Controle de Setpoint de HVAC em um Gateway de Borda: Hardware, Implantação e Resultados Medidos

Aviso de uso

Este é um recomendador de setpoint supervisório, não um sistema de controle com certificação de segurança: os intertravamentos e controles de segurança próprios da planta têm precedência, e nenhum valor de economia de energia é declarado.

O que esta solução faz

Uma planta central de HVAC em um escritório, shopping ou fábrica normalmente opera com um cronograma fixo: o mesmo setpoint esteja o andar cheio ou vazio. Esta solução coloca um gateway ao lado da planta que lê o controlador de HVAC e um medidor de energia em um modelo de ponto único, aprende uma recomendação de setpoint a partir dos próprios dados históricos daquele edifício e a escreve de volta no controlador; uma escrita conta como aplicada somente depois que o valor tiver sido lido de volta do campo e corresponder ao que foi enviado.

Ela é usada em planta central: chillers, unidades de tratamento de ar e os controladores à sua frente. Não é para aparelhos de ar-condicionado tipo split e não está no circuito de segurança.

• Seleção e implantação: página de design de referência
• Repositório de código-fonte: não publicado. github.com/Seeed-Solution/Solution_HVAC_SmartControl não é acessível publicamente.

• Controladores e medidores existentes conectam-se como estão

  Controladores que falam OPC UA, Modbus TCP, Modbus RTU sobre RS-485 ou BACnet/IP não são substituídos, e o medidor SDM630 tem um modelo integrado. Até 2.000 pontos, dos quais até 50 podem ser graváveis.

• Cada escrita é lida de volta e verificada

  Valor, qualidade, carimbo de data/hora e prioridade do último valor conhecido como bom são congelados antes da escrita; o ponto é relido após um atraso de estabilização e comparado dentro de uma tolerância. Uma leitura de retorno cuja qualidade não seja boa não é aprovada.

• Rollback automático e alarmes em falhas

  Incompatibilidade na leitura de retorno, fonte offline, previsão desativada, abortar pelo operador e um lote parcialmente aplicado acionam um rollback. Os alarmes são indexados pela causa, então uma falha recorrente reutiliza o alarme aberto.

• Capacidade medida: 2.000 pontos a 349,99 eventos/s

  Contra uma meta de 350,0, medido em uma execução de loopback de 180 s em um reComputer série R2000. As condições estão no apêndice.

O que o console mostra

O console em execução renderiza a tabela de pontos com qualidade por ponto, a página de acesso com cada fonte e sua contagem de pontos registrados, e um livro-razão de recebimento de comandos. É no livro-razão que o caminho de escrita fica visível: cada linha traz o valor solicitado, o valor efetivo, o ator, o reconhecimento do protocolo e — após o atraso de estabilização — o resultado da leitura de retorno. Uma escrita cujo registrador tenha sido alterado fora de banda é lida como mismatched, compensated com o valor que foi encontrado, e o comando de compensação emitido por plugin:prediction:rollback aparece como a próxima linha.

A página de acesso lista cada fonte com sua contagem de pontos registrados; este é o primeiro lugar em que a fiação aparece como funcionando:

A tabela de pontos traz a qualidade por ponto, então um ponto que não esteja lendo good fica visível aqui:

A página de runtime da previsão mostra os setpoints recomendados desta rodada, a janela de histórico por trás deles e o modo de controle atual:

O caminho de escrita é visível no livro-razão de recebimento de comandos — valor solicitado, valor efetivo, ator, reconhecimento do protocolo e leitura de retorno recebem cada um uma coluna:

As capturas acima estão conectadas aos próprios simuladores de protocolo do pacote, não a um medidor ou controlador físico; o lado do gateway executa o software fornecido.

De que hardware você precisa

Três coisas: um controlador que você já tenha, um medidor e um host Docker.

