Thermal management software in electric vehicles controls the heating and cooling of the battery, interior and other components in such a way that energy is used efficiently and the range is maintained. Testing is not carried out in the vehicle, but increasingly on the hardware in the loop system and on a virtual control unit environment that only maps the thermal management components in isolation and thus enables earlier fault detection.
Key Takeaways
- Thermal management software in electric vehicles regulates up to 200 different system circuits because the battery, interior and availability of power have to be taken into account simultaneously.
- The shift from vehicle testing to hardware in the loop directly reduces costs because extreme temperatures such as minus 20 degrees are simulated in the laboratory instead of sending the team to Scandinavia.
- A virtual ECU environment allows only the thermal management components to be tested without basic software cross-influences, which makes errors 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 processes are physically slow and cannot be accelerated at will.
- Before a large-language model can generate test specifications, the input requirements must be available in a structured, machine-readable form, which is the actual effort involved.
What thermal management must achieve in electric vehicles
Thermal management regulates everything that is heated and cooled in an electric car. The software for this is located on a separate control unit that controls the temperatures of the battery and interior and communicates with other control units.
The aim is not just to ensure that it doesn’t get too hot or too cold. The system should work as energy-efficiently as possible. Cooling a battery system or heating the interior requires a lot of energy, and every kilowatt hour wasted is detrimental to the range.
The complexity arises from the combinatorics. Speed, outside temperature, the cooling requirements of the battery, the heating requirements of the interior and the available power all interact. In total, there are around 200 different circuits in which the system can be operated.
Why tests on the vehicle alone are not enough
Tests on real vehicles 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 to a cold place. If you want to test cooling in the heat, you have to go to Africa.
This is exactly where the shift left approach comes in: testing as early as possible before the vehicle even has to hit the road. The basic idea is simple. The earlier a fault is found, the cheaper it is to rectify.
Nevertheless, certain properties can only be assessed on the vehicle. How an air conditioning system feels, whether valves are thermodynamically correctly connected, whether the bus communication between the control units runs smoothly: such things belong on the real car. The early phase takes the pressure off these vehicle tests, it does not 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 control unit is connected. Physically, this is a cabinet about two meters high and three meters wide full of technology.
The control unit itself is a small box containing all the intelligence. Some of the sensors and actuators are actually installed in the HiL, such as resistance values for the temperature sensors, while the majority are simulated. The system runs in real time so that the control unit behaves as if it were in the car.
This allows scenarios to be set that would be complex to set up in the vehicle. 40 degrees outside temperature, driving uphill: the system starts to regulate and cool. If the vehicle is to be tested later, the basic function is secured and only the fine adjustment remains on site.
The virtual ECU as the next shift left step
The virtual ECU shifts testing even further forward because it does not require any hardware at all. Instead of the entire control unit, only the thermal management software is abstracted and operated virtually.
The advantage lies in the isolation. Basic software and other functions that generate cross-influences are located on a real control unit. The virtual ECU only tests the thermal management components and suppresses these faults.
There is also the time advantage. The basic software only arrives weeks later, but with short release cycles, the functionality can be tested beforehand. Errors become visible earlier and the HiL is freed up for other, more exploratory testing, for example.
The signals are manipulated at a different point here. Instead of changing bus signals, the tests attack the outermost interface of the virtual ECU, the Real-Time Environment (RTE). This is where the battery temperature is set, for example, and the control unit returns its control for valves or fans via the same interface.
One test case, two environments
The same test logic should run on HiL and virtual ECU. At the top level, the test case remains the same, only the connection changes.
Using battery cooling as an example, this means that the test case can be used on the HiL and also on the virtual ECU. The mapping is adapted for the VECU and other tools are initialized, but the actual test case remains the same. This means that there is no duplication of maintenance effort for two separate test suites.
The majority of tests are automated. Pure test runtimes of two to three days are not uncommon because some functions simply need time.
Why temperature slows down the test design
Temperature is an inertial phenomenon, and this inertia is inherent in every test case. A jump from 0 to 30 degrees does not exist in reality, there are only rises and falls over time.
The software takes this into account with filter functions. If a car drives out of the garage in summer, the outside temperature suddenly rises by 10 to 15 degrees. There are holes in the air on the highway where it is briefly 5 degrees colder. If the control system reacted immediately to every jump, it would switch pointlessly between heating and cooling.
Compared to an airbag control unit, which has to react in milliseconds, thermal management is much slower. This also characterizes the test cases.
A good example is preconditioning. The driver sets on his cell phone that he wants a temperature-controlled car at seven o’clock. The car registers the appointment, all the control units go to sleep, start up again later, check the outside temperature and battery charge status and calculate when they need to start heating or cooling in order to reach 21 degrees in the interior on time. In testing, the timers are simulated down so that nobody has to wait five hours to leave. Some processes, such as the control units going to sleep, still take time.
Testing function, not controller quality
The tests check whether a function works in principle, not how precisely the controller tunes. This separation keeps the tests stable and independent of constant data status changes.
A lot of re-dating is carried out on the vehicle in order to optimize the control system. For the function tests, this data is of no interest in detail. Separate data sets on the HiL minimize the cross-influences from such changes.
In concrete terms, this means testing whether the battery is cooled and whether this works reasonably well. Whether the controller shows overshoots and undershoots is checked on the vehicle, because such subtleties are not easy to simulate.
As the project has matured, the test cases have become more stable. In the beginning, a lot had to be adapted, but today the linking is tighter. If a function changes, you can see this not only in the functional specifications, but also in the system requirements. This shows which test cases need to be checked or adapted. If a change has no effect, the test case simply runs through again in green.
Where the automation goes next
Three building blocks characterize the further development of the test strategy. They are all aimed at testing earlier and with less manual work.
- **Expanding the virtual ECU ** The setup is just beginning and the first tests are already underway. Further test cases are to migrate from HiL to the VECU.
- **Continuous integration: Today, the software still has to be flashed manually onto the ECU, the test run started and the results uploaded. In future, this will be fully automated as soon as the software to be tested is stored.
- **Test specifications with LLM ** A large language model is to be used to create finished test specifications from the requirements instead of writing them manually.
With the LLM approach, the actual work is done at the input. Before a model can generate meaningful test specifications, the requirements must be available in a suitable, structured form. Only this first step makes everything else possible.
In a regulated environment, not just any output can be accepted. The generated output must be testable, and the quality of the input requirements determines whether the generated tests are any good at all.
