La aviónica es donde el sector aeroespacial se encuentra con el software, y es el ejemplo más claro de esta sección de un campo donde la habilidad adyacente no se transfiere tan fácilmente como parece.
No es software normal con documentos de más
Una suposición habitual es que el software aeronáutico certificado es software normal más carga de cumplimiento. Esa suposición produce contrataciones fallidas y programas fallidos.
Cuatro cosas que difieren fundamentalmente.
Cada línea traza hasta un requisito. El código existe porque un requisito lo exigió, y ese vínculo está documentado y revisado. Un código que hace algo razonable pero no se puede trazar hasta un requisito es un hallazgo.
Hay que demostrar la cobertura de verificación. Hay que mostrar que las pruebas ejercitan el código hasta un nivel de cobertura estructural definido, que aumenta con el nivel de aseguramiento. Esto condiciona cómo se escribe el código, porque las construcciones complejas se vuelven caras de cubrir.
Se exige determinismo. El tiempo tiene que ser predecible y estar acotado. La asignación dinámica de memoria, los bucles no acotados y las rutas de ejecución impredecibles se evitan o se prohíben según el nivel.
Las propias herramientas exigen cualificación. Si la salida de una herramienta se confía sin revisión independiente, la herramienta tiene que estar cualificada. Los compiladores, los generadores de pruebas y las herramientas de análisis entran todos en esto.
Un ingeniero de software comercial hábil no es automáticamente un ingeniero de aviónica hábil. Las restricciones invierten varios hábitos que hacen bueno a alguien en software ordinario.
La consecuencia para la contratación es concreta: reclutar ingenieros de software generalistas para puestos certificados y esperar un ajuste corto subestima sistemáticamente la transición, y los propios ingenieros con frecuencia la encuentran frustrante antes de que resulte satisfactoria.
Qué cubre esta dirección
El alcance: electrónica de aeronaves, GPS, control de vuelo, comunicaciones y sistemas de a bordo.
Cuatro áreas.
Sistemas de control de vuelo. La cadena desde la entrada del piloto o del piloto automático hasta el movimiento de la superficie de control, incluidas las arquitecturas fly-by-wire y su redundancia.
Sistemas de navegación. Navegación por satélite, sistemas inerciales, datos de aire y la fusión de los tres.
Comunicaciones y vigilancia. Radio, enlace de datos, transpondedores y los sistemas que permiten ver y coordinar las aeronaves.
Arquitecturas integradas. Cómo comparten hardware de cómputo las funciones con particionamiento garantizado, de modo que un fallo en una no pueda afectar a otra.
Por qué los requisitos son tan estrictos
Merece la pena explicarlo en vez de solo afirmarlo, porque entenderlo es lo que hace bueno a un ingeniero, no solo cumplidor.
Los requisitos de aseguramiento vienen determinados por la consecuencia. Una función cuyo fallo sería catastrófico carga las obligaciones más pesadas; una cuyo fallo es meramente incómodo carga muchas menos.
Eso produce tres realidades prácticas.
La misma función puede cargar obligaciones distintas. Según el avión, la arquitectura y lo que quedaría disponible si falla. El nivel de aseguramiento sale de una evaluación de seguridad, no del nombre de la función.
La arquitectura puede reducir la carga. Diseñar de forma que un fallo se detecte y se gestione por una vía independiente puede reducir el nivel de aseguramiento exigido a un componente, lo cual es una compensación de ingeniería genuina y no un ejercicio de papeleo.
El cambio es costoso. Modificar software certificado implica reverificar las partes afectadas y restablecer la evidencia, que es por lo que cambios aparentemente triviales cargan un coste desproporcionado y por lo que el software se congela mucho antes de lo que esperan los equipos comerciales.
Dónde encaja en el dominio
Aviónica, navegación y sistemas aeroespaciales es la quinta de las nueve direcciones del dominio de espacio, aeroespacial y nueva movilidad de Astra Trainer, situada junto a ingeniería aeronáutica y operaciones de aviación, y conectando con el dominio de robótica, donde sistemas de control cubre la teoría de control subyacente.
También se combina con semiconductores y electrónica para el hardware, y con IA, datos y computación para la práctica de ingeniería de software, aunque los socios deben notar que la transición del software comercial al certificado es la sustancia de esta dirección más que un detalle. Puedes verlas aquí.
Navegación, y una dependencia que merece nombrarse
Una observación factual con consecuencias reales de ingeniería.
La navegación por satélite se ha convertido en una dependencia compartida por mucho más que la aviación: transporte marítimo, transporte por carretera, topografía, agricultura, servicios de emergencia y, especialmente, sincronización horaria de precisión para redes de telecomunicaciones, sistemas financieros y redes eléctricas.
Las señales llegan débiles al suelo, lo que las hace susceptibles tanto a interferencias no intencionadas como a interferencia o suplantación deliberadas. Se han reportado episodios de interferencia que afectan a la navegación aeronáutica en varias regiones, y el sistema de aviación los gestiona mediante procedimientos, ayudas de navegación alternativas y sistemas inerciales.
Tres consecuencias para la ingeniería y la plantilla.
El posicionamiento alternativo y complementario es un área activa. La navegación inercial, la navegación de terreno y visual, y las fuentes de sincronización horaria alternativas reciben atención por esta dependencia.
La resiliencia es un requisito de diseño, no una prestación. Los sistemas que asumen disponibilidad continua de navegación por satélite están dando por sentado algo que no siempre se cumple.
El conjunto de habilidades es nicho y creciente. Los ingenieros que entienden tanto el procesamiento de señal de navegación por satélite como los sistemas inerciales son escasos, y se necesitan bien fuera de la aviación.
Esto se plantea como una consideración de ingeniería conocida. No es una predicción sobre ninguna región o evento concreto.
Los puestos, con nombre
Ingenieros de software de aviónica. Software aeronáutico certificado. La escasez central.
Ingenieros de hardware de aviónica. Placas, interfaces, cualificación ambiental.
Ingenieros de seguridad de sistemas. Evaluación de seguridad, análisis de fallos y asignación de nivel de aseguramiento. Centrales y escasos.
Ingenieros de verificación y validación. Pruebas basadas en requisitos y análisis de cobertura. La población más numerosa en un programa certificado.
Ingenieros de sistemas de navegación. Navegación por satélite, inercial y fusión de sensores.
Ingenieros de integración y ensayo. Bancos de pruebas, iron birds e instrumentación de ensayo en vuelo.
Especialistas en certificación de software y hardware electrónico complejo.
Técnicos de mantenimiento de aviónica. Con licencia, en servicio, y una escasez separada y persistente.
Quién puede formarse para esto
Ingenieros de otros dominios de seguridad certificada. Señalización ferroviaria, instrumentación y control nuclear, dispositivos médicos, seguridad funcional en automoción. Ya aceptan que la evidencia forma parte del producto, que es la actitud más difícil de inculcar, y necesitan el marco específico de aviación.
Ingenieros de software embebido. De entornos industriales o de automoción, ya acostumbrados a entornos deterministas y restringidos. Un paso más corto que desde desarrollo web o de aplicaciones.
Ingenieros de pruebas. Hacia verificación, que es el mayor requisito de cualquier programa certificado y el punto de entrada más accesible.
Técnicos de mantenimiento de aviónica. Hacia puestos de soporte de ingeniería e integración, aportando conocimiento de cómo se comportan los sistemas en servicio que los equipos de diseño con frecuencia no tienen.
Ingenieros de electrónica. Hacia hardware e integración.
Personal militar de aviónica. Llega con la cultura de sistemas y aeronavegabilidad ya incorporada.
La certificación y las licencias son legales, no un trámite. Los sistemas aerotransportados se aprueban mediante procesos regulatorios, y la aprobación de organización de diseño, el crédito de certificación y la liberación de aeronavegabilidad los ostentan organizaciones aprobadas y firmantes cualificados. El mantenimiento de aviónica exige una licencia con las habilitaciones adecuadas. La tecnología de aviación también está sujeta a control de exportación en la mayoría de las jurisdicciones. La formación construye comprensión de ingeniería y apoya a quienes trabajan hacia estas vías. No otorga aprobación, crédito de certificación, licencia ni autoridad para liberar nada al servicio.
Qué llevarte de todo esto
El software certificado es otro oficio, no software normal con documentos, y varios hábitos que hacen bueno a un ingeniero comercial aquí son restricciones.
El nivel de aseguramiento sigue a la consecuencia, así que las decisiones de arquitectura pueden reducir de verdad la carga, lo que convierte la evaluación de seguridad en una actividad de ingeniería más que en un trámite de aprobación.
El cambio es costoso porque hay que restablecer la evidencia, que es por lo que el software se congela antes de lo que esperan los equipos comerciales.
La navegación por satélite es una dependencia compartida mucho más allá de la aviación, y el posicionamiento resiliente es un conjunto de habilidades nicho y creciente.
Y los ingenieros de ferrocarril, nuclear, dispositivos médicos o seguridad funcional en automoción se reconvierten mucho mejor que los ingenieros de software generalistas, porque ya tratan la evidencia como parte del producto.
¿Es el software de aviónica certificado solo software con más papeleo?
No. Cada línea traza hasta un requisito, hay que demostrar estructuralmente la cobertura de verificación, el tiempo tiene que ser determinista, y las propias herramientas pueden exigir cualificación. Varios hábitos que hacen bueno a un ingeniero comercial se convierten en restricciones.
¿Por qué varían los requisitos de aseguramiento?
Porque siguen la consecuencia del fallo, determinada por una evaluación de seguridad. La misma función puede cargar obligaciones muy distintas según la arquitectura y lo que quede disponible si falla.
¿Por qué es tan caro cambiar software certificado?
Porque hay que restablecer la evidencia de verificación afectada. Por eso el software se congela mucho antes en un programa aeroespacial de lo que esperan los equipos comerciales.
¿Quién se reconvierte a puestos de aviónica?
Ingenieros de señalización ferroviaria, instrumentación nuclear, dispositivos médicos o seguridad funcional en automoción, porque ya aceptan la evidencia como parte del producto. Los ingenieros de software embebido dan un paso más corto que los desarrolladores de aplicaciones.
¿Dónde encaja esto en el dominio?
Quinta de las nueve direcciones del dominio de espacio, aeroespacial y nueva movilidad de Astra Trainer, conectada con sistemas de control en robótica y con electrónica en el dominio de chips. Puedes verlas aquí.