FMEA - Análise de Modos de Falhas e Efeitos

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.

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.

E você, já aplica o FMEA na sua empresa? 

Tem alguma informação para acrescentar? 

Deixe seu comentário abaixo!