¿Los sistemas de aviónica críticos para la seguridad ejecutan Linux?

Ninguno de los sistemas de aviónica en los que he trabajado ha usado Linux o cualquier sistema operativo de consumo. Hay algunos problemas principales.

Lo primero es lo práctico. La mayoría de la aviónica crítica para la seguridad implica un circuito de control y, por lo tanto, tiene un requisito de tiempo real. Eso significa que no solo es importante ejecutar un proceso y obtener una respuesta, sino que debe obtener la respuesta dentro de un límite de tiempo estrictamente controlado. Cada proceso de software crítico en una aeronave está programado para garantizar que tenga un ciclo de control estable. Para hacer eso, necesita un sistema operativo en tiempo real y Linux no lo es.

En segundo lugar está la necesidad de certificación. El software utilizado en una aeronave debe desarrollarse para cumplir con el nivel de garantía de desarrollo (DAL) apropiado para el nivel de peligro asociado. Los sistemas críticos de seguridad deben cumplir con el nivel "A" de DAL. Cualquier sistema operativo que use debe cumplir con el mismo DAL que la función que se ejecuta en él. Estos requisitos están definidos en RTCA DO-178C . Linux no fue desarrollado con este estándar. Solo hay unas pocas plataformas de desarrollo de SO/software que pueden certificarse. Green Hills, Wind River y LynxOS son los pocos sistemas con los que estoy familiarizado que cumplen con los requisitos.

También existe otra restricción en el sentido de que la certificación requiere un control de versiones muy estricto. La aviónica existirá en el campo durante muchos años y cualquier cambio en ella también debe certificarse. En general, no hay una razón válida para actualizar el sistema operativo en una unidad antigua y, en muchos casos, no podría hacerlo sin actualizar el hardware (que es un gasto mayor que nadie quiere). Entonces, al actualizar una unidad antigua, tengo que crear el software 'nuevo' para que se ejecute en la versión del sistema operativo que exista actualmente en el producto. Esa podría ser una plataforma de 15 o 20 años (o más). Un sistema operativo en rápida evolución como Linux tendría un impacto negativo en el soporte de productos a largo plazo.

La respuesta corta es que ningún sistema de aviónica crítico para la seguridad que yo conozca use Linux, y los sistemas de mayor criticidad a menudo no usan un sistema operativo comercial en absoluto. Sin embargo, Linux se usa en otras aplicaciones críticas para la seguridad, como Space X Falcon 9 y aplicaciones médicas. Es difícil hacer una explicación más detallada sin profundizar demasiado, ya que la pregunta es algo así como preguntar "¿los fuselajes modernos están hechos con nanomateriales?", Donde una explicación detallada tendría que cubrir los pros y los contras del material, lugares dónde su uso tiene más y menos sentido, diferencias en los fabricantes y una descripción general de lo que se usa en su lugar, etc. Trataré de cubrir todos esos puntos de manera sucinta con enlaces a más información.

Según este informe de la FAAdesde 2001, algunos de los principales sistemas operativos para aviónica certificada fueron VRTX, LynxOS, PSOS, VxWorks y OSE de Enea, aunque la aviónica no crítica a veces usa otros sistemas como Windows NT. (Sí, LynxOS se basa en Unix y Linux se considera "similar a Unix", pero hay muchas diferencias entre los dos, al igual que Linux no es similar a Mac OS X basado en BSD). Sin embargo, los sistemas más críticos no utilizan ningún sistema operativo comercial. Señalan que "con la evidencia disponible hoy, en general, se puede afirmar que los productos COTS generalmente no cumplen con los requisitos para el software de criticidad de nivel A". En términos sencillos, eso significa que la mayoría de la aviónica desarrollada con software de terceros, desde VxWorks hasta Linux, no se estaba probando ni analizando lo suficiente como para colocarla en algo crítico como un sistema de aterrizaje. Unidad TCAS, o unidad de visualización crítica. Sin embargo, es probable que eso haya cambiado en los más de 10 años desde que se escribió el informe. Aquí hay una más recienteartículo sobre el uso del sistema operativo en tiempo real en aviónica .

¿Qué significan RTOS y COTS?

