I Introduction
Ia Motivation
A lot of effort has been put into demonstrating the feasibility of behavior planning, but an approach guaranteeing safety of the intended function (SOTIF, see [IOS2019]) is still far away. Building up a safety case for an autonomous driving system based on mileage driven is not suitable due to the highdimensional state space of realworld scenarios. Instead, advances in verifiability, safety assessment and explainability will be essential to make autonomous driving reliable [Schwarting2018].
Traffic rules have been designed to help humans manage the otherwise chaotic traffic environment. If all vehicles were fully autonomous, the current set of rules could be reduced or adapted. In a transition period with mixed traffic, however, we need to make sure that the planned behavior satisfies those specified rules at all times. First of all, obeying those rules would make the behavior of autonomous cars more understandable to other traffic participants. Secondly, it will help clarify the liability of the autonomous vehicle in case of an accident.
For the behavior of an autonomous vehicle to follow traffic rules, large statemachines have been used (e.g. [Urmson2008, Montemerlo2008, Leonard2008]), requiring extensive and careful engineering. Transferring such state machines to different markets with other specifications does not scale well and quickly becomes hard to maintain. The problem of behavior planning is challenging due to the highdimensional continuous state space, nonlinear motion dynamics, interactions with other agents and their unobservable intentions. This has led to researchers investigating collaborative approaches [Kessler2017a], gametheoretic approaches [Lenz2016], as well as probabilistic approaches [Hubmann2018].
However, since these new approaches try to incorporate reactive predictions into the decision making process, the complexity is growing and it becomes even harder to fuse them with classic rulebased systems to abide by the traffic regulations and specifications. Rules get either hardcoded or are inherently learned from data, which are not transferable solutions in case of rule changes. Specification as the satisfaction of traffic rules should thus be formalized in some way, for instance as formal logic.
IB Contribution
Checking potentially many trajectory hypotheses for complex traffic rules in a continuous space entails high computational costs. In this paper, we address the problem of verifying the highlevel behavior of an autonomous vehicle in a semantic state space to satisfy a set of traffic rules. The solution shall be easily integrated into a planning framework so that the final trajectory also satisfies the rules and does not need to be checked again. We make use of the work of [Altche2018a], building our verification approach on top of that. Fig.1 gives an overview of our approach.
The main contributions of this paper are:

an LTL representation corresponding to the partitioning method of [Altche2018a],

the formalization of some traffic rules to LTL for the introduced semantic state,

a method to verify highlevel maneuvers to comply to these rules,

