Acidente da Tam pode ter sido causado por problemas de usabilidade

Está todo mundo querendo encontrar a causa e os culpados pelo acidente da Tam ocorrido ontem, dia 17/07/2007 no aeroporto de Congonhas. O avião tentou posar lotado, sob chuva forte, numa pista incompleta, em alta velocidade e em plena crise da aviação. Derrapou e explodiu num prédio. Mais de 200 mortos.

Agora, a opinião pública quer culpar alguém para aliviar sua raiva. Os jornais citam a possibilidade de uma falha técnica no avião, mas não se levanta que possíveis falhas técnicas poderiam ter ocorrido. Os jornalistas só querem saber de suspeitos:

A investigação pode demorar 10 meses, isso se não acabar em pizza. Enquanto o resultado oficial não chega, as opiniões se dividem em duas hipóteses: erro humano ou falha mecânica. Eu não entendo nada de aviação, mas quando li a notícia tive o pressentimento de que poderiam ser as duas coisas em conjunto: comportamento das pessoas e adaptação das máquinas inadequados para a situação.

O comportamento das pessoas, a mídia já está cuidando de avaliar, ou melhor, julgar. Então, aqui pretendo levantar as inadequações das adaptações das máquinas, em especial, no nível da interface entre os pilotos e o sistema. Esse ponto é relevante para análise do acidente porque a ação humana é restringida pelas possibilidades que o sistema oferece. Se os pilotos tomaram uma decisão que levou ao acidente, pode ser que não houvessem outras alternativas disponíveis no sistema para aquela situação ou, mesmo que elas existissem, elas não estavam visíveis.

Antes, um esclarecimento: não sou especialista no assunto. O que escrevo abaixo me baseio exclusivamente na minha experiência como designer de interação para a Web, na leitura de alguns artigos de Donald Norman sobre a Psicologia Cognitiva em cockpits e numa breve pesquisa que fiz sobre a documentação do modelo do avião e simuladores. Se alguém entender mais do que eu, por favor, corrija-me.

Para começar, vamos ver o que a Tam diz sobre a análise de acidentes em seu guia para a segurança em vôos:

E.3.2.1 Em poucos anos, sistemas complexos têm evoluído para sistemas automatizados sofisticados com muitas interações e interfaces. Esses sistemas podem ser formados por vastos subsistemas de hardware, firmware (isto é, software com dongle), software de eletrônica, aviônica, hidráulica, pneumática, biomecânica, ergonomia e fatores humanos. Há complicações adicionais envolvendo outras considerações, como o potencial de supervisão pela gerência e percepção do risco. Um paradigma mais completo do risco de um sistema deve levar em consideração todas estas complexidades.

Até aí tudo bem. Eles propõem, então, o modelo SHEL (Software, Hardware, Environment - Ambiente e Liveware - Pessoas):

Modelo Shel

A partir daí, as pessoas são tratadas como "Equipamento humano" e os demais equipamentos devem combinar com às suas características peculiares. O problema é que as pessoas tem o "péssimo hábito" de...

adaptar-se a más combinações, mascarando, dessa forma, qualquer má combinação sem removê-la e, como tal, constitui um perigo potencial. Exemplos disso são altímetros de três ponteiros, mau layout dos assentos nas cabines, que pode atrasar a evacuação, etc.

Eu não diria que isso é um péssimo hábito. Diria que, se uma pessoa é obrigada a usar um determinado sistema, o melhor a fazer é adaptar-se a ele. E o inverso também é verdadeiro: os sistema deve se adaptar à pessoa. Numa relação de adaptação mútua, os conflitos se assentam, mas, quando emergem variáveis externas incomuns, a adaptação acaba: o homem vai prum lado e a máquina vai pro outro. O homem abandona os procedimentos padrões e age com base na emoção para encontrar uma solução inesperada para um problema inesperado, enquanto a máquina solicita ou executa procedimentos pré-definidos para a solução do problema - isso se ela tiver percebido a adversidade.

Segundo relatos dos controladores de vôo da torre do aeroporto, os pilotos foram avisados de que a pista estava molhada e escorregadia antes do pouso. Tocaram o solo normalmente, mas não se sabe por que, os pilotos resolveram tentar subir de novo. A torre só se deu conta de que alguma coisa estava errada quando ouviram um dos pilotos gritar "vira, vira, vira!", mas em seguida o avião bateu e explodiu. Os colegas dos pilotos acreditam que o avião entrou em aquaplanagem (um estado em que o atrito com o solo é reduzido) e, quando não havia mais espaço, tentaram decolar novamente ou dar um cavalo-de-pau.

O avião pode ter entrado rápido demais na pista para a condição climática da situação, o que indicaria uma decisão errada dos pilotos. Mas vejamos se essa decisão foi tomada só pelos pilotos ou se a máquina também participou da decisão.

Segundo o FCOM, o manual do A320, quando a aeronave se encontra a baixa altitude, o modo de controle muda para pouso automaticamente. A partir daí, a máquina faz o ajuste automático da velocidade do avião e do ângulo de inclinação dentro de certos limites, que podem ser definidos pelo piloto. A imagem capturada de um simulador do A320 demonstra a sinalização visual de que o auto-land está ativado:

Autoland no controle do cockpit

Em seguida, o piloto pode ativar o auto-brake, que possui três opções:

Autobrakes no cockpit

Pode ser que os pilotos, acostumados com o procedimento padrão, ativaram o auto-brake Lo, quando deveria ser Med ou Max. Também pode ser que eles tenham superestimado a velocidade máxima que o avião poderia atingir naquela situação e usaram o padrão. Em ambos os casos, a máquina não toma a decisão sozinha, mas contribui para o piloto tomar.

Quando se automatizam procedimentos nas máquinas, o processo não fica explícito para os homens e eles tendem a confiar demais na automatização. É por isso que a cabine do avião tem tantos displays e controles. Poderia ser tudo automatizado e controlado através de poucos controles, mas devido às experiências fracassadas de outrora, a aviação tenta reduzir ao mínimo a automatização.

Entretanto, talvez a aviação não esteja atenta para os perigos da automatização da ação humana. Quando as pessoas repetem os mesmos procedimentos diversas e diversas vezes, a tendência é que ignorem pequenas variações necessárias, como uma redução da velocidade em função da chuva.

Quando os pilotos perceberam que não ia dar pra parar na pista, era tarde demais. O procedimento padrão é identificar a inadequação para pouso antes de tocar o solo porque, para levantar novamente do solo, é preciso uma velocidade muito mais alta do que quando se pousa. Se, mesmo assim o avião pousa e ultrapassa uma marca na pista, ele é aconselhado a arremeter. Nesse caso, o avião aterrissou antes da marca, mas não conseguiu reduzir o suficiente. Na verdade, o avião acelerou, não se sabe se por intenção do piloto ou mal-funcionamento do reverso.

Se a investigação apontar "erro humano" na operação, devemos considerar se não seriam problemas de usabilidade imprevistos que surgiram na situação de risco e não permitiram a rápida recuperação do problema ou se a automatização induziu ao "erro humano".

Quem quizer saber mais sobre usabilidade em situações críticas, dê uma olhada no blog Confiabilidade humana, mantido pelos pesquisadores da USP.

Fred van Amstel ([email protected]), 19.07.2007

Veja os coment?rios neste endere?o:
http://www.usabilidoido.com.br/acidente_da_tam_pode_ter_sido_causado_por_problemas_de_usabilidade_.html