Virtual test driving at GME
Last year, the vehicle dynamics software CarMaker was ported onto the dSPACE hardware platform. Since then, IPG has not only been selling CarMaker/HIL test benches, which are based on a hardware platform using established standard technologies, but also a further version of CarMaker for dSPACE real-time systems. As a long-standing customer of CarMaker, GME Engineering initiated porting the software, and a few months ago put the outcome, the CarMaker/DS, into operation. We spoke to Dr. Henning Holzmann, Head of Driving Performance Simulation at GME in Rüsselsheim and his team members, Dr. Michael Kochem and Karl Michael Hahn, about their first experiences with the CarMaker/DS test bench, and about the importance of virtual vehicle development at GME.
Dr. Holzmann, barely one and a half years ago GME Engineering suggested porting CarMaker onto the dSPACE hardware platform. How did you come up with this idea?
Holzmann: General Motors decided to introduce a standard HIL-System-Platform as part of a global harmonization process. Following a long decision making process, GM chose to go for the dSPACE hardware platform, since it is supported in all GM relevant regions throughout the world and covers a wide range of technological applications. The next obvious question was: What does this decision really mean for us in GME Driving Performance Simulation? How can we transfer as much of our knowledge as possible of vehicle dynamics simulation onto the new hardware platform? After all, we had many years of experience with the IPG HIL systems and most recently had been very successful and also very satisfied with it in the development of the latest OPEL Corsa. The obvious idea was to port the complete CarMaker software package onto the dSPACE hardware. For this reason we got dSPACE and IPG to get together, a co-operation which resulted in an excellent porting concept. IPG had implemented the concept without any technical problems by the end of last summer. At the CarMaker User Conference in June 2006 CarMaker was shown on a dSPACE system for the first time. After the new product was officially released by IPG, we at GME Engineering bought two systems, which we are very satisfied with. In our opinion, the combination of dSPACE hardware and IPG software provides the same level of performance as the IPG/IPG system.
What requirements did you identify for porting?
Hahn: The requirements for the migration were very simple: we wanted everything to perform on the dSPACE hardware exactly as it has been doing previously. This also referred to the CarMaker tools: we wanted IPG-CONTROL and IPG-MOVIE, for example, to remain available as usual after the transfer. IPG carried out the plan very professionally. The central mechanism for porting the CarMaker onto the dSPACE system was quickly identified. From then on all expectations were fully met. And we are able to use our existing developments - driving maneuvers, evaluations, etc. - exactly as we had done before.
So after the migration, have you been able to carry on smoothly with your previous development work?
Hahn: Yes. The interfaces have basically not changed. There are now a few more possibilities with dSPACE tools, but our working methods certainly didn't have to change.
Holzmann: This also applies for our internal GME test automation environment. Our working methods are essentially based on Software-in-the-Loop- and Hardware-in-the-Loop work. Software-in-the-Loop works exclusively using CarMaker/Simulink and HIL now runs CarMaker on the dSPACE hardware. The test automation tool is designed to work in SIL as well as in HIL with the same functionality and the same commands. Thanks to the unchanged interfaces, the test automation can be used in exactly the same way as prior to the migration.
How do you assess CarMaker as a tool for virtual vehicle dynamics development?
Holzmann: We always keep a close eye on the whole vehicle dynamics software market and overall I believe CarMaker is currently the best performing system in the market. With CarMaker we have developed a simulation-based release recommendation for the software and parameters of the ABS/ESC system in the latest OPEL Corsa. I think that this capability is clearly CarMaker's unique selling point, distinguishing it from all other vehicle dynamics simulation tools. From a total of 72 possible different vehicle variants, 20-25 were ultimately tested as validation cars. The remaining variants were tested in the simulation. Accordingly, the release recommendations were made both on the basis of real driving tests and, for the first time, through a software based approach based on the CarMaker-Model. And as far as I know that has never been achieved with any other vehicle dynamics simulation tool in the market.
Traditionally, vehicles were released based on real driving tests. What role does a software-based release recommendation play in vehicle development?
Holzmann: Perhaps I should first give a short introduction into complexity. Currently, we have the responsibility for the development of several global GM vehicle platforms here in Rüsselsheim. One of these platforms, for example, provides around 20 body styles, which really reflect all the varieties of GM vehicles which will be available on the global market. In addition, there will be approximately 55 powertrain varieties with different engine-/gearbox combinations and different exhaust emission standards among the vehicles of this platform. There are also the different control systems, such as ABS/ESC, continuous damping (CDC), active steering and all-wheel-drive. Additionally, the control units are linked up to each other and theoretically the product portfolio allows the customer to combine the control systems in various ways. If you multiply control systems with powertrains and body styles, you get a four-digit number of variants. This clearly shows that we can no longer really work without simulation and without well engineered test automation, which is able to run for a weekend or even longer. Simulation is absolutely necessary in order to cover the wide variety of future variants at all.
When you talk about complexity, which role does the linking up of the control systems play?
Hahn: The linking up is a really important aspect, because the suppliers can't test the linked-up systems. Each supplier is responsible for making sure that his own subsystem works. As an OEM we have to ensure that the different chassis control systems interact correctly.
Holzmann: We start off with the subsystem part that has been validated by the supplier and it is our job to validate these at the vehicle level. Then we connect the different chassis controls systems and investigate their interaction.
What are the requirements for granting software-based release recommendations?
Kochem: Our task is to check if the performance of the system corresponds to its specifications. We test whether the software and the corresponding parameter set will be able to ensure the optimal functioning of the vehicle on the road. Therefore we require an excellent quality of the simulation models as well as of the hardware. Reality must be reflected as accurately as possible both in the SIL and in HIL simulation. We ignore neither Software-in-the-Loop nor Hardware-in-the-Loop. Software-in-the-Loop is very well suited to carry out tests with a high throughput, and to check the precision or the validity of the software. But inaccurate parameters or software errors can always occur, and these have to be detected by Hardware-in-the-Loop simulation.
Hahn: Software-in-the-Loop tests focus on a particular area in the control unit, namely the performance software, which contains the actual control algorithm. The periphery, or what surrounds it - the operating system, the CAN communication, the power-stage drivers - are not implemented in the SIL area and therefore must definitely be tested again by Hardware-in-the-Loop in order to allow the making of reliable release recommendations.
Holzmann: And for that you naturally need the best vehicle model in the market. From our many years of experience with CarMaker, we know that it offers the best vehicle dynamics model, which is why we use it for our simulation.
How important is a continuous toolchain?
Holzmann: A continuous toolchain from the beginning to the end is extremely important. Initially, we model the vehicle as a multi-body system and compare calculations with measurements. Afterwards the model is integrated into CarMaker/Simulink by means of a custom-made translator to make it available for Software-in-the-Loop simulation. Of course we once again compare our calculations and measurements. In the HIL tests the same set of parameters is used, which has already been validated in the multi-body simulation and the SIL simulation. This results in a continuous toolchain from the beginning to the end.
To simulate vehicles which do not yet exist in real hardware, a complete virtual toolchain is necessary. At GME Driving Performance Simulation we have established such a complete toolchain, which is highly validated and works excellently, so we can fully rely on the results of our simulation. If you wanted to replace one tool in this chain, this would break the whole ensemble.
Kochem: For that reason, our test automation is designed in such a way that both SIL and HIL can be run without making changes. We can be sure that both SIL and HIL reflect realistic conditions and that both processes are based on the same simulation.
How do you execute performance checks?
Hahn: We always examine the vehicle. Even when we examine an ESC control unit, we don't look directly into the ESC, but concentrate on what the vehicle is doing. We look at it the way the customer would experience it. We are not interested in whether some function in the ESC produces a particular signal at a particular time. The supplier has already examined that. We are only interested in the vehicle itself. Does the vehicle stay on the road? Is the driver able to handle a certain situation? That's our objective. Naturally we do this step by step, starting with the ESC and then with the other networked systems.
Holzmann: The procedure is the same as for the driving test. During a test drive, particular maneuvers are driven, to test or to apply a particular behavior. And the simulation imitates the test drive. We've talked a lot to colleagues from the driving test department and asked: What do you do in order to parameterize, co-ordinate or test an ABS/ESC system? This has helped us to identify a number of representative driving maneuvers, which we simulated with CarMaker. We started off with 20-30 driving maneuvers for the ABS/ESC system, which we simulated using many different parameter variations. Of course the target values are set for each test drive. These can be very simple values such as the braking distance after emergency braking or very complex computed details, which help the test driver to decide what behavior is good or bad. Naturally, this procedure is very well suited for maneuvers which can be evaluated using objective criteria.
What role does the test drive play in addition to the simulation?
Holzmann: Simulation doesn't replace the driving test. It supports it, so that - by a close co-operation - we can achieve the best results. At General Motors we call this the "Road-Lab-Math" strategy. Each of the three elements - the driving test (road), Hardware-in-the-Loop simulation (lab) and Software-in-the-Loop simulation (math) - have their own area of application, which is very important and cannot be replaced. Only the results from all three elements together lead to a reliable release.
Thank you very much for talking to us!
