FACULDADE PITÁGORAS

ADILSON DA SILVA
PAULO RENATO OTTONI
RONALDO LOURENÇO FERREIRA
WESLEY CHRISTIANN GOULART COELHO
THIAGO CORREIA RIBEIRO

FERRAMENTAS PARA ANÁLISES DE RISCOS

MONOGRAFIA DE PÓS-GRADUAÇÃO EM ENGENHARIA DE

SEGURANÇA DO TRABALHO

Belo Horizonte - MG
2013
 ADILSON DA SILVA
PAULO RENATO OTTONI
RENATO LOURENÇO FERREIRA
WESLEY CHRISTIANN GOULART COELHO
THIAGO CORREIA RIBEIRO

FERRAMENTAS PARA ANÁLISES DE RISCOS

Monografia de pós-graduação apresentada a

Faculdade Pitágoras por Adilson da Silva,
Paulo Renato Ottoni, Renato Lourenço
Ferreira, Wesley Christiann Goulart Coelho,
Thiago Correia Ribeiro como requisito para
obtenção do grau de Engenheiro de
Segurança do Trabalho.

Belo Horizonte - MG
2013
 FACULDADE PITÁGORAS

Por

ADILSON DA SILVA
PAULO RENATO OTTONI
RENATO LOURENÇO FERREIRA
WESLEY CHRISTIANN GOULART COELHO
THIAGO CORREIA RIBEIRO

UM ESTUDO PROSPECTIVO DA ADOÇÃO DE FERRAMENTAS PARA ANÁLISES

DE RISCOS

MARÇO, 2013

APROVADO POR:

________________________________________________________
FACULDADE PITÁGORAS
PROF. ENGº JOSEVAN URSINE FUDOLI
Dedicamos este trabalho a Deus por
abençoar nosso caminho, aos nossos pais
pelo exemplo e determinação, irmãos e
amigos pelo apoio. A nossas namoradas,
esposas e filhos pela força, dedicação e
compreensão.
 RESUMO

UM ESTUDO PROSPECTIVO DA ADOÇÃO DE FERRAMENTAS PARA ANÁLISES

DE RISCOS.
ABSTRACT
 SUMÁRIO

Técnicas de Identificação e Análise de Riscos

1- Introdução
2- Descrição do Processo de gerenciamento de riscos
3 -Técnicas de Identificação de Risco
3.1-Técnica de Incidentes Críticos(TIC)
3.2-What-If / Checklist
3.3-Análise Preliminar de Riscos (APR)
3.4-Estudo de Perigo e Operabilidade – HAZOP
3.5-Análise de Modos de Falhas e Efeitos (AMFE)
3.6-Análise de Árvores de Falhas (AAF)
4 - Conclusão
5 - Referências Bibliográficas
1-Introdução

A gerência de riscos é definido como a ciência, a arte e a função que busca à proteção
dos recursos humanos, materiais e financeiros de uma empresa, no que se refere à eliminação,
redução ou ainda financiamento dos riscos, caso seja economicamente viável.
Este estudo iniciou nos EUA e alguns países da Europa, logo após a Segunda Guerra
Mundial, quando começou a estudar a possibilidade de redução de prêmios de seguros e a
necessidade de proteção da empresa frente a riscos de acidentes. A gerência de riscos é muito
antiga como o próprio homem que, desde sempre, esteve envolvido com riscos e decisões na
luta da sobrevivência.
É necessário para se ter um gerenciamento de riscos eficaz, o gerente de riscos e a
empresa devem estar engajados em sistema de gestão integrado, em que se inclui a Qualidade,
Meio Ambiente, Segurança, Saúde Ocupacional e Responsabilidade Social.
E importante lembrar que, antes de qualquer ação de gerenciamento de riscos, conheçam-se os
tipos de riscos a que uma empresa esta sujeita, por meio de aplicação de técnicas especificas e
reconhecidas tecnicamente.
Através do conforto e do desenvolvimento trazidos pela industrialização produziram
também o aumento considerável no número de acidentes, devido à obsolescência dos
equipamentos e máquinas cada vez mais sofisticadas, sem o devido treinamento para operá-
las.
Com a preocupação e a necessidade de dar maior atenção ao ser humano, além de buscar
uma maior eficiência, nasceram primeiramente o Controle de Danos, o Controle Total de
Perdas e a Engenharia de Segurança de Sistemas.
A Engenharia de Segurança de Sistemas, surgida com o crescimento e necessidade de
segurança total em áreas como aeronáutica, aeroespacial e nuclear, ela trouxe valiosos
instrumentos para a solução de problemas ligados à segurança. Com a difusão dos conceitos
de perigo, risco e confiabilidade, as metodologias e técnicas aplicadas pela segurança de
sistemas, inicialmente utilizadas somente nas áreas militar e espacial, tiveram, a partir da
década de 70, uma aplicação quase que universal na solução de problemas de engenharia em
geral
2 - Descrição do Processo de gerenciamento de riscos

Normalmente o risco é associado a impactos negativos ou a perigos, porém a sua melhor

abordagem é quando refere à exposição a conseqüências incertas ou a desvios potencias do
que era esperado ou planejado, ligados as ameaça e oportunidades.
O gerenciamento de riscos pode ser definido como um processo no qual alguns fatores
de incerteza presentes em determinado contexto são sistematicamente identificados,
analisados, estimados, categorizados e tratados. Busca-se alcançar um equilíbrio entre a
concretização de oportunidades de ganhos e a minimização de perdas. Refere-se a uma
atividade interativa que permite o aprimoramento contínuo do processo de decisão e a
melhora crescente do desempenho da organização.
O processo leva em conta a criação de infra-estrutura e cultura adequadas, com
aplicação de método sistemático, a fim de permitir que as decisões sejam tomadas mediante o
conhecimento dos riscos associados às atividades da organização.
De acordo com as melhores práticas o gerenciamento de riscos acontece através de um
método sistemático que estabelece um contexto para depois identificar, analisar, estimar,
tratar, monitorar e comunicar os riscos associados a alguma atividade, função ou processo da
organização. Este gerenciamento deve ser visto como parte de uma cultura interna, tomando
lugar em sua filosofia, práticas e processos, a fim de se tornar parte da gestão estratégica.
Simplificadamente, o processo envolve a definição do contexto no qual organização
atua, ou seja, objetivos, estratégias, valores e cultura, estabelecendo-se, a estrutura sobre a
qual as decisões se apóiam. Então, posteriormente é feito a identificação dos riscos e a sua
análise, estimando-se a expectativa de ocorrência dos eventos e os impactos que estes causam
à organização. Após a análise, os riscos são avaliados e categorizados para que lhes seja dado
o tratamento adequado.

3 -Técnicas de Identificação de Risco

3.1 Técnica de Incidentes Críticos (TIC)

Esta técnica se originou em 1941, quando J.C. Flanagan, sistematizou técnica

desenvolvida através de estudos comportamentais realizados no programa de psicologia da
aviação da Força Aérea dos EUA. Os vários estudos realizados entre 1941 e 1945, tinham o
objetivo de identificar exigências críticas que poderiam determinar o sucesso ou o fracasso de
uma atividade. Neste estudo destacam-se:
 • O que poderia estar causando o insucesso no aprendizado do voo, contribuindo assim
para melhorias no programa de seleção de pilotos;
• Identificar possíveis causas de fracassos em missões de bombardeio, utilizando de
análises dos relatórios das missões, por observadores especialistas, contribuindo para evoluir
os procedimentos de treinamento do pessoal;
• Identificar possíveis e prováveis incidentes comportamentais, sendo eles negativos ou
positivos e relacionando à liderança de combate.
Flanagan, juntamente com outros psicólogos do Programa de Psicologia da Força Aérea
criaram o Instituto Americano de Pesquisa, logo após o fim da II Grande Guerra. Este
Instituto, tinha o objetivo de estudar o comportamento humano. Em 1947, se concretiza a
sistematização da técnica e passa a ser conhecida formalmente como Técnica de Incidentes
Críticos.
Em Segurança do Trabalho, os esforços estão concentrados no pós-fato, ou seja, depois
que o acidente ocorreu. Logo as tentativas de controlar esses acidentes, acabam se tornando
um processo de tentativa e erro, o que não é muito eficaz.
Se faz necessário um critério que possa medir a eficiência da Segurança, e também
algum modo de medi-la. Hoje o profissional de segurança está diante de uma noção intuitiva,
sem a certeza da eficiência dos vários métodos de prevenção. Não tem como medir a
eficiência interna de um programa de prevenção. Precisamos medir se estamos indo bem ou
mal com nossas medidas de prevenção de acidentes. Precisamos ter consciência que a função
principal de uma medida de desempenho, é nos mostrar o nível de segurança dentro de um
sistema.
Efetivamente, as medidas de desempenho de segurança, devem nos ajudar a prevenir
acidentes e tentar reduzir ao máximo o registro deles. Devem também nos dizer, ou melhor,
mostrar uma previsão de possível ocorrência de tal acidente.
Devemos ter uma visão clara desta “medida” de eficiência da segurança, ela deve nos
mostrar o nível de segurança que atingimos ou se estamos ainda crescendo ou decrescendo. O
registro do acidente nos mostra a falta de segurança e não o nível de segurança. Não tem
como falar em nível de segurança ou de proteção contra acidente com eles acontecendo.
Faz-se então necessária uma técnica de identificação de fatores causadores de acidentes
com ou sem lesão. O registro do acidente sem lesão nos dá parâmetros para analisarmos a
gravidade do mesmo com lesão e tomarmos providências no sentido de evitar que acidentes
com lesão venham a ocorrer, uma vez que temos muito mais acidentes sem lesão do que com
lesão. Outro dado importante é que as pessoas envolvidas ou não nestes acidentes, tem mais
facilidade de falar mais abertamente dos acidentes sem lesão do que com lesão, tornando mas
fácil o levantamento de dados. Assim, registrando e identificando o alto índice de incidentes
sem lesão, poderíamos utilizar estas informações para evitarmos futuros acidentes com lesão.

3.1.1 Procedimentos Utilizados

O método identifica erros ou condições inseguras que podem causar ou contribuir para
que ocorra um acidente com lesão. Estes erros ou condições são identificados por
colaboradores, escolhidos em diversos setores, ou melhor, departamentos principais, que se
queira analisar. Desta forma teremos informações diversas das categorias de risco.
Estes observadores, depois de um tempo, são interrogados por um entrevistador, onde o
mesmo busca levantar os incidentes que ocorreram, tantos quantos o colaborador se recordar,
que resultaram ou não em lesões.
Após todas as entrevistas e com todos os dados em mãos é possível levantar as causas
potenciais de acidentes, organizar e implantar ações de prevenção bem como melhor distribuir
recursos destinados a prevenção de acidentes.
A técnica deve ser repetida periodicamente, podendo alterar a amostra aleatoriamente
para poder detectar novas oportunidades de melhorias da segurança.
Depois que os setores analisados estiverem com grau de segurança aceitável e as
melhorias sendo implantadas, pode-se executar a técnica em outros setores, fazendo um
rodízio.

3.2 What If/ Check List

Segundo LEES, 2005, What-if é a técnica de identificação de perigos mais antiga. Ela
consiste na análise do processo com a formulação de uma série de perguntas iniciando com
“E se”.
Esta é uma técnica de análise qualitativa, com aplicação bastante simples e útil na
detecção de riscos, tanto na fase de processo, projeto ou pré-operacional, e pode ser utilizada
em qualquer estágio da vida de um processo. O objeto do What-If é proceder à
identificação e tratamento de riscos que pode ser testado possíveis omissões no
sistema.(CARDELLA, 1999).
Por não ser sistemática como outras técnicas, como Hazop e FMEA, sua flexibilidade
estrutural pode ser indicada como uma das suas desvantagens, já que depende da experiência
dos participantes da equipe de análise para que todos os perigos potenciais sejam descritos e
avaliados adequadamente. Em contrapartida, por ser flexível pode ser utilizada em diversos
sistemas, mesmo os que não envolvem processos,(Schmitz, 2009).
Apresentação técnica da What IF

What If ou “E se?” é uma técnica de identificação de perigos e análise de riscos que

