A Loop Acceleration Technique to Speed Up Veri cation of …rpgoldman.goldman-tribe.org › papers › loop-acceleration... · 2013-06-28 · un-augmented model. That approach would

Software Tools for Technology Transfer manuscript No.(will be inserted by the editor)

A Loop Acceleration Technique to Speed Up Verification ofAutomatically-Generated Plans

Robert P. Goldman and Michael J.S. Pelican and David J. Musliner

SIFT, LLC; Minneapolis, MN, USA

Received: 2 April 2012 / Revised version: 18 February 2013

Abstract. The CIRCA planning system automaticallycreates reactive plans and uses formal verification tech-niques to prove that those plans will preserve systemsafety. CIRCA’s timed automata verification system ishighly efficient, yet can display pathologically bad be-havior when reasoning about reaction loops, a particularform of interacting cycles of states. In this paper we de-scribe a loop acceleration technique that recognizes thesestate space structures during the verification process andbypasses the process of expanding an arbitrarily largecycle of states, effectively compressing loops of arbitrarysize into a compact, finite set of states. The resulting per-formance improvement can be very dramatic: in domainswhere tight loops of short-duration transitions interactwith long-duration transitions, our new loop accelera-tion methods can reduce verification time (and henceplanning time) from hours to below a second.

1 Introduction

The ability to automatically prove reachability proper-ties of programs or plans has many applications in com-puter science, including safety proofs for plans gener-ated by classical planning systems. Although intractable(or in some cases undecidable) in the worst-case, algo-rithmic improvements and modern computing hardwarehave made these model-checking techniques practical forlarger and larger problems. Unfortunately, when patho-logical cases arise, practitioners may encounter the in-tractability.

We describe a specific challenge, state space fragmen-tation, that can arise in the context of model-checkingtimed automata, and present a practical solution to manyinstances of this challenge. The model of timed automa-ta [1], an extension of nondeterministic finite state ma-chines, was developed to analyze real-time systems, such

as discrete supervisory control of temporally-extendedprocesses. Systems for model-checking timed automatainclude UPPAAL [2–4] and Kronos [5].

The state-space fragmentation problem arises whenstate transitions of greatly different temporal latenciescreate interacting cycles of states. This problem wasfirst described by Hune [6] and Iversen [7] in the con-text of verifying real-time controllers for LEGO R©Mind-stormsTM robots. In some cases where two transition cy-cles apply to the same plan state, the shorter durationtransition can “fragment” [8] the larger transition, cre-ating an explosion in the number of states considered bythe model-checker.

We encountered the fragmentation problem in theform of “reaction loops” in the CIRCA hard real-timeplanning, controller synthesis, and reactive execution sys-tem. CIRCA automatically synthesizes hard real-timecontrollers that may be modeled as timed automata,and uses a custom timed automaton model-checker inits controller synthesis [9–12]. As part of the controllersynthesis process, the timed automaton model-checker isused to verify that the controllers are safe (that failurestates are unreachable). We encountered the fragmenta-tion problem checking CIRCA controllers that executedquick reactions to meet environmental threats while si-multaneously monitoring long-duration processes. Suchproblems would typically make the verification runs takeso long as to make the controllers impossible to ana-lyze, and thus synthesis became impossible. We devel-oped a new technique for loop acceleration that coversa case not handled by previous methods. We describethat technique and its implementation in this paper, andshow that it radically speeds up timed automaton ver-ification. While the technique exploits some particularfeatures of CIRCA control problems, these features arenot especially exotic, so the technique should be readilyapplicable in other timed automaton problems.

2 Goldman, Pelican & Musliner: Loop Acceleration for Plans

We begin by discussing related work on fragmenta-tion in timed automata, focusing on the work by Hen-driks and Larsen. After that, in Section 3, we introducethe CIRCA system, its controller synthesis process, andthe way it uses a timed automaton verifier. We then re-view the model of timed automata, and discuss some ofthe most important features of timed automata reach-ability verification (Sections 4 and 5). We bring thingstogether, discussing how the CIRCA controllers may bemodeled with timed automata (Section 6). We introducethe problem of reaction loops (Section 7), and the loopacceleration technique that we have developed to han-dle the problem (Section 8). After that, we present aproof that analytically demonstrates the correctness ofthe technique (Section 9), and empirically demonstrateits usefulness with empirical results from tests with theCIRCA system (Section 10). We conclude with someideas about future directions (Section 11).

2 Related work

The most closely-related work to ours is the work onloop acceleration for UPPAAL done by Hendriks andLarsen [13,8]. It was the discovery of this work that in-spired our own. Despite that, their work is quite differentfrom ours in technique and objectives.

In particular, their technique is particularly tailoredto verifying correct controllers. It was developed in re-sponse to a problem verifying the correctness of a con-troller that conducted a busy-waiting loop during thecourse of a long-running process in the controller’s en-vironment. It was very expensive to recognize that thesystem would eventually reach the desired state — ver-ification of an “eventually reachable” TCTL goal. Theirsolution involves adding loop acceleration edges to themodel, allowing UPPAAL to detect the reachability morequickly, using breadth-first search, than with the originalun-augmented model.

That approach would not help us in the verificationof CIRCA control plans; in fact, it would actually makeverification worse! The difference is that the primarytask in CIRCA verification is to demonstrate that thecontroller is safe by showing that it can never reach anundesirable state. This means that verification involvesexhaustive search of the state space, so that augmentingthe model with new transitions (shortcuts), as Hendriksand Larsen do, would actually make the search spacebigger, and in the case where the controller is safe, wouldmake the search consume more time. Our technique, bycontrast, works by collapsing together parts of the statespace that are equivalent with respect to the class ofsafety queries, making exhaustive search faster.

Hendriks and Larsen’s technique also works only inthe case where a loop is concerned only with a singleclock. That is, where all the guards and invariants in-volve only a single clock, and where the value of that

single clock increases monotonically. By contrast, in ourloops there are typically multiple clocks racing againsteach other, and clocks are reset — since the loop involvesthe controller repeatedly servicing some process in theenvironment.

Other researchers have recently presented approachesto acceleration in different, but related contexts. Forexample, Fietzke et al. [14] have shown how to accel-erate loops involving a single clock in a variation oftimed automata they call “Extended Timed Automata.”Bozga et al. [15] present theoretical work on identifyingperiodic relations in model checking and an implemen-tation in their FLATA toolset. However, they are inter-ested in infinitely periodic loops, and are working withinteger programs, rather than timed automata. Bardinet al. have developed a general theory of acceleration inmodel-checking [16], that includes loop acceleration as aspecial case of what they call “flat acceleration.” Theyhave applied it to integer programs in the FAST tool [17].Closer to our own interests is the work by Ben Salahon partial order optimization for timed automata [18].While the field of their optimization is different, it issimilar in computing a convex clock region for multipledifferent paths, in their case paths that represent differ-ent permutations of the same discrete transitions. Thetheoretical underpinnings of this work might make avail-able a more direct proof of correctness of our own loopacceleration.

3 CIRCA Background

CIRCA, the Cooperative Intelligent Real-time ControlArchitecture [9–12], like many autonomy architectures,comprises three layers:

1. The Adaptive Mission Planner (AMP)2. The Controller Synthesis Module (CSM), and3. The Real-Time Subsystem(RTS).

The AMP generates a long duration mission plan con-sisting of one or more mission phases. It constructs phasesby reasoning about long term resource management (wherecomputation time devoted to planning is a significant re-source) and choosing groups of mission goals and threatsto compose as planning problems for the CSM. Throughon-line resource management and dynamic compositionof planning problems, the AMP helps deal with the pos-sibly intractable challenge of planning (and verifying) asingle policy for the entire mission. This simplifies theoverall autonomous control problem into a sequence ofsimpler problems for which controllers can more easily beplanned, verified, and executed. The RTS executes theindividual controllers, providing hard real time guaran-tees. We will not discuss these components further inthis paper: the CSM is our focus here.

The CIRCA CSM contains two main modules of in-terest for this paper: the planner proper, which reasons

Goldman, Pelican & Musliner: Loop Acceleration for Plans 3

ACTION turn_on_main_engine ;; Turning on the main engine

PRECONDITIONS: ’((engine off))

POSTCONDITIONS: ’((engine on))

DELAY: <= 1

EVENT IRU1_fails ;; Sometimes the IRUs break without warning.

PRECONDITIONS: ’((IRU1 on))

POSTCONDITIONS: ’((IRU1 broken))

