Authors

Taha Sidani, Yilmaz Cengeloglu and Ali Sidani

Intelligent Simulation and Training Laboratory

ABSTRACT

The complexity of maintaining a generic and flexible Intelligent Simulation-Based Training System (ISTS) necessitates a coordinated methodology to handle inter and intra process communications. Several issues must be considered before committing to one form of process communication. Such issues involve system portability, real time interaction, distributed system realization, memory, and multi-process communications. This document examines the application of different communication strategies to ISTS. The advantages and disadvantages of using memory-based InterProcess Communication (IPC) facilities in SunOS operating system versus the use of properties for communication in an X Window environment are described. Furthermore, the use of rule-based blackboard architecture to handle communications between modules within the Tutoring group is presented. This research provides the ground work for a flexible and generic Intelligent Simulation Training System.

INTRODUCTION

Most of the research in Intelligent Tutoring Systems (ITS) is directed at developing domain specific systems. These systems lack a generic structure that permits reusability. The portability to another domain requires redesigning the majority of these systems. It is important to differentiate between domain dependent and domain independent modules within an ITS. This will aid in the development and portability of the ITS to other domains. ISTS is a generic simulation-based training system being developed at the University of Central Florida. Developing a generic tutoring system is one of the primary goals of this project. Achieving this requires a modular design to separate the dependent and independent knowledge. The current application of ISTS deals with the tutoring and evaluation of Air Traffic Control (ATC). Currently the LISP version on the Symbolics machine is being ported to a UNIX-based environment. The design of a modularized architecture for ISTS simplifies its adaptation to various simulation-based domains. Its structure can be grouped into three primary processes that execute independently of one another: the Tutoring group, the Simulation, and the Discourse.

Tutoring Group

The Tutoring group is developed using the C Language Integrated Production System (CLIPS). CLIPS is a forward chaining rule based system implemented using the Rete Algorithm. The environment provided by CLIPS allows procedural and object-oriented programming. Its portability, extensibility, capabilities and low cost made it an ideal choice for use in the implementation of ISTS.

The Tutoring group is comprised of a collection of modules categorized into sub-groups describing the Input, Control, Instruction and Domain Expertise. It is accountable for processing the student input, controlling the flow of execution, evaluating and instructing the student in coordination with the domain dependent expert knowledge. The Input Group provides the mechanism by which the student's response to the simulation or the student's desire to modify the simulation are entered into the system. It is made up of two subgroups; the Translator and the Input Filter. They check the student's input against domain syntax and object constraint. Once valid the input is passed to the Simulation. The control group controls the flow of operation by activating and deactivating the appropriate modules. The Instruction group is made up of the Tutor, Evaluator and Student Model. These modules determine how well the student is performing. The Evaluator module is responsible for evaluating the student's input by comparing the action taken against the actions of the domain expert. The Student Model keeps a record of the evaluations and scores for each student. It receives performance data from the Evaluator and Tutor and uses it along with the student's previous data to generate the student's status. This information represents the student's understanding of the domain. The Tutor monitors the training process, by coordinating the instructional aspect of the operation with the Domain Expert, Domain Expert Instructor and the Student Model. It dynamically manipulates the lesson plan to provide the student with an individualized lesson. The last group, Domain Expertise, is made up of the Domain Expert, and the Domain Expert Instructor (DEI). Expert rules and facts for the domain are conveyed by these modules. The DEI is an important module needed to maintain a generic tutor. It provides all of the domain specific knowledge about teaching and evaluating to the Tutor and Evaluator modules, respectively. See Biegel 1989 for a more detailed information concerning each module.

Simulation

The Simulation is a domain dependent process that represents a graphical representation of the domain, in this case ATC. The current simulation is implemented in C using the X Window interface. It is a pseudo-real-time process running in parallel with the Tutoring group and the Discourse. An object-oriented approach is used to supply the objects within the simulation with attributes and behaviors. A number of objects with pre-assigned behaviors (e.g., planes, airports and weather patterns etc.) make up the scenario presented to the student. Establishing new events within the lesson involves the creation and activation of new objects (e.g., aircraft) in the simulation.

Discourse

The Discourse is a communication module to provide an interface between user actions and the system. It handles all of the student interactions with the system. Student actions include mouse and keyboard driven activities such as menu selection and ATC commands entry. The Discourse monitors and conveys all of the student actions to the Tutoring group. It captures student's response to events in the simulation. The trainee can direct the commands to the tutoring system (e.g., ask questions about the current situation) or to manipulate objects in the simulation. An example of such command in the Air Traffic Control domain might be aimed at controlling an aircraft, "DL591 climb and maintain 3000 feet ". Other inputs by the student include sending comments to the instructor. The Discourse module conveys all student entries to the Tutoring group portion for evaluation and record keeping.

COMMUNICATIONS IN ISTS

