Content uploaded by Sergiy Bogomolov

Author content

All content in this area was uploaded by Sergiy Bogomolov on Feb 12, 2016

Content may be subject to copyright.

Runtime Veriﬁcation 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 ﬁrst steps towards a runtime veriﬁcation

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/Stateﬂow (SLSF), etc.—

based on randomized diﬀerential testing. First, hybrid automaton models

are randomly generated. Next, these hybrid automaton models are trans-

lated to a number of diﬀerent tools (currently, dReach, Flow*, HyCre-

ate, SpaceEx, and the MathWorks’ Simulink/Stateﬂow) using the HyST

source transformation and translation tool. Then, the hybrid automaton

models are executed in the diﬀerent tools and their outputs are parsed.

The ﬁnal step is the diﬀerential comparison: the outputs of the diﬀerent

tools are compared; if the results do not agree (in the sense that an anal-

ysis or veriﬁcation result from one tool does not match that of another

tool, ignoring timeouts, etc.), a candidate bug is ﬂagged and the model

is saved for future analysis by the user. The process then repeats and the

random diﬀerential 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

diﬀerent development tools, and in an earlier version of HyST.

1 Introduction

Runtime veriﬁcation 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 ﬁnite traces and outputs a truth value derived from a

truth domain [3]. Runtime verﬁcation can be used broadly in many purposes

such as debugging, testing, veriﬁcation, validation, fault protection, and online

system repair. In this paper, we describe preliminary work towards a randomized

diﬀerential 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/Stateﬂow (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 diﬀerential 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 ﬁrst steps toward a randomized diﬀerential testing framework to

monitor CPS development and veriﬁcation tools, and identifying several bugs in

existing tools, including a semantic diﬀerence 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 Diﬀerential Testing

We ﬁrst describe how the hybrid systems are randomly generated in HyRG

so they have diverse continuous and discrete behaviors. We then analyze these

examples with diﬀerent hybrid systems development and veriﬁcation tools, and

then compare their outputs to identify possible bugs in the tools.

Figure 1shows the overview of our framework for randomized diﬀerential

testing to monitor hybrid systems development tools. First, a random hybrid

automaton randomly generated by HyRG will be translated to diﬀerent formats

of other tools with HyST. Next, we analyze the automaton with diﬀerent ver-

iﬁcation 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.ﬂow ←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.ﬂow}

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, ﬂows, invariants, transitions, guards, updates, and initial conditions.

of sets of time-bounded reachable states computed by diﬀerent 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 diﬀerent 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 diﬀerent random model.

Otherwise, there is possibly a bug in the HyST translation, the veriﬁcation 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 deﬁne the structure of a hybrid automaton [2] and then describe a few

details of the framework

Deﬁnition 1. A hybrid automaton His a tuple, H∆

=hLoc,Var,Flow,Inv,

Trans,Initi, consisting of following components: (a) Loc: a ﬁnite set of dis-

crete locations. (b) Var: a ﬁnite 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 ﬁnite set of invariants for each discrete location, ∀l∈Loc,Inv(l)⊆ Rn.

(d) Flow: a ﬁnite 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 ﬁnite 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 satisﬁed, 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 diﬀerent 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 (Deﬁnition 1) of ARare randomly generated as

shown in Figure 2. We use the dot (.) notation to refer to diﬀerent 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 aﬃne functions used in ﬂows, guards, invariants,

assignments, etc., we instead partition these aﬃne functions into interesting

classes. While we assume aﬃne 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 ﬂow l.ﬂow (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 diﬀerences among several hybrid systems veriﬁcation 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

diﬀerences in resets between SpaceEx and SLSF. In SLSF, the variables x1and

x2are updated in order, so that x1will be ﬁrst 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 diﬀerence.

variables are updated concurrently in SpaceEx, so x2will be updated by using

the previous value of x1. Based on this, we ﬁxed this translation error in HyST.

4 Conclusion and Future Work

In this paper, we describe our preliminary results toward building a random-

ized diﬀerential testing framework to monitor hybrid and cyber-physical systems

(CPS) development tools like SLSF and veriﬁcation 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 veriﬁcation of hybrid systems.

In: Computer Aided Veriﬁcation (CAV). LNCS, Springer (2011)

3. Leucker, M., Schallhart, C.: A brief account of runtime veriﬁcation. 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 aﬃne 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 deﬁnite 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

deﬁnite matrix A, so it is exponentially asymptotically stable.

HyRG takes as inputs the options speciﬁed 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

Deﬁnition 2. A time-dependent switching set Time is a tuple Time ∆

=hτ, β , θ, σ, φi,

where (a) τ: a time variable. (b) β: a ﬁrst 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 ﬁrst 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 ﬂag

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 ← ∅

3ﬂag ←1

wh i le ﬂag = 1

5ﬂag ←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 ﬂag ←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 ﬂag ←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

7ﬂow ← {˙

X=AX+B}

return ﬂow

Fig. 9: Randomly generated ﬂow 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

diﬀerent classes of matrix’s deﬁniteness 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 aﬃne hybrid automaton ARhas continuous dynamics deﬁned 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 coeﬃcients and Bis an n-vector

of real constants. We denote Ψ(t) as a fundamental matrix of a linear system

of diﬀerential 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 diﬀerential 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 deﬁnite (pd), then all of its

eigenvalues are positive, (b) negative deﬁnite (nd), then all of its eigenvalues are

negative, (c) semipositive deﬁnite(psd), then all of its eigenvalues are non-nega-

tive, (d) seminegative deﬁnite(nsd), then all of its eigenvalues are non-positive,

(e) and indeﬁnite (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 deﬁniteness is considered based on the real part of its eigenvalues

Deﬁnition 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 Deﬁnition 3, suppose that (λ, v) is an eigenpair of A, so v∗Av=

λv∗v=λ. Thus a sign of λdepends on a deﬁniteness of A. For example, if

Ais negative deﬁne, then λ=v∗Av<0 for all eigenpairs (λ, v) of A. In

other words, a Hermitian matrix Ais considered negative deﬁne. 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 ﬂow dynamic for each location

l∈ AR.Loc shown in Figure 9—called from randHA(Figure 2, line 6). The inputs

include a set of diﬀerent classes of matrix’s deﬁniteness optFlw that includes all

possible classes of ﬂows for every location in AR. We deﬁne optFlw as a tuple

optFlw ∆

=hpd,nd ,psd ,nsd,indi. For each deﬁniteness ζ∈optFlw,Λ(n, ζ) is a

function that returns an n×nrandom matrix corresponding ζ. For randomly

generating a ﬂow of location l, we ﬁrst generate the vector of state variable X

(line 2). Next, we randomly select a diﬀerent classes of deﬁniteness 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 diﬀerent 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 deﬁ-

niteness (line 5). The continuous dynamics ﬂow is generated by the ﬁrst order

diﬀerential equation {˙

X=AX+B}(line 7), where ˙

Xis an n×1 vector of the

ﬁrst 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 deﬁned as a solution

set of a ﬁnite 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 inﬁnite prism, or an arbitrary inﬁnite cone. On the other hand, we

also investigate several bounded polytopes including: (a) ddimensional simplex

polytope (spo): the convex hull of d+ 1 aﬃnely 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 deﬁned as an intersection of

2dhalf-spaces. (c) ddimensional cross polytope (cpo): the family of polytopes

that analogues to a octahedron, and is deﬁned 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 deﬁned 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 ﬁrst 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.