Erros Fatais na Programação (5º Caso) - Therac-25 (1985-1987)

O Fantasma na Máquina: O Desastre do Therac-25 e o Preço do Código Mal Escrito

Olá pessoal, a postagem de hoje é sobre o Therac-25, um dos casos mais impactantes e trágicos da história da engenharia de software embarcado. Não se trata apenas de um acidente médico dos anos 80 — é um ponto de ruptura na forma como entendemos concorrência, validação de estados e a imensa responsabilidade técnica por trás de sistemas críticos.

Na primeira metade da década de 1980, a Atomic Energy of Canada Limited (AECL) lançou o Therac-25 como o grande sucessor do Therac-20. A inovação também foi o seu calcanhar de Aquiles: a arquitetura. Enquanto o modelo anterior mantinha interlocks (intertravamentos) físicos que impediam mecanicamente a emissão de feixes de alta energia em condições inseguras, o novo projeto removeu esses bloqueios. A fabricante transferiu a responsabilidade de segurança quase integralmente para o software.

A máquina era controlada por um computador baseado no minicomputador DEC PDP-11, rodando código majoritariamente escrito em linguagem Assembly. O controle de posicionamento do alvo metálico, a seleção de energia do feixe e a validação de estados internos passaram a depender exclusivamente de variáveis em memória e rotinas concorrentes.

O Therac-25 operava em dois modos: feixes de elétrons de baixa energia para tumores superficiais; e feixes de alta energia (25 MeV) que atingiam um alvo metálico para gerar raios-X, destinados a tumores profundos. O detalhe fatal: se o feixe de 25 MeV fosse disparado sem o alvo de metal no lugar, o paciente receberia diretamente uma carga massiva e letal de radiação. O que antes era impedido por aço e relés eletromecânicos, passou a ser "evitado" apenas por linhas de código.

A Linha do Tempo da Tragédia: Confiança Cega e Avisos Ignorados

A crença na infalibilidade do código atrasou o diagnóstico do problema, resultando em uma série de acidentes devastadores documentados entre 1985 e 1987.

O Primeiro Alerta: Marietta, Geórgia (3 de junho de 1985)

O primeiro caso ocorreu no Kennestone Regional Oncology Center, em Marietta, Geórgia, nos Estados Unidos. Uma paciente de 61 anos realizava um tratamento de câncer de mama. Durante a sessão, a máquina parou e exibiu uma mensagem enigmática no terminal: "Malfunction 54". O operador, acostumado com erros de rotina que não representavam perigo, simplesmente reiniciou o sistema. A paciente sentiu um "choque elétrico excruciante".

A AECL insistiu que era fisicamente impossível a máquina ter disparado uma overdose. O diagnóstico médico inicial foi "queimadura por umidade". Meses depois, o braço da paciente foi paralisado e ela sofreu dores terríveis até o fim de sua vida. O sistema entregou entre 15.000 e 20.000 rads. A dose prescrita era de apenas 200 rads.

A Negação em Hamilton, Ontário (26 de julho de 1985)

Pouco tempo depois, no Ontario Cancer Foundation Clinic (junto ao Hamilton General Hospital), em Hamilton, Ontário, Canadá, outra paciente sofreu queimaduras severas por radiação. Novamente, a fabricante sustentou que uma overdose era impossível, pois o software “não permitiria”.

(Nota: Um terceiro incidente, menos severo mas igualmente sintomático, ocorreria em dezembro de 1985 no Yakima Valley Memorial Hospital, em Yakima, Washington, mas a causa real continuou oculta).

O Erro de Digitação: Tyler, Texas (21 de março de 1986)

O caso decisivo para desvendar o mistério aconteceu no East Texas Cancer Center, em Tyler, Texas, Estados Unidos. O paciente Ray Cox recebia tratamento quando a operadora inseriu o modo incorreto no terminal ("X" para raios-X em vez de "E" para elétrons). Ela percebeu rapidamente e usou a seta para cima para corrigir a tela em menos de 8 segundos.

Essa sequência aparentemente banal desencadeou uma condição de corrida (race condition). O software possuía tarefas concorrentes que compartilhavam variáveis globais sem a devida sincronização (semáforos ou locks). Uma rotina atualizava o modo selecionado na interface, enquanto outra controlava o posicionamento mecânico do alvo. A digitação rápida criou um estado inconsistente: a tela indicava "elétrons", mas o sistema de energia estava armado para 25 MeV, e o alvo de proteção não havia sido colocado no lugar.