;; If the engine is burning while the active IRU breaks,

;; we have a limited amount of time to fix the problem before

;; the spacecraft will go too far out of control.

TEMPORAL fail_if_burn_with_broken_IRU1

PRECONDITIONS: ’((engine on)(active_IRU IRU1) (IRU1 broken))

POSTCONDITIONS: ’((failure T))

DELAY: >= 5

Fig. 1. Example transition descriptions given to CIRCA’s CSM.

about time-abstract states to plan actions, and a ver-ifier that reasons about partial and complete plans toensure that they meet logical and timing safety require-ments. In this section, we briefly sketch these functionalmodules and describe an example problem that we willcarry throughout the paper, to illustrate how CIRCAuses model verification in the context of automated plan-ning and how the loop acceleration technique speeds upmodel verification.

3.1 State Space Planning

Unlike traditional AI planners, CIRCA reasons aboutuncontrollable processes including adversaries, and met-ric, continuous time. The CSM takes in a description ofthe processes in the system’s environment, representedas a set of time-constrained transitions that modify thevalue of world features. Discrete states of the system aremodeled as sets of feature-value assignments. Transitionshave preconditions, describing when they are applicable,and bounded delays, capturing the temporal character-istics of controllable processes (i.e., actions) and uncon-trollable processes (i.e., world dynamics).

Example 1. Figure 1 shows several transitions from aCIRCA problem description for controlling the Cassinispacecraft during Saturn Orbit Insertion [19,20]. In thisproblem, CIRCA must generate a controller that willturn on the main engine in time to perform the orbitalinsertion within the time window. In order for the ma-neuver to complete successfully, the spacecraft must beguided by a working Inertial Reference Unit (IRU).

The transition descriptions, together with specifica-tions of initial states, implicitly define the set of possiblesystem states. The CSM is responsible for deciding, ineach state, what action the system should take to main-tain system safety and drive the system towards its goals.For example, Figure 2 illustrates a small portion of the

State 8(ACTIVE_IRU NONE)(ENGINE ON)(IRU1 OFF)(IRU2 WARMING)

State 6(ACTIVE_IRU NONE)(ENGINE OFF)(IRU1 OFF)(IRU2 ON)

turn_on_main_engine warm_up_IRU2

State 3 **(ACTIVE_IRU NONE)(ENGINE OFF)(IRU1 OFF)(IRU2 WARMING)

start_IRU2_warm_up

State 0(ACTIVE_IRU NONE)(ENGINE OFF)(IRU1 OFF)(IRU2 OFF)

Fig. 2. The beginning of a state space plan for Saturn OrbitInsertion. In this diagram, the ellipse marks the initial state, otherstates are rectangles, and the shaded state is a goal state.

Saturn problem’s state space, after the CSM has madeonly its first few decisions about how to control the sys-tem.

The CSM reasons about both controllable and un-controllable transitions:


Action transitions represent actions selected by CIRCA;the CSM’s objective is to assign an action to eachreachable state. In Figure 2, a dashed arrow showsthat the system has chosen the action start_IRU2_-warm_up in the initial state zero. Associated witheach action is a worst case execution time, an up-per bound on the delay before the action occurs.The special “do nothing” action “no op” can alsobe used. Typically this is done when the controllerwishes to wait for some uncontrolled process to com-plete. For example, the controller might begin warm-ing up an IRU, execute no-op in the state where theprocess of warming up is ongoing, and then designatethe IRU as the active IRU, when it has completedwarming up.

Temporal (uncontrollable) transitions represent uncon-trollable processes. Associated with each temporaltransition is a lower bound on its delay. If the pre-conditions hold true for at least this time, the tran-sition may fire and enforce its postconditions. If atemporal transition leads to an undesirable state, theCSM may plan an action to preempt the temporal byensuring that the action will definitely occur beforethe temporal could possibly occur. Transitions whoselower bound is zero are referred to as events, andare handled specially for efficiency reasons. Transi-tions whose postconditions include the distinguishedproposition (failure T) are called temporal transi-tions to failure (TTFs).

Reliable temporal transitions represent continuous pro-cesses that may need to be employed by the CIRCAagent. Reliable temporal transitions have both up-per and lower bounds on their delays. For example,when CIRCA turns on an Inertial Reference Unit itinitiates the process of warming up that equipment;the process will definitely complete if it is continuedwithout interruption for some time, as shown by thesolid arrow leaving state 3 in Figure 2.

Note that each transition is an implicit description ofmany transitions in an automaton model. Each of thesetransitions is enabled in any discrete state that satisfiesits preconditions, and disabled everywhere else. We ex-plain how these implicit descriptions work more preciselyin Section 6.

Central to the controller synthesis problem is pre-emption. If a temporal transition leads to an undesir-able state, the CSM may plan an action to preempt thetemporal:

Definition 1 (Preemption). A temporal transition maybe preempted in a (discrete) state by planning an actionfor that state which will necessarily occur before thetemporal transition’s delay can elapse.

Note that successful preemption does not ensure thatthe threat posed by a temporal transition is handled; itmay simply be postponed to a later state (in general, itmay require a sequence of actions to handle a threat). A

threat is handled by preempting the temporal transitionwith an action that carries the system to a state whichdoes not satisfy the preconditions of the temporal.

3.2 CIRCA controller synthesis algorithm

Algorithm 1 (Controller Synthesis).

1. Choose a state from the set of unplanned reachablestates (at the start of state space planning, only theinitial states are reachable).

2. For each uncontrollable transition enabled in thisstate, choose whether or not to preempt it. Transi-tions that lead to failure states must be preempted.The CSM creates a boolean constraint variable forthe preemption decision for each of these uncontrol-lable transitions.

3. Choose a single control action or no-op for this state.4. Invoke the verifier to confirm that the (partial) con-

troller is safe (see below for a discussion of how theverifier is invoked on partial controllers). “Safe,” hereis defined as “does not make any transitions to thedistinguished failure state” and “successfully enforcesall of the preemption decisions made in step 2.”

5. If the controller is not safe, use a counterexamplefrom the verifier to direct backjumping and returnto step 1 [21].

6. If the controller is safe, recompute the set of reach-able states.

7. If there are no unplanned reachable states (reachablestates for which a control action has not yet beenchosen), terminate successfully.

8. If some unplanned reachable states remain, loop tostep 1.

The search algorithm maintains the decisions thathave been made, along with the potential alternatives,on a search stack. The algorithm makes decisions attwo points: step 2 and step 3. Preemption decisions areboolean: the algorithm can choose to require preemptionor not, for each uncontrollable transition leading out ofa state. The set of alternative action choices for a state isdependent on the domain description and several prun-ing heuristics that eliminate applicable but inappropri-ate actions from consideration.

Note that Algorithm 1 is implemented as an “on thefly” algorithm: it expands the reachable sub-space of thestate space during its search. Unless forced to, it doesnot expand the full (discrete) state space, which can beexponential in the size of the input problem description.

3.3 Use of verifier

The CSM uses the verifier to confirm both that failure isunreachable and that all the chosen preemptions will beenforced. The CSM uses the verifier module after eachassignment of a control action (see step 4). This means


that the verifier will be invoked before the controller iscomplete. At such points we use the verifier as a con-servative heuristic by treating all unplanned states asif they are “safe havens.” Unplanned states are treatedas absorbing states of the system, and any verificationtraces that enter these states are regarded as successful.

Treating unplanned states in this way constitutes aconservative heuristic in the sense that any detected fail-ure is definitely a true failure (soundness), but the ver-ifier may fail to identify failures that will later becomeapparent (incompleteness). At the limit, when the con-trol program is complete, the verifier will be both soundand complete.

When the verifier indicates that a controller is un-safe, it will return a path from the initial state to thedistinguished failure state. The action choices that theplanner made for the states along that path form a setof candidate decisions to backtrack and revise, as dis-cussed in [21]. If no safe plan is possible, the overallCSM may return failure, at which time the next higherlevel of CIRCA, the AMP, would try to compose a dif-ferent problem for the CSM, perhaps by omitting somegoals. The CSM algorithm will never return an unsafecontroller.

To verify safety in CIRCA plans, the CSM representsthe CIRCA control plans as timed automata. In the nextsection we review timed automata, and following that weexplain the relationship between CIRCA control plansand timed automata.

We continue to work on improving CIRCA and ap-plying it in new domains. Recent work has included re-search in using statistical verification to verify large CIR-CA plans [22] and application to on-board autonomy forsatellites [12,23].

4 Timed Automata

