An Ontology-based Approach to Generate the Advanced Driver

Assistance Use Cases of Highway Trafﬁc

Wei Chen

1,2

and Le

ıla Kloul

Laboratory DAVID, Versailles Saint-Quentin-en-Yvelines University, 45, avenue des

Etats-Unis, 78000, Versailles, France

Institute of Technological Research SystemX, 8, Avenue de la Vauve, 91120, Palaiseau, France

Keywords:

Autonomous Vehicle, Ontology, Use Cases.

Abstract:

Autonomous vehicles perceive the environment with different kinds of sensors (camera, radar, lidar...). They

must evolve in an unpredictable environment and a wide context of dynamic execution, with strong interacti-

ons. In order to generate the safety of the autonomous vehicle, its occupants and the others road users, it is

necessary to validate the decisions of the algorithms for all the situations that will be met. These situations are

described and generated as different use cases of automated vehicles. In this work, we propose an approach

to generate automatically use cases of autonomous vehicle for highway. This approach is based on a three

layers hierarchy, which exploits static and mobile concepts we have deﬁned in the context of three ontologies:

highway, weather and vehicle. The highway ontology and the weather ontology conceptualize the environ-

ment in which evolves the autonomous vehicle, and the vehicle ontology consists of the vehicle devices and

the control actions. To apply our approach, we consider a running example about the insertion of a vehicle by

the right entrance lane of a highway.

1 INTRODUCTION

Autonomous vehicles must evolve in an unpredicta-

ble environment and a wide context of dynamic exe-

cution, with strong interactions. Since the 1970s,

the research on autonomous vehicle became a ten-

tancy in the industry. After years of exploration,

certain progress has been made. In early 2018,

Audi expanded Trafﬁc Light Information Vehicle-

to-Infrastructure (V2I) system to Washington (Krok,

2018). Nissan plans to continue the collaboration

with NASA to adapt NASA technology for use in

their Seamless Autonomous Mobility platform (Bar-

tosiak, 2018). Not only is the traditional auto industry

dedicated to this research domain, but other compa-

nies, such as Google and Intel, have also participa-

ted to the development of the autonomous vehicles.

Waymo, which started as Google’s self-driving car

project, canceled the design of the steering wheel and

pedals (Gain, 2017), which completely overturns the

design of traditional cars.

Recently, the world’s ﬁrst driverless taxi was put

into use in Dubai (Caughill, 2017). Tesla has made

the ﬁrst delivery of ﬁfty (50) out of two hundreds

(200) vehicles to Dubai. The goal is for the cars to

evolve into a fully autonomous taxi service. Auto-

nomous vehicles are no longer just in the scenes of

science ﬁction movies. They come to real life and will

become more commonplace as ordinary cars. Howe-

ver, at the same time, autonomous vehicles brought

new problems to our lives, for example, the issue

of accident liability determination, and most impor-

tantly, the issue of safety.

The recent fatal crash in California of Tesla’s Au-

topilot System shows that safety assessment of intelli-

gent systems is a high-priority topic in the automated

vehicle industry. The driver’s hands were not detected

on the wheel for six seconds prior to the collision

(BBC, 2018) while the owners guide speciﬁes that the

driver must keep the hands on the steering wheel at all

times (Tesla, 2018). The autopilot is not smart enough

to hold all the situations it meets. Human driver needs

to be involved at critical moments, but its attention

cannot be focused for a long time since most of the

time the driver has nothing to do in such vehicles.

To ensure the safety of the autonomous vehicle,

its occupants and the other road users, when autono-

mous vehicles evolve in the dynamic environment, it

is necessary to simulate all possible situations to test

and validate the decisions of the algorithms of the Ad-

vanced Driver-Assistance Systems (ADAS) inside the

vehicle. These situations are described and genera-

Chen, W. and Kloul, L.

An Ontology-based Approach to Generate the Advanced Driver Assistance Use Cases of Highway Trafﬁc.

DOI: 10.5220/0006931700750083

In Proceedings of the 10th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management (IC3K 2018) - Volume 2: KEOD, pages 75-83

ISBN: 978-989-758-330-8

ted as different use cases of automated vehicles. A