Un concepto importante aquí es un sistema operativo en tiempo real o RTOS. En pocas palabras, un RTOS proporciona garantías de que el software no se quedará sin tiempo de cómputo programado, los mensajes entre las partes del software se transmiten en una pequeña cantidad de tiempo, la memoria no se agotará y otras tareas importantes están garantizadas en lugar de funcionar. bien en condiciones normales y luego rompiéndose en condiciones inusuales. Los sistemas operativos normales no pueden ofrecer tales garantías. Estas garantías, o sus sustitutos aceptables, se requieren para la certificación de la mayoría de la aviónica.

Otro concepto importante es la diferencia entre los sistemas internos y comerciales listos para usar (COTS). Los sistemas comerciales listos para usar están disponibles públicamente y no se personalizan mucho para cada fabricante. Este artículo ofrece un buen resumen de las ventajas y desventajas de los sistemas operativos comerciales e internos. Muchas aviónicas de alta criticidad todavía tienen el software central desarrollado internamente debido a las ventajas que implican.

¿Linux cumple con los requisitos de certificación?

Sí, Linux no está "certificado por la FAA", pero en realidad ningún RTOS está "certificado por la FAA" o "cumple con DO-178C". DO-178C proporciona objetivos que los ingenieros de sistemas de aviónica deben cumplir para certificar todo su software de aviónica (los objetivos cubren auditorías, pruebas, análisis de seguridad y redacción de requisitos, entre otras cosas). Por lo tanto, lo mejor que puede hacer el proveedor del sistema operativo es proporcionar un software "listo para DO-178C" o seguir las pautas de DO-178C. Tenga en cuenta que DO-178C reconoce varios niveles de seguridad, por lo que lo que se puede certificar con DO-178C para un sistema de mantenimiento puede no serlo con DO-178C para una unidad de visualización crítica. El problema con Linux no es que Linux no esté "certificado bajo DO-178C", es que es difícil de certificar debido a los desafíos que se indican a continuación. Eso' Es posible certificar un sistema usando Linux, pero hacerlo podría ser prohibitivamente difícil debido al análisis adicional, las medidas de seguridad y la documentación que se necesitarían, especialmente para la aviónica más crítica. Algunos de estos desafíos y métodos alternativos de cumplimiento se describen eneste informe de la FAA .

Ventajas y desventajas de Linux

Hay ventajas en el uso de Linux, que se comparten en parte con otros sistemas comerciales. Más empleados ya tendrán experiencia con Linux, y el sistema operativo se diseñó con más experiencia y tiempo que la mayoría de las organizaciones tienen disponible. Los sistemas comerciales también tienen un precio de etiqueta mucho más bajo que el software interno. Los sistemas comerciales también son más adaptables y permiten cambios en el hardware y espacio para el crecimiento futuro sin volver a la mesa de diseño. Las herramientas para trabajar con el software están más desarrolladas y también pueden tener un historial de servicio más largo que brinda confianza en el software.

Estos son algunos de los problemas que enfrenta Linux en un sistema de aviónica cuando compite con un RTOS, de este informe de la FAA :

• particionamiento: si se supone que dos programas se ejecutan de forma independiente, debe existir evidencia de que un programa no puede interferir con otro a través de la estructura de memoria compartida, cachés, soporte de placa y firmware, errores, interrupciones, etc.

• Tiempo de ejecución en el peor de los casos: en la informática de escritorio, está bien si atasco mi PC con demasiadas solicitudes o condiciones inusuales a la vez y el sistema se ralentiza o se salta algunos pasos del programa. En aviónica esto no es aceptable por razones obvias. El proveedor necesitaría verificar esto a través de modelos de CPU, memoria, etc. o pruebas de laboratorio rigurosas y análisis de tiempo. Ambos son más difíciles cuanto más complejo es su hardware y software.

• Cobertura MCDC: las pruebas en la aviónica más crítica (Nivel A) requieren ejecutar suficientes líneas de código y condiciones de decisión para alcanzar el estándar de cobertura de código MCDC, que se encuentra entre "ejecutar cada línea de código" y pruebas exhaustivas de cada combinación de condiciones. Algunos sistemas operativos como Linux pueden ser extremadamente difíciles de probar lo suficientemente a fondo como para cumplir con este estándar.
• documentación: el análisis riguroso y la prueba de estrés requieren mucha documentación sobre el funcionamiento interno del sistema operativo
• Consideraciones de seguridad: Linux, por diseño, tiene más problemas de seguridad que una aplicación interna sencilla. Estos temas de seguridad se están volviendo cada vez más importantes, especialmente en las fuerzas armadas.
• código muerto e inalcanzable: por lo general, se requiere deshabilitar cuidadosamente las muchas funciones no utilizadas de Linux y garantizar que no puedan interferir en su software para la certificación

