Warum wurde der fatale Fehler des Mars Climate Orbiter nicht vor dem Start entdeckt?

pacoverflow

Der Mars Climate Orbiter scheiterte 1999 aus folgenden Gründen:

bodengestützte Computersoftware, die Ausgaben in Nicht-SI-Einheiten von Pfund (Kraft)-Sekunden (lbf·s) anstelle der im Vertrag zwischen der NASA und Lockheed festgelegten SI-Einheiten von Newtonsekunden (N·s) erzeugte. Das Raumschiff traf den Mars auf einer Flugbahn, die ihn zu nahe an den Planeten brachte, was dazu führte, dass er die obere Atmosphäre passierte und sich auflöste.

Ich finde diesen Softwarefehler absolut schockierend. Wie wurde es vor dem Start nicht gefunden? Ich würde denken, dass einige grundlegende Integrationstests den Fehler erkannt hätten. Und gab es keine Simulationen, die darauf hindeuteten, dass das Raumschiff auf der Grundlage der von der Software gemeldeten fehlerhaften Zahlen auf einem falschen Weg geflogen wäre?

Organischer Marmor

Ja, man sollte meinen, diese Dinge würden in Preflight-Simulationen auftauchen www-users.math.umn.edu/~arnold/disasters/ariane5rep.html

Makyen

Oder, bevor ein Produkt veröffentlicht wird: Pentium FDIV bug .

PlasmaHH

Sie hätten auch einfach <code>boost::units </code> verwenden können, aber jeder macht Fehler, und wenn eine Kette von Fehlern lang genug ist, führt dies zu Katastrophen. Es gibt keine Möglichkeit, fehlerfreie Software zu erstellen.

Luan

@PlasmaHH Und je kompliziertere Systeme und Bibliotheken Sie verwenden, desto höher ist die Wahrscheinlichkeit, dass das Problem in den Bibliotheken liegt. Wie verhält es sich boost::unitsbei harter Strahlung? :D

PlasmaHH

@Luaan: sehr gut, da es sich um eine Komponente ohne Overhead handelt, die nur zur Kompilierzeit existiert. Sie vermasseln die Einheiten, es wird nicht kompiliert. Wenn es kompiliert, ist es derselbe Maschinencode. Es ist auch nützlich zu verstehen, wie eine solche Bibliothek funktioniert und was bei ihrer Verwendung absolut nicht passieren kann.

SantiBailors

@PlasmaHH Ich stimme zu, dass jeder Fehler macht, aber deshalb geht die breite Öffentlichkeit (einschließlich mir) immer davon aus, dass bei solchen sicherheitskritischen Vorgängen mehrere Kontrollebenen vorhanden sind, damit ein Fehler die Produktionsphase erreicht, die Sie benötigen dass all diese Schichten versagen (selbst wenn nur eine nicht versagt und der Fehler abgefangen wird) und dass die Wahrscheinlichkeit, dass sie alle versagen – und jede zur „richtigen“ Zeit – lächerlich ist. Das macht meines Erachtens Vorfälle wie diesen für die breite Öffentlichkeit zu schockierend.

PlasmaHH

@SantiBailors: Ja, an vielen Stellen scheinen Statistiken und Risikobewertungen für die Mehrheit der Menschen eher kontraintuitiv zu sein. In diesem Fall ist es weniger eine Frage der Zeit als vielmehr des Ortes, was die Wahrscheinlichkeit etwas erhöht. So wie wenn man mit der Familie ein Hotelzimmer verlässt und alle nach übrig gebliebenen Gegenständen suchen und dort noch etwas fehlt, und im nächsten Jahr dasselbe Zimmer bucht und diesen Gegenstand findet, weil sich niemand die Mühe gemacht hat, genau dort nachzusehen. ^^

Benutzer2338816

@PlasmaHH Ein Start im Jahr 1998 und umfangreiche Integrationstests noch früher machten es etwas schwierig, sich auf die gute Verwendung von Boost-Bibliotheken zu verlassen.

Vikki

@PlasmaHH: Ja, wenn die Software einfach genug ist.

PlasmaHH

@ Sean: In diesem Fall könnten Sie nur beweisen, dass die Software der Spezifikation entspricht, die Spezifikation könnte immer noch Unsinn erfordern.

GdD

