StateClock: a Tool for Timed Reactive Modules - Department of

2000 Conference on Information Sciences and Systems, Princeton University, March 15-17, 2000

StateClock: a Tool for Timed Reactive Modules Jonathan S. Ostroff Department Of Computer Science, York University, Toronto, Canada, M3J 1P3. Email: [email protected] Abstract: We provide an overview of the compositional specification and verification tool StateClock using temporal logic and timed object-based visual system descriptions. Verification of the system is performed module by module using model-checking and theorem proving.

1.0 Introduction The StateTime toolset [4] consists of three tools: a visual system builder for discrete realtime systems, a model-checker for special realtime temporal logic properties such as the realtime response property p ⇒ e 3 q (q holds 3 ticks after p), and a constraint logic theorem prover. StateTime lacks a notion of modules and module composition. Also, the constraint based theorem prover proved inadequate to the more demanding needs of compositional reasoning. The purpose of this paper is to present a new tool called StateClock for the compositional design and verification of discrete realtime reactive systems that are described by assemblies of modules. The basic component of StateClock is the real-time reactive module. Event timers and clocks can be used with ordinary temporal logic to express real-time properties. The resulting compositional nature of StateClock allows the designer to treat much larger systems than can be treated with non-compositional tools. StateClock consists of a system builder for constructing assemblies of modules (which can be instances of classes), a simulator for validating modules, and a translator to

the fair transition systems of the STeP [2] tool for model-checking and theorem proving. The STeP tool has a notion of clocked transition or hybrid systems for describing continuous realtime systems, but these systems cannot be checked automatically with the model-checker. In this paper, we use a combination of modelchecking and theorem proving for modular verification.

2.0 Visual object-based descriptions and modularity Consider the system PING-PONG in Fig. 1 which is organized into three modules: OBS (an observer), PING and PONG. Consider the module PING in Fig. 2. A real time reactive module such as PING has an interface, a specification, a body (its implementation), and an environment. • The interface lists all the variables that the module shares with its environment (other modules). An interface variable is declared to have one of three modes: in (the module can read but not write to it), out (only the module can write to the variable) or shared (both the module and the environment can write to the variable). Variables may be of type boolean, string, integer or integer subtype, enumerated or array. • The specification is a set of temporal logic formulas in the interface variables that describe how the module ought to behave in any arbitrary environment. For example, the modular specification ping in Fig. 2 asserts that if the signal y remains high (true) awaiting the signal z (if it occurs), at a time that the clock c is ticking with c = 3 , then the clock will continue to tick until such time as z goes high at time c = 4 . The job of the environment is to arbitrarily change all the input or shared variables. The envi-


FIGURE 1. A system as an assembly of modules Two examples of assemblies of modules are shown below. SYSTEM is organized into three modules, which in turn may have sub-modules. A module or sub-module may be an instance of a class. PINGPONG consists of three modules: OBS, PING and PONG.

FIGURE 2. The module PING Modular specification ping : (y Awaits z) /\ ct /\ c = 3 ==> ct Until (z /\ c = 4) where c is a clock in OBS and ct asserts the clock is ticking. Interface Variables in y: bool in c: CLOCK out x, z: bool

Local variable ping_d: integer Environment

ronment, in this case, consists of the event arbitrary (Fig. 2) that may change the input y at any moment (lower time bound is zero, upper time bound is infinity) and module OBS (Fig. 3). The environment is generated automatically by StateClock. The action choose(y) in arbitrary will randomly chooses a value for y . The clock c is also an input and should change arbitrarily, except that in this case the clock is set by observer OBS when it observes x going

high, as shown in OBS. If specification ping is verified in this environment (arbitrary and OBS), then any module (e.g. PONG) can be substituted for the environment without the specification or interface of PING changing. • The body implements the specification. The body may introduce new local variables in addition to the interface variables. In StateClock, the body is described in a statechart-


