Análise de Falhas: Metodologia, Evidências e Engenharia

Análise de falhas aplicada à engenharia: metodologia, evidências, mecanismos, causas, ensaios, RCA, FMEA, FTA, governança e ações corretivas.

Confira!

Análise de falhas é o processo técnico utilizado para compreender por que um item, sistema ou processo deixou de cumprir a função requerida, quais mecanismos contribuíram para o evento, quais evidências sustentam a conclusão e quais ações são necessárias para reduzir a probabilidade de recorrência. O objetivo não é simplesmente nomear um componente que falhou, mas reconstruir a sequência do evento de forma tecnicamente defensável.

Uma análise consistente distingue ocorrência, sintoma, modo de falha, mecanismo físico ou lógico, causa, fatores contribuintes e consequência. Essa separação é essencial porque substituir o componente que apresentou a pane pode restaurar a função sem eliminar a condição que originou a falha. Em sistemas complexos, a causa pode estar no projeto, instalação, ambiente, operação, manutenção, configuração, suprimentos, software, interface entre disciplinas ou processo de decisão.

Por isso, análise de falhas não é sinônimo de RCA, FMEA ou FTA. A análise de falhas é um processo investigativo mais amplo. A RCA pode integrar esse processo quando é necessário identificar causas-raiz de um evento ocorrido; a FMEA é predominantemente preventiva e parte dos modos de falha possíveis; a FTA parte de um evento de topo e investiga combinações causais. Cada técnica responde a uma pergunta diferente.

Em organizações intensivas em ativos, a análise de falhas também é uma ferramenta de governança. Ela transforma ocorrências de campo em evidências para revisar projeto, manutenção, critérios de operação, sobressalentes, contratos, padrões técnicos, dados de ativos e decisões de ciclo de vida. Quando formalizada, deixa de ser uma atividade reativa isolada e passa a alimentar um sistema contínuo de confiabilidade e melhoria.

Falha, pane, defeito, causa e mecanismo: por que a terminologia importa

A ABNT NBR 5462 estabelece uma distinção importante entre conceitos frequentemente usados como sinônimos. Falha é o evento que termina a capacidade de um item desempenhar uma função requerida. Pane é o estado resultante de incapacidade de desempenhar essa função. Um defeito é um desvio de uma característica em relação a um requisito e pode existir sem causar falha imediata.

A norma também diferencia causa de falha e mecanismo de falha. A causa está associada às circunstâncias de projeto, fabricação ou uso que conduzem ao evento. O mecanismo é o processo físico, químico, elétrico, lógico ou de outra natureza que efetivamente conduz à perda da função. Essa distinção é decisiva para evitar conclusões superficiais.

Conceito	Pergunta de engenharia
Defeito	Qual requisito ou característica está fora do esperado?
Falha	Qual função deixou de ser cumprida e em que momento?
Pane	Em qual estado de incapacidade o item ficou após a falha?
Modo de falha	Como a perda da função se manifestou?
Mecanismo de falha	Qual processo produziu a degradação ou ruptura?
Causa	Quais circunstâncias permitiram ou provocaram o mecanismo?
Consequência	Qual efeito operacional, econômico, de segurança ou conformidade resultou?

Essa disciplina terminológica conecta a análise com Engenharia de Confiabilidade e Disponibilidade e com o conteúdo de Engenharia de Manutenção, porque permite relacionar eventos reais aos modos de falha, estratégias de manutenção e requisitos de desempenho.

Quando uma falha precisa de investigação estruturada

Nem toda pane exige uma investigação completa. O nível de profundidade deve ser proporcional à criticidade, recorrência, incerteza e consequência. Uma troca simples pode ser suficiente para um item não crítico cuja causa é conhecida e cujo risco residual é baixo. Já eventos que envolvem segurança, indisponibilidade relevante, falhas repetitivas, impacto contratual ou causa desconhecida exigem tratamento diferente.

Critérios típicos para abrir uma análise estruturada incluem:

