No todos los bugs acaban en un mensaje de error. Entre junio de 1985 y enero de 1987, un acelerador de radioterapia llamado Therac-25 administró sobredosis masivas a pacientes en Estados Unidos y Canadá. Varias personas murieron; otras quedaron con lesiones graves. Se considera una de las peores series de accidentes por radiación en la historia de los aceleradores médicos.
El análisis clásico de Nancy G. Leveson y Clark S. Turner, publicado en la revista Computer de la IEEE en 1993, convirtió el caso en lectura obligada para ingenieros de software: no bastaba con «arreglar el bug»; el diseño entero era inseguro.
Once máquinas y demasiada confianza en el código
Se instalaron once Therac-25: cinco en EE. UU. y seis en Canadá. Fabricado por la empresa canadiense AECL (Atomic Energy of Canada Limited), el equipo usaba un PDP-11 y software en ensamblador heredado en parte de modelos anteriores (Therac-6 y Therac-20).
La diferencia crítica: en el Therac-25 se eliminaron muchos enclavamientos de hardware que en los modelos previos impedían ciertos estados peligrosos. La seguridad quedó, en gran medida, en manos del software. Si el código fallaba, no había una segunda barrera física equivalente.
Condiciones de carrera y operadores rápidos
Uno de los fallos más estudiados —el de Tyler (Texas)— involucraba una condición de carrera: si el operador editaba muy rápido el modo y la energía (en menos de unos ocho segundos, el tiempo que tardaban en ajustarse los imanes) y volvía a la línea de comandos, el software podía dejar la máquina en una configuración inconsistente. El haz de electrones de alta potencia podía aplicarse sin el dispersor adecuado, disparando la dosis.
Los mensajes de error eran crípticos; a veces bastaba con pulsar una tecla para reanudar. Los operadores, acostumbrados a falsas alarmas, tendían a continuar. Leveson enfatiza que centrarse solo en «la línea de código culpable» es engañoso: el problema era un sistema que no toleraba el error humano ni el fallo concurrente.
Poca documentación, poca prueba unitaria
Según la investigación, el software lo desarrolló esencialmente una sola persona durante años, con documentación escasa. Las pruebas se centraban en el sistema integrado; un responsable de calidad llegó a hablar de «2.700 horas de prueba» que, al aclararse, eran sobre todo horas de uso. La FDA acabó exigiendo cambios profundos; en 1987 la máquina se retiró para rediseño, incluyendo salvaguardas hardware contra errores de software.
Lecciones que siguen aplicando
Therac-25 enseña que en sistemas críticos el software no puede ser el único freno de seguridad; que las condiciones de carrera en código concurrente son peligros reales; y que ignorar incidentes tempranos multiplica el daño. Es el reverso trágico de anécdotas como la polilla del primer «bug»: aquí el fallo no se pegó en un cuaderno, se midió en grays de radiación.
Cada vez que un coche autónomo, un respirador o un avión confían en software, el espectro del Therac-25 aparece en las mesas de diseño. No como curiosidad histórica, sino como advertencia.
Leveson insiste en una idea incómoda para la industria: la seguridad no se improvisa con un parche tras la tragedia. Hace falta análisis de peligros, independencia entre software y hardware, y una cultura que tome en serio los primeros avisos. En el Therac-25 hubo señales previas; no siempre se interpretaron como lo que eran.
El caso se estudia en facultades de informática de medio mundo precisamente porque no es un «bug de película» aislado, sino un fallo de sistema: interfaces confusas, reutilización de código sin revalidar supuestos, y la tentación de ahorrar en enclavamientos físicos. Esas tentaciones no han desaparecido.
Fuentes
- Nancy Leveson: Therac-25 Accidents (versión actualizada)
- IEEE Computer / MIT mirror: An Investigation of Therac-25 Accidents
- Computing Cases: Software Design (extractos del caso)
- IEEE: Leveson & Turner, «An investigation of the Therac-25 accidents», Computer, 1993
Deja una respuesta