Você está na página 1de 12

IESAM – MBA Engenharia de Manutenção – Professor Wilton Matos Costa

Critérios de Avaliação de Processos de Manutenção Centrada em


Confiabilidade-(RCM)

Prefácio- Manutenção Centrada em Confiabilidade (RCM) foi inicialmente


desenvolvida pela indústria da aviação comercial para melhorar a segurança e
confiabilidade de seus equipamentos. Foi documentada pela primeira vez em um
relatório escrito por F.S. Nowlan and H.F. Heap e publicado pelo Departamento de
Defesa dos EUA em 1978. Desde então, a RCM tem sido usado para ajudar a formular
estratégias de gestão de ativos físicos em quase todas as áreas da atividade humana
organizada, e na maioria dos países industrializados do mundo. O processo definido por
Nowlan e Heap serviu como base de vários documentos adaptados em que o processo
RCM foi desenvolvido e aperfeiçoado ao longo dos anos seguintes.
A maioria destes documentos conserva os elementos-chave do processo original. No
entanto, o uso generalizado do termo "RCM" levou ao aparecimento de um número de
processos que diferem significativamente do original, mas seus proponentes também
chamam de "RCM". Muitos desses outros processos não conseguem atingir as metas
descritas no relatório de Nowlan e Heap, e alguns são ativamente contraproducentes.
Como resultado, tem havido uma crescente demanda internacional por uma norma que
estabeleça os critérios que qualquer processo deve cumprir, a fim de ser chamado de
"RCM". Este documento atende a essa necessidade.
Os critérios estabelecidos nesta Norma SAE são baseados em conceitos e processos de
RCM presentes em três documentos RCM:
(1) Nowlan e Heap 1978, "Manutenção Centrada em Confiabilidade",
(2) EUA aviação naval da MIL-STD-2173 (AS) ( Centrada em Confiabilidade
Requisitos manutenção de aeronaves Naval, sistemas de armas e equipamentos de
apoio) e seu sucessor, EUA Naval Air Systems Command Manual de Gestão 00-25-403
(Diretrizes para a NavalAviation processo de manutenção Centrada em Confiabilidade),
e
(3) "Manutenção Centrada em Confiabilidade (RCM 2), " John Moubray. Estes
documentos são considerados os mais amplamente aceitos e utilizados documentos
disponíveis de RCM.
Este documento descreve os critérios mínimos que qualquer processo deve cumprir para
ser chamado de "RCM". Ele não tenta definir um processo RCM específico.
Este documento é destinado a qualquer pessoa que deseje verificar se qualquer processo
que pretende ser RCM é de fato RCM. Ele é especialmente útil para as pessoas que
desejam adquirir RCM serviços (formação, análise, facilitação, consultoria, ou qualquer
combinação destes).

1. Escopo - Esta norma SAE para Manutenção Centrada em Confiabilidade (RCM) é


destinada ao uso por toda organização que tem ou faz uso de ativos físicos ou sistemas e
que pretende fazer uma gestão de forma responsável.

1.1 Finalidade - RCM é um processo específico usado para identificar as políticas que
devem ser implementadas para gerenciar modos de falha que podem causar a falha
funcional de qualquer ativo físico em um dado contexto operacional . Este documento
destina-se a ser utilizados para avaliar qualquer processo que pretende ser um processo
RCM, a fim de determinar se é um processo RCM verdadeiro. Este documento suporta

Tradução Livre da Norma SAE JA1011- Exclusivo para uso em sala de aula -1-
IESAM – MBA Engenharia de Manutenção – Professor Wilton Matos Costa

tal avaliação, especificando os critérios mínimos que um processo deve ter para ser um
processo RCM.

2. Referências
2.1.1 SAE PUBLICATIONS— Available from SAE, 400 Commonwealth Drive,
Warrendale, PA 15096-0001.

SAE JA1012— A Guide to Reliability-Centered Maintenance (RCM)

2.1.2 U.S. DEPARTMENT OF COMMERCE PUBLICATIONS— Available from


