{"id":1571,"date":"2009-07-03T10:57:15","date_gmt":"2009-07-03T08:57:15","guid":{"rendered":"http:\/\/bernd-leitenberger.de\/blog\/?p=1571"},"modified":"2019-07-30T07:15:28","modified_gmt":"2019-07-30T05:15:28","slug":"program-alarm","status":"publish","type":"post","link":"https:\/\/www.bernd-leitenberger.de\/blog\/2009\/07\/03\/program-alarm\/","title":{"rendered":"„Program Alarm“"},"content":{"rendered":"

Mit diesen Worten begann ein Vorfall bei der Apollo 11 Landung, den ich in meiner kleinen Serie \u201e40 Jahre erste Mondlandung\u201c besser beleuchten will. Fangen wir mal an mit der Sicht, welche die Öffentlichkeit mitbekam. Hier der Mitschnitt der Kommunikation:\"\"<\/p>\n

102:38:26<\/strong> Armstrong: (With the slightest touch of urgency) Program Alarm.<\/p>\n

102:38:28<\/strong> Duke: It\u2019s looking good to us. Over.<\/p>\n

102:38:30<\/strong> Armstrong: (To Houston) It\u2019s a 1202.<\/p>\n

<\/a>102:38:32<\/strong> Aldrin: 1202. (Pause)<\/p>\n

102:38:42<\/strong> Armstrong (on-board): (To Buzz) What is it? Let\u2019s incorporate (the landing radar<\/a> data). (To Houston) Give us a reading on the 1202 Program Alarm.<\/p>\n

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).<\/p>\n

102:38:53<\/strong> Duke: Roger. We got you\u2026(With some urgency in his voice) We\u2019re Go on that alarm.<\/p>\n

Dieser Alarm taucht nochmal auf:<\/p>\n

102:42:19<\/strong> Aldrin: Program Alarm. (Pause) 1201<\/p>\n

102:42:24<\/strong> Armstrong: 1201. (Pause) (On-board) Okay, 2000 at 50.<\/p>\n

102:42:25<\/strong> Duke: Roger. 1201 alarm. (Pause) We\u2019re Go. Same type. We\u2019re Go.<\/p>\n

Als bei<\/p>\n

<\/a>102:43:15<\/strong> Armstrong (on-board): I\u2019m going to\u2026<\/p>\n

Armstrong die Steuerung mit dem Einrasten von P66 auf semiautomatisch umstellt (nicht, wie immer behauptet wird, auf manuell \u2013 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.<\/p>\n

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.<\/p>\n

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 \u2013 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 \u2013 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“.<\/p>\n

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 \u2013 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.<\/p>\n

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 \u2013 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 \u2013 das machte beim Softwaredesign einige Probleme \u2013 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.<\/p>\n

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.<\/p>\n

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).<\/p>\n