DO-178B, Consideraciones de software en la certificación de sistemas y equipos a bordo, es una directriz que trata sobre la seguridad del software crítico para la seguridad utilizado en ciertos sistemas a bordo. Fue desarrollada conjuntamente por el grupo de trabajo de seguridad crítica RTCA SC-167 de la Comisión Técnica de Radio para Aeronáutica (RTCA) y el 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 lo publicó como ED-12B . Aunque técnicamente es una directriz , fue un estándar de facto para el desarrollo de sistemas de software de aviónica hasta que fue reemplazado en 2012 por DO-178C .
La Administración Federal de Aviación (FAA) aplica el 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 especifica la Orden Técnica Estándar (TSO) para la cual se busca la certificación. En los Estados Unidos, la introducción de TSO en el proceso de certificación de aeronavegabilidad, y por extensión el DO-178B, está explícitamente establecido en el Título 14: Aeronáutica y Espacio del Código de Reglamentos Federales (CFR), también conocido como Reglamento Federal de Aviación , 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 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 según sus efectos en la aeronave, la tripulación y los pasajeros.
La norma DO-178B por sí sola 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 de que se cumplen los requisitos de seguridad explícitos. Normalmente, 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 alto nivel, análisis de diseño detallado, análisis de nivel de código, análisis de pruebas y análisis de cambios). Estas tareas y artefactos de seguridad del software son partes integrales de apoyo del proceso para la gravedad del peligro y la determinación de DAL que se documentarán en las evaluaciones de seguridad del sistema (SSA). Las autoridades de certificación requieren y la norma DO-178B especifica que se establezca la DAL correcta utilizando estos métodos de análisis integrales para establecer el AE de nivel de software. Cualquier software que ordene, controle y monitoree funciones críticas para la seguridad debe recibir la DAL más alta: Nivel A. Son los análisis de seguridad del software los que impulsan las evaluaciones de seguridad del sistema que determinan la DAL que impulsa el nivel adecuado de rigor en la norma 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 de DO-178B que se deben satisfacer si la redundancia, las características de seguridad de diseño y otras formas arquitectónicas de mitigación de riesgos se encuentran 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 que se deben satisfacer (eventualmente con independencia) está determinado por el AE del nivel de software. 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 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 ser calificada si sustituye a la revisión humana.
Los procesos tienen como objetivo respaldar los objetivos, según el nivel de software (A a D; el nivel E estaba fuera del alcance de DO-178B). Los procesos se describen como áreas abstractas de trabajo en DO-178B, y corresponde a los planificadores de un proyecto real definir y documentar los detalles específicos de cómo se llevará a cabo un proceso. En un proyecto real, se deben demostrar las actividades reales que se realizarán en el contexto de un proceso para respaldar los objetivos. Estas actividades son definidas por los planificadores del proyecto como parte del proceso de Planificación.
Esta naturaleza basada en objetivos de la DO-178B permite una gran flexibilidad en lo que respecta al seguimiento de 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 la DO-178B, y un proyecto debe demostrar que está respetando esos criterios a medida que realiza las actividades en el proceso.
La naturaleza flexible de los procesos y criterios de entrada y salida de la DO-178B dificulta su implementación la primera vez, porque estos aspectos son abstractos y no existe un "conjunto básico" de actividades a partir del cual trabajar. La intención de la DO-178B no era ser prescriptiva. Existen 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 esta norma, y ha creado un nicho de mercado para la capacitación y consultoría de la 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 la "Guía y ayudas de trabajo para software y hardware electrónico complejo".
Los requisitos del sistema normalmente se incorporan a todo el proyecto.
Los últimos 3 documentos (estándares) no son necesarios para el nivel de software D.
DO-178B no está pensado como un estándar de desarrollo de software; es una 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 son:
Generalmente se requiere trazabilidad desde los requisitos del sistema hasta todo el código fuente o el código de objeto ejecutable (dependiendo del nivel del software).
Proceso de desarrollo de software normalmente utilizado :
Resultados documentales obtenidos mediante este proceso:
Generalmente se requiere el análisis de todo el código y la trazabilidad desde las pruebas y los resultados hasta todos los requisitos (dependiendo del nivel del software).
Este proceso normalmente también implica:
Otros nombres para las pruebas realizadas en este proceso pueden ser:
Documentos mantenidos por el proceso de gestión de la configuración :
Este proceso maneja informes de problemas, cambios y actividades relacionadas. El proceso de gestión de configuración generalmente proporciona identificación de revisión y archivo de:
Documentos de salida del proceso de aseguramiento de la calidad:
Este proceso realiza revisiones y auditorías para demostrar el cumplimiento de la norma DO-178B. La interfaz con la autoridad de certificación también está a cargo del proceso de control de calidad.
Normalmente, 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.
El software puede automatizar, asistir o de otra manera manejar o ayudar en los procesos DO-178B. Todas las herramientas utilizadas para el desarrollo DO-178B deben ser parte del proceso de certificación. Las herramientas que generan código embebido se califican como herramientas de desarrollo , con las mismas restricciones que el código embebido. Las herramientas utilizadas para verificar el código (simuladores, herramienta de ejecución de pruebas, herramientas de cobertura, herramientas de generación de informes, etc.) deben calificarse como herramientas de verificación , un proceso mucho más ligero que consiste en una prueba de caja negra integral de la herramienta.
Una herramienta de terceros puede ser calificada como herramienta de verificación, pero las herramientas de desarrollo deben haber sido desarrolladas siguiendo el proceso DO-178. Las empresas que ofrecen este tipo de herramientas como COTS están sujetas a auditorías por parte 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.
La trazabilidad de los requisitos se ocupa de documentar la vida de un requisito. Debe ser posible rastrear el origen de cada requisito y, por lo tanto, cada cambio realizado en el requisito debe documentarse para lograr la trazabilidad. Incluso el uso del requisito después de que se hayan implementado y utilizado las características implementadas debe ser rastreable.
VDC Research señala que el DO-178B se ha vuelto "algo anticuado" en el sentido de que no se adapta bien a las necesidades y preferencias de los ingenieros actuales. En el mismo informe, también señalan que el DO-178C parece estar bien preparado para abordar este problema. [ cita requerida ]