Menu Fermer

Boeing fait le point, la voie à suivre pour Starliner – NASASpaceFlight.com

Un peu plus de deux mois après l’essai en vol orbital tronqué de leur capsule d’équipage Starliner, les responsables de Boeing ont donné un aperçu approfondi des problèmes rencontrés lors du vol.

La mise à jour, qui a eu lieu le vendredi 28 février, a également fourni des informations sur la voie à suivre pour Starliner, notamment l’audit logiciel en cours, la fermeture des échappements de processus et les lacunes dans les tests logiciels, ainsi que le travail avec la NASA pour déterminer le futur programme de vol.

La NASA sera en fin de compte celle qui décidera du type de vol que le Starliner effectuera ensuite et de la date de ce prochain vol, mais John Mulholland, vice-président et directeur du programme des équipages commerciaux de Boeing, a confirmé qu’il y a de la place dans le programme Atlas V très chargé de United Launch Alliance cette année pour un autre vol du Starliner.

Toutefois, M. Mulholland a conseillé de ne pas déterminer exactement quand le prochain vol de Starliner aura lieu, en disant que tant que les recommandations finales de l’équipe d’examen indépendante ne seront pas reçues (la semaine prochaine), tant que l’audit interne de Boeing sur les logiciels et les processus qui conduisent à ce que les problèmes en vol ne soient pas découverts avant le vol ne sera pas terminé, et tant que Boeing ne pourra pas mettre en œuvre de nouvelles exigences et règles pour la vérification et la validation des logiciels, il ne peut y avoir de discussion réaliste sur le moment où Starliner reprendra le vol.

M. Mulholland a rappelé – comme il l’a fait au cours des deux derniers mois – que la fusée Atlas V s’est parfaitement comportée lors du lancement de l’essai en vol orbital le 20 décembre 2019 depuis la base aérienne de Cape Canaveral, en Floride.

[contenu intégré]

L’Atlas V a déposé le Starliner dans la trajectoire suborbitale prévue et n’est en aucun cas responsable des problèmes rencontrés après la séparation du Starliner du sommet de l’étage supérieur du Centaure.

Ce qui s’est bien passé :

Si une grande attention a été accordée, à juste titre, aux problèmes rencontrés lors des débuts du Starliner, moins d’attention a été accordée aux plus de 80 % de la mission qui s’est parfaitement déroulée.

Il est à noter que de nombreux systèmes du Starliner ont eu un rendement supérieur aux prévisions avant le vol, notamment les systèmes de contrôle de l’environnement et de survie de l’appareil, les systèmes de propulseurs et les systèmes de refroidissement de l’avionique (utilisés lorsque les radiateurs du module de service ne sont pas disponibles pendant les opérations de pré-lancement, de lancement et de rentrée et d’atterrissage).

Le système de protection thermique de l’embarcation – plus communément appelé bouclier thermique – a également donné des résultats supérieurs aux prévisions.

Il en va de même pour les panneaux solaires à la base du module de service et des systèmes d’alimentation associés de Starliner – qui ont en fait fourni plus de puissance que prévu.

En fait, certains de ces systèmes ont si bien fonctionné ensemble que les directives d’exploitation conservatrices mises en place lors de l’essai en vol orbital peuvent être assouplies à l’avenir, ce qui apporte une efficacité supplémentaire à l’appareil.

De plus, bien qu’il ne soit pas utilisé pour s’amarrer à la station, le système d’amarrage de la NASA de Starliner a également subi une vérification presque complète pendant les deux jours de vol libre, M. Mulholland ayant noté que « nous savons que nous avons un bon contrôle du système d’amarrage ».

Les équipes s’occupent du véhicule Starliner après l’atterrissage. Crédit : NASA

En ce qui concerne plus particulièrement le système de propulseurs de Starliner, Boeing a parlé en profondeur des contraintes imposées aux propulseurs pour fonctionner en dehors de leur enveloppe normale.

Après que le Starliner n’ait pas effectué la combustion d’insertion orbitale (à cause de l’anomalie du logiciel Mission Elapsed Timer) comme prévu, le vaisseau spatial a dû effectuer une « combustion prolongée du propulseur à trois axes très inefficace pour amener le Starliner sur une orbite stable », a raconté M. Mulholland.

Cela a nécessité de faire brûler les propulseurs bien plus longtemps que le plan de mission nominal, ce qui a introduit des signatures de surchauffe « faussement positives ».

Ces « faux positifs » n’étaient pas inattendus une fois que le système a été soumis à cette brûlure inefficace à trois axes.