falha em ativo ou função crítica;
recorrência do mesmo modo de falha;
consequência de segurança, meio ambiente ou conformidade;
indisponibilidade ou perda de produção relevante;
ocorrência em equipamento novo, recém-comissionado ou dentro de garantia;
divergência entre comportamento observado e premissas de projeto;
falha simultânea ou aparentemente comum em sistemas redundantes;
evento cuja causa permanece incerta após o diagnóstico de manutenção;
necessidade de sustentar decisão contratual, técnica ou de investimento.

A Análise de Criticidade de Ativos ajuda a definir quando mobilizar recursos de investigação. Em organizações maiores, o gatilho pode ser formalizado em Gestão de Processos, Workflows e Aprovações Técnicas, evitando que eventos relevantes sejam encerrados apenas como ordens corretivas.

Preservação de evidências: o primeiro passo da análise

Uma das falhas mais comuns do próprio processo investigativo ocorre antes da análise começar: o equipamento é desmontado, limpo, reconfigurado, reiniciado ou descartado sem registro adequado da condição encontrada. Isso pode destruir evidências críticas e tornar impossível distinguir causa de consequência.

A condição as found deve ser preservada na medida compatível com segurança e continuidade operacional. O registro pode incluir fotografias, posição de chaves, alarmes, logs, temperatura, estado de proteção, configuração, firmware, histórico recente de intervenções, diagramas, tendências de processo, qualidade de energia, peças removidas, vestígios físicos e depoimentos das equipes envolvidas.

Em ambientes digitais ou automatizados, a preservação pode envolver logs de servidores, switches, VMS, CLPs, relés, BMS, SCADA, sistemas de monitoramento e plataformas de gestão. Em equipamentos eletromecânicos, pode envolver medições, amostras de óleo, superfícies de fratura, resíduos, folgas, desgaste, isolamento, torque, vibração ou termografia.

Quando a análise tem implicação contratual, de garantia ou segurança, a governança da evidência precisa ser ainda mais rigorosa. A Gestão de Requisitos, Evidências e Critérios de Aceite e a Governança Documental permitem controlar origem, versão, autoria, integridade e rastreabilidade dos registros usados na conclusão.

Como estruturar uma análise de falhas passo a passo

Uma investigação tecnicamente consistente pode ser organizada em uma sequência de trabalho:

1. Definir a função perdida e o evento analisado. Evitar descrições vagas como “equipamento queimou”. 2. Estabelecer a fronteira do sistema. Definir equipamentos, interfaces, utilidades, software, pessoas e condições incluídas. 3. Preservar e registrar a condição encontrada. Documentar evidências antes de alterar o sistema. 4. Construir a cronologia. Relacionar operação, alarmes, intervenções, mudanças e eventos antecedentes. 5. Caracterizar o modo de falha. Descrever como a perda da função se manifestou. 6. Formular hipóteses. Listar mecanismos e causas tecnicamente plausíveis. 7. Selecionar ensaios e verificações. Buscar evidências capazes de confirmar ou refutar cada hipótese. 8. Reconstruir a cadeia causal. Separar causa imediata, mecanismo, fatores contribuintes e causas sistêmicas. 9. Avaliar extensão da condição. Verificar se o problema pode existir em ativos semelhantes, redundantes ou instalados sob a mesma premissa. 10. Definir ações. Tratar contenção, correção, prevenção, redesign, revisão de plano, dados ou processo. 11. Validar eficácia. Confirmar se as ações realmente reduziram o risco ou eliminaram a condição. 12. Registrar aprendizado. Atualizar documentação, padrões, planos, cadastro, requisitos e lições aprendidas.

Essa sequência pode ser adaptada ao tipo de ativo. O valor está em manter a rastreabilidade entre evidência → hipótese → teste → conclusão → ação.

Uma hipótese plausível não é uma causa comprovada. Investigações críticas precisam preservar evidências, testar explicações alternativas e manter rastreabilidade entre hipótese, ensaio e conclusão.

Conheça a Auditoria Técnica de Engenharia →

Hipóteses e verificação: evitar conclusões por plausibilidade

Uma hipótese tecnicamente plausível não é uma causa comprovada. Em investigação de falhas, é comum uma equipe reconhecer um padrão familiar e encerrar a análise antes de testar explicações alternativas. Esse viés pode ser reforçado quando a primeira hipótese é apresentada por alguém com forte autoridade técnica ou quando a solução proposta é operacionalmente conveniente.

O método deve procurar evidências que confirmem e também possam refutar cada hipótese. Se a causa proposta é sobretemperatura, é necessário verificar sinais térmicos, condições de ventilação, carga, proteção, ambiente e histórico. Se a hipótese é erro de configuração, deve-se comparar backups, logs, revisões, permissões, mudanças e comportamento do sistema. Se a hipótese é falha de alimentação, a análise precisa considerar qualidade de energia, proteção, coordenação, conexões e eventos a montante.

A lógica é semelhante à usada em Root Cause Analysis — RCA, mas a análise de falhas pode terminar antes de uma RCA completa quando o objetivo é caracterizar tecnicamente o modo e o mecanismo. Quando a ocorrência possui causas organizacionais, humanas ou de processo relevantes, a RCA amplia a investigação.

Ensaios e dados que podem sustentar a investigação

Não existe pacote universal de testes. Os métodos dependem da tecnologia, do mecanismo suspeito e da evidência disponível. Em diferentes disciplinas, uma análise pode recorrer a:

Domínio	Exemplos de evidências e técnicas
Elétrica	oscilografia, qualidade de energia, resistência de isolamento, termografia, coordenação de proteção, registros de relés
Mecânica	vibração, alinhamento, análise de óleo, metalografia, fratura, desgaste, folgas, ensaios não destrutivos
Automação	logs de CLP/SCADA, sequência de eventos, estados de I/O, firmware, lógica e histórico de mudanças
Redes e telecom	syslog, SNMP, NetFlow, erros de interface, perda óptica, OTDR, topologia, redundância, configurações
Data Center	BMS/DCIM, eventos UPS/STS/PDU, temperatura, carga, bateria, geradores, alarmes e transferências
Segurança eletrônica	logs de VMS, storage, câmeras, controladoras, rede, sincronismo, gravação e eventos de integração

A A3A atua transversalmente em infraestrutura crítica, o que permite conectar a análise à arquitetura do sistema. Projetos como o monitoramento operativo para teleassistência em subestação, o FEED de telecomunicações em usina hidrelétrica e a implantação turnkey de videomonitoramento em complexo governamental exemplificam ambientes nos quais a função depende de interfaces entre energia, redes, software, infraestrutura e operação.

Análise de falhas, RCA, FMEA, FTA e RAM

As técnicas são complementares, mas não devem ser usadas como nomes diferentes para a mesma análise.

Técnica	Ponto de partida	Pergunta central
Análise de Falhas	ocorrência, componente ou função perdida	o que falhou, como ocorreu e quais evidências explicam o mecanismo?
RCA	evento ocorrido	por que o evento aconteceu e quais causas precisam ser removidas?
FMEA/FMECA	item, função ou processo	como pode falhar e quais efeitos e criticidades resultam?
FTA	evento de topo	quais combinações podem produzir esse evento?
RAM	arquitetura e dados de falha/reparo	qual confiabilidade, disponibilidade e mantenabilidade o sistema entrega?

A FMEA ajuda a verificar se o modo observado já era previsto e quais barreiras deveriam existir. A FTA é útil quando o evento depende de combinações ou redundâncias. A Análise RAM permite avaliar o efeito das falhas e reparos sobre o desempenho sistêmico. A Análise de Weibull ajuda quando o comportamento estatístico ao longo do tempo é relevante.

Da falha técnica à causa sistêmica

