Quel a été l'impact historique du vol 501 d'Ariane 5?

La désintégration de la fusée Ariane 5 37 secondes après le lancement de son voyage inaugural ( vol 501 ) est communément appelée l'un des bogues logiciels les plus chers de l'histoire ¹ :

Il a fallu 10 ans et 7 milliards de dollars à l'Agence spatiale européenne pour produire Ariane 5, une fusée géante capable de lancer une paire de satellites de trois tonnes en orbite à chaque lancement et destinée à donner à l'Europe une suprématie écrasante dans le secteur spatial commercial.

Tout ce qu'il a fallu pour faire exploser cette fusée moins d'une minute dans son voyage inaugural en juin dernier, éparpillant des décombres enflammés à travers les marais de mangroves de la Guyane française, était un petit programme informatique essayant de bourrer un nombre 64 bits dans un espace 16 bits.

Un bug, un crash. De toutes les lignes de code négligentes enregistrées dans les annales de l'informatique, celle-ci peut être la plus dévastatrice. Des entretiens avec des experts en fusée et une analyse préparée pour l'agence spatiale, un chemin clair d'une erreur arithmétique à une destruction totale émerge.

Quels changements majeurs la panne du Flight 501 et les enquêtes ultérieures ont-ils inspirés à la recherche de systèmes critiques pour la sécurité et de tests de logiciels?

Je ne cherche pas une explication du bogue lui-même, mais une explication de l'impact historique du bogue, en termes de recherches qui ont été inspirées ou directement liées aux enquêtes sur l'échec. Par exemple, cet article conclut:

Nous avons utilisé l'analyse statique pour:

• vérifier l'initialisation des variables,
• fournir la liste exhaustive des conflits potentiels d'accès aux données pour les variables partagées,
• répertorier de manière exhaustive les erreurs potentielles d'exécution de la sémantique Ada.

À notre connaissance, c'est la première fois que des techniques d'analyse statique à base booléenne et non booléenne sont utilisées pour valider des programmes industriels.

De même, ce document ^(pdf) note:

Des analyses de programmes statiques basées sur l'interprétation abstraite ont été utilisées pour l'analyse statique du logiciel ADA intégré du lanceur Ariane 5 et de l'ARD. L'analyseur de programme statique vise à la détection automatique de la dé fi nitivité, de la potentialité, de l'impossibilité ou de l'inaccessibilité des erreurs d'exécution telles que les débordements scalaires et à virgule flottante, les erreurs d'index du tableau, les divisions par zéro et les exceptions arithmétiques associées, les variables non initialisées, les courses de données sur structures de données partagées, etc. L'analyseur a pu détecter automatiquement l'erreur de vol Ariane 501. L'analyse statique des logiciels embarqués critiques pour la sécurité (tels que les logiciels avioniques) est très prometteuse .

J'aimerais une explication approfondie de l'impact de cet événement unique sur les approches et les outils de test de logiciels.

