Runtime Verification for Hybrid Analysis Tools

Abstract

We present the first steps towards a runtime verification framework for monitoring hybrid and cyber-physical systems (CPS) development tools—such as hybrid systems reachability analysis tools, model-based development environments like Simulink/Stateflow (SLSF), etc.— based on randomized differential testing. First, hybrid automaton models are randomly generated. Next, these hybrid automaton models are translated to a number of different tools (currently, dReach, Flow*, HyCre-ate, SpaceEx, and the MathWorks' Simulink/Stateflow) using the HyST source transformation and translation tool. Then, the hybrid automaton models are executed in the different tools and their outputs are parsed. The final step is the differential comparison: the outputs of the different tools are compared; if the results do not agree (in the sense that an analysis or verification result from one tool does not match that of another tool, ignoring timeouts, etc.), a candidate bug is flagged and the model is saved for future analysis by the user. The process then repeats and the random differential testing approach for monitoring continues until the user terminates the process. We present preliminary results that have been useful in identifying several bugs in the analysis methods of the different development tools, and in an earlier version of HyST.

Full text

Runtime Verification for Hybrid Analysis Tools
Luan Viet Nguyen1, Christian Schilling2, Sergiy Bogomolov3, and Taylor T.
Johnson1
1University of Texas at Arlington, USA
2Albert-Ludwigs-Universit¨at Freiburg, Germany
3IST Austria, Austria
Abstract. We present the first steps towards a runtime verification
framework for monitoring hybrid and cyber-physical systems (CPS) de-
velopment tools—such as hybrid systems reachability analysis tools, model-
based development environments like Simulink/Stateflow (SLSF), etc.—
based on randomized differential testing. First, hybrid automaton models
are randomly generated. Next, these hybrid automaton models are trans-
lated to a number of different tools (currently, dReach, Flow*, HyCre-
ate, SpaceEx, and the MathWorks’ Simulink/Stateflow) using the HyST
source transformation and translation tool. Then, the hybrid automaton
models are executed in the different tools and their outputs are parsed.
The final step is the differential comparison: the outputs of the different
tools are compared; if the results do not agree (in the sense that an anal-
ysis or verification result from one tool does not match that of another
tool, ignoring timeouts, etc.), a candidate bug is flagged and the model
is saved for future analysis by the user. The process then repeats and the
random differential testing approach for monitoring continues until the
user terminates the process. We present preliminary results that have
been useful in identifying several bugs in the analysis methods of the
different development tools, and in an earlier version of HyST.
1 Introduction
Runtime verification is an approach to ensure the correctness and reliability of
a system during its execution. It can check and analyze executions of a system
under scrutiny that violate or satisfy a given correctness property by using a
decision procedure called a monitor. A monitor can also be considered as a
device that can read finite traces and outputs a truth value derived from a
truth domain [3]. Runtime verfication can be used broadly in many purposes
such as debugging, testing, verification, validation, fault protection, and online
system repair. In this paper, we describe preliminary work towards a randomized
differential testing framework [5] that may be used as a runtime monitor for
various components (from parsers to analysis algorithms) in hybrid and cyber-
physical systems (CPS) analysis tools such as SpaceEx, dReach, Flow*, and
Mathworks’ Simulink/Stateflow (SLSF). A test subject is the hybrid automaton
randomly generated in the input format for SpaceEx using a prototype tool called

2
Random Generation
(HyRG)
Model Translation
(HYST)
SpaceEx HyCreatedReachFlow*
Execute a Random Model on Different Tools
SLSF
Compare Analysis Results by Calling reachCheck
Sat
Report a Candidate Bug
Unsat
Other Tools
Fig. 1: Overview of monitoring framework for hybrid systems analysis tools with
randomized differential testing.
HyRG [4]4, which is then translated to other formats including dReach, Flow*,
and SLSF using the HyST model transformation tool [1]. Our contributions
include the first steps toward a randomized differential testing framework to
monitor CPS development and verification tools, and identifying several bugs in
existing tools, including a semantic difference between SpaceEx and SLSF that
we did not know about and a couple bugs in Flow* and dReach that have been
corrected by the tool authors (for more details, see [1]).
2 Monitoring with Randomized Differential Testing
We first describe how the hybrid systems are randomly generated in HyRG
so they have diverse continuous and discrete behaviors. We then analyze these
examples with different hybrid systems development and verification tools, and
then compare their outputs to identify possible bugs in the tools.
Figure 1shows the overview of our framework for randomized differential
testing to monitor hybrid systems development tools. First, a random hybrid
automaton randomly generated by HyRG will be translated to different formats
of other tools with HyST. Next, we analyze the automaton with different ver-
ification tools such as SpaceEx, Flow*, dReach, and HyCreate, and simulate it
with SLSF. Then we compare all analysis results by using a function reachCheck
shown in Figure 3. The reachCheck function has an input Reach, which is a list
4The tool and examples are available online: http://verivital.uta.edu/hyrg/

3
1fu n c ti o n randHA(m,n)
AR← ∅
3AR.Var ← { x1,...,xn}// ge n er a te s t a t e va r i a b l e s
{AR.Loc,AR.Trans} ← discreteStructure(m)// gen . lo c at i on s and t r an s it i o ns
5fo r eac h l o c at i on li n AR.Loc
l.flow ←randFlow(AR.Var)// ge n er a te fl o w s o ve r s t a t e v a r i a b l e s
7l.inv ←randInv(AR.Var)// ge n er a te an i n va r i a nt ov er st a t e v a r i a b l e s
AR.Flow ← AR.Flow ∪ {l.flow}
9AR.Inv ← AR.Inv ∪ {l.inv}
fo r eac h t r a ns i t io n ti n AR.Trans
11 t.grd ←randGrd(AR.Var)// gen . g uar d c on d i ti o n o ve r s t a t e v a r i a b l e s
t.rst ←randRst(AR.Var)// gen . up da te a c ti o n o ve r s t a t e v a r i a b l e s
13 AR.Trans.t←t// add g uard and u pd at e t o t r a n s i t i o n
AR.Init ←randInit(m,AR.Var)// ge ne ra te an i n i t i a l c on di ti on
15 return AR
Fig. 2: Pseudo-code overview of HyRG method to randomly generate hybrid
automata. The output hybrid automaton ARis generated as a tuple of random
locations, flows, invariants, transitions, guards, updates, and initial conditions.
of sets of time-bounded reachable states computed by different tools (e.g., the
output of SpaceEx, Flow*, etc.). Each set of reachable states, R(t), is the set of
states that may be visited by following the model’s trajectories and transitions,
at a given time t∈[0, β], where βis the time bound. That is, for a given time
t,R(t) is the set of states reachable at time t(sometimes referred to as a time-
slice). The input Trace is a set of all simulation traces produced by SLSF up to
a maximum simulation time β. The reachCheck function can check whether the
reachable states or simulation traces computed by different tools at each time
have non-empty intersections. If the reachable sets computed by these tools have
a non-empty intersection (pairwise over all the tools), then reachCheck will re-
turn SAT, and the monitoring continues by generating a different random model.
Otherwise, there is possibly a bug in the HyST translation, the verification tools,
or in SLSF. For the simulation traces, if some portion of a trace is not contained
in any of the reachable states, reachCheck will return UNSAT. Obviously all
these tools have numerous parameters, so numerical issues, accuracies, etc. must
be taken into account by the user to determine whether a candidate bug is real.
We define the structure of a hybrid automaton [2] and then describe a few
details of the framework
Definition 1. A hybrid automaton His a tuple, H∆
=hLoc,Var,Flow,Inv,
Trans,Initi, consisting of following components: (a) Loc: a finite set of dis-
crete locations. (b) Var: a finite set of ncontinuous, real-valued variables, where
∀x∈Var,v(x)∈ R and v(x)is a valuation—a function mapping xto a
point in its type—here, R; and Q∆
=Loc × Rnis the state space. (c) Inv:
a finite set of invariants for each discrete location, ∀l∈Loc,Inv(l)⊆ Rn.
(d) Flow: a finite set of derivatives for each continuous variable x∈Var, and
Flow(l, x)⊆ Rnthat describes the continuous dynamics in each location l∈Loc.
(e) Trans: a finite set of transitions between locations; each transition is a tuple
τ=hsrc,dst,Grd,Rsti, which can be taken from source location src to destina-
tion location dst when a guard condition Grd is satisfied, and a state is updated
by an update map Rst. (f) Init: an initial condition, Init ⊆ Q.

4
1fu n c ti o n reachCheck(Reach,Trace)
result ←SA T
3foreach se t of r e a ch a b le st a te s Riin Reach
foreach se t of r e a ch a b le st a te s Rjin Reach
5if i6=ja nd ∀t∈[0, β ]Ri(t)∧ Rj(t)is U NS A T th e n result ←UNS AT
foreach ex e c ut i o n t r ac e Rki n Trace
7if ∀t∈[0, β ]Rk(t)6⊂ Ri(t)is UN S AT t h en result ←UN S AT
return result
Fig. 3: reachCheck checks whether the set of reachable states and traces computed
by different tools overlap (have non-empty intersection) at every time instant.
We denote a hybrid automaton that has been randomly generated by AR. The
various syntactic components (Definition 1) of ARare randomly generated as
shown in Figure 2. We use the dot (.) notation to refer to different components
of tuples, e.g., AR.Loc refers to the set of locations Loc of AR.
We randomly generate each syntactic component of the automaton to gener-
ate AR. The inputs include a number of locations m, and a number of variables
n. First, we generate a set of state variables AR.Var ={x1,...,xn}(line 3). Next,
we randomly generate sets of locations AR.Loc and transitions AR.Trans based
on an arbitrary discrete structure (line 4). Rather than picking only random
matrices and vectors for the affine functions used in flows, guards, invariants,
assignments, etc., we instead partition these affine functions into interesting
classes. While we assume affine functions making up the automaton, the gen-
eral method may be extended to nonlinear functions. Next, for each location
l∈ AR.Loc (line 5), we randomly generate its flow l.flow (line 6) and invariant
l.inv (line 7) over the state variables AR.Var. Next, we iterate over each transi-
tion t∈ AR.Trans (line 10) to randomly generate a guard condition t.grd and
an update t.rst as expressions over AR.Var (lines 11 through 12). Finally, we
generate a random initial condition AR.Init for AR(line 14). We highlight that
all structural components of the automaton are selected randomly (i.e., the tran-
sitions and continuous dynamics), and are not simply parameters. For brevity,
we do not describe in detail the random generation of all structural components
here, but refer to Appendix A.
3 Preliminary Experimental Results
We evaluate our preliminary5monitoring framework in several scenarios to
compare differences among several hybrid systems verification tools including
SpaceEx, dReach, and Flow*, as well as SLSF simulation. Consider a randomly
generated ARwith the results shown in Figure 4(details and the model are
in Appendix A). The reachable states of x1and x2computed by the STC and
LGG algorithms in SpaceEx do not contain a simulation trace for an equiva-
lent SLSF model when ARtakes a transition. This happens because of semantic
differences in resets between SpaceEx and SLSF. In SLSF, the variables x1and
x2are updated in order, so that x1will be first updated to a new value, and
then x2will be updated using the new (updated) value of x1. However, these
5Some of the steps are currently manual, particularly the parsing of reachable states
and comparison thereof, but the generation with HyRG and translation with HyST
is fully automatic.

5
0 20 40 60 80 100
-5
0
5
10
15
20
Time (s)
x1
(a)
0 20 40 60 80 100
-10
0
10
20
30
40
Time (s)
x2
(b)
Fig. 4: SLSF simulation (blue), reachable states computed by SpaceEx’s LGG
algorithm (red), and reachable states computed by SpaceEx’s STC algorithm
(green) for ARshowing x1and x2versus time, respectively. The SLSF simu-
lation traces and the reachable states computed by SpaceEx’s LGG and STC
algorithms do not line up (i.e., have an empty intersection) at some time points
(so reachCheck returns unsat) due to a semantic difference.
variables are updated concurrently in SpaceEx, so x2will be updated by using
the previous value of x1. Based on this, we fixed this translation error in HyST.
4 Conclusion and Future Work
In this paper, we describe our preliminary results toward building a random-
ized differential testing framework to monitor hybrid and cyber-physical systems
(CPS) development tools like SLSF and verification tools like SpaceEx, dReach,
Flow*, etc. Our preliminary results include identifying semantic mismatches be-
tween tools automatically that have been integrated into subsequent versions of
HyST. Additionally, we have found several bugs in Flow* and dReach that have
been corrected by the tool authors. Based on our promising preliminary results,
we plan to fully automate every step of the framework in the future.
References
1. Bak, S., Bogomolov, S., Johnson, T.T.: HyST: A source transformation and trans-
lation tool for hybrid automaton models. In: Proc. of the 18th Intl. Conf. on Hybrid
Systems: Computation and Control (HSCC). ACM (2015)
2. Frehse, G., Le Guernic, C., Donz´e, A., Cotton, S., Ray, R., Lebeltel, O., Ripado, R.,
Girard, A., Dang, T., Maler, O.: SpaceEx: Scalable verification of hybrid systems.
In: Computer Aided Verification (CAV). LNCS, Springer (2011)
3. Leucker, M., Schallhart, C.: A brief account of runtime verification. Journal of Logic
and Algebraic Programming 78(5), 293–303 (May 2009)
4. Nguyen, L.V., Schilling, C., Bogomolov, S., Johnson, T.T.: Poster: Hyrg: A random
generation tool for affine hybrid automata. In: 18th International Conference on
Hybrid Systems: Computation and Control (HSCC 2015) (2015)
5. Yang, X., Chen, Y., Eide, E., Regehr, J.: Finding and understanding bugs in c com-
pilers. In: Proceedings of the 32Nd ACM SIGPLAN Conference on Programming
Language Design and Implementation. pp. 283–294. PLDI ’11, ACM, New York,
NY, USA (2011)

6
Loc1
t≤7
˙x1=−0.7949x1+ 0.2722x2
˙x2= 0.2722x1−0.1835x2
˙
t= 1
Loc2
t≤9
˙x1=−0.2936x1−0.1111x2
˙x2=−0.1111x1−0.4496x2
˙
t= 1
Loc3
t≤5
˙x1=−0.5679x1−0.1359x2
˙x2=−0.1359x1−0.9269x2
˙
t= 1
start
t≥7
t:= 0 ∧x1:= 2 ∧x2:= 8
t≥9
t:= 0 ∧x1:= x1+ 9 ∧x2:= x2+ 15
t≥10
t:= 0
x1:= 7
x2:= 4
t≥5
t:= 0
x1:= x1+ 17
x2:= x1+ 18
Fig. 5: An example of a random time-dependent switching hybrid automaton AR
randomly generated with HyRG using negative definite matrices.
A Appendix: Additional Random Generation Details
In this appendix, we describe the case study presented in the paper and addi-
tional details on the random generation methods used in HyRG, described pre-
viously in the high-level overview of Figure 2. The empirical results presented
in Section 3are for the automaton in Figure 5. The initial state of ARis Loc3,
and the randomly initial values of its variables are respectively generated as
x1= 10, x2= 17, and t= 0. ARis nondeterministic. The continuous dynamics
of each location in system AR.Loc are randomly generated based on a negative
definite matrix A, so it is exponentially asymptotically stable.
HyRG takes as inputs the options specified in Figure 2. As output, HyRG
may produce a hybrid automaton in the input XML format of the SpaceEx
toolAdditionally, HyRG is integrated with SLSF via a hybrid automaton to
SLSF translation procedure.
Time-Dependent Switching Options ATime set includes all necessary
components for randomly generating a time-dependent switched system
Definition 2. A time-dependent switching set Time is a tuple Time ∆
=hτ, β , θ, σ, φi,
where (a) τ: a time variable. (b) β: a first order linear equation over the time
variable, β←˙τ= 1. (c) θ: an invariant randomly generated as θ←aτ≤b.
(d) σ: a guard condition randomly generated as σ←cτ≤d. (e) φ: an update

7
map randomly generated as φ←τ=e. (f) ι: a initial condition generated as
ι←τ=f, where a,b,c,d,e,fare random constant numbers such that ab ≥0,
bc ≥0, and e, f ≥0.
Randomly Generating Discrete Structure. The discrete structure of a
hybrid automata is a set of locations and transition lines connected some pairs
of locations. It can be randomly generated using random adjacency matrices.If a
hybrid automata has a random mnumber of locations, so its transition graph is
an m×mrandom adjacency matrix adjMatrix , whose elements equal to either
0 or 1. If an element adjMatrix[i, j] is equal to 1, there is a transition from ith
location to jth location. Otherwise, there is no connection between these two
locations. An example of a discrete structure’s graph randomly generated by
a random adjacency matrix AGis shown in Figure 6. If any diagonal element
adjMatrix[i, i] is equal to 1, the ith location will be connected to itself. In other
words, it has a self-loop transition. Moreover, a number of transitions can also
be controlled by restricting the sum of rows and columns of adjacency matrix
less than some arbitrary constants.
The pseudo-code for generating a random discrete structure by creating an
arbitrary adjacency matrix shown in Figure 7—called from randHA (Figure 2,
line 4). We first call the function randAdjMatrix (line 2) to get a random adjacency
matrix adjMatrix. Next, we iterate over each row element iof an adjacency matrix
adjMatrix (line 3), and then create a corresponding location li(line 5). For each
row element iof adjMatrix , we iterate over each row element jof adjMatrix
(line 6), and then generate a corresponding transition ti,j(line 8) when the
value of adjMatrix[i, j] is equal to one.
The pseudo-code of randomly generating an arbitrary adjacency matrix shown
in Figure 8. A function randi([0,1],m) (line 6) generates an m×mrandom ma-
trix whose elements are equal to either 0 or 1. We use a boolean variable flag
to keep generating adjMatrix until we get our desired matrix (line 4), which pro-
vides at least one pair of ingoing and outgoing transitions for each location. We
can generate this desired matrix by putting constraints on the sum of each row
Loc1Loc2
Loc3
Loc4
AG=







1101
0010
0111
1000







Fig. 6: An example of the transition graph of the hybrid automaton model ran-
domly generated by the random adjacency matrix AG.

8
fu n c ti o n discreteStructure(m)
2adjMatrix ←randAdjMatrix(m,Opt)
foreach row element ii n adjMatrix
4// gen era te a co rr es p on di ng l o c a t ion
AR.Loc ← AR.Loc ∪ {li}
6foreach row element ji n adjMatrix
// ge ner ate a t r a nsit i o n from l oca t i o n i t o l o c a t i on j
8if adjMatrix[i, j ]=1 then AR.Trans ← AR.Trans ∪ {ti,j}
return AR.Loc, AR.Trans
Fig. 7: Randomly generated discrete structure pseudo-code. The input is a num-
ber of locations m. And, the output are random sets of locations AR.Loc and
transitions AR.Trans.
1fu n c ti o n randAdjMatrix(m,Opt)
adjMatrix ← ∅
3flag ←1
wh i le flag = 1
5flag ←0
adjMatrix ←randi([0,1],m)// Figure 6
7foreach row element ii n adjMatrix
// wi t ho ut s e l f −lo op i mpl eme nt ati on , ze ro a l l di ag o na l el eme nt s
9if Opt.F=∅then adjMatrix[i, i]←0
// ge n er at e a t le a s t one in g oi n g t r a n si t i o n
11 if PadjMatrix[i, :] = 0 then flag ←1
// ge n er at e a t le a s t one ou tg o in g t r a n s it i o n
13 foreach co l um n el em e n t jin adjMatrix
if PadjMatrix[:, j ]=0 then flag ←1
15 return adjMatrix
Fig. 8: Randomly generated adjacency matrix pseudo-code. The input includes
a number of locations m, and a set of options Opt. The output is an adjacency
matrix adjMatrix.
1fu n c ti o n randFlow(n,AR.Var,Opt,optFlw)
X← AR.Var // as s i g n a ve c to r of s t a t e va r i a b l e s
3if Opt.F6=∅t hen ra nd o m ly se l ec t ζ∈optFlw
// re tur n a random mat ri x f o r a co rr esp on din g random f l ow
5A←Λ(n, ζ)
// ge ner ate a new c on ti nu ous f l ow
7flow ← {˙
X=AX+B}
return flow
Fig. 9: Randomly generated flow pseudo-code. The input includes the number of
variables n, a set of state variables AR.Var, a set of options Opt, and a set of
different classes of matrix’s definiteness optFlw.
and column of adjMatrix (lines 7through 14). Additionally, If we want to gener-
ate a random hybrid automaton without self-loop transition (line 9), we set all
diagonal elements of adjMatrix equal to zero.
Randomly Generating Continuous Flow Dynamics. A randomly gen-
erated affine hybrid automaton ARhas continuous dynamics defined as ˙x=
Ax+B, x∈ Rn, where nis a random number of state variables, xis an n-vector
of state variables, and ˙xis an n-vector of the derivatives of these variables w.r.t.
time. Furthermore, Ais an n×n-matrix of real coefficients and Bis an n-vector
of real constants. We denote Ψ(t) as a fundamental matrix of a linear system
of differential equations ˙x=Ax, where tdenotes time. Moreover, Ψ(t) = eAt

9
can be considered as one fundamental matrix of the system. By using the eigen-
decomposition theorem, a matrix Acan be written as A=vDv−1, where D
is an n×ndiagonal matrix whose diagonal elements correspond to neigen-
values λiof the matrix A, and vis an n×n-matrix where each column viis
a corresponding eigenvector of A. Note that v−1is an n×nconstant matrix
and its determinant is non-zero. If Ψ(t) = eAt is a fundamental matrix, so
Ψ(t) = eAtv=evDv−1tv=ve Dt v−1v=veDt is also a fundamental matrix.
Therefore, the general solution of a system of differential equations ˙x=Axis
x(t) = veDtC, where Cis an n-vector of real values determined by the initial con-
ditions of x(t). If x(t0) = x0is a vector of initial conditions, then C=Ψ(t0)−1x0.
For linear systems, the continuous dynamics may be described as an exponen-
tial function of eigenvalues, and the eigen-decomposition theorem allows us to
generate a random matrix Afrom sets of arbitrarily given eigenvalues and eigen-
vectors.
Suppose that Ais a symmetric real matrix with all of its eigenvalues are
real numbers. If Ais considered as: (a) positive definite (pd), then all of its
eigenvalues are positive, (b) negative definite (nd), then all of its eigenvalues are
negative, (c) semipositive definite(psd), then all of its eigenvalues are non-nega-
tive, (d) seminegative definite(nsd), then all of its eigenvalues are non-positive,
(e) and indefinite (ind), then its eigenvalues have both positive and negative
values. More generally, if Ais equal to its self-adjoin. Then Ais a Hermitian
matrix, and its definiteness is considered based on the real part of its eigenvalues
Definition 3. Let A ∈Cn×nbe an Hermitian matrix, and U,U∗∈Cnbe
a complex vector and its conjugate transpose vector respectively. (a) For every
nonzero vector U (i) if U ∗AU>0, then A is pd (ii) if U ∗AU<0, then A is
nd (b) For every vector U (i) if U ∗AU≥0, then A is psd (ii) if U∗AU≤0,
then A is nsd
According to Definition 3, suppose that (λ, v) is an eigenpair of A, so v∗Av=
λv∗v=λ. Thus a sign of λdepends on a definiteness of A. For example, if
Ais negative define, then λ=v∗Av<0 for all eigenpairs (λ, v) of A. In
other words, a Hermitian matrix Ais considered negative define. This type of
Hermitian matrix is also considered as a Hurwitz matrix that has all negative
real part eigenvaluesCorrespondingly, the continuous dynamic of each location
in system ARgenerated based this matrix will be exponentially asymptotically
stableOtherwise, if Ais randomly generated as a skew-Hamiltonian matrix, then
all eigenvalues of Ahave only imaginary parts.
The pseudo-code of a randomly generated flow dynamic for each location
l∈ AR.Loc shown in Figure 9—called from randHA(Figure 2, line 6). The inputs
include a set of different classes of matrix’s definiteness optFlw that includes all
possible classes of flows for every location in AR. We define optFlw as a tuple
optFlw ∆
=hpd,nd ,psd ,nsd,indi. For each definiteness ζ∈optFlw,Λ(n, ζ) is a
function that returns an n×nrandom matrix corresponding ζ. For randomly
generating a flow of location l, we first generate the vector of state variable X
(line 2). Next, we randomly select a different classes of definiteness in optFlw

10
fu n c ti o n randInv(d,AR.Var,Opt,optInv)
2if Opt.I6=∅t hen ra nd o m ly se l ec t ρ∈optInv
// re t ur n s a se t of random li n e a r in e q u a l i t i e s
4inv ←Γ(d,AR.Var, ρ)
return inv
Fig. 10: Randomly generated invariant pseudo-code. The input includes a dimen-
sion dof a invariant polytope, a set of variable x, a set of option choices Opt,
and a set of different ddimensional polytopes optInv.
1fu n c ti o n randGrd(inv,AR.Var,Opt)
Opt.G6=∅then grd ←Ω(inv,AR.Var)
3return grd
Fig. 11: Randomly generated guard condition pseudo-code. The input are an
invariant polytope inv , a set of option choices Opt and a set of variable AR.Var.
(line 3), and then assign a random matrix corresponding to this class of defi-
niteness (line 5). The continuous dynamics flow is generated by the first order
differential equation {˙
X=AX+B}(line 7), where ˙
Xis an n×1 vector of the
first derivatives of state variables X, and Bis an n×1 arbitrary constant vector.
Randomly Generating Invariants. An invariant for each location of AR
is randomly generated based on the concept of convex polytopes. Let x∈Rnis
a vector of state variables of AR, then a convex polytope is defined as a solution
set of a finite system of linear inequalities Cx≤Dwhere Cis an k×nconstant
matrix, kis a number of linear inequalities, Dis either an k×1 vector of constants
or symbolic expression algebra of state variables. Each linear inequality divides
the whole space in two separately halves called a half-space.Suppose that we have
an knumber of half-spaces generated by an krandom linear inequalities. An
invariant Inv ∈Rdof a hybrid system ARis an ddimensional convex polytope
randomly generated as an intersection of khalf-spaces. We investigate a polytope
generated from system of linear inequalities, which is not full-dimensional. Then,
there exists at least one state variable missing from all linear inequalities. Thus,
this polytope contains a ray, and is unboundedAn unbounded polytope (upo) can
be randomly generated as a slab between two arbitrary parallel hyperplanes, an
arbitrary infinite prism, or an arbitrary infinite cone. On the other hand, we
also investigate several bounded polytopes including: (a) ddimensional simplex
polytope (spo): the convex hull of d+ 1 affinely independent points in Rd, or an
intersection of d+ 1 half-spaces. (b) ddimensional cubical polytope (opo): the
family of polytopes that analogues to a cube, and is defined as an intersection of
2dhalf-spaces. (c) ddimensional cross polytope (cpo): the family of polytopes
that analogues to a octahedron, and is defined as an intersection of 2d+ 2
half-spaces The pseudo-code of randomly generated invariant polytope for each
location in ARshown in Figure 10. If a location in ARhas an invariant, we
randomly select one type of ddimensional polytope in optInv (line 2), and then
assign a corresponding set of random linear inequalities to generate an arbitrary
invariant inv (line 4).

11
1fu n c ti o n randRst(n,AR.Var,Opt)
X← AR.Var
3Opt.R6=∅th e n r a ndo m ly se l ec t ψ∈optRst
rst ← {X=Ω(n,AR.Var, ψ)}
5return rst
Fig. 12: Randomly generated update map pseudo-code. The input are a number
variables n, a set of option choices Opt and a set of variable AR.Var.
1fu n c ti o n randInit(n,AR.Var,Opt)
X← AR.Var
3init ← {X=rand(n,1)}
return init
Fig. 13: Randomly generated initial condition pseudo-code. The input are a num-
ber variables n, a set of option choices Opt and a set of variable AR.Var.
Randomly Generating Guard Conditions. For each location l∈ AR.Loc,
its invariant inv is randomly generated as a ddimensional convex polytope Pby
the pseudo-code shown in Figure 10. If Sis a random convex hull of any set of ver-
tices of P, so Sis considered as a ddimensional sub-polytope of PThen, a random
outgoing guard condition of location lis a set of linear inequalities represented
the complement between a vector space Rdand S. A function Ω(inv,AR.Var)
whose inputs are an invariant inv and a set of state variables AR.Var returns a
set of random linear inequalities Jx≥K, where J, K are defined similar to C,
and Drespectively. The pseudo-code of randomly generated a guard condition
for an outgoing transition of each location lshown in Figure 11. If there exists
an outgoing transition from location l, then we will assign a corresponding set
of random linear inequalities for its arbitrary guard condition grd by calling the
Ωfunction (line 2).
Randomly Generating Update Map. A update map can be randomly
generated by assigning either a random constant or an arbitrary symbolic ex-
pression algebra of state variables to each state variable in AR.Var. Suppose that
a set of update map optRst is a tuple optRst ∆
=hconst,symboi. For each type of
an update ψ∈optRst,Φ(n,AR.Var, ψ) is a function that returns an n×1 vector
of random constants or symbolic expression algebra of state variables. Figure 12
shows the pseudo-code for randomly generating a update map. If any transition
of system ARhas an update action, we first randomly select whether to update
state variables to constants or assign them to any symbolic expression algebra
of state variables (line 3). And then, we set an equality between a vector of state
variables Xand a random vector returned by calling Φfunction to be an update
action rst (line 4).
Randomly Generating Initial Conditions. The pseudo-code for gener-
ating a random initial condition init is shown in Figure 13. We use a random
function rand(n,1) (line 3) to generate an n×1 vector of constants, and then
assign it to a vector of state variables X.