What is an ODM, and Why Do We Care From a Safety Perspective?

Introduction

One of the significant challenges of assuring the safety of Robotics and Autonomous Systems (RAS) concerns the interactions between the RAS and its environment (including variables such as the expected weather conditions, light levels, users, other actors, and the built environment etc.). Each interaction could manifest in a novel/unanticipated situation, and these interactions may require an appropriate action to be taken by the RAS. The use and efficacy of an Operational Domain Model forms a significant portion of our current research, and the aim of this article is to garner early feedback on the concept and to provide a research update of all things RAS!

ODDs

The automotive industry (and increasingly the air sector, too) refer to the description of these foreseen interactions, and the boundary of safe operation therein as an Operational Design Domain (ODD)…or at least that’s what SOME versions of an ODD do. Which is one of the issues.  To some authors it is a declaration of safety operating boundaries, to others it is an ontology of actors, to others it is a taxonomy and syntax, and I have also found it to describe the safe operating context and associated safety requirements. Many include all of this and more.

We all kind of know what we mean…sort of…just not very specifically. Not only is the safety research community not particularly clear what should be in it, but we’re also somewhat vague about what should NOT be in it, nor how we should use it (from a safety assurance perspective).

Operational Domain Model

In our work developing a suite of autonomous robots for one of our new university buildings, we have referred to this amorphous blob of a ‘model’ as an Operational Domain Model (ODM):

• Operational: What will the RAS encounter (i.e. static objects, dynamic objects, furniture and furnishings etc.)?
• Domain: Where will the RAS operate (i.e. within the confines of our new building)?
• Model: The pictorial representation of the boundaries between the ODM and a Reduced Operating Model (ROM), and that of unsafe (autonomous) operation.

What should be in an ODM?

For an ODM to be of benefit from a safety assurance perspective, it must be usable (of material benefit to safety analyses), efficient (only contain what is relevant) and valid (accurate and ‘complete’).

To support usability, it must contain relevant data against which safety analyses can be carried out, including but not (yet) limited to:

• Scope of Operation:
  • Environment
  • Operating Conditions
  • Operating Location
  • Assumptions
  • Actors
  • Use Cases
  • Exception Cases
• …all of which determine the Scenarios (some of which may be potentially hazardous) that may be encountered by the RAS as it interacts with its environment.

This information enables the definition of the Safe Operating Context (SOC), which is given by the following form

SOC = <ODM> + <Operating Scenarios>

The specific contents of the ODM will vary with individual circumstances and applications, but when considering the holistic approach to the careful management of an ODM, there are two main options:

1. Aim to identify and classify every conceivable object in the entire operating environment (domain) from the outset
2. Aim to identify a reasonable boundary and argue what is deemed ‘outside’ of normal (safe) operation.

Our current research finds us leaning heavily toward the latter option, and to explain the rationale for this, consider even the tightly bound and controllable environment of a typical office environment.  For Option 1 we would need to consider (and train algorithms for) the detection and classification of every object in terms of its:

• Ability to dynamically move under its own volition
• Size
• Shape (to illustrate this consider every type of conceivable chair, or desk)
• Colour (white cardboard box)
• Material (brown cardboard)
• Contrast to its surroundings
• Etc.

Whereas it may be perfectly acceptable (and safe) to mainly detect an object (without necessarily understanding its classification).

However, by selecting Option 2, we are faced with the conundrum of the size and range of test coverage…but some of this coverage could be mitigated through ‘Stress Testing’ perhaps (although we must be careful not to put every conceivable instance into a bin marked ‘test for this’).  As such, Option 2 requires an approach that starts with an abstract safe concept (such as ‘detect all objects above dimensions x, y, z within a distance of x metres from the RAS) which is further refined and decomposed as the design of the RAS matures.

Initial analysis of our robot development suggests that the management of the ODM approach should be iterative, concurrent with the development of the Autonomous System (AS), and iterated as technology options are down-selected.  This last point is key.  As but one example, consider an ODM in which the initial version has defined the safe operating context and autonomous capabilities for each scenario.  The selection of a particular technology (say a type of sensor) may challenge the boundaries of the initial ODM should the selected technology be incapable of performing certain tasks under certain conditions.  Examples of this could be the inability of infrared sensors to see through fog, or the inability of an optical sensor to detect transparent material.  In such cases, either the design needs to change (i.e. the addition of additional, diverse sensors), or the boundaries of operation need to be limited.

The point at which the AS crosses/nears the defined safety boundary is referred to as entering/approaching the Reduced Operating Domain (ROD) – and the ‘size’ and ‘shape’ of the boundary between ODM and ROD may shift owing to, for example, inherent weaknesses in the selected technology.

When Should an ODM be delivered?

The concept that an ODM is created at the outset and delivered in a ‘fire and forget’ manner must be dismissed out of hand.  An initial ODM will need to be created at the outset of a project and will (by virtue of the immaturity of the project) contain little data as to any specifics of fulfilling a SOC.  Regardless of the ODM approach selected (the options noted above), we are resolute and steadfast that the ODM (and even an ODD) should be carefully managed, and updated iteratively and recursively in line with the increasing maturity of the system design.

At the end of this research project, we will present a reasoned approach to ODMs, and assert what:

• Constitutes an ODM
• Should be in an ODM
• Should be kept out of an ODM
• The purpose of an ODM is
• …and how safety engineers should use it.

So watch this space (as ever).  How do you find the concept of an ODM or even an ODD – what would you argue is its purpose (and contents)?