Diagnóstico de Confiabilidade de Ativos

Diagnóstico de confiabilidade de ativos: escopo, evidências, dados de campo, criticidade, falhas, mantenabilidade, arquitetura, priorização e roadmap de melhoria.

Confira!

Diagnóstico de confiabilidade de ativos é uma avaliação estruturada da capacidade de equipamentos, sistemas e processos de sustentar funções requeridas ao longo do tempo, com base em evidências técnicas, dados de campo e condições reais de operação. Seu objetivo não é produzir uma nota genérica de maturidade, mas identificar onde a confiabilidade está sendo perdida, quais mecanismos explicam o desempenho observado e quais ações têm maior potencial de reduzir risco, indisponibilidade e recorrência.

Em muitas organizações, os sintomas aparecem antes das causas: aumento de corretivas, backlog crítico, falhas repetidas, disponibilidade abaixo da meta, intervenções emergenciais, dificuldade de diagnóstico, sobressalentes insuficientes ou ativos operando com soluções provisórias. Tratar cada evento isoladamente pode reduzir o problema imediato, mas não necessariamente corrige o sistema que produz as falhas.

Um diagnóstico robusto combina inventário e criticidade, histórico de falhas, manutenção, condição, arquitetura, dados de indisponibilidade, modos de falha, mantenabilidade, suporte, documentação, obsolescência e governança. O resultado esperado é uma linha de base técnica e um plano de melhoria priorizado por risco, impacto e viabilidade.

O que é um diagnóstico de confiabilidade de ativos

O diagnóstico é uma fotografia técnica da situação atual, mas precisa ser construída de forma analítica. Ele compara funções requeridas, desempenho esperado e comportamento observado, procurando evidências que expliquem lacunas entre os três.

A IEC 60300-1:2024 trata dependabilidade ao longo do ciclo de vida e conecta confiabilidade, disponibilidade, manutenibilidade e suporte. Isso é importante porque baixa confiabilidade percebida nem sempre é consequência apenas de falhas físicas. Tempos de espera, diagnóstico deficiente, falta de sobressalente, configuração inadequada, erro de operação ou arquitetura frágil também podem reduzir a capacidade de entregar a função requerida.

Por isso, um diagnóstico não deve começar perguntando apenas “quantas falhas ocorreram?”. Ele deve perguntar:

qual função é crítica;
qual nível de desempenho é requerido;
quais falhas ou degradações impedem esse desempenho;
com que frequência e duração ocorrem;
quais causas ou condições se repetem;
quanto tempo é gasto em detecção, diagnóstico, logística, reparo e retorno;
quais controles existem e se são eficazes;
quais riscos permanecem sem tratamento.

Diagnóstico de confiabilidade não é auditoria de manutenção

Uma auditoria de manutenção pode avaliar processos, execução de plano, backlog, registros e disciplina operacional. Isso é relevante, mas não é suficiente para explicar a confiabilidade de um sistema.

O diagnóstico de confiabilidade atravessa as fronteiras entre manutenção, operação, projeto, engenharia, suprimentos e gestão de ativos. Uma falha recorrente pode nascer de dimensionamento inadequado, acesso ruim, lógica de controle, condição ambiental, procedimento, qualidade de energia ou escolha tecnológica.

Da mesma forma, um ativo com poucas falhas registradas pode ser crítico se operar sem redundância, estiver obsoleto ou possuir tempo de reposição incompatível com a continuidade exigida.

O foco deve permanecer no desempenho da função e no risco associado à sua perda.

Definir escopo antes de analisar dados

Um diagnóstico sem escopo claro tende a gerar grande volume de informação e pouca decisão. Antes da coleta, é necessário delimitar:

unidades, sistemas e ativos abrangidos;
período histórico analisado;
funções e níveis de serviço relevantes;
critérios de criticidade;
indicadores mínimos;
fontes de dados disponíveis;
stakeholders envolvidos;
premissas e limitações.

Em uma planta industrial, por exemplo, pode não ser necessário analisar todos os equipamentos com o mesmo nível de detalhe. Ativos críticos, sistemas de utilidades e gargalos de produção podem receber primeiro uma análise mais aprofundada.

Evidências que devem sustentar o diagnóstico

A qualidade da conclusão depende da qualidade e da diversidade das evidências. A IEC 60300-3-2:2004 fornece orientação para coleta de dados de confiabilidade, mantenabilidade, disponibilidade e suporte em campo, destacando o retorno de experiência operacional como parte do processo de dependabilidade.

Um conjunto de evidências pode incluir:

