Die 10 größten Computer-Pannen der Geschichte

Wenn Computer versagen, ist das selten nur „ein Bug“ – oft hängt plötzlich Infrastruktur, Geld oder sogar Sicherheit daran. In dieser Top-10 geht es um die größten Computer-Pannen der Geschichte, also Vorfälle, bei denen Software, Daten oder IT-Prozesse spektakulär danebenlagen. Sortiert ist die Liste nach einem transparenten Schadens-Score (0–100): Er kombiniert finanzielle Größen (z. B. dokumentierte Kosten/Obligationen), Reichweite (betroffene Menschen/Transaktionen/Anrufe) und Sicherheitsfolgen (z. B. Verletzungen/Todesfälle) – je höher der Score, desto gravierender die Gesamtauswirkung.

Übersicht

1. 2003: Nordamerika-Blackout (Alarmsoftware & Kaskade)
2. 2013: Healthcare.gov (Start mit massiven IT-Problemen)
3. 2012: Knight Capital (Algorithmus-Fehlstart)
4. 1994: Pentium-FDIV-Bug (Intel-Chip-Rücktausch)
5. 1994: Denver Airport Gepäcksystem (Automatisierung floppt)
6. 1999: Mars Climate Orbiter (Einheitenfehler)
7. 1996: Ariane 5 Flug 501 (Integer-Overflow)
8. 1985: Bank of New York (Software-Glitch & Notkredit)
9. 1990: AT&T-Netzausfall (Switch-Software-Fehler)
10. 1985–1987: Therac-25 (Software in Medizintechnik)

2003: Nordamerika-Blackout – wenn Alarmsoftware und Netzbetrieb kollabieren

Rang: 1

Der Blackout vom 14. August 2003 ist ein Lehrstück dafür, wie moderne Gesellschaften an digitalen Kettenreaktionen hängen. In Teilen der USA und Kanadas brach die Stromversorgung großflächig zusammen – mit Folgen, die weit über „Licht aus“ hinausgehen: Verkehrssysteme, Industrieprozesse, Kühlung, Kommunikationsnetze und Zahlungsverkehr geraten in Stress, sobald Energie wegfällt. Besonders bitter: Ein großer Blackout wirkt selten wie ein einzelner Defekt. Er entsteht meist, weil mehrere kleine Probleme sich ungünstig überlagern und Entscheidungen unter Zeitdruck getroffen werden müssen. In der öffentlichen Wahrnehmung bleibt oft „ein Fehler“ hängen, tatsächlich ist das Muster typischer: Ausfälle in Alarmierung oder Monitoring nehmen Operatoren die Situationsübersicht, während gleichzeitig reale Netzprobleme eskalieren. Wenn dann Schutzmechanismen auslösen und Lastflüsse umverteilt werden, kann aus lokalen Störungen eine Kaskade werden. Genau deshalb zählt dieser Vorfall zu den größten Computer-Pannen: Nicht, weil Software „den Strom abschaltet“, sondern weil digitale Systeme die Wahrnehmung, Koordination und Stabilisierung des Gesamtsystems beeinflussen. Und wenn die Informationslage bricht, wird jede richtige Entscheidung schwerer. Besonders aussagekräftig ist die dokumentierte wirtschaftliche Größenordnung – Schätzungen im Milliardenbereich machen klar, dass ein einziger Tag Systemversagen volkswirtschaftlich messbar ist. Der Blackout ist damit ein Paradebeispiel für ein modernes Risiko: Nicht nur Hardware fällt aus, sondern die Fähigkeit, komplexe Infrastruktur in Echtzeit zu verstehen und zu steuern, hängt an Softwareketten, Datenqualität und robusten Prozessen.

• Großflächige Kaskadeneffekte in kritischer Infrastruktur
• Fehlerhafte/fehlende Alarmierung verschärft operative Entscheidungen
• Volkswirtschaftlicher Schaden in Milliardenhöhe dokumentiert

