Registrar | Login | Busca:
 
 
Sinônimos de tipos de conteúdo | Mais visitados |  

Home » Conteúdo » FMEA (Failure Mode and Effect Analysis)
 
 
FMEA (FAILURE MODE AND EFFECT ANALYSIS)
 
 
  • Visitas: 173815
    • Currently 3/5 Stars.
    • 1
    • 2
    • 3
    • 4
    • 5
  • Nota: 3/5 (2355 votos)
Melhores Práticas
FMEA (Failure Mode and Effect Analysis)
Criado por sayuri tahara ( USP - NUMA ) em 17 de Dezembro de 2008 - 09:34.
Atualizado por Carolina Amigo ( USP São Carlos ) em 16 de Novembro de 2012 - 16:48.
Sumário:
Descrição:

Objetivos dessa página

  • Fornecer uma visão ampla e superficial do FMEA, possibilitando ao usuário ter noções de como, quando e porquê aplicar o método
  • Fornecer informações sobre as limitações do método e dicas para evitar erros na execução do mesmo

Definição

FMEA (failure mode and effect analysis) é uma ferramenta usada para aumentar a confiabilidade de um certo produto durante a fase de projeto ou processo. A ferramenta consiste basicamente em sistematizar um grupo de atividades para detectar possíveis falhas e avaliar os efeitos das mesmas para o projeto/processo. A partir dessas possíveis falhas, identificam-se ações a serem tomadas para eliminar ou reduzir a probabilidade de que as mesmas ocorram. Essas ações também podem objetivar aumentar a probabilidade de detecção dessas falhas, para que os produtos que apresentam inconformidades não cheguem ao cliente.

Deste modo é obtida uma lista de possíveis falhas, organizada por ordem do risco que elas representam e com respectivas ações a serem tomadas para mitigá-las. Essa lista auxilia na escolha de projetos alternativos com alta confiabilidade durante as etapas iniciais da fase de projeto. Assim garante-se que todas as possíveis falhas de um projeto/processo sejam consideradas e suas probabilidades de ocorrência minimizadas (quando se fizer necessário).

Tipos de FMEA

Geralmente é aceito que existem quatro tipos de FMEAs. As etapas e a maneira de realização da análise são as mesmas, diferenciando-se principalmente quanto ao objetivo. Desta maneira, temos:

  • FMEA de design: São consideradas as falhas que poderão ocorrer com o produto dentro das especificações do projeto. O objetivo desta análise é evitar falhas no produto ou no processo decorrentes do projeto. É comumente denominada também de FMEA de projeto ou produto
  • FMEA de processos: São consideradas as falhas no planejamento e execução do processo, ou seja, o objetivo desta análise é evitar falhas do processo, tendo como base as não conformidades do produto com as especificações do projeto.
  • FMEA de sistemas: São considerados sistemas e subsistemas nas fases conceituais e de projeto. O objetivo desta análise é focalizar nos modos de falhas entre funções do sistema. São inclusas as interações entre sistemas e elementos dos sistemas.
  • FMEA de serviços: São analisados os serviços antes de eles atingirem o consumidor. É usado para identificar tarefas críticas ou significantes para auxiliar a elaboração de planos de controle. Ajudam a eliminar gargalos nos processos e tarefas.

Apesar de as etapas e a maneira de realização da análise serem as mesmas, existem pequenas variações entre cada tipo de análise. Um exemplo de diferença é a definiçã dos índices (serão descritos posteriormente) adotados na elaboração do FMEA.

Portanto, neste trabalho serão focados dois tipos de FMEA por serem os mais utilizados e conhecidos: FMEA de design e FMEA de processos.

Mecanismos

Os mecanismos utilizados no FMEA são relativemente simples. O método consiste basicamente em identificar e dispor todos os modos de falha em potencial em uma tabela que facilitará a sua interpretação.

Após os modos de falha estiverem sido dispostos na tabela, eles deverão ser analisados e classificados em relação à 3 aspectos: Severidade, detectabilidade e probabilidade. Pela multiplicação desses 3 índices, tem-se à disposição, os modos de falha ordenados de acordo com a sua importância. Desta maneira, obtêm-se uma tabela que auxilia na tomada de decisões de mudanças (relacionadas com o aumento de confiabilidade) no projeto .

Posteriormente, serão apresentadas explicações mais detalhadas sobre o funcionamento e elaboração de um FMEA.

