180 REAL-TIME LOGIC, GRAPH-THEORETIC ANALYSIS, AND MODECHART

erty. For example, suppose we like to check whether some instance of an interval I1 contains an instance of an interval I2. First, we find in the graph an instance of interval I2. Then we check if an instance of interval I1 contains within it interval I2, and the algorithm returns true if this is the case. If we like to check whether every instance of an interval I1 contains an instance of an interval I2, we need to repeat the above steps for every appearance of I2. Other cases and combinations of quantifiers can be checked similarly.

6.10 AVAILABLE TOOLS

Modechart Toolset (MT) [Clements et al., 1993b] is a set of tools using the Modechart language for the specification, modeling, and analysis of real-time embedded systems. It supports the creation, modification, and storage of Modechart specifications and allows the analysis of Modechart specifications using a consistency and completeness checker, a simulator, and a verifier. A user manual for MT can be found in [Rose, Perez, and Clements, 1994].

XSVT [Stuart et al., 2001] is a new prototype tool built as part of MT that combines simulation and verification techniques to analyze Modechart specifications.

6.11 HISTORICAL PERSPECTIVE AND RELATED WORK

[Jahanian and Mok, 1986] developed RTL as a concise, first-order logic language to formally specify real-time systems and their absolute timing properties. They proposed an analysis framework relating the system specification and the desired safety assertion(s). The Bledsoe-Hines decision procedure was suggested as a means to check and verify the satisfaction of the safety assertion(s) given a system specification. However, for RTL, this analysis problem is in general undecidable, and requires exponential time to solve for decidable cases. Other real-time logics include the Interval Logic developed recently by [Mattolini and Nesi, 2001].

To derive a more efficient analysis algorithm, [Jahanian and Mok, 1987] define a subclass of RTL formulas that is a class of practical real-time systems. This graphtheoretic approach is based on inequalities and graph analysis, and does not require the use of logic decision procedures.

The Modechart graphical specification language was introduced by Mok et al. [Jahanian and Stuart, 1988; Jahanian and Mok, 1994] to facilitate the specification of real-time systems and as an alternative to Statecharts and STATEMATE. Furthermore, Modechart claims to remedy the weaknesses of Statechart in handling absolute-timing specifications. To combat the state-explosion problem, [Stuart et al., 2001] combine simulation and verification techniques to make it easier to understand specifications and to speed up verification of properties expressed in CTL-like forms. [Brockmeyer et al., 2000] provide a flexible and extensible simulation environment for testing real-time specifications.

SUMMARY 181

Recently, [Rice and Cheng, 1999] used RTL and the constraint graph approach described here to specify and verify part of the X-38 Space Station Crew Return Vehicle Avionics. Part of the analysis is shown in this chapter.

6.12 SUMMARY

A real-time system can be specified in one of two ways. The first is to structurally and functionally describe the system by specifying its mechanical, electrical, and electronic components. This type of specification shows how the components of the system work and shows their functions and operations. The second is to describe the behavior of the system in response to actions and events. Here, the specification tells sequences of events allowed by the system.

To show that a system or program meets certain safety properties, we can relate the specification of the system to the safety assertion representing the desired safety properties. This assumes that the actual implementation of the system is faithful to the specification. Note that even though a behavioral specification does not show how one can build the specified system, one can certainly show that the implemented system, built from the structural-functional specification, satisfies the behavioral specification.

One of the following three cases may result from the analysis relating the specification and the safety assertion. (1) The safety assertion is a theorem derivable from the specification, thus the system is safe with respect to the behavior denoted by the safety assertion. (2) The safety assertion is unsatisfiable with respect to the specification, so the system is inherently unsafe since the specification will cause the safety assertion to be violated. (3) The negation of the safety assertion is satisfiable under certain conditions, meaning that additional constraints must be added to the system to ensure its safety.

The event-action model [Heninger, 1980; Jahanian and Mok, 1986] captures the data dependency and temporal ordering of computational actions that must be taken in response to events in a real-time application. There are four basic concepts.

1.An action is a schedulable unit of work and can be primitive or composite. A primitive action is atomic in that it cannot or does not need to be broken into subactions for the purpose of analysis. It consumes a bounded amount of time. A composite action is a partial ordering of primitive actions or other composite actions.

2.A state predicate is an assertion about the state of the specified system.

3.An event is a temporal marker for indicating a point in time that is significant in describing the system behavior. There are four classes of events:

(a)An external event is caused by actions outside the specified system.

(b)A start event marks the beginning of an action, for example, the start of the DOWN-GATE action.

(c)A stop event marks the end of an action, for example, the end of the DOWN-GATE action.

182REAL-TIME LOGIC, GRAPH-THEORETIC ANALYSIS, AND MODECHART

(d)A transition event marks the change in certain attributes of the system state.

4.A timing constraint is an assertion about the absolute timing of system events.

