Using Ontologies for the Formalization and Recognition of Criticality for Automated Driving

Knowledge representation and reasoning has a long history of examining how knowledge can be formalized, interpreted, and semantically analyzed by machines. In the area of automated vehicles, recent advances suggest the ability to formalize and leverage relevant knowledge as a key enabler in handling the inherently open and complex context of the traffic world. This paper demonstrates ontologies to be a powerful tool for a) modeling and formalization of and b) reasoning about factors associated with criticality in the environment of automated vehicles. For this, we leverage the well-known 6-Layer Model to create a formal representation of the environmental context. Within this representation, an ontology models domain knowledge as logical axioms, enabling deduction on the presence of critical factors within traffic scenes and scenarios. For executing automated analyses, a joint description logic and rule reasoner is used in combination with an a-priori predicate augmentation. We elaborate on the modular approach, present a publicly available implementation, and evaluate the method by means of a large-scale drone data set of urban traffic scenarios.


I. INTRODUCTION
P URSUING the feat of automated driving -i.e.taking human operators out of the control loop -has sparked scientific interest for several decades.Pushed by pioneers like Ernst Dickmanns as early as the 1980s, it peaked in prestigious research projects such as PROMETHEUS [1].Despite focused industry efforts and assertive claims, the dream of full driving automation on urban roads has not been realized ever since.
Currently, systems at SAE Level 3 [2] -e.g.traffic jam assists -are developed only for highly restricted operational design domains (ODDs).This indicates that a key barrier lies within both the complexity and openness of less restricted driving contexts as well as their robust perception and subsequent semantic understanding.Consequentially, the development of an automated driving system (ADS) mature enough to overcome these challenges can only be mastered by including stakeholders of a diverse set of disciplines.
It is hence imperative to identify a common conceptualization of the ODD across all parties involved in the system's development and operation.Furthermore, this conceptualization must also be comprehensible for machines, as it forms the basis of the interaction for all subsystems of the ADS with the real world.While for restricted and highly regulated domains such as highways, a model may be feasibly constructed in a comparatively short time, an urban context has two properties impeding this approach.Firstly, it is highly complex, meaning that individuals in such scenarios can be of a vast amount of possible types, each of them possessing a multitude of potentially relevant properties possibly with uncountably large The research leading to these results is funded by the German Federal Ministry for Economic Affairs and Climate Action within the project 'Verification & Validation Methods for Automated Vehicles in Urban Environments'.The authors would like to thank the consortium for the successful cooperation.
Lukas Westhofen and Christian Neurohr are with the German Aerospace Center (DLR) e.V., Institute of Systems Engineering for Future Mobility, Oldenburg, Germany (e-mail: firstname.lastname@dlr.de).
Michael Schuldes is with the ika, Aachen, Germany (e-mail: michael.schuldes@ika.rwth-aachen.de).value ranges.Secondly, the urban context is open, meaning that new classes, properties, and behaviors of individuals can emerge rapidly without prior notice or time to respond.Therefore, a central question arises: How to construct a machinecomprehensible model of open and complex driving contexts?
Earlier work suggests that such operational domains (ODs) can be structured through the identification and subsequent explanation of safety-relevant factors, called criticality phenomena [3].This knowledge can then be constituted to a context model, in turn enabling semantic reasoning.
For example, such reasoning allows for an automated assessment of the situational risk.In the area of automated driving, risk evaluations are often performed using criticality metrics [4], e.g. to guide decisions of the driving automation towards states of minimal risk or to derive relevant test cases within a safety case.Essentially, such metrics measure 'late' factors that closely precede traffic conflicts, e.g.(predicted) small temporal and spatial distances.Naturally, the question arises: Can the previously derived criticality phenomena be simultaneously used to approximate the actual risk earlier?  Figure 1 sketches an example of how criticality phenomena and metrics interact.Here, the presence of kindergartens goes along with the presence of children alongside the driving area at pick-up times.The resulting possibility of traffic participants with unpredictable behaviors can be, statistically speaking, antecedent to an increased maximum required deceleration (a req ) or decreased time to brake (TTB).In total, the recognition and analysis of combinations of factors like the presence of kindergartens, children, and certain daytimes, can lead to a more timely and robust comprehension of the situational risk.
The work at hand addresses the two challenges directly visible in Figure 1: Firstly, building an underlying ontology and secondly, leveraging it to reason on criticality phenomena.The core of our work is based on the family of well-understood description logics (DLs) as a formalism to construct an ontology.Contemporary approaches suggest the use of ontologies for situation comprehension within ADSs, but lack a justification behind the selection and formalization of relevant concepts.As to bridge this gap, we propose to integrate the construction of the ontology into the verification and validation process of an ADS.More specifically, this ontology is iteratively refined by expressing the criticality phenomena using DL axioms and rules.Finally, the approach enables us to analyze these factors using a statistical evaluation of their association with traffic conflicts as measured by criticality metrics.
To summarize, the main contributions of this work are 1) to provide a method that enables the • construction of an ontology based on a set of criticality phenomena, • formalization of such factors based on the ontology, • inference of their presence in traffic scenarios, and 2) an open-source implementation of the method, including • the Automotive Urban Traffic Ontology, and • an ontology-based tooling that recognizes criticality phenomena in traffic scenario data.After presenting related work in section II, section III introduces the foundations of our approach, namely the methodical criticality analysis and the formalisms of description logics and rules.The method to both construct an ontology as well as to infer the presence of criticality phenomena (first contribution) is the topic of section IV.The implemented ontology (second contribution) is portrayed in section V, followed by an example on its iterative construction based on the formalization process in section VI.To conclude contribution two, section VII presents our publicly available tooling.An initial evaluation is provided in section VIII, for which we have exemplarily chosen a drone data set, depicting the usage of this method for an in-depth semantic analysis of data.

