Softwarefehler in der Raumfahrt
am Beispiel des Pathfinder-Projekts

 

Hauptseminar Analyse von Softwarefehlern
Wintersemester 2002/2003
Prof. Thomas Huckle - TU München

Florian Kreitmaier - Alex Schuster - Marcel Meyer

 

 

Vorwort:
Softwarefehler und ihre Vermeidung spielen eine große Rolle in der Programmentwicklung. An Hand von einigen "klassischen" Beispielen sollten im Hauptseminar "Analyse von Softwarefehlern" gravierende Softwarefehler aus verschiedensten Bereichen analysiert werden.
Das Hauptseminar wurde von Herrn Prof. Thomas Huckle im Wintersemester 2002/2003 an der TU München geleitet und durchgeführt.
Wir - Florian Kreitmaier, Alex Schuster und Marcel Meyer - haben uns mit dem Thema "Mars Pathfinder" auseinandergesetzt. Als weiteres kleines Thema wählten wir noch "NORAD", da wir finden, dass speziell dieses Thema sehr schön zeigt, wie ein simpler Fehler im Softwaresystem das Überleben der Menschheit gefährden kann.

 

Inhalt:

1. Die geplante Mission
1.1 Der Lander
1.2 Die Drone

2. Missionsablauf
2.1 Der Flug
2.2 Die Landung

3. Probleme
3.1 Die Symptome
3.2 Prioritäteninversion allgemein erklärt
3.3 Lösung Prioritätenvererbung
3.4 Lösung Priority Ceiling Protocol
3.5 Prioritäteninversion beim Pathfinder

4. Die Zukunft der Marserkundung

5. NORAD - Wie die Welt beinahe unterging

6. Literaturangaben

 

 

Die geplante Mission

Die Mars-Pathfinder-Mission begann ihre Reise mit dem Start auf einer Delta II Trägerrakete um 1:58 a.m. EST, 4. Dezember 1996 von dem Startkomplex 17B Cape Canaveral Air Station. Auf direktem Weg steuerte der Mars-Pathfinder den Roten Planeten ?Mars an, bei dem er im Juli 1997 unversehrt ankam. Mars Pathfinder sandte einen kleinen Roboter, Sojourner, auf die Oberfläche. Dieser landete durch das Landemodul namens "?Carl Sagan Memorial Station" auch am 4.Juli 1997, dem Unabhängigkeitstag der USA, unversehrt und richtete die Augen der Welt auf ihn. Es wurde ein sensationeller Erfolg, jeder sprach binnen Tagen nur vom ?Mars.
 

Nach den Jahren des Kalten Krieges stehen der ?NASA nun nicht mehr unbegrenzte Mittel zur Verfügung. Sowohl Zeit als auch Geld sind sehr knapp. Daher änderte sich die Strategie der ?NASA zu "faster / better / cheaper". Statt wie bisher für einzelne Projekte bis zu 10 Jahre zu benötigen und dabei immense Kosten zu verursachen, versuchte man ein Projekt mit erheblich weniger Zeit und erheblich weniger Kosten auf die Beine zu stellen. So hatte Pathfinder "nur" ein Budget von 150 Millionen Dollar (es hat letztendlich ca. 170 Millionen Dollar verschlungen). Der Zeitplan des gesamten Projekts war auf 3 Jahre beschränkt.

Daher mussten die Ingenieure abwägen, was selber entwickelt und gebaut werden sollte und was gekauft wird. Eigenentwicklungen sind meist leistungsfähiger, besser angepasst und vor allem zuverlässiger, allerdings auch entscheidend teurer! Militärische Ausrüstung ist zwar zuverlässig und robust genug, aber zu gross, zu schwer und zu stromintensiv für Weltraummissionen. Ausserdem ist sie auch nicht gerade billig. Kommerzielle Systeme sind relativ günstig zu bekommen, in ihren Anforderung meist bedeutend genügsamer, wenn auch nicht so robust. Letztendlich wurden z.B. alle Radios des Kommunikationssystems zugekauft und für die Mission lediglich noch modifiziert. So wurde auch das Betriebssystem für den Roboter Sojourner zugekauft. Man entschied sich für das ?Echtzeitbetriebssystem VxWorks von Windriver.