The motivation for introducing the real-time logic (RTL) [Jahanian and Mok, 1986] is that the specifications written in the event-action model cannot be easily manipulated by a computer. RTL is a first-order logic with special features to capture the timing requirements of the specified system while making the specification easy to manipulate mechanically. RTL was especially attractive because at the time of its introduction, temporal logic was able to express the relative ordering of events or actions [Heninger, 1980; Bernstein and Harter, 1981], but temporal logic has not yet been extended with the capability of expressing absolute timing characteristics. Furthermore, temporal logic uses an interleaving model of computation to specify concurrency in computer systems, but this model cannot express true parallelism. For instance, temporal logic models two parallel actions as if one is followed by the other or vice versa, so that from an initial state s0 there are two paths, corresponding to the two orderings of these actions, leading to state s1.

A scheduler is often an integral part of a real-time system. The correctness of a real-time system depends on the correctness of its scheduler. Temporal logic, however, usually assumes the fair scheduling of the specified system’s resources and events. This is appropriate for non-time-critical systems but certainly is not sufficient for the analysis of real-time systems.

RTL is based on the event-action model, augmented with several features such as the occurrence function @, which assigns time values to event occurrences.

There are three types of RTL constants: actions, events, and integers. Action constants are as defined in the event-action model and capital letters are used to denote them to distinguish them from variables. A subaction Bi of a composite action A is denoted as A.Bi . Event constants serve as temporal markers and are classified into:

(1) start events indicating the beginning of actions, preceded by ↑; (2) stop events indicating the end of actions, preceded by ↓; (3) transition events indicating the change in certain attributes of the system state; and (4) external events, preceded by .

One restricted class of RTL formulas [Jahanian and Mok, 1987] is motivated by the fact that in the specification of many real-time systems:

1.the RTL formulas consist of arithmetic inequalities involving two terms and an integer constant in which a term is either a variable or a function; and

2.the RTL formulas do not contain arithmetic expressions that have a function taking an instance of itself as an argument.

Such a restricted RTL class allows the use of a graph-theoretic approach for analysis. For example, we can use a single-source shortest-paths algorithm for the simple integer programming problem where each inequality is of the form xi − x j ≤ ±ai j , where xi and x j are variables and a is an integer constant. We can also use a constraint graph to represent the set of inequalities. Each variable is presented by a node

EXERCISES 183

in the graph, and an inequality xi ± ai j ≤ x j is represented by a directed edge with weight ±ai j connecting xi to x j . Then, a set of inequalities represented by such a graph is unsatisfiable iff there is cycle in the graph with a positive total weight.

The class of RTL formulas consists of arithmetic inequalities of the following form:

occurrence function ± integer constant ≤ occurrence function.

To show the practicality of RTL specification and the constraint graph analysis approach, we use RTL to specify and analyze the timing properties of the avionics of the X-38, a family of vehicles built as incremental development prototypes for the Crew Return Vehicle of the International Space Station.

Modechart specifications allow a graphical interface between the user and the analysis tool. To verify timing properties in a Modechart specification, we first generate a computation graph from the specification. This computation graph represents all behaviors allowed by the Modehcart specification. Then we apply specialized decision procedures [Jahanian and Stuart, 1988] or more general model-checking algorithms [Clarke, Emerson, and Sistla, 1986] to the computation graph to determine if a given timing property is satisfiable. To apply either of these approaches, the computation is viewed as the model of the specified system and the timing property to be checked is given as an RTL formula. Then the decision procedure or model checker decides whether the computation graph satisfies this property.

The computations of a specified system are represented by an infinite computation tree. Then this computation tree can be converted into a finite computation graph for analysis and verification.

Two classes of RTL formulas are preserved by a computation graph: (1) minimum and maximum distance between endpoints and (2) exclusion and inclusion of endpoint and interval.

EXERCISES

1.Express the following safety assertion in RTL: If the brake actuator is activated (ACTIVATED) within 30 time units of the completion of action TRANSMIT (which transmits the signal from the brake to the brake actuator), we are assured that within 100 time units of pressing the brake (BRAKE), the brake actuator is activated, and within 120 time units of pressing the brake but at least 40 time units after pressing the brake, the braking mechanism will be applied (STOP).

2.Express the following safety assertion in RTL: In the hospital intensive care unit, once the pulse/blood pressure monitor pad, blood oxygen sensor, and respiration sensor are properly attached to the patient’s arm, index finger, and nose, respectively, and the alarm is enabled, the alarm sounds if any of the following conditions becomes true and remains sounding until a nurse or doctor arrives and disables the alarm: pulse rate is above 120 beats per minute for 20 s, systolic blood pressure is above 180 mmHg for 60 s, blood oxygen count is below 80% for 15 s, or respiration rate is above 35 times per minute for 30 s.

184 REAL-TIME LOGIC, GRAPH-THEORETIC ANALYSIS, AND MODECHART

3.Compare the timing specification features of Statechart/STATEMATE (described in chapter 5) and Modechart.

4.If all edges involved in a positive cycle in a constraint graph G correspond to literals that belong to unit clauses, F (SP ¬SA in clausal form) must be unsatisfiable. If an edge corresponds to a literal that belongs to non-unit disjunctive clause Ci , then it must be shown that each of the remaining literals in Ci is also involved in a different positive cycle. Explain why this is necessary.

