In the early stages of specifying and deploying any new Driver-in-the-Loop (DIL) simulator, one of the most common considerations is the integration with 3rd party hardware and software tools. For example, you may already have an in-house solution for vehicle physics simulation, or you may have existing Hardware-in-the-Loop (HIL) test benches that must be connected to your DIL simulator.
Can a “turn-key” DIL simulator that is, by default, an all-inclusive offering, give you the seamless connectivity with your preferred tools that you need? Well, sometimes yes, and sometimes no – and finding this out with certainty involves looking beyond a rote specification summary.
Sum of the Parts
A famous quote, usually attributed to Aristotle, states that “The whole is [often] more than the sum of its parts.” This is conceptually accurate when it comes to reviewing driving simulator specifications. Just as it would be quite difficult to create a refined automobile by gluing together assorted parts, building a refined virtual car (in the form of a DIL simulator) from some PCs and actuators and whatnot would be equally difficult.
Luckily, the task at hand is usually not quite so elemental, i.e., most users of tools do not want to be tasked with designing and building the tools themselves. A carpenter wants to build houses, not hammers. A carmaker wants to build cars, not driving simulators.
With driving simulators, more often than not, it’s more a matter of wanting a variant without upsetting the system as a whole. This can perhaps be best illustrated by a representative case study:
Case Study: Switching vehicle physics models
The Challenge: “We are interested in using Driver-in-the-Loop simulation to help develop our cars. But we are a large organization, so we have different groups using different vehicle modelling tools. For example, our design groups favor SIMPACK, but our development group uses VI-CarRealTime. We know about some driving simulators that fit well with our development group’s needs, but we are concerned that this direction might exclude our design groups. What should we do?
The Solution: Stay flexible and scalable by establishing a hub DIL simulation lab that hosts an Ansible Motion Delta series DIL simulator. This engineering-class simulator can be operated under centralized supervision, and used as a shared tool for all your functional groups. The simulator is not tethered to any particular vehicle physics tool, and there are operational cases in the field that demonstrate connectivity to your named vehicle modelling tools. In fact, we can connect directly to these tools (as executed in MS Windows), or we can connect to intermediate real-time systems such as Concurrent and dSPACE that may be hosting deployed models from SIMPACK and VI-CarRealTime, and we can connect to many other tools as well.
Behind the Curtain
Many so-called “turn-key” driving simulators are, in fact, closed systems that are not really meant to be broken into their constituent elements or integrated with other systems. Unfortunately, sometimes this is exactly what needs to be done. Driving simulator use cases might pull projects (and the corresponding DIL simulator specifications) in many different directions. Projects, such as the case study described above, might require plug-and-play switching capability between various software tools and simulation environments, and require connectivity to hardware such as sensors or test benches.
Actually, there is a subtlety to the above-described challenge. It’s easy enough to source a DIL simulator that can switch out its vehicle physics (on paper, at least) – the elusive part is finding a DIL simulator that can serve the diverse demands of various projects and use cases in a way that preserves the overall fidelity of the simulations.
What we really need to do is step behind the curtain, and seek an answer to the following question: What is the architectural hub of the DIL system that you are considering? Some driving simulators place the computational hosting environment at the hub. Other simulators place a vehicle physics engine at the hub. Still others are clearly force-fitting everything around some mechatronic equipment. Of course, these system architectures may be appropriate or inappropriate based on your intended use cases. Here at Ansible Motion, we have a different answer to the above question than other DIL simulator providers.
To review some of Ansible Motion's unique approaches to Driver-in-the-Loop simulation, and learn how working with us can benefit your vehicle developments, download our FREE eBook:
