Ontology of autonomous driving based on the SAE J3016 standard

Abstract

Autonomous driving is a recently developed area in which technology seems to be ahead of its understanding within society. That causes some fears concerning the reliability of autonomous vehicles and controversies over liability in case of accidents. Specifying levels of driving autonomy within the SAE-J3016 standard is widely recognized as a significant step towards comprehending the essence of the achievements. However, the standard provides even more valuable insights into the process of driving automation. In the paper, we develop the ideas using the methods of formal ontology that allow us to make the conceptual system more precise and formalize it. To increase inseparability, we ground our system on a top-level BFO ontology. We present a formal account of several areas covered by the SAE-J3016 standard, including motor vehicles and their systems, driving tasks and subtasks, roles of persons in road communication, and autonomy levels.

Keywords

Autonomous driving autonomous vehicle self-driving car BFO

1. Introduction

Automation of driving is an emerging technology that has evoked significant public interest. The technology offers economic gains and improvements in traffic safety and efficiency. Still, concerns over the technology’s reliability and controversies over liability assignment in inevitable cases of traffic incidents raise some fears. To achieve a satisfactory level of social acceptance of the technology, it is essential to build a sound and clear conceptual framework to discuss it.

While determining levels of autonomy presented in [17,18] is essential in building a sound and clear conceptual framework, the demand for higher terminological clarity is expressed in the community c.f. [10]. There are debates about the adequacy of the definitions of levels of automation, and the original standard may ignore some important distinctions for an adequate description of the area.

The paper’s primary purpose is to present an ontology built upon the standard Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles, SAE-J3016. By “ontology”, we mean a logical model specifying the meaning of the standard’s terms. The ontology aims to introduce explicit distinctions and provide a proper formal specification that makes the terms used in the standard unambiguous. The work proposes using a top-level ontology to increase interoperability and better understand the most general concepts. The ontology’s novelty is that it receives a machine-readable form that allows for its direct use in information systems. Our work on applying ontological methods to SAE-J3016 is part of a broader effort of ontologization of industrial norms. Let us mention some other examples. Several ontologies of security management based on ISO 27000 series standards are reviewed in [11]. The scope of the project Identification of Medicinal Products (IDMP) run by EDMC1

¹
https://spec.edmcouncil.org/idmp/

includes several ISO standards (ISO-11238, ISO-11239, ISO-11240, ISO-11615, ISO-11616, ISO-21090) concerning substances, forms, doses, units of measurement, packaging, product information, and data types in medical informatics. [30] presents an ontology of beef cuts based on UNECE standards.

As for the ontology-building methodology, the main choice we have made is to ground our ontology of autonomous driving on a top-level ontology. We have chosen Basic Formal Ontology (BFO) for that purpose. Consequently, we have followed OBO Foundry principles that underlie BFO [2]. The ontology was validated on several levels. Firstly, we have ensured that the definitions provided by the SAE-J3016 standard have their just representation in the ontology. This was done by carefully mapping the concepts and definitions in the standard to the corresponding elements in our ontology. Secondly, we have validated the ontology by using it to adequately describe the examples given in the standard. We present a detailed analysis of one of these examples in the paper. And finally, we checked the consistency of the DL/OWL representation of the ontology.

The paper has the following structure. We start by discussing related works and present the problem statement, including the goals and requirements, in Sections 2 and 3, respectively. The following sections, ordered as Sections 4 through 8, detail the content of the ontology. First, we introduce the essentials of the Basic Formal Ontology (BFO) as a general framework for driving automation in Section 4. Then, in Section 5, we describe types of motor vehicles and their systems, with a focus on driving automation systems (DAS) and their features. In Section 6, we examine the dynamic driving task (DDT) as a capability that can be realized by either a dynamic automation system or a human driver in operating a motor vehicle. Additionally, in Section 7, we discuss the possible roles of humans in advanced driving technology, including an illustrative example of a role-changing situation during a motor vehicle operation. Finally, we introduce the five levels of driving automation into the ontology as different ways of sustained vehicle operation in Section 8. The paper concludes with a discussion of future work.

2. Related works

There are many research areas related to this paper. Among them, we would like to distinguish works on formal ontologies of the automotive domain, standards similar to SAE-J3016, other works commenting on the standard, expanding and criticizing it, and ontological works based on other industrial standards from different domains.

Several ontologies were proposed in the different areas of the automotive domain. Probably, the extension of schema.org to the automotive domain2

²
https://schema.org/docs/automotive.html

is the best known and most often used among them. The main purpose of schema.org is to conceptually organize annotations of web pages to support semantic search over the internet. Thus, the automotive extension contains vocabulary (types and properties) relevant to describing car-selling offers, allowing for detailed specifications of the car’s interior and exterior. Use cases include sales offers for new and used cars, the latter also with damages, and car rental offers.

Another two ontological projects we want to mention here have a different nature. They contribute to the technical specification of cars themselves. One of them is Vehicle Signal Specification Ontology (VSSo).3

https://www.w3.org/TR/vsso/

It provides an ontological account of the standard catalog of signals indicating the state of a car and car systems at a certain moment, including, e.g., car dashboard warnings. In the other one, a set of ontologies, including Car Ontology, Control Ontology, and Map Ontology prepared for the sake of ontology-based Advanced Driver Assistance Systems is proposed [31]. Car Ontology contains information about the vehicles and their equipment. Control Ontology represents the actions taken by autonomous cars. Map Ontology describes the space in which vehicles move. It is an inventory of the entities that make up road networks, e.g., intersections and roads. None of the ontologies covers the scope of SAE-J3016, and none of them can help define autonomous driving. Thus, creating a new ontology based on the standard in which the levels are defined seems to be the optimal way of achieving the goals of the present paper.

As for the industrial standards, many of them are related to SAE J-3016, covering a similar area, extending it, and concerning relevant issues. Some of them are issued by the same organization. Worth mentioning among them are Vehicular Communication [16], Active Safety Systems Terms And Definitions [19], Active Safety System Sensors [20], Human Factors Definitions for Automated Driving and Related Research Topics [21] and Ontology and Lexicon for Automated Driving System (ADS)-Operated Vehicle Behaviors and Maneuvers in Routine/Normal Operating Scenarios [22]. SAE also publishes a series of papers resulting from the works of the Automated Vehicle Safety Consortium on best practices related to automated driving system design and evaluation: Best Practice for Metrics and Methods for Assessing Safety and Performance of Automated Driving Systems (ADS) [3] and Best Practice for Evaluation of Behavioral Competencies for Automated Driving System Dedicated Vehicles (ADS-DVs) [4].

From the standards issued by other institutions, let us mention Operational Design Domain (ODD) taxonomy for an automated driving system (ADS) – Specification [15] by the British Standards Institution (BSI) and A Framework for Automated Driving System Testable Cases and Scenarios [27] by National Highway Traffic Safety Administration (NHTSA) from the USA presenting a more detailed taxonomy of features within the SAE levels, ODD category descriptions and maneuver list. Expanding the ontological coverage of the area outlined by the aforementioned standards is a promising perspective for future works.

As SAE autonomy levels attracted significant public interest, many other scientific and popular publications commented on them, extending the scene with additional elements and insights and presenting criticism towards it. Let us mention a few of them. [29] discusses human-centered aspects of driving, introducing optional human user intervention concerning driving parameters and maneuvers within automated driving. Similarly, [14] discusses human-oriented notions related to driving, namely: driving style, driveability, driving behavior, and driving experience in the context of autonomous driving. They introduce the ontology in the form of textual definitions of the notions and diagrams. [7] discusses the role of the fallback-ready user in a car and proposes another level of automation based on how a request to intervene is organized.

[6] argue that the socio-technical perspective should have a more significant impact on the discourse on autonomous driving and that the role of SAE levels of autonomy underpinned by a techno-centric, expert-dominated logic is overestimated. [24], based on a set of surveys, claims that the SAE 6-level taxonomy confuses consumers. It proposes to use a simple binary framing driving vs. riding instead. [28] stresses the role of circumstances in which technology, self-driving cars, in particular, have an impact on our life. It says that the conceptualization, like the SAE levels of autonomy, that does not refer to the final goals of users cannot be a good roadmap for the development of the technology.

3. Problem statement and objectives

The Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles [17,18] standard goes beyond merely providing a classification of the levels of autonomy in driving automation. It also provides a comprehensive vocabulary for the domain of driving automation, including definitions of essential concepts in the field. However, recent studies [7,28] suggest that some of the definitions provided by the standard may be misleading in specific contexts and require re-evaluation, especially given the growing public interest in autonomous vehicles and the need to shape the technological future of the automotive industry.

Despite these concerns, SAE-J3016 is widely recognized as the industry’s most-cited reference for automated vehicles [6,9], and other relevant documents, such as those issued by the BASt or NHSTA, refer to it and accept its principles [6]. As a result, we chose to base our ontology on SAE-J3016. We see our work as another step towards clarification of the nomenclature concerning different levels of autonomy of driving. This is particularly important given the growing public interest in autonomous vehicles and the need to shape the future of the automotive industry.

Through our analysis of the standard, we discovered that it overlooks some critical distinctions necessary for accurately describing the domain, such as the distinctions between roles and agents that hold them, between functions, capabilities, and processes that realize them, and between systems and their features. Our proposed ontology explicitly introduces these distinctions and provides formal specifications for the terms used in the standard to ensure unambiguous interpretation. Our work is also a machine-readable version of the standard that, as such, can be directly incorporated into information systems.

