ARPA, in its STOW program, expressed a goal of expanding virtual simulation exercises to encompass 100,000 DIS entities. Obvious scalability challenges to meeting this goal are the computer and network issues such as bandwidth and computing power. However, human issues are also relevant; such issues include exercise management, reducing the staffing necessary for an exercise, and maintaining realism while increasing the span of control of human operators.
As a part of STOW, the Command Forces (CFOR) program simulates command and control nodes in software. One of its goals is to address and improve the human aspects of scalability. In particular, it aims to (1) reduce the number of personnel required to operate a training exercise; (2) maintain the fidelity of a DIS exercise; (3) enhance the training value to the operators; and (4) facilitate exercise management.
The Advanced Research Program Agency (ARPA) is engaged in implementing a program called the Synthetic Theater of War (STOW). This program has an expressed a goal of expanding virtual simulation exercises to encompass 100,000 entities. Obvious challenges to meeting this goal include electronic issues such as communications bandwidth and computing power. However, human issues are also relevant, including exercise management, reducing the staffing necessary for an exercise, and maintaining realism while increasing the span of control of human operators.
The Command Forces (CFOR) program is a part of ARPA's STOW program. It seeks to introduce command and control nodes into virtual exercises. This paper discusses how CFOR's concept, architecture, and design address scalability in a large DIS exercise. CFOR scalability goals are to
The Command Forces program was initiated in 1994 to be a part of ARPA's STOW program. Its goal is to introduce realistic Command and Control into virtual exercises. The sections that follow describe CFOR's concept, architecture, and implementation.
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 will 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 (SAF) development provides a first generation capability. SAF technology allows the virtual battlefield to be populated with a collection of combat entities at the individual platform and small unit levels (platoons, sections, batteries, teams, etc.).
To support expansion of virtual simulation to larger-scale applications, CFOR extends the basic DIS architecture to incorporate explicit, virtual representation of command nodes, Command and Control information exchange, and command decision making. This extension incorporates four fundamental tenets.
The battlespace is composed of physical platforms (e.g., tanks, aircraft, ships), each of which 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 a "command entity." Command entities are virtual military decision makers. They represent the individual or collective behavior of a commander and his staff. The effects of a command entity's 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 platform-level battlefield entities.
As a part of the CFOR concept, the Command and Control Simulation Interface Language (CCSIL, pronounced "cecil") represents the information exchanges between commanders. Through exchange of a structured set of these messages, CCSIL reflects real-life information exchanges among military decision makers.
Command and Control behavior is represented in the command entities. While selected vehicle and small unit commander behaviors are adequately represented in existing SAF software, implementation of higher echelons of command implies a qualitative "jump" in SAF capabilities. To emulate higher-echelon commanders, command entities must be capable of generating commands to subordinates and reacting to those from superiors; and they must possess a wide repertoire of possible decision behaviors to accommodate any of an essentially infinite variety of battlefield conditions.
ModSAF, ARPA's latest example of SAF technology, is capable of modeling the behaviors of platforms and small units with much more sophistication than did its predecessors; but it can be expected to show only modest increases in its reactive behavioral repertoire. While it will be necessary to expand the numbers and behaviors of entities modeled in ModSAF, the challenge in developing CFOR is to create a full repertoire of command behaviors at Company, Battalion, and higher echelons.
Ultimately, CFOR will support the ability of one or a few human operators to control large numbers of simulated warfighting forces. Human interaction with the CFOR will be based on real-world Command and Control procedures. On the real-world battlefield, Command and Control is exercised through communication: through the issuance and receipt of orders, requests, and reports. The human CFOR controller will utilize the same tools to command the computer-generated forces.
A summary of the functional architecture
of CFOR is as follows (See Figure 1):
The DIS protocols define a common interface for each entity that ensures interoperability and consistent physical interactions on the virtual battlefield. Analogous requirements exist for the Command and Control interactions among entities. Accordingly, the CFOR framework includes an architecture for command entities that extends beyond the DIS network interface to provide a well-defined, common interface for all command decision activities. Command entities are under no implementation constraints beyond those imposed by the interface specified by the architecture. In this way, the CFOR framework extends the basic tenets of the DIS paradigm into a new mode of entity interactions.
A technical reference model describing the command entity architecture is
depicted in Figure 2. This architecture promotes interoperability and coherent
Command and Control activity by providing a shared infrastructure, a common set
of information and computing services, accessible through a well- defined
applications interface. The architecture consists of three layers: Application
Layer, Information Services and Utilities Layer, and Baseline Infrastructure
Layer. The elements of the technical reference model are discussed below.
The Application Layer is where the command decision-making software resides. 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.
This 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 to model the decision process. They avoid making any inferences or judgments that are the proper purview of command entities. The functionality of these services and utilities will be adjusted over time to represent the common functionality required across the variety of command entity implementations. Separating the information services from the command entity application in this manner offers several benefits:
At the lowest level in the architecture is the baseline infrastructure, which incorporates ModSAF 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.
The CFOR architecture requires that small units and vehicles be capable of implementing orders generated by command entities. For the Army, a company team has been selected as the lowest level of command entity. Entities below this level (platoons and individual vehicles), are modeled in SAF (initially ModSAF). This requires that ModSAF be enhanced to accept and implement CCSIL orders and to generate CCSIL reports.
The CFOR project is an on-going effort that is a part of the STOW Advanced Concept Technical Demonstration (ACTD) that is jointly sponsored by the United States Atlantic Command (USACOM) and the Advanced Research Projects Agency (ARPA). This 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 Command and Control functions over their subordinate command entities.
The program plan for CFOR calls for multiple, concurrent activities:
This implementation CFOR facilitates the use of virtual simulation in a number of ways. They are discussed below.
The number of personnel needed to operate the current SAF is dictated by their ability to monitor and direct large numbers of small units and vehicles. Typically each SAF operator controls several platoons; he must monitor the status of each platoon, direct each to work within an operational plan, and, occasionally, exercise control over individual vehicles when they don't behave as he expects.
Under CFOR, mid-level commanders (company team commanders in the Army) are simulated. Battalion commanders are then the lowest level of commander that must interface with the exercise directly. This permits one operator to control all of the battalion's units and vehicles.
The fidelity of the behavior of vehicles in the current SAF is determined by validated software. However, the behavior of units is often dependent on the direct manipulation of human operators. This removes the maneuvering and fighting of platoons from a validated process and requires militarily proficient operators.
With CFOR, unit activity will be dictated by a chain of orders from superiors that mimic real-world orders. Coordinated company-level activity will be based on missions provided by superiors and planned and monitored by dedicated software simulation. Transmission and reception of these orders and reports will be constrained by battlefield conditions.
Currently, SAF operators gain little training since they don't fill a command position in the military hierarchy.
With CFOR, a commander fills the role of a real military commander and interfaces with the exercise via messages that mimic real world messages. He operates from a workstation that is an extension of his real-world command and control system, and thus gains positive training from an exercise.
Currently, command and control decisions are transmitted verbally to SAF operators. Special effort must be exerted to record these decisions for post- exercise evaluation. This is particularly true for the orders given by the operators to their subordinate units and vehicles.
With CFOR, Battalion orders are sent to simulated companies using CCSIL messages. Similarly, Company orders to platoons, Company reports to Battalion, and Platoon reports to Company use CCSIL. All of these messages are communicated over DIS. Thus, command and control activity is public and available for logging and on-line or post-exercise analysis and critique.
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.
Dahmann, J. S., M. R. Salisbury, L. B. Booker, D. W. Seidel, September 1994, "Command Forces: An Extension of DIS Virtual Simulation," Eleventh Workshop on Standards for the Interoperability of Defense Simulations, Orlando, Florida
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.
MITRE Corporation, January 1995, Command and Control Simulation Interface Language (CCSIL),Message Content Definitions, McLean VA.
MITRE Corporation, January 1995, Command and Control Simulation Interface Language (CCSIL) Usage and Guidance, McLean VA
MITRE Corporation, January 1995, Command Forces (CFOR) Infrastructure Interface Definition, McLean VA
Salisbury, M.R., March 1995, "Command and Control Simulation Interface Language (CCSIL): Status Update," Twelfth Workshop on Standards for the Interoperability of Defense Simulations, Orlando, FL.