The need to have separate processes arises from the requirement to perform continuous checking of the interface process and the real time operation of the simulation. The discourse and simulation modules as well as the tutoring group must operate simultaneously and independently of one another. Each process is characterized by an event loop that interprets incoming events and activates the appropriate actions. One of the functions of the interface process is to send student commands to the Tutoring group. Similarly, the simulation relays information to the Tutoring group about the states of the simulated objects. The communication between the simulation and the Tutoring group is an on going process. It requires sending requests in the form of messages and acknowledging the receipt of those requests. Some of the needs of the Tutoring system includes requesting simulation initialization, simulation activation and deactivation, and other information regarding the status of simulation objects and simulation clock, see figure# 1.

Figure # 1: Sample protocol

Providing immediate feedback to the trainee requires the discourse module to continually check for input. Student input events are determined by keyboard entry and mouse driven menu and button selection. The interactions between the Tutoring group and the Discourse can be intensive at times. The Tutoring group continually sends formatted feedback and status messages to be displayed. In addition, requests are frequently forwarded for reading user input from a specified window.

Rule-Based Communications

Modules within the Tutoring group are implemented using CLIPS. The central part of this blackboard architecture consists of rules, facts, frames and a global blackboard. The blackboard uses a global memory storage to hold current and new information in the form of facts. Facts represent valid pieces of information. The structure of a rule is composed of a

condition and an action part. The rule is said to fire (activate the action) when all of its condition patterns match corresponding facts present or newly asserted onto the blackboard. Each module is made up of functions and rules. All of the rules associated with a specific module must have a fact pattern with its name in the condition part. For instance, a rule in the Tutor module might be written as:

(defrule RuleName1

(current-module tutor)

?x <-(student-input freeze)

=>

(retract ?x)

(assert (tutor-freeze simulation)))

The patterns written before the "=>" make up the condition part. The ones that follow represent the action part of the rule. The rule shown above will fire only if both facts in the condition part are present on the blackboard.

The Control module within the Tutoring group is responsible for orchestrating communications between modules. It responds to requests and inputs from the student and/or other modules. It uses a set of generic rules to determine the next appropriate module that should be activated. Modules are activated by assertion of a fact containing the module's name (e.g., add to the blackboard "current-module tutor" to activate the Tutor module). After the activated module processes all of its instantiated rules, control is given back to the Control module so that the next module can be activated. For a detailed description of this process, refer to (Sargeant, Biegel, and Draman 1992).

X Window Protocols

The interface and simulation processes are implemented in C under the X Window environment. The X Window System is a C-based graphical networking environment that provides mechanisms which facilitates linking different workstations together. This operating environment is noted as being the first system that is truly hardware and vendor independent (Johnson & Reichard 1990). It is available on many different types of workstations including Sun, PC, Macintosh, and Cray. A program written under X Window is highly portable to different machines running under the same environment. In short, the X window system is an open environment graphical windowing system that is powerful, flexible and portable.

Applications written under X should meet the standards described in the Inter-Client Communication Conventions Manual (ICCCM). ICCCM consists of a set of conventions created to specify how X applications should interact and how they should cooperate in dealing with shared resources, window and session managers. These conventions standardize communications between X applications and make them highly portable in the X environment. However, X Windows is not a general purpose inter-process communication system; it is not designed for massive data transfer (Johnson & Reichard 1990). Inter-client communications in X is the process by which different X applications pass information to one another. it involves using Atoms, and properties. An Atom is a unique resource ID, 32-bit integer, used to represent a piece of information such as a string or a name. Properties consists of a collection of bytes associated with a window. Each property is identified using an Atom. X Windows provide a number of features for data exchange between applications. Four methods for program-to-program communication in X are considered:

* Window properties

* Sending X events

* Selections

* Cut buffers

Using properties as the means for communication is the most common form of data exchange between programs in X. The collection of named and typed data stored in a property is associated with a specific window. The data stored in the property is maintained by the X server not the X applications. Atoms are used to identify the name of a property and the type of stored data. In order to communicate, programs must establish an agreement with reference to properties, windows, reading, and writing. Applications must know before hand the Window and Property IDs. The Root window is typically used while communicating with properties. The primary reason for the selection of the Root window is related to the availability of an X function that returns the ID for the Root window. Hence, each program can access the same window ID. An example of this form of communication can be described by examining the setup and actions of two X programs. Events within each program are detected by a program specific event loop. Both programs select to be notified whenever a property is written or changed. The window IDs and the property IDs are setup to be the same for both applications. Program 1, the sender, writes to a given property on the Root window. The receiving program will get notified of the change in the property. Program 2 will then read the raw data from the property and converts it from Atoms to strings, see figure# 2.

Figure#2: X Window Communication with Properties

Another form of communication in X deals with events. X Windows permits applications to send events to any window. The receiving application sets up before hand a mask that permits the acceptance of events from one of its own windows. Consequently, the sender must know the window ID of the receiving application in order to forward the event. For this reason, properties are used in conjunction with sending events.

Selections, "cut and paste", provide a very powerful means of transferring information between windows. Because X applications could run on different machines, X uses an interclient communication mechanism to implement "cut and paste". Using the selection mechanism for data exchange is more complex than then using other techniques. Doing a simple data transfer places an unacceptable burden on the application programmer. Selections provide flexibility but the complexity of this process discourages the typical user from utilizing its full capabilities.