NTIS, Port Royal Road, Springfield, VA22161
Nowlan, F. Stanley, and Howard F. Heap, “Reliability-Centered Maintenance,”
Department of Defense,
Washington, D.C. 1978. Report Number AD-A066579.

2.1.3 U.S. DEPARTMENT OF DEFENSE PUBLICATIONS— Available from


DODSSP, Subscription Services Desk,
Building 4/Section D, 700 Robbins Avenue, Philadelphia, PA 19111-5098
MIL-STD 2173(AS)— ”Reliability-Centered Maintenance Requirements for Naval
Aircraft, WeaponsSystems and Support Equipment” (U.S. Naval Air Systems
Command)

NAVAIR 00-25-403— ”Guidelines for the Naval Aviation Reliability Centered


Maintenance Process” (U.S.
Naval Air System Command)

MIL-P-24534— ”Planned Maintenance System: Development of Maintenance


Requirement Cards,
Maintenance Index Pages, and Associated Documentation” (U.S. Naval Sea Systems
Command)
S9081-AB-GIB-010/MAINT— ”Reliability-Centered Maintenance Handbook” (U.S.
Naval Sea Systems Command)

2.1.4 INDUSTRIAL PRESS PUBLICATION— Available from Industrial Press, Inc.,


200 Madison Avenue, New York City,
New York, 10016 (also available from Butterworth-Heinemann, Linacre House, Jordan
Hill, Oxford, GreatBritain OX2 8DP).
Moubray, John, “Reliability-Centered Maintenance,” 1997

2.1.5 U.K. MINISTRY OF DEFENCE PUBLICATION— Available from Reliability-


centred Maintenance ImplementationTeam, Ships Support Agency, Ministry of Defence
(Navy), Room 22, Block K, Foxhill, Bath, BA1 5AB UnitedKingdom.
NES 45— Naval Engineering Standard 45. “Requirements for the Application of
Reliability-CentredMaintenance Techniques to HM Ships, Royal Fleet Auxiliaries and
other Naval Auxiliary Vessels”
(Restricted-Commercial)

2.2 Other Publications— The following publications were consulted in the course of
developing this SAETechnical Report and are not a required part of this document.

Tradução Livre da Norma SAE JA1011- Exclusivo para uso em sala de aula -2-
IESAM – MBA Engenharia de Manutenção – Professor Wilton Matos Costa

Anderson, Ronald T. and Neri, Lewis, “Reliability-Centered Maintenance: Management


and EngineeringMethods,” Elsevier Applied Science, London and New York, 1990

Blanchard, B.S., Verma, D., and Peterson, E.L., “Maintainability: A Key to Effective
Serviceability andMaintenance Management,” John Wiley and Sons, New York, 1995

“Dependability Management— Part 3-11: Application Guide— Reliability Centred


Maintenance,”
International Electrotechnical Commission, Geneva, Document No. 56/651/FDIS.

Jones, Richard B., “Risk-Based Management: A Reliability-Centered Approach,” Gulf


PublishingCompany, Houston, TX, 1995

MSG-3. “Maintenance Program Development Document,” Air transport Association,


Washington DC,
Revision 2 1993

“Procedures for Performing a Failure Mode, Effects and Criticality Analysis,”


Department of Defense,
Washington, DC, Military Standard MIL-DTD. 1629A, Notice 2, 1984

“Reliability Centered Maintenance for Aircraft, Engines, and Equipment,” United States
Air Force, MILSTD-1843 (NOTE: Cancelled without Replacement, August 1995)

Smith, Anthony M., “Reliability Centered Maintenance,” McGraw-Hill, New York,


1993

Zwingelstein, G., “Reliability Centered Maintenance, A Practical Guide for


Implementation,” Hermés, Paris, 1996