To enhance interoperability and gain a better understanding of the most general concepts, we grounded our ontology on a foundational ontology. Foundational ontologies address very general concepts that apply to all domains, including the domain of autonomous driving. Understanding the top classes of our ontology requires moving beyond the autonomous vehicle ontology, which is precisely a foundational ontology’s role. We chose Basic Formal Ontology (BFO) [2] as our foundational ontology, as specified in ISO/IEC 21838-2:2021.4

⁴
https://standards.iso.org/ittf/PubliclyAvailableStandards/c074572_ISO_IEC_21838-2_2021(E).zip

One reason for this choice is that BFO offers an insightful account of functions and dispositions [12,26], which are crucial for our considerations. Additionally, BFO is gaining recognition in the community, as evidenced by its selection for the Industrial Ontologies Foundry project [8].

In the paper, we will use Description Logic as a formal tool to specify autonomous driving vocabulary standardized in SAE J3016. The OWL counterpart of the formalization is available in the GitHub repository.5

⁵

https://github.com/kul-ai/ontology-autonomous-driving

4. Short introduction to the BFO categories used in this paper

BFO divides all entities into continuants and occurrents (see Fig. 1). Continuants are entities that persist through time (e.g., a motor vehicle), whereas occurrents unfold themselves in time (e.g., a sustained operation of a vehicle).

Fig. 1.

This figure illustrates the key categories and their interrelations within the Basic Formal Ontology (BFO). Central to the BFO are two primary divisions: ‘continuant’ and ‘occurrent.’ The ‘continuant’ encompasses entities that endure over time, including subcategories such as ‘object’ and ‘specifically dependent continuant’. A notable relationship is highlighted between ‘object’ and ‘specifically dependent continuant’, defined by the properties ‘inheres in’ and ‘is bearer of.’ the term ‘inheres in’ indicates that a ‘specifically dependent continuant’ is always associated with a specific object, while ‘is bearer of’ clarifies that an object provides a foundation or support for a ‘specifically dependent continuant’, indicating the dependency of the ‘specifically dependent continuant’ on the object for its existence. Further, the ‘object’ category is linked to ‘process’ (a branch of ‘occurrent’) through the relationship ‘has participant at some time,’ suggesting that objects are involved in processes at certain times. Within the ‘realizable entity’ category, which includes ‘role,’ ‘disposition,’ ‘function,’ and ‘capability,’ there are connections to ‘process’ through ‘has realization’ and ‘realizes,’ showing that these entities come into effect or are actualized within processes. Under ‘specifically dependent continuant’, ‘quality’ is described as the attributes or characteristics inherent to continuants.

An object is a special kind of continuant that does not depend in its existence on any other entity through its whole life, is material, maximally self-connected, and manifests causal unity. Persons, as well as vehicles and their parts, are examples of objects.

Unlike objects, specifically dependent continuants depend for their existence on one or more independent continuants called their bearers. Objects are bearers of specifically dependent continuants, such as qualities and realizable entities. Among realizable entities, we have roles (e.g., a human driver) and dispositions (e.g., monitoring the driving environment). We also say that roles and dispositions inhere in objects (or, more generally, in the independent continuants).

Qualities are realized whenever they exist, i.e., whenever they inhere in some object. For instance, the weight or height of a vehicle are qualities. Realizable entities can exist but need not be realized. Realizable entities are realized in processes and are triggered by processes. For instance, a dynamic driving task that we believe is a realizable entity is realized in a driving process and is triggered when someone gets the motor vehicle’s engine started. Realizable entities can be externally grounded (to the bearer) as roles or internally grounded as dispositions, capabilities, or functions.

A role exists because its bearer is placed in special physical, social, or institutional circumstances. The bearer does not have to be in such circumstances, and no physical change within the bearer necessarily occurs when the role appears or ceases to exist. To cite one example from the standard [18, p.4]: “a driver who fails to monitor the roadway during engagement of a Level 1 adaptive cruise control (ACC) system still has the role of driver, even while s/he is neglecting it.” By referring to roles, we can make this statement precise by saying that what makes a person to bear the role of driver is a set of circumstances s/he is in, i.e., being in the car “during engagement of a Level 1 adaptive cruise control (ACC) system”; monitoring the roadway is not relevant for the role attribution.

Dispositions, as roles, inhere in material entities. Unlike the case of roles, where a bearer can easily enter a role and step out of it, gaining or losing a disposition is related to physical changes. We can say that a Driving Automation System has certain dispositions (e.g., lateral driving control). It can lose the disposition due to system failures caused by physical changes (malfunctioning). Realization of a disposition occurs when and because its bearer is in some special physical circumstances, but this realization is strongly based on their physical makeup. For example, consider a car with the disposition of being able to move (e.g., it has a functioning engine, wheels, etc.). This disposition is realized when the car is actually moving, which occurs when and because the car is in some special physical circumstances (e.g., the engine is running, the wheels are turning, etc.). The realization of this disposition is strongly based on the car’s physical makeup (e.g., it has an engine that can convert fuel into motion, wheels that can roll, etc.).

A disposition is a capability as long as its realization brings about or helps bring about a state of affairs in which its bearer, or a user of that bearer in the case of artifacts, has an interest. So, having a capability means that it is useful for some purpose.6

⁶

We would like to stress that the capability category does not belong to the BFO as standardized by ISO/IEC 21838-2:20211. Our way of understanding the category complies with how it is currently approached by the BFO community, see [12].

For example, a car’s main capability is “providing conveyance on public roads”. It is a disposition of the car that is useful for the car’s users. The capability can be realized when needed, e.g., when transporting someone or something from place A to B is needed. The realization of this disposition brings about the state of affairs that is “being in place B”.

A function is a disposition whose realization is an end- or goal-directed activity of its bearer that exists in the bearer because of its specific physical makeup as a result of intentional design in the case of artifacts [2, p.179]. A designed function is an object’s disposition because it was designed to do a certain thing (to realize the function). We consider the driving automation system (DAS) features, such as parking assistance feature or adaptive cruise control, to be functions. Every function is associated with a type of process whose instances are realizations of that function (parking, conditional driving automation). Functions are often close in their naming to processes that realize them (they are often used interchangeably in the SAE standard), e.g., parking assistance.

We will rather talk about the functions of the components of a system or a vehicle. If a vehicle component has a function, we do not say that the vehicle itself has this function. Still, we can say that the vehicle has the capability related to this component function (see [12]).

We shall use Description Logic (DL) as a formal tool to express dependencies between categories. BFO’s categories become the DL concepts. How the concepts relate to the BFO classes we use in our formalization is shown in Table 1 (see also Fig. 1). As the table makes explicit, we will use no more than seven BFO categories directly.

Table 1

Names of the BFO’s classes we use in our formalization

Autonomous driving ontology class	BFO URI	BFO label
Function	obo:BFO_0000034	function
Object	obo:BFO_0000030	object
Process	obo:BFO_0000015	process
Quality	obo:BFO_0000019	quality
RealizableEntity	obo:BFO_0000017	realizable entity
Role	obo:BFO_0000023	role
SpecificallyDependentContinuant	obo:BFO_0000020	specifically dependent continuant

Below, we introduce the BFO properties we shall use and basic notions and conventions. Table 2 collects the BFO properties we shall use in our formalization. Their meaning is specified in BFO.

Table 2

Names of the BFO’s properties we use in our formalization

Autonomous driving ontology property	BFO URI	BFO label
hasOccurentPart	obo:BFO_0000117	has occurrent part
hasPart	obo:BFO_0000174	has proper continuant part at some time
hasParticipant	obo:BFO_0000057	has participant at all times
inheresIn	obo:BFO_0000197	inheres in
isBearerOf	obo:BFO_0000196	bearer of
isOccurentPartOf	obo:BFO_0000132	occurrent part of
isPartOf	obo:BFO_0000175	proper continuant part of at some time
isPrecededBy	obo:BFO_0000062	preceded by
occuresIn	obo:BFO_0000066	occures in
realizedIn	obo:BFO_0000054	has realization
realizes	obo:BFO_0000055	realizes

Domains and ranges of the properties have been restricted to the BFO categories we have used in our formalization. The formula $\exists R . ⊤ ⊑ C$ expresses the fact that relation R has a domain C. To express the same statement in a slightly more friendly way, we shall use the following notation: $\begin{matrix} (1) & Domain (R) = C \end{matrix}$ Similarly, the formula $⊤ ⊑ \forall R . D$ stands for the fact that concept D is the range of relation R, but we shall rather write: $\begin{matrix} (2) & Range (R) = D \end{matrix}$ $R^{_}$ stands for the inverse of R. Below, we list self-explanatory statements about BFO properties. $\begin{array}{c} (3) & Domain (inheresIn) = RealizableEntity \\ (4) & Range (inheresIn) = Object \\ (5) & isBearerOf \equiv {inheresIn}^{_} \\ (6) & Domain (hasParticipant) = Process \\ (7) & Range (hasParticipant) = Object \\ (8) & Domain (realizedIn) = RealizableEntity \\ (9) & Range (realizedIn) = Process \\ (10) & realizes \equiv {realizedIn}^{_} \\ (11) & Domain (hasPart) = Object ⊔ RealizableEntity \\ (12) & Range (hasPart) = Object ⊔ RealizableEntity \\ (13) & isPartOf \equiv {hasPart}^{_} \\ (14) & Domain (hasOccurentPart) = Process \\ (15) & Range (hasOccurentPart) = Process \\ (16) & isOccurentPartOf \equiv {hasOccurentPart}^{_} \\ (17) & Domain (isPrecededBy) = Process \\ (18) & Range (isPrecededBy) = Process \\ (19) & Domain (occuresIn) = Process \\ (20) & Range (occuresIn) = Object \end{array}$

5. Motor vehicles and their systems

5.1. Types of motor vehicles