consiste em detectar perigos utilizando um questionamento aberto promovido pela pergunta
“E se?” O objeto What If…? pode ser um sistema, processo, equipamento ou evento. O
âmbito é "tudo o que poderá traduzir-se em erro ou falha” Este âmbito é mais amplo que o de
outras técnicas porque o seu método é mais livre. O What lf admite tanto o questionamento
livre como o sistemático. No livre, o objeto é questionado por meio da pergunta “E se?” em
relação a qualquer aspecto que se julgar conveniente. Assim, ter-se-ão perguntas do tipo:
- E se for colocado mais produto?
- E se a matéria-prima estivesse contaminada?
- E se ocorresse um temporal?
No questionamento sistemático, o objeto é focalizado do ponto de visão de diversos
especialistas, como por exemplo, nas áreas de eletricidade, instrumentação, combate a
incêndio, preservação ambiental e medicina ocupacional. Fazem-se reuniões específicas onde
a pergunta “E se?” é aplicada a cada especialidade. O What if deve ser registrado em
formulário próprio, com campos para o que pode resultar danoso, causas, conseqüências e
medidas de controlo de riscos e de emergências (Freitas, 2003) .
Segundo DE CICCO e FANTAZZINI (1994b), nas culturas empresarias mais eficientes
no controle de riscos, os procedimentos dos departamentos técnicos e as equipes de análise
produzem revisões rápida e eficientemente. Os mesmos autores sugerem, ainda, alguns passos
básicos quando da sua aplicação:
a) Formação do comitê de revisão: montagens das equipes e seus integrantes;
b) Planejamento prévio: planejamento das atividades e pontos a serem abordados na
aplicação da técnica;
c) Reunião Organizacional: com a finalidade de discutir procedimentos, programação de
novas reuniões, definição de metas para as tarefas e informação aos integrantes sobre o
funcionamento do sistema sob análise;
d) Reunião de revisão de processo: para os integrantes ainda não familiarizados com o
sistema em estudo;
 e) Reunião de formulação de questões: formulação de questões "O QUE - SE...",
começando do início do processo e continuando ao longo do mesmo, passo a passo, até o
produto acabado colocado na planta do cliente;
f) Reunião de respostas às questões (formulação consensual): em sequência à reunião de
formulação das questões, cabe a responsabilidade individual para o desenvolvimento de
respostas escritas às questões. As respostas serão analisadas durante a reunião de resposta às
questões, sendo cada resposta categorizada como: - resposta aceita pelo grupo tal como
submetida; - resposta aceita após discussão e/ou modificação; - aceitação postergada, em
dependência de investigação adicional. O consenso grupal é o ponta chave desta etapa, onde a
análise de riscos tende a se fortalecer;
g) Relatório de revisão dos riscos do processo: o objetivo é documentar os riscos
identificados na revisão, bem como registrar as ações recomendadas para eliminação ou
controle dos mesmos.
Tabela 1-Formulário de registro de identificação de perigos (Freitas,2003)

Descrição Perigo / Medidas de Controlo de

Conseqüências risco e de emergência

1. Falha de equipamentos, materiais e

instrumentos
– O que ocorreria se uma peça do
equipamento deixasse de funcionar?
– O que aconteceria se um tubo de uma
caldeira falhasse?
2. Falhas de serviço
– O que aconteceria se houvesse uma
falha de eletricidade?
– O que aconteceria se faltasse a água?

3.3 Análise Preliminar de Riscos (APR)

3.3.1 Objetivo

Análise Preliminar de Perigo (APP) é uma metodologia indutiva estruturada para

identificar os potenciais perigos decorrentes da instalação de novas unidades e sistemas ou da
própria operação da planta que opera com materiais perigosos.
 Esta metodologia procura examinar as maneiras pelas quais a energia ou o material de
processo pode ser liberado de forma descontrolada, levantando, para cada um dos perigos
identificados, as suas causas, os métodos de detecção disponíveis e os efeitos sobre os
trabalhadores, a população circunvizinha e sobre o meio ambiente. Após, é feita uma
Avaliação Qualitativa dos ricos associados, identificando-se, desta forma, aqueles que
requerem priorização. Além disso, são sugeridas medidas preventivas e/ou mitigadoras dos
riscos a fim de eliminar as causas ou reduzir as conseqüências dos cenários de acidente
identificados.
O escopo da APP abrange os eventos perigosos cujas causas tenham origem na
instalação analisada, englobando tanto as falhas de componentes ou sistemas, como eventuais
erros operacionais ou de manutenção (falhas humanas). O grau de risco é determinado por
uma matriz de risco gerada por profissionais com maior experiência na unidade orientada
pêlos técnicos que aplicam a análise.

3.3.2 Aplicação

Esta metodologia deve ser empregada para sistemas na fase inicial do projeto, quando
existe apenas os elementos básicos do sistema e os materiais já estão definidos. O uso da APP
ajuda a selecionar as áreas de instalação nas quais outras técnicas mais detalhadas da análise
de riscos ou contabilidade possam ser utilizadas posteriormente. Esta técnica visa a
identificação e avaliação preliminar dos perigos presentes em uma instalação ou unidade.
Em cada perigo em análise, busca-se determinar:
• os eventos acidentais a ele associados;
• as conseqüências da ocorrência destes eventos;
• as causas básicas e os eventos intermediários;
• os modos de prevenção das causas básicas e eventos intermediários;
• os modos de proteção e controle, dada a ocorrência das causas básicas e eventos
intermediários.
As etapas básicas para a elaboração de uma APR, são:
1. Rever os problemas conhecidos através da revisão de experiência passada em
sistemas similares ou análogos, para determinação dos riscos que poderão estar presentes no
sistema que está sendo desenvolvido;
2. Revisar a missão atentando para os objetivos, as exigências de desempenho, as
principais funções e procedimentos, os ambientes onde se darão as operações;
 3. Determinar os riscos principais com potencialidade para causar direta e
indiretamente lesões, perda de função, danos a equipamentos, perda de material;
4. Determinar os riscos iniciais e contribuintes para cada risco principal detectado;
5. Revisar os meios de eliminação ou controle de riscos elaborando uma revisão dos
meios possíveis, procurando as melhores opções compatíveis com as exigências do sistema;
6. Analisar os métodos de restrição de danos considerando os métodos possíveis
mais eficientes na restrição geral de danos, no caso de perda de controle sobre os riscos;
7. Indicar quem levará a cabo as ações corretivas mostrando claramente os
responsáveis pelas ações corretivas, designando as atividades que cada unidade irá
desenvolver.

3.3.3 Dados Necessários

As principais informações requeridas para a realização da APP estão indicadas no
Quadro 1.
Quadro 1 – Informações necessárias para a realização da APP

• Dados demográficos
Região
• Dados climatológicos
• Premissas de Projeto
• Especificações técnicas de
projeto
• Especificações de
Instalações equipamento
• Lay-out da instalação
• Descrição do principais
sistemas
de proteção e segurança
• Propriedades físicas e
químicas
Substâncias • Características da
inflamabilidade
• Característica de toxicidade
 3.3.4 Pessoal Necessário e Suas Atribuições

A APP deve ser realizada por uma equipe estável, contendo entre cinco e oito pessoas,
entre esses membros da equipe deve-se dispor de um membro com experiência em segurança
de instalações e pelo menos um que seja conhecedor do processo envolvido. É recomendável
que a equipe tenha a composição, funções e atribuições específicas como indicadas no Quadro
2.
Quadro 2- Composição recomendável de uma equipe de APP

Função Perfil/Atividades
Pessoa responsável pelo evento que deverá
• Definir a equipe
• Reunir informações atualizadas, tais como:
fluxogramas de engenharia, especificações técnicas
Coordenador do projeto, etc;
• Distribuir material para equipe;
• Programar reuniões;
• Encaminhar aos responsáveis as sugestões e
modificações oriundas da APP
Pessoa conhecedora da metodologia, sendo
responsável por:
• Explicar a metodologia a ser empregada aos demais
participantes;
Líder
• Conduzir as reuniões e definir o ritmo de
andamento das mesmas;
• Cobrar dos participantes pendências das reuniões
anteriores.
Pessoas que estarão ou não ligadas ao evento, mas que
Especialista detêm informações sobre o sistema a ser analisado ou
experiência adquirida em sistemas similares.
Pessoa que tenha poder de síntese para fazer
Relator anotações, preenchendo as colunas da planilha da APP
de foram clara e objetiva.
3.3.5 Estimativa de Tempo e Custo Requeridos

Em geral, as reuniões não devem durar mais do que três horas, sendo a periodicidade de
duas a três vezes por semana. O tempo necessário para a realização e reuniões da APP
dependerá da complexidade do sistema/ processo a ser analisado. O reconhecimento
antecipado dos perigos existentes no processo economiza tempo e reduz os custos oriundos de
modificações posteriores da instalação/ sistema. Isto faz com que os custos em termos de
homens-hora alceados à realização da APP tenham um retorno considerável.

3.3.6 Natureza dos Resultados

Na APP são levantadas as causas que podem promover a ocorrência de cada um dos
eventos e as suas respectivas conseqüências, sendo, então, feita uma avaliação qualitativa da
freqüência de ocorrência do cenário de acidentes, da severidade das conseqüências e do risco
associado. Portanto, os resultados obtidos são qualitativos, não fornecendo estimativas
numéricas. Normalmente uma APP fornece também uma ordenação qualitativa dos cenários
de acidentes identificados, a qual pode ser utilizada como um primeiro elemento na
priorização das medidas propostas para redução dos riscos da instalação/ sistema analisado.

3.3.7 Apresentação da Técnica de APR

A metodologia de APP compreende a execução das seguintes etapas:

• Definição dos objetivos e do escopo da análise;
• Definição das fronteiras do processo/instalação analisada;
• Coleta de informações sobre a região, a instalação e os perigos envolvidos;
• Subdivisão do processo/ instalação em módulos de análise;
• Realização da APP propriamente dita (preenchimento da planilha);
• Elaboração das estatísticas dos cenários identificados por Categoria de Risco
(freqüência e severidade);
• Análise dos resultados e preparação do relatório;
Para a execução da analise o processo de instalação com estudo deve ser dividido em
“módulos de análise”. A realização da analise propriamente dita é feita através do
preenchimento da planilha de APP para cada módulo. A planilha adotada para a realização da
APP, mostrada no quadro 3, contém 7 colunas, as quais devem ser preenchidas conforme a
descrição respectiva a cada campo:
Quadro 3 - Composição recomendável de uma equipe de APP

Recomendaçõe
Perigo Causa Consequência Frequência Severidade Risco
s

Todo As As A a severidade o risco é As recomenda-

evento causas consequências frequência é é definida definido ções propostas
acidental responsá são os efeitos definida conforme conforme devem ser de
com veis pelo dos acidentes conforme descrito na descrit na caráter
potencial perigo envolvendo: descrito na Quadro 5 figura 1 e Preventivo e/ou
para podem radiação quadro 4 no quadro mitigador.
causar envolver térmica, 6.
danos às tanto sobrepres-
pessoas, falhas de são ou dose
às equipam tóxica.
instalaçõe entos
s ou ao como
meio falhas
ambiente. humanas
.

No contexto da APP, um cenário de acidente é definido como sendo o conjunto formado

pelo perigo identificado, suas causas e cada um de seus efeitos. Um exemplo cenário de
acidente possível seria: grande liberação de substância tóxica devido a ruptura de tubulação
levando à formação de uma nuvem tóxica. De acordo com a metodologia da APP, os cenários
de acidente devem ser classificados em categorias de freqüência, as quais fornecem uma
indicação qualitativa da freqüência esperada de ocorrência para cada um dos cenários
identificados. O Quadro 4 mostra as categorias de freqüências em uso atualmente para a
realização de APP.
Quadro 4 – Categorias de freqüência de ocorrência dos cenários

CATEGORIA DENOMINAÇÃO DESCRIÇÃO

Conceitualmente possível, mas extremamente

EXTREMAMENTE
A improvável de ocorrer durante a vida útil do
REMOTA
processo/instalação;
 Não esperado ocorrer durante a vida útil do
B REMOTA
processo/instalação;

Pouco provável de ocorrer durante a vida útil do

C IMPROVÁVEL
processo/instalação;

Esperado ocorrer até uma vez durante a vida útil

D PROVÁVEL
do processo/instalação;
Esperado de ocorrer várias vezes durante a vida
E FREQUENTE útil do processo/instalação.