evaluations showing computational properties of the approach.
This paper is organized as follows: Section II presents work directly related to our paper. Section III defines the addressed problem. Section IV introduces the necessary concepts this work is based on. The proposed method is presented in Section V. In Section VI, we formalize a set of traffic rules. Section VII evaluates the algorithm’s abilities followed by a discussion in Section VIII.
Ii Related Work
Recent work such as [Wolff2014, Rizaldi2018, Vasile2017] investigated verifying reachandavoid tasks^{1}^{1}1In reachandavoid tasks, the robot stays in a safe region until the goal region is reached. or routing tasks in linear temporal logic (LTL). LTL is a formal language that combines boolean and temporal operators. Plaku2016 argue for its expressiveness on sequencing and partial ordering as well as persistency (”move slowly”). Wolff2014 transform linear temporal logic constraints to mixed integer linear constraints. In this way, temporal constraints can be integrated into optimizationbased motion planning without creating an abstraction to verify the LTL formula. Solving this MILP leads to an optimal trajectory satisfying the logical specifications. They apply this approach to reachavoid tasks, whereas we focus on maneuver planning.
Rizaldi2018 present an automatabased maneuver planner where each motion primitive is encoded as a state. They formalize reach (”until you reach the goal”) and avoid tasks (”do not collide with an obstacle”) to LTL to check the validity of a transition from one state to another. In contrast, we identify atomic propositions that allow us to express highlevel maneuvers such as overtaking directly in LTL.
Rizaldi2015 were the first to use logic as a language to formalize Vienna Road Traffic rules by specifically using higher order logic (HOL) in [Rizaldi2015]. Their work is extended in [Rizaldi2017], where they use LTL to formalize German traffic rules. As they use highlevel states such as overtaking or merging as atomic propositions, they need to verify the value of the overtaking proposition externally (i.e., not LTL). In contrast, we describe maneuvers such as overtaking using LTL as a sequence of states. Their approach checks for rule satisfaction in a continuous state space and can be used as the monitor system of an ego trajectory, whereas we formulate rules in a semantic state space.
Kohlhaas2015 use a semantic state space that consists of the state and action space of the ego vehicle for a highlevel maneuver planner. Relations of objects and road elements are represented in an ontology. They transform the semantic space as a directed graph and use a graph search to generate feasible solutions. They claim that their semantic state space is capable of representing traffic rules by the use of conditions. However, they do not describe which rules they model. In contrast, we present a set of rules from the Vienna Convention in regard to overtaking and passing orders.
ReyesCastro2013 translate LTL specifications into an automaton. A second automaton is created as a discrete abstraction of an RRT*explored workspace. A discrete search then creates feasible traces satisfying the LTL formula which guide the RRT* into feasible directions satisfying the specification. Similar to our approach, they check for the satisfaction of rules at an abstract layer. However, they only check for safety rules such as ”do not cross solid center lines” or ”do not travel in the wrong direction”. In contrast, the combinatorial approach we use directly applies lane constraints to the planning problem, thus satisfying these types of rules by design.
Iii Problem Definition
We follow the behavior planning problem formulation we introduced in [Esterle2018]. There, we separate the problem into highlevel envelope planning and lowlevel trajectory planning inside a homotopy. Based on an object list and a prediction for each object, the envelope planner has to plan a maneuver envelope
(1) 
at each prediction time step in local streetwise coordinates with the arc length and the perpendicular offset . The maneuver envelope is then used for lowlevel trajectory planning. Fig.2 shows our contribution embedded in a planning framework.
In this paper, our goal is to generate envelopes satisfying a set of rules. To do so, we generate a semantic trace representing a possible maneuver variant. When selecting such a maneuver, we need to consider rules such as passing orders and overtaking rules. We formulate the satisfaction of traffic regulations and social conventions on the highlevel envelope planner as a model checking problem. Given a semantic trace and a set of rules , the following should hold:
(2) 
The operator denotes the satisfaction relation of LTL.
Iv Preliminaries
Iva Linear Temporal Logic
Temporal logics extend classical logics by temporal operators to reason not just about an absolute truth but about truths which might hold only at some points in time. Linear temporal logic (LTL) is one of the simplest, building upon propositional logic by adding temporal operators.
IvA1 Syntax
Formally, the language of LTL formulas is defined as
where denotes a set of atomic propositions, (resp. , , ) denote the boolean operators “not”, “and”, “or” and “implies”, and , (resp. , , ) denote the temporal operators “next”, “until”, “globally” (or “always”), “finally” (or “eventually”).
Precedence is defined as follows: The unary operators bind stronger than the binary ones, e.g. is equal to
. The “until” operator is rightassociative, e.g. is equal to . and bind equally strong. Operator takes precedence over , , .
We first need to characterize when a formula is true or not. In LTL, this is done with respect to a trace:
Definition IV.1
A valuation of is a function that assigns to each proposition of an element of . A trace is an infinite sequence of valuations.
For instance, if , then the function defined by , , is a valuation of . Intuitively, it represents the truth value of every variable in a given configuration. A trace represents the evolution of such configurations over time. Note that from an algorithmic viewpoint, a maneuver defined over a given planning horizon is finite. A finite sequence of valuations is turned into a trace by repeating the last valuation indefinitely.
IvA2 Semantics
We can define the semantics of an LTL formula as follows:
Definition IV.2
For every formula , every instant and every trace , the relation (pronounced “ holds for at instant ”) is inductively defined as follows:

if and only if (iff) ,

iff and ,

iff or ,

iff or ,

iff ,

iff for all , ,

iff there exists s.t. ,

