Autonomous Systems on a Leash

A precisely defined operating environment is not only important for autonomous driving. The Operational Design Domain (ODD) also ensures safety for many other highly automated systems in rail transport, logistics and mobile robotics.

mask Production

The progress in the field of artificial intelligence (AI) is fast, with machine learning (ML) enabling completely new levels of automation for real systems such as machines and vehicles. This ranges from simple support for humans to the complete takeover of tasks by a system. The more tasks that were previously carried out by humans (and for which they made responsible decisions) are taken over, the greater the demands on the system. Take autonomous driving, for example: For an assistance system for distance control, where the driver constantly monitors the situation, these demands are much lower than for a fully automated system, where the driver can devote their attention to completely different things. Other examples of increasing automation range from autonomous mobile robots (AMRs) to driverless trains and autonomous ships.

Operational design domain determines
deployment scenario

When it comes to highly automated systems, most of the attention in the public debate is often focused on the degree of automation employed. In other words, which tasks no longer require human input? However, it is also crucial to consider the situation in which the system can take over. The situation or environment in which an automated system operates plays a decisive role. In the example above, this means, for instance: Can I only use the automation function on the highway or everywhere? Do I need a fully monitored and isolated route for a driverless train or can it run in unrestricted environments?

Operational Design Domain (ODD)

ODD is a set of operating conditions, including all entities relevant, in which a given AI system, or feature thereof, is specifically designed to function (generalized from SAE J3016).

The description of a specific operating environment is referred to as an Operational Design Domain (ODD). This ODD contains all important operating conditions for the dependable execution[1] of a function or system. These can include, for example, the presence or absence of certain objects, as well as system restrictions, other actors or special environmental conditions. In the case of autonomous driving, for example, this may mean that only certain speeds, weather or traffic conditions are supported. For AMRs, this may include the absence of people in the work area, hazardous substances or other machines.

ODD sets boundaries for AI

Up to now, this approach has mainly been used for Automated Driving Systems (ADS) in the automotive sector. However, it can also be applied to other areas such as rail transportation, mobile robotics or logistics. In addition, the explicit definition of the operating environment can also be considered very important - if not absolutely necessary - for all types of AI systems. The reasoning for this is that in less restricted environments, the systems - and therefore usually also the AI - have to navigate many different contexts. The more open the operating environment is, the more uncertainties and possibly unexpected situations can arise. However, if the operating conditions can be narrowed down, then it is easier to ensure that all relevant aspects can be handled safely by the AI system. The AI system is kept on a leash, so to speak.

The explicit description of the ODD can be decisive here. It specifies the operating conditions under which the automated system should function, i.e., which environment the system should be able to handle. ML is data-driven, meaning that it is based on what has already been seen and learned. Thus, if the data is sufficiently representative of the operating environment, this helps to ensure that no important aspects are overlooked.

Blogbeitrag Automatisierung ODD Picture EN

Picture 1 Schematic comparison between operating condition restrictions as ODD and possible degrees of automation

The comparison between the two dimensions – degree of automation and complexity of the ODD – is particularly revealing (see Figure 1), as it shows which types of automated systems can already be implemented (see green area). Even when the ODD is severely restricted, highly automated solutions are still possible today. Examples of this are driverless subway trains or robots with safety cages. In very open environments, on the other hand, only lower levels of automation are generally possible, e.g., automated driving on public roads (which must be monitored by humans) or very slow surveillance robots in public spaces. Oftentimes, systems that fall somewhere between these two extremes are implemented. This includes, for example, semi-automated freeway assistants that can only be used under certain road conditions and speeds[2], assistance features for monitoring heavy construction machinery, and automated aircraft systems that are only used for take-off/landing.

Would you like to learn more about ODDs for autonomous systems?

Then please get in touch with us – we will be happy to help you.

Contact Pfeil nach rechts

At the Fraunhofer Institute for Cognitive Systems IKS, researchers are working on numerous industrial projects to find out exactly how autonomous systems can be put into practice, taking into account both the desired degree of automation and potential ODD limitations. A key point to remember is that the concept of ODD is central to the development of autonomous systems, as it helps to achieve higher levels of automation in a safe and reliable way. Many new solutions for rail vehicles, AMRs or vehicles for industrial partners have already been successfully developed in this way. Please feel free to contact us – we are happy to help you solve your challenges and further tap into your automation potential.

[1] Scientific paper on safety arguments based on an ODD:

[2] Example Mercedes Drive Pilot:

Read next

Showcasing Cutting-Edge Automation at Fraunhofer IKS

Alex da silva photo
Alexandre Sawczuk da Silva
Safety engineering / Fraunhofer IKS
Safety engineering