Las normas de certificación de software DO-178B y DO-178C sirven como guía para producir sistemas aéreos dignos de volar. DO-178B (Consideraciones de Software en Sistemas y Equipos Aéreos para Certificación), publicado por primera vez en 1992, fue el documento predominante tenido en cuenta para obtener la certificación de autoridades como EASA (Agencia de Seguridad Aérea de la Unión Europea) y FAA (Administración Federal de Aviación) para sistemas aéreos comerciales basados en software. Sin embargo, en 2013, las Regulaciones Federales de Aviación reconocieron a DO-178C como un método para demostrar la conformidad de aeronavegabilidad. Para obtener más información general sobre las normas DO-178B y DO-178C, [puede leer este artículo].
Los documentos como los siguientes deben cumplir con las normas DO-178B o DO-178C:
- 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)
Estos no son los únicos documentos necesarios para satisfacer las normas DO-178B y DO-178C. Hay un gran número de otros documentos para enriquecer la aeronavegabilidad. Puede verificar y comprar estos documentos aquí.
Documentos DO178
Documento PSAC
El documento PSAC (Plan for Software Aspects of Certification) describe los estándares, procesos, protocolos y metodologías necesarios a seguir, así como también detalla los datos del ciclo de vida. De esta forma, se pueden cumplir los objetivos de los documentos DO-178. PSAC también especifica el cronograma de desarrollo del software y una visión general del sistema. Tanto la autoridad certificadora como el solicitante hacen uso de este documento. PSAC debe producirse en el proceso inicial de planificación del software y ser aprobado por la autoridad. Para consultar nuestro Documento PSAC, por favor haga clic aquí.
Documento SDP
El documento SDP (Software Development Plan) tiene como objetivo verificar si se ha especificado la información necesaria, como los procedimientos de desarrollo de software, protocolos, estándares, ciclos de vida y el entorno de desarrollo. El documento SDP es una parte esencial del período de planificación del software. Para consultar nuestro Documento SDP, por favor haga clic aquí.
Documento SVP
El documento (Software Verification Plan) specifica los casos de prueba necesarios y las coberturas, procedimientos, protocolos, verificación de requisitos, verificación del código fuente con un control de versiones adecuado. SVP también es un elemento clave del proceso de planificación. Para consultar nuestro Documento SVP, por favor haga clic aquí.
Documento SCMP
El documento SCMP (Software Configuration Management Plan) es otro aspecto clave del período de planificación. Durante el proceso de desarrollo del software, a menudo ocurre que el plan inicial cambia. SCMP nos ayuda a detectar, controlar, mantener y rastrear esos cambios. Se aplica a lo largo del proceso de desarrollo del software. SCMP tiene como objetivo minimizar los errores y maximizar la productividad. Los miembros del equipo deben esforzarse en informar y notificar los cambios. Para consultar nuestro Documento SCMP, por favor haga clic aquí.
Documento SQAP
El documento SQAP (Software Quality Assurance Plan) incluye herramientas, métodos y técnicas utilizadas para asegurar que un producto o servicio cumpla con las especificaciones dadas en el SRS (Especificación de Requisitos de Software). 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 uno de ellos. SQA se lleva a cabo a lo largo del ciclo de vida del software. Para consultar nuestro Documento SQAP, por favor haga clic aquí.
Documento SAS
El documento SAS (Software Accomplishment Summary) resume cada paso de los componentes del software durante el desarrollo y la verificación. SAS debe incluir el resumen de los hallazgos de la calificación de las herramientas de verificación. La FAA debe ser notificada del SAS. Eso permite a la autoridad certificadora validar los hallazgos de los datos de verificación y sirve como prueba del estado de calificación de la herramienta. Para consultar nuestro Documento SAS, por favor haga clic aquí.
Normas ARP4754 y Normas DO178
ARP4754 significa «Práctica Recomendada Aeroespacial ARP4754A Guías para el Desarrollo de Aeronaves Civiles y Sistemas». Las Normas ARP4754 proporcionan orientación para sistemas completos de aeronaves, mientras que las Normas DO178 se utilizan para el software de vuelo. Ambas normas son aceptadas por autoridades como la FAA y la EASA.
ARP4754 fue desarrollado y publicado por SAE (Sociedad de Ingenieros Automotrices) en 1996. En 2010, SAE publicó ARP4754A que significa Guías para el Desarrollo de Aeronaves Civiles y Sistemas. ARP4754A amplía la idea de garantía de diseño para su uso en los niveles de aeronave y sistema, así como estandariza el uso de la palabra garantía de desarrollo. ARP4754 fue reconocido por la FAA en noviembre de 2011.
Desde los requisitos hasta la integración y verificación, ARP4754 cubre todo el ciclo de desarrollo de la aeronave. ARP4754 proporciona abstracción para la aeronave, sistema y elemento. Para el diseño del elemento, ARP4754 hace referencia explícita a DO-178 y DO-254. ARP4754 se enfoca en la evaluación de seguridad a lo largo de diferentes procesos como desarrollo, diseño y verificación. No obstante, se debe tener en cuenta que ARP4754 no incluye el alcance específico del desarrollo de software o hardware electrónico, actividades de seguridad en servicio y desarrollo estructural de aeronaves.
Fases de Diseño
Revisión de Diseño Preliminar (PDR)
El diseño preliminar es una fase esencial del proceso de desarrollo de software. Durante el diseño preliminar, se especifican los requisitos de alto nivel y los casos de uso para construir la arquitectura del sistema. Documentos de interfaz, base de datos y arquitectura y diagramas de relaciones de componentes pueden utilizarse en el diseño. El diseño preliminar ofrecerá una representación visual del sistema al inicio del proyecto basado en estas entradas. El diseño preliminar también crea la base para las siguientes fases de diseño más detalladas. Puede verse como un plano.
La Revisión de Diseño Preliminar (PDR) finaliza la fase de diseño preliminar del proyecto. Para avanzar con el diseño detallado, PDR debe ofrecer suficiente seguridad. El propósito del PDR es asegurar que el diseño preliminar y la arquitectura básica del sistema estén completos, que haya confianza técnica de que los requisitos pueden cumplirse dentro del presupuesto y el cronograma.
Revisión de Diseño Crítico (CDR)
La Revisión de Diseño Crítico (CDR) finaliza la fase de diseño crítico del proyecto. Los diseños finales se presentan con CDR a través de análisis exhaustivos, simulaciones, esquemas, código de software y datos de prueba. CDR asegura que el sistema pueda avanzar a las pruebas y producción. También expresa que los requisitos mencionados pueden cumplirse dentro del presupuesto y el cronograma. Los dibujos y especificaciones completos que surgen proporcionan una línea base de producto inicial, con una línea base final. CDR debe ser exhaustivo y completo.
Fase de Diseño Final
La Fase de Diseño Final proporciona dibujos arquitectónicos y de ingeniería detallados de cada componente en el proyecto. Para algunos proyectos, puede ser necesario crear un informe de diseño final. Los problemas de diseño detectados deben resolverse antes de finalizar la fase de diseño final. Los dibujos e informes deben ofrecer suficiente detalle para permitir estimaciones razonablemente precisas de los costos de construcción y operación, así como del tiempo de construcción. El informe de diseño final debe incluir un cronograma actualizado, estimaciones de costos y especificaciones. Además, se debe aprobar que el proyecto sea económicamente factible. Cualquier cambio durante la Fase de Diseño Final es más costoso en comparación con otras fases. Por lo tanto, debe llevarse a cabo con mucha atención.
SOI (Etapas de Participación)
Las evaluaciones de Etapas de Participación (SOI) son realizadas por las autoridades de aviación de los países relevantes en varias etapas del proyecto, como planificación, desarrollo y verificación, para evaluar el cumplimiento de DO-178B de los proyectos. En casos ideales, se planifican un total de cuatro revisiones de SOI.
La evaluación inicial, que es el primer SOI, incluye la fase de planificación de los estudios de cumplimiento de certificación del proyecto. La segunda revisión de SOI se centra en las fases de desarrollo del proyecto. Comenzando con el desarrollo de requisitos de software de alto nivel, cuestiona si el diseño, los requisitos de software de bajo nivel y el código fuente se producen de acuerdo con DO178B. La tercera revisión de SOI se centra en las fases de validación. No solo las actividades de prueba, sino todas las actividades realizadas con fines de verificación son examinadas. El cuarto SOI, por otro lado, es la evaluación final realizada cerca del final del proyecto, cuestionando si hay alguna actividad pendiente y si ha surgido algún problema nuevo desde las evaluaciones anteriores.
La expectativa de DO-178B de los productos de software producidos durante la fase de planificación es acordar un conjunto de reglas común entre la autoridad y la empresa que lo hace y cumplir con este conjunto de reglas a lo largo del proyecto. En otras palabras, al escribir planes y estándares, la empresa no solo determina sus propios procesos sino también escribe las reglas para cómo la autoridad se evaluará a sí misma a lo largo del proceso de certificación.
Can Önal ([email protected])
Mor Teknoloji