iff there exists such that and for all , .
When we have a trace with the configurations with , we denote it by (). Table I provides examples for the temporal operators.
IvB Free SpaceTime Partitioning
To facilitate highlevel decisions, an intermediate representation bridging the gap between obstacle lists from sensor fusion and semantic information is needed. We build on top of the work of Altche2018a, that partitions collisionfree spacetime into discrete threedimensional cells with geometric adjacency relations, described in the following.
We first briefly introduce the concept of partitioning in 2D space. Let denote the extend of the road in the Frenet space. The free space around an obstacle is partitioned into four collisionfree regions – front, behind, left and right. For each obstacle, regions are derived in accordance with Fig.3.
Fig.4 illustrates the concept of enumeration of the free space. The setbased intersection of the region ”behind ” (denoted by ) and ”to the right of ” () yields a new region ”to the right of and behind ”. This region is abbreviated with the signature , where the order of the letters refers to the respective obstacle .
Partitioning the 2D free space at each discrete time step yields a set of free spacetime cells , denoted by . denotes the spacetime cell corresponding to the signature at time step . The term cell is used here in contrast to 2D, where we only speak of regions.
From this discrete cell decomposition, adjacency information is calculated to create a graph structure. The discrete transition graph is defined as with the vertex set and the edges set . We let . Edges between two cells and at two consecutive time steps and exist if the cells are adjacent at both time steps. For the definition of adjacency , we refer the reader to [Altche2018a]. Formally, is defined as:
Fig.5 illustrates the relationship between the free spacetime partitioning and the adjacency graph, called navigation graph. Since the obstacle moves faster than , the cells with the signatures and are no longer adjacent at . Therefore, no connection exists in the adjacency graph between the corresponding vertices.
Each path in corresponds to a set of homotopic collisionfree trajectories (that may, however, be infeasible). This reduces the behavior generation problem to a discrete selection of a maneuver variant and trajectory planning for the obtained maneuver variant.
V Maneuver Verification
Va Semantic State Space Definition
The challenge of formalizing traffic rules in LTL starts with the selection of an expressive semantic state space and abstracting that as atomic propositions. Based on the navigation graph, we introduce a semantic state space for each agent in the scenario except the ego vehicle:

Obstaclerelated:

position of the free space in relation to the traffic participant (in front , behind , to the left , to the right ),

traffic participant type vehicle , pedestrian , cyclist , railborne (denoted as a subscript of the position).


Road typerelated (pedestrian crosswalk , carriageway ).
Let us formalize these notions in a form suitable for LTL. We first need to define atomic propositions. There exist only two road type propositions: and . For obstacle propositions, let (resp. , resp. ) be the set of all vehicles (resp. pedestrians, resp. cyclists) in the scenario. Then, for every obstacle , the following are atomic propositions: , , , .
Let be a representation of the current situation. We can create a corresponding LTL trace, in the following denoted by (recall that a trace is a sequence of functions assigning to every atomic variable a truth value at a given instant). First, we have (resp. ) iff the road type is a pedestrian crosswalk (resp. on the carriageway) at instant .
For every instant and every object , we have:

iff ego is in front of at instant ,

iff ego is behind at instant ,

iff ego is to the left of at instant ,

