Cumplimiento de software DO-178C para la industria aeroespacial y de defensa

La norma DO-178C del Comité Técnico de Radio para Aeronáutica (RTCA) es una norma de seguridad funcional que proporciona orientación y consideraciones para la producción de software para sistemas y equipos a bordo. El objetivo es garantizar que el sistema realice su función prevista con un nivel de confianza en la seguridad que cumpla con los requisitos de aeronavegabilidad. Si una aeronave va a volar sobre el espacio aéreo comercial de los EE. UU., se requiere el cumplimiento de la norma.

DO-178C Proporciona la siguiente orientación:

• Objetivos de los procesos del ciclo de vida del software
• Actividades que proporcionan un medio para satisfacer esos objetivos
• Descripciones de la evidencia en forma de datos del ciclo de vida del software que indican que se han cumplido los objetivos
• Variaciones en los objetivos, independencia, datos del ciclo de vida del software y categorías de control por nivel de software
• Consideraciones adicionales (por ejemplo, software desarrollado previamente) que son aplicables a ciertas aplicaciones
• Definición de términos proporcionados en el glosario

La DO-178C cubre todo el ciclo de vida de la ingeniería, desde la planificación, el desarrollo, la verificación, el control de calidad, la coordinación y la certificación. Se subdivide en 12 secciones. La sección 1, que no se muestra, expresa el propósito, el alcance y cómo utilizar el documento.

RTCA se fundó en 1935. Es una organización independiente de desarrollo de normas y sirve como base para la certificación gubernamental de los equipos utilizados por las decenas de miles de aeronaves que vuelan diariamente por el espacio aéreo mundial.

RTCA es una corporación privada sin fines de lucro que trabaja en estrecha colaboración con la Administración Federal de Aviación (FAA) y con expertos de la industria de los EE. UU. y de todo el mundo, como el grupo de trabajo de la Organización Europea para Equipos de Aviación Civil (EUROCAE), para ayudar a desarrollar esta norma de aviación integral y contemporánea. La EUROCAE es una organización sin fines de lucro cuyo objetivo es desarrollar normas para la aviación civil europea.

El estándar DO-178 original se publicó en 1982. Sin embargo, no se consideró útil. Como resultado, se publicó la revisión DO-178A en 1985. Esta revisión se centró más en los principios de ingeniería de software y las prácticas de verificación modernas. Introdujo una correlación entre las condiciones de falla críticas con los niveles 1, 2 y 3. El nivel 1, que quizás conozca mejor como Nivel de Garantía de Desarrollo (DAL), era el más estricto.

En diciembre de 1992, revisión DO-178B Se publicó el documento de certificación de software, que pasó de ser un documento de tipo "cómo hacer" a un documento de tipo "qué hacer". Se puso un gran énfasis en los objetivos que su proceso de software debe satisfacer para alcanzar la conformidad y, en última instancia, la certificación.

Otro cambio notable fue el número de posibles condiciones de falla crítica definidas en DAL. Se ampliaron a cinco niveles de software y cambiaron de números a letras de la A a la E. El nivel A era el más estricto y el nivel E significaba que no había requisitos de seguridad. Además, se hizo mucho hincapié en probar los requisitos. Se recomendó no mirar el código para crear casos de prueba, sino mirar los requisitos. Se respaldó con una cobertura de código estructural para garantizar que se cubriera todo.

La DO-178B también incorporó trazabilidad bidireccional entre sistemas, requisitos de alto y bajo nivel, incluidos casos de prueba, y hasta el código para demostrar que se han implementado todos los requisitos. Se introdujo la idea de tener herramientas calificadas para su uso.

Hoy estamos en la revisión C. Publicada en enero de 2012, la DO-178C eliminó la redacción imprecisa que se encontraba en la DO-178B para mayor claridad. También se convirtió en un esfuerzo conjunto entre RTCA y EUROCAE. Pero la principal diferencia entre la DO-178B y la DO-178C es la adopción de un enfoque modular para los documentos de orientación complementarios. Ahora tiene normas complementarias, incluidas las siguientes.

Esta guía proporciona una descripción general condensada de cada una de las secciones del DO-178C, destacando los puntos clave.

Aspectos del sistema relacionados con el desarrollo de software, Sección 2

