Model checking has been used successfully to analyze concurrent, nite-state systems. ... analysis tool we are using is Symbolic Model Veri er (SMV) 8], a model checker ... In the above event, A is called a triggering condition, and B is called a when condition or an ..... Every propositional variable a can be soundly checked.
Model Checking Timing Requirements Joanne M. Atlee University of Waterloo Waterloo, Ontario
John Gannon University of Maryland College Park, Maryland
Abstract Model checking has been used successfully to analyze concurrent, nite-state systems. System properties to be veri ed are expressed as temporal logic formulae. A model checker accepts a description of system behavior (e.g., a reachability graph or a transition relation) and a system property, and through exhaustive analysis determines whether or not the property holds in the system. In this paper, we extend the Software Cost Reduction (SCR) requirements notation to specify systems' timing requirements. We describe an analysis tool that transforms timed SCR speci cations into timed reachability graphs, and show how some real-time properties can be veri ed with a symbolic model checker for branching-time temporal logic. In addition, we compare our system for analyzing SCR requirements with other model checkers that verify properties of real-time systems.
1 Introduction Software errors frequently arise from incorrect system requirements. Successful requirements acquisition requires a thorough review process in which both domain experts and implementors can participate. Research groups have developed requirements notations with precise meanings that can be read by both groups of reviewers [18, 24]. In [6, 27], we showed how one such notation, the Software Cost Reduction (SCR) requirements notation [18], could be analyzed using a model checker. In this paper, we extend the SCR requirements notation to specify systems' timing properties. We describe an analysis tool which generates the timed reachability graph of an SCR speci cation that has timing requirements and produces input for the model checker. We also compare our system for analyzing SCR speci cations with other model checkers that verify real-time properties. At present, model checkers exist for three types of temporal logics. All three types of temporal logics and representative model checkers can be used to specify and analyze timing requirements.
Branching-time temporal logic. In a logic with branching-time semantics, a formula is inter-
preted at discrete states of the system's reachability graph. In any system state, the future of a system's execution looks like a tree, where each branch represents a possible execution path. Branching-time logic formulae, when interpreted at a particular state, cannot refer to the next state since it is not known. Instead, the logic formulae must quantify over the
A previous version of this paper was presented at ISSTA'93.
1
set of possible next states. To prove that a formula is an invariant property of the software requirements, the property must be determined true for all states in the system's reachability graph. Examples of model checkers for branching-time logics include CTL [7, 9], TPCTL [16], Xesar [15], and SMV [8]; the Concurrency Workbench [10] also contains a CTL{based model checker. Linear-time temporal logic. In a logic with linear-time semantics, a formula is interpreted at discrete points in time with respect to a particular path in the system's reachability graph. The logic model being analyzed is an execution path: for each state, there exists a unique next state, thereby de ning a unique linear execution path. To prove that a formula is an invariant property of the software requirements, the property must be interpreted over all possible execution paths in the reachability graph. Model checkers exist for the TRIO [14] and RTTL [26, 25] linear-time logics. Interval temporal logic. In a logic with interval semantics, a formula is interpreted over an interval of time. For example, in Modechart [19, 21, 22], a time interval is represented by a sequence of states that is delimited by two event occurrences. The formula to be veri ed, expressed in Real-Time Logic (RTL), speci es the pair(s) of events that delimit the intervals of interest. To prove that an RTL formula is an invariant property of a Modechart speci cation, the model checker searches the system's reachability graph for all time intervals delimited by the events referenced in the logic formula and determines whether the formula is true with respect to those intervals. HMS [13] is another interval logic for which model checking algorithms have been developed, though not implemented. In a real-time system, the set of possible futures for a particular system state can depend on how the system reached that state. An execution path to the state can cause timing constraints to be unsatis able in that state, thereby disabling some of the transitions leaving the state. To distinguish between system states that have di erent future behaviors, the reachability graph of a real-time system contains duplicate nodes, where each copy of a replicated node is annotated with the same system properties but has a di erent set of future behaviors. Unfortunately, this replication of graph nodes adds to the state explosion problem that plagues reachability analysis techniques; the timed reachability graphs of some concurrent systems are so large that model checking becomes inecient. We generate and analyze timed reachability graphs that do not contain duplicate nodes. The analysis tool we are using is Symbolic Model Veri er (SMV) [8], a model checker for Computational Tree Logic (CTL) [7]. CTL has branching-time semantics, and all of CTL's temporal operators are quanti ed over the set of possible futures. For example, there are two nextstate operators, one for expressing property p in some next state and one for expressing p in all next states. Because the temporal operators are quanti ed, CTL model checkers do not always need to distinguish between system states that have di erent futures: if system state x is represented by duplicate nodes and property p is true in all the next states of all the copies of x, then p is true in all next states of x. We take advantage of the fact that CTL's temporal operators are quanti ed and construct timed reachability graphs in which each system state is represented by a single graph node. The disadvantage of this approach is that only a subset of CTL formulae can be veri ed against our compact representation of a system's timed reachability graph. To determine if we could verify interesting properties of existing system requirements, we used our extended SCR notation and analysis tool to analyze safety and timing requirements for two 2
well-known small problems: a railroad crossing system and a nuclear control rods system. These problems are often used to demonstrate the e ectiveness of real-time speci cation and veri cation techniques. For comparison, we analyzed the same problems using model checkers for TRIO (a temporal logic with linear-time semantics) and Modechart/RTL (a temporal logic with interval semantics). The three model checkers analyze reachability graphs of varying degrees of detail: the more timing information a reachability graph contains, the richer the logic that can be checked against it. However, a more detailed reachability graph usually means a larger graph, and a rich logic is not always needed to express a system's safety and real-time properties. We conclude the paper with some preliminary guidelines for choosing the most ecient model checker based on the types of properties one wants to verify.
2 SCR/SMV This section describes the Software Cost Reduction (SCR) requirements notation and the Symbolic Model Veri er (SMV). A more formal presentation of the combined SCR/SMV methodology and how it can be used to analyze behavioral requirements appears in [4, 27]. This section extends the SCR/SMV methodology to specify and verify timing requirements. System speci cation. The SCR requirements notation was developed by a research group at the U.S. Naval Research Laboratory as part of a general Software Cost Reduction project [1, 17, 18]. An SCR document speci es a software system's behavior as a nite set of concurrent, event-driven, state-transition machines called modeclasses. Each modeclass is composed of a set of modes (so named because they represent the system's di erent modes of operation) and transitions among the modes; at least one of the modes must be an initial mode of the modeclass. The modeclasses' sets of modes are nite and mutually disjoint. Informally, each modeclass describes one aspect of the system's behavior, and the global behavior of the entire system is de ned by the composition of the system's modeclasses. The system is in exactly one mode of each modeclass at all times. The system's environment is represented by a set of boolean environmental conditions1 . A primitive event is a change in value of one environmental condition: primitive event @T(A) is the event of environmental condition A becoming true, and event @F(A) represents A becoming false. A conditioned event is a primitive event whose occurrence depends on the values of other conditions [17]: @T(A) WHEN [B ] occurs if A becomes true while B is true. More formally, the event occurs at time t if (a) A is false and B is true at time t?1, and (b) A is true at time t. The model of time is discrete2. In the above event, A is called a triggering condition, and B is called a when condition or an enabling condition. Since a primitive event is a type of conditioned event (i.e., a conditioned event with vacuously true when conditions), the term conditioned event will henceforth refer to both primitive and conditioned events. Although conditions are boolean, rst-order predicate conditions that can be represented by a nite number of boolean conditions (such as integer ranges) are also expressible. 2 SCR semantics actually uses continuous-time de nitions for a conditioned event [1, 11]. For a given conditioned event @T(C1) WHEN [C2], if primitive event @T(C1) occurs at time t, then the conditioned event occurs at time t if and only if there exists a non-empty time interval such that C2 is true throughout interval [t?; t). This paper uses a discrete-time de nition of conditioned events in order to facilitate model checking. 1
3
Monitor: Current Mode NoTrain Approaching Waiting @T − BC − − Crossing − − Passed − @T Initial Mode: Waiting (NoTrain)
TrainXing
− @T @F −
New Mode BC Crossing Passed Waiting
Gate−Controller: Current Mode Up MoveDown Down MoveUp Initial Mode: Up
GateUp
Gatedown
In(BC)
In(Passed)
New Mode
t − − @T
− @T t −
@T − − −
− − @T −
MoveDown Down MoveUp Up
Relationships: NoTrain ^ Approaching ^ TrainXing ^ Departing GateUp −> ~GateDown @T(TrainXing) −> WHEN [In(BC,299)] @T(NoTrain) −> WHEN [In(Passed,99)] @T(GateUp) −> WHEN [In(MoveUp,19)] @T(GateUp) −> WHEN [~In(MoveUp,100)] @T(GateDown) −> WHEN [In(MoveDown,19)] @T(GateDown) −> WHEN [~In(MoveDown,50)]
Figure 1: SCR requirements speci cation of the railroad crossing system. Mode transitions re ect the occurrence of conditioned events that are of interest to the system. A mode transition is de ned by its source mode, its destination mode, and a conditioned event specifying condition values in the source and destination modes. If the above conditioned event triggers a mode transition from mode M1 to mode M2, then the mode transition occurs at time t if and only if the system is in mode M1, condition A is false, and condition B is true at time t?1, and the system is in mode M2 and condition A is true at time t. Consider an SCR requirements speci cation of the classic railroad crossing problem [23]. Such a speci cation would consist of two modeclasses: a MONITOR that monitors the location of the train, and a GATE-CONTROLLER that controls the position of the railroad crossing gate based on the train's location. The four MONITOR modes describe equivalence classes of train locations: (Waiting (waiting for a train), BC (Before Crossing), Crossing, and Passed). The GATE-CONTROLLER modes represent the system's knowledge of the gate's position: (Up, MoveDown, Down, and MoveUp). The initial modes of the system are Waiting and Up, assuming that the initial environmental conditions satisfy predicate NoTrain; the system is not de ned if a train is initially present. Figure 1 shows an SCR requirements speci cation for the railroad crossing problem. SCR requirements have a tabular format. The top of the table is labeled with environmental conditions that a ect the system's behavior. For example, conditions indicating the presence of an Approaching train, a train in the TrainXing, a train Departing the crossing, or NoTrain in the 4
area are predicates on the values of sensors on the train tracks. Likewise, conditions GateUp and GateDown represent the values of sensors on the crossing-gate mechanism. Each row in the table speci es an event that activates a transition from the mode on the left to the mode on the right. A table entry of \@T" (or \@F") under column C1 represents a triggering event @T(C1) (or @F(C1)); a table entry of \t" (or \f") represents a when condition WHEN[C1] (or WHEN[C1]). If the value of a condition C1 does not a ect the occurrence of a conditioned event, then the table entry is marked with a hyphen (\{"). For example, if the GATE-CONTROLLER is in mode MoveDown, the system will transition into mode Down when the gate has nished moving into the down position (@T(GateDown)). Timed system speci cation. We adapted van Schouwen's Inmode() and Drtn() functions [29] to represent state and timing constraints as boolean \environmental" conditions. A state condition speci es whether or not the system is in a particular mode. Such a condition is especially useful for synchronizing the activities of concurrent modeclasses. State conditions have format In(mode) where mode must be the name of a mode in one of the speci cation's modeclasses. A timing condition speci es whether or not the system has been in a particular mode for a particular length of time. Timing conditions have format In(mode,time) where mode is the name of a mode in a modeclass, and time is a positive integer. Timing conditions can be used either to synchronize concurrent modeclasses or to specify delay and deadline constraints on transitions. Delay constraints are speci ed using timing conditions in when clauses, and deadline constraints are expressed as negated timing conditions in when clauses. For example, the last two environmental assumptions state that a descending gate should reach the GateDown position at least 19 time units but less than 50 time units after entering mode MoveDown. Hard deadlines are timing constraints to which a system must immediately react; these are speci ed as primitive events @T(In(MoveDown,50)). A hard deadline event @T(In(Mode,T)) cannot be used to specify that the system should leave a Mode after being in that Mode for T time units. Such a mode transition would indicate that the system is both in the Mode (because In(Mode,T) is becoming true) and not in the Mode (because the transition is leaving the Mode) at the same time. We introduce the concept of timeout events to allow the speci cation of systems leaving a mode after so many time units. Timeout events are a slight variation on hard deadline events. A timeout event @TO(In(Mode,T)) occurs at time t if In(Mode,T) is false at time t?2 and true at time t?1, and if In(Mode) is false at time t. Environmental Assumptions The set of relationship declarations at the bottom of the speci cation describes constraints on the values of the environmental conditions. The syntax and semantics of the relationship speci cations are described in [3]; for the purposes of this paper, relation \?" denotes implication and relation \^" denotes a type of enumeration where the values become true in cyclical order, from left to right. For example, the rst declaration states that exactly one of the conditions representing the train's location (NoTrain, Approaching, TrainXing and Departing) is true at any time; in addition, the order in which the conditions become true is assumed to be NoTrain, Approaching, TrainXing, Departing, NoTrain, Approaching,.... 5
The other declarations state assumptions about when certain events occur. For example, the second declaration indicates that the train should not reach the crossing gate until after the system has been in mode BC for 299 or more time units (i.e., until 299 or more time units have passed since the train was rst detected). Timed reachability graph. A reachability graph is a graphical representation of the composition of concurrent modeclasses. Each node in the reachability graph models a composite mode consisting of exactly one mode from each of the system's modeclasses. A timed reachability graph is a reachability graph for a timed speci cation. Timed reachability graphs are typically much larger than un-timed reachability graphs because they distinguish between system states at di erent points in the execution. For example, composite mode BC/MoveDown would typically be modeled by at least two nodes in a timed reachability graph: one that models the system having been in component mode MoveDown for 19 time units or more (so that the timing constraint on the transition to component mode Up is satis ed), and one that models the system having been in MoveDown for less than 19 time units. We have built an analysis tool, tgraph [2, 5], that accepts a timed SCR requirements speci cation and builds a corresponding compact timed reachability graph. Unlike other timed reachability graphs, our graphs model each composite mode as a single node. For each composite mode, tgraph calculates the range of times the system could have spent in the component modes before entering the composite mode, and it uses this information to determine which transitions leaving the composite mode have timing constraints that are satis ed by some execution path. Let G = (N ; R) be a compact timed reachability graph, where N is the set of nodes and R is the transition relation. Each node N 2 N represents a composite mode, in which the system is in the set of modes N:modes, one mode per modeclass. For each component mode A 2 N:modes, NA:min and NA:max are the minimum and maximum amounts of time, respectively, the system could have spent in A before entering composite mode N . N:deadline is the maximum amount of time the system can stay in composite mode N . Each transition T = (S; e; D) 2 R represents a transition from S 2 N to D 2 N caused by the occurrence of conditioned event e. T:delay and T:deadline are the minimum and maximum amounts of time, respectively, the system must stay in source S to enable the timing constraints in the transition's event e. Values T:delay and T:deadline are calculated with respect to the amounts of time the system has spent in the source node's component modes. Consider the calculation of T:delay for a transition T = (S; e; D) 2 R. If the transition's event e has timing constraint WHEN[In(A,t)], where A 2 S:modes, then the transition is delayed until system has been in component mode A for more than t time units. Since the system could have been in A for as many as SA:max time units upon entry to node S , the transition is delayed for at least t ? SA:max +1 time units. The transition is similarly delayed if e has a timing constraint @T(In(A,t)) or @TO(In(A,t)). If the transition event e has a state constraint @T(In(A)) or @F(In(A)), then the transition event has a delay (and a deadline) of 0 time units, since the transition must occur when component A is being entered or exited, respectively. A transition has a default delay of 1 time unit, if its event has no state or timing constraints. The delay is unde ned if state or timing constraints cannot be satis ed because the system is not in the corresponding component modes. More formal de nitions of T:delay and T:deadline, which is similarly calculated, are shown in Figure 23. The notation used in Figure 2 is relaxed. Calculations are de ned for graph nodes S and D and transition T, where T = (S; e; D) 2 R Event e is considered an arbitrary set of triggering and WHEN conditions. Values 3
6
T:delay =
T:deadline =
DA :minT =
DA :min =
DA :maxT =
DA :max = S:deadline =
8 >> >> >> >> < >> >> >> >> :
MAX ( ft ? SA :max + 1 j WHEN [In(A;t)] 2 eg; ft ? SA :max + 1 j @TO(In(A;t)) 2 eg; ft ? SA :max j @T (In(A; t)) 2 eg; f0 j @T (In(A)) 2 e ^ SA :min = 0g; fundefined j @T (In(A)) 2 e ^ (A 2= S:modes _ SA :min > 0)g; f0 j @F (In(A)) 2 e ^ A 2= S:modes ^ 9G; f : (G; f;S ) 2R A 2 G:modesg; fundefined j @F (In(A)) 2 e ^ (A 2 S:modes _ 8G;f : (G; f;S ) 2R A 2= G:modes)g )
if e has state or timing constraints
1
otherwise
8 >> >> >< >> >> >:
MIN ( ft ? SA :min ? 1 j WHEN [!In(A;t)] 2 eg; ft ? SA :min j @T (In(A; t)) 2 eg; ft ? SA :min + 1 j @TO(In(A; t)) 2 eg; f0 j @T (In(A)) 2 e ^ SA :min = 0g; f0 j @F (In(A)) 2 e ^ A 2= S:modes ^ 9G; f : (G; f;S ) 2R A 2 G:modesg; )
if e has state or timing constraints
1
otherwise
8 > > > > > > > < > > > > > > > :
0
if A 2= S:modes ^ A 2 D:modes
MAX ( 1; ft + 1 j WHEN [In(A;t)] 2 eg; ft j @T (In(A; t)) 2 eg; ft + 1 j @TO(In(A;t)) 2 eg; SA :min + T:delay; fSA :min + (DB :min ? SB :min) j SB :max SA :maxg )
if A 2 S:modes ^ A 2 D:modes
undefined
otherwise
MIN ( fDA:minT j 9T;S; e : T = (S; e; D) 2Rg )
8 > > > > > > > < > > > > > > > :
0
if A 2= S:modes ^ A 2 D:modes
MIN ( 1; ft ? 1 j WHEN [!In(A;t)] 2 eg; ft j @T (In(A; t)) 2 eg; ft + 1 j @TO(In(A;t)) 2 eg; SA :max + T:deadline; fSA :max + (DB :max ? SB :max) j SB :max SA :maxg )
if A 2 S:modes ^ A 2 D:modes
undefined
otherwise
MAX ( fDA :maxT j 9T;S; e : T = (S; e; D) 2Rg ) MIN ( f0 j (S;e; D) 2R ^ e = f@F (In(A))g ^ A 2= S:modes ^ 8G;f : (G;f; S ) 2R A 2 G:modesg; f0 j (S; e; D) 2R ^ e = f@T (In(A))g ^ SA :min = 0g; ft ? SA :min j (S; e; D) 2R ^ e = f@T (In(A; t))g ^ t SA :ming; ft ? SA :min + 1 j (S; e; D) 2R ^ e = f@TO(In(A; t))g ^ t SA :ming; 1 )
Figure 2: Calculations used in construction of compact timed reachability graph. 7
Values NA:min and NA:max are calculated with respect to the delays and deadlines for transitions into node N and the minimum and maximum amounts of time the system could have spent in component mode A before entering those transitions' source nodes. Let value DA :minT be the minimum amount of time the system could have spent in mode A before entering D, only considering a single transition T = (S; e; D) 2R into node D. If A is not a component mode of D, then DA :minT is unde ned. If the system enters mode A during transition T , then the system has spent exactly 0 time units in A before entering D. Otherwise, the value of DA :minT is constrained by the amount of time the system spent in A before entering T 's source mode (which is at least SA:min time units), T 's minimum delay constraint, and any timing constraints in event e on how long the system must be in mode A before the transition is enabled. Value DA :minT is also constrained by the length of time the system has spent in other component modes B that were entered after the system entered mode A: if mode B is entered after mode A, then the time spent in B cannot be more than the time spent in A. The value DA :min is the smallest of all the values DA :minT calculated for all of the transitions into graph node D. More formal de nitions of DA :min and DA :max, which is similarly calculated, are shown in Figure 2. A graph node S 2 N will have a deadline if there is a transition that leaves the node due the occurrence of a primitive timing event; such a transition indicates that the system cannot spend more than t time units in component mode A, and therefore cannot spend more than t ? SA:min time units in composite node S (see Figure 2 for a more formal de nition of this computation). Starting with the system's initial composite modes, tgraph explores the set of potential transitions leaving each node in the reachability graph, calculating the transitions' delay and deadline constraints. An explored transition and its destination node are added to the reachability graph the transition's timing constraints are satis able. A transition T is considered to be satis able as long as both T:delay and T:deadline are not unde ned, T:delay is less than or equal to T:deadline, and T:delay is less than or equal to the source's deadline (S:deadline). Calculating the set of nodes and edges in the timed reachability graph is an iterative process that continuously updates the timing information of the nodes' component modes based on incoming satis able transitions, and determines the satis ability of transitions leaving nodes based on the nodes' current timing information. This iterative process terminates when the nodes' timing information reach a xed point and none of the unsatis ed timing constraints are any closer to being satis ed. Finally, sequences of transitions that occur at the same time (i.e., whose deadlines are 0 time units) are represented as single compound transitions from the sequence's initial source node to the sequence's nal destination node; and the individual segments that compose the sequence are removed from the reachability graph. The compact timed reachability graph for the railroad crossing problem speci ed in Figure 1 is given in Figure 3. Each node in the graph is labeled with its set of component SCR modes, its deadline, and the minimum and maximum times the system could have spent in each component mode before entering the composite mode. Each transition is labeled with its delay and deadline constraints followed by its event.
NA :min and NA :max for component mode A in composite mode N are unde ned if A 2= N:modes, and an arithmetic computation is unde ned if any of its operands is unde ned. MIN and MAX functions are de ned over integers and sets of integers, and return value unde ned if any of their operands is unde ned.
8
Waiting/Up deadline: inf
(1,inf) @T(NoTrain)
(1,inf) @T(Approaching)
Waiting: [0,0] Up: [0,inf]
Passed/Up deadline:inf
BC/MoveDown deadline: 49
Passed: [20,99] Up: [0,0]
BC: [0,0] MoveDown: [0,0]
(20,99) @T(GateUp)
(20,49) @T(GateDown)
Passed/MoveUp deadline:99
BC/Down deadline: inf
Passed: [0,0] MoveUp: [0,0]
BC: [20,49] Down: [0,0]
Crossing/Down deadline: inf (0,inf) @F(TrainXing)
(251,inf) @T(TrainXing)
Crossing: [0,0] Down: [251,inf]
Figure 3: Compact timed reachability graph for the SCR 6speci cation of the railroad crossing system.
Assertion language. The property speci cations are expressed in a subset of Computational
Tree Logic (CTL). Unfortunately, given the compact representation of our timed reachability graph, CTL model checking is not sound with respect to the entire CTL language; formulae not modeled by the speci cation can be evaluated true with respect to the timed reachability graph. Consider the following two sub-graphs: a
b d
e
d f
c
a
d
b
c
d g
e
Figure 4: (a) Traditional timed reachability graph.
f
g
(b) Compact timed reachability graph.
On the left is a sub-graph of a traditional timed reachability graph, in which system states that have di erent future behaviors are represented by multiple graph nodes. System state d is represented by three graph nodes, and the future behavior of the system in state d depends on which state preceded state d. For example, the future state is e if the preceding state was a. The sub-graph on the right is our compact representation of the same sub-graph. CTL formula AG(a ! EX (EX (f ))) states that if from state a, then it is possible to reach state f in two transitions (formula EX (f ) 9
is true if f is true in some next state). This formula is false in the traditional timed reachability graph but may be true in the compact timed reachability graph, depending on whether other transitions leaving state a also lead to states that have possible next states f. In general, the subset of CTL that can be soundly checked against a compact timed reachability graph consists of all propositional logic formulae, modal formulae containing only universally quanti ed operators, and modal formulae containing existentially quanti ed operators that are evaluated at the initial state of the model. Below is a more detailed enumeration of this subset of CTL: Every propositional variable a can be soundly checked. If p and q are propositional formulae, then EXp, EFp, EGp, and E [p U q] can be soundly checked. If f and g are either modal or propositional formulae, then !p, p&q, p j q, AXf , AFf , AGf , and A[f U g] can be soundly checked. The temporal logic formulae are evaluated with respect to a particular state in the logic model. For example X is the nextstate operator, and formula EX (AX ) is true in state si i formula is true in some (in every) successor state of si. U is the until operator, and formula E [ U ] (A[ U ]) is true in state si i along some (every) path emanating from si there exists a future state sj at which holds and is true until state sj is reached. F is the future operator, and EF (AF ) is true in state si i along some (every) path from si there exists a future state in which holds. Finally, G is the global operator, and EG (AG ) is true in state si i holds in every state along some (every) path emanating from si. Some of the properties that should hold in the railroad crossing example are AG(Crossing? > Down) AG((In(Passed)& In(Passed; 99))? > AX (In(Passed))) AG( In(ModeDown; 50)) The rst assertion is the safety property associated with the railroad crossing problem: if the train is in the railroad crossing, then the gate must be down. The second assertion states that if the train has passed the crossing but the delay constraint In(Passed; 99) has not yet been satis ed, then the MONITOR will continue to be in mode Passed in all next states. The last assertion states that the GATE-CONTROLLER should never be in mode MoveDown for 50 time units (given our environmental assumptions). tgraph will accept a set of CTL formulae to be veri ed against an SCR speci cation, and will check that all of the atomic propositions in the formulae are declared as either conditions or modes in the speci cation; it will also check that the formulae belong to the above subset of CTL. Appendix A contains proofs that model checking formulae written in the above subset of CTL is sound with respect to compact timed reachability graphs. Model checking. The tgraph analysis tool translates the timed reachability graph it generates into an SMV speci cation, which is expressed in terms of an initial state and a transition relation. The initial state speci es the initial modes of modeclasses and initial values of environmental variables. The transition relation speci es the next composite mode (i.e., the next node in the reachability graph), depending on the current composite mode and both the current and next values of the environmental variables. The environmental assumptions are translated into invariant formulae that constrain both the values and the changes to values of environmental conditions. 10
RAILROAD−CROSSING parallel GATE−CONTROLLER
MONITOR serial
serial
WAITING (0,
)
delay 100
MOVEDOWN −>BC
(20,100)
delay 300
(0, PASSED
UP
BC
−>BC
(20,50)
−>PASSED
) MOVEUP
CROSSING
DOWN
Figure 5: Modechart requirements speci cation of the railroad crossing system. The SMV model checker veri es a formula by traversing backwards through the speci cation's transition relation to construct a propositional-logic representation of . For example, to verify formula EX (f ), the veri er constructs the weakest-precondition of the transition relation with respect to f ; to verify AX (f ), the veri er constructs the negation of the weakest-precondition of the transition relation with respect to f . Veri cations of formulae with future (EF and AF ) and global (EG and AG) operators involve xed-point calculations of weakest-precondition computations [8]. The speci cation satis es the formula if and only if all of the system's initial states satisfy the formula's propositional-logic representation.
3 Modechart This section brie y describes the Modechart speci cation language and its veri er. More thorough descriptions of this system can found in [22, 28]. Timed system speci cation. Modechart requirements have a hierarchical, graphical representation. The modes of operation are represented by graph nodes, and mode transitions are represented by edges annotated with transition conditions. Each mode is either parallel, serial, or primitive. Parallel and serial nodes contain sets of child nodes. When a parallel node is entered, all of its children are entered simultaneously and executed independently. When a serial node is entered, one of its children (the initial node) is entered and only one child is executed at any time. Transitions between modes may be conditioned on the occurrence of events (e.g., mode entry or action execution), the values of predicates, or delay and/or deadline constraints. A transition activated by an event occurs at the same time as the event. A transition conditioned on delaydeadline pair (r, d) is enabled when at least r and at most d time units have passed since the transition's source mode was entered; the transition must occur after d time units have passed if no other transition from the source mode has been activated. Mode transitions are instantaneous, and it is possible for a sequence of transitions to occur in zero time units. The Modechart speci cation language is actually richer than the description presented here, but the veri er will only accept speci cations in the above format. 11
Figure 5 contains a Modechart speci cation for the railroad crossing problem. Machine mode MONITOR monitors the location of the train, and machine mode GATE-CONTROLLER controls the position of the crossing gate. The lower-level modes correspond to the modes used in the SCR speci cation of the same system. All of the transitions in the MONITOR mode are enabled by timing conditions, while those in GATE-CONTROLLER are either activated by timing conditions or by mode entry events in the MONITOR mode. The GATE-CONTROLLER transition from MoveUp to Up is annotated with timing constraint (20,100), specifying a transition delay of 20 time units and a deadline of 100 time units. The transition from MoveUp to MoveDown is annotated with !BC, indicating it is activated when the MONITOR enters BC. Delay-deadline pair (20,100) corresponds to the timing conditions In(MoveUp,19) and In(MoveUp,100) in the SCR speci cation4 , and mode entry event !BC corresponds to triggering condition @T(In(BC)). Computation graph. Modechart's veri er builds a nite computation graph representing the system's state space. Each node is labeled with the set of current system modes, the current values of state variables, the set of actions currently being performed, and a list of simultaneous events. Each edge represents a single change in the annotations of the edge's source and destination nodes (e.g., a new system mode or new variable value); thus, if multiple state changes occur simultaneously, a sequence of nodes may be entered and exited in a single time instant. For each node N, a set of potential successors and a separation graph are generated. The separation graph nodes are nodes which lie on the path from the system's initial node to N plus N's potential successors. The separation graph edges are weighted to represent timing constraints; positive weights are delays and negative weights are deadlines. A potential successor Pi is pruned from the computation graph if a transition to another potential successor Pj must activate (due to timing constraints) before any of the transitions to Pi is enabled. Let the distance between two points be the maximum sum of the weights along any path from the rst point to the second. Two nodes in the computation graph are equivalent if they have the same label, their sets of potential successors have the same labels, and the distances between the nodes and their potential successors (and vice versa) are identical. In such a case, one of the nodes is deleted from the graph and edges to it are replaced by edges to the other node. Assertion language. The Modechart veri er checks a subset of Real-Time Logic (RTL), and a user-friendly interface ensures that the formulae to be veri ed are restricted to this subset of RTL. There are two sets of operators which specify assertions about modes and mode entry events, respectively. We only de ne the meanings of the formulae used in our case studies. An M-interval is a set of consecutive nodes in a computation graph, each of which is labeled with system mode M. The following formulae state relationships between M-intervals. cm M1 M2 evaluates to true if and only if each M1-interval contains a subsequence which represents an M2-interval. xm M1 M2 evaluates to true if and only if there is no overlap between any M1-interval and M2-interval. et M1 gives the minimum and maximum times the system spends in all its M1-intervals. In this paper, one time unit is subtracted from SCR delay constraints so that a transition annotated with a delay constraint is enabled at the same time as a transition annotated with the \equivalent" Modechart delay. 4
WHEN
12
An MN-interval is a set of consecutive nodes in a computation graph that starts with a mode entry event into mode M and ends with a mode entry event into mode N. The second set of assertions supported by the Modechart veri er express relationships between MN-intervals. One such formula is iu.
iu !M1 !M2 !M3 !M4 evaluates to true if and only if every (xth) M1M2-interval is contained within some (yth) M3M4-interval.
The safety assertion we want to verify in the railroad crossing example (that the gate is down if the train is in the railroad crossing) can be expressed as either a cm formula or a iu formula. cm(Crossing, Down) iu(!Crossing, !Passed, !Down, !MoveUp) The rst formula states that every Crossing-interval is contained within a Down-interval. The second formula states that every interval delimited by entry events into modes Crossing and Passed is contained within an interval delimited by entry events into modes Down and MoveUp. Model checker. The decision procedures for RTL formulae are graph-search algorithms. For example, the decision procedure for xm M1 M2 sequentially searches the computation graph nodes for all M1-intervals. For each of these, recursive searches locate all subsequent and prior M2-intervals. The distances between the entries and exits of each pair of M1- and M2-intervals are compared to determine if any of the intervals overlap5.
4 TRIO This section brie y describes the TRIO logic and model checker. More thorough descriptions of this system can be found in [12, 14]. Timed system speci cation. A TRIO timed system speci cation is a history speci cation that represents a possible execution of the system. Variables, predicates, and functions are either time-independent (i.e., their values are constant) or time-dependent (i.e., their values change over time). The history speci cation assigns invariant values to time-independent variables, predicates, and functions; and for each time-dependent variable and predicate, it assigns values for each time instant in the temporal domain. Figure 6 depicts a TRIO history speci cation for one execution of the railroad crossing system. The speci cation uses the boolean and temporal domains and consists entirely of time-dependent predicates. There is a time-dependent predicate for each of the MONITOR modes (Waiting(), BC(), Crossing(), and Passed()), each of the GATE-CONTROLLER modes (Up(), MoveDown(), Down(), and MoveUp()), each of the four possible locations of the train (notrain(), approaching(), trainxing(), and departing()), and each of the stable positions of the crossing gate (gatedown() and gateup()). The horizontal lines in Figure 6 depict the time instances when each predicate is true. For example, predicate Waiting() is true during time intervals 0{1, 510{520, and 990{991. One can see that the system cycles among the modes in the two modeclasses (MONITOR and 5 The decision procedure for xm M1 M2 cannot simply search for nodes annotated with both M1 and M2.
Mode entry and exit events may occur within a sequence of simultaneous events; thus, there may be graph nodes that represent the time instant that M1 (or M2) is being entered or exited but that are not labeled with M1 (or M2).
13
Waiting() BC() Crossing() Passed() Up() MoveDown() Down() MoveUp() notrain() approaching() trainxing() departing() gateup() gatedown()
0
100
200
300
400
500
600
700
800
900
1000
Figure 6: A TRIO history speci cation for the railroad crossing system. GATE-CONTROLLER), and that exactly one mode in each of the two modeclasses is true all all times, except during a mode transition when both the source and then destination modes are true. Assertion language. TRIO is a rst-order logic language, extended with temporal operators Futr and Past that de ne the truth of predicates in the future and past, respectively. TRIO terms are de ned inductively. Every variable is a term. Every n-ary function applied to n terms is a term. TRIO formulae are also de ned inductively. Every n-ary predicate applied to n terms is a formula. If A and B are formulae, then :A and A ^ B are formulae. If A is a formula and x is any time-independent variable, then 8xA is a formula. If A is a formula and t is a temporal term, then Futr(A; t) and Past(A; t) are formulae. Futr(A; t) means that formula A will be true t time units in the future. Past(A; t) is de ned similarly. A number of other temporal operators can be de ned in terms of the Futr and Past operators [14]; the operators used in this paper are: AlwF (A) =def 8t((t > 0 ^ Futr(true; t)) ! Futr(A; t)) AlwP (A) =def 8t((t > 0 ^ Past(true; t)) ! Past(A; t)) Always(A) =def AlwP (A) ^ A ^ AlwF (A) Sometimes(A) =def :AlwP (:A) _ A _ :AlwF (:A) 14
Lasted(A; t) =def 8t0(0 < t0 < t ! Past(A; t0)) Until(A1; A2) =def 9t(Futr(A2; t) ^ (8t0(0 < t0 < t ! Futr(A1; t0)) The rst two operators state that A will hold in every future time instant and that A was true in every past time instant, respectively. Always(A) means that A holds in all time instances of the temporal domain, and Sometimes(A) means that A holds in some time instant of the temporal domain. Lasted(A; t) means that A has been true for the last t ? 1 time instances, not including the current time instant. As demonstrated above, TRIO is at least as expressive as temporal logic since the latter's operators (e.g., AlwF (A) and Until(A1; A2)) can be de ned in the former. The following TRIO formulae represent some of the invariant properties that should hold in the railroad crossing example. Always(Crossing() ! Down()) Always((MoveDown() ^ :(Lasted(MoveDown(); 20))) ! Futr(MoveDown(); 1)) Always(:(Lasted(MoveDown(); 50))) The rst TRIO formula is the railroad crossing safety property: if the train is in the Crossing() then the gate must be Down(). The second formula states that if the system is in mode MoveDown() but has not been in that mode for the last 19 time units, then the system will still be in mode MoveDown() in the next time instant. The third formula states that the system will never be in mode MoveDown() for 50 consecutive time units. Model checker. Model checking of TRIO formulae is decidable if all of the speci cation's domains, including the temporal domain, are nite. A version of the tableaux algorithm is used to evaluate a formula with respect to a single state (representing an instant of time) of the history speci cation. To verify a formula over the entire history speci cation, the model checker must check the formula against all time instances, which is why the temporal domain must be nite.
5 Case Studies To evaluate the di erent types of model checkers, we used the SCR/SMV, Modechart, and TRIO veri cation systems to analyze two existing requirements speci cations. The railroad crossing speci cation used in this study was originally speci ed using Petri nets [23], and was adapted to Modechart in [28]; we created equivalent SCR and TRIO speci cations. The speci cation for the nuclear rods control system was originally speci ed as a set of RTL formulae [20]; from these formulae we produced SCR, Modechart, and TRIO requirements. Railroad crossing. The SCR system speci cation for the railroad crossing example was displayed previously in Figure 1. This system's MONITOR and GATE{CONTROLLER modeclasses are so tightly coupled that the system's reachability graph is virtually a simple cycle. For example, the Modechart computation graph contains 13 nodes, only one of which has more than a single successor. Thus, verifying this speci cation was quite straightforward. The most important formula to verify is the safety property: if the train is in the railroad crossing, then the gate must be down. This property is expressed by the following assertion: AG(Crossing ! Down) (S 1) In addition, the speci cation has several delay and deadline constraints due to environmental assumptions. The following assertions express invariant transition delays: if there is a delay constraint on a transition and that amount of time has not yet passed, then the transition is not 15
allowed. For example, assertion (S 2) states that all transitions leaving MoveDown are delayed until the system has been in MoveDown for 19 time units.
AG((MoveDown & In(MoveDown; 19)) ! AX (MoveDown)) (S 2) AG((MoveUp & In(MoveUp; 19)) ! AX (MoveUp)) (S 3) AG((BC & In(BC; 299)) ! AX (BC )) (S 4) AG((Passed & In(Passed; 99)) ! AX (Passed)) (S 5) The following two assertions express invariant deadline requirements: if there is a hard deadline constraint of t time units on a transition, then the system never stays in the source mode of that transition for t time units. For example, assertion (S 6) states that the system is never in mode MoveDown for 50 time units. AG(!In(MoveDown; 50)) (S 6) AG(!In(MoveUp; 100)) (S 7) All of the safety and timing properties listed above were successfully veri ed using the SMV model checker. The Modechart system speci cation of the railroad crossing example was shown in Figure 5. Either of the following two assertions could have been used to express system's safety property. Assertion (M 1) states that every Crossing-interval is contained within a Down-interval. Assertion (M 2) states that every interval that starts with an entry into mode Crossing and ends with an entry into mode Passed is contained within an interval that starts when Down is entered and ends when MoveUp is entered. cm(Crossing; Down) (M 1) iu(! Crossing; ! Passed; ! Down; ! MoveUp) (M 2) One can verify delay and deadline constraints using the veri er's et command, which determines the minimum and maximum times the system spends in any mode. The Modechart veri er calculated the following bounds on the length of time the system could spend in modes BC, Passed, MoveDown, and MoveUp. et(BC ) = [300; inf] (M 3) et(Passed) = [100; inf] (M 4) et(MoveDown) = [20; 50] (M 5) et(MoveUp) = [20; 100] (M 6) The TRIO history speci cation that we analyzed (which only represents one possible execution path) was depicted in Figure 6. The system's safety property is expressed by the following TRIO formula:
Always(Crossing() ! Down())
(T 1)
The formula states that whenever predicate Crossing() is true, predicate Down() must be true. This formula is valid in the history speci cation we chose to analyze. We were also able to verify the following delay constraints. 16
Manager: Current Mode Stable
In(S1None)
In(S2None)
In(S1Req)
In(S2Req)
− − @T @T − −
− − − − @T @T
@T − − − f t
− @T f t − −
Grant1 Grant2
New Mode Grant1 Grant2 Stable Grant2 Stable Grant1
Initial Mode: Stable
SubSys1:
Current Mode S1None S1Check S1Req S1RecGrant S1MoveRod
0) d,2 ,5) ) eRo v 1 o d nt1 nt1 e dy1 t ne1 n(S1M Gra Gra eck But In( Do In( Rea I Ch f − @T − − − − − − @T − − − − @T − − − − − − − − − − @T − − − − − − @T − − − − − − − − @T − − − − − − @TO on1
New Mode S1Check S1Req S1RecGrant S1MoveRod S1None S1None
Initial Mode: S1None
SubSys2:
Current Mode S2None S2Check S2Req S2RecGrant S2MoveRod
0) d,2 ,5) ) eRo v 2 o d nt2 nt2 2 ton hecke eady2 ne2 n(S2M Gra Gra ( ( o n n I But I D C R I − − @T − − − f − − − − − @T − − − @T − − − − − − − − − @T − − − − − − − @T − − − @T − − − − − − − − − @TO
New Mode S2Check S2Req S2RecGrant S2MoveRod S2None S2None
Initial Mode: S2None
Figure 7: SCR speci cation of the nuclear rods control system.
Always((BC () ^ :Lasted(BC (); 300)) ! Futr(BC (); 1)) Always((Passed() ^ :Lasted(Passed(); 100)) ! Futr(Passed(); 1)) Always((MoveDown() ^ :Lasted(MoveDown(); 20)) ! Futr(MoveDown(); 1)) Always((MoveUp() ^ :Lasted(MoveUp(); 100)) ! Futr(MoveUp(); 1))
(T 2) (T 3) (T 4) (T 5)
Formula (T 2) states that if predicate BC() is true but has not been true for the last 300 consecutive time units, then predicate Crossing() cannot be true in next time unit. The other formulae are similarly structured. We were also able to verify the following deadline constraints.
Always(:Lasted(MoveDown(); 50)) (T 6) Always(:Lasted(MoveUp(); 100)) (T 7) These formulae state that the system is never in a mode passed its deadline. Nuclear control rods. The nuclear control rods system regulates the movement of two control rods in a nuclear reactor. The SCR and Modechart speci cations for this problem are shown in Figures 7 and 8. Both speci cations consist of three modeclasses running in parallel: modeclasses SUBSYS1 and SUBSYS2 describe the subsystems that operate the two control rods, and modeclass 17
NUCLEAR RODS parallel
SUBSYSTEM 1
MANAGER
serial
serial
serial
(1, 1)
MStart
S1Check
(0, infinity)
S1Req
(Grant1==false)
Stable
(1, 20)
(req1)
Action R1: req1 = true
S2None
(1, 1)
S2Check
(0, infinity)
S2Req
(Grant2==false)
(req2)
(req1)
(req2)
Grant1 Action G1: req1 = false
Grant2 Action G2: req2 = false
(1, 20)
S1None
SUBSYSTEM 2
Action R2: req2 = true S2Wait
(Action R2 done)
(−>Grant1)
S2RecGrant
(−>Grant2)
(0, 5)
S2MoveRod
(0, 5)
S1Wait
(Action R1 done)
S1RecGrant
S1MoveRod
(30, 30)
(30, 30)
Figure 8: Modechart speci cation of the nuclear rods control system. MANAGER coordinates the operation of the two subsystems to ensure that the control rods never move at the same time. The MANAGER modeclass consists of four modes: MStart6, Stable (no rods are moving), Grant1, and Grant2. The modes for modeclass SUBSYS1 are: S1None, S1Check (run tests to ensure that it is safe to move the rod), S1Req (request permission to move rod), S1Wait (wait until permission is granted from the MANAGER process), S1RecGrant (receive permission to move rod), and S1MoveRod. Modeclass SUBSYS2 has the same modes as modeclass SUBSYS1, pre xed with S2 rather than S1. The original speci cation included a safety property that stated the two control rods could not move at the same time.
AG( (S 1MoveRod & S 2MoveRod))
(S 8)
In addition to the above assertions, we were able to verify several related invariant properties.
AG( (S 1RecGrant & S 2RecGrant)) AG(S 1RecGrant ! Grant1) AG(S 2RecGrant ! Grant2) AG(S 1MoveRod ! Grant1) AG(S 2MoveRod ! Grant2)
(S 9) (S 10) (S 11) (S 12) (S 13)
Assertion (S 9) states that the two subsystems cannot receive permission to move their rods at the 6 Mode MStart is only used in the Modechart speci cation; it is needed to ensure that the ui assertions we want to verify are preserved along all cycles in the system's computation graph. This concept is discussed further in Section 6.
18
same time. Assertions (S 10) and (S 11) each state that if a subsystem has received permission to move its rod, then the MANAGER has granted such permission. Finally, the last two assertions state that if a subsystem is moving its rod, then the MANAGER has granted the subsystem permission to do so. The original speci cation also stated that several timing constraints must hold invariantly.
AG(In(S 1MoveRod; 20) ! AX (S 1None)) AG(In(S 2MoveRod; 20) ! AX (S 2None)) AG(In(Grant1; 5) ! (S 1MoveRod j S 1None)) AG(In(Grant2; 5) ! (S 2MoveRod j S 2None))
(S 14) (S 15) (S 16) (S 17)
Assertions (S 14) and (S 15) state that the system leaves MoveRod modes after 20 time units, if not before. Assertions (S 16) and (S 17) state that a subsystem must start moving its rod 5 time units upon receiving permission to do so; otherwise, it must abort its request. All of the above formulae were successfully veri ed with the SMV model checker. The Modechart veri er assertions that correspond to the nuclear systems' safety assertions are
xm(S 1RecGrant; S 2RecGrant) xm(S 1MoveRod; S 2MoveRod) cm(S 1RecGrant; Grant1) cm(S 2RecGrant; Grant2) cm(S 1MoveRod; Grant1) cm(S 2MoveRod; Grant2)
(M 7) (M 8) (M 9) (M 10) (M 11) (M 12)
Formulae (M 7) and (M 8) state that the subsystems' RecGrant and MoveRod modes are mutually exclusive (i.e., the two subsystems cannot both be in mode RecGrant or both be in mode MoveRod at the same time). Formulae (M 9) and (M 10) state that all instances of RecGrant are contained within an instance of the appropriate Grant mode. The last pair of formulae state that all instances of MoveRod are also contained within an instance of the appropriate Grant mode. None of these safety properties could be checked with the version of the veri er we used7. We were able to verify all of the system's timing constraints, using the et operation to calculate the minimum and maximum times the system spent in modes Grant, RecGrant, and MoveRod. et(Grant1) = [30; 30] (M 12) et(Grant2) = [30; 30] (M 15) et(S 1RecGrant) = [0; 5] (M 13) et(S 2RecGrant) = [0; 5] (M 16) (M 17) et(S 1MoveRod) = [1; 20] (M 14) et(S 2MoveRod) = [1; 20] The TRIO history speci cation that we analyzed is depicted in Figure 9. We were able to verify all of the following TRIO formulae, which represent the system's safety properties. We used a version of the Modechart veri er which was dated February 1993. We aborted each veri cation attempt after 600 cpu minutes. We do not know whether the veri er would have terminated had we waited longer. 7
19
Stable() Grant1() Grant2() S1None() S1Check() S1Req() S1Wait() S1ReqGrant() S1MoveRod() S2None() S2Check() S2Req() S2Wait() S2ReqGrant() S2MoveRod()
0
100
200
300
400
500
600
700
800
900
1000
Figure 9: A TRIO history speci cation for the nuclear rods control system.
Always(:(S 1MoveRod() ^ S 2MoveRod())) (T 8) Always(:(S 1RecGrant() ^ S 2RecGrant())) (T 9) Always(S 1RecGrant() ! Grant1()) (T 10) Always(S 2RecGrant() ! Grant2()) (T 11) Always(S 1MoveRod() ! Grant1()) (T 12) Always(S 2MoveRod() ! Grant2()) (T 13) Formulae (T 8) and (T 9) state that the system cannot be in the two MoveRod or the two RecGrant modes simultaneously. The next four formulae state that the SUBSYS modeclasses cannot be in their respective RecGrant or MoveRod modes unless the MANAGER modeclass is in the associated Grant mode. We were also able to verify all the required delay and deadline constraints. Always(Lasted(S 1MoveRod(); 20)? > Futr(S 1None())) (T 14) Always(Lasted(S 2MoveRod(); 20)? > Futr(S 2None())) (T 15) Always(Lasted(Grant1(); 5) ! (S 1MoveRod() j S 1None())) (T 16) Always(Lasted(Grant2(); 5) ! (S 2MoveRod() j S 2None())) (T 17) Formulae (T 14) and (T 15) state that the system always stops moving its rods after 20 time units. The last two formulae state that within 5 time units of receiving permission to move its rod, a subsystem must start moving the rod or must abort the request. 20
6 Comparison Each of the systems used in the above experiments have their strengths and weaknesses. Based on our experiences in running these case studies, we make the following comparisons. Property speci cation. Speci cation of RTL properties is fairly straightforward because assertions are automatically translated into logic formulae. In addition to making property speci cation easier, the assertions restrict the type of RTL one can input to the respective veri ers. More expertise is needed to formulate CTL and TRIO property speci cations, since one needs to be pro cient at formulating rst-order logic expressions. RTL and TRIO are real-time temporal logics which permit the expression of quantitative properties about delays and deadlines; their veri ers include notions of time. For example, the Modechart veri er responds to et(Passed) by calculating the minimum and maximum times the system ever remains in mode Passed. In contrast, CTL is a propositional temporal logic with no notion of real-time in the logic; its model checker is only capable of verifying temporal boolean formulae. While the names of state and timing conditions imply that they possess some concept of time, they do not. They are simply the names of boolean conditions. Thus, we can only verify real-time formulae that reference those state and timing conditions that appear in the SCR tabular requirements. For example in the railroad crossing problem, we can verify that whenever the system enters mode Passed, it remains in that mode for at least 100 time units; we can verify this property because the speci cation contains timing condition In(Passed,99). We cannot verify that the system remains in Passed for at least 50 time units under these same circumstances because the appropriate timing condition does not appear in the tabular speci cation. System speci cation. SCR and Modechart system speci cations are fairly easy to create and to understand because both speci cation languages are based on extended nite state machines. The Modechart speci cation language is especially convenient because one can specify persistent state variables and actions to be performed upon mode entry. However, since the veri cation formulae can only reference modes and mode entry events, no analysis can be performed on the values of variables or the status of actions. Furthermore, there is a problem with the semantics of Modechart that allows a state variable to be both true and false in the same time instant (in di erent nodes along a zero-time path)8. Also, a transition's timing constraints can only depend on how long the system has been in the transition's source mode; one cannot annotate a transition A!B with a delay or deadline constraint on how long the system has been in a third mode C. The most dicult aspect of using the Modechart speci cation language is that it is possible to write speci cations that cannot be veri ed. For example, cm and xm formulae cannot be veri ed if one of a system's modeclasses remains in one of the modes forever while another modeclass makes progress. This is possible if the system's speci cation has in nite deadlines on transitions. Furthermore, MN-interval formulae such as iu can only be veri ed if the mode intervals referenced by the formula are preserved along every path and every cycle in the computation graph. For Our initial Modechart speci cation for the nuclear control rods system contained a zero-time transition cycle (which went undetected). We had assumed that actions R1 and R2 (which respectively assign request variables req1 and req2 the value true) would cause delays in the sub-system cycles because actions cannot be performed in zero time units; action R1 (R2) is started when mode S1Req (S2Req) is entered, and mode S1Req (S2Req) cannot exit until action R1 (R2) terminates. However, if the action terminates at the same time as mode S1Req is entered (i.e., if zero time units have passed since mode S1Req last exited), then the transition out of S1Req is still enabled and the action is not restarted. We added a one unit time delay to the transition from MoveRod to None to remove the zero-time cycle. 8
21
example, an interval formula is not preserved in a cycle if the beginning endpoint of an interval occurs before the cycle, and if the end of the interval and beginning of the next interval occur within the cycle: after every traversal of the cycle, the beginning endpoint of the interval will have occurred once more often than the terminating endpoint of the interval. The use of unique initial modes helps to avoid unpreserved interval formulae in most cases; we added initial mode MStart into the MANAGER modeclass of the Modechart speci cation of the nuclear rods example to ensure that iu assertions about rod movements would be preserved. However, the introduction of unique initial modes sometimes causes other interval formulae that originally were preserved to become unpreserved. TRIO system speci cations (execution paths) are conceptually simple to create, but the process is time consuming and prone to error because the speci cations are created manually. Reachability graph. The greatest di erence between SCR/SMV, Modechart, and TRIO analyses is the representation of the speci cations' reachability graphs. A TRIO history speci cation is an execution path that consists of one node per time unit. Each node speci es which predicates are true at that time unit. The size of the speci cation is bounded by the number of time instances the human veri er chooses to analyze. In a Modechart computation graph, each edge represents a single event or a single change in the system state. If multiple state changes occur simultaneously, these changes are represented by a sequence of nodes that are traversed in zero time units. Furthermore, the same system state (de ned by the current modes, variable values, and active actions) may be replicated, where each copy of the state has a di erent set of future behaviors because a di erent set of timing constraints are satis able in that node. As a result, the size of the computation graph explodes whenever the system consists of loosely coupled processes. The nuclear control rods system, for example, contains two subsystem modeclasses that operate asynchronously; the computation graph for this system consisted of 2525 good nodes, 17,683 total nodes, and 26,204 edges9. In an SCR compact timed reachability graph, each transition represents a compound state change. If multiple events occur simultaneously or if multiple transitions are concurrently activated by the same event, all the resultant state changes are collapsed into a single compound transition. In addition, each system state is represented by a single node in the system's timed reachability graph. The result is a more compact representation of the reachability graph: the reachability graph for the nuclear control rods system consisted of 16 nodes and 40 edges. Analytical ability. The timed reachability graph that we generate from SCR speci cations has a compact representation in which each system state is represented by one graph node. The disadvantage of compacting all of the system's behavior into this reduced state space is that the SMV model checker is no longer sound with respect to the entire CTL language. To ensure that assertions-to-be-veri ed belong to the checkable subset of CTL, the assertions are included in the SCR speci cation and their well-formedness is checked by tgraph. Appendix A contains proofs that the SMV model checker is sound with respect to this subset of CTL and compact timed reachability graphs. In a Modechart computation graph, the precise length of time a mode has been active is always known because a di erent graph node is used to represent each equivalence class of the possible system states. Since information about how long a mode has been active is retained in the computation graph, time bounds can be computed. For example, formula et M1 gives the minimum We list the number of total nodes in the computation graph because some of the veri cation algorithms search through all of the nodes and edges. 9
22
and maximum times the system spends in mode M1 in a Modechart speci cation. However, such minimum and maximum times are bounded by the delay and deadline constraints on its transitions, and SCR/SMV analysis can verify invariant delay and deadline constraints. The biggest problem we had using the Modechart veri er was the veri er's response time. On small examples like the railroad crossing system, the response time was negligible. The veri er also responded quickly when calculating timing properties of the nuclear control rods system. However, we were not able to check M-interval and MN-interval formulae against the nuclear control rods speci cation. A TRIO history speci cation explicitly states which predicates are true at every point in time. In addition, TRIO assertions can reference the value of a predicate at any point in time. For example, one can ask if a predicate A has been true for the last 10 time units (Lasted(A,10)), the last 20 time units (Lasted(A,20)), etc. In contrast, the generated SMV speci cation contains no timing information. Imprecise (but accurate) timing information is used to construct the timed reachability graph; but this information is discarded when the system's reachability graph is transformed into input to the SMV model checker. As a result, arbitrary formulae about time cannot be veri ed against an SCR speci cation. Only assertions that reference timing conditions that have been declared in the system speci cation (e.g., In(MoveDown,50)) can be veri ed. In the above experiments, this capability was sucient.
7 Conclusion One surprising lesson learned from these experiments is that a real-time analysis tool is not always needed to analyze real-time properties. All the safety and timing properties one wanted to verify in the railroad crossing and nuclear rods examples could be veri ed with respect to the systems' compact timed reachability graphs using the SMV model checker. We have demonstrated that generating a system model using time to eliminate illegal paths and performing untimed checks of system properties on the resulting graph is interesting and potentially more ecient, if one is only interested in \qualitatively timed" properties. The type of analysis tool one needs depends on the types of formulae one wants to verify. If one wants to verify safety assertions and invariant delay and deadline requirements, the most ecient analysis technique is to generate the system's compact timed reachability graph and to analyze the graph using SMV. If one is not concerned with verifying safety properties and is most interested in a tool that calculates time bounds (as opposed to verifying time bounds), then one should generate the system's computation graph and use the Modechart veri er. If one wants to verify safety assertions, liveness assertions, and complex timing requirements, then one will need to generate a timed reachability graph (with replicated nodes) and use a model checker for a real-time logic such as TRIO or RTTL.
Acknowledgement D.A. Stuart, C.L. Heitmeyer, and D. Labaw made valuable technical contributions. We are especially indebted to R. Gerber for discussions on the soundness of model checking CTL formulae against compact timed reachability graphs.
23
References [1] T. Alspaugh, S. Faulk, K. Britton, R. Parker, D. Parnas, and J. Shore. Software Requirements for the A-7E Aircraft. Technical report, Naval Research Laboratory, March 1988. [2] J. Atlee. Automated Analysis of Software Requirements. PhD thesis, Department of Computer Science, University of Maryland, 1992. [3] J. Atlee. \The Non-simultaneity of SCR Events, February 1996. Presented at the Fifth International SCR Workshop. [4] J. Atlee and M. Buckley. \A Logic-Model Semantics for SCR Software Requirements". In Proceedings of the International Symposium on Software Testing and Analysis, 1996 (to appear). [5] J. Atlee and J. Gannon. \Analyzing Timing Requirements". In Proceedings of the International Symposium on Software Testing and Analysis, pages 117{127, June 1993. [6] J. Atlee and J. Gannon. \State-Based Model Checking of Event-Driven System Requirements". IEEE Transactions on Software Engineering, 19(1):24{40, January 1993. [7] M. Browne. Automatic Veri cation of Finite State Machines Using Temporal Logic. PhD thesis, Department of Computer Science, Carnegie Mellon University, 1989. [8] J. Burch, E. Clarke, K. McMillan, D. Dill, and J. Hwang. \Symbolic Model Checking: 1020 States and Beyond". In Proceedings of the 5th Annual Symposium on Logic in Computer Science, pages 428{439, June 1990. [9] E. Clarke, E. Emerson, and A. Sistla. \Automatic Veri cation of Finite State Concurrent Systems Using Temporal Logic Speci cations". ACM Transactions on Programming Languages and Systems, 8(2):244{263, April 1986. [10] R. Cleaveland, J. Parrow, and B Ste an. The Concurrency Workbench: Operating Instructions. Technical Report 10, Laboratory for Foundations of Computer Science, University of Edinburgh, 1988. [11] P. Clements. \On the Meaning of SCR Event Expressions", September 1993. Presented at the Third International SCR Workshop. [12] M. Felder and A. Morzenti. \Validating Real-Time Systems by Executing Logic Speci cations in TRIO". In Proceedings of the 14th Internation Conference on Software Engineering, pages 199{211, May 1992. [13] A Gabrielian and R. Iyer. \Integrating Automata and Temporal Logic: A Framework for Speci cation of Real-Time Systems and Software". In Proceedings of the Uni ed Computation Laboratory, 1990. [14] C. Ghezzi, D. Mandrioli, and A. Morzenti. \TRIO, a logic language for executable speci cations of real-time systems". Journal of Systems and Software, 12(2):107{123, May 1990. 24
[15] S. Graf, J.-L. Richier, C. Rodriguez, and J. Voiron. \What are the Limits of Model Checking Methods for the Veri cation of Real Life Protocols?". In Proceedings of the International Workshop on Automatic Veri cation Methods for Finite State Systems, pages 275{285, June 1989. [16] H. Hansen. Time and Probability in Formal Design of Distributed Systems. PhD thesis, Department of Computer Systems, Uppsala University, 1991. [17] C. Heitmeyer, B. Labaw, and D. Kiskis. \Consistency Checking of SCR-Style Requirements Speci cations". In Proceedings of the 2nd IEEE International Symposium on Requirements Engineering, pages 56{65, March 1995. [18] K. Heninger. \Specifying Software Requirements for Complex Systems: New Techniques and Their Applications". IEEE Transactions on Software Engineering, SE-6(1):2{12, January 1980. [19] F. Jahanian, R. Lee, and A. Mok. \Semantics of Modechart in Real Time Logic". In Proceedings of the 21st Hawaii International Conference on System Sciences, pages 479{489, 1988. [20] F. Jahanian and A. Mok. \A Graph-Theoretic Approach for Timing Analysis and its Implementation". IEEE Transactions on Computers, C-36(8):961{974, August 1987. [21] F. Jahanian and A. Mok. \Modechart: a Speci cation Language for Real-Time Systems". December 1994. [22] F. Jahanian and D. Stuart. \A Method for Verifying Properties of Modechart Speci cations". In Proceedings of the Real-Time Systems Symposium, pages 12{21, 1988. [23] N. Leveson and J. Stolzy. \Safety Analysis Using Petri Nets". IEEE Transactions on Software Engineering, SE-13(3):386{397, March 1987. [24] N.G. Leveson, M.P.E. Heimdahl, H. Hildreth, and J.D. Reese. \Requirements Speci cation for Process-Control Systems". IEEE Transactions on Software Engineering, 20(9):684{707, September 1994. [25] J. Ostro . \Deciding Properties of Timed Transition Models". IEEE Transactions on Parallel and Distributed Systems, 1(2):170{183, April 1990. [26] J. Ostro . \A Veri er for Real-Time Properties". The Journal of Real-Time Systems, 4:5{35, 1992. [27] T. Sreemani and J. Atlee. \Feasibility of Model Checking Software Requirements: A Case Study". In Proceedings of the Conference on Computer Assurance, pages 77{88, 1996. [28] D. Stuart. Implementing a veri er for real-time systems. In Proceedings of the Real-Time Systems Symposium, pages 62{71, 1990. [29] J. van Schouwen. The A-7 Requirements Model: Re-examination for Real-Time Systems and an Application to Monitoring Systems. Technical Report TR-90-276, Department of Computing and Information Science, Queen's University, Kingston, Ontario, May 1990. 25
A Soundness of Model Checking A system's timed reachability graph can be modeled by a machine M = hS; Q; V; I; R; Ai, where S is a nite set of states Q 2 S is the set of initial states V is a nite set of boolean variables used to annotated states with boolean properties I : S ! 2V is a function, mapping from states to their respective interpretations, where an interpretation is an assignment of truth values to the boolean variables. R (S S ) is the transition relation. If (s; t) 2 R, then whenever the machine M is in state s, it may transition to state t. The term dom(R) refers to the domain of relation R: 8s 2 S (s 2 dom(R) $ 9t 2 S ((s; t) 2 R)) Our tgraph analysis tool produces a compact representation of the system's timed reachability graph. It can be modeled by a machine MC = hSC ; QC ; V; IC ; RC i, where SC is a nite set of compact states. SC is de ned to be a partition on the set of states S such that all states t 2 S that have the same interpretation belong to the same block of the partition. SC = f1; 2; : : :; j2V jg 8t 2 S; 9i(1 i 2V ^ t 2 i) Sj2V j = S 8s; t 2 S ((s 2 i ^ t 2 i) ! I (s) = I (t)) i=1 i 8i; j (i 6= j ! i \ j = ;) Since the partition SC is de ned in terms of the states' interpretations, we de ne block I (s) to be the partition block containing state s: 8s 2 S; 9i(1 i 2V ^ I (s) = i) 8s; t 2 S (I (s) = I (t) $ I (s) = I (t)) QC 2 SC is the set of initial compact states. QC = fI (q) j q 2 Qg V is the same set of boolean variables. IC : SC ! 2V is a function mapping compact states to interpretations 8s 2 S (I (s) = IC (I (s))) RC (SC SC ) is the transition relation of our compact state-transition machine. If there exists a transition (s:t) 2 R in machine M, then there is a corresponding transition in machine MC from the block containing s toh the block containing t: i 8s; t 2 S (s; t) 2 R ! (I (s); I (t)) 2 RC Furthermore, if there is a transition from block i 2 SC to block j 2 SC in machine MC , then machine M must have at least one representative transition from a state in block i to a state in block j . 8i; j 2 SC [(i; j ) 2 RC ! 9s 2 i; 9t 2 j ((s; t) 2 R)] We will use the term dom(RC ) to refer to the domain of relation RC : 8i 2 SC (i 2 dom(RC ) $ 9j 2 SC ((i; j ) 2 RC )) 26
The truth of a formula f is evaluated with respect to a particular state s in a model M. Thus, the model checker determines whether or not the following holds: M; s j= f In compact model MC , the truth of a formula f is evaluated with respect to a particular compact state i in model MC : MC ; i j= f We want to verify that a formula f is true in a timed reachability graph M if and only if f is true in M's representative compact timed reachability graph MC . As will be shown below, this statement is true if f is a propositional logic formula or a temporal logic formula containing only universally-quanti ed temporal operators (e.g., AX ). if M; s j= f then MC ; I (s) j= f if MC ; i j= f then 8s 2 i(s 2 dom(R) ! M; s j= f ) The rst statement says that if formulae f holds in state s in model M , then f holds in partition block I (s) (which contains state s) in model MC . The second statement says that if f holds in compact state i in model MC , then in model M, f holds with respect to all the states s belonging to partition block i. The above statements are also true if f is an existentially-quanti ed temporal logic formula and if f is evaluated at the initial state of the model. In general, the evaluation of existentially quanti ed temporal operators is not sound because the set of transitions out of states s 2 i and t 2 i may be di erent; thus the evaluation of f in some next state of i does not imply that f is true in some next state of s 2 i. The rest of the appendix consists of proofs showing that model checking a restricted set of the CTL branching-time temporal logic is sound with respect to compact timed reachability graphs. The rst three theorems are the minimal set of theorems needed to prove that model checking propositional logic formulae is sound. All three theorems use the property that a block in partition SC has the same interpretation as its member states: 8s 2 S (I (s) = IC (I (s)))
Theorem A.1 An atomic proposition p is true with respect to state i of a compact timed reachability graph MC if and only if p is true with respect to all states s 2 i in timed reachability graph M: MC ; i j= p i 8s 2 i(M; s j= p) Proof: (() M; s j= p ) p 2 I (s) ) p 2 IC (I (s)) ) MC ; I (s) j= p Proof: ()) MC ; i j= p ) p 2 IC (i) ) 8s 2 i(p 2 I (s))) ) 8s 2 i(M; s j= p) 2
27
Theorem A.2 A negated formula f is true with respect to state i of a compact timed reachability graph MC if and only if f is true with respect to all states s 2 i in timed reachability graph M: MC ; i j= f i 8s 2 i(M; s j= f ) Proof: (() M; s j= f ) (I (s) ! f ) (IC (I (s))) ! f ) MC ; I (s) j= f Proof: ()) MC ; i j= f ) (IC (i)) ! f ) 8s 2 i(I (s)) ! f )) ) 8s 2 i(M; s j= f ) 2 Theorem A.3 A disjunction f _ g is true with respect to state i of a compact timed reachability graph MC if and only if f _ g is true with respect to all states s 2 i in timed reachability graph M: MC ; i j= f _ g i 8s 2 i(M; s j= f _ g) Proof: (() M; s j= f _ g ) (I (s)) ! (f _ g) ) (IC (I (s))) ! (f _ g) ) MC ; I (s) j= f _ g Proof: ()) MC ; i j= f _ g ) IC (i)) ! (f _ g) ) 8s 2 sigmai(I (s)) ! (f _ g))) ) 8s 2 i(M; s j= f _ g) 2 The following theorems prove that the CTL model checker is sound for verifying certain temporal logic formulae with respect to compact timed reachability graphs. These theorems use the concept of a path in a reachability graph. Let a path in a timed reachability graph be denoted by a sequence of ordered pairs of states and input conditions (< t0; D0 >; < t1; D1 >; ...), where all ordered pairs < ti; Di > belong to the domain of R and all subsequences of the path of length 2 are connected by R (i.e., if < ti; Di >; < ti+1; Di+1 > appears in the path, then (ti; Di ; ti+1) 2 R). Likewise, let a path in a compact timed reachability graph be denoted by a sequence of ordered pairs of compact states and input conditions (< T0; D0 >; < T1; D1 >; ...), where all ordered pairs < Ti; Di > belong to the domain of RC and all subsequences of the path of length 2 are connected by RC (i.e., if < Ti; Di >; < Ti+1; Di+1 > appears in the path, then (Ti; Di; Ti+1) 2 RC ). Because the following theorems use the concept of a path in a reachability graph, they use the property that if there exists a transition from state s 2 S to t 2 S in machine M, then in machine MC there is a transition from the block i t: h containing s to the block containing C I 8s; t 2 S; 8D 2 2 (s; D; t) 2 R ! (SP (s); D; SP (t)) 2 R They also use the property that if there is a transition from block Si 2 S C to block Sj 2 S C in machine MC , then machine M must have a representative transition from a state in block Si to a state in block Sj . h i 8Si; Sj 2 S C ; 8D 2 2I (Si; D; Sj ) 2 RC ! 9s 2 Si; 9t 2 Sj ((s; D; t) 2 R) 28
Theorem A.4 Formula AXf is true with respect to input condition D and state Si of a compact timed reachability graph MC if and only if AXf is true with respect to input condition D and all states s 2 Si that have transitions labeled D in timed reachability graph M: MC ; Si; D j= AXf i 8s 2 Si((s; D) 2 dom(R) ! M; s; D j= AXf ) Proof: AXf is true with respect to input condition D in a state s 2 S (or Si 2 S C ) if and only if for all next states t 2 S (or all next states T 2 S C ) reachable via a transition labeled with input condition D, f is true in state t (or state T ). More precisely, f must be true with respect to all such next states t (T ) and all input conditions E that activate transitions out of t (T ). M; s; D j= AXf ) 8paths in M leaving state s via a transition labeled D (< s; D >; < t; E >; :::) : M; t; E j= f ) 8t 2 S; 8E 2 2I (((s; D; t) 2 R ^ (t; E ) 2 dom(R)) ! ((P (t) ^ E ) ! f )) ) 8T 2 S C ; 8E 2 2I (((SP (s); D; T ) 2 RC ^ (T; E ) 2 dom(RC )) ! ((P C (T ) ^ E ) ! f )) ) 8paths in MC leaving SP (s) via a transition labeled D (< SP (s) ; D >; < T; E >; :::) : MC ; T; E j= f ) MC ; SP (s); D j= AXf )
MC ; Si; D j= AXf ) 8paths in MC leaving state Si via a transition labeled D (< Si; D >; < T; E >; :::) : MC ; T; E j= f ) 8T 2 S C ; 8E 2 2I (((Si; D; T ) 2 RC ^ (T; E ) 2 dom(RC )) ! ((P C (T ) ^ E ) ! f )) ) 8s 2 Si; 8t 2 S; 8E 2 2I (((s; D; t) 2 R ^ (t; E ) 2 dom(R)) ! ((P (t) ^ E ) ! f )) ) 8paths in M leaving each state s 2 Si via a transition labeled D (< s; D >; < t; E >; :::) : M; t; E j= f ) 8s 2 Si((s; D) 2 dom(R) ! M; s; D j= AXf 2
The following theorems use the concept of reachable states (reachable via some path in the model). The existence of a path from state s to state t in model M implies a path from compact state SP (s) to compact state SP (t) in model MC . However, the existence of a path from Si to Sj in model MC does not necessarily imply a path from some state s 2 Si to some state t 2 Sj in model M: a path from Si to Sj through intermediate state Sm could represent two disjoint paths in model M, one from s 2 Si to m 2 Sk and the other from n 2 Sk to t 2 Sj . Furthermore, we do not even know the rst transition in those paths. It is possible for a path from qC to Si with an initial transition labeled D to exist in model MC , and for all paths from q to states s 2 Si in model M to start with initial transitions labeled with input conditions other than D: in such a case, there is a path in M from q to q0 2 qC and there are subsequent paths from q0 to states s 2 Si that start with transitions labeled D. Fortunately, because the technique used to build a compact timed reachability graph actually traces the system's timed reachability graph, only states s 2 S that are reachable from the system's initial state q are represented in the compact timed reachability graph. Therefore, the existence of a path from initial compact state qC to state Si in model MC does imply the existence of paths from initial state q 2 qC to all states s 2 Si, although we do not know the sequences of ordered pairs that comprise those paths. 29
The following theorems refer to the truth of formulae AGf and EFf with respect to the initial state of the model. Because we do not know what input conditions the transitions leaving the initial state are annotated with, the input conditions are quanti ed. The proofs of both of these theorems use the property that if a state Si 2 S C is reachable from state qC via some path in model MC , then all states s 2 Si are reachable from state q via some unknown path in model M.
TheoremC A.5 Formula AGf is true with respect to initial state qC of a compact timed reachability graph M if and only if AGf is true with respect to initial state q in timed reachability graph M:
8D 2 2I [(qC ; D) 2 dom(RC ) ! MC ; qC ; D j= AGf ]
i
8D 2 2I [(q; D) 2 dom(R) ! M; q; D j= AGf ]
Proof: AGf is true with respect to initial state q (or qC ) if and only if f is true in all reachable states t 2 S (or all reachable states T 2 S C ). 8D 2 2I [(q; D) 2 dom(R) ! M; q; D j= AGf ] ) 8D 2 2I [(q; D) 2 dom(R) ! [8states t reachable from state q via an initial transition labeled D (< q; D >; :::; < t; E >) : M; t; E j= f ]] ) 8D 2 2I [(q; D) 2 dom(R) ! [8t 2 S ((9 a path in M(< t0; E0 >; < t1; E1 >; :::; < tn; En >)^ q = t0 ^ D = E0 ^ 8i; :::; < SP (tn); En >)^ q = t0 ^ qC = SP (t0) ^ D = E0 ^ 8i; :::; < T; E >) : MC ; T; E j= f ]] ) 8D 2 2I [(qC ; D) 2 dom(RC ) ! MC ; qC ; D j= AGf ]
30
2
8D 2 2I [(qC ; D) 2 dom(RC ) ! MC ; qC ; D j= AGf ] ) 8D 2 2I [(qC ; D) 2 dom(RC ) ! [8states T reachable from state qC via an initial transition labeled D (< qC ; D >; :::; < T; E >) : MC ; T; E j= f ]] ) 8D 2 2I [(qC ; D) 2 dom(RC ) ! [8T 2 S C ((9 a path in MC (< T0; E0 >; < T1; E1 >; :::; < Tn; En >)^ qC = T0 ^ D = E0 ^ 8i; :::; < tm; Em >)^ q = t0 ^ D = E0 ^ 8i; :::; < t; E >) : M; t; E j= f ]] ) 8D 2 2I [(q; D) 2 dom(R) ! M; q; D j= AGf ]
Theorem A.6 Formula EFf is trueC with respect to input condition D and initial state qC of a compact timed reachability graph M if and only if EFf is true with respect to input condition D and initial state q in timed reachability graph M:
9D 2 2I [(qC ; D) 2 dom(RC ) ^ MC ; qC ; D j= EFf ] $ 9D 2 2I [(q; D) 2 dom(R) ^ M; q; D j= EFf )
Proof: EFf is true with respect to initial state q (or qC ) if and only if f is true in some reachable state t 2 S (or in some reachable state T 2 S C ). 9D 2 2I [(q; D) 2 dom(R) ^ M; q; D j= EFf ] ) 9D 2 2I [(q; D) 2 dom(R) ^ 9 some state t reachable from state q via an initial transition labeled D (< q; D >; :::; < t; E >) : M; t; E j= f ] ) 9D 2 2I [(q; D) 2 dom(R) ^ 9t 2 S [9 a path in M(< t0; E0 >; < t1; E1 >; :::; < tn ; En >)^ q = t0 ^ D = E0 ^ 8i; :::; < SP (tn); En >)^ q = t0 ^ qC = SP (t0) ^ D = E0 ^ 8i; :::; < T; E >) : MC ; T; E j= f ] ) 9D 2 2I [(qC ; D) 2 dom(RC ) ^ MC ; qC ; D j= EFf ] 31
2
9D 2 2I [(qC ; D) 2 dom(RC ) ^ MC ; qC ; D j= EFf ] ) 9D 2 2I [(qC ; D) 2 dom(RC ) ^ 9 some state T reachable from state qC via an initial transition labeled D (< qC ; D >; :::; < T; E >) : MC ; T; E j= f ] ) 9D 2 2I [(qC ; D) 2 dom(RC ) ^ 9T 2 S C [9 a path in MC (< T0; E0 >; < T1; E1 >; :::; < Tn; En >)^ qC = T0 ^ D = E0 ^ 8i; < t1; E1 >; :::; < tm; Em >)^ q = t0 ^ D = E0 ^ 8i; :::; < t; E >) : M; t; E j= f ] ) 9D 2 2I [(q; D) 2 dom(R) ^ M; q; D j= EFf ]
32
