Licence CC BY

La première Ariane 5 n'a pas explosé à cause d'un bug informatique

Dernière mise à jour :
Auteur :
Catégories :
Temps de lecture estimé : 2 minutes

Vous connaissez sans doute la fusée européenne Ariane 5, qui est l’un des lanceurs les plus fiables du monde dans sa catégorie1.

Si vous vous intéressez un minimum au spatial ou à l’informatique, vous savez aussi sans doute que son premier lancement fut un échec, parfois qualifié de « bug informatique le plus couteux de l’histoire » et généralement raconté à peu près ainsi :

Pour des raisons de coûts, un code dans les systèmes informatiques qui gèrent le guidage a été copié de Ariane 4 à Ariane 5. Or le logiciel Ariane 4 utilisait des nombres entiers de 16 bits, tandis que les capteurs Ariane 5 envoyaient des nombres flottants de 64 bits. Comme Ariane 5 est beaucoup plus puissante que Ariane 4, le capteur a renvoyé une valeur qui tenait très bien dans un flottant de 64 bits mais pas dans un entier de 16 bits. Ça a provoqué une erreur de conversion, donc le logiciel a cru que la fusée allait dans une mauvaise direction, et a ordonné une correction massive alors qu’en réalité tout allait bien. Résultat, la fusée est partie en travers, a commencée à se désagréger et s’est auto-détruite.

Si la personne qui vous raconte ça est à un poste technique, il est fréquent qu’elle rajoute :

Si les décideurs avaient écouté les équipes techniques au lieu de décider de grappiller un peu d’argent en faisant un copier/coller, ça ne serait pas arrivé.

Sachez-le :

Cette explication est fausse, ou au moins très, très incomplète.

Le rapport sur l’accident de la fusée Ariane 5, vol 501 est public et nous expose les causes réelles de celui-ci. Et elles sont beaucoup plus profondes et complexes qu’un simple bug informatique ; les procédures de conception, de qualification et de tests sont notamment mises en cause.

Et en particulier, si l’erreur informatique est bien un déclencheur, elle aurait pu être traitée et n’est pas directement la cause de la perte de la fusée. Le paragraphe « 3.2 Cause de l’accident » dit précisément ceci :

C’est la perte totale des informations de guidage et d’attitude 37 secondes après le démarrage de la séquence d’allumage du moteur principal (30 secondes après le décollage) qui est à l’origine de l’échec d’Ariane 501. Cette perte d’informations est due à des erreurs de spécification et de conception du logiciel du système de référence inertielle.

Les revues et essais approfondis effectués dans le cadre du programme de développement d’Ariane 5 ne comportaient pas les analyses ou essais adéquats du système de référence inertielle ou du système complet de contrôle de vol qui auraient pu mettre en évidence la défaillance potentielle.

(Un autre paragraphe un peu plus tôt dans le document insiste sur le fait que cette erreur n’est pas la cause directe de l’échec du lancement).

Attitude, altitude

Vous êtes plusieurs à me l’avoir signalé : la citation ci-dessus parle bien d’information d’attitude et non d’altitude. Ça n’est pas une coquille.

L’attitude, en aérospatiale, c’est l’orientation du vaisseau par rapport à une référence. C’est particulièrement important en l’absence de gravité parce que plus rien ne donne de direction « naturelle » au vaisseau, qui peut très bien pointer dans une direction et avancer dans une autre – et il vaut mieux éviter d’allumer les moteurs si le vaisseau n’est pas dans la direction voulue…

En réalité, on retrouve ce genre de problèmes multi-factoriels dans pratiquement tous les gros échecs de systèmes industriels. Mais il est beaucoup plus simple d’accuser le seul management qui fait de l’économie à outrance (si on est technique) ; ou la seule technique qui ne sait pas développer ou tester (si on est dans le management).

Je ne peux que vous recommander la lecture du rapport si le sujet vous intéresse : il est pas très long, assez facile à lire et très instructif, notamment sur les évènements déclencheurs de catastrophes et sur les chaines de confiance douteuses qui ont conduit à ne pas tester des éléments testables.


  1. Au point qu’on lui a confié le lancement du Télescope James Webb, un jouet à dix milliards (pas millions : milliards) de dollars US.


Icône d’après DLR/Thilo Kranz (CC-BY 3.0) 2013

8 commentaires

En réalité, on retrouve ce genre de problèmes multi-factoriels dans pratiquement tous les gros échecs de systèmes industriels. Mais il est beaucoup plus simple d’accuser le seul management qui fait de l’économie à outrance (si on est technique) ; ou la seule technique qui ne sait pas développer ou tester (si on est dans le management).

Comme toujours dans ce genre de choses, un bogue est introduit pour une raison X ou Y et une faille dans la procédure lourde (en gros : manque de rigueur) n’a pas permis de l’identifier et de le corriger à temps. Alors que c’est le but même de ces procédures.

En vrai je ne vois pas en quoi ça invalide le propos des gens que tu critiques. Le vrai problème est en effet ce changement de représentation de la valeur qui ne correspondait plus à ce qui était attendu d’un code plus ancien.

Et pour des raisons de coûts, de temps et d’erreurs humaines, ce problème n’a pas été identifié ni corrigé avant le lancement inaugural. Donc la critique reste valide.

Après oui, ce n’est pas forcément la faute au décideur pressé uniquement (ça l’est rarement entièrement de toute façon). D’où le fait que les procédures doivent être suivies avec rigueur et qu’on doit éviter dans des systèmes si complexes se passer de tests d’intégration complets (quitte à utiliser des simulateurs).

