BMS-15 — CAN / CAN FD / UDS / Diagnostics

1. A BMS Is Useless on Its Own

The SOC, SOP, and fault information the BMS computes is worthless if it just keeps it to itself — it has to reach systems like the VCU, the inverter, and the charger reliably. In automotive, that communication usually runs over CAN: a multi-node, differential serial protocol that’s robust against noise.

2. Why CAN FD Makes a Difference

Classic CAN carries 8 bytes per frame; CAN FD pushes that to 64 bytes, at a higher speed on top of that. Since a BMS has to periodically transmit voltage/temperature data for more than 96 cells, classic CAN’s small payload forces that data to be split across many frames. CAN FD means fewer frames, less bus load, and less latency.

3. What Does the BMS Say to the VCU?

Conceptual examples — not a real OEM’s definition:

• BMS → VCU: SOC, SOH, pack voltage/current, max charge/discharge current (SOP), temperature, warnings, faults.
• VCU → BMS: Wakeup, charge request, drive request, shutdown request, power/torque request.

A CAN frame contains an ID (message identifier), a control field, a data field, and a CRC. Because the data field is limited, a decimal value (like SOC = 67.3%) isn’t carried directly — it’s encoded as an integer and decoded on the receiving end with a scale/offset factor. For example, if SOC is encoded with a resolution of 0.1 and the raw value transmitted is 673, the receiver interprets it as 673 × 0.1 = 67.3%.

ASSUMPTION — This scale/offset example is purely conceptual; real values depend on an OEM-specific DBC definition and aren’t fabricated here. Real OEM CAN IDs and signal definitions can’t be used without independent verification.

4. UDS and DTC

UDS (ISO 14229) is a standard protocol for diagnostic services — a service tool can use it to read/clear DTCs, read data, and run routines like calibration. A DTC (Diagnostic Trouble Code) is a standard code that identifies a fault; the BMS logs the relevant DTC once it confirms a fault.

5. What Happens When Communication Drops?

The BMS monitors whether critical messages arrive within a set period using a message timeout mechanism. If an expected message (a wakeup request from the VCU, or cell data from a CMU) doesn’t arrive within the timeout window, it’s classified as a communication-loss fault (see the CAN case study in BMS-13). Functions relying on the lost data default to the safe side: if data from a CMU is cut off, the affected cells are flagged “no data” and treated as worst-case; if communication with the VCU is fully lost, the vehicle typically enters a safe mode.

6. How It’s Verified in Production

CAN signal definitions (DBC files) and timing are verified on a real CAN bus during EOL testing. HIL testing checks that the message-timeout and plausibility mechanisms work correctly under scenarios like a broken line, a noisy bus, and injected corrupt messages (BMS-19).

7. How It Connects to Other Systems

CAN communication carries SOC/SOH/SOP data to the VCU (BMS-08/09/10), exposes fault management’s DTC records to service tools (BMS-13), and is a core component of the Services layer in the software architecture (BMS-16). Cybersecurity measures (BMS-18) are aimed directly at protecting this channel.

Summary

• CAN is robust and widespread; CAN FD is faster and carries more data.
• Signals are encoded into a limited data field with scale/offset; real CAN IDs can’t be used without verification.
• The message-timeout mechanism catches communication loss and keeps the system on the safe side.

Sources

• ISO 11898 (CAN), ISO 14229 (UDS).
• ISO 26262 — communication safety context.