Embora o artigo “A ironia da Automação”, de Lisanne Bainbridge, tenha sido publicado em 1983, suas reflexões continuam mais atuais do que nunca. Em um mundo onde a automação avança rapidamente, a ideia de que substituir não só operadores humanos por máquinas elimina problemas operacionais se mostra ilusória. Pelo contrário, quanto mais sofisticados os sistemas automatizados, maior a necessidade de intervenção humana qualificada, especialmente em momentos críticos.
Resumo
Este documento discute as maneiras pelas quais a automação dos processos industriais pode expandir, em vez de eliminar, os problemas com o operador humano. Alguns comentários serão feitos sobre métodos para aliviar esses problemas dentro da abordagem “clássica” de deixar o operador responsável por condições anormais e sobre o potencial de uso contínuo do operador humano para a tomada de decisões on-line na colaboração humano-computador.
Ironia: combinação de circunstâncias, cujo resultado é o oposto direto do que se poderia esperar.
Paradoxo: afirmação aparentemente absurda, embora talvez realmente bem fundamentada.
O objetivo clássico da automação é substituir o controle manual humano, o planejamento e a solução de problemas por dispositivos automáticos e computadores. No entanto, como Bibby e colegas (1975) destacam: “mesmo os sistemas altamente automatizados, como as redes de energia elétrica, precisam de seres humanos para supervisão, ajuste, manutenção, expansão e aprimoramento. Portanto, pode-se chegar à conclusão paradoxal de que os sistemas automatizados ainda são sistemas homem-máquina, para os quais tanto os fatores técnicos quanto os humanos são importantes”.
Este documento sugere que o interesse crescente em fatores humanos entre os engenheiros reflete a ironia de que, quanto mais avançado for um sistema de controle, mais crucial poderá ser a contribuição do operador humano. Este documento trata especialmente do controle em indústrias de processo, embora exemplos sejam extraídos da automação de cabines de comando. Nas plantas de processo, os diferentes modos de operação podem ser automatizados em diferentes graus, por exemplo, a operação normal e o desligamento podem ser automáticos, enquanto a partida e as condições anormais são manuais.
Os problemas do uso do controle automático ou manual são uma função da previsibilidade do comportamento do processo, seja qual for o modo de operação. As duas primeiras seções deste artigo discutem o controle automático on-line em que se espera que um operador humano assuma o controle em condições anormais; a última seção apresenta alguns aspectos da colaboração entre homem e computador no controle on-line.
Introdução
As ironias importantes da abordagem clássica da automação estão nas expectativas dos projetistas do sistema e na natureza das tarefas deixadas para os operadores humanos realizarem. A visão do projetista sobre o operador humano pode ser a de que ele não é confiável e é ineficiente, portanto, deve ser eliminado do sistema. Há duas ironias nessa atitude. Uma delas é que os erros do projetista podem ser uma das principais fontes de problemas operacionais. Infelizmente, as pessoas que coletaram dados sobre isso relutam em publicá-los, pois os números reais são difíceis de interpretar. (Alguns tipos de erro podem ser relatados mais prontamente do que outros, e pode haver discordância sobre sua origem). A segunda ironia é que o projetista que tenta eliminar o operador ainda deixa o operador para fazer as tarefas que o projetista não consegue pensar em como automatizar.
É essa abordagem que causa os problemas que serão discutidos aqui, pois significa que o operador pode ser deixado com uma coleção arbitrária de tarefas, e pouca atenção pode ter sido dada ao fornecimento de suporte para elas.
Tarefas após a automação
Há duas categorias gerais de tarefas deixadas para um operador em um sistema automatizado. Espera-se que ele monitore se o sistema automático está operando corretamente e, se não estiver, que chame um operador mais experiente ou que ele mesmo assuma o controle. Discutiremos primeiro as ironias da tomada de controle manual, pois os pontos apresentados também têm implicações para o monitoramento. Assumir o controle e estabilizar o processo requer habilidades de controle manual; diagnosticar a falha como base para o desligamento ou a recuperação requer habilidades cognitivas.
Habilidades de controle manual
Vários estudos (Edwards e Lees, 1974) mostraram a diferença entre operadores de processo inexperientes e experientes que fazem uma mudança de etapa.
O operador experiente executa o número mínimo de ações, e a saída do processo se move suave e rapidamente para o novo nível, enquanto que com um operador inexperiente ela oscila em torno do valor-alvo. Infelizmente, as habilidades físicas se deterioram quando não são usadas, principalmente os refinamentos de ganho e tempo. Isso significa que um operador anteriormente experiente que estava monitorando um processo automatizado pode agora ser um operador inexperiente.
Se ele assumir o controle, poderá colocar o processo em oscilação. Ele pode ter de esperar pelo feedback, em vez de controlar por loop aberto, e será difícil para ele interpretar se o feedback mostra que há algo errado com o sistema ou simplesmente que ele julgou mal sua ação de controle. Ele precisará tomar medidas para neutralizar seu controle ineficaz, o que aumentará sua carga de trabalho. Quando é necessária a tomada de controle manual, é provável que haja algo errado com o processo, de modo que ações incomuns serão necessárias para controlá-lo, e pode-se argumentar que o operador precisa ser mais, e não menos, habilidoso, e menos, e não mais, carregado do que a média.
Habilidades cognitivas.
Conhecimento de longo prazo: Um operador que descobre como controlar a planta por si mesmo, sem treinamento explícito, usa um conjunto de proposições sobre o possível comportamento do processo, a partir do qual ele gera estratégias para tentar (por exemplo, Bainbridge, 1981). Da mesma forma, um operador só será capaz de gerar novas estratégias bem-sucedidas para situações incomuns se tiver um conhecimento adequado do processo.
Há dois problemas com isso para os operadores de “máquina”. Um deles é que a recuperação eficiente do conhecimento da memória de longo prazo depende da frequência de uso (considere qualquer assunto em que você tenha passado em um exame na escola e sobre o qual não tenha pensado desde então).
A outra é que esse tipo de conhecimento só se desenvolve por meio do uso e do feedback sobre sua eficácia. As pessoas que recebem esse conhecimento em aulas teóricas sem exercícios práticos apropriados provavelmente não entenderão muito dele, pois não estará dentro de uma estrutura que o torne significativo, e não se lembrarão muito dele, pois não estará associado a estratégias de recuperação integradas ao restante da tarefa. Há uma certa preocupação de que a geração atual de sistemas automatizados, que são monitorados por antigos operadores manuais, esteja se valendo de suas habilidades, que não se espera que as gerações posteriores de operadores tenham.
Armazenamento de trabalho: O outro aspecto importante das habilidades cognitivas na tomada de decisões on-line é que as decisões são tomadas no contexto do conhecimento do operador sobre o estado atual do processo. Essa é uma forma mais complexa de memória de trabalho do que a noção de um armazenamento de curto prazo com capacidade limitada usado para itens como números de telefone.
O operador tem em sua cabeça (Bainbridge, 1975) não dados brutos sobre o estado do processo, mas resultados de previsões e decisões sobre o processo que serão úteis em situações futuras, incluindo suas ações futuras. Essas informações levam tempo para serem acumuladas. Os operadores manuais podem entrar na sala de controle de um quarto a meia hora antes de assumirem o controle, para que possam ter essa noção do que o processo está fazendo. A implicação disso para a tomada de controle manual de uma planta controlada automaticamente é que o operador que precisa fazer algo rapidamente só pode fazê-lo com base em informações mínimas; ele não poderá tomar decisões com base em um amplo conhecimento do estado da planta até que tenha tido tempo de verificar e pensar sobre isso.
Monitoramento. Pode parecer que o operador, que deve apenas monitorar se os sistemas automáticos estão funcionando corretamente e chamar o supervisor se não estiverem, tem uma tarefa relativamente simples que não apresenta as complexidades acima. Uma complexidade que ela levanta, é claro, é que o supervisor também não poderá assumir o controle se não tiver revisado seu conhecimento relevante ou praticado uma habilidade manual crucial.
Outro problema surge quando se pergunta se o monitoramento pode ser feito por um operador não qualificado. Sabemos, por meio de muitos estudos de “vigilância” (Mackworth, 1950), que é impossível, mesmo para um ser humano altamente motivado, manter a atenção visual efetiva em uma fonte de informações sobre a qual muito pouco acontece, por mais de meia hora. Isso significa que é humanamente impossível realizar a função básica de monitoramento de anormalidades improváveis que, portanto, deve ser feita por um sistema de alarme automático conectado a sinais sonoros. (Os operadores manuais perceberão o comportamento anormal das variáveis que eles observam como parte de sua tarefa de controle, mas podem ser igualmente incapazes de perceber alterações em outras).
Isso levanta a questão de quem percebe quando o sistema de alarme não está funcionando corretamente. Novamente, o operador não monitorará os automáticos de forma eficaz se eles estiverem operando de forma aceitável por um longo período. Infelizmente, as pessoas podem anotar números sem perceber o que eles são. Uma ironia mais séria é que o sistema de controle automático foi instalado porque pode fazer o trabalho melhor do que o operador, mas ainda assim o operador está sendo solicitado a monitorar se ele está funcionando de forma eficaz.
Há dois tipos de problemas com isso. Em modos complexos de operação, o monitor precisa saber qual deve ser o comportamento correto do processo, por exemplo, em processos em lote em que as variáveis precisam seguir uma trajetória específica no tempo. Esse conhecimento requer treinamento especial ou monitores especiais. O segundo problema é que, se as decisões puderem ser totalmente especificadas, um computador poderá tomá-las mais rapidamente, levando em conta mais dimensões e usando critérios especificados com mais precisão do que um operador humano.
Portanto, não há como o operador humano verificar em tempo real se o computador está seguindo suas regras corretamente. Portanto, só se pode esperar que o operador monitore as decisões do computador em algum meta-nível, para decidir se as decisões do computador são “aceitáveis”. Se o computador está sendo usado para tomar as decisões porque o julgamento humano e o raciocínio intuitivo não são adequados nesse contexto, então qual das decisões deve ser aceita? O monitor humano recebeu uma tarefa impossível.
Atitudes do operador. Conheço uma fábrica automatizada em que a gerência precisava estar presente durante o turno da noite, ou os operadores mudariam o processo para “manual”. Isso levanta questões gerais sobre a importância da habilidade para o indivíduo. Um resultado da habilidade é que o operador sabe que pode assumir o controle adequadamente, se necessário. Caso contrário, o trabalho é um dos piores tipos, é muito chato, mas muito responsável, mas não há oportunidade de adquirir ou manter as qualidades necessárias para lidar com a responsabilidade. O nível de habilidade de um trabalhador também é um aspecto importante de seu status, tanto dentro quanto fora da comunidade de trabalho. Se o trabalho for “desqualificado” ao ser reduzido ao monitoramento, é difícil para os indivíduos envolvidos aceitarem esse fato. Isso também leva a ironias de diferenças salariais incongruentes, quando os trabalhadores desqualificados insistem em um alto nível salarial como o símbolo remanescente de um status que não é mais justificado pelo conteúdo do trabalho.
Ekkers e colegas (1979) publicaram um estudo preliminar sobre as correlações entre as características do sistema de controle e a saúde subjetiva e o sentimento de realização dos operadores. Simplificando bastante: a alta coerência das informações do processo, a alta complexidade do processo e a alta controlabilidade do processo (seja manual ou por meio de automação adequada) foram todas associadas a baixos níveis de estresse e carga de trabalho e boa saúde, e o inverso, enquanto a dinâmica rápida do processo e a alta frequência de ações que não podem ser feitas diretamente na interface foram associadas a altos níveis de estresse e carga de trabalho e saúde precária. A alta capacidade de controle do processo, a boa ergonomia da interface e um rico padrão de atividades foram associados a um alto sentimento de realização. Muitos estudos demonstram que altos níveis de estresse levam a erros, enquanto a saúde debilitada e a baixa satisfação no trabalho levam a altos custos indiretos de absenteísmo, etc. (por exemplo, Mobley e colegas, 1979i.b)
Abordagens para soluções. Pode-se afirmar que esses problemas são um paradoxo, pois, ao automatizar o processo, o operador humano recebe uma tarefa que só é possível para alguém que esteja no controle on-line. Esta seção discutirá algumas possíveis soluções para os problemas de manter a eficiência e as habilidades do operador se for esperado que ele monitore e assuma o controle; a próxima seção apresentará propostas recentes para manter o operador humano on-line com suporte de computador. A solução desses problemas envolve a tomada de decisões multidimensionais: aqui serão apresentadas sugestões para discussão. As recomendações em qualquer caso específico dependerão de fatores como o tamanho e a complexidade do processo, a taxa de alteração do processo, a velocidade e a frequência das falhas do processo ou do controle automático, a variabilidade do produto e do ambiente, a simplicidade e o custo do desligamento e as qualidades do operador.
Monitoramento. Em qualquer situação em que um evento de baixa probabilidade deva ser percebido rapidamente, o operador deve receber assistência artificial, se necessário, até mesmo alarmes sobre alarmes. Em um processo com um grande número de loops, não há como o operador humano chegar rapidamente à parte correta da planta sem alarmes e, de preferência, também com alguma forma de análise de alarme. Infelizmente, a proliferação de luzes vermelhas piscantes confundirá em vez de ajudar. Há grandes problemas e ironias no projeto de grandes sistemas de alarme para o operador humano (Rasmussen e Rouse, 1981). Os displays podem ajudar o operador a monitorar o desempenho do controle automático, mostrando os valores-alvo. Isso é simples para faixas de tolerância simples, mas se torna mais complexo se as tolerâncias mudarem durante o processamento em lote.
Uma possível solução é mostrar as tolerâncias apropriadas no momento em um VDU por meio de geração de software. Na verdade, isso não contorna os problemas, mas apenas levanta os mesmos problemas em uma forma diferente. O operador não observará o VDU se houver uma probabilidade muito baixa de falha no controle do computador. Se o computador puder gerar os valores necessários, ele também deverá ser capaz de fazer o monitoramento e os alarmes. E como o operador monitora se o computador está funcionando corretamente ou assume o controle se obviamente não estiver?
Um operador com muita prática no uso de telas geradas por computador pode ter grandes problemas se elas não estiverem mais disponíveis em uma emergência. Uma sugestão irônica, mas sensata, é que os monitores com fio direto sejam usados para as principais informações do processo e os monitores de software para os detalhes quantitativos (Jervis e Pope, 1977). As interrupções “catastróficas” de falhas são relativamente fáceis de identificar. Infelizmente, o controle automático pode “camuflar” a falha do sistema controlando contra as mudanças variáveis, de modo que as tendências não se tornam aparentes até que estejam fora de controle. Isso implica que os sistemas automáticos também devem monitorar movimentos incomuns de variáveis.
A “degradação graciosa” do desempenho é citada na “Lista de Fitts” de qualidades homem-computador como uma vantagem do homem sobre a máquina. Esse não é um aspecto do desempenho humano a ser buscado nos computadores, pois pode gerar problemas com o monitoramento de falhas (por exemplo, Wiener e Curry, 1980); os sistemas automáticos devem falhar obviamente. Se o operador humano precisa monitorar os detalhes da tomada de decisão do computador, então, ironicamente, é necessário que o computador tome essas decisões usando métodos e critérios, e em um ritmo que o operador possa seguir, mesmo que esse não seja o método tecnicamente mais eficiente.
Se isso não for feito, quando o operador não acreditar ou não concordar com o computador, ele não conseguirá rastrear a sequência de decisões do sistema para ver até que ponto ele concorda. Um método para superar os problemas de vigilância que é frequentemente sugerido é aumentar artificialmente a taxa de sinal. No entanto, seria um erro aumentar artificialmente a taxa de falha do computador, pois o operador não confiará no sistema. Ephrath (1980) relatou um estudo no qual o desempenho do sistema era pior com o auxílio do computador, porque o operador tomava as decisões e não confiava no sistema.
Armazenamento de trabalho. Se o operador humano não estiver envolvido no controle on-line, ele não terá conhecimento detalhado do estado atual do sistema. Você pode se perguntar quais são as limitações que isso impõe à possibilidade de controle manual eficaz, seja para estabilização ou desligamento do processo, seja para diagnóstico de falhas.
A solução mais direta quando o desligamento é simples e de baixo custo é o desligamento automático. Os problemas surgem com processos que, devido à complexidade, ao custo ou a outros fatores (por exemplo, uma aeronave no ar), precisam ser estabilizados em vez de desligados. Isso deve ser feito manual ou automaticamente? O desligamento manual pode ser usado se a dinâmica do processo puder ser deixada por vários minutos enquanto o operador analisa o que está acontecendo.
No caso de falhas muito rápidas, em poucos segundos (por exemplo, um reator nuclear de água pressurizada em vez de uma aeronave), quando não há aviso de alterações anteriores, de modo que o armazenamento de trabalho on-line também seria inútil, é necessária uma resposta automática confiável, independentemente do investimento necessário e, se isso não for possível, o processo não deve ser construído se os custos da falha forem inaceitáveis.
Com falhas menos rápidas, pode ser possível “ganhar tempo” com respostas manuais aprendidas demais. Isso requer prática frequente em um simulador de alta fidelidade e um conhecimento suficiente das falhas do sistema para garantir que todas as categorias de falhas sejam cobertas. Se a resposta à falha exigir um número maior de ações separadas do que as que podem ser executadas no tempo disponível, algumas devem ser executadas automaticamente e o restante por um operador altamente experiente.
Conhecimento de longo prazo. Os pontos da seção anterior deixam claro que pode ser importante manter as habilidades manuais. Uma possibilidade é permitir que o operador use o controle manual por um curto período em cada turno. Se essa sugestão for ridícula, você deverá praticar no simulador. Um simulador adequado para ensinar o comportamento básico do processo pode ser muito primitivo. Reações rápidas e precisas só podem ser aprendidas em um simulador de alta fidelidade, portanto, se essas reações forem necessárias, esse é um custo necessário.
Você pode fazer observações semelhantes sobre as habilidades cognitivas de programação e diagnóstico. As representações pictóricas simples são adequadas para o treinamento de alguns tipos de detecção de falhas (Duncan e Shepherd, 1975), mas somente se as falhas puderem ser identificadas a partir da aparência de estado estável do painel de controle, e esperar pelo estado estável é aceitável. Se a detecção de falhas envolver a identificação de alterações ao longo do tempo, serão necessários simuladores dinâmicos para o treinamento (Marshall e Shepherd, 1981).
O treinamento de reconhecimento simples também não é suficiente para desenvolver habilidades para lidar com falhas desconhecidas ou para escolher ações corretivas (Duncan, 1981). Há problemas com o uso de qualquer simulador para treinar situações extremas. As falhas desconhecidas não podem ser simuladas, e o comportamento do sistema pode não ser conhecido para falhas que podem ser previstas, mas que não foram experimentadas. Isso significa que o treinamento deve se preocupar com estratégias gerais em vez de respostas específicas; por exemplo, as simulações podem ser usadas para proporcionar experiência com eventos de baixa probabilidade, que podem ser conhecidos pelo instrutor, mas não pelo aluno.
Ninguém pode ser ensinado sobre propriedades desconhecidas do sistema, mas pode ser ensinado a praticar a solução de problemas com as informações conhecidas. É inadequado esperar que o operador reaja a eventos desconhecidos apenas consultando os procedimentos operacionais. Esses procedimentos não podem abranger todas as possibilidades, portanto, espera-se que o operador os monitore e preencha as lacunas. No entanto, é irônico treinar os operadores para seguir instruções e depois colocá-los no sistema para fornecer inteligência. É claro que, se houver alarmes frequentes ao longo do dia, o operador terá uma grande experiência de controle e reflexão sobre o processo como parte de seu trabalho normal. Talvez a ironia final seja o fato de que são os sistemas automatizados mais bem-sucedidos, com pouca necessidade de intervenção manual, que talvez precisem do maior investimento em treinamento de operadores humanos.
Colaboração entre homem e computador. Ao eliminar as partes fáceis de sua tarefa, a automação pode tornar mais difíceis as tarefa do operador humano. Vários autores (Wiener e Curry, 1980; Rouse, 1981) apontam que a abordagem da “lista de Fitts” para a automação, atribuindo ao homem e à máquina as tarefas em que eles são melhores, não é mais suficiente. Ela não considera a integração do homem e do computador, nem como manter a eficácia do operador humano apoiando suas habilidades e motivação.
Sempre haverá um envolvimento humano substancial com os sistemas automatizados, porque outros critérios além da eficiência estão envolvidos, por exemplo, quando o custo de automatizar alguns modos de operação não é justificado pelo valor do produto, ou porque o público não aceitará sistemas de alto risco sem nenhum componente humano. Isso sugere que os métodos de colaboração entre humanos e computadores precisam ser mais bem desenvolvidos. Definer (1981) lista os possíveis níveis de intervenção humana na tomada de decisões automatizada. Este documento discutirá as possibilidades de intervenção do computador na tomada de decisão humana. Isso inclui instruir ou aconselhar o operador, atenuar seus erros, fornecer telas sofisticadas e ajudá-lo quando a carga de tarefas for alta. Rouse (1981) chama isso de interação homem-computador “encoberta”.
Instruções e orientações. Usar o computador para dar instruções é inadequado se o operador estiver simplesmente atuando como um transdutor, pois o computador poderia muito bem ativar um transdutor mais confiável. Thompson (1981) enumera quatro tipos de orientação sobre: causas subjacentes, importância relativa, ações alternativas disponíveis e como implementar ações. Ao seguir a orientação, as reações do operador serão mais lentas e menos integradas do que se ele próprio pudesse gerar a sequência de atividades; e ele não está praticando a “inteligência”. Também há problemas com a exibição eficiente de informações sobre procedimentos.
Atenuando o erro humano. As possibilidades da máquina para neutralizar o erro humano variam de simples intertravamentos de hardware a computação on-line complexa. Exceto nos casos em que sequências específicas de operações devam ser seguidas, é mais apropriado colocar essas “verificações” nos efeitos das ações, pois isso não faz suposições sobre a estratégia usada para alcançar esse efeito. Sob controle manual, os operadores humanos geralmente obtêm feedback suficiente sobre os resultados de suas ações em poucos segundos para corrigir seus próprios erros (Ruffell-Smith, 1979), mas Wiener e Curry (1980) dão exemplos de humanos que cometem os mesmos tipos de erros ao configurar e monitorar equipamentos automáticos, quando não recebem feedback adequado. Talvez isso deva ser planejado. Kreifeldt e McCarthy (1981) dão conselhos sobre monitores para ajudar os operadores que foram interrompidos no meio da sequência. Rouse (1981) sugere o monitoramento por computador dos movimentos dos olhos humanos para verificar se a varredura do instrumento é adequada, por exemplo, para evitar a visão de túnel.
Monitores gerados por software. A disponibilidade cada vez maior de telas flexíveis em VDUs gera possibilidades fascinantes de projetar telas compatíveis com o conhecimento específico e os processos cognitivos usados em uma tarefa. Isso levou a uma especulação tão rica e criativa que parece um pouco mesquinho apontar que há dificuldades na prática. Uma possibilidade é exibir apenas os dados relevantes para um determinado modo de operação, como inicialização, operações de rotina ou manutenção. No entanto, é preciso ter cuidado, pois é possível que uma interface ideal para condições normais camufle o desenvolvimento de condições anormais (Edwards, 1981).
Goodstein (1981) discutiu as exibições de processo que são compatíveis com diferentes tipos de habilidade do operador, usando uma classificação de três níveis de comportamento sugerida por Rasmussen (1979), ou seja, baseada em habilidade, baseada em regras e baseada em conhecimento. O uso de diferentes tipos de habilidade é, em parte, uma função da experiência do operador, embora os tipos provavelmente não se enquadrem em um continuum simples. Chafin (1981) discutiu como as recomendações de design de interface dependem do fato de o operador ser ingênuo/novato/competente/especialista. Entretanto, ele estava preocupado com o acesso humano a bancos de dados de computadores quando não estava sob pressão de tempo.
A interação homem-máquina sob pressão de tempo levanta problemas especiais. A mudança entre o pensamento baseado em conhecimento e a reação “reflexa” não é apenas uma função da prática, mas também depende da incerteza do ambiente, de modo que os mesmos elementos da tarefa podem ser executados usando diferentes tipos de habilidade em momentos diferentes. Portanto, você pode confundir o operador, em vez de ajudá-lo, se der a ele um visor que seja apenas uma função do seu nível geral de habilidade.
Os operadores que não estão estressados com o tempo, se descobrirem que têm o tipo errado de tela, podem solicitar um nível diferente de informações. Isso aumentaria a carga de trabalho de alguém que está tomando decisões que são acompanhadas por um sistema dinâmico. Rouse (1981) sugeriu, portanto, que o computador poderia identificar o tipo de habilidade que o operador está usando e alterar os visores (ele não diz como isso poderia ser feito). Não sabemos até que ponto os operadores ficariam confusos com as alterações de visor que não estivessem sob seu próprio controle. Ephraph e Young (1981) comentaram que leva tempo para um operador alternar entre os modos de atividade, por exemplo, do monitoramento para o controle, mesmo quando esses modos estão sob seu controle, e supõe-se que os mesmos problemas surgiriam com as mudanças no modo de exibição. Certamente, seria necessário muito cuidado para garantir que os diferentes monitores fossem compatíveis. O artigo recente de Rasmussen e Lind (1981) tratava dos diferentes níveis de abstração em que o operador poderia estar pensando sobre o processo, o que definiria a base de conhecimento a ser exibida. Mais uma vez, embora os operadores evidentemente pensem em diferentes níveis de complexidade e abstração em momentos diferentes, não está claro se eles seriam capazes de usar ou escolher muitas exibições diferentes sob estresse de tempo. Algumas observações foram feitas acima sobre os problemas dos operadores que aprenderam a trabalhar com telas geradas por computador, quando essas telas não estão mais disponíveis em condições anormais.
Pesquisas recentes sobre a memória humana (Craik, 1979) sugerem que quanto mais processamento de significado alguns dados tiverem recebido, mais eficazmente eles serão lembrados. Isso nos faz pensar no quanto o operador aprenderá sobre a estrutura do processo se as informações sobre ele forem apresentadas de forma tão bem-sucedida que ele não precisará pensar a respeito para absorvê-las. Seria certamente irônico se descobríssemos que a tela mais compatível não é a melhor tela a ser apresentada ao operador, afinal! (Como de costume nas decisões de escolha de monitores, isso depende da tarefa a ser realizada. Um monitor altamente compatível sempre favorece reações rápidas. Esses pontos especulam se eles também favorecem a aquisição do conhecimento e das habilidades de raciocínio necessárias em condições anormais).
Alguns pontos práticos podem ser sugeridos. Deve haver pelo menos uma fonte de informações permanentemente disponível para cada tipo de informação que não possa ser simplesmente mapeada em outras, por exemplo, sobre o layout da planta no espaço em oposição à sua topologia funcional. Os operadores não devem ter que alternar entre monitores para obter informações sobre estados anormais em partes do processo diferentes daquelas em que estão pensando no momento, nem entre monitores que fornecem informações necessárias em um processo de decisão.
A pesquisa sobre monitores sofisticados deve se concentrar nos problemas de garantir a compatibilidade entre eles, em vez de descobrir qual monitor independente é o melhor para uma função específica sem considerar sua relação com as informações de outras funções. Para finalizar com um tom mais otimista, os monitores de software oferecem algumas possibilidades interessantes para enriquecer a tarefa do operador, permitindo que ele crie sua própria interface. 3.4. Alívio da carga de trabalho humana. Um computador pode ser usado para reduzir a carga de trabalho humana, seja simplificando as decisões do operador, como acima, seja assumindo parte da tomada de decisões. Ephrath e Young (1981) descobriram que o desempenho geral do controle era melhor com o controle manual de um único loop, mas também era melhor com um piloto automático no ambiente complexo de um simulador de cockpit. Isso sugere que o auxílio é melhor utilizado em cargas de trabalho mais altas. No entanto, o efeito do tipo de auxílio depende do tipo de carga de trabalho. Johannsen e Rouse (1981) descobriram que os pilotos relataram menos profundidade de planejamento sob o piloto automático em condições ambientais anormais, presumivelmente porque o piloto automático estava lidando com as condições, mas mais planejamento em condições de emergência da aeronave, onde eles sugerem que o piloto automático libera o piloto do controle on-line para que ele possa pensar em outras coisas.
Chu e Rouse (1979) estudaram uma situação com o auxílio do computador e do piloto automático. Eles fizeram com que o computador assumisse a tomada de decisões quando o operador tivesse uma fila de um outro item de tarefa a ser tratado e ele estivesse controlando manualmente, ou após uma fila de três itens se o piloto automático estivesse controlando. O estudo de Enstrom e Rouse (1977) deixa claro por que Rouse (1981) comenta que métodos on-line mais sofisticados de adaptação do auxílio do computador à carga de trabalho humana só serão possíveis se os cálculos da carga de trabalho puderem ser feitos em tempo real. (Seria precipitado afirmar que é uma ironia o fato de que o objetivo de auxiliar a capacidade humana limitada tenha levado a computação ao limite de sua capacidade, já que a tecnologia tem uma maneira de acompanhar essas observações).
Enstrom e Rouse também destacam a importância de o ser humano saber com quais tarefas o computador está lidando e como, caso contrário, surgem os mesmos problemas das equipes humanas em que não há uma atribuição clara de responsabilidade. Sinaiko (1972) faz um comentário que enfatiza a importância da percepção do operador humano sobre as habilidades do computador: “Quando as cargas eram leves, o homem parecia disposto a deixar que o computador assumisse a maior parte da responsabilidade da atribuição; quando as cargas eram pesadas, os homens intervinham com muito mais frequência [e] se sobrepunham ao computador”. Evidentemente, além das considerações técnicas, o design do auxílio do computador é um problema multidimensional.
Conclusão. As sugestões engenhosas analisadas na última seção mostram que os seres humanos que trabalham sem pressão de tempo podem ser solucionadores de problemas impressionantes. A dificuldade continua sendo o fato de que eles são menos eficientes quando estão sob pressão de tempo. Espero que este documento tenha deixado claro tanto a ironia de que a automação não está necessariamente eliminando as dificuldades quanto a possibilidade de que resolvê-las exija ainda mais engenhosidade tecnológica do que a automação clássica.
Referências
Bainbridge, L. (1975). The representation of working storage and its use in the organisation of behaviour. In W. T. Singleton and P. Spurgeon (Eds.), Measurement of Human Resources. Taylor and Francis, London, pp. 165–183.
Bainbridge, L. (1981). Mathematical equations or processing routines? In J. Rasmussen and W. B. Rouse (Eds.), op. cit., pp. 259–286.
Bibby, K. S., Margulies, F., Rijnsdorp, J. E., & Withers, R. M. J. (1975). Man’s role in control systems. Proc. 6th IFAC Congress, Boston.
Chafin, R. L. (1981). A model for the control mode man-computer interface. Proc. 17th Ann. Conf. on Manual Control, UCLA. JPL Publication 81-95, pp. 669–682.
Chu, Y. & Rouse, W. B. (1979). Adaptive allocation of decision-making responsibility between human and computer in multitask situations. IEEE Transactions on Systems, Man & Cybernetics, SMC-9, 769.
Craik, F. M. (1979). Human memory. Annual Review of Psychology, 30, 63.
Dellner, W. J. (1981). The user’s role in automated fault detection and system recovery. In J. Rasmussen and W. B. Rouse (Eds.), op. cit., pp. 487–499.
Duncan, K. D. (1981). Training for fault diagnosis in industrial process plant. In J. Rasmussen and W. B. Rouse (Eds.), op. cit., pp. 553–573.
Duncan, K. D. & Shepherd, A. (1975). A simulator and training technique for diagnosing plant failures from control panels. Ergonomics, 18, 627.
Edwards, E. (1981). Current research needs in manual control. Proc. 1st European Annual Conference on Human Decision Making and Manual Control, Delft University, pp. 228–232.
Edwards, E. & Lees, F. P. (Eds.) (1974). The Human Operator in Process Control. Taylor and Francis, London.
Ekkers, C. L., Pasmooij, C. K., Brouwers, A. A. F., & Janusch, A. J. (1979). Human control tasks: A comparative study in different man-machine systems. In J. E. Rijnsdorp (Ed.), Case Studies in Automation Related to Humanization of Work. Pergamon Press, Oxford, pp. 23–29.
Enstrom, K. O. & Rouse, W. B. (1977). Real-time determination of how a human has allocated his attention between control and monitoring tasks. IEEE Transactions on Systems, Man & Cybernetics, SMC-7, 153.
Ephrath, A. R. (1980). Verbal presentation. NATO Symposium on Human Detection and Diagnosis of System Failures, Roskilde, Denmark.
Ephrath, A. R. & Young, L. R. (1981). Monitoring vs. man-in-the-loop detection of aircraft control failures. In J. Rasmussen and W. B. Rouse (Eds.), op. cit., pp. 143–154.
Gaodstein, L. P. (1981). Discriminative display support for process operators. In J. Rasmussen and W. B. Rouse (Eds.), op. cit.
Jervis, M. W. & Pope, R. H. (1977). Trends in operator-process communication development. Central Electricity Generating Board, E/REP/054/77.
Johannsen, G. & Rouse, W. B. (1981). Problem-solving behaviour of pilots in abnormal and emergency situations. Proc. 1st European Annual Conference on Human Decision Making and Manual Control, Delft University, pp. 142–150.
Kreifeldt, J. G. & McCarthy, M. E. (1981). Interruption as a test of the user-computer interface. Proc. 17th Annual Conference on Manual Control, UCLA. JPL Publication 81-95, pp. 655–667.
Mackworth, N. H. (1950). Researches on the measurement of human performance. Reprinted in H. W. Sinaiko (Ed.), Selected Papers on Human Factors in the Design and Use of Control Systems (1961). Dover Publications, New York, pp. 174–331.
Marshall, E. C. & Shepherd, A. (1981). A fault-finding training programme for continuous plant operators. In J. Rasmussen and W. B. Rouse (Eds.), op. cit., pp. 575–588.
Mobley, W. H., Griffeth, R. W., Hand, H. H., & Meglino, B. M. (1979). Review and conceptual analysis of the employee turnover process. Psychological Bulletin, 86, 493.
Rasmussen, J. (1979). On the structure of knowledge—a morphology of mental models in a man-machine system context. Riso National Laboratory, Denmark, RISO-M-2192.
Rasmussen, J. & Lind, M. (1981). Coping with complexity. Proc. 1st European Annual Conference on Human Decision Making and Manual Control, Delft University, pp. 70–91.
Rasmussen, J. & Rouse, W. B. (Eds.) (1981). Human Detection and Diagnosis of System Failures. Plenum Press, New York.
Rouse, W. B. (1981). Human-computer interaction in the control of dynamic systems. Computing Surveys, 13, 71.
Ruffell-Smith, P. (1979). A simulator study of the interaction of pilot workload with errors, vigilance, and decisions. NASA TM-78482.
Sinaiko, H. W. (1972). Human intervention and full automation in control systems. Applied Ergonomics, 3, 3.
Thompson, D. A. (1981). Commercial air crew detection of system failures: state of the art and future trends. In J. Rasmussen and W. B. Rouse (Eds.), op. cit., pp. 37–48.
Wiener, E. L. & Curry, R. E. (1980). Flight-deck automation: promises and problems. Ergonomics, 23, 995.
Autor: Lisanne Bainbridget
Fonte: 1983 International Federation of Automatic Control
Artigo original: https://bit.ly/3XIJO9Z