Das Ziel der gesamten Mission war dreigeteilt:
Es sollte zum einen eine neue Landetechnik erprobt bzw. deren Tauglichkeit für den Einsatz auf anderen Planeten gezeigt werden. Man wollte zum ersten mal in der letzten Landephase nicht auf Fallschirme oder Raketen gesetzt werden, sondern auf Luftsäcke. Das Landemodul pumpt nach dem Abbremsvorgang durch Fallschirme und Raketen in der Atmosphäre Luftsäcke auf, die das Modul vollständig umgeben, und landet daraufhin ungebremst auf der Planetenoberfläche.
Zum anderen sollte gezeigt werden, dass die "faster / better / cheaper"-Strategie wirklich funktioniert.
Und schließlich sollten der Lander und die Drone Bilder der Umgebung aufnehmen, geologische Proben nehmen und vor allem meteorologische Daten sammeln, um Grundlagen für zukünftige Missionen zu schaffen. Die Dauer des Projektes war auf ca. 7 Tage bis max. 1 Monat festgelegt. Danach wären die Batterien der Drone erschöpft, so dachte man. Alles darüber hinausgehende wäre "fein" gewesen. Die Mission dauerte letztendlich 3 Monate und war ein voller Erfolg.

zum Seitenanfang        zum Inhaltsverzeichnis

 

 

Die geplante Mission - Der Lander

Die gesamte Mission besteht im Prinzip aus 5 Teilen:

  • der Transport-Rakete aus dem Erdorbit (Bild 1)
  • einem Antriebsmodul für den Flug zum ?Mars (Bild 2)
  • einem Hilfsmodul welches Bremsraketen und -fallschirme für den Lander bereitstellt (Bild 3)
  • und letztendlich dem eigentlichem Lander (Bild 4)
  • mit der darin enthaltenen Drone (Bild 4)

Bild 1

Bild 2

Bild 3

Bild 4
Das Landemodul trägt den Namen "Carl Sagan Memorial Station" zu Ehren des Astronomen ?Carl Sagan.
Es enthält die gesamte Mikrowellenkommunikationseinheit um mit der Erde kommunizieren zu können. Die Drone selber hat nur eine sehr eingeschränkte Reichweite und nutzt den Lander als Vermittler. Zudem befindet sich auf dem Lander auch die Messeinheit zum Sammeln der meteorologischen Daten und eine Kamera mit welcher im Verlauf der Mission unzählige Fotos von der unmittelbaren aber auch entfernteren Umgebung geschossen werden.

Das System wurde von einem PowerPC, einem gegen Strahlung geschützten IBM RAD6000, kontrolliert und gesteuert. Damit war der Lander das rechenstärkste Gerät, dass das ?JPL jemals ins All geschossen hatte. Als Betriebssystem wurde VxWorks von Wind River eingesetzt. Die Kommunikationsprotokolle etc. wurden vom ?JPL selber entwickelt.

zum Seitenanfang        zum Inhaltsverzeichnis

 

 

Die geplante Mission - Die Drone

