Vol 501 d'Ariane 5: hypothèses logicielles héritées et responsabilité

Résumé

• La commission d'enquête indépendante a établi une chaîne technique précise. Une valeur à virgule flottante sur 64 bits associée au biais horizontal a dépassé la plage d'un entier signé sur 16 bits dans une fonction d'alignement héritée d'Ariane 4. La conversion non protégée a déclenché une erreur d'opérande. La réponse spécifiée a arrêté chaque processeur de référence inertielle, et les deux unités identiques sont tombées en panne à environ un cycle de données d'intervalle.
• La conversion a été l'élément déclencheur, pas une cause racine institutionnelle suffisante. Ariane 5 n'avait pas besoin de la fonction d'alignement après le décollage; l'exigence de synchronisation d'Ariane 4 a été maintenue pour la commonality; les données de trajectoire d'Ariane 5 ont été omises de la spécification du système inertiel; et les tests en boucle fermée représentatifs utilisaient des sorties inertielles simulées au lieu des unités réelles ou d'un modèle détaillé.
• Le contrôle était distribué mais identifiable. L'ESA possédait le programme et a délégué la gestion du développement d'Ariane 5 au CNES. Le CNES, l'architecte industriel, le fournisseur du système inertiel et d'autres partenaires contractuels contrôlaient différentes spécifications, décisions de conception, revues et tests. La commission a déclaré que la décision de laisser certaines conversions non protégées avait été prise conjointement à plusieurs niveaux contractuels, de sorte que le dossier ne permet pas de réduire la responsabilité à un programmeur anonyme.
• La redondance n'a pas assuré l'indépendance. Les deux systèmes inertiels avaient un matériel et un logiciel identiques et ont rencontré la même condition déterministe. La sauvegarde a donc reproduit la défaillance de l'unité active au lieu de l'absorber. La défaillance de commande ultérieure dépendait également d'une interface qui permettait à des mots de diagnostic d'une unité défaillante d'être interprétés comme des données de vol.
• L'impact direct est confirmé: le lanceur et les quatre satellites Cluster ont été détruits environ quarante secondes après le séquence d'allumage du moteur principal. L'ESA a ensuite estimé un impact financier de 288 millions d'ECU pour l'achèvement de la qualification d'Ariane 5, tandis que la mission de récupération Cluster II a été approuvée dans une enveloppe de 214 millions d'ECU. Ces chiffres de programme ne sont pas interchangeables avec un total de dommages unique.
• Les preuves de réparation sont substantielles mais limitées. L'ESA et le CNES ont accepté les quatorze recommandations, créé plus de quarante actions détaillées, modifié le comportement des exceptions du SRI, élargi les tests au niveau système avec du matériel réel et l'injection de trajectoire, rendu les logiciels embarqués séparément contrôlés en configuration, établi un rôle d'architecte logiciel et utilisé une revue externe. Le vol 503 a achevé la qualification avec succès en 1998, et la qualification formelle a suivi en 1999. Les archives publiques n'exposent pas tous les résultats de test, les dossiers de décision des fournisseurs ou les audits à long terme nécessaires pour prouver la cohérence de toutes les réformes.

Le dépassement est le déclencheur, pas l'explication complète

Le vol 501 est devenu l'une des mises en garde les plus répétées de l'ingénierie logicielle parce que son défaut immédiat est facile à énoncer. Un programme a tenté de convertir une valeur trop grande pour le type de destination, une exception s'est produite, et la fusée a été perdue. Cette description est exacte dans la mesure où elle va. Elle dépouille également la plupart des décisions qui ont rendu une conversion capable de détruire un lanceur.

La commission indépendanterapport officiel, daté du 19 juillet 1996, n'a pas traité l'événement comme un crash logiciel mystérieux. Il a retracé une chaîne causale depuis la désintégration aérodynamique en arrière jusqu'aux commandes de tuyère, aux données inertielles invalides, à l'arrêt du processeur, à la conversion non protégée, à la fonction d'alignement héritée, à la trajectoire d'Ariane 5 et aux tests et spécifications qui n'avaient pas réuni ces éléments. La commission a également énoncé les limites de son travail. Un rapport technique séparé avait une diffusion restreinte; la commission publique n'avait pas effectué une évaluation complète de toute la télémétrie ni une revue complète de chaque système du lanceur. Ses conclusions sont autoritaires dans ce périmètre, pas une archive publique de chaque fait d'ingénierie et contractuel.

Cette limite est importante pour la responsabilité. Les preuves publiques sont suffisamment solides pour établir la séquence technique et plusieurs défaillances de contrôle organisationnelles. Elles ne sont pas assez solides pour attribuer des motivations privées, déterminer les dommages contractuels, reconstruire chaque approbation interne ou nommer un individu comme cause unique.

Le langage de la commission lui-même détourne l'attention de cette simplification: les choix de conception pertinents étaient partagés entre partenaires du projet et niveaux contractuels, tandis que la revue et la qualification impliquaient les principaux entités du programme.

La question utile n'est donc pas de savoir qui a tapé l'instruction de conversion. C'est de savoir qui contrôlait si la fonction devait encore exister, quel domaine numérique elle devait tolérer, ce qu'une exception devait faire, si les deux voies redondantes pouvaient tomber en panne de manière identique, quelles données une voie défaillante pouvait placer sur le bus, quel équipement réel entrait dans les tests de bout en bout, et quelles preuves les commissions de qualification exigeaient avant le vol. Chaque question a un propriétaire différent.

Ensemble, elles expliquent pourquoi une instruction localement compréhensible est devenue une défaillance au niveau de la mission.

Ce que l'enquête publique a réellement confirmé

La chronologie a commencé normalement. Lepremier communiqué officiel d'informationde l'ESA a enregistré l'allumage du moteur principal à 09:33:59 heure locale à Kourou, soit 12:33:59 TU, le 4 juin 1996. Les propulseurs solides se sont allumés 7,5 secondes plus tard et le lanceur a décollé. Le guidage et la trajectoire sont restés normaux jusqu'à environ H0 plus 37 secondes. La télémétrie a ensuite montré les deux tuyères des propulseurs solides se déplaçant à leurs limites; le véhicule a basculé brusquement, s'est brisé sous les charges aérodynamiques et a été détruit par son système de neutralisation embarqué après la perte d'intégrité structurelle.