use case is deﬁned as one or several scenarios app-

lied to functional ranges and behaviors to simulate the

ADAS. A scenario describes the temporal develop-

ment between several scenes in a sequence of scenes.

In this work, we propose an approach to gene-

rate automatically use cases of autonomous vehicle

in the context of highway. This approach is based on

a three layers hierarchy, which exploits static and mo-

bile concepts we have deﬁned in the context of three

ontologies: highway, weather and vehicle. We con-

sider a running example: “Insertion of vehicle by the

right entrance lane of a highway”, to show the con-

cepts and their relationships in the ontologies. We in-

troduce the approach of use cases generation with dif-

ferent scenarios constructed using several scenes and

we show how to apply this approach on the running

example.

Structure of the paper: Section 2 is dedicated to

Related Works. In Section 3, we describe our run-

ning example. The three ontologies are presented in

Section 4. Our approach of use cases generation is

presented in Section 5. Finally, we conclude our work

in Section 6.

2 RELATED WORKS

Several researchers have used ontologies for the con-

ceptualization of the ADAS or the control of the au-

tonomous vehicle.

An ontology of recognition for the ADAS system

is presented in (Armand et al., 2014). The authors de-

ﬁne an ontology composed of concepts and their in-

stances. This ontology includes contextual concepts

and context parameters. It is able to process human-

like reasoning on global road contexts. Another on-

tology is proposed by Pollard et al. (Pollard et al.,

2013) for situation assessment for automated ground

vehicles. It includes the sensors/actuators state, envi-

ronmental conditions and driver’s state. However, as

the classes of both ontologies are highly generalized,

they are not enough to describe use cases to simulate

and validate ADAS.

To build a knowledge base for smart vehicles and

implement different types of ADAS, Zhao et al. (Zhao

et al., 2015) proposed three ontologies: map ontology,

control ontology and car ontology. They focus on al-

gorithms for rapid decision making for autonomous

vehicle systems. They provide an ontology-based

knowledge base and decision-making system that can

make safe decisions about uncontrolled intersections

and narrow roads. However, the authors did not con-

sider the equipment of the road infrastructure in their

map ontology, for example the trafﬁc signs which are

an important part for use cases construction.

Morignot et al. (Morignot and Nashashibi, 2012)

propose an ontology to relax trafﬁc regulation in unu-

sual but practical situations, in order to assist drivers.

Their ontology represents the vehicles, the infrastruc-

ture and the trafﬁc regulation for the general road.

It is based on the experience of the members of the

lab with driving license, not based on a texts corpus.

That may be useful for modelling the concepts invol-

ved in trafﬁc regulation relaxation, but we need more

rigorous ontologies for modelling the concepts invol-

ved in general situations.

In (Bagschik et al., 2017), the authors propose,

using ontology, to create scenarios for development of

automated driving functions. They propose a process

for an ontology based scene creation and a model for

knowledge representation with 5 layers: road-level,

trafﬁc infrastructure, temporary manipulation of the

ﬁrst two levels, objects and environment. A scene is

created from ﬁrst layer to ﬁfth layer. This ontology

has modelled German motorways with 284 classes,

762 logical axioms and 75 semantic web rules. A

number of scenes could be automatically generated

in natural language. However, the natural language

is not a machine-understandable knowledge and the

transformation of natural language based scenes to si-

mulation data formats with such a huge ontology is a

tremendous work.

In (H

ulsen et al., 2011) and in (Hummel et al.,

2008) use a description logic to describe the sce-

nes. The ﬁrst work provides a generic description of

road intersections using the concepts Car, Crossing,

RoadConnection and SignAtCrossing. They use des-

cription logic to reason about the relations between

cars and describe how a trafﬁc intersection situation is

set up in this ontology and deﬁne its semantics. The

results are presented for an intersection with 5 roads,

11 lanes and 6 cars driving towards the intersection.

Hummel et al. (Hummel et al., 2008) also propose

an ontology to understand road infrastructures at in-

tersections. This approach focuses on the geometri-

cal details related to the multilevel topological infor-

mation. It presents scene comprehension frameworks

based on the description logic, which can identify un-