Les systèmes de propulseurs ont été arrêtés par précaution après que la combustion sur trois axes ait mis Starliner sur une orbite stable et à puissance positive. Des équipes ayant l’expérience des propulseurs de l’époque de la navette ont alors enquêté sur les « faux positifs » et ont travaillé à la remise en service de chaque propulseur.

Tous les propulseurs sauf un ont été remis en service avec succès, et tous ceux qui ont été ramenés ont fonctionné parfaitement pour le reste de la mission – à l’exception d’un problème très mineur avec la valve de pressurisation d’azote d’un propulseur de contrôle d’attitude qui n’a pas pu se fermer pendant la rentrée.

Ce problème de fermeture de valve n’était pas un problème de vol ou de sécurité, mais Boeing a tiré sur le propulseur concerné pour déterminer pourquoi la valve ne s’est pas fermée.

Hier, lors de l’entraînement au lancement dans le simulateur de mission Boeing, nous nous sommes sentis à l’aise dans nos combinaisons. Allez #Starliner ! @BoeingSpace @Commercial_Crew #NASA pic.twitter.com/oXtgQgTAi7

– Col. Mike Fincke (@AstroIronMike) 27 février 2020

L’atterrissage proprement dit s’est déroulé à 182 mètres du centre de la zone d’atterrissage, et les charges à l’atterrissage étaient « bénignes, inférieures aux prévisions et trois fois inférieures aux exigences de la NASA », a noté M. Mulholland.

Les performances des parachutes étaient également normales.

En outre, tous les examens des données après le vol – une série d’examens distincts de l’audit logiciel en cours et des points d’action/examen de l’équipe d’examen indépendante – sont maintenant terminés.

En parlant de l’examen des données, M. Mulholland a noté que la capsule d’essai en vol orbital avait été autorisée à poursuivre le traitement post-mission et les efforts de retournement de vol.

Voir aussi

« Dans l’ensemble, le matériel du véhicule est en excellent état après la mission », a déclaré M. Mulholland, qui a fait l’éloge des techniciens et des ingénieurs qui ont construit le Starliner et qui sont maintenant chargés de retourner cette capsule pour son prochain vol.

La prochaine capsule (vaisseau spatial n°2) à voler est celle prévue à l’origine pour le test en vol de l’équipage. Il se trouve actuellement dans la zone de production dangereuse de l’installation de traitement des équipages et des cargaisons commerciales du Centre spatial Kennedy, où il est soumis à des tests de preuve et de fuite.

On ne sait pas encore quel type de mission cette capsule va effectuer – une répétition du test de vol orbital sans équipage ou du test de vol en équipage.

La NASA informera le public des résultats du rapport de l’équipe d’examen indépendante le vendredi 6 mars à 11h00 EST (16h00 UTC). Les responsables de Boeing ont averti que la NASA pourrait ne pas être prête à faire une annonce lors de cette réunion d’information pour savoir si un vol de retour de l’essai en vol orbital sera nécessaire.

La voie à suivre :

Dans l’ensemble, M. Mulholland a apprécié les recommandations provisoires fournies à Boeing par l’équipe d’examen indépendante, notant que ces recommandations détaillées et préliminaires – y compris les étapes d’enquête et d’examen – ont permis à l’équipe de commencer à se déplacer et à renforcer la robustesse de l’équipe, des systèmes et des processus pour assurer la sécurité des vols de Starliner.

[contenu intégré]

Une étape clé déjà soulignée par l’équipe d’examen indépendante est la nécessité d’améliorer les disciplines de l’ingénierie des systèmes et des processus.

Certaines de ces améliorations ont déjà été mises en œuvre – par exemple, Boeing effectue des visites sur place, des examens et des discussions de renforcement des relations avec ses différents fournisseurs.

Mais il reste encore beaucoup de travail à faire du côté des logiciels.

« Nous devons examiner le processus de test des logiciels pour une qualification formelle », a noté M. Mulholland. « Nous avons déjà réalisé un audit sur les domaines de logique élevée et moyenne à comparer aux tests de logiciels pour identifier les lacunes, et nous avons identifié les domaines dans lesquels nous avons testé ou non les logiciels.

« Nous recherchons également d’autres anomalies qui pourraient devoir être corrigées. Jusqu’à présent, nous n’en avons trouvé aucun, mais l’audit global des logiciels se poursuit ».

M. Mulholland s’est engagé à ce que, si d’autres problèmes de logiciels sont découverts lors des tests, Boeing révèle ces problèmes et leurs solutions ; en outre, il espère être en mesure de fournir une réponse à ce sujet d’ici un mois environ.

M. Mulholland a également abordé des questions difficiles et répétées sur les raisons pour lesquelles un test complet de bout en bout du logiciel du Starliner, un test qui aurait permis de cerner les deux problèmes qui ont affecté l’avion lors du test de vol orbital, n’a pas été effectué.

