Original-URL des Artikels: https://www.golem.de/news/nasa-boeing-umging-sicherheitsprozeduren-bei-starliner-2002-146558.html    Veröffentlicht: 11.02.2020 16:10    Kurz-URL: https://glm.io/146558

Nasa

Boeing umging Sicherheitsprozeduren bei Starliner

Vergessene Tabelleneinträge, fehlende Zeitabfragen und störende Mobilfunksignale sollen ursächlich für die Probleme beim Testflug des Starliner-Raumschiffs gewesen sein. Das seien aber nur Symptome des Zusammenbruchs der Sicherheitsprozeduren in der Softwareentwicklung von Boeing. Parallelen zur Boeing 737 MAX werden deutlich.

Bei Boeing sieht es noch schlimmer aus als bisher bekannt: Zwei Software- und ein bis dahin noch nicht veröffentlichter Hardwarefehler seien nur Symptome eines tiefer liegenden Problems in der Entwicklung des Starliner-Raumschiffs und fehlender Aufsicht. Das wurde auf einer Pressekonferenz deutlich, die Nasa-Chef Jim Bridenstine ansetzte, um weitere Details aus den Untersuchungen des missglückten Testfluges vom Boeing Starliner im Dezember zu veröffentlichen. Der Zwischenbericht der Nasa zum ersten Testflug des Raumschiffs habe in der Presse zu Spekulationen geführt, die nun ausgeräumt werden sollten. Doug Loverro, Nasa-Chef für menschliche Raumfahrt, zeichnete dabei ein noch schlechteres Bild vom Stand der Entwicklung bei Boeing als bisher bekannt war.

Bei der Entwicklung und den Tests der Software für das Raumschiff habe es "mehrfach Umgehungen der Sicherheitsprozeduren" gegeben, sagte Loverro. John Mulholland, Vizepräsident für das Commercial Crew Programm der Nasa, erklärte die elfstündige Abweichung der Missionsuhr während des Fluges mit einer fehlenden Synchronisation. Die Missionsuhr sollte im letzten Countdown vor dem Start mit der Rakete synchronisiert werden. Das geschah jedoch nicht, weil der entsprechende Programmteil nicht programmiert worden war. Die Frage sei nun, warum diese Softwareanforderungen nicht implementiert worden seien und warum das in Tests vor dem Start nicht aufgefallen sei.

Kathy Luders, verantwortlich für die Sicherheitseinschätzung beim Commercial Crew Raumfahrtprogramm der Nasa, beschrieb die Details des zweiten Softwarefehlers. Dieser wurde erst etwa zehn Stunden vor dem geplanten Wiedereintritt des Starliners in die Erdatmosphäre gefunden und zwei Stunden vor dem Wiedereintritt durch ein Softwareupdate behoben. Es habe sich um eine Tabelle gehandelt, die nur von einem anderen Teil der Steuersoftware übernommen, aber nicht angepasst worden sei. Das betreffende Programm ist für die Lagekontrolle des Raumschiffs im Orbit zuständig. Die erfolgt beim Starliner mit Hilfe eines Servicemoduls, das bis kurz vor dem Wiedereintritt fest mit der Kapsel verbunden ist. Danach werden beide Teile getrennt und nutzen jeweils eigene Steuerdüsen, um sich voneinander zu entfernen.

Nach der Trennung benutzte das Servicemodul immer noch die gleiche Software für die Steuerung der Düsen. Allerdings ist es ohne die zuvor befestigte Kapsel viel leichter und hat andere Trägheitsmomente. Die Steuerdüsen können das Servicemodul ohne Kapsel viel stärker in Rotation versetzen als mit ihr. Die notwendigen Zahlen sind in einer Tabelle hinterlegt, dem Trägheitstensor. Allerdings stellte sich heraus, dass in der Software bei der Steuerung des Servicemoduls ohne Kapsel der gleiche Trägheitstensor hinterlegt war, wie beim Flug mit Kapsel.

In der Folge wären die Steuerbefehle des Programms zu stark ausgefallen und das Servicemodul möglicherweise nach der Abtrennung mit der Kapsel kollidiert, statt sich von ihr zu entfernen. Dieser Fehler wurde während des Fluges überhaupt nur deshalb gefunden, weil Boeing und die Nasa gemeinsam nach Fehlern mit ähnlichen möglichen Ursachen wie der Abweichung der Missionsuhr suchten, die den Wiedereintritt beeinträchtigen würden. Ohne den ersten schweren Fehler wäre die Abtrennung wohl an dem dann unerkannten zweiten Fehler gescheitert.

