CFOR Approach to Simulation Scalability

David W. Seidel (dseidel@mitre.org)
Marnie R. Salisbury (marnie@mitre.org)
Lashon B. Booker (booker@mitre.org)
Judith S. Dahmann (jdahmann@mitre.org)

The MITRE Corporation

Abstract

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.

I. Introduction

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

  1. Reduce the number of personnel required to operate a training exercise by permitting operators to control larger numbers of vehicles;

  2. Maintain the fidelity of DIS exercises by faithfully representing the command decision making of intermediate command nodes and the flow of orders and reports in the battlefield;

  3. Enhance the training value to the operators by utilizing or mimicking real-world command and control workstations; and

  4. Facilitate exercise management by monitoring and logging command and control activity during an exercise.

II. Command Forces

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. CFOR Concept

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.

  1. Command and Control can be represented in terms of the interactions and behaviors of command entities. The CFOR approach is based on the close match between the real-world Command and Control process and the DIS paradigm. While Command and Control relationships are typically depicted in terms of the hierarchical relationships among commanders at different echelons, their physical instantiation 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 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.

  2. The Command and Control process is an information flow process among command entities. Individual command entities (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).

    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.

  3. Command and Control information flow must be restricted by a faithful representation of real world communications. Information flow must be routed through command nodes compatible with the real world and subjected to battlefield effects. As with real commanders, virtual command decision makers have access to information about the world through their own direct sensations of the world through their virtual viewports (or system sensors), information reported by subordinates through CCSIL messages, and CCSIL intelligence messages from superiors. Since CCSIL messages are distributed via DIS Signal PDUs, CCSIL messages will be subject to battlefield effects to the extent that DIS implements them.

  4. The Command and Control decision process is represented in the individual command entities--the originators and recipients of information exchanges. In a micro-level view of the decision process, command entity Command and Control behavior varies with the level of command (company commanders should be modeled differently than battalion command posts), and representation of command entity behavior is independent from the representation of information exchanges.

    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.

B. Architecture


A summary of the functional architecture of CFOR is as follows (See Figure 1):

  1. Commanders at workstations transmit orders and receive reports via a newly devised Command and Control Simulation Interface Language (CCSIL). These messages are encapsulated in DIS Signal PDUs and transmitted along with all other DIS PDUs.

  2. Subordinates (initially Army company commanders) are simulated in software. They accept orders from their commanders, plan activities for their units, and transmit orders to their subordinates using CCSIL.

  3. Vehicles and small units (initially Army platoons) are modeled in ModSAF; they receive orders from their simulated command entity superior and implement his orders using normal ModSAF mechanisms.

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.

1. Command Entity Application.

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.

2. Information Services.

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:

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 specify all interface parameters.

3. Baseline Infrastructure

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.

4. Small Unit Functionality

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.

C. Implementation

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:

III. Scalability

This implementation CFOR facilitates the use of virtual simulation in a number of ways. They are discussed below.

A. Personnel Reduction

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.

B. Fidelity

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.

C. Training Value

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.

D. Exercise Management

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.

IV. 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.

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.


For more information, contact the CFOR Team (cfor@alsp.arpa.mil)