Les performances de propulsion initiales étaient normales. Ce fait précoce a empêché l'enquête de se fixer sur la désintégration ou l'explosion visible comme cause. La direction de l'enquête s'est déplacée vers le système électrique et logiciel. L'ESA et le CNES ont ensuite donné à une commission indépendante l'autorité de déterminer la cause, d'examiner si les tests de qualification et d'acceptation étaient appropriés, et de recommander des actions correctives. Lemandat du 10 juinpromettait également l'accès aux équipes industrielles, aux documents et au matériel. Ce mandat est une preuve importante du périmètre: l'adéquation des tests n'était pas un ajout ultérieur d'un commentateur mais une question explicite assignée à l'enquête.

La récupération physique a aidé à combler le fossé probatoire. Une grande partie de la baie d'équipement du véhicule a été récupérée, et lepoint du 14 juinde l'ESA a signalé un dysfonctionnement impliquant les plates-formes inertielles en mode opérationnel d'Ariane 5. Les deux systèmes de référence inertielle, ou SRI, ont finalement été récupérés. La mémoire de l'unité défaillante en dernier a fourni des informations non entièrement disponibles dans la télémétrie, car la transmission détaillée des défaillances avait été attribuée à l'unité défaillante en premier. Les enquêteurs ont comparé ces contenus mémoire avec le code source, la télémétrie, le radar, les observations optiques et la simulation post-vol.

La commission a constaté que le SRI de sauvegarde est devenu inopérant à environ H0 plus 36,7 secondes. Environ 0,05 seconde plus tard, le SRI actif est tombé en panne pour la même raison. Dans la séquence plus détaillée, les unités étaient séparées par un cycle de données de 72 millisecondes. L'unité active a ensuite transmis un motif binaire de diagnostic. L'ordinateur de bord a interprété ce motif comme des données de vol et a généré de grandes commandes de tuyère pour une déviation d'attitude qui ne s'était pas produite.

À environ H0 plus 39 secondes, un angle d'attaque supérieur à 20 degrés a produit des charges qui ont séparé les propulseurs de l'étage principal et déclenché la neutralisation.

Le rapport a étayé cette chaîne de manière exceptionnelle. Les enquêteurs ont reproduit les événements internes du SRI en simulation, lu le contexte de défaillance de la mémoire récupérée et trouvé le code cohérent avec le scénario. La simulation post-vol utilisant la trajectoire réelle du vol 501 a reproduit la séquence. Laprésentation publiée du rapport de la commissionpar l'ESA a résumé la conclusion comme des erreurs de spécification et de conception dans le logiciel de référence inertielle combinées à une analyse et des tests inadéquats du SRI et du système complet de contrôle de vol.

Plusieurs anomalies observées ont été exclues. Les conditions météorologiques étaient acceptables. La propulsion était dans les spécifications. Les variations de pression dans les actionneurs de la tuyère du moteur principal étaient suffisamment significatives pour être étudiées mais ont été jugées sans rapport avec la défaillance. Le système de destruction a agi après que le lanceur se soit déjà désintégré; il n'a pas causé la perte. Ces constatations négatives font partie d'une reconstruction disciplinée. Elles empêchent le récit d'accumuler chaque anomalie dans une fausse histoire multi-cause.

Quarante secondes contenaient plusieurs défaillances différentes

La première fonction logicielle pertinente était l'alignement. Le SRI utilisait des gyrolasers et des accéléromètres et calculait les angles et les vitesses dans son propre ordinateur. Son logiciel d'alignement était significatif avant le lancement, lorsque le véhicule occupait une position fixe connue. Une exigence héritée d'Ariane 4 permettait au traitement d'alignement de continuer pendant cinquante secondes après le début du mode vol du SRI, de sorte qu'un retard de compte à rebours tardif pouvait être récupéré sans répéter un long alignement. Ariane 5 entrait en mode vol SRI trois secondes avant H0.

La fonction s'est donc poursuivie pendant environ quarante secondes après le décollage même si Ariane 5 n'en avait pas besoin opérationnellement.

La deuxième défaillance était une hypothèse de domaine. Dans le processus d'alignement, une valeur interne appelée BH, ou biais horizontal, était liée à la vitesse horizontale et indiquait la précision de l'alignement. Ariane 5 construisait la vitesse horizontale beaucoup plus rapidement qu'Ariane 4 pendant la période pertinente. La commission a décrit l'accumulation comme cinq fois plus rapide. Une valeur qui restait dans la marge héritée d'Ariane 4 a donc dépassé la plage supposée du nouveau véhicule alors que le code d'alignement obsolète était toujours en cours d'exécution.

La troisième défaillance était la conversion non protégée. Le logiciel convertissait la valeur BH à virgule flottante sur 64 bits en un entier signé sur 16 bits. Des conversions comparables avaient été identifiées comme sources possibles d'erreur d'opérande. Sept variables avaient été considérées à risque; quatre ont reçu une protection et trois non. Le rapport n'a trouvé aucune justification dans le code source pour laisser les trois non protégées, bien que le raisonnement sous-jacent existât dans un ensemble documentaire plus large. La croyance était que ces valeurs étaient physiquement limitées ou avaient une grande marge de sécurité.

Ce raisonnement était erroné pour BH sous la trajectoire d'Ariane 5.

La charge de travail du processeur a influencé la décision de protection. La commission a été informée que l'ordinateur du SRI avait un objectif de charge de travail maximal de 80 %, de sorte que toutes les conversions n'étaient pas protégées. Ce fait n'établit pas que les limites de ressources rendaient la défaillance inévitable. Il montre qu'un compromis a été fait entre le calcul, la protection contre les exceptions et les limites physiques supposées. La responsabilité s'attache aux preuves utilisées pour le compromis.

Si une conversion reste exposée parce qu'une quantité est supposée ne jamais franchir une limite, la limite et les conditions de mission la soutenant doivent être explicites, revues et testées.

La quatrième défaillance était la politique d'exception. Une erreur d'opérande n'aurait pas dû détruire la mission par elle-même. La spécification du SRI exigeait qu'une exception détectée soit annoncée sur le bus de données, le contexte stocké en mémoire et le processeur arrêté. Le redémarrage était impraticable car l'attitude ne pouvait pas être facilement reconstruite. La commission a retracé cette politique à une architecture centrée sur les défaillances matérielles aléatoires: lorsqu'une unité physique tombe en panne, un double peut prendre le relais.

Une erreur de conception logicielle déterministe viole cette hypothèse car le double peut rencontrer la même condition.

La cinquième défaillance était la redondance en mode commun. Les deux SRI fonctionnaient en parallèle avec un matériel et un logiciel identiques. L'un était actif et l'autre en veille chaude. Cette disposition protégeait contre certaines défaillances matérielles indépendantes, mais elle ne créait pas de diversité de conception. Les deux unités calculaient la même fonction à partir du même domaine de vol et s'arrêtaient à cause de la même condition logicielle. La sauvegarde est tombée en panne en premier, supprimant invisiblement la voie de récupération restante juste avant que la voie active ne tombe en panne.

