Agente Kepware MQTT: publicar tags en un broker MQTT en la nube con TLS

Publicar con Kepware MQTT es una de las formas más rápidas de llevar a la nube los datos de una planta llena de PLC de distintos fabricantes, porque Kepware ya habla los drivers y su función IoT Gateway añade un cliente MQTT por encima. En este tutorial configurarás el agente MQTT Client de Kepware para publicar tags en un broker en la nube con TLS, elegirás y adaptarás el payload JSON, añadirás un Last Will, verificarás los datos y, opcionalmente, dividirás los mensajes agrupados del agente en un árbol de topics limpio con un topic por tag.

Cómo funciona el agente MQTT de Kepware

Kepware (KEPServerEX y su sucesor Kepware Server) es un servidor de conectividad industrial con drivers para cientos de protocolos de PLC y dispositivos. Su plug-in IoT Gateway añade agentes que envían datos de tags a sistemas externos. El agente MQTT Client es uno de ellos: se conecta a un broker como un cliente MQTT corriente y publica los valores de los tags en JSON.

El modelo es sencillo:

1. Canales y dispositivos sondean tus PLC mediante los drivers de Kepware, igual que ya hacen para el SCADA.
2. Un agente MQTT Client mantiene la conexión con el broker, los ajustes de publicación y el formato del payload.
3. Los IoT items son los tags que añades a ese agente, cada uno con su propia frecuencia de escaneo y comportamiento ante cambios.
4. En cada ciclo de publicación, el agente envía a su topic un mensaje JSON con los valores pendientes.

Como el agente abre una conexión saliente, no hace falta abrir puertos entrantes en la máquina de Kepware. Esa es buena parte de la razón por la que este patrón es tan popular para llevar datos OT a un broker MQTT en la nube. Las etiquetas y los valores por defecto varían un poco entre versiones de Kepware, así que toma los nombres de campo siguientes como orientación y consulta la ayuda de tu versión si algo no coincide.

Antes de empezar

• Kepware con la función IoT Gateway licenciada e instalada.
• Al menos un canal y un dispositivo que ya devuelvan tags con calidad buena. Compruébalo antes en el Quick Client.
• Los datos de conexión del broker. Para una primera prueba, usa el servidor MQTT público gratuito solo con tags no sensibles: es para pruebas y prototipos, no para datos de producción. Para producción, crea un broker privado y anota su usuario, contraseña y client ID.
• Acceso saliente desde el equipo de Kepware al puerto TCP 8883 (TLS) del broker.

Paso 1: crear el agente MQTT Client

En la herramienta de configuración de Kepware, despliega IoT Gateway, haz clic derecho para añadir un nuevo agente y selecciona MQTT Client como tipo. El asistente pide los ajustes básicos:

Después abre los ajustes de seguridad o de cliente del agente y completa:

• Client ID: para el broker público, cualquier valor único y no vacío, como kepware-k7q2. Para un broker privado, el client ID exacto emitido con tus credenciales; los client ID están vinculados a esas credenciales.
• Usuario y contraseña: en blanco para el broker público; YOUR_USERNAME y YOUR_PASSWORD para uno privado.
• Versión de TLS: TLS 1.2 o posterior.

El broker presenta un certificado de Let's Encrypt de confianza pública, así que normalmente no necesitas importar ningún certificado de CA. Si tu organización inspecciona el tráfico TLS con un proxy, el equipo de Kepware deberá confiar en el certificado de ese proxy.

Paso 2: añadir un Last Will

Configura el Last Will del agente para que los consumidores sepan cuándo desaparece Kepware:

• Topic: connectmq/demo/k7q2/plant1/kepware/status
• Mensaje: offline

Si el agente se desconecta de forma inesperada, el broker publica este mensaje en su nombre. Combínalo con una regla de dashboard que atenúe los valores cuando el estado sea offline.

Paso 3: añadir IoT items

Haz clic derecho en el agente, añade IoT items y navega hasta los tags que quieras. Para cada item, define:

1. Scan rate: cada cuánto muestrea Kepware el tag para este agente. Ajústalo a la velocidad real de cambio del valor; de uno a cinco segundos va bien para la mayoría de valores de proceso.
2. Publicar en cada escaneo o al cambiar el dato: prefiere la publicación al cambiar para estados y valores analógicos lentos. Es el report by exception integrado de Kepware, que explicamos en nuestra guía de report by exception.
3. Deadband: en valores analógicos con ruido, una banda muerta suprime los cambios menores que un umbral.

Empieza con unos pocos tags, confirma el flujo de extremo a extremo y luego añade el resto.

Paso 4: verificar los datos

Suscríbete desde cualquier máquina con el cliente de Mosquitto:

mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -i kepware-viewer-k7q2 -t "connectmq/demo/k7q2/#" -v

Con el formato Standard, cada mensaje en el topic del agente tiene este aspecto:

{
  "timestamp": 1792137600000,
  "values": [
    { "id": "Line1.Filler.Speed",     "v": 118.4, "q": true, "t": 1792137599950 },
    { "id": "Line1.Filler.Running",   "v": true,  "q": true, "t": 1792137599950 },
    { "id": "Line1.Filler.GoodCount", "v": 48211, "q": true, "t": 1792137599950 }
  ]
}