Fonte	Exemplos de informação
CMMS/EAM	ordens, falhas, tempos, códigos, custos, backlog
operação	eventos, alarmes, indisponibilidade, bypasses, restrições
inspeção	condição física, anomalias, acessibilidade, ambiente
documentação	diagramas, listas, manuais, procedimentos, histórico de revisão
engenharia	FMEA/FMECA, RAM, RBD, estudos, critérios de projeto
suprimentos	lead time, obsolescência, sobressalentes, contratos
automação	logs, tendências, eventos e diagnósticos
pessoas	entrevistas com operação, manutenção e engenharia

Nenhuma dessas fontes deve ser considerada isoladamente como verdade absoluta. Dados de CMMS podem estar incompletos; entrevistas podem refletir percepção; documentação pode estar desatualizada. O diagnóstico melhora quando as fontes se confirmam ou quando divergências são explicitamente registradas.

Qualidade de dados faz parte do resultado

É comum encontrar histórico insuficiente ou inconsistente. Isso não inviabiliza o diagnóstico, mas muda o nível de confiança das conclusões.

Algumas falhas típicas de dados são:

ordens encerradas sem causa registrada;
códigos de falha usados de forma inconsistente;
tempos de indisponibilidade misturados com horas de mão de obra;
eventos duplicados;
ausência de identificação do ativo afetado;
manutenção preventiva registrada como corretiva ou vice-versa;
perda de informação em planilhas paralelas;
histórico fragmentado entre sistemas.

O diagnóstico deve classificar qualidade e completude dos dados. Quando necessário, as ações de melhoria incluem redefinição de taxonomia, campos obrigatórios, governança de cadastro e critérios de fechamento de ordens.

Dado ruim também é um achado de confiabilidade. Sem rastreabilidade de falha, causa, duração e ativo afetado, a organização perde capacidade de priorizar e aprender com a operação.

Aplicações de Campo e Coleta de Dados Técnicos →

Criticidade como filtro do diagnóstico

Criticidade orienta onde concentrar engenharia. Um equipamento que falha com frequência, mas possui baixa consequência e rápida recuperação, pode ter prioridade menor que um equipamento raramente falho, porém sem redundância e com alta consequência.

A classificação pode considerar segurança, meio ambiente, produção, qualidade, conformidade, continuidade, reputação, custo, redundância, recuperabilidade e lead time.

A análise deve também observar dependências. Um componente aparentemente pequeno pode suportar diversas funções críticas e se tornar um single point of failure do sistema.

Indicadores que ajudam a construir a linha de base

Indicadores são úteis quando possuem definição consistente e ligação com a função analisada. Alguns dos mais comuns incluem:

disponibilidade;
indisponibilidade acumulada;
MTBF ou tempo entre falhas;
MTTR ou tempos específicos de restabelecimento;
número de falhas funcionais;
recorrência por modo de falha;
proporção de manutenção emergencial;
backlog crítico;
tempo de espera por material;
tempo de diagnóstico;
custo de manutenção;
cumprimento de tarefas baseadas em condição.

A comparação deve respeitar população, período, regime operacional e exposição. Comparar diretamente dois ativos que operam em condições distintas pode produzir conclusões erradas.

Pareto de falhas: útil, mas insuficiente

Pareto é uma boa ferramenta de triagem. Pode revelar quais ativos, sistemas ou categorias concentram eventos ou horas de indisponibilidade.

O risco está em tratar frequência como único critério. Um modo de falha de baixa frequência pode ser prioritário se sua consequência for severa. Por isso, Pareto deve ser combinado com criticidade e análise de consequências.

Também é útil elaborar mais de um Pareto:

quantidade de eventos;
horas de indisponibilidade;
custo;
recorrência;
impacto em produção;
falhas de segurança ou conformidade.

As prioridades podem mudar completamente conforme a variável observada.

Separar frequência de duração da falha

Dois sistemas podem produzir a mesma indisponibilidade anual por mecanismos diferentes.

Sistema A pode apresentar 20 falhas de uma hora. Sistema B pode apresentar duas falhas de dez horas. Embora a indisponibilidade total seja a mesma, as estratégias de melhoria são diferentes.

No primeiro caso, o foco pode estar em eliminar recorrência e reduzir taxa de falha. No segundo, o problema pode estar em diagnóstico, logística, reparo, acesso ou sobressalentes.

Essa decomposição evita recomendações genéricas como “aumentar preventiva” sem saber qual componente da indisponibilidade precisa ser reduzido.

Decompor o tempo de restabelecimento