3. Definições
3.1 Idade - A medida de exposição ao estresse calculado a partir do momento em que
um item ou componente entra em serviço quando novo ou re-entra em serviço após uma
tarefa concebida para restaurar a sua capacidade inicial, e pode ser medido em termos
de tempo de calendário, tempo de funcionamento, distância percorrida, ciclos, ou
unidades de produção ou processamento.
3.2 Tarefa - Uma tarefa que é ao mesmo tempo, tecnicamente viável e vale a pena fazer
(aplicável e eficaz).
3.3 Probabilidade condicional de falha- Probabilidade que uma falha irá ocorrer em
um período específico, desde que o item questão tenha sobrevivido até a mortalidade
infantil.
3.4 Desempenho Desejado- O nível de desempenho desejado pelo proprietário ou
usuário de um ativo físico ou sistema.
3.5 Conseqüências Ambientais - Um modo de falha ou insuficiência múltipla tem
conseqüências ambientais se ele pode violar qualquer norma ambiental ou
regulamentação empresarial, municipal, regional, nacional ou internacional que é
aplicável ao ativo físico ou sistema sob consideração.

Tradução Livre da Norma SAE JA1011- Exclusivo para uso em sala de aula -3-
IESAM – MBA Engenharia de Manutenção – Professor Wilton Matos Costa

