DO-178C, Consideraciones de software en la certificación de equipos y sistemas aerotransportados, es el documento principal mediante el cual las autoridades de certificación como la FAA , EASA y Transport Canada aprueban todos los sistemas aeroespaciales comerciales basados en software. El documento es publicado por RTCA, Incorporated , en un esfuerzo conjunto con EUROC y reemplaza DO-178B . El nuevo documento se llama DO-178C/ED-12C y se completó en noviembre de 2011 y fue aprobado por la RTCA en diciembre de 2011. Estuvo disponible para la venta y uso en enero de 2012. [1] [2] [3]
A excepción de FAR 33 / JAR E, el Reglamento Federal de Aviación no hace referencia directa a la aeronavegabilidad del software. [4] El 19 de julio de 2013, la FAA aprobó el AC 20-115C , designando al DO-178C como un "medio aceptable, pero no el único, reconocido para demostrar el cumplimiento de las regulaciones de aeronavegabilidad FAR aplicables para los aspectos de software de los sistemas y equipos a bordo". Certificación." [5]
Desde el lanzamiento de DO-178B , ha habido fuertes llamados por parte de los DER ( Representantes de ingeniería designados por la FAA ) para que se aclaren/refinan las definiciones y los límites entre los conceptos clave de DO-178B de requisitos de alto nivel, requisitos de bajo nivel y derivados. requisitos y una mejor definición de los criterios de salida/entrada entre los requisitos de los sistemas y el diseño del sistema (ver ARP4754 ) y el de los requisitos de software y el diseño de software (que es el dominio de DO-178B). Otras preocupaciones incluyeron el significado de 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 fundamento para cada objetivo de DO-178C), DO-330 (Cualificación de herramientas), DO-331 (Modelado), DO -332 (Orientado a objetos) y DO-333 (Métodos formales) se crearon para abordar los problemas observados. Los miembros del SC-205 trabajaron con el comité SAE S-18 para garantizar que ARP4754A y los documentos DO-xxx mencionados anteriormente proporcionen un proceso unificado y vinculado con criterios complementarios.
En general, DO-178C mantiene la mayor parte del texto de DO-178B, lo que ha generado preocupaciones de que los problemas con DO-178B, como la ambigüedad sobre el concepto de requisitos de bajo nivel, puedan no resolverse por completo. [6]
El trabajo del comité conjunto RTCA/EUROCAE se dividió en siete Subgrupos:
El subgrupo de Verificación y Desarrollo Basado 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 es un mecanismo colaborativo de gestión del trabajo. [7] Los artefactos de trabajo y los borradores de documentos se guardaron en un área restringida disponible únicamente 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 de desarrollo de software actuales. [8] [9]
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 [10] ), 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-178C por sí solo no pretende garantizar los aspectos de seguridad del software. Los atributos de seguridad en el diseño y su implementación como funcionalidad deben recibir tareas obligatorias adicionales de seguridad del sistema para impulsar y mostrar evidencia objetiva de que cumplen con 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 integrales para establecer el nivel de software AE. "El nivel de software establece el rigor necesario para demostrar el cumplimiento" de la DO-178C. [10] Cualquier software que ordene, controle y supervise funciones críticas para la seguridad debe recibir el DAL más alto: Nivel A.
El número de objetivos a cumplir (algunos 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. [11]
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-178C). Los procesos se describen como áreas de trabajo abstractas en DO-178C, 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 de DO-178C 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-178C, 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 del DO-178C 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-178C 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 bajo este estándar y ha creado un nicho de mercado para la capacitación y consultoría del 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 participa en la revisión de un sistema o subsistema según lo definido por EASA en el Memorando de Certificación SWCEH – 002: Directrices de aprobación de SW y FAA. en la Orden 8110.49: Directrices de Aprobación de SW.
DO-178 requiere conexiones bidireccionales documentadas (llamadas 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, mientras que también se rastrea hasta las líneas de código fuente destinadas a implementarlo, los casos de prueba destinados a verificar el exactitud del código fuente con respecto al requisito, los resultados de esas pruebas, etc. Luego se utiliza un análisis de trazabilidad para garantizar que el código fuente cumpla cada requisito, que cada requisito funcional se verifique mediante pruebas, que cada línea de el código fuente tiene un propósito (está conectado a un requisito), etc. El análisis de trazabilidad accede a la integridad del sistema. El rigor y detalle de los artefactos de certificación está relacionado con el nivel de software.
SC-205/WG-12 fue responsable de revisar DO-178B/ED-12B para actualizarlo con respecto al desarrollo de software y tecnologías de verificación actuales. La estructura del documento sigue siendo prácticamente la misma de B a C. Los cambios de ejemplo incluyen: [13]
DO-178B no fue completamente consistente en el uso de los términos Directrices y Orientaciones dentro del texto. Las "orientaciones" transmiten un sentido de obligación ligeramente más fuerte que las "directrices". Como tal, con el DO-178C, el SCWG ha decidido el uso de "orientaciones" para todas las declaraciones que se consideran "recomendaciones", reemplazando las instancias restantes de "directrices" con "información de respaldo" y utilizando esa frase siempre que el texto está más orientado a la "información" que a las "recomendaciones".
Todo el documento DO-248C /ED-94C, Información de respaldo para DO-178C y DO-278A , se incluye en la categoría de "información de respaldo", no de orientación. [18]
El Capítulo 6.1 define el propósito del proceso de verificación del software. DO-178C agrega la siguiente declaración sobre el Código de objeto ejecutable:
A modo de comparación, DO-178B establece lo siguiente con respecto al Código de objeto ejecutable:
La aclaración adicional de la Revisión C llenó un vacío que un desarrollador de software podría haber encontrado al interpretar el documento de la Revisión B. [19]
{{cite web}}: Mantenimiento CS1: nombres numéricos: lista de autores ( enlace )La industria espera que el paquete final —DO-178C— se publique en el primer trimestre de 2011 y entre seis a nueve meses después de su ratificación.
La publicación de estos estándares tan esperados se producirá a mediados de 2011 y serán reconocidos por las autoridades de certificación en 2012.
{{cite web}}: Mantenimiento CS1: copia archivada como título ( enlace )DO-178C contendrá más detalles sobre el modelado de software y la capacidad potencial de utilizar el modelado para reemplazar algunas de las técnicas de verificación normalmente requeridas en DO-178B.
DO-178C también abordará más completamente el software OO (orientado a objetos) y las condiciones bajo las cuales se puede utilizar y las ramificaciones de certificación de OO en DO-178C.