A timed automaton is a nondeterministic finite automa-ton (NFA) augmented with timing information [1] (ournotation has been adapted from the descriptions in [24]and [25]).

Definition 2 (Timed Automaton). A timed automa-ton A is a tuple

⟨S,si,X ,L, E , I

⟩where

1. S is a finite set of locations;2. si is the initial location;3. X is a finite set of clocks;4. L is a finite set of labels;5. E is a finite set of edges; and6. I is the set of invariants.

Each edge e ∈ E is a tuple 〈s, L, ψ, P, s′〉 where s ∈ Sis the source, s′ ∈ S is the target, L ⊆ L are the labels,1

ψ ∈ ΨX is the guard , and P ⊆ X is a set of clocks to

1 Labels are used in parallel composition of timed automata,which we do not use here.

reset. Timing constraints (ΨX ) appear in guards and in-variants. Guards dictate when the model may follow anedge, invariants indicate when the model must leave astate. In CIRCA models, all clock constraints on guardsare of the form ci > k and all clock constraints on in-variants are of the form ci ≤ k. In our models, all clockresets re-assign the corresponding clock to zero; they areused to start and reset processes.

The state of a timed automaton is a pair: 〈s, C〉.s ∈ S is a location and C : X → Q ≥ 0 is a clockvaluation, that assigns a non-negative rational numberto each clock.

A timed automaton trace is a sequence of state tran-sitions that represents the computation of a timed au-tomaton. Corresponding to any timed automaton, A, isa transition system, SA, with two types of transitions:time-elapse transitions and discrete transitions:

Definition 3 (Time-Elapse Transition). A time-elapse

transition, 〈s, C〉 t→ 〈s, C + t〉 can occur when for all t′

such that 0 ≤ t′ ≤ t, C + t′ satisfies the invariant I(s).

Definition 4 (Discrete Transition). A discrete tran-

sition, 〈s, C〉 e→ 〈s′, C ′〉, for some e ∈ E can occur whenC satisfies the guard of e, ψ(e), and C ′ satisfies the resetof e applied to C, P (e, C).

For brevity, we will refer to discrete transitions as jumptransitions or jumps in the remainder of this paper.

To understand CIRCA’s CSM graphs, the concept oftime abstraction is helpful.

Definition 5 (Time abstraction). The time abstrac-tion of a timed automaton is a non-deterministic finiteautomaton whose states correspond to the locations ofthe timed automaton, and in which there is an edge ebetween s and s′ whenever there exists s′′ and t suchthat s

t→ s′′e→ s′.

The CIRCA CSM graph is the time abstraction of aTA model of the corresponding plan. The translation ofCSM graphs to TA models is described in Section 6.

Figure 3 illustrates the timed automaton model cor-responding to our running example, the partial Saturnorbit insertion plan shown in Figure 2. Since the CSMhas not yet completed the plan in Figure 2, the timed au-tomata model has sinks at locations 4 and 5, correspond-ing to the unplanned CSM states 6 and 8. Figure 4 illus-trates the corresponding transition system reachabilitygraph, where boxes correspond to a reachable locationand clock zone, represented as a difference bound ma-trix. The reachability graph shows that locations 4 and5 are reachable, but since their corresponding states areunplanned, the verification traces halt there. The planis safe so far, since failure is not reachable.

In this paper, we will concern ourselves primarilywith reachability verification of a particular timed au-tomaton. We will be asking if it is possible for a timed


RTA-Location 0INITInvariant: ()

INITGuard: ()Resets: (4 3 2 1)

RTA-Location 2SSP-State 0Action: start_IRU2_warm_up(ACTIVE_IRU NONE)(ENGINE OFF)(IRU1 OFF)(IRU2 OFF)Invariant: (c(1) <= 1)

#<TEMPORAL fail_if_dont_burn>Guard: (c(2) >= 1000)Resets: NIL

#<ACTION start_IRU2_warm_up>Guard: (c(1) >= 0)Resets: (1 3)

RTA-Location 3SSP-State 3Action: turn_on_main_engine(ACTIVE_IRU NONE)(ENGINE OFF)(IRU1 OFF)(IRU2 WARMING)Invariant: (c(1) <= 1 c(3) <= 60)

#<ACTION turn_on_main_engine>Guard: (c(1) >= 0)Resets: (1 2)

#<TEMPORAL fail_if_dont_burn>Guard: (c(2) >= 1000)Resets: NIL

#<RELIABLE-TEMPORAL warm_up_IRU2>Guard: (c(3) >= 45)Resets: (1)

RTA-Location 5SSP-State 6Action: NIL(ACTIVE_IRU NONE)(ENGINE OFF)(IRU1 OFF)(IRU2 ON)Invariant: uninitialized

RTA-Location 4SSP-State 8 **Action: no_op(ACTIVE_IRU NONE)(ENGINE ON)(IRU1 OFF)(IRU2 WARMING)Invariant: (c(3) <= 60)

#<TEMPORAL fail_if_burn_without_guidance>Guard: (c(2) >= 1)Resets: NIL

#<RELIABLE-TEMPORAL warm_up_IRU2>Guard: (c(3) >= 45)Resets: NIL

RTA-Location 6SSP-State 10Action: NIL(ACTIVE_IRU NONE)(ENGINE ON)(IRU1 OFF)(IRU2 ON)Invariant: uninitialized

RTA-Location 1FAILUREInvariant: ()

Fig. 3. The timed automaton model corresponding to Figure 2.


RTA-State 0Location 0 = SSP-State INITInvar: ()Active clocks: NILClock zone: <=0 <=0 <=0 <=0 <=0 inf <=0 inf inf inf inf inf <=0 inf inf inf inf inf <=0 inf inf inf inf inf <=0

INITGuard: ()Resets: (4 3 2 1)

RTA-State 1Location 2 = SSP-State 0Invar: (c(1) <= 1)Active clocks: (0 1 2)Clock zone: <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0

#<ACTION start_IRU2_warm_up>Guard: (c(1) >= 0)Resets: (1 3)

RTA-State 2Location 3 = SSP-State 3Invar: (c(1) <= 1 c(3) <= 60)Active clocks: (0 1 2 3)Clock zone: <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=1 <=1 <=0 <=1 <=0 <=0 <=0 <=0 <=0 <=0 inf inf <=0 inf <=0

#<ACTION turn_on_main_engine>Guard: (c(1) >= 0)Resets: (1 2)

RTA-State 3Location 4 = SSP-State 8Invar: (c(3) <= 60)Active clocks: (0 2 3)Clock zone: <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=0 <=1 <=1 <=1 <=0 <=0 inf inf inf inf <=0

#<RELIABLE-TEMPORAL warm_up_IRU2>Guard: (c(3) >= 45)Resets: NIL

#<TEMPORAL fail_if_burn_without_guidance>Guard: (c(2) >= 1)Resets: NIL

RTA-State 5Location 1 = SSP-State FAILUREInvar: ()Active clocks: NILClock zone: <=0 <=0 <=-1 <=-1 <=0 inf <=0 <=0 <=0 <=0 <=60 <=0 <=0 <=0 <=0 <=60 <=1 <=1 <=0 <=0 inf inf inf inf <=0

RTA-State 4Location 6 = SSP-State 10Invar: uninitializedActive clocks: (0 2)Clock zone: <=0 <=0 <=-44 <=-45 <=0 inf <=0 <=0 <=0 <=0 <=60 <=0 <=0 <=0 <=0 <=60 <=1 <=1 <=0 <=0 inf inf inf inf <=0

Fig. 4. The timed automaton reachability space corresponding toFigure 2.

automaton to reach a particular location, s ∈ S. Inparticular, we will be checking the safety of a CIRCAplan by asking if a timed automaton corresponding tothe plan can ever reach the distinguished failure state.While such reachability queries are not tractable, theyare computable, and can be answered by simple graphsearch algorithms.

Algorithm 2 (Reachability Verification).

1: let openlist ← {〈si,0〉} {initial state}2: while openlist 6= ∅ do3: s← pop(openlist)4: if visited(s) then5: skip6: else if not action-assigned(s) then7: skip {For incremental verification, see below}8: else if failure(s) then9: return unsafe

10: else11: let succ ← successors(s)12: openlist ← openlist ∪ succ13: end if14: end while15: return safe

