Keywords

1 Motivation

Due to the steadily increasing relevance of autonomous driving functions and rising software complexity, the automotive industry is facing unprecedented challenges. Essentially, these challenges have three different underlying causes:

  • The market which is demanding new vehicles in less time and with smaller budget

  • The product itself which is becoming much more complex with numerous control units which are networked with each other

  • The development process which requires increasing levels of validation in the domains of vehicle dynamics, advanced driver assistance systems (ADAS), automated vehicles (AV) and powertrain.

As many recent publications have shown, there is no longer any doubt among industry experts that billions of test kilometers must be driven to fully validate vehicle safety of autonomous driving functions. This means it is not feasible to simply build physical prototypes and to validate them, but rather that a new approach to vehicle development is required.

2 Driving Simulators in the Development Process

2.1 Updating and Streamlining the Automotive Product Development Cycle

Traditional automotive design and development cycles form a largely serial process with the design stages undertaken up front, based on previous model or competitor vehicle data. The targets for the new vehicle are often subjective, with little or no direct correlation to the objective metrics produced by simulation tools. Subjective feedback is limited to later stages in the design process and requires the manufacture of expensive mule and prototype vehicles. Additionally, a commitment to suppliers is required to create tooling and molds. However, there is a high degree of risk that subjective targets will not be met without iterative design changes and associated costly (both financial and time) retooling.

Fig. 1.
figure 1

Traditional automotive development V-cycle

Full size image

In Fig. 1, the traditional V-cycle is shown, with the left side representing the initial simulation activities, leading from concept to detailed design of each component. On the right side the testing phase is depicted, beginning with the component level followed by full vehicle testing in laboratories and on proving grounds, finally resulting in vehicle sign off.

This approach is not particularly well suited for the mentioned new challenges facing the automotive industry. It is not sufficiently fast, beyond that innovative technology requires a more integrated development approach. Furthermore, it can be difficult, especially for new technologies like ADAS/AV, when billions of driven kilometers are a prerequisite. And finally, it can be expensive, especially when late cycle changes on the right side of the cycle have to be applied.

This workflow has been optimized by connecting engineers from the area of computer-aided engineering (CAE) directly with test drivers, starting from the very first phases in the development process, as shown in Fig. 2. This connection is made possible with the driving simulator. Using this tool, a test driver is able to control a simulated vehicle model which has been created by CAE engineers. This enables the test driver to provide immediate subjective feedback to engineers early in the development cycle. As a result, more vehicle variants can be tested and more issues can be identified earlier in the development cycle saving both time and money. It is important to mention here that simulators are not intended to completely replace proving ground testing, but the vehicles that are tested at the proving grounds will be better refined and closer to design intent.

Fig. 2.
figure 2

VI-grade driving simulator accelerated V-cycle

Full size image

The test effort described above and the test cases for the corresponding vehicle systems have reached such a level of complexity over the course of time, that their testing in real test driving alone is hardly manageable. The reason for this is the necessary consideration of the vehicle’s entire environment. In a collaborative engineering process engineers and test drivers can work together to create a more sophisticated vehicle.

Already, as a direct result of adopting the advanced driving simulator technology, it can be observed that fewer physical prototypes are required as the sign off process becomes more virtual, since driving simulators enable users to simulate all automotive disciplines with a single machine. This leads to a narrower V-cycle, which is equivalent to a shorter development time.

2.2 Testing Disciplines on Driving Simulator

Ride and handling testing is facilitated by a hybrid architecture. The nine-degrees-of-freedom platform separates low frequency, large amplitude motions required for handling from the smaller amplitude higher frequency (up to 50Hz) motions required for ride as well as delivering pitch, roll and heave whilst maintaining high platform stiffness. Typical motorsport applications include race car setup, hybrid and race strategy, driver training and vehicle development. Vehicle dynamics applications include chassis tuning, tire development, driver training and control system design whereas for ride and comfort, variant comparisons and offline results replay from experimental and/or multi-body simulations are typically applied.

Noise, vibration and harshness (NVH) tests allow for interactive driving simulation of vehicle NVH from a desktop PC as well as fully immersive vehicle NVH evaluation while driving a physical car. Increasingly, there are demands to use the same sound models used for NVH simulators in the full motion platform to improve the quality of the overall driving experience in the simulator. This applies in particular for electric vehicle development where vehicle noises (e.g. tire and wind noise) which may have been partially or fully masked in a petrol/diesel-powered vehicle may become an irritant to the driver in an electric vehicle.