Die Jet Propulsion Laboratories (?JPL) konstruierten ein völlig neues Modell, welches in der Lage war, nur aus eigenem Antrieb extrem holpriges Terrain zu überqueren, ohne die Unebenheiten auf den Rover selbst zu übertragen. So war das Fahrzeug in der Lage, Hindernisse bis zum anderthalbfachen seines Raddurchmessers einfach zu überrollen. Auch sollte er sich selbst bei großen Neigungen waagrecht halten können, um nicht die solare Energieversorgung oder die Durchführung der hochentwickelten chemischen und biologischen Experimente zu gefährden. Doch das größte Problem stellte die Steuerung des Gefährts dar: Die Entfernung zur Erde würde sehr groß sein (circa 20 bis 30 Lichtminuten), so dass eine direkte Steuerung so gut wie unmöglich wäre. Daher begann man erste Tests mit intelligenten, eigenständig handelnden Robotern durchzuführen: Erst wurde ein kleines Vehikel mit noch einfacher KI namens Tooth entwickelt, dann Rocky und Rocky 2 und schließlich Rocky 3, welcher in der Wüste sehr gute Ergebnisse vorlegte. So entschloss sich das Pathfinder-Team, auf Grundlage dieser Entwicklungen einen eigenen Rover zu entwerfen. Eine Version des Rocky 3 stellte die Basisversion dar, doch wurde das System von 25 auf 7 Kilogramm abgespeckt und mit moderneren Geräten ausgestattet, beispielsweise einem zigarettenschachtelgroßen Seismometer (welches allerdings später kaum stärkere Marsbeben feststellen sollte). Tests des Vehikels in der Wüste verliefen sehr erfolgreich, der sechsrädige Roboter nahm eigenständig Gesteinsproben und führte Untersuchungen durch.
Doch erst durch einen glücklichen Umstand wurde es offiziell beschlossen, einen Rover in die Konfiguration der Sonde mitaufzunehmen und damit neben technischer Forschung ("faster / better / cheaper") auch wissenschaftliche Forschung durchzuführen, denn deutsche Raumfahrtwissenschaftler boten an, einen am Mainzer Max-Planck-Institut entwickelten Alpha-Proton-Röntgenspektrometer (APXS) zu liefern. Zur Freude der Geologen wurde der Vorschlag angenommen und das APXS neben - ebenfalls in Deutschland entwickelten - Kameras, einer Wetterstation und anderen Instrumenten in die Sonde eingebaut. Doch um das Gerät sinnvoll einzusetzen, musste man es direkt an die Steine heranführen und dazu war eben nur ein Rover geeignet. Damit war der Weg für Sojourner endgültig geebnet.

Als Recheneinheit wurde ein ?80C85-Prozessor gewählt. Dieser ist zwar relativ langsam, aber dafür vor allem sehr stromsparend, was bei der mobilen Einheit trotz einem kleinen Sonnensegel sehr wichtig war. Auch Sojourner wurde übrigens mit dem ?Echtzeitbetriebssystem VxWorks von Windriver betrieben.

Auf der Erde blieb eine exakte Kopie des Sojourners namens "Marie Curie" zurück. Der Hintergedanke war, evtl. auftretende Probleme beim Sojourner auf dem Mars anhand der Kopie direkt nachzuvollziehen und so eine schnellere und bessere Lösung zu finden. Dies erwies sich - wie sich später rausstellte - als gute Investition.

zum Seitenanfang        zum Inhaltsverzeichnis

 

 

Missionsablauf - Der Flug

Der Flug der Mission verlief ohne Probleme. Am 04.12.1996 startete die Trägerrakete, eine Delta-II-Rakete (Bild), von Cape Canaveral. Die Flugbahn von Pathfinder wird während des Fluges insgesamt 4x angepasst (TCM-1 bis TCM-4). Die Sonde konnte wie geplant am 04.07.1997 (dem Unabhängigkeitstag der USA) in die Atmosphäre des ?Mars eindringen. Mit 4,6 mph begann wie geplant der Landeanflug auf den roten Planeten.

zum Seitenanfang        zum Inhaltsverzeichnis

 

 

Missionsablauf - Die Landung

Die erfolgreiche Landung war eines der Hauptziele der Mission. Dieses wurde auch vollständig erreicht – die Landung verlief fast problemlos.

Nach einer siebenmonatigen Reise trat die vom Flugmodul abgetrennte Landeeinheit mit über 7500 m/s in 125 km Höhe in die Mars-Atmosphäre ein. Noch vor der Abtrennung des Hitzeschildes werden die Fallschirme geöffnet. Diese bremsen das gesamte Modul im Verlauf der nächsten 4 Minuten auf ein 10tel der ursprünglichen Geschwindigkeit herab. Nach dem Abwurf des Schildes beginnt Pathfinder den Boden nach einem geeigneten Landeplatz mit Radar abzusuchen. Mit Hilfe der Bremsraketen dann wird das Modul auf max. 25m/s herabgebremst. Kurz vor der Landung dann werden die Luftsäcke aufgeblasen. In einer Höhe von ca. 30 Metern wird der Lander dann vom Anflugmodul getrennt und stürzt ungebremst zu Boden.

