Arquitetura geral, modos de operação e limites do EMS Builder

O Edge-EMS Builder fica entre os dispositivos de campo e os sistemas superiores, com autonomia na borda como base e possibilidade de expansão para colaboração entre nuvem e borda ou entre vários nós. Ele organiza “ler dados, calcular estados, avaliar regras e executar ações” em uma malha de controle contínua.

Este artigo responde a quatro perguntas:

1. Como a arquitetura geral do Edge-EMS Builder é dividida em camadas?
2. Quais modos de operação são possíveis?
3. Como combinar recursos para atender a um requisito de negócio?
4. Até onde podem ser ampliadas as conexões cabeadas, sem fio e entre instalações?

Aqui, “modos de operação” se refere ao funcionamento do sistema, não às modalidades de parceria comercial. Para as modalidades Platform, Solution e Co-create, consulte Modalidades de serviço do Edge-EMS Builder.

I. Arquitetura geral: campo, borda e nuvem em malha fechada

O Edge-EMS Builder opera na borda; o CommBridge abstrai as diferenças entre protocolos de campo, enquanto MQTT, WebSocket e HTTP conectam a nuvem, o frontend e sistemas de terceiros.

Camada	Responsabilidades principais	Objetos/canais típicos
Negócio e nuvem	Monitoramento unificado, configuração remota, distribuição de estratégias, análise operacional e integração com negócios de terceiros	JelinaCloud, plataforma de nuvem do cliente, SCADA, sistema de despacho; MQTT / HTTP
Interação e integração	Envia dados ao frontend em tempo real, recebe comandos de controle e oferece leitura/gravação a sistemas externos	Frontend Web personalizado, serviços de backend; WebSocket / HTTP
Mecanismo de borda do EMS Builder	Unificação dos dados, cálculo em tempo real, avaliação de estratégias, execução de ações, alarmes, compartilhamento e expansão das configurações	Modelo de dados, mecanismo de expressões, perfis de acionamento, destinos de compartilhamento, UDE
Camada de aquisição CommBridge	Adapta protocolos de baixo nível e converte pontos de campo em dados reconhecidos pelo EMS Builder	Modbus, OPC UA, S7, serial, IEC 101/104, CAN etc.
Camada de dispositivos de campo	Fornece dados em tempo real e executa o controle final	PCS, BMS, medidores de energia, carregadores, inversores fotovoltaicos, sensores e dispositivos de terceiros

Por que dividir em camadas

• Alterações nos dispositivos não exigem reescrever estratégias: protocolos e pontos são adaptados na camada de aquisição, enquanto as estratégias superiores usam dataKey unificado.
• Alterações de negócio não invadem os drivers de comunicação: limites, horários e regras de controle são ajustados na camada de estratégias, sem alterar a implementação dos protocolos dos dispositivos.
• Interface desacoplada do mecanismo de controle: o Edge-EMS Builder não depende de uma UI fixa; o frontend pode assinar dados e enviar comandos por canais padrão.
• A malha local pode permanecer ativa quando a nuvem está indisponível: decisões e ações críticas são executadas na borda; a capacidade offline específica depende da configuração do projeto e de suas dependências externas.

II. Como uma operação de controle é concluída

Qualquer estratégia de negócio pode ser dividida em quatro etapas: “Aquisição → Cálculo → Decisão → Execução”:

Etapa	O que o EMS Builder faz	Exemplo: suporte à capacidade da área atendida por um transformador de distribuição
① Aquisição	O CommBridge lê os pontos originais e os sincroniza com o EMS Builder	Lê a carga do transformador, o estado do PCS e o SOC
② Cálculo	O mecanismo de expressões calcula estados intermediários, margens ou riscos	Calcula o déficit de capacidade e a potência de descarga disponível do armazenamento de energia
③ Decisão	O perfil de acionamento avalia condições e seleciona ações	Inicia o suporte quando a carga se aproxima do limite e o SOC permite
④ Execução	Grava nos dispositivos, registra alarmes, publica por MQTT ou envia ao frontend	Envia a referência de potência ao PCS e informa o estado da execução

Após a execução, potência, SOC e estado dos dispositivos são adquiridos novamente e entram no próximo ciclo de avaliação. Uma estratégia estável também deve incluir limites de entrada/saída, filtragem de oscilações (debounce), prioridades, tratamento de falhas de comunicação, proteção dos dispositivos e intervenção manual, além de um simples IF / THEN.

Dois mecanismos de suporte presentes em toda a malha

