4.2 Propositional, Predicate, and Temporal Logics

Logics are formal notations that deal with the truth or falsity of statements and relations. They provide precise methods for specifying, checking, manipulating, and verifying properties and behaviors. In this section, we briefly review and evaluate three mainstream logics. The train crossing gate application is employed as an example to illustrate each language.

The simplest logic is the propositional calculus. It defines a system for expressing and reasoning about the truth values of statements or propositions that are composed of basic objects and logical connectives. The basic objects are the constants T and F, for true and false respectively, and a set of variables that can take on the values T or F. Such a variable or constant is often called propositional or Boolean. The standard logical connectives include Ù, Ú, Ø, and Þ, meaning and, or, not, and implication, respectively. Recall, for example, that aÞb is equivalent to ØaÚb , where a and b are propositional variables or constants.

Let Trains_In and Gate_Closed be Boolean variables whose truth values denote whether or not there are trains in the crossing area and if the gate is closed, respectively. Then, the global requirement for a gate system can be expressed:

( Trains_In Þ Gate_Closed ) Ù ( ØTrains_In Þ ØGate_Closed ) .

This can be manipulated into the equivalent expression:

( Trains_In Ù Gate_Closed ) Ú ( ØTrains_In Ù ØGate_Closed ).

The first term is a safety assertion - if there are trains in the area, the gate must be closed. The second term is a statement about the progress of the system, assuming that the gate is open when the condition ØGate_Closed is true. Note that if the gate is always closed, the system is guaranteed to be "safe", but no cars will ever cross the track, i.e., there will be no progress for this part of the system.

The statements can be interpreted as conditions that change truth values as a result of state changes in the system; the state changes are triggered by events. Alternatively, any state S can be represented by an expression E such that E is true whenever the system is in state S and false otherwise. However, one serious limitation of propositional logic is that it doesn't provide any more detailed way to say what it means to be in a given state. For example, the variable or state Trains_In could be true or false, but it may be more useful to describe it’s meaning more precisely.

Predicate logic adds such facilities in a complete, if not always convenient, fashion. This more powerful logic allows predicates which are assertions containing variables and functions that may range over general domains such as integers, strings, or sets. There are also universal and existential quantifiers, denoted " ("for all") and $ ("there exist(s)"), respectively.

Let the variable count, ranging over the non-negative integers, contain the number of trains in the crossing area (as in Figure 3.6). Then the proposition Trains_In can be refined to the predicate count>0. A predicate logic expression of the gate requirement is

"count ( ( count>0 Þ Gate_Closed ) Ù ( count=0 Þ ØGate_Closed ) ) .

A major limitation is that the logic has no convenient way to express ordering. For example, the intent in the requirement is that ØGate_Closed be true (the gate is to be open) sometime after count becomes zero.

Temporal logic solves this problem [Manna&Pnueli93]. Despite its name, temporal logic does not deal with time, but only with the ordering of events and states in a system. The operation of a system from a given state is characterized by sequences of states, each sequence representing a possible execution or path through the system starting from the given state. Assertions on properties of the sequences and states can be made with the predicate calculus plus some new temporal operators.

The most widely used operators are the unary operators [] and _, which have the meaning:

[]A : The assertion A is true for all future states.

_A : The assertion A is eventually true.

The meaning is interpreted relative to some given current state or "time". Thus, the assertion _A at some state S specifies that every sequence of reachable states starting from S will eventually contain a state where A is true. Another useful operator is the binary until operator, denoted U, which is defined for the assertions A and B:

A U B : A holds (at least) until the first occurrence of B

and B will eventually occur .

Using these operators, we express some of the requirements for the train crossing gate. A, perhaps natural, safety assertion is

[] ( count>0 Þ _ Gate_Closed ) .

This assertion could be relative to the start state or any intermediate state. It states that every state with count>0 coincides with or is followed eventually by a state such that Gate_Closed is true. However, the assertion is flawed - there may be any number of intermediate states between the time that count>0 and Gate_Closed where either Ø Gate_Closed or count=0 holds. A more satisfying statement is

[] ( count>0 U Gate_Closed) Ù (count=0 U ØGate_Closed ) .