Schadens-Score

95/100

Dokumentierter Schaden

Schätzung 7–10 Mrd. US$

Quelle

U.S. Nuclear Regulatory Commission (PDF)

Zurück zur Übersicht

---

2013: Healthcare.gov – Milliardenprojekt, das am Starttag stolpert

Rang: 2

Man kann ein System technisch korrekt entwickeln – und trotzdem beim Go-Live spektakulär scheitern. Healthcare.gov wurde 2013 zum Symbol dafür, wie riskant große IT-Vorhaben werden, wenn viele Anbieter, Module und Termine zusammenkommen. Zum Start der Einschreibung traten für Nutzerinnen und Nutzer teils massive Probleme auf: Fehlermeldungen, Abbrüche, lange Antwortzeiten – kurz: genau die Arten von Ausfällen, die Vertrauen zerstören, weil sie den ersten Eindruck prägen. Was die Panne so groß macht, ist nicht nur die öffentliche Sichtbarkeit, sondern die dokumentierte Größenordnung an Verpflichtungen/Kosten, die im Raum standen, während das System dennoch nicht stabil genug für Spitzenlasten war. Bei solchen Projekten passiert das Scheitern selten wegen „einer Zeile Code“. Typisch sind Integration und End-to-End-Tests: Wenn viele Komponenten zusammenlaufen (Identitätsprüfung, Datendrehscheibe, Tarife, Zahlungen, Schnittstellen), reicht ein einziger Engpass, um alles zu verstopfen. Dazu kommt Governance: Wer entscheidet, ob man live geht? Wer stoppt, wenn Qualität nicht stimmt? Und wie reagiert man, wenn Live-Traffic echte Systemgrenzen offenlegt? Gerade deshalb ist Healthcare.gov eine Computer-Panne im historischen Sinn: Sie zeigt, dass Software nicht nur gebaut, sondern operativ geführt werden muss – mit realistischen Lastannahmen, klaren Verantwortlichkeiten und testbaren Qualitätskriterien. Der dokumentierte Umfang der Obligationen zeigt zudem, wie teuer „Nachbessern unter Öffentlichkeit“ ist. Als Fallstudie ist Healthcare.gov bis heute relevant, weil fast jede Behörde und jedes Großunternehmen ähnliche Muster kennt – nur meistens ohne Scheinwerferlicht.

• Go-Live-Probleme durch Integration, Last und Qualitätssteuerung
• Hohe dokumentierte Obligations-/Kosten-Größenordnung
• Lehrstück für Governance, End-to-End-Tests und Betriebsreife

Schadens-Score

90/100

Dokumentierter Betrag

840 Mio. US$ obligiert (Stand März 2014)

Quelle

U.S. Government Accountability Office (GAO) (PDF)

Zurück zur Übersicht

---

2012: Knight Capital – eine Stunde, die ein Unternehmen fast zerstört

Rang: 3

Im Hochfrequenzhandel sind Sekunden teuer – und genau deshalb sind Fehlkonfigurationen dort so gefährlich. Am 1. August 2012 erlebte Knight Capital eine der bekanntesten „Software-killt-Firma“-Geschichten: Ein automatisiertes Routing-/Handelssystem erzeugte in kurzer Zeit massenhaft fehlerhafte Orders und Positionen. Der Vorfall ist so spektakulär, weil er zeigt, wie schnell aus einem technischen Detail ein existenzielles Risiko wird: Software führt nicht nur Anweisungen aus, sie kann in modernen Märkten selbst zum Marktakteur werden. Sobald ein System falsch parametriert, unvollständig ausgerollt oder inkonsistent getestet ist, kann es sich mit hoher Geschwindigkeit „selbst verstärken“ – besonders wenn Kontrollmechanismen (Kill Switches, Limits, Rollback-Prozesse) nicht in der nötigen Strenge greifen. Im Ergebnis entstanden Verluste in einer Größenordnung, die ein etabliertes Unternehmen in kürzester Zeit ins Wanken bringt. Historisch ist der Fall deshalb wichtig, weil er einen kulturellen Shift markiert: Technik- und Compliance-Fragen wurden im Handel noch stärker miteinander verknüpft. Die Lehre lautet: In ultra-schnellen Systemen sind Software-Engineering-Prozesse (Release-Management, Feature-Flags, Testing, Zugriffskontrollen, Observability) nicht nur „Best Practice“, sondern Überlebensbedingung. Der Vorfall ist auch deshalb eine ikonische Computer-Panne, weil er nicht vom „bösen Hacker“ handelt, sondern von einem internen Fehlerpfad – etwas, das jede Organisation trifft, wenn Prozesse nicht robust genug sind. Genau diese Art Panne ist die gefährlichste: Sie kommt ohne Warnung, ist rein selbstgemacht und läuft schneller ab, als Menschen sinnvoll eingreifen können.

