O incidente do Therac-25 (2021)

• Máquina médica de radiação Therac-25 envolvida em acidentes fatais
• Falha de software levou vários pacientes a uma grave superexposição à radiação
• O problema surgiu após a substituição do sistema de segurança existente por um sistema de controle digital
• A falta de diagnóstico da falha e de comunicação atrasou a identificação da causa dos acidentes
• Como principal lição de segurança, destaca-se a importância da confiabilidade dos algoritmos e de testes rigorosos

---

Visão geral do incidente do Therac-25

• O Therac-25 era amplamente utilizado como equipamento médico de radioterapia
• Esse equipamento tinha a função de aplicar doses intensas de radiação em pacientes com câncer
• Os dispositivos de segurança mecânicos do tipo interlock foram substituídos por um sistema de controle baseado em software
• Porém, essa mudança aumentou o risco de ocorrência de erros de software

Como o acidente aconteceu

• Em determinadas sequências de operação ou com entradas rápidas em sequência, surgia uma falha no programa
• Com isso, os dispositivos de segurança não funcionavam corretamente, e os pacientes recebiam radiação com intensidade acima do projetado
• Entre 1985 e 1987, ocorreram vários casos de superexposição grave em pacientes, com algumas mortes
• No início, havia uma tendência de ignorar problemas de software como causa das falhas da máquina de radiação

Causas do problema

• No processo de verificação de confiabilidade, foram realizados apenas testes simples que não refletiam o ambiente clínico real
• Houve tratamento de erros e gerenciamento de interlocks insuficientes, o que provocou falhas de algoritmo em situações extremas
• A ausência de um sistema claro de relato de problemas e comunicação entre fabricante e hospital atrasou a identificação e a correção da falha
• O caso é avaliado como um fracasso de projeto de software orientado à segurança

Principais lições

• Ao projetar algoritmos diretamente ligados à segurança, são necessários validação rigorosa e programação defensiva
• É essencial diversificar os casos de teste e realizar simulações com base em cenários reais de uso
• Destaca-se a implementação sistemática de vários loops de tratamento de erros e sistemas de log
• Em áreas que exigem alta confiabilidade, é preciso reconhecer o risco de depender exclusivamente do controle por software
• Este incidente é um caso emblemático que relembrou à engenharia de software e à indústria de dispositivos médicos em todo o mundo a importância da confiabilidade dos algoritmos, da gestão de segurança e dos sistemas de comunicação

[GN⁺]

Opiniões do Hacker News

• Destaca-se que a qualidade de software não surge simplesmente por haver bons desenvolvedores, mas é o produto final de processos que atravessam toda a organização. Esse processo afeta não só as práticas de desenvolvimento, mas também testes, diretoria e até vendas e atendimento. O que devemos aprender com o caso Therac-25 é que sistema de tipos, testes unitários e código defensivo não resolvem tudo sozinhos. Na minha opinião, a verdadeira falha foi ter demorado demais para relatar, investigar e corrigir os acidentes. O podcast Cautionary Tales também tratou recentemente do caso, e me chamou a atenção o fato de que os usuários do Therac-25 enfrentavam continuamente erros desconhecidos, mas isso não chegava de forma adequada a quem poderia corrigir o problema. (link do podcast)

  • Não concordo com essa opinião. Tenho muitos anos de experiência projetando componentes aeronáuticos, e o princípio central é que uma única falha nunca pode levar a um acidente. A forma de fazer isso não é “escrever software de qualidade” nem “testar o suficiente”, mas ter “um sistema independente capaz de impedir isso mesmo se o software se comportar da pior forma possível”. No caso do Therac-25, seria necessário um detector de radiação que desligasse automaticamente o equipamento ao ultrapassar o limite de segurança, além de um projeto físico que tornasse impossível emitir radiação excessiva.

  • Eu também estava prestes a recomendar esse podcast. Vale especialmente a pena se você se interessa por bugs de software. Um fato interessante é que os aparelhos operados manualmente no início tinham o mesmo defeito, mas um fusível queimava com a fuga de corrente e impedia que o defeito se concretizasse. É um excelente exemplo do Swiss Cheese Model (referência sobre o Swiss Cheese Model)

  • Quero ressaltar que a maior parte do software não está ligada diretamente à vida ou morte. Na maioria dos casos, quando falha, a página só carrega devagar, o relatório fica cheio de NaN ou é preciso iniciar manualmente um job em lote. É raro alguém morrer de fato por causa de um problema de qualidade de software, e imagino que os desenvolvedores que criam esse tipo de software saibam muito bem da responsabilidade que têm.

  • A empresa em que trabalhei fabricava equipamentos fotográficos e científicos de altíssima qualidade. Eram muito caros, mas os clientes reconheciam que valiam o preço. Vivi na prática que qualidade não é apenas resultado de processo; no fim das contas, ela nasce da “cultura”.

  • Muitos desenvolvedores acham que, se não trabalham com sistemas de alta confiabilidade, então questões de qualidade não têm nada a ver com eles, e isso está totalmente errado. Mesmo falhas de software que parecem pequenas podem ter um impacto enorme na vida de alguém ou em uma empresa. Por exemplo, bloquear um fluxo importante, corromper dados de vida pessoal ou prontuários médicos, ou impedir o pagamento de um produto essencial.