Quando se deve utilizar o FMEA

Inicialmente o FMEA foi desenvolvido para ser usado na fase de projetos para evitar, através de análise de falhas em potencial e propostas de ações de melhoria, que ocorram falhas nos projetos de produtos/processos. Porém ela pode ser usada ao longo do ciclo de vida do produto para detectar possí­veis falhas à medida que o sistema envelhece.

É importante ressaltar que o FMEA deve ser constantemente revisado e atualizado. Durante a fase de projeto do produto, recomenda-se que se aplique ou atualize o FMEA durante os seguintes estágios:

  • Formulação do conceito
  • Projeto preliminar
  • Conclusão do projeto detalhado
  • Programas de melhoria do projeto

Possivelmente, nas fases iniciais de projeto, as informações sobre o produto estarão limitadas. Ainda assim, é possível desenvolver o FMEA respondendo a perguntas básicas como por exemplo:

  • Como cada parte do produto poderia falhar?
  • Quais mecanismos poderiam produzir estes modos de falha?
  • Quais seriam os efeitos se essas falhas ocorressem?
  • Essas falhas poderiam acarretar em algum perigo?
  • Como essa falha é detectada?
  • O que será planejado durante a fase de projeto para compensar a falha?

O FMEA também é utilizado em produtos que já estão em operação. Neste caso busca-se achar a causa raiz das falhas do sistema para propor soluções de melhoria. Assim, diferentemente do FMEA realizado na fase de projetos, não é necessário prever possíveis falhas, pois neste caso trabalha-se com falhas que já estão ocorrendo no sistema.

Benefícios e informações geradas pelo FMEA

O FMEA traz à empresa um melhor conhecimento dos problemas nos produtos/processos. O método gera uma forma sistemática de se hierarquizar informações sobre as falhas dos produtos/processos, estabelecendo-se, portanto, um sistema de prioridades de melhorias, investimento, desenvolvimento, análises teste e validação.

A aplicação da ferramenta gera arquivos que servem como uma referência para o futuro ao nível das evoluções possíveis, da documentação de erros do passado, do desenvolvimento de técnicas avançadas de projeto e do incentivo para a necessidade constante de desenvolvimento. Desta maneira são geradas ações de melhoria no projeto do produto/processo, que devem ser devidamente monitoradas (melhoria contínua).

Devido a essa documentação de riscos e prevenção de ocorrência de falhas, o tempo e o custo de desenvolvimento diminuem. Ao mesmo tempo a confiabilidade, qualidade e segurança do produto/processo aumentam.

Esse método ajuda a empresa a manter sempre o foco no cliente, garantindo sua satisfação e segurança. Assim, facilita a empresa a identificar características críticas para a qualidade.

A análise do FMEA pode ser um ponto inicial para vários outros tipos de análise, por exemplo:

  • Análise de sistema de segurança
  • Análise de planejamento de manutenção
  • Planejamento da produção
  • Análise de nível de reparos
  • Planejamento de testes
  • Análise de apoio à logística

Pode-se observar então, que o FMEA pode ser um método iterativo, pois à medida que são feitas análises adicionais, novas informações, que podem aumentar a precisão do método, surgem.

Há também o benefício de incorporar dentro da organização a atitude de prevenção de falhas, a atitude de cooperação e trabalho em equipe. Este último é importante para, entre outros aspectos, capturar o conhecimento coletivo de um time.

Limitações e abusos do FMEA

O FMEA é uma ferramenta extremamente eficiente se aplicada de maneira correta. Porém observa-se na prática muitos FMEAs que não apresentam resultados satisfatórios devido a extrapolação de seus limites pelos projetistas.

A eficácia da ferramenta está muito ligada a perícia do projetista, devido ao fato de que os modos de falha precisam ser previstos por ele. Algumas limitações do FMEA estão listadas abaixo:

  • O FMEA não pode ser feito até que o projeto tenha progredido a um certo ponto em que os elementos do sistema tenham sido selecionados até o nível que a análise deseja explorar
  • Se o FMEA for executado muito tarde, ele pode não impactar o projeto de modo eficaz e pode não garantir a confiabilidade do dispositivo
  • Freqüentemente erros humanos e ambientes hostis são negligenciados
  • Os efeitos combinados de falhas coexistentes não são considerados
  • Se o sistema for muito complexo e a análise se estender até o nível de subsistema (ou mais detalhado), o processo pode ser extremamente tedioso e consumir muito tempo
  • Probabilidades de falhas podem ser difíceis de se obter. Obter, aplicar e interpretar esses dados a sistemas únicos, introduz incertezas que são difíceis de se avaliar. Além disso, a maioria dos sistemas se degradam ao decorrer do tempo, portanto possuem status múltiplos.
  • FMEA não analisa perigos ou problemas quando o sistema está operando devidamente
  • É causado um impacto inicial no cronograma do produto e de manufatura
  • Há uma necessidade de se compor um time com uma característica interdisciplinar elevada e posteriormente treiná-los devidamente, gerando custos.

