AR 501 rapport d' enquête

Rapport de la Commission d'enquête Ariane 501 Echec du vol Ariane 501 Président de la Commission : Professeur J.-L. LIONS

AVANT-PROPOS

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) SSC (Suède)
M. Jean-Luc Fauquembergue DGA (France)
M. Gilles Kahn 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 DERA (U.K.)

La Commission d'enquête a reçu pour mandat :

_ de déterminer les causes de l'échec du lancement,
_ d'analyser l'adéquation des essais de qualification et des essais de recette face aux problèmes rencontrés,
_ de recommander les actions correctives pour éliminer les causes de l'anomalie et d'autres faiblesses éventuelles des systèmes incriminés.

La Commission a commencé ses travaux le 13 juin 1996 ; elle était assistée d'un Comité technique consultatif composé de :

Dr. Mauro Balduccini (BPD)
M. Yvan Choquer (Matra-Marconi Space)
M. Rémy Hergott (CNES)
M. Bernard Humbert (Aerospatiale)
M. Eric Lefort (ESA)

Rapport de la Commission d'enquête Ariane 501

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.

1 L'ECHEC

1.1 DESCRIPTION GÉNÉRALE

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é :

un comportement nominal du lanceur jusqu'à H0 + 36 secondes ; la défaillance du système de référence inertielle de secours, suivie immédiatement par celle du système de référence inertielle actif ; le braquage en butée des tuyères des deux moteurs à propergols solides puis, quelques instants après, du moteur Vulcain, provoquant le basculement brutal du lanceur ; l'auto-destruction du lanceur déclenchée correctement par la rupture des liaisons entre les étages d'accélération à poudre et l'étage principal. 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.

1.2 INFORMATIONS DISPONIBLES

La Commission disposait pour ses travaux des informations suivantes sur le lancement :

données de télémesure reçues au sol jusqu'à H0 + 42 secondes données de trajectographie provenant des stations radar observations optiques (caméra IR, films) expertise des débris récupérés 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.

1.3 RÉCUPÉRATION DES DÉBRIS

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.

1.4 AUTRES ANOMALIES OBSERVÉES SANS RAPPORT AVEC L'ACCIDENT

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.

2 ANALYSE DE L'ECHEC

2.1 SÉQUENCE DES ÉVÉNEMENTS TECHNIQUES

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.

Le lanceur a commencé à se désintégrer à environ H0 + 39 secondes sous l'effet de charges aérodynamiques élevées dues à un angle d'attaque de plus de 20 degrés qui a provoqué la séparation des étages d'accélération à poudre de l'étage principal, événement qui a déclenché à son tour le système d'auto-destruction du lanceur ; cet angle d'attaque avait pour origine le braquage en butée des tuyères des moteurs à propergols solides et du moteur principal Vulcain ; le braquage des tuyères a été commandé par le logiciel du calculateur de bord (OBC) agissant sur la base des données transmises par le système de référence inertielle actif (SRI2). A cet instant, une partie de ces données ne contenait pas des données de vol proprement dites mais affichait un profil de bit spécifique de la panne du calculateur du SRI 2 qui a été interprété comme étant des données de vol ; la raison pour laquelle le SRI 2 actif n'a pas transmis des données d'attitude correctes tient au fait que l'unité avait déclaré une panne due à une exception logiciel ; l'OBC n'a pas pu basculer sur le SRI 1 de secours car cette unité avait déjà cessé de fonctionner durant le précédent cycle de données (période de 72 millisecondes) pour la même raison que le SRI 2 ; l'exception logiciel interne du SRI s'est produite pendant une conversion de données de représentation flottante à 64 bits en valeurs entières à 16 bits. Le nombre en représentation flottante qui a été converti avait une valeur qui était supérieure à ce que pouvait exprimer un nombre entier à 16 bits. 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 ; l'erreur s'est produite dans une partie du logiciel qui n'assure que l'alignement de la plate-forme inertielle à composants liés. Ce module de logiciel calcule des résultats significatifs avant le décollage seulement. Dès que le lanceur décolle, cette fonction n'est plus d'aucune utilité ; La fonction d'alignement est active pendant 50 secondes après le démarrage du mode vol des SRI qui se produit à H0 - 3 secondes pour Ariane 5. En conséquence, lorsque le décollage a eu lieu, cette fonction se poursuit pendant environ 40 secondes de vol. Cette séquence est une exigence Ariane 4 mais n'est pas demandé sur Ariane 5 ; l'erreur d'opérande s'est produite sous l'effet d'une valeur élevée non prévue d'un résultat de la fonction d'alignement interne appelé BH (Biais Horizontal) et lié à la vitesse horizontale détectée par la plate-forme. Le calcul de cette valeur sert d'indicateur pour la précision de l'alignement en fonction du temps ; la valeur BH était nettement plus élevée que la valeur escomptée car la première partie de la trajectoire d'Ariane 5 diffère de celle d'Ariane 4, ce qui se traduit par des valeurs de vitesse horizontale considérablement supérieures. 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.

