Cuando un gateway deja de conectar y empieza a ayudar a mantener

Un gateway industrial puede ser una puerta, un traductor o una primera línea de análisis. La diferencia no está en la carcasa que instalamos en el armario, sino en la pregunta que resolvemos con el dato. Si solo enviamos un aviso cuando la máquina ya se ha detenido, hemos conectado la planta; todavía no la hemos ayudado a anticiparse.

En una línea de producción, el historial del PLC suele guardar señales valiosas: una corriente que sube despacio, una temperatura que tarda más en estabilizarse o ciclos que se alargan. El reto es convertir esa señal en una decisión comprensible para mantenimiento, sin prometer predicciones que los datos aún no pueden sostener.

El salto de transportar datos a interpretarlos

La función básica de un gateway es resolver comunicaciones entre mundos distintos. Puede recoger valores de PLCs, variadores o sensores mediante protocolos industriales y entregarlos a un SCADA, un ERP o una API. Esta capa ya evita exportaciones manuales y hace visible la operación.

Pero la visibilidad no equivale a criterio. Un histórico con miles de registros no indica por sí mismo qué activo requiere atención ni cuándo actuar. Para que el gateway aporte una capa de mantenimiento accionable necesita una lógica adicional: reconocer qué es normal, detectar una desviación relevante y dirigirla hacia una persona o proceso concreto.

El dato gana valor cuando quien recibe la alerta sabe qué revisar, con qué prioridad y por qué ha aparecido.

No se trata de sustituir la experiencia del técnico. El objetivo es preservar el contexto de la planta entre turnos y reducir el tiempo que se dedica a buscar una anomalía entre gráficos dispersos.

Empezar por un modo de fallo, no por una plataforma

El proyecto resulta más útil cuando empieza con una hipótesis concreta. Por ejemplo: detectar un comportamiento térmico anómalo en un motor crítico, avisar de una pérdida progresiva de rendimiento en un compresor o identificar paradas que se repiten bajo una misma receta.

Esa hipótesis permite decidir qué variables deben llegar al Edge, es decir, al equipo que procesa datos cerca de la máquina. No todos los puntos disponibles son necesarios. Para cada caso conviene definir:

• La señal que puede anticipar el problema: corriente, vibración, temperatura, presión, ciclos o tiempo de funcionamiento.
• El estado operativo con el que debe compararse: producto, velocidad, turno, formato o fase del ciclo.
• La calidad mínima exigible: frecuencia de captura, límites físicos, datos ausentes y sincronización horaria.
• La acción asociada: aviso informativo, inspección planificada, orden de trabajo o parada segura según el riesgo.

Con este enfoque, el gateway no intenta encontrar cualquier patrón posible. Se configura para responder a una necesidad operativa que puede validar el equipo de mantenimiento.

Reglas antes que promesas de IA

No toda mejora necesita un modelo de Inteligencia Artificial. En muchos activos, una regla bien planteada ya ofrece una primera barrera útil: una temperatura que supera su rango durante cierto tiempo, una desviación respecto a la media de una máquina equivalente o un número anómalo de reinicios por turno.

Las reglas tienen dos ventajas. Son explicables y se pueden ajustar con el conocimiento de planta. Si generan demasiadas falsas alarmas, el equipo puede revisar el umbral, el contexto o la calidad de la señal antes de automatizar decisiones más complejas.

Cuando existe histórico fiable y la relación entre variables es menos evidente, el análisis estadístico o los modelos de IA pueden complementar estas reglas. Aun así, deben llegar después de resolver la instrumentación, la semántica de los datos y el circuito de respuesta. Una predicción sin responsable, prioridad ni evidencias es solo otra notificación que terminará ignorada.

Diseñar el aviso para que encaje en el trabajo real

Una alerta útil debe explicar lo suficiente para que alguien pueda actuar. En vez de «anomalía detectada», puede incluir el activo, la variable afectada, el periodo de desviación, el estado de máquina y el enlace al histórico relevante. El resultado puede integrarse en un SCADA, un panel de mantenimiento o una herramienta de gestión de órdenes, según el flujo de cada instalación.

También conviene acordar qué sucede cuando el Edge pierde conectividad con sistemas superiores. El control de máquina debe conservar su comportamiento determinista y seguro; el análisis nunca debe convertirse en una dependencia que bloquee el proceso. Separar control, supervisión y analítica ayuda a mantener esta frontera clara.

Un piloto medible antes de escalar

La forma más prudente de avanzar es elegir un activo repetitivo y relevante, definir una señal temprana y medir si el aviso cambia la respuesta del equipo. Durante el piloto, mantenimiento puede confirmar qué alertas eran útiles, qué variables faltaban y qué reglas deben descartarse. Solo después tiene sentido replicar el patrón en más líneas o incorporar modelos más avanzados.

En Proyingel diseñamos integraciones entre automatización, datos de planta y software industrial para que la información llegue a una decisión realista. Hablemos de un caso de uso concreto y planteemos una primera fase que respete la operación diaria.