Motor vehicle [18, 3.32] is a mechanically powered object designed to provide conveyance on public streets, roads, and highways. Understanding of the concept is compatible with [1, ANSI-D.16-2017, Section 2.2.7] and follows 49 U.S.C. § 30102(a)(6) (definition of motor vehicle) [13]. We do not distinguish between internal combustion and electric vehicles since vehicles of both kinds can be equipped with driving automation systems.

A motor vehicle is a BFO object, i.e., a maximal causally unified material entity: $\begin{matrix} (21) & \begin{array}{r} MotorVehicle ⊑ Object \end{array} \end{matrix}$ Providing conveyance on public roads is the main vehicle’s capability: $\begin{matrix} (22) & \begin{array}{r} MotorVehicle ⊑ \exists isBearerOf . ProvidingConveyanceOnPublicRoads \end{array} \end{matrix}$ The capability is realized in the driving process. Since we focus only on motor vehicles, the driving process we have in mind is always the operation of a motor vehicle.

In [17,18], we find a distinction between conventional, ADS-equipped, ADS-dedicated, and ADS-equipped dual-mode motor vehicles (ADS stands for Automated Driving Systems). The relations between these types of vehicles is presented in Fig. 2. Conventional vehicle [17, 3.5], [18, 3.32.1] is a motor vehicle designed to be operated by an in-vehicle (aka conventional) driver during part or all of every trip. $\begin{matrix} (23) & \begin{array}{r} ConventionalVehicle \equiv MotorVehicle ⊓ \exists isBearerOf . BeingOperatedByInVehicleDriver \end{array} \end{matrix}$

Fig. 2.

Types of motor vehicles.

Being operated by an in-vehicle driver is a capability: $\begin{matrix} (24) & \begin{array}{r} BeingOperatedByInVehicleDriver ⊑ Capability \end{array} \end{matrix}$ It can be realized only in the sustained operation of a vehicle performed by an in-vehicle driver. $\begin{aligned} BeingOperatedByInVehicleDriver & ⊑ \forall realizedIn . (SustainedOperationOfVehicle \\ (25) & ⊓ (\exists isPerformedBy . InVehicleDriver)) \end{aligned}$

A motor vehicle can be equipped with many vehicle systems, such as active safety systems or driving automation systems (including automated driving system). Some of the systems are designed only to support drivers, whereas the automated driving system is designed to turn a vehicle into an autonomous agent. The more systems with certain functions a motor vehicle is equipped with, the larger the capability it gains. $\begin{matrix} (26) & \begin{array}{r} MotorVehicle ⊑ (⩾ 0 isEquippedWith . VehicleSystem) \end{array} \end{matrix}$

ADS-equipped vehicle [17, 3.5], [18, 3.32.1] is a motor vehicle equipped with an automated driving system. $\begin{matrix} (27) & \begin{array}{r} ADSEquippedVehicle \equiv MotorVehicle ⊓ (\exists isEquippedWith . AutomatedDrivingSystem) \end{array} \end{matrix}$

The property isEquippedWith is a specialization of BFO’s hasPart property and relates a motor vehicle with a vehicle system. $\begin{matrix} (28) & isEquippedWith ⊑ hasPart \end{matrix}$

It is worth stressing that an ADS-equipped vehicle can still be a conventional vehicle if “an in-vehicle driver is required for at least part of every trip” (see [17, 3.5, NOTE 2], [18, 3.32.1, NOTE 2]).

ADS dedicated vehicle [17, 3.3], [18, 3.32.3] is an ADS-equipped vehicle designed for driverless operation under routine/normal operating conditions during all trips within its given operational design domain (ODD), if ODD is specified.7

⁷

See the last paragraph of Section 7.2 for an explanation of the ODD class.

\begin{matrix} (29) & \begin{array}{r} ADSDedicatedVehicle \equiv ADSEquippedVehicle ⊓ \exists isBearerOf . DriverlessOperationCapability \end{array} \end{matrix}

Driverless operation capability is a capability: $\begin{matrix} (30) & \begin{array}{r} DriverlessOperationCapability ⊑ Capability \end{array} \end{matrix}$ It is realized in a driverless operation process. $\begin{matrix} (31) & \begin{array}{r} DriverlessOperationCapability ⊑ \exists realizedIn . DriverlessOperation \end{array} \end{matrix}$ However, in some special situations (e.g., a system failure), an ADS-dedicated vehicle can be operated by a human driver (see [17, 3.3, NOTE 4], [18, 3.32.3, NOTE 3]).

ADS dedicated vehicle can be dispatched in a driverless operation by a dispatcher: $\begin{aligned} ADSDedicatedVehicle & ⊑ (⩾ 0 isDispachedIn . (DriverlessOperation \\ (32) & ⊓ (\exists isDipachedBy . DriverlessOperationDispatcher))) \end{aligned}$

ADS-equipped dual-mode vehicle [17, 3.12], [18, 3.32.2] is an ADS-equipped vehicle designed to enable either driverless operation under routine/normal operating conditions within its given ODD (if any), or operation by an in-vehicle driver, for complete trips. $\begin{aligned} ADSEquippedDualModeVehicle & \equiv ADSEquippedVehicle \\ ⊓ \exists isBearerOf . DriverlessOperationCapability \\ (33) & ⊓ \exists isBearerOf . BeingOperatedByInVehicleDriver \end{aligned}$ From definitions (23), (29) and (33) follows that ADS-equipped dual-mode vehicle is both a conventional vehicle and an ADS-dedicated vehicle.

We assume, however, that there are no processes that can realize both a driverless operation capability and a being operated by an in-vehicle driver capability: $\begin{matrix} (34) & \begin{array}{r} \exists realizes . DriverlessOperationCapability ⊑ \neg (\exists realizes . BeingOperatedByInVehicleDriver) \end{array} \end{matrix}$

Intuitively, contrary to our definitions, the three classes: ConventionalVehicles, ADSDedicatedVehicles and ADSEquippedDualModeVehicles may be regarded as disjoint. ConventionalVehicles are designed to be normally operated only by in-vehicle (human) drivers, ADSDedicatedVehicles are designed to be normally operated only by ADS, and ADSEquippedDualModeVehicles possess capabilities for both operating modes and are designed in such a way that their users may choose the way a vehicle is operating. However, a formal account of such intuition causes a serious difficulty concerning ADSDedicatedVehicles: formalizing the intuitive notion of normal conditions. That notion is not precisely defined in the SAE standard, and we cannot provide such a definition either. Instead, we focus on vehicle capabilities: a conventional vehicle has full capabilities for human driving for the whole trip, an ADS dedicated vehicle – for automated driving for the whole trip, and a dual-mode vehicle – for both types of driving.

5.2. Driving automation system (DAS) and its features

A vehicle system is a system (i.e., the hardware and software) that is a part of a motor vehicle. $\begin{matrix} (35) & \begin{array}{r} VehicleSystem ⊑ \exists isPartOf . MotorVehicle \end{array} \end{matrix}$

A vehicle system can perform driving-relevant tasks, which we define while defining subclasses of the vehicle systems. Active safety system and driving automation systems are vehicle systems. They can support the driver but cannot perform part or all of the dynamic driving task (DDT).

Driving automation system (DAS) [17, 3.8], [18, 3.6] is a vehicle system: $\begin{matrix} (36) & \begin{array}{r} DrivingAutomationSystem ⊑ VehicleSystem \end{array} \end{matrix}$ It is capable of performing part or all of the dynamic driving task on a sustained basis. $\begin{aligned} DrivingAutomationSystem & ⊑ \forall performs . (\exists realizes . (DynamicDrivingTask \\ (37) & ⊔ DynamicDrivingSubtask)) \end{aligned}$

DAS performs only driving automation processes and requests to intervene. $\begin{matrix} (38) & \begin{array}{r} DrivingAutomationSystem ⊑ \forall performs . (DrivingAutomation ⊔ RequestToIntervene) \end{array} \end{matrix}$

DAS may be a bearer of operational design domain [17, 3.22], [18, 3.21] that is a quality of the DAS that by design restricts its indented usage to some conditions “including, but not limited to, environmental, geographical, and time-of-day restrictions, and/or the requisite presence or absence of certain traffic or roadway characteristics”. $\begin{matrix} (39) & \begin{array}{r} DrivingAutomationSystem ⊑ (⩾ 0 bearerOf . OperationalDesignDomain) \end{array} \end{matrix}$

Operational design domain inheres in a DAS: $\begin{matrix} (40) & \begin{array}{r} OperationalDesignDomain ⊑ Quality ⊓ \exists inheresIn . DrivingAutomationSystem \end{array} \end{matrix}$

DAS is a bearer of DAS features. $\begin{matrix} (41) & \begin{array}{r} DrivingAutomationSystem ⊑ \exists isBearerOf . DrivingAutomationSystemFeature \end{array} \end{matrix}$

Driving automation system (DAS) feature [17, 3.9], [18, 3.7] is a function of driving automation system: $\begin{matrix} (42) & \begin{array}{r} DrivingAutomationSystemFeature ⊑ Function ⊓ \exists inheresIn . DrivingAutomationSystem \end{array} \end{matrix}$ DAS feature is realized in driving automation. $\begin{matrix} (43) & \begin{array}{r} DrivingAutomationSystemFeature ⊑ \forall realizedIn . DrivingAutomation \end{array} \end{matrix}$

Among DAS features, we have maneuver-based features, sub-trip features, and full-trip features. While full-trip features can be easily distinguished from the two others, the difference between maneuver-based and sub-trip features is not that obvious. SAE-J3016 does not give an explicit definition of maneuver; we can only read that it is a “narrowly defined use case” (SAE-J3016, 2021, 3.7.1). Among examples, we can find “parking a car” and “passing a slower moving vehicle on a public road”. Several useful, complementary definitions can be found in dictionaries, where the maneuver is presented as (1) a series of changes in direction and position for a specific purpose,8