Die NASA bildete ein Gremium, um den Verlust des Raumfahrzeugs zu untersuchen, und gelangte zu einigen hochrangigen Schlussfolgerungen . Die Kammer nannte eine Reihe von beitragenden Faktoren, die ich gefiltert habe, um die für die Frage relevantesten einzuschließen:

  • Fehler blieben in bodengestützten Computermodellen unentdeckt, wie kleine Triebwerkszündungen auf dem Raumfahrzeug vorhergesagt und dann auf dem Raumfahrzeug während seiner interplanetaren Reise zum Mars ausgeführt wurden
  • Die systemtechnische Funktion innerhalb des Projekts, die alle miteinander verbundenen Aspekte der Mission verfolgen und überprüfen sollte, war nicht robust genug, was durch die erstmalige Übergabe eines Mars-gebundenen Raumfahrzeugs von einer Gruppe, die es konstruiert und gestartet hat, noch verschlimmert wurde ein neues Multi-Mission-Operations-Team
  • Einige Kommunikationskanäle zwischen Projektingenieurgruppen waren zu informell
  • Das kleine Missionsnavigationsteam war überzeichnet und seine Arbeit wurde nicht von unabhängigen Experten begutachtet
  • Das Personal war in Bereichen wie der Beziehung zwischen dem Betrieb der Mission und ihren detaillierten Navigationsmerkmalen oder dem Prozess der Einreichung formeller Anomalieberichte nicht ausreichend geschult
  • Der Prozess zur Überprüfung und Validierung bestimmter technischer Anforderungen und technischer Schnittstellen zwischen einigen Projektgruppen und zwischen dem Projekt und seinem Hauptauftragnehmer war unzureichend

Auch in dem hochrangigen Bericht ist dieses Zitat:

Zu diesen beitragenden Ursachen gehören eine unzureichende Berücksichtigung der gesamten Mission und ihres Betriebs nach dem Start als Gesamtsystem, inkonsistente Kommunikation und Schulung innerhalb des Projekts sowie das Fehlen einer vollständigen End-to-End-Verifizierung der Navigationssoftware und der zugehörigen Computermodelle.

Es klingt, als wäre es ein Versagen des Managements und der Qualitätskontrolle auf mehreren Ebenen. Der gesamte Bericht ist auch verfügbar, wenn Sie eine leichte Lektüre vor dem Schlafengehen wünschen.

Der Mars Climate Orbiter war eine der Sonden in der Faster Better Cheaper (FBC)-Initiative des Administrators Goldin, die knappe Budgets und sehr kurze Zeitpläne für Projekte erzwang, was seitdem umstritten ist, da mehrere Ausfälle von Raumfahrzeugen auf Versagen von Management und Technik zurückzuführen sind aufgrund der Eigeninitiative. Die Harvard Business Review hat einen großartigen Artikel, der zusammenfasst, was schief gelaufen ist:

Mit der Umstellung von einem langsamen, zuverlässigen, aber kostspieligen Entwicklungsansatz auf FBC zwang die NASA ihre Projektmanager, radikal neue Prozesse und Verfahren zu erfinden. FBC legte ihnen Budget-, Zeitplan- und Gewichtsbeschränkungen auf, die mit den traditionellen Ansätzen der NASA zur Entwicklung von Raumfahrzeugen nicht erfüllt werden konnten. „Die Einstellung war: ‚Das Buch funktioniert nicht. Also werfen Sie das Buch weg, versuchen Sie etwas anderes und schreiben Sie dann ein neues Buch'“, erklärte ein NASA-Manager. Dieser Ansatz implizierte die Notwendigkeit für Projektmanager, aus den kollektiven Erfahrungen der Organisation zu lernen, zu übernehmen, was funktionierte, und abzuwerfen, was nicht funktionierte. Leider hat die NASA diesen Lernprozess auf verschiedene Weise untergraben.

Erstens forderte die NASA mit dem Start jeder FBC-Mission immer schnellere Entwicklungszeiten und noch niedrigere Kosten. Da es jedoch in der Regel mehr als vier Jahre dauert, bis ein kleines Raumfahrzeug vom Reißbrett zur abgeschlossenen Mission gelangt, waren die Manager gezwungen, die strengeren Anforderungen an neue Projekte zu erfüllen, während frühere Projekte noch im Gange waren. Sie konnten also nicht alle potenziellen Lektionen einer Mission erfassen, bevor sie zur nächsten übergingen. Kurz gesagt, die NASA legte die Messlatte höher, bevor sie prüfte, ob die Projektmanager sie dort löschen konnten, wo sie war. Als die Organisation erkannte, dass sie die Messlatte zu hoch gelegt hatte – ungefähr zu dem Zeitpunkt, als die ersten FBC-Missionen zu scheitern begannen – war die Projektpipeline voller Missionen, die möglicherweise gefährdet waren. Es ist keine Überraschung, dass spätere FBC-Missionen häufiger fehlschlugen als frühere.