• Destinos de compartilhamento: dados de outros nós Edge-EMS Builder podem participar de expressões e condições de gatilho como dados locais, permitindo colaboração entre dispositivos.
• Expansão dinâmica de unidades de dispositivo (UDE): defina uma vez o template de dispositivos semelhantes; quando novas instâncias são conectadas, as configurações de agregação, agrupamento e compartilhamento são materializadas automaticamente, reduzindo trabalho repetitivo.

III. Três modos de operação

Os três modos usam o mesmo mecanismo do Edge-EMS Builder e podem operar separadamente ou ser combinados no mesmo projeto.

1. Autonomia na borda

Aquisição de dados, cálculo, avaliação e controle são realizados dentro da instalação. Esse modo é adequado a cenários com requisitos rigorosos de velocidade de resposta, operação contínua e manutenção dos dados no local.

Fluxo típico: dispositivos de campo → CommBridge → estratégia do Edge-EMS Builder → dispositivos de campo

Necessidades atendidas: carga e descarga por faixa de horário, prevenção de fluxo reverso, controle de demanda, intertravamento de dispositivos e alarmes locais.

Prioridades de projeto: a proteção local tem prioridade; dependências externas, como tarifas de energia, previsão do tempo ou comandos da nuvem, exigem estratégias de cache, tempo limite e operação degradada.

2. Colaboração entre nuvem e borda

A borda realiza a execução em tempo real, enquanto a nuvem cuida do gerenciamento unificado, da orquestração de estratégias, da operação e manutenção remotas ou da análise entre instalações. O MQTT oferece publicação/assinatura bidirecional e mecanismos de resposta; o Edge-EMS Builder também pode obter informações externas autorizadas por HTTP.

Fluxo típico: a nuvem envia metas/estratégias → a borda valida e executa → os resultados retornam à nuvem

Necessidades atendidas: monitoramento de várias instalações, ajuste remoto de parâmetros, envio de curvas programadas, análise operacional e alarmes centralizados.

Prioridades de projeto: metas da nuvem não podem contornar os limites de segurança locais. Durante uma desconexão, deve estar definido se o sistema continuará executando, manterá o último valor válido ou adotará uma estratégia segura.

3. Colaboração entre vários nós

Vários nós Edge-EMS Builder sincronizam dados por destinos de compartilhamento. O nó mestre pode consolidar o estado dos nós subordinados e realizar cálculos unificados; os nós subordinados também podem assumir novas tarefas após uma mudança de função.

Fluxo típico: vários nós subordinados compartilham dados → o nó mestre calcula a meta da instalação → cada nó executa a parcela atribuída

Necessidades atendidas: distribuição de potência entre unidades, controle de grupos de dispositivos em diferentes áreas, balanceamento de carga da instalação, redundância e alternância de funções.

Prioridades de projeto: defina as relações entre mestre e subordinados, a periodicidade do compartilhamento, a validade temporal dos dados, os estados de falha de rede e a estratégia local após perda de conexão.

IV. Recursos principais e suporte à operação

Recurso	Problema resolvido	Papel na malha de controle
Modelo de dados	Unifica a organização de dados originais, por faixa de horário, agregados e compartilhados	Base da aquisição e do cálculo
Mecanismo de expressões	Usa Lua para somar, filtrar, avaliar estados e calcular entre dispositivos	Cálculo
Perfis de acionamento	Orquestra regras de negócio por “condições + ações”	Decisão e execução
Colaboração entre nuvem e borda por MQTT	Publica dados, assina comandos e oferece respostas e comunicação bidirecional entre nuvem e borda	Conexão entre nuvem e borda
Colaboração entre dispositivos e destinos de compartilhamento	Permite que vários nós compartilhem dados e participem dos cálculos uns dos outros	Colaboração distribuída
Expansão dinâmica de unidades de dispositivo (UDE)	Oferece templates, placeholders dinâmicos e reconciliação de instâncias existentes	Expansão em escala
Ciclo de vida dos alarmes	Acompanha anomalias, recuperação e resolução manual	Estado e tratamento
Histórico e arquivamento	Oferece análise de tendências, exportação assíncrona e múltiplos planos de arquivamento	Retenção de dados
Operação e manutenção	Oferece recomendações de capacidade, origem das configurações, bloqueio para manutenção e logs de controle	Operação contínua

Além disso, Envio em tempo real ao frontend e controle direto oferece um canal WebSocket para sistemas de frontend e backend, permitindo que interfaces personalizadas assinem dados em tempo real e enviem comandos dentro das restrições de permissão e segurança.

