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.

Self-driving cars are the new black. Every OEM and major tech company is taking on the autonomous challenge, and the competition is fierce. 

As an OEM or Tier 1 supplier, the landscape is rife with offerings, software tools that are aimed at assisting all areas of autonomous vehicle development and validation, many of them pioneering grabs at what is promising to be the Wild West of automotive engineering in the coming years.  And yes, some of these tools are either direct or indirect products of the gaming industry. 

If anyone asked the question, “Would you trust your autonomous vehicle validation to a game?” most of us would cringe a little.  But such questions are actually not too far off the mark these days. 

Customer race cars are a growing market for major automotive manufacturers. GT3 racing in particular continues to attract new manufacturers. Lexus (RC F), Acura (NSX) and Mercedes-AMG (GT) are joining the competitive IMSA GT Daytona class here in 2017. Ford meanwhile is the latest company to join GT4 competition on both sides of the Atlantic, having unveiled the Mustang GT4 at the SEMA show in November.