II. RELATED WORK
For road traffic, conceptualizations of knowledge have been collected, aggregated, consolidated, and described since the regulation of the traffic domain.For example, in Germany, there exist harmonized taxonomies and guidelines on the type of objects as well as how they shall be constructed [5].
For automated systems sufficiently intelligent to navigate complex traffic scenarios, the subsequent step is making this aggregated knowledge accessible.A unified terminology of the basic models -scene, situation, scenario -was defined by Ulbrich et al. [6].Within those scenarios, it was found that classes of entities could be structured along the so-called 6-Layer Model, a deliberately informal but comprehensive framework [7].We base the work at hand on these naturallanguage definitions as well as their classes of entities and provide a formal implementation thereof.Going into more detail, Czarnecki et al. collected large amounts of structured albeit informal domain knowledge regarding the environment of automated vehicles [8], [9].Furthermore, several standards present a structured domain model alongside, e.g.ASAM OpenSCENARIO [10].These sources were considered during the development of our implementation.
Hence, an ontology with formal semantics can be constructed from structured knowledge.For automated driving, several groups have formalized their domain conceptualizations by means of ontologies to represent both knowledge and data.This includes the RONNY ontology for intersection situations [11], the Automotive Global Ontology (AGO) [12], an Object-Oriented Framework (OOF) [13], and an approach of Core Ontologies (CO) [14].Recently, the community initiated standardization efforts for the simulation domain [15].Three of those ontologies are developed for specific use cases -intersection recognition for RONNY, closed world scenario descriptions for OOF, and automated decision making for CO -while the ontology presented for the work at hand aims to support various competencies.The AGO provides a knowledge organization framework focused on data labeling, but also includes a methodical approach to derive ontological concepts.This derivation is based on pre-existing data schemes to foster compatibility for the subsequent labeling use case.Hence, none of the ontologies considers its systematic integration into a safety case by means of a traceable identification and formalization of concepts w.r.t. the safety-relevant aspects of the OD.Rather, they represent the particular views and knowledge of the authors and knowledge sources.
Besides formalizing (shared) conceptualizations, research has leveraged the capabilities using logic reasoning on formalized ontologies to facilitate artificial intelligence functionality in ADSs.For a general semantic interpretation of perceived scenes, approaches have been presented as early as 2006 [16], based on the foundations of prior research in logics for artificial intelligence, including expert systems [17] as well as spatial and temporal logics for robotics [18], [19] in the 1970s to 1990s.Applications for automated driving can be traced back to using RONNY on the 2007 DARPA Urban Challenge vehicle AnnieWAY [11], which relies on a plain DL approach for scene inference on road geometries.We adopt a similar dogma, but also consider scenarios, i.e. the dynamical actions of traffic participants, in the inference process.Furthermore, our work specifically addresses the problem of lifting concrete domains to abstract ones such that input data becomes suitable for DL reasoning.Subsequent to RONNY, various ontology-based approaches for situation comprehension and planning components of automated vehicles were proposed.This includes a turning assistant for urban intersections [20] and context-aware speed adaption systems [21], [22].Furthermore, ontological formalisms were profoundly leveraged by Hülsen et al. in order to interpret the driving context at urban intersections using a combined DL-rule approach.[23].Their application of ontology-based inference on A-Boxes is related to the evaluation presented in section VII: They specifically leverage the open world assumption and rely on rules and description logics for situation analysis.Note, however, that the authors were developing their approach specifically for run time inference.Reasoning is hence only performed on abstract concepts within a reduced ontology.Furthermore, this inference approach is purely scene-based, whereas the work at hand aims to show how inference on large ontologies can be performed on complex scenario data at design time.
While these use cases relate to the situation comprehension of an ADS, our approach views ontologies as an inherent cornerstone of a safety case, which is in turn required for homologation.In the end, a shared ontological model between the stakeholders of the safety case will be necessary.For this purpose, it is hence insufficient to omit a justification for the selection of concepts, e.g.why to differentiate between a personal mobility device and a bicycle.This justification can then be used for verifying and validating the situation comprehension of the ADS.First steps have been made by Jatzkowski et al. who demonstrated how the relevancy of scene concepts can be derived from abstract system skills [24].In order to methodically support a safety case, Bagschik and Menzel examined how a knowledge base can be leveraged for automated scene creation [25] which in turn can be used to derive test scenarios from keywords [26].In such a scenariobased verification and validation process, it is essential to assign observed concrete scenarios to scenario classes, an approach coined as tagging in prior work [27].Albeit all four approaches are methodically integrated into their respective verification and validation processes, they do not highlight the applicability of the underlying logical formalisms for automated reasoning, or leave this issue for future work.However, it is only due to a logical foundation that a) concepts become rigorously traceable and b) inference can be leveraged for e.g.formal scenario analysis or consistency checks of the domain model (i.e.whether certain axioms are contradictory).
Finally, when moving from risk assessment at design time to dynamic risk assessment, early work shows that ontological reasoning can be employed to quantify risk at run time [28].Here, a rudimentary and small ontology was used for demonstration purposes, leaving open the methodical construction of larger ontologies necessary to represent complex urban contexts and the handling of issues accompanied by the growth in size in terminological and assertional components.

A. Criticality and its Phenomena within the Open Context
a) The Open Context Problem: An open and complex urban context poses great challenges when aiming to safely deploy an ADS [29], [3].Therefore, the ISO/DIS 21448 instructs to reduce the set of unknown hazardous scenarios, which can lead to unsafe situations if they are not considered in the design process [30].This requirement becomes harder to fulfill as the context grows in openness and complexity.
b) Criticality Analysis: It is therefore imperative to analyze the operational environment prior to system design, which was coined under the term criticality analysis [3].Its goal is to identify and understand the OD elements that areindependent of the system's realization -safety-relevant for the driving task.Hence, it uncovers both potential unknown unknowns as well as increases the understanding of known unknowns.The analysis delivers evidences for OD coverage and decomposition by a) the creation of a finite catalog of abstract scenarios that can be used to identify both requirements on the system behavior and relevant test cases, b) an argumentation about the coverage of such a catalog w.r.t. the OD, and c) a downstream effort reduction by providing generic statements about the safety-relevant elements of the OD.
To this end, one is specifically concerned with identifying situations of high accident risk.Hence, criticality can roughly be understood as a function of the probability and severity of the occurrence of any accident given a traffic situation.We build upon the following definitions from prior work.
Definition III.1 (Criticality).[3] Criticality is the combined risk of the involved actors when the situation is continued.
Aspects of criticality are measured using criticality metrics: Definition III.2 (Criticality Metric).[4] A criticality metric is a function κ : S × R + → O that measures for a given traffic scene S ∈ S at a time t ∈ R + aspects of criticality on a predetermined scale of measurement O ⊆ R ∪ −∞, +∞.Scenario level criticality metrics extend this definition from scenes to scenarios.
Criticality metrics measure late factors present in the chain of events leading to traffic conflicts.Consequentially, a measurement of factors preceding in turn increases in criticality metrics can be fruitful for purposefully generating evidences in a safety case, e.g. to identify factors of high relevance.We refer to these factors as criticality phenomena.

Definition III.3 (Criticality Phenomenon). [3]
A criticality phenomenon is a single influencing factor, or a combination thereof, that is associated with increased criticality in a scene or scenario.This work examines how a formalization of such phenomena can be leveraged for the construction of an ontology as well as for an analysis of criticality in traffic scenarios.The construction of such an ontology is inherently tied to a safety case, as elaborated in subsection IV-A.A subsequent ontology-based analysis contributes, in turn, to the single steps of a verification and validation process, as illustrated in subsection IV-B.

B. Knowledge Representation and Reasoning
Knowledge representation and reasoning concerns formalisms that model expert knowledge as well as methods thereon that enable machines to reason about conceptualizations of the real world.We base our approach on those foundations, which are concisely introduced in the following.
a) Ontologies and Description Logics: The term ontology originates from philosophy, denoting the discipline of studying things, their existence, and human conceptualizations thereof.Based on this, the fields of formal logic and computer science specify an ontology as a formalization of a conceptualization of a shared mental model of a certain aspect of the real world (often called the domain of discourse).
Such a shared formal model of the domain of discourse enables multiple stakeholder to agree on a common and consistent terminological basis.This is specifically important considering the multiple points of failure in information exchange: Different symbols can stand for the same realworld things, and different real-world things can be referred to by the same symbols.Furthermore, a layer of indirection is introduced by the interpreter through first resolving symbols to certain concepts, which is eventually resolved to a (potentially unintendedly different) real-world object.Ontologies make those relations explicit: they clearly assign semantics to concepts which are unambiguously denoted by a set of symbols.They can also aid in making the ambiguities of natural language explicit.Having a consistent and commonly understood ontology therefore mitigates mismatches in the semantics of used symbols and concepts among all parties.
DLs is a family of formal logics to represent such ontologies as a decidable fragment of first order logic.At the core of DLs are so-called concepts (or classes), which are semantically defined as sets of individuals, and roles (or relations), which are, analogously, sets of tuples of individuals.Individuals are concrete, existing instances within the domain of interest [31].All three can be referred to by their names, i.e. symbols.Note that the possible logical operators that can be used to define the right-and left-hand sides of the GCIs and RIAs in T are determined by the given DL fragment, consisting e.g. of negation (¬), intersection (⊓), union (⊔), and universal (∀r.C) and existential (∃r.C) role quantification.Semantically, the operators are defined in terms of an interpretation I = (∆ I , • I ), where ∆ I is the interpretation domain and • I an interpretation function assigning each operator a subset of ∆ I or ∆ I × ∆ I .For example, we say that C ⊑ C ′ iff for all interpretations I it holds that C I ⊆ C ′ I .⊤, ⊥ ∈ N C are unique names for the top (universally true) and bottom (universally false) concept with ⊤ I = ∆ I ∧ ⊥ I = ∅ ∀ I.The work omits further details and assumes some familiarity with DLs [31].
For our purposes, we additionally define the special functions con : T → 2 NC , rol : T → 2 NR , and ind : A → 2 NI which retrieve the set of employed roles, concepts, and individual names from the given GCI, RIA, CA, and RA respectively.In conjunction, we say nms := rol ∪ con ∪ ind .Furthermore, the set of T-Box axioms that involve a concept or a role X is defined as axs(X) b) Rules: The modeled axioms of a DL ontology are often enhanced by rules in form of a set of Horn clauses [32].
Definition III.6 (Rule Atom).For a given ontology O over a vocabulary N, a rule atom over a set of variables names V is an expression of the form where Definition III.7 (Rule).For a given ontology O over a vocabulary N, a rule over variables V is a Horn clause of a set of antecedent rule atoms R A over V and precedent rule atoms R P over V ′ ⊆ V , i.e. of the form ra∈RA r a =⇒ rp∈RP r p .Semantically, they are defined by universal quantification over the variables of V .c) Reasoning: A reasoner can then deduct new assertions from the given ontology, and is therefore able to check propositions and answer queries.For example, it can deduce the axiom C ′ (x) from the previously sketched axioms in Definition III.5.Generally, we denote the entailment of an axiom α from an ontology O by O |= α.Based on this, a subset of relevant decision problems is: , and • membership of a given individual to a concept, i.e.C(x).Furthermore, knowledge bases can be queried, i.e. retrieving all individuals x : C(x).These reasoning inquiries are substantiated to our domain of discourse in subsection IV-B.

