Software-Engineering ohne Neustart-Option im All

Dein Webserver stürzt um 3 Uhr nachts ab. Kubernetes startet ihn neu. Nutzer sehen kurz eine Fehlerseite. Niemand wird gefeuert. Stell dir jetzt vor, dein Server kreist um den Mars, der Neustart dauert 45 Minuten (in denen du keine Lageregelung, keine Temperaturregelung und keine Kommunikation hast), der „Nutzer“ ist ein 2,5-Milliarden-Dollar-Raumfahrzeug, und es gibt kein Kubernetes – nur deinen Code und die strahlungsgehärtete CPU, auf der er läuft.

Weltraumsoftware arbeitet unter Randbedingungen, die normales Software-Engineering geradezu gemütlich aussehen lassen. Du kannst keinen Hotfix ausrollen. Du kannst dich nicht per SSH einloggen und die Logs ansehen. Du kannst keine Server dazustellen, wenn die Last steigt. Jede Zeile Code muss vor dem Start korrekt sein, denn danach ist die Software jahre- oder jahrzehntelang auf sich allein gestellt, läuft auf Hardware, die langsam durch Strahlung beschädigt wird, und kommuniziert über eine Funkverbindung mit mehrminütigen Verzögerungen und Bandbreiten im Kilobit-pro-Sekunde-Bereich.

Die Randbedingungen, die alles prägen

Strahlung. Im Weltraum wird Elektronik ständig von energiereichen Teilchen getroffen. Ein einziges Teilchen kann ein Bit im Speicher kippen (ein sogenannter Single-Event-Upset, kurz SEU), ein Register verfälschen oder einen Prozessor zum Stillstand bringen. Das ist keine Ausnahme: Satelliten im niedrigen Erdorbit erleben pro Tag tausende Bitfehler. Strahlungsgehärtete Komponenten sind deshalb langsamer, teurer und Generationen hinter Consumer-Hardware zurück. Der Prozessor des Mars-Rovers Perseverance ist ein RAD750 – grob vergleichbar mit einem PowerPC aus dem Jahr 1998 mit 200 MHz.

Kommunikationsverzögerungen. Der Mars ist per Funk je nach Bahnposition 4 bis 24 Minuten entfernt, Jupiter 33 bis 54 Minuten. Das ist nicht bloß Latenz, sondern bedeutet, dass das Raumfahrzeug jedes Problem mindestens für die Laufzeit hin und zurück selbstständig behandeln muss, bevor die Bodenstation es überhaupt sieht, geschweige denn einen Befehl schicken kann. Als die Voyager-Sonden in über 22 Lichtstunden Entfernung von der Erde auf eine Anomalie stießen, traf die Software fast zwei Tage lang ihre Entscheidungen allein.

Kein physischer Zugriff. Du kannst keine defekte Komponente austauschen, keinen RAM nachrüsten und keine Festplatte wechseln. Wenn der Hauptrechner ausfällt und das Backup nicht funktioniert, ist die Mission vorbei. Jeder Fehlerfall muss deshalb vor dem Start in der Software vorweggenommen werden.

Wie sich Weltraumcode unterscheidet

Weltraumsoftware nutzt Techniken, die in der normalen Softwareentwicklung als maßlos überdimensioniert gelten würden.

Triple Modular Redundancy (TMR). Kritische Berechnungen laufen dreimal auf drei unabhängigen Prozessoren. Ein Voter vergleicht die drei Ergebnisse und übernimmt die Mehrheitsantwort. Wenn ein Prozessor durch Strahlung ein falsches Ergebnis liefert, überstimmen ihn die beiden anderen. Manche Systeme laufen sogar mit fünf Kopien (Pentuple Redundancy), für noch mehr Sicherheit.

Memory Scrubbing. Ein Hintergrundprozess liest den Speicher permanent aus, prüft ihn mit Error-Correcting Codes (ECC) und korrigiert Einzelbitfehler, bevor sie sich zu nicht mehr korrigierbaren Mehrfachbitfehlern aufsummieren. Das läuft ununterbrochen: Jedes Byte wird mehrmals pro Sekunde geprüft und bei Bedarf korrigiert.

