Introduction

Distributed Real Time Test Kit

 

Debugging DRTSs (Distributed Real Time Systems) is difficult because of timing constraints, interprocess communication and synchronization. 

The traditional dynamic method for debugging sequential software has no timing constraints. For these systems cyclic debugging (run the program until an error shows up, examine the program states, insert assertions and re-execute the program to obtain additional information) is commonly used. However, there are several reasons why this approach can?t be applied in DRTs:

-Processes can't be stopped since the execution is dependent on the time and will produce different outputs. Debugging can't modify the execution trace.

-Lack of a global clock reference and a global state since the different processes can be running in different nodes and the global state is the combination of the states of all the nodes.

-The nondeterministic and nonrepeatable nature of RTDSs rules out cyclic debugging. 

In [Tsai 96] different approaches are classified as: real-time debugging, interactive debugging, deterministic replay, and dynamic simulation. Also examples from different researchers are described.

Architecture


We focus our research to developing practical tools for determining if the execution of a real-time distributed program, as characterized by a captured execution trace, is consistent with a formal description of the program behavior.

The general architecture of our system is shown in figure 1. The RTDS processes use functions from the log library to send log information to the database. 

On the other side, the database server provides the information to the program that evaluates the specifications. The rules or specifications must be written according to the ITCL logic (see next section) and can be stored in a file so that the ITCL program will test all the rules in the file, or can also be checked one by one using the terminal. The program reports whether the specifications hold or not, and in the negative case shows one counterexample.

For testing purposes we have developed a simple program that simulates the behavior of different trains in a Crossroad (see section 3). This program can directly dump the data into a file or send it to the database as shown in figure 2.



 

 

This software was developed by Reid Simmons and Joaquin Lopez Fernandez of Carnegie Mellon University.

This software was funded by NASA-Ames under Contract No. NAS2-00002.

Last modified: Monday, December 04, 2000