⁸
http://merriam-webstercollegiate.com/dictionary/maneuver

(2) a movement or set of movements needing skill and care,9

⁹

https://dictionary.cambridge.org/dictionary/english/manoeuvre

(3) any skillful change of movement or direction in driving a vehicle, controlling a spacecraft, etc.10

¹⁰

https://world_en.en-academic.com/44139/maneuver

Moreover, the Automated Vehicle Safety Consortium (AVSC) Best Practice for Evaluation of Behavioral Competencies for Automated Driving System Dedicated Vehicles (ADS-DVs) defines maneuver as a “[g]oal-oriented vehicle motion control action undertaken by an ADS to achieve a specific result or outcome” [3, 3.6. Maneuver]. We can see that a maneuver is a goal-oriented process and requires skills. We can also add that a driving maneuver is triggered by certain road circumstances (like the presence of a slower-moving vehicle ahead) and has to be adjusted to those circumstances. Thus, its structure (beginning and end) is determined by the circumstances. The examples presented in SAE-J3016 documents show that the intended meaning goes there along the same lines. For a more technical discussion about car driving maneuvers and their catalog, see [23] and SAE-J3164 standard [22].

Sub-trips, on the other hand, are proper parts of a trip bounded by ODDs: “Sub-trip features require a human driver to operate the vehicle between the point-of-origin and the boundary of the feature’s ODD and/or after leaving the feature’s ODD” (SAE-J3016, 2021, 3.7.2). As examples of sub-trips, we have: traveling at higher speeds and driving in a traffic jam.

Having presented the intuitions on different kinds of fragments of trips, we can pass to the formal definitions. Maneuver-based feature [18, 3.7.1] is a DAS feature: $\begin{matrix} (44) & \begin{array}{r} ManeuverBasedFeature ⊑ DrivingAutomationSystemFeature \end{array} \end{matrix}$ It is realized to fulfill a specific, precisely defined use case, different from full driving automation and high driving automation:11

¹¹

“Full driving automation” and “high driving automation” are characterized in Section 8.2.2.

\begin{aligned} ManeuverBasedFeature & ⊑ \exists realizedIn . (DrivingAutomation \\ (45) & ⊓ \neg (FullDrivingAutomation ⊔ HighDrivingAutomation)) \end{aligned}

Realizing the maneuver-based feature involves the realization of functions such as lateral or longitudinal vehicle motion control, object and event detection and response (OEDR), or possibly other dynamic driving subtasks. Driver supervision can be required or not. Driver, depending on the level of driving automation, can also be involved in performing the rest of the DDT.

Sub-trip feature [18, 3.7.2] is a DAS feature: $\begin{matrix} (46) & \begin{array}{r} SubTripFeature ⊑ DrivingAutomationSystemFeature \end{array} \end{matrix}$ A human driver must perform the complete DDT for at least part of every trip. Here, we have functions that perform only part of a trip (so a trip as a context is required to talk about the sub-trip features). For example: “During a given vehicle trip, a user with a Level 4 automated parking feature dispatches the vehicle in driverless operation to find a parking space in a nearby designated parking facility. Following a period of shopping, the user retrieves the vehicle via dispatch to begin his/her trip home.” (see [18, 3.7.2, EXAMPLE 4]). $\begin{matrix} (47) & \begin{array}{r} SubTripFeature ⊑ \forall realizedIn . (\exists isPartOf . OperateMotorVehicle) \end{array} \end{matrix}$

A sub-trip feature cannot be realized by performing a full driving automation process: $\begin{matrix} (48) & \begin{array}{r} SubTripFeature ⊑ \exists realizedIn . (DrivingAutomation ⊓ \neg FullDrivingAutomation) \end{array} \end{matrix}$

A sub-trip feature depends on the operational design domain: $\begin{matrix} (49) & \begin{array}{r} SubTripFeature ⊑ \forall dependsOn . OperationalDesignDomain \end{array} \end{matrix}$

Full-trip feature [18, 3.7.3] is an ADS feature: $\begin{matrix} (50) & \begin{array}{r} FullTripFeature ⊑ DrivingAutomationSystemFeature \end{array} \end{matrix}$ It can be realized in high and full driving automation processes: $\begin{matrix} (51) & \begin{array}{r} FullTripFeature ⊑ \exists realizedIn . (HighDrivingAutomation ⊔ FullDrivingAutomation) \end{array} \end{matrix}$ that make up the complete trip: $\begin{matrix} (52) & \begin{array}{r} FullTripFeature ⊑ \exists realizedIn . OperateMotorVehicle \end{array} \end{matrix}$

The SAE standard also defines a driver support DAS feature [17, 3.10], [18, 3.8] that is a DAS feature: $\begin{matrix} (53) & \begin{array}{r} DriverSupportDrivingAutomationSystemFeature ⊑ DrivingAutomationSystemFeature \end{array} \end{matrix}$ It is realized in the driver support driving automation process, i.e., during driver assistance or partial driving automation. $\begin{matrix} (54) & \begin{array}{r} DriverSupportDrivingAutomationSystemFeature ⊑ \forall realizedIn . DriverSupport \end{array} \end{matrix}$

Some maneuver and sub-trip features are driver-support DAS features. It can also be proved that a driver support DAS feature is a dynamic driving subtask, discussed in the next section.

6. Dynamic driving task (DDT) capability

Dynamic driving task (DDT) [17, 3.13], [18, 3.10] is a capability of a dynamic automation system or a human driver: $\begin{aligned} DynamicDrivingTask & ⊑ Capability \\ (55) & ⊓ \exists inheresIn . (DrivingAutomationSystem ⊔ HumanDriver) \end{aligned}$ DDT is a capability because it is a disposition whose realization a human user has an interest in.

DDT consists of many capabilities required to operate a vehicle in on-road traffic (excluding strategic functions such as trip scheduling and selection of destinations and waypoints). So, it is realized in the operation of a motor vehicle (aka driving): $\begin{matrix} (56) & DynamicDrivingTask ⊑ \forall realizedIn . OperateMotorVehicle \end{matrix}$ Any instance of dynamic driving task can be discomposed into so-called subtasks [17, 3.13], [18, 3.10] which we interpret as functions: $\begin{matrix} (57) & DynamicDrivingSubtask ⊑ Function ⊓ \exists isPartOf . DynamicDrivingTask \end{matrix}$

A dynamic driving subtask inheres either in a part of a motor vehicle or in a part of a human driver. $\begin{aligned} DynamicDrivingSubtask \\ (58) & ⊑ \exists inheresIn . (\exists isPartOf . (DrivingAutomationSystem ⊔ HumanDriver)) \end{aligned}$

Lateral vehicle motion control [17, 3.15], [18, 3.14] is a function designed to realize activities necessary for the real-time, sustained regulation of the y-axis component of vehicle motion. $\begin{matrix} (59) & LateralMotionControl ⊑ DynamicDrivingSubtask \end{matrix}$ Lateral vehicle motion control realization includes the detection of the vehicle positioning relative to lane boundaries and applying steering or differential braking inputs to maintain appropriate lateral positioning. We assume that every instance of DDT has the lateral vehicle motion control as its part: $\begin{matrix} (60) & \begin{array}{r} DynamicDrivingTask ⊑ \exists hasPart . LateralMotionControl \end{array} \end{matrix}$

Longitudinal motion control [17, 3.16], [18, 3.15] is a function designed to realize activities necessary for the real-time, sustained regulation of the x-axis component of vehicle motion. $\begin{matrix} (61) & LongitudinalMotionControl ⊑ DynamicDrivingSubtask \end{matrix}$ Longitudinal motion control realization includes maintaining speed as well as detecting a preceding vehicle in the path of the subject vehicle, maintaining an appropriate gap to the preceding vehicle, and applying propulsion or braking inputs to cause the vehicle to maintain that speed or gap. Every instance of DDT has longitudinal motion control as its part: $\begin{matrix} (62) & \begin{array}{r} DynamicDrivingTask ⊑ \exists hasPart . LongitudinalMotionControl \end{array} \end{matrix}$

Object and event detection and response (OEDR) [17, 3.20], [18, 3.19] is a function designed to realize monitoring the driving environment (detecting, recognizing, and classifying objects and events and preparing to respond as needed) and executing an appropriate response to such objects and events (i.e., as needed to complete the DDT and/or DDT fallback). $\begin{aligned} ObjectAndEventDetectionAndResponse & ⊑ DynamicDrivingSubtask \\ (63) & ⊓ \exists hasPart . MonitorDrivingEnvironment \end{aligned}$ Every instance of DDT has longitudinal motion control as its part: $\begin{matrix} (64) & \begin{array}{r} DynamicDrivingTask ⊑ \exists hasPart . ObjectAndEventDetectionAndResponse \end{array} \end{matrix}$

Monitoring [17, 3.19], [18, 3.18] is a function designed to realize real-time human or machine sensing and processing of data used to operate a vehicle or to support its operation. $\begin{matrix} (65) & Monitor ⊑ DynamicDrivingSubtask \end{matrix}$ Every instance of DDT has a monitoring function as its part: $\begin{matrix} (66) & \begin{array}{r} DynamicDrivingTask ⊑ \exists hasPart . Monitor \end{array} \end{matrix}$

Monitor user [17, 3.19.1], [18, 3.18.1] is a monitoring function designed to realize activities or automated routines designed to assess whether and to what degree the user is performing the role specified for him/her. $\begin{matrix} (67) & MonitorUser ⊑ Monitor \end{matrix}$