La sixième défaillance était la sémantique d'interface. Le SRI actif défaillant émettait des informations de diagnostic sur le bus sous une forme que l'ordinateur de bord traitait comme des données d'attitude. Une frontière de défaillance solide distinguerait les valeurs de navigation valides, les valeurs périmées de meilleur effort, l'invalidité explicite et les charges utiles de diagnostic afin qu'une ne puisse être acceptée comme une autre. Le vol 501 a plutôt transformé une défaillance de processeur en commandes erronées.

La désintégration a donc nécessité plus qu'un dépassement: elle a nécessité l'arrêt des deux voies et l'acceptation de données non-vol dans la chaîne de contrôle.

Ces distinctions sont opérationnellement importantes. Le déclencheur était la conversion hors plage. Le mode de défaillance immédiat était l'arrêt du processeur. La défaillance de redondance était la réponse identique des deux SRI. Le mécanisme de propagation était les données de diagnostic interprétées comme du guidage. La perte physique a suivi une déviation extrême de la tuyère et un chargement aérodynamique. La cause racine institutionnelle se trouvait en amont dans les exigences réutilisées, les limites non divulguées, la visibilité logicielle et la qualification non représentative.

Appeler tout cela un dépassement cache les contrôles qui auraient pu interrompre la chaîne.

L'historique de service hérité a été pris à tort pour une preuve dans le nouveau domaine

La réutilisation du logiciel n'était pas intrinsèquement imprudente. Le logiciel SRI d'Ariane 4 avait un historique de service, et modifier un code stable peut introduire de nouveaux défauts. La commission a enregistré la justification de la commonality comme une présomption que le logiciel qui fonctionnait bien sur Ariane 4 ne devrait pas être modifié sauf si nécessaire. C'est une préoccupation de départ raisonnable, mais ce n'est pas une preuve de qualification pour un lanceur différent.

L'unité de réutilisation pertinente n'était pas seulement le code source. Elle comprenait les exigences de synchronisation, les plages numériques, les hypothèses de charge du processeur, la politique d'exception, le comportement du bus, la logique de redondance, les substitutions de test et les documents de justification. Ariane 5 a hérité d'un ensemble de décisions de conception d'un véhicule avec une séquence de préparation et une trajectoire précoce différentes. L'exécution continue de la fonction d'alignement était utile pour Ariane 4 et inutile pour Ariane 5.

Son argument de sécurité numérique était valide uniquement dans un domaine de trajectoire qui ne s'appliquait plus.

Voilà pourquoi un historique réussi peut être trompeur. Un composant peut être sans défaut dans les conditions exactes qui préservent ses hypothèses. La réutilisation modifie le système environnant: entrées, vitesses, synchronisation, interfaces, ressources, conséquences des défaillances et options de récupération. Le fait qu'Ariane 4 n'ait jamais dépassé la plage de conversion de BH montrait une compatibilité avec Ariane 4, pas une propriété universelle du logiciel.

La commission a constaté que les données de trajectoire d'Ariane 5 avaient été conjointement exclues des exigences et spécifications du SRI. Elle a également constaté que les restrictions de mise en œuvre n'étaient pas déclarées dans la spécification système. Ce sont des défaillances liées. Sans une exigence décrivant le nouveau domaine d'entrée, le fournisseur n'était pas obligé de qualifier l'unité par rapport à celui-ci. Sans une restriction déclarée décrivant l'ancien domaine, les réviseurs système manquaient d'une incompatibilité visible à contester.

Le contrat pouvait donc sembler satisfait alors que l'adéquation à la mission restait non prouvée.

Le dossier de normalisation européen ultérieur rend ce point explicite sans prétendre qu'un document ultérieur régissait 1996. Lemanuel ECSS pour la réutilisation de logiciels existantstraite désormais la sélection, l'achèvement de la qualification, la qualification des outils et la gestion des risques de réutilisation comme des activités dédiées pour les systèmes de lancement, spatiaux et au sol. Lanorme actuelle d'assurance des produits logicielsapplique des exigences d'assurance au développement et à la maintenance pour les lanceurs, les engins spatiaux, les charges utiles et les installations associées. Ces publications sont des références ultérieures, pas une preuve que le vol 501 a directement produit chaque clause. Elles montrent ce qu'un cadre de contrôle mature doit rendre explicite: la réutilisation est une nouvelle affirmation d'assurance limitée à une application particulière.

La NASA a tiré la même leçon dans son propre matériel institutionnel. Uneentrée des leçons apprises de la NASA sur la conversion numériqueutilise le vol 501 pour avertir qu'un dépassement peut désactiver les deux chaînes dans un système double chaîne. Uneleçon séparée sur le micrologiciel de navigation réutilisésouligne qu'un module acceptable dans une application peut être inacceptable dans une autre. Ce sont des leçons institutionnelles secondaires construites à partir de l'enquête, pas de nouvelles preuves sur qui a pris les décisions Ariane. Leur valeur est qu'elles traduisent l'accident en contrôles réutilisables plutôt que de le préserver comme folklore.

Les tests étaient extensifs, mais la frontière de test décisive était erronée

Le programme Ariane 5 n'a pas sauté les tests. La commission a décrit la qualification de l'équipement, la qualification du logiciel de l'ordinateur de bord, l'intégration des étages et la validation système. Elle a également noté une documentation d'ingénierie solide et des revues extensives. Une affirmation selon laquelle le lanceur n'était simplement pas testé serait inexacte et inutile. La défaillance provenait de ce que l'architecture de test supposait que chaque niveau avait déjà prouvé.

Au niveau de l'équipement, le SRI a été rigoureusement testé contre les conditions environnementales, à certains égards au-delà des attentes d'Ariane 5. Il n'a pas été testé avec le compte à rebours, la synchronisation de vol et la trajectoire d'Ariane 5. La commission a déclaré qu'un test au sol aurait pu injecter des signaux accélérométriques dérivés des paramètres de vol prédits tandis qu'une table tournante représentait le mouvement angulaire. Si cet équipement ou ce test d'acceptation avait été effectué, le mécanisme de défaillance aurait été exposé.

