Norma SAE JA 1012 Versão Português

Norma
SAE JA1012
TREINAMENTO
CONSULTORIA
Manutenção
Centrada em
Confiabilidade
CERTIFICAÇÃO
www.sqlbrasil.com.br
PRÁTICA RECOMENDADA PARA VEÍCULOS DE SUPERFÍCIE E AEROESPACIAIS
Um Guia para o Padrão RCM.
Introdução – RCM foi documentada pela primeira vez em relatório escrito por F. S. Nowlan e H. F. Heap da
Companhia Aérea “United Airlines” e publicada pelo Departamento de Defesa dos Estados Unidos em 1978.
Descrevia estado da arte dos processos e metodologias, usados para o desenvolvimento da manutenção de
programas para aviões comerciais daquela época. Desde então, o processo RCM tem sido largamente usado
por outras indústrias, e extensivamente refinado e desenvolvido. Estes refinamentos têm sido incorporados e
aplicados em grande número de documentos, publicado por uma grande variedade de organizações por todo
o planeta. Muitos destes documentos permanecem fieis aos princípios básicos do RCM, como originalmente
explicitados por Nowlan e Heap.
Contudo, no desenvolvimento de alguns destes documentos, elementos-chave do processo RCM foram

omitidos ou não foram interpretados adequadamente. Devido ao crescimento da popularidade do processo
RCM, surgiram outros processos que foram denominados “RCM”, por seus criadores, porem não têm
nenhuma base no processo de Nowlan e Heap. Embora a maioria desses processos possa ter alcançado
alguns objetivos do RCM, uns poucos são contra producentes, e alguns são até mesmo perigosos.
Como resultado disso, tem havido um crescimento da demanda internacional para um padrão, que norteia os
critérios que qualquer processo deve atender de modo a ser denominado “RCM”. SAE JA1011 supre essa
necessidade. Entretanto SAE JA1011 pressupõe um elevado grau de familiaridade com os conceitos e
terminologia do RCM. Este guia amplia, e onde for necessário, esclarecem os termos e os conceitos-chave
especialmente àqueles que são inerentes ao RCM. Observe que este guia não tem como objetivo ser um
manual ou uma série normas de procedimentos RCM. Aqueles que desejam aplicar o método RCM são
fortemente encorajados a estudar o assunto de maneira mais detalhada, e desenvolver suas habilidades sob
a direção e experiência dos que praticam o RCM.
SAE JA 1012 – Um Guia para o Padrão RCM
Índice dos Assuntos
1. Objetivo __________________________________________________________________ 3
1.1. Como o Guia é Organizado _________________________________________________ 3
2.1. Documentos Pertinentes ___________________________________________________ 3
2.2. Publicações Relacionadas __________________________________________________ 3
2.3. Outras Publicações ______________________________________________________ 7
3. Definições _______________________________________________________________ 7
4. Siglas ___________________________________________________________________ 7
5. Definição de Ativo _________________________________________________________ 7
6. Lista de Funções __________________________________________________________ 8
6.1. Contexto Operacional _____________________________________________________ 11
6.2. Lista de Funções __________________________________________________________12
6.3. Descrição das Funções ____________________________________________________ 14
6.4. Padrões de Desempenho __________________________________________________ 15
7. Falhas Funcionais ________________________________________________________ 17
7.1. Falha Total ou Parcial _____________________________________________________ 17
7.2. Limite Superior e Inferior ___________________________________________________ 18
8. Modos de Falhas ________________________________________________________ 18
8.1. Identificação dos Modos de Falhas __________________________________________ 18
8.2. Estabelecendo o que significa “O Mínimo Aceitável” _____________________________ 19
8.3. Níveis de Causa ________________________________________________________ 20
8.4. Fontes de Informação ____________________________________________________ 22
8.5. Tipos de Modos de Falha __________________________________________________ 23
9. Efeitos da Falha _________________________________________________________ 24
9.1. Pré Supostos Básicos ___________________________________________________ 24
9.2. Informações Necessárias _________________________________________________ 24
10. Categoria de Conseqüências de Falhas _____________________________________ 26
Revisão 09/2013 Página 2 de 65

10.1. Categoria das Conseqüências _____________________________________________ 26
10.2. Avaliar as Conseqüências de Falhas ________________________________________ 30
11. Seleção das Políticas de Gerenciamento de Falhas ____________________________ 31
11.1. Relacionamento entre Idade e Falha ________________________________________ 31
11.2. Tecnicamente Viável e Valer a Pena ________________________________________ 32
11.3. Eficácia de Custo _______________________________________________________ 32
11.4. Seleção das Políticas nas Falhas de Gerenciamento ___________________________ 32
12. Gerenciamento das Conseqüências das Falhas ______________________________ 33
12.1. Modos de Falhas Evidentes com Conseqüências de Segurança

ou Ambiental _________________________________________________________ 33
12.2. Modos de Falhas Ocultas com Segurança ou Conseqüências

no meio Ambiental _____________________________________________________ 36
12.3. Modos de Falhas Evidentes com Conseqüências Econômicas ___________________ 36
12.4. Modos de Falhas não Ocultam com Conseqüências

Econômicas ___________________________________________________________ 37
13. Políticas de Gerenciamento de Falhas - Tarefas Programadas ___________________ 37
13.1. Tarefas Sob Condição ___________________________________________________ 37
13.2. Tarefas de Restauração Programada e Descarte Programado ____________________ 44
13.3. Tarefas de Busca de Falhas _______________________________________________ 45
13.4. Combinação de Tarefas __________________________________________________ 50
14. Políticas de Gerenciamento de Falhas – Modificações

Rodar até Falhar ________________________________________________________ 51
14.1. Modificações de uma só vez ______________________________________________ 51
14.2. Rodar até Falhar ______________________________________________________ 54
15. Seleção de Política de Gerenciamento de Falhas ____________________________ 54
15.1. Duas Abordagens _____________________________________________________ 54
15.2. Abordagem Rigorosa __________________________________________________ 54
15.3. Abordagem do Digrama de Decisão _______________________________________ 54
16. Um Programa Ativo ____________________________________________________ 58

17. Formulas Estatísticas e Matemáticas _____________________________________ 58
17.1. Logicamente Robusto __________________________________________________ 58
17.2. Disponível ao Proprietário ou Usuário ______________________________________ 58
18. Importantes Considerações Adicionais ____________________________________ 58
18.1. Priorizar Ativos e Estabelecer Objetivos ___________________________________ 63
18.2. Planejamento _______________________________________________________ 63
18.3. Nível de Analise e Limites do Ativo ______________________________________ 64
18.4. Documentação Técnica ________________________________________________ 64
18.5. Organização ________________________________________________________ 65
18.6. Treinamento ________________________________________________________ 65
19. Notas _______________________________________________________________ 65
19.1. Palavras-chave _____________________________________________________ 65
Figura 1 Função de uma Bomba ___________________________________________ 15

Figura 2 Deterioração Permitida ____________________________________________ 16
Figura 3 Modos de Falha de uma Bomba _____________________________________ 19
Figura 4 Modo de Falha em Diferentes Níveis de Detalhe _______________________ 22
Figura 5 Falha Evidente em uma Função de Proteção ___________________________ 28
Figura 6 Falha Oculta de uma Função de Proteção ____________________________ 29
Figura 7 Seis Padrões de Falha ___________________________________________ 31
Figura 8 Curva P – F ______________________________________________________ 38
Figura 9 Intervalo P - F ___________________________________________________ 39
Figura 10 Intervalo Liquido P - F _____________________________________________ 40
Figura 11 Falhas Aleatórias e Intervalo P – F ___________________________________ 41
Figura 12 Curva P – F Linear ________________________________________________ 42
Figura 13 Intervalos P - F Inconsistentes _______________________________________ 43
Figura 14 Limites de Vida Seguros ___________________________________________ 45
Figura 15 Busca de Intervalo de Falha, Disponibilidade e Confiabilidade_______________ 48
Figura 16 Primeiro Diagrama de Decisão _______________________________________ 59
Figura 17 Segundo Diagrama de Decisão _______________________________________ 60

1. Objetivo – SAE JA1012 (“Um Guia de Manutenção Centrada em Confiabilidade – RCM –

Padronizado”) amplifica e elucida cada um dos critérios-chave listados em SAE JA1011
(“Processo de Avaliação de Critérios para RCM”), e resume assuntos adicionais que
deverão ser aplicados para que o RCM obtenha sucesso.
1.1. Como o Guia é Organizado – As seções 5 a 14, 16 e 17 deste guia refletem a base do
SAE JA1011. A seção 15 explica em maiores detalhes como elementos-chave do processo
RCM podem ser combinados a fim de se selecionar políticas adequadas no gerenciamento
de modos de falha individuais e suas conseqüências. Seção 18 é direcionada ao
gerenciamento e fontes essenciais para o bom sucesso do desempenho do RCM.
2. Referências
2.1. Publicações Aplicadas / Inerentes – As publicações listadas as seguir, formam parte

deste documento, na sua extensão, aqui especificada. A menos que seja indicado de outra
forma a ultima emissão publicada do SAE, deve ser utilizada. O uso de outras publicações
de direito, devem constar na data em que o pedido for solicitado. Na eventualidade de
conflito entre o texto deste documento e as referências aqui citadas, predomina o texto
deste documento. Entretanto, nada que conste neste documento deve ultrapassar as leis e
regulamentos que nele se aplicam, a menos que uma exceção tenha sido obtida.
2.1.1 Publicação SAE – Pode-se obter do SAE, 400 Commonwealth Drive Warrendale, PA
155096-0001.
SAE JA1011 – Critério de avaliação para o processo de Manutenção Centrada em

Confiabilidade (RCM).
2.2. Publicações Pertinentes – As publicações a seguir têm como o objetivo informar e não
são parte dos requisitos deste Informativo Técnico SAE.
2.2.1 Departamento de Publicações Comerciais dos Estados Unidos – Pode-se obter do NTIS,
Port Royal Road, Springfield, VA 22161.
Nowlan, F. Stanley, and Howard F. Heap, “Manutenção Centrada em Confiabilidade”,

Departamento de Defesa, Washington, D. C. 1978, Report Number AD –
A066579.
2.2.2 Publicações do Departamento de Defesa dos Estados Unidos, disponível no

DODSSP, Balcão de Serviço de Assinaturas, Edifício 4 / Seção D, 700 Robbins Avenue,
Philadelphia, PA 191115098.
MIL – HDBK 2173 (AS) “Requisito de Manutenção Centrada em Confiabilidade” para

Aviões da Marinha, "Sistema de Armamentos e Equipamento de Apoio”, (U. S.
Comando Naval de Sistemas Aéreos) (Nota: Foi cancelado em agosto de
2001, sem reposição).
NAVAIR 00-25-403 - “Guia do Processo de Manutenção Centrada em Confiabilidade,

para a Aviação Naval”. (Comando de Sistemas de Aeronaval)
MIL – P 24534 – “Sistema de Manutenção Planejado": "Cartões de Requisito para o

Desenvolvimento de Manutenção, Índice de Paginas de Manutenção e
Documentação Associada”. (U. S. Comando de Sistema Oceano-Naval)
2.2.3 Publicação de Noticias Industriais – Disponível de Noticias Industriais, Inc 200 Madison
Avenue, New York City, New York, 10016 (Também disponível no Butter Worth –

Heinemann, Linacre House, Jordan Hill, Oxford, Great Britain OX2 8DP).
Moubray, John, “Manutenção Centrada em Confiabilidade”, 1997
2.2.4 U.K. Publicação do Ministério da Defesa – disponível no Grupo de Implementação da

Manutenção Centrada em Confiabilidade, Agência de Apoio a Navios, Ministério da Defesa
(Marinha). Sala 22, Bloco K, Foxhill, Bath, BA 1 5AB, Reino Unido.
NES 45 “Padrão Naval de Engenharia 45, Requisitos para a Aplicação das Técnicas
da Manutenção Centrada em Confiabilidade para HM Navios, Frotas Auxiliares
(Royal) Realeza e outras Embarcações Auxiliares da Marinha”. (Restritos-
Comercial)
2.3. Outras Publicações – As Publicações a seguir foram consultadas ao longo do

desenvolvimento deste Relatório Técnico SAE e não faz necessariamente parte deste
documento.
Anderson Ronald T. e Neri, Lewis, “Métodos de Engenharia e Gerenciamento de

Manutenção Centrada em Confiabilidade”. Elsevier Ciência Aplicada, Londres
e New York, 1990.
Adrews, J. D. e Moss, T. R., “Confiabilidade e Cota de Risco”, Lonuan, Harlow Essex
(U. K.), 1993.
Blanchard, B. S., D. Verma and Peterson, E.L. “Manutenção (Sustentabilidade) chave
para Serviço Efetivo e Manutenção de Gerenciamento”. John Wiley and Sons,
New York, 1995.
Cox, S.J. e Tait, N.R.S. “Confiabilidade, Segurança e Risco de Gerenciamento”.
Butterworth Heinemann, Oxford, 191.
“Dependência de Gerenciamento – Parte 3 – 11: Guia de Aplicação – Manutenção
Centrada em Confiabilidade” Comissão Internacional Eletrotécnica Genebra,
Doc. Nº 56/651/FDIS
Jones, Richard B., Gerenciamento Baseado em Risco: Aproximação Centrada em
Confiabilidade Cia de Publicações Guef, Husto, TX, 1995.
MSG 3, “Documento de Programa de Desenvolvimento da Manutenção” Associação
de Transporte Aéreo, Washington, D.C. Revisão 2, 1993
“Procedimento para o desempenho de um modo de falha, Análise Crítica e Efeitos”
Departamento de Defesa, Washington, D.C. Padrão Militar MIL – STD –
1629A., Aviso 2, 1984
“Manutenção Centrada em Confiabilidade para Aviões, Motores e Equipamentos”,
Força Aérea dos Estados Unidos, MIL – STD – 1843 (Nota: Foi Cancelado em
Agosto de 1995, sem reposição)
Smith, Antony M., “Manutenção Centrada em Confiabilidade”, McGraw – Hill, New
York, 1993.
Zwingelstein, G, “Manutenção Centrada em Confiabilidade”, um guia pratico para
implementação, Hermés, Paris, 1996.
1. Definições
3.1. Vida Útil (idade) – É a medida de exposição de cansaço, computada desde o instante em
que um item ou componente inicia sua trajetória operacional, ao ser colocado em uso
quando nova ou que reinicia seu trajeto, após ser restaurada em sua capacidade inicial, e
que pode ser avaliado em termos de tempo de uso, desgaste devido ao uso, distancia que é
submetido a viagens de longa distancia, ciclos de uso, unidades de rendimento, ou
quantidade colocada.

3.2. Serviço Realizado Adequadamente – Um serviço que é ao mesmo tempo tecnicamente

possível de ser realizado e que vale a pena ser feito (aplicável e afetivo).
3.3. Probabilidade Condicionada de Falha – A probabilidade de que uma falha venha a

ocorrer em um determinado período, considerando-se que o item em questão, tenha se
mantido com sobre venda até o inicio daquele período.
3.4. Desempenho Desejado – O nível de desempenho desejado pelo proprietário ou usuário de

um ativo físico ou um sistema.
3.5. Conseqüências Ambientais – O modo de falha ou múltiplas falhas têm conseqüências

ambientais se isso representar uma violação nos padrões do meio ambiente no que
concerne a uma corporação, municipal, regional, nacional ou internacional, ou uma
regulamentação aplicada a um ativo físico ou sistema sob consideração.
3.6. Falha Evidente – Um modo de falha cujos efeitos se tornam evidentes aos operadores dos
equipamentos sob circunstâncias normais, caso o modo de falha ocorre no próprio
equipamento.
3.7. Função Evidente – Uma função cuja falha ocorre no próprio equipamento, se torna
evidente aos seus operadores sob circunstancias normais.
3.8. Conseqüências de Falha – A forma em que os efeitos de um modo de falha, ou múltiplas

falhas (falha evidente, impacto, ou segurança, meio-ambiente, capacidade operacional,
custos do conserto feitos diretamente ou indiretamente).
3.9. Efeito da Falha – O que acontece quando um modo de falha ocorre.
3.10. Tarefa de busca de Falha – Uma tarefa programada usada para determinar se ocorreu
uma falha oculta específica.
3.11. Política de Gerenciamento de Falha – termo genérico que inclui condição de trabalho,
esquema de restauração esquema de rejeição, falha detectada, rodar até falhar mudanças
imediatas.
3.12. Modo de Falha – Acontecimento único que ocasiona falha funcional.
3.13. Função – É a expectativa que o proprietário e o usuário têm do desempenho de um sistema

ou ativo físico.
3.14. Falha Funcional – Situação em que um sistema ou ativo físico não são hábeis no
desempenho de função especifica, em nível ideal de desempenho.
3.15. Falha Oculta – Modo de falha cujos efeitos não são vistos pelos operadores em
circunstancias normais, caso ocorra falha sob sua responsabilidade.
3.16. Função Oculta – Função cuja falha não é vista pelos operadores em circunstâncias
normais.
3.17. Capacidade Inicial – Nível de desempenho que um ativo físico ou sistemas são capazes
de assimilar no momento em que iniciam seu trabalho.
3.18. Falhas Múltiplas – Evento que acontece se a função que está protegida falha, se o
dispositivo de proteção se encontra em estado de falha.

3.19. Intervalo de Rede – P – F – Intervalo mínimo entre a descoberta de uma falha em potencial
e a ocorrência de falha funcional.
3.20. Conseqüências Não Operacionais – Categoria de conseqüências de falhas que não afeta
adversamente segurança, meio ambiente ou operações, mas que requer somente conserto
ou substituição de algum item que passa ser afetado pela falha.
3.21. Condição de Ideal de Tarefa – É uma tarefa programada para detectar uma falha em
potencial.
3.22. Modificação Imediata – Ação tomada para mudar a configuração física de um ativo ou
sistema (redesenhado ou modificado), para alterar o método usado pelo operador ou
responsável pela manutenção do desempenho de tarefa específica, a fim de mudar o
contexto do sistema em operação ou mudar a capacidade do operador ou responsável pela
manutenção (treinamento).
3.23. Contexto Operacional – Circunstância em que um ativo físico ou sistema que se espera
que opere normalmente.
3.24. Conseqüências Operacionais – Categoria de falha que afeta adversamente a capacidade

operacional de um ativo fixo ou sistema (saída de material, qualidade do produto, serviço ao
consumidor, capacidade militar, ou custos adicionais somados a custo de reparo).
3.25. Proprietário – Pessoa ou organização que pode ser responsabilizada ou sofrer as

conseqüências do modo de falha em decorrência de ser proprietário do ativo ou do sistema.
3.26. Intervalo P – F – Intervalo entre o ponto em que uma falha em potencial é detectada,
levando a conseqüente degradação de falha funcional (também conhecida como “período
de desenvolvimento de falha” e “tempo que leva à falha”).
3.27. Falha em Potencial – Condição identificada que indica que uma falha de função pode
ocorrer ou que está prestes a ocorrer.
3.28. Manutenção Pró-Ativa – Manutenção empreendida antes que a falha ocorra, de modo a
prevenir o item de entrar em um estado de falha (restauração programada, descarte
programado e manutenção sob condição).
3.29. Dispositivo de Proteção ou Sistema de Proteção – Dispositivo ou sistema com o objetivo

de evitar, eliminar ou minimizar as conseqüências de falhas de algum outro sistema.
3.30. Função (ões) Primária (s) – Função ou funções que se constituem a razão principal do
porque de um ativo físico ou sistema ser adquirido ou por seu proprietário ou usuário.
3.31. Rodar até Falhar – A política gerencial de falha que permite que um modo de falha
específico ocorra sem que haja qualquer tentativa de antecipar ou prevenir que isso ocorra.
3.32. Conseqüências de Segurança – Modo de falha ou falhas múltiplas têm conseqüências de

segurança, caso ocorra ferimentos ou perda de vida de seres humanos.
3.33. Programas – Desempenhados em intervalos fixos, pré-determinados, incluindo

“monitoração continua” (quando efetivamente o intervalo é zero).

3.33.1. Supressão de Programa – Tarefa programada que envolve a supressão de um item na

sua condição real, ou antes, da idade limite, independente da sua condição naquele
momento.
3.34. Restauração Programada – Tarefa programada que restaura a capacidade de um item na

condição real, ou antes, de intervalo especifico (vida útil), independente da sua condição
naquele momento, a um nível tolerável de probabilidade de sobrevivência até o final de
outro intervalo específico.
3.35. Funções Secundárias – Funções cujo ativo físico ou sistema têm que realizar
independente de suas funções primárias, ou seja, aquelas necessárias para realização de
requisitos que regulam, e aqueles que se referem a assuntos quais sejam: proteção,
controle, contenção, conforto, aparência, energia e integridade estrutural.
3.36. Usuário – Pessoa ou organizador que opera um ativo ou sistema e que pode sofrer ou ser
responsabilizado pelas conseqüências de modo de falha ou desse sistema.
4. Siglas
BITE Equipamentos fixos para Teste.

FFI Intervalo (tarefa) Detectar Falha
FEMEA Modo de Falha e Analise dos Efeitos
MM Milímetros
MMF Intervalo entre Falhas Múltiplas
MTBF Intervalo médio entre Falhas
MTED Intervalo médio entre Falhas da Função Protegida
MTIVE Intervalo médio entre Falhas do Dispositivo de Proteção
PSI Libras por Polegada Quadrada
RCM Manutenção Centrada em Confiabilidade
EPM Revolução por Minuto
UTIVE Indisponibilidade Permitida de Função Protegida
5. Definição de Ativo – “RCM é um processo especifico usado para identificar as políticas

que devem ser implementadas para gerenciar o modo de falha que poderia causar falha
funcional de qualquer ativo físico dado em um contexto operacional” (SAE JA1011, seção
1.1).
Para identificar adequadamente políticas de gerenciamento de falhas para qualquer ativo

físico ou sistema, o ativo ou sistema precisam ser definidos. Isso envolve a seleção de ativo
/ sistema, definindo seus limites e identificando o mais apropriado nível de detalhe, para que
a análise seja levada avante.
SAE JA1011 refere aos processos usados na seleção das políticas adequadas no
gerenciamento de falhas, supondo-se que o ativo / sistema já tenha sido selecionado e
definido. Isso não significa que haja critério nos processos a serem usados para seleção e
definição dos próprios ativos ou sistemas, porque tal processo tende a ser altamente
dependente do tipo de ativo / sistema, onde e para que, e por quem ele está sendo (ou
será) usado. Entretanto, alguma informação generalizada sobre este tópico é encontrada na
seção 18 deste guia.
6. Funções – Um processo RCM feito em conformidade com a SAE JA 1011 se inicia com a
seguinte pergunta: “Quais são as funções e padrões desejados em associação ao
desempenho do ativo deste contexto operacional (funções)?” Esta seção discute os quatros
conceitos-chave relativos a funções que estão listadas na seção 5.1 do SAE JA 1011:

a. Contexto operacional
b. Funções primárias e secundárias
c. Lista de funções
d. Padrão de desempenho
6.1. Contexto Operacional – “O contexto operacional do ativo deverá ser definido” (SAE JA
1011, seção 5.1.1)
As funções, modo de falha, conseqüências de falha e políticas de gerenciamento de falha

que serão aplicadas a qualquer ativo não vão depender somente de que ativo ele se refere,
mas também das exatas circunstâncias em que ele será aplicado. Como resultado, estas
circunstâncias precisam ser claramente definidas antes de qualquer tentativa de se
responder à pergunta acima citada.
Uma declaração contextualizada de operação para ativo físico inclui tipicamente uma breve
e completa descrição de como deve ser usado, onde deve ser usado, total critério de
desempenho que governe itens como: saída de material, quantidade de trabalho,
segurança, integridade do meio-ambiente e assim por diante. Itens específicos que
deveriam ser documentados no contexto de segurança operacional incluem:
a. Quantidade versus processo de fluidez: ou seja, o ativo é executado em processo

quantitativo (intermitente) ou em processo de fluidez (contínuo);
b. Padrão de Qualidade: Qualidade total ou serviço ao consumidor realizado a
contento em termos de emissão qual seja, taxa de refugo, satisfação do cliente
(tais como: desempenho desejado em sistemas de transporte imediato ou taxa de
reivindicação de garantia por bens manufaturados) ou aparelhamento militar;
c. Padrões de Meio-Ambiente: Quais os padrões de meio-ambiente que se aplicam
(se houver algum) ao ativo organizacional, regional, nacional e internacional;
d. Padrões de Segurança: Se alguma expectativa predeterminada de segurança (em
termos de taxa total de ferimentos e / ou mortes) se aplica ao ativo;
e. Palco de Operações: Características do local onde o equipamento vai ser operado
(ártico versus tropical, deserto versus selva, à beira-mar versus mar adentro,
proximidade das fontes de suprimento de partes e / ou mão-de-obra etc.);
f. Intensidade das operações: No caso de haver fabricação e extração de minério,
se o processo cujo equipamento faz parte da execução 24 horas do dia, sete dias
por semana, ou seja realizado com intensidade menor. No caso de serviço publico
se o equipamento opera sob carga máxima ou carga normal. No caso de
equipamento militar, se a política de gerenciamento de falhas ocorre em tempos
de paz ou se ocorre em tempos de guerra.
g. Redundância: Se há algum poder de redundância ou de apoio, e se caso houver,
que formato isso tem;
h. Tarefa em andamento: A que extensão é permitida que os estoques da tarefa em
andamento (se houver algum) parem sem que isso afete a saída de material ou de
contingente.
i. Sobressalentes: Se tiver sido tomada qualquer decisão a respeito de estoques-
chave de sobressalentes que possa alterar a política subseqüente de
gerenciamento de seleção de falhas.
j. Demanda de mercado / suprimentos de matéria-prima: Se flutuações cíclicas na
demanda de mercado e / ou suprimento de matéria-prima são passíveis de
alteração nas políticas subseqüentes da seleção de gerenciamento de falhas (tais
flutuações podem ocorrer no decurso de um dia, se for o caso de ônibus de
transporte urbano, ou no decorrer de um ano, se for o caso de estação de energia
elétrica, um parque de diversões, ou um fábrica de processamento de alimentos).

No caso de um sistema complexo e de grandes proporções, poderia ser mais sensato

estruturar o contexto operacional de uma maneira hierárquica, se necessário iniciar a
missão com toda a organização que está usando o ativo.
6.2. Lista de Funções – “Todas as funções do ativo / sistema devem ser identificadas (todas as
funções primárias e secundárias incluindo as funções de todos os dispositivos protetores)”.
(SAE JA 1011 seção 5.1.2)
O objetivo do processo RCM é desenvolver uma gama de políticas que salvaguarde as

funções dos ativos ou um sistema sob padrões de desempenho que sejam aceitos pelos
seus proprietários / usuários. Como resultado, o processo RCM se inicia com a identificação
de todas as funções do ativo em seu contexto operacional.
Funções podem ser divididas em duas categorias: funções primárias e funções secundárias.
6.2.1 Funções Primárias – A razão porque uma organização adquire um ativo ou sistema, tem
como propósito preencher uma função especifica / varias funções. São conhecidas como
funções primárias de um ativo. Por exemplo, a razão principal porque alguém adquire um
carro, talvez seja para “transportar 5 pessoas a uma velocidade de 90 km por hora,
rodando em rodovias ideais”.
6.2.2 Funções Secundárias – Espera-se da maioria dos ativos, que desempenhem outras
funções além das funções primárias. São conhecidas como suas funções secundárias. As
funções secundárias são geralmente menos óbvias que as funções primárias. Mas a perda
de uma função pode acarretar sérias conseqüências, e algumas vezes, mais severas do
que a perda da função primária. Como conseqüência, as funções secundárias necessitam
freqüentemente de tanta atenção quanto, se não, mais atenção ainda do que as funções
primárias, portanto elas também devem ser claramente identificadas.
Quando as funções secundárias são identificadas, alguns cuidados devem ser tomados
para que não haja descuido nas seguintes situações:
a. Integridade do meio-ambiente;
b. Segurança / integridade estrutural
c. Controle / contenção / conforto
d. Aspecto externo
e. Dispositivo de proteção e sistemas
f. Economia / eficiência
g. Supérfluos
Estes assuntos são discutidos a seguir em maiores detalhes.
6.2.2.1 Integridade do meio-ambiente – Estas funções definem a extensão em que o ativo deve
estar, quando em concordância com a corporação municipal, regional, nacional e
internacional, no que tange os padrões do meio ambiente ou regulamentos que se
aplicam ao ativo. Estes padrões governam coisas como, a liberação de materiais
perigosos no meio ambiente, assim como poluição sonora.
6.2.2.2 Segurança – É algumas vezes necessário escrever declarações sobre funções que
lidam especificamente com ameaças de segurança inerentes ao projeto ou operação do
processo (em oposição à ameaça de segurança que é resultado de falha funcional). Por
exemplo, a função de isolação em um aparelho elétrico residencial é “Evitar que os
usuários toquem em componentes elétricos expostos”.

6.2.2.3 Integridade Estrutural – Muitos ativos têm a função secundária de prover apoio para / ou
ter um suporte seguro para outro item. Por exemplo, enquanto que a função primária de
uma parede deva ser a de proteger as pessoas e equipamentos das intempéries, pode
também se esperar que ela dê apoio ao telhado, ou que suporte o peso de prateleiras e
quadros.
6.2.2.4 Controle – Em muitos casos, usuários não somente querem ativos para preencher
funções de um padrão de desempenho, mas eles também podem ser capazes de
ajustar esse desempenho. Esta expectativa é sintetizada em declarações de função, em
separado. Por exemplo, a função de um sistema de refrigeração, talvez possa regular a
temperatura desejada, entre uma temperatura especifica e outra. Indicação e retorno
formam um importante sub-dispositivo no controle das categorias de funções.
6.2.2.5. Contenção – Sistemas cuja função primária é armazenar materiais e muito mais,
acondicioná-los. Similarmente, sistemas que transferem materiais – especialmente
líquidos – também têm a função de contenção. Estas funções precisam ser também
especificadas.
6.2.2.6 Conforto – Geralmente os proprietários e usuários esperam que seus ativos ou sistemas
não causem dor ou ansiedade aos operadores ou mantenedores. Estes problemas
deveriam é claro, ser considerados no estagio inicial do seu projeto. Entretanto,
deterioração ou mudanças de expectativa podem levar a um nível inaceitável de dor ou
ansiedade. A melhor maneira de assegurar que isso não aconteça é se certificar que as
declarações de função associada estejam descritas de forma precisa e que elas reflitam
totalmente os padrões em curso.
6.2.2.7 Aspecto Externo – O aspecto externo constitui uma função secundária importante Por
exemplo, o motivo principal da maioria dos equipamentos industriais ser pintada é para
protegê-los contra a corrosão. Entretanto, uma cor brilhante pode ser escolhida a fim de
que sua visibilidade se destaque por medida de segurança, e também esta função
deveria ser documentada.
6.2.2.8 Proteção – As Funções protetoras evitam, eliminam ou minimizam as conseqüências de

falha em alguma outra função. Estas funções estão associadas com dispositivos ou
sistemas que:
a. Avisam os operadores sobre condições anormais (luz de advertência ou alarmes);

b. Dispositivo que desliga o equipamento no caso de falha funcional (mecanismos
para desligar);
c. Elimina ou libera condições anormais ocasionadas por uma falha funcional
(liberação de mecanismo, sistema de supressão de incêndio, preservação de
vida);
d. Substituição de uma função que falhou (componentes de estrutura redundante,
planta de apoio);
e. Previne situações de perigo antes que se chegue ao local (sinais de perigo,
coberturas de proteção).
Função protetora assegura que falha de função quando protegida é muito menos
séria do que seria quando está sem proteção. Os dispositivos associados são
incorporados no sistema a fim de reduzir riscos, de tal forma que suas funções
deveriam ser documentadas com cuidados especiais.
6.2.2.9 Economia / Eficiência – Na maioria das organizações as expectativas de custo total são
expressas na forma de gastos orçamentários. Entretanto para ativos específicos, as
expectativas de custos podem ser endereçadas diretamente por declaração de função

secundária concernente a coisas como taxa de consumo de energia e taxa de atrito de

materiais processados.
6.2.2.10 Funções Supérfluas – Alguns sistemas incorporam itens que são completamente
supérfluos. Isso acontece geralmente quando o equipamento ou a maneira em que ele é
usado tenha sido modificado após um período de anos, ou quando um equipamento
novo é superdimensionado.
Embora tais itens não possuam função positiva e são com freqüência muito cara para
serem removidos, eles podem de fato falhar e, portanto reduzir todo sistema de
confiabilidade. Para que isso seja evitado, alguns podem requerer manutenção e assim
consumir recursos.
Se eles são removidos, os modos de falha associados e os custos serão também

removidos. Entretanto, antes que sejam removidos, podem ser recomendadas com
confiança, suas funções precisam ser claramente identificadas e compreendidas.
6.2.2.11 Funções / Confiabilidade – Há freqüentemente tendências de se escrever declarações

de função de “confiabilidade” para “operar 7 dias por semana, 24 horas por dia”. De fato,
confiabilidade não é uma função no seu próprio direito. É uma expectativa de
desempenho que permeia todas as outras funções. Além de tudo, gols de confiabilidade
/ disponibilidade podem ser documentados no contexto da declaração. A confiabilidade
de um ativo específico é de fato gerenciada, quando apropriadamente lidado com cada
modo de falha que poderia causar perda de função.
6.3. Descrição das Funções –“Todas as declarações de função devem inserir um verbo, um
objeto, e um padrão de desempenho (quantitativo em cada caso onde isso possa ser feito).”
(SAE JA 1011, seção 5.1.3)
Por exemplo, a figura 1 mostra uma bomba, bombeando água de um tanque para outro. A
capacidade nominal da bomba é de 1000 litros por minuto, e a água é retirada do tanque a
um índice máximo de 800 litros por minuto. A função primária desta bomba seria descrita
como: “Bombear água do tanque X para o tanque Y, a não menos do que 800 litros por
minuto”. Aqui o verbo é “bombear”, o objeto é “água”, e o padrão de desempenho é “do
tanque X para o tanque Y a não menos do que 800 litros por minuto”.
Declarações de função de proteção necessitam manuseio especial. Estas funções são

exceção – em outras palavras, quando alguma coisa sai errada – a declaração da função
deveria refletir esse fato. Isso é geralmente feito ao se incorporar as palavras “se” ou “no
caso de”, seguida de um breve resumo das circunstâncias ou acontecimento que ativaria a
proteção. Por exemplo, a função de uma válvula de pressão de segurança pode ser descrita
como se segue: “ser capaz de liberar a pressão de uma caldeira se ela exceder a 250 psi."

Figura 1 – Função de uma bomba
6.4. Padrões de Desempenho –“Padrões de desempenho incorporados em declarações de