Nach dem Aufprall flog Pathfinder noch fast 2,5 Meilen, bis er seinen Landeplatz letztendlich erreichte. Dort wurden die Säcke wieder zusammengezogen, das Landemodul in die richtige Position geschubst und die Ladeklappen geöffnet. Hierbei trat dann das erste Problem auf. Eine der Rampen konnte nicht geöffnet werden, da sich einer der Luftsäcke im Öffnungsmchanismus verklemmt hatte. Sojourner nutze daraufhin aber einfach die zweite, welche sich zuverlässig geöffnet hatte.
Auch unmittelbar nach der Landung begann sich die Hochleistungsantenne mithilfe der Position der Sonne in Richtung Erde auszurichten. Alle warteten gespannt auf das erste Bild von der Oberfläche...

zum Seitenanfang        zum Inhaltsverzeichnis

 

 

Probleme - Die Symptome

Nachdem zuerst alles einwandfrei funktionierte, traten nach Beginn der Aufzeichnung von meteorologischen Daten mit dem Sojourner scheinbar nicht reproduzierbare und zufällige System-Zurücksetzungen auf. Das Betriebssystem startete einfach neu, wobei immer alle bis dahin gesammelten aber noch nicht übertragenen Daten verloren gingen.

Allerdings waren diese Fehler auch schon bei den ersten Tests auf der Erde aufgetreten! Damals aber entschied man sich, die Fehler zu ignorieren. Zum einen schienen es Hardwarefehler zu sein und zum anderen waren sie stets durch einen Neustart des Systems wieder "verschwunden". Dies war eine der negativen Auswirkung der "cheaper / better / faster"-Strategie, welche früher vermutlich niemals vorgekommen wäre.

Nachdem die Fehler auf dem ?Mars recht häufig auftraten, begann man auf der Erde mit einer fieberhaften Suche nach selbigen. Doch trotz ewiger Versuchsreihen schaffte man es nicht mit "Sojourners" Zwilling "Marie Curie" den Fehler zu reproduzieren. Erst früh am darauffolgenden Morgen, als alle Techniker bis auf einen einzigen nach Hause gegangen waren, wurde der Fehler entdeckt. Durch Analyse des Logbuches zu diesem Zeitpunkt konnte festgestellt werden, dass es bei der Programmierung von "Sojourner" ein Problem gab, "Prioritäten-Inversion" genannt.

zum Seitenanfang        zum Inhaltsverzeichnis

 

 

Problem - Prioritäteninversion allgemein erklärt

Bei ?Echtzeitsystemen wird einzelnen Prozessen eine maximale Reaktionszeit garantiert. Um dies zu ermöglichen, erhalten einzelne Prozesse unterschiedliche Prioritäten. Bei einem preemptiven ?Echtzeitsystem wie VxWorks bedeutet dies, dass die Ausführung eines Prozesses mit niedriger Priorität von einem Prozess mit hoher Priorität unterbrochen werden kann.

Im Mehrprogrammbetrieb müssen Ressourcen, auf die von mehreren Prozessen zugegriffen wird, geschützt werden. Beispielsweise darf ein hochpriorisierter Prozess einen niedrigpriorisierten Prozess, der gerade Daten in einen Netzwerkpuffer schreibt, nicht unterbrechen, um selbst Daten in den Puffer zu schreiben, denn ansonsten würden korrupte Daten entstehen.
Um solche Fehler zu vermeiden bieten sich zum Beispiel auf Benutzerebene ?Semaphoren an. Vor dem Aquirieren einer Ressource muss ein Prozess stets die ?Semaphore anfordern und selbige nach Freigabe der Ressource ebenfalls wieder freigeben. Da das Überprüfen und Anfordern eine atomare Operation ist – vom Kern des Betriebssystems sichergestellt – ist dies eine deterministische Methode parallele Zugriffe zu verhindern.
Beispiel:

Prozess L belegt die ?Semaphore (die mit dem Puffer assoziert ist) bevor er Daten in den Puffer schreibt. Wenn nun Prozess H versucht, den laufenden Prozess zu unterbrechen und dieselbe ?Semaphore zu belegen, wird er vom Betriebssystem davon abgehalten. Dies bedeutet, dass H keinen Zugriff auf den Puffer hat und warten muss, bis L seine Arbeit beendet hat und die ?Semaphore frei gibt.

Probleme können dabei auftreten, wenn ein niedrig priorisierter Prozess eine Ressource blockiert und ein hoch priorisierter Prozess dadurch seine Fälligkeit überschreitet. Dies muss bereits beim Entwickeln des System beachtet werden.

 