reasonable sensor data by checking for consistency.

All these ontologies are limited to the situation of in-

tersection which is not enough to simulate an environ-

ment and validate the ADAS.

KEOD 2018 - 10th International Conference on Knowledge Engineering and Ontology Development

3 RUNNING EXAMPLE

We consider the situation “Insertion of vehicle by the

right entrance lane of a highway” as the running ex-

ample. It is in daylight and the temperature is c

◦

The humidity is h % and the pressure is p mPa. The

wind speed is v

km/h and its direction is d

◦

(from

0 to 360

◦

, 180

◦

refers to a southerly wind).

Figure 1: Scenography of the running example.

The highway is separated into two carriageways

by median. In the scenography of this running ex-

ample (Figure 1), a portion of one carriageway is se-

lected. The left hard shoulder is located on the imme-

diate outside of the median. The edge of the left hard

shoulder is marked by two single solid white lines.

This carriageway has three main lanes and an entrance

lane. There is a chevrons marking placed between the

outside lane and the entrance lane. The entrance lane

is composed of an acceleration section and a taper.

An entrance ramp is connected with the entrance lane

at the point where the width of the chevrons reduces

to one meter (1m). The right soft shoulder is located

on the immediate outside of the right hard shoulder.

In the beginning of the acceleration section, a give

way sign is placed on the right soft shoulder. There

are two deﬂection arrows marking on the acceleration

section. The types of dashed lines are provided on Fi-

gure 1. Their deﬁnitions are those provided in the ofﬁ-

cial French document for road symbols (Minist

ere de

l’

ecologie, 1988).

Figure 2: Initial scene of the running example.

In the initial scene (Figure 2) of running exam-

ple, the Ego vehicle (blue) rolls on the right lane of

a separated lane road. The speed of Ego is given

by v

km/h on the portion which speed is limited to

130 km/h. The System Trafﬁc Jam Chauffeur (TJC)

is active and regulates the speed of Ego with respect

to a target vehicle V c

(green) that is located d

m in

front of Ego. A third vehicle V c

(red) arrives on the

entrance lane and wants to insert the highway. V c

and V c

roll at a speed equal to v

km/h and v

km/h,

respectively.

Figure 3: Vehicle insertion before Ego.

Figure 4: Vehicle insertion after Ego.

We suppose that v

= v

in this running ex-

ample. From the initial scene, there are two possi-

bilities: V c

inserts before or after Ego. In the ﬁrst

case (Figure 3), Ego decelerates and V c

turns on the

left direction lights and begins to insert before Ego.

It follows that the radar of Ego detects this vehicle

which becomes the new target vehicle. Ego follows

V c

. In the second case, if Ego makes the decision to

accelerate, obviously this action will lead to another

scene and inﬂuence the whole scenario as showed in

Figure 4. Of course Ego may do nothing and conti-

nue driving. In this case, it is the turn of V c

to make

decision to decelerate or accelerate. There are also

situations where both Ego and V c

do the same acti-

An Ontology-based Approach to Generate the Advanced Driver Assistance Use Cases of Highway Trafﬁc

ons. For example, they accelerate. But eventually all

these situations will render in either of two possibili-

ties: V c

inserts before or after Ego. Note that Ego

cannot change to the left lane because on that lane,

there is no vehicle and thus no possible target vehicle

to follow.

4 ONTOLOGIES

An ontology is a structural framework for the repre-

sentation of knowledge about a domain. It is often

conceived as a set of concepts with their deﬁnitions

and relationships (Uschold and Gruninger, 1996). In

this work, we deﬁne three ontologies: highway onto-

logy and weather ontology to specify the environment

in which evolves the autonomous vehicle, and the

vehicle ontology which consists of the vehicle devices

and control actions. The ontologies we have deﬁned

have been edited in Protege (protege.stanford.edu,

2012).

4.1 The Concepts

In the following, we describe the concepts of the three

(3) ontologies.

Highway Ontology: The highway infrastructure

consists of the physical components of highway sy-

stem providing facilities essential to allow the vehicle

driving on the highway. We have built highway onto-

logy based on the French ofﬁcial documents (Minist

ere de l’

ecologie, 1988) (Minist

ere de l’

equipement,

2000). This ontology involves four main concepts:

