FMEA na Engenharia: como analisar modos, efeitos e causas de falha

FMEA aplicada à engenharia: funções, modos de falha, efeitos, causas, controles, severidade, ocorrência, detecção, RPN, Action Priority e aplicações.

Confira!

FMEA — Failure Modes and Effects Analysis, ou Análise dos Modos e Efeitos de Falha — é um método sistemático para identificar como um item, sistema, projeto ou processo pode falhar, quais efeitos essas falhas podem produzir, quais causas estão associadas e quais ações devem ser priorizadas para reduzir risco antes que o problema se materialize.

A força do método está menos na planilha e mais na forma de raciocinar. Uma FMEA bem conduzida obriga a equipe a esclarecer funções, interfaces, requisitos, falhas potenciais, mecanismos causais, controles existentes e evidências. Isso permite transformar conhecimento disperso de especialistas em uma análise estruturada e rastreável.

Embora seja muito conhecida na indústria automotiva, a FMEA não se limita a esse setor. A IEC 60812:2018 estabelece uma abordagem genérica aplicável a hardware, software, processos, ações humanas e interfaces. Já o manual AIAG & VDA fornece uma metodologia específica e harmonizada para aplicações automotivas de Design FMEA, Process FMEA e FMEA-MSR.

O que é FMEA

A FMEA parte de uma pergunta simples: de que forma esta função pode deixar de ser cumprida?

A partir dela, a equipe identifica modos de falha, efeitos e causas e avalia quais situações exigem tratamento. O método pode ser aplicado antes da implantação, durante revisões de projeto, em processos de produção, em modificações, na engenharia de manutenção ou na análise de sistemas existentes.

Segundo a IEC 60812:2018, a FMEA fornece um método sistemático para identificar modos de falha e seus efeitos locais e globais, podendo também incorporar suas causas. Os modos de falha podem ser priorizados para apoiar decisões de tratamento.

Uma análise típica conecta seis elementos:

1. função ou requisito;
2. modo de falha;
3. efeito da falha;
4. causa ou mecanismo de falha;
5. controles existentes;
6. ação necessária para reduzir ou controlar o risco.

Quando esses elementos são tratados apenas como colunas de formulário, a FMEA tende a se tornar burocrática. Quando são tratados como uma cadeia lógica de engenharia, o método ajuda a revelar riscos que ainda não apareceram em campo.

Função vem antes da falha

Um dos erros mais comuns é iniciar a FMEA listando defeitos conhecidos. A análise deve começar pela função.

Considere um sistema de bombeamento. “Motor queimado” é uma falha física possível, mas não descreve necessariamente a falha funcional do sistema. Dependendo do escopo, a função pode ser manter determinada vazão, pressão ou disponibilidade. O sistema pode falhar em cumprir essa função mesmo sem que o motor esteja queimado — por exemplo, devido a cavitação, obstrução, erro de comando, perda de alimentação, sensor incorreto ou configuração inadequada.

Definir a função permite identificar modos de falha de forma mais completa e reduz o risco de a análise ser limitada ao histórico conhecido.

O que é um modo de falha

Modo de falha descreve como a função deixa de ser cumprida ou passa a ser cumprida de maneira inadequada.

Exemplos podem incluir:

• não iniciar quando requerido;
• parar durante a operação;
• operar abaixo da capacidade requerida;
• fornecer saída incorreta;
• atuar fora do tempo especificado;
• permanecer energizado quando deveria desligar;
• apresentar vazamento;
• perder comunicação;
• produzir medição incorreta;
• falhar de forma intermitente.

O nível de detalhe deve ser compatível com a decisão. Modos excessivamente genéricos não orientam ações; modos excessivamente fragmentados tornam a análise impraticável.

Efeito, modo de falha e causa não são a mesma coisa

A qualidade da FMEA depende da separação entre esses conceitos.

Efeito é o que acontece como consequência da falha. Pode ser local, no subsistema ou no nível do usuário/processo.

Modo de falha é a maneira pela qual a função é perdida ou degradada.

Causa é aquilo que inicia ou explica o modo de falha, dentro do nível de análise adotado.

Um exemplo simplificado:

