Apollo 11: Wie ein kleiner Computer die Mondlandung unterstützte

20. Juli 1969. Die Eagle sinkt zur Mondoberfläche. Neil Armstrong und Buzz Aldrin haben begrenzten Treibstoff, einen wechselnden Blick auf das Landegebiet und einen Bordcomputer, der Programmalarm meldet. Michael Collins bleibt mit der Columbia im Mondorbit. In Houston muss die Missionskontrolle entscheiden: Ist diese Warnung ein Grund, den Abstieg abzubrechen?

Der Apollo Guidance Computer wird gerne mit einem heutigen Handy oder Taschenrechner verglichen. Spannender ist eine andere Frage: Wie konnten ein kleiner Rechner, Astronauten, Raumschiffsysteme und ein großes Entwicklungsteam gemeinsam eine Landung ermöglichen? Apollo 11 erzählt vom Rechnen unter engen Grenzen – und davon, welche Arbeit ein Computer bewahren sollte, wenn nicht mehr alles gleichzeitig gelingt.

Der Abstieg der Eagle war gemeinsame Arbeit

Die Landung bestand aus mehr als einer automatisch abgearbeiteten Rechnung. Armstrong bewertete das Gelände und steuerte den Endanflug. Aldrin beobachtete Instrumente und rief Werte aus. Die Missionskontrolle beurteilte Telemetrie und beriet die Besatzung. Berechnungen brauchten Sensordaten; die Steuerung wiederum funktionierende Triebwerke und Raumschiffhardware.

Das Apollo Lunar Surface Journal hält Funksprüche und Zusammenhänge fest. Beim Lesen wird die parallele Arbeit sichtbar: messen, bestätigen, entscheiden, fliegen. Der Rechner unterstützte diese Handlungen. Die Behauptung „Der Computer hat Apollo 11 gelandet“ lässt genau das Zusammenspiel verschwinden, das die Leistung so bemerkenswert macht.

Zum Einstieg helfen drei getrennte Fragen. Navigation: Wo ist das Fahrzeug und wie bewegt es sich? Flugführung: Welcher Weg führt zum Ziel? Regelung: Wie müssen Schub und Lage verändert werden, damit das Fahrzeug diesem Weg folgt? Eine gute Antwort auf eine dieser Fragen löst die anderen nicht automatisch.

Was war der Apollo Guidance Computer?

Der Block-II-AGC wurde am MIT Instrumentation Laboratory entwickelt und von Raytheon gefertigt. Er gehörte zum Führungs-, Navigations- und Steuerungssystem der Raumfahrzeuge. Kommando- und Mondlandemodul hatten jeweils einen eigenen Rechner mit unterschiedlicher Missionssoftware. Das Landeprogramm war also nicht einfach dasselbe Programm wie im Kommandomodul.

Entscheidend war die Echtzeitfähigkeit: Eine nützliche Rechnung musste rechtzeitig vorliegen. Ein genauer Wert, der erst nach dem benötigten Regelzeitpunkt fertig wird, kommt zu spät. Rechenleistung bedeutet hier etwas anderes als die Ladezeit einer heutigen Webseite.

Auch Zuverlässigkeit reicht über Programmcode hinaus. Sensoren können problematische Eingaben liefern, Schnittstellen beanspruchen Rechenzeit, und die Besatzung braucht verständliche Anzeigen. Tests mussten deshalb die Beziehungen zwischen diesen Teilen erfassen. Entwickelt wurde ein zusammenarbeitendes System – einschließlich seiner Reaktion auf gestörte Annahmen.

Die technischen Daten des Apollo-11-Computers

Die Speicherzahlen beziehen sich auf Wörter, nicht unmittelbar auf heutige Acht-Bit-Bytes. Das Paritätsbit dient der Prüfung gespeicherter Information und ist kein zusätzliches Nutzdatenbit. Auch Zahlendarstellung und Befehlssatz unterscheiden sich von modernen Prozessoren. Ein bloßes Teilen zweier Datenblattzahlen ergibt deshalb schnell einen irreführenden Leistungsvergleich.

Ein heutiger Mikrocontroller kann mehr Speicher und einen schnelleren Takt besitzen. Damit hat er noch keine getesteten Apollo-Schnittstellen und keine validierte Flugsoftware. Umgekehrt wäre der AGC für moderne Multimediaaufgaben ungeeignet. „Leistungsfähiger“ braucht eine definierte Aufgabe. Hier zählt, ob die notwendigen Navigations- und Steuerungsarbeiten ihre Fristen einhielten.

