Define and validate the Operational Domain Model (ODM)
The Operational Domain Model (ODM) defines the scope of the operation of an AS within which the AS can be demonstrated to be acceptably safe when carrying out its autonomous capability. When AS are developed and put into operation it is based on assumptions made about when, where, and under what conditions that AS will need to operate. The operational scope defined by those assumptions determines the scenarios that may be encountered by the AS as it interacts with its environment. It is illustrated in Figure 6 below how the ODM effectively reduces the number of possible scenarios that the AS may need to deal with when performing its autonomous capability.
Figure 6: Defining an Operational Domain Mode
The assumptions must be made explicit in the form of a defined ODM that characterises the operating domain. If the ODM is insufficiently defined then the AS may encounter scenarios during its operation that were not considered during the development of the system, and which could therefore be unsafe and for which no assurance is provided. It is crucial therefore that all relevant elements of the operating domain, including those with with the AS may interact are included within the ODM. In identifying relevant elements of the ODM it is important that “non‐mission interactions” are also considered [18].
Example 3 - Autonomous cars Automotive
For autonomous cars, the term Operational Design Domain (ODD) [23] is often used to refer to the ODM. A number of approaches to defining the ODD for an autonomous car have been proposed. NHTSA [45] defined and categorised an ODD taxonomy based on a review of over 50 sources of literature in automotive and other domains. The taxonomy is intended to be descriptive, recognising that other organisations of the elements are possible. The report provides a set of sample baseline ODDs for different automated driving features or capabilities, such as those shown in Figure 7 below for an Automated Highway Drive (HWD) function.
Note that the examples in Figure 7 are used to define what is asserted as being within the ODM for that particular capability (function). If the operation of the vehicle is outside of this definition then the safety of that capability is no longer assured. We return to the issue of operation outside of the defined operating context at Stage 2.
Figure 7: Example baseline ODD for HWD function (from [45])
Note 3 - Challenges when defining an ODM
One of the major challenges when defining an ODM can be identifying an appropriate level of detail at which to specify elements of the ODM. If elements are not specified with sufficient granularity then important differences in the features that may impact safety may be missed. On the other hand, too much granularity can make any analysis based on the ODM intractable due to the high number of element combinations.
It may be necessary to revisit the granularity of the ODM as a result of information learned from other activities; for example, it may be informed by the nature of the relevant operating scenarios identified at Activity 3.
Example 4 - Office environment
In the ODM for an autonomous robot operating in an office environment, the ODM may include ‘walls’ or ‘doors’ as part of the model. However, relying only on ‘wall’ or ‘door’ as an element of an ODM will miss crucial attributes of walls or doors that will affect the detection capability of an AS. A wall or door made of translucent material would not be capable of detection by some technologies (e.g. LiDAR). In the ODM, the material of the walls and doors should also be specified.
Example 5 - Defining people Automotive
In the ODM for an autonomous shuttle bus operating in pedestrianised areas, the ODM must include people as part of the model. However, defining “people” as a feature of the ODM may miss crucial differences between children and adults that affect the safety of the AS operation. “Children” and “adults” should therefore be defined as separate elements of that particular ODM. The appropriate elements to choose and their granularity would be expected to differ for each ODM depending upon the particular operational context of the system.
Once created the ODM shall be validated to check that both the scope of the defined model and its level of detail are appropriate. The results of the validation activity shall be explicitly documented ([C]).
The process of defining and validating the ODM is an iterative process, and any initial ODM specification may need to be expanded or reduced based on the outputs of later process activities. This may include new information that is obtained about the design, operation, capabilities, limitations and/or potential failure conditions of the AS.
