My Authors
Read all threads
Mardi 4 juin 1996. À 09h33 heure locale, Ariane 5 s’élance pour la première fois de son pas de tir avec à son bord 4 satellites de la mission Cluster, chargés d’étudier les effets du vent solaire sur la magnétosphère terrestre. Sauf qu’après 37 secondes de vol, c’est le drame...
La fusée braque ses tuyères sur le côté et commence à se disloquer à cause de la pression aérodynamique. Les boosters latéraux se détachent et déclenchent l'autodestruction du lanceur.
La raison de cet échec à plusieurs centaines de millions de dollars ? Un bug informatique apparemment. Sauf que oui et non. Si c’est effectivement un problème informatique qui a mené à la destruction d’Ariane 5, le problème de fond est bien plus grave qu’un “simple” bug…
Mais déjà, commençons par voir ce qu’il s’est passé.

Ariane 5, comme toutes les fusées ou missiles balistiques utilise un certain nombre d’instruments de mesure afin de récolter des données sur son environnement, sa trajectoire ou son comportement en vol.
L’élément principal dans cette analyse du comportement c’est la centrale inertielle de la fusée. C’est ce qui va lui permettre de mesurer un certain nombre de paramètres comme sa trajectoire, son angle d’incidence, de rouli, sa vitesse, etc
Ce “Système de Référence Inertiel” (qu’on va maintenant appeler SRI) est composé de capteurs (gyroscopes, accéléromètres, lasers) qui transmettent leurs mesures à l’ordinateur du SRI, chargé de les convertir en données “exploitables”.
Et enfin le SRI transmet ces données à l’ordinateur d’Ariane 5, chargé de d’adapter le comportement de la fusée en fonction de ce qu’il reçoit. Histoire d’améliorer la fiabilité, un deuxième SRI (identique au premier, c’est important) est en mode “veille” durant le lancement.
Si le premier SRI dysfonctionne durant le vol, l’ordinateur de bord switche automatiquement vers le 2ème en espérant qu’il fonctionne. La plupart des équipements à bord de la fusée sont d’ailleurs dupliqués pour faire face à ce genre d'événement.
Le petit souci avec ce SRI, c’est qu’il avait été conçu pour Ariane 4. Et Ariane 4 et 5 ont des trajectoires de vol très différentes l’une de l’autre, la vitesse horizontale d’Ariane 5 par exemple, peut être 4 à 5 fois importante que celle Ariane 4.
Dans le code source du SRI (c’est codé en langage ADA), une des instructions est chargée de convertir la vitesse horizontale mesurée par les capteurs. La conversion permet de passer d’un float (nombre à virgule) stocké sur 64 bits en un nombre entier (integer) stocké sur 16 bits.
Vous le sentez venir le problème ?

Un entier relatif stocké sur 16 bits peut prendre une valeur allant de -32768 à +32767. Si on essaye de convertir un nombre supérieur ou inférieur à cet intervalle, on va avoir ce qu’on appelle un dépassement d’entier.
Un dépassement d’entier c’est ce qui avait causé un bug assez drôle dans le jeu Civilization où Gandhi était réputé adepte de l’atomisation de ses ennemis :

Chaque civilisation démarre avec un niveau d'agressivité et celui de Gandhi était le plus bas du jeu : 1.
Sauf que dans le jeu, si une civilisation découvre la démocratie, son agressivité est automatiquement réduite de 2.

Mais la variable responsable de ça ne gère pas les nombres négatifs. Donc au lieu de se maintenir à son plancher de 0, elle devient… 255, soit la valeur maximale
Quand il s’agit d’un jeu-vidéo le résultat est assez drôle, mais quand il s’agit d’un tir de fusée à un demi milliard de dollars, ça l’est moins.

Vous vous souvenez quand j’ai dit que c’était plus important qu’un simple bug ? Bah on y est là. C’est ce qui a suivi le problème
Le SRI détecte donc l’exception (exception informatique = une erreur qui empêche l’exécution normale du programme) et c’est donc à son système de gestion des exceptions de prendre le relais. Et ses spécifications indiquent la marche à suivre :
- Indiquer à l’ordinateur de bord (via le bus de données) qu’il y a eu une erreur

- Enregistrer l’état du programme et de la mémoire au moment de l’erreur

- Éteindre l’ordinateur du SRI

Heureusement 0.05 secondes plus tard, le deuxième SRI s’active pour prendre le relais…
Sauf que le deuxième SRI, c’est une copie du premier, donc on a la même erreur. Et là, on a un autre problème : Il n’y a plus aucun SRI de secours. Du coup, le deuxième suit la procédure et envoie ses données de diagnostic à l’ordinateur d’Ariane 5…
Mais l’ordinateur d’Ariane 5, il interprète ça comme les données issues des capteurs et il se dit qu’il y a un gros problème de trajectoire. Il ordonne alors aux boosters et à l’étage central de braquer leur tuyère pour corriger la trajectoire, et la suite on la connaît.
“Mais du coup c’était bien une histoire de bug informatique ?”

Oui et non. Le vrai problème dans cette histoire, c’est la gestion des risques.
Quelque chose qui a plutôt surpris les enquêteurs c’est que dans le code fautif la variable problématique n’était pas la seule susceptible d’être victime d’un dépassement, il y en avait 7 dans le code en question.

Sauf que sur les 7, seules 4 étaient protégées des dépassements.
Surtout que la protection est assez simple, on affecte juste une valeur plancher (ou plafond) à la variable sur 16 bits si la variable sur 64 bits a une valeur trop grande.

Et la partie du programme gérant la vitesse verticale était protégée, elle.
Si toutes les variables n’étaient pas protégées, c’est sans doute parce que compte tenu des spécifications (pour Ariane 4), la marge de sécurité semblait suffisamment importante et des valeurs problématiques n’étaient pas envisagées.
La redondance des appareils pose aussi problème. À cette époque, on estimait que les problèmes les plus susceptibles d’apparaître étaient d’ordre aléatoire et avoir 2 systèmes identiques semblait être une bonne idée.
Et enfin il y a les problèmes des specs. Si la trajectoire de vol d’Ariane 5 avait été incluse dans le cahier des charges, cette erreur ne serait probablement pas survenue. Et l’opposé est vrai aussi : Si les limites du SRI avaient été mieux analysées, les équipes responsables
de l’intégration des équipements se seraient rendues compte qu’il n’était pas adapté.

Des tests et simulation au sol auraient également pu alerter les ingénieurs sur ce problème.
Même si cet échec est regrettable, il a (comme tous les accidents/catastrophes) au moins eu le mérite de pousser les équipes à adopter de nouvelles pratiques de développement et de contrôle afin d’éviter que ce genre de problème ne se reproduise.
Ça souligne également l’importance de la phase de test d’un logiciel. C’est compliqué et chronophage mais c’est certainement une des parties les plus cruciale du développement. Surtout lorsqu’il s’agit d’un système critique comme le contrôle de la trajectoire d’un pétard géant.
Missing some Tweet in this thread? You can try to force a refresh.

Enjoying this thread?

Keep Current with Erreur_418

Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Follow Us on Twitter!

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3.00/month or $30.00/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!