Arquitectura IIoT: capas de dispositivo, edge, broker y app

Una buena arquitectura IIoT divide un sistema industrial en cuatro capas: dispositivos que miden y controlan, gateways edge que traducen y filtran, un broker que distribuye los mensajes y aplicaciones que convierten los datos en decisiones. En esta referencia verás de qué es responsable cada capa, qué reglas de diseño mantienen las capas independientes y cómo ejecutar un pequeño ejemplo de extremo a extremo que recorre las cuatro.

Por qué importan las capas en el IoT industrial

Muchos de los primeros proyectos IIoT se construyeron como tuberías directas: un script lee un PLC y escribe en una base de datos que consulta un dashboard. Funciona para la demo. Luego un segundo consumidor necesita los datos, se sustituye el PLC o la base de datos se traslada al cloud, y cada cambio se propaga por toda la cadena.

Una arquitectura por capas contiene esas ondas expansivas. Cada capa tiene una sola tarea y un contrato claro con sus vecinas. Sustituyes un PLC y solo cambia la configuración del edge. Añades una herramienta de analítica y solo aparece un nuevo suscriptor. Pasas de on-premises al cloud y el edge simplemente se conecta a otra dirección de broker. El modelo publicación/suscripción es lo que hace posible este desacoplamiento, y por eso un broker MQTT está en el centro de la mayoría de los diseños IIoT modernos.

Las cuatro capas de la arquitectura IIoT

Capa	Responsabilidad	Componentes típicos	Habla	Responsable
Dispositivo	Medir, actuar, controlar el proceso	Sensores, PLC, variadores, CNC, robots	Bus de campo, Modbus, OPC UA, E/S analógicas y digitales	Ingeniería de control
Edge	Recoger, normalizar, almacenar en búfer, filtrar, asegurar el enlace ascendente	PC industriales, gateways, Node-RED, convertidores de protocolo	Protocolos de dispositivo hacia abajo, MQTT hacia arriba	OT, a veces junto con IT
Broker	Enrutar mensajes, mantener el estado actual, autenticar clientes	Broker MQTT gestionado o autoalojado	MQTT 3.1.1 y 5.0 sobre TLS y WebSocket	Equipo de plataforma o proveedor del servicio
Aplicación	Visualizar, almacenar, analizar, integrar, decidir	Dashboards, historiadores, MES, conectores ERP, analítica	Suscripción y publicación MQTT	IT, equipos de datos, operaciones

Capa de dispositivo

Es el mundo físico: sondas de temperatura, caudalímetros, PLC, variadores, controladores CNC y robots. Los dispositivos están optimizados para el control determinista, no para compartir datos. Muchos solo hablan buses de campo o protocolos serie, y algunos no tienen ninguna interfaz de comunicación. La regla de arquitectura en esta capa es sencilla: no modifiques la lógica de control para atender necesidades de IT. Lee los datos de forma no invasiva y deja la seguridad y el control donde deben estar.

Capa edge

El edge es el traductor y el guardián. Un gateway edge lee tags de PLC, registros Modbus o entradas de sensores, los convierte a un formato común y los publica por MQTT. También hace el trabajo que nunca debería viajar por una WAN: filtrar el ruido, informar por excepción, añadir marcas de tiempo y unidades, y almacenar los datos en búfer cuando el enlace ascendente cae. Nuestras guías para elegir un gateway edge IIoT y sobre edge computing frente a cloud computing en IIoT profundizan en lo que pertenece a esta capa.

Responsabilidades clave del edge:

Conversión de protocolos de dispositivo a MQTT.
Normalización de nombres, unidades y marcas de tiempo.
Informe por excepción con bandas muertas para reducir el tráfico.
Store and forward durante los cortes de red.
Conexiones solo salientes hacia el broker sobre TLS.
Publicación de su propia salud: estado en línea mediante last will, firmware, hora del último sondeo.

Capa de broker