Otras industrias críticas para la seguridad

¿Qué pasa con industrias similares críticas para la seguridad? El Space X Falcon usa Linux en algunas de sus computadoras de vuelo ( fuentes ). Según esta entrevista , Space X parece priorizar el crecimiento futuro, la disponibilidad, los tiempos de ciclo cortos y la experiencia sobre la simplicidad y solidez del desarrollo interno en esta área. Tenga en cuenta que las computadoras de control de vuelo en el Space X Falcon no son directamente análogas a una LRU en la aviónica moderna típica, por lo que es probable que se requiera trabajo adicional o una arquitectura inusual para que Linux funcione para las aplicaciones de aviónica típicas.

Linux también se usa en muchas aplicaciones médicas críticas para la seguridad, pero no sin problemas similares a los que se enfrentan en la aviación. Recomiendo leer "Elegir Linux para dispositivos médicos" de Wind River , o este artículo sobre las desventajas de Linux en aplicaciones médicas críticas para la seguridad.

Supongo que está hablando de la aviónica principal, como la guía de vuelo, el piloto automático, el vuelo por cable o las pantallas. Otros sistemas de aviones podrían considerarse críticos para la seguridad, pero no son ejemplos típicos de dispositivos críticos para la seguridad, como bolsas de vuelo electrónicas certificadas, soluciones de conectividad y software de mantenimiento. A veces, estos son más adecuados para una aplicación de Linux debido a la alta complejidad y las consideraciones de seguridad menos rigurosas.

Tenga en cuenta que no soy un experto en este campo y mi consejo no reemplaza el consejo de un especialista en certificación.

Parece que los pilotos ahora al menos a veces usan tabletas para listas de verificación .

Si estas tabletas son dispositivos Android (la mayoría de ellos ), entonces ejecutan el kernel de Linux. Android usa menos de la pila estándar de Linux, pero aún usa el kernel de Linux. Las listas de verificación son críticas para la seguridad, creo. Las tabletas Apple y Windows usan kernels diferentes, no Linux.

Hay muchas aplicaciones de listas de verificación para dispositivos Android . Supongo que alguien los usa.

Kernel es el núcleo del sistema operativo de una computadora que mantiene un control completo sobre todas las demás partes. Como el cableado de un avión.

Para aclarar algunos conceptos erróneos sobre Linux que se encuentran en muchas de las respuestas dadas.

Linux NO es un sistema operativo "comercial". Es gratis para que cualquiera descargue y piratee como quiera. (Algunas empresas lo empaquetan con una gran cantidad de aplicaciones como una distribución o "distribución" y cobran por respaldar el paquete).

Linux NO es una compilación monolítica con muchas funciones extrañas. El núcleo del kernel de Linux es lo suficientemente simple y eficiente como para instalarlo en relojes inteligentes y muchos otros dispositivos integrados. Los adornos son proporcionados por una multitud de módulos de kernel opcionales. Cuando construyes tu kernel de Linux para la instalación, eliges qué módulos quieres y si los quieres integrados en un solo blob con el núcleo (rápido) o como blobs separados (operacionalmente flexible).

Linux NO es un sistema operativo de "tierra de usuario". Para eso hay que añadir una capa de interfaz como GNU o Android. Se utiliza ampliamente en aplicaciones integradas, donde los ingenieros de la empresa han hecho lo descrito anteriormente.

Linux no es más inseguro que cualquier otro sistema operativo. De hecho, muchos lo consideran uno de los más seguros. Es en la zona del usuario donde las distribuciones como Android salen terriblemente mal, mientras que otra serie de exploits recientes se centró en fallas de diseño de hardware.

Linux puede ser tan estable y compatible como desee. Una empresa de sistemas operativos de aviónica puede respaldar felizmente una compilación de kernel determinada durante veinte años o más, y simplemente ignorar el flujo incesante de avances a menos y hasta que necesiten aprovecharlo para una actualización o un nuevo producto. Una modificación determinada a menudo puede ser "reportada" a su compilación anterior, por lo que no necesita lidiar con la actualización completa.

Linux tiene varios ajustes en tiempo real disponibles si desea usarlos. Posiblemente ninguno sea completamente satisfactorio para el control de vuelo central, pero la licencia abierta significa que, en principio, no hay nada que le impida arremangarse y ajustarlo usted mismo. Luego puede volver a introducir su código en el árbol fuente de Linux y otros pueden usarlo y mejorarlo aún más.