Watchdog-Timer. Hardware-Timer, die regelmäßig von der Software zurückgesetzt werden müssen. Hängt die Software (etwa durch einen strahlungsbedingten Lockup), läuft der Timer ab und löst einen Hardware-Reset aus. Die Software muss so gebaut sein, dass sie unerwartete Neustarts an jeder beliebigen Stelle überlebt – jede Berechnung kann unterbrochen und neu gestartet werden.

// Simplified space software patterns
// Watchdog — must be kicked regularly or hardware resets
void main_loop(void) {
while (1) {
kick_watchdog();  // Reset the timer — we're alive
// All operations must complete within watchdog timeout
read_sensors();
kick_watchdog();
run_attitude_control();
kick_watchdog();
check_thermal_limits();
kick_watchdog();
process_ground_commands();
kick_watchdog();
}
}
// Critical value stored with redundancy
typedef struct {
int32_t value_a;  // Primary copy
int32_t value_b;  // Redundant copy
int32_t value_c;  // Third copy for voting
} RedundantInt;
int32_t read_redundant(RedundantInt *r) {
// Majority vote — tolerates one corrupted copy
if (r->value_a == r->value_b) return r->value_a;
if (r->value_a == r->value_c) return r->value_a;
if (r->value_b == r->value_c) return r->value_b;
// All three differ — flag anomaly
raise_anomaly(MEMORY_CORRUPTION);
return r->value_a;  // Best guess
}

Das Testen ist das eigentliche Produkt

Das Jet Propulsion Laboratory der NASA schätzt, dass das Testen von Weltraumsoftware 60 bis 80 % des gesamten Entwicklungsaufwands verschlingt. Nicht 60 % der Zeit, sondern 60 % der Gesamtkosten. Das Testen ist also teurer als die Entwicklung, weil es die Korrektheit in einem Maß belegen muss, an das normales Software-Testing nicht annähernd herankommt.

Jeder Codepfad muss getestet werden. Nicht „hohe Code Coverage“ im Sinne von Web-Entwicklern – sondern buchstäblich jeder Pfad durch jede Funktion, einschließlich Fehlerpfade, Timeout-Pfade und solcher, die Hardwareausfälle behandeln. 100 % Branch Coverage ist der Ausgangspunkt, nicht das Ziel.

Neben Unit-Tests durchläuft Weltraumsoftware Hardware-in-the-Loop-Tests (die echte Software läuft auf der echten Flughardware, während die Weltraumumgebung simuliert wird), Langzeit-Stresstests (monatelanger Dauerbetrieb, um zeitabhängige Bugs aufzuspüren) und Fault-Injection-Tests (gezielte Speicherkorruption, abgeschaltete Prozessoren und gekappte Kommunikationsverbindungen, um zu prüfen, ob sich die Software erholt).

Formale Verifikation wird zunehmend für die kritischsten Komponenten eingesetzt. Statt zu testen, ob der Code für bestimmte Eingaben funktioniert, beweist formale Verifikation mathematisch, dass er für alle möglichen Eingaben funktioniert. Das ist teuer und langsam, aber für Code, der die Lage (Orientierung) eines Raumfahrzeugs steuert oder den Antrieb verwaltet, ist der Aufwand gerechtfertigt.

Was trotzdem schiefgeht

Trotz dieser Sorgfalt scheitert Weltraumsoftware immer wieder. Die Fehlschläge sind lehrreich, weil sie die Grenzen selbst sorgfältigster Ingenieurskunst zeigen.

• Mars Climate Orbiter (1999) stürzte ab, weil ein Team imperiale Einheiten und das andere metrische verwendete. Die Software war korrekt – die Anforderungen waren falsch. Kein Testaufwand fängt eine falsche Spezifikation ab.
• Ariane 5, Flug 501 (1996) explodierte, weil eine 64-Bit-Fließkommazahl in eine 16-Bit-Ganzzahl umgewandelt wurde und überlief. Der Code stammte von der Ariane 4, wo der Wert nie den 16-Bit-Bereich überschritt. Für die Ariane 4 war der Code korrekt, für die Ariane 5 katastrophal falsch.
• Mars Polar Lander (1999) stürzte vermutlich ab, weil eine Vibration beim Ausfahren der Landebeine als Bodenkontakt fehlinterpretiert wurde und die Triebwerke in 40 Metern Höhe abschalteten. Ein zeitabhängiges Problem bei der Sensorauswertung, das die Tests nicht fanden, weil sie die Vibrationscharakteristik nicht exakt nachbildeten.
• Der anfängliche Spiegelfehler des Hubble-Teleskops (1990) war kein Softwarefehler – der Spiegel wurde wegen eines falsch kalibrierten Prüfinstruments in die falsche Form geschliffen. Das Testwerkzeug selbst hatte einen Fehler.