① O controlador de HVAC — qualquer que já esteja à frente da planta, desde que fale OPC UA, Modbus TCP/RTU ou BACnet/IP. Para um teste em seco sem planta conectada, o pacote inclui um simulador OPC UA na porta 4841.

② O medidor de energia — um Eastron SDM630 no mapa de registradores Modbus V2, via Modbus TCP, um gateway Modbus TCP ou RS-485. Dez pontos somente leitura: tensão e corrente trifásicas, potência ativa total (kW), fator de potência total, frequência, energia ativa importada (kWh).

③ O host do gateway — o único dispositivo que você precisa escolher. O serviço é uma carga de trabalho Docker em x86-64 ou arm64, então uma máquina Linux já na rede da planta é um alvo suportado.

	Gateway	Armazenamento	Quando escolhê-lo
	reComputer R1124-10 4 GB RAM, RS-485 / RS-232 / DI / DO on board	16 GB eMMC	O histórico fica em um servidor; o gateway mantém uma pequena janela local
	reComputer R1125-10 mesma placa, eMMC maior	32 GB eMMC	Meses de histórico de operação permanecem no gateway; o conjunto de treinamento pode ser reimportado localmente

A série R1100 traz RS-485 on board, então um medidor em RS-485 não precisa de adaptador USB. O serviço em si precisa de cerca de 1 GB de disco; o armazenamento decide quanto histórico você pode consultar localmente sem um servidor.

Outros pré-requisitos: Docker Engine 20.10 ou mais recente, portas 8280 e 4841 livres no host e pelo menos uma semana de operação histórica em CSV ou Excel com colunas de carimbo de data/hora, setpoint, temperatura medida e consumo de energia.

Limites de Seleção Negativa

• Horizonte de Armazenamento Local: R1124-10 (16GB eMMC) armazena uma pequena janela local; se você precisar de meses de telemetria de alta frequência armazenada on-premise para re-treinamento offline do modelo, escolha o R1125-10 (32GB).
• Intertravamentos de Segurança: Este gateway fornece setpoints de caráter consultivo; nunca o conecte em circuitos de corte de segurança de emergência de caldeiras ou chillers que exijam controladores com certificação de segurança.

Como implantar no local

1. Instale o hardware: fiação

Verifique primeiro a ordem de bytes e palavras do medidor

O modelo SDM630 integrado usa por padrão bytes e palavras em big-endian, conforme o padrão publicado pelo fornecedor. Leia um registrador com um valor físico conhecido e compare com o próprio visor do medidor. Tensão e frequência que são próximas mas incorretas, ou energia importada que salta para trás, geralmente significam um erro na configuração da ordem das palavras; verifique a ordem das palavras antes da fiação.

Coloque o gateway na mesma rede que o controlador e o medidor (ou seu gateway Modbus TCP). Para Modbus RTU, faça o baud rate, a paridade e o unit id corresponderem ao que está configurado no medidor; uma incompatibilidade aparece apenas como timeout, sem mensagem de erro. Use o perfil de deployment serial-device: o perfil Docker padrão não anexa nenhum dispositivo serial do host, portanto não há /dev/ttyUSB0 dentro do contêiner.

2. Software: três etapas

Os campos de formulário por etapa e os pacotes de aplicação estão na página do reference design; escolha uma configuração para o seu site e faça o download.

Escolha uma configuração e faça o download 🖱️

Resumo:

1. Fazer o deploy do serviço — deployment Docker, seja na máquina que executa a ferramenta de deployment ou via SSH para um dispositivo na rede da planta. O formulário carrega o transporte do medidor, o endpoint OPC UA, os limites de segurança, o modo de controle e os limiares de alarme.
2. Abrir o console — criar o primeiro administrador e confirmar que ambas as fontes estão online com suas contagens de pontos esperadas. O assistente de acesso solicita endereço e intervalo de polling por protocolo:

3. Comissionar — registrar o medidor, executar previsões em modo observe, injetar falhas de propósito e só então habilitar escritas. Antes que um lote seja enviado, confirme na página de seleção exatamente quais pontos ele cobre:

Deixe Control Mode em observe e deixe Safety Baseline Approved By em branco. Enquanto o aprovador estiver em branco, a baseline aparece como não aprovada; inserir um nome significa que esse engenheiro aprova os limites de segurança.

A estimativa até um console em execução com leitura de pontos é de cerca de 60 minutos. O comissionamento leva mais tempo, porque inclui um ciclo completo de ocupação com previsões em modo observe revisadas por quem opera a planta.

O que a imagem publicada cobre

A imagem publicada missionpack-knn:v1.6.5 não inclui o template SDM630, o coordenador de rollback nem o envelope de alarme. Na v1.6.5 as subetapas de modo observe ainda se aplicam; as subetapas de medidor, rollback e alarme não podem ser concluídas.

Interfaces disponíveis

Tudo o que o deployment expõe fica atrás de uma porta HTTP no host do gateway. Nada sai da rede da planta a menos que a publicação northbound seja ativada.

• Operadores — o console no navegador em 8280: tabela de pontos com qualidade por ponto, registro de medidor, execuções de previsão, recibos de comando, banner de alarme.
• Monitoramento — GET /system/runtime-metrics. Com a publicação northbound ativada, ele carrega northbound.spool.queued e northbound.spool.dropped; queued voltando para 0 com dropped inalterado é a verificação solicitada na etapa de comissionamento.
• Seu próprio sistema — a mesma superfície de API do console atrás de 8280, além do endpoint de health em que o deployment aguarda na inicialização.

Lista completa de endpoints

Porta / endpoint	O que atende	Precisa de internet
8280 /	Console no navegador	Não
8280 /system/runtime-metrics	Contadores de runtime, contadores do spool northbound	Não
8280 /api/v1/health	Health check; a inicialização permite 30 s	Não
4841	Simulador OPC UA embutido, para um dry run	Não

Em um recibo de comando, leia a coluna de readback: protocol_acknowledged só significa que o controlador aceitou o frame. A coluna de readback (matched, ou mismatched, compensated com o valor encontrado) é o que o campo realmente contém. Uma compensação emitida pelo coordenador de rollback aparece como seu próprio recibo imediatamente após a escrita que ele desfez, de modo que o trilho de auditoria fica em ordem sem juntar duas tabelas.

Os logs do contêiner fazem rotação em 10 MB com quatro backups (docker logs missionpack_knn). Exporte o trilho de auditoria de comandos, o journal de rollback e o histórico de alarmes antes que expirem.

Escopo de protocolo southbound

Todos os pontos ficam em um único registro, limitado a 2.000 pontos, dos quais no máximo 50 podem ser graváveis. Os 10 pontos de medidor SDM630 são somente leitura; eles contam para os 2.000 e não para os 50.

Transporte	Papel	Restrições
OPC UA	Leitura e escrita no controlador de HVAC	Endpoint definido por deployment; simulador embutido em 4841
Modbus TCP	Medidor e controladores	Unit id e porta por fonte; direto ou por meio de um gateway TCP
Modbus RTU (RS-485)	Medidor	Precisa do perfil de deployment serial-device; o perfil padrão não anexa dispositivos seriais do host
BACnet/IP	Leitura e escrita em unidades de tratamento de ar	Escritas usam uma prioridade e liberam com Null. COV subscription, registro BBMD e MS-TP não estão implementados

Desempenho e dados medidos

Tudo aqui foi medido contra o simulador de protocolo em loopback; não há dados de site de edifício, e cada valor vem de uma única execução, salvo indicação em contrário.

Capacidade

Métrica	Valor	Condições
Throughput de amostragem	349,99 eventos/s (99,99% da meta de 350,0)	2.000 pontos, 4 fontes de protocolo
Taxa de previsão	0,939 ciclo/s	Mesma execução
Pico de RSS do process-group	217,3 MiB	Mesma execução