La sección 2 analiza los procesos del ciclo de vida del sistema, los artefactos producidos, cómo fluyen hacia el ciclo de vida del software y el flujo de información entre estos procesos. Una gran parte de esto es el análisis de requisitos, donde los requisitos del sistema de software se desarrollan inicialmente a partir de los requisitos operativos del sistema o los requisitos del cliente, y cómo estos artefactos fluyen hacia el ciclo de vida del software.

En el ciclo de vida del software, continúa la descomposición de requisitos, se lleva a cabo la verificación del software y, finalmente, la certificación.

Aunque DO-178C captura el flujo entre los ciclos de vida del sistema y del software en el diagrama anterior, el tema está bien definido en el Norma SAE ARP4754A, Directrices para el desarrollo de aeronaves y sistemas civiles.

La sección 2 aborda los siguientes temas:

• Asignación de requisitos del sistema al software
• Flujo de información entre los procesos del ciclo de vida del sistema y del software y entre los procesos del ciclo de vida del software y del hardware
• Proceso de evaluación de la seguridad del sistema, condiciones de falla, definiciones de nivel de software y determinación del nivel de software » Consideraciones arquitectónicas
• Consideraciones arquitectónicas
• Consideraciones de software en los procesos del ciclo de vida del sistema
• Consideraciones del sistema en los procesos del ciclo de vida del software

Otra parte importante de la sección 2 es la determinación de la clasificación de nivel de software o DAL. Los resultados catastróficos equivalen a un fallo del software de control de vuelo que provocaría la caída de un avión y la pérdida de muchas vidas. Esto se clasificaría como nivel de software A.

Peligroso es un nivel inferior, por lo que las lesiones graves o fatales a un número relativamente pequeño de ocupantes que no sean la tripulación de vuelo serían de nivel de software B. La clasificación continúa bajando al nivel de software E, donde no hay ningún problema de seguridad si ocurriera una falla.

Otra perspectiva o aspecto de esta clasificación es el control de calidad. Con cada nivel que se aumenta, del nivel E al nivel A, hay un mayor número de objetivos que deben cumplirse. Por ejemplo, hay un aumento en la trazabilidad entre los artefactos producidos durante el desarrollo del producto. Además, hay un aumento en las pruebas de software. Es posible que el software deba satisfacer la cobertura de código de objeto o de ensamblaje en lugar de solo la cobertura de declaraciones, ramas y MC/DC.

Para compartir una práctica recomendada, si su software está clasificado en el nivel B o inferior, es posible que desee intentar lograr algunos o todos los objetivos del nivel de software inmediatamente superior. El esfuerzo adicional entre algunos de los niveles de garantía de desarrollo puede no ser demasiado sustancial y los beneficios podrían muy bien dar sus frutos si los requisitos del cliente se vuelven más estrictos.

A continuación se muestra el conocido modelo V. El lado derecho captura las fases de diseño del sistema y del software, mientras que el lado izquierdo captura las fases de verificación. La norma ARP4754 es el documento de referencia para el desarrollo de sistemas de aeronaves, teniendo en cuenta el entorno operativo y las funciones generales de la aeronave. Esto incluye la validación de los requisitos y la verificación de la implementación del diseño para la certificación y la garantía del producto.

Ciclo de vida del software, sección 3

La Sección 3 analiza los aspectos del proceso del ciclo de vida del software. La secuencia conocida a través del SDLC es la gestión de requisitos, el diseño, la codificación y la integración. DO-178C no recomienda ningún proceso de desarrollo. Las organizaciones deben tomar esa decisión en función de su propia experiencia y de factores como la tecnología actual, como Agile, DevSecOps, CI/CD o los requisitos del cliente. Cualquiera sea el proceso que elija, los objetivos de la norma que se deben cumplir no se ven obstaculizados por el proceso.

Los procesos del ciclo de vida del software DO-178C incluyen lo siguiente:

• Proceso de planificación de software. Define y coordina las actividades de desarrollo de software y los procesos integrales de un proyecto.
• Procesos de desarrollo de software. Producir el producto de software. Este proceso se compone de procesos de requisitos, diseño, codificación e integración.
• Procesos integrales de software. Garantizar la corrección, el control y la confianza en los procesos del ciclo de vida del software y sus resultados. Estos incluyen la verificación, la gestión de la configuración, el control de calidad y la coordinación de la certificación.

