Softwarefehler und ihre Auswirkungen

„Bugs“ sind eine Fehlerklasse im Bereich Software und umfassen alles von internen Logikproblemen bis hin zu Speicherverwaltungsfehlern und Problemen in Software-Nutzeroberflächen. Da Computer in fast allen Bereichen des Lebens verwendet werden, können Softwarefehler überall auftreten, vom Haushalt über Bankautomaten bis hin zu Kernkraftwerken. Gebiete, in denen die Vorbeugung gegenüber Bugs besonders wichtig ist, sind unter anderem Finanzen, Sicherheit und Kontrollsysteme, zum Beispiel im Verkehr oder in der Energieversorgung. Im Folgenden zwei Beispiele für Bugs, die Unfälle ausgelöst haben: Die Explosion der Ariane 5, der Softwarefehler beim medizinischen Bestrahlungsgerät Therac-25 – und ein Beispiel für eine erfolgreiche Vermeidung: Der Millenium-Bug.

Explosion der Ariane 5

Ein klassisches Beispiel für einen Softwarefehler bei einem Flugkontrollsystem ist der Start der Ariane 5, einer Satellitenträgerrakete der ESA [2].

Am 04.06.1996, ca. 36 Sekunden nach ihrem Start, wich die Rakete stark vom geplanten Kurs ab, fiel auseinander und explodierte im Himmel [3].

Die Ursache für diesen desaströsen Raketenstart war eine Konvertierung einer 64-bit-großen Gleitkommazahl¹ zu einer 16-bit Integer (ganze Zahl)² im Navigationssystem, dem Inertial Reference System (SRI) [3]. Da ein 64-bit-Gleitkommazahl einen viel größeren Wertebereich als ein 16-bit Integer speichern kann, kam es zu einem sogenannten „stack overflow“. Das heißt, der vorhergesehene Speicherplatz wurde quasi überfüllt. Durch diese Überfüllung sendete das SRI eine Fehlermeldung an den Boardcomputer und das SRI stürzte ab [3].

Diese Fehlermeldung wurde von dem Bordcomputer nicht als Fehlermeldung erkannt, sondern als Flugdaten misinterpretiert [3]. Daraufhin wurde der Kurs stark korrigiert [3]. Um diese vermeintliche Kurskorrektur durchzuführen, lenkte der Boardcomputer die Düsen der beiden Feststoffbooster und des Triebwerks in die Extrempositionen [3].

Durch diese plötzliche Auslenkung der Rakete gab es hohe aerodynamische Kräfte, die an der Rakete zerrten [3]. Unter dieser Belastung brach die Verbindung zwischen den Feststoffboostern und der Hauptstufe [3]. Diese getrennte Verbindung war letztendlich das, was eine Selbstzerstörung der Rakete auslöste [3].

Das Bestrahlungsgerät vom Typ Therac-25

In der Medizin können Softwarefehler schlimme Konsequenzen haben. Ein Beispiel ist der Therac-25. Er wurde zur medizinischen Strahlentherapie eingesetzt. Mit Geräten diesen Typs wurden zwischen 1985 und 1987 vier Menschen durch Strahlenüberdosis getötet und zwei schwer verletzt³ [4, 5]. Der Therac-25 war ein Linearbeschleuniger mit zwei Behandlungsmodi, einem Elektronenstrahl und einem Röntgenstrahl, zwischen denen mit einem Drehkopf geschaltet werden konnte [5]. Für den Röntgenbetrieb wurde eine Wolframanode mit einem sehr starken Elektronenstrahl beschossen, und die Anode generierte dann die Röntgenstrahlung.

Das Programm, mit dem der Therac-25 betrieben wurde, wurde von einem einzigen, anonymen Angestellten des Herstellers AECL geschrieben [4]. Außerdem wurde keine sorgfältige Fehleranalyse der Software durchgeführt und der Code wurde während der Entwicklung wenig dokumentiert [4]. Der Code⁴ der Software war deswegen schwer verständlich und als dann mehrere Unfälle passierten, war lange unklar, dass es sich um einen „Bug“ handelte. Diese Unsicherheit wurde dadurch verstärkt, dass Fehlermeldungen nicht im Handbuch erklärt waren und die Software generell fehleranfällig war [4].

