When one speaks about computer simulation technology for automotive development, there are several categories to consider: Off-line modelling (OLM), Software-in-the-Loop (SIL), Hardware-in-the-Loop (HIL), Vehicle-in-the-Loop (VIL), and Driver-in-the-Loop (DIL). It is worth noting that HIL has taken on new meaning in recent years; HIL previously referred only to the integration of physical control systems (ECUs, etc.) with simulations, but now the term also covers mechanical-HIL, integrated sub-system test benches. When it comes to proving out on-board embedded systems (electro-mechanical control systems, ADAS, etc.), each category of simulation can be quite useful.Of all of these simulation approaches, HIL simulation usually receives a majority of resource allocations, and this is understandably so. HIL connects real subsystems with simulation models, so it is possible to replace computationally prohibitive models with real systems or prototypes. It is also a natural conduit for OEMs and their suppliers to work together. To integrate HIL simulations, one only needs to define the communication I/O with the real system, and “wire it” into the simulation. The actual I/O data exchange is then managed by a capable HIL system at one end, such as dSPACE or Opal-RT, and a capable simulation environment at the other end, such as Ansible Motion’s DIL co-simulation backbone.
The good news is that most HIL simulation real-time execution frameworks are a natural fit with DIL simulations, which by definition must operate in real time for human driver interactions to be valid. DIL simulations can, of course, add further efficiency to vehicle developments by bringing real people into early and often contact with on-board systems. We’ll have more on that later, but first, here are 7 key points to consider when integrating or “on-boarding” vehicle HIL simulations:
- Find the right real-time operating system(s). There are a number of commercially available, real-time operating systems. All may work, but each is different. Bandwidth is key.
- Specify a truly modular system. You do not just want a system that is only modular inside its own world, within a specific supplier’s operational framework. You want a system that can also attach to external systems, such as DIL simulators, with standard communication interfaces.
- Define use cases. It is always good to have a clear understanding of use cases. When you speak about Hardware-in-the-Loop, are you thinking simply of a specialized operating system, or is it a true HIL setup that can execute real-time simulations and accommodate hardware I/O? Will you be integrating models from your suppliers or customers? What software, hardware, or interface restrictions (if any) affect the use of shared models?
- Is the internal modeling architecture streamlined? The difference between a “go” and “no-go” situation can be as simple as assessing real-time compatibility, or it may be a bit more complex (pun intended). Also check to running performance because you may wish to attach it to other in-the-loop systems in the future.
- Decide whether you need mobility. Is it appropriate to have your HIL setup confined to the laboratory, as is the case with a bench-top simulator? Or does your system need to be more portable, used trackside or at a proving ground?
- Classify your simulations. If you can place your simulations into broad categories such as fail-safe testing, subsystem interaction testing, parameter sweep testing and human interaction testing, you will immediately have a powerful way to recognize which, if any, simulations will benefit from the addition of DIL and /or other simulation types to the process.
- Aim for efficiency. If, having considered points 1-6, you are satisfied that you have the capability to run HIL simulation efficiently, how best can you put it to work? Is it a tool that makes your life easier? Or is it adding unnecessary complexities? Are there any low-hanging simulation fruit in the trees, ways to realize near term gains?
Recap
When HIL simulations are integrated with the DIL simulations, new opportunities arise. By keeping DIL simulations in place right along with HIL, throughout the development process, the number of real-world vehicle tests can either be measurably reduced or purposefully concentrated in areas that promise the most potential. HIL simulation usually requires real-time execution by default, and this makes for a natural fit with DIL simulations, which, by their very nature, must operate in real time.
Consider the following example: An established auto manufacturer can run through OLM and SIL simulations with blinding speed, covering a huge range of “what ifs” well in advance of product development kick-off and throughout the development cycle. If a particular ECU or component becomes available (as hardware), and its interaction complexities with vehicle areas must be evaluated, the development program might logically enter a HIL phase. However, the timing of this HIL phase may only be slightly ahead of prototype vehicle testing, or even simultaneous with it. In either case, subjective driver feedback will influence the HIL area. Why wait for this to occur sequentially? Since subjective feedback has the power to completely redirect an entire vehicle development program (usually at the most inconvenient time!), it is quite useful to have a “sneak preview” of subjective assessments in the form of DIL simulation capability. If the correct tools are in place via the above considerations, it is possible to expand the definition of co-simulation, and find yourself ahead of the curve.
To learn more about how DIL simulation is influencing modern vehicle development, download our FREE white paper, “Look Down the Road: Driving Simulator Technology & How Automotive Manufacturers will Benefit”.
