MITRE INFORMAL REPORT Synthetic Theater of War Project
Modeling and Simulation Technical Center
CFOR Approach to Simulation Scalability Marnie R. Salisbury David W. Seidel Lashon B. Booker Judith S. Dahmann
Presented to:
Electronic Conference on Scalability in Training Simulation April - June 1995
The MITRE Corporation 7525 Colshire Drive McLean, Virginia 22102
CFOR Approach to Simulation Scalability David W. Seidel (
[email protected]) Marnie R. Salisbury (
[email protected]) Lashon B. Booker (
[email protected]) Judith S. Dahmann (
[email protected]) The MITRE Corporation 7525 Colshire Drive McLean VA 22102 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. 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 a 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 (4) Facilitate exercise management by monitoring and logging command and control activity during an exercise.
1
April 1995
CFOR Approach to Simulation Scalability
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. 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 platformlevel 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. 2
April 1995
CFOR Approach to Simulation Scalability
(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. 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. 3
April 1995
CFOR Approach to Simulation Scalability
Command Entity
The DIS protocols define a common interface for Command Small Unit each entity that ensures interoperability and Decision Making and Vehicle consistent physical interactions on the virtual Automated CFOR Command Entity Forces battlefield. Analogous requirements exist for the Command Information Services (ModSAF) Workstation Command and Control interactions among and Utilities entities. Accordingly, the CFOR framework CCSIL CCSIL CCSIL ModSAF Interface Interface Interface includes an architecture for command entities that extends beyond the DIS network interface to provide a well-defined, common interface for all DIS(CCSIL) command decision activities. Command entities are under no implementation constraints beyond Figure 1. Technical Reference Model Context 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. 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. 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 Command Entity Application process. They avoid making any inferences or Command Decision Processes 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 CE Information Services across the variety of command entity C2 Services Comm Platform implementations. Separating the information Services Servicer Tactics, services from the command entity application Techniques, in this manner offers several benefits: Missions, Sense, Procedures
Perceive
(1) It provides a shared baseline of background knowledge;
Tasks
Comms Environment Evaluation
Move
(2) It reduces command entity developers' efforts by providing common software; and
Unit Info Shoot
(3) It allows command entity applications to focus on command decision behavior.
SAF / CE Baseline Infrastructure ModSAF
Access to the services and utilities is
CCSIL Network Interface
Figure 2. Technical Reference Model
4
April 1995
CFOR Approach to Simulation Scalability
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. Platform Services provide a generic interface to a command entity's physical representation on the battlefield. Since a live commander operates from a vehicle on the battlefield (a tank, for example), the command entity must also be associated with a simulated vehicle. Services provided include sense (what the commander can sea visually or with instruments), move (the ability to independently direct his vehicle), and shoot (loading, directing, and firing on-board weapons). By using this interface, command entities can be developed that can accommodate multiple SAF implementations (e.g., ModSAF or CCTT SAF). Communications Services permit an application to interface to CCSIL message utilities. A message dispatcher maintains a queue of incoming messages waiting to be processed. Other capabilities provide 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 with access to the message queue. Missions and Tasks services provide a command entity with a skeletal decomposition of standard company team operations into tactically meaningful components, along with guidelines for implementing the tasks and subtasks associated with each component. The rationale for providing such a declarative representation of doctrine is that a command entity competent in executing all the basic components can execute any mission defined in terms of those components. The components for company teams build on the collective ARTEP tasks. The target repertoire of mission decompositions includes those missions corresponding to the set of virtual training exercises (Attack, Defend, Delay, Movement to Contact, Reconnaissance in Force, Raid, Exploitation, and Pursuit). Tactics, Techniques, and Procedures services will provide a command entity with doctrinally acceptable decision options for conducting an operation. These services are designed to present tactical considerations and techniques, standard operating procedures, and "tricks of the trade" in a manner that facilitates the "how to" aspects of a company command entity's job. The decision options offered typically represent textbook solutions that every human commander would recognize from his military education. The motivating rationale for these services is to help command entities in those areas where human commanders can roputinely generate an acceptable solution, regardless of their level of competence. Environmental Evaluation. Environment includes terrain, ocean, and atmosphere. Services include the ability to compute mobility corridors, control measures, reverse slopes, routes, travel time and speed. For example, a service might compute 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.). Another service might compute choke points, high ground within engagement range, and engagement areas in or adjacent to the corridor for a given mobility corridor. Unit Info services provide access to static data about units (own and enemy). They also include the ability to make basic inferences (e.g., combat power) from 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. Baseline Infrastructure. At the lowest level in the architecture is the baseline infrastructure, 5
April 1995
CFOR Approach to Simulation Scalability
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. 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. 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: a.
Knowledge Acquisition. Experts in each field and for each military Service will gather information about the command process. Particular emphasis will be placed on planning, decision-making, monitoring, and revising plans.
b.
Infrastructure Implementation. As described earlier, the command entity infrastructure will provide services to the command entity simulation. An initial delivery of this software was made in January 1995; new versions will be issued every six months.
c.
Command Entity Simulation Implementation. The CFOR program plan calls for multiple contractors, each developing a unique command entity simulation. After a suitable period of development, the implementations will be evaluated and a more standardized approach will be selected. Subsequently, developers will deliver new and improved command entities every six months until the 1997 demonstration. It is expected that initial experience will be gained in implementing Army command entities and that experience will be applied to implementing those of the other military services.
d.
ModSAF Enhancement. ModSAF will be enhanced to model new entities (vehicles and small units), to model new behaviors for entities, and to implement CCSIL orders and requests and generate CCSIL reports.
SCALABILITY This implementation CFOR facilitates the use of virtual simulation in a number of ways. They are discussed below Personnel Reduction The number of personnel needed to operate the current SAF is dictated by their ability to monitor
6
April 1995
CFOR Approach to Simulation Scalability
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. 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 realworld 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. 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. 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. 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
7
April 1995
CFOR Approach to Simulation Scalability
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, October 1994, Command and Control Simulation Interface Language (CCSIL),Message Content Definitions, McLean VA MITRE Corporation, October 1994, Command and Control Simulation Interface Language (CCSIL) Usage and Guidance, McLean VA MITRE Corporation, October 1994, Command Forces (CFOR) Infrastructure Interface Definition, McLean VA
8
April 1995