Zweitens war der NASA nicht klar, dass die FBC-Initiative, weil sie so sehr auf gemeinsames Lernen angewiesen war, einen aggressiveren und systematischeren Ansatz für das Wissensmanagement erfordern würde. Obwohl die NASA 1995 eine „Lessons Learned“-Datenbank eingeführt hatte, ergab eine Umfrage aus dem Jahr 2001, dass nur ein Viertel ihrer Manager dazu beitrug. Eine ähnliche Anzahl von Managern wusste nicht, dass das System überhaupt existierte. Während „Red Team Reviews“ – regelmäßige Fortschrittsüberprüfungen, die von den erfahrensten Managern der NASA durchgeführt wurden – sich bei frühen FBC-Projekten als unschätzbar erwiesen, führte die NASA bei späteren Missionen weniger dieser Bewertungen durch. Als Folge litt der Lerntransfer innerhalb der Organisation.

Schließlich fiel die NASA dem „abergläubischen Lernen“ zum Opfer – der Annahme, dass man aus gescheiterten Missionen mehr lernen kann als aus erfolgreichen. Im herausfordernden Klima der Weltraumforschung kann der Unterschied zwischen dem Erfolg einer Mission und dem Scheitern einer anderen subtil sein. Es gibt keinen Grund zu der Annahme, dass Erfolg auf einen fehlerfreien Prozess hinweist, während Misserfolg das Ergebnis einer ungeheuerlichen schlechten Praxis ist. Beispielsweise hätten bei der berühmten Pathfinder-Mission von 1997 genauso viele Fehler gemacht werden können wie bei der gescheiterten Polar Lander-Mission von 1999. Aber die NASA wird es nie erfahren. Indem sie bei ihren erfolgreichen Missionen keine detaillierten Postmortems durchführte, verpasste die Weltraumbehörde die Gelegenheit, Probleme (und Lösungen) zu identifizieren, die dazu beigetragen haben könnten, spätere Fehlschläge zu vermeiden.

Eine Zusammenfassung davon wäre, dass der Versuch, das Tempo der Missionen zu beschleunigen und die Kosten zu senken, zwar nichts Schlechtes war, aber die Art und Weise, wie es implementiert wurde, die Menschen zwang, Abstriche zu machen. Die Strategie beruhte auf gemeinsamem Lernen, wobei neuere Projekte den Code, die Ausrüstung, das Wissen und die gewonnenen Erkenntnisse aus älteren Projekten wiederverwendeten, aber die Agentur stellte dafür weder geeignete Werkzeuge bereit, noch förderte sie eine Kultur des Teilens. Lehren aus früheren Projekten wurden nicht gezogen, da die früheren Projekte nicht abgeschlossen wurden, bevor die späteren Projekte gestartet wurden. Sie überprüften die Erfolge nicht, da das Top-Management nicht der Meinung war, dass es etwas zu lernen gab. Es gab mehrere Ausfälle von Raumfahrzeugen, die auf diese Fehlzündung der Strategie zurückgeführt werden, was zu dem Satz führte: "Schneller, besser, billiger - Sie können zwei haben, die Sie mögen".

RickNZ

Ich habe am Mars Climate Orbiter gearbeitet. Die in den Aufzählungspunkten aufgeführten Gründe für diese Antwort klingen für mich zutreffend. Es ist erwähnenswert, dass die Navigation, die erforderlich ist, um das Fahrzeug zum Mars zu bringen, gut funktioniert hat. Es war der endgültige Anflug und Eintritt in die Umlaufbahn, der fehlschlug. Dieser Teil der Mission ist auch am schwierigsten genau zu simulieren, insbesondere in einer Umgebung mit einer Reihe von geografisch unterschiedlichen Spielern.

GdD

Das ist interessant @RickNZ, danke fürs Teilen. Es muss ein schlechter Tag gewesen sein, als das passierte!

1337joe

Es gab eine gute Anzahl von Möglichkeiten, den Fehler nach dem Start zu finden, worauf sich die meisten Berichte über die Mission konzentrieren. Um speziell zu betrachten, welche Tests vor dem Start durchgeführt wurden, bietet dieses Papier der American Astronautical Society einen anständigen Überblick, beginnend auf Seite 6: Die Fehler des Mars Climate Orbiter und des Mars Polar Lander: eine Perspektive der beteiligten Personen

  1. Sie modifizierten Code aus einer früheren Mission, die den Einheitenumrechnungsfaktor hatte, ihn aber in den Gleichungen begrub und ihn nicht kommentierte, um die Umrechnung offensichtlich zu machen.
  2. Anforderungs- und Code-Komplettlösungen haben den fehlenden Umrechnungsfaktor nicht bemerkt, da er im ursprünglichen Code nicht offensichtlich war und sie die vorherige Gleichung nicht in dem erforderlichen Maße verstanden haben, um den Mangel zu erkennen.
  3. Beim formalen Software-Abnahmetest wurde eine "Wahrheitsdatei" verwendet, die durch manuelle Berechnung der codierten Gleichung erstellt wurde, und keine Datendatei aus einer unabhängigen Quelle (wahrscheinlich, weil das Navigationsteam aus Kostengründen erst sehr spät in das Projekt einbezogen wurde). Sparmaßnahme).
  4. Integrationstests bestanden darin, sicherzustellen, dass die Datei erstellt wurde und auf den richtigen Server verschoben werden konnte: Sie taten nichts mit den Daten in der Datei.

