Advanced Driver Assistance Systems (ADAS) implementations are on the rise as vehicle manufacturers continue to introduce greater levels of supplemental control into the driving experience, with greater safety and convenience as the goals.
Early testing in a digital environment is just as applicable to ADAS development as it is to everything else on board – perhaps even more so. Consider the case of introducing a new ADAS function such as a lane departure warning system. The system may be unfamiliar to drivers, thus making their reactions harder to predict. It is certainly desirable to connect real drivers with such a system as early as possible. How can this be achieved?Many current ADAS developments make use of offline Software-in-the-Loop (SIL) simulations to run through myriad sensor calculations, ECU settings, and scripted scenarios. This creates evaluation subsets for later confirmation with Hardware-in-the-Loop (HIL), and/or focused prototype vehicle testing with real drivers. Other development programs rely on securing time with prototype vehicles and testing as much as possible in the time available, without relying on SIL, HIL or other off-line simulations, in order to catch any issues. For complex system deployments, the first case is usually more desirable than the second.
For offline SIL and HIL simulations, automotive engineers have traditionally employed ‘scenario tools.’ This class of software tools (there are many commercial offerings) does an excellent job of modeling sensors and surroundings via object, traffic, roadway, and scene libraries, enabling engineers to review thousands of possible settings in large numbers of scripted scenarios.
But what about Driver-in-the-Loop simulation?
Sometimes scenario tools are connected to simplified DIL simulators in an effort to demonstrate ADAS systems to real drivers. However, such simulators are not particularly useful as core product (vehicle) development tools outside a few niche areas, since they are not compelling for experienced test drivers and expert vehicle evaluators. However, they can be acceptable concept demonstrators for common driver surveys or at technology showcase events such as trade shows.
A fundamental limitation is that most scenario tools have animation style graphics that are not designed to be rendered with low latency. Latency being the time delay from graphics demand to realization. An example of high latency graphics is a “live” broadcast of a television program, wherein you are watching a smooth stream of visual information – but with, say, six seconds of latency, since the information is purposefully delayed from event occurrence in order to oblige content censors. In a proper DIL simulator, nothing is delayed on purpose, but delays do exist in the software, hardware, and architecture. Delays in simplified DIL simulators – usually on the order of tens or hundreds of milliseconds - may be fine for some SIL (or real) sensors and certain ADAS system verifications, but the human eye is a tougher customer.
Breaking the barrier
In brief, there is a recognized barrier for the use of scenario tools in vehicle dynamics class DIL simulators where photo-realistic, low latency graphics are prerequisites for driver immersion and subjective driver evaluations. The good news is that Ansible Motion’s DIL architecture allows that barrier to be broken.
Beyond the barrier, expert and novice drivers alike are able to experience how ADAS systems perform in immersive virtual driving scenarios, long before the first vehicle prototype is built. Unexpected interactions between human drivers and ADAS controls – e.g. What happens when a driver overrides a brake application? – can be exposed early on, when fixes are faster, cheaper and far less likely to impact program delivery deadlines.
To learn more about how vehicle dynamics class DIL simulators can include evaluation of on-board electronic systems like ADAS systems, download our FREE eBook, Looking down the road: Harnessing the benefits of driving simulator technology:
