IoT-Based EV Battery Management System Using NXP Microcontrollers & Flutter

Range Anxiety is at the forefront of the conversation surrounding EV's, but Charging Infrastructure is at the forefront of the Policy discussion. For Engineers working on the intersection of Electrochemistry & Embedded Systems neither of those issues are true frontier challenges.

The real problem is this: a lithium-ion battery pack is not a monolithic energy reservoir. It is a community of individual electrochemical cells, each aging at a slightly different rate, and each responding differently to temperature gradients across the pack, each carrying a subtly different internal resistance profile that shifts with every charge cycle.

Treat them identically as every naive BMS does and the weakest cell in the pack becomes the constraint on the entire system.

The weakest cell's ceiling is the charging point of battery packs. The lowest point in the weakest cell is where battery packs discharge their usable power. As a result, battery packs are no longer able to be used to their total capacity because the individual battery cells do not all wear out at the same speed.

A smart EV Battery Management and Optimization System (SEBMOS), was designed so that there are no assumptions made about battery pack performance, only actual measured performance for each individual cell and also provide immediate visibility to those measurements through cell level and continuous real-time monitoring.

The requirements are specific and unforgiving: precision analog front-end capability, functional safety compliance to at least ASIL-B for fault detection, reliable operation across the full automotive temperature envelope, and a hardware security architecture that protects calibration data and state-of-health models from tampering.

This integrated circuit provides the hardware foundation for the NXP MC33772C battery cell controller IC. This device was specifically designed for this application.

It measures the voltage of six battery cells with 16-bit ADC resolution, where each battery cell will be monitored at the same time and will provide a measurement of the battery cell voltages with ±1.5mV accuracy at all operating conditions. In addition, the integrated circuit directly integrates cell balancing drive circuitry into the IC design.

Daisy-chain SPI communication architecture allows multiple MC33772C devices to be cascaded across a large pack without multiplying the MCU's communication interface requirements, a scalability characteristic that directly influenced the decision.

The NXP S32K344 is the system MCU responsible for coordinating all cell controller data acquisition, managing thermal management, executing the charge/discharge state machines, and managing cloud communication.

Additionally, it has an ASIL-D capable design ecosystem, which provides the safety architecture foundation necessary to meet automotive/industrial energy storage certification requirements.

The choice of a single-vendor stack between the cell controller and system MCU was deliberate: NXP's application-layer software examples and reference designs for the MC33772C and S32K series significantly compress bring-up time on a hardware design that has no margin for ambiguity at the analog-digital boundary.

In this prototype being implemented, battery pack architecture is design with a configuration of 96S4P lithium NMC (nickel manganese cobalt) to be constructed with 96 cells in series within 4 strings of cells in parallel. This design produces a nominal value for the pack voltage of 355 volts while producing a nominal value of 75 kilowatt hours. These values are typical for medium-range BEV applications.

Sixteen MC33772C cell controller ICs are distributed across the pack in groups of six series cells each, daisy-chained on an isolated SPI bus that traverses the full pack voltage stack through digital isolators at each chain boundary.

A distribution of NTC sensors is used to monitor temperature. Thirty-two sensors are positioned throughout the pack enclosure based on the results of thermal modelling, with the sensor density being highest in the centre of the pack where thermal gradients will be the steepest.

The NTC outputs are multiplexed through an ADC expander network and read by the MC33772C's auxiliary ADC channels, co-locating cell voltage and temperature measurement on the same hardware acquisition cycle to eliminate temporal offset between correlated datasets.

To ensure electrical accuracy over thousands of cycles, the passive balancing architecture has been designed with precision balance resistors with a tolerance of 0.1%, which is much more precise than standard tolerances for this type of application. These balance resistors support accurate balancing current calculations, which provide an essential part of a reliable and even distribution of charge within the cells.

