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 aucun doute. Mais c'est beaucoup de code, il y avait sûrement un gros effort de programmation derrière. Quelqu'un connaît-il ce projet? Je peux seulement imaginer que c'est une sorte de C. intégré.
Il fonctionne 2,5 millions de lignes de C sur un processeur RAD75 fabriqué par BAE . Le JPL a un peu plus d'informations mais je soupçonne que beaucoup de détails ne sont pas rendus publics. Il semble que les scripts de test aient été écrits en Python.
Le système d'exploitation sous-jacent est Wind River'sVxWorks RTOS . Les RTOS en question peuvent être programmés en C, C++, Ada ou Java. Cependant, seuls C et C++ sont standard pour le système d'exploitation, Ada et Java sont pris en charge par les extensions. Wind River fournit une quantité énorme de détails sur les modalités et les raisons de VxWorks .
Le chipset sous-jacent est presque absurde robuste . Ses spécifications peuvent ne pas sembler beaucoup au premier abord, mais il est autorisé à avoir un et un seul "écran bleu" tous les 15 ans. Gardez à l'esprit que cela est sous le bombardement de radiations qui tueraient un humain plusieurs fois. Dans l'espace, la robustesse l'emporte sur la vitesse. Bien sûr, une telle robustesse a un coût. Dans ce cas, c'est 200 000 $ à 500 000 $.
Un programmeur Erlang parle sur les fonctionnalités des ordinateurs et de la base de code sur Curiosity.
Le code est basé sur celui de MER ( Spirit et Opportunity ), qui étaient basés sur leur premier atterrisseur, MPF ( Sojourner ). Il s'agit de 3,5 millions de lignes de C (dont une grande partie autogénérée), exécutées 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 implémenté en 150 modules distincts, chacun remplissant une fonction différente. Les modules hautement couplés sont organisés en composants qui font abstraction des modules qu'ils contiennent et "spécifient soit une fonction, une activité ou un comportement spécifique". Ces composants sont davantage organisés en couches, et il n'y a "pas plus de 10 composants de niveau supérieur".
Source: Discours liminaire par Benjamin Cichy à 2010 Workshop on Spacecraft Flight Software (FSW-10) , slides, audio, and video (commence par aperçu de la mission, discussion sur l’architecture à la diapositive 80).
Quelqu'un sur Hacker News a demandé "Je ne sais pas ce qui 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 distincte cette année-là ou une autre année qui décrit leur processus de génération automatique. Je sais que c'était un sujet populaire en général lors de la conférence FSW-11.
Simulink est une possibilité. C'est un composant MATLAB populaire parmi les ingénieurs mécaniciens, et donc la plupart des ingénieurs de navigation et de contrôle, et leur permet de `` coder '' et de simuler des choses sans penser qu'ils codent.
La programmation basée sur des modèles est définitivement une chose que l'industrie prend lentement conscience, mais je ne sais pas à quel point elle se propage à JPL ou si elle aurait choisi de l'utiliser lors du démarrage du projet.
La troisième possibilité, la plus probable, 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 la télémétrie 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 à partir de la même définition de paquet exacte, et formatent le paquet afin qu'il soit correctement formaté d'un côté et analysé de l'autre côté. Cela implique de faire bien des choses, y compris le type de données, la taille et l'endianité (bien que ce dernier soit généralement une chose globale; vous pouvez avoir plusieurs processeurs à bord avec une endianité différente).
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 choses comme la journalisation, la validation de commande/télémétrie, la vérification des limites et la gestion des erreurs. Et puis 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 est 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 change éventuellement 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 côté sol.
Avec tout cela, il est beaucoup plus facile (à mon avis) d'écrire une collection de fichiers texte statiques (en XML, CSV ou certains DSL/what-have-you), de les exécuter via un script Perl/Python, et hop! Code!
Je ne travaille pas au JPL, je ne peux donc pas fournir de détails qui ne figurent 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 la quantité d'autocodage dans un projet varie considérablement en fonction de l'identité du responsable FSW.