THE USE OF TCL AND TK

TO IMPROVE DESIGN AND CODE REUTILIZATION

Lisbet Rodriguez Kirk Reinholtz

Jet Propulsion Laboratory California Institute of Technology

Pasadena, California

Abstract Tcl and Tk facilitate design and code reuse in the

ZIPSIM series of high-performance, high-jidelity space- craft simulators. Tcl and Tk provide a framework for the construction of the Graphical User Interfaces for the sim- ulators. The interfaces are architected such that a large proportion of the design and code is used for several applications, which has reduced design time and life-cycle costs.

Backmound

The simulators are typically used during software development to perform unit, regression, and performance tests; and during mission operations to validate command sequences before transmission to the spacecraft. All ver- sions of the simulator are built upon a shared framework that provides a number of features, including the subject of this paper: extensive use of a command language called Tcl and a GUI (Graphical User Interface) toolkit based upon Tcl, called Tk.

The Graphical User Interface (GUI) allows quick and easy access to the monitoring of memory displays, clocks, register contents and more. Most GUI windows on ZIPSIM contain a Tcl or Ci-t monitor that examines the value of variables every time unit and posts the changes to the presentation engine for display via the GUI. The pro- cedures written in Tcl and Tk have a very general structue so that they may be reused in the construction of new objects.

Most of the GUI windows are independent of the implementation of the model containing the data to be dis- played, so it is possible to achieve a high level of reuse by using a single GUI component to display data from several models. For example, any- that contains "memory" (e.g. RAM, ROM, bulk storage devices) uses the same GUI to present the contents of the memory.

The Simulator ArchitectuI.e

The architecture of ZIPSIM can be viewed as consist- ing of two parts: A semantic component that performs the actual simulation; and a presentation component that is used to view and manipulate the simulation as it progresses. The interface between the components con- sists of a number of Tcl commands implemented in the semantic engine that are used to examine and modify the state of the engine, as well as control its execution. The presentation component consists of a mix of mission-inde-

pendent code that provides common control (e.g. "start", "stop", B U breakpoints, trace control) and display (e.g. examination and alteration of memory contents and CPU registers) capabilities, and mission-specific code that dis- plays simulator state structured to the needs of a particular mission (e.g. a status queue implemented as a linked list is displayed as a series of textual status messages, rather than as hex digits that the user must manually decode for links and queue contents).