2.2 COMMENTAIRES AU SUJET DU SCENARIO DE DÉFAILLANCE

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.

2.3 PROCÉDURES D'ESSAI ET DE QUALIFICATION

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 :

qualification des équipements, qualification des logiciels (logiciel du calculateur de bord), intégration des étages, essais de validation système. 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 :

les performances de guidage, navigation et pilotage dans la totalité du domaine de vol, le fonctionnement de la redondance des capteurs, les fonctions spécifiques des étages, la conformité du logiciel de vol (calculateur de bord) avec tous les équipements du système électrique de contrôle de vol. 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 :

la trajectoire nominale, des trajectoires dégradées par rapport aux paramètres internes du lanceur, des trajectoires dégradées par rapport aux paramètres atmosphériques, des défaillances d'équipements, suivies de leur détection et élimination. 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 consiste à le placer sur une table dynamique trois axes (pour stimuler la centrale à gyrolasers) et à remplacer la sortie analogique des accéléromètres (qui ne peuvent pas être stimulés mécaniquement) par des signaux simulés et injectés à travers un connecteur d'entrée spécifiquement conçu pour ces essais et d'une carte électronique réalisée à cet effet. Cette méthode est similaire à celle qui a été mentionnée au sujet d'un essai éventuel au niveau équipements. La deuxième consiste à remplacer à la fois la sortie analogique des accéléromètres et celle des gyrolasers par des signaux produits par simulation et injectés à travers un connecteur d'entrée conçu pour cet essai. 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 :

les SRI doivent être considérés comme entièrement qualifiés au niveau équipements ; la précision du logiciel de navigation du calculateur de bord dépend, de manière critique, de la précision des mesures des SRI. Dans l'ISF, cette précision ne pouvait être obtenue par l'électronique produisant les signaux d'essai ; la simulation des modes de défaillance est impossible avec des équipements réels ; elle ne peut être réalisée qu'avec un modèle ; la période de base du SRI est de 1 milliseconde, tandis que celle de la simulation sur l'ISF est de 6 millisecondes. Cela entraîne un surcroît de complexité au niveau de l'électronique d'interface et peut conduire à une réduction supplémentaire de la précision de la simulation. 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.

2.4 AUTRES FAIBLESSES ÉVENTUELLES DES SYSTEMES INCRIMINÉS

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 :

conception du système électrique logiciels embarqués implantés dans des sous-systèmes autres que le système de référence inertielle calculateur de bord et logiciel du programme de vol. 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.

3 CONCLUSIONS

3.1 RÉSULTATS DE L'ENQUETE

La Commission a constaté ce qui suit :

A- Au cours de la campagne de préparation du lancement et de la chronologie, il ne s'est produit aucun événement en rapport avec l'accident.

B- Les conditions météorologiques au moment du lancement étaient acceptables et n'ont joué aucun rôle dans l'accident. La Commission n'a relevé aucun autre facteur externe susceptible d'être incriminé.

C- L'allumage des moteurs et le décollage se sont, dans l'ensemble, déroulés de façon nominale, et les effets de l'environnement (bruit et vibrations) sur le lanceur et sa charge utile apparaissent sans rapport avec l'accident. La performance des propulseurs a été conforme aux spécifications.

