Paris, le 19 juillet 1996
Président de la Commission :
Professeur J.-L. LIONS
Le vol inaugural d'Ariane 5 qui a eu lieu le 4 juin 1996 s'est soldé par un échec. Environ 40 secondes seulement après le démarrage de la séquence de vol, le lanceur, qui se trouvait alors à une altitude de quelques 3700 mètres, a dévié de sa trajectoire, s'est brisé et a explosé. Des ingénieurs des équipes du projet Ariane 5 du CNES et de l'industrie ont immédiatement commencé à rechercher les causes de cet échec. Dans les jours qui ont suivi, le Directeur général de l'ESA et le Président du CNES ont constitué une Commission d'enquête indépendante dont ils ont désigné les membres :
| - | Prof. Jacques-Louis Lions (Président) | Académie des Sciences (France) |
| - | Dr. Lennart Lübeck (Vice-Président) | Swedish Space Corporation (Suède) |
| - | M. Jean-Luc Fauquembergue | Délégation Générale pour l'Armement (France) |
| - | M. Gilles Kahn | Institut National de Recherche en Informatique et en Automatique (INRIA), (France) |
| - | Prof. Dr. Ing. Wolfgang Kubbat | Université technique de Darmstadt (Allemagne) |
| - | Dr. Ing. Stefan Levedag | Daimler Benz Aerospace (Allemagne) |
| - | Dr. Ing. Leonardo Mazzini | Alenia Spazio (Italie) |
| - | M. Didier Merle | Thomson CSF (France) |
| - | Dr. Colin O'Halloran | Defence Evaluation and Research Agency (DERA), (U.K.) |
La Commission d'enquête a reçu pour mandat :
La Commission a commencé ses travaux le 13 juin 1996 ; elle était assistée d'un Comité technique consultatif composé de :
Conformément au mandat qu'elle a reçu, la Commission a concentré ses recherches sur les causes de l'échec, les systèmes incriminés, les éventuelles défaillances semblables sur des systèmes similaires ainsi que sur des événements qui pourraient être liés à l'accident. En conséquence, les recommandations de la Commission sont limitées aux domaines examinés. Le présent rapport contient l'analyse de l'échec, les conclusions de la Commission et ses recommandations en vue de mesures correctives, la plupart d'entre elles devant être apportées avant le prochain vol d'Ariane 5. En outre, il a été rédigé un rapport, pour distribution restreinte, dans lequel les résultats des travaux de la Commission sont présentés avec davantage de détails techniques. Bien qu'elle ait utilisé les données de télémesure enregistrées pendant le vol, la Commission n'a pas évalué ces données et ne s'est pas livrée non plus à un examen complet de l'ensemble du lanceur et de tous ses systèmes.
Le présent rapport est le résultat d'un travail collectif de la Commission, avec l'aide des membres du Comité technique consultatif.
Nous nous sommes tous efforcés de présenter une explication très précise des raisons de l'échec et d'apporter une contribution à l'amélioration des logiciels d'Ariane 5. Ces améliorations sont nécessaires pour garantir le succès du programme.
Les résultats des travaux de la Commission reposent sur les présentations détaillées et transparentes des équipes du projet Ariane 5 et sur des documents qui témoignent du haut niveau de qualité du programme Ariane 5 en ce qui concerne l'ingénierie en général ainsi que l'exhaustivité et la traçabilité des documents.
D'après les documents mis à la disposition de la Commission et les informations qui lui ont été présentées, on peut faire les remarques suivantes :
Le matin du 4 juin 1996, les conditions météorologiques qui régnaient sur le site de lancement de Kourou étaient acceptables pour que le lancement ait lieu ce jour là et que le lanceur puisse être transféré sur son pas de tir. Il convient de noter, en particulier, qu'il n'y avait pas de risque de foudre ; l'intensité du champ électrique mesurée était négligeable. La seule incertitude portait sur les critères de visibilité.
La chronologie de lancement, qui inclut le remplissage de l'étage principal cryotechnique, s'est déroulée correctement jusqu'à H0-7 minutes ; elle a alors été arrêtée car les critères de visibilité n'était pas satisfaits à l'ouverture de la fenêtre de lancement (08 h 35, heure locale). Les conditions de visibilité se sont améliorées comme prévu et le lancement a eu lieu à H0 = 09 h 33 min 59s, heure locale (soit 12 h 33 min 59s, TU). L'allumage du moteur Vulcain et des deux moteurs à propergol solide ainsi que le décollage se sont déroulés de façon nominale. Le lanceur a réalisé un vol nominal jusqu'à environ H0 + 37 secondes. Peu après, il a brusquement dévié de sa trajectoire, s'est brisé et a explosé. Une première analyse des données de vol a montré :
On a pu remonter rapidement jusqu'à l'origine de cette défaillance dans le système de pilotage et, plus précisément, dans les systèmes de référence inertielle qui, à l'évidence, ont cessé de fonctionner presque simultanément à environ H0 + 36,7 s.
La Commission disposait pour ses travaux des informations suivantes sur le lancement :
Toutes les données de télémesure reçues à Kourou ont été transférées au CNES à Toulouse où elles ont été converties en paramètres reportés sur des graphiques en fonction du temps. Le CNES a remis une copie des données à l'Aerospatiale qui a travaillé, pour l'essentiel, sur les données relatives au système électrique.
Le lanceur s'est auto-détruit à proximité de l'ensemble de lancement, à une altitude d'environ 4000 mètres. Tous les débris sont donc retombés au sol, sur une superficie d'environ 12 km2, à l'est de l'ensemble de lancement. La récupération des débris s'est toutefois avérée difficile car cette région se compose, pour l'essentiel de mangrove et de savane.
Il a néanmoins été possible d'extraire des débris les deux systèmes de référence inertielle. Le système qui avait travaillé en mode actif et qui a été le dernier à cesser de fonctionner était particulièrement intéressant : en effet, on ne disposait pas pour ce système de certaines données de télémesure (la transmission au sol de ces données n'étant prévue que pour l'unité qui tombe en panne la première). Les résultats de l'examen de cette unité ont donc été très utiles pour analyser le déroulement de la défaillance.
L'analyse après vol des données de télémesure a révélé un certain nombre d'anomalies qui ont été portées à la connaissance de la Commission. Dans la plupart des cas, leur importance est mineure et dans l'ordre normal des choses pour un vol de démonstration.
L'attention de la Commission a cependant été attirée sur une anomalie particulière ; il s'agit de variations de la pression hydraulique des vérins de la tuyère du moteur principal qui se sont progressivement développées à partir de H0 + 22 secondes. Ces variations avaient une fréquence d'environ 10 Hertz.
On dispose de quelques explications préliminaires quant aux causes de ces variations ; elles sont actuellement à l'étude.
Après examen, la Commission a estimé que cette anomalie, tout en étant significative, n'avait aucune relation avec l'échec du vol Ariane 501.
De manière générale, la chaîne de pilotage d'Ariane 5 repose sur un concept standard. L'attitude du lanceur et ses mouvements dans l'espace sont mesurés par un système de référence inertielle (SRI) dont le calculateur interne calcule les angles et les vitesse sur la base d'informations provenant d'une plate-forme inertielle à composants liés, avec gyrolasers et accéléromètres. Les données du SRI sont transmises, via le bus de données, au calculateur embarqué (OBC) qui exécute le programme de vol et qui commande les tuyères des étages d'accélération à poudre et du moteur cryotechnique Vulcain, par l'intermédiaire de servovalves et de vérins hydrauliques.
Pour améliorer la fiabilité, on a prévu une importante redondance au niveau des équipements. On compte deux SRI travaillant en parallèle ; ces systèmes sont identiques tant sur le plan du matériel que sur celui du logiciel. L'un est actif et l'autre est en mode "veille active" ; si l'OBC détecte que le SRI actif est en panne, il passe immédiatement sur l'autre SRI à condition que ce dernier fonctionne correctement. De même, on compte deux OBC et un certain nombre d'autres unités de la chaîne de pilotage qui sont également dupliquées.
La conception des SRI d'Ariane 5 est pratiquement la même que celle d'un SRI qui est actuellement utilisé à bord d'Ariane 4, notamment pour ce qui est du logiciel.
Sur la base de la documentation et des données exhaustives relatives à l'échec d'Ariane 501 qui ont été mises à la disposition de la Commission, on a pu établir la séquence suivante d'événements ainsi que leurs interdépendances et leurs origines, depuis la destruction du lanceur jusqu'à la cause principale en remontant dans le temps.
Les événements internes du SRI qui ont conduit à l'accident ont été reproduits par simulation. En outre, les deux SRI ont été récupérés pendant l'enquête de la Commission et le contexte de l'accident a été déterminé avec précision à partir de la lecture des mémoires. De plus, la Commission a examiné le code logiciel qui s'est avéré correspondre au scénario de l'échec. Les résultats de ces examens sont exposés dans le Rapport technique.
On peut donc raisonnablement affirmer que la séquence d'événements ci-dessus traduit les causes techniques de l'échec d'Ariane 501.
Dans le scénario de défaillance, les principales causes techniques sont l'erreur d'opérande lors de la conversion de la variable biais horizontal BH et l'absence de protection de cette conversion, qui a provoqué l'arrêt de fonctionnement du calculateur du SRI.
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. 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. Compte tenu du grand nombre de documents qu'exige toute application industrielle, l'hypothèse retenue, même si elle a fait l'objet d'un accord, est, pour l'essentiel, passé inaperçue lors de toute les revues externes, bien qu'il ne se soit pas agi d'une intention délibérée.
La raison pour laquelle les trois autres variables, y compris celle qui caractérise le biais horizontal, sont restées non protégées est que l'on a estimé qu'elles étaient soit limitées physiquement, soit assorties d'une grande marge de sécurité, raisonnement qui s'est avéré erroné dans le cas de la variable BH. Il est important de noter que la décision de protéger certaines variables, mais de ne pas le faire pour d'autres, a été prise conjointement par les partenaires du projet à différents niveaux contractuels.
Il n'a pas été possible de déterminer si des données de trajectoire ont été utilisées pour analyser le comportement des variables non protégées, mais il convient surtout de noter qu'il a été décidé conjointement de ne pas inclure les données de trajectoire d'Ariane 5 dans les exigences et la spécification du SRI.
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. La spécification relative au mécanisme de traitement des exceptions a également contribué à la défaillance. En cas d'exception quelle qu'elle soit, la spécification système précise que la défaillance doit être indiquée sur le bus de données, que son contexte doit être enregistré dans une mémoire EEPROM (qui a été récupérée et lue à l'issue du vol Ariane 501) et que le processeur du SRI doit être arrêté.
C'est la décision d'arrêter le fonctionnement du processeur qui s'est finalement révélée fatale. Un redémarrage est impossible car le calcul de l'attitude est trop difficile pour être refait après l'arrêt du processeur, de sorte que le système de référence inertielle devient alors inutile. La raison qui sous-tend cette procédure draconienne tient à la philosophie adoptée par le programme Ariane, qui consiste à ne prendre en compte que les défaillances aléatoires de matériels. Dans cette optique, les mécanismes de traitement des exceptions ou des erreurs sont conçus pour faire face à une défaillance aléatoire de matériel, qui peut être efficacement prise en charge par un système de secours.
Bien que la défaillance ait été provoquée par une erreur de conception de logiciel à caractère systématique, il est possible d'introduire des mécanismes pour atténuer ce type de problème. Par exemple, les calculateurs présents dans les SRI auraient pu continuer de fournir leurs meilleures estimations des informations d'attitude requises. Il est préoccupant de constater qu'une exception de logiciel puisse être autorisée, voire requise pour provoquer l'arrêt d'un processeur alors que celui-ci commande des équipements critiques pour la mission. De fait, la perte d'une fonction logicielle correcte présente un risque car c'est le même logiciel qu'utilisent les deux unités SRI. Dans le cas d'Ariane 501, cela s'est traduit par la mise hors circuit de deux équipements critiques ne présentant pas de défaillance.
L'exigence qui est à l'origine de la poursuite du fonctionnement du logiciel d'alignement après le décollage a été imposée il y a plus de 10 ans pour les premiers modèles de lanceurs Ariane afin de faire face à l'éventualité assez peu probable d'un arrêt de la chronologie entre H0-9 secondes, au moment ou le SRI d'Ariane 4 passe en mode vol, et H0-5 secondes, lors de la mise en route, dans le lanceur, de certaines opérations dont le retour à l'état initial prend plusieurs heures. La période choisie pour le maintien de la fonction d'alignement, qui est de 50 secondes après le passage en mode vol, était basée sur la durée nécessaire aux équipements au sol pour reprendre le contrôle intégral du lanceur en cas d'arrêt.
Cette fonction particulière devait permettre aux premières versions d'Ariane de réenclencher la chronologie sans attendre la procédure normale d'alignement, qui dure 45 minutes ou plus, préservant ainsi la possibilité d'utiliser une fenêtre de lancement étroite. En fait, cette fonction a servi une seule fois en 1989 pour le vol V33.
Cette exigence n'a pas lieu d'être sur Ariane 5, dont la séquence de préparation est différente. Elle a été conservée pour des raisons de communité, qui semblent reposer sur le principe selon lequel il n'est pas opportun, sauf preuve contraire, de procéder à des modifications sur des logiciels qui ont bien fonctionné sur Ariane 4.
Même dans les cas où cette exigence est considérée comme étant toujours valable, il est risqué de laisser la fonction d'alignement opérationnelle après le décollage du lanceur. L'alignement des centrales mécaniques et à gyrolasers à composants liés implique des fonctions filtres mathématiques complexes afin d'aligner correctement l'axe X sur l'axe de gravité et de calculer le Nord à partir de la détection de la rotation terrestre. L'alignement avant le lancement se fait sur la base de l'hypothèse selon laquelle le lanceur occupe une position fixe connue. De ce fait, la fonction d'alignement est totalement perturbée lorsqu'elle est exécutée en vol car les mouvements du lanceur tels qu'ils sont mesurés sont interprétés comme des écarts capteurs et d'autres paramètres caractérisant le comportement des capteurs.
Pour en revenir à l'erreur de logiciel, la Commission tient à souligner qu'un logiciel est le résultat d'une conception extrêmement détaillée et ne tombe pas en panne au sens où on l'entend pour des systèmes mécaniques. En outre, un logiciel est flexible et possède un grand pouvoir d'expression, ce qui favorise des exigences très contraignantes, qui entraînent à leur tour des modes de fonctionnement complexes et difficiles à évaluer.
Un aspect sous-jacent du développement d'Ariane 5 est la stratégie suivie pour lutter contre les défaillances aléatoires. Le fournisseur des SRI n'a fait qu'appliquer la spécification qui lui était imposée, selon laquelle le processeur devait être arrêté au cas où il détecterait une exception. Or, l'exception constatée n'était pas due à une défaillance aléatoire, mais à une erreur de conception. L'exception a bien été détectée, mais a été traitée de manière inappropriée du fait que le logiciel doit être considéré comme correct tant qu'il ne s'est pas révélé défaillant. La Commission a quelques raisons de penser que ce principe a également été appliqué à d'autres domaines de la conception des logiciels d'Ariane 5. Elle est favorable au principe opposé, selon lequel un logiciel est présumé défaillant tant qu'il n'a pas été jugé correct par les meilleurs pratiques en vigueur.
Cela signifie qu'un logiciel critique au sens où la défaillance de celui-ci compromet la mission, doit être identifié en tant que tel à un niveau très détaillé, que les possibilités de fonctionnement en mode exceptionnel doivent être confinées et qu'une bonne politique de sauvegarde doit prendre en compte des défaillances de logiciel.
La qualification du système de contrôle de vol d'Ariane 5 suit une procédure standard et est exécutée aux niveaux suivants :
La méthode appliquée consiste à vérifier à chaque niveau ce qui n'a pas pu l'être au niveau précédent, assurant ainsi en fin de compte une couverture complète de chaque sous-système et du système intégré.
Les essais au niveau équipements ont été conduits de façon rigoureuse, dans le cas du SRI, en ce qui concerne tous les paramètres d'environnement, au-delà même de ce que l'on pouvait attendre pour Ariane 5. Toutefois, aucun essai n'a été fait pour vérifier que le SRI réagirait correctement eu égard à la chronologie, à la séquence de vol et à la trajectoire d'Ariane 5.
Il convient de noter que les lois de la physique interdisent de tester le SRI comme une "boîte noire" dans des conditions de vol, à moins de procéder à un essai en vol totalement réaliste, mais qu'il est possible de procéder à des essais au sol en injectant des signaux accélérométriques simulés correspondant aux paramètres de vol prévus tout en utilisant une table tournante afin de simuler les mouvements angulaires du lanceur. Si un essai de ce type avait été exécuté par le fournisseur ou dans le cadre des essais de recette, le processus de défaillance aurait été mis en lumière.
La principale explication de l'absence d'un tel essai, déjà mentionnée plus haut, est que la spécification du SRI (qui doit être considérée comme un document précisant les exigences applicables au SRI) ne mentionne pas les données de trajectoire d'Ariane 5 en tant qu'exigences fonctionnelles.
La Commission a également constaté que la spécification système applicable au SRI ne fait pas état de restrictions opérationnelles résultant de l'application choisie. Une telle déclaration de limitation, qui devrait être obligatoire pour tout dispositif critique pour la mission, aurait permis de mettre en évidence toute non-conformité avec la trajectoire d'Ariane 5.
Les nombreux essais et simulations exécutés sur l'installation de simulation fonctionnelle ISF, qui est implantée dans les locaux de l'architecte industriel, constituaient l'autre possibilité majeure de détecter le processus de défaillance existant. Les essais ISF ont pour objet de qualifier :
Un grand nombre de simulations en boucle fermée du vol complet, simulant le fonctionnement du segment sol, la transmission des télémesures et la dynamique du lanceur ont été faites afin de vérifier :
Lors de ces essais, de nombreux équipements était matériellement présents et mis en oeuvre, mais pas les deux SRI, qui étaient simulés par des modules logiciels réalisés à cet effet. Certains essais en boucle ouverte, destinés à vérifier la conformité du calculateur de bord et du SRI, ont été exécutés avec le SRI réel. Il est entendu que ces essais étaient seulement des essais d'intégration électrique et des essais de conformité "de bas niveau" (communication par les bus).
Il n'est pas obligatoire, même si c'est préférable, que tous les éléments d'un sous-système soient présents dans tous les essais à un niveau donné. Quelquefois, cela n'est matériellement pas réalisable, de même qu'il est parfois impossible de mettre en oeuvre ces éléments intégralement ou de manière représentative. Dans de tels cas, il est logique de les remplacer par de simulateurs, à condition toutefois d'avoir vérifié soigneusement que les niveaux d'essai précédents couvrent l'intégralité du domaine étudié.
Cette procédure est particulièrement importante pour l'essai final du système avant que celui-ci soit utilisé de manière opérationnelle (les essais exécutés sur le lanceur 501 proprement dit ne sont pas traités ici car ils n'interviennent pas dans la qualification du système électrique de contrôle de vol).
Afin de mieux comprendre les explications fournies quant à la décision de ne pas intégrer les SRI dans la simulation en boucle fermée, il est nécessaire de décrire les configurations d'essai qui auraient pu être utilisées.
Comme il n'est pas possible de simuler au banc d'essai les importantes accélérations linéaires du lanceur sur l'ensemble des trois axes (voir ci-dessus), il existe deux possibilités d'intégrer les SRI dans la boucle :
La première méthode fournit en principe une simulation précise (dans les limites de la plage de fréquences de la table dynamique trois axes) et est assez onéreuse ; la deuxième est moins coûteuse et les résultats obtenus dépendent essentiellement de la précision de la simulation. Ces deux méthodes permettent de tester une grande partie de l'électronique et l'ensemble du logiciel dans des conditions de fonctionnement réelles.
Lorsque la philosophie d'essai du projet a été définie, il a été admis qu'il était important que les SRI soient intégrés dans la boucle et il a été décidé de retenir la méthode B ci-dessus. A un stade ultérieur du programme (1992), cette décision a été modifiée. Il a alors été décidé de ne pas intégrer les SRI réels dans la boucle pour les raisons suivantes :
La Commission est d'avis que ces arguments étaient techniquement valables, mais que, étant donné qu'un essai de simulation au niveau système a pour objet de vérifier non seulement les interfaces, mais également l'ensemble du système pour l'application considérée, on a pris un risque incontestable en supposant qu'un équipement critique tel que le SRI était validé du seul fait de sa qualification ou de son utilisation antérieure sur Ariane 4.
Etant entendu qu'il est souhaitable d'obtenir une grande précision lors d'une simulation, il est incontestablement préférable, lors des essais système sur l'ISF, de faire des compromis en matière de précision, mais d'atteindre tout les autres objectifs, notamment de démontrer la bonne intégration, au niveau système, d'équipements tels que le SRI. La précision du système de guidage peut être démontrée efficacement par analyse et par simulation sur ordinateur.
Dans ce contexte, il convient finalement de noter que la principale méthode utilisée pour prévenir les défaillances est celle des revues, qui font partie intégrante du processus de conception et de qualification et qui sont conduites à tous les niveaux avec l'ensemble des grands partenaires du projet (avec également la participation d'experts externes). Dans un programme de cette taille, ce sont littéralement plusieurs milliers de problèmes et de défaillances potentielles qui sont résolus avec succès au cours des revues et il n'est certes pas facile de détecter des erreurs de conception de logiciel du type de celle qui a été la cause technique principale de l'échec du vol 501. Néanmoins, il est évident que les limitations du logiciel SRI n'ont pas été totalement analysées lors des revues et que l'on n'a pas pris conscience du fait que l'organisation des essais ne permettait pas de mettre en évidence ces limitations. De même, les conséquences éventuelles d'une procédure autorisant le fonctionnement du logiciel d'alignement pendant le vol n'ont pas été évaluées à leur juste valeur. A cet égard, la procédure de revue a contribué à l'échec.
Conformément au mandat qui lui a été donné, la Commission d'enquête a examiné d'autres faiblesses éventuelles de conception, notamment au niveau du système de contrôle de vol. Elle n'a relevé aucun point faible en relation avec l'accident, mais, malgré le peu de temps dont elle disposait, elle a procédé à une analyse approfondie du système de contrôle de vol sur la base de l'expérience qu'elle avait déjà acquise lors de l'analyse de la défaillance.
Cette analyse a porté sur les domaines suivants :
La Commission a également examiné les méthodes appliquées lors du programme de développement, en particulier celles qui ont été utilisées pour mettre au point les logiciels.
Les résultats de l'analyse ont été consignés dans le rapport technique et la Commission espère qu'ils contribueront à améliorer encore davantage le système de contrôle de vol d'Ariane 5 et son logiciel.
La Commission a constaté ce qui suit :
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.
Sur la base de ses analyses et de ses conclusions, la Commission d'enquête émet les recommandations ci-après :
Le contenu de ces pages relève de la seule responsabilité de leurs auteurs, et ne représente pas nécessairement le point de vue officiel de l'INRIA ni de toute autre partie. Les informations sont présentées de bonne foi, mais leur exactitude ne saurait être garantie.
