Correas transportadoras: del rodamiento caliente a la OT aprobada

Componentes, variables y modos de falla

En una overland el problema no es solo detectar: es saber dónde mirar. El gemelo junta sensores, inspecciones de ruta y órdenes anteriores en un solo estado del activo, tramo por tramo, para que la cuadrilla salga a buscar algo concreto.

Ejemplo ilustrativo: CV-102, overland en Antofagasta

1. Señal: la temperatura del rodamiento de la polea de cola (pulley de cola) supera el umbral de 66 °C.
2. Causa raíz: el gemelo la atribuye al rodamiento 3, con confianza de 87%, y muestra los datos de origen.
3. Acción: crea la OT 4471 en SAP PM.
4. Aprobación: la OT queda esperando al supervisor del turno B.
5. Ejecución registrada: cada paso queda en un registro auditable.

Ejemplo ilustrativo. CV-102, sus valores y su OT no corresponden a una faena ni a una medición real.

Preguntas que el equipo de mantenimiento le hace al gemelo en un caso así:

• Si la temperatura del rodamiento 3 sigue esta tendencia, ¿llega a la detención programada?
• ¿Conviene adelantar el cambio a la detención del martes o esperar la de fin de mes?
• ¿Qué polines del tramo 4 llevan más tiempo sin inspección?
• ¿Cuántas detenciones no programadas de esta correa partieron en la polea de cola el último año?
• ¿Qué se ha cambiado en esta polea y con qué resultado?

Decisiones que habilita y acciones C4

El DS 132 exige un procedimiento de instalación, operación, mantención e inspección de las correas (art. 113) y que todo trabajo de mantención se haga con la correa totalmente detenida (art. 116). Por eso la decisión de fondo suele ser la misma: qué intervención entra en qué detención.

• Adelantar un cambio a la próxima detención programada o mantener el plan.
• Agrupar intervenciones de un mismo tramo para usar una sola detención.
• Priorizar la ruta de inspección según el riesgo de cada tramo.
• Cambiar un rodamiento ahora o seguir con monitoreo más frecuente, con el riesgo declarado.

Acciones posibles de los agentes, siempre en sistemas de gestión y con aprobación donde corresponde: OT en SAP PM o en tu CMMS, aviso al supervisor de turno por correo o mensajería, ticket para la ruta de inspección. El gemelo no arranca, detiene ni ajusta la correa: no escribe al SCADA ni a ningún sistema de control.

Datos de entrada por sistema

• Historian — OSIsoft PI, Ignition u otro: temperaturas, vibración, corriente y potencia de accionamientos, velocidad, tonelaje por pesómetro.
• Sensores IoT en polines o descansos, cuando existen.
• SCADA en solo lectura: estados de marcha, paradas y alarmas, incluidas las de desalineamiento.
• SAP PM o CMMS: historial de OT, cambios de componentes, plan de mantención.
• Planillas de turno e inspección de ruta: hallazgos de terreno y termografías registradas.

Qué revisa DTI Discover y qué no hace el gemelo

En DTI Discover se elige qué correa gemelizar primero y se mide si los datos alcanzan para proyectar fallas o solo para alertar:

• Cobertura de sensores por tramo y por componente: dónde hay temperatura, dónde vibración, dónde nada.
• Historial de fallas en el CMMS con código de componente y causa registrada.
• Formato de las inspecciones de ruta: planilla, papel o CMMS.
• Línea base de horas de detención no programada de la correa, para medir el KPI del sector: horas de detención no programada evitadas por trimestre.

Límites honestos: si ni un sensor ni una inspección ven un polín, el gemelo tampoco lo ve. La proyección de falla depende de un historial bien codificado; si no existe, el piloto parte con alertas y causa raíz, y la proyección se construye a medida que se acumulan datos. Más contexto en mantenimiento predictivo y en la arquitectura de seguridad.

Preguntas frecuentes