Gateways Revolution Pi MQTT: Raspberry Pi industrial (CM4) em produção

Um gateway Revolution Pi MQTT oferece a conhecida stack de software do Raspberry Pi em um gabinete para trilho DIN feito para painéis elétricos, com alimentação de 24 V, módulos de I/O industriais e ciclo de vida de produto mais longo. Este artigo explica onde os controladores industriais baseados em Pi se encaixam, como ler sinais de campo de um Revolution Pi em Python e publicá-los via MQTT e o que muda quando um protótipo vira um gateway de produção. Os mesmos padrões valem para outros dispositivos industriais baseados no Compute Module 4 e no Compute Module 5.

Por que um Raspberry Pi industrial

Um Raspberry Pi comum é excelente para protótipos, mas um painel elétrico é outro ambiente: alimentação de 24 V CC, ruído elétrico, amplas faixas de temperatura, vibração e equipes de manutenção que esperam montagem em trilho DIN e bornes de parafuso. Controladores industriais baseados no Raspberry Pi Compute Module resolvem esses problemas mantendo o Raspberry Pi OS (ou um derivado próximo), Python, Node-RED e o resto do ecossistema que você já conhece.

A família Revolution Pi, da KUNBUS, é o exemplo mais conhecido. Um módulo base como o RevPi Connect contém o Compute Module, portas Ethernet e condicionamento de energia. Módulos de expansão para I/O digital, I/O analógica e gateways de fieldbus se encaixam na lateral e se comunicam com a base por um conector de backplane. Outros fabricantes constroem controladores baseados em CM4 e CM5 com suas próprias I/O, e a abordagem de integração deste artigo se aplica com uma biblioteca de I/O diferente.

Arquitetura típica

Na maioria das implantações, o Pi industrial não substitui o CLP que controla a máquina. Ele fica ao lado, como gateway de borda:

1. Os sinais de campo chegam ao controlador diretamente pelos módulos de I/O (um contato de porta, um pulso de medidor de vazão, um transmissor de pressão 4-20 mA) ou indiretamente via Modbus TCP, Modbus RTU ou outro protocolo a partir do CLP existente.
2. A aplicação do gateway amostra os valores, aplica escalas e bandas mortas, detecta mudanças de estado e coloca timestamp em tudo.
3. O MQTT leva os dados para fora, até um broker na nuvem ou na rede da planta, onde dashboards, historiadores e ferramentas de alerta os assinam.
4. Comandos opcionais voltam via MQTT para as saídas, mas apenas para funções que não sejam de segurança e com validação explícita.

Essa divisão é importante. O CLP mantém o controle determinístico e certificado para segurança, enquanto o gateway cuida da conectividade e da modelagem de dados, justamente as coisas em que um CLP costuma ser fraco. Se os seus sinais vêm de um CLP em vez de I/O direta, o guia Raspberry Pi com Modbus e MQTT mostra o lado do polling em detalhes.

Lendo as I/O do RevPi em Python

O Revolution Pi expõe os valores de todos os módulos por meio de uma imagem de processo gerenciada pelo driver piControl. Você configura os módulos e dá um nome a cada I/O na ferramenta web PiCtory e depois lê e escreve esses nomes a partir de qualquer linguagem. O comando piTest é a verificação mais rápida:

piTest -d            # lista os módulos detectados
piTest -r I_1        # lê a entrada I_1
piTest -w O_1,1      # aciona a saída O_1

Em Python, a biblioteca revpimodio2 mapeia a imagem de processo para objetos nomeados conforme a sua configuração no PiCtory. Ela suporta tanto polling cíclico quanto callbacks de eventos, o que combina bem com MQTT: as entradas mudam raramente, então publicar por mudança mantém o tráfego baixo.

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"]      # nomes do PiCtory
ANALOG_INPUTS = {"InputValue_1": 0.001}     # nome -> fator de escala (ex.: mV para 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()

As entradas digitais são publicadas imediatamente a cada mudança e como retained, então um assinante sempre sabe o estado atual. Os valores analógicos são amostrados a cada cinco segundos. O tratador de comandos aceita apenas valores explícitos para uma saída nomeada e ignora todo o resto. Observe que, por convenção, a assinatura de comandos usa um topic não retained: se um comando "on" retained ficasse parado no broker, a saída seria acionada toda vez que o gateway reiniciasse.

Desenho de topics para dados da planta

