¿Se puede hacer un retrofit de IIoT en un PLC antiguo sin tocar su lógica?
Sí. Se trata de leer las señales que ya están ahí, en lugar de reprogramar el controlador que las genera.
Esa es la clave de todo el problema del retrofit. La mayoría de los integradores ya saben cómo extraer datos de una máquina. Lo que los frena es el coste de tocar un programa que nadie quiere revalidar.
Por qué los proyectos de retrofit de PLC se estancan: es el riesgo, no la antigüedad de la máquina
Un PLC que lleva doce años ejecutando la misma lógica de escalera no es un problema técnico. Es la prueba de que la lógica funciona. La barrera real del retrofit es lo que ocurre en el momento en que alguien abre ese programa: una solicitud de cambio, un ciclo de validación, una línea de producción que no puede detenerse para hacer pruebas, una cláusula de garantía que trata cualquier modificación de firmware como una alteración que anula el soporte y, más a menudo de lo que cualquier fabricante quiere admitir, nadie en el equipo que entienda la lógica original lo bastante bien como para tocarla con seguridad.
Nada de esto tiene que ver con la obsolescencia. Tiene que ver con el riesgo. Y el riesgo es precisamente lo que un proyecto de retrofit debería evitar, no introducir.
Consulta el PLC, no lo reprogrames: el método de captura de datos no invasivo
Hay dos formas fundamentalmente distintas de extraer datos IIoT de una máquina que ya tiene un PLC en funcionamiento:
- Reescribir el programa. Añadir lógica de registro dentro del PLC existente, exponer nuevos registros, modificar el ciclo de escaneo. Esto requiere acceso al programa fuente, una revalidación completa de la lógica de control y una ventana de cambio en una máquina que, por definición, está en producción.
- Leer lo que ya está ahí. Consultar el puerto de comunicación existente del PLC (Modbus RTU sobre su bus RS-485, Modbus TCP sobre Ethernet, u OPC-UA si el controlador lo expone) o aprovechar entradas/salidas digitales o analógicas libres en paralelo: señales de marcha/paro, fallo o fin de ciclo que suelen estar ya cableadas a una regleta de bornes sin nada conectado. Ninguno de los dos enfoques cambia una sola línea del programa en ejecución.
El segundo camino es el que hace que un retrofit sea aprobable en una reunión de control de cambios, en lugar de quedar bloqueado en ella.
ESP32 PLC frente a GateBerry: cómo elegir el dispositivo adecuado para el retrofit
Industrial Shields cubre esto con dos dispositivos pensados para distintos alcances del mismo problema. Ninguno sustituye al otro. Usar el que no toca para el alcance solo añade coste o complejidad.
| Alcance | ESP32 PLC | GateBerry |
|---|---|---|
| Uso típico | Una sola máquina, un único punto de conexión | Varias máquinas, varios protocolos, una misma planta |
| Tamaño | Compacto, se instala dentro del propio armario | Carril DIN, envolvente de gateway dedicada |
| Conectividad | WiFi y Bluetooth nativos, LoRa opcional para puntos alejados | Modbus RTU/TCP, OPC-UA, MQTT, CAN, LoRa, GPS, 4G LTE (modular) |
| Procesamiento | Lectura y publicación locales | Traducción de protocolo y agregación local de varias fuentes |
| Entorno de programación | Arduino IDE, construido sobre el ecosistema abierto de Arduino | Nativo de Linux: Python, Node-RED, Docker |
Si el trabajo es una sola máquina y un único conjunto de señales, un ESP32 PLC cableado en paralelo suele ser todo el retrofit. Si el trabajo es un armario con tres PLCs antiguos que hablan tres protocolos distintos, un GateBerry junto a ellos, leyendo cada uno y publicando un único feed consistente, es el camino más rápido hacia un conjunto de datos utilizable.
Arquitectura del retrofit de un PLC: del controlador existente a tu panel de control
El patrón se mantiene igual sea cual sea el dispositivo que hace la lectura:
PLC existente (sin cambios) → señales captadas mediante consulta Modbus o E/S en paralelo → ESP32 PLC o GateBerry → MQTT, OPC-UA o Modbus TCP → la plataforma que ya uses: Grafana, un histórico SCADA, un MES o un servicio IoT en la nube.
Nada de esta cadena requiere que el PLC existente exponga algo que no exponga ya, y nada de ella requiere una ventana de cambio más larga que el tiempo que se tarda en conectar unos cables a una regleta de bornes.
Ejemplo: datos de mantenimiento predictivo en 146 telares antiguos
Problema: Un fabricante textil necesitaba datos de mantenimiento predictivo y preventivo, control de consumos y análisis de paradas, incluyendo las razones de parada, en 146 telares que funcionan en dos turnos al día. Los controladores existentes de los telares nunca se diseñaron para exponer nada de eso.
Requisitos: Ningún cambio en la lógica de control existente en ninguna de las 146 máquinas. Datos que cubran el estado de marcha/paro, las razones de parada y los consumos, agregados a escala en los dos turnos de producción.
Solución: El mismo enfoque no invasivo descrito antes: un ESP32 PLC o un GateBerry cableado en paralelo a las señales existentes de cada telar, publicando por MQTT a una plataforma central, sin abrir el programa de ningún controlador.
Resultado: Los datos de paradas, razones de parada y consumos en tiempo real cubren ahora los 146 telares en los dos turnos, alimentando decisiones de mantenimiento predictivo y preventivo que antes dependían de registros manuales.
Primeros pasos: PLC Solution Library, ESP32 PLC y GateBerry
La PLC Solution Library incluye código funcional para exactamente esto: consulta Modbus RTU y TCP, publicación MQTT y lectura de E/S en paralelo, filtrable por dispositivo y protocolo. Si tu próximo retrofit necesita algo de esto, no partes de cero.
Descubre ESP32 PLC para retrofits de una sola máquina, o GateBerry para gateways multiprotocolo y multimáquina, en www.industrialshields.com.