A. Ontologies for Structuring an Open and Complex Context
The necessity of tackling the open context problem has been introduced in subsection III-A, for which we propose to use ontologies as introduced in subsection III-B.In its core, ontologies are based on the so-called open-world assumption, stating that if O |= α then O |= ¬α does not necessarily hold.Therefore, ontologies distinguish between the actual truth value of a statement and the information about it that can be inferred from the current knowledge, mitigating the problem of incomplete knowledge about the open context.Here, the openness refers to the inherent existence of things possibly unknown at design time, e.g. a traffic participant may not be detected by a machine learning perception system due to its anomalistic shape (such as costumes during carnivals).Although a reasoner may find that, based on the knowledge retrieved from the perception system, O |= (∃has traffic entity.Traffic Participant)(s i ) holds, it will not conclude that no traffic participant is present in the current scene s i .This can be then, for example, be propagated when querying the ontology whether it knows about the absence of vulnerable road users close to the road.
On a more general note, Figure 2 schematically depicts how an ontology functions as a central interface between the real world and the various entities that relate to the world.In the life cycle of a complex system, those entities are manifold in appearance, ranging from persons, such as developers, engineers, and testers, up to artifacts, such as the safety case, data schemes, and even the system itself, all with diverse models of the world.A mismatch in the understanding of the context between one of those entities can be fatal.This issue specifically concerns data-focused applications as a well-founded safety case relies not solely on a single data source but rather on various recording modalities to support its claims, e.g. from test vehicles, naturalistic driving studies, or drone data from intersections.Their data schemes need to be aligned in order to avoid discrepancies between these evidences.For example, a safety case may demonstrate that a machine learning-based pedestrian perception has an acceptable False Negative Rate w.r.t. the overall positive risk balance.Everything else should then relate to precisely the same understanding of a pedestrian that was used for labeling the test data and hence for calculating the False Negative Rate.

Open and Complex Context System
Naturally, the questions arise how to reach an agreement on a common conceptualization as well as how to construct a formalization thereof.We propose to guide the creation of such a model along the identification of criticality phenomena.A methodical criticality analysis iteratively assembles a list of safety-relevant factors within traffic scenarios, although its completeness argumentation is based on two assumptions: 1) there exist finitely many criticality phenomena, and 2) their traces are recognizable within data.The justification of these assumptions rests upon a comparison to human driving skills [3, Sec.IV c].The completeness assumption can then be justified as follows: By definition, each criticality phenomenon is associated with criticality.If we choose a suitable measurement principle (e.g. a suitable criticality metric) that can uncover their implications by finding related traffic conflicts, we are able to identify their traces in data.By analyzing whether this event can not be explained by a previously discovered phenomenon -i.e.we have found a new phenomenon -, it is possible to achieve a completeness based on the overall finiteness assumption [33].This completeness can then be recognized by a reduced frequency of unexplained traffic conflicts.Further discussion on discovering and explaining phenomena are given by Neurohr et al. [3].
Concurrently to the criticality analysis, a shared ontology can be created from these factors, closing the gap in handling the open context at design time.Note that the completeness of the shared ontology is based on the validity of the justification of the two previously mentioned assumptions.Obviously, the ontology needs to be maintained during deployment.Furthermore, concepts irrelevant for safety, e.g.those regarding mobility or performance goals of the system, may be added.

B. Competency Questions
We now derive competency questions that aid in developing an ontology for structuring the open context.a) Preliminaries for Competencies: First, we introduce some high-level DL notations on the representation of criticality phenomena and scenarios.Those high-level classes and their relations are depicted in Figure 3.We start with the concept of all scenarios, Scenario.Scenarios can have various member individuals i, denoted by the relation has traffic entity.Criticality phenomena are modeled as sets of such scenario entities.For each criticality phenomenon X, we denote its corresponding concept CP X ⊑ ∃has traffic entity −1 .⊤.For example, the class of all fast vehicles can be defined as CP fast ≡ Vehicle ⊓ Fast Object.Whereas this example solely refers to one subject w.r.t.criticality, such phenomena can generally address one or more objects in addition to the subject.Occlusion, for example, has the occluded entity as its subject but also relates to the occluding entity as well as the entity for which the occlusion happens.Therefore, objects are referred to by the relation object CPX , mapping from CP X to a number of objects.
Eventually, we are interested in decomposing the scenario space into a set of abstract scenarios covering the identified criticality phenomena.For a given CP X , we therefore denote its scenario class by S CPX ≡ ∃has traffic entity.CP X .
b) Derivation of Competency Questions: Starting early in the design phase of ADSs, contemporary approaches suggest to cluster the scenario space into abstract scenario classes.This clustering can be formally analyzed to support the experts decomposing the OD.Relevant questions are: • Whether a set of scenario classes can occur at the same time -if they are disjoint, e.g.risk estimations can be performed without explicitly considering their conjunctioni.e.
• Whether a scenario class is subsumed by another, as to facilitate a hierarchical decomposition within the safety argumentation, i.e. S CP1 ⊑ S CP2 (T2).• Whether the chosen decomposition is complete, i.e.
This decomposition can be supported by a counterexampleguided abstraction refinement as proposed by Neurohr et al.
[3, Sec.V A 5)].For this, is is necessary to assess whether a given scenario is member of a certain scenario class or an individual is or is involved in a criticality phenomenon -i.e., ¬S CPX (s) (A1), ¬CP X (i) (A2), or ∃object CPX −1 .⊤(i)(A3).Reasoning services on the ontology can support answering such questions formally by delivering counterexamples as to why these memberships do not hold.Furthermore, data recording and subsequent scenario mining is often used to identify relevant test scenarios.Given a real world traffic recording, we can find representative instances for our previously defined abstract scenario classes by asking a reasoner to query for A1 to A3.Finally, during system testing, answering A1 to A3 allows to check whether a concrete simulation or test run is an instance of a given test case.As one central element of a safety case, system testing can contribute valuable evidences for a necessary homologation prior to deployment.
However, even after successful homologation, constant monitoring of the ODD is required post-deployment, e.g. to detect changes in the assumptions on the ODD that were made in the pre-deployment safety case.The ontology can be used to formalize such assumptions on the ODD definition.An ontology-based monitor can then decide whether a) the observed scenario is consistent with the modeled knowledge about the world (i.e. the assumptions) and b) the observed or predicted future scenario still lies within the ODD.Otherwise, appropriate mechanisms have to be executed by the ADS.The first query reduces to the formal expression O |= Scenario(s) (A4), whereas the second one can be based on A1 to A3. Especially after incidents but also in joint operation with humans, e.g. for Level 3 functions, the system's behavior needs to be explainable at runtime.If a vehicle chooses a behavior based on specific circumstances in its environment (i.e.assesses A1 to A3), it is advisable to investigate why this behavior was chosen.We can query a reasoner to derive a logical explanation as to why S CPX was deemed to be present.
Table I presents the derived seven competency questions -A1 to A4 and T1 to T3 -the proposed ontology was implemented against.Note that there also exist other possible competency questions, such as model finding -algorithmically generating a witness for the satisfiability of ⊤ ⊑ ¬C, e.g. a concrete scenario s for a given abstract scenario class S CPX .Such competency questions require different architectures and approaches in ontology design and were thus excluded.
Whereas the ontology has been implemented w.r.t.all competency questions, the evaluation of the ontology-based tooling as presented in section VII and section VIII is focused on the first three competency questions, A1 to A3.This allows, on one hand, to keep the ontology implementation generic and applicable to a variety of use cases, and, on the other hand, the practical evaluation focused and comprehensible.

