Quel est le logiciel intégré au Mars Curiosity Rover?

Le rover Mars Curiosity a atterri avec succès et l'une des vidéos promotionnelles "7 minutes de terreur" se vante de l'existence de 500 000 lignes de code. C'est un problème compliqué, sans doute. Mais c'est beaucoup de code, il y avait sûrement un gros effort de programmation derrière. Est-ce que quelqu'un sait quelque chose sur ce projet? Je peux seulement imaginer que c'est une sorte de C. intégré

Il exécute 2,5 millions de lignes de C sur un processeur RAD750 fabriqué par BAE . Le JPL a un peu plus d'informations mais je suppose que beaucoup de détails ne sont pas publiés. Il semble que les scripts de test aient été écrits en Python.

Le système d'exploitation sous-jacent est le RTOS VxWorks de Wind River . Le RTOS en question peut être programmé en C, C ++, Ada ou Java. Cependant, seuls les systèmes C et C ++ sont standard pour le système d'exploitation, Ada et Java sont pris en charge par les extensions. Wind River fournit énormément de détails sur le comment et le pourquoi de VxWorks .

Le chipset sous-jacent est presque absurdement robuste . Ses caractéristiques peuvent ne pas sembler beaucoup au début, mais il est autorisé à avoir un et un seul "écran bleu" tous les 15 ans. Rappelez-vous que cet engin est sous le bombardement de radiations qui tueraient plusieurs fois un être humain. Dans l'espace, la robustesse l'emporte sur la vitesse. Bien sûr, une telle robustesse a un coût. Dans ce cas, il s’agit d’une somme modique de 200 000 $ à 500 000 $.

Un programmeur Erlang parle des fonctionnalités des ordinateurs et de la base de code sur Curiosity.

Le code est basé sur celui de MER ( Spirit and Opportunity ), basé sur leur premier atterrisseur, MPF ( Sojourner ). Il s'agit de 3,5 millions de lignes de C (en grande partie auto-générées), fonctionnant sur un processeur RA50 fabriqué par BAE et le système d' exploitation VxWorks . Plus d'un million de lignes ont été codées à la main.

Le code est mis en œuvre sous la forme de 150 modules distincts, chacun remplissant une fonction différente. Les modules fortement couplés sont organisés en composants qui résument les modules qu’ils contiennent et "spécifient une fonction, une activité ou un comportement spécifique". Ces composants sont en outre organisés en couches et il n’ya «pas plus de 10 composants de premier niveau».

Source: Exposé principal de Benjamin Cichy à l' atelier 2010 sur les logiciels de vol des engins spatiaux (FSW-10) , diapositives, audio et vidéo (commence par une vue d'ensemble de la mission et une discussion sur l'architecture à la diapositive 80).

Quelqu'un sur Hacker News a demandé "Je ne suis pas sûr de ce que signifie que la plupart du code C est généré automatiquement. De quoi?"

Je ne suis pas sûr à 100%, bien qu'il y ait probablement une présentation séparée cette année-là ou une année différente décrivant leur processus d'auto-génération. Je sais que c'était un sujet populaire en général à la conférence FSW-11.

Simulink est une possibilité. C'est un composant MATLAB populaire parmi les ingénieurs en mécanique, et donc la plupart des ingénieurs en navigation et contrôle, et qui leur permet de «coder» et de simuler des choses sans penser à ce qu'ils codent.

La programmation basée sur un modèle est certainement une chose dont l’industrie commence lentement à prendre conscience, mais je ne sais pas dans quelle mesure elle réussit à comprendre JPL ou s’ils auraient choisi de l’utiliser lorsque le projet a démarré.

La troisième et la plus probable des possibilités concerne le code de communication. Avec tous les systèmes spatiaux, vous devez envoyer des commandes au logiciel de vol à partir du logiciel au sol, recevoir une télémétrie à partir du logiciel de vol et la traiter avec le logiciel au sol. Chaque paquet de commande / télémétrie est une structure de données hétérogène, et il est nécessaire que les deux côtés travaillent avec la même définition de paquet, et formatez le paquet de sorte qu'il soit correctement formaté d'un côté et analysé de l'autre. Cela implique de définir un grand nombre d'éléments, y compris le type de données, la taille et le caractère final (bien que ce dernier soit généralement global; vous pouvez avoir plusieurs processeurs intégrés avec un caractère différent).

Mais ce n'est que la surface. Vous avez besoin de beaucoup de code répétitif des deux côtés pour gérer des tâches telles que la journalisation, la validation des commandes / télémétrie, la vérification des limites et la gestion des erreurs. Et alors vous pouvez faire des choses plus sophistiquées. Supposons que vous ayez une commande pour définir une valeur de registre matériel et que cette valeur soit renvoyée en télémétrie dans un paquet particulier. Vous pouvez générer un logiciel au sol qui surveille ce point de télémétrie pour vous assurer que lorsque cette valeur de registre est définie, la télémétrie est modifiée pour refléter le changement. Et bien sûr, certains points de télémétrie sont plus importants que d’autres (par exemple, le courant de bus principal) et sont conçus pour descendre en plusieurs paquets, ce qui implique une copie supplémentaire du côté vol et une déduplication des données du côté sol.

Avec tout cela, il est beaucoup plus facile (à mon avis) d'écrire une collection de fichiers texte statiques (au format XML, CSV ou quelque DSL / what-have-you), de les exécuter à l'aide d'un script Perl / Python et le tour est joué! Code!

Je ne travaille pas chez JPL, je ne peux donc fournir aucun détail qui ne soit pas dans la vidéo, à une exception près. J'ai entendu dire que le code C généré automatiquement est écrit par des scripts Python et que la quantité de codage automatique dans un projet varie considérablement en fonction du responsable de FSW.