¿Por qué se usa Python en aviones aunque no sea certificable?

Recientemente tuve una conversación con personas activas en la industria de la aviación y me dijeron que uno de los principales lenguajes/herramientas que usan es Python.

Por otro lado, siempre he sabido que la gente evita C++ o, por ejemplo , Linux por razones de certificación de aviónica. La certificación también es una de las razones por las que no ve la IA y la visión artificial en C++ en los aviones. Sin embargo, esas personas usan Python todo el tiempo.

No tuve (y nunca tendré) la oportunidad de preguntar por qué y para qué lo usaron. ¿Alguien podría explicar por qué y para qué la gente seguiría usando Python aunque puede ser muy difícil obtener la certificación?

hay más computadoras en un avión que aviónica, especialmente en un avión comercial. también hay más computadoras en la industria que en un avión. pueden escribir su sitio web en php, su servidor de reservas en cobol, información y entretenimiento en java o base de datos en sql, lo que sea.
Además, el hecho de que lo usen no significa que lo usen en el avión . Trabajo en software integrado (menos crítico) y todo el sistema de prueba está escrito en Python, aunque el software real está en C.
¿A qué te refieres con certificado?
Esto es rogar por una broma de 'serpientes en un avión'....
@LangeHaare Prácticamente todo lo que se incluye en el diseño de una aeronave debe estar certificado por las autoridades de aviación pertinentes antes de que la aeronave pueda volar legalmente. Los sistemas críticos para la seguridad, como el código que ejecuta los controles de vuelo, requieren el cumplimiento de estándares de certificación bastante estrictos.
Para agregar un comentario adicional sobre C++, Lockheed escribió específicamente un estándar de codificación para su uso en el programa F-35: stroustrup.com/JSF-AV-rules.pdf . Así que sí, se usa C++.
"... me dijeron que uno de los principales lenguajes/herramientas que usan es Python..." ¿Pero para qué? La pregunta realmente debería extenderse para incluir esa información vital. De lo contrario, me temo que será demasiado especulativo.
@reirab, ¿por qué C ++ y Linux serían certificables? Me parece razonable poder certificar el software.
@tuskiomi Depende del tipo de código en cuestión. ¿Utiliza Linux en el sistema de entretenimiento a bordo para pasajeros? No es un problema. ¿Usarlo en las computadoras que ejecutan el sistema fly-by-wire? Problema mucho mayor. Entre otras cosas, el no determinismo será un problema. El tiempo es inherentemente no determinista en un sistema operativo con multitarea preventiva. RTOS o bare metal suelen ser las únicas opciones viables para tales escenarios. La asignación de memoria dinámica también es inherentemente no determinista (a menos que sepa exactamente cada asignación que ocurrirá y en qué orden).

Respuestas (3)

El hecho de que los desarrolladores de aviación usen Python no significa que Python realmente salga volando.

Gran parte del desarrollo de la aviación consiste en probar, estresar, validar, analizar y documentar el código que sale volando.

Python es un lenguaje excelente para todo ese trabajo de validación, aunque se queda en el suelo.

Sí, Python es un lenguaje de secuencias de comandos común que se utiliza con equipos de prueba automatizados. Los lenguajes principales que conozco que realmente vuelan son Ada/SPARK, C/C++ y ensamblador
@selectstriker2 C++ ¿estás seguro de eso? Estaba bastante seguro de que las empresas también tenían algunos problemas con la certificación de ese idioma. Como ejemplo: las personas que hacen IA y visión por computadora para UAV escriben todo su código en el plano C en lugar de usar las conocidas bibliotecas de código abierto como openCV.
No es el idioma lo que causa problemas de certificación. Cosas como la memoria dinámica, el manejo de excepciones, la herencia y la sobrecarga de funciones pueden aumentar la cantidad de trabajo de certificación (verificación) necesario. La mayor carga de certificación es cuando usa un RTOS en lugar de escribir para bare metal.
Estoy seguro de que se está utilizando mucho C++ en proyectos DO-178B/C en el nivel D o el nivel E.
Y el hecho de que el código esté volando no significa que sea crítico para la seguridad. En estos días, la gente está usando iPads como parte de su configuración de aviónica: ¡IPADS! Pero estos se usan normalmente para la navegación y la cartografía: el iPad nunca puede controlar las superficies de control, el tren de aterrizaje ni nada mecánico.
Hay directrices completas publicadas para el desarrollo de software en C y C++. Estos prohíben el uso de las partes más "problemáticas" de los idiomas. Consulte misra.org.uk/Publications/tabid/57/Default.aspx . Ada "parecía una buena idea en ese momento", pero nunca se ha convertido en un lenguaje convencional, lo que significa que la base de usuarios es (probablemente insosteniblemente) pequeña, a menos que crea que tiene un futuro a largo plazo del que quiere ser parte, lo más probable es que evite involucrarse con él.
@LandonZeKepitelOfGreytBritn: "Plane C": ¿es una broma deliberada? :-)
@psmears Dado el enlace de alephzero, de hecho hay un subconjunto de C que podría considerarse "plano C".
Como nota al margen, parte del software de verificación tiene que estar calificado formalmente bajo DO-330. La regla general es que si el software automatiza los procesos de certificación DO-178 y no se revisa el resultado de la herramienta, debe realizar un proceso de calificación para demostrar que su software es confiable.
¡Por supuesto que Python sale volando! importar antigravedad
@selectstriker2 Algunos lenguajes básicamente fuerzan la asignación de memoria dinámica, te guste o no. Pitón es uno de ellos.
@PeterGreen Por eso no usaría Python en aplicaciones críticas para la seguridad. Estaba hablando de usar C++, que se puede usar, pero debe considerar los elementos que enumeré.
@selectstriker2 Je, de acuerdo. Los chicos de QNX y C/MISRA que trabajan en automoción ni siquiera pueden conseguir C++ en los vehículos, a pesar de los esfuerzos considerables. ¿Pitón? El edificio se reiría de la propuesta, ya que no se acercará a cumplir con las especificaciones de seguridad, certificados, etc.
Trabajé para un subcontratista de aviónica. Usamos C para todo el software de controles y python para hardware en la prueba de caja negra de bucle TODO. ~80%-90% de todo el código escrito fue código de prueba de Python. Cada línea de C tenía cientos de líneas de python probándola.
@selectstriker2 casi todas las características del lenguaje de C++ sobre c causan problemas de determinismo. Eso, junto con compiladores impredecibles y no certificados, significa que no tiene sentido escribir en un idioma en el que debe estar constantemente atento para asegurarse de que no se utilicen las características del idioma.d