C. Methodical Formalization and Recognition Criticality
We have introduced the working hypothesis that by creating an ontology via a set of identified criticality phenomena we are able to achieve an iterative completeness of the model w.r.t. the safety relevant factors.Furthermore, we established the practical relevance of the guiding competency questions regarding the safety assurance of ADSs within a thereby created model.In particular, we demonstrated the importance of answering competency question A1 -scenario membership.Based on these foundations, we propose a general method that 1) formalizes criticality phenomena within an iteratively refined ontology, 2) transforms data from various sources into the language of the ontology, and 3) utilizes DL & rule reasoners to infer the presence of criticality phenomena in such traffic scenarios The process is depicted in Figure 4 where these steps are respectively marked by 1 , 2 , and 3 .4. The general method of formalizing a natural language phenomenon and reasoning about its presence in data.

Criticality
In step 1 , the T-Box T is iteratively constructed by formalizing a list of criticality phenomena.This list is constantly growing by continuous conduction of a criticality analysis [3].We therefore pick a criticality phenomenon CP X and create a formalization of its semantics using appropriate rules or DL axioms.This semantics can be based on both existing concepts -C 1 , . . ., C n -as well as newly introduced concepts -C k , . . ., C l .This necessitates the addition of C k , . . ., C l to T , in turn recursively formalizing them until the valid assumption can be made that so-called basic concepts can not be further specified.A validation of the assumption is required, i.e. it has to be argued why neither a rule nor a description logic axiom is suitable to represent the given concept.
If one aims to infer the presence of a formalized criticality phenomenon, these basic concepts are then required to be either directly quantifiable or computationally derivable from the data.In that case, they shall have a definition in natural language as to facilitate a correct observation.If basic concepts are not observable in data (for example, if the recording modality does not allow to recognize certain features such as whether turning indicators are enabled), an analysis of the phenomena relying on those concepts can not be performed.
Hinging on the assumption of convergence of the criticality analysis, this process leads to an iterative completion of the ontology towards an exhaustive representation of all concepts that are deemed essential for identifying safety-relevant factors.This step is elaborated on in detail in the upcoming section V -concerning the basic ontological framework -and section VI -concerning the formalization of criticality phenomena within this ontological framework.
Step 2 unifies the various scenario data sources by conversion into a T -compliant A-Box A. This creates scenarios s 1 to s n with traffic entities i to i ′ that are represented using the concepts C, C ′ , . . .and roles r, r ′ , . . . of T .A realization of this step is given in subsection VII-A and subsection VII-B.
Once the manifold data sources are convertible from their native data schemes, new facts can be inferred by performing reasoning on the ontology O = (T , A), as indicated by 3 .Such a reasoning pipeline has been prototypically implemented for the work at hand whilst taking into account various practical concerns, e.g.temporal reasoning performance and concrete domain abstraction.This finally answers competency question A1, i.e. for which i ∈ {1, . . ., n} S CPX (s i ) holds, and, per definition, also A2 to A3, cf.subsection VII-C.

V. THE AUTOMOTIVE URBAN TRAFFIC ONTOLOGY
Starting with step 1 of the sketched method of Figure 4, this section presents the employed T-Box.It describes the conceptual foundations, general structure, idea, modeling, and implementation of an integrated set of suitable ontologies.

A. The 6-Layer Model as a Conceptual Foundation
As a tool for structured environment description, the wellknown Layer Model can be utilized to create a formal model of the context.It was originally defined by Schuldt [34] and has been continuously refined for specific use cases, e.g. by Bagschick et al. for the instantiation of highway scenes [25].In a recent work by Scholtes et al., their ideas are examined in-depth and adapted for urban environments while keeping compatibility to the fundamental ideas behind the Layer Model [7].Since Scholtes et al. give detailed definitions of the layers as well as justifications, guidance, and examples, it serves as a suitable basis for our use case -namely, the construction of a formal ontology implementing the Layer Model.
The work categorizes the environment, its entities, and their properties in six individual layers: Road Network and Traffic Guidance Objects (L1), Roadside Structures (L2), Temporary Modifications of the former (L3), Dynamic Objects (L4), Environmental Conditions (L5), and Digital Information (L6), encompassing the so-called 6-Layer Model (6LM).It thereby provides a generally usable, unbiased, and objective environment description, i.e. it functions as a clearly structured basis for scenario descriptions and their ontologies.While the 6LM provides a unique top-level structuring for the environment, an ontology details and formalizes the different entities, properties, and relations in a more comprehensive way.

B. Architecture
In order to address the issue of integrating the 6LM into a formal ontology as necessitated by the process of Figure 4, we present the Automotive Urban Traffic Ontology (A.U.T.O.).In its core, it is a set of integrated ontologies with the goal to enable reasoning about criticality in urban traffic scenarios.Due to this scope, the 6LM as defined by Scholtes et al. for urban environments, is used as an architectural guiding pattern.
Architecturally, we separate each layer into a core and an implementation.Cores represent an ontological interface which other layers and applications of the ontology can access without being concerned with detailed domain knowledge, which in turn is given in a set of implementations.For example, the concept Lane is part of the Layer 1 core, but concrete specializations of lanes can be given in an implementation.
Moreover, this work extends the 6LM by detaching conceptually separated parts which semantically span over multiple layers or are completely independent of the traffic domain.This modularity enables separation of concerns and re-use of concepts, e.g. for spatial properties (heights, distances, etc.).
Note that often, so-called Upper Level Ontologies are employed for the purpose of unification.We deliberately omit the use of such ontologies as we were not able to identify an ontology that satisfied the needs imposed by the competency questions.Namely, this concerns issues of suitable formalization to enable inferences by DL reasoners, documentation, implementation, comprehensibility, and modularity.This problem is currently addressed in the standardization project ASAM OpenXOntology [15], where an Upper Level Ontology is laboriously integrated into a traffic domain ontology.
We hence opt for a lean approach, where single, re-usable domain ontologies are imported, as displayed in Table II.On top of the related ontologies, we introduce a framework in which traffic entities of the 6LM are integrated into traffic models such as scenes and scenarios.Collectively, this conglomerate of ontologies yields the A.U.T.O.shown in Figure 5.
The diagram indicates the direction of the dependencies of the modules through arrows.Therefore, both the traffic models as well as the 6LM rely on the set of related ontologies.The former uses e.g.temporal concepts to specify scenarios, the latter uses e.g.physical properties for traffic participants.

C. Implementation
We provide an open-source implementation 1 of the previously introduced ontology in OWL2 (i.e. the DL SROIQ (D) ).The provided A.U.T.O.consists of 26 OWL2 files implementing the modular architecture of Figure 5.Each file represents one ontology module in which its respective domain concepts are defined.For example, the Physics ontology defines concepts such as Spatial Object, Dynamical Object, and Non Moving Dynamical Object alongside their natural language definition.Here, a Spatial Object is defined as 'any physical object with a geometrical representation, e.g. a vehicle'.If expressible in DLs, the OWL2 files also specifies logical axioms implementing these natural language definitions.For example, the Physics ontology states Dynamical Object ⊑ Spatial Object and Non Moving Dynamical Object ≡ Dynamical Object ⊓ ∃has velocity.{0.0}.Those logical T-Box axioms then allow the reasoner, in turn, to infer entailed statements on the A-Boxes for the subsequent evaluation -such as, whether a given vehicle is a Non Moving Dynamical Object.For a visual excerpt of the T-Box of A.U.T.O., including the subsumption relation and other logical axioms, we reference to Figure 6.
We also rely on well-established ontologies, enabling compatibility to a wide range of tooling such as GraphDB: • geometrical concepts are represented using OGC's GeoSPARQL ontology2 , which gives access to DE-9IM and RCC8 vocabularies [35], and • temporal concepts are represented using W3C's OWL Time ontology3 , which itself relies on an adapted version of Allen's 13 temporal relations [19].
A Note on Temporal Identity: Some ontological approaches assume a perdurantistic dogma, i.e. things are inherently four dimensional entities in space-time.A.U.T.O.takes an endurantistic view: it specifies individuals in three dimensions and tracks temporal identity by the role identical to.