Elemento	Exemplo
Função	alimentar carga crítica com continuidade
Modo de falha	saída de energia indisponível
Efeito local	carga sem alimentação
Efeito no sistema	interrupção de processo crítico
Causa potencial	falha de componente, comando, conexão ou alimentação a montante
Controle	redundância, proteção, monitoramento, testes periódicos

A mesma ocorrência pode aparecer como efeito em um nível e como modo de falha em outro. Por isso, a fronteira da análise precisa ser definida antes de preencher a FMEA.

Tipos de FMEA

A estrutura fundamental é semelhante, mas o objeto muda conforme a aplicação.

Design FMEA — DFMEA

DFMEA avalia riscos associados ao projeto de produto ou sistema. O foco está em funções, requisitos, arquitetura, interfaces e escolhas de engenharia.

Pode apoiar decisões sobre:

• redundância;
• tolerância a falhas;
• materiais e componentes;
• proteção;
• interfaces;
• capacidade;
• diagnóstico;
• manutenibilidade;
• critérios de teste;
• condições ambientais.

Quanto mais cedo aplicada, maior a capacidade de eliminar riscos por mudança de projeto, em vez de criar controles posteriores para compensá-los.

Process FMEA — PFMEA

PFMEA analisa como um processo pode gerar resultados inadequados. É muito utilizada em manufatura, montagem, instalação, execução e atividades repetitivas.

O foco pode incluir sequência de operações, parâmetros, recursos, ferramentas, erro humano, inspeção, medição e controles de processo.

FMEA de sistemas

Em sistemas complexos, a análise considera funções e interfaces entre subsistemas. Dependências compartilhadas, falhas de causa comum e propagação de efeitos tornam-se especialmente importantes.

FMEA aplicada à operação e manutenção

A FMEA também pode apoiar análise de ativos em operação, especialmente quando combinada com criticidade, histórico de falhas, condição e estratégias de manutenção. Nesse cenário, ajuda a identificar quais modos precisam de prevenção, monitoramento, detecção, contingência ou mudança de projeto.

FMEA e FMECA: qual a diferença

A FMECA — Failure Modes, Effects and Criticality Analysis — adiciona uma avaliação formal de criticidade aos modos de falha. A IEC 60812:2018 trata FMEA e FMECA no mesmo referencial e admite diferentes métodos de priorização.

Para o cluster de confiabilidade, a distinção é importante: FMEA identifica e estrutura os riscos de falha; FMECA aprofunda sua criticidade por critérios definidos. A FMECA merece análise própria porque pode envolver matrizes de criticidade, severidade e outros parâmetros quantitativos ou semi-quantitativos.

Como fazer uma FMEA passo a passo

Não existe um único roteiro universal para todos os setores, mas uma FMEA robusta segue uma lógica que não deve ser invertida: escopo → função → falha funcional → modo de falha → efeito → causa/mecanismo → controles → avaliação → ação → verificação. Quando a equipe começa pela lista de componentes que “podem quebrar”, tende a produzir uma planilha extensa e pouco conectada ao desempenho real do sistema.

A ABNT NBR 5462 ajuda a separar conceitos que frequentemente aparecem misturados. Falha é o término da capacidade de um item desempenhar a função requerida; causa de falha descreve as circunstâncias que conduzem ao evento; mecanismo de falha descreve os processos físicos, químicos ou outros que o produzem. Essa distinção é fundamental porque efeitos, causas e mecanismos exigem tratamentos diferentes.

Elemento	Pergunta de engenharia	Exemplo
Função	O que o item deve fazer e em qual nível?	Manter vazão mínima de 10.000 m³/h
Falha funcional	De que forma a função pode deixar de ser atendida?	Vazão abaixo do mínimo
Modo de falha	Qual estado ou evento produz a falha funcional?	Ventilador não gira
Efeito	O que acontece quando o modo ocorre?	Temperatura do ambiente aumenta
Causa/mecanismo	Por que o modo pode ocorrer?	Rolamento travado por perda de lubrificação
Controle	Como prevenir, detectar ou limitar a consequência?	Vibração, temperatura e redundância
Ação	O que deve mudar para reduzir risco?	Monitoramento, redesign ou revisão da política

