No dia 7 de outubro de 2008, o voo 72 da Qantas estava voando alto sobre o Oceano Índico a caminho de Perth, na Austrália Ocidental, quando repentinamente caiu sem aviso. Antes que os pilotos pudessem descobrir o que estava acontecendo, aconteceu de novo - parecia que o avião tinha vontade própria; que o computador no coração do Airbus A330 tinha ficado não confiável.
Embora os pilotos tenham conseguido fazer um pouso de emergência seguro, os violentos arremessos feriram mais de 100 pessoas, algumas delas gravemente, e causaram danos significativos ao mobiliário da cabine.
Os investigadores encarregados de encontrar a causa rastrearam o problema até os dados ruins fornecidos por um computador de bordo chamado Air Data/Inertial Reference Unit, desencadeando uma série de problemas de software que culminaram em um comando automático de 10 graus de nariz para baixo durante o voo de cruzeiro. Como era possível que fantasmas no código pudessem ferir tantas pessoas e ameaçar derrubar um avião de uma das companhias aéreas mais seguras do mundo?
A fonte final do problema se mostrou elusiva, mas os investigadores acreditaram que o voo 72 da Qantas contém lições valiosas sobre o tipo de risco de segurança que se tornará cada vez mais comum à medida que os aviões se tornam mais complexos.
O voo 72 da Qantas era um serviço regular programado com a companhia aérea nacional da Austrália de Cingapura para Perth, na Austrália Ocidental. Operado pelo Airbus A330-303, prefixo VH-QPA (foto acima), um avião de fuselagem larga, o voo partiu de Cingapura às 9h32, horário local, com 303 passageiros e 12 tripulantes a bordo, com destino ao sul através do Oceano Índico.
No comando estavam o capitão Kevin Sullivan e o primeiro oficial Peter Lipsett, ambos com mais de 10.000 horas de voo. Um terceiro piloto, o segundo oficial Ross Hales, também estava voando para que os pilotos pudessem alternar os intervalos de descanso durante o voo. Na metade da jornada, o primeiro oficial Lipsett cedeu seu lugar ao segundo oficial Hales e fez seu intervalo de descanso. Era 12h39.
No fundo do compartimento de aviônicos do A330, uma falha apareceu em um dispositivo chamado número um Air Data/Inertial Reference Unit, ou ADIRU 1 para breve.
O A330 tem três ADIRUs, cada um dos quais conectado a um conjunto independente de sensores que medem uma ampla gama de parâmetros, incluindo velocidade do ar; altitude; e ângulo de ataque (AOA), a medida do ângulo de inclinação em relação ao fluxo de ar.
Os ADIRUs processam essas informações e as fornecem aos computadores de voo na forma de “palavras” de 32 bits codificadas em binário. Cada “bit” é uma unidade de informação com dois estados binários, um ou zero, aos quais são atribuídos significados diferentes dependendo de sua posição na palavra de 32 bits.
Uma palavra enviada do ADIRU para o computador de voo contém um rótulo de 8 bits que significa que tipo de informação está sendo transmitida (velocidade do ar, altitude, etc.); um identificador de origem/destino de 2 bits que indica de onde as informações estão vindo e para onde estão indo; até 19 bits de dados reais medidos; um indicador de status de 2 bits que indica se os dados são válidos ou não; e um indicador de paridade de 1 bit que faz com que o computador de destino rejeite a palavra se ela contiver o número errado de zeros e uns.
De particular interesse é a seção de dados de 19 bits. Cada bit na sequência de 19 bits é atribuído a um número específico, sempre duas vezes o número anterior, que muda dependendo do parâmetro que está sendo medido.
Por exemplo, no parâmetro de altitude, o bit # 12 é sempre um pé, o bit # 13 é sempre dois pés, o bit # 14 é sempre quatro pés e assim por diante. Um valor de altitude é codificado como uma soma desses números; os números usados na soma são indicados alterando o valor binário do bit associado de zero para um.
Por exemplo, a altitude de cruzeiro do voo 72 de 37.012 pés pode ser indicada com um valor binário de um nos bits # 27 (32.768 pés), # 24 (4.096 pés), # 19 (128 pés) e# 15 (8 pés), com todos os outros bits na seção de dados definidos para um valor binário de zero.
O que aconteceu exatamente dentro do ADIRU 1 a bordo do voo 72 exatamente às 12h40 é desconhecido até hoje. Mas, embora o evento desencadeador seja um mistério, o efeito que teve sobre os dados disponibilizados por este ADIRU foi notável.
Assim que o erro ocorreu, o ADIRU começou a enviar rajadas de dados erroneamente rotulados - dados em que as informações de altitude possuíam a sequência de rótulo de 8 bits correspondente à velocidade do ar ou AOA.
Como o valor exato dos dados codificados na palavra depende do tipo de dado como o rotulado, a informação foi corrompida. Os bits específicos que foram definidos com um valor binário de um para somar à altitude da aeronave permaneceram definidos como tal, mas agora representavam o número correspondente em um parâmetro diferente.
Considere o exemplo anterior com uma altitude medida de 37.012 pés. Para somar 37.012 pés, bits# 27 , # 24 , # 19 e # 15 receberam um valor binário de um. No entanto, na escala usada para dados AOA, esses mesmos bits correspondiam a valores que somavam um total de 50.625 graus.
Assim que o erro ocorreu, o ADIRU 1 começou a enviar intermitentemente esses dados errados para os computadores de voo. Mas esse não foi o único problema. Alguns dos dados falsos foram usados como ponto de referência para calcular o próximo lote, corrompendo “palavras” futuras também.
Alguns parâmetros que dependiam dos parâmetros corrompidos foram corrompidos, assim como os “relatórios de status” periódicos emitidos pelo ADIRU, que indicavam se vários sistemas estavam funcionando ou não.
Embora nenhum mecanismo que explicasse conclusivamente todos os tipos de dados corrompidos tenha sido encontrado, a origem do problema pode ter sido a CPU ADIRU cometer erros ao ler valores armazenados em sua memória de acesso aleatório.
O recurso integrado que rotulava os dados como válidos ou inválidos não detectou o problema porque a corrupção ocorreu durante o processo de montagem de palavras, após as verificações terem sido realizadas.
Muitos dos dados corrompidos também passaram por verificações adicionais, ou essas verificações falharam; por exemplo, o computador sempre verificava os dados AOA para garantir que eram compatíveis com a velocidade e o ângulo de inclinação medidos do avião. Mas, como esses parâmetros também foram corrompidos, a verificação não funcionou.
Na outra extremidade, o computador recebia dados de todas as três ADIRUs, incluindo as duas que estavam funcionando normalmente, e comparava constantemente suas saídas para garantir consistência e detectar dados falsos.
A cada período de um segundo, o computador fez 25 comparações dos valores AOA emitidos pelos três ADIRUs, calculou o valor mediano em cada intervalo de amostragem e descartou os dados AOA de qualquer ADIRU cujas saídas estavam consistentemente muito longe da mediana durante o curso do período de um segundo.
No caso de um valor AOA diferir significativamente da mediana no início do intervalo de um segundo, o computador "lembraria" os últimos dados válidos enviados desse ADIRU e os usaria em seus cálculos por 1,2 segundos antes de amostrar novamente. Mas havia uma falha oculta neste processo.
Se um "pico" de dados AOA inválidos ocorresse no início do período de comparação de um segundo, desaparecesse e retornasse dentro de 0,2 segundos após o final do período de comparação, o período de memorização de 1,2 segundo seria acionado, mas o computador não rejeitar as saídas AOA do ADIRU porque elas não eram inválidas durante todo o período de um segundo.
Então, quando o período de memorização terminou e o computador fez uma nova amostragem dos dados, a saída era inválida novamente, mas seria tratada como válida porque a saída acabara de passar no teste de comparação.
O computador presumiu que, se o teste tivesse passado, qualquer valor recebido após o fim do teste seria necessariamente válido e usou esse valor em seu próximo cálculo do ângulo de ataque real do avião.
Por este método, a enxurrada de dados ruins do ADIRU 1 (e, em particular, os dados AOA ruins) passaram por todas as proteções destinadas a filtrá-los. Os dados ruins foram então usados pelo computador de voo em seus cálculos.
Na cabine, os pilotos notaram os efeitos dos dados ruins segundos após sua criação. Em primeiro lugar, o piloto automático se desconectou, pois se mostrou incapaz de reconciliar as diferenças nos dados que estava recebendo dos três ADIRUs.
O Capitão Sullivan anunciou imediatamente que tinha controle manual. Menos de cinco segundos depois, os pilotos se viram bombardeados por uma súbita cascata de avisos acionados por dados errados e corrompidos.
Mensagens de falha inundaram a tela do computador no console central, e os avisos de "estol" e "excesso de velocidade" começaram a disparar intermitentemente - uma combinação obviamente impossível, considerando que um indicava que eles estavam voando muito devagar e o outro indicava que eles estavam voando também velozes!
O Capitão Sullivan tentou engajar o segundo piloto automático reserva do A330. Ao mesmo tempo, os valores de velocidade e altitude no visor de voo de Sullivan, que fornece seus dados do ADIRU 1, pareceram enlouquecer, flutuando descontroladamente de uma maneira completamente inconsistente com o nível da aeronave e trajetória dócil.
Uma mensagem de falha e uma luz de advertência associadas à unidade de referência inercial número um (parte do ADIRU 1) também dispararam. Em resposta às indicações não confiáveis de velocidade do ar, Sullivan desligou o piloto automático e voou com o avião manualmente usando os instrumentos de espera no console central.
Totalmente perplexo com a cascata de avisos aparentemente falsos, o capitão Sullivan e o segundo oficial Hales chamaram o primeiro oficial Lipsett de volta à cabine para ajudar a descobrir o que estava acontecendo.
Mas antes que Lipsett chegasse à cabine do piloto, a sequência de eventos que se desenrolavam no reino da informação repentinamente invadiu o mundo real. Um pico de dados de altitude erroneamente rotulados como dados AOA e marcados como válidos pelo computador de voo acionou duas condições de emergência separadas das chamadas proteções de piso alfa do A330.
As proteções de piso do Alpha, uma parte central da filosofia de projeto da Airbus, são limites impostos à inclinação, ângulo de ataque, velocidade do ar e ângulo de inclinação que desencadearão ações corretivas automáticas quando excedidos.
Essas proteções normalmente evitam que os pilotos façam entradas de controle que possam colocar o avião em uma atitude perigosa, e corrigem uma atitude perigosa se uma delas ocorrer. Mas os dados defeituosos acionaram incorretamente duas das proteções do piso alfa, embora a aeronave estivesse em uma atitude normal para voo de cruzeiro.
Um sistema denominado "proteção AOA alta" detectou um ângulo de ataque excessivamente alto (proveniente do ADIRU 1 defeituoso) e aplicou uma entrada de elevador de nariz para baixo de 4 graus, o máximo que poderia comandar, para ajudar a trazer o AOA de volta aos limites.
Exatamente ao mesmo tempo, os mesmos dados ruins acionaram um sistema separado denominado “compensação anti-pitch up”, que se destina a neutralizar a tendência do A330 de se inclinar ao voar em alta velocidade e alto ângulo de ataque. Este sistema aplicou uma entrada de elevador de nariz descendente de 6 graus, que também passou a ser o máximo que ele poderia comandar. Os dois comandos de nariz para baixo foram aditivos, juntos aplicando um movimento súbito de 10 graus com o nariz para baixo.
O efeito de um comando de 10 graus para baixo do nariz durante o voo de cruzeiro foi repentino e catastrófico. O avião mergulhou imediatamente, arremessando no teto qualquer pessoa e qualquer coisa que não estivesse amarrada.
Pelo menos 60 passageiros sentados não usavam cintos de segurança, e as forças G negativas os jogaram de cabeça para baixo nas unidades de serviço de passageiros no fundo dos compartimentos superiores.
Vários outros, incluindo a maioria da tripulação e cerca de 20 passageiros, estavam fora de seus assentos, desempenhando várias funções ou indo para os banheiros. Eles também se viram atirados contra o teto com grande força.
Os compartimentos de bagagem se abriram, espalhando malas e mochilas pelos corredores. Bebidas, comida, laptops, livros e outros itens soltos voaram em todas as direções. Na cabine, os pilotos foram puxados para cima e para fora de seus assentos, contido apenas por seus cintos de segurança.
O Capitão Sullivan alcançou seu manche lateral para tirar a aeronave do mergulho, mas quando ele tentou trazer o nariz para cima, não houve resposta; os sistemas automáticos o haviam bloqueado. Ele me soltou e tentou novamente. Desta vez, como o pico de dados acabou, os elevadores responderam e o avião começou a nivelar.
À medida que as forças G negativas diminuíam, todos na cabine que estavam presos ao teto desabaram de novo. Pessoas bateram no chão, nos assentos e em outros passageiros, caindo em meio a uma confusão caótica de objetos aleatórios.
Ainda se recuperando do choque do transtorno, os passageiros e a tripulação fizeram um balanço da situação. A manobra violenta causou ferimentos generalizados - havia ossos quebrados, contusões, lacerações graves e muito mais.
Todos os comissários de bordo ficaram feridos em vários graus. Uma pessoa quebrou uma perna, vários sofreram graves ferimentos na coluna e muitos estavam sangrando profusamente. O primeiro oficial Lipsett, que estava a caminho da cabine, quebrou o nariz.
Agora de volta ao controle, Sullivan e Hales, que não se machucaram, começaram a tentar limpar todas as mensagens de erro na tela do computador. As notificações de falha afetaram uma grande variedade de sistemas, e muitos deles não exigiam nenhuma ação, mas a que continuava aparecendo, independentemente do que eles fizessem, era a mesma falha “NAV IR 1” que receberam anteriormente.
E enquanto eles trabalhavam, os avisos de estol e velocidade excessiva continuavam a soar. O segundo oficial Hales fez um anúncio pelo sistema de som, pedindo a todos os passageiros e tripulantes que se sentassem e colocassem os cintos de segurança imediatamente.
De repente, outro pico de dados ruins do AOA chegou ao computador de voo. Embora a desconexão do piloto automático tenha alterado a lógica do piso alfa, removendo a proteção AOA alta, o sistema de compensação anti-pitch up permaneceu ativo e foi acionado novamente.
Desta vez, o mergulho não foi tão acentuado e a maioria das pessoas tinha colocado os cintos de segurança, mas alguns que haviam se machucado ou tentavam ajudar os outros não, e foram jogados no teto novamente. Assim como da primeira vez, os esforços iniciais de Sullivan para subir não surtiram efeito; e assim como da primeira vez, a resistência diminuiu após alguns segundos e ele conseguiu nivelar o avião.
Uma queda repentina era uma coisa, mas duas diminuições repentinas eram outra bem diferente. Com todos os tipos de alarmes ligados e desligados em segundo plano e novas mensagens de erro aparecendo constantemente, a tripulação não tinha certeza do que estava acontecendo e temia que pudesse mergulhar novamente a qualquer momento. Um desembarque imediato em Learmonth, na Austrália Ocidental, parecia a melhor opção.
Lipsett, apesar do nariz quebrado, finalmente conseguiu chegar à cabine e assumir o lugar de Hales. Ele relatou que também havia feridos entre os passageiros. Neste momento, Sullivan notou que a guarnição do estabilizador automatizado não estava funcionando; a guarnição teria que ser ajustada manualmente.
O equipamento de navegação também não funcionava e eles não podiam interagir com a interface do computador. Sullivan declarou um pan-pan-pan, um nível abaixo de um mayday, e informou aos controladores que o voo 72 estava indo para Learmonth com “problemas no computador de voo”.
Depois de receber a palavra dos comissários de bordo de que havia vários ossos quebrados, lacerações e outros ferimentos, ele atualizou isso para um socorro completo e solicitou que as ambulâncias encontrassem a aeronave após o pouso.
Os pilotos voaram o restante do voo em modo totalmente manual, tentando ignorar os alarmes espúrios constantes que se recusavam a desligar. O primeiro oficial Lipsett ligou para a manutenção da Qantas em Sydney pelo sistema de comunicação por satélite para tentar obter ajuda para resolver a situação, mas eles também não conseguiram descobrir o que estava errado. No entanto, as quedas repentinas nunca mais voltaram, e o voo 72 pousou em segurança em Learmonth às 13h32.
Ao todo, pelo menos 119 dos 315 passageiros e tripulantes ficaram feridos, 12 deles gravemente. O interior da cabine estava totalmente destruído. Painéis de teto foram quebrados, unidades de serviço de passageiros destruídas, compartimentos superiores arrancados do alinhamento. Lixo, comida, sangue e bebidas derramadas espalhadas pelo chão.
E embora o avião voasse novamente e ninguém morresse, muitas pessoas sofreram ferimentos que ficarão com eles pelo resto de suas vidas - tudo por causa de alguns "fantasmas no código".
Os investigadores do Australian Transportation Safety Board tiveram que perguntar: como tal coisa pôde acontecer? Acontece que não foi a primeira vez que esse tipo de erro ocorreu. Outro A330 da Qantas experimentou um problema de dados semelhante em 2006, também na costa da Austrália Ocidental. E em dezembro de 2008, aconteceu novamente em outro voo da Qantas fora da Austrália Ocidental.
Nenhum desses outros dois casos envolveu um pitch down não comandado, mas o modo de falha do ADIRU em todos os três incidentes foi semelhante, e dois deles envolveram até mesmo o mesmo ADIRU.
O fato de que todas essas falhas ocorreram dentro de uma pequena região geográfica parecia muito estranho para ser uma coincidência, mas apesar de uma variedade de teorias e de um apelo da Australian and International Pilots Association para proibir voos sobre a área, os investigadores não conseguiram encontrar nada inerente a Austrália Ocidental que pode ter causado o mau funcionamento.
Na verdade, o ATSB nunca foi capaz de descobrir de forma conclusiva o que fez com que o ADIRU começasse a enviar dados falsos e com rótulos incorretos. Apenas uma teoria não poderia ser descartada: um efeito de evento único, ou SEE para breve.
A SEE ocorre quando uma partícula de alta energia do espaço sideral, como um nêutron, atinge um chip de computador e altera aleatoriamente uma chave binária de um para zero ou zero para um. Se um SEE ocorreu em um local crítico dentro do módulo de memória da CPU ADIRU, ele poderia, apenas talvez, ter acionado tudo o que se seguiu.
O ATSB não foi capaz de encontrar evidências para provar ou refutar a teoria, mas o fato de os dois ADIRUs que experimentaram este tipo de mau funcionamento estarem próximos um do outro em número de série sugeriu que pode ter havido alguma falha de hardware mínima naquele lote de ADIRUs que os tornou mais suscetíveis a um SEE.
O que tornou a falha do ADIRU perigosa não foi que ela falhou em si, mas que os dados inválidos passaram por várias camadas de verificações cruzadas sem serem sinalizados como tal. Se os picos de dados tivessem sido sinalizados como inválidos em algum ponto do processo, o computador os teria desconsiderado e a segurança do voo nunca teria sido comprometida.
A investigação encontrou um modo de falha até então desconhecido, no qual picos de dados ocorrendo aproximadamente a cada 1,2 segundos podem levar o computador a pensar que dados ruins são reais. Era aí que residia o verdadeiro problema de segurança.
Pode não ser possível evitar que alguns zeros e zeros sejam corrompidos de vez em quando, mas se as proteções em camadas nem sempre conseguissem detectar os dados corrompidos, isso representava um risco à segurança. Essas proteções eram boas - o próprio ADIRU poderia eliminar 93. 5% de dados inválidos por conta própria antes que o computador fizesse sua verificação cruzada - mas isso não foi suficiente para evitar que um pouco de código incompatível ferisse 119 pessoas.
Em princípio, entretanto, o ADIRU permaneceu completamente seguro. Este tipo de falha ocorreu apenas três vezes em 128 milhões de horas de serviço para este modelo de ADIRU, bem dentro da zona de probabilidade que os reguladores consideram “extremamente remota”.
Um ângulo final que o ATSB buscou foi a taxa de uso do cinto de segurança entre os passageiros das companhias aéreas. Durante os dois distúrbios durante o voo, passageiros sem restrições colidiram com o teto e contra outros passageiros, causando ferimentos não apenas a si próprios, mas também a outras pessoas que estavam usando os cintos de segurança e não teriam se machucado.
Embora alguns fatores pudessem estar relacionados com o uso mais baixo do cinto de segurança, não havia uma razão universal para que as pessoas optassem por não usá-lo. Fazer com que as pessoas usem o cinto de segurança quando o sinal do cinto de segurança não está colocado é um desafio que as companhias aéreas enfrentam há décadas.
Conectar o cinto de segurança o tempo todo não é uma solução prática porque as pessoas ficariam complacentes com sua presença e ignorariam o cinto com taxas mais altas do que antes. Os investigadores decidiram que mais pesquisas teriam que ser feitas para encontrar as maneiras mais eficazes de contornar esse paradoxo.
Em seu relatório final, o ATSB escreveu que a investigação foi extremamente difícil e tocou em várias áreas onde nenhuma investigação de acidente aéreo havia se aventurado antes. Os autores do relatório também estavam cientes de que o incidente do voo 72 da Qantas pode ser representativo do tipo de caso que se tornará cada vez mais comum na era moderna.
“Dada a complexidade crescente dos sistemas [de aeronaves]”, escreveram eles, “esta investigação ofereceu uma visão sobre os tipos de problemas que se tornarão relevantes para investigações futuras”.
Poucos dias após o acidente, a Airbus emitiu um boletim para todos os operadores do A330 instruindo os pilotos a desligar imediatamente o ADIRU indicado ao receber uma falha “NAV IR”. Este conselho pode ter evitado um acidente semelhante em dezembro daquele ano, quando os pilotos do voo 71 da Qantas experimentaram um defeito idêntico no ADIRU, mas desligaram a unidade afetada após apenas 28 segundos.
As autoridades regulatórias em todo o mundo reeditaram este boletim da Airbus como uma diretiva de aeronavegabilidade, tornando-o uma regra oficial. A Airbus também redesenhou a lógica usada pelo computador de voo para verificar os dados AOA, eliminando a possibilidade de que picos de dados oportunos passassem pela verificação cruzada.
Além disso, a Airbus começou a incluir novas maneiras de testar seu software de verificação de dados, incluindo testes com picos de dados intermitentes, que não haviam sido tentados anteriormente.
No entanto, o ATSB encontrou um problema: embora o evento que precipitou essa falha fosse tão raro que o ADIRU ainda atendesse a todas as diretrizes de segurança razoáveis, ele representou apenas um exemplo de corrupção nas vastas quantidades de informações sendo processadas dentro dos muitos computadores de uma aeronave.
Que outras lacunas podem existir que podem fazer com que um bug de software, um SEE ou outras fontes de dados inválidos se manifestem de maneiras perigosas? Como esses eventos poderiam ser previstos?
Uma maneira era atacar uma das fontes suspeitas de erros: os SEEs. Após o acidente da Qantas, a Agência Europeia para a Segurança da Aviação começou a pedir aos fabricantes de computadores para aeronaves que levassem em consideração os SEEs durante a fase de projeto para tornar seus produtos menos suscetíveis.
No momento da publicação do relatório, a Administração Federal de Aviação dos Estados Unidos ainda estava pesquisando as melhores maneiras de abordar o problema. Hoje, a compreensão das implicações desse fenômeno para a segurança ainda está em desenvolvimento.
No entanto, o voo 72 da Qantas se destaca como o primeiro caso em que os investigadores investigaram profundamente uma falha grave de software - e serve como um lembrete da importância de manter o cinto de segurança preso o tempo todo.
Edição de texto e imagens por Jorge Tadeu (Site Desastres Aéreos)
Com Admiral Cloudberg, Wikipedia, ASN e The Aviation Herald - Imagens: AAPIMAGE, Wikipedia, Australian Transportation Safety Board, News.com.au, Sydney Morning Herald, ABC, New Zealand Herald e Masakatsu Ukon. Clipes de vídeo cortesia de Mayday (Cineflix).
Nenhum comentário:
Postar um comentário