Simulation and modelling: Staying in the loop
Advances in the integration of control systems and vehicle models as well as the virtual driving environment are three reasons why driver-in-the-loop simulators should be an essential part of dynamic vehicle testing, according to Maarten van Donselaar
Simulators are increasingly understood by automotive engineers as an alternative to expensive and time-consuming prototype building. Yet, the argument for making the step from desk-top simulation to driver-in-the-loop simulation, in many cases, still needs to be won.
A simulator’s value goes way beyond its ability to give vehicle dynamics analysts repeatable, controllable feedback of the feel of their models. Simulators can contribute to components and systems development in steering, ride and handling, tyres, HMI and ergonomic assessment, problem investigation, software debugging, competitor assessment, and benchmarking and engineer training. Their use as a day-to-day engineering tool is not just limited to the OEM; tier one suppliers and anyone responsible for the programming behind control systems need to use simulators.
But there is much more to simulators than assessment by engineers for engineering. What about the real customer – anyone from a racing driver to a 17-year-old learner – and real life situations? After vehicle models and control algorithms have been open-loop validated and tested, a human driver should be introduced to close the control loop.
We need his or her realistic response to, for instance, an emergency situation and to monitor how that interferes with overall stability. We need to conduct objective-subjective assessments such as “how well does the car absorb bumps”, “how does that correlate to design parameters” and “how comfortable is that interaction perceived to be”. Humans can help but also counteract the most perfectly engineered control strategy, so we need to know how they behave.
This is both expensive and dangerous in a prototype vehicle and it cannot be done behind a desk with a Logitech steering wheel. A simulator will offer an environment that may not be 100% realistic (that is not the aim), but realistic enough that the triggers are the same as in real world driving so the driver responds naturally to what happens while driving the vehicle.
Another development, thanks to the growing use of simulators in automotive engineering, has been rapid controller prototype testing; by hooking up the actual ECU to the simulator, it can operate in exactly the same way as a real car. The simulator sends simulated sensor signals to the ECU and the control system sends its command signals back. This same loop can be evaluated on a desktop of course, but to be in any way meaningful, there needs to be a driver in the loop.
Until recently, the industry was forced to rely on basic software and fictive roads in which to test its simulated vehicles. This has not done much to aid the cause of the simulator as manufacturers naturally want to validate their vehicle models by using the roads they know on their regular test routes.
However, within the past couple of years, increased computer power and laser scanning and building capability – offering road profiles, types of surface, bumps and camber and so on – have provided data to the required level of accuracy for automotive simulation (to 1mm in some cases). Costs have come down and there are now the necessary tools to allow efficient, automated data processing.
The tool chain to deliver this advanced software – the required understanding of the vehicle dynamics process and tyre behaviour, vehicle modelling, image generation, road scanning and interfacing with the real vehicle – are getting better and better. Depending on the level of accuracy required, two software engineers can put together a 20km route in around six months.
This progress is allowing OEMs to take decisions much earlier in the design process. Educated choices can be made without the need to build a mule. For example, engineers can test multiple locations of a fuel tank and see how they affect the vehicle’s handling.
The integration of vehicle models with the simulator has never been easier. Having recognised the call from simulation engineers wanting to work with their own unmodified vehicle models, on their own modelling packages and PCs, with and without the simulator, simulator manufacturers have developed flexible external physics packages.
Simulations created in vehicle modelling packages such as Vi-Grade, IPG Carmaker, Vedyna, Carsim, DSpace ASM and Simpack can now be plugged and seamlessly integrated through their Simulink S-functions, to run natively, in co-simulation, with the simulator. This saves time on compiling code and saves costs by eliminating the need for the code generation packages. Removing the need to compile code also means that third party libraries such as Bosch ESP can be used.
This does not replace the simulator’s internal vehicle model and many users still prefer to go down that route, especially if it is open architecture and users can easily modify, add or replace subsystems.
Automotive simulation has borrowed much from the defence environment. There is no greater need for off-line testing than preparing for battle. It’s largely still a matter for the academics but we are seeing interesting developments with simulators and unmanned, remotely operated vehicles. The driver will be on board a simulator, sending the control output to a real vehicle some hundreds or thousands of kilometres away; the driver’s reactions in the simulator will be a response to the returned input. This might sound far-fetched for the road but it does point towards the next development frontier for automotive electronics: the challenge to get data back and forth with high bandwidth and low latencies.
Maarten van Donselaar is CEO of Cruden