Modelado de datos IIoT: de tags a modelos de información

El modelado de datos IIoT consiste en convertir miles de tags de PLC crípticos en información estructurada y autodescriptiva que cualquier aplicación pueda consumir sin tener al lado una hoja de cálculo de tags. En esta guía aprenderás las tres capas de un buen modelo de datos industrial, cómo encajan ISA-95, las plantillas Sparkplug B y OPC UA, y cómo publicar un activo modelado sobre MQTT para que el resultado sea visible y comprobable en minutos.

Por qué los tags planos dejan de escalar

Toda planta empieza con tags. Un PLC expone N7:42, DB10.DBW4 o Line2_Mtr3_Amps, y alguien mantiene una hoja de cálculo que explica qué significa cada uno. Eso funciona para un HMI que habla con un controlador. Deja de funcionar en cuanto añades un segundo consumidor.

Los problemas aparecen de forma predecible:

El significado vive fuera de los datos. El tag T_204 es una temperatura solo porque un documento lo dice. La unidad, el rango válido y el activo al que pertenece no están en el payload.
Cada integración repite el mapeo. El equipo del MES, el del historian y el de analítica reconstruyen cada uno el mismo diccionario de tags, y cada versión se desvía.
Máquinas idénticas parecen distintas. Cinco llenadoras de tres fabricantes exponen cinco esquemas de nombres, así que un dashboard construido para una no puede reutilizarse para las demás.
Los cambios rompen a los consumidores en silencio. Cuando un ingeniero de control renombra un tag, nada avisa a las aplicaciones aguas abajo.

Un modelo de datos lo soluciona incorporando estructura, contexto e identidad a los propios datos. Es la base de un Unified Namespace y es lo que hace que los datos de una planta sean reutilizables y no simplemente disponibles.

Las tres capas de un modelo de datos IIoT

Una forma útil de pensar el modelado de datos IIoT es en tres capas. Cada una responde a una pregunta distinta y cada una puede diseñarse de forma independiente.

Capa	Pregunta que responde	Norma o herramienta típica	Ejemplo
Ubicación (dónde)	¿A qué sitio, área, línea y celda pertenece?	Jerarquía de equipos ISA-95	`acme/berlin/packaging/line2/filler1`
Tipo (qué)	¿Qué clase de activo es y qué atributos tiene siempre?	Plantillas Sparkplug B, ObjectTypes de OPC UA	`Filler` con velocidad, estado, contador, rechazos
Datos de instancia (valor)	¿Cuál es el valor actual, con qué unidad, calidad y timestamp?	Esquema de payload (JSON o Protobuf)	`{"value": 118.4, "unit": "bpm", "ts": ...}`

Ubicación: la ruta ISA-95

La capa de ubicación da a cada dato una dirección que las personas reconocen. ISA-95 define una jerarquía de empresa, sitio, área, línea de producción o centro de trabajo, y unidad de trabajo. Usarla como ruta del topic significa que la dirección de un valor también te dice de dónde procede físicamente. El artículo sobre la jerarquía de equipos ISA-95 profundiza en la elección de los niveles y el de topics MQTT ISA-95 muestra cómo se corresponden con los niveles del topic.

Mantén estable la capa de ubicación. La disposición física cambia poco, así que es una buena columna vertebral. Evita poner en la ruta elementos volátiles como códigos de producto o nombres de turno.

Tipo: definiciones de activos reutilizables

La capa de tipo es donde ocurre el modelado de verdad. Defines una Pump una sola vez, con sus atributos (caudal, presión de descarga, corriente del motor, estado de marcha), unidades y rangos permitidos, y cada instancia de bomba sigue esa definición independientemente del PLC o del fabricante que haya debajo.

Hay dos formas habituales de expresar tipos en sistemas MQTT industriales:

Las plantillas Sparkplug B permiten que un nodo edge publique una definición de plantilla en su certificado de nacimiento (birth) y después publique instancias que hacen referencia a ella. Consulta la guía de plantillas Sparkplug para ver su funcionamiento.
Los ObjectTypes y las especificaciones complementarias de OPC UA definen tipos ricos y estandarizados para muchas clases de máquinas. Si tus máquinas ya hablan OPC UA, reutiliza esos tipos en lugar de inventar otros. La comparativa OPC UA vs MQTT explica cómo conviven ambos.

Si no aplica ninguno, para empezar basta con un JSON Schema por tipo de activo guardado en control de versiones.

Datos de instancia: un payload coherente