RoadPart, Roadway, Zone and Equipment. The

concept RoadPart refers to the long proﬁle of the

highway. We consider that the highway is compo-

sed of connected segments and interchanges. There

are two types of interchanges on highway: Branch

and Ramp. The branch connects to another highway

and the ramp connects to other types of roads. The

concept Roadway refers to the longitudinal proﬁle

of the highway. The special areas on the highway

(Toll, Sa f etyArea, RestArea, etc.) are classiﬁed

in the concept Zone. The concept Equipment re-

fers to the facilities that guarantee the normal ope-

ration of highways. It could be Barrier, Fence,

Tra f f icSymbol, Lighting or EmergencyTelephone.

The concepts of this ontology are deﬁned in terms

of entity, sub-entities and properties. For example,

the concept EntranceLane is deﬁned as in Table 1.

In the running example, the ID of EntranceLane is

EnLane

Table 1: Deﬁnition of the concept EntranceLane.

Concept EntranceLane

Entity entrance lane

Deﬁnition A lane which allows vehicles

accessing a highway to accelerate

until integrating the highway ﬂow.

Properties ID, Alignment (Horizontal & Ver-

tical), Length, Width, SpeedLimit

Sub-entities Acceleration Section, Taper

Figure 5 shows all the ﬁfty-four (54) concepts we

have deﬁned for highway ontology. The framed con-

cepts are the concepts that can be used for the running

example.

Weather Ontology: The weather describes the

state of the atmosphere at a particular place and time.

Some phenomena inﬂuence the visibility of captors

Figure 5: Concepts of highway ontology (framed concepts for running example).

KEOD 2018 - 10th International Conference on Knowledge Engineering and Ontology Development

on the autonomous vehicle, for exemple the concepts

Daylight, Precipitation, Fog and Haze. As the pro-

perties of the concept Daylight presented in Table 2,

the visibility of the autonomous vehicle is reﬂected

by the distance at which an infrastructure or a vehicle

can be clearly discerned. Some concepts have their

properties to show the physical quantity, such as the

concepts Temperature, Pressure and Humidity.

Figure 7: Concepts of Weather ontology.

Table 2: Deﬁnition of the concept Daylight

Concept Daylight

Entity daylight

Deﬁnition The combination of all direct and in-

direct sunlight during the daytime.

Properties Direction (from 0 to 360

◦

, 180

◦

re-

fers to south light), Visibility (m)

We have deﬁned twelve (12) concepts for the we-

ather ontology (Figure 7). The framed concepts are

those that can be used for the running example.

Table 3: Properties of concept Vehicle.

ID Ego V c

V c

Role EgoCar TargetCar OtherCar

Category Class1 Class1 Class1

Height H

Width W

Length L

Weight m

Color Blue Green Red

Speed v

Vehicle Ontology: This ontology describes the per-

formance of a vehicle with nine (9) properties. Table

3 shows the properties of three vehicles in the ini-

tial scene of running example. All roles (EgoCar,

TargetCar and OtherCar) of vehicles can be repre-

sented. There are ﬁve classes of vehicle category pro-

vided in (Minist

ere de l’

equipement, 2000), where

Class1 refers to light vehicles whose hight is less than

or equal to 2m and GVWR (Gross Vehicle Weight

Rating) is less than or equal to 3,5t. The concept

Vehicle consists of two main sub-entities: Device

and Action. Device refers to the devices actionable

during the performance of the vehicle, such as the

WindscreenWiper and the Light. Action refers to the

control actions that could be made by pilot, such as

action ChangeLane deﬁned in Table 4.

Table 4: Deﬁnition of the concept ChangeLane.

Concept ChangeLane

Entity change lane

Deﬁnition An action indicating a lane change to

enter or exit the highway or overta-

king another vehicle.

Properties Direction (Left/right)

Figure 6 shows the twenty-six (26) concepts we

have deﬁned for vehicle ontology. The framed con-

cepts are those that can be used for the running exam-

ple.

4.2 The Relationships and Rules

In order to represent the complex and intricate relati-

onships between the entities, we consider three kinds

