LE CAS ARIANE 5



  

  .: Pourquoi Ariane 5 :.

J'ai choisi d'illustrer la necessité de tester le code avec le crash d'Ariane 5 en 1996. Ce crash est assez représentif des "mauvaises habitudes de codages", dont les conséquences peuvent être assez catastrophique. Comment une simple affectation peut elle provoquer un bug à 5 millions de $ ?

Je me suis basé sur le rapport d'enquête officiel. Ce rapport est téléchargeable ici.


  .: La défaillance  :.

Ariane 5 au décollage.
et après 39s de vol....


Ce crash est le résultat d'une succesion d'erreurs techniques et stratégiques. Le calculateur en cause était chargé de fournir des données au coeur du contôle de vol. Il avait était développé pour Ariane 4, et avait effectué sans problèmes plusieurs vols.

Les erreurs de stratégies sont que le calculateur est repris tel quel sur Ariane 5, sans aucune reprise des spécifications, ni tests complémentaires. Malheureusement les données d'entrées d'ariane 5 sont totalement différente de celles d'ariane 4. Ce qui aura pour conséquence de provoquer le bug qui entrainera la destruction du lanceur.


Première erreur technique
:
Le code contient tout bêtement une affectation d'une donnée 64 bits vers une donnée 16 bits. Comme les données d'entrées d'ariane 5 sont plus importante que prévu, il arrive qu'une valeur de plus de 16 bits est affectée à la variable codée sur 16 bits. Une exception est alors logiquement levée.

Deuxième erreur technique :
En ADA un mécanisme permet de récupérer ce type d'exception. Ici aucun mécanisme de protection n'est prévu. L'exception est transmise au coeur du contrôle de vol, qui la traite comme n'importe quel autre valeur fournie par le calculateur. D'ou son comportement aberrant, qui entraine la perte de trajectoire, puis par conséquent le méchanisme d'auto-destruction.

Un deuxième calculateur fonctionnait en redondnace à chaud ( fonctionnement en parallèle). Mais comme sa conception était en tout point identique au premier, les même causes ont produit les mêmes effets...

 


  .: Les conclusions  :.

Donc voici une erreur qui pourrait paraître anodine. Mais cet exemple montre bien que rien ne doit être laissé au hasard et que le code doit être implémenter rigoureusement, maîtrisé, et surtout vérifié.

Une des conclusions du rapport d'enquête est que malgrés les éventuelles difficultés le calculateur aurait du être testé...