Am Mars gescheitert
Das größte Echo in der Öffentlichkeit bekam diese Softwareseuche aber durch zwei gescheiterte Marsmissionen. Der Absturz des Mars Climate Orbiters am 23. September 1999 ist inzwischen legendär. Die Bodenkontrolle sendete Daten in Poundforce, aber die Software des Orbiters interpretierte sie als Angaben in SI-Einheiten, in Newton. Entsprechend falsch war die Flugbahn und der Mars Climate Orbiter stürzte auf den Planeten.
Den Schlusspunkt dieser peinlichen Serie von Fehlern setzte dann der Mars Polar Lander am 3. Dezember 1999. Die Bremsdüsen der Sonde mussten abschalten, sobald der Lander die Oberfläche berührt. Dazu gab es druckempfindliche Sensoren in den Landebeinen. Diese Sensoren lieferten aber auch schon ein Signal, als die Beine ausgefahren wurden. Das war bekannt und Warnungen vor diesem Problem fanden sich auch in der Dokumentation der Landerhardware. Aber diese Warnungen kamen nicht bei den Programmierern an, weshalb die Software keine Routine enthielt, die dieses falsche Signal ausfiltert.
Zu viel Rechenleistung brachte zu viel Komplexität
Diese Fehler waren ein Phänomen, das in den 90er Jahren plötzlich auftauchte. Über Jahrzehnte funktionierte die Software weitgehend zuverlässig, die von Programmierern abgeliefert wurde. Es gab Probleme, aber nicht in dieser Zahl, nicht mit diesen Auswirkungen und nicht über alle möglichen Raumfahrtprogramme verteilt. Eine solche Reihe von Fehlern, noch dazu primitive Fehler, war praktisch undenkbar. Am berühmten Y2K Bug konnte es noch nicht liegen. Die Raketen liefen übrigens nicht mit Windows 95, das zur gleichen Zeit für seine Abstürze legendär war. Die Fehler mussten untersucht werden.
Wie zu erwarten war, zeigten die Untersuchungen (zweiter Link) eine Reihe von Nachlässigkeiten in allen Bereichen. Es fängt mit Kritik am Management und der Verteilung von Verantwortung an. Es geht mit fehlender Kommunikation im Unternehmen und schlechter Spezifikation der Anforderungen an die Software weiter. Systemtests wurden nicht mehr mit der vollständigen Hardware durchgeführt, womit sie praktisch wertlos waren. Aber beim Zusammenspiel von Komponenten stecken die Bugs im Detail. Gerade diese Details fehlen aber, wenn ein Testsystem nur simuliert wird, anstatt die finale Hardware zu benutzen. Hinter diesen Nachlässigkeiten wurden verschieden Gründe vermutet. Sparzwänge standen ganz oben auf der Liste, genauso wie übertriebenes Selbstvertrauen. Beide hatten sicherlich einen Anteil.
Das erklärt aber nicht, warum die selbe Art von Problemen parallel in der NASA, der ESA, US-Militärmissionen und kommerziellen Missionen auftauchen. In allen Fällen spielte die wachsende Komplexität der Software eine wichtige Rolle. Der Ausfall der Ariane 5 ist exemplarisch. Die Ursache war eine Variable, die aus Performancegründen nicht auf Bereichsüberschreitung kontrolliert wurde. Die Variable befand sich aber in einem ganzen Programmteil, der nicht mehr benötigt wurde und trotzdem ständig lief. Anstatt neue Software zu entwickelt, wurde alte Software erweitert.
Weniger ist zuverlässiger
Mit der beschränkten Rechenleistung früherer Jahre, hätte es dieses Problem nie gegeben. Die exponentiell wachsende Rechenleistung der Hardware erlaubte erst den Luxus, solche unnötigen Programmteile auszuführen. Es war also keine schlechtere Qualitätskontrolle nötig, um diese Fehler zu erlauben. Die Qualitätskontrolle musste sich um immer mehr Funktionen in der Software kümmern, womit Fehler leichter durch kamen. Inzwischen hat sich in der Programmierung eine gewisse Askese durchgesetzt und die Testverfahren wurden verbessert. Dazu gehören Verfahren wie die die systemtheoretische Prozessanalyse (STPA).
In der Praxis lief das alles auf eine engere Integration der Softwareentwickler in den Rest der Entwicklung der Hardwareentwicklung hinaus. Bis dahin wurde die Softwareentwicklung als alleinstehender Teil der Entwicklung betrachtet. Das ging soweit, dass in der Fehleranalyse der Punkt “Software” nur als ein einziger Punkt in der Fehleranalyse auftauchte. Die Anforderungen an die Software wurden klarer formuliert und strukturiert. Damit wurden sie für die Softwareentwickler besser zugänglich und konnten auch besser getestet werden.
Kommentare (2)