188 VERIFICATION USING TIMED AUTOMATA

timed automata. First, an axiomatic specification specifies the system in a descriptive, axiomatic style without showing how it operates. Then, an operational specification describes the operation of the system. A formal proof is required to show that the operational specification implements the axiomatic specification.

There are several ways to construct this proof. [Lynch and Attiya, 1992; Lynch and Vaandrager, 1991] have used assertional techniques for untimed, concurrent, and distributed systems, and thus propose adapting these techniques to verify timing properties of real-time systems. In particular, the method of simulations is used to establish the relationships (such as implementation) between two specifications described by two corresponding timed automata. Here, the concept of simulations includes special cases such as refinement mappings, backward and forward simulations, and history and prophecy mapping.

Several definitions exist for a general timed automaton. One variation proposed by Lynch and Vaandrager is as follows [Lynch and Vaandrager, 1991].

Timed Automaton: Formally, a timed automaton A is a general labeled transition system with four components:

states(A) is a set of states.

start(A) is a nonempty set of start states.

acts(A) is a set of actions. Actions can be internal or external. Internal actions are within the system. External actions include visible actions (which can be input or output actions) and special time-passage actions v(t), where t is a positive real number.

steps(A) is a set of steps (usually known as transitions in other definitions of automata).

The number of states can be finite or infinite. To improve readability, the notation

Having defined the concept of a timed automaton, we next consider its behavior by observing its execution from one point in time to another. A timed execution is a sequence of internal, visible, and time-passage actions, connected by their intervening states, and augmented with the notion of trajectories for each time-passage action. A trajectory indicates the state changes during time-passage steps. To formally define a time execution, we first define the notion of a timed execution fragment.

Timed Execution: A timed execution fragment is a finite or infinite alternating sequence

α = ω0π1ω1π2ω2 . . . ,

If the first state of the first trajectory, ω0, of a timed execution fragment is a start state, then this fragment is a timed execution.

A state of a timed automaton A is reachable if it is the final state of the final trajectory in some finite-timed execution of A. A time of occurrence is associated with each instance of a state or action in a timed execution. This is done by summing all the preceding time-passage values. Note that this notion of time of occurrence is similar to that of the occurrence in real-time logic (RTL).

Given a timed automaton A, of practical interest is the set atexecs(A) of admissible timed executions in which the total amount of time passage is ∞. Next, we define timed traces to represent the visible behavior of timed automata for solving verification problems.

7.1.2 Timed Traces

A timed trace of any timed execution is the sequence of visible events that occur in the timed execution, paired with their times of occurrence. This sequence has the form

(π1, t1), (π2, t2), (π3, t3), . . . ,

where the πs are non-time-passage actions and the ts are non-negative real-valued times.

The notation ttrace(α) denotes the timed trace of the timed execution α. The timed traces obtained from all the admissible timed executions of a timed automaton A constitute the set attraces(A) of admissible timed traces of A.

Example. Consider a traffic semaphore with three light signals. Initially, there is no light when the system is off. Once it is turned on at time 0, the event turn green makes the green light turn on. Next, the event turn yellow, occurring 20 s later, turns the green light off and then the yellow light on. Next, the turn red event occurring 5 s later turns the yellow light off and then the red light on. Next, the event turn green, occurring 15 s later, turns the red light off and then the green light on. This sequence is repeated infinitely often. The timed trace of this timed execution is

(turn green, 0), (turn yellow, 20), (turn red, 25), (turn green, 40), . . . .

Operations on automata exist that allow the definitions of complex automata by combining simpler automata. These operations include projection and parallel composition.

190 VERIFICATION USING TIMED AUTOMATA

7.1.3 Composition of Timed Automata

To model a complex system, we need to combine several automata representing different parts of the system through composition. Two timed automata A and B are compatible iff they have no common output actions and the internal actions of A are different from those of B. Then the composition of A and B, written as A × B, is the timed automaton with:

This means that A and B can execute jointly on a common input or time-passage action, or on an output of one that is an input of the other.

7.1.4 MMT Automata

The above definition of a timed automaton is very general. To allow more efficient verification via simulations, a more specialized automaton is introduced. A Merritt– Modugno–Tuttle (MMT) automaton [Merritt, Modugno, and Tuttle, 1991] is an I/O automaton augmented with upper and lower bounds on time between specific actions. The MMT automaton model can be used to represent many types of timed automata. An I/O automaton is a labeled transition system for representing an untimed asynchronous system. Its internal and output actions are grouped into tasks.