Au niveau système, l'Installation de simulation fonctionnelle a exécuté de nombreuses simulations en boucle fermée. Elle modélisait le segment sol, la télémétrie, la dynamique du lanceur, les trajectoires nominales et dégradées, les défaillances d'équipement, l'isolement et la récupération. De nombreux équipements réels étaient présents. Les deux SRI ne l'étaient pas. Des modules logiciels simulaient leurs sorties. Les tests utilisant le SRI réel vérifiaient l'intégration électrique et la conformité au bus de bas niveau, pas son comportement complet sous la nouvelle trajectoire.

Cette substitution a créé un problème d'assurance circulaire. Le simulateur représentait la sortie attendue d'un SRI fonctionnel, donc il n'exécutait pas le code d'alignement interne hérité qui pouvait échouer. Les tests d'équipement étaient supposés avoir couvert l'unité, tandis que les tests système remplaçaient l'unité parce qu'elle était supposée qualifiée. Aucun des deux niveaux n'a exercé l'interaction entre l'implémentation réelle du SRI et le domaine de vol réel d'Ariane 5. La commission a constaté que l'inclusion de la quasi-totalité du SRI dans la simulation système était techniquement réalisable et aurait détecté la défaillance.

Ce n'était pas une exigence de mettre tous les composants physiques dans chaque test. La commission a reconnu les limites pratiques. Le contrôle est le chevauchement: lorsqu'un composant est simulé à un niveau, les réviseurs doivent vérifier que les niveaux antérieurs ont couvert le comportement omis et que le simulateur préserve chaque caractéristique pertinente pour le test de niveau supérieur. Une simulation n'est pas représentative parce qu'elle produit des données nominales plausibles. Elle ne l'est que si ses omissions ne peuvent pas cacher les modes de défaillance sous enquête.

Letravail ultérieur de la NASA sur les meilleures pratiques de guidage, navigation et contrôleénonce la leçon comme des tests sur toute la gamme des profils de mission avec des composants nominaux, défaillants et dégradés sur la plateforme hôte pertinente. Une autreévaluation des accidents réels par le Centre d'ingénierie et de sécurité de la NASAcartographie le vol 501 sur l'analyse de l'héritage, la redondance en mode commun, les tests de bout en bout, les bases de données de trajectoire et le confinement des défaillances. Encore une fois, ces sources fournissent une référence ultérieure autoritaire, pas un accès indépendant aux fichiers confidentiels d'Ariane.

La détection avait également une dimension temporelle. La simulation post-vol a reproduit la défaillance avec les entrées de trajectoire réelles. Le mécanisme n'était donc pas au-delà de la capacité de modélisation; les données et l'implémentation décisives n'avaient pas été combinées avant le vol. Un dossier de responsabilité utile demanderait quand chaque partie possédait la trajectoire, le code SRI ou modèle, l'exigence de synchronisation, l'hypothèse de plage et l'autorité d'exiger une exécution intégrée. Le rapport public établit que l'opportunité existait.

Il ne publie pas une chronologie complète de routage des documents montrant exactement où l'obligation d'intégration aurait dû être appliquée en premier.

Qui avait le contrôle pratique

L'ESA était le propriétaire du programme. Son communiqué contemporain indique qu'elle a délégué la gestion du développement d'Ariane 5 au CNES. L'ESA a également sélectionné et financé le programme plus large par l'intermédiaire de sa structure d'États membres, nommé la commission d'enquête avec le CNES, accepté le plan de récupération et conservé la responsabilité des vols de qualification. Cela donnait à l'ESA le contrôle sur les exigences du programme, la gouvernance, les ressources, les attentes de qualification et sur la question de savoir si les preuves présentées par les organismes délégués étaient suffisantes pour le vol.

Le CNES détenait la gestion déléguée du développement et un rôle technique central. Il participait aux spécifications et à la qualification, recevait et traitait la télémétrie à Toulouse, rejoignait l'ESA dans l'enquête et approuvait ensuite les définitions logicielles et les plans de qualification aux côtés de l'architecte industriel. La délégation ne rendait pas l'ESA hors de propos, et la propriété de l'ESA ne faisait pas du CNES un simple observateur. La responsabilité suivait la répartition réelle de l'autorité de programme et d'ingénierie.

L'architecte industriel contrôlait la cohérence système entre les équipements fournis par plusieurs entreprises. Avant le vol 501, les logiciels embarqués étaient largement traités comme faisant partie de l'équipement matériel plutôt que comme un élément de configuration séparément visible. Le dossier post-accident indique que sa conception détaillée et ses effets sur le logiciel ailleurs dans le lanceur étaient insuffisamment connus au niveau du programme. Ce fossé de visibilité limitait la capacité de l'architecte, ou les preuves requises de lui, à contester une fonction d'équipement héritée comme étant un danger système.

Le fournisseur du SRI contrôlait la mise en œuvre détaillée dans les limites de sa spécification, y compris la gestion de la conversion et le comportement du processeur. Mais la commission a explicitement déclaré que le fournisseur suivait une exigence selon laquelle toute exception détectée devait arrêter le processeur. Elle a également déclaré que les décisions de protection avaient été prises conjointement par les partenaires du projet à plusieurs niveaux contractuels et que les données de trajectoire avaient été conjointement exclues des exigences du SRI.

Les preuves ne soutiennent donc pas le transfert de l'ensemble de la défaillance au fournisseur du composant ou à un développeur logiciel individuel.

Les organismes de qualification et de revue contrôlaient l'acceptation. Leur but était de valider les décisions de conception et d'obtenir la qualification de vol. Ils pouvaient exiger des restrictions, des preuves de plage, une couverture de test et des démonstrations intégrées. La commission a constaté que la revue n'avait pas pleinement analysé les limites du logiciel d'alignement ou les implications de la poursuite du fonctionnement en vol. Un processus de revue peut être procéduralement complet tout en étant substantiellement faible s'il vérifie qu'une analyse existe sans contester les hypothèses à l'intérieur.

Le rôle d'Arianespace était différent. Elle était responsable de l'exploitation des systèmes de lancement Ariane et a participé à la présentation de la récupération, mais le vol 501 était un vol de qualification de l'ESA dans le cadre du programme de développement. Les preuves publiques utilisées ici ne montrent pas qu'Arianespace contrôlait l'exigence du SRI ou la décision d'omettre le comportement réel du SRI de la simulation. Attribuer une responsabilité de conception simplement parce qu'elle a ensuite exploité le lanceur dépasserait le dossier.

La communauté scientifique Cluster et le public ont subi les conséquences sans contrôler le logiciel du lanceur. La propre revue de l'ESA surpourquoi Cluster a été attribué au vol 501indique que le calendrier et une opportunité de lancement financièrement attractive ont motivé le choix; les comités consultatifs et les investigateurs principaux ne se sont pas opposés, et la décision a été considérée comme rationnelle à l'époque. Ce dossier ne prouve pas que la communauté des charges utiles a accepté un risque logiciel non divulgué. Il montre que le risque du premier vol était visible consciemment à un niveau général tandis que le défaut de qualification spécifique ne l'était pas.

