Guía de fabricación inteligente: de máquinas conectadas a plantas guiadas por datos

Esta guía de fabricación inteligente muestra cómo convertir máquinas aisladas en una planta que se mide a sí misma en tiempo real. Aprenderás qué casos de uso se amortizan primero, cómo deben fluir los datos desde un PLC hasta un dashboard, cómo nombrarlos para que sigan siendo útiles y cómo construir una canalización funcional con MQTT en una tarde.

Qué significa realmente la fabricación inteligente

La fabricación inteligente no es un producto que se compra. Es la práctica de recoger datos de máquinas, procesos y personas de forma continua, ponerlos a disposición de quien los necesite y usarlos para tomar mejores decisiones más rápido de lo que permite una hoja de cálculo semanal.

La mayoría de las plantas ya generan los datos. Los PLC saben si un husillo está girando, los contadores de energía saben cuántos kilovatios hora ha consumido un compresor y las estaciones de calidad saben qué piezas no han superado la inspección. El problema es que esa información está encerrada en máquinas individuales, HMI propietarios e integraciones punto a punto que nadie quiere tocar. Una planta inteligente rompe esos silos con tres ingredientes:

1. Conectividad: cada señal relevante sale de la máquina en un formato estándar y abierto.
2. Una columna vertebral de datos compartida: un único lugar donde los productores publican y los consumidores se suscriben, en lugar de decenas de enlaces a medida.
3. Contexto: datos que llevan su significado consigo, de modo que "temperatura 71.2" se convierte en "línea 2, CNC 4, temperatura del rodamiento del husillo en grados Celsius".

El resto de esta guía trata cada ingrediente y cómo se combinan en proyectos concretos. Si antes quieres el marco general del sector, la guía de la Industria 4.0 explica dónde encaja la fabricación inteligente dentro del conjunto más amplio de tecnologías.

Casos de uso de fabricación inteligente de alto valor

El mejor primer proyecto es el que responde a una pregunta que tu jefe de producción ya se hace cada mañana. La tabla siguiente enumera los casos de uso que con más frecuencia justifican el esfuerzo, qué datos necesita cada uno y dónde profundizar.

Fíjate en que las dos primeras filas necesitan muy pocos datos. Una única señal digital que indique "en marcha o no" más un contador de piezas basta para calcular la disponibilidad y el rendimiento. Por eso el seguimiento de paradas es el punto de partida clásico: barato de instrumentar, útil de inmediato, y construye la infraestructura que reutilizarán todos los proyectos posteriores.

El flujo de datos de la planta: de la máquina a la decisión

Toda arquitectura de fabricación inteligente, se llame como se llame, sigue las mismas cuatro capas. Entenderlas evita el error más caro de la digitalización de plantas: construir integraciones aisladas que no se pueden ampliar.

Capa 1: fuentes de datos

Son los PLC, los controladores CNC, los robots, los sensores inteligentes, los contadores de energía, los lectores de códigos de barras y los terminales de operario. Hablan una mezcla de protocolos: Modbus TCP o RTU, OPC UA, EtherNet/IP, Profinet, interfaces CNC propias de cada fabricante o simplemente E/S digitales. Para máquinas antiguas sin ninguna interfaz, un pequeño sensor de retrofit, como una pinza amperimétrica o una toma de la baliza luminosa, suele ser la forma más rápida de obtener una señal de marcha. El artículo sobre captura de datos en planta compara estas opciones en detalle.

Capa 2: gateways edge

Un gateway edge se sitúa cerca de las máquinas, lee los protocolos nativos y traduce las lecturas a mensajes MQTT. Puede ser un PC industrial con Node-RED, una Raspberry Pi con un script de Python, un ESP32 para sensores sencillos o un conversor de protocolos comercial. El gateway es también donde guardas los datos en buffer cuando cae la red, añades marcas de tiempo y conviertes los valores brutos de los registros en unidades de ingeniería.

