Der Therac-25-Vorfall (2021)

• Beim medizinischen Strahlungsgerät Therac-25 kam es zu tödlichen Unfällen
• Durch einen Softwarefehler wurden mehrere Patienten einer schweren Überdosis an Strahlung ausgesetzt
• Die Probleme traten auf, nachdem bestehende Sicherheitssysteme durch ein digitales Steuerungssystem ersetzt worden waren
• Wegen mangelhafter Fehlerdiagnose und fehlender Kommunikation verzögerte sich die Aufklärung der Unfallursache
• Als zentrale Lehre für die Sicherheit wird die Bedeutung von Zuverlässigkeit von Algorithmen und gründlichen Tests hervorgehoben

---

Überblick über den Therac-25-Vorfall

• Therac-25 war ein weit verbreitetes medizinisches Bestrahlungsgerät für therapeutische Zwecke
• Das Gerät diente dazu, Krebspatienten mit hochdosierter Strahlung zu behandeln
• Frühere mechanische Interlock-Sicherungen wurden durch ein softwarebasiertes Steuerungssystem ersetzt
• Diese Veränderung erhöhte jedoch das Risiko von Softwarefehlern

Ablauf des Unfalls

• Bei bestimmten Arbeitsschritten oder schnell aufeinanderfolgenden Eingaben trat ein Fehler im Programm auf
• Dadurch funktionierten die Sicherheitseinrichtungen nicht korrekt, sodass Patienten Strahlung in stärkerer als der vorgesehenen Dosis erhielten
• Zwischen 1985 und 1987 kam es bei mehreren Patienten zu schweren Überbestrahlungen, einige starben
• Anfangs wurde die Software als Ursache der Defekte der Strahlungsmaschine häufig übersehen

Ursachen des Problems

• Im Rahmen der Zuverlässigkeitsprüfung wurden nur einfache Tests durchgeführt, die die reale klinische Umgebung nicht abbildeten
• Wegen unzureichender Fehlerbehandlung und mangelhafter Interlock-Verwaltung traten in Extremsituationen Algorithmusfehler auf
• Da es zwischen Hersteller und Krankenhäusern kein klares System zur Meldung von Problemen und zur Kommunikation gab, verzögerten sich Erkennung und Behebung der Fehler
• Der Vorfall gilt als Versagen eines sicherheitsorientierten Softwaredesigns

Zentrale Lehren

• Bei der Entwicklung von Algorithmen, die direkt mit Sicherheit verknüpft sind, sind gründliche Verifikation und defensives Programmieren erforderlich
• Vielfältige Testfälle und Simulationen auf Basis realer Nutzungsszenarien sind unverzichtbar
• Die systematische Umsetzung verschiedener Fehlerbehandlungsroutinen und Log-Systeme wird betont
• In Bereichen mit hohen Anforderungen an die Zuverlässigkeit muss das Risiko einer ausschließlichen Abhängigkeit von Softwaresteuerung erkannt werden
• Der Vorfall ist ein repräsentatives Beispiel dafür, wie wichtig Zuverlässigkeit von Algorithmen, Sicherheitsmanagement und Kommunikationsstrukturen in der weltweiten Softwaretechnik und Medizinprodukteindustrie sind

[GN⁺]

Hacker-News-Meinungen