Esse encadeamento melhora a qualidade da análise porque torna cada linha verificável. Se a equipe não consegue declarar a função e o requisito, ainda não possui base para afirmar que houve falha. Se a causa está descrita apenas como “desgaste”, provavelmente o mecanismo ainda não foi aprofundado. Se o controle não atua sobre a causa nem reduz o efeito, ele não deveria receber crédito na priorização.

A granularidade também precisa ser proporcional à decisão. Uma FMEA de arquitetura trabalha com funções e subsistemas; uma DFMEA pode chegar a componentes e interfaces; uma análise aplicada à manutenção deve aprofundar os modos que realmente orientam tarefas, inspeções e políticas. Detalhar cada parafuso sem efeito decisório aumenta esforço sem aumentar qualidade.

Definir objetivo e escopo

Antes da análise, determine o que será estudado, a fase do ciclo de vida, fronteiras, interfaces, nível de decomposição, condições operacionais e decisão que a FMEA deve suportar.

Uma FMEA para revisar um projeto executivo é diferente de uma FMEA para definir estratégia de manutenção de uma planta existente.

Estruturar o sistema ou processo

Decomponha o objeto em níveis coerentes: sistema, subsistema, equipamento, função, etapa de processo ou outra estrutura adequada.

A análise de estrutura reduz lacunas e evita que componentes ou interfaces relevantes fiquem fora do escopo.

Identificar funções e requisitos

Para cada elemento, registre o que deve ser realizado e sob quais critérios. Sempre que possível, use requisitos verificáveis: capacidade, tempo, faixa operacional, disponibilidade, precisão, proteção ou outro parâmetro técnico.

Identificar modos de falha

Pergunte como a função pode ser perdida, reduzida, excedida, atrasada, intermitente ou executada incorretamente.

Identificar efeitos

Avalie o que ocorre localmente e como o efeito se propaga. É importante chegar até a consequência relevante para o sistema, processo, usuário ou negócio.

Identificar causas e mecanismos

As causas devem ser específicas o suficiente para orientar ações. “Falha do equipamento” raramente é uma causa útil. Desgaste, contaminação, sobretemperatura, erro de parametrização, perda de comunicação, folga, fadiga, sobretensão, instalação inadequada ou procedimento incorreto são exemplos mais acionáveis quando suportados pelo contexto.

Avaliar controles existentes

Controles podem atuar na prevenção, detecção ou mitigação. É necessário distinguir controle de projeto, inspeção, teste, monitoramento, alarme, redundância, procedimento e contingência.

Priorizar riscos

A priorização depende do referencial adotado. Metodologias tradicionais frequentemente utilizam severidade, ocorrência e detecção e podem calcular RPN. A abordagem AIAG & VDA para o setor automotivo introduziu Action Priority — AP no lugar do RPN como método de priorização de ações.

Isso não significa que toda FMEA, em qualquer setor, deva usar AP. A organização precisa adotar critérios compatíveis com seu referencial, requisitos contratuais e natureza do risco.

Definir ações e responsáveis

A FMEA só cria valor quando produz ações efetivas. Cada ação deve ter responsável, prazo, objetivo, evidência de implementação e regra para reavaliar o risco residual.

A abordagem de sete passos AIAG & VDA

Para aplicações automotivas, o manual AIAG & VDA estrutura o desenvolvimento da FMEA em sete etapas:

1. Planejamento e preparação.
2. Análise de estrutura.
3. Análise de função.
4. Análise de falhas.
5. Análise de risco.
6. Otimização.
7. Documentação de resultados.

A estrutura reforça um aspecto valioso mesmo fora da indústria automotiva: a análise de risco deve ser precedida por uma boa compreensão da estrutura e das funções.

Entretanto, quando o trabalho não está submetido a requisitos automotivos, a IEC 60812:2018 oferece uma referência genérica mais apropriada para adaptar o método ao contexto de engenharia.

Severidade, ocorrência e detecção

Esses três critérios são amplamente associados à FMEA.

Severidade avalia a relevância do efeito da falha.

Ocorrência representa a frequência ou probabilidade associada à causa ou modo, conforme o método utilizado.

