BMS Communication Architectures

A battery management system is only as useful as the data it can collect and share. The BMS measures cell voltages, temperatures, and current; estimates state of charge, state of health, and state of power; controls contactors and thermal management; and communicates all of this to the rest of the system — the vehicle controller, the charger, the cloud. Every one of those functions depends on communication links working correctly, at the right speed, with sufficient noise immunity, and without creating safety hazards.

The communication architecture of a battery system spans two distinct domains with very different requirements:

Internal communications — within the battery pack itself. Primarily the link between the Analogue Front End (AFE) ICs that measure cell voltages and the BMS master processor. This link operates in the presence of the full HV battery stack, with the AFE floating at the battery potential of its cell group. The overriding requirement is galvanic isolation — the communication path must not provide a low-resistance path between the HV bus and the low-voltage microcontroller.

External communications — between the BMS master and the rest of the system. In an EV, this means the vehicle CAN bus, connecting the BMS to the vehicle control unit, motor controller, charger, and instrument cluster. In a BESS, it means Modbus or CAN to the energy management system. The requirements here are standardised message formats, deterministic timing, and functional safety compliance.

This page covers the protocols used across both domains.

Section Map

Internal BMS Comms	External BMS Comms	Charging Comms
isoSPI	CAN bus	ISO 15118
SPI	CAN FD	DIN 70121
I²C	LIN	OCPP
UART	RS485 / Modbus	SMBus
Daisy chain topology	Automotive Ethernet
	Wireless BMS

Internal BMS Communications

SPI — Serial Peripheral Interface

SPI is the low-level hardware protocol used between the BMS master microcontroller and the AFE ICs that measure cell voltages. It is a full-duplex, synchronous, four-wire interface: MOSI (Master Out Slave In), MISO (Master In Slave Out), SCLK (clock), and CS (Chip Select). The master controls the clock; data is shifted out on one edge and sampled on the other.

SPI is fast (up to 20–50 Mbit/s in practice for battery AFEs), simple to implement, and supported by every microcontroller family. The limitation in battery applications is that standard SPI provides no galvanic isolation — if the AFE is floating at a high battery potential (e.g. the top group in a 400V string is sitting at ~380V above chassis ground), a direct SPI connection between that AFE and the low-voltage microcontroller creates a lethal conduction path. Standard SPI is therefore only used for the direct connection between a microcontroller and a single ground-referenced AFE — which limits its use to small, low-voltage packs.

For multi-cell string applications, SPI is used locally between the microcontroller and the first AFE in a chain, with isoSPI carrying the signal onwards through the chain.

→ BMS hardware

isoSPI — Isolated SPI

isoSPI is the most important internal communication protocol in automotive battery management. Developed by Linear Technology (now Analog Devices) and integrated into the LTC681x family of battery stack monitor ICs, it is the dominant technology for communication between AFE slave devices in a multi-cell battery string.

The problem isoSPI solves:

In a 400V battery pack with 111 cells in series, the AFE measuring cells 101–111 is sitting at approximately 360V above chassis ground. The AFE measuring cells 1–12 is near ground. If standard SPI were used to daisy-chain these AFEs, the communication path would provide a conductive link between high and low voltage nodes — defeating the HV isolation required for safety. An isolated data path is mandatory.

How isoSPI works:

The isoSPI interface translates a full-duplex SPI signal of up to 1 Mbit/s into a differential signal, which is then transmitted via twisted pair and a simple, inexpensive transformer. This interface is integrated into Linear Technology’s most recent battery stack monitors, a set of analogue integrated circuits designed to measure battery stack cell voltages. Two isoSPI ports are included in the LTC6811, a 12-cell battery monitoring IC, enabling multiple devices to be daisy-chained for monitoring long, high voltage battery strings.

The galvanic isolation is provided by the transformer — there is no DC path across it, so the HV potential of the AFE cannot be conducted to the master processor. The differential signalling over twisted pair provides excellent common-mode noise rejection, which matters in the electrically noisy environment of a battery pack with fast-switching contactors and power electronics nearby.

Key characteristics:

Data rate: up to 1 Mbit/s
Isolation: galvanic, provided by pulse transformer
Topology: daisy chain (each AFE has two isoSPI ports — upstream and downstream)
Noise immunity: full performance against ultra-harsh 200 mA BCI (Bulk Current Injection) has been demonstrated and qualified for chassis-harness vehicle wiring
Typical chain length: up to 16 LTC681x devices on a single chain

Supplier ecosystem:

isoSPI is primarily associated with the Analog Devices (formerly Linear Technology) LTC6811 / LTC6812 / LTC6813 family. The competing Texas Instruments BQ79600 family uses a similar isolated daisy-chain approach. NXP’s MC33771/MC33772 BCC devices use a proprietary isolated SPI protocol via their MC33664 isolation transceiver.

Daisy Chain Topology

The daisy chain topology places AFE ICs in sequence along the cell string, each connected to the next via an isolated link. The master communicates with the entire chain through the first AFE; commands propagate down the chain and responses return up it.

The advantage is simplicity and low cable count — only two wires (plus transformer) span each AFE-to-AFE link, regardless of the voltage difference between them. The disadvantage is that a fault in any link in the chain disrupts communication with all AFEs beyond that point. Up to sixteen ADC units can be serviced on a single extended isoSPI bus.

Some designs use a ring topology instead of a simple chain — the last AFE connects back to the master, providing redundancy. If any single link fails, the chain can be traversed from the other direction.

I²C — Inter-Integrated Circuit

I²C is a two-wire (SDA data, SCL clock) synchronous serial protocol developed by Philips (now NXP). It is used in BMS hardware for lower-speed, shorter-range communication — typically between the BMS master microcontroller and peripheral devices on the same PCB: temperature sensor ICs, real-time clocks, EEPROMs, isolated ADCs for pack voltage measurement, and isolation monitoring ICs.

I²C is not used for multi-cell AFE daisy chains (SPI/isoSPI is standard for this) and is not suitable for inter-module communication in a pack. Its use in BMS hardware is as an on-board peripheral bus.

Key characteristics: 100 kbit/s (standard), 400 kbit/s (fast mode), 3.4 Mbit/s (high speed); multi-master, multi-slave; address-based arbitration; pull-up resistors required on both lines.

SMBus (System Management Bus) – a two-wire communication protocol, built on I²C, specifically used by “smart batteries” in laptops and consumer electronics to report SoC, cycle count, manufacturer data and fault codes to a host device

UART — Universal Asynchronous Receiver/Transmitter

UART is the simplest serial interface — two wires (TX and RX), no clock line, asynchronous. It is used in BMS applications primarily for debugging during firmware development, factory configuration, and end-of-line calibration. UART is also used extensively for debugging purposes when developing firmware for a BMS, allowing output of code to be printed and displayed on a screen.

In production systems, UART is not typically used as a primary communication interface — it lacks the multi-node capability of CAN, the noise immunity of differential protocols, and the speed needed for real-time cell data transmission. It appears at UART-to-USB or UART-to-Bluetooth bridge points for service and diagnostics.

External BMS Communications

CAN Bus

CAN (Controller Area Network) is the dominant external communication protocol for automotive BMS systems and the standard for BMS-to-vehicle communication in passenger EVs, commercial EVs, and most industrial battery applications.

Developed by Bosch in the 1980s and standardised in ISO 11898, CAN is a multi-master, differential bus. Any node can transmit when the bus is idle; collisions are resolved by arbitration without data loss. The two-wire differential signalling (CAN_H and CAN_L) provides excellent noise rejection in the automotive electrical environment.

Why CAN is dominant in automotive BMS:

Deterministic behaviour — CAN’s priority-based arbitration ensures that high-priority messages (contactor control, safety limits, overtemperature warnings) are transmitted with predictable latency
Multi-node — a single CAN bus connects the BMS, vehicle control unit, motor controller, onboard charger, and instrument cluster without point-to-point wiring between each
Well-understood — every automotive microcontroller has a CAN peripheral; every automotive ECU development team has CAN expertise; test tools and diagnostics are mature
Functional safety — CAN is well-characterised in terms of failure modes, and AUTOSAR CAN Stack implementations exist at ASIL D

