DO-178B, Consideraciones de software en sistemas aerotransportados y certificación de equipos es una guía que trata sobre la seguridad del software crítico para la seguridad que se utiliza en ciertos sistemas aerotransportados. Fue desarrollado conjuntamente por el grupo de trabajo crítico para la seguridad RTCA SC-167 de la Comisión Técnica de Radio para Aeronáutica (RTCA) y WG-12 de la Organización Europea para Equipos de Aviación Civil (EUROCAE). RTCA publicó el documento como RTCA/DO-178B , mientras que EUROCAE publicó el documento como ED-12B . Aunque técnicamente es una guía, fue un estándar de facto para desarrollar sistemas de software de aviónica hasta que fue reemplazado en 2012 por DO-178C..
La Administración Federal de Aviación (FAA) aplica DO-178B como el documento que utiliza como guía para determinar si el software funcionará de manera confiable en un entorno aéreo, [1] cuando lo especifique la Orden Técnica Estándar (TSO) para la cual se busca la certificación. En Estados Unidos, la introducción de los 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 Code of Federal Regulations (CFR), también conocido como Federal Aviation Regulations , Parte 21, Subparte O.
El nivel de software , también denominado 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 la seguridad y análisis de riesgos 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.
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 impulsar y mostrar evidencia objetiva del cumplimiento de los 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 soporte del proceso para la determinación de la gravedad del peligro y DAL que se documentará 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 que determinan el DAL que impulsa el nivel apropiado de rigor en DO-178B. Las evaluaciones de seguridad del sistema combinadas con métodos tales comoLas evaluaciones de seguridad del sistema combinadas con métodos tales comoLas evaluaciones de seguridad del sistema combinadas con métodos tales comoSAE ARP 4754A determina el DAL posterior a la mitigación y puede permitir que se satisfagan los objetivos de reducción del nivel de software DO-178B si la redundancia, las características de seguridad del diseño y otras formas arquitectónicas de mitigación de riesgos están en los requisitos impulsados por 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 de seguridad previos.
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 se asegura la objetividad de los procesos de verificación y validación en virtud de su “independencia” del equipo de desarrollo del software. Para los objetivos que deben cumplirse con independencia, la persona que verifica el elemento (como un requisito o el 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 ser equivalente a la independencia. [4] Sin embargo, la herramienta en sí debe calificarse si sustituye a la revisión humana.