La taxonomía ISO 14224 como requisito previo del mantenimiento predictivo basado en datos

Adaptación de un conjunto de datos público a la estructura de una planta de beneficio minero.

Resumen

Los modelos predictivos de mantenimiento dependen de cómo se registró la historia de fallas. Este trabajo examina esa dependencia con un experimento reproducible. El conjunto de datos público AI4I 2020, de origen sintético, se reorganizó según el modelo de datos de la norma ISO 14224: jerarquía de nueve niveles, clase de equipo y codificación de cada falla por modo, mecanismo y causa. Los registros se reinterpretaron como lecturas de doce bombas centrífugas de pulpa de una planta de beneficio y se entrenaron clasificadores de bosque aleatorio con validación cruzada agrupada por equipo. Con la sola etiqueta binaria de falla, el modelo alcanzó una sensibilidad de 0,79 y una precisión de 0,52, sin indicar qué falla. Con la codificación por modo, los modos de sobrecalentamiento, avería por sobreesfuerzo y desviación de parámetro se reconocieron con sensibilidades entre 0,82 y 0,91, mientras que el modo asociado al desgaste quedó en 0,19, lo que señala que requiere otra estrategia de mantenimiento. Al introducir errores deliberados en el 25 % de los códigos de entrenamiento, el F1 macro bajó de 0,61 a 0,44. Los resultados respaldan que la codificación normalizada define el alcance de un proyecto predictivo antes de cualquier elección de algoritmo.

Palabras clave. ISO 14224, taxonomía de equipos, codificación de fallas, calidad de datos de mantenimiento, mantenimiento predictivo, aprendizaje automático.

1. Introducción

En muchas operaciones mineras la iniciativa de mantenimiento predictivo arranca por el algoritmo: se reúnen lecturas de sensores, se exporta el historial de órdenes de trabajo y se entrena un modelo. El problema aparece después, cuando el historial resulta ser texto libre, los equipos figuran en niveles distintos de la estructura del sistema de gestión de mantenimiento y el campo de código de falla está vacío o lleno de valores genéricos. En ese punto ya no es posible definir con precisión qué evento se quiere anticipar ni sobre qué unidad física.

La literatura sobre mantenimiento basado en condición reconoce desde hace tiempo que la adquisición y el tratamiento de los datos de eventos tienen el mismo peso que el diagnóstico y el pronóstico (Jardine et al., 2006). Las revisiones más recientes sobre aprendizaje automático para diagnóstico de fallas coinciden en que la escasez de datos etiquetados y de calidad sigue limitando la aplicación industrial de estos métodos (Lei et al., 2020). La norma ISO 14224 ofrece un marco para recolectar e intercambiar datos de confiabilidad y mantenimiento de equipos con una estructura común (International Organization for Standardization [ISO], 2016). Aunque nació en la industria del petróleo, el gas natural y la petroquímica, su lógica de jerarquía y codificación es aplicable a cualquier planta de procesos.

El objetivo de este artículo es mostrar, con datos y código verificables, cómo la estructura del registro de mantenimiento condiciona lo que un modelo predictivo puede aprender. Para ello se adapta un conjunto de datos público a la estructura de ISO 14224 y se comparan modelos entrenados con distintos niveles de calidad de codificación. Las adaptaciones realizadas se declaran de forma explícita, porque el valor del ejercicio depende de que el lector pueda distinguir qué proviene de la fuente y qué fue asignado por el autor.

2. Estructura del dato de confiabilidad según ISO 14224

2.1 Jerarquía taxonómica

ISO 14224 organiza los activos en una taxonomía de nueve niveles (ISO, 2016). Los niveles 1 a 5 describen el uso y la ubicación: industria, categoría de negocio, instalación, planta o unidad, y sección o sistema. Los niveles 6 a 9 describen la subdivisión del equipo: unidad de equipo, subunidad, componente o ítem mantenible, y parte. La unidad de equipo pertenece a una clase con límites definidos, lo que permite comparar tasas de falla entre equipos de una misma clase sin mezclar, por ejemplo, el motor con la bomba que acciona. La Figura 1 muestra la jerarquía aplicada al caso de estudio.

Para un modelo predictivo, la jerarquía cumple dos funciones. Fija la unidad de análisis, es decir, si se predice la falla del equipo completo, de una subunidad o de un ítem mantenible. También permite validar el modelo sobre equipos que no participaron en el entrenamiento, que es la condición real de uso cuando el modelo se extiende a otra línea de la planta.

2.2 Modo, mecanismo y causa de falla

