Todas as manhãs, as fitas de progresso de voo eram impressas em folhas A4 e divididas com recurso a um cortador de papel. A primeira consola radar onde trabalhei era feita de plástico azul e estava repleta de botões vermelhos e amarelos, que brilhavam no escuro. Não havia muito para ver no ecran para além dos limites do sector, rumos de aproximação final e o “blip” da aeronave, juntamente com os códigos 3/A e a informação de altitude do Modo C. Era tudo o que tínhamos e necessitávamos na altura.
[spacer height=”20px”]
Passaram menos de 10 anos e tudo mudou. Hoje, sento-me em frente a um ecran radar de alta resolução, capaz de disponibilizar tanta informação que não sou capaz de a assimilar toda: Áreas e zonas activas, dados meteorológicos, estradas, rios e cidades, SID’s e STAR’s, tabelas com planos de voo, trajectórias planeadas, vectores de velocidade, entre muitas outras coisas. Todas as autorizações dadas aos pilotos são imediatamente visíveis nos ecrans dos sectores adjacentes. Os servidores monitorizam toda a informação em tempo real para me alertar antes que quebras de separação e violações de espaço aéreo ocorram. Posso honestamente dizer que o trabalho se tornou mais prazeroso e menos stressante.
A tecnologia que já estava presente no cockpit de uma aeronave, bateu à porta das salas de operação, mudando completamente a maneira como o nosso trabalho é feito. Isto faz-me pensar: será que estamos cientes dos riscos que a automatização está a introduzir na nossa rotina diária? Seremos capazes de reconhecer as ameaças e evitar as armadilhas que os sistemas computorizados trazem? Percebemos de facto o que se passa “dentro” desses sistemas?
[spacer height=”20px”]
Na tarde de 29 de Setembro de 2006, um Boeing 737 num voo entre Manaus e o Rio de Janeiro (via Brasília) colidiu com um Embraer Legacy 600 que voava na direcção oposta (São José dos Campos para Manaus). O acidente ocorreu em condições visuais (VMC), com ambas as aeronaves niveladas a FL370 sobre a floresta amazónica, ceifando a vida de 154 pessoas. Ocorreu meia hora depois dos controladores terem perdido contacto (Radar e Rádio) com o Embraer. A investigação veio a revelar que a perda de contacto radar se deveu provavelmente à selecção inadvertida, por parte do piloto, do transponder para stand-by. A aeronave continuou então o seu voo autorizado a FL370, na ausência de instruções do CTA para descer para FL360 no ponto estabelecido para esse efeito no plano de voo. Isto deixou os controladores aéreos militares envolvidos “às escuras”, já que sem a indicação em tempo real do Modo C da aeronave, os seus sistemas reverteram-se a apenas apresentar a informação do plano de voo e que supostamente a aeronave estaria a voar. Como resultado, sucessivos sectores ACC viram-se providenciados com a informação de que o Embraer (visível apenas intermitentemente através de radar primário) estaria a voar a FL360. É óbvio que esta não terá sido a causa única da tragédia, mas foi certamente um factor crucial.
Arrisco-me a afirmar que o acidente poderia – ainda hoje também – ter acontecido em qualquer lugar do mundo.
[spacer height=”20px”]
Quantas surpresas esconderão os sistemas de gestão de tráfego aéreo? Compreenderemos completamente o equipamento com que trabalhamos? Suspeito que ninguém sabe a extensão completa dos algoritmos que se vão juntando para criar a lógica dos sistemas informáticos que usamos. Se nem os próprios criadores dos mesmos são capazes de prever todos os cenários que estes enfrentarão no futuro, estarei a exagerar?
Talvez esteja, mas sugiro que tentem responder às seguintes questões:
-A que nível conhecem os computadores que usam?
-Quantas vezes são surpreendidos pelo seu comportamento?
-Conseguem convencer-se que compreendem inteiramente a sua lógica?
-Conseguem usar todas as suas funções de uma forma hábil?
[spacer height=”20px”]
Lembro-me de um dia há uns anos, pouco tempo depois de ter sido introduzido um novo sistema, que nos apercebemos que a mais simples situação nos poderia causar problemas.
Neste caso concreto, 2 controladores estavam a lidar com uma aeronave que voava sem transponder. Graças ao novo sistema, o controlador assistente tinha conseguido correlacionar a informação do primário da aeronave com o seu plano de voo, que supostamente seria uma grande ajuda neste tipo de cenários. Mas, na realidade, rapidamente se tornou óbvio que os efeitos desta função raramente usada não estavam claros para todos os envolvidos, já que era muito difícil distinguir o “pseudo-track” criado desta forma com o que era criado pelo sistema em tempo real baseado na informação do transponder.
Podem imaginar o que a tripulação estaria a pensar ao ouvir na frequência 2 controladores constantemente a pedir-lhes para verificarem o estado do transponder… numa aeronave que não tinha um a bordo.
[spacer height=”20px”]
É óbvio que, enquanto o meu sistema topo de gama estiver a trabalhar como é suposto, não preciso de me preocupar com um grande número de coisas simples.
As minhas acções são mais eficientes e com certeza que, num todo, o sistema é mais seguro. Os problemas surgem quando o computador em si se torna o objecto no qual estou focado: actualizações sem sucesso dos dados de voo, modificações pouco comuns de rota, mostrar/esconder informação, etc… Todas estas acções requerem a nossa atenção e muitas vezes fazem-nos esquecer aquilo que é realmente importante – as aeronaves que vemos no ecran ou através das janelas da Torre de Controlo.
Muitos incidentes/acidentes ocorreram quando os pilotos esqueceram que a sua prioridade era pilotar a aeronave. Agora, os controladores de tráfego aéreo enfrentam um desafio semelhante.
[spacer height=”20px”]
Focarmo-nos na ferramenta ao invés de no trabalho a fazer não é o único problema nos sistemas automatizados. Muitos investigadores apontam que devemos esperar outros, tais como:
-Quebras na consciência do que se está a passar (Situational Awareness) e as consequentes surpresas
Já verificamos nos exemplos acima que os sistemas automatizados, com a sua crescente autonomia, nos podem colocar em situações difíceis. O número de funções e modos de automatização disponíveis tem vindo a crescer. É claro para todos que vamos continuar a ser surpreendidos pelo seu comportamento;
-Níveis de conhecimento requeridos e a necessidade de novas formas de treino
A maioria dos programas de treino actuais não cobre a complexidade de todo o sistema. Ao invés disso, dão-nos apenas uma série de dicas e truques para funcionar com o sistema em condições de rotina. Mas, para podermos antecipar completamente as nossas acções, precisamos de compreender as relações complexas que ocorrem “dentro da caixa”;
-Complacência e confiança na automatização
Os sistemas funcionam bem na maioria do tempo e com isso aprendemos a confiar neles. Mas estaremos realmente preparados para aquilo que se seguirá a uma falha total ou parcial do sistema que usamos?
[spacer height=”20px”]
Há cerca de 2 anos eu e os meus colegas enfrentamos uma falha.
Era uma ocupada tarde de Verão quando recebemos uma chamada a indicar que a base de dados dos planos de voo estava com problemas. Éramos ainda capazes de levar todas as aeronaves aos seus destinos, mas não era possível atribuir novos códigos SSR, pelo que foi decidido que novos voos não poderiam entrar no nosso espaço aéreo.
Estávamos determinados a encontrar uma forma de permitir que as aeronaves em espera descolassem assim que possível e levamos sensivelmente meia hora a arranjar os procedimentos de substituição: todo o tráfego a partir seria mantido em níveis de voo “baixos” (para se manter afastado dos sectores ACC) e foi redireccionado para as FIR’s e TMA’s adjacentes. Toda a coordenação foi feita verbalmente e independentemente para cada aeronave, dado que os dados de voo se tinham tornado irrelevantes. Foram-nos dados alguns códigos SSR (insuficientes) e tínhamos de ter certeza que não eram utilizados mais que uma vez a cada 30 minutos. Tínhamos voltado de novo a ver a importância vital do papel, da caneta e do relógio no controlo de tráfego aéreo. Era completamente seguro, mas longe de ser eficiente.
Esse dia fez-me perceber quantas acções são necessárias para um simples voo do Ponto A ao Ponto B. Lembrou-me de quantas chamadas telefónicas teriam de ser feitas para se alterar um código SSR ou para coordenar uma aeronave a um nível de voo diferente do previsto. Muitas acções que iriam representar razões pelas quais a minha atenção se iria dispersar.
[spacer height=”20px”]
Ao olhar para essa tarde percebi também que uma falha semelhante poderá afectar a segurança das aeronaves. Imaginem os efeitos potenciais de se perder a base de dados de voo de um momento para o outro: será que os procedimentos estão estabelecidos para o que deverá ser feito nessas circunstâncias? Quantas vezes tivemos oportunidade de praticar como lidar com uma falha deste género?
[spacer height=”20px”]
Todos estes problemas são elementos inerentes destes sistemas gigantescos. Não há avanço tecnológico que nos possa livrar destas ameaças e o desenvolvimento contínuo dos mesmos virá introduzir novos desafios.
A única coisa que podemos fazer é preparar-nos, aprendendo como os sistemas automatizados trabalham, que lógica seguem e praticar o que fazer na eventualidade de falharem. Isto fará com que estejamos prontos a responder e, se necessário, trabalhar da forma que há 9 anos era considerada rotina.
[spacer height=”20px”]
Tradução e adaptação João Queirós. 02Abril16. As fotos deste artigo são meramente ilustrativas provenientes dos ficheiros da US Navy Air Traffic Controllers image files.
Artigo original HINDSIGHT MAGAZINE Adrain Bednarek by EuroControl sob autorização para o cavok.pt
Nota: Este artigo contem links embebidos em palavras ou frases a bold, que reencaminham para outros sítios da web de interesse para o assunto do artigo.