La capa de valor es el payload. Elijas el formato que elijas, cada valor debe llevar el mismo sobre: el valor, la unidad de ingeniería, un timestamp de origen y un indicador de calidad. Sin timestamp de origen, los consumidores no pueden distinguir un mensaje tardío de una lectura nueva. Sin calidad, un sensor congelado parece un proceso estable.

Diseñar un modelo de datos IIoT paso a paso

La siguiente lista de comprobación sirve para una primera línea o una primera clase de máquina. Hazla sobre papel antes de escribir ninguna configuración de gateway.

Elige una clase de activo con varias instancias. Bombas, motores o llenadoras son buenos candidatos porque la reutilización compensa de inmediato.
Enumera las preguntas que hacen los consumidores. "¿Está en marcha?", "¿Cuánto ha producido esta hora?", "¿Se está desviando hacia un fallo?". El modelo debe responderlas directamente.
Define el tipo. Nombra cada atributo en lenguaje llano y asígnale una unidad, un tipo de dato y un rango esperado. Decide qué atributos son telemetría (cambian a menudo), estado (cambian con eventos) y metadatos (casi nunca cambian).
Mapea los tags a los atributos por fabricante. Es el único lugar donde deberían aparecer nombres de tags específicos del fabricante, normalmente en el gateway edge.
Fija la ruta de ubicación. Elige los niveles ISA-95 que necesitas y anota los nombres permitidos en cada nivel.
Elige el sobre del payload. JSON con valor, unidad, timestamp y calidad es lo más fácil de depurar. Sparkplug B con Protobuf es más compacto e incorpora la semántica de birth y death.
Versiona el modelo. Añade un atributo modelVersion o guarda las definiciones de tipo en un repositorio para que los consumidores puedan detectar cambios.
Publica una instancia y revísala con los consumidores antes de extenderla al resto de la flota.

Publicar un activo modelado sobre MQTT

Aquí tienes un ejemplo mínimo en Python que publica una llenadora modelada: los metadatos como retained message y la telemetría como mensajes periódicos, todo bajo una ruta ISA-95. Usa el servidor MQTT público gratuito en broker.connectmq.com, pensado para pruebas y prototipos, así que no envíes datos reales de planta; el área pública es legible por cualquiera.

import json
import random
import time
import uuid

import paho.mqtt.client as mqtt

BROKER = "broker.connectmq.com"
RUN_ID = uuid.uuid4().hex[:8]
BASE = f"connectmq/demo/{RUN_ID}/berlin/line2/filler1"

# Definición de tipo: cómo es cada Filler
FILLER_MODEL = {
    "type": "Filler",
    "modelVersion": "1.2.0",
    "attributes": {
        "speed": {"unit": "bpm", "dataType": "float", "min": 0, "max": 200},
        "state": {"dataType": "string", "enum": ["RUNNING", "IDLE", "FAULT"]},
        "goodCount": {"unit": "units", "dataType": "int"},
        "rejectCount": {"unit": "units", "dataType": "int"},
    },
    "metadata": {"vendor": "ExampleVendor", "serial": "F-2291", "commissioned": "2024-03-11"},
}


def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)


client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"model-demo-{RUN_ID}")
client.on_connect = on_connect
client.connect(BROKER, 1883, keepalive=60)
client.loop_start()

# Publica el modelo una vez, retenido, para que los suscriptores tardíos puedan descubrirlo
client.publish(f"{BASE}/model", json.dumps(FILLER_MODEL), qos=1, retain=True)

good, rejects = 0, 0
try:
    while True:
        ts = int(time.time() * 1000)
        speed = round(random.gauss(120, 4), 1)
        good += int(speed / 60 * 5)
        rejects += 1 if random.random() < 0.05 else 0
        for name, value, unit in [
            ("speed", speed, "bpm"),
            ("goodCount", good, "units"),
            ("rejectCount", rejects, "units"),
        ]:
            payload = {"value": value, "unit": unit, "ts": ts, "quality": "GOOD"}
            client.publish(f"{BASE}/telemetry/{name}", json.dumps(payload), qos=0)
        client.publish(f"{BASE}/state", json.dumps({"value": "RUNNING", "ts": ts}), qos=1, retain=True)
        time.sleep(5)
except KeyboardInterrupt:
    client.loop_stop()
    client.disconnect()

Observa el resultado con el cliente de Mosquitto:

mosquitto_sub -h broker.connectmq.com -p 1883 -i watcher-$RANDOM -t "connectmq/demo/+/berlin/#" -v