DSKY: dem Rechner eine genaue Frage stellen

Display and Keyboard, kurz DSKY, war die numerische Schnittstelle der Besatzung. PROG zeigte das Programm, VERB die Aktion und NOUN die ausgewählten Daten. Drei Zahlenregister mit Vorzeichen stellten Werte dar. Meldeleuchten wiesen beispielsweise auf Programmalarm oder Bedienfehler hin. Hinter den Tasten verbarg sich kein universeller Grafikbildschirm.

Ein gutes Museumsbeispiel ist VERB 16 NOUN 60 ENTR. In unserer Apollo-11-Ausstellung überwacht diese Eingabe Horizontalgeschwindigkeit, Vertikalgeschwindigkeit und Höhe. Die Noun-Tabellen von Luminary099 belegen die Reihenfolge VHORIZ, HDOTDISP und HCALC. Meine Umsetzung verwendet eine vereinfachte Skalierung: Die ersten beiden Register zeigen Zehntel Fuß pro Sekunde, das dritte ganze Fuß.

Die Reihenfolge ist also historisch begründet, die Werte stammen aus meinem Flugmodell. V06 N60 E liest eine Momentaufnahme; KEY REL gibt die laufende Anzeige wieder frei. V35 E demonstriert Lampen und Ziffern, RSET beendet die Vorführung. Das beschreibt die hier unterstützte Bedienung und verspricht keine vollständige Nachbildung der historischen Pinball-Software.

Zum gezielten Erkunden der Schnittstelle gibt es außerdem das frühere Apollo-DSKY-Exponat. Artikel und Landungssimulator ergänzen es, indem sie Zahlenanzeigen mit einem bewegten Fahrzeug verbinden.

Software, Arbeitsspeicher und gewebte Programme

Im Festspeicher lagen Programme, die während der Mission erhalten bleiben sollten. Veränderlicher Speicher nahm Zustände und Zwischenergebnisse auf. Für den Festspeicher nutzte der AGC Core Rope: Informationen wurden durch die Führung von Drähten an magnetischen Kernen dargestellt. Das war gefertigter Programmspeicher, den Astronauten nicht wie RAM umschreiben konnten.

Diese Bauweise verband die Softwarefreigabe mit der Hardwareproduktion. Vor der Herstellung und Prüfung eines Seilspeichers brauchte es einen kontrollierten Programmstand und dessen Validierung. Ein spät entdeckter Fehler konnte damit zum Fertigungs- und Betriebsproblem werden, statt sich durch einen gewöhnlichen Download erledigen zu lassen.

AGC-Quelltexte enthalten Assemblerbefehle und Anweisungen an den Assembler. Ein zusätzliches Interpretationssystem bot kompakte Operationen für Navigationsmathematik, die wiederum Ausführungszeit kosteten. Beides unterscheidet sich vom Intel-8080-Befehlssatz im IMSAI-Artikel. Die Rechner stehen für verschiedene Architekturen und Einsatzziele.

Hinzu kam die Ablaufplanung. Der Executive ordnete Arbeit nach Prioritäten; weitere Mechanismen behandelten kurze zeitkritische Aufgaben und Interrupts. Geschützte Wiederanlaufpunkte erlaubten, ausgewählte wichtige Arbeit nach einem Software-Restart wiederherzustellen. Zuverlässigkeit entstand auch dadurch, dass Entwickler festlegten, welcher Zustand erhalten beziehungsweise rekonstruierbar sein musste.

Luminary 099: der originale Landecode von Apollo 11

Luminary 1A Build 099 war die Führungssoftware des Apollo-11-Mondlandemoduls. Erhaltene Listings wurden durch Archivierungsprojekte wie Virtual AGC digitalisiert und transkribiert. Der archivierte Ausdruck von LMY99 Revision 001 trägt den 14. Juli 1969. Das ist das Datum dieses Listings, kein Beleg dafür, dass das gesamte Programm an diesem Tag geschrieben oder geändert wurde.

Die Ausstellung enthält drei Originaldateien: LUNAR_LANDING_GUIDANCE_EQUATIONS.agc, EXECUTIVE.agc und ALARM_AND_ABORT.agc. Die beibehaltenen Kopfzeilen nennen das MIT-Museum-Material, Paul Fjelds Digitalisierung, Deborah Douglas und die Transkriptionsarbeit. Eine lokale Herkunftsdatei dokumentiert Ausgangscommit, Dateigrößen und SHA-256-Prüfsummen.