• Alguém nos comentários do artigo mencionou que, nos anos 80 e 90, havia no setor médico uma forte percepção de que computadores eram perigosos. Até o começo e meados dos anos 2000, os prontuários ainda eram escritos à mão em papel. Participei por um curto período de um projeto experimental de prontuário eletrônico em UTI, no qual meu papel era administrar o servidor, e toda a equipe médica odiava muito o sistema. Na época nem existiam tablets, então consultar ou alterar registros no computador era incômodo. Todas as prescrições eram normalmente escritas diretamente no prontuário ao lado do leito, com possibilidade de verificação e correção imediatas. Como perda de informação ou atraso no acesso podiam ser fatais, os médicos não odiavam computadores sem motivo; eles realmente sentiam que eram mais perigosos do que caneta e papel. Imagino que a situação tenha melhorado depois, mas ainda é algo a se ter em mente.

  • Hoje, empresas como a Chipsoft praticamente dominam o setor de TI hospitalar. Cobram valores altíssimos, mas a qualidade do software é péssima, e quanto maiores ficam, menos alternativas restam. Não entendo por que permitimos fornecedores tão hostis.

  • Ainda hoje há casos em que a queda de sistemas informatizados obriga a equipe médica a voltar para caneta e papel. Não consigo entender como esses sistemas não têm redundância. O mais espantoso é que esses produtos comerciais existem assim mesmo.

  • Nos EUA e na Europa, EMR (prontuário médico eletrônico) não é classificado como dispositivo médico, então escapa de muitas regulações. link do artigo relacionado

• É interessante comparar com o escândalo dos Correios britânicos. São casos totalmente diferentes, mas ambos compartilham a mesma premissa equivocada de que “software não pode estar errado”. Do ponto de vista de um desenvolvedor isso é até risível, mas para não especialistas a fragilidade do software é difícil de entender. Havia uma cultura de assumir que software não teria defeitos e, por isso, nem sequer testá-lo adequadamente.

  • Na verdade, até desenvolvedores muitas vezes confiam demais em software. Eu sempre parto do princípio de que qualquer sistema que desenvolvi pode ruir a qualquer momento. É por isso que eu nunca entraria em um carro autônomo. Acho curioso como os usuários do HN parecem adorar virar beta testers de novas tecnologias. Claro, dizem que carros autônomos são estatisticamente mais seguros, mas uma das razões é que os motoristas ao redor dirigem com mais cuidado por causa deles. Além disso, carros autônomos são sistemas novos aos quais não se aplicam supervisão humana, possibilidade de intervenção direta nem critérios rígidos, e acho que esse é o problema.

  • Acho que houve um processo mental em que, como nas máquinas elétricas e mecânicas tradicionais a principal falha vinha do desgaste de peças, concluiu-se erroneamente que software seria naturalmente mais confiável por não se desgastar.

  • Acho que o escândalo dos Correios foi muito mais malicioso. Altos executivos recebiam incentivos com base no dinheiro arrecadado dos donos das agências, e também mentiram para os tribunais e para ministros sobre a confiabilidade do software. Comparado a isso, o Therac-25 parece mais um erro honesto.