Capa 3: la columna vertebral de datos MQTT

Todos los gateways publican en un broker MQTT central y todas las aplicaciones se suscriben a él. Este patrón de publicación/suscripción es la decisión de arquitectura clave. Un nuevo dashboard, un historian o un modelo de mantenimiento pueden añadirse más tarde suscribiéndose a topics existentes, sin tocar un solo PLC. Las máquinas no necesitan saber quién consume sus datos.

MQTT funciona bien aquí porque es ligero, tolera redes poco fiables, admite niveles de calidad de servicio y tiene librerías cliente para prácticamente todos los lenguajes y plataformas. Operar el broker por tu cuenta implica parchear, monitorizar y proteger una pieza crítica de la infraestructura; un broker MQTT gestionado elimina esa carga operativa para que el equipo de planta pueda centrarse en los datos.

Capa 4: consumidores

Los consumidores son las herramientas que convierten los mensajes en decisiones: dashboards en planta, una base de datos de series temporales como InfluxDB alimentada por Telegraf, un MES, lógica de alertas, modelos de mantenimiento o un gemelo digital 3D de la línea. Cada uno es simplemente otro cliente MQTT. Para ver cómo se conecta esta capa con los sistemas de planificación de la producción, consulta integración de MES y MQTT.

Diseñar un espacio de nombres de topics que escale

Un espacio de nombres de topics es la libreta de direcciones de tu planta. Si lo haces bien desde el principio, cada nuevo consumidor podrá encontrar los datos sin preguntar a nadie. Si lo haces mal, acabarás con topics como data/plc7/reg40012 que solo entiende un ingeniero.

El enfoque más adoptado es seguir la jerarquía de equipos de ISA-95, que también es la columna vertebral del patrón Unified Namespace:

<enterprise>/<site>/<area>/<line>/<cell>/<category>

acme/izmir/machining/line2/cnc4/state
acme/izmir/machining/line2/cnc4/telemetry
acme/izmir/machining/line2/cnc4/counters
acme/izmir/utilities/compressors/comp1/energy

Unas pocas reglas mantienen limpio el espacio de nombres:

• Usa minúsculas, sin espacios y sin barra inicial.
• Mantén la jerarquía física (dónde está algo) y pon el tipo de dato en el último nivel.
• Publica el estado actual como mensajes retenidos para que un nuevo suscriptor vea de inmediato el último valor.
• Pon las unidades y las marcas de tiempo en el payload JSON, no en el topic.
• Nunca pongas secretos, datos personales ni números de serie que consideres sensibles en los nombres de los topics.

ConnectMQ detecta automáticamente los topics ISA-95 y Unified Namespace y muestra en su portal los dispositivos conectados agrupados por empresa, planta, área, línea y celda. Si algunos de tus equipos ya hablan Sparkplug B, ConnectMQ decodifica los payloads Protobuf y los republica en topics ISA-95 legibles, de modo que un mensaje en spBv1.0/factory1/DDATA/line1/cnc1 queda disponible en connectmq/factory1/production/line1/cnc1/telemetry. El artículo sobre Sparkplug B y el Unified Namespace explica las ventajas e inconvenientes de ambas convenciones.

Una hoja de ruta de fabricación inteligente paso a paso

Esta hoja de ruta es deliberadamente incremental. Cada paso aporta algo útil por sí mismo, y ninguno requiere parar toda la planta ni un presupuesto plurianual.

