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.