lk!JUk Tcl ('Tool command language"), is a freely distrib-

uted embeddable language. It was developed by John K. Ousterhout at the University of California, Berkeley. Associated with Tcl is Tk, a toolkit for building GUI appli- cations for the X Window System. Both Tcl and Tk are interpreted, so changes may be applied, even during the execution of the simulator, without the cost of an edit/ compilebmkhm cycle. ZIPSIM is implemented using Tcl as the standard simulator component interface technique. Tk to implement GUI functionality, and C u for the remainder of the implementation.

Tcl is a simple string-oriented language. All data structures in Tcl are represented as strings -- all structures, including procedures and numerical values. It isn't until an arithmetic operation is preformed on same numerical val- ues that Tcl converts them and performs the operation.

Tk is jointly used with Tcl in the construction of Graphical User Interfaces. Tk provides tools for the build- ing of pre-defined widgets and makes it possible to con- struct more complex objects by combining the previously mentioned widgets.

Tk has many "widgets", including Frames, labels, buttons, menus and entries. Because these widgets are defined as structures of the language it is possible to reuse them by merely changing the specifications regarding width, height, color, title, etc. An elaborate combination of widgets has made it possible for our High Speed Simulator to have substantial GUI interface at a fraction of the cost of implementation using older GUI development methods. (see figure 1).

The simplicity of Tcl makes it possible for a GUI object to be implemented in less than an hour. By duplicat- ing the procedure that builds one object and making some parameter and name changes, a whole new and indepen- dent object is built. The general structure of any object

'The work described in this paper was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a wntract with the National Aeronautics and Space Administration.

may be modified and reused without any cost or loss of time.

Because Tcl and Tk are so easy to learn, extremely powerful, and contain so many sophisticated features, they have drastically reduced the time needed for the develop- ment of the simulator interfaces. Thousands of lines of C-H code have been eliminated

GUI W~ndows

The DMS Status window is one of the many windows that are available in the GUI. The DMS (Data Memory Subsystem) is an additional memory for the CDS (Com- mand and Data Subsystem) in the form of a digital tape recorder that is unique to the Galileo spacecraft. It is a four track sequential recorder with a multispeed record capabil- ity and a playback device. The DMS Status window is a very good example of the technique used in the manufac- turing of the entire GUI.

The DMS Status window aids in keeping close inspection on the DMS components to assure that no errors or invalid values are being produced. It consists of two frames -- top and bottom. The top frame is formed by twelve labels. These labels display the status of an element of the DMS (e.g. status, mode, rate). The window is bounded to a monitor that examines the content and updates it if necessary. The bottom frame contains a button widget labeled 'Quit' which has the function of destroying the window and the monitor (see figure 2).

The monitor provides the feature of being able to fol- low the behavior of the DMS status as the simulation is in progress. If the DMS Status window is closed at any point during the execution and then re-opened, all the values are recomputed and updated with the actual values.

All of the GUI windows have a similar architecture to the one described for the DMS. The same procedure may be used for any other window by redefining a few general parameters. Consider the following code (assume that the value of font12 is a 12 point font defined for your system):

proc label-win { title label value) {

set width 30

set height 25

toplevel .$title

frame .$title.top -relief flat -width $width\

-height $height

pack append .$title .$title.top {top fill expand)

label .$title.top.label -relief flat -font $fontl2\

-text [format "%5s %5sW $label $value]

pack append .$title.top .$tide.top.label \

{top fill expand )

1 The command set has the form:

set <var_name> <value>

The field value may be one word, or a series of words enclosed in double quotes ("") or braces ({ 1).

The command toplevel creates a new top-level wid- get. These are identical tofiames except that they occupy top-level windows whereas frames occupy internal win- dows. Label widgets arr: created through the label com- mand. A label is also similar to a frame except that it also displays a text string or bitmap. All widget commands have the form:

The pack command has the form:

pack <option> unas te~widgeu <slave-widgeb \

The option following the command is used to insert one or more children (slave widgets) into the packing order for their parent (the master widget). The options may be afer. append, before, or info. The second set of options may be empty or it may contain specification of side (top, bottom, left, right), request for more space (padx <pixel>, pady <pixel>, expand), fill option (fill, fillx, filly), or posi- tion within its frame (frame center, frame {nlnelelselslwlnw 1).

Now consider we want to build two windows with the same structure, but with two different labels. We then call proc label - win as follows:

label-win "label A" Color Red

label-win "label B" Color Blue

The above procedure calls will invoke label win with different sets of parameters. The resulting objects are shown in figure 3. In this same manner, any number of objects could be constructed and reuse becomes a big ele- ment.

Procedure label-win is a very simple example of the mechanism we have used for our GUI implementation. The examples are very narrow. but show the basic idea of reuse available through the use of Tcl and Tk.

Common Windows

Memory windows and register display windows are two of the types of windows that are available for several of the spacecraft's modules. These illustrate one way of how reusability comes into play. One general procedure exists for the implementation of the memory or register windows. The same procedure is used for all the instances

of these windows. The objects themselves are completely independent of each other but they have the same struc- ture.

The way in which this is implemented is as follows. We use a variable name that is unique to each module (e.g. the module name) as part of the window name. This vari- able is passed as one of the parameters when the call to display the window is made. This builds a window fully unrelated to any other and allows that many memory or register displays be open at once without any difficulties.

The procedures called made from within the proce- dure that builds the window share a common name but dif- ferent body and exists for each module. When the call is made, to get the values of, say a memory range, the mod- ule name is specified. Suppose a memory view is requested for HLMlA and CRClB (see figure 4). The pro- cedures invoked by the GUI would be through:

simsend HLMl A memoryDisplay OxA 0x7A

simsend CRClB memoryDisplay 0x0 0x17

Simsend is mission-independent which allows the issuance of commands directly to a module through a Tcl interpreter. The general format is:

simsend <object-name> <command>

Clock and Perf-0-Meter

The clock and the perf-o-meter are two of the widgets that could be used for any of our simulators with few or no modifications. The clock displays the simulation time and the spacecraft time. The perf-o-meter shows the speed at which the simulation is taking place. These two windows are completely independent from any internal structure of the simulators so the same definition may be reused for all of them. See figure 5.

CLI Mode vs. GUI Mode

The high-speed simulator may be run in Command- Line Interface (CLI) mode or in GUI mode. When using the simulator in CLI mode, it is possible to perform all of the same operations that are provided through GUI mode. The same performance, accuracy, and reliability are pro- vided in either mode in which the user decides to perform the simulation. The only difference between GUI and CLI modes is, of course, the presencelabsene of windows and displays.

a .tcl extension. The Tk code that builds that GUI is placed in a separate file with a .tk extension.

The split semanticlpresentation architecture that the ZIPSIM series uses, when combined with the use of Tcl and Tk, provides for a high degree of reuse. There are two major reasons for this: The presentationfsemantic interface is explicit and so more easily formalized; and the use of Tcl/I'k avoids many source-code edits and parameteriza- tion that would otherwise be necessary. The formalized interface means that presentation code based on the inter- face may be reused on any mission for which the interface makes sense -- and there is a lot of such code, and so a lot of reuse. Tcl is used for all semanticlpresentation inter- faces, and Tcl is string-based (i.e. there are no binary rep- resentations used in Tcl -- everything, including the various numeric types, is reduced to strings within Tcl), so data-typing and conversion issues do not exist, again con- tributing to the reusability of much of the presentation code.

References

[I] Alan Morrissett et al, Multimission High Speed Spacecraft Simulation for the Galileo and Cassini Missions, Proceedings of the Computing in Aerospace 9 Conference, AIAA, 1993.

[2] John E. Zipse et al, A Multicomputer Simulation of the Galileo Spacecraft Command and Data Subsystem, Proceedings of the Sixth Distributed Memory Com- puting Conference, IEEE Computer Society, 199 1.

[3] John K. Ousterhout, An Introduction to Tcl and Tk, Addison-Wesley, 1994.

This feature of the simulator enables the reuse of most of the code implementation. Tcl and Tk provide an envi- ronment where the same procedure calls may be used in both modes. The way in which this is achieved is by plac- ing files that are common to both modes -- files with strictly Tcl implementation (no Tk present) -- in a file with

Figure 1. FASTSIM High Speed Simulator

Figure 2. DMS Status Window

Figure 3. Labels created by using label - win

Figure 4. (a) HLMlA Memory Display, (b) CRClB Memory Display

(a) (b) Figure 5. (a) Perf-0-Meter, (b) Clock