HARE: A Hybrid Abstraction Refinement Engine for Verifying Non-linear Hybrid Automata

Abstract

(Hybrid Abstraction-Refinement Engine) is a counterexample guided abstraction-refinement (CEGAR) based tool to verify safety properties of hybrid automata, whose continuous dynamics in each mode is non-linear, but initial values, invariants, and transition relations are specified using polyhedral constraints. works by abstracting non-linear hybrid automata into hybrid automata with polyhedral inclusion dynamics, and uses to validate counterexamples. We show that the CEGAR framework forming the theoretical basis of , makes provable progress in each iteration of the abstraction-refinement loop. The current tool is a significant advance on previous versions of —it considers a richer class of abstract models (polyhedral flows as opposed to rectangular flows), and can be applied to a larger class of concrete models (non-linear hybrid automata as opposed to affine hybrid automata). These advances have led to better performance results for a wider class of examples. We report an experimental comparison of against other state of the art tools for affine models (, , and ) and non-linear models (, , and ).

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Abstractions play an important role in the verification of cyber-physical systems, where complex continuous dynamics are abstracted into simpler dynamics that are amenable to automated analysis. This is because the general problem of safety verification is undecidable even for very simple class of continuous dynamics [2, 4, 20, 25, 32]. The success of the abstraction based method depends on finding the right abstraction, which can be difficult. One approach that tries to address this issue is the counter example guided abstraction refinement (CEGAR) framework [9] that tries to automatically discover the right abstraction through a process of progressive refinement based on analyzing spurious counter examples in abstract models. CEGAR has been found to be useful in a number of contexts [6, 12, 21, 22], including hybrid systems [3, 10, 11, 14, 17, 23, 30, 31].

In this paper, we present the tool , which is a CEGAR based tool for safety verification of hybrid automata with non-linear hybrid systems. The input to is the parallel composition of one or more hybrid automata, where the continuous dynamics in each control mode is described by non-linear ordinary differential equations, while the initial values, invariants, and transition relations are specified using polyhedral constraints. abstracts such models into hybrid automata with polyhedral inclusion dynamics, i.e., in the abstract model, in each mode, the derivative of the continuous variables with respect to time is constrained to belong to a polyhedral set. In this sense, is different from the other CEGAR based tool for non-linear hybrid systems, namely,  [28], which abstracts hybrid automata by finite discrete transition systems. To perform validation of counter examples, uses and the $\delta$-satisfiability procedure of .

The tool described in this paper, is a significant improvement over the version reported in [29]. First, the old version only verified affine hybrid automata. The new version also considers non-linear dynamics. Second, the old version used rectangular automata to abstract concrete models. The new version uses polyhedral hybrid automata. We have observed a marked improvement in running time due to the change in abstract models—there are fewer refinement iterations on many examples because of the use of polyhedral hybrid automata. Third, the tool has been made robust. The implementation has migrated to from to improve its running time. We have changed some of the 3^rd party tools that uses internally. All these changes have enabled to handle a larger class of examples (including more affine hybrid automata), with a faster running time (see results reported in Sect. 6). We have compared the performance of against a number of state of the art model checkers for affine hybrid automata and non-linear hybrid automata—  [19],  [18],  [7],  [28],  [16], and  [8]. We also compare against the old version of  [29]. We show that the new tool successfully proves safety when the others fail, and the running time is comparable to the other tools (see Sect. 6). A virtual machine for the new , along with examples and scripts can be downloaded from https://uofi.box.com/v/HARE.

The rest of the paper is organized as follows. We introduce basic definitions and notation in Sect. 3. Our CEGAR framework, algorithms for abstraction, counter example validation, and refinement, that form the theoretical basis for , are described in Sect. 4. The tool architecture and its internals are presented in Sect. 5, and Sect. 6 reports our experimental results.

2 Related Work