There are eight cut buffers in the X server providing a limited global shared storage. There are simple X library routines available for reading/writing to/from the buffers. Using this form of global memory is not recommended. Having other forms of communication in X that are more powerful and flexible makes communicating with cut buffers obsolete.

InterProcess Communication (IPC)

InterProcess Communication involves sharing data between processes and coordinating access to the shared data. SunOS operating system provides several facilities and mechanism by which processes can communicate.

* Messages

* Semaphores

* Shared Memory

Messaging facility provides processes with a means to send and receive messages, and to queue messages for processing in arbitrary order. Messages can be assigned a specific type and each have an explicit length. Among other uses, this allows a server process to direct message traffic between multiple clients on its queue.

Semaphores provide a mechanism by which processes can query or alter status information. They are often used to monitor and control the availability of system resources, such as shared memory segments. Semaphores may be operated on as individual units or as elements in a set. A semaphore set consist of a control structure and array of individual semaphores.

Shared memory allows more than one process at a time to attach a segment of physical memory to its virtual address space. When write access is allowed for more than one process, an outside protocol or mechanism such as a semaphore can be used to prevent contentions.

Process communications in ISTS take advantage of the multiprocessing capabilities of the SunOS operating system. InterProcess Communications (IPC) establishes direct links between processes and avoids unnecessary translations as previously discussed under the X Window protocols. The multiple processes use the message facility to communicate with one another. Each process has one incoming queue to receive messages from other processes. The message queue uses "First-In First-Out" (FIFO) methodology as shown in figure# 3.

Figure# 3: IPC message passing

Messages sent in the queue can be of variable size. The application programmer must insure that the queue space limitations are not exhausted when more than one process use the same queue. The process owning the queue must establish the read/write permissions to allow/deny other processes access to the queue. Furthermore, it is the responsibility of the owner process to remove the queue when it is no longer in use or prior to exiting.

FUTURE RESEARCH

The Simulation, Discourse, and the Tutoring processes operate independently of one another. The modularity embedded within the ISTS architecture enforces functional abstraction hence, non dependencies between processes. The IPC message passing permits multiple processes to communicate with the same process. As figure# 4 illustrates, the Simulation and the Discourse both communicate with the Tutoring process via its queue. The flexibility of such a design facilitates future expansion of ISTS.

Figure# 4: Multiple-to-one process communication

Another objective to this architectural approach is to show that future simulations could be distributed across a number of independent and self-sufficient computers rather than one central computer. Interactions between distributed simulations could be achieved via a Local Area Network (LAN), ethernet. Existing protocols such as SIMNET (Simulator Networks) could provide easy LAN connection (Garvey, 1989). The ATC simulation could be distributed as a Radar simulation, several Flight simulations, and Weather simulation, as shown in figure# 5.

Figure# 5: ISTS realization with distributed simulations

Expanding the ISTS architecture to make use of distributed simulations broadens its usefulness and effectiveness, and facilitates the transmission of information between synergistic simulations. The realism of the simulation increases with distributed systems. In the ATC domain, a pilot using a flight simulator could interface directly with the ATC Radar simulation. This allows real-time interaction between simulations and provides a more realistic pilot behavior.

CONCLUSION

This document describes the means of communications between the various modules and processes of ISTS. In examining the different methods of interclient communications available in X, it is apparent that all of the methods require the use of the X server. In order to establish and maintain communication between two X applications, each application is obligated to go through the X server, see figure# 2. The X Window communication facilities do not establish a direct link between the communicating programs. The X communication protocol is slower than that of using IPC. Using IPC is faster since programs can exchange information directly. There is no need for the sender to convert the information to atoms then retranslate back to strings on the receiving end. However, the programmer is responsible for insuring that the links are initially established and killed at the end of the process. One of the advantages of using X Window communication protocols is having the X server maintain the necessary links between programs. This means that it is the server's responsibility to remove the links and every thing related to it when the program is exited.

Due to the intensive nature of data exchange between the primary processes, the IPC methodology is used to handle the intra process communications between the Simulation and the Tutoring group, and the Discourse and Tutoring group. The inter communications between modules within the Tutoring group is handled by assertions and retractions of facts using CLIPS.

REFERENCES

Biegel, John E. 1989. "The essential components of an intelligent simulation training system". Simulation and AI, 1989 p.54-57.

Biegel, John E. 1988. ISTS system description. Intelligent Simulation Training System lab, Department of Industrial Engineering, University of Central Florida.

Draman, M. 1990. TTESS; a tutorial tool for expert-supervised simulations. Ph.D. dissertation, University of Central Florida.

Garvey, Richard E. Jr. 1989. "SIMNET-D: Extending Simulation Boundaries". Journal of the American Defense Preparedness Association, pp. 40-43.

Johnson , and Reichard. (1990). Advanced X window Applications programming: The basics and beyond! Management Information Source, Inc.

Sargeant, J. M. , Biegel, J.E. , and Draman M. 1992. "MANAGING AND INTERPRETING STUDENT ACTIONS IN AN INTELLIGENT SIMULATION TRAINING SYSTEM". 14th Conference on Computers and Industrial Engineering, March 9-11, 1992, Cocoa Beach, FL.