Introducción al caso Therac-25
II.Breve introducción al accidente
Se vendieron 11 unidades de Therac 25, 5 unidades se desplegaron en Estados Unidos y 6 unidades se instalaron en Canadá entre 1985 y 1987**. * Ocurrieron seis accidentes graves en los que la dosis de radiación excedió la norma en gran escala, y todo el equipo fue retirado del mercado en 1987. Se realizaron modificaciones importantes al diseño original, incluida la instalación de dispositivos de protección de hardware para evitar errores de software. Los siguientes son 4 de estos 6 incidentes:
1. En junio de 1985, una mujer de 61 años fue al Centro Oncológico Kennestone en Marietta para recibir rayos de electrones de 10 MeV en la clavícula durante el tratamiento. , el paciente sintió calor y dolor y gritó en voz alta. El doctor Tim Still no pudo explicarlo y sospechó que estaba relacionado con una radiación excesiva y se comunicó con AECL por teléfono. Los ingenieros de AECL respondieron que no había posibilidad de sobredosis en el equipo. Posteriormente, el paciente presentó una demanda. El paciente sufrió graves quemaduras y le amputaron los hombros y los brazos, pero la demanda no pudo presentarse por falta de pruebas.
2. En julio de 1985, una paciente de 40 años con cáncer de cuello uterino recibió tratamiento con Therac 25 en Hamilton, Ontario, Canadá. La dosis de tratamiento fue de 200 rads. Durante el tratamiento, la máquina se detuvo y. 'HTILT' apareció en la pantalla. Al mismo tiempo, la consola mostró "Sin dosis" y el tratamiento se suspendió, por lo que el operador presionó el teclado para reanudar la operación. Después de ocurrir cinco veces, la máquina entró en estado suspendido y se reinició. El paciente refirió una fuerte sensación de ardor y sensación de hormigueo por descarga eléctrica. El paciente falleció 5 meses después. Según análisis posteriores, el paciente recibió 15.000 rads de radiación durante el tratamiento. Para el cuerpo humano, una dosis de radiación de 1.000 rads ya es mortal.
3. En marzo de 1986, un paciente masculino con tumores en la espalda recibió tratamiento con Therac 25 en el ETCC Tyler Hospital en el este de Texas, EE. UU. El modo de tratamiento fue por haz de electrones, la dosis fue de 180 rad y el área fue. 10 cm × 17 cm. El operador estaba muy familiarizado con el funcionamiento del equipo. Rápidamente tocó el teclado e ingresó los datos relevantes. Descubrió que el modo se mostraba como ', el significado de esta información no está claramente definido en las instrucciones. , la explicación es que se ha emitido energía, que puede ser demasiado baja o demasiado alta. La consola mostró que la dosis era demasiado baja, por lo que el operador realizó las operaciones de recuperación y reinicio. En ese momento, el paciente en la cabina de tratamiento ya no pudo soportarlo y saltó de la cama y llamó a la puerta, lo que obligó a realizar el tratamiento. finalizado. El paciente murió cinco meses después. Se estimó que había recibido entre 16.000 y 25.000 rads de radiación.
4. En abril de 1986, tres semanas después del incidente anterior, el ETCC del Este de Texas en los Estados Unidos realizó un tratamiento con haz de electrones Therac 25 en un paciente masculino con cáncer de piel facial. La dosis era de 180 rad, todavía. Usando la misma operación Según la operación del personal, el proceso del incidente fue casi idéntico al caso anterior y el paciente gritó de dolor intenso. Debido a un daño cerebral, falleció 20 días después. Se analizó que el paciente recibió 25.000 rads de radiación.
3. Diagnóstico de fallos
Desde que se comenzó a utilizar el tratamiento con radioterapia en Estados Unidos en los años 60, no se han producido accidentes importantes, ya sea en un paciente, en un hospital o en un hospital. fabricante, No existe ninguna preparación mental para la posibilidad de accidentes por radiación con dosis excesivas. Después de que se produjera el primer accidente en 1985 y un paciente presentara una demanda, el fabricante del equipo AECL negó por completo la posibilidad de un mal funcionamiento. Dado que tanto el fabricante como el hospital carecían de los registros necesarios, la FDA no pudo iniciar una investigación.
En julio de 1985, después del accidente de Hamilton, la FDA instó a AECL a investigar. Aunque AECL no pudo recrear la escena del accidente, habían comenzado a sospechar que el accidente pudo haber sido causado por una falla momentánea del sistema. El microinterruptor en la posición fija de la mesa giratoria se debió a errores de datos de entrada del software. AECL realizó las mejoras correspondientes y notificó al hospital y a la FDA, afirmando: "El análisis muestra que la tasa de riesgo del nuevo régimen es 5 órdenes de magnitud menor que el régimen anterior".
Después de dos accidentes consecutivos ocurridos en el Hospital Tyler en el este de Texas, EE. UU., en 1986, gracias a los esfuerzos conjuntos de operadores y médicos, finalmente se descubrió que el sistema de control del Therac 25 puede tener importantes peligros ocultos.
1. Sistema de control software de Therac 25
A partir de Therac 6, el equipo ha sido controlado mediante software informático, pero su principal función de control la realiza el circuito hardware, y el El software sólo juega un papel auxiliar. Al diseñar Therac20 y Therac25, los desarrolladores afirmaron que el sistema de control por computadora fue diseñado de forma independiente. De hecho, debido a su confianza en el software de control Therac 6, ambos dispositivos reutilizan el software de control principal de Therac 6.
Las características del sistema de control de software de Therac 25 son:
1) Funcionamiento cíclico según prioridades de tareas personalizadas. Es decir, las "tareas" se ejecutan en orden de criticidad y las tareas con alta criticidad se ejecutan antes que las tareas con baja criticidad. No hay otras tareas que se ejecuten sincrónicamente excepto test & set.
2) El software consta de cuatro componentes, a saber:
Almacenamiento de datos: configuración de la máquina y datos de tratamiento del paciente;
Procesamiento de interrupción;
Tareas clave: detectar entrada de datos, leer datos codificados, buscar parámetros operativos, llamar a subrutinas, configurar los imanes que excitan la máquina para que se doble (con un retraso de 8 segundos), hacer un bucle o retrasar hasta que se complete la configuración del imán, mientras se configura iniciar tratamiento, realizar tratamiento;
Tareas no críticas: manejadas por teclado, incluida la entrada de texto, codificación de variables de datos compartidos de 2 dígitos y configuración de una bandera después de completar la entrada de datos.
2. Recreación del accidente del Therac 25 en el Hospital Taylor en abril de 1986
Después del accidente del Therac 25 en el Hospital ETCC Taylor en abril de 1986, ETCC detuvo inmediatamente el trabajo del Therac 25. y Notificar a AECL. Los médicos de ETCC llevaron inmediatamente a cabo una cuidadosa investigación del accidente. Dado que la operadora de la máquina pudo recordar con precisión el funcionamiento real del equipo cuando ocurrió el accidente, después de un período de arduo trabajo, finalmente se reprodujo el mensaje de error "Malfuncionamiento 54". Descubrieron que durante la fase de edición de la máquina, la velocidad de entrada de datos era un factor clave en el error. Es decir, para un operador experto, después de repetir la misma operación miles de veces, la velocidad de edición sería cada vez más rápida. , y eventualmente Esto hará que aparezca el mensaje 'Malfuncionamiento 54', indicando que ha ocurrido un accidente por sobredosis de radiación. Los médicos que participaron en el experimento alcanzaron una velocidad de edición crítica después de un largo período de práctica. El ingeniero de AECL, que estaba confundido por los resultados, llegó al lugar al día siguiente. No fue hasta que reapareció el mensaje 'Malfunction 54' bajo la capacitación de médicos y operadores que aceptó la opinión del hospital y midió la dosis de radiación. esta vez había alcanzado una saturación de 25.000 rad.
Los médicos del Centro Conjunto de Radiación de la Universidad de Chicago que recibieron la noticia realizaron experimentos en su equipo de enseñanza Therac 20. Dos meses después, los médicos observaron que los fusibles se quemaban y los relés se abrían con frecuencia en los experimentos de los estudiantes. Tras el análisis, el incidente fue esencialmente idéntico al fallo del Therac 25, pero debido a la protección del circuito del hardware, no provocó ningún impacto grave.
Con esta serie de resultados experimentales, finalmente se confirmó la causa del fallo del Therac 25. Las fallas no son causadas solo por errores comunes de software. La causa principal de la falla es el diseño de seguridad general del sistema.
4. Lecciones
Después de determinar la causa del accidente, se suspendió el uso de todos los Therac 25, se retiraron del mercado, se rediseñaron y se instalaron dispositivos de protección de hardware. Después de eso, la dirección, la comunidad de ingenieros y el mundo académico mantuvieron largas discusiones para discutir las lecciones del accidente. Este proceso duró hasta mediados de la década de 1990, y personas de todos los ámbitos de la vida tenían opiniones diferentes. Entre ellos, el resumen y la comprensión de los accidentes del famoso experto estadounidense en ingeniería de seguridad Leveson es el más sistemático y representativo. La siguiente parte de este artículo cita algunas de las principales conclusiones a las que llegó.
1. La ocurrencia de cualquier accidente rara vez es simple. Generalmente está contenida en una red compleja compuesta de muchos eventos interrelacionados, que involucran factores como la tecnología, las humanidades y la organización. La razón importante de los múltiples accidentes de Therac 25 esta vez es que, sin pruebas muy claras, están convencidos de que se ha identificado la causa del accidente. Por ejemplo, en el accidente de Hamilton se consideró el microinterruptor como la causa principal. accidente y otras pruebas fueron ignoradas. Análisis de varios posibles factores relevantes.
Otra suposición errónea es que corregir un error de software evitará accidentes futuros. De hecho, los fallos de software quedan expuestos constantemente, uno tras otro.
La causa del accidente a menudo se atribuye simplemente a un error humano. De hecho, cualquier factor implicado en el accidente puede etiquetarse como error humano, incluso la pérdida y el fallo del hardware pueden atribuirse al diseñador. proporcionar la información necesaria y la falta de mantenimiento y reemplazo por parte del operador hacen que sea inútil e inútil atribuir un accidente únicamente a un error humano.
Es igualmente inútil atribuir la causa de un accidente a errores informáticos y de software. . El software en el accidente de Therac 25 tuvo problemas, pero fue solo un factor. Si creemos que el software fue la causa principal del accidente de Therac 25, entonces debemos concluir que para evitar accidentes similares en el futuro, perfecto. Se deben construir estructuras. Obviamente es imposible darse cuenta de que el software no funcionará de maneras inesperadas en cualquier entorno. Aparte de eso, no tengo más remedio que no utilizar software en ningún sistema. Está claro que todos los argumentos anteriores son demasiado pesimistas.
Debemos utilizar una perspectiva de ingeniería de sistemas para analizar los problemas que enfrentamos desde la perspectiva de accidentes de sistemas complejos. Para el incidente de Therac 25, los factores involucrados incluyen:
Falta de gestión y falta de procedimientos establecidos para rastrear todos los incidentes reportados;
Confianza excesiva en el software, hasta el punto de que todos se eliminó el hardware Dispositivos de enclavamiento, lo que convierte al software en un único punto de falla que puede causar accidentes;
Prácticas de ingeniería de software de bajo nivel;
Los resultados de evaluaciones de riesgos poco realistas y dependencia excesiva en evaluaciones.
Es poco probable que vuelva a ocurrir exactamente el mismo accidente en el futuro. Si estudiamos y mejoramos varios factores relacionados con los accidentes, es posible evitar que ocurran errores similares.
2. Se debe enfatizar la ingeniería de sistemas. Un error común en este caso y en otros incidentes de ingeniería es confiar demasiado en el software. Los profesionales no relacionados con el software parecen creer que el software no puede fallar y, por lo tanto, dependen demasiado de las funciones de control de la computadora. De hecho, aunque el software no sufre desgaste como el hardware, los errores de diseño del software son más difíciles de descubrir y eliminar. Los modos de falla del hardware son generalmente limitados, por lo que es más fácil crear mecanismos de protección. La lección aprendida de Therac 25 es no eliminar los bloqueos de hardware estándar al implementar el control por computadora.
Las copias de seguridad de hardware, los enclavamientos y otros dispositivos de protección de seguridad han sido reemplazados por software en muchos sistemas diferentes, incluidos aviones comerciales, plantas de energía nuclear y sistemas de armas. Cuando existen interbloqueos de hardware, a menudo están controlados por software. Al diseñar sistemas peligrosos, suponer que un solo fallo es suficiente para provocar un accidente grave viola los principios básicos de la ingeniería de sistemas. El software debe manejarse como un componente separado. El software no debe asumir funciones de seguridad por sí solo. En el diseño del sistema, es necesario evitar que un solo error de software o un error de ingeniería del software sea suficiente para causar consecuencias catastróficas.
Otra tendencia en la comunidad de ingenieros actual es ignorar el software. El primer análisis de seguridad de Therac 25 no incluyó el software (aunque el software asumió casi todas las responsabilidades de seguridad, cuando ocurrieron los problemas, los analistas se centraron por completo en). hardware nuevamente. Investigar el posible impacto del software no debería ser el último paso en el análisis de incidentes. De hecho, los errores de software pueden causar fallas transitorias del hardware porque el software envía instrucciones al hardware que se está controlando.
En Therac 25, la respuesta del paciente se convierte en el único indicador real del alcance de la exposición a la radiación. Therac 25 depende completamente del operador. No existe ningún mecanismo independiente para comprobar si el funcionamiento es correcto y la máquina por sí sola no puede detectar si se han producido grandes dosis de radiación. La cámara de iones del Therac 25 no puede soportar haces de electrones de alta densidad y muestra bajas dosis de radiación cuando están saturados.
Cualquier empresa que construya sistemas críticos para la seguridad debe realizar experimentos de verificación y contar con un procedimiento de análisis de incidentes establecido en caso de que se encuentre alguna pista de un problema. La primera llamada del doctor Tim Still debería impulsar a Kennestone a realizar una investigación exhaustiva. AECL y los procedimientos de respuesta de emergencia deben iniciarse inmediatamente después de la primera demanda.
Toda empresa que utilice equipos peligrosos debe tener un registro y seguimiento de peligros, además de hacer que los informes y análisis de accidentes formen parte de su proceso de control de calidad. Esto no sólo ayudará a prevenir accidentes, sino que también reducirá las tarifas de seguros y los litigios en caso de una demanda. Los antecedentes se proporcionan más adelante.
Finalmente, no es prudente confiar demasiado en los resultados numéricos del análisis de seguridad. No es verificable afirmar que la seguridad ha mejorado en 5 órdenes de magnitud después del accidente de Hamilton y la mejora de la falla del microinterruptor.
3. No se puede ignorar la ingeniería de software. Therac 25 incluyó un error de codificación del software, un problema poco común entre otros incidentes generales relacionados con la computadora. Los errores informáticos generales implican principalmente requisitos, condiciones ambientales y estado del sistema. Aunque la implementación de la ingeniería de software no puede eliminar por completo los errores en el software, puede reducirlos en gran medida. Muchas empresas utilizan software en sus sistemas pero no lo toman tan en serio como los ingenieros de software. Los siguientes principios básicos de la ingeniería de software se violan claramente en Therac 25:
·La preparación de la documentación del software no debe ser una tarea posterior. -comportamiento factual;
·Se deben establecer sistemas y estándares de garantía de calidad del software;
·El diseño debe mantenerse simple;
·Cómo obtener mensajes de error , como Para las pruebas de verificación de software, se debe formular un plan desde el comienzo del diseño del software;
·El software debe probarse y analizarse exhaustivamente a nivel de módulo y es incorrecto realizarlo únicamente. pruebas del sistema;
·La seguridad debe estar integrada en el sistema de software. Cualquier proyecto de software crítico para la seguridad debe incluir procedimientos especiales de análisis y diseño de seguridad. Además, la seguridad a nivel del sistema debe garantizarse independientemente de la existencia de. errores de software. El Therac 20 contenía el mismo error de software que causó el incidente de Taylor, pero el entrelazado del hardware eliminó las consecuencias del fallo.
Aquí también podemos aprender importantes lecciones sobre la reutilización de software. Existe una tendencia general a creer que la reutilización de software o el uso de software comercial disponible aumenta la seguridad porque el software ya se utiliza ampliamente. De hecho, reutilizar módulos de software no garantiza la seguridad del nuevo sistema y, en ocasiones, incluso se convierte en un diseño peligroso. La seguridad es un atributo de calidad del sistema y no es del todo equivalente a la calidad del software. Reescribir software nuevo para hacerlo más claro, más simple y, en muchos casos, más seguro.
El hecho de que una persona haya tomado un curso de programación y haya escrito programas en una microcomputadora no significa que tenga la capacidad de desarrollar software crítico para la seguridad. Trabajar en el desarrollo de software crítico para la seguridad requiere capacitación especializada. Ningún ingeniero posee automáticamente las capacidades de un ingeniero de software.
La interfaz de usuario recibió cierto grado de atención durante el incidente de Therac 25. De hecho, solo se vio parcialmente afectada por este incidente, aunque la interfaz del software, como otras partes del software, tiene espacio para. mejora. . Los ingenieros de software necesitan más capacitación en diseño de interfaces y más entrada de datos desde una perspectiva de ingeniería humano-máquina. Es importante resaltar los posibles conflictos entre facilidad de uso y seguridad. Uno de los propósitos del diseño de la interfaz de usuario es hacer que su uso sea lo más conveniente posible para los operadores, pero en el software Therac 25, la simplicidad de operación va a expensas de la seguridad del sistema. Finalmente, no sólo se debe considerar la seguridad del software y la interfaz del software en el diseño inicial, sino que también se deben registrar los motivos de la decisión para que se puedan documentar los cambios futuros.