Most thermal modelling projects in automotive spend the majority of their time not solving physics — but configuring it. Setting up geometry representations, mapping cell sensor signals to Simulink ports, assigning material properties, wiring the cooling boundary conditions from CFD into the thermal solver. The same steps, repeated for every new battery variant, every new pack geometry, every new cooling configuration.
The Battery Thermal Model Configurator was built to eliminate that overhead — and to produce something better than what the manual process was generating.
The Problem It Was Solving
At Mercedes-Benz R&D India, the battery thermal modelling workflow involved building coupled Simulink thermal models for high-voltage battery packs. These models had to:
- Represent the thermal mass and conductance of cells, modules, and pack structure accurately
- Incorporate cooling channel behaviour derived from full CFD simulations
- Be directly compatible with the electrical model and the ageing model in the broader simulation framework
- Be audit-ready — traceable, versioned, documentable
Each model took significant engineering time. The cell geometry changes, the module layout changes, the cooling strategy changes — and each change propagated through the entire model setup manually. The process didn’t scale.
The Configurator was the answer.
What It Actually Does
The tool operates as a model generation pipeline — taking structured inputs about the battery geometry, cooling configuration, and cell data, and producing a fully parameterised, coupled Simulink thermal model as output.
The key technical pieces:
Reduced-Order Thermal Model (ROM) of the Battery
Rather than resolving full 3D heat transfer inside the pack (expensive, slow), the tool builds a lumped thermal network: each cell, module wall, and pack structure is a node with thermal mass, and conductance paths connect them based on geometry and contact properties.
The parameters — thermal resistance between cell and cooling plate, between module and pack wall, effective heat capacity of each node — are not assumed. They are computed from geometry and material data using standardised methods implemented inside the Configurator. This is one of the key improvements: generic, formula-driven HTC and thermal property calculations that previously required manual lookup and entry.
CFD Coupling for Cooling Channels
The cooling channel behaviour — flow distribution, local heat transfer coefficients, coolant temperature rise along the channel — comes from CFD simulation results (steady-state or transient, depending on the study). The Configurator reads these results and maps them as boundary conditions into the thermal ROM.
This is the coupling that makes the model high-fidelity despite being a reduced-order representation. The cell thermal behaviour is lumped; the cooling channel behaviour is physics-derived from CFD. The two are connected at the cooling plate interface.
CFD Simulation Results
(flow distribution, HTC, ΔT_coolant)
│
▼
Cooling Boundary Conditions
│
▼
┌──────────────────────────────────┐
│ Lumped Thermal Network │
│ Cell → Module → Pack Structure │
│ (thermal mass + conductances) │
└──────────────────────────────────┘
│
▼
Coupled Simulink Thermal Model
(compatible with electrical + ageing models)
Signal Mapping: Sensors and Simulink Ports
A battery pack in a real vehicle has cell-level temperature sensors at defined locations. The simulation model needs to output signals at those same locations — so that the BMS logic and the validation process work against the same sensor positions.
The Configurator handles automatic mapping of cell sensor signals to Simulink output ports, and input/output port mapping for the full model interface. This was previously done by hand, and it was error-prone at scale. With larger packs (hundreds of cells), manual port mapping is a genuine source of bugs.
Power Loss Architecture
One of the enhancements implemented was a structured power loss hierarchy — from cell-level Joule heating (I²R), through module-level aggregation, to pack-level totals. This replaced a simpler assumption of uniform heat generation and improved model accuracy, particularly for high-rate discharge and fast charging scenarios where cell-to-cell current distribution is uneven.
Outcomes
| Metric | Result |
|---|---|
| Model development time reduction | 60% |
| Workflow standardisation | Consistent process across all pack variants |
| Manual preprocessing errors | Significantly reduced |
| Model compatibility | Direct integration with electrical + ageing models |
| Validation coverage | Multiple scenarios and configurations |
The 60% reduction came from a combination of: automated HTC and property calculations, automatic signal mapping, and the structured generation process replacing ad-hoc manual assembly.
What Made This Hard
The CFD-to-ROM interface. CFD gives you spatially-resolved results; the ROM needs boundary conditions at specific nodes. The mapping between them is not trivial — it requires decisions about how to aggregate distributed heat transfer coefficients into representative lumped values without losing the information that actually matters (local hot spots, flow maldistribution effects).
Sensor mapping at scale. A large HV battery pack can have hundreds of cells and tens of temperature sensors. Getting the Simulink port structure right — and keeping it traceable to the physical sensor layout — required careful architecture of the mapping logic.
Keeping it audit-ready. Internal toolchain at Mercedes-Benz R&D had to pass review. The Configurator output had to be traceable: every parameter, every boundary condition, every mapping had to have a documented source. Building that traceability into the generation process, rather than as a manual annotation step afterwards, was a design constraint that shaped the architecture.
Why This Matters Beyond the Project
The Configurator is an example of a recurring pattern in simulation-heavy engineering: the meta-problem — the problem of building the infrastructure that makes the actual problems faster to solve — is often worth more engineering investment than another incremental improvement to the solver.
A 60% reduction in model development time, compounded across multiple battery programmes and multiple years, is a larger return than almost any accuracy improvement to the model itself. The constraint wasn’t model fidelity. It was throughput.
That instinct — identify where the time actually goes, then engineer a solution to that — has appeared in every subsequent role.