An Approach to Monitoring and Assertion-Checking of Real-Time ...

An Approach to Monitoring and Assertion-Checking of Real-Time Speci cations Monica Brockmeyer Farnam Jahanian Electrical Engineering and Computer Science Department University of Michigan Ann Arbor, MI 48109-2122 USA fmonicab,[email protected] Constance Heitmeyer Bruce Labaw Naval Research Laboratory Washington, DC 20375 email: fheitmeye,[email protected]

Abstract

This paper describes the development of a monitoring and assertion checking tool, MAC, which supports monitoring of symbolic execution traces generated by the Modechart Toolset, permitting testing of speci cations early in the design phase and providing a mechanism for evaluating properties of the system on a particular execution trace. This approach avoids the many of the diculties of run-time monitoring and testing such as interference and the probe aect. Monitoring and assertion checking capabilities are provided by the automatic translation of assertions in a declarative language (such as Real Time Logic) into monitoring fragments, written in Modechart, which augment the original speci cation to perform monitoring and assertion checking during simulation.

1 Introduction

Ensuring that embedded real-time systems meet their prescribed speci cations is a growing challenge that faces the industry in the coming decade. The distributed nature of these systems introduces additional complications into the ascertainment of their correctness. Several studies have demonstrated that the cost of detecting and removing software errors increases signi cantly as the development process moves from requirements speci cation toward production [1]. The

This work is supported in part by the Naval Research Laboratory under Grant N00014-94-P2015.

source of safety-critical failures can often be traced to requirements, speci cation, or design errors very early in the software development process [2]. It has been argued that formal speci cation methods can reduce the number of errors in a speci cation by preventing imprecision and ambiguity. Furthermore, formal speci cations are amenable to formal analysis techniques including consistency and completeness checks, validation and testing, and veri cation. Testing, debugging, and monitoring describe a variety of techniques commonly used to guarantee the correctness of computer systems. When applied to realtime systems, especially distributed real-time systems, these approaches must address additional challenges such as interference, the probe eect, and the lack of a global clock. [3]. These diculties can be avoided by performing monitoring and assertion checking in the context of a simulation of the behavior of the system under development. In this paper, we describe the incorporation of a monitoring and assertion checking tool into the Modechart Toolset. The Modechart Toolset (MT)[4] is a collection of integrated tools developed by the Naval Research Laboratory together with researchers from the University of Texas to address these challenges. MT supports the formal speci cation of real time behavior for distributed systems in a language called Modechart [5] and formal analysis via formal veri cation, simulation, and completeness and consistency checking. We develop an approach to monitoring and asser-

tion checking in the context of symbolic executions of Modechart speci cations. This approach is intended to complement the existing analysis techniques in the Modechart Toolset. We develop a Monitoring and Assertion Checking Tool (MAC) which is tightly integrated into the Toolset. In particular, the MAC tool supports monitoring execution traces as generated by the Modechart Simulator. Furthermore, it provides a mechanism for evaluating properties of the system on a particular execution trace. For example, it can be used to detect an undesirable behavior or violation of a design assumption as an execution trace is generated. By combining evaluation of a property with a graphical representation of the execution trace, the MAC tool and the Modechart Simulator together conveniently provide some assurance of the user's intent during the speci cation and design phase. The MAC tool can also be used to invoke user-de ned handlers upon detection of certain properties. The handlers can be used to change the simulator execution pro le or even the system state before the computation resumes. Furthermore, the MAC tool can complement the Modechart Veri er in several novel ways. While the veri er can be used to prove the correctness of a speci cation with respect to a safety property, the MAC tool in conjunction with the Modechart Simulator allows the user to focus explicitly on a subset of the computations. By monitoring a speci cation simulation, the MAC tool can be used to trigger the veri er when certain conditions are observed in a computation. Our implementation of the monitoring and assertion checking tool automatically translates assertions into Modechart fragments in order to provide a speci cation for the monitoring process. These monitoring fragments are symbolically executed together with the original speci cation to provide monitoring and assertion checking capabilities. The remainder of this paper is organized as follows: Section 2 introduces a robot controller example that is used to illustrate the Modechart language and the monitoring and assertion checking tool (MAC) throughout this paper. Section 3 describes our approach to monitoring and assertion checking. In Section 4 we discuss related work in monitoring and assertion checking and in Section 5 we describe the direction of our future eorts.

2 Speci cation in Modechart: A Robot Controller Example