FIGURE 3. The observer OBS Interface in x: bool out c: CLOCK The observer is part of the environment of each module (PING and PONG respectively). The observer does not interfere with any of the signals x, y, z of the other modules. The observer starts the clock c when it detects the signal x going high, and stops the clock 5 ticks later. Clocks can also be count-down, i.e. they can be started at a particular value and they count down with each tick of the global clock.

like notation that supports sequential composition, parallel composition and nondeterminism in hierarchical structures. An arrow drawn from one structure to another is called an event which has associated time bounds, a guard and an update function. Updates must respect the modes of the interface variables, otherwise a syntax error is flagged. If, in any environment, the behaviour of the body of the module m conforms to its specification s , then we write mms . In PING, there is a local integer variable ping_d that is incremented until it reaches a value of 100. The purpose of the local variable is to cause state explosion so

that we can see the difference between verifying the system all at once or compositionally one module at a time. The reactive modules of StateClock allow for real-time descriptions using clocks and event timers. Event timers are used to impose real-time constraints (via lower and upper time bounds) on module events. An event has the form event[low,hi] guard/update. The lower bound ensures that the event is activated only after low ticks of the global clock, whereas the upper bound ensures that the event is taken on or before hi ticks of the global clock provided it is still enabled.

FIGURE 4. Module PONG Interface: in x: bool in c: CLOCK out y: bool Specification pong : (x Awaits y) /\ ct /\ c = 0 ==> ct Until ([]y /\ ct /\ c = 3) Environment arbitrarily change x ; for clock c use OBS (Fig. 3) Local pong_d: integer


Any number of clocks can be declared in a module, and once declared, can be started or stopped in event updates. Clocks may also be used in event guards to express conditions under which the event is enabled. There are two kinds of clocks. Count-up clocks are started at some initial value (either zero or as set by the user); they count up in lock-step with the tick of a conceptual global clock. A count-down clock is started at some initial value and counts down until it reaches zero. Both kinds of clock are useful in system descriptions. Clock values can also be used to assert realtime temporal logic properties. For example if a count-up clock c is started when the condition p becomes true, then the temporal logic formula ( c.start ∧ p ) ⇒ e ( q ∧ c = 3 ) asserts that q must occur three ticks later. In this way, ordinary temporal logic can be used to assert properties approximating those of special realtime temporal logics with response properties such as p ⇒ e 3 q . While tools exist for verifying special realtime temporal logics [1], no such tool currently combines algorithmic and deductive methods as STeP does for ordinary linear time temporal logic. By using clocks and event timers, we can express real-time properties of interest within the framework of ordinary temporal logic. The StateClock tool allows the user to select a module at any level in the project and to view its interface and body, as well as its specification. By collecting the interface and body (with its local variables) all in one window, the designer immediately knows which variables the events of the body have access to. The simulator view (not shown) allows the designer to execute the module (in an arbitrary environment), or to view and execute collections of modules interacting with each other. A mistaken description of an algorithm or system

can often be found in simulation mode, even before model-checking or theorem-proving is undertaken.

3.0 Modular verification Once the body of a module is implemented, the module and its specification are automatically converted to STeP fair transition systems, and STeP can be used to check that the module conforms to its specification (Fig. 5). Since module specifications can be quite complex, it is preferable to use the model checker rather than the theorem prover (which needs greater user guidance) provided the fair transition system (which might deal with infinite state domains) can be reduced to a finite representation. Otherwise, the theorem prover must be used. The rule for composing modules is given by   m 2 ms 2  m 1 || m 2 mr  ( s1 ∧ s2 ) → r  where s 1, s 2 are the specifications of the modules m 1, m 2 respectively. The composed system m 1 || m 2 satisfies requirement r provided the requirement condition ( s 1 ∧ s 2 ) → r holds. m 1 ms 1

The compositional rule can be used for topdown or bottom-up design. In bottom-up development, two pre-existing modules already known to satisfy their specifications are composed, and what must be checked is the requirement condition. In top-down development, a task is decomposed into two or more sub-modules each with their associated specifications that, taken together, satisfy the task requirement. Each module and its specification can then be assigned to a programmer. The programmer must develop a body that will make the module specification valid. The StateClock tool allows simultaneous use of