5.Consider the following set of inequalities.

1.t1 : C ≤ A

2.t2 : A − 15 ≤ B

3.t3 : B + 15 ≤ C

4.t4 t6 : C − 10 ≤ D B + 10 ≤ D

5.t5 t7 : D + 15 ≤ C D + 15 ≤ B

6.t7 t8 : D + 15 ≤ B D + 5 ≤ D

(a)Construct the constraint graph for these inequalities.

(b)List the positive cycles.

(c)Using these positive cycles, construct a tree to find out if this set of inequalities is unsatisfiable. You might have to check that the inequalities in a leaf node are by themselves not satisfiable.

6.Consider the generation of the search tree in the graph-theoretic analysis technique. This technique requires a re-ordering of the clauses under certain circumstances to reduce the size of the search tree. Does this re-ordering always reduces the size of the search tree? Explain. If not, give a counter-example.

7.The goal of this problem is to apply formal techniques based on RTL to the specification and verification of a timing-based mutual algorithm by [Attiya and Lynch, 1989]. For this problem, assume there are only two operators (processes). Construct a set of RTL formulas that specify the actions of the processes executing this algorithm. Prove the safeness and verify the response time of the mutual-exclusion algorithm claimed in their paper by using the graph-theoretic technique.

8.Give two decidable classes of timing properties for the modechart/computation graph approach. Then give two classes of timing properties for which the modechart/computation graph approach cannot provide a solution.

9.Consider again the specification of the NASA 2001 Mars Odyssey Orbiter [Cass, 2001] described in chapter 5 (exercise 8), but now with timing constraints on the different events and actions.

The orbiter is in the ready mode before launch. Before and during launch, the orbiter is folded into a protective housing. The execution time for the launch is 60 s. The start of the launch occurs after a delay of 30 s but within 90 s of the time the orbiter becomes ready.

After launch, the solar panel extends within 120 s to convert solar energy into electric energy for navigational use. When the orbiter approaches Mars after 18 months, its engine fires within 20 s and the orbiter inserts into Mars’ orbit.

EXERCISES 185

Braking starts 50 s after the start of engine firing, and braking takes 20 s. After braking, the orbiter deploys its high-gain antenna within 100 s. At any time after launch, if an emergency occurs (expected steps are not executed as observed by a specialized monitoring computer), the orbiter skips the above steps and enters a safe mode within 10 s and lets mission controllers take over control of the orbiter. Represent the behavior of the orbiter using

(a)RTL

(b)Modechart.

10.Use Modechart to specify a smart traffic light controller for the intersection of two roads, one running North-South (NS), and the other running East-West (EW). Both EW and NS are four-lane roads. Each of the roads has a sensor, which once every T seconds informs the signal controller whether any cars are approaching the intersection along that road or are waiting at the intersection for the light to change. If the light along the road is green, the sensor also indicates the speed (in m/s) of the cars on each of the four lanes (0 if no car is approaching

on a lane). The speeds are measured D feet away from the intersection. For this problem assume that T = 1/2 and D = 300. Each sensor writes its output to a buffer. It may overwrite a value in the buffer. Every write to a buffer is timestamped automatically and raises a (maskable) interrupt in the controller. The signal controller must abide by the following constraints:

1.It starts with the NS light green and the EW light red and runs in normal mode. The other modes are power off mode, degraded mode, and automatic mode, but you need to only specify the normal mode described below.

2.Normal mode: If the light has just changed to green along either EW or NS, the controller ignores inputs from the sensors for the next 40 s. After that, it checks the time-stamps on the buffers. If both times-tamps are no more than T/2 s old, it proceeds to step 3. If either of them is no more than T/2 s old, it proceeds to step 2a. Otherwise, it unmasks the sensors’ interrupts and waits for sensor input for at most T/2 s, and proceeds to step 2a on receiving an input. If it does not receive a value within T/2 s, it enters and runs in automatic mode.

2a. The controller unmasks the sensors’ interrupts and awaits an input from the other sensor for at most T/2 s. It goes to step 3 on receiving the input; if it does not receive an input, it enters and runs in automatic mode.

3.The controller first masks interrupts that the sensors may raise. If neither sensor has detected a car approaching or halted, the controller does nothing. Otherwise, if exactly one sensor has detected a car, the controller changes the light in the other direction to red (without going through the intermediate yellow) and then changes the light in that sensor’s direction to green. If both sensors have detected cars, let us, for convenience, assume that the NS light was green and EW was red. The controller computes the time since the NS

sensor input—call this X. It then calculates the distance the fastest car in NS would have advanced in X + C s (where C is the time in seconds for the

186 REAL-TIME LOGIC, GRAPH-THEORETIC ANALYSIS, AND MODECHART

controller to do these calculations), and checks that the remaining distance is enough for the car to come safely to a halt (using a table lookup). If it is judged to be safe, the controller returns to step 2. Otherwise, it changes the green light to yellow (for a period read from a table—this time is dependent on the speed of the car), then to red. It then changes the red light on EW to green and returns to step 2.