Proceso de planificación de software, sección 4

La Sección 4 analiza los objetivos y las actividades del proceso de planificación del software. Los objetivos están claramente definidos y plasmados en la Tabla A-1 de la norma. Hay siete objetivos que deben cumplirse en función del nivel de software (AD). Estos objetivos incluyen la definición de lo siguiente:

• Proceso del ciclo de vida del software
• Interrelaciones entre procesos
• Métodos y herramientas a utilizar
• Normas de desarrollo que se utilizarán para garantizar la seguridad
• Verificación de que el software satisface los requisitos de desarrollo
• Verificación de que las organizaciones que realizarán esas actividades

También hay muchas consideraciones en el proceso de planificación del software, como la intención de utilizar software desarrollado previamente o software comercial listo para usar (COTS), la calificación de herramientas y muchas más descritas en la sección 12.

La Tabla A-1 de la norma captura los objetivos, los niveles de software que aplican y el resultado esperado de estas actividades, que son un conjunto de documentos con información de reporte sobre la organización, el estándar de la industria, el desarrollo de software, las herramientas, los resultados de la verificación y la certificación.

Proceso de desarrollo de software, sección 5

El proceso de desarrollo de software se aplica según lo definido por el proceso de planificación de software y el plan de desarrollo de software. Ya sea que los equipos u organizaciones elijan una metodología de desarrollo de software como DevOps, Spiral, Waterfall u otra, se deben llevar a cabo los cuatro procesos enumerados a continuación.

1. Proceso de requisitos de software
2. Proceso de diseño de software
3. Proceso de codificación de software
4. Proceso de integración

El proceso de requisitos de software comienza con la recopilación de todos los requisitos de las partes interesadas, los organismos reguladores, las normas y otros. Estos requisitos se organizan en dominios como hardware, software, mecánico, químico, eléctrico, etc., y luego se convierten en los requisitos a nivel de sistema.

Los requisitos de alto nivel se derivan de los requisitos de sistema de nivel superior. Descomponen un requisito de sistema en varios requisitos funcionales y no funcionales de alto nivel. Esta fase de la descomposición de requisitos ayuda en el diseño arquitectónico del sistema en desarrollo.

Los requisitos de alto nivel aclaran y ayudan a definir el comportamiento esperado, así como las tolerancias de seguridad, las expectativas de seguridad, la confiabilidad, el rendimiento, la portabilidad, la disponibilidad, la escalabilidad y más. Cada requisito de alto nivel se vincula con el requisito del sistema que satisface. Además, se crean casos de prueba de alto nivel y se vinculan con cada requisito de alto nivel con el fin de verificarlo y validarlo. Esto es parte del proceso de diseño de software, ya que cada requisito de alto nivel se descompone a su vez en requisitos de bajo nivel.

Los requisitos de bajo nivel son requisitos de software derivados de requisitos de alto nivel. Además, descomponen y refinan las especificaciones del comportamiento y la calidad del servicio del software. Luego, profundizan en otro nivel de abstracción y lo asignan a unidades de software individuales. El proceso de codificación comienza cuando se escriben unidades de código para facilitar el diseño detallado y la implementación del software. Las entradas al proceso de codificación son los requisitos de bajo nivel y la arquitectura del software del proceso de diseño del software, el plan de desarrollo del software y los estándares del código del software.

Una vez finalizado el proceso de codificación, el proceso de integración consta de lo siguiente:

Es necesario identificar y corregir los defectos de codificación. Las entradas inadecuadas o incorrectas detectadas durante el proceso de integración se deben proporcionar a los siguientes procesos de software como retroalimentación para su aclaración o corrección:

• Requisitos
• Diseño
• Codificación
• Planificación

La trazabilidad bidireccional que se establece desde cada requisito de bajo nivel hasta su requisito de alto nivel y hasta las pruebas de bajo nivel o casos de pruebas unitarias que lo verifican y validan ayuda en este esfuerzo.

Nivel d

