Um módulo de trilho DIN falando MQTT para a nuvem, BACnet para o edifício e Modbus TCP para as máquinas. Essa frase costumava descrever um painel cheio de gateways. Agora descreve uma única CPU compacta com capacidade Ethernet, e a história multi-protocolo na plataforma xLogic não é um slide de marketing — está no firmware, documentada nas revisões do manual: MQTT desde V1.04, BACnet desde V1.57, Modbus desde o primeiro dia.
Aqui está como usar isso sem criar um pesadelo de manutenção.
O Mapa de Protocolos
Cada protocolo tem seu público natural, e o truque é mantê-los separados:
- Modbus TCP— o chão da máquina: VFDs, HMIs, SCADA, outros PLCs. Determinístico, baseado em registros, o aperto de mão industrial universal.
- MQTT— a nuvem: publique telemetria para um broker, painéis se inscrevem. Orientado a eventos, amigável ao NAT, construído para redes não confiáveis.
- BACnet— o edifício: salas de planta, AHUs, cabeçotes de BMS. A língua nativa da indústria imobiliária.
Uma CPU servindo os três públicos significa que o construtor da máquina, o gerente de instalações e o painel da nuvem veem o mesmo dispositivo — cada um em sua própria linguagem, nenhum deles precisando de uma caixa conversora.
Edifício Real: Pequena Sala de Planta
Uma sala de planta com um AHU, dois grupos de fan-coil e uma bomba de calor: Modbus TCP para o HMI local e os VFDs, BACnet para o BMS do edifício para agendamentos e alarmes, MQTT para um serviço de nuvem para tendências remotas. Três protocolos, um controlador, um programa. O engenheiro do BMS perguntou quem fez o gateway. A resposta — "não há gateway" — gerou um silêncio que durou cinco segundos completos.
Esse silêncio é o produto funcionando.
O que Manter Separado
Os protocolos podem compartilhar a CPU, mas não devem compartilhar o plano de dados. Mapeie os pontos uma vez, deliberadamente: quais registros são visíveis para Modbus, quais objetos são BACnet, quais tópicos são MQTT. Um único mapa de pontos, mantido em uma planilha, previne a falha clássica — um número de registro mudando e três sistemas ficando obsoletos silenciosamente.
E lembre-se dos limites do modelo: BACnet/IP e MQTT precisam das CPUs com capacidade Ethernet. Os modelos apenas seriais mantêm Modbus RTU e BACnet/MSTP. Verifique o modelo em relação à exigência antes da promessa, não depois do pedido de compra.
O Ângulo de Suporte Que Ninguém Precifica
Multi-protocolo não é apenas um recurso; é uma porta de vendas. As licitações agora pedem integração BMS como padrão, conectividade em nuvem como um item da lista de verificação. Um controlador que atende a ambos sem complementos passa pelo filtro de pré-qualificação. A diferença de preço entre as versões de protocolo único e multi-protocolo é pequena; a diferença nos projetos que você pode licitar não é.
Disciplina do Mapa de Pontos
Multi-protocolo é uma bênção e uma armadilha. A bênção: uma CPU servindo três sistemas. A armadilha: três sistemas lendo versões ligeiramente diferentes da verdade. A solução é chata e não negociável — um único mapa de pontos que lista cada valor uma vez, com seu registro, seu objeto BACnet e seu tópico MQTT na mesma linha.
Comece a planilha no primeiro dia, antes que o primeiro bloco seja conectado. Colunas: nome do valor, registro Modbus, tipo e instância do objeto BACnet, tópico MQTT, tipo de dado, escalonamento, taxa de atualização e qual sistema é autoritário para gravações. A última coluna importa mais do que as pessoas pensam — quando o BMS e o painel da nuvem querem ambos alterar um ponto de ajuste, alguém tem que vencer, e o mapa diz quem. Sem ele, dois sistemas brigam por um valor e a máquina se comporta de forma imprevisível às 3 da manhã.
Versione o mapa com o programa. Cada mudança de firmware, cada ponto adicionado, cada renumeração — o mapa é atualizado no mesmo commit. Eu herdei projetos onde o mapa estava desatualizado há dois anos e três pessoas tinham cópias diferentes. Reconstruí-lo levou uma semana de olhar para tabelas de registro. Uma semana. Não seja esse projeto.
E teste os caminhos entre protocolos deliberadamente: escreva um ponto de ajuste do BMS, verifique se a máquina responde, verifique se o painel da nuvem mostra a mudança. Um teste de ponta a ponta por ponto, na comissionamento, captura os erros de mapeamento enquanto ainda são baratos para corrigir.
Realidade de Firmware e Versão
Os recursos do protocolo chegaram em ondas, e a história do histórico de revisões do manual conta a história: MQTT em 4.2, o servidor web em 4.5, instruções de WiFi em 6.0, BACnet em 6.2, suporte a SR-22 em 6.2.1. Se você está planejando um projeto multi-protocolo, a versão do firmware não é um detalhe — é uma exigência. Uma CPU que foi enviada há dois anos pode precisar de uma atualização antes de falar BACnet, e o caminho de atualização depende do modelo.
Faça a verificação do firmware parte da lista de verificação de pré-vendas. Anote a versão no pedido, confirme-a na entrega e documente-a na folha de comissionamento. A conversa mais cara neste negócio é "deveria suportar isso" seguida de "este não suporta."
E mantenha os protocolos honestos sobre suas forças. BACnet para o edifício, Modbus para as máquinas, MQTT para a nuvem — cada um no tipo de fio para o qual foi projetado. A CPU Ethernet lida com os três simultaneamente; não faz magicamente deles um único protocolo, e não deveria. A separação é o que mantém a planta funcionando quando a conexão com a nuvem cai — o tráfego local de Modbus e BACnet não espera pela internet.
O Hábito de Documentação do Protocolo
Um controlador de três protocolos sem um mapa de protocolo é uma exposição de museu. A disciplina custa uma hora na comissionamento e economiza uma semana toda vez que o edifício muda: uma folha listando cada ponto, seu registro Modbus, seu objeto BACnet e seu tópico MQTT — com a autoridade de gravação marcada. A folha vive com os desenhos do painel, versionada com o programa. Quando o engenheiro do BMS pergunta "qual valor é a temperatura de suprimento?" a resposta é uma linha, não uma tarde de arqueologia de registro.
Compre a versão com os protocolos. Os projetos seguirão.