A avaliação de freqüência também poderá ser determinada a partir de experiências dos

componentes do grupo ou por banco de dados de acidentes (próprio ou de empresas
similares). Os cenários de acidentes também devem ser classificados em categorias de
severidade esperada de ocorrência para cada um dos cenários identificados. O quadro 5
mostra as categorias de severidade em uso para a realização de APP.

Quadro 5 – Categorias de severidade dos perigos identificados

CATEGORIA DENOMINAÇÃO DESCRIÇÃO/ CARACTERÍSTICAS

Sem danos ou danos insignificantes aos

equipamentos, à propriedade e/ou ao meio
ambiente; Não ocorrem lesões/mortes de
I DESPREZÍVEL funcionários, de terceiros (não funcionários) e/ou
pessoas (indústrias e comunidade); o máximo que
pode ocorrer são casos de primeiros socorros ou
tratamento médico menor;
Danos leves aos equipamentos, à propriedade e/ou
ao meio ambiente (os danos materiais são
II MARGINAL controláveis e/ou de baixo custo de reparo);
Lesões leves em empregados, prestadores de
serviço ou membros da comunidade;
Danos severos aos equipamentos, à propriedade
e/ou ao meio ambiente;
Lesões de gravidade moderada em empregados,
III
CRÍTICA
prestadores de serviço ou em membros da
comunidade (probabilidade remota de morte);
Exige ações corretivas imediatas para evitar seu
desdobramento em catástrofe;
Danos irreparáveis aos equipamentos, à propriedade
e/ou ao meio ambiente ( reparação lenta ou
impossível);
IV CATASTRÓFICA
Provoca mortes ou lesões graves em várias
pessoas(empregados, prestadores de serviço ou em
membros da comunidade).
 Além disso, é importante salientar que para cada classe de severidade e frequência deve
ser adequada ao tipo de sistema e empreendimento analisado, para tomar a análise de risco
mais preciso e menos subjetivo. Para o estabelecimento do nível de risco, utiliza-se uma
matriz, indicando a freqüência e a severidade dos eventos indesejáveis, conforme a figura 1 e
no quadro 6.

Figura 1 – Matriz de Classificação de Risco – Freqüência x Severidade

Quadro 6 – Legenda da Matriz de classificação de Risco – Freqüência x Severidade

SEVERIDADE FREQUÊNCIA RISCO

I Desprezível A Extremamente 1 Desprezível

Remota

II Marginal B Remota 2 Menor

III Crítica C Improvável 3 Moderado

IV Catastrófica D Provável 4 Sério

Por fim, é feita à análise dos resultados obtidos, listando-se as recomendações de

medidas preventivas e/ou mitigadoras pela equipe da APP.
3.3.8 Proposta de Estrutura de relatório

CAPITULO 1 – Descrição dos objetivos visados com a aplicação da técnica, do escopo

abrangido pela análise, e da estrutura do relatório;

CAPITULO 2 – Descrição do sistema analisado, contemplando aspectos de operação,

manutenção, bem como possíveis modificações a serem feitas.

CAPITULO 3 – Descrição da metodologia utilizada, destacando-se os eventuais

critérios adotados na análise.

CAPITULO 4 – Apresentação da Análise Preliminar de Riscos do sistema analisado,

contendo a identificação dos módulos de análise, as planilhas da APP, estatística dos cenários
de acidentes levantados pela APP.

CAPITULO 5 – Conclusões gerais da APP, listando cenários de risco serio ou critico

identificados na APP. As recomendações geradas devem ser enfatizadas;se possível, designar
o órgão responsável por suas avaliações e implementações.

CAPITULO 6 – Referências Bibliográficas

ANEXOS – Fluxogramas utilizados na APP do sistema analisado.

3.3.9 - Principais vantagens da APR

A vantagem desta técnica é que ela é mais abrangente do que um checklist, informando as
causas que ocasionaram a ocorrência de cada um dos eventos e as suas respectivas
conseqüências, obtenção de uma avaliação qualitativa da severidade das conseqüências
(Quadro 4) e freqüência (Quadro 5) de ocorrência do cenário de acidente e do risco associado:
MATRIZ DE RISCO (Figura 1).
A desvantagem dela é requerer um maior tempo para a execução de todo processo até
o relatório final, necessitando de uma equipe com grande experiência em várias áreas de
atuação como: processo, projeto, manutenção e segurança.

3.4 - Estudo de Operabilidade e Perigo - HAZOP

A ferramenta HAZOP - (Hazard and Operability Studies) ou Estudo de operabilidade e
perigo - foi criada pela Imperial Chemical Industries, Ltd. (ICI) na década de 60 - (NOLAN,
1994). É uma metodologia de Análise de Riscos que foi desenvolvida para identificar riscos e
problemas operacionais em plantas de processos industriais, os quais, apesar de
aparentemente não apresentarem riscos imediatos, podem comprometer a produtividade e a
segurança da planta (CARDELA, 1989).
A diferença básica entre APP e HAZOP baseia-se no fato de que aquele procura
identificar uma falha de equipamento (identifica perigos), e este se refere a uma falha de
processo (identifica desvios do processo). Desse modo, nem todo desvio é um perigo, mas
todo perigo é um desvio. A técnica APP pode ser considerada um subconjunto da técnica
HAZOP.
A metodologia do HAZOP é baseada em um procedimento que gera perguntas de
maneira estruturada e sistemática através do uso apropriado de um conjunto de palavras-guias.
O principal objetivo é investigar de forma minuciosa e metódica cada segmento de um
processo, visando descobrir todos os possíveis desvios das condições normais de operação,
identificando as causas responsáveis por tais desvios e as respectivas consequências. Uma vez
verificadas as causas e as consequências de cada tipo de desvio, esta metodologia procura
propor medidas para eliminar ou controlar o perigo ou para sanar o problema de operabilidade
da instalação (AGUIAR, 2001).
O HAZOP enfoca tanto os problemas de segurança, buscando identificar os perigos que
possam colocar em risco os operadores e os equipamentos da instalação, como também os
problemas de operabilidade que embora não sejam perigosos, podem causar perda de
produção ou que possam afetar a qualidade do produto ou a eficiência do processo. Portanto,
o HAZOP identifica tanto problemas que possam comprometer a segurança da instalação
como aqueles que possam causar perda de continuidade operacional da instalação ou perda de
especificação do produto (AGUIAR, 2001).
Embora um estudo de HAZOP seja, sem dúvida, dispendioso, frequentemente evita
uma despesa muito maior do que quando a planta tem que ser modificada por causa de algum
problema que poderia ser identificado por um estudo de HAZOP (KING, 1988).

3.4.1. Apresentação da Técnica do HAZOP

“A técnica de HAZOP é implementada por uma equipe multidisciplinar coordenada por
um líder que guia as reuniões de análise”(CAGNO, 2002), revisando a planta através de uma
série de reuniões, durante as quais um grupo composto de diversos especialistas realiza um
brainstorming1 sobre o projeto da planta em busca de riscos, seguindo uma estrutura pré-
estabelecida. Uma das grandes vantagens deste brainstorming é que ele estimula a criatividade
e gera idéias, através da interação do grupo. Desta forma, esta técnica oferece aos integrantes
da equipe a oportunidade de liberarem sua imaginação, pensando em todos os modos pelos
quais um evento indesejado possa ocorrer ou um problema operacional possa surgir
(CARDELA, 1989).
No entanto, para minimizar a possibilidade de que algo seja omitido, a reflexão é
executada de maneira sistemática: cada circuito é analisado, linha por linha, para cada tipo de
desvio passível de ocorrência nos parâmetros de funcionamento do processo.
O HAZOP não é uma técnica para trazer mentes "recém chegadas" para trabalhar em um
problema. Esta é uma técnica que permite aos que são peritos em um processo utilizarem seus
conhecimentos e experiências de maneira sistemática, de modo que os problemas tenham
menor probabilidade de serem omitidos. A porcentagem de acidentes, posteriores ao HAZOP,
que ocorrem porque o grupo não tinha o conhecimento necessário para o desenvolvimento do
estudo é mínima. A maioria dos acidentes ocorre porque o grupo responsável pelo estudo
deixou de aplicar os seus conhecimentos (AGUIAR, 2001).
Para a finalidade de um HAZOP, uma linha é uma conexão por tubulação (ou qualquer
outro meio) entre dois equipamentos industriais principais. A equipe de estudo usa desenhos
da instalação, parâmetros de processo e palavras-guia no estudo de uma dada instalação, que
aplicados a pontos específicos - nós-de-estudo - dos fluxogramas do processo, usualmente em
linhas de transporte de fluidos entre dois equipamentos, têm como objetivo evidenciar riscos
potenciais nesses pontos (CARDELA, 1989).
A aplicação mais eficaz do HAZOP ocorre quando o estudo é desenvolvido com base
no projeto básico da planta, pois a partir deste ponto o sistema está suficientemente definido
para permitir respostas significativas às questões emergentes do procedimento do HAZOP.
Além do mais, neste ponto, qualquer alteração que necessite ser realizada, em função
dos riscos analisados, pode ser feita com um custo relativamente baixo (CARDELA, 1989).
O processo de execução de um estudo de HAZOP é estruturado e sistemático. Portanto,
faz-se necessário o entendimento de alguns termos específicos que são utilizados no
desenvolvimento de uma Análise de Riscos desta natureza:
• Nós-de-estudo (Study Nodes): são os pontos do processo, localizados através dos
fluxogramas da planta, que serão analisados nos casos em que ocorram desvios;
• Intenção de operação: a intenção de operação define os parâmetros de funcionamento
normal da planta, na ausência de desvios, nos nós-de-estudo;
 • Desvios: os desvios são afastamentos das intenções de operação, que são evidenciados
pela aplicação sistemática das palavras-guia aos nós-de-estudo (p. ex., mais pressão), ou seja,
são distúrbios provocados no equilíbrio do sistema;
• Causas: são os motivos pelos quais os desvios ocorrem. A partir do momento em que

um desvio tenha demonstrado possuir uma causa aceitável, ele pode ser tratado como uma
ocorrência significativa e analisado adequadamente. As causas dos desvios podem advir de
falhas do sistema, erro humano, um estado de operação do processo não previsto (p. ex.,
mudança de composição de um gás), distúrbios externos (p. ex., perda de potência devido à
queda de energia elétrica), etc;
• Consequências: as consequências são os resultados decorrentes de um desvio da

intenção de operação em um determinado nó-de-estudo (p. ex., liberação de material tóxico

para o ambiente de trabalho);
• Parâmetros de processo: são os fatores ou componentes da intenção de operação, ou
seja, são as variáveis físicas do processo (p. ex., vazão, pressão, temperatura) e os
procedimentos operacionais (p. ex., operação, transferência);
• Palavras-guia ou Palavras-chave (Guide Words): são palavras simples utilizadas para
qualificar os desvios da intenção de operação e para guiar e estimular o grupo de estudo ao
brainstorming. As palavras-guia são aplicadas aos parâmetros de processo que permanecem
dentro dos padrões estabelecidos pela intenção de operação.
Aplicando as palavras-guia aos parâmetros de processo, em cada nó-de-estudo da planta em
análise, procura-se descobrir os desvios passíveis de ocorrência na intenção de operação do
sistema.

Quadro 7 - Exemplos de Palavras-guia

Palavras-Guia Desvios Considerados

NÃO, NENHUM Negação do propósito do projeto. (ex.: nenhum
fluxo)
MENOS Decréscimo quantitativo. (ex.: menos fluxo)
MAIS, MAIOR Acréscimo quantitativo. (ex.: mais fluxo)
TAMBÉM, BEM COMO Acréscimo qualitativo. (ex.: também)
PARTE DE Decréscimo qualitativo. (ex.: parte do fluxo)
REVERSO Oposição lógica do propósito do projecto. (ex.:
fluxo)
OUTRO QUE, SENÃO Substituição completa. (ex.: outro que ar)
 Normalmente, os principais resultados fornecidos pelo HAZOP consistem em:
- Identificação de todos os desvios acreditáveis que possam conduzir a eventos
perigosos ou a problemas operacionais.
- Uma avaliação das conseqüências (efeitos) destes desvios sobre o processo.
O exame dos meios disponíveis para se detectar e corrigir ou mitigar os efeitos de tais
desvios. Podem ser recomendadas mudanças no projeto, estabelecimentos ou mudança nos
procedimentos de operação, teste e manutenção. Desse modo, os resultados obtidos são
puramente qualitativos, não fornecendo estimativas numéricas nem qualquer tipo de
classificação em categorias (AGUIAR, 2001).
3.4.2 Exemplo de aplicação de HAZOP

Aguiar et al., 2001 desenvolveu estudo de caso de aplicação de HAZOP em

descarregamento de ácido sulfúrico.
Como resultados deste processo sistemático, foram identificados e considerados
relevantes pelo grupo de estudos quatro pontos ou nós de referência, representados no
desenho esquemático de interfaces e conexões (Figura 1), bem como os parâmetros, palavras-
guia, desvios, causas e conseqüências associados, conforme representados no Quadro 1.

Figura 2 Diagrama Esquemático de Interfaces e Conexões do Sistema de Transferência de Ácido Sulfúrico do Caminhão
para o Tanque
Quadro 8 Resultados do HAZOP

Sistema: Transferência de Produto Corrosivo do Caminhão para o Tanque

Nó 1 Nó 2 Nó 3 Nó 4
Parâmetro Vazão Vazão Pressão Vazão
Palavra
Guia Mais Menos Mais Mais
Desvio Mais Vazão Menos Vazão Pressão Alta Mais Vazão
Causas • Falha no • Boca de visita do •Caminhão cheio, •Caminhão
arqueamento do caminhão válvula (4) cheio, boca de
tanque; fechada; aberta e válvulas (3) e visita
• Caminhão com •Válvulas (4) ou (3) (2) aberta,
quantidade de parcialmente fechadas; válvulas (3)
produto maior do que fechadas; •Caminhão cheio, fechada e
o tanque •Rotor da bomba bomba (2) aberta.
comporta; danificado; desligada, válvulas (3)
• O tubo de inspeção •Válvulas (1) ou (2) e (4)
não é abertas e abertas e válvulas (1) e
vedado; linha de ar (2)
• O dreno do tanque despressurizada; fechadas;
está entupido; •Mangote com •Válvulas (3) e (4)
• O dreno do tanque vazamento; fechadas e
está mais alto •Ruptura da linha (2) aberta;
do que o topo do tubo •Boca de visita do
de caminhão
inspeção. fechada, suspiro do
caminhão
entupido, válvula (3)
fechada,
válvulas (2) e (4)
abertas.

3.5-Análise de Modos de Falhas e Efeitos (AMFE)

3.5.1 Introdução

Apresenta-se neste capítulo uma revisão bibliográfica sobre o FMEA, tendo como
tópicos as definições, descrição da equipe responsável pelo desenvolvimento, procedimentos
(etapas), as aplicações (projetos, processos, serviços), relacionamentos com outros FMEAs,
quando executar e o respectivo formulário. Apresenta-se também a definição de Análise do
Modo de falha, Efeitos e Criticidade (FMECA) e seus relacionamentos com o FMEA.
3.5.2 Histórico
Quanto ao FMEA não se sabe quando surgiu. Em alguns trabalhos não é possível sabe
se a data é referente ao FMEA ou ao FMECA. Por exemplo, analisando o texto a seguir: “O
FMEA teve sua origem nos Estados Unidos no dia 9 de novembro de 1949, como um padrão
para as operações militares - Procedures for Performing a Failure Mode, Effects and
Criticality Analysis (Military Procedure MIL-P-1629). Esta norma foi utilizada como uma
técnica de avaliação da confiabilidade para determinar os efeitos nos sistemas e falhas em
equipamentos. As falhas foram classificadas de acordo com seus impactos nos sucessos das
missões e com a segurança pessoal/equipamento” (www.fmeca.com, 2000). A norma MIL-P-
1629 executa a análise de criticalidade em seu procedimento, logo, não deveria ser FMEA, e
sim FMECA.O FMECA, atualmente, é denominado de Military Standard MIL-STD-1629A e
teve o seu início na indústria automobilística nos anos 70. Em 1988, a Organização
Internacional de Padronização (International Organization of Standardization) lançou a série
ISO 9000, dando um impulso às organizações para desenvolverem um Sistema de
Gerenciamento de Qualidade formalizado e direcionado às necessidades, desejos e
expectativas dos clientes. A QS 9000 é um 1 SAKURADA, Eduardo Yuji. As técnicas de
Análise do Modos de Falhas e seus Efeitos e Análise da Árvore de Falhas no
desenvolvimento e na avaliação de produtos. Florianópolis: Eng. Mecânica/UFSC,
(Dissertação de mestrado), 2001. padrão da indústria automotiva análogo à ISO 9000. As
empresas Chrysler Corporation, FordMotor Company e General Motors Corporation
desenvolveram a QS 9000 em um esforço para padronizar o sistema de qualidade fornecedor.
De acordo com a QS 9000, os fornecedores de automóveis devem utilizar o
Planejamento de Qualidade de Produto Avançado (Advanced Product Quality Planning –
APQP), incluindo FMEAs de projeto e de processo, e desenvolver um Plano de Controle.
Atualmente um novo padrão está sendo desenvolvido pela SAE (Society Automotive
Engineering) junto com as empresas: General Motors Corporation, Ford Motor Company e a
Chrysler Corporation (www.fmeca.com, 2000).

3.5.3 Áreas de utilização do FMEA atualmente

O FMEA tem sido utilizado nas mais diversas áreas:

• Sistemas hidráulicos e pneumáticos (LATINO, 1996), (BULL et al,1995);
• Equipamentos de semicondutores (VILLACOURT, 1992);
• Circuitos elétricos (PRICE, 1996);
• Desenvolvimento de reator termonuclear (PINNA et al, 1998).
 • Indústrias siderúrgicas (CASTRO, 2000);
O FMEA é frequentemente utilizado com a Análise da Árvore de Falhas (FTA), mas
pode ser usado com outras ferramentas, por exemplo, com o QFD (Quality Function
Deployment) (SOUZA, 2000), FCM (Mapas Cognitivos Fuzzy) (PELÁEZ, 1996).
Segundo HAWKINS e WOOLLONS (1998) uma das maiores críticas a respeito do uso
do FMEA é o tempo consumido. Esse problema tem sido amenizado com o uso dos FMEAs
automatizados. O desenvolvimento dos computadores, das linguagens e das interfaces para
programação, tem favorecido o desenvolvimento de FMEAs automatizados e vários autores
(BULL et al,1995; PRICE, 1996; PELÁEZ, 1996; RAIMOND et al, 1997) iniciaram o
desenvolvimento de softwares para auxiliar nas atividades como: o preenchimento dos
formulários, gerenciamento das reuniões e o cadastro das falhas. HUANG et al (1999)
apresenta um protótipo de FMEA automatizado com suporte para Internet, isto é, os
participantes de uma reunião poderiam estarem diversas partes do mundo executando o
mesmo FMEA.

3.5.4 Definições

A Associação Brasileira de Norma Técnicas (ABNT), na norma NBR 5462 (1994),

adota a sigla originária do inglês FMEA (Failure Mode and Effects Analysis) e a traduz como
sendo Análise dos Modos de Falha e seus Efeitos. Observa-se que a norma utiliza o termo
pane para expressar falha. Ainda segundo a norma, o FMEA é um método qualitativo de
análise de confiabilidade que envolve o estudo dos modos de falhas que podem existir para
cada item, e a determinação dos efeitos de cada modo de falha sobre os outros itens e sobre a
função específica do conjunto. NBR 5462 (1994) A Military Standard (MIL-STD 1629A)
(1980), identifica como sendo um procedimento pelo qual cada modo de falha potencial em
um sistema é analisado para determinar os resultados ou efeitos no sistema e para classificar
cada modo de falha potencial de acordo com a sua severidade.
FMEA é uma técnica analítica utilizada por um engenheiro/time como uma maneira de
garantir que, até a extensão possível, os modos potenciais de falha e suas causas/mecanismos
associados tenham sido considerados e localizados. Na sua forma mais rigorosa, o FMEA é
um sumário do conhecimento do engenheiro/time (incluindo uma análise de itens que
poderiam falhar baseado na experiência e em assuntos passados) de como um produto ou
processo é desenvolvido. Esta abordagem sistemática confronta e formaliza a disciplina
 mental que um engenheiro passa em qualquer processo de planejamento de manufatura ( Ford
Motor Company, 1997).
Um dos requisitos para a utilização da ferramenta é que se tenha total conhecimento do
que é modo de falha e efeitos. Portanto, para iniciar o estudo foi feito o uso do dicionário
MICHAELIS (2000), sendo consultados os seguintes termos: MODO, FALHA e EFEITO.
• MODO é a “Forma ou maneira de ser ou manifestar-se uma coisa”; “Maneira ou forma
particular de fazer as coisas, ou de falar”; “Maneira de conseguir as coisas; meio, via”.
• FALHA: “Defeito”, “Desarranjo, enguiço” ou “ato ou efeito de falhar”, sendo que
FALHAR está descrito como “Não dar o resultado desejado, não ser como se esperava”.
Desta forma, pode-se então começar a definir MODO DE FALHA como sendo: “a
formado defeito”, “maneira na qual o defeito se apresenta”, “maneira com que o item falha ou
deixa de apresentar o resultado desejado ou esperado”, “é um estado anormal de trabalho, a
maneira que o componente em estudo deixa de executar a sua função ou desobedece as
especificações”. O modo de falha é uma propriedade inerente a cada item, visto que cada item
tem suas características particulares como função, ambiente de trabalho, materiais, fabricação
e qualidade. Por exemplo, para um eixo pode-se ter como modo de falha, ruptura,
empenamento, desgaste e, para um filtro pode-se ter, rompido, entupido e assim por diante.
Existem duas abordagens para levantar os modos de falha: Funcional e Estrutural. A
abordagem funcional (Quadro 9) é genérica, não necessita de especificações de projeto ou de
engenharia. Pode ser tratada como uma não-função. Por exemplo:

Quadro 9 - Modo de falha com a abordagem funcional.

A abordagem estrutural necessita de informações de engenharia as quais muitas vezes

não estão facilmente disponíveis. Tanto na abordagem funcional como na abordagem
estrutural é muito importante que se tenha, bem definida, a função do componente, pois é a
referência para se verificar quando o item está em falha ou não. O Quadro 10 apresenta os
modos de falha para um eixo adotando a abordagem estrutural.
Quadro 10 - Modo de falha com a abordagem estrutural

EFEITO: “Resultado produzido por uma ação ou um agente, denominados causa em

relação a esse resultado”, “conseqüência, resultado”, “fim, destino” (MICHAELIS, 2000).
Pode se dizer que os EFEITOS do modo de falha são os resultados produzidos quando
estes vêm a ocorrer, são as conseqüências do modo de falha. Em outras palavras, o efeito é a
forma ou maneira de como o modo de falha se manifesta ou como é percebido em nível de
sistema. O modo de falha ocorre internamente, em nível de componentes, subsistemas,
gerando efeitos externos, Figura 3.
Na identificação dos efeitos, deve-se perguntar: O que pode acontecer com o
desenvolvimento deste modo de falha? O que isto causa no sistema? O que o cliente vê?
Quais os danos que isso pode causar ao ambiente?

Figura 3 – Indicativo de que o Modo de falha é uma ação interna e efeito uma ação externa

CAUSA: “Aquilo que determina a existência de uma coisa”; “O que determina um