• Automatisierung verstärkte den Fehler innerhalb von Minuten
• Fehlkonfiguration/Deployment-Probleme als Kernmuster
• Lehrfall für Limits, Kill Switches, Release-Engineering und Kontrollen

Schadens-Score

90/100

Dokumentierter Verlust

ca. 460 Mio. US$

Quelle

U.S. Securities and Exchange Commission (PDF)

Zurück zur Übersicht

---

1994: Pentium-FDIV-Bug – wenn ein Rechenfehler zum PR- und Kostendesaster wird

Rang: 4

Der Pentium-FDIV-Bug ist der Klassiker dafür, wie eine scheinbar „kleine“ Tabelle in einem Chip riesige Folgen haben kann. Der Fehler saß nicht in einer App, sondern in der Hardware-Implementierung der Gleitkommadivision (FPU): Bestimmte Divisionen lieferten leicht falsche Ergebnisse. Für viele Nutzerinnen und Nutzer war das zunächst abstrakt – wer teilt schon Milliarden zufälliger Zahlen? Aber genau das war der Punkt: Computer werden gerade dann kritisch, wenn sie für Wissenschaft, Finanzen, Engineering oder Simulationen genutzt werden. Dort kann ein seltener Fehler bedeuten, dass ein Modell falsche Schlüsse zieht, ein Ergebnis nicht reproduzierbar ist oder Vertrauen in Berechnungen sinkt. Zusätzlich eskalierte der Vorfall, weil Kommunikation und Erwartungsmanagement nicht perfekt liefen: Wenn ein Hersteller zunächst austauschwillig nur unter Bedingungen ist, wirkt das auf Kundschaft wie „Wir entscheiden, ob dein Problem real ist“. Am Ende wurde der Rücktausch breiter – und teuer. Der besondere historische Impact liegt in zwei Dingen. Erstens: Er machte „Rechenkorrektheit“ als öffentliches Thema sichtbar. Zweitens: Er war ein frühes Lehrstück, dass Qualitätssicherung, Offenheit und schnelle, kundenorientierte Reaktion bei Tech-Hardware entscheidend sind. Der dokumentierte finanzielle Einschlag (Charge für Ersatz und Abschreibungen) zeigt, dass Vertrauensverlust in Technologie unmittelbar in Kosten übersetzt werden kann. Der Pentium-FDIV-Bug ist daher nicht nur eine Anekdote, sondern eine Panne mit langfristigem Effekt auf Qualitätsprozesse, Kommunikation und die Erwartung, dass Hersteller auch seltene, aber reale Fehler ernst nehmen müssen.

• FPU-Lookup-Tabellenfehler führte zu falschen Divisionsergebnissen
• Öffentlicher Druck machte Korrektheit/Transparenz zu einem Kernwert
• Dokumentierter großer finanzieller Aufwand für Ersatz/Abschreibungen

Schadens-Score

85/100

Dokumentierter Betrag

475 Mio. US$ pre-tax charge

