500 Millionen US-Dollar pro Codezeile oder die Kosten für Softwarefehler im Weltraum
Vor einigen Monaten endete auf edx.org der Kurs „Einführung in die Weltraumtechnologie: Astronautik und bemannte Flüge (Ende der Luft- und Raumfahrttechnik: Astronautik und bemannte Raumfahrt)“. Der Kurs wurde von einem amerikanischen Astronauten unterrichtet, der derzeit MIT-Professor Jeffrey Alan Hoffman ist. Wie der Name schon sagt, ist der Kurs recht einfach und allgemein, er erschien mir jedoch ziemlich interessant und informativ.In einem Teil des Kurses wird das Thema Sicherheit behandelt, und wir sprechen unter anderem über Software-Sicherheit. Prof. Prof. Hoffman liefert interessante Beispiele für Probleme mit Software für die Luftfahrt und Astronautik. In diesem Artikel werde ich mir Raumbeispiele aus Hoffmanns Vorlesungen genauer ansehen.Mars Polar Lander
Mars Polar Lander (MPL) Ein 290 Kilogramm schweres Raumschiff, das am 3. Januar 1999 von der NASA gestartet wurde, um Boden und Klima rund um den Mars-Südpol zu untersuchen. Am 3. Dezember 1999 konnte das Kontrollzentrum während der Landung die Kommunikation mit dem Gerät nicht wieder aufnehmen.
MPL im NASA LabMit offenen Landemasten und Sonnenkollektoren war die MPL 1,06 m hoch und hatte eine Quergröße von 3,6 m. Die Karosserie besteht aus einer Waben-Aluminium-Struktur, die mit Graphit-Epoxid-Platten befestigt ist. Bei der Landung werden drei Aluminiumstützen aus der Transportposition geöffnet und löschen die Landungsenergie mit Hilfe von zerstörbaren Aluminiumeinsätzen in Form von Waben.Geplanter Landeplatz
MPL tritt in einer Höhe von mehr als 100 km mit einer Geschwindigkeit von ~ 7 km / s in die Marsatmosphäre ein. In 3 Minuten senkt sich das Gerät auf eine Höhe von 8,8 km und verlangsamt sich auf eine Geschwindigkeit von 0,5 km / s. Danach gibt es ein Signal zum Öffnen des Fallschirms, das unmittelbar nach dem Trennen des Hitzeschilds folgt (Hitzeschild). Wenn die Geschwindigkeit des Geräts mit einem Fallschirm auf 85 m / s reduziert wird, beginnt ein Radar zu arbeiten, das die Oberflächenmerkmale überwacht, um den möglichen Landeplatz zu bestimmen.
MPL Flugstufendiagramm1 min nach dem Öffnen des Fallschirms in einer Höhe von 1,3 km bei einer Abstiegsgeschwindigkeit von 80 m / s wird das Abstiegsfahrzeug mit einem Fallschirm (Außenschale) vom Außengehäuse getrennt und landet auf Bremsmotoren. Die erwartete Abstiegszeit bei laufenden Motoren beträgt ungefähr 1 Minute. Während dieser Zeit sinkt das Gerät auf eine Höhe von 12 m. Dann schalten sich die Motoren aus und das Gerät fällt planmäßig auf die Oberfläche. 5 Minuten nach dem Berühren der Oberfläche beginnt das Gerät, Sonnenkollektoren und Antennen auszurichten, wodurch eine Verbindung mit der Erde hergestellt wird. Dann beginnt die Datenübertragungssitzung und signalisiert, dass die Landung erfolgreich war.Der Verlauf der Ereignisse
Am 3. Dezember löste sich das Abstiegsfahrzeug von der Kreuzfahrtbühne und wechselte bis zum Abschluss der Landung in den geplanten Funkstummschaltungsmodus. Um 20:04:00 UTC, 6 Minuten vor dem Eintritt in die Atmosphäre, korrigierte der programmierte Betrieb der Motoren die Position des Geräts und richtete den Wärmeschirm aus. MPL trat um 20:10:00 UTC mit einer Geschwindigkeit von 6,9 km / s in die Marsatmosphäre ein. Die Wiederaufnahme der Kommunikation wurde um 20:39:00 UTC nach der Landung erwartet. Die Verbindung wurde jedoch nie hergestellt und das Gerät für verloren erklärt.Der genaue Grund für den Kommunikationsverlust ist nicht bekannt, aber der Unfalluntersuchungsbericht enthält die Schlussfolgerung, dass die wahrscheinlichste Ursache des Unfalls ein Softwarefehler ist, der die Vibrationen beim Öffnen der Stützen als Vibrationen bei der Landung falsch berechnet hat. Infolgedessen stellte das Gerät die Bremsmotoren in einer Höhe von 40 m ab, obwohl bekannt war, dass die Offenlegung der Stützen zu Fehlalarmen führen könnte. Die Leistungsbeschreibung für die Software sah diesen Fall nicht vor.Zitat aus dem Bericht:„Magnetsensoren an jeder der drei Landestützen dienen dazu, den Moment des Bodenkontakts zu bestimmen und die Landemotoren auszuschalten. Die während mehrerer Tests erhaltenen Daten zeigten, dass bei den Landesensoren (Hallsensoren) während der Offenlegung der Stützen Fehlalarme auftreten (in diesem Moment senkt sich das Gerät mit dem Fallschirm ab). Die Programmlogik empfängt Daten von den Sensoren als Aufnahmesignal, wenn Auslösungen in zwei aufeinanderfolgenden Ablesungen auftreten. Tests haben gezeigt, dass die Kurzzeitsignale, die beim Öffnen der Stützen auftreten, tatsächlich lang genug sind, um ein falsches Positiv zu verursachen. Fast immer erzeugte eine der drei Säulen ein falsches Signal, das das Programm als Landungssignal nahm.Die Software, die Sensorantworten bis zum Einschalten des Bodenberührungserkennungsalgorithmus ignorieren sollte, war falsch organisiert und falsche Antworten wurden im System gespeichert. Sobald der Algorithmus zur Bestimmung der Erdberührung in einer Höhe von 40 m eingeschaltet war, erteilte das Programm sofort den Befehl, die Landemotoren auszuschalten.In einer Höhe von 40 m betrug die Sinkgeschwindigkeit des Fahrzeugs ungefähr 13 m / s (47 km / h), die ohne den Schub der Bremsmotoren in der Nähe der Oberfläche unter dem Einfluss der Marsgravitation auf 22 m / s (80 km / h) anstieg. Die geschätzte Abnahmegeschwindigkeit betrug 2,4 m / s (9 km / h). Bei einer solchen Kollisionsgeschwindigkeit mit der Oberfläche konnte das Gerät nicht überleben. “Wenn Sie sich den Algorithmus des Programms ansehen, können Sie sehen, dass eine Zeile zum Zurücksetzen des Status der IndicatorState-Variablen auf den ursprünglichen Wert FALSE das Gerät retten könnte, was die NASA 328 Millionen US-Dollar gekostet hat.Ariane 5
Am 4. Juni 1996 erfolgte der erste Start der von der Europäischen Weltraumorganisation (ESA) entwickelten neuen Trägerrakete Ariane 5. Der Start endete mit einem Fehlschlag - die Rakete stürzte in der 39. Sekunde des Fluges aufgrund eines fehlerhaften Betriebs der Bordsoftware ab.
Die Einführung der ersten Ariane 5Ariane 5 ist die europäische Trägerrakete der Familie Ariane. Starts finden im Kosmodrom Kourou in Französisch-Guayana statt. Die Entwicklung von Ariane 5 dauerte 10 Jahre, kostete 7 Milliarden US-Dollar und sollte die Trägerrakete Ariane 4 ersetzen.Eine 1996 gestartete Trägerrakete mit einer Masse von 720 Tonnen sollte vier Satelliten mit einer Masse von jeweils 1,2 Tonnen starten. Diese Satelliten drehen sich jeweils in ihrer eigenen Umlaufbahn, bilden ein Tetraeder und arbeiten in einer Gruppe. Es war das europäische Clusterprojekt zur Untersuchung des Erdmagnetfelds (später im Jahr 2000 wurden vier neue Satelliten für das Cluster-II-Programm von zwei Sojus-Trägerraketen erfolgreich in die Umlaufbahn gebracht). .Der Verlauf der Ereignisse
Vor der Beschreibung des Vorfalls ist zu beachten, dass das Design des Navigationssystems (Inertial Reference System - SRI) für Ariane 5 nahezu identisch mit dem Design für Ariane 4 ist, insbesondere in Bezug auf Software.Das Startmoment wird mit H0 bezeichnet. Die Vorgänge vor dem Start erfolgten im Normalmodus bis zu dem Zeitpunkt H0 - 7 Minuten, als die Verletzung des „Sichtbarkeitskriteriums“ aufgezeichnet wurde. Daher wurde der Start um eine Stunde verschoben.Um H0 = 12:33:59 UTC wurde ein Start durchgeführt, der normalerweise bis zum Moment von H0 + 37 Sekunden erfolgte. In den folgenden Sekunden trat eine scharfe Abweichung der Rakete von einem bestimmten Pfad auf, und dann folgte eine Explosion.
Ariane 5 Explosionsmoment beim ersten StartAlso: im Moment H0 + 39 Sek. Nach dem Start wurden aufgrund der hohen aerodynamischen Belastung aufgrund des Überschreitens des "Anstellwinkels" des kritischen Wertes die Startbeschleuniger der Rakete von ihrer Hauptstufe getrennt, die als Grundlage für die Aufnahme des Raketen-Selbstzündungssystems diente.Die Änderung des Anstellwinkels erfolgte aufgrund einer abnormalen Drehung der Düsen von Festbrennstoffverstärkern. Eine solche Abweichung der Düsen der Beschleuniger verursachte einen Befehl des Bordcomputers auf der Grundlage von Informationen des Navigationssystems SRI 2. Einige dieser Informationen waren zu diesem Zeitpunkt falsch: Was als Flugdaten interpretiert wurde, war tatsächlich Tatsächlich handelte es sich um die Diagnoseinformationen des eingebauten Computers des SRI 2-Systems. Der eingebaute Computer SRI 2 übertrug falsche Daten, da er eine abnormale Situation diagnostizierte, indem er eine von einem der Softwaremodule ausgelöste Ausnahme „abfing“. Gleichzeitig konnte der Bordcomputer nicht auf das Backup-System SRI 1 umschalten, da er bereits im vorherigen Zyklus (Zeitraum von 72 ms) aus demselben Grund wie SRI 2 nicht mehr funktioniert hatte.Die von einem der SRI-Softwaremodule "ausgelöste" Ausnahme war das Ergebnis der Konvertierung von Daten von einem 64-Bit-Gleitkommaformat in eine 16-Bit-Ganzzahl mit Vorzeichen, was zu einem Operandenfehler führte. In einer Softwarekomponente, die ausschließlich zur „Anpassung“ einer integrierten Trägheitsplattform entwickelt wurde, ist ein Fehler aufgetreten. Darüber hinaus - das klingt paradox, aber dieses Programmmodul liefert nur dann signifikante Ergebnisse, wenn die Rakete die Startrampe abbricht. Nach dem Start der Rakete hat dieses Modul keine Auswirkungen auf den Flug. Die Einstellfunktion muss jedoch gemäß den dafür festgelegten Anforderungen weitere 50 Sekunden lang wirken. nach der Einleitung des "Flugmodus". Diese Sequenz basiert auf den Anforderungen für Ariane 4, ist jedoch für Ariane 5 nicht erforderlich.Der Fehler "Operandenfehler" trat aufgrund einer unerwartet großen horizontalen Neigung von BH (Horizontal Bias) auf. Der BH-Wert erwies sich als viel höher als erwartet, da sich die Flugbahn der Ariane 5 erheblich von der Flugbahn der Ariane 4 unterschied. Die letzte Maßnahme, die fatale Folgen hatte, war das Herunterfahren des eingebauten SPI-Computers - dementsprechend funktionierte das gesamte Navigationssystem nicht mehr. Es war technisch unmöglich, ihre Handlungen wieder aufzunehmen. Diese gesamte Ereigniskette wurde mithilfe von Computersimulationen vollständig reproduziert. Die Simulationsergebnisse sowie Materialien aus anderen Studien und Experimenten ließen Experten den Schluss zu, dass die Ursachen und Umstände der Katastrophe vollständig identifiziert wurden.
Ariane 5 auf der Startrampe vor einem erfolgreichen Start, Französisch-Guayana 2002.In der Ariane 5-Software finden Sie verschiedene Optionen zur Beseitigung des lästigen Fehlers (diese Optionen spiegeln sich in den Untersuchungsergebnissen wider). Auf die eine oder andere Weise kostete diese Codezeile die ESA 500 Millionen US-Dollar (die Kosten einer Rakete mit Fracht).Ich möchte auch darauf hinweisen, dass nirgends in den Berichten die Hilflosigkeit des Backup-Systems in Ariane 5 bei diesem Vorfall betont wird, obwohl in Vorträgen von Prof. Dr. Hoffman dieser Unfall wird nur in diesem Zusammenhang erwähnt. Mit zwei identischen doppelten Systemen SRI 1 und SRI 2 können wir uns vielleicht vor Problemen mit physischen Geräten in einem der Systeme schützen, aber wenn es zu einem Softwarefehler kommt, ist eine solche Vervielfältigung einfach nutzlos. Dann spricht Hoffman über den nächsten Schritt: die Software zu duplizieren und sie anders zu machen (verschiedene Unternehmen, verschiedene Programmierer). Es scheint, dass wir uns mit einer solchen Struktur vor Fehlern geschützt haben, aber solche Maßnahmen erschweren das Gesamtsystem und schaffen noch mehr Stellen, an denen Fehler auftreten können, und der dritte Fall wird als Beispiel angeführt.Space Shuttle
Am 12. April 1981 machte das wiederverwendbare Raumschiff Columbia im Rahmen des Space-Shuttle-Programms seinen ersten Testflug vom Kosmodrom in Cape Canaveral.
Vorbereitung auf die STS-1-Mission - den ersten Space-Shuttle-FlugDer Verlauf der Ereignisse
Am 10. April 1981, ungefähr 20 Minuten vor dem geplanten Start, versuchten die Astronauten und das Shuttle-Servicepersonal, ein Backup-Flugsteuerungssystem zu starten, das das Haupt-Vier-Computer-System duplizierte, scheiterte jedoch. Der Start wurde 16 Minuten vor der voraussichtlichen Zeit abgesagt und um zwei Tage verschoben.Wie man sich nicht an den berüchtigten Comic erinnert So kam es, dass das Backup-Flugsteuerungssystem BFS (Backup Flight Control System) auf dem fünften Bordcomputer nicht mit dem primären Flugsteuerungssystem PASS (Primary Avionics Software System) synchronisiert werden konnte, das bereits auf vier anderen Bordcomputern ausgeführt wurde. Es gab einen Fehler in der Software - einen sehr kleinen, fast unglaublichen, sehr komplizierten und sehr alten Fehler bei der Initialisierung von PASS.Um das Shuttle zuverlässig zu machen, wird alles darin dupliziert: Sensoren, Elektronik, Steuerungssystem, Computer, Software, Datenbusse, Netzteile. Um das Konzept „Ausfall - Betrieb, Ausfall - Sicherheit“ „FO / FS“ (Ausfall - Betrieb, Ausfall - Sicher) zu erfüllen, wurden viele Komponenten viermal dupliziert: entweder wörtlich (4 Ausrüstungssätze) oder gleichwertig (Wechselstromkreise) Ersetzen eines oder mehrerer der erforderlichen vier Blöcke).Die Nummer vier wurde aus einem logischen und intuitiven Grund gewählt: Das FO / FS-Prinzip erfordert, dass das Gerät nach dem ersten Ausfall voll funktionsfähig bleibt und nach dem zweiten Ausfall eine sichere Rückgabe gewährleistet. Die Mindeststimme erfordert drei Stimmen. In der Anfangsphase müssen Sie also 4 Stimmen haben, damit Sie nach einer Ablehnung abstimmen können. Das Shuttle hatte 5 Bordcomputer, von denen vier dieselbe Software hatten und in allen kritischen Phasen des Fluges arbeiteten. Dieser Ansatz ist ideal bei Problemen mit Computern oder anderen Geräten (Berechnungen zufolge verursachten Fehler in einem System mit drei Computern in drei von einer Million Fällen den Verlust des Geräts, und ein System mit vier Computern reduzierte diese Chance auf vier von einer Milliarde), funktioniert jedoch nicht. angesichts der Möglichkeit eines kritischenschwerwiegender Fehler in der Software. So tauchte auf dem fünften Computer die Idee einer alternativen Software auf, die auf den ersten vier die minimale Softwarefunktionalität ausführen würde.Die Softwareentwicklung für BFS umfasste dieselben Spezifikationen, dieselbe Programmiersprache, denselben Compiler und dieselbe Hardware, auf der diese Software installiert wurde. Es wurde jedoch von einer völlig anderen Organisation (Rockwell International für BFS und IBM, Federal Systems Division für PASS) entwickelt und auf verschiedenen Betriebssystemen installiert. Das Betriebssystem für PASS war asynchron und prioritätsgesteuert (daher erhält die wichtigste Aufgabe immer sofort die Kontrolle über den Computer). Im Gegensatz dazu sieht BFS eher wie ein vollständig synchrones System von „Zeitintervallen“ aus, bei dem jedem Prozess die zugewiesene Zeit zur Vervollständigung seines Zyklus gegeben wird.Leider sind synchrone und asynchrone Systeme schlecht kombiniert. Damit BFS mit PASS synchronisiert werden kann, muss PASS synchron werden oder dies für synchronisierte Prozesse emulieren. Der Emulationsprozess wurde mit minimalem Entwicklungsverlust sichergestellt. Sobald der allererste Computer eingeschaltet und PASS gestartet wurde, versuchte sie, den Beginn aller Prozesse mit den Telemetriedaten des Schiffes zu synchronisieren. Diese Synchronisation wurde durchgeführt, indem der Zeitwert aus den Telemetriedaten gelesen und die Telemetriephasen gemäß der zentralen Zeit berechnet wurden.Am Freitagmorgen, dem 10. April, wurde klar, dass einige Prozesse in PASS nicht in ihrer Phase verarbeitet werden: einen Zyklus früher als die übrigen PASS- und BFS-Prozesse. Unter der Annahme, dass „verschmutzte“ Daten empfangen wurden, hörte BFS bei Bedarf vollständig auf, Informationen von PASS abzuhören, und konnte daher nicht mit PASS synchronisieren. Bei BFS waren die in die Schleife eingehenden Daten früher nur aus dem Gleichgewicht geratene „Interferenzen“.Bereits zu Beginn des Nachmittags konnte die NASA nach Zusammenkunft aller Experten die Art des Problems klären. Der Fehler in der Phaseneinstellung könnte durch die Methode des alten Großvaters behoben werden: Wenn etwas nicht funktioniert, schalten Sie es aus und wieder ein.
Dieser Ansatz funktioniert jedoch nicht für ein vollständig geladenes und startbereites Raumschiff. Bordcomputer spielen eine entscheidende Rolle bei der Verarbeitung der Informationen, die "vom" und "zum" Startvorbereitungssystem für den Weltraum kommen.Die von Experten gesammelten Informationen und die Tatsache, dass der Neustart der Bordcomputer am Freitagabend das Problem behebt, gaben dem NASA-Management genügend Informationen, um einen Start am Sonntagmorgen zu planen. Die wahren Fehlerursachen wurden jedoch am Sonntagabend, 8 Stunden nach dem Start, bekannt gegeben.Bordcomputer verwenden die Timer-Warteschlange des Betriebssystems als Uhr. Der erste Datensatz ist die gewünschte Startzeit des nächsten Prozesses. Wenn Hunderte von Prozessen pro Sekunde ausgeführt werden, zeigt der erste Datensatz immer eine ziemlich genaue aktuelle Zeit (immer) in Eile, aber immer genau genug). Die resultierende Zeit ist für alle Backup-Bordcomputer immer genau gleich. Wenn der allererste Computer gestartet wird - es gibt kein aktives Computing -, ist dies der einzige Moment, in dem die Warteschlange leer ist. Und da es keine anderen funktionierenden Computer gibt, durfte der erste seine Uhr benutzen, um die Zeit zu bestimmen.Aber die Leitung war nicht wie beabsichtigt leer. Zwei Jahre vor dem Start gab es eine Änderung in der Datenbus-Initialisierungsroutine, die durchgeführt wurde, bevor die Startzeit berechnet wurde. Diese Routine fügte einen Verzögerungswert in die Timer-Warteschlange ein. Diese Änderung blieb unbemerkt: Wie die Initialisierung des Busses letztendlich mit der Bestimmung der Phasen für die Telemetrie verbunden ist. Darüber hinaus war diese Zeitverzögerung klein genug, damit der erste Eintrag in der Warteschlange nahe an der Gegenwart lag. Ein Jahr später (ein Jahr vor dem Start) wurde eine weitere Änderung vorgenommen, um eine mögliche Prozessorüberlastung zu beheben. Die Verzögerungszeit wurde geringfügig erhöht. Und dies war genug für die Wahrscheinlichkeit von 1/67, dass beim Einschalten des ersten Bordcomputers bei Ihren Berechnungen der StartzeitWenn die Timer-Warteschlange ein wenig vorwärts läuft, kann er ein Ergebnis erhalten, wenn die Startzeit in der Vergangenheit liegt. Dann verschob das Betriebssystem den Beginn des Prozesses um einen Zyklus (wie bei einem Alarm, wenn es auf "Vergangenheit" gesetzt ist, überspringt es einen 12-Stunden-Zyklus, damit es in der "Zukunft" klingeln kann), was letztendlich dazu führt, dass fast alles Prozesse wurden spät im Zyklus ausgeführt.Tests konnten diesen Fehler erkennen, aber die Wahrscheinlichkeit eines Fehlers trat erst in den späten Testphasen auf, als das gesamte System getestet wurde. Selbst dann erforderten die meisten Tests keine Initialisierung von Grund auf. Und selbst bei Tests, bei denen dies erforderlich war, wurde ein Labor mit ziemlich genauen Modellen für PASS, BFS und Telemetrie benötigt. Und selbst wenn alle oben genannten Bedingungen erfüllt sind, bestand bei Auftreten eines Fehlers die Versuchung, alles neu zu starten und ... den Fehler niemals zu wiederholen und niemals sicher zu sein, ob dies ein Problem im Laboraufbau war. Wahrscheinlich ist genau dies in einem der NASA-Labors etwa 4 Monate vor dem Flug geschehen.Doch an dem Tag, an dem der erste Bordcomputer 30 Stunden vor dem geplanten Start eingeschaltet wurde, machte sich das Problem bemerkbar.Alle Informationen über den Fehler im Shuttle stammen aus einem Artikel von John Garman (stellvertretender Leiter der Abteilung für Weltraumsoftware bei der NASA). Darin schreibt er auch: „Ideale Zuverlässigkeit ist nicht gegeben, weil Projekte immer um Zeit und Kosten verhandeln müssen. Die Herausforderungen, denen wir uns heute gegenübersehen, sind die Wartung von Softwaresystemen vor Ort, das Sammeln großer Änderungen und Ergänzungen in der Entwicklungsphase sowie die Neukonfiguration der Software für Maschinen oder Missionen, die niemals vollständig identisch sind. Es ist leicht zu sagen: "Verstoße nicht gegen die Regeln." Dies ist nicht möglich, ohne die relative Position der Software in eingebetteten Systemen umzukehren - und das ist falsch! Software mag die "Seele" der komplexesten Systeme sein, aber sie ist immer noch nur ein Teil der unterstützenden Hülle, ... ein sehr flexibler Teil. "
Die Shuttle-Landung auf der Oberfläche des ausgetrockneten Rogers LakeDie Kosten für diesen Softwarefehler betragen 0 US-Dollar (natürlich waren die Kosten für die Übertragung des Starts wahrscheinlich beträchtlich, aber angesichts der zuvor berücksichtigten Unfälle, bei denen das Raumschiff vor Abschluss seiner geplanten Mission vollständig verloren ging, waren die Kosten für die Umschulung des Starts I hoch vernachlässigt, zumal ich keine passenden Daten finden konnte).Ich möchte jedoch darauf hinweisen, dass dieser Fehler die Startzeit um zwei Tage verschoben hat: vom 10. auf den 12. April, und meiner Meinung nach war es unmöglich, einen besseren Termin für den ersten Start des Shuttles zu wählen, da am selben Tag genau vor 20 Jahren Yuri Gagarin machte seinen Flug in den Weltraum. Wie kann man sich nicht an die Worte einer Schildkröte erinnern, dass "Zufälligkeit nicht zufällig ist"? Source: https://habr.com/ru/post/de381073/
All Articles