V. Como combinar recursos para necessidades diferentes

O Edge-EMS Builder não exige que todos os projetos adotem a mesma estratégia. Ele usa o mesmo método de construção para atender a requisitos diferentes:

Requisito = dados necessários + regras de cálculo + condições de acionamento + ações de execução + proteção e validação

Necessidade	Dados necessários	Cálculo e avaliação	Ações típicas
Redução de picos e preenchimento dos vales de carga / controle de demanda	Potência no ponto de conexão com a rede, SOC, estado do PCS e meta de demanda	Calcula o déficit de potência e a capacidade disponível de carga/descarga	Envia a referência de potência ao PCS e registra o estado da estratégia
Prevenção de fluxo reverso	Potência no ponto de conexão com a rede, potência fotovoltaica e potência disponível do armazenamento	Avalia a tendência de injeção na rede e limita a saída	Absorção pelo armazenamento, limitação fotovoltaica ou alarme
Balanceamento de carga de carregadores	Margem do transformador, demanda e estado de cada carregador	Calcula a potência disponível para alocação e a distribui conforme as regras	Ajusta o limite de potência de cada carregador
Coordenação entre unidades	SOC, limites de potência e disponibilidade de cada unidade	Distribui a meta da instalação conforme SOC, capacidade ou prioridade	Envia submetas a vários PCS/nós
Faixas de horário e curvas programadas	Faixas de horário, tarifa de energia, SOC e previsão de carga	Identifica a faixa atual e verifica os limites de proteção	Altera metas de carga/descarga e retorna os resultados da execução
Controle orientado por informações externas	Tarifas de energia, clima, plano de produção e resultados de previsão	Valida a atualidade dos dados e os usa na otimização ou avaliação	Ajusta metas, entra em operação degradada ou emite alarmes

Exemplo: transformar uma necessidade de negócio em configuração do EMS Builder

O requisito é:

“Quando a potência no ponto de conexão com a rede exceder 800 kW, se o SOC estiver acima de 20%, o armazenamento deve descarregar automaticamente; quando a potência cair para 760 kW, o suporte deve cessar.”

Para implementá-lo, é necessário configurar pelo menos:

1. Dados como potência no ponto de conexão, SOC, disponibilidade do PCS e potência máxima de descarga;
2. Expressões para o déficit de capacidade e a potência de descarga desejada;
3. Condições com dois limites: ativação em 800 kW e desativação em 760 kW;
4. Ações de gravação da potência do PCS, limitação de frequência e tratamento de falhas;
5. Proteções de SOC/temperatura/alarmes, intervenção manual e estratégias para falhas de comunicação;
6. Casos de teste para operação normal, condições de limite, desconexão, falhas de dispositivos e outros cenários.

O Edge-EMS Builder fornece a infraestrutura para expressar e executar estratégias; sua segurança e correção continuam dependendo da definição dos requisitos, das capacidades dos dispositivos e da qualidade da validação.

VI. Possibilidades de conexões cabeadas, sem fio e entre instalações

A lógica central do Edge-EMS Builder é desacoplada do meio físico de rede. Porém, a possibilidade de conexão não significa que qualquer enlace sem fio seja adequado ao controle em tempo real.

Rede IP de nível superior

MQTT/MQTTS, HTTP e WebSocket podem operar sobre redes IP acessíveis. Conforme o hardware e as condições da rede, o projeto pode usar Ethernet, Wi-Fi, 4G/5G ou redes privadas para conectar a nuvem e outros nós.

Isso representa viabilidade arquitetural, não uma especificação garantida de módulos sem fio integrados ao hardware de borda do Edge-EMS Builder. A capacidade sem fio específica deve ser confirmada conforme o hardware escolhido, a rede da operadora, a cobertura local e os requisitos de certificação.

Rede de dispositivos de campo

A conexão sem fio de PCS, BMS, medidores e outros dispositivos depende dos próprios dispositivos, do gateway sem fio e da adaptação de protocolos pelo CommBridge. O enlace sem fio é apenas um meio de transmissão e não resolve automaticamente o mapeamento de registradores, os requisitos de tempo real ou as permissões de controle.

Aspectos adicionais para conexões sem fio ou de longa distância

