Aus Softwarefehlern lernen – Teil 2: Warum explodierte Ariane 5 nach dem Start?

Zahlen wirken in Programmen so selbstverständlich, dass viele Entwicklerinnen und Entwickler sie intuitiv wie in der Mathematik behandeln: Addition, Subtraktion, Multiplikation – was soll da schon schiefgehen? In der Praxis lauern hier jedoch zahlreiche Fallstricke. Speicherbegrenzungen, Rundungsfehler, Konvertierungen zwischen Datentypen und die unterschiedliche Behandlung von Ganzzahlen und Gleitkommazahlen führen immer wieder zu katastrophalen Fehlern.

Muster 2: Überlauf, Arithmetik und Präzision: Wenn Zahlen kippen

Ein ikonisches Beispiel dafür ist der Fehlschlag des ersten Ariane-5-Starts im Jahr 1996. Nur 37 Sekunden nach dem Start verließ die Rakete ihre Flugbahn, begann sich unkontrolliert zu drehen und zerstörte sich schließlich selbst. Die Ursache war nicht ein Materialproblem oder ein Defekt an der Rakete, sondern ein Softwarefehler in der Trägheitsnavigationssoftware.

Konkret versuchte das System, einen 64-Bit-Gleitkommawert in einen 16-Bit-Integer zu konvertieren. Der Wert war für die Ariane 5 jedoch zu groß und es kam zu einem Überlauf, der dann eine Ausnahme auslöste. Die Folge: Das gesamte Leitsystem schaltete sich ab. Da die Rakete zwei identische Systeme hatte, die synchron liefen, wiederholte sich der Fehler sofort auf dem Backup – die Redundanz konnte also nicht helfen.

Das wirft die Frage auf: Warum passiert so etwas in einem milliardenschweren Raumfahrtprogramm? Die Antwort ist tatsächlich lehrreich: Die Software der Ariane 5 basierte in Teilen auf dem Vorgängermodell Ariane 4. Dort waren die Wertebereiche kleiner, und ein 16-Bit-Integer war völlig ausreichend. Bei der Ariane 5 lagen die Beschleunigungen jedoch in einem anderen Bereich. Die alten Annahmen passten nicht mehr, aber die Entwickler haben die entsprechenden Codepfade nie überprüft – schließlich hatte die Software ja bereits jahrelang zuverlässig funktioniert.

Dieses Muster findet sich auch heute immer wieder in unzähligen Projekten:

• Entwicklerinnen und Entwickler übernehmen alte Codepfade, ohne ihre Gültigkeit für neue Einsatzbedingungen zu prüfen.
• Implizite Typumwandlungen oder fehlende Bereichsprüfungen führen im Grenzfall zu Überläufen.
• Fehlerbehandlung fehlt oder ist zu global – wie im Fall der Ariane, bei der eine einzelne Ausnahme zum Totalausfall führte.

In der Praxis begegnen Developer diesem Risiko immer wieder – auch in völlig alltäglichen Projekten. Typische Symptome sind:

• Plötzliche Sprünge oder negative Werte in Zählern,
• NaN-Ergebnisse oder Inf-Werte bei Gleitkommarechnungen und
• stille Rundungsfehler, die sich erst bei großen Zahlen oder nach langer Laufzeit bemerkbar machen.

Das Schlimmste daran ist, dass Gegenmaßnahmen durchaus bekannt sind, häufig aber aus Zeit- und Kostengründen vernachlässigt werden:

1. Explizite Bereichsanalysen: Vor allem bei Übernahmen prüfen, ob alle Wertebereiche noch passen.
2. Saturating Arithmetic oder Clamping: Wenn ein Wert den zulässigen Bereich überschreitet, diesen auf das Maximum setzen oder den Vorgang abbrechen, statt unbemerkt überlaufen zu lassen.
3. „Fail fast“ bei kritischen Konvertierungen: Lieber ein gezielter Fehler, der sich früh zeigt, als eine stille Datenkorruption.
4. Telemetrie und Monitoring: Wertebereiche im Betrieb überwachen und auffällige Ausreißer melden.

Interessant dabei ist auch die psychologische Komponente: Viele Teams verlassen sich auf ihre Testabdeckung und übersehen, dass Testdaten oft zu nett sind. Grenzwerte, Extrembereiche und ungewöhnliche Kombinationen fehlen häufig. Erst Property-based Testing, Fuzzing oder gezielte Grenzwerttests decken die kritischen Fälle auf.

Der Ariane-5-Vorfall hat gezeigt, dass selbst in hochkritischen Projekten mit gefühlt unendlichem Budget ein scheinbar banales Zahlenproblem zu einer Milliardenkatastrophe führen kann. Für den Alltag in der Unternehmens-IT heißt das: Jede Zahl ist ein Modell, und Modelle haben Grenzen. Wer diese Grenzen kennt und absichert, verhindert nicht nur Abstürze, sondern spart sich auch stundenlange Fehlersuche bei subtilen Rundungsfehlern.

Aus Softwarefehlern lernen – die Serie

Diese Artikelserie stellt neun typische Fehlerklassen vor, die in der Praxis immer wieder auftauchen – unabhängig von Branche oder Technologie. In jeder Kategorie wird die Serie ein konkretes Beispiel vorstellen, dessen Ursachen analysieren und daraus ableiten, was Softwareentwicklerinnen und Softwareentwickler langfristig lernen können.

Im nächsten Teil lesen Sie: Concurrency und Scheduling: Wenn sich Prozesse gegenseitig blockieren.

(who)