Modechart [5] is a graphical speci cation language based on concurrent nite state diagrams. It provides a compact and structured way to represent real time systems. Although similar to Harel's Statecharts [6],

Modechart is speci cally designed for the speci cation of real time systems. Modechart is extended from Statecharts with constructs for expressing timing constraints. It has a visual hierarchical structure and a small set of well de ned constructs for the de nition of event-driven real time systems. These constructs include modes, modetransitions, events, and timing constraints. During a non-zero moment in time, a mode can be either active or inactive. Informally, the state of a real time system is described by the collection of modes which are active. Modes are hierarchically arranged in a tree structure; there is a top level mode from which all modes are descended and each mode has only one parent. The children of each mode can execute serially or in parallel, allowing Modechart to capture both concurrent and sequential behavior. The hierarchical nature of Modechart also allows speci cations to be evaluated at dierent levels of abstraction. A mode having no children is called an atomic mode. The behavior of a real time system is captured by mode transitions. Mode transitions are expressions which control the exit from one mode and entry into another. These transitions can be speci ed by timing constraints or can be triggered by events in the system or by predicates on the behavior of modes in the speci cation. Events in Modechart include modeentry, mode-exit events, transition events, and external events. If M1 , and M2 are modes, the exit of M1 is indicated by M1!, the entry of M2 is indicated by !M2 , and the transition from M1 to M2 by M1! M2 . External events are represented by single letters, e.g. E . These form the atomic units of a system; assertions are described in terms of timing and ordering relationships between instances of these type of events. Transitions can also be controlled by predicates on modes. For example, the predicate f(M )g indicates that the mode M is active at the current time period. Another useful predicate, f< M )g, indicates that the mode M has been active for at least one unit of time. More precisely, M was entered before the current moment of time, and since then, M has not exited before the current moment. Further discussion of the possible predicates on modes can be found in [5,7]. Finally, more complex mode transition expressions can be formed from triggers and timing constraints. More elaborate triggers can be composed by taking the conjuncts of trigger expressions, and these conjuncts can be disjuncted together with timing expressions. Consider the robot controller for a manufacturing assembly line illustrated in Figure 1. A producer pro-

Position 3

Consumer Process Position 4

SYSTEM (Parallel) ROBOT_CONTROLLER (Serial) RC.PROCESS

180 Degrees

RC.GRAB

{(Arm_Rotation.90)}

{(Hand_Position.Holding)}

Robot Process

90 Degrees

{(Done_Processing.Yes)} RC.WAIT_TO_DROP {(Arm_Rotation.180)}

RC.ROT90.1RC.ROT90.2 {(Arm_Extension.Extended)} RC.EXTEND

{(Position_3.No)} RC.DROP

0 Degrees {(Hand_Position.Empty)} RC.ROT-180 {(Arm_Rotation.0)} {(Arm_Extension.Retracted)}

{(Position_2.Yes)}

Position 1 Production Process

Position 2 RC.WAIT_TO_GRAB

Figure 1: Diagram of a Robot Controller for a Manufacturing Assembly Line

RC.RETRACT

PRODUCER_BELT (Serial) PRODUCER.STOP PRODUCER.START {(P_Belt_Moving.No)} & {(Position_1.Yes)} & {(Position_2.No)} {(P_Belt_Moving.Yes)} & {(Position_2.Yes)}

cess controls a conveyer belt carrying items to be processed by a robot. The producer process is responsible for moving items from position 1 to position 2. When the item is in position 2, the robot picks up the item, rotates away from the belt and processes the item. Next, the robot attempts to place the item on another conveyer belt (position 3) where it is removed by a consumer process who moves it to position 4. These three processes are physically distributed and communicate with each other (as well as with the environment) via a system of sensors and actuators. These sensors and actuators are also speci ed in Modechart. Finally, Modechart is also used to model certain aspects of the environment in which the system operates. This permits expression of various natural constraints on the behavior of the system. The processes, sensors, actuators, and the environment which compose the system are speci ed through parallel modes. Since these modes are root modes of the system, they all become active when the system is started. Figure 2 describes the three controller processes. The producer process, indicated by the serial mode Producer Belt has two major constraints on its behavior. If the belt is stopped and there is an item in position 1 and no item in position 2, the producer process starts the producer conveyer belt. If the belt is moving and there is an item in position 2, the producer process stops the conveyer belt. The producer belt observes the environment through sensors which indicate whether the belt is moving and whether there is an item in position 1 or position 2. It aects the environment through an actuator which starts and stops the producer conveyer belt. The two atomic children of Producer Belt, Producer.Stop and Producer.Start informally indicate the states of having just sent requests to stop and start the producer conveyer belt.