Boeings Raumfahrtvertreter Jim Chilton trug während der Pressekonferenz ein vorbereitetes Statement vor, dass Boeing bei dem Testflug viel gelernt habe und man schließlich teste, um zu lernen. Man sei immer überrascht von Dingen, die man lerne und wünsche sich, bei der Softwareentwicklung anders vorgegangen zu sein. In Bezug auf den zweiten bekanntgewordenen Softwarefehler sagte er: "Ich nehme da eine gewisse Neugier wahr und ein 'Hey, warum habt ihr uns nicht mehr erzählt?'" Man solle sich den Fehler als eine Herausforderung bei der Softwareintegration vorstellen. Während der erste Fehler bei der Integration von Raumschiff und Rakete entstanden sei, komme der zweite aus der Integration von Kapsel und Servicemodul.

Die Frage "Hey, warum habt ihr uns nicht mehr erzählt?" beantwortete Chilton hingegen erst, als sie noch einmal von einer Journalistin gestellt wurde. Er verstrickte sich dabei in Widersprüche. Boeing habe nichts von dem zweiten Fehler gesagt, weil es schließlich keine Anomalie im Flug gab. Boeing habe damals angeblich befürchtet, ohne die unabhängige Überprüfung der Nasa eine falsche Ursache zu nennen. Diese Aussage ist unverständlich in Anbetracht der Tatsache, dass Boeing noch während der Mission den Fehler gefunden und komplett verstanden haben musste, um ihn zu korrigieren, die Korrektur zu testen und den Fehler beseitigen zu können.

Chilton fuhr mit einer bemerkenswerten Begründung fort, weshalb der zweite Fehler nicht veröffentlicht wurde.

In Wahrheit ist es ein Problem, das nicht aufgetreten ist

"Es ist nicht so, dass wir etwas nicht offengelegt hätten. Wir wussten, dass wir einige Probleme hatten. Eines wurde durch eine Anomalie offensichtlich, das andere fanden wir durch eine Analyse, und wir wussten, dass wir mehr zu tun hatten. Also wollten wir nicht spekulieren. Und ich glaube nicht, dass Sie gewollt hätten, dass wir spekulieren und eine falsche Darstellung von dem liefern, was passierte", sagte Chilton. "Ich glaube nicht, dass ich es als etwas charakterisieren würde, das wir nicht offengelegt haben. Denn in Wahrheit ist es ein Problem, das nicht aufgetreten ist, und es ist schwierig, über Dinge zu spekulieren, die nicht passiert sind."

Der dritte besprochene Fehler betrifft den Kommunikationsausfall zwischen Bodenkontrolle und Raumschiff nach dem Start. Der wurde nach dem Flug zuerst damit erklärt, dass sich das Raumschiff zwischen dem Empfangsbereich von zwei TDRS-Relaissatelliten befunden habe. Nach der Landung hieß es, dass die falsche Ausrichtung der Antenne durch die falsche Fluglage das Problem gewesen sei. Mulholland erklärte sie nun mit "einem erhöhten Grundrauschen über spezifischen geografischen Gegenden", die auch ohne die Lage- und Kursabweichung aufgetreten wäre.

Erst auf hartnäckiges Nachfragen mehrerer Journalisten, die in Antennenproblemen mögliche Probleme beim Andocken an die internationale Raumstation ISS sahen, wurde der zunehmend resigniert wirkende Mulholland deutlicher. Demnach entstanden die Störungen nach der bisherigen Einschätzung durch unbeabsichtigt aufgefangene Signale von Mobilfunksendern auf der Erde, nicht durch Störsignale, die vom Raumschiff selbst erzeugt wurden. Die Relaissatelliten konnten deshalb nur dann mit dem Starliner kommunizieren, wenn er nicht über bewohntes Gebiet mit Mobilfunksendern flog.

Eine Million Code-Zeilen müssen überprüft werden

Auf die Frage nach dem Ausmaß der Softwareprobleme und der notwendigen Korrekturen sagte Boeing-Vertreter Chilton, dass die gesamte Flugsoftware zusammen mit der Nasa überarbeitet und neu zertifiziert werden müsse. Die Software für das Raumschiff habe etwa eine Million Zeilen Code. Davon seien rund 66 Prozent während des unvollständigen Testfluges im Dezember ausgeführt worden. Mulholland sieht jetzt die Aufgabe von Nasa und Boeing nicht einfach nur darin, die Softwarefehler zu beheben, sondern die Prozessfehler beim Programmieren der Software zu identifizieren.