Detecção considera a capacidade dos controles de identificar a causa ou o modo antes que o efeito relevante ocorra ou chegue ao usuário, novamente conforme a escala adotada.

As escalas não devem ser improvisadas. Precisam ter definições objetivas, consistentes e adequadas ao setor. A mesma nota numérica pode representar riscos muito diferentes quando organizações utilizam critérios distintos.

O problema de usar apenas RPN

O RPN — Risk Priority Number — normalmente resulta da multiplicação de severidade, ocorrência e detecção. É simples para ordenar grandes planilhas, mas possui uma limitação matemática importante: o mesmo produto pode representar perfis de risco completamente diferentes.

Considere dois modos. O modo A possui severidade 10, ocorrência 2 e detecção 3, resultando em RPN 60. O modo B possui severidade 5, ocorrência 6 e detecção 2, também resultando em RPN 60. A igualdade numérica não significa equivalência decisória. O primeiro pode representar uma consequência de segurança rara, porém inaceitável; o segundo pode representar uma perda operacional frequente, mas reversível.

Outro problema é a falsa linearidade. As escalas de 1 a 10 são ordinais: severidade 10 não é necessariamente “duas vezes” severidade 5, embora a multiplicação trate os números dessa forma. Pequenas mudanças de classificação também podem alterar o ranking sem que o risco real tenha mudado na mesma proporção.

A evolução AIAG & VDA passou a utilizar Action Priority como mecanismo principal de priorização no contexto automotivo, mantendo severidade, ocorrência e detecção visíveis em vez de reduzi-las a um único produto. Em outras aplicações, matrizes de criticidade, regras de escalonamento ou critérios específicos de segurança e conformidade podem ser mais adequados.

Uma regra prática é estabelecer gatilhos não compensáveis. Consequências severas de segurança, ambientais ou regulatórias podem exigir ação independentemente de uma ocorrência estimada como baixa. Da mesma forma, um modo com ocorrência elevada pode justificar ação de melhoria contínua mesmo que o efeito individual seja moderado.

A lição é geral: o número deve apoiar a decisão, não substituí-la. A priorização precisa preservar a visibilidade da consequência, da confiança nos dados, da eficácia dos controles e do contexto em que a função opera.

FMEA e engenharia de confiabilidade

A FMEA é uma das ferramentas centrais da Engenharia de Confiabilidade, mas não resolve todos os problemas de confiabilidade.

Ela é predominantemente uma análise estruturada de modos e efeitos. Quando a decisão exige modelar probabilidade de sucesso, disponibilidade de arquitetura, comportamento temporal, combinações lógicas de eventos ou distribuições de vida, outros métodos como RAM, RBD, FTA e Weibull podem ser necessários.

O valor está em combinar ferramentas conforme a pergunta de engenharia.

FMEA aplicada à manutenção

Em manutenção, uma FMEA pode ajudar a revisar tarefas existentes e identificar quais modos de falha realmente justificam intervenção.

Para cada modo relevante, a equipe pode perguntar:

• existe mecanismo de degradação detectável;
• é tecnicamente possível monitorá-lo;
• existe intervalo P-F ou outro comportamento conhecido;
• uma tarefa preventiva reduz efetivamente a probabilidade da falha;
• a falha pode ser tolerada até ocorrer;
• há consequência de segurança, ambiental ou operacional relevante;
• é melhor modificar o projeto do que manter mais.

Essa lógica prepara a base para métodos como RCM. O serviço de Engenharia de Manutenção pode utilizar análises de falha e criticidade para estruturar planos mais proporcionais ao risco.

FMEA em projetos de engenharia

Durante o projeto, a FMEA pode ser incorporada a Design Reviews e gates técnicos. Isso é particularmente útil para sistemas críticos e multidisciplinares.

Uma revisão pode selecionar funções críticas e verificar:

• perda total ou parcial da função;
• falhas de interface;
• falhas de alimentação ou utilidades;
• falhas de comunicação;
• condição de falha segura;
• causas comuns;
• capacidade de isolamento;
• acessibilidade para manutenção;
• alarmes e diagnóstico;
• recuperação após falha;
• testes necessários para demonstrar os controles.

A saída pode alimentar requisitos, desenhos, especificações, lógica de automação, planos de teste, sobressalentes e procedimentos operacionais.

