Multiple Level Federation Issues

Gary N. Bundy
David W. Seidel

The MITRE Corporation
1820 Dolley Madison Boulevard
McLean Virginia 22102
gbundy@mitre.org

Abstract

This paper discusses issues revealed as a result of the study of a multiple level federation. A multiple level federation is a group of simulations that model at different levels of granularity using the Runtime Infrastructure of the High Level Architecture to communicate. For each of the issues discussed, a series of protocols to resolve the issue are also discussed.

1.0 Introduction

This paper represents the results of investigation and analysis conducted during the initial phases of an experiment in the use of the High Level Architecture (HLA). The HLA was developed for the Department of Defense by the Defense Modeling and Simulation Office (DMSO) to establish a common high-level simulation architecture to facilitate the interoperability of all types of models and simulations among themselves and with C4I systems. The purpose of this experiment was to investigate linking simulations from three different levels of abstraction and prototype a HLA federation of these simulations. This experiment was entitled the "Multiple Level Prototype Federation (MLPF)." For each of the three levels in the prototype federation a simulation typical of that level was selected. Each of the simulations represent larger federations of simulations. The three levels and simulations selected for this experiment are:

Figure 1 is an example of a multiple level federation.

Figure 1. Multiple Level Federation Architecture Components

1.1 Premise

In conducting an exercise within the Department of Defense, objects need to be represented at multiple levels of detail. The more detailed simulations require more resources to accomplish their modeling and consequently must be restricted to special purposes. By representing objects in an exercise with multiple levels of detail, we can use the detailed simulations to represent pockets that require greater attention to be paid to the ongoing activity. These pockets can be defined based on any of a number of characteristics (fixed geography, sphere of influence around a vehicle, sphere of influence around an activity, etc.). However, we must also model the objects with less detail for those simulations that need a complete view of their area of interest, including activity taking place in the detailed pocket of another simulation.

1.2 Background

The Defense Modeling and Simulation Office has been developing a High Level Architecture (HLA) for modeling and simulation for the Department of Defense (DoD) (DMSO, 1995). The scope of the HLA effort include:

While the goal of the HLA is to have total interoperability, constraints such as legacy systems or real-time participants may impose additional constraints. A federation of federates (a group of simulations interoperating in the HLA) may impose additional constraints and restrictions to support the training goals of a particular federate.

DMSO provides a complete description of the

Figure 2. Layered Federation Diagram

2.1.2 Informal Communication

The second approach is informal. A simulation subscribes to the objects of interest in the MLPF FOM. However, this protocol does create additional problems. Using the AWSIM/R, AFSAF, J-MASSexample, it would be confusing for J-MASS to accept hand-offs from both AWSIM/R and AFSAF, especially objects in AFSAF that originated in AWSIM/R.

2.1.3 Advantages and Disadvantages

The main advantage of using a layered communication protocol over an informal communication protocol is simplification of communication. In a multiple layer federation, the simulations have already been organized into layers. The layered communication protocol takes advantage of this fact uses it to reduce the number of simulations that can hand-off to one another and simplify the hand-off. In addition, the use of layered protocols is a well established precedent in the software field (i.e., architectures). One disadvantage of this approach is that a simulation may have to act as an intermediary without any value added. The one advantage of an informal communication protocol is the lack of restrictions which allow the most natural communication to occur. Of course, this freedom comes at the price of increased complexity.

2.2 Hand-off

A crucial protocol issue that must be decided amongst the federation participants is how to handle hand-offs. A hand-off is when a simulation allows another simulation to control an object or a set of attributes of an object that the first simulation currently owns. Hand-offs will not occur consistently in a controllable manner unless the simulations cooperate and agree to a common protocol for performing hand-offs. We suggest three possible protocols for hand-offs:

  1. Receiving simulation requests to take a hand-off
  2. Sending simulation requests that a hand-off be taken
  3. Simulation manager directs the simulations to give and receive hand-offs
The advantages and disadvantages of each of these protocols will be presented.

2.2.1 Receiving Simulation Requests to Take a Hand-off

This protocol simplifies the interaction of the simulations in a federation and allows the simulations to share objects with little coupling. In this protocol, a more detailed simulation would subscribe to objects in less detailed simulations. As an object approaches the detailed simulation's area of interest (AOI), the detailed simulation would begin modeling the object. When it was ready to take of hand-off of the object, it would use the RTI to make this request. The reverse hand-off is also simplified. When the object leaves the AOI of the detailed simulation, the detailed simulation uses the RTI to request that control of the object be retaken by the less detailed simulation.

2.2.2 Sending Simulation Requests that a Hand-off be Taken

The second protocol requires more coordination amongst the simulations and couples them together. With this protocol, a higher level simulation determines when one of its objects has entered the AOI of another simulation. It then uses the RTI to indicate that an object is available for hand-off.

2.2.3 Simulation Manager Controls Hand-offs

The third protocol uses a simulation manager to control hand-offs. The simulation manager would determine when an object has reached another simulation's AOI, when the appropriate ghosting period had occurred, and when the simulations should hand-off objects. The simulation manager would provide a fair arbitration of hand-offs based upon the overall needs of the federation. Although modules of a simulation manager could be reused, most federations would have unique requirements and a unique combination of simulations requiring the simulation manager to be unique for each federation.