Using traffic scenarios in a driving simulator enables ADAS studies with human acceptance in-the-loop. Driver-in-the-loop (DIL) methods can help to gain important knowledge concerning the system characteristics and the vehicle behavior at a much earlier stage in the development process. The driving simulator provides a realistic and repeatable test bed to evaluate dangerous manoeuvers, driver distraction and monitoring, ADAS systems development and verification (AEB, LDW, LKA, ACC, etc.).

In the domain of driving simulators, an open environment and a turnkey solution are essential. Many OEMs and suppliers already have software that is embedded in their development process. When implementing a driving simulator, it allows them to keep using their existing tool environment and thus maintain their way of vehicle development.

VI-DriveSim as an ecosystem includes the software and hardware components required for a driving simulator as shown in Fig. 3.

Fig. 3.
figure 3

VI-DriveSim key components

Full size image

Because of its open API structure, it allows for a custom combination of the ecosystem plus the customer software can be used on driving simulators. IPG Automotive with its open integration and test platform CarMaker is the first VI-certified partner to offer an external physics engine approved for use with VI-DriveSim.

3 Consistency in the Development Process

A major challenge to increase efficiency in the development process through new or additional methods, such as the use of driving simulators, is to ensure that the continuous use of existing key components for virtual test driving is made possible. These key components include the virtual prototype, road models and environment models, entire scenarios for describing the movement of other road users, as well as solutions for automated test validation [1].

Depending on the availability of existing key components for virtual test driving, different requirements arise for the simulation environment in order to enable efficient progress in the development. This results in different configurations or usage modes of the simulation environment in order to utilize the strengths of the tools with the underlying data.

The virtual prototype is a purpose-driven digital twin of the vehicle under test (VUT). As a parameterized whole vehicle model in the simulation tool, it comprises the same systems and components as its real-world counterpart, see Fig. 4. All required component and system models from the development departments involved at both OEMs and suppliers are combined at the earliest possible point in the development process. The virtual prototype can thus be used seamlessly in all stages of the development process – for early testing of the control algorithm using the model-in-the-loop method up to function and release tests of the system on a hardware-in-the-loop test bench, which enables front-loading.

To increase efficiency in the development process, virtual prototypes already configured in earlier stages are seamlessly reused on the driving simulator. The continuous reuse of the vehicle model helps to increase confidence in simulation by avoiding the effort and potential errors involved in converting and analyzing datasets from different modelling and simulation tools.

In addition, component and controller models are already integrated into the virtual prototype at this stage of development via typical and performant mechanisms like direct code integration, including automatic translation of Simulink models into code (Simulink Coder Interface) or the Functional Mock-Up Interface standard (FMI). With this procedure, they can also be reused. The work can therefore focus on the development of functions and systems in the driving simulator.

Fig. 4.
figure 4

Components of the virtual prototype

Full size image

4 Solutions for Different Consistency Requirements

In the following, typical configurations or usage modes and their advantages are presented.

4.1 Consistent Use of the CarMaker Vehicle Model

CarMaker is used by many OEMs and suppliers throughout the entire development process. As a basis, the required virtual prototypes are built in CarMaker and the models are integrated as described before [2, 3]. In many cases, users from the fields of vehicle dynamics and comfort would like to continue using the already existing virtual prototypes, which were often built in other departments, and use them on high-precision track files of circuits or country roads modelled in VI-Road for investigations in the field of lateral and vertical dynamics. In addition, it can be observed that central CAE departments are increasingly being established whose main task is to build virtual vehicle models of different levels of detail and distribute them within the company [4, 5].

In combination with the first solution presented in this paper, the virtual prototype with all integrated models in CarMaker can be used in the VI-grade simulator environment familiar to the user, including the visualization of the tracks with VI-GraphSim, see Fig. 5.

This means that CarMaker provides the whole modelling of the vehicle model as well as the model integration capabilities, while other components of the driving simulator application are executed by VI-DriveSim. The continued use of existing road models, which are also an important component for driving simulator applications, can be mentioned as a second advantage for increasing efficiency in the development process.

Fig. 5.
figure 5

Integration of the vehicle model and subsystem models

Full size image

When selecting the tire model, there are different possibilities for the calculation: In the first case, the contact points of the tires are transferred from the road model to the vehicle model which then includes the tires. A detailed modelling of the IPGRoad is therefore not necessary, since the horizontal excitation comes from the detailed road model in VI-Road.