Doyen et al. consider rectangular abstractions for safety verification of affine hybrid systems in [15]. However, their refinement is not guided by counter example analysis. Instead, a reachable unsafe location in the abstract system is determined, and the invariant of the corresponding concrete location is split to ensure certain optimality criteria on the resulting rectangular dynamics. This, in general, may not lead to abstract counter example elimination, as in our CEGAR algorithm. We believe that the refinement algorithms of the two papers are incomparable—one may perform better than the other on certain examples. Empirical evaluations could provide some insights into the merits of the approaches, however, the implementation of the algorithm in [15] was not available for comparison at the time of writing the paper.

Bogomolov et al. consider polyhedral inclusion dynamics as abstract models of affine hybrid systems for CEGAR in [7]. Their abstraction merges the locations, and refinement corresponds to splitting the locations. Hence, the CEGAR loop ends with the original automaton in a finite number of steps, if safety is not proved by then. Our algorithm splits the invariants of the locations, and hence, explores finer abstractions. Our method is orthogonal to that of [7], and can be used in conjunction with [7] to further refine the abstractions.

Nellen et al. use CEGAR in [26] to model check chemical plants controlled by programmable logic controllers. They assume that the dynamics of the system in each location is given by conditional ODEs, and their abstraction consists of choosing a subset of these conditional ODEs. The refinement consists of adding some of these conditional ODEs based on an unsafe location in a counter example. The method does not ensure counter example elimination in successive iterations. Their prototype tool does not automate the refinement step, in that the inputs to the refinements need to be provided manually. Hence, we did not experimentally compare with this tool.

Zutshi et al. propose a CEGAR-based search in [33] to find violations of safety properties. Here they consider the problem of finding a concrete counter example and use CEGAR to guide the search of the same. We instead use CEGAR to prove safety—the absence of such concrete counter examples.

3 Preliminaries

Numbers. Let , , and denote the set of natural, rational, and real numbers, respectively. Similarly, , , and are respectively the set of positive natural, rational, and real numbers, and and are respectively the set of non-negative rational and real numbers. For any we define .

Sets and Functions. For any sets A and B, is the size of A (the number of elements in A), is the power set of A, $A\times B$ is the Cartesian product of A and B, and $B^A$ (similarly $A\rightarrow B$) is the set of all functions from A to B. In order to make the notations simpler, for any , by $A^n$ and $A^{n\times m}$, we mean and . The latter represents matrices of dimension $n \times m$ with elements from A. For any and set $C\subseteq A$, . Similarly, for any $\pi =a_1,a_2,\ldots ,a_n$, a sequence of elements in A, we define $f(\pi )$ to be $f(a_1),f(a_2),\ldots ,f(a_n)$.

Polytopes. For any set of variables , a function , and a constant , is an affine constraint over the variables in . A polyhedron is a conjunction of finite number of affine constraints. Every polyhedron P over , defines a set of points in , namely the set of points that satisfy all constraints of P. We only consider non-strict inequalities, therefore P always defines a closed set. For any point , means satisfies all the constraints in P. A polyhedron that defines a bounded set is called polytope. We denote the set of all polytopes over by .

3.1 Hybrid Automata

In this section, we present hybrid automata models for representing concrete and abstract hybrid systems.

Definition 1

(Hybrid Automata). A hybrid automata is a tuple in which

• is a non-empty finite set of locations.

• is a non-empty finite set of variables. We let be the set of all possible valuations of variables in . We also let to be the set of primed variables ( and ). For every variable we use $x'$ to denote the corresponding variable in .

• maps each location to a polytope over as invariant of that location.

• maps each location q to the set of possible flows of that location. Each element in this set is a pair . Intuitively it means, if the current continuous state is then is a possible direction field.

• $\mathtt {E}$ is a set of edges of the form $e=(s,d,r)$ where

  • are respectively source and destination of e,

  • specifies relation of valuations before and after taking edge e as the reset relation.

  We let to be guard of e, as the set of valuations for which the reset relation is non-empty (note that $\mathtt {G}(e)$ can be represented by a polytope in ). We use $\mathtt {S}(e)$, $\mathtt {D}(e)$ and $\mathtt {R}(e)$, to denote different elements of guard e.