Uma investigação madura não para na peça danificada. Um contator pode ter falhado por aquecimento, mas o aquecimento pode estar relacionado a aperto inadequado, especificação incorreta, sobrecarga, ventilação insuficiente, qualidade de instalação ou manutenção inadequada. Uma placa eletrônica pode apresentar dano, mas a causa dominante pode estar em surto, aterramento, ambiente, firmware ou alimentação auxiliar.

Por isso, é útil distinguir pelo menos quatro níveis:

efeito observado: o que a operação percebeu;
modo/mecanismo: como o item perdeu a função;
causa técnica: condição que originou ou permitiu o mecanismo;
causa sistêmica: processo, requisito, decisão ou governança que permitiu a condição permanecer.

Essa última camada aproxima a análise de Technical Authority em Engenharia, Project Assurance e Gestão de Engenharia. A recorrência muitas vezes não decorre de desconhecimento técnico, mas de ausência de processo para transformar conhecimento em decisão controlada.

Falha relevante precisa gerar evidência de engenharia, não apenas uma ordem corretiva. Critérios, responsáveis, versões, conclusões e ações devem permanecer rastreáveis para sustentar decisões e auditorias futuras.

Conheça Gestão de Requisitos, Evidências e Critérios de Aceite →

Governança da análise: papéis, independência e rastreabilidade

Análises com impacto relevante precisam de governança proporcional. Deve existir um responsável pela investigação, critérios para participação de operação, manutenção, engenharia, fornecedor e segurança, além de regras para revisão e aprovação das conclusões.

Em determinados casos, a equipe que projetou, instalou ou operou o sistema não deve ser a única responsável por validar a causa. Revisão independente reduz vieses e aumenta a confiança na conclusão, especialmente quando a análise suporta aceite, garantia, responsabilização técnica ou decisão de investimento.

A Auditoria Técnica de Engenharia e o Design Review podem compor essa camada de assurance. Em contratos ou empreendimentos de maior complexidade, a Engenharia do Proprietário mantém a visão do owner sobre requisitos, evidências, aceite e risco residual.

Ações corretivas: corrigir, prevenir e verificar eficácia

Uma boa análise separa ações de contenção das ações que tratam causa. Substituir um componente, reiniciar um serviço, aplicar um patch emergencial ou operar em contingência pode ser necessário para restaurar a função, mas isso não significa que o risco de recorrência tenha sido reduzido.

As ações podem envolver:

correção ou substituição do item;
revisão de projeto ou arquitetura;
alteração de especificação ou fornecedor;
mudança de proteção, redundância ou segregação;
atualização de procedimento operacional;
revisão do Plano de Manutenção;
alteração de frequência, condição ou técnica de inspeção;
atualização de sobressalentes e estratégia de suporte;
melhoria de cadastro, instrumentação ou monitoramento;
revisão de treinamento, competência ou autorização;
alteração de workflow, aprovação ou controle de mudanças.

A ação só deve ser considerada encerrada quando existe evidência de implementação e um critério para avaliar eficácia. Essa disciplina evita que a organização acumule relatórios tecnicamente corretos sem reduzir efetivamente a recorrência.

Como integrar análise de falhas ao PCM e à gestão de ativos

O PCM — Planejamento e Controle da Manutenção deve funcionar como um dos mecanismos de captura dos eventos que precisam de investigação. Ordens corretivas, recorrências, retrabalho, falhas em ativos críticos e anomalias sem causa definida podem gerar gatilhos formais para análise.

Os resultados retornam ao sistema de manutenção por meio de revisão de planos, criticidade, cadastro, peças, procedimentos e critérios de aceite. Ao mesmo tempo, os Indicadores de Manutenção permitem verificar se as ações reduziram recorrência, indisponibilidade, retrabalho ou trabalho emergencial.

No nível de Gestão de Ativos, a análise pode alterar decisões de reforma, recomissionamento, modernização ou substituição. Quando a falha revela limitação estrutural do ativo, continuar otimizando manutenção pode ser economicamente inferior a uma intervenção de ciclo de vida.