Schließlich konnte das zugrunde liegende Software-Problem gefunden werden: Es gab ein Fenster von ca. acht Sekunden, in dem eine Änderung des Behandlungsmodus (Röntgenstrahlung bzw. Elektronenstrahlung) zwar auf dem Bildschirm angezeigt wurde, aber die Wolframanode noch nicht an ihrem Platz war. Bei einer Korrektur in diesem Zeitfenster konnte es passieren, dass der Elektronenstrahl zwar in der starken Einstellung für die Generation von Röntgenstrahlen war, aber die Anode nicht im Strahlengang, und die Patienten direkt mit diesem viel zu starken Strahl beschossen wurden, statt mit Röntgen- oder einem schwächeren therapeutischen Elektronenstrahl [4]. Deswegen erfuhren die Betroffenen einen Elektronenstrahl mit einer Strahlenenergie und Stromstärke, die wesentlich zu hoch für diesen Behandlungsmodus war [4]. Zusätzlich gab es keine mechanische Verriegelung wie bei vorherigen Geräten – und die softwareseitigen Kontrollen waren nicht ausreichend, um einen solchen Fehler in allen Benutzungsszenarien zu finden.

Funktionierende Früherkennung: Millennium Bug

Ein Gegenbeispiel für gute Fehlerbekämpfung ist der Millennium Bug, auch „Y2K-Bug“. Die Jahrtausendwende 1999/2000 erforderte eine Unterscheidung zwischen 1901 und 2001 in Softwareanwendungen. Aber viele Programme speicherten Datum im Format TT.MM.JJ – Jahreszahlen mit zwei Stellen gespeichert, also 1986 als 86, aber jetzt musste man zwischen 1901 und 2001 unterscheiden können [6]. Dieses Problem wurde früh entdeckt und weltweit wurden viele Systeme auf diesen Bug hin untersucht und korrigiert, so dass es beim Jahreswechsel nicht zu großen Störungen kam, auch wenn einige Medien eine Y2K-Apokalypse vorhergesagt hatten. Allerdings wurden viele Geldautomaten in der Sylvesternacht vorsichtshalber abgestellt, im Kernkraftwerk Fukushima fiel die Anzeige für die Steuerstäbe aus und es kam zu kleineren Störungen.

Präventive Strategien

Failure Mode and Effect Analysis

Um Softwarefehlern vorzubeugen gibt es mehrere präventive Strategien. Eine dieser Methoden ist die Failure Mode and Effect Analysis (FMEA) – ein Verfahren, das 1949 von dem US-Militär entwickelt wurde [7]. Die Grundlage ist ein laufender Prozess, der Ursache-Fehler-Wirkungsketten durchspielt [7]. Die Wirksamkeit hängt stark davon ab, dass wirklich alle möglichen Ursachen so klein wie möglich heruntergebrochen werden. Ein Nachteil ist allerdings, dass man letztendlich nur Probleme analysieren kann, wenn man vermutet hat, dass sie auftreten können.

Failure Tree Analysis

Ein anderer Ansatz ist die Failure Tree Analysis (FTA), auch Fault Tree Analysis, bei der das System ausgehend von dem Output betrachtet wird [8]. Wie der Name nahelegt, ist es eigentlich ein Flussdiagramm von Fehlern mit den jeweiligen Auftrittswahrscheinlichkeiten (die natürlich fundiert sein müssen, um aussagekräftig zu sein – eins der Probleme bei der offiziellen FTA des Therac-25 [4, S.8]) [8].

Weitere Maßnahmen

