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. 

As on-board vehicle control systems continue to advance, the behind-the-scenes validation strategies required to develop them must advance as well.  New innovations in connectivity and automation require that OEMs and Tier-1s devise new test methods to verify proposed systems for both function and safety.

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.

During on-board systems development programs, it is sometimes necessary to connect real sensor hardware to simulated environments, allowing information exchange to/from virtual worlds. This is classic Hardware-in-the-Loop (HIL) testing. Since virtual environments can be scripted and modified explicitly and efficiently, the advantages are self-evident. But this type of work only confirms sensor function in the context of the scripted experiments.

In many cases, vehicle development engineers may need to ask deeper, system-level questions. For example, a development engineering team might wish to understand how all the available information from a particular sensor suite might be used. In such cases, it becomes a game of “what-ifs,” and suddenly the HIL simulation task may actually become quite daunting.

Over the last several years we’ve compiled something akin to a list of Frequently Asked Questions (FAQs) related to driving simulator technology.  And I’ve long thought that it would be interesting to share these FAQs, maybe one or two at a time, in a series of articles. 

But as I began to compile the notes for these articles, an interesting pattern emerged:  I realized that many of the questions in our FAQ list are, well…rather oblique.  I started to wonder if the questions themselves might be tethered to certain preconceived notions about driving simulators.  What to do?

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 an age when so many vehicle sub-systems and components can be verified and signed off virtually – via off-line computer modeling, virtual test driving in Driver-in-the-Loop (DIL) simulators, and so on – it’s ironic that the one component that arguably has the biggest impact on overall vehicle performance continues to remain just out of reach for computational analysists: The tire.