id es la ruta completa del tag en Kepware, v el valor, q indica si la calidad es buena y t es la marca de tiempo del tag en milisegundos desde epoch. En un broker privado de ConnectMQ, el cliente MQTT del portal en el navegador y el explorador de topics en vivo muestran los mismos mensajes sin instalar nada.

Paso 5: dar forma al payload con una plantilla Advanced

El formato Advanced te permite escribir una plantilla con marcadores que Kepware rellena. Una plantilla que renombra los campos a algo más cómodo para el código posterior tiene este aspecto:

{
  "source": "kepware-plant1",
  "sent": |SERVERTIMESTAMP|,
  "tags": [
    |#each VALUES|
    { "name": "|TAGNAME|", "value": |VALUE|, "good": |QUALITY|, "ts": |TIMESTAMP| }|#unless @last|,|/unless|
    |/each|
  ]
}

La plantilla debe producir JSON válido para cualquier combinación de valores, también cuando solo ha cambiado un tag. Pruébala observando los mensajes mientras cambias tags en el simulador del PLC o en el Quick Client.

Paso 6: repartir en un árbol de topics por tag

El agente publica lotes en un único topic. Es eficiente, pero muchos consumidores prefieren un topic por valor dentro de una jerarquía ISA-95, que es además lo que hace navegable un Unified Namespace. Un pequeño republicador puede hacer la división. Se ejecuta en cualquier sitio, se conecta al broker como un cliente normal y asigna las rutas de tags de Kepware a topics:

# kepware_fanout.py - split Kepware Standard-format batches into per-tag topics
import json, uuid
import paho.mqtt.client as mqtt

ROOT = "connectmq/demo/k7q2/plant1"
SOURCE = f"{ROOT}/kepware"

def to_topic(tag_id: str) -> str:
    # "Line1.Filler.Speed" -> "connectmq/demo/k7q2/plant1/line1/filler/speed"
    return f"{ROOT}/" + "/".join(part.lower() for part in tag_id.split("."))

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

def on_message(client, userdata, message):
    batch = json.loads(message.payload)
    for item in batch.get("values", []):
        payload = {"value": item["v"], "quality": "good" if item["q"] else "bad", "ts": item["t"]}
        client.publish(to_topic(item["id"]), json.dumps(payload), qos=1, retain=True)

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=f"kep-fanout-{uuid.uuid4().hex[:8]}")
client.on_connect = on_connect
client.on_message = on_message
client.tls_set()
# client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")  # private broker
client.connect("broker.connectmq.com", 8883, keepalive=30)
client.loop_forever()

Cada lote de Kepware se convierte en varios mensajes retained por tag, de modo que el límite del servidor público de diez mensajes por segundo por cliente se aplica al cliente de reparto; mantén pequeña la lista de tags de prueba. En un broker privado, los límites dependen de tu plan. Nuestro artículo sobre topics MQTT ISA-95 te ayuda a diseñar la jerarquía de destino, y ConnectMQ detecta automáticamente los topics con estructura ISA-95 en la vista de dispositivos.

Diagnóstico del agente MQTT de Kepware

Lista de comprobación para producción

1. Broker privado con TLS en el 8883 y credenciales del portal.
2. Client ID único por agente, nunca compartido con herramientas de prueba.
3. Last Will configurado y monitorizado.
4. Publicación al cambiar el dato y bandas muertas en los tags analógicos.
5. Tamaño de mensaje dentro del límite de tu plan: 256 KB en el plan Serverless gratuito y 1 MB en Serverless de pago.
6. Firewall del equipo de Kepware: solo salida por el 8883.
7. Un procedimiento documentado para rotar certificados o credenciales.

Para ver el panorama completo de dónde encaja Kepware entre PLC, gateways y consumidores, consulta la guía de MQTT para IoT industrial. Si estás comparando Kepware con un gateway propio, nuestro tutorial de gateway OPC UA a MQTT muestra la alternativa de código abierto.

Empieza con ConnectMQ

Dale a tu servidor Kepware un destino en la nube en minutos. Regístrate en app.connectmq.com, elige el plan Serverless gratuito sin tarjeta de crédito, crea un broker y copia el usuario, la contraseña y el client ID generados en el agente MQTT Client. ConnectMQ es un broker MQTT gestionado, así que no hay ningún servidor que parchear, y las reglas de alerta por umbral del portal pueden vigilar tus tags en cuanto llegan.

Preguntas frecuentes

¿Kepware admite MQTT sobre TLS?

Sí. Usa una URL ssl:// con el puerto 8883 en el agente MQTT Client y selecciona una versión de TLS actual. Los brokers con certificados de confianza pública normalmente no requieren importar ningún certificado adicional.

¿Puede Kepware publicar cada tag en su propio topic MQTT?

El agente MQTT Client publica lotes en el topic del agente, y las opciones de topics por tag dependen de la versión de Kepware. Un pequeño cliente de reparto que divida los lotes en topics por tag funciona con cualquier versión.

¿Qué QoS debería usar el agente MQTT de Kepware?

QoS 1 es un buen valor por defecto para datos de tags: garantiza la entrega al menos una vez con poca sobrecarga. QoS 2 rara vez es necesario para telemetría.

¿Puede una aplicación en la nube escribir tags a través de Kepware MQTT?

El agente puede configurarse para aceptar peticiones de escritura en un topic suscrito, pero actívalo solo con un control de acceso estricto y una necesidad clara. La mayoría de las implantaciones mantienen la ruta hacia la nube en solo lectura.