Of course, any naive attempt to apply Algorithm 2is doomed to failure. In particular, if one assumes densetime, the state space of this search may be uncountablylarge. Practical verification systems for timed automatatypically search in a space of equivalence classes of states,since the state space of any timed automaton can be re-duced to a finite number of equivalence classes [26]. Typ-ically, a verification system will collapse together multi-ple states using clock zones. In the following discussionwe will use “state” for both state and state equivalenceclass; no confusion should result since any practical al-gorithm will have to manipulate the latter, rather thanthe former.

Verification systems also employ clever techniques forreducing the number of states that must be explored, an-swering the visited query (step 4, above), and comput-ing the successor set (step 11). Furthermore, instead ofsimply returning unsafe, reachability verification sys-tems typically return a counterexample trace, that ex-hibits a path from the initial state to the failure state,and can be used for debugging. To the best of our knowl-edge, CIRCA is unique in automating the exploitation ofcounterexample traces in planning (see [21] for an expla-nation of our technique for using counterexample tracesto direct backtracking in planning search). We will re-turn to the skeletal search algorithm later and describemodifications for our planning application.

Recall that the CSM verifies partial plans during con-struction, before they are fully designed. Before the plan-ning process is complete, there will be states that do notyet have action assignments. We verify partial plans by


treating such states as safe sink states. That is the func-tion of the check in line 6 of Algorithm 2. Note that whenthe planning algorithm (Algorithm 1) is completed, allof the states will have an action assigned to them, so thefinal verification will be a full verification. The sequenceof verifications can be thought of as a fixpoint computa-tion that converges on a full TA verification of the CSMplan.

5 Difference-Bound Matrices

As mentioned in Section 4, CIRCA’s verifier reduces thesize of its search space by collapsing states to equiva-lence classes with respect to their temporal character-istics. For example, given two automata states, 〈s, C1〉and 〈s, C2〉, in the timed automata representing a CIR-CA plan graph, if the clock assignments C1 and C2 differonly in a single clock value, and that value exceeds anyedge’s test (guard or invariant) on the clock, then 〈s, C1〉and 〈s, C2〉 can be treated as members of a single equiva-lence class. Similarly, if C1 and C2 differ only in the valueof a single clock xi, and xi is only tested against 1 and 3,it may be possible to collapse C1 and C2 into equivalenceclasses based on the inequalities xi < 1, 1 ≤ xi < 2, and2 ≤ xi. Since clock values are constrained to increaseuniformly, it is also straightforward to collapse statesin which multiple clocks differ, as long as relevant con-straints are satisfied.

To support the required equality operation, the CIR-CA verifier uses the difference-bound matrix (DBM) [27,25] data structure to represent the set of clock valuesin an automata state. To understand the nature of the“fragmentation” problem and our “loop acceleration” so-lution it is helpful to understand the basics of the DBMstructure.

Each DBM is a (k+1)×(k+1) matrix D representinga clock zone for a state in the timed automaton for aCIRCA graph.D will have k clocks x1, ...xk, representingk− 1 uncontrolled transitions and the special controlledaction clock x1. For each i, Di0 is the upper bound on theabsolute value of clock xi and D0i is the lower bound onthe value of the clock xi. The other entries in the matrixrepresent bounds on the relative distance between twoclock values. For all i and j for which we have clocksxi and xj , the DBM entry Dij is the upper bound onthe difference between values of clocks xi and xj . Toallow for strict and non-strict bounds, each entry alsocontains a second symbol (0 or 1) to indicate whetherthe inequality of the bound between the clocks is strictor not. The absence of a bound between xi and xj isrepresented by ∞ in Dij . Thus, the domain, D, of theDij entries is Q× {0, 1} ∪∞.

Thus, a DBM D is a (k + 1)× (k + 1) matrix whoseentries are elements from D. A clock interpretation v sat-isfies D iff for all 1 ≤ i ≤ k, xi ≤ Di0 and −xi ≤ D0i,and for all 1 ≤ i, j ≤ k, xi−xj ≤ Dij . Although there are

more than one DBM describing any clock zone, there isan algorithm for computing an unique, canonical DBMfor any clock zone. In order to implement Algorithm 2,we must compute a successor zone for any DBM D pro-gressing over an edge e, which can by achieved by a com-bination of intersection, time-elapse, and projectionoperations on clock zones.

Note Readers with an AI or constraint programmingbackground may notice the similarity between DBMsand Simple Temporal Networks (STNs) [28]. These twodata structures represent the same class of constraints,and both support emptiness (consistency) checks, how-ever, they are implemented differently, in order to op-timize different operations. STNs are typically used inplanning and scheduling problems where a set of tem-poral variables are related together by an increasing setof constraints. These constraints accumulate as the plan-ning or scheduling problem is solved. Often there is back-tracking, which involves the removal of constraints, andoften the set of variables is not fixed: new time pointsmay be added to the network. With DBMs used in timedautomaton verification, on the other hand, the set ofvariables is typically fixed, and there is no backtrack-ing. Operations to be optimized include checking to seeif one DBM is identical to another or contains another.These checks are typically not needed in planning andscheduling applications.

6 Modeling CIRCA with Timed Automata

Recall that as part of the CIRCA controller synthesisprocess, we incrementally verify the quality of partialplans, as they are generated (see step 4 of Algorithm 1).To do so, we translate the CIRCA problem representa-tion into timed automata, which involves expanding theimplicit representation of the state space.

6.1 Translating CIRCA problems to timed automata

Recall that CIRCA controller synthesis problems areposed by providing an initial state description, and aset of transition descriptions, partitioned into volitional(controlled) and non-volitional (uncontrolled) transitions.Taken together, these specify a timed automaton, as fol-lows.

Definition 6 (CIRCA problem). A CIRCA planningproblem is a 4-tuple, P = 〈F ,V, T , i〉 In it, F = {f0...fm}is a set of state features. For each fi ∈ F , Vfi = {vi0...viki}is a set of possible values. The initial state specification,i, is a full feature assignment (see Definition 7 below).T = A ∪ U is a set of CIRCA transitions (defined

further below), that is partitioned into controllable (A)and uncontrollable (u) transitions. For historical reasons,these are sometimes referred to as volitional and non-volitional transitions.


All CIRCA problems contain a distinguished failurefeature, whose possible values are >,⊥ (true and false).Failure is always false in the initial state. Note that anysimple safety property, �φ, or �¬φ can be captured withuse of the failure feature. More complex safety propertiescan be encoded by compiling them into the transitiondefinitions, but we rarely have the need to do this.

Definition 7 (Feature Assignment). A feature valueassignment, 〈f, a〉, maps a feature to one of its possiblevalues. A feature assignment, A, is a set of feature valueassignments for a subset of F . The set of features whosevalues are specified by A is feats(A). A full feature as-signment is a feature assignment where feats(A) = F .Finally, we can project a feature assignment onto a sub-set of features, G ⊆ F : πG(A), by removing the elementsof A whose features are not in G.

Definition 8 (CIRCA transition description). ACIRCA transition is a 4-tuple, t = 〈N,P,E,∆〉. N isthe name of the transition. P , the precondition, is a fea-ture assignment, as is E, the effect of t.2 ∆ is a set oftime bounds on the occurrence of the transition, a pair,〈lb(t),ub(t)〉, of lower and upper bound, which we willdiscuss further below. For technical reasons, we requirethat P and E be inconsistent : E must assign a differentvalue to at least one of the features in P .

The set of locations of the timed automaton corre-sponding to P is defined by F and V: it is the set of allpossible full feature assignments. Each location, l cor-responds to a unique feature assignment, which we willwrite as fa(l).

To complete the construction, we need additional def-initions to translate the CIRCA transition descriptionsinto sets of transitions in the timed automaton. The firstis the definition of applicability of a CIRCA transition:

Definition 9 (Applicability of CIRCA transition).A CIRCA transition, t, is applicable at a location, l,when the feature assignment of l satisfies the precondi-tions of t: fa(l) |= P (t).3

The set of transitions that are applicable at l is app(l).We will have need of the set of uncontrollable transitionsat l, appU (l) = app(l) ∩ U .

Then we must define the translation of each CIRCAtransition to one or more edges in the timed automaton:

Definition 10 (Image of CIRCA transition). Theimage of a CIRCA transition, t, from location l, img(t, l)→l′, is the location l′ such that:

fa(l′) =(fa(l)− πfeats(E(t))(fa(l))

)∪ E(t)

2 CIRCA actually supports nondeterministic transitions thathave multiple different effect feature assignments, but for this pre-sentation we ignore that complication.

3 Because of the simplicity of the feature-value representation,for any two assignments, A1 and A2, A1 |= A2 iff A1 ⊇ A2.

