31 votes

Logiciel Parcheando à un milliard de kilomètres.

Quelqu'un pourrait-il nous éclairer sur la manière dont la NASA conçoit l'architecture de ses vaisseaux spatiaux pour s'assurer qu'elle est en mesure de corriger les bogues dans le code déployé ?

Je n'ai jamais construit de systèmes de type "temps réel" et c'est une question qui m'est venue à l'esprit après avoir lu cet article :

http://pluto.jhuapl.edu/overview/piPerspective.php?page=piPerspective_05_21_2010

"Une des premières choses importantes que nous ferons lorsque nous réveillerons le vaisseau spatial la semaine prochaine la semaine prochaine sera de télécharger près de 20 mineurs corrections de bugs et autres améliorations du code à notre logiciel de protection contre les pannes (ou "réponse du pilote automatique"). ou "réponse du pilote automatique").

14voto

Cylon Cat Points 5314

J'ai été développeur de logiciels pour des systèmes de commutation téléphonique publics, qui ont des contraintes assez sévères en matière de fiabilité, de disponibilité, de survivabilité et de performance, qui s'approchent des besoins des systèmes spatiaux. Je n'ai pas travaillé sur des vaisseaux spatiaux (bien que j'aie travaillé avec de nombreux anciens programmeurs de la navette lorsque j'étais chez IBM), et je ne suis pas familier avec VXworks, le système d'exploitation utilisé sur de nombreux vaisseaux spatiaux (y compris les rovers de Mars, qui ont un record de fonctionnement phénoménal).

L'une des exigences de base pour le patchage est qu'un système doit être conçu dès le départ pour Parcheando. Cela inclut la structure des modules, de sorte que de nouvelles variables puissent être ajoutées, et des méthodes remplacées, sans perturber les opérations actuelles. Cela signifie souvent que l'ancien et le nouveau code pour une méthode modifiée seront résidents, et l'opération Parcheando met simplement à jour le vecteur de répartition pour la classe ou le module.

Il est à peu près obligatoire que le logiciel Parcheando (et un-Parcheando) soit intégré au système d'exploitation.

Lorsque je travaillais sur des systèmes téléphoniques, nous utilisions généralement Parcheando et les fonctions de remplacement de modules dans le système pour charger et tester nos nouvelles fonctionnalités ainsi que les corrections de bogues, bien avant que ces changements ne soient soumis aux builds. Chaque développeur doit être à l'aise avec Parcheando et le remplacement de modules dans le cadre de son travail quotidien. Cela construit un niveau de confiance dans ces composants, et assure que le code Parcheando et de remplacement est exercé de façon routinière.

Les tests sont beaucoup plus rigoureux sur ces systèmes que tout ce que vous avez pu rencontrer sur n'importe quel autre projet. Des maquettes complètes et partielles du système de déploiement seront facilement disponibles. Il y aura probablement aussi des environnements de machines virtuelles, où la charge complète pourra être exécutée et testée. Des plans de test à tous les niveaux au-dessus du test unitaire seront rédigés et examinés formellement, tout comme les inspections formelles du code (et celles-ci seront également de routine).

La conception de systèmes tolérants aux pannes, y compris la conception de logiciels, est essentielle. Je ne connais pas les systèmes de vaisseaux spatiaux en particulier, mais quelque chose comme des grappes à haute disponibilité est probablement standard, avec la capacité supplémentaire de fonctionner à la fois synchronisé et non synchronisé, et avec la possibilité de transférer des informations entre les côtés pendant un basculement. Un avantage supplémentaire de cette structure de système est que vous pouvez diviser le système (si nécessaire), recharger le côté inactif avec une nouvelle charge logicielle et la tester dans le système de production sans être connecté au réseau ou au bus du système. Lorsque vous êtes convaincu que le nouveau logiciel fonctionne correctement, vous pouvez simplement basculer sur celui-ci.

Comme avec Parcheando, chaque développeur devrait savoir comment faire des bascules, et devrait les faire à la fois pendant le développement et les tests. En outre, les développeurs devraient connaître chaque problème de mise à jour logicielle qui peut forcer un basculement, et devraient savoir comment écrire des correctifs et des remplacements de modules qui évitent les basculements requis chaque fois que cela est possible.