VI. ONTOLOGY-BASED FORMALIZATION OF CRITICALITY PHENOMENA
In general, criticality phenomena are not fixed to the combined DL-rule approach proposed in this work.Various approaches exhibit differences in ease and specificity of the modeling process, computational efficiency of decidability problems, and availability of expertise.However, a common feature is their formalization being based on an implicit or explicit ontology.This section depicts the formalization process for our DL-rule approach as well as how the formalization can be leveraged for the construction of such an ontology.

A. The Formalization Process
Recall that the general method of subsection IV-C started the formalization process (step 1 ) where a criticality phenomenon is formalized.We now explain this process in more detail, which is based on the previously introduced framework of A.U.T.O. and a catalog 4 of criticality phenomena defined in natural language that was assembled during prior work [3].We illustrate the formalization of the exemplary criticality phenomenon 'Bicyclist Illegitimately Riding Over Pedestrian Crossing' (CP 69) as a special case of Misconduct (CP 143).
The first step involves the collection and assembly of knowledge regarding the semantics of the criticality phenomenon, which relies on standards, laws, and domain experts.For our example, we deem as necessary the semantics of the relevant regulatory aspects, bicyclists, pedestrian crossings, and riding over.During the process, the stakeholders agree on 1) the relevant regulatory aspects being given by the German traffic regulations (StVO) stating that a bicyclist can not exercise the right of way indicated by a pedestrian crossing if the bicyclist is mounted, 2) a bicyclist as a traffic participant on a bicycle, and 3) a pedestrian crossing as a an area that is officially marked with corresponding white stripes.4) riding over as the movement of an actor across an area A suggestion of an (aspectual) semantics is then given by: "A bicyclist that in one scene is not on a drivable lane, and in a directly succeeding scene on a pedestrian crossing where the bicyclist is exercising a right of way is using this pedestrian crossing illegitimately." As temporal identities of traffic entities need to be tracked through different scenes, we express this using a rule-based approach such that individuals can be bound to variables: Scene(s1) ∧ Scene(s2) ∧ has traffic entity(s1, b1) ∧ has traffic entity(s2, b2) ∧ identical to(b2, b1) ∧ Bicyclist(b1) ∧ Bicyclist(b2) ∧ directly after(s2, s1) ∧ Non Driveable Lane(w) ∧ has traffic entity(s1, w) ∧ intersects(b1, w) ∧ Pedestrian Crossing(c) ∧ has traffic entity(s2, c) ∧ intersects(b2, c) 4 https://github.com/lu-w/auto/blob/main/criticalityphenomena.owlIntuitively, this rule states that if a bicyclist is driving on a non-drivable lane (e.g., sidewalk) in one scene and on a pedestrian crossing in a subsequent scene in which also a traffic participant on an intersecting lane with an intersecting path, then CP 69 holds for that bicyclist.More specifically, the identity of the bicyclist in the first scene (s 1 ) is referred to as b 1 , respectively as b 2 for the second scene (s 2 ).The scenes have b 1 and b 2 as their respective traffic entity (hence, has traffic entity) and are directly after each other (hence, directly after).Furthermore, s 1 has a non-drivable lane w as its traffic entity which the bicyclist b 1 intersects.Similarly, the second scene s 2 has a pedestrian crossing c and driveable lane l that intersects c.Furthermore, s 2 has a driver d within s 2 on lane l that drives a vehicle v which in turn has an intersecting path with the bicyclist b 2 .
The formalization relies on a set of concepts from A.U.T.O. that are assumed to be already existent as well as suitably defined and axiomatized in the ontology, e.g. for temporal and spatial concepts.On the other hand, Bicyclist, Pedestrian Crossing, and Non Driveable Lane (underlined) are, for the scope of the example, not present at the time of formalization and therefore need to be added to T .The following integration of concepts and their subsumption is also visualized in Figure 6.Requiring that the necessary basic concepts can either be directly observed in the analyzed data or at least be derived therefrom, e.g. by means of machine learning algorithms such as image segmentation for Non Driveable Lane, we now have the ability to (aspectually) infer the presence of CP 69 .

B. Approaching Formalizability
Concepts and phenomena may be inherently unformalizable due to their vagueness (e.g.subjectivity and case-by-case decisions).To mitigate this problem, CP X can be specified by: 1) An exact representation: if possible, we give an exact representation using an equivalence, i.e.CP X ≡ f (C k , . . ., C l ) where f is a logical concept expression.2) An under approximation: if an exact representation is not possible, we use an approximation.In DL, an under approximation can be specified as a GCI of the form CP X ⊒ f (C k , . . ., C l ).On top of DL, sufficient conditions for CP X can be stated as a rule, i.e. ra∈RA r a → CP X (v).Besides those three formalizations, our prototype contains the definitions of in total 16 criticality phenomena, depicted along their primary classification within A.U.T.O. in Table III.They were selected from a catalog of roughly 300 criticality phenomena described in natural language which originated during an initial iteration of the criticality analysis.Their formalization is detailedly presented in the Appendix.

VII. IMPLEMENTING THE CRITICALITY RECOGNITION
We present a Python implementation 5 of the process of section IV that is based on the ontology introduced in section V.While the realization of step 1 has already been unveiled, we now focus on the data and reasoning steps, i.e. 2 and 3 .

A. The OMEGA-Format
As motivated in section I, the use of various data sources is of high value when analyzing the criticality within traffic scenarios.Methodically, our approach rests upon a unified 5 https://github.com/lu-w/criticality-recognitiondata format that allows to represent traffic scenarios from different sources, including drones, measurement vehicles, and stationary cameras.This format therefore provides input for A.U.T.O.A-Boxes.For this, the OMEGA-format was chosen [36].The data format is HDF5-based and designed to store reference data of urban automotive settings in an object-list structure together with map and weather information.

B. Ontology Mapping
In order for Automotive Urban Traffic Ontology (A.U.T.O.) to harness the information provided by OMEGA-compliant data sets, we need to map the OMEGA-format onto the concepts provided by A.U.T.O., i.e. a realization of step 2 .As the development of the OMEGA-format was performed in conjunction with the development of A.U.T.O., the format is naturally mappable to the concepts of the ontology.
For example, we translate each object of the OMEGA-type reflector_guidingLamps into a corresponding axiom within the ABox.The following specification of the OMEGAformat defines reflector guiding lamps as "6.1 Type: reflector_guidingLamps: Any reflectors or lamps along the lane (reflectors and guiding lamps are assumed to be regularly placed, their exact position is not known.)".We create a new individual i as well as a corresponding boundary geometry i geom and map the definition to i by: (System ⊓ ∀consists of.(ReflectorGuiding Lamp ⊓∃within.{igeom }))(i)