Le contrôle était donc distribué, mais pas dissous. L'ESA pouvait définir l'assurance et la qualification du programme. Le CNES pouvait gérer le développement et exiger des preuves techniques. L'architecte industriel pouvait intégrer les restrictions et le comportement inter-équipements. Les fournisseurs pouvaient exposer les limites de mise en œuvre et tester leurs unités. Les comités de revue pouvaient retenir la qualification. Chaque couche avait une opportunité de prévention ou de détection. L'absence d'un contrôleur unique n'est pas l'absence d'un contrôle responsable.

L'impact a été une perte de programme, un retard scientifique et une nouvelle décision de financement

Le lanceur et les quatre satellites Cluster ont été détruits. La mission avait été conçue pour étudier l'interaction du vent solaire avec la magnétosphère terrestre en utilisant des mesures simultanées de quatre satellites. Un satellite survivant ne pouvait pas fournir la science de formation tridimensionnelle prévue. L'historique de la mission Clusteractuel de l'ESA enregistre qu'un remplacement a été assemblé à partir de pièces de rechange, trois autres satellites et leurs instruments ont été commandés, et deux lanceurs Soyouz avec de nouveaux étages supérieurs Fregat ont finalement transporté les paires en 2000.

La perte représentait des années de travail d'un réseau industriel et scientifique international. Les satellites originaux et de remplacement impliquaient un contractant principal dirigeant 35 contractants majeurs, onze instruments sur chaque satellite et une communauté scientifique s'étendant à travers les États membres de l'ESA et d'autres pays. La conséquence n'était pas seulement la valeur marchande du matériel détruit. Les équipes ont dû préserver l'expertise, reproduire des composants indisponibles, modifier les opérations, requalifier les unités de remplacement et attendre quatre ans pour la capacité d'observation prévue.

Le récit de l'ESA surla résurrection de Clusterenregistre les options envisagées après l'échec: un satellite Phoenix à partir de pièces de rechange, de nouveaux satellites de taille réelle, des satellites nationaux plus petits et des arrangements de lancement alternatifs. Le Comité du programme scientifique a approuvé une option Cluster II à quatre satellites dans une enveloppe de 214 millions d'ECU. C'est une décision de programme confirmée, pas une valorisation des satellites originaux et pas une indemnité civile.

La récupération d'Ariane 5 avait sa propre mesure financière. L'ESA et le CNES ont estimé en septembre 1996 que l'impact jusqu'à la fin de la qualification serait de 288 millions d'ECU. Leplan de récupération de la qualificationproposait de réaffecter les fonds du programme Ariane, d'ajouter des fonds de développement, d'obtenir une contribution de l'industrie et d'utiliser les revenus d'une charge utile commerciale du vol 503. Ce chiffre ne doit pas être ajouté mécaniquement à l'enveloppe de 214 millions d'ECU de Cluster II et décrit comme une perte complète. Les périmètres diffèrent, et les archives publiques n'établissent pas si chaque poste budgétaire était incrémental, transféré ou finalement dépensé selon l'estimation.

La récupération elle-même comportait des contraintes. Le matériel d'ingénierie de l'ESA sur leconcept d'opérations de Cluster IIindique que la nouvelle mission était plafonnée à moins de la moitié du coût original. L'obsolescence du matériel a forcé des changements, l'infrastructure au sol a évolué, le personnel expérimenté était parti et le temps de test avec chaque modèle de vol a été réduit. La mission a préservé le retour scientifique, mais elle l'a fait via un autre problème contrôlé de réutilisation et de requalification. Ce dossier illustre une conséquence économique plus large d'une défaillance technique: le programme de réparation hérite de la pression de calendrier et de budget de l'événement qu'il tente de corriger.

Aucun dossier public utilisé ici n'identifie de victimes du vol 501, et la désintégration s'est produite dans la zone de lancement contrôlée. Le rapport d'ingénierie post-vol de l'ESA décrivait la surveillance environnementale et la récupération des débris, y compris une zone de retombée mesurée près du pas de tir et aucune pollution gazeuse détectée au sol en dehors de la zone de lancement. Ces faits ne rendent pas la perte mineure. Ils limitent correctement les revendications humaines et environnementales tout en laissant visibles les conséquences financières, scientifiques et de programme confirmées.

Le plan correctif a changé à la fois le code et l'autorité

La commission a fait quatorze recommandations. La première couche concernait la chaîne directe: arrêter l'alignement immédiatement après le décollage; empêcher les logiciels inutiles de s'exécuter en vol; empêcher les capteurs de cesser toute sortie utile; confiner les exceptions lorsque c'est réalisable; et reconsidérer les défaillances de mode commun d'origine logicielle lors de la définition des composants critiques. Ces changements ciblaient la durée de vie des fonctions, le confinement des exceptions et le fonctionnement dégradé plutôt que seulement élargir un entier.

La deuxième couche concernait les preuves. La commission a appelé à une installation avec autant d'équipement réel que techniquement réalisable, des entrées réalistes et des tests complets en boucle fermée avant chaque mission. Elle a exigé des données de trajectoire dans les spécifications et les exigences de test, une revue de la couverture des équipements existants, des restrictions d'exploitation explicites, une vérification de la plage pour les valeurs internes et communiquées, et une attention égale au code et aux documents de justification. Cela a converti les hypothèses de connaissances de fond en artefacts de qualification.

La troisième couche concernait la gouvernance. Les logiciels critiques devaient devenir un élément séparément contrôlé en configuration. Les équipements contenant des logiciels recevraient des revues de qualification spécifiques, avec la participation de l'architecte industriel et un rapport sur les tests système complets. Des entités externes examineraient les spécifications, le code et la justification, et l'organisation devait avoir une autorité, des responsabilités et des interfaces plus claires.

Lerapport d'ingénierie détaillé de l'ESA sur le vol 501 à 502rapporte que toutes les recommandations sont devenues un plan de plus de quarante actions. Les changements du SRI comprenaient la suppression de l'alignement en vol, l'évitement de l'arrêt du processeur, le gel des valeurs au dernier état valide si un processeur s'arrêtait, l'amélioration de la gestion des exceptions et la suppression des fonctions non utilisées en vol. L'Installation de simulation fonctionnelle a gagné des interfaces pour un processeur SRI réel, une plateforme gyrométrique sur table tournante, des maquettes d'étage supérieur et de contrôle d'attitude, et des actionneurs électriques d'étage principal.

