Conectividade de CLP para a Nuvem: Arquiteturas e Trade-offs

A conectividade de CLP para a nuvem virou um requisito de rotina: a manutenção quer dados de condição remotos, a gestão quer OEE entre plantas, de Joinville a Manaus, e as equipes de dados querem séries temporais limpas para análise e para alimentar um gêmeo digital da produção. Este guia compara as três arquiteturas que de fato funcionam nas plantas, MQTT nativo no CLP, gateways de borda e encaminhamento via SCADA, e percorre as decisões de segurança e confiabilidade por trás de cada uma. Você sairá com um checklist para escolher o design da sua própria planta.

Por que o MQTT é a ponte usual

Os CLPs falam protocolos de campo projetados para comunicação local e determinística: PROFINET, EtherNet/IP, Modbus, comunicação S7, ADS. Nenhum deles foi projetado para atravessar a internet. As aplicações na nuvem, por outro lado, querem fluxos de eventos por conexões criptografadas e autenticadas que atravessem firewalls.

O MQTT se encaixa entre os dois por três características:

• Apenas conexões de saída. O lado da planta abre uma conexão TLS com o broker. Nada na nuvem precisa entrar na planta, então nenhuma porta de entrada é aberta no firewall.
• Desacoplamento publish/subscribe. O lado do CLP publica uma vez; dashboards, historiadores, ferramentas de análise e alertas assinam de forma independente. Adicionar um consumidor não mexe na planta.
• Leve e tolerante a links ruins. Cabeçalhos pequenos, keep alive, níveis de QoS, retained messages e sessões persistentes lidam bem com links celulares ou WAN congestionadas.

Se o conceito de broker é novo para você, comece por o que um broker MQTT faz antes de escolher uma arquitetura.

Arquitetura 1: MQTT nativo no CLP

O próprio controlador executa um cliente MQTT e se conecta ao broker. A Siemens oferece uma biblioteca para S7-1200 e S7-1500, o CODESYS tem uma biblioteca de cliente MQTT e o Beckhoff TwinCAT tem funções IoT; os passo a passo estão no tutorial Siemens S7 MQTT e nos artigos relacionados.

Pontos fortes: nenhum hardware extra, latência mínima, payloads definidos por quem melhor conhece o processo.

Pontos fracos: código de rede e de certificados passa a viver no programa de controle, cada mudança significa um download no CLP, o store-and-forward é limitado pela memória do controlador e o CLP precisa de uma rota até a internet ou até um broker na DMZ, algo a que muitas equipes de segurança resistem.

Combina quando: um fabricante de máquinas entrega máquinas conectadas, ou alguns poucos controladores precisam de algumas dezenas de sinais e adicionar hardware é inviável.

Arquitetura 2: gateway de borda

Um gateway na rede de controle lê os CLPs pelos protocolos nativos e publica MQTT para cima. Pode ser um PC industrial com um servidor de conectividade comercial, um contêiner em uma plataforma de borda, o Node-RED ou um pequeno serviço em Python. O guia de gateway de borda IIoT aborda em profundidade as escolhas de hardware e software.

Pontos fortes: os programas dos CLPs ficam intocados, um gateway atende muitos controladores e marcas, o buffer em disco sobrevive a quedas da WAN, e a formatação de payloads, as bandas mortas e a codificação Sparkplug B acontecem em um lugar onde as ferramentas de software são boas.

Pontos fracos: mais um dispositivo para atualizar, monitorar e fazer backup; o gateway vira um nó crítico; e as leituras por protocolo nativo precisam ser habilitadas nos CLPs, o que às vezes enfraquece proteções do lado do controlador, como o PUT/GET desabilitado.

Combina quando: você está conectando uma linha, uma planta ou uma frota mista. É a escolha padrão para a maioria das plantas existentes (brownfield).

Arquitetura 3: encaminhamento via SCADA

O servidor SCADA ou IHM existente já faz polling de cada CLP. Um módulo ou script MQTT nesse servidor encaminha tags selecionadas para o broker, muitas vezes em Sparkplug B. O Ignition é um exemplo comum; veja Ignition com MQTT.

Pontos fortes: reaproveita o banco de tags, a configuração de alarmes e a nomenclatura existentes; nenhuma nova conexão com os CLPs; um único lugar para gerenciar o que sai da planta.

Pontos fracos: os dados da nuvem passam a depender da disponibilidade e do licenciamento do SCADA; os nomes de tags do SCADA podem não seguir o padrão de nomenclatura corporativo; e o servidor SCADA, normalmente um ativo OT de alto valor, passa a ter um caminho de saída para a internet.

Combina quando: o SCADA já cobre os ativos que interessam e a equipe dele é dona da integração.

Arquiteturas de CLP para a nuvem lado a lado

Muitas plantas acabam misturando as três: fabricantes de máquinas entregam equipamentos com conexão nativa, linhas legadas passam por gateways e o SCADA encaminha seus resumos de alarmes e de produção.

Padrões de segurança para CLP na nuvem

A segurança é onde esses projetos decolam ou travam. Os padrões abaixo valem independentemente da arquitetura.

