BESS Communication Protocols: The Complete 2026 Guide
What Are BESS Communication Protocols?
BESS communication protocols are the rules that let every part of a battery storage system share data.
So without them, batteries, inverters, and grid systems cannot work together.
Each device in a BESS speaks a different digital language. But a shared protocol gives them a common way to talk.
For example, the battery uses CAN Bus internally. The inverter, however, often uses Modbus. And the grid uses IEC 61850.
Choosing the right BESS communication protocols matters a lot. A bad choice leads to slow integration, poor performance, and higher costs.
Why BESS Communication Protocols Affect System Safety
Speed is critical in a BESS. A fault signal must reach the controller in milliseconds. So the protocol must be fast enough to carry it in time.
Also, the protocol must be reliable. If a message is lost, the system may not shut down safely. Therefore, engineers choose protocols based on both speed and reliability.
In addition, some protocols are secure by design. Others, however, have no built-in encryption. As a result, security must be added at the network level for older protocols.
For more background, see our guides on the Battery Management System (BMS), the Power Conversion System (PCS), and the Energy Management System (EMS).
The Five Layers of BESS Communication Protocols
BESS communication protocols work across five system layers. Each layer has different speed needs and data types. So understanding these layers helps you pick the right protocol at each level.
| Layer | Component | Common Protocols |
|---|---|---|
| 1 — Cell | Battery cells, modules, BMUs | CAN Bus, SMBus |
| 2 — BMS | Battery Management System | Modbus RTU, CAN Bus, RS-485 |
| 3 — PCS | Power Conversion System / Inverter | Modbus TCP, CAN Bus, PROFINET, EtherNet/IP |
| 4 — EMS | Energy Management System | Modbus TCP, OPC UA, MQTT, IEC 60870-5-104 |
| 5 — Grid | Utility / SCADA / Cloud | IEC 61850, DNP3, IEEE 2030.5, MQTT, REST |
No single protocol covers all five layers. So most BESS projects use three or four protocols together.
As a result, a protocol gateway is almost always part of a real BESS design. We cover this in detail later.
1. Modbus — The Most Widely Used BESS Communication Protocol
Modbus is the most common BESS communication protocol in the world. It was developed in 1979, but it is still used in almost every BESS project today.
So why is it so popular? Because it is simple, cheap, and works with every BESS hardware vendor.
How Modbus Works as a BESS Communication Protocol
Modbus uses a master-slave model. One master — usually the EMS — sends a request to a slave device such as the BMS. The slave then replies with its data.
There are two forms. First, Modbus RTU sends binary data over an RS-485 serial cable. Then, Modbus TCP sends the same data over a standard Ethernet network. As a result, Modbus TCP works across a local area network or even the internet.
In a BESS, Modbus TCP links the BMS to the EMS and SCADA systems. So it is how most BESS assets respond to grid operator commands.
Why Modbus Has Limits as a BESS Communication Protocol
Modbus is easy to use, but it does have gaps. For example, it has no built-in security. Also, it uses polling, which adds latency.
However, these gaps are manageable. Engineers add security at the network level. And for most BESS use cases, the polling delay is acceptable.
But Modbus should not be the only protocol on an external BESS interface. For that reason, most projects combine it with a secure protocol like OPC UA or IEEE 2030.5.
| STRENGTHS ✓ Works with every BESS hardware vendor ✓ Simple to set up and easy to debug ✓ No licence cost ✓ Runs over RS-485 serial and Ethernet TCP/IP | LIMITATIONS ✗ No built-in encryption or authentication ✗ Polling model adds latency ✗ Limited data model vs IEC 61850 ✗ Not suitable alone for utility-facing use |
Used for: BMS ↔ EMS, BMS ↔ PCS, SCADA, field instruments
See also: Battery Management System (BMS) Explained | Power Conversion System (PCS) Guide
2. CAN Bus — The Internal BESS Communication Protocol
CAN Bus is the backbone of every battery rack. It was built for cars, but it also works perfectly inside BESS enclosures.
In fact, it is now found in products from BYD, CATL, Huawei, Sungrow, and Pylontech. So it has become the standard for internal BESS communication.
Why CAN Bus Suits BESS Internal Communication
CAN Bus uses a two-wire pair — CAN-H and CAN-L. This design blocks interference from the high-current switching inside a battery cabinet.
Also, CAN Bus is a multi-master system. So every node — modules, BMUs, and the BMS controller — can send data at any time. As a result, the system gets real-time updates without waiting to be polled.
Furthermore, China’s national grid standards require CAN Bus as the BMS-to-inverter link in all utility-scale BESS projects. So it is not just popular — it is often mandatory.
CAN Bus Limits in a BESS System
CAN Bus is fast, but its range is short. At 1 Mbit/s, cables can be no longer than 40 metres. Therefore, it cannot be used beyond the battery enclosure.
However, a gateway solves this. The gateway reads CAN Bus data and then sends it upstream as Modbus TCP, MQTT, or another BESS communication protocol.
| STRENGTHS ✓ Resists EMI via differential CAN-H / CAN-L signalling ✓ Error detection and arbitration built in ✓ Real-time, event-driven — no polling needed ✓ Used by all major BESS OEMs | LIMITATIONS ✗ Short cable range — max 40 m at 1 Mbit/s ✗ Cannot reach the utility or cloud layer ✗ Vendor register maps differ between brands ✗ Needs a gateway for EMS or cloud integration |
Used for: Cell ↔ BMU, BMU ↔ BMS Master, BMS ↔ PCS (close-range)
3. IEC 61850 — The Grid-Level BESS Communication Protocol
IEC 61850 is the international standard for substation automation. It is also the leading BESS communication protocol for utility grid connections, especially in Europe and Asia-Pacific.
Unlike Modbus, it defines a full information model — not just a transport layer. So any IEC 61850 device can talk to any other, no matter the brand.
What Makes IEC 61850 Different
IEC 61850 uses logical nodes and data objects to describe every piece of equipment. As a result, there is no need for custom register mapping between vendors.
Also, IEC 61850-7-420 extends the standard to cover Distributed Energy Resources, including BESS. However, this DER extension is still developing. So some projects use custom mappings alongside the standard.
GOOSE Messaging — Speed That Other BESS Communication Protocols Cannot Match
GOOSE stands for Generic Object-Oriented Substation Event. It delivers event signals in under one millisecond. Therefore, it is used for protection — where a delayed signal could mean a fault goes uncleared.
MMS, in contrast, handles scheduled data exchange between the EMS and the utility. Together, GOOSE and MMS give IEC 61850 a range that no other BESS communication protocol can match alone.
When to Specify IEC 61850 for Your BESS
Use IEC 61850 for any utility-scale BESS in Europe, the UK, or Asia-Pacific. Many regulators now require it for all new grid-connected storage assets.
Furthermore, specifying it early avoids costly retrofits. So include it in the EMS and gateway specification from day one.
| STRENGTHS ✓ True multi-vendor interoperability — no register mapping ✓ GOOSE delivers sub-millisecond protection events ✓ Rich, self-describing data model ✓ Mandated by EU, UK, and APAC utility operators | LIMITATIONS ✗ Higher engineering cost than Modbus ✗ DER model (7-420) still maturing ✗ Not all BESS OEMs support it natively ✗ Needs SCL configuration expertise |
Used for: EMS ↔ Utility SCADA, substation automation, protection, VPP
See also: How EMS Enables Advanced Grid Services | BMS vs EMS — Control Layers
4. DNP3 — The North American Utility BESS Communication Protocol
DNP3 is the standard BESS communication protocol for utility SCADA in North America. It is formally specified under IEEE Std 1815 and has been in use since 1993.
So if your BESS connects to a North American utility, you will almost certainly need DNP3.
Why DNP3 Works Well for Remote BESS Sites
DNP3 was built for tough conditions. It works over serial radio links, low-bandwidth WAN, and cellular networks. As a result, it suits remote BESS sites where network quality is poor.
Also, DNP3 supports unsolicited reporting. This means the BESS sends data only when something changes. So it uses far less bandwidth than a polling protocol like Modbus.
Adding Security to DNP3 in BESS Projects
The base DNP3 standard has no native security. However, Secure Authentication v5 (SAv5) adds a challenge-response layer. This significantly improves protection on any BESS grid link.
NERC CIP standards require strong authentication on all utility-connected BESS assets in North America. Therefore, SAv5 is now a standard requirement in most DNP3 BESS specifications.
| STRENGTHS ✓ Reliable over poor network links — serial, radio, cellular ✓ Unsolicited reporting cuts bandwidth ✓ Leading protocol for North American utility SCADA ✓ Timestamped events support accurate fault logging | LIMITATIONS ✗ Less rich data model than IEC 61850 ✗ Security needs SAv5 as a separate add-on ✗ Rarely used outside North America ✗ Not suited to cloud or IoT use |
Used for: EMS ↔ Utility SCADA, remote BESS, North American grid connections
5. OPC UA — The Secure Cloud BESS Communication Protocol
OPC UA connects BESS systems to cloud platforms and enterprise software. It is specified under IEC 62541 and is widely used in industrial IoT deployments.
Unlike older protocols, it is secure by design. So it is a strong choice for any external-facing BESS interface.
How OPC UA Improves on Legacy BESS Communication Protocols
Legacy OPC was Windows-only and had no encryption. OPC UA, however, works on any platform — Linux, Windows, or embedded controllers.
Also, OPC UA uses TLS encryption by default. So every connection is secure without any extra setup. In addition, it uses a rich object model that represents a full BESS asset in a structured, self-describing format.
As a result, cloud analytics platforms can ingest BESS data without any custom engineering. So it saves time and reduces integration risk.
Combining OPC UA and IEC 61850 in Large BESS Projects
The best approach for utility-scale BESS is to use both. IEC 61850 handles real-time grid communication. OPC UA, in contrast, carries asset data to cloud analytics and digital twin platforms.
Furthermore, AWS, Azure, and Google Cloud all support OPC UA PubSub natively. Therefore, OPC UA provides a direct, secure path from the BESS site to cloud tools.
| STRENGTHS ✓ TLS encryption built in — no add-on needed ✓ Works on any platform — Linux, Windows, embedded ✓ Rich object model for complex BESS data ✓ Native support in AWS, Azure, and Google Cloud | LIMITATIONS ✗ Heavier than MQTT for simple data streams ✗ Too complex for small C&I BESS projects ✗ Higher engineering cost than Modbus ✗ Slower to implement than simpler alternatives |
Used for: EMS ↔ Cloud, asset management, digital twins, predictive maintenance
See also: How EMS Enables Advanced Grid Services
6. MQTT — The Cloud Telemetry BESS Communication Protocol
MQTT is a lightweight protocol for cloud telemetry. It is now the most popular BESS communication protocol for real-time monitoring and remote dashboards.
So if you want to stream battery data to the cloud, MQTT is the best place to start.
How MQTT Works in a BESS
MQTT uses a broker between publishers and subscribers. The BMS gateway publishes data — such as state of charge, temperature, and fault codes — to the broker.
Then cloud dashboards subscribe and receive that data in near real time. Also, the publisher-subscriber model means you can add new cloud apps without touching any hardware.
Furthermore, IEC 61850 data models can be mapped directly to MQTT topics. So a single gateway can serve both the grid and the cloud at the same time.
MQTT and the EU Battery Passport
The EU is introducing Battery Passport rules for storage assets. MQTT is well-suited to Battery Passport data exports because of its lightweight, streaming design.
As a result, MQTT is increasingly specified alongside IEC 61850 in European BESS projects. So it is becoming a standard part of the cloud layer in most modern designs.
| STRENGTHS ✓ Very lightweight — low bandwidth and CPU use ✓ Best choice for high-frequency streaming data ✓ Native support in AWS, Azure, and Google Cloud ✓ Publisher-subscriber model is flexible and scalable | LIMITATIONS ✗ No built-in BESS data model — custom topics needed ✗ Not suitable for direct control commands ✗ QoS levels must be configured carefully ✗ TLS must be switched on manually |
Used for: Cloud telemetry, remote monitoring, Battery Passport exports, IIoT analytics
7. PROFINET and EtherNet/IP — Real-Time BESS Communication Protocols
PROFINET and EtherNet/IP are Industrial Ethernet protocols. They are used inside containerised BESS units where Modbus TCP is not fast or precise enough.
So if your BESS has a PLC controlling HVAC, fire suppression, and the inverter, these protocols are likely the right choice.
When to Use These Real-Time BESS Communication Protocols
Modbus TCP is fine for most BMS-to-EMS links. But it cannot guarantee the timing needed for fast power electronics.
PROFINET and EtherNet/IP, in contrast, are deterministic. They deliver messages within a fixed time window. As a result, charge and discharge commands arrive at exactly the right moment.
Also, both support IEEE 1588 Precision Time Protocol. This keeps all BESS components synchronised to within microseconds. Therefore, they are ideal for frequency regulation services that need sub-second response.
PROFINET vs EtherNet/IP — Which One Should You Choose?
PROFINET is the standard choice in Europe and Asia. It works best with Siemens TIA Portal and Siemens PLCs.
EtherNet/IP, however, is more common in North America. It is the native protocol for Rockwell Automation hardware. So the right choice usually depends on which PLC the project already uses.
| STRENGTHS ✓ Deterministic real-time communication ✓ Gigabit Ethernet capable — high throughput ✓ IEEE 1588 PTP for microsecond synchronisation ✓ Tight integration with Siemens (PROFINET) and Rockwell (EtherNet/IP) | LIMITATIONS ✗ Vendor lock-in — PROFINET and EtherNet/IP are not compatible ✗ Higher infrastructure cost than Modbus TCP✗ Not used for utility or cloud communication ✗ Needs managed switches with QoS and VLAN support |
Used for: BMS ↔ PCS sync, containerised BESS with PLC, auxiliary system automation
8. IEEE 2030.5 — The Compliance BESS Communication Protocol
IEEE 2030.5 is a secure, RESTful protocol for connecting BESS to utility systems. It is mandatory under California Rule 21 for all grid-connected BESS in California.
So if your project is in California — or a state adopting similar rules — you will need this protocol.
Why IEEE 2030.5 Is the Most Secure BESS Communication Protocol
Unlike Modbus or DNP3, IEEE 2030.5 requires TLS 1.2 on every connection. There is no optional configuration — it is always on.
Also, it uses standard HTTPS calls. So it fits naturally into modern IT networks. As a result, integration with utility head-end systems is simpler than with legacy serial protocols.
Using IEEE 2030.5 Without Replacing Your BESS Hardware
Most existing BESS hardware does not natively support IEEE 2030.5. However, a protocol gateway solves this easily.
The gateway translates from SunSpec Modbus or DNP3 on the device side to IEEE 2030.5 on the utility side. So operators can achieve full Rule 21 compliance without any new field hardware.
In addition, more US states and international regulators are expected to adopt similar DER rules by 2030. Therefore, specifying IEEE 2030.5 gateway support today future-proofs the asset.
| STRENGTHS ✓ TLS 1.2 mandatory — security built in ✓ RESTful HTTPS fits modern networks ✓ California Rule 21 and CSIP compliant ✓ Works via gateway — no hardware replacement needed | LIMITATIONS ✗ Primarily a North American standard ✗ REST polling too slow for fast control loops ✗ Needs specialist Rule 21 / CSIP knowledge ✗ Smaller vendor ecosystem than DNP3 or Modbus |
Used for: BESS DER interconnection, California Rule 21, utility scheduling and monitoring
All BESS Communication Protocols Compared
The table below compares all eight BESS communication protocols side by side. Use it to quickly find the right protocol for each layer of your system.
| Protocol | Layer | Real-Time | Security | Utility | Cloud/IoT |
|---|---|---|---|---|---|
| Modbus RTU/TCP | BMS ↔ EMS/PCS | Polling | None | Via SCADA | No |
| CAN Bus | Cell ↔ BMS | Yes | None | No | No |
| IEC 61850 | EMS ↔ Grid | GOOSE <1ms | Opt. TLS | Yes | Via mapping |
| DNP3 | EMS ↔ Utility | Low latency | SAv5 | N. America | No |
| OPC UA | EMS ↔ Cloud | Near RT | TLS | Emerging | Yes |
| MQTT | EMS ↔ Cloud | Streaming | Opt. TLS | No | Yes |
| IEEE 2030.5 | EMS ↔ Utility | REST poll | TLS mandatory | Yes | Possible |
| PROFINET/EtherNet-IP | BMS ↔ PCS | Deterministic | Network | No | No |
Why Every BESS Needs a Protocol Gateway
No BESS project uses just one communication protocol. CAN Bus batteries connect to Modbus inverters. Modbus inverters connect to IEC 61850 substations. DNP3 talks to SCADA. MQTT streams data to the cloud.
So a protocol gateway is what holds the whole system together. It translates data between protocols in real time.
What a BESS Protocol Gateway Does
A good gateway supports IEC 61850, DNP3, Modbus, OPC UA, and MQTT — all at the same time. As a result, the BESS can serve both the utility and the cloud from a single device.
Also, a gateway future-proofs the asset. So when utility requirements change, you update the gateway — not the hardware. This saves a lot of time and cost later in the project.
The Golden Rule for BESS Communication Protocol Design
| Design the gateway first Specify your protocol gateway before you procure any hardware. This one decision shapes every grid service, every cloud integration, and every future revenue stream. Retrofitting protocol support after commissioning is expensive and often technically very difficult. |
How to Pick the Right BESS Communication Protocols
For Commercial and Industrial BESS Projects
Most C&I projects use CAN Bus inside the battery rack. Then they use Modbus RTU between the BMS and inverter. After that, Modbus TCP connects the inverter to the EMS. Finally, MQTT pushes telemetry to the cloud.
This stack is cost-effective and easy to commission. Also, it is supported by every major BESS hardware vendor. So it is the best starting point for most behind-the-meter projects.
For C&I peak shaving, see: How C&I BESS Peak Shaving Lowers Demand Charges. For BESS with solar, see: C&I BESS with Renewable Energy.
For Utility-Scale BESS Projects
Utility-scale projects need IEC 61850 in Europe and APAC. In North America, however, DNP3 is the SCADA standard. In California, IEEE 2030.5 is also required.
As a result, the EMS must speak all three. A multi-protocol gateway or a native multi-protocol EMS platform makes this possible.
For grid-following inverter design, see: Grid-Following BESS Guide. For weak-grid environments, see: BESS Grid-Forming Technology.
Cybersecurity Rules for BESS Communication Protocols
Modbus and CAN Bus have no built-in security. So they need network-level protection — firewalls, VPNs, and strict network segmentation.
For external interfaces, use a secure protocol by design. For example, OPC UA, IEEE 2030.5, or DNP3 with SAv5 are all good choices.
- OPC UA: TLS encryption and X.509 certificates built in
- IEEE 2030.5: TLS 1.2 mandatory on every connection
- DNP3 SAv5: Challenge-response authentication add-on for existing systems
- Modbus / CAN Bus: Protect with firewalls, VPNs, and network segmentation
Also, NERC CIP standards apply to all utility-connected BESS in North America. Therefore, document all security controls for every communication interface.
Key Standards and References for BESS Communication Protocols
The sources below give primary-source detail on each BESS communication protocol. They are recommended for engineers who need full specification documents.
| Standard | Link | Protocol |
|---|---|---|
| IEC 61850 (IEC) | https://www.iec.ch/homepage | IEC 61850 |
| IEEE Std 1815 — DNP3 | https://standards.ieee.org/ieee/1815/ | DNP3 |
| IEEE 2030.5 / SEP 2.0 | https://standards.ieee.org/ieee/2030.5/ | IEEE 2030.5 |
| IEEE 2800-2022 | https://standards.ieee.org/ieee/2800/10508/ | Grid connection — IBR |
| NERC CIP Standards | https://www.nerc.com/pa/Stand/Pages/CIPStandards.aspx | Cybersecurity — all protocols |
| ENTSO-E Network Code RfG | https://www.entsoe.eu/network_codes/rfg/ | European grid requirements |
| MODBUS.org | https://modbus.org/ | Modbus RTU / TCP |
| OPC Foundation | https://opcfoundation.org/ | OPC UA |
| MQTT.org | https://mqtt.org/ | MQTT |
Conclusion — Choosing the Right BESS Communication Protocols
Choosing the right BESS communication protocols is one of the most important design decisions in any energy storage project. Get it right and the system integrates smoothly. Get it wrong and commissioning becomes painful and expensive.
So start with the basics. Use CAN Bus and Modbus for internal communication. Then add IEC 61850 or DNP3 for the utility interface. Finally, layer in OPC UA or MQTT for cloud analytics.
Above all, specify a capable protocol gateway early. It is the device that makes all the other protocols work together. And it keeps every integration option open as requirements change over the asset’s life.
Explore more from the Sunlith Energy library: BESS Technical Blog | BMS Explained | C&I BESS Economics | PCS Guide.