Active balancing was evaluated and deferred for the prototype phase: the added circuit complexity of switched-inductor or capacitor-based active balancers was judged to carry unacceptable validation risk for a first hardware revision, with passive balancing delivering adequate cycle-life improvement at the cell voltage matching precision the MC33772C provides.

The BMS PCB operates in an environment that severely punishes "low effort" designs. High voltage (pack positive to pack negative) is 403V fully charged and shares space within the same physical enclosure of a low voltage (MCU) of 3.3 volts (V) and 5 volts (V).

Creepage and clearance distances are specified per IEC 60664-1 for pollution degree 2, overvoltage category III. Reinforced insulation boundaries separate high and low voltage zones on the PCB with a minimum 8mm clearance enforced in layout and verified in Altium Designer's DRC rules.

The board is a six-layer design. The two internal planes serve as dedicated ground and power pour layers. Signal routing on outer layers keeps analog acquisition traces away from switching node traces, the gate driver outputs for contactor control carry high dV/dt edges that couple aggressively into adjacent traces if routing discipline is not enforced explicitly in the constraint manager.

In order to prevent corrosion of PCB solder joints, we must conformally coat (using Humiseal 1B31 acrylic) all assemblies after the reflow process. Assemblies post-reflow will encounter condensation, gas outgassing from the cell chemistry, and mechanical vibration issues during transport and use over the countless years before service is completed.

The NXP EdgeLock SE050 stores the cell calibration coefficients and state-of-health model parameters generated during pack commissioning.

Protecting this data from modification is not paranoia, a tampered calibration dataset could cause the BMS to permit charge or discharge conditions that accelerate cell degradation or create thermal runaway preconditions. Hardware-rooted protection of calibration data is a safety requirement, not a product feature.

Through the implementation of a dual execution context within FreeRTOS on the S32K344, firmware architecture creates a separation between functionality that is safety critical with respect to the optimisation and communication functions.

The safety tasks such as overvoltage protection, undervoltage protection, overcurrent detection, contactor control and thermal runaway detection will execute at a higher priority than the optimise and communication tasks with deterministic timing and will have a separate watchdog monitor.

Optimization and communication tasks execute at lower priority and are suspended rather than terminated if safety task execution demand increases.

The State of Charge (SOC) estimation algorithm uses a combined coulomb counting and extended Kalman filter approach. Raw coulomb counting from the Allegro ACS780 pack current sensor provides the primary SOC estimate.

The Kalman filter fuses this with cell voltage measurements and a parameterized equivalent circuit model of the NMC cell chemistry to correct for coulomb counting drift, a systematic error that accumulates over hundreds of cycles if uncorrected.

The State of Health (SOH) computation runs on a longer timescale, updated at the conclusion of each full charge cycle.

It compares measured full-charge capacity against the factory-calibrated nominal capacity, tracks internal resistance evolution using electrochemical impedance spectroscopy approximations performed during relaxation periods, and produces a capacity retention percentage and predicted remaining useful life estimate in charge cycles.

You can see how optimization takes shape in the thermal balancing algorithm. As a result of charging or sustained high power discharging (which typically causes a temperature difference between the cells), the distributed NTC will report back a thermal gradient across the pack.

After receiving this information, the firmware will adjust the balancing duty cycle for each cell group to give preference to discharging thermal energy from the cell group(s) that are at a higher temperature than the rest.

It also sends charge rate reduction commands to the charging system via CAN when thermal margins narrow, accepting a modest increase in charge time in exchange for measurable reductions in thermal stress accumulation.

Three communication interfaces are controlled by the S32K344 simultaneously. The BMS is able to connect via CAN FD with the vehicle's powertrain control network, allowing for communication regarding SOC, SOH, available power, and fault status to occur at intervals of 10ms per standard integration requirements for BEVs; providing an accurate and timely reporting mechanism to the vehicle ECU.

A local UART interface provides a commissioning and diagnostics port for service tooling. The Quectel BG95-M3 LTE-M module provides the cloud uplink path.

