Vol 501 d'Ariane 5

La fusée a explosé à une altitude de 4 000 mètres au-dessus du centre spatial de Kourou, en Guyane. Il n'y a eu aucune victime, les débris étant retombés relativement près du pas de tir et le vol étant inhabité.

L'incident, dû à un dépassement d'entier dans les registres mémoire des calculateurs électroniques utilisés par le pilote automatique, a provoqué la panne du système de navigation de la fusée, causant de fait sa destruction ainsi que celle de la charge utile. Cette charge utile était constituée des quatre satellites de la mission Cluster, d'une valeur totale de 370 millions de dollars.

Vol 501 d'Ariane 5 et délimitation de la zone des retombées de débris.

Le vol a été largement suivi, par caméra, radar et télémesures, et le dysfonctionnement du système de guidage inertiel a été rapidement cerné par l'équipe d'enquête comme étant la cause de l'incident.

Les informations des télémesures ont été envoyées pour analyse au Centre national d'études spatiales de Toulouse, en France, tandis qu'une équipe sur place s'affairait à récupérer les débris de la fusée. La priorité a été donnée aux débris qui présentaient un risque d'incendie, tels que des réserves d'ergols non brûlés. La récupération des débris a été particulièrement difficile, du fait que cette région est essentiellement composée de mangroves et de savanes gorgées d'eau, après la saison des pluies qui venait de se terminer. Des pièces lourdes telles que les tuyères — pesant plusieurs tonnes — ont été retrouvées sous plusieurs mètres d'eau, profondément enfoncées dans la vase, et n'en ont jamais été retirées.

La récupération des deux systèmes de guidage inertiel parmi les débris de la fusée, et l'analyse des informations encore présentes dans la mémoire des appareils a permis de retracer avec précision les dernières secondes du vol. L'enquête s'est portée sur le cahier des charges du système de navigation, et les essais en laboratoire nécessaires pour obtenir l'autorisation de vol. Des simulations de vol après-coup, utilisant les systèmes de guidage inertiel et l'ordinateur de bord dans les conditions de vol réalistes d'Ariane 5, ont reproduit les évènements qui ont conduit à l'explosion de la fusée. Les résultats correspondaient aux informations retrouvées dans les mémoires des appareils qui ont servi durant le vol.

Gilles Kahn est intervenu en tant que membre de la commission d'enquête sur le vol 501 d'Ariane 5 (1996), comme coauteur avec Didier Lombard, permettant de rendre explicite le bug informatique sous-jacent.

Fragment d'un des satellites Cluster.

Dans le rapport de la commission d'enquête, les points suivants ont été soulevés :

• Des essais de chaines fonctionnelles sur table ont en principe lieu avant le décollage. En effet une centrale inertielle mesure des grandeurs physiques, telles qu'accélération et vitesse angulaire, qui sont très difficiles à reproduire en laboratoire. Les essais en laboratoire consistent à remplacer les mesures de la centrale inertielle par des valeurs simulées artificiellement. La réussite de ces simulations est une condition nécessaire pour obtenir le certificat d'aptitude au vol. Le système de navigation, utilisé depuis longtemps sur Ariane 4, était réputé fiable et le Centre national d'études spatiales a tout simplement demandé à ne pas effectuer les simulations de vol pour ces appareils, ce qui devait ainsi lui permettre d'économiser 800 000 francs sur le coût des préparatifs avant lancement. Or, si ces chaines étaient fonctionnelles sur Ariane 4, elles se sont révélées non compatibles avec le nouveau lanceur. Réalisées en laboratoire après la catastrophe, ces simulations ont justement permis de vérifier que l'accident était inéluctable.
• Le bug qui a causé la mise hors service des systèmes de guidage-pilotage à centrales inertielles est causé par la procédure d'étalonnage de l'appareil. Dans un usage normal, cet étalonnage s'effectue au sol et mesure donc de très faibles valeurs d'accélération puisque la fusée est immobile. Pour ce faire, le logiciel transcrit les mesures d’accélérations horizontale et verticale (des flottants codés sur 64 bits) en entiers signés codés sur 16 bits. Or, le programme Ariane 4 a fait le choix de laisser l'appareil en mode calibrage une quarantaine de secondes[2] après le décollage. Ce choix qui date du début du programme Ariane, plus de dix ans avant l'accident, était motivé par le fait que sur les premières fusées Ariane, en cas de report du décollage, il était nécessaire de relancer la procédure de calibrage, qui durait plus de 45 minutes. Cette fonctionnalité, héritée d'Ariane 4 n'a plus d'utilité pour Ariane 5 et a parasité son système de navigation inertielle.
• Pour ne pas saturer la mesure de l’accélération verticale au décollage, le logiciel effectue un écrêtage de sa représentation entière à -32768 et +32767 (extremums pour 16 bits) pour ne pas générer de message d'erreur de dépassement d'entier. Mais cette précaution n'a pas été prise pour l'accélération horizontale car le risque de saturation n'était pas identifié pour Ariane 4. Malheureusement, il se produit avec Ariane 5, plus puissante et qui génère des accélérations de vol plus élevées. Faute de protection, un signal d'erreur a donc été envoyé[2] - [3].
• L'arrêt automatique du système de guidage inertiel principal, en cas d'avarie, était un choix de conception décidé longtemps avant l'incident. La possibilité d'une avarie simultanée des deux systèmes de guidage (principal et secours) n'avait pas été envisagée et ses conséquences n'avaient donc pas été anticipées avant le décollage d'Ariane 5. D'une manière générale, le cahier des charges du programme Ariane est axé sur des erreurs aléatoires et momentanées des appareils. Dans ces cas, un appareil de secours identique fait généralement l'affaire. Le problème vient du fait que les deux appareils étaient de conception strictement identiques et, de ce fait, ce qui cause la panne de l'un d'entre eux a toutes les raisons de mettre en défaut le deuxième. On a donc un mode de défaillance commun conduisant à « perdre » les deux centrales en même temps, ce qui laisse le pilotage automatique de la fusée dans le flou le plus complet.
• En effet, selon le cahier des charges de la centrale inertielle, une erreur informatique au sein de l'appareil doit entraîner son arrêt immédiat, l'erreur doit être inscrite dans une mémoire permanente de l'appareil (EEPROM), et un signal de panne doit être transmis aux autres appareils. C'est le choix de conception d'arrêter l'appareil en cas d'incident qui a été fatal à Ariane 5.

Après enquête, les ingénieurs du CNES se sont aperçus que par mesure d'économie, le logiciel de navigation de la fusée Ariane 5 était celui qui avait été conçu pour Ariane 4[4], ce qui a induit une incompatibilité entre le logiciel et le matériel.

Tout tenait au maintien de la fonction d'alignement (décidée pour Ariane 4 mais inutile pour Ariane 5) et à la valeur de l'accélération horizontale, plus élevée sur Ariane 5 mais pour laquelle il n'avait pas été prévu de protection contre le risque d'être saturés par une valeur trop grande (car il existait une marge de sécurité suffisante sur Ariane 4). C'est pourtant le dépassement d'une valeur non protégée qui a provoqué la mise en panne des deux centrales inertielles. La centrale active (SRI 2) a émis des messages d'erreur ASCII qui ont été interprété comme des données de vol produisant un comportement inadapté du lanceur (braquage de tuyères) et sa destruction sous des charges aérodynamiques hors norme. En conséquence, le logiciel décida de l'autodestruction de la fusée[5].

C'est ainsi que, par effet domino, la saturation d'une donnée inutile, a conduit à la perte du vol.