Gateways industriais se beneficiam de uma hierarquia de topics que espelha a planta: empresa, unidade, área, linha, célula ou máquina. Essa estrutura no estilo ISA-95 é a espinha dorsal de um Unified Namespace e torna as assinaturas naturais (plant1/packaging/# para tudo de uma área). O ConnectMQ reconhece topics no estilo ISA-95 e mostra os dispositivos conectados por esses níveis no portal, o que facilita navegar por uma grande frota de gateways. O guia de MQTT Sparkplug B e Unified Namespace explica quando acrescentar o Sparkplug B sobre o JSON simples.

Algumas regras mantêm o namespace útil ao longo dos anos:

• Coloque o caminho do ativo no topic e as medições no payload, e não o contrário.
• Use nomes de sinal estáveis vindos do PiCtory ou de uma tabela de mapeamento, nunca endereços de registro brutos.
• Publique status e metadados (versão de firmware, hash da configuração de I/O) em topics retained.
• Mantenha os topics de comando separados (.../cmd/...) e documente exatamente quem pode publicar neles.

Do piloto à produção

O código acima basta para um piloto no servidor MQTT público, mas dados da planta não devem ficar em um broker público, que serve apenas para testes e protótipos. Gateways de produção precisam de um broker privado, TLS e alguns hábitos operacionais:

1. Credenciais privadas via TLS. Crie um broker no ConnectMQ, use o username, a senha e o client ID gerados no portal e conecte na porta 8883. Os client IDs ficam vinculados às credenciais emitidas, então um gateway não consegue se passar por outro.
2. Rede apenas de saída. O gateway abre a conexão com o broker; não é necessária nenhuma regra de firewall de entrada na rede OT.
3. Store and forward. Mantenha uma fila local para que quedas de rede não criem lacunas nos dados. O padrão de buffer offline de mensagens MQTT em Python funciona sem alterações em um RevPi.
4. Gestão do serviço. Rode o script como unidade systemd com reinício automático e use o watchdog de hardware.
5. Blindagem. Chaves SSH, firewall, atualizações regulares e um usuário de serviço dedicado, como no checklist de segurança para Raspberry Pi IoT.
6. Controle de mudanças. Versione juntos a configuração do PiCtory e o código do gateway, para que os nomes de I/O no código sempre correspondam ao hardware.

Um broker MQTT gerenciado cuida do lado do servidor: certificados, disponibilidade e cotas. Para plantas maiores, os planos Dedicated e BYOC mantêm o tráfego em um cluster isolado ou na sua própria conta de nuvem.

Onde os gateways Pi industriais se encaixam bem

Controladores industriais baseados em Pi são uma ótima escolha para modernizar máquinas antigas com sensores que o CLP nunca teve, monitorar utilidades como ar comprimido, água e medidores de energia, coletar estados de máquina para cálculos de OEE e fazer conversão de protocolos onde um gateway do fabricante seria caro ou fechado. Eles não substituem CLPs de segurança e não devem fechar malhas de controle rápidas que dependem de temporização determinística. Mantenha essas funções no controlador projetado para elas e deixe o gateway reportar o que acontece. Os dados coletados assim também são uma boa base para um gêmeo digital da máquina ou da utilidade monitorada.

Para uma visão mais ampla de gateways de borda na plataforma Pi, veja o tutorial de MQTT com Raspberry Pi e a documentação oficial do Compute Module.

Conecte seus gateways industriais ao ConnectMQ

Comece um piloto no plano Serverless gratuito em app.connectmq.com, sem cartão de crédito, e veja os sinais do seu RevPi aparecerem no explorador de topics ao vivo em minutos. Quando o piloto comprovar seu valor, migre os mesmos gateways para um broker Dedicated ou BYOC sem alterar o código.

Perguntas frequentes

Posso usar Node-RED em vez de Python em um Revolution Pi?

Sim. O Node-RED roda no RevPi e tem nós para a imagem de processo, e seus nós MQTT nativos publicam em qualquer broker. O Python dá mais controle sobre buffer e testes.

O Revolution Pi substitui um CLP?

Ele pode executar lógica de controle simples, mas a maioria das plantas mantém seus CLPs existentes para controle e segurança e usa o RevPi como gateway de dados ao lado deles.

Com que velocidade um gateway RevPi consegue publicar dados?

O ciclo de I/O é rápido o bastante para monitoramento, mas a pergunta útil é com que frequência os consumidores precisam dos dados. Publique por mudança para sinais digitais e em intervalo fixo para valores analógicos.

O MQTT é seguro o suficiente para dados da planta?

MQTT sobre TLS com credenciais únicas por gateway, conexões apenas de saída e um broker privado é um projeto sólido. Nunca publique dados da planta em um broker público.