Command Forces: An Extension of DIS Virtual Simulation - CiteSeerX

MITRE INFORMAL REPORT Synthetic Theater of War Project

Modeling and Simulation Technical Center

Command Forces: An Extension of DIS Virtual Simulation Judith S. Dahmann Marnie R. Salisbury Lashon B. Booker David W. Seidel Presented to:

Eleventh Workshop on Standards for the Interoperability of Defense Simulations September 1994 Orlando, Florida

The MITRE Corporation 7525 Colshire Drive McLean, Virginia 22102

94-105

COMMAND FORCES: AN EXTENSION OF DIS VIRTUAL SIMULATION Judith S. Dahmann Marnie R. Salisbury Lashon B. Booker David W. Seidel The MITRE Corporation 7525 Colshire Drive McLean Virginia 22102.

Abstract Command Forces (CFOR) is a concept that incorporates explicit modeling of battlefield command and control (C2) in virtual simulation. CFOR extends the Distributed Interactive Simulation (DIS) architecture by adding a new class of DIS entities (command entities) and explicit representation of the information exchanged among these entities (Command and Control Simulation Interface Language). Command entities themselves are structured in a layered architecture separating general DIS interface capabilities, command vehicle representation, command entity information services, and command decision making. CFOR utilizes the basic DIS virtual simulation architecture for platform ground truth information exchange and interaction (e.g., Entity State PDUs) and transmission of CCSIL (i.e., Signal PDUs). 1

Vision and Goal for CFOR Beginning with SIMNET, the promise of entitybased virtual DIS has grown. By providing a realistic, man-in-the-loop synthetic environment for training and concept evaluation, virtual simulation provides the opportunity for the DoD to experiment with real-life combat situations in a simulated environment, interacting with one another and with simulated entities representing friendly and opposing forces. A goal of DIS proponents is to represent increasingly larger-scale and more diversified military operations in virtual simulation, extending DIS to incorporate larger numbers of active entities and to represent a wider range of combat and environmental effects. They envision that commanders at all echelons, ultimately to the Joint Task Force Commander and his staff, will be able to operate in a fully virtual combat theater representing both conventional regional contingency operations and non-traditional military operations. By providing battlefield representation to the resolution of the fighting entities, this expanded virtual battlefield will

provide a dynamic, realistic environment for exercising the next generation of military requirements. A key element in achieving this goal is the ability to represent both fighting forces and their commanders in software. Current semi-automated forces (SAFOR) development is recognized as providing a first generation semi-automated forces capability. SAFOR technology allows the virtual battlefield to be populated with a useful, but not exhaustive, collection of combat entities at the individual platform and small unit levels (platoons, sections, batteries, teams, etc.). To support extension of virtual simulation to largerscale applications, CFOR extends the basic DIS architecture to incorporate explicit, virtual representation of command nodes, C2 information exchange, and command decision making. 2

CFOR Technical Approach Extension of DIS to incorporate command and control is based on four fundamental ideas (see Figure 1). 1. C 2 can be represented in terms of the interactions and behaviors of command entities The CFOR technical approach for incorporation of C 3 into the virtual simulation environment is based on the close match between the real-world C3 process and the SIMNET/DIS paradigm. While C2 relationships are typically depicted in terms of the hierarchical relationships among commanders at different echelons, the physical instantiation of C2 on the battlespace can be viewed more directly as interactions among autonomous decision-making entities. The battlespace is composed of physical platforms (e.g., tanks, aircraft, ships). Each of these platforms has a physical representation and multiple behaviors. To the extent that a platform hosts a commander, it is also the locus of command decision making behavior, and can be considered as a "command entity." Command entities are virtual military decision makers at different echelons (see Figure 1). They might represent the individual or collec-

Command Forces: An Extension of DIS Virtual Simulation

Page 1

SAFOR Battalion Workstation CCSIL Interface

Company Command Entity

Small Unit Commander and Vehicle Automated Forces CCSIL Interface

-- DIS --- CCSIL --