Dieser kurze Ausschnitt aus der Public-Domain-Transkription von EXECUTIVE.agc steht im Pfad für fehlende Core-Sets:

        TC      BAILOUT1    # NO CORE SETS AVAILABLE.
        OCT     1202

TC überträgt die Kontrolle. OCT ist eine Assemblerdirektive, die einen oktalen Wert ablegt. Das folgende Wort liefert hier die Alarminformation für den Bailout-Pfad. OCT ist kein CPU-Befehl, der eigenständig eine Fehlermeldung anzeigt. Im Pfad für fehlende VAC-Bereiche findet sich entsprechend OCT 1201.

Aus einer bekannten Anekdote wird so nachprüfbare Technik: Labels, Kommentare, Speicherverwaltung und Wiederanlauf stehen neben Flugführungsrechnungen. Der Viewer zeigt eine historische Quelle. Er ist keine Ausführungsspur mit einem wandernden Befehlszeiger, der suggeriert, Luminary fliege unser Modell.

P63, P64 und P66: drei Aufgaben beim Abstieg

„Armstrong übernahm manuell“ klingt leicht so, als sei der Computer ausgeschaltet worden. P66 zeigt ein interessanteres Bild: Menschliche Entscheidung und rechnergestützte Regelung blieben miteinander verbunden. Der Kommandant konnte das Fahrzeug umlenken, während das System beim Abstieg half.

Unser Simulator übernimmt diese Programmnamen zur Erklärung des Ablaufs. Seine Wechsel bei 1.800 m und 150 m sind gewählte Lernschwellen. Sie reproduzieren weder Luminarys originale Umschaltbedingungen noch die historische Flugbahn der Eagle.

Warum die Alarme 1201 und 1202 die Landung nicht beendeten

Die Alarme meldeten erschöpfte Ressourcen des Executive: 1202 bedeutete fehlende Core-Sets, 1201 fehlende VAC-Bereiche. Gemeint waren Arbeitsbereiche für eingeplante Jobs. Nicht der feste Programmspeicher war plötzlich voll. Die Meldungen bezeichneten Vergabefehler in einem System mit konkurrierender Arbeit.

Der NASA-Missionsbericht führt die Überlast auf die Schnittstelle zwischen Rendezvousradar, Kopplungseinheit und Computer zurück. Unerwartete Zähleraktivität beanspruchte Rechenzyklen. „Zu viele nützliche Radarmessungen“ verkürzt den Mechanismus unzutreffend; auch ein angeblich defekter Prozessor erklärt ihn nicht. Der Bericht dokumentiert fünf Alarme während des angetriebenen Abstiegs.

Als Bild hilft eine kleine Werkstatt mit begrenzten Werkbänken. Die Plätze sind belegt, zusätzliche Aufträge treffen ein. Prioritäten entscheiden, wer als Nächstes arbeiten darf; sie schaffen keine neuen Werkbänke. Ein vorbereiteter Wiederanlauf kann vorübergehende Belegungen auflösen und die wichtigsten Arbeiten an bekannten Stellen wieder aufnehmen. Das ist eine Analogie für geschützte Wiederherstellung, keine vollständige AGC-Ablaufbeschreibung.

Der Restart-Mechanismus stellte geschützte wichtige Arbeit wieder her und verwarf andere Arbeit. Nicht jede Aufgabe überlebte, und nicht jeder beliebige Fehler wäre ungefährlich gewesen. In Houston halfen Steve Bales und Jack Garman bei der Bewertung. Weiterzufliegen setzte voraus, das Alarmverhalten einzuordnen und die fortgesetzte Flugführung zu beurteilen.

Die Lehre ist deshalb an Bedingungen gebunden: Ein System kann eine bestimmte Überlastklasse überstehen, wenn Wiederherstellung und betriebliche Reaktion zusammen vorbereitet sind. Daraus folgt nicht, Warnungen zu ignorieren. NASAs Bericht zu den Programmalarmen und der Missionsbericht ergänzen sich bei dieser Einordnung.

Was meine Mondlandung tatsächlich simuliert

Das Cockpit verbindet Mondansicht, DSKY, Höhen- und Geschwindigkeitsanzeigen mit Schub, Neigung, Treibstoffverbrauch und Landebewertung. Geführter und manueller Flug laufen durch dieselbe eigenständige zweidimensionale Physik. Neigung lenkt den Schub um, Treibstoffverbrauch verändert die Masse, und ein misslungener Anflug kann in einer unsicheren Landung enden.