La trazabilidad es crucial para DO-178C. La profundidad de la trazabilidad varía según el nivel de software. Si analizamos la trazabilidad que se requiere para el nivel D de DO-178C, las organizaciones no necesitan preocuparse por cómo se desarrolló el software y, por lo tanto, no es necesario tener ninguna trazabilidad hasta los requisitos de bajo nivel, el código fuente o la arquitectura del software. Los equipos solo necesitan rastrear desde los requisitos del software del sistema hasta los requisitos de alto nivel y luego hasta los casos de prueba, los procedimientos de prueba y los resultados de las pruebas.

Nivel C y B

En los niveles B y C, la forma en que se desarrolló el código fuente cobra importancia. Los equipos deben ampliar la trazabilidad agregando vínculos bidireccionales desde los requisitos de alto nivel a los de bajo nivel y al código fuente.

Nivel A

En el caso de los proyectos de nivel A, los requisitos son ampliar la trazabilidad no solo hasta el código fuente, sino también hasta el código ensamblador/objeto. Esto se debe a que se sabe que los compiladores amplían y traducen lenguajes de nivel superior a código ensamblador que no se corresponde con el código original.

Parasoft cuenta con una solución de cobertura de código ensamblador denominada ASMTools que automatiza la cobertura de código a nivel de lenguaje ensamblador. La automatización de esta tarea alivia mucho el trabajo si se requiere cobertura de código a nivel de ensamblador.

Para la trazabilidad de los requisitos, Parasoft automatiza la vinculación entre los requisitos, los casos de prueba y el archivo fuente, si es necesario. Existen integraciones con herramientas ALM como Jama, Codebeamer y Polarion para ayudar a lograr esta trazabilidad bidireccional y crear una matriz de trazabilidad para los requisitos de verificación.

Proceso de verificación del software, sección 6

El objetivo del proceso de verificación de software es detectar, informar y eliminar los errores que puedan haberse introducido durante el proceso de desarrollo del software. La norma utiliza el término “verificación” en lugar de “prueba” porque las pruebas por sí solas no pueden demostrar la ausencia de errores. La verificación es una combinación de revisiones, análisis, casos de prueba y procedimientos de prueba.

Las pruebas proporcionan consistencia interna y la integridad de los requisitos, mientras que las ejecuciones de pruebas proporcionan una demostración del cumplimiento de los requisitos.

Proceso de verificación del software DO-178C permite lo siguiente:

• Los requisitos del sistema asignados al software se descompondrán en requisitos de alto nivel que satisfagan los requisitos del sistema.
• Los requisitos de alto nivel se desarrollarán en la arquitectura del software y los requisitos de bajo nivel que satisfagan los requisitos de alto nivel.
• Si uno o más niveles de requisitos de software se descomponen en requisitos de alto y bajo nivel, cada nivel sucesivamente inferior satisface sus requisitos de nivel superior. Si el código se genera directamente a partir de los requisitos de alto nivel, esto no se aplica.
• La arquitectura del software y los requisitos de bajo nivel se desarrollarán en un código fuente que satisfaga los requisitos de bajo nivel y la arquitectura del software.
• El código del objeto ejecutable debe satisfacer los requisitos del software y brindar confianza en el cumplimiento de su funcionalidad prevista.
• El código del objeto ejecutable deberá ser robusto y responder correctamente a entradas y condiciones anormales.
  Los medios utilizados para realizar la verificación sean técnicamente correctos y completos para cada nivel de software determinado.
• Los medios utilizados para realizar la verificación sean técnicamente correctos y completos para cada nivel de software determinado.

Las pruebas de software demuestran o “validan” que el software satisface sus requisitos y revelan con un alto grado de confianza que se han eliminado los errores que podrían conducir a condiciones de falla inaceptables, según lo determinado por el proceso de evaluación de seguridad y protección del sistema. El siguiente diagrama muestra las actividades de prueba de software con subsecciones.

Para detallar más cada actividad de prueba, la norma proporciona un conjunto de tablas con objetivos bien definidos y resultados o artefactos necesarios para demostrar el cumplimiento. Estos objetivos se logran mediante pruebas de software y pueden incluir lo siguiente:

• Realizar análisis estático
• Prueba unitaria
• Pruebas de integración
• Prueba del sistema
• Hardware en el objetivo
• Acoplamiento de datos y control
• Cobertura del código estructural (declaración, ramal, MC/DC, ensamblaje)