3.6 Falha- um modo de falha evidente cujos efeitos tornam-se aparentes para a equipe
operacional sob circunstâncias normais se o modo de falha ocorre por si só.
3.7 Função Evidente- uma função cuja falha em si se torna evidente para a equipe de
operação sob circunstâncias normais.
3.8 Conseqüências da Falha - A(s) maneira(s) na qual os efeitos de um modo de falha
ou falha múltipla se manifestam (evidência de falha, impacto sobre a segurança, o
ambiente, a capacidade operacional, direta e custos de reparação indiretos).
3.9 Efeito da Falha - O que acontece quando um modo de falha ocorre.
3.10 Tarefa de Encontrar a falha (Failure Finding Task)- Tarefa programada
utilizada para determinar se uma falha oculta específica ocorreu.
3.11 Política de Gestão de Falha - termo genérico que engloba as tarefas baseadas na
condição, restauração programada, descarte programado, investigação de falha,
corretiva, gerência de falha, e reprojetos.
3.12 Modo de Falha- Um único evento, que causa uma falha funcional.
3.13 Função- O que o proprietário ou usuário de um ativo físico ou sistema quer que ele
faça.
3.14 Falha Funcional - Estado em que um ativo físico ou sistema é incapaz de executar
uma função especificada a nível desejado de desempenho.
3.15 Falha oculta - modo de falha cujos efeitos não se tornam evidentes para a equipe
operacional sob circunstâncias normais se o modo de falha ocorre por si só.
3.16 Função Oculta - função cuja falha propriamente dita não se torna evidente para a
equipe operacional sob condições normais.
3.17 Capacidade- Nível de desempenho inicial que um ativo físico ou sistema é capaz
de alcançar no momento em que entra em serviço.
3.18- Falha Múltipla - evento que ocorre se uma função protegida falhar enquanto seu
dispositivo de protecção ou protective system está em um estado de falha.
3.19 Consequências não-operacionais - uma categoria de conseqüências de falha que
não afetam negativamente a segurança, o meio ambiente, ou operações, mas apenas
exigem reparação ou substituição de qualquer item (s) que podem ser afetados pela
falha.
3.20 Tarefa baseada em condição -Uma tarefa agendada usada para detectar uma falha
potencial.
3.21 Reprojeto (one-time change) Qualquer medida tomada para mudar a
configuração física de um ativo ou de um sistema (reprojeto ou modificação), para
alterar o método usado por um operador ou mantenedor para realizar uma tarefa
específica, para mudar o contexto operacional do sistema, ou para alterar a capacidade
de um operador ou mantenedor (formação)
3.22 Contexto operacional- circunstâncias em que um ativo físico ou sistema deverá
operar.
3.23 Consequências Operacionais - categoria de conseqüências de falhas que afectam
negativamente a ocapacidade operacional de um ativo físico ou sistema (produção,
qualidade do produto, serviço ao cliente, a capacidade militar, ou custos operacionais,
além do custo do reparo).
3.24 Proprietário - pessoa ou organização que pode sofrer ou ser responsabilizado
pelas consequências de modo de falha em virtude da propriedade do bem ou do sistema.
3.25 Intervalo PF - intervalo entre o momento em que uma falha potencial torna-se
detectável e o ponto no qual se degrada em uma falha funcional (também conhecido
como "período de desenvolvimento da falha" e "tempo de espera para falha.
3.26- Falha Potencial - Condição identificável que indica que uma falha funcional é ou
está prestes a ocorrer ou está no processo de ocorrer.

Tradução Livre da Norma SAE JA1011- Exclusivo para uso em sala de aula -4-
IESAM – MBA Engenharia de Manutenção – Professor Wilton Matos Costa

3.27 Dispositivo de proteção ou sistema de proteção, um dispositivo ou sistema que


se destina a evitar, eliminar, ou minimizar as conseqüências de falha de algum outro
sistema.
3.28 Função (s) - A função (s), que constitue o principal motivo (s) para que um ativo
físico ou sistema iseja adquirido pelo seu proprietário ou usuário.
3.29 Corretiva (Run-to-Failure)- política de gestão de falha que permite um modo de
falha específico para ocorrer sem qualquer tentativa de antecipá-la ou preveni-la
3.30 Consequências de segurança - modo de falha ou ifalha múltipla tem
conseqüências de segurança se ele puder ferir ou matar pessoas.
3.31- Tarefas Programadas- Realizadas em períodos fixos, intervalos pré-
determinados, incluindo "monitoramento contínuo" (onde o intervalo é efetivamente
zero).
3.32 Descarte Programado- tarefa agendada que implica descartar um item em ou
antes de uma idade especificada independentemente de sua condição no momento.
3.33 Restauração Programada - A tarefa programada que restaura a capacidade de um
item em ou antes de um intervalo especificado (limite de idade), independentemente do
seu estado, no momento, para um nível que proporciona uma probabilidade de vida
tolerável ao final de outro intervalo especificado.
3.34 Funções Secundárias- Funções que um ativo físico ou sistema tem de cumprir
além do sua(s) funções primárias, tais como as necessárias para cumprir os requisitos
regulamentares e aqueles que dizem respeito a questões de protação tais como controle,
confinamento, o conforto, a aparência, a eficiência energética e sua integridade
estrutural.
3.35 Usuário- A pessoa ou organização que opera um ativo ou um sistema e pode sofrer
ou ser responsabilizada financeiramente com as conseqüências de um modo de falha do
sistema.

4. Siglas
4.1 RCM - Manutenção Centrada em Confiabilidade

5. RCM - Manutenção Centrada em Confiabilidade - Qualquer processo


RCM devem assegurar que todas as sete perguntas seguintes são respondidas de forma
satisfatória e são respondidas na seqüência apresentada a seguir:

a. Quais são as funções e padrões associados desejados de desempenho do ativo em


seu contexto operacional presente (funções)?
b. De que forma ele pode deixar de cumprir suas funções (falhas funcionais)?
c. O que causa cada falha funcional (modos de falha)?
d. O que acontece quando cada falha ocorre (efeitos de falha)?
e. De que forma cada falha é significativa (conseqüências da falha)?
f. O que deve ser feito para prever ou prevenir cada falha (tarefas pró-ativas e
intervalos de tarefas)?
g. O que deve ser feito se uma tarefa proativa adequada não puder ser encontrada
(ações padrão)?

Para responder a cada uma das perguntas anteriores "de forma satisfatória", informações
necessárias devem ser obtidas, e em seguida decisões devem ser tomadas. Todas as
informações e decisões devem ser documentados de uma forma que faz com que tornem

Tradução Livre da Norma SAE JA1011- Exclusivo para uso em sala de aula -5-
IESAM – MBA Engenharia de Manutenção – Professor Wilton Matos Costa

a informação e as decisões totalmente disponíveis para serem aceitas pelo proprietário


ou usuário do ativo.

5.1 Funções
5.1.1 O contexto operacional do ativo deve ser definido.
5.1.2 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 de proteção).
5.1.3 Todas as declarações de função deve conter um verbo, um objeto, e um padrão de
desempenho (quantificado em cada onde isso pode ser feito).
5.1.4 Os padrões de desempenho incorporados em declarações de função deve ser o
nível de desempenho desejado pelo proprietário ou usuário do ativo / sistema em seu
contexto operacional.
5.2 Falhas funcionais - Todos os estados de falha associados a cada função devem ser
identificados.
5.3 Modos de falha
5.3.1 Todos os modos de falha razoavelmente susceptíveis de causar cada falha
funcional devem ser identificados.
5.3.2 O método usado para decidir o que constitui um modo de falha "razoavelmente
provável" deve ser aceitável para o proprietário ou usuário do ativo.
5.3.3 Os modos de falha deve ser identificados num nível de causa e efeito que faz com
que seja possível identificar uma política de gestão de falha.
5.3.4 Listas de modos de falha deve incluir modos de falha que aconteceram antes,
modos de falha que são impedidas atualmente, programas de manutenção existentes e
modos de falha que ainda não aconteceu, mas mas pensado para ser razoavelmente
provável (possível) no contexto operacional.
5.3.5 Listas de modos de falha deve incluir qualquer evento ou processo que é
susceptível de causar uma falha funcional, incluindo deterioração, defeitos de projeto, e
do erro humano, seja causado por operadores ou mantenedores (a menos que o erro
humano esteja sendo ativamente dirigida por processos analíticos além de RCM) .