Mulholland beschrieb den Entwicklungsprozess als eine reine Standardprozedur für die Softwareentwicklung: Er fängt an mit dem Aufstellen der Anforderungen an die Software und geht weiter mit dem Schreiben des Codes. Anschließend folgt ein Peer Review, in dem andere Programmierer den geschriebenen Code überprüfen. Danach geht es zum Unit-Testing, in dem einzelne funktionale Einheiten des Codes getestet werden, und anschließend kommen Integrationstests, nachdem der gesamte Code zusammengefügt wurde. Den Abschluss bilden die formalen Qualifikationstests.

Loverro ergänzte, bei der Ursachenforschung sei festgestellt worden, dass die Fehler entstanden seien, weil dieser Prozess von den Boeing-Mitarbeitern an mehreren Stellen umgangen worden sei. Sie hätten an mehreren Stellen während des Prozesses auffallen sollen. Nur weil der Prozess an so vielen Stellen durchbrochen worden sei, müsse nun der gesamte Code eingehend überprüfend werden. Bis dahin sei noch viel zu tun. Erst danach werde über die Notwendigkeit eines neuen Testflugs entschieden.

Schließlich wurde die Frage gestellt, welche systematischen Fehler es innerhalb der Nasa gab, damit es überhaupt zu den Zuständen bei Boeings Starliner kommen konnte. Wie solle die Nasa in den nächsten Jahren die Sicherheit viel ambitionierterer Vorhaben wie die geplanten Mondlandungen mit kommerziellen Landefähren garantieren können, wenn sie nicht einmal das schaffe? Loverro, der für diese Programme bei der Nasa verantwortlich ist, bedankte sich für die Frage und übte Selbstkritik an der Agentur.

Berichte über 737 MAX waren Anlass für Kontrollen

"Unsere Nasa-Aufsicht war unzureichend. Das ist offensichtlich. Das haben wir erkannt. Die Überprüfung ergab nicht nur Empfehlungen für Boeing, sondern auch für uns [die Nasa]", sagte Loverro. Die Nasa habe aber ohnehin geplant, viel mehr Einsicht in die Details der Mondlandefähren zu haben, denn Flüge zur ISS seien inzwischen in gewisser Weise Routine, anders als Flüge zum Mond. Dort sei ein Prozess mit begrenzter Aufsicht wie beim Commercial Crew Programm nicht geeignet.

In Bezug auf die systematischen Fehler sagte Loverro außerdem, wie es zu der anstehende Überprüfung der Sicherheitskultur des Raumfahrtprogramms von Boeing kam. Demnach hatten vor allem "Presseberichte über die Sicherheitskultur in anderen Bereichen von Boeing" den Ausschlag gegeben. Nach dem Absturz von zwei Boeing 737 MAX Flugzeugen wurden dort zahlreiche Probleme in Boeings Unternehmenskultur festgestellt. Dort wurde die begrenzte Aufsicht durch die Flugaufsichtsbehörde FAA kritisiert. Die Überprüfung soll der Nasa Anhaltspunkte liefern, wie es zu den Prozessfehlern überhaupt kam.

Nasa-Chef Bridenstine schloss mit der Anmerkung, dass er sich explizit bei den anwesenden Nasa-Mitarbeitern für ihre Transparenz bedanke. Er wisse das zu schätzen. Vor der Pressekonferenz habe er allen Beteiligten gesagt, sie sollten so transparent wie möglich sein und niemals Angst vor der Wahrheit haben.

Der Abschlussbericht wird erst Ende Februar erwartet.  (fwp)


Verwandte Artikel:
Crew Dragon: SpaceX soll im Mai bemannt zur ISS fliegen   
(11.02.2020, https://glm.io/146556 )
Nasa: Boeings Starliner hatte noch einen schweren Softwarefehler   
(07.02.2020, https://glm.io/146491 )
Boeing 777x: Jungfernflug für das größte zweistrahlige Verkehrsflugzeug   
(27.01.2020, https://glm.io/146300 )
Jigsaw Assembler: Googles Software soll bei Erkennung von Fälschungen helfen   
(07.02.2020, https://glm.io/146507 )
Militär-Hacker: USA klagen vier Chinesen wegen Equifax-Hack an   
(11.02.2020, https://glm.io/146554 )

© 1997–2020 Golem.de, https://www.golem.de/