FMEA e gestão de riscos

FMEA não substitui um processo completo de gestão de riscos. Ela é um método específico para riscos associados a modos de falha.

Riscos contratuais, financeiros, regulatórios, de cronograma, segurança da informação ou mercado podem exigir outras técnicas. O artigo sobre Gestão de Riscos em Projetos de Engenharia aborda a governança mais ampla de riscos em projetos.

Quando a FMEA é usada dentro desse sistema, os modos de falha críticos podem ser escalados para registros corporativos ou de projeto, mantendo conexão entre risco técnico e decisão gerencial.

Erros comuns em uma FMEA

Uma FMEA perde valor quando é produzida apenas para cumprir uma exigência documental. Alguns sinais são recorrentes:

• funções genéricas ou inexistentes;
• copiar modos de falha de outro equipamento sem revisar contexto;
• confundir efeito, modo e causa;
• usar a mesma causa para todos os modos;
• preencher severidade, ocorrência e detecção sem critérios definidos;
• priorizar apenas pelo RPN;
• registrar controles que não existem ou não são testados;
• criar ações sem responsável e evidência;
• não atualizar a análise após mudança de projeto;
• produzir a FMEA individualmente, sem equipe multidisciplinar;
• ignorar interfaces e falhas de causa comum.

A FMEA deve ser um documento vivo enquanto o objeto analisado muda.

Quem deve participar

A qualidade da análise cresce quando diferentes perspectivas são combinadas. Dependendo do escopo, a equipe pode envolver:

• engenharia de projeto;
• operação;
• manutenção;
• automação e controle;
• segurança;
• qualidade;
• fornecedores;
• comissionamento;
• especialistas do processo;
• responsáveis pela gestão de ativos.

A facilitação também importa. Um coordenador experiente mantém a lógica entre função, falha, efeito, causa, controle e ação e evita que a sessão se transforme em uma discussão sem estrutura.

Exemplo simplificado de FMEA em um sistema crítico

Considere um sistema de ventilação de uma sala técnica cuja função seja manter a temperatura ambiente abaixo de 27 °C com a carga térmica de projeto. A função já contém um critério mensurável; portanto, é possível distinguir degradação aceitável de falha funcional.

Campo da FMEA	Exemplo
Função	Manter ambiente ≤ 27 °C na condição de projeto
Falha funcional	Não manter a temperatura requerida
Modo de falha	Vazão insuficiente no circuito de insuflamento
Efeito local	Redução da remoção de calor
Efeito no sistema	Sobretemperatura, alarmes e eventual desligamento de equipamentos
Causa 1	Ventilador indisponível por falha mecânica
Causa 2	Comando incorreto ou perda de alimentação
Causa 3	Obstrução de filtro/duto elevando perda de carga
Controles atuais	Alarme de temperatura, indicação de status e inspeção periódica
Ações possíveis	Detecção de vazão, redundância, revisão da manutenção e teste funcional

Observe que “ventilador quebra” não é uma linha suficiente. O ventilador pode estar girando e a vazão continuar abaixo do requisito por obstrução, rotação incorreta, damper fechado ou perda de desempenho. Da mesma forma, a perda de um ventilador pode não resultar em falha funcional se outra unidade assumir automaticamente a carga e a capacidade remanescente atender ao requisito.

A avaliação dos controles também precisa considerar quando a falha é detectada. Um alarme de temperatura alta detecta o efeito já em propagação; um sensor de vazão pode revelar a perda funcional mais cedo; monitoramento de vibração pode atuar ainda antes, sobre um mecanismo de falha específico do ventilador. São camadas diferentes de prevenção e detecção e não devem receber o mesmo crédito sem análise.

Se a consequência for perda de equipamentos críticos, a equipe pode concluir que apenas melhorar detecção não é suficiente e decidir por redundância, segregação elétrica ou mudança de arquitetura. Se a consequência for apenas desconforto temporário em área não crítica, monitoramento e procedimento de resposta podem ser proporcionais. A FMEA deve conduzir a uma decisão compatível com o efeito, não a uma lista automática de ações.