C. Automated Recognition of Criticality Phenomena
After creating an A-Box A based on T containing a set of n scenarios, the naïve option would be to run the reasoner directly on O = (T , A).With this, two problems arise: 1) deriving abstract facts from concrete domains, such as performing complex trigonometrical calculations to check whether one geometry occludes another, and 2) exploding state spaces for large A-Boxes, especially when analyzing real world scenarios.We resolve both issues within our implementation.
a) Deriving Abstract Facts from Concrete Domains: Here, we propose an iterative augmentation approach to lift A-Boxes from concrete to abstract domains.We provide a library where the user can easily specify definitions for arbitrary concepts C and (reified) roles r using Python code 6 .This enables us to derive whether those concepts or roles are present by means of classical imperative programming.The library provides a high level interface that performs such an augmentation for each individual within A of an ontology O, denoted by DO AUGMENTATION(O), changing O in-place and returning the number of performed augmentations.
Finally, the lifting of domains needs to be integrated with the reasoner, whose interface is denoted by DO REASONING(O).This integration is sketched by Algorithm 1. return O 8: end procedure This simple yet correct procedure yields an iterative detection of all possible inferences on O.Note that efficiency can be improved by directly integrating the augmentation into the reasoning engine, which was left for future work.
b) Exploding State Spaces: The second issue concerns the sheer size of real world scenarios.As an example, a complex urban traffic scene may contain 80 individuals on Layer 4 and 200 individuals on Layers 1 and 2.Even at a sampling rate of 3 Hertz, this amounts to over 2.5 • 10 5 individuals in 30 seconds and a combinatorial size of 6.25•10 10 and 1.5625 • 10 16 for potential binary and ternary relations.
Upon closer inspection, many of those relations may not be logically possible.For example, spatial relations between a lane in scene one and a vehicle in scene two are irrelevant.Therefore, we safely use successive examination of the single scenes to correctly infer all non-temporal facts.
This still leaves open the question of handling temporality.For example, the previously introduced rule for criticality phenomenon CP 69 argues over two directly succeeding scenes, which can not be recognized on a scene level.However, running the reasoner directly on the scenario-level A-Box leads to the discussed scalability issues.Analogously to program slicing [37], we suggest a temporal slicing approach.
Here, entities not relevant for temporal inference are sliced from the A-Box and re-added after finishing the temporal reasoning on the whole scenario, as shown in Algorithm 2. The algorithm relies on the following operators: for i ∈ {1, . . ., n} do 3: end for

C
= TEMPORAL CONCEPTS(T ) A sliced = SLICE(A merged , C) DO INFERENCE((T , A sliced )) 10: return (T , A res ) 12: end procedure using the previously introduced role identical to.
• TEMPORAL CONCEPTS(T ), which identifies a set N T of concepts and roles that are (possibly indirectly) used in an axiom involving a concept from a set of temporal concepts T , e.g.T = {Interval, Point}.Formally, In the case that O contains rules, N T can be defined analogously.
• SLICE(A, T), which creates an A-Box A sliced with only individuals that relate to concepts in T, i.e.
Intuitively, the algorithm takes as input an A-Box A with one scenario consisting of n scenes.It creates an A-Box A res where all temporal facts -i.e.those on a scenario-level -are inferred.This concerns, for example, the rule for CP 69 , which can only be applied when multiple scenes are present in the analyzed A-Box.Firstly, it infers all entailed facts on each scene using Algorithm 1. Afterwards, it merges all scenes into a single A-Box A merged .Based on the formalized criticality phenomena in T , it also derives a set of temporal concepts C which are necessary to infer facts about the presence of temporal criticality phenomena.Those are then used to create a sliced A-Box A sliced in which only individuals of concepts in C remain.This sliced A-Box is then considerably smaller than the original A-Box and therefore suitable for the inference sketched in Algorithm 1. Finally, all individuals that were previously sliced away are re-added to the A-Box A res .
Since criticality phenomena have been modeled as axioms within T , Algorithm 2 eventually yields an inferred A-Box A in which the presence of criticality phenomena is documented.

VIII. EVALUATION AND RESULTS
We evaluate the implementation on the inD data set [38], showing how the reasoner can answer the competency questions A1 to A3 based on the exemplary set of formalized phenomena and our implementation of Algorithm 1 and Algorithm 2. Albeit the main contribution of this work being the development of the method and tooling, we present a first evaluation for a semantic data analysis use case.Recall that we have previously argued that a verification and validation process relies on various recording modalities, including fleet monitoring, test vehicles, and drone data.As to exemplarily examine one of these relevant data sources, we have selected a large-scale drone data set which can act as a precursor to a rigorous investigation of a variety of data sources.

A. The inD data set
The inD data set consists of naturalistic trajectories of more than 11 500 road users, including vehicles, bicyclists, and pedestrians, at four urban intersections in Aachen, Germany.The utilization of drones in the creation of the data set retains naturalistic driving behavior by being inconspicuous and aids the accuracy of positioning and object dimensions.Its distinctive perspective allows to draw conclusions about the behavior of traffic participants in certain situations -e.g.bicyclists at pedestrian crossings -which in turn can be constructively used as assumptions for designing, implementing, and safeguarding an ADS.Moreover, and in contrast to an in-vehicle perspective, we are able to assume a holistic view on the traffic scenario, i.e. tracking of 'behavior chains' where the decisions of traffic participants influences each other through transitive propagation.As an example of such a chain, consider an occluded pedestrian which leads to a strong braking maneuver of an intersecting vehicle that in turn leads to a potential rear-end collision of a following vehicle.

B. Reasoning Results
In order to demonstrate the practicality and utility of our approach, we evaluate of the method on inD in three steps: • Firstly, we present an intuitive example depicting the inference results for a single, representative traffic conflict.• Secondly, analyze four scenarios on each intersection.
• Lastly, we compare the inferences of our tooling against two criticality metrics as determined by prior work [39].

1) An Exemplary Traffic Conflict
We identified a simple yet representative traffic conflict within the inD data set 7 .Here, a passenger car approaches the intersection at the Frankenberger Park in Aachen, Germany, from the east while a pedestrian is occluded behind parking vehicles.The passenger car is forced to a substantial braking maneuver by the appearance of the pedestrian.The criticality phenomena within this conflict were inferred automatically by our tooling and are represented visually in Figure 7. 7 Namely, scenario number 94 in recording number 18 The inferences show that the pedestrian and vehicle are indeed bilaterally occluded by parking vehicles while having a high relative speed during the first seconds of the scenario.Furthermore, the driver passes these parking vehicles while the pedestrian has access to the road.This leads to the occurrence of the more concrete criticality phenomenon Small Distance.Note that, albeit a harsh braking, the criticality phenomenon Strong Braking Maneuver was not detected, as the vehicle has been decelerated just below the threshold of 4.61 m/s².This showcases an inherent limitation of the binary identification approach, where values just below thresholds are deemed irrelevant albeit possibly still influencing the overall criticality.
As an illustration of the aforementioned holistic view on traffic scenarios, Figure 8 shows a bar chart of the amount of criticality phenomena per scene for the exemplary scenario.
It is evident that occluded traffic infrastructures -such as lane markings -make up a large amount of the overall criticality phenomena.Furthermore, we find a considerable number of small distances and intersecting planned paths, as is to be expected in urban intersection scenarios.Overall, the amount of inferred criticality phenomena per scene is quite high, raising the issue of the specificity of the formalizations.

2) Evaluation of Multiple Scenarios
We present an evaluation of in total 16 scenarios -four scenarios for each of the four inD intersections -with a mean duration of 11.27 ± 3.68 seconds covering a total span of 180.28 seconds with 361 unique traffic participants.The scenarios were converted into A.U.T.O.A-Boxes at a rate of 1 Hertz, leading to 183 scenes.Due to the large scale of the data set, we reduced the evaluation to scene-level criticality phenomena, i.e. performing only Algorithm 1.The overall number of inferred criticality phenomena amounts to 114 922, resp.628 per scene.If this number is again taken relative to the involved traffic participants, we find that there exist roughly 1.74 criticality phenomena per scene per traffic participant.
A detailed break-down of the inferred criticality phenomena per scene per traffic participant into the single phenomena classes for each of the intersections is presented in Table IV.For example, on intersection two, there exist 1.332 occluded pedestrians per traffic participant in each scene.The value is considerably lower for the other intersections, indicating a higher pedestrian occurrence or occlusion potential.
To further show the capabilities of a semantic analysis, we demonstrate how a naïve analysis of the temporal relation of two criticality phenomena can be performed -namely   Intersecting Planned Paths and Occlusion -on passenger carpedestrian constellations.We first formulate two hypotheses: H 1 occlusions and intersecting paths are, independent of their temporal constellation, associated between passenger cars and pedestrians, and H 2 in the cases where both occur, it is more likely to observe intersecting paths after occlusions than before.
We test H 1 by means of a simple contingency table as depicted in Table V.This table displays the amount of cases of all four combinations of the occurrence of the two criticality phenomena between passenger cars and pedestrians., where n ij indicates the number n in the i-th row and j-th column of the contingency table.For the analyzed criticality phenomena, this yields Φ = 0.04.With the phi coefficient taking values from [−1, 1] in the dichotomous case, we find a minor yet positive correlation between the variables.As to test H 2 , we first perform a simple analysis of the differences of the starting times of the intervals in which the criticality phenomena occur, taking into account all combinations of traffic participants.Since the association has been examined by Φ, we can now focus on only the cases in which both small distances and occlusions occur.Our results indicate that, on average, small distances start 0.87 seconds after occlusions, with a standard deviation of 5.83 seconds.