2.2.4 Advantages and Disadvantages

The protocol with the most disadvantages requires the sending simulation to request that a hand-off be taken. The main disadvantage is the coupling resulting from the need for the sending simulation to have internal knowledge of other simulations. The internal knowledge required of other simulations includes the AOIs of other simulations (otherwise the sending simulation does not know if other simulations are capable of modeling the object) as well as the ghosting area required by the other simulations. Another disadvantage is that when the AOIs for the various simulations overlap, the receiving simulations may compete for the hand-off since the sending simulation cannot directly address a particular simulation in the RTI.

The protocol which uses a simulation manager to handle hand-offs has the advantage of being a fair arbitrator. However, the major disadvantage of this approach is that the simulation manager will have to be unique for each federation since the simulations and requirements for each federation will be different. A further difficulty with implementing the simulation manager is that the HLA protocol currently does not provide for addressing a particular simulation.

The protocol that requires members of the federation (i.e., simulations or a simulation manager) to know the least about other members of the federation specifies that the receiving simulation request the hand-off of a particular object when the object has entered its AOI. Other advantages include that in the absence of a simulation with greater resolution, the object continues to be modeled at its current resolution.

2.3 Object Updates

A third protocol issue is how a simulation tracks the modeling activity of other simulations at different levels of abstraction. In our case, how does AFSAF know what flights of AWSIM/R aircraft are doing; similarly, how does AWSIM/R know what AFSAF aircraft are doing. Two approaches were examined:

2.3.1 Information Push

A simulation models the activity of its objects--its normal FOM dictates the how often it must describe their state via the RTI and what attributes must be included in the description. It listens to object descriptions in the form dictated by its normal FOM. To operate in a MLPF environment with the information push approach, the simulation need not change its listening behavior but it must augment its describing behavior, adding descriptions of the object states in terms that other simulations at different levels of abstraction can understand. In order to accomplish this, the sending simulation must understand the timing and content of each of the abstraction levels and must be able to translate to each of them. So, for example, AWSIM/R must be capable of generating detail on each aircraft in one of its flights sufficient for AFSAF to reflect the aircraft in its own modeling database.

2.3.2 Information Pull

As in the previous approach, each simulation models the activity of its objects and its normal FOM dictates the how often it must describe their state via the RTI and what attributes must be included in the description; it listens according to the same dictate. To operate in a MLPF environment with the information pull approach, the simulation's object description process remains unchanged; however it must augment its listening behavior. It must also subscribe to object states in terms that other simulations at different levels of abstraction normally generate. In order to accomplish this, the receiving simulation must understand the content of each of the abstraction levels and must be able to translate from each of them. So, for example, AFSAF must be capable of hearing a description of an AWSIM/R flight of aircraft and disaggregate it into the activity of individual aircraft in sufficient detail to be compatible with AFSAF modeling.

2.3.3 Advantages and Disadvantages

Both information push and information pull require the ability to aggregate from more detailed representations and to disaggregate from less detailed representations. With information pull, a simulation can create an internal representation of a received object, then update that representation using its perception of the simulated battlespace; it can maintain a consistent view of the object more easily. Proper implementation of information push requires that the pushing simulation possess an understanding of the receiving simulation's internal perception of the battlespace, a more complicated problem.

3 Conclusion

This paper discusses issues revealed as a result of the study of a multiple level federation. A multiple level federation is a group of simulations that model at different levels of granularity using the Run Time Infrastructure of the High Level Architecture to communicate. In particular, this study considered the following levels and representative simulations:

The three major issues discussed in this paper are: Although we did not recommend a protocol for each of the issues listed above, some of the protocols have advantages that are not offset with disadvantages. For model communication, using a layered communication protocol decreases complexity while placing only a minor constraint on the simulations. Similarly, with hand-off protocols, having the accepting simulation request a hand-off prevents needless coupling amongst the simulations. And finally, with object and attribute updates, information pull provides a cleaner, more natural representation of external objects.

Acknowledgments

The MLPF project was sponsored by the Defense Modeling and Simulation Office (DMSO) and the US Air Force's Electronic Systems Center (ESC). The project builds on the AWSIM Interoperability with ModSAF project that was sponsored by the US Air Force's ESC) and the Synthetic Theater of War (STOW) program that was sponsored by the Defense Advanced Research Projects Agency (DARPA).

References

Defense Modeling and Simulation Office (DMSO), Preliminary Definition of the DoD High Level Architecture for Modeling and Simulation, 31 May 1995.

Author's Biographies

Gary Bundy is the technical leader for the AIM effort at The MITRE Corporation. He has been with MITRE for over five years. During that time he has supported DoD agencies in integrating military simulations as well as integrating military simulations with C4I systems.

David Seidel is project leader for the AIM effort at The MITRE Corporation. For the past five years he has supported DoD agencies in integrating military simulations. He has over fifteen years of experience in development and application of military wargames.


Postscript Version