DO-178C

DO-178C, Consideraciones de software en la certificación de sistemas y equipos aerotransportados, es el documento principal mediante el cual las autoridades de certificación, como la FAA , la EASA y Transport Canada, aprueban todos los sistemas aeroespaciales comerciales basados ​​en software. El documento es publicado por RTCA, Incorporated , en colaboración con EUROCAE y reemplaza a DO-178B . El nuevo documento se denomina DO-178C/ED-12C, se completó en noviembre de 2011 y fue aprobado por RTCA en diciembre de 2011. Estuvo disponible para su venta y uso en enero de 2012. ^{[ 1 ] [ 2 ] [ 3 ]}

Excepto por FAR 33 / JAR E, las Regulaciones Federales de Aviación no hacen referencia directa a la aeronavegabilidad del software . ^{[ 4 ]} El 21 de julio de 2017, la FAA aprobó AC 20-115D , designando a DO-178C como un "medio aceptable, pero no el único, reconocido para demostrar el cumplimiento con las regulaciones de aeronavegabilidad FAR aplicables para los aspectos de software de la certificación de sistemas y equipos a bordo". ^{[ 5 ]}

Desde la publicación de DO-178B , los Representantes de Ingeniería Designados (DER) de la FAA habían solicitado enérgicamente la aclaración y el perfeccionamiento de las definiciones y los límites entre los conceptos clave de DO-178B: requisitos de alto nivel, requisitos de bajo nivel y requisitos derivados, así como una mejor definición de los criterios de entrada y salida entre los requisitos del sistema y el diseño del sistema (véase ARP4754 ) y los requisitos del software y el diseño del software (que es el ámbito de DO-178B). Otras preocupaciones incluían el significado de la verificación en un paradigma de desarrollo basado en modelos y consideraciones para reemplazar algunas o todas las actividades de prueba de software con simulación de modelos o métodos formales. La publicación de DO-178C y los documentos complementarios DO-278A (Sistemas terrestres), DO-248C (Información adicional con justificación para cada objetivo de DO-178C), DO-330 (Calificación de herramientas), DO-331 (Modelado), DO-332 (Orientado a objetos) y DO-333 (Métodos formales) se crearon para abordar los problemas señalados. Los miembros del SC-205 colaboraron con el comité SAE S-18 para garantizar que el ARP4754A y los documentos DO-xxx mencionados anteriormente proporcionen un proceso unificado y vinculado con criterios complementarios.

En general, DO-178C conserva la mayor parte del texto de DO-178B, lo que ha generado preocupación de que algunos problemas de DO-178B, como la ambigüedad sobre el concepto de requisitos de bajo nivel, no se resuelvan por completo. ^{[ 6 ]}

El trabajo del comité conjunto RTCA/EUROCAE se dividió en siete subgrupos:

• SG1: Integración de documentos del SCWG
• SG2: Problemas y justificación
• SG3: Calificación de herramientas
• SG4: Desarrollo y verificación basados ​​en modelos
• SG5: Tecnología orientada a objetos
• SG6: Métodos formales
• SG7: Consideraciones relacionadas con la seguridad

El subgrupo de Desarrollo y Verificación Basados ​​en Modelos (SG4) fue el más grande de los grupos de trabajo. Todo el trabajo se recopila y coordina a través de un sitio web que funciona como un mecanismo de gestión de trabajo colaborativo. ^{[ 7 ]} Los artefactos de trabajo y los borradores de documentos se guardaban en un área restringida accesible solo para los miembros del grupo.

El trabajo se centró en actualizar DO-178B/ED-12B con respecto a las prácticas, herramientas y tecnologías actuales de desarrollo de software. ^{[ 8 ] [ 9 ]}

El nivel de software , también conocido como nivel de garantía de desarrollo (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 ^{[ 10 ]} ), se determina a partir del proceso de evaluación de seguridad y análisis de riesgos , 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.

• Catastrófico : El fallo puede provocar muertes, generalmente con la pérdida de la aeronave.
• Peligroso : Un fallo 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 dificultades físicas o una mayor carga de trabajo, o causa lesiones graves o mortales entre los pasajeros.
• Grave : Un fallo reduce significativamente el margen de seguridad o aumenta considerablemente la carga de trabajo de la tripulación. Puede provocar molestias a los pasajeros (o incluso lesiones leves).
• Menor : Un fallo reduce ligeramente el margen de seguridad o aumenta ligeramente la carga de trabajo de la tripulación. Algunos ejemplos podrían ser las molestias que pueda causar a los pasajeros o un cambio rutinario en el plan de vuelo.
• Sin efecto : El fallo no tiene repercusión en la seguridad, el funcionamiento de la aeronave ni la carga de trabajo de la tripulación.