What the BMS transmits on CAN:

In a typical automotive BMS, the CAN messages carry: pack voltage, pack current, SoC, SoH, SoP (maximum available charge and discharge power), cell voltage minimum/maximum/average, cell temperature minimum/maximum/average, fault flags, contactor status, and charge current limits for the OBC. The specific message format and ID allocation are defined in the vehicle-level CAN database (DBC file).

CAN bus speeds:

Classical CAN operates at 125 kbit/s, 250 kbit/s, or 500 kbit/s — the 500 kbit/s rate is standard for powertrain CAN in most automotive applications. The BMS master communicates with the vehicle network at this speed.

CAN for BESS:

In stationary battery energy storage systems, CAN is used for communication between the BMS and the power conversion system (PCS) / inverter. The BMS publishes available charge and discharge power limits; the PCS operates within those limits. Some BESS systems use Modbus or CANopen (an application layer protocol on top of CAN) rather than raw CAN.

→ BMS algorithms — SoC, SoH, SoP → Master and slave BMS

CAN FD — CAN with Flexible Data Rate

CAN FD is an evolution of classical CAN, standardised in ISO 11898-1:2015. It maintains CAN’s arbitration and multi-node architecture but adds two capabilities:

Higher data rate — the payload phase of the CAN FD frame can be transmitted at a much higher bit rate than the arbitration phase. While arbitration runs at the standard CAN rate (typically 500 kbit/s or 1 Mbit/s), the data phase can run at up to 8 Mbit/s. In practice, 2 Mbit/s data phase with 500 kbit/s or 1 Mbit/s arbitration is a common automotive configuration.

Larger payload — classical CAN frames carry a maximum of 8 bytes of data. CAN FD frames carry up to 64 bytes. This is significant for the BMS: transmitting all individual cell voltages in a single message becomes practical with CAN FD where it requires multiple frames with classical CAN.

Why CAN FD matters for BMS:

As pack cell counts increase (400+ cells in some applications), the volume of data the BMS must transmit grows. Transmitting all cell voltages at a useful update rate (100–200 ms) within the constraints of classical CAN bus load requires careful message scheduling. CAN FD reduces this pressure significantly. It is also the required transport for UDS (Unified Diagnostic Services) over CAN FD, which is the standard diagnostic protocol used for BMS calibration updates and end-of-line testing.

Current BMS reference designs include multiple CAN FD interfaces alongside LIN, automotive Ethernet, and SPI, reflecting the multi-protocol architecture of modern battery systems.

LIN — Local Interconnect Network

LIN (Local Interconnect Network, ISO 17987) is a single-wire, master-slave, low-speed serial protocol. It operates at 19.2 kbit/s (maximum 20 kbit/s), using a single wire plus ground — significantly simpler and cheaper than CAN.

In battery systems, LIN is used for lower-priority, lower-frequency communication where CAN is overkill. Typical BMS applications:

12V auxiliary battery management — the LFP or lead-acid 12V battery and its charge controller often communicate via LIN to the vehicle system
Thermal management sensors — some coolant temperature sensors and valve position sensors use LIN
Seat and climate control — in vehicles where the battery conditioning system is integrated with HVAC, LIN connects auxiliary actuators
Cell voltage sensor modules — in some architectures, simple cell voltage monitoring nodes communicate with the BMS via LIN (though isoSPI/CAN FD is more common for this in automotive)

LIN is always a single master, multiple slaves — the BMS master (or vehicle gateway) initiates all transactions; slaves respond only when polled.

RS485 and Modbus

RS485 is a differential two-wire serial interface standard (EIA-485) that supports multi-drop networks at distances up to 1,200m — far beyond the reach of CAN in standard configurations. It is the dominant external communication protocol for stationary battery energy storage systems (BESS), industrial battery applications, and telecom/UPS battery systems.

Modbus RTU and Modbus TCP are the most common application-layer protocols running over RS485 in BESS applications. The BMS publishes battery status registers (voltage, current, SoC, SoH, temperature, alarms) to a Modbus holding register map; the EMS (Energy Management System) or SCADA system reads these registers and writes setpoints (charge power limit, discharge power limit, enable/disable).