Fíjate en la profundidad: el servidor público admite hasta 8 niveles de topic, así que la demo conserva solo sitio, línea y máquina bajo el prefijo de demo (el topic más profundo, .../filler1/telemetry/speed, tiene exactamente 8 niveles). En tu propio namespace añadirías también la empresa y el área. En producción, en un broker MQTT gestionado, usas tus propias credenciales y no estás limitado a un prefijo de demo compartido.

Cómo te ayuda ConnectMQ a ver el modelo

Cuando los datos modelados empiezan a fluir, necesitas una forma de verificarlos. ConnectMQ detecta topics de estilo ISA-95 y Unified Namespace y muestra en el portal los dispositivos conectados agrupados por niveles ISA-95, de modo que un nivel incorrecto o un nombre de línea mal escrito salta a la vista. El explorador de topics en vivo muestra los mensajes retenidos de modelo y estado junto a la telemetría, una forma rápida de confirmar que el sobre es coherente entre instancias.

Si tus nodos edge publican Sparkplug B, ConnectMQ decodifica los payloads Protobuf y puede republicarlos en topics ISA-95; por ejemplo, spBv1.0/factory1/DDATA/line1/cnc1 se convierte en connectmq/factory1/production/line1/cnc1/telemetry. Así obtienes un transporte Sparkplug compacto desde el edge y topics legibles y modelados para los consumidores. El artículo sobre Sparkplug B y el Unified Namespace trata ese patrón en detalle.

Errores comunes en el modelado de datos IIoT

Modelar el PLC en lugar del proceso. Si tu atributo se llama DB10_Word4, solo has movido el tag. Modela aquello de lo que hablan operadores e ingenieros.
Demasiados niveles de jerarquía. Cada nivel extra es un lugar más para incoherencias de nombres. Usa los niveles que varían en tu planta y omite el resto.
Unidades en los nombres de atributo. temperature_degC acopla el nombre a la unidad. Pon la unidad en el payload o en la definición de tipo.
Sin timestamps de origen. La hora de llegada al broker no es la hora de medición, sobre todo cuando los gateways almacenan en búfer durante los cortes.
Mezclar estado y telemetría en un mismo flujo. Los cambios de estado son poco frecuentes y deben retenerse; la telemetría de alta frecuencia normalmente no.
Sin responsable. Un modelo sin responsable se desvía. Asigna una persona o un equipo por tipo de activo.

Adónde va el modelo después

Un buen modelo de datos no es un fin en sí mismo. Alimenta el historian, el MES, los dashboards, el machine learning y un gemelo digital 3D, donde cada atributo tipado se asocia directamente a su máquina en la escena, sea una planta en Querétaro o en Valencia. La guía de IoT industrial con MQTT muestra la arquitectura general y, si quieres entender cómo se enrutan los mensajes entre todos estos consumidores, empieza por qué hace un broker MQTT. Cuando una sola planta se te quede pequeña, un broker MQTT en la nube permite que varios sitios publiquen en un namespace único y coherente.

Empieza con ConnectMQ

Modela una clase de activo, publícala y obsérvala en un broker real. Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, apunta tu gateway o el script de Python anterior a tus propias credenciales (YOUR_USERNAME, YOUR_PASSWORD, YOUR_CLIENT_ID) y usa la vista de dispositivos ISA-95 para comprobar que tu jerarquía tiene el aspecto que diseñaste.

Preguntas frecuentes

¿Qué es el modelado de datos IIoT?

El modelado de datos IIoT es la práctica de dar a los datos industriales una estructura coherente: una ubicación en una jerarquía de activos, un tipo que define qué atributos tiene un activo y un formato de payload con unidades, timestamps y calidad. Sustituye las hojas de cálculo de tags por datos autodescriptivos.

¿Debo usar plantillas Sparkplug B o tipos OPC UA?

Usa tipos OPC UA si tus máquinas ya los exponen o existe una especificación complementaria para tu clase de equipo. Usa plantillas Sparkplug B cuando tu arquitectura edge sea nativa de MQTT y quieras la semántica de birth y death; ambos pueden alimentar el mismo namespace ISA-95.

¿Dónde debe hacerse el mapeo de tags al modelo?

En el gateway edge o el conector más cercano al PLC. Así los nombres específicos del fabricante quedan en un solo lugar y todos los consumidores por encima del gateway ven solo el modelo limpio.

¿Necesito un modelo de datos antes de empezar un Unified Namespace?

Necesitas al menos la capa de ubicación y un sobre de payload. Los tipos de activo pueden añadirse clase a clase, pero acordar primero las rutas y el sobre evita renombrados costosos más adelante.

Modelado de datos IIoT: de tags planos a modelos de información