• Es wird betont, dass Softwarequalität nicht einfach dadurch entsteht, dass man gute Entwickler hat, sondern das Endprodukt eines organisationsweiten Prozesses ist. Dieser Prozess betrifft nicht nur Entwicklungspraktiken, sondern auch Tests, das Management und sogar Vertrieb und Service. Was wir aus dem Therac-25-Fall lernen sollten: Typsysteme, Unit-Tests oder defensives Programmieren allein lösen nicht alle Probleme. Das eigentliche Versagen bestand meiner Meinung nach darin, dass Unfallberichte, Untersuchungen und Korrekturen viel zu lange dauerten. Kürzlich wurde das auch im Podcast Cautionary Tales behandelt; besonders eindrücklich war dabei, dass Nutzer des Therac-25 wiederholt unbekannte Fehler erlebten, diese Informationen aber die zuständigen Personen nicht richtig erreichten. (Podcast-Link)

  • Ich stimme dieser Meinung nicht zu. Ich habe lange Erfahrung in der Konstruktion von Flugzeugteilen, und das zentrale Prinzip lautet: Ein einzelner Fehler darf niemals zu einem Unfall führen. Das erreicht man nicht durch „gute Software“ oder „ausreichende Tests“, sondern durch „ein unabhängiges System, das selbst das schlimmste Fehlverhalten der Software verhindern kann“. Im Fall von Therac-25 wären ein Strahlungsdetektor nötig gewesen, der bei Überschreiten des Sicherheitsgrenzwerts automatisch abschaltet, sowie ein physisches Design, das eine übermäßige Strahlungsabgabe grundsätzlich unmöglich macht.

  • Ich wollte diesen Podcast auch gerade empfehlen. Besonders wenn man sich für Softwarebugs interessiert, ist er hörenswert. Eine interessante Tatsache ist, dass auch frühere manuell betriebene Geräte denselben Defekt hatten, dieser aber nicht wirksam wurde, weil eine Sicherung bei einem Kurzschluss durchbrannte. Das ist ein hervorragendes Beispiel für das Swiss-Cheese-Modell (zum Swiss-Cheese-Modell)

  • Ich möchte hervorheben, dass die meiste Software nicht direkt lebensentscheidend ist. In den meisten Fällen bedeutet ein Fehler nur, dass eine Seite langsam lädt, ein Bericht voller NaN ist oder ein Batch-Job manuell gestartet werden muss. Dass Menschen tatsächlich an Softwarequalitätsproblemen sterben, ist selten, und ich gehe davon aus, dass Entwickler solcher Software sich ihrer Verantwortung sehr wohl bewusst sind.

  • Das Unternehmen, bei dem ich gearbeitet habe, stellte Foto- und Wissenschaftsgeräte von höchster Qualität her. Sie waren sehr teuer, aber die Kunden fanden den Preis gerechtfertigt. Ich habe aus erster Hand erlebt, dass Qualität nicht einfach das Ergebnis eines Prozesses ist, sondern letztlich aus der „Kultur“ entsteht.

  • Viele Entwickler glauben, Qualitätsprobleme gingen sie nichts an, solange sie nicht an hochzuverlässigen Systemen arbeiten, aber das ist völlig falsch. Selbst scheinbar kleine Softwarefehler können enorme Auswirkungen auf das Leben von Menschen oder auf Unternehmen haben. Zum Beispiel können sie wichtige Abläufe blockieren, Lebens- oder Krankenakten beschädigen oder verhindern, dass dringend benötigte Produkte bezahlt werden.

• Im Kommentar zum Artikel erwähnte jemand, dass es in den 80er- und 90er-Jahren im Gesundheitswesen ein starkes Bewusstsein dafür gab, dass Computer gefährlich sein können. Noch bis in die frühen bis mittleren 2000er wurden Krankenakten von Hand auf Papier geführt. Ich war kurz an einem experimentellen Projekt für elektronische Patientenakten auf einer Intensivstation beteiligt und war dort für den Serverbetrieb zuständig; das gesamte medizinische Personal hasste dieses System. Damals gab es noch nicht einmal Tablets, daher war es umständlich, Einträge am Computer zu prüfen oder zu ändern. Medikamentenverordnungen wurden direkt in die Akte am Bett geschrieben, und man konnte sie sofort einsehen und korrigieren. Informationsverlust oder verzögerter Zugriff konnten fatal sein, also hassten die Ärzte Computer nicht grundlos, sondern weil sie sie tatsächlich als gefährlicher als Stift und Papier empfanden. Ich nehme an, dass sich die Lage inzwischen verbessert hat, aber es bleibt etwas, das man im Hinterkopf behalten sollte.

  • Heute haben Unternehmen wie Chipsoft die Krankenhaus-IT fast monopolisiert. Sie verlangen extrem hohe Preise, während die Softwarequalität katastrophal ist, und je größer die Anbieter werden, desto weniger Alternativen gibt es. Ich verstehe nicht, warum wir solche feindseligen Anbieter zulassen.

  • Noch immer gibt es Fälle, in denen medizinisches Personal wegen Ausfällen von IT-Systemen wieder zu Stift und Papier zurückkehren muss. Ich verstehe nicht, warum diese Systeme keine Redundanz haben. Dass so etwas heute ein kommerzielles Produkt ist, ist erstaunlich.

  • In den USA und in Europa werden EMR-Systeme (elektronische Krankenakten) nicht als Medizinprodukte eingestuft und sind daher von vielen Regulierungen ausgenommen. Link zum Artikel