Como ingeniero de software que trabaja en una empresa de defensa que desarrolla y vende sistemas de misión crítica (pero no críticos para la seguridad), puedo confirmar que hay una división bastante pareja entre el desarrollo en Ada (95) para nuestros productos heredados y varios tipos de C/ C++ para nuestros nuevos productos. El desarrollo en ambos se hace, por supuesto, con los estándares apropiados.

Python se limita en gran medida a complementos para nuestros IDE o actividades de validación y verificación (utilizados tanto por ingenieros de software como de sistemas).

Disfruté mucho de Ada 83 cuando se enseñó en mi universidad, en parte para crear un campo de juego nivelado para los estudiantes. Descubrí que cuando aproveché bien sus características, mis programas tenían muchas menos probabilidades de bloquearse que con C o C++. Encuentro especialmente C++ extraordinariamente problemático como lenguaje (y lo he estado usando durante más de 20 años, y leí los últimos tres estándares, bueno, tal vez por eso). C no es exactamente seguro, pero al menos es un lenguaje pequeño que es fácil de comprender por completo (el lenguaje, no las bibliotecas). Entonces, ¿Ada está realmente eliminada incluso en aviónica? Eso sería triste.
He trabajado en software de aviónica crítico para la seguridad durante los últimos 10 años más o menos, y en ese tiempo nunca he visto a Ada en uso. Sé que algunas empresas grandes pueden usarlo para algunos proyectos, pero no se enseña en la mayoría de las universidades. C/C++ tiende a ser el lenguaje bare metal más enseñado.
@Peter La gente de SPARK/Ada afirma que se usa en los motores EuroFighter y Rolls-Royce. Me gusta mucho la idea de la demostrabilidad del lenguaje, pero definitivamente parece una característica de nicho.
@mbrig Me parece divertido que el ADA desarrollado por el DOD de EE. UU. se esté utilizando en los motores EuroFighter y los británicos (bueno, más o menos ... OK solo de nombre) Rolls-Royce.
@FreeMan Me imagino que EuroFighter y Rolls también usan Internet desarrollado por el Departamento de Defensa de EE. UU. :) DoD desarrolla muchas cosas.
@mbrig Actualmente trabajando en el Eurofighter, así que puedo confirmar que todo está sobre el Typhoon (y el Tornado). Creo que fue ordenado por el MOD hace mucho tiempo.
@PeterA.Schneider: Un problema importante con C es que, si bien el estándar señala que las implementaciones a menudo exponen de manera útil las características documentadas del entorno de ejecución en los casos en que el estándar no impondría requisitos, y la programación de bajo nivel a menudo requiere el uso de tales características, no existe un medio estándar por el cual el código pueda indicar que requiere, por ejemplo, la capacidad de usar operaciones relacionales para probar si dos punteros identifican regiones de almacenamiento superpuestas. Los sistemas de direcciones lineales generalmente definirán una relación de ordenación transitiva global entre todos los punteros...
... pero los compiladores de dichos sistemas a veces pueden decidir que, dado que el estándar no impone requisitos sobre lo que sucede si el código compara dos punteros no relacionados, deben asumir que el código nunca lo hará.
Es por eso que probamos y verificamos todo, solo asegúrese de que el compilador no haya generado un código de máquina que se comporte de manera diferente a lo esperado.

Hay tres áreas básicas de codificación para ingenieros de aviación. Código de software que se ejecuta en computadoras de vuelo y otros equipos de aviónica, software que verifica y crea formalmente ese código y secuencias de comandos para automatizar tareas de trabajo informales. Python tiene diferentes casos de uso en todos ellos.

