Aus Softwarefehlern lernen – Teil 9: Bugs entscheiden über Leben und Tod

In den bisherigen Kategorien ging es um viele Fehler, die wirtschaftliche Verluste oder Projektkatastrophen ausgelöst haben. Doch es gibt eine Klasse von Softwarefehlern, die weit schwerwiegendere Konsequenzen haben: sicherheitskritische Fehler, die Menschenleben kosten können.

Muster 9: Sicherheitskritische Systeme – Wenn Software über Leben und Tod entscheidet

Sicherheitskritische Systeme finden sich überall dort, wo Software unmittelbar mit physischen Prozessen interagiert – in der Luftfahrt, der Medizintechnik, der Automobilbranche, der Bahntechnik und in der Industrieautomation. Wenn hier ein Bug auftritt, sind die Folgen oft irreversibel.

Der Therac-25 war ein medizinischer Linearbeschleuniger, entwickelt zur Strahlentherapie von Krebspatientinnen und -patienten. Die Maschine war eine Weiterentwicklung der Vorgängermodelle Therac-6 und Therac-20, die noch stark auf Hardwaresicherungen und physische Interlocks setzten. Beim Therac-25 verlagerte der Hersteller viele dieser Sicherheitsmechanismen in die Software – eine Entscheidung, die sich als fatal herausstellen sollte.

Zwischen 1985 und 1987 kam es nämlich zu mindestens sechs dokumentierten Strahlenunfällen. Mehrere Patientinnen und Patienten erhielten extrem hohe Dosen, einige starben an den Folgen. Die Ursachenanalyse deckte damals eine Kombination aus Design- und Prozessfehlern auf:

1. Race Conditions in der Steuerungssoftware: Wenn Anwenderinnen oder Anwender sehr schnell Eingaben tätigten, konnte die Maschine einen internen Statuswechsel doppelt interpretieren. Sie glaubte, der Schutzmechanismus sei aktiv, obwohl er es nicht war.
2. Verlass auf Software-Interlocks: Früher sorgten physische Sicherungen dafür, dass Hochleistungsstrahlung nur bei korrekter Konfiguration ausgelöst wurde. Beim Therac-25 vertraute man darauf, dass die Software dies fehlerfrei prüft.
3. Fehlende formale Spezifikationen und unabhängige Reviews: Weder gab es einen formalen Sicherheitsnachweis, noch waren die Testprozesse robust genug, um die Race Conditions unter realistischen Bedingungen zu entdecken. Die Software wurde von einem einzelnen Entwickler geschrieben, der auch gleichzeitig der einzige Tester war.

Das Therac-25-Desaster zeigt ein Muster, das sich in vielen sicherheitskritischen Vorfällen wiederholt:

• Technische Schulden durch Verlagerung auf Software: Hersteller ersetzen Hardware-Interlocks aus Kosten- oder Komfortgründen durch Softwarelogik – oft ohne gleichwertige Absicherung.
• Mangelndes Verständnis von Nebenläufigkeit und Timing: Sicherheitskritische Systeme müssen deterministisch arbeiten. Unerwartete Race Conditions sind hier besonders gefährlich.
• Fehlende unabhängige Prüfung: Wenn die Entwicklerinnen und Entwickler auch die Tester sind, bleiben viele Annahmen unentdeckt. Safety Engineering verlangt Redundanz in der Prüfung, nicht nur in der Hardware.

Gegenmaßnahmen sind auch in diesem Fall wieder verhältnismäßig einfach zu ergreifen:

1. Defensive Architektur: Safety-kritische Zustände dürfen nicht von einem einzigen Signal oder Prozess abhängen. Hardware- und Software-Interlocks sollten sich ergänzen.
2. Formale Spezifikationen und Verifikation: Wichtige Abläufe sollten mathematisch modelliert und verifiziert werden.
3. Kompromisslose Post Mortems: Jede Abweichung ist zu dokumentieren und zu analysieren, mit konkreten Änderungen im Design.
4. Lückenlose Telemetrie und Logging: Safety-Systeme müssen jederzeit nachvollziehbar machen, warum sie eine Aktion ausgeführt oder blockiert haben.
5. Unabhängige Audits und Zertifizierungen: Branchen wie Medizintechnik (IEC 62304), Luftfahrt (DO-178C) und Automobil (ISO 26262) schreiben genau das vor – und das aus gutem Grund.

Safety-kritische Fehler entstehen selten durch schlampige Entwicklerinnen oder Entwickler. Häufiger liegt die Ursache in organisatorischem Druck: Termine, Kosten oder das Vertrauen darauf, dass „die Software es schon regelt“. Das Problem ist, dass Softwarefehler leise eskalieren, bis sie plötzlich sichtbar und irreversibel werden.

Der Therac-25 ist heute ein Lehrbuchbeispiel dafür, dass man bei sicherheitskritischen Systemen niemals auf formale Sicherheitsmechanismen verzichten darf. Jede vermeintliche Abkürzung in Richtung „rein softwarebasiert“ kann hier Menschenleben kosten.

(who)