acontecimento”; “agente, motivo, razão”; “origem, princípio” (MICHAELIS, 2000).
As causas do modo de falha são os motivos que levaram o modo de falha a ocorrer,
podem estar nos componentes da vizinhança, fatores ambientais, erros humanos, ou no
próprio componente.
Em resumo, vale ressaltar, embora as definições sejam simples, nem todas as falhas
poderão se ajustar a estas definições, podendo gerar muitas discussões em uma reunião de
FMEA. Deve-se ter em mente que, um modo de falha é uma anomalia que ocorre em nível de
componente e um efeito ocorre em nível de sistema. Esta anomalia deve ser caracterizada em
termos de função ou especificações de projeto, processo ou uso.
Uma maior discussão pode ocorrer entre modo de falha e causa do modo de falha. Os
membros da equipe devem ter consciência de que o importante é que a falha seja considerada
na análise, para que posteriormente sejam tomadas as medidas necessárias para sua
eliminação. Este problema voltará a ser discutido no estudo de caso realizado na bomba de
engrenagens, que será discutido em outro capítulo.
.3.5.5 O que é o FMEA
O FMEA é um método qualitativo que estuda os possíveis modos de falha dos
componentes, sistemas, projetos e processos e os respectivos efeitos gerados por esses modos
de falha. O modo de falha é a expressão utilizada para caracterizar o processo e o mecanismo
de falha que ocorre nos itens. O efeito é maneira como o modo de falha se manifesta. Cada
item pode ter diferentes modos de falha. Um determinado modo de falha vai se tornar mais ou
menos evidente, dependendo da função que o item está desempenhando naquele caso
específico. O efeito, por sua vez, segue a mesma sistemática.
A relação entre modo de falha e efeito, se bem controlada, pode tornar-se uma ajuda
muito grande para a análise da confiabilidade e também para os processos de manutenção a
serem adotados. A dificuldade é grande neste relacionamento dado que diferentes modos de
falha podem se manifestar da mesma maneira, ou seja, apresentam o mesmo efeito. Essa
complexidade torna-se ainda mais evidente quando da associação de um item a outro. Por
exemplo, um eixo enquanto um elemento de máquina isolado pode ter modos de falha do tipo:
fratura abrupta, fratura por fadiga, empenamento. Se associado ao mancal, e o eixo estiver
girando, pode-se considerar, ainda, os modos de falha: eixo trancado e eixo desalinhado.
Tanto o modo de falha “empenamento” quanto eixo desalinhado tem como efeito, quando o
eixo gira, a vibração. Esse efeito pode ser produzido também por problemas específicos dos
mancais que suportam o eixo ou por outros componentes que estão montados no eixo.
Outro aspecto importante a ser abordado na análise do FMEA é a causa geradora do
modo de falha. Embora muitos modos de falha sejam inerentes ao item em análise, o estudo
das causas permite aprofundar a relação entre o item e a função e gerar procedimentos mais
consistentes para aproveitar bem os efeitos, nas suas primeiras manifestações, no sentido de
tomar as providências requeridas antecipando-se à perda da função devido à ocorrência do
modo de falha. Com base nas análises feitas sobre os modos de falha e seus efeitos, são
tomadas ações que posteriormente sofrerão uma reavaliação e documentação. O material
gerado pelo FMEA tem como função servir como uma ferramenta para prognóstico de falhas
e auxiliar o desenvolvimento/análise de projeto de produtos, processos ou serviços.
O FMEA, por ser um registro, pode evitar que problemas passados venham a ocorrer
novamente buscando a melhoria contínua, sendo um documento vivo, atualizado e representa
as últimas mudanças realizadas do produto.
O conhecimento dos modos de falha dos itens, em qualquer fase do ciclo de vida do
produto, permite tomar as providências aos técnicos, na fase do ciclo de vida que se está
analisando, para evitar a manifestação daquele modo de falha. Assim, portanto auxilia nos
aspectos da mantenabilidade e da confiabilidade. O material gerado pode também servir em
programas de capacitação, proporcionando um melhor entendimento dos componentes e do
sistema. Com isso, tem-se um maior conhecimento a respeito das falhas facilitando a escolha
do tipo de manutenção (corretiva, preventiva, preditiva), garantindo maior disponibilidade2
do equipamento.

3.5.6 O que é o FMECA

A sigla FMECA tem origem da seguinte expressão em inglês Failure Modes, Effects
and Criticality Analysis e é ser traduzida como Análise dos Modos de Falha, Efeitos e
Criticalidade. Muitos autores, KUME [1996], PALADY (1997), STAMATIS (1995),
VILLACOURT(1992), propõem discutir a respeito do FMEA, mas na verdade se referem ao
FMECA. MOHR (1994) apresenta a diferença entre FMEA e FMECA da seguinte maneira:
FMECA = FMEA + C ( 4.1 )
onde, C = Criticalidade = (Ocorrência) x (Severidade) ( 4.2 )
O índice Ocorrência é usado para avaliar as chances (probabilidade) de a falha ocorrer,
enquanto que a Severidade avalia o impacto dos efeitos da falha, a gravidade dos efeitos.
Todos os autores relacionam a severidade aos efeitos dos modos de falha. No entanto, a
Ocorrência é relacionada, dependendo do autor, ao modo de falha ou às causas do modo de
falha.
Existe ainda outra métrica do FMECA, que se chama índice de detecção das falhas,
Figura 4. Este também é relacionado aos modos de falha ou às causas do modo de falha. Em
muitos trabalhos, não fica claro se estamos relacionando os índices ao modo de falha ou às
causas do modo de falha, sendo encontrado frequentemente questões como: Disponibilidade
é a capacidade de um item estar em condições de executar uma certa função em um dado
instante ou durante um intervalo de tempo determinado, levando-se em conta os aspectos
combinados de sua confiabilidade, mantenabilidade e suporte de manutenção, supondo que os
recursos externos requeridos estejam assegurados (Dias, 1997).
- Quais são as chances da falha ocorrer?
- Quais são as chances de se detectar a falha antes que ela alcance o cliente?
Afinal, as duas questões referem-se ao modo de falha ou às causas da falha? Esta
questão foi observada por PALADY (1997) e este afirma que, independente da abordagem, os
resultados obtidos são os mesmos. As duas abordagens estão ilustradas na Figura 4.

Figura 4 – (1 ) Índices baseados nas causas. (2) Índices baseados nos modos de falha.

No FMECA é calculado o Número de Prioridade de Risco (NPR) sendo que em algumas

abordagens o valor é atribuído ao modo de falha e em outras a cada causa do modo de falha.
A expressão (4.3) é bastante similar à expressão para o cálculo da criticalidade (4.2),
diferenciando apenas pela parcela de detecção.
NPR = Ocorrência x Severidade x Detecção ( 4.3 )
Detecção é um valor que mostra a eficiência dos controles de detecção da falha (modo
de falha ou causa do modo de falha). Quanto maior for o valor atribuído ao índice de detecção
significa que maior será a dificuldade de detectar a falha.
A seguir são apresentados exemplos de tabelas utilizadas para estimar os índices de
severidade, ocorrência e detecção.
Quadro 11 – Probabilidade de ocorrência (BEM-DAYA e RAOUF, 1996)

Quadro 12 – Severidade dos efeitos (BEM-DAYA e RAOUF, 1996)

Quadro 13 – Índice de detecção das falhas (BEM-DAYA E RAOUF, 1996)

3.5.7 Quando iniciar um FMEA/FMECA

Segundo VILLACOURT (1992), nos primeiros estágios do ciclo de vida do produto é

onde se tem maior influência na confiabilidade do produto. À medida que o projeto
 amadurece, torna-se mais difícil para alterá-lo. Infelizmente, o tempo, o custo, e os recursos
requeridos para corrigir um problema, detectado nas fases finais do processo de projeto,
aumentam. Como está evidenciado na Figura 4.6, nas primeira fases do processo de projeto,
investe-se em torno de 15 % do custo total do projeto, mas decide-se sobre 95 % do custo do
ciclo devida do produto. Essa é uma constatação que evidencia a importância de investir-se
em pesquisa e desenvolvimento, para que seja considerado o máximo de informação e
técnicas, nas fases iniciais do processo de desenvolvimento de produtos. Segundo DOWNEY,
citado por BACK e FORCELLINI (1998), 80% do custo do produto fica comprometido com
20 % da fase do projeto realizado. Isso corresponde à fase de projeto conceitual concluída.

Figura 5 – Os custos comprometidos ao longo do desenvolvimento do produto (VILLACOURT, 1992).

A frase citada por TENG e HO (1996), “a melhor confiabilidade é a confiabilidade

especificada no projeto do produto”, manifesta a importância da confiabilidade nas etapas do
processo de projeto. Por esses motivos o FMEA deve ser iniciado o mais rápido possível.
Quanto mais cedo for feito o FMEA, mais fácil e barato serão as mudanças para a
melhoria do produto. No entanto, nas fases iniciais de projeto (projeto conceitual) as
informações são bastante reduzidas, sendo então utilizada a abordagem funcional para os
modos de falha. Contudo, em tendo-se conhecimento da técnica de FMEA/FMECA e das
métricas a ela vinculada, pode-se já nas primeiras fases iniciais, levantar todos os requisitos
requeridos para considerar este processo de análise ao longo do projeto. Após a fase do
projeto detalhado, muitas características do produto já foram definidas. Nesta etapa é possível
usar, como recomenda a norma americana MIL-STD 1629A (1980), tanto a abordagem
funcional quanto estrutural. Iniciar o FMEA na fase de projeto não garante que todas as falhas
dos processos seguintes do desenvolvimento do produto serão evitadas. Segundo SOUZA
(2000), devido à complexidade e dificuldade de predizer as falhas, algumas podem ocorrer em
campo. Consequentemente, o feed back de campo também é uma da etapa muito importante
 em um programa de confiabilidade. LATINO (1996) propõe uma abordagem modificada de
FMEA, em sua obra é possível perceber a importância dos históricos do produto colhidos
durante a fase do uso, resultando em reduções no tempo gasto para o desenvolvimento do
FMEA, redução do número de pessoas envolvidas e dos custos.

3.5.8 Aplicações do FMEA/FMECA

A literatura tem trazido exemplos de aplicação do FMEA em diferentes setores. Estes

exemplos e recomendações não são consensuais. Neste texto será apresentada uma discussão
geral sobre estas aplicações. Estão presentes na literatura aplicações em sistema, projeto,
processo e serviço. Esta é a classificação de STAMATIS (1995) e o autor entende que:
FMEA de Sistema – É usado para analisar sistemas e subsistemas nas fases iniciais de
concepção e projeto. O FMEA de sistema enfoca os modos potenciais de falha entre as
funções do sistema, causada por algumas deficiências do sistema. Ele inclui a interação entre
os sistemas e os elementos do sistema.
FMEA de Projeto – É usado para analisar produtos antes que eles sejam liberados para a
manufatura. O FMEA de projeto enfoca os modos potenciais de falha causados pelas
deficiências do projeto.
FMEA de Processo – É usado para analisar os processos de manufatura e montagem. O
FMEA de processo enfoca os modos de falhas causados pelas deficiências do processo ou
montagem.
FMEA de Serviço – É usado para analisar serviços antes que eles alcancem o cliente. O
FMEA de serviço enfoca os modos de falha (tarefas, erros, enganos) causados pelas
deficiências do sistema ou processo.
As interações entre as aplicações podem ser vistas na Figura 6.

Figura 6 – Relacionamento entre os vários tipos de FMEAs (STAMATIS, 1995).

 STAMATIS (1995) explica que os modos de falha do FMEA de sistema geram todas as
informações essenciais para os FMEAs de projeto e processo, e embora os efeitos
permaneçam os mesmos, as causas no FMEA de sistema tornam-se os modos de falhas no
projeto, no qual geram suas próprias causas, que finalmente tornam-se os modos de falha no
FMEA de processo. A explicação não é clara, principalmente, no que se relaciona às causas
que vão passando a ser modos de falha. O fato dos efeitos permanecerem os mesmos, leva a
concluir que a análise está sendo feita considerando sempre o mesmo usuário, ou seja, o
usuário final do produto, o cliente externo.
O guia desenvolvido pela Ford Motor Company (1997), apresenta apenas três áreas
principais para as aplicações: Conceito, Projeto, Processo. O FMEA de Conceito apresenta-se
semelhante ao FMEA de sistema de STAMATIS (1995), o qual é empregado para analisar as
concepções de sistemas e subsistemas, nas fases iniciais de projeto. Essa aplicação focaliza os
modos de falha potenciais associados às funções propostas, de um conceito adotado, pelas
decisões de projeto. As definições de FMEA de projeto e processo também são semelhantes
às definições adotadas por STAMATIS (1995).
Na Figura 7 são apresentadas as dez categorias de FMEA utilizadas pela Ford: Uma
aplicação de conceito, três de projeto, três de montagem e três de manufatura.

Figura 7 – Categorias de FMEA (FORD, 1997).

3.5.9 A equipe participante do FMEA/FMECA

Alguns autores como KUME [1996], STAMATIS (1995), VILLACOURT (1992) dizem
que um FMEA deve ser desenvolvido por uma equipe. No entanto, PALADY (1997) diz que
um FMEA pode e tem sido executado como um esforço individual, mas concorda que é mais
eficiente quando aplicada em um esforço de equipe. Pode se afirmar que é preciso ter uma
liderança e profissionais de área específica e correlata ao tema em análise requerendo do
grupo objetividade e sinergia para atingir os objetivos propostos. Não há uma regra para
definir o número de participantes do FMEA. PALADY (1997)sugere um número de cinco a
sete participantes, já STAMATIS (1995) diz que o número deve variar de cinco a nove
pessoas, mas cinco é um bom número. O que se pode observar nasequipes é que os
engenheiros de projeto e processo quase sempre devem estar presentes nas equipes.
PALADY (1997) recomenda que uma pessoa deve ser responsável pela duração do
FMEA, pelo orçamento e pela eficácia do FMEA, enquanto que a equipe deve ser responsável
em desenvolver a FMEA. O procedimento FMEA apresentado pela Ford tem um ponto de
vista semelhante ao de PALADY (1997) e concordam que embora a preparação do FMEA
seja designada a um indivíduo, a contribuição do FMEA deve ser um esforço de equipe.
A equipe deve estar selecionada pelas áreas envolvidas de modo que cada membro
contribua com diferentes experiências e conhecimentos. A equipe define os pontos e
problemas, identifica e propõe idéias, fornece e recomenda análises ou técnicas apropriadas, e
toma uma decisão baseada num consenso, que é uma decisão coletiva alcançada através da
participação ativa de todos os membros.
STAMATIS (1995) salienta que não é necessário que haja concordância das idéias em
100 por cento, mas todos os membros devem estar comprometidos com a decisão.
Tanto STAMATIS (1995) como PALADY (1997) concordam que não se deve usar como
regra a decisão da maioria, pois isto não garante que esteja correta. Pode-se afirmar que os
princípios democráticos são válidos para o relacionamento entre os membros da equipe, mas a
decisão final deverá ser de consenso.
Para alcançar um consenso, cada membro do time deve estar disposto a:
- Receber ideias;
- Ter uma postura para contribuir e não defender;
- Ouvir ativamente os outros pontos de vista;
- Verificar e descobrir as razões das outras opiniões;
- Confrontar com as diferenças de maneira não agressiva;
Estes itens foram apresentados por STAMATIS (1995) e se assemelham bastante com
as regras usadas no Brainstorming. Afinal, uma equipe de Brainstorming também é composta
por pessoas de vários setores, que exercem diferentes funções e estão reunidas com um
objetivo em comum. No anexo 3 são apresentadas algumas equipes FMEA sugeridas por
STAMATIS (1995) e PALADY (1997).
A eficiência e a produtividade do FMEA podem ficar comprometidas quando
STAMATIS, 1995):
- O propósito da reunião não estiver claro;
- A reunião for mantida apenas para “cumprir tabela”;
- Houver repetição de informações antigas;
- Forem tratados assuntos muito enfadonhos; assuntos triviais;
- O líder reprime o time;
- A equipe for constituída de membros despreparados;
- As tarefas forem definidas superficialmente;
- Existir pouco tempo ou vontade para tratar com situações inesperadas;
Quando a equipe continua a se reunir sem a verificação dos itens acima, erros ocorrem,
como por exemplo:
• Erros causados por mal entendimento;
• Descoberta da necessidade de buscar informações adicionais;
• Dados incompletos porque o formulário é muito difícil de se completar;
• Falha no uso de dados existentes;
STAMATIS (1995) salienta que todos os membros da equipe devem ter algum
conhecimento do comportamento do grupo, das tarefas, dos problemas a serem discutidos, das
pessoas relacionadas direta ou indiretamente com o problema. Acima de tudo, eles devem
estar dispostos a contribuir. Uma equipe é um grupo de indivíduos que estão comprometidos
em alcançar objetivos organizacionais em comum, que se encontram regularmente para
identificar e resolver problemas, que buscam melhorar os processos, que trabalham juntos de
maneira eficaz e interagem abertamente. As equipes multidisciplinares podem e devem fazer
uso de ferramentas como, FTA, Brainstorming e QFD. Na equipe é necessário que haja um
coordenador que tenha conhecimento a respeito deFMEA para orientar as reuniões. Os
membros da equipe são escolhidos em função do problema, pois cada produto possui
características particulares como função, projeto, materiais, fabricação, qualidade. É muito
importante que os membros participantes tenham conhecimento das definições utilizadas no
FMEA e também conhecimento do produto na respectiva área.
 3.5.10 Procedimento geral para a execução do FMEA/FMECA

Os procedimentos descritos pelos autores são baseados na experiência de cada um. Estes
procedimentos foram agrupados no Quadro 13. sendo possível verificar que as sequências de
algumas etapas são coincidentes e existe pouca variação entre um procedimento e outro. As
etapas descritas são referentes ao FMECA. Para o FMEA, como foi discutido anteriormente,
não existem as etapas referentes à avaliação da criticidade (NPR).

Quadro 14 – Procedimentos para o desenvolvimento do FMECA.

Estudando as experiências transmitidas pelos autores STAMATIS (1995),

VILLACOURT (1992), KUME [1996], PALADY (1997), FORD (1997), sentiu-se
necessidade de aproximar o conhecimento apresentado, ao que se entende ser necessário
aplicar, quando se vai iniciar um processo de FMEA/FMECA. Estas proposições são
resultados das discussões feitas com os participantes dos processos de FMEA que serão
apresentados em outro capítulo.

1. Escolha dos membros da equipe

Um dispositivo para desempenhar qualquer função, por mais simples que seja, requer
itens caracterizados por: funções, materiais, acabamentos, tolerâncias e qualidade. A
aplicação do FMEA a um desses itens, em qualquer fase do ciclo de vida, vai exigir
diversidade, qualidade e profundidade de informações. Este grau de exigência só poderá ser
suprido quando se dispõe de uma equipe de trabalho com especialistas das diversas áreas
relacionadas comprometidos com o método e com o produto em análise.
No quadro 14 foi apontado ser obrigatório pelo menos a presença de um responsável
pelo projeto e pelo sistema. Na experiência vivida percebeu-se que é preciso ter um
responsável pelo projeto ou sistema que vai preparar os aspectos relacionados com o projeto,
como modelo físico, modelo confiabilíssimos, diagramas, fotografias, e vai implementar as
decisões das reuniões. E também é necessário ter um líder de FMEA, ou especialista em
FMEA para dirimir as dúvidas conceituais relativas ao que é modo de falha, efeito, função,
causa, FMEA de componente, FMEA de sistema, além de organizar e registrar as informações
nos formulários.

2. Definição do sistema e dos componentes

O sistema é definido nesta etapa e é feita a lista dos componentes que constituem o
sistema. Um componente não precisa ser necessariamente uma peça do equipamento. Quando
existirem muitos componentes, deve-se racionalizar a análise e procurar buscar os
componentes que ao falharem podem comprometer a função, a segurança, a ergonomia, bem
como aqueles que tem a taxa de falha mais elevada, componentes novos, componentes que
sofreram manutenção, enfim deve-se analisar os pontos que sofreram mudanças. Um
subsistema também pode ser considerado como componente. Dependendo da complexidade
do sistema agrupam-se os componentes em subsistemas tratando-os como um componente
único. A definição do sistema e dos componentes é muito importante para a aplicação das
definições dos modos de falha e dos efeitos. Os modos de falha estão associados aos
componentes, enquanto que os efeitos estão associados ao sistema. A preparação deste
contexto pode ser feita pelo líder do projeto e pelo líder de FMEA.
3. Diagrama funcional de blocos, fluxogramas, modelos confiabilíssimos.
Os diagramas funcionais de blocos, fluxogramas ou modelos confiabilíssimos são
utilizados para mostrar como as diferentes partes do sistema interagem umas com as outras,
facilitando a verificação dos caminhos críticos e o entendimento do sistema.
Os Diagrama funcional de blocos e fluxogramas são facilitam a análise dos sistemas,
permitindo uma melhor visualização do problema. São etapas que aparecem formalmente nos

procedimentos descritos por VILLACOURT (1992) e STAMATIS (1995), sendo que o

último sugere o uso do diagrama funcional de blocos para os FMEAs de sistema e projeto e o

fluxograma para o FMEA de processo.

É possível desenvolver o FMEA sem o auxílio dos diagramas, mas a análise do sistema

se torna muito mais difícil e a chance de se esquecer de algum detalhe se tornam maior. Nesta

fase, a participação de um especialista em confiabilidade e na ferramenta auxiliar de análise

utilizada, torna-se recomendável.

4. Funções dos componentes

A descrição da função deve ser exata e concisa. As funções são muito importantes
porque são uma grande referência para os modos de falha, especialmente quando se está
utilizando a abordagem funcional. A descrição da função deve ser preparada pelo projetista e
colocada em discussão para todos os membros do processo de análise de FMEA.

5. Modos de falha de cada componente

Modo de falha é um estado anormal de trabalho, uma anomalia apresentada pelo item
que está sendo analisado. Os componentes constituintes do sistema são analisados, sendo
levantados todos os seus respectivos modos de falha. Devem-se perguntar quais as possíveis
maneiras do componente em estudo se apresentar defeituoso? Como ele pode deixar de
executar a sua função para o qual foi projetado? A análise deve ser feita levando-se em
consideração a função do componente e as especificações de projeto. Se existe um modo de
falha, deve-se levá-lo em consideração, pelo menos no início do processo. Se o modo de falha
for tecnicamente possível de ocorrer, ele deve ser levado em consideração. A Figura 4.9 é
usada para mostrar que a análise dos modos de falha é uma ação interna ao sistema, em última
análise, está relacionado com o componente. Nesta etapa, geralmente ocorrem discussões a
respeito da classificação da falha. Vale ressaltar aqui que, nem sempre é possível classificar
uma falha como modo de falha, causa ou efeito.

6. Efeitos causados no sistema

O estudo e a identificação dos efeitos é fundamental tanto para o projetista quanto para
quem trabalha com processo. É um requisito fundamental para incorporar aos itens conceitos
de mantenabilidade e processos de manutenção como manutenção centrada na confiabilidade
e manutenção centrada na produtividade. Uma vez que se tem clareza de como os modos de
falhasse manifestam, pode-se projetar sensores para captar estas informações. Estes sensores
 vão anunciar quando se está iniciando um processo de falha, o que permitirá programar as
ações corretivas. A análise dos efeitos requer aprofundar o conhecimento e a percepção sobre
o sistema de um ponto de vista mais externo. Aqui interessa saber as informações que o
sistema está emitindo. É muito importante que se tenha à disposição uma lista de funções do
sistema para auxiliar o desenvolvimento da listas de efeitos que podem ocorrer. Os efeitos dos
modos de falha ocorrem ao nível de sistema e refletem sobre o cliente (externo ou interno).
Quando chega a este ponto, ainda dentro do período de vida útil, tem-se um problema, cuja
solução sempre é custosa, como visto na figura acima.

7. Avaliação dos efeitos e análise das causas dos modos de falha

Para a avaliação dos efeitos são usadas algumas escalas para estimar o impacto com
relação à segurança do cliente, meio ambiente, normas governamentais, imagem da empresa
ou custos. As escalas utilizadas para a avaliação não são precisa, variando com o autor,
análise, tipo de produto, empresa. O Quadro 12 e Quadro 15 são exemplos de escalas de
severidade utilizadas para a avaliação.

Quadro 15 – Categorias ou riscos para avaliar a gravidade da falha (DE CICCO e FANTAZZINI, 1988).

São verificados os modos de falha relacionados com os efeitos que obtiveram uma
classificação elevada e então se inicia o trabalho de levantamento das causas destes modos de
falha. Neste contexto e para esta atividade a equipe de FMEA deve estar o mais completa
possível.

8. Revisão do formulário e seleção das ações principais.

O processo de revisão deve iniciar a partir dos registros, inicialmente, estabelecidos.
Evidentemente para ser deflagrado um processo de FMEA necessidades, requisitos e metas
foram estabelecidas. Então o processo de revisão deve incorporar todos estes parâmetros.
 Nesta etapa também são definidas as ações de melhoria, data de implementação e os