D- 22 secondes après H0 (commande d'allumage du moteur cryotechnique principal), des variations d'une fréquence de 10 Hz ont commencé à se manifester au niveau de la pression hydraulique des vérins qui commandent l'orientation de la tuyère du moteur principal. Ce phénomène est significatif et n'a pas encore été parfaitement expliqué. L'enquête montre toutefois qu'il est sans rapport avec l'accident.

E- A H0 + 36,7 secondes (environ 30 secondes après le décollage), le calculateur du système de référence inertielle de secours, qui fonctionnait en mode de veille pour la fonction de guidage et de contrôle d'attitude, est devenu inopérant. Cette panne s'explique par le fait qu'une variable interne liée à la vitesse horizontale du lanceur a dépassé une limite inscrite dans le logiciel de ce calculateur.

F- Environ 0,05 seconde plus tard, le système de référence inertielle actif - identique du point de vue matériel et logiciel au système de secours - est tombé en panne pour la même raison. Compte tenu de la défaillance du système inertiel de secours, il est alors devenu impossible d'obtenir des données de guidage et d'attitude exactes et la perte de la mission était inévitable.

G- Du fait de sa défaillance, le système de référence inertielle actif a transmis essentiellement des informations de diagnostic au calculateur principal du lanceur, qui les a interprétées comme des données de vol et les a utilisées pour des calculs de contrôle de vol.

H- Sur la base de ces calculs, le calculateur principal a envoyé aux tuyères des étages d'accélération à poudre et, un peu plus tard, également à la tuyère du moteur principal, l'ordre de procéder à une correction importante de trajectoire par rapport à une déviation qui, en fait, ne s'était pas produite.

I- Le changement d'attitude rapide qui s'est alors produit a entraîné la désintégration du lanceur à H0 + 39 secondes sous l'effet des charges aérodynamiques.

J- La destruction du lanceur s'est déclenchée automatiquement dès sa désintégration, à 4000 m d'altitude et à 1000 m du pas de tir.

K- Les débris sont retombés sur une zone de 5 x 2,5 km². Parmi les équipements récupérés au sol figuraient les deux systèmes de référence inertielle, qui ont été utilisés aux fins d'analyse.

L- L'analyse après vol des données de télémesure a fait apparaître un certain nombre d'anomalies additionnelles qui sont en cours d'analyse, mais dont on estime qu'elles n'ont pas joué de rôle dans l'échec du lancement.

M- Le système de référence inertielle d'Ariane 5 est, pour l'essentiel, identique à un système actuellement utilisé sur Ariane 4. La partie du logiciel qui a interrompu le fonctionnement des calculateurs des systèmes de référence inertielle est utilisée avant le lancement pour aligner le système de référence inertielle, mais aussi, sur Ariane 4, pour permettre un réalignement rapide du système en cas d'interruption tardive de la chronologie. Cette fonction de réalignement, qui n'a aucune utilité sur Ariane 5, a néanmoins été maintenue pour des raisons de communité et pouvait, comme sur Ariane 4, rester active pendant une quarantaine de secondes après le décollage.

N- Lors de la conception du logiciel du système de référence inertielle d'Ariane 4 et d'Ariane 5, il a été décidé qu'il n'était pas nécessaire de protéger le calculateur de la centrale inertielle contre un arrêt de fonctionnement dû à une valeur excessive de la variable liée à la vitesse horizontale, laquelle protection a été prévue pour plusieurs autres variables du logiciel d'alignement. Cette décision de conception a été prise sans que l'on analyse ou comprenne parfaitement les valeurs que cette variable particulière pourrait prendre lorsque le logiciel d'alignement est autorisé à fonctionner après le décollage.

O- Une telle défaillance ne s'est pas produite sur les vols Ariane 4 utilisant le même système de référence inertielle, car la trajectoire pendant les 40 premières secondes du vol est telle que la variable particulière liée à la vitesse horizontale ne peut dépasser, même en tenant compte d'une marge opérationnelle adéquate, la limite inscrite dans le logiciel.

P- Ariane 5 a une accélération initiale élevée et une trajectoire telle que sa vitesse horizontale s'accroît cinq fois plus rapidement que celle d'Ariane 4. La vitesse horizontale supérieure d'Ariane 5 a généré, en l'espace de ces 40 secondes, la valeur excessive qui a entraîné l'arrêt de fonctionnement des calculateurs des systèmes de référence inertielle.

Q- Le processus des revues, auquel tous les grands partenaires d'Ariane 5 participent, a pour objet de valider les décisions de conception et d'obtenir la qualification pour le vol. Au cours de ce processus, les limitations du logiciel d'alignement n'ont pas été pleinement analysées et l'on n'a pas mesuré les conséquences que pouvait avoir le maintien de cette fonction en vol.

R- Les données de trajectoire d'Ariane 5 n'étaient pas expressément prévues dans la spécification relative au système de référence inertielle ni dans les essais au niveau équipements. En conséquence, la fonction de réalignement n'a pas été testée dans les conditions de vol simulées d'Ariane 5 et l'erreur de conception n'a pas été décelée.

S- Il aurait été techniquement possible d'inclure la quasi-totalité du système de référence inertielle dans les simulations du système complet. Pour un certain nombre de raisons, il a été décidé d'utiliser les résultats simulés du système de référence inertielle, et non le système proprement dit ou sa simulation détaillée. Si l'on avait inclus ce système, la défaillance aurait pu être décelée.

T- Des simulations après vol ont été conduites à l'aide d'un calculateur doté du logiciel du système de référence inertielle et dans un environnement simulé, en intégrant les données de trajectoire réelles du vol Ariane 501. Ces simulations ont fidèlement reproduit la séquence des événements qui ont conduit à la défaillance des systèmes de référence inertielle.

3.2 CAUSE DE L'ACCIDENT

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.

4 RECOMMANDATIONS

Sur la base de ses analyses et de ses conclusions, la Commission d'enquête émet les recommandations ci-après :

1- Inhiber la fonction d'alignement du système de référence inertielle immédiatement après le décollage. De façon plus générale, faire en sorte qu'aucune fonction logicielle ne soit active en vol, sauf en cas de nécessité.

2- Mettre en place une installation d'essais qui réunisse, dans la mesure des possibilités techniques, un maximum d'équipements réels, introduire dans cette installation des données réalistes, et procéder à des essais complets en boucle fermée au niveau systèmes. Procéder à des simulations complètes avant toute mission. Etendre la couverture des essais.

3- Interdire à tous les instruments de mesure quels qu'ils soient, par exemple au système de référence inertielle, de cesser d'envoyer les meilleures données disponibles.

4- Organiser une revue de qualification spéciale pour tous les équipements comprenant des logiciels. L'architecte industriel participera à ces revues et remettra un rapport sur les essais systèmes complets réalisés avec ces équipements. Toute restriction d'utilisation de ces équipements sera présentée de façon explicite à la commission de revue. Déclarer tous les logiciels critiques comme des produits à configuration contrôlée (CCI).

5- Revoir tous les logiciels de vol (y compris les logiciels intégrés), et en particulier :
_ identifier toutes les hypothèses implicites faites par le code et ses documents de justification sur les paramètres fournis par l'équipement. Vérifier ces hypothèses au regard des restrictions d'utilisation de l'équipement.
_ Vérifier la plage des valeurs prises dans les logiciels par l'une quelconque des variables internes ou de communication.
_ L'équipe projet proposera des solutions aux problèmes potentiels du logiciel du calculateur de bord, en mettant plus particulièrement l'accent sur la commutation de celui-ci. Ces solutions seront passées en revue par un groupe d'experts externes, qui fera rapport à la commission de qualification du calculateur de bord.

6- Chaque fois que cela sera techniquement possible, envisager de confiner les exceptions à l'intérieur des tâches et concevoir des solutions de secours.

7- Fournir davantage de données à la télémesure lorsqu'un composant quelconque tombe en panne, de façon à être moins tributaire de la récupération des équipements.

8- Redéfinir quels sont les composants critiques en tenant compte des défaillances d'origine logicielle (en particulier des points de défaillance unique).

9- Associer des participants externes (au projet) aux revues des spécifications, du code et des documents de justification. S'assurer que ces revues prennent en compte le bien-fondé de l'argumentation au lieu de contrôler que des vérifications ont été faites.

10- Intégrer les données de trajectoire dans les spécifications et les exigences d'essais.

11- Revoir la couverture des essais réalisés sur les équipements existants et l'étendre en cas de besoin.

12- Traiter les documents de justification avec autant d'attention que le code. Améliorer la technique visant à assurer la cohérence entre le code et ses justifications.

13- Mettre sur pied une équipe qui sera chargée d'élaborer la procédure de qualification des logiciels, de proposer des règles strictes de confirmation de la qualification, et de s'assurer que la spécification, la vérification et les essais des logiciels seront d'un niveau de qualité systématiquement élevé dans le programme Ariane 5. Envisager de faire appel à des spécialistes externes en matière de RAMS (Fiabilité, disponibilité, facilité de maintenance, sécurité).

14- Il y a lieu d'envisager une organisation plus transparente de la coopération entre les partenaires du programme Ariane 5. Il faut une coopération technique étroite et une définition nette des responsabilités et des mandats pour assurer la cohérence du système, avec des interfaces simples et claires entre les partenaires.