1. Elige una línea y una pregunta. Por ejemplo: "¿Por qué la línea 2 produjo un 15 por ciento menos de lo previsto la semana pasada?" Una pregunta acotada mantiene el alcance realista.
2. Inventaría las señales. Haz una lista de lo que ya puede ofrecer cada máquina de esa línea y de lo que necesita un sensor de retrofit. Normalmente basta con una señal de marcha, un contador de piezas y un código de alarma para empezar.
3. Define el espacio de nombres de topics. Anota la ruta ISA-95 de cada activo de la línea y el formato del payload. Acordadlo antes de escribir una sola línea de código.
4. Haz un prototipo en un broker de pruebas. Usa el servidor MQTT público gratuito para validar payloads y dashboards con datos simulados o no sensibles.
5. Despliega los gateways edge. Instala gateways que lean las máquinas y publiquen en el espacio de nombres. Añade buffer local para los cortes de red.
6. Pasa a un broker privado con credenciales y TLS. Los datos de producción deben ir por una conexión autenticada y cifrada.
7. Construye el primer consumidor. Un panel de estado de línea o un informe de paradas. Enséñaselo a operarios y supervisores y recoge sus comentarios.
8. Añade contexto. Permite que los operarios asignen motivos de parada desde una tableta, como se describe en códigos de motivo de parada. Los datos sin motivos te dicen que has perdido tiempo, no por qué.
9. Mide y amplía. Sigue durante unas semanas el KPI que elegiste en el paso 1. Cuando se mueva, replica el patrón en la siguiente línea y añade un segundo caso de uso, como la energía o la monitorización de estado.

Los fabricantes pequeños y medianos pueden seguir exactamente la misma secuencia con una huella menor; el artículo sobre fabricación inteligente para pymes muestra cómo hacerlo con hardware estándar.

Práctica: transmite una máquina simulada con Python

La forma más rápida de entender el flujo de datos es construirlo. El script siguiente simula una máquina CNC que publica su estado y su telemetría en el área pública gratuita de broker.connectmq.com. Usa paho-mqtt 2.x, un topic de estado retenido y un mensaje de Last Will, que son los mismos componentes que usa un gateway real.

Instala primero la librería:

pip install "paho-mqtt>=2.0"

Después guarda esto como cnc_simulator.py:

import json
import random
import time
import uuid

import paho.mqtt.client as mqtt

RUN_ID = uuid.uuid4().hex[:8]
BASE = f"connectmq/demo/{RUN_ID}/site1/line1/cnc1"

client = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id=f"cnc1-sim-{RUN_ID}",
)
# Si el simulador muere, el broker publica "offline" por nosotros.
client.will_set(f"{BASE}/status", "offline", qos=1, retain=True)


def on_connect(client, userdata, flags, reason_code, properties):
    print(f"Connected: {reason_code}. Subscribe with:")
    print(f'  mosquitto_sub -h broker.connectmq.com -p 1883 -i watcher-{RUN_ID} -t "{BASE}/#" -v')
    client.publish(f"{BASE}/status", "online", qos=1, retain=True)


client.on_connect = on_connect
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_start()

state = "RUNNING"
parts = 0
try:
    while True:
        # De vez en cuando cambia el estado de la máquina para generar paradas.
        if random.random() < 0.1:
            new_state = random.choice(["RUNNING", "RUNNING", "IDLE", "STOPPED"])
            if new_state != state:
                state = new_state
                payload = {"state": state, "ts": int(time.time() * 1000)}
                client.publish(f"{BASE}/state", json.dumps(payload), qos=1, retain=True)

        if state == "RUNNING":
            parts += 1

        telemetry = {
            "ts": int(time.time() * 1000),
            "spindleTempC": round(random.uniform(38.0, 46.0), 2),
            "spindleRpm": 8000 if state == "RUNNING" else 0,
            "partCount": parts,
        }
        client.publish(f"{BASE}/telemetry", json.dumps(telemetry), qos=0)
        time.sleep(2)
except KeyboardInterrupt:
    client.publish(f"{BASE}/status", "offline", qos=1, retain=True)
    client.loop_stop()
    client.disconnect()

Ejecútalo con python cnc_simulator.py y copia en un segundo terminal el comando mosquitto_sub que imprime. Verás llegar al instante los mensajes retenidos de status y state, seguidos de telemetría cada dos segundos. Detén el script con Ctrl+C y el status pasará a offline; si en cambio lo matas a la fuerza, el broker publicará el Last Will cuando expire el keepalive.

