6.1 SPECIFICATION AND SAFETY ASSERTIONS

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 specification and the safety assertion can be written in one of several realtime specification languages. The choice of language would in turn determine the algorithms that can be used for the analysis and verification. We begin the study with the event-action model and a first-order logic called real-time logic (RTL) [Jahanian and Mok, 1986].

6.2 EVENT-ACTION MODEL

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. The same action may appear more than once in a composite action. Recursive actions and circular chains of actions where an action is a subaction of its predecessor in the chain are not allowed.

The notation A;B indicates that the sequential execution of action A is followed by action B. For example, TRAIN-APPROACH;DOWN-GATE means that the train first approaches the railroad crossing sensor, then the gate moves

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

down. The notation A B indicates the parallel execution of action A and action B. For example, DOWN-GATE RING-BELL means that the moving-down of the gate and the ringing of the alerting bell happen simultaneously.

2.A state predicate is an assertion about the state of the specified system. For example, GATE-IS-DOWN is true if the gate is in the down position.

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. For example, APPLY-BRAKE is an external event which means the pressing of the brake pedal by the drive or operator.

(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.

(d)A transition event marks the change in a certain attribute of the system state. For example, GATE-IS-DOWN becomes true when the gate is moved to the down position.

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

6.3REAL-TIME LOGIC

The motivation for introducing real-time logic [Jahanian and Mok, 1986] is that the specifications written in the event-action model cannot be easily to 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 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.

For example, conventional temporal logic can specify that an action B follows another action A such as TRAIN-APPROACH followed by DOWN-GATE, but cannot specify that DOWN-GATE will occur within a certain time period (say 5 s) after the occurrence of TRAIN-APPROACH. Furthermore, temporal logic uses an interleaving model of computation to specify concurrency in computer systems, but this model cannot express true parallelism. For example, 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. @(TrainApproach, i) = x means that the ith occurrence of the train approach occurs at time x. 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 .

Example. We now use RTL to specify a simple railroad crossing with one train rail. From the field measurements and the knowledge about the mechanical characteristics of the train, train sensor, gate controller, and gate, we obtain the following specifications. The goal of the gate controller is to ensure that when the train is crossing the intersection of the road with the rail, no car is on the intersection. In this simplified version, this is achieved by having the gate in the down position when the train is crossing.

Specification in English: When the train approaches the train sensor and is detected by the sensor, a signal is sent to the gate controller to initiate the lowering of the gate at the railroad crossing.

The gate will be moved to the down position within 30 s from the time when the train approach is detected by the sensor.

The gate needs at least 15 s to lower itself to the down position.

Safety Assertion in English: If the train needs at least 45 s to travel from the sensor position to the railroad crossing, and the train crossing is completed within 60 s from the time the train is detected by the sensor, then we are assured that at the start of the train crossing the gate has moved to the down position and that the train leaves the railroad crossing within 45 s from the time the gate has completed moving to the down position.

We now show the specification and the safety assertion in RTL.

Specification in RTL:

x@(TrainApproach, x) ≤ @(↑ Downgate, x)

@(↓ Downgate, x) ≤ @(TrainApproach, x) + 30

y@(↑ Downgate, y) + 15 ≤ @(↓ Downgate, y)

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

Safety Assertion in RTL:

t u@(TrainApproach, t) + 45 ≤ @(Crossing, u)

@(Crossing, u) < @(TrainApproach, t) + 60 →

@(↓ Downgate, t) ≤ @(Crossing, u)

@(Crossing, u) ≤ @(↓ Downgate, t) + 45

To use existing theorem proving methods [Chang and Lee, 1973] to prove that the safety assertion (SA) is a theorem derivable from the specification (SP), we further translate the above into Presburger arithmetic formulas. The following Presburger arithmetic formulas with uninterpreted functions correspond to the RTL formulas describing the SP and SA.

Specification in Presburger Arithmetic Formulas:

x f (x) ≤ g1(x) g2(x) ≤ f (x) + 30

yg1(y) + 15 ≤ g2(y)

Safety Assertion in Presburger Arithmetic Formulas:

t u f (t) + 45 ≤ h(u) h(u) < f (t) + 60 → g2(t) ≤ h(u) h(u) ≤ g2(t) + 45

In these formulas, t, u, x, and y are variables, f , g1, g2, and h are uninterpreted integer functions. f corresponds to the occurrence function for event TrainApproach. g1 corresponds to the occurrence function for the start of action Downgate. g2 corresponds to the occurrence function for the end of action Downgate. h corresponds to the occurrence function for event Crossing.

The problem of determining whether SA follows from SP is in general undecidable for the full set of RTL formulas, so not all analysis problems of this type can be solved. For the subclass of RTL formulas that are decidable, the solutions still require exponential run time.

Several ways are available to improve the efficiency of the analysis. First, we can use approximations to yield a simpler set of specification and safety assertions for analysis. Second, we can focus the analysis on the part of the specification that is relevant to the validity of the given safety assertions. Third, we can restrict the specification language so that less general but more efficient analysis procedures can be applied. Here we consider the third approach.

6.4 RESTRICTED RTL FORMULAS

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 would allow the potential use of a graphtheoretic approach for analysis. For instance, 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 ai j is an integer constant. We can also use a constraint graph to represent the set of inequalities. Each variable is presented by a node 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 a cycle is present in the graph with a positive total weight on it.

As a result of these observations, we restrict the RTL formulas to consist of arithmetic inequalities of the following form:

occurrence function ± integer constant ≤ occurrence function.

Note that @(E1, i)±I < @(E2, j) can be rewritten as @(E1, i)±I +1 ≤ @(E2, j). Also, ¬(@(E1, i)±I ≤ @(E2, j)) can be rewritten as @(E2, j)±I +1 ≤ @(E1, i).

All formulas in the preceding railroad crossing example satisfy this restriction and thus are in this RTL subclass. However, the formula

t u@(TrainApproach, t) + u ≤ @(Crossing, t),

which is not found in the example, is not in the restricted RTL subclass since the first argument of ≤ is the sum of a function and a variable.

To facilitate the analysis, we first transform the RTL formula F into the corresponding Presburger arithmetic formula F . Each occurrence function @(e, i) is replaced by a function fe(i) where e is an event and i is an integer or a variable. Next, we express F in clausal form F in preparation for the analysis. F is a formula of the form

C1 C2 · · · Cn .

Each Ci is a disjunctive clause

L1 L2 · · · Ln

and each L j is a literal of the form

v1 ± I ≤ v2

where v1 and v2 are uninterpreted integer functions corresponding to the occurrence functions and I is an integer constant.

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

Given a system specification SP and a safety assertion SA expressed in the restricted RTL subclass, the goal is to show that SA is a theorem derivable from SP, that is, SP → SA. This is equivalent to showing that the negation of SP → SA, that is, ¬(SP → SA), is unsatisfiable. Since SP → SA can be rewritten as ¬SP SA, our analysis is to prove that the formula SP ¬SA is unsatisfiable. The following example shows the clausal form of the specification and the negation of the safety assertion of the preceding example.

Example. Consider SP and ¬SA in clausal form. T and U are Skolem constants corresponding to variables t and u, respectively.

Specification in Clausal Form:

f (x) ≤ g1(x)

g2(x) ≤ f (x) + 30

g1(y) + 15 ≤ g2(y)

Rewriting the formula yields the following three clauses:

(x) ≤ g1(x)

g2(x) − 30 ≤ f (x)

g1(y) + 15 ≤ g2(y)

Negation of Safety Assertion in Clausal Form:

¬( t u f (t) + 45 ≤ h(u) h(u) < f (t) + 60 → g2(t)

≤ h(u) h(u) ≤ g2(t) + 45)

is equivalent to

¬( t u ¬( f (t) + 45 ≤ h(u) h(u) < f (t) + 60) (g2(t)

≤ h(u) h(u) ≤ g2(t) + 45))

is equivalent to

t u ( f (t) +45 ≤ h(u) h(u) < f (t) +60) ((h(u) < g2(t) g2(t) +45 < h(u))

is equivalent to

t u ( f (t) + 45 ≤ h(u) h(u) < f (t) + 60) ((h(u) + 1

≤ g2(t) g2(t) + 46 ≤ h(u)).