La gouvernance a changé en parallèle. L'architecte industriel a officiellement pris le rôle d'architecte logiciel. Les programmes embarqués sont devenus des éléments de configuration contrôlés. L'architecte et le CNES approuvaient les spécifications et les plans de qualification, des spécialistes externes du logiciel ont rejoint les revues majeures, et le système électrique et logiciel a reçu un plan de qualification intégré, un plan de vérification des exigences, des tests système et un document de justification.

Ce sont des réparations de responsabilité parce qu'elles nomment qui doit voir, approuver et prouver le comportement logiciel inter-systèmes.

Les annonces publiques montrent que le calendrier a répondu aux preuves plutôt que de rester fixe. Unemise à jour de la campagne du vol 502de mars 1997 liait la campagne à des travaux électriques, logiciels et de mode dégradé supplémentaires. Plus tard, lesdernières préparations du vol 502ont été retardées en partie pour terminer la qualification du programme de vol et résoudre une oscillation de boucle de contrôle identifiée par simulation. Le retard seul n'est pas une preuve de qualité, mais c'est une preuve observable que des analyses non résolues pouvaient déplacer la date de lancement.

Le vol 502 du 30 octobre 1997 n'a pas fourni un point final simple et propre. Il a évité la défaillance logicielle du vol 501, mais un couple de roulis excessif et un arrêt prématuré de l'étage principal ont laissé les charges utiles sur une orbite plus basse que prévu. L'analyse détaillée des données du vol 502de l'ESA a ensuite indiqué que les performances globales étaient bonnes et a expliqué l'anomalie principale par des tests moteur. Cela importe pour évaluer la correction: un vol sans répétition de la défaillance du SRI soutenait la correction spécifique, tandis qu'une anomalie séparée montrait pourquoi la qualification du programme ne pouvait pas reposer sur une seule voie corrigée.

Le vol 503 du 21 octobre 1998 a achevé le troisième vol de qualification avec succès. Lerésultat contemporainde l'ESA a rapporté l'injection réussie de la charge utile représentative et a décrit la phase de développement comme close. Lerapport annuel 1999 sur le transport spatialde l'ESA enregistre qu'après une analyse détaillée du vol 503, la Commission de qualification des lanceurs a formellement qualifié Ariane 5 générique le 22 juin 1999, suivie du premier vol opérationnel en décembre.

Cette séquence est plus forte qu'un communiqué de presse émis immédiatement après un lancement réussi. Elle combine des modifications de conception documentées, une autorité révisée, des installations élargies, des revues retardées, deux vols de qualification ultérieurs et une décision formelle ultérieure de la commission. Elle ne divulgue toujours pas chaque vecteur de test, résultat d'injection d'exception, constatation de revue indépendante ou audit de configuration.

La conclusion défendable est que le mécanisme de défaillance identifié et le processus d'assurance ont été matériellement réparés et soumis à une qualification réussie, pas que tout risque logiciel a été définitivement éliminé.

Ce que prouve le succès ultérieur, et ce qu'il ne peut pas prouver

Le service ultérieur d'Ariane 5 est une preuve que le véhicule a dépassé le vol 501, mais le succès agrégé ne peut pas valider chaque contrôle correctif séparément. Les missions ultérieures utilisaient des configurations de lanceur, des fournisseurs, des logiciels et des processus opérationnels en évolution. Un long dossier sans le même dépassement BH soutient fortement la conclusion que le défaut direct ne s'est pas reproduit. Il ne révèle pas si chaque hypothèse de domaine de mission était toujours documentée ou si chaque simulateur restait représentatif.

Lematériel sur le risque d'ingénierie systèmede la NASA résume indépendamment le vol 501 comme un problème de réutilisation du SRI dans lequel les fonctionnalités d'Ariane 4 et les restrictions d'exploitation non documentées n'ont pas été conciliées avec Ariane 5, et les tests système en boucle fermée excluaient les unités inertielles réelles. C'est une corroboration utile et une mémoire institutionnelle. Ce n'est pas un audit de la conformité continue de l'ESA ni un substitut à une preuve de qualification spécifique à la configuration.

De même, les normes ultérieures ne doivent pas être lues rétroactivement comme des obligations légales qui s'appliquaient automatiquement en 1996. Les exigences ECSS ont évolué sur des décennies, et l'ESA avait des normes d'ingénierie logicielle antérieures. L'accident peut être comparé aux attentes actuelles, mais une analyse équitable de la responsabilité applique d'abord les contrôles et les connaissances disponibles à l'époque. Les recommandations de la commission montrent que l'injection réaliste, l'analyse de plage, les restrictions explicites, la revue indépendante et une autorité claire étaient réalisables en 1996.

La critique ne dépend pas d'un recul important important une chaîne d'outils moderne.

Les preuves de réparation présentent également une asymétrie de publication. Les institutions divulguent généralement les plans, les jalons majeurs et les vols réussis. Les résultats de test défavorables détaillés, les dérogations, les non-conformités des fournisseurs et les constatations d'audit interne sont moins visibles. L'enquête publique du vol 501 était exceptionnellement précise sur une défaillance mais a déclaré qu'un rapport technique plus détaillé restait restreint. Sans ce dossier et les dossiers de qualification ultérieurs, un observateur externe ne peut pas reproduire indépendamment chaque affirmation d'assurance.

La hiérarchie de preuves la plus fiable est donc en couches. La mémoire récupérée, l'examen du code, la télémétrie et la simulation de reproduction établissent la chaîne de défaillance. Les recommandations de la commission et les documents du programme établissent les réformes prévues. Les changements d'installations et les revues de qualification établissent l'activité de mise en œuvre. Les vols 502 et 503 établissent les résultats opérationnels à travers deux configurations. La qualification formelle établit l'acceptation institutionnelle.

Aucun seul ne prouve une gouvernance durable; ensemble, ils fournissent un dossier substantiel mais incomplet.

Les contrefactuels doivent commencer à la décision contrôlable la plus précoce

Le contrefactuel le plus étroit est de protéger la conversion BH. Une vérification de plage ou un gestionnaire d'exceptions aurait pu empêcher l'erreur d'opérande d'arrêter le processeur. C'est techniquement plausible et directement soutenu par la commission. C'est aussi une leçon institutionnelle faible car elle laisse en place un alignement en vol obsolète, des hypothèses de plage non divulguées, une logique de défaillance identique et des interfaces de diagnostic ambiguës.

