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.
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.
In case you've happened to miss it, advances in computer graphics have elevated video gaming to a whole new level of realism in recent years. Witness iRacing and rFactor as two of many examples of the new level of "ultra-realism." If we make the assertion that games can be classified as a type of simulation, vehicle engineers might be left to wonder if the gamers are somehow winning the race, figuratively speaking. There is no need to worry.
Thanks to new LIDAR scanning technologies and sophisticated scene and surface rendering offerings from entities such as rFpro (not to be confused with rFactor), the capability already exists to realistically recreate geo-specific locations that are applicable to the engineering-class virtual test drive world – the world that is of interest to carmakers.