Deve-se tomar muito cuidado também para não se negligenciar alguns itens importantes, como por exemplo:

  • utilitários com Ex.: eletricidade, ar comprimido, água de arrefecimento, óleo lubrificante pressurizado, vapor, etc...
  • Atividades humanas de suporte - Ex.: processo de controle...
  • elementos de interface

Para não tornar o FMEA extremamente tedioso, deve-se ignorar alguns itens que não auxiliam a análise de falhas, como por exemplo:

  • elementos passivos em ambientes não hostis com Ex.: fios elétricos

Como fazer um FMEA

Nesta seção será descrito como fazer um FMEA passo a passo. Serão apresentadas, primeiramente, as informações necessárias para se iniciar a elaboração do FMEA. Posteriormente, será comentada cada coluna da tabela com dicas para a sua elaboração e exemplos.

Informações necessárias

As unidades de análise do FMEA são os sistemas, subsistemas e componentes, assim divididas a fim de sistematizar todo o projeto. Deve-se definir bem a abrangência dessas unidades, não somente ao nível de discretização das funções e desempenhos individuais, mas também no nível de interações entre todas elas. Isso se faz necessário porque alterações em um subsistema podem vir a causar alterações no funcionamento de outro subsistema. O fato de dois subsistemas não estarem contacto direto não significa que não possa haver interação entre eles.

Primeiramente deve-se definir o sistema a ser analisado e obter os desenhos, minutas, descrições, diagramas e listas de componentes. Defina bem o que está sendo analisado (uma área, atividade, equipamento...). Depois defina se deve-se analisar o sistema inteiro ou partes dele, e quais são os alvos a serem considerados (pessoal, produto, etc..).

Faça um WBS (Work Breakdown Structure ) até elementos convenientes e lógicos. Neste caso pode-se fazer tanto um WBS funcional (de acordo com as funções dos elementos do sistema) ou um de arquitetura. Pode-se considerar também a possibilidade de se fazer ambos.

Somente então deve realizar a análise dos elementos (FMEA). Na seção "material para download" está disponível um modelo de Tabela de FMEA para design.

Geral

  • Anexar na tabela todas as hipóteses feitas durante a execução do FMEA e também a definição de notas usadas.
  • Incluir no cabeçalho da tabela a data de revisão do documento
  • Todos os membros do time devem ser listados no cabeçalho da tabela
  • Incluir nome e número do produto (parte do produto) para fácil identificação do mesmo posteriormente

Função

  • Cada função deve ter uma medida associada
  • Cada função deve ser escrita em um contexto de verbo-substantivo
    • Exemplo:
      • O sistema ABC deve desembaçar vidros e aquecer ou esfriar a cabine até 20°C em todas as condições de operação (de -20°C à 50°C)
      • No tempo de 3 a 5 minutos

Modo de falha em potencial

  • Cada função deve ser escrita em um contexto de verbo-substantivo
  • Cada função deve ser escrita como uma antifunção
    • Existem 5 tipos de modo de falhas:
      • Falha completa
      • Falha parcial
      • Falha intermitente
      • Falha devido ao excesso da função
      • Função indesejada
      • Exemplo:
        • O sistema ABC não aquece o veículo nem desembaça o vidro
        • O sistema ABC leva mais que 5 minutos para aquecer a cabine
        • O sistema ABC não aquece o a cabine até 20°C em temperaturas abaixo de 0°C
        • O sistema ABC esfria a cabine para a temperatura de 10°C
        • O sistema ABC liga o desembaçador traseiro

Efeitos potenciais de falha

  • Os efeitos devem ser descritos do modo em que os clientes iriam descrevê-los
  • Efeitos devem incluir: segurança/ corpo regulador; cliente final; clientes internos - manufatura, montagem e serviços
    • Exemplo:
      • Não é possível ver além da janela da frente
      • O ar condicionado deixa a cabine muito fria
      • Não esquenta o suficiente
      • Leva muito tempo para aquecer

