Introducing Liveness into Multi-lane Spatial Logic lane change controllers using UPPAAL
MM. Gleirscher, S. Kugele, S. Linker (Eds.): 2nd InternationalWorkshop on Safe Control of Autonomous Vehicles (SCAV 2018)EPTCS 269, 2018, pp. 17–31, doi:10.4204/EPTCS.269.3 © M. SchwammbergerThis work is licensed under theCreative Commons Attribution License.
Introducing Liveness into Multi-lane Spatial Logiclane change controllers using UPPAAL ∗ Maike Schwammberger
Department of Computing Science, University of OldenburgOldenburg, Germany [email protected]
With Multi-lane Spatial Logic (MLSL) a powerful approach to formally reason about andprove safety of autonomous traffic manoeuvres was introduced. Extended timed automatacontrollers using MLSL were constructed to commit safe lane change manoeuvres on high-ways. However, the approach has only few implementation and verification results. We thusstrenghen the MLSL approach by implementing their lane change controller in UPPAAL andconfirming the safety of the lane change protocol. We also detect the unlive behaviour ofthe original controller and thus extend it to finally verify liveness of the new lane changecontroller.
Keywords.
Autonomous cars, Multi-lane Spatial Logic, Automotive-Controlling TimedAutomata, UPPAAL, Safety, Liveness.
Nowadays, driving assistance systems and fully autonomously driving cars are increasingly cap-turing the market. For such autonomous systems, traffic safety and prevention of human ca-sualties is of the utmost importance. In this context, safety means collision freedom and thusreasoning about car dynamics and spatial properties. A softer, but also highly desirable, re-quirement is liveness, meaning that a good state is finally reachable.An approach to separate the car dynamics from the spatial considerations and thereby tosimplify reasoning, was introduced in [13] with the Multi-lane Spatial Logic (MLSL) for express-ing spatial properties on multi-lane motorways with one driving direction for all cars. The ideato separate dynamics from control laws follows the work by Raisch et al. [20] and Van Schuppenet al. [11].The logic MLSL and its dedicated abstract model was extended for country roads withoncoming traffic [12] and urban traffic scenarios with intersecting lanes [14, 27]. The authorsinformally introduced respective controllers for safe lane change manoeuvres and safe turningmanoeuvres at intersections. The respective safety of the controllers is proven with a semi-formalmathematical proof [13, 12, 14]. With automotive-controlling timed automata (ACTA) , a formalsemantics for the previously informal controllers was later introduced [14]. (Un-) decidabilityresults for (parts of) the logic MLSL were provided [10, 16, 23].MLSL itself is a thoroughly researched and strong formal approach for proving propertiesof autonomous traffic manoeuvres. Recently, the first computer-based assistance for reasoningwith a new hybrid extension of MLSL (HMLSL) was introduced by Linker [17]. The authors ∗ This research was partially supported by the German Research Foundation (DFG) in the Research TrainingGroup GRK 1765 SCARE. Introducing Liveness into MLSL lane change controllers successfully investigate safety constraints for the motorway traffic scenarios from [13] with Is-abelle/HOL [22]. They outline an interesting extension of their work to liveness properties.In this paper, we also focus on the motorway case. While [17] presents a strong implementa-tion result focused directly on the spatio-temporal logic HMLSL, we instead investigate safetyand liveness of the protocol of the lane change controller for highway traffic [13]. The controllercan be formalised as an automotive-controlling timed automaton (ACTA) [14] and uses formulasof MLSL to reason about traffic situations and to decide, whether a car can safely change lanes.As ACTA are extended timed automata [1], we implement the lane change controller in thetool UPPAAL [2], which allows for model-checking of timed automata. With this, we verify thecorrect behaviour of the considered lane change protocol and confirm the hitherto informallyproven safety property in a preferably generic UPPAAL model. Thus, our goal is to show unreachability of a bad state with a collision in the overall system. With UPPAAL, we alsodetect the absence of liveness in the original lane change controller from [13]. We thus adaptthe old lane change controller and show the liveness of the new controller with UPPAAL.In Sect. 2, we briefly introduce the abstract model and logic MLSL from [13]. We alsointroduce the lane change controller and ACTA formalism. In Sect. 3, we explain the adaptionsof the lane change controller for the implementation in UPPAAL and introduce our UPPAALverification properties. We extend the original controller from [13] to a new live lane changecontroller in Sect. 3.4. Finally, we summarise our results in Sect. 4 and give ideas for futurework.
In this section, we briefly introduce the approach from [13]. For this, we start with an overviewover the abstract model for highway traffic in Sect. 2.1 and introduce the Multi-lane Spatial Logicin Sect. 2.2. In Sect. 2.3, we introduce the automotive-controlling timed automata (ACTA) from[14], which serve to formalise the lane-change controller from [13], that we describe in Sect. 2.4.
The abstract model for highway traffic consists of neighbouring infinite lanes , , . . . of continuousspace, leading in the same direction from the set of all lanes L . Every car has a unique caridentifier A , B , . . . from the set I of all car identifiers and a real value for its position pos on alane. An example for a traffic situation in our abstract model is depicted in Fig. 1. We use theconcept of an ego car as the car under consideration and use the special variable ego to refer tothis car. For Fig. 1, we assume E is our ego car and thus have the valuation ν ( ego ) = E .In the abstract model, the space a car E is currently occupying on a lane is represented by its reservation res ( ego ), while a claim clm ( ego ) is akin to setting the direction indicator (cf. dottedpart of cars A and B in Fig. 1, showing the desire of A and B to change to lane ). Thus, a claimrepresents the space a car plans to drive on in the future. For now we assume, that the size ofa car includes its’ physical size and its braking distance. With this, safety is already violated, ifa car invades the braking distance of another car. The idea is that every car is supposed to beable to do an emergency brake at every moment, without causing a collision.Static information about cars like their positions and their reserved or claimed lanes iscaptured in a traffic snapshot TS = ( res , clm , pos , spd , acc ) from the set TS of all traffic snapshots.E.g. res ( A ) = { } , clm ( A ) = { } and pos ( A ) = for car A in Fig. 1. As lanes are of infinite . Schwammberger B A B D A E View V ( E, TS ) pos ( E ) h h Figure 1: Abstract model with adjacent lanes to and cars A , B , E and D . Cars A and B bothplan to change to lane , indicated with their resp. dotted claims on lane . Car D is too faraway from car E to be considered in E ’s standard view V ( E , TS ).size, we also have an infinitely large traffic snapshot with infinitely many cars in it. However,for checking safety and liveness properties of our lane-change controller, only cars within somebounded view V around our ego car E are of interest. Definition 1 (View) . For an arbitrary traffic snapshot TS , the view V , owned by car E ∈ I , isdefined by V = ( L , X , E ) , where L ⊆ L is an interval of lanes visible in V and X = [ r , t ] ⊆ R is aninterval of space along the lanes.We define the standard view of car E by V ( E , TS ) = ( L , [ pos ( E ) − h , pos ( E ) + h ] , E ) , where h is a sufficiently large horizon for looking forwards resp. backwards from the position pos ( E ) , asgiven in the traffic snapshot TS . Note that we assume there exists a minimal positive value for the size of all cars, thusonly finitely many cars are considered in a view. We furthermore assume that there exists amaximum velocity for all cars and the horizon h is big enough to consider the fastest car thatcould endanger E contained in its the standard view V ( E , TS ). In the example in Fig. 1, car D is not considered in V , as it is to far away from E .We use a car dependent sensor function Ω E : I × TS → R + which, given a car identifier C ∈ I and a traffic snapshot TS ∈ TS , provides the size Ω E ( C , TS ) of C as perceived by E ’s sensors.For a view V = ( L , X , E ) and a traffic snapshot TS = ( res , clm , pos , spd , acc ), we introduce thefollowing abbreviations, used for the semantics definition of our logic MLSL in the next Sect. 2.2: res V : I → P ( L ) with res V ( C ) = res ( C ) ∩ L (1) clm V : I → P ( L ) with clm V ( C ) = clm ( C ) ∩ L (2) len V : I → P ( L ) with len V ( C ) = [ pos ( C ) , pos ( C ) + Ω E ( C , TS )] ∩ X (3)The functions (1) and (2) restrict their counterparts res ( C ) and clm ( C ) from TS to the set oflanes considered in V . Function (3) defines the part of car C that E perceives with its sensors inthe extension X of the considered view V . With Multi-lane Spatial Logic (MLSL), we can reason about traffic situations in our local view V . As variables, we allow for car variables c , d , . . . from the set CVar , valuated with car identifiersfrom the set I and lane variables n , l , . . . from the set LVar , valuated with lanes from L . We define ego ∈ CVar .0 Introducing Liveness into MLSL lane change controllers
Definition 2 (Valuation of variables) . A valuation ν is a function ν : Var → I ∪ L , where Var = CVar ∪ LVar and ν : CVar → I and ν : LVar → L . Formulae of MLSL are built from atoms, Boolean connectors and first-order quantifiers. As spatial atoms, we use free to represent free space on a lane and re ( c ) (resp. cl ( c )) to formalisethe reservation (resp. claim) of a car. We also allow for the comparison of variables u = v forvariables u , v , ∈ Var of the same type.We use a horizontal chop operator similar to chop operations for timing intervals in DurationCalculus [6] or interval temporal logic [21], denoted by (cid:97) . Also, we introduce a vertical chopoperator given by the vertical arrangement of formulas. Intuitively, a formula ϕ (cid:97) ϕ holds ifwe can split the view V vertically into two views V and V such that on V the formula ϕ holdsand V satisfies ϕ . Similarly a formula ϕ ϕ is satisfied by V , if the view can be chopped at a laneinto two subviews, V and V , where V i satisfies ϕ i for i = , . Definition 3 (Syntax) . The syntax of a
Multi-lane Spatial Logic formula φ M is defined by ϕ M :: = true | u = v | free | re ( c ) | cl ( c ) | ¬ ϕ | ϕ ∧ ϕ | ∃ c : ϕ | ϕ (cid:97) ϕ | ϕ ϕ ,where c ∈ CVar and u , v ∈ Var . We denote the set of all MLSL formulas by Φ M . The semantics of MLSL formulas is defined over a traffic snapshot TS , a view V and avaluation of variables ν . We denote the length of a real interval X ⊆ R by | X | . Definition 4 (Semantics of MLSL) . The satisfaction of MLSL formulas ϕ with respect to atraffic snapshot TS , a view V = ( L , X , E ) with L = [ l , n ] and X = [ r , t ] , and a valuation ν of variablesis defined inductively as follows: TS , V , ν | = true for all TS , V , ν TS , V , ν | = u = v ⇔ ν ( u ) = ν ( v ) TS , V , ν | = free ⇔ | L | = and | X | > and ∀ i ∈ I V : len V ( i ) ∩ ( r , t ) = /0 TS , V , ν | = re ( c ) ⇔ | L | = and | X | > and ν ( c ) ∈ I V and res V ( ν ( c )) = L and X = len V ( ν ( c )) TS , V , ν | = cl ( c ) ⇔ | L | = and | X | > and ν ( c ) ∈ I V and clm V ( ν ( c )) = L and X = len V ( ν ( c )) TS , V , ν | = ¬ ϕ ⇔ not TS , V , ν | = ϕ TS , V , ν | = ϕ ∧ ϕ ⇔ TS , V , ν | = ϕ and TS , V , ν | = ϕ TS , V , ν | = ∃ : ϕ ⇔ TS , V , ν | = ∃ α ∈ I V : TS , V , ν ⊕ { c (cid:55)→ α } | = ϕ TS , V , ν | = ϕ (cid:97) ϕ ⇔ ∃ s ∈ R : r ≤ s ≤ t and TS , V [ r , s ] , ν | = ϕ and TS , V [ s , t ] , ν | = ϕ TS , V , ν | = ϕ ϕ ⇔ ∃ m ∈ N : l − ≤ m ≤ n + and TS , V [ l , m ] , ν | = ϕ and TS , V [ m + , n ] , ν | = ϕ Abbreviation.
In the following we use the abbreviation (cid:104) ϕ (cid:105) to state that a formula ϕ holds somewhere in the considered view. For example, in Fig. 1 with valuation ν ( ego ) = E , the formula (cid:104) ϕ (cid:105) ≡ (cid:104) re ( ego ) (cid:105) holds in V ( E , Road ), because there somewhere exists a reserved space for car E . Example . Consider Fig. 1 and assume a valuation of variables ν ( ego ) = E , ν ( a ) = A , ν ( b ) = B and ν ( d ) = D . Consider the following MLSL formulas: ϕ ≡ (cid:104) re ( ego ) (cid:97) free (cid:105) ϕ ≡ (cid:104) cl ( a ) ∧ cl ( b ) (cid:97) ¬ cl ( a ) ∧ cl ( b ) (cid:105) ϕ ≡ (cid:104) cl ( b ) (cid:97) free (cid:97) re ( d ) (cid:105) . Schwammberger V ( E , TS ) the formula ϕ holds, as there is free space in front of car E . Equally ϕ holds,as there is a claim of both cars A and B at the same spot on lane and after this there is aspace with only the claim of car B . Thus TS , V ( E , TS ) , ν | = ϕ and TS , V ( E , TS ) , ν | = ϕ . However, TS , V ( E , TS ) , ν (cid:54)| = ϕ , as car D is not part of view V ( E , TS ). (cid:52) Before we introduce the actual lane change controller protocol from [13] in Sect. 2.4, we brieflydefine the extended timed automata type, introduced in [14] to formalise the controller. As vari-ables these automotive-controlling timed automata (ACTA) use both clock and data variables.For clock variables x , y ∈ X and clock updates we refer to the definition of timed automata [1]and for data variables u , v ∈ Var and data updates we refer to the extension of timed automataproposed for UPPAAL [9]. These clock and data updates ν act are allowed on transitions ofACTA.Further on, the controllers use MLSL formulas ϕ M as well as clock and data constraints ϕ X resp. ϕ Var as guards ϕ on transitions and invariants I ( q ) in states q . An example for a dataconstraint for a variable l ∈ Var is l > . A guard or invariant ϕ from the set Φ of all guards andinvariants is defined by ϕ ≡ ϕ M | ϕ X | ϕ Var | ϕ ∧ ϕ | true .We express possible driving manoeuvres by controller actions , which may occur at the tran-sitions of an ACTA. Controller actions e.g. enable a car to set or withdraw ( wd ) a claim ( c ) ora reservation ( r ) for a lane. Definition 5 (Controller Actions) . With c ∈ CVar , a controller action c act is defined by c act :: = c ( c , ψ D ) | wd c ( c ) | r ( c ) | wd r ( c , ψ D ) | τ ,where ψ D :: = k | l | l + l | l − l with k ∈ N , l , l ∈ LVar . The set of all controller actions isdefined by
Ctrl
Act . In this section, we introduce the lane change controller from [13], whose implementation intoUPPAAL we introduce in Sect. 3. The overall goal of this controller is to safely change lanesin freeway traffic. Here, safety of ego car means collision freedom and thus disjunction of thereserved spaces of ego and other cars, expressed by the MLSL formula
Safe ( ego ) ≡ ¬∃ c : c (cid:54) = ego ∧ (cid:104) re ( ego ) ∧ re ( c ) (cid:105) . (4)The main idea for the lane change controller is to first claim the space on a lane it wants toenter and reserve it only if no collision is detected. We assume a lane change to take at most t lc time to finish. The lane change controller is constructed for the ego car ( ν ( ego ) = E in theexample from Fig. 1) but scales to all cars as ego can be substituted by an arbitrary car variable c ∈ CVar .We explain the construction of the controller starting with the initial state. As we want toprevent different reservations from overlapping, we introduce a collision check for the ego carexpressed by the MLSL formula cc ≡ ¬∃ c : c (cid:54) = ego ∧ (cid:104) re ( ego ) ∧ re ( c ) (cid:105) . (5)2 Introducing Liveness into MLSL lane change controllers
Formula (5) is evaluated to true, iff nowhere exists a car different from the ego car whosereservation overlaps with the actors reservation. We assume cc to hold in the initial state of ourcontroller. Next the lane change controller can claim some space on either the lane to its left orright, provided such a lane exists. Here N is the lane identifier of the highest lane from the setof all lanes L .In order to transform a claim into a reservation and thus finally change lanes, a car firstneeds to check if there are overlaps of other cars’ claims or reservations with its own claim. Thisis formalised by the potential collision check pc ( c ) ≡ c (cid:54) = ego ∧ (cid:104) cl ( ego ) ∧ ( re ( c ) ∨ cl ( c )) (cid:105) . (6)Formula (6) evaluates to true, iff there exists a car different from the ego car whose claimor reservation overlaps with ego car’s own claim. A (temporary) potential collision is allowed,because it does not endanger the safety property (4). However, if a potential collision is detected,the car must withdraw its claim immediately.When ∃ c : pc ( c ) does not hold, the actor reserves the claimed lane and starts changing lanes.To prevent deadlocks, we set a time bound t in state q for the time that may pass betweenclaiming and reserving crossing segments. After t lc time, the lane change is finished and thereservation of actor E is reduced to the new lane. q : cc q q : ¬∃ c : pc ( c ) ∧ x ≤ tq : x ≤ t lc n + ≤ N / c ( ego , n + ) ; l : = n + ≤ n − / c ( ego , n − ) ; l : = n − ∃ c : pc ( c ) wd c ( ego ) ¬∃ c : pc ( c ) / x : = ∃ c : pc ( c ) / wd c ( ego ) ¬∃ c : pc ( c ) / r ( ego ) ; x : = x ≥ t lc / wd r ( ego ) ; n : = l Figure 2: Lane change controller from [13].
We first introduce the specific abstract model we examine with UPPAAL and the consideredassumptions and restrictions for it in Sect. 3.1. We explain the adaptions of the lane changecontroller from Sect. 2.4 to the type of extended timed automata UPPAAL accepts in Sect. 3.2.We explain our verification method and show safety of the existing controller in Sect. 3.3. Wedetect liveness issues for the lane change controller from Sect. 2.4 and adapt it to a live controllerin Sect. 3.4. We provide a summary of the goals and limitations of the current implementationand give an overview over scenario and UPPAAL model extensions in Sect. 3.5. . Schwammberger The model we examine with UPPAAL is the traffic situation depicted in Fig. 1, where weconsider lanes to and the cars A , B and E contained in view V ( E , TS ). We encode the trafficsnapshot TS , more precisely the positions, claims and reservations of the cars on the lanes, by aglobal data structure pos t . For reservations res this is encoded as follows:p o s t r e s [ c a r i d t ] = { { { } , 1 0 , 5 } , { { } , 1 2 , 5 } , { { } , 4 0 , 5 }} ;Here e.g. the first line represents car A and the Boolean lane list { , , , } states that A has areservation only on lane . The second parameter is the position of A on lane and the lastparameter is the size of A . Thus the space A occupies is the interval [ , ] on lane . The otherlines are the respective values for cars B and E , such that B initially occupies interval [ , ] onlane and E occupies interval [ , ] on lane . We have a similar structure pos t clm [ carid t ]for the claims of the cars, where initially all Boolean lists for claims are empty, as all cars aresupposed to start in the initial state of the controller without any claim. The lane change controller is not responsible for distance keeping. However, for cars with dif-ferent acceleration and speed, a controller for distance keeping is inevitable to avoid rear-endcollisions. Such a distance controller is outlined, but not formalised or constructed in [13]. An-other possible distance controller is introduced and formally verified, but not yet implemented in[8]. Recently, the group of Kim Larsen synthesised an adaptive cruise control distance controllerwith the UPPAAL extension Stratego [15]. As the authors base their work on the spatial modelof MLSL, this approach is of high interest for our implementation. However, they only considera model consisting of one single lane without any neighbouring lanes and only two specific cars ego and f ront (cf. Fig. 3). Their idea is, that the ego car keeps track of its distance to the f ront car always . Additionally, their goal is to minimise the distance between ego and f ront . For this,one UPPAAL automaton for each ego and f ront is used, additional to a system controller. f rontego X distance vel egoacc ego vel frontacc front Figure 3: One-lane scenario with distance keeping from [15].Consider on the other hand our multi-lane scenario, e.g. in Fig. 4. It is not enough to keeptrack of the distance to f ront , as cars A , B , C and D might change lanes and thus be in frontof ego any time. Thus, we also need to keep track of the distances to these cars. A problemhere is state space explosion, as the number of considered parallel timed automata for UPPAALincreases significantly, when using the approach from [15] directly. A second problem is thediscretisation of space in their approach.4 Introducing Liveness into MLSL lane change controllers Z B D frontegoX Y A C V W
Cars of interest for ego
Figure 4: Cars of interest for ego car for distance keeping in multi-lane highway scenario [13].However, for examining the safety and liveness solely of the lane change manoeuvres withthe controller from [13], we do not need to consider a scenario with cars with different speedand acceleration. We restrict all cars to have the same constant speed whereby the relativedistances between the cars along the lanes never change. Although this is a strong restriction,it is reasonable, as our goal is to show safety and liveness of lane change manoeuvres, wherecollision freedom while changing lanes is considered, not rear-end collisions.Nonetheless, as a constant speed for all cars is a strong assumption, we plan to implement aversion of the adaptive cruise controller from [15] in future work for a more realistic model.
Despite the speed limitation, we encode a preferably general behaviour. In our model, theexpected behaviour of car E is that it is always able to change lanes and that there can never occur a potential collision or collision with E , as there is no conflicting car on any neighbouringlane. In contrast, cars A and B can not always change lanes, as their position intervals [ , ]and [ , ] would intersect if the cars had reservations or claims on the same lane. Thus, we expect potential collisions between A and B , but show that the lane change controller always prevents actual collisions . For the UPPAAL implementation, we adapt the lane change controller from Fig. 2 to UPPAALsyntax, as neither formulas of Multi-lane Spatial Logic (cf. Def. 3, p. 20) nor controller actionsfor claiming or reserving lanes (cf. Def. 5, p. 21) are directly implementable in UPPAAL. Theresulting UPPAAL lane change controller
LCP is depicted in Fig. 5. Each of the cars A , B and E in our model owns one instance LCP(i) of the controller
LCP , where i ranges over A , B and E .Note, that Fig. 5 already contains the adaptions to a live controller, we explain later in Sect. 3.4.We start with the UPPAAL representation of MLSL formulas. The only MLSL formulasused by the lane change controller are the collision check cc (cf. formula (5), p. 21) in theinitial state q and the potential collision check pc ( c ) (cf. formula (6), p. 22) used in severalguards and invariants of the controller. Our solution for implementing formulas (5) and (6)in UPPAAL bases on checking the intersection of position intervals of cars with the BooleanUPPAAL functionb o o l i n t e r s e c t ( c o n s t p o s t p1 , c o n s t p o s t p2 ) { r e t u r n e x i s t s ( l a n e : l a n e i d t )p1 . l a n e [ l a n e ] and p2 . l a n e [ l a n e ] . Schwammberger LCP in UPPAALand not ( p1 . pos > p2 . pos+p2 . s i z e o r p2 . pos > p1 . pos+p1 . s i z e ) ; } The function intersect checks for two position parameters pos_t (cf. Sect. 3.1) if their po-sition intervals intersect and if both positions are on the same lane. If e.g. car A and B bothclaim lane with clm [ A ] = {{ , , , } , , } and clm [ B ] = {{ , , , } , , } , the function call intersect ( clm [ A ] , clm [ B ]) returns true .With the intersect function, we encode the collision check cc from MLSL formula (5) by thefunctionb o o l c c ( ) { r e t u r n not e x i s t s ( c : c a r i d t ) c != egoand i n t e r s e c t ( r e s [ ego ] , r e s [ c ] ) ; } and the potential collision check pc ( c ) from MLSL formula (6) withb o o l pc ( c a r i d t c ) { r e t u r n c != egoand ( i n t e r s e c t ( clm [ ego ] , r e s [ c ] )o r i n t e r s e c t ( clm [ ego ] , clm [ c ] ) ) ; } We use the functions cc () and pc ( c ) in the UPPAAL controller LCP in Fig. 5 exactly in the samemanner as we use the respective MLSL formulas in the original lane change controller from6
Introducing Liveness into MLSL lane change controllers
Fig. 2. Besides MLSL formulas, we also encode controller actions for claiming and reservinglanes and their respective withdrawal actions with UPPAAL methods. For claiming a lane forthe ego car, the related lane change controller calls the methodv o i d c l a i m ( l a n e i d t l a n e ) { clm [ ego ] . l a n e [ l a n e ] = t r u e ; } where in the Boolean list { , , , } for claims, the value of the forwarded lane lane is set to true . Upon a reservation request from a lane change controller, we have to check if there existsa claim for the related car and only then transform the claim into a reservation. Thus,v o i d r e s e r v a t i o n ( ) { f o r ( i : l a n e i d t ) { i f ( clm [ ego ] . l a n e [ i ] ) { r e s [ ego ] . l a n e [ i ] = t r u e ;clm [ ego ] . l a n e [ i ] = f a l s e ; }}} changes the value of the respective lane in the reserved lanes for the ego car to true , whilesetting the value for the transformed claim for the same lane to false . The requirement queries for the verifier in UPPAAL are formulated in a computation tree logic(CTL) [7, 26] style specification language. The first query we successfully check is
A[] not deadlock , (7)with which we globally exclude deadlocks in an arbitrary run of our system. We checked thequery on a normal work station in to seconds with a memory usage peak of roughly KB.Figure 6:
Observer1 checking for a collision.For the second query, we introduce the Observer automaton
Observer1 , depicted in Fig. 6.This Observer automaton uses a slightly adapted version of the collision check cc() to check fora collision between any two arbitrary cars at any moment. We use the query
A[] not Observer1.unsafe (8)to show in averagely less than seconds with a memory usage peak of KB, that there existsno example trace where the formula cc does not hold. With this query, we verify the safetyproperty (4) (p. 21) for the lane change controller from [13]. . Schwammberger With query (7), we exclude deadlocks in our system. However, the original controller in Fig. 1 isnot truly live, as e.g. livelocks exist, where no car ever changes lanes, even though in our modelat least car E , should always be able to change lanes.To analyse liveness, we introduce a second Observer automaton Observer(i) , as depictedin Fig. 7. For every instance
LCP(i) of the lane change controller, we require an automaton
Observer(i) which synchronises with
LCP(i) over communication channels. E.g. on claiminga lane for car A , LCP(A) sends over the channel claiming[A] with which
Observer(A) synchro-nises, such that both controllers simultaneously change to a new state. Upon reserving a lane,
LCP(A) sends over reserving[A] and the Observer changes to a state success . We check thequery
A<> (Observer(A).success or Observer(B).success or Observer(E).success) , (9)which states, that finally in every trace , at least one of the controllers
LCP(i) is successful inchanging a lane. Remember, that we generally expect query (9) to be successfully verified, as inour model at least car C should be able to finally change a lane in every possible trace.Figure 7: Observer(i) checks for every instance of the lane change controller
LCP(i) , if when-ever car i claims a lane, it finally changes lanes, or if a potential collision occurs.
Without a time invariant in state q of the original controller from [13] and without respectivetime guards on the outgoing edges, query (9) does not hold .The reason is that there exists a trace, where cars A and B both infinitely often claim lane without any elapse of time and thus both circle between their respective states q , q and q in a livelock . As no time elapses, LCP(E) has no possibility of executing any transition andthus starves. This problem is easily solvable by introducing the invariant x < = t w to state q and placing the guard x > = t w on the outgoing edges of q , as done in the UPPAAL automatondepicted in Fig. 5. With these adaptions, we successfully show query (9) in less than . secondswith a memory usage peak of KB.8
Introducing Liveness into MLSL lane change controllers
The verification query (9) is already a weak liveness property, as it shows that in every simulationtrace, at least one of the controllers finally changes lanes. We refine this property to
A<> Observer(i).success , (10)which states for an arbitrary car identifier i , that the related car finally changes lanes. Whenconsidering only the first adaption, as anticipated, this property only holds for LCP(E) . Thereason is, that there still exists a trace, where cars A and B both unsuccessfully try to changeto lane infinitely often and thus creating a potential collision infinitely often, preventing bothcontrollers from ever transforming their claim into a reservation.To solve this, we introduce an additional state q_wait , in which the controller is forced towait for a bounded non-deterministic time. For now, we delimit this waiting time in q_wait byits invariant x ≤ and the guard x ≥ on its outgoing edge. With this, cars A and B do notpermanently block each other from changing a lane and we verify both A<> Observer(A).success and
A<> Observer(B).success (11)in each less than . seconds with a memory usage of each less than KB.
With the traffic situation from Fig. 1 and the corresponding implementation, as described inthis section, we presented one very specific scenario, designed for the following purposes: • Showing the absence of collisions between any cars (i.e. proving safety (4)) and • Identifying and analysing the existing livelocks (cf. location q ) and • Eliminating the livelocks and showing liveness of the new controller.For this, the restrictions for the scenario, e.g. on cars and lanes were reasonable. However,we also tried different scenarios, with different numbers of lanes and cars. Our liveness andsafety properties were not violated for any of the considered numbers of lanes and cars. Up to parallel lanes were considered without any problems. However, we observed the followingrun-time issues when adding cars.While run-time seemes to increase only linear by about ms each time when we add onelane, it appears to increase exponentially when adding a car. This observation is not surprising,as adding only one car i means adding two timed automata and one clock variable to thesystem: One timed automaton LCP(i) with its clock x and one observer automaton Observer(i) .Consider for example the model from Fig. 1 with one additional car. Now for property (11),UPPAAL takes seconds to verify the query instead of the previously observed . secondsfor the three car scenario. While seconds for four cars is still acceptable, after including afifth car, UPPAAL could not finish the verification of query (11) within one day.Thus, for future considerations of our implementation where more than four cars should beconsidered, we would have to optimise our implementation first. . Schwammberger We strengthened the MLSL approach from the group of Olderog [13, 12, 14], by implementingtheir lane change controller for highway traffic in UPPAAL and successfully verified their safetyproperty. We additionally optimised their controller by examining and implementing livenessproperties into it.
Related Work
There exist several approaches for analysis and control of traffic using intelligent transportationsystems, where e.g. in [18] traffic lights are used as a central control mechanism at intersections.The authors verify safety of their hybrid systems with the tool KeYmaera. There also exists anapproach to synthesise intelligent traffic light control mechanisms with the UPPAAL extensionStratego [3]. The key idea of this approach is to minimise waiting times and energy waste.Also various approaches for safe and autonomously driving systems were implemented dur-ing the DARPA Grand Challenge, where e.g. finite state machines were used to describe theautonomous behaviour of the cars [25, 28].For a hazard warning extension of MLSL, a dedicated hazard warning controller was im-plemented in UPPAAL [24]. However, the hazard warning controller was focused on a timelywarning message delivery via broadcast channels and did not use MLSL formulas. A combinedproof of UPPAAL verification queries with a formal proof by induction was used to prove thetimely warning delivery.
Future Work
In the end of Sect. 3.4, we observe that cars A and B block each other on lane and suggestan adaption ensuring the liveness of the controllers. However, this adaption does not guarantee fairness , as one of the cars could get the right of changing lanes arbitrarily more often than theother car. To overcome this problem, we could implement a notion of fairness into LCP(i) , whereeither car A or car B lets the other car go first, when they already got the right of way oftenenough. Also, we could use the UPPAAL extension for stochastical model checking (UPPAALSMC) [4], to analyse the probabilities of unfair behaviour. We could add prices to the transitionsof our controller, which increase, when a car unsuccessfully claims too often.In this paper, we only considered the lane change controller for highway traffic [13]. Animplementation of their lane change controller for country-roads [12] and the crossing controllerfor intersections [14] would be highly interesting. Also, they published results on a relaxationof their assumption of perfect knowledge , where the controllers communicate, to cope for themissing information. Also, for future considerations with more cars or different controllers, anoptimisation of our implementation is of high interest, as described in Sect. 3.5.Last but not least, for now we have the assumption of a constant speed. To verify propertiesin a more realistic scenario, our cars should be able to dynamically change their speed. To thisend, we plan to implement an adaption of the existing UPPAAL Stratego distance controllerfrom [15], as described in Sect. 3.1. Their adaptive cruise control implementation also minimisesthe distance between the ego car and the car in front, which we could use to optimise thetraffic flow in our scenario. With this, we could even extend our MLSL scenario to a platooningscenario (cf. PATH Project [19] and the European SARTRE project [5]). However, as outlinedin Sect. 3.1, the adaption of the distance controller from [15] poses some non-trivial challenges.0 Introducing Liveness into MLSL lane change controllers
Acknowledgements.
I would like to thank Marius Mikuˇcionis for his help with starting theUPPAAL implementation.
References [1] Rajeev Alur & David L. Dill (1994):
A Theory of Timed Automata . Theoretical Computer Science
A Tutorial on
Uppaal . In Marco Bernardo& Flavio Corradini, editors: , Springer, doi:10.1007/978-3-540-30080-9 7.[3] Andreas Berre Eriksen, Chao Huang, Jan Kildebogaard, Harry Lahrmann, Kim G. Larsen, MarcoMuniz & Jakob Haahr Taankvist (2017):
Uppaal Stratego for Intelligent Traffic Lights . In: .[4] Peter Bulychev, Alexandre David, Kim Guldstrand Larsen, Axel Legay, Marius Mikuˇcionis & DannyBøgsted Poulsen (2012):
Checking and Distributing Statistical Model Checking , pp. 449–463. SpringerBerlin Heidelberg, Berlin, Heidelberg, doi:10.1007/978-3-642-28891-3 39.[5] E. Chan, A. Ekfjorden, P. Jootel, J. Gidney, A. D˜A (cid:44) avila, M. Br ˜Ad’nnstr ˜A˝um, D. Skarin &L. Wahlstr ˜A˝um (2012):
SAfe Road TRains for the Environment (SARTRE): Project final report .Technical Report. Available at [6] Zhou Chaochen, C. A. R. Hoare & Anders P. Ravn (1991):
A calculus of durations . InformationProcessing Letters
Design and Synthesis of Synchronization SkeletonsUsing Branching-Time Temporal Logic . In:
Logic of Programs, Workshop , Springer-Verlag, London,UK, UK, pp. 52–71, doi:10.1007/BFb0025774. Available at http://dl.acm.org/citation.cfm?id=648063.747438 .[8] W. Damm, H. Hungar & E.-R. Olderog (2006):
Verification of Cooperating Traffic Agents . Interna-tional Journal of Control
Uppaal Stratego . In Christel Baier & Cesare Tinelli, editors:
Tools and Algorithmsfor the Construction and Analysis of Systems , Lecture Notes in Computer Science
No Need Knowing Numerous Neighbours .In Roland Meyer, Andr´e Platzer & Heike Wehrheim, editors:
Correct System Design , LNCS
Reachability and controlsynthesis for piecewise-affine hybrid systems on simplices . IEEE Trans. Automat. Contr.
Proving Safety of Traffic Manoeuvreson Country Roads . In Zhiming Liu, Jim Woodcock & Huibiao Zhu, editors:
Theories of Programmingand Formal Methods , LNCS
An Abstract Modelfor Proving Safety of Multi-lane Traffic Manoeuvres , pp. 404–419. Springer, doi:10.1007/978-3-642-24559-6 28.[14] Martin Hilscher & Maike Schwammberger (2016):
An Abstract Model for Proving Safety of Au-tonomous Urban Traffic . In Augusto Sampaio & Farn Wang, editors:
Theoretical Aspects of Com-puting (ICTAC) , LNCS . Schwammberger [15] Kim Guldstrand Larsen, Marius Mikuˇcionis & Jakob Haahr Taankvist (2015): Safe and OptimalAdaptive Cruise Control , pp. 260–277. Springer International Publishing, Cham, doi:10.1007/978-3-319-23506-6 17.[16] Sven Linker (2015):
Proofs for Traffic Safety – Combining Diagrams and Logic . Ph.D. thesis,University of Oldenburg.[17] Sven Linker (2017):
Spatial Reasoning About Motorway Traffic Safety with Isabelle/HOL . In NadiaPolikarpova & Steve Schneider, editors:
Integrated Formal Methods , Springer International Publish-ing, Cham, pp. 34–49, doi:10.1007/978-3-319-66845-1 3.[18] Sarah M. Loos & Andr´e Platzer (2011):
Safe Intersections: At the Crossing of Hybrid Systems andVerification . In Kyongsu Yi, editor:
Intelligent Transportation Systems (ITSC) , pp. 1181–1186,doi:10.1109/ITSC.2011.6083138.[19] J. Lygeros, D.N. Godbole & S.S. Sastry (1998):
Verified hybrid controllers for automated vehicles . IEEE Transactions on Automatic Control
Discrete Supervisory Control of Hybrid Sys-tems Based on l-Complete Approximations . Discrete Event Dynamic Systems
A Temporal Logic for Multilevel Reasoning About Hardware . Computer
Isabelle/HOL: A Proof Assistant for Higher-OrderLogic . Lecture Notes in Computer Science, Springer Berlin Heidelberg. Available at https://books.google.de/books?id=xwdqCQAAQBAJ .[23] Heinrich Ody (2015):
Undecidability Results for Multi-Lane Spatial Logic . In Martin Leucker,Camilo Rueda & Frank D. Valencia, editors:
Theoretical Aspects of Computing - ICTAC , LNCS http://theoretica.informatik.uni-oldenburg.de/~sefie/files/mlsl-undec-ictac15.pdf .[24] Ernst R¨udiger Olderog & Maike Schwammberger (2017):
Formalising a Hazard Warning Com-munication Protocol with Timed Automata . In Luca Aceto, Giorgio Bacci, Giovanni Bacci, AnnaIng ˜A¸slfsd ˜A¸sttir, Axel Legay & Radu Mardare, editors:
Models, Algorithms, Logics and Tools , LNCS
Systems for Safety and Autonomous Behavior inCars: The DARPA Grand Challenge Experience . Proceedings of the IEEE
Specification and verification of concurrent systems in CESAR , pp.337–351. Springer, doi:10.1007/3-540-11494-7 22.[27] Maike Schwammberger (2017):
Imperfect Knowledge in Autonomous Urban Traffic Manoeuvres .In:
Proceedings First Workshop on Formal Verification of Autonomous Vehicles, FVAV@iFM 2017,Turin, Italy, 19th September 2017. , pp. 59–74, doi:10.4204/EPTCS.257.7.[28] M. Werling, T. Gindele, D. Jagszent & L. Groll (2008):
A robust algorithm for handling mov-ing traffic in urban scenarios . In:2008 IEEE Intelligent Vehicles Symposium