Quelle

Intel – 1994 Annual Report (PDF)

Zurück zur Übersicht

---

1994: Denver Airport – das Gepäcksystem, das die Realität unterschätzte

Rang: 5

Die Gepäckanlage des Denver International Airport ist eine der berühmtesten IT-/Automationspannen, weil sie zeigt, wie gnadenlos physische Welt und Software zusammenstoßen. Die Vision war verlockend: ein hochautomatisiertes System, das Gepäck schnell, zuverlässig und effizient über kilometerlange Strecken transportiert. Doch in der Praxis bedeutet so etwas: Sensorik, Weichen, Motoren, Mechanik, Taktung, Fehlertoleranz, Redundanz – und vor allem Integration unter Zeitdruck. Wenn in einem reinen Softwareprojekt etwas schiefgeht, kann man oft „patchen“. In einem cyber-physischen System ist jeder Bug plötzlich eine mechanische Kollision, ein Stau, ein Riemen, der reißt, oder ein Knoten, der sich nicht mehr entwirren lässt. Genau das machte Denver so teuer und so sichtbar: Die Komplexität wurde unterschätzt, die Abhängigkeiten waren hoch, und die Inbetriebnahme wurde zum Kampf gegen reale Kaskaden aus kleinen Fehlern. Der entscheidende Punkt ist nicht, ob Automatisierung grundsätzlich schlecht wäre – im Gegenteil. Das Problem ist das Management von Komplexität: klare Scope-Grenzen, realistische Tests, schrittweise Rollouts, robuste Fallbacks und eine Architektur, die Ausfälle einkalkuliert. Der Fall ist bis heute ein Standardbeispiel im Projektmanagement, weil er zeigt, wie schnell ein „Alles-auf-einmal“-Ansatz kollabiert, wenn die Umgebung nicht perfekt kontrollierbar ist. Auch wenn ein Flughafenprojekt viele Kostentreiber hat, bleibt die Gepäckanlage ein Symbol: Wer in die physische Welt digital eingreift, muss die Realität als härtesten Reviewer akzeptieren. Und genau das ist die Lektion dieser Computer-Panne.

• Cyber-physisches System: Softwarefehler werden zu mechanischen Problemen
• Komplexität und Integration als Haupttreiber des Scheiterns
• Lehrbeispiel für stufenweise Inbetriebnahme und Fallback-Design

Schadens-Score

80/100

Dokumentierter Umfang

Gepäcksystem-Kostenstand ca. 300 Mio. US$ (bis dahin)

Quelle

GAO – Denver International Airport (PDF)

Zurück zur Übersicht

---

1999: Mars Climate Orbiter – ein Einheitenfehler, der eine Mission kostet

Rang: 6

Der Verlust des Mars Climate Orbiter ist eine der berühmtesten Pannen, weil sie so „menschlich“ wirkt: Einheiten passen nicht zusammen – und plötzlich ist ein Raumfahrzeug weg. Der Kern: In komplexen Projekten sind Schnittstellen gefährlicher als einzelne Komponenten. Wenn ein Team Werte in imperialen Einheiten liefert (z. B. pounds-force), ein anderes Team aber metrische Einheiten erwartet (Newton), können Zahlen formal korrekt aussehen und dennoch physikalisch falsch sein. Genau das ist das Perfide: Es ist kein Crash beim Kompilieren, kein offensichtlicher Alarm. Es ist ein schleichender Systemfehler, der sich erst bemerkbar macht, wenn das System im realen Betrieb „physisch“ reagiert – hier: bei der Flugbahnberechnung und dem Eintritt in eine zu niedrige Marsatmosphäre. Der Vorfall zeigt, warum Technik-Organisationen so besessen von Standards, Verification, unabhängigen Checks und klaren Datenverträgen sein müssen. Einheiten sind nicht „Detail“, sondern Semantik – und Semantikfehler sind die schlimmsten, weil sie nicht wie Tippfehler aussehen. Historisch ist Mars Climate Orbiter deshalb so wichtig, weil die Lektion universell ist: Schnittstellen brauchen klare Spezifikationen, maschinenprüfbare Validierung und Kultur, die „lästige“ Plausibilitätschecks belohnt. In der Softwarewelt nennt man das heute gern Contract Testing, Schema Validation oder strong typing – in der Raumfahrt ist es überlebenswichtig. Dass ein einzelner Missmatch so teuer enden kann, macht diesen Fall zu einer Top-10-Panne: Er ist spektakulär, aber zugleich erschreckend realistisch.

