Ontology of autonomous driving based on the SAE J3016 standard

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 EDMC11 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 domain22 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).33 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.44 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.55

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.66 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.

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.

Domains and ranges of the properties have been restricted to the BFO categories we have used in our formalization. The formula ∃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:

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:

(21)MotorVehicle⊑Object

Providing conveyance on public roads is the main vehicle’s capability:

(22)MotorVehicle⊑∃isBearerOf.ProvidingConveyanceOnPublicRoads

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.

(23)ConventionalVehicle≡MotorVehicle⊓∃isBearerOf.BeingOperatedByInVehicleDriver

Fig. 2.

Types of motor vehicles.

Being operated by an in-vehicle driver is a capability:

(24)BeingOperatedByInVehicleDriver⊑Capability

It can be realized only in the sustained operation of a vehicle performed by an in-vehicle driver.

BeingOperatedByInVehicleDriver⊑∀realizedIn.(SustainedOperationOfVehicle(25)⊓(∃isPerformedBy.InVehicleDriver))

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.

(26)MotorVehicle⊑(⩾0isEquippedWith.VehicleSystem)

ADS-equipped vehicle [17, 3.5], [18, 3.32.1] is a motor vehicle equipped with an automated driving system.

(27)ADSEquippedVehicle≡MotorVehicle⊓(∃isEquippedWith.AutomatedDrivingSystem)

The property isEquippedWith is a specialization of BFO’s hasPart property and relates a motor vehicle with a vehicle system.

(28)isEquippedWith⊑hasPart

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.77

(29)ADSDedicatedVehicle≡ADSEquippedVehicle⊓∃isBearerOf.DriverlessOperationCapability

Driverless operation capability is a capability:

(30)DriverlessOperationCapability⊑Capability

It is realized in a driverless operation process.

(31)DriverlessOperationCapability⊑∃realizedIn.DriverlessOperation

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:

ADSDedicatedVehicle⊑(⩾0isDispachedIn.(DriverlessOperation(32)⊓(∃isDipachedBy.DriverlessOperationDispatcher)))

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.

ADSEquippedDualModeVehicle≡ADSEquippedVehicle⊓∃isBearerOf.DriverlessOperationCapability(33)⊓∃isBearerOf.BeingOperatedByInVehicleDriver

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:

(34)∃realizes.DriverlessOperationCapability⊑¬(∃realizes.BeingOperatedByInVehicleDriver)

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.

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:

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):

A dynamic driving subtask inheres either in a part of a motor vehicle or in a part of a human driver.

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.

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.

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).

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.

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.

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.

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.

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.

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:

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:

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]).1414

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.

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).

The sustained operation of a vehicle is performed either by a human driver or by an automated driving system.

Sustained operation of a vehicle is an ‘essential’ part of an operating motor vehicle process:

The sustained operation of a vehicle has two disjoint subclasses, and no driving automation process:

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.