• Tenho a sensação de que um caso semelhante ao do Therac-25 vai acontecer em breve. Há gente demais operando agentes de IA em modo YOLO, então, se um modelo como Claude ou Gemini for conectado de forma errada a hardware real, parece questão de tempo até causar um acidente. IA baseada em agentes ainda está aquém no campo de sistemas embarcados, e só de imaginar uma aplicação irresponsável de IA em áreas como equipamentos de radiação já dá medo.

  • No caso Horizon dos Correios britânicos, vários donos de agências cometeram suicídio e dezenas de vidas foram destruídas. Acho que precisamos aprender com o Therac-25 que todo software importa. Todo software traz o risco de prejudicar alguém, então é preciso sempre ter cuidado.

  • Mesmo IA não agêntica, por algumas definições, já está “matando pessoas”. Recentemente ganhou destaque um caso em que um chatbot de IA levou alguém ao suicídio, e, à medida que IA for usada em áreas de decisão importantes como seguro de saúde, é bem provável que mais pessoas “morram por causa da IA”. Já existem vários casos em que IA causou acidentes fatais, como em carros autônomos. Até bugs aparentemente triviais, como erros em Excel, já afetaram a sociedade em escalas de dezenas ou centenas de milhares de pessoas. Mas, com IA, a responsabilidade também tende a ficar nebulosa e fácil de contornar, como no caso Horizon. Também sinto que ferramentas de copiloto de IA ainda deixam muito a desejar na área embarcada.

  • O caso do MCAS do 737 MAX é uma falha em nível de sistema, mas ainda assim é um exemplo emblemático desse tipo de grande problema de qualidade de software. Acho que desastres assim vão se repetir no futuro.

  • O desastre com o Boeing 737 MAX também é um exemplo representativo de software de baixa qualidade que tirou cerca de 350 vidas (link com informações sobre o MCAS)

  • Quando tentei usar agentes de IA mais modernos em trabalho embarcado, o desempenho ficou abaixo do esperado. Vejo com frequência LLMs se confundirem mesmo em um webapp CRUD simples quando o modelo de dados fica mais complexo e há duas ou três etapas de transformação. Por exemplo, quando o campo de entrada é created_at, o armazenamento usa created_on e o envio para um sistema externo usa last_modified, isso já vira problema.

• Achei marcante o relato de que, no Therac-25, certos pressionamentos de tecla em um terminal VT100 podiam causar uma superexposição à radiação em um instante. Um operador experiente conseguia digitar rapidamente em menos de 8 segundos e, nesse caso, a entrada não era refletida corretamente, o que podia levar a um acidente fatal. Ao ver problemas assim, a tendência atual de levar até interfaces industriais e automotivas para touchscreens me parece inquietante.

  • Em UI, costuma-se usar a abordagem de optimistic update para melhorar a experiência do usuário, de modo que a tela reage rápido, mas a aplicação real só é sincronizada depois. Espero que haja consciência de onde esse método não deve ser usado.

  • Houve um caso no iOS 11 em que, ao digitar rapidamente “1+2+3” na calculadora, o resultado saía errado (caso relacionado no HN). Até algo aparentemente banal como uma calculadora pode apresentar esse mesmo modo de falha.