Other operators, such as Next-State and Previous-State, are also defined. Temporal logic is a very powerful extension of conventional logic, and has proven quite effective for reasoning about concurrent programs. However, it does not specify time or describe events directly. For example, it would be desirable to specify the maximum amount of time permitted to close the gate, i.e., a deadline, once a train enters the area. Some extensions with time intervals and absolute time have been proposed, but none seem as useful as the real-time logic presented in the next section.

1. Let srt_green, str_yellow, srt_red, ave_green, ave_yellow, and ave_red be Boolean state variables representing in an obvious way the colors of the street and avenue lights at any time in the Traffic Light Example of Section 3.4.1. For example, if the street light is green, then srt_green is true; otherwise, str_green is false. A safety requirement is that the street and avenue lights must never be green at the same time. One progress requirement is that the lights are never red or yellow together.

Express both the safety and progress requirements in propositional logic.

What would be another progress property?

2. Consider the coolant controller described in Question #2 of the Exercises at the end of Section 3.2. Let Ti be the temperature sampled in period i, i = 1,2, . . . . The system should be in one of three phases, represented by Boolean state variables, depending on the Ti values obtained in the most recent periods:

Moving: Temperature is not stable.

Stable: System has entered the keep_stable phase.

Error: System has entered the error_action phase.

Specify this requirement in predicate logic.

3. We use the same example and variables as in the last question (#2).

(a) Explain in words the meaning of the following temporal logic expression.

[] ( "i ( ( Ti = C ) Ù (Ti+1 = C ) ) Þ à stable )

(b) A required behavior for the system is as follows: Whenever Ti ¹ C, and Ti is a valid value, the rods will be moved, eventually resulting in Ti = C and entering the keep_stable phase, provided that the error_action is not invoked.

Describe this behavior in temporal logic.

Real-time logic (RTL) was invented by Jahanian and Mok in the 1980's (e.g. [Jahanian&Mok86]). RTL was designed specifically as a logic for reasoning about the timing properties of real-time systems. This was accomplished through a very simple but clever addition to predicate logic - a function for describing events and their occurrence times.

This function, denoted @, is called the occurrence function. @ maps events and non-negative integers into non-negative integers, with the interpretation:

@(E, i) yields the time of the ith occurrence of event E.

Here, an event name E designates a class of events whose occurrences are ordered both by instance (i) and by time (@); instances of events in the same class cannot occur simultaneously. Time is discrete and is translated to the positive integers 1, 2, 3, ... .

With the @ function, one can talk about the time of the 10th depression of button a, @(a,10), or the time of the 43rd clock tick, say @(tick,43). Thus, if the 0th instance of event E occurs at time 16, the 1st at time 23, the 2nd at time 24, and no further instances of E have occurred, we have @(E,0)=16, @(E,1)=23, @(E,2)=24, and @(E,i) undefined for i>2. It is also convenient to define initiation and termination events for actions or computations. The start of an action of type A will correspond to an event class ­A ; the completion of A will correspond to an event ¯A .

1. Suppose that upon pressing Button a, a computation Test must be completed within 30 seconds. This requirement can be expressed in RTL as

"x (@(a,x) < @(­Test,x)) Ù (@(¯Test,x) £ @(a,x) + 30) .

Note that the a and Test events are matched; the xth a has a corresponding xth Test.

2. Two actions A1 and A2 are to be mutually exclusive; i.e., during the execution of A1, A2 cannot be executed, and vice versa. This standard constraint can be stated in RTL using the start and end events of the actions:

"i,j ( ( @(¯A1,i) < @(­A2,j) ) Ú ( @(¯A2,j) < @(­A1,i) ) ) .

3. Consider a standard sporadic timing constraint [Jahanian&Mok86]: On event E with minimum event separation p, execute A with deadline d. An RTL specification of these constraints is

"i $j ( (@(E,i) £ @(­A,j)) Ù (@(¯A,j) £ (@(E,i) + d) ) )

Ù "i ( (@(E,i) + p) £ @(E,i+1) ) .

In this specification, other instances of A are possible. It is required only that there exist an instance, a "jth", associated with each E. Note also that a unique A does not necessarily correspond to each E; the specification is satisfied, for example, if two successive E’s are followed by a single associated A and d is sufficiently large. This problem cannot occur if d £ p .

4. Let the train crossing gate (Figure 3.5) operate so that the gate will close within 5 time units of receiving a close command, provided that an intervening open command has not been issued. The transition events are classes in the RTL sense. The constraint may be stated precisely in terms of these events:

If a cg command is issued at some time t1, then either

a) the gate will close (c-c event) at some time t2 £ t1 +5, and there will have been no og command issued between t1 and t2, or

b) the gate receives an og command at some time t2 £ t1 +5 and the gate will not close (no c-c event) at any time between t1 and t2.