I.e., the successor state is updated by the effects of t.

Definition 11 (Clocks for CIRCA transitions). Foreach uncontrollable CIRCA transition, t, we define aunique clock, c(t). Note that a single CIRCA transitionwill correspond to multiple edges in the timed automa-ton.

There is a single clock, cRTS, that governs the func-tion of all of the controlled actions.

Finally, we need the definition of a CIRCA plan, orcontroller design:

Definition 12 (CIRCA plan). A CIRCA plan for P,ΠP , is a partial function from locations of P to control-lable transitions or no-op. For brevity, we will simply useΠ in the following.

The CIRCA plan is similar to other AI planning sys-tems, and similar to deterministic Markov Decision Pro-cess policies, in assigning a single action to each state. Inthis way it diverges from the discrete controller model ofRamadge and Wonham [29] which disables some subsetof the controllable transitions for a state.

Definition 13 (Translation of CIRCA transition).The translation of a CIRCA transition, t at a location,l is:

φ(t, l) = 〈t, l, clock(t) ≥ lb(t),R(l, img(t, l)), img(t, l)〉

if t is applicable in l, otherwise nothing.

The set of clocks reset by the timed automaton edge,R(l, img(t, l)), is as follows:

1. For each uncontrolled transition, t′ that is applica-ble at img(t, l) and that is not applicable at l, addclock(t′);

2. If Π(img(l)) 6= Π(l), add cRTS.

All resets are to zero.

To complete the construction, we need to specify theinvariants of all of the locations in the timed automaton:

Definition 14 (Location invariants). The locationinvariant of l, I(l), is the following conjunction: ∧

t∈appU (l)

clock(t) ≤ ub(t)

∧XWhere X is cRTS ≤ ub(Π(l)) unless Π(l) = no-op, inwhich case X = >.

We notate the resulting translation as θ(P).

A CIRCA plan, Π, is complete if the set of locationsin its domain is a subgraph of the timed automaton thatis closed under reachability.


l1

Threatened by obstacle

Encounter obstacle

Encounter obstacle

Send message

Reach destination

Reach destination

Correct course

c1 > j

c1 > j

c2 > k

mcRTS

ncRTS

l2

Not threatened by obstacle

Fig. 5. An example of the pathological situation causing state-space fragmentation. Controlled actions are shown as dashededges, uncontrolled as solid.

6.2 Verifying CIRCA plans

In order to verify a (partial) plan, Π, we translate it intoa timed automaton (TA) model, θ(Π), using the aboveconstruction. We search the resulting model to verify theproposition ¬ � failure. We do this using an “on the fly”construction method so that we only build a reachablesubspace of the timed automaton.

As mentioned earlier, we conduct this verificationmultiple times, while constructing the plan, per our dis-cussion of incremental verification in Section 3.3. To doso, we must verify partial plans, as well as completeplans. While doing so, any state on the frontier of θ(Π)– i.e., a state that is reachable from an element of Πbut that has not yet been assigned an action or no-op, is made an absorbing state. This has the effect oftreating these states as safe havens, giving us an over-approximation of the safety of the plans, which convergeson a true verification.

7 The Problem: Reaction Loops

Some patterns of interaction between a CIRCA con-troller and its environment, in a CIRCA plan, cause statespace explosion when verifying. Hendriks and Larsen [8]refer to this state space explosion as fragmentation, be-cause it is a failure of the timed automaton verifier’sabstraction methods in which the verifier cannot exploitrepeated structure. Fragmentation occurs when a highspeed process interacts with a slow one. In control sys-tems, this typically occurs when a digital control system(fast) interacts with its environment (slow).

Examples arise in the following situations: CIRCAis controlling a system in an environment that presents

the system with repeated threats, while a slow processcarries the system towards a state where it can achieveits goals. For example, a vehicle might have to carryout small course corrections in response to obstacles inits path, while it is navigating to its destination. Seethe CIRCA-generated controller design in Figure 5. Thesystem can rapidly respond to the need for a course cor-rection, where “rapidly” means that the duration of theresponse transition is small relative to the duration ofthe process of reaching the destination, and the need forcourse corrections can also recur frequently. One morecomplication is necessary — there must be another tran-sition out of the “unthreatened” state (the one where nocourse connection is necessary), that will impose an in-variant on that state. For example, while the vehicle isnavigating smoothly, but before it has reached its desti-nation, it might wish to seize the opportunity to send amessage to base that will update information about itscurrent state.

Intuitively, what happens during verification is thatthe verifier first considers what happens if it must cor-rect its course early in the course of a traversal, andthen later, and then later, and then later, and . . . Theverifier considers every way that the clocks represent-ing the course correction processes might interact withthe clocks for the navigation process and opportunity ex-ploitation. Consider what happens during forward search,when the system considers the state where the vehicle isthreatened with collision (l1), and is navigating towardsthe destination. At this point, the clock on “reach des-tination,” c1, starts at zero. After j time units expireon this clock, the system may make a discrete transitioncorresponding to reaching its destination. If the vehicledoes not take corrective action before time k, it maycrash. More formally, when entering l1, c2 is reset tozero, and after k time units, the Crash jump is enabled.

In this threatened state, the controller takes an ac-tion to correct its course. This action has some duration,m, much smaller than j. That duration imposes an in-variant on l1; the system cannot remain in l1 more thanm time units before transitioning. Reaching the bottomlocation, l2, the controller attempts to send a message,an action that takes n time units. The maximum de-lay, n, also imposes an invariant, this time on locationl2. n is also much smaller than j. This action may suc-ceed, or the vehicle may encounter an obstacle beforen time units elapse, returning the system to l1. In theresulting state, of the system the location will again bel1, and c1 ≤ m + n. The next time around the loop,c1 ≤ 2(m + n), and so forth. When j is large relativeto m and n, the resulting number of search states inthe verifier can be very large, and can make reachabilitytesting infeasible.

The clock zone techniques for collapsing the temporalstate space [26] fail to partition the state space into asmall number of equivalence classes, and the state spacebecomes fragmented. In practice, this problem can cause


L1

L2

These two

must be the

same planner

transition, and

must have a

lower bound in

their guards.

There must be an

urgent transition

out that imposes

an upper bound

(state invariant)

on the dwell time

in L2.

Discrete

transition into

the loop.

Fig. 6. An illustration of the subgraph pattern (in the timed ab-straction graph) that provides candidates for loop acceleration inCIRCA.

CIRCA to fail to find plans in important cases — thereaction loop problem is not at all uncommon in safety-focused controllers. Note that if there is no invariant inthe second state of the loop, like the one provided by“send message,” if all we are concerned with is reachingthe destination eventually, then the pathology does notarise; clock zone techniques (based on difference-boundmatrices) are sufficient.

Note that the number of loops is not relevant tothe safety of the controller. For the purpose of checkingsafety, the only two things that matter are (1) whetherthe system can follow the “crash” transition and (2)what is the state of the clocks when it leaves the loopthrough either reaching the destination or sending a mes-sage. The first question can be answered by simple staticinspection, whether the k lower bound on crashing isgreater or less than the m upper bound on evasive ma-neuvers. We will not consider this question further inthe paper. Our focus will be on efficiently answering thesecond question, noting that the number of iterationsaround the loop, and the individual dwell times in eachlocation are of no interest in and of themselves.

8 Loop Acceleration for Reaction Loops

In this section, we discuss how we optimize away thestate space fragmentation we just described. In CIRCA’sTA verifier, while performing the search described in Al-gorithm 2, we look for instances of the pattern of statesand transitions forming a reaction loop that is a candi-date for acceleration. Then we rewrite the successors sothat we generate just three states per loop, no matterhow many iterations the loop makes, in a kind of localoptimization.

In the course of verification, our technique looks forcandidates that meet the reaction loop pattern describedin the previous section. We show an example of this pat-

tern in Figure 6. Specifically, in the forward verificationsearch, the verifier checks for states where:

1. There is a backedge from the current location, to thelocation from which the current state was reached.

2. There is a long-duration process with a lower boundon its completion time (in CIRCA terms, a temporal)that is active in both of the locations.

3. There is a CIRCA transition in the current loca-tion, other than the backedge, that imposes an upperbound (invariant) on the state dwell time.

More formally, when checking a successor, s, for loca-tion l, reached by transition t, we check the followingconditions:

1. Backedge: ∃t′|t′ = l→ l′ and t = l′ → l;2. Long duration process: There exists a CIRCA tran-

sition, T , such that