Ein anderes Problem, welches nur schwer zur Entwicklungszeit vorausgesehen werden kann, tritt auf, wenn 3 oder mehr unterschiedlich priorisierte Prozesse auf eine gemeinsame aber exklusive Ressource zugreifen.

Hat der am niedrigsten priorisierte Prozess (L) eine ?Semaphore blockiert und wird ihm durch einen mittelpriorisierten Prozess (M) zwischenzeitlich der Rechnerkern entzogen, muss ein hochpriorisierter Prozess (H) nach seiner Anforderung der ?Semaphore bis zum Abschluss sämtlicher niedrig- und mittelpriorisierter Prozesse warten (im Beispiel rechnet zuerst M zu Ende, dann erst L, der dann auch die Semaphore frei gibt). Dies kann dazu führen, dass der hochpriorisierte Prozess seine Fälligkeit überschreitet!

Diesen Effekt nennt man Prioritäteninversion (priority inversion).

zum Seitenanfang        zum Inhaltsverzeichnis

 

 

Lösung Prioritätenvererbung

Dem Problem der Prioritäteninversion kann mit der sogenannten Prioritätenvererbung begegnet werden.

Dabei wird dem Prozess, der aktuell eine Ressource belegt, die maximale Priorität der noch auf diese Ressource wartenden Prozesse zugewiesen (die Überwachung der Zugriffe und die Zuweisung erledigt das Betriebssystem). Daduch kann beispielsweise ein mittel priorisierter Prozess nicht die Ausführung eines niedrig priorisierten Prozesses unterbrechen und somit die Ausführung eines hoch priorisierten Prozesses verzögern oder gar verhindern. Der hochpriorisierte Prozess muss nur warten, bis der niedrigpriorisierte Prozess seine Arbeit beendet hat und die ?Semaphore frei gibt. Der ursprünglich niedrigpriorisierte Prozess erhält nach Freigabe der ?Semaphore seine ursprüngliche Priorität zurück.

Ein konkretes Beispiel für diesen Lösungsansatz findet sich weiter unten bei Prioritäteninversion beim Pathfinder.

Aber auch hier kann es Situationen geben, in denen trotz Prioritätsvererbung immer noch Probleme auftreten:

Eines dieser Probleme ist die Verwendung von mehreren Ressourcen durch einen einzelnen Prozess, wenn diese von anderen unterschiedlichen Prozessen bereits belegt werden. Hier kommt zwar der hoch priorisierte Prozess letztendlich schon zur Ausführung, es wird aber sehr lange gewartet.
Ein weiteres Problem ist die Verklemmung. Diese tritt auf, wenn zwei Prozesse auf meherere Ressourcen parallel zugreifen und sich dabei nicht "abstimmen". Im Beispiel nimmt sich der niedrig prioriserte Prozess die ?Semaphore 1, wird durch einen höher priorisierten Prozess unterbrochen welcher sich ?Semaphore 2 nimmt und kommt selbst nach dem Schlafenlegen des höher prioriserten Prozesses nicht mehr zu Ausführung, da er mittlerweile die vom höher priorisierten Prozess belegte ?Semaphore 2 benötigen würde.

zum Seitenanfang        zum Inhaltsverzeichnis

 

 

Lösung Priority Ceiling Protocol

Ein Lösungsansatz, welcher auch die bei der Prioritätsvererbung auftretenden Probleme zu lösen versucht, ist die Verwendung des sogenannten Priority Ceiling Protocols (PCP). Eine Vereinfachung davon, das Immediate Inheritance PCP, ist im Prinzip so leistungsfähig wie das PCP selber und dabei im Prinzip so effektiv wie normale binäre ?Semaphoren.
Der wesentliche Unterschied zwischen beiden besteht darin, dass beim PCP eine bestimmte große Priorität festgelegt wird, die ressourcennutzende Prozesse zugewiesen bekommen, sobald sie aktiv sind. Dies geschieht unabhängig von den möglichen Prioritäten der möglichen Prozesse. IIPCP hingegen sucht speziell nach der größtmöglich auftretenden Priorität eines ressourcennutzenden Prozesses und definiert diese als Standard Priorität für ressourcennutzende Prozesse.