In the second case, the VI-Tire API is used which allows to utilize a variety of specialized tire models like ITWM’s CDTire models or MegaRide’s tyre [6, 7] models to extend the area of application. In this case, the tire models are no longer part of the vehicle model itself. Instead, they are calculated separately using the direct tire vendor libraries, coupled to the vehicle solver via the VI-Tire API, so that the tire-vehicle interface is done at the wheel carrier level. The connection to the road contact is managed a by the VI-Tire API. In addition to a larger availability of models, this configuration also offers possibilities for automated parallelized calculation of tire models which is critical for real time performance with complex tire models. In both cases, as in the cases described below, the signals are exchanged via the Concurrent Simulation Workbench, a main component of the entire software environment for low latency.

A typical application of this solution is, for instance, the development and calibration of chassis systems for the adaption of lateral and horizontal dynamics. For example, the steering system and the corresponding steering feel can be optimized early on in the development process. Different mechanical variants or different calibrations of the parameters in the control unit software can be compared both objectively and subjectively.

4.2 Consistent Use of Scenarios

Fig. 6.
figure 6

Overview of the simulation environment

Full size image

In the field of driving simulator applications, a transition from studies on an empty road such as a racetrack to scenarios with several road users can be observed. These new applications are made possible by an extension of the software environment on the driving simulator.

In the area of ADAS/AV development, the aim is also to ensure that scenarios and objective evaluation criteria, which both may contain intellectual property of the OEM or the supplier, can be reused with driving simulators without any steps of conversion. This allows to reduce the effort required to carry out scenario-based tests: Since no conversions have to be made, user confidence in the simulation results increases and the reproducibility of the results in the different phases of the development process (from MIL to DIL) is ensured. It also aims at avoiding re-parameterization and validation of sensor models.

In addition, modelled 3D worlds can also be considered a key component for virtual test driving, as the effort required to create them is not negligible [8, 9]. In this regard, the use of generated 3D environments and scenarios in driving simulator applications in a co-simulation of different simulation tools should be avoided: Especially when investigating driver acceptance and reaction to driver assistance functions, it should be considered extremely critical if the real driver and virtual sensor models possibly access different 3D environments for perception. A high level of conformity must be achieved in order to exclude unfavorable effects on the human-machine-interface.

For this purpose, IPG Automotive and VI-grade are working on further solutions to integrate CarMaker with all components, including the virtual prototype, sensor models, scenario and test run descriptions as well as the visualization MovieNX, into a VI-grade driving simulator, see Fig. 6. This allows the developer to use the familiar CarMaker environment while sitting in the VI-grade driving simulator. This also applies to the use of different sensor types and classes together with road and environment models parametrized with the CarMaker toolchain.

Typical areas of application for this operating mode are studies of the HMI interaction between ADAS functions and the human driver, e.g. to evaluate the takeover maneuver of SAE level 2 or 3. On the path to SAE automation level 5 and when developing ADAS/AV functions, the necessary interaction between driver and vehicle increases. The vehicle may ask the driver to take over a driving task for example. A safe handover between assistance systems and the driver presents a challenge for modern HMI systems. In order to manage the handover successfully, analyses of usability and comfort of the respective functions can be performed with HMI mock-ups in the driving simulator.

Thanks to a full feedback from the simulator, the user is able to evaluate the ADAS functions and their influence on the driver and to experience the takeover from the automated system − for example when developing highway assistance or collision avoidance systems or for verification of driver distraction or the effectiveness of the HMI design. The simulator allows to safely test and optimize the behavior of these functions, especially in provoked failure situations or various traffic situations, early in the development cycle. [10].

The described solutions will be available in all driving simulators, from desktop simulators to static simulators to dynamic simulators. This way, the model integration for example can be verified, prepared and optimized in the office on a desktop system. Once the models are used on the fully dynamic simulator, which replicate real world testing more closely, the focus is on subjective vehicle refinement instead of model preparation and debugging.

5 Conclusion and Outlook

In this paper, the high importance of driving simulators in the vehicle development process was presented. Furthermore, it illustrated the challenges in the development process, solutions for different use cases and possibilities for an accelerated development process with already existing key elements for virtual test driving.

With the help of a single driving simulator and the software solutions from IPG Automotive and VI-grade, it is possible to cover an extremely wide range of requirements. The continuous development in the areas of software and hardware makes it possible to extend the virtual vehicle development process to other areas of application. In order to further simplify the development process, the possibility of ECU integration for hardware-in-the-loop has been identified as an opportunity for improvement.

IPG Automotive and VI-grade continue to work towards customization in order to increase the consistency in the development process further.