∃t′, t′′|t = l′ → l, t′ = φ(T, l), t′′ = φ(T, l′)

and the lower bound on the clock for T is “large,”where “large” is a threshold that may be set as aparameter of the optimization.

3. Upper bound on the state dwell time: I(l) 6=∞.

The presence of the backedge (1), of course, is nec-essary for there to be a loop that we can accelerate.However, while necessary, this is not sufficient. If wehave only the backedge and the long duration process(2), then the difference-bound matrices will efficientlyabstract the state space of the timed automaton, andthere will be no fragmentation. It is only if we add theseparate upper bound (3), that we encounter fragmen-tation.

In the context of the CIRCA solver, the very largeloop-related state space ordinarily generated by a reac-tion loop can be collapsed into only three states:

1. A state for the top location, entering the loop;2. A state for the bottom of the loop location and3. A state for the top location, in iterations after the

first entry.

The reason that this is possible is that we can com-pute the possible states of the various clocks upon leav-ing the loop without explicitly enumerating the statesrelating to the two clocks that control the loop proper.The loop clocks will behave the same way upon exit fromthe loop no matter how many times the loop is executed(with the exception of the first entry into the loop, whichis why we have three states, instead of two. We may rea-son by cases about all of the other clocks. During theloop, the other active clocks will be related to each other(and to the loop clocks) in one of two ways:

1. They will be synchronized (possibly with some off-set), when they enter the loop, and will stay syn-chronized or

2. They will be unconstrained with respect to each other.


Note that when we say “synchronized (possibly withsome offset)” what we mean is that the clocks will beat some bounded distance from each other — not neces-sarily zero — and that this distance will not change, nomatter how many times they go through the loop.

Which of the two possibilities — clocks stay synchro-nized, or clocks may stray an arbitrary distance — ob-tains depends on what happens when the system passesthrough the transition that corresponds to the backedge.All of the clocks that are reset by this transition will bereset to zero and will become (perfectly) synchronized.The others will be unaffected, so the relations amongthem (synchronized or not) will remain, and they willbe desynchronized from the clocks that are reset. Notethat this simplification occurs partly because of threespecial features of CIRCA timed automata:

1. Each discrete transition is controlled by exactly oneclock, with a guard that is controlled by constants.There may additionally be state invariants, that comefrom urgent discrete transitions: these are also testedagainst constants. That is, there are no constraintsthat directly relate two clocks together (although somesuch constraints may be inferred in the closure com-putations over the DBMs).

2. When a discrete transition is followed, the clock con-trolling that transition will either be reset, or willbecome inactive.

3. The verification effort aims at checking reachabilityof states (in our case, the distinguished failure state)that are not included in any loop.

These are not requirements of the TA model, but webelieve that they are common features of many controlsystems where a discrete controller must interact withtemporally-extended processes.

The DBM implementation of timed automata sub-stantially reduces the state space by reasoning efficientlywith equivalence classes of clock valuations. The combi-nation of the special features of CIRCA and the loopstructure allow us to collapse the TA state space evenfurther, and construct equivalence classes that are largerthan the ones already captured by the DBM abstraction.We may simply remove the upper bounds on any clockthat is not reset in the loop since it can grow withoutlimit until the system exits the loop. We still enforce thestate invariants imposed by transitions leaving the loop,so clock values cannot grow to values inconsistent withurgent transitions leaving the loop. We enforce the syn-chronization constraints which do not change betweenloop iterations, and thus capture the exit conditions (thestate of the clocks upon leaving the loop) very simply indifference-bound matrices. We also do a simple staticcheck to verify that the state of the system in the loopremains safe, as well.

Loop acceleration procedure The actual loop accelera-tion is done by a local, “peephole” optimization during

forward state space verification search. In Algorithm 2,when we create the successors to state, in line 11, wecheck each successor to see if it is a candidate for loopacceleration, according to the criteria outlined above. Ifthe successor is a candidate, we replace it according toAlgorithm 3. In particular, our algorithm will rewritetwo states for each loop: it will initially detect the op-portunity to accelerate when the search reaches a statecorresponding to the bottom of the loop. At that pointit will recognize the backedge and accelerate the statecorresponding to reaching the location at the bottom ofthe loop. Then it will create a second accelerated statecorresponding to returns to the top of the loop.

Algorithm 3 (Loop acceleration rewrite).

1: proc accelerate search state(s, t) {State s reachedvia t}

2: let r ← P (t) {clocks reset}3: let nr ← activeclocks(s)− r {clocks not reset}4: for all c ∈ nr do5: for all c′ ∈ r do6: desync(dbm(s), c, c′)7: end for8: {Remove upper bound: 0 ≤ c <∞}9: dbm(s)[0, c]← (0, 1)

10: dbm(s)[c, 0]←∞11: end for12: {now conduct normal DBM updates ...}13: dbm(s)← dbm(s) ∩ I(s))14: dbm(s)← elapse time(dbm(s))15: dbm(s)← dbm(s) ∩ I(s))16: if empty(dbm(s)) then17: return false {infeasible}18: else19: return true {feasible}20: end if

Recall that P is the set of clocks reset by a timedautomaton transition. I(l) is the invariant for a timedautomaton location, l; we extend it to search states byprojection: I(s) = I(l) for s = 〈l, C〉. Notation is as perDefinition 2. dbm(s) is the difference bound matrix cor-responding to the search state s. Clocks in the procedureare counting numbers; c0 represents the numerical zerovalue. The operations in lines 13-15 are the standardoperations for computing a successor difference boundmatrix, per Alur’s survey article [25].

The desync(·, ·) procedure desynchronizes its two ar-gument clocks. It does this by relaxing constraints on thedistances between the two clocks:

proc desync(dbm, c1, c2)dbm[c1, c2]←∞dbm[c2, c1]←∞The modifications of standard TA successor DBM

computations in Algorithm 3 are above line 13: clocksfor transitions that are not reset in the back-edge tran-


sitions are desynchronized from clocks that are, and ad-ditionally their upper bounds are removed. The intuitivejustification for these modifications is the case analysisabove: the desynchronization only affects the relation-ship between clocks that are reset by the back edge, andthose that are not. Clocks that are not reset will retainthe interrelationships that were established on entry intothe loop. We justify this intuition in the next section.

Example 2. Consider how the optimization would be ap-plied to the situation in Figure 5. In the verificationsearch, we encounter l1, which is processed normally:

The verifier will try to generate a successor for reach-ing the destination. The outcome of this is not of interestfor our discussion; we pass over it. Next, the verifier willattempt to generate a successor for the “Crash” state.If it succeeds, verification will terminate with a coun-terexample, so let us assume that it does not (i.e., thatm < k). Finally, the verifier will generate a successor forl2.

At this point, the verifier will detect the possibilityof loop acceleration, and will perform the modificationsdescribed in Algorithm 3 to the DBM of the correspond-ing search state. It will generate successors for reachingthe destination, and sending a message, assuming thatthey are consistent with the temporal constraints. It willalso generate a successor for the back-edge, “encounterobstacle,” that returns the system to l1. When it doesso, it will apply the same optimization to the DBM ofthe search state. It will attempt to generate out edgesas per normal, but the successor state for l2 will be rec-ognized as already closed, so no further loop states willbe generated.

The current version of CIRCA incorporates our loopacceleration technique as an option. On many scenariosthis optimization speeds up problem solving sufficientlyto make previously infeasible problems solvable. In thenext two sections, we demonstrate the correctness of thealgorithm, then present test results.

9 Proof of Correctness

In order to prove our technique correct, we must showthat it does not change the outcomes of any verification.We do this by showing that for any trace, T , passingthrough an accelerated loop, that is found by the stan-dard verification algorithm, there exists a correspond-ing trace, T ′, found by the accelerated verification algo-rithm. The correspondence preserves the clock valuationon the state immediately following the loop, ensuringthat the results of verification are preserved.

Lemma 1 (Loop acceleration equivalence). For anysub-trace,

〈lpre, Cpre〉 →(〈ltop, C0〉

δ→ 〈ltop, C1〉 →(〈l, C〉 δ→ 〈l, C ′〉 →

)∗)〈lpost, Cpost〉

found by the standard verification algorithm, there existsa corresponding path that will be found by the acceleratedverification algorithm:

〈lpre, Cpre〉 →(〈ltop, C0〉

δ→ 〈ltop, C1〉 →[〈lbot, C〉

δ→ 〈lbot, C ′〉 →(〈ltop, C ′′〉

δ→ 〈ltop, C ′′′〉 →)

?

]?

)〈lpost, Cpost〉

