Cómo hacer una prueba de concepto IIoT en 30 días

Una prueba de concepto IIoT debe responder a una pregunta de negocio con datos reales de planta en un plazo corto y fijo, y 30 días son suficientes si mantienes el alcance acotado. En esta guía encontrarás un plan semana a semana, las métricas de éxito que conviene acordar antes de empezar, un stack ligero formado por un gateway, un broker MQTT gestionado y un dashboard, y un simulador funcional para que puedas construir el pipeline de datos incluso antes de que llegue el hardware.

Por qué se estancan la mayoría de los pilotos IIoT

Los pilotos de IoT industrial rara vez fracasan porque la tecnología no funcione. Se estancan porque el alcance crece hasta "conectar toda la línea", porque nadie acordó qué significa el éxito o porque el piloto depende de una infraestructura que tarda meses en aprobarse. El resultado es el famoso purgatorio de los pilotos: una demo que impresiona una vez y no se vuelve a usar nunca.

Una buena prueba de concepto es justo lo contrario. Es lo bastante pequeña para terminarla, lo bastante importante para que alguien en planta quiera el resultado y está construida con componentes que pueden escalar sin reescribirse si tiene éxito.

Paso 1: elige un alcance acotado y valioso

Elige una pregunta que una persona concreta necesite responder. Buenos ejemplos:

• "¿Por qué se para la CNC cuello de botella de la célula 3 y durante cuánto tiempo?"
• "¿Está funcionando el compresor cuando la planta está parada por la noche?"
• "¿Con qué frecuencia el horno 2 supera su banda de temperatura?"

Después, limita el alcance de forma deliberada:

1. De una a tres máquinas, idealmente del mismo tipo.
2. De tres a diez señales, como estado, contador de piezas, corriente y una alarma.
3. Solo lectura. Nada de escribir en los PLC durante la prueba de concepto.
4. Un dashboard, usado por personas con nombre y apellidos.

Si la máquina objetivo no tiene interfaz de red, planifica sensores adicionales. Nuestra guía sobre retrofit de máquinas antiguas para IoT cubre pinzas de corriente y contadores de piezas.

Paso 2: acuerda las métricas de éxito antes del primer día

Pon las métricas por escrito y consigue que el director de planta las firme. Combina medidas técnicas y de negocio.

Los objetivos anteriores son ejemplos. Fija los tuyos, pero que sean medibles. "Demostrar el valor del IIoT" no es una métrica. Muchos equipos también recogen el retorno esperado para el business case; nuestro artículo sobre el ROI del IIoT explica cómo plantearlo con honestidad.

Paso 3: elige un stack ligero

Resiste la tentación de construir una plataforma. Una prueba de concepto necesita cuatro cosas:

1. Una fuente de datos. El PLC de la máquina a través de un gateway de protocolo, o sensores adicionales a través de un microcontrolador.
2. Un gateway edge. Un pequeño PC industrial o una Raspberry Pi con Node-RED, un script en Python o un gateway comercial que lea la fuente y publique en MQTT.
3. Un broker. Un broker MQTT gestionado para que nadie se pase la primera semana instalando y asegurando un servidor.
4. Un dashboard. Node-RED Dashboard, Grafana alimentado por un pequeño suscriptor o el propio dashboard del broker durante los primeros días.

Es el mismo modelo por capas descrito en nuestra referencia de arquitectura IIoT, solo que con un componente por capa. Como todas las capas hablan MQTT, cada pieza puede sustituirse más adelante sin tocar las demás.

El plan de prueba de concepto IIoT de 30 días

Para el trabajo de red de la semana 1, la lista de comprobación de conectividad IIoT te da las reglas exactas y los comandos de prueba.

Construye el pipeline antes de que llegue el hardware

Las aprobaciones de hardware y firewall suelen tardar una semana o más. No esperes. Construye el pipeline completo contra un simulador desde el primer día, usando el servidor MQTT público gratuito (solo con datos simulados, nunca con datos de producción), para que cuando el gateway real entre en funcionamiento simplemente sustituya al simulador.

import json
import random
import time
import uuid
from datetime import datetime, timezone
import paho.mqtt.client as mqtt

POC_ID = uuid.uuid4().hex[:6]
BASE = f"connectmq/demo/{POC_ID}/plant1/cell3"
MACHINES = ["cnc01", "cnc02"]

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"poc-sim-{POC_ID}")
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()
print(f"Subscribe to: {BASE}/#")

state = {m: {"state": "RUNNING", "parts": 0} for m in MACHINES}

while True:
    now = datetime.now(timezone.utc).isoformat(timespec="seconds")
    for m in MACHINES:
        s = state[m]
        # Cambios de estado aleatorios: casi siempre en marcha, a veces inactiva o parada
        r = random.random()
        new_state = "RUNNING" if r < 0.85 else ("IDLE" if r < 0.95 else "STOPPED")
        if new_state != s["state"]:
            s["state"] = new_state
            client.publish(f"{BASE}/{m}/state",
                           json.dumps({"value": new_state, "ts": now}),
                           qos=1, retain=True)
        if s["state"] == "RUNNING":
            s["parts"] += 1
            client.publish(f"{BASE}/{m}/parts",
                           json.dumps({"value": s["parts"], "ts": now}),
                           qos=1, retain=True)
        amps = round(random.uniform(8, 12) if s["state"] == "RUNNING" else random.uniform(0.5, 2), 2)
        client.publish(f"{BASE}/{m}/current",
                       json.dumps({"value": amps, "unit": "A", "ts": now}), qos=0)
    time.sleep(5)

