Proyecto de Soporte para Decisiones de Mantenimiento en Orica

IV RECOLECCIÓN & EVALUACIÓN DE INFORMACIÓN

La frase ”basura que entra es igual a basura que sale” no podría ser mas aplicable refiriéndose a intentar analizar información usando una herramienta de software de análisis de confiabilidad. Con análisis basado en PHM, la calidad de la información es de gran importancia ya que se pretende usar los resultados del análisis de manera cotidiana para la toma de decisiones prácticas.

El usuario del software debe conocer bastante bien el equipo sometido a análisis, sus modos de falla, y las variables monitoreadas que probablemente sean factores influyentes que reflejen el deterioro de modos de falla. El software confirma o refuta tales supuestos utilizando computación intensiva basada en técnicas estadísticas. Si la hipótesis de que una variable CM es significativa se confirma (no es rechazada al nivel de importancia de 5%) por el software, el ingeniero de confiabilidad obtendrá una relación probabilística entre:

  1. Variables importantes,
  2. Edad de trabajo, y
  3. Probabilidad de falla de componente.

Posteriormente, el método aplica un algoritmo “predictivo” [1] en combinación con el PHM para generar un modelo de Estimativo de Vida Útil Remanente (RULE). Una vez desarrollado y aceptado, el modelo será desplegado como un agente “vigilante” que silenciosamente escanea la información de monitoreo de condiciones a medida que esta aparece en sitios designados de la base de datos. El agente escribe los resultados en una tabla de la base de datos accesible al Ingeniero de Confiabilidad y al Gerente de Mantenimiento a través del sistema normal de reportes CMMS.

A. Información sobre fallas

En las instalaciones de Laverton, el CMMS es usado para crear ordenes de trabajo, expedir formatos de permiso de trabajo y reportar historia de fallas de equipos. Los campos disponibles para ser diligenciados en el cierre de las ordenes de trabajo incluyen “observaciones, causa, componentes y comentarios”. El proceso de extracción de información para las bombas encontró comentarios que iban desde frases generales tales como “retirado-dañado” hasta observaciones como “OK”. En muchos casos no se intentaba identificar los modos o causas de fallas (ej. Operar la bomba en seco, o cavitación) ni diferenciar entre una falla potencial y una suspensión. En Orica enfatizamos que los técnicos no tenían la culpa por tales “brechas” de comunicación. Los entrenadores de CMMS se enfocaron en la mecánica de manipular el software en lugar de motivar estilos precisos de expresión de Mantenimiento Centrado en Confiabilidad (RCM) de las observaciones de campo, tornándolas en descripciones legibles de las condiciones de los equipos como fueron encontrados. Como resultado de esto, y debido al orgullo que los técnicos tienen en su trabajo, sus textos de comentario incluían mayormente descripciones de “que hice” y muy pocas descripciones de “que encontré”. Obviamente, ambas son requeridas para Análisis de Confiabilidad.

Por lo tanto, la información disponible en CMMS no era la apropiada para cargarla directamente en el software de análisis de confiabilidad. Se encontraron dos obstáculos. En primer lugar, la estructura de la información de CMMS no es la que se necesita para generar una muestra. Una muestra de ciclos de vida (discriminar entre terminación-por-falla y terminación-por-suspensión) es necesaria antes de poder realizar análisis de confiabilidad. El problema fue resuelto de manera relativamente fácil usando algoritmos de mapeo y transformación de información (ilustrados en la Figura 5).

Figura 5 Transformación de información de CMMS en una Muestra para Análisis de Confiabilidad

En razón a que una muestra es una recopilación de ciclos de vida es imposible desarrollar una muestra directamente desde la representación estructural de historia de órdenes de trabajo del CMMS. La Figura 5 arriba indica que la información en el CMMS debe ser transformada a una estructura en la cual los ciclos de vida son identificables y susceptibles de ser contados. Los ciclos de vida en la muestra, tanto los terminados como los parciales (suspendidos), deben ser contabilizados por el procedimiento o software de análisis de confiabilidad. Adicionalmente, la mejor manera de asegurar una muestra no-sesgada es seleccionar dos puntos en tiempo calendario que definan la ventana de la muestra. Uno selecciona el ancho de la ventana de tal manera que haya un número suficiente de ciclos de vida para el análisis. El término suficientes depende de varios factores, uno de los cuales es cuan estrechamente la información de monitoreo de condiciones refleja el verdadero estado de un determinado modo de falla. Variables externas que reflejan el contexto de operación dentro de poblaciones estadísticas mixtas también deben ser identificadas y contabilizadas en el modelo.

