IODP Success Stories
IODP Success Stories
IODP Success Stories
Driveability of virtual vehicles
Can transient vehicle models written in software be used to measure driveability on an engine testbed?
A Japanese OEM does it with Model.CONNECT™.
Engineers at a Japanese OEM have investigated a co-simulation environment that can run proprietary vehicle models to build a virtual vehicle on an engine testbed.
The OEM approached AVL with the idea of developing a testing methodology that would accelerate the front-loading of the vehicle development process. The question they were asking themselves was: How could driveability tests, normally executed on the road with real vehicles, be run on an engine testbed with a virtual vehicle?
Why run driveability tests in the laboratory?
The goal was to reduce the time required to obtain a vehicle and instrument it for testing purposes. By moving as much of such transient response testing into the virtual world as possible, not only would fewer prototype vehicles be required, but making key insights into driveability issues available at an earlier stage would also shorten the development process.
So what was the first step?
In the organization, engineers had already generated models describing transient vehicle behavior, but they needed realistic torque excitation. In a pure office environment, the torque excitation would be provided by an engine model, itself excited by the actions of a driver following a vehicle speed profile such as an emissions cycle, or a specific set of driveability-relevant maneuvers. The first step to validate the use of the company’s own vehicle and powertrain models for driveability testing would be to use a real engine and have the virtual driver drive the real engine in a virtual vehicle while following a series of virtual driving maneuvers.
What is the key enabler for this to happen?
The first step was to determine whether the transient models developed in-house could be run in a co-simulation in a testbed environment. This required AVL’s co-simulation technology Model.CONNECT™, that provided access to realtime data and control parameters. This co-simulation platform permits models from different domains, vendors and frequencies to be interconnected and run in a realtime environment.
In contrast to other solutions that run by controlling the engine speed with the dynamometer and torque via the throttle pedal, the AVL solution uses a vehicle model to accurately predict the torque present on the engine’s flywheel, or transmission output shaft (depending on the required configuration) and uses the dynamometer in torque control mode.
This requires highly responsive torque control by low-inertia dyno, accurate and realtime torque calculation and a stiff drive shaft connection between the engine and the dyno. Without these three things, the system would be extremely difficult to control and certainly incapable of recreating the events required to emulate driveability-relevant situations.
And the results?
Model.CONNECT™ was used as a platform for models, defining the behavior of the powertrain including the transmission control unit (TCU) and the torque rate limiter function, which was then coupled to an engine testbed. The system was then excited by a series of driving maneuvers that the simulated driver converted into throttle movement and gearshift events.
The Japanese OEM was able to incorporate the behavior of their vehicles and the corresponding transmission control functions into an engine testbed environment.
Virtual cooling systems
Can thermal management systems for a hybrid vehicle be developed … without the vehicle?
AVL set up a virtual cooling system for a hybrid vehicle; tested and developed on an engine testbed.
Designing and subsequently testing cooling systems for hybrid vehicles requires a hybrid vehicle as a test platform. And if the cooling system needs to be de-rated and optimised for a range of vehicles, then waiting for all the vehicle variants to be available as test platforms becomes untenable.
But surely vehicle simulation is easy nowadays?
There are other factors behind the push to move thermal management development into the laboratory, such as the practical impossibility of running at Vmax, the availability of drivers, the time required to install equipment in a vehicle, and of course the issue of variable ambient conditions. But these too can be simulated.
So why can’t thermal system development work be moved into the laboratory?
Unfortunately, the tools used to simulate various aspects of hybrid vehicles and their cooling systems are all from different vendors and many have different simulation domains. To make things worse, some of these models are optimised for realtime applications and others are computationally complex and hence time intensive. And they all need to be connected. Even if they could be connected as a co-simulation, moving thermomanagement work into the laboratory would also require interfaces to connect this environment to highly responsive testbed temperature controllers to emulate real-world conditions in realtime on an engine testbed.
But it has been done.
AVL and partners were able to connect the vehicle test boundary conditions to models in a co-simulation environment including a simulation of the hybrid vehicle and the models simulating the thermomanagement system. The complete environment was then connected to a physical engine testbed permitting the vehicle tests to be run.
High-performance media conditioning systems on the engine testbed applied the conditions prescribed by the models to the engine’s coolant return line.
This frontloading of design work to the engine testbed by applying co-simulation in the form of Model.CONNECT™ enabled developers to design and test the performance and de-rating strategies of thermomanagement systems for a range of hybrid vehicles. Without the vehicles.
De-rating strategies in the virtual world
Is using a racetrack the best way to determine the optimum de-rating strategy for high-performance vehicles?
AVL worked on a project involving high-performance hybrid vehicles. The e-motors in such vehicles provide the instantaneous additional boost for acceleration at critical moments.
But what happens if the electric motor has reached its thermal limit and must be temporarily de-rated - but the driver is in a situation where he is about to rely on the expected (and previously available) torque?
What does de-rating mean and why do I need it?
Combustion engines are deliberately tested to ensure that they can withstand hundreds of hours of operation at maximum power. However, electric motors can also be operated for short periods of time in overload conditions, thus squeezing even more phenomenal acceleration out of the powertrain. But, there is always a limit, even for electric motors. The coil end temperature must be controlled as closely as possible to the limiting temperature and once this temperature has been exceeded, the motor must be de-rated to permit the temperature of the coil to fall and prevent damage.
Would this de-rating affect the driver?
It would if it were to happen unpredictably. That is the point. It cannot be allowed to happen. This means that engineers need to test the complete powertrain under real conditions to determine the optimum cooling strategy and be able to guarantee predictable torque for the driver.
So how can you make the unpredictable predictable?
The only way is to put the vehicle through its paces as a real driver would. Either on a real test track, although this would require complex instrumentation and telemetry, along with good weather. An alternative would be to emulate these demanding conditions in the laboratory, with parts of the vehicle being physically present and the test track and driver being simulated.
Designing de-rating strategies in the lab …
Thanks to Model.CONNECT™, it is now possible to run high-performance powertrains in virtual vehicles in simulated driving conditions while simultaneously monitoring and optimizing the de-rating and cooling strategies.
Thus, it is now possible to provide high-performance hybrid vehicles with a performance that is responsive – and predictable.
Manage your flash sets
Who can tell me with certainty which datasets are flashed in this hybrid vehicle?
AVL can answer the question in seconds with the Flashset Manager.
Actually, there are at least two questions that are typically asked. The first is the one mentioned above, and the other is “are these datasets mature on a product level?”.
When engine calibrators hand over their datasets to their clients, they will state, “engineering targets achieved under normal conditions”. The transmission calibrators say the same thing. The battery control unit teams ditto. Do they mean that all calibration datasets have been tested on their own, as stand-alone calibrations, or together as a system in a hybrid vehicle?
Should we be thinking on a product level?
OEMs have had this problem for a long time. And solved it with Excel lists. Then along came the hybrid vehicle and threw the calibration teams into iterative loops of inter-departmental communication. Teams should be thinking in terms of calibration dataset maturity on a product, i.e. on a vehicle level.
Attributes such as driveability, fuel consumption, emissions and OBD are really only meaningful on a product level, particularly for hybrids. All elements in a calibration must be checked against each other: In a hybrid, this means the controller calibrations for the combustion engine, the e-motor, and the battery cannot be done independently and separately from each other.
So how can datasets be connected on a product level?
On the day of dataset delivery to the client, the hybrid vehicle datasets are delivered to the client as a system of interconnected calibrations. The maturity of the calibrations (plural!) needs to be tracked, but not in Excel lists, as these are prone to typos, overwriting and versioning errors.
So how do I know for sure which datasets are flashed on my vehicle?
The Flashset Manager software created by AVL’s calibrators addresses this question and is a database solution with administration right management. It now takes just seconds, not days of searching through Excel lists, to determine the exact combination of hex and A2L files flashed in the hybrid vehicle.