of relationships (Figure 8): the relationships between

the highway entities, the relationships between the

vehicle entities, and the relationships between the en-

tities of highway and vehicle. Moreover, the trafﬁc

regulation and the interactions between the concepts

are written as rules to simulate the environment of au-

tonomous vehicle. We use ﬁrst-order logic to repre-

Figure 6: Concepts of vehicle ontology.

An Ontology-based Approach to Generate the Advanced Driver Assistance Use Cases of Highway Trafﬁc

sent these relationships and rules. Note that we use

the ID of concepts as the variables in the relationship

formulas.

Figure 8: Relationships (solid lines) and effects (dashed li-

nes).

a. Relationships between Highway Entities

There are three types of relationships between the en-

tities of the highway ontology:

– inheritance relationship (unary). For exam-

ple the relationship isShoulder(RightSo f tShoulder

)

means that RightSo f tShoulder

is a sub-entity of

Shoulder.

– composition relationship (binary). For example

hasCarriageway(Roadway

,RightSo f tShoulder

)

means that Roadway

is composed of

RightSo f tShoulder

– position relationship (binary) which con-

sists of the longitudinal position, the trans-

verse position and the vertical position. For

example the vertical position relationship

hasPrioritySign(RightSo f tShoulder

,PrioritySign

)

means that PrioritySign

is located on

RightSo f tShoulder

Combining the three previous types of re-

lationships, we can infer more complex relati-

onships. For example, combining relationships

isShoulder, hasCarriageway, hasPrioritySign with

isPrioritySign and isRoadway relationships, we can

infer the following one (Formula (1)).

isRoadway(Roadway

)

isShoulder(RightSo f tShoulder

)

isPrioritySign(PrioritySign

)

hasCarriageway(Roadway

,RightSo f tShoulder

)

hasPrioritySign(RightSo f tShoulder

,PrioritySign

)

→ hasPrioritySign(Roadway

,PrioritySign

)

(1)

Where

is the conjunction logical connector and

→ is the implication logical connector.

Table 5 lists out all relationships bet-

ween the entities of highway for running

example. We note that the relationships

hasRightHardShoulder(Median

,Le f thardshoulder

)

means that there is Le f thardshoulder

at the right

hand of Median

. Le f thardshoulder

is the ID of

entity le f t hard shoulder. This entity is different

from right hard shoulder which refers to the hard

shoulder at the edges of the highway.

Table 5: Relationships between highway entities for run-

ning example.

Type Relationship

Inheritance isHighway, isInterchange,

isRamp, isShoulder,

isEquipment, isSymbol,

isMarking, isSpeci f icMarking,

isSign, isPrioritySign

Composition hasSegment, hasInterchange,

hasRoadway, hasMedian,

hasCarriageway, hasShoulder,

hasLane, hasMainLane,

hasAuxilaryLane,

hasAccelerationSection,

hasTaper

Position Longitudinal position:

connecteToSegment,

connecteToAccelerationSection,

connecteToTaper

Transverse position:

hasLe f tMedian,

hasLe f tShoulder,

hasRightShoulder,

hasLe f tLine, hasRightLine,

hasLe f tChevronMarking,

hasRightChevronMarking,

hasLe f tSo f tShoulder,

hasRightSo f tShoulder

Vertical position:

hasSignCedezlepassage,

hasDe f lectionArrowMarking

b. Relationships between Vehicle Entities

There are eight (8) binary relationships bet-

ween EgoCar and the other cars (TargetCar and

OtherCar). We consider that the EgoCar position is

the origin point as shown in Figure 9.

The EgoCar can have a TargetCar in front, which

is conceptualised using relationship hasAheadVehicle

and each OtherCar around it is considered using the

KEOD 2018 - 10th International Conference on Knowledge Engineering and Ontology Development

Figure 9: Vehicles around the EgoCar.

following relationships:

- hasAheadLeftVehicle

- hasLeftVehicle

- hasBehindLeftVehicle

- hasBehindVehicle

- hasBehindRightVehicle

- hasRightVehicle

- hasAheadRightVehicle

In the ﬁrst scene of our running example, the rela-

tionship between EgoCar and TargetCar can be des-

