Três dispositivos podem suportar o mesmo protocolo e ainda falhar em se comunicar.
Em um BESS comercial, o BMS reporta o status da bateria e os limites operacionais, o PCS converte a energia e executa comandos de carga/descarregamento, e o EMS decide quando essa energia deve ser transferida de acordo com os objetivos do local. A comunicação comumente utiliza interfaces baseadas em CAN, RS485, Modbus RTU/TCP, ou Ethernet. Mas compartilhar um nome de protocolo não prova compatibilidade—os dispositivos também devem concordar sobre mapas de dados, escalonamento, endereços, temporização, autoridade de controle, lógica de alarme e comportamento de segurança.
A arquitetura do BESS do DOE ilustra isso como diferentes camadas de controle: o BMS fica próximo aos módulos da bateria, o PCS controla a conversão de energia, enquanto o EMS opera no nível de controle do local.
Essa hierarquia é mais fácil de entender se seguirmos um comando.
O EMS diz 100 kW. O PCS não pode simplesmente obedecer.
Imagine que a demanda da fábrica se aproxima de seu limite máximo.
O EMS calcula:
Descarregamento necessário do BESS = 100 kW
Ele envia um pedido de energia para o PCS.
Mas antes de entregar 100 kW, a cadeia de controle tem outra opinião.
O BMS pode atualmente reportar:
SoC: 24%
Descarregamento máximo permitido: 62 kW
talvez por causa do SoC, tensão da célula, temperatura, corrente, ou outra restrição da bateria.
O resultado correto não é:
Comando do EMS = 100 kW → Saída do PCS = 100 kW
O PCS deve operar dentro do envelope permitido da bateria.
Conceitualmente:
BMS → “O que a bateria é permitida fazer”
EMS → “O que o local quer que a bateria faça”
PCS → “O que a conversão de energia pode realmente executar”
Essa separação é fundamental para o controle seguro do BESS.
CAN e Modbus são linguagens, não acordos.
É aqui que as especificações de aquisição muitas vezes se tornam muito otimistas.
O fornecedor A diz:
Comunicação do BMS: CAN.
O fornecedor B diz:
O PCS suporta CAN.
O comprador escreve:
Compatível.
Ainda não.
O CAN descreve um mecanismo de comunicação. Os dispositivos ainda precisam de definições de mensagem compatíveis.
O mesmo problema aparece com o Modbus.
Dois dispositivos podem suportar Modbus RTU, mas discordar sobre:
endereços de registro
tipo de dado
ordem dos bytes
escalonamento
permissões de leitura/gravação
IDs de dispositivos
taxas de atualização
códigos de alarme
Um valor de registro de500não tem significado até que todos concordem se significa:
500 A
50,0 A
ou algo completamente diferente.
É por isso que eu solicitarei o protocolo de comunicação real ou o mapa de registros antes da comissionamento.
DawniceProdutosMostra por que a interface depende da fronteira do sistema.
Nem todo produto comercial de bateria expõe a mesma interface.
O da DawniceBS09-225-D 225,07 kWh sistema do lado DC, por exemplo, publicacomunicação CAN/RS485, enquanto o BS07-265-ES-X listainterfaces e identifica o CAN como o método de comunicação do BMS.
Seu integradoBS07-265-ES-X 125 kW/265,3 kWhsistema, em vez disso, publicaModbus TCP/RTUDawnice BS09-225-D
E a especificação do container de 1 MW/2,089 MWh da Dawnice lista a comunicação EMS através deRS485 e TCP/IP.
Essas diferenças fazem sentido.
Uma bateria do lado DC precisa de uma interface para um PCS externo.
Um sistema tudo-em-um já contém mais da relação bateria–PCS internamente.
Uma planta containerizada precisa então de comunicação de nível superior com EMS, monitoramento, medidores e potencialmente SCADA do local.
A arquitetura de comunicação segue afronteira do sistema.
O medidor também faz parte da conversa.
O corte de pico nos dá um bom exemplo.
O medidor do local relata:
Importação da rede = 680 kW
O alvo do EMS é:
600 kW
O EMS calcula aproximadamente:
80 kW de descarga necessária
e envia o comando.
O PCS o executa.
O medidor então relata a nova condição da rede, permitindo que o EMS ajuste novamente.
Portanto, o loop real está mais próximo de:
Medidor do Local → EMS → PCS ↔ BMS → PCS → Medidor do Local
É por isso que um CT invertido ou escalonamento incorreto do medidor pode fazer uma bateria perfeitamente saudável se comportar de forma incorreta.
O EMS está tomando decisões racionais a partir de informações ruins.
A arquitetura de comunicação BESS do DOE inclui de forma semelhante medidores, EMS, PCS, BMS, controles ambientais, HMI, sistemas de incêndio e infraestrutura de rede, em vez de tratar a comunicação da bateria como um único cabo CAN.
A falha de comunicação precisa de um estado seguro definido.
Agora desconecte a rede EMS.
O que deve acontecer?
Essa resposta pertence à especificação de design.
Dependendo da aplicação e da arquitetura aprovada, o sistema pode:
continuar o último comando válido por um período definido
retornar ao controle local do PCS
reduzir a potência
parar a carga/descarga
gerar um alarme
ou entrar em outro estado seguro pré-definido.
A mesma pergunta se aplica quando:
a comunicação BMS–PCS falha
os dados do medidor desaparecem
a conexão com a nuvem é perdida
o SCADA se torna indisponível
Essas falhas não são equivalentes.
Uma interrupção na nuvem não deve necessariamente ter a mesma consequência que a perda dos limites do BMS necessários para a operação segura da bateria.
A matriz de perda de comunicação deve, portanto, definir:
link perdido → tempo limite → ação de fallback → alarme → condição de recuperação
antes do SAT.
A matriz de responsabilidade importa mais do que a lista de protocolos.
Eu colocaria esta tabela no acordo técnico:
| Interface | Dados / Função | Parte Responsável |
|---|---|---|
| Bateria ↔ PCS | Limites, SoC, alarmes, comandos | Fornecedor/integrador nomeado |
| PCS ↔ EMS | Comando/status de potência | Fornecedor/integrador nomeado |
| Medidor ↔ EMS | Medição de rede/carga | Parte EPC / EMS |
| EMS ↔ SCADA | Monitoramento/controle | Integrador EMS / site |
| Plataforma remota | Acesso a dados/suporte | Fornecedor definido |
| Infraestrutura de rede | IP/VLAN/firewall | Responsabilidade do site/EPC |
A última coluna evita uma conversa de comissionamento surpreendentemente comum:
Fornecedor da bateria:
“Nosso CAN funciona.”
Fornecedor do PCS:
“Nosso CAN funciona.”
Integrador:
“Então, por que eles não se comunicam?”
A biblioteca de suporte técnico da Dawnice contém procedimentos de comunicação dedicados para combinações comoPCS Solis 50 kW com armazenamento Dawnice 100/143 kWhePCS Megarevo 500 kW com armazenamento C&I Dawnice 860 kWh, o que ilustra que o emparelhamento real de dispositivos requer configuração e trabalho de integração além de listar um protocolo em uma ficha técnica.
O que eu testaria antes de considerar a interface completa.
Eu não considero a comunicação comissionada porque cada dispositivo mostra um ícone verde.
Durante o FAT/SAT, quero provar:
os valores de SoC e temperatura estão corretamente escalonados
os limites de carga/descarregamento do BMS chegam ao PCS
os comandos de potência do EMS são executados corretamente
a direção e a escala do medidor estão corretas
os alarmes se propagam para o HMI/SCADA pretendido
os timestamps concordam
o comportamento de perda de comunicação corresponde à especificação
o sistema se recupera corretamente após o retorno da comunicação
Para um projeto Ruibit/Dawnice, essa responsabilidade deve ser congelada antes do envio sempre que PCS, EMS, medidores ou sistemas SCADA externos estiverem envolvidos. A Dawnice afirma que seu C&Iusam detecção de fumaça e temperatura em tempo real e supressão automática, enquanto alguns sistemas tudo-em-um combinamsuporta interfaces padrão, incluindo CAN, RS232 e RS485, e fornece serviços de integração de sistemas e comissionamento para projetos maiores de C&I.
Uma lista de protocolos me diz quais conversas podem ser possíveis.
Um BESS comissionado prova que os dispositivos entendem os mesmos dados, respeitam a mesma hierarquia de controle, falham de forma segura quando a conversa para e não deixam ambiguidade sobre quem é responsável por fazer as interfaces funcionarem.
Perguntas Frequentes
1. Como o BMS, PCS e EMS se comunicam em um BESS comercial?
OO BMS fornece status da bateria, SoC, alarmes e limites operacionais., oO EMS determina a potência de carga ou descarga necessária., e oO PCS executa comandos de conversão de energia respeitando os limites da bateria e do sistema..
2. Quais protocolos de comunicação são comumente usados em BESS comerciais?
As interfaces comuns incluemCAN, RS485, Modbus RTU/TCP e comunicação baseada em Ethernet.Apoiar o mesmo protocolo não garante automaticamente a compatibilidade entre dispositivos.
3. Por que dois dispositivos BESS podem suportar CAN ou Modbus, mas ainda assim falhar na comunicação?
Eles podem usar definições demensagens diferentes, endereços de registro, escalonamento, ordem de bytes, IDs de dispositivos, taxas de atualização, códigos de alarme ou lógica de controle.O mapa de protocolo/registros real deve, portanto, ser verificado.
4. O que deve acontecer se a comunicação BMS, PCS ou EMS for perdida?
O sistema deve entrar em um estado predefinido com base na interface com falha. A especificação deve definir otempo limite, ação de fallback, comportamento de alarme e condições de recuperaçãopara cada falha de comunicação.
5. Quem é responsável pela integração BMS–PCS–EMS?
A responsabilidade deve ser explicitamente atribuída nos documentos do projeto. Os compradores devem definir quem possui cada interface entre abateria, PCS, EMS, medidor, SCADA, plataforma remota e rede do siteantes do FAT e do comissionamento.