Monitor driving environment [17, 3.19.2], [18, 3.18.2] is a monitoring function designed to realize activities automated routines that accomplish real-time roadway environmental object and event detection, recognition, classification, and response preparation (excluding actual response), as needed to operate a vehicle. $\begin{matrix} (68) & MonitorDrivingEnvironment ⊑ Monitor \end{matrix}$

Monitor vehicle performance [17, 3.19.3], [18, 3.18.3] is a monitoring function designed to realize activities or automated routines that accomplish a real-time evaluation of the vehicle performance and response preparation, as needed to operate a vehicle. $\begin{matrix} (69) & MonitorDrivingAutomationSystemPerformance ⊑ Monitor \end{matrix}$

Monitor driving automation system performance [17, 3.19.4], [18, 3.18.4] is a monitoring function designed to realize activities or automated routines for evaluating whether the driving automation system realizes part or all of the dynamic driving task appropriately. $\begin{matrix} (70) & MonitorVehiclePerformance ⊑ Monitor \end{matrix}$

To realize DDT means to realize all its parts. This constraint cannot be expressed in description logic.

Fig. 3.

Types of human user roles.

Fig. 4.

Types of human users.

7. Person roles in the sustained operation of a vehicle

In the J3016, we read “a driver who fails to monitor the roadway during engagement of a Level 1 adaptive cruise control (ACC) system still has the role of driver, even while s/he is neglecting it.” (our italics) [17, p. 4] This sentence is a perfect illustration of what a role is and why we need roles in our model. First of all, “driver” in the sentence above once means a person, and the other time something that inheres in a person and can be realized (in the context:) during engagement of a Level 1 adaptive cruise control and by (in the process:) monitoring the roadway. So, a role is a realizable entity that can be realized in processes of a correlated type, and its existence requires its bearer to be in some special physical, social, or institutional set of circumstances. So we have the following taxonomy of roles as presented in Fig. 3 and the mirror taxonomy of human users that have those roles in Fig. 4. The mirror taxonomy follows the pattern reflected by the following examples: $\begin{array}{c} (71) & HumanUser \equiv Person ⊓ (\exists isBearerOf . HumanUserRole) \\ (72) & DDTFallbackReadyUser \equiv Person ⊓ (\exists isBearerOf . DDTFallbackReadyUserRole) \end{array}$

So, strictly speaking, definitions of different types of human users do not carry any substantial meaning. To understand who the DDT fallback-ready user is, we have to go to the specification of the role.

Human user role [17, 3.29], [18, 3.31] is the (human) role: $\begin{matrix} (73) & HumanUserRole ⊑ \exists inheresIn . Person \end{matrix}$ It is realized in the sustained operation of a vehicle.12

¹²
[17, 3.29] defines this class as “the human role in driving automation”, which is narrower than our definition because DrivingAutomation is a subclass of SustainedOperationOfVehicle.

\begin{matrix} (74) & HumanUserRole ⊑ \exists realizedIn . SustainedOperationOfVehicle \end{matrix}

7.1. Human driver role

Human driver role [17, 3.29.1], [18, 3.31.1] is a human user role: $\begin{matrix} (75) & HumanDriverRole ⊑ HumanUserRole \end{matrix}$ It is realized in no driving automation, driver support driving, or conditional driving automation $\begin{aligned} HumanDriverRole & ⊑ \exists realizedIn . (NoDrivingAutomation ⊔ DriverSupport \\ (76) & ⊔ ConditionalDrivingAutomation) \end{aligned}$ by a person who performs in real-time DDT subtask or all of the DDT or DDT fallback for a particular vehicle: $\begin{aligned} HumanDriverRole & ⊑ \exists inheresIn . (Person ⊓ (\exists performs . (DDTFallback \\ (77) & ⊔ (\exists realizes . (DynamicDrivingTask ⊔ DynamicDrivingSubtask))))) \end{aligned}$

In-vehicle driver role In-vehicle driver (aka conventional driver) role [17, 3.29.1.1], [18, 3.31.1.1] is a human driver role $\begin{matrix} (78) & InVehicleDriverRole ⊑ HumanDriverRole \end{matrix}$ It is realized in no automation driving by a person that manually operates a conventional vehicle: $\begin{matrix} (79) & \begin{array}{r} InVehicleDriverRole ⊑ \exists realizedIn . (NoDrivingAutomation ⊔ DriverSupport) \end{array} \end{matrix}$ It inheres in a person that manually operates a conventional vehicle: $\begin{matrix} (80) & \begin{array}{r} InVehicleDriverRole ⊑ \exists inheresIn . (Person ⊓ \exists manuallyOperates . ConventionalVehicle) \end{array} \end{matrix}$ A manual operation means manual exercising in-vehicle braking, accelerating, steering, and transmission gear selection input devices in order to operate a vehicle. $manuallyOperates$ has a parent property $isSeatedInDriverSeatIn$ and $isSeatedInDriverSeatIn$ is a sub-property of $occupies$ . $isSeatedInDriverSeatIn$ and $occupies$ will be used in the forthcoming paragraphs. $isSeatedInDriverSeatIn$ indicates that a human user is seated in the driver’s seat in the motor vehicle, whereas $occupies$ indicates the vehicle the human user occupies.

Remote driver role Remote driver role [17, 3.29.1.2], [18, 3.31.1.2] is a human driver role: $\begin{matrix} (81) & RemoteDriverRole ⊑ HumanDriverRole \end{matrix}$ It is realized in the following processes: partial driving automation, conditional driving automation, high driving automation, and the DDT fallback $\begin{aligned} RemoteDriverRole & ⊑ \exists realizedIn . (PartialDrivingAutomation \\ ⊔ ConditionalDrivingAutomation ⊔ HighDrivingAutomation \\ (82) & ⊔ DynamicDrivingTaskFallback) \end{aligned}$ by a driver who remotely operates the vehicle: $\begin{matrix} (83) & \begin{array}{r} RemoteDriverRole ⊑ \exists inheresIn . (Person ⊓ \exists remotelyOperates . ADSEquippedVehicle) \end{array} \end{matrix}$ By remote operation, we mean not sitting in a vehicle in a position that allows manual exercising in-vehicle braking, accelerating, steering, and transmission gear selection input devices (if any) but being able to operate the vehicle.

Remote driving [18, 3.24] is an action performed by the remote driver: $\begin{matrix} (84) & \begin{array}{r} RemoteDriving ⊑ Process ⊓ \exists isPerformedBy . RemoteDriver \end{array} \end{matrix}$ where $\begin{matrix} (85) & RemoteDriver \equiv Person ⊓ (\exists isBearerOf . RemoteDriverRole) \end{matrix}$ So, it is a performance of part or all of the DDT or DDT fallback by a remote driver.

Remote assistant role Remote assistant role [18, 3.31.5] is a human driver role: $\begin{matrix} (86) & RemoteAssistantRole ⊑ HumanDriverRole \end{matrix}$ It is realized in a driverless operation of an ADS-equipped vehicle: $\begin{matrix} (87) & \begin{array}{r} RemoteAssistantRole ⊑ \exists realizedIn . DriverlessOperation \end{array} \end{matrix}$ by a person who provides remote assistance: $\begin{matrix} (88) & \begin{array}{r} RemoteAssistantRole ⊑ \exists inheresIn . (Person ⊓ \exists performs . RemoteAssistence) \end{array} \end{matrix}$

Remote assistance [18, 3.23] is an action performed by a remote assistant: $\begin{matrix} (89) & \begin{array}{r} RemoteAssistence ⊑ Process ⊓ \exists isPerformedBy . RemoteAssistant \end{array} \end{matrix}$ It is an event-driven provision of information or advice to an ADS-equipped vehicle in driverless operation to facilitate trip continuation when the ADS encounters a situation it cannot manage. $\begin{matrix} (90) & \begin{array}{r} RemoteAssistence ⊑ \exists hasParticipant . ADSEquippedVehicle \end{array} \end{matrix}$

7.2. DDT fallback-ready user role

DDT fallback-ready user role [17, 3.29.3] [18, 3.31.3] is a human driver role: $\begin{matrix} (91) & \begin{array}{r} DDTFallbackReadyUserRole ⊑ HumanUserRole \end{array} \end{matrix}$

It is realized in a conditional driving13

¹³
We can specify an in-vehicle fallback-ready user role and a remote fallback-ready user role taking into account if the user is or is not in the driver’s seat [18, 3.31.3.1, 3.31.3.2].

\begin{matrix} (92) & \begin{array}{r} DDTFallbackReadyUserRole ⊑ \forall realizedIn . ConditionalDrivingAutomation \end{array} \end{matrix}

by a person who is able to operate the vehicle and is receptive (1) to ADS-issued requests to intervene and (2) to evident DDT performance-relevant system failures in the vehicle:

\begin{aligned} DDTFallbackReadyUserRole & ⊑ inheresIn . (Person \\ ⊓ isReceptiveTo . (RequestToIntervene \\ (93) & ⊔ DDTPerformanceRelevantSystemFailure)) \end{aligned}

isReceptiveTo

is a normative relation that expresses an obligation of a person to reliably and appropriately focus his/her attention in response to a stimulus.

In-vehicle fallback-ready user role [18, 3.31.3.1] is a DDT fallback-ready user role that inheres in a person seated in the driver’s seat. $\begin{aligned} (94) & InVehicleDDTFallbackReadyUserRole ⊑ DDTFallbackReadyUserRole \end{aligned}$ $\begin{aligned} InVehicleDDTFallbackReadyUserRole & ⊑ inheresIn . (Person \\ (95) & ⊓ isSeatedInDriverSeatIn . ConventionalVehicle) \end{aligned}$

