Ensuring safety in Autonomous Driving Systems (ADS) as they transition between different Operational Design Domains (ODDs) is both challenging and crucial. In our research projects, we found that there are no established methods out there for modeling, analyzing, and documenting ODDs in a suitable manner for safety engineering processes. Even worse, no guidance is available to pick the right level of granularity and detail when crafting an ODD, which should be helpful for engineers as input for specific analysis or design activities. Our research introduces a novel concept and metamodel designed to support cross-domain safety analysis and ODD change management. This approach facilitates the expansion of ODDs and reduces the effort required to assure system safety in new environments. By integrating safety engineering with environment models, our method provides a structured framework that enhances safety assurance and efficiency.
Why do you need support for ODD change management?
The need for robust ODD change management arises from several use cases:
1) Start with a small ODD and expand it over time
You start with a small ODD to constrain the initial risk and deploy your service as soon as possible. Over time you want to increase the ODD and with that gain access to new customers, expand your service, and create more value.
2) Deploy your system in a different area
You are a company that operates globally, and you would like to deploy your system in a new geographical area. For example, your system is assured for ODDs in Japan, and now you want to bring it into the European market, where the operational environment may share many aspects, but there are new aspects to consider, too.
3) Transfer an existing system into a different domain
You may also operate in different application domains, and you have a system that is assured for one specific domain only. For instance, you have an automated driving system, which was built for automated goods transport in logistics warehouses, where the normative and regulatory context from the machinery domain is relevant. Let’s say, you want to deploy that same system for operation on public roads, maybe because the system should transport goods from one warehouse to another place nearby. Suddenly, the normative and regulatory context for safety assurance on public roads is relevant and consequently, the requirements for ODD documentation and analysis differ.
In all these cases, you already have a certain foundation, and you have assured your system by following an expensive safety engineering process. Instead of starting all over again, a more sophisticated method for detecting the impact of these scenarios to minimize the rework to the necessary minimum would be ideal. This is the goal we are working towards in our ODD-related research at Fraunhofer IESE: Create operational environment representations, which…
- are traceable to the safety engineering artifacts, in which environmental dependencies exist. The underlying goal is to provide support for efficiently managing frequent changes or ODD expansions through formal traceability.
- are meaningful inputs for different safety engineering activities such as HARA, SOTIF triggering condition analysis, validation scenario design, or approval. In these activities, different aspects of the environment as well as different degrees of detail and granularity are required. We are working on methods for task-specific environment ontology tailoring using base taxonomies like ISO 34503 to achieve this goal.
In summary, it is important to understand the relationships between safety engineering artifacts and the operational environment. This understanding is a precondition for providing methodological guidance on how to manage changes in your ODD, such as those in the outlined scenarios.
More About our Research involving the ODD
Regarding methodological support to create fit-for-the-purpose operational environment models with guiding questions for engineers, we published a poster at the PEGASUS VVM final event. In addition, we found that Large Language Models can accelerate the situation space exploration process in HARA analyses specifically.
- Guideword-based ODD tailoring: Towards making ODD descriptions processable for different stakeholders
- Safety-aware Operational Environment Analysis How tailored ontologies of the operational environment can support safety engineering
- LLM-Augmented Hazard Analysis and Risk Assessment (HARA): Human-AI collaboration framework for efficient HARA
- LLM-Augmented Safety-Security Engineering: HARA and TARA support with LLM-augmented tooling
- ODD Change impact analysis: Metamodel and concept to support change impact analysis for cross-domain safety engineering
- LLM-Human Co-Engineering: Increase efficiency of Safety Engineering Processes (HARA)
ODD Change Management: What do you need for your change impact analysis?
First and foremost, the operational domain, but also the safety engineering artifacts and their dependencies, must be modeled. This requires a process and a technical representation to model the environment. Furthermore, we need to have a concept to compare elements semantically. Last, we require the integration into a tool to automate these processes.
In this blog post, we focus on the modeling aspects. In a future blog post, we will present a method to systematically analyze the environment.
Concept and Metamodel
Our research introduces a comprehensive model-based method integrating safety engineering artifacts with environment models. This integration is achieved through a structured metamodel that links context elements to safety requirements, thus facilitating systematic safety analysis.
The core of this approach lies in using domain abstraction models, inspired by the PEGASUS 6-layer model, which allows for comparing different ODDs through shared abstract concepts. For example, the abstract concept of “Humans at Risk” can be applied across various environments, helping to identify and assure safety requirements consistently. This conceptual framework not only supports the identification of relevant safety artifacts but also aids in managing the dependencies and changes within complex ODDs, making the safety analysis process more efficient and reliable.
The technical prototype we implemented
Based on the existing technical model-based safety engineering framework
Our method is seamlessly integrated with the Digital Dependability Identity (DDI) framework, which includes the Open Dependability Exchange (ODE) metamodel. This integration allows for a comprehensive representation and analysis of safety engineering artifacts throughout the ADS life-cycle. We aimed at being compatible with technical standardization efforts like OpenODD and DIN SPEC 99004, to which we contribute our experiences in person, too.
Traceability analysis and model transformation via automation
Additionally, we have implemented an automated change impact analysis algorithm using the Eclipse Epsilon framework. This algorithm helps identify relevant context elements and safety requirements that need attention when expanding or changing an ODD. By automating these checks, we reduce the need for manual reanalysis and ensure systematic coverage of safety concerns, thus enhancing the efficiency and accuracy of the safety assurance process.
Are you ready to improve the creation and analysis of the operational environment impact on your system?
We tested and refined our approaches in public-funded and bilateral projects with industry customers in the automotive and machinery domain, specifically for automated driving systems and autonomous mobile robots. Apart from the methodological expertise, we built up various technical assets to support the transfer to industry. First, we have technical representations of various environment ontologies like VDA 702 SitKat, ISO 34503, or the PEGASUS 6-layer model. Based on these ontologies, concrete environment models can be derived for a specific system or function. Our in-house model-based safety engineering tool safeTbox enables linking safety engineering artifacts such as basic events in component fault trees or HARA situations formally to elements in the environment models. In this way, it is for instance possible to determine the coverage of the operational environment in HARA or SOTIF analyzes – thanks to a fit-for-the-purpose tailored environment model for the specific system and safety process.
Based on these assets, we can support your team with the following value propositions:
Knowledge Transfer “State-of-the-art complex environment modeling and analysis”: We transfer state-of-the-art knowledge about modeling, analyzing, and documenting operational environments / ODDs to your engineers in a seminar/workshop format and enable them to perform safety analyses with high coverage and confidence despite the environmental complexity.
Method Transfer “ODD creation”: We enable your engineers to create standard-compliant ODD representations (SOTIF, ISO 34503), which do not only enable “ticking the ODD box”, but are meaningful inputs for the safety and SOTIF analyzes requiring the environment as inputs. A common mode of collaboration is the application of the method on an existing example system, which is well enough understood so that the focus can rest on the new method aspects. The method transfer happens primarily through the discussions between experts from your company and IESE, when the method is applied by your experts based on instructions and templates from IESE.
Service “ODD creation/review”: We support the operative creation of ODD artifacts in your concrete project or review your already existent ODD documentation for alignment with state-of-the-art and state of the practice.
Service / Method Transfer “Environment Ontology Tailoring”: You want to operate your system in a unique/non-standard operational environment, which is not covered sufficiently by existing taxonomies/ontologies? We can support this with our systematic approach to interviewing domain experts, resulting in a tailored environment ontology, which can be used as a basis for coverage argumentation in your HARA and safety analyses.