Protocolos e integração
KNX, BACnet e Modbus: guia de protocolos
Em que diferem o KNX, o BACnet e o Modbus quanto ao modelo de dados, à topologia e ao esforço de integração, e como combiná-los num único sistema de automação de edifícios sem perder o controlo da lista de pontos.
Resposta rápida
O KNX é um barramento de campo descentralizado para iluminação, sombreamento e controlo de salas; o BACnet é um protocolo de automação de edifícios orientado a objetos, para instalações técnicas e sistemas de supervisão; o Modbus é um protocolo simples baseado em registos, para contadores, variadores e equipamentos. A maioria dos edifícios utiliza mais do que um, ligados através de gateways e de um mapa de pontos documentado.
Porque é que a escolha do protocolo é importante
Os protocolos não são uma preferência abstrata. Determinam que dispositivos podem integrar o sistema, que ferramenta de engenharia é necessária, como são designados os dados, quantos gateways existem pelo meio e quem poderá assegurar a manutenção da instalação mais tarde. Um protocolo com um modelo de objetos rico torna a integração previsível; um protocolo baseado em registos oferece flexibilidade, mas deixa o significado ao integrador. Um barramento descentralizado reduz a dependência de um controlador central; um protocolo de supervisão sobre IP facilita a integração das instalações técnicas e o diagnóstico remoto. A maioria dos edifícios acaba com mais do que um protocolo, porque a iluminação, as instalações técnicas, a medição e o controlo de salas têm histórias e ecossistemas de dispositivos diferentes. A tarefa de projeto consiste em colocar cada protocolo onde se adequa e tornar as fronteiras explícitas, em vez de declarar um vencedor. Um protocolo fácil de instalar mas difícil de documentar custará mais ao longo da vida do edifício. É na fronteira que reside a maior parte do risco de integração: um gateway sem responsável é uma falha à espera de uma entrega. A escolha do protocolo é, por isso, uma decisão de ciclo de vida e não uma preferência de compra. A questão não é saber que protocolo é aberto, mas que partes da instalação continuam a poder ser mantidas quando o integrador original já não estiver disponível. Uma decisão tomada apenas pelo empreiteiro elétrico ignora habitualmente a equipa de manutenção.
- Ecossistema de dispositivos e ferramentas de engenharia
- Modelo de dados e nomenclatura
- Número de gateways e pontos de falha
- Manutenibilidade e suporte ao ciclo de vida
KNX: controlo de salas descentralizado
O KNX é um barramento de campo para controlo de edifícios, amplamente utilizado em iluminação, sombreamento, terminais de AVAC e funções de sala. Os dispositivos são endereçados individualmente e comunicam através de endereços de grupo, pelo que um interruptor pode comandar uma luz sem um programa central. A engenharia é feita no ETS, onde se definem a estrutura de endereços de grupo e os parâmetros dos dispositivos. O modelo descentralizado é resiliente: se um dispositivo falhar, o resto do barramento continua a funcionar. O KNX pode ser prolongado sobre IP com routers e interfaces, o que o torna viável entre pisos e edifícios. O seu ponto forte é o controlo de salas normalizado, com um mercado de dispositivos alargado. A sua limitação é que as sequências complexas das instalações técnicas e a lógica entre sistemas residem habitualmente num controlador de supervisão ou num gateway, e não no próprio barramento. Um plano de endereços de grupo bem estruturado é a diferença entre uma instalação KNX sustentável e um projeto que ninguém quer tocar. Os endereços de grupo devem ser planeados por função e localização, e não pela ordem de instalação dos dispositivos. Uma linha suporta tipicamente 64 dispositivos; os acopladores e os segmentos ampliam a instalação, e cada fronteira deve ser documentada. Os endereços de grupo devem também deixar margem para um novo piso ou para uma alteração de arrendamento. Um barramento fácil de ampliar é também fácil de ampliar em excesso.
- Barramento de par entrelaçado com lógica descentralizada
- Endereçamento individual e de grupo
- O ETS como ferramenta de engenharia
- Encaminhamento IP para instalações de maior dimensão
BACnet: objetos e integração de supervisão
O BACnet é um protocolo orientado a objetos, concebido para a automação e o controlo de edifícios. Um dispositivo expõe objetos como entrada analógica, saída analógica, valor analógico, entrada binária, saída binária, valor binário e objetos multiestado. Cada objeto tem propriedades: valor presente, unidades, indicadores de estado, descrição e limites de alarme. Os serviços permitem leitura, escrita, descoberta e subscrição de alteração de valor. O BACnet funciona sobre IP e sobre MS/TP, o que lhe permite alcançar controladores de instalações técnicas e dispositivos de campo no mesmo local. O seu modelo de objetos torna a integração mais previsível do que um mapa de registos em bruto, desde que os nomes dos objetos e as unidades sejam coerentes. Os testes BACnet e as listas de dispositivos certificados ajudam, mas não substituem uma verificação ponto a ponto durante o comissionamento. Uma nomenclatura coerente entre dispositivos vale mais do que uma longa lista de objetos. O defeito de integração mais comum não é uma falha do protocolo; é um ponto associado ao objeto errado ou com escala incorreta. Um navegador de objetos mostra o que existe, não o que significa. O acesso ao nível das propriedades é importante: um dispositivo que expõe um valor mas não permite escrever o respetivo setpoint não pode suportar uma sequência de reset. A lista de objetos deve registar que propriedades são de escrita, e não apenas as que são de leitura.
- Dispositivos, objetos, propriedades e serviços
- Tipos de objeto normalizados para pontos
- Segmentos BACnet/IP e MS/TP
- Descoberta, COV e teste de pontos
Modbus: registos e limites práticos
O Modbus é um protocolo simples de pedido-resposta, estruturado em torno de coils e registos. O Modbus RTU funciona sobre ligações série; o Modbus TCP transporta o mesmo modelo em Ethernet. Um mestre interroga os escravos por endereço de unidade e código de função, lendo ou escrevendo um número definido de registos. O protocolo define o transporte, não o significado: um registo pode ser uma temperatura, uma palavra de estado, um contador de energia ou uma versão de firmware. É essa flexibilidade que explica a sua utilização em contadores, variadores de frequência, inversores e sensores, e a razão pela qual cada integração necessita do mapa de registos do fabricante. Preste atenção à escala, aos valores com sinal, à ordem das palavras de 32 bits, aos intervalos de polling e ao comportamento do timeout. Um dispositivo Modbus que deixa de responder deve gerar uma falha clara, e não um valor antigo que parece válido. Um registo que lê zero pode significar desligado, em falha ou não configurado; o mapa deve indicar qual. Documentar o mapa de registos é mais valioso do que qualquer configuração de gateway, porque é disso que o engenheiro seguinte vai precisar. Um segmento série suporta tipicamente 32 unidades sem repetidor, e interrogar demasiados dispositivos expõe rapidamente o limite. O mapa de registos deve ser versionado com o firmware do dispositivo, porque os endereços mudam. O diagnóstico série é limitado; um analisador de protocolo é uma ferramenta de comissionamento, não uma solução permanente.
- RTU sobre série, TCP sobre Ethernet
- Polling mestre-escravo e endereços de unidade
- Coils e registos com significado específico do fabricante
- Escala, ordem de bytes e comportamento do timeout
DALI e outros barramentos de campo
O DALI merece uma abordagem separada, porque a iluminação é frequentemente a maior população de dispositivos de um edifício. Uma linha DALI endereça drivers e dispositivos de controlo individuais, tipicamente 64 por linha, e transporta comandos lentos mas fiáveis. Não é uma rede de edifício; os gateways ligam-na ao KNX, ao BACnet ou a um controlador. O DALI-2 acrescenta declarações de interoperabilidade para sensores e dispositivos de controlo, o que é relevante quando produtos de vários fabricantes partilham uma linha. A iluminação de emergência pode ser monitorizada através do DALI quando as luminárias o suportam, mas o regime de ensaios e a obrigação de comunicação de resultados continuam a ser locais. Os erros comuns são a dispersão de endereços, a ausência de mapas e um gateway tratado como um cabo transparente. Uma integração de iluminação deve registar a linha, o endereço, o grupo e a pertença a cenas de cada luminária, porque é esse registo que a manutenção utiliza efetivamente. Outros barramentos, como 0-10V e a regulação por corte de fase, continuam a existir e devem ser integrados onde estão, em vez de substituídos por uniformidade. O projeto deve indicar qual barramento é responsável por cada luminária, porque dois caminhos de comando para um mesmo driver são uma falha previsível. Um gateway DALI que perde o seu mapa pode deixar um piso às escuras sem que um único driver falhe. Os resultados dos ensaios de emergência devem ser exportados num formato que a pessoa responsável possa assinar.
- Endereçamento individual de drivers e grupos
- Declarações de interoperabilidade DALI-2
- Gateways para KNX, BACnet ou controladores
- Registos de linha, endereço e cenas na entrega
Combinar protocolos sem uma pilha frágil
Um projeto prático coloca cada protocolo onde o seu ecossistema de dispositivos é mais forte: KNX para o controlo de salas, DALI para luminárias, BACnet para instalações técnicas e equipamento de supervisão, Modbus para contadores e variadores. Os gateways fazem a tradução entre eles, mas cada gateway é um dispositivo com alimentação, firmware, configuração e um modo de falha. Mantenha o número de gateways deliberado, documente cada um e decida o que acontece quando fica offline. Coloque as sequências de controlo onde possam ser executadas localmente, e não apenas no gateway. Segmente as redes para que uma falha num segmento não derrube o edifício inteiro. A sincronização horária é importante para a análise de tendências e a correlação de alarmes. A arquitetura de integração deve poder ser explicada numa página; se exigir um diagrama que ninguém consegue seguir, provavelmente é demasiado profunda. O projeto deve também indicar que sistema detém o relógio principal e como o tempo é distribuído. Uma pilha simples e documentada é mais fácil de testar e mais barata de manter do que uma cadeia de tradutores. Cada camada de tradução adicional acrescenta latência, um ficheiro de configuração e uma pessoa que tem de compreender ambos os lados. Um gateway que traduz nos dois sentidos necessita de uma regra para comandos conflituosos, e não apenas para dados perdidos. A sincronização horária deve provir de uma única fonte, e não de cada gateway de forma independente.
- Um protocolo por ecossistema de dispositivos
- Gateways deliberados e documentados
- Sequências locais independentes dos gateways
- Segmentação de rede e sincronização horária
Critérios de decisão e seleção de gateways
A seleção de gateways decide-se habitualmente com três perguntas: o que o dispositivo expõe, o que o sistema de supervisão consegue consumir e quem dará suporte à ligação. Uma interface nativa é preferível a um gateway quando existe, porque retira um dispositivo e um ficheiro de configuração do caminho crítico. Um gateway justifica-se quando o protocolo não é nativo, quando é necessário isolamento elétrico ou quando o número de dispositivos excede o que o controlador consegue interrogar de forma fiável. A capacidade não é apenas um número de pontos; a carga de polling, o tempo de resposta e o número de ligações simultâneas também contam. Verifique se o gateway suporta os tipos de objeto e os serviços de que a sequência necessita, e não apenas se consegue ler um valor. Confirme o suporte de firmware e a política de atualizações do fabricante. Registe quem configura o gateway, quem é responsável pela sua cópia de segurança e quem é chamado quando falha. O gateway mais barato raramente é a integração mais barata quando se contabiliza o suporte. Um gateway que não pode ser salvaguardado não pode ser substituído numa tarde. Dois gateways em série devem ser considerados um indício de mau projeto, mesmo quando cada um funciona isoladamente. Um gateway sem capacidade de reserva torna-se a razão do atraso da fase seguinte. Como regra de planeamento, mantenha a carga de polling e o número de dispositivos bem abaixo do máximo documentado e trate metade da capacidade declarada como nível de aviso, e não como objetivo.
- Interface nativa antes do gateway, sempre que possível
- Verificar serviços e tipos de objeto, não apenas valores
- A carga de polling e o tempo de resposta são importantes
- Responsável, cópia de segurança e via de substituição registados
A lista de verificação da integração e os modos de falha
Uma integração está concluída quando cada ponto foi comprovado, e não quando o gateway aparece online. Comece por uma lista de pontos que indique origem, destino, tipo de dados, unidade, intervalo, escala, sentido de leitura ou escrita, classe de alarme e estado de falha. Confirme o mapa de objetos ou de registos face à documentação do fabricante. Teste valores normais, valores fora do intervalo, desligação, reinício e sincronização horária. Verifique se os alarmes chegam com a prioridade correta e se desaparecem corretamente. Confirme que uma falha do gateway produz uma falha visível, e não um valor congelado. Registe os resultados e entregue os mapas, as credenciais e os desenhos de rede. A lista de verificação é também um documento comercial: define aquilo por que o integrador é responsável e o que permanece com o fornecedor do equipamento. Uma lista de verificação assinada transforma uma visita informal de comissionamento em prova de que a integração funciona. Sem ela, cada alteração futura começa com uma investigação em vez de um desenho. A lista deve ser revista em cada fase, e não apenas no final, porque um ponto em falta na lista está normalmente em falta no preço. A lista deve ser assinada pela parte que irá manter o sistema, e não apenas pelo instalador. A lista de pontos é também a defesa mais clara contra o alargamento do âmbito, porque mostra o que foi acordado.
- Lista de pontos com unidades, escala e sentido
- Mapa de objetos ou de registos verificado
- Testes de falha, reinício e sincronização horária
- Mapas, credenciais e desenhos entregues
KNX, BACnet e Modbus em comparação
17 rows| Aspeto | KNX | BACnet | Modbus |
|---|---|---|---|
| Origem e âmbito | Barramento de edifício para dispositivos de sala e de campo | Redes de automação e controlo de edifícios | Protocolo industrial de registos |
| Topologia | Barramento, árvore ou estrela sobre par entrelaçado | IP, Ethernet e MS/TP | RTU série ou TCP |
| Endereçamento | Endereços individuais e de grupo | Instância de dispositivo e identificadores de objeto | ID de escravo ou de unidade mais endereço de registo |
| Modelo de dados | Objetos de grupo e pontos de dados | Objetos, propriedades e serviços | Coils e registos sem semântica |
| Descoberta | Programação do barramento com ETS | Descoberta por broadcast e lista de objetos | Mapa de registos manual |
| Dispositivos típicos | Interruptores, reguladores de intensidade, atuadores e controladores de sala | UTA, arrefecedores, caixas VAV e BMS | Contadores, variadores, inversores e sensores |
| Ferramenta de engenharia | Projeto ETS | Ferramenta do fabricante e configuração do BMS | Manual do fabricante e configuração do polling |
| Modelo de leitura e escrita | Escrita e leitura de grupo | Serviços e matrizes de prioridade | Códigos de função e polling |
| Ensaios | Varrimento do barramento e teste de grupos | Navegador de objetos e teste COV | Teste de leitura, escrita e escala de registos |
| Licenciamento | Licença ETS por projeto | Ferramentas do fabricante e testes de dispositivos | Habitualmente sem licença de protocolo |
| Adequação típica | Iluminação, sombreamento e controlo de salas | Integração de instalações técnicas e supervisão | Medição e dados de equipamentos |
| Erro comum | Dispersão de endereços de grupo | Mapeamento de objetos sem unidades | Ordem de bytes e escala incorretas |
| Limite típico por segmento | 64 dispositivos por linha antes dos acopladores | Segmento MS/TP habitualmente mantido bem abaixo de 127 nós | 32 unidades por segmento série sem repetidor |
| Comportamento de resposta | Rápido para comandos de sala, lento para leituras de grupo extensas | As subscrições COV reduzem a carga de polling | O ciclo de polling cresce com o número de dispositivos |
| Cibersegurança | Barramento local; os routers IP necessitam de reforço de segurança | As redes IP necessitam de segmentação e controlo de acesso | Ligações série isoladas; o TCP necessita de regras de rede |
| Documentação | Plano de endereços de grupo e lista de dispositivos | Lista de objetos com unidades e definições COV | Mapa de registos com escala e ordem das palavras |
| Quando não utilizar | Sequências complexas de instalações técnicas e lógica entre locais | Leituras simples de contadores numa pequena ligação série | Objetos complexos, alarmes e programação horária |
Imagens do projeto
3 images
Perguntas frequentes
01Qual é melhor, KNX ou BACnet?
Resolvem problemas diferentes. O KNX é forte no controlo de salas e de campo; o BACnet é forte na integração de instalações técnicas e na supervisão. Muitos projetos utilizam ambos, com um gateway ou um controlador que fala as duas linguagens. A escolha deve seguir o ecossistema de dispositivos, e não uma preferência. Um projeto que força todos os dispositivos para um único protocolo paga normalmente isso em gateways ou em funcionalidades perdidas.
02Um único controlador pode falar os três protocolos?
Por vezes, através de interfaces nativas ou de gateways. Verifique que protocolos são nativos, quantos pontos suporta cada interface e se o controlador consegue executar as sequências necessárias enquanto interroga dispositivos externos. O suporte nativo numa ficha técnica não garante a capacidade de pontos nem os serviços de que a sequência necessita.
03O Modbus TCP é o mesmo que o Modbus RTU?
Partilham o mesmo modelo de registos, mas utilizam transportes diferentes. O RTU funciona sobre ligações série com restrições de temporização; o TCP funciona sobre Ethernet. Os gateways entre os dois são comuns, e o comportamento do polling deve ser verificado. Um gateway TCP à frente de um dispositivo série lento não torna esse dispositivo mais rápido, e o timeout deve refletir a resposta real.
04O que é um objeto BACnet?
Um objeto é a representação de um ponto ou função dentro de um dispositivo, com propriedades como valor presente, unidades, estado e limites de alarme. A integração associa esses objetos aos nomes de pontos do sistema de supervisão. O mapeamento deve preservar as unidades, a escala e o significado, porque um objeto corretamente ligado mas com unidades erradas continua a ser uma leitura errada.
05Necessito sempre de gateways?
Não. Muitos dispositivos expõem BACnet, Modbus ou KNX diretamente. Um gateway é necessário quando a interface, a topologia ou o licenciamento do fabricante exigem tradução. Cada gateway deve ter um responsável e um comportamento de falha documentado. Cada gateway acrescenta também uma dependência de firmware, pelo que o seu histórico de atualizações deve constar do plano de manutenção.
06Quantos dispositivos cabem num barramento?
Depende do protocolo, do segmento, do orçamento de potência e da topologia. O projeto deve seguir a norma e as regras do fabricante e, em seguida, verificar a carga e os tempos de resposta. Não existe um número universal responsável. Um barramento que funciona em bancada com dez dispositivos pode comportar-se de forma diferente com quarenta, sobretudo quando o polling e a potência estão próximos do limite.
07Como deve ser testada a integração?
Ponto a ponto: valores normais, valores fora do intervalo, desligação, reinício, prioridade de alarmes e sincronização horária. Registe os resultados e entregue os mapas de objetos ou de registos. Um gateway online não é o mesmo que uma integração que funciona. O teste deve incluir também a perda do próprio gateway, porque é essa a falha que o edifício acabará por experimentar.
Próximo passo
Traga-nos o edifício.
Diga-nos o tipo de edifício, os sistemas abrangidos e o resultado pretendido. Indicaremos o caminho mais curto para um sistema funcional.