Condições para todas as três linhas: 2.000 pontos em 4 fontes de protocolo, OPC UA e Modbus amostrados a cada 5 s, BACnet a cada 10 s, apenas loopback, execução de 180 s, em um reComputer série R2000 (arm64).

Reprodução: upstream b5fe4cc, captura capacity-smoke r14

Latência

Métrica	Valor	Condições
Latência do ciclo de previsão	46,27 ms máx	n = 4 ciclos, sem carga
Latência de admissão de controle	1,41 ms máx	n = 2 ciclos, sem carga

Ambas refletem apenas o custo do próprio caminho de código.

Reprodução: upstream f831bae, baseline de runtime de northbound-smoke

Runtime e parâmetros principais

O modelo de previsão é KNN, treinado no próprio histórico operacional do edifício (CSV ou Excel com colunas de timestamp, setpoint, temperatura medida e potência); o serviço é uma workload Docker em x86-64 ou arm64. Cada previsão pode ser revisada no console antes de ir para o controlador.

• Modo de controle e limites de segurança: o modo de controle é fornecido como observe, portanto nenhum ponto é escrito até que um operador o altere. O mínimo / máximo de setpoint de 18 / 30 °C, a mudança máxima de 1,0 °C por 300 s e a lista permitida de modos off / fan / cool / heat / auto são todos placeholders; preencha-os para a planta.
• A verificação de write-back vem desativada por padrão: a configuração de execução de previsão (criada no console) deve declarar "rollback": { "enabled": true, "settle_seconds": 2.5 } explicitamente; uma configuração sem seção rollback é tratada como enabled: false.
• settle_seconds (0–30, padrão 1,0) deve ser maior que o intervalo de amostragem da fonte, ou o readback verá o valor pré-escrita e reportará uma divergência que não existe.

Degradação conhecida

• A taxa de previsão tem um teto estrutural (ainda não corrigido): o loop de previsão dorme um intervalo fixo após cada ciclo, portanto sua taxa é 1/(1.0 + t_cycle). Em 2.000 pontos t_cycle é cerca de 0,119 s, o que coloca o teto perto de 0,894 ciclo/s, abaixo do limite de 0,90 exigido pelo soak test.
• Somente escritas Modbus são verificadas por readback: uma saída BACnet não tem prioridade de escrita disponível e é ignorada.
• Ordem de bytes: até ser verificada em relação ao próprio display do medidor, os pontos do medidor são decodificados com a ordem de palavras vendor-default (big-endian) e podem estar errados.

Próximas etapas

• Leitura/escrita com readback independente contra dispositivos reais OPC UA, Modbus TCP, Modbus RTU (USB-para-RS-485) e BACnet/IP em um reComputer série R10 ou reTerminal DM.
• Uma execução de 72 horas sem supervisão nos mesmos hosts de destino, com exercícios de recuperação de rede, broker, processos e dispositivos durante a execução.

Fontes de dados e ativos

• Mapa de registradores SDM630 — documento publicado pela Eastron sobre o protocolo Modbus (mapa de registradores Modbus V2, registradores de entrada float32 IEEE-754). Os endereços seguem esse documento; a ordem de bytes e palavras big-endian é o padrão do fornecedor.
• Dados históricos de operação — fornecidos pelo site que faz o deployment. Nada é distribuído com o pacote, e nenhum conjunto de dados público é usado ou exigido.
• Capturas de console — capturas de tela originais do software empacotado em execução contra os próprios simuladores de protocolo do pacote. A configuração do simulador, o host de captura e os checksums são registrados em gallery/ATTRIBUTION.md do pacote. Nenhum ativo de terceiros, marca registrada ou imagem de stock é incluído.
• Diagrama de arquitetura — desenhado a partir de um IR de arquitetura estruturado; trabalho original, sem arte de terceiros.