5.4 Efeitos de Falha


5.4.1 Efeitos de falha devem descrever o que aconteceria se nenhuma tarefa específica
seja realizada para antecipar, prevenir ou detectar a falha..
5.4.2 Efeitos de falha devem incluir todas as informações necessárias para apoiar a
avaliação das consequências da falha, tais como:
a. Que evidência (se houver) que a falha ocorreu (no caso de funções ocultas, que
podem ocorrer se uma falha múltipla ocorrer)
b. O que fazer (ou nada) para matar ou ferir alguém, ou para ter um efeito adverso sobre
o ambiente
c. O que ele faz (ou nada) para ter um efeito adverso sobre a produção ou operações.
d. Quais são os danos físicos (se houver) causados pela falha
e. O que (se houver) deve ser feito para restaurar a função do sistema após a falha

5.5 Categorias de Consequência de falha


5.5.1 As conseqüências de cada modo de falha devem ser formalmente categorizadas
como segue:
5.5.1.1 O processo de categorização conseqüência deve separar os modos de falha
ocultos de modos de falha evidentes.

Tradução Livre da Norma SAE JA1011- Exclusivo para uso em sala de aula -6-
IESAM – MBA Engenharia de Manutenção – Professor Wilton Matos Costa

5.5.1.2 O processo de categorização de conseqüência deverá distinguir claramente


eventos (modos de falha e multiple failures), que têm segurança e / ou consequências
ambientais daqueles que só tem conseqüências econômicas (consequências operacionais
e não-operacionais).
5.5.2 A avaliação das conseqüências de falha deve ser realizado como se nenhuma
tarefa específica está sendo feita atualmente para antecipar, prevenir ou detectar a falha.

5.6 Seleção da Política de Gestão da Falha


5.6.1 A seleção do processo de gestão da falha deve levar em conta o fato de que
probabilidade condicional de alguns modos de falha de irá aumentar com a idade (ou a
exposição ao stress), que a probabilidade condicional de outros não irão mudar com a
idade, e a probabilidade condicional de ainda outros irão diminuir com a idade.
5.6.2 Todas as tarefas agendadas devem ser tecnicamente viáveis e vale a pena fazer
(aplicável e eficaz), e o significado para atendimento deste requisito constam no item
5.7.
5.6.3 Se duas ou mais propostas de políticas de gestão de falha são tecnicamente viáveis
e valem a pena fazer (aplicável e efetivas), a política que é mais rentável será escolhida.
5.6.4 A seleção de políticas de gestão de falha deve ser realizada como se nenhuma
tarefa específica está sendo feita para antecipar, prevenir ou detectar a falha.

