O Therac-25 foi um acelerador linear de radioterapia desenvolvido pela Atomic Energy of Canada Limited (AECL) e lançado em 1982. Entre 1985 e 1987, pelo menos seis pacientes receberam overdoses massivas de radiação, resultando em três mortes confirmadas e sequelas permanentes nos sobreviventes.
Ao contrário de seus predecessores (Therac-6 e Therac-20), que possuíam interlocks de hardware independentes do software, o Therac-25 delegou toda a segurança ao software — escrito em assembly para o PDP-11 e reaproveitado das versões anteriores sem auditoria completa de segurança.
O caso é considerado o estudo de caso mais citado da história da segurança de software e da Interação Humano-Computador. As falhas não eram apenas técnicas: envolviam design de interface deficiente, cultura organizacional de minimização de riscos e normalização do risco pelos operadores ao longo de meses de uso.
A investigação de Leveson & Turner (1993) identificou que os bugs existiam nos sistemas anteriores mas eram inofensivos porque o hardware os mascarava. A decisão de remover os interlocks físicos para reduzir custo foi o ponto de inflexão.
CONTEXTO GERAÇÃO D: Esta simulação reimagina o caso no contexto da era Web & Multimídia (1990s–2000s). A interface VT100 é substituída por formulários HTML com validação JavaScript. Novos riscos surgem: latência de modem, dependência de servidor remoto, complexidade da stack web. A pergunta central é: o que melhoraria e o que pioraria se o Therac-25 fosse construído com tecnologia web?
O Therac-25 usava um disco óptico rotativo para posicionar fisicamente o colimador entre o modo Elétron e o modo Raio-X. A rotação levava aproximadamente 8 segundos. Durante esse intervalo, o terminal VT100 continuava aceitando entradas — inclusive edições de campos já confirmados.
Quando o operador editava o modo após o armamento, o display atualizava imediatamente, mas o disco continuava rotacionando para a posição original. Resultado: display mostrava modo E (Elétron) enquanto o hardware disparava feixe X (Raio-X) a 25 MeV — sem o filtro de tungstênio.
Acidente histórico — Tyler, TX (março de 1987): Um técnico percebeu que havia selecionado modo X por engano e corrigiu para E. O display confirmou E. O hardware havia iniciado o travamento mecânico para X. O paciente recebeu estimados 16.000–25.000 rad (dose terapêutica: ~200 rad). A mensagem: MALFUNCTION 54.
O indicador ⚠ HW: RAIO-X mostra o mismatch entre formulário e hardware.
IHC — Três princípios violados:
1. Visibilidade do estado (Nielsen #1): O formulário atualizava instantaneamente ao clique, criando a ilusão de que a mudança foi aplicada ao hardware.
2. Feedback acurado: Não havia indicação visual do estado físico do turntable. A latência de 8 segundos era invisível na interface.
3. Mensagens acionáveis (Nielsen #9): "MALFUNCTION 54" não informa causa, estado resultante nem ação corretiva.
PERSPECTIVA GERAÇÃO D: Na era web, a validação client-side (JavaScript) atualiza o formulário instantaneamente, mas a comunicação com o hardware depende de request-response HTTP. A separação entre front-end e back-end torna esse tipo de dessincronia mais provável, não menos. Um <form> HTML não sabe o estado do turntable.
Uma variável de 1 byte (Class3) era usada como flag booleana. O código usava x = x + 1 para sinalizar "verificado" em vez de x = 1. A cada 256ª execução, o incremento causava overflow (255 + 1 = 0). O sistema interpretava 0 como "não verificado" e pulava a verificação do colimador.
O pior aspecto: após o disparo irregular, o monitor de unidades exibia 0 UM. O operador interpretava como "nada aconteceu" e repetia o tratamento.
Acidente — Yakima, WA (1987): O display mostrou "DOSE: 0 MONITOR UNITS". O operador repetiu múltiplas vezes. A vítima morreu semanas depois. Na simulação, o intervalo é 1/8 (em vez de 1/256) para observabilidade pedagógica.
IHC — Feedback falso-positivo: Este é o caso mais grave de feedback enganoso na história do design de interface: a máquina confirmou que nenhuma dose foi administrada quando a dose máxima foi entregue. Combinado com a normalização do risco, operadores desenvolveram o reflexo de prosseguir sem avaliar.
Lição: Sistemas críticos nunca devem mostrar "0" ou "nenhuma ação" quando uma ação de alto risco foi executada.
PERSPECTIVA GERAÇÃO D: Na era web, um campo de formulário mostrando "0 cGy" seria igualmente enganoso. Porém, logs de servidor centralizados (via HTTP) poderiam detectar a inconsistência entre dose enviada e dose reportada — se o desenvolvedor implementasse auditoria server-side.
Uma única variável compartilhada era usada para analisar entradas do teclado e rastrear a posição do turntable. Quando o operador navegava rapidamente entre campos (< 400ms), as rotinas de teclado e hardware liam/escreviam simultaneamente sem exclusão mútua.
Paradoxo do operador experiente: Esta condição era mais provável com operadores rápidos e treinados — o inverso do esperado em segurança. O treinamento tornava o operador mais suscetível ao bug.
IHC — Nielsen #7 (Flexibilidade e eficiência): Atalhos para usuários experientes não devem comprometer segurança. A ausência de feedback durante digitação rápida reforçava o comportamento perigoso.
PERSPECTIVA GERAÇÃO D: Validação server-side obrigatória (POST HTTP → resposta do servidor) mitigaria isso ao forçar round-trip antes de confirmar. Mas se o desenvolvedor confiou apenas em JavaScript client-side, o mesmo padrão de variável compartilhada no DOM pode persistir.
Este bug não existia no Therac-25 original porque o sistema era standalone (PDP-11 local). Na simulação web, a validação depende de comunicação com servidor remoto. Com modem discado (14.4–56 kbps) e latência variável, a conexão pode cair durante o processo de validação.
O resultado: o sistema fica em ESTADO INDETERMINADO. O servidor pode ter recebido parte dos parâmetros. O hardware pode estar parcialmente configurado. O operador não sabe se os dados foram aceitos ou não.
POR QUE ISSO É PERIGOSO: A dependência de rede introduz um ponto de falha que não existia no sistema original. Se a arquitetura web não implementar timeouts explícitos, fallbacks locais e estados de segurança (fail-safe), o sistema pode operar com configuração parcial — potencialmente mais perigoso que o Therac-25 standalone.
Os bugs do Therac-25 eram consequências diretas de decisões de arquitetura típicas dos anos 1970–1980:
Software escrito em assembly PDP-11. Sem tipos de dados, sem verificação de overflow em tempo de compilação. O bug x = x + 1 era sintaticamente válido e invisível ao montador — responsabilidade total do programador.
O PDP-11 rodava um loop de polling. Sem preempção, sem mutex, sem semáforo. Variáveis compartilhadas entre a rotina de teclado e o controle de hardware eram a norma — e a fonte das race conditions.
Terminal passivo: exibia o que o host enviava e aceitava qualquer tecla sem validação local. Não havia "campo bloqueado", "estado de espera" ou feedback de processamento.
O Therac-20 possuía circuitos independentes que verificavam posição do colimador antes de liberar o feixe. O Therac-25 removeu esses circuitos para reduzir custo, delegando 100% ao software. Essa decisão transformou bugs latentes em falhas letais.
Código reaproveitado do Therac-20. Bugs que eram inofensivos (mascarados por interlocks) tornaram-se letais. A premissa "o código já foi testado" impediu reavaliação de segurança.
Relatórios anteriores foram descartados como "erro do operador". Sem processo formal de análise de falhas nem comunicação entre hospitais afetados. A AECL resistiu quando o software foi apontado como causa.
Se o Therac-25 fosse reconstruído na era Web & Multimídia, a assinatura de hardware e software seria radicalmente diferente:
Campos com validação de tipo nativa: <input type="number" min="0" max="25">, <select> com opções predefinidas. Elimina entradas fora de faixa. Dropdowns impedem digitação livre. Porém, validação client-side (JavaScript) pode ser bypassada — segurança real depende do servidor.
Monitores CRT coloridos (800×600+) permitem codificação semântica: vermelho = parar, amarelo = atenção, verde = seguro. Em vez de "MALFUNCTION 54" críptico, alertas com ícone, descrição e ação recomendada. Reduz fadiga de alarme — se o designer diferenciar severidade dos alertas.
Conectividade HTTP permite enviar logs a servidor central. O padrão de overdoses em Yakima e Tyler seria detectado por análise cruzada de dados — não dependeria de relatos informais em conferências de usuários. Bancos de dados SQL permitem queries sobre padrões de falha.
Modems discados (14.4–56 kbps) impõem latência de 200–2000ms. Se a validação depender de servidor remoto, queda de conexão durante tratamento deixa sistema em estado indeterminado. Ponto de falha inexistente no Therac-25 standalone. A UX inteira fica dependente da qualidade da linha telefônica.
HTML + CSS + JavaScript + servidor HTTP + CGI/PHP + banco de dados = muito mais camadas que o assembly PDP-11 original. Cada camada é vetor de bugs. A ilusão de que "interface bonita = sistema seguro" é mais perigosa que o terminal críptico, porque gera confiança falsa no operador.
A cultura de desenvolvimento web dos anos 90 priorizava velocidade de entrega sobre testes de segurança. Ciclos de deploy semanais, sem revisão de código formal, sem testes automatizados em sistemas críticos. A facilidade de "publicar uma correção" criava incentivo perverso para lançar software incompleto.
Analisados à luz das heurísticas de Nielsen (1994) e princípios modernos de design de sistemas críticos:
O operador nunca sabia o estado real do hardware — apenas o que o display/formulário exibia. Com race conditions e latência, a interface era sistematicamente atrasada ou incorreta. O estado do turntable era invisível.
Heurística de Nielsen #1O mismatch entre parâmetros do formulário (PRESCRITO) e estado físico (CONFIRMADO) não era visível no terminal original. A simulação torna isso explícito com o indicador ⚠ HW em âmbar.
Heurística de Nielsen #2O botão [P] PROSSEGUIR era a ação primária após qualquer MALFUNCTION, mesmo quando prosseguir era a ação mais perigosa. O [R] RESET era secundário e discreto. A simulação reproduz essa hierarquia visual.
Heurística de Nielsen #3Nenhum mecanismo impedia: executar fora do estado ARMADO, editar campos após armamento, prosseguir após múltiplas malfunctions do mesmo tipo. O design assumia que o operador sempre tomaria a decisão correta.
Heurística de Nielsen #5Operadores precisavam memorizar o significado de cada código. "MALFUNCTION 54" não diz o que aconteceu. A documentação estava em manuais físicos separados, inacessíveis durante operação.
Heurística de Nielsen #6Mensagens de erro violavam os três requisitos: não descreviam o problema em linguagem clara, não indicavam a causa e não sugeriam solução construtiva.
Heurística de Nielsen #9Quando desvios ocorrem repetidamente sem consequências aparentes, operadores passam a tratá-los como normais. MALFUNCTIONs eram tão frequentes que operadores desenvolveram reflexo de pressionar [P]. A interface reforçava esse reflexo ao apresentar [P] como resposta padrão.
Sociologia organizacional · The Challenger Launch DecisionNa 8ª execução, o sistema completa normalmente mas mostra dose = 0 UM. O indicador ⚠ no campo DOSE sinaliza o mismatch. O Painel Instrutor exibe a nota pedagógica explicando o bug real.
Bug novo que demonstra riscos exclusivos da arquitetura web. Configurável via Painel Instrutor (latência + checkbox de queda). Não existia no Therac-25 original.
Divisão pela variável de potência poderia causar potência máxima silenciosa. Não presente nesta simulação.
O overflow real ocorria a cada 256 execuções (semanas de uso). Na simulação, intervalo reduzido para 1/8 para observabilidade em sessão pedagógica de 30 minutos.
Comando fora de ordem (44) e transição inválida (21) não estão presentes. Na interface web, botões são desabilitados por estado — o que é, em si, a melhoria de IHC que a Geração D traz: prevenção de erros via interface.
Leveson, N. G. & Turner, C. S. (1993). An Investigation of the Therac-25 Accidents. IEEE Computer, 26(7), 18–41.
MIT OpenCourseWare. Therac-25 Hands-on Assignment.
Sharp, H., Preece, J., & Rogers, Y. (2019). Interaction Design: Beyond Human-Computer Interaction (5th ed.). Wiley. Cap. 3, 6, 7.
Nielsen, J. (1994). Usability Engineering. Morgan Kaufmann. As 10 heurísticas aplicadas na análise de IHC do Therac-25.
Vaughan, D. (1996). The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA. University of Chicago Press.
TELERX-25 — Simulação educacional do Therac-25 (versão terminal).
Esta simulação é exclusivamente educacional. Não representa nenhum sistema médico real e não controla hardware.
Desenvolvida para a disciplina de Interface e Jornada do Usuário (nível superior).
Os bugs descritos são reconstruções baseadas em literatura científica para fins pedagógicos.