Remote fallback-ready user role [18, 3.31.3.2] is a DDT fallback-ready user role that inheres in a person who is not in the driver’s seat. $\begin{aligned} (96) & RemoteVehicleDDTFallbackReadyUserRole ⊑ DDTFallbackReadyUserRole \\ RemoteVehicleDDTFallbackReadyUserRole ⊑ inheresIn . (Person \\ (97) & ⊓ \neg isSeatedInDriverSeatIn . ConventionalVehicle) \end{aligned}$

DDT performance-relevant system failure [17, 3.18], [18, 3.17] is a malfunction in a vehicle system: $\begin{matrix} (98) & \begin{array}{r} DDTPerformanceRelevantSystemFailure ⊑ occuresIn . VehicleSystem \end{array} \end{matrix}$ DDT performance-relevant system failure prevents, for instance, the DAS from reliably performing the portion of the DDT on a sustained basis, including the complete DDT.

Request to intervene [17, 3.24], [18, 3.25] is an alert provided by an ADS to a fallback-ready user indicating that s/he should promptly perform the DDT fallback. $\begin{matrix} (99) & \begin{array}{r} RequestToIntervene ⊑ Process ⊓ \exists isPerformedBy . AutomatedDrivingSystem \end{array} \end{matrix}$ We assume that a DDT performance-relevant system failure precedes a request to intervene. $\begin{matrix} (100) & \begin{array}{r} RequestToIntervene ⊑ \exists isPrecededBy . DDTPerformanceRelevantSystemFailure \end{array} \end{matrix}$

DDT fallback [17, 3.14], [18, 3.12] is the response by the user to either perform the DDT or achieve a minimal risk condition or the response by an ADS to achieve minimal risk condition (1) after the occurrence of a DDT performance-relevant system failure(s), or (2) upon operational design domain (ODD) exit. $\begin{aligned} DynamicDrivingTaskFallback ⊑ MinimalRiskConditionAchievement \\ (101) & ⊔ (\exists realizes . DynamicDrivingTask) \\ (102) & DynamicDrivingTaskFallback ⊑ \exists isPerformedBy . (HumanUser ⊔ AutomatedDrivingSystem) \\ DynamicDrivingTaskFallback ⊑ \exists isPrecededBy . (DDTPerformanceRelevantSystemFailure \\ (103) & ⊔ OperationalDesignDomainExit) \end{aligned}$

Minimal risk condition achievement is a process carried out to achieve a minimal risk condition. A minimal risk condition [17, 3.17], [18, 3.16] is a stable, stopped condition to which a user or an ADS may bring a vehicle after performing the DDT fallback in order to reduce the risk of a crash when a given trip cannot or should not be continued.

Operational design domain (ODD) exit is a transition (i.e., a process) between being in a situation where a given driving automation system or feature thereof is specifically designed to function and a situation where it is not the case. Operational design domain [17, 3.22], [18, 3.21] is an operating condition under which a given driving automation system or feature thereof is specifically designed to function, including, but not limited to, environmental, geographical, and time-of-day restrictions, or the requisite presence or absence of specific traffic or roadway characteristics.

7.3. Example

Figure 5 illustrates the way the ontology can be used to classify parts of a motor vehicle’s operation and roles an ADS or a person can have while performing them (see [18, Figs 3-8 in 3.12]).14

¹⁴
File “individuals-autonomous-driving.ttl” at https://github.com/kul-ai/ontology-autonomous-driving/ contains the OWL modeling of the example.

ADS i1, being part of ADS-equipped vehicle i3, performs conditional driving automation process i2 (level 3). Person i4 participates in i2 in the role i5 of DDT fallback-ready user. i5 has a realization in i2. Having the role i5, the person i4 is receptive to any DDT performance-relevant system failures. When a DDT performance-relevant system failure i9 occurs in i1, person i2 is receptive to i9. i1 cannot continue DDT performance. Person i4 changes her role from a DDT fallback-ready user to a human driver role i6 and performs the dynamic driving task fallback i7. i6 has a realization in i7. i7 cannot realize DDT. Assuming that i3 is not operable but can still realize lateral and longitudinal control, i7 is classified as partial driving automation (level 2) and a minimal risk condition achievement process and results in achieving a stable stopped condition (i.e., a minimal risk condition).

Fig. 5.

Role changing situation during an operation of a motor vehicle.

7.4. Driverless operation dispatcher role

Driverless operation dispatcher role15

¹⁵
Our ontology is missing the concept of “driverless operation dispatcher entity” characterized in [17, 3.4], [18, 3.3] as an “entity that dispatches an ADS-equipped vehicle(s) in driverless operation.”. “driverless operation dispatcher entity” seems equivalent to the “driverless operation dispatcher role”.

[17, 3.29.4], [18, 3.31.4] is a human driver role

\begin{matrix} (104) & DriverlessOperationDispatcherRole ⊑ HumanUserRole \end{matrix}

It is realized by someone dispatching an ADS-equipped vehicle(s) in driverless operation.

\begin{aligned} DriverlessOperationDispatcherRole ⊑ \exists inheresIn . (Person \\ (105) & ⊓ \exists performs . DispatchInDriverlessOperation) \\ (106) & DriverlessOperationDispatcherRole ⊑ \exists realizedIn . DispatchInDriverlessOperation \end{aligned}

7.5. Passenger role

The passenger role [17, 3.29.2], [18, 3.31.2] is a human user role: $\begin{matrix} (107) & PassengerRole ⊑ HumanUserRole \end{matrix}$ As such, it has a realization in the sustained operation of a vehicle (what can be inferred). The passenger role inheres in someone being inside a vehicle but not doing anything related to driving: $\begin{matrix} (108) & \begin{array}{r} PassengerRole ⊑ \exists inheresIn . (Person ⊓ \neg \exists operates . ConventionalVehicle ⊓ \exists occupies . MotorVehicle) \end{array} \end{matrix}$

8. Five levels of automation of the sustained operation of a vehicle

Fig. 6.

Types of processes.

Sustained operation of a vehicle [17, 3.26], [18, 3.28] is a process that is a performance of part or all of the dynamic driving task both between and across external events, including responding to external events and continuing performance of part or all of the dynamic driving task in the absence of external events (c.f. Fig. 6 to see it in the context of processes types). $\begin{matrix} (109) & \begin{array}{r} SustainedOperationOfVehicle ⊑ \exists realizes . (DynamicDrivingTask ⊔ DyamicDrivingSubtask) \end{array} \end{matrix}$

The sustained operation of a vehicle is performed either by a human driver or by an automated driving system. $\begin{matrix} (110) & \begin{array}{r} SustainedOperationOfVehicle ⊑ \exists isPerformedBy . (HumanDriver ⊔ AutomatedDrivingSystem) \end{array} \end{matrix}$

Sustained operation of a vehicle is an ‘essential’ part of an operating motor vehicle process: $\begin{matrix} (111) & \begin{array}{r} SustainedOperationOfVehicle ⊑ \exists isOccurentPartOf . OperateMotorVehicle \end{array} \end{matrix}$

The sustained operation of a vehicle has two disjoint subclasses, and no driving automation process: $\begin{matrix} (112) & NoDrivingAutomation ⊑ SustainedOperationOfVehicle \end{matrix}$ and driving automation process: $\begin{matrix} (113) & DrivingAutomation ⊑ SustainedOperationOfVehicle \end{matrix}$

8.1. No driving automation (aka level 0)

No driving automation (aka level 0) [17, 5.1], [18, 5.1] is a sustained operation of a vehicle in which the in-vehicle driver performs the entire dynamic driving task (even when enhanced by active safety systems). $\begin{matrix} (114) & NoDrivingAutomation ⊑ \exists isPerformedBy . InVehicleDriver \end{matrix}$

No driving automation realizes DDT: $\begin{matrix} (115) & \begin{array}{r} NoDrivingAutomation ⊑ \exists realizes . DynamicDrivingTask \end{array} \end{matrix}$

No driving automation can be performed only by the in-vehicle driver: $\begin{matrix} (116) & NoDrivingAutomation ⊑ \forall isPerformedBy . InVehicleDriver \end{matrix}$

8.2. Driving automation

Driving automation [17, 3.7 and 5], [18, 3.5 and 5] is a sustained operation of a vehicle process such that a vehicle system performs part or all of the dynamic driving task. $\begin{matrix} (117) & \begin{array}{r} DrivingAutomation ⊑ \exists isPerformedBy . VehicleSystem \end{array} \end{matrix}$

Driving automation can be performed only by a vehicle system: $\begin{matrix} (118) & \begin{array}{r} DrivingAutomation ⊑ \forall isPerformedBy . VehicleSystem \end{array} \end{matrix}$

Driving automation realizes some DAS features: $\begin{matrix} (119) & \begin{array}{r} DrivingAutomation ⊑ \exists realizes . DrivingAutomationSystemFeature \end{array} \end{matrix}$

Driving automation and no driving automation process are disjoint: $\begin{matrix} (120) & DrivingAutomation ⊓ NoDrivingAutomation ⊑ ⊥ \end{matrix}$

Driving automation has two disjoint subclasses: driver support $\begin{matrix} (121) & DriverSupport ⊑ DrivingAutomation \end{matrix}$ and automated driving $\begin{matrix} (122) & AutomatedDriving ⊑ DrivingAutomation \end{matrix}$

8.2.1. Driver support

Driver support [17, 4], [18, 4] is a driving automation process that is the sustained execution by a driving automation system of the lateral or the longitudinal vehicle motion control subtask of the DDT: $\begin{array}{c} (123) & \begin{array}{r} DriverSupport ⊑ \forall realizes . DynamicDrivingSubtask \end{array} \\ (124) & \begin{array}{r} DriverSupport ⊑ \forall realizes . (LateralMotionControl ⊔ LongitudinalMotionControl) \end{array} \\ (125) & \begin{array}{r} DriverSupport ⊑ \exists realizes . (LateralMotionControl ⊔ LongitudinalMotionControl) \end{array} \end{array}$

