| Ernest H. Page | Roger Smith | |
| The MITRE Corporation | STAC Inc. | |
| 1820 Dolley Madison Blvd. | 3481 Woodley Park Place | |
| McLean, VA 22102, U.S.A. | Oviedo, FL 32765 |
Our objective in this tutorial is to spare the intrepid discrete event simulationist those moments of doubt by providing a gentle introduction to the current practice of military training simulation. We introduce some of the common terminology, and briefly highlight a few of the current thrusts in research, development and practice. Be aware, however, that this presentation merely scratches the surface of a large topic. The world of military simulation is very broad, and training applications are but a part - albeit an important part - of it. Likewise, any legitimate treatment of military training would fill volumes and is well beyond the scope of this effort. Even limiting our focus to military training simulation, space limitations dictate that some important and interesting topics are omitted here. We have tried to include bibliographic references and URLs most useful to the reader interested in furthering his or her study.
The presentation strongly reflects a U.S. military training simulation perspective, since that is the environment the authors are most familiar with, and no attempt has been made to differentiate military training simulation by national approach. To our knowledge, however, many of the concepts described here correspond directly or approximately to military training simulation concepts outside the U.S.
The remainder of the paper is organized as follows. Section 2 provides an introduction to some common terminology and definitions relevant to military training simulation. A brief historical perspective and a discussion of the current trend toward systems interoperability is provided in Section 3. Section 4 identifies a few of the current research issues in military training simulation, and conclusions appear in Section 5.
A logical first step in familiarization with the military training simulation world is an introduction to the language of military training simulation. If you are unfamiliar with U.S. Department of Defense (DoD) in general, the first thing you will realize is that there is no shortage of acronyms in the DoD vernacular. In this article, we attempt to keep acronym usage to a minimum for readability, but be advised that familiarity with the acronyms is critical to your successful entree into the military simulation arena. A good source for acronym and terminology definitions is (U.S. Department of Defense 1997b).
The second thing you'll discover about DoD is that while quite often definitive sources for terminology exist, both usage and other published sources do not always match the definitive. Perhaps this should not be surprising. The DoD is a very large organization; it is probably not uncommon that the views expressed by someone affiliated with a large organization do not always completely and accurately reflect the official position of the organization itself.
Within the DoD, simulation is applied to support a variety of missions, including: (1) training, (2) analysis, (3) acquisition, (4) mission rehearsal, and (5) test and evaluation. Our focus is limited to the application of simulation for training, although much of what follows applies to each of these missions.
So the DoD lexicon is not without its ambiguities and contradictions. As another example, the same source that seems to preclude Monte Carlo simulation, which inherently contains no notion of time, from the class of things called simulation, offers this definition (U.S. Department of Defense 1997b):
In addition to these basic concepts and definitions, there are a variety of ways that simulations are differentiated within the DoD. We review a few of these taxonomies below.
The categorization of simulation into live, virtual, and constructive is problematic, because there is no clear division between these categories. The degree of human participation in the simulation is infinitely variable, as is the degree of equipment realism. This categorization of simulations also suffers by excluding a category for simulated people working real equipment (e.g. smart vehicles).As noted in Section 3, one of the goals of current DoD M&S initiatives is the creation of synthetic environments that represent the ``seamless'' integration of virtual, live and constructive simulations within a common simulated battlespace.
The Corps Battle Simulation (CBS) is a ground combat model used to train Army and Joint staffs at a variety of levels. CBS is primarily written in SIMSCRIPT II.5 and falls into the category of logical-time simulation. The Modular Semi-Automated Forces (ModSAF) is also (primarily) a ground combat model, but used to train at lower echelons than CBS. ModSAF is written in C, and falls into the category of real-time simulation. Both CBS and ModSAF are interactive models, i.e. they permit user input to occur while the model is running. Both CBS and ModSAF have the capability to pace their rate of execution at some ratio to real time. For CBS this is accomplished by posting specialized events on the event list. For ModSAF this is accomplished by specifying its frame rate. The critical difference between the two (justifying their separation into different categories) comes when the amount of computation required to compute the next state exceeds the amount of real time available before the next state should occur. If at time t=10 seconds it requires 3 seconds to compute the state for time t=11 seconds, what do you do?
Fundamentally, no system can guarantee complete, simultaneous faithfulness to both simulation time and real time. In situations like the one described here, a choice must be made by the simulation. Logical-time simulations, like CBS, observe simulation time. It takes however long it takes to compute the next state. (As an aside, CBS has a capability to attempt to catch up by running faster than the desired rate over a user-specified interval.) Real-time simulations, like ModSAF, degrade or abandon next-state computation, if necessary, in order to maintain synchrony with real time.
The difference between logical-time simulations and real-time simulations is also apparent in their code. Logical-time simulations have the classical discrete event or continuous simulation data structures and algorithms. Real-time simulations resemble real-time systems - their execution is measured by hertz frequency, and they are typically interrupt driven.
Historically, entity-level simulations have been used to train at lower military echelons, e.g. Platoon, Company, and aggregate-level simulations have been used as the basis for training at higher military echelons, e.g. Brigade, Division. A current trend is toward the development of singular simulation systems that train at all echelons. The costs and benefits of this approach are yet to be fully understood.
Historically, military simulations and simulators have been applied in fairly narrowly focused contexts to achieve specific sets of goals. If no single system could fulfill the objectives of a given training exercise, a new system was constructed or the objectives of the exercise modified to accommodate the capabilities at hand. In the mid-to-late 1970s, the idea of connecting training devices, namely simulators, began to take shape.
The first meaningful attempt to interoperate military simulators was the Simulator Networking (SIMNET) project initiated by the Defense Advanced Research Projects Agency (DARPA) in 1983 (Allusi 1991; Ground and Schwab 1988). SIMNET was an effort to interoperate tank trainers to support unit (collective) training, and represented advances in a number of areas including, image generation technologies, low-cost simulator design, and networking technologies.
The success of SIMNET spurred the desire to describe general purpose protocols to support a wide range of network-based training applications. This effort resulted in the formulation of two unique sets of protocols which we briefly describe below.
...to create synthetic, virtual representations of warfare environments by systematically connecting separate subcomponents of simulation which reside at distributed, multiple locations ... The property of connecting separate subcomponents or elements affords the capability to configure a wide range of simulated warfare representations patterned after the task force organization of actual units ... Equally important is the property of interoperability which allows different simulation environments to efficiently and consistently interchange data elements essential to representing warfighting outcomes.The DIS protocols and concept of operations are closely tied to those of SIMNET. Generally, DIS simulations are entity-level, real-time simulations. Communication in a DIS environment is based on the Protocol Data Unit (PDU), a bit-encoded packet for communicating entity state and other types of information identified as useful within the protocol, e.g. weapons fire events. A process known as dead reckoning is used to reduce the number of entity state PDUs introduced onto the network during runtime, by allowing entity state extrapolation between updates. Using dead reckoning, each simulation maintains a low fidelity model of the objects owned by other simulations and uses this model to update the position and orientation of those objects based on the last reported value. For each object a simulation owns, it also maintains the same low fidelity representation. When the low fidelity and high fidelity representations differ by some predetermined threshold, the owning simulation broadcasts a PDU containing the actual (high fidelity) values.
DIS has been used as the protocol underlying numerous warfighting experiments and Advanced Concepts Technology Demonstrations (ACTDs), most notably, the Synthetic Theater of War (STOW) family of experiments.
Prior to 1990, DARPA was working to improve the efficiency of simulation-based training through better hardware infrastructure. Their emphasis on networks and portable computer centers made it possible, so they hoped, for warfighters in Europe and Korea to train at their home bases rather than travel to the Warrior Preparation Center (WPC) in Einsiedlerhof, Germany or the Korea Battle Simulation Center (KBSC) in Seoul, Korea. About the same time the Berlin Wall came down, the DARPA vision of distributed simulation was put to the test by the Allied Command Europe (ACE) '89 exercise. It failed. As is often the case, the exercise did not fail in areas where attention was paid (the network, switches, more rugged computers, etc.) but in areas where attention was lacking - the simulation software. The complexity of distributed computation was greatly underestimated. As the Commander of the Warrior Preparation Center later said, ``The smoke got too thick and the mirrors got too heavy.''
Many of the software problems observed in ACE '89 were traceable to an inconsistent perception of the time and state relationships within the distributed simulation, and disagreement about how simulations should cooperate in modeling combat objects. ALSP provides an ASCII-based message-passing protocol and software infrastructure that coordinates the advance of simulation time, enforces adherence to a common object model of the shared simulation state, and arbitrates contests over the right to modify that shared state.
Fielded in the spring of 1991, the ALSP Joint Training Confederation (JTC), which currently consists of eight Joint and Service simulations, has been successfully employed to support numerous major, large-scale, Joint training exercises, including the annual Ulchi Focus Lens, Prairie Warrior and Unified Endeavor exercises (Miller and Zabek 1996).
At the heart of the HLA is the notion of a federation. A federation is a collection of federates - simulations and other systems - that interoperate using the protocols described by the architecture. A Federation Object Model (FOM), constructed in accordance with the formalism identified in (U.S. Department of Defense 1988a), provides the model specification and establishes a contract between the federates regarding the nature of the activity taking place during federation runtime. Federation execution is accomplished through an HLA Runtime Infrastructure (RTI) which is an implementation of the infrastructure services defined in (U.S. Department of Defense 1988c). In addition to defining services for the RTI, the HLA Interface Specification defines services that must be implemented by federates.
In a typical federation execution, a federate joins the federation, indicates its operating parameters (e.g. information the federate will provide to the federation and information it will accept from the federation) and then participates in the evolution of federation state until the federate departs the federation, or the simulation terminates. FOM data is provided to the RTI at runtime, enabling the infrastructure to provide a level of enforcement with respect to the ``information contract'' that the FOM represents.
In a 1996 memorandum signed by the U.S. Undersecretary of Defense for Acquisition and Technology Dr. Paul Kaminski, the HLA is endorsed as the standard for all U.S.DoD M&S (U.S Department of Defense 1996). The HLA standard supersedes both ALSP and DIS and all DoD M&S efforts must comply with the HLA, receive a waiver, or be retired by 2001.
The need for, and demands on, military simulation are continually increasing. Driven largely by fiscal necessity, an increasing pressure to employ simulation is driving exploration into new methods for modeling combat activities. DoD is currently focusing significant attention in the areas of domain architectures, common terrain representation, behavior representation, multiresolution modeling and synthetic natural environments.
The Joint Simulation System (JSIMS) and One Semi-Automated Forces (OneSAF) programs are attempts to unify the next generation of Service simulations and Semi-Automated Forces simulations, respectively, to eliminate software duplication, lower development costs, provide common user interfaces, and reduce life-cycle costs for using and enhancing the systems. The JSIMS architecture attempts to isolate two distinct classes of simulation functionality (Powell 1996). The first class is domain-independent simulation infrastructure. The second class includes basic representations of simulated objects and the building blocks for creating user interfaces, and external system data exchange. This layer also manages communication with the first layer, allowing specific model builders to focus on their model rather than on the intricacies of the infrastructure for supporting those models. The OneSAF architecture, currently under development, is likely to reflect a similar separation of functionality (U.S. Department of Defense 1997a).
Programs like OneSAF and JSIMS, when viewed in the context of the HLA initiative, illustrate a seeming dichotomy in current DoD approaches to M&S. The former collection seeks to construct large, monolithic simulations that serve many audiences with widely varying objectives. The latter approach (within the context of the broader DoD M&S technical framework) suggests that small, simple, well-defined and narrowly-scoped simulations provide the basis for the application of M&S, with complex problems being addressed by the federation of multiple simulations.
Both JSIMS and OneSAF prominently tout the notion of composability in their architectures. So it is possible that in the end, each of these programs - HLA, JSIMS, OneSAF - may result in the reflection of a common set of modeling principles, blurring or erasing the dichotomy. But it is probably premature to make any predictions or judgements.
To overcome these problems DOD has instituted the Synthetic Environment Data Representation and Interchange Specification (SEDRIS) project. Their intent is to create a common database format that completely supports the characteristics of existing databases. The principles underlying SEDRIS are that the data representation: (1) be complete, (2) support loss-less translation, and (3) be unambiguous.
The approach taken by most CGF systems is to replicate the product of human decision making, rather than the process. Since we do not completely understand the inner workings of the human mind, it is easier to gather information about observed human reactions to certain situations than it is to represent the process of cogitation. However, recent developments in Artificial Intelligence (AI) technologies, e.g. intelligent agents, potentially offer new solutions to this problem.
Solutions to the multiresolution modeling problem are being sought under the DARPA Advanced Simulation Technology Thrust (ASTT) program.
The collection and management of environmental data presents significant challenges, as does the validation of environmental models. Consistent environmental effects in a multiresolution simulation are particularly challenging, and are the subject of investigation within the DARPA ASTT program.
The military training simulation arena is ripe with challenges. Training applications, arguably, are the primary driving force behind several of the current DoD M&S initiatives. While many of the applications and concepts employed in the military training simulation domain bear little resemblance to ``traditional'' discrete event simulations and discrete event simulation concepts, a synthesis of these two cultures is likely to benefit each. We are hopeful that this tutorial is a useful contribution toward such a synthesis.
ROGER SMITH is the Technical Director for STAC Inc. and an Adjunct Professor at the Florida Institute of Technology. He is actively involved in designing, developing, and fielding simulations, having contributed to JSIMS, WARSIM, WIM, JSIGSIM, BLRSI, ADST, TACSIM, AWSIM, ALBAM, and others. He is very active in the simulation community, serving as the Chairman for the ACM Special Interest Group on Simulation and as a member of the editorial board of ACM Transactions on Modeling and Computer Simulation.
This document was generated using the LaTeX2HTML translator Version 96.1 (Feb 5, 1996) Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html camera.
The translation was initiated by Ernest Page on Sat Aug 1 14:40:35 EDT
1998