• Im Vergleich zum britischen Postskandal ist das interessant. Es sind völlig unterschiedliche Fälle, aber gemeinsam ist beiden die falsche Annahme, dass „Software nicht falsch liegen kann“. Aus Entwicklersicht ist das eine absurde Vorstellung, aber für Nichtfachleute ist die Fragilität von Software schwer zu begreifen. Es herrschte eine Kultur, in der man davon ausging, dass Software keine Mängel haben könne, und sie deshalb nicht einmal ordentlich testete.

  • Tatsächlich vertrauen oft selbst Entwickler Software zu sehr. Bei jedem System, das ich entwickelt habe, gehe ich immer davon aus, dass es jederzeit zusammenbrechen kann. Deshalb würde ich niemals in ein selbstfahrendes Auto steigen. Es ist erstaunlich, wie sehr HN-Nutzer es lieben, Betatester neuer Technologien zu sein. Natürlich wird behauptet, dass autonome Fahrzeuge statistisch sicherer seien, aber ein Grund dafür ist auch, dass die anderen Verkehrsteilnehmer vorsichtiger fahren. Außerdem sind autonome Fahrzeuge neue Systeme, bei denen menschliche Aufsicht, direkte Eingriffsmöglichkeiten und strenge Standards nicht in gleichem Maß gelten, und genau das halte ich für problematisch.

  • Bei den meisten traditionellen elektrischen oder mechanischen Maschinen war Verschleiß der Hauptgrund für Ausfälle, und weil Software sich nicht abnutzt, entstand wohl der falsche Glaube, sie sei automatisch zuverlässiger.

  • Ich denke, der Postskandal war deutlich böswilliger. Führungskräfte erhielten Anreize abhängig davon, wie viel Geld sie von Filialleitern eintreiben konnten, und sie logen Gerichte und Minister über die Zuverlässigkeit der Software an. Im Vergleich dazu war Therac-25 eher ein ehrlicher Fehler.

• Ich habe das Gefühl, dass bald ein ähnlicher Vorfall wie bei Therac-25 passieren wird. Zu viele Leute betreiben AI-Agenten im YOLO-Modus, und wenn Modelle wie Claude oder Gemini falsch mit echter Hardware verbunden werden, wird das irgendwann wohl zu einem Unfall führen. Agentenbasierte AI ist im Bereich eingebetteter Systeme noch nicht ausgereift, und wenn ich mir vorstelle, dass AI leichtfertig in Bereichen wie Bestrahlungsgeräten eingesetzt wird, wird mir mulmig.

  • Im britischen Post-Horizon-Skandal begingen mehrere Filialleiter Suizid, und Dutzende Leben wurden zerstört. Ich denke, wir sollten aus dem Therac-25-Fall lernen, dass jede Software wichtig ist. Jede Software birgt das Risiko, jemandem zu schaden, deshalb sollte man immer vorsichtig sein.

  • Auch nicht-agentische AI „tötet“ nach manchen Definitionen bereits Menschen. Kürzlich gab es viel Aufsehen um einen Fall, in dem ein AI-Chatbot zu einem Suizid beitrug, und wenn AI künftig in wichtigen Entscheidungsbereichen wie der Krankenversicherung eingesetzt wird, dürfte es mehr Fälle geben, in denen Menschen „wegen AI“ sterben. AI verursacht bereits heute an vielen Stellen Todesfälle, etwa bei autonomen Fahrzeugen. Selbst scheinbar triviale Fehler wie Excel-Bugs haben gesellschaftliche Auswirkungen auf Zehn- oder Hunderttausende gehabt. Aber auch bei AI wird die Verantwortlichkeit vermutlich oft unklar bleiben und so Ausweichmöglichkeiten wie im Horizon-Fall schaffen. Auch AI-Copilot-Tools wirken auf mich im Embedded-Bereich noch unzureichend.

  • Die 737-MAX-MCAS-Affäre war zwar ein Versagen auf Systemebene, ist aber ein typisches Beispiel für ein großes Softwarequalitätsproblem dieser Art. Ich denke, solche Katastrophen werden sich auch in Zukunft wiederholen.

  • Auch die Abstürze der Boeing 737 MAX sind ein typisches Beispiel dafür, wie schlechte Softwarequalität rund 350 Menschen das Leben kostete (Infos zu MCAS)

  • Als ich mit den neuesten AI-Agenten Embedded-Arbeiten ausprobierte, blieb die Leistung hinter den Erwartungen zurück. Selbst bei einer einfachen CRUD-Web-App sieht man oft, dass LLMs durcheinanderkommen, sobald das Datenmodell komplexer wird und schon zwei oder drei Transformationsstufen auftreten. Zum Beispiel dann, wenn ein Eingabefeld created_at heißt, beim Speichern aber created_on und beim Senden an ein externes System last_modified.