5.7 Políticas de Gestão de Falha - Tarefas Agendadas


5.7.1 Todas as tarefas agendadas devem cumprir os seguintes critérios:
5.7.1.1 No caso de um modo de falha evidente que tem conseqüências ambientais ou de
segurança, a tarefa é reduzir a probabilidade de o modo de falha para um nível que é
tolerável para o utilizador ou proprietário do bem.
5.7.1.2 No caso de um modo de falha oculto no qual a falha múltipla associada tem
segurança ou conseqüências ambientais, a tarefa deve reduzir a probabilidade de o
modo de falha escondida de um modo que a probabilidade da falha seja reduzida a um
nível que é tolerável para o proprietário ou usuário do ativo.
5.7.1.3 No caso de um modo de falha evidente que não tem consequências desegurança
ou ambientais, os custos indiretos e indiretos de fazer a tarefa será menos do que os
custos diretos e indiretos do modo de falha, quando medido ao longo de períodos
comparáveis de tempo.
5.7.1.4 No caso de um modo de falha escondido onde a falha associada múltipla não
tem conseqüências de segurança ou ambiental, os custos diretos e indiretos de fazer a
tarefa deve ser menos do que os custos indiretos e diretos da falha múltipla, mais o
custo da reparação dos modos de falha oculta quando medidos em períodos comparáveis
de tempo.
5.7.2 Tarefas baseadas na Condição (ON-CONDITION TASKS), qualquer tarefa
baseada em avaliação da condição (ou preditiva ou baseada nas condições ou a tarefa de
monitoramento de condição) que está selecionado deve satisfazer os seguintes critérios
adicionais:
5.7.2.1 Deve existir uma falha potencial claramente definida.
5.7.2.2 Deve existir um intervalo PF identificável (ou período de desenvolvimento
falha).
5.7.2.3 O intervalo de tarefa deve ser menor que o menor intervalo PF provável.
5.7.2.4 Deve ser fisicamente possível fazer a tarefa em intervalos menores do que o
intervalo PF.
5.7.2.5 O menor tempo entre a detecção de uma falha potencial e a ocorrência da falha
funcional (o intervalo PF menos o intervalo de tarefas) deve ser suficientemente longo

Tradução Livre da Norma SAE JA1011- Exclusivo para uso em sala de aula -7-
IESAM – MBA Engenharia de Manutenção – Professor Wilton Matos Costa

para a acção pré-determinada para ser tomada para evitar, eliminar ou minimizar as
consequências do modo de falha.
5.7.3 Tarefas Programadas de Descarte (SCHEDULED DISCARD TASKS)-Qualquer
tarefa agendada de descarte programado que está selecionado deve satisfazer os
seguintes critérios adicionais:
5.7.3.1 Deve haver uma idade claramente definida (de preferência demonstrável) em
que há um aumento na probabilidadecondicional do modo de falha sob consideração.
5.7.3.2 Uma proporção suficientemente grande de ocorrências deste modo de falha deve
ocorrer após essa idade para reduzir a probabilidade de falha prematura a um nível que é
tolerável ao proprietário ou usuário do ativo.
5.7.4 Tarefas de Recuparação Programada (SCHEDULED RESTORATION TASKS)-
qualquer recuperaçãoagendada que está selecionado deve satisfazer os seguintes
critérios adicionais:
5.7.4.1 Haverá uma idade claramente definida (de preferência demonstrável) em que há
um aumento na probabilidade de condicional do modo de falha sob consideração.
5.7.4.2 Uma proporção suficientemente grande de ocorrências deste modo de falha deve
ocorrer após essa idade para reduzir a probabilidade de falha prematura a um nível que é
tolerável ao proprietário ou usuário do ativo.
5.7.4.3 A tarefa deve restaurar a resistência à falha (condição) do componente a um
nível que é tolerável para o propietário ou usuário do ativo.
5.7.5 TAREFAS DE BUSCA DE FALHA (FAILURE-FINDING TASKS)-Qualquer
tarefa de busca de falha, que é selecionado deverá satisfazer os seguintes critérios
adicionais (failure-finding não se aplica aos modos de falha evidentes):
5.7.5.1 A base sobre a qual o intervalo de tarefa é seleccionado deve ter em conta a
necessidade de reduzir a probabiidade da falha múltipla do sistema protegido associado
a um nível que é tolerável para o proprietário ou usuário do ativo.
5.7.5.2 A tarefa deve confirmar que todos os componentes abrangidos pela descrição do
modo de falha são funcionais.
5.7.5.3 A tarefa de busca de falha processo de seleção associado intervalo deve levar em
conta qualquer probabilidade de que a tarefa em si pode deixar a função escondida em
um Estado de falha.
5.7.5.4 Deve ser fisicamente possível fazer a tarefa em intervalos especificados.

