Tödliche Strahlung: Wie der Therac-25 die Welt der Softwareentwicklung für immer veränderte

Von DerSchneider

Es gibt Fehler, die sind lästig. Und es gibt Fehler, die töten. Der Therac-25, ein strahlentherapeutisches Gerät des kanadischen Staatsunternehmens Atomic Energy of Canada Limited (AECL), markiert eine düstere Zäsur in der Technikgeschichte. Zwischen 1985 und 1987 verwandelte sich eine Hightech-Waffe im Kampf gegen Krebs in eine Todesfalle. Mindestens sechs Menschen wurden durch massive Überdosen ionisierender Strahlung verletzt, drei von ihnen starben an den Folgen . Die Ursache war kein Bedienfehler im klassischen Sinne und kein mechanisches Versagen. Es war ein Softwarefehler – einer der ersten, der nachweislich Menschen das Leben kostete und der die bis dahin vorherrschende Naivität im Umgang mit Software in sicherheitskritischen Systemen schonungslos offenlegte.

Das Versprechen der Perfektion: Eine Maschine, zwei Gesichter

Um das Desaster zu verstehen, muss man die Faszination begreifen, die der Therac-25 bei seiner Markteinführung 1983 auslöste. Er war ein Meisterstück der Kompaktheit. Als Linearbeschleuniger vereinte er zwei Behandlungsmethoden in einem Gerät: Zum einen die Elektronentherapie mit relativ niedrigen Energien (5 bis 25 MeV) zur Behandlung oberflächlicher Tumore, etwa der Haut. Zum anderen die hochenergetische Röntgentherapie (Megavolt-Therapie), bei der ein 25-MeV-Elektronenstrahl mit 100-fach höherem Strom auf ein Wolfram-Target geschossen wird, um tief im Körper liegende Tumore zu bekämpfen .

Diese Dualität war innovativ, aber auch riskant. Die physikalischen Anforderungen beider Modi sind fundamental verschieden. Im Röntgenmodus muss ein Ablenkmagnet (Bending Magnet) den Strahl auf das Target lenken; im Elektronenmodus wird der Strahl hingegen weit gefächert, um eine großflächige Behandlung zu ermöglichen. Eine Verwechslung – also der volle, ungefilterte Elektronenstrahl im Röntgenmodus – wäre katastrophal.

AECL ging einen radikalen Schritt. Während die Vorgängermodelle Therac-6 und Therac-20 noch auf elektromechanische Verriegelungen (Interlocks) setzten, die physikalisch verhinderten, dass der Strahl im falschen Modus ausgelöst werden konnte, vertraute der Therac-25 bei diesen sicherheitskritischen Prüfungen erstmals vollständig auf seine Software . Diese Entscheidung, getrieben vom Wunsch nach Designvereinfachung und Kostensenkung, sollte sich als fataler Irrglaube an die Allmacht des Codes erweisen.

Die Chronologie eines Grauens: Wenn der Körper schreit

Die erste bekannte Tragödie ereignete sich am 3. Juni 1985 in der Kennestone Regional Oncology Clinic in Marietta, Georgia. Die 61-jährige Brustkrebspatientin Katie Yarborough lag unter dem Therac-25. Nach der Bestrahlung spürte sie einen heftigen Schlag, eine „Hitze, die wie nie zuvor“ in ihren Körper fuhr. Sie schrie, wollte aufspringen. Die Bedienerin, die den Vorfall über die Gegensprechanlage mitbekam, beruhigte sie: „Nur ein kleines Problem mit der Mechanik, nichts Schlimmes“ .

Es war etwas Schlimmes. Yarborough erlitt schwere Strahlenverbrennungen an der Brust und am Arm. Der Arm sollte für immer gelähmt bleiben, die betroffene Brust musste später amputiert werden. Sie hatte eine Strahlendosis erhalten, die um ein Vielfaches über der verordneten lag .