O disparo ocorreu. Cox sentiu um forte impacto e a mensagem "Malfunction 54" apareceu. Acreditando ser um erro trivial, o tratamento foi reiniciado e uma segunda descarga letal foi aplicada. Ele faleceu meses depois.

O Padrão se repete: Tyler, Texas (11 de abril de 1986)

Na mesma clínica em Tyler, Texas, outro paciente sofreu um evento idêntico. Foi a reprodução experimental desse erro pelo físico do hospital que revelou a verdade perturbadora: a velocidade de digitação do operador era o gatilho. Era um bug sensível à temporização.

O Estouro de Variável: Yakima, Washington (17 de janeiro de 1987)

No Yakima Valley Memorial Hospital, em Yakima, Washington, um novo incidente letal trouxe à tona outra falha crassa: um overflow de variável. O software usava um contador armazenado em 1 byte (que vai de 0 a 255) para verificar se o equipamento estava posicionado corretamente. Ao atingir 256, a variável retornava a 0. Se o operador pressionasse "Set" no exato momento em que o contador marcava 0, o sistema interpretava erroneamente que as verificações de segurança haviam sido concluídas com sucesso, liberando o feixe sem validação.

O Que Mudou no Mundo Pós-Therac-25?

O Therac-25 reunia um catálogo de antipadrões: concorrência sem exclusão mútua, dependência de variáveis globais e a reutilização de código de um sistema antigo (Therac-20) sem reanálise de risco após a remoção do hardware de segurança. O legado dessas falhas forçou uma revolução na indústria e na engenharia de software aplicada à saúde. Aqui estão as medidas rigorosas adotadas para evitar que isso se repita:

Redundância de Hardware Obrigatória (Interlocks): O software nunca mais pôde ser o único responsável pela segurança crítica. Hoje, circuitos físicos independentes cortam a energia instantaneamente se parâmetros perigosos forem detectados, independentemente do que o código afirme.

Normas Formais de Engenharia de Software (IEC 62304): Surgiram padrões internacionais estritos para o ciclo de vida de softwares médicos. Eles exigem documentação rastreável, testes de unidade e integração exaustivos, classificação rigorosa de risco e proíbem a reutilização cega de código legado.

Análise de Árvore de Falhas (FTA) e FMEA: Fabricantes agora são obrigados a realizar análises sistemáticas de todos os modos possíveis de falha, cobrindo cenários de limites (edge cases) e interações humano-máquina não previstas.

Interfaces Homem-Máquina (IHM) Defensivas: Mensagens genéricas ("Malfunction 54") foram banidas de sistemas críticos. Os sistemas modernos devem informar o estado exato da máquina e bloquear reinicializações automáticas após falhas de segurança.

Cultura de Transparência e Reporte: Protocolos regulatórios (como os da FDA) garantem que falhas sejam imediatamente reportadas e investigadas de forma independente, impedindo que a "negação corporativa" custe novas vidas.

O Therac-25 nos lembra de uma dura realidade: quando o software controla energia suficiente para alterar a biologia humana, cada byte deixa de ser abstrato — ele passa a ter peso físico. Em sistemas críticos, confiar que “o código não pode errar” é o primeiro passo para uma falha catastrófica.

O que acharam da postagem de hoje? Por hoje é isso pessoal, um abraço e até a próxima.

FONTES:

LEVESON, Nancy G.; TURNER, Clark S. An Investigation of the Therac-25 Accidents. Report I, 1993. Disponível em: https://web.mit.edu/6.033/1999/www/reports/r01-graebner.html. Acesso em: 2 mar. 2026.

THERAC-25 Case Narrative — Online Ethics Center. Disponível em: https://onlineethics.org/cases/therac-25/therac-25-case-narrative. Acesso em: 2 mar. 2026.

Therac-25: Problemas de Projeto de Software. The Daily WTF. Disponível em: https://thedailywtf.com/articles/the-therac-25-incident. Acesso em: 2 mar. 2026.

THERAC-25: Importance of Software Quality Assurance to Prevent Failures in Medical Devices. ResearchGate. Disponível em: https://www.researchgate.net/publication/309189886_Importance_of_software_quality_assurance_to_prevent_and_reduce_software_failures_in_medical_devices_Therac-25_case_study. Acesso em: 2 mar. 2026.

Wikipedia — Therac-25. Disponível em: https://en.wikipedia.org/wiki/Therac-25. Acesso em: 2 mar. 2026.

Softnery. O Código Que Mata: A História Não Contada do Therac-25. Disponível em: https://www.news.softnery.com/p/o-codigo-que-mata-historia-do-therac-25. Acesso em: 2 mar. 2026.