BMS Communication Protocols: CAN Bus, Modbus RTU, and JSON Compared

Every BMS has to talk to something. That may be a vehicle controller, an inverter, a SCADA system, a charging station, or a cloud platform. The protocol it uses determines integration complexity, data throughput, latency, cable distances, and long-term maintainability [1]. Many BMS datasheets list protocol support as a checkbox feature without explaining when each choice makes sense. This note compares the three protocols that matter most in practice.

The Short Answer

Choose the protocol by the system the BMS has to talk to. A vehicle controller, charger, or display on the same machine is best served by CAN Bus. A PLC, SCADA system, or inverter in a stationary installation is best served by Modbus RTU. A cloud platform or software service is best served by JSON. Most real installations need more than one of these, so the useful question is which combination matches the system architecture.

Side-by-Side Comparison

CAN Bus: The Real-Time Standard

Controller Area Network has been the backbone of automotive and mobile machinery communication since Bosch introduced it in the 1980s [2]. It runs on a differential two-wire bus (CAN-H and CAN-L) at speeds up to 1 Mbps. Hardware-level message arbitration guarantees that the highest-priority message always wins when two nodes transmit at the same time.

That deterministic behavior is the reason CAN Bus dominates safety-critical applications. When a BMS needs to tell a vehicle controller to disconnect now, the message cannot be held up by lower-priority data traffic. On an error-free bus the highest-priority message waits at most for the frame already in progress to finish. A standard frame carrying 8 data bytes is at most about 135 bits long including bit stuffing, which takes well under 0.2 milliseconds at 1 Mbps [2]. Lower-priority messages wait longer as bus load grows, so worst-case latency depends on message priority and bus utilization and has to be checked for each system [3].

Our BMS masters implement CAN Bus 2.0b with both standard (11-bit) and extended (29-bit) identifier formats, and the bit rate is configurable at 125, 250, 500, or 1000 kbps [4]. The BMS continuously broadcasts cell voltages, temperatures, SOC, SOH, protection status, and fault codes on configurable message IDs. Integration with a host controller is straightforward. The CAN message IDs are mapped to the controller's receive configuration, with no handshaking, no polling, and no connection management.

The main limitation is physical. CAN Bus cable runs top out at about 40 meters at 1 Mbps and can be longer at lower speeds [2]. For vehicle and mobile applications this is rarely a problem. For building-scale energy storage with hundreds of meters between battery racks and the control room, it becomes a constraint.

Modbus RTU: The Industrial Workhorse

Where CAN Bus is the standard in vehicles, Modbus is the standard for stationary equipment such as SCADA systems, PLCs, energy management systems, and grid-tied inverters [5].

Modbus RTU runs over an RS485 physical layer on a client-server polling model. The host requests specific data from defined register addresses and the BMS responds with the requested values. Polling adds latency equal to the polling interval. For stationary energy storage this is acceptable, because update rates of 1 to 10 seconds are usually sufficient.

The practical advantages add up quickly. Every PLC, SCADA system, and industrial gateway supports Modbus natively. RS485 allows cable runs of several hundred meters at typical baud rates, such as the 115200 baud used on our BMS, and the permitted length shrinks as the baud rate rises [6][10]. Cable quality and correct termination decide how much of that range is usable in a real installation. Multiple devices share a single bus with unique addresses. The protocol is simple enough that an experienced engineer can write a complete Modbus integration in an afternoon.

Our BMS products implement Modbus RTU with a published register map covering all cell voltages, temperatures, pack-level metrics, protection status, and configuration parameters [4]. The register map follows standard Modbus conventions, with holding registers for read-write parameters and input registers for read-only measurements, so integration with any Modbus-capable host is predictable.

JSON: The Cloud Bridge

CAN Bus and Modbus serve machine-to-machine communication. JSON serves a different need, human-readable and web-compatible data exchange for cloud platforms and modern software systems [7].

Technically JSON is a data format, which means it needs a transport layer underneath. That transport can be serial (RS232 or RS485) or a network (TCP/IP, MQTT, or HTTP). Our BMS products output JSON-formatted data strings containing all telemetry in a structured, self-describing format. Each message includes field names alongside values, so a developer reading the data stream can immediately understand what they are looking at without consulting an external register map.

This self-describing quality makes JSON well suited to cloud integration. LiBat Connect ingests JSON telemetry from BMS units through cellular or WiFi gateways, parses the structured data, and stores it directly in a time-series database [8]. There is no protocol translation layer, no register mapping table, and no risk of misinterpreting data fields when firmware versions change.

The trade-off is overhead. JSON messages are larger than equivalent CAN frames or Modbus responses because they carry field names in every message. That does not matter for cloud connectivity over cellular or WiFi, but it makes JSON impractical for the tight timing and bandwidth constraints of real-time control loops.

In Practice, Most Installations Use More Than One

The protocol choice depends on the integration target. A vehicle controller that needs real-time data calls for CAN Bus. An industrial PLC on RS485 infrastructure calls for Modbus. A cloud analytics platform calls for JSON.

Our BMS masters provide CAN Bus 2.0b, RS485, and RS232 interfaces and speak the LiBat Standard Protocols, JSON, and Modbus RTU [4]. A single BMS can therefore serve a vehicle controller over CAN Bus, a PLC over Modbus RTU, and a monitoring system over JSON. Which protocols can run in parallel depends on the ports of the model, listed in the table below.

We designed it this way because most real-world installations do not fit neatly into one protocol category. An AGV battery pack needs CAN Bus for the vehicle, Modbus for the warehouse management system, and JSON for remote monitoring. A grid-tied ESS needs Modbus for the inverter and JSON for the cloud [9]. Supporting all three natively lets the BMS adapt to the installation.

LiBat BMS Interfaces by Model

All five models support CAN Bus speeds of 125, 250, 500, and 1000 kbps, and RS485 at 115200 baud with 8N1 settings in half-duplex mode. All five list LiBat Standard Protocols, JSON, and Modbus RTU. The BCU2002 also provides WiFi and GSM wireless connectivity. The full specifications are on the BMS product overview.