The Department of Defense has a long history of using simulations to train soldiers to perform missions and to learn to work together in teams and across command structures. In the area of command and staff training these simulations have typically been interactive, constructive, time-stepped models. Several of these have emerged as the most prominent tools for service specific and Joint training. In order to bring all of the services into a single synthetic environment for Joint operations similar to those experienced during Desert Storm, these models have been joined into a confederation - the Joint Training Confederation (JTC) shown in Table 1.
| Joint Training Confederation | |
|---|---|
| Function | Model |
| Ground Combat | Corps Battle Simulation (CBS) |
| Air Combat | Air Warfare Simulation (AWSIM) |
| Marine Operations | Marine Air Ground Task Force Tactical Warfare Simulation (MTWS) |
| Naval Operations | Research, Evaluation, and Analysis Simulation (RESA) |
| Intelligence | Tactical Simulation System (TACSIM) |
| Electronic Combat | Joint Electronic Combat / Electronic Warfare Simulation (JECEWSI) |
| Logistics | Combat Service Support Training Simulation System (CSSTSS) |
| Missile Launch Warning | Portable Space Model (PSM) |
| Confederation Interoperability | Aggregate Level Simulation Protocol (ALSP) |
The JTC was created from existing models that were not intended to operate together. Each was built to serve a specific customer, focusing the fidelity on the functions that were most needed for the intended customer. The confederation of these models allow all of the services to train together using the model that best serves their needs, but to do so in an environment that is synchronized with the other service models. The creation of this confederation has been very effective, but it has illustrated the difficulties of joining simulations that contain fundamentally different assumptions about the way combat should be modeled. As a result, compromises were arrived at to make the JTC operate.
The models listed in the table have been built, enhanced, and integrated over the past 15 years and are reaching the end of their service lives. As the simulation community considers the creation of the next generation of models to replace these, it is clear that interoperability among them is a primary requirement. In constructing the JTC, two characteristics came to light. The first was that each service had built a large body of software that were duplicates of each other. Each contained functions to manage time, calculate location, manage lists of entities, provide user interfaces, and a host of other services. This duplication presented an opportunity for the application of software reuse techniques across the models. Second, the shadows of a fundamental architecture could be seen running through each of the systems. Each contained tools for scenario generation, after action analysis, data storage, trainee interfaces, controller interfaces, and an engine for the execution of simulation events.
Based on these two characteristics, and motivated by the declining defense budget, an effort to build the next generation of models under a common architecture was explored. This architecture would provide the framework and management structure to take advantage of software reuse and to support broader interoperability capabilities.
The Joint Simulation System Project Office (JPO) is now leading a group of service simulation offices and their contractors in designing and building a simulation factory that can compose software, data, and information from a common library into custom simulations that are able to meet the training needs of different military customers. The Joint Simulation System (JSIMS) uses a Domain Specific Software Architecture (DSSA) that can describe the fundamental components and interfaces of any command and staff training simulation. The domain engineering process developed under DARPA and DISA sponsorship was used to discover the underlying architecture for these simulations. The five step process was:
| JSIMS Domain Components | |
|---|---|
| Component | Description |
| Unit | Cognitive, reasoning behavior of military commanders and staffs |
| Equipment | Physical behavior of combat entities (e.g. tanks, aircraft, ships, radios) |
| Perceived Truth | Organization and storage of Unit’s understanding of the combat environment |
| Environmental Truth | Combat environment, including weather, terrain, oceans, electronic noise, and true locations of Equipment instances |
| Data Collection | Storage of simulation event, state, and management information |
| After Action Review | Tools to support the analysis of information stored in Data Collection |
| Time | Progress and management of simulated time |
| Scenario | Common thread tieing together instances of Unit, Equipment, Perceived Truth, and Environmental Truth that are needed for a training event |
| Source Database | Storage of data from external sources that must be made available to the simulation |
| Session Manager | Tools to provide management of simulation control operations |
| Viewer | Tools for viewing the operations of combat objects |
| Facility | Network, security, and underlying computer management functions |
Software instances of the components can be combined together to provide all of the functions necessary for all phases of command and staff training exercises. Under the JSIMS umbrella, each service will be assigned the development of instances of the components that are necessary for a simulation. Many of the components can be built once, in accordance with all service requirements, and used in any service specific or joint training exercise. Components like Facility, Viewer, and Session Manager are very similar in the legacy simulations of the JTC. Under JSIMS these will be built once and used by all services. But components like Unit and Equipment will be turned into hundreds or thousands of instances of specific decision making processes and combat vehicles respectively. Development of these will be assigned to the service that is most knowledgeable in an area and will adhere to a defined interface specification. The Environmental Truth component is a hybrid of the two previously described groups. It can be divided into land, air, sea surface, sea sub-surface, space, and littoral regions for development by the service that operates in each of these environments. But, these sub-environments must be integrated into a single instance of Environmental Truth in order to provide the interactions needed by simulated vehicles and commanders operating within it.
The twelve components are being refined by further study. The intention is to adhere to OO principles, and to choose components based on the domain rather then computer implementation factors. The architecture described in the JSIMS documents is a big step in this direction, but some refinements must be made to fully reach these goals.
It is clear that the Department of Defense is serious about using advanced techniques for simulation design and development in the future. They have committed to bridging service boundaries to accomplish their goals: