¿Qué CPU y lenguajes de programación se utilizan en los nuevos sistemas de control de vuelo de los aviones?

¿Los nuevos sistemas de hoy están construidos con las mismas CPU, lenguajes de programación y software de desarrollo que los de hace 20 años o más?

Por nuevo me refiero a que estos sistemas se están diseñando actualmente para futuros aviones de pasajeros, o han estado en servicio por primera vez recientemente.

Cualquier ejemplo específico de nuevos diseños utilizados en un importante avión comercial de última generación (el A350 y el 787 son los ejemplos más obvios) sería mejor que las respuestas generales.

Estoy interesado en ejemplos de cualquier sistema esencial de vuelo (pero no, por ejemplo, entretenimiento a bordo).

Como parte de esta pregunta: ¿la industria tiende a actualizar sus productos a través de actualizaciones incrementales de los microprocesadores y lenguajes de programación que adopta, o tiende a hacer cambios únicos en una generación hacia nuevas tecnologías? Y, ¿existen diferencias significativas en la forma en que los fabricantes de aerolíneas (a diferencia de las industrias militares/de aviación general) abordan esto?

Respuestas (2)

Nota: Me concentré más en los cambios en el hardware y el software de aviación que en lo que se usa actualmente, ya que la pregunta vinculada sobre los lenguajes de programación sigue vigente para las aeronaves "nuevas". No deseo duplicar esa pregunta o sus respuestas. En mi opinión, C++, C# y Ada probablemente serán los lenguajes de programación dominantes para aviónica al menos durante la próxima década.

Primero, debe comprender el ciclo de vida de los aviones. Muchas aeronaves están en servicio desde hace más de 30 años . La aviónica recibe actualizaciones (ya sea agregando nuevas funciones, corrigiendo errores o agregando cumplimiento para cumplir con los mandatos). Sin embargo, la mayor parte del trabajo se realiza durante el desarrollo inicial del software y el hardware. Luego, la configuración es mayormente fija hasta que esa generación de aviónica es reemplazada por el fabricante o modificada por otro fabricante.

Entonces, ¿qué ha cambiado en la práctica?

Si la aviónica pasa por una actualización generacional (como las pantallas CRT a LCD), cualquier cambio debe valer el costo, por lo que generalmente no se cambia mucho. Tal vez la CPU, pero definitivamente no el lenguaje de programación. Por ejemplo, el G1000 estuvo disponible durante 12 años antes de lanzar otra generación de hardware (aunque mientras tanto publicaron numerosas actualizaciones de software para compatibilidad de hardware y visión sintética y demás).

De manera similar, Avidyne Entegra estuvo disponible durante cinco años y agregó continuamente funciones importantes como el clima de enlace de datos y el enfoque LPV antes de que finalmente actualizara el hardware en la versión 9 en 2009. Los jets Falcon como el Falcon 900 tuvieron una actualización de software y hardware para su aviónica en 2011 , pero esa actualización se basó en la familia de hardware y software Primus Epic, cuya primera generación ya tenía 9 años. Creo que todos los 900 todavía ejecutaban el antiguo hardware de 1996 antes de la actualización de 2011. En el otro extremo del espectro de estas actualizaciones lentas, el sistema JSF de los militares está diseñado para actualizarse fácilmente cada pocos años (pero no dicen con qué frecuencia).

¿Por qué no hacer actualizaciones más frecuentes?

Lo que genera valor en la aviónica no suelen ser las características nuevas y exóticas y, definitivamente, no es el rendimiento informático. El valor está impulsado por la confiabilidad, el cumplimiento de los mandatos y el cumplimiento de la seguridad . Esto requiere características que sean lo suficientemente simples para que el ingeniero y el piloto las entiendan y que sean lo suficientemente sólidas como para que cientos de vidas dependan de ellas. Por lo tanto, las nuevas funciones que se agregan generalmente requieren poco rendimiento adicional y hay poco incentivo para la tecnología de punta o los últimos paradigmas de programación como la computación en la nube, el aprendizaje automático o la orientación a objetos.

Un ingeniero de Rockwell Collins afirmó algo que se aplica a toda la aviónica: "En el pasado, luchábamos para adaptar todo lo que necesitábamos hacer al tamaño del procesador y las velocidades que teníamos y cómo obtener todos esos bits en las interfaces que teníamos. Con el procesadores que tenemos ahora e interfaces de fibra, eso ya no es una preocupación... Ahora el problema es cómo administrar y diseñar un buen software sin problemas y probar todas las líneas de código involucradas. ancho de banda que necesitamos, tenemos que asegurarnos de que podemos usarlo y no diseñarnos a nosotros mismos en una esquina".

La verificación es uno de los mayores factores impulsores (y costos) en el uso de procesadores y lenguajes de programación. Todo el hardware y software debe tener un nivel de seguridadadjunto, con las funciones más críticas (como aviónica para aterrizaje automático) consideradas "Nivel A", lo que significa que tal falla de la aviónica podría ser catastrófica. Para lograr los estrictos requisitos de seguridad del software de nivel A (que a menudo es una de esas fallas cada 10^9 horas de vuelo), el software y el hardware deben probarse exhaustivamente para garantizar que nada salga mal. Eso incluye cubrir cada condición en cada línea de código. La mayoría de las herramientas desarrolladas para trabajar con su lenguaje de programación y arquitectura de software también deben ser verificadas formalmente (generalmente llamadas "calificadas"). Además de todo eso, se deben realizar costosas pruebas de vuelo para evaluar cualquier cambio. Esto crea mucha inercia y significa una revisión completa de un producto existente o comenzar desde cero para un nuevo producto solo para obtener un "