DO-178C por sí solo no pretende garantizar los aspectos de seguridad del software. Los atributos de seguridad en el diseño y tal como se implementan 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. Las autoridades de certificación exigen y DO-178C especifica que se establezca el DAL correcto utilizando estos métodos de análisis exhaustivos para establecer el nivel de software AE. "El nivel de software establece el rigor necesario para demostrar el cumplimiento" con DO-178C. ^{[ 10 ]} Cualquier software que comanda, controle y supervise funciones críticas para la seguridad debe recibir el DAL más alto: Nivel A.

El número de objetivos que deben cumplirse (algunos con independencia) viene determinado por el nivel de software AE. La expresión «con independencia» se refiere a una separación de responsabilidades donde la objetividad de los procesos de verificación y validación se garantiza gracias a su «independencia» del equipo de desarrollo de 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 quien lo creó, y esta separación debe estar claramente documentada. ^{[ 11 ]}

Los procesos están diseñados para respaldar los objetivos, según el nivel de software (de la A a la D; el nivel E quedaba fuera del alcance de la norma DO-178C). En esta norma, los procesos se describen como áreas de trabajo abstractas, y corresponde a los planificadores de un proyecto real definir y documentar los detalles de su ejecución. En un proyecto real, las actividades concretas que se realizarán en el contexto de un proceso deben demostrar su eficacia para respaldar los objetivos. Estas actividades son definidas por los planificadores del proyecto como parte del proceso de planificación.

La naturaleza objetiva de la norma DO-178C permite una gran flexibilidad en cuanto a la adaptación a diferentes estilos de ciclo de vida del software . Una vez definida una actividad dentro de un proceso, se espera que el proyecto respete dicha actividad documentada. Además, según la norma DO-178C, los procesos (y sus actividades concretas) deben tener criterios de entrada y salida bien definidos, y el proyecto debe demostrar que los cumple al realizar las actividades del proceso.

La flexibilidad de los procesos y los criterios de entrada/salida de la norma DO-178C dificulta su implementación inicial, ya que estos aspectos son abstractos y no existe un conjunto básico de actividades a partir del cual trabajar. La intención de la DO-178C no era ser prescriptiva. Existen muchas maneras posibles y aceptables de definir estos aspectos en un proyecto real. Esto puede resultar complicado la primera vez que una empresa intenta desarrollar un sistema de aviónica civil bajo esta norma, lo que ha generado un nicho de mercado para la formación y la consultoría en DO-178C.

Para un proceso genérico basado en DO-178C, las Etapas de Participación (SOI) son las puertas mínimas en las que una Autoridad de Certificación se involucra al revisar un sistema o subsistema según lo definido por EASA en el Memorando de Certificación SWCEH – 002: Directrices de Aprobación de Software y FAA en la Orden 8110.49: Directrices de Aprobación de Software .

La norma DO-178 exige conexiones bidireccionales documentadas (denominadas trazas) entre los artefactos de certificación. Por ejemplo, un requisito de bajo nivel (LLR) se rastrea hasta un requisito de alto nivel (HLR) que debe satisfacer, y también se rastrea hasta las líneas de código fuente destinadas a implementarlo, los casos de prueba destinados a verificar la corrección del código fuente con respecto al requisito, los resultados de dichas pruebas, etc. Posteriormente, se utiliza un análisis de trazabilidad para asegurar que cada requisito se cumpla mediante el código fuente, que cada requisito funcional se verifique mediante pruebas, que cada línea de código fuente tenga un propósito (esté conectada a un requisito), y así sucesivamente. El análisis de trazabilidad evalúa la completitud del sistema. El rigor y el detalle de los artefactos de certificación están relacionados con el nivel de software.

El SC-205/WG-12 fue responsable de revisar el DO-178B/ED-12B para actualizarlo con respecto a las tecnologías actuales de desarrollo y verificación de software. La estructura del documento permanece prácticamente igual de B a C. Algunos ejemplos de cambios incluyen: ^{[ 13 ]}