FIGURE 5. StateClock is the front-end description tool and STeP is the back-end reasoning tool

project.stc

StateClock • modularity • visual and temporal logic descriptions

m.his

STeP m.fts m.spec

• Fair transition systems • First Order Temporal Logic Specifications

• clocks and event timers

• Model-Checking

• simulation/execution

• Theorem-proving

Given a module m, StateClock communicates with STeP via a fair transition system (m.fts) and a temporal logic specification (m.spec). StateClock can also store a simulation run of a module in a history file (m.his). The whole project can be stored and later retrieved from a file project.stc.

both top-down and bottom-up design in a given project. During design, the STeP theorem prover is used to check the requirement condition while the model-checker is used to check that module bodies satisfy their associated specifications.

4.0 Modular verification of PINGPONG We would like to show that the combined system PING-PONG (i.e. modules PING, PONG and OBS) satisfies the global requirement ping_pong given by (x Awaits y) /\ c = 0 /\ ct ==> ct Until (z /\ c = 4)

i.e. once the signal x goes high, signal z will go high 4 ticks later. We proceed as follows: • First check that the module PING satisfies its specification ping (Fig. 2). The environment is the arbitrary event shown in Fig. 2, as well as OBS. By clicking on PING in Fig. 1, the environment is automatically generated, and converted to a fair transition system that includes the environment. The specification ping is shown to be valid using 16,749 states in 5 seconds via modelchecking.

• A similar procedure is performed for module PONG. The specification pong (Fig. 4) is shown to be valid using 31,004 states in 11 seconds. • We must now check the requirement condition ping ∧ pong → ping_pong . The theorem prover discharges this in under a second. By our modular rule, the requirement ping_pong therefore holds for the global system PING_PONG. If we had tried to model-check the complete system PING-PONG for the requirement, it would take 82 seconds and use 260,233 states, which is an order of magnitude increase due to the state explosion problem.

5.0 Conclusion The StateClock tool has been used on two large examples. (a) It was used to show the correctness of the delay trip reactor shutdown software for a nuclear reactor described in [5]. Three versions of the control software are used with the final decision to shut down based on majority voting. (b) StateClock was also used to modularly debug and verify the Therac-25 radiation system described in [3]. In both


cases, the global system was too large to treat at once using the STeP model-checker. Global requirements are usually much simpler to write (and get right) than modular specifications. Modular specifications need to take into account the effects of the environment, which are not needed in requirements. Nevertheless, when our tools run out of steam and smarts, it is necessary to decompose our global system and to work one module at a time without ever having to look at the global system. Acknowledgements Lewis Lo wrote the StateClock software. The translation algorithm for converting timed events with timers and clocks to fair transition systems was done by Eddie Ng. Thomas Armstrong wrote the documentation which can be found at http://www.cs.yorku.ca/~stateclock. This research was supported by NSERC. References [1] Alur, R., T.A. Henzinger, and P.-H. Ho. Automatic Symbolic Verification of Embedded Systems. IEEE Transactions on Software Engineering, 22(3): 181201, 1996. [2] Bjorner, N., A. Browne, E. Chang, M. Colon, A. Kapur, Z. Manna, H.B. Sipma, and T. Uribe. STeP: Deductive-Algorithmic Verification of Reactive and Real-Time Systems. In Computer-Aided Verification (CAV '96), New Brunswick, NJ, edited by R. Alur and T. Henzinger, Springer-Verlag, LNCS 1102, 415-418, 1996. [3] Leveson, N.G. and C.S. Turner. An Investigation of the Therac-25 Accidents. Computer, 26(7): 18-41, 1993. [4] Ostroff, J.S. A Visual Toolset for the Design of Real-Time Discrete Event Systems. IEEE Trans. on Control Systems Technology, 5(3): 320-337, 1997. [5] Ostroff, J.S. Composition and Refinement of Discrete Real-Time Systems. ACM Trans. on Software Engineering Methodology, 8(1): 1-48, 1999. www.cs.yorku.ca/techreports/1998/CS-199810.html