ArticlePDF Available

Computer-Aided Design for Safe Autonomous Vehicles

Authors:

Abstract and Figures

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 identification of modeling errors that lead to unrealistic environment behavior.
Content may be subject to copyright.
University of Pennsylvania
ScholarlyCommons
!*&0#.1*&2)1'*))*)"=78*17&'1 "(-3303+2,.2**6.2,&2)440.*)"(.*2(*

Computer-Aided Design for Safe Autonomous
Vehicles
Ma"hew O'Kelly
13/*00=7*&794*22*)9
Houssam Abbas
University of Pennsylvania-&''&77*&794*22*)9
Rahul Mangharam
University of Pennsylvania6&-9017*&794*22*)9
3003;8-.7&2)&)).8.32&0;36/7&8 -D46*437.836=94*22*)910&'%4&4*67
&683+8-* 31498*62,.2**6.2,311327&2)8-* 0*(86.(&0&2)31498*62,.2**6.2,
311327
B.74&4*6.74378*)&8"(-30&60=311327 -D46*437.836=94*22*)910&'%4&4*67
36136*.2+361&8.3240*&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&131498*6.)*)*7.,2+36"&+*983231397$*-.(0*7&=
Computer-Aided Design for Safe Autonomous Vehicles
Abstract
B.74&4*6)*8&.078-*)*7.,23+&2&983231397:*-.(0*8330(-&.2;-.(-(&4896*7+361&0)*7(6.48.3273+
)6.:.2,7(*2&6.37.236)*683)*:*034&7&+*8=(&7*+36&2&983231397:*-.(0*$!&8-*68-&2+3(9732&
4&68.(90&6(31432*283+8-*$0./*&)&48.:*(69.7*(3286308-*8330(-&.213)*078-**2)83*2))=2&1.(73+
8-*$.2&+361&0;&=79.8&'0*+368*78.2,&2):*6.C(&8.32.678&)31&.274*(.C(0&2,9&,*(&4&'0*3+
)*7(6.'.2,8-*7(*2&6.378-&83((96.28-*)&=83)&=34*6&8.323+&2$.7)*C2*)B*0&2,9&,*&003;78-*
)*7(6.48.32&2)(31437.8.323+86&A(4&68.(.4&287&2)8-*74*(.C(&8.323++361&0(366*(82*776*59.6*1*287
7(*2&6.3)*7(6.'*).28-.70&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=8330B*8330(-&.2&003;78-*97*6
83*<403.8&2).28*,6&8*8-*786*2,8-73+'38-8*78.2,&2)6*&(-&'.0.8=.2&;&=2384377.'0*;-*2*&(-.7692
&032*.2&00=,.:*2&4&68.(90&6*<*(98.323+8-*7(*2&6.38-&8:.30&8*78-*6*59.6*1*287&:.79&0.>&8.328330
(&2).740&=8-.7(3928*6*<&140*&2),*2*6&8*0&'*0*)7*2736)&8&B**@*(8.:*2*773+8-*&4463&(-.7
)*132786&8*)32C:*&983231397)6.:.2,7(*2&6.37)6&;2+631&(300*(8.323+7(*2&6.378-&8&((3928+36
3:*63+&((.)*2872&8.32;.)*B*7*(&7*789).*7)*132786&8*63'9782*77,9.)*):*6.C(&8.32-*96.78.(783
6*)9(*&2&0=7.78.1*(3928*6*<&140*:.79&0.>&8.32+36.)*28.+=.2,(3286300*6'9,7.2'38-8-*).7(6*8*
)*(.7.3203,.(&2)03;0*:*0&2&03,(328.29397)=2&1.(7&2).)*28.C(&8.323+13)*0.2,*663678-&80*&)83
926*&0.78.(*2:.6321*28'*-&:.36
Disciplines
31498*62,.2**6.2,?0*(86.(&0&2)31498*62,.2**6.2,
B.78*(-2.(&06*4368.7&:&.0&'0*&8"(-30&60=311327 -D46*437.836=94*22*)910&'%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: ORamp Scenario Automaton Figure 19: ORamp 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
~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 = ΠaAI 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, Π)
XRnis the continuous state space of the system
and InitΣRnis its set of initial states (modeling
state estimation errors).
LNis 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.
EL×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×XX.
Π : RnRpis 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
X0Rn. 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 x0X0. 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 x0X0s.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)
e(`1,`3)
e(`1,`4)e(`2,`3)
e(`2,`4)
e(`4,`5)
e(`3,`5)
e(`5,`6)
Figure 18: ORamp Scenario Automaton Figure 19: ORamp Transitions and Resets
3
Mode Transitions
Speed Control (`1)
Guard (`1,`2):
70R+7.4833 ˙
R224.50
Reset Re(`1,`2): NA
Next State: Headway Control
Guard (`1,`3):
(t>t
f)^(sx<s
xgoal)
Reset Re(`1,`3): NA
Next State: Goal Failure
Guard (`1,`4):
(ttf)^(sxsxgoal)
Reset Re(`1,`4): NA
Next State: Scenario End
Headway Control (`2)
Guard (`2,`1):
70R+7.4833 ˙
R225.50
Reset Re(`2,`1): NA
Next State: Speed Control
Guard (`2,`3):
(t>t
f)^(sx<s
xgoal)
Reset Re(`2,`3): NA
Next State: Goal Failure
Guard (`2,`4):
(ttf)^(sxsxgoal)
Reset Re(`2,`4): NA
Next State: Scenario End
Figure 5: On Ramp: scenario instance details, scenario automaton (middle) and corresponding guards and resets. NA: not present.
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 Prefix
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):
(t>t
f)^(||xg||2>r)
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
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(`x,`5)
e(`2,`1)
e(`2,`6)
e(`2,`4)
e(`4,`1)
e(`1,`3)e(`3,`1)
e(`2,`3)
e(`3,`2)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)
e(`1,`3)
e(`1,`4)e(`2,`3)
e(`2,`4)
e(`4,`5)
e(`3,`5)
e(`5,`6)
Figure 18: ORamp Scenario Automaton Figure 19: ORamp Transitions and Resets
ℇ: Scenario End
ɸ: Mobility Goal
a1: Ego-Vehicle
a2: Environment Vehicle
a3: Environment Vehicle
!: Laws
a4: Road
Figure 6: Highway: scenario instance details, scenario automaton (middle) and corresponding guards and resets. NA: not present.
4. Case Studies and Performance
Consider a trip taken by an AV: it begins by navigating
a one way residential road, turning onto an arterial road at
a T-Junction (Figure 4), then negotiates an on-ramp for a
highway (Figure 5), eventually switching lanes to overtake
another vehicle (Figure 6). This section details the analysis
of the AV control and decision system for each scenario,
and shows the complementary nature of specification-guided
testing and reachability analysis. Each scenario is written in
the AVCAD SDL and analyzed using the toolchain.
4.1. Under-constrained Environment Dynamics
The first example presented utilizes the T-Junction sce-
nario. This case study illustrates the challenges of modeling
the environment vehicles without being overly restrictive
or overly permissive. Specifically, it reveals that the non-
deterministic dynamics of the environment vehicle were
under-constrained, allowing it to rear-end the ego-vehicle.
SCENARIO 1 (T-JUNCTION, FIGS. 4 & 7). The scenario
contains three agents: an ego-vehicle, an environment ve-
hicle, and a T-junction road network with a stop sign. The
ego-vehicle begins in mode Drive (`1), traveling towards
the stop sign obeying relevant traffic laws. When it reaches
the region where the roads connect it enters mode Pause
(`2) and comes to a stop. Once there is a sufficiently large
gap in the traffic the ego-vehicle begins the turn right
(mode Turn Prefix,`3). Finally, when it has reached
the main road it switches to mode Turn Predicate (`4)
and aligns itself with the centerline.
The top panel of Fig. 7 shows a collision, which can be
traced back to the dynamics of env: indeed the latter could
accelerate behind ego and rear-end it. In an accident of
this nature, the liability always falls on the trailing vehicle’s
operator. This undesirable behavior can be excised in two
ways: either env dynamics are constrained to disallow this.
Or, the scenario automaton (which is the composition of
all agents’ hybrid automata) is given a new exit condition,
which is triggered precisely when env displays such unrea-
sonable behavior. In this case new exit conditions are defined
so as not to add further discrete locations to the automaton;
thus such false positives are suppressed.
Upon applying new exit conditions another failure mode
is identified by S-TALIRO. In this case ego fails to yield
to an accelerating vehicle, an example is depicted in the
bottom panel of Fig. 7. While, dReach is also capable of
identifying this failure mode (see Table 1 column ‘Controller
Error’); S-TALIROis capable of producing many variations
of the crash. In order to correct this failure, the guard in
Pause is refined to ensure that the environment vehicle’s
speed is low enough, and there is a large enough gap that
the ego-vehicle has time to complete the maneuver. Upon
correcting this problem, dReach exhaustively verified the
scenario to be SAFE, with added uncertainty in the ego-
vehicle’s perception in 543 seconds (Table 1 column ‘Cor-
Figure 7: 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
sxenv 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]
˙sxenv 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
TABLE 1: Verification Results for the T-Junction Scenario. δ-
UNSAFE means the scenario is nearly unsafe (A δ-sized pertur-
bation in dynamics or specification leads to collisions)
rected Controller.) dReach certified the scenario as SAFE
even with added uncertainty in envs initial set and non-
determinism in its dynamics (Table 1 last column).
4.2. Adapting Controllers Between Scenarios
The second scenario investigate is a highway merge
maneuver, which adds complexity due to the nature of
on-ramp road geometry. This scenario illustrates the com-
plexities of adapting controllers that work in one scenario
to a different, seemingly similar, scenario. This motivates
the development of CAD toolchains, like AVCAD, to ease
the creation of scenarios and analyze them from multiple
perspectives. It also illustrates how fast semi-formal testing
can help flush out many bugs quickly, thus complementing
slow reachability analysis, which is used to certify it as bug-
free (or to find corner case bugs that only reachability can
find).
SCENARIO 2 (ONRAMP, FIG. 5). There are three agents:
the ego-vehicle, an environment vehicle, and a highway
on-ramp road network. The on-ramp is a cubic spline.
The shape of the on-ramp matters because the tracking
performance of the ego-vehicle controllers is altered by
sharp curvatures. The ego-vehicle uses a hybrid Adap-
tive Cruise Controller (ACC) shown in Fig. 8. It en-
ters the Speed Control (`1) mode so as to match the
speed of the highway traffic. It then transitions to the
Headway Control (`2)mode if a minimum time to col-
lision constraint is violated.
The ACC design shown in Fig. 8 has been utilized exten-
sively on real vehicles, but is designed for operating condi-
Figure 8: Hybrid Adaptive Cruise Controller. In Speed Control,
AV tries to maintain a desired speed. In Headway Control, it tries
to maintain a given separation from the leading vehicle. R is the
spacing to lead vehicle. In Region 3, the vehicle breaks to avoid
collision.
Figure 9: Robustness of On-Ramp scenario as a function of some
initial state variables (1000 runs). Color in on-line version.
tions involving highway driving tasks with straight roads.
Initial testing on the on-ramp indicates that it produces
oscillating reference velocity profiles, because it switches
frequently between Headway Control and Speed Control.
This makes it difficult for the ego-vehicle to track the
reference trajectory, particularly on short on-ramps where
road curvature is high. Robust testing in S-TALIROwas
able to quickly identify that the design was flawed within 8
seconds. In contrast, dReach also returned δ-UNSAFE, but
ran for 5+ hours. This raises the general point that when
analyzing new controller designs or complex environments,
robust testing produces interpretable results more quickly
that reachability analysis. Once the design and controller
composition issues have been addressed in simulation, then
reachability analysis can be brought in to certify the sce-
nario as error-free, or find corner case errors.
Additionally, if a safe design for the entire initial set
InitΣproves to be unrealizable, robust testing can quickly
identify potential safe sub-regions. Namely, consider Fig. 9.
It shows the robustness of system trajetories as a function
of the initial velocity of env, the goal region of ego, and
the x-coordinate of env. In Fig. 9 sample points denoted
by green spheres are safe. Fig. 9 suggests that the system
Figure 10: A search over a family of scenario instances. The top
panel shows the initial set of the ego-vehicle and a sampling of
possible trajectories computed by the TP. The bottom panel shows
how varying the curvature changes the road geometry.
Figure 11: Analysis of samples generated by robust testing de-
tails that updating the controller gains yields no counterexamples
(10,000 runs)
is robust on longer ramps (Initial ego goal between 39
and 50 meters). dReach is able to prove that this region
of the scenario (with full width intervals on all other state
variables) is safe in about 3 minutes. This approach is useful
because it can precisely answer regulatory questions such
as: under what conditions is the system safe to operate?
4.3. Controller Gain Error
The last scenario involves a highly parameterized driving
task capable of covering most modern highway designs.
This scenario demonstrates how AVCAD enables a search for
violations over road topologies and geometries in order to
identify design flaws in the continuous control of the vehicle.
This capability is important since the tracking controllers in
this domain generally make strong assumptions about the
reference trajectory properties and do not investigate the
influence of dynamic obstacles.
SCENARIO 3 (HIGH WAY, FIG. 6 ). The scenario contains
four agents: an ego-vehicle, two environment vehicles, and
a parameterized multi-lane road. The highway’s curva-
ture is a design parameter that can be varied. In mode
Lane Follow (`1) the ego-vehicle computes a trajectory
to track the current lane. The scenario automaton (which is
the product of all agents’ automata) shown in Fig. 6 includes
the hybrid controller of Fig. 8 for the AV. These aspects
of the controller are represented in Speed Control (`3)
mode so as to match the speed of the highway traffic
and Headway Control (`4)mode if a minimum time to
collision constraint is violated. Unlike the Scenario 2 these
modes are briefly visited (with a minimum dwell time to
simulate the sampling rate) and an indicator variable is set
so that the proper controller is active. In addition, mode
Lane Change (`2) allows the ego vehicle to overtake
a slower moving vehicle in the current lane of travel if
preconditions regarding the spacing in the alternate lane
are met. When the lane change maneuver is complete the
ego-vehicle switches to tracking the new lane.
Vehicle controller gains are often tuned in the field or
simulation after the structure of the controllers has been
determined; the original control engineers are not always in-
volved. Defensive code should include assertions regarding
the parameter selection, but in practice such guidelines may
be ignored, or a fast direct design procedure may not exist.
S-TALIROwas used to search for specification violations
over all possible curvatures of the highway in a pre-fixed
interval. In the case of the hybrid ACC low gains on the
headway controller combined with a straight line estimate
of the headway Rcaused the ego-vehicle to undershoot
the target acceleration and rear end one of the environment
vehicles at a road curvature of 100 (m).
The design was adjusted, increasing the proportional
gain of the headway controller and the desired headway
time, then the system retested. Over the course of 10,000
runs no counterexamples were found. Fig. 11 summarizes
the results (where the axes are: Environment Vehicle 1 Ve-
locity, Road Radius, and Environment Vehicle 2 Velocity).
Quantitatively, all sampled trajectories resulted in the ego-
vehicle maintaining at least 5.5 mof separation from the
other cars. The narrow range of the normalized robutness
indicates low variance in vehicle spacing performance.
5. Counterexample Visualization
All of the counter-examples produced in AVCAD can
be visualized as videos in the gaming engine UNITY.
This allows automotive engineers to understand better what
happened (as opposed to looking at multi-dimensional sig-
nals against time), and can, in some cases, accelerate
the debugging process. Sample videos can be seen at
(http://bit.ly/2oRHMG5).
6. Related Work
Other approaches such as theorem proving [14], [15],
[26], verification [3], [10], [28], and synthesis [5], [17], [30]
also address the safety of autonomous vehicles. The authors
of [14], [15], [26] all demonstrate the use of theorem proving
for AV safety. The drawback of the approach is that all
such techniques require human input and abstract models,
making scaling the methodology difficult. Additionally, ex-
isting work such as [15] only considers scenarios involving
straight roads and utilizes very conservative lemmas (such
as, vehicle spacing of at least 291 feet) [24]. In [2] the
authors solve the reachability problem online in order to
verify online operation of the AV. In our previous work [20]
we also consider scenario-based approaches and the use of
reachability analysis to verify AV controllers. Additonally,
in [21] we consider a specification-guided testing approach
to falsifying safety properties of AVs. In contrast this work
builds a larger library of scenarios with multiple dynamic
agents, adds realistic road geometries, introduces a flexible
scenario description language, and integrates specification-
guide testing with exhaustive reachability analysis. Finally,
other works [5], [17], [30] address the synthesis of AV
controllers from formal specifications. This orthogonal at-
tack largely addresses design at the behavior level only, and
when composed with the complete system often must still
be verified.
7. Conclusions
Because the operation of an AV involves components
from very different domains, verifying its correctness will
necessitate the deployment of tools from different disci-
plines. In this work we demonstrate how a combination
of robust testing and reachability analysis can lead to the
uncovering of bugs in both the continuous and discrete
aspects of the AV controller, as well as modelling errors
in the description of uncontrollable agents. Once the bugs
are addressed we show several cases where reachability
analysis can verify that the system meets the specification.
The key is to integrate these tools in a coherent toolchain,
in a manner similar to CAD toolchains in semiconductor
industry. AVCAD is one such toolchain, integrating a sce-
nario description language, executable scenarios, testing and
reachability tools, and rich counter-example visualization.
As current tools reveal new errors and hit their limitations,
AVCAD forms the basis for an extensible CAD toolset for
correctness verification of AVs.
References
[1] H. Abbas, G. E. Fainekos, S. Sankaranarayanan, F. Ivancic, and
A. Gupta. Probabilistic temporal logic falsification of cyber-physical
systems. ACM Transactions on Embedded Computing Systems,
12(s2), May 2013.
[2] M. Althoff and J. M. Dolan. Reachability computation of low-order
models for the safety verification of high-order road vehicle models.
In American Control Conference (ACC), 2012, pages 3559–3566.
IEEE, 2012.
[3] M. Althoff and J. M. Dolan. Online verification of automated road
vehicles using reachability analysis. IEEE Transactions on Robotics,
30(4):903–918, 2014.
[4] Y. S. R. Annapureddy and G. E. Fainekos. Ant colonies for temporal
logic falsification of hybrid systems. In Proc. of the 36th Annual
Conference of IEEE Industrial Electronics, pages 91–96, 2010.
[5] W. Damm, H.-J. Peter, J. Rakow, and B. Westphal. Can we build it:
formal synthesis of control strategies for cooperative driver assistance
systems. Mathematical Structures in Computer Science, 23(04):676–
725, 2013.
[6] T. Dreossi, T. Dang, A. Donze, J. Kapinski, X. Jin, and J. V. Desh-
mukh. A trajectory splicing approach to concretizing counterexamples
for hybrid systems. In NASA Symposium on Formal Methods, 2015.
[7] G. Fainekos and G. Pappas. Robustness of temporal logic specifi-
cations for continuous-time signals. Theoretical Computer Science,
410(42):4262–4291, September 2009.
[8] G. E. Fainekos, A. Girard, and G. J. Pappas. Temporal Logic Verifi-
cation Using Simulation, pages 171–186. Springer Berlin Heidelberg,
Berlin, Heidelberg, 2006.
[9] E. Gat. On three-layer architectures. In Artificial Intelligence and
Mobile Robots. MIT Press, 1998.
[10] D. Heß, M. Althoff, and T. Sattel. Formal verification of maneuver au-
tomata for parameterized motion primitives. In Proc. of the IEEE/RSJ
International Conference on Intelligent Robots and Systems, pages
1474–1481, 2014.
[11] Y. Kanayama, Y. Kimura, F. Miyazaki, and T. Noguchi. A stable
tracking control method for an autonomous mobile robot. In ICRA
1990. Proceedings., pages 384–389. IEEE, 1990.
[12] S. Kong, S. Gao, W. Chen, and E. M. Clarke. dreach: Delta-
reachability analysis for hybrid systems. In Tools and Algorithms
for the Construction and Analysis of Systems - 21st International
Conference, TACAS 2015, pages 200–205, 2015.
[13] R. Koymans. Specifying real-time properties with metric temporal
logic. Real-Time Systems, 2(4):255–299, 1990.
[14] S. Linker and M. Hilscher. Proof theory of a multi-lane spatial logic.
In International Colloquium on Theoretical Aspects of Computing,
pages 231–248. Springer, 2013.
[15] S. M. Loos, A. Platzer, and L. Nistor. Adaptive cruise control: Hybrid,
distributed, and now formally verified. In International Symposium
on Formal Methods, pages 42–56. Springer, 2011.
[16] M. McNaughton. Parallel Algorithms for Real-time Motion Plan-
ning. PhD thesis, Robotics Institute, Carnegie Mellon University,
Pittsburgh, PA, July 2011.
[17] A. Mehra, W.-L. Ma, F. Berg, P. Tabuada, J. W. Grizzle, and A. D.
Ames. Adaptive cruise control: Experimental validation of advanced
controllers on scale-model cars. In 2015 American Control Confer-
ence (ACC), pages 1411–1418. IEEE, 2015.
[18] W. G. Najm, J. D. Smith, and M. Yanagisawa. Pre-crash scenario
typology for crash avoidance research. In DOT HS. Citeseer, 2007.
[19] T. Nghiem, S. Sankaranarayanan, G. Fainekos, F. Ivancic, A. Gupta,
and G. Pappas. Monte-carlo techniques for falsification of temporal
properties of non-linear hybrid systems. In Hybrid Systems: Compu-
tation and Control, 2010.
[20] M. O’Kelly, H. Abbas, S. Gao, S. Shiraishi, S. Kato, and R. Mang-
haram. Apex: Autonomous vehicle plan verification and execution.
SAE World Congress, 1, Apr 2016.
[21] M. O’Kelly, H. Abbas, R. Mangharam, S. Dai, B. Kim, J. Shum,
Y. Kashiba, and S. Shiraishi. Specification-guided testing and sce-
nario visualization for adas safety analysis (under review). In ACM
ESEC/FSE’17, 2017.
[22] M. OKelly, V. Pacelli, S. Gao, J. Weimer, and R. Mangharam. Policy
approximation with radial basis function networks. Technical report,
Scholarly Commons, University of Pennsylvania, April 2017.
[23] B. Paden, M. ˇ
Cáp, S. Z. Yong, D. Yershov, and E. Frazzoli. A
survey of motion planning and control techniques for self-driving
urban vehicles. IEEE Transactions on Intelligent Vehicles, 1(1):33–
55, 2016.
[24] T. P. Pavlic, P. A. Sivilotti, A. D. Weide, and B. W. Weide. Comments
on adaptive cruise control: hybrid, distributed, and now formally
verified. OSU CSE Dept TR22, 2011.
[25] R. Rajamani. Vehicle dynamics and control. Springer Science &
Business Media, 2011.
[26] A. Rizaldi and M. Althoff. Formalising traffic rules for accountability
of autonomous vehicles. In 2015 IEEE 18th International Conference
on Intelligent Transportation Systems, pages 1658–1665. IEEE, 2015.
[27] S. Sankaranarayanan and G. Fainekos. Simulating insulin infusion
pump risks by in-silico modeling of the insulin-glucose regulatory
system. In International Conference on Computational Methods in
Systems Biology, 2012. [To Appear].
[28] O. Stursberg, A. Fehnker, Z. Han, and B. H. Krogh. Verification of
a cruise control system using counterexample-guided search. Control
Engineering Practice, 12(10):1269–1278, 2004.
[29] C. Urmson, J. Anhalt, D. Bagnell, C. Baker, R. Bittner, M. Clark,
J. Dolan, D. Duggins, T. Galatali, C. Geyer, et al. Autonomous driving
in urban environments: Boss and the urban challenge. Journal of Field
Robotics, 25(8):425–466, 2008.
[30] T. Wongpiromsarn, U. Topcu, and R. M. Murray. Receding horizon
control for temporal logic specifications. In Proceedings of the 13th
ACM international conference on Hybrid systems: computation and
control, pages 101–110. ACM, 2010.
Appendix
1. Control
In AVCAD, a reference tracker is employed to follow
paths generated by the local planner. First, we define a fixed
frame at the center of the vehicle body. The pose tracking
error is derived [11] as:
"sxe
sye
θe#="cos(θ) sin(θ) 0
sin(θ) cos(θ) 0
0 0 1#"sxr ef sx
syref sy
θref θ#(2)
Given the pose error, we define the path tracking con-
troller [23] u(t):
a
vδ=k1sxe+vref cos(θe)
δref +vref (k2sye+k3sin(θe))(3)
Then the closed-loop error dynamics are defined by the
following non-linear ODEs such that ˙
qerr is [23]:
"˙xe
˙ye
˙
θe#="(δref +vref (k2ye+k3sin(θe))) yek1xe
(δref +vref (k2ye+k3sin(θe))) xe+vref sin(θe)
δref δ#
(4)
For these error dynamics a control Lyapunov function,
V=1
2(s2
xe+s2
ye)+ 1cos(θe)
k2guarantees path stability for the
kinematic bicycle model for k1, k2, k3>0,˙
δ= 0,˙vr ef = 0
[23].
2. Local Planning
The local planner, derived from [16]. Each execution of
the local planner requires as an input the current state of the
vehicle and a goal state as defined by the behavioral planner.
The local planner’s objective is then to find a feasible path
from the initial pose to a goal pose The control input κ(s)
is assumed to be a cubic spline, such that the path can be
parameterized, and is defined as a function of arc length s:
κ(s) = a(p) + b(p)s+c(p)s2+d(p)s3(5)
Note that there are three free parameters [b, c, sf](where a
is fixed by the inital condition and sfis the total arc length
of the trajectory).
For any particular (state, goal) pair the problem is a
nonlinear program. To find feasible solutions we use an
initialization function to produce a parameter assignment.
p0=κ0=κi, p1=κ1=1
49(8b(sfsi)26κ0κ3)
(6)
p2=κ2=1
4(κ32κ0+ 5κ1), p3=κ3=κf(7)
Then, the local planner simulates the trajectory, computes
the cost, and updates the parameters via gradient descent.
Further details are provided in [22].
3. Behavioral Controller
The controller and definitions presented in this section
are derived from [25]. Define the hybrid ACC such that:
g(ν) = (a=kp(sxR)kd(v˙
R)R < Rref +˙
R2
2D
a=kpsc (vvdes)R > Rref +˙
R2
2D
(8)
... For example, manufacturers have used the technology to make dental implants (Dawood et al., 2015) or even bone tissues (Bose et al., 2013). CAD tools have also evolved with regards to visualisation features, with photo-realistic renderings becoming more commonplace, for instance to better picture violations of requirements in autonomous vehicle safety assessment (O'Kelly et al., 2017) or to simulate coating appearance depending on lightning (Jhamb et al., 2020). ...
Preprint
Full-text available
Architectural design practice has radically evolved over the course of its history, due to technological improvements that gave rise to advanced automated tools for many design tasks. Traditional paper drawings and scale models are now accompanied by 2D and 3D Computer-Aided Architectural Design (CAAD) software. While such tools improved in many ways, including performance and accuracy improvements, the modalities of user interaction have mostly remained the same, with 2D interfaces displayed on 2D screens. The maturation of Augmented Reality (AR) and Virtual Reality (VR) technology has led to some level of integration of these immersive technologies into architectural practice, but mostly limited to visualisation purposes, e.g. to show a finished project to a potential client. We posit that there is potential to employ such technologies earlier in the architectural design process and therefore explore that possibility with a focus on Algorithmic Design (AD), a CAAD paradigm that relies on (often visual) algorithms to generate geometries. The main goal of this dissertation is to demonstrate that AR and VR can be adopted for AD activities. To verify that claim, we follow an iterative prototype-based methodology to develop research prototype software tools and evaluate them. The three developed prototypes provide evidence that integrating immersive technologies into the AD toolset provides opportunities for architects to improve their workflow and to better present their creations to clients. Based on our contributions and the feedback we gathered from architectural students and other researchers that evaluated the developed prototypes, we additionally provide insights as to future perspectives in the field.
... Our work borrows ideas from robustness guided falsification for AVs [10], where the goal is to detect boundary-case failures. The goals of our approach are similar to those of [9], though their framework is not capable of simulating the AV system in a closed-loop, including the perception system. In contrast to our work, their framework utilizes a game engine only to visualize the results after the testing and analysis is done on well defined, but simpler, vehicle dynamic models like a bicycle model, which may not well represent the reality. ...
Conference Paper
Full-text available
One of the main challenges in testing autonomous driving systems is the presence of machine learning components, such as neural networks, for which formal properties are difficult to establish. We present a simulation-based testing framework that supports methods used to evaluate cyber-physical systems, such as test case generation and automatic falsification. We demonstrate how the framework can be used to evaluate closed-loop properties of autonomous driving system models that include machine learning components.
Article
Full-text available
Autonomous vehicles (AVs) have already driven millions of miles on public roads, but even the simplest scenarios have not been certified for safety. Current methodologies for the verification of AV's decision and control systems attempt to divorce the lower level, short-term trajectory planning and trajectory tracking functions from the behavioral rules-based framework that governs mid-term actions. Such analysis is typically predicated on the discretization of the state space and has several limitations. First, it requires that a conservative buffer be added around obstacles such that many feasible plans are classified as unsafe. Second, the discretized controllers modeled in this analysis require several refinement steps before being implementable on an actual AV, and typically do not allow the specification of comfort-related properties on the trajectories. In contrast, consumer-ready AVs use motion planning algorithms that generate smooth trajectories. While viable algorithms exist for the generation of smooth trajectories originating from a single state, analysis should consider that the AV faces state estimation errors and disturbances. Third, verification is restricted to a discretized state space with fixed-size cells; this assumption can artificially limit the set of available trajectories if the discretization is too coarse. Conversely, too fine of a discretization renders the problem intractable for automated analysis. This work presents a new verification tool, APEX, which investigates the combined action of a behavioral planner and state lattice-based motion planner to guarantee a safe vehicle trajectory is chosen. In APEX, decisions made at the behavioral layer can be traced through to the spatio-temporal evolution of the AV and verified. Thus, there is no need to create abstractions of the AV's controllers, and aggressive trajectories required for evasive maneuvers can be accurately investigated.
Conference Paper
Full-text available
One significant barrier in introducing autonomous driving is the liability issue of a collision; e.g. when two autonomous vehicles collide, it is unclear which vehicle should be held accountable. To solve this issue, we view traffic rules from legal texts as requirements for autonomous vehicles. If we can prove that an autonomous vehicle always satisfies these requirements during its operation, then it cannot be held responsible in a collision. We present our approach by formalising a subset of traffic rules from the Vienna Convention on Road Traffic for highway scenarios in Isabelle/HOL.
Conference Paper
Full-text available
An increasing amount of robotic systems is developed for safety-critical scenarios, such as automated cars operating in public road traffic or robots collaborating with humans in flexible manufacturing systems. For this reason, it is important to provide methods that formally verify the safety of robotic systems. This is challenging since robots operate in continuous action spaces in partially unknown environments so that there exists no finite set of scenarios that can be verified before deployment. Verifying the safety during the operation based on the current perception of the environment is often infeasible due to the computational demand of formal verification methods. In this work, we compute sets of behaviors for parameterized motion primitives using reachability analysis, which is used to build a maneuver automaton that connects motion primitives in a safe way. Thus, the computationally expensive task of building a maneuver automaton is performed offline. The proposed analysis method provides the whole set of possible behaviors so that it can be verified whether forbidden state-space regions are avoided during the operation of the robot, to e.g. avoid colliding with obstacles. The method is applied to continuous sets of parameterized motion primitives, making it possible to verify infinitely many motions within the parameter space, which to the best knowledge of the authors has not been published before. The approach is demonstrated for collision avoidance of road vehicles.
Article
Full-text available
An approach for formally verifying the safety of automated vehicles is proposed. Due to the uniqueness of each traffic situation, we verify safety online, i.e., during the operation of the vehicle. The verification is performed by predicting the set of all possible occupancies of the automated vehicle and other traffic participants on the road. In order to capture all possible future scenarios, we apply reachability analysis to consider all possible behaviors of mathematical models considering uncertain inputs (e.g., sensor noise, disturbances) and partially unknown initial states. Safety is guaranteed with respect to the modeled uncertainties and behaviors if the occupancy of the automated vehicle does not intersect that of other traffic participants for all times. The applicability of the approach is demonstrated by test drives with an automated vehicle at the Robotics Institute at Carnegie Mellon University.
Article
Full-text available
We present a Monte-Carlo optimization technique for finding system behaviors that falsify a metric temporal logic (MTL) property. Our approach performs a random walk over the space of system inputs guided by a robustness metric defined by the MTL property. Robustness is guiding the search for a falsifying behavior by exploring trajectories with smaller robustness values. The resulting testing framework can be applied to a wide class of cyber-physical systems (CPS). We show through experiments on complex system models that using our framework can help automatically falsify properties with more consistency as compared to other means, such as uniform sampling.
Conference Paper
Recent advances in automotive technology, such as, sensing and onboard computation, have resulted in the development of adaptive cruise control (ACC) algorithms that improve both comfort and safety. With a view towards developing advanced controllers for ACC, this paper presents an experimental platform for validation and demonstration of an online optimization based controller. Going beyond traditional PID based controllers for ACC that lack proof of safety, we construct a control framework that gives formal guarantees of correctness. In particular, safety constraints-maintaining a valid following distance from a lead car-are represented by control barrier functions (CBFs), and control objectives- achieving a desired speed-are encoded through control Lyapunov functions (CLFs). These different objectives can be unified through a quadtraic program (QP), with constraints dictated by CBFs and CLFs, that balances safety and the control objectives in an optimal fashion. This methodology is demonstrated on scale-model cars, for which the CBF-CLF based controller is implemented online, with the end result being the experimental validation of an advanced adaptive cruise controller.
Conference Paper
dReach is a bounded reachability analysis tool for nonlinear hybrid systems. It encodes reachability problems of hybrid systems to first-order formulas over real numbers, which are solved by delta-decision procedures in the SMT solver dReach. In this way, dReach is able to handle a wide range of highly nonlinear hybrid systems. It has scaled well on various realistic models from biomedical and robotics applications.
Article
Self-driving vehicles are a maturing technology with the potential to reshape mobility by enhancing the safety, accessibility, efficiency, and convenience of automotive transportation. Safety-critical tasks that must be executed by a self-driving vehicle include planning of motions through a dynamic environment shared with other vehicles and pedestrians, and their robust executions via feedback control. The objective of this paper is to survey the current state of the art on planning and control algorithms with particular regard to the urban setting. A selection of proposed techniques is reviewed along with a discussion of their effectiveness. The surveyed approaches differ in the vehicle mobility model used, in assumptions on the structure of the environment, and in computational requirements. The side-by-side comparison presented in this survey helps to gain insight into the strengths and limitations of the reviewed approaches and assists with system level design choices.