Las normas de certificación de software DO-178B y DO-178C sirven de guía para producir sistemas aéreos aeronavegables. Publicada por primera vez en 1992, la DO-178B (Software Considerations in Airborne Systems and Equipment Certification) fue un documento importante que se tenía en cuenta para obtener la certificación necesaria de autoridades comerciales como la EASA (Agencia de la Unión Europea para la Seguridad Aérea) y la FAA (Administración Federal de Aviación) para los sistemas aéreos basados en software. No obstante, las Regulaciones Federales de Aviación aceptaron en 2013 la DO-178C como método para demostrar la conformidad de aeronavegabilidad. Para obtener información más general sobre las normas DO-178B y DO-178C, puede leer este artículo.
Las normas DO-178B o DO178C deben cumplirse mediante los siguientes documentos de ejemplo, entre otros.
- PSAC (Plan for Software Aspects of Certification)
- SDP (Software Development Plan)
- SVP (Software Verification Plan)
- SCMP (Software Configuration Management Plan)
- SQAP (Software Quality Assurance Plan)
- SAS (Software Accomplishment Summary)
Los documentos necesarios para cumplir las normas DO-178B y DO-178C no se limitan a estos. Existen muchos otros documentos que enriquecerán la aeronavegabilidad. Puede consultar y adquirir estos documentos aquí.
Documentos DO178
Documento PSAC
El documento PSAC (Plan for Software Aspects of Certification), además de producir los datos del ciclo de vida, explica las normas, los procesos, los protocolos y las metodologías necesarios que deben seguirse. De este modo, pueden cumplirse las normas DO-178. El PSAC también especifica el calendario de desarrollo del software y el estado general del sistema. Tanto la autoridad aprobadora como el solicitante se benefician de este documento. El PSAC debe elaborarse durante el proceso inicial de planificación del software y ser aprobado por la autoridad de certificación. Haga clic aquí para consultar nuestro documento PSAC.
Documento SDP
El documento SDP (Software Development Plan) tiene como objetivo comprobar si se ha determinado la información necesaria, como los procedimientos de desarrollo, los protocolos, las normas, los ciclos de vida y el entorno de desarrollo. El documento SDP es una parte importante del proceso de planificación del software. Haga clic aquí para consultar nuestro documento SDP.
Documento SVP
El documento SVP (Software Verification Plan) especifica los escenarios de prueba y la cobertura necesarios, los procedimientos, los protocolos, la verificación de requisitos y la verificación del código fuente, al tiempo que proporciona un control de versiones adecuado. El SVP también es una parte importante del proceso de planificación. Haga clic aquí para consultar nuestro documento SVP.
Documento SCMP
El documento SCMP (Software Configuration Management Plan) es otro elemento importante del proceso de planificación. El plan inicial elaborado a lo largo del proceso de desarrollo de software suele sufrir cambios. El SCMP nos ayuda a detectar, controlar, mantener y hacer seguimiento de estos cambios. Se aplica durante todo el proceso de desarrollo del software. El SCMP tiene como objetivo minimizar los errores y maximizar la eficiencia. Los miembros del equipo deben esforzarse por comunicarse y notificarse mutuamente los cambios. Haga clic aquí para consultar nuestro documento SCMP.
Documento SQAP
El documento SQAP (Software Quality Assurance Plan) contiene las herramientas, los métodos y las técnicas utilizados para garantizar que un producto o servicio cumpla las especificaciones dadas en el SRS (Software Requirement Specification). El SQAP explica cómo se llevarán a cabo las actividades de aseguramiento de la calidad del software en el proyecto. El equipo de SQA establece hitos y evalúa la calidad del proyecto en cada hito. El SQA se lleva a cabo durante todo el ciclo de vida del software. Haga clic aquí para consultar nuestro documento SQAP
Documento SAS
El SAS (Software Accomplishment Summary) resume cada paso de los componentes de software durante los procesos de desarrollo y verificación. El SAS debe incluir un resumen de los hallazgos de la calificación de las herramientas de verificación. La FAA debe ser informada sobre el SAS. Esto proporciona a la autoridad de certificación la validación de los hallazgos de los datos de verificación y sirve como evidencia del estado de calificación de la herramienta. Haga clic aquí para consultar nuestro documento SAS
Normas ARP4754 y normas DO178
ARP4754 corresponde a «Aerospace Recommended Practice ARP4754A Guidelines for Development of Civil Aircraft and Systems». Las normas ARP4754 proporcionan orientación para los sistemas de aeronaves en su conjunto, mientras que las normas DO178 se utilizan únicamente para el software de vuelo. Ambas normas son aceptadas por autoridades como la FAA y la EASA.
ARP4754 fue desarrollada y publicada por la SAE (Society of Automotive Engineers) en 1996. En 2010, la SAE publicó la ARP4754A, que corresponde a Guidelines for Development of Civil Aircraft and Systems. La ARP4754A enriquece la idea de garantía de diseño utilizada a nivel de aeronave y de sistema, y también estandariza el uso del término garantía de desarrollo. La ARP4754 fue aprobada por la FAA en noviembre de 2011.
ARP4754 cubre todo el ciclo de desarrollo de la aeronave, desde la identificación de los requisitos hasta el final de los procesos de integración y verificación. La ARP4754 proporciona abstracción para aeronaves, sistemas y componentes. Para el diseño de componentes, la ARP4754 remite explícitamente a la DO-178 y la DO-254. La ARP4754 se centra en la evaluación de la seguridad a través de distintos procesos, como el desarrollo, el diseño y la verificación. No obstante, cabe señalar que la ARP4754 no incluye el alcance específico del desarrollo de software o de hardware electrónico, las actividades de seguridad en servicio ni el proceso de desarrollo estructural de la aeronave.
Fases de diseño
Revisión Preliminar de Diseño (PDR)
El diseño preliminar es una fase importante del proceso de desarrollo de software. Durante el diseño preliminar, se identifican los requisitos de alto nivel y los casos de uso para formar la arquitectura del sistema. En el diseño pueden utilizarse documentos de interfaz, base de datos y arquitectura, así como diagramas de relaciones entre componentes. El diseño preliminar proporcionará una representación visual del sistema al inicio del proyecto basada en estas entradas. El diseño preliminar también sienta las bases de las fases de diseño más detalladas posteriores. Puede considerarse un borrador.
La Revisión Preliminar de Diseño (PDR) concluye la fase de diseño preliminar del proyecto. La PDR debe proporcionar garantías suficientes para proceder con el diseño detallado. El propósito de la PDR es asegurar que el diseño preliminar y la arquitectura básica del sistema estén completos, y que exista confianza técnica en que los requisitos pueden cumplirse dentro del presupuesto y el calendario.
Revisión Crítica de Diseño (CDR)
La Revisión Crítica de Diseño (CDR) concluye la fase de diseño crítico del proyecto. Los diseños finales se presentan en la CDR mediante análisis exhaustivos, simulaciones, esquemas, código de software y datos de prueba. La CDR garantiza que el sistema pueda avanzar hacia las pruebas y la producción. También establece que los requisitos en cuestión pueden cumplirse dentro del presupuesto y el calendario. Los planos y especificaciones completos resultantes proporcionan una línea base final junto con una línea base inicial del producto. La CDR debe ser amplia en alcance y detallada.
Fase de diseño final
La fase de diseño final proporciona planos arquitectónicos y de ingeniería detallados de cada componente del proyecto. Para algunos proyectos, puede ser necesario elaborar un informe de diseño final. Los problemas de diseño identificados deben resolverse antes de completar la fase de diseño final. Los planos y los informes deben proporcionar suficiente detalle para permitir estimaciones planificadas. El informe de diseño final debe incluir un cronograma actualizado, estimaciones de costes y especificaciones. También debe confirmarse que el proyecto es económicamente viable. Cualquier cambio realizado durante la fase de diseño final es más costoso en comparación con otras fases. Por lo tanto, deben llevarse a cabo con mucho cuidado.
SOI (Stages of Involvement)
Para evaluar la conformidad de los proyectos con la DO-178B, las autoridades de aviación de los países correspondientes realizan evaluaciones SOI en diversas etapas del proyecto, como la planificación, el desarrollo y la verificación. Idealmente, se planifican un total de cuatro revisiones SOI.
La primera evaluación SOI cubre la fase de planificación del trabajo de conformidad de certificación del proyecto. La segunda revisión SOI se centra en las fases de desarrollo del proyecto. Comenzando por el desarrollo de los requisitos de software de alto nivel, cuestiona si el diseño, los requisitos de software de bajo nivel y el código fuente se han producido conforme a la DO178B. La tercera revisión SOI se centra en las fases de verificación. Se revisan no solo las actividades de prueba, sino todas las actividades realizadas con fines de verificación. La cuarta SOI es la evaluación de cierre realizada hacia el final del proyecto, en la que se cuestiona si quedan actividades pendientes y si han surgido nuevos problemas desde las evaluaciones anteriores.
Lo que la DO-178B espera de los productos de software elaborados en la fase de planificación es acordar un conjunto común de reglas entre la autoridad y la empresa que lo ejecuta, y adherirse a este conjunto de reglas durante todo el proyecto. En otras palabras, al redactar los planes y las normas, la empresa no solo determina sus propios procesos, sino que también escribe las reglas sobre cómo la autoridad la evaluará a lo largo del proceso de certificación.
Autor: Can Önal ([email protected])