iff ego is to the right of at instant .
VB Road typebased Partitioning
Following our state space definition, we extend the partitioning of the road space (see Section IVB) to include road type information. Instead of checking the roadtype for each free spacetime cell when evaluating a trace, we choose to encode the property of roadtype in the discrete graph. This way, we keep the direct mapping from a trace to a maneuver intact instead of introducing an intermediate step of processing a discrete path and cutting out roadtype related regions.
We calculate a set of road regions , where the superscript denotes the partitioning related to the road type. We then use as the initial set of regions for the free spacetime partitioning, following Algorithm 1 in [Altche2018a].
VC Runtime Verification
Classical model checking would require translating the graph structure into an automaton. The model checker would then generate traces that comply with the formalized rules. However, we choose to go in another direction by performing runtime verification. We do not create an automaton from the full graph but only from a graph traversal from the root node to a goal node thus yielding only a trace instead of a ”fullfledged” automaton. We then use a model checker to check whether such a trace satisfies the specified rules according to (2). The benefit of our formulation is that we leave the general concept of [Altche2018a, Park2015]
untouched, which is to assign heuristic costs to each graph solution, then rank them along those costs and select a finite number of graph solutions for trajectory planning. Using additional information as graph costs such as time gaps would not directly be possible if we translated the graph to an automaton for model checking. Another benefit of runtime verification is its possible use in combination with other planners as the trace to be checked does not necessarily have to be a graph solution.
However, the creation of a single automaton for each trace instead of the whole graph creates additional computational overhead. Note that we do not know beforehand whether the selected path from the transition graph is dynamically feasible. It thus may be necessary to check many traces. The model checking approach on the other hand would always provide valid plans.
Algorithm 1 shows the proposed method. For a given planning interval , we construct the semantic finite abstraction of the current state of all relevant traffic participants and their predicted motions by first partitioning the state space (Line 6). The function generateFiniteAbstraction() contains the partitioning along the road type (Section VB) and the free space (see Section IVB). For a detailed description of the free space partitioning and the calculation of adjacency in generateAdjacencyGraph(), we refer the reader to [Altche2018a]. From that, we obtain a graph representation (Line 7). The starting node represents the cell where the ego vehicle is located at the initial planning time step. As we do not know the final cell of the optimal maneuver yet, all cells at the final time step are possible goal cells. We perform a graph search to get all possible traces (Line 11). We finally calculate the time margins using a function calculateTimeMargins() as in [Altche2018a]. We assume the existence of a function sort() to sort the traces by their costs (Line 14). We then verify each semantic trace using the proposed verification method.
We turn a finite time trace into an infinite trace by repeating the last state indefinitely. This may cause inaccuracies, as we evaluate the nextoperator on the last (repeated) state. Investigating these sideeffects in detail and evaluating finitetime semantics is the subject of future work.
As the instants correlate with prediction time steps, a verified trace from satisfying the specifications can be directly mapped to a maneuver envelope as defined in (1), serving as the input to the trajectory planner.
Vi Vienna Convention Traffic Rules as LTL
Based on the Vienna Convention of Traffic Rules [EconomicCommissionforEuropeInlandTransportCommittee1968], we have selected rules that cover the interaction of the ego vehicle with only one other traffic participant. Extending this to rules that cover more traffic participants is the subject of future work.
Traffic Rule 1
Do not overtake a vehicle on its right side, except in congested traffic, where overtaking on the right is also allowed (Article 11.1, 11.6).
The rule concerns roads with two or more lanes in the same direction such as highways. The rule shall only apply in congested traffic. Formalizing congestion requires the speed of the vehicles, which we choose not to include in our semantic state space definition. Here, we assume the scene interpretation module to provide a signal CONGESTED. It could for example be set to true if all other vehicles are slower than a certain threshold. We formulate as:
This means that except for the case of congested traffic, we do not allow a temporal sequence in which the ego vehicle starts behind a vehicle, goes to the right of the vehicle and then goes in front of the vehicle. The until operator allows to follow this rule independently of the number of instants that the ego vehicle stays to the right of the other vehicle. If the first occurrence of were not in the formula, the trace would not be valid. We thus limit the forbidden set by adding followed by the ordering . Fig.6 illustrates a scenario in which the obtained trace for the overtaking maneuver on the right does violate . Note that since the rule applies to each obstacle, we perform the rule checking for each obstacle separately. For simplicity reasons, Fig.6 displays only an abbreviated signature of the trace omitting road type information.
Traffic Rule 2
Do not overtake a vehicle that slows down or waits in front of a pedestrian walk (Article 11.9).
We rephrase as follows: A vehicle shall not be overtaken if a pedestrian crosswalk is immediately in front of the vehicle. This is a slightly modified version of the actual rule as we do not model the slowdown but only the position of the crosswalk in relation to the vehicle. This way we impose that a vehicle which is not slowing down should not be overtaken as well, which we consider a reasonable assumption as well. Formally, this results in
The rule is similar to , mirroring the overtaking maneuver on the right instead of the left. The last temporal state we request for such a trace to be forbidden needs to be in front of the respective vehicle but also of the road type pedestrian crosswalk . Fig.7 illustrates a scenario where the maneuver to overtake the red vehicle right in front of a pedestrian crosswalk will be forbidden as it violates .
Traffic Rule 3
Stop if pedestrians are using or intend to use a pedestrian crossing. (Article 21.3)
We formulate it as
such that no state in the trace is allowed that is a pedestrian walk and lies in front of a pedestrian. The formulation covers pedestrians coming from the left and right. Fig.8 illustrates a maneuver that forbids.
Vii Evaluation
Viia Evaluating the Formalized Rules
We will first use synthetic traces to show the effectiveness of our formalized rules. Table II shows that the trace representing a maneuver to overtake on the right violates . It can also be seen that the sequence defining a maneuver to overtake on the right in the trace
can be captured and classified as violating as well, no matter how many states the trace has.
However, there are some drawbacks from the selected state space. The relation ”right of ” states that is in the next lane to the right. Still, we currently cannot capture that could be before or behind the ego vehicle. An extension of the state space could be beneficial to formalize such rules more clearly. We leave this to future work.
Rule forbids overtaking of a vehicle that is right in front of a pedestrian walk. Table III shows example traces and whether they satisfy rule or not. In regard to the obstaclerelation , and are identical. However, they differ in the road type of their final state, which is why violates and the others do not.
Rule forbids any state that is a pedestrian crosswalk and in front of a pedestrian. Table IV shows a trace with (). This represents a situation in which a pedestrian is to the left of the street oriented towards the street, while the ego vehicle passes the pedestrian. As can be seen in Table IV, rule forbids such a trace if the pedestrian stands at a pedestrian crosswalk, represented by the state . If not, the trace will be classified as legal.
ViiB Maneuver Verification
We want to answer the following questions:

