PROFINET para MQTT: Opções de Gateway para Levar Dados de Fieldbus à Nuvem

PROFINET para MQTT é uma pergunta que muitas equipes de automação fazem quando querem dados de máquina em dashboards ou na nuvem, e a resposta é menos óbvia do que no Modbus ou no OPC UA. Este guia explica por que os dados PROFINET não podem simplesmente ser lidos por polling, compara as quatro opções práticas de gateway e mostra um exemplo funcional que lê variáveis de processo de um controlador Siemens S7 e as publica em um broker MQTT. Ao final, você saberá qual opção se encaixa na sua planta e com o que tomar cuidado.

Por que o PROFINET é diferente

O PROFINET IO é um padrão de Ethernet industrial para troca cíclica em tempo real entre um IO controller (geralmente um CLP) e IO devices (I/O remoto, inversores, ilhas de válvulas, sensores). O controlador estabelece relações de aplicação com cada dispositivo conforme a configuração de hardware na ferramenta de engenharia e então troca dados de processo em um ciclo fixo, muitas vezes a cada poucos milissegundos. Alarmes e dados acíclicos de registros trafegam em paralelo.

Três características importam para a integração com MQTT:

• O controlador é dono dos dispositivos. Um IO device troca dados cíclicos com o controlador para o qual foi configurado. Um cliente qualquer na rede não pode simplesmente perguntar a velocidade a um inversor, como um mestre Modbus pede um registrador a um medidor.
• Os dados de processo são bytes brutos. Os dados cíclicos são um bloco de bytes de entrada e saída cujo significado é definido no projeto do CLP e nos arquivos de descrição de dispositivo (GSDML), não na rede.
• A rede de tempo real é preciosa. Adicionar tráfego ou dispositivos a uma rede PROFINET deve ser planejado com o engenheiro de automação, nunca improvisado.

A consequência prática: em quase todos os casos, a melhor fonte de dados PROFINET é o CLP que já controla os dispositivos, porque ele tem os dados, o contexto e os nomes.

As quatro opções de PROFINET para MQTT

A opção 4 aparece porque surge em discussões, mas é uma técnica de diagnóstico, não uma forma sólida de construir um pipeline de dados. O restante deste guia foca nas três primeiras.

Opção 1: ler o CLP a partir de um gateway de borda

É a abordagem menos intrusiva e a que a maioria das equipes usa para começar. O gateway fica na rede da planta, lê valores do CLP e os publica em MQTT. Dois caminhos de acesso são comuns em controladores Siemens:

• Servidor OPC UA. Os controladores S7-1500 (e S7-1200 com firmware recente) podem executar um servidor OPC UA. Você o habilita na configuração de hardware e escolhe quais tags expor. O gateway então usa um cliente OPC UA, como no nosso tutorial de gateway OPC UA para MQTT. Esse é o caminho preferido quando disponível: seguro, simbólico e suportado.
• Comunicação S7 (PUT/GET). Bibliotecas open source como a python-snap7 leem data blocks por endereço. No S7-1200 e no S7-1500, isso exige o acesso PUT/GET habilitado nas configurações de proteção da CPU e o data block com acesso não otimizado, para que os offsets de bytes sejam fixos. Habilitar o PUT/GET reduz o nível de proteção da CPU, então combine isso com o responsável pela segurança do CLP.

Outros fabricantes de controladores PROFINET oferecem escolhas semelhantes, normalmente um servidor OPC UA ou um protocolo de leitura próprio.

Exemplo: data block S7 para MQTT com python-snap7

Suponha que o programador do CLP criou um data block não otimizado DB10 que reúne os valores a compartilhar, um padrão comum e recomendado chamado bloco de interface:

pip install python-snap7 "paho-mqtt>=2.0"

# s7_profinet_mqtt.py - lê um DB de interface S7 e publica no MQTT
import json, logging, time, uuid
import paho.mqtt.client as mqtt
import snap7
from snap7.util import get_real, get_dint, get_bool

logging.basicConfig(level=logging.INFO)
log = logging.getLogger("s7")

PLC_IP, RACK, SLOT = "192.168.0.10", 0, 1   # S7-1200/1500: rack 0, slot 1 é o típico
DB_NUMBER, DB_SIZE = 10, 14
TOPIC_ROOT = "connectmq/demo/p3x8/plant1/assembly/line3"   # seu próprio id aleatório
MQTT_HOST, MQTT_PORT = "broker.connectmq.com", 1883        # produção: 8883 com TLS
MQTT_USER, MQTT_PASS = None, None                          # produção: "YOUR_USERNAME", "YOUR_PASSWORD"
CLIENT_ID = f"s7-bridge-{uuid.uuid4().hex[:8]}"            # produção: "YOUR_CLIENT_ID"


def decode(buf):
    return {
        "line_speed": round(get_real(buf, 0), 2),
        "motor_current": round(get_real(buf, 4), 2),
        "good_count": get_dint(buf, 8),
        "running": get_bool(buf, 12, 0),
        "fault": get_bool(buf, 12, 1),
    }


def main():
    mq = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=CLIENT_ID)
    if MQTT_USER:
        mq.username_pw_set(MQTT_USER, MQTT_PASS)
        mq.tls_set()
    mq.will_set(f"{TOPIC_ROOT}/bridge", "offline", qos=1, retain=True)
    mq.on_connect = lambda c, u, f, rc, p: c.publish(f"{TOPIC_ROOT}/bridge", "online", qos=1, retain=True)
    mq.connect(MQTT_HOST, MQTT_PORT, keepalive=30)
    mq.loop_start()

    plc = snap7.client.Client()
    last = {}
    while True:
        try:
            if not plc.get_connected():
                plc.connect(PLC_IP, RACK, SLOT)
                log.info("connected to PLC %s", PLC_IP)
            values = decode(plc.db_read(DB_NUMBER, 0, DB_SIZE))
            ts = time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime())
            for name, value in values.items():
                if last.get(name) != value:            # publica somente na mudança
                    mq.publish(f"{TOPIC_ROOT}/{name}",
                               json.dumps({"value": value, "ts": ts}), qos=1, retain=True)
                    last[name] = value
        except Exception as exc:                       # snap7 lança RuntimeError em erros de comunicação
            log.error("PLC read failed: %s", exc)
            plc.disconnect()
            time.sleep(5)
        time.sleep(1)


if __name__ == "__main__":
    main()

Para valores analógicos que oscilam constantemente, adicione uma banda morta para que a ponte não publique cada pequena variação; nosso guia de report by exception mostra como. Para ver o resultado, assine no servidor MQTT público, lembrando que qualquer pessoa pode lê-lo, então use apenas dados de teste:

mosquitto_sub -h broker.connectmq.com -p 1883 -i s7-viewer-p3x8 -t "connectmq/demo/p3x8/#" -v

Opção 2: deixe o CLP publicar MQTT diretamente

Vários fabricantes de CLP oferecem blocos de função de cliente MQTT. No Siemens S7-1500 e S7-1200, por exemplo, há uma biblioteca cliente MQTT para o TIA Portal que se baseia na open user communication da CPU, com suporte a TLS. O programa do CLP decide exatamente quando publicar, o que é ideal para dados orientados a eventos, como conclusão de lotes ou alarmes.

Pontos a planejar:

1. Certificados. Para TLS, a CPU precisa confiar na CA do broker. O broker usa um certificado Let's Encrypt, então carregue o certificado raiz correspondente no repositório de certificados do CLP.
2. Carga de CPU e de comunicação. Publicar muitos valores em altas taxas a partir do CLP concorre com as tarefas de controle. Publique resumos e eventos, não cada varredura.
3. Tratamento de reconexão. O programa precisa lidar com desconexões do broker de forma elegante e sem bloquear a lógica de controle.
4. Gestão de mudanças. Cada alteração de topic ou payload é um download no CLP. Mantenha o lado do CLP simples e faça o mapeamento mais pesado depois.

Nosso artigo sobre Siemens S7 MQTT aprofunda a configuração do lado do CLP.