La norma separa tres preguntas que en una orden de trabajo suelen mezclarse. El modo de falla describe cómo se manifiesta la pérdida de función y se registra con códigos de tres letras, como OHE (sobrecalentamiento), VIB (vibración), LOO (baja salida) o BRD (avería). El mecanismo de falla describe el proceso físico, químico u otro que condujo a la falla, agrupado en categorías mecánicas, de material, de instrumentación, eléctricas, de influencia externa y varias; ejemplos son el desgaste, la fatiga o el sobrecalentamiento del material. La causa de falla identifica las circunstancias de diseño, fabricación, instalación, operación, mantenimiento o gestión que originaron la falla (ISO, 2016).

La distinción tiene consecuencias prácticas. Un registro que dice «desalineación» como modo de falla confunde un mecanismo con su manifestación, y un modelo entrenado con ese campo aprenderá categorías que no son comparables entre sí. La Tabla 2, más adelante, muestra cómo se asignaron los tres atributos en este trabajo.

3. Metodología

3.1 Conjunto de datos de partida

Se utilizó el conjunto AI4I 2020 Predictive Maintenance Dataset, publicado en el repositorio de aprendizaje automático de la Universidad de California en Irvine bajo licencia CC BY 4.0 (AI4I 2020 Predictive Maintenance Dataset, 2020). Su autor lo presenta como un conjunto sintético que refleja datos reales de mantenimiento predictivo en la industria (Matzka, 2020). Contiene 10 000 registros con temperatura del aire y del proceso, velocidad de rotación, torque, tiempo de desgaste de la herramienta, una variante de producto (L, M o H) y una etiqueta de falla. La etiqueta se acompaña de cinco indicadores que identifican cuál de los modos simulados provocó la falla: desgaste de herramienta (TWF), disipación de calor (HDF), potencia (PWF), sobreesfuerzo (OSF) y falla aleatoria (RNF). Cada modo responde a una regla documentada por la fuente, que se resume en la Tabla 2.

La elección de un conjunto público responde a la trazabilidad: cualquier lector puede descargarlo y reproducir los resultados. Su origen sintético es también su principal limitación, como se discute en la sección 5.

3.2 Adaptación a la estructura de ISO 14224

La adaptación fue estructural. No se alteró ningún valor medido ni ninguna etiqueta original; se renombraron variables y se añadieron atributos de jerarquía y codificación. Cada registro se reinterpretó como una lectura de operación de una bomba centrífuga de pulpa de la clase PU, ubicada en el sistema de bombeo a ciclones de la unidad de molienda y clasificación de una planta de beneficio. La Tabla 1 resume la correspondencia de variables.

El tiempo de desgaste de AI4I aumenta de forma acumulada y vuelve a cero en cada reemplazo de la herramienta. Esos reinicios definieron 120 campañas del ítem de desgaste, que se distribuyeron de forma cíclica entre 12 bombas agrupadas en tres líneas. Esta asignación no existe en la fuente: se introdujo para disponer de los niveles 5 y 6 de la jerarquía y poder agrupar la validación por equipo.

Tabla 1. Correspondencia entre las variables de AI4I 2020 y la base adaptada

La codificación de cada modo AI4I con los atributos de ISO 14224 se hizo por analogía física, a criterio del autor, y se presenta en la Tabla 2. En el caso de PWF, la fuente solo indica que la potencia salió del rango admisible, sin información sobre el proceso físico; por eso se registró como desviación de parámetro con el mecanismo genérico de falla mecánica. Esa decisión ilustra un punto del artículo: un indicador binario de falla no contiene por sí mismo el mecanismo, y alguien tiene que asignarlo con criterio técnico.

3.3 Revisión de la calidad del registro

Antes de modelar se aplicaron las reglas de consistencia que exigiría cualquier registro normalizado: toda falla debe tener un modo y todo modo debe corresponder a una falla. El conjunto original, pese a ser sintético, no las cumple por completo. Se encontraron 9 registros con falla y sin ningún modo, 18 registros con el indicador RNF activo y sin falla, y 24 registros con más de un modo activo a la vez. Los 27 registros incoherentes se excluyeron, de modo que la base modelada quedó con 9973 registros y 330 fallas. En los registros con varios modos se asignó un modo principal según la prioridad OSF, PWF, HDF, TWF y RNF, porque ISO 14224 asocia un modo a cada evento de falla. Como consecuencia, ninguna falla de la base modelada quedó codificada como UNK.

Que un conjunto preparado para investigación presente estas inconsistencias es un recordatorio útil. En una planta, donde el registro depende del turno, de la urgencia de la reparación y de la persona que cierra la orden de trabajo, la proporción de casos de este tipo suele ser mayor.

3.4 Diseño experimental

Se usaron como variables de entrada las cinco lecturas de proceso y la variante de servicio. En todos los casos el clasificador fue un bosque aleatorio de 300 árboles (Breiman, 2001), con estandarización de variables y sobremuestreo SMOTE de las clases minoritarias (Chawla et al., 2002). El sobremuestreo se aplicó dentro de cada partición y solo sobre los datos de entrenamiento.

Tabla 2. Codificación de los modos de AI4I 2020 con los atributos de ISO 14224

La validación fue cruzada en cinco particiones estratificadas y agrupadas por equipo, de manera que ninguna bomba aparece a la vez en entrenamiento y en prueba. Se plantearon cuatro experimentos:

• E0, fuga de información: la etiqueta binaria se predice incluyendo los cinco indicadores de modo como entradas.

• E1, registro sin codificación: se predice solo si hubo falla o no.

• E2, registro codificado: se predice la clase normal o uno de los cuatro modos ISO presentes en la base.

• E3, codificación degradada: se repite E2 alterando una fracción de los códigos de falla del entrenamiento (10 %, 25 %, 40 % y 60 %), por omisión del código o por asignación de un modo equivocado. La partición de prueba conserva siempre los códigos correctos y cada condición se repitió con tres semillas.

Las métricas reportadas son precisión, sensibilidad (recall), F1, coeficiente de correlación de Matthews, recomendado para clases desbalanceadas (Chicco & Jurman, 2020), y área bajo la curva de precisión y sensibilidad. Para E2 y E3 se usa el F1 macro de los cuatro modos, que pondera por igual cada modo sin importar su frecuencia.

4. Resultados

4.1 Cuando el código de falla entra como variable

En E0 todas las métricas alcanzaron el valor de 1,00. El resultado no tiene valor predictivo: los indicadores de modo se conocen después de la falla, y al usarlos como entrada el modelo solo reproduce la etiqueta. Este tipo de fuga de información es una de las causas más frecuentes de resultados engañosos en minería de datos (Kaufman et al., 2012). En un historial de mantenimiento, el modo, el mecanismo y la causa se registran después del evento y solo pueden cumplir el papel de etiqueta.

4.2 Registro sin codificación frente a registro codificado

La Tabla 3 compara E1 y E2. Detectar que habrá una falla, sin importar cuál, tiene un desempeño casi igual en ambos experimentos: sensibilidad de 0,79 frente a 0,77 y precisión de 0,52 frente a 0,54. La diferencia está en la información que entrega cada modelo. E1 emite una alarma genérica; E2 indica además el modo probable, y con él la subunidad, el ítem mantenible y la tarea que corresponde planificar.

La Figura 2 muestra la matriz de confusión de E2. Los modos OHE, BRD y PDE se distinguen bien entre sí y de la operación normal, porque sus reglas de generación dependen de las variables medidas. El modo LOO se comporta de otra manera: el 81 % de sus fallas se clasificó como operación normal y, a la vez, 117 registros normales se clasificaron como LOO.

El bajo desempeño en LOO tiene una explicación física. En la fuente, la falla por desgaste ocurre en un tiempo aleatorio entre 200 y 240 minutos de uso, de modo que las lecturas de proceso no contienen información sobre el momento exacto. El modelo solo puede reconocer que el ítem entró en la ventana de desgaste. Desde la ingeniería de confiabilidad, este es un modo dependiente de la edad, para el cual el reemplazo preventivo a un intervalo definido por el análisis de vida suele ser la respuesta adecuada, mientras que el monitoreo de condición conviene cuando existe un síntoma medible que antecede a la falla (Jardine et al., 2006). Sin la codificación por modo, este hallazgo queda oculto dentro de las métricas globales de E1.

Tabla 3. Desempeño de los experimentos E1 y E2 en validación cruzada agrupada por equipo

4.3 Efecto de la codificación defectuosa

La Figura 3 resume E3. Con la codificación completa, el F1 macro fue de 0,61. Cuando una cuarta parte de las fallas del entrenamiento perdió su código, el valor bajó a 0,54; cuando esa misma fracción recibió un modo equivocado, bajó a 0,44. Con el 60 % de códigos defectuosos los valores fueron de 0,35 por omisión y de 0,22 por error.

El error de código resultó más dañino que la omisión en todas las fracciones evaluadas. Un código ausente reduce los ejemplos disponibles para aprender un modo, mientras que un código equivocado enseña al modelo una relación falsa entre las variables y el modo. Para la gestión del registro, esto sugiere que un campo obligatorio que fuerza al técnico a elegir cualquier código puede ser peor que permitir un valor de «sin determinar» que luego revise el ingeniero de confiabilidad.

