Service après-vol Boeing Starliner, photo NASA / Bill Ingalls
Deux fois presque perdu
Dans la terminologie de la NASA, la mission a été reconnue comme «presque perdue avec une large couverture médiatique» («appel rapproché à haute visibilité»). Le terme suivant est l'accident avec la perte du navire et peut-être la mort. Le statut est assez rare, et la dernière fois, il a été désigné la situation lorsqu'en 2013 l'astronaute Luca Parmitano a failli se noyer dans une combinaison spatiale lors d'une sortie dans l'espace en raison d'un filtre obstrué du système de refroidissement par eau.
Le premier bug s'est manifesté 31 minutes après le départ. Le vaisseau spatial n'a pas effectué la manœuvre prévue pour passer à la trajectoire de vol de l'ISS à partir de son orbite d'origine. Le MCC a tenté de rectifier la situation, mais, en tant que mal, ces tentatives se sont superposées à des problèmes de communication, et en conséquence, Starliner était sur une orbite inadaptée au rendez-vous avec l'ISS, et avec des réservoirs de carburant vides. En raison d'une erreur dans le code, le vaisseau spatial a synchronisé le chronomètre de temps de vol avec le lanceur non pas au début du compte à rebours, mais 11 heures avant le lancement. En conséquence, l'ordinateur de bord a estimé que le navire se trouvait à un stade de vol différent de celui de la réalité.
La séparation des compartiments du navire Staliner, une image de la vidéo Boeing
Le deuxième bug n'a pas eu le temps de faire ses preuves. En raison du premier problème, les experts de la NASA et de Boeing ont commencé à analyser le code pour voir si nous manquions autre chose? Et, comme il s'est avéré, pas en vain. Lors de l'atterrissage, après avoir effectué une manœuvre de freinage, le vaisseau spatial était censé se diviser en un véhicule de descente et un module de service (montré dans l'illustration ci-dessus, presque tous les engins spatiaux passent par une procédure similaire, par exemple, Soyouz est divisé en trois compartiments, et Crew Draron réinitialise le module de service avant freinage). Après la séparation, le module de service a dû effectuer une manœuvre pour s'éloigner du navire, mais en raison d'une erreur dans le code, la procédure a été incorrectement transmise au contrôleur contrôlant le processus. En conséquence, le module de service pourrait heurter le véhicule de descente et y causer des problèmes.
Le troisième problème n'était pas si critique, mais j'ai bu beaucoup de sang du personnel au sol. Tout au long de la mission, le navire a eu des problèmes de communication avec le sol, ce qui a rendu difficile son contrôle depuis le MCC, et dans le cas d'un vol habité, cela entraînerait des difficultés dans les négociations avec les astronautes.
Deux problèmes critiques, dont chacun aurait conduit à la perte du navire sans l'intervention du MCC, sont apparus pendant la phase de conception et de développement et ont réussi à s'infiltrer à travers de nombreux contrôles pendant la phase de test. Les deux problèmes étaient détectables grâce à des tests, et les processus de Boeing auraient pu et auraient dû les trouver et les résoudre.
Que faire?
Le rapport complet contient des informations exclusives et des secrets commerciaux, de sorte que la NASA n'a publié qu'un aperçu général, ce qui est encore assez intéressant.
21 recommandations sont directement liées aux tests. Tout d'abord, il est nécessaire d'améliorer les tests d'intégration tant au niveau matériel que logiciel. En mon nom propre, je constate que les erreurs qui n’ont pas été détectées au stade des tests d’intégration occupent toujours une part importante dans les causes des accidents spatiaux. De plus, avant chaque vol, il est nécessaire de mener une «répétition générale» avec une implication maximale de l'équipement de vol, d'analyser son comportement et ses limites, et d'agir sur les lacunes détectées dans les simulations.
10 recommandations ont été attribuées à des exigences, mais en fait elles concernent également les tests. Les exigences avec des conditions multiples devraient être mieux analysées et la couverture de décision devrait être augmentée - la couverture de test des conditions dans le code. Permettez-moi de vous rappeler qu'une couverture de décision à 100% signifie une couverture de déclaration à 100%, mais pas l'inverse.
35 recommandations devraient améliorer les processus. Et en fonction de ce qu'il est proposé d'améliorer, il est possible de reconstruire les problèmes découverts. Le renforcement de la revue de code et des données de test devrait résoudre le problème du fait que les erreurs dans le code n'ont pas été remarquées ni lors de l'écriture du code (pour la revue de code) ni pendant le processus de test (les données de test étaient évidemment insuffisantes). Une plus grande implication des experts dans les domaines critiques pour la sécurité devrait éliminer les lacunes de compétence. Et la proposition de modification de la documentation des commissions de décision devrait corriger la situation lorsque les défauts de développement et de test ne sont pas remarqués ou reçoivent une priorité trop faible pour être éliminés.
Les 7 recommandations sont des correctifs de code qui permettront de corriger les bugs en tenant compte du temps de vol et de la procédure de séparation du module de service, et également de fiabiliser l'algorithme de sélection d'antenne.
Et les 7 dernières recommandations concernent la structure organisationnelle et le matériel. Des changements attendent la structure organisationnelle des messages de sécurité (évidemment, pour mieux transmettre les messages «nous avons un problème important ici»), l'audit externe devrait être amélioré et un filtre supplémentaire sera introduit dans la conception du navire pour protéger contre les interférences hors bande.
Chère leçon
Bien qu'il n'y ait rien de joyeux dans l'histoire du vol d'urgence, il servira à améliorer les processus de création de technologie spatiale et de sécurité des vols. Bien sûr, il est très ennuyeux de rater des bogues de production qui auraient pu et auraient dû être trouvés lors des tests bien avant le vol. Désormais, les premiers vols d'essai devraient plutôt confirmer l'exactitude des décisions prises, plutôt que détecter des problèmes inaperçus. Le vol d'essai a été très instructif, mais aussi très coûteux. Boeing doit maintenant effectuer un autre lancement d'essai à ses propres frais pour s'assurer que le navire est sûr et volable. Sa date exacte est encore inconnue, alors que novembre 2020 est prévu.