A confiabilidade operacional é afetada pelo tempo necessário para recuperar a função. Um evento de oito horas pode ser decomposto em:

Etapa	Tempo
detecção e triagem	0,5 h
liberação operacional	1,0 h
diagnóstico	1,0 h
espera por sobressalente	3,0 h
reparo efetivo	1,5 h
teste e retorno	1,0 h

Nesse cenário, atacar apenas a velocidade de reparo teria efeito limitado. O principal ganho está em logística e preparação.

A NBR 5462, utilizada como base terminológica interna, diferencia tempos de manutenção, atrasos logísticos, diagnóstico, localização, reparo e restabelecimento. Essa decomposição é particularmente útil em diagnóstico.

Analisar modos de falha e recorrência

Depois da triagem quantitativa, os eventos relevantes devem ser tratados em nível de modo de falha.

A IEC 60812:2018 fornece base para FMEA e FMECA. Um diagnóstico pode utilizar essa lógica para organizar:

função;
falha funcional;
modo de falha;
efeito;
causa ou mecanismo;
controle existente;
consequência;
evidência;
ação recomendada.

A recorrência é um sinal importante. Quando o mesmo modo se repete após sucessivas corretivas, é provável que a ação esteja restaurando a função sem eliminar a causa.

RCA: quando aprofundar a causa raiz

Nem todo evento exige uma Análise de Causa Raiz (RCA) extensa. A RCA deve ser aplicada quando consequência, recorrência, incerteza ou potencial de aprendizado justificarem o esforço.

Um critério pode considerar:

severidade do evento;
recorrência;
falha de controle crítico;
exposição futura;
potencial de repetição em outros ativos;
custo da investigação.

O diagnóstico deve evitar RCA baseada apenas em narrativa. Evidências físicas, sequência temporal, dados de processo, configuração, histórico de intervenções e alterações precisam sustentar a conclusão.

Arquitetura e pontos únicos de falha

Parte da baixa confiabilidade pode ser estrutural. RBD, FTA e análise funcional ajudam a identificar dependências que não aparecem no histórico de ordens.

A IEC 60300-3-1:2003 apresenta visão geral de técnicas de análise de dependabilidade e critérios para selecionar métodos apropriados. Em sistemas críticos, uma análise de arquitetura pode identificar:

single points of failure;
redundâncias não independentes;
falhas de causa comum;
propagação de falha;
interfaces frágeis;
capacidade degradada insuficiente;
ausência de bypass ou contingência.

Um sistema pode nunca ter sofrido a combinação crítica de eventos e ainda assim apresentar risco alto. O diagnóstico precisa considerar tanto evidência histórica quanto exposição estrutural.

Ausência de histórico de falha não prova baixa exposição. Sistemas críticos precisam ser avaliados também por arquitetura, dependências e consequências potenciais.

Engenharia de Confiabilidade e Disponibilidade →

Avaliação de confiabilidade quando os dados são limitados

A IEC 62308:2006 trata métodos de avaliação de confiabilidade a partir de dados de campo e ensaio, inclusive para itens críticos e complexos. Em ativos com histórico limitado, pode ser necessário combinar diferentes fontes e explicitar incerteza.

Algumas abordagens possíveis incluem:

histórico de ativos semelhantes;
dados de fabricante com verificação de contexto;
bancos de dados reconhecidos;
testes e inspeções;
modelagem de arquitetura;
julgamento especializado documentado;
análise por cenários.

O diagnóstico deve separar dado observado, estimativa e premissa. Misturar essas categorias transmite uma precisão que não existe.

Condição física e degradação

Dados históricos não substituem inspeção. Equipamentos podem estar operando com degradação relevante ainda não transformada em falha funcional.

Dependendo da disciplina, inspeções podem observar:

aquecimento;
corrosão;
desgaste;
folgas;
contaminação;
vibração;
isolamento;
vazamentos;
qualidade de conexões;
alarmes desabilitados;
proteções bypassadas;
modificações não documentadas.

A condição deve ser relacionada ao mecanismo de falha e à criticidade. Um indicador de condição ruim não implica automaticamente substituição; ele precisa ser interpretado no contexto do risco e da estratégia de ciclo de vida.

Mantenabilidade e capacidade de recuperação

O diagnóstico também deve avaliar se a organização consegue recuperar o sistema no prazo necessário.

Questões úteis incluem:

existe acesso seguro para intervenção;
o nível de intervenção está definido;
há documentação atualizada;
os pontos de teste são adequados;
é possível isolar o equipamento sem desligamentos excessivos;
as ferramentas estão disponíveis;
a competência necessária existe;
o procedimento é executável;
o sistema pode ser testado após reparo.