Is it feasible to check all maneuvers?

How long does it take to check a maneuver?

How does the complexity of the problem influence the runtime?
ViiB1 Implementation
As explained in Section VC, we do runtime verification instead of model checking. Although it might appear as an overkill, we use NuSMV, a powerful model checking tool [Cimatti2002], since this will allow us to easily modify and extend our approach in the future. All algorithms have been implemented in MATLAB. The simulations were performed on a 2.6GHz desktop PC with 16GB RAM.
ViiB2 Scenarios
We evaluate three different scenarios: A twolane samedirection scenario similar to [Altche2018a], a twolane scenario with a pedestrian crossing, and a threelane highway CommonRoad scenario [Koschi2017]. We assume full observability and use a constantacceleration model to predict the other participants. Fig.9 illustrates the scenarios. We compare all scenarios for a planning horizon of for two different grades of discretization. We compute the predicted occupancy of each obstacle between consecutive time instants . This ensures that we do not miss any occupancy when partitioning at larger step sizes. However, the occupied areas grow with the size of the step size. Some maneuvers might thus not be available at a broader discretization.



ViiB3 Computational Results
Table V summarizes our computational results. The size of the adjacency graph depends on the number of time steps, the number of obstacles, the number of unique road types and the layout of the scenario.
At this early stage, we use a naive implementation calculating every possible path from the starting node to all possible goal nodes. This leads to an explosion of the number of traces for . To understand the reason for that, let us have a look at the following traces:
The graph approach distinguishes between the traces although they might (and in this case do) represent the same homotopy class. To introduce a topology grouping step after the graph search omitting those duplicate traces or to use branchandbound techniques will be the subject of future work.
The number of traces for is much higher than for . Because contains a pedestrian walk, we obtain four additional cells. We get a high number of adjacent cells leading up to a high number of possible traces for two reasons: First, the adjacency definition in [Altche2018a] lets two cells be adjacent if the closures intersect at a single point, which trades a lower number of infeasible traces in a kinematic sense for lower computational costs in the adjacency calculation. Secondly, we do not distinguish between forward and backward driving, which also introduces additional connections between cells. Improving these two points in combination with the topology grouping step will reduce the number of traces. We list the computational costs for calculating a single trace using the Dijkstra algorithm, for which we set the weights of the graph to the time gaps introduced in [Altche2018a]. Improving the weights of the graph will also be the subject of future work.
We observe for with the smaller step size that a small number of traces get rejected. These traces represent maneuvers going to the left lane and then starting an overtaking maneuver on the right which consequently violate . Running with the coarser discretization does not allow such complex maneuvers, which is why all of the 16 traces are valid.
We chose Scenario to demonstrate the necessity for our rulechecking approach. Roughly forty percent of the traces get rejected, because they violate the rules. Checking a single trace takes around per obstacle in our implementation. This could be further sped up as we currently create a model file for every trace that we check, save that on the hard drive and then call the model checker. Future work will focus on reducing the computational time.
Scenario , which depicts a scene from the popular NGSIM dataset, shall show the feasibility of our approach in more realistic scenarios. Compared to , it takes roughly three times as much time. Reasons for that are the arbitrary shape of the road and the number of lanes.
The verification of a trace for takes about half the time compared to and . The reason is that and consider two obstacles, which brings the necessity to check the rules for each obstacle in separately. We evaluated the runtime of a trace verification with ten rules instead of three, which did not change the runtime significantly. With the need to check potentially many traces, the model checker might seem like a bottleneck. However, model checking tools support a huge set of formulas. To tune the verification algorithm for online use in a car running at a high frequency, a model checker only supporting our limited formula could be implemented more efficiently.
We have not discussed sequential planning yet, which means the use of the maneuver verification approach in a receding horizon manner. A maneuver to overtake a vehicle on the right might be forbidden, but a maneuver to only change to the right lane might be legal. At the next planning step, passing the vehicle and changing back to the left lane might be feasible as well. Possible ways to cope with that could be to incorporate past states into the trace checking. A detailed analysis of such effects is the subject of future work.
Scenario Description  
Planning horizon  4  4  4  4  4  4 
Step size  1  0.5  1  0.5  1  0.5 
No. of obstacles  2  2  1  1  2  2 
No. of road types  1  1  2  2  1  1 
Semantic Partitioning  
Graph Nodes  20  36  35  63  20  36 
Graph Edges  32  70  124  248  40  80 
Maneuver Verification  
No. of all traces  16  672  139  75441  76  4240 
No. of sat. traces  16  640  83  35531  61  1840 
Computation times  
Partitioning  0.073  0.129  0.144  0.206  0.290  0.426 
Graph generation  0.014  0.021  0.020  0.037  0.013  0.020 
Dijkstra Search  0.001  0.000  0.000  0.000  0.001  0.000 
Calculating costs  1e05  9e06  1e05  1e05  8e06  1e05 
Verification of  0.044  0.045  0.022  0.024  0.043  0.046 
Viii Conclusion and Future Work
To formalize traffic rules using LTL, we introduced a novel link between combinatorial behavior planning and model checking. We showed that LTL can indeed be used to verify highlevel maneuver plans. This may help shift part of the development from writing code to writing specifications. Although we discretize the continuous environment and evaluate the rules on a higher, more abstract level, the rules still hold on the continuous level due to the homotopy property of each trace.
We selected rules that cover only one other traffic participant. Future work will need to consider interactions with more than one road user. Further investigations will also concentrate on the improvement of the graph costs, where we currently use the notion of time gaps, a relatively sparse definition that yields many traces with the same costs. We briefly touched the limited expressiveness of the semantic space in Section VIIA, which we will try to extend in the future while carefully weighing increased computational complexity against expressiveness.
When expressing traffic rules in the real world, there is a difference between ”should” and ”must”. Some rules must never be violated, others should not be violated except in emergency situations. Future work includes investigating the difference between soft and hard rules as well as developing a heuristic for a graph search algorithm that incorporates knowledge of previously checked traces.
As a probabilistic prediction will be essential for robust behavior planning, the approach needs to be extended to incorporate the prediction of multiple possible maneuvers. This could open the door for probabilistic model checkers. Alternatively, our method could be used as an additional safety layer which verifies a probabilistic behavior planner.
Comments
There are no comments yet.