Annette L. Wilson
awilson@mitre.org
Richard M. Weatherly
weather@mitre.org
The MITRE Corporation
7525 Colshire Drive
McLean, Virginia 22102,
U.S.A.
The ALSP Joint Service Training Confederation has grown from three to six members in 1994. To support the larger confederation, two new capabilities have been added to the ALSP software. In the past every message produced by a confederation member was sent to all other members; now a more efficient distribution scheme is employed that only sends messages where they are required. Additionally, new tools have been provided to assist the exercise managers in the monitoring, troubleshooting, and control of their large confederations. 1 ALSP Architecture ALSP assumes a logical architecture of its components that can be viewed as shown in Figure 1. This grouping is called an ALSP confederation. This is a logical view and does not consider which computers might host which components, or the physical path for communications between the components.
Figure 1: ALSP Logical Architecture 1.1 Actor An actor typically is a warfare simulation. Most existed before integration using ALSP was considered. Most must still operate alone in other exercises. Some actors operate in peripheral roles-global displays, event loggers, etc. In all cases, it is a part of the ALSP philosophy to modify the operation (computer code) of the actor so that it can operate in an ALSP confedera-tion, but to minimize the extent of the modifications. Three major modifications to an actor are required. The first is to recognize that some simula-tion objects in its game space are not its to control. This requires special logic to prevent manipulation of foreign or "ghosted" objects. The second modification is to recognize its responsibility to inform the rest of the confederation of significant changes to simulation objects that it controls. This responsibility requires that changes to significant attributes, such as location, be reported. It also requires that significant events between controlled objects and ghosted objects, like combat, be reported. The third modification requires an actor to coordinate its advance of simulation time with the confederation. While the coordination logic resides in the translator, very often the mechanism of time advance in the actor must be modified. 1.2 Translator A translator is a set of computer code that provides the bulk of the modifications to an actor. The translator may be contained within the actor code or it may be a separate program. In all cases, the translator must be closely tied to the actor to produce an integrated process. While some functions provided by a translator are common to all translators (communicating with the ACM for example), most functions are unique and specific to the actor that the translator supports. 1.3 ALSP Common Module (ACM) An ACM is the glue that holds the ALSP confederation together. Only one version of the ACM functions for all actor/translators, although a separate copy is provided for each as shown in Figure 1. This mechanism provides a common point of interface for all translators. It also permits actors to join a confederation without knowing or caring who the other members are. Services provided by the ACM include: * Coordination of the process of joining and departing from the ALSP confederation. * Coordination of actor local time with confederation time. * Filtering of incoming messages so that only those of interest are received by the translator. * Coordination of the ownership of attributes of objects so that this ownership can migrate between actors. * Enforcement of the ownership of attributes so that actors may only report new values for attributes of objects that they own. 1.4 ALSP Broadcast Emulator (ABE) An ABE is a process that facilitates the distribution of ALSP information. Its primary function is to receive a message on one of its communications paths and retransmit the message on all of its remaining communications paths. This permits configurations like that depicted in Figure 1 where all ALSP components are local to one another (in the same computer or on a local area network). It also permits configurations where sets of ACMs communicates with their own ABE and the ABEs communicate among one another over wide area networks, for example. 2 Evolution of ALSP The ALSP concept formulation evolved through analysis of existing warfare simulations. Based on experiences with aggregate level warfare simulations in use at the Warrior Preparation Center (WPC), MITRE personnel proposed that ALSP be investigated, as an ARPA funded prototyping effort, with the aim of generalizing and systematizing the simulation interface process. ARPA guidance in this investigation was to use as many of the SIMNET, now DIS, principles as possible in the design of ALSP. Principles central to DIS that were used in ALSP are: * No Central Node - simulators joined and departed from the confederation at will * Geographic Distribution - simulators could be distributed to different geographic locations yet exercise over the same terrain * Object Ownership - each simulator controlled its own resources, firing its own weapons and determining the appropriate damage to its systems when fired upon * Message-based Protocol - information from one simulator was distributed to all other simulators using a defined message-based protocol. Additional requirements of aggregate-level simulations that were not a primary concern in DIS are: * Time Management - Simulation times must be coordinated so that the times for all simulations would appear the same to users and so that event causality would be maintained. The goal was to have events occur in the same sequence in all simulations. * Data Management - A method was needed to permit all simulations to share information in a commonly understood manner given each had its own representation of data. This included the need for multiple simulations to control attributes of the same object. * Architecture - A method was needed to permit the simulations to continue to use their existing architectures, yet exist in an ALSP confederation. 2.1 The Laboratory In January 1991, a ground combat simulation, GRWSIM, was selected for use in determining if the ALSP concepts could function in the real warfare simulation world. Analysis confirmed that the GRWSIM code could be modified to participate in a confederation of models. A set of reusable code was developed in Ada to facilitate the integration. Ada was selected because this computer language provides features that ease the development of the required software such as: support for modern object oriented design and a consistent concurrent tasking model across different operating systems. Once the experiments with GRWSIM were completed using reusable ALSP software, the success prompted the next step: a GRWSIM-AWSIM demonstration which occurred in June 1991. The software was again obtained from WPC and modified with reusable code. Success with the joining of these simulations led to the decision to link AWSIM and CBS. In September 1991, an AWSIM-CBS demonstration took place in the MITRE laboratory as a join effort with JPL. Experience with the successful AWSIM-CBS lab demonstrations resulted in a decision to use ALSP in support of a major exercise - Reforger 92. 2.2 Fielding the Software The decision to support Reforger 92 forced a compressed schedule for development of exercise-quality software. The effort was further complicated by realization that the lab architecture for ALSP, where the ALSP software attached to the simulation, was not generally usable. A new architecture was devised, where the ALSP software would reside in a process separate from the simulation and would communicate with it using a message-based protocol. This new architecture caused much of the laboratory computer code to be obsolete. A closely coordinated development process began in September 1991, resulting in a new ALSP architecture and new translators for AWSIM and CBS. In keeping with an ALSP philosophy that warfare simulations are best modified by agencies responsible for maintaining them, three agencies were involved in the development process: MITRE, LANL, and JPL. JPL was responsible for the CBS development with LANL responsible for the AWSIM development. MITRE was responsible for ALSP software development which included the ACM and ABE. In addition to software development, the simulation-to-simulation portions of the protocol required refinement. Representatives of the developing and using agencies undertook this task over several working sessions. The result of this effort was a CBS-AWSIM Interface Control Document (ICD) produced by JPL. 2.3 Exercise Support In preparation for Reforger 92, ALSP was incorporated into several exercises scheduled for earlier in the year, Central Fortress 92 and Ulchi Focus Lens 92 which were held in June and August 1992, respectively. Each exercise offered the opportunity to challenge ALSP's capabilities and expand its functionality. For example, in Ulchi Focus Lens ALSP ran over a wide area network between sites in Germany and Korea without major problems. The Reforger 92 exercise was a US Army, Europe (USAREUR) exercise that was conducted in Germany in September and October 1992. In this exercise, both CBS and AWSIM were executed at WPC. In August 1993, a confederation of CBS-RESA-AWSIM supported Ulchi Focus Lens 93. This exercise was the first ALSP confederation to contain major simulations from the Army, Navy, and Air Force. 2.4 New Requirements The ALSP software continues to evolve to support the needs of the growing confederation and to facilitate confederation management. For example, the ALSP confederation grew from three members (CBS, AWSIM, and RESA) in 1993 to six members (CBS, AWSIM, RESA, CSSTSS, JECEWSI, and MTWS) in 1994. This growth increases demands on computation and communication resources as well as increases the complexity of managing an ALSP-based exercise. To support sending each message to every ACM, the ABE will double its communications demands just to get existing messages to the new actors' ACMs. As the confederation continues to grow, the communication demands will continue to increase. To help manage this growth, the methodology of sending all messages to every destination has been reexamined. Changes brought about by this reexamination are discussed in section 3 below. As the confederation has grown, the task of managing the confederation has become increasingly difficult; the need for better tools to monitor and manage the confederation has become apparent. The new tools for managing the confederation are the topic of section 4 below. 3 Traffic Reduction The ABE design sends all messages to all ACMs. The ACM then filters the message stream based on criteria proved by the actor. While this approach has been sufficient, it is clear that as the number of actors in the confederation increases, the strategy of sending all information to all actors will fail in the face of an N**2 growth in demand for communications and processing. The sections below describes work intended to reduce the demand for communications services and accommodate larger confederations. 3.1 Event Distribution Protocol To address growth questions associated with the assumptions of reliable, order preserving multicast provided by the ABE, MITRE undertook the Event Distribution Protocol (EDP) research project. The project focused on whether more efficient methods for message distribution could be implemented by intelligently distributing object state change information between actors. The EDP project includes extensions to the peer-level protocol used between ACMs, new software to replace the ABE, and statistical study of message traffic in current ALSP confederations. To determine where opportunities for traffic reduction exist, we reviewed the method by which actors become aware of objects owned by other actors in an ALSP confederation. 3.1.1 Object Discovery Process Ideally, the generator of an update message would be able to determine the exact destination and content of each message it produces given knowledge of all the other actor's requirements for information. Such an approach leads to an unacceptable growth in replicated object information among the ACMs because each ACM must make object discovery decisions for all the other ACMs in the confederation each time one of its objects changes state. The object discovery process and the information required to compute it is outlined below. When an ACM receives an update message from the confederation it asks two questions: 1. Is the object currently known (being ghosted) by my client actor? 2. Does this update pass my client actor's filter criteria: a. Is the updated object an instance of an object class which the client actor is interested in? b. Given the object's class is desirable, does the update contain information about object attributes of concern to the actor? c. Within the list of desirable object attributes, do the updated attribute values satisfy all specified range constraints placed by the actor? The result of these questions is applied to the decision square in Figure 2.
Figure 2: The Object Discovery Decision The actions taken as a result of the object discovery decision are explained below: * Update - Pass the newly received attribute values to the actor so that it can modify its perception of the object. * Create - Inform the actor of the existence of a new object and provide it with an initial set of attribute values. * Delete - Instruct the actor to stop including this object in its perception of the combat environment. * Discard - Extinguish the update message and send nothing to the actor. 3.1.2 Object Class and Attribute Based Reduction If the cost of replicating all the information needed to distribute the discovery process across the confederation is too high, then what can be done to reduce the flow of undesired messages between ACMs? The compromise taken in the EDP was to distribute part of the filter criteria among the ACMs so they can apply it to reduce the amount of information they produce but defer the discovery decision to the recipient. If the ABEs are also modified to restrict message flow based on a knowledge of the recipient's needed, most of the "Discard" cases in the discovery decision can be eliminated. It is important to note that only parts 2a and 2b of the filter criteria question above can be distributed. The class of an object and the set of attributes for that class are static for the life of the object. Thus, the discovery decision from a filter criteria perspective is only a function of attribute values. Figure 3 depicts a four ACM confederation with two ABEs joined by a tie link. Each arc is labeled with the partial criteria that restrict the messages that flow along it. For example, ABE 2 will only send messages to ABE 1 that satisfy the criteria for either ACM 1 or ACM 2. Criteria C(i) is the filter criteria received by ACM(i) from its client actor.
Figure 3: Filter Criteria Generated by EDP 3.1.3 Statistical Results In June 1993, an AWSIM-CBS-RESA-TACSIM functional validation test was held at the WPC. This test furnished an opportunity to collect realistic data without the danger of disturbing an actual exercise. The data was then analyzed to determine the reduction in message traffic that would be realized by this distribution scheme. The results of the analysis were very encouraging: most update messages could be shortened to at least one destination and many could be eliminated to one or more destinations. 3.2 Interaction Filtering In all confederations thus far, each actor has received every interaction message. It was then up to the actor to decide whether the interactions were relevant to it. If actors were to define a hierarchy of allowed interaction kinds similar to the class hierarchy, the ACM could screen the interaction messages and discard those which are not of interest to the actor. By distributing the interaction filter to the ABE, further reductions can be made. As an example, consider an air-to-air engagement interaction of interest only to AWSIM and RESA, under the existing methodology, the interaction message would be sent from the initiating actor (say AWSIM) to its ACM, from the ACM to the ABE, from the ABE to the five other ACMs, and finally from the five ACMs to their respective actors (to which only one, RESA, the message was of interest). Under the new methodology, the initiating actor (AWSIM) would send the message to its ACM, the ACM to the ABE, the ABE to the RESA ACM and finally to RESA which is the only actor interested in air-to-air engagements. Though not all interaction message traffic can be reduced so dramatically, this example demonstrates a potential for traffic reduction. 3.3 Traffic Reduction Implementation The ALSP software (ACM and ABE) has been modified to implement the traffic reduction techniques. Interaction filtering between an actor and its ACM was released in ALSP Version 7.0 and has been used during integration testing. The EDP and distribution of interaction filters will be released in Version 7.1 of the software. This version will be released just prior to the March 94 Confederation Test and will be in use for the 1994 exercise season. 4 Management Tools The ALSP Control Terminal (ACT) is used to monitor and control the ALSP software. An ACT can be attached to either an ACM or an ABE. Multiple ACTs can be attached to an individual component; however, a single ACT cannot be simultaneously connected to multiple components. This restriction requires the confederation manager, the person who provides primary control for all ALSP components, to establish an ACT for each component. For a confederation of six actors connected over a wide area network through two ABEs (as might be found in a 1994 Confederation), the manager must monitor eight ACTs. As the confederation has grown, the task of monitoring and controlling the confederation has become increasingly difficult. It is virtually impossible to view eight ACTs simultaneously from a single workstation. 4.1 Confederation Monitor Screen The Confederation Monitor Screen, which can be displayed on any ACT, was the first step in providing a single screen to monitor the entire confederation. This screen provides assurance that the confederation is advancing normally and should there be a problem, some indication of where the problem may be found. The Confederation Monitor Screen is composed using status messages which are periodically broadcast by all components of the confederation. ACM status messages contain information about the actor's state, while ABE status messages contain the list of channels attached to it. Each component uses the status message transmission time and content to build a table of system-wide communications activity and performance. Drawbacks to this tool are (1) the messages used to build the screen are carried by the same communications paths as all actor-generated and inter-ACM messages and (2) the ACT used to display the Confederation Monitor Screen can only control the component to which it is attached. Thus, the manager still requires an ACT for each component. Placing the status messages in the regular message stream allows the system to compute a latency measurement for the communications path. However, since the messages are routed through the ABE and the confederation can be composed of a number of linked ABEs, failure of a single link can cause a loss of visibility into a significant portion of the confederation. The Confederation Management Tool (CMT), to be released with Version 7.1, will alleviate both of these problems at some cost in additional communications channels. 4.2 Confederation Management Tool The CMT monitors the confederation through direct connections to each component. The CMT has the ability to issue a single command and have that command sent to each component in the confederation (e.g. Open Log Files) or to function as an ACT for any component to which it is attached. When the CMT is functioning as an ACT, all of the usual ACT monitor screens and commands are available. The CMT thus provides the capability to control the entire confederation from a single point. The CMT also provides three new views of the confederation: the Communications Monitor Screen, the Object Monitor Screen, and the Temporal Monitor Screen. 4.2.1 Communications Monitor Screen The Communications Monitor Screen displays the status of communications links in the confederation. For each link an item is displayed on the screen which shows the computers and components associated with that link. Alarm conditions are added to the display as they arise; they are: excessive buffer utilization on either end of the link, insufficient timeliness of link status information, loss of link connectivity, excessive link latency, and existence of conflicting connection parameters (communications protocol or host location). 4.2.2 Object Monitor Screen The Object Monitor Screen displays the number of owned and ghosted objects, by class, for each member of the confederation. Object ownership information for a single actor was previously available at each individual ACT Actor Monitor Screen. Now it can be viewed for the entire confederation on a single screen. To provide a uniform basis for comparison, the CMT forms the union of all the object class hierarchies used in the confederation. This unified class tree allows a meaningful juxtaposition of individual actor's object counts. 4.2.3 Temporal Monitor Screen The Temporal Monitor Screen provides a summary of the information available on the Actor Monitor Screen of each individual ACM ACT and that provided by any Confederation Monitor Screen. This includes, the amount of real time since each actor advanced simulation time, the length of time since each ACM received a message from its actor, a running average of the ratio of real-time to simulation-time, a percentage measure of each actor's utilization, and other time related information. The Temporal Monitor Screen allows the manager to determine at a glance whether the confederation is moving forward at the desired rate and, if it is not, an indication of which actor is responsible for the delay. Acknowledgments The EDP work was partially supported by a MITRE Mission Oriented Investigation and Exploration (MOIE) project under contract number DAAB07-93-C-N651. Author Biographies Annette L. Wilson is a Member of the Technical Staff for the MITRE Corporation. She received her B.S. in computer science Magna Cum Laude from Texas A&M in 1986. She participated in the design and development of the production ALSP and EDP software systems. She is currently leading development efforts for the 1994 releases of the ALSP software. Richard M. Weatherly is a Principal Engineer for the MITRE Corporation in their C3 Modeling and Simulation Center. He received his Ph.D. in Electrical Engineering from Clemson University in 1984. He is an original member of the ALSP team and the designer of the ALSP system software. ****************************************************************************** Annette L. Wilson The MITRE Corporation awilson@mitre.org C3 Modeling and Simulation Center (703) 883-6342 (voice) 7525 Colshire Drive (703) 883-3343 (FAX) McLean, Virginia 22102 ******************************************************************************