Habiendo dicho todo eso, es mucho trabajo personalizar Linux para su régimen de hardware/software determinado y las licencias abiertas dificultan el cobro de fuertes regalías. Por lo tanto, a las casas de software especializadas les resulta igualmente difícil ganarse la vida con eso, por lo que, a menos que una casa de aviónica quiera el gasto de personalizar su propio sistema operativo, solo encontrará ofertas con licencia comercial disponibles de los especialistas.

Esta última es la razón principal por la que Linux rara vez aparece en la aviónica, y por la que todos los demás problemas no se abordan.

Por otro lado, si incluye drones comerciales de consumo y de gama baja, Linux ya es popular, si no dominante. No hay duda de que en los próximos años se abrirá camino de manera constante en la cadena alimentaria.

¿Se usa Linux para aplicaciones críticas de seguridad? No si. Tal vez. Tengan paciencia conmigo...

El USS Umwalt usa Linux para sus amplios requisitos de datos y LynxOS para aplicaciones integradas en tiempo real, que se describen en este artículo .

La computadora portátil estándar Linux es un sistema operativo de espacio de usuario: espera hasta que un usuario hace clic con el mouse, presiona una tecla o genera una salida, y luego toma medidas. Puede haber o no muchos programas abiertos. La entrada del usuario es un evento estadístico en lo que respecta al O/S: puede ocurrir o no en el próximo minuto.

Compare eso con un lazo de control digital. Se ejecuta en un procesador y usa memoria, solo hardware de computadora estándar. Pero se diferencian del software de escritorio en que:

• Están incrustados ;
• Tener un conjunto de tareas predefinidas;
• Tener restricciones de tiempo estrictas;
• Ejecutar en un bucle sin fin. Al final del programa, vuelve al inicio y vuelve a realizar la rutina, esto sería un marco de iteración.

El software necesita leer entradas y generar salidas, cada iteración, y un marco de iteración se ejecuta durante un período de tiempo fijo. Un sistema de tiempo real duro es un sistema en el que las respuestas cronometradas deben ser deterministas: cualquier cosa que haga debe terminarse en una iteración del software. Si el bucle de control se ejecuta a 100 Hz, un ciclo de iteración tarda 10 milisegundos, y el hardware debe ser lo suficientemente rápido para garantizar que todo el proceso pueda terminar dentro del tiempo, cada vez.

Estos lazos de control generalmente no son enormes, y generalmente no tienen una cantidad de ventanas abiertas entre 1 y 100. Programas pequeños y rápidos y una cantidad limitada de ventanas, así es como O/Ses para programas críticos de seguridad y lazos en tiempo real. están hechos para. Lo cual es genial, en los viejos tiempos no solía haber un sistema operativo para esto y el código tenía que escribirse en ensamblador o algo peor. Las llamadas de E/S eran específicas del hardware y, por lo tanto, no eran portátiles de un conjunto de chips a otro.

Aquí es donde entran los O/S en tiempo real como VxWorks, LynxOS y algunos otros. Son O/S basados ​​en Unix y compatibles con POSIX. La capa de hardware se vuelve invisible para el programador, que tiene un conjunto de herramientas de desarrollo para utilizar lenguajes informáticos de alto nivel con llamadas de E/S estándar y rutinas de temporización. Son escalables: puede comenzar con un sistema operativo que simplemente se inicia y luego ejecuta inmediatamente su binario compilado de forma cruzada a una velocidad establecida en la interfaz del temporizador. O puede volver a configurar el kernel e incluir un par de interrupciones de usuario que observen los teclados o los datos RS-232 que ingresan, todo depende del programador, que también tiene un amplio conjunto de herramientas para temporización y E/S.

VxWorks puede ser costoso (pero es bien compatible), y ahora hay algunas alternativas de código abierto disponibles basadas en el kernel de Linux, como Xenomai , RTLinux y Xilinx . Algunos de estos intentan tener todos los servicios disponibles para las aplicaciones de escritorio y solo tienen un temporizador de interrupción que hace todo lo posible para que la tarea se ejecute de manera uniforme, incluso si un procesador de textos inicia una revisión ortográfica. Otros son difíciles de escalar, como VxWorks, pero son de código abierto y el soporte puede ser un desafío. Que yo sepa, todavía no han estado en Marte, VxWorks sí.