Un contrefactuel plus fort supprime la fonction d'alignement après le décollage. La première recommandation de la commission a fait exactement cela. Parce que la fonction ne servait aucun objectif de vol d'Ariane 5, la désactiver élimine le calcul déclencheur et réduit la surface d'attaque sans changer le guidage requis. C'est le contrôle de prévention le plus clair. Cela n'excuse pas le besoin de comprendre pourquoi la fonction a survécu à la revue de conception.

Un contrefactuel plus précoce met les données de trajectoire d'Ariane 5 dans la spécification du SRI et exige du fournisseur qu'il déclare les restrictions de mise en œuvre. L'incompatibilité entre la plage de BH et la vitesse horizontale précoce d'Ariane 5 serait alors visible à l'interface équipement-système. La commission a déclaré qu'une telle déclaration devrait être obligatoire pour les équipements critiques pour la mission. Cela aurait permis une revue avant l'exécution du code et dépend moins de l'espoir qu'un test franchisse accidentellement la limite.

Le contrefactuel de détection le plus fondé sur des preuves est le test représentatif. La commission a déclaré que l'injection de signaux accélérométriques prédits et de mouvement angulaire dans le SRI aurait exposé le mécanisme. Elle a également déclaré que l'inclusion de la quasi-totalité du SRI dans la simulation système globale était réalisable et aurait détecté la défaillance. Ce ne sont pas des affirmations spéculatives sur une ingénierie inconnue. Ce sont des constatations de l'enquête après avoir reproduit l'événement avec la trajectoire réelle.

Le confinement des défaillances offre un autre contrefactuel. Si une exception avait été confinée à la tâche d'alignement non essentielle tandis que la navigation continuait, ou si le SRI avait transmis une attitude valide de meilleur effort avec un état de santé explicite, la mission aurait pu rester contrôlable. La commission a recommandé à la fois le confinement au niveau de la tâche et la poursuite de la sortie du capteur de meilleur effort. Les preuves publiques ne contiennent pas une analyse dynamique complète prouvant qu'une telle conception aurait sauvé le vol 501, donc la conclusion doit rester conditionnelle.

Une redondance par diversité de conception aurait également pu empêcher l'arrêt en mode commun, mais elle comporte un coût et une complexité. Un code indépendant ou des algorithmes bornés différemment peuvent échouer de différentes manières et introduire de nouveaux risques d'intégration. La conclusion soutenue est plus étroite: la redondance identique n'a pas protégé contre la condition déterministe qui s'est produite, et la qualification devait traiter les modes communs d'origine logicielle comme des risques à point unique.

La question de savoir si une diversité de conception complète aurait été proportionnée n'est pas résolue par le rapport public.

Un dernier contrefactuel concerne l'attribution de la charge utile. Cluster aurait pu voler sur un autre lanceur ou un test Ariane 5 ultérieur, mais l'analyse rétrospective de l'ESA a trouvé l'attribution au vol 501 rationnelle et financièrement attractive sous les informations disponibles à l'époque. Un vol ultérieur n'aurait pas automatiquement exposé le défaut SRI caché; la même fonction non testée aurait pu échouer sur le premier Ariane 5 transportant n'importe quelle charge utile. Le choix de la charge utile a changé qui supportait la perte, pas la faiblesse de qualification sous-jacente.

Faits confirmés, inférence soutenue et inconnues restantes

Les faits confirmés incluent la date et la séquence de lancement, le vol précoce normal, les défaillances quasi simultanées des SRI, la conversion non protégée de 64 à 16 bits, la fonction d'alignement continue, la trajectoire précoce différente d'Ariane 5, l'arrêt du processeur, les mots de diagnostic traités comme des données de vol, les commandes de tuyère extrêmes, la désintégration et la destruction. La commission a confirmé que les tests d'équipement spécifiques à la trajectoire et l'inclusion du SRI dans la simulation système auraient pu détecter le mécanisme.

Elle a confirmé que les deux unités utilisaient un matériel et un logiciel identiques et que les décisions de protection et d'exigences traversaient les niveaux contractuels.

Les faits organisationnels confirmés incluent la propriété du programme par l'ESA et la délégation au CNES, le mandat de la commission indépendante, l'acceptation de toutes les recommandations, le rôle d'architecte logiciel, le contrôle de configuration séparé pour les logiciels embarqués, les installations élargies, la revue externe et la séquence de qualification ultérieure. Les faits d'impact confirmés incluent la destruction des quatre satellites Cluster, l'estimation de 288 millions d'ECU pour les conséquences de qualification d'Ariane 5, l'enveloppe de 214 millions d'ECU pour Cluster II et les lancements de remplacement réussis en 2000.

L'inférence soutenue commence là où le dossier relie les contrôles mais ne documente pas chaque décision privée. La commonality, le calendrier, la charge de travail et la confiance dans l'héritage d'Ariane 4 ont probablement fait apparaître la réutilisation comme moins risquée qu'une refonte. La fragmentation entre la visibilité du logiciel d'équipement et du logiciel système a probablement rendu la fonction d'alignement obsolète et sa limite de plage moins contestable.

Ces inférences correspondent aux constatations de la commission et aux changements de gouvernance ultérieurs, mais le rapport public ne fournit pas de procès-verbaux prouvant le poids relatif de chaque incitation.

C'est également une inférence soutenue qu'un meilleur typage d'interface ou une gestion de l'état de santé aurait pu empêcher les informations de diagnostic de devenir une commande de contrôle. La chaîne de défaillance démontre le danger, et les recommandations appellent à un meilleur confinement des exceptions et à un catalogage des informations sur le bus. Le dossier public ne publie pas assez de détails de protocole pour spécifier une implémentation alternative garantie.

Des inconnues restent matérielles. Le rapport technique restreint ne fait pas partie des preuves publiques utilisées ici. Le code source complet, l'historique des versions, les contrats des fournisseurs, les analyses de dangers internes, les procès-verbaux de revue, les dérogations de test, le routage des données de trajectoire et les dossiers d'approbation individuels ne sont pas publics sous une forme permettant une matrice de responsabilité complète.

Le dossier public n'établit pas si un individu a spécifiquement averti à propos de BH, si un test SRI intégré proposé a été rejeté pour des raisons de coût ou de calendrier, ou comment les gestionnaires ont quantifié le risque logiciel résiduel avant le lancement.

La responsabilité légale est également inconnue de ce dossier. La commission d'enquête était une investigation technique, pas un tribunal. Les sources examinées ici n'incluent pas un jugement attribuant la responsabilité contractuelle ou délictuelle entre l'ESA, le CNES, Arianespace, l'architecte industriel, les fournisseurs ou les entités à la charge utile. Le contrôle technique et la responsabilité institutionnelle peuvent être analysés sans revendiquer un résultat juridique qui n'a jamais été jugé dans le dossier cité.