função devem ser o nível de desempenho desejado pelo proprietário ou usuário do ativo /
sistema no seu contexto operacional”. (SAE JA 1011, seção 5.1.4)
Qualquer sistema organizado exposto ao mundo real irá se deteriorar – até a total
desorganização (também conhecida como “caos" ou “entropia”) – a menos que alguns
passos sejam tomados para se lidar com o que quer que esteja causando a deterioração do
sistema.
Por exemplo, bombas centrífugas estão sujeitas ao desgaste dos impelidores. Isso
acontece quando a bomba movimenta ácido ou óleo lubrificante, e se os impelidores são
feitos de titânio ou aço doce. A única questão é quão rápido os impelidores se desgastaram
a ponto de não conseguir bombear fluídos na taxa de vazão mínima requerida.
Uma vez que o desempenho de um ativo cai abaixo do mínimo aceitável pelo usuário
aquele ativo falhou. Por outro lado, se o desempenho do ativo é usado acima deste mínimo,
ele continua a funcionar a um nível satisfatório para o usuário. Como se verifica neste guia,
“usuários” incluem os proprietários dos ativos – geralmente os operadores – e a sociedade
como um todo. Proprietários ficam satisfeitos se seus ativos geram um retorno satisfatório
do investimento feito, ao adquiri-los (geralmente retorno para operações comerciais ou
outras medidas para operações não comerciais). Usuários ficam satisfeitos se cada ativo
continua realizando o que eles querem que ele realize num padrão de desempenho – que
eles – os usuários considerão satisfatório. Finalmente, a sociedade como um todo está
satisfeita se os ativos não falham de forma a ameaçar a segurança pública e o meio-
ambiente.
Em suma, isto quer dizer que se nós estamos buscando um ativo que continue a funcionar a
um nível que seja satisfatório ao usuário, então o objetivo da manutenção é assegurar que
os ativos continuem a desempenhar acima do nível mínimo aceitável para aqueles usuários.
Se fosse possível construir um ativo que pudesse fornecer um mínimo de desempenho sem
que se deteriorasse de nenhuma forma, então ele seria capacitado a rodar continuamente,
sem necessidade de manutenção.
Entretanto, a deterioração é inevitável, deveria então ser permitida. Isto quer dizer que
quando algum ativo é colocado em atividade, ele deve ser capaz de fornecer, mais do que o
padrão mínimo de desempenho desejado pelo usuário. O que o ativo é capaz de fornecer
neste ponto é conhecido como sua capacidade inicial. A figura dois mostra o
relacionamento correto entre esta capacidade e desempenho desejado.

Isto quer dizer que o desempenho pode ser definido de duas maneiras:
a. Desempenho desejado (o que o usuário quer que o ativo realize);

b. Capacidade estruturada (o que isso pode fazer)
Figura 2 – Deterioração permitida
A margem para deterioração precisa ser grande o suficiente que permita um uso razoável
antes que o componente se degrade, ocasionando falha funcional, mas não grande o
suficiente que o sistema seja “muito sofisticado” e, portanto, muito caro. Na prática, a
margem é adequada no caso da maioria dos componentes, desse modo é geralmente
possível desenvolver programas de manutenção adequados.
Entretanto se o desempenho desejado é maior que a capacidade intrínseca, nenhuma

quantidade de manutenção poderá fornecer o desempenho desejado, caso, portanto, em
que o ativo não admite manutenção.
Tudo isso quer dizer que, para averiguar se o ativo pode ser mantido, nós precisamos
conhecer ambos os tipos de desempenho: capacidade intrínseca do ativo e o desempenho
mínimo que o usuário está preparado para aceitar, de acordo com o contexto em que o
ativo está sendo usado. Este desempenho mínimo é o desempenho padrão que precisa ser
incorporado na declaração da função.
Por exemplo, a capacidade inicial da bomba na figura 1 é de 1000 litros por minuto, e a taxa
em que a água está sendo retirada do tanque (fornecida) é 800 litros por minuto. Neste
contexto, a bomba preenche as expectativas dos seus usuários, enquanto ela continua a
bombear água para dentro do tanque, mais rápido do que é retirada. Como resultado, a
função primária da bomba foi descrita como sendo “bombear água do tanque X para o
tanque Y, a não menos do que 800 litros por minuto”, e não “bombear 1000 litros por
minuto”. Note que se a mesma bomba tivesse que ser usada numa situação onde o
fornecimento do tanque fosse (digamos) 900 litros por minuto, então a função primária seria,
“bombear água do tanque X para o tanque Y a não menos que 900 litros por minuto”, e o
programa de manutenção seria mudado para refletir esta nova expectativa de desempenho.
Note que os usuários e mantenedores têm como freqüência, significantemente diferentes

visões sobre o que se constitui desempenho aceitável. Como resultado, para evitar mal-
entendidos sobre o que se constitui “falha funcional”, o padrão de desempenho mínimo

aceitável, deve ser claramente compreendido e aceito pelos usuários e mantenedores do

ativo junto com qualquer outra pessoa que tenha interesse legítimo no comportamento do
ativo.
Padrões de desempenho precisam ser quantificados onde for possível, porque padrões
quantitativos são mais claros e mais precisos do que padrões qualitativos. Ocasionalmente
é somente possível usar padrões qualitativos, por exemplo, quando se lida com funções
relacionadas com a aparência. Nestes casos, um cuidado especial deve ser tomado para
assegurar que o padrão qualitativo é compreendido e aceito pelos usuários e mantenedores
do ativo.
7. Falhas Funcionais – Um processo RCM em conformidade com SAE JA 1011, pergunta o

seguinte: “De que maneira ele falha a fim de preencher sua função (falha funcional)?“ Para
responder essa questão satisfatoriamente, SAE JA1011 seção 5.2 declara que “todos
estados de falha, associados com cada função devem ser identificados”.
Seção 6 explica que um ativo falha se ele é incapaz de fazer o que os usuários querem que
ele faça. Explica também que o que o ativo precisa fazer para ser definido como uma
função e que todo ativo tem mais de uma (e com freqüência, várias) funções diferentes.
Desde que é possível haver falha em cada uma dessas funções, conseqüentemente,
qualquer ativo pode sofrer uma variedade de estados de falha.
Por exemplo, a função primária da bomba na figura 1 era “bombear água do tanque X para
o tanque Y a não menos do que 800 litros por minuto”, enquanto uma função secundária é
para “conter a água na bomba”. É possível para tal bomba ser capaz de bombear a
quantidade de água desejada (não falhar em termos de sua função primária) ao gotejar
excessivamente (falhou na sua função secundária). Opostamente, é igualmente possível
para a bomba se deteriorar a um ponto onde não pode bombear a quantidade desejada
(falhou na sua função primária) enquanto ela ainda contém o liquido desejado (não falhou
na sua função secundária).
Por essa razão, é mais exato definir falha em termos de perda de funções específicas, em
vez de falha total de um ativo. O exemplo anterior também mostra porque o processo RCM
usa o termo “falha de função” para descrever estado de falha, ao invés de “falha” própria
(note que RCM faz distinção entre: uma falha de função, e modo de falha, que é um
exemplo que ocasiona estado de falha próprio).
Dois pontos devem ser considerados quando as falhas definidas são: falha parcial ou falha
total, e limites altos e limites baixos.
7.1. Falha Parcial e Total – Falhas funcionais que representam a falha total da função são
relativamente fáceis de serem identificadas. Por exemplo, é claro que a bomba mencionada
em 6.3 terá sofrido uma falha funcional se ela falhar em bombear qualquer quantidade de
água (falha total). Entretanto, a bomba também terá sofrido uma falha funcional se ela puder
bombear água, mas, a taxa com que ela faz este bombeamento é menor que 800 litros por
minuto.
O segundo estado de falha neste exemplo é conhecido como uma “falha parcial”. Falhas
parciais precisam ser identificadas separadamente porque elas são, na maioria das vezes,
causadas por diferentes modos de falha relacionados à falha total e porque as
conseqüências são também quase sempre diferentes.
Tenha em mente que falha parcial não é o mesmo que deterioração abaixo da sua
capacidade inicial. Todas as coisas deterioram abaixo de sua capacidade inicial após algum
uso, e tal deterioração pode ser tolerada até que não atinja o ponto que é inaceitável para o

usuário do ativo, como mostrado na figura 2. Deterioração somente se torna falha funcional
(parcial ou total) quando o desempenho cai abaixo do nível mínimo exigido pelo usuário.
7.2. Limites Superiores e Inferiores – Os padrões de desempenho associados com algumas

funções incorporam limites superiores e inferiores. Estes limites significam que o ativo
falhou se ele desempenha acima do limite superior ou abaixo do limite inferior. Nestes
casos, a violação do limite superior precisa ser documentada separadamente da violação do
limite inferior. Isto porque os modos de falha e/ou as conseqüências associadas com
exceder o limite superior são usualmente diferentes daquelas associadas com ir abaixo do
limite inferior.
Por exemplo, a função primária de uma máquina de fresar pode ser listada como: “fresar
mancais num ciclo de 3,00 minutos ± 0,03 minutos, para um diâmetro de 75 mm ± 0,1mm,
com um acabamento superficial não maior que Ra 0,2”. Esta máquina falhou se:
a. Parou totalmente.
b. Se fresa uma peça num ciclo de tempo maior que 3,03 minutos.
c. Se fresa uma peça num ciclo menor que 2,97 minutos.
d. Diâmento excede 75,1mm.
e. Diâmetro está abaixo de 74,9mm.
f. Acabamento superficial muito áspero (excede Ra 0,2).
8. Modos de Falha - Um processo RCM em conformidade com a SAE JA1011 então faz a
pergunta, “Que causa cada falha funcional (modos de falha)?” Esta seção discute os
seguintes cinco conceitos-chave concernentes aos modos de falha que estão listados na
5.3 da SAE JÁ 1011:
a. Identificar modos de falha.

b. Estabelecer qual é o significado de “razoavelmente provável”
c. Níveis das causas.
d. Fontes de informação.
e. Tipos de modos de falha.
8.1. Identificar Modos de Falha – “Todos os modos de falha razoavelmente prováveis de

causar cada falha funcional deverão ser identificados.” (SAE JÁ 1011, seção 5.3.1).
A seção 7 deste Guia mencionou que o RCM distingue entre o estado de falha do ativo
(falha funcional) e os eventos que causam os estados de falha (modos de falha). Porque é
impossível definir as causas de falha até que possamos estabelecer exatamente o que
queremos dizer por “falha”, o processo RCM identifica falhas funcionais antes dos modos de
falha. A maneira pela qual isso é geralmente documentado está na figura 3, para a função
primária de uma bomba ilustrada na figura 1. Figura 3, que lista uma função do ativo, falhas
funcionais e modo de falhas, mostra de perto todos os elementos de um Modo de Falha e
Análise dos Efeitos (FMEA). Os “efeitos” de cada modo de falha são listados em um passo
subseqüente (veja seção 9 deste Guia).
A figura 3 também mostra que no mínimo, a descrição de um modo de falha deveria

consistir de um substantivo e um verbo. A descrição deveria conter detalhes suficientes
para que seja possível selecionar uma política de gerenciamento de falhas apropriada,
porém sem muitos detalhes, para que não haja muito tempo desperdiçado na análise do
processo.

Em particular, os verbos usados para descrever modos de falha deveriam ser escolhidos
com cuidado, porque eles influenciam fortemente no processo de seleção da política de
gerenciamento da falha subseqüente. Por exemplo, verbos como: ”falhar”, “quebrar”, ou que
”mau funcionamento” deveriam ser usados raramente, porque há pouca ou quase nenhuma
indicação de como deveria ser a maneira apropriada de como um modo de falha deva ser
gerenciado. O uso de verbos mais específicos torna possível a seleção de toda uma gama
de opções no gerenciamento de falhas.
Por exemplo, o modo de falha 1A4 na Figura 3, poderia ter sido expresso como “falha de
acoplamento”. Entretanto uma expressão como essa, não dá nenhuma indicação do que
deveria ser feito para antecipar ou prevenir um modo de falha. Se dissermos “os pinos
acoplados vêm soltos” ou “o acoplamento do eixo das tesouras está solto devido à fadiga”,
torna-se então muito mais fácil antecipar a identificação de uma tarefa.
Figura 3 - Modo de falha de uma bomba
Para válvulas, conectores e dispositivos similares, o modo de falha descrito deveria indicar
se a perda da função é ocasionada pela falha do item, quando ele está na posição abrir/
fechar. ”Válvulas fechadas por bloqueio” querem dizer mais do que “válvulas bloqueadas”.
Além disso, o propósito de se identificar modos de falha é justamente, identificar a causa da
falha da função de maneira a se encontrar ou antecipar a falha, ou prevenir que ela ocorra.
Como resultado é possível, que algumas vezes seja necessário se adiantar e tomar uma
decisão, qual seja: “válvulas fechadas por bloqueio devido à ferrugem no parafuso
principal”. Neste contexto, o uso da palavra “ferrugem” sugere que talvez seja apropriado
focar esforços no sentido de gerenciar a falha, detectando ou controlando a ferrugem.
8.2. Estabelecer o que significa: “Razoavelmente Possível” – “O método usado para decidir
o que se constitui “razoavelmente” um modo de falha, deve ser aceito pelo proprietário ou
usuário do ativo (SAE JÁ 1011, seção 5.3.2.).
Seção 8.1 menciona que todos os modos de falha que razoavelmente causam cada falha
funcional devem ser identificados. “Razoavelmente” significa exatamente isso: Uma
semelhança que satisfaz o teste da racionalidade, quando aplicado por pessoal treinado e
com conhecimento de causa. (Um termo freqüentemente usado no lugar de “Razoável”

neste contexto é a palavra “credibilidade”). Se as pessoas que são treinadas para usar o
RCM, e que têm conhecimento do ativo no seu contexto operacional, concordarem que a
probabilidade de que a ocorrência de um modo de falha específico seja suficientemente alta
para garantir futuras análises, então aquele modo de falha deveria ser listado.
Na prática, é algumas vezes muito difícil decidir se o modo de falha deveria ou não ser
listado. Esta emissão é relacionada a ambas as probabilidades de ocorrência, assim como o
nível de detalhe usado para descrever os modos de falha. Muito poucos modos de falha, e/
ou pequenos detalhes, direcionam as análises superficiais e algumas vezes a análises
perigosas. Muitos modos de falha, e/ ou muitos detalhes, ocasionam a todo processo RCM
mais tempo gasto, do que o necessário. Em casos extremos, isso pode causar o processo
de se gastar duas ou até três vezes mais o tempo necessário (Um fenômeno conhecido
como “análise paralisante”) e também pode conduzir a programas de manutenção não
muito eficientes.
Nas situações onde pode haver dúvidas ou desacordos em como é constituído o limiar da
“racionalidade”, a decisão final precisa ser tomada pela organização que possui ou usa o
ativo, porque a organização em última análise será responsável pelas conseqüências, se
ocorrer modo de falha.
Note que a decisão de se listar modo de falha deveria ser avaliada, considerando-se as
conseqüências. Se as conseqüências forem de fato muito severas, então modos de falha
com menor possibilidade de ocorrer devem ser listados e submetidos à análise.
Por exemplo, se a bomba descrita na figura 3 fosse instalada em uma indústria alimentícia
ou em uma montadora de veículos, o modo de falha “cobertura esmagada por objeto vindo
do céu” seria imediatamente recusado como sendo hilariamente impossível. Entretanto se
essa mesma bomba bombeasse líquido frio para um reator nuclear, em uma fábrica
comercial, esse modo de falha tem tudo pra ser considerado com seriedade – muito embora
essa ocorrência seja praticamente impossível. (Políticas adequadas de gerenciamento de
falhas podem ocorrer a fim, de impedir o vôo de um avião sobre o sítio da fábrica, ou
construir um telhado que possa suportar a queda de um avião. Isto não é mera
especulação, é claro que ambas as políticas são consideradas como rotina nas estações
nucleares).
8.3. Níveis de Causa – “Modos de falha deverão ser identificados ao nível de causa em que
seja possível identificar apropriadamente uma política de gerenciamento de falha”. (SAE JÁ
1011, seção 5.3.3).
Foi constatado anteriormente neste guia, que modos de falha deveriam ser descritos com
detalhes suficientes, para que seja possível selecionar uma política de gerenciamento de
falha adequado, mas não com muitos detalhes, para se evitar grande perda de tempo, ao
ser feita a análise do processo.
O tamanho que um modo de falha é descrito, nos diferentes níveis pode ser ilustrado na
figura 4, com base na bomba cuja função e falhas funcionais foram descritas na figura 3.
Figura 4 lista alguns modos de falha que podem causar a falha funcional “incapaz de
transferir nenhuma quantidade de água”. Neste exemplo, estes modos de falha são
considerados em sete níveis de detalhe, começando com falha da bomba em toda sua
extensão.
O primeiro ponto a salientar deste exemplo é a conexão entre o nível de detalhe e o número
do modo de falha listado. O exemplo mostra que no próximo “treinamento” em um FMEA,
um maior número de modos pode ser listado. Por exemplo, há 3 modos de falha listados
para a bomba do nível 3, na figura 4, porém 20 no nível 6.

Outro ponto levantado da figura 4 é “causa raiz”. Isso é discutido a seguir.
8.3.1 Causa Raiz – O termo “causa raiz” é freqüentemente usado em conexão com a análise de
falhas. Implica que é possível se chegar ao último nível absoluto de causa, se um treino
somente for suficiente. De fato, isso não só é muito difícil de ser feito, mas é também
geralmente desnecessário.
Por exemplo, na figura 4 o modo de falha “pino que impele está solto” é listado no nível 3,
que por sua vez é ocasionado por “pino que impele está rachado”. Se fossemos para um
nível mais adiante, isso pode ter sido causado por “pino que impele mais apertado que o
necessário” (nível 5), que pode ter sido ocasionado por “erro de montagem” (nível 6). O
erro de montagem pode ter ocorrido porque o “técnico estava distraído” (nível 7). Ele pode
ter se distraído por que “seu filho estava doente” (nível 8). Este modo de falha aconteceu
porque “o filho ingeriu comida estragada no restaurante” (nível 9).
Claramente, este processo poderia se estender quase que para sempre – muito além do
ponto em que a organização responsável pela manutenção e operacionalidade do ativo
tem algum controle sobre os modos de falha. É por causa disso que SAE JÁ 1011 requer
um processo RCM para identificar modos de falha, a um nível de causa que permita ser
possível identificar uma política de gerenciamento de falha apropriada. Este nível varia
para cada modo de falha diferente. Alguns modos de falha podem ser identificados ao
nível 3, outros ao nível 5, e o restante aos outros níveis.

Figura 4 – Modos de Falha
Note que alguns modos de falha mostrados na figura 4 podem não ser considerados
“razoavelmente” em um contexto diferente daquele usado para desenvolver a figura 4.
Nesse caso, não haveria nenhuma razão para listá-los. Ao contrário, outros modos de falha
que não são mostrados na figura 4, mas que são considerados “razoavelmente” naquele
contexto, pode ser acrescido na lista. Note também que os modos de falha listados na figura
4 se aplicam somente a falha funcional, "incapaz de transferir qualquer água”. Figura 4 não
mostra modos de falha que poderiam causar outras falhas funcionais, tais como perda de
contenção ou perda de proteção.
8.4. Fontes de Informação sobre Modos de Falha - “Listas de modos de falha devem incluir
modos de falhas que tenham ocorrido antes, modos de falha que estão atualmente sendo
prevenidos nos programas de manutenção, e modos de falha que ainda não tenham
ocorrido, mas que são passíveis de ocorrer no contexto operacional”. (SAE JA1011, 5.3.4).
Modos de falha que tenham ocorrido antes nos mesmos ativos ou similares, são os mais
óbvios candidatos na inclusão da lista de modos de falha, a menos que algo tenha sido
mudado, de tal maneira que esse modo de falha não ocorra outra vez. Fontes de
informação sobre estes modos de falhas incluem pessoas que conhecem bem o ativo
(operadores, mantenedores, vendedores de equipamento, ou outros usuários do mesmo
equipamento), relatório de histórico técnico e banco de dados.

Modos de falha que são sujeitos a rotina de manutenção pró-ativa existente deveriam ser
também incorporados na lista de modos de falha. Uma forma de assegurar que nenhum
desses modos de falha tenham passado despercebidos é estudar os planos de
manutenções, já existentes, usados para ativos iguais ou muito parecidos a estes, e fazer a
pergunta, “Que modo de falha poderia ocorrer se essa tarefa não fosse executada ?”
Entretanto, esquemas existentes deveriam ser revisados somente como uma checagem
final, depois que toda análise RCM tenha sido completada, de forma a reduzir a
possibilidade de perpetuação do “status quo.”
Finalmente, a lista de modos de falha deveria incluir modos de falha que não tenham ainda
ocorrido, mas que são considerados como reais possibilidades no contexto ora considerado.
Identificar e decidir como lidar com modos de falha que ainda não aconteceram é essencial
do gerenciamento pró-ativo, de um modo geral, o risco de gerenciamento em particular. É
também um dos maiores desafios do prospecto RCM, porque pede um alto grau de
julgamento, aplicado por pessoas com conhecimento e habilidade.
8.5. Tipos de Modos de Falha – “Listas de modos de falha deveriam incluir qualquer evento ou
processo que seja passível de ocorrência de falha funcional, incluindo deterioração, defeitos
de esboço e erro humano, seja ele causado por operadores ou mantenedores (a menos que
o erro humano esteja sendo ativamente elaborado por processo analítico, fora do RCM)”.
(SAE JA1011, 5.3.5).
Para começar, a deterioração ocorre quando a capacidade de um ativo está acima do

desempenho desejado, mas cai abaixo do desempenho esperado, após o ativo ser
colocado em funcionamento. Isso cobre todas as formas do “usar e desgastar”, tais como:
fadiga, corrosão, abrasão, erosão, evaporação, degradação (especialmente de isolantes,
lubrificantes, etc.) Estes modos de falha deveriam, é claro, ser incluídos em uma lista de
modos de falha, onde quer que se considere serem “razoavelmente” possíveis, ao nível de
detalhe mais apropriado, como é discutido em 8.3.
Em alguns casos, o projeto de um ativo ou a configuração de um sistema poderia ser

considerado incapaz de satisfazer toda uma série de requisitos funcionais no contexto em
que operam. Se essas deficiências são conhecidas para afetar o equipamento existente, ou
no caso de um novo equipamento e se pensa que existem projetos e processos de gestão
de modificações que são incapazes de retificar estas deficiências, estes modos de falha
deveriam ser listados e uma política de gerenciamento de falhas adequada seria
identificada mais tarde na análise.
Muitas falhas funcionais ocorrem quando o estresse do ativo aumenta além da sua
habilidade em enfrentar tal estresse. Na prática, o aumento desses estresses é
freqüentemente atribuído a seres humanos. O estudo do assunto classifica tais erros
humanos em uma grande variedade de formas. Entretanto, no mundo dos ativos físicos,
estes erros são classificados nas seguintes categorias:
a. Operação incorreta. Geralmente ela assume duas formas. A primeira é

sustentada, quase sempre deliberadamente, acima da sua capacidade (por
exemplo, se a máquina opera a níveis de desempenho que se aproximam ou
excedem sua capacidade inicial, assim como um motor de automóvel que trabalha
a um excessivamente alto RPM, ocasionando falha prematura). A segunda é uma
súbita, geralmente não intencional, sobrecarga (por exemplo, se um ativo opera
de forma incorreta, tomando-se como exemplo um veículo que gira o motor ao
contrário ao mesmo tempo em que é acelerado para frente, ocasionando dano a
engrenagem).

b. Forma incorreta de montagem (por exemplo, se o mecânico esquece uma

ferramenta atrás da engrenagem, ou o eletricista conecta um disjuntor de forma
incorreta).
c. Dano externo (por exemplo, se a cobertura de uma bomba é esmagada por uma
empilhadeira).
Se essas considerações foram consideradas a fundo e são consideradas razoáveis de

ocorrer no contexto de operação (e se ainda não são tratados por um processo analítico
especifico), deveriam ser também incorporados na lista dos modos de falha, de forma que
políticas de gerenciamento de falhas apropriadas possam ser identificadas.
9. Efeitos de Falha – O processo RCM em conformidade com SAE JA1011, pergunta: O que
acontece quando a falha ocorre (efeito de falha)? Esta seção discute dois conceitos –
chaves concernentes a efeitos de falha que são listados na seção 5.4 do SAE JA 1011,
como segue:
a - Suposição básica
b - Introdução necessária
9.1. Suposição Básica – “Efeitos de falha descrevem o que aconteceria se não for executada
nenhuma tarefa específica para antecipar, prevenir ou detectar a falha” (SAE JA1011,
seção 5.4.1)
Uma declaração de efeito de falha descreve o que aconteceria se um modo de falha

ocorresse. Note que RCM faz uma distinção clara entre efeito de falha (o que ocorre) e
conseqüência de falha (como e quanto o modo de falha implica).
Como explicado na seção 10 deste Guia, declarações de efeitos de falha são usadas para
acessar as conseqüências de cada modo de falha. Eles também suprem informação básica
necessária para decidir que política de gerenciamento de falha precisa ser implementada
para evitar, eliminar ou minimizar estas conseqüências para satisfação dos proprietários/
usuários do ativo.
A principal opção de política de gerenciamento de falha inclui manutenção pró-ativa de

tarefas (condição ideal, esquema de restauração, esquema de rejeição) junto com
freqüências associadas. Se desejarmos identificar essas tarefas corretamente, é essencial
assumir que manutenção não pró-ativa está sendo levada a bom termo, quando identifica
modos de falha e efeitos associados. Em outras palavras, para se iniciar, verdadeiramente
do zero, é essencial assumir que o modo de falha causa de fato a falha funcional associada.
Modos de falha precisam ser descritos, e declarações de efeito de falha, precisam ser
escritos, de acordo.
9.2. Informação Necessária – “Efeitos de falha devem incluir toda informação necessária para
dar amparo à avaliação das consequências de falha", tais como:
a. Que evidência há (se houver alguma) que tenha ocorrido falha (no caso de
funções ocultas, o que aconteceria se ocorresse multiplica falha).
b. O que pode acontecer(se houver) morte ou ferimento em alguém ou houver efeito
adverso no meio ambiente.
c. O que pode acontecer (se houver) efeito adverso na produção ou nas operações.
d. Que dano físico (se houver) é causado pela falha.
e. “O que (se houver) deve ser feito para restaurar a função do sistema depois de
ocorrida à falha”. (SAE JA1011, seção 5.4.2)

9.2.1 Evidências que tenha ocorrido a falha – Uma declaração de efeito de falha deveria
descrever se há evidência de que o modo de falha que está sendo considerado tenha
ocorrido por si só. Se este for o caso, deveria descrever a maneira como a falha ocorreu.
Por exemplo, deveria mencionar se houve mudança notável no comportamento do
equipamento como resultado do modo de falha, (luzes de alerta, alarmes, mudança de
velocidade, ou níveis de barulho etc). Deveria descrever também se o modo de falha é
acompanhado (ou precedido) por efeitos físicos óbvios como, barulho alto, fogo, fumaça,
vapor, cheiros diferentes ou poças de água no chão.
Quando se lida com proteção, as descrições de efeito de falha deveriam descrever de

maneira breve, o que poderia acontecer se a função protegida falhasse no momento em
que encontra o dispositivo de proteção em estado de “falha”.
9.2.2 Ameaça à segurança ou ao meio ambiente – Se há possibilidade de uma pessoa se ferir

ou mesmo ser morta, devido a resultado direto de modo de falha ou se houver interferência
nos padrões ou regulamentação do meio ambiente, o efeito de falha deveria ser descrito
da maneira como aconteceu. Uma lista inclui:
a. Aumento do risco de fogo ou explosão.

b. Perigo de escapamento de gases químicos.
c. Eletrocussão.
d. Acidentes com veículos ou descarrilamentos.
e. Ingresso de sujeira em alimentos ou em produtos farmacêuticos.
f. Exposição a pontas cortantes ou maquinário em movimento.
Ao listar estes efeitos um cuidado deveria ser tomado para não dizer que o modo de falha
“tem conseqüências de segurança” ou “afeta o meio – ambiente”. Declare simplesmente o
que ocorreu e deixe a avaliação das conseqüências para o próximo estágio do processo
RCM.
9.2.3 Efeitos sobre Produção ou Operação – Descrições de efeito de falhas deveriam indicar
como a produção ou operações são afetadas (se for o caso) e por quanto tempo. Os
pontos a seguir deveriam ser considerados.
a. Downtime: Por quanto tempo o ativo deveria ficar inoperante devido a este modo
de falha, desde o momento que ocorre a falha até o momento em que retorna a
total operação. Para assegurar que o programa de gerenciamento de falha seja
“razoavelmente” conservador (mas não tanto conservador). Deveria supor que
aquele modo de falha ocorreu em uma situação do pior caso, por exemplo: no
chão da fábrica, tarde da noite, ou que equipamento móvel se encontre em lugar
remoto, longe do lugar que deveria estar.
b. Agilidade do operador: Se o equipamento precisa operar mais devagar devido a
modo de falha, e se for o caso, qual a velocidade.
c. Qualidade: Se o modo de falha afeta a qualidade na qual a função esta sendo
desempenhada, tal como exatidão ou precisão de guia ou sistemas de controle,
parâmetros de qualidade do produto, e até mesmo emissão de serviços ao cliente
(desempenho, no tempo prometido, etc). A declaração de efeito de falha deveria
também indicar se o modo de falha aumenta o índice de refugos ou resíduos,
ocasionar o fracasso da missão, incorrer em significantes penalidades financeiras
contratuais.
d. Outros sistemas: Se o equipamento ou processo precisarem parar, diminuir a
marcha, ou são afetados pelo modo de falha.

e. Custo operacional total: Se o modo de falha causar outros aumentos do custo

operacional tais como aumento no consumo de energia ou atrito excessivo no
processamento de materiais.
9.2.4 Danos secundários – Se o modo de falha em pauta causar estrago significante para outros
componentes do sistema, os efeitos desta avaria secundária deveriam ser também
registrados.
9.2.5 Ação corretiva requerida – A descrição dos efeitos de falha deveria incluir um breve relato
da ação requisitada, para corrigir o modo de falha após a ocorrência do mesmo.
10. Categorias de Conseqüências de Falhas
10.1 Categorias de Conseqüências – “As conseqüências de todos os modos de falha devem

ser formalmente categorizadas...” (SAE JA1011, seção 5.5.1).
Depois de cada modo de falha razoavelmente provável e seus efeitos foram identificados a
um nível apropriado de detalhe, o passo seguinte no processo RCM é acessar as
conseqüências de cada modo de falha. A primeira fonte de informação usada para acessar
conseqüência de falha é a descrição dos efeitos de falha.
Alguns modos de falha afetam a saída de material, qualidade do produto ou serviço ao

cliente. Outros ameaçam a segurança ou o meio-ambiente. Alguns aumentam o custo
operacional, por exemplo, o aumento no consumo de energia enquanto que uns poucos têm
impacto em quatro, cinco ou seis dessas áreas. Ainda outros podem aparentar ter nenhum
efeito se eles ocorrem por si próprios, mas podem, entretanto, expor a organização em risco
de muito mais sérios modos de falha.
Se nenhum desses modos de falha não são antecipados ou prevenidos, o tempo e esforço
necessários a serem gastos para corrigi-los também afetam a organização, porque repará-
los consome recursos que seriam mais bem aproveitados em outro lugar.
A natureza e severidade desses efeitos governam a maneira na qual cada modo de falha é
visto pela organização. O impacto preciso em cada caso - em outras palavras, a extensão
na qual cada modo de falha implica - depende do contexto operacional do ativo, os padrões
de desempenho aplicados a cada função e os efeitos físicos de cada modo de falha.
Esta combinação de contexto, padrões e efeitos significa que todo modo de falha tem um
conjunto específico de conseqüências a ele associadas. Se as conseqüências são muito
sérias, serão então feitos esforços consideráveis para prevenir modo de falha, ou pelo
menos antecipá-lo a tempo de reduzir ou eliminar as conseqüências. Por outro lado, se o
modo de falha só tem conseqüências menores, é possível tomar ação pró-ativa e o modo
de falha será simplesmente corrigido a cada vez que isso ocorrer.
Isso significa que as conseqüências dos modos de falha são mais importantes do que suas
características técnicas. Isso sugere também que toda idéia de gerenciamento de falha não
tem muito a ver com antecipação ou prevenção dos modos de falha em si mesmo, mas sim
para evitar ou reduzir suas conseqüências.
Esta seção traz à memória considerações sobre os critérios usados para avaliar as
conseqüências dos modos de falha e, portanto, decidir se é lucrativo fazer qualquer
gerenciamento de falha. Estas conseqüências estão divididas em quatro categorias de dois
estágios. O primeiro estágio separa as falhas ocultas das falhas evidentes.

10.1.1 Falhas Ocultas e Evidentes – “O processo de categorização de conseqüência deverá

separar os modos de falha ocultos dos modos de falha evidentes”. (SAE JA1011, seção
5.5.1.1).
Alguns modos de falha ocorrem de uma maneira que ninguém percebe que o item está em
estado de falha, a menos que, ou até que alguma outra falha (ou evento anormal) também
ocorra. Estas são conhecidas como falhas ocultas. Uma falha oculta é um modo de falha
cujos efeitos não se tornam aparentes para a equipe de operação em circunstâncias
normais, se o modo de falha ocorre por si só. Ao contrário, uma falha evidente é aquela
cujos efeitos se tornam aparentes para a equipe de operação sob circunstâncias normais,
se o modo de falha ocorre por si só.
A visão do RCM para avaliação das conseqüências de falha começa por separar as falhas
ocultas das falhas evidentes. As falhas ocultas podem ser responsáveis por metade dos
modos de falha que poderiam afetar modernos e complexos equipamentos, portanto,
devem ser manuseadas com cuidados especiais. Os parágrafos que se seguem explicam
a relação entre falhas ocultas e proteção, e introduz o conceito de “falha múltipla”.
Falhas Ocultas e Proteção: 6.2.2.8 deste guia menciona que a função de qualquer
proteção assegura que as conseqüências de falha da função que está protegida são muito
menos sérias do que aquelas funções sem proteção. Portanto qualquer função com
proteção é de fato parte de um sistema que tem pelo menos, dois componentes:
a. Dispositivo de Proteção
b. Função Protegida
A existência de tais sistemas cria dois conjuntos de possibilidades de falhas, dependendo

da proteção da falha, se ela é evidente ou não. As implicações de cada conjunto são
consideradas nos parágrafos seguintes, começando com os aparelhos cuja falha é
evidente.
10.1.1.1 Falhas Evidentes de Dispositivos de Proteção – Neste contexto, uma falha “evidente” de
função que protege, acontece onde os efeitos dos modos de falha que ocorrem por si
só, se tornam aparentes à equipe operacional, sob circunstâncias normais. A existência
de tais modos de falha cria, em qualquer época três cenários possíveis, como segue.
A primeira possibilidade é aquela em que, nem a função que protege nem a que é
protegida venha a falhar. Neste caso, todos os procedimentos são normais.
A segunda possibilidade é que a função protegida falhe antes da proteção. Neste caso,
a proteção leva adiante a função que lhe é inerente e, dependendo da natureza da
proteção as conseqüências de falha da função protegidas são reduzidas ou eliminadas.
A terceira possibilidade é que a função que protege falha antes da função protegida.
Porque essa falha é “evidente”, a perda da proteção se torna visível. Nesta situação, a
chance de que essa função protegida falhe enquanto que a função que protege se
encontra já em estado de falha, pode ser quase que eliminada desligando-se a função
protegida ou providenciando-se proteção alternativa até que a função que protege seja
restaurada, como ilustrada na figura 5. Isto quer dizer que as conseqüências de uma
falha visível da função que protege, geralmente caem nas categorias “operacionais”,
como será discutido em 10.1.2.

Figura 5 – Falha Evidente de uma Função que Protege
10.1.1.2 Funções Ocultas de Dispositivos de Proteção – Falhas ocultas podem ser identificadas
fazendo-se a seguinte pergunta: Alguns efeitos deste modo de falha se tornam
evidentes à equipe operacional se o modo de falha ocorrer por si só, sob circunstâncias
normais?
Se a resposta for não, o modo de falha está oculto, se a resposta for sim ele é visível.
Note que neste contexto, “por si só” significa que nada mais falhou. Note também que
nós supomos que neste ponto da análise, nenhuma tentativa está sendo feita para
checar se a função associada ainda está funcionando. Isso ocorre porque tais
checagens são uma maneira de manutenção do esquema e, todo o propósito da análise
é descobrir se tal manutenção é necessária.
Se tal modo de falha ocorrer, o fato de que a proteção é incapaz de preencher sua
função não irá se tornar evidente sob circunstâncias normais. A existência de tais modos
de falha cria quatro cenários possíveis em qualquer época, dois dos quais são também
aplicados a falhas de funções evidentes, da função que protege.
A primeira se aplica onde nenhuma função falha, nesse caso, assim como antes, tudo
se processa normalmente.
A segunda possibilidade é que a função protegida falhe, enquanto a proteção está ainda
em funcionamento. Nesse caso a proteção leva adiante sua responsabilidade funcional,
de tal forma que as conseqüências de falha da função protegida são outra vez reduzidas
ou juntamente eliminadas.
A terceira possibilidade é que a proteção falhe enquanto que a função protegida está
ainda em funcionamento. Neste caso, a perda da proteção não tem conseqüências
diretas. De fato, ninguém sabe ainda que a proteção está em estado de falha.
A quarta possibilidade, durante qualquer ciclo, é que a proteção falhe, então a função
protegida falha, ao mesmo tempo em que a proteção se encontra em estado de falha.
Essa situação é conhecida como falha múltipla. (Esta é uma possibilidade real,
simplesmente porque a falha da proteção não é evidente, assim, ninguém saberia da
necessidade de se tomar uma ação corretiva – ou alternativa - para se evitar falha
múltipla).

A seqüência de eventos que conduz à múltipla falha está resumida na figura 6.
Figura 6 – Falha oculta de uma função protegida.
10.1.2 Conseqüências de Segurança, Ambiental, Operacional e Não operacional – As

consequências do processo de categorização deverão distinguir claramente eventos
(modos de falha e múltiplas falhas) que têm conseqüência em segurança e/ ou no meio-
ambiente, daquelas que têm somente conseqüências econômicas (conseqüências
operacionais e não operacional). (SAE JÁ 1011, seção 5.5.1.2).
NOTA – Em toda esta seção, “falha” se refere a modo de falha e falha múltipla.
10.1.2.1 Conseqüências de Segurança – A falha tem conseqüências de segurança se houver

uma probabilidade intolerável de que ela pudesse matar ou ferir uma pessoa. A
diferença entre ema probabilidade “tolerável” e uma “intolerável” é discutida com mais
detalhes em 12.1.3 deste Guia.
10.1.2.2 Conseqüências Ambientais – Em outro nível, “segurança” se refere à segurança ou bem

estar da sociedade em geral. Tais falhas tendem a serem classificadas, como assuntos
“ambientais”. As expectativas da sociedade assumem a forma de padrões ambientais no
âmbito municipal, regional e nacional. Algumas organizações têm também seus próprios
ou talvez mais restritos padrões corporativos. Como resultado disso, a falha tem
conseqüências ambientais, se houver uma intolerável probabilidade de ocorrer quebra
do padrão ambiental ou regulamentação.
10.1.2.3 Conseqüências Operacionais – A função primária da maioria dos equipamentos no

comércio e na indústria é geralmente conectada à necessidade de se adquirir proventos
ou apoio a atividades remuneradas. Falhas que ofertam funções primárias desses ativos
afetam a capacidade de se captar proventos em benefício da organização. A magnitude
desses efeitos depende de quão necessariamente o equipamento é utilizado e da
disponibilidade de alternativas. Entretanto, na maioria dos casos, o custo desses
resultados são maiores – do que o custo do conserto das falhas, e esses custos
precisam ser levados em consideração, quando se estima o custo benefício de alguma
política de gerenciamento de falha. Em geral, as falhas afetam as operações de quatro
maneiras:
a. Afetam a saída do produto.

b. Afetam a qualidade do produto.

c. Afetam o serviço ao consumidor (o que pode ocasionar penalidade financeira).
d. Aumentam o custo da operação adicionado ao custo do reparo.
Em empresas fins lucrativos como na esfera militar, muitas falhas também afetam a
habilidade da organização em preencher sua função primária, algumas vezes com
resultados devastadores. Ao mesmo tempo em que pode ser difícil avaliar os resultados
ao se perder a batalha, ou mesmo a guerra, falhas que alteram a capacidade
operacional, têm ainda, implicações econômicas. Se elas ocorrem com freqüências
talvez seja necessário movimentar (digamos) 60 tanques de guerra, ao invés de 50, ou
seis aviões cargueiros, em lugar de cinco. Redundância, neste caso pode ser muito
dispendiosa.
Por esta razão, se uma falha evidente não apresenta perigo à segurança ou ao meio
ambiente o processo RCM focaliza isso mais adiante nas conseqüências de falha
operacional.
Porque estas conseqüências tendem a ter uma natureza econômica, são geralmente
avaliadas em termos econômicos. Entretanto, em casos extremos (tais como, perder a
guerra), o “custo” pode ser avaliado na base da quantidade. Na prática, o custo total que
afeta qualquer falha que tenha conseqüências operacionais, depende de dois fatores:
a. Qual o custo da falha, cada vez que ela ocorre, em termos do seu efeito na
capacidade operacional, adicionado ao custo do conserto da falha (e qualquer
outro prejuízo secundário).
b. Com que freqüência isso ocorre.
10.1.2.4 Conseqüências Não-Operacionais – As conseqüências de uma falha evidente que não

tenha efeito adverso na segurança, no meio ambiente ou capacidade operacional são
classificadas como não operacionais. As únicas consequências associadas a essas
falhas são o custo direto do conserto da falha e qualquer outra avaria secundária,
portanto essas conseqüências são também econômicas.
10.1.3 RCM – e Legislação/ Regulamentações de Segurança – Uma questão que surge com
freqüência concernente a relação RCM e tarefas específicas por autoridades reguladoras
(legislação ambiental é diretamente ligada a ela).
A maioria das regulamentações governamentais em segurança demanda que os usuários

sejam capazes de demonstrar que estão fazendo o que por prudente para assegurar que
seus ativos sejam seguros. Isso tem conduzido a um rápido aumento na ênfase da
concepção de se proceder a uma auditoria, que requer basicamente dos usuários do ativo
que produzam documentação que evidencia a existência de programas de manutenção,
racionais e defensáveis. Na vasta maioria dos casos RCM satisfaz completamente esse
tipo de requisito.
Entretanto, algumas regulamentações demandam que tarefas específicas deveriam ser

realizadas com tipos específicos de equipamento e em intervalos específicos. O processo
RCM sugere, com freqüência, uma tarefa diferente e/ou um intervalo diferente e, na
maioria destes casos a tarefa originária do RCM é uma política de gerenciamento de falha
superior a outras. Entretanto, em casos como esses, é prudente continuar com a tarefa
especificada pelos regulamentos e discutir a mudança sugerida com a autoridade
reguladora apropriada.

10.2. Estimativa das Conseqüências de falha – “A estimativa das conseqüências de falha deve
ser levada a bom termo, como se nenhuma tarefa especifica esteja sendo feita para
antecipar, prevenir ou detectar a falha” (SAE JÁ 10 11, seção).
Pelas razões explicadas em 9.1 é essencial assumir que nenhuma manutenção pró-ativa
esteja sendo desempenhada quando se está identificando conseqüências de falha.
11. Seleção de Política de Gerenciamento de Falha.
11.1 Relação entre Idade e Falha – “O processo de seleção de gerenciamento de falha deve
levar em consideração o fato de que a probabilidade condicional de alguns modos de falha
aumentará com a idade (ou exposição ao desgaste), e que a probabilidade condicional de
outros não mudará com a idade e, que a probabilidade condicional de outros vai reduzir
com a idade. (SAE JÁ 10 11, seção).
Um dos mais importantes fatores que afeta a seleção de qualquer política de gerenciamento
de falha é a relação entre idade (ou exposição ao estresse) e falha. Há seis conjuntos de
modelos em que a probabilidade condicional de falha varia à medida que o item envelhece
como é demonstrado na figura 7.
Figura 7 – Os seis modelos de falha

Modelos A e B mostram ambos, um ponto em que há um rápido crescimento da

probabilidade condicional de falha (algumas vezes chamado de “zona gasta”). Modelo C
mostra um aumento regular na probabilidade de falha, mas não mostra de forma distinta a
zona gasta. Modelo D mostra baixa probabilidade condicional de falha quando o item é novo
ou recém – saído da loja, então se verifica um aumento rápido para um constante ou muito
lento aumento do nível, enquanto que o modelo E, mostra uma constante probabilidade
condicional de falha em todas as idades (falhas imprevistas). Modelo F começa com alta
taxa de mortalidade infantil, caindo para queda constante ou bastante vagarosa da
probabilidade condicional de falha.
Em geral, modelos de falha relacionados com a idade se aplicam a itens muito simples ou a
itens complexos que sofrem com um modo de falha dominante. Na prática, eles são
comumente associados diretamente com o uso (muito freqüente onde o equipamento fica
em contato direto com o produto), fadiga, corrosão, oxidação e evaporação.
11.2 Tecnicamente Viável e Vale a Pena Ser Executado – “Todas as tarefas programadas
deverão ser tecnicamente viáveis e vale à pena serem feitas (JA10 11, seção 5.6.2)”
Qualquer tarefa programada vale a pena ser feita somente se ela reduz (evita, elimina ou
minimiza) as conseqüências do modo de falha, na medida em que justifica direta ou
indiretamente o custo de se fazer a tarefa. (Note que neste contexto os dispositivos
monitorados não removíveis constituem uma “tarefa programada”, não obstante, aquela que
está sendo feita automaticamente – continuamente ou em intervalos pré-determinados – por
um dispositivo monitorado). Portanto eles deveriam estar sujeitos aos mesmos critérios de
seleção, como é feito em qualquer outra tarefa programada. Note também que tais
dispositivos requerem, eles mesmos, projeto, instalação e manutenção, que deveria
também ser considerado, quando se estima seu custo beneficio.
Se uma tarefa programada apropriada não pode ser encontrada e, se as conseqüências do

modo de falha não são aceitas pelo proprietário ou usuário do ativo, então alguma outra
forma deve ser encontrada para lidar com as conseqüências de falha.
Claro que deve ser também tecnicamente possível para qualquer política de gerenciamento
de falha, influenciar as conseqüências de falha. Deva ou não, tal política ser tecnicamente
viável (ou aplicável) dependendo das características técnicas da política e do modo de falha
que está sendo considerado.
Os critérios técnicos, que governam tal viabilidade são discutidos com maiores detalhes da
seção 12 até 14 deste Guia.
11.3 Custo - Benefício - “Se duas ou mais políticas de gerenciamento de falha propostas são
tecnicamente viáveis e que valham a pena ser feitas (aplicável e efetiva) a política que for
mais lucrativa deverá ser selecionada.” (SAE JÁ 1011, seção 5.6.3).
Dados os números de opções de política de gerenciamento de falha (especialmente

manutenção prognosticada ou técnicas monitoradas/condicionadas) que são atualmente
avaliadas, existe uma tendência de se selecionar uma política, puramente com base na
sofisticação técnica, ao invés de ser embasada no custo-benefício. Quando mais de uma
opção de política de gerenciamento de falha é tecnicamente apropriada, o RCM sendo
corretamente aplicado, sempre procurará selecionar a política que lida satisfatoriamente
com as conseqüências do modo de falha em um padrão mais econômico, em vez de
selecionar sempre política com alto grau de sofisticação técnica.

11.4 Seleção de Política de Gerenciamento de Falha – “A seleção de políticas de

gerenciamento de falha deve ser conduzida como se uma tarefa específica não estivesse
sendo feita para antecipar, prevenir ou detectar a falha.” (SAE JA1011, seção 5.6.4)
Outra vez, por razões explanadas em 9.1 deste guia, é essencial supor que uma
manutenção não pró-ativa esteja sendo realizada quando se seleciona políticas de
gerenciamento de falhas.
12. Gerenciamento de Conseqüência de Falha.
12.1 Modos de Falha Evidente com Consequência em Segurança e Meio-Ambiente “No

caso de modo de falha evidente que tenha consequências em segurança e no meio-
ambiente, a tarefa deverá reduzir a probabilidade de modo de falha a um nível tolerável ao
proprietário ou usuário do ativo". (SAE JA1011, seção 5.7.11)
A maioria das pessoas gostaria de viver em um meio-ambiente em que não haja nenhuma
possibilidade de ocorrência de morte ou ferimentos, mas há de fato um elemento de risco
em tudo o que fazemos. Em outras palavras, “zero” é uma coisa impossível de se obter.
Então, o que e possível de se obter?
A resposta a essa questão, é que o problema do risco deve ser considerado em muito mais
detalhes.
A estimativa de risco consiste em três elementos. O primeiro questiona o que poderia

acontecer se o evento em consideração viesse a ocorrer. A segunda pergunta é, qual a
possibilidade de que o evento venha de fato a ocorrer. A combinação destes dois elementos
dá a medida do grau desse risco. A terceira pergunta é - com freqüência a mais debatida -
se esse risco é tolerável.
Por exemplo, considere o modo de falha que resulte em morte ou ferimento em dez
pessoas (o que poderia acontecer). A probabilidade de que este modo de falha venha a
ocorrer é 1 em 1.000 no período de um ano (essa é a probabilidade que isso ocorra).
Baseado nesses dados, o risco associado a este modo de falha é:
10 x (1 em 1000) = 1 morte ou 1 ferido no período de 100 anos.
Considere agora um segundo modo de falha que viesse a causar 1.000 (mortes ou pessoas
feridas), mas, que a probabilidade de que esse modo de falha ocorresse fosse à base de 1
por 100.000 no período de 1 ano. O risco associado a este modo de falha é:
1.000 x (1 em 100.000) = 1 morte ou 1 ferido no período de 100 anos.
Nestes exemplos, o risco é o mesmo, embora os números em que se baseiam sejam

totalmente diferentes. Note também que estes exemplos não indicam se o risco é tolerável
ou não, eles meramente o quantificam. Se o risco é tolerável ou não, é outra questão que
será focalizada mais adiante.
(Os termos “probabilidade” (1 em 10 chances de modo de falha em qualquer época) e “taxa

de falha” (uma vez em 10 períodos, na média, correspondeu a Período de Tempo Entre
Falhas (PTEF), de 10 períodos) são, freqüentemente, usados como se fossem alternados
quando aplicados a falhas aleatórias. No sentido exato da palavra, isso não é verdade.
Entretanto, se o PTEF for maior do que 4 períodos, a diferença é tão pequena que pode, na
maioria das vezes, ser ignorado).

Cada um dos três elementos de risco será considerado com mais detalhes nos próximos
parágrafos.
12.1.1 O Que Poderia Acontecer Se Ocorresse um Modo de Falha? – Exatamente o que

acontece se e quando cada modo de falha acorre, deveria ser reportado como parte da
lista de efeitos de falha. Em outras palavras, a declaração do efeito de falha, deveria ser
reportada caso qualquer ocorrência do modo de falha (digamos) tem uma chance em dez,
de matar uma pessoa, ou mesmo matar dez pessoas, ou fazer com que o operador perca
um membro do corpo. Para ser razoavelmente conservador, note que a declaração de
efeito de falha deveria refletir o “cenário do pior caso” (mas não o pior caso, porque seria
excessivamente conservador). Na dúvida, as pessoas que estão fazendo a análise
deveriam se perguntar, se o pior vai se tornar pior ainda, qual será o ponto de vista
defensável perante qualquer autoridade, sendo também, em última análise possível de ser
responsabilizado por eles e também por seus superiores.
12.1.2 Qual a Possibilidade da Ocorrência de um Modo de Falha? – Seção 8.1 deste guia
menciona que somente modos de falha “razoavelmente” passíveis de ocorrer, no contexto
em pauta, deveram ser relatados no FMEA (Tempo Médio entre Falhas). Como resultado,
se o FMEA foi preparado em bases realísticas, o mero fato de que o modo de falha foi
listado, sugere que há uma probabilidade limitada de que isso possa ocorrer. Seria ideal
que essa probabilidade fosse quantificada, ou como parte da declaração do efeito de falha,
ou em data base separada de forma que o risco possa também ser quantificado. (Note
que, na prática, falhas históricas pontuais são freqüentemente impossíveis de ser
avaliadas, especialmente no caso de equipamento novo, que incorpora montantes
substanciais de tecnologia de ponta. Nesses casos, o julgamento deve ser embasado em
estimativas inteligentes feitas pelas pessoas que conhecem com clareza o equipamento e
o contexto em que ele está sendo utilizado).
12.1.3 O Risco é Tolerável? - Como mencionado previamente, o risco é medido multiplicando-se

probabilidade por gravidade. Isso é geralmente expresso em bases anuais (embora possa
ser expresso em termos de eventos, considerando-se o número de ciclos ou horas em que
a operação ocorre, ou o que mais faça sentido, de acordo com o contexto em pauta).
Decidir o que é tolerável é totalmente outra questão.
O que se crê sobre o que é nível de tolerável risco de morte ou risco de ferimentos, varia
muito de pessoa para pessoa, de grupo para grupo. Muitos fatores influenciam estas
crenças. Os dois mais dominantes são o grau de controle que, qualquer indivíduo, pensa
que tem sobre a situação e o benefício que as pessoas acreditam que vai originar, quando
se expõem ao risco. Em contrapartida, isso influencia quanto à extensão que eles estarão
sujeitos a se expor sob tal risco. Então, essa visão precisa ser traduzida a um grau de risco
que possa ser tolerado por toda população (todos os operários do chão-de-fábrica, todos
os cidadãos de uma cidade ou mesmo a população inteira de um país).
Em outras palavras, se eu tolero a probabilidade de que 1 pessoa em 100.000 (10-5) seja

morta no trabalho no período de um ano, e eu tenho 1.000 colegas que têm a mesma
visão, então nós todos aceitamos o fato de que em média, uma pessoa da nossa fábrica
será morta no trabalho a cada 100 anos – e que essa pessoa possa ser eu e que isso
possa acontecer este ano.
Tenha em mente que qualquer quantificação do risco, neste padrão trata-se somente de
uma aproximação a grosso modo. Em outras palavras, uma probabilidade 10-5, não passa
de aproximação. Com isso em mente, o próximo passo é traduzir a probabilidade de que
um indivíduo e seus colegas de trabalho estejam preparados para a tolerância de que
qualquer um deles pode ser morto por qualquer eventualidade de trabalho, com uma

probabilidade de que isso ocorra em um só evento (modo de falha ou falha múltipla) e que
poderia matar alguém.
Por exemplo, seguindo a lógica do exemplo anterior, a probabilidade de que qualquer dos
meus 1000 colegas será morto em qualquer época (ano) é de 1 em 100 (supondo-se que
todos na fábrica corram, a grosso modo, o mesmo risco). Se as atividades
desempenhadas na fábrica reúnem (digamos) 10.000 eventos que poderiam matar
alguém, então a probabilidade média de que cada evento pudesse matar uma pessoa,
deve ser reduzida para 10-6 em cada ano. Isso quer dizer que a probabilidade de que um
evento que poderia matar 10 pessoas deve ser reduzido para 10-7, enquanto que a
probabilidade de um evento que tem 1 chance em 10 de matar uma pessoa, deve ser
reduzida para 10=5. (As técnicas usadas para movimentar para cima e para baixo a
graduação de probabilidade, neste padrão, são conhecidas como “probabilística” ou
avaliação quantitativa de risco).
Embora os assuntos discutidos acima, geralmente dominem decisões sobre tolerância de

risco, não se limitam somente a esses assuntos. Fatores adicionais que ajudam a decidir o
que é tolerável, inclusive valores industriais, quando se conhece sobre os efeitos reais e
conseqüências de cada modo de falha, valor estabelecido sobre vida humana, por grupos
culturais diferentes, a idade e o estado civil do indivíduo.
12.1.4 Quem Deveria Avaliar os Riscos? - A diversidade dos fatores discutidos anteriormente,
significa que neste ponto é, na maioria das vezes, impossível para cada pessoa – ou
mesmo organização – decidir o que é “tolerável” em benefício de todas as pessoas
expostas a um tipo de risco. Além disso, atualmente poucas organizações usam uma
metodologia formal para determinar o que constitui um risco tolerável. Na ausência de tal
metodologia, o tolerável pode ser determinado por um grupo representado por:
a. Pessoas que tenham uma clara compreensão do mecanismo da falha, dos efeitos
da falha (especialmente a natureza de qualquer perigo). A possibilidade de que o
modo de falha ocorra, e quais as medidas possíveis que podem ser tomadas para
antecipar ou prevenir a falha.
b. Pessoas que tenham uma visão legítima sobre a tolerância ou outra maneira de
encarar os riscos. Podem também serem incluídos representantes de:
1. Possíveis vítimas (operadores ou mantedores, no caso de riscos de

segurança diretos e a comunidade em geral, no caso de risco ao meio
ambiente).
2. Aqueles que têm quem lidar com as conseqüências, caso alguém se

machuque, ou seja morto, ou se um padrão ambiental é quebrado. (como
gerenciamento).
Entretanto, se uma organização já estabeleceu níveis de risco que são considerados

toleráveis por todas as partes envolvidas, então esses níveis podem ser usados quando
qualquer política de gerenciamento de falha vale a pena ser aplicada aos modos de falhas
com conseqüências de segurança ou ao meio ambiente.
12.1.5 Gerenciamento de Segurança de Falha – Se há um risco intolerável que um modo de falha

possa afetar a segurança ou meio-ambiente, o processo RCM estipula que precisamos
tentar reduzir a probabilidade do modo de falha ou suas conseqüências, ou ambos, a um
nível que o total de risco caia a um nível tolerável. Isso sugere que, para os modos de

falha que tenham conseqüências em segurança e no meio ambiente, a política de

gerenciamento de falha só terá valor ao ser aplicada se isso reduzir o risco do modo de
falha a um baixo nível de tolerância.
Note que quando se lida com modo de falha evidente, que tenha conseqüências de
seguranças e de meio-ambiente, RCM não considera o custo do modo de falha. Se o risco
é intolerável, deve então ser reduzido a um nível tolerável, ou introduzindo-se uma tarefa
(ou tarefas) pró-ativas adequadas, ou mudando-se o esboço ou operação do ativo, de tal
forma que esse risco seja reduzido a um nível tolerável.
12.2 Modos de Falha Ocultos com Consequências em Segurança e no Meio Ambiente –

“No caso de um modo de falha oculto, onde as falhas múltiplas associadas têm
consequências na segurança e no meio-ambiente, a tarefa deverá reduzir a probabilidade
de modo de falha oculta a uma extensão que reduza a probabilidade de falha múltipla
associada a um nível que seja tolerável pelo proprietário ou usuário do ativo". (SAE JA
1011, seção 5.7.1.2).
Como foi previamente explicada uma falha múltipla somente ocorre se a função protetora
está em estado de falha. Isso quer dizer que a probabilidade falha múltipla, em qualquer
período, é dada pela probabilidade de que a função protegida vai falhar ao mesmo tempo
em que a proteção está em um estado de falha, durante o mesmo período. Isso pode ser
calculado como segue na Equação 1:
Probabilidade de uma falha múltipla = Probabilidade de falha da função protegida X