CONSUMER_BELT (Serial) CONSUMER.STOP CONSUMER.START {(C_Belt_Moving.No)} & {(Position_1.Yes)} & {(Position_2.No)} {(C_Belt_Moving.Yes)} & {(Position_2.Yes)}

Figure 2: Modechart Speci cation of Processes for a Robot Controller for a Manufacturing Assembly Line

Since Producer Belt is a serial mode, when it becomes active, one of its children becomes active. Since the mode Producer.Stop is indicated as an initial mode, it becomes active at this time. The mode transition expression, f(P Belt Moving.No)g & f(Position 1.Yes)g & f(Position 2.No)g, describes the states of the three sensors, P Belt Moving, Position 1, and Position 2, stating that this transition is to be taken if all three of these mentioned modes are active at a particular moment in time. The mode entry event, ! Producer.Start, represents a signal to the actuator Start P Belt. The consumer process operates in a similar manner, starting and stopping the conveyer belt to move items from position 3 to position 4. The robot controller moves items from position 3 to position 4, as well as processing them. The constraints on the robot controller's behavior may be stated informally as follows: If an item is in position 2 and the robot hand is empty, the robot extends its arm, then grabs the item, then rotates 90 degrees, then processes the item, then rotates 90 degrees. If there is no item in position 3, the robot arm drops the item, then retracts its arm, then rotates -180 degrees. The robot communicates with the producer belt through the sensor indicating whether there is an item in position 2. It communicates with the consumer belt via the sensor indicating whether there is an item in position 3. It communicates with the environment through the sen-

sors indicating the hand position, arm extension, and arm rotation as well as through the actuators controlling the hand position, arm extension, arm rotation, and item processing. Figure 2 indicates that these sequences of actions are speci ed by sequential modes. As with the Producer and Consumer processes, the Robot process speci es signals to actuators with mode entry events and speci es signals from sensors with mode transition expressions.

Start_P_Belt Start_P_Belt.Wait_For_Request

->Producer.Start Start_P_Belt.Delay

Position_1 (Serial) Position_1.Yes (Serial) M1

(1,1) M2

->Env.Posn_1.No

(1,1)

Start_P_Belt.Now (1,3)

(1,1)

Position_1.No (Serial) M4

M3 ->Env.Posn_1.Yes

Figure 4: Modechart Speci cation of a typical Actuator for a Robot Controller for a Manufacturing Assembly Line

, , , , , , and . The actuators alter the state of the environment. A delay occurs between the request to the actuator and the corresponding change in the environment. Moreover, there is generally some minimum interval of time required between subsequent requests to the actuator. In this speci cation of the an actuator for Start P Belt these two times are the same. The transition Start P Belt.Wait forRequest ! Start P Belt.Delay occurs when the event ! Producer.Start is generated by the robot controller process. After the delay period, which is indicated by the timing constraint, (1,5), the mode Start P Belt.Now is entered. This event is observed by the environment, triggering mode transitions there which in turn trigger mode transitions in the corresponding sensors. The full speci cation contains additional actuators, including Stop P Belt, Start C Belt, Stop C Belt, RotateArm 90, Rotate Arm -180, Grab Item, Drop Item, Process Item, Extend Arm, and Retract Arm. For the sake of brevity, the Modechart speci cation for the environment is omitted. This system concisely demonstrates many of the usual properties of real time systems. Many of the typical safety (including real time) properties can be tested for such a system. For example, one may want sensors include

Figure 3: Modechart Speci cation of a typical Sensor for a Robot Controller for a Manufacturing Assembly Line

Figure 3 displays a speci cation for a typical sensor, while Figure 4 displays a speci cation for a typical actuator. The sensors detect the state of the environment and relay this information to the three processes. Since sensors test the environment only periodically, there is generally some delay in relaying a state change in the environment back to the processes relying on the sensors. As a consequence, it is possible that a sensor will indicate a stale value to the processes. In Figure 3, mode M2 indicates a situation where there is no item in position 1, but this fact has not yet been detected by the sensor. After some delay, the sensor tests the environment again and moves to mode M3 which indicates that the sensor now records the correct state of the environment. The mode Position 1.Yes indicates the state where the sensor records that there is an item in position 1 while the mode Position 2.No indicates the state where the the sensor records that there is no item in position 1. These modes are used by the processes to determine mode transitions. The full speci cation contains several additional sensors to communicate the state of the environment to the controller processes. These

