Content uploaded by Jan Reich
Author content
All content in this area was uploaded by Jan Reich on Jul 06, 2023
Content may be subject to copyright.
Concept and metamodel to support cross-domain safety
analysis for ODD expansion of autonomous systems
Jan Reich 1, Daniel Hillen1, Joshua Frey1, Nishanth Laxman1, Takehito Ogata2,
Donato Di Paola2, Satoshi Otsuka3, Natsumi Watanabe3
1 Fraunhofer Institute for Experimental Software Engineering IESE, Kaiserslautern, Germany
2 European Research and Development Centre, Hitachi Europe
3 Research and Development Group, Hitachi, Ltd.
{firstname.surname}@iese.fraunhofer.de
{takehito.ogata, donato.di-paola}@hitachi-eu.com
{satoshi.otsuka.hk,natsumi.watanabe.jv}@hitachi.com
Abstract. Automated driving systems (ADS) can improve efficiency in logistics
and last-mile delivery, but a major challenge is ensuring safety for operational
design domain (ODD) expansion or cross-domain deployment. Various ontolo-
gies and formats exist for modeling and representing the operational environ-
ment. However, their structuring schemes are not suitable for safety engineering
activities, as the safety-relevant aspects of the environment differ from those rel-
evant for other purposes, e.g., simulation scenario representation. This paper ad-
dresses the problem of effectively supporting safety engineers in performing en-
vironmental safety analyses considering cross-domain aspects and the impact of
environmental changes. We contribute a concept for modeling and comparing
operational design domains as well as algorithms for semi-automatically analyz-
ing change impact. The approach is model-based, integrated within the Digital
Dependability Identity (DDI) framework, and has been evaluated qualitatively
for ADS cross-deployment from a logistic warehouse to urban environments. The
evaluation suggests that the approach is a suitable starting point for explicitly
linking ontological domain modeling with safety engineering. It also helps safety
engineers to think about ODDs in a structured way, performing change impact
analyses regarding specification gaps, and enabling cross-domain learning.
Keywords: SOTIF, safety assurance, autonomous system, autonomous vehicle
1 Introduction
Context. Automated driving systems (ADS) promise economic and societal benefits in
various use cases such as smart logistics warehouses, last-mile delivery, or passenger
transport services. The lack of methods for systematically analyzing the impact of a
given operational environment on ADS safety is a significant challenge to enabling the
benefits [1]. To manage operational domain complexity, manufacturers develop their
systems for a constrained environment, the operational design domain (ODD). The
2
ODD specifies “operating conditions under which a given driving automation system
or feature thereof is specifically designed to function” [2]. Thus, the ODD specifies the
context for engineering, validating and arguing the system’s safety.
In practice, manufacturers start with small controllable ODDs and gradually extend
them to more complex situation classes in line with increasing technology maturity and
experience [3]. In contrast, Tier 1 suppliers developing ADS technology are interested
in efficiently performing cross-domain deployment [4]. For instance, ADS technology
can be used both in smart logistics warehouses and urban environments to realize dif-
ferent use cases. Although there are many differences regarding the environments, there
are many common concepts with similar impacts on safety, too. To realize the two use
cases, both OEM and suppliers need efficient methods for analyzing the impact of an
extended or changed ODD on safety.
SotA deficiencies. Analyzing the impact of ODD changes on safety requires two com-
ponents: a representation of the ODD and a way to compare multiple ODD representa-
tions regarding their impact on safety artifacts. Rich ADS environment ontologies like
the 6-layer model [5], BSI PAS 1883 [6] or the ADS operational world model ontology
[7] have been proposed to inform ODD specification. In addition, ASAM OpenODD
[8] specifies a format capable of representing a defined ODD. The main focus of these
approaches is to enable ADS verification and validation, i.e. to derive validation sce-
narios covering the ODD. However, the relationship to other important safety engineer-
ing artifacts such as hazard analysis and risk assessment (HARA) or safety require-
ments is not considered. In addition, analyzing the impact of extended or changed ODD
representations on these artifacts is still an open problem. These gaps lead to the neces-
sity to research how to support safety engineers in terms of a) linking ODD representa-
tions to safety engineering artifacts and b) performing change impact analyses for
changed ODDs. Without systematic model-based approaches, it will be hardly possible
to manage changes in complex ODDs with both acceptable efficiency and adequate
confidence in the safety analyses.
Contribution. In this paper, we propose a model-based method to address the research
gaps. To that end, we introduce a metamodel that supports explicit traceability between
safety artifacts and their dependencies on an ODD representation, independent of the
environment ontology used. Cross-domain safety analysis is enabled through hierarchi-
zation and domain abstraction concepts. Based on the metamodel, an algorithm is de-
fined that enables the identification of safety artifacts and associated context elements
needing attention by safety engineers. The method has been qualitatively evaluated with
industry experts from Hitachi in a use case, where an ADS safety monitor assured for
a logistics warehouse intersection is to be cross-deployed to an urban intersection.
Paper Structure. Section 2 briefly summarizes the related work surrounding existing
models and methods for ODD specification and analysis. Section 3 introduces the con-
cepts to enable environmental safety analysis. In section 4, the formalization of the
concepts in a metamodel and a change impact analysis algorithm are explained. Section
5 describes the results of the industrial case study along with a critical discussion of the
results. Section 6 concludes the paper and highlights future research.
3
2 Related work
A common approach to modeling the operational environment is the use of ontologies
for structuring and instantiating the model. BSI PAS 1883 [6] defines a standardized
minimal set of categories and elements that should be defined in the ODD for autono-
mous vehicles. Another environment structuring approach has been proposed by
Scholtes et al. with the 6-layer model. A more detailed ontology is provided by Czar-
necki [7] which is structured like the 6-layer model but has five layers. Furthermore, a
list of elements is provided for each layer. These environment models describe the au-
tomotive environment and focus on structuring the elements for verification and vali-
dation, but they are not tailored toward safety engineering activities.
To enable practical use, ontologies and environment models must be formalized.
Two large initiatives are working on defining standardized technical formats for mod-
eling the environment. OpenODD [8] defines a language for specifying an ODD via
allowed or restricted operating conditions on top of the elements of an assumed ontol-
ogy. The OpenXOntology [9] project defines a standardized ontology for scenarios in
the automotive domain. For OpenODD, an initial proposal is publicly available and
OpenXOntology is still under development. While these formats enable engineers to
model the operational domain and its ODD subset, there is no support for explicitly
linking environment elements to other safety artifacts.
In Kemmanns’ [10] dissertation, a method is proposed for creating environment
models to support model-based hazard analysis and risk assessment in the context of
ISO 26262. A metamodel and ontologies for structuring the environment are proposed
in the OASIS framework (Ontology-based Analysis of Situation Influences on Safety).
The concepts by Kemmann are a foundation for the work presented in this paper. While
he focuses on HARA and thus on scenarios in the context of ISO 26262, our concept is
more generic as it is not restricted to functional safety artifacts only.
The approaches described above are related to safety-driven environment modeling
and do not explicitly consider ODD expansion scenarios. Gyllenhammar [11] proposed
an approach for the continuous development and management of ODDs where use
cases are connected to operating conditions. When extending the environment, new use
cases arise that are linked to operating conditions. Only if all operating conditions are
located within the ODD can the AV drive safely within the use case. Therefore, a
change impact analysis could identify whether new use cases are located within the
ODD so that operation is safe. This approach can be implemented with our concept by
linking use case-specific artifacts to environmental elements.
SotA gap summary. A variety of research provides support for environment mod-
eling of verification and validation activities, such as describing scenarios for simula-
tion. However, these models are not yet sufficiently connected and tailored for safety
activities. While creating environment ontologies is an important contribution, only
their formal connection to safety engineering processes will solve the broader challenge
of safe ODD change management. These gaps lead to the necessity to research how to
support safety engineers in terms of a) linking ODD representations to safety engineer-
ing artifacts and b) performing change impact analyses for changed ODDs.
4
3 Concept
3.1 Method overview
This section describes the methodological big picture of the steps required to engineer
a safety-driven environment model suitable for analyzing the change impact on safety
engineering artifacts (see Fig. 1).
The assumed safety engineering process for ADS consists of common activities such
as hazard analysis and risk assessment (HARA), the derivation of safety requirements
realizing the safety goals, and the allocation of the requirements to architectural ele-
ments. It is especially challenging for ADS that the safety artifacts have complex de-
pendencies to elements of the ODD. For instance, safety requirements are dependent
on the presence of particular situations containing various context element combina-
tions out of a large set of possibilities. Thus, managing the possible situation space and
its impact on safety engineering gets top priority. Operational domain ontologies de-
scribing the relevant concepts of the particular mobility domain are an important input
to the ODD modeling process performed by domain experts. Unfortunately, an ontol-
ogy’s adequacy is highly dependent on the goals of its usage. Existing ontologies de-
compose the world into concepts relevant to enable scenario-based validation. In con-
trast, the goal of the method described in this paper is to bring environment models
closer to a representation that is more suitable for safety engineering.
Fig. 1. Overview of method for creating & analyzing safety-driven environment representations
The key contribution to achieving this is an integrated metamodel that supports express-
ing the dependencies between safety engineering artifacts and the safety-driven envi-
ronment. Since ODD extensions or changes between multiple mobility domains are a
practical challenge, concepts are provided to support creating a mobility domain ab-
straction model, which is then refined into more concrete safety-targeted ODD models.
For instance, a priority signal is an abstract concept relevant to many concrete mobility
domains. In logistics warehouses, orange blinking lights realize priority signaling,
5
while in urban environments, there are pedestrian or vehicle traffic lights. If there is a
safety requirement for handling the right of way, the environmental dependencies can
be leveraged to analyze relevance. Thus, the domain abstraction model is a key element
to enable conceptual similarity comparison of context elements when ODDs are
changed. To support safety engineers in performing this analysis, an analysis algorithm
is defined based on the introduced concepts. The result is a set of efficiently generated
insights on environment-induced assurance gaps, e.g., in the shape of context elements,
for which no safety requirements have been specified yet. Section 3.2 introduces the
required modeling concepts with an example. In this paper, we focus only on the mod-
eling aspects. A method for enhancing environment models, which are then formally
specified through the metamodel, will be presented in a future publication.
3.2 Concepts for safety-driven environment representation
Fig. 2 visualizes the three conceptual features used to create a safety-driven environ-
ment representation that can be referenced, from safety engineering artifacts. The con-
cepts build upon each other logically, i.e., concept 2 assumes the presence of concept
1, and concept 3 assumes the presence of concepts 1 and 2.
Fig. 2. Illustration of concepts for safety-driven environment representation
Concept 1: Linking safety engineering artifacts to context elements they refer
to is the basis for analyzing the safety impact of a changing ODD. The first step is
to explicitly express the dependencies between safety artifacts such as safety require-
ments and the context elements they refer to. On the one hand, this enables navigation
to all referenced context elements of any safety requirement. This is useful when
6
specifying the relevance or irrelevance of context elements in different domains. Chil-
dren appear in automotive environments and ADS therefore need to consider them. In
warehouses, process measures usually ensure that children do not get access and thus
no special requirements are needed for ADS. On the other hand, explicit context ele-
ments enable providing an additional specification of context elements by adding at-
tributes.
Concept 2: Hierarchization enables representing shared ontological concepts.
Existing environment ontologies are structured hierarchically. This allows engineers to
group ontology elements with similar attributes and according to conceptual dimen-
sions relevant for achieving particular inference goals. An additional value of hierarchi-
zation in the safety engineering context is that safety artifacts can be bound to parent
context elements, thereby subsuming child context elements. For instance, in Fig. 2, a
high-level safety requirement demands keeping a safe distance from dynamic objects.
The hierarchical structure of the environment model enables algorithmic reasoning that
the relevant concrete dynamic objects are pedestrians and vehicles. Note that the hier-
archization concept can be applied separately for multiple semantical domains, e.g. for
an automotive ODD or a warehouse ODD.
Concept 3: Shared domain abstraction enables similarity specification. Concept
3 builds on concepts 1 and 2 to enable operationalizing a model structure supporting
the analysis of the impact of different ODDs on safety artifacts. In Fig. 2, the starting
point is a safety requirement bound to a Human Worker context element in a warehouse
ODD. The question to answer is whether a Pedestrian in the automotive environment
is a) covered by the requirement, b) irrelevant to the requirement, or whether c) a new
requirement needs to be specified. To answer this question, a similarity metric is re-
quired that enables comparing the equality of Pedestrians and Human Workers in the
context of the safety requirement. Our solution to this problem is the use of domain
abstraction to create a model that is independent of concrete warehouse and automotive
elements but specifies common safety-relevant concepts in a generic mobility domain.
For instance, a human at risk is such a concept capturing the notion of humans, who
might get endangered by ADS and therefore need to be protected. In different concrete
operational environments, this concept is present for many different concretizations,
e.g., Pedestrian, Bicyclist, Police Officer in automotive or Human Worker, Warehouse
Leader, Maintenance Person in warehouses.
The concepts in the domain abstraction model allow capturing essential aspects rel-
evant to safety engineering in the mobility domain and thus grouping concrete context
elements in different domains according to these aspects. Thus, to determine the simi-
larity of context elements in different concrete domains in the context of a safety re-
quirement, we look for a shared parent concept in the domain abstraction. While this
criterion may be sufficient for classifying humans at risk, it may be not so obvious for
other safety-relevant abstract concepts like vulnerability or predictability. There, the
equivalence is dependent on the concretely considered safety artifact. Therefore, a mod-
eling approach needs to provide the possibility to explicitly specify the presence or
absence of equivalence for two context elements, despite them being grouped under a
similar abstract concept. This acknowledges the common theme that safety engineering
7
is often case-dependent and (un-)setting context element equivalence with a docu-
mented rationale allows tracing and analyzing the decision at any later point in time.
In summary, the three introduced concepts enable us to conceptually bridge the gap
between environment ontologies created by domain experts for different mobility do-
mains and the artifacts created by safety engineers during the safety engineering process
for an ADS. To make the concepts practically usable by safety engineers and consum-
able by an algorithm, a formal metamodel and algorithm are introduced in Section 4.
4 Concept formalization
4.1 Metamodel
Fig. 3 shows the metamodel with the elements and relationships necessary to formally
represent the introduced concepts.
Fig. 3. Metamodel for integrating environment models with safety artifacts
Context Representation. The fundamental basis for making environmental ele-
ments referencable is a representation of context elements, realized by the orange ele-
ments and relationships. An EnvironmentPackage is the container of ContextElements,
which can be further specified by ElementAttributes. EnvSituations capture a set of
Context Elements representing higher-level situations.
Safety Artifact Reference. Concept 1 of section 3.2 is realized by the blue elements
and relationships. There exist many SafetyArtifacts in a safety engineering lifecycle,
therefore concrete artifacts like SafetyRequirements inherit from SafetyArtifact. This is
the point where the expressiveness of the Open Dependability Exchange (ODE) meta-
model for extensively capturing and relating artifacts of the safety engineering lifecycle
can be realized (see section 5 for details). The SafetyArtifact.relatedContextElements
relationship enables binding SafetyArtifacts to ContextElements.
Hierarchization Concept. Concept 2 of section 3.2 is realized by the red elements
and relationships. To represent hierarchization, the ContextElementGeneralization ele-
ment is used. The element represents a relationship between two ContextElements. It
8
inherits a rationale attribute from InterContextElementRelationship, which is used to
give a rationale for why the two ContextElements are in a hierarchy relationship. This
is required for documentation and process traceability purposes. Navigating from a
child Context Element to its parent is possible via ContextElement.generalizations. The
multiplicity of this relationship makes it possible to relate a child Context Element to
multiple parents. This is required because a child context element needs to be related
to multiple parents in the context of the safety-driven domain abstraction concept 3.
Domain Abstraction Concept. Concept 3 of section 3.2 is realized by the green
elements, relationships, and attributes. Domain abstraction implies the presence of con-
crete EnvironmentPackages and an abstract EnvironmentPackage. This is modeled by
the EnvironmentPackage.isAbstractSafetyDomainEnvironmentpackage attribute and
enables modular specification of the domain abstraction model and its reuse in different
projects. ContextElements from concrete EnvironmentPackages can be linked via Con-
textElementGeneralization to ContextElements in abstract EnvironmentPackages. Fig-
uratively spoken, this concept enables modeling an interconnected and modularized
environment model, where the modules are either abstract or concrete.
Concept 3 introduced the notion of equivalence between concrete ContextElements
in different concrete EnvironmentPackages, which share a parent ContextElement in an
abstract EnvironmentPackage. The EquivalentLink element represents the equivalence
relationship between ContextElements and is used to explicitly specify two ContextEl-
ements as equivalent or not equivalent (EquivalentLink.inverted = true). This is neces-
sary for workshops where safety engineers and domain experts need to determine
equivalence in the context of a particular SafetyArtifact. Since this determination may
lead to important consequences, e.g., requiring a ContextElement to be sufficiently cov-
ered by a SafetyRequirement, documentation of the (non-)equivalence rationale via the
inherited InterContextElementRelationship.rationale is necessary.
4.2 Analysis algorithm
The change impact analysis can be supported by algorithms that are defined on the
metamodel. There are two main steps, (i) preparation and (ii) analysis. The preparation
step (i) requires as input the environment model of the old and the new domain as well
as the abstract environment model. The algorithm should output lists of context ele-
ments that are exclusive to (a) the old domain and (b) the new domain, as well as (c) a
list of candidates containing pairs of inter-domain siblings, i.e., two elements of a dif-
ferent domain having the same parent in the abstract model. The algorithm first re-
trieves all elements and then decides based on the attached generalization link and its
environment package whether it is exclusive to one domain. This is the case if the low-
est-level abstract parent element has no child from a different domain. As an interme-
diate step, the algorithm creates a mapping between the lowest-level abstract parent
element and a list of connected concrete context elements. Then it can filter for elements
of different domains and the same parent. Additionally, the algorithm collects all safety
artifacts that have a reference to the context element by iterating over the artifacts and
gathering those that are referenced to the specific context element. For elements in list
(a), the algorithm will further retrieve the referenced safety artifacts. These elements
9
require no further action because they are irrelevant when deploying the system in the
new domain. Related safety requirements therefore do not need to be fulfilled. Elements
in list (b) are not relevant in the old domain, so new safety artifacts must be created.
List (c) is the input for another expert analysis. Each pair of siblings is enriched with
safety artifacts that reference the element from the old domain. Safety engineers must
actively determine whether the siblings are equivalent between domains in the context
of the safety artifact. The enhanced model instance then serves as input for the next
step.
The analysis algorithm (ii) retrieves all elements that have an equivalent link at-
tached. It can provide a list of elements that are (d) equivalent between domains and (e)
explicitly non-equivalent even though they have the same parent. For elements in list
(d), no new safety artifacts need to be created; the existing ones can be reused. Last,
safety engineers know that no reusable safety artifacts exist for elements of list (e). For
those elements, new artifacts must be created.
The metamodel is an enabler for script-based change impact analysis. The described
algorithms support engineers in analyzing the environment and identifying reuse po-
tential. The algorithm output therefore does not generate artifacts but proposes elements
and artifacts so that engineers do not need to collect the relevant information manually.
5 Case study
Case study introduction. The case study for demonstrating and evaluating the devel-
oped concepts targets a use case, where an ADS system is assumed to be assured for
straight crossing of an intersection in a logistics warehouse environment (Fig. 4). This
means that safety artifacts such as safety requirements exist and consider the relevant
context elements of the warehouse ODD. The ODD is to be expanded such that the
ADS can be safely deployed to an intersection in an automotive urban environment.
Thus, the safety engineers need to determine the change impact of the ODD expansion
in terms of the need to modify existing safety requirements and/or specify new require-
ments for automotive-specific context elements, and the warehouse-specific require-
ments that are irrelevant for the automotive ODD and thus do not require revalidation.
Evaluation method. To apply the method described in sections 3 and 4, we instantiated
both domain-specific ODD models with domain experts from Hitachi in separate work-
shops for each domain. The experts used a mobility domain abstraction model, which
had been created previously inspired by the PEGASUS 6-layer model, as input and
concretized the abstract concepts for each concrete ODD. For the warehouse domain,
example safety requirements were derived and linked to the respective context elements
of the warehouse ODD model. Afterwards, context elements from automotive and
warehouse with shared abstract concepts were algorithmically determined and analyzed
in the context of the particular requirements regarding their equivalence. Then equiva-
lent links were created for elements that are similar in both domains. These processes
resulted in the target models, which were subsequently analyzed utilizing the change
impact algorithm. The safety engineers are then provided with the algorithm results
showing safety requirements and context elements relevant to required safety
10
modifications for the ODD expansion. The results were evaluated qualitatively by in-
dustry experts regarding their benefits and drawbacks compared to a non-model-based
approach as a baseline. Given the early stage of the research conducted, an empirical
evaluation was deemed inappropriate due to the cost-benefit imbalance.
Fig. 4. Case study context: assuring expansion of an ODD from warehouse to automotive
Implementation. The proposed model-based method was realized technically and
integrated with the Digital Dependability Identity (DDI) framework [12]. The frame-
work contains the Open Dependability Exchange (ODE) metamodel with integrated
capabilities to express the artifacts of the safety engineering lifecycle. In addition, a
scripting engine based on the Eclipse Epsilon framework [13] enables executing algo-
rithms on technical DDI instances conforming to the ODE. Our environment represen-
tation extends the ODE metamodel so that we can link context elements to specific
safety artifacts. The change impact algorithm was realized in the Epsilon Object Lan-
guage (EOL). Note that, although the case study focuses on safety requirements, the
change impact analysis can be easily extended to analyze environmental dependencies
of other safety artifacts, e.g., from HARA, due to the ODE’s expressiveness.
5.1 Creation and analysis of safety-driven environment representation
Fig. 5 shows an excerpt of the models created within the case study. For the sake of
clarity, it only contains the case study elements needed to illustrate the working princi-
ple of the approach. These include the domain abstraction model (top), two domain-
specific safety-targeted ODD models (distinguished by color – purple: warehouse, blue:
automotive), and safety requirements referencing the context elements. The domain ab-
straction model is realized as EnvironmentPackage with isAbstractSafetyDomainEnvi-
ronmentPackage set to true. The domain-specific models are also EnvironmentPack-
ages, but non-abstract. All elements in the EnvironmentPackages are ContextElements
hierarchized by ContextElementGeneralization, and in the bottom layer are Safety Re-
quirements. In the following, four scenarios are described to highlight the features of
the models.
11
Fig. 5. Excerpt of the safety-targeted ODD models with implications on safety requirements
Irrelevant requirements. Safety Requirement SR1 refers to the context element
Item Rack, which is part of the warehouse package and a concretization of the abstract
concept Indirectly Harmful Objects. If the domain experts would find a context element
in the automotive domain concretizing this concept, there would be another child ele-
ment for Indirectly Harmful Objects. Since this is not the case, SR1 is deemed irrelevant
for the automotive domain, so no revalidation, and validation effort is saved. This case
illustrates the general comparison concept: The potential similarity of two concrete con-
text elements is indicated via the abstract concept of a common parent.
New requirements. The context element Firetruck in the automotive package is a
concretization of the abstract concept Emergency Vehicles. For this abstract concept,
no concrete concept exists in the warehouse package. The conclusion is that a firetruck
was not envisioned to exist in warehouses and consequentially, no safety requirement
existed for its assured deployment in the warehouse ODD. Thus, a new safety require-
ment SR5 needs to be specified to address Firetruck. Note that the safety requirement
would not be generated automatically, but the lack of consideration of Firetruck would
be reported to the safety engineer.
Common abstract concept – covered by req. The next two scenarios deal with
abstract concepts with concretizations in both domains. Safety requirement SR2 de-
mands a safe distance from Human Workers in the warehouse. The relevant abstract
concept within SR2 is that Human Workers can be endangered by ADS and are thus
Humans at Risk. In the automotive domain, a Police Officer is equally deemed to be a
Human at Risk, expressed by the ContextElementGeneralization relationship. Merely
using the common parent concept as a sufficient criterion to indicate equality may be
hazardous. Therefore, an extra step has been introduced in that the safety engineers and
domain experts discuss the concrete case in the context of the concrete safety require-
ment and actively set the EquivalentLink, documenting of the rationale within the link’s
rationale attribute. After equality is determined, coverage of SR2 for Police Officer can
be assumed and no new requirement is needed.
Common abstract concept – new req. This scenario starts with safety require-
ment SR3 linking to Warehouse Leader, concretizing the abstract concept Rule-Im-
posing Object. Police Officer is a Rule-Imposing Object in the automotive domain.
12
Thus, one could assume SR3 already covers the Police Officer. However, this is not
the case in reality, as Police Officer imposes rules on the ADS, while the rules im-
posed by Warehouse Leaders only indirectly affect the ADS via the Human Worker
behavior. Thus, a new requirement SR4 is required. This scenario illustrates the im-
portance of the manual equivalence analysis step. The modeling formalism and the al-
gorithm can automatically constrain the number of cases to be analyzed manually
based on the common abstraction.
Fig. 6. Snapshot of the output of the automated model-based change impact analysis algorithm
Fig. 6. shows the output of the script execution realizing the change impact analysis
algorithm based on the introduced metamodel. The script output consists of exactly the
context elements deemed relevant or irrelevant in the illustrative scenarios in Fig. 5.
The output is structured by the specific call to action for the engineers.
5.2 Discussion
The case study demonstrates the capability of the presented approach to filter and cat-
egorize relevant ODD model parts to efficiently support safety engineers in performing
ODD change impact analyses. The baseline approach against which this paper’s ap-
proach was evaluated was a non-model-based approach that uses the BSI PAS 1883
ontology to identify the impact of ODD changes on requirements. The evaluation feed-
back revealed that especially the domain abstraction model and the introduction of
safety-motivated intermediate abstract concepts like Indirectly Harmful Object, Hu-
mans at risk, rule-imposing objects, or emergency vehicles improved the quality of the
domain-specific ODD models. The clear separation of abstract safety-driven mobility
concepts and domain-specific concepts facilitates reuse and even learning across do-
mains. For instance, when a new abstract concept is formulated based on a new concrete
domain, domain experts can reflect on whether this abstract concept might be concretiz-
able in other concrete domains and thus reveal gaps. The algorithm’s output was
deemed appropriate for enabling safety engineers to identify concrete next steps
13
(identification of new requirement, context element equivalence analysis, documenta-
tion of coverage rationale or requirement irrelevance).
One issue that emerged in the case study was the termination criterion for context
concretization, i.e., when to stop differentiating a particular concept. The conclusion
was that this is highly dependent on which safety artifact is concerned: While for be-
havioral requirements, the predictability or vulnerability aspects regarding humans are
relevant, appearance aspects are more relevant for perception requirements. This means
that the modeling formalism should be extended in the future to condition context ele-
ment concretization by aspects particularly relevant to the questions appearing in dif-
ferent safety engineering processes. This will enable the definition of improved meth-
odological support to create safety-targeted ODD models in which high confidence in
completeness can be argued.
The introduced approach provides the means to make existing domain ontologies
more safety-targeted. However, the suitability of intermediate safety-driven abstract
concepts to provide a complete decomposition of ontological aspects has not been eval-
uated. An evaluation of a real-world system is planned in the upcoming iteration.
6 Conclusion and future work
For safety engineers, it is a challenge to integrate existing ADS environment ontologies
into ODD models and systematically analyze the impact of extended or changed ODDs
on safety engineering artifacts. Therefore, we explored the conceptual needs for an
ODD representation that is suitable for integration into safety engineering processes.
The result is a formalized metamodel that provides means to model (a) links between
safety engineering artifacts and context elements; (b) hierarchical context element
structures to express shared ontological concepts; and (c) abstract domain structures to
make similar context elements in different concrete ODDs like warehouses or urban
environments comparable through abstraction.
In addition, we introduced an algorithm that leverages the introduced formalisms to
identify safety artifacts and their linked context elements requiring attention by safety
engineers in an extended ODD specification. The benefit of using our approach is that
manual reanalysis can be avoided in those cases where context elements in the extended
ODD share similar concepts with context elements in the previous ODD. The industrial
evaluation demonstrated that the proposed model-based approach is a suitable starting
point for systematically integrating environment modeling and analysis activities in an
overall safety engineering process. In addition, using the mobility domain abstraction
model makes it easier to create environment models for new concrete ODDs and even
support cross-domain learning. Thanks to the independence of concrete environment
ontologies, safety engineers can instantiate the approach with existing ontologies such
as [5][7][14], then run the algorithms to analyze the impact on safety changes. In par-
allel to exploring suitable formalisms for the representation and analysis of ODDs, a
concrete model for safety-driven ADS domain abstraction has been created, which can
be used to accelerate the creation of ODD models for new mobility environments by
refinement. This model will be the subject of another publication.
14
The case study revealed an important open issue: Since every safety engineering task
needs a different perspective on the ODD, it is necessary to support safety engineers in
constructively creating task-specific environment models that are sufficiently complete.
We believe this can be achieved by adding task-specific guiding questions that prompt
domain experts to cognitively think about the ODD from the perspective of a particular
safety engineering task. In future work, we want to research what such methodological
guidance for instantiating the models presented in this paper might look like.
Acknowledgment. Part of this work for writing the article has been funded by the pro-
ject Layers of Protection Architecture for Autonomous Systems (LOPAAS) funded by
the Fraunhofer Gesellschaft
References
1. Burton, S., Hawkins, R.: Assuring the safety of highly automated driving, state-of-the-art
and research perspectives, Assuring Autonomy International Programme, Report 2020
2. SAE International, SAE J3016:2021 Taxonomy and Definitions for Terms Related to Driv-
ing Automation Systems for On-Road Motor Vehicles, DOI: 10.4271/J3016_202104
3. Templeton, B. (2021): Will It Be Hard Or Easy For Self-Driving Cars To Expand Their
Territory?https://www.forbes.com/sites/bradtempleton/2021/03/30/will-it-be-hard-or-easy-
for-self-driving-cars-to-expand-their-territory/?sh=3ea1a8996fc4 Accessed: 20/02/2023
4. Reich, J. et al. (2022). Engineering Dynamic Risk and Capability Models to Improve Coop-
eration Efficiency Between Human Workers and Autonomous Mobile Robots in Shared
Spaces. In: Model-Based Safety and Assessment. IMBSA 2022. Lecture Notes in Computer
Science, vol 13525. Springer, Cham. https://doi.org/10.1007/978-3-031-15842-1_17
5. Scholtes, M. et al., (2021). 6-Layer Model for a Structured Description and Categorization
of Urban Traffic and Environment, In: IEEE Access, vol. 9, pp. 59131-59147, DOI:
10.1109/ACCESS.2021.3072739
6. British Standards Institution (BSI), PAS 1883:2020: Operational Design Domain (ODD)
taxonomy for an automated driving system (ADS) - Specification
7. Czarnecki, K. (2018). Operational Design Domain for Automated Driving Systems - Tax-
onomy of Basic Terms. DOI: 10.13140/RG.2.2.18037.88803.
8. ASAM OpenODD Project, https://www.asam.net/standards/detail/openodd/, 20/02/2023
9. ASAM OpenXOntology Project, https://www.asam.net/project-detail/asam-openxontol-
ogy/, Accessed: 20/02/2023
10. Kemmann, S. (2015): SAHARA-A Structured Approach for Hazard Analysis and Risk As-
sessments. Dissertation. Technical University Kaiserslautern, Germany.
11. Gyllenhammar, M., Johansson, R., Warg, F., Chen, D., Heyn, H., Sanfridson, M., Soderberg,
J., Thorsén, A., Ursing, S. (2020). Towards an Operational Design Domain That Supports
the Safety Argumentation of an Automated Driving System. In: 10th European Congress on
Embedded Real Time Software and Systems (ERTS), TOULOUSE, France. ⟨hal-02456077⟩
12. DEIS Consortium: Dependability Engineering Innovation for Cyber-Physical Systems Pro-
ject Dissemination: http://www.deis-project.eu/dissemination/ Accessed: 20/02/2023
13. Eclipse Epsilon Framework, website: https://www.eclipse.org/epsilon/, 20/02/2023
14. Westhofen, L., Neurohr, C., Butz, M., Scholtes, M., Schuldes, M. (2022): Using Ontologies
for the Formalization and Recognition of Criticality for Automated Driving. IEEE Open
Journal of Intelligent Transportation Systems. 3. 1-1. 10.1109/OJITS.2022.3187247.