1. Apenas saída. Os dispositivos da planta iniciam conexões TLS com o broker. Nada de redirecionamento de portas de entrada, nada de VPN para as redes de controladores para coletar dados.
2. Segmente por nível. Mantenha os CLPs na zona de controle. Coloque os gateways na fronteira ou em uma DMZ industrial e permita que só o gateway alcance o broker. O padrão de DMZ MQTT explica o posicionamento do broker entre OT e TI.
3. TLS em tudo fora da célula. Use a porta 8883 com validação de certificado; nunca desabilite a verificação para fazer uma conexão funcionar.
4. Uma identidade por publicador. Cada CLP ou gateway recebe seus próprios usuário, senha e client ID, para que um dispositivo comprometido possa ser revogado sem afetar os outros.
5. Somente leitura por padrão. Trate escritas da nuvem para o CLP como um projeto separado, com listas de permissões, verificação de faixas, intertravamentos no CLP e trilha de auditoria.
6. Mantenha segredos fora dos projetos. Não faça commit de senhas do broker em projetos de CLP ou repositórios de gateway compartilhados entre equipes.
7. Fique atento a abusos. Use um broker que limite inundações de mensagens e bloqueie logins com falhas repetidas, e gere alertas quando um publicador esperado desaparecer.

O ConnectMQ, por exemplo, aplica cotas por plano, proteção contra inundação e bloqueio de IP após falhas repetidas de login em todos os brokers, então essas proteções não dependem de cada planta acertar a própria configuração.

Confiabilidade e qualidade dos dados

Uma conexão que funciona em uma demonstração não é a mesma coisa que uma que entrega dados confiáveis por anos. Verifique estes pontos antes da entrada em operação:

• Report by exception com heartbeats. Publique em mudanças significativas, mais uma atualização periódica, para que valores parados possam ser diferenciados de links mortos.
• Last Will e status retido. Um estado online ou offline retido por publicador permite que todo consumidor saiba o que é atual.
• Timestamps na origem. Marque o horário dos valores onde são lidos, não onde são recebidos, e mantenha os relógios sincronizados com NTP.
• Buffer. Decida o que acontece durante uma queda da WAN: descartar, armazenar em memória ou armazenar em disco e reenviar em ordem.
• Nomenclatura. Defina uma hierarquia de topics baseada em ISA-95 antes de o segundo site se conectar. Renomear depois sai caro.

Testando o caminho de rede

Antes de construir qualquer coisa, prove que a rede da planta consegue alcançar um broker via TLS. A partir de uma máquina na zona onde o publicador vai rodar:

mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -i plant-path-test-9x2c -t 'connectmq/demo/9x2c/path-test' -m 'hello from the plant'

Se falhar por timeout, o firewall bloqueia a saída na 8883. Se falhar durante o handshake, um proxy de inspeção TLS pode estar substituindo os certificados, uma conversa a ter cedo com a equipe de rede. O comando usa o servidor MQTT público (gratuito), que é compartilhado, pode ser lido por qualquer pessoa e serve para testes e protótipos, então envie apenas textos de teste, nunca dados de produção.

Onde o broker deve ficar

Suas opções são um broker local (on-premises), um broker que você mesmo opera na nuvem ou um broker MQTT gerenciado. Brokers locais são úteis para consumidores locais e designs com DMZ; para dados de toda a empresa, um broker na nuvem acessível a partir de todos os sites é mais simples. O ConnectMQ oferece isso como serviço gerenciado com MQTT 3.1.1 e 5.0, TLS na 8883 e opções que vão de planos Serverless compartilhados a clusters Dedicated e implantações BYOC na sua própria conta de nuvem. A visualização de dispositivos do portal entende topics ISA-95 e Sparkplug B, então dados de clientes nativos de CLP, gateways e SCADA chegam a uma única hierarquia navegável.

Checklist de decisão

1. Quantos CLPs, de quantos fabricantes, estão no escopo este ano?
2. Os programas dos CLPs podem ser alterados e baixados, e quem aprova isso?
3. O SCADA já faz polling dos ativos de que você precisa?
4. Qual a latência de dados exigida: segundos, minutos ou horas?
5. O que acontece com os dados durante uma queda da WAN, e por quanto tempo?
6. Qual zona pode iniciar conexões de saída, e em quais portas?
7. Quem será responsável por atualizações do gateway, certificados e monitoramento?
8. Algum caminho de escrita da nuvem para o CLP é necessário, e ele passou por avaliação de riscos?

Se as respostas apontam para muitos fabricantes, nenhuma alteração nos CLPs e quedas longas, comece com um gateway de borda. Para a arquitetura de ponta a ponta, continue com o guia de IoT industrial com MQTT.

Comece seu projeto de CLP para a nuvem com o ConnectMQ

Seja qual for a arquitetura escolhida, ela precisa de um broker MQTT na nuvem confiável do outro lado. Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, e conecte hoje mesmo seu primeiro CLP ou gateway via TLS.

Perguntas frequentes

Qual é a forma mais segura de conectar um CLP à nuvem?

Mantenha o CLP na sua zona de controle, deixe um gateway ou um broker na DMZ fazer apenas conexões TLS de saída, dê a cada publicador suas próprias credenciais e mantenha o caminho de dados somente leitura.

Preciso de um gateway de borda para levar o CLP à nuvem?

Nem sempre. Alguns CLPs podem publicar MQTT nativamente, mas os gateways costumam ser preferíveis para frotas de vários fabricantes, buffer durante quedas e para manter os programas dos CLPs inalterados.

OPC UA ou MQTT: qual é melhor para levar o CLP à nuvem?

O OPC UA se destaca no acesso local e estruturado aos dados do CLP, enquanto o MQTT é melhor para distribuir eventos a muitos consumidores na nuvem. Muitas arquiteturas leem via OPC UA na borda e publicam via MQTT.

Os dados do CLP devem ir para a nuvem em tempo real?

A maioria dos casos de uso na nuvem precisa de segundos a minutos, não de milissegundos. Mantenha o controle em malha fechada local e envie dados por report by exception para cima.