El rover Mars Curiosity ha aterrizado con éxito, y uno de los videos promocionales "7 minutos de terror "se jacta de que hay 500.000 líneas de código. Es un problema complicado, sin duda. Pero eso es un montón de código, seguramente hubo un gran esfuerzo de programación detrás de él. ¿Alguien sabe algo de este proyecto? Solo puedo imaginar que es una especie de C. incrustada.
Se está ejecutando 2.5 millones de líneas de C en un procesador RAD750 fabricado por BAE . El JPL tiene un poco más de información, pero sospecho que muchos de los detalles no se publican. Parece que los scripts de prueba fueron escritos en Python.
El sistema operativo subyacente es Wind River's VxWorks RTOS . El RTOS en cuestión puede programarse en C, C ++, Ada o Java. Sin embargo, solo C y C ++ son estándar para el sistema operativo, Ada y Java son compatibles con las extensiones. Wind River proporciona una gran cantidad de detalles sobre cómo y por qué VxWorks .
El conjunto de chips subyacente es casi absurdo robusto . Sus especificaciones pueden no parecer mucho al principio, pero se permite tener una y solo una "pantalla azul" cada 15 años. Tenga en cuenta que esto está bajo el bombardeo de la radiación que mataría a un humano muchas veces. En el espacio, la robustez vence a la velocidad. Por supuesto, la robustez como esa tiene un costo. En este caso, se trata de $ 200,000 a $ 500,000.
Un programador de Erlang habla sobre las características de las computadoras y el código base de Curiosity.
El código se basa en el de MER ( Spirit y Oportunidad ), que se basaron en su primer módulo de aterrizaje, MPF ( Sojourner ). Se trata de 3.5 millones de líneas de C (gran parte autogenerada), que se ejecutan en un procesador RA50 fabricado por BAE y VxWorks del sistema operativo. Más de un millón de líneas fueron codificadas a mano.
El código se implementa como 150 módulos separados, cada uno con una función diferente. Los módulos altamente acoplados se organizan en componentes que abstraen los módulos que contienen y "especifican una función, actividad o comportamiento específico". Estos componentes están organizados en capas y "no hay más de 10 componentes de nivel superior".
Fuente: Keynote talk por Benjamin Cichy en 2010 Taller sobre el software de vuelo de Spacecraft (FSW-10) , diapositivas, audio y video (comienza con el resumen de la misión, discusión de la arquitectura en la diapositiva 80).
Alguien en Hacker News preguntó: "No estoy seguro de qué significa que la mayoría del código C se genera automáticamente. ¿De qué?"
No estoy 100% seguro, aunque probablemente haya una presentación por separado en ese año o en un año diferente que describa su proceso de autogeneración. Sé que fue un tema popular en general en la conferencia FSW-11.
Simulink es una posibilidad. Es un componente de MATLAB popular entre los ingenieros mecánicos, y por lo tanto, la mayoría de los sistemas de navegación y amplificación; ingenieros de control, y les permite "codificar" y simular cosas sin pensar que están codificando.
La programación basada en modelos es definitivamente una cosa de la que la industria se está dando cuenta poco a poco, pero no sé qué tan bien se está poniendo de moda en JPL o si hubieran elegido usarlo cuando se inició el proyecto.
La tercera y más probable posibilidad es para el código de comunicación. Con todos los sistemas espaciales, debe enviar comandos al software de vuelo desde el software de tierra, y recibir telemetría del software de vuelo y procesarlo con el software de tierra. Cada paquete de comando / telemetría es una estructura de datos heterogénea, y es necesario que ambos lados trabajen desde la misma definición de paquete, y formateen el paquete para que esté correctamente formateado en un lado y analizado en el otro. Esto implica obtener una gran cantidad de cosas correctas, incluidos el tipo de datos, el tamaño y el endianness (aunque este último suele ser algo global; es posible que tenga varios procesadores integrados con endianness diferente).
Pero eso es sólo la superficie. Necesita mucho código repetitivo en ambos lados para manejar cosas como el registro, la validación de comandos / telemetría, la verificación de límites y el manejo de errores. Y luego puedes hacer cosas más sofisticadas. Supongamos que tiene un comando para establecer un valor de registro de hardware, y ese valor se envía de nuevo en telemetría en un paquete en particular. Podría generar un software de tierra que supervise ese punto de telemetría para asegurarse de que cuando se establece este valor de registro, eventualmente la telemetría cambie para reflejar el cambio. Y, por supuesto, algunos puntos de telemetría son más importantes que otros (por ejemplo, la corriente del bus principal) y están diseñados para reducirse en varios paquetes, lo que implica una copia adicional en el lado de vuelo y la deduplicación de datos en el lado de tierra.
Con todo eso, es mucho más fácil (en mi opinión) escribir una colección de archivos de texto estático (en XML, CSV o algún DSL / what-have-have), ejecutarlos a través de un script Perl / Python, y ¡presto! Código!
No trabajo en JPL, por lo que no puedo proporcionar ningún detalle que no esté en el video, con una excepción. He oído que el código C autogenerado está escrito por los scripts de Python, y la cantidad de autocodificación en un proyecto varía mucho dependiendo de quién sea el líder de FSW.
Lea otras preguntas en las etiquetas history embedded-systems space-technology