• are respectively sets of initial and unsafe locations.

We denote different elements of by adding a subscript to their names. For example, we use to denote the set of variables of . We may omit the subscript whenever it is clear from the context.

In this paper, we use non-linear hybrid automata to specify a concrete system. In this class of automata, for any location , $\mathtt {F}(q)$ is specified by a continuous (possibly nonlinear) function f of type . More precisely, . Therefore, $\mathtt {F}(q)$ defines exactly one direction for any valuation in the invariant of that location. We abuse the notation and write $\mathtt {F}(q)=f$ when it causes no confusion. Next, in this paper, we use polyhedral hybrid automata to specify abstract systems. In this class of automata, for any location , $\mathtt {F}(q)$ is specified by a polytope . More precisely, . Therefore, $\mathtt {F}(q)$ is independent of the current valuation. We abuse the notation and write $\mathtt {F}(q)=P$ when it causes no confusion. Note that affine hybrid automata and rectangular automata which we used in [29] for specifying concrete and abstract systems, are subclasses of non-linear automata and polyhedral automata we use in this paper.

The semantics of a hybrid automaton is defined using an infinite transition system in the usual way. is the state set of . For any two states , we write $q_1=q_2$ and goes to at non-negative time t according to the continuous dynamics of location $q_1$. We also write $q_1$ and $q_2$ are source and destination of the edge e and and satisfies invariants of source and destination locations as well as the transition relation. Finally, we use and to refer to the set of initial and unsafe states respectively.

A trajectory is a sequence $\tau =s_0,(t_0,e_0),s_1,(t_1,e_1),s_2,(t_2,e_2),\ldots ,s_n$ such that for any $i<n$ there is a state $s'_i$ such that . We define $\tau _0$ to be the initial state $s_0$ and $\tau _\mathsf {lst}$ to be final state $s_n$. For any hybrid automaton , the reachability problem asks whether or not has a trajectory $\tau$ such that and . If the answer is positive, we say the is unsafe. Otherwise, we say the is safe.

For any hybrid automaton , set of states , and edge we define the following functions:

• . Discrete post of S in with respect to e is the set of states reachable from S after taking e.

• . Discrete pre of S in with respect to e is the set of states that can reach a state in S after taking e.

• . Continuous post of S in is the set of states reachable from S in an arbitrary amount of time using dynamics specified for the source locations.

• Continuous pre of S in is the set of states that can reach a state in S in an arbitrary amount of time using dynamics specified for the source locations.

4 CEGAR Algorithm for Safety Verification of Non-linear Automata

Every CEGAR-based algorithm has four main parts [9]: 1. abstracting the concrete system, 2. model checking the abstract system, 3. validating the abstract counter example, and 4. refining the abstract system. We explain parts of our algorithm regarding each of these parts in this section. Algorithm 1 shows at a very high level what the steps of our algorithm are.

For technical reasons (see Sect. 4.1 of [29]), we assume that in the concrete hybrid automaton, each location has a self loop transition that ensures that the duration between successive discrete steps is bounded. This assumption also makes defining the refinement step technically easier.

4.1 Abstraction

Input to our algorithm is a non-linear automaton which we call the concrete hybrid automaton. The first step is to construct an abstract hybrid automaton which is a polyhedral automaton. The abstract hybrid automaton is obtained from the concrete hybrid automaton , by splitting the invariant of any location into a finite number of cells of type and defining an abstract location for each of these cells which over-approximates the non-linear dynamics in the cell by polyhedral dynamics. Definitions 2 and 3 formalizes the way an abstraction is constructed from . Note that the construction guarantees that the behavior of over-approximates behavior of and therefore if is found to be safe, is guaranteed to be safe as well.

Definition 2

(Invariant Partitions). For any hybrid automaton and function we say P partitions invariants of the following conditions hold for any location :

• $\bigcup P(q) = \mathtt {I}(q)$, which means union of cells in P(q) covers invariant of q.