Severidade

  • Os índices de severidade devem corresponder, de preferência, aos índices pré-definidos na tabela 2
  • Caso opte-se por usar um critério interno para os índices de severidade, deve-se anexar ao FMEA uma referencia para as tabelas com os índices e explicações de como ela deve ser utilizada.
    • Exemplo:
      • Não é possível ver além da janela da frente com severidade 9
      • O ar condicionado deixa a cabine muito fria com severidade 5
      • Não esquenta o suficiente com severidade 5
      • Leva muito tempo para aquecer com severidade 4

Causas potenciais/mecanismos de falha

  • As falhas devem limitar-se aos interesses do projeto
  • A análise deve manter-se dentro do escopo definido (sistema que está sendo analisado e interface com outros sistemas)
  • Causas em nível de análise de componentes devem ser identificadas como características do sistema (características que podem ser controladas no processo)
  • Geralmente há mais de uma causa de falha para cada modo de falha
  • As causas devem ser identificadas para um modo de falha, e não para um efeito individual
    • Exemplo:
      • Posicionamento incorreto das saídas de ar do desembaçador
      • Caminho incorreto percorrido pelas mangueiras das saídas de ar (provavelmente muito próximas à s fontes de calor)
      • Capacidade inadequada de resfriamento para a aplicação em questão

Ocorrência

  • Os índices de ocorrência devem corresponder, de preferência, aos índices pré-definidos na tabela XXX
  • Caso opte-se por usar um critério interno para os índices de ocorrência, deve-se anexar ao FMEA uma referencia para as tabelas com os índices e explicações de como ela deve ser utilizada.
  • Os índices de ocorrência para o FMEA de projeto são baseados na probabilidade que uma causa pode ocorrer, de acordo com falhas passadas, performances de sistemas similares em aplicações similares.
  • Valores 1 de ocorrência devem ter dados que providenciam uma justificativa para tal valor. Esses dados, ou as fontes desses dados, devem ser incluídos na coluna de ações recomendadas.
    • Exemplo:
      • Posicionamento incorreto das saídas de ar do desembaçador com ocorrência 3
      • Caminho incorreto percorrido pelas mangueiras das saídas de ar (provavelmente muito próximas à s fontes de calor) com ocorrência 6
      • Capacidade inadequada de resfriamento para a aplicação em questão com ocorrência 2

Classe

  • A classificação é usada para definir características potencialmente críticas ou significantes
  • Características críticas (sugere-se que se utilize para severidades 9 ou 10 com ocorrência igual ou maior que 2) devem possuir uma ação recomendada associada
  • Características significantes (sugere-se que se utilize para severidades entre 8 a 4 com ocorrência igual ou maior que 4) devem possuir uma ação recomendada associada
  • Deve-se ter um critério bem definido para cada caso de aplicação caso opte-se por não usar a classificação sugerida
    • Exemplo:
      • Não é possível ver além da janela da frente com severidade 9 - Posicionamento incorreto das saídas de ar do desembaçador com ocorrência 3 - crítica

Controle atual de projeto

  • Controles preventivos são aqueles que ajudam a reduzir a probabilidade que um modo de falha ou causa de falha possa ocorrer com afetam o índice da ocorrência
  • Controles de detecção são aqueles que identificam problemas na fabricação dos produto com índice de detecção associado
  • Se os controles preventivos e de detecção não forem listados em colunas separadas, eles devem incluir uma identificação do tipo de controle (P ou D)
  • Exemplo:
    • Especificações de engenharia (P) com controle preventivo
    • Dados de projetos antigos (P) com controle preventivo
    • Teste funcional com controle de detecção
    • Durabilidade geral de um produto (D) com controle de detecção

Detecção

  • Os índices de detecção devem corresponder, de preferência, aos índices pré-definidos na tabela XXX
  • Caso opte-se por usar um critério interno para os índices de detecção, deve-se anexar ao FMEA uma referencia para as tabelas com os índices e explicações de como ela deve ser utilizada.
  • Detecção é o valor associado a cada tipo de controle de detecção
  • Valores de detecção igual a 1 devem eliminar o potencial para falha devido a deficiência de projeto
    • Exemplo:
      • Especificações de engenharia (P) com sem valor de detecção
      • Dados de projetos antigos (P) com sem valor de detecção
      • Teste funcional com detecção 3
      • Durabilidade geral de um produto (D) com detecção 5

