Un gateway Revolution Pi MQTT te ofrece el conocido stack de software de Raspberry Pi en una carcasa para carril DIN pensada para armarios eléctricos, con alimentación de 24 V, módulos de E/S industriales y un ciclo de vida de producto más largo. Este artículo explica dónde encajan los controladores industriales basados en Pi, cómo leer señales de campo de un Revolution Pi en Python y publicarlas por MQTT, y qué cambia cuando un prototipo se convierte en un gateway de producción. Los mismos patrones se aplican a otros equipos industriales basados en Compute Module 4 y Compute Module 5.
Por qué una Raspberry Pi industrial
Una Raspberry Pi estándar es excelente para prototipos, pero un armario eléctrico es otro entorno: alimentación de 24 V DC, ruido eléctrico, amplios rangos de temperatura, vibraciones y personal de mantenimiento que espera montaje en carril DIN y bornes de tornillo. Los controladores industriales basados en el Raspberry Pi Compute Module resuelven esos problemas sin renunciar a Raspberry Pi OS (o un derivado cercano), Python, Node-RED y el resto del ecosistema que ya conoces.
La familia Revolution Pi de KUNBUS es el ejemplo más conocido. Un módulo base como el RevPi Connect contiene el Compute Module, los puertos Ethernet y el acondicionamiento de alimentación. Los módulos de expansión de E/S digital, E/S analógica y gateways de bus de campo se acoplan al lateral y se comunican con la base a través de un conector de backplane. Otros fabricantes construyen controladores basados en CM4 y CM5 con su propia E/S, y el enfoque de integración de este artículo se traslada cambiando la librería de E/S.
| Necesidad | Pi estándar | Controlador industrial basado en Pi |
|---|---|---|
| Alimentación | 5 V USB-C | 24 V DC, a menudo con amplio rango de entrada |
| Montaje | Caja o adaptador DIN | Carril DIN nativo |
| E/S | GPIO de 3,3 V | Entradas/salidas digitales de 24 V, analógicas de 0-10 V y 4-20 mA |
| Almacenamiento | Tarjeta SD | eMMC en el Compute Module |
| Entorno | Oficina | Clasificaciones de temperatura y CEM para armario eléctrico |
| Ciclo de vida | Ritmo de consumo | La disponibilidad a largo plazo es un objetivo de diseño |
Arquitectura típica
En la mayoría de los despliegues, la Pi industrial no sustituye al PLC que controla la máquina. Se coloca junto a él como gateway de edge:
- Las señales de campo llegan al controlador directamente a través de módulos de E/S (un contacto de puerta, un pulso de caudalímetro, un transmisor de presión de 4-20 mA) o indirectamente mediante Modbus TCP, Modbus RTU u otro protocolo desde el PLC existente.
- La aplicación del gateway muestrea los valores, aplica escalado y bandas muertas, detecta cambios de estado y añade marcas de tiempo a todo.
- MQTT transporta los datos hacia fuera, a un broker en la nube o en la red de planta, donde se suscriben dashboards, historians y herramientas de alertas.
- Los comandos opcionales vuelven por MQTT hacia las salidas, pero solo para funciones que no son de seguridad y con validación explícita.
Esta división es importante. El PLC mantiene el control determinista y con certificación de seguridad, mientras que el gateway se encarga de la conectividad y el modelado de datos, justo lo que a menudo un PLC hace mal. Si tus señales vienen de un PLC en lugar de E/S directa, la guía de Raspberry Pi con Modbus y MQTT muestra en detalle la parte del sondeo.
Leer la E/S del RevPi en Python
El Revolution Pi expone todos los valores de los módulos mediante una imagen de proceso gestionada por el driver piControl. Configuras los módulos y das un nombre a cada E/S en la herramienta web PiCtory, y después lees y escribes esos nombres desde cualquier lenguaje. El comando piTest es la comprobación rápida más sencilla:
piTest -d # listar los módulos detectados
piTest -r I_1 # leer la entrada I_1
piTest -w O_1,1 # activar la salida O_1
En Python, la librería revpimodio2 asigna la imagen de proceso a objetos con los nombres de tu configuración de PiCtory. Admite tanto el sondeo cíclico como callbacks por eventos, lo que encaja bien con MQTT: las entradas cambian poco, así que publicar solo al cambiar mantiene bajo el tráfico.
import json
import os
import time
import paho.mqtt.client as mqtt
import revpimodio2
BROKER = os.getenv("MQTT_HOST", "broker.connectmq.com")
PORT = int(os.getenv("MQTT_PORT", "1883"))
USERNAME = os.getenv("MQTT_USERNAME")
PASSWORD = os.getenv("MQTT_PASSWORD")
CLIENT_ID = os.getenv("MQTT_CLIENT_ID", "revpi-gw-r2d7k1")
PREFIX = os.getenv("TOPIC_PREFIX", "connectmq/demo/r2d7k1/plant1/packaging/line2/revpi1")
DIGITAL_INPUTS = ["I_1", "I_2", "I_3"] # nombres de PiCtory
ANALOG_INPUTS = {"InputValue_1": 0.001} # nombre -> factor de escala (p. ej. mV a V)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=CLIENT_ID)
if USERNAME:
client.username_pw_set(USERNAME, PASSWORD)
if PORT == 8883:
client.tls_set()
client.will_set(f"{PREFIX}/status", "offline", qos=1, retain=True)
client.reconnect_delay_set(1, 60)
def on_connect(client, userdata, flags, reason_code, properties):
client.publish(f"{PREFIX}/status", "online", qos=1, retain=True)
client.subscribe(f"{PREFIX}/cmd/O_1", qos=1)
def on_message(client, userdata, msg):
value = msg.payload.decode().strip().lower()
if value in ("1", "true", "on"):
rpi.io.O_1.value = True
elif value in ("0", "false", "off"):
rpi.io.O_1.value = False
client.on_connect = on_connect
client.on_message = on_message
client.connect_async(BROKER, PORT, keepalive=30)
client.loop_start()
rpi = revpimodio2.RevPiModIO(autorefresh=True)
rpi.handlesignalend(rpi.cleanup)
def publish_digital(ioname, iovalue):
payload = {"value": bool(iovalue), "ts": round(time.time(), 3)}
client.publish(f"{PREFIX}/di/{ioname}", json.dumps(payload), qos=1, retain=True)
for name in DIGITAL_INPUTS:
rpi.io[name].reg_event(publish_digital)
publish_digital(name, rpi.io[name].value) # estado inicial
rpi.mainloop(blocking=False)
while not rpi.exitsignal.wait(5):
analog = {n: round(rpi.io[n].value * f, 3) for n, f in ANALOG_INPUTS.items()}
client.publish(f"{PREFIX}/ai", json.dumps({**analog, "ts": int(time.time())}), qos=1)
client.publish(f"{PREFIX}/status", "offline", qos=1, retain=True)
client.loop_stop()
client.disconnect()
Las entradas digitales se publican inmediatamente al cambiar y como retained, de modo que un suscriptor siempre conoce el estado actual. Los valores analógicos se muestrean cada cinco segundos. El manejador de comandos solo acepta valores explícitos para una salida concreta e ignora todo lo demás. Ten en cuenta que, por convención, la suscripción de comandos usa un topic no retained: si en el broker quedara un comando "on" retained, la salida se activaría cada vez que se reiniciara el gateway.
Diseño de topics para datos de planta
Los gateways industriales se benefician de una jerarquía de topics que refleje la planta: empresa, sitio, área, línea, celda o máquina. Esa estructura al estilo ISA-95 es la columna vertebral de un Unified Namespace y hace que las suscripciones sean naturales (plant1/packaging/# para todo lo de un área). ConnectMQ reconoce los topics de estilo ISA-95 y muestra en su portal los dispositivos conectados por esos niveles, lo que facilita navegar por una gran flota de gateways. La guía de MQTT Sparkplug B y Unified Namespace explica cuándo conviene añadir Sparkplug B por encima del JSON simple.
Unas pocas reglas mantienen útil el namespace con el paso de los años:
- Pon la ruta del activo en el topic y las mediciones en el payload, no al revés.
- Usa nombres de señal estables de PiCtory o de una tabla de mapeo, nunca direcciones de registro en bruto.
- Publica el estado y los metadatos (versión de firmware, hash de la configuración de E/S) en topics retained.
- Mantén separados los topics de comandos (
.../cmd/...) y documenta exactamente quién puede publicar en ellos.
Del piloto a producción
El código anterior basta para un piloto en el servidor MQTT público gratuito, pero los datos de planta no deben estar en un broker público. Los gateways de producción necesitan un broker privado, TLS y algunos hábitos operativos:
- Credenciales privadas sobre TLS. Crea un broker en ConnectMQ, usa el usuario, la contraseña y el client ID generados en el portal y conéctate por el puerto 8883. Los client IDs están vinculados a las credenciales emitidas, de modo que un gateway no puede suplantar a otro.
- Red solo saliente. El gateway abre una conexión hacia el broker; no se necesitan reglas de firewall entrantes en la red OT.
- Almacenamiento y reenvío. Mantén una cola local para que los cortes de red no generen huecos en los datos. El patrón de buffer de mensajes MQTT sin conexión en Python funciona sin cambios en un RevPi.
- Gestión del servicio. Ejecuta el script como unidad systemd con reinicio automático y usa el watchdog de hardware.
- Bastionado. Claves SSH, firewall, actualizaciones periódicas y un usuario de servicio dedicado, como se explica en la checklist para asegurar una Raspberry Pi IoT.
- Control de cambios. Versiona juntas la configuración de PiCtory y el código del gateway, para que los nombres de E/S del código coincidan siempre con el hardware.
Un broker MQTT gestionado se ocupa del lado del servidor: certificados, disponibilidad y cuotas. Para plantas más grandes, los planes Dedicated y BYOC mantienen el tráfico en un clúster aislado o en tu propia cuenta de nube.
Dónde encajan bien los gateways Pi industriales
Los controladores industriales basados en Pi son una gran opción para modernizar máquinas antiguas con sensores que el PLC nunca tuvo, monitorizar servicios auxiliares como aire comprimido, agua y contadores de energía, recopilar estados de máquina para el cálculo del OEE y convertir protocolos donde un gateway del fabricante sería caro o cerrado. No sustituyen a los PLC de seguridad y no deberían cerrar lazos de control rápidos que dependan de una temporización determinista. Deja esas tareas en el controlador diseñado para ellas y que el gateway informe de lo que ocurre.
Para una visión más amplia de los gateways de edge en la plataforma Pi, consulta el tutorial de Raspberry Pi con MQTT y la documentación oficial del Compute Module.
Conecta tus gateways industriales a ConnectMQ
Inicia un piloto con el plan gratuito Serverless en app.connectmq.com, sin tarjeta de crédito, y observa cómo aparecen las señales de tu RevPi en el explorador de topics en vivo en pocos minutos. Cuando el piloto demuestre su valor, pasa los mismos gateways a un broker Dedicated o BYOC sin cambiar el código.
Preguntas frecuentes
¿Puedo usar Node-RED en lugar de Python en un Revolution Pi?
Sí. Node-RED funciona en el RevPi y tiene nodos para la imagen de proceso, y sus nodos MQTT integrados publican en cualquier broker. Python te da más control sobre el buffering y las pruebas.
¿El Revolution Pi sustituye a un PLC?
Puede ejecutar lógica de control sencilla, pero la mayoría de las plantas mantienen sus PLC existentes para el control y la seguridad y usan el RevPi como gateway de datos junto a ellos.
¿Con qué rapidez puede publicar datos un gateway RevPi?
El ciclo de E/S es lo bastante rápido para monitorización, pero la pregunta útil es con qué frecuencia necesitan los datos los consumidores. Publica al cambiar para las señales digitales y a intervalos fijos para los valores analógicos.
¿Es MQTT lo bastante seguro para datos de planta?
MQTT sobre TLS con credenciales únicas por gateway, conexiones solo salientes y un broker privado es un diseño sólido. Nunca publiques datos de planta en un broker público.