The second obstacle, on the other hand, is far more daunting. In some cases it was difficult to determine if the pump had failed or if the work order represented a suspension. Mistaking a suspension for a failure will mislead the analysis and modelling into mistakenly associating preventive repair with failure. That is, the model will “try” to correlate values of condition monitoring variables occurring at a time when the component is actually in good condition, with a failure event. This will have the effect of introducing scatter (i.e. lowering confidence) in the model’s predictive capability.

De otra parte, el segundo obstáculo es mucho más desalentador. En algunos casos resultaba difícil determinar si la  bomba había fallado o si la orden de trabajo representaba una suspensión. Equivocar una suspensión con una falla confundirá el análisis y el modelaje, haciendo que se asocien de manera errónea las reparaciones preventivas con las fallas. Es decir, el modelo “intentará” correlacionar valores de variables de monitoreo de condiciones que ocurran en un momento en el cual el componente está realmente en buenas condiciones, con un evento de falla. Esto tendrá el efecto de introducir dispersión (ej. reducir la confianza) en la capacidad de predicción del modelo.

Por lo tanto, el requisito más básico de información para análisis de confiabilidad (Weibull, PHM, y la mayoría de los otros) es diferenciar entre fallas y suspensiones al reportar las condiciones encontradas para cada modo de falla significativo encontrado durante la ejecución de una orden de trabajo.

B. Edad de Trabajo

La edad de trabajo del equipo es importante en todo estudio de confiabilidad. La edad de trabajo es una línea de referencia que mide la utilización acumulada, o la tensión, de un componente. Las unidades de ingeniería seleccionadas para medir la edad de trabajo deben reflejar el desgaste por uso normal acumulado del componente. La edad calendario es apropiada en aquellos casos en los cuales el opera de manera mas o menos uniforme. La energía consumida o las unidades de producción entregadas ofrecen frecuentemente una mejor indicación de la edad de trabajo verdadera. Las horas de operación de las bombas no estaban disponibles fácilmente y debían ser estimadas en base a la fecha de la orden de trabajo y de las prácticas de operación conocidas de las bombas. Por ejemplo, las dos bombas de catholyte compartían el mismo servicio y eran cambiadas de en-línea a standby cada dos semanas. Conociendo esto, se podía estimar la edad de trabajo en base a fechas calendario, a tiempo promedio de operación de la planta, y a un tiempo de servicio de 50%. Las otras dos bombas operaban de manera continua y la vida de trabajo estaba basada en directamente en las fechas de las órdenes de trabajo.

C. Información sobre vibración

El monitoreo de condición (CM) ha sido utilizado en las instalaciones de Laverton por más de 9 años. Esto incluye análisis de vibración (VA) de todos los conjuntos de bombas, ventiladores y compresores. El CM es llevado a cabo por un contratista externo especialista. Motores críticos que tienen redundancia standby son cambiados de manera regular para garantizar que siguen operando. Las unidades de standby son arrancadas para efectuar VA. La información de VA es recopilada por el Contratista y cada quince días se envía un resumen ejecutivo a Laverton.

El informe VA asigna a cada máquina rotativa una calificación de desempeño que va de “1” a “5”. Cuando una máquina llega al nivel 3 la comenzamos a monitorear cuidadosamente, al nivel 4 planeamos reemplazarla en la siguiente oportunidad y si llega al nivel 5 es reemplazada inmediatamente. No se lleva una “pizarra” para contar aciertos, fallas y falsas alarmas en este programa de monitoreo de condición. (Hacerlo, en un RCM” Viviente[2] proyecto, es una importante conclusión de este estudio.)

En caso que la condición del equipo reportada por VA es tan severa, y se toma la decisión de reemplazarlo, esto tendrá un significativo impacto en la producción. Un ejemplo es una bomba de motor magnético en el sistema de Catholyte que presentaba ruido excesivo. Se tomó la decisión de reemplazar el motor en lugar de arriesgarse a un disparo y parada no planeados (que potencialmente podría ocurrir en unas horas mas).

Al enfrentar una decisión de parar y reemplazar un ítem, el nivel de confianza en la toma de esa decisión no es conocido, debido a las razones antes mencionadas. Se sabe de algunas bombas que han operado durante largos periodos de tiempo con altos niveles de vibración sin necesidad de ser reemplazadas. Esto implica que factores diferentes a aquellos reportados en el VA, influyen sobre la probabilidad de falla. Entonces le corresponde a la organización y a sus ingenieros de confiabilidad el identificar, a través de observaciones y análisis, aquellos factores internos y externos que probablemente influyan sobre la producción y la rentabilidad.

