Driver-in-the-loop simulation adds value to HIL testing. In article #3 of our Tool Integration Series, we catch up with Cruden’s Christiaan Koppel to explore the applications and benefits of a widely used engineering tool integration.

Car factories might be out of certain stock due to the global chip crisis, but you’ll find no shortage of electronic control units (ECUs) in automotive development labs that are working on the next generation of production models.

Hardware-in-the-loop (HIL) testing is the final stage of controller development following proof-of-concept work at the model-in-the-loop stage and executable code testing during the software-in-the-loop phase. At every step, there is value in adding experiments with a human driver to the development process, but especially with HIL, where testing the interaction between the driver and ECU is an important part of the validation process.

Validating the ECU with all the intrinsic faults and shortcomings of a driver involved is a more robust approach than a pure HIL test without DIL integration, which assumes the driver’s course of action. Drivers are unpredictable, so testing the combination of a driver with the ECU is a more realistic test of whether the car remains safe or not. In extreme cases, if the driver does something that the ECU software engineer did not expect, then the combination of driver and safety-system ECU could make the situation worse rather than better. That makes driver-in-the-loop (DIL) integration highly relevant to the development of safety systems such as electronic stability control (ESC).

To make these tests possible, a DIL simulator is integrated with existing HIL test systems from the likes of dSPACE, Concurrent or Speedgoat. Different tool providers take different approaches. dSPACE, for example, offers a one-stop-shop of hardware and software, whereas Concurrent’s hard real-time, Linux-based operating system requires the customer to integrate elements such as the vehicle model or I/O cards. That enables a more flexible approach to building a HIL test bench, but also one that requires more work. Cruden can integrate its DIL simulators regardless of the customer’s choice of HIL system.

For HIL/DIL integration to work, the two simulation environments must share a vehicle dynamics model running in real time on the HIL system, because the ECU under test expects sensor inputs to arrive, always at the same frequency, in real time.

Example sensor inputs being exchanged between the two sides could involve an engine RPM sensor or a wheel-speed sensor. Driving through a virtual world in the Cruden simulator, the vehicle model generates the sensor signals that the ECU uses as inputs. Conversely, the ECU also has outputs back to the vehicle model, which then influence the driver in the simulator.

Of course, ensuring that the driving simulator integrates perfectly with the customer’s vehicle model is a cornerstone of every Cruden implementation.

“Taking dSPACE as an example, we modify a template vehicle model on the vehicle dynamics side to make it work with our simulator,” explains Christiaan Koppel, lead project engineer at Cruden. “That goes beyond ensuring that the HIL and DIL systems can exchange signals or data.”

There are two parts to the integration. The first is to create a data interface to exchange signals and data between Cruden’s Panthera simulator control software and the vehicle model running on the real-time system. Then the vehicle model must be tuned for DIL use, so that the vehicle responds properly to the driver’s inputs and the platform motion, pedal feel and steering-wheel torque enhance the immersive experience. It’s not hard to imagine, for example, that a HIL model used mostly for braking development, has excellent fidelity in longitudinal acceleration and deceleration, but doesn’t perform as well in the lateral domain.

“If we get a vehicle model from a HIL team that was working on the steering systems, then it’s the other way around,” adds Koppel. “With a HIL system, you’re often very specific on the elements that you’re testing, and you make sure that your model has what you need to test that element. However, to make a vehicle model feel realistic in a driving simulator, we must make sure that the fidelity is where we want it: in all aspects of vehicle dynamics. That’s where Cruden’s experts come in, working closely with its client engineers.”

Cruden and dSPACE share many automotive customers. Integrations between the two are so common that whenever Cruden creates a new release of its Panthera software, it always tests and validates that the dSPACE integration works correctly. It means that engineers on both sides aren’t starting from scratch, every time a new project begins, which in turn expedites the integration process.

“The work that we do in order to get a dSPACE vehicle model to feel like a proper car, need not be redone for every customer,” he confirms. “Once we have a correct dSPACE Automotive Simulation Model (ASM) in a certain release, we can share that knowledge on how to configure the model with other customers.”

Beyond the vehicle model, there are other ways to tighten the integration between a driving simulator and a HIL test system. Sensor simulation in dSPACE, for example, means that sensor models might be attached to the virtual car to detect other traffic vehicles, buildings or road markings. These virtual sensors must also work in the virtual world inside the driving simulator, so Cruden must ensure that features in the driving scenery are visible to sensors as well as to the human eye, thereby aligning with the virtual world used in the dSPACE software.

“There are specific requirements for the content,” says Koppel. “For example, materials on the objects need to be physics based so that the sensor models can react to them. Materials appear differently to a radar sensor or LIDAR and the reflection differs, depending on the material. If we want to share our 3D model with the dSPACE software, we need to make sure that we use materials that are physics based, so that they can be converted to the characteristics that are needed in the dSPACE software to make the sensor simulation work.

“Content can flow in two directions,” he continues. “We can also take elements that are generated in the dSPACE software and convert them so they will render properly in our driving simulator. This sharing of information is not restricted to sensor simulation. A traffic light status would typically come from the dSPACE side, for instance.

Sometimes, HIL integrations go beyond common applications such as ECU testing for ESC or other chassis systems. Cruden has a motorsport customer that integrates HIL and DIL testing for Formula E, where the ECUs that monitor energy management are tested with a racing driver in the loop in preparation of a race event. This helps to determine the best energy strategy, encompassing both the driver’s and the ECU’s role in the process.

Cruden has also integrated a simulator to a customer’s ‘wet-bench’ HIL system that includes a full braking system, complete with all the necessary hardware and brake fluid. The principal use case under test is to blend hydraulic braking with electric braking, so that the driver experiences seamless deceleration and consistent brake pedal feel, rather than noticing the switch from friction to regenerative braking.

An extension of this type of integrated testing is set to become more common in the future. In a vehicle-in-the-loop (VIL) setup, an entire car sits on a four-wheel chassis dyno side-by-side with a DIL simulator. The regular powertrain still provides motive power, but the driver pilots the car from the simulator. As they travel through a virtual world, they create sensor and steering inputs that are fed to the real car through a HIL system, with steering, accelerator and brake robots replicating their actions in the real car.

dSPACE has already worked with Hyundai Mobis on VIL testing to validate ADAS and autonomous driving (AD) functions. Another potential application could lie in homologation testing, providing the authorities with a safe, repeatable way to ensure that ADAS and AD systems perform in the way their makers claim, including in heavy traffic.

Cruden is open to working with whichever HIL system the customer wishes to integrate. As always, its approach is about adding value to existing, preferred engineering tools by adding a DIL component, rather than prescribing specific products. In addition, the size and flexibility of Cruden’s simulator architecture opens the door to bespoke configurations for specialized use cases, such as adding a wet bench to the top frame for brake simulation, as described above. In this way, Cruden integrates with HIL not only at the software level, but also with simulation hardware.

For more information, please contact Dennis Marcus via d.marcus@cruden.com or on +31 20 707 4646.

Links to subsequent articles will be added below as they are published.

View all articles in our Tool Integration series of articles: here.

Article 1: Driving simulator and third-party engineering tool integration

Article 2: Four wheels good: Vehicle model integration for dynamics and more

Article 4: In search of perfect harmony: HMI testing in a driving simulator

Article 5: New Panthera Corebox is at the heart of tool integration

Article 6: Standard interfaces for non-standard simulators

Article 7: Perfect harmony: The driving simulator as a virtual OEM

Article 8: Tool Integrations - Data acquisition

‍