Vieles davon lief darauf hinaus, dass sie Code aus einer früheren Mission wiederverwendeten und dort die gesamte Validierung durchlaufen hatten, sodass das Management (das unter dem Druck stand, die Kosten zu minimieren) davon ausging, dass die Änderungen ein geringes Risiko darstellten. Sie haben genug Tests durchgeführt, um sich wohl zu fühlen, aber sie hatten keine Experten zur Hand, um unabhängige Tests durchzuführen, also kauften sie sich nicht viel.

Abgesehen davon bedeutete dieses Versäumnis, tatsächlich aussagekräftige Integrationstests durchzuführen, dass die vom Small Forces-Modul (der Software mit dem Fehler) erzeugten Datendateien beim Start das falsche Format hatten und nicht wirklich verwendet werden konnten. In den ersten Monaten der Mission wendete/berechnete das Navigationsteam die Ergebnisse der Drehimpuls-Entsättigungszündungen manuell auf der Grundlage von E-Mails zwischen ihnen und dem Auftragnehmer.

KalleMP

"Berechnung ... manuell" Wow, zu glauben, dass sie den Fehler gefunden haben könnten, bevor er kritisch wurde. Diese Traurigkeit.

Peter - Wiedereinsetzung von Monica

Fehler bei der Einheitenumrechnung könnten durch geeignete Programmiertechniken nahezu unmöglich gemacht werden. Sie zu unterstützen war eines der Designziele von Ada. Ada ermöglicht es, Untertypen von allen eingebauten Typen zu erstellen. Unterschiedliche Untertypen können einander nicht direkt zugeordnet werden. Man hätte also einen Typ für Fuß und einen anderen für Meter; beide behalten die eingebauten Operatoren bei, aber jede Konvertierung muss explizit sein. Ich dachte, Ada wird in der Raumfahrt und Luftfahrt eingesetzt?

Cort Ammon

@PeterA.Schneider Viele Projekte wurden auf C verschoben. Die Begründung für eine solche Verschiebung geht definitiv weit über den Rahmen eines Kommentars hinaus. Es könnte tatsächlich als verdammte SE-Frage dienen!

ANkeine

Große Organisationen haben große Risse, durch die Dinge herunterfallen können. Die NASA hat die zusätzlichen Probleme von:

  • Es gibt nicht viel Präzedenzfall für die meisten Dinge, die sie tun.

  • Meistens bekommen sie nur eine Chance.

In einem solchen Fall sind die großen Ticketartikel in der Regel gut aufgehoben. Wenn klar ist, was die Frage ist und die Möglichkeit besteht, es falsch zu machen, gibt es Ressourcen, um das Problem zu lösen, und niemand sagt, gehen Sie, bis Sie beweisen können, dass es funktioniert.

Wenn jedoch nicht klar ist, was die zu stellende Frage sein soll, möglicherweise weil es offensichtlich ist, wenn niemand es überprüft, helfen alle Ressourcen der Welt nicht.

Michael Rogers

Ich habe in den 50er und 60er Jahren an den Midas- und Samos -Projekten gearbeitet und am Space Shuttle bis zu seinem Untergang in den 80er Jahren. Bei Ersterem war die Qualitätssicherung umfassend, jede Mutter und jede Lötstelle wurde geprüft. Es gab im Wesentlichen keine Qualitätssicherung auf dem Shuttle, Techniker, die mir gesagt wurden, würden ihre eigene Arbeit inspizieren ! Was viel Zeit und Geld sparen würde.

Wie in den meisten Unternehmen geht es um Geld. Solange die Gewinne die Verluste übersteigen, gilt dies als akzeptabel.

Hobbes

Ihre Informationen zum Shuttle stimmen z. B. mit space.stackexchange.com/questions/9260/… nicht überein - was besagt, dass die Shuttle-Flugsoftware zu den am strengsten überprüften der Welt gehört. Haben Sie weitere Informationen?

Organischer Marmor

Außerdem war der „Untergang“ des Shuttles nicht in den 80er Jahren, sondern im Jahr 2011.

Nathan Tuggy

Außerdem sprechen Sie von Shuttle-Hardware, nicht von MCO-Software.

Peterh

@Hobbes Ich denke, das OP spricht mehr über die mechanischen und regelmäßigen Service-Dinge, nicht über die Software. Und seine Erfahrung stammt hauptsächlich aus der Vor-Challenger-Ära, aus der bekannt ist, dass die Inspektion/Testung nicht so stark war wie nach der Katastrophe.