Margaret Hamilton baute Apollo-Software so, dass sie sicher scheitern konnte – nicht so, dass sie nie scheiterte

Drei Minuten vor der Landung von Apollo 11 begann der Computer der Mondlandefähre Programmalarmmeldungen auszugeben.

Die entscheidende technische Frage war nicht, ob der Computer jede Überlastung für immer verhindern konnte.

Entscheidend war, ob die Software eine Überlastung erkennen, weniger wichtige Arbeit verwerfen, Wesentliches erhalten und schnell genug in einen sicheren Zustand zurückkehren konnte.

Genau diese Unterscheidung steht im Zentrum der Arbeit von Margaret Hamilton am MIT Instrumentation Laboratory.

Software wurde missionskritisch, bevor das Fachgebiet reif war

Als die NASA 1961 ihren ersten Apollo-Vertrag an das MIT vergab, galt Software noch nicht als die ausgereifte Ingenieurdisziplin, die sie später werden sollte. Der Apollo Guidance Computer besaß aus heutiger Sicht winzige Speicher- und Rechenressourcen, musste aber Navigation, Steuerung, Anzeigen, Astronauteninteraktion und missionskritische Abläufe in Echtzeit unterstützen.

Hamilton leitete schließlich die Software Engineering Division des Instrumentation Laboratory. Ihr Team arbeitete an der Bordsoftware für Kommando- und Mondmodul. Das berühmte Foto von Hamilton neben hohen Stapeln ausgedruckten Codes ist deshalb so eindrucksvoll, weil es Software sichtbar macht: Sie war kein unsichtbares Zubehör, sondern Teil des operativen Systems des Raumfahrzeugs.

Die Aufgabe bestand nicht nur darin, korrekte Befehle zu schreiben. Die Software musste auch dann vernünftig reagieren, wenn Daten im falschen Moment eintrafen, die Last anstieg, Menschen Fehler machten oder Hardware unerwartet reagierte.

Die Apollo-11-Alarme testeten Erholung statt Perfektion

Während des Mondabstiegs am 20. Juli 1969 erzeugte der Leitcomputer die Programmalarmmeldungen 1201 und 1202. Historische Berichte der NASA und beteiligter Ingenieure beschreiben eine Überlastung des Executive, ausgelöst durch unnötige Rendezvous-Radar-Aufgaben während des Abstiegs.

Der Computer fror nicht einfach ein. Die Executive-Software konnte neu starten und ausgewählte Programme hoher Priorität wieder aufnehmen, während für die Landung nicht notwendige Arbeit verworfen wurde. Dieses Verhalten war vor der Mission entworfen und ausführlich getestet worden.

Populäre Erzählungen verkürzen die Geschichte manchmal auf „Hamilton schrieb den Code, der Apollo 11 rettete“. Die technische Leistung war breiter und kollektiv. Hamilton führte eine große Softwareorganisation; zahlreiche Ingenieure entwarfen, implementierten, testeten und unterstützten das System. Die Mission konnte weitergehen, weil Architektur und Betriebsteam auf ungewöhnliche Zustände vorbereitet waren.

Hamiltons Beitrag lässt sich daher besser als Führung in einem System verstehen, in dem Zuverlässigkeit auch kontrollierte Wiederherstellung bedeutete.

Zuverlässige Systeme rechnen damit, dass etwas schiefgeht

Ein fragiles System funktioniert, solange jede Annahme wahr bleibt. Ein resilientes System geht von der Gegenannahme aus: Irgendwann wird eine Annahme verletzt.

Hamilton verwies später auf Konzepte wie asynchrone Software, Prioritätsplanung, Prioritätsanzeigen, End-to-End-Tests und Entscheidungen mit dem Menschen im Regelkreis. Die NASA würdigte solche Ideen als Bausteine moderner hochzuverlässiger Softwaretechnik.

Diese Philosophie zeigt sich im Alarmereignis deutlich. Der Computer konnte dringende von weniger wichtiger Arbeit unterscheiden, neu starten und wesentliche Aufgaben erhalten. Mission Control konnte die Alarmmeldungen einordnen, weil das Verhalten getestet und verstanden war.

Keine dieser Eigenschaften machte Fehler unmöglich. Sie machte Fehler überlebbar.

Die tiefere Lektion betrifft die Architektur

Teams behandeln Zuverlässigkeit oft wie ein reines Fehlerzählproblem: Entfernt man genügend Bugs, wird das System sicher. Apollo zeigt eine schwierigere Wahrheit. Manche Störungen entstehen aus unerwarteten Kombinationen korrekter Komponenten, ungewöhnlichem Timing, ausgelasteten Ressourcen oder Verfahren, die unglücklich mit Software zusammenspielen.

Zuverlässigkeit muss deshalb in Architektur und Betrieb eingebaut sein und darf nicht erst am Ende durch zusätzliche Tests ergänzt werden.

Ein gutes System fragt vorher: Welche Arbeit ist absolut wichtig? Was darf entfallen? Welcher Zustand muss einen Neustart überleben? Was soll der Bediener sehen? Was geschieht bei Überlastung? Woran erkennt das Team, dass die Wiederherstellung sicher ist?

Heute stellen wir dieselben Fragen bei verteilten Systemen, Cloud-Infrastruktur, Luftfahrt, Medizintechnik, Cybersicherheit und nahezu jedem Dienst, der unter Belastung verfügbar bleiben soll.

Warum Hamiltons Geschichte weiter relevant ist

2016 erhielt Hamilton die Presidential Medal of Freedom für ihre Beiträge zur Softwaretechnik und zum Apollo-Programm. Zu diesem Zeitpunkt war Software längst zur Infrastruktur fast jeder modernen Branche geworden.

Ihre Geschichte ist gerade deshalb lehrreich, weil Apollo tatsächlich Alarmmeldungen erlebte. Ein System, das nie unter Druck gerät, sagt wenig über seine Resilienz aus.

Der bessere Test beginnt nach dem Alarm.

Kann das System Wichtiges erkennen, Unwichtiges abwerfen, einen bekannten Zustand wiederherstellen, klar mit Menschen kommunizieren und sicher weiterarbeiten?

Perfekte Software ist ein Ziel.

Wiederherstellbare Software ist eine Ingenieurstrategie.

Quellen

• NASA — Margaret Hamilton
• NASA Apollo 11 Lunar Surface Journal — Program Alarms
• MIT News — Margaret Hamilton’s Apollo code
• MIT News — Apollo mission at MIT
• MIT News — Presidential Medal of Freedom
• Titelbild — Draper Laboratory; Restaurierung Adam Cuerden / Wikimedia Commons. In den USA gemeinfrei; freie Nutzung auf Commons durch VRT bestätigt.