I/O Automaton: An I/O automaton A has the following components:

states(A) is a set of states.

start(A) is a nonempty subset of start states.

acts(A) is a set of actions. Actions can be internal or external. External actions can be input or output actions.

steps(A) is a set of steps (usually known as transitions in other publications). This is a subset of states(A) × acts(A) × statesA).

part(A) is a partition of the locally controlled (internal and output) actions into at most countably many equivalence classes.

Note that the definition of a basic timed automaton is basically that of an I/O automaton extended with the notion of time for steps(A). To define an MMT automaton, [Lynch and Attiya, 1992; Lynch and Vaandrager, 1991] extend the I/O automaton model with lower and upper time bound information. More precisely, an MMT automaton is an I/O automaton with only finitely many partition classes; and for each class C, lower and upper time bounds are defined and denoted lower(C)

and upper(C), where 0 ≤ lower(C) < ∞ and 0 < upper(C) ≤ ∞. In other words, the lower bounds cannot be infinite and the upper bounds cannot be 0.

Since an MMT automaton can represent the time differences between certain actions in the modeled system or its component, the execution of the MMT automaton shows the behavior of the modeled system over time. A timed execution of an MMT automaton is an alternating sequence of the form s0, (π1, t1), s1, . . . , where the πs

π j +1

can be input, output, or external actions. For each i, si −→s j+1 must hold such that the successive times are nondecreasing and are required to satisfy the specified lower and upper time bound requirements.

The points at which the bounds for a class C begin to be measured are called initial indices. Index i is defined as an initial index for a class C enabled in state si , and one of the following must hold: i = 0, C is not enabled in s j−1, or πi C. With this definition, the following conditions must hold for every initial index i for

aclass C:

1.If upper = ∞, there exists k > i, tk ≤ ti + upper(C), such that either πk C or C is not enabled in state sk .

2.There does not exist k > i, tk < ti + lower(C), and πk C.

Condition (1) is the upper bound requirement; an upper bound of ∞ means that actions in the corresponding class may never occur. Condition (2) is the lower bound requirement. The condition of admissibility must also hold; that is, if the sequence is infinite, then the times of actions approach ∞.

7.1.5 Verification Techniques

A problem P can be formulated as a set of finite or infinite sequences of actions with corresponding times. Then a timed automaton A is said to solve P if all its admissible timed traces are in P. Since we can express P as the set of admissible timed traces of another timed automaton B, the concept of admissible timed traces induces a preorder on timed automata. The notation A ≤ B means that the set of admissible timed traces of A is a subset of the set of admissible timed traces of B.

Example. The following MMT automaton describes the behavior of the pedals of a simplified automobile, which has been specified in Statecharts in chapter 4. The automobile can be in one of three states: stop, move, or slow. The inputs are apply accelerator, apply brake, and apply hand brake. The nontrivial time bounds are

speed up: [0, tspeedup], slow: [0, tspeedup], and stop: [0, tspeedup], where tspeedup, tslow,

and tstop are the upper bounds on the time for the car to speed up, slow, and stop, respectively. The state components now, latest(speedup), latest(slow), and latest(stop) are also needed to add timing specifications to each state.

As in the Statecharts specification, the MMT automaton shows that (1) the transition from the state “stop” to the state “speed up” occurs when the accelerator is applied; (2) the transition from the state “speedup” to the state “slow” occurs when

192 VERIFICATION USING TIMED AUTOMATA

the brake is applied; (3) the transition from the state “slow” to the state “speedup” occurs when the accelerator is applied; and (4) the transitions from the states “speedup” and “slow” to the state “stop” occur when the hand brake is applied.

Automaton C: car’s pedals system States:

status stop, slow, speedup, initially stop now, a non-negative real, initially 0

Transitions:

apply accelerator

Precondition:

s.status stop, slow

Effect:

s .status = to speedup

s .latest(speedup) = now + tspeedup s .latest(stop) = ∞

s .latest(slow) = ∞

apply brake

Precondition: s.status = speedup

Effect:

s .status = toslow

s .latest(slow) = now + tslow s .latest(speedup) = ∞

s .latest(stop) = ∞

apply hand brake

Precondition:

s.status speedup, slow

Effect:

s .status = stop

s .latest(stop) = now + tstop s .latest(speedup) = ∞

s .latest(slow) = ∞

speedup

Precondition:

s.status = speeding up

Effect:

s .status = speedup

s .latest(speedup) = ∞