Quando a falha afeta disponibilidade, segurança, garantia ou decisão de investimento, a investigação precisa ir além do diagnóstico de manutenção. Engenharia de confiabilidade integra evidências, mecanismos, risco e ações em uma conclusão tecnicamente defensável.

Conheça Engenharia de Confiabilidade e Disponibilidade →

Análise de falhas como serviço de engenharia consultiva

Quando a ocorrência possui complexidade, criticidade ou impacto contratual relevante, a análise pode ser estruturada como um serviço de engenharia com escopo, evidências, premissas, métodos e entregáveis claramente definidos. O trabalho pode incluir levantamento de campo, entrevistas técnicas, leitura de históricos, ensaios, análise documental, modelagem, workshop multidisciplinar, revisão independente e plano de ações.

Uma estrutura de entrega pode conter relatório da condição encontrada, cronologia, definição funcional, matriz de hipóteses e evidências, resultados de testes, mecanismo de falha, causa técnica e sistêmica, extensão da condição, risco residual e plano de ações priorizado. Dependendo do caso, o trabalho pode evoluir para Engenharia de Confiabilidade e Disponibilidade, Engenharia de Manutenção, Gerenciamento de Riscos de Engenharia ou Serviços Continuados de Engenharia Consultiva.

O valor da análise está em transformar uma ocorrência isolada em conhecimento reutilizável. Quando evidências, decisões e ações permanecem rastreáveis, cada falha pode melhorar projeto, operação e manutenção futuros em vez de apenas gerar uma nova ordem corretiva.

Referências técnicas

[1] ABNT. NBR 5462:1994 — Confiabilidade e mantenabilidade — Terminologia. Rio de Janeiro: ABNT, 1994.

[2] IEC. IEC 62740:2015 — Root cause analysis (RCA). Geneva: IEC, 2015.

[3] IEC. IEC 60812:2018 — Failure modes and effects analysis (FMEA and FMECA). Geneva: IEC, 2018.

[4] IEC. IEC 61025:2006 — Fault tree analysis (FTA). Geneva: IEC, 2006.

[5] IEC. IEC 60300-3-1:2003 — Dependability management — Analysis techniques for dependability. Geneva: IEC, 2003.

[6] ISO. ISO 55001:2024 — Asset management — Asset management system — Requirements. Geneva: ISO, 2024.

Perguntas frequentes

O que é análise de falhas?

É o processo técnico de investigar uma ocorrência para identificar a função perdida, o modo e mecanismo de falha, as evidências, causas e ações necessárias para reduzir a probabilidade de recorrência.

Qual a diferença entre falha e pane?

Na terminologia da NBR 5462, falha é o evento que termina a capacidade de desempenhar uma função requerida; pane é o estado de incapacidade resultante.

Análise de falhas é a mesma coisa que RCA?

Não. A análise de falhas é mais ampla e pode incluir caracterização do modo, mecanismo e evidências. RCA é uma técnica específica para investigar causas-raiz de eventos ocorridos.

Quando uma falha deve ser investigada formalmente?

Quando há criticidade, recorrência, impacto relevante, causa desconhecida, risco de segurança ou conformidade, falha de redundância, implicação contratual ou necessidade de decisão de engenharia.

Quais técnicas podem ser usadas em uma análise de falhas?

Dependendo do caso, podem ser usados inspeção visual, ensaios elétricos e mecânicos, termografia, vibração, análise de óleo, logs, FMEA, FTA, RCA, RAM, Weibull e outras técnicas especializadas.

Como saber se a ação corretiva foi eficaz?

A ação precisa ter critério de verificação e ser acompanhada por evidências e indicadores capazes de demonstrar redução da recorrência, risco ou indisponibilidade associada.

Materiais técnicos complementares

Soluções relacionadas

Serviços de Engenharia relacionados

Conteúdos técnicos correlatos

Governança e aprofundamento