DO-178B, Consideraciones de software en la certificación de equipos y sistemas de a bordo, es una directriz que trata sobre la seguridad del software crítico para la seguridad utilizado en ciertos sistemas de a bordo. Fue desarrollado conjuntamente por el grupo de trabajo crítico para la seguridad RTCA SC-167 de RTCA y WG-12 de EUROCAE . RTCA publicó el documento como RTCA / DO-178B , mientras que EUROCAE publicó el documento como ED-12B . Aunque técnicamente era una guía, era un estándar de facto para el desarrollo de sistemas de software de aviónica hasta que fue reemplazado en 2012 por DO-178C .
Ultima versión | 1 de diciembre de 1992 |
---|---|
Organización | |
Dominio | Aviación |
Abreviatura |
|
La FAA aplica DO-178B como el documento que utiliza como guía para determinar si el software funcionará de manera confiable en un ambiente aéreo, [1] cuando lo especifique la Orden Técnica Estándar (TSO) para la cual se solicita la certificación. En los Estados Unidos, la introducción de TSO en el proceso de certificación de aeronavegabilidad, y por extensión DO-178B, se establece explícitamente en el Título 14: Aeronáutica y Espacio del Código de Regulaciones Federales (CFR), también conocido como Regulaciones Federales de Aviación . Parte 21, Subparte O.
Nivel de software
El nivel de software , también conocido como nivel de garantía de diseño (DAL) o nivel de garantía de desarrollo de elementos (IDAL) según se define en ARP4754 ( DO-178C solo menciona IDAL como sinónimo de nivel de software [2] ), se determina a partir del proceso de evaluación de seguridad. y análisis de peligros mediante el examen de los efectos de una condición de falla en el sistema. Las condiciones de falla se clasifican por sus efectos en la aeronave, la tripulación y los pasajeros.
- Catastrófico : la falla puede causar un accidente. Error o pérdida de la función crítica necesaria para volar y aterrizar aeronaves de forma segura.
- Peligroso : la falla tiene un gran impacto negativo en la seguridad o el rendimiento, o reduce la capacidad de la tripulación para operar la aeronave debido a angustia física o una mayor carga de trabajo, o causa lesiones graves o fatales entre los pasajeros. (Importante para la seguridad)
- Mayor : la falla es significativa, pero tiene un impacto menor que una falla peligrosa (por ejemplo, provoca molestias a los pasajeros en lugar de lesiones) o aumenta significativamente la carga de trabajo de la tripulación (relacionada con la seguridad)
- Menor : la falla es notable, pero tiene un impacto menor que una falla mayor (por ejemplo, causar molestias al pasajero o un cambio de plan de vuelo de rutina)
- Sin efecto : la falla no tiene impacto en la seguridad, la operación de la aeronave o la carga de trabajo de la tripulación.
DO-178B por sí solo no pretende garantizar los aspectos de seguridad del software. Los atributos de seguridad en el diseño e implementados como funcionalidad, deben recibir tareas de seguridad del sistema obligatorias adicionales para conducir y mostrar evidencia objetiva del cumplimiento de requisitos de seguridad explícitos. Por lo general, los planes de seguridad del software IEEE STD-1228-1994 se asignan y las tareas de análisis de seguridad del software se realizan en pasos secuenciales (análisis de requisitos, análisis de diseño de nivel superior, análisis de diseño detallado, análisis de nivel de código, análisis de prueba y análisis de cambios). Estas tareas y artefactos de seguridad del software son partes integrales de apoyo del proceso para que la gravedad del peligro y la determinación de DAL se documenten en las evaluaciones de seguridad del sistema (SSA). Las autoridades de certificación requieren y DO-178B especifica que se establezca el DAL correcto utilizando estos métodos de análisis integrales para establecer el nivel de software AE. Cualquier software que ordene, controle y monitoree funciones críticas para la seguridad debe recibir el DAL más alto - Nivel A. Son los análisis de seguridad del software los que impulsan las evaluaciones de seguridad del sistema los que determinan el DAL que impulsa el nivel apropiado de rigor en DO-178B. Las evaluaciones de seguridad del sistema combinadas con métodos como SAE ARP 4754A determinan el DAL posterior a la mitigación y pueden permitir la reducción de los objetivos de nivel de software DO-178B para ser satisfechos si la redundancia, las características de seguridad de diseño y otras formas arquitectónicas de mitigación de peligros están en los requisitos impulsados los análisis de seguridad. Por lo tanto, el tema central de DO-178B es la garantía y verificación del diseño después de que se hayan establecido los requisitos previos de seguridad.
El número de objetivos a satisfacer (eventualmente con independencia) está determinado por el nivel de software AE. La frase "con independencia" se refiere a una separación de responsabilidades donde la objetividad de los procesos de verificación y validación está asegurada en virtud de su "independencia" del equipo de desarrollo de software. Para los objetivos que deben satisfacerse con independencia, la persona que verifica el elemento (como un requisito o un código fuente) puede no ser la persona que creó el elemento y esta separación debe estar claramente documentada. [3] En algunos casos, una herramienta automatizada puede equivaler a la independencia. [4] Sin embargo, la herramienta en sí debe ser calificada si sustituye a la revisión humana.
Nivel | Condición de falla | Objetivos [5] | Con independencia | Tasa de fracaso |
---|---|---|---|---|
A | Catastrófico | 66 | 25 | 10 −9 / h |
B | Peligroso | sesenta y cinco | 14 | 10 −7 / h |
C | Importante | 57 | 2 | 10 −5 / h |
D | Menor | 28 | 2 | 10 −3 / h |
mi | Sin efecto | 0 | 0 | n / A |
Procesos y documentos
Los procesos están destinados a respaldar los objetivos, de acuerdo con el nivel de software (A a D, el nivel E estaba fuera del alcance de DO-178B). Los procesos se describen como áreas de trabajo abstractas en DO-178B, y depende de los planificadores de un proyecto real definir y documentar los detalles de cómo se llevará a cabo un proceso. En un proyecto real, las actividades reales que se realizarán en el contexto de un proceso deben mostrarse para respaldar los objetivos. Los planificadores del proyecto definen estas actividades como parte del proceso de planificación.
Esta naturaleza basada en objetivos de DO-178B permite una gran flexibilidad con respecto a seguir diferentes estilos de ciclo de vida del software . Una vez que se ha definido una actividad dentro de un proceso, generalmente se espera que el proyecto respete esa actividad documentada dentro de su proceso. Además, los procesos (y sus actividades concretas) deben tener criterios de entrada y salida bien definidos, de acuerdo con DO-178B, y un proyecto debe demostrar que está respetando esos criterios mientras realiza las actividades en el proceso.
La naturaleza flexible de los procesos de DO-178B y los criterios de entrada / salida dificultan la implementación la primera vez, porque estos aspectos son abstractos y no existe un "conjunto base" de actividades desde las que trabajar. La intención de DO-178B no era prescriptiva. Hay muchas formas posibles y aceptables para que un proyecto real defina estos aspectos. Esto puede resultar difícil la primera vez que una empresa intenta desarrollar un sistema de aviónica civil bajo este estándar y ha creado un nicho de mercado para la capacitación y consultoría DO-178B.
Para un proceso genérico basado en DO-178B, se proporciona un resumen visual que incluye las Etapas de participación (SOI) definidas por la FAA en las "Orientaciones y ayudas de trabajo para software y hardware electrónico complejo".
Planificación
Los requisitos del sistema se suelen incluir en todo el proyecto.
Los últimos 3 documentos (estándares) no son necesarios para el nivel de software D ..
Desarrollo
DO-178B no está diseñado como un estándar de desarrollo de software; es garantía de software que utiliza un conjunto de tareas para cumplir objetivos y niveles de rigor.
Los documentos de salida del proceso de desarrollo:
- Datos de requisitos de software (SRD)
- Descripción del diseño de software (SDD)
- Código fuente
- Código de objeto ejecutable
Por lo general, se requiere la trazabilidad desde los requisitos del sistema hasta todo el código fuente o código objeto ejecutable (según el nivel de software).
Proceso de desarrollo de software utilizado habitualmente :
Verificación
Documentar los resultados obtenidos por este proceso:
- Casos y procedimientos de verificación de software (SVCP)
- Resultados de la verificación del software (SVR):
- Revisión de todos los requisitos, diseño y código.
- Prueba de código objeto ejecutable
- Análisis de cobertura de código
Por lo general, se requiere el análisis de todo el código y la trazabilidad desde las pruebas y los resultados hasta todos los requisitos (según el nivel de software).
Este proceso también suele implicar:
- Herramientas de prueba basadas en requisitos
- Herramientas de análisis de cobertura de código
Otros nombres para las pruebas realizadas en este proceso pueden ser:
Gestión de la configuración
Documentos mantenidos por el proceso de gestión de la configuración :
- Índice de configuración de software (SCI)
- Índice de configuración del entorno del ciclo de vida del software (SECI)
Este proceso maneja informes de problemas, cambios y actividades relacionadas. El proceso de gestión de la configuración normalmente proporciona identificación de revisión y archivo de:
- Entorno de desarrollo de código fuente
- Otros entornos de desarrollo (por ejemplo, herramientas de prueba / análisis)
- Herramienta de integración de software
- Todos los demás documentos, software y hardware
Seguro de calidad
Documentos de salida del proceso de garantía de calidad:
- Registros de garantía de calidad del software (SQAR)
- Revisión de conformidad de software (SCR)
- Resumen de logros de software (SAS)
Este proceso realiza revisiones y auditorías para demostrar el cumplimiento de DO-178B. La interfaz con la autoridad de certificación también es manejada por el proceso de aseguramiento de la calidad.
Enlace de certificación
Por lo general, un Representante de ingeniería designado (DER) revisa los datos técnicos como parte de la presentación a la FAA para su aprobación.
Herramientas
El software puede automatizar, asistir o manejar o ayudar en los procesos DO-178B. Todas las herramientas utilizadas para el desarrollo de DO-178B deben formar parte del proceso de certificación. Las herramientas que generan código incrustado se califican como herramientas de desarrollo , con las mismas restricciones que el código incrustado. Las herramientas utilizadas para verificar el código (simuladores, herramienta de ejecución de pruebas, herramientas de cobertura, herramientas de informes, etc.) deben calificarse como herramientas de verificación , un proceso mucho más ligero que consiste en una prueba exhaustiva de caja negra de la herramienta.
Una herramienta de terceros puede calificarse como herramienta de verificación, pero las herramientas de desarrollo deben haberse desarrollado siguiendo el proceso DO-178. Las empresas que proporcionan este tipo de herramientas como COTS están sujetas a auditorías de las autoridades de certificación, a las que dan acceso completo al código fuente, las especificaciones y todos los artefactos de certificación.
Fuera de este alcance, la salida de cualquier herramienta utilizada debe ser verificada manualmente por humanos.
- Una herramienta de gestión de problemas puede proporcionar la trazabilidad de los cambios.
- Se pueden crear SCI y SECI a partir de registros en una herramienta de control de revisiones .
Gestión de requerimientos
La trazabilidad de requisitos se ocupa de documentar la vida de un requisito. Debería ser posible rastrear hasta el origen de cada requisito y, por tanto, todos los cambios realizados en el requisito deberían documentarse para lograr la trazabilidad. Incluso el uso del requisito después de que se hayan implementado y utilizado las características implementadas debería ser rastreable.
Crítica
VDC Research señala que DO-178B se ha vuelto "algo anticuado" porque no se adapta bien a las necesidades y preferencias de los ingenieros de hoy. En el mismo informe, también señalan que DO-178C parece estar bien preparado para abordar este problema. [ cita requerida ]
Recursos
- FAR Parte 23/25 §1301 / §1309
- FAR parte 27/29
- AC 23 / 25.1309
- CA 20-115B
- RTCA / DO-178B
- Orden de FAA 8110.49 Pautas de aprobación de software
Ver también
- DO-178C
- Software de aviónica
- ARP4761 (proceso de evaluación de la seguridad)
- ARP4754 (proceso de desarrollo del sistema)
- DO-248B (Informe final para aclarar DO-178B)
- DO-254 (similar a DO-178B, pero para hardware)
- Gestión de requisitos (demasiado general para "aplicarse directamente" a DO-178B)
- IEC 61508
- ISO / IEC 12207 (estándar de desarrollo del proceso del ciclo de vida del software)
- ED-153 (Directrices para la garantía de seguridad del software ANS)
- Cobertura de decisión / condición modificada
- Aeroespacial DO-178B
Referencias
- ^ Circular de asesoramiento de la FAA 20-115B
- ^ RTCA / DO-178C "Consideraciones de software en la certificación de equipos y sistemas aerotransportados", p. 116. "Un ejemplo es el término" nivel de garantía de desarrollo de elementos "(IDAL), que para software es sinónimo del término" nivel de software ".
- ^ RTCA / DO-178B "Consideraciones de software en la certificación de equipos y sistemas aerotransportados", p. 82
- ^ RTCA / DO-178B "Consideraciones de software en la certificación de equipos y sistemas aerotransportados", p.82
- ^ RTCA / DO-178B "Consideraciones de software en la certificación de equipos y sistemas aerotransportados", Anexo A
enlaces externos
- AC 25.1309-1A
- CA 20-115B
- Orden FAA 8110.49 Cambio 1