← Back to: Battery Charging / Gauging / Protection / BMS
Definition & Boundaries (Charging Domain)
“Battery to the cloud” is not a single bucket. This page focuses only on charging-domain telemetry and alerts: charge state transitions (precharge/CC/CV/terminate/recharge), JEITA temperature zones, instantaneous I/V, and any temperature/safety-driven derating during charge. Everything else stays out.
Why inside the Charging branch? (1) Charging most often triggers safety policies; (2) charger ICs/AFEs already expose state machines and event bits—edge collection is cheap; (3) other BMS pages (protection/leakage) need the actual charging-time context to explain their anomalies.
In scope
- Charge states, JEITA zones, I/V snapshots
- Derating due to temperature/safety timers
- Edge sampling vs. cloud reporting strategy
Out of scope
- HV insulation monitoring (see “Insulation/Leakage Monitor (HV)”)
- Multi-cell balancing & stack control (2S–6S)
- USB-C PD negotiation, vehicle IoT, OTA/FOTA, multi-tenant billing
Edge sampling frequency is typically higher than what the cloud actually needs. The real job here is to select what to upload without losing safety cues. Cloud analytics aims to reconstruct the charging process; without explicit “I’m in warm now”, “CC→CV just happened”, or “NTC opened”, reconstruction is guesswork.
BOM seed: Charger/AFE must expose charge state and JEITA zone to the edge gateway; devices with only fixed-temperature charging are not acceptable.
Edge Data Plane — Required Fields
The six mandatory fields below anchor every later section (uplink cadence, signed metering, cross-brand mapping, and BOM notes). If your IC does not report JEITA explicitly and only hints “reduced current,” cloud analytics can only infer, not assert.
Charge state
precharge → fast-CC → CV → terminate → recharge; used to reconstruct each charge cycle.
JEITA zone
cold / cool / normal / warm / hot; explains temperature-driven derating decisions.
Ichg actual vs. set
Mismatch implies thermal/safety limits; must be logged with timestamp.
VBAT / VSYS / VIN snapshot
At least VBAT; VSYS/VIN when available to reconstruct power-path context.
Event bits
NTC open/short, safety timer expiry, input UVLO; primary alert sources.
Device identity
brand, PN, lot/batch; anchors cross-brand and small-batch consistency.
Represent each alert as a charging-context event—bundle the JEITA zone, Ichg, and VBAT snapshot at that instant. This distinguishes real thermal conditions from simple “reduced current” hints.
Minimal event payload (draft):
{ ts, device_id, pn, charge_state, jeita_zone, ichg, vbat, event_code }
Note: vendor field names vary (TI granular, Microchip simpler, onsemi often minimal) → mapped later in cloud.
BOM seed: Do not approve alternatives that fail to report charge_state, jeita_zone, and vbat. If only “charging/not charging” is available, prepare a cloud-side mapping update before deployment.
Telemetry Packaging & Uplink Cadence
Charging behavior is bursty (JEITA change, safety timer hit, CC→CV transition), but cloud analytics expects ordered, continuous data. That is why edge must run two tracks in parallel: event-driven uploads for safety, and periodic uploads for analytics.
Event-driven (safety-first)
Trigger whenever charge_state, JEITA zone, or safety event changes. Ideal for high-reliability and automotive-oriented chargers.
Periodic (analytics-first)
Send a compact snapshot every 5 min, on charge completion, or at recharge start. Cloud uses these to rebuild the full charge history.
Because low-cost edge nodes often use basic MCU + Wi-Fi/BLE modules, do not uplink the whole BMS. Send only charging-domain fields defined in this page (state, JEITA, I/V, events, device identity).
Late arrivals (edge was offline) must carry ts_local,
seq, and device_id.
Otherwise, the cloud cannot place them back onto the charging timeline and anomaly models will drift.
For bandwidth-constrained deployments, combine multiple events into one batch at the edge, then let the cloud split by timestamp.
BOM seed: Edge device must support ring-buffered, ordered upload for charging-domain events. For low-bandwidth modules, batch multiple events into a single uplink frame.
Signed Safety Metering (Minimal Set)
Charging-time anomalies (thermal derating, NTC faults, safety timer hits) are the ones most often used for supplier/field/customer attribution. These records must not be editable en route to the cloud, so the signature is created at the edge, not in the cloud.
A signed payload is therefore: timestamped, sequenced, device-bound, and charging-context aware. If the charger IC cannot sign, the edge MCU/gateway must collect raw charging measurements and sign on its behalf.
meas_ts
Timestamp at edge when the charging measurement was taken.
energy_in / charge_in_mAh
How much charge/energy entered the battery in this step.
charge_state_at_meas
To re-create the charging phase during which the record was made.
jeita_zone_at_meas
So cloud can tell if it was a temperature-driven limit.
safety_event_code
Optional but strongly recommended (NTC open/short, safety timer expiry).
device_id / pn / vendor
Required for small-batch and cross-brand traceability.
sig (edge-generated)
MAC or digital signature computed at edge before uplink.
To prevent replay, always include the ts,
seq, and
device_id trio in the signature.
Cloud will reject packets with duplicated device_id + seq
or out-of-order timestamps.
For small-batch deployments, a shared-key MAC is acceptable. For high-volume or customer-facing deployments, switch to a public-key scheme and keep the payload structure the same.
BOM seed: Charger / gauge must expose charging measurement to the edge gateway for signing. Do not approve ICs that cannot provide per-charge metering or that prevent edge-side signing.
Cloud Analytics & Model Updates
Cloud consumes charging-domain telemetry only (states, JEITA zones, actual I/V, safety events, PN/vendor) and does three things: visualize/converge behavior across boards, detect anomalies that point to procurement changes, and push updated JEITA / thresholds without interrupting a charge already in progress.
1) Converge & visualize
Plot charge curves for different batches, IC brands and JEITA strategies. Healthy deployments form one “family” of curves.
2) Detect abnormal warm entries
Several units of same batch going warm too often → likely a replacement without NTC / reduced telemetry → alert purchasing.
3) Push model / JEITA updates
Seasonal or regional tweaks (summer → lower warm, cold region → extend cold~cool) are authored in cloud and delivered to edge.
Non-interrupt rule: Edge must mark the new model as pending, finish current CC/CV cycle, then switch and immediately upload
a model_switched event. This keeps cloud timelines consistent.
Because TI / ST / NXP / Renesas / onsemi / Microchip / Melexis expose different field names and JEITA encodings, cloud must maintain a telemetry schema table (compat layer). Edge may stay on v1 while cloud is already at v2 — compat layer absorbs the difference.
BOM seed: “Cloud telemetry mapping must be updated before approving this alternative.” “Edge shall support apply-after-charge for model updates.”
Cross-Brand & Small-Batch
R&D often selects a charger IC with full telemetry, but small-batch procurement swaps it for lead time or price. Cloud then starts receiving half-empty packets. This chapter defines three replacement paths and how cloud should normalize them.
A → A (same brand/series)
Fields usually stay compatible, cloud mapper stays the same. Still verify signed metering wasn’t removed in the cheaper PN.
A → B (cross-brand)
Field names, enums and JEITA bands all change. BOM must say: “Cloud telemetry mapping must be updated before approving this alternative.”
A → low-telemetry part
Edge must measure I/V/NTC and synthesize a standard charging payload. If edge cannot, mark the PN as do NOT approve.
TI — richest events, best kept.
Microchip — minimal states → cloud must fill gaps.
onsemi — easy to source, double-check field granularity.
NXP / Renesas — often inside PMIC, edge MCU must re-pack.
Melexis — car-grade story breaks if swapped to consumer silently.
Cloud should run a field-consistency check: same product/batch but missing JEITA or missing Ichg_real → raise a “possible mixed lot / procurement replacement” alert and send it to purchasing.
BOM seed: “Cloud telemetry mapping must be updated before approving this alternative.” “Do not approve low-telemetry chargers unless edge can synthesize a standard charging payload.”
Security & Anti-Tamper
This section locks down charging-domain telemetry so the cloud can trust it. It does not cover enterprise IAM, full PKI rotation or vehicle-wide security. We only ensure: the packet was produced at the time of charge, it hasn’t been replayed, and the charger IC really is the one listed in the BOM.
Anti-replay
Same charge log (same ts +
seq +
device_id) can be accepted once only.
Everything else goes to rejected.
Anti-offline rewriting
If edge was offline and later uploads a batch, each event must have its own signature and ordered sequence. Missing numbers → suspicious.
Anti-fake / anti-unapproved IC
If procurement swapped to a low-telemetry charger, edge must flag telemetry_cap=degraded so cloud can warn purchasing.
Minimal secure payload this page accepts:
ts
seq
device_id
pn
sig
charging_ctx{state,jeita,ichg,vbat,event}
If any of these are missing, cloud should not move the packet into analytics or downstream BMS pages.
Common attacks / incidents (for charging-domain telemetry)
Procurement swapped to low-telemetry PN
Cloud sees JEITA/state/Ichg fields disappear → flag “mixed lot / suspected substitution”.
Local edit of edge buffer
Signature mismatch → rejected; event kept in audit.
Offline + replay
Sequence not continuous → accepted-but-flagged or rejected by policy.
Fake charger reports “charging/not charging” only
Telemetry capability bit is “degraded”; cloud must notify purchasing.
Cloud rejection / accept-but-flag policy
Rule 1. sig invalid → reject → write audit → optional alert.
Rule 2. seq gap > allowed (e.g. >2) → accept-but-flag → mark source as “unstable”.
Rule 3. pn not in approved_pn_list → alert procurement.
Rule 4. JEITA missing but PN is JEITA-capable → alert: telemetry degraded.
Reference PNs (7 brands)
BOM remark: “Edge must send ts, seq, device_id, pn and sig for every charging-domain event. Packets without these fields shall not be used for analytics.”
Validation & Field Ops
This section tells the lab and field teams how to prove the charging-domain analytics is actually working: golden charge, degraded-telemetry charge, offline catch-up, and daily JEITA-miss watch. Results should be written into your work order / BOM notes.
1) Lab charge (golden kit)
Use TI BQ25895RTWR + ST STC3115IJT + Melexis MLX91231. Cloud must show CC→CV→Terminate, JEITA changes and safety events.
2) Degraded telemetry test
Swap to onsemi NCP1855 or Microchip MCP73871-2AAI/ML. Cloud must immediately mark “missing telemetry → check procurement”.
3) Offline & catch-up
Charge while offline → edge buffers signed events → come back → cloud sorts by ts+seq without reordering.
Acceptance criteria (to write into work order/BOM)
- Safety events (JEITA warm, NTC fault, safety timer) visible in cloud in ≤ 5 s.
- Critical fields (
charge_state,jeita_zone,ichg_real,vbat) present in ≥ 99% packets. - Model updates delivered to edge before next charge starts.
- Offline batch preserves order (no time-line drift after reconnection).
Verification script shape
Purpose: prove golden kit reports all charging-domain fields.
Steps: lab supply → set battery temperature → run CC/CV → disconnect network → reconnect.
Expected cloud fields: charge_state, jeita_zone, ichg_set, ichg_real, vbat, event_code, pn, sig, ts, seq.
Exception: if jeita_zone missing for PN known to support JEITA → raise “telemetry degraded”.
Field ops / periodic checks
Daily – pull list of devices that did not report JEITA → send to purchasing.
Weekly – check for sig failures / seq gaps → site visit if recurring.
Monthly – compare approved PN list vs actual reported PN (ISL9238, MC33772C, BQ25895).
Validation PNs (7 brands)
BOM remark: “Each batch must pass lab charge + degraded-telemetry test + offline catch-up before field rollout.”
BOM Remarks & Procurement Hooks
This section consolidates all “must write into BOM / work order” sentences from this page. Purchasing can copy/paste directly. Scope is charging-domain edge→cloud telemetry only: exposure of state/JEITA, signed safety metering, cross-brand mapping, buffered upload. It does not cover price, lead time, or marketing copy.
“All charger / gauge alternatives must stay within TI / ST / NXP / Renesas / onsemi / Microchip / Melexis. If procurement changes PN — even inside the same brand — cloud telemetry mapping must be updated before deployment.”
Mandatory BOM remarks
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. Edge device must support buffered upload for temporary disconnection.
Recommended / nice-to-have remarks
- Packets missing <charge_state, jeita_zone, ichg_real, vbat> shall be treated as degraded telemetry.
- Procurement must notify cloud ops when replacing charger / gauge PN even inside the same brand / series.
- Do not approve chargers that hide safety timer expiry or NTC fault bits.
- Apply-after-charge model update is mandatory; edge shall not switch JEITA table mid-charge.
Approved brand scope (must tell purchasing)
Approved charger / gauge brands for this edge–cloud charging analytics page: TI, ST, NXP, Renesas, onsemi, Microchip, Melexis. For any substitution within these brands, cloud-side telemetry mapper must be updated and re-validated with the golden charge script.
FAQ — Edge–Cloud Charging Telemetry (12)
All questions below stay inside this page’s domain: edge–cloud + charging telemetry + signed safety metering. They do not cover HV insulation, multi-string balancing or pack-FET control.
How often should edge upload during CC/CV?
Use event-driven for state/JEITA changes + periodic (5 min or at charge end) for health.
Procurement: “Edge MCU must support event+periodic upload.”
What if the device is offline during charge?
Edge must buffer last N events with ts+seq and replay when online.
Procurement: “Edge must support buffered upload.”
Can we batch small events to save bandwidth?
Yes, but every event keeps its own ts+seq+charging context.
Procurement: “Do not approve chargers that cannot expose individual events.”
What if charger only says “reduced current”?
Cloud can only infer, not confirm → analytics is degraded.
Procurement: “Do NOT replace JEITA-enabled parts with fixed-temp chargers.”
Cloud shows half-empty packets after brand swap?
Normal if mapping not updated. Different brands expose different fields.
Procurement: “Cloud telemetry mapping must be updated before cross-brand use.”
Edge is on model v1, cloud is on v2 — what now?
Edge marks “pending”, finishes current charge, then switches to v2 and uploads “model_switched”.
Procurement: “Apply-after-charge model update is mandatory.”
Can we use a cheaper charger without NTC fault bits?
No. Cloud cannot reconstruct risks at that moment.
Procurement: “Do not approve chargers that hide safety/NTC fault bits.”
Why sign metering if we already use TLS?
We must prove data wasn’t changed offline; TLS doesn’t protect cached packets.
Procurement: “Signed safety metering is required.”
How to detect replayed charging logs?
Check (ts, seq, device_id, pn); duplicates go to rejected.
Procurement: “Edge must include ts, seq, device_id and pn in every packet.”
We used a non-listed brand once — acceptable?
Cloud should mark “unapproved PN” and request mapper update.
Procurement: “Approved brands: TI, ST, NXP, Renesas, onsemi, Microchip, Melexis.”
Can we skip VBAT / VSYS / VIN to save bytes?
Usually no; cloud needs power-path snapshot to rebuild charge context.
Procurement: “Charger / gauge must expose state + JEITA + key voltages.”
Who must tell cloud that PN changed?
Whoever triggered the substitution (purchasing / field) must tell cloud ops.
Procurement: “Notify cloud ops on every charger/gauge PN change.”