That is, the trace from the accelerated loop enters the lo-cation immediately outside the loop with the same clockvaluation as the un-accelerated sub-trace. Here “*” isKleene star, “?” is zero or one, l ∈ {ltop, lbot} and lpost 6∈{ltop, lbot}.

Less formally, for every path through a loop in the orig-inal model, there is a corresponding trace in the accel-erated model that ends in the same state.

Proof (Iff).

Base model path implies accelerated path: Assume thatthere exists an exit state, 〈lpost, Cpost〉, generated bythe original model that is not generated by the ac-celerated model.There are two cases:

Case 1. The path enters ltop and then exits the loopon the next discrete transition. In this case the proofis immediate, since the loop acceleration proceduredoes not change the path at all.

Case 2. The path goes at least once through the loopbefore exiting. In that case there must be some statein the loop, 〈l, C〉 for l = ltop or l = lbot, and t a dis-

crete transition, such that 〈l, C〉 t→ 〈lpost, Cpost〉 andC is not contained in the DBM of the correspond-ing accelerated search state, but C is contained inthe DBM of a standard search state. That followsbecause the transition t is not changed by the loopacceleration: if the destination state is not reachable,


and the transitions are the same, the predecessorstate must be unreachable.This is a contradiction, because the accelerated DBMsare relaxations of the corresponding base model DBMs,since the loop acceleration only removes constraints.It follows from this that any clock states contained inthe zones of the base model verifier will be containedin the zones of the accelerated model.

Accelerated path implies base model path: As in the pre-vious direction, we may ignore paths that enter onlyltop and leave the loop immediately.So we assume that there is a path that enters bothstates at least once, and then reaches 〈lpost, Cpost〉.So there must be 〈l, C〉 for l = ltop or l = lbot, and t a

discrete transition, such that 〈l, C〉 t→ 〈lpost, Cpost〉,and C is contained in the DBMs of only the acceler-ated model, and not of the base model checker.There are two ways this could happen, correspondingto the two modifications made by Algorithm 3: eitherthere are two clocks, c and c′ desynchronized by line 6that should not be desynchronized; or there is someclock, c, whose value is too high: the removal of upperbounds (lines 8-11) is incorrect.

Case 1 (Incorrect desynchronization). Without lossof generality, we assume that clock c is reset by theloop edge, and clock c′ is not, and in the acceleratedstate, c − c′ is higher than is permitted by the basemodel. This cannot happen, because lower bounds onthe transition times cannot prevent the clocks fromdiverging from each other: as the distance betweentransitions grows, the distance between clocks resetand clocks not reset only grows. Upper bounds onthe transition times in the CIRCA model, which cankeep the clocks from diverging, are not relaxed bythe loop acceleration operations.

Case 2 (Clock value too high). In this case, theremust be some clock, c, not reset by the loop, whosevalue is too high. But this cannot happen, since anyclock that is not reset by the loop will grow mono-tonically as we go around the loop. Any bounds onsuch a clock must be imposed by urgent transitionsout of the loop. But such urgent transitions imparttheir constraints as invariants on the locations, andloop acceleration does not relax invariants.

Theorem 1 (Loop acceleration preserves verifica-tion results). For all traces, t explored by the standardverification algorithm, either (a) there is a correspond-ing trace in the loop-accelerated verification algorithm,according to Lemma 1, (b) the trace is also generated bythe loop-accelerated algorithm, or (c) the trace does notreach the failure state.

Proof. We may partition the set of traces into threesubsets:

0

100000

200000

300000

400000

500000

600000

700000

800000

0 10 20 30 40 50 60 70

Veri

fier

runti

me (

ms)

Verifier run

No accelAccel

Fig. 7. The first 56 of 62 verifier runs in this single-threat domainare fairly quick even without loop acceleration. The final six runsillustrate long-duration reaction loops that cause the original ver-ifier to perform very badly; the loop-accelerated verifier continuesto perform well.

0

100

200

300

400

500

600

0 10 20 30 40 50

Veri

fier

runti

me (

ms)

Verifier run

No accelAccel

Fig. 8. Zooming in on the data in Figure 7, we can see that even inthe first 56 verifier runs, the loop-accelerated verifier outperformsthe original.

1. Traces that never enter an accelerated loop;2. Traces that enter an accelerated loop and never leave

that loop;3. Traces that enter an accelerated loop and depart.

Traces of type (1) will be generated identically by theloop-accelerated verifier, so fall into case (b). Traces oftype (2) cannot enter a failure state, because of the struc-ture of CIRCA models; ergo they fall into case (c). Tracesof type (3) have corresponding loop-accelerated traces,by Lemma 1.

Having shown that the loop acceleration procedure issound, we proceed to demonstrate its utility in the nextsection.

10 Experimental Results

Our initial evaluation of the loop acceleration techniqueindicates that it can provide tremendous benefit to the


CIRCA verification system, and rarely incurs any costthat makes it worse than the baseline verification ap-proach. For example, the graphs in Figure 7 and Fig-ure 8 show the significant improvement in verificationtime in the course of planning a controller for a repre-sentative problem domain. The planning domain mod-els a spacecraft in which a solar observing spacecraftstationed at the L1 Lagrange point must expose a sen-sitive instrument to possible damage in order to achieveits science goals. The planner searches for a controllerthat will safe the instrument before a possible solar flarecan damage it. Although flares can be detected whenthey occur, the planner must analyze the race betweenthe complete observation transition and the flare

damages instrument transition to decide whether it isnecessary to power off the instrument immediately or itcan wait until the observation has been completed. Thiscreates a “reaction loop” as described in Section 7.4

The graphs in Figure 7 and Figure 8 show the timerequired by each call to the verification subroutine (i.e.,step 4 of Algorithm 1). Each time the planner choosesa controlled action for a new state, it invokes the veri-fier to ensure that failure is not reachable in the currentpartial plan. In this case, CIRCA calls the verifier 62times in the course of planning. Every partial plan issafe. So, the plan becomes steadily larger and the verifi-cation problem becomes increasingly difficult. However,the planner’s state space size alone does not determineverification time. As we have seen, plan loops can causean explosion in the verifier’s state space. As shown inFigure 7, the verification problem becomes qualitativelymore difficult at the 57th verification. Without loop ac-celeration, the verifier state space grows from 2145 statesto 102,329 states, and the time to verify increases by afactor of 1140 (from 573 to 653,303 milliseconds). Theverifier with loop acceleration recognizes the loop, so itsruntime grows by less than a factor of two (increasingfrom 139 to 253 milliseconds). It is significant that theruntime of the unaccelerated verifier depends on the du-ration of the slowest temporal bounding the loop. In theaccelerated verifier, the runtime is unaffected by the du-ration of any transition involved in the loop. Overall, theloop-accelerated planning system builds a verified planin a total of 3.6 seconds, while the original system re-quires over 4000 seconds.5

In domains where the planner does make poor choices,creating partial plans in which failure is reachable, theloop acceleration can provide another huge benefit: thecounterexamples it produces (necessary to guide back-tracking as described in step 5 of Algorithm 1) can bedramatically shorter than those produced by the non-accelerated verifier. For example, in a variation of the

4 Source for the evaluation domain is available at http://www.

musliner.com/david/papers/sttt2013loopacceldata.html.5 Timing information was obtained by running on a Linux com-

puter with an Intel Duo2 dual core 2.4GHz CPU (4800 BogoMips)and 6 gigabytes of memory.

solar observer domain with an additional possible failurecondition, the planner makes some action choices thatcreate partial plans in which failure is reachable. Afterthe fifth action choice, the partial plan allows for theinstrument to be exposed long enough to a flare to dam-age the instrument, which is considered a domain fail-ure. The verification of this partial plan using the non-accelerated verifier required 164 seconds, expanded over20,000 states, and returned a counterexample of 20,002states. Of the 20,002 states in the counterexample, thesame two state cycle repeated 10,000 times. In contrast,the loop accelerated version completed the whole plan-ning problem in less than a tenth of a second and, onthe same fifth verification, its counterexample was justsix states long.

11 Conclusions

We have described a new loop acceleration techniquethat can dramatically speed up timed automata verifi-cation. While we have developed this technique in thecontext of CIRCA planning, it is quite general, becauseCIRCA creates practical discrete controllers that aremodeled by common timed automata forms, and resem-ble the controllers that occur in other practical domains.Our technique applies to all timed automata safety veri-fication problems that match the single-threat two-stateloop pattern we have described.6

