123 Main Street, New York, NY 10001

← 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.

Scope: Charging-domain edge–cloud analytics Left: charger, gauge/AFE, NTC. Middle: Edge gateway (sign+buffer). Right: Cloud analytics (charging). Below-right: other BMS pages (not in this page). Charger IC (TI / ST / onsemi / Microchip …) Gauge / AFE Temp / NTC Edge Gateway / MCU sign + buffer Cloud analytics (charging domain) Other BMS pages not in this page
Figure: Charging-domain scope — telemetry from charger/gauge/NTC → edge (sign+buffer) → cloud analytics. Other BMS topics are intentionally excluded.

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.

Edge telemetry frame — required charging fields Six horizontal lanes inside an edge telemetry frame: charge_state, jeita_zone, ichg_set/real, vbat/vsys/vin, event_code, device_id (PN). Edge telemetry frame (charging) different vendors → mapped later charge_state jeita_zone ichg_set / ichg_real vbat / vsys / vin event_code device_id (PN / brand / lot) from charger IC from gauge / AFE from temp / NTC
Figure: Required charging telemetry — state, JEITA, Ichg set/real, VBAT/VSYS/VIN, event code, and device identity (PN).

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).

Uplink priority for charging-domain telemetry

P0 — safety events

over-temp, NTC fault, safety timer → upload immediately

P1 — charge state changes

precharge → CC → CV → terminate → recharge

P2 — JEITA zone changes

cold / cool / normal / warm / hot transitions

P3 — periodic health packet

battery summary for cloud analytics

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.

Edge telemetry uplink scheduling Event-driven lines go into an ordered edge buffer; periodic upload pushes data to the cloud ingest endpoint. Temp ↑ → JEITA Charge state Safety timer Edge buffer (ring, ordered) stores last N charging events Cloud endpoint (ingest, order, analyze) periodic upload
Figure: Event-driven (safety) and periodic (analytics) telemetry both enter an ordered edge buffer, then are uploaded to the cloud on schedule.

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.

Signed safety metering payload Payload split into header (ts, seq, device_id), charging context (state, JEITA, Ichg), metering (Wh/mAh), and signature section (MAC), signed at edge. Header ts, seq, device_id Charging context state, JEITA, Ichg Metering Wh / mAh in Signature (MAC) signed at edge Signed safety metering payload for charging-related analytics
Figure: Header (ts, seq, device_id) + charging context (state, JEITA, Ichg) + metering (Wh/mAh) + signature block (MAC), signed at the edge.

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.

Cloud analytics and model update loop Edge devices send charging telemetry, cloud detects abnormal warm patterns, creates model v2 / new JEITA, and pushes it back to edge to apply on next charge. Edge device current model v1 charging-domain telemetry only Cloud analytics converge, visualize, detect telemetry schema mapping (multi-brand) Cloud model v2 updated JEITA / thresholds apply on next charge telemetry uplink model / JEITA update apply-after-charge & upload “model_switched”
Figure: Cloud detects abnormal charging patterns and pushes updated JEITA or safety thresholds back to edge devices; edge applies only after the current charge finishes.

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.

Cloud-side telemetry mapper for cross-brand chargers Different charger IC payloads (TI, Microchip, onsemi) are normalized by a cloud telemetry mapper into a single charging analytics schema. TI payload JEITA, events, PN Microchip payload simple states onsemi payload verify granularity Telemetry Mapper (cloud) map vendor payloads → normalized raise alert on mixed lots Charging analytics schema state, JEITA, Ichg, VBAT, events, PN usable by other BMS pages
Figure: Cloud-side telemetry mapper unifies payloads from TI, Microchip and onsemi chargers into one charging analytics schema for the BMS domain.

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)

TI BQ25895RTWR ST STC3115IJT / STC3117 NXP MC33772C Renesas ISL9238HRTZ-T7A onsemi NCP1855 Microchip MCP73871-2AAI/ML Melexis MLX91231
Edge-to-cloud anti-tamper validation flow Edge generates signed payload, potential tamper/replay is intercepted, cloud validator checks timestamp, sequence, PN and signature, then routes to analytics or rejected. Edge device ts + seq + device_id + pn charging_ctx + sig signed at edge uplink tamper / replay attempt Cloud validator check ts + seq + sig + pn if missing → reject Analytics charging-domain only Rejected / audit replay / tamper / unapproved PN valid invalid / replay
Figure: Anti-tamper flow validating timestamp, sequence, PN and signature before admitting charging telemetry to cloud analytics.

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)

TI BQ25895RTWR ST STC3115IJT / STC3117 NXP MC33772C Renesas ISL9238HRTZ-T7A onsemi NCP1855 Microchip MCP73871-2AAI/ML Melexis MLX91231
Charging telemetry validation steps Four-step validation flow: lab charge, edge buffer (offline), cloud log, validation report for field ops. 1) Lab charge BQ25895 + STC3115 + MLX91231 2) Edge buffer offline capture signed events 3) Cloud log check ts+seq order check missing JEITA 4) Report daily JEITA-miss weekly sig-gaps
Figure: Validation flow to confirm charging telemetry, buffering and cloud ingestion all work before field rollout.

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.

TI BQ25895RTWR / BQ25890 ST STC3115IJT / STC3117 NXP MC33772C Renesas ISL9238HRTZ-T7A onsemi NCP1855 / NCP1860 Microchip MCP73871-2AAI/ML Melexis MLX91231

Request a Quote

Accepted Formats

pdf, csv, xls, xlsx, zip

Attachment

Drag & drop files here or use the button below.

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.”