Mantenabilidade ruim costuma aparecer nos dados como MTTR alto, mas sua causa pode estar no projeto e não na equipe.

Sobressalentes, logística e suporte

Lead time, disponibilidade de peças e obsolescência podem dominar a indisponibilidade. O diagnóstico precisa cruzar criticidade com estratégia de sobressalentes.

Para cada item relevante, podem ser avaliados:

tempo de reposição;
consumo histórico;
custo de estoque;
possibilidade de reparo;
equivalentes aprovados;
vida de prateleira;
obsolescência;
dependência de fornecedor único;
capacidade de contingência durante espera.

O objetivo não é maximizar estoque, mas reduzir exposição de forma economicamente justificável.

Obsolescência como risco de confiabilidade

Obsolescência não significa apenas fim de fabricação. Ela pode envolver perda de suporte, indisponibilidade de firmware, incompatibilidade com sistemas atuais, ausência de competência interna, componentes sem equivalência ou impossibilidade de atualização segura.

Um ativo obsoleto pode continuar funcionando por anos. O risco aparece quando a próxima falha não pode ser restaurada no prazo aceitável.

Por isso, diagnóstico de confiabilidade deve alimentar decisões de retrofit, modernização e renovação.

Avaliar eficácia do plano de manutenção

Não basta verificar se o plano está sendo cumprido. É necessário avaliar se as tarefas controlam os modos de falha relevantes.

Perguntas de diagnóstico incluem:

a tarefa está ligada a um mecanismo de falha conhecido;
a frequência é coerente com o comportamento de degradação;
o critério de aceitação está definido;
a evidência registrada é suficiente;
a tarefa detecta anomalias com tempo para agir;
as falhas continuam ocorrendo apesar da tarefa;
existem modos críticos sem qualquer política de tratamento.

Esse tipo de revisão aproxima o diagnóstico da engenharia de manutenção e da RCM.

Estruturar achados por evidência e consequência

Um diagnóstico útil não deve produzir apenas uma lista longa de observações. Cada achado pode ser estruturado em cinco campos:

Condição observada. O que foi identificado.
Evidência. Qual dado, inspeção, documento ou registro sustenta o achado.
Consequência. Qual função, risco ou desempenho pode ser afetado.
Causa provável ou lacuna. O que explica a condição ou impede decisão segura.
Recomendação. Qual ação deve ser avaliada ou implementada.

Essa estrutura evita recomendações desconectadas da evidência.

Exemplo de achado técnico

Condição: duas bombas críticas operam em redundância 1+1.

Evidência: histórico mostra cinco eventos no ano; inspeção confirma que ambas compartilham o mesmo painel de alimentação e o mesmo trecho de sucção.

Consequência: falha no painel ou obstrução comum pode retirar simultaneamente os dois equipamentos e interromper a função.

Lacuna: a redundância de equipamentos não elimina pontos comuns de arquitetura.

Recomendação: avaliar segregação elétrica, vulnerabilidade hidráulica, contingência operacional e eventual modificação de projeto conforme risco e viabilidade.

O valor do diagnóstico está em conectar a observação ao mecanismo de perda da função.

Priorização das ações

Nem toda recomendação deve virar projeto imediato. O plano de melhoria precisa considerar risco, benefício, urgência, dependências, custo e capacidade de execução.

Uma matriz prática pode usar:

Prioridade	Característica
imediata	risco intolerável, segurança, conformidade ou exposição crítica
alta	recorrência relevante, indisponibilidade ou risco elevado
média	ganho consistente com planejamento de curto/médio prazo
estruturante	dados, processo, documentação ou governança necessários para melhorias futuras
oportunidade	otimização com benefício, mas sem urgência operacional

A priorização deve ser transparente para que decisões possam ser revisitadas quando contexto ou recursos mudarem.

Roadmap de melhoria de confiabilidade

Um diagnóstico normalmente produz ações em horizontes diferentes.

0–90 dias: controlar riscos imediatos, corrigir bypasses críticos, revisar sobressalentes urgentes, fechar causas de falhas recorrentes e melhorar registros essenciais.

3–12 meses: revisar planos, executar FMEA/FMECA ou RCM em sistemas prioritários, atualizar documentação, corrigir arquitetura vulnerável e estruturar indicadores.

12–36 meses: implementar modernizações, renovação de ativos, projetos de redundância, automação de diagnóstico e mudanças estruturais de processo.

O roadmap deve indicar responsável, dependências, entregável, critério de conclusão e indicador de resultado.