3) Comparison against Criticality Metrics
Besides comparing the relations between criticality phenomena themselves, one can also identify their relation to measured criticality as computed by criticality metrics.Here, our hypothesis states that an increase of a criticality metric is often preceded by a set of relevant criticality phenomena.This methodical approach obviously rests upon the assumption of a specific and sound formalization of criticality phenomena as well as upon employing valid criticality metrics.
Prior work has already examined various criticality metrics for 22 traffic scenarios of inD for left-turn and passing maneuvers of vehicle pairs [39].We restrict our exemplary comparison to the analysis of one scenario and two metrics, namely scenario number 449 in recording number 28 and the Time To Collision (TTC) and Required Acceleration (a req ).Similar to Figure 7, the plot of this scenario is presented in Figure 9 but now includes the metrics' values over time.In the example, a minimum TTC of 0.6 s and a req of -11.8 m/s² is given, with the metrics starting a linear approach of their minimum values at second 1044.7.After second 1046.7, the passing maneuver is finished.Our tooling observes that before this critical encounter, an occlusion took place between both traffic participants.Furthermore, we also identified high relative speeds during the passing phase of both vehicles.
A note on risk quantification: Within a rigorous safety case, this relation needs to be examined statistically on populations of representative scenarios, i.e. how strong is the association between certain phenomena and measured criticality across the OD.Depending on this strength, certain phenomena may be treated differently during the argumentation and evidence generation.For example, an argument as to why the ADS sufficiently mitigates the risk induced by occluded pedestrians may be elaborated on more extensively than those in which a lane marking is occluded -depending on the associational findings and subsequent causal analyses.After this initial examination of the OD, safety standards require the development of a system design as well as a subsequent hazard analysis and assessment of risks.This assessment can be based upon prior knowledge that originated from the analysis of criticality metrics and phenomena.Since criticality phenomena represent factors that impact the safety in traffic in general, it is likely that such phenomena will also be relevant for the hazard analysis of the given system.The quantification provided by the aforementioned associational analysis of criticality can be used as an initial estimate for the risk assessment, although the specific system design may influence the actual risk.For example, an ADS could be designed in a way that effectively mitigates risks induced by occluded pedestrians.Nevertheless, an argument as to why this specific criticality phenomenon is handled sufficiently well by the system is mandatory.

IX. CONCLUSION AND FUTURE WORK
We presented a first step towards a structured method to obtain a formalized definition of an OD, incorporated into the framework provided by the criticality analysis.This ontological OD definition has shown to be well-suited for reasoning over formalized criticality phenomena, thereby being a central element in a verification and validation strategy.
Obviously, future work can address the extension of the knowledge base -formalizing a wider variety of criticality phenomena -, the data sources -analyzing data generated by test vehicles or simulation runs -, a rigorous data analysis -studying the presence of (conjunctions of) criticality phenomena and their relation to traffic conflicts -as well as a practical evaluation of the competency questions A4 and T1 to T3.An in-depth semantic analysis of large-scale intersection scenarios over a variety of criticality phenomena enables insights into the complex operating contexts of urban ADSs prior to system design.Furthermore, a first evaluation demonstrated the method's feasibility on a drone data set.However, its transferability to live settings under real-time constraints, e.g. for monitoring of ODD boundaries defined via criticality phenomena, is yet to be examined.Incorporating a vehicle perspective (instead of the actor-agnostic view of drones) implicates the necessity of theoretically and practically addressing incomplete and uncertain knowledge about the environment originating from vehicle sensor data.Eventually, the results of this method can be used for safeguarding specific system designs.Future work has to address a rigorous analysis of the relation between criticality phenomena and criticality metrics as well as how these results can be used for the system's hazard analysis and risk quantification.
Theoretically, we based the presented approach on DLs as well as rules and identified them as a suitable formalism to represent and reason on abstract knowledge about road traffic.
For this theoretical aspect of the work, it remains an open question how to formalize knowledge about concrete domains directly in DLs.For the examined application of A-Box reasoning, we have tackled this challenge by means of augmentations that annotate existing spatio-temporal relations, but methodically, an integration into the logical framework is preferable.In the case of more abstract T-Box reasoning, it is not only preferable, but also mandatory to incorporate spatiotemporal semantics.For example, Allen's calculus states that meets•during ⊑ overlaps⊔during⊔starts, which is not a valid RIA in SROIQ (D) .In general, SROIQ (D) has been shown not to be able to represent the semantics of such calculi [35], i.e. relational composition tables, due to the lack of e.g.role negations.At least for RCC8, an alternative formalization using GCIs was proposed [40] and prototypically implemented [41], although the work seems to be abandoned.Therefore, theoretical advances need to address the incorporation of spatio-temporal semantics into the reasoning process, e.g. by integrating qualitative reasoning frameworks.
We furthermore presented an implementation of the proposed method and evaluated a prototype on the large and multi-faceted A-Boxes of the inD drone data set.
Practically, we found that reasoners, albeit mature, currently diminish in viability, leaving many of the available tools unmaintained.Another practical aspect concerns the extensive space and time consumption of the PELLET reasoner when running on the large A-Boxes of inD, and hence potential performance improvements by e.g.extending the idea of A-Box slicing.Alternatively, one refrain from using DL reasoners for inferring temporal properties.Scenarios can still be sliced, but analyzed with a solver for a scenario language.
Lastly, the work has two assumptions: First, we assumed crisp terminological concepts within the T-Box.Second, the A-Box was considered perfectly representing ground truth.
The first issue ignores that the OD model represents inherently fuzzy knowledge of humans -e.g.'heavy rain' may not have a crisp boundary.Representations of knowledge need to acknowledge vagueness within the T-Box and incorporate it into the reasoning process.The second issue concerns the applicability when presented with uncertain inputs.Here, one has to propagate those perception uncertainties along the inferences made by the reasoner.For a meaningful contribution to verification and validation, it is therefore imperative to both regard vagueness at design time and uncertainties at run time.