• Latência e jitter: mantenha preferencialmente as malhas de controle de milissegundos no local. Enlaces de longa distância são mais adequados ao envio de metas, ao reporte de dados e à colaboração sem requisitos rígidos de tempo real.
• Desconexão e dados expirados: registre a validade temporal dos dados compartilhados e defina estratégias de manutenção, operação degradada ou saída após a desconexão.
• Segurança: use TLS, autenticação, privilégio mínimo e auditoria, evitando expor interfaces de controle de dispositivos diretamente à Internet pública.
• Proteção local: intertravamentos de hardware, proteção dos dispositivos e controle local de segurança não podem depender da nuvem nem de enlaces instáveis.

Portanto, o princípio geral recomendado é:

O controle em tempo real permanece na borda; as metas de otimização podem vir da nuvem. A rede sem fio fornece conectividade, enquanto segurança e recuperação de desastres sustentam a proteção.

VII. Da conexão sem fio à expansão de possibilidades

Os limites das capacidades do Edge-EMS Builder podem ser avaliados por três condições:

Pré-requisito	Pergunta a responder
Dados disponíveis	Os estados necessários podem ser adquiridos de forma estável, com origem confiável e validade temporal?
Regras expressáveis	Metas, restrições, prioridades e caminhos de exceção podem ser descritos claramente e testados?
Ações executáveis	O dispositivo ou sistema oferece interfaces de controle conformes, autorizáveis e verificáveis?

Quando as três condições são atendidas, o Edge-EMS Builder pode ir além do EMS tradicional e abranger controle de grupos de dispositivos em complexos industriais, ajuste de cargas flexíveis, integração com planos de produção e coordenação entre ambiente e energia, em cenários de automação de “Percepção → Decisão → Execução”.

Ainda assim, os seguintes limites permanecem:

• O Edge-EMS Builder não substitui a lógica de proteção do fabricante, certificações de segurança ou intertravamentos locais.
• Resultados de previsões externas ou de IA exigem validação de faixa, tratamento de tempo limite e limites seguros de atuação; não podem contornar regras determinísticas para controlar equipamentos críticos.
• A eficácia da colaboração entre dispositivos depende dos relógios, da rede, da qualidade dos dados e do algoritmo de distribuição de metas.
• Novas estratégias devem ser validadas por simulação ou em ambiente de testes antes de entrar em produção por um processo controlado.

VIII. Capacidade de implantação: partir de medições reais

O cenário recomendado S3.5 atualmente validado no AFE-E630 é: carga configurada de aquisição de 5.000 pontos/segundo, 30 operações de agregação, 90 execuções de Trigger/segundo, 20 operações MQTT/segundo e 10 tarefas de colaboração/segundo, com armazenamento por alteração (salvamento no máximo a cada 10 segundos).

No lote de testes de 2026-07-29 (relatório v1.3), as latências P95 de Trigger / MQTT nesse cenário foram, respectivamente, 56 ms / 77 ms; o P95 de uso da CPU do sistema completo foi 71.09%, e o P95 de uso real de memória do sistema completo foi 41.41%. Para o planejamento inicial da capacidade de produção, recomenda-se reservar cerca de 20% de margem de engenharia sobre essa carga medida.

Esses resultados se baseiam em hardware e software específicos e em 2.000 amostras válidas de curta duração. Não constituem uma conclusão de estabilidade de 72 horas nem podem ser extrapolados diretamente para scripts, tamanhos de mensagem e volumes de banco de dados diferentes. Consulte o Relatório de testes de desempenho do AFE-E630.

Lista de verificação antes da entrada em operação

• A lista de pontos, as grandezas, a precisão, as permissões de leitura/gravação e os valores anormais dos dispositivos foram confirmados?
• Estão definidos os critérios de ativação e desativação, o debounce, as prioridades e o tratamento de conflitos das estratégias?
• Há caminhos de operação degradada para desconexão, dados expirados, dispositivos offline e falhas de gravação?
• Proteção dos dispositivos, intertravamentos de hardware, intervenção manual e auditoria de permissões funcionam de forma independente?
• Foram realizados testes de estresse com scripts reais, tamanhos reais de mensagem, volume histórico do banco de dados e hardware de destino?
• Existem versionamento de configurações, plano de reversão e monitoramento de logs e alarmes?

Próximos passos

• Para conhecer o valor e os cenários do produto, leia a Apresentação do Edge-EMS Builder.
• Para entender os objetos de configuração, leia Conceitos principais.
• Para conhecer o processo de configuração de negócio, leia Ampliação temporária de capacidade na área de um transformador de distribuição ou Balanceamento de carga de um conjunto de carregadores.
• Para integração com frontend e nuvem, consulte Envio em tempo real ao frontend e controle direto e Colaboração entre nuvem e borda por MQTT.