La integración de hardware y software es crucial para garantizar la seguridad, protección y confiabilidad.

Tenga en cuenta que todos estos métodos de prueba están automatizados por el conjunto de herramientas de Parasoft. Puede obtener una idea de nuestra solución C/C++ haciendo clic en Visita guiada a Parasoft C/C++test.

Las siguientes tablas enumeran el conjunto de objetivos y resultados esperados en función de cada nivel de garantía del diseño del software para garantizar la aeronavegabilidad.

Proceso de gestión de configuración de software, sección 7

La sección 7 analiza los objetivos y las actividades del proceso de gestión de configuración de software. Es necesario poder definir y controlar las configuraciones del software durante todo el ciclo de vida del software. Las organizaciones o los equipos deben tener líneas de base de origen, control de versiones, control de cambios, revisión de cambios, protección contra cambios no autorizados, informes de problemas y mucho más.

Estas son las actividades del proceso de gestión de la configuración del software:

1. Identificación de configuración
2. Líneas base y trazabilidad
3. Informe de problemas, seguimiento y acciones correctivas
4. Cambio de control
5. Cambiar revisión
6. Contabilidad del estado de configuración
7. Archivar, recuperar y publicar

Estas actividades se detallan con más detalle en forma de objetivos y sus resultados. Los objetivos incluyen la capacidad de controlar los cambios en las características de los artículos, registrar e informar sobre el procesamiento del control de cambios y el estado de la implementación.

En la Tabla A-8, observe la columna “Categoría de control por nivel de software”. La DO-178C especifica qué elementos deben tratarse como Categoría de control 1 o 2 según la DAL del proyecto. Los elementos tratados como Categoría de control 1 (CC1) deben someterse a procesos completos de informe de problemas, revisión formal de cambios y procesos de lanzamiento. Los elementos CC2 no necesitan someterse a estos procesos más formales, pero deben cumplir con las necesidades de identificación y trazabilidad de la configuración, estar protegidos contra cambios no autorizados y satisfacer los requisitos de retención de datos aplicables. El mapa entre los datos CC1 y CC2 se encuentra en la siguiente tabla.

Proceso de garantía de calidad del software, sección 8

El proceso de SQA se plasma en el Plan de Garantía de Calidad del Software, que se elabora durante el proceso de planificación del software. Los resultados de las actividades del proceso de SQA deben registrarse, evaluarse y rastrearse. Es necesario realizar auditorías y resolver cualquier desviación de los estándares. El proceso implica garantizar que:

• Se desarrollan planes y estándares de software, se revisan y cumplen con el cumplimiento.
• Los artefactos, informes y evidencias están disponibles con las aprobaciones.
• Los datos del producto de software y del ciclo de vida del software cumplen con los requisitos de certificación.

Proceso de enlace de certificación, sección 9

La Sección 9 analiza el proceso de enlace de certificación y sus objetivos, que incluyen lo siguiente:

• Establecer comunicación y entendimiento entre el solicitante y la autoridad de certificación durante todo el ciclo de vida del software para ayudar en el proceso de certificación.
• Obtener un acuerdo sobre los medios de cumplimiento a través de la aprobación del Plan de Aspectos de Software de la Certificación.
• Proporcionar justificación del cumplimiento.

Su organización deberá elaborar el Plan de aspectos de software de la certificación (PSAC), que incluirá el proceso de enlace de certificación. El PSAC incluirá planes para resolver los problemas identificados por el enlace de certificación y obtener un acuerdo sobre el plan. La siguiente tabla enumera el conjunto de objetivos y los resultados esperados.

Las mejores prácticas para obtener la certificación se reducen a trabajar en estrecha colaboración con su enlace de certificación, que puede ser mejor conocido como su Representante de ingeniería designado (DER), para evaluar el cumplimiento, actuar en su nombre para obtener la aprobación y recomendar que la FAA apruebe su certificación.

Descripción general del proceso de certificación, Sección 10

La Sección 10 es sólo para fines informativos sobre el proceso de certificación.

Se mencionan los tipos de sistemas y equipos a los que se aplica la certificación. Se especifica que las autoridades de certificación no certifican el software como un producto único e independiente, sino que debe ser parte del sistema o equipo a bordo.

