The Operational Design Domain (ODD) precisely defines the area in which automated driving functions may be used. As such, they represent a fundamental prerequisite for safe automated driving. Part 1 of a three-part series on the importance of ODD.
October 13, 2022
© iStock/Eerik
An automated driving system (ADS) enables a vehicle to perform a sustained Dynamic Driving Task (DDT). The hardware and software components of an ADS collectively automate the driving task through implementation of various ADS features. Autonomous Driving, however, refers to a driving system capable of performing all its functions independently and self-sufficiently.
The SAE J3016 standard provides a clear definition of levels of autonomy to differentiate the automated driving capabilities from the autonomous. From Level 1-2, the driving automation system provides features capable of providing driver assistance, and partial driving automation respectively. As for the levels 3-5, range from a conditional driving automation - requiring fallback ready driver, to full driving automation-without the need for any driver.
A vehicle equipped with an ADS may be able to deploy multiple features operating at different levels of autonomy. It is important to note that every ADS feature must fulfill a usage specification indicating its level of automation and the designated Operational Design Domain (ODD). Thus, accurately describing an ADS feature requires specifying both, its level of automation and the supported ODD.
An ADS feature, e.g., Autopark, satisfying a usage specification of {Level4, geo-fenced campus} may only be deployed, without a fallback ready driver, within the geographically restricted campus-area. This geo-fenced campus constitutes the supported ODD of the Autopark Level 4 ADS feature, in which it can be safely operated.
Operational Design Domain (ODD) remains a key aspect in assuring the safety of an ADS. It provides knowledge about the ADS capabilities and limitations for a set of pre-defined operating conditions.
PAS1883 standard provides a taxonomy, i.e., a vocabulary of terms and conditions which could be used for a defining an ODD specification. At the top-level, they categorize ODD specification attributes into – scenery, environmental conditions, and dynamic elements. An ADS operation (i.e., ADS-feature deployment) is considered unsafe, if it is operating in conditions not satisfying its supported ODD. In other words: it is operating outside ODD.
In the second part of this series, we will look at the safety implications of transitioning through multiple ODDs while executing the Dynamic Driving Task (DDT).
It is paramount that the actual operating conditions i.e., Operational Domain (OD) be accurately detected during ADS operation. The OD must be continuously checked against an ODD specification to ascertain if the ADS is operating outside its designated ODD and trigger an ODD-exit event. An ODD-exit, when reliably detected, can be safely handled by a pre-defined DDT Fallback task.
Here is an example: When a vehicle moves outside the ODD for a particular automated driving function, it must move to a nearby roadside parking lot and wait for further instructions.
So much for today. What the structured, machine-readable specification of an ODD is all about, you can read in the next part of this blog series.