5. Discusión

Los resultados permiten ordenar un proyecto predictivo en una secuencia distinta a la habitual. Primero se define la unidad de análisis con la jerarquía, luego se depura y se codifica el historial de fallas, y solo entonces se evalúa qué modos tienen un síntoma medible con los sensores disponibles. En este caso, la codificación separó tres modos aptos para el monitoreo de condición de uno que requiere una estrategia basada en la edad, una decisión que el modelo binario no permite tomar.

Para una planta de beneficio, la aplicación inmediata consiste en exigir en el cierre de cada orden correctiva un conjunto mínimo de campos: equipo en el nivel 6, subunidad o ítem mantenible, modo, mecanismo, causa y método de detección. Con ese registro, la validación agrupada por equipo deja de ser un ejercicio académico y pasa a ser la forma natural de comprobar si un modelo entrenado en una línea funcionará en otra.

El trabajo tiene límites que conviene declarar. AI4I 2020 es un conjunto sintético inspirado en un proceso de mecanizado, de modo que las reglas que generan cada falla no corresponden a la física de una bomba de pulpa. La reinterpretación de variables, la asignación de equipos y líneas y la correspondencia de modos con los códigos de ISO 14224 son decisiones del autor. Por esa razón, las cifras obtenidas no representan el desempeño esperable en una bomba real. El ejercicio mide el efecto de la estructura del dato sobre el aprendizaje, un efecto independiente de la física particular del equipo. Validar estas conclusiones con historiales reales de planta es el paso siguiente.

6. Conclusiones

La codificación por modo de falla, según ISO 14224, mantuvo la capacidad de detectar fallas del modelo binario y añadió la identificación del modo, con sensibilidades de 0,82 a 0,91 en los tres modos que dependen de las variables medidas.

La misma codificación reveló que el modo asociado al desgaste no es predecible con las variables disponibles. En términos de gestión, ese resultado orienta el modo hacia el reemplazo por edad y evita invertir en un monitoreo que no aportaría anticipación.

La calidad del código pesa sobre el resultado tanto como el algoritmo. Con un 25 % de códigos equivocados el F1 macro cayó de 0,61 a 0,44, y los errores resultaron más dañinos que las omisiones.

Los códigos de falla son la variable objetivo del aprendizaje y no deben usarse como entradas. Hacerlo produce métricas perfectas sin ningún valor de anticipación.

Referencias bibliográficas

• AI4I 2020 Predictive Maintenance Dataset [Conjunto de datos]. (2020). UCI Machine Learning Repository. https://doi.org/10.24432/C5HS5C

• Breiman, L. (2001). Random forests. Machine Learning, 45(1), 5–32. https://doi.org/10.1023/A:1010933404324

• Chawla, N. V., Bowyer, K. W., Hall, L. O., & Kegelmeyer, W. P. (2002). SMOTE: Synthetic minority over-sampling technique. Journal of Artificial Intelligence Research, 16, 321–357. https://doi.org/10.1613/jair.953

• Chicco, D., & Jurman, G. (2020). The advantages of the Matthews correlation coefficient (MCC) over F1 score and accuracy in binary classification evaluation. BMC Genomics, 21, Artículo 6. https://doi.org/10.1186/s12864-019-6413-7

• International Organization for Standardization. (2016). Petroleum, petrochemical and natural gas industries — Collection and exchange of reliability and maintenance data for equipment (ISO 14224:2016). https://www.iso.org/standard/64076.html

• Jardine, A. K. S., Lin, D., & Banjevic, D. (2006). A review on machinery diagnostics and prognostics implementing condition-based maintenance. Mechanical Systems and Signal Processing, 20(7), 1483–1510. https://doi.org/10.1016/j.ymssp.2005.09.012

• Kaufman, S., Rosset, S., Perlich, C., & Stitelman, O. (2012). Leakage in data mining: Formulation, detection, and avoidance. ACM Transactions on Knowledge Discovery from Data, 6(4), Artículo 15. https://doi.org/10.1145/2382577.2382579

• Lei, Y., Yang, B., Jiang, X., Jia, F., Li, N., & Nandi, A. K. (2020). Applications of machine learning to machine fault diagnosis: A review and roadmap. Mechanical Systems and Signal Processing, 138, Artículo 106587. https://doi.org/10.1016/j.ymssp.2019.106587

• Matzka, S. (2020). Explainable artificial intelligence for predictive maintenance applications. En 2020 Third International Conference on Artificial Intelligence for Industries (AI4I) (pp. 69–74). IEEE. https://ieeexplore.ieee.org/document/9253083