Es folgten weitere Vorfälle: Im Juli 1985 im Ontario Cancer Institute in Kanada, im Dezember 1985 im Yakima Valley Memorial Hospital in Washington. Im März und April 1986 dann die beiden Todesfälle im East Texas Cancer Center in Tyler. Der 33-jährige Ray Cox wurde am 21. März 1986 bestrahlt. Als der Schmerz ihn durchfuhr, versuchte er, sich vom Behandlungstisch zu reißen. Er verstarb Wochen später unter qualvollen Umständen. Sein Mitpatient, der 66-jährige Verdon Kidd, erlitt das gleiche Schicksal nur wenige Wochen darauf . Im Januar 1987 starb in Yakima ein weiterer Patient. Die Tabelle der Opfer liest sich wie ein düsterer Logbucheintrag eines Serienkillers .

Das unsichtbare Gift: Der Tanz der Bit-Fehler

Die Untersuchungen förderten ein erschreckendes Bild zutage. Der Fehler lag nicht auf der Hand. Er trat nur unter bestimmten, seltenen Bedingungen auf – einem perfekten Sturm aus menschlichem Verhalten und maschineller Logik. Die Software des Therac-25, geschrieben in Assembler für einen PDP-11-Computer, litt unter mehreren schwerwiegenden Konstruktionsfehlern.

Der Hauptschuldige war eine sogenannte „Race Condition“. Trat sie auf, übersprang die Software eine entscheidende Sicherheitsprüfung für die Position des Ausbrechers (der den Strahl im Elektronenmodus aufweitet) und des Targets . Das Szenario: Ein erfahrener Bediener gab die Behandlungsparameter ein. Dabei konnte es vorkommen, dass er versehentlich zuerst den Röntgenmodus (X) anwählte, dies bemerkte und innerhalb von acht Sekunden auf Elektronenmodus (E) korrigierte. Genau in diesem Fenster, in dem das System die Änderung der physikalischen Komponenten (wie das Einschwenken des Targets) verarbeitete, konnte die Dateneingabe des Bedieners die Software verwirren. Die Folge: Das System ging fälschlicherweise davon aus, dass der Röntgenmodus mit seinem niedrigen Strom aktiv sei, schaltete aber tatsächlich den Elektronenmodus – also den 100-fach höheren Strom – frei, während sich das strahlabschwächende Target noch außerhalb des Strahlengangs befand .

Ein weiteres Symptom des Software-Versagens war die unsägliche Fehlerbehandlung. Trat ein Problem auf, spuckte das System eine kryptische Meldung aus: „MALFUNCTION“ gefolgt von einer Zahl zwischen 1 und 64. Das Benutzerhandbuch erklärte diese Codes nicht einmal. Die Bediener lernten, dass ein Druck auf die „P“-Taste (für „Proceed“) den Fehler oft zurücksetzte und die Behandlung fortgesetzt werden konnte. Im Falle des tödlichen Fehlers (oft „Malfunction 54“) schien dies ebenfalls zu funktionieren – nur mit dem Unterschied, dass die Maschine nun mit voller Kraft weiterstrahlte .

Systemisches Versagen: Die Wurzeln des Desasters

Die Therac-25-Katastrophe war kein Unglück, das auf einen einzelnen Programmierfehler zurückging. Sie war das Ergebnis einer ganzen Kette von systemischen Fehlern in der Unternehmenskultur und der Ingenieurspraxis der 1980er Jahre.

Erstens: Der fatale Vertrauensvorschuss. AECL entfernte die bewährten Hardware-Interlocks, weil sie teuer und wartungsintensiv waren, und übertrug ihre Sicherheitsfunktion eins zu eins auf die Software. Dies geschah, ohne zu verstehen, dass Software grundsätzlich anderen Versagensmustern unterliegt als Mechanik. Ein Riegel fällt entweder oder er fällt nicht. Software kann in unendlich vielen, nicht vorhersehbaren Zuständen versagen .

