Documentos de Académico
Documentos de Profesional
Documentos de Cultura
NORMA
SAE JA1011 EDITADA AGO 1999 Editada 1999-08
El criterio en esta Norma SAE está basado en el proceso RCM y conceptos de tres documentos
RCM: 1) Nowlan and Heap´s 1978 book, “Reliability – Centered Maintenance”, 2) US naval
aviation´s MIL – STD – 2173(AS) (Reliability – Centered Maintenance Requirements of naval
Aircraft, Weapons Systems and Support Equipment) y su sucesor, U.S. Naval Air Systems
Command Management Manual 00-25-403 (Líneas Guía para el Naval Aviation Reliability –
Centered Maintenance Process) y 3) “Reliability - Centered Maintenance (RCM 2)” por John
Moubray. Estos documentos están dictaminados a ser los más ampliamente aceptado y
ampliamente utilizado como documentos RCM disponibles.
Este documento describe el criterio mínimo que cualquier proceso debe cumplir para ser
llamado “RCM”. Esto no intenta definir un proceso RCM específico.
Este documento está destinado para cualquiera que desee cerciorarse si cualquier proceso que
pretenda ser RCM sea de hecho un RCM. Esto es especialmente útil a personas que deseen
comprar servicios RCM (análisis, entrenamiento,ejecución de estos servicios, recursos,
consultas o combinación de éstos).
1
El Panel Técnico de Normas y Reglas SAE condiciona que: “Este reporte es publicado por
SAE para avanzar en la situación de las ciencias técnicas y de ingeniería. El uso de este
reporte es enteramente voluntario y su aplicación y su conformidad para cualquier uso
particular, incluyendo cualquier infracción de patente, es solamente responsabilidad del
usuario”.
SAE revisa cada reporte técnico al menos cada cinco años en el cual puede reafirmarse, revisarse o
cancelarse. SAE le invita a escribirle sus observaciones y sugerencias.
2
TABLA DE CONTENIDOS
1. Alcance 3
1.1 Propósito 3
2. Referencias 3
2.1 Publicaciones afines 3
2.1.1 Publicaciones SAE 4
2.1.2 Publicaciones del Ministerio de Comercio de Estados Unidos 4
2.1.3 Publicaciones del Ministerio de Defensa de Estados Unidos 4
2.1.4 Publicación de la Prensa Industrial 4
2.1.5 Ministerio de Defensa del Reino Unido 4
2.2 Otras Publicaciones 4
3. Definiciones 5
4. Acrónimos 7
6. Notas 12
6.1 Palabras Claves 12
1. Alcance- Esta Norma SAE para Mantenimiento Centrado en la Confiabilidad (RCM) está
proyectado para utilizarse por cualquier organización que tiene o hace uso de recursos o
sistemas físicos donde se requiere responsabilidad en su dirección.
1.1. Propósito- RCM es un proceso específico utilizado para identificar políticas que van a ser
implementadas para manejar modos de fallo lo cual causaría la falla funcional de cualquier
recurso físico en un contexto de operación dado. Este documento está proyectado para
utilizarse en la evaluación de cualquier proceso que pretenda ser un proceso RCM, con el
propósito de determinar si es un verdadero proceso RCM. Este documento se comporta como
una evaluación por la especificación del criterio mínimo que un proceso debe tener para ser
verdaderamente un proceso RCM.
2. Referencias
3
2.1.1 PUBLICACIONES SAE- Disponible en SAE, 400 Commonwealth Drive Warrendale,
PA 15096-0001.
2.2 Otras Publicaciones – Las siguientes publicaciones fueron consultadas en el curso del
desarrollo de este Reporte Técnico SAE y no son parte requerida de este documento.
4
3. Definiciones
3.1 Edad- Una medida de exposición al estrés computado desde el momento que un artículo o
componente entra en servicio cuando entra o re – entra en servicio luego de una tarea
diseñada para restaurar su capacidad inicial, pudiendo ser medida en términos de tiempo
calendario, tiempo de corrida, distancia viajada, ciclos de servicio, o unidades de salida o de
principio a fin.
3.2 Tarea Apropiada- Tarea que técnicamente es factible y que merece la pena hacerla
(aplicable y efectiva).
3.6 Falla Evidente- Tipo de fallo cuyos efectos se hacen evidentes en la operación del equipo
bajo circunstancias normales y el tipo de fallo ocurre en el propio equipo.
3.7 Función Evidente- La función en un equipo bajo circunstancias normales cuyo fallo
ocurre evidentemente en la operación del mismo.
3.8 Consecuencias de Fallo- Tema sobre el (los) comportamiento por los efectos del modo de
fallo o fallas múltiples (evidencia de fallo, impacto en la seguridad, el ambiente, capacidad
operacional, costos de reparación directos e indirectos).
3.10 Tarea de búsqueda de Fallos- Una tarea programada para determinar si ha ocurrido una
falla oculta.
3.13 Función- Lo que desea hacer el propietario o usuario de un recurso o sistema físico.
3.14 Fallo Funcional- Un estado en el cual un recurso o sistema físico no es capaz de ejecutar
una función específica a un nivel de desempeño deseado.
3.15 Fallo Oculto- Un modo de fallo cuyos efectos bajo circunstancias normales no llegan a
hacerse evidentes en la operación del equipo si el modo de fallo ocurriera en el mismo.
3.16 Función Oculta- Una función cuyo fallo bajo circunstancias normales en el equipo no
resulta evidente en la operación del mismo.
5
3.17 Capacidad Inicial- El nivel de desempeño que un recurso o sistema físico es capaz de
alcanzar en el momento de que él entre en servicio.
3.18 Fallo Múltiple- Un evento que ocurre si una función protegida falla mientras su
dispositivo o sistema protector está en estado de fallo.
3.20 Tarea a Condición- Una tarea programada para detectar un fallo potencial.
3.21 Cambio Una Vez- Cualquier acción tomada para cambiar la configuración física de
recursos o sistema (rediseño o modificación), cambiar el método utilizado por un operador o
mantenedor para ejecutar una tarea específica, cambiar el contexto de operatividad del
sistema, o cambiar la capacidad de un operador o mantenedor (adiestramiento).
3.22 Contexto operativo- Las circunstancias en las cuales se espera que trabaje un recurso o
sistema físico.
3.23 Consecuencias Operacionales- Una categoría de consecuencias por fallo que afecta
negativamente la capacidad operacional de un recurso o sistema físico (salida, calidad del
producto, servicio al cliente, capacidad militar o costos de operatividad en adición al costo de
reparar).
3.24 Propietario- Una persona u organización que puede sufrir o ser responsable por las
consecuencias de un modo de fallo en virtud de la propiedad de un equipo o sistema.
3.25- Intervalo P-F – El intervalo entre el punto en el cual un fallo potencial deviene
detectable y el punto al cual degrada a una falla funcional (también conocido como “periodo
de desarrollo de fallo” y (tiempo principal de fallo).
3.26 Fallo Potencial- Una condición identificable la cual indica que una falla funcional está
cercana a ocurrir o está en proceso de que ocurra.
3.28 Función(es) Primaria(s)- La(s) Función(es) la(s) cual(es) constituye(n) la(s) principal(es)
razón(es) por qué un elemento o sistema físico es adquirido por su propietario o usuario.
3.29 Correr hasta la Falla- Política de manejar un fallo que permita que ocurra un modo de
fallo específico sin ningún intento de detectarlo o prevenirlo.
3.32 Sustitución Programada- Una tarea programada que ocasiona eliminar un elemento
antes de un límite de tiempo especificado independiente de su condición en ese instante.
6
3.33 Restauración de lo Programado- Una tarea programada que restaura la capacidad de un
elemento a o antes de un intervalo especificado (límite de edad), independiente de su condición
en ese instante, a un nivel que proporciona una probabilidad tolerable de sobrevivir al final
de otro intervalo especificado.
3.34 Funciones Secundarias- Funciones, que un equipo o sistema físico tiene que cumplir
aparte de su función(es) primaria(s), tales como esas necesitadas para cumplir requerimientos
regulatorios y las que conciernen a ediciones tales como protección, control, contenido,
comodidad, apariencia, eficiencia energética e integridad estructural.
3.35 Usuario- Una persona u organización que opera un equipo o sistema pudiendo sufrir o
ser responsable por las consecuencias de un modo de fallo de ese sistema.
4. Acrónimos
a. ¿Cuáles son las funciones y normas asociadas deseadas de desempeño del recurso en su
contexto de operación actual (funciones)?
b. ¿En cuáles modos puede fallar el cumplimiento de sus funciones (fallos funcionales)?
c. ¿Qué causa cualquier fallo funcional (modos de fallo)?
d. ¿Qué sucede cuando ocurre cada fallo (efectos del fallo)?
e. ¿En cuál modo ocurre cada fallo (consecuencias del fallo)?
f. ¿Que se haría para pronosticar o prevenir cada fallo (tareas proactivas e intervalos de
g. ¿Qué
tarea)?se haría si una tarea proactiva apropiada no pudiera encontrarse (acciones
implícitas)?
Para responder “satisfactoriamente” cada una de las preguntas previas se recogerá la
siguiente información y realizadas las siguientes decisiones. Toda información y decisiones
serán documentadas de modo que conforme la información y decisiones totalmente
disponibles, aceptadas por el propietario o usuario del recurso.
5.1 Funciones
5.1.2 Todas las funciones del recurso / sistema serán identificadas (todas las funciones
primarias y secundarias, incluyendo las funciones de todos los dispositivos protectores.
5.1.3 Todas las declaraciones de función contendrán un verbo, un objeto y una norma de
ejecución (cuantificado en cada caso donde pueda ser hecho).
5.1.4 Las normas de ejecución incorporadas en las declaraciones de función, tendrán el nivel
de ejecución en su contexto de operación deseado por el propietario o usuario del sistema /
recurso.
5.2 Fallos Funcionales- Serán identificados todos los estados de fallo asociados con cada
función.
7
5.3 Modos de Fallo
5.3.1 Serán identificados todos los modos de fallo que sean la causa probable de cada fallo
funcional.
5.3.2 El método de costumbre para decidir que constituye un “probable” modo de fallo será
aceptable para el propietario o usuario del recurso.
5.3.3 Un modo de fallo será identificado a un nivel causal tal que haga posible identificar una
política apropiada de manejo del fallo.
5.3.4 Las listas de modos de fallo incluirán modos de fallo que hayan ocurrido anteriormente,
modos de fallo que estén actualmente siendo prevenidos por programas de mantenimiento
existentes y modos de fallo que no hayan sucedido todavía pero que se ha pensado sea
probable (creíble) en el contexto de operación.
5.3.5 Las lista de modo de fallos incluirá cualquier evento o proceso que sea probablemente la
causa de un fallo funcional, incluyendo el deterioro, efectos de diseño y error humano causado
por operadores o mantenedores (a menos que el error humano esté siendo activamente
dirigido por un proceso analítico aparte del RCM).
5.4.1 Los efectos por fallo describirán que sucedería para anticipar, prevenir o detectar el
fallo al ejecutarse una tarea no específica.
5.4.2 Los efectos fallo incluirán toda la información necesaria para apoyar la evaluación de las
consecuencias del fallo, tales como:
a. Qué evidencia (cualquiera) que el fallo haya ocurrido (en el caso de funciones ocultas,
que sucedería si ocurriera un fallo múltiple)
b. Qué hace (cualquier cosa) para matar o dañar a alguien, o tener un efecto adverso en el
ambiente
c. Qué hace (cualquier cosa) para tener un efecto adverso en la producción o las
d. Qué
operaciones
daño físico (cualquiera) causa el fallo
e. Qué (cualquier cosa) debe hacerse para restaurar la función del sistema luego del fallo
5.5.1 Las consecuencias de cada modo de fallo serán formalmente categorizadas como sigue:
5.5.1.1 El proceso de categorización de consecuencia separará los modos de fallo oculto de los
modos de fallo evidente.
5.5.2 La valoración de las consecuencias del fallo será llevado a cabo como si una tarea no
específica se haya hecho vigente para anticipar, prevenir o detectar el fallo.
8
5.6 Selección de la Política de Administración de Fallo
5.6.2 Todas las tareas programadas será técnicamente factibles y valga la pena hacerla
(aplicable y efectiva) y los medios por los cuales este requerimiento será satisfecho están en
5.7.
5.6.3 Si dos o más políticas propuestas de administración de fallos son técnicamente factibles y
vale la pena hacerlas (aplicable y efectiva), se seleccionará la política del mejor costo eficaz.
5.6.4 La selección de políticas de administración de fallo se llevará a cabo como si una tarea no
específica se haya hecho vigente para anticipar, prevenir o detectar el fallo.
5.7.1.2 En el caso de un modo de fallo oculto donde el fallo múltiple asociado ha tenido
consecuencias de seguridad o en el ambiente, la tarea reducirá la probabilidad del modo de
fallo oculto a una extensión la cual reduce la probabilidad de fallo múltiple asociado a un nivel
tolerable por el propietario o usuario del recurso.
5.7.1.4 En el caso de un modo de fallo oculto donde la falla múltiple asociada no tenga
consecuencias de seguridad o ambiental, los costos directos e indirectos de realizar esa tarea,
serán menores que los costos directos e indirectos del fallo múltiple más el costo de reparar el
modo fallo oculto cuando se mida con periodos comparables de tiempo.
5.7.2.3 El intervalo de tarea será menor que el intervalo P – F más corto probable.
5.7.2.4 Será físicamente posible hacer la tarea a intervalos menores que el intervalo P – F.
9
5.7.2.5 El tiempo más breve el descubrimiento de un fallo potencial y la ocurrencia de un fallo
funcional (el intervalo P – F menos el intervalo de tarea) será lo suficientemente
grande para que sea tomada la acción predeterminada para evitar, eliminar o
minimizar las consecuencias del modo de fallo.
5.7.3.1 Será una edad claramente definida (preferentemente una demostrable) a la cual hay
un aumento en la condición de probabilidad de un modo fallo bajo consideración.
5.7.3.2 Una proporción suficientemente grande de las ocurrencias de este modo de fallo
ocurrirá luego de esta edad para reducir la probabilidad de falla prematura a un nivel
tolerable para el propietario o usuario del recurso.
5.7.4.1 Habrá una claramente definida (preferentemente demostrable) edad a la cual hay un
incremento en la probabilidad condicional del modo fallo bajo consideración.
5.7.4.2 Una proporción suficientemente grande de las ocurrencias de este modo de fallo
ocurrirá luego de esta edad para reducir la probabilidad de falla prematura a un nivel
tolerable para el propietario o usuario del recurso.
5.7.5.1 Las bases a las cuales se selecciona el intervalo de tarea tomarán en cuenta la necesidad
de reducir la probabilidad de fallo múltiple del sistema protegido asociado a un nivel
tolerable por el propietario o usuario del recurso.
5.7.5.2 La tarea confirmará que todos los componentes abarcados por la descripción del modo
fallo sean funcionales.
10
5.8 Políticas de Administración de Fallo – Cambios de Una Vez y Corrida a Fallo
5.8.1.1 El proceso RCM se esforzará por extraer el desempeño deseado del sistema puesto que
está generalmente configurado y operado por tareas programadas aplicadas
apropiadamente.
5.8.1.2 En los casos donde tales tareas no se encuentren, puede necesitarse de los cambios de
una vez para los sistemas o recursos estando sujetos al siguiente criterio.
5.8.1.2.1 En los casos donde el fallo está oculto y el fallo múltiple asociado ha tenido
consecuencias para la seguridad o el ambiente, es obligatorio el cambio de una vez que
reduce la probabilidad de un fallo múltiple a un nivel tolerable por el propietario o
usuario del recurso.
5.8.1.2.2 En los casos donde el modo fallo es evidente y tiene consecuencias de seguridad y
ambiente, es obligatorio el cambio de una vez pues reduce la probabilidad del modo
fallo a un nivel tolerable por el propietario o usuario del recurso.
5.8.1.2.4 En los casos donde el modo fallo es evidente y no tiene consecuencias en la seguridad
o el ambiente, cualquier cambio de una vez debe ser de un costo – eficaz en la opinión
del propietario o usuario del recurso.
5.8.2 CORRER HASTA EL FALLO - Cualquier política correr hasta el fallo que sea
seleccionada satisfará le criterio apropiado como sigue:
5.8.2.1 En los casos donde la falla esté oculta y no haya una tarea programada apropiada, la
falla múltiple asociada no tendrá consecuencias en la seguridad o el ambiente.
5.8.2.2 En los casos donde la falla es evidente y no hay una tarea programada apropiada, el
modo fallo asociado no tendrá consecuencias en la seguridad o el ambiente.
5.9.1 Este documento reconoce que (a) muchos de los datos utilizados en el análisis inicial son
inherentemente imprecisos, con el tiempo estarán disponibles más datos precisos, (b) el
modo en que se utilice al recurso, junto con las expectativas en el desempeño asociado,
también cambiarán con el tiempo, por último (c) la tecnología del mantenimiento
continúa su desarrollo. Por eso es necesario una revisión periódica si el programa de
dirección de recurso RCM – derivado es para asegurar que los recursos continúen
cumpliendo totalmente con las expectativas funcionales de sus propietarios y usuarios.
5.9.2 Por lo tanto cualquier proceso RCM proporcionará una revisión periódica tanto de la
información utilizada para ayudar en las decisiones así como de las decisiones en sí
mismas. El proceso realizado para conducir tal como una revisión asegurará que todas
las siete preguntas en la Sección 5 sea contestada satisfactoriamente y en un modo
consistente con el criterio expresado desde 5.1 hasta 5.8.
11
5.10 Fórmulas Estadística y Matemática
5.10.1 Cualquiera de las fórmulas estadística y matemática que son utilizadas en la aplicación
del proceso (especialmente esos que suelen computar los intervalos de cualquier tarea)
serán lógicamente consistente, estarán disponibles y aprobados por el usuario o
propietario del recurso.
6. Notas
12
Razón— No aplicable.
Sección de Referencia
13