• For any $p_1,p_2\in P(q)$, $p_1\ne p_2$ implies $p_1$ and $p_2$ have disjoint interior¹.

Definition 3

(Abstraction Using Invariant Partitioning). For any non-linear automaton and invariant partition , returns polyhedral automaton which is defined below:

• ,      – ,

• ,          – ,

• ,

• , and

• , where for any bounded set , is a polytope W such that and for any sequence of bounded sets $S_1,S_2,\ldots$, if the maximum distance of any two points in $S_n$ converges to 0 then the maximum distance of any two points in the image of this sequence under converges to 0 as well.

In addition, we define function to map 1. every state in to a state in , and 2. every edge in to an edge in . Formally, for any and , we define to be and to be $(q_1,q_2, r)$.

When is an affine dynamic, there is unique minimum polytope for that can be constructed exactly and efficiently. However, if the concrete flow is non-linear, abstraction even using the minimum rectangular hull might be very expensive. In our current implementation, when the flow is non-linear, we first find the rectangular hull for and then use interval arithmetic to find a rectangular set that contains as specified in Definition 3.

4.2 Counter Example and Model Checking Polyhedral Automata

After an abstract hybrid automaton is constructed (initially and after any refinement), we have to model check it. In this section we define the notion of a counter example and annotation of a counter example, which we assume is returned by the abstract model checker $O^\mathtt {Poly}$ when it finds that the input hybrid automaton is unsafe.

Definition 4

For any hybrid automaton , a counter example is a path $e_1,\ldots , e_n$ such that and .

Definition 5

A counter example $\pi$ is called valid in has a trajectory $\tau$ and $\tau$ has the same sequence of edges as $\pi$. A counter example that is not valid is called spurious.

Definition 6

An annotation for a counter example $\pi = e_1,\ldots , e_n$ of hybrid automaton is a sequence such that the following conditions hold:

Condition 1 means that each $S_i$ and $S'_i$ in $\tau$ are a non-empty set of states. Conditions 2 and 3 mean that sets of states in $\tau$ are computed using backward reachability. Finally, condition 4 means that $S'_n$ is the set of unsafe states in destination of $e_n$. Note that these conditions completely specify $S_0$, ..., $S_n$ and $S'_0,\ldots ,S'_n$ from $e_1$, ..., $e_n$ and . Also, every $S_i$ and $S'_i$ is a subset of states corresponding to exactly one location.

In this paper, we assume to have access to an oracle $O^\mathtt {Poly}$ that can correctly answer reachability problems when the hybrid automata are restricted to be polyhedral automata. If no unsafe location of is reachable from an initial location of it, returns ‘safe’. Otherwise, it returns an annotated counter example of .

Fig. 1.

Validation and refinement. There are three locations: $i-1$, i, and $i+1$. $S_{i+1}$ and $S'_i$ are elements of annotated counter example $\tau$. $R'_{i-1}$, $R_i$, and are computed when $\tau$ is validated. i is the smallest index for which and are separated. Hence we need to refine in location i. Refinement should be done in such a way that for the result of refinement we have ( is the preimage of ).

4.3 Validating Abstract Counterexamples and Refinement

For any invariant partition P and non-linear automaton , if (for ) returns ‘safe’, we know is safe. So the algorithm returns is ‘safe’ and terminates. On the other hand, if $O^\mathtt {Poly}$ finds to be unsafe it returns an annotated counter example $\tau$ of . Since is an over-approximation of , we cannot be certain at this point that is also unsafe. More precisely, if $\pi$ is the path in $\tau$, we do not know whether is a valid counter example in or it is spurious. Therefore, we need to validate $\tau$ in order to determine if it corresponds to any actual run from an initial location to an unsafe location in C.

To validate $\tau$, an annotated counter example of , we run $\tau$ on C. More precisely, we create a sequence where

We proved the following proposition and lemma in [29].

Proposition 7