• Die Anekdote, dass beim Therac-25-Gerät durch bestimmte Tasteneingaben an einem VT100-Terminal in Sekundenbruchteilen eine übermäßige Strahlenexposition ausgelöst werden konnte, war besonders eindrücklich. Erfahrene Nutzer konnten die Tasten innerhalb von 8 Sekunden sehr schnell eingeben, und in diesem Fall wurden die Eingaben nicht korrekt übernommen, was zu tödlichen Unfällen führen konnte. Wenn man solche Probleme sieht, wirkt der heutige Trend zu Touchscreens selbst bei industriellen oder automobilen Interfaces beunruhigend.

  • Im UI wird zur Verbesserung der Nutzererfahrung häufig mit sogenannten optimistic updates gearbeitet; dadurch wirkt die Anzeige schnell aktualisiert, während die eigentliche Übernahme erst später synchronisiert wird. Ich hoffe, man ist sich genau bewusst, wo so etwas nicht eingesetzt werden sollte.

  • Im Taschenrechner von iOS 11 gab es einen Fall, bei dem eine schnelle Eingabe von „1+2+3“ nicht korrekt berechnet wurde (passendes HN-Beispiel). Selbst ein scheinbar trivialer Taschenrechner kann also denselben Fehlermodus aufweisen.

• Ich frage mich, ob andere solche Fälle wie Therac-25 oder allgemeiner Sicherheits- und Ethikfälle an der Universität gelernt haben. Ich selbst habe diesen Fall in einer allgemeinen Ingenieurvorlesung zusammen mit der Badewannenkurve und Berechnungsmethoden für redundante Kühlpumpen behandelt und frage mich, ob so etwas heute noch Teil des Curriculums ist.

  • In einem Kurs zu Maschineninterfaces an der Purdue University Anfang der 90er wurde das Konzept der „Hysterese“ besonders betont. Analoge Systeme stoppen nicht wie Computer augenblicklich, sondern können innerhalb ihres Betriebsbereichs sehr unterschiedliches Verhalten zeigen, und das musste man unbedingt berücksichtigen.

  • In Vorlesungen zum Systems Engineering werden ähnliche Themen behandelt. (MIT-Kurslink)

  • Ich habe solche Fälle in einem Informatikstudium auf Hochschulniveau behandelt. Später, als ich in der Medizintechnik arbeitete, kamen sie mir immer wieder in den Sinn.

  • In der Ingenieurethik erinnere ich mich, dass wir tatsächlich nur Tacoma Narrows und Therac-25 behandelt haben. Und selbst das nur in einer einstündigen Vorlesung.

  • Aus Neugier habe ich selbst eine Umfrage erstellt. Mich interessiert, ob andere entsprechende Lehrveranstaltungen erlebt haben. (Umfragelink)