• Semantikfehler: Zahlen „stimmen“, aber Einheiten passen nicht
• Schnittstellen und unabhängige Prüfungen sind entscheidend
• Ikonisches Beispiel für Datenverträge, Standards und Validierung

Schadens-Score

80/100

Dokumentierter Kontext

Mishap Investigation Board Report (Missionverlust)

Quelle

NASA – Mishap Investigation Board (PDF)

Zurück zur Übersicht

---

1996: Ariane 5 Flug 501 – ein Overflow, der eine Rakete zerstört

Rang: 7

Der Ariane-5-Fehlstart (Flug 501) ist ein Paradebeispiel dafür, wie gefährlich „Code-Wiederverwendung ohne Kontext“ sein kann. Ein Teil der Software stammte aus Ariane 4 und war in seinem ursprünglichen Einsatz sinnvoll – aber die Randbedingungen hatten sich geändert: andere Flugprofile, andere Dynamik, andere Wertebereiche. In den ersten Sekunden nach dem Start kam es zu einer Datentyp-Konvertierung, die einen Überlauf auslöste. Der Fehler wurde nicht sauber abgefangen, und das System reagierte auf die Ausnahme in einer Weise, die die Steuerung praktisch lahmlegte. Was diese Panne so berühmt macht, ist die brutale Einfachheit: Ein Integer-Overflow klingt nach Anfängerfehler, aber hier zerstörte er ein High-Tech-System in Sekunden. Der eigentliche Lerneffekt ist tiefer: Safety-Kritikalität entsteht nicht nur aus Hardware, sondern aus Annahmen. Wenn eine Variable „normalerweise“ nie einen bestimmten Bereich überschreitet, ist das keine Garantie – erst recht nicht, wenn man die Plattform wechselt. Ariane 5 zeigt deshalb, warum robuste Schutzmaßnahmen, explizite Range-Checks, defensive Programmierung und vor allem systematische Hazard-Analysen wichtig sind. Es geht nicht darum, jeden Fehler zu verhindern – das ist unrealistisch – sondern darum, Fehler so zu behandeln, dass sie nicht katastrophal eskalieren. In der Praxis heißt das: Ausnahmen dürfen nicht den Zustand zerstören, und Redundanz darf nicht identisch fehlschlagen. Genau solche Prinzipien haben die Ingenieurkultur in sicherheitskritischen Systemen geprägt. Ariane 5 ist deshalb eine der größten Computer-Pannen: Sie ist spektakulär sichtbar, technisch lehrreich und in ihrer Grundlogik (falsche Annahmen + unzureichendes Fehlerhandling) erschreckend universell.

• Datentyp-Konvertierung mit Überlauf löste Kettenreaktion aus
• Wiederverwendeter Code passte nicht zu neuen Randbedingungen
• Lehrfall für Range-Checks, defensive Programmierung und Fehlerhandling

Schadens-Score

75/100

Schlüsselthema

Overflow + unpassendes Exception-Handling in sicherheitskritischer Software

Quelle

European Space Agency (ESA) – Inquiry Board Report (PDF)

Zurück zur Übersicht

---

1985: Bank of New York – wenn ein Softwarefehler Liquidität frisst

Rang: 8