• Fico curioso se as pessoas aprenderam sobre casos como o Therac-25 ou outros exemplos de segurança/ética na universidade. Eu estudei esse caso em uma disciplina geral de engenharia, junto com curva da banheira e cálculo de bombas de resfriamento redundantes, e queria saber se esse tipo de conteúdo ainda faz parte da grade.

  • Em uma disciplina de interfaces de máquinas na Purdue, no começo dos anos 90, o conceito de “histerese” foi enfatizado. Era obrigatório considerar que sistemas analógicos não param instantaneamente como computadores e podem apresentar vários comportamentos dentro da faixa de operação.

  • Esse tipo de tema aparece em disciplinas de engenharia de sistemas. (link da aula do MIT)

  • Aprendi sobre esses casos em cursos de ciência da computação no nível universitário ou acima. Depois, trabalhando em medtech, continuei lembrando disso.

  • Lembro que, em ética em engenharia, literalmente só vimos Tacoma Narrows e Therac-25. E isso em uma única aula de 1 hora.

  • Fiquei curioso e criei uma enquete. Quero saber quem teve esse tipo de aula. (link da enquete)

• Os aparelhos anteriores tinham intertravamentos de hardware. Mesmo que houvesse problema no software, isso terminava apenas como um incômodo. Mas, por excesso de confiança na estabilidade do software, os intertravamentos de hardware foram removidos para cortar custos, e passou-se a depender apenas de monitoramento por software. No fim, um problema pequeno virou uma tragédia fatal. É um caso emblemático de dissonâncias surgindo em diferentes pontos do sistema.

• O autor do primeiro comentário do artigo é médico, formado também em ciência da computação, e presidente de uma sociedade profissional ligada à prevenção de abuso infantil (link do perfil). Mas os pareceres médicos sobre abuso infantil ainda têm muitas fragilidades por causa de dados e evidências incorretos, além de raciocínio circular exploratório. É difícil encontrar uma verdade objetiva, e no campo há uma tendência de considerar “abuso infantil sem sombra de dúvida” com base em apenas alguns achados. Mais recentemente, surgiram IAs de caixa-preta que prometem detecção de alta precisão com base nesses dados imperfeitos, mas é impossível obter previsões corretas a partir de dados errados (garbage in, garbage out). Preocupa-me que diagnósticos imprecisos por IA levem a falsas acusações de abuso infantil, destruição de famílias e punições indevidas. (material relacionado, artigo clínico, IA e problemas de dados, link do estudo)

• Um relatório de 1993 mencionava a necessidade de qualificação para engenheiros de software de sistemas críticos para a segurança. Não se pode virar desenvolvedor de software crítico para segurança após apenas algumas aulas de programação, e o relatório previa que, se casos como o Therac-25 se repetissem, certificações do tipo se tornariam obrigatórias. No Reino Unido já se discutia o desenho de currículos obrigatórios. Mas, passados 32 anos, a realidade ficou bem longe dessa expectativa.

  • Atuo há 15 anos no Canadá como engenheiro de software profissional registrado, mas não senti benefícios práticos e pretendo deixar de renovar a licença em breve. Houve um debate sobre tornar o desenvolvimento de software uma área de engenharia mais estruturada, mas isso agora parece ter quase desaparecido.

  • Software crítico para segurança não se aprende em sala de aula; isso se constrói com longa experiência prática e treinamento. Existem padrões como o Do-178 na aviação e o IEC 61508 na indústria, mas o nível real de aplicação varia conforme orçamento e cronograma. Ainda assim, quando ocorre um acidente, para a vítima tanto faz se havia relatórios de auditoria. Toda regulação e toda regra acabam surgindo só depois que alguém já se sacrificou.

• Todo o software do Therac-25 foi escrito por um único desenvolvedor e, depois que ele deixou a empresa em 1986, sua identidade nunca foi revelada. Muitos leitores podem imaginar que “o desenvolvedor enriqueceu com essa tragédia e se aposentou no luxo”, mas naquela época, ao contrário de hoje, desenvolvedores eram mal pagos e pouco valorizados. Nos anos 80, os protagonistas das empresas de tecnologia eram os vendedores, e a comissão de venda do Therac-25 pode muito bem ter superado o salário anual do desenvolvedor. Especialmente considerando a localização da AECL, o contexto da época, o vínculo governamental e o fato de ser software embarcado, tudo isso apontava para salários baixos. Em 1986, algo em torno de CAD 30 mil a 50 mil, o que mesmo corrigido para valores atuais daria entre US$ 78 mil e US$ 129 mil, sem stock options.