Observa el flujo desde otro terminal con el topic que imprime el script:

mosquitto_sub -h broker.connectmq.com -p 1883 -i poc-watch-$RANDOM \
  -t 'connectmq/demo/<POC_ID>/plant1/cell3/#' -v

El simulador usa la misma estructura de topics y el mismo formato de payload que usará el gateway real: estado y contador de piezas retenidos, lecturas de corriente no retenidas y una marca de tiempo ISO en cada mensaje. Construye tu dashboard contra él. Cuando el gateway esté listo, cambia el dashboard y el gateway a tu broker privado con TLS y las credenciales del portal. El broker público es solo para desarrollo, porque cualquiera puede leerlo.

Quién hace qué durante los 30 días

Una prueba de concepto necesita un equipo pequeño con roles claros, no un comité de dirección. Tres o cuatro personas suelen bastar:

• El patrocinador, a menudo el director de planta o de producción, es dueño de la pregunta de negocio y toma la decisión de seguir o no el día 30.
• El ingeniero de control es responsable de todo lo que ocurre en la máquina: qué tags o sensores leer, el acceso en solo lectura y la validación de valores frente al HMI.
• La persona de IT o de datos es responsable de la ruta de red, las credenciales del broker y el dashboard.
• El usuario final, normalmente un supervisor de turno o un responsable de mantenimiento, prueba el dashboard cada día a partir de la semana 3 y dice con sinceridad si le ayuda.

Haz un seguimiento de quince minutos dos veces por semana. Cualquier cosa bloqueada más de dos días va directamente al patrocinador, porque un plan de 30 días no tiene margen para esperar aprobaciones.

Errores habituales en una prueba de concepto

• Elegir primero la máquina más difícil. Empieza por una máquina con una interfaz accesible y un responsable colaborador.
• No implicar a los operarios. Si los operarios no participaron en el dashboard, no lo usarán, y la adopción es una métrica de éxito.
• Recogerlo todo. Dos mil tags hacen el piloto más lento y las conclusiones más difíciles de encontrar. Empieza por las señales que responden a tu pregunta.
• Saltarse las métricas aburridas. La completitud de los datos y la latencia son lo que preguntarán los equipos de IT y OT antes de escalar. Mídelas.
• Construir infraestructura desechable. Un broker en el portátil de alguien tendrá que reconstruirse para escalar. Usa algo que pueda soportar el despliegue en producción.

De la prueba de concepto al despliegue

Si el piloto tiene éxito, la siguiente pregunta es lo rápido que puedes añadir máquinas. Con una jerarquía de topics limpia y un broker que escala por plan, añadir la décima máquina es igual que añadir la segunda, y esos mismos topics pueden alimentar después un gemelo digital 3D de la planta. ConnectMQ te permite empezar con el plan Serverless gratuito (hasta 25 conexiones, QoS hasta 1, mensajes de 256 KB), que cubre de sobra un piloto de 30 días, y pasar a Serverless de pago con QoS 2 y suscripciones compartidas o a un clúster Dedicated a medida que crece el despliegue, sin cambiar topics ni código de cliente. El explorador de topics en vivo del portal, la vista de dispositivos ISA-95 y las reglas de alerta por umbral dan soporte directo a las semanas 2 y 3. Para el recorrido completo más allá del piloto, lee la guía de IoT industrial con MQTT.

Empieza tu piloto de 30 días en ConnectMQ

Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito. Ejecuta el simulador contra tu propio broker ConnectMQ desde el primer día, construye el dashboard mientras el hardware está pedido y llega al día 30 con números reales.

Preguntas frecuentes

¿Cuánto debe durar una prueba de concepto IIoT?

Unos 30 días es un plazo realista para una a tres máquinas con una pregunta concreta. Los pilotos más largos tienden a crecer en alcance sin llegar a una decisión.

¿Cuánto cuesta una prueba de concepto IIoT?

Sobre todo tiempo de las personas, más un gateway y posiblemente sensores. Un nivel gratuito de broker MQTT gestionado y herramientas open source como Node-RED mantienen bajo el coste de software.

¿Cuántas máquinas debe incluir un piloto?

De una a tres, idealmente del mismo tipo. Es suficiente para demostrar la ruta de los datos y su valor sin convertir el piloto en un despliegue.

¿Qué pasa después de una prueba de concepto con éxito?

Usa el esfuerzo documentado por máquina y las métricas medidas para planificar un despliegue por fases. Mantén la misma jerarquía de topics y el mismo broker para que el piloto se convierta en la primera fase y no en algo desechable.