500 millions de dollars par ligne de code ou le coût des erreurs logicielles dans l'espace
Il y a quelques mois sur edx.org, le cours «Introduction aux technologies spatiales: astronautique et vols habités (Fin de l'ingénierie aérospatiale: astronautique et vols spatiaux humains)» a pris fin. Le cours a été dispensé par un astronaute américain, actuellement professeur au MIT - Jeffrey Alan Hoffman. Comme son nom l'indique, le cours est assez simple et général, cependant il m'a semblé plutôt intéressant et instructif.Dans une partie du cours, la question de la sécurité est abordée et, entre autres, nous parlons de la sécurité des logiciels. Prof. Hoffman fournit des exemples intéressants de problèmes avec les logiciels pour l'aviation et l'astronautique. Dans cet article, j’examinerai de plus près les exemples spatiaux tirés des conférences de Hoffmann.Atterrisseur polaire de Mars
Mars Polar Lander (MPL) Un vaisseau spatial de 290 kilogrammes lancé par la NASA le 3 janvier 1999 pour étudier le sol et le climat autour du pôle Sud de Mars. Le 3 décembre 1999, lors de l'atterrissage, le centre de contrôle n'a pas pu reprendre la communication avec l'appareil.
MPL au NASA LabAvec des poteaux d'atterrissage ouverts et des panneaux solaires, le MPL mesurait 1,06 m de haut et avait une taille transversale de 3,6 m. Le corps est fabriqué sur la base d'une structure en nid d'abeille en aluminium fixée avec des panneaux graphite-époxy. Lors de l'atterrissage, trois supports en aluminium sont ouverts depuis la position de transport et éteignent l'énergie d'atterrissage à l'aide d'inserts en aluminium destructibles fabriqués sous forme de nids d'abeilles.Cours d'atterrissage prévu
Le MPL pénètre dans l'atmosphère de Mars à une altitude de plus de 100 km à une vitesse de ~ 7 km / s. En 3 minutes, l'appareil descend à une altitude de 8,8 km et ralentit à une vitesse de 0,5 km / s, après quoi il donne un signal pour ouvrir le parachute, qui suit immédiatement après la séparation du bouclier thermique. Lorsque la vitesse de l'appareil est réduite à 85 m / s à l'aide d'un parachute, un radar commence à fonctionner, qui surveille les caractéristiques de la surface pour déterminer le site d'atterrissage possible.
Diagramme des étapes de vol MPL1 min après l'ouverture du parachute à une altitude de 1,3 km, lorsque la vitesse de descente est de 80 m / s, le véhicule de descente est séparé du boîtier extérieur avec un parachute (coque arrière) et commence à atterrir sur les moteurs-freins. Le temps de descente prévu, avec les moteurs en marche, est d'environ 1 min, période pendant laquelle l'appareil diminue à une hauteur de 12 m, puis les moteurs s'arrêtent et l'appareil fait une chute prévue à la surface. 5 minutes après avoir touché la surface, l'appareil commence à déployer les panneaux solaires et l'orientation de l'antenne, ce qui établira une connexion avec la Terre. Commence alors la session de transfert de données, signalant que l'atterrissage a réussi.Le déroulement des événements
Le 3 décembre, le véhicule de descente s'est désamarré de l'étape de croisière et, jusqu'à l'atterrissage, est passé au mode de silence radio prévu. A 20:04:00 UTC, 6 minutes avant d'entrer dans l'atmosphère, le fonctionnement programmé des moteurs a corrigé la position de l'appareil, orientant l'écran thermique. MPL est entré dans l'atmosphère de Mars à une vitesse de 6,9 km / s à 20:10:00 UTC. La reprise des communications était attendue à 20:39:00 UTC après l'atterrissage. Mais la connexion n'a jamais été établie et l'appareil a été déclaré perdu.La raison exacte de la perte de communication est inconnue, mais le rapport d'enquête sur l'accident conclut que la cause la plus probable de l'accident est une erreur logicielle qui a mal calculé les vibrations lors de l'ouverture des supports en tant que vibrations de l'atterrissage. En conséquence, le dispositif a coupé les moteurs de frein à une hauteur de 40 m, malgré le fait que l'on savait que la divulgation des supports pouvait conduire à des faux positifs. Le mandat du logiciel ne prévoyait pas ce cas.Citation du rapport:«Des capteurs magnétiques montés sur chacun des trois supports d'atterrissage permettent de déterminer le moment de contact avec le sol et d'arrêter les moteurs d'atterrissage. Les données obtenues lors de plusieurs tests ont montré que dans les capteurs d'atterrissage (capteurs Hall) de fausses alarmes se produisent lors de la divulgation des supports (à ce moment le dispositif descend en parachute). La logique du programme reçoit les données des capteurs comme un signal de démarrage si des déclenchements se produisent lors de deux lectures consécutives. Des tests ont montré que les signaux à court terme qui se produisent lorsque les supports sont ouverts sont en fait suffisamment longs pour provoquer un faux positif. Presque toujours, l'un des trois piliers a généré un faux signal, que le programme a pris comme signal d'atterrissage.Le logiciel, qui était censé ignorer les réponses des capteurs jusqu'au moment où l'algorithme de détection de contact avec le sol était activé, était mal organisé et de fausses réponses étaient stockées dans le système. Dès que l'algorithme de détermination du toucher de la terre a été activé à une altitude de 40 m, le programme a immédiatement émis une commande d'arrêt des moteurs d'atterrissage.À une altitude de 40 m, le taux de descente du véhicule était d'environ 13 m / s (47 km / h), ce qui, sans la poussée des moteurs-freins, a augmenté à 22 m / s (80 km / h) près de la surface sous l'influence de la gravité de Mars, la vitesse de décroissance estimée était de 2,4 m / s (9 km / h). À une telle vitesse de collision avec la surface, l'appareil n'a pas pu survivre. »Si vous regardez l'algorithme du programme, vous pouvez voir qu'une ligne de réinitialisation de l'état de la variable IndicatorState à la valeur FALSE initiale pourrait sauver l'appareil, ce qui a coûté 328 millions de dollars à la NASA.Ariane 5
Le 4 juin 1996, le premier lancement du nouveau lanceur Ariane 5 développé par l'Agence spatiale européenne (ESA) a eu lieu. Le lancement s'est soldé par un échec - la fusée s'est écrasée à la 39e seconde du vol en raison d'un mauvais fonctionnement du logiciel embarqué.
Le lancement du premier Ariane 5Ariane 5 est le lanceur européen de la famille Ariane. Les lancements ont lieu au cosmodrome de Kourou en Guyane française. Le développement d'Ariane 5 a duré 10 ans, a coûté 7 milliards de dollars et devait remplacer le lanceur Ariane 4.Lancé en 1996, un lanceur d'une masse de 720 tonnes devait lancer quatre satellites d'une masse de 1,2 tonne chacun. Tournant chacun sur sa propre orbite, ces satellites forment un tétraèdre et travaillent en groupe, c'était le projet European Cluster pour étudier le champ magnétique terrestre (plus tard en 2000, quatre nouveaux satellites pour le programme Cluster-II ont été mis en orbite avec succès par deux lanceurs Soyouz) .Le déroulement des événements
Avant de décrire l'incident, il convient de noter que la conception du système de navigation (Inertial Reference System - SRI) pour Ariane 5 est presque identique à celle d'Ariane 4, notamment en ce qui concerne les logiciels.Le moment de début est noté H0. Les opérations précédant le départ se sont déroulées en mode normal jusqu'au moment H0 - 7 minutes, lorsque la violation du «critère de visibilité» a été enregistrée. Par conséquent, le départ a été reporté d'une heure.À H0 = 12:33:59 UTC, un lancement a été effectué, ce qui s'est produit normalement jusqu'au moment de H0 + 37 sec. Dans les secondes qui ont suivi, une forte déviation de la fusée par rapport à un chemin donné s'est produite, puis une explosion a suivi.
Le moment de l'explosion d'Ariane 5 lors du premier lancementDonc: pour le moment H0 + 39 sec. après le lancement, en raison de la charge aérodynamique élevée due au dépassement de l '"angle d'attaque" de la valeur critique, les accélérateurs de lancement de la fusée ont été séparés de son étage principal, qui a servi de base à l'inclusion du système d'auto-allumage de la fusée.Le changement de l'angle d'attaque s'est produit en raison d'une rotation anormale des buses des propulseurs à carburant solide, une telle déviation des buses des accélérateurs a provoqué une commande émise par l'ordinateur de bord sur la base des informations du système de navigation SRI 2. Certaines de ces informations à l'époque étaient incorrectes: ce qui a été interprété comme des données de vol était en fait en fait, ce sont les informations de diagnostic de l'ordinateur intégré du système SRI 2. L'ordinateur intégré SRI 2 a transmis des données incorrectes car il a diagnostiqué une situation anormale en "interceptant" une exception levée par l'un des modules logiciels. Dans le même temps, l'ordinateur de bord n'a pas pu passer au système de sauvegarde SRI 1, car il avait déjà cessé de fonctionner lors du cycle précédent (période de 72 ms). Pour la même raison que SRI 2.L'exception "levée" par l'un des modules logiciels SRI était le résultat de la conversion des données d'un format à virgule flottante 64 bits en un entier signé 16 bits, ce qui a conduit à une erreur d'opérande. Une erreur s'est produite dans un composant logiciel conçu uniquement pour effectuer le «réglage» d'une plate-forme inertielle embarquée. De plus - cela semble paradoxal, mais ce module de programme ne donne des résultats significatifs que jusqu'à ce que la fusée casse la rampe de lancement. Après le décollage de la fusée, ce module n'a aucun effet sur le vol. Mais la fonction de réglage, conformément aux exigences établies pour elle, doit agir pendant 50 secondes supplémentaires. après le lancement du "mode de vol". Cette séquence est basée sur les exigences d'Ariane 4, mais elle n'est pas nécessaire pour Ariane 5.L'erreur "Operand Error" s'est produite en raison d'une inclinaison horizontale de BH (Horizontal Bias) inattendue. La valeur BH s'est avérée être beaucoup plus élevée que prévu, car la trajectoire de vol de l'Ariane 5 était considérablement différente de la trajectoire de vol d'Ariane 4. La dernière action, qui a eu des conséquences fatales, a été l'arrêt de l'ordinateur SPI intégré - en conséquence, l'ensemble du système de navigation a cessé de fonctionner. Il était techniquement impossible de reprendre ses actions. Toute cette chaîne d'événements a été entièrement reproduite par simulation informatique. Les résultats de la simulation, ainsi que le matériel d'autres études et expériences, ont permis aux experts de conclure que les causes et les circonstances de la catastrophe étaient entièrement identifiées.
Ariane 5 sur la rampe de lancement avant un lancement réussi, Guyane française 2002.Vous pouvez trouver plusieurs options pour éliminer le bug gênant dans le logiciel Ariane 5 (ces options se reflètent dans les résultats de l'enquête), mais d'une manière ou d'une autre, cette ligne de code a coûté 500 millions de dollars à l'ESA. (le coût d'une fusée avec cargaison).Je tiens également à noter que nulle part dans les rapports l'accent n'est mis sur l'impuissance du système de sauvegarde dans Ariane 5 dans cet incident, bien que dans les conférences du prof. Hoffman cet accident est mentionné juste dans ce contexte. Ayant deux systèmes identiques SRI 1 et SRI 2, nous pouvons peut-être nous protéger contre les problèmes d'équipement physique dans l'un des systèmes, mais lorsqu'il s'agit d'une erreur logicielle, une telle duplication est tout simplement inutile. Puis Hoffman parle de la prochaine étape: dupliquer le logiciel, le rendre différent (différentes entreprises, différents programmeurs). Il semblerait qu'avec une telle structure, nous nous protégions des erreurs, mais de telles mesures compliquent le système global et créent encore plus d'endroits où des erreurs peuvent se produire, et le troisième cas est donné à titre d'exemple.Navette spatiale
Le 12 avril 1981, le vaisseau spatial Columbia réutilisable dans le cadre du programme de la navette spatiale a effectué son premier vol d'essai à partir du cosmodrome de Cap Canaveral.
Préparation de la mission STS-1 - le premier vol de la navette spatialeLe déroulement des événements
Le 10 avril 1981, environ 20 minutes avant le lancement prévu, les astronautes et le personnel du service de navette ont tenté de lancer un système de commande de vol de secours, qui dupliquait le système principal à quatre ordinateurs, mais a échoué. Le départ a été annulé 16 minutes avant l'heure prévue et a été reporté de deux jours.Comment ne pas rappeler la bande dessinée notoire Il se trouve que le système de contrôle de vol de secours BFS (Backup Flight Control System) sur le cinquième ordinateur de bord n'a pas pu se synchroniser avec le système de contrôle de vol principal PASS (Primary Avionics Software System), qui fonctionnait déjà sur quatre autres ordinateurs de bord. Il y avait un bug dans le logiciel - une erreur très petite, presque incroyable, très complexe et très ancienne lors de l'initialisation de PASS.Pour rendre la navette fiable, tout y est dupliqué: capteurs, électronique, système de contrôle, ordinateurs, logiciels, bus de données, alimentations. En fait, pour satisfaire le concept de «panne - opérationnelle, panne - sûre» «FO / FS» (Fail - Operational, Fail - Safe) de nombreux composants ont été dupliqués 4 fois: soit littéralement (4 ensembles d'équipements), soit de manière équivalente (circuits alternatifs remplacement d'un ou plusieurs des quatre blocs requis).Le numéro quatre a été choisi pour une raison logique et intuitive: le principe FO / FS exige qu'après la première panne l'équipement reste pleinement opérationnel, et après la deuxième panne assure un retour en toute sécurité. Le vote minimum nécessite trois votes, donc dans la phase initiale, vous devez avoir 4 votes pour pouvoir voter après un refus. La navette avait 5 ordinateurs de bord, quatre d'entre eux avaient le même logiciel et fonctionnaient à toutes les étapes critiques du vol. Cette approche est idéale en cas de problèmes avec des ordinateurs ou d'autres équipements (selon les calculs, les erreurs dans un système de trois ordinateurs ont causé la perte de l'appareil dans trois cas sur un million, et un système de quatre ordinateurs a réduit cette chance à quatre sur un milliard), mais cela ne fonctionne pas, étant donné la possibilité d'une critiquebug fatal dans le logiciel. Ainsi, l'idée d'un logiciel alternatif est apparue sur le cinquième ordinateur, qui effectuerait la fonctionnalité logicielle minimale sur les quatre premiers.Le développement logiciel pour BFS comprenait les mêmes spécifications, le même langage de programmation, le même compilateur et le même matériel sur lequel ce logiciel a été installé. Mais il a été développé par une organisation complètement différente (Rockwell International pour BFS et IBM, Federal Systems Division pour PASS) et installé sur différents systèmes d'exploitation. Le système d'exploitation pour PASS était asynchrone et piloté par priorité (ainsi, la tâche la plus importante est toujours instantanément donnée le contrôle de l'ordinateur). BFS, au contraire, ressemble plus à un système complètement synchrone d '«intervalles de temps», où chaque processus se voit attribuer le temps alloué pour terminer son cycle.Malheureusement, les systèmes synchrones et asynchrones sont mal combinés. Pour que BFS se synchronise avec PASS, PASS doit devenir synchrone ou émuler cela pour les processus synchronisés. Le processus d'émulation a été assuré avec une perte de développement minimale. Dès que le tout premier ordinateur s'est allumé et que PASS a démarré, elle a essayé de synchroniser le début de tous les processus avec les données de télémétrie du navire. Cette synchronisation a été effectuée en lisant la valeur de temps à partir des données de télémétrie et en calculant les phases de télémétrie en fonction de l'heure centrale.Vendredi matin 10 avril, il est devenu clair que certains processus PASS ne sont pas traités dans leur phase: un cycle plus tôt que les autres processus PASS et BFS. En supposant la réception de données «polluées», BFS, comme requis, a complètement arrêté «d'écouter» les informations de PASS et n'a donc pas pu se synchroniser avec PASS. Pour BFS, les données entrant dans la boucle étaient juste des «interférences» déséquilibrées.Déjà en début d'après-midi, après avoir réuni tous les experts, la NASA a pu clarifier la nature du problème. L'erreur de phasage pourrait être corrigée par l'ancienne méthode du grand-père: si quelque chose ne fonctionne pas, éteignez-le et rallumez-le.
Mais cette approche ne fonctionne pas pour un vaisseau spatial entièrement chargé et prêt à être lancé - les ordinateurs de bord jouent un rôle essentiel dans le traitement des informations provenant "de" et "vers" le système de préparation du lancement spatial.Les informations recueillies par les experts et le fait que le redémarrage des ordinateurs de bord vendredi soir a résolu le problème ont donné à la direction de la NASA suffisamment d'informations pour planifier un lancement dimanche matin. Mais les véritables causes de l'erreur ont été révélées dimanche soir, 8 heures après le lancement.Les ordinateurs de bord utilisent la file d'attente du minuteur du système d'exploitation comme horloge, le premier enregistrement est l'heure de début souhaitée du processus suivant, lorsque des centaines de processus sont exécutés à la seconde, le premier enregistrement affiche toujours une heure actuelle assez précise (toujours pressé, mais toujours assez précis). Le temps résultant est toujours exactement le même pour tous les ordinateurs de bord de sauvegarde. Lorsque le tout premier ordinateur démarre - il n'y a pas de calcul actif, c'est le seul moment où la file d'attente est vide. Et comme il n'y a pas d'autre ordinateur en état de marche, le premier a été autorisé à utiliser sa montre pour déterminer l'heure.Mais la ligne n'était pas vide comme prévu. Deux ans avant le lancement, la routine d'initialisation du bus de données a été modifiée, avant le calcul de l'heure de démarrage. Cette routine a inséré une valeur de retard dans la file d'attente du temporisateur. Ce changement est passé inaperçu: au final, comment l'initialisation du bus est associée à la détermination des phases de télémétrie. De plus, ce délai était suffisamment court pour que la première entrée dans la file d'attente soit proche du présent. Mais un an plus tard (un an avant le lancement) une autre modification a été apportée pour corriger une éventuelle surcharge du processeur, le temps de retard a été légèrement augmenté. Et cela suffisait pour la probabilité de 1/67 que, lorsque vous allumez le premier ordinateur de bord, dans vos calculs de l'heure de début,en utilisant la file d'attente du chronomètre un peu en avant, il pouvait obtenir un résultat lorsque l'heure de début était passée. Ensuite, le système d'exploitation a reporté le début du processus pour un cycle (comme cela se produit avec une alarme, lorsqu'elle est réglée sur le «passé», elle saute un cycle de 12 heures afin qu'elle puisse sonner dans le «futur»), ce qui conduit finalement au fait que presque tout les processus ont été exécutés à la fin du cycle.Les tests pouvaient détecter cette erreur, mais la probabilité d'une erreur n'apparaissait qu'aux dernières étapes des tests, lorsque l'ensemble du système était testé, mais même dans ce cas, la plupart des tests ne nécessitaient pas d'initialisation à partir de zéro. Et même dans les tests où cela était nécessaire, un laboratoire avec des modèles assez précis de PASS, BFS et de télémétrie était nécessaire. Et même si toutes les conditions ci-dessus sont remplies, lorsqu'une erreur se produit, il y avait une tentation de tout redémarrer et ... de ne jamais répéter l'erreur, et de ne jamais être sûr qu'il s'agissait d'un problème dans la configuration du laboratoire. C'est probablement ce qui s'est passé dans l'un des laboratoires de la NASA environ 4 mois avant le vol.Et pourtant, le jour où le premier ordinateur de bord a été allumé, 30 heures avant le lancement prévu, le problème s'est fait sentir.Toutes les informations sur le bug de la navette proviennent d'un article de John Garman (chef adjoint du département des logiciels spatiaux de la NASA). Il y écrit également: «La fiabilité idéale n'est pas assurée, car les projets doivent toujours négocier le temps et les coûts. Maintenir les systèmes logiciels sur place, accumuler des changements et des ajouts importants aux stades de développement et reconfigurer les logiciels pour les adapter à des machines ou des missions qui ne sont jamais complètement identiques sont les défis auxquels nous sommes confrontés aujourd'hui. Il est facile de dire: «Ne violez pas les règles». Ce n'est pas possible sans inverser la position relative du logiciel dans les systèmes embarqués - et c'est faux! Le logiciel est peut-être "l'âme" des systèmes les plus complexes, mais ce n'est encore qu'une partie de la coque de support, ... une partie très flexible. "
La navette atterrissant à la surface du lac Rogers asséchéLe coût de cette erreur logicielle est de 0 $ (bien sûr, les coûts de transfert du lancement étaient probablement considérables, mais à la lumière des accidents précédents considérés, lorsque le vaisseau spatial a été complètement perdu avant qu'il ne termine sa mission prévue, le coût de la reconversion du lancement I négligée, d'autant plus que je n'ai pas pu trouver de données adéquates).Mais je voudrais noter que cette erreur a reporté l'heure de lancement de deux jours: du 10 avril au 12 avril, et, à mon avis, il était impossible de choisir une meilleure date pour le premier lancement de la navette, car le même jour, il y a exactement 20 ans Yuri Gagarin a fait son vol dans l'espace. Comment ne pas se souvenir des paroles d'une tortue selon lesquelles "le hasard n'est pas accidentel". Source: https://habr.com/ru/post/fr381073/
All Articles