The Trouble with Tribbles und Bugs

Die unendlichen Weiten können ein gefährlicher Ort sein und das besonders wenn die Software, die Dein Weltraumgefährt betreibt nicht richtig arbeitet. Dieses Thema ist Bestandteil vieler Science-Fiction-Filme und -Serien wie 2001: Odyssee_im_Weltraum. Dort kämpft die Crew gegen den Bordcomputer mit „neurotischen Verhalten“ um ihr Überleben.

Doch das Problem mit fehlerhafter Software, die sich negativ auf das Ziel der eigentlichen Mission auswirkt, gibt es leider schon heute. Als Beispiel möchte ich die Missionen Mars Climate Orbiter der NASA und Schiaparelli der ESA und Roskosmos. Beide Missionen hatten das Ziel ein Labormodul auf dem Mars zu landen und beide Missionen endeten im Totalverlust der Module.

Der Mars Climate Orbiter startete zusammen mit dem Mars Global Surveyor startete am 11. Dezember 1998 vom Weltraumbahnhof Cape Canaveral und erreichte am 23. September 1999 den Mars. Dort sollte sie durch verschiedene Bremsmanöver einen passenden Kurs zum landen einschlagen. Durch einen Softwarefehler wurde aber eine falsche Höhe bzw. der falsche Kurs eingeschlagen. Die einzelnen Softwarekomponenten des Mars Climate Orbiter wurden zum einen von der NASA und von Lockheed Martin entwickelt. Die NASA übergab die Messdaten im  metrischen System und Lockheed Martin im angloamerikanischen Maßsystem, was zu abweichenden Ergebnissen führte.

Am 19. Oktober 2016 wurde die Landung von Schiaparelli mit dem gleichen Ziel wie das Modul der NASA gestartet. Es sollten alle Technologien für künftige Landungen auf dem Mars erprobt werden. Aber auch hier konnte die Mission nicht erfolgreich beendet werden. Wie heise.de berichtet, haben “ die Messung der Eigendrehung zuständige IMU (Inertial Measurement Unit) aber ungefähr eine Sekunde lang eine Messbereichsüberschreitung registriert, wodurch andere Berechnungen überlastet worden seien. Als Konsequenz habe der Lander einen negativen Wert für die geschätzte Höhe ermittelt. Schiaparelli habe sich dann so verhalten, als sei er bereits gelandet, was angesichts einer tatsächlichen Höhe von 3,7 Kilometern zum Absturz geführt habe“.

Hätten sich die beiden Abstürze durch Softwaretests vermeiden lassen? Ich denke ja.

Ein Ergebnis der Untersuchung der NASA war, dass die Fehler durch eine bessere Zusammenarbeit und mehr Erfahrung sogar noch beim Anflug behoben hätte werden können. Hier wäre die Lösung ein umfangreicher Integrationstest mit allen Komponenten hilfreich. Dies ist aber meist erst möglich, wenn die einzelnen Komponenten einen testbaren Stand aufweisen. Während der Entwicklung der einzelnen Softwareteile sorgen abgestimmte Schnittstellenspezifikationen und darauf aufbauende Mocks für die Prüfung der korrekten Zusammenarbeit.

Dabei sollte neben der Prüfung der Funktionalität auch andere Aspekte beachtet werden. Bei der Schiaparelli hätte die Tests mit Daten, die auf der Spezifikation beruhten, nicht geholfen. Die Daten, welche zum Absturz geführt hatten, lagen außerhalb der Spezifikation. Deshalb empfiehlt es sich bei System, die besonders robust sein müssen und bei denen ein nachträglicher Eingriff durch einen Supporttechniker schwierig ist, durch den „Beschuss“ mit randomisierten Testdaten zu validieren. Im Vordergrund steht die Zuverlässigkeit der Software. Das System wird mit sinnvollen Daten, die so im Rahmen des Einsatzes anfallen könnten, aber auch mit anderen Daten (Negative Zahlen, Große Zahlen, Buchstaben etc.) bombardiert. So wird sichergestellt, dass das System sowohl bei „falschen“ Daten aber auch zu vielen Daten richtig arbeitet.

Nicht nur bei dem Einsatzszenario der beiden Weltraumgefährte, sondern bei jeden Softwaresystem sollte der Tester sich über den Einsatz Gedanken machen und daraus den Testfokus ableiten und dabei der Fantasie ruhig etwas Freiraum lassen, um dorthin zu gehen, wo nie ein Tester gewesen ist.