5.8 Gestão de Políticas de falha - Reprojetos e corretivas


5.8.1 Reprojetos
5.8.1.1 O processo RCM devem esforçar-se para extrair o desempenho desejado do
sistema como ele é atualmente configurado e operado pela aplicação apropriadas das
tarefas programadas.
5.8.1.2 Nos casos em que tais tarefas não pudedem ser encontradas, reprojetos para o
ativo ou sistema podem ser necessários,
sujeitos aos os seguintes critérios.
5.8.1.2.1 Nos casos em que a falha está escondida, e a múltipla falha associada tem
consequências nasegurança ou ambientais, o reprojeto que reduz a probabilidade de
múltiplas falhas a um nível tolerável ao proprietário ou usuário do ativo é obrigatório .
5.8.1.2.2 Nos casos em que o modo de falha é evidente e tem consequências segurança
ou ambientais, o reprojeto que reduz a probabilidade do modo de falha a um nível
tolerável ao proprietário ou usuário do ativo é obrigatória.
5.8.1.2.3 Nos casos em que o modo de falha está escondido, e a falha múltipla associada
não ter consequências de segurança ou ambientall, qualquer reprojeto deve ser
financeiramente atrativa na opinião do opropietário ou usuário do ativo.

Tradução Livre da Norma SAE JA1011- Exclusivo para uso em sala de aula -8-
IESAM – MBA Engenharia de Manutenção – Professor Wilton Matos Costa

5.8.1.2.4 Nos casos em que o modo de falha é evidente e não tem consequências de
segurança ou ambientais, qualquer alteração de uma só vez deve ser financeiramente
vantajosa na opinião do proprietário ou usuário do ativo.
5.8.2 Corretiva (RUN-TO-FAILURE)-Qualquer política degestão de corretiva deve
satisfazer o critério adequado, como segue:
5.8.2.1 Nos casos em que a falha está escondida e não há tarefa apropriada
programada,e as falhas associadas não terão segurança consequências ou ambientais.
5.8.2.2 Nos casos em que a falha é evidente e não há tarefa apropriada programada, o
modo de falha associado não deve ter consequência na segurança ou ambientais.

5.9 Um Programa Vivo


5.9.1 Este documento reconhece que (a) grande parte dos dados utilizados na análise
inicial são inerentemente imprecisos, e que os dados mais precisos serão
disponibilizados com o tempo, (b) o modo pelo qual o ativo é utilizado, juntamente com
expectativas de desempenho associadas, também mudará com o tempo, e (c) a
tecnologia de manutenção continua evoluindo. Assim, uma revisão periódica é
necessária se o programa de gerenciamento de RCM-derivado de ativos deve garantir
que os ativos continuam a cumprir as expectativas atuais funcionais de seus
proprietários e usuários.
5.9.2 Portanto, qualquer processo RCM deve prever uma revisão periódica de ambos a
informação utilizada para apoiar as decisões e as próprias decisões. O processo utilizado
para realizar tal revisão deve assegurar que as sete questões da Seção 5 continuam a ser
respondidas satisfatoriamente e de forma consistente com o critério estabelecido em 5.1
até 5.8.
5.10 Fórmulas Matemáticas e Estatísticas
5.10.1 Quaisquer fórmulas matemáticas e estatísticas que são utilizadas na aplicação do
processo (especialmente aquelas usadas para calcular os intervalos de quaisquer tarefas)
devem ser logicamente robustas, e deve estar disponível para aprovação pelo
proprietário ou usuário do ativo.