Dazu wird bereits vor Inbetriebnahme (offline sozusagen) die Priorität des Prozesses mit der höchsten Priorität bestimmt, welcher jemals überhaupt eine ?Semaphore anfordern würde. Dieser Wert wird als Semaphoren-Attribut gespeichert. Sobald nun ein Prozess diese ?Semaphore anfordert wird seine Priorität sofort auf eben diesen maximalen Wert angehoben. Somit ist sichergestellt, dass er in seiner Ausführung nicht mehr durch ursprünglich höher priorisierte Prozesse unterbrochen werden und somit dem maximal priorisierten Prozess eine Ressource vorenthalten kann.
Eine Vorstellung von dieser Vorgehensweise erhält man durch folgende Übersicht:


zum Seitenanfang        zum Inhaltsverzeichnis

 

 

Prioritäteninversion beim Pathfinder

Bei der Pathfinder-Mission im Speziellen trat das Problem der Prioritäteninversion folgendermassen zu Tage:
2 Prozesse (Prozess B und Prozess M) mit jeweils unterschiedlicher Priorität konkurrierten um eine gemeinsame Ressource – dem Informationsbus.

Prozess M mit der niedrigsten Priorität aber der längsten Laufzeit war für das Sammeln von meteorologischen Daten zuständig.
Prozess Z mit mittlerer Priorität und Laufzeit sammelte Informationen über den Zustand der Drone und Prozess B (geringe Laufzeit aber höchste Priorität) war für die Verwaltung des Busses zuständig.

Alle drei Prozesse liefen parallel und mussten natürlich gewisse Fälligkeiten erfüllen. An der Grafik sieht man sehr schön das Problem der Prioritäteninversion beim B-Prozess und der daraus resultierenden Nichteinhaltung seiner Fälligkeit.
Eine ebenfalls unabhängig aktive Laufzeitüberwachung erkannte das Problem der Fälligkeitsüberschreitung, interpretierte es als kritischen Fehler und löste eine Systemrücksetzung aus. Alle Daten, welche sich zu diesem Zeitpunkt noch im Zwischenspeicher befanden, gingen natürlich verloren. Auch die bisher durchgeführten Arbeitsschritte wurden zurückgesetzt, so dass nach dem Systemneustart wieder von vorne begonnen werden musste.

Lösung des Problems:

Bei Sojourner löste man dieses Problem mit Prioritätenvererbung. Das Betriebssystem VxWorks unterstützt diese eigentlich von Haus aus, doch war sie ausgerechnet an dieser Stelle deaktiviert worden. Da allerdings ein C-Code-Interpreter auf dem System vorhanden war, schickten die JPL-Ingenieure ein Programm zur Drone hoch, welches letztendlich ein einziges Bit in den Tausenden von Programmzeilen kippte und somit die Überwachung aktivierte.
Nachfolgende Grafik zeigt (bei gleichem Sachverhalt wie oben) den korrekten Ablauf nachdem das Problem behoben wurde.

Nachdem das Betriebssystem sich der Prioritäteninversion angenommen hatte, verlief die Mission die restlichen 3 Monate problemlos.

zum Seitenanfang        zum Inhaltsverzeichnis

 

 

Die Zukunft der Marserkundung

Im Frühjahr 2003 soll eine weitere Mission zum ?Mars gestartet werden. Diesesmal sollen gleich 2 mobile Dronen die Marsoberfläche erkunden.
Die Landung ist für Januar 2004 geplant.
Der Projektname lautet momentan "Mars Exploration Rovers".
Ein endgültiger Name für die einzelnen Dronen ist bisher noch nicht gefunden.

Eine Möglichkeit, in die Geschichte mit einzugehen, bietet www.nametherovers.org – dort kann man Namensvorschläge für die beiden kleinen Roboter abgeben.

zum Seitenanfang        zum Inhaltsverzeichnis

 

 

NORAD - Wie die Welt beinahe unterging