_{¹ Le chiffre de 7 milliards de dollars fait probablement référence au coût total du projet Ariane 5, Wikipedia rapporte que l'échec a entraîné une perte de plus de 370 millions de dollars. Un échec encore assez cher mais loin des 7 milliards de dollars.}

Techniquement parlant, il s'agissait plutôt d'une " pourriture logicielle ". Le logiciel de contrôle de vol a été recyclé à partir de la fusée Ariane 4 antérieure, une décision raisonnable étant donné le coût de développement d'un logiciel, en particulier lorsqu'il s'agit d'un logiciel essentiel qui doit être testé et vérifié selon des normes beaucoup plus rigoureuses que la plupart des logiciels commerciaux.

Malheureusement, personne n'a pris la peine de tester les effets qu'aurait le changement d'environnement d'exploitation, ou s'ils l'ont fait, ils n'ont pas effectué lesdits tests selon une norme suffisamment approfondie.

Le logiciel a été conçu pour s'attendre à ce que certains paramètres ne dépassent jamais certaines valeurs (poussée, accélération, taux de consommation de carburant, niveaux de vibration, etc.). En vol normal sur Ariane 4, ce n'était pas un problème car ces paramètres n'atteindraient jamais des valeurs invalides sans que quelque chose soit déjà spectaculairement faux. L'Ariane 5 est cependant beaucoup plus puissante et des gammes qui sembleraient idiotes sur le 4 pourraient très facilement se produire sur le 5.

Je ne sais pas quel paramètre était hors de portée (il pourrait s'agir d'une accélération, je vais devoir vérifier), mais quand il l'a fait, le logiciel n'a pas pu faire face et a subi un dépassement arithmétique pour lequel il y avait eu Vérification des erreurs et code de récupération insuffisants. L'ordinateur de guidage a commencé à envoyer des ordures aux cardans de la buse du moteur, qui à leur tour ont commencé à pointer la buse du moteur de manière assez aléatoire. La fusée a commencé à s'effondrer et à se briser, et le système d'autodestruction automatique a détecté que la fusée était maintenant dans une attitude irrécupérable et a terminé le travail.

Pour être honnête, cet incident n'a probablement pas enseigné de nouvelles leçons, car le type de problèmes a été mis au jour auparavant dans toutes sortes de systèmes, et il existe déjà des stratégies en place pour gérer la recherche et la correction des erreurs. Ce que l'incident a fait, c'est ramener à la maison le point qu'être laxiste dans la mise en œuvre de ces stratégies peut avoir d'énormes conséquences, dans ce cas, des millions de dollars de matériel détruit, certains clients extrêmement énervés et une laideur dans la réputation d'Arianespace.

Ce cas particulier était particulièrement flagrant car un raccourci pris pour économiser de l'argent a fini par coûter très cher, à la fois en termes d'argent et de perte de réputation. Si le logiciel avait été testé avec autant de robustesse dans un environnement simulé Ariane 5 qu'il l'avait été à l'origine pour Ariane 4, l'erreur se serait sûrement révélée bien avant que le logiciel ne soit installé dans le matériel de lancement et mis en commande de un vol réel. De plus, si un développeur de logiciel avait délibérément injecté des informations absurdes dans le logiciel, l'erreur aurait même pu être détectée à l'ère Ariane 4, car cela aurait mis en évidence le fait que la récupération d'erreur en place était insuffisante.

Donc, en bref, il n'a pas vraiment enseigné de nouvelles leçons, mais il a percuté les dangers de ne pas se souvenir des anciennes. Il a également démontré que l'environnement dans lequel un système logiciel fonctionne est tout aussi important que le logiciel lui-même. Ce n'est pas parce que le logiciel est correct pour l'environnement X qu'il est adapté à un environnement similaire mais distinct Y. Enfin, il a souligné combien il est important que les logiciels critiques soient suffisamment robustes pour faire face à des circonstances qui n'auraient pas dû se produire. arrivé.

Comparez le vol 501 avec Apollo 11 et ses problèmes informatiques. Alors que le logiciel LGC a souffert d'un sérieux problème lors de l'atterrissage, il a été conçu pour être extrêmement robuste et a pu rester dans un état opérationnel malgré les alarmes logicielles qui ont été déclenchées, sans mettre aucun astronaute en danger et toujours en mesure de terminer sa mission.

C'était surtout un problème de réutilisation et un problème de gestion et non un problème de codage. D'après mes souvenirs (je me trompe probablement certaines choses) du rapport.

• un sous-système a été conçu pour Ariane IV. Les trajectoires d'Ariane IV ne pouvaient pas entraîner de débordement et il a alors été délibérément décidé que si cela se produisait, il s'agissait d'un problème matériel et l'arrêt du sous-système et le recours à la réserve étaient la bonne chose à faire.

• pour Ariane V, il a été décidé de réutiliser ce sous-système et non de revoir les hypothèses et le code mais de s'appuyer sur des tests.

• en outre, il a été décidé d'abandonner les tests complets.

Différents paramètres de vol d'Ariane V ont provoqué le débordement. Arrêtez le primaire. Arrêtez le disque de rechange. Autodestruction.

Autres choses dont je me souviens:

• le sous-système au moment du débordement n'était plus utile. On pourrait dire que son échec n'aurait pas dû déclencher l'autodestruction. (D'un autre côté, la complexité supplémentaire pourrait elle-même être source de problèmes).

• il y avait des données de débogage envoyées à un bus alors qu'elles ne le devraient pas. Je ne me souviens pas du détail.

Comme d'autres l'ont mentionné, cela a amené l'industrie en général à réexaminer le concept de réutilisation et à le placer dans un cadre de référence plus large selon lequel les composants ne sont pas évalués isolément mais dans le contexte de l'ensemble du système. Cela réduit considérablement l'attrait de la réutilisation, car même si un composant peut être réutilisé sans changement, il doit encore être analysé avec un nouvel ensemble d'hypothèses. Un autre corollaire est que le matériel de sauvegarde exécutant le même logiciel n'est pas aussi attrayant, car la plupart des matériels modernes sont des ordres de grandeur plus fiables que les logiciels modernes. J'ai entendu dire que certains contrats de défense nécessitent deux systèmes logiciels distincts développés par des équipes différentes utilisant des technologies différentes fonctionnant à partir des mêmes spécifications pour vérifier la bonne mise en œuvre.