responsáveis pelas ações. PALADY (1997) salienta que as ações de melhorias recomendadas
devem resultar em benefícios de qualidade e confiabilidade.
Recomenda-se que a equipe utilize técnicas de solução de problemas em suas revisões,
como por exemplo, Brainstorming, diagramas de pareto as quais são muito eficazes e úteis.
Neste contexto os formulários devem estar preenchidos, principalmente, naqueles contextos
para o qual a reunião foi convocada. A ação de FMEA é um exercício de conhecimento
constante e por isso precisa ser executado por etapas.

3.5.11 Resultados e benefícios obtidos com o FMEA/FMECA

O Quadro 16 foi gerado a partir da informações colhidas da obra de STAMATIS (1995).

A proposta é apresentar uma síntese resumida do conceito geral do FMEA proposto pelo
autor.

Quadro 16 – Resultados e benefícios obtidos com o FMECA

 3.5.12 Comentários

Com o estudo de FMEA/FMECA foi possível constatar que:

• O procedimento para a aplicação no projeto ou no processo de fabricação é
praticamente o mesmo.
• Quase sempre haverá a presença do engenheiro de projeto ou processo porque é
necessário que se conheça bem o sistema em análise.
• As informações mais importantes para a execução do FMEA são: desenhos,
protótipos, descrição das funções (componentes, sistema), especificações de projeto e
processo, diagramas de blocos (fluxogramas, modelos confiabilíssimos).
• As particularidades relacionadas aos processos FMEA/FMECA como mostram as
quadros 11,12 e 13, estão relacionadas aos índices que caracterizam o número de prioridade
de risco (NPR). Embora estejam disponível na literatura e em normas, os escores que definem
as métricas associadas aos índices podem ser redefinidos pela equipe que faz a execução do
FMEA/FMECA.
A opção de se aplicar um FMECA ao invés de FMEA está centrada, em controlar a
severidade e a probabilidade de ocorrência. Esta necessidade está mais fortemente presente
nos itens reparáveis e em sistemas de produção contínua ou que envolvam riscos de acidentes.
Em itens não reparáveis, nos casos em que é desejável e suficiente ter a confiabilidade e a
mantenabilidade como referências, é recomendável utilizar o FMEA.
3.6 Análise de Árvores de Falhas (AAF)

3.6.1 O Método Dedutivo

Ao igual que os métodos indutivos, os métodos dedutivos são muito utilizados nas
análises de sistemas, porém, eles fornecem um enfoque mais efetivo e versátil para o análise
preditivo de identificação dos riscos. Os conceitos básicos envolvidos podem ser usados para
fazer avaliações simples e podem também ser usados para fazer avaliações quantitativas. Os
custos de fazer este tipo de estudo aumentam proporcionalmente com a complexidade e o
escopo do trabalho, portanto é necessário um ponto de vista seletivo quando se planeja uma
análise deste tipo para garantir que seu custo se justifique pelos riscos que estão sendo
identificados e avaliados.
O enfoque dedutivo começa com a definição do evento não desejado, um acidente
imaginado ou real no caso de uma investigação, e organiza graficamente, em forma
sistemática todos os eventos conhecidos, falhas e acontecimentos (dentro do contexto do
módulo do sistema estabelecido) que possam contribuir ou causar o acontecimento do evento
não desejado.

A informação organizada dentro dos formulários da Análise Preliminar de Riscos ou

Análise de Modos e Efeitos de Falhas fornecerão informações muito importantes para este
tipo de análise. O modelo lógico mais comumente utilizado dentro das análises de Segurança
de Sistemas é a análise da Árvore de Falhas, (AAF).

3.6.2 Descrição geral do método

A análise da Árvore de Falhas foi desenvolvida pelos engenheiros do Laboratório da

Bell Telefhone Company no início dos anos 60, e tem continuado a receber contínuas
melhoras, especialmente na área de avaliação matemática. Para os efeitos desta discussão,
todos os exemplos serão baseados nas técnicas atuais da AAF, porém, outros métodos e
técnicas estão sendo desenvolvidos e utilizados em aplicações específicas.
Em resumo, as cinco etapas básicas utilizadas na análise da árvore de falhas são:
1- Escolha do evento não desejado a ser analisado, e definir a configuração do sistema,
módulo, ciclo de vida e ambiente do objetivo do estudo.
2- Obter informações, desenhos e qualquer outro tipo de informação disponível para ter
um bom entendimento do sistema a ser analisado.
3- Construção do diagrama lógico da árvore de falhas. (veja a descrição da continuação
a continuação)
 4- Avaliar o diagrama lógico (utilizando os enfoques objetivos definidos)
5- Preparar um resumo das conclusões da análise da árvore de falhas para serm
apresentadas e analisadas pela gerência.

3.6.3 Características

Objetivos: A análise da árvore de falhas é identificar as combinações das falhas nos

equipamentos ou componentes de um sistema ou erros humanos que podem resultar em um
acidente
Quando usar:
a) Projeto. A AAF pode ser usado na fase de projeto de um sistema ou planta para
descobrir modalidades de falhas ocultas, que resultam das combinações das falhas dos
equipamentos ou componentes ou por erros de operação. (humanos)
b) Operação. A AAF incluindo características de procedimentos de operação e do
operador, pode ser usado para estudo um sistema em operação, a fim de identificar
combinações potenciais de falhas que possam causar acidentes.
Tipos de resultados: Uma listagem dos conjuntos de falhas do equipamento e/ou
operação que possam resultar num acidente específico. Estes conjuntos podem ser
classificados qualitativamente de acordo com sua importância.
Natureza dos resultados: Qualitativos, com potencial de ser quantitativos. A árvore de
falhas pode ser avaliada quantitativamente quando as probabilidades de falhas dos
componentes é conhecida.
Informações necessárias:
a) Completo conhecimento da operação e funcionamento dos componentes dos
sistemas.
b) Conhecimento das modalidades de falhas dos componentes do sistema e seus efeitos
sobre ele. Esta informação pode ser obtida de uma análise de FMEA.

Pessoal necessário: A análise da árvore de falhas deve ser realizada por uma analista
responsável com consultas a engenheiros e a pessoal com experiência no sistema incluído na
análise. Uma análise mediante uma equipe é mais eficiente, cada membro da equipe se
concentrando em uma árvore individual ou uma rama da árvore principal.
Tempo e custo: O tempo e custo necessário para realizar a análise dependerão em
grande parte da complexidade do sistema a ser analisado, a gravidade das conseqüências e di
nível da resolução determinado. A realização de uma pequena unidade de processo pode levar
uma dia ou mais com uma equipe experiente e com bastantes conhecimentos do sistema.
Grandes acidentes potenciais e sistemas complexos podem precisar de uma semana ou mais.
3.6.4 Aplicação do método

AAAF é uma ferramenta amplamente usada para análise de segurança de sistemas. Uma
das vantagens do método é a de ser muito sistemático e analisar todas as falhas que poderiam
resultar num acidente.

A AAF possibilita a não ocorrência de um acidente quando fornece dados sobre falhas
do equipamento ou de operação (erro humano). Cada uma das causas imediatas é examinada,
até que o analista tenha identificado todas as causas básicas do evento. A árvore de falhas é
um diagrama que mostra a inter-relação lógica entre estas causas básicas e o ambiente.

O resultado da AAF é uma lista de combinações da falhas do equipamento ou de

operação que são suficientes para identificar aquelas que são significativas para o
desenvolvimento do evento. Estas combinações de falhas são conhecidas como CONJUNTO
DE REDUÇÃO MÍNIMA. Cada conjunto de redução mínima é a menor redução de falhas
que são suficientes para causar o acidente ou evento quando aquelas causas se apresentam
simultaneamente.

3.6.5 Símbolos lógicos usados na AAF

A realização da AAF é uma representação gráfica da inter-relação entre as falhas de

equipamentos ou de operação que podem resultar em um acidente específico. Os símbolos
mostrados a seguir são usados na construção da árvore para representar está inter-relação.

Portão “OU”: indica que a saída do evento ocorre

quando há uma entrada de qualquer tipo.

Portão “E” : indica que a saída do evento ocorre

somente quando há uma entrada simultânea de todos os
eventos.

Portão de Inibição : indica que a saída do evento ocorre

quando acontece a entrada e a condição inibidora é
satisfeita.
 Portão de Restrição: indica que a saída do evento ocorre
quando a entrada acontece e o tempo específico de atraso
ou restrição expirou.

Evento Básico: representa a FALHA BÁSICA do

equipamento ou falha do sistema que não requer outras
falhas ou defeitos adicionais.

EVENTO INTERMEDIÁRIO: representa uma falha

num evento resultado da interação com outras falhas que
são desenvolvidas através de entradas lógicas como as
acima descritas.

EVENTO NÃO DESENVOLVIDO: representa uma

falha que não é examinado mais, porque a informação
não está disponível ou porque suas consequências são
insignificantes.

EVENTO EXTERNO: representa uma condição ou um

evento que é suposto existir como uma condição limite
do sistema para análise.

TRANSFERÊNCIAS: indica que a árvore da falhas é

desenvolvida de forma adicional em outras folhas. Os
símbolos de transferência são identificados através de
números ou letras.

3.6.6 Definições de termos utilizados na analise de árvores de falhas

As falhas e defeitos dos equipamentos ou sistemas que são descritos na análise de

árvore de falhas podem ser agrupados em três classes:
 1- Falhas e defeitos primários
2- Falhas e defeitos secundários
3- Falhas e defeitos de comandos

1- Falhas e Defeitos Primários

São no sistema devido ao mal funcionamento de equipamentos que podem ocorrer no

ambiente e condições para o qual o equipamento foi projetado, por exemplo: um selo de
bomba centrífuga que se rompe nas condições normais de operação da bomba. As falhas
primárias são de responsabilidade específica do equipamento e não podem ser atribuídas a
outras causas ou condições externas.

2- Falhas e Defeitos Secundários

São falhas no sistema devido ao mal funcionamento que podem ocorrer em ambientes
para o qual o mesmo NÃO foi projetado, por exemplo: o selo da bomba centrífuga que se
rompe por excesso de pressão devido a que a bomba ficou funcionando com a descarga
bloqueada. Essas falhas são atribuídas a causas ou condições externas.

3 - Falhas e defeitos de comandos

São falhas no sistema devido a mal funcionamento do equipamento no qual o comando

opera, mas em um tempo ou local errado, por exemplo: um alarme de alta temperatura que
não funciona devido a uma falha no sensor de temperatura no processo,. A falha do alarme é
uma falha de comando e falha do sensor é uma falha primária.

3.6.7 Guias para uso do método analítico

Existem quatro etapas na construção de uma árvore de falhas:

1. Definição do problema
2. Construção da árvore de falhas
3. Solução da árvore de falhas
4. Determinação do conjunto mínimo

1. Definição do Problema

A definição do problema consiste em:

• Definir o EVENTO PRINCIPAL, que será o objeto da análise da árvore de falhas;
• Definir as condições limites do análise incluindo:
a) Eventos não considerados.
 b) Eventos considerados
c) Limites físicos do sistema
d) Nível de resolução
e) Outras suposições

a) Definir o EVENTO PRINCIPAL

O EVENTO PRINCIPAL é o mais importante aspecto da definição do sistema. Pode
ser um evento ou acidente indesejável que afetará de forma significativa o desempenho do
sistema. A definição desse evento deve ser o mais exata possível. Deve indicar QUAL é a
falha, ONDE acontece a falha e QUANDO acontece a falha.

b) Definir os EVENTOS CONSIDERADOS

É importante listar todos os eventos relacionados com o evento principal que serão
considerados durante a análise do sistema, e as interfases com outros sistemas de serviço ou
suporte. Uma forma de definir esses eventos é analisar qual é sua contribuição para o
desenvolvimento ou conseqüência do evento principal.

c) Definir os LIMITES físicos do sistema

