Thermal management software in electric vehicles controls the heating and cooling of the battery, the cabin and other components so that energy is used efficiently and range is preserved. Thermal management testing no longer happens only in the vehicle. It increasingly moves to hardware-in-the-loop systems and to a virtual ECU that runs the thermal management components in isolation, so bugs show up earlier.
Key Takeaways
- Thermal management software in electric vehicles handles up to 200 different system configurations, because it has to balance the battery, the cabin and the available power at the same time.
- Moving tests from the vehicle to a hardware-in-the-loop system cuts costs directly: extreme temperatures such as minus 20 degrees are simulated in the lab instead of sending the team to Scandinavia.
- A virtual ECU lets you test only the thermal management components, without side effects from the basic software, which makes bugs visible even earlier in the release cycle.
- Automated test runs for thermal management functions take two to three days, because temperature control and timer-based preconditioning are physically slow and can’t be sped up at will.
- Before a large language model can generate test specifications, the input requirements have to exist in a structured, machine-readable form, and that is where the real effort lies.
What Thermal Management Has to Do in an Electric Vehicle
Thermal management takes care of everything in an electric car that gets heated or cooled, and thermal management testing has to cover all of it. The software runs on its own control unit (ECU), which controls the temperatures of the battery and the cabin and communicates with other ECUs.
The goal isn’t just to keep things from getting too hot or too cold. The system should also work as energy-efficiently as possible. Cooling a battery system or heating the cabin takes a lot of energy, and every wasted kilowatt-hour comes out of the range.
The complexity comes from the combinations. Speed, outside temperature, the battery’s cooling demand, the cabin’s heating demand and the available power all interact. Altogether, there are around 200 different configurations in which the system can operate.
Why Testing in the Vehicle Isn’t Enough
Tests in a real vehicle are expensive and slow. If you want to test at minus 20 degrees while it’s 20 degrees outside, you have to take the car and a tester somewhere cold. If you want to test cooling in extreme heat, you’re off to Africa.
This is where shift left comes in: test as early as possible, before the vehicle ever has to hit the road. The idea is simple. The earlier you find a bug, the cheaper it is to fix.
Some things can still only be judged in the vehicle. How the air conditioning feels, whether valves switch correctly in thermodynamic terms, whether the bus communication between the ECUs runs cleanly: those belong in the real car. Early testing takes load off the vehicle tests. It doesn’t replace them.
How a Hardware-in-the-Loop System Simulates the Vehicle
A hardware-in-the-loop (HiL) system simulates the vehicle while the real ECU is connected to it. Physically, it’s a cabinet about two meters high and three meters wide, packed with equipment.
The ECU itself is a small box that holds all the intelligence. In the HiL, some of the sensors and actuators are real, such as resistors that provide the values for the temperature sensors, while most are simulated. The system runs in real time, so the ECU behaves as if it were in the car.
That lets you set up scenarios that would be hard to arrange in the vehicle. 40 degrees outside, driving uphill: the system starts regulating and cooling. When vehicle testing comes around later, the basic function is already verified, and only the fine-tuning is left for the test drive.
The Virtual ECU as the Next Shift-Left Step
A virtual ECU moves testing even further forward, because it doesn’t need any hardware at all. Instead of the whole ECU, only the thermal management software is abstracted and run virtually.
The advantage is isolation. A real ECU also carries basic software and other functions that interfere with each other. The virtual ECU tests only the thermal management components and leaves that interference out.
There is a time advantage, too. The basic software often arrives only weeks later, but with short release cycles, the functionality can be tested before then. Bugs become visible earlier, and the HiL is freed up for other work, such as more exploratory testing.
Signals are manipulated at a different point here. Instead of changing bus signals, the tests work at the outermost interface of the virtual ECU, the Runtime Environment (RTE). That is where the battery temperature is set, for example, and the ECU returns its commands for valves or fans through the same interface.
Thermal Management Testing with One Test Case in Two Environments
The same test logic is meant to run on both the HiL and the virtual ECU. At the top level, the test case stays the same. Only the connection to the environment changes.
Take battery cooling as an example. The test case runs on the HiL and on the virtual ECU as well. For the VECU, you adjust the mapping and initialize different tools, but the test case itself doesn’t change. That way, you don’t end up maintaining two separate test suites.
Most of the tests are automated. Pure test run times of two to three days aren’t unusual, because some functions simply take time.
Why Temperature Slows Down Test Design
Temperature is a sluggish phenomenon, and that sluggishness shows up in every test case. A jump from 0 to 30 degrees doesn’t exist in reality. There are only rises and drops over time.
The software accounts for this with filter functions. When a car pulls out of a garage in summer, the outside temperature rises by 10 to 15 degrees almost instantly. On the highway, you drive through pockets of colder air where it’s briefly 5 degrees cooler. If the control system reacted immediately to every jump, it would keep switching back and forth between heating and cooling for no reason.
Compared with an airbag ECU, which has to respond within milliseconds, thermal management is much slower. That shapes the test cases as well.
Preconditioning is a good example. The driver sets a time on their phone: a comfortable car at seven o’clock. The car registers the appointment, all ECUs go to sleep, wake up again later, check the outside temperature and the battery’s state of charge, and work out when to start heating or cooling so the cabin is at 21 degrees on time. In testing, the timers are shortened in simulation so nobody has to wait five hours for the departure time. Some steps, like the ECUs going to sleep, still take their time.
Testing the Function, Not the Controller’s Precision
The tests check whether a function works in principle, not how precisely the controller is tuned. That separation keeps the tests stable and independent of the constant changes to calibration data.
In the vehicle, a lot of recalibration happens to optimize the control. For the functional tests, those calibration details don’t matter. Separate data sets on the HiL keep the side effects of such changes to a minimum.
In practice, that means checking whether the battery gets cooled and whether that works reasonably well. Whether the controller overshoots or undershoots is something you look at in the vehicle, because those details are hard to simulate.
As the project matured, the test cases became more stable. At first, a lot had to be adapted. Today the traceability is much tighter. When a function changes, you don’t just see it in the functional specification, you also see it in the system requirement. That tells you exactly which test cases to check or adapt. If a change has no effect, the test case simply passes again.
Where Test Automation Goes Next
Three areas of work shape how the test strategy develops. All of them aim at testing earlier and with less manual effort.
- Expanding the virtual ECU. The setup is at an early stage, and the first tests are already running. More test cases are to move from the HiL to the VECU.
- Continuous integration. Today, someone still has to flash the software onto the ECU by hand, start the test run and upload the results. In the future, this should happen fully automatically as soon as a software build for testing is checked in.
- Test specifications with an LLM. A large language model is to produce finished test specifications from the requirements instead of people writing them by hand.
With the LLM approach, the real work sits at the input. Before a model can generate useful test specifications, the requirements have to be available in a suitable, structured form. Only that first step makes everything else possible.
In a regulated environment, you can’t accept just any output. The generated output has to be verifiable, and the quality of the input requirements decides whether the generated tests are any good at all.
Frequently Asked Questions
What makes thermal management software in electric vehicles so difficult to test?
The sheer number of combinations. Speed, outside temperature, the battery’s cooling requirements, the interior’s heating requirements, and the availability of power all interact with one another, resulting in approximately 200 different system configurations in which the system can operate. Added to this is the demand for energy efficiency: Every kilowatt-hour unnecessarily consumed during heating or cooling reduces the driving range.
Which aspects of thermal management can only be evaluated on an actual vehicle?
Anything that cannot be meaningfully simulated: how an air conditioning system feels inside the cabin, whether valves switch correctly in thermodynamic terms, and whether bus communication between the control units runs smoothly. Fine-tuning the controller, including overshoot and undershoot, must also be done on the vehicle itself. Early testing reduces the burden on vehicle testing but does not replace it.
What are the advantages of a virtual ECU environment over a hardware in the loop system?
Isolation and time savings. A real ECU contains base software and other functions that introduce interference; in a virtual environment, only the thermal management software is run. Since the base software often doesn’t arrive until weeks later, functionality can be verified in advance during short release cycles. Side effect: The HiL system remains available for more exploratory testing.
Do you need two separate test suites for HiL and the virtual ECU?
No. At the highest level, the test case remains the same; only the interface differs. For the virtual ECU, the mapping is adjusted and other tools are initialized, but the test logic itself remains unchanged. A test case for battery cooling thus runs in both environments without requiring duplicate maintenance effort.
Do functional tests on the test bench also verify the quality of the control system?
No, they verify whether a function works in principle. For example, they check whether the battery is being cooled and whether that works reasonably well. The controller’s overshoots and undershoots are observed on the vehicle. Dedicated data sets on the HiL keep the tests stable, because the calibration data on the vehicle keeps changing.
How do you test time-delayed functions such as the preconditioning of an electric car?
The timers are shortened in simulation during testing so that no one has to wait five hours until the set departure time. Nevertheless, processes such as the ECUs entering sleep mode and waking up take time, as does the actual heating or cooling. Pure test runs lasting two to three days are therefore not uncommon.
Can a large language model generate test specifications from requirements?
Only if the input requirements are already available in a structured, machine-readable format. This very first step is the real work. In the regulated automotive environment, the generated output must also be verifiable. The quality of the generated tests depends on the quality of the requirements, not the model.
