The ADAS/AD challenge

Technological drivers behind automated driving

New technologies such as electrification, connectivity and automation are the driving forces behind the transformation ongoing in the mobility sector. Vehicles of the future will be driven by computers with the knowledge of other cars and even the cloud - instead of only a single human driver.

Automotive engineers face the task of addressing complex technical challenges related to safety and validation of open-world problems when it comes to automated driving in the real world.

Levels of automation and their classification

Driver Assistance (DA) and Autonomous Driving (AD) systems can be divided into five levels:

Level 1 - Assisted driving

The system has some control or influence on longitudinal direction (braking/acceleration) or lateral direction (steering) of the vehicle, but the driver remains in control at all times.

Level 2 - Partial automation

The system can control both direction and speed without driver influence however the driver must be capable of resuming control at a moments notice.

Level 3 - Highly automated driving

The driver has no direct influence on direction or speed and is only expected to be able to resume control after a defined period of time to regain situational awareness.

Level 4 - Fully automated driving

The system handles all tasks (for specific use-cases only) and the driver is not expected to be able to intervene.

Level 5 - Full autonomy

The system handles all tasks for all use-cases and the “driver” is possibly not even capable of intervening.

Step-change of safety levels from assistance to automation

The transition from assisted to automated driving releaves the driver but increases the functional and safety related requirements to the system since the driver can no longer be considered as a backup layer in the overall system concept. The technical system needs to be evolved from a "fail-safe" approach to a "fail-operational" approach when changing from a Level 2 to a Level 3 automation. This means the system must continue to operate even in the occurance of a failure.

Higher safety levels lead to increased system complexity and increased system performance

For each level the system takes over more responsibility for the vehicle dynamics and as a consequence the driver load reduces. As the level increases the complexity of the system increases (with big jumps for Level 3, 4 and 5) and the required system performance (CPU, memory, etc.) increases similarly.

Shortcoming of traditional methods

The traditional way of validating an automotive system before official road release and hence providing the evidence for its correct behavior and safety is done by extensive real system testing, e.g., seeing how the software behaves when exposed to different scenarios. This is already a high effort for regular driving scenarios, but also (very) rare events need to be considered before the road release. Even if the probability for such "rare" events is low, the law of big numbers leads to numerous occurrences over the time and across the vehicle fleet. Even for a 1 in a million event we can expect it to happen many times a day in the US alone.

Rare events are rare for an individual, but a tester would be unlikely to encounter such an event on a tough test drive and even less likely to be able to encounter it on demand. Therefore, testing-by-driving is not how the required level of confidence regarding safe functionality can be reached for automated driving systems.

This challenge regarding an environment which is hardly constrained by a well-defined set of requirements is called the "Open World problem" which is very specific to the automated driving domain and which requires complete new approaches. By definition testing can only “see” the most common events in the environment and is very unlikely to be exposed to the very real but also very rare events. These events could be uncommon, they could be environmental conditions that confuse sensors, or perhaps a crash by surrounding vehicles but these “corner cases” do happen and they do affect the level of disengagement of automated driving software.

What is needed for successful validation is a way to capture these rare events and then to explore the automated driving software using "virtual testing". Only through this, automotive safety standards such as ISO PAS21448 (SOTIF) can be fulfilled for automated driving functions where no safety driver is engaged.

What is needed to master the ADAS/AD challenge

Mastering system complexity, safety, and performance is a critical aspect of ADAS/AD development. In order to meet the requirements for disengagement metrics, it is necessary to handle rare and difficult-to-test scenarios. These scenarios arise because ADAS is an open-world problem, which means that the software must work with incomplete knowledge about the world and collect information as it is discovered.

The validation of open-world problems is challenging because the problem space is much larger than any test set can cover. Therefore, the ADAS middleware platform must support advanced technologies that enable validation evidence to be collected and applied to new software developments.

These technologies must be able to capture scenarios in real-time and replay them with high fidelity, creating a chain of reproducibility from the real world into a virtual world. Only this capability makes simulation based testing or validations an acceptable replacement for real world testing.

The ETAS Deterministic Middleware Solution comprises several mechanisms to establish and maintain this chain of reproducibility, ensuring that the ADAS system is developed and validated with the highest level of accuracy and reliability.