El broker es el hub. Todos los gateways edge publican en él y todas las aplicaciones se suscriben a él. Ninguno de los lados conoce al otro, y precisamente de eso se trata. Además de enrutar, el broker guarda los retained messages para que las nuevas aplicaciones vean el estado actual al instante, mantiene las sesiones de los clientes que se reconectan, aplica la autenticación y las cuotas, y publica los mensajes de last will cuando los gateways se caen. Si quieres los fundamentos, lee qué hace un broker MQTT.

El broker es también donde vive el namespace. Un Unified Namespace organiza los topics según la jerarquía ISA-95, por ejemplo connectmq/acme/plant1/packaging/line4/filler02/telemetry, para que cualquier aplicación pueda encontrar los datos por ubicación en lugar de por lista de tags. Las reglas para diseñar ese árbol están en nuestra guía de estructura de topics UNS.

Capa de aplicación

Las aplicaciones son donde los datos se convierten en valor: dashboards en vivo, cálculos de OEE, notificación de alarmas, historiadores, integración con MES y ERP, machine learning. Cada aplicación es simplemente otro cliente MQTT. Se suscribe a la parte del namespace que necesita y puede publicar resultados de vuelta, como un OEE calculado o un fallo previsto, que otras aplicaciones pueden consumir. El almacenamiento a largo plazo suele ser un suscriptor dedicado que escribe en una base de datos de series temporales, tema tratado en nuestro artículo sobre el historiador MQTT.

Reglas de diseño que mantienen limpia la arquitectura

Todas las flechas apuntan al broker. Los dispositivos nunca hablan directamente con las aplicaciones, y las aplicaciones nunca sondean a los dispositivos.
Las conexiones van hacia fuera. El edge y las aplicaciones abren conexiones hacia el broker; nada abre conexiones hacia la planta.
Un único namespace, documentado. La jerarquía de topics y el formato del payload se ponen por escrito y se versionan.
Retén el estado, no los eventos. Los valores actuales se retienen; las alarmas y las piezas terminadas no.
Cada cliente tiene su propia identidad. Credenciales separadas por gateway y por aplicación, para poder revocar una sin afectar a las demás.
La inteligencia en la capa adecuada. La lógica crítica en tiempo se queda en el dispositivo o en el edge; la analítica entre plantas pertenece a la capa de aplicación.
Observa el propio sistema. El estado de los gateways, el estado de conexión y las tasas de mensajes también son datos.

Ejemplo de extremo a extremo a través de las cuatro capas

El siguiente ejemplo usa el servidor MQTT público gratuito de ConnectMQ, pensado para pruebas y prototipos. El comando bash hace de capa edge y publica lecturas de dispositivo. El script de Python es una aplicación: un pequeño historiador que guarda cada lectura en SQLite y publica una alerta cuando se supera un umbral.

Capa edge (simulada), publicando una lectura cada dos segundos:

ID=arch-$RANDOM
echo "Use prefix connectmq/demo/$ID"
while true; do
  T=$(awk -v r=$RANDOM 'BEGIN{printf "%.1f", 60 + (r % 300) / 10}')
  mosquitto_pub -h broker.connectmq.com -p 1883 -i "$ID-edge" -q 1 \
    -t "connectmq/demo/$ID/plant1/heat/furnace1/temperature" \
    -m "{\"value\":$T,\"unit\":\"C\"}"
  sleep 2
done

Capa de aplicación, almacenando datos y publicando alertas:

import json
import sqlite3
import sys
import time
import paho.mqtt.client as mqtt

PREFIX = sys.argv[1]  # p. ej. connectmq/demo/arch-12345
LIMIT_C = 85.0

db = sqlite3.connect("historian.db", check_same_thread=False)
db.execute("CREATE TABLE IF NOT EXISTS readings (ts REAL, topic TEXT, value REAL)")

def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.subscribe(f"{PREFIX}/plant1/+/+/temperature", qos=1)

def on_message(client, userdata, msg):
    data = json.loads(msg.payload)
    value = float(data["value"])
    db.execute("INSERT INTO readings VALUES (?, ?, ?)", (time.time(), msg.topic, value))
    db.commit()
    print(f"{msg.topic} = {value}")
    if value > LIMIT_C:
        alert_topic = msg.topic.rsplit("/", 1)[0] + "/alert"
        client.publish(alert_topic, json.dumps({"reason": "over_limit", "value": value}), qos=1)

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=f"{PREFIX.split('/')[-1]}-historian")
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_forever()