En el broker público importan dos detalles. La profundidad de los topics está limitada a ocho niveles, por eso la demo usa una jerarquía abreviada bajo el prefijo único connectmq/demo/<id>. Y cualquiera puede leer todo lo que hay en el área pública, así que ahí solo deben ir valores simulados o no sensibles.

Convertir los mensajes en tu primer KPI

Los mensajes en bruto adquieren valor cuando responden a una pregunta. El suscriptor siguiente escucha el topic de estado y calcula la disponibilidad, el primer factor del OEE, a partir del tiempo pasado en cada estado. Pasa como argumento el ID de ejecución que imprime el simulador.

import json
import sys
import time
import uuid

import paho.mqtt.client as mqtt

RUN_ID = sys.argv[1]
STATE_TOPIC = f"connectmq/demo/{RUN_ID}/site1/line1/cnc1/state"

durations = {"RUNNING": 0.0, "IDLE": 0.0, "STOPPED": 0.0}
current = {"state": None, "since": None}


def on_connect(client, userdata, flags, reason_code, properties):
    client.subscribe(STATE_TOPIC, qos=1)


def on_message(client, userdata, msg):
    data = json.loads(msg.payload)
    now = data["ts"] / 1000
    if current["state"] is not None:
        durations[current["state"]] += now - current["since"]
    current["state"], current["since"] = data["state"], now
    planned = sum(durations.values())
    if planned > 0:
        availability = durations["RUNNING"] / planned * 100
        print(f"state={data['state']:<8} availability={availability:5.1f}% {durations}")


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"oee-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=30)
client.loop_forever()

Es intencionadamente sencillo: trata todo el tiempo observado como tiempo de producción planificado e ignora turnos y pausas programadas. Una versión de producción guarda los cambios de estado en una base de datos y calcula disponibilidad, rendimiento y calidad por turno. El artículo sobre KPI de la fábrica inteligente explica qué métricas añadir después y cómo evitar las cifras de vanidad.

Fiabilidad, seguridad y escala en la planta

Un prototipo que funciona en un portátil todavía no es un sistema de planta. Antes de basar tus decisiones en los datos, resuelve estos puntos.

Calidad de servicio. Usa QoS 1 para cambios de estado, contadores y alarmas, que no deben perderse, y QoS 0 para la telemetría de alta frecuencia, en la que la siguiente muestra sustituye a la que se pierda. El artículo los niveles de QoS en MQTT explicados repasa en detalle las garantías de entrega.

Buffer en el edge. Los cortes de red ocurren. Los gateways deben encolar los mensajes en local y publicarlos con su marca de tiempo original tras reconectarse, para que la serie temporal no tenga huecos.

Seguridad. El tráfico de producción debe usar TLS en el puerto 8883 con credenciales por gateway. Nunca compartas un mismo usuario entre todos los dispositivos y nunca expongas directamente las redes de planta a internet; los gateways solo hacen conexiones salientes. La checklist de buenas prácticas de seguridad en MQTT es una buena revisión antes de la puesta en marcha.

Capacidad del broker. Cuenta de antemano tus clientes y el tamaño de los mensajes. Una línea piloto puede necesitar una docena de conexiones; una planta entera con gateways por máquina, dashboards y servicios puede necesitar cientos. Con ConnectMQ, el plan Serverless gratuito cubre hasta 25 conexiones con QoS hasta 1, el plan Serverless de pago lo eleva a 1.000 conexiones con QoS 2, mensajes de 1 MB y suscripciones compartidas, y los planes Dedicated o BYOC te dan un clúster aislado o un despliegue en tu propia cuenta en la nube.

Monitorizar la columna vertebral. Vigila el estado de las conexiones tan de cerca como el de las máquinas. Un gateway que se desconecta en silencio parece exactamente una máquina parada. Los topics status retenidos con un Last Will, combinados con alertas por umbral en el portal de tu broker, hacen visibles estos fallos.