Bei Banken denkt man bei „Computer-Panne“ oft an Onlinebanking-Ausfälle. Der Bank-of-New-York-Vorfall von 1985 zeigt jedoch eine andere Dimension: den Kernbetrieb von Finanzmärkten. Ein Softwareausfall führte dazu, dass die Bank als Intermediär im Wertpapiergeschäft bestimmte Abwicklungen nicht rechtzeitig abschließen konnte. In solchen Systemen zählt nicht nur „ob“ etwas passiert, sondern „wann“ – denn verspätete Lieferung oder Weitergabe erzeugt Kettenreaktionen: Gegenparteien warten, Sicherheiten werden gebunden, Liquiditätsbedarf steigt, und plötzlich wird ein operatives Problem zu einem systemischen Risiko. Besonders eindrucksvoll ist der dokumentierte Notkredit der New Yorker Fed in zweistelliger Milliardenhöhe. Das heißt nicht, dass dies „Kosten“ im Sinne eines endgültigen Verlustes waren – aber es zeigt die Größenordnung der Stresssituation, die ein Softwareglitch auslösen kann. Genau darum ist dieser Fall eine große Computer-Panne: Er verdeutlicht, dass IT in kritischen Prozessen nicht nur Effizienz, sondern Stabilität bedeutet. Und Stabilität ist ein ökonomischer Wert. Der Vorfall ist zudem zeitlos, weil er das Muster des „Hidden Plumbing“ offenlegt: Die Öffentlichkeit sieht Börsenkurse, aber das System hängt an Abwicklung, Messaging, Settlement und fehlerarmen Backoffice-Prozessen. Wenn dort etwas ausfällt, kann die Zentralbank plötzlich als Feuerwehr auftreten. Als Fallstudie ist Bank of New York deshalb eine Erinnerung: In hochvernetzten Systemen kann ein Softwarefehler nicht nur Nutzer nerven, sondern Liquidität binden, Vertrauen beschädigen und das System in einen Ausnahmezustand zwingen. Das macht ihn historisch so relevant – und zu Recht ein Top-10-Eintrag.

• Softwareausfall traf die Wertpapierabwicklung (Settlement/Delivery)
• Dokumentierte außergewöhnliche Liquiditätshilfe zeigt Stressgröße
• Lehrfall für Resilienz in „unsichtbarer“ Finanzinfrastruktur

Schadens-Score

70/100

Dokumentierter Betrag

22,6 Mrd. US$ discount window lending (Liquidität)

Quelle

Federal Reserve Bank of Richmond (PDF)

Zurück zur Übersicht

---

1990: AT&T-Netzausfall – ein Bug, der sich durchs Netz vervielfältigt

Rang: 9

Der AT&T-Ausfall im Januar 1990 ist eine der berühmtesten Telekom-Pannen, weil er zeigt, wie gefährlich „selbstverstärkende“ Fehler in verteilten Systemen sind. Ausgangspunkt war eine Störung in der Software eines Switches. In einem Telefonnetz sind Switches hochgradig kooperativ: Sie signalisieren sich gegenseitig Zustände, routen Anrufe weiter und reagieren auf Ausfälle automatisch. Genau hier liegt der Haken: Wenn ein Knoten unerwartet neu startet oder in einen Fehlerzustand fällt, reagieren andere Knoten – und zwar nach Regeln, die normalerweise Stabilität bringen sollen. Unter ungünstigen Bedingungen kann daraus aber eine Rückkopplung entstehen: Ein Switch fällt aus, Nachbarn melden/versuchen umzurouten, Signalisierung lastet die anderen Systeme aus, weitere Knoten geraten ins Straucheln, und der Fehler „wandert“ durchs Netz. Das ist das Gegenteil eines isolierten Bugs – es ist ein Systemfehler, der durch Architektur und Interaktion entsteht. Berühmt wurde der Fall auch, weil er die Bedeutung von Tests in verteilten Umgebungen zeigte: Ein Softwarefehler kann in der Laborumgebung harmlos wirken, aber im Netzverbund eskaliert er durch Timing, Last und Wiederholungsmechanismen. Für die Öffentlichkeit war die Wirkung simpel: viele Millionen blockierte Verbindungsversuche. Für Ingenieure war es eine frühe, sehr laute Warnung: Verteilte Systeme brauchen nicht nur Korrektheit, sondern Stabilitätsbeweise, Rate-Limits, Backoff-Strategien und eine Architektur, die einzelne Knotenfehler nicht global repliziert. AT&T 1990 ist deshalb eine große Computer-Panne, weil sie ein Grundmuster moderner IT vorwegnimmt – genau das, was heute auch Cloud- und Plattformausfälle so gefährlich macht: nicht der erste Fehler, sondern die Kaskade danach.