cribed using Formula (2), and the relationship bet-

ween EgoCar and OtherCar can be described using

Formula (3).

hasAheadVehicle(Ego, V c

) (2)

hasRightVehicle(Ego, V c

) (3)

Where Ego, V c

and V c

are the ID of EgoCar,

TargetCar and OtherCar, perspectively.

c. Relationships between Highway and Vehicle

Entities

In this study, we consider that all vehicles obey the

trafﬁc rules. Therefore, the binary relationships bet-

ween vehicle and highway entities are the followings:

- enters

- leaves

- on

The formulas of these relationships have two va-

riables, the ID of concept Vehicle and the ID of

a concept which can be any of Lane, Shoulder or

Sa f etyArea. For example, in the ﬁrst scene, the rela-

tionships between the entities of vehicle and highway

can be described as:

on(Ego, Lane

) (4)

on(V c

, Lane

) (5)

on(V c

, EnLane

) (6)

Where Lane

is the ID of Lane and EnLane

the ID of EntranceLane.

We consider the trafﬁc regulation as rules to deﬁne

the features and signiﬁcance of highway infrastruc-

ture, and regulate the behavior of vehicles. In the run-

ning example, the speed on Carriageway

, which is

the ID of Carriageway, is limited to 130 km/h. This

rule limits the speed of EgoCar and this can be speci-

ﬁed as:

Speed(Ego) ≤ SpeedLimit(Carriageway

) (7)

Where Speed is a function to generate the speed

of vehicles and SpeedLimit is a function to show the

speed limit on a portion of highway. Note that v

≤

130km/h can be derived from Formula (7).

The weather phenomena can have an effect on the

highway, the vehicle and on itself (Figure 8). These

effects are also written as rules. For example, the

Snow phenomenon can only appear at very low tem-

peratures, and it can make the vehicle make action

TurnOn the FogLight to increase the visibility of Ego

for the other cars. And the Snow phenomenon can af-

fect the visibility of the Equipment of highway. In

this work, we assign values directly to the function

Visibility because there is not enough available data

to build the model which simulates the effects of we-

ather phenomena.

5 USE CASES GENERATION

Simon Ulbrich et al. (Ulbrich et al., 2015) present

a deﬁnition of interfaces for the design and test of

functional modules of an automated vehicle. Based

on that, we deﬁne the scene as a snapshot of the vehi-

cle environment including the static and mobile ele-

ments, and the relationships among those elements.

A scenario describes the temporal development bet-

ween several scenes in a sequence of scenes (Figure

10). These scenes are developped by the actions made

by EgoCar or the events occuring due to the actions

made by other vehicles, and this from the point of

view of EgoCar. A use case describes one or several

scenarios applied to some ranges and behaviors to si-

mulate the ADAS.

In order to generate use cases based on the ontolo-

gies we have deﬁned, we deﬁne a three-layers appro-

ach. This approach follows a bottom-up hierarchy of

an ontology with three layers for semantic expression

of dynamic events in dynamic trafﬁc scenes (Yun and

Kai, 2015). Our approach consists of the following

three layers:

An Ontology-based Approach to Generate the Advanced Driver Assistance Use Cases of Highway Trafﬁc

Figure 10: A scenario (red dashed line) made by acti-

ons/events (edges) and scenes (nodes).

Basic Layer: The basic layer includes the static

concepts and the mobile concepts of the highway, the

weather and the vehicle ontologies. The entities that

do not change position are considered as static. The

infrastructure and the weather are considered as the

static concepts, while EgoCar and the trafﬁc are con-

sidered as the mobile ones. Some of the static con-

cepts, such as the lighting and the weather, can change

state but not their position. We call them dynamic

concepts, in order to distinguish them from the mo-

bile ones. All the concepts that appear in the running

example are framed in Figure 5, Figure 6 and Figure

Interaction Layer: The static concepts and the mo-

bile concepts of the basic layer are deﬁned in terms

of entity, sub-entities and properties. The interaction

layer describes the interaction relationships, between

on the one hand the static entities, and on the other

hand the mobile ones. Moreover this layer describes

the relationships between static and mobile entities.