MQTT over TLS 1.2 handles telemetry publication. Each device publishes to structured topic namespaces: cell-level voltage and temperature data at 1-minute intervals during active operation, SOC and SOH updates at charge cycle boundaries, alarm events immediately upon detection, and thermal event records with full pack state snapshots for post-event analysis.

The Django backend built with Django REST Framework on AWS ECS, receives telemetry through AWS IoT Core acting as the managed MQTT broker. Ingested data writes to TimescaleDB for time-series storage, with InfluxDB retained for the high-frequency cell voltage streams that demand write throughput beyond PostgreSQL's practical limits at this sampling rate.

An ML inference service hosted with Django running a GBRT model, trained on datasets of cell degradation, is processing all SOH updates for each completed charge cycle and producing an estimate of how many more cycles a battery will be able to provide power before reaching the industry-established threshold of 80% capacity retention (i.e., the point at which the battery is considered to have reached its end-of-life for automotive applications).

This prediction is served to the Flutter application and, in fleet configurations, to the operator's asset management API.

Celery manages asynchronous backend workloads: daily pack health summary generation, thermal event escalation notifications, predictive maintenance alert dispatch, and the weekly lifespan report delivered to registered users via push notification.

The BLoC architectural pattern is utilized within the Flutter app, with a clean separation between data, domain, and presentation layers. One of the major design constraints faced by the Flutter app team was to take very technical battery electrochemistry data and develop two personas for the application to support, an EV owner who requires a meaningful summary of information and a fleet technical manager who needs detailed information at the cell level.

The solution is a layered disclosure interface. The home screen presents three numbers: current SOC as a percentage with confidence interval, current SOH as a capacity retention percentage, and predicted remaining life in charge cycles rendered as an estimated calendar date at current usage rate.

When tapping on an item, you will receive more information about its underlying data; for example, you can get to know how many cells were used in your SOC (State of Charge) voltage heatmap, capacity curve for SOH (State of Health) and degradation trend chart to predict Lifespan.

Regarding the Cell Voltage Heatmap specifically, you can see the complete 96-cell pack presented as a colour-coded grid: green = Cells within ±5mV, Amber = Cells within ±15mV, Red = Cells > ±15mV relative to the Pack Mean.

A fleet manager reviewing fifty packs can identify a cell imbalance developing in a specific pack in under three seconds. This visualization was the most requested feature in user testing and the clearest demonstration that cell-level measurement produces insights unavailable from pack-level monitoring.

Charge session monitoring uses a WebSocket connection to the Django Channels backend for real-time SOC and thermal status during active charging updating at 5-second intervals with thermal gradient visualization and estimated time-to-full at current charge rate.

For validation of hardware, the Chroma 17020 Battery Pack Simulator was used to inject precise cell voltage and temperature profiles for testing during bring-up without having to use physical cell arrays, a required practicality because the operating voltage of the hardware under test is at pack voltages, thus requiring testing in a control environment.

The most significant engineering challenge was achieving accurate SOH estimation across the full operating temperature range.

Cell equivalent circuit model parameters are strongly temperature-dependent, and a model parameterized at 25°C produces meaningful SOH errors at −10°C winter operating conditions. Resolution required temperature-indexed model parameter tables, increasing flash storage requirements but eliminating the seasonal SOH estimate drift observed in initial testing.

The architecture scales from single vehicle BMS to grid level energy storage management without fundamental redesigning. Extended MC33772C daisy chain length to support larger pack configurations.

The Django backend handles fleet-scale telemetry with a device-partitioned TimescaleDB schema, utilizing hypertable partitioning and read replica deployment. The ML lifespan prediction model becomes more intelligent with a larger fleet dataset – a compounding intelligence advantage that grows with scale of deployment.

The SEBMOS prototype establishes that cell-level intelligence, delivered through purpose-built NXP silicon, a principled firmware architecture, and a cloud-native Django backend, is not a research-grade aspiration. It is an engineerable, deployable, scalable product reality.