Der rote Faden: Der Code war laut Spezifikation korrekt, aber die Spezifikation entsprach nicht der Realität. Das ist die schwerste Art von Bug, um sie zu verhindern, denn sie steckt in der Lücke zwischen Modell und Wirklichkeit.

Was Software auf der Erde lernen kann

Die meisten von uns entwickeln keine Weltraumsoftware. Aber einige dieser Praktiken lassen sich direkt auf den Bau zuverlässiger Systeme auf der Erde übertragen.

Auf Neustarts auslegen. Weltraumsoftware geht davon aus, dass sie jederzeit neu gestartet werden kann, und muss dabei in einen bekannten, funktionierenden Zustand zurückkehren. Webservices sollten diese Eigenschaft ebenfalls haben: Erholt sich dein Server nach einem Absturz ohne manuelles Eingreifen? Macht er dort weiter, wo er aufgehört hat, oder gehen Arbeitsschritte verloren? Defensive Engineering Patterns, die Raumfahrtingenieure für unverzichtbar halten, sind in der Webentwicklung oft optional – sollten es aber nicht sein.

Fehlerfälle testen, nicht nur den Happy Path. Weltraumsoftware-Tests spritzen gezielt Fehler: Prozesse werden beendet, Speicher korrumpiert, Netzwerkverbindungen gekappt, bei jedem Systemaufruf werden Fehlercodes zurückgegeben. Die meisten Tests von Webanwendungen prüfen, ob Funktionen laufen, aber nicht, ob das System Fehler sauber behandelt.

Redundanz für kritische Daten. Wenn deine Anwendung Daten speichert, die teuer neu zu erzeugen sind – Finanzdaten, Nutzerinhalte, Konfigurationszustände –, speichere sie redundant und prüfe sie regelmäßig. Datenbankreplikation ist das naheliegendste Beispiel, aber Redundanz innerhalb der Anwendung (Prüfsummen, Validierung, periodische Integritätsprüfungen) fängt Korruption ab, die Replikation nur weiterverbreitet.

Watchdogs für kritische Prozesse. Wenn ein Prozess auf keinen Fall hängen darf, überwache ihn. Nicht nur „läuft der Prozess?“, sondern „macht der Prozess Fortschritte?“. Health Checks, die prüfen, ob das System tatsächlich funktioniert – Anfragen verarbeitet, Zustand aktualisiert, Fristen eingehalten –, fangen Fehler ab, die auf Prozessebene unentdeckt bleiben.

Die neue Weltraumsoftware

Die kommerzielle Raumfahrtindustrie (SpaceX, Rocket Lab, Planet) stellt einige dieser Traditionen infrage. SpaceX setzt auf seinen Falcon-9-Flugcomputern auf Linux und C++ – nach traditionellen Luftfahrtstandards Ketzerei. Planet Labs betreibt Hunderte kleiner Satelliten und behandelt sie eher wie ein verteiltes System als wie maßgeschneiderte Hardware: Fällt ein Satellit aus, gleicht die Konstellation es aus.

Das wirft eine grundsätzlichere Frage auf: Wie viel Zuverlässigkeit brauchst du wirklich? Ein 2,5 Milliarden Dollar teurer Mars-Rover rechtfertigt fünf Jahre Testen. Ein 500.000-Dollar-Kommunikationssatellit, der einer von Hunderten in einer Konstellation ist, rechtfertigt deutlich weniger. Die Ingenieurspraxis sollte zum Risikoprofil passen, statt blind Traditionen aus einer anderen Ära zu folgen.

Die Kernlektion gilt aber unabhängig vom Budget: Software, auf die man nach dem Einsatz physisch nicht mehr zugreifen kann, muss zuverlässiger sein als Software, die man anfassen kann. Ob du ein Raumfahrzeug startest, ein IoT-Flottenupdate ausrollst oder ein Edge-Computing-Netz betreibst – das Prinzip ist dasselbe: Wenn du dich nicht per SSH einloggen und es reparieren kannst, muss die Software damit allein fertig werden. Diese Denkweise, mit Augenmaß angewandt, macht alle Software besser.