• Softwarefehler in einem Switch löste netzweite Kaskaden aus
• Verteilte Systeme können Bugs durch Rückkopplung vervielfachen
• Lehrfall für Rate-Limits, Backoff, Isolation und Kaskadenprävention

Schadens-Score

65/100

Dokumentierte Reichweite

Über 50 Mio. blockierte Anrufe (in ~9 Stunden)

Quelle

California Polytechnic State University – Case Study

Zurück zur Übersicht

---

1985–1987: Therac-25 – wenn Software in der Medizintechnik zur Gefahr wird

Rang: 10

Therac-25 steht in dieser Liste, weil „Computer-Panne“ hier nicht Geld oder Service meint, sondern Sicherheit. Das Gerät war eine computergesteuerte Strahlentherapieanlage. In mehreren dokumentierten Fällen kam es zu massiven Überdosierungen – mit schweren Verletzungen und Todesfällen. Technisch ist Therac-25 berüchtigt, weil es eine unheilvolle Mischung aus Softwarefehlern, unzureichenden Schutzmechanismen und problematischen Mensch-Maschine-Schnittstellen war. Dazu gehörten beispielsweise Race Conditions: schnelle Bedienfolgen konnten Zustände erzeugen, die das System falsch interpretierte. Fatal ist dabei, dass in safety-kritischen Systemen nicht nur „Fehlerfreiheit“ zählt, sondern „sichere Fehlertoleranz“: Wenn etwas unklar ist, muss das System in einen sicheren Zustand gehen. Genau das fehlte oder war unzureichend. Ebenso wichtig war die Kommunikation: Warnhinweise, Protokollierung, nachvollziehbare Diagnostik – ohne das werden Operatoren im Ernstfall zu „Fehlersuchern“, während Patientinnen und Patienten im Raum liegen. Therac-25 ist historisch so bedeutend, weil es die Software-Engineering-Kultur in sicherheitskritischen Bereichen geprägt hat. Der Fall machte deutlich, dass Software nicht einfach ein „Bauteil“ ist, sondern ein Systemverhalten steuert, das formal verifiziert, getestet, auditiert und mit Redundanz abgesichert werden muss. Außerdem zeigt Therac-25, dass Pannen nicht immer aus spektakulären Hackerangriffen entstehen, sondern aus alltäglichen Dingen: ungetestete Randfälle, fehlende Sicherheitsarchitektur, schlechte Feedbackkanäle. Deshalb bleibt Therac-25 ein Mahnmal – und ein Grund, warum moderne Medizintechnik strenge Entwicklungs-, Dokumentations- und Meldepflichten kennt. Als „größte Computer-Panne“ zählt es durch die Schwere der Folgen.

• Mehrere Überdosierungsereignisse mit schweren Verletzungen/Todesfällen
• Race Conditions und fehlende Safety-Mechanismen als zentrale Muster
• Prägte Safety-Engineering und Standards für softwaregesteuerte Geräte

Schadens-Score

65/100

Kernrisiko

Softwarefehler in einem sicherheitskritischen, patientennahen System

Quelle

Columbia University – Leveson/Turner (PDF)

Zurück zur Übersicht

---