La perte économique complète n'est pas disponible. Les enveloppes de programme décrivent le financement de la récupération et de la qualification, pas le coût social net. Une partie du matériel, des connaissances et des pièces de rechange a été réutilisée. L'opportunité scientifique a été retardée plutôt que définitivement effacée car Cluster II a finalement fonctionné avec succès pendant de nombreuses années. La valeur contrefactuelle des observations manquées entre 1996 et 2000 ne peut pas être évaluée à partir des documents publics.

Enfin, la durabilité à long terme de la correction n'est que partiellement observable. Le succès ultérieur des vols est une preuve de résultat solide, et les normes actuelles institutionnalisent l'assurance de la réutilisation. Les sources publiques ne divulguent pas si chaque modification ultérieure d'Ariane a reçu une analyse de domaine de mission identique, à quelle fréquence les revues logicielles indépendantes ont trouvé des défauts matériels, ou comment les transitions de configuration et de fournisseur ont été auditées. L'absence d'un mécanisme répété du vol 501 n'est pas une preuve complète de chaque processus.

Un test de responsabilité durable pour les logiciels de mission hérités

Le premier test est la définition du domaine. Avant d'approuver la réutilisation, le programme peut-il décrire les domaines opérationnels anciens et nouveaux en termes mesurables: plages de valeurs, vitesses, synchronisation, phases de vol, conditions environnementales, marges du processeur, interfaces et états dégradés? Une étiquette comme « héritée » ou « éprouvée en vol » n'est pas une comparaison de domaine.

Le deuxième test est la propriété des hypothèses. Chaque hypothèse pertinente pour la sécurité est-elle attachée à un propriétaire, une justification, une condition d'expiration et une méthode de vérification? Les hypothèses intégrées dans le code, les spécifications et les dossiers de conception sont-elles conciliées? Une limite qui n'existe que dans le raisonnement d'un fournisseur ne peut pas protéger un intégrateur système.

Le troisième test est la nécessité fonctionnelle. Chaque tâche s'exécutant pendant une phase critique sert-elle une exigence de mission actuelle? Les fonctions héritées inutilisées peuvent-elles être supprimées ou inhibées, et la suppression elle-même a-t-elle été qualifiée? Le vol 501 montre qu'un but dormant ne signifie pas une exécution dormante.

Le quatrième test est l'intégrité de la plage et des exceptions. Toutes les conversions, limites arithmétiques et valeurs de communication sont-elles testées sur des domaines nominaux et hors nomination? Une exception préserve-t-elle le service sûr de la plus haute valeur, isole-t-elle la tâche défaillante et produit-elle un état de santé non ambigu? Arrêter un capteur sain parce qu'un calcul non essentiel a échoué n'est pas un comportement de sécurité intrinsèque.

Le cinquième test est l'indépendance de la redondance. Quels dangers sont vraiment indépendants entre les voies, et lesquels sont communs via un code, des exigences, des données, une synchronisation ou des outils identiques? Une sauvegarde ne doit jamais être traitée comme un argument de fiabilité tant que les conditions de mode commun n'ont pas été exercées.

Le sixième test est la validité de l'interface. Les données de diagnostic, périmées, invalides et opérationnelles peuvent-elles être distinguées structurellement, pas seulement par convention? Le consommateur rejette-t-il les transitions d'état impossibles et les commandes hors domaine? Les informations de défaillance ne doivent pas pouvoir se faire passer pour les informations utilisées pour contrôler le véhicule.

Le septième test est le chevauchement représentatif. Lorsqu'un équipement réel est omis d'un test système, quelles preuves de niveau inférieur couvrent le comportement omis, et qui approuve la fidélité du simulateur? Les trajectoires de mission prédites sont-elles injectées dans des processeurs réels ou des modèles exécutables détaillés? Les niveaux de test doivent se chevaucher autour du risque, pas laisser un fossé entre la propriété du composant et celle du système.

Le huitième test est la contestation indépendante. Les réviseurs inspectent-ils le fond des arguments de plage, de la politique d'exception et de la justification de réutilisation, ou vérifient-ils seulement l'achèvement des documents? L'assurance logicielle ou la commission de qualification peuvent-elles arrêter le vol lorsque les preuves du domaine de mission sont incomplètes? L'indépendance sans autorité de décision peut identifier le risque sans le contrôler.

Le neuvième test est la traçabilité de la configuration. Le logiciel embarqué est-il séparément contrôlé, avec le source, le compilateur, les données, les hypothèses, les résultats de test et la justification liés à la version volée? Les enquêteurs peuvent-ils reconstruire exactement ce que chaque unité redondante a exécuté et ce que le simulateur représentait? Le contrôle du numéro de série du matériel est insuffisant lorsque le logiciel détermine le comportement de défaillance.

Le dixième test est la preuve de réparation. La correction inclut-elle un test de reproduction de la défaillance originale, des tests pour les conditions d'exception et de plage adjacentes, une intégration en boucle fermée, des exercices en mode dégradé et une revue indépendante? Les vols ultérieurs testent-ils le domaine pertinent, et les anomalies non répétées sont-elles étudiées plutôt que rejetées comme bruit de succès sans rapport?

Le vol 501 perdure parce que la défaillance était assez simple à expliquer et assez systémique pour résister à un remède simple. Le lanceur n'a pas été perdu simplement parce qu'une valeur était trop grande, ni parce que le logiciel a été réutilisé, ni parce qu'une unité s'est arrêtée. Il a été perdu parce qu'une hypothèse héritée a franchi une frontière de mission sans devenir une obligation système explicite; une redondance identique partageait la même faiblesse déterministe; la qualification a simulé l'implémentation qui importait; et l'autorité pour la cohérence des logiciels embarqués était trop diffuse.

La réparation a été en conséquence plus large qu'une conversion patchée. Elle a changé la durée de vie des fonctions, la gestion des exceptions, l'équipement de test, l'injection de trajectoire, le contrôle de configuration logicielle, la revue, l'architecture et l'autorité. Ces changements, suivis d'une qualification renouvelée, sont des preuves significatives d'apprentissage institutionnel. L'obligation de responsabilité restante est de préserver ces preuves à chaque décision de réutilisation.

L'historique des vols peut soutenir la confiance, mais seule une validation spécifique à la mission peut montrer que les hypothèses de l'ancien logiciel tiennent toujours dans le système qui volera réellement.