Seção de Referência
SAE JA1012— A Guide to Reliability-Centered Maintenance (RCM)

Nowlan, F. Stanley, and Howard F. Heap, “Reliability-Centered Maintenance,”


Department of Defense,
Washington, D.C. 1978. Report Number AD-A066579.

MIL-STD 2173(AS)— ”Reliability-Centered Maintenance Requirements for Naval


Aircraft, WeaponsSystems and Support Equipment” (U.S. Naval Air Systems
Command)

NAVAIR 00-25-403— ”Guidelines for the Naval Aviation Reliability Centered


Maintenance Process” (U.S.
Naval Air Systems Command)

MIL-P-24534— ”Planned Maintenance System: Development of Maintenance


Requirement Cards,

Tradução Livre da Norma SAE JA1011- Exclusivo para uso em sala de aula -9-
IESAM – MBA Engenharia de Manutenção – Professor Wilton Matos Costa

Maintenance Index Pages, and Associated Documentation” (U.S. Naval Sea


SystemsCommand)

S9081-AB-GIB-010/MAINT— ”Reliability-Centered Maintenance Handbook” (U.S.


Naval Sea Systems
Command)

Moubray, John, “Reliability-Centered Maintenance,” 1997

NES 45— Naval Engineering Standard 45. “Requirements for the Application of
Reliability-CentredMaintenance Techniques to HM Ships, Royal Fleet Auxiliaries and
other Naval AuxiliaryVessels” (Restricted-Commercial)

Anderson, Ronald T. and Neri, Lewis, “Reliability-Centered Maintenance: Management


and EngineeringMethods,” Elsevier Applied Science, London and New York, 1990

Blanchard, B.S., Verma, D., and Peterson, E.L., “Maintainability: A Key to Effective
Serviceability andMaintenance Management,” John Wiley and Sons, New York, 1995

“Dependability
Management— Part 3-11: Application Guide— Reliability Centred Maintenance,”
International Electrotechnical Commission, Geneva, Document No. 56/651/FDIS.

Jones, Richard B., “Risk-Based Management: A Reliability-Centered Approach,” Gulf


PublishingCompany, Houston, TX, 1995

MSG-3. “Maintenance Program Development Document,” Air transport Association,


Washington DC,
Revision 2 1993

“Procedures for Performing a Failure Mode, Effects and Criticality Analysis,”


Department of Defense,
Washington, DC, Military Standard MIL-DTD. 1629A, Notice 2, 1984

“Reliability Centered Maintenance for Aircraft, Engines, and Equipment, United States
Air Force,” MILSTD-
1843 (NOTE: Cancelled without Replacement, August 1995)

Tradução Livre da Norma SAE JA1011- Exclusivo para uso em sala de aula -10-
IESAM – MBA Engenharia de Manutenção – Professor Wilton Matos Costa

SAE JA1011 Issued AUG1999

Smith, Anthony M., “Reliability Centered Maintenance,” McGraw-Hill, New York,


1993

Zwingelstein, G., “Reliability Centered Maintenance, A Practical Guide for


Implementation,” Hermés,
Paris, 1996

Developed by the SAE G11 Reliability Centered Maintenance (RCM) Subcommittee


Sponsored by the SAE G11 Supportability Committee

Tradução Livre da Norma SAE JA1011- Exclusivo para uso em sala de aula -11-
IESAM – MBA Engenharia de Manutenção – Professor Wilton Matos Costa

Tradução Livre da Norma SAE JA1011- Exclusivo para uso em sala de aula -12-

Você também pode gostar