Driver support is always an ODD-specific execution: $\begin{matrix} (126) & \begin{array}{r} DriverSupport ⊑ \exists hasUsageSpecification . OperationalDesignDomain \end{array} \end{matrix}$

It is expected that the driver supervises the driving automation system: $\begin{matrix} (127) & \begin{array}{r} DriverSupport ⊑ \exists hasOccurentPart . SuperviseDrivingAutomationSystemPerformance \end{array} \end{matrix}$ Supervise DAS performance [17, 3.25], [18, 3.27] is the driver activities $\begin{matrix} (128) & \begin{array}{r} SuperviseDrivingAutomationSystemPerformance ⊑ Process ⊓ \exists isPerformedBy . HumanDriver \end{array} \end{matrix}$ performed while operating a vehicle with an engaged driver support feature to monitor that feature’s performance, respond to inappropriate actions taken by the feature, and complete the DDT otherwise. $\begin{aligned} SuperviseDrivingAutomationSystemPerformance \\ (129) & ⊑ \exists dependsOn . (\exists realizes . DriverSupportDrivingAutomationSystemFeature) \end{aligned}$

Driver support realizes a driver support DAS feature: $\begin{matrix} (130) & \begin{array}{r} DriverSupport ⊑ \forall realizes . DriverSupportDrivingAutomationSystemFeature \end{array} \end{matrix}$

Driver support is a process in which a conventional vehicle participates: $\begin{matrix} (131) & \begin{array}{r} DriverSupport ⊑ \exists hasParticipant . ConventionalVehicle \end{array} \end{matrix}$

Driver support cannot realize the trip. It is expected that the driver performs the remainder of the DDT that goes beyond the scope of the driver support. Also, the object and event detection and response function cannot be entirely realized by the vehicle system. It is expected that the driver completes the OEDR subtask. We do not express this aspect formally.

Driver support has two subclasses: driver assistance $\begin{matrix} (132) & \begin{array}{r} DriverAssistance ⊑ DriverSupport \end{array} \end{matrix}$ and partial driving automation $\begin{matrix} (133) & \begin{array}{r} PartialDrivingAutomation ⊑ DriverSupport \end{array} \end{matrix}$

It is assumed they are disjoint: $\begin{matrix} (134) & \begin{array}{r} DriverAssistance ⊓ PartialDrivingAutomation ⊑ ⊥ \end{array} \end{matrix}$

Driver assistance (aka level 1) Driver assistance [17, 5.2], [18, 5.2] is a driver support process that is the sustained execution either the lateral or the longitudinal vehicle motion control subtask of the DDT (but not both simultaneously): $\begin{aligned} DriverAssistance & ⊑ \exists realizes . (LateralMotionControl ⊔ LongitudinalMotionControl) \\ (135) & \neg (\exists realizes . (LateralMotionControl ⊓ LongitudinalMotionControl)) \end{aligned}$

Partial driving automation (aka level 2) Partial driving automation [17, 5.3], [18, 5.3] is a driver support process that is the sustained execution both the lateral and longitudinal vehicle motion control subtasks of the DDT: $\begin{aligned} PartialDrivingAutomation \\ (136) & ⊑ \exists realizes . (LateralMotionControl ⊓ LongitudinalMotionControl) \end{aligned}$

8.2.2. Automated driving

Automated driving [17, 4], [18, 4] is a driving automation process where an ADS performs the entire DDT. $\begin{array}{c} (137) & \begin{array}{r} AutomatedDriving ⊑ \exists isPerformedBy . AutomatedDrivingSystem \end{array} \\ (138) & \begin{array}{r} AutomatedDriving ⊑ \exists realizes . DynamicDrivingTask \end{array} \end{array}$

Automated driving has an ADS-equipped vehicle as its participant: $\begin{matrix} (139) & \begin{array}{r} AutomatedDriving ⊑ \exists hasParticipant . ADSEquippedVehicle \end{array} \end{matrix}$

Automated driving has three disjoint subclasses, a conditional driving automation $\begin{matrix} (140) & \begin{array}{r} ConditionalDrivingAutomation ⊑ AutomatedDriving \end{array} \end{matrix}$ a high driving automation $\begin{matrix} (141) & \begin{array}{r} HighDrivingAutomation ⊑ AutomatedDriving \end{array} \end{matrix}$ and a full driving automation: $\begin{matrix} (142) & \begin{array}{r} FullDrivingAutomation ⊑ AutomatedDriving \end{array} \end{matrix}$

Conditional driving automation (aka level 3) Conditional driving automation [17, 5.4], [18, 5.4] is an automated driving process that is the ODD-specific performance: $\begin{matrix} (143) & \begin{array}{r} ConditionalDrivingAutomation ⊑ \exists hasUsageSpecification . OperationalDesignDomain \end{array} \end{matrix}$

It is expected that the DDT fallback-ready user is receptive to ADS-issued requests to intervene, as well as to DDT performance-relevant system failures in other vehicle systems, and will respond appropriately: $\begin{matrix} (144) & \begin{array}{r} ConditionalDrivingAutomation ⊑ \exists hasParticipant . DDTFallbackReadyUser \end{array} \end{matrix}$

Conditional driving automation realizes a sub-trip feature: $\begin{matrix} (145) & \begin{array}{r} ConditionalDrivingAutomation ⊑ \exists realizes . SubTripFeature \end{array} \end{matrix}$

High driving automation (aka level 4) High driving automation [17, 5.5], [18, 5.5] is an automated driving process that is the ODD-specific $\begin{matrix} (146) & \begin{array}{r} HighDrivingAutomation ⊑ \exists hasUsageSpecification . OperationalDesignDomain \end{array} \end{matrix}$ High driving automation may include the performance of DDT fallback carried out by an ADS, so it is not expected that a user will respond to a request to intervene. $\begin{array}{c} (147) & \begin{array}{r} HighDrivingAutomation ⊑ (⩾ 0 hasOccurentPart . (\exists realizes . DynamicDrivingTaskFallback)) \end{array} \\ (148) & \begin{array}{r} HighDrivingAutomation ⊑ \neg (\exists hasParticipant . DDTFallbackReadyUser) \end{array} \end{array}$

High driving automation realizes a sub-trip feature: $\begin{matrix} (149) & \begin{array}{r} HighDrivingAutomation ⊑ \exists realizes . SubTripFeature \end{array} \end{matrix}$

Full driving automation (aka level 5) Full driving automation [17, 5.5], [18, 5.5] is an automated driving process with the sustained and unconditional (i.e., not ODD-specific) performance by an ADS of the entire DDT and DDT fallback. $\begin{array}{c} (150) & \begin{array}{r} FullDrivingAutomation ⊑ \neg (\exists hasUsageSpecification . OperationalDesignDomain) \end{array} \\ (151) & \begin{array}{r} FullDrivingAutomation ⊑ (⩾ 0 hasOccurentPart . (\exists realizes . DynamicDrivingTaskFallback)) \end{array} \\ (152) & \begin{array}{r} FullDrivingAutomation ⊑ \neg (\exists hasParticipant . DDTFallbackReadyUser) \end{array} \end{array}$

Full driving automation realizes a full-trip feature: $\begin{matrix} (153) & \begin{array}{r} FullDrivingAutomation ⊑ \exists realizes . FullTripFeature \end{array} \end{matrix}$

8.3. Operating a motor vehicle and a trip

Operating a motor vehicle (aka driving) [17, 3.21], [18, 3.20] is a collection of activities of the sustained operation of a vehicle type: $\begin{matrix} (154) & \begin{array}{r} OperateMotorVehicle ⊑ Process ⊓ \exists hasOccurentPart . SustainedOperationOfVehicle \end{array} \end{matrix}$

It is performed by a human driver (with or without the support of driving automation features) or by an ADS: $\begin{matrix} (155) & \begin{array}{r} OperateMotorVehicle ⊑ \exists performedBy . (HumanDriver ⊔ AutomatedDrivingSystem) \end{array} \end{matrix}$

Operating a motor vehicle realizes the entire DDT for a given vehicle: $\begin{array}{c} (156) & \begin{array}{r} OperateMotorVehicle ⊑ \exists realizes . DynamicDrivingTask \end{array} \\ (157) & \begin{array}{r} OperateMotorVehicle ⊑ \exists hasParticipant . MotorVehicle \end{array} \end{array}$

Trip Trip [17, 3.27], [18, 3.29] is the traversal of an entire travel pathway by a vehicle from the point of origin to a destination. We treat it as a process dependent on (constituted by) an operating a motor vehicle that by itself is a collection of processes: $\begin{matrix} (158) & \begin{array}{r} Trip ⊑ Process \end{array} \end{matrix}$

Any trip has part an operation of a motor vehicle. $\begin{matrix} (159) & \begin{array}{r} Trip ⊑ \exists hasOccurentPart . OperateMotorVehicle \end{array} \end{matrix}$

Driverless operation of an ADS-equipped vehicle Driverless operation [17, 3.11], [18, 3.9] is on-road operation performed by an ADS: $\begin{matrix} (160) & \begin{array}{r} DriverlessOperation ⊑ OperateMotorVehicle ⊓ \exists isPerformedBy . AutomatedDrivingSystem \end{array} \end{matrix}$ It has a participant that is an ADS-equipped vehicle that is unoccupied or in which on-board users are not drivers or in-vehicle fallback-ready users: $\begin{aligned} DriverlessOperation & ⊑ \exists hasParticipant . (ADSEquippedVehicle \\ ⊓ (\exists isOccupiedBy . (InVehicleDDTFallbackReadyUser ⊔ \neg HumanDriver)) \\ (161) & ⊔ \forall isOccupiedBy . \neg Person) \end{aligned}$