Indisponibilidade média da proteção.
(Eq. 1)
Para as falhas múltiplas que têm conseqüências em segurança e no meio- ambiente, a

probabilidade tolerável (ou taxa de falha) deveria ser determinada como descrita 12.1.3 e
12.1.4. A probabilidade da falha (ou índice de falha) da função protegida é geralmente
levada em consideração. Portanto, se essas duas variáveis não conhecidas, a
indisponibilidade permitida da função protetora pode ser expressa, como segue na Equação
2:
Indisponibilidade Permitida = Probabilidade de Tolerância de uma falha múltipla

Probabilidade de falha da função protegida.
(Eq. 2)
Portanto, um elemento crucial do desempenho esperado de qualquer proteção, que venha

sofrer por modo de falha oculta, é a máxima indisponibilidade que pode ser permitida, se a
possibilidade da falha múltipla associada não exceda o nível tolerável. Essa
indisponibilidade é determinada nos três estágios a seguir:
a. Se ainda não foi determinado como descrito em 12.1.3 e 12.1.4 estabeleça qual a
probabilidade de que a organização esteja preparada para tolerar a falha múltipla.
b. Então determine a probabilidade de que a função protegida venha a falhar no
período sob consideração (Isso é conhecido algumas vezes como “taxa de
demanda”)
c. Finalmente, determine a indisponibilidade (também conhecida como “tempo morto
fracionado”) da proteção que resulta em probabilidade de falha múltipla tolerável.
Note que é geralmente possível variar ambos, a probabilidade de falha não antecipada da
função protetora e (especialmente) a indisponibilidade da função que protege, adotando-se
políticas de gerenciamento de falha adequadas. Como resultado, é também possível