With the ﬁrst order logic, we describe the relations-

hips between the entities using formulas such as those

used for the running example in Subsection 4.2. Then

the scene generated is described as the logic formulas

with the concepts in the basic layer and the relations-

hips in the interaction layer. For example, in the ﬁrst

scene of the running example, the vehicles part can be

described as follows:

on(Ego, Lane

) (8)

on(V c

, Lane

) (9)

on(V c

, EnLane

) (10)

hasAheadVehicle(Ego, V c

) (11)

Distance(Ego, V c

) = d

(12)

hasRightVehicle(Ego, V c

) (13)

Distance(Ego, V c

) = d

(14)

Generation Layer: The task of the generation layer

is to build use cases which include one or several

scenarios. In the beginning of this section, the sce-

nario is deﬁned as a sequence of scenes, associated

with the goals, values and actions of EgoCar, the

values and events from the other actors, and the va-

lues of the properties deﬁned in the static concepts.

In the running example, the objective is the insertion

of V c

(OtherCar) by the right entrance lane of the

highway. The actions which can possibly be made by

Ego (EgoCar) are Decelerate, Accelerate and Run.

The actions possibly made by other vehicles, which

are considered as events from Ego’s point of view,

are Decelerate, Accelerate, Run, ChangeLane and

TurnOn (Figure 6).

With the same initial scene, it is evident that dif-

ferent actions or events lead to different scenes, and

make different scenarios. In the running example, we

describe two of several possibilities. The scenario in

the ﬁrst case (Figure 11) can be generated as:

Scene1 = {Concepts} ∨ {Relationships} (15)

Scene2 = (Scene1, Decelerate) (16)

Scene3 = (Scene2, Event

) (17)

Where

Event

≡ (V c

, ChangeLane(Le f t)) (18)

In Scene 2, Vc

is on EnLane

which is presented

in formula (6) and the relationship between EnLane

and Lane

is hasLe f tLane(EnLane

, Lane

). The-

refore, Event

means that V c

makes action

ChangeLane from Enlane

to Lane

Figure 11: Scenario “Insertion before Ego”.

One scenario is one possibility of a use case (Fi-

gure 10). A use case includes one or several scenarios.

The use case of autonomous vehicle is the simulation

of the driving environment, the trafﬁc and the pilot.

As the role of the pilot, system ADAS limits to a set

of decisions that will be made by EgoCar. For ex-

ample, the existence of a target vehicle is necessary

for the EgoCar to activate the system TJC. Therefore,

the EgoCar cannot make the action ChangeLane to

KEOD 2018 - 10th International Conference on Knowledge Engineering and Ontology Development

the left lane because there is no target vehicle. These

ranges and behaviors are presented as rules to make

sure that only reasonable use cases will be generated.

6 CONCLUSIONS

In this article, we propose an ontology-based appro-

ach for the generation of use cases with a hierarchy

in three layers: basic layer, interaction layer and ge-

neration layer. We built three ontologies for the con-

ceptualization and characterization of the components

of use cases: a highway ontology and a weather on-

tology to specify the environment in which evolves

the autonomous vehicle, and a vehicle ontology which

consists of the vehicle devices and the control actions.

Relationships and rules, such as trafﬁc regulation, are

expressed using a ﬁrst-order logic.

An autonomous vehicle is a safety-critical system

for which all behaviors must be predictable. The-

refore, the generated use cases need to be modelled

with a semantically explicit formal language to im-

prove their reliability and robustness. In the future,

we are interested in the formalisation of these use ca-

ses considering also the time factor.

ACKNOWLEDGEMENTS

This research work has been carried out in the fra-

mework of IRT SystemX, Paris-Saclay, France, and

therefore granted with public funds within the scope

of the French Program “Investissements d’Avenir”.

REFERENCES

Armand, A., Filliat, D., and Guzman, J. I. (2014).

Ontology-based context awareness for driving assis-

tance systems. In 2014 IEEE Intelligent Vehicles Sym-

posium Proceedings, Dearborn, MI, USA, June 8-11,

2014, pages 227–233.

Bagschik, G., Menzel, T., and Maurer, M. (2017). Ontology

