He estado profundizando en el concepto de tecnología inmersa en la operación. No me refiero a un dashboard más ni a un modelo corriendo aparte, sino a herramientas que viven dentro del proceso y hablan el mismo idioma que los equipos.
Para eso tuve que meterme harto en cómo operan los equipos de chancado. Antes de tocar un modelo pasé tiempo entendiendo el proceso: qué hace cada componente, cómo falla, qué variable lo delata y quién decide cuando algo se sale de rango.
El prototipo
Con eso armé un prototipo de gemelo digital. En el video se ve el recorrido: el chancador entra en alerta, abres el equipo, revisas las tendencias y llegas al componente que está fallando. En este caso es el rodamiento del contraeje. La vibración sube, la temperatura pasa la alarma y el espectro muestra picos que apuntan a daño en la pista externa.
El video es un caso ilustrativo con datos sintéticos.
Lo que me llevo
1. Lo más trabajoso no fue predecir, fue asociar cada señal al componente correcto. Si un tag de vibración no está vinculado al rodamiento que corresponde, la mejor predicción termina en una OT que dice «inspeccionar equipo».
2. Los sensores virtuales salen de juntar la física del proceso con relaciones estadísticas. Un chancador también vibra más cuando el mineral viene más duro o entra más carga, y eso no es una falla. La física dice dónde mirar: con la geometría del rodamiento y la velocidad del eje se calcula la frecuencia exacta en que aparece un daño en la pista externa. La estadística dice qué es normal: cuánta vibración y temperatura se esperan para ese tonelaje, esa potencia y esa temperatura de aceite. La diferencia entre lo medido y lo esperado es un sensor que nadie instaló: la salud del rodamiento.
3. Para que todo esto escale hay que estandarizar. Eso significa escribir la jerarquía completa: proceso, equipo, componente, variable, modo de falla y el sensor virtual que lo detecta. Con eso ordenado, lo que construyes para un chancador sirve después para un molino o una bomba. Y alguien tiene que responder por esa jerarquía cuando algo cambia en terreno. Antes que cualquier modelo, eso es gobierno del dato.
Lo que salió en la conversación
¿Modelos de supervivencia o sensores virtuales? Depende de cuánta historia de fallas haya. Cuando un modo de falla tiene suficientes eventos registrados, un modelo de supervivencia como Cox funciona muy bien: usa variables de operación como carga, dureza o temperatura de aceite para estimar el riesgo en el tiempo, y aprovecha también los equipos que aún no han fallado. Cuando las fallas son pocas, que es lo más común en equipos críticos, el enfoque del video parte por los sensores virtuales: un modelo estima lo que el equipo debería medir para esa condición de operación y se vigila la diferencia con lo medido. Así se pasa de una pauta por calendario a una por condición.
Si mañana cambian un sensor en terreno, ¿quién se entera de que el modelo ya no está leyendo lo mismo?
Referencias
- DirectIndustry e-Magazine — “Digital twins: the proving ground for industrial AI”, octubre de 2026. Cómo se usa la simulación para probar decisiones antes de ejecutarlas, y por qué el propio gemelo también hay que validarlo. directindustry.com
- Mining (revista) — “From Reactive to Resilient: a hybrid digital twin and deep learning…”, 2026. Un marco de mantenimiento predictivo para molinos SAG que combina gemelo digital y deep learning. research.itu.edu.tr
Publicado originalmente en LinkedIn el 6 de noviembre de 2026.
