Você já deve ter se deparado com vários erros de código no seu cotidiano, seja em um aplicativo, em um site ou em um sistema. Esses erros podem ser causados por diversos fatores, entre eles, as falhas de programação.
Muitas vezes, esses erros podem ser inofensivos, até engraçados em alguns casos. Mas há situações em que eles podem ser extremamente perigosos.
Uma breve história
Entre as décadas de 70 e 80, radioterapia era um dos tratamentos utilizados para combater o câncer, existiam dois tipos diferentes de tratamento, com emissão de elétrons e raio-x. Cada um deles necessitava um equipamento específico para ser realizado, gerando mais custos para os hospitais.
Então, uma empresa desenvolveu um equipamento que podia realizar ambos os tratamentos, o Therac-25. De acordo com a necessidade do paciente, o equipamento poderia ser configurado para emitir elétrons _ou _raio-x.
Uma boa solução?
O Therac-25 foi um grande avanço na medicina, pois permitia que os hospitais economizassem dinheiro e espaço, além de facilitar o tratamento dos pacientes. No entanto, o equipamento começou a apresentar comportamentos estranhos.
Relatos de pacientes
Em um dos primeiros casos, um paciente que estava em tratamento com o Therac-25 relatou que estava sentindo dores intensas durante o processo e sua pele no local da aplicação parecia queimar. Porém os médicos acreditavam que se tratava de uma reação normal do tratamento.
Em um caso mais grave, um paciente relatou estar sentindo choques elétricos durante o processo. Mas o equipamento parecia estar funcionando normalmente, sem apresentar erro durante o procedimento e o monitor indicava que tudo estava correto.
Malfunction 54
Esse erro genericamente chamado de "Malfunction 54" era causado na tela do equipamento, sem especificar o que estava acontecendo. Muitas vezes, os médicos apenas reiniciam o equipamento e continuavam o tratamento, sem saber o que estava acontecendo. Além disso, as informações no monitor apontavam os valores corretos.
O problema
O Therac-25 era controlado totalmente por software, programado em uma linguagem de baixo nível, o que permitia um controle mais preciso do hardware.
Em um momento, uma pessoa que estava operando o equipamento, cometeu um erro ao configurar o tratamento e assim que notou, mudou o tipo de radiação emitida para a correta. Após o procedimento, apareceu um alerta no monitor que indicava ter sido emitida a dose abaixo do necessário. Então a pessoa recomeçou o procedimento.
Investigação
Depois de vários relatos, tentativas de reproduzir o erro e investigações, foi descoberto que o erro era causado por um problema de software. No momento em que a pessoa alterava o tipo de radiação, o equipamento não conseguia processar a mudança e emitia a dose de radiação muito acima do necessário, causando graves danos e até a morte dos pacientes.
A empresa responsável pelo Therac-25 usou práticas inadequadas de desenvolvimento de software, não haviam mensagens claras em relação aos erros, sequer haviam feito testes de segurança e qualidade.
Considerações
Essa história aqui resumida, é um exemplo de como um erro de software pode ser extremamente perigoso. A falta de ética e responsabilidade no desenvolvimento de software pode causar danos irreparáveis.
Um ponto importante, apesar de sermos muito dependentes de softwares atualmente, não podemos confiar cegamente neles. Mesmo que máquinas tenham uma precisão maior que humanos, elas ainda são programadas por humanos e muitas vezes podem não ter boas intenções.
Mais detalhes sobre o Therac-25.
Enjoy!
Top comments (6)
Uau! Eu nunca tinha ouvido essa história antes. Que exemplo incrível de como uma mensagem de erro vaga pode causar grandes problemas. E concordo totalmente com a sua opinião de que não devemos simplesmente confiar nas máquinas sem questioná-las!
Isso me faz pensar que confiamos na IA para resolver todos os nossos problemas com algoritmos sem realmente entendermos ou mesmo pensarmos no que está acontecendo nos bastidores. Quando nos separamos cada vez mais do que está acontecendo na máquina, é menos provável que percebamos quaisquer problemas que possam surgir.
Observe que usei o Google Translate para traduzir o seguinte:
Wow! I had never heard this story before. What an incredible example of how a vague error message can cause big problems. And, I totally agree with your takeaway that we shouldn't just put our faith in machines without questioning them!
It makes me think about us trusting AI to solve all our issues with algorithms without us really understanding or even thinking about what's going on behind the scenes. When we separate ourselves further and further from what's happening in the machine, we're less likely to pick up on any problems that might arise.
Boa observação, @michaeltharrington. A ligação que você fez do Therac-25 com a IA no quesito de questionamento foi muito precisa. Vejo muitas pessoas confiando TCCs e até mesmo decisões de trabalho ou da própria vida à IA sem ao menos questionar se está certo ou não pois supostamente foi "dada uma ideia que a máquina estaria desprovida da capacidade humana de errar".
Ser uma pessoa desenvolvedora de software também exige uma grande responsabilidade. E muita gente ainda negligencia a importância do nosso papel e dos nossos estudos para aprimorarmos as boas práticas. Esse artigo me trouxe uma grande reflexão. Obrigada por compartilhar!
Excelente post, @bug_elseif. Uma leitura muito fluida que eu não encontrava já há algum tempo. Não conhecia a história do Therac-25 e o post foi muito claro e esclarecedor tanto na história quanto na mensagem a ser passada. Confesso que a imagem do erro da soma me capturou de primeira para a leitura. Continue escrevendo seus posts e instigando à reflexão!
Aqui está a prova que embora reiniciar a máquina faça o problema sumir, ele pode não ter desaparecido. Isso me lembrou outra história também, relacionada a Apollo 11.
A Margaret Hamilton, que era a mulher que estava encarregada do software que iria no foguete da Apollo levava a filha pro trabalho em algumas ocasiões, e algumas vezes ela participava de simulações. Eis que em uma das simulações, a filha da Margaret colocou pra rodar o programa de decolagem no que seria o meio do voo, o que resultaria em sérios problemas na missão que eventualmente poderiam resultar na destruição da nave ou algo do tipo.
A Margaret levou esse "bug" pra equipe e foi dito pra ela que quem iria pilotar a nave são astronautas altamente treinados, que não cometeriam o mesmo que uma criança, como a filha dela, cometeu na simulação. Mas a Margaret sempre ficou com aquela sensação de "e se?".
E aí na Apollo 8, uma das missões antes da Apollo 11, adivinha o que um dos astronautas altamente treinados fez? Ativou o script de decolagem no meio do voo e toda a equipe em solo precisou desesperadamente encontrar uma forma de reestabelecer o software da nave para que a missão pudesse ser concluída.
Não preciso dizer que essa correção de bug foi colocada no software da Apollo 11.
Ótima historia, obrigado por compartilhar.
Eu passei pelo título desse artigo umas 4 ou 5 vezes, o nome dele não é nada chamativo ou claro, na 6ª vez eu fiquei curioso para saber sobre oq era e olha eu aqui kkkkkkkk.