RS485 vs CAN for BESS:

RS485 is preferred over CAN for BESS external communication for practical reasons: it supports longer distances between the battery cabinet and the monitoring system without signal repeaters; Modbus is universally understood by SCADA/EMS systems without automotive-specific tooling; and RS485 transceivers are available in standard industrial packaging without the EMC and temperature requirements of automotive CAN.

For internal BESS communication (between BMS master and slave boards within a battery cabinet), CAN or proprietary protocols are more common.

RS485 stands out for its ability to handle long-distance communication, reaching up to 1,200 metres, with high noise resistance ensuring stable data transfer in industrial environments such as solar power plants or factory energy management systems.

Automotive Ethernet

Automotive Ethernet is the most significant development in vehicle networking in the current generation. Standard Ethernet was not suitable for automotive use due to its multi-pair cable requirement, susceptibility to EMI, and lack of time-determinism. Automotive Ethernet standards address these limitations.

100BASE-T1 (formerly BroadR-Reach): 100BASE-T1 employs a single unshielded twisted-pair cable to transmit and receive (full duplex) data over communication distances of at least 15 metres, operating at 100 Mbit/s. This simplifies the interface to a single twisted pair with universal applicability, significantly reducing cable numbers and cabling weight.

1000BASE-T1: The 1 Gbit/s variant, also over single unshielded twisted pair, being adopted for high-bandwidth applications (ADAS cameras, central compute platforms).

Role of Automotive Ethernet in battery systems:

In current generation vehicles, automotive Ethernet is not yet the primary BMS communication interface — CAN FD remains dominant for powertrain communication including BMS. However, Ethernet is being adopted for:

OTA (Over The Air) software updates — high-bandwidth BMS firmware updates require Ethernet; CAN FD is too slow for large calibration files and software packages
Diagnostics — DoIP (Diagnostics over IP, ISO 13400) over Ethernet is replacing UART-based diagnostic interfaces for BMS calibration and end-of-line testing
Cloud connectivity gateway — the telematics unit uses Ethernet to aggregate data from CAN and relay it to the cloud
Next-generation BMS masters — new BMS architectures with zonal ECU or central compute platforms use Ethernet as the backbone

SOME/IP (Scalable service-oriented Middleware over IP) and DoIP (Diagnostics over IP) are communication concepts included in the AUTOSAR software standard, which forms the basis for all current vehicle ECUs.

AUTOSAR Classic and AUTOSAR Adaptive both define the software architecture for BMS firmware, with Adaptive AUTOSAR specifically targeting the Ethernet-based high-compute platforms that next-generation BMS systems will run on.

Charging Communications

The communication between the EV and the charging infrastructure is a separate domain from the vehicle-internal CAN network. The charger and BMS must negotiate charge power in real time, and in more advanced systems, exchange authentication credentials and enable bidirectional energy flow.

ISO 15118 — Vehicle-to-Grid Communication

ISO 15118 is the standard for digital communication between an EV and an EVSE (charging station). It runs over the pilot signal line in the CCS connector (or over PLC — power line communication — on the charging cable).

Key capabilities:

Charge parameter negotiation — the EV’s BMS publishes maximum voltage, maximum current, and target SoC; the charger responds with available power
Plug & Charge (PnC) — ISO 15118-2 defines an automated authentication mechanism where the vehicle identifies itself to the charging network without a separate RFID card or app interaction. The vehicle certificate is stored in the BMS/secure element
V2G (Vehicle to Grid) — ISO 15118-20 extends the standard for bidirectional energy flow, including V2G frequency regulation services

DIN 70121

DIN 70121 is the predecessor to ISO 15118-2, still used by a large proportion of DC fast chargers in Europe. It provides the same basic charge negotiation function as ISO 15118 but without Plug & Charge authentication or V2G capability. Many deployed CHAdeMO and early CCS chargers communicate via DIN 70121.

SMBus

SMBus (System Management Bus) is a subset of I²C used in portable and consumer battery systems — notably laptop batteries (defined in the SBS — Smart Battery System — specification). The BMS publishes voltage, current, temperature, SoC, SoH, chemistry, and fault flags to standardised SMBus registers that the host system reads.