Esse exemplo mostra por que a FMEA conecta engenharia de requisitos, falhas, controles, projeto, comissionamento e manutenção. A qualidade da análise é medida pela capacidade de explicar como uma causa leva à perda da função e qual ação interrompe essa cadeia.

Como saber se a FMEA está boa

Uma FMEA de qualidade permite responder rapidamente:

• quais são as funções críticas;
• quais modos de falha ameaçam essas funções;
• quais efeitos são mais relevantes;
• quais causas têm controles insuficientes;
• quais ações estão abertas;
• quais riscos permanecem após as ações;
• quais decisões de projeto ou manutenção foram alteradas pela análise.

Se a equipe possui uma planilha extensa, mas não consegue responder a essas perguntas, provavelmente existe volume documental sem maturidade analítica.

Quando contratar apoio especializado

Apoio externo pode ser útil quando o sistema é multidisciplinar, crítico, novo para a organização ou quando uma análise independente precisa desafiar premissas de projeto e controles existentes.

Também pode ser relevante para estruturar a metodologia, definir escalas, facilitar workshops, consolidar FMEAs de fornecedores, relacionar riscos a requisitos e criar um plano de ações verificável.

Em ativos existentes, FMEA pode ser integrada a criticidade, histórico, inspeções e análise de confiabilidade para orientar prioridades de manutenção e modernização.

Referências técnicas

[1] IEC. IEC 60812:2018 — Failure modes and effects analysis (FMEA and FMECA). Geneva: International Electrotechnical Commission, 2018.

[2] AIAG; VDA. AIAG & VDA FMEA Handbook. 1st ed., 2nd printing. Southfield: Automotive Industry Action Group, 2022.

[3] IEC. IEC 60300-1:2024 — Dependability management — Part 1: Managing dependability. Geneva: International Electrotechnical Commission, 2024.

Perguntas frequentes

O que significa FMEA?

FMEA significa Failure Modes and Effects Analysis, em português Análise dos Modos e Efeitos de Falha. O método identifica como funções podem falhar, seus efeitos, causas, controles e ações de redução de risco.

Qual é a diferença entre FMEA e FMECA?

A FMECA adiciona uma avaliação formal de criticidade aos modos e efeitos de falha. A FMEA estrutura modos, efeitos e causas; a FMECA aprofunda a priorização por criticidade.

Qual é a diferença entre DFMEA e PFMEA?

DFMEA analisa riscos do projeto de produto ou sistema. PFMEA analisa riscos associados ao processo de fabricação, montagem, instalação ou execução.

O que são severidade, ocorrência e detecção na FMEA?

São critérios usados em diferentes metodologias para avaliar a relevância do efeito, a ocorrência do modo ou causa e a capacidade dos controles de detectar o problema, conforme escalas previamente definidas.

O RPN ainda deve ser usado?

Depende do referencial adotado. O RPN continua presente em muitas metodologias, mas possui limitações. A abordagem AIAG & VDA automotiva utiliza Action Priority para priorização de ações.

Quando a FMEA deve ser atualizada?

Sempre que mudanças relevantes alterarem funções, arquitetura, processo, interfaces, causas, controles, requisitos ou evidências. Também deve ser revisada quando falhas de campo revelarem premissas incompletas.

Materiais técnicos complementares

Soluções relacionadas

• Aplicações de Campo, Inspeção e Coleta de Dados Técnicos
• Gestão do Conhecimento Técnico e Lições Aprendidas
• Sistemas Web Corporativos para Gestão, Operação e Integração

Serviços de engenharia relacionados

• Engenharia de Confiabilidade e Disponibilidade
• Engenharia de Manutenção
• Gestão de Ativos de Engenharia
• Recomissionamento de Sistemas e Instalações

Conteúdos técnicos correlatos

• Engenharia de Confiabilidade: métodos e indicadores
• Gestão de Ativos: ciclo de vida, valor, risco e desempenho
• Gestão de Riscos em Projetos de Engenharia
• Design Review em Projetos de Engenharia
• Gestão de Requisitos em Engenharia
• ISO 55000 e Gestão de Ativos

Guias, frameworks e referenciais

• Comissionamento: guia completo do planejamento, testes, aceite e handover
• Framework de Handover Técnico de Obras e Sistemas