Das Gelände ist eine eigene Illustration mit ebener Kollisionsfläche. Vollständige Dynamik in sechs Freiheitsgraden, echte Radarfehler, Orbitnavigation, Treibstoffschwappen und Aufstiegs- oder Abbruchverfahren gehören nicht zum Modell. Die Szenarien sind Lernstarts und keine historischen Eagle-Zustandsvektoren. Der geführte Regler reagiert auf Modellabweichungen, statt eine Apollo-Flugbahn abzuspielen.

Die historische Missionszeitleiste läuft als eigener Ereigniswähler neben dem Flug. Die Alarmlektion erklärt einen Zusammenhang, ohne zufällige Störungen in die Flugphysik einzubauen. Im Technikmodus rückt echter Quellcode ins Cockpit. Damit lassen sich historische Quellen und spielerisches Lernen verbinden, ohne eine vollständige Nachbildung aller Systeme zu behaupten.

Die Eagle selbst landen

1. Apollo 11 — Lande die Eagle öffnen. Zunächst Höhe, Vertikal- und Horizontaltempo, Treibstoff, Schub und Neigung suchen.
2. Unter SZENARIO Geführter Abstieg · 6.000 m · P63–66 auswählen und START drücken. Beobachten, wie aus Bremsen Anflug und Endabstieg werden.
3. Mit PAUSE die Instrumente in Ruhe lesen. Auf Einheiten achten: Instrumententafel und DSKY stellen nicht alle Größen in derselben Einheit dar.
4. Für einen eigenen Versuch Endanflug · 120 m · manuell wählen. Schub und Neigung behutsam ändern; seitliche Bewegung ist ebenso wichtig wie die Höhe.
5. SCHWEBESCHUB als Orientierung nutzen. Dieser Schub gleicht das Gewicht bei aktueller Masse aus. Eine vorhandene Sinkgeschwindigkeit verschwindet dadurch nicht sofort.
6. Das DSKY-Tastenfeld fokussieren und V16 N60 E ausprobieren. RSET quittiert Lampen; die getrennte NEUSTART-Taste setzt den Flug zurück.
7. 02 / IM APOLLO-COMPUTER auswählen. Der Flug pausiert, DSKY und Instrumente bleiben neben der Technikansicht erhalten.
8. Im Quellviewer Executive · 1201 / 1202 wählen, Code lesen und die separate Alarmlektion ausprobieren. Anschließend in Modus 01 zurückkehren und den Flug bewusst fortsetzen.

Das bleibende Vorbild: verlässliches Zusammenspiel

Zur MIT-Softwarearbeit gehörten viele Menschen, darunter Margaret Hamilton und Hal Laning, dessen Executive-Entwurf konkurrierende Arbeit organisierte. Spezialisten für Flugführung, Programmierung, Fertigung und Tests sowie Missionskontrolle und Besatzung brachten unterschiedliche Kenntnisse ein. Kein einzelnes Foto und kein Codeausschnitt steht für dieses gesamte System.

Für mich machen solche Details die Landung noch beeindruckender. Knapper Speicher verlangte sorgfältige Entscheidungen; klare Schnittstellen, Validierung und Wiederherstellung machten sie praktisch nutzbar. Die wichtigste Qualität eines Rechners kann sein, wie verlässlich er mit Menschen zusammenarbeitet, sobald die Bedingungen nicht mehr ideal sind. Im Cockpit lässt sich dieses Zusammenspiel erkunden →

Quellen und historischer Code

• NASA: Apollo 11 Mission Report, MSC-00171 — §5, Tabelle 5-I und Untersuchung der Computeralarme.
• NASA: Apollo Lunar Surface Journal, The First Lunar Landing und Program Alarms — Besatzungsinteraktion und Wiederanlauf.
• NASA: Computers in Spaceflight, AGC-Hardware und Software — Technik und Entwicklungsgeschichte.
• Apollo-Gerätehandbuch: Computersubsystem — Oszillator und abgeleitete Zeitbasis.
• Virtual AGC: Rechnerarchitektur, Assemblerhandbuch, DSKY-Dokumentation und Luminary-Archiv.
• MIT: Behind the scenes of the Apollo mission — Menschen und technischer Kontext.
• Auf Commit festgelegtes Apollo-11-Quellarchiv, Virtual-AGC-Projekt und Genauigkeitsbeschreibung unserer Implementierung.

Die Abbildungen zeigen die Museumsimplementierung und eigene Erklärgrafiken. Historische NASA-Fotos oder Filmmaterial sind nicht enthalten. Der Codeausschnitt stammt aus der dokumentierten Public-Domain-Quelle.