How should a battery management platform be developed?
Separate the battery-side BMS from the cloud platform. The BMS measures voltage, temperature, and current and performs local safety protection. The platform connects devices, monitors status, manages alerts, analyzes history, and supports operations. Begin with one real protocol, one hardware model, and one alert-to-resolution loop. Networked software must never replace millisecond local protection.
Network and cloud services can be delayed or unavailable, so overvoltage, undervoltage, overcurrent, and overtemperature protection belongs in hardware and control design. Cloud software can show trends, distribute an approved policy, and support human action, while high-risk remote control is not an ordinary UI button. Wavesteam's public BMS platform case shows a relevant product form, but target scale, latency, and safety require new evidence.
| Architecture | Suitable context | Advantage | Risk and cost |
|---|---|---|---|
| One protocol directly to business backend | One model, small proof | Short path and lower first cost | Protocol/business coupling and poor multi-model maintenance |
| Protocol adapters plus IoT platform | Multiple models, production operation, alerts and OTA | Unified identity, device model, message, permission | Continuing version and capacity work |
| Edge gateway plus cloud | Weak network, several field buses, local autonomy | Translates CAN/serial and operates offline | Additional gateway hardware, certificates, versions, field support |
| Local monitoring only | Closed site or no-cloud requirement | Clear data boundary and little WAN dependency | Limited cross-site analysis and remote operation |
A formal product often benefits from an adapter layer without building a large IoT platform immediately. Start thin when protocols are few and stable; separate identity, device shadow, routing, OTA, and rules as vendors, firmware, tenants, and operating requirements grow.
When separating device, connectivity, and platform responsibilities, also compare How should a remote device monitoring platform and mini-program be developed? and How should a smart pet collar app be developed?; the linked guidance adds context that should be considered in the same decision.
Turn telemetry into a closed incident record
Messages need device identity, protocol and firmware version, collection time, sequence, measurements, state flags, and quality indicators. Ingestion authenticates, decodes, deduplicates, orders, and corrects time. Hot data supports current status, time series support trends, and raw frames are retained only for justified diagnostics or audit. Alert rules are versioned by model, batch, and operating condition with threshold, duration, recovery, suppression, and owner, producing trigger–notification–acknowledgement–action–recovery–review.
Local sampling and cloud reporting are different. Ten thousand devices reporting once a second create about 315.36 billion messages per year before per-cell values. Use events, aggregation, change thresholds, and storage tiers. An anomaly can raise frequency and preserve a before/after window; stable operation reports summaries. Diagnostic need, safety, and cost determine the strategy.
Treat remote control as a physical-risk operation
Parameter changes, current limits, contactors, and firmware updates need hardware support, hazard analysis, and relevant standards. Use separate authorization, dual or secondary confirmation where appropriate, current-state interlocks, short-lived signatures, replay protection, complete audit, and a fail-safe device state. “Command sent” is not “executed”; require device acknowledgement and final-state verification, and let local interlocks reject unsafe commands.
Vehicle rechargeable energy storage can draw on ISO 6469-1:2019, while functional safety, cybersecurity, and vehicle law may also apply. Stationary storage, two-wheelers, swap cabinets, and consumer products have different standards. MQTT 5.0 can structure messaging but does not replace device identity, key management, signed firmware, and vulnerability response.
The client provides the frozen protocol, units/scales and flags, firmware, real samples, network, scale forecast, alert owners, and prohibited controls. Wavesteam delivers registration, current state, trends, basic alerts, work orders, audit, adapters, rule versions, monitoring, deployment, and client-controlled accounts. SOH or remaining-life prediction is not assumed without calibrated capacity, cycle/condition data, and verifiable labels.
Acceptance covers normal and threshold jitter, sensor error, lost/duplicate/out-of-order messages, offline backfill, restart, clock drift, bulk onboarding, alert storms, authorization bypass, and failed upgrades. We report online and message completeness, P95 delay, alert discovery and acknowledgement, false results, storage cost, command acknowledgement, and recovery. Battery, hardware, functional-safety, operations, and software specialists jointly review the final boundary.