„Program Alarm“

Mit diesen Worten begann ein Vorfall bei der Apollo 11 Landung, den ich in meiner kleinen Serie „40 Jahre erste Mondlandung“ besser beleuchten will. Fangen wir mal an mit der Sicht, welche die Öffentlichkeit mitbekam. Hier der Mitschnitt der Kommunikation:

102:38:26 Armstrong: (With the slightest touch of urgency) Program Alarm.

102:38:28 Duke: It’s looking good to us. Over.

102:38:30 Armstrong: (To Houston) It’s a 1202.

102:38:32 Aldrin: 1202. (Pause)

102:38:42 Armstrong (on-board): (To Buzz) What is it? Let’s incorporate (the landing radar data). (To Houston) Give us a reading on the 1202 Program Alarm.

Erst rund 10 Sekunden später bekam Armstrong die Antwort mit dem Abstieg weiter zu machen (genauer gesagt: Zu diesem Zeitpunkt steuert der LGC (Lunar Module Guidance Computer) noch voll automatisch, die Crew kontrollierte nur die Ausgaben und verglich sie mit Landepunkten die sie zu einer bestimmten Zeit überfliegen sollte).

102:38:53 Duke: Roger. We got you…(With some urgency in his voice) We’re Go on that alarm.

Dieser Alarm taucht nochmal auf:

102:42:19 Aldrin: Program Alarm. (Pause) 1201

102:42:24 Armstrong: 1201. (Pause) (On-board) Okay, 2000 at 50.

102:42:25 Duke: Roger. 1201 alarm. (Pause) We’re Go. Same type. We’re Go.

Als bei

102:43:15 Armstrong (on-board): I’m going to…

Armstrong die Steuerung mit dem Einrasten von P66 auf semiautomatisch umstellt (nicht, wie immer behauptet wird, auf manuell – keine der Mondlandungen benutzte diesen Modus) verschwinden die Programmalarme. Dafür hat die Besatzung nun das Problem, dass sie ihren Landeplatz um 4 Meilen verpasst hat und einer mit Felsen übersäten Gegend herunter kommt.

Soviel zu dem Vorkommnis selber. Nun die Einschätzung aus dem Kontrollzentrum. Dort hatte Steve Bales die Einschätzung weiter zu machen weiter gegeben. Er hatte vor sich eine Karte, in der stand welche Programm Alarme einen Abbruch bedeuten und welche nicht, soweit die Erklärung. Der 1201 und 1202 Programmalaram bedeuteten eine Überlastung des Bordcomputers, der nun neu startete und nieder priorisierte Tasks verwarf, darunter die Anforderung von Aldrin den DeltaH Wert auszugeben, die letzte Aktion, die diesen Alarm auslöste.

Steve Bales hatte diese Tafel geschrieben, nachdem einen Monat vorher bei einem Training der Flugkontrolleure die Programmalarme durchgespielt worden waren und Gene Kranz bei einem 1201 Fehler den Abbruch der Mission anordnete – zu Unrecht, wie er später von den SimSups erfuhr. Was ihn (wie er in seiner Autobiografie schreibt) besonders ärgerte ist, dass er, der so viel Wert auf Missionsregeln legt, eine der Grundlegenden Regeln gebrochen hatte: Es musste neben dem Alarm auch eine Abweichung geben – also die Kontrolle musste verloren sein oder etwas musste nicht mehr funktionieren, damit die Landung abgebrochen wird. Darauf hin gab es eine Revision der Regeln, die auch in die Bücher wanderte. Steve Bales hatte durch seine zusätzlich angefertigte Karte den schnellsten Zugriff, und konnte so als erstes die Antwort geben. Man wusste also in der Flugkontrolle, dass dieser Alarm nicht kritisch war. Zeitgleich gab im Jack Garman im „Trench“. der Verbindung zu den Herstellern der Hardware in den hinteren Räumen die Ursache durch. Beim ersten Fehler war Garman schneller als Bales nachsehen konnte, doch bei den folgenden Aufrauschen hatte Bales die Karte zu Hand und gab sofort das „Go“.

Was jedoch unklar war, war die Ursache. Nach der Landung bekam das MIT IL, welches den LGC und seine Software entwickelte, einige Anrufe von der NASA, die sicher gehen wollte, dass der Fehler nicht nach der Landung beim Rückstart auftrat. Es zeigte sich, dass die primäre Ursache war, dass das Rendezvous Radar von Aldrin aktiviert worden war. Aldrin wollte sicher gehen, dass es funktionieren würde, wenn er es im Falle eines Abbruchs brauchte und hatte dies auch vorher mit dem MIT geklärt. Die Vorgehensweise stand auch im Buch für die Abstiegsprozeduren. Doch anders als im Simulator, wo der Switch keine Bedeutung hatte, wurde nun das Radar aktiviert. Das verursachte an und für sich auch nicht das Problem. Das Landeradar war auch zusammen mit dem Computer getestet worden. Er musste eigentlich in dem gewählten Modus die Daten nicht verarbeiten, sondern nur auslesen. Das Problem war, dass anders als beim MIT wo dies getestet wurde, Radar und Computer an einer Stromversorgung hingen und die Phasen dieser nicht abgestimmt worden waren. Das dies ein Problem bedeuten konnte, war schon 1968 bemerkt, aber nicht korrigiert worden. Das führte dazu, dass Zähler im LGC unkontrollierbar inkrementiert und dekrementiert wurden, als er versuchte die einkommenden Daten zu synchronisieren. Das verursachte 15 % zusätzliche Last. Der LGC war ausgelegt für 85 % Maximallast – nun war er bei 100 %. Eine weitere Anforderung konnte nun zu einer Überlastung führen. In diesem Falle war es Aldrins Anweisung den DELTAH Wert auszugeben.