“La certificación se aplica a aeronaves, motores o hélices y, en el caso de algunas autoridades de certificación, a unidades de potencia auxiliares. Las autoridades de certificación consideran el software como parte del sistema o equipo de a bordo instalado en el producto certificado; es decir, las autoridades de certificación no certifican el software como un producto único e independiente”.

La aprobación también depende de una demostración o revisión exitosa de los productos producidos.

Datos del ciclo de vida del software, sección 11

La sección 11 analiza artefactos como los datos y la documentación producidos durante el ciclo de vida del software. Los datos deben ser inequívocos, completos, verificables, consistentes, modificables y rastreables. También deben estar en varios formatos, como electrónicos e impresos. El panel web de análisis y generación de informes automatizados de Parasoft proporciona gran parte de la información necesaria dentro de varios artefactos y documentos.

Los artefactos que se deben producir durante el ciclo de vida del software incluyen el código fuente, el código objeto, los casos de prueba, los resultados, los informes de problemas y, por supuesto, los planes. Aquí está la lista completa.

• Plan para los aspectos de software de la certificación
• Código de objeto ejecutable
• Plan de desarrollo de software
• Casos y procedimientos de verificación de software
• Plan de verificación de software
• Resultados de la verificación del software
• Plan de gestión de configuración de software
• Índice de configuración del entorno del ciclo de vida del software
• Plan de garantía de calidad del software
• Normas de requisitos de software
• Índice de configuración del software
• Estándares de diseño de software
• Informes de problemas
• Estándares de código de software
• Registros de gestión de configuración de software
• Datos de requisitos de software
• Registros de garantía de calidad del software
• Descripción del diseño
• Resumen de logros del software
• Código fuente
• Trazar datos
• Archivo de elementos de datos de parámetros

Consideraciones adicionales, Sección 12

La Sección 12 proporciona orientación y consideraciones adicionales sobre temas que pueden tener un impacto en los objetivos y las actividades del ciclo de vida del software. Por ejemplo, el uso o las modificaciones del software desarrollado previamente. La Sección 12 proporciona aclaraciones adicionales y actividades a realizar que ayudan a garantizar la seguridad y la recertificación. Estas son solo algunas otras consideraciones:

Con base en esta consideración, la sección 12 proporciona objetivos adicionales en gestión de configuración de software, garantía de calidad de software, calificación de herramientas de desarrollo y más.

La sección 12 aborda la importancia de la “calificación de herramientas” y la determinación de su necesidad. Esto se debe a que, si se utiliza una herramienta que elimina, reduce o automatiza procesos, los equipos deben tener en cuenta si la herramienta podría introducir errores en el ciclo de vida.

Para determinar el impacto de la herramienta se deben utilizar los siguientes criterios:

Existen cinco niveles de calificación de herramientas, del TQL-1 al TQL-5, que se determinan en función del uso de la herramienta y su posible impacto en el ciclo de vida del software. El TQL-1 es el nivel más riguroso. El nivel de calificación de la herramienta debe coordinarse con la autoridad de certificación.

Los objetivos, actividades, orientación y datos del ciclo de vida necesarios para cada nivel de calificación de herramientas se describen en DO-330, “Consideraciones de calificación de herramientas de software”.

Parasoft admite los procesos de calificación de herramientas conformes con DO-178C y DO-330 con un kit de calificación de herramientas automatizado. El kit de calificación de herramientas automatiza el proceso de creación de la documentación de respaldo necesaria para utilizar C/C++test para análisis estáticos, pruebas unitarias y requisitos de cobertura.

Kit de calificación de herramientas de Parasoft Reduce el tiempo necesario para realizar la calificación de la herramienta y la posibilidad de error humano al aprovechar la automatización para guiar a los usuarios a través del siguiente flujo de trabajo:

1. Especifique los casos de uso y las capacidades que se utilizarán en el proyecto.
2. Asigne rápidamente problemas conocidos en la herramienta que está calificando a las características de la herramienta que está utilizando en el desarrollo.
3. Planifique y capture los resultados de los esfuerzos de pruebas manuales.
4. Ejecutar pruebas automatizadas.
5. Reúna todos los datos y genere los documentos críticos.