Three Devices Can Support the Same Protocol and Still Fail to Communicate
In a commercial BESS, the BMS reports battery status and operating limits, the PCS converts power and executes charge/discharge commands, and the EMS decides when that power should move according to site objectives. Communication commonly uses CAN, RS485, Modbus RTU/TCP, or Ethernet-based interfaces. But sharing a protocol name does not prove compatibility—the devices must also agree on data maps, scaling, addresses, timing, control authority, alarm logic, and fail-safe behavior.
DOE's BESS architecture illustrates these as different control layers: the BMS sits close to battery modules, the PCS controls power conversion, while the EMS operates at the site-control level.
That hierarchy is easier to understand if we follow one command.
The EMS Says 100 kW. The PCS Cannot Simply Obey.
Imagine factory demand approaches its peak limit.
The EMS calculates:
Required BESS discharge = 100 kW
It sends a power request toward the PCS.
But before delivering 100 kW, the control chain has another opinion.
The BMS may currently report:
SoC: 24%
Maximum permitted discharge: 62 kW
perhaps because of SoC, cell voltage, temperature, current, or another battery constraint.
The correct result is not:
EMS command = 100 kW → PCS output = 100 kW
The PCS must operate within the battery's permitted envelope.
Conceptually:
BMS → “What the battery is allowed to do”
EMS → “What the site wants the battery to do”
PCS → “What power conversion can actually be executed”
That separation is fundamental to safe BESS control.
CAN and Modbus Are Languages, Not Agreements
This is where procurement specifications often become too optimistic.
Supplier A says:
BMS communication: CAN.
Supplier B says:
PCS supports CAN.
The buyer writes:
Compatible.
Not yet.
CAN describes a communication mechanism. The devices still need compatible message definitions.
The same issue appears with Modbus.
Two devices may both support Modbus RTU while disagreeing about:
register addresses
data type
byte order
scaling
read/write permissions
device IDs
update rates
alarm codes
A register value of
500
is meaningless until everybody agrees whether it means:
500 A
50.0 A
or something else entirely.
That is why I would request the actual communication protocol or register map before commissioning.
Dawnice Products Show Why the Interface Depends on the System Boundary
Not every commercial battery product exposes the same interface.
Dawnice's BS09-225-D 225.07 kWh DC-side system , for example, publishes CAN/RS485 interfaces and identifies CAN as the BMS communication method.
Its integrated BS07-265-ES-X 125 kW/265.3 kWh system instead publishes Modbus TCP/RTU and EMS/cloud readiness.
And Dawnice's 1 MW/2.089 MWh container specification lists EMS communication through RS485 and TCP/IP .
Those differences make sense.
A DC-side battery needs an interface to an external PCS.
An all-in-one system already contains more of the battery–PCS relationship internally.
A containerized plant then needs higher-level communication with EMS, monitoring, meters, and potentially site SCADA.
The communication architecture follows the system boundary .
The Meter Is Part of the Conversation Too
Peak shaving gives us a good example.
The site meter reports:
Grid import = 680 kW
The EMS target is:
600 kW
The EMS calculates approximately:
80 kW discharge required
and sends the command.
The PCS executes it.
The meter then reports the new grid condition, allowing the EMS to adjust again.
So the real loop is closer to:
Site Meter → EMS → PCS ↔ BMS → PCS → Site Meter
This is why a reversed CT or incorrect meter scaling can make a perfectly healthy battery behave incorrectly.
The EMS is making rational decisions from bad information.
DOE's BESS communication architecture similarly includes meters, EMS, PCS, BMS, environmental controls, HMI, fire systems, and network infrastructure rather than treating battery communication as one CAN cable.
Communication Failure Needs a Defined Safe State
Now unplug the EMS network.
What should happen?
That answer belongs in the design specification.
Depending on the application and approved architecture, the system might:
continue the last valid command for a defined period
fall back to local PCS control
reduce power
stop charge/discharge
raise an alarm
or enter another predefined safe state.
The same question applies when:
BMS–PCS communication fails
meter data disappears
cloud connection is lost
SCADA becomes unavailable
These failures are not equivalent.
A cloud outage should not necessarily have the same consequence as losing the BMS limits required for safe battery operation.
The communication-loss matrix should therefore define:
lost link → timeout → fallback action → alarm → recovery condition
before SAT.
The Responsibility Matrix Matters More Than the Protocol List
I would put this table into the technical agreement:
| Interface | Data / Function | Responsible Party |
|---|---|---|
| Battery ↔ PCS | Limits, SoC, alarms, commands | Named supplier/integrator |
| PCS ↔ EMS | Power command/status | Named supplier/integrator |
| Meter ↔ EMS | Grid/load measurement | EPC / EMS party |
| EMS ↔ SCADA | Monitoring/control | EMS / site integrator |
| Remote platform | Data/support access | Defined supplier |
| Network infrastructure | IP/VLAN/firewall | Site/EPC responsibility |
The last column prevents a surprisingly common commissioning conversation:
Battery supplier:
“Our CAN works.”
PCS supplier:
“Our CAN works.”
Integrator:
“Then why don't they communicate?”
Dawnice's technical-support library contains dedicated communication procedures for combinations such as Solis 50 kW PCS with Dawnice 100/143 kWh storage and Megarevo 500 kW PCS with Dawnice 860 kWh C&I storage , which illustrates that actual device pairing requires configuration and integration work beyond listing a protocol on a datasheet.
What I Would Test Before Calling the Interface Complete
I do not consider communication commissioned because every device shows a green icon.
During FAT/SAT, I want to prove:
SoC and temperature values are correctly scaled
BMS charge/discharge limits reach the PCS
EMS power commands are executed correctly
meter direction and scaling are correct
alarms propagate to the intended HMI/SCADA
timestamps agree
communication-loss behavior matches the specification
the system recovers correctly after communication returns
For a Ruibit/Dawnice project, that responsibility should be frozen before shipment whenever external PCS, EMS, meters, or SCADA systems are involved. Dawnice states that its C&I Products support standard interfaces including CAN, RS232 and RS485 and provides system-integration and commissioning services for larger C&I projects.
A protocol list tells me which conversations might be possible.
A commissioned BESS proves that the devices understand the same data, respect the same control hierarchy, fail safely when the conversation stops, and leave no ambiguity about who is responsible for making the interfaces work.
FAQs
1. How do BMS, PCS, and EMS communicate in a commercial BESS?
The BMS provides battery status, SoC, alarms, and operating limits , the EMS determines the required charge or discharge power , and the PCS executes power-conversion commands while respecting battery and system limits .
2. What communication protocols are commonly used in commercial BESS?
Common interfaces include CAN, RS485, Modbus RTU/TCP, and Ethernet-based communication . Supporting the same protocol does not automatically guarantee compatibility between devices.
3. Why can two BESS devices support CAN or Modbus but still fail to communicate?
They may use different message definitions, register addresses, scaling, byte order, device IDs, update rates, alarm codes, or control logic . The actual protocol/register map must therefore be verified.
4. What should happen if BMS, PCS, or EMS communication is lost?
The system should enter a predefined state based on the failed interface. The specification should define the timeout, fallback action, alarm behavior, and recovery conditions for each communication failure.
5. Who is responsible for BMS–PCS–EMS integration?
Responsibility should be explicitly assigned in the project documents. Buyers should define who owns each interface between the battery, PCS, EMS, meter, SCADA, remote platform, and site network before FAT and commissioning.