based scene creation for the development of automa-

ted vehicles. CoRR Computing Research Repository,

abs/1704.01006.

Bartosiak, D. (2018). Nissan and nasa extend partnership

on autonomous tech. http://www.thedrive.com/

sheetmetal/17607/nissan-and-nasa-extend-

partnership-on-autonomous-tech.

BBC (2018). Tesla in fatal california crash was on au-

topilot. http://www.bbc.com/news/world-us-canada-

43604440.

Caughill, P. (2017). Dubai jump starts autonomous taxi

service with 50 tesla vehicles. https://futurism.com/

dubai-jump-starts-autonomous-taxi-service-with-50-

tesla-vehicles/.

Gain, B. (2017). Waymo patent shows plans to replace

steering wheel & pedals with push buttons. https://

driverless.wonderhowto.com/news/waymo-patent-

shows-plans-replace-steering-wheel-pedals-with-

push-buttons-0179498/.

ulsen, M., Z

ollner, J. M., and Weiss, C. (2011). Trafﬁc in-

tersection situation description ontology for advanced

driver assistance. In IEEE Intelligent Vehicles Sym-

posium (IV), 2011, Baden-Baden, Germany, June 5-9,

2011, pages 993–999.

Hummel, B., Thiemann, W., and Lulcheva, I. (2008). Scene

understanding of urban road intersections with des-

cription logic. In Logic and Probability for Scene In-

terpretation, 24.02. - 29.02.2008.

Krok, A. (2018). Audi expands trafﬁc light information

v2i to washington. https://www.cnet.com/roadshow/

news/audi-v2i-trafﬁc-light-information-washington-

dc/.

Minist

ere de l’

ecologie, E. d. r. e. d. r. (1988). Arr

e du 16

fvrier 1988 relatif l’approbation de modiﬁcations de

l’instruction interministrielle sur la signalisation rou-

tiere, instruction interministerielle sur la signalisation

routiere. Journal ofﬁciel du 12 mars 1988.

Minist

ere de l’

equipement, des Transports, d. L. d. T. e. d.

l. M. (2000). Dcret n 2000-1355 du 30/12/2000 paru

au jorf n 0303 du 31/12/2000. JORF n0303 du 31

dcembre 2000.

Morignot, P. and Nashashibi, F. (2012). An ontology-based

approach to relax trafﬁc regulation for autonomous

vehicle assistance. CoRR Computing Research Repo-

sitory, abs/1212.0768.

Pollard, E., Morignot, P., and Nashashibi, F. (2013). An

ontology-based model to determine the automation le-

vel of an automated vehicle for co-driving. In Procee-

dings of the 16th International Conference on Infor-

mation Fusion, FUSION 2013, Istanbul, Turkey, July

9-12, 2013, pages 596–603.

protege.stanford.edu (2012). Protg. http://protege.

stanford.edu/.

Tesla (2018). Model x. https://www.tesla.com/modelx.

Ulbrich, S., Menzel, T., Reschka, A., Schuldt, F., and Mau-

rer, M. (2015). Deﬁning and substantiating the terms

scene, situation, and scenario for automated driving.

In IEEE 18th International Conference on Intelligent

Transportation Systems, ITSC 2015, Gran Canaria,

Spain, September 15-18, 2015, pages 982–988.

Uschold, M. and Gruninger, M. (1996). Gruninger, m.: On-

tologies: Principles, methods and applications. know-

ledge eng. rev. 11(2), 93-155. 11.

Yun, Y. and Kai, C. (2015). A method for semantic repre-

sentation of dynamic events in trafﬁc scenes. Infor-

mation and control, 44(1): 83-90. http://ic.sia.cn/CN/

10.13976/j.cnki.xk.2015.0083.

Zhao, L., Ichise, R., Mita, S., and Sasaki, Y. (2015). Core

ontologies for safe autonomous driving. In Procee-

dings of the ISWC 2015 Posters & Demonstrations

Track co-located with the 14th International Semantic

Web Conference (ISWC-2015), Bethlehem, PA, USA,

October 11, 2015.

An Ontology-based Approach to Generate the Advanced Driver Assistance Use Cases of Highway Trafﬁc