reduzir a probabilidade de falha múltipla para quase todo nível desejado, dentro do bom
senso, adotando-se tais políticas (zero, claro, é em ideal impossível de ser alcançado).
12.3 Modos de Falha Evidente com Conseqüências Econômicas - No caso de um modo de

falha evidente que não tem conseqüências na segurança e no meio-ambiente, o custo
direto e indireto de se realizar a tarefa vai ser menor do que o custo do modo de falha,
direto e indireto, quando medido em períodos de tempo iguais. (SAE JA 1011, seção
5.7.1.3).
Seção 10.1.2.3 e 10.1.2.4 descreve os elementos-chave das conseqüências econômicas de

um modo de falha. Estas seções também mostram que conseqüências econômicas ajustam
conseqüências operacionais e não operacionais, e elas são julgadas na suposição de que
nenhuma tarefa programada esteja sendo realizada.
Se conseqüências de falha são econômicas, o custo total da organização durante um

período de tempo não é afetado somente pela magnitude das conseqüências que venham a
ocorrer, mas também o quão freqüente as conseqüências possam ocorrer. De igual modo,
o custo total para a organização, em levar adiante qualquer tarefa programada, é também
afetado pelo custo total de se realizar a tarefa em si, e quão freqüentemente ela é feita.
Nesse contexto, o custo total de se realizar a tarefa deveria incluir o custo dessa mesma
tarefa, mais o fato de que em tempo ideal, seja talvez necessário, fazer trabalho adicional
originário dessa tarefa. Por exemplo, talvez seja necessário checar o rolamento para
detectar ruído uma vez por semana e, trocar o rolamento uma vez a cada quatro ou cinco
anos, em média.
Conseqüentemente, para avaliar a viabilidade econômica de qualquer tarefa, é necessário

comparar o custo total do modo de falha num determinado período com o custo total da
política de gerenciamento de falha em um período igual (na maioria dos casos, estes custos
são comparados, reduzindo-os a bases anuais.)
O custo da realização da tarefa neste período é menor do que o total do custo do modo de
falha, nesse caso vale a pena realizar a tarefa. Caso contrário, não é apropriado e, outra
política de gerenciamento de falha precisa ser considerada.
Note que se há um grau razoável de certeza de que a probabilidade condicional do modo de

falha ocorrer, irá aumentar com a idade, então o período usado para comparação deveria
ser grande o suficiente para abranger os dois, quando novo, e o período de aumento da
probabilidade de falha, quando é avaliado, se a tarefa programada vale a pena ser feita.
Note também que se a vida útil remanescente do ativo, for significantemente menor do que
o intervalo entre as ocorrências do modo de falha (especialmente no caso de falhas
relacionadas com a idade), então pode ser interessante levar em consideração quando se
avalia a viabilidade econômica de uma tarefa programada.
12.4 Modos de Falha Ocultas com Conseqüências Econômicas – “No caso de um modo de
falha oculta, onde a falha múltipla associada não tem conseqüências na segurança ou no
meio-ambiente, o custo direto e indireto, da realização da tarefa deverá ser menor do que o
custo do modo de falha múltipla, acrescido do custo do conserto do modo de falha oculta,
quando medido, comparando-se períodos de tempo. (SAE JA 1110, seção 5.7.1.4)”.
Falhas múltiplas que têm somente conseqüências econômicas em termos de dinheiro

(operacional ou não operacional). Gerenciamento de falha também custa dinheiro. Como
resultado, é geralmente possível identificar uma política de gerenciamento de falha que
reduz o custo total do gerenciamento de falha oculta a um mínimo. Em casos como esses, o

primeiro passo é determinar qual a política de gerenciamento de falha que conduz a um

total mínimo de custo, em bases anuais, daí averiguar se esse (não obstante esteja
minimizado) risco financeiro possa ser tolerado pelos proprietários/ usuário do ativo.
13. Políticas de Gerenciamento de Falha – Tarefas Programadas.
13.1 Tarefas em Condições Ideais – “Qualquer tarefa em condições ideais (ou vaticinada, ou
baseada em condição, ou tarefa monitorada sob condição) que é selecionada, vai satisfazer
os seguintes critérios adicionais”:
a. Deverá haver uma falha em potencial, claramente definida.

b. Deverá haver um intervalo P-F identificável (ou período de aumento da falha).
c. O intervalo da tarefa deverá ser menor do que intervalo P-F o mais curto possível.
d. Deverá ser fisicamente possível fazer a tarefa a intervalos menores do que o
intervalo P-F.
e. O tempo mais curto entre a descoberta de falha em potencial e a ocorrência de
falha funcional (o intervalo P-F menos o intervalo da tarefa), deverão ser longos o
suficiente para ação pré-determinada a ser tomada a fim de evitar, eliminar ou
minimizar as conseqüências do modo de falha. (SAE JA 1011, seção 5.7.2).
13.1.1 Falha em Potencial e Curva P-F - A maioria dos modos de falha não ocorre
instantaneamente. Em tais casos, é possível, com freqüência, detectar que os itens sob
consideração estão no estágio final de deterioração antes que eles atinjam o estado de
falha. Essa evidência de falha iminente é conhecida como “falha em potencial”, que é
definida como “condição identificável que mostra que a falha funcional, ou está para
ocorrer, ou está já no processo de ocorrência”. Se essa condição pode ser detectada, é
possível agir para prevenir a falha total do item e/ ou evitar modo de falha.
A figura 8 ilustra o que acontece no estágio final do processo de falha. É chamado de

curva P-F, porque mostra como a falha é iniciada, se deteriora ao ponto no qual é possível
ser detectada (“P”) e então, se não for detectada e corrigida, o processo de deterioração
continua – geralmente, a um índice de aceleração – até que ele alcance o ponto de falha
funcional (“F”).
Figura 8 -
Se uma falha em potencial é detectada entre o ponto P e o ponto F na figura 8, esse é o

ponto no qual pode ser possível tomar ação para prevenir falha funcional e/ou evitar suas

conseqüências. (Se for possível ou não tomar ação significativa, vai depender da rapidez
com que a falha ocorre como será discutido mais adiante). Tarefas elaboradas para
detectar falhas em potencial são conhecidas como tarefas em condições ideais.
Tarefas em condições ideais são denominadas assim porque os itens inspecionados são
colocados em operação em condições tais que permitam que ele continue a satisfazer
padrões de desempenho específico – em outras palavras, na condição de que o modo de
falha, ora considerado, não venha a ocorrer antes da próxima checagem. Isso é também
conhecido com manutenção previsível (porque estamos antecipando se – e possivelmente
quando – o item irá falhar, baseado no comportamento ora apresentado) ou na
manutenção baseada em condição (porque a necessidade de correção ou conseqüência
em que a ação é evitada é baseada em julgamento da condição em que o item se
encontra).
13.1.2 Intervalo P-F – Em adição à falha em potencial é também necessário considerar que o
montante do tempo (ou o número dos ciclos em estresse), decorrente entre o ponto em
que uma falha em potencial ocorre – em outras palavras, o ponto em que se torna
identificável e o ponto onde se deteriora em falha funcional. Como mostrado na figura 9,
esse intervalo é conhecido como intervalo P- F.
Figura 9 -
O intervalo P-F indica a freqüência com que a tarefa deve ser feita. Para se detectar a
falha em potencial antes que se torne falha funcional, o intervalo entre as checagens deve
ser menor do que o intervalo P-F. E também essencial que a condição de falha em
potencial seja suficientemente clara, para se ter certeza de que a pessoa treinada para
desempenhar a checagem irá detectar a falha em potencial, se e quando ela ocorrer (ou
que pelo menos, a possibilidade de falha em potencial não seja detectada, ou que seja
suficientemente pequena, a fim de reduzir a probabilidade de um não antecipado modo de
falha a um nível que seja tolerável ao proprietário ou ao usuário do ativo).
O intervalo P-F é também conhecido como período preventivo, o tempo que conduz à falha
funcional ou período do aumento da falha. Isso pode ser medido em qualquer unidade, que
forneça uma indicação da exposição do estresse (tempo gasto, unidade de saída de
material, ciclos etc.) Para modos de falha diferentes, isso varia em frações, de um
segundo, para várias décadas.
Note que se uma tarefa em condições ideais é feita em intervalos que são mais longos do
que o intervalo P-F, há uma chance de que a falha em potencial seja toda ela perdida. Por

outro lado, se a tarefa for feita a uma fração muito pequena da do intervalo P-F, recursos
serão desperdiçados no processo de inspeção.
Na prática os intervalos de tarefa deveriam ser sempre selecionados, quando mais curtos
do que os muitíssimo curtos intervalos P-F. Na maioria dos casos, é suficiente selecionar
um intervalo de tarefa igual à metade desse intervalo P-F. Entretanto, é algumas vezes
apropriado selecionar intervalos de tarefas que são outras frações de intervalo P-F. Isso
talvez seja controlado pelo intervalo total P-F, requerido (conforme discutido a seguir), ou
talvez seja porque o usuário do ativo tem informação histórica relevante que diz que uma
fração diferente é apropriada.
13.1.3 Intervalo Total P-F – O intervalo total P-F é o intervalo mínimo para o espaço entre a
descoberta de uma falha em potencial e a ocorrência de falha funcional. Isso é ilustrado
na figura 10, que mostra o processo de falha com um intervalo de nove meses. A figura
mostra que, se o item é checado mensalmente, o intervalo total P-F é de 8 meses. Por
outro lado, se ele é chocado a intervalos de seis meses, o intervalo total P-F seria de 3
meses. Então, no primeiro caso o total mínimo de tempo disponível para se fazer alguma
coisa sobre a falha em potencial é cinco meses maior do que no segundo caso, mas a
tarefa em condições ideais deve ser feita com uma freqüência seis vezes maior.
Figura 10 -
O Intervalo total P-F controla todo período disponível para que seja tomada qualquer ação
necessária a fim de reduzir ou eliminar as conseqüências dos modos de falha. Para uma
tarefa com condições ideais, que seja tecnicamente viável, o intervalo total P-F deve ser
maior do que o período requerido, para se evitar ou reduzir as conseqüências dos modos
de falha. Se o intervalo total P-F é muito curto para se tomar ação consciente, então a
tarefa em condições ideais, não é tecnicamente viável. Na prática, o período requerido é
largamente variável. Em alguns casos, pode ser uma questão de horas (digamos, o final
de um ciclo em operação ou até o fim do turno), ou até alguns minutos (para desligar a

máquina ou evacuar o prédio). Em outros casos, podem ser semanas ou até meses
(digamos, até um desligamento maior). Em geral, intervalos P-F maiores são preferidos por
duas razões:
a. É possível fazer o que for necessário para evitar conseqüências de modo de falha
(inclusive planejar ação corretiva) em um mais considerado e portanto, mais
controlado padrão.
b. Algumas condições ideais são requeridas.
Por essa razão, muito esforço está sendo dispendido para encontrar técnicas de falhas em
condições e em condições ideais que dêem o mais longo intervalo P-F. possível.
Entretanto, é possível se fazer em alguns casos, bem pequenos intervalos P-F.
13.1.4 Relação Entre Intervalo P-F e Idade.
13.1.4.1 Falhas Aleatórias e Intervalo P-F – Quando se aplicam esses princípios pela primeira
vez, as pessoas frequentemente, têm dificuldade em distinguir entre a “vida” de um
componente e o intervalo P-F. Isso os leva, a se basearem em tarefas contínuas nas
condições ideais sobre a “vida” real ou imaginária do item. Se ela, realmente existe,
essa vida é geralmente muitas vezes maior do que o intervalo P-F, dessa forma a tarefa
produz pouco ou nada. Na realidade, nós mensuramos a vida de um componente,
antecipadamente, do momento em que o item entra em operação. O intervalo P-F é
medido com base na falha funcional, então, os dois conceitos, são com freqüência, não
totalmente relacionados. A diferença é importante porque os modos de falha que não
são relacionados à idade (em outras palavras, às falhas aleatórias) podem ser
precedidas por alarme assim como as outras não o são.
Por exemplo, a Figura 11 retrata um componente que se conforma a um padrão de falha

aleatória (padrão E). Um dos componentes falhou após cinco anos, um segundo após
seis meses e um terceiro após dois anos. Em cada, caso, a falha funcional foi precedida
por uma falha potencial com um intervalo P-F de quatro meses.
Figuras 11 – Falhas Aleatórias Intervalo P-F.
A Figura 11 mostra que para se detectar a falha em potencial precisamos proceder a

uma tarefa de inspeção a cada dois meses. Porque o modo de falha ocorre em bases
aleatórias, nós não sabemos quando a próxima vai acontecer então o ciclo de inspeções
deve começar tão logo o item é colocado em operação. Em outras palavras, o tempo de
inspeção não tem nada a ver com a idade ou vida do componente.

Entretanto, isso não quer dizer que tarefas em condições ideais se apliquem somente a
itens que falham em bases aleatórias. Elas também podem ser aplicadas aos itens que
sofrem modos de falha relacionados à idade, como discutido abaixo.
13.1.4.2 Intervalos P-F e Modos de Falha Relacionados à Idade - Se um item se deteriora em um

padrão mais ou menos linear, durante toda sua vida, isso indica que os estágios finas de
deterioração serão também mais ou menos lineares. Isso é verdadeiro com modos de
falha relacionados com a idade.
Por exemplo, considere o uso de um pneu. A superfície de um pneu é gasta num padrão
mais ou menos linear, até que a lona se desgaste ao mínimo permitido. Se esse mínimo
é (digamos) de 2 mm, é possível especificar um desgaste maior do que 2 mm, que
permite detectar adequadamente uma falha funcional iminente. Este claro é um nível de
falha em potencial.
Se a falha em potencial é determinada (digamos) 3mm, então o intervalo P-F é a

distância que se esperaria que o pneu percorresse gastando a lona de 3 mm para 2 mm,
como ilustrado na figura 12.
Figura 12 – Curva Linear P-F.
A figura 12 sugere também que se o pneu começa a rodar com a lona (digamos) com 12
mm, poderia se prever que o intervalo P-F baseado na distância total geralmente
coberta antes que o pneu tenha que ser recauchutado. Por exemplo, se o pneu dura
pelo menos 50.000 km antes que precise ser recauchutado, é razoável se concluir que a
lona se desgasta a razão de 1 mm para cada 5.000 km de uso. Isso monta ao intervalo
P-F de 5.000 km. A tarefa em condições ideais associada poderia ser comunicada ao
motorista: “Cheque a lona a cada 2.500 km rodado e informe sobre aqueles pneus, cuja
espessura da lona é menor do que 3 mm”.
Essa tarefa não somente irá assegurar que o desgaste seja detectado antes que ele
exceda o limite permitido, mas também dará também tempo suficiente – 2.500 km nesse
caso – para que operador do veículo planeje a remoção do pneu antes que ele atinja o
limite permitido.
Em geral, a deterioração entre “P” e “F”, é encontrada somente onde os mecanismos da

falha são intrinsecamente relacionados à idade.
13.1.5 Consistências do Intervalo P-F – As curvas P-F ilustradas até o momento, nesta seção do
guia, indica que o intervalo P-F para qualquer modo de falha é constante. De fato, não é

este o caso – alguns realmente variam numa grande classificação de valores, como
mostrados na figura 13. Nestes casos um intervalo de tarefa deve ser selecionado, menor
do que os menores intervalos P-F. Isso assegura um grau razoável de segurança ao se
detectar uma falha em potencial antes que ela se torne falha funcional. Se o intervalo total
associado com este intervalo mínimo é extenso o suficiente para se tomar ação ao lidar
com conseqüências de modo de falha, a, tarefa em condição ideal é tecnicamente viável.
Por outro lado, se o intervalo P-F é muito consistente, então não é possível estabelecer um
intervalo tarefa significativo, e a tarefa deveria ser abandonada em benefício de alguma
outra forma de se lidar com o modo de falha.
Figura 13 - Intervalo P-F inconsistentes.
13.1.6 Categorias de Técnicas em condições Ideais - As quatro principais categorias de

