![Scenario 1. Top: collision due to under-constrained environment vehicle. Bottom: collision due to incorrect transitions. State Variable Description Controller Error Corrected Controller Robustly SAFE sx env Environment X-position m [10,10] [10,10] [9,11] ˙ venv ∈ F () Environment Velocity Noise [0, 0] [-0.5,0.5] [-0.5,0.5] ˙ sx env ∈ F () Environment X-Position Noise [0, 0] [0,0] [-0.5,0.5] Runtime (s) 2.6 GHz Intel Core i7, 16 GB RAM 83.622 41.985 542.344 Result δ = 0.1 δ-UNSAFE SAFE SAFE](https://www.researchgate.net/profile/Houssam-Abbas/publication/316643507/figure/fig3/AS:667699701100546@1536203422128/Scenario-1-Top-collision-due-to-under-constrained-environment-vehicle-Bottom_Q320.jpg)
Content uploaded by Houssam Abbas
Author content
All content in this area was uploaded by Houssam Abbas on Oct 18, 2017
Content may be subject to copyright.
University of Pennsylvania
ScholarlyCommons
!*&0#.1*&2)1'*))*)"=78*17&'1 "(-3303+2,.2**6.2,&2)440.*)"(.*2(*
Computer-Aided Design for Safe Autonomous
Vehicles
Ma"hew O'Kelly
13/*00=7*&794*22*)9
Houssam Abbas
University of Pennsylvania-&''&77*&794*22*)9
Rahul Mangharam
University of Pennsylvania6&-9017*&794*22*)9
3003;8-.7&2)&)).8.32&0;36/7&8 -D46*437.836=94*22*)910&'%4&4*67
&683+8-* 31498*62,.2**6.2,311327&2)8-* 0*(86.(&0&2)31498*62,.2**6.2,
311327
B.74&4*6.74378*)&8"(-30&60=311327 -D46*437.836=94*22*)910&'%4&4*67
36136*.2+361&8.3240*&7*(328&(8 6*437.836=43'3<94*22*)9
!*(311*2)*).8&8.32
&D-*;*00=3977&1''&7&2)!&-90&2,-&6&131498*6.)*)*7.,2+36"&+*983231397$*-.(0*7&=
Computer-Aided Design for Safe Autonomous Vehicles
Abstract
B.74&4*6)*8&.078-*)*7.,23+&2&983231397:*-.(0*8330(-&.2;-.(-(&4896*7+361&0)*7(6.48.3273+
)6.:.2,7(*2&6.37.236)*683)*:*034&7&+*8=(&7*+36&2&983231397:*-.(0*$!&8-*68-&2+3(9732&
4&68.(90&6(31432*283+8-*$0./*&)&48.:*(69.7*(3286308-*8330(-&.213)*078-**2)83*2))=2&1.(73+
8-*$.2&+361&0;&=79.8&'0*+368*78.2,&2):*6.C(&8.32.678&)31&.274*(.C(0&2,9&,*(&4&'0*3+
)*7(6.'.2,8-*7(*2&6.378-&83((96.28-*)&=83)&=34*6&8.323+&2$.7)*C2*)B*0&2,9&,*&003;78-*
)*7(6.48.32&2)(31437.8.323+86&A(4&68.(.4&287&2)8-*74*(.C(&8.323++361&0(366*(82*776*59.6*1*287
7(*2&6.3)*7(6.'*).28-.70&2,9&,*.7&2*<*(98&'0*8-&8(&2'*463(*77*)'=&74*(.C(&8.32,9.)*)
&9831&8*)8*78,*2*6&836'9,-928.2,&2)'=&2*<-&978.:*6*&(-&'.0.8=8330B*8330(-&.2&003;78-*97*6
83*<403.8&2).28*,6&8*8-*786*2,8-73+'38-8*78.2,&2)6*&(-&'.0.8=.2&;&=2384377.'0*;-*2*&(-.7692
&032*.2&00=,.:*2&4&68.(90&6*<*(98.323+8-*7(*2&6.38-&8:.30&8*78-*6*59.6*1*287&:.79&0.>&8.328330
(&2).740&=8-.7(3928*6*<&140*&2),*2*6&8*0&'*0*)7*2736)&8&B**@*(8.:*2*773+8-*&4463&(-.7
)*132786&8*)32C:*&983231397)6.:.2,7(*2&6.37)6&;2+631&(300*(8.323+7(*2&6.378-&8&((3928+36
3:*63+&((.)*2872&8.32;.)*B*7*(&7*789).*7)*132786&8*63'9782*77,9.)*):*6.C(&8.32-*96.78.(783
6*)9(*&2&0=7.78.1*(3928*6*<&140*:.79&0.>&8.32+36.)*28.+=.2,(3286300*6'9,7.2'38-8-*).7(6*8*
)*(.7.3203,.(&2)03;0*:*0&2&03,(328.29397)=2&1.(7&2).)*28.C(&8.323+13)*0.2,*663678-&80*&)83
926*&0.78.(*2:.6321*28'*-&:.36
Disciplines
31498*62,.2**6.2,?0*(86.(&0&2)31498*62,.2**6.2,
B.78*(-2.(&06*4368.7&:&.0&'0*&8"(-30&60=311327 -D46*437.836=94*22*)910&'%4&4*67
Computer-Aided Design for Safe Autonomous Vehicles
Matthew O’Kelly, Houssam Abbas, Rahul Mangharam
Department of Electrical and Systems Engineering
University of Pennsylvania
Philadelphia, PA
Email:[mokelly, habbas, rahulm]@seas.upenn.edu
Abstract—This paper details the design of an autonomous
vehicle CAD toolchain, which captures formal descriptions
of driving scenarios in order to develop a safety case for an
autonomous vehicle (AV). Rather than focus on a particular
component of the AV, like adaptive cruise control, the toolchain
models the end-to-end dynamics of the AV in a formal way
suitable for testing and verification. First, a domain-specific
language capable of describing the scenarios that occur in
the day-to-day operation of an AV is defined. The language
allows the description and composition of traffic participants,
and the specification of formal correctness requirements. A
scenario described in this language is an executable that can be
processed by a specification-guided automated test generator
(bug hunting), and by an exhaustive reachability tool. The
toolchain allows the user to exploit and integrate the strengths
of both testing and reachability, in a way not possible when
each is run alone. Finally, given a particular execution of the
scenario that violates the requirements, a visualization tool
can display this counter-example and generate labeled sensor
data. The effectiveness of the approach is demonstrated on five
autonomous driving scenarios drawn from a collection of 36
scenarios that account for over 95% of accidents nationwide.
These case studies demonstrate robustness-guided verification
heuristics to reduce analysis time, counterexample visualization
for identifying controller bugs in both the discrete decision
logic and low-level analog (continuous) dynamics, and identifi-
cation of modeling errors that lead to unrealistic environment
behavior.
1. Introduction
What type of evidence should we require before giving
a driver’s license to an autonomous vehicle? To answer this
question, consider the major components which make up
an AV. An AV is typically equipped with multiple sensors,
like a LIDAR (a laser range finder) and several cameras.
The readings of these sensors are processed by algorithms
that extract the content of the current scene (who’s doing
what where). This information is then fused together to
provide the AV with its state estimate (position, velocity,
etc) and that of the other agents in the scene. The AV
must then decide where to go next (a decision taken by the
behavioral planner component of the control stack), what
trajectory to follow to get there (a computation performed
by the trajectory planner) and how to actuate steering and
acceleration to follow that trajectory (performed by the
trajectory tracker). Add to this the interaction with other
vehicles and the respect of traffic laws, and it is clear that
verifying correctness of AV control is a gargantuan task.
The Electronic Design Automation (EDA) industry has
a long history of successfully managing the complexity
of semiconductor development by providing tools that en-
able easy design entry, modular design, abstraction, formal
equivalency checking between abstractions, automated test
generation, formal verification, and the re-use of tests and
other artifacts across abstractions. Most of these techniques
are applicable to the development of AVs, by utilizing an
integrated approach which deploys the appropriate tools as
a coherent and traceable whole.
The novelty of the AV domain is that AVs need to
operate in a variety of scenarios (e.g., highway driving vs.
parking), and will execute different controllers depending
on the scenario, Thus, the AV must be verified in represen-
tative scenarios.Since each scenario can have an infinite
variety of instantiations (highways with different curvatures,
intersections with different traffic signage), it is important
to obtain good coverage of a given scenario. The space
to be covered includes road varieties and the set of initial
states of all agents involved (AVs and human drivers).
Safety-criticality implies that coverage must be rigorously
measured or bounded, rather than let it be set by an arbitrary
timeout on the duration of verification. Thus a formal de-
scription of scenarios is needed, suitable for processing by
formal testing and reachability tools. The supported testing
and reachability tools must be able to handle the cyber-
physical nature of AVs, as they combine vehicle dynamics,
constraints imposed by road geometry, traffic laws, discrete
supervisory logic, and uncertainty regarding the environ-
ment.
Contributions. The toolchain proposed in this paper,
AVCAD, addresses this need. It provides a scenario de-
scription language (SDL) to create driving scenarios with
different numbers of agents and on different road topologies
(Figure 1 Panel 1). It also enables the specification of formal
correctness requiements in Metric Temporal Logic [13], a
rich specification language similar to SystemVerilog As-
sertions. The toolchain comes pre-loaded with five driving
scenarios, drawn from the 2007 NHTSA accident analy-
sis [18]. The executable scenarios (Figure 1 Panel 2) are
automatically passed to two verification tools: S-TALIRO
and dReach. S- TALIROis a specification-guided automatic
test generation tool for cyber-physical systems. It can find
many different ways in which the AV might violate the
specification, thus promoting good coverage of the test
space. It is also possible to obtain upper bounds on the
probability of missing a counter-example (i.e., a requirement
violation). dReach is a formal verification tool that can
exhausively determine whether a hybrid dynamical system
violates its specification (Figure 1 Panel 4). However, it can
only handle smaller-scale scenarios than S-TaLiRo. Thus
the two tools are complementary since they handle systems
of different sizes and provide different guarantees. AVCAD
Lane Follow
Track Trajectory
Lane Change
Update Trajectory
Headway Control
Too c los e
Speed Control
Track speed limit
Scenario End
Scenario boundary
Goal Failure
Unrealizable
e(`1,`2)
e(`1,`6)
e(`1,`5)
e(`2,`1)
e(`2,`6)
e(`2,`4)
e(`1,`3)e(`3,`1)e(`2,`3)e(`2,`4)
e(`4,`2)
Figure 14: Autopilot Scenario Automaton Figure 15: Autopilot Transitions and Resets
Speed Control
Track speed limit
Headway Control
Maintain gap
Scenario End
Merge complete
Goal Failure
Unrealizable
e(`1,`2)
e(`2,`1)
e(`1,`4)
e(`1,`3)e(`2,`4)
e(`2,`3)
Figure 16: On Ramp Scenario Automaton Figure 17: On Ramp Transitions and Resets
Speed Control
Track speed limit
Headway Control
Maintain gap
Exit Type 1
Exit trajectory
Scenario End
Scenario boundary
Ramp Navigation
Track ramp
Exit Type 2
Fol low c ar
Goal Failure
Unrealizable
e(`1,`7)e(`2,`7)
e(`1,`2)
e(`2,`1)
e(`1,`3)
e(`1,`4)e(`2,`3)
e(`2,`4)
e(`4,`5)
e(`3,`5)
e(`5,`6)
Figure 18: O↵Ramp Scenario Automaton Figure 19: O↵Ramp Transitions and Resets
δ-Reachability
Verification Engine
Robust Testing Engine
Controller/Search Refinements
3
4
5
Counterexample
Counterexample Visualization
Scenario Description Language
Straight Road Autopilot On Ramp
Exit Ramp T-Junction Roundabout
Scenario Executables
21
Unsafe
Init
L1
L2
…
~x0
~xt
0
~x1
~xt
1
~x2
~xt
k1
~xk
~xt
k
Unsafe
Init
step 0 step 1 … step k
modeq0
modeq1
modeqk
flowq0(~x0,~xt
0,t
0)
flowq1(~x1,~xt
1,t
1)
flowqk(~xk,~xt
k,t
k)
jumpq0!q1(~xt
0,~x1)
jumpq1!q2(~xt
1,~x2)
jumpqk1!qk(~xt
k1,~xk)
Figure 1: The AVCAD toolchain: (1) Scenario Description Language (2) Scenario Executables Generation (3) Robust Testing [G. Fainekos]
(4) Verification Engine [S. Kong] (5) Scenario Visualization
also enables a mixed testing-reachability approach, in which
testing results guide the reachability analysis and reduce its
runtime. Finally, the counter-examples can be visualized in
a photorealistic environment (Figure 1 Panel 5) aiding in the
debugging process and enabling the generation of synthetic
camera-based sensor outputs.
Outline. Section 2 describes the Scenario Description
Language and presents the formal models of agents and
scenarios. Section 3 summarizes the capabilities of the veri-
fication engines and the mixed testing-reachability approach.
Section 4 presents five case studies in using AVCAD on the
pre-loaded scenarios. Section 6 discusses related work and
Section 7 concludes the paper.
Notation and terminology. The ego-vehicle is the AV
under test. For a state variable x,˙x:= dx/dt.Ris the set
of real numbers.
2. Scenario Description Language
The Scenario Description Language (SDL) allows the
user to quickly specify a driving scenario with the following
components. A scenario Sconsists of a set of agents, A, that
includes the ego-vehicle and other vehicles and the road, a
set of traffic laws L, a goal Φto be achieved by the ego-
vehicle in this scenario, exit conditions Ethat define when
a scenario is over (otherwise the verification tools might not
know when to terminate), and a set of initial states Init that
captures the initial states of all vehicle agents.
S= (A, L,Φ, Init, E)
Rather than define these formally, it is best to illustrate
them using the T-Junction scenario from the AVCAD library
depicted in Fig. 2.
Agents (A): There are 3 agents: the ego-vehicle (a1),
environment-vehicle (a2), and road agent (a3). The
ego-vehicle’s model will be detailed in Sections 2.1-2.3. It is
unrealistic to assume perfect knowledge of the environment
vehicle’s intentions and dynamics, the latter must be mod-
eled non-deterministically. For example, the dynamics of the
environment vehicle a2are given by ˙x=vx,˙vx∈[0,1] m
s2.
So at every moment, a2can change acceleration arbitrarily.
In general, roads are described as finitely-parameterized
curves: e.g., straight lines (with parameter length), arcs (pa-
rameters length, radius), cubic splines (parameters length
and curvatures), etc. These basic curves can be linked
together using a connectivity graph. Because the elements
STOP
ɸ: Mobility Goal
ℇ: Scenario
End
!: Laws
a1: Ego-Vehicle
t >tf
a2: Environment Vehicle
Init
a3: Road
Gap Sensor
Figure 2: The T-Junction Scenario.
are parameterized they can be initialized within a set. Thus
when the scenario is verified, the results are applicable to all
modeled behaviors of the environment vehicles and roads,
not just one arbitrarily fixed behavior or road.
Law Set (L): The laws are fixed in a given scenario and
expressed in Metric Temporal Logic (MTL) [13]. In Fig. 2,
one law imposes a speed limit of 50 over for the duration
Tof the scenario: l=Always[0,T ](v < 50).
Goal (Φ): The goal Φof the ego vehicle is always of the
form “Ego must reach some region within Ntime units”.
In Fig. 2, the goal region is the green rectangle, expressing
that the vehicle must exit the highway.
Initialization (Init): An AV estimates its state x0to within
some bounded error (because of measurement imprecision),
and so it only knows that x0is in some set Inita. Thus,
it is necessary at verification time to verify that whatever
actual value x0has in Inita, the scenario will not lead to a
collision or to a requirement violation. The set Init is the
product of all vehicles’ initial sets: Init = Πa∈AI nita. The
initial sets of the 2 cars are shown in light grey in Fig. 2.
Exit Condition (E): Finally, the scenario ends either when
the ego vehicle leaves the region defined by the T-Junction
(the green region in Fig. 2) and proceeds to the next navi-
gation task, or a timeout occurs (the red region in Fig. 2).
The SDL enables the user to describe these elements
of a scenario in a consistent and structured manner, and
handles many low-level details like maintaining a global
clock, monitoring for important events like scenario end,
type and dimensionality checking, and sharing of variables
to model one AV perceiving another (e.g., the gap sensor
of Fig. 2). The SDL also relieves the user from initially
having to create an AV model by providing one by default,
described next.
2.1. AV Control and Planning
When the user creates an ego-vehicle agent, the latter
is modeled as having the hierarchical control stack [9], [29]
shown in Fig. 3 (bottom). It consists of a discrete behavioral
planner, a trajectory planner, and a trajectory tracker. This
architecture is common, but others have also been proposed.
All testing and reachability results apply to this model,
briefly described here, with more details in the appendix
and [20].
Behavioral Planner (BP): takes the information about the
environment and the next destination point (the goal) as
an input and outputs the next waypoint which should be
reached by the AV. This planner contains the intelligence
and decision logic needed, for example, to decide when to
change lanes or come to a stop. AVCAD implements a stan-
dard 2-mode adaptive cruise controller shown in Fig. 3 [25].
The appendix provides more details. The BP is responsible
for the discrete dynamics of the AV. The next planning and
control layers are responsible for the continuous dynamics.
Trajectory Planner (TP): given the environment informa-
tion, the current state xinit of the AV and a goal state xgoal
(which includes the next waypoint produced by the BP),
the trajectory planner computes constant-velocity reference
trajectories t7→ κ(t)to be followed by the vehicle to
get from xinit to xgoal. Here, κ(t)is the curvature of the
reference at time t. See Section 2.3 for how AVCAD solves
the problem of modeling this optimization-based planner.
Trajectory Tracker (TT): This computes acceleration and
steering rate to make the vehicle follow the reference tra-
jectory computed by the trajectory planner. The continuous
dynamics of the ego-vehicle are described by a kinematic bi-
cycle model where the components of ˙xare: ˙sx=vcos(θ),
˙sy=vsin(θ),˙v=a,˙
θ=v
lsin(δ), and ˙
δ=vref , where
(sx, sy)is the position, θis orientation, vis the longitudinal
velocity, δis the steering angle, and aand vref are the
control inputs (acceleration and reference velocity respec-
tively). The AVCAD agents are extensible to incorporate
many, but not all design choices. For example, a user may
extend an AVCAD agent by modifying properties such as
the mass, incorporating alternate PID controllers, changing
the set of discrete behavioral modes, or even changing the
cost function of the trajectory planner.
2.2. Formal model of AV
To perform rigorous reachability analysis on the sce-
nario, AVCAD uses a formal internal representation of the
AV and the agents in the scenario, i.e. a representation
with unambiguous mathematical semantics. While several
AV simulators exist with much richer models than presented
above, the fact that they lack this internal formal representa-
tion means that it is not possible to run any formal tools on
them. Agents in AVCAD have both discrete switching dy-
namics in the Behavioral Planner and continuous dynamics
in the Trajectory Planner and Tracker. Thus the appropriate
formal model is the hybrid automaton.
Scenario
A
: Parallel composition of agent objects
L
: Traffic Laws
: Goal to be achieved
Init
: Initialization
E
: End conditions
Scenario [Off Ramp]
A
Agent [Hybrid Automaton]
X
Xinit
L
E
⇧
Agent [Road]
Agent [Environment Vehicle]
Agent [Ego Vehicle]
L
Init
E
Trajectory Tracker
Motion Planner
Behavioral Planner
: Continuous States
: Set of Initial States
: Discrete Modes
: Transitions
: Output Function
: Ego-Vehicle, Environment, Road
: Speed Limit, Maintain Spacing
: Exit Highway
: Agent Poses, Ramp Length, etc.
: Goal Region and Timeout
Pseudocode [Ego Vehicle]
Figure 3: Scenario structure. A white arrow indicates class in-
heritance. The Off-ramp scenario automaton is the product of all
vehicle agents’ automata. The AV automaton in this scenario uses
2 modes (see Fig. 8 for its explanation).
DEFI NI TI ON 2.1 (HY BRID AU TOMATON ).
Ahybrid automaton (HA) is a tuple Σ =
(X, I nitΣ, L, f, E, I nv, Γ, Re, Π)
•X⊆Rnis the continuous state space of the system
and InitΣ⊆Rnis its set of initial states (modeling
state estimation errors).
•L⊂Nis a finite set of control modes that the system
switches through (e.g., Headway Control and Speed
Control in Fig. 3).
•In each mode `∈Lthe continuous state vector
obeys ˙x=f(`, x). It can stay in this mode as long
as xis the invariant set of that mode, Inv(`)⊂Rn.
If xexits the invariant, it must either switch to a
different mode or the simulation stops.
•E⊆L×Lis the set of mode transitions (a.k.a.
switches). The system will switch from mode `to `0
when xis in the guard set Γ(`, `0)⊂X. (The guards
are assumed disjoint). Upon a transition, the state
is reset instantaneously to x+∈Inv(`0)given by:
x+=Re((`, `0), x), where Re :E×X→X.
•Π : Rn→Rpis an output function. Other AVs can
measure Π(x(t)), but don’t have direct access to
x(t).
In Fig. 3, a high-level view of the SDL’s class hierarchy
depicts an AVCAD scenario as the product of each agent’s
hybrid automaton.
2.3. Approximation of Trajectory Planner
AVCAD strikes a balance between accurate modeling of
AV operation and verifiability of the models. Specifically,
in the case of the Trajector Planner, AVCAD introduces an
approximation of the TP’s outputs to maintain the ability to
perform reachability analysis, as detailed below.
Let xgoal ∈Rnbe the goal state to be reached by
the AV. In the Trajectory Planner, the reference trajectories
connecting current state to xgoal are found by minimizing
the following cost over all spline trajectories κ: [0, T ]→R
that are finitely-parametrized, where κ(t)is the curvature of
the reference at time t[16].
min
κZtf
t0
φ(x(t), κ(t), t)dt +||xgoal −x(tf)||2
st. ˙x=f(x(t), κ(t)) (1)
Here φpenalizes large curvatures This optimization cannot
be represented within the hybrid automaton formalism (Sec-
tion 2.2). Moreover, it can’t be handled by the reachability
tool (dReach) used in AVCAD. Therefore, AVCAD does
the following: recall that xinit is the current state of the
AV and xgoal is the goal state. Offline, a region in front
of the AV is sampled, yielding a set of Mpossible goals
{xgoal,i}M
i=1, expressed in relative coordinates. Then for
each goal xgoal,i the reference trajectory connecting them
is computed by solving Eq. (1). Denote the computed ref-
erence trajectory by κi. Thus we now have a training set
{(xgoal,i, κi)}M
i=1. A neural network N NT P is used to fit the
function xgoal,i 7→ κi.Online, given an actual target state
xgin relative coordinates, the AV computes N NT P (xg)to
obtain the parameters of the reference trajectory κgleading
to xg. The function NNT P can be used as part of the hybrid
automaton formalism. Importantly, NNT P is a composition
of linear functions and nonlinearities, and represented in
the hybrid systems formalism used in AVCAD (Section 3).
Further details are provided in [22].
3. Verification Engines
AVCAD enables two methods of system verification:
testing and exhaustive reachability analysis. Because an AV
combines continuous dynamics (i.e., differential equations)
with discrete decision logic (e.g., the behavioral planner),
the testing and exhaustive verification engines must be able
to handle this added complexity, which is well beyond the
complexity of purely digital designs.
Consider a system model Hlike the one presented
above. Hcaptures the dynamics of the AV and all other
agents present in the scenario. His required to sat-
isfy a specification ϕwritten in Metric Temporal Logic
(MTL) [13]. MTL is a formal language for expressing
complex reactive requirements with real-time constraints,
such as “If other car approaches the AV with velocity > v
for more than nms, accelerate within 3seconds in current
lane”. Readers familiar with SystemVerilog Assertions will
appreciate that MTL is a subset of SVA, yet is expressive
enough to describe many properties of interest for AV
scenarios. The system state x0can start anywhere in a set
X0⊂Rn. The initial set X0models the error with which
the AV estimates its state. That is, online, the AV computes
a state estimate with a bounded error, and so it only knows
that x0∈X0. Thus, it is necessary, at verification time, to
verify that whatever actual value x0has, the scenario will
not lead to a collision or to a violation requirement. The
purpose of the following two verification tools, S-TALIRO
and dReach, is precisely to answer this question: does there
exist an initial state x0∈X0s.t. the system’s behavior from
x0violates ϕ?
3.1. Specification Guided Testing
AVCAD translates the executable scenario created by the
user to a format that can be processed by S- TALIRO[4].
S-TALIROis a tool for automatic test generation for Cyber-
Physical Systems (CPS). S- TALIROuses a stochastic search
algorithm, like Simulated Annealing, to find initial condi-
tions, a state x0, such that the trajectory of Hstarting in x0
violates ϕ. The results are then returned to the designer
to debug. Note that if such a falsifying x0exists, then
S-TALIROwill find it in the long run with probability
approaching 1.
In practice, S- TALIROcan find errors quickly, as will be
shown in the experiments. Furthermore, if the system does
not violate its specification, S-TALIROcan still estimate
how close the system gets to a violation. It does so by
computing an upper bound on the minimum robustness
ρϕ(x0)of ϕover X0which approaches the true minimum
as the number of tests increases. The robustness ρϕ(x0)of ϕ
relative to x0[8] is a real number that measures two things:
its sign tells whether xsatisfies the spec (ρϕ(x)>0) or
violates it (ρϕ(x)<0). Moreover, the trajectory starting
at x0can be disturbed by any amount |ρϕ(x0)|without
changing its truth value (e.g., if it is correct, the disturbed
trajectory is also correct). The robustness of MTL speci-
fications has been used successfully for the verification of
automotive systems [6], medical devices [27], and general
CPS. The theory behind S-TALIROcan be reviewed in
numerous publications, such as [7], while the test generation
algorithm is presented in detail in [19] and [1].
3.2. Delta Reachability Analysis
AVCAD also translates the executable scenario to a for-
mat that can be processed by dReach [12], an exhaustive
δ-decidability reachability tool. Whereas the testing tool
S-TALIROmight be interrupted before having found a
violation that does exist in X0, dReach answers the verifica-
tion question exhaustively: once it terminates, its answer is
decisive. Specifically: if dReach returns that the scenario is
SAFE, then it is indeed safe. If it returns that the scneario
is δ-UNSAFE, then this means that a δ-sized perturbation
of the scenario’s trajectories can reach a slightly expanded
unsafe set. The argument then is that in practice, a system
that is this close to being unsafe should be considered as
unsafe, and its design made more robust.
3.3. Guiding Reachability by Testing
The properties of the testing and exhaustive verification
methodologies described above are complementary; thus, a
scalable CAD system for AVs should leverage their indi-
vidual strengths where applicable. AVCAD enables simple
heuristics to utilize the results of robust simulation from
S-TALIROto guide the reachability analysis of dReach.
For instance, regions of the state space that have low ro-
bustness relative to the specification ϕare good candidates
for exhaustive reachability analysis. Instead of feeding the
full initial set X0to dReach, a smaller sub-region of it,
around the initial state of a low-robustness trajectory, is
fed to dReach, potentially finding elusive counter-examples
faster. This is illustrated in Section 4.3.
STOP ɸ: Mobility Goal
ℇ: Scenario
End
!: Laws
a1: Ego-Vehicle
Gap Sensor
t >tf
a2: Environment Vehicle
Init
a3: Road
Lane Follow
Track Tra jectory
Lane Change
Update Trajectory
Scenario End
Scenario boundary
Goal Failure
Unrealizable
e(`1,`2)
e(`1,`4)
e(`1,`3)
e(`2,`1)
e(`2,`4)
Figure 9: Straight Road Scenario Automaton Figure 10: Straight Road Transitions and Resets
Drive
Proceed to stopline
Pause
Wait for gap
Goal Failure
Unrealizable
Turn Prefix
Execute turn
Turn Predicate
Complete turn
Scenario End
Scenario boundary
e(`1,`2)
e(`2,`3)
e(`2,`6)
e(`3,`4)
e(`4,`5)
Figure 12: Autopilot Transitions and Resets
Lane Follow
TrackTrajectory
Lane Change
Update Trajectory
Scenario End
Scenario boundary
Goal Failure
Unrealizable
Figure 9: Straight Road Scenario Automaton Figure 10: Straight Road Transitions and Resets
Drive
Proceed to stopline
Pause
Wait for gap
Goal Failure
Unrealizable
TurnPrefix
Execute turn
TurnPredicate
Complete turn
Scenario End
Scenario boundary
(`1,`2),Re(`1,`2)
(`2,`3),Re(`2,`3)
(`2,`6),Re(`2,`6)
(`3,`4),Re(`3,`4)
(`4,`5),Re(`4,`5)
Figure 12: Autopilot Transitions and Resets
Drive
Proceed to stopline
Pause
Waitfor gap
Goal Failure
Unrealizable
TurnPrefix
Execute turn
TurnPredicate
Complete turn
Scenario End
Scenario boundary
Figure 9: T-Junction Scenario Automaton
State Transi tion
Drive (`1)
Guard (`1,`2): sxsxstop
Reset Re(`1,`2): I
stop =1,t
=0
Next State: Pause
Pause (`2)
Guard (`2,`3): (t>t
pause)(dgap >d
min)
Reset Re(`2,`3): I
drive =0,I
stop =0,t
=0
Next State: TurnPrefix
Turn Pre fix (`3)
Guard (`3,`4): sy<s
fy1
Reset Re(`3,`4): s
x0=sx,s
y0=sy,s
ego =0
s
xgoal =wpx1,s
ygoal =wpy1
I
pre =0,I
pred =1
Next State: TurnPredicate
Turn Pred icate (`4)
Guard (`4,`5): sy<s
fy2
Reset Re(`4,`5): s
x0=sx,s
y0=sy,s
ego =0
s
xgoal =wpx2,s
ygoal =wpy2
I
pred =1,t
=0
Next State: Scenario Complete
Table1: T-JunctionTransitions and Resets
Lane Follow
TrackTrajectory
Lane Change
Update Trajectory
HeadwayControl
Too clo se
Speed Control
Trackspeed limit
Scenario End
Scenario boundary
Goal Failure
Unrealizable
Figure 10: Autopilot Scenario Automaton
State Transi tion
Drive (`1)
Guard (`1,`2): sxsxstop
Reset Re(`1,`2): I
stop =1,t
=0
Next State: Pause
Pause (`2)
Guard (`2,`3): (t>t
pause)(dgap >d
min)
Reset Re(`2,`3): I
drive =0,I
stop =0,t
=0
Next State: TurnPrefix
Turn Pre fix (`3)
Guard (`3,`4): sy<s
fy1
Reset Re(`3,`4): s
x0=sx,s
y0=sy,s
ego =0
s
xgoal =wpx1,s
ygoal =wpy1
I
pre =0,I
pred =1
Next State: TurnPredicate
Turn Pred icate (`4)
Guard (`4,`5): sy<s
fy2
Reset Re(`4,`5): s
x0=sx,s
y0=sy,s
ego =0
s
xgoal =wpx2,s
ygoal =wpy2
I
pred =1,t
=0
Next State: Scenario Complete
Table2: AutopilotTransitions and Resets
Speed Control
Trackspeed limit
HeadwayControl
Maintaingap
Scenario End
Merge complete
Goal Failure
Unrealizable
Figure 11: On Ramp Scenario Automaton
State Transi tion
Drive (`1)
Guard (`1,`2): sxsxstop
Reset Re(`1,`2): I
stop =1,t
=0
Next State: Pause
Pause (`2)
Guard (`2,`3): (t>t
pause)(dgap >d
min)
Reset Re(`2,`3): I
drive =0,I
stop =0,t
=0
Next State: TurnPrefix
Turn Pre fix (`3)
Guard (`3,`4): sy<s
fy1
Reset Re(`3,`4): s
x0=sx,s
y0=sy,s
ego =0
s
xgoal =wpx1,s
ygoal =wpy1
I
pre =0,I
pred =1
Next State: TurnPredicate
Turn Pred icate (`4)
Guard (`4,`5): sy<s
fy2
Reset Re(`4,`5): s
x0=sx,s
y0=sy,s
ego =0
s
xgoal =wpx2,s
ygoal =wpy2
I
pred =1,t
=0
Next State: Scenario Complete
Table3: OnRamp Transitions and Resets
1
State Transition Transition
Drive (1)
Guard(1,2):sxsxstop
ResetRe(1,2):I
stop=1,t
=0
Next State: Pause
Guard: NA
Reset: NA
Next State: NA
Pause (2)
Guard(2,3):(t>t
pause)(dgap>d
min)
ResetRe(2,3):I
drive =0,I
stop=0,t
=0
Next State: Turn Pr efix
Guard:(2,6)(t>t
f)(=2)
Reset: NA
Next State: Goal Failure
TurnPrefix (3)
Guard(3,4):sy<s
fy1
ResetRe(3,4):s
x0=sx,s
y0=sy,s
ego =0
s
xgoal=wpx1,s
ygoal=wpy1
I
pre =0,I
pred =1
Next State: TurnPredicate
Guard: NA
Reset: NA
Next State: NA
TurnPredicate (4)
Guard(4,5):sy<s
fy2
ResetRe(4,5):s
x0=sx,s
y0=sy,s
ego =0
s
xgoal=wpx2,s
ygoal=wpy2
I
pred =1,t
=0
Next State: Scenario Complete
Guard: NA
Reset: NA
Next State: NA
State Transition Transition Transition Transition
SpeedControl(1)
Guard(1,2):
ResetRe(1,2):
Next State:
LaneChange
Guard(1,3):
ResetRe(1,3):
Next State:
GoalFailure
Guard(1,3):
ResetRe(1,3):
Next State:
GoalFailure
Guard(1,4):
ResetRe(1,4):
Next State:
ScenarioEnd
HeadwayControl (2)
Guard(2,1):
ResetRe(2,1):
Next State:
LaneFollow
Guard(2,4):
ResetRe(2,4):
Next State:
ScenarioEnd
Guard(2,4):
ResetRe(2,4):
Next State:
ScenarioEnd
Guard: NA
Reset: NA
Next State: NA
Exit Type1 (2)
Guard(2,1):
ResetRe(2,1):
Next State:
LaneFollow
Guard(2,4):
ResetRe(2,4):
Next State:
ScenarioEnd
Guard(2,4):
ResetRe(2,4):
Next State:
ScenarioEnd
Guard: NA
Reset: NA
Next State: NA
Exit Type2 (2)
Guard(2,1):
ResetRe(2,1):
Next State:
LaneFollow
Guard(2,4):
ResetRe(2,4):
Next State:
ScenarioEnd
Guard(2,4):
ResetRe(2,4):
Next State:
ScenarioEnd
Guard: NA
Reset: NA
Next State: NA
RampNavigation (2)
Guard(2,1):
ResetRe(2,1):
Next State:
LaneFollow
Guard(2,4):
ResetRe(2,4):
Next State:
ScenarioEnd
Guard(2,4):
ResetRe(2,4):
Next State:
ScenarioEnd
Guard: NA
Reset: NA
Next State: NA
Figure 13: T-Junction Transitions and Resets
1
State Transition Transition
Drive (1)
Guard (1,2):sxsxstop
Reset Re(1,2):I
stop =1,t
=0
Next State: Pause
Guard: NA
Reset: NA
Next State: NA
Pause (2)
Guard (2,3):(t>t
pause)(dgap >d
min)
Reset Re(2,3):I
drive =0,I
stop =0,t
=0
Next State: Turn P refix
Guard:(2,6)(t>t
f)(= 2)
Reset: NA
Next State: Goal Failure
Turn Prefix (3)
Guard (3,4):sy<s
fy1
Reset Re(3,4):s
x0=sx,s
y0=sy,s
ego =0
s
xgoal =wpx1,s
ygoal =wpy1
I
pre =0,I
pred =1
Next State: Turn Predicate
Guard: NA
Reset: NA
Next State: NA
Turn Predicate(4)
Guard (4,5):sy<s
fy2
Reset Re(4,5):s
x0=sx,s
y0=sy,s
ego =0
s
xgoal =wpx2,s
ygoal =wpy2
I
pred =1,t
=0
Next State: Scenario Complete
Guard: NA
Reset: NA
Next State: NA
State Transition Transition Transition Transition
SpeedControl (1)
Guard (1,2):
Reset Re(1,2):
Next State:
Lane Change
Guard (1,3):
Reset Re(1,3):
Next State:
Goal Failure
Guard (1,3):
Reset Re(1,3):
Next State:
Goal Failure
Guard (1,4):
Reset Re(1,4):
Next State:
Scenario End
Headway Control (2)
Guard (2,1):
Reset Re(2,1):
Next State:
Lane Follow
Guard (2,4):
Reset Re(2,4):
Next State:
Scenario End
Guard (2,4):
Reset Re(2,4):
Next State:
Scenario End
Guard: NA
Reset: NA
Next State: NA
Exit Type1 (2)
Guard (2,1):
Reset Re(2,1):
Next State:
Lane Follow
Guard (2,4):
Reset Re(2,4):
Next State:
Scenario End
Guard (2,4):
Reset Re(2,4):
Next State:
Scenario End
Guard: NA
Reset: NA
Next State: NA
Exit Type2 (2)
Guard (2,1):
Reset Re(2,1):
Next State:
Lane Follow
Guard (2,4):
Reset Re(2,4):
Next State:
Scenario End
Guard (2,4):
Reset Re(2,4):
Next State:
Scenario End
Guard: NA
Reset: NA
Next State: NA
Ramp Navigation (2)
Guard (2,1):
Reset Re(2,1):
Next State:
Lane Follow
Guard (2,4):
Reset Re(2,4):
Next State:
Scenario End
Guard (2,4):
Reset Re(2,4):
Next State:
Scenario End
Guard: NA
Reset: NA
Next State: NA
Figure 13: T-Junction Transitions and Resets
2
Mode Transitions
Drive (`1)
Guard (`1,`2):sxsxstop
Reset Re(`1,`2):t0=0
Next State: Pause
Guard: NA
Reset: NA
Next State: NA
Pause (`2)
Guard (`2,`3):(t>t
pause)^(dgap >d
min)
Reset Re(`2,`3):t0=0
Next State: Tur n Pre fix
Guard:(`2,`6)(t>t
f)^(`= 2)
Reset: NA
Next State: Goal Failure
Turn Prefix (`3)
Guard (`3,`4):sy<s
fy1
Reset Re(`3,`4):s0
x0=sx,s
0
y0=sy,s
0
ego =0
s0
xgoal =wpx1,s
ygoal =wpy1Next State: Turn Predicate
Guard: NA
Reset: NA
Next State: NA
Turn Predicate (`4)
Guard (`4,`5):sy<s
fy2
Reset Re(`4,`5):s0
x0=sx,s
0
y0=sy,s
0
ego =0
s0
xgoal =wpx2,s
ygoal =wpy2Next State: Scenario Complete
Guard: NA
Reset: NA
Next State: NA
Mode Transitions
Lane Fol low (`1)
Guard (`1,`2):
(R1<4.2) ^(R210)
Reset Re(`1,`2):
NA
Next State:
Lane Change
Guard (`1,`3):
70R1+7.4833 ˙
R1225
Reset Re(`1,`3):t0
m=0
Next State:
Speed Control
Guard (`1,`4):
70R1+7.4833 ˙
R1224
Reset Re(`1,`4):t0
m=0
Next State:
Headway Control
Guard (`1,`6):
(ttf)^(sxsxgoal)
Reset Re(`1,`6): NA
Next State:
Scenario End
Lane Change (`2)
Guard (`2,`1):
sego straj
Reset Re(`2,`1):
NA
Next State:
Lane Follow
Guard (`2,`3):
70R2+7.4833 ˙
R2225
Reset Re(`2,`3):t0
m=0
Next State:
Speed Control
Guard (`2,`4):
70R2+7.4833 ˙
R2224
Reset Re(`2,`4):t0
m=0
Next State:
Headway Control
Guard (`2,`6):
(ttf)^(sxsxgoal)
Reset Re(`2,`6): NA
Next State:
Scenario End
Speed Control (`3)
Guard (`3,`1):
(tm>0.05) ^(`prev = 1)
Reset Re(`3,`1):
NA
Next State:
Lane Follow
Guard (`3,`2):
(tm>0.05) ^(`prev = 2)
Reset Re(`3,`2):
NA
Next State:
Lane Change
Guard: NA
Reset: NA
Next State: NA
Guard: NA
Reset: NA
Next State: NA
Headway Control (`4)
Guard (`4,`1):
(tm>0.05) ^(`prev =1)
Reset Re(`4,`1):
NA
Next State:
Lane Follow
Guard (`4,`2):
(tm>0.05) ^(`prev = 2)
Reset Re(`4,`2):
NA
Next State:
Lane Change
Guard: NA
Reset: NA
Next State: NA
Guard: NA
Reset: NA
Next State: NA
All Modes (`x)
Guard (`x,`5):
Reset: NA
Next State:
Goal Failure
Guard: NA
Reset: NA
Next State: NA
Guard: NA
Reset: NA
Next State: NA
Guard: NA
Reset: NA
Next State: NA
Figure 4: T-Junction: scenario instance details, scenario automaton (middle) and corresponding guards and resets. NA: not present.
t >tf
a1: Ego-Vehicle
a2: Environment Vehicle
ɸ: Mobility Goal
Init
!: Laws
a3: Road
ℇ: Scenario End
Lane Follow
Track Tra jectory
Lane Change
Update Trajectory
Headway Control
Too c los e
Speed Control
Track speed limit
Scenario End
Scenario boundary
Goal Failure
Unrealizable
e(`1,`2)
e(`1,`6)
e(`1,`5)
e(`2,`1)
e(`2,`6)
e(`2,`4)
e(`1,`3)e(`3,`1)e(`2,`3)e(`2,`4)
e(`4,`2)
Figure 14: Autopilot Scenario Automaton Figure 15: Autopilot Transitions and Resets
Speed Control
Track speed limit
Headway Control
Maintain gap
Scenario End
Merge complete
Goal Failure
Unrealizable
e(`1,`2)
e(`2,`1)
e(`1,`4)
e(`1,`3)e(`2,`4)
e(`2,`3)
Figure 16: On Ramp Scenario Automaton Figure 17: On Ramp Transitions and Resets
Speed Control
Track speed limit
Headway Control
Maintain gap
Exit Type 1
Exit trajectory
Scenario End
Scenario boundary
Ramp Navigation
Track ramp
Exit Type 2
Foll ow car
Goal Failure
Unrealizable
e(`1,`7)e(`2,`7)
e(`1,`2)
e(`2,`1