En général, ces systèmes sont conçus de A à Z (matériel, système d'exploitation, compilateurs et éventuellement langage de programmation) pour ces environnements. Je ne considère pas que Windows, Mac OSX, Linux ou toute autre variante d'Unix soient suffisamment robustes. Cela est dû en partie aux exigences du temps réel, mais la question de la fiabilité et de la capacité de survie est tout aussi importante.

UPDATE : Comme autre point d'intérêt, voici une blog d'un des pilotes du rover de Mars . Cela vous donnera une perspective sur la vie quotidienne de la maintenance d'un vaisseau spatial en fonctionnement. C'est génial !

5voto

Lie Ryan Points 24517

Je n'ai jamais construit de système en temps réel non plus, mais dans ces systèmes, je soupçonne qu'ils n'ont pas de mécanisme de protection de la mémoire. Ils n'en ont pas besoin puisqu'ils ont écrit tous leurs logiciels eux-mêmes. Sans protection de la mémoire, il sera trivial pour un programme d'écrire l'emplacement mémoire d'un autre programme et cela peut être utilisé pour corriger à chaud un programme en cours d'exécution (l'écriture d'un code auto-modifiant était une technique populaire dans le passé, sans protection de la mémoire, les mêmes techniques utilisées pour l'auto-modification du code peuvent être utilisées pour modifier le code d'un autre programme).

Linux a été capable de faire des Parcheando mineurs du noyau. sans redémarrage depuis un certain temps avec Ksplice. Ceci est nécessaire pour une utilisation dans des situations où tout temps d'arrêt peut être catastrophique. Je ne l'ai jamais utilisé moi-même, mais je pense que la technique qu'ils utilisent est essentiellement la suivante :

Ksplice peut appliquer des correctifs au noyau Linux sans redémarrer l'ordinateur. Ksplice prend en entrée un diff unifié et le code source original du noyau, et il met à jour le noyau en cours d'exécution en mémoire. L'utilisation de Ksplice ne nécessite aucune préparation avant que le système soit système (le noyau en cours d'exécution n'a pas besoin d'avoir été spécialement spécialement compilé, par exemple). Afin de générer une mise à jour, Ksplice doit déterminer quel code dans le noyau a été modifié par le code source source. Ksplice effectue cette analyse au niveau de la couche de code objet ELF, plutôt plutôt qu'au niveau du code source C.

Pour appliquer un patch, Ksplice commence par gèle l'exécution d'un ordinateur pour qu'il soit le seul programme en cours d'exécution. Le système système vérifie qu'aucun processeur n'était en train d'exécuter des fonctions qui seront modifiées par le patch. Ksplice modifie le début des fonctions modifiées afin qu'elles pointent vers de nouvelles versions mises à jour mises à jour de ces fonctions, et modifie les données et les structures en mémoire qui doivent être être modifiées. Enfin, Ksplice reprend chaque processeur là où il s'est arrêté. là où il s'est arrêté.

(extrait de Wikipédia)

3voto

Greg Points 4537

Eh bien, je suis sûr qu'ils ont des simulateurs pour faire des tests et des mécanismes pour le hot-Parcheando. Jetez un coup d'œil à l'article ci-dessous - il y a une assez bonne vue d'ensemble de la conception du vaisseau spatial. La section 5 traite de la machinerie de calcul.

http://www.boulder.swri.edu/pkb/ssr/ssr-fountain.pdf

A noter :

  • Processeurs redondants
  • Commutation des commandes par la carte de liaison montante qui ne nécessite pas l'aide du processeur.
  • Règles décalées dans le temps

2voto

Dan Bryant Points 19021

Je n'ai pas travaillé sur des vaisseaux spatiaux, mais les machines sur lesquelles j'ai travaillé ont toutes été construites pour avoir un état d'inactivité stable où il est possible d'arrêter brièvement la machine pour mettre à jour le micrologiciel. Les systèmes qui ont permis des mises à jour "en direct" sont ceux qui étaient divisés en composants en interaction, où vous pouvez arrêter un segment du système suffisamment longtemps pour le mettre à jour et les autres composants peuvent continuer à fonctionner normalement, car ils peuvent tolérer l'arrêt temporaire du composant entretenu.

L'un des moyens d'y parvenir est de disposer de capacités parallèles (redondantes), comme des machines parallèles qui effectuent toutes la même tâche, de sorte que le processus puisse être acheminé autour de la machine en service. L'avantage de cette approche est que vous pouvez l'arrêter pendant de plus longues périodes pour des services plus importants, comme la maintenance préventive régulière du matériel. Une fois que vous avez cette capacité, la prise en charge des temps d'arrêt pour une mise à jour du micrologiciel est assez facile.

1voto

Paul Nathan Points 22910

L'une des approches utilisées dans le passé est l'utilisation de LISP.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X