dSPACEs Model Initiative

dSPACE has developed its own simulation models for designing and testing automotive electronic control units (ECUs) for powertrain and vehicle dynamics. They will be available under the name Automotive Simulation Models (ASM) starting in the third quarter of 2005.

There are already several model libraries on the market, so why does dSPACE need its own?

Hanselmann: Models from different suppliers, and frequently customers own models, all run on our simulators. However, we often encounter gaps in these solutions – in modeling depth, in handling, in the quality of integration with our hardware and software, in synchronization with our project management, or in parameterization and commissioning. It is these gaps that we want to fill.

Is producing your own models the only way to do this, rather than closer cooperation with partners?

Hanselmann: A lot can be achieved by close cooperation. However, since we know our HIL systems intimately, we can clearly focus on meeting customer application priorities with a systems approach and avoid negotiating compromises with other parties. Also, there are many customers who appreciate a solution from a single source.

Will dSPACEs models now be first choice for use in its simulators?

Hanselmann: We are keeping all options open. Customers will decide which models they want to run on our simulators. We’ll continue to support customers models and models from third parties. This takes into account the fact that customers are ‘used to’ specific models, and that no two models are identical. They can have different modeling depths, or different parameterizations. And the model vendors specialist experience also plays a role. Our models are now an additional option.

Up to now, dSPACE has had a successful partnership with TESIS. What is going to happen to that?

Hanselmann: We will still offer TESIS models for use with our simulators and make dSPACE test and development systems available to TESIS for optimum technical maintenance and continued development.

The goals of the ASMs are better technical integration and very fast processes in setting up and modifying simulators, says Dr. Hanselmann.

The vehicle dynamics model is based on a multibody system. It can be extended by means of engine models and the model for brake hydraulics, to create a virtual vehicle. The drivetrain model is configurable for front, rear, and all-wheel drive. Maneuvers are planned by means of graphical editors.

What advantages will ASM have for customers?

Hanselmann: They will have better technical integration, plus particularly fast processes for setting up and modifying simulators. They will be able to modify the models simply and quickly themselves, for example, by replacing or adding components. Our ASM models are optimally designed for this, as they are open Simulink models, and completely accessible to and viewable by customers.

What does ‘open Simulink model’ mean?

Schutte: To the greatest possible extent, the models are constructed from basic Simulink blocks. They are not implemented in S-functions, which would be visible to customers only as single, closed DLLs. So users can study the ASM implementation in detail. Though there are a few model parts that are awkward to describe in Simulink because of the block structure – for example, the modules for maneuver control, for the driver, or for computing the road. These parts are implemented as C-coded S-functions. However, customers can replace the modules any time they want, of course, and their functionality is explained in detail in the documentation.

What applications are the ASMs suited to?

Schutte: The ASMs are for simulating diesel and gasoline engines, and the dynamics behavior of vehicles. They represent the controlled systems for engine, transmission, and chassis ECUs, so they are ideal for real-time use in HIL test systems. The models are also easy to combine in Simulink, so they can be used to build a virtual vehicle, for example, for HIL testing of an entire ECU network in which both engine and vehicle dynamics ECUs have to be tested. But they are also suitable for offline simulation, so they can be used in function design.

Are there model extensions?

Schutte: Yes, we currently offer a brake hydraulics model and a physical turbocharger model as extension libraries, for example. And we are more than willing to develop model extensions or special modules based on the present models, especially where this is necessary for the functionality of a dSPACE Simulator in a specific test task.

How well do dSPACE models perform?

Schutte: The ASMs are primarily designed for real-time use in HIL simulators and in terms of simulation precision, they are comparable to models that are already on the market. However, performance is more than just simulation precision. As Dr. Hanselmann already mentioned, features such as ease of parameterization , usability, variant handling, potential for specific further developments, and worldwide support are at least as important.
As regards real-time capability on current dSPACE hardware, the ASMs execution time is far below the usual sampling rate of 1 ms, even including the necessary I/O, so users have plenty of scope for additional models.

Have the ASMs been real-world tested?

Schutte: Of course, we first tested the models on the HIL simulators we have available in-house for currently available ECUs, such as ESP8 for vehicle dynamics and EDC16c for common-rail diesel engines. We are running parallel projects to validate the vehicle dynamics model using measurement data from a vehicle currently in production. The initial results indicate very good consistency between measurement and simulation. An ASM engine model has been integrated into a universal HIL simulator for diesel engine ECUs and is performing well in practice.

What are the particular features and strengths of the dSPACE models?

Schutte: We are concentrating at the moment on implementing all the model parts that are needed for typical HIL applications. On the engine side, these include mean-value models with mass and energy flows, the associated component models such as turbocharger and injection systems, and the ECU functions needed for commissioning. There are also utilities for parameterizing the engines.

In vehicle dynamics, formulas are needed for the drivetrain, car body, axles, and wheels, plus additional model parts that HIL applications need. These include a driver model, a road model, and maneuver control.
A key tool in our view is ModelDesk, our user and parameterization interface, which has a typical dSPACE look and feel. It’s a graphical user interface that makes it easy to enter parameters, and to manage and switch data sets. Frequently recurring structural variants can also be selected online. This is increasingly important for tasks such as adapting HIL systems to country and feature variants in automated testing. ModelDesk is also the front end for the fast and flexible definition of road profiles and test maneuvers.

Where did dSPACE gain the necessary know-how?

Schutte: That comes from a whole range of sources. First, we have years of experience in all the issues involved in real-time simulation, not least because we have run several hundred projects for turn-key HIL systems. For the actual modeling work, we put together a team of engineers who previously specialized in vehicle or engine technology at their university. Additional know-how comes to us via other routes, for example, through cooperation with universities. To produce ASM, we combined all this accumulated knowledge with state-of-the-art technology as reflected in the latest scientific literature.

How will the models develop from here?

Schutte: We will further develop the mathematical/physical core models as our international customers want, to meet the specific requirements of HIL simulation. ModelDesk, the graphical interface for handling the models, will be given a whole series of functional extensions, for example, for engine model parameterization, user guidance, simulation control, and of course remote control for use in automated test sequences. These requirements come from our own practical experience with applications and will be implemented as soon as possible after Version 1.0.