This can be translated in a straightforward fashion to RTL. (See Exercises.)

5. Using the gate example again, let in be the event associated with a train entering the area and out be the event occurring when a train leaves. The following RTL expression gives the conditions for at least one train in the area between times t1 and t2:

"t ( (t1 £ t £ t2) Þ $i Ø$j ( (@(in,i) £ t) Ù (@(out,j) £ t) Ù (j=i ) ) )

The assertion states that between t1 and t2 there always exists at least one previous train entering event without a subsequent matching exit.

RTL has been used by its creators for some manual and automatic theorem proving of properties of specifications; in their methodology, they translate modecharts, a state-based scheme similar to statecharts, into RTL formulas for subsequent analysis. RTL also been applied to proving the correctness of computer programs, where the actions are program statements.

Some recent more practical applications include using RTL as the assertional language for run-time monitoring of timing constraints in distributed programs [Jahanian_et_al94] and for checking the behavior of CRSMs (Section 3.3.2) during simulations [Raju&Shaw94]. One variation of this type of monitoring and checking includes the program form:

when <event> { assert( <RTL_constraint>) } .

The semantics is that the <RTL_constraint> is checked whenever an instance of <event> occurs. If the check, fails an error exception is raised.

The constraint contains an expression in RTL without quantifiers and referring to the past history of events. It is most common to refer to the most recent event of a given class, the second most recent, and so on, rather than to the events starting from the first occurrence. The notation @(E, -i) , i>0, will denote the time of the ith most recent event of class E, where @(E,-1) returns the time of the most recent E event. Thus, if n instances of E have occurred with times @(E,1), . . . , @( E,n), then @(E,-i) = @(E,n-i+1) , (i>0).

1. Suppose that a traffic light controller at an intersection gives special service and priority to emergency vehicles, such as ambulances or police cars. When such a vehicle approaches the intersection, the controller switches all lights to red with enough time so that the area can be cleared safely before the emergency vehicle arrives. Let the vehicle send two types of messages (events) to the controller - an approaching event indicating that the vehicle will be crossing the intersection shortly, and a before event when the vehicle is just at the intersection. There must be at least 5 seconds between these events, in order for the controller to switch the lights and for the intersection to clear. To check that the system adheres to this constraint, the following statement can be used:

when before { assert( @(before,-1) ³ @(approaching,-1) + 5 ) }

Each time that an instance of the event before occurs, the assertion is checked.

2. Recall the Mouse Clicker example presented in Section 3.5.3. A DC message (event) is emitted every time that a double click is recognized. The correctness of an implementation or of an executable CRSM specification can be checked on each instance of DC with the following :

when DC

{ assert( (@(U,-1) - @(D,-1)) £ tSC Ù

(@(D,-1) - @(U,-2)) £ tDC Ù

(@(U,-2) - @(D,-2)) £ tSC } .

1. An alarm clock is defined with the following property:

When the alarm event occurs, a bell should ring for either 30 seconds

or until a stop button is pressed, whichever happens first.

Express this property in RTL. Let AC, ­BELL, ¯BELL, and STOP be the names of the alarm event, start_bell_ringing, stop_bell_ringing, and stop button events, respectively.

2. Specify the following mutual exclusion constraint in RTL:

In the Traffic Light system (Section 3.4.1), the street and avenue lights

can never be green simultaneously.

Assume that each of the commands, gs, ys, rs, ga, ya, and ra, are event classes.

3. Take the gate constraint given in words in Example 4 of the first set of examples in this section and describe it formally in RTL.

4. Recall the Nuclear Power Plant Monitor example of Section 2.2.2. Every 100 ms, the T, F, and S actions are to be executed in sequence in the order shown in Figure 2.5, and completed before the end of the 100 ms cycle.

Express this requirement in RTL.

5. Let SC, DC, SS, SE, D, and U be event classes in the mouse clicker example of Section 3.5.3. Using RTL, describe the relations that must hold among instances of these events.

Hint: Examine a history of instances of these events, ordered by time of occurrence.