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.

Artikel von Frank Wunderlich-Pfeiffer veröffentlicht am 11. Februar 2020, 16:10 Uhr

Das Starliner Raumschiff besteht aus der Kapsel und einem abtrennbaren Servicemodul. (Bild: Nasa)

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.