La captura de datos en planta es la base de todo proyecto de manufactura inteligente: ningún dashboard, cifra de OEE o modelo predictivo es mejor que los datos que tiene debajo. Esta guía compara los cuatro métodos principales de captura, muestra cuándo encaja cada uno y explica cómo centralizarlo todo en un único namespace MQTT para poder añadir nuevas máquinas y nuevos consumidores sin rehacer el trabajo.
¿Qué datos estás capturando realmente?
Antes de elegir un método, enumera las preguntas que quieres responder. La mayoría de las plantas empiezan con un puñado de señales que responden a casi todas las preguntas del día a día:
| Tipo de dato | Ejemplo | Fuente típica | Frecuencia típica |
|---|---|---|---|
| Estado de máquina | En marcha, inactiva, parada, preparación | Bit de PLC, baliza luminosa, sensor de corriente | Al cambiar |
| Conteos | Piezas buenas, chatarra | Contador de PLC, sensor de proximidad | Al cambiar o por minuto |
| Valores de proceso | Temperatura, presión, velocidad | Tags de PLC, sensores analógicos | De 1 a 10 segundos |
| Motivos de parada | Falta de material, cambio de herramienta | Entrada del operario | Por evento |
| Resultados de calidad | Pasa/no pasa, cota medida | Estación de prueba, calibre | Por pieza |
| Energía | kWh, kW | Medidor de energía | De 1 a 60 segundos |
El estado y los conteos bastan para el análisis de OEE y de paradas, por eso son el punto de partida habitual. Los códigos de motivo los aportan las personas, no las máquinas, así que toda arquitectura necesita una forma de que los operarios contribuyan. Para diseñar esos códigos, consulta los códigos de motivo de parada.
Comparativa de métodos de captura de datos en planta
1. Captura manual
Hojas de papel, hojas de cálculo o entradas en terminales que rellenan los operarios. Empezar no cuesta casi nada y capta un contexto que las máquinas no pueden conocer, como por qué se paró una línea. Sus debilidades son bien conocidas: las entradas se hacen al final del turno de memoria, las paradas cortas desaparecen y los datos llegan demasiado tarde para actuar.
La captura manual sigue siendo útil para los códigos de motivo y las verificaciones, pero debe ser digital (un formulario en tableta que publique un evento) y limitarse a lo que solo una persona puede aportar.
2. Lectura del PLC
Las máquinas modernas tienen un PLC que ya conoce el estado, los conteos y muchos valores de proceso. Leer esos tags mediante el protocolo de la máquina (Modbus TCP, OPC UA, EtherNet/IP, S7 y otros) proporciona los datos más ricos sin hardware nuevo.
El problema es el acceso. Los fabricantes de máquinas pueden no documentar las direcciones de los tags, el PLC puede estar bloqueado y modificar su código puede afectar a las garantías. Coordínate con el responsable de la máquina antes de escribir nada en un controlador; leer suele ser de bajo riesgo.
3. Sensores retrofit
En máquinas antiguas sin controladores accesibles, añade sensores desde fuera: un transformador de corriente en el motor principal para detectar marcha frente a inactividad, un sensor de proximidad o fotoeléctrico para contar piezas, un sensor de vibración o temperatura para datos de condición, o un sensor de luz en la baliza. Los sensores inalámbricos agilizan la instalación; consulta los sensores industriales inalámbricos para ver opciones.
Los sensores retrofit ven menos que el PLC, pero funcionan en cualquier máquina, sin importar su antigüedad o marca, y nunca tocan el sistema de control.
4. Gateways de edge
Un gateway es un pequeño ordenador industrial que se comunica localmente con los PLC y sensores y reenvía los datos hacia arriba. Se encarga de la traducción de protocolos, el buffering durante los cortes de red, el filtrado (publicar al cambiar en lugar de en cada ciclo) y de añadir contexto, como la posición de la máquina en la jerarquía de la planta.
| Método | Riqueza de datos | Esfuerzo por máquina | Toca el sistema de control | Ideal para |
|---|---|---|---|---|
| Manual | Baja, pero con contexto | Muy bajo | No | Códigos de motivo, verificaciones |
| Lectura de PLC | Alta | Medio | Solo lectura | Máquinas modernas |
| Sensores retrofit | Media | Bajo | No | Máquinas antiguas |
| Gateway de edge | Alta | Medio | Solo lectura | Parques mixtos, muchos protocolos |
La mayoría de las plantas terminan con una combinación: gateways que leen PLC en las líneas más nuevas, sensores retrofit en las antiguas y tabletas para los códigos de motivo.
Centralizar los datos de planta con MQTT
El método que elijas para cada máquina importa menos que adónde van los datos después. Si cada sistema de captura escribe en su propia base de datos, habrás recreado los silos que querías eliminar. El patrón más adecuado: cada sistema de captura publica en un único broker MQTT con una estructura de topics coherente, y cada consumidor se suscribe.
acme/plant1/machining/line1/cnc4/state {"state":"RUNNING","ts":...} retained
acme/plant1/machining/line1/cnc4/count {"good":1,"scrap":0,"ts":...}
acme/plant1/machining/line1/cnc4/spindle {"tempC":41.8,"rpm":8000,"ts":...}
acme/plant1/machining/line1/cnc4/reason {"code":"TOOL_CHANGE","by":"op17"}
La ruta sigue la jerarquía ISA-95 descrita en topics MQTT según ISA-95. Que un valor venga de un PLC, de un sensor de pinza o de una tableta se convierte en un detalle de implementación: los consumidores solo ven el topic.
Un ejemplo mínimo de gateway
El siguiente script en Python lee dos registros holding de un dispositivo Modbus TCP (un código de estado y un contador de piezas), publica el estado al cambiar como mensaje retained y publica los incrementos del conteo. Usa pymodbus 3.x y paho-mqtt 2.x y funciona en una Raspberry Pi o en cualquier PC industrial pequeño.
import json
import time
import uuid
import paho.mqtt.client as mqtt
from pymodbus.client import ModbusTcpClient
PLC_IP = "192.168.10.50"
BASE = "connectmq/demo/sfdc-91be/line1/cnc4" # sustituye 91be por tu propio id
STATES = {0: "STOPPED", 1: "RUNNING", 2: "IDLE", 3: "FAULT"}
mq = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
client_id=f"gw-cnc4-{uuid.uuid4().hex[:6]}")
mq.will_set(f"{BASE}/gateway", json.dumps({"online": False}), qos=1, retain=True)
mq.connect("broker.connectmq.com", 1883, keepalive=30)
mq.loop_start()
mq.publish(f"{BASE}/gateway", json.dumps({"online": True}), qos=1, retain=True)
plc = ModbusTcpClient(PLC_IP, port=502)
last_state, last_count = None, None
while True:
if not plc.connected:
plc.connect()
rr = plc.read_holding_registers(0, count=2)
if rr.isError():
print("Modbus read failed:", rr)
time.sleep(5)
continue
state = STATES.get(rr.registers[0], "UNKNOWN")
count = rr.registers[1]
now = time.time()
if state != last_state:
mq.publish(f"{BASE}/state", json.dumps({"state": state, "ts": now}), qos=1, retain=True)
last_state = state
if last_count is not None and count != last_count:
delta = (count - last_count) % 65536 # gestionar el desbordamiento del contador de 16 bits
mq.publish(f"{BASE}/count", json.dumps({"good": delta, "total": count, "ts": now}), qos=1)
last_count = count
time.sleep(1)
El mismo script funciona sin cambios contra un broker privado de ConnectMQ en cuanto añades credenciales y TLS. El mensaje Last Will marca el gateway como desconectado si pierde la conexión, de modo que los dashboards pueden distinguir entre "máquina parada" y "no tenemos datos". En el servidor público todo es legible por cualquiera, así que úsalo solo con valores simulados; para máquinas reales, cambia a credenciales privadas y TLS.
Checklist de captura de datos en planta
Usa esta lista antes de ampliar el despliegue más allá de una línea piloto:
- Define primero las preguntas y captura solo las señales que las responden.
- Acuerda una jerarquía de topics que refleje la distribución de tu planta y documéntala.
- Pon la marca de tiempo en el origen (gateway o controlador), en UTC.
- Publica al cambiar los estados y conteos; muestrea los valores de proceso a una frecuencia fija razonable.
- Retén el estado actual para que los nuevos suscriptores lo vean de inmediato.
- Marca la calidad del dato: gateway en línea/desconectado mediante Last Will y fallos de sensor como valores explícitos.
- Gestiona el desbordamiento de contadores y los reinicios del gateway sin contar dos veces.
- Asigna a cada dispositivo su propio client ID y credenciales.
- Deja que los operarios añadan contexto con un formulario digital sencillo de códigos de motivo.
- Contrasta los datos con la realidad durante una semana antes de que nadie construya KPIs sobre ellos.
De la captura al valor
Una vez que los datos fluyen, los siguientes pasos son directos: monitorización del estado de las máquinas en una pantalla junto a la línea, análisis de OEE y de paradas y, más adelante, la integración con el MES o mantenimiento. Cada uno es simplemente otro suscriptor. Los mismos topics pueden incluso alimentar un gemelo digital 3D de la planta.
El broker en el centro debería ser la menor de tus preocupaciones. ConnectMQ es un broker MQTT gestionado con MQTT 3.1.1 y 5.0, endpoints TLS y WebSocket seguro, un explorador de topics en vivo y una vista de dispositivos agrupada por niveles ISA-95, lo que facilita confirmar que cada sistema de captura publica en el lugar correcto. Las reglas de alerta por umbral del portal pueden avisarte cuando un valor como la temperatura del husillo supera un límite. La guía de manufactura inteligente muestra cómo encajan estas piezas en una hoja de ruta completa de planta, y el servidor MQTT público gratuito es la forma más rápida de probar tu script de gateway antes de crear credenciales.
Empieza a capturar datos de planta con ConnectMQ
Crea un broker en el plan gratuito Serverless en app.connectmq.com, sin tarjeta de crédito, y apunta tu primer gateway hacia él con el usuario, la contraseña y el client ID generados.
Preguntas frecuentes
¿Cuál es la forma más barata de empezar con la captura de datos en planta?
Un sensor de corriente o de conteo de piezas en una máquina cuello de botella, un pequeño gateway y un broker gratuito. Solo con eso obtienes el tiempo en marcha, el tiempo inactivo y la producción de la máquina que limita tu línea.
¿Debo leer los datos del PLC o añadir sensores?
Lee el PLC cuando tengas acceso y documentación, porque ya contiene datos ricos. Usa sensores retrofit en máquinas antiguas o bloqueadas donde el acceso al PLC sea imposible o arriesgado.
¿Con qué frecuencia deben capturarse los datos de máquina?
Los estados y conteos deben publicarse al cambiar. Los valores de proceso suelen muestrearse cada 1 a 10 segundos, lo que basta para dashboards y análisis de tendencias sin saturar la red.
¿Necesito un MES para la captura de datos en planta?
No. La captura, los dashboards y el OEE pueden funcionar directamente sobre datos MQTT. Un MES resulta útil más adelante, cuando necesitas seguimiento de órdenes, genealogía y flujos de trabajo obligatorios.