$R'_n=\emptyset$ in $\tau '$ implies there exists i such that 1. $R'_i = \emptyset$, 2. $R_i \ne \emptyset$, 3. , and 4. and are nonempty disjoint sets.

Lemma 8

The counter example $\pi ' = e'_1, \ldots , e'_n$ of C is valid $R'_n\ne \emptyset$.

Refinement. Suppose the counterexample $\tau$ is spurious. There is a smallest index i such that $R'_i = \emptyset$. We will refine the location $(q,p) = \mathtt {D}e_i$ of by refining its invariant p. We know from Proposition 7, . However, the corresponding sets in the abstract system are not disjoint, that is, ( is the preimage of ). Our refinement strategy is to find a partition for the location (q, p) such that in the refined model (for some $P'$), $S'_i$ is not reachable from $R_i$ (Fig. 1). Let us denote by the restriction of to the single location q with invariant p, i.e., has only one location q whose flow and invariant is the same as that of (q, p) in , and only transitions whose source and destination is q. We will say that an invariant partition $P_r$ of separates $R_i$ from $S'_i$ iff in the automaton , . In other words, the states corresponding to $S'_i$ in are not reachable from in . Our refinement strategy will refine by partitioning the control location (q, p) by the invariant partition $P_r$. Using results from [27], we observed [29] that such a partition $P_r$ always exists. We also showed that such a refinement strategy ensures that any abstract counter example appears only finitely many times in the CEGAR loop.

The previous discussion, relies on the fact that we can compute exactly. Unfortunately this is not possible for the class of hybrid automaton we are considering. We use $\delta$-complete decision procedures available through and to check whether $R'_n$ will be empty for some n. If returns , we know the $R'_n=\emptyset$, and we can conclude that the counter example is spurious. However, if returns , we know $\delta$-perturbation of the syntax of the formula defining $R'_n$ makes it satisfiable. But this does not imply that $R'_n$ itself isnon-empty. Hence, it is possible that because of our use of for counter example validation, we may not be able to detect spurious counter examples.

Fig. 2.

Flow chart of ’s CEGAR loop

5 Tool’s Architecture

Figure 2 shows the flow and architecture of . It also identifies 3^rd party libraries/tools that are internally used by at different steps. We use  [13] to check if a fix-point is reached in the abstract system model-checking, and also to check whether an unsafe state is reached. We use Boost Interval Arithmetic Library () [1] to abstract non-linear dynamics. We use to validate a counter example (the validation a counter example of length n involves at most n invocations of ). Note that calls , internally. Also, / are not available in the form of libraries. Therefore, executes as a separate process and communicates with it through files. Finally, we use Parma Polyhedra Library () [5] to manipulate symbolic abstract states. This includes, computing discrete/continuous abstract posts, constructing annotated counter examples, finding rectangular hull of a polytope, abstracting affine flows, and checking if a parallelly composed location/edge has non-empty invariant/transition relation. Compared to the old version of in [29], we have replaced with , since does not support non-linear dynamics. Also, we have implemented everything in instead of to improve performance.

The abstract model checker in has a parameter with possible values and . It specifies whether the tool should perform forward or backward reachability. But can only compute and not . This is the reason for the step “Reverse Time If Necessary”. There is an optional integer parameter for each of the abstract and concrete model checkers. If the maximum number of iterations is reached in the abstract model checker, it returns as an answer. If abstract model checker returns this answer to the concrete model checker, will be returned as a result. If the maximum number of iterations is reached in the concrete model checker, it returns as the answer. In addition to or , the user can also ask to produce a , an , or the . Clearly, the first two will only be produced if the system is found to be unsafe and the last one will only output the abstract reachable states. Note that abstract model checker can be directly called by user.

