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.