Part 2 – From ML to Silicon: Deploying a System-Level, ML-Based BEV Digital Twin on an Embedded Microcontroller

Part 1 recap: From Physics to ML

In Part 1 – From Physics to Machine Learning: Building a System-Level, ML-Based BEV Digital Twin, we started with a validated high-fidelity, system-level BEV digital twin in GT-SUITE, combining thermal, electrochemical battery, and vehicle dynamics models. Using a structured DOE and GT’s Machine Learning Assistant, we generated training data and developed NARX-based ML metamodels that captured the dynamic behavior of the physics-based system. The result was a system-level ML digital twin that reproduced the key outputs of the original model while running approximately 280 times faster and 1,000 times lighter. But achieving these results on a desktop is only half the challenge. The next step is to determine whether this lightweight model can run in real time on resource-constrained embedded hardware. Let’s dive into it in this part.

From Desktop to Device: Deploying the ML Digital Twin In the Field

A metamodel that is 1,000 times lighter than its parent physics model is lightweight in a relative sense, relative to a workstation. The real test of “light enough” is whether it fits on the kind of memory-constrained microcontroller that actually ships inside a vehicle’s BMS or ECU. That is the second half of this project: taking the GT-generated NARX metamodels and getting them running, live, on a microcontroller.

The Target Hardware

While the ultimate target for this workflow is commercial Battery Management System (BMS) class hardware, the ESP32-WROOM (a dual core, 240 MHz microcontroller with 4 MB of flash and 520 KB of RAM) served as a meaningful stand-in for prototyping: a genuine microcontroller-class target with real flash and RAM constraints, rather than a desktop or server environment. The WiFi link used here stands in for the physical sensor connections a production BMS would ultimately carry, letting the same validation approach translate directly to that context. The goal was to demonstrate that a GT-exported (.cMEX) ML model could run on this hardware with real time wireless communication and headroom left over for future model growth, using Simulink as the bridge between GT-SUITE and the embedded target.

The Deployment Workflow: GT-SUITE, Simulink, and ESP32

Steps to reach from a trained metamodel to running embedded code:
● Export the GT-ML model as a .cMEX file from MLA
● Import and map the model’s inputs and outputs inside a Simulink subsystem
● Configure the target microcontroller (board type, Wi-Fi credentials, communication interface: XCP on Serial, baud rate)
● Run a MATLAB master script that loads drive cycle data, computes the simulation stop time, and hands off cleanly to Simulink
● Use Simulink’s Monitor and Tune mode to run the compiled model live on the ESP32 hardware
● Compare embedded vs. simulation results in the Data Inspector

The live embedded trace tracks the GT-SUITE reference closely across the full highway drive cycle, a strong first proof point that a GT-exported metamodel can run in real time on genuine hardware.

Scaling Up: From a Single Model to the Full Closed-Loop System

The single-model, open-loop deployment (Qm alone) used a modest slice of the ESP32’s resources, comfortably under 10% of both flash and RAM even while streaming a live highway cycle over Wi-Fi. A useful in field digital twin, though, does not run one output in isolation. It needs the full closed-loop system of multiple interdependent NARX/MLP/NeuralODE metamodels, with battery, motor, thermal, and vehicle sub-models feeding each other’s outputs back as inputs, matching the model layout used throughout this project.

Best Practices for a Lean Closed-Loop Deployment

Moving from a single standalone metamodel to a full multi-model, closed-loop system is where embedded memory budgeting really pays off. A few best practices can make significant difference between a comfortable fit and a tight one:
● Treat trained weights as constants. Once a NARX, MLP, or NeuralODE model is trained, its coefficient arrays never change again, so marking them static const lets the compiler place them in flash instead of RAM.
● Reserve RAM for what genuinely changes at runtime. Each model’s cyclic delay buffers, its neuron Outputs array, and its live inner-computation state need to stay mutable and fast to access. Keeping RAM free for these live values, rather than fixed weights, is what lets several models run in the same closed loop.
Applying these practices can significantly improve the system’s Flash and RAM footprint even while running interconnected metamodels live, in real time, on a resource constrained microcontroller.

The underlying principle generalizes well beyond this one project: flash is the natural home for fixed, unchanging weights, cheap to stack up, model after model, while RAM is reserved for the live computation state and NARX history buffers that every running model needs simultaneously. Getting that split right is a large part of what makes a digital twin fit comfortably on embedded hardware.

Full System-Level Results on the ESP32

With these practices in place, all output channels of the closed loop system were compared between the ESP32’s live embedded computation and the GT-SUITE reference simulation over a full highway drive cycle.

The embedded and reference traces sit almost on top of each other across every channel, from the slow thermal drift of battery temperature to the fast, noisy swings of motor power and current, a strong result for a physics-trained NARX metamodel running under real embedded memory constraints.

Machine Learning as an Enabler, not a Replacement

The right solution fidelity depends entirely on where a project sits in the development process. Early on, in vehicle architecture studies and battery architecture and chemistry trade-offs, the full explanatory power of physics-based models is what matters most. Later, in verification, processor-in-the-loop (PIL) testing and full-vehicle XiL validation and control need something that runs fast enough to close the loop in real time.

Machine learning does not replace the physics-based digital twin. It sits in the middle of that V, translating high-fidelity insight into a form that can thrive on a real microcontroller. That is what opens doors that were not previously available: running a validated battery, motor, thermal, and vehicle model live on a BMS-class microcontroller and interacting with real sensor values as inputs to predict quantities which are hard and/or expensive to measure through physical sensors and perform preventive maintenance in low network areas where it’s hard for cloud based digital twin to communicate with. The two approaches are complementary: physics for exploration and ground truth, machine learning for reach, and together they make the in-field digital twin practical. GT’s virtual calibration work on xEV thermal management systems and the IEEE ITEC 2023 paper behind this workflow offer good next stops for readers who want to go deeper, alongside the wider set of write-ups on the GT blog.

Follow our LinkedIn channel to stay updated on the latest advancements in our solutions and subscribe to the GT blog to receive updates on new AI capabilities, engineering solutions, and industry trends or contact us for a live walkthrough.

Frequently Asked Question

1. Can a GT-SUITE ML digital twin really run on a low-cost microcontroller?
Yes. A GT-exported (.cMEX) NARX metamodel was deployed to an ESP32-WROOM (240 MHz dual core, 4 MB flash, 520 KB RAM) using Simulink as the bridge. A single open-loop model (motor heat generation, Qm) used under 10% of both flash and RAM while streaming a live highway drive cycle over Wi-Fi. The embedded output closely matched the GT-SUITE reference.

2. How do you fit a full closed-loop, multi-model digital twin into limited embedded memory?
Split memory by what changes. Mark trained weights as static const so the compiler stores them in flash, and keep RAM for what changes at runtime: delay buffers, neuron output arrays, and live computation state. Applied to the eight-model closed-loop system, this cut RAM usage from 14.8% to 7.9%, and the embedded and GT-SUITE traces still matched across every output channel.

3. Does machine learning replace physics-based digital twins?
No. They are complementary. Physics-based models are best for early work like vehicle architecture and battery chemistry trade-offs, where explanatory power matters most. ML models sit in the middle of the V-diagram, turning that insight into a form fast enough for PIL testing, XiL validation, and real-time use on a BMS-class microcontroller. This also enables in-field prediction of hard-to-measure quantities and preventive maintenance in low-network areas where cloud-based twins can’t connect.