técnicas em condições ideais são as seguintes:
a. Técnicas baseadas na variação da qualidade do produto. Em muitos casos, a

ocorrência de risco de um defeito encontrado num artigo produzido por uma
máquina, está relacionada diretamente a um modo de falha da própria máquina.
Muitos desses defeitos aparecem gradualmente, e, portanto ocasionam no
momento certo evidências de falha em potencial.
b. Técnicas, que monitoram efeitos primários. Efeitos primários (velocidade, taxa de
fluidez, pressão, temperatura, força, corrente elétrica, etc.) São outras fontes de
informação sobre as condições do equipamento. Os efeitos podem ser
monitorados por uma pessoa usando um manômetro, por computador como parte
do processo do sistema de controle, ou por prancheta.
c. Técnicas baseadas nos sentidos humanos (visão, audição, tato e olfato).
d. Técnicas que monitoram as condições. Estas são técnicas para detectar falhas em
potencial que envolve o uso de equipamento especializado (que é algumas vezes
embutido no ativo que está sendo monitorado). Estas técnicas são conhecidas
como condições de monitoramento para distinguí-las de outros tipos de
manutenção em condições ideais.
Muitos modos de falha são precedidos por mais de uma – com freqüência, várias – falha
em potencial diferente, então, mais de uma categoria de tarefa em condições ideais, pode
ser apropriada. Cada uma delas terá um intervalo P-F diferente, e cada uma vai requerer
diferentes tipos e níveis de habilidade. Isso significa que nenhuma categoria de tarefas

será sempre mais efetiva e mais cara. Portanto, para evitar divergências desnecessárias
na seleção da tarefa, é essencial que:
a. Se considere todos os fenômenos razoavelmente detectados, que precedem

cada modo de falha, e toda uma gama de tarefas em condições ideais que
poderia ser usada para detectar esses sinais de perigo.
b. Aplicar rigorosamente os critérios de seleção de tarefa RCM para determinar
quais tarefas (caso haja alguma) que melhor se adequam ao custo/eficácia
para antecipar modo de falha ora em consideração.
Note que qualquer dispositivo não removível desenhado para se certificar se um modo de
falha está em processo de ocorrência ou pronto para ocorrer, satisfaria os mesmo critérios
para viabilidade técnica e que valha a pena ser feita, assim como qualquer manutenção
em condições ideais. Note também que quando tais dispositivos são agregados a um
sistema, constituem-se em uma função adicional ou a funções com modos de falha
adicionais e deveriam ser analisadas adequadamente.
13.2 Restauração Programada e Programa Para Descartar Tarefas – “Qualquer tarefa

selecionada para ser descartada deverá satisfazer os seguintes critérios adicionais”.
a. Deve haver uma idade claramente definida (preferivelmente uma que possa
ser demonstrada) na qual há um aumento da probabilidade condicional do
modo de falha, ora considerado.
b. Uma proporção suficientemente grande de ocorrências desse modo de falha
deve ocorrer após essa idade a fim de reduzir a probabilidade de falha
prematura a um nível que seja tolerável ao proprietário e ao usuário do ativo
(SAE JA 1011, seção 5.7.3).
Qualquer tarefa de restauração programada que é selecionada deve satisfazer os seguintes

critérios:
a. Deve haver idade claramente definida (preferivelmente uma que possa ser
demonstrada) na qual há um aumento da probabilidade condicional do modo
de falha, ora considerado.
b. Uma proporção suficientemente grande de ocorrências desse modo de falha
deve ocorrer após essa idade, a fim de reduzir a probabilidade de falha
prematura a um nível que seja tolerável ao proprietário e ao usuário do ativo
c. A tarefa deve restaurar a resistência de haver falha do (condição) componente
a um nível que seja tolerável ao proprietário e ao usuário do ativo (SAE JÁ
1011, seção 5.7.4).
Tarefas de restauração programada e descarte programado têm um número de

características semelhantes, portanto essa parte do guia considera primeiro suas
características em comum depois irá revisar suas diferenças.
Restauração programada envolve tomar ação periódica para restaurar a capacidade de um

item na ocasião, ou antes, de um intervalo especifico, (limite de idade) independente de
suas condições, a um nível que supre uma probabilidade tolerável de sobrevivência, até o
término de outro intervalo específico (que não precisa ser o mesmo que o intervalo inicial).
Essa ação geralmente envolve uma re-manufaturação de um único componente ou
inspeção de todo o aparelhamento.
Descarte programado significa descartar um item ou componente na ocasião, ou antes, de

um limite de idade específico, independente da sua condição. Isso é feito com a

compreensão de que a troca de um componente velho por um novo vai restaurar a

resistência original contra a falha.
Se o modo de falha em consideração se adequa ao padrão A ou B, é possível identificar a

idade em que o desgaste começa. A tarefa de restauração programada e a tarefa de
descarte programado devem ser feitas a intervalos menores do que essa idade. Em outras
palavras, a freqüência de uma tarefa de restauração programada ou descartada é
controlada pela idade em que o item ou componente mostra um aumento rápido na
probabilidade condicional de falha.
No caso do Padrão C, são requeridas técnicas analíticas mais complexas. Essas técnicas
estão além do escopo deste guia. Note que dois tipos do limite-vida se aplicam a tarefas de
restauração programada e descarte programado. Esses são limites vida-segurança e vida-
economia.
13.2.1 Limites Vida - Segurança – Limites vida-segurança se aplicam somente a modos de falha
que têm segurança ou conseqüências no meio-ambiente, de forma que tarefas associadas
devem reduzir a probabilidade de que um modo de falha ocorra antes da vida-limite, um
nível tolerável. (Um método para decidir o que é tolerável foi discutido em 12.1.3 deste
guia. Na prática probabilidades tão baixas como 10-6 e algumas vezes até 10-9 são, com
freqüências usadas neste contexto). Este requisito significa que limite vida-segurança não
pode ser aplicado a qualquer modo de falha que tenha uma probabilidade significativa de
ocorrência quando o item entra em operação.
O ideal seria de que limites de vida-segurança deveriam ser determinados antes que um
novo item seja colocado em operação. Isso deveria ser estabelecido ao se testar uma
amostra de itens estatisticamente adequados procedendo-se operação simulada em
ambiente próprio para isso, a fim de determinar que “vida” foi realmente realizada. Algumas
indústrias aplicam uma fração conservadora dessa vida como limite de vida-segurança
(tipicamente uma terceira ou uma quarta), conforme ilustrado na figura 14.
Figura 14 - Limites Vida – Segurança
13.2.2 Limites Vida-Economia – Algumas vezes experiência operacional sugere que a

restauração programada ou descarte programado ou descarte programado de um item é
desejável em termos econômicos. Isso é conhecido como limite de vida-economia. É
baseado na relação, confiabilidade-idade real do item, ao invés de uma fração da idade na
qual há um aumento da probabilidade condicional da falha. Uma suficientemente grande
maioria dos itens deve sobreviver ao limite vida-economia, para que se justifique a tarefa
em termos econômicos.

13.3 Tarefas Para Descoberta de Falhas – Qualquer tarefa desenhada para se descobrir falhas
deve satisfazer os seguintes critérios adicionais (tarefa para descobrir falhas não se aplica a
modo de falha evidente):
a. A base na qual o intervalo de falha é selecionado deve levar em consideração

a necessidade de reduzir a probabilidade de falha múltipla do sistema de
proteção associada, a um nível que seja tolerável ao proprietário ou usuário do
ativo.
b. A tarefa deve certificar que todos os componentes cobertos pela descrição do
modo de falha são funcionais.
c. Tarefas para descobrir falha e processo de seleção de intervalo associado
deveriam levar em consideração qualquer probabilidade de que a própria
tarefa pode deixar a função oculta em estado de falha.
d. Deverá ser fisicamente possível realizar a tarefa em intervalos específicos
(SAE JA 1011, seção 5.7.5).
13.3.1 Falhas Múltiplas e Descobertas de Falhas – Como mencionado em 10.1.1.2, a falha

múltipla ocorre se a função protegida falha, enquanto a proteção está em estado de falha.
Esse fenômeno foi ilustrado na Figura 5. A equação 1, repetida abaixo como equação 3,
mostra como a probabilidade de uma falha múltipla pode ser calculada.
Probabilidade de uma Falha Múltipla = Probabilidade de uma função protegida X

Indisponibilidade Média do dispositivo de proteção.
(Eq. 3)
Isso levou a conclusão de que a probabilidade de falha múltipla pode ser reduzida,
reduzindo-se a indisponibilidade da proteção em outras palavras, aumentando-se a
disponibilidade.
A melhor maneira de se fazer isso é evitar que a função que protege entre em estado de
falha, aplicando-se algum tipo de manutenção pró-ativa. Entretanto, poucas tarefas
satisfazem os critérios de viabilidade técnica, quando aplicados em falhas ocultas.
Todavia, embora a manutenção pró-ativa seja com freqüência não apropriada, é ainda
essencial que se faça alguma coisa para reduzir a probabilidade de falha múltipla ao nível
requerido. Isso pode ser feito checando-se periodicamente se a falha oculta ocorreu. Tais
checagens são conhecidas como tarefas para se descobrir falhas.
13.3.2 Aspectos Técnicos de Descoberta de Falha – O objetivo da descoberta de falhas é para

averiguar se um modo de falha oculta ou combinação de modos de falha ocultas
apresentaram uma função protegida incapaz de fornecer a proteção requerida, caso seja
necessário. (É por causa disso que as tarefas para descobrir falhas são também
conhecidas como checagens funcionais). Os próximos parágrafos consideram alguns
assuntos-chave nessa área.
13.3.2.1 Checagem da Função Que Protege Como Um Todo – A tarefa de descoberta de falha
deve assegurar que todos os modos de falha da falha oculta sejam detectados para os
quais foram direcionados. Isso é especialmente verdadeiro quando se trata de
dispositivos complexos, tais como sensores, circuitos elétricos e acionadores. Seria
ideal que isso fosse feito simulando-se as condições que o sensor pode detectar e
checando se o acionador responde corretamente ao teste. O intervalo para descoberta
de falha deveria ser estabelecido de acordo.

13.3.2.2 Não Perturbe – Ao se desmontar alguma coisa cria-se a possibilidade de que ao se

remontar o item, ele será feito incorretamente. Se isso acontece a um dispositivo que
protege que venha a sofrer devido às falhas ocultas, o fato de que os modos de falha
estão ocultos significa que ninguém vai saber se ele foi deixado em estado de falha até
a próxima checagem (ou até que seja necessário). Por essa razão, procure sempre
formas de checagem das funções dos dispositivos que protegem sem desconectá-los ou
até mesmo interrompê-los.
Dito isso, alguns dispositivos devem ser simplesmente desmontados ou removidos para
checagem caso estejam operando apropriadamente. Nesses casos, devem ser tomados
cuidados especiais para realizar a tarefa, de tal maneira que os dispositivos continuarão
ainda a operar quando voltarem a funcionar.
13.3.2.3 Deve ser Fisicamente Possível Checar a Função – Num pequeno número de casos,
mas significante, é impossível se levar adiante qualquer tarefa adianta qualquer tarefa
para detectar descoberta de falha. São eles:
a. Quando for impossível obter acesso ao dispositivo que protege para

checar sua função (Isso é quase sempre resultado de descuido), e
b. Quando a função do dispositivo não pode ser checada sem que seja
destruída. (Como é o caso de dispositivos como o fusível, discos
rompidos). Na maioria desses casos, outras tecnologias são disponíveis
(como dispositivo automático para interromper a corrente elétrica no lugar
do fusível). Entretanto, em um ou dois casos as únicas opções são
encontrar outra maneira de gerenciar o risco associado com proteção
ainda não testada, até que alguma coisa melhor apareça ou abandonar os
processos em pauta.
13.3.2.4 Minimizar o risco Durante a Realização da Tarefa – Deveria ser possível levar adiante a
tarefa para descobrir falhas sem o aumento significativo do risco de falha múltipla. Se
um dispositivo que protege tem que ser inabilitado para que a tarefa de descoberta de
falha seja levada adiante ou se tal dispositivo é checado e encontrado em estado de
falha, então a proteção alternativa deveria ser providenciada ou a função protegida deve
ser fechada até que a proteção original seja restaurada.
13.3.2.5 A Freqüência Deve Ser Prática – A tarefa de se descobrir falhas tem que ser prática nos
intervalos requeridos. Isso é discutido em 13.3.3. Entretanto, antes que possamos
decidir se um intervalo requerido é prático, precisamos determinar qual realmente é o
intervalo “requerido”.
13.3.3 Intervalos de Tarefa Para Descobrir Falhas.
13.3.3.1 Intervalos Para Descobrir Falhas, Disponibilidade e confiabilidade – Não uma, mas duas
variantes – disponibilidade e confiabilidade – são usadas para determinar intervalos a
fim de descobrir falhas. Pode ser determinado há uma correlação linear entre a
indisponibilidade, intervalo para se descobrir falha e confiabilidade da função que
protege, como dada pelo seu MTBF (Intervalo entre falhas), como segue na Equação 4:
Indisponibilidade = 0,5 X Intervalo para descobrir falha

MTBF da função que protege
(Eq. 4)
Isso também pode mostrar que essa relação linear é válida para todas as
indisponibilidades menores do que 5%, considerando-se que a função que protege se
amolda a uma distribuição de sobrevivência exponencial. (1)

(1) Ver Cox e Tait ou Andrens e Moss.
13.3.3.2 Excluindo Tempo de Tarefa e Tempo de Reparo – A “Indisponibilidade” da função que

protege na Equação 4 não inclui nenhuma indisponibilidade ocorrida enquanto a tarefa
de descobrir falhas esteja sendo realizada, nem encrue nenhuma indisponibilidade
causada pela necessidade de se restaurar a função se ela estiver a ponto de falhar. Isso
acontece por duas razões:
a. A indisponibilidade requerida para levar adiante a tarefa de descobrir falhas e executar

qualquer reparo, é provavelmente muito pequena relativamente à indisponibilidade entre
tarefas, a um alcance que vai ser geralmente pouco significante no terreno puramente
matemático.
b. Ambos, a tarefa de descobrir falhas e qualquer conserto que precise ser realizado,
deveriam ser levados adiante sob condições estritamente controladas. Essas condições
deveriam reduzir bastante a chance de uma falha múltipla, durante a intervenção, ou se
não eliminada completamente. Isso significa desligar o sistema protegido ou encontrar
proteção alternativa até que o sistema esteja completamente restabelecido. Se isso for
feito apropriadamente, resultante da intervenção (controlada) pode ser ignorada em
qualquer julgamento da probabilidade de uma falha múltipla.
No processo de decisão do RCM, o último ponto é coberto por critérios para julgar se a
tarefa de descoberta de falhas vale a pena ser feita. Se houver um aumento significante
na possibilidade de uma falha múltipla enquanto a tarefa está ocorrendo, a resposta à
pergunta: “A tarefa reduz a probabilidade de uma falha múltipla a um nível tolerável” a
resposta será “não”.
13.3.3.3 Calcular FFI usando-se somente Disponibilidade e Confiabilidade – Se nós usamos a

sigla “FFI” para descrever o intervalo para descobrir falha e “MTIVE” (Intervalo Entre
Falhas da Função que Protege) para descrever MTBF (Intervalo Entre Falhas) da função
que protege, Equação 4, pode ser reorganizada, para se obter Equação 5:
FFI = 2X Indisponibilidade X Mtive

