Diese Prinzipien klingen zwar einfach, aber in der Praxis werden sie immer wieder infrage gestellt und ignoriert – oft mit schweren Folgen. Denn der Teufel steckt im Detail. In diesem Beitrag schauen wir uns diesen Lebenszyklus mit seinen Varianten genauer an und fassen zusammen, wie man den verursachten Schaden am besten minimieren kann.
Ein wohlbekanntes Beispiel
Am 5. Juli 2023 endete die 27-jährige Geschichte der europäischen Trägerrakete Ariane 5 mit ihrem letzten Start, der den deutschen Satelliten „Heinrich Hertz“ erfolgreich ins All brachte. "Ein guter Anlass, um auf die Geschichte der Ariane 5 zurückzublicken – eine Geschichte, die nicht sehr erfolgreich begann", kommentierte die ARD Tagesschau [ARD23].
Abb. 1: Start der Ariane 501 [Hen97] am 4. Juni 1996. Als blinder Passagier mit an Bord: der Fehlerzustand eines nicht abgefangenen arithmetischen Überlaufs
Dieser nicht sehr erfolgreiche Beginn war der Jungfernflug mit der Seriennummer 501 am 4. Juni 1996. 36,7 Sekunden nach dem Start, als die Ariane 501 etwa 3700 m Höhe erreicht hatte, schlug eine ihrer Softwarekomponenten fehl. In der Folge explodierte die Rakete 66 Sekunden nach dem Start.
Abb. 2: Explosion der Ariane 501 [Hen97] in ca. 4000 m Höhe. Die Fehlerwirkung ist eingetreten
Damit nimmt dieser "holprige Start" [ARD23] einen prominenten Platz im Geschichtsbuch der Softwarefehler ein. Dieser Platz ist aus verschiedenen Gründen wohlberechtigt und der Fall in vieler Hinsicht lehrreich: Es war ein banaler, leicht verständlicher Fehlerzustand in der Software; er hat umfangreiche Teststufen überwunden; die Zuverlässigkeitsmaßnahme eines Ausweichsystems hat beim Eintreten des Fehlschlags nichts geholfen; und schließlich hat der Fehlschlag einen Gesamtverlust von etwa 290 Millionen Euro verursacht.
Darüber hinaus wurde der Fehler durch eine hochkarätige Kommission zügig analysiert [Lio96], und ihr Bericht vom 19. Juli 1996 ist bis heute eine sehr empfehlenswerte Lektüre für jeden Softwareingenieur. Professor Lions und seine Kommission beschrieben darin, wie es zur Explosion kommen konnte. Der Rechner des Trägheitsnavigationssystems beziehungsweise des inertialen Navigationssystems (INS) empfing von einem Sensor eine 64-Bit-Gleitkomma-Variable und konvertierte sie in eine 16-Bit-Ganzzahl mit Vorzeichen. Bei Sekunde 36,7 des Flugs von Ariane 501 meldete der Sensor aber einen höheren Messwert, als in 16 Bit passt. Dieser arithmetische Überlauf wurde im Ada-Code nicht abgefangen und führte zum Ausfall des INS. Der Fehlercode des INS wurde vom On-Board-Lenkungssystem als Kursabweichung interpretiert, und die Rakete setzte zu einem halsbrecherischen Lenkmanöver an, fing an auseinanderzubrechen und löste die Selbstsprengung aus, um keinen weiteren Schaden anzurichten.
Der grundlegende Lebenszyklus eines Softwarefehlers
In der Umgangssprache sprechen wir zwar immer von Fehlern, aber in der Softwaretechnik ist es essenziell, die Begriffe des Fehlerzustands und der Fehlerwirkung auseinanderzuhalten. Das ISTQB-Glossar [Glossar] definiert diese Begriffe im Einklang mit der internationalen Norm [ISO24765] wie folgt:
- Ein Fehlerzustand ist eine Unzulänglichkeit oder ein Mangel in einem Arbeitsergebnis, sodass es seine Anforderungen oder Spezifikationen nicht erfüllt.
- Eine Fehlerwirkung ist ein Ereignis, in welchem eine Komponente oder ein System eine geforderte Funktion nicht im spezifizierten Rahmen ausführt.
Bekanntlich entstehen Fehlerzustände in der Software kaum durch Umwelteinflüsse oder Materialverschleiß, denn Software ist immateriell. Der grundlegende Lebenszyklus eines Softwarefehlers basiert darauf, dass Menschen Fehlhandlungen begehen (Irrtümer), die zu Fehlerzuständen (Defekten) führen, was wiederum zu Fehlerwirkungen führen kann. [CTFL]
In diesem Lebenszyklus gibt es drei Hauptereignisse:
- die Fehlhandlung, die den Fehlerzustand in ein Arbeitsergebnis einfügt,
- die Entdeckung des Fehlerzustands und
- die Behebung des Fehlerzustands.
Das Fehlermanagement der Softwareentwicklung fokussiert auf dem zweiten Teil dieses Lebens, nach der Entdeckung, weil man unentdeckte Fehler nicht verwalten kann. Aber unser Fokus in diesem Beitrag liegt auf dem ersten Teil, zwischen Fehlhandlung und Entdeckung, weil dieser die größten wirtschaftlichen Konsequenzen hat.
Fehlerzustände gar nicht entstehen lassen
Am besten wäre es, so wenige Fehlhandlungen zu begehen wie möglich. Wird kein Fehler eingefügt, dann kosten die Qualitätskontrolle und das Testen weniger, es gibt keine Fehlerbehebungskosten, und schon gar keinen Schaden durch Fehlerwirkungen.
Fehlhandlungen vermeidet man nicht durch Testen, sondern durch vorbeugende Maßnahmen. Empirische Studien nennen die Qualifikation der Beteiligten, Einsatz eines reifen Entwicklungslebenszyklus, die sorgfältige Qualitätssicherung der Anforderungen und Spezifikationen sowie Einsatz geeigneter Programmiersprachen als effektivste Maßnahmen der Fehlervorbeugung.
Ist der Fehlerzustand einmal entstanden, klingt sein Lebenszyklus sehr einfach: Er ist als blinder Passagier mit an Bord, bis er durch Prüfungen entdeckt wird oder eine Fehlerwirkung verursacht. In der Praxis steckt der Teufel aber im Detail. Das Beispiel von Ariane 501 zeigt diese Komplexität.
Auf den ersten Blick scheint die Fehlhandlung bei Ariane 5 passiert zu sein, als der Entwickler die Datenkonversion codiert hat, ohne einen Überlauf abzufangen. Aber in Wirklichkeit stimmt das so nicht. Der Code des INS wurde für Ariane 4 entwickelt und später unverändert in Ariane 5 übernommen. Zur Zeit der Entwicklung des INS galt die Anforderung, aus Performancegründen auf jeden Code zu verzichten, der nicht nötig war. Und die Spezifikation von Ariane 4 sah eine Flugbahn vor, bei der die Messwerte des besagten Sensors immer in die 16-Bit-Festkommazahl hineinpassten. Nur schade, dass Ariane 5 eine andere Flugbahn hatte … Die eigentliche Fehlhandlung war also, das INS in die Ariane 5 zu übernehmen, ohne zu merken, dass das System die neue Flugbahn nicht korrekt verarbeitet.
Eine weitere Fehlhandlung bestand darin, dass die Systemdokumentation des INS nicht deutlich genug auf diese Einschränkung der Funktionalität hingewiesen hat. Auch Dokumentation ist ein wichtiges Arbeitsergebnis, dessen Qualitätssicherung in der Entwicklung viel zu oft vernachlässigt wird.
Arbeitsergebnisse, die Fehlerzustände enthalten können
Wie wir am Beispiel gesehen haben, kann nicht nur Code, sondern auch Dokumentation einen Fehlerzustand enthalten. Für welche Arbeitsergebnisse gilt das noch? Architektur, Entwürfe, Modelle, Konfigurationen, Tests, gehören sicherlich auch dazu.
Gilt das auch für Spezifikationen und Anforderungen? Wenn wir die oben zitierte Definition des Fehlerzustands als Nichterfüllung von Spezifikationen und Anforderungen ernst nehmen wollen, dann nicht. Anforderungen dokumentieren die (informellen) Bedürfnisse an das System, und hier sollten wir eher von Anomalien sprechen. Folglich sind auch die Reviews von Anforderungen und Spezifikationen als eine Fehler vorbeugende Maßnahme anzusehen. Entwickler und Tester, als typische Nutzer der Anforderungen, sollten am Review der Anforderungen und Spezifikationen beteiligt sein – am besten durch perspektivisches Lesen, einem Reviewverfahren, dessen Effektivität empirisch nachgewiesen ist.
Fehler bei Tests nicht entgehen lassen
Ist der Fehlerzustand als blinder Passagier mit an Bord, gilt es, ihn schnell zu entdecken. Empirische Evidenz belegt es immer wieder: Je früher ein Fehlerzustand im Softwarelebenszyklus nach der Fehlhandlung entdeckt wird, desto günstiger ist seine Behebung und desto weniger Schaden kann durch die Fehlerwirkung entstehen.
Bei Codierfehlern haben wir die frühesten Möglichkeiten bei der statischen Codeanalyse und beim Codereview. Diese statischen Tests finden die Fehlerzustände selbst – die Analyse einer Fehlerwirkung und das Debugging entfallen. Bei der heutigen Qualität und Verfügbarkeit der Werkzeuge wie SonarQube ist die statische Codeanalyse die effizienteste QS-Maßnahme gegen Codierfehler – man muss sie aber auch konsequent einsetzen [Hol13]. Und es besteht große Hoffnung, dass durch den Einsatz von künstlicher Intelligenz (KI) die statische Codeanalyse einen weiteren kräftigen Schub zur Effektivität bekommen wird [Fie23]. Frühe Fehlerentdeckung setzt sich mit den Komponententests (heute meist Unittests genannt) fort, die immer noch wesentlich effizienter sind als spätere System- oder Abnahmetests.
Unser Ariane-5-Beispiel zeigt interessanterweise auch diesen Aspekt. Das INS war durch statische Codeanalyse geprüft und man hat bei Ariane 4 einige Anomalien bewusst akzeptiert, um die Performanzanforderung zu erfüllen. Bei der Entscheidung, das INS aus Ariane 4 ins Ariane-5-Programm zu übernehmen, wurde das Ergebnis der statischen Codeanalyse erneut geprüft, und eine Reihe von Anomalien behoben. Aber nicht der abgefangene arithmetische Überlauf, von dem man "bewiesen" hatte, dass er bei der geplanten Flugbahn nicht eintreten kann.
Ein gutes Beispiel für einen entgangenen Fehler, das heißt einen Fehlerzustand, der nicht durch eine Testaktivität entdeckt wurde, obwohl diese den Fehlerzustand hätte finden sollen [Glossar].
Eine spätere Teststufe, der Systemintegrationstest (in [Lio96] finaler Systemtest genannt), hätte wieder große Chancen gehabt, den Fehlerzustand im INS zu entdecken. Bei diesem Software-in-the-Loop-Test wurde die Sensorik mit der Flugbahn der Ariane 5 simuliert. Das Projektteam hat aber die Fehlentscheidung getroffen, das INS (und seine Backupversion) nicht in diesen Test einzubinden, weil es sich auf die erwiesene Zuverlässigkeit bei Ariane 4 verlassen hat und weil so eine Teststufe sehr teuer ist. So ist der Fehler schon wieder beim Testen entgangen.
Fehlertoleranz
Dass Fehlerzustände eingebaut werden können und den QS-Maßnahmen entgehen können, verursacht ein Produktrisiko: dass die resultierende Fehlerwirkung die Qualität des Softwareprodukts beeinträchtigt. Maßnahmen zur Fehlervermeidung und solche zur Fehlerentdeckung (Tests) verringern die Eintrittswahrscheinlichkeit dieses Risikos.
Die Eintrittswahrscheinlichkeit können wir aber nicht realistisch auf 0 drücken und damit das Risiko komplett vermeiden. Deshalb ist es bei sehr hohem Schadenpotenzial wie zum Beispiel bei Raketensoftware wichtig, auch solche Maßnahmen zu treffen, die die Schadenhöhe im Fall der Fälle beschränken. Das gilt auch für Systeme, bei denen ein im Betrieb entdeckter Fehlerzustand nicht zeitnah behoben werden kann. Wir sprechen in diesem Zusammenhang von Fehlertoleranz: dem Grad, zu dem eine Komponente oder ein System trotz Vorhandensein von Hard- oder Softwarefehlern bestimmungsgemäß funktioniert. In fehlertoleranten Systemen kann ein Fehler ein längeres Leben führen, in dem die Fehlerwirkung mehrfach eintritt, bevor der Fehlerzustand behoben wird.
Bei Ariane 5 hat die Softwarearchitektur versucht, die Fehlertoleranz durch den Einbau eines zweiten identischen INS-Systems zu lösen. Eine Fehlhandlung mit fatalen Folgen. Diese Architektur mag bei Hardwarekomponenten wie zum Beispiel den Sensoren helfen, aber im Fall von immaterieller Software kann sie nicht funktionieren. Als bei Ariane 501 in Sekunde 36,7 das Haupt-INS den arithmetischen Überlauf bekam und ausfiel, war das Ersatz-INS aus dem gleichen Grund bereits ausgefallen. Die Systemsteuerung hatte keine Ausweichmöglichkeit mehr. Der Fehler wurde nicht toleriert, sondern zeigte fatale Wirkung.
Die Raumfahrtindustrie hat seitdem dazugelernt und erhöht die Fehlertoleranz durch unabhängig entwickelte Ersatzsysteme. Um die Kosten im Rahmen zu halten, bieten solche Ersatzsysteme nur die vitale Grundfunktionalität des Hauptsystems [Hol13].
Schlussfolgerung
Der "holprige Start" der Ariane führt uns auch vor Augen, wie wichtig der Lebenszyklus von Fehlern ist, vom Einbau des Fehlerzustands bis zu seiner Behebung. Auch wenn nicht alle Raketensoftware bauen, sollten alle an der Systementwicklung Beteiligten – ob Entwickler, Tester, oder Fachexperten – die Grundbegriffe Fehlhandlung, Fehlerzustand, Fehlerwirkung, Fehlertoleranz oder Anomalie verstehen und differenzieren. Wir alle sollten gemeinsam anstreben, dass möglichst wenige Fehlerzustände zum blinden Passagier unserer Systeme werden. Und wenn das doch geschieht, sollten wir die Lebensspanne der Fehlerzustände möglichst kurz halten.
Weitere Informationen
[ARD23] ARD Tagesschau: Letzter Flug der Ariane 5 – Erfolgsgeschichte mit holprigem Start, siehe:
www.tagesschau.de/wissen/technologie/ariane-letzter-flug-100.html
[CTFL] ISTQB/GTB Lehrplan Certified Tester Foundation Level, Version v4.0, 4.8.2023, siehe:
www.german-testing-board.info/lehrplaene/istqbr-certified-tester-schema/core-module/certified-tester/
[Dal97] J. de Dalmau, J. Gigou, Ariane-5: Learning from Flight 501 and Preparing for 502, 1997, siehe:
www.esa.int/esapub/bulletin/bullet89/dalma89.htm
[Fie23] F. Fieber, Wie wird sich Softwaretesten durch KI verändern?, Testing Intelligence – Testen mit KI, siehe:
www.testing-intelligence.com/
[Glossar] ISTQB/GTB Standardglossar der Testbegriffe, Version 4.1 vom 30.6.2023, siehe:
glossary.istqb.org/de_DE/search
[Hen97] J.-Y. Henrion, T. Valilée, Chronologie V88 Ariane 501, siehe: http://www.capcomespace.net/dossiers/espace_europeen/ariane/ariane5/AR501/V88_AR501.htm
[Hol13] G. J. Holzmann, Landing a Spacecraft on Mars, IEEE Software Magazine, 2013
[ISO24765] ISO/IEC/IEEE Standard 24765: Systems and software engineering – Vocabulary, 2017, siehe:
www.iso.org/standard/71952.html
[Lio96] J.-L. Lions u. a., Ariane 5 Flight 501 Failure – Report by the Enquiry Board, 1996, siehe: esamultimedia.esa.int/docs/esa-x-1819eng.pdf