¿Se puede usar para aviónica crítica para la seguridad? Sí, si es escalable en tiempo real y probado de acuerdo con los estándares aplicables para toda la aviónica. Hasta donde yo sé, todavía no hay nada a bordo del avión, pero eso puede ser solo cuestión de tiempo.

Realmente no hay necesidad de tener un sistema operativo comercial en aviónica.

El software de aviónica tiende a estar diseñado para hardware específico: no existe una plataforma de hardware genérica fabricada en un mercado masivo por muchos proveedores.

La aviónica no interactúa con muchos otros sistemas o hardware.

La aviónica generalmente se ejecuta como una sola aplicación, por lo que no es necesario compartir el tiempo o, en el caso de RTOS, un programa de ciclo de reloj garantizado.

Esos son los propósitos principales de un sistema operativo en comparación con un simple cargador de arranque que carga e inicia una aplicación: el sistema operativo facilita múltiples plataformas de hardware, múltiples controladores y utilidades para almacenamiento en disco/flash, tiempo compartido con otras aplicaciones y dispositivos periféricos. como la creación de redes. Lo que debe hacer la aviónica: interactuar con la pantalla, los sensores externos y los botones de control; no es necesario que involucre un sistema operativo.

Es bueno tener un sistema operativo integrado para un dispositivo dedicado, especialmente si la aplicación integrada va a publicar servicios web para control y acceso externo. Sin embargo, es más lento de cargar (podría ser un factor para la aviónica) y consume más recursos que una aplicación dedicada que se inicia con un cargador de arranque.

Debido al extenso ciclo de certificación, la aviónica no suele ejecutar lo último y lo mejor, ni tiene un ciclo de actualización corto en el hardware.

ninguno de los argumentos intercambiados aquí es completamente incorrecto, pero desearía que algunos participantes aplicaran un poco más de esfuerzo para equilibrar sus argumentos.

Las verdaderas palabras de moda para la aviación son tiempo real y seguridad .

Por supuesto, en la aviación, la seguridad es lo primero y si necesita que suceda algo, la mayoría de las veces tiene que suceder de inmediato y algo tiene que demostrarle al piloto que el trabajo está hecho.

Antes de que pueda certificar algo, debe verificarlo y validarlo; eso puede ser un dolor de cabeza. Y es por eso que a la mayoría de la gente no le gusta eso.

Linux no es demasiado complejo para probarlo y usarlo en la aviación, pero el estilo de escritorio sí lo es. Linux en su diseño de software es bastante adecuado para su uso en aviación, como la mayoría del software compatible con Posix. La belleza de Linux es que cada componente está diseñado para hacer exactamente un trabajo y hacerlo lo mejor posible (en contraste con Windows). Para la aviación, nunca usaría un software complejo y de vanguardia como para una computadora de escritorio. Solo implementaría y probaría los elementos que realmente necesita. Y hay implementaciones en tiempo real de sistemas similares a POSIX como QNX, por ejemplo, y su arquitectura de software es muy parecida a Linux.

La perspectiva en tiempo real: una vez, Microsoft perdió una competencia en un sitio de fabricantes de acero porque no pudieron explicar cómo manejar una barra de acero de 50 toneladas, moviéndose a 6 m/s con un software que reacciona con una latencia de 500 ms. En este momento, la barra podría haber perforado la siguiente pared unos 3 m más o menos...

Este simple hecho es aún más cierto para la aviación.

Otro argumento es que la industria de la aviación es conservadora: la mayoría de las cosas que vuelan mejor tienen más de 10, a menudo 40 años.

Y en este campo a menudo se cree que no se puede ganar dinero con el software de código abierto, lo cual no es cierto. Muchos instrumentos patentados (y fiables) funcionan con software de los años noventa, es decir, muchos cajeros automáticos todavía funcionan con derivados de Windows NT. Quiero decir: muchos fabricantes de instrumentos no están dispuestos a publicar el código fuente de su software bien mantenido.

Por otro lado: si Boeing hubiera utilizado software de código abierto para su 737MAX, existe cierta probabilidad de que los accidentes no hubieran ocurrido.

Y bueno, ahí lo tiene: se trata de probar en una cantidad de tiempo aceptable.

No, más pruebas y aún más pruebas... Y luego podría terminar con un software adecuado para la aviación. Y para esto, un derivado en tiempo real de un software POSIX sería una buena opción, si no la ideal.