Devem ser definidos os limites físicos do sistema que será analisado, os quais
englobam todos os equipamentos que deverão ser considerados na análise da árvore de falhas.
Uma forma prática de definir os limites e marcar no fluxograma de processo os equipamentos
serão considerados.
d) Definir o NÍVEL DE RESOLUÇÃO
Junto com os limites físicos do sistema, o analista deve especificar o nível de resolução
da análise, o qual determinará a quantidade de detalhes a ser incluída na análise.
Por exemplo, um motor que opera uma válvula pneumática de controle remoto pode ser
incluído como um simples equipamento, ou pode ser descrito como diversos itens mecânicos
(corpo, cilindro, etc.) Também podem ser incluídos os sistemas de operação como o
suministro de ar, etc. Um fator a ser considerado na decisão do nível de resolução é a
quantidade de detalhes disponíveis nas falhas do sistema, para isto, em casos de sistemas
críticos, uma análise de Modos e efeitos de falhas (FMEA) deverá ser realizado previamente.
e) Outras Suposições
O analista deve especificar outras suposições quando sejam necessárias para definir o
sistema da forma mais completa possível, como por exemplo, o modo de operação do sistema,
capacidade, etc.
 2. Construção de Árvore de Falhas
A construção da árvore de falhas inicia-se com o EVENTO PRINCIPAL e continua,
nível por nível, até que todos os eventos relacionados com o evento principal tenham sido
desenvolvido até suas causas básicas (EVENTOS BÁSICOS)
O analista começa com o evento principal e no nível seguinte, determina as causas
imediatas que causam o evento principal. Geralmente, estas não são causas básicas e sim
causas intermediárias que demandam um desenvolvimento adicional. Caso o analista possa
determinar imediatamente as causas básicas do evento principal, problema não é adequado (é
simples demais) para se promover uma análise tão complicada como uma árvore de falhas,
deverá ser usado um método mais simples e menos custoso.
Se forem exigidas todas as causas imediatas para a ocorrência do evento principal, então
as causas serão ligadas ao evento através de um portão lógico “E”, então, cada uma das causas
imediatas é tratada da mesma maneira que o evento principal e suas causas imediatas,
necessárias e suficientes serão identificadas e indicadas na árvore de falhas com a entrada
lógica adequada. Caso só uma das causas é suficiente para que o evento principal aconteça,
serão ligadas ao evento através de um Portão lógico “OU”.

3.6.8 Regras para construção da árvore de falhas

Há diversas regras básicas que devem ser seguidas na construção de uma árvore de
falhas, elas são:

a) Registras o evento de falha.

Escreva o evento dentro do símbolo correspondente com precisão e escreva um relato
separado indicando como aconteceu, onde aconteceu e quando.
A condição “quando” indica o estado do sistema no tocante ao equipamento
informando desta forma o porque do estado do equipamento que se encontra em situação de
“falha”. Estes relatos devem ser o mais completos possíveis e o analista deve resistir a
tentação de abreviá-lo ou utilizar palavras usadas só pelo pessoal da planta ou processo.

b) Avaliação do evento de falha

Ao se avaliar um evento de falha, deve-se fazer a pergunta:
-“Esta falha pode ser causada pelo mal funcionamento do equipamento?”
Se a resposta for sim, classificar o evento como “falha no estado do equipamento”. Se
a resposta for não, classificar o evento como “falha do sistema”, esta classificação ajudará no
desenvolvimento posterior da análise. Se o evento for classificado como falha do
equipamento, acrescente uma entrada “OU” ao evento falho e procure as razões para esta
falha de equipamento, sejam primárias ou secundárias. Caso o evento falho estiver nas
“falhas do sistema” procure então as causas imediatas e necessárias para que aconteça o
evento.
c) A regra “sem milagres”
Se o funcionamento normal do equipamento provoca uma seqüência de falhas,
considere então que o equipamento funciona normalmente. Jamais considere uma falha como
“milagre”, ou totalmente não esperada.
d) A regra “complete toda entrada cada vez”
Todas as entradas necessárias para que aconteça um evento devem ser analisadas e
registradas antes de se passar para um outro evento. A árvore de falhas deve ser completada
em níveis e deve-se completar cada nível antes de iniciar a análise do próximo.
e) A regra do “não há entrada de evento para evento”
As entradas devem ser adequadamente definidas como eventos de falhas, e estarem
ligadas sempre através de um portão lógico.
As regras (C) e (E) tem por finalidade enfatizar quão importante é ser esquemático e
metódico ao construir uma árvore de falhas. Estas regras proíbem atalhos que levam a árvores
incompletas ou mal analisadas.
3. Solução da Árvore de Falhas
A árvore de falhas acabada fornece muita informação útil através de uma demonstração
gráfica e lógica da seqüência de falhas que poderiam resultar num acidente, entretanto, exceto
no caso de árvores de falhas muito simples, nem mesmo um analista experimentado poderá
identificar diretamente da árvore de falhas, todas as combinações de falhas que levam ao
acidente.
As árvores de falhas podem ser resolvidas através de métodos matemáticos, como a
álgebra de Boole, o mediante um método de resolução através de matrizes. Ambos os
métodos dão como resultado as séries de cortes mínimos que indicam as combinações de
falhas de equipamentos ou sistemas que podem resultar no evento principal. As séries
mínimas de corte são úteis para hierarquizar os modos pelos quais o acidente pode ocorrer, e
permitem quantificar a probabilidade de falha da árvore, caso se tenham as informações
suficientes.
Não sendo o escopo de nosso estudo a solução das árvores de falhas, indicaremos um
método geral que se aplica para todas as soluções.
 O método para a solução das árvores de falhas tem quatro etapas:
a) Identificar exclusivamente todas as entradas e os eventos Básicos
b) Simplificar todas as entradas nos eventos Básicos
c) Retirar os eventos duplicados da árvore
d) Suprimir todas as superséries (séries que contêm outra série como sub-série)
O EVENTO BÁSICO ( ou inicial) é sempre a primeira entrada da matriz e deve ser
claramente definido no início da resolução.

3.6.9 Hierarquização da série de cortes mínimos

A hierarquização das séries de cortes mínimos é o passo final dos procedimentos

analíticos da árvore de falhas. Para se fazer uma hierarquização qualitativa, podem ser
considerados dois fatores:

O primeiro é a importância estrutural, que é baseada no número de componentes de

eventos BÁSICOS que se encontram em cada série de cortes mínimos. Por exemplo, uma
série de corte mínimo de um evento é mais importante que uma série de cortes mínimos de
dois eventos, uma de dois eventos é mais importante que uma de três, e assim por diante.
Esta hierarquização significa que é mais provável que ocorra um evento que dois, dois
que três, etc.
O segundo fator considera a hierarquização dentro de cada tamanha de série de corte
mínimo, por exemplo, hierarquização das séries de cortes mínimos de dois eventos, baseado
no tipo de evento que constitui a série. A regra geral que orienta esta hierarquização é:

1. Erro humano
2. Falhas dos equipamentos ativos
3. Falhas nos equipamentos passivos

Esta hierarquização significa que os erros humanos têm mais probabilidade de acontecer
que as falhas de equipamentos ativos (em funcionamento) e que há mais probabilidades que
aconteça uma falha em um equipamento ativo que em passivo (parado).
Utilizando esta regra em uma lista de séries de cortes mínimos de dois eventos teríamos
a hierarquia mostrada na lista a seguir

LISTA DE HIERARQUIA DE EVENTOS 
HIERARQUIA EVENTO BÁSICO TIPO 1 EVENTO BÁSICO TIPO 2
 1 Erro humano
2 Erro humano Falha equipamento ativo
3 Falha equipamento passivo
4 Erro humano Falha equipamento ativo
5 Erro humano Falha equipamento passivo
6 Falha de equipamento ativo Falha equipamento passivo
Falha de equipamento ativo
Falha equipamento passivo

Embora sugerida pela experiência, estas hierarquias podem diferir significamente de

sistema para sistema, com base em fatores tais como qualidade do equipamento, revisões,
manutenção preventiva, treinamento dos operadores, etc.
O melhor método de hierarquização qualitativa consiste no fato de o analista exemine
detalhadamente cada corte mínimo em particular e estabeleça a série mais importante com
base na experiência real e operacional.

4 - Conclusão

Taxas de frequência e gravidade das lesões, não servem como critérios de eficiência de
segurança. Precisamos de medidas de desempenho que não necessitem da lesão para gerar
dados.
Se existir potencial para perdas, e ele sempre existe, precisamos preocupar com as
condições humanas e ambientais, mesmo que não fique evidenciada sua relação com a lesão.
Sabendo que estas condições são modificáveis, se corrigirmos ou fizermos adaptações
conseguiremos reduzir perdas por acidentes.
Hoje temos um processo de tentativa e erro, com o TIC podemos ter mais eficiência na
segurança, podendo identificar um problema antes do fato ocorrer e não ficar fazendo
experiência buscando melhorar após o fato ocorrer e sim evitar que ele ocorra.
A TIC tem a função de melhorar a capacidade de prever acidentes, através da pesquisa de
campo com os colaboradores, podemos identificar possíveis ameaças de acidente e assim
fazermos alterações de lay-out, transferência de colaborador de setor, etc., assim buscando
uma redução de acidentes com lesão e prejuízos.

5 - Referências Bibliográficas

Apostila de engenharia de segurança do trabalho da UFF Universidade Federal Fluminense

Metodologias de análise de riscos APP e HAZOP. Profª Laís Alencar da Silveira de Aguiar,
Rio de Janeiro
Norma ABNT ISO 31.001: 2009 (Sistema de Gestão de Risco) ABNT- Brasil, RJ 2009
MORAES, Giovanni de Araújo. Sistema de Gestão de Segurança e Saúde Ocupacional –
OHSAS 18.001 comentada. Brasil, RJ. 2006.

Gerenciamento Verde Editora e Livraria Virtual.

Norma ABNT ISO Guia 73:2009 (Guia de Sistema de Gestão de Riscos). ABNT, RJ.

DE CICCO & FANTAZINNI, Introdução à Engenharia de Segurança de Sistemas,

FUNDACENTRO, SP-Brasil, 1994, 3ª edição.

BRASIL, Fernando, Notas de Aula, Curso de Técnicas de Análise de Riscos, 2002, RJ.
TECNOLOGIAS CONSAGRADAS DE GESTÃO DE RISCOS.

Coletânea "Técnicas Modernas de Gerência de Riscos" e do livro "Introdução à Engenharia de

Segurança de Sistemas", de autoria de Francesco De Cicco e Mario Luiz Fantazzini.
PONTE, Marcus Vinicius Vidal, Gerenciamento de Riscos, Secretaria da Receita Federal 4º
Prêmio Schöntag, 2005, RJ

AGUIAR, L.A.A. et al.A Termelétrica de Santa Cruz: Laboratório Químico e

Operações com Produtos Químicos na Área Industrial. Monografia do curso de
Especialização em Eng. de Segurança do Trabalho UFRJ. Rio de Janeiro, 2001.
CARDELLA, Benedito. Segurança no Trabalho e Prevenção de Acidentes. Uma
Abordagem Holística. São Paulo: Atlas, 1999.

DE CICCO, Francesco, FANTAZZINI, Mario Luiz. A identificação e análise de riscos.

Revista Proteção - Suplemento especial n.2, Novo Hamburgo, n.28, abril, 1994b.

FREITAS, Luís. (2003). Gestão da segurança e saúde no trabalho – Volume 1. 1.ª Edição.
Edições Universitárias Lusófonas, Lisboa.

LEES, F.P. Lees’ Loss Prevention in the Process Industries, 3 a Edição, Sam Mannan,
2005.
Schmitz, Juliana Aplicação Do Hazop Dinâmico Na Avaliação De Perigo Operacional Em

Uma Coluna De Destilação De Uma Planta De Separação De Ar, Dissertação de

Mestrado, novembro,2009.

AGUIAR, L. A. Metodologias de análise de riscos App & hazop, Rio de janeiro,

2001.http://professor.ucg.br/SiteDocente/admin/arquivosUpload/13179/material/APP_e_HAZ
OP.pdf

CAGNO, E.; CARON, F.; MANCINI, M.Multilevel Hazop For Risk Analysis In Plant
Commissioning. Reliability Engineering & System Safety. Italia.v.77, n. 3, p. 309-323, set.
2002.

CARDELLA, Benedito. Segurança de processo em novas unidades industriais. Gerência de

Riscos, São Paulo, n. 13, p. 8-12, jul/ago 1989.

KING, Ralph; HIST, Ronald. King’s safety in the process industries. 2 ed., Inglaterra:
Hodder Headline Group,1998. 661 p.

NOLAN, Dennis P. Application of HAZOP and What-If safety reviews to the petroleum,
petrochemical & chemical industries. New Jersey, U.S.A.: Noyes Publications, 1994.