,

Position 2 Position 3 Position 4 P Belt Moving C Belt Moving Hand Position ArmExtension Arm Rotation Done Processing

,

to know \Does the robot process ever enter the mode when there is no item in position?" or \Does an item ever wait in position 2 more than 20 time units before being processed?"

RC.Process

3 Integration of Monitoring with the Modechart Toolset

In this section, we discuss the implementation of the Monitoring and Assertion Checking tool (MAC) and describe how monitoring is performed on the execution of the robot speci cation and how checking a constraint on its behavior is accomplished.

executed together with the original speci cation generating an execution trace that highlights the violation of the original assertion. What is attractive about this approach is that instead of generating an operational description (or algorithm), an indicator of the status of the assertion is provided. Assertions

3.1 Approach to Monitoring and Assertion-Checking Monitoring in the Modechart Toolset

The MAC tool complements the existing tools in MT, allowing testing to take place for program speci cations and assertions for which formal veri cation is impractical. This tool provides valuable feedback to system designers during the initial design process. Users of the Modechart Toolset enter speci cations via the speci cation editor. The speci cation editor has a graphical interface via which the user draws the modes and transitions which comprise the speci cation. Generally, once a user has entered a speci cation she or he will want to perform certain applicationindependent consistency checks. The static analyzer checks the speci cation to guarantee that the speci cation is well-formed and fully speci ed. After these static checks have been performed, analysis of the more dynamic properties of the system may be desirable. The two tools for checking dynamic properties of the speci cation are the Modechart Veri er and the Modechart Simulator. The veri cation tool provides a model checking approach for verifying properties of speci cations by examination of a computation graph using a model-checking approach. The veri er is complemented by the Simulator Tool. The simulator generates a symbolic execution of the Modechart speci cation. One use of the simulator is to ascertain whether a Modechart speci cation satis es the developer's intent. The tool user can generate an execution trace and examine it for errors or variations from informal speci cations of the system. The MAC Tool is a component of the Modechart Simulator. The key idea is to augment a Modechart speci cation with a monitoring fragment which represents the assertion to be checked. The monitoring fragment, also expressed as a Modechart speci cation, is used to represent the satisfaction or violation of an assertion. The goal is to use the Modechart simulator to produce a possible execution trace of the augmented speci cation. The monitoring fragment is symbolically

Modechart

Original Modechart Specification

RTL

Monitor: Fragment Generator Extended Modechart Spec.

Profile

Event List and Handlers

Simulator

Event Sequence

Monitor: Satisfiability Checker

User-defined Handlers

Log File

Figure 5: Implementation Design Figure 5 illustrates the MAC Tool and its relationship to the Modechart Toolset. As described later in this section, there are several ways to specify an assertion. The Fragment Generator produces a Modechart speci cation designed to perform monitoring during simulation. This supplemental speci cation (or fragment) is appended to the original speci cation. The MT simulator produces possible execution traces from a Modechart speci cation and a user-de ned pro le. The monitoring speci cation is symbolically executed along with the original speci cation. The execution traces generated by the MT simulator are examined by the Satis ability Checker to test for violations of system constraints. Satis ability checking is simpli ed to checking for particular events generated by the newly created monitoring fragment. The tool also supports user-de ned handlers that are invoked by the monitor when a particular property is satis ed or a violation is detected. There are several ways in which assertions can be speci ed by the user:

(a) The user may provide his or her own monitoring fragment as a Modechart speci cation. This allows the user the maximum exibility in terms of what kind of properties can be monitored. Modechart monitoring fragments can be developed in the speci cation editor in much the same manner as are ordinary system speci cations. The only real dierence is that the user must identify to the MAC Tool which mode represents a violation of the assertion and what handler should be invoked upon entry to the violating mode. (b) Classes of assertions which are supported by the MT veri er are also supported by the MAC tool. These assertions are speci ed in Real Time Logic via a graphical, forms-based interface. (One such a form is displayed in Figure 6.) The user lls the relevant information into the RTL formula, but is not required to write RTL formulae from scratch. Each of these assertions corresponds to a Modechart monitoring fragment. The necessary information is lled in the fragment and the resulting fragment is attached to the original Modechart speci cation. (c) The user can specify more complex assertions, composing primitive relationships described above in part (b). Composition of primitive assertions is described in [8]. Again the user can ll mode names into a form to specify the primitive assertions; these are then very easily composed using the usual logical connectives. In this case, the MAC Fragment Generator composes monitoring fragments written in Modechart to develop a complex monitoring fragment tailored to the user's request. The resulting fragment is appended to the original speci cation and simulated together with it.

