DO-178B, Consideraciones de software en la certificación de equipos y sistemas aerotransportados es una directriz que trata sobre la seguridad del software crítico para la seguridad utilizado 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 el WG-12 de la Organización Europea de 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 el desarrollo de sistemas de software de aviónica hasta que fue reemplazado en 2012 por el DO-178C .
La Administración Federal de Aviación (FAA) aplica DO-178B como 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 de norma técnica (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 del DO-178B, está explícitamente establecida 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 peligros examinando 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.
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 obligatorias adicionales de seguridad del sistema para conducir y mostrar evidencia objetiva de que cumplen con los requisitos de seguridad explícitos. Por lo general, se asignan planes de seguridad de software IEEE STD-1228-1994 y las tareas de análisis de seguridad de 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 pruebas y análisis de cambios). Estas tareas y artefactos de seguridad del software son partes integrales de soporte del proceso para que la gravedad de los peligros y la determinación de DAL se documenten en las evaluaciones de seguridad del sistema (SSA). Las autoridades de certificación exigen 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 que se cumplan los objetivos de reducción del nivel de software DO-178B si la redundancia, las características de seguridad de 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 del 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 cumplir (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 de software. Para 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 equivaler a independencia. [4] Sin embargo, la herramienta en sí debe ser calificada si sustituye la revisión humana.
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 corresponde a los planificadores de un proyecto real definir y documentar los detalles de cómo se llevará a cabo un proceso. En un proyecto real, se deben mostrar 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 del 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, según DO-178B, y un proyecto debe demostrar que respeta esos criterios mientras realiza las actividades en el proceso.
La naturaleza flexible de los procesos y criterios de entrada/salida de DO-178B hacen que sea difícil implementarlo 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 DO-178B no era ser 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 según este estándar y ha creado un nicho de mercado para la capacitación y consultoría del 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 laborales para software y hardware electrónico complejo".
Los requisitos del sistema suelen incluirse en todo el proyecto.
Los últimos 3 documentos (estándares) no son necesarios para el nivel de software D.
DO-178B no pretende ser un estándar de desarrollo de software; es un aseguramiento del software que utiliza un conjunto de tareas para cumplir objetivos y niveles de rigor.
Los documentos de salida del proceso de desarrollo:
Generalmente se requiere trazabilidad desde los requisitos del sistema hasta todo el código fuente o el código objeto ejecutable (según el nivel de software).
Proceso de desarrollo de software utilizado habitualmente :
Salidas documentales obtenidas por este proceso:
Normalmente 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 normalmente también implica:
Otros nombres para las pruebas realizadas en este proceso pueden ser:
Documentos mantenidos por el proceso de gestión de configuración :
Este proceso maneja informes de problemas, cambios y actividades relacionadas. El proceso de gestión de configuración normalmente 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 DO-178B. La interfaz con la autoridad de certificación también se gestiona mediante el proceso de garantía 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, ayudar o manejar o ayudar en los procesos DO-178B. Todas las herramientas utilizadas para el desarrollo de DO-178B deben ser 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 haber sido desarrolladas 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 les dan acceso completo al código fuente, las especificaciones y todos los artefactos de certificación.
Fuera de este alcance, los resultados de cualquier herramienta utilizada deben ser verificados manualmente por humanos.
La trazabilidad de requisitos se ocupa de documentar la vida de un requisito. Debería ser posible rastrear el origen de cada requisito y, por lo tanto, cada cambio realizado en el requisito debería documentarse para lograr la trazabilidad. Incluso el uso del requisito después de que se hayan implementado y utilizado las funciones implementadas debe ser rastreable.
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 actuales. En el mismo informe, también señalan que el DO-178C parece estar bien preparado para abordar esta cuestión. [ cita necesaria ]