Ejecútalo con el prefijo que imprime el bucle edge, por ejemplo python historian.py connectmq/demo/arch-12345. Fíjate en lo que nunca ocurre: el historiador no conoce la dirección IP del horno, y el bucle edge no sabe que el historiador existe. Podrías añadir un dashboard, un segundo historiador o un modelo de ML como suscriptores adicionales sin tocar ninguno de los dos. En producción, lleva ambos lados al puerto 8883 con TLS y credenciales de ConnectMQ obtenidas en el portal, y mantén los datos reales de planta fuera del servidor público, que cualquiera puede leer.

Dónde ejecutar el broker

La capa de broker puede ejecutarse on-premises, en una DMZ, en el cloud o en una combinación de ellos. Una única planta con un aislamiento estricto puede mantener un broker local. Las organizaciones con varias plantas, por ejemplo una empresa minera con operaciones en Chile y Perú o un fabricante con sedes en Monterrey y Bilbao, suelen querer un broker central al que todas las plantas accedan con conexiones salientes. Ejecutarlo por tu cuenta implica parches, renovación de certificados, monitorización y planificación de capacidad. Un broker MQTT gestionado elimina ese trabajo, y nuestra guía de broker MQTT en la nube compara los modelos de alojamiento.

ConnectMQ está diseñado para ser la capa de broker de esta arquitectura. Soporta MQTT 3.1.1 y 5.0 sobre TCP 1883, TLS 8883, WebSocket 8083 y WebSocket seguro 8084, de modo que los gateways edge y las aplicaciones de navegador se conectan al mismo namespace. Detecta topics ISA-95 y de Unified Namespace, decodifica Sparkplug B y lo republica en topics ISA-95, y ofrece una vista de dispositivos por nivel ISA-95, un explorador de topics en vivo y reglas de alerta por umbral. Sobre esa misma capa de aplicación puedes construir un gemelo digital 3D de la planta que se suscriba al namespace como un cliente más. Las integraciones con historiadores, bases de datos y dashboards siguen el patrón anterior: herramientas como Node-RED, Telegraf o tus propios suscriptores se conectan a ConnectMQ como clientes MQTT. Las opciones de despliegue van desde Serverless gratuito hasta clústeres Dedicated y BYOC en tu propia cuenta cloud. Para el panorama industrial completo, lee la guía de IoT industrial con MQTT.

Empieza con ConnectMQ

Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito. Apunta hacia él un gateway edge y una aplicación, y tendrás las cuatro capas de tu arquitectura IIoT funcionando en una tarde.

Preguntas frecuentes

¿Cuáles son las capas de una arquitectura IIoT?

Una referencia práctica usa cuatro capas: dispositivos que miden y controlan, gateways edge que recogen y convierten los datos, un broker que enruta los mensajes y mantiene el estado, y aplicaciones que visualizan, almacenan y analizan.

¿Por qué se usa MQTT como capa de mensajería IIoT?

MQTT es ligero, orientado a eventos y usa conexiones salientes, por lo que funciona bien en redes de planta segmentadas. Su modelo publicación/suscripción permite que muchas aplicaciones usen los mismos datos sin integraciones punto a punto.

¿El procesamiento debe hacerse en el edge o en el cloud?

El filtrado crítico en tiempo, la conversión de protocolos y el almacenamiento en búfer pertenecen al edge. La analítica entre máquinas y entre plantas, el almacenamiento a largo plazo y la integración con el negocio suelen pertenecer a la capa de aplicación, a menudo en el cloud.

¿Qué relación tiene el modelo Purdue con esta arquitectura IIoT?

El modelo Purdue describe niveles de seguridad de red, mientras que esta arquitectura describe el flujo de datos. Se complementan: los dispositivos están en los niveles Purdue inferiores, los gateways edge a nivel de planta y el broker en la DMZ o en el cloud.

Capas de la arquitectura IIoT: dispositivo, edge, broker y aplicación