3.2 A Monitoring Example: The Robot Controller Revisited

In Figure 7, the robot example described above has been supplemented with a monitoring fragment. In this example, the assertion to be monitored is designed to test whether the mode RC.Process is ever active for fewer than 6 time units. The mode Monitor contains the monitoring fragment. This fragment could be provided by the user or it could be generated by the tool to provide monitoring for an assertion speci ed in RTL. As long as the mode RC.Process stays active for at least 6 units of time, the system stays in modes Monitor.G1, Monitor.G2, or Monitor.G3. However if the mode exits earlier, the system will enter mode Monitor.B1.

Monitor (Parallel) ROBOT_CONTROLLER (Serial)

Monitor (Serial)

RC.PROCESS

{(Arm_Rotation.90)} RC.GRAB {(Hand_Position.Holding)}

{(Done_Processing.Yes)} RC.WAIT_TO_DROP {(Arm_Rotation.180)}

RC.ROT90.1 RC.ROT90.2 {(Arm_Extension.Extended)} RC.EXTEND {(Position_2.Yes)} {(Arm_Rotation.0)}

RC.ROT-180

{(Position_3.No)} RC.DROP

MONITOR.G1

MONITOR.G3

{(Hand_Position.Empty)} {(Arm_Extension.Retracted)}

RC.WAIT_TO_GRAB RC.RETRACT PRODUCER_BELT (Serial) PRODUCER.STOP{(P_Belt_Moving.No)} & {(Position_1.Yes)} & {(Position_2.No)} PRODUCER.START