Opção 3: um gateway como dispositivo PROFINET

Gateways de hardware de vários fabricantes funcionam como IO device PROFINET de um lado e como cliente MQTT do outro. Você importa o arquivo GSDML do gateway na ferramenta de engenharia, adiciona-o à configuração de hardware e mapeia os dados do CLP para a área cíclica de entrada/saída dele. O gateway converte esses bytes em mensagens MQTT conforme a própria configuração.

Isso oferece uma interface limpa e determinística: o CLP simplesmente copia valores para a área de saída do gateway a cada ciclo, e nada faz polling do CLP. As contrapartidas são uma alteração de hardware, um download no CLP para adicionar o dispositivo e um segundo lugar (a interface web do gateway) onde fica o mapeamento de dados. Combina com plantas que têm regras rígidas contra habilitar PUT/GET ou OPC UA nos controladores.

Escolhendo a opção certa

Use este checklist com o engenheiro de automação:

1. O CLP tem um servidor OPC UA que você pode habilitar? Use a opção 1 com OPC UA.
2. O PUT/GET é aceitável pela sua política de segurança? A opção 1 com comunicação S7 é rápida e barata.
3. Você precisa de dados orientados a eventos definidos na lógica do CLP? Opção 2.
4. As configurações do controlador estão travadas, mas uma alteração de hardware é aceitável? Opção 3.
5. É um piloto em uma linha? Comece pela opção 1; você sempre pode migrar para a opção 2 ou 3 em escala.

Seja qual for a escolha, dê aos dados uma estrutura de topics no estilo ISA-95, para que os valores vindos do PROFINET fiquem ao lado dos dados Modbus, EtherNet/IP e OPC UA em um único namespace; veja nosso guia de topics MQTT ISA-95.

O lado do broker

As três opções terminam com um cliente MQTT publicando em um broker, então a escolha do broker independe do protocolo de campo. Um broker MQTT gerenciado como o ConnectMQ suporta MQTT 3.1.1 e 5.0 sobre TLS na 8883, detecta topics ISA-95 e Unified Namespace e os exibe em um explorador de topics ao vivo e em uma visualização de dispositivos organizada pelos níveis ISA-95. Regras de alerta por limite podem então sinalizar um bit de falha ou uma corrente de motor acima do limite sem código extra. Para a arquitetura de referência completa, leia o guia de MQTT para IoT industrial. Os mesmos topics podem alimentar um gêmeo digital da linha, seja em uma planta em Joinville ou em Manaus.

Comece a usar o ConnectMQ

Escolha seu caminho PROFINET e deixe o broker ser a parte fácil. Cadastre-se em app.connectmq.com, escolha o plano gratuito Serverless (sem cartão de crédito), crie um broker e use o usuário, a senha e o client ID gerados no seu gateway ou no cliente MQTT do CLP. Os dados da sua linha estarão visíveis no portal do ConnectMQ em minutos.

Perguntas frequentes

Um gateway MQTT pode ler dispositivos PROFINET diretamente?

Não da forma como um mestre Modbus faz polling de um medidor. Os IO devices PROFINET trocam dados cíclicos com o controlador configurado, então os gateways ou leem o controlador ou são eles próprios configurados como IO devices.

Habilitar o PUT/GET em um S7-1200 ou S7-1500 é seguro?

Isso reduz a proteção de acesso da CPU, então deve ser uma decisão deliberada e documentada, com segmentação de rede implementada. Quando disponível, o servidor OPC UA do CLP é a alternativa mais segura.

Preciso de arquivos GSDML para um gateway PROFINET para MQTT?

Apenas na opção 3, em que o gateway é adicionado à configuração de hardware do CLP como IO device. Ler o CLP via OPC UA ou comunicação S7 não exige esses arquivos.

Ler o CLP afeta o desempenho em tempo real do PROFINET?

As leituras vão para a interface de comunicação da CPU, não para a troca cíclica de IO, e um polling moderado tem pouco impacto. Mantenha taxas de polling razoáveis e leia blocos de interface compactos.