If you are an engineer who uses driving simulators to develop Advanced Driver Assistance Systems (ADAS), then the terminology “ground truth” means something specific to you. Ground truth representations define how your sensors and on-board systems interact with the virtual world, with calculated surfaces and objects. But if you are a technical manager, “ground truth” can have a double meaning.
As a manager overseeing the integration of Driver-in-the-Loop (DIL) simulation technologies with your vehicle development process, your virtual world undoubtedly expands beyond the confines of your DIL simulator lab. As such, your “ground truth” may be related to defining reference points for cross-functional compatibility and resource management. As a manufacturer of engineering class DIL simulators, we have been exposed to some of the typical management considerations. So we thought we would share a few thoughts.
DIL simulators bring together a number of advanced technologies. Mapping these technologies to expected use cases is often one of the first steps in defining your driving simulator systems. But it does not end there. New use cases and available technologies will continue to emerge, and your DIL simulators need to be robust and modular enough to remain compatible with these moving targets.
As with any engineering tool, it is important to delineate R&D activities from defined and stable procedures. In addition, DIL simulations, by definition, always include the human element, since a real driver participates in the simulations. Sometimes, seemingly complex engineering mysteries can be solved by recognizing that drivers are, in fact, unable to discern the causes of their virtual experiences, so subjective feedback must always be correctly interpreted in light of the technology in play.
In a previous article we examined the costs and ROI benefits of driving simulators, and proposed that one of the cornerstones for ROI realization with DIL simulators is the ability to add measurable margin to a vehicle development program – Margin that can then be used in a number of ways. Another possibility comes by allowing DIL simulation use cases to organically emerge. For example, we had one customer who discovered that their simulator could be used to assess a set of outward visibility criteria. This is certainly “outside the box” of traditional use cases, but the efficiency gains were simply too big to ignore.
Most companies have dedicated IT groups that oversee computer hardware and software licensing. Just as would be the case with a real time Hardware-in-the-Loop (HIL) system such as dSPACE or Opal-RT, or a computer controlled machine tool, DIL simulators should be regarded as a special case for which some special internal working practices may be required. For example, you may wish to have a typical networked, firewalled PC serve your simulator in a gateway capacity, delivering data and information to and from your servers and the DIL simulator system. In such cases, you and your IT specialists will need to act as stewards to preserve the computation systems on the other side of that gateway, within the DIL simulator itself, such that real-time communications are not corrupted.
Internally, you may have multiple DIL simulators to serve multiple functional groups or specific tasks. These simulators may be small scale (stationary desktop form factors) or large scale (dynamic full-size form factors), and they might be deployed in various locations at a single site, or positioned around the world. Fundamentally, you will probably wish to have some measure of compatibility for data exchange, model sharing, and experimentation protocols. Achieving this requires using DIL simulators with a common architecture, rather than individual “DIL silos,” such as the satellite simulator network discussed in the previous article titled, Use Cases for Automotive Driving Simulators.
Externally, you may need to communicate with supplier-provided vehicle subsystems and/or models, real-time software applications, devices, and data systems. This requires an inversion of the one-size-fits-all solution that is offered by most driving simulator suppliers. While a commoditised driving simulator might seem appealing at first glance - in terms of ease of specification, etc. – this approach typically becomes limited by its own design. For example, such offerings typically mandate the use of a particular vehicle physics, image generation pipeline, or communication architecture. The inversion is this: Working successfully with external systems requires a bespoke driving simulator wrapper with industry standard underpinnings.
As with any other tool, ultimately the degree of success depends on the people interacting with it. In this age of specialisation, it is not a stretch to imagine assigning dedicated operational staff to a test lab or a DIL simulator lab. With a full-size dynamic DIL simulator, there may even be a natural development over time towards sub-system specialties. The key aspect from a management perspective is to groom and support an operational staff that can put your DIL simulators into use as practical tools, as a means to an end, rather than as a distraction from the tasks at hand. Of course, you’ll need a good DIL simulator supplier as well. You need a supplier who can deliver a functional, capable solution rather than a science project. And you’ll want training and the correct level of continued support. I suppose it goes without saying, but I will say it anyway: Ansible Motion would love to help you!
To learn more about how DIL simulator technology is becoming an invaluable part of modern vehicle development, download our FREE eBook, Looking down the road: Harnessing the benefits of driving simulator technology.