¿En qué está integrado el software Mars Curiosity Rover?

El rover Mars Curiosity ha aterrizado con éxito, y uno de los videos promocionales "7 minutes of terror" se jacta de que hay 500,000 líneas de código. Es un problema complicado, sin duda. Pero eso es mucho código, seguramente hubo un gran esfuerzo de programación detrás de él. ¿Alguien sabe algo sobre este proyecto? Solo puedo imaginar que es algún tipo de C. incrustado

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 publicitan. Parece que los scripts de prueba fueron escritos en Python.

El sistema operativo subyacente es VxWorks RTOS de Wind River . El RTOS en cuestión se puede programar 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 extensiones. Wind River proporciona una gran cantidad de detalles en cuanto a cómo y por qué de VxWorks .

El chipset subyacente es casi absurdamente robusto . Sus especificaciones pueden no parecer mucho al principio, pero se le permite tener una y solo una "pantalla azul" cada 15 años. Tenga en cuenta que esto está bajo el bombardeo de radiación que mataría a un humano muchas veces. En el espacio, la robustez gana a la velocidad. Por supuesto, la robustez como esa tiene un costo. En este caso, es genial $ 200,000 a $ 500,000.

Un programador de Erlang habla sobre las características de las computadoras y la base de código en Curiosity.

El código se basa en el de MER ( Spirit and Opportunity ), que se basó en su primer módulo de aterrizaje, MPF ( Sojourner ). Son 3,5 millones de líneas de C (gran parte de ellas autogeneradas), que se ejecutan en un procesador RA50 fabricado por BAE y el sistema operativo VxWorks . 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 realizando 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 se organizan en capas y "no hay más de 10 componentes de nivel superior".

Fuente: Charla magistral de Benjamin Cichy en el Taller 2010 sobre software de vuelo de naves espaciales (FSW-10) , diapositivas, audio y video (comienza con una descripción general de la misión, discusión de 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 un año diferente que describa su proceso de generación automática. 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 ingenieros de navegación y control, y les permite 'codificar' y simular cosas sin pensar que están codificando.

La programación basada en modelos es definitivamente algo de lo que la industria se está dando cuenta lentamente, pero no sé qué tan bien se está dando cuenta en JPL o si hubieran elegido usarlo cuando comenzó 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 exactamente desde la misma definición de paquete, y formatee el paquete para que esté formateado correctamente en un lado y analizado en el otro lado. Esto implica hacer un montón de cosas correctas, incluido el tipo de datos, el tamaño y la resistencia (aunque esto último suele ser una cuestión global; podría tener múltiples procesadores a bordo con diferente capacidad).

Pero esa es solo 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 devuelve en telemetría en un paquete en particular. Podría generar un software de tierra que supervise ese punto de telemetría para garantizar 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 designados para reducirse en múltiples paquetes, lo que implica una copia adicional en el lado del vuelo y la desduplicación de datos en el lado del suelo.

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-you), ejecutarlos a través de un script Perl / Python, ¡y listo! ¡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 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.