Si DO-178C explica cómo se desarrolla el software de una aeronave, la pregunta anterior es de dónde salen sus requisitos y por qué a una función le toca nivel A y a otra nivel D. La respuesta está en dos documentos de SAE: ARP4754A, que gobierna el desarrollo de la aeronave y de sus sistemas, y ARP4761, que aporta los métodos de evaluación de seguridad. Este artículo explica cómo encajan y cómo se recorre el proceso.
Dos documentos, dos funciones
ARP4754A —Guidelines for Development of Civil Aircraft and Systems— describe el proceso: cómo se capturan requisitos, cómo se define la arquitectura, cómo se reparten las funciones entre sistemas, cómo se asignan los niveles de garantía y cómo se valida y verifica todo ello. Es el marco que conecta el requisito de certificación de la aeronave con el objeto que acaba fabricándose.
ARP4761 aporta las herramientas: los métodos concretos de análisis de seguridad que alimentan ese proceso. No es un proceso alternativo, es la caja de herramientas del anterior.
Por debajo quedan DO-178C para el software y DO-254 para el hardware electrónico complejo. Y por encima, los requisitos de certificación aplicables a cada categoría de aeronave, con su cláusula general sobre equipos, sistemas e instalaciones, que es la que exige demostrar que ningún fallo con consecuencias catastróficas es razonablemente probable.
La clasificación de las condiciones de fallo
Todo el edificio descansa sobre una idea: cuanto peor sea la consecuencia de un fallo, menos probable tiene que ser. La clasificación y sus objetivos cuantitativos, por hora de vuelo, son los siguientes:
- Catastrófica: impide la continuación segura del vuelo y el aterrizaje. Objetivo: menos de 10⁻⁹.
- Peligrosa: gran reducción de los márgenes de seguridad o de la capacidad de la tripulación, lesiones graves a algunos ocupantes. Objetivo: menos de 10⁻⁷.
- Mayor: reducción significativa de márgenes, aumento notable de la carga de trabajo, molestias o lesiones leves. Objetivo: menos de 10⁻⁵.
- Menor: no reduce de forma apreciable la seguridad; aumenta ligeramente la carga de trabajo. Objetivo: menos de 10⁻³.
- Sin efecto sobre la seguridad.
De esa clasificación salen dos cosas distintas que conviene no confundir. Una es el objetivo probabilístico, que se demuestra con números a partir de tasas de fallo de los equipos. La otra es el nivel de garantía de desarrollo, que no se demuestra con números sino con rigor de proceso, y que existe precisamente porque los errores de diseño y de software no tienen tasa de fallo: no se desgastan, estaban ahí desde el principio.
El recorrido completo, fase a fase
1. Análisis funcional de peligros a nivel de aeronave
Se parte de las funciones de la aeronave —controlar la trayectoria, generar empuje, proporcionar presurización, informar a la tripulación— y, para cada una, se pregunta qué ocurre si se pierde, si se degrada o si funciona de forma errónea y no detectada. Esa última es la que más daño hace: un indicador que se apaga avisa; un indicador que miente, no.
Cada condición de fallo se clasifica, y de esa clasificación nacen los requisitos de seguridad de alto nivel. Es la actividad más importante de todo el proceso y la que exige más experiencia operacional, porque hay que imaginar la situación completa: fase de vuelo, condiciones meteorológicas, carga de trabajo y qué más puede estar pasando a la vez.
2. Análisis funcional de peligros a nivel de sistema
Una vez repartidas las funciones entre sistemas, se repite el ejercicio con el detalle de cada uno.
3. Evaluación preliminar de seguridad del sistema
Aquí se trabaja sobre la arquitectura propuesta, antes de que exista. Se construyen árboles de fallos de arriba abajo para comprobar si la arquitectura puede alcanzar los objetivos, y de ahí salen los requisitos de seguridad derivados: redundancias necesarias, independencia exigida, monitorizaciones, intervalos de inspección y los niveles de garantía que se asignan a cada elemento.
Esta fase es la que más valor aporta y la que más se recorta por calendario. Hacerla bien significa descubrir en la mesa de diseño que una arquitectura no llega, cuando cambiarla todavía cuesta poco.
4. Evaluación de seguridad del sistema
Con el sistema ya diseñado y los datos reales de los equipos, se cierran los números: tasas de fallo, cobertura de las monitorizaciones, intervalos de mantenimiento. Es la demostración de que lo construido cumple lo que se prometió.
5. Evaluación a nivel de aeronave
Se agregan los resultados de todos los sistemas y se comprueba que, en conjunto, la aeronave cumple. Aquí aparecen las interacciones que nadie vio por separado.
Los análisis de causa común
Un árbol de fallos supone que las ramas son independientes. Esa suposición es la que más veces falla en la realidad, y por eso ARP4761 exige comprobarla con tres análisis específicos:
- Análisis zonal: se recorre físicamente cada zona de la aeronave mirando qué hay instalado junto a qué. Dos canales redundantes que pasan por el mismo conducto no son independientes frente a un incendio local.
- Riesgos particulares: sucesos externos que afectan a varias zonas a la vez. Impacto de ave, desprendimiento de un álabe de turbina, rayo, granizo, fuga de fluido, descompresión.
- Modos comunes: fallos que afectan a elementos redundantes por compartir diseño, fabricante, lote, software, herramienta de desarrollo, calibración o personal de mantenimiento.
Estos análisis son los que más hallazgos producen en revisión, y los que más cambian el diseño físico de la instalación. Un ingeniero que los domina es especialmente valorado, porque obligan a mirar la aeronave como un objeto real y no como un diagrama.
Los niveles de garantía de desarrollo
A cada función y a cada elemento se le asigna un nivel de A a E, derivado de la clasificación de las condiciones de fallo a las que contribuye. Ese nivel determina cuánto rigor se exige en su desarrollo, y es el que después se traduce en los objetivos de DO-178C para el software y de DO-254 para el hardware.
El proceso admite reducir el nivel de un elemento si la arquitectura lo permite: con redundancia suficiente e independencia demostrada, dos elementos de nivel inferior pueden cubrir una función de nivel superior. Como en otros sectores, la condición es demostrar la independencia, y es ahí donde se concentra el escrutinio.
Requisitos: capturarlos, validarlos y verificarlos
ARP4754A dedica una parte sustancial a los requisitos, y distingue dos actividades que se confunden a diario:
- Validación de requisitos: ¿son los requisitos correctos y completos? ¿Expresan de verdad lo que hace falta? Se responde con revisiones, análisis, modelos, simulación y ensayos.
- Verificación de la implementación: ¿se ha construido lo que los requisitos pedían?
El fallo clásico es verificar impecablemente un conjunto de requisitos que estaba incompleto. Toda la trazabilidad del mundo no detecta un requisito que nunca se escribió, y por eso la validación tiene actividades propias.
Esta cadena completa, desde la cláusula de certificación hasta el caso de prueba del software, se recorre en el máster de Part-21, CS-23/25/27/29 y DO-178C/DO-254, que es donde se ve cómo encajan ARP4754A, ARP4761 y los documentos de software y hardware.
Qué perfiles contrata el sector
Ingeniero de seguridad de sistemas, ingeniero de sistemas aeronáuticos, especialista en certificación, ingeniero de requisitos y responsable de aeronavegabilidad. Contratan fabricantes de aeronaves, proveedores de sistemas, organizaciones de diseño aprobadas, ingenierías y autoridades.
Es una especialidad con una ventaja poco conocida: el método es transferible casi íntegro. Quien domina este proceso entiende de inmediato la seguridad funcional de automoción, la de ferrocarril y la de proceso industrial, porque las tres son adaptaciones de la misma idea a otro contexto.
Cómo se lee un árbol de fallos sin equivocarse
El árbol de fallos es la herramienta más usada y también la más fácil de malinterpretar. Tres ideas evitan la mayoría de los errores.
La primera: el suceso de cabecera manda. Un árbol responde exactamente a la pregunta que se le hace. «Pérdida total de empuje» y «pérdida no detectada de indicación de empuje» son árboles distintos, con ramas distintas, y confundirlos lleva a conclusiones opuestas.
La segunda: los conjuntos mínimos de corte son el resultado útil. Son las combinaciones más pequeñas de fallos básicos capaces de provocar el suceso. Un conjunto de corte de un solo elemento es un punto único de fallo, y en una función catastrófica no puede existir. La lista de conjuntos de corte ordenada por tamaño dice mucho más sobre la robustez del diseño que la probabilidad final.
La tercera: el número depende de hipótesis que hay que escribir. Tiempo de exposición, intervalo entre inspecciones, cobertura de las monitorizaciones y suposiciones de independencia. Dos ingenieros pueden obtener resultados muy distintos del mismo sistema simplemente por asumir intervalos de mantenimiento diferentes. Por eso las hipótesis se documentan y se revisan con el mismo cuidado que el cálculo.
Fallos latentes y el intervalo de inspección
Hay una categoría de fallo que merece atención propia: el que ocurre y nadie se entera, porque afecta a un elemento que solo se usa cuando falla el principal. Un sistema de reserva averiado no da síntomas hasta el día en que hace falta.
La probabilidad de que un fallo latente esté presente crece con el tiempo que puede permanecer oculto. De ahí que el análisis de seguridad no solo produzca requisitos de diseño, sino también tareas de mantenimiento con su periodicidad: comprobaciones periódicas cuyo intervalo sale directamente del cálculo.
Esto tiene una consecuencia que sorprende a quien llega de otros sectores: parte del expediente de seguridad de una aeronave no está en el diseño, sino en el programa de mantenimiento. Si el operador alarga un intervalo de inspección, está modificando una hipótesis del análisis de seguridad, y eso tiene que gestionarse formalmente.
Entender esa conexión entre diseño, análisis y mantenimiento es lo que distingue a un ingeniero de seguridad con experiencia de alguien que solo sabe construir árboles.
Preguntas frecuentes sobre ARP4754A y ARP4761
¿Son obligatorias?
Son medios de cumplimiento aceptados, no leyes. La autoridad las reconoce como forma válida de demostrar el cumplimiento de los requisitos de certificación, y en la práctica son el camino estándar.
¿Qué diferencia hay entre un FHA y un FMEA?
El FHA es de arriba abajo y parte de funciones: qué pasa si esta función falla. El FMEA es de abajo arriba y parte de componentes: qué pasa si este componente falla de esta manera. Se complementan, y ninguno sustituye al otro.
¿Se aplican a drones?
En operaciones certificadas se aplican enfoques equivalentes, adaptados al nivel de riesgo. En categorías de menor riesgo, el marco regulatorio es distinto y proporcionado, aunque los métodos de análisis siguen siendo los mismos.
¿Qué se actualizó en las revisiones recientes?
Las actualizaciones han ido en la línea de aclarar la relación entre los distintos documentos, reforzar la validación de requisitos y modernizar los métodos de análisis, incorporando técnicas que ya se usaban en la práctica. El esquema conceptual —clasificar, analizar, asignar niveles y demostrar— se mantiene.
Formaciones de SEIUM relacionadas con certificación aeronáutica
- Máster en Ingeniería de Rehabilitación Energética y Certificación
- Máster en Ingeniería de IEC 61508, EN 50126/8/9, ARP4761/4754A, IMO; LCC/RCM.
- Máster en Ingeniería de Rutas: requisitos de certificación por sector/continente.
- Máster en Ingeniería de Part-21/CS-23/25/27/29, DO-178C/DO-254, STC/TC.
- Máster en Ingeniería de Certificación Marítima