Doch war die Mission gefährdet? Nein. Der LGC war so programmiert worden, dass eine BAILOUT Routine nun aktiv wurde. Sie startet ihn neu und er verwarf dabei alle niedrig priorisierten Tasks – Der LGC war für seine Zeit extrem modern in der Programmierung: Er hat eine Prioritätensystem, das dafür sorgte, dass er niedrige priorisierte Aktivitäten erst nach den wichtigen Berechnungen ausführte. Weiterhin war eine Anforderung der NASA gewesen, dass man ihn im laufenden Betrieb jederzeit neu starten konnte und er an den Stellen weiterarbeitete, an denen er vorher war – das machte beim Softwaredesign einige Probleme – aber hier bewährte es sich. Der LGC (im heutigen Sinne vergleichbar mit einem Microcontroller) startete im Bruchteil einer Sekunde neu. Die Besatzung merkte keinerlei Beeinflussung des Kontrollverhaltens. Nur die Anzeige von (nicht für die Landung relevanten) Daten fror kurz ein. Die wichtigsten Angaben wie Höhe, Winkel, Geschwindigkeit wurden laufend aktualisiert. Nun ja, eine Einschränkung gab es: Die DELTAH Anforderung von Aldrin wurde ignoriert. Die Bodenkontrolle übermittelte ihm nun die Werte. Sobald Armstrong die Handsteuerung übernahm und den semiautomatischen Modus aktivierte, ging die Arbeitslast des Computers zurück und es gab keine Überlastung mehr.

So war die Lösung relativ einfach: Beim Aufstieg musste das Rendezvous Radar nur in den aktiven Modus gestartet werden, bei dem der Bordcomputer die Daten verarbeitete. Bei diesem konnte der Synchronisationsfehler nicht auftreten. Folgende Missionen sollten dann auch eine Synchronisation der Phasen der Stromversorgung bekommen.

Die gesellschaftliche Bedeutung des Vorfalls ist aber das genaue Gegenteil dessen, was tatsächlich passierte: Steve Bales bekam zusammen mit den Astronauten einen Tapferkeitsorden (stellvertretend für die Flugleitung) weil er die Mission vor dem Scheitern bewahrte. In der Folge erscheinen viele Artikel welche das eingreifen von Menschen rühmten der die Mission rettete, während Computerfehlern sie fast zum Scheitern brachten. (Wahlweise Steve Bales oder Armstrong). Dabei ist nichts weiter von der Wirklichkeit entfernt. Bis heute hält sich diese Vorstellung (ich verweise hier auch mal auf einen Kommentar von Michel van zum Blog).

  • Es war kein Computerfehler. In unserem heutigen Verständnis würden wir es als „Warnung“ interpretieren. Der Computer arbeitete korrekt weiter. Die Mission war nie gefährdet
  • Es war ein Hardwarefehler, bedingt durch eine unterschiedliche Phase die am LGC und Radar anlag
  • Der Computer war sogar so robust programmiert, dass er diesen Fehler abfangen und dadurch erst die Mission rettete (und nicht etwa die Astronauten oder die Flugkontrolle)

Da ganze hatte gesellschaftlichen Einfluss. Als ich meine ersten Computererfahrungen machte galten „Computerfehler“ noch aus beliebte Ausrede. So nach dem Motto: Computer sind fehleranfällig, fallen aus und sind blöd. Meine Erfahrung ist eine andere und seit ich selbst eine Vorlesung in der Programmiersprache Delphi halte bringe ich meinen Studenten bei: „Der Computer macht nicht was Du denkst, sondern was Du programmierst“ und „Wer Blödsinn programmiert wird Blödsinn bekommen“.
1202 Alarm

7 thoughts on “„Program Alarm“

  1. @Daniel: Da ich gerade gestern abend nochmal genau jene Passage in „Man on the Moon“ las, antworte ich einfach mal drauf:

    Armstrong benutzte einen Trigger-Schalter mit dem er manuell die Sinkgeschwindigkeit in „1 feet per second“ Schritten verändern konnte, während der Bordcomputer sich weiterhin um die Horizontalgeschwindigkeit kümmerte. Dementsprechend flog Eagle nur noch semi-, also halb – automatisch.

    Er verringerte auf diese Weise während des Endanflugs die Sinkrate um über einen Krater hinwegzufliegen in dem Eagle ansonsten vollautomatisch gelandet wäre.

    Erst ganz kurz vor dem Aufsetzen flog Armstrong manuell, um auch kleine Seitwärtsbewegungen ausgleichen zu können.

  2. Ähh nein
    Der manuelle Modus wurde niemals bei einer Apollo Mission genutzt, nur ein anderer semiautomatischer Modus. Der manuelle Modus hätte nur zu einem enormen Treibstoffverbrauch geführt, da er das gesamte RCS deaktiviert hätte – jede Translatorische Bewegung führt auch zu Nick/Rollbewegung da der Schubvektor nur zu einem Zeitpunkt durch den Schwerpunkt führt, sich dieser aber durch verbrauchten Treibstoff laufend ändert. In jedem semiautomatischen Modus (wovon es mehrere gab) behält der Computer die Steuerung des RCS und gleicht diese unerwünschten Bewegungen aus.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.