Zweitens: Die Sünden der Wiederverwendung. AECL rühmte sich, bewährten Code aus den Vorgängermodellen Therac-6 und Therac-20 wiederzuverwenden. Man ging davon aus, dass Code, der in diesen Geräten jahrelang fehlerfrei lief, auch sicher sei. Was man übersah: Die alten Geräte hatten noch die Hardware-Interlocks. Die Softwarefehler existierten dort bereits, blieben aber folgenlos, weil die Mechanik sie abfing. Im Therac-25, wo diese Schutzmechanismen fehlten, wurden die jahrelang schlummernden Bugs mit einem Mal tödlich .

Drittens: Mangelnde Tests und Arroganz. Die Software wurde nie umfassenden Tests unterzogen. Unit-Tests, Integrationstests – Fehlanzeige. AECL verließ sich auf vage Systemtests vor Ort. Als die ersten Beschwerden aus Marietta und Ontario kamen, reagierte das Unternehmen mit Unglauben und Arroganz. Man schob die Schuld auf die Bediener („Zu schnelle Eingaben“, „Bedienfehler“) und weigerte sich beharrlich, einen Systemfehler einzuräumen . Erst als die US-amerikanische Gesundheitsbehörde FDA (Food and Drug Administration) 1986 eingriff und die Stilllegung aller Geräte anordnete, lenkte AECL ein .

Das Erbe des Schreckens: Die Geburt der Software-Sicherheit

Der Therac-25 wurde zu einem watershed moment – einem Wendepunkt – für die Softwaretechnik und die Medizingeräteindustrie. Die Untersuchungen, insbesondere die akribische Arbeit der Informatikerin Nancy Leveson, die den Fall bis ins kleinste Detail sezierte, wurden zur Pflichtlektüre für ganze Generationen von Ingenieuren .

Die Lehren waren schmerzhaft, aber notwendig:

• Software ist anders: Man kann Sicherheit nicht einfach von der Hardware auf die Software übertragen. Software-Sicherheit muss von Grund auf neu gedacht, spezifiziert, entworfen und verifiziert werden.
• Redundanz und Diversität: In sicherheitskritischen Systemen müssen unabhängige, diversitäre Sicherheitsmechanismen existieren. Eine Softwarelösung darf die einzige Sicherheitsbarriere sein, aber sie muss dann selbst durch unabhängige Software- oder Hardware-Einheiten mehrfach abgesichert sein.
• Testen ist nicht genug: Die Komplexität von Software ist so hoch, dass Testen allein niemals alle Fehler finden kann. Es braucht formale Methoden, gründliche Code-Reviews und eine klare Spezifikation.
• Unternehmenskultur und Fehlerkultur: Die Arroganz und Ignoranz von AECL gegenüber den ersten Opfern zeigt, wie wichtig eine offene Fehlerkultur ist. Jeder Unfallbericht muss ernst genommen werden.

Die Konsequenz war die Verschärfung von Regulierungsstandards. In den USA verschärfte die FDA ihre Anforderungen an die Zulassung von Medizinprodukt-Software drastisch. Weltweit wurden neue Normen erarbeitet, wie die IEC 62304, die bis heute den Lebenszyklus von Medizinprodukte-Software definiert und strenge Auflagen für die Dokumentation, das Risikomanagement und die Validierung von Software festschreibt .

Der Therac-25 ist heute mehr als nur eine Fußnote in einem Geschichtsbuch. Er ist das ultimative Menetekel für das Zeitalter der Digitalisierung. In einer Welt, in der Software immer häufiger über Leben und Tod entscheidet – im autonomen Fahrzeug, in der Energieversorgung, in der Medizintechnik – müssen wir uns täglich an die Lektion von Marietta und Tyler erinnern: Code ist kein Gesetz, das die Natur befolgt. Code ist ein fragiles Menschenwerk, das unser tiefstes Misstrauen und unsere höchste Sorgfalt verdient. Die Opfer des Therac-25 starben nicht an Krebs, sondern an unserem blinden Vertrauen in die Perfektion der Maschine.