Primero, para el software real en el avión. Hay diferentes niveles de seguridad aquí y diferentes niveles requeridos de prueba. Python sería una pesadilla para certificar una pantalla crítica, un piloto automático o una unidad de advertencia de proximidad al suelo. La falta de programación orientada a objetos de C y las quejas cuando se abusa de los tipos de variables pueden ser molestas, pero también facilitan la verificación de que el software no está haciendo nada malo a sus espaldas. Por otro lado, he oído hablar de sistemas no críticos como entretenimiento y mantenimiento a bordo, incluso utilizando sistemas como Windows NT.

La generación de código y la verificación formal (del tipo que está documentado para demostrar a las autoridades de certificación que no matarás a nadie), a veces tienen que estar calificados formalmente. No puede simplemente escribir una secuencia de comandos de Python para probar todo su software mediante simulación, métodos formales, etc., y luego decirle a las autoridades de certificación que su secuencia de comandos de Python no mostró problemas. Para ser más específicos, DO-330 brinda orientación de que si está utilizando una herramienta para reemplazar los procesos DO-178 (como pruebas, generación de código o control de configuración), entonces esa herramienta debe calificarse formalmente o su salida debe ser verificado (sí, incluso si la salida es más infalible que un humano que hace el mismo análisis).

Finalmente, muchos trabajos de los ingenieros implican la creación de secuencias de comandos, y hay pocos lenguajes más populares en este momento para la creación de secuencias de comandos que python. Por secuencias de comandos me refiero a resolver problemas como:

  • ¿En qué temas estoy trabajando en esta área?
  • ¿Cómo agrego una descripción a cien archivos a la vez?
  • ¿Es este criterio estadísticamente diferente de ese criterio?
  • ¿Cómo puedo extraer cientos de líneas de datos de nuestra base de datos y volcarlos en una hoja de cálculo para mi ingeniero de proyectos?
  • ¿Cómo puedo enviarle un correo electrónico a mi jefe todos los días para pedirle una promoción?

En estos asuntos no críticos pero cotidianos, las secuencias de comandos de Python pueden ayudar a resolver muchas tareas complejas o repetitivas y hacerlas manejables.

He visto más de unas pocas terminales de aeropuerto con Win NT, ¡se nota por el BSOD! (Sí, he visto algunos). Por supuesto, eso está relacionado con la aviación, pero no es específico de un avión.
¡Seguro que pasamos una buena parte del tiempo escribiendo elegantes hojas de cálculo de Excel llenas de VBA para procesar datos!
... piratea ese guión de promoción
"La falta de programación orientada a objetos de C y las quejas cuando se abusa de los tipos de variables pueden ser molestas, pero también facilitan la verificación de que el software no está haciendo nada malo a sus espaldas". Um... C es horrible para verificar cualquier cosa, realmente quieres un sistema de tipos más fuerte para eso. Java, C++, obviamente Ada, todos tienen una mejor posición aquí, por no hablar de los sistemas de tipos realmente fuertes que ofrecen lenguajes como O'Caml, Haskell o Idris. E incluso Python podría decirse que es más seguro que C porque su sistema de tipos es más fuerte.
(Supongo que tiene razón, aunque ese código C que esencialmente usa el subconjunto Fortran77 del lenguaje se puede verificar bastante bien, pero es extremadamente doloroso escribirlo).
Me gusta cómo pones "¿Cómo puedo enviarle un correo electrónico a mi jefe todos los días para pedirle un ascenso?" como un problema que necesita un guión para resolver. Asegúrese de que en esos correos electrónicos señale las virtudes de la automatización. :-)
@leftaroundabout Sí, C tiene mucho espacio para errores como el manejo de NaN, la inicialización y las estructuras de memoria, pero, por lo general, la generación de código para ellos se configura de manera lo suficientemente consistente como para evitar problemas (como evitar la asignación dinámica y las protecciones contra la división por cero). La programación orientada a objetos y la escritura suelta, por otro lado, requieren muchas pruebas complejas de cobertura estructural porque es posible que lo que cree que es un Foo sea en realidad una barra insidiosa. Ver CAST-17 por ejemplo.
@CodyP bueno, escribir libremente es lo que quise decir principalmente con "C es horrible para verificar cualquier cosa". Nuevamente, la verdad es que, siempre que básicamente escriba Fortran77 en C, es razonablemente rígido. Pero tan pronto como quiera hacer algún tipo de polimorfismo, C no lo ayudará en absoluto y tendrá que pasar por void*cuál es el tipeo más flexible que puede obtener. Y sin ningún polimorfismo, es muy difícil adherirse a DRY, que en principio es muy deseable por seguridad.
C++ OTOH permite una gran cantidad de reutilización de código a través de plantillas, que no se basan en ningún subtipo peligroso y es completamente verificable en tiempo de compilación. Y los lenguajes Hindley-Milner generalmente resuelven todos los polimorfismos en tiempo de compilación y nunca hacen ninguna coerción implícita. Acerca de Java o C#... No estoy seguro; ciertamente no son la opción más segura, pero al menos están diseñados por adelantado con conocimiento de los subtipos OO y sus posibles ramificaciones de seguridad.