D. Historia operacional

Otra fuente de información fue obtenida en los registros de historia de alarmas del Sistema de Control Distribuido (DCS). Esta fuente de información fue de asistencia para confirmar las edades de trabajo de las bombas al señalar los eventos de parada e inicio.

V LIMPIEZA & TRANSFORMACIÓN DE INFORMACIÓN

A. Limpieza de Información

Se requiere de efectuar algunos pasos para limpiar y transformar la información antes de usar el software de análisis de confiabilidad.

  1. Preparar o actualizar el Análisis de Modos y Efectos de Falla (FMEA) para bomba y motor. El FMEA se constituye en una “base de conocimiento” y cada uno de sus registros describe un modo de falla cuyo comportamiento ha de ser determinado por el “conteo” (ej. análisis de confiabilidad básico) de las instancias de ordenes de trabajo de ese modo de falla.
  2. Identificar los modos de falla a partir de las órdenes de trabajo y vincularlos al FMEA. Cada vínculo representa un evento de terminación y de inicio en la muestra (ver Figura 5).
  3. Correlacionar información VA a los eventos de falla y suspensión de la bomba usando una técnica como PHM. Consultar la Tabla 3.
  4. Asegurarse que todas las actividades de PM sean correctamente asignadas a los eventos de suspensión o falla de las bombas.
  5. Usar los eventos de parada/inicio registrados en el DCS, de ser necesario, para determinar la edad de trabajo de la bomba en cada evento de vida (ej. orden de trabajo).
  6. Antes del modelaje, utilizar la función de validación de información en el software para ubicar, reparar, o eliminar información errónea e ilógica. Un ejemplo común de esta última sería un registro de Event o Inspección que contenga una edad de trabajo de fecha posterior que sea mas baja que una edad de trabajo de una fecha anterior.
  7. Crear eventos de inicio en los que los ciclos de vida comenzaron antes de la fecha de inicio de la ventana de la muestra.
  8. Asegurar que las fallas y las suspensiones sean definidas y diferenciadas con exactitud. Las fallas “potenciales confirmadas sean contabilizadas como fallas. Estándares bien establecidos del departamento de mantenimiento deben diferenciar fallas de suspensiones.

Sorprendentemente, fue difícil encontrar FMEA para la bomba magnética básica y aun para el motor de inducción estándar en el dominio público. Existen muchas referencias acerca del método, sin embargo, no se pudo encontrar un análisis específico. El estudio desarrolló un modelo FMEA (buscando en la historia de ordenes de trabajo) para las bombas y motores y este fue usado para identificar los modos de falla significativos de interés. Uno de los resultados sorprendentes del análisis de bombas fue que las fallas de bombas estaban mayormente relacionadas con factores operacionales y no con defectos mecánicos intrínsecos.

El siguiente paso fue vincular la información CMMS asociada con fallas con los diferentes modos de falla del FMEA. Consultar la Tabla 2. Un paso importante es asignar la historia de órdenes de trabajo con fechas de inicio y terminación para eventos de bombas y motores, prestando particular atención a fallas o suspensiones [3]. Consultar la Tabla 4.

Tabla 2 Algunos modos de falla de las órdenes de trabajo
Tabla 3 Información de Vibración
Tabla 4 Algunos registros de ordenes de trabajo con referencia de RCM y tipo de Event indicado

VI RESULTADOS

El estudio identificó que las variables de vibración no estaban estrechamente asociadas con las fallas reportadas. De hecho, los resultados indican que la mayoría de las fallas se debieron a técnicas operacionales y no a deterioro mecánico. Esto se considera como un hallazgo valioso del estudio ya que indica el área en el cual se debe enfocar el entrenamiento de administración de activos al igual que el programa CBM mismo. Respecto a lo primero, una lección es dedicar mas tiempo a entrenar a los operarios en la correcta operación de las bombas. Respecto a lo segundo, podríamos examinar el valor de retorno del programa VA. Se recomienda hacer seguimiento (mediante un proceso de RCM viviente)  a los aciertos y desaciertos de VA con el fin de efectuar una evaluación del desempeño predictivo del programa. Esta evaluación, consistente con el mejoramiento continuo, resultará en un programa CBM mas efectivo. Los objetivos de mejoramiento son

  1. Diferenciación entere falla y suspensión que lleve a modelos de decisión mas confiables, y
  2. Determinación de características extraídas de  monitoreo de vibración o de otra condición que reflejen los modos de falla que están ocurriendo en realidad.
  3. Diferenciación entere falla y suspensión que lleve a modelos de decisión mas confiables, y
  4.  Determinación de características extraídas de  monitoreo de vibración o de otra condición que reflejen los modos de falla que están ocurriendo en realidad.