APPENDIX EVALUATED CRITICALITY PHENOMENA
We now display the formalization of the examined criticality phenomena as introduced in Table III.Employed concepts are only traced one layer down their recursive formalization.Basic concepts are marked by b .Concepts that are augmented by an algebraic or first order logic formalization are indicated by := instead of the DL operators ≡, ⊑, or ⊒.For this, we mix first-order predicate logic with DL and algebraic operations.Semantically, this is to be understood as a first order logic formula over the corresponding algebraic or geometric theory where the DL fragments, e.g.∃has traffic entity.{Ai }, represent sets of individuals on which we use set operators.These formulae are implemented using the augmentation library.We rely on some geometrical notation, listed in Table VI.We restrict the geometries to two dimension in Euclidean space and assume a single coordinate system.
Overall, the algebraic and geometric formalizations are based on the notation depicted in Table VII.
For an additional overview,  The diameter of the geometry g i (m) p f l i , p f r i , p br i , p bl i The front left, right and back left, right points of the geometry g i (assuming a given yaw θ The euclidean distance between two points (m) area(g i ) The area of the geometry g i (m²) points(g i ) The set of points of the geometry g i ray(p, θ) A ray (half-line) starting from p with angle θ circle(p, r) A circle around p with radius r centroid(g i ) The centroid point of the geometry g i polygon(P ) The polygon spanned by a tuple of points P   The passing activity is augmented using finite look back from the current scene s i , searching for a scene s j and scenes s k between s i and s j satisfying the passing constraint.O ∈ (∃in traffic model.{si }) ∧ ∃s j ∈ (∃before.{si }).∃A j ∈ (∃in traffic model.{sj } ⊓ ∃identical to.{A i }).∃O j ∈ (∃in traffic model.{sj } ⊓ ∃identical to.{O}).
O j ∈ (∃is in proximity.{Aj }) ∧ O j ∈ (∃in front of.{A j })∀s k ∈ (∃after.{sj } ⊓ ∃before.{si }).∃t < t H .∃p ∈ {p f l i , p f r i }.pos ω (p, s i , θ i , t) = x} where pos ω (p i , s i , θ i , t) := p i + s i • t • (cos(θ t i ), sin(θ t i )) and 2 ) else and t H is a time horizon (set to 1 s). Figure 10 shows two relevant areas and their intersection (in red).Our two-dimensional approach is visualized in Figure 11.We over approximate occlusions by assuming a circular field of view with some visibility range r for an analyzed subject, i.e. fov(A i ) := {x ∈ R 2 | ||c i − x|| ≤ r}.c i is the point where the sensing of A i is assumed to be located.For simplicity, .
For a given opaque entity of non-zero height with its polygon exterior g and a subject A i , the left-and rightmost points and relative angles from the viewpoint of c i are: • is occluded for(N, A), • is occluded by(N, O 1 ), . . ., is occluded by ( , Daytime, Pick-Up, Children, Behavior, Unpredictability, Acceleration, . . .

Fig. 1 .
Fig.1.Exemplary interaction of criticality phenomena and metrics in traffic conflicts, based on an ontology.Criticality phenomena are hatched, metrics are white.TTB is the time to brake, areq is the maximum required deceleration.

Definition III. 4 (
Vocabulary).A vocabulary is a triple N = (N R , N C , N I ) of sets of role names N R , concept names N C , and individual names N I .Definition III.5 (Ontology).An ontology over a vocabulary N is a tuple O = (T , A), where • T is a finite set of terminological assertions (called T-Box), namely general concepts inclusions (GCIs) such as C ⊑ C ′ for two concept names C, C ′ ∈ N C as well as role inclusion axioms (RIAs) such as r ⊑ r ′ for two role names r, r ′ ∈ N R , and • A is a finite set of concept and role assertions (CAs and RAs) (called A-Box), such as C(x) and r(x, x ′ ) for x, x ′ ∈ N I , C ∈ N C , and r ∈ N R .

Fig. 2 .
Fig. 2. Schematic representation of the role of an ontology in developing and safeguarding complex systems in open contexts.

Fig. 3 .
Fig. 3. Model of the relevant concepts and relations of the competency questions.A solid edge with solid tip is a custom relation, a solid edge with open tip is the subsumption relation, and a dashed edge is a definition.

Fig. 5 .
Fig. 5.The modular architecture of the Automotive Urban Traffic Ontology.
which reduces A to an A-Box A si with only individuals of scene s i , i.e.A si := {α ∈ A | ∃n ∈ ind (α) : (∃has traffic entity −1 .{si })(n)}.• MERGE(A 1 , . . ., A n ), whose result is roughly equal to i∈{1,...,n} A i , but special temporally constant individuals (e.g.lanes) are not merged as to avoid duplicates.Temporal identity is added by the MERGE(•) algorithm Algorithm 2 Temporal inference Input: an ontology O = (T , A) with exactly one scenario s and scenes s 1 . . .s n in A Output: O including inferred facts for s 1: procedure DO TEMPORAL REASONING 2:

Fig. 9 .
Fig.9.The computed criticality metrics and inferred criticality phenomena for the exemplary scenario between both traffic participants over time.

Fig. 10 .
Fig. 10.The relevant areas of two vehicles in a following scenario.j) Strong Braking Maneuver (CP 103): Strong braking maneuvers are inferred based on the driven vehicle type.Motorized Road Vehicleb (v) ∧ has acceleration b (v, a) ∧a < −4.61 → CP 103 (v) Bicycle b (v) ∧ has acceleration b (v, a) ∧ a < −3.3 → CP 103 (v)k) High Relative Speed (CP 163): CP 163 is a vehicle with high relative speed, i.e.CP 163 ≡ ∃object CP163 .⊤withobject CP163 (A 1 , A 2 ) := ||v 1 − v 2 || 2 min(s rule max , s A1 max ) ≥ 0.25where s rule max is the maximum allowed speed and s A1 max is the estimated maximum speed capability of A 1 .l)Occlusion (CP 25): Occlusions are modeled as n-ary relations, allowing multiple occluding objects.CP 25 is the reified occlusion relation, i.e.CP 25 ≡ Is Occlusion.Our two-dimensional approach is visualized in Figure11.We over approximate occlusions by assuming a circular field of view with some visibility range r for an analyzed subject,

Fig. 11 .
Fig. 11.Visualization of occlusions on an inD scene.Occluded areas are orange, occluding objects are blue, and the observer is a purple dot.

TABLE I COMPETENCY
QUESTIONS OF THE PROPOSED ONTOLOGY.QUESTIONS WITH BOLD-FACED IDENTIFIERS ARE FOCUSED ON IN THIS WORK.
T2 Scenario ⊑ SCP 1 ⊔ • • • ⊔ SCP n Completeness of a set of scenario classesIs the scenario space decomposition into right and left turn maneuvers complete?T3

TABLE II DETACHED
, RELATED ONTOLOGIES OF THE 6LM USED WITHIN A.U.T.O.
3) An over approximation: an over approximation is specified by a GCI CP X ⊑ f (C k , . . ., C l ).Combined with an under approximation, it allows for a two-sided bound.For example, 'Occluded Pedestrian' (CP 157) can be exactly formalized assuming that Pedestrian, Is Occlusion, and is occluded are exactly formalized or basic concepts: CP 157 ≡ Is Occlusion ⊓ ∃is occluded.PedestrianThe phenomenon 'Misconduct' (CP 143) on the other hand has a broad scope.We hence model certain aspects of it, such as driving without vehicle lights turned on in night scenarios: CP 143 ⊒ (Off Light Vehicle ⊓ ∃in traffic model.Night Scenario) ⊔ CP 69 Similarly, 'Vulnerable Road User with Road Access' (CP 114), contains the vague concept Road Access, which was over approximated in terms of is near.It is formalized as CP 114 ⊑ Vulnerable Road User ⊓ ∃is near.Driveable Lane.Such approximations can be iteratively refined.

TABLE IV INFERRED
CRITICALITY PHENOMENA (CP) RELATIVE TO THE NUMBER OF TRAFFIC PARTICIPANTS (TP) AND SCENES OVER THE SELECTED 16 SCENARIOS, ARRANGED BY INTERSECTION (INT.).
The inferred criticality phenomena over time of a 6.6 second scenario with one moving vehicle, one pedestrian, and eight parking vehicles.The subject (and objects) are annotated by gray boxes on each criticality phenomenon.Occ. by = Occluded by and Passing Park.Veh.= Passing of Parking Vehicles.
00 − n 10 n 01 (n 10 + n 11 ) • (n 00 + n 01 ) • (n 00 + n 01 ) • (n 01 + n 11 ) Table VIII presents a listing of all employed target values for criticality phenomena where thresholds have been applied or used within their concepts.
a) Pedestrian Crossing / Ford (CP 117): CP 117 is defined as the disjunction of pedestrian crossings and fords.CP 117 ≡ Pedestrian Crossing b ⊔ Pedestrian Ford b

TABLE VI EMPLOYED
GEOMETRICAL NOTATION AND FUNCTIONS.
TABLE VII EMPLOYED MATHEMATICAL IDENTIFIERS INCLUDING THEIR CORRESPONDING DL REPRESENTATION (IN A.U.T.O.).

TABLE VIII TARGET
VALUES FOR EACH CRITICALITY PHENOMENON (CP).CP 181 is under-approximated by the (not exhaustive) union of retirement homes, schools, and kindergartens.