Indicadores para medir se o plano funcionou

Depois da implementação, a organização precisa verificar resultado. Dependendo do caso, indicadores podem incluir:

redução de falhas funcionais;
redução de recorrência;
aumento de disponibilidade;
redução de tempo de diagnóstico;
redução de indisponibilidade logística;
redução de backlog crítico;
aumento da cobertura de modos críticos por controles;
redução de ativos com risco de obsolescência sem plano;
redução de corretivas emergenciais.

A ação só deve ser considerada eficaz quando a evidência de desempenho sustentar a conclusão.

Diagnóstico e ISO 55001:2024

A ISO 55001:2024 reforça tomada de decisão, riscos e oportunidades, criticidade dos ativos, dados, informação, planejamento e ciclo de vida. Um diagnóstico de confiabilidade pode alimentar diretamente esse sistema de gestão.

Os achados podem apoiar:

atualização de criticidade;
revisão de objetivos de gestão de ativos;
AMPs e roadmaps;
decisões de CAPEX;
gestão de riscos;
requisitos de dados;
revisão de estratégias de manutenção;
decisões de renovação e obsolescência.

Assim, confiabilidade deixa de ser apenas indicador operacional e passa a ser insumo para decisão de ciclo de vida.

Quando contratar um diagnóstico de confiabilidade

O diagnóstico tende a gerar maior valor quando há falhas recorrentes, disponibilidade abaixo da meta, grande volume de corretivas, dificuldade de explicar downtime, ativos críticos antigos, expansão de planta, integração de sistemas, baixa qualidade de dados ou necessidade de justificar investimentos de modernização.

Também é útil antes de estruturar programas de RCM, grandes revisões de manutenção ou planos de gestão de ativos. O diagnóstico ajuda a identificar onde métodos mais aprofundados realmente são necessários.

O entregável deve permitir decisão. Mais do que apontar problemas, um bom diagnóstico estabelece evidência, criticidade, mecanismo, prioridade e plano de melhoria, criando uma linha de base para acompanhar se a confiabilidade efetivamente evolui.

Diagnóstico sem roadmap é apenas fotografia. O valor aparece quando evidências são convertidas em prioridades, responsáveis, ações e critérios para medir a redução efetiva do risco.

Gestão de Ativos de Engenharia →

Referências técnicas

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

[2] IEC. IEC 60300-3-2:2004 — Dependability management — Part 3-2: Application guide — Collection of dependability data from the field. Geneva: IEC, 2004.

[3] IEC. IEC 60300-3-1:2003 — Dependability management — Part 3-1: Application guide — Analysis techniques for dependability — Guide on methodology. Geneva: IEC, 2003.

[4] IEC. IEC 62308:2006 — Equipment reliability — Reliability assessment methods. Geneva: IEC, 2006.

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

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

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

Perguntas frequentes

O que é um diagnóstico de confiabilidade de ativos?

É uma avaliação estruturada do desempenho de confiabilidade, disponibilidade, manutenibilidade e suporte dos ativos, baseada em dados de campo, condição, arquitetura, histórico de falhas e evidências técnicas.

Qual a diferença entre diagnóstico de confiabilidade e auditoria de manutenção?

A auditoria de manutenção costuma avaliar processos e execução da função manutenção. O diagnóstico de confiabilidade também investiga arquitetura, projeto, operação, dados, sobressalentes, obsolescência, condição e causas de perda da função.

É possível fazer diagnóstico com dados ruins?

Sim, desde que a baixa qualidade dos dados seja explicitada como limitação. O diagnóstico pode combinar histórico, inspeção, entrevistas, documentação, modelagem e outras evidências, sempre distinguindo dado observado de premissa.

Quais indicadores devem ser analisados?

Disponibilidade, falhas funcionais, MTBF, tempos de restabelecimento, recorrência, backlog crítico, emergências, indisponibilidade logística, custo e outros indicadores pertinentes ao sistema e à função analisada.

O diagnóstico precisa incluir FMEA ou RCM?

Não obrigatoriamente. FMEA, FMECA, RCM, RBD e outras técnicas devem ser aplicadas onde criticidade, incerteza ou complexidade justificarem maior profundidade.

Qual deve ser o principal entregável?

Uma linha de base de confiabilidade, achados sustentados por evidências, priorização por risco e impacto e um roadmap de melhoria com responsáveis, prazos e critérios de resultado.

Materiais técnicos complementares

Soluções relacionadas

Serviços de engenharia relacionados

Conteúdos técnicos correlatos

Guias, frameworks e referenciais