The model to be checked along with all the options for the model checker are specified in a single human readable text file according to from Boost Property Tree Library [24]. Every model, contains one or more hybrid automata and the safety problem is considered for their parallel composition which is constructed on the fly. Continuous variables can be read by all hybrid automata. If the file specifies polyhedral automata, each hybrid automaton can write to all variables through transition relations and flow. On the other hand, if the file specifies a non-linear automaton, different hybrid automata can still write to a common variable through transition relations, but flow of a variable should be defined in exactly one hybrid automaton. Initial and unsafe states are specified after all hybrid automata using zero or more polyhedra for each composed location. Each edge has an optional label. If it is specified, it means that edge must be synced with an edge from other hybrid automata in the file. Otherwise, it will be interleaved. If a specified label does not end with ‘?’, ‘!’, or ‘!!’, synchronization will be among all hybrid automata in the file (i.e. each hybrid automaton must take an edge with the exact same label). Characters ‘?’, ‘!’, and ‘!!’ are used to specify input/output hybrid automata, where ‘?’ is for an input edge, ‘!’ is for an output edge, and ‘!!’ is for a broadcast edge. Character ‘*’ at the beginning of a location name means that location is transient and time cannot pass inside that location. Allowing transient locations in the model has three benefits 1. neither abstract nor concrete model checker will waste time by computing continuous post in transient locations, 2. the result automata will have one less variable, and 3. the model will be easier to understand. Finally, the current interface to the tool is only through the command line.

6 Experimental Results

The new version of is available from https://uofi.box.com/v/HARE; the old version of the tool can be downloaded from https://uofi.box.com/cegar-hare-tacas-2016. Examples and scripts for running the examples can also be found on the links. Both these links contain a virtual machine to make repeatability straightforward.

We have run with different set of examples with both affine and non-linear dynamics. Brief explanations of the affine benchmarks can be found in [29]. Table 1 contains the results for the affine examples. We compare the performance of , its old version in [29],  [19],  [18], and  [7]s². The first two tools are affine hybrid automata model checkers that are not CEGAR based, while the last is a CEGAR based tool for concurrent hybrid automata³. In the past [29], we also reported the performance of  [28] on affine examples. However, since it performed poorly on affine examples, we have not included it for comparison in Table 1.

The new version of proved all examples are safe, while the old version could not do this for four examples. Also the new version is faster on all examples, except one. almost never reached a fixed point. could prove safety for only half of the examples, and it did it faster than new version of in only one case. Abstraction in appears to be a very expensive operation—in four examples, the initial abstraction was not constructed even after 600 s (10 min) and we terminated the execution. Also, in three examples we could not find any set of locations that does not cause the tool to crash right at the beginning. Among 8 examples that worked for , it could prove safety for 5 of them and it was always slower than new version of .

Table 1. Comparing with its old version in [29] and other tools for affine dynamics. Dim. is the number of continuous variables. Size is the number of locations/edges in the input (concrete) model. Iters. is the number of iterations in our CEGAR loop before proving safety. FP. tells whether or not a tool reached a fixed-point. If a tool does not reach a fixed-point then even if it says the system is safe, the answer may not be true. As explained in [29], sometimes tells it reached a fixed-point, but before that it generates a warning that its result may not be complete. We continue to consider those cases as has not reached a fixed-point. Merged Locs. is the number of locations we initially merged for . Columns old and new for contain results from the previous and current version of this tool. All times are in seconds and all examples were run on a laptop with Intel i5 2.50 GHz CPU and 6 GB of RAM.

Table 2 contains results of comparing with  [16],  [28], and  [8] on nonlinear examples. Note that and support proving safety for unbounded time and unbounded number of discrete transitions. But both and require bounded time and bounded number of discrete transitions. Also none of these two tools check whether the computed (unbounded) reachable set so far is a fixed-point. Therefore, no matter how big the time-bound is set, proving safety for this time bound in these tools does not guarantee unbounded time safety. In our experience, we set the bound for discrete number of transitions large enough so none of the tools reported maximum number of discrete transitions are reached. For the first 5 examples, we set the time bound equal to 1000 in and . For the last example, the time bound is 10 in all tools. always finished faster than . On three examples is faster than and only in one example it is slower. On 3 examples proved safety faster than , and in 2 examples was faster. comes with an example named circuit (not reported in Table 2). The size of hybrid automaton in this example is small, but it has constants of the order $10^{12}$, which turns out to be too big for and and trigger a bug in these two tools (and hence ). Only proves safety of this example. Finally, in our experiments, performs much faster for the affine dynamics. Non-linear examples are also available at link for the new version of we mentioned earlier.