Am 05. Oktober 1960 besichtigten der Präsident von IBM und zwei weitere Unternehmensführer das Hauptquartier der North American Air Defense (?NORAD) in der Nähe von Colorado Springs. Die Besucher wurden in die Kommandozentrale geführt, in welcher über einer riesigen Karte an der Wand, die die USA und große Teile Asiens zeigte, eine Anzeige angebracht war, die die Alarmstufen darstellte. Diese Anzeige war mit den Radaranlagen in Thule in Grönland verbunden (einem vorgeschobenen Beobachtungsposten in der Zeit des kalten Krieges).
Den Besuchern wurde erklärt, dass die Anzahl der "blinkenden Lampen" den Alarmzustand repräsentiert. Eine "blinkende Lampe" bedeutete, dass sich wenige Objekte in der Luft befanden, das ganze also Routine war. Zwei "blinkende Lampen" bedeuteten, dass sich ein paar nichtidentifizierte Objekte in Luftraum befanden. Fünf "blinkende Lampen" hingegen stellten die höchste Alarmstufe dar, die aussagt, dass sich feindliche Atomraketen im Anflug auf Amerika befinden.

Kommandozentrale der NORAD im Cheyenne Mountain
Während sich die Besucher noch in der Kommandozentrale befanden, ging eine Lampe nach der anderen an. Als nach der vierten Lampe auch noch die fünfte Lampe zu blinken begann, stürmten hohe Offiziere aufgeregt in den Raum, gleichzeitig wurden die Besucher in einen anderen Raum begleitet.
Der stellvertretende Chef der Einrichtung, Air Marshal Slemon, nahm sofort Kontakt auf mit dem Chef General Kuter, der sich in einer Höhe von 4500 Metern auf dem Rückweg nach Colorado Springs befand. Slemon erklärte ihm, dass es so aussah, als hätte die Sowjetunion ihre Atomraketen von Sibirien aus gestartet. Daraufhin wurde dann der US-Generalstab zur Beratung hinzugezogen und die Bomber und Raketen wurden auf den Weg gebracht, bevor sie am Boden zerstört werden konnten.
Die Situation bei NORAD war sehr angespannt, aber man sah sich auch vor einem logischen Problem: Man ging mit 99,9 prozentiger Sicherheit davon aus, dass die Sowjetunion einen Angriff auf die USA gestartet hatte. In diesem Fall hätten sich aber die Bahnen der Raketen verfolgen lassen müssen und man hätte dadurch auch bereits feststellen können, welche Ziele in den USA angegriffen werden sollten. Solche Bahnen gab es aber nicht. Nachdem Slemon dann nach Rückfrage beim Geheimdienst erfahren hatte, dass sich ?Chruschtschow zur Zeit in New York bei der Vollversammlung der UNO befindet, wurde er stutzig was den anscheinenden Angriff anbelangt. Er überlegte, dass die Sowjetunion wohl kaum die USA angreifen würde, wenn der vorsitzende der kommunistischen Partei zu Besuch in den USA war. Daher blies er den Alarm ab.
Einige Stunden später konnte man sich langsam ein genaueres Bild über diesen Vorfall machen. Was die Radaranlagen in Thule in Grönland entdeckt hatten, war der Mond, der über Norwegen aufging. Bei der Entwicklung des Systems wurde einfach nicht berücksichtigt, dass der 443.000 Kilometer entfernte Mond als feindliches Objekt in einer Entfernung von 5.000 bis 6.000 Kilometer eingestuft werden könnte. Als die Radarstrahlen auf dem Mond, der an sich ein langsam bewegendes Objekt darstellt, auftrafen, wurde diese reflektiert und das System interpretierte die Echos als weitere russische Raketen. Daher begann für das Frühwarnsystem ein massiver Angriff sowjetischer Atomraketen. So hätte also ein Fehler in der Software bereits in den 60er Jahren beinahe dazu geführt, dass die Zivilisation wie wir sie kennen ausgelöscht worden wäre.


Vermeidung des Fehlers:


Wie hätte man aber diesen kleinen Fehler, der beinahe katastrophale Auswirkungen nach sich zog, nun vermeiden können?
Nun ganz einfach: Durch die Radarstrahlen bzw. die Laufzeit der Radarstrahlen kann man die Entfernung eines Objekts bestimmen. Hätte man nun diese Messung in das Programm miteinbezogen und ausgewertet, hätte man den aufgehenden Mond von anfliegenden Atomraketen unterscheiden können.

weitere Bilder zu NORAD

zum Seitenanfang        zum Inhaltsverzeichnis

 

 

Literaturangaben:

 

zum Seitenanfang        zum Inhaltsverzeichnis

 


website created by Florian Kreitmaier, Alex Schuster and Marcel Meyer