¿Qué pasa con la compatibilidad con las nuevas funciones de la CPU?

La virtualización (lo que permite que diferentes sistemas operativos actúen como si se estuvieran ejecutando solos, pero en realidad se ejecutan con una capa entre ellos y el hardware básico) y el procesamiento multinúcleo ahora es compatible con algunos sistemas operativos en tiempo real para procesadores comerciales listos para usar. . Estos tienen que seguir los estándares en DO-332 y otros materiales. Según mi texto de 2013 , esto todavía está en la fase de investigación y no se ha certificado ninguna aviónica con estas características. El problema principal es que los procesadores multinúcleo no solo tienen más funciones, sino que tienen más funciones que no están completamente documentadas ni comprobables. Para obtener más información sobre problemas con el uso de múltiples núcleos, consulte el CAST 32 de la FAA y esta presentación .

" Virtualización (donde diferentes procesos actúan como si se estuvieran ejecutando por sí mismos, pero en realidad se ejecutan en una máquina virtual) "... mmm, la definición que tengo para la virtualización es: CPU, memoria, almacenamiento, E/S y red parecen ser de propiedad y uso exclusivos de un sistema operativo, mientras que en realidad varias instancias de sistema operativo se ejecutan en los mismos recursos que un virtualizador comparte entre ellas. La virtualización puede ser por hardware , o por software .
Gracias @CodyP por esta respuesta detallada e informativa a la pregunta. Hay muchos asuntos aquí que merecen un examen más detallado, pero dos que se destacan: 1) multi-core processors [have] features that are not comprehensively documented or testable- en otras palabras, ¡las futuras generaciones de CPU pueden resultar esencialmente inadecuadas para aplicaciones aeroespaciales críticas! 2) puede llegar un momento en que el hardware de microprocesamiento sobre el que se construyen estos sistemas muy conservadores simplemente deje de estar disponible.
@mins ¡Gracias por la captura!
Completamente documentado o comprobable significa que hay variables ocultas internas y características que no se describen completamente. Probablemente valdrá la pena la dificultad adicional de verificación para usar CPU multinúcleo. En el peor de los casos, puede apagar un núcleo. Sin embargo, no olvide que 1) Estamos hablando de procesadores integrados, no de procesadores de escritorio o móviles, por lo que es un mercado diferente y verá que se utilizan diferentes procesadores 2) Incluso el mercado de la electrónica de consumo por sí solo es muy diverso. Después de todo, Apple sigue poniendo procesadores Apple de doble núcleo en iPads.
Para la virtualización, una de las principales preocupaciones es que cuantas más cosas ejecute en una máquina, más se estará dando a sí mismo un "Punto único de falla". Cuando algo se rompe en un avión, nos gusta la redundancia y la independencia del sistema: cuantas menos cosas se rompan cuando algo más se rompe, ¡mejor!
@JonStory No estoy seguro de cuánto afecta la virtualización al análisis de punto único de falla, pero puedo suponer que si se implementa correctamente, no sería tan diferente de los IMA actuales, donde podría tener mantenimiento y fly-by-wire funcionando uno al lado del otro en una sola tarjeta. El punto único de falla se mitiga al tener varias computadoras separadas. Sin embargo, la virtualización de la CPU no se diseñó con el mismo particionamiento robusto que usamos en el software de aviónica, por lo que el particionamiento sería un desafío.
Sí, definitivamente es posible hacerlo, como con cualquier cosa, solo podemos tener dos... es solo que está acumulando más en un sistema: lo cual es excelente para reducir costos, pero no necesariamente ideal para confiabilidad crítica para la seguridad, donde "Cada sistema hace una cosa, todo de una cosa, y nada más que esa cosa" suele ser más útil. Ciertamente puede ser un riesgo controlado, pero no obstante es un riesgo.
Votado a la baja porque, si bien es una respuesta detallada, en realidad no responde a la pregunta original sobre procesadores o lenguajes de programación.
Definitivamente no es C#, supongo que te refieres simplemente a C. C# se recolecta como basura, algo que definitivamente evitarías en los sistemas en tiempo real.

Muchos factores intervienen en la selección del lenguaje de programación y el procesador para cada producto, algunos de los cuales son:

  • Propósito general del sistema de software
  • Nivel de garantía de diseño seleccionado (AE)
  • Restricciones de hardware del producto.
  • Experiencia de la empresa con un idioma
  • Herramientas de desarrollo disponibles
  • Herramientas de verificación disponibles

Creo que los lenguajes más comunes que se usan en los sistemas críticos para la seguridad de la aviación son C y Ada, con C++ ganando más uso en los últimos 10 o 15 años.

Los procesadores pueden variar desde simples micros SO8 de 8 bits hasta PowerPC, multinúcleo x86 o ARM System on Chips. El hardware electrónico, como los PLD y los FPGA, también se está volviendo popular para ciertas cargas de trabajo.

¡Bienvenido a Aviation.SE! Su respuesta podría incluir un poco más de detalle sobre lo que ha cambiado para responder completamente la pregunta, pero es un buen comienzo. Muchas respuestas se editan y construyen/mejoran durante un período de tiempo para agregar más detalles.