• Unit Testing: Die kleinen Einheiten des Codes einzeln testen – die kritische Konversion bei der Ariane 5 hätte dadurch bemerkt werden können
• Wartbarkeit und Lesbarkeit: Aktiv darauf achten, dass der Code auch für andere Leute leicht lesbar und gut zu überarbeiten ist – einer der Faktoren, der bei den Therac-25-Vorfällen dafür gesorgt hat, dass alles so lange gedauert hat.

Was lässt sich lernen?

Eine sorgfältige Fehleranalyse und Fehlerprävention sind unerlässlich, um Risiken zu identifizieren und kleinzuhalten. Darüber hinaus können Methoden wie Unit Testing und die Sicherstellung von Wartbarkeit und Lesbarkeit des Codes entscheidend dazu beitragen, Bugs zu verhindern und die Reaktionsfähigkeit auf Probleme zu erhöhen.

---

Fußnoten:

1. Eine Gleitkommazahl oder „float“ (kurz für „floating point„) ist ein Datentyp, der sich für sehr große und sehr kleine Zahlen (mit Nachkommastellen) eignet. ↩︎
2. Ein „Integer“ ist ein Datentyp, mit dem nur ganze Zahlen, also ohne Dezimalstellen, gespeichert werden. ↩︎
3. Bei den verschiedenen Fällen wurden Strahlendosen von ca. 13.000 bis 25.000 rads bzw. 130 bis 250 Gy geschätzt ↩︎
4. AECL hat in keinem der Gerichtsverfahren den Code selber vorgelegt, aber durch unterschiedliche Notfalleingriffe der Techniker der Krankenhäuser, in denen die Vorfälle passiert sind, konnte das Programm rekonstruiert werden ↩︎

Quellen:

[1] Explosion der Ariane 5:

https://www.esa.int/ESA_Multimedia/Images/2009/09/Explosion_of_first_Ariane_5_flight_June_4_1996

[2] European Space Agency. (n.d.). Ariane-5 | ESA. Retrieved October 26, 2024, from https://www.esa.int/esapub/achievements/Sc72s6.pdf

[3] Lions, J. L. (19.07.1996). ARIANE 5: Flight 501 Failure. Paris: Inquiry Board (ESA intern).

http://www.rvs.uni-bielefeld.de/publications/Incidents/DOCS/ComAndRep/Ariane/Esa/ariane5/COPY/ariane5rep.html

[4] Leveson, N.G. & Turner, C.S. (July 1993). An Investigation of the Therac-25 Accidents. _Computer_, 26 (7). https://doi.org/10.1109/MC.1993.274940

Gleicher Bericht, besser lesbar unter: http://www.cse.msu.edu/~cse470/Public/Handouts/Therac/Therac_1.html

[5] Leveson, N.G. (1985). Medical Devices: the Therac-25. https://api.semanticscholar.org/CorpusID:13148715

[6] Li, F., Williams, H., & Bogle, M. (1999). The ‚Millennium Bug‘: its origin, potential impact and possible solutions. International Journal of Information Management, 19(1), 3-15. https://doi.org/10.1016/S0268-4012(98)00043-7

[7] Zhu, YM. (2017). Software Failure Mode and Effects Analysis. In: Failure-Modes-Based Software Reading. SpringerBriefs in Computer Science. Springer, Cham. https://doi.org/10.1007/978-3-319-65103-3_2

[8] Signoret, JP., Leroy, A. (2021). Fault Tree Analysis (FTA). In: Reliability Assessment of Safety and Production Systems. Springer Series in Reliability Engineering. Springer, Cham. https://doi.org/10.1007/978-3-030-64708-7_16

[9] Pan, K., Liu, H., Gou, X., Huang, R., Ye, D., Wang, H., Glowacz, A., & Kong, J. (2022). Towards a Systematic Description of Fault Tree Analysis Studies Using Informetric Mapping. Sustainability. 14. 11430. https://doi.org/10.3390/su141811430

Dieser Beitrag wurde redaktionell überarbeitet von Andrea Thorn, Florian Mischke und Pairoh Seeliger.