En bref, il a déclaré que les équipes utilisaient une pratique courante dans l’industrie consistant à diviser les tests de qualification de logiciels prolongés en plusieurs parties et à tester chacune de ces parties indépendamment.

Rendu du largage de la jupe d’avion lors du lancement du bimoteur Centaur du Starliner sur sa trajectoire suborbitale initiale – via Mack Crawford pour NSF/L2

Pour Starliner, cela s’est traduit par un compte à rebours et un lancement, s’arrêtant juste après la séparation du vaisseau spatial de l’étage supérieur du Centaur de l’Atlas V.

Le deuxième morceau a été ramassé par la suite et a subi la brûlure critique de l’insertion en orbite.

Le problème ici est que parce que le morceau de test du logiciel de compte à rebours/lancer s’est arrêté avant la combustion de l’insertion orbitale, le test n’a pas pu vérifier que le temps de mission écoulé correct a été tiré par Starliner de la fusée Atlas V.

Si le test s’était déroulé sur l’insertion en orbite, il aurait permis de détecter le problème du temps écoulé de la mission et de le corriger au sol avant le vol.

(Le problème de la minuterie de mission a été retracé au fait que le logiciel a extrait le temps de mission de l’Atlas V avant le décompte final et ne l’a pas extrait une seconde fois une fois le décompte final commencé… ce qui a conduit à l’arrêt de la minuterie de 11 heures).

À cette fin, Boeing va maintenant effectuer un test de logiciel de bout en bout, du lancement à l’amarrage, sur plusieurs jours, pour les missions à venir.

Inversement, le deuxième problème de logiciel – le problème de cartographie des jets qui aurait empêché le module de service de Starliner de mettre à feu ses propulseurs pour effectuer une brûlure d’évitement critique afin de s’éloigner du module d’équipage après la séparation du module de service et du module d’équipage suite à la brûlure de désorbitation – n’a pas été détecté parce que l’émulateur utilisé pour vérifier cette partie du code logiciel était un héritage d’autres programmes de Boeing, et non de Starliner, et n’était pas mis à jour avec le logiciel de cartographie des jets correct pour Starliner.

Journée de formation et de développement ! S’entraîner à se rendre sur la rampe de lancement depuis la salle des combinaisons du Centre spatial Kennedy. Chevaucher l’Astro Van II de @BoeingSpace avec @Astro_Ferg et @AstroDuke . Notre équipe de renfort, Barry Wilmore, est également avec nous. #NASA #Commercial_Crew pic.twitter.com/poCqruobOY

– Col. Mike Fincke (@AstroIronMike) 24 février 2020

La pièce de matériel qui avait le code correct du logiciel de cartographie de jet du module de service Starliner – et qui a été marquée pour effectuer cette qualification logicielle – a été retirée du test et envoyée au Nouveau-Mexique pour le test du moteur à feu chaud du module de service à la place.

L’émulateur substitué n’a alors pas été mis à jour avec le code correct du logiciel de cartographie par jet.

Lorsque le test de vérification du logiciel de cartographie des avions à réaction a été refait au sol avec le matériel qui avait le bon codage logiciel – effectué pendant que le test de vol orbital se préparait à la désorbitation, à la rentrée et à l’atterrissage – le problème a été découvert et le bon code a été transmis à Starliner pour éviter ce que la NASA a classé comme une situation de « perte de véhicule ».

A ce propos, M. Mulholland a indiqué que Boeing a mis à jour et continue de mettre à jour toutes les procédures de test des logiciels afin d’inclure non seulement des listes de contrôle pour les logiciels mais aussi tout le matériel spécifique nécessaire pour ces tests de qualification afin de garantir qu’il n’y ait plus jamais de décalage entre le matériel et l’émulateur.

« A l’avenir, nous allons définir le matériel nécessaire pour s’assurer qu’il est bien là pour les tests de qualification », a déclaré M. Mulholland.

En outre, Boeing va maintenant procéder à des tests de logiciels intégrés de désamarrage à l’atterrissage sur toute la durée de la mission afin de s’assurer que ce problème ne se reproduira pas lors de futures missions.

En outre, une discipline et des exigences accrues seront ajoutées à tous les processus d’examen et d’approbation des séquences de test des logiciels à l’avenir.

M. Mulholland a également déclaré que les équipes de Starliner ont commencé à partager les résultats des leçons tirées des tests de logiciels – y compris le point faible identifié dans les « tests par morceaux » – avec d’autres départements et divisions de Boeing et a également partagé les résultats avec des entreprises extérieures et l’industrie spatiale.