• Proporcionar un lenguaje y una terminología más claros, proporcionar mayor coherencia.
• Más objetivos (para los niveles A, B y C)
• Se aclaró el "objetivo oculto", aplicable al Nivel A, que estaba implícito en la sección 6.4.4.2b de la norma DO-178B , pero no figuraba en las tablas del Anexo A. Este objetivo ahora se enumera explícitamente en la norma DO-178C, Anexo A, Tabla A-7, Objetivo 9: "Se logra la verificación del código adicional que no puede rastrearse hasta el Código Fuente". ^{[ 14 ]}
• Archivos de datos de parámetros: Proporcionan información independiente que influye en el comportamiento de un código objeto ejecutable (sin modificarlo). Un ejemplo sería un archivo de configuración que establece la planificación y los principales intervalos de tiempo de un sistema operativo particionado. El archivo de datos de parámetros debe verificarse junto con el código objeto ejecutable, o bien debe probarse para todos los rangos posibles de los parámetros.
• DO-330 "Consideraciones sobre la cualificación de herramientas de software", un nuevo documento externo e independiente del dominio, se desarrolló para proporcionar orientación sobre un proceso de cualificación de herramientas aceptable. Si bien DO-178B se utilizó como base para el desarrollo de este nuevo documento, el texto se adaptó para que fuera aplicable directa e independientemente al desarrollo de herramientas y se amplió para abordar todos los aspectos de las herramientas. Como documento independiente del dominio, DO-330 está destinado a utilizarse no solo como apoyo de DO-178C/ED-12C, sino también de DO-278 /ED-109, DO-254/ED-80 y DO-200 , incluso para aplicaciones no aeronáuticas, por ejemplo, ISO 26262 o ECSS . ^{[ 15 ]} En consecuencia, la guía de cualificación de herramientas se eliminó de DO-178C y se sustituyó por una guía para decidir cuándo aplicar la guía de cualificación de herramientas DO-330 a las herramientas utilizadas en un contexto DO-178C. ^{[ 16 ]}
• Se añadieron suplementos tecnológicos para extender la guía del documento DO-178C a técnicas específicas. En lugar de ampliar el texto anterior para abarcar todas las técnicas de desarrollo de software actuales y futuras, los suplementos permiten añadir, eliminar o modificar explícitamente la guía del estándar principal para su aplicación a técnicas o tecnologías específicas. Toda la guía de estos suplementos se redacta en el contexto de los elementos de guía afectados en DO-178C y, por lo tanto, debe considerarse con el mismo nivel de autoridad que dicho documento principal. ^{[ 17 ]}
  • DO-331 "Suplemento de desarrollo y verificación basados ​​en modelos para DO-178C y DO-278A": aborda el desarrollo y la verificación basados ​​en modelos (MBD) y la capacidad de utilizar técnicas de modelado para mejorar el desarrollo y la verificación, evitando al mismo tiempo los inconvenientes inherentes a algunos métodos de modelado.
  • DO-332 "Tecnología orientada a objetos y técnicas relacionadas. Suplemento a DO-178C y DO-278A": aborda el software orientado a objetos y las condiciones bajo las cuales puede utilizarse.
  • DO-333 "Métodos formales suplementarios a DO-178C y DO-278A": aborda los métodos formales para complementar (pero no reemplazar) las pruebas.

• DO-178B
• DO-248C , Información complementaria para DO-178C y DO-278A
• Cobertura de condiciones/decisiones modificadas

• Glosario DO-178C , 2023
• Charlotte Adams (21 de octubre de 2010). "El software de seguridad crítica para aplicaciones de misión crítica recibirá un impulso con la publicación de DO-178C" . Military & Aerospace Electronics . Consultado el 4 de febrero de 2014 .
• Charlotte Adams (1 de septiembre de 2010). "Cambios en el núcleo del DO-178C" . Avionics Intelligence . Consultado el 23 de octubre de 2010 .
• Bill StClair y Nat Hillary (2010). "DO-178C: Certificación mejorada para sistemas de aviónica rentables" . VME and Critical Systems . Archivado del original el 17 de julio de 2011. Recuperado el 23 de octubre de 2010 .
• John McHale (8 de octubre de 2009). "Actualización a la certificación DO-178B, DO-178C, para abordar las tendencias modernas del software de aviónica" . Avionics Intelligence . Archivado del original el 14 de julio de 2011. Recuperado el 23 de octubre de 2010 .
• Frederic Pothon (2012). "DO-178C/ED-12C vs DO-178B/ED-12B: Cambios y mejoras" . Open DO . Archivado del original el 17 de diciembre de 2012. Recuperado el 23 de octubre de 2010 .