Table 2. Comparing running time of with other tools for non-linear dynamics. Dim. is the number of continuous variables. Size is the number of locations/edges in the input (concrete) model. Reached Abst. Size is the number of locations/edges in the final abstract model that are reached in right before safety is proved. Time Bound is 10 for the “Sinusoid” model in all four tools. For all the other examples, there is no time bound in both and . In other word, and prove unbounded time safety for all but the last example. and on the other hand, require finite time bound, and we set it to be 1000 (except for the “Sinusoid” model which is 10). We have terminated all the runs that took more than 600 s (10 min). requires bounded invariants. So in the first four examples, we put 100 as an upper bound and $-100$ for as a lower bound of unbounded variables. does not support trigonometric functions and encounters an internal error on one of the examples. All times are in seconds and all examples were run on a laptop with Intel i5 2.50 GHz CPU and 6 GB of RAM.

6.1 Unbounded Invariants

The first 4 examples in Table 2 are taken from . Tools like and that try to compute the reachable set as precisely as possible, tend not to specify invariants. On the other hand, tools like and that perform refinement by partitioning the state space tend to require bounded invariants. Another reason for to prefer bounded invariants is that , which uses internally, only works for bounded variables. We had a few options to bound the invariants in those examples. The first option is to bound the invariants using large enough numbers (just like what we did for ). This means we are guessing the invariant. If the guessed invariants are all closed sets, one can verify the guess by setting closure of complement of it as the unsafe states. If the unsafe states are not reachable then the guess is valid. Note that since computes over-approximation of unsafe states, it is possible that incorrectly says a guessed invariant is invalid. The second option is to first use tools like or and find a coarse invariant for all locations. Note that since these tools have bounded number of discrete transitions and they do not check for fixpoint, one might still need to verify that invariants obtained using or are valid. The third option, which we have used for the current implementation, is noticing that the only part of the implementation that requires invariant to be bounded is where is called. If this tool is called with an unbounded variable, then it will quickly raise an exception and terminate. In other words, it will terminate without saying that the counter example is valid. We take not saying valid as saying invalid. This approach makes it possible to use even when invariants are not bounded. Note that during validation of a counter example of length larger than one, it is possible that only invariants after some step k are unbounded. Our current approach guarantees all variables are bounded when is called for indices k or smaller. An example of such a system, Automatic lane change system (driver assist) that comes with . It is a system with affine dynamics and 10 unsafe sets. proved unbounded safety for all these sets in about 190 s. During this time, encountered exception in almost every iteration. But eventually, the abstract model checker reached a fixed point and found the system to be safe, so was not called again. needs to prove safety for each of these sets separately and it took this tool about 1163 s to prove them all when the time bound is set to 1000. and could not prove safety for any of these sets within 600 s (10 min)⁴. A fourth option is one where we initially partition the state space blindly for a small number of times first, and then start the actual CEGAR loop. We used this option in all four examples in Table 2 from .

7 Conclusion

We presented a new version of the CEGAR-based model checker for non-linear hybrid systems called . This version is a significant improvement over the previous version of that was reported in [29]. First, can now verify non-linear hybrid automata instead of hybrid automata with affine dynamics and rectangular constraints. Second, now uses polyhedral hybrid automata as abstractions as opposed to rectangular hybrid automata. Finally, the implementation has been optimized. These changes have enabled the tool to handle a larger class of examples, in faster time. These observations have been substantiated by our experimental results reported here. While the use of for counter example validation has improved the performance for affine hybrid automaton, our experiments show that performs poorly for counter examples for non-linear automata (when compared with ). In the future, we plan to explore if we can use (instead of ) for counter example validation.