S.RC.PROCESS-> & {S.RC.PROCESS Hand_Position

Done_Processing

Arm_Extension

Position_3

Arm_Rotation

Position _4

Rotate_Arm_-180

Extend_Arm

Grab_Item

Drop_Item

Retract_Arm

Process_Item

S.RC.PROCESS->

S.RC.PROCESS-> & ->MONITOR.G3

MONITOR.B1 C_Belt_Moving

Start_C_Belt

Stop_C_Belt

Environment (Parallel)

Figure 7: A Modechart Speci cation of a Assembly-Line and Robot Arm Controller with Monitoring Component

It may be noted that there are many possible Modechart fragments which could be used to monitor this assertion. The particular fragment shown in Figure 7 is designed for simplicity. Later, we demonstrate another approach to monitoring a delay which can be composed with other monitors to monitor more complex assertions. Figure 8 contains a simulation of the robot together with the monitoring fragment as generated and displayed by the Modechart Simulator. Mode names are listed on the vertical axis on the left and the elapsed time is displayed across the top. A thick horizontal line indicates the period of time during which each mode is active. The particular execution displayed violates the delay assertion. It can be seen from this diagram that at time point 27, RC.Process becomes active and exits at time point 32. Moreover, at time point 32, the mode Monitor.B1 becomes active, while the mode Monitor.G2 becomes inactive.

4 Related Work

In this section, we highlight the relevant work in this area. For a more complete discussion see [8]. The foundations for our work are found in [9] which develops the framework for understanding a system computation in terms of an event-based model. A more formal approach to real time monitoring, including the development of the idea of a computation pre x is provided in [10]. More attention has been given to the issues of online or run-time monitoring than to that of monitoring and assertion checking of symbolic executions of real time systems. Run-time monitoring systems must address problems related to the probe eect including perturbation and event reordering, in addition to the issues we describe. See [3] for many of the major con-

Figure 6: Specifying an Assertion via the Forms Interface tributions with regard to distributed non-real time systems as well as several which address monitoring in the context of distributed real time systems. Special hardware support for collecting run-time data in real time applications has been considered in a number of recent papers [11{13]. These approaches introduce specialized co-processors for the collection and analysis of run-time information. The STATEMATE system [14], based on Statecharts [6], provides symbolic execution of system speci cations. In an approach similar to ours, these executions can be monitored via special \watchdog" code which is de ned by the user in Statecharts. There is no automatic generation of watchdog code. History-checking of TRIO speci cations is provided in the recent work of [15]. TRIO is a rst order temporal logic which deals with time in a quantitative way by providing a metric to indicate distance in time between events. History-checking is provided by applying a tableaux-based algorithm to a history (execution trace) of a TRIO speci cation.

5 Future Work and Conclusions

In this paper we have presented a framework for monitoring execution traces generated from Modechart speci cations. We have described an approach to monitoring assertions based on translating assertions speci ed in Real Time Logic into monitoring fragments speci ed in Modechart. An implementation of a monitoring and assertion checking tool (MAC) for for the Modechart Toolset has been completed. Future work includes enriching the Modechart Toolset by extending simulator options to allow developers more control over the generation of execution traces. Ideally, the monitoring system would be capable of providing feedback to the simulation to permit \steering" of an execution. In addition, we would like to augment the user interface to the simulator tool with

an animated display of the execution of the speci cation. An animated display would use color or highlighting to indicate active modes and enabled transitions. Finally, we would like to incorporate actions into the Modechart Toolset. Actions are procedures attached to modes that are executed upon the occurrence of a mode-entry event. In addition to providing Modechart with general data handling capabilities, actions would provide a valuable extension to the monitoring and assertion-checking tool. For example, actions connected to monitoring fragments could compile performance statistics concerning the simulated execution.

References

[1] D. Gabel, \Technology 1994: Software engineering," IEEE Spectrum, vol. 31, no. 1, pp. 38{41, january 1994. [2] N. G. Leveson. Software safety. 11th IEEE Workshop on Real-Time Operating Systems and Software, May 1994. Invited Talk. [3] J. J. P. Tsai and S. J. H. Yang, editors, Monitoring and Debugging of Distributed Real-Time Systems, IEEE Computer Society Press, Los Alamitos, CA, 1995. [4] P. C. Clements, C. L. Heitmeyer, B. G. Labaw, and A. T. Rose, \MT: A toolset for specifying and analyzing real-time systems," in Proc. IEEE Real-Time Systems Symposium, December 1993. [5] F. Jahanian and A. K. Mok, \Modechart: A speci cation language for real-time systems," IEEE Trans. Software Engineering, vol. 20, no. 10, , 1994. [6] D. Harel, \Statecharts: A visual formalism for complex systems," Science of Computer Programming, vol. 8, , 1987.

Figure 8: Simulation of Robot with Monitoring Fragment [7] A. Rose, M. Perez, and P. Clements, \Modechart toolset user's guide," Technical Report NRL/MRL/5540-94-7427, Center for Computer High Assurance Systems, Naval Research Lab, Washington, D.C., February 1994. [8] M. Brockmeyer and F. Jahanian, \Monitoring and assertion checking of real-time spec ciations in modechart," Technical Report 95-269, Computer Science and Engineering, The University of Michigan, Ann Arbor, MI, October 1995. [9] F. Jahanian, \Run-time monitoring of real-time systems," in Advances in Real-Time Computing, S. H. Son, editor, chapter 18, Prentice-Hall, Englewood Clis, NJ, 1994. [10] F. Jahanian and A. Goyal, \A formalism for monitoring real-time constraints at run-time," in Proc. of Fault-Tolerant Computing Symposium (FTCS20), June 1990.

[11] D. Haban and K. G. Shin, \Application of realtime monitoring to scheduling tasks with random execution times," IEEE Trans. Software Engineering, vol. 16, no. 12, pp. 1374{1389, December 1990.

[12] H. Kopetz, A. Damm, C. Koza, M. Mulazzani, W. Schwabl, C. Senft, and R. Zainlinger, \Distributed fault-tolerant real-time systems: The MARS approach," IEEE Micro, vol. 9, no. 1, pp. 25{40, February 1989. [13] J. J. P. Tsai, K.-Y. Fang, and H.-Y. Chen, \A non-invasive architecture to monitor real-time distributed systems," IEEE Computer, vol. 23, no. 3, pp. 11{23, March 1990. [14] D. Harel et al., \Statemate: A working environment for the development of complex reactive systems," IEEE Trans. Software Engineering, vol. SE-16, no. 4, , April 1990. [15] M. Felder and A. Morzenti, \Validating real-time systems by history-checking trio speci cations," in Procedings of the 14th International Confernence on Software Engineering, New York, NY, 1992,

ACM Press.