Errores habituales en la fabricación inteligente

La mayoría de los proyectos estancados fracasan por razones organizativas más que técnicas. Atención a estos patrones:

• Empezar por una plataforma en lugar de por un problema. Comprar una gran suite antes de saber qué decisiones quieres mejorar lleva a dashboards que nadie abre.
• Integraciones punto a punto. Conectar el MES directamente a cada PLC funciona con una máquina y se vuelve imposible de mantener con veinte. Haz pasar todo por el broker.
• Falta de contexto. Paradas sin códigos de motivo, energía sin volumen de producción y datos de calidad sin IDs de lote son difíciles de aprovechar.
• Ignorar a los operarios. Las personas de la línea saben por qué se ha parado la máquina. Dales una forma sencilla de registrarlo y enséñales los resultados.
• Nadie es responsable del espacio de nombres. Alguien debe aprobar los nuevos topics y formatos de payload, o la estructura se degrada en pocos meses.
• Tratar la nube como todo o nada. Los lazos de control en tiempo real se quedan en el PLC. El broker transporta tráfico de monitorización, analítica y coordinación, no funciones de seguridad.

Próximos pasos

Una vez conectada la primera línea, la misma columna vertebral sirve para trabajos más avanzados: modelos de mantenimiento que leen datos de vibración, vistas 3D de la línea y consumos energéticos de referencia para toda la planta. Para la arquitectura industrial que hay detrás de todo esto, la guía de IoT industrial con MQTT es el complemento natural de esta guía de fabricación inteligente.

Conecta tu planta con ConnectMQ

Puedes construir toda la canalización de esta guía sin operar ninguna infraestructura de broker. Regístrate en app.connectmq.com con el plan Serverless gratuito, sin tarjeta de crédito, crea un broker y copia en tus gateways el nombre de usuario, la contraseña y el client ID generados. Apúntalos al puerto 8883 con TLS y usa el explorador de topics en tiempo real del portal, la vista de dispositivos ISA-95 y las reglas de alerta por umbral para ver cómo tu primera línea se pone en marcha. Cuando estés listo para ir más allá del piloto, un plan de broker MQTT en la nube crece contigo desde una línea hasta toda la planta.

Preguntas frecuentes

¿Cuál es el mejor primer proyecto de fabricación inteligente?

La monitorización del estado de las máquinas y el seguimiento de paradas en una sola línea es el punto de partida más habitual y fiable. Solo necesita una señal de marcha y un contador de piezas, da resultados visibles rápidamente y construye la infraestructura de datos que reutilizarán los proyectos posteriores.

¿Tengo que sustituir mis máquinas antiguas para empezar con la fabricación inteligente?

No. Las máquinas antiguas pueden equiparse con sensores externos, como pinzas amperimétricas, tomas de la baliza luminosa o sensores de vibración, conectados a un gateway edge que publica por MQTT. Solo merece la pena plantearse sustituirlas cuando la propia máquina es el cuello de botella.

¿Por qué usar MQTT en lugar de conectar los sistemas directamente?

MQTT desacopla a los productores de los consumidores. Las máquinas publican una vez en el broker, y cualquier número de dashboards, bases de datos o modelos puede suscribirse sin nuevas integraciones en planta, lo que mantiene la arquitectura mantenible a medida que crece.

¿Puedo usar el broker público para datos de producción?

No. Cualquiera puede leer el área pública de broker.connectmq.com, que está pensada para pruebas con datos simulados o no sensibles. Los datos de producción deben ir a un broker privado con credenciales y TLS.

¿Qué relación hay entre ISA-95 y el Unified Namespace?

ISA-95 define la jerarquía de empresa, planta, área, línea y celda. El Unified Namespace usa esa jerarquía como estructura de topics de un broker MQTT central, de modo que cada dato de la planta tiene una dirección predecible y autodescriptiva.