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. 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:
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:
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:
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:
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.
The advantages and disadvantages of each of these protocols will be
presented.
2.3.1 Information Push
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.
Postscript
Version