Two major, undesirable costs that can occur in a compressed vehicle development cycle are the result of: (i) Correcting problems that were not caught until late in the development cycle, and (ii) Failing to catch problems at all before they are introduced into the marketplace. The best case in these situations is that an OEM receives complaints in the field that result in warranty claims; the worst is a product recall. The old advice of never buying a car in the first year of a new model release (delay purchase until the bugs have been ironed out), is still followed by many. Such buyer uncertainty can be amplified nowadays due to the complexity of vehicle systems that are now in play.
Computer scientist, Alan Kay, famously quipped that, “Technology is anything that wasn’t around when you were born.” If this is true, then the dream of autonomous vehicles (AVs) is old enough to be classified as an ancestral memory. A few examples: Radio-controlled automobiles? 1926 (Houdina and Phantom Auto); Safer highways built for autonomous car transit? 1950s (multiple entities; see the below film as one example from GM); Radar-based collision avoidance systems? 1959 (Cadillac Cyclone).
In the rush to innovate, include complex on-board systems into vehicle programs, and conduct the required virtual sign-offs for such systems, vehicle constructors are naturally keen to integrate real-time sensor (software) models into their vehicle simulation programs.
Unfortunately, most sellers of silicon – suppliers of sensors and complete ECUs and anything in-between – do not typically have ready-to-go, Software-in-the-Loop (SIL) models that allow inclusion of their offerings inside vehicle physics simulation environments.
Historically speaking, driving simulators have always attempted to connect real people with imaginary vehicles. The fundamental principle is not new. But the technology used to make this happen is certainly a moving target.
Over the last thirty years or so, driving simulators have taken on many, many forms – everything from small-scale gaming / entertainment systems, to the large-scale systems used by vehicle manufacturers for their product research and development activities. These days, anyone brave enough to type the words ‘driving simulator’ into an internet search engine will still be bombarded with all sorts of possibilities, simulators with wildly different form factors, features, and price tags. It’s easy to imagine that anyone seeking to learn about driving simulator technology might become confused by all these possibilities.
In the spirit of continuing on with our ‘driving simulator myths series’ (see Part 1 for the previous installment), I can’t help but comment on a puzzling trend: Hexapod-based driving simulators continue to be deployed despite the body of evidence that their time has come and gone.
Some might assert that autonomous personal vehicles are being developed to improve safety, reduce fuel consumption, decrease urban infrastructure strains, and so on. But let’s be honest: One of the key economic “drives” for this technology, no pun intended, is related to the prospect that people will have new time windows in their days in which to consume visual media. However, due to some fundamental aspects of human physiology, this lucrative ambition may prove to be more difficult to implement than imagined.
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.
Side-stepping entertainment applications, automotive driving simulators have historically been purposed almost exclusively towards human behavioral studies – and to good end. Inside the safe, controlled confines of a driving simulator lab, researchers can, for example, assess a driver’s performance while impaired from alcohol consumption, or explore the implications of driver distraction.
Laboratories such as NHTSA’s National Advanced Driving Simulator (NADS) at the University of Iowa in the USA have been used for countless studies that have directly contributed to improvements in highway safety. Furthermore, some automotive manufacturers use driving simulators to observe and/or survey typical drivers’ interactions with infotainment systems and ADAS interventions.
These are still the early days for the human-machine interfaces (HMI) that will be crucial to the success of autonomous vehicles. And it’s unclear whether cross-industry standards will emerge regarding the application of autonomous technologies – not just in terms of functionality, but in the way that conceptual HMIs convey functionality to drivers / occupants.
A racing driver sits at the ready before the start of a qualifying session or race. Gripping the steering wheel, he looks straight ahead, then into each mirror, wondering, “Is this real or virtual?”
A decade ago, such a question would not have even occurred to a driver. At that time the distinction was self-evident: You were either sitting in a real car at a real race track, or sitting in a driving simulator, or playing a video game – and it was blindingly obvious which was which.
Nowadays, the fidelity of Driver-in-the-Loop (DIL) driving simulators and video games has increased to the point where the line has been blurred. In some cases a driver’s senses may not be able to clearly distinguish the various realms.
