← Back to: Battery Charging / Gauging / Protection / BMS
Role of the BMS Bus in the Charging Branch
This section scopes the bus to the charging branch of the BMS: it is the communications path that lets the charger / power-path controller, the cell monitor with balancing hooks, and the vehicle gateway or cloud edge see the same charging state. It is not a tutorial on the entire in-vehicle network. If this bus goes down, the system cannot guarantee JEITA-compliant charging.
Charging / power-path controller
Runs the CC → CV → taper → terminate state machine and knows when VIN or MOSFET faults happen. Must publish CHG_STATE and CHG_FAULT_CODE.
Cell monitor / balancing AFE
Knows per-cell temperature and whether balancing is inhibited by temperature or charge-in-progress. Must publish BAL_ACTIVE and BAL_INHIBIT_REASON.
Vehicle gateway / cloud edge
Consumes charging status, JEITA zone and device brand / revision to log events, trigger OTA and refresh the cloud-side telemetry mapper.
Signals that must go on the charging BMS bus
Keep these six groups together; this is the minimum set for cloud-side normalization and procurement control.
- CHG_STATE (Pre / Fast / CV / Taper / Terminated / Recharge)
- JEITA_ZONE (Cold / Cool / Normal / Warm / Hot)
- CHG_FAULT_CODE (VIN missing, NTC open, safety timer, watchdog, MOS short)
- BAL_ACTIVE and BAL_INHIBIT_REASON
- VSYS_PRIORITY / SYS_SUPPLY_MODE (VSYS from VIN or from VBAT)
- FW_REV / IC_BRAND (for OTA and cloud-side telemetry mapping)
Bus-down strategy: for safety-critical designs, if the charging BMS bus is down, stop or sharply derate charging. For portable or less critical profiles, keep charging but label measurements as NOT_SYNCHRONIZED for the gateway / cloud.
Do not approve non-reporting charger ICs. Cloud-side telemetry mapping must be updated before using cross-brand alternatives. Devices that only support fixed-temperature charging must not replace NTC / JEITA-enabled parts.
Message Set for Charging, Balancing, and JEITA over CAN-FD/LIN
This section defines the stable charging-domain message set so that a cloud-side telemetry mapper can normalize payloads coming from TI, ST, NXP, Renesas, onsemi, Microchip and Melexis devices, without modifying the vehicle gateway firmware. Keep the field names consistent and tell procurement not to use non-reporting ICs.
Charging-domain field set (10–12 keys)
These are the keys the cloud mapper expects to see:
BUS_VER/PROFILE_ID— tells the cloud which message profile this node is using.CHG_STATE— 0 idle, 1 pre, 2 fast, 3 cv, 4 taper, 5 term, 6 recharge.JEITA_ZONE— -1 sensor_fail, 0 cold, 1 cool, 2 normal, 3 warm, 4 hot.TEMP_SENSE_STATUS— NTC present / fixed-temp-only.BAL_ACTIVE— bitmap or aggregated.BAL_INHIBIT_REASON— overtemp / charge_in_progress / cell_high.CHG_FAULT_CODE— DTC-mappable faults.SYS_SUPPLY_MODE— VSYS from VIN / VBAT / pass-through.IC_BRAND+IC_REV— supports cloud-side mapper update when cross-brand alternatives are used.SECURE_FLAG— 0 = non-secure, 1 = key-based.
Do not remove these keys when you change brand. Instead, tell the cloud mapper to adopt the new profile.
CAN-FD payload strategy
Use one fast frame for CHG_STATE + JEITA_ZONE + CHG_FAULT_CODE. Use one slow frame for PROFILE_ID + IC_BRAND + IC_REV + SECURE_FLAG. Both can fit easily in 64-byte frames.
Fast: 100–500 ms. Slow: 1–5 s or on-demand.
LIN payload strategy
Split into a fast periodic frame (at least CHG_STATE + JEITA_ZONE + CHG_FAULT_CODE) and a slow / diagnostic frame for brand / revision / profile. Devices that cannot send the diagnostic frame must be explicitly downgraded in the cloud mapper.
Fast: 100–500 ms. Slow: 1–5 s or on gateway request.
Do not approve non-reporting charger ICs. Cloud-side telemetry mapping must be updated before using cross-brand alternatives. Devices that only support fixed-temperature charging must not replace NTC / JEITA-enabled parts. Use only CAN-FD/LIN devices from TI, ST, NXP, Renesas, onsemi, Microchip or Melexis on this branch.
Diagnostics / UDS for Charging-Oriented BMS Nodes
This chapter defines the minimal UDS set a charging-branch BMS node must support so the vehicle gateway and the cloud can read charging state, JEITA zone, balance inhibit and device identity. You do not need to port the full vehicle-level UDS; you only need the small subset used by this charging branch. If you purchase CAN/LIN devices that do not support these services, the cloud cannot see the required data.
0x10 Diagnostic Session Control
Enter extended session to access charging-related DIDs. Keep it small and scoped to the charging node.
0x22 ReadDataByIdentifier
Read JEITA zone, charging state, IC brand/revision and the cloud mapper profile ID.
0x19 ReadDTCInformation
Report temp-sensor-missing, charge-inhibit and balance-inhibit as DTCs so cloud can diagnose remote packs.
0x2E WriteDataByIdentifier
Light-weight writes: reporting interval, max charge current, balance reporting enable.
0x27 SecurityAccess
Protect the charging node before OTA or cross-brand profile changes. Will be linked to Chapter 4.
Recommended DID layout for the charging branch
These DIDs mirror the message set in the previous chapter, so cloud-side telemetry mapping can stay stable even when devices are substituted.
- DID 0xF200 — Charging State: Same enumeration as
CHG_STATE(0 idle, 1 pre, 2 fast, 3 cv, 4 taper, 5 term, 6 recharge). - DID 0xF201 — JEITA Zone + NTC status: Encodes JEITA zone plus “NTC present / NTC open”. This is where you express “NTC-driven hotspot derating is REQUIRED.”
- DID 0xF202 — Balance status / inhibit reason: Reports whether balancing is active or was inhibited by temperature or charging.
- DID 0xF210 — IC Brand / IC Revision / Secure-capable: Tells gateway and cloud exactly which device is sitting on the charging bus.
- DID 0xF220 — Cloud mapper profile ID: Must be updated whenever you use cross-brand alternatives so the cloud can change the decoder.
Fault → DTC mapping (charging scope)
NTC missing / open → medium-priority DTC → tell purchasing not to use fixed-temperature-only parts.
Bus timeout on the charging BMS bus → high-priority DTC → recommend to stop or derate charging.
Non-reporting charger IC → DTC “device does not expose mandatory charging signals” → send to purchasing to trigger cross-brand replacement.
Cloud-side telemetry mapping must be updated before using cross-brand alternatives.
This chapter is limited to the charging branch. It does not cover OBD legislation, production-line flashing or EOL testing.
Key-Based Authentication and OTA Security Hooks on the Charging BMS Bus
This chapter explains why a charging BMS bus must be secured and how OTA must carry the node’s identity (brand, revision, capability bitmask) so the cloud mapper can adapt. Many small-batch substitutions fail OTA because the replacement LIN/CAN device is non-secure or does not report its identity. Such devices must not be approved.
Fake charger IC
Pretends to be in CV, does not implement JEITA, and still announces “OK to charge”. Must be blocked by key-based join.
Non-reporting IC
Cheaper replacement that does not send charging/JEITA/balance frames; OTA and cloud lose visibility.
Bus spoofing
Attacker injects “charge-inhibit cleared” or “all cells normal”. Must be authenticated per node.
Required security capabilities on the charging bus
- CAN-FD transceiver or SBC with secure key slot.
- Charger MCU with secure boot and signed firmware.
- OTA payloads that embed device identity (brand + revision + capability bitmask).
Do not approve non-secure CAN/LIN devices on the charging BMS bus.
Key-based authentication flow
1) Gateway sends a challenge on a dedicated CAN ID.
2) Charging BMS node responds using its secure key (can be bound to 0x27 SecurityAccess).
3) If authentication fails, allow charging but report “non-secure” to the cloud so the fleet can be flagged.
OTA security hooks
• Before OTA → read DID 0xF210 to confirm brand and revision.
• Apply OTA → signed, secure-boot-compatible firmware only.
• After OTA → write DID 0xF220 to tell the cloud the profile changed.
Cloud-side telemetry mapping must be updated before using cross-brand alternatives.
BOM remark: “Do not approve non-secure CAN/LIN devices on the charging BMS bus. Cloud-side telemetry mapping must be updated before using cross-brand alternatives. Devices that only support fixed-temperature charging must NOT replace NTC / JEITA-enabled parts.”
IC / Device Mapping across TI, ST, NXP, Renesas, onsemi, Microchip, Melexis
This chapter locks the charging-domain BMS bus to seven suppliers only. Use TI, ST, NXP, Renesas, onsemi, Microchip, or Melexis for CAN-FD / LIN / SBC / secure-MCU parts that must report charging state, JEITA zone and diagnostic status. When you substitute across brands, the cloud-side telemetry mapper must be updated to decode the frames correctly.
① Charger / power-path controller
TI BQ chargers (e.g. BQ24075-Q1, BQ25619-Q1) + host MCU → push charging state to CAN/LIN.
Needs bridge (MCU + CAN-FD) to join the charging BMS bus.
② Cell monitor / balancing AFE
ST L9963E, Renesas ISL78714 → have cell temp + balancing inhibit. Connect to domain MCU, then publish to bus.
Must report “balance inhibited by temperature”.
③ CAN-FD / LIN / SBC
TI TCAN4550-Q1, TCAN1145-Q1; NXP TJA1443; onsemi NCV7357; Microchip MCP2562FD; Melexis MLX81112 (LIN accessory).
FD + diag + optional secure is preferred.
④ Charging-domain MCU / SoC
NXP S32K3, ST SPC58, Renesas RH850, Microchip PIC32MZ + MCP2518FD.
These MCUs build the message set defined in Chapter 2.
TI (Texas Instruments)
CAN-FD / SBC: TCAN4550-Q1, TCAN1145-Q1, TCAN1042-Q1.
Charger/PMIC hooks: TPS65381A-Q1 (safety PMIC), BQ-series chargers (needs host).
Substitute → update cloud mapper.
STMicroelectronics
Cell/BMS: L9963E (multi-cell monitor + NTC + balancing).
Automotive nodes: L99xx family, MCU: SPC5/SPC58 with CAN-FD.
Use ST-to-ST first; cross-brand → cloud update.
NXP
Transceivers: TJA1443, TJA1044GT (LIN-to-CAN scenarios).
Controller: S32K312 / S32K3x for charging/BMS.
TI → NXP swap is allowed, but mapper must know the new brand/rev.
Renesas
AFE: ISL78714 (multi-cell, balancing).
MCU: RH850 + CAN-FD + LIN.
Keep AFEs + MCUs in same brand to simplify diagnostics.
onsemi
CAN/LIN: NCV7357, NCV7356, auto-grade SBCs.
Good for simple charging add-ons that still need FD or wake.
Cross-brand → must align frame layout.
Microchip
CAN-FD: MCP2562FD, controller: MCP2518FD.
MCU: PIC32MZ, SAM E5x with FD support.
Works well as FD bridge for TI/ST chargers.
Melexis
LIN accessory / actuator: MLX81112, MLX81113, MLX81115, MLX81109.
Can subscribe to CHG_STATE / JEITA broadcast.
LIN-only → mark as limited diagnostics.
BOM remark: “Use only CAN-FD/LIN devices from TI / ST / NXP / Renesas / onsemi / Microchip / Melexis on this branch; update cloud-side mapper when substituting.”
Small-Batch Procurement & Cross-Brand Alternatives (Charging-Bus View)
This chapter targets small-batch / service / aftermarket scenarios where the original FD device is not in stock. The main risk is buying a LIN-only node that does not report charging state, JEITA zone or diagnostics; once installed, OTA, gateway and cloud all lose visibility. Write the BOM so that non-FD and non-secure parts are not approved.
Path A → A (same brand)
TI TCAN1042-Q1 → TI TCAN1145-Q1 NXP older CAN → NXP TJA1443 Microchip MCP2561FD → MCP2562FD onsemi NCV7356 → NCV7357
Keep message set unchanged → cloud mapper still valid.
Path A → B (cross-brand)
TI TCAN4550-Q1 ↔ NXP TJA1443 Microchip MCP2518FD + MCP2562FD ↔ TI TCAN4550-Q1 Renesas ISL78714 + RH850 ↔ ST L9963E + SPC5
Cross-brand ⇒ update cloud mapper profile.
Path A → LIN-only downgrade
Use Melexis MLX81112 / MLX81113 or other LIN accessory node only when FD parts are unavailable. Must send periodic CHG_STATE/JEITA over LIN and must mark itself as non-secure / limited diagnostics.
Cloud profile = “LIN-reduced”.
BOM remarks to copy
1) NTC-driven hotspot derating is REQUIRED.
2) Do NOT substitute non-FD or non-secure transceivers on the charging BMS bus.
3) Cloud-side telemetry mapping must be updated before using cross-brand alternatives.
4) Charger/gauge must expose charging state and JEITA zone to the edge gateway.
5) Devices that only support fixed-temperature charging must NOT replace NTC/JEITA-enabled parts.
Small-batch acceptance checklist
- Node can enter diagnostics session: UDS 0x22 / 0x19.
- Node can send CHG_STATE within 500 ms.
- Node can report brand / revision (DID 0xF210).
- Node can set secure / non-secure bit; if non-secure → send to cloud.
- Node can be mapped to the seven-brand profile on the cloud.
This chapter does not cover commercial negotiations, customs / export, or vehicle-level BOM strategies. It is limited to the charging-BMS-bus view.
BOM Remarks & Cloud-Side Telemetry Mapping
This section collects all BOM-level sentences we used across previous chapters. Paste them as-is into the project BOM so purchasing will not buy non-reporting or non-secure parts for the charging-domain BMS bus. It also explains why every cross-brand substitution must trigger a cloud-side telemetry mapper update.
Standard BOM remarks (copy & paste)
1) Charger / gauge must expose charging state and JEITA zone to edge gateway.
2) Signed safety metering is required; do not approve ICs without reporting capability.
3) Cloud-side telemetry mapping must be updated before using cross-brand alternatives.
4) Devices that only support fixed-temperature charging must NOT replace NTC / JEITA-enabled parts.
5) Use only CAN-FD/LIN devices from TI / ST / NXP / Renesas / onsemi / Microchip / Melexis on this branch.
6) Do NOT substitute non-FD or non-secure transceivers on the charging BMS bus.
Why is the BOM so explicit?
The message set for this charging-domain bus is not the global vehicle DBC. It is the compact message set we defined in Chapter 2 (CHG_STATE, JEITA_ZONE, CHG_FAULT_CODE, BAL_INHIBIT_REASON, SYS_SUPPLY_MODE, IC_BRAND, IC_REV, SECURE_FLAG). Once purchasing replaces a TI TCAN4550-Q1 with an NXP TJA1443, or a ST L9963E with a Renesas ISL78714, field names or bit locations can become vendor-specific. Without a BOM remark, the cloud team will not know that the frame layout has changed.
The BOM is therefore the only reliable place to tell purchasing: “only these seven brands are allowed, and every cross-brand move must force a cloud mapper refresh.”
JEITA / NTC / diagnostics / secure are all listed because all four directly affect charging safety. If any one of them is missing, the gateway may decide to hold or stop charging.
Engineering → Purchasing → Cloud handover format
Engineering provides:
- Message set version:
CHG-BUS-PROFILE = 2.1 - Expected fields:
CHG_STATE, JEITA_ZONE, CHG_FAULT_CODE, BAL_INHIBIT_REASON, IC_BRAND, IC_REV, SECURE_FLAG - Approved vendor range:
TI / ST / NXP / Renesas / onsemi / Microchip / Melexis
Purchasing returns:
- Actual brand: e.g. NXP
- Actual revision: e.g. TJA1443 Rev.1.2
- Transport capability: e.g. CAN-FD 5 Mbps, LIN 20 ms periodic, no secure bit
Cloud mapper updates:
- Map actual brand/rev to current charging message set.
- If downgraded to LIN-only → switch to “LIN-reduced” profile.
- If secure bit is missing → report “non-secure, allow charge with limitations.”
Scope of this section: charging-domain BMS bus only. It does not describe the cloud platform architecture, data lakes, or mappers for other vehicle domains.
Request a Quote
Frequently Asked Questions
All questions below are limited to the charging-domain BMS bus (CAN-FD / LIN). They do not cover vehicle-level OBD, off-board chargers, or unrelated BMS hardware.
Why does my charger report CC/CV locally but the gateway never sees the transition?
Because the local charger is reporting over I²C/SPI only. The charging-domain CAN-FD/LIN fast frame must also carry CHG_STATE in 100–500 ms periods. If the node is a downgraded LIN-only part, the gateway may time out before the transition arrives.
How do I encode JEITA zones over CAN-FD or LIN without modifying the gateway firmware?
Use the fixed JEITA enumeration from this page: -1 = sensor_fail, 0 = cold, 1 = cool, 2 = normal, 3 = warm, 4 = hot. Put it in the fast CAN-FD frame; for LIN, place it in the slow/diagnostic frame and keep the ID unchanged so the gateway can parse it with the existing profile.
Can I run charging status on CAN-FD while keeping balancing reports on LIN?
Yes. Define two sub-profiles in the cloud mapper: one for fast charging state on CAN-FD, one for balancing/temperature inhibit on LIN. In the BOM, specify that the project uses a split bus so purchasing will not merge the two onto a single low-rate LIN node.
What UDS services are mandatory for a charging-oriented BMS node?
At minimum: 0x10 Diagnostic Session Control, 0x22 ReadDataByIdentifier (JEITA, charging state, brand/rev), 0x19 ReadDTCInformation (NTC missing, charge inhibit, balance inhibit), 0x2E WriteDataByIdentifier (tweak current/reporting rate), and 0x27 SecurityAccess to pair with key-based auth.
How do I protect OTA updates to the charger controller on this shared BMS bus?
Perform key-based join on the charging bus, read DID 0xF210 to confirm IC brand/revision, deliver the signed firmware, and after OTA report the new profile ID so the cloud-side mapper can re-bind the signals to the new firmware version.
What happens if purchasing substitutes a non-FD LIN transceiver on the charging branch?
The bus becomes LIN-only / non-secure / limited diagnostics. You must downgrade to a “LIN-reduced” cloud profile, extend the reporting interval, and keep the BOM remark stating this is a temporary fallback due to component availability.
How do I trigger a cloud-side telemetry mapper refresh after a cross-brand replacement?
Report the actual brand and actual revision (for example “NXP TJA1443 Rev.1.2”) back to the cloud together with the existing message set version. The mapper compares the two; if the brand/rev is unknown, it loads or requests an updated decoding profile.
Can balance-inhibit-by-temperature be exposed as a DTC?
Yes. Map it to a medium-priority DTC and expose it through UDS 0x19. This is important because it tells the cloud that the cells are healthy but balancing is intentionally paused due to temperature.
Do I still need secure boot if my CAN-FD transceiver already supports key-based authentication?
Yes. The transceiver checks who is allowed on the bus; secure boot checks that the firmware running on the charger or BMS node was not tampered with. Both are needed for OTA on a shared charging bus.
How often should charging status frames be transmitted to avoid gateway timeouts?
Keep charging-state frames at 100–500 ms; JEITA and temperature at 500–1000 ms; diagnostics on demand. Slower than this and the gateway may mark the node as “NOT_SYNCHRONIZED”.
Which brands are approved for cross-brand alternatives on the charging BMS bus?
TI, ST, NXP, Renesas, onsemi, Microchip, and Melexis. Other vendors are not covered by the message-set definition in this page and may require a custom cloud mapper.
What BOM remark will prevent purchasing from using non-reporting charger ICs?
“Signed safety metering is required; do not approve ICs without reporting capability.” This makes it clear that parts without telemetry support cannot be used on this bus.