Figure 1. Example of DIS Extension to Incorporate C 3 tive behavior of a commander and his staff. The effects of a command entity decision process are communicated to other command entities in the chain of command through message exchanges across the battlespace, and eventually result in action by platformlevel battlefield entities. 2. The C 2 process is an information flow process among command entities. Individual command entities (e.g., company team commanders or command staffs at battalion and above) work together through the exchange of information. This includes standard interactions such as operations orders, time-driven information such as status reports and situationally triggered exchanges such as spot reports and fragmentary orders (FRAGOs). At the macrolevel, representation of the C2 process is based on these information exchanges as represented in a Command and Control Simulation Interface Language (CCSIL, pronounced “cecil"). Through exchange of a structured set of messages, CCSIL reflects the content of real life exchanges among military decision makers. CCSIL draws on the experience of the modeling and simulation community in the C 2 modeling domain. In particular EAGLE, the next generation TRAC OAC analysis model, implements a hierarchical representation of C2 , with communication among command levels based on explicit language representation (i.e., Battle Management Language or BML). One component of BML is an OPORD metaphor. Similarly, BDM's Action-Cognition Behavior Model (ACBM) SAFOR implementation provides an explicit language representation for C2 interactions. CCSIL incorporates several components. First is a standard data structure which is used across command levels and across the military services; the contents of this structure vary by application. Second is an enumeration of terms and battlefield concepts that define the semantics of the messages to ensure consistency in use and interpretation. By using this interface language to specify interactions among command entities, individ-

ual developers are free to represent the behavior of those entities using different technical approaches, permitting diverse concurrent developments. However, coordination among development efforts is important to ensure that a consistent set of behavior is manifest across echelons. This point is very important if the command entities are to effectively work together to present a coherent view of the command process. While opportunities for distributed and concurrent development of elements are sought, the result needs to be considered as an integrated system. A consistent perspective must be sought on the meaning of CCSIL concepts and the degree of intelligence possessed by each level of command. This requires more than simple agreement of terms. It also requires the same understanding of how behavioral capabilities are associated with behavioral representation. 3. The CFOR approach to information flow supports a faithful representation of real world communications. This is true both procedurally and physically (i.e., subjected to battlefield effects). Exchange of CCSIL messages will be representative of the information available to commanders. As will be noted in the discussion of the command entity architecture below, virtual command decision makers will have access to information about the world through several channels: their own direct sensations of the world through their own virtual view port (or system sensors) as well as information reported to them through CCSIL messages. This access to information is intended to mirror the information available to an actual battlefield commander. The exchange of CCSIL messages will be handled through DIS Signal PDUs. CCSIL messages will be subject to battlefield effects to the extent that DIS supports communications modeling. 4. The C2 decision process is represented in the individual command entities—the originators and recipients of information exchanges. This is a micro-level view of the decision process. The command entity C2 behavior varies with the level of command (company commanders should be modeled differently than battalion command posts), and the representation of command entity behavior is independent from the representation of information exchanges. C 2 behavior is represented in the command entities. While selected vehicle and small unit commander behaviors have been adequately represented in SAFOR software, expansion to higher echelons of command implies a qualitative “jump” in the required capabilities of the SAFOR. To emulate the higher-echelon commanders, command entities must be capable of generating commands to subordinates, as well as reacting to those from superiors; and they must possess a wide repertoire of possible decision behaviors to accommodate any one

Command Forces: An Extension of DIS Virtual Simulation

Page 2

and coherent C 2 activity. However, this is belied by two factors Command Decision Processes • Interoperability in real C2 processes is not achieved solely through information flow. For example, commanders share a base of knowledge and training that greatly reduces their need for exCE Information Services plicit communications, and this base of information is not part of the routine C2 Services Comm Platform information flow. Services Servicer Tactics, • From a software standpoint, it is not Techniques, Missions, wise to treat a command entity as a Missions, Sense, Procedures Tasks "black box." Two examples enforce Tasks Perceive this statement: Requirements to monitor command entity activity suggest Comms the need for conventions regarding Environment Move how C2 state information is mainEvaluation Terrain tained for an entity; and contributions of multiple simulation developers can Evalu Unit Info be leveraged more effectively if comOther ation Shoot mon Command Entity functionality is organized in an open, modular, and extensible manner. These issues all have implications for how command entities are organized to SAF / CE Baseline Infrastructure process the variety of information needed to make command decisions. Raising CCSIL Network Interface ModSAF such questions about entity implementations constitutes an apparent Figure 2. CFOR Technical Reference Model departure from the DIS paradigm in which entities are under no impleof the essentially infinite variations in battlefield condimentation constraints beyond those imposed by the DIS tions that they may encounter over the course of an exnetwork protocols. However, this aspect of the DIS ercise. ModSAF, ARPA's latest example of SAFOR paradigm was designed to meet the requirements of technology, is capable of modeling the behaviors of modeling the physical interactions among entities. The platforms and small units with much more sophisticaDIS protocols define a common interface for each entity tion than did its predecessors, but it can be expected to that ensures interoperability and consistent physical show only modest increases in the reactive behavioral interactions on the virtual battlefield. Analogous rerepertoire. While it will be necessary to expand the quirements exist for the C 2 interactions among entities. numbers and behaviors of entities modeled in ModSAF, Accordingly, the CFOR framework includes an archithe real challenge in developing CFOR is to create a full tecture for command entities that extends beyond the repertoire of command behaviors at Company, DIS network interface to provide a well-defined, comBattalion, and higher echelons. mon interface for all command decision activities. Ultimately, CFOR will support one or a few human Command entities are under no implementation conoperators controlling large numbers of simulated straints beyond those imposed by the interface specified warfighting forces. Human interaction with the CFOR by the architecture. In this way, the CFOR framework extends the basic tenets of the DIS paradigm into a new will be based on real-world C2 procedures. On the realmode of entity interactions. 2 world battlefield, C is exercised through communication: that is, through the issuance of orders and the isA technical reference model describing the comsuance and receipt of reports and requests. The human mand entity architecture is depicted in Figure 2. The arCFOR controller will utilize the same tools to command chitecture promotes interoperability and coherent C2 the computer-generated forces. activity by providing a shared infrastructure, a common set of information and computing services, along with a 3 Command Entity Architecture well-defined applications interface. There are three layThe macro-level view of the CFOR framework sugers in this architecture: Applications Layer, Information gests that CCSIL message exchanges are sufficient to Services and Utilities Layer, and Baseline Infrastructure ensure both interoperability among command entities Monitor

Command Entity Application

Command Forces: An Extension of DIS Virtual Simulation

Page 3

Layer. These elements of the technical reference model are discussed in the following paragraphs. 3.1 Command Entity Applications The Applications Layer is where the command decision-making software resides. As noted above, this aspect of a command entity is under the purview of the simulation developer organizations; they are free to implement their own approach to making command decisions. Another kind of application is the command entity monitor. This is a tool for monitoring the content of messages received and transmitted by a command entity. It will provide a useful view of C 2 activity for exercise controllers. 3.2

Command Entity Information Services The second layer of the architecture contains the services and utilities that provide the information needed to support command decisions. These services impose few restrictions on how the decision process is modeled. They avoid making any inferences or judgments that should be made by command entities. The functionality of these services and utilities may be adjusted over time to represent the common functionality required across various command entity implementations. Separating the information services from the command entity application in this manner offers a number of benefits: • It provides a shared baseline of background knowledge; • It reduces command entity developers' efforts by providing common software. • It allows command entity applications to focus on command decision behavior; Access to the services and utilities is implemented using an object-oriented, implementation-language independent interface between command entity applications and the command entity information services. To accomplish this, the Interface Definition Language (IDL) specification of the Common Object Request Broker Architecture (CORBA) was selected to define the interface and fully specify all interface parameters. The remainder of this section provides more details about the services and utilities available through this interface. a. Platform Services Platform Services provide a generic interface to a command entity's physical representation on the battlefield. Since a real commander operates from a vehicle on the battlefield (a tank, for example) the command entity must also be associated with a simulated vehicle. By providing this interface, command entities can be developed that can accommodate multiple SAF implementations (e.g., ModSAF or CCTT SAF)

b. Communications Services Communications Services offer an application interface to CCSIL message utilities. A message dispatcher maintains a queue of incoming messages waiting to be processed. Other capabilities include access to descriptions of the communications nets assigned to this unit, utilities to help format command entity output into proper CCSIL message format and send it to the appropriate recipients, and notification of incoming messages and access to the message queue. c. Missions, Tasks These services provide doctrinal decision templates to help interpret a mission and devise a plan. Templates present the decisions to be made, the choices available, and criteria for selecting among alternatives. For example, options will be provided for movement technique, formation, control measures, schemes of maneuver, decision alarms, etc., for a given mission. In addition, doctrinal templates will fit the enemy's strength, objectives, terrain, etc. d. Tactics, Techniques, Procedures This service will provide templates to help fill out orders and implement a plan. This includes a list of the possible subordinate behaviors associated with each task, guidance regarding parameter settings for those behaviors, and criteria for matching tasks to subordinates. It will identify required capabilities for a unit to fill a role in a scheme of maneuver and retrieve information about parameter settings, decision points, composition of formations, etc. e. Environment Evaluation Environment includes terrain, ocean, and atmosphere. Services will include the ability to compute mobility corridors, control measures, reverse slopes, routes, travel time and speed. Examples include computing a control measure of a given type (point, line, area) having specified attributes (size, relative location, etc.); identifying the mobility corridors leading to a given location along with a list of relevant attributes (trafficability and space, degree of canalization, etc.); and for a given mobility corridor, computing the choke points, high ground within engagement range, engagement areas in or adjacent to the corridor, etc. f. Unit Info These services provide access to static data about units (both own and enemy). They also include the ability to make basic inferences (e.g., combat power) from the raw data. For instance, retrieving the command hierarchy that a unit belongs to; identifying subordinates having an indicated set of capabilities; and assessing the maneuverability or combat power of a unit. 3.3

Baseline Infrastructure Finally, at the lowest level in the architecture, is the baseline infrastructure which incorporates ModSAF

Command Forces: An Extension of DIS Virtual Simulation

Page 4

platform representation and general DIS interface utilities. These capabilities are accessed by command entity implementations indirectly through the Information Services and Utilities layer. It is this bottom portion of the command entity architecture which is likely to change the most over the next few years. The layered architecture provides a mechanism for isolating the command entity applications from these anticipated changes. 4

Implementation Plan The CFOR project is an on-going effort that is a part of the Synthetic Theater of War (STOW) program, an Advanced Concept Technical Demonstration (ACTD) that is jointly sponsored by the United States Atlantic Command (USACOM) and the Advanced Research Projects Agency (ARPA). The STOW/CFOR program will support a USACOM exercise in 1997. In the exercise, objects from each US armed service will interact with each other and with credible opposing force objects. Command and control of the objects will be simulated in command entities using the CFOR architecture and will communicate using CCSIL. Human operators at workstations will perform higher echelon C2 functions over their subordinate command entities. The program plan for CFOR calls for multiple, ongoing activities: • Command Entity Knowledge Acquisition. Experts in each field will gather information about the command process. Particular emphasis will be placed on planning, decision-making, monitoring, and revising plans. • Command Entity Infrastructure Implementation. As described earlier in this paper, the command entity infrastructure will provide services to the command entity simulation. An initial delivery of this software will be made in January 1995; thereafter, new versions will be issued every six months. • Command Entity Simulation Implementation. The CFOR program plan calls for multiple contractors, each developing a unique command entity simula-

tion. After a suitable period of development, the implementations will be evaluated and a more standardized approach will be selected. Subsequently, the developers will deliver new and improved command entities every six months until the 1997 demonstration. Bibliography BBN Systems and Technologies, February 1993, Requirements for ModSAF 1.0, Cambridge MA. Ceranowicz, A. Z, J. E. Smith, A. J. Courtemanche, R. B. Calder, November 1992, ModSAF Programmer’s Guide, Loral Advanced Distributed Simulation, Inc., Cambridge MA. Defense Modeling and Simulation Office, July 1993, Survey of Semi-Automated Forces, Arlington VA. DIS Steering Committee, October 1993, The DIS Vision, A Map to the Future of Distributed Simulation, Orlando FL. Institute for Simulation and Training, February 1994, Standard for Distributed Interactive Simulation—Application Protocols, Version 2.0 Fourth Draft, Orlando FL Institute for Simulation and Training, June 1993, Communication Architecture for Distributed Interactive Simulation (CADIS) Guidance Document, Orlando FL Institute for Simulation and Training, June 1993, Communication Architecture for Distributed Interactive Simulation (CADIS) Proposed IEEE Final Draft Standard, Orlando FL Institute for Simulation and Training, June 1993, Communication Architecture for Distributed Interactive Simulation (CADIS) Rationale, Orlando FL Loral Advanced Distributed Simulation, Inc., February 1993, ModSAF Software Architecture Design and Overview Document, Cambridge MA. Seidel, D. W., May 1993, Aggregate Level Simulation Protocol (ALSP) Program Status and History, MTR 93W0000079, The MITRE Corporation, McLean VA.

Command Forces: An Extension of DIS Virtual Simulation

Page 5