(Eq. 5)
Isso significa que para se determinar intervalo de descoberta de falha para uma única
função que protege, é necessário averiguar o intervalo entre falhas e a disponibilidade
desejada da função (De onde é possível computar a indisponibilidade a ser usada na
fórmula". Para aqueles que se sentem desconfortáveis com fórmula matemáticas, a
Equação 5 pode ser usada para desenvolver uma tabela simples, como mostrada na
Figura 15;
Figura 15 -

13.3.3.4 Métodos Rigorosos Para Calcular FFI (tarefa) – Uma única fórmula para determinar
intervalos de descoberta de falha que incorpora todas as variáveis até agora
consideradas, pode ser desenvolvida combinando-se as Equações 1 e 5, como
explicado nos parágrafos que se seguem. Para ser feito, mais termos precisam ser
definidos como se vê abaixo:
a. A probabilidade de falha múltipla é de 1 em 1.000.000, em um ano, implica
em um intervalo entre falhas múltipla de 1.000.000 de anos. Se isso é
chamado de MMF, a probabilidade de falha múltipla que ocorrer em um ano
é 1/MMF (intervalo entre falhas múltiplas).
b. Se a demanda do índice da função protegida é (digamos) uma em 200
anos, isso corresponde a uma probabilidade de falha da função protegida
de 1 em 200, em um ano, ou intervalo entre falhas da função protegida de
200 anos. Se isso é chamado de MTED, a probabilidade de falha da função
protegida em um ano será de 1/MTED. Isso também é conhecido como
demanda de índice.
c. MTIVE é o intervalo entre falhas da função protegida e FFI é o intervalo
(tarefa) para descobrir falha.
d. UTIVE é a indisponibilidade permitida da função que protege.
Se as expressões anteriores são substituídas, a equação 5 se torna:
1/MMF = (1/MTED) x UTIVE (Eq. 6)
Isso pode ser reorganizado, como segue na Equação 7:
UTIVE = MTED
MMF (Eq.7)
Substituindo-se UTIVE da Equação 7 para a Equação 5 obtem-se a

Equação 8 :
FFI = 2 x MTIVE x MTED

MMF
(Eq.8)
Esta fórmula permite um intervalo para descobrir falha a ser determinada de uma só vez, para uma
única, independente função que protege.
13.3.3.4.1. Modos de Falha Múltipla de uma única função que protege – Ao longo dessa seção,
todas as possibilidades de falha que façam com que qualquer função que protege
venha a falhar foram agrupadas em um único modo de falha (“falha de Bomba em
estado de prontidão”). A grande maioria das funções que protegem pode ser tratada
dessa forma, porque todos os modos de falha que possam causar a falha de uma
função que protege são checados quando a função do dispositivo como um todo é
checado.
Entretanto, é algumas vezes apropriado levar adiante um FMEA detalhado da função

que protege, para se identificar modos de falha individuais, cada um dos quais,
podendo causar ao dispositivo que protege ou ao sistema, inabilidade de providenciar
a proteção requerida. Isso é feito não somente sob um, mas sob dois conjuntos de
circunstâncias:

a. Quando algum modo de falha é conhecido como susceptível à manutenção

em condições ideais ou para restauração programada ou tarefas
programadas para descarte; e ainda outros, sem previsão nem passíveis
de prevenção. Nesses casos, a condição ideal ou tarefa de restauração/
descarte programadas deveriam ser aplicados aos modos de falha que
qualificam, e descoberta de falhas aplicada aos modos de falha
remanescentes.
b. Quando o dispositivo que protege é novo e que as únicas informações de
falha que estão disponíveis (banco de dados, suprimentos de
componentes ou o que quer se seja) se aplicam a peças do dispositivo
mas não ao dispositivo como um todo.
Nessas circunstâncias, a Equação 8 deveria ser modificada para ajuste da combinação

dos modos de falha individuais que são objeto da tarefa para descobrir falha,
determinando-se um intervalo combinado entre falhas da função que protege, baseado
nos MTBFs de cada modo de falha.
13.3.3.4.2 Métodos Para Calcular Intervalos de Descoberta de Falhas Para Outros Tipos de
Função que Protegem - As técnicas para estabelecer intervalos de descoberta de falha
descritas anteriormente são aproximações baseadas em risco unicamente a funções
que protegem. O gerenciamento de múltiplas funções que protegem e o gerenciamento
de falhas múltiplas que tenham somente conseqüências econômicas está além do
escopo deste guia.
13.3.3.5 A Praticabilidade de Intervalos de Tarefa Para Descoberta de Falha – Os métodos

descritos até agora para calcular intervalos de descoberta de falhas produzem algumas
vezes intervalos muito curtos ou muito longos, com as seguintes implicações:
a. Intervalo de tarefa para encontrar falha muito curto, tem duas implicações
principais:
1. Algumas vezes o intervalo é de longe, muito curto, para ser prático. Um

exemplo deveria ser uma tarefa para descoberta de falha que requeira
que um item de porte de uma fábrica na ativa, seja desligado a cada três
ou quatro dias (poucos dias).
2. A tarefa poderia se tomar habitual (que pode acontecer se um alarme
contra incêndio é testado com freqüência).
Nesses casos a tarefa proposta deve ser rejeitada e que se descubra alguma outra
forma para reduzir a probabilidade de falha múltipla a um nível tolerável.
b. Um intervalo muito longo para descobrir falhas tem também duas

implicações:
1. Para intervalos que são substancialmente maiores do que a vida útil

remanescente que foi projetada para o ativo: Tais intervalos sugerem que
não há necessidade de se realizar tarefa de descoberta de falha
programada (Embora seja ainda necessário averiguar durante a atividade
que os dispositivos tenham sido instalados corretamente).
2. Para intervalos que são maiores do que o limite máximo planejado do

sistema de manutenção, mas que são menores do que o remanescente
projetado da vida útil do ativo: Nesses casos, cuidados deveriam ser
tomados para não diminuir os intervalos associados, simplesmente para
acomodar as limitações dos sistemas planejados existentes, se somente

porque tarefas para encontrar falhas podem algumas vezes incluir os

modos falhas, que não são passíveis de serem detectados.
c. Note que um intervalo de tarefa para encontrar falha pode emergir,

excedendo o intervalo médio entre falhas da função protegida. Assim como
o montante pelo qual o intervalo para encontrar falhas exceda o aumento
falhas, o valor da descoberta de falhas diminui rapidamente até que um
ponto é alcançado, onde há pouco ou nenhum efeito na probabilidade de
falha múltipla. Se em qualquer das fórmulas acima, obtiver-se um intervalo
neste ponto ou além dele, algum outro caminho precisa ser encontrado
para reduzir a probabilidade de falha múltipla a um nível tolerável.
13.4 Combinação de Tarefas – Se um modo de falha ou falha múltipla pode afetar segurança
ou meio-ambiente, e não se encontrou nenhuma tarefa programada, que por si só reduza o
risco de falha a um baixo nível tolerável, é algumas vezes possível que uma combinação de
tarefas (geralmente advindas de duas categorias de tarefas diferentes, tais como uma tarefa
em condições ideais e uma tarefa de descarte programada) pode reduzir o risco de modo
de falha ao nível tolerável.
Quando se considera tais combinações, cuidado deve ser tomado para assegurar que cada
tarefa por si só vai satisfazer os critérios de viabilidade técnica apropriada para aquele tipo
de tarefa, e que cada tarefa é concluída na freqüência apropriada para aquela tarefa.
Cuidado também tem que ser tomado para assegurar que duas tarefas combinadas irão de
fato reduzir as conseqüências a um nível tolerável. Entretanto, deve ser acentuado que
situações nas quais combinações de tarefas são necessárias, são muito raras, e todo
cuidado deve ser tomado para não se aplicar tais combinações indiscriminadamente.
14. Políticas de Gerenciamento de Falhas – Mudanças no Tempo Certo e Rodar até

Falhar.
14.1 Mudanças no Tempo Certo – O Processo RCM deve se empenhar a fim de extrair o
desempenho desejado do sistema como é correntemente configurado e operado quando
são aplicadas tarefas programadas apropriadamente. (SAE JA1011, Seção 5.8.11).
Nos casos onde tais tarefas não podem ser encontradas, no tempo certo, mudanças do
ativo ou sistema podem ser necessárias submetidas aos seguintes critérios:
a. No caso em que a falha está oculta e que a falha múltipla associada tem segurança
ou conseqüências ambientais, uma mudança no tempo certo que reduz a
probabilidade de falha múltipla a um nível tolerável ao proprietário ou usuário do
ativo é compulsório.
b. Nos casos onde o modo de falha é evidente e que tem segurança ou
conseqüências ambientais, uma mudança no tempo certo que reduza a
probabilidade de modo de falha a um nível tolerável ao proprietário ou usuário do
ativo, o compulsório.
c. Nos casos onde o modo de falha está oculto e a falha múltipla associada não tem
conseqüências à segurança ou conseqüências ambientais, qualquer mudança no
tempo certo deve ser custo-benefício, na opinião do proprietário ou usuário do ativo.
d. Nos casos onde o modo de falha é evidente e não tem segurança ou
conseqüências ambientais, qualquer mudança no tempo certo, deve ser custo-
benefício, na opinião do proprietário ou usuário do ativo. (SAE JÁ 1011, Seção
5.8.1.2).

As seções anteriores deste guia acentuaram que a capabilidade inicial (ou confiabilidade
inerente) de qualquer ativo é estabelecida por seu próprio esboço e de como ele é feito, e a
manutenção não pode render confiabilidade além da inerente no esboço. Isso conduz a
duas conclusões.
Primeiramente, se a capacidade inicial de um ativo é maior do que o desempenho desejado,

a manutenção pode ajudar o desempenho desejado. A maioria dos equipamentos é
especificada, desenhada e construída, portanto é geralmente possível desenvolver um
programa de manutenção satisfatório, como previamente descrito. Em outras palavras, na
maioria dos casos, RCM nos ajuda a extrair o desempenho desejado do ativo como é
correntemente configurado.
Em segundo lugar, se o desempenho desejado excede a capabilidade inicial, então o

montante da manutenção pode apresentar o desempenho desejado. Nesses casos,
manutenção “melhor” não pode resolver problemas, portanto é necessário olhar além da
manutenção para obter soluções. Na maioria dos casos, isso envolve mudança da
capabilidade de um dos três elementos do sistema:
a. Uma mudança na configuração física do ativo (que normalmente se refere a

um “redesenho” ou “modificação)”. Isso em qualquer ação deveria resultar em
uma mudança para um modelo ou uma lista de peças. Isso inclui mudança na
especificação de um componente, a adição de um item novo, substituição da
máquina por uma de diferente marca ou substituição da máquina por um de
diferente marca ou tipo ou relocar uma máquina. (Note que se qualquer
mudança, por feita, o processo RCM deverá ser aplicado integralmente ao
novo modelo com o objetivo de assegurar que ela continue a funcionar como
pretendido).
b. Uma mudança para um processo ou procedimento que afete o desempenho
do ativo.
c. Uma mudança na capacidade de uma das pessoas envolvidas na operação ou
manutenção do equipamento (Isso geralmente envolve treinar a pessoa em
questão, como método para se lidar com um modo de falha específico).
O termo “mudança imediata” é usado nesse guia para se referir a essas intervenções,
porque elas são geralmente feitas de imediato para qualquer sistema específico, em
oposição a tarefas programadas que são desempenhadas a intervalos regulares. Os
parágrafos que se seguem traçam os objetivos específicos de mudanças imediatas para
cada uma das categorias principais das conseqüências de falha.
14.1.1 Conseqüências em Segurança ou Ambientais – Se um modo de falha pudesse afetar

segurança ou o meio-ambiente e nenhuma tarefa programada ou combinação de tarefas
podem ser encontradas para reduzir o risco de falha a um nível tolerável, alguma coisa
precisa ser mudada simplesmente porque agora nós estamos lidando com um perigo que
afeta segurança e meio-ambiente, que não pode ser prevenido adequadamente. Nesses
casos, “redesenhar” é geralmente realizado com um entre dois objetivos:
a. Reduzir a probabilidade de um modo de falha não antecipado que ocorra a um

nível que é tolerável. Isso é geralmente feito ou se substituindo o componente
afetado por outro mais resistente ou mais confiável, ou fazer o possível para
antecipar o modo de falha.
b. Trocar o item ou o processo de tal forma que o modo de falha não tenha mais
conseqüências em segurança ou conseqüências ambientais. Isso é feito com
mais freqüência instalando-se um dispositivo adequado que proteja. Lembre-se
que se tal dispositivo é um adendo, os requerimentos de sua manutenção
também devem ser analisados.

Conseqüências em segurança ou ambientais também podem ser reduzidas eliminando-se

materiais perigosos de um processo ou mesmo abandonando-se todo o processo que seja
arriscado. Em suma, se o nível de risco associado com qualquer modo de falha é considerado
como intolerável, o RCM nos obriga ou a impedir que o modo de falha ocorra ou fazer um
processo seguro. A alternativa é aceitar as condições que são conhecidas como inseguras ou
ambientalmente insalubres. Isso não é mais aceitável para a maioria das indústrias.
14.1.2 Falhas Ocultas – No caso de falhas ocultas, o risco de falha múltipla pode ser reduzido
fazendo-se qualquer uma das seguintes mudanças imediatas:
a. Faça a falha oculta evidente, adicionando um outro dispositivo: Certas falhas

ocultas podem ser evidenciadas agregando-se um outro dispositivo (como
“Equipamento para Teste Embutido”, ou BITE), que chame a atenção do
operador para a falha oculta. E necessário cuidado especial nessa área, porque
falhas de funções extras instaladas com esse propósito têm também a tendência
de serem ocultas. Se muitas camadas de proteção são agrupadas, isso se torna
bastante difícil – se não impossível – definir tarefas para descoberta de falhas
perceptíveis. Uma aproximação mais efetiva é substituir uma função evidente
por uma função oculta, como se explica no próximo parágrafo.
b. Substitua uma função que protege, cuja falha é evidente pela função oculta: Na
maioria dos casos isso significa substituir um dispositivo ou sistema cuja falha é
genuinamente evidente por uma cuja falha não é evidente.
c. Substitua um dispositivo mais confiável (mas oculto) por um dispositivo existente
que protege. Um dispositivo mais confiável (em outras palavras, um que tenha
maior intervalo entre falhas) vai possibilitar que a organização alcance um de
três objetivos:
1. Reduzir a probabilidade de falha múltipla sem mudar os intervalos de tarefa
para descobrir falhas. Isso aumenta o nível de proteção.
2. Aumentar o intervalo entre tarefas sem mudar a probabilidades de falha
múltipla. Isso reduz a necessidade de recursos.
3. Reduzir a probabilidade de falha múltipla a aumentar os intervalos das tarefas.
d. Duplicar a função oculta: Se não for possível encontrar um único dispositivo que
protege que tenha um suficientemente alto MTBF para dar o nível de proteção
desejado, é ainda possível concluir com êxito qualquer dos três objetivos acima
duplicando-se (ou até mesmo triplicando) a função oculta. Entretanto, tenha em
mente que a função de todos esses dispositivos ainda precisariam ser
submetidos à análise, a fim de identificar uma política de gerenciamento de falha
apropriada.
e. Faça com que seja possível desempenhar uma tarefa programada (por
exemplo, melhorando o acesso ao dispositivo que protege ou sistema).
f. Reduza o índice exigido da função protegida: Dependendo dos modos de falha
que levam a necessidade de proteção, mude a configuração física do sistema
e/ou a capabilidade do operador ou mantenedor, de tal forma que o sistema
venha a requerer proteção com menor necessidade.
14.1.3 Conseqüências Operacionais e não Operacionais – Para alguns modos de falha com
conseqüências operacionais e não operacionais, o custo-benefício maior da política de
gerenciamento de falha pode ser o de mudar o sistema para reduzir os custos totais. Para
que se consiga isso, as mudanças deveriam procurar:
a. Reduzir o número da ocorrência dos modos de falha, ou se possível eliminá-los

todos, como já mencionado fazer algum elemento do sistema mais robusto ou
mais confiável.

b. Reduzir ou eliminar a conseqüências do modo de falha (por exemplo,

providenciando um capacitador de apoio).
c. Fazer uma tarefa programada custo-benefício (por exemplo, fazer um
componente mais acessível).
Note que nesse caso, modificações precisam ter os custos justificados, considerando que
eles sejam compulsórios se não houver jeito de reduzir risco de falhas que tenham
conseqüências em segurança e no meio-ambiente a um nível tolerável.
14.2 Rodar Até Falhar – Qualquer política “rodar até falha” que for selecionada deverá
satisfazer os critérios apropriados como segue:
a. Nos casos onde a falha está oculta e não há tarefa programada apropriada, a
falha múltipla apropriada não deverá ter conseqüências em segurança ou no
meio-ambiente.
b. Nos casos onde a falha é evidente e não há tarefa programada apropriada, o
modo de falha associado não deverá ter conseqüências em segurança ou no
meio ambiente. (SAE JA1011, Seção 5.8.2).
No caso de algumas falhas que são evidentes e que não afetam segurança ou o meio
ambiente, ou que são ocultas e que a falha múltipla não afeta a segurança ou o meio-
ambiente, o maior custo-benifício da política de gerenciamento de falha, pode simplesmente
ser para permitir que falhas ocorram e assim dar os passos apropriados para consertá-las.
Em outras palavras, “rodar até falhar” só será válido se:
a. Uma tarefa programada adequada não pode ser encontrada para uma pode ser
encontrada para uma falha oculta e a falha múltipla associada não tem
conseqüências na segurança ou no meio-ambiente, e:
b. Um custo-benefício em tarefa pró-ativa não pode ser encontrado para falhas
com conseqüências operacionais ou não operacionais.
15. Seleção de Política de Gerenciamento de Falha.
15.1 Duas Aproximações – As últimas três perguntas no processo RCM, discutido nas seções
10 até 14 desse guia, envolvem a seleção de políticas de gerenciamento de falha
apropriado para cada modo de falha identificado no FMEA. Duas aproximações distintas
podem ser usadas para selecionar políticas de gerenciamento de falhas. A primeira é uma
aproximação rigorosa e a segunda é uma aproximação de diagrama de decisão.
A aproximação rigorosa é mais abrangente e produz um custo otimizado total para política
de gerenciamento de falha por lidar com cada modo de falha no FMEA. Diagramas de
decisão são populares porque são rápidos e mais baratos do que as aproximações
rigorosas. Entretanto, qualquer diagrama de decisão precisa ser totalmente direcionado
para as conseqüências de segurança e meio-ambiente de cada modo de falha. Deve-se ter
também em mente que o uso de diagramas de decisão não introduz um elemento de sub
otimização para o processo de seleção de política de gerenciamento de falha, do ponto de
vista do custo.
Note que quando se aplica qualquer das duas aproximações muitas decisões têm que ser
feitas na ausência total de dados. Isso pode direcionar a uma forte tendência de depender
excessivamente de “negligência lógica”, na qual decisões são tomadas automaticamente,
se não houver dados compreensíveis, disponíveis de imediato. Entretanto, a aplicação da
tal lógica pode direcionar a decisões incorretas, especialmente quando se julgam as
conseqüências. Na prática, uma decisão deve ser tomada se repercussões possíveis de
grande incerteza não possam ser toleradas, dessa forma a ação deve ser tomada para

mudança das conseqüências do modo de falha – em vez de depender das decisões de

“negligência”.
15.2 Aproximação Rigorosa – A aproximação rigorosa da seleção de políticas de

gerenciamento de falhas requer dos usuários julgamento econômico e conseqüências de
segurança / meio-ambiente de cada modo de falha, para considerar opções de política de
gerenciamento de falhas tecnicamente viáveis que possam ser aplicadas a cada modo de
falha, e para selecionar política de gerenciamento de falha que lida mais efetivamente com
ambos, conseqüências econômicas e segurança / meio-ambiente. Esta aproximação é
aplicada nos seguintes estágios:
a. Separar falhas evidentes das falhas ocultas

b. Para cada falha evidente:
1. Estabelecer a real probabilidade de que a falha múltipla associada possa ferir ou

provocar a morte de alguém
2. Estabelecer a probabilidade tolerável de que a falha múltipla possa ferir ou
provocar a morte de alguém
3. Estabelecer a real probabilidade de que a falha múltipla possa violar um padrão
ambiental ou regulamento
4. Estabelecer a probabilidade tolerável de que a falha múltipla possa violar o
padrão ou o regulamento
5. Estabelecer conseqüências totais do modo de falha operacional e não
operacional e a falha múltipla associada
6. No caso de falha múltipla que possa ter conseqüências na segurança e no meio-
ambiente e onde a real probabilidade da ocorrência dessas conseqüências seja
maior do que a probabilidade tolerável, identificar todas as políticas de
gerenciamento de falhas que possam reduzir a probabilidade de falha múltipla a
um nível tolerável.
7. Identificar todas as políticas de gerenciamento de falhas (caso haja alguma) que
possam custar menos do que as conseqüências do modo de falha econômica e
a falha múltipla juntas, quando mensuradas em um período de tempo adequado.
8. Selecionar políticas de gerenciamento de falhas que lidem com maior custo-
benefício com segurança / meio-ambiente e modos de falha com conseqüências
econômicas e falha múltipla.
15.3 Aproximações do holograma de Decisão –Todas as aproximações do diagrama de

decisão para o RCM que concordam com SAE JA1011 são baseadas na hipótese de que
conseqüências na segurança / meio-ambiente deveriam ser tratadas antes das
conseqüências econômicas. Outra hipótese construída na maioria desses diagramas, é que
algumas categorias de políticas de gerenciamento de falhas são quase sempre mais “custo-
benefício” do que outras.
Essas duas hipóteses são usadas para estabelecer hierarquias nas quais os usuários são
encorajados a selecionar uma política de gerenciamento de falha, da primeira categoria
dentro da hierarquia que é considerada como sendo tecnicamente viável e que vale a pena
ser feita. As hipóteses chave feitas ao se estabelecer tais hierarquias são discutidas nos
parágrafos seguintes.
NOTA – Através de toda essa seção, “falha” se refere a modo de falha e falha múltipla.
15.3.1 Conseqüências da Hierarquia – Todas as aproximações válidas do diagrama de decisão

para RCM supõem que se uma política de gerenciamento de falha lida satisfatoriamente
com a falha que tem conseqüências na segurança ou no meio- ambiente então, vai lidar

satisfatoriamente com as conseqüências daquela falha (operacional e não operacional). Na

maioria dos casos, essa hipótese é valida, mas não verdadeira em todos os casos.
O resultado dessa hipótese é que os diagramas de decisão RCM válidos são construídos
de tal forma que se as conseqüências de uma falha na segurança ou no meio-ambiente
são considerados como sendo intoleráveis, então os usuários são obrigados a encontrar
uma política de gerenciamento de falha que reduza as conseqüências na segurança /
meio-ambiente a um nível tolerável, sem considerarem as conseqüências econômicas da
falha. Essa aproximação é inerentemente conservadora, nesse caso isso assegura que as
conseqüências em segurança e no meio-ambiente de toda falha são lidadas
apropriadamente. Como resultado isso vai conduzir a um programa de manutenção sadio,
concernente à segurança e ao meio-ambiente, que contém um número reduzido de
políticas de gerenciamento de falhas que são mais custosos do que o necessário.
15.3.2 Políticas de Hierarquia – Duas hipóteses chave são construídas dentro do desenho da
maioria dos diagramas de decisão do RCM. A primeira hipótese é que algumas categorias
de política de gerenciamento de falha são inerentemente mais “custo-benefício” do que
outras. A segunda hipótese é que algumas são mais conservadoras do que outras. Se um
diagrama de decisão usa uma aproximação hierárquica para seleção de política, as
hierarquias a seguir refletem mais exatamente essas hipóteses:
a. Para modos de falha evidente que possam afetar a segurança ou o meio-

ambiente, políticas de gerenciamento de falhas são consideradas na seguinte
ordem: tarefas em condições ideais, restauração programada, tarefas de
descarte, combinação de tarefas (geralmente em condições ideais e descarte
programado), mudança imediata.
b. Para modos de falha que não possam afetar a segurança ou o meio-ambiente,
políticas de gerenciamento de falas são consideradas na seguinte ordem:
tarefas em condições ideais, tarefas em condição/descarte programados,
manutenção não programada, mudança imediata.
c. Para modos de falha oculta onde a falha múltipla possa afetar a segurança e o
meio-ambiente, políticas de gerenciamento de falhas são consideradas na
seguinte ordem: tarefas em condições ideais, tarefas de restauração/descarte
programados, descoberta de falhas, combinação de tarefas (geralmente
descoberta de falhas e descarte programado), mudança imediata.
d. Para modos de falha oculta onde a falha múltipla não possa afetar a
segurança e o meio-ambiente, políticas de gerenciamento de falhas são
consideradas na seguinte ordem: tarefas em condições ideais, tarefas de
restauração/descarte, descoberta de falhas, manutenção sem programa,
mudança imediata.
Os motivos para o direcionamento de políticas de gerenciamento de falha são discutidos

nos parágrafos seguintes.
15.3.2.1 Tarefas em Condições Ideais – Tarefas em condições ideais são em primeiro lugar
consideradas dentro do processo de seleção de tarefas, pelas seguintes razões:
a. Elas podem quase sempre ser desempenhadas sem que o ativo seja mudado
da posição em que foi instalado e geralmente quando estão em operação, e
dessa maneira, elas raramente interferem com operações.
b. São geralmente fáceis de organizar
c. Elas identificam condições específicas de falhas em potencial, portanto ações
corretivas podem ser claramente definidas antes que se inicie o trabalho. Isso
reduz o montante do trabalho de reparo a ser feito e permite que ele seja feito
mais rapidamente.

d. Ao se identificar o equipamento no ponto da falha em potencial, elas

permitem que se conheça quase que a totalidade da sua vida útil.
15.3.2.2 Restauração Programada e Tarefas de Descarte Programadas – Se uma tarefa em

condições ideais adequada não pode ser encontrada para uma falha específica, a
próxima escolha é uma restauração programada. As desvantagens de restauração
programada e descarte programado são que:
a. Em quase todos os casos elas podem ser somente feitas quando os itens são
parados e enviados (geralmente) para a oficina, portanto as tarefas quase
sempre afetam as operações de alguma maneira;
b. A idade limite se aplica a todos os itens, portanto, muitos itens ou
componentes que possam ter sobrevivido a idade maiores, serão removidos;
c. Tarefas de restauração envolvem trabalho de oficina, portanto elas geram
maior acúmulo de serviço do que tarefas em condições ideais.
Como mencionado em 13.2 deste guia, restaurações programadas e descarte

programado são geralmente considerados, juntas porque elas têm muito em comum.
Quando essas tarefas são encontradas na prática, é geralmente óbvio que, ou o
componente em questão deve ser lidado com o descarte programado ou com a
restauração programada. Entretanto, no caso de alguns modos de falha, ambas as
categorias de tarefas podem satisfazer os critérios pra viabilidade técnica. Nesses
casos, o custo-benefício mais adequado dentre os dois deve ser selecionado.
15.3.2.3 Descoberta de Falhas – Manutenção pró-ativa realizada com sucesso, previne que
objetos falhem, ao passo que descoberta de falhas aceita que elas vão dispender mais
tempo – embora não muito – em estado de falha. Isso significa que manutenção pró-
ativa é inerentemente mais conservadora do que descoberta de falha (em outras
palavras, é mais segura), portanto esta última deve ser especificada somente se uma
tarefa pró-ativa mais efetiva não pode ser encontrada. Por essa razão os diagramas de
decisão RCM, deveriam colocar sempre as três categorias de tarefas pró-ativas antes
do processo de seleção de descoberta de falha.
15.3.2.4 Combinação de Falhas – Nesse ponto, os diagramas de decisão tentam encontrar em

uma única tarefa que vai lidar apropriadamente com as conseqüências do modo de
falha, que estão sendo consideradas. Entretanto, como mencionadas em 13.4, algumas
vezes acontece que uma tarefa única não pode ser encontrada e que por si só reduza o
risco de falha a um nível tolerável. Talvez neste ponto seja apropriado procurar uma
combinação de tarefas, como explicado em 13.4. A maior desvantagem da combinação
de tarefas é que elas são inevitavelmente mais caras do que tarefas individuais.
15.3.2.5 Rodar até falhas – Quando se analisa a eficácia de tarefa pró-ativa planejada para lidar
com modos de falha que tenham conseqüências econômicas, é sempre feita
comparação entre o custo da tarefa e os custos associados com modo de falha
antecipado. Nesses casos, tarefas são selecionadas somente se elas reduzem o custo
total da falha. Se tal tarefa não pode ser encontrada, permitindo-se que o modo de falha
ocorra, será menos custoso do que a manutenção pró-ativa, e, portanto, ao se permitir
que o modo de falha ocorra (rodar até falhar) deveria ser selecionado como política de
gerenciamento de falha apropriado. (Se os custos de se permitir que o modo de falha
ocorra são ainda assim considerados excessivos, então, somente, outra opção é
implementar uma mudança imediata como foi discutido previamente). Como explicado
em 14.2 deste guia, rodar até falhar não uma opção para um só modo de falha e falhas
múltiplas que tenham consequências em segurança e meio ambiente.

15.3.2.6 Mudanças Imediatas – Confiabilidade, esboço e manutenção têm ligações intrínsecas.

Isso pode induzir à tentação de se fazer mudanças imediatas nos sistemas existentes
(especialmente modificações no equipamento) antes de se considerar os requerimentos
da sua manutenção. De fato, todos os diagramas de decisão RCM consideram a
manutenção antes das mudanças imediatas, por quatro razões, como se segue:
a. A maioria das modificações tem duração de seis meses a três anos, desde
a sua concepção até a autorização dependendo do custo e da
complexidade do novo esboço. Por outro lado, a pessoa da manutenção
que está de plantão hoje, tem que manter o equipamento hoje e não aquele
que deveria estar lá ou que possa estar lá em algum tempo no futuro.
Portanto, as realidades de hoje têm que ser lidadas antes das mudanças de
amanhã.
b. A maioria das organizações enfrenta oportunidades aparentemente muito

mais desejáveis na melhoria do esboço do que economicamente ou
fisicamente viáveis. Ao focalizar conseqüências de falha, RCM nos dá uma
grande ajuda no desenvolvimento racional de conjunto de prioridades para
esses projetos, especialmente porque separa aqueles que são essenciais
daqueles que são meramente desejáveis. Claramente, tais prioridades
podem ser estabelecidas somente depois que a revisão esteja completada.
c. Mudanças imediatas são caras. Elas envolvem o custo do desenvolvimento

de novas idéias (o esboço de uma máquina nova, desenhar um novo
procedimento operacional), o custo de transformar a idéia em realidade
(fabricar uma nova peça, adquirir uma nova máquina, elaborar um novo
programa de treinamento) e o custo de implementar a mudança (instalação
da peça, conduzir o programa de treinamento). Futuros custos indiretos
ocorrem se equipamento ou pessoas tem que ser removidas do serviço
enquanto a mudança está sendo implementada.
d. Há um risco de que a mudança falhe em eliminar ou mesmo aliviar o

problema para a qual foi programada para resolver. Em alguns casos, isso
pode até criar mais problemas.
Por todas essas razões, aproximações do diagrama de decisão RCM procuram extrair o
desempenho desejado de qualquer sistema como é correntemente configurado antes de
se fazer tentativa para mudar a configuração do sistema.
15.3.3 Aplicar Aproximação do Diagrama de Decisão – Diferentes diagramas de decisão RCM

estão uso pelo mundo todo. Alguns desses diagramas se conformam muito de perto aos
princípios discutidos anteriormente, enquanto outros divergem substancialmente (em
alguns casos, a um grau em que não concordam de maneira alguma com SAE JA
1011). Alguns desses diagramas são de propriedade exclusiva, enquanto que outros
são de domínio público. Por essas razões, este Guia não endossa um diagrama de
decisão específico. Entretanto, puramente com o propósito de ilustração, dois exemplos
de diagrama de decisão que concordam com os princípios discutidos em 15.3.1 e 15.3.2
são providenciados nas figuras 16 e 17. (Note os comentários em 18.6 sobre a
necessidade de treinamento antes de usar qualquer diagrama de decisão).
Estes diagramas de decisão são tipicamente aplicados em três estágios, como segue:
a. Começando do princípio, use diagramas de decisão para determinar a

categoria de conseqüências que se aplica ao modo de falha em questão.

b. Trabalhando na coluna de conseqüências relevantes, use os critérios de

viabilidade técnicas discutidas nas seções 12 até a 14 deste guia a fim de
avaliar a viabilidade técnica de possível políticas de gerenciamento de falha
em cada categoria.
c. Selecione políticas de gerenciamento de falha de primeira categoria que
satisfaçam os critérios de viabilidade técnica e que lidem efetivamente com
as conseqüências do modo de falha ora considerado.



16. Programa Vivo – “Este documento reconhece que (a) a maioria dos dados usados na
análise inicial é inerentemente imprecisa, e que dados mais precisos estarão disponíveis a
tempo; (b) a maneira em que o ativo e usado, junto com expectativas de desempenho
associado vão também mudar com o tempo, e; (c) manutenção tecnológica vai continuar a
evoluir. Portanto, uma revisão periódica é necessária se o programa de gerenciamento do
ativo derivado do RCM é para assegurar que o ativo continua a preencher as expectativas
funcionais dos proprietários e usuários” (SAE JA1011, seção 5.9.1).
“Portanto qualquer processo RCM deve providenciar revisão periódica para ambos, a
informação usada para apoiar as decisões e as decisões por si mesmas. O processo usado
para conduzir tal revisão deverá assegurar que todas as sete questões do parágrafo 5
continuam a ser respondidas satisfatoriamente e de uma maneira consistente com os critérios
estabelecidos na seção 5.1 até 5.8 (do SAE JÁ 1011)”. (SAE JÁ1011, seção 5.9.2)
Para assegurar que as sete questões do SAE JA1011 “continuem a ser respondidas
satisfatoriamente e de uma maneira consistente com os critérios estabelecidos” do
documento, questões específicas que deveriam ser respondidas incluem o seguinte:
a. Contexto operacional: O contexto tem operacional mudado o suficiente para

mudar qualquer uma das informações registradas ou decisões feitas durante a
analise operacional? (Por exemplo, uma mudança de um turno só / 5 dias de
operação para 24 horas / 7 dias de operação ou vice versa).
b. Expectativas de desempenho: Algumas expectativas de desempenho têm mudado
o suficiente para que seja necessário revisar os padrões de desempenho que
foram definidos durante a análise inicial?
c. Modos de falha: Desde a análise prévia tem havido divulgação que algum modo
de falha existente foi registrado incorretamente, ou algum modo de falha não
antecipado tenha ocorrido, que devesse ser registrado?
d. Efeitos de falha: Deveria ser alguma coisa adicionada ou mudada na descrição
dos efeitos de falha? (Isso se aplica especialmente à evidência de falha e de
estimativas na operação das máquinas).
e. Conseqüências de falha: Aconteceu algo que tenha feito com que alguém
acreditasse que conseqüências de falha devessem ser julgadas diferentemente?
(Possibilidades incluem aqui mudanças de regulamentações ambientais e
mudanças de percepção sobre níveis de risco toleráveis).
f. Políticas de gerenciamento de falha: Há alguma razão para acreditar que
quaisquer políticas de gerenciamento de falha selecionadas inicialmente não são
mais apropriadas?
g. Tarefas programadas: Alguém descobriu uma tarefa programada que pudesse ser
superior àquelas selecionadas previamente? (Na maioria dos casos “superior”
significa mais “custo-benefício”, mas também poderia significar tecnicamente
superior).
h. Intervalos de tarefas: Há alguma evidência que sugere que a freqüência de
qualquer tarefa devesse ser mudada?
i. Execução da tarefa: Há alguma razão que sugere que a tarefa ou tarefas
devessem ser feitas por alguém diferente do tipo de pessoa selecionada
originalmente?
j. Modificações do ativo: Tem o ativo sido mudado de maneira que adicione ou
subtraia quaisquer funções ou modos de falha, ou que mude as características de
qualquer política de gerenciamento de falha? (atenção especial deveria ser dada
para controlar o sistema e a proteção).
17. Fórmulas Matemáticas e Estatísticas – Quaisquer fórmulas matemáticas e estatísticas

que são usadas na aplicação do processo (especialmente aquelas usadas para computar

os intervalos de qualquer tarefa) devem ser logicamente robustas e, devem estar

disponíveis e aprovadas pelo proprietário e usuário do ativo. “(SAE JÁ 1011, seção 5.10.1)”.
Processos RCM usam algumas vezes fórmulas matemáticas e estatísticas, especialmente

para computar intervalos de tarefas em que as tarefas de Descoberta de Falha devam ser
desempenhadas, é o caso da fórmula encontrada em 13.3.3 e a fórmula encontrada em
13.3.3.4.
Em adição, dados estão algumas vezes disponíveis e permitem várias fórmulas a serem
usadas para refinar as freqüências em que diferentes tipos de tarefas pró-ativas devam ser
desempenhadas.
Antes de um processo RCM conforme ao SAE JA1011 adote quaisquer fórmulas como
essas, elas devem se submeter a dois critérios-chave: as fórmulas precisam ser
logicamente robustas e precisam ser avaliadas e aprovadas pelo proprietário e usuário do
ativo.
17.1 Logicamente Robustas – As fórmulas precisam ser “logicamente robustas”. Isso significa
que elas precisam ser consistentes com as condições do comportamento do equipamento e
a determinação que reside sobre as fundações do RCM. Especificamente, isso significa que
fórmulas não necessitam elaborar teorias inadequadas sobre padrões de falha que se
apliquem a modos de falha individuais, que poderiam afetar o ativo em consideração ou
sobre o relacionamento entre variáveis como idade, MTBF e intervalos P-F.
17.2 Disponível para o Proprietário ou Usuário – Para que as fórmulas sejam disponibilizadas
e aprovadas pelo proprietário ou usuário do ativo, “duas condições precisam ser
encontradas”.
Primeiro, o provedor da fórmula precisa estar apto para mostrar a fórmula para o usuário,
demonstrar como foi originada e as teorias nas quais basearam, e explicar porque a fórmula
deveria ser usada como foi proposta.
Segundo, o usuário ou proprietário do ativo precisa ter compreensão suficiente sobre os

princípios fundamentais do gerenciamento físico do ativo, para estar apto a avaliar por ele
(ela) mesmo se a fórmula de fato é apropriada.
18. Considerações Adicionais Importantes – SAE JA1011 descreve os critérios técnicos

mínimos que qualquer processo precisa acordar com o chamado “RCM” quando aplicado a
um ativo específico. Para que RCM tenha sucesso é essencial que se direcione ao
gerenciamento e aos tópicos de recursos que são discutidos nessa seção, desse Guia, o
seguinte:
a. Priorizar ativos e estabelecerem objetivos.

b. Planejamento.
c. Nível de análises e limites do ativo.
d. Documentação técnica.
e. Organização.
f. Treinamento.
g. O papel virtual do Computador.
h. Coleta de dados.
I. Implementação.

18.1 Priorizar ativos e estabelecer objetivos.
Diferentes proprietários e usuários vão preferir aplicar RCM a diferentes ativos. Pode ser
que um prefira aplicar RCM em todos os ativos. Outro pode preferir a aplicação RCM em
alguns ativos ou peças dos ativos agora, esperando aplicar eventualmente, no restante.
Estas decisões vão depender de um grande alcance, sobre as metas da análise RCM,
assim como a importância dessas metas em relação a outras iniciativas adotadas pelo
proprietário ou usuário do ativo.
Proprietários ou usuários deveriam estabelecer conscientemente prioridades entre os

ativos, usando critérios que sejam apropriados à sua organização. Ao estabelecer essas
prioridades, note que aplicar RCM demanda tempo e custa dinheiro.
Como resultado, antes de comprometer recursos em escala significativa, qualquer

organização deveria estabelecer qual o benefício que a organização espera receber em
troca do comprometimento de recursos. Na prática, RCM salienta a eficiência total da
organização que a aplica, em uma enorme variedade de áreas, incluindo:
a. Segurança.
b. Integridade ambiental.
c. Desempenho operacional.
d. Custo – Benefício.
e. Qualidade do produto e serviço do Cliente.
f. Eficiência em manutenção.
g. Motivação individual.
h. Grupo de trabalho.
i. Transferência de pessoal.
j. Serviço de Auditoria.
Esses tópicos não somente devem ser direcionados quando se prioriza as análises, mas
também precisam ser considerados detalhadamente com respeito a cada análise.
Especialmente antes de iniciar a análise RCM de qualquer ativo específico ou sistema, é
essencial estabelecer a abrangência do que se espera em termos da melhoria do
desempenho de cada análise, em qualquer ou na totalidade das áreas descritas acima,
também detectar qual a sua melhoria no que tange ao custo total dessa análise.
18.2 Planejamento – Antes de se analisar cada item, um plano esclarecedor deve ser
elaborado um plano que direciona os seguintes tópicos.
a. Decidir exatamente qual equipamento deve ser coberto pela análise, como
discutido em 18.3.
b. Estabelecer os objetivos da análise (quantificá-los quando for possível) e
concordar quando e porque sua realização deve ser medida.
c. Fazer uma projeção de quanto tempo vai ser necessário para levar a análise a
bom termo (hora trabalhada e tempo gasto)
d. Decidir quais conjuntos de habilidades devem ser envolvidos no processo da
análise, depois identificar especificamente pelo nome, cada participante.
e. Organizar treinamento apropriado em RCM para aqueles que ainda não
receberam tal treinamento, como discutido abaixo.
f. Organizar facilidades físicas apropriadas para que o processo seja levado
adiante.
g. Decidir quando e quem vai fazer a análise e aprová-la. Isso envolve certeza de
que o processo RCM foi aplicado corretamente, e que a informações e
decisões são aceitáveis ao proprietário/usuário do ativo.
h. Decidir quando, onde e por quem as recomendações vão ser implementadas.

i. Organizar para que a análise seja mantida atualizada como discutido na seção
16 deste guia.
18.3 Níveis da Análise e Limites do Ativo – Antes de se analisar qualquer ativo, é necessário
estabelecer o nível no qual a análise deve ser desempenhada. (algumas vezes chamada de
nível de importância) e definir os limites do sistema.
Se uma compreensível hierarquia do ativo foi projetado e foi tomada uma decisão para se
analisar o ativo específico, a um nível específico, então o “sistema” geralmente inclui todos
os ativos abaixo daquele sistema no ativo hierárquico. (Se um ativo hierárquico não existe,
é de ajuda, porém não essencial, compilar um). As únicas exceções são sistemas que são
julgados como sendo tão insignificantes que não serão analisados de jeito nenhum, ou
subsistemas tão complexos que são colocados de lado para serem analisados em
separado.
O nível de análise é o nível de importância do item no qual a análise será desempenhada.

Embora não haja um nível melhor para realizar a analise RCM, geralmente há um nível
favorável (este nível pode variar de sistema para sistema dentro do ativo hierárquico). O
nível favorável da análise vai depender de vários fatores. Esses fatores incluem, mas não
se limitam a isso, se uma completa análise, ou mais limitada, seja desempenhada, caso
qualquer análise prévia exista e o nível no qual eles foram realizados, e a complexidade do
item que está sendo direcionado.
Deveria ser tomado cuidado para escolher um nível de análise que permita que funções
sejam identificadas de uma forma que seja razoavelmente fácil para se compreender, que
permita a identificação de um número de modos de falha gerenciáveis para cada função,
que permita conseqüências de falha, que sejam julgadas sem dificuldade. Análises de
níveis tão baixos ficam sujeitas a trabalho extra quando se analisa e/ou ocorrem tarefas de
saída de material, também se torna difícil identificar funções e padrões de desempenho
associados desejáveis, tornando-se muito mais difícil julgar conseqüências imediatamente.
Análises de tão alto nível precisam de identificação de muitos modos de falha para cada
função, o que aumenta a probabilidade de modos de falha passarem despercebidos. A
escolha lógica, portanto é selecionar um nível intermediário que permita identificar um
número de modos de falha gerenciáveis e julgar suas conseqüências sensatamente.
Quando se aplica RCM a qualquer ativo ou sistema, é importante definir com clareza onde o
“sistema” a ser analisado começa e onde termina. É preciso cuidado para assegurar que
ativos e componentes dentro das fronteiras não falhem nas “emendas”. Isso se aplica
especialmente a itens como válvulas e bordas.
18.4 Documentação Técnica – Antes de se analisar qualquer sistema específico ou subsistema,

é extremamente profícuo obter qualquer documentação que possa estar disponível, que
descreva a configuração física do ativo, seus componentes maiores e como funciona.
Dependendo da complexidade do sistema e como ele é compreendido pelos que fazem a

análise, esses documentos podem incluir alguns ou todos seguintes requisitos:
a. Desenhos organizados em geral.

b. Diagramas de tubulação e fiação que incluem diagramas de processo e
instrumental.
c. Manuais de operação e manutenção.
d. Documento de apoio ao projeto.
e. Lista de peças.

Quando disponível essa documentação pode ser obtida, geralmente, dos projetistas do
sistema e/ou fabricantes/vendedores. Documentação já existente deve geralmente ser
suficiente para completar a análise RCM. Se não houver documentação específica
(especialmente desenhos), deve ser criado somente se isso tornar a análise
significantemente mais exata, e/ou fácil de ser realizada.
18.5 Organização – Qualquer organização que decide aplicar RCM em qualquer ativo, precisas
estabelecer uma organização que incorpore os seguintes elementos:
a. Pessoa ou grupo de pessoas que sejam responsáveis por assegurar que o

processo RCM a ser usado, concorda com SAE JÁ 1011, e por estabelecer
planos claros, decidindo o que deve ser analisado e por quem. (ver 18.1)
b. Pessoa ou grupo de pessoas que sejam responsáveis em assegurar que os
ativos selecionados são analisados como foi planejado.
c. Pessoa ou grupo de pessoas que vão liderar a aplicação do processo.
d. Pessoa que será responsável em providenciar informações e assistir nas
tomadas de decisão (representantes dos proprietários/usuários dos ativos,
operadores, mantenedores, representantes do projeto ou vendedor (caso seja
necessário),etc.).
e. Facilidades físicas requeridas para conduzir a análise (escritórios, salas de
reunião, computadores, etc.)
18.6 Treinamento – O processo RCM abrange muitos conceitos que são novidades para a
maioria das pessoas, portanto qualquer pessoa que deseje aplicar RCM precisa conhecer
quais são esses conceitos e como eles se aglutinam, antes que possam fazer uso do
processo com segurança.
Como resultado, requisitos de treinamento devem ser claramente definidos. Isso é essencial
para assegurar que o processo RCM seja aplicado corretamente, e que os resultados
possam ser concebidos com confiança. O montante do treinamento requerido pelos
membros do time RCM vai variar conforme suas atuações.
Para pessoas que gerenciam a aplicação do processo, que participam como provedores de
informações, ou que serão envolvidos na implementação dos resultados de cada análise,
um curso formal de não menos do que três dias de duração é geralmente suficiente.
Para pessoas que dirigirão a aplicação desse processo (“analistas” ou “facilitadores”) um

treinamento mais profundo é requerido. Isso deve tomar a forma de monitoramento no
próprio local, suplementado, talvez por um treinamento formal, até que a pessoa que está
sendo treinada seja competente em todas as habilidades requisitadas.
19. Notas.
19.1 Palavras-chaves – Manutenção baseada em condição, manutenção prognosticada,

manutenção preventiva, manutenção pró-ativa, RCM, manutenção centrada em
confiabilidade, manutenção programada.

Norma SAE JA 1012 Versão Português

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Norma SAE JA 1012 Versão Português

Enviado por

Direitos autorais:

Formatos disponíveis

Norma

Um Guia para o Padrão RCM.

Contudo, no desenvolvimento de alguns destes documentos, elementos-chave do processo RCM foram

Índice dos Assuntos

1.1. Como o Guia é Organizado _________________________________________________ 3

2.1. Documentos Pertinentes ___________________________________________________ 3

2.2. Publicações Relacionadas __________________________________________________ 3

2.3. Outras Publicações ______________________________________________________ 7

5. Definição de Ativo _________________________________________________________ 7

6. Lista de Funções __________________________________________________________ 8

6.1. Contexto Operacional _____________________________________________________ 11

6.2. Lista de Funções __________________________________________________________12

6.3. Descrição das Funções ____________________________________________________ 14

6.4. Padrões de Desempenho __________________________________________________ 15

7. Falhas Funcionais ________________________________________________________ 17

7.1. Falha Total ou Parcial _____________________________________________________ 17

7.2. Limite Superior e Inferior ___________________________________________________ 18

8. Modos de Falhas ________________________________________________________ 18

8.1. Identificação dos Modos de Falhas __________________________________________ 18

8.2. Estabelecendo o que significa “O Mínimo Aceitável” _____________________________ 19

8.3. Níveis de Causa ________________________________________________________ 20

8.4. Fontes de Informação ____________________________________________________ 22

8.5. Tipos de Modos de Falha __________________________________________________ 23

9. Efeitos da Falha _________________________________________________________ 24

9.1. Pré Supostos Básicos ___________________________________________________ 24

9.2. Informações Necessárias _________________________________________________ 24

10. Categoria de Conseqüências de Falhas _____________________________________ 26

Revisão 09/2013 Página 2 de 65

10.1. Categoria das Conseqüências _____________________________________________ 26

10.2. Avaliar as Conseqüências de Falhas ________________________________________ 30

11. Seleção das Políticas de Gerenciamento de Falhas ____________________________ 31

11.1. Relacionamento entre Idade e Falha ________________________________________ 31

11.2. Tecnicamente Viável e Valer a Pena ________________________________________ 32

11.3. Eficácia de Custo _______________________________________________________ 32

11.4. Seleção das Políticas nas Falhas de Gerenciamento ___________________________ 32

12. Gerenciamento das Conseqüências das Falhas ______________________________ 33

12.1. Modos de Falhas Evidentes com Conseqüências de Segurança

12.2. Modos de Falhas Ocultas com Segurança ou Conseqüências

12.3. Modos de Falhas Evidentes com Conseqüências Econômicas ___________________ 36

12.4. Modos de Falhas não Ocultam com Conseqüências

13. Políticas de Gerenciamento de Falhas - Tarefas Programadas ___________________ 37

13.1. Tarefas Sob Condição ___________________________________________________ 37

13.2. Tarefas de Restauração Programada e Descarte Programado ____________________ 44

13.3. Tarefas de Busca de Falhas _______________________________________________ 45

13.4. Combinação de Tarefas __________________________________________________ 50

14. Políticas de Gerenciamento de Falhas – Modificações

14.1. Modificações de uma só vez ______________________________________________ 51

14.2. Rodar até Falhar ______________________________________________________ 54

15. Seleção de Política de Gerenciamento de Falhas ____________________________ 54

15.1. Duas Abordagens _____________________________________________________ 54

15.2. Abordagem Rigorosa __________________________________________________ 54

15.3. Abordagem do Digrama de Decisão _______________________________________ 54

16. Um Programa Ativo ____________________________________________________ 58

Revisão 09/2013 Página 3 de 65

17. Formulas Estatísticas e Matemáticas _____________________________________ 58

17.1. Logicamente Robusto __________________________________________________ 58

17.2. Disponível ao Proprietário ou Usuário ______________________________________ 58

18. Importantes Considerações Adicionais ____________________________________ 58

18.1. Priorizar Ativos e Estabelecer Objetivos ___________________________________ 63

18.2. Planejamento _______________________________________________________ 63

18.3. Nível de Analise e Limites do Ativo ______________________________________ 64

18.4. Documentação Técnica ________________________________________________ 64

18.5. Organização ________________________________________________________ 65