Amateur de Logiciel Libre et de la distribution GNU/Linux Fedora. #JeSuisArius

+2 -0

Le début de ton message jusqu’à

Cette explication est fausse, ou au moins très, très incomplète.

En gros. Tu critiques les personnes qui tiennent ces propos.

Édité par Renault

Amateur de Logiciel Libre et de la distribution GNU/Linux Fedora. #JeSuisArius

+0 -0

L’ironie c’est que le code d’Ariane est écris en Ada. Ce qui prouve, que même avec un langage sûr, il est toujours possible de faire des conneries X)

Heziode

Le rapport mentionne le langage en disant ceci :

Il en est résulté une erreur d’opérande. Les instructions de conversion de données (en code Ada) n’étaient pas protégées contre le déclenchement d’une erreur d’opérande bien que d’autres conversions de variables comparables présentes à la même place dans le code aient été protégées.

Et ceci :

On a notamment analysé la conversion de représentations flottantes en nombres entiers et il s’est avéré que les opérations comportant sept variables risquaient de conduire à une erreur d’opérande. En conséquence, une protection a été ajoutée à quatre des variables, comme en témoigne le code Ada, alors que trois variables sont restées non protégées. Aucun élément justifiant cette décision n’a été retrouvé dans le code source proprement dit.

Je ne connais pas assez Ada pour savoir si la sûreté du langage a un rapport direct avec tout ça.

Il a été signalé à la Commission que les conversions n’étaient pas toutes protégées car un objectif de charge de travail maximale de 80 % avait été assigné au calculateur du SRI. Afin de déterminer la vulnérabilité des codes non protégés, une analyse a été conduite sur chaque opération pouvant donner lieu à une exception, y compris une erreur d’opérande.

En gros, c’était délibéré d’avoir certaines conversions non protégées. Mais c’est sûr que si ton langage permet facilement de vérifier ça et que tu ne le fais pas, c’est un risque. Quand tu prends ce risque de manière calculée, ça va. Quand tu te merdes dans le calcul de ce risque, ça ne va pas. :D

Je ne connais pas non plus Ada assez, mais dans d’autres langages, les conversions de type sont très surveillées et tu as de meilleurs outils pour gérer les erreurs quand elles surviennent.

Quand tu décides de faire autrement (pour des raisons de performance par exemple), tu peux passer par de l’analyse statique (Polyspace dans mon ancienne boîte sur du C), pour faire des vérifications sur le code sans perte de performance à l’éxécution. En gros, tu vires des if ou utilise des fonctions de conversion non-sûres parce que tu sais prouver que le dépassement n’arrivera pas avec ce qui est connu sur les opérandes.

Le problème, c’est que les analyses automatiques ont des limites liées à la quantité d’information disponible à travers le reste du code (par exemple des tests de plage de valeur). Au bout d’un moment, tu es obligé de donner des informations toi-même, et donc potentiellement introduire des erreurs. Surtout si ces hypothèses se révèlent fausses (par exemple les entrées envoyées par un autre calculateur, ou des accélérations supérieures à ce qui était envisagé).

Édité par Aabu

+0 -0

En gros, c’était délibéré d’avoir certaines conversions non protégées. Mais c’est sûr que si ton langage permet facilement de vérifier ça et que tu ne le fais pas, c’est un risque. Quand tu prends ce risque de manière calculée, ça va. Quand tu te merdes dans le calcul de ce risque, ça ne pas pas. :D

Aabu

Dans le cas présent, ce risque était parfaitement calculé… avec les données de trajectoire d’Ariane 4, pour laquelle ce logiciel a été développé, tandis qu’on a choisi de ne pas joindre les données de vols d’Ariane 5 aux specs de la mise à jour du SRI pour Ariane 5 (dont une centrale inertielle n’a à priori pas besoin, à moins qu’on y ajoute des fonctionnalités annexes, ce qui n’était d’ailleurs pas le cas sur Ariane 5: la fonctionnalité annexe était héritée d’Ariane 4).

J’aime beaucoup ce cas de catastrophe industrielle, où, comme souvent, personne n’a fait de choix expliquant à lui seul la catastrophe. Pour citer le rapport:

Bien que la source de l’erreur d’opérande ait été identifiée, elle n’est pas en soi la cause de l’échec de la mission.

+3 -0

Sur ce sujet, je ne me risquerai pas a faire un commentaire avant d’avoir bien lu et compris le rapport.

Je ne peux que vous recommander la lecture du rapport si le sujet vous intéresse : il est pas très long, assez facile à lire et très instructif, notamment sur les évènements déclencheurs de catastrophes et sur les chaines de confiance douteuses qui ont conduit à ne pas tester des éléments testables.

Cela me rappelle une expérience professionnelle marquante : un équipement majeur était constitué de deux sous systèmes : un unité de commande et de contrôle, et plusieurs unités de production.
Chaque sous système faisait l’objet de spécifications très complète., et de tests destinés à vérifier la conformité aux spécifications. Mais on n’avait pas de spécification documentée d’interfonctionnement !
Or, en situation de forte charge, des éléments d’information des unités de productions parvenaient trop tard au système de commande et de contrôle, d’où des plantages catastrophiques en pleine heure de pointe.
En fait, les spécifications ne prévoyaient pas une charge aussi élevée, mais comme le truc marchait, personne ne s’est posé la sérieusement la question des moyens de test pour générer une charge comparable.

En l’occurrence, si un truc marche très bien depuis 10 ans, a du mal à imaginer pourquoi il se plante de temps en temps.

Édité par etherpin

Il se faut s’entraider, c’est la loi de la nature. (Jean de La Fontaine, l’âne et le chien)

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte