Cap. 11 - ATTENTION, TIME-SHARING and WORKLOAD

Livro: Engineering Psychology and Human Performance. (3a. ed)
Autor: Wickens, C. D.; Hollands, J. G.
Editora: Prentice-Hall, 1999

Suponha o COMAIR 5191, do acidente de Lexington relatado mais abaixo, para Atlanta, GA, partindo de Lexington, KY.
Em primeiro lugar, analisando o capítulo pelo seu título, há a questão da falta de atenção da tripulação para o desempenho da tarefa de encontrar a aeronave correta que, como foi visto numa breve transcrição do acidente, não era a que eles deveriam voar. Não tenho aqui como verificar ainda o número de aeronaves que estavam no pátio naquele começo de manhã do dia 27 de agosto passado, pois isso seria um elemento a mais no cumprimento desta tarefa. Podemos conectar o termo "atenção" também às tarefas de check-list pré-vôo ou taxiamento até a cabeceira mantendo a aeronave orientada na linha central da taxiway. Para a explicação do "time-sharing",
poderíamos supor que duas tarefas concorrentes estavam acontecendo simultaneamente: a de taxiar mantendo a orientação das linhas centrais da pista de táxi e fazer o check-list pré-vôo e, assim, por causa da divisão de tarefa, o comandante da aeronave posicionou-a na cabeceira errada. Aqui cabe uma explicação técnica, pois, conforme está expresso no capítulo (p. 440), alguns pesquisadores tendem a definir o conceito de "atenção" como indivisível e, portanto, "dividir atenção" com outra tarefa tornaria-se uma contradição. Desta forma, o autor propõe a idéia de "tempo compartilhado", tradução não oficial para "time-sharing". É importante esclarecer, penso, que a "multi-tarefa" dos sistemas operacionais baseados no POSIX, por exemplo, apenas dão a impressão de atividades, processos ou serviços "rodando" simultaneamente (devido a alocação de prioridades de execução, e suas decorrências, desses serviços, grosso modo expondo, processada pela CPU na casa dos nano-segundos e aí a impressão de simultaneidade) e não servem como metáfora para entendimento do que é proposto na idéia de time-sharing. Nos dois casos citados como exemplo, a performanca no cumprimento da tarefa pretendida está diretamente ligada aos recursos disponíveis para seu cumprimento. É fácil imaginar que, ao alocar todo recurso disponível numa única tarefa, a performance alcançada será potencialmente a máxima possível. Verifica-se, entretanto, que há um instante cuja alocação de recurso não mais interfere na performance. O exemplo a seguir é singelo, porém, pense que ao se fazer café, a partir de certo ponto não adianta mais colocar pó de café no coador para deixá-lo mais forte, por causa de seu ponto de saturação. Já no compartilhamento de tempo entre duas ou mais tarefas, pode-se considerar que a alocação de maior recurso disponível em uma das tarefas pode acarretar em perda de performance na(s) outra(s). Um nivelamento de alocação de recursos, por outro lado, pode não ser a melhor técnica para cumprimento das tarefas concorrentes entre si. Se houver, por exemplo, um comportamento automatizado que pode ser empregado em uma das tarefas, fica mais fácil empregar um maior nível de recurso para cumprimento da(s) outra(s) tarefas. A questão do "esforço dispendido" e "dificuldade" são também variáveis a serem consideradas nesta análise do compartilhamento de tempo no cumprimento de múltiplas tarefas simultâneas (dirigir automóvel e falar ao celular, fazer um check-list pré-vôo enquanto taxia a aeronave, ler um texto enquanto se ouve música com letra ou música instrumental etc). Considerando-se os vários registros que podem ser computados em termos de alocação de recursos disponíveis e performances obtidas chega-se, então, à ferramenta de trabalho que o autor chamou de Performance Resource Function (PRF) (p.447), apresentada num gráfico que espero poder mostrar aqui.

A carga de trabalho, simplificadamente, mas numa versão extremamente aplicável, pode ser definida pela razão entre o tempo ocupado no desempenho das tarefas pretendidas pelo tempo total disponível para isso (p.457). Por outro lado e a partir do desdobramento do PRF, pode-se dizer que a carga de trabalho é definida pela relação entre a fonte de recursos disponíveis e a demanda de tarefas existentes para esses recursos apresentados (p.459). A carga de trabalho, de acordo com o autor, tem uma importância distinta para os projetistas, contrapondo-se com a busca de uma boa performance através do design do projeto, de forma que se deve considerar o quanto de demanda de recursos alocados uma determinada tarefa exige do operador e prevê-la antes de concluir o projeto. Assim, um desafio que se apresenta ao projetista na medição da carga de trabalho está nas ações que não estão à vista e que são necessárias para o cumprimento da(s) tarefa(s) pretendidas. Não há -- até onde entendi e seguindo nossa linha de exemplos -- meios seguros de quantificar a carga cognitiva empregada durante a execução das tarefas, porém sabe-se que elas competem com outras tarefas de percepção e cognição de uma tal maneira que podem ser previstas (predicted) (p.458).

Voltando ao nosso COMAIR 5191, é lícito aplicar, como foi exposto inclusive nas reportagens, ao controlador de tráfego aéreo da Torre de Controle do Aeroporto de Blue Grass, que, a despeito da legislação vigente da FAA, cumpria sozinho as tarefas simultâneas de efetivo controle de tráfego aéreo, de monitoração do radar de vigilância e de atribuições administrativas, no mínimo, com recursos cognitivos negativamente alterados pelas duas horas de sono dentro das nove de descanso que tirou entre um turno e outro.

Lexington Crash, Aug. 27th, 2006.

O acidente no Aeroporto de Blue Grass, em Lexington, KY, é uma sucessão de eventos que não combina com o que conhecemos ser a prática de segurança corrente nos Estados Unidos. À parte os julgamentos, que nesta etapa são necessariamente prematuros, a lista das incongruências é sintomática:

1. após ter sido transportada do hotel até o aeroporto, no amanhacer do dia 27 de agosto, sem que fosse observado qualquer comportamento anormal por parte do motorista de táxi, a tripulação da COMAIR, Capt. Jeffrey Clay, co-piloto James Polehinke e a comissária de bordo Kelly Heyer entrou na aeronave errada;

2. tendo sido autorizada para alinhamento e decolagem na pista ativa, RWY22, o comandante taxiou a aeronave para o alinhamento da pista errada, RWY26;

3. a pista menor, num aeródromo -- um aeroporto sem as facilidades usuais, tais como sala de embarque, check-in etc -- com uma pista cruzada homologada para aeronaves comerciais tem que ter, segundo os padrões da FAA mencionados em uma reportagem sobre o assunto (http://www.aeroblue.org/files/AeroBlue_Lex_200608029.pdf), no mínimo 80% do comprimento da pista principal. No caso de Blue Grass, a RWY26 tinha 50% do comprimento da RWY22;

4. a pista principal, RWY22, segundo uma das reportagens (http://www.cnn.com/2006/US/08/30/plane.crash/index.html), é mais alta no meio de seu cumprimento e faz com que se tenha a impressão que as duas pistas são do mesmo tamanho;

5. a pista de táxi para acesso às cabeceiras 22 ou 26 foi reformada na semana anterior ao acidente e o acesso à cabeceira 22 se fazia por um outro trajeto. Embora a tripulação conhecesse o aeródromo, não estiveram lá durante a ocorrência das modificações. As publicações cartográficas às quais deveriam constar as mudanças não tinham sido ainda publicadas e, duas semanas após o acidente, o que foi publicado não representou ainda todas as modificações efetuadas. A informação aos pilotos era feita por NOTAM - Notice to Airmen, isto é, boletins com duração variável que avisam aos aeronautas as particularidades recentes do aeroporto que não constam de publicações definitivas ou são temporárias o suficiente para não fazerem parte delas (www.cnn.com/2006/US/09/12/comair.crash.ap/index.html);

6. a RWY26 não possuía iluminação alguma e a iluminação de centro de pista também não estava operacional naquela hora. Esta última, caso em funcionamento, poderia ser uma dica para chamar atenção da tripulação;

7. uma olhada mais atenta da tripulação à bússola no painel da cabine da aeronave indicaria estarem voltados para o rumo magnético 260° ao invés dos 220° corretos;

8. do ponto de vista da instrução emAnada do controle de tráfego aéreo ainda não há questionamentos. Mas a FAA, segundo as reportagens, reconhece que o órgão operacional deveria funcionar, segundo suas próprias regras, com dois operadores e os representantes do Sindicato Nacional dos Controladores de Tráfego Aéreo - NATCA - já haviam reclamado dessas condições oficialmente (www.cnn.com/2006/US/09/12/comair.crash.ap/index.html). Não é mandatório, pelo padrão FAA, o controlador de tráffego aéreo acompanhar visualmente a aeronave após tê-la instruído para a decolagem. O controlador do turno estava operacionalmente apto, segundo o NTSB - National transportation Safety Board -, e teve descanso de nove horas entre turnos, quando o exigido são oito horas. Não obstante isso, o controlador dormiu apenas duas horas nesse período de descanso. Reputo que uma queda no seu ritmo circadiano tenha obstruído um estado de vigilância maior que proporcionaria movimentação suficiente para observar a aeronave na pista errada, mesmo não sendo obrigado a tal.

9. aparentemente as condições da aeronave estavam em ordem, segundo a NTSB.

Aplicando o Modelo SHELL - interações entre Software, Hardware, Environment e Liveware (este consigo próprio, por isso aparece duplicado) - à lista de fatores contribuintes acima apresentada, eu descartaria problemas que não fossem Liveware e Enviroment, caso se possa considerar para este último que o meio-ambiente criado para o funcionamento normal do sistema de taxiamento, pouso e decolagem foi alterado.