RPN (número de prioridade de risco - risk priority number)

  • RPN é uma multiplicação dos índices de severidade, ocorrência e detecção.
  • É usado o índice mais baixo de detecção parar calcular o RPN
  • Não deve-se usar um limite de RPN como principal elemento para a definir ações recomendadas
    • Exemplo:
      • Não é possível ver além da janela da frente com severidade 9 - Posicionamento incorreto das saídas de ar do desembaçador com ocorrência 3 com teste funcional com detecção 3 com RPN 81

Ações recomendadas

  • Todas características críticas ou significantes devem ter ações recomendadas associadas a elas
  • As ações recomendadas devem focar no projeto e devem ser dirigidas no sentido de mitigar a causa da falha ou eliminar o modo de falha
  • Caso as ações recomendadas não consigam mitigar ou eliminar o potencial para falhas no projeto, as ações recomendadas devem forçar as características a sofrerem uma mitigação de processo o quanto antes em um FMEA de processo.

Responsáveis e data alvo de finalização

  • Deve haver uma pessoa designada para assumir a responsabilidade pelo cumprimento de cada ação recomendada
  • Deve-se colocar um nome e não um título para assumir a responsabilidade por cada ação.
  • Deve-se lembrar que somente pessoas listadas como membro do time podem ser listadas pela responsabilidade de uma ação
  • Deve haver uma data alvo de cumprimento da ação para cada ação recomendada

Resultado das ações

  • O campo ação tomada deve detalhar quais ações ocorreram e quais os resultados de cada ação tomada
  • As ações devem ser completadas até a data alvo de finalização da ação
  • Ao menos que o modo de falha tenha sido eliminado, a severidade não deve mudar.
  • O índice de ocorrência pode ou não diminuir baseado nos resultados das ações
  • O índice de detecção pode ou não diminuir baseado nos resultados das ações
  • Caso os índices de severidade, ocorrência ou detecção não tenham melhorado, devem ser definidas novas ações recomendadas.
Download: application/zip FMEA_atual_2012.zip 336,97 kB
Palavras-chave: Failure Mode and Effect Analysis, FMEA
Nó: 9428

Conhecimentos relacionados Xfmea - Software para Análise de FMEA e FMECA
Análise dos Efeitos e Criticidades dos Modos de Falha - FMEA & FMECA e Xfmea
FMEA - A Special Bibliography from the NASA Scientific and Technical Information (STI) Program
Failure Mode and Effects Analysis of Software-Based Automation Systems
APIS IQ-FMEA
Proposta de análise integrada de falhas potenciais de produto
An Improved Method of Failure Mode Analysis for Design Changes
Potential Failure Mode and Effects Analysis (FMEA) - Reference Manual, Fourth Edition
Innovation and learning: exploring feedback from service to design
Using causal reasoning for automated failure modes and effects analysis (FMEA)


Ver todos

Comentários

Log in ou crie uma conta de usuário para comentar.

        

Uso do FMEA na fase de comissionamento de Planta

Bom dia!

Muito bom o artigo!

Gostaria de saber quanto a eficiência da aplicação do FMEA em uma planta industrial em fase de comissionamento uma vez que mapeamos os sistemas e sub-sistemas desta planta de modo que consigamos identificar os efeitos e como não temos histórico de problemas por se tratar de uma planta que ainda não entrou em operação.
É possível obter resultados reais utilizando a experiência do time, o conhecimento de problemas de outras plantas do mesmo processo e indicação de falhas de equipamentos baseando-se na literatura de cada equipamento?

Solicitação de autorização.

Boa tarde!
Venho por meio deste recurso contata-lo com o intuito de autorização de uso do material aqui posto em ordem conceitual, faço o curso de Técnico de Segurança do Trabalho e o material disposto me atraiu, sendo assim gostaria de pedir a autorização do prezado introdutor do artigo para que possa utilizar, por obsequio, tópicos e pontos centrais na elaboração de um trabalho de manejo do FMEA.


Por obséquio estabelecer contato se possível.


Obg.



Amanda Caraça
amanda_esfinge@hotmail.com
katitatuzi@yahoo.com.br

 
 
Copyright © 2007 Portal de Conhecimentos