Confiabilidade humana - PCS5006

25.9.08

Primeira atividade

Benvindos srs e sras participantes da terceira edição do curso de Confiabilidade Humana para projeto da IHC de sistemas críticos! Seguem as instruções para o primeiro artigo, a ser entregue em formato digital - .doc ou .pdf - em 08/10/2008. O modelo para o artigo é o da ACM: http://www.acm.org/sigs/publications/pubform.doc

1. Introdução
- explique por que o ser humano é importante na sua pesquisa.
- caracterize o ser humano alvo do seu projeto de pesquisa, em termos de papel e de perfil (para saber a diferença, consulte a bibliografia de PCS5756 ou o artigo [Aquino Junior e Filgueiras, 2005] http://doi.acm.org/10.1145/1111360.1111388


2. <>
Resuma o capítulo do Wickens&Holland que lhe foi atribuído, destacando o fator humano mais relevante para o seu projeto de pesquisa. Estenda a pesquisa, lendo outros autores sobre esse fator. Esta seção do artigo deverá comunicar, aos colegas do curso e aos leitores em geral, o que é importante saber sobre esse fator humano.

3. na
- explique o seu projeto de pesquisa e mostre por que a participação desse ser humano é relevante no projeto.
- relacione o fator humano estudado ao seu projeto de pesquisa.
4. Conclusões
Referências
Os artigos serão avaliados em função da pesquisa realizada e distribuídos para os colegas terem conhecimento dos vários fatores humanos estudados. Os melhores trabalhos serão selecionados para apresentação no fim do curso.

22.10.06

Tarefas para a aula de 27/10

Pessoal,
Na próxima aula, vamos discutir o erro humano em metade da aula; na outra metade, vamos conversar um pouco sobre análise de tarefas. Vou pedir para vocês lerem os seguintes artigos:

Handbook of Human Factors and Ergonomic Methods, Chapter 33: Hierarchical Task Analysis (HTA) - John Annett

http://www.useit.com/papers/goalcomposition.html
Neste ensaio sobre tarefas, Nielsen discute como pensar no que as pessoas podem fazer a partir do uso do sistema. É interessante para pensarmos como o usuário inova no uso das funções de um sistema.

http://giove.cnuce.cnr.it/CTTE/tse-published.pdf
Este artigo descreve a ferramenta que usaremos para documentar as tarefas.

Até lá!

5.10.06

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.

29.9.06

Definições e características do desempenho humano

Na aula de 06/10, vamos discutir algumas definições essenciais para criarmos uma linguagem comum. Para isso, peço que todos leiam o seguinte artigo:

Avizienis, A. et al. ;Basic Concepts and Taxonomy of Dependable and Secure Computing. IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING, VOL. 1, NO. 1, JANUARY-MARCH 2004

Começaremos a aula por uma definição destes termos na área de confiabilidade humana. Em seguida, faremos uma discussão sobre algumas características do desempenho humano, usando para isso o seguinte livro:

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

A seguir, capítulos e seus respectivos responsáveis:

Rafael Gasparetti - Signal Detection, Information Theory and Absolute Judgement
Victor Furtado - Attention in Perception and Display Space
Moacyr Cardoso - Spatial Displays
Eduardo Giannoto - Navigation and Interaction in Real and Virtual Environments
Olivia Korehisa - Language and Communications
Adilson Oliveira - Memory and Training
Denise Gastaldo - Decision Making
Leôncio Barros - Selection of Action
Maria Cristina Toledo - Manual Control
Paulo Roberto - Complex Systems, Process Control and Automation
Bemildo Ferreira - Attention, Time-Sharing and Workload

Por favor, resumam as principais idéias de cada capítulo e identifiquem, nos acidentes estudados na aula anterior, as circunstâncias que evidenciam as características humanas estudadas.

Até breve!
Lucia

26.9.06

Pesquisa de acidentes para dia 29/09

Prezados,
Peço que vocês estudem com cuidado os seguintes acidentes e façam:
1. um resumo do ocorrido, com ilustrações, etc.
2. uma linha do tempo que evidencie a seqüência de acontecimentos. Ela deve conter a indicação de todos os eventos que vocês acharem relevantes para a compreensão do acidente.
3. a identificação dos fatores humanos que contribuíram para o acidente. Identifiquem problemas nas interfaces entre o ser humano e seu ambiente (modelo SHELL).
4. destacar o evento do acidente na linha do tempo
5. ações pós-acidente são opcionais mas muito bem-vindas.

O material deve ser uma apresentação para ser mostrada aos colegas e discutida na aula. Cada grupo terá 20 minutos para apresentar.

Sorteei os acidentes e os grupos para esta primeira aula. A referência enviada por email é um material base, mas vocês devem buscar mais informações para completar a tarefa.


Rafael Gasparetti e Victor Furtado – RG254
Moacyr Cardoso e Eduardo Giannoto – KLM/PANAM, Tenerife
Olivia Korehisa e Adilson Oliveira – Therac 25
Denise Gastaldo e Leôncio Barros – Chernobyl
Maria Cristina Toledo e Paulo Roberto – TMI

Nosso convidado Bemildo deve trazer o acidente de Lexington.
Obrigada!
Lucia

Boas vindas

Em primeiro lugar, sejam bem-vindos os novos alunos da disciplina PCS5006 ao grupo de estudo de confiabilidade humana. Este é um grupo que se reúne há um ano nas sextas à tarde, alguns dias com mais interessados, outros com menos, mas sempre ativo.

Retomando um post antigo:

o foco do grupo de estudo é a Confiabilidade Humana como parâmetro de projeto da interação homem-computador (IHC) de sistemas críticos, dando subsídio para as fases de concepção, desenvolvimento e avaliação destes sistemas.

Pretendemos estabelecer os conceitos e pesquisas técnicas para melhorar o acoplamento dos sistemas à estrutura social da operação. As reuniões serão usadas para apresentação e discussão dos resultados das pesquisas.

Regras de participação

Este é um grupo de estudo, em primeiro lugar. É uma oportunidade de troca de idéias sobre um tema de interesse comum. Fora do período letivo, que vai de setembro a dezembro de cada ano, interessados podem se vincular ao grupo, contribuindo para os estudos através de leituras, pesquisas específicas, produção bibliográfica e principalmente, com a presença nas discussões.

A participação é formalizada em uma disciplina de pós-graduação (PCS5006). Os alunos regularmente matriculados receberão créditos pela participação se não faltarem a mais que três aulas (nota C na terceira falta) e se cumprirem as tarefas atribuídas. Espera-se, no entanto, que a participação seja continuada, mesmo fora do período de oferecimento da disciplina!

Nossos tópicos de 2006

O conjunto de temas é grande. Já há alguns temas tratados em postagens anteriores neste blog. Neste ano, pretendo fazer um estudo mais detalhado de algumas técnicas de análise de confiabilidade humana, ensaiando o que tem sido proposto na literatura em uma situação real, já que este ano contamos com um especialista em controle de tráfego aéreo.

Postagens

Todos os trabalhos apresentados em aula devem ser postados neste blog!


Até sexta,
Lucia

25.11.05

Vídeos da NASA - Confiabilidade Humana - Fatores Humanos

Este site contém uma série de vídeos, onde um cientista da NASA comenta sobre a importância de se estudar Human Factors e Human Reliability.

Assisti alguns e são bastante interessantes.

Abraços,

Galba

12.11.05

CREAM - Cognitive Reliability and Error Analysis

Estou postando um resumo sobre o CREAM. Tentei exemplificar, da melhor forma que encontrei, um exempo real de aplicação. Dos poucos artigos que achei, nenhum apresentou uma aplicação deste método, apenas comentários e comparações. Quando acreditei ter achado algo, este era o mesmo do livro do Hollnagel.

CREAM
Cognitive Reliability and Error Analysis Method

Método apresentado por Erik Hollnagel, professor da Linkping University, Suécia, em livro de mesmo nome do método, pela editora Elsevier Science Ltd., em 1998.

Como segunda referência para este resumo, foi utilizado um trabalho realizado por pesquisadores do Departamento de Ciência da Computação da Universidade de Paderborn. Este trabalho, no início de da discussão, apresenta o livro de Erik Hollnagel como referência principal.

-> Introdução
Uma das premissas para o desenvolvimento de trabalhos na área da human reliability analysis (HRA) é a tentativa de responder perguntas como: “Why to investigate human reliability?”. Análises realizadas pelo Instituto de Operações em Energia Nuclear, em 180 eventos ocorridos nos anos de 1984 e 1985, mostraram que 51% de todos os incidentes podem ser relacionados a problemas de desempenho humano. Os outros 39% principais eventos também podem ser classificadas como “instâncias” do erro humano, levando à, praticamente, 90% dos incidentes sendo direta ou indiretamente relacionados a este último.

Uma outra análise, agora elaborada pela NASA, em 612 incidentes entre 1990 e 1993, mostrou que 66% deles foram causados por erro humano. Outras categorias que também ocasionaram estes incidentes são: procedimentos falhos (5%), disfunção em equipamentos (8%) e pouco treinamento ou quebras na comunicação (21%). Contudo, estes últimos foram considerados como havendo uma relação com o erro humano, totalizando assim uma faixa de 80-85%, ao invés dos 66%.

O CREAM é apresentado como um método capaz de fazer dois tipos de análises: retrospectiva (onde se quer descobrir quais foram as causas iniciais do erro) e predição de desempenho (a partir de uma ação inicial definir seus efeitos). Dois termos para a aplicação do método são definidos: causa deve ser conhecida como genótipo e efeito como fenótipo, estes definem os pontos iniciais e finais. As causas e efeitos entre estes pontos são definidos como antecedentes e conseqüências, respectivamente.

-> Classificação
Quando uma cadeia de evento precisa ser analisada, é necessário levantar uma seqüência abstrata o suficiente para que não haja muitos detalhes, evitando que a análise se torne complexa, contudo, este é um dos principais problemas apontado por Hollnagel.
São usados quatro grupos, um referindo-se aos fenótipos e os outros três ao genótipo. Cada grupo se separa em categorias mais detalhadas, onde são distinguidas as conseqüências gerais e as específicas.

-> Modos de Erro
Este modo descreve como uma ação incorreta pode se manifestar. Pode ser separados em quatro grupos:
- Ação de tempo errado
- Ação de tipo errado
- Ação de objeto errado
- Ação de lugar errado

-> Genótipos relacionados ao humano
Este categoria é sobre funções específicas da cognição. Hollnagel separa estes entre análises e sínteses. A primeira é responsável por identificar a situação corrente (observação, reconhecimento) e a segunda de determinar o que fazer e como (opções, planejamento, programação). Neste modelo, esta análise é descrita como observação e interpretação e a síntese como planejamento e execução.

-> Genótipos relacionados com tecnologia
Possui sub-grupos ligados ao sistema sob análise e avalia mal funcionamento técnico, operação inadequada e questões ligadas às interfaces:
- Disfunção nos equipamentos
- Procedimentos
- Problemas de interface temporários
- Problemas de interface permanentes

-> Genótipos relacionados á organização
Relacionados aos genótipos não ligados ao tecnológico e/ou humano:
- Comunicação
- Organização
- Treinamento
- Condições ambientais
- Condições de trabalho

-> Relacionamento
Hollnegel comenta que o método não possui característica hierárquica entre os grupos, ou seja, existe um relacionamento livre entre eles que será definido na análise do evento em questão. Para tal, cada conseqüência descrita em um grupo precisa corresponder a um, ou mais, antecedente em outros grupos.

Para cada conseqüência, uma lista de antecedentes prováveis (possíveis explicações) deve existir. Cada um desses antecedentes são, também, conseqüências em outro grupo, ou para a causa raiz. Tal procedimento apresenta a extensão que o método pode obter até se alcançar uma explicação ou enquanto ainda fizer sentido.

-> Um exemplo teórico
Assuma que uma análise começa sobre uma conseqüência de um determinado grupo B. A descrição deste grupo fornece alguns antecedentes para este evento e assuma que, de acordo com as circunstâncias dadas, o antecedente mais provável é o B2, o qual é uma conseqüência do grupo A. Continuando a análise deste ponto, deve-se determinar qual o antecedente mais provável para B2 dentro do grupo A. Aceite a antecedente A3 para este exemplo. Pode ser que este último, seja a conseqüência de um grupo C.

-> Análise retrospectiva
Seu objetivo é achar as respostas para questões do porque algo aconteceu e como. Para tal é necessário seguir os seguintes passos:
- Determinar o contexto
- Descrever os possíveis modos de erro
- Descrever as causas prováveis
- Realizar uma análise mais detalhada dos passos principais (traçar possíveis links conseqüência-antecedente para os modos de erro selecionados)

Como já apontado, determinar o contexto de um evento sem ser muito detalhista e nem deixar de lado importantes informações é complexo e, portanto, não recomendado que se faça. CREAM usa CPC (Common Performance Conditions), que é um grupo de nove condições. Para cada contexto, uma condição geral deve ser descrita como aquela corrente e, com esta informação, ser pontuada a partir de níveis dados pelo método.

Para efeito de elucidação, citarei aqui as nove condições do CPC: adequação à organização; condições de trabalho; adequação da MMI (modelo proposto por Sheridan e Hennessy, 1984. Relacionado com a devida apresentação das informações em interfaces e indicadores) e suporte operacional; procedimentos disponíveis; número de objetivos a serem alcançados simultaneamente; tempo disponível; treinamento e experiência; eficiência na colaboração dos envolvidos.

No próximo passo, devem ser determinados quais modos de erro são prováveis e quais são suas possíveis causas, ou seja, quais genótipos são mais prováveis. Tendo em vista que as causas podem ter ligações entre elas, níveis de relacionamento entre causas (CPC) e os genótipos devem ser definidos, objetivando a orientação do analista para dar seqüência à aplicação do método.

-> Analisado os passos
O primeiro evento deve ser descrito e combinado com um modo de erro predefinido, e.g., ação de tempo errado. Para este modo de erro, um(ns) antecedente(s) deve(m) ser determinado(s), isto é feito usando tabelas de relacionamento fornecidas pelo método. Cada antecedente também é uma conseqüência, e a busca por seus antecedentes deve ser feita. O autor apresenta três formas de o analista descobrir que o processo foi finalizado:
- um antecedente específico é encontrado
- nenhum antecedente foi encontrado para uma conseqüência
- o antecedente não pode ser qualificado como conseqüência

-> Um exemplo real
“Even there are only few examples were CREAM was applied for analysis or prediction (what might be due to the little age of the method and its complexity), it seems that, once understood and with the appropriate amount of detailed information, it is nevertheless a very powerful method.”

Este texto acima fecha a conclusão do trabalho apresentado sobre o CREAM pela University of Paderborn. Atesto que realmente é difícil encontrar um exemplo publicado da aplicação do método em algum evento, somente comentários e pequenas comparações com outros. Nesta parte apresento um resumo do exemplo existente no livro do Hollnagel e, consequentemente, no trabalho da University or Paderborn.

O evento real considerado para apresentação ocorreu em 25 de Janeiro de 1982, na R. E. Ginna Nuclear plant, onde houve a ruptura de um tubo de vapor oriundo do gerador B. Um seqüência de eventos é apresentada pelo autor para definição do cenário, acompanhada do texto:
“As the first three steps are strongly context dependent and the official documentation of the incident is not avaliable, only the results of the original analysis are provided here.”

Primeiramente, cada CPC foi descrita para este evento e verificado em qual nível ela atendia ao requerido. Por exemplo, a CPC condição de trabalho foi nivelada como incompatível, já que havia muitas pessoas na sala de controle, trazendo distúrbios nas tarefas do operador.

Na determinação dos modos de erro possíveis, estes são listados de acordo com a tabela fornecida pelos métodos, cada um é esclarecido e pontuado de acordo com sua pertinência ao evento (impossível, possível e provável).

No terceiro passo, as prováveis causas são determinadas, ou seja, a tabela de CPC vs genótipos é usada. As CPC’s que não trazem problemas para esta análise são marcadas e se algum genótipo não tem ligação com as CPC’s, este grupo não é considerado como uma provável causa. Contudo, este caso não ocorre neste evento, há pelo menos uma ligação e os três grupos são analisados.

Continuando, deve-se agora descrever o evento inicial, considerado aqui como um atraso no fechamento da válvula de isolação do vapor principal (MSIV). O modo de erro mais provável, neste caso, é o tempo. O antecedente específico é o atraso e nenhum outro modo de erro foi aplicado aqui.

Usando tabelas fornecias pelo método, um processo de “linkagem” é iniciado. Da tabela dos modos de erro, o tempo (considerado o mais provável) apresenta seis antecedentes gerais e dois específicos. Dos gerais, dois foram escolhidos: procedimento inadequado e planejamento inadequado. Tomando o primeiro como uma conseqüência agora, deve-se ir até o grupo dos procedimentos para encontrar um antecedente. Neste grupo, problema de projeto e controle inadequado da qualidade parecem relevantes. De acordo com a categoria organizacional, o controle inadequado da qualidade é claramente relevante e tem como antecedente procedimento inadequado. Já o problema de projeto não parece conveniente.

Um antecedente, procedimento inadequado, tornou-se conseqüência e foi encontrado como antecedente novamente, finalizando a análise para ele.

Com o término dessa, dá-se seqüência para planejamento inadequado, repetindo-se todo o processo.

Cada passo desse é realizado para cada modo de erro, até que as prováveis causas possam ser encontradas.

10.11.05

Capítulo 5 – Um projeto para máquina falível - Livro: Human Error - James Reason

Resumo do livro de James Reason, Human Error
Um projeto para uma máquina falível (A design for a fallible machine)

Este capítulo vem esboçar uma resposta para a seguinte pergunta: "Que tipo de dispositivo que trabalha baseado em informações poderia operar corretamente na maioria das vezes, mas também produzir respostas ocasionalmente erradas como no comportamento humano? A idéia é "fazer coisas que são feitas pela mente humana" (Boden, 1987, p. 48). De acordo com Bolden (1987, p. 48), há duas vantagens nesta tentativa:

"First, it enables one to express richly structured psychological theories in a rigorous fashion (for everything in the program has to be precisely specified, an all its operation have to be made explicity); and secondly, it forces one to suggest specific hypotheses about precisely how a psychological change can come about."

-> Componentes estruturais da "máquina"
A máquina possui dois componentes principais: working memory (WM) e knowledge base (KB). A primeira é subdividida também em duas partes: focal (FWM) e periférica (PWM). Se imaginarmos dois círculos, um sendo a FWM e o outro sendo a PWM, o primeiro estaria circunscrito no segundo. Como entrada e saída de informações, são necessários alguns sensores e atuadores, estes são definidos aqui, respectivamente, como input function (IF) e output function (OF). O primeiro alimenta a PWM e a KB, o segundo é uma combinação de efeitos oriundos de KB, havendo uma realimentação destes como IF da máquina.

-> Funções de cada parte da máquina

- FWM
Recebe informações constantemente da KB e do IF.

- PWM
Sua função primária é gerenciar o acesso das informações à FWM. Têm suas informações de entradas vindas diretamente da KB e do IF, segura tais informações brevemente enquanto realiza uma seleção daquela pequena porção que irá alcançar a FWM. Qual informação deve acessar a FWM e qual não deve é realizado de acordo com uma variedade de prioridades.

- Knownledge base (KB)
Repositório de unidade de conhecimento. Ilimitado em capacidade e tempo no qual o conhecimento fica armazenado. Contudo, não é considerado uma biblioteca, mas um conjunto de pistas. Como nossa memória, essas pistas podem aumentar na forma de informações mais elaboradas, à medida que são usadas pela WM.

-> Mecanismos de recuperação
A máquina possui alguns mecanismos para recuperar a informação existente na KB para a FWM. Dois deles: similarity-matching e frequency-gambling, ambos constituem as premissas computacionais do sistema. O terceiro mecanismo chama-se directed serch (ou serial search), oriundo do sofisticado processo da FWM.

- Similarity-matching
Para evitar extensas buscas dentro da KB, este mecanismo tenta encontrar recentes e similares ocorrências (OF) da FWM. Caso nada seja encontrado, buscas mais profundas são realizadas.

- Frequency-gambling
Em algumas situações, encontrar a ocorrência que seja similar ao requisitado não é suficiente, uma grande quantidade de respostas pode ser obtida da KB. Nesses casos, uma grande quantidade de possíveis candidatos pode ser encontrada na PWM, partindo então para a busca através do mecanismo de frequency-gambling. Entre os candidatos, aquele que já foi empregado com maior freqüência será o escolhido.

- Directed search
FWM não tem acesso direto à KB, somente aos resultados de suas buscas. O que a FWM pode fazer é recusar algum resultado de frequency-gambling oferecido pela última. Sendo assim, se um resultado não é satisfatório para a FWM, esta pode reiniciar a busca com algumas alterações em suas informações de filtro.

-> Analisando um processo
Analisando a máquina falível em um processo, a seguinte seqüência de fatos pode ser cogitada:
O problema é encaminhado, através das IF, para a KB e WM. Em um primeiro passo, a KB entrega uma seqüência de resultado através da similarity-matching e frequency-gambling para a WM. Um resultado é avaliado por esta última e considerado inadequado, o problema é analisado novamente e novas pistas são enviadas à KB. Após uma busca mais profunda, um novo grupo de resultados é entregue à WM. Novamente, esta pode considerá-lo inadequado, reformulando novas pistas enviando-as para a KB. Nova busca, desta vez ainda mais profunda, é realizada e novos resultados são novamente entregues. A WM os considera adequados e uma solução é apresentada.

Na tentativa de modelar os fundamentos da cognição humana, duas questões importantes precisam ser abordadas: (a) as propriedades da KB e seus modos de representação e (b) um conjunto de regras, ou heurísticas, para selecionar qual estrutura de conhecimento armazenada será ativada em certa situação. Segundo o autor, esse mecanismo de “response-selecting” descrito acima não somente provê o modelo de gerenciamento de informações do ser humano, como também cria e define formas de reconhecimento do erro humano.

Em um mundo real, cada problema teria uma única solução, contudo, a realidade está muito longe disto: (a) a busca para solucionar problemas pode resultar em várias respostas ou em nenhuma, (b) as estruturas de conhecimento podem estar incompletas, erradas ou perdidas entre elas. Essas premissas são formas de apresentar uma preocupação na tentativa de modelar a cognição humana.

-> Modelando resultados sobre conhecimentos incompletos
Nesta parte o autor apresenta dois exemplos, para efeito de ilustração das idéias até então apresentadas, resumirei apenas um deles: reconhecimento a partir de pistas limitadas.

Foi realizada uma simulação (implementada em Prolog, por Philip Marsden) sobre os meios pelos quais pessoas com conhecimento variado sobre os presidentes dos Estados Unidos respondem à tarefa de identificar, entre 20 nomes, aquele que corresponde a uma (ou até três) determinada pista selecionada de fatos biográficos da vida deste.

Para este modelo, uma KB normativa foi preenchida com um específico número de fatos verdadeiros sobre cada presidente. Após esse passo, uma KB descritiva é criada como uma versão incompleta da KB normativa, com o objetivo de modelar a cognição humana. Como já comentado, após algumas buscas, os dados armazenados na KB vão sendo alimentados com novas informações e tornando-se mais completos, ou seja, após várias execuções a KB descritiva torna-se muito parecida com a KB normativa.

WM não tem acesso direto à KB descritiva (DKB). Suas interações ocorrem através dos processos: similarity-matching e frequency-gambling. A busca é acionada pela WM através da apresentação de uma séria de pistas e termina com a aceitação do produto da busca por parte da mesma WM.

A partir do momento que um candidato veio como resposta para a WM, um processo comparativo é iniciado acumulando, assim, duas informações: (a) evidências de confirmação de similaridades entre o pedido de busca e o resultado, (b) evidência de contradições entre as mesmas entidades.Em uma fase seguinte de decisão, um certo peso é dado para as evidências e é definido a estratégia mais apropriada para este problema em particular.

Através de uma pesquisa realizada com estudantes dos Estados Unidos e da Inglaterra, dois grupos foram divididos de acordo com seu conhecimento dos presidentes dos Estados Unidos. O resultado das simulações e da pesquisa com os jovens resultou em uma relação entre os resultados de 0,85 para um grupo e 0,87 para o outro.

Referências:
REASON, James. Human Error. Cambridge: Cambridge University Press, 1990. 302 p.

8.11.05

Atualizando: Acidente Challenger

Posto aqui o resumo e conclusão sobre o acidente da Challenger. Qualquer nova definição de falha/erro/disfunção é muito bem vinda (questionamento sobre as minhas e aquelas comentadas em sala também são).

Challenger (51-L) (28/01/1985)

Tripulação:
Francis R. Scobbe – Comandante.
Michael J. Smith – Piloto.
Judith A. Resnick – Especialista da Missão 1.
Ellison S. Onizuka – Especialista da Missão 2.
Ronald E. McNair – Especialista da Missão 3.
Gregory B. Jarvis – Especialista do Satélite 1.
Sharon Christa McAuliffe – Especialista do Satélite 2.

-> Objetivos da missão (Missions Highlights)
Os planos para a Challenger, quando em órbita , seriam:
1 - Primeiro dia: após chegar a órbita, a tripulação teria duas tarefas agendadas. Primeiramente eles checariam a disponibilidade do satélite TDRS-B antes de planejar seu lançamento. Após o almoço, eles lançariam o satélite e realizariam uma série de manobras de separação. O primeiro período de sono estava programado para durar 8 horas, começando aproximadamente 18 horas após a equipe ter acordado na manhã do lançamento.
2 - Segundo dia: o experimento chamado Comet Halley Active Monitoring Program (CHAMP) foi iniciado. Também estava programado a apresentação de uma fita de vídeo (TISP – teacher in space) e manobras para colocar a Challenger a 152 milhas de altitude orbital de onde o Spartan seria lançado.
3 - Terceiro dia: a tripulação iniciou a preparação para o pré-lançamento do Spartan. O satélite foi posicionado usando um sistema de manipulação remota (RMS) para um braço robótico. A nave seria lentamente afastada do Spartan até 90 milhas de distância.
4 - Quarto dia: a Challenger se aproximaria do Spartan, enquanto Gregory B. Jarvis continuaria realizando seus experimentos sobre dinâmica dos fluídos iniciados no segundo dia. Transmissões ao vivo também estavam programadas e seriam conduzidas por Christa McAuliffe.
5 - Quinto dia: a tripulação aproximou-se do Spartan e usou o braço robótico para capturar o satélite e colocá-lo no compartimento da Challenger.
6 - Sexto dia: iniciou-se a preparação para re-entrada. Isto inclui checagem no controle de vôo, teste nos jatos de manobra e no compartimento de armazenamento. Uma nova conferência, por parte da tripulação, estava programada para após o almoço.
7 - Sétimo dia: o dia teria sido todo reservado com intuito de preparar a nave para sair de órbita e entrar na atmosfera. A Challenger foi programada para aterrisar no Kennedy Space Center, 144 horas e 34 minutos após seu lançamento.

-> Acidente
Após seu lançamento, o contato visual com a Challenger durou, aproximadamente, 73,137 segundos (1 minuto e 13 segundos). Uma série de eventos ocasionou seu fracasso, quando esta foi envolvida por uma bola de fogo.
Através de sistema de computadores e mecanismos de melhorias nas imagens, as câmeras de vídeo mostraram que fortes jatos de uma fumaça cinza vinham das proximidades da junta do foguete direito e eram oriundos de uma área em frente ao tanque externo. Esta foi a primeira evidência de que a junta não estava completamente vedada.
Após 2,5 segundos, outros 8 jatos de fumaça foram registrados. Um fato interessante: os jatos ocorriam com uma freqüência de 4 por segundo, aproximadamente a mesma da dinâmica estrutural da nave. A cor preta e a densidade da fumaça indicava que o anel de vedação havia sofrido erosão pelos gases quentes propelidos.
A aproximadamente 37 segundos, a Challenger começou a deparar-se com situações extremas devido a alta altitude. Todas elas foram reconhecidas pelo sistema de navegação e ações foram automaticamente tomadas, contudo, tais forças aumentaram os níveis de pressão sobre a nave. O aumento no força de propulsão, necessária para vencer os eventos, foram suficientes para que a primeira pequena chama no foguete direito fosse visualizada (através das câmeras) aos 58,788 segundos do lançamento. No quadro seguinte, da mesma câmera, esta mesma chama já podia ser vista sem nenhum mecanismos de melhoria na imagem. No mesmo momento (aproximadamente 60 segundos) o sistema de telemetria mostrou uma diferença de pressão entre os foguetes direito e esquerdo.
Algumas manobras fizeram com que a chama fosse direto para o tanque externo. A primeira confirmação visual deste evento deu-se aos 64.660 segundos, quando uma mudança abrupta de cor e formato aconteceu na chama. Tal mudança indicou que em sua composição havia hidrogênio, presente apenas no tanque externo.
Aos aproximados 72 segundos, uma série de eventos ocorreu muito rapidamente. Aos 73,124 um vapor branco, que obedecia um padrão, foi observado oriundo do tanque externo. Esta era a indicação de que a estrutura do tanque de hidrogênio começava a falhar. Aos 73.137 segundos, a Challenger e toda sua tripulação foram consumidas pela explosão.

-> Análise de falha, erro e disfunção
Conclusão apresentada pela Comissão responsável pelo caso:

“In view of the findings, the Commission concluded that the cause of the Challenger accident was the failure of the pressure seals in the aft field joint of the right Solid Rocket Motor. The failure was due to a faulty design unacceptably sensitive to a number of factors. These factors were the effects of temperature, physical dimensions, the character of materials, the effects of reusability, processing and the reaction of the joint to dynamic loading.”

Do ponto de vista do sistema, a falha principal pode ser apontada como sendo o uso de uma peça (anel de vedação da junta) irregular ou avariada como é citado na conclusão da Comissão acima. O estado de erro é alcançado com a presença desta peça na estrutura da nave. A disfunção foi gerada quando o anel de vedação avariado não respondeu flexivelmente como era esperado.
Os eventos aconteceram de forma rápida, o contato visual com a disfunção apresentada pela vedação ocorreu poucos segundos antes da explosão e o sistema de telemetria apresentou a primeira irregularidade após 60 segundos do lançamento (frisando que a explosão ocorreu aos 73 segundos). Tais fatos tornam inadequado apontar falha/erro/disfunção do ponto de vista humano nos segundos que antecederão o fracasso da missão.
A relação que deve ser feita é: a falha apresentada pelo sistema caracteriza a disfunção do ponto de vista humano. Deste último pode-se dizer: a falha é fundamentada no uso de procedimentos de testes e ensaios não acordados com os requisitos da peça e o projeto de operação inadequado da mesma. O erro fica aqui definido como a aprovação de uma determinada peça (aqui o foco é o anel de vedação) que pode não atender as necessidades. Através deste estado de erro, peças que não atendam as especificações podem juntar-se àquelas que atendam, podendo levar à disfunção quando a usada é a primeira.

Referência:
Site da NASA acessado em 28 de setembro de 2005: http://www-pao.ksc.nasa.gov/kscpao/shuttle/missions/51-l/mission-51-l.html

3.10.05

Modelos

Nosso próximo tema são os modelos da atividade/desempenho humano. Há diversos pontos de vista sobre a ação humana em sistemas complexos e em conseqüência, muitos diferentes modelos. Vamos começar por alguns modelos clássicos:
  1. O modelo de Rasmussen, que estabelece os níveis de comportamento skill-based, rule-based e knowledge based, sobre o qual se assenta a teoria de erro humano do Reason, que veremos em seguida, é o tema da Bárbara.
  2. O modelo do Processador Humano de Informações, que deu origem ao modelo GOMS do Card, Moran e Newell, em que os elementos da memória, percepção e atuação humana são listados junto com princípios básicos de funcionamento, é o tema do João.
  3. O modelo SHELL, em que o ser humano é confrontado com o seu contexto, formado pelo software, hardware, ambiente e outros seres humanos, é o tema do Daniel.
  4. Coube ao Galba identificar o modelo do ser humano em tarefas contínuas, com base no trabalho de Thomas Sheridan.

O objetivo: definir sob qual papel o ser humano é visto em cada um destes modelos; quais os aspectos da performance humana o modelo procura destacar; quais as principais contribuições de cada modelo e seu uso. Um pequeno resumo a ser postado no blog, com referências bibliográficas no padrão é o produto esperado da atividade.

Até lá!
Lucia

Sobre responsabilidade civil e criminal no projeto visando confiabilidade humana

Na sexta passada, em que discutimos os acidentes, ficou evidente que grande parte dos erros cometidos pelos operadores foi provocada por deficiências no projeto. Como projetistas de sistemas, precisamos ficar atentos às nossas responsabilidades e às possíveis imputações legais decorrentes das decisões de projeto.

Ações judiciais de responsabilidade civil e criminal são um prejuízo à cultura de segurança das empresas e podem representar um atraso às pesquisas na área de confiabilidade humana; por outro lado, elas despertam nos projetistas a consciência da importância da confiabilidade humana nos projetos de engenharia.

O texto a seguir foi publicado na lista do AirSafetyGroup e fala sobre responsabilidade no acidente do Concorde.

A good example of how many people and of how large a range may get involved after an air accident 5 years after the accident that costed all the lives of the CONCORDE disaster on take-off , the french judge accuses the top engineer. As it was revealed , the weak point of the CONCORDE wing structure was too well known years ago : the soft wing cover would not stand the impact of pieces of blown up tyres and therefore the fuel tanks found at this point were not protected. The solution was a KEVLAR shield and/or tyres that will not explode .
To no surprise of course (!) it was considered on those days that a possible grounding at large scale for the CONCORDE would affect badly its reputation and 'eventually' the decision makers relied on the showlders of 'statistics' : it was a rare thing to happen . True , you may say a 0,1 % . However , for a thing that will be repeated so often , the possibility of 1 becomes a certainty , and so the disaster did happen .
The judge makes the point that despite the time intervened from the day the problem became known , eversince , NOTHING has been modified !
This proves that one can not really have a tranquil sleep years after some safety details have been 'neglected'. Not all judges everywhere will be proven equally sensitive of course ( I bet you ) but once the first example appeared there is a tendency for others to immitate them
That reminds me that some local ATC procedures found for a long time in the 'grey area' and where no one ( traditionally ) wants to bring some clarification , may challenge the statistics as well. Can you imagine , say , some retired supervisors be called in front of the judge for having not reacted on something 'abnormal' some ...20 years ago in their carreer ?
Interesting , eh ?


27.9.05

Tarefas da semana - análise de acidentes representativos

Pessoal,
com base nas definições de falha, erro e disfunção, combinamos avaliar na próxima sexta alguns acidentes.
1. (Bárbara) O acidente com o equipamento Therac-25.
2. (Daniel) O acidente com o vôo da TAM
3. (João) O acidente de Three-Mile Island
4. (Galba) O acidente da Challenger

Cada um deverá providenciar documentação descritiva do acidente e estudá-la para relatar com detalhes para os demais. A idéia é identificar falhas, erros e disfunções do sistema, em componentes de hardware, software e humanos.

Até sexta!
Lucia

17.9.05

O acidente de Atenas

De: "Fragoso"
Data: Sex Set 9, 2005 1:10 pm
Assunto: Crew confusion found in Athens plane crash The crew members of a Cypriot airliner that crashed Aug. 14 near
Athens became confused by a series of alarms as the plane climbed,
failing to recognize that the cabin was not pressurizing until they
grew mentally disoriented because of lack of oxygen and passed out,
according to several people connected with the investigation.

Complicating the cockpit confusion, neither the German pilot nor the
young, inexperienced Cypriot co-pilot could speak the same language
fluently, and each had difficulty understanding how the other spoke
English, the worldwide language of air traffic control.

A total of 121 people were killed in the crash after the plane
climbed and flew on autopilot, circling near Athens as it was
programmed to do until one engine stopped running because of a lack
of fuel. The sudden imbalance of power, with only one engine
operating, caused the autopilot to disengage and the plane to begin
its final descent.

The Greek authorities have made cryptic statements hinting at oxygen
problems but have so far not announced the full findings of
investigators.

The people interviewed for this article agreed to do so on condition
that they not be identified because none are official spokesmen for
the investigation and because of political sensitivities arising from
a Cypriot plane crashing in Greece.

Investigators pieced together the story of the crash from numerous
sources. In the wreckage, they found the first solid clues - the
pressurization valve and an air outflow valve set incorrectly. Air
traffic control tapes provided information on the confusion in the
cockpit.

The plane had a sophisticated new flight data recorder that provided
a wealth of information. There were maintenance records from the
night before, and investigators interviewed the mechanics who worked
on the plane.

Among other things, the investigators determined that the pilot was
not in his seat because he was up trying to solve a problem that
turned out to be not the greatest threat facing him.

The plane that crashed, a Boeing 737, underwent maintenance the night
before. The maintenance crew apparently left a pressurization
controller rotary knob out of place, according to the officials
connected to the investigation, and the crew did not catch the
mistake during preflight checks the next day. This meant that the
plane could not pressurize.

At 10,000 feet, or 3,000 meters, as designed, an alarm went off to
warn the crew that the plane would not pressurize. However, the crew
members mistakenly thought that the alarm horn was a warning to tell
them that their controls were not set properly for takeoff, the
officials said.

The same horn is used for both conditions, although it will sound for
takeoff configuration only while the plane is still on the ground.

The crew continued the climb on autopilot. At 14,000 feet, oxygen
masks deployed as designed and a master caution light illuminated in
the cockpit. Another alarm sounded at about the same time on an
unrelated matter, warning that there was insufficient cooling air in
the compartment housing avionics equipment.

The radio tapes showed that this created tremendous confusion in the
cockpit. Normally an aircraft cabin is held at 8,000 feet pressure,
so the crew at over 14,000 feet would already be experiencing some
disorientation because of a lack of oxygen.

During this time, the German captain and the Cypriot co-pilot
discovered they had no common language and that their English, while
good enough for normal air traffic control purposes, was not good
enough for complicated technical conversation in fixing the problem.

The crew members called the maintenance base in Cyprus and were told
that the circuit breaker to turn off the loud new alarm was in a
cabinet behind the captain. The captain got up from his seat to look
for the circuit breaker, apparently ignoring the confused co-pilot.

As the plane continued to climb on autopilot, the air grew so thin
that the crew became seriously impaired. The captain passed out first
on the floor of the cockpit, followed by the co-pilot, who remained
in his seat, according to the officials.

The autopilot did as it was programmed to do, flying the plane at
34,000 feet to Athens and entering a holding pattern. It remained in
a long circling pattern, shadowed by Greek military jets, until fuel
ran low and one engine quit.

Boeing, the maker of the plane, is-sued a notice shortly after the
crash to airlines that it would revise flight crew training manuals
to stress to crews that they must understand how the various warning
systems work and what to do about them.

The notice stresses that the takeoff configuration warning horn will
not sound under any circumstances after the plane has left the
ground.

The same horn will then be used only for a cabin altitude warning.
The company notice said there had been other instances of confusion
over the horn by pilots.

"Confusion between the cabin altitude warning horn and the takeoff
configuration warning horn can be re-solved if the crew remembers
that the takeoff configuration warning horn is only armed when the
airplane is on the ground," the notice said. "If this horn is
activated in flight, it indicates that the cabin altitude has reached
10,000 feet."

9.9.05

Escolha dos temas - Galba

Oi a todos,

Antes de qualquer coisa, vou me apresentar, rapidamente, aos demais: meu nome é Galba Falce de Almeida, engenheiro eletricista (ênfase em computadores) e mestre em sistemas integráveis, trabalho com pesquisa/aulas no Centro Universitário da FEI. O resto vai sendo apresentado durante as aulas e no convívio do grupo de pesquisa.

Bom, em virtude dos objetivos levantados para a minha tese, os temas de maior interesse pra mim são:

7. Processo de projeto para desempenho humano confiável.
Human-centred design.
Normas aplicáveis ao projeto da IHC de sistemas críticos.
Análise de tarefas mediadas por computador.
Descrição de tarefas de interação.

3. Modelos da interação e do desempenho humano
O modelo de Rasmussen: comportamento baseado em habilidade, regras e conhecimento.
Características do desempenho humano no controle de sistemas: limitações de percepção, memória e tempo de resposta.
Modelos de previsão de desempenho na operação de computadores. GOMS.
Arquiteturas cognitivas - ACT-R

Um abraço....

Galba

Quem vai fazer o quê?

Peço comentar este post durante a semana com os 2 temas de interesse que vc mais se identifica, da lista de temas sugeridos. Vou separar o material de leitura para distribuição na primeira aula.

6.9.05

Objetivos do nosso grupo de estudo

O foco do grupo de estudo é a Confiabilidade Humana como parâmetro de projeto da interação homem-computador (IHC) de sistemas críticos, dando subsídio para as fases de concepção, desenvolvimento e avaliação destes sistemas.

Pretendemos estabelecer os conceitos e pesquisas técnicas para melhorar o acoplamento dos sistemas à estrutura social da operação.

As reuniões serão usadas para apresentação e discussão dos resultados das pesquisas.

Regras de participação

Este é um grupo de estudo, em primeiro lugar. É uma oportunidade de troca de idéias sobre um tema de interesse comum. Os interessados podem se vincular ao grupo, contribuindo para os estudos através de leituras, pesquisas específicas, produção bibliográfica e principal e obrigatoriamente, com a presença nas discussões.

A participação é formalizada em uma disciplina de pós-graduação (PCS5006). Os alunos regularmente matriculados receberão créditos pela participação em % das aulas e cumprimento das tarefas atribuídas. Espera-se, no entanto, que a participação seja continuada, mesmo fora do período de oferecimento da disciplina!

Nossos tópicos

O conjunto de temas é grande, vamos ter que selecionar alguns de interesse comum. Na lista original, temos os seguintes tópicos e as sugestões de abordagem:

1. Conceitos
Conceito de sistema crítico.
Conceito de erro, confiabilidade, segurança, risco e perigo.

2. Sistemas críticos
Exemplos de sistemas críticos.
A operação humana de sistemas críticos.
Componentes dos sistemas críticos: homem, máquina, sistema e tarefas.
Interfaces de sistemas críticos.
Exemplos de interfaces de operação na área aeronáutica, nuclear e química.

3. Modelos da interação e do desempenho humano
O modelo de Rasmussen: comportamento baseado em habilidade, regras e conhecimento.
Características do desempenho humano no controle de sistemas: limitações de percepção, memória e tempo de resposta.
Modelos de previsão de desempenho na operação de computadores. GOMS.
Arquiteturas cognitivas - ACT-R

4. Erro humano.
Origem e manifestações.
Deslizes (slips), lapsos e enganos (mistakes).
Performance Shaping Factors.
Caracterização dos erros humanos relacionados à interação homem-computador. Análise de erros humanos em grandes acidentes.
Modelo de Reason - GEMS

5.Conceito de confiabilidade humana.
Probabilidade do erro humano.
Evolução histórica do conceito.
Análise e redução do erro humano.
Aplicações da confiabilidade humana nas análises de segurança e de risco

6. Técnicas
Técnica HERA-JANUS para registro e análise do erro.
Métodos qualitativos:H-HAZOP, FMEA, etc.
Métodos quantitativos:THERP, HEART, SLIM, CREAM.
Novas abordagens aos métodos de Análise da Confiabilidade Humana

7. Processo de projeto para desempenho humano confiável.
Human-centred design.
Normas aplicáveis ao projeto da IHC de sistemas críticos.
Análise de tarefas mediadas por computador.
Descrição de tarefas de interação.

8.Verificação e validação das interfaces homem-computador de sistemas críticos.
Avaliação da carga mental de trabalho.
Sense-making.
Heurísticas para interfaces de sistemas críticos.
Padrões para recuperabilidade do erro humano nas interfaces.

9. Aspectos da gestão da confiabilidade operacional
Impacto do erro humano no treinamento e manutenção.
Usabilidade de procedimentos operacionais