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 un esfuerzo conjunto con EUROC y reemplaza al 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 el uso en enero de 2012. [1] [2] [3]
A excepción de la FAR 33 / JAR E, las Regulaciones Federales de Aviación no hacen referencia directa a la aeronavegabilidad del software. [4] El 19 de julio de 2013, la FAA aprobó la AC 20-115C , designando a DO-178C como un "medio aceptable reconocido, pero no el único medio, para demostrar el cumplimiento de las regulaciones de aeronavegabilidad FAR aplicables para los aspectos de software de los sistemas y equipos de a bordo". [5]
Desde la publicación de la DO-178B , los representantes de ingeniería designados (DER) de la FAA han pedido enérgicamente que se aclaren o refinen las definiciones y los límites entre los conceptos clave de la DO-178B de requisitos de alto nivel, requisitos de bajo nivel y requisitos derivados, y que se definan mejor los criterios de entrada y salida entre los requisitos de los sistemas y el diseño del sistema (véase ARP4754 ) y los de los requisitos de software y el diseño de software (que es el dominio de la 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 la DO-178C y los documentos complementarios DO-278A (Sistemas de tierra), DO-248C (Información adicional con fundamentos para cada objetivo de la 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 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, la DO-178C conserva la mayor parte del texto de la DO-178B, lo que ha suscitado inquietudes de que los problemas con la DO-178B, como la ambigüedad sobre el concepto de requisitos de bajo nivel, podrían no resolverse por completo. [6]
El trabajo del comité conjunto RTCA/EUROCAE se dividió en siete subgrupos:
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 es un mecanismo de gestión del trabajo colaborativo. [7] Los artefactos de trabajo y los documentos borrador se guardaron en un área restringida disponible solo para los miembros del grupo.
El trabajo se centró en actualizar el 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 desarrollo (DAL) o nivel de garantía de desarrollo de ítem (IDAL) según se define en ARP4754A (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 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 DO-178C por sí sola 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 de que se cumplen los requisitos de seguridad explícitos. Las autoridades de certificación requieren y la DO-178C especifica que se establezca el DAL correcto utilizando estos métodos de análisis integrales para establecer el AE de nivel de software. "El nivel de software establece el rigor necesario para demostrar el cumplimiento" con la DO-178C. [10] Cualquier software que ordene, controle y monitoree funciones críticas para la seguridad debe recibir el DAL más alto: Nivel A.
El número de objetivos que se deben satisfacer (algunos 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. [11]
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-178C). Los procesos se describen como áreas abstractas de trabajo en DO-178C, 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-178C 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-178C, 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-178C 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-178C 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-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 en la revisión de un sistema o subsistema según lo define EASA en el Memorando de Certificación SWCEH – 002: Directrices de Aprobación de SW y la FAA en la Orden 8110.49: Directrices de Aprobación de SW.
La DO-178 requiere conexiones bidireccionales documentadas (denominadas trazas) entre los artefactos de certificación. Por ejemplo, se traza un Requisito de Bajo Nivel (LLR) hasta un Requisito de Alto Nivel (HLR) que se pretende satisfacer, mientras que también se traza 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 esas pruebas, etc. Luego se utiliza un análisis de trazabilidad para garantizar que cada requisito se cumpla con el código fuente, que cada requisito funcional se verifique mediante una prueba, que cada línea de código fuente tenga un propósito (esté conectada con un requisito), etc. El análisis de trazabilidad accede a la integridad 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 sigue siendo en gran medida la misma de B a C. Algunos ejemplos de cambios incluyen: [13]
La DO-178B no fue completamente coherente en el uso de los términos "Directrices" y "Orientación" dentro del texto. "Orientación" transmite un sentido de obligación ligeramente más fuerte que "directrices". Por ello, con la DO-178C, el SCWG ha decidido utilizar "orientación" para todas las declaraciones que se consideran "recomendaciones", reemplazando las instancias restantes de "directrices" por "información complementaria" y utilizando esa frase dondequiera que el texto esté más orientado a la "información" que a la "recomendación".
Todo el documento DO-248C /ED-94C, Información complementaria para DO-178C y DO-278A , cae dentro de la categoría de "información complementaria", no de orientación. [18]
El capítulo 6.1 define el propósito del proceso de verificación de 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}}: CS1 maint: nombres numéricos: lista de autores ( enlace )La industria espera que el paquete final —DO-178C— se lance en el primer trimestre de 2011 y que se expida entre seis y nueve meses después de la ratificación.
La publicación de estas normas, que se esperaba desde hace tiempo, se producirá a mediados de 2011 y serán reconocidas por las autoridades de certificación en 2012.
{{cite web}}: CS1 maint: 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.