Our work in this area is ongoing. We are working togeneralize the loop acceleration technique to applicabil-ity beyond simple two-state reaction loops. Although ourcurrent technique has substantially expanded the set ofproblems that CIRCA can solve, by speeding up a com-mon pattern, we would like to extend its applicability toproblems where instead of simple loops of states, thereare “meshes” of states created from multiple threats in-teracting with the system, potentially interleaving.

Acknowledgments

This article was supported by Office of Naval Researchcontract N0014-10-1-0188 via Carnegie Mellon Univer-sity subaward number 1140185-240250 and Air Force Of-fice of Scientific Research contract FA9550-12-1-0146 viaCarnegie Mellon University subaward number 1150105-284227. This paper does not represent the official posi-tion or opinions of the Office of Naval Research, the AirForce Office of Scientific Research, or Carnegie MellonUniversity. Thanks to Ed Koeller for collecting support-ing images and data. Thanks to our reviewers for manyhelpful questions, suggestions, and corrections.

6 Note that, while we use the term “threat,” the pattern is actu-ally more general — any case where the controller must service anoutside process that is time-pressured exhibits the same pattern.


References

1. R. Alur and D. L. Dill, “A theory of timed automata,”Theoretical Computer Science, vol. 126, pp. 183–235,1994.

2. K. G. Larsen, P. Pettersson, and W. Yi, “Model-checkingfor real-time systems,” in Proc. of Fundamentals of Com-putation Theory, no. 965 in Lecture Notes in ComputerScience, pp. 62–88, Aug. 1995.

3. G. Behrmann, J. Bengtsson, A. David, K. G. Larsen,P. Pettersson, and W. Yi, “Uppaal implementation se-crets,” in Proc. of 7th International Symposium on For-mal Techniques in Real-Time and Fault Tolerant Sys-tems, 2002.

4. G. Behrmann, A. David, and K. G. Larsen, “A tuto-rial on uppaal,” in Formal Methods for the Design ofReal-Time Systems: 4th International School on FormalMethods for the Design of Computer, Communication,and Software Systems, SFM-RT 2004 (M. Bernardo andF. Corradini, eds.), no. 3185 in LNCS, pp. 200–236,Springer–Verlag, September 2004.

5. S. Yovine, “Kronos: A verification tool for real-timesytems,” Springer International Journal of SoftwareTools for Technology Transfer, vol. 1, October 1997.

6. T. S. Hune, “Modeling a language for embedded systemsin timed automata,” Research Series RS-00-17, BRICS,Department of Computer Science, University of Aarhus,Aug. 2000. 26 pp. Earlier version entitled Modelling aReal-Time Language appeared in Fourth InternationalWorkshop on Formal Methods for Industrial Critical Sys-tems (FMICS99) pages 259–282.

7. T. K. Iversen, K. J. Kristoffersen, K. G. Larsen,M. Laursen, R. G. Madsen, S. K. Mortensen, P. Pet-tersson, and C. B. Thomasen, “Model-checking real-timecontrol programs - verifying LEGO MINDSTORMS sys-tems using UPPAAL,” in In Proc. of 12th EuromicroConference on Real-Time Systems, pp. 147–155, IEEEComputer Society Press, 2000.

8. M. Hendriks and K. G. Larsen, “Exact acceleration ofreal-time model checking,” Electronic Notes in Theoret-ical Computer Science, vol. 65, Apr. 2002.

9. D. J. Musliner, E. H. Durfee, and K. G. Shin, “CIRCA:a cooperative intelligent real-time control architecture,”IEEE Transactions on Systems, Man and Cybernetics,vol. 23, no. 6, pp. 1561–1574, 1993.

10. D. J. Musliner, E. H. Durfee, and K. G. Shin, “Worldmodeling for the dynamic construction of real-time con-trol plans,” Artificial Intelligence, vol. 74, pp. 83–127,Mar. 1995.

11. D. J. Musliner, M. J. S. Pelican, R. P. Goldman, K. D.Krebsbach, and E. H. Durfee, “The evolution of CIRCA,a theory-based AI architecture with real-time perfor-mance guarantees,” in AAAI Spring Symposium on Ar-chitectures for Intelligent Theory-Based Agents, 2008.

12. D. Kortenkamp, P. Bonasso, D. J. Musliner, M. J. S.Pelican, and J. Hostetler, “Embedding planning technol-ogy into satellite systems,” in AIAA Infotech@Aerospace,2011.

13. M. Hendriks, Model Checking Timed Automata - Tech-niques and Applications. PhD thesis, Institute for Pro-gramming research and Algorithmics (IPA), 2006.

14. A. Fietzke, E. Kruglov, and C. Weidenbach, “Automaticgeneration of inductive invariants by sup(la),” Tech. Rep.MPII2012RG1-002, Max-Planck-Institut fur Informatik,2012.

15. F. K. . Marius Bozga, Radu Iosif, “Fast acceleration of ul-timately periodic relations,” Tech. Rep. TR-2010-3, Ver-imag Technical Report, 2010. Version: 1.

16. S. Bardin, A. Finkel, J. Leroux, and P. Schnoebe-len, “Flat acceleration in symbolic model checking,”in Proceedings of the 3rd International Symposium onAutomated Technology for Verification and Analysis(ATVA’05) (D. A. Peled and Y.-K. Tsay, eds.), vol. 3707of Lecture Notes in Computer Science, (Taipei, Taiwan),pp. 474–488, Springer, Oct. 2005.

17. S. Bardin, J. Leroux, and G. Point, “FAST extended re-lease,” in Computer Aided Verification (CAV) (T. Balland R. B. Jones, eds.), vol. 4144 of Lecture Notes in Com-puter Science, pp. 63–66, Springer, 2006.

18. R. B. Salah, On Timing Analysis Of Large Systems.PhD thesis, Institut National Polytechnique De Greno-ble, Oct. 2007.

19. E. Gat, “News from the trenches: An overview of un-manned spacecraft for AI,” in AAAI Technical ReportSSS-96-04: Planning with Incomplete Information forRobot Problems (I. Nourbakhsh, ed.), American Associ-ation for Artificial Intelligence, Mar. 1996.

20. D. J. Musliner and R. P. Goldman, “CIRCA and theCassini Saturn orbit insertion: Solving a prepositioningproblem,” in Working Notes of the NASA Workshop onPlanning and Scheduling for Space, Oct. 1997.

21. R. P. Goldman, M. J. S. Pelican, and D. J. Musliner,“Guiding planner backjumping using verifier traces,” inProceedings of the Fourteenth International Conferenceon Automated Planning and Scheduling (S. Zilberstein,J. Koehler, and S. Koenig, eds.), pp. 279–286, June 2004.

22. C. M. Potts, K. D. Krebsbach, J. T. Thayer, and D. J.Musliner, “Improving trust estimates in planning do-mains with rare failure events,” in AAAI Spring Sym-posium on Trust and Autonomous Systems, 2013.

23. D. Kortenkamp, M. B. Hudson, S. Bell, D. J. Musliner,M. J. S. Pelican, J. Hamell, and P. Zetocha, “Embeddingplanning technology into satellite systems,” in Interna-tional Symposium on Artificial Intelligence, Robotics andAutomation in Space, 2012.

24. C. Daws, A. Olivero, S. Tripakis, and S. Yovine, “Thetool kronos,” in Hybrid Systems III: Verification andControl, pp. 208–219, 1996.

25. R. Alur, “Timed automata,” Tech. Rep. MS-CIS-98-10,University of Pennsylvania, 1998.

26. R. Alur, “Timed automata,” in Working Notes of theNATO-ASI Summer School on Verification of Digitaland Hybrid Systems, 1998.

27. D. Dill, “Timing assumptions and verification of finite-state concurrent systems,” in Automatic VerificationMethods for Finite State Systems (J. Sifakis, ed.),vol. 407 of Lecture Notes in Computer Science, pp. 197–212, Springer Berlin / Heidelberg, 1990.

28. R. Dechter, I. Meiri, and J. Pearl, “Temporal constraintnetworks,” Artificial Intelligence, vol. 49, no. 1–3, pp. 61–95, 1991.

29. P. J. Ramadge and W. M. Wonham, “The control ofdiscrete event systems,” Proceedings of the IEEE, vol. 77,pp. 81–98, Jan. 1989.

Documents

A Loop Acceleration Technique to Speed Up Veri cation of …rpgoldman.goldman-tribe.org › papers › loop-acceleration... · 2013-06-28 · un-augmented model. That approach would