SMBus is not used in automotive or large-format industrial battery systems — it is specific to consumer portable devices. It is included here because engineers transitioning from consumer electronics to automotive battery development often encounter it and need to understand where it fits.

Wireless BMS Communication

Wireless BMS replaces the wired communication between the Cell Sensor Circuits and the BMS master with a radio link. GM’s Ultium architecture, developed with Analog Devices, was the first automotive production deployment at scale.

The value proposition: A large EV pack may have 20 or more CSC modules, each requiring a wired connection back to the BMS master. The LV harness weight, manufacturing complexity, and potential failure modes of hundreds of individual connections are significant. Wireless communication eliminates this harness entirely within the pack.

The technical challenges:

Latency — cell voltage measurements must be available to the BMS within a defined time window for safety protection functions. Wireless latency must be guaranteed and bounded
EMI — the battery pack environment contains switching power electronics, high di/dt transients from contactor operation, and strong magnetic fields. The wireless link must be immune to all of these
Power supply — the CSC boards must be powered from the cells they monitor (floating at battery potential), and the wireless transceiver adds to that power budget
Functional safety — a safety-critical communication link must meet ISO 26262 ASIL C or D requirements. Certifying a wireless link to ASIL D is technically demanding but has been achieved in the GM Ultium implementation

Technologies used: The GM/Analog Devices implementation uses a proprietary 2.4 GHz protocol. Other development programmes have evaluated Bluetooth Low Energy (BLE) and proprietary sub-GHz protocols.

→ Wireless BMS

Communication Protocol Summary

Protocol	Domain	Speed	Topology	Isolation	Primary BMS use
SPI	Internal	Up to 50 Mbit/s	Point-to-point or single chain	None	AFE to MCU (local, ground-referenced)
isoSPI	Internal	Up to 1 Mbit/s	Daisy chain	Galvanic (transformer)	AFE daisy chain in HV strings
I²C	Internal	Up to 3.4 Mbit/s	Multi-device on-board	None	Peripheral ICs on BMS PCB
UART	Internal	Up to ~4 Mbit/s	Point-to-point	None	Debug, factory calibration
CAN (Classical)	External	125–500 kbit/s	Multi-node bus	None (external isolation if needed)	BMS to vehicle network
CAN FD	External	Up to 8 Mbit/s data	Multi-node bus	None	BMS to vehicle; OTA; diagnostics
LIN	External	Up to 20 kbit/s	Single-master bus	None	Low-priority auxiliary comms
RS485/Modbus	External	Up to 10 Mbit/s	Multi-drop, long range	None (common in BESS)	BESS BMS to EMS/SCADA
Automotive Ethernet	External	100 Mbit/s – 1 Gbit/s	Point-to-point or switched	None	OTA, diagnostics, next-gen BMS
ISO 15118	Charging	Low (PLC)	Point-to-point	N/A	EV to EVSE negotiation, V2G
Wireless (proprietary)	Internal	Protocol-dependent	Star or mesh	N/A	Wireless BMS (CSC to master)

Choosing the Right Protocol

For most engineers implementing a BMS, the protocol choices are largely constrained by the application:

Automotive EV: CAN FD for external vehicle network communication; isoSPI (or equivalent proprietary protocol) for internal cell measurement chain; automotive Ethernet increasingly for OTA and diagnostics.

Stationary BESS: RS485/Modbus for external EMS communication; CAN for internal master-slave communication within the battery cabinet; isoSPI internally.

Industrial / commercial EV (forklift, AGV, bus): CAN for external communication; isoSPI internally. May use CANopen as the application layer.

Consumer / portable devices: SMBus for host communication; I²C/SPI for internal components.

The one protocol that spans all applications is CAN — even in BESS and industrial systems, CAN is typically present somewhere in the communication stack, usually at the BMS master level. Understanding CAN thoroughly — message framing, arbitration, error handling, DBC file structure, and the AUTOSAR software architecture that wraps it — is the single most impactful communication skill for a battery engineer.