StartseiteWas geht?

Die Softwarefehlerseuche in der Raumfahrt der späten 90er

Von / 25. November 2015 / 2 Kommentare / Seite 4 von 4 / Auf einer Seite lesen
Mehr

Unter Schmerzen entstand ein neuer Respekt für die Probleme von Softwareentwicklung. Danach wurde sie in der Fehleranalyse zum ersten mal komplex dargestellt und nicht mehr als ein einziger möglicher Fehler betrachtet. Es gab eine bessere Strukturierung der Softwareentwicklung, mit besserer Übersicht und eigenem Management. Die Kommunikation wurde verbessert den Softwareingenieuren eine höhere Priorität bei der Meldung von Problemen vor dem Start eingeräumt. Erprobte Software in einem neuen System wurde nicht mehr automatisch als zuverlässig angesehen, sondern als anfällig für Probleme im Kontext eines neuen Systems.

Zumindest führten die schmerzenhaften Verluste dazu, dass die einfachen Softwarefehler der späten 90er seit dem nicht wieder auftraten. Inzwischen stehen wieder die Probleme der mechanischen Hardware im Mittelpunkt. Wegen der hohen Kosten waren Vereinfachungen in den konservativen Verfahren der Fehlerkontrolle dort notwendig. Diese Vereinfachungen sorgen ihrerseits wieder für neue Fehler, wie zuletzt bei Orbital Sciences und SpaceX. Möglicherweise ist das auch ein Blick in die weitere Entwicklung bei der Software. Dann käme nach einem Exzess akribischer Kontrolle, konservativer Systeme und explodierender Kosten wieder eine Phase der Einsparungen, in der alte Fehler zurück kommen. Wir werden es in einigen Jahren oder Jahrzehnten sehen.

1 / 2 / 3 / 4
Mehr

Kommentare (2)

  1. #1 Karl Mistelberger
    26. November 2015

    Die Raumfahrt steckte schon früher in einer Krise: Communication Aberration. Jedem Amateurastronomen wäre der Fehler von Perkin-Elmer aufgefallen.

    Mehr: https://www.google.de/search?q=perkin+elmer+null+corrector

  2. #2 Michael Khan
    Darmstadt
    7. Dezember 2016

    Hier wird eine ganze Menge als “Softwarefehler” subsumiert, selbst wenn das nicht zutrifft. Wenn Software, die gemäß korrekten Spezifikationen richtig codiert wurde und auf der Rakete, für deren Steuerung sie ursprünglich entwickelt worden war, problemlos funktionierte, nun plötzlich ohne hinreichende Tests auf einer ganz anderen Rakete installiert wird, für deren Steuerung sie nie entwickelt war udn wo sie auch gar nicht funktionieren kann – wieso sollte das ein Softwarefehler sein? Es ist mit ziemlicher Sicherheit ein Managementfehler, weil zu wenig Zeit und Resourcen für Systemtests verfügbar gemacht wurden.

    Die Beschreibung der vermeintlichen Problemursache beim Mars Climate Orbiter ist schlicht falsch: “Die Bodenkontrolle sendete Daten in Poundforce, aber die Software des Orbiters interpretierte sie als Angaben in SI-Einheiten, in Newton.”. Das ist Unsinn.

    Richtig ist, dass der Hersteller der Sonde in der Vielzahl der Daten, die dem Kontrollzentrum bei der NASA übermittelt worden waren, bei einem Parameter einen Fehler gemacht hatte. Es handelt sich um den Parameter, der angibt, wie viel Auswirkung auf die Bahn die kleinen Manöver haben, mit denen die Schwungráder desatutiert werde, Dieser nicht unmittelbar intuitiv verifizierbare Parameter wurde vom Hersteller in pound-force-seconds angegegeben. Die Bahnbestimmungs- und Navigationssoftware bei NASA/JPL verwendete und erwartete aber Daten in metrischen Einheiten, also Newton-seconds.

    Der falsche Wert führte zu einem sich langsam aufbauenden Fehler in der Bahnbestimmung, und zwar unglücklicherweise gerade in der Komponente, die mit den Funkmessdaten, aus denen die Bahn bestimmt wird, nicht gut beobachtet werden konnte.

    Die Leute beim JPL wussten, dass etwas nicht stimmt, weil die Residuen in der Bahnbestimmung zu groß waren. Sie konnten aber die Ursache nicht orten. Zum einen, weil sie Pech hatten und dr Fehler sich ausgerechnet in der einen Komponente auswirkte, die sie mit ihren Funkmessdaten weniger gut “sehen”konnten. Zum anderen, weil die eine Billigmission sein sollte und die Ressourcen entsprechend limitiert waren. Am Ende wich die berechnete von der tatsächlichen Position um 75 km ab. Noch einmal Pech – der Fehler war genau so, dass die Sonde statt, wie gezielt 150 km, nur 75 km über der Oberfläche vorbeiflog.

    Abgesehen von der generell nicht richtigen Darstellung im Blog-Artikel – auch das hier war kein Softwarefehler. Es war eine Kombination aus falschen Eingangsdaten, Pech, und unzureichenden Resourcen. Was auch immer schief lief – dass es hier irgendwo ein Problem mit fehlerhafter Software gegeben habe, sehe ich nicht.