Driverless operation (historically) depends on dispatching in driverless operation: $\begin{matrix} (162) & \begin{array}{r} DriverlessOperation ⊑ \exists isPrecededBy . DispatchInDriverlessOperation \end{array} \end{matrix}$

9. Conclusions and future works

We have presented a formalized conceptual framework including the essential notions relevant to autonomous driving, including motor vehicles and their systems, driving tasks and subtasks, roles of persons in road communication, and autonomy levels. The framework is based on the SAE-J3016 standard, which proved to be a valuable pre-ontological source. We were able to cover all concepts listed and defined in the standard, and we believe that our account is adequate concerning the intentions of the authors of the standard. In several points, our use of a high-level ontology allowed us to increase precision.

The clarification of the roles of individuals in driving at various levels of autonomy seems to be particularly important, as it is useful for discussing responsibility for accidents or failures. This responsibility clearly relies on the role a person is performing in the process of driving. Let us emphasize that, as illustrated in the example depicted in Fig. 5, the role of a person in a car may change during a single trip. Thus, the notion of role, whose precise meaning is taken from BFO, has shown to be crucial for the application of the whole conceptual framework of our ontology of autonomous driving.

The conceptual ordering of the domain of autonomous vehicles is not finished yet. Pointing out the limitations of the SAE-J3016 standard [28] writes: “Policymakers and the public need clearer information about the conditions in which particular automated devices can operate and the additional changes that might be required for such systems to be safe, equitable, and effective. This means less focus on the ‘driving task’ and more attention to place, infrastructure, and road rules.” These aspects also require ontological formalization.

Another critical issue influencing driving automation is vehicular communication (see a recent survey: [25]). From the point of view of ontology, it is worth noting that here, a respective SAE standard exists [16] and can be used as a pre-ontological source. Growing capacities for vehicle-to-vehicle communication and communication between vehicles and the environment indicate to shift in interest from the operation of individual vehicles to an integrated transportation system approach (c.f. [5]). That area also deserves conceptual clarification employing ontological tools.

Yet another field, important from the broad introduction of autonomous vehicles, covers car accidents and harm caused by them. That conceptual area should also be precisely described and formalized to discuss the right decisions of driving systems and issues related to responsibility for accident consequences.

To validate the ontology, we have checked that the definitions provided by the SAE-J3016 standard have their just representation in the ontology and that the examples given in the standard can be adequately described using the ontology. We have presented a detailed analysis of one of the examples. Further validation is a matter of future work. One direction here is to consult the actual SAE-J3016 standard users to determine whether the ontology design and conceptual clarification within it suit their needs. Another one is connected with checking the robustness of the ontology in the context of modifications and extensions of the SAE-J3016 standard proposed by its commentators.

Footnotes

Acknowledgements

This research was supported by the National Science Centre of Poland (grant UMO-2017/26/M/HS1/01092).

References

ANSI, Manual on classification of motor vehicle traffic crashes, Technical report, ANSI D.16, 2017.

Arp,

Smith and

A.D.

Spear, Building Ontologies with Basic Formal Ontology, The MIT Press, 2015.

AVSC00006, AVSC best practice for metrics and methods for assessing safety performance of automated driving systems (ADS), Technical report, SAE International, 2021.

AVSC00008, AVSC best practice for evaluation of behavioral competencies for automated driving system dedicated vehicles (ADS-DVs), Technical report, SAE International, 2021.

European Commission and Joint Research Centre,

Alonso Raposo,

Makridis,

Ciuffo and

Thiel, The r-evolution of driving: From connected vehicles to coordinated automated road transport (C-ART). Part I, Framework for a safe & efficient coordinated automated road transport (C-ART) system, Publications Office, 2017. doi:10.2760/052089.

Hopkins and

Schwanen, Talking about automated vehicles: What do levels of automation do?, Technology in Society64 (2021), 101488. doi:10.1016/j.techsoc.2020.101488.

Inagaki and

T.B.

Sheridan, A critique of the SAE conditional driving automation definition, and analyses of options for, Cognition, Technology and Work (2019), 569–578. doi:10.1007/s10111-018-0471-5.

B.S.

Kulvatunyou,

Wallace,

Kiritsis,

Smith and

Will, The industrial ontologies foundry proof-of-concept project, in: Advances in Production Management Systems. Smart Manufacturing for Industry 4.0,

Moon,

G.M.

Lee,

Park,

Kiritsis and

von Cieminski, eds, Springer International Publishing, Cham, 2018, pp. 402–409.

Lipson and

Kurman, Driverless: Intelligent Cars and the Road Ahead, The MIT Press, 2017.

10.

D.F.

Llorca, From driving automation systems to autonomous vehicles: Clarifying the terminology, CoRR, 2021, arXiv:2103.10844.

11.

Meriah and

L.B.

Arfa Rabai, Comparative study of ontologies based ISO 27000 series security standards, Procedia Computer Science160 (2019), 85–92, The 10th International Conference on Emerging Ubiquitous Systems and Pervasive Networks (EUSPN-2019) / The 9th International Conference on Current and Future Trends of Information and Communication Technologies in Healthcare (ICTH-2019) / Affiliated Workshops. doi:10.1016/j.procs.2019.09.447.

12.

Merrell,

Limbaugh,

Koch and

Smith, Capabilities, 2021, https://philpapers.org/rec/MERC-14.

13.

Motor vehicle and driver programs 49 U.S.C. 30102(a) (6), 1994, https://www.law.cornell.edu/uscode/text/49/30102.

14.

Ossig,

Cramer and

Bengler, Concept of an ontology for automated vehicle behavior in the context of human-centered research on automated driving styles, Information12(1) (2021), 21. doi:10.3390/info12010021.

15.

PAS-1883:2020, Operational design domain (ODD) taxonomy for an automated driving system (ADS) – specification, Technical report, British Standards Institution, 2020.

16.

SAE-J2945/1, On-board system requirements for V2V safety communications, Technical report, SAE International, 2020.

17.

SAE-J3016, Taxonomy and definitions for terms related to driving automation systems for on-road motor vehicles, Technical report, SAE International, 2018.

18.

SAE-J3016, Taxonomy and definitions for terms related to driving automation systems for on-road motor vehicles, Technical report, SAE International, 2021.

19.

SAE-J3063, Active safety systems terms and definitions, Technical report, SAE International, 2021.

20.

SAE-J3088, Active safety systems sensors, Technical report, SAE International, 2017.

21.

SAE-J3114, Human factors definitions for automated driving and related research topics, Technical report, SAE International, 2016.

22.

SAE-J3164, Ontology and lexicon for automated driving system (ADS)-operated vehicle behaviors and maneuvers in routine/normal operating scenarios, Technical report, SAE International, 2023.

23.

Schreiber,

Kauer,

Schlesinger,

Hakuli and

Bruder, Verification of a maneuver catalog for a maneuver-based vehicle guidance system, in: 2010 IEEE International Conference on Systems, Man and Cybernetics, 2010, pp. 3683–3689. doi:10.1109/ICSMC.2010.5641862.

24.

B.D.

Seppelt,

Reimer,

Russo,

Mehler,

J.T.

Fisher and

Friedman, Consumer confusion with levels of vehicle automation, in: Proceedings of the 10th International Driving Symposium on Human Factors in Driver Assessment, Training and Vehicle Design: Driving Assessment 2019, 2019.

25.

P.K.

Singh,

S.K.

Nandi and

Nandi, A tutorial survey on vehicular communication state of the art, and future research directions, Vehicular Communications18 (2019), 100164, https://www-sciencedirect-com-443.web.bisu.edu.cn/science/article/pii/S2214209618300901 . doi:10.1016/j.vehcom.2019.100164.

26.

A.D.

Spear,

Ceusters and

Smith, Functions in Basic Formal Ontology, Appl. Ontology11(2) (2016), 103–128. doi:10.3233/AO-160164.

27.

Staplin,

Mastromatto,

K.H.

Lococo,

K.W.

Gish and

J.O.

Brooks, The effects of medical conditions on driving performance, (Report No. DOT HS 812 623), Technical report, National Highway Traffic Safety Administration, Washington, DC, 2018.

28.

Stayton and

Stilgoe, It’s time to rethink levels of automation for self-driving vehicles [opinion], IEEE Technology and Society Magazine39(3) (2020), 13–19. doi:10.1109/MTS.2020.3012315.

29.

Steckhan,

Spiessl,

Quetschlich and

Bengler, Beyond SAE J3016: New design spaces for human-centered driving automation, in: HCI in Mobility, Transport, and Automotive Systems,

Krömker, ed., Springer International Publishing, Cham, 2022, pp. 416–434.

30.

Trypuz,

Kulicki,

Grądzki,

Trójczak and

Wierzbicki, Machine-understandable and processable representation of UNECE standards for meat. Bovine meat – carcases and cuts case study, in: Metadata and Semantics Research,

Garoufallou,

Subirats Coll,

Stellato and

Greenberg, eds, Springer International Publishing, Cham, 2016, pp. 144–154. doi:10.1007/978-3-319-49157-8_12.

31.

Zhao,

Ichise,

Mita and

Sasaki, Core ontologies for safe autonomous driving, in: Proceedings of the ISWC 2015 Posters & Demonstrations Track Co-Located with the 14th International Semantic Web Conference (ISWC-2015), Bethlehem, PA, USA, October 11, 2015, 2015, http://ceur-ws.org/Vol-1486/paper_9.pdf .