VII CONCLUSIONES

Este fue un estudio preliminar basado en una pequeña muestra de bombas operando durante un periodo de solo dos años. Los autores pretenden ampliar la muestra y aplicar las lecciones aprendidas relativas al manejo de la información sobre fallas y suspensiones, en particular lo siguiente:

  1. Mejorar el manejo de las órdenes de trabajo para lo referente a a su relación con RCM para la identificación tanto del modo de falla y el tipo de evento (sea PF, FF, o S) en la orden de trabajo.
  2. Reportar el modo de falla como una referencia a un registro FMEA donde es definido en el contexto de Función, Falla Funcional y Efectos.
  3. Incluir “que se encontró” y “que se hizo” en el campo de texto libre de la orden de trabajo.
  4. Actualizar de manera dinámica el FMEA, en base a las observaciones diarias referentes a la ejecución de la orden de trabajo. El texto libre de la orden de trabajo, en la medida en que se justifique, soportar actualizaciones al campo de texto de Efectos en un registro FMEA/RCM en un proceso continuo de refinamiento de conocimiento. El texto libre de las órdenes de trabajo debe ser examinado por el ingeniero de confiabilidad con el fin de expandir el texto de Efectos de la base de conocimiento de RCM para cubrir situaciones razonablemente similares que puedan surgir en el curso de las operaciones de la empresa. Retroalimentación e intercambio de estos conceptos con los técnicos debe ocurrir de manera regular.

RECONOCIMIENTOS

En este documento deseamos expresar nuestros reconocimientos a las siguientes personas:
Por el apoyo y estímulo recibido de M Wiseman y del Dr D Lin (OMDEC),
Por la asistencia prestada por C Hill (CMA) y S Mustadanagic (Iwaki)
Por las sugerencias recibidas de parte del Dr. Naaman Gurvitz (Clockwork Solutions)

REFERENCIAS

  1. http://www.reliasoft.com/products.htm
  2. http://www.plant-maintenance.com/
  3. http://www.isograph-software.com/
  4. Weibull, W. (1951), “A statistical distribution function of wide applicability”, J. Appl. Mech.-Trans.ASME 18 (3): 293–297 .
  5. Jardine A.K.S., Banjevic D., Wiseman M.., Buck S. and Joseph T. “Optimising a Mine Haul Truck Wheel Motors’ Condition Monitoring Program: Use of Proportional Hazards Modelling”, http://www.omdec.com/moxie/About/cases/
  6. Living RCM and EXAKT, http://www.livingreliability.com/en
  7. Mixed Populations Mathematical Basis, Naaman Gurvitz, Clockwork Solutions Inc. http://www.clockwork-solutions.com
  8. http://www.omdec.com/wiki/tiki-index.php?page=The+elusive+PF+interval

© 2011, Ron Jenkins. All rights reserved.

  1. [1] Desde los registros históricos de información de monitoreo de condiciones, se pueden compilar las transiciones pasadas desde cada estado hacia todos los demás estados en una matriz y de esta manera se pueden determinar las probabilidades de cada transición. Estas probabilidades, cuando se combinan con el Modelo de Riesgo Proporcional producirán una predicción de falla. Para una explicación detallada y más información, ver Ref 8.
  2. [2] RCM “Viviente” (LRCM) es un proceso dinámico mediante el cual las órdenes de trabajo son vinculadas a registros de conocimiento RCM/FMEA, y cada vínculo se constituye en un punto de información en una muestra para análisis de confiabilidad. En segundo lugar, los registros RCM/FMEA deben ser actualizados a medida que cada orden de trabajo revele nuevo conocimiento acerca de una falla y sus efectos. Ref 6.
  3. [3] Este paso, incluyendo la preparación de la tabla de Events debe ser automatizado a través de un proceso de RCM “viviente” y software de soporte. Ref. 6
This entry was posted in Casos de éxito and tagged , . Bookmark the permalink.