• Frühere Geräte hatten Hardware-Interlocks. Selbst wenn die Software versagte, blieb es dann bei einer Unannehmlichkeit, aber aus übertriebenem Vertrauen in die Stabilität der Software wurden diese Hardware-Interlocks aus Kostengründen entfernt und die Überwachung vollständig der Software überlassen. So führte ein kleines Problem letztlich zu einer tödlichen Katastrophe. Es ist ein typischer Fall von Dissonanzen an ganz unterschiedlichen Stellen.

• Der Verfasser des ersten Artikelkommentars ist Arzt und Informatiker sowie Vorsitzender einer Fachgesellschaft zur Prävention von Kindesmisshandlung (Profil-Link). Doch bei der medizinischen Beurteilung von Kindesmisshandlung gibt es noch immer viele Schwächen durch fehlerhafte Daten und Evidenz sowie zirkuläre explorative Logik. Objektive Wahrheit ist schwer zu finden, und in der Praxis besteht die Tendenz, bereits wenige Befunde als „zweifelsfreie Kindesmisshandlung“ zu werten. In letzter Zeit tauchen Blackbox-AI-Systeme auf, die auf Basis solcher unvollständigen Daten hochpräzise Erkennung versprechen, doch aus falschen Daten kann keine richtige Vorhersage entstehen (garbage in, garbage out). Ich sorge mich, dass ungenaue AI-Diagnosen zu falschen Vorwürfen von Kindesmisshandlung, zerstörten Familien und ungerechten Strafen führen könnten. (weiterer Verweis, klinische Publikation, AI- und Datenprobleme, Studienlink)

• Im Bericht von 1993 wurde die Notwendigkeit einer Qualifikation für Entwickler sicherheitskritischer Software erwähnt. Man könne sich nicht schon nach ein paar Programmierkursen als Entwickler sicherheitskritischer Software bezeichnen, und es wurde vorhergesagt, dass nach weiteren Vorfällen wie Therac-25 eine entsprechende Zertifizierung verpflichtend werden würde. Im Vereinigten Königreich wurde bereits über die Gestaltung eines Pflichtcurriculums diskutiert. Doch 32 Jahre später sieht die Realität ganz anders aus.

  • Ich bin in Kanada seit 15 Jahren als professioneller Softwareingenieur registriert, habe aber keinen praktischen Nutzen daraus gezogen und werde die Zertifizierung wohl bald nicht mehr verlängern. Es gab einmal Diskussionen darüber, die Softwareentwicklung zu einer strukturierteren Ingenieurdisziplin zu machen, aber das scheint inzwischen weitgehend verschwunden zu sein.

  • Sicherheitskritische Software lernt man nicht im Hörsaal, sondern durch lange Praxiserfahrung und Schulung. Es gibt Standards wie Do-178 in der Luftfahrt oder IEC 61508 in der Industrie, aber das tatsächliche Anwendungsniveau hängt von Budget und Zeitplan ab. Wenn jedoch ein Unfall passiert, ist das für die Opfer bedeutungslos, selbst wenn alle Audit-Ergebnisse vorliegen. Alle Regulierungen und Regeln entstehen letztlich erst, nachdem jemand geopfert wurde.

• Die Therac-25-Software wurde vollständig von einem einzigen Entwickler geschrieben, und nachdem er 1986 das Unternehmen verlassen hatte, wurde seine Identität nie öffentlich bekannt. Viele Leser könnten sich vorstellen, dass der Entwickler an dieser Tragödie viel Geld verdiente und in luxuriösem Ruhestand lebt, aber damals waren Entwickler ganz anders als heute schlecht bezahlt und wenig anerkannt. In den 80er-Jahren waren in Technologieunternehmen die Verkäufer die Hauptfiguren, und die Verkaufsprovisionen für Therac-25 überstiegen vermutlich das Jahresgehalt des Entwicklers. Vor allem der Standort von AECL, die Zeit, die staatliche Prägung und der Embedded-Software-Kontext sprechen alle für niedrige Bezahlung. 1986 lag das Gehalt in Kanada bei etwa 30.000 bis 50.000 CAD, was heute ungefähr 78.000 bis 129.000 USD entspräche, und es gab keine Aktienoptionen.