Technial Report 420

DESIGN OF AN INTEGRATED DIV EVEL

BATTLE SIMULATION FOR RESEARCH,

DEVELOPMENT, AND TRAINING: "

Volume I

00 Roland V. Tiede, Roger A. Burt, and Theodore T. Bean

RolndScience Applications, Incorporated

HUMAN FACTORS TECHNICAL AREA

and

ARI FIELD UNIT AT FORT LEAVENWORTH, KANSAS

U.S. Army V, Research Institute for the Behavioral and Social Sciences

August 1979

2 Approved for public releje; dipribution unlimited.

.....

lip"~'
U. S. ARMY RESEARCH INSTITUTE

FOR THE BEHAVIORAL AND SOCIAL SCIENCES

A Field Operating Agency under the Jurisdiction of the

Deputy Chief of Staff for Personnel

WILLIAM L. HAUJSER

JOSEPH ZEIDNER Colonel, U S, Army Technical Director Commander

Research accomplished under contract

to the Department of the Army

Science Applications, Inc.

NOTICES

DISTR IBUTI ON: Primary distribution of this report hes been mede by AR I. Please address correspondenzr

concerning distribution of reports to: U. S. Army Research Ins~titute for the Behavioral and Social Sciences.

ATTN PERI.P, 5001 Eisenhoviir Avenue, Alexandria, Virginia 22333,

FINAL DISPOSITION: This report may be dastroyed when it is no longer needed. Plea14 do not return it to

the U. S. Army Research Institute for the Behavioral and Social Sciences.

ftT-The findings in this report are not to be construed as an official Department of the Army position,

unless so designated by other authorized documents.
Unclassified SECURITY CLASSIFICATION OF THIS PAGE (Wen Date Entered) ___

• 

REPORT DOCUMENTATION PAGE BEEOPT NMLEMuERo 1. REPORT NUMBER / 2. GOVT ACCESSION NO. 3. RRCIPIZNT'S CATALOG NUMBER

•Technical Report 420 ... . ... . , ..f-_XPC OF REPORTX & ERIOD COVERED 6 ESIGN OF AN INTEGRATED JIVISIONEV TLE §IMULATION FOR U-ESEARCH, REVELOPMENT, ANDk

J F RAINING • Volume I // _W S-R N UM E R

_i THO(. 6. CbONTRACT OR URWNrT NUMBER(&)

( Roland V. Tiede Roger A.iBurt and

Theodore T. Bean # 78

9. PERFORMING ORGANIZATION NAME AND ADDRESS 10. PROGRAM ELEMENT. PROJECT. TASK

Science Applications, Inc. / A A&.. W

8400 West Park Drive / 2Q162722A76

McLean, VA 22102

11. CONTROLLING OFFICE NAME AND ADDRESS

U.S. Army Research Institute for the Behavioral Au 7)

and Social Sciences /.-I3. NUMBEROF PGES

5001 Eisenhower Avenue, Alexandria, VA 22333 162 14. MONITORING AGENCY NAME & ADDRESS(If different from Controlling Office) 15. SECURITY CLASS. (of thi. report)

.- ~ / 1i Unclassified

...... lIS. DECLASSI'FICATION/DOWNGRADING

SCHEDULE

IS. DISTRIBUTION STATEMENT (of this Report)

Approved for public release; distribution unlimited.

17. DISTRIBUTION STATEMENT (of the abiract entered In Block 20. if different from Report)

IS. SUPPLEMENTARY NOTES

This volume describes the structured framework of the simulation and the con- siderations that entered into its design. Volume II, ARI Technical Paper 421,

provides more detailed design information. Research was monitored by Dr. Edgar

M. Johnson, Mr. Robert S. Andrews, and Dr. Thomas M. Granda of ARI.

* 19. KEY WORDS (Continue on reverse side .f necessary end identify by block number) V7 Division level battle simulation Battle outcome generator Intelligence

Event store simulation Division staff InstrumenTop-down design Tactical information messages tation of

Decision variables Event threads live

Interactive simulation Performance measurement modules

20. AnsT'Acr mbatse m ,,wvwe s.b f n , sod ideguiy by block number)

Requirement: (1) Develop a top-down design for an integrated family of

modular division-level battle simulations which separately or jointly will

exercise players performing critical functions in command and control (Vol. 1).

(2) Develop detailed design specifications for the Intelligence Staff module

of the integrated battle simulation (Vol. II).

The design approach involved the following principles: selection of the

decision variables to be manipulated by the division staff modules (Continued)

D o 1473 IEDTIOW OF I NOV 65 IS OBOLETE JAN 73Unclassified

i SECURITY CLASSiFICATiON OF THiS PAGE (When Dote Entered)

• i - -/_, * -*--.... -.
Unclassified

SECURITY CLASSIFICATION OF THIS PAG rnDMrest.)

Item 20 (Continued)

and the event threads both within and external to the staff modules thereby

fixing the event sequence and time of occurrence; and incorporating into

the simulation every event thread needed to support the input/output relationship. The dynamic realism needed to place decisionmakers in a realistic environment is achieved by means of an event store technique. The

five classes of events of which the event threads are composed are defined

and the logical flow of the event store simulation is illustrated. A sixth

class of event needed for operation in an ADP-assisted mode is also defined.

The approach begins at the heart of the information system, the decisions,

and then develops the simulation needed to implement them--the inverse of

the usual approach.

The design concept provides for a man in the loop in that any one or

any combination of five basic staff modules (Cmd Grp, G-2, G-3, G-l/G-4,

FSCE) plus one enemy module (Cmd Grp) may be either occupied by human

players or simulated. The module simulations are designed as "plug-in"

modules any one or more of which can be replaced by players. The simulation also contains a battle outcome generator which simulates all other

events within the division and the enemy force opposing it, and which feeds

back to the players in slow, real, or fast time (at the option of the

user) the results of their decisions. The design also ,rovides for interfaces with higher and adjacent units. It includes the following features:

1. The modules are based on the traditional G-staff structure.

2. Nuclear battle events are included.

3. Live modules may be required to perform simultaneous planning

and execution; the results of such planning may be evaluated

by subsequent execution of plans.

4. Other staff elements not included in the basic five modules

(e.g., engineer, signal) are "hardwired" components of the

simulation.

5. The basic design provides for manual operation by live players

but it is readily expandable to permit player operation in an

ADP-assisted mode.

'IS t-.*4

TAB

veilrl

Mt. Unclassified

AV SECURITY CLASSIFICATION OF THIS PAGE(ften Date Entered)

-
Technical Report 420

DESIGN OF AN INTEGRATED DIVISION-LEVEL

BATTLE SIMULATION FOR RESEARCH,

DEVELOPMENT, AND TRAINING:

Volume I

Roland V. Tiede, Roger A. Burt, and Theodore T. Bean

Science Applications, Incorporated

Submitted by: Edgar M. Johnson, Chief HUMAN FACTORS TECHNICAL AREA

and

Robert S. Andrews, Chief

ARI FIELD UNIT AT FORT LEAVENWORTH, KANSAS

Approved by:

Milton S. Katz, Acting Director

ORGANIZATIONS AND SYSTEMS

RESEARCH LABORATORY

U.S. ARMY RESEARCH INSTITUTE FOR THE BEHAVIORAL AND SOCIAL SCIENCES

5001 Eisenhower Avenue, Alexandria. Virginia 22333

Office, Deputy Chief of Staff for Personnel

Department of the Army

August 1979

Army Project Number Staff Operations and

20162722A765 Procedures

Approved for public release; distribution unlimited.

' iii
ARI Research Reports and Technical Reports are intended for sponsors of

R&D tasks and for other research and military agencies. Any findings ready

for implementation at the time of publication are presented in the last part

of the Brief. Upon completion of a major phase of the task, formal recommendations for official action normally are conveyed to appropriate military

agencies by briefing or Disposition Form.

iv

lv

.
FOREWORD

The Army Research Institute for the Behavioral and Social Sciences

(ARI) conducts research on tactical information systems with particular

emphasis on the human factor in battlefield command/control and intelligence functions and operations. The development and refinement of

man-in-the-loop simulations to serve as research test-beds is a necessary

step in the development of command staff aids and procedures to meet the

challenge of the modern battlefield. The ARI research program in this

domain is independently and jointly executed by the human Factors Technical

Area in Alexandria, Va., and the ARI Field Unit at Fort Leavenworth,

Kans.

The present report describes a range of design alternatives for a

man-in-the-loop simulation for research, development, and training. The

basic concept developed is one of a modular simulation where one or more

elements within the command staff group may be exercised, with controllers

supervising play and feeding in data, etc., from unpopulated (simulated)

staff elements. Pre-established event threads provide a means for

realistic play of a complex scenario with a relatively small controller

team. The possible role of computer support to the controllers is also

discussed. Detailed design specifications are provided in ARI Technical

Report 421. This effort provides part of the methodological and technological base required for development and evaluation of command group

aids and procedures.

Research on staff operations and procedures is conducted both

in-house and augmented contractually with organizations selected for

their specialized capabilities and unique facilities. Efforts in this

area are responsive to general requirements of Army Projects 2Q162722A765

and 2Q163743A774 and to special requirements of the U.S. Army Combined

Arms Combat Development Activity, Fort Leavenworth, Kans., and the U.S.

Army Intelligence Center and School, Fort Huachuca, Ariz. This effort

is also responsive to Human Resource Need 78-85 "War Gaming of Intelligence," and was conducted under Contract DAliCI9-77-C-0047 by Science

Applications, Inc., monitored by both the Human Factors Technical Area

and the Fort Leavenworth Field Unit of ARI.

Sz NER

chnical Director

, " 4.

V
DESIGN OF AN INTEGRATED DIVISION-LEVEL BATTLE SIMULATION FOR RESEARCH,

DEVELOPMENT, AND TRAINING

BRIEF

This volume describes the structural framework of the simulation and

the considerations that entered into its design. A companion volume,

DETAILED DESIGN NOTES FOR DESIGN OF AN INTEGRAT DIVISION-LEVEL BATTLE SIMULATION FOR RESEARCH, DEVELOPMENT, AND T AINING, provides more

detailed design information.

-Requirement_Aj___

1. !5ixevelop a top-down design for an integrated family of 9modular division-level battle simulations which separately or jointly

will exercise players performing critical functions in command and

control.

2. Develop detailed design specifications for the Intelligence S module of the integrated battle simulation.

<'->The design approach involved the following principles: selection of

the decision variables to be manipulated by the division staff modules

and the event threads both within and external to the staff modules

thereby fixing the event sequence and time of occurrence; and incorporating into the simulation every event thread needed to support the

input/output relationship. The dynamic realism needed to place decision makers in a realistic environment is achieved by means of an

event store technique. The five classes of events of which the event

threads are composed are defined and the logical flow of the event

store simulation is illustrated. A sixth class of event needed for

operation in an ADP-assisted mode is also defined. The approach begins at the heart of the information system, the decisions, and then

develops the simulation needed to implement them--the inverse of the

usual approach. -

'_>The design concept provides for a man in the loop in that any one or

any combination of five basic staff modules (Cmd Grp, G-2, G-3,

G-I/G-4, FSCE) plus one enemy module (Cmd Grp) may be either occupied

by human players or simulated. _bg module simulations are designed

as "plug-in" modules any one o more of which can be replaced by

players. The simulation also o tains a battle outcome generator * . which simulates all other events whin the division and the enemy

force opposing it, and which feeds bck to the players in slow, real,

or fast time (at the option of the user) the results of their decisions. The design also provides for the interfaces with higher

and adjacent units. It includes the following features:

vii
1. The modules are based on the traditional G-staff structure.

2. Nuclear battle events are included.

3. Live modules may be required to perform simultaneous

planning and execution; the results of such planninq

may be evaluated by subsequent execution of plans.

4. Other staff elements not included in the basic five

modules (e.g., engineer, signal) are "hardwired"

components of the simulation.

5. The basic design provides for manual operation by live

players but it is readily expandable to permit player

operation in an ADP-assisted mode.

Conclusions:

The general top-down design of the simulation has been developed as has the more detailed design of the Intelligence Staff

module. However, two basic design problems were uncovered in the

course of the research.

1. A fundamental problem is inherent in the modular nature

of the simulation. If a populated module performs below standard

(makes errors, omits or takes illogical actions) how can simulated

command and control processes reflect the degraded force effectiveness that results? Although much simpler to implement, standard performance by simulated command control nodes independent of performance

of populated modules would not meet simulation objectives.

2. In the interest of economy of operation and player

motivation it would be desirable to eliminate or reduce the requirement for repetitive, low-skill tasks, e.g., answering radios and

telephones and transmitting messages, routine filing, etc., which

have little impact on the quality of decision making and are of little

interest to the investigator. It may also be desirable to modify or

recombine tasks in investigations of alternative procedures. This

can be difficult to accommodate and still retain a credible, realistic

decision-making environment.

It is concluded that both the above problems are serious enough to

warrant additional analysis before implementing the simulation.

viii
..

TABLE OF CONTENTS

SECTION PAGE

GLOSSARY OF ACRONYMS ix

1 INTRODUCTION 1-1

1.1 Purpose and Scope 1-1

1.2 Approach 1-1

2 THE PROBLEM 2-1

2.1 Statement of the Problem 2-1

2.2 Objectives 2-1

2.3 Modeling Requirements 2-1

2.4 Data Flow Requirements 2-3

2.5 Functional Requirements 2-18

3 ANALYSIS OF SIMULATION REQUIREMENTS 3-1

3.1 Desiqn Principles 3-1

3.2 Decision Variables and Input/Output Formats 3-4

3.3 Dynamic Realism 3-9

3.4 Design Decisions 3-12

4 TOP-DOWN DESIGN 4-1

4.1 Desiqn Concept 4-1

4.2 Proposed Initial Implementation 4-38

4.3 Basic Components of the First Implementation 4-53

4.4 Future Extensions 4-62

4.5 Applications of the Top-Down Design 4-65

5 INSTRUMENTATION OF LIVE MODULES 5-1

5.1 Cost of Realism 5-1

5.2 Performance Measurement 5-3

5.3 Control Parameters 5-10

6 DESIGN OF THE INITIAL IMPLEMENTATION (LIVE 6-1

INTELLIGENCE (G2) MODULE)

6.1 Physical Layout 6-1

6.2 Personnel Requirements 6-1

6.3 Outputs and Inputs 6-8

6.4 Control Parameters 6-8

* 6.5 Measurements and Evaluation 6-13

6.6 Plan for Initial Implementation 6-16

(Design Notes A through J present detailed design information and are

contained in the companion volume DETAILED DESIGN NOTES FOR DESIGN OF

AN INTEGRATED DIVISION-LEVEL BATTLE SIMULATION FOR RESEARCH, DEVELOPMENT, AND TRAINING)

ix
LIST OF ILLUSTRATIONS

FIGURE PAGE

2-1 Basic Elements of "Man In The Loop" Combat Sim- 2-2

ulation

2-2 Data Flow in Modular Staff Simulation 2-7

2-3 Nature of the Data Element Transformations at Points 2-10 in the Decision-Making Node (CP)

2-4 Bases for Measurement 2-12

2-5 Process Types in ADP-Assisted Tactical Decision Node 2-16

2-6 Overview of the Simulation 2-19

3-1 Logical Flow of the Event-Store Simulation 3-11

3-2 Tactical Command Post Configuration 3-13

3-3 Main Command Post Configuration 3-14

3-4 Tactical Operations Center Configuration, Main CP 3-15

3-5 Locations of G-2 Activities 3-16

3-6 A Feasible Modular Structure 3-17

3-7 Process Levels in a Tactical Decision-Making Node 3-24

4-1 Basic Modules of the Integrated Division-Level 4-3

Battle Simulation, Showing the Five Classes of Events

4-2 Modified Version of the Integrated Division-Level 1-4

Battle Similation Showing the Six Classes of Events

4-3 Sizes of the Major Data Groups 4-26

4-4 The Preprocessinq System 4-34

4-5 Proposed Physical Layout 4-40

4-6 The Controller's Basic Display 4-45

4-7 Staff Inputs Received on the Teletype Printer 4-50

4-8 Events on the Controller's Message Log 4-52

4-9 System Flow Chart of the Interactive Executive 4-56

Control Routine

4-10 Structure of File Combining Principal Data Groups of 4-60

the Three Data Bases

4-11 Dynamic Ground Combat Model 4-67

5-1 SOP Flow Chart 5-8

4- xX
LIST OF ILLUSTRATIONS (Continued)

FIGURE PAGE

6-1 Physical Layout in Live G2 Conficuration 6-2

6-2 Components of EW 6-7

6-3 Schedule for Initial Implementation 6-19

xi
LIST OF TABLES

TABLE PAGE

3-1 Analysis of Functional Design Requirements 3-3

3-2 G-2 Decision Outputs 3-5

3-3 Input/Output Matrix for Intelligence Staff Module 3-6

3-4 Input/Output Classification Based on Relationship 3-8

to the Simulation

3-5 Event Classes for the Integrated Division-Level 3-10

Battle Simulation

4-1 Configuration Number 4-5

4-2 Event Numbering Convention used in the Basic Design 4-8

4-3 Class 1 Events 4-10

4-4 Class 2 Events 4-13

4-5 Class 3 Events 4-16

4-6 Class 4 Events 4-17

4-7 Class 5 Events 4-20

5-1 Elementary Operations 5-6

5-2 Possible ARI Research Application 5-13

6-1 Intelligence Staff Module 6-9

6-2 Module Outputs and their Modular Addresses 6-10

6-3 Input/Output Matrix for Intelligence Staff Module 6-11

6-4 Possible ARI Research Applications 6-14

xii
GLOSSARY OF ACRONYMS

ADA Air Defense Artillery

ADP Automated Data Processing

AMORE Analysis of Military Organization Effectiveness

Methodology

APC Armored Personnel Carrier

ARI Army Research Institute

BICC Battlefield Information Coordination Center

BDE Brigade

BN Battalion

BOG Battle Outcome Generator

C3 Command Control and Communications

CBRE Chemical Biological Radiological Element

CEWI Combat Electronic Warfare Intelligence

CG Commanding General, Command Group

CP Command Post

CPU Central Processing Unit

CRT Cathode Ray Tube

CSS Combat Service Support

DAME Division Airspace Management Element

DIV Division

DTG Date-Time-Group

EW Electronic Warfare

EOOB Electronic Order of Battle

EWIOC Electronic Warfare Intelligence Operations Center

FEBA Forward Edge of the Battle Area

FS Fire Support

FSE Fire Support Element Staff

GI/G4 Combat Service Support Staff

G2 Intelligence Staff

G3 Operations Staff

HQ Headquarters

xiii

p.
IECR Interactive Executive Control Routine

INTREP Intelligence Report

INTSUM Intelligence Summary

I/O Input/Output

LRRP Long Range Reconnaissance Patrol

NBC Nuclear Biological Chemical

OPLAN Operational Plan

POL Petrol, Oil, Lubricants

RTO Radio Telephone Operator

SAGE Semi-Active Ground Environment

SAI Science Applications, Inc. F

SCORES Scenario Oriented Recurring Evaluation System

SIMTOS Simulated Tactical Operation System

SITMAP Situation Map

SITREP Situation Report

SOK State of Knowledge

SOP Standard Operating Procedure

TAC Tactical Command Post

TACP Tactical Air Control Party

TASE Tactical Air Support Element

TCAC Technical Control and Analysis Center

TOC Tactical Operations Center

TOE Table of Organization and Equipment

TOS Tactical Operations System

TRADOC Training and Doctrine Command

xiv

Y .- -
Section 1

INTRODUCTION

1.1 PURPOSE AND SCOPE

This report describes the top-down design of an Integrated

Division-Level Battle Simulation for Research, Development, and

Training. It discusses and documents the critical trade-offs which

need to be made in further development and implementation of the

simulation and which underlay the numerous design decisions that

have already been made. It discusses the applicability of the design to the three major areas for which such a simulation should be

useful , namely:

* Behavioral science research on human performance in

command and control.

0 Combat developments, for the analysis and evaluation of

tactics and doctrine.

* As a training device for command groups/staff.

Also discussed are the player tasks and roles in each of the modules,

the general rules of play, the information flow required to support

stand-alone and integrated play, controller requirements and functions,

data to be obtained and evaluation criteria to be applied, and other

aspects of the design necessary to allow for implementation of the

simulation.

1.2 APPROACH

The approach to the design of this simulation is somewhat unique

as compared to past designs of combat simulations. It involves the application of the following principles:

0 Selection of the decision variables to be manipulated

by the division staff modules and the associated inputs

and outputs.

0 Tying together the inputs and outputs by means of event

threats both within and external to the staff modules

thereby fixing the event sequence and time of occurrence.

* Incorporating into the simulation every event thread

needed to support the input/output relationship.

This approach begins at the heart of the information system, i.e.,

the decisions to be made, and then develops the combat simulation

needed to implement them, which is the inverse of the usual approach.

b z.

1-l
The dynamic realism needed to place decision makers in a realistic decision-making environment will be achieved by means of an

event-store technique. The five classes of events of which the event

threads will be composed are defined and the logical flow of the event

store simulation is illustrated. A concept for incorporating a wide

range of scenarios is presented and the trade-offs involved in ADP

support for the controllers are discussed. A sixth class of event

needed for operation in an ADP-assisted staff mode is also defined.

A basic system concept is presented in Section 4 and the relationship of the event classes to the simulation components is defined. A careful distinction is drawn between portions of the simulation that will be "hard wired" and those that will be readily

addressable as inputs. Examples are given of both kinds of parameters and the discussion shows why the cost effectiveness of the

simulation is determined by the wise choice of hard wired components.

The data organization is outlined and the requirement for and the

manner in which the real data base and the Blue and Red perceived

data bases will be organized is shown. The specific features to be

included in the initial implementaiton are described as are the tradeoffs involved in deferring some features for future extensions.

This is followed by a discussion of the design of live staff

modules. The question of the tradeoff between module size and realism

is addressed. The issue of the complexities introduced by alternative

(adaptive) man-machine interface definition is raised again. It is

indicated that live staff modules may be essentially a complete operating shift less the lower (communication) staff processes which will

be incorporated into the simulation proper in the interest of economy.

This is followed by a discussion of the control parameters that are

incorporated in the design to facilitate employment of the simulation

for behavioral research. The final section of the report repeats

much of the preceding design information in the context of the detailed design of the live G2 module.

Appearing in a companion volume to this report is detailed

design information on the staff module inputs and outputs, the detailed

specifications for each of the event classes and event thread charts

for all interface events.

1-2

~1
- .. .

Section 2

THE PROBLEM

2.1 STATEMENT OF THE PROBLEM

The problem addressed in this research may be stated as follows:

To develop a battle simulation which will provide a cost-effective

tool for use as:

0 A systems measurement bed for behavioral science research on human performance in the division command

group and the principle staff sections.

* An aid in analysis and evaluation of tactics and doctrine in combat developments.

0 A training device for command groups and staff elements.

2.2 OBJECTIVES

The technical objectives of this effort are:

0 To develop a top-down design for an integrated family of

modular division-level battle simulations which separately or jointly will exercise players performing

critical functions in command and control.

0 To develop detailed design specifications for the Intelligence Staff module of the integrated battle simulation.

s To develop, implement, and demonstrate the Intelligence

Staff module as a stand-alone battle simulation for

research, development, and training of Intelligence

functions and for subsequent integration with other

modules.

2.3 MODELING REQUIREMENTS

Both the statement of the problem and the technical objectives require that the simulation be interactive and, thus, have man (i.e..

one or more decision makers) "in the loop".

Figure 2-1 illustrates the basic elements of any interactive

combat simulation. A scenario, which specifies forces, situation, and

missions provides the initial conditions and the constraints imposed

on the decision makers. In the general case, two opposing decision

makers feed decisions to and receive feedback from a decision outcome

generator. The latter also calculates the combat outcomes in terms

of the measures of effectiveness being used to assess the final

2-1

9.- .... - -. . . - - -
< 4

I 1

1I4 cn-4

'nI 4-rC maC

C= La I"JW CM C0- 0 o < U ( 1-4 0- (n 0-4 -

U- V) = J D

-4J

*1J

z U,

LALA.

2-2
(battle) outcomes. For some applications, the functions of the opposing (Red) decision maker may be incorporated into the decision

outcome generator (usually termed "control"). Such applications might

include studies of the nature of the player-invoked information

processes and decisions made as a result of a predetermined sequence

of tactical events. They might also include cases in which the decision maker is being trained to perform a prescribed series of information processes or indoctrinated ("programmed") to make certain

decisions in response to selected tactical events.

It should be noted that for such an interactive combat simulation, the simulation proper incorporates only the scenario (input

data), the decision outcome generator, and the combat outcomes (output).

The boxes occupied by the decision makers are not simulated but real.

This means that the data exchange between the player boxes and the

simulation proper is a crucial factor in the design of the simulation.

This is discussed in greater detail in the following paragraph.

2.4 DATA FLOW REQUIREMENTS

The requirements imposed by the problem and objectives stated

above fall under two general headings. The first is a requirement to

simulate combat and the other events that result from player decisions.

The second must concern itself with the information flow and decision

making inherent in the division command post. Since provision must

be made for manning only a part of the command post, i.e., or,. or more

staff modules, there is a requirement for modeling or simulating

those portions of the division command group and staff sections that

are not manned by human decision makers (players). In other words,

there is a requirement for a simulation of portions of the division

command and staff quite distinct from the requirement to simulate

combat.

2.4.1 Information Flow and Decision Making

2.4.1.1 Man in the Loop. All three of the applications cited in the

problem statement require that the tool or test bed be built around one

or more human decision makers. This statement is, in itself, transparently obvious, but some of its implications may not be. Two

functionally distinct groups can be identified in any combat force

and might be called managers and effectors. Managers are concerned

primarily with decision making under conditions of uncertainty and

with the acquisition of data which reduce that uncertainty, i.e., provide information. Effectors are concerned primarily with the translation of data received from the manaaers into physical processes

which can also create reportable events. A combat simulation

substitutes data processes for the physical processes of real combat.

In other words, the simulation accepts the data generated by the

.I2-3
managers and, in turn, qenerates the data provided to them by the effectors and by other manaqers. The facet of the problem addressed

here arises from the fact that the simulation of physical processes

may not proceed at the same rate as the physical processes being

simulated. Most computer simulations of combat run at many times the

rate of the processes being simulated. Some manually assessed war

games run at rates far slower than the combat being simulated.

However, when the manager whose decision making is under scrutiny is

actually "in the loop", combat interactions being simulated must, for

many applications, proceed at the same pace that they would in actual

combat, else the decision maker is not in a realistic decision making

environment. Unfortunately, combat is not as gentlemanly as chess

and interactions do not stop while decision makers make up their

minds. There are, of course, exceptions to this general rule. For

example, during the planning stages of a military operation, the

coupling between the ongoing combat interactions and the planning

process are normally not, or should not be, nearly so tight as during

the implementation stage of that same plan. Hence, the combat interaction might well, in the interest of economy, run faster than a real

world pace between plan completion and plan implementation. On the

other hand, in a training situation, it might be desirable to slow

combat interaction to facilitate the learning process.

Sackman*, from studies of the SAGE system, was the first to set

forth some general principles concerning the dialogue between a human

decision maker and a simulation. Although couched in the terms of the

human/computer dialoque, his principles are equally applicable to the

more general problem of man interfacing with any simulation:

0 Real Time Parallelism: Real time digital events should

operate in parallel with, and reflect the pacing of, the

separate and distinct real time characteristics of the

men, equipment, and relevant situation events required to

meet system goals. This parallelism should hold throughout the range of system capacity and associated computer

operating time. Program design and control should accordingly have a structure that results in a close empirical

fit between digital timing and environmental timing as

determined by empirical performance effectiveness thro,,oh

system testing.

9 Temporal Anthropomorphism: The computer system should

optimize around the characteristic variabilities of real

time human norms for effective system performance rather

than try to-fit the human into an alien pace that may

ostensibly be more convenient from program and equipment

considerations.

*H. Sa-man.-mputers, System Science Evolving Society. New York,

John Wiley, 1967.

2-4
- 4 . I

0 Conversational Principle: Human performance in man/

computer dialog will vary with the similarity of the

responding computer system, to the real time exchange

characteristics of human conversation.. .As computer

response time and message pattern deviate increasinqly

from real time parallelism...so will user performance

deteriorate... (pp. 442-443).

2.4.2 Modular Structure

A fundamental requirement for this simulation is that the

five basic staff elements be designed as independent modules. The

basic rationale for modularity is to provide a means whereby any one

or combination of modules miaht be populated with live decision makers

while the remainder were being simulated. The modules can be described in terms of the traditional functions of the US General Staff

9with Troops, viz., Command Group, G-2, G-3, G-I/G-4, plus a Fire

Support Element. Although the G-staff structure remains a valid

basis for partitioning staff functions, it is no longer the sole

basis for staff organization while operating in the field. Modifications to the original G-staff structure (borrowed from the French

Army in WWI) have appeared at an increasing rate ever since the entry of the US into WW II. Two major trends have appeared: the incorporation of numerous specialized activities into the command post,

e.g., fire support, air defense, signal, etc., and the evolution

* into a bi-functional staff consisting of operations and logistics/

administration. What has happened is that the staff has become a

matrix organization. Functions are assigned on a G-staff basis but

are carried out in the new modular locations. After discussions

with ARI and with personnel at the Combined Arms Combat Development Agency at Ft. Leavenworth, the decision was made to proceed

with the traditional G-staff modules. This decision is discussed

in greater detail at paragraph 3.4.

The extent to which ancillary functions such as those performed by the Chemical Biological Radiological Element (CBRE),

Division Airspace Management Element (DAME), Tactical Air Control

Party (TACP), Electronic Warfare Intelligence Operations Center

(EWIOC), etc., are included in the principal staff modules will be

determined by the selection of tactical decision variables and information messages to be incorporated in the simulation (see

paragraphs 3.1 and 3.2).

2.4.3 Modular Data Flow

The problem introduced by the requirement for modularity

must be defined. If the test bed is to have a "stand alone" capability for one or more (but less than the totality) of staff elements,

2-5

!U
4!

it is not only the physical processes of combat that must be simulated, but also the data processes performed by every staff module

that is not manned by human decision makers. Furthermore, this data

processing must be in modules such that any single module or specified

combination can be replaced by human decision makers.

The data flow in a modular staff simulation is portrayed at

Figure 2-2. The figure shows a staff in which only the G-2 module

is manned; all other staff modules are simulations. The outside

ring of the figure shows the data transfers that must take place

between each staff module and the world outside the division CP. This

outside world is represented by the decision outcome simulation. Shown

at the ring inside of the staff are the internal data transfers between

the staff modules. Input and output arrows connect each module with

the internal and exterior data transfer rings. As indicated, each

such pair of arrows is an interface or a potential interface between

a human decision maker and the "simulation." The data processes

and the data flow within the simulated modules do not have to duplicate

that of a real staff module in every detail. But, at every interface between a staff module and the information stream, the simulation must provide realistic data transfers by providing the data normally available to decision makers within the module and accepting

the data* generated by such decision makers. If the simulation were

to exercise only the G-2 module decision makers, only two sets

of interfaces between players and simulation would need be explicitly

defined. If, however, the simulation is to exercise human decision

makers in any of the staff modules or combinations of the

command group and one or more of the remaining modules, all ten of

the indicated interfaces must be thus explicitly defined. This is true

even though the data flow into and out of a given staff-section need

not be as detailed and complete when the module is simulated as when

it is occupied. However, provision must be made in the design to

handle all of the traffic that would occur in the latter case.

Furthermore, if the staff modules are to be indeed modular,

e.g., the same command group (CG) module is employed reghrdless of

which other staff module(s) is populated with human decision makers,

then the CG simulation must be capable of accepting every output of

every other staff section that is routed to it and it must be capable

of generating every output provided by CG to every other module. By

"capable" is meant that it must contain every format, every look-up

table, every algorithm (procedure) needed to generate such outputs

and to process such inputs. It does not mean that all would be

exercised if only one of the other modules is player occupied. If

the player-occupied module were the G-2 module, the G-2 simulation

*The word data is used in describing modeling procedures even though

real world decision makers usually perceive that they are providing

information.

2-6
-4

.. G 3

INTERNEXERNA

DAT DATUBU

FSC EXTERNAL

* Interface for data transfer.

Staff mnrfl. sim~ulation

Fiqure 2-2. Data Flow in M~odular Staff Simulation.

2-7
would need to process and generate only the data exchanges between

G-2 and CG plus those exchanges with the rest of the model that had the

potential of generating G-2 inputs elsewhere.

This, in turn, -imposes a substantial burden on the decision

implementation simulation which must be capable of generating events

at the finest level of detail needed for any intended application.

No division-level combat simulation has ever been built to handle interactions relating to all major staff actions at such a level of detail simultaneously. It appears feasible to design a simulation which

would be sensitive to actions, hence the performance, of a principal

staff officer, e.g., the G-2, but it does not appear to be feasible to

design one that would at the same time be sensitive to the performance

of a G-3 file clerk.

2.4.4 Pgrformance Measurement

The need for performance measurements in a simulation of this

type adds another facet to the problem. This question is further

compounded by the multiple applications for which the simulation is to

be used. In order to examine this question it is necessary to develop

precise definitions of measures appropriate for evaluating combat effectiveness and tactical information system performance. Effectiveness

measures appropriate for evaluating tht outcomes of combat models are

described at paragraph 2.4.6. Performance measures appropriate for

comparing the performance of modules within the information system

(staff modules) include measurement of the following:

* Effort required to carry out information processes.

* Time delays associated with carrying out information

processes.

* Completeness of selected information sets.

* Accuracy of selected information sets.

0 Validity of selected information sets.

* Numbers of personnel and equipment.

To measure the six variables identified above, it is necessary

to define precisely what is to be measured. The above variables are

defined for this purpose as follows:

0 The effort required can be measured in man-hours of

personnel effort required to perform the information

processes needed to carry out specified functions such

as maintenance of a specified file or preparation of a

specified output and the frequency with which selected

files (displays) are accessed.

2-8
@ Time delays can be measured in terms of the time

(usually in minutes) required to perform the information

processes needed to carry out specified functions just

as in measuring effort.

* Completeness of selected information sets can be measured by the presence or absence of the data elements

specified to be included in the set. This implies a

standard of measurement against which this count will

be made and this is established below.

* Accuracy of selected information sets can be measured

by comparing corresponding data elements of the selected set with a standard set. Data elements which

do not match exactly are in error. This measurement

standard is also discussed below.

* Validity of selected information sets is defined as the

combination/intersection of the truth of the information,

as compared to ground truth, and its relevance to the

decision for which the information set has been assembled.

This quality of information cannot be measured directly

in real systems, except on a basis of experience with

real or synthetic systems as will be pointed out below.

0 Personnel and equipment involved can be measured

directly.

Havinq defined the variables to be measured, it is necessary

to look for the appropriate points within the system at which measurements can be made. Numbers of people and equipment pose no problem

because this measurement is a property of the information system

structure beinq investigated and not of its performance. The other

five variables, however, are true performance measures and it is necessary to determine points at which or between which these variables are

to be measured. This illustrated at Figure 2-3. Points at which

measurable data sets exist (data inputs, files, and direct outputs)

have been identified by marking them with letters a, b, or c. The

input sets, files, and data extracts have been marked a to Uenote that

data elemen-s in these sets should be unaltered by any-processing between these points. Data aggregations hcve been marked b to indicate

that data elements contained in this class of data sets can be altered

between input and output but only to the extent that output data elements can be objective combinations of input element. Objective is

defined to mean an a priori rule for combinations already stored in

the data base is used. Outputs marked c, however, contain subjective

combinations of input data elements (combinations not stored in the

data base in advance) and new data elements not contained in the data

2-9
L- +- .- ( , - --

C3C

IVq I

41 1-

0

41 ..

L..

4-) -

U 41

C

-0 S- -J '0 o4-, 4-' 1 

-to L. CL CA t

ex- 00) 

S-4 CC0

4'1 0.344 L

m ~ 0~ 0' =:E=c0 L~~~ ---- ~ 4'04342- ., !.*. 

W C- E Wo=

4J-'4--a,

LU~~~ J m Jl U~ 0 E). 

0) 41 j CD

s- 0 - L

2-10
base. Data sets of class c result from human decision making. The

formal command/staff outputs of the decision making node are shown

along the lower tier of Figure 2-3. They consist of combinations of

the indirect outputs which can be designated as purely of class a,

b, or c. Appropriate bases for measurements at each of the identified

measurement points can now be established.

Appropriate bases for measuring each of the measurable products

are summarized at Figure 2-4.

a Delay time and effort can both be measured between the

inputs and the files. Such measurements provide information on the delay times between inputs and the files

(especially visible files) and on the file maintenance

effort. For data extracts, both can be measured either

between input and extract or between file and extract--

whichever is more appropriate. For the remaining output

products (aggregations, estimates, decisions, and recommendations) both delay time and effort are measurable

between the file and the respective output. A measurement between outputs of this type and input is not, in

general, possible because the identity of the original

input data elements has been lost.

0 Completeness of files, data extracts, and data aggregations is directly measurable by comparison with inputs.

On the other hand, the completeness of estimates,

decisions, and recommendations is not measurable in terms

of inputs since they contain data elements not necessarily all derived from the data base. Their completeness, therefore, can only be measured on the basis of

experience (check lists) and by counting the number

of requests for clarification submitted by the recipients

of such outputs.

* Accuracy of files, data extracts, and data aggregations

can also be measured by direct comparison with inputs.

The accuracy of estimates, decisions, and recommendations, however, can be based only on experience for the

same reasons as for completeness.

* The validity of the decision node outputs is not directly

measurable within the information system itself. Since,

by definition, validity depends on comparing the truth of

information with ground truth, this factor can be measured

only with respect to the physical phenomena that lie beyond the sensors originating the information at the

peripheries of the information system. Only the physical

2-11
ca: CU) U U a)

- CL CL D CD

w) w wL G)

C>.

LUUULU L

w 1- 4. Ln 0

L- Ln0.

-- c- 4-

LUL

>-4-

4 -)t 4-' 4-' czL :r =3 S- 4) -)0 0U1w+J0 0- 0

-L i -a -0 S..

LO C c S- -a L

F-C

C.)L V) : : ) U Q

LL- < *- On01

-L a.' LL

5-J LA - U- D)

0)C

4,.1

L2-12
results of decisions are measurable physical quantities

and these again lie outside the confines of the information system. It is this factor that indeed requires an

effectiveness model to relate information system performance to combat effectiveness. Any attempts at

direct measurement of the validity of information outputs or of files, therefore, can be based only on experience.

The implications for performance measurement for each of the

three applications listed at paragraph 2.1 can now be addressed.

0 Behavioral science research on human performance. For

this application the primary emphasis will certainly be

on measurement of the performance of players in one or

more staff modules in terms of the six variables defined

above. Measurement of combat effectiveness will, in

general, be required only for those measurements which

Figure 2-4 indicates "experience" as the basis for measurement. In those cases where experience will no suffice, combat outcomes will have to be invoked. It must

be noted that combat outcome is a far less sensitive measure than direct measurement of the data. Application of

the simulation for this purpose will also require control

of extraneous variables as closely as possible. For example, it may be desirable not to have a discrete opposing

"Red" player in such a simulation, but to control Red inputs

very closely so as to force the decision making situations

it is desired to study. In fact, for some research of this

kind it may not be necessary to havL a truly interactive

simulation at all; many such investigations can be performed from a completely preset, or "canned", sequence

of events.

9 Analysis and Evaluation of Tactics and Doctrine. This

application can be in either of two contexts The first

is an examination of the impact of new tactics and doctrine on the staff itself. This is an extension of the

behavioral research described above. In fact, it lies

at the opposite extreme from the point of view of performance measurement. The evaluation of tactics and

doctrine on the outcome of the battle is not accomplished

by measuring the completeness, accuracy, validity, or

timeliness of staff outputs, nor the effort required to

produce them. For this application, one is primarily

interested in combat outcomes and measurement of changes

2-13
in combat effectiveness resulting from changes in tactics and doctrine. For this purpose, the presense of an

opposing "Red" player is almost a necessity becuase tactics and doctrine cannot be evaluated solely in terms of

their effectiveness against existing enemy doctrine, but

must also consider the adjustment to new tactics and

doctrine that a reasonably intelligent opponent can be

expected to make. This application is truly a study of

war rather than of staffing for war.

0 Training device. This application encompasses features

of both the above applications. For teaching staff procedures and the mechanics of staff processes, measurement

of the performance of the various staff operations is

paramount. On the other hand, when teaching the doctrinal and policy bases for decision making, demonstration of the relation between decisions and combat outcomes is certainly a preferred training technique.

Historically, in the absence of simulations useable

for this purpose, Army training in command and tactical

decision making has substituted the instructor's experience and judgment for combat outcomes. Student performance was measured against the "school solution."

Employing a battle simulation to evaluate the student's

solution certainly offers a more efficacious training

device. However, in this case, the instructor himself

may prefer to act as the opponent in order to induce the

particular training situation and teaching point desired.

Hence, a simulation for this application needs to provide measures of performance of the kind discussed above

and measured effectiveness as discussed in paragraph

2.4.6 below.

2.4.5 Automated Tools for Players

One of the requirements of the design is that it must allow

for the use of automated systems and tools by the players as well

as the use of an automated system to support the control and play

of an exercise. This requirement adds still another dimension to

the problem of information flow and decision making for the simulation. If the automated tools and system were completely self contained within one of the player occupied staff modules, it would,

of course, not impact on the design of the simulation (e.g., a desk

top calculator used by the G-3 in the preparation of a movement

schedule). Such a restriction would, however, be very limiting and

the intent is to highlight the requirement to study human factors

and staff performance and to train staff members when the staff

module is being assisted by an ADP system such as the Tactical Ooerations System (TOS) which serves more than one staff module by

means of a shared data base and processing facilities.

-- 2-14
Figure 2-5 illustrates the information flow in the elementary

decision node when ADP is added to the node. It will be noted that

some information continues to flow through the Level I (Receive and

Transmit) processes which can be thought of as manual interface devices (radio, telephone, teletypewriter, etc.). On the other hand,

for that information which comes in or is transmitted via the ADP system, new interfaces with manual processes must be developed through

new input/output devices, i.e., computer terminals. It should also

be noted that the information traversing these interfaces may be at

levels higher than Level I and is no longer restricted to the forms

associated with the manual system. In other words, the information

that passes into the manual part of the decision making node from AOP

terminals is already selectively retrieved and may be aggregated. As

such ADP systems are currently designed, capability to use the data

base for higher level operations is limited except as such information

is added in free text, consequently, capability to process such information is also very limited. Nevertheless, such a combined system will now have a dual data base, part manual and part automated.

Clearly, the manual process configuration will change provided the

manual elements within the note perceive some advantage to using the

ADP to process some portion of the information flow. It is also

clear that a precisely defined standing operating procedure must

specify which information will be processed manually and which will

be processed in part through ADP.

The gravity of the problem raised by this requirement now

becomes apparent. Clearly, any information transferred through an

automated terminal must exist on the simulation side of the interface in digital form. Thus, the simulation must contain the data

bases and automatic data processing that would support automated

interface devices. On the other hand, if the players are operating

without ADP assistance, this same information must be transferred

through manual input/output devices. Thus, the interface specification must be variable to reflect varying degrees of ADP assistance

to players, but the simulation must have the capability to process in

digital form the maximum scope of information that it might ever be

desired to provide through automated terminals.

2.4.6 Effectiveness Measures

This discussion is concerned with the requirement for measuring

the outcomes of combat models as distinguished from the measurement

of performance within the information and decision making simulation

which was discussed at paragraph 2.4.4 above.

The outcomes of combat can be distinguished through quantita-

| tive comparisons of three factors:

* Changes in the geographic area controlled by both sides.

2-15

L. 00 .. ....
77

II

A -

ferceve Peceiv

Iwc tu

Figure 2-5. Proce~S esinAPssteTaiclDiio

Nodregae.irqt

. .Rtr Rereb v

2-16q.So-t
0 Changes in the resources available to both sides.

0 Time intervals required to effect the above changes.

Tiede (1967) has demonstrated that ground force missions specify acceptable changes, i.e., specify constraints, in these three factors.1 The

same reference also indicates that one of two objective functions may

be associated with each military mission:

0 Minimization of resource expenditure for missions requiring engagement of the bulk of the available force

(e.g., area defense or penetration).

0 Maximization of area controlled for missions requiring

engagement of small portions of the force (e.g., delay

or exploitation).

Comparisons of combat outcomes in the a terms is conceptually simple

and straightforward but the quantification of these outcomes is frequently difficult.

Measurement of time intervals poses no problem. There are no

great difficulties in measuring times between events (e.g., changes in

resources and in area), provided there are means for determining that

those events have indeed occurred.

Measurement of changes in resources has until recently posed

a fundamental difficulty even though there is no conceptual difficulty

in measuring resources. The problem has been that this factor is

really a multi-dimensional function with no generally accepted method

of aggregating resources of different kinds. For example, a solution

within constraints that expends 50 lives and 10 tanks has minimized

resource expenditure with respect to one that expends 50 lives and 20

tanks. But where is one ranked that expends 55 lives and 5 tanks?

"Total resources expended" cannot be calculated as a single quantity

unless values are assigned to the various classes of resources.

A recently developed methodology called Analysis of Military Organizational Effectiveness Methodology (AMORE)2 does enable one to combine

different classes of resources into a single measure, i.e., potential

unit effectiveness.

For area controlled by a military force, there is a similar

difficulty. Again, as for resources, we have really defined an areaof-control function--not a method for aggregating areas of widely

different characteristics and hence military values. At this stage,

this difficulty can be overcome only on a case-by-case basis, as was

SR.V. Tiede, "A Formulation of Ground Combat Missions in Mathematical

Programming Form," RAC-TP-265, Research Analysis Corporation, July 1967.

2G. Page and S. Rose, "Analysis of Military Organizational Effectiveness (AMORE)," proceedings of the 42d Military Operations Research

Symposium, December 1978.

2-17
suggested for varying classes of resources. It is hoped that the mission statement will specify, or a combat simulation will demonstrate,

the relative vaues of controlling different subareas. Against, we

know from experience that the values of certain key terrain features

may be so high as to dominate a much larger area.

The preceding brief review of some of the factors involved in

quantifying the outcomes of combat shed some light on the output requirements for a combat simulation. Clearly, the status of resources

on both sides of the conflict must be quantified both in terms of

.expenditures and replacements. For division-level combat, the resources to be accounted for must include personnel, major weapons

(e.g., tanks, APCs, artillery tubes and launchers), ammunition by major

category (individual weapons if tactical nuclear war is to be simulated),

and POL. Such resource data will permit calculation of exchange ratios

which may be an important criterion for some comparisons. Maintaining

resource data at a level of resolution much finer than indicated poses

difficult data management problems which are justified only for special

applications.

The area controlled by both forces is another needed output.

This is, in general, a more complicated problem than kFeping track of

FEBA changes. FEBA change is an adequate measure for :lissions in

which the division is heavily engaged in an essentially flankless environment. However, even for many conventional engagements in more

open warfare (e.g., Middle East, Vietnam, or even the North German

Plain) other measures must be provided. It is necessary to have means

for determining which side controls key terrain features such as

dominant ridge lines, bridges, defines, key roads, communication

centers, etc.

Finally, if the dynamics of combat are to be simulated, as is

almost always the case for studies of changes in performance within

the tactical information and decision making system, there must be means

for recording time intervals between events. This can be done either

by recording status at predetermined time intervals or by recording the

time at which selected events occur.

2.5 FUNCTIONAL REQUIREMENTS

From the preceding discussion we can now define the functional

modeules that must be contained in the simulation. The simulation proper

must contain a maximum of seven modules (Figure 2-6). These are

0 A Command Group Module,

* A G-2 Module,

2-18

9.
ogo

CD 0

3EEIX'

SLLa-~ .

U': I M

2-19
0 A G-3 Module,

0 An FSCE Module,

0 A G-I/G-4 Module,

* A Decision Outcome Module, and

6 A Red Command Group Module.

The seventh, Red Command Group, module may be combined with the Decision

Outcome module for some applications to reduce the overhead costs of

operating the simulation, but must nevertheless be designed so that it

will be available for those applications that require it.

For the live staff modules, the design must include a detailed

definition of the man/simulation interface for each of the five staff

modules and the Red Command Group. For the five Blue staff modules,

the design must also provide the needed internal instrumentation as

discussed in paragraph 2.4.5 above.

kI

2-20
Section 3

ANALYSIS OF SIMULATION REQUIREMENTS

3.1 DESIGN PRINCIPLES

The discussion of the problem in the preceding section has

made it clear that the simulation needed to achieve the design goal

is a rather specialized information system. It must be capable of:

* Accepting and implementing the decisions made by human

players in one or more modules of the Blue division staff.

0 Simulating those processes that will produce feedback to

the selected staff module(s).

0 Generating and presenting the feedback at the appropriate

time and in a realistic manner.

* Calculating the final outcome of the battle being simulated in terms of the selected measures.

0 Measuring the human performance within the selected

staff module(s).

Of these five requirements, the first four are highly interrelated and

determine the design of the simulation proper. The fifth is concerned

primarily with instrumenting the non-simulated portion and is related

to the first four only insofar as the simulation must provide some

of the data points needed to measure human performance.

In developing the design concept, the following principles

have been followed:

1. For each Blue staff module and for the Red command module, the selected decision variables and their associated

input and output messages establish the scope of the

simulation.

The application of this principle requires definition of some of its

terms. An input is defined as an inbound data package (message) received by a staff module. An output is defined as an outbound data

package (message) transmitted outside the staff module. A decision

variable is defined as any decision class or type that results in one

or multiple outputs. It may be as simple as a decision to disseminate

an incoming message to another staff module or as complex as a formal

operations plan or order. However, once the range of decision variables

to be included in the simulation has been established together with

their associated outputs and the inputs needed to make those decisions,

the scope of the entire simulation has been set. In order to appreciate this fact, one must realize that every input is but a report of

3-1

--
an event whether that event was triggered exogenously to the simulation by the scenario or internally by the clock or through interaction. In a sense, the outputs and inputs selected as a result of the

choice of decision variables comprise the "meta-language" through

which the players and simulation communicate. It should be noted that

this is the reverse of the usual approach to scoping a battle simulation or war game. The more usual approach is to select the range of

scenarios and interactions to be encompassed and then to design an

information system which will make it play.

2. The selected inputs, outputs, and their associated

events are tied together by means of event threads

which fix their sequence and time of occurrence.

The application of this second principle determines the level i

of resolution of the simulation in terms of the unit size of the forces

carried in the data base, the state variables needed to describe those

units, the unit of resolution of those state variables, as well as

the needed time resolution. This follows directly from the concept

that each input to a staff module is the report of an event. Thus,

the reportable events determine the level of aggregation that can be

tolerated. For example, it is unlikely that any selected input will

require the reporting of an individual rifle shot. For purposes of

reporting ammunition expenditure, aggregation of rifle firing to battalion level at three hour intervals may suffice. On the other hand,

for the purpose of reporting an initial contact with the enemy, aggregation of individual rifle firing may be possible only to company

level and the report may be triggered by a transition in posture from "1moving (in APCs)" to "engaged," and may need to be reported to the

nearest minute.

3. The simulation must contain every event thread needed

for every input/event/output relationship.

This principle simply means that the simulation must be capable

of accepting and implementing the totality of the selected decision/

outputs. It must also be capable of triggering every reportable event

whether triggered by interaction, the scenario, or the clock. While

the totality of all event threats must be made explicit within the

simulation, not all such event threads will necessarily be activated

in every application. It is possible that some event threads will

have the property of being connected to less than the full set of

staff modules. Such event threads would be activated only if needed

to process inputs and outputs from live staff modules.

Table 3-1 illustrates how the design requirements imposed by

the application of the above principles apply to each of the seven

simulation modules shown at Figure 2-6.

3-2

p!
VI) LI) 4-) 4-)

>I >

-0 (A) 4-) WU LUJ

(0 4-) = C ._ a- O: O 0 -0 Ln )

C)S.- CL 4-' ) -0 . a E 4-. C C- C:- (0

Cu4- S c 4-S- E- (1 1- *-_ a) -C. 4-

F - LI) v, ) 4- (-'W 4-- --) 0)

=*- - o r, U 0 0 LJ U a- u WO O 17' d) (1) Cu 4-' > S- 4-) >5. S_ ) LUJ a: C) M LL) 0U- LI) Lu0a ro

4-)

C '- u C .J W u- _.j - CU =L)

Z~y C C CD - C CuW

VI) LU E E E 0 E l,, 0 E S- ZL

(D-DC..- .- - S-CuV '-.- a) a)

-6)C -1.. 4Cu Cu +- >u W 4- L

C5 ( Cu Cu ( a) Cu a)- 0) WLU CS.- cu - n M)C C) C:) C)- M) M~ -L

0 LUJ

cn 0 0 0 0 0

4-

U

4-

00

4- Eu

-- 0a ro u 0

C) 4--

I 4-- -

0

Cu E u >

-cCI -

-. 3 3-3

0"room
3.2 DECISION VARIABLES AND INPUT/OUTPUT FORMATS

This section describes the manner in which the decision variables, staff inputs, and the formats for each were defined and selected.

3.2.1 Decision Outputs

Decision variables are defined as any decision class or type

that results in one or multiple outputs. Having made that definition, it is clear that there is a one-to-one correspondence between

decision variables and output classes. Table 3-2 is an example of

such a listing of decision variables (or decision outputs) for the

G-2 section. They have been broken down into major types with a

further breakout by output content. Shown for each is the trigger

event which causes each output to be produced and the usual addressees. Similar listings were prepared for each of the other

modules (Cmd Grp, G-3, G-I/G-4 and FSCE) and are listed in Design

Notes A, B, and C.

3.2.2 Decision Inputs

Shown at Table 3-3 is a listing of the classes of innuts to

the G-2 section. Shown alongside each input class are the usual

sources for each. The remainder of the table is a matrix which shows

the relationship between G-2 inputs (rows) and G-2 outputs (columns).

The "X" entries denote which inputs can provide data for each output.

The inputs and outputs define the interface requirements for a live

G-2 staff module. The matrix indicates which inputs must be connected

with which outputs by event threads when the G-2 module is being simulated. Similar matrices have been prepared for all staff modules and

are contained in Design Note C.

3.2.3 Rationale for Format Development

Having developed reasonably comprehensive lists of inputs and

outputs of which an example is shown at Table 3-3, these were subjected to a three-stage screening process in the course of developing

the simulation formats. These steps are:

0 Classification with respect to simulation requirements.

0 Classification with respect to running time.

0 Classification by formatting requirements.

Each of the above provides a basis for reducing the number of data exchanges that will actually be required in the simulation.

3-4
Table 3-2 G-2 Decision Outputs.

OUTPUT TYPE CONTENT TRIGGER DISTRIBUTION1

Recurring Reports Intelligence Summary Clock (SOP) 1, 2, 3

Para 1, SITREP Clock (SOP) G-3

Weather Forecast Weather Forecast 2, 3

As Required Intelliqence Report Own Initiative 1, 2, 3

Reports INTEL Estimate2 CG Guidance 2

COUNTERINTEL Est. CG Guidance 2

INTEL Annex 3 CG Guidance G-3

Spot Reports NBC 1 NBC 1 1, 2, 3

Retransmit Spot Rpt Incoming Spot Rpt 2

Query4 Own Initiative 1 or 2 or 3

Response 4 Query 1 or 2 or 3

Frag Orders Revise EEl CG Guidance 2, 3

Revise Tasking CG Guidance or 2, 3

Spot Report

Special Request Own Initiative 2

Response Request 2

1. Distribution Code:

1 - Higher HQ

2 - All other staff modules

3 - Subordinate Units

2. Includes Analysis of Area of Operations.

3. Includes new EEl and tasking.

4. Queries and responses may be sent to any addressee in the distribution code and may concern any legitimate area of G-2 responsibility. Coordination actions by other staff modules will also be

handled as queries and responses.

3-5
Table 3-3. Input/Output Matrix for Intelligence Staff Module.

INPUT MESSAGES SORC __

04D CMDR'S GUID TR- - rX05 CMDARS DECow X

-X RETRANSMIT -- T

12 F RORER (FS E -- FX TX

77 EU FIRE SPT CAP Fb X-X -

19 POST STRIKE ANAL FE - T7

XX RETRANSMIT ______YX

-54 NUC WARNNWGORDER G3__ _ XT X T

570 OP PLAN

80D OP EST 3 X 

59 INITIAL EN CONT - G3

XX Of RETRANSMITI

896 REQUEST - GXX

b4 RESPONSE jX

XX R E TRA NSI PC__T

492 FRAG ORDER (SS CIG I TX 

349N0 REPORT 79

35 GENERASITCRSXI

D4 SPELIL REPOT 'CRSXi

43 SPOT REPORT -R3

44 CBT INTELL RPT CORPX_

435 P O ASTK R DM~ W!W V X

*wr SP_ REP5T -.-- X
4

The first classification was accomplished as shown at Table

3-4. This table indicates that there are three classes of outputs and

three classes of inputs. The grouping shown is on the basis of:

0 No interaction with the simulation.

* Interaction with other staff modules.

* Interaction directly with the decision outcome generator.

It will be noted immediately that the class of outputs labeled "external

transmissions" do not need to be in a form assimilable by the simulation.

In fact, they will be ignored by the simulation and will be generated

only by live staff modules. Their content and time of submission may

be useful for evaluating live staff performance. By the same token, the

inputs labeled external message receipt are not generated by the simulation and can, in fact, be part of the initial scenario preparation.

Such inputs would not have to be strictly formatted for entry into live

staff modules, but when the staff module is simulated such entries must

be assimilable by the simulation. It should be noted that all data exchanges with higher headquarters do not necessarily have to be of this

type. For example, a query to corps or a request for reinforcement

could be a direct entry into the decision outcome generator; in this

case, a controller is simulating Corps HQ. The remaining message exchanges, transmissions, and receipts must be made explicit at the module boundaries so that any module can be populated by live players.

Furthermore their interconnection with simulated events, either within

or other staff modules or in in the decision outcome generator, must be

established.

The second step in screening inputs/outputs involves a review

of the listed data exchanges to see which ones are pertinent within

the expected running time of the simulation. Since the simulation is

of division level combat, it is estimated that there will be little

requirement to run the simulation for a time period (real time = game

time) greater than 12 hours. On this basis a number of reports generated by staff modules at periods of 24 hours (e.g., the INTSIJM) can

also be treated as external transmissions. Even though the INTSUM is

provided to other staff modules by G-2, it is basically a compilation

of past events in a convenient format for reference. Actually, the

germane information would already have been passed to the affected

staff modules as retransmissions of spot reports or combat intelligence

reports. Thus, the INTSUM can be treated as an external transmission

even though it is normally routed to higher HQ, to subordinate units,

and to other staff modules. This means that only live staff modules

will be required to produce INTSUMs and this output does not have to

be entered into the simulation. If it is needed as an input to some

other live staff module (e.g., G-3) it can be handled as an external

message receipt, i.e., prepared in advance of the simulation, and

does not need to be generated by the simulation.

;.3 ~3-7

t. ' . J' -
vi

1Z0

0 -

-C 4- oC

>0")

C 0 4,) u0 .- 0 • ) c..J U o- ~ (Al (U 4-' 4- 0 S S- . - 4- = .0 SL.l E) 0 0 0 0

(( 1. - J .00 0 0,. a) c 0'"} 

0 aO u'

- 00 C7 ( 0 V): ,' 

..

.m C w U0'4-'

r_ ,- S u o C 0 0U ) 0 1+'- IV ))4-'

oto ( U- to !- 

4-) (A IA- a'cC U , L. a ) 4)() - 0)03)1- CU CU0'

0. a) M 0

CU4- 4- aj

00

C 0 " C (U S 0 

E

ro ) 0 * U, 4-. 

-

- 04 ) a" E" -' C -- to (" 

, (• ,- (AW C0 (,)4-

co x 0)- = X 4- UJ 0'0 I CA (0

"r- (a_ , 

W

-CA 0 ) 0 

' 0 -0 -) ",-- 4- eU4ULnw a lX 

40 " -- 0 0) 0 ) 

0

0 4LA) rz u = 

0

L4- 

A

E 4-3-' 

4 LA 0 (a (04) CLA 

a- Cz 

(a 

0.- 

L 

00- 

-CL

V ME 4-' E

4) U 1 *(' (a CD C 1 ea0 r_ 0)(1)

C (L. 0) CA 4-J - 4J ' (..0 A SO

'U X 0,0 .. 00 ) >10

S.- 0'- LA41 

-

0) C . ) CAI3-
rI

The third step in.the process of developing the final list of

formats consists of sorting based on content. It Is highly likely,

for example, that a number of spot reports with different names,

based on content, can in fact be represented by a single format containing the basic "who, what,.where, when, why" data. On the other

hand, it may also be necessary to break out some of the inputs shown

as single entries in Table 3-3 into multiple formats in order to accommodate different information categories. After this process was

completed we were in a position to make the final format selection

and definition. The formats selected appear at Design Note D.

3.3 DYNAMIC REALISM

The realistic time sequencing of events in the simulation is

based on an event-store technique in which the simulated time clock

is tied to a real clock so as to provide slow time, real time, or

fast time play. The input to individual Blue staff modules or to the

Red command module, i.e., the tactical information messages from the

field (or from higher headquarters), represent one class of events

whose sequencing must fit into the event-store framework. The output

directives and orders from Blue staff modules to Blue units in the

field or from the Red command module to its subordinate units represent

a second class. In addition to these "interfacing" classes, there are

three other classes of events which must also be handled by the eventstore mechanism.

The five classes of events required in the simulation are defined in Table 3-5. Each class will require a separate set of rules

or algorithms in the simulation, but all classes will have to fit

into the general event-store framework. The separate modes for handling the events, examples of events in each class, and special simulation techniques to be employed with some classes are presented in

paragraph 4.1.

The logical flow of the simulation procedures providing the

time sequencing of events is illustrated in Figure 3-1. The process

will require a large data storage array called the Event Table. The

table will contain separate entries for all events (of all five

classes) that will occur at some time in the future of the current

simulated clock reading. Such entries will be called "scheduled

events". They will be extracted from the table and the corresponding

entries erased when the simulated clock arrives at or near the time

associated with the individual events. If one or more new events

arise as a consequence of the processing of a scheduled event, these

new events are then put into the Event Table so that they become

scheduled for processing at some future time on the simulated time

clock.

4 3-9

k6_ A M-1.m
4JJ

4-A E 4- 0) 4"

0 C1 41 4- 4.J 1 * 4-1

00-) .-. .-. ) .4--.) 4- 4.) 4J.) 0) )

4- > 41 -.> tA 4- m ) f0)

V -0) 0 "0 1 S- (D EC S- ) v.) 5o 0, .,--

4C 0)0 W-. U 4- u.

o> r) .- J mC a-.C

I.,-) - -. -w L . -:: 0. ) U 0

0 *- -0 di w

to a1 (U(a , (

- >. 0C ) 0 .- - u, - (..

U to 0 MO 4-) m.

5 ,5 - 0 --- - ,

04- 4)00 - a .- > 0o (.

> ) U -0-0 -,a A 0 C

0) a,- >a . 4 -

- V . 0 - S- 0 

U CO OU U Jj §1 IIJ: u (7 

4-) 4- E C 4- 0..) c I W) "

, 4 - 0.) E U) 4-3 . CL t.- o -4-

co S- a e r_ - X (7

-o a ooo - w C

4- n 4- W W 0c 0 0

0 CA( ' - Q ) -v) > )4

.C CU 00 ,.. 4- (L + . CU a.- L.

I) 4- 34)L 4-.. u

4-) () CU 0 E 44 U L >'-1 ) 4-0

Cc S~. (A-+ 0 c 0.

-- 0u

,a .4. 0 3 c).

0~- CC 43 CO'M

S- C qj w) CLa = C

3-00- .v S- (a

0) Ua 4-C4-)

S-41 4) LU 4- =) .) 0

U4- 0) () 0)a s- a)4C

0 C> > 0 4-' 0

4.) U 1-J 0)J 4-0)( 0 .

0)~V 4). =- 4 r.) 4-)

4- 0 0 0 Q 05 >41 t

a- W)U) 4-) (a tio 0 0

(U 0 to U 4.(L)1. c 

41u 1- (1 0) U0

aj~~..0 4)4-C.01S 

>) o) . ) cu c+ 0 4-

-L C\M cm1 4m L 4' ) (V4-)U

4-t.( E > 4

3-10
Begin I

DIVISION SIMULATION

THE NEXT EVENT IS EXTRACTED FROM

THE EVENT TABLE AND THE ENTRY

ERASED

ALLOWING A MARGIN OF PROCESSING

TIME, THE EVENT IS PROCESSED WHEN

THE EVENT TIME COMES UP ON THE

SIMULATED CLOCK

I 'IS THE EVT A MESSAGE RECEIVED

EVENT (INPUT TO A -BLUE STAFF

MODULE OR TO THE RED COMMAND

MODULE)?

MODIFY AND UPDATE REAL WORLD ACCESS AGGREGATE AND DEGRADE

BASE ACCORDING TO SIMULATION REAL WORLD DATA AND FORMAT

RULES THE TACTICAL INFORMATION

MESSAGE

IF EVENT IS THE PROGENITOR OF NEW

EVENTS, SCHEDULE THESE EVENTS BY

NEW ENTRIES IN THE EVENT TABLE

DOES THE SIMULATED TIME CLOCK

INDICATE THE END OF THE DESIRED

EXERCISE IN SIMULATED COMBAT?

NO YES

End

DIVISION 51MULAT

Fiqure 3-1. Logical Flow of the Event-Store Simulation.

3-1I
The central data processing problem in implementing this eventstore technique is the ordering or arranging of the scheduled events

so that they may be readily extracted in the proper time sequence. It

is estimated that the number of entries in the table (covering all

classes of events) will range between 100 and 500 durin any moment in

the active play of the simulated combat. However, the loading of

each new event requires that the order of arrangement of entries be

modified so that the correct time sequence is preserved.

3.4 DESIGN DECISIONS

A number of questions arose during the evolution of the top

down design of the simulation. The resolution of each of these questions affected the overall design concept. Most of these were resolved during Phase I of the design effort and the decision made is

discussed below. However, in two cases the questions were not resolved and additional design effort is needed.

3.4.1 Traditional G Staff Versus Bi-Functional Staff

This question was raised in paragraph 2.4.2. The nature of

the difficulty can best be appreciated by looking at the staff structure specified by some of the current doctrinal literature. This is

illustrated in Figures 3-2 through 3-5 which have been extracted

from TC 101-5, 'Control and Coordination of Division Operations,"

April 1976.' Figure 3-2 shows the configuraiton for a division tactical command post (TAC). Figure 3-3 shows the configuraiton of the

Main division command post while Figure 3-4 is a blow-up of the Tactical Operations Center (TOC) contained in "Main". It is immediately

apparent that the G-staff functions are not the basis for organizing

the various staff activity centers. G-2, G-3, and FSE functions are

being performed both at TAC and at TOC. In fact, the same is also

true of command group, G-l, and G-4 functions, although to a lesser

degree. Figure 3-5 is a representation of the locations in which

G-2 functions are performed which have been indicated by cross-hatching.

It will be seen that G-2 functions are being performed at four different

activity centers, three in TOC and one in TAC. The difficulty of designing a pure G-2 module now becomes clear. If the requirements for

man/simulation interface are to be met, the "players" or "subjects"

must be played in a realistic operational environment. The reason

for combining G-2 and G-3 elements in an Op Center at TOC is the extensive interface between these two staff elements needed for actual

operations. That interface would have to be simulated by controllers

for a "pure" G-2 module.

A basic principle of any modular design is to draw the boundaries around modules so as to minimize the interconnections between

modules. A feasible modular structure that parallels TC 101-5 is

depicted at Figure 3-6. The five modules identified are:

3-12
RADIO /

CONTRO0L .e

-7 N G-2/G-3 RATT

FS E

" USAF !

• O. ADA

MULTICHANNEL ADA USAF

SWITCHBOARD

RADIO < RELAY

"Covered and concealed from the air."

Figure 3-2. Tactical Command Post Configuration.

I

3-13

V
r* p

SIG PT % ORPS~

MULTICHANNEL RATT

COMMCEN §Cpy GENR " RW

[ (See also Figure-3) IS SYSCON

SWBD

k W

I !

MEDICS C OF S

HHC DISTR

HHC MSG

CEN

RATT

"Covered and concealed from the air."

DIVISION

MULTICHANNEL

SYSTEM

Fiqure 3-3. Main Command Post Configuration.

I

3-14

Av
x(-x x x- Xx Kx

FA M

NRATT GENR

xGENR+x

X~A GENR

TSEE

IC _ _ INTEL RATT

x x ALLSOURCEf- OP CENTER IINTE LIGENCEG2G.

USAF RADI

AnN)IINTACP, R&S

x ENTRANCE

x x x-x-L--- X X -x

Figure 3-4. Tactical Operations Center Confiquralton, Main CP.

3-15
RATT

J.JUI I;1 ADA'.. U SAF

-"I3

I ADID

C I I 1 il /OV

~ FA

RATT 1AJO

I K Li\\I\\* ADA

J-1.C~~ >-! INE 7

- ~ ~ ~ X 7 -1 RZ,~ SF l.I

SO i __ rrn Liz 7 ] \ x

ENTrIANC L

Figure 3-5. Locations of G-2 Activities.

3-16
"- - C . r--- nd

IULTIC 1A: . L ADA/ . I US'F ,\>- :,-'K

SWI'VTCH ;OAF'L' '

/-

. "L I

•~ on cFSE

-Ari r

1 .i L _r r- L

I I L G 2 Ci 

nhir S AF PAU

1 ' - >O >ci _ ' -_7:'

x ENTRANCE RAT

x x x~ -[ x' xWCUr

Figure 3-6. A Feasible Modular Structure.

3-17
0 Command Group at TAC (to include G-2/G-3/ADA/FSE/USAF

elements)

0 Operations Center at TOC (to include Reconnaissance and

Surveillance element)

* All-Source Intelligence Center at TOC

* FSCE at Toc

* ADMIN, G-I/G-4 at TOC.

The above discussion brings into clearer focus the problem

raised in the discussion of modular structure in paragraph 2.4.2.

The identification of inputs and outputs for each of the G-staff elements is fairly straightforward.from the doctrinal literature. This

is not the case for the bi-functional staff described in TC 101-5.

The identification of the inputs and outputs for each of the staff

modules in the bi-functional staff is not spelled out in the doctrinal literature and would, in fact, depend on the SOPs in effect in

a particular division. In effect, one would have to make an arbitrary

assignment of decision outputs to each module and determine the inputs needed to support these. This process is compounded by the fact

that under this concept the module boundaries row separate portions

of the same G-staff module (for example, G-2 activities would be carried on in three different modules). This means that the data exchanges between different portions of the G-2 staff element would now

have to be made explicit at the new module boundaries, whereas they

were implicit within G-2 when it was a single module. Thus, the

module input/output matrix could, in fact be significantly larger

resulting in a larger number of formats that would have to be handled

by the simulation.

These considerations were discussed at some length with ARI

and jointly with representatives of ARI and the Command and General

Staff College at Ft. Leavenworth. The final decision was that the

traditional G staff organization would be the basis for organizing

the staff modules in this simulation.

3.4.2 Nuclear Events

A design decision was required with respect to including

nuclear events in the simulation. The inclusion of such events imposes the following additional requirements on the design of the

simulation:

* Adds the requirement for unique exchanges between staff

modules (Class 2 events).

0 Adds the requirement for unique outputs from the staff

modules to subordinate, adjacent, and higher headquarters (Class 3 events).

3-18

pI
0 Adds the requirement for unique inputs to the staff

modules from subordinate, adjacent, and higher headquarters (Class 4 events).

The above requirements, in turn, require:

* Unique events internal to the staff modules for processing decisions associated with nuclear events

(Class 1 events).

0 Unique events internal to the battle outcome generator

and the rest of the outside world (Class 5 events).

0 Unique characteristics for units within the data base,

e.g.,

Individual nuclear rounds remaininq in nuclear

capable delivery units.

- Changes to the combat effectiveness of combat

units in a "warned" posture.

Despite the additional complexity incurred by including the

capability to exercise the decision variables associated with nuclear

warfare, this capability is of such importance that it was included

in the simulation design and the associated events are included in the

detailed annexes. It is, of course, not necessary to use nuclear events

in any particular scenario if not required for the purpose of the

investigation.

3.4.3 Simultaneous Planning, Execution, and Reportinq

Another design decision concerned the requirement to exercise

the staff modules simultaneously in activities associated with

planning future operations and executing and reporting on current operations. A number of considerations entered into this decision.

First, staff planning is normally isolated from the monitoring of

current operations because:

* "Operations" is concerned with the management of the execution of a prior plan.

0 The planning process is triggered by an actual or projected change in mission and is based on (and as insensitive as possible to) assumed future states (capabilities, threat, environment.

* Plans are revised (coupled to real world states) as

the time for execution approaches.

Hence, there is little requirement for real time inputs from the ongoing battle purely for planning purposes.

3-19
The second consideration was that computer simulation can assist planning but not plan. This results directly from the fact that

the degree of uncertainty associated with planning is even higher than

that associated with execution. After fll, the decisions required

during execution concern the modifications required to adapt a prior

plan to the realities of the world as the uncertainty is reduced

through execution. If the latter decisions are too complex to simulate completely by means of computer algorithms, this is even more

true of planning decisions.

Finally, the worth of a plan, once prepared, can be evaluated

in only one of two ways (see also the discussion at paragraph 2.4.4):

* Comparing it the "school solution" (experience).

0 Implementing it, to include simulating its execution.

The above considerations led to the basic decision that the

activities associated with the preparation of complete, formal operations plans and orders, or the portions thereof assigned to a particular staff module, would be performed only by live staff modules and

not by simulated staff modules. Data required by a live staff module

for OPLAN/ORDER preparation can be obtained in one of two ways:

a Current situation data may be obtained "on-line" by

queries to simulated staff modules or the battle outcome generator, as appropriate.

* Other data will be prepared "off-line" in advance by

the controller and may be accessed by the players on

request.

A completed OPLAN/ORDER (or assigned portions thereof) is transmitted

by the live staff module to the controller who logs it in for later

evaluation of staff module performance. Such an OPLAN/ORDER has no

direct impact on the ongoing simulation. The requirement to perform

such planning activities does, of course, impact on the workload, and

hence the stress, imposed on a live staff module and thus effect its

performance in monitoring and controlling the on-going battle.

If a completed OPLAN/ORDER is to be evaluated by executing it

within the simulation, it can be introduced by the controller in the

same way that he would introduce the special situation and any operations orders prepared by players in advance of the simulation,

normally by means of a preprocessor, for any other kind of play.

This will, however, require that the on-qoing play be stopped at some

appropriate juncture in order to transition to a new OPLAN/ORDER.

.t 4- 3-20

.D. N -- ' '= . .
3.4.4 Other Staff Elements

As has already been indicated in paragraph 3.4.1 above, there

are many other staff elements collocated or closely associated with

the five staff modules of the Blue staff being simulated. For example, much of the detailed management of the sensor systems available to the G-2 and the production of intelligence from these sources

is performed at the All Source Analysis Center (ASAC) which is part

of the operations center of the CEWI Battalion. Similarly, engineer

information processing is performed by an engineer element, CBR processing by a CBRE, Army air activities by a DAME, Air Force air support activities by a TASE, etc. The decision was made to incorporate

such activities into the battle outcome generator where they would be

handled in the same way as subordinate units, i.e., their activities

would not be simulated explicitly, but those of their outputs and

inputs that flow across the five explicitly modeled staff modules

would be made explicit as are orders to and reports from subordinate

units.

3.4.5 Simulation of Command and Control

The following question arose with respect to the design of

the simulated command and control elements within the simulation:

0 How can the simulation of command and control actions

within the simulation (non-populated staff modules,

other staff elements not specifically represented, and

subordinate staffs) be carried out so as to reflect a

realistic, variable level of performance by populated

staff modules?

This problem is best explained with reference to Figure 4-1.

As shown in that figure, Class 1 events occur within staff modules;

Class 2, 3, and 4 events occur at the staff module boundaries; and

Class 5 events occur within the Battle Outcome Module. The design

provides that these events are to be connected by event threads which

cause the successive events to occur in the prescribed logical sequence.

Within a populated module the players themselves carry out the Class

1 events and react to or generate the interface events. In a simulated module, these threads must be provided within the simulation.

It is conceptually a simple matter to close the event threads that are

routed through the simulated modules so that they are essentially insulated from any perturbations to the information flow that might occur if a populated module did not behave in the manner being simulated

when the module is not populated. If the model were designed in this

manner, the only abnormal behavior of a populated module that would

be reflected in the simulation would be failure to close an event

thread that led through that module. Such a design would not be responsive to the major objective of providing feedback to players on

the results of their actions. The simulation should show the effect

of degraded performance within a live staff module in all of the

3-21 'U
other command control activities being simulated. This will require

very careful and detailed analysis of all event thread routing to

insure that the effects of incorrect staff action by a live staff

module are, in fact, portrayed as unforeseen events and delayed and/

or degraded reports that would result. Examples of such degraded

performance by a live G-2 module would be: faulty tasking of sensor

systems that would reduce the enemy information available to the

command group or the G-3; Assignment of an intelligence mission to

the cavalry squadron without coordination with G3 which resulted in

non-availability of the squadron for an operational mission; or,

faulty tasking of sensor systems that denied important target information to the FSE.

One important facet of this problem that cannot be overlooked

is the real world response time to such faulty actions. For example,

faulty tasking of sensors by G2 that resulted in degraded target information for the FSE would affect the on-going battle. Faulty sensor tasking that reduced intelligence available to the G3 or the command group could affect the on-going battle, but would even more

likely lead to bad planning for tomorrow's battle. The latter effect 

fects 

is 

of 

difficult 

faulty staff 

to capture 

actions 

in 

that 

a 4-12 

lead 

hour 

to degraded 

scenario. 

planning 

Thus, the 

for

ef- I

future action may be difficult to capture without implementing the faulty plan.

This problem has not been resolved in the current effort and

additional design effort will be needed before a simulation can be

built that will implement this design objective.

3.4.6 Task Design for Interactive Simulations-#

Another question arose with respect to populated, i.e., interactive, staff modules:

0 How should the tasks within a populated staff module be

designed or redesigned so as to emphasize those tasks

which are the subject of investigation, deemphasize

those which might only increase player boredom and decrease his interest, and do this in a manner which retains realism and credibility?

This problem arises from the following consideration. If the

simulation is to be a cost-effective tool for research, not only must

the personnel requirements be held to a minimum in the control section, but the number of players in a live staff module must also be

held to a credible minimum. One way to approach this goal is to

eliminate some of the low skill level, high frequency, and hence,

boring tasks within the staff module. An insight as to what this entails may be gained by viewing the staff module as a decision node

and looking at the sequence of kinds of processes that it performs.

3-22

42MNNI- -k
Figure 3-7 is a representation of a series of processes such

as a decision node carries out on information flowing through the

node. At the bottom of the figure is an external information stream--

the communications network--which the node taps and to which it contributes. Six progressively more complex processing levels are depicted. The information that flows up from the external stream must

first be received, a Level I or communications process. The received

information in a tactical military system is in the form of orders

(plans), summaries, reports, queries, or requests. These must be

tagged, sorted, recorded (think of the large number of telephone and

voice radio inputs), and used to update files; much of it is also

displayed on situation maps or "totes." The composite of these

processes may be called Level II or message center and filing processes. The Level II processes produce a data base, some part of

which is in the form of visible displays for ready reference. It is

pertinent to comment in passing that the graphical representation of

certain kinds of information on-a situation map is the substitute for

the hill overlooking the battlefield and for helicopters when the

latter cannot fly or see.

The next four process levels use the files in successively

more complex ways. Note that they, too, update the files, but these

updates are more in the nature of manipulations on the basic data

added by Level II. These utilization processes begin with Level III,

selective retrieval of information from the files. At Level IV, such

data are aggregated by means of a priori rules, which may vary from

simple arithmetic combinations to more sophisticated rules of combination such as the appearance of three or four maneuver battalions operating in the same area triggers the search for their associated

fire and service support elements. The important consideration is

that the rules for aggregation have been determined in advance and

are stored. Process Level V also aggregates data, but the rules

for aggregation are devised by the user in real time--that is, he

hypothesizes, through pattern recognition, new and higher level interpretations of the data being presented. For example, the rapid

increase in density of artillery in a given sector is interpreted as

an indicator of enemy intent to attempt a breakthrough in that sector.

Process Level 5 may also be accomplished in a succession of stages

that amounts to piling hypotheses one on top of another. Furthermore,

data aggregations may be extrapolated forward in time. This amounts

to yet another hypothesis formulation of a different type; assumptions

are made about observed rates and/or accelerations. For example,

examination of present positions and rates of advance for both sides

leads to a prediction that the main battle will occur at point Y at

time T. Level V produces what is commonly called "perception." At

the highest level, Level VI, data aggregations are compared and

evaluated, and one or more are selected. This last is the culmination of the decision process.

3-23

4

mw
Level VI

Decision

PercapeiGnCOre030

Level IV

Peatioaret

aggrega-- Peregat

a" tin

Level rV

ct ion

proee Mzen1ifrainirc

Fliue 3-7.tressLvlvnaTcialDcso-aigNd

.)-.vl\eJ etiv

19,3-g,

A.. rcr, ot eo
Implementation of the decision requires composing a decision

node output that will be in one of the same forms as were the inputs.

The more complex of these outputs can involve further utilization of

the data base at Levels III through V as indicated. This Implies

that the basic decision acts like a new system input that triggers

additional subordinate decisions necessary for the implementation of

the basic decision. As the arrows show, there may therefore be

reiterative cycling through the data base to complete the composition

of the staff output that implements the basic decision. It will be

noted that this view of the command and staff processing of information is essentially the same as that presented in Chapter 5 of FM

lO-51 and is just another way of looking at the functional flow chart

of the commander's information flow and decision processes. Note

too that every output from the node involves some processing at Level

VI. This may be as simple as a decision to relay an incoming message

to a new addressee, which says that almost every process at every

level has been a one-for-one transformation except for the selection

of one or more new addressees for an incoming message.

With this view of a manual information processing system, we

can gain some insights as to what might happen when we, in effect,

shift the interface between the staff module and the outside world

from its peripheral communication nodes and move some of the lower

level communication and message center and filing functions out of the

module and into the simulation. We are now faced with the problem of

redefining the tasks to be conducted within the staff module in such

a way that the node remains a realistic, credible, military decisionmaking environment, i.e., appears to the players to be a staff element and not a laboratory for studying human reactions. The problem

is quite similar to that faced by the ADP assisted system designer

becaust it amounts to shifting the interface between the decision

maker and the outside world (see also paragraph 3.4.7 below).

This problem, too, can use additional design effort in order

to assure that the simulation, when built, has maximum utility as a

research tool.

3.4.7 ADP Assisted Staff

Paragraph 2.4.5 has already pointed out that providing ADP

assistance to the staff substantially complicates the information

flow. Not only must computer terminals be added to the populated

staff modules, but the simulation data base must be expanded to

provide information to players in different formats and aggregated

differently. For example, much information provided players on a

spot report basis in the manual mode is replaced by access to a

1U.S. Department of the Army, Staff Organization and Procedure, FM

101-5, Washington, July 1972.

3-25
special data base that is updated as a result of simulated events to

reflect the current status of the forces being managed. Such a capability adds a new class of events to the simulation which is defined

in Paragraph 4.1. In order to have maximum usefulness, the simulation should also be able to reflect the effects of making adaptive

software available to players, thus permitting players to make changes

in the amount, kind, reporting frequency, and the format of the displayed information. In order to keep the problem reasonably tractable

and also within anticipated budget constraints, the initial implementation of the model will be a simulation of manual data exchanges

between players and the simulation. The basic design, as will be

discussed in Section 4, will permit the addition of an ADP-assisted

staff capability as an increment at a later time.

3.4.8 Initial Configurations

Another design consideration that needed attention was the

question of the number of staff modules that could be populated

simultaneously. Although the original design concept included all

possible combinations from zero to six (including the Red player

module), it soom became apparent that handling a significant number

of live modules simultaneously would require a substantial personnel

complement within Control. More than one or two personnel within

Control would make running the model prohibitively expensive and

there is no immediate requirement to handle more than two populated

staff modules at one time. It was therefore decided that the initial

implementation would be limited to not more than two populated staff

modules. The expansion of this capability to permit other and larger

configurations will be considered at a later time after experience

is acquired in the actual loadings that will be imposed on Control.

It is also likely that the provision of ADP assistance to staff

modules will reduce the requirement for Controller intervention in

the data flow. This is discussed in more detail in Paragraph 4.4.

I

3-26
. . . . . . .. .. J ... 7 - ,4

Section 4

TOP-DOWN DESIGN

This section presents, first, the general design concept, for

the integrated division-level battle simulation, and second, the basic

elements of the proposed initial implementation. The initial implementation will be subject to the following specific constraints on the

scope of the full concept:

0 One or two human controllers, aided by computerized

preprocessing capabilities and an interactive executive

control routine, will control the play of the game.

0 Configurations of play will be limited to no more than

two populated staff modules (any two out of six modules).

0 Blue staff modules will operate under a manual staff

system only.

The section begins with the fundamental structure of the design concept.

This structure is followed by the specification of the proposed physical layout, computer capabilities, and controller functions required

for the initial implementation. The basic elements of the implementation and the proposed general approach for attaining them are then

described. The section concludes with two subsections: one demonstrating the manner in which the first implementation provides a framework

capable of extensions and augmentations beyond the constraints shown

above and the other providing insight as to the applicability of the

simulation for behavioral science research, evaluation of doctrine and

tactics, and training of the division connand groups/staff.

4.1 DESIGN CONCEPT

The fundamental design concept of the integrated division-level

battle simulation is that of an event-store simulator in which the simulated time clock is geared to a real clock so that the simulated combat

may be played in slow time, real time, or fast time. The basic structure

of the system as depicted in Figure 2-6 consists of seven functional

"boxes" or simulation modules in which command and staff operations and

the resulting division-level combat are simulated by the dynamic portrayal

of the occurrence of significant events in the battle. The structure

handled five classes of such events, as follows:

0 Class 1 - Staff processing events.

* Class 2 - Exchange of tactical information between staff

elements.

4-1
* Class 3 - Tactical information outputs from staff elements.

* Class 4 - Tactical information inputs to staff elements.

•0 Class 5 - All other events in the battle simulation.

The seven modules, and the places where the five event classes fitted

into the conceptual structure, are shown in Figure 4-1.

Subsequent to presentation of the original concept the basic

structure has been further defined to reflect the following additional

components:

An additional functional module - a module which simulates higher headquarters, adjacent division headquarters,

Blue staff elements not delineated by the boxes on the

left, and "acts of. God" events.

0 An additional defined event class - Class 6 events which

are interface events between staff elements and their

ADP terminal devices.

* The controller's role in the simulation.

The modified conceptual structure is shown in Figure 4-2.

4.1.1 Configurations

In the basic concept shown in the two figures, the five Blue

staff modules on the left and the single Red command module on the

right may consist of either a group of human players executing standard

staff procedures or else a set of simulation rules or algorithms for

processing the Class I and Class 6 events inherent in the staff procedures. The choice between the populated version of these modules or

the simulated version depends on the application.

Since the simulation rules or algorithms throughout the structure will always depend on the choice of configuration being played,

that is, the combination of populated modules and simulated modules in

the game, the configuration number has been defined as a basic control

variable in the system. The definition is embodied in Table 4-1.

Configuration number is an integer with a value zero to 63.

The binary representation of configuration number delineates the populated modules and simulated modules selected for play. The control

variable itself must be incorporated into the basic logic of all simulation rules in order to assure that the proper internal and external

routing of tactical information messages is preserved.

It should be noted that the basic design concept, with its 64

alternative configurations, reflects a fundamental asymmetry with

4-2

~4-2
-

--

- --------------------------------------

04

I 0 a)

I IM

4--3 .9 I 40

CU~

I 00 I -11 r- 4- - I

a §a

4-3
41)

I z2C

I I U)

I I >

m '0

'A~ La

IL La 0 J 4-3

o-

(u( 4-

CL V)

CIO0*-

4-4-
Table 4-1. Configuration Number

CONFIGURATION BINARY NUMBER OF IDENTIFICATION OF

NUMBER REPRESENTATION POPULATED MODULES POPULATED MODULES

0 000000 0 (none)

1 000001 1 BLUE CG

2 000010 1 BLUE FSE

3 000011 2 BLUE CG and FSE

4 000100 1 BLUE G2

5 000101 2 BLUE CG and G2

6 000110 2 BLUE FSE and G2

7 000111 3 BLUE CG, FSE, and G2

8 001000 1 BLUE G3

9 001001 2 BLUE CG and G3

10 001010 2 BLUE FSE and G3 11 001011 3 BLUE CG, FSE, and G3

12 001100 2 BLUE G2 and G3

13 001101 3 BLUE CG, G2 and G3

14 001110 3 BLUE FSE, G2 and G3

15 001111 4 BLUE CG, FSE, G2, and G3

16 010000 1 BLUE G1/G4

17 010001 2 BLUE CG and GI/G4

18 010010 2 BLUE FSE and G1/G4

19 010011 3 BLUE CG, FSE, and GI/G4

20 010100 2 BLUE G2 and GI/G4

21 010101 3 BLUE CG, G2, and G1/G4

22 010110 3 BLUE FSE, G2, and GI/G4

23 010111 4 BLUE CG, FSE, G2, and GI/G4

24 011000 2 BLUE G3 and GI/G4

25 011001 3 BLUE CG, G3, and G1/G4

26 011010 3 BLUE FSE, G3, and GI/G4

27 011011 4 BLUE CG, FSE, G3 and G1/G4

28 011100 3 BLUE G2, G3, and G1/G4

29 011101 4 BLUE CG, G2, G3, and G1/G4 30 011110 4 BLUE FSE, G2, G3, and G1/G4

31 011111 5 BLUE CG, FSE, G2, G3, and

GI/G4 32 100000 1 RED CMID only

33 100001 2 BLUE CG vs RED CMD

34 100010 2 BLUE FSE vs RED CMD

35 100011 3 BLUE CG, FSE vs RED CMD

36 100100 2 BLUE G2 vs RED CMD

37 100101 3 BLUE CG, G2, vs RED CMD

38 100110 3 BLUE FSE, G2 vs RED CMD

39 100111 4 BLUE CG, FSE, G2 vs RED CMD

40 101000 2 BLUE G3 vs RED CMD

41 101001 3 BLUE CG, G3 vs RED CMD

42 101010 3 BLUE FSE, G3 vs RED CMD

4-5

* p
Table 4-1. Configuration Nunber (continued)

CONFIGURATION BINARY NUMBER OF IDENTIFICATION OF

NUMBER REPRESENTATION POPULATED MODULES POPULATED MODULES

43 101011 4 BLUE CG, FSE, G3 vs RED CMD

44 101100 3 BLUE G2, G3 vs RED CMD

45 101101 4 BLUE CG, G2, G3 vs RED CMD

46 101110 4 BLUE FSE, G2, G3 vs RED CMD

47 101111 5 BLUE CG, FSE, G2, G3 vs

RED CH1D

48 110000 2 BLUE GI/G4 vs RED CMD

49 110001 3 BLUE CG, GI/G4 vs RED CMD

50 110010 3 BLUE FSE, G1/G4 vs RED CMD

51 110011 4 BLUE CG, FSE, GI/G4 vs

RED CMD

52 110100 3 BLUE G2, GI/G4 vs RED CMD

53 110101 4 BLUE CG, G2, G1/G4 vs RED

CMD

54 110110 4 BLUE FSE, G2, GI/G4 vs RED

CMD

55 110111 5 BLUE CG, FSE, G2, G1/G4 vs

RED CUID

56 111000 3 BLUE G3, G1/G4 vs RED CMD

57 111001 4 BLUE CG, G3, GI/G4 vs RED

CMD

58 111010 4 BLUE FSE, G3, G1/G4 vs RED

CMD

59 111011 5 BLUE CG, FSE, G3, G1/G4 vs

RED CMD

60 111100 4 BLUE G2, G3, GI/G4 vs RED

CMD

61 111101 5 BLUE CG, G2, G3, GI/G4 vs

RED CMD

62 111110 5 BLUE FSE, G2, G3, GI/G4 vs

RED CMD

63 111111 6 BLUE CG, FSE, G2, G3, G1/G4

vs R'D CMD

4-6
respect to the Blue and Red sides in the'play of division-level combat.

The Blue side will always consist of the division command group and

principal staff sections, whether the individual staff elements are

populated modules or simply simulated modules. The Red side, on the

other hand, will consist of only the Red commander himself (with possibly an assistant). The Red Command Module will always present the

commander with "completely staffed" alternatives for decision. He will

execute his command functions without further assistance from staff

elements.

4.1.2 Classes of Events

The different classes of events associated with the basic design

concept are shown in Figure 4-2 by the open-faced arrows with the class

numbers inside. The Class 1 events (staff processing) and the Class 6

events (staff interfacing with their field ADP terminals) are shown inside the five Blue Staff Modules and inside the single Red Command

Module. The Class 2 events (staff coordination between staff sections)

are shown interconnecting the five Blue Staff Modules. The Class 3

events (frag orders to subordinate units, reports to higher headquarters,

and other staff outputs) are shown emanating from the staff modules and

pointing into the interior modules of the simulation: the battle outcome generator (BOG) and the other units module. The Class 4 events

(staff inputs; reports from the BOG or the other units module) are shown

with arrow heads reversed from those of Class 3. Finally the Class 5

events (battle events and events stemming from other units) are shown

wholly inside the interior modules of the simulation.

All events represent significant occurrences in the divisionlevel combat, but Class 2, Class 3, Class 4, and Class 6 events are

further qualified as "interface" events because they deal exclusively

with tactical information flow. It will be shown below that the definition and numbering of interface events will always be associated with

the specific tactical information messages or documents identified in

Design Note A.

The position of the human controller(s) in the basic design

concept is shown in Figure 4-2. As it relates to simulation events,

this position suggests some controller involvement with the imposition

of certain decision choices, intervention with military judgement, and

the handling of staff input/output. The controller's station shown in

the middle of the simulation, therefore, implies the following two

design imperatives:

* One or more human controllers will always be required

to run the game.

0 The controllers will have to perform their functions

according to the schedule of events and the simulated

time clock.

4-7
A detailed specification of the controller's functions depends on the

level of computer assistance used to implement the simulation and on

the actual procedures followed in playing populated staff modules. This

specification is given in paragraph 4.2.2 for the initial implementation.

Under any proposed implementation, however, there will always be

certain Class I events and Class 5 events in which the controller(s)

must intervene in order to supplement the logical rules of the simulation or to influence the onslaught of events on a populated staff module.

These Class 1 or Class 5 events are therefore further qualified as

"release" events, because the controller(s) must execute their "release,"

that is, complete the intervention on or before the time of occurrence

as measured by the simulated clock. The specific release events in the

initial implementation and the method provided for controller intervention are discussed further in paragraph 4.3.6.

The remainder of this subsection provides the definitions and

detailed descriptions of the events in each class that have been identified for the simulation.

At the beginning of the basic design effort, an event numbering

convention was adopted to provide a basis for organizing the large number of events anticipated to emerge in each class. The convention is

shown in Table 4-2.

Table 4-2. Event Numbering Convention Used in the Basic Design.

Class 1 Events are numbered 100 to 199.

Class 2 Events are numbered 200 to 299.

Class 3 Events are numbered 300 to 399.

Class 4 Events are numbered 400 to 499.

Class 5 Events are numbered 500 to 599.

Class 6 Events are numbered 600 to 699.

It can be seen from the table that the convention is based on

the a priori assumption that the design will involve no more than 100

defined events in each of the six classes. In the material that follows,

only a subset of the hundred numbers have resulted in basic event definitions. Furthermore, beginning with the Class 2 events, the interface

events will exhibit event numbers that are directly related to the

standardized tactical messages.

4-8

L.
4.1.2.1 Staff Processing Events

Class 1 events are the action-handling steps performed by individual members of a staff section in completing a required staff action.

For every input/output relationship prescribed for the staff element

(see Design Note C), there will be a standard operating procedure (SOP)

spelling out the action steps required. These steps will be executed

whenever the staff element is triggered to perform the staff action.

If the staff section is a populated staff module, the action

steps will be executed entirely by the human players. The simulation

itself will acknowledge the completion of the staff action only by means

of the interface events (staff outputs) stemming from the action; it

will not record the occurrence of individual action steps nor measure

the performance of the players regarding conformance to the action SOP.

The performance measurements on human players will be handled in a separate manner, as discussed in Section 5.

Class 1 events have meaning only for those staff sections that

are simulated staff modules. Under all configurations of play except

one (configuration "63" in Table 4-1), one or more staff modules will

always be simulated in order to provide the full division staff environment required for a single populated staff module.

For simulated staff modules operating under a manual staff system, the action steps in each staff action will consist of, and be

represented by, a thread of Class 1 events. All such event threads will

contain an internal trigger, or starting, Class 1 event, and one or

more terminating, or ending, Class 1 events. The number of events simulated between the trigger and the terminating action steps will depend

on the individual action SOPs and on the level of detail used in simulating the staff action.

The event numbers and definitions of the Class I events that represent the internal triggers and the terminators of all staff actions

are presented in Table 4-3. Class 1 events are specified further in

Design Note I and the internal triggers and terminations are defined in

Design Note J. Included in the Design Note I material is a discussion

of two areas that require further research to improve the efficiency of

the simulation.

The simulation will provide basic rules or algorithms that will

generate the interval of simulated time taken to complete staff actions.

r This interval will be a function of the level of action traffic impinging on the staff section as well as the number of action steps in the

staff actions.

Some staff actions will contain intermediate Class 1 events that

are release events, that is, events which require controller intervention as described above. For example, in an exercise with a populated

A: 4-9
Table 4-3. Class 1 Events.

Event Number Definition of the Event

Internal

Triggers

100 Clock ifdicatesthat is is time to initiate staff action.

101 Receives a tactical information message from BOG or higher HQ.

102 Receives a retransmitted copy of input to another section.

103 Receives an info copy of output by another section.

104 -o Receives a query from another sect on.

105 Receives a request for concurrence rom another section.

lOb Receives a request for consideration from another section.

107 Receives a concurring response to a request for concurrence.

108 Receives a non-concurring response to a request for concurrence.

109 Receives an info copy of a request frag order.

110 Receives a non-concurring response to a request for consideration.

III Receives a response to its query to another section.

112 Receives information from another section.

Action .

Steps

(Not yet defined.)

Terminators

189 -Sends to selected staff elements.

190 Issues frag order or warning order.

191 Initiates query .2

192 Initiates a request for concurrence 2.

193 Initiates a request for consideration3.

194 Initiates a report for higher headquarters.

195 Aggregates its information on file for a response.

196 Issues a concurring response to a request for concurrence.

197 Issues a non-concurring response to a request for concurrence.

198 Issues a non-concurring response to a request.

199 Retransmits copies of its input.

1For all staff modules except Blue CG, queries will be automatically

separated into staff queries or queries to subordinate units. The

Blue CG module will have the selectable option between staff queries

or queries to subordinate units.

2 A request for concurrence is based on a frag order under initiator's

purview.

3A request for consideration is based on a frag order under recipient's

purview.

4-10 p
G2 staff module and a simulated G3 module, the G2 player(s) might submit

a request for concurrence to G3 regarding a Frag Order (Intel). The

release event would occur following the trigger (Event No. 105 in Table

4-3) in the simulated G3 module. On or before the time of occurrence,

the controller would have to insert the decision to reflect the choice

of the alternative responses by the G3 (Event Nos. 196 or 197 in Table

4-3).

4.1.2.2 Staff Coordination Events

Class 2 events are interface events covering the exchange of

tactical information between staff sections. The internal routing requirements of all staff actions, staff queries, requests, and responses

will be effected through Class 2 events.

In accordance with the fundamental asymmetry of the basic design,

Class 2 events will be used at the interfaces between Blue Staff Modules

only; no Class 2 events will occur with respect to the single Red Command Module. The Red side, whether it is a populated module or a simulated module, will always deal with completely staffed tacticl decision alternatives and will not be concerned further with staff coodination.

Staff coordination exchanges on the Blue side, on the other hand,

can occur in four different ways, depending on the combination of populated modules and simulated modules being played. The four alternative

kinds are as follows:

0 The initiator of the exchange is a live module; the

recipient is a simulated module.

0 The initiator is a simulated module; the recipient is

a live module.

0 Both the initiator section and the receiving staff element are simulated modules.

0 The initiator and the recipient are both populated modules.

Class 2 events are defined for all four cases.

If the initiator of the exchange is a populated module (as in

items 1 and 4 above), then the Class 2 event will be initiated by a

pencil copy or typewritten copy of the exchange prepared by the human

players, transmitted by the controller/computer, and then printed as a

*machine prepared message. Oral exchanges will not be permitted.

If the recipient of the exchange is a populated module (as in

items 2 and 4), then the human players in the module will receive the

Class 2 message from the controller/computer. The coordination exchange

will always appear as a machine prepared message to the human recipients.

4-11

pI
The times of occurrence and the tactical information message of

all Class 2 events regardless of the cases above, will always be recorded

and logged by the simulation in order to provide a basis for post processing analysis of the staff coordination exchanges.

The event numbers and definitions of the Class 2 events are

shown in Table 4-4. The table specifies 65 different events numbered

according to the numbering convention cited above. The last two digits

of the event numbers are the embedded reference numbers for the standardized tactical information messages whose simulated flow will be one

of the central features of the basic design. The message reference

numbers will be seen to occur in one or more of the remaining interface

event classes. They stem from Uesign Note A: The list of Individual

Tactical Information Messages.

Class 2 events are further specified with respect to the manner

they will be handled in Design Notes G and J. Design Note G gives the

logical rules for Class 2 events. Design Note J contain the event thread

charts showing the progenitors and follow-on events associated with the

staff coordination exchanges.

4.1.2.3 Staff Output Events

Class 3 events are the frag orders, warning orders, and queries

sent out by the staff modules to subordinate units in the field as well

as the periodic reports and requests submitted by the staff sections to

higher and adjacent headquarters. These staff output events are all

interface events dealing exclusively with tactical information flow and

corresponding to the staff output messages listed in Design Note A.

Staff outputs, like other interface events, will consist of two

kinds of tactical messages in the basic design. The first type message

will be one containing basic decision variables affecting the simulated

combat. This type will always trigger one or more battle events (Class

5) so that the course of the simulated conflict will change in response

to the frag orders issued by the staff sections.

The second type of staff output will consist of the required

reports to Corps or adjacent divisions such as Preplanned Requests for

Fire Support, the Division Intsum, Division Sitrep, and Division Personnel Daily Summary. These reports represent outputs stemming from

required actions on the part of the different staff sections, but having no direct bearing on the simulated combat events in the BOG within

the running time of a given simulation.

It will be seen that the distinction between the two kinds of

staff outputs is preserved in the proposed implementation of the design.

The decision variables will be incorporated into the simulation rules

associated with battle events in the BOG. The tactical documents not

4-12

-- '"' m I I -... " i.. .. .T.. ... ...... ...... .
Table 4-4. Class 2 Events.

Event Number Definition of Event

Initiated by Command Group

201 Query to principal staff section.

202 Info copy: Nuclear Release Request.

203 Mission Analysis

204 Commander's Guidance

205 Commander's Decision

Initiated by Fire Support Element

210 Query to another staff section.

212 Info copy: Frag Order (FS)

213 Info copy: Immediate Request to Corps for Fire Support.

214 Info copy: Preplanned Request to Corps for Fire Support.

215 Rexmttd copy: Arty Sitrep.

216 Rexmttd copy: Arty Target List

217 Rexmttd copy: Friendly Unit Fire Support Capability.

218 Rexmttd copy: Enemy-Unit Fire Support Capability.

219 Post Strike Analysis

220 Fire Support Annex

221 Staff Request to another section.

222 Staff Response to another section.

223 Rexmttd copy: Immediate Request for Fire Support.

224 Rexmttd copy: Preplanned Request for Fire Support.

225 Rexmttd copy: Target (Intel).

226 Rexmttd copy: Fire Support Status

Initiated by G2 Section

230 Query to another staff section.

232 Info copy: Frag Order (Intel).

233 Info copy: Division Intsum.

234 Rexmttd copy: NBC Report.

235 Rexmttd copy: Weather Forecast.

236 Intel Para Division Sitrep.

237 Intel Estimate.

238 Intel Annex.

239 Staff Request to another section.

240 Staff Response to another section.

241 Rexmttd copy: Bde Intsum.

242 Rexmttd copy: Shell Report. 243 Rexmttd copy: Spot Report.

t2* Rexmttd copy: Combat Intelligence Report.

245 Rexmttd copy: Post Strike Damage Report. 246 Rexmttd copy: Estimate of Enemy Strength.

247 Rexmttd copy: Target List (Intel).

4-13 I'
Table 4-4. Class 2 Events (Continued).

Event Number Definition of Events

Initiated by G3 Section

250 Query to another staff section.

252 Info copy: Frag Order (OPS)

253 Info copy: Division Sitrep.

254 Info copy: Nuclear Warning Order.

255 Info copy: Air Defense Warning Order.

257 Info copy: Operations Plan

258 Operations Estimate.

259 Rexmttd copy: Initial Enemy Contact Report.

260 Rexmttd copy: Unit Progress Report.

261 Rexmttd copy: Loss-of-Contact/Friendly Unit Report.

262 Rexmttd copy: Electronic Order of Battle.

263 Staff Request to another section.

264 Staff Response to another section.

265 Rexmttd copy: Bde Sitrep.

267 Rexmttd copy: Organic Aviation Sortie Status.

Initiated by Gl/G4 Section

280 Query to another staff section.

282 Info copy: Frag Order (CSS)

283 Info copy: Division Personnel Daily Summary.

284 Info copy: Periodic Logistic Report.

285 Info copy: Personnel Requisition.

287 Combat Service Support Estimate.

288 Combat Service Support Annex.

289 Staff Request to another section.

290 Staff Response to another section.

291 Rexmttd copy: Bde/Bn Personnel Daily Summary.

292 Rexmttd copy: CAPE Report.

296 Rexmttd copy: Discom Sitrep. t

4-14
directly affecting the conflict will be "played" as part of staff actions

required of players in populated staff modules, but will not be linked

to the battle outcome generator.

The event numbers and definitions of the Class 3 events are

shown in Table 4-5. The table specifies 27 different staff outputs,

numbered according to the standard convention and with the embedded

message reference numbers used with interface events.

Class 3 events are further specified in Design Notes E and J. The

distinction between the two kinds of Class 3 events is not shown in Table

4-5, but is given in precise deta-il, first, under the message references

in Design Note A, and then in the detailed specification in Design Note

E. The corresponding event thread charts for Class 3 events are

presented in Design Note J.

4.1.2.4 Staff Input Events

Class 4 events are the input tactical information messages to

the staff modules from the interior modules of the simulation. They

will be embodied in periodic reports and spot reports coming from the

subordinate units simulated in the BOG, and in fragmentary orders, intelligence reports, etc. coming from the other units module.

Class 4 reports will be the basic vehicles by which the staff

modules will acquire and maintain their own bodies of perceived information about the "state of the battle." All staff input messages will

reflect not only certain errors and/or omissions in the message content

but also simulated delays in the times of arrival in the hands of the

receiving staff sections, so that the state of knowledge about the

division-level combat held by the staff elements (or the single Red

Command Module) will always be at variance with, and delayed from, the

actual simulated battle events.

The event numbers and definitions of the Class 4 events are

shown in Table 4-6. The table specifies 42 different staff inputs,

numbered according to the standard convention and with embedded message

reference numbers.

Class 4 events are further specified in Design Notes F and J.

Staff inputs, like other interface events, are divided into two types:

those which update the state of knowledge about the on-going conflict

and those which serve as part of a planning activity being pursued at

the same time. Staff inputs are also divided into those messages

which may be "queried" and those which may not. These distinctions

are drawn precisely in the specification given in Design Note F. The

event thread charts covering all Class 4 events are given in Design

Note J.

4-15

tU
Table 4-5. Class 3 Events.

Event Number Definition of Event

Issued by Command Group

301 Query to subordinate units.

302 Nuclear Release Request.

Issued by Fire Support Element

310 Query to subordinate units.

311 Query to Corps regarding its Frag Order (FS).

312 Fragmentary Order (FS).

313 Immediate Request to Corps for Fire Support.

314 Preplanned Request to Corps for Fire Support.

Issued by G2 Section

331 Query to Corps regarding its Frag Order (Intel). 7

332 Fragmentary Order (Intel).

333 Division Intsum.

334 NBC Report.

Issued by G3 Section

350 Query to subordinate units. I

351 Query to Corps regarding its Frag Order (OPS).

352 Fragmentary Order (OPS).

353 Division Sitrep.

354 Nuclear Warning Order.

355 Air Defense Warning Order.

356 Request for Reserves.

357 Operations Plan.

Issued by GI/G4 Section

380 Query to subordinate units.

381 Query to Corps regarding its Frag Order (CSS).

382 Fragmentary Order (CSS).

383 Division Personnel Daily Summary.t

384 Periodic Logistics Report.

385 Personnel Requisition.

386 Immediate Request to Corps for Logistic Support.

4

4-16 t
Table 4-6. Class 4 Events.

Event Number Definition of Event

Received by Cormand Group

(None of the following reports are distributed automatically to the

CG, but some may be procured through "query.")

Received by Fire Support Element

415 Arty Sitrep.

416 Arty Target List.

417 Friendly Unit Fire Support Capability.

418 Enemy Unit Fire Support Capability.

423 Immediate Request for Fire Support.

424 Preplanned Request for Fire Support.

425 Target Report (Intel).

426 Fire Support Status Report.

427 Query from addressee on issued Frag Order (FS).

428 Fire Support Estimate/Annex.

429 Frag Order (FS) from Corps.

Received by G2 Section

434 NBC Report.

435 Weather Forecast.

441 Bde Intsum.

442 Shell Report.

443 Spot Report.

444 Combat Intelligence Report.

445 Post Strike Damage Report.

446 Estimate of Enemy Strength Report.

447 Target List (Intel).

448 Query from addressee on issued Frag Order (Intel).

449 Frag Order (Intel) from Corps.

Received by G3 Section

459 Initial Enemy Contact Report.

460 Unit Progress Report.

461 Loss-of-Contact/Friendly Unit Report.

462 Enemy Electronic Order of Battle.

465 Bde/Bn Sitrep.

466 Air Defense Alert.

467 Aviation Sortie Status Report.

468 Query from addressee on issued Frag Order (OPS).

469 Query from addressee on issued Nuclear Warning Order.

470 Query from addressee on issued Air Defense Warning Order.

471 Frag Order (OPS) from Corps.

472 Operations Special Estimate/Annex.

, , 4-17

p

tU
Table 4-6. Class 4 Events (Continued).

Event Nunmber Definition of Event

Received by GI/G4 Section

486 Immediate Request for Logistic Support.

491 Bde/Bn Personnel Daily Summary.

492 CAPE Report.

493 Preplanned Request for Logistic Support.

494 Query from addressee on issued Frag Order (CSS).

495 Frag Order (CSS) from Corps.

496 Division Support Command Sitrep.

497 CMO Estimate/Annex.

4-18
4.1.2.5 Battle Events

Class 5 events cover all significant occurrences taking place

in the interior modules of the simulation. These events include not

only the actual maneuvers and engagements by units of the opposing

forces but also all the responses to Class 3 staff outputs and progenitors for Class 4 staff inputs.

The maneuver and combat events in the BOG, as well as certain

target detection and intelligence processing events, have not yet been

fully defined. It can be seen that these events have no direct relationship with the separately defined tactical information messages so

that their event numbers do not conform to the rule about embedded

message reference numbers. Battle events of this type are instead

numbered in such a manner that they fall into the unused spaces in the

range between 500-599.

The progenitors and/or follow-on events associated with specific

tactical messages, on the other hand, do conform to the rule even though

they are not themselves interface events. It will be seen, for example,

that events defined as follows:

"Addressee received Query from Command Group.",

"Addressee received Frag Order (OPS).", and

"Corps receives Division Intsum."

are the follow-on events associated with specific staff output messages,

while events defined as follows:

"Preparation of Post Strike Damage Report.",

"Corps xmits Frag Order (OPS).", and

"Prepration of CMO Estimate/Annex."

are progenitor events to their specific staff input messages. Since

the progenitor or follow-on relationship is implicit for all defined

tactical messages except those associated solely with staff coordination exchanges, the rule of embedded reference numbers is carried over

to these Class 5 events.

The event numbers and definitions of the Class 5 events identified so far are shown in Table 4-7. The table specifies 61 events conforming to the rule for embedded reference numbers and 12 events associated with maneuvers and engagements. The latter type events are marked

with asterisks. As new definitions are derived for these events, they

will be inserted in the available unused spaces in the table.

4-19
Table 4-7. Class 5 Events.

Event Nuner Definition of Event

Battle Events

500* Battefield clock indicates it is time to initiate ordered action.

501 Addressee receives Query from Command Group.

502 Corps receives Nuclear Release Request.

503* Unit(s) begin moving.

504* Unit(s) cross phase line or check point.

505* Unit(s) close at destination.

508* Enagement Phase nn; Battle Array nnn.

510 Addressee receives Query from FSE.

511 Corps receives Query on its Frag Order (FS).

512 Addressee receives Frag Order (FS).

513 Corps receives Immediate Request for Fire Support.

514 Corps receives Preplanned Request for Fire Support.

515 Preparation of Arty Sitrep.

516 Preparation of Arty Target List.

517 Preparation of Friendly Unit Fire Support Capability.

518 Preparation of Enemy Unit Fire Support Capability.

519* Enemy target attacked by conventional weapons.

520* Enemy target attacked by nuclear weapon.

523 Preparation of Immediate Request FS.

524 Preparation of Preplanned Request FS.

525 Preparation of Target Report (Intel).

526 Preparation of Fire 3upport Status Report.

528 Preparation of Fire Support Estimate/Annex.

529 Corps xmits Frag Order (FS).

530 Addressee receives Query from G2.

531 Corps receives Query on its Frag Order (Intel).

532 Addressee receives Fran Order (Intel).

533 Corps receives Division Intsum.

534 Preparation of NBC Report or Corps receipt thereof.

535 Preparation of Weather Forecast.

536* Friendly unit(s) attacked by conventional weapons.

537* Freindly unit(s) attacked by nuclear weapon.

538* Assessment of damage from conventional weapons. 539* Assessment of damage from nuclear weapons540* Intelligence Received.

141 Preparation of Bue Intsuni.

n,, nutTter contains no embedded message reference number.

4 -2(
Table 4-7. Class 5 Events (Continued).

Event Number Definition of Event

Battle Events - continued

542 Preparation of Shell Report.

543 Preparation of Spot Report.

544 Preparation of Combat Intelligence Report.

545 Preparation of Post Strike Damage Report.

546 Preparation of Estimate of Enemy Strength.

547 Preparation of Target List (Intel).

549 Corps xmits Frag Order (Intel).

550 Addressee receives Query from G3.

551 Corps receives Query on its Frag Order (OPS).

552 Addressee receives Frag Order (OPS).

553 Corps receives Division Sitrep.

554 Addressee receives Nuclear Warning Order.

555 Addressee receives Air Defense Warning Order.

556 Corps receives Request for Reserves.

557 Corps receives Operations Plan.

559 Preparation of Initial Enemy Contact Report.

560 Preparation of Unit Progress Report.

561 Preparation of Loss-of-Contact/Friendly Unit Report.

562 Preparation of Enemy Electronic Order of Battle.

565 Preparation of Bde/Bn Sitrep.

566 Preparation of Air Defense Alert.

567 Preparation of Organic Aviation Sortie Status Report.

571 Corps xmits Frag Order (OPS).

572 Preparation of Operations Special Estimate/Annex.

580 Addressee receives Query from Gl/G4.

581 Corps receives Query on its Frag Order (CSS).

582 Addressee receives Frag Order (CSS).

583 Corps receives Division Personnel Daily Summary.

4-21
Table 4-7. Class 5 Events (Continued).

Event Number Definition of Event

Battle Events - continued

584 Corps receives Periodic Logistics Report.

585 Corps receives Personnel Requisition.

586 Preparation of Immed. Req. for Logistic Support or Corps receipt.

591 Preparation of Bde/Bn Personnel Daily Summary.

592 Preparation of CAPE Report.

593 Preparation of Preplanned Request for Logistic Support.

595 Corps xmits Frag Order (CSS).

596 Preparation of DisCom Sitrep or Corps receipt thereof.

597 Preparation of CMO Estimate/Annex.

42

-, 4-22
The Class 5 events are further specified in Design Notes H and

J. The distinction between the various kinds of Class 5 events and

their interaction for intelligence is given in detail in Desin Note H.

The corresponding event thread charts for Class 5 events are presented

in Design Note J.

4.1.2.6 Staff Interfacing With Their ADP Terminals

Class 6 event: are defined as those occurrences that take place

when members of a staff seciton enter or read out tactical information

while sitting at the ADP terminal. They are applicable to the design

only when the simulation rules have been expanded to accommodate computerized decision-making aids and the player modules have been equipped

with TOS-emulating terminals.

Class 6 events have not yet been defined.

4.1.3 Computer Assistance

Any implementation of the system design concept described so

far must address the following fundamental questions regarding the organization and play of the simulated conat:

0 How should the data bases be organized in order to store

and to manipulate the Blue and Red division-level forces,

the Blue and Red perceptions of their own and the enemy

forces, the schedule of events unfolding in the scenario,

and the formats used in the tactical information flow?

* What preprocessing activities are required to set up the

play of a specified scenario?

0 By what means do the investigators/controllers set the

control parameters so that the exercise reflects the

desired research objectives?

a What procedures should the controllers then use to control

the play and, at the same time, maintain the desired slow

time, real time, or fast time pace of events?

Each of these basic questions brings into focus a separate aspect of the

role of computer assistance in making the simulation an effective tool

for research, development, and training.

The system design concept could, in principle, be implemented

and played as a slow time, all-manual game without any computer assistance. Indeed, the integrated battle simulation could be run using no

other materials than the equipment for the populated staff modules,

blackboards, preprinted message forms, maps, books or compendia of simulation rules, look-up tables, pencils, and paper. Preparation for

th play and the manipulation of the simulation variables during the

game would require large amounts of time and manpower. A large nuner

., 4-23
of qualified controllers would be required, first, to set up the opposing

force organizations on blackboards and deploy these forces on the controller's situation map, and second to modify the blackboard data bases

and maintain the situation map as the events of the simulated battle

unfolded. A slow time game under these circumstances is entirely feasible, but it is doubtful that the team of controllers could perform its

functions and still keep up with a simulated time cl ck running at real

time. In earlier attempts at all-manual simulations it was found that

it took as long as 8 hours to play 1 hour of combat.

The discussion that follows addresses the various ways in which

a computer could be used to assist in (1) the preprocessing and data

management of the simulation data bases, (2) the interactive control of

the event-store simulator, (3) the use of interactive terminals for

players (to simulate an ADP-assisted staff), and (4) the post-processing

functions. The discussion begins by considering the size and basic

organization of the information or data on which the exercise of the

model would be based. It then follows with separate paragraphs devoted

to the different computer assistance areas above and emphasizing the

manner in which these areas relate to the fundamental questions.

4.1.3.1 Data Organization

One measure of the size of the model design will be the maximum

number of entities and state variables (i.e., limit parameters) required

to define the level of resolution of the combat units in the opposing

forces, the maximum number of such units allowed on each side, the

geographic size of the tactical area of play, and the table or list of

scheduled events used during the play. These sizing parameters and the

basic organization of the major data groups in the model must be specified whether or not the simulation is implemented simply as a manual

game or as a computerized research tool. Sizing and structure considerations will determine the requirements for preprinted message

forms and for blackboard space, in an all-manual implementation; they

will define the basic organization of files and internal data arrays

for a system that is partially or fully computerized.

The sizing estimates presented here are based on the kilobyte

as the unit of measure of the system data. A kilobyte is a "chunk" of

information equivalent to 1000 letters, characters, or numeric digits.

The major data groups required in the simulation are identified

as follows:

0 Real World Data Base

* Blue Perceived Data Base

1 Tiede et al, Information Flow and Combat Effectiveness, Research

Analysis Corps., RAC Report R-lO0, April 1970.

4-24 Af
0 Red Perceived Data Base

* Event Table

* Message Format Specifications and Data Element Dictionary.

Each of the major repositories will have its own organization of data

subgroups and elementary data items. The number of entries in each subgroup will be fixed, and each such number will represent one of the

basic sizing parameters of the system. All major groups except the last

will be dynamic storage media in the sense that individual elementary

data items in them will be capable of being accessed, updated, and/or

erased during the course of the play. The message format specifications

and data element dictionary alone'will be "read only" data, since the

formats and the data element(s)/data chains employed in simulation will

be fixed and invariant.

The sizes of the major data groups, measured in kilobytes, are

shown in Figure 4-3. The figure is scaled to show the relative amounts

of data space required for each group. The overall requirement is

approximately 316 kilobytes.

The basic functions of these major data groups, their principal

subgroups, and the basis for the individual data space requirements are

discussed below.

Real World Data Base. The real world data base will contain

the ground truth facts of the simulated battle as it continuously unfolds by the occurrences of battle events. The basic data subgroups

are (1) the Blue force table, (2) the Red force table, and (3) the

battle array file.

The force tables for the opposing sides will have identical

structure. Each table will be broken down into a unit-type subtable

and a unit subtable. The unit-type subtable will consist of up to 25

unit type entries where each entry contains unit type identification

data and the mathematical force balance coefficients associated with

its weapons. Although the specific data items have not yet been defined*

it is estimated that each unit-type entry will require 120 bytes or .12

kilobytes of information, making the total requirement for the subtable

.12 x 25 = 3 kilobytes.

It should be noted that the information in the unit-type subtable will remain invariant during the course of play, but that composition of the forces, in terms of the types of combat and support units,

may be varied with each new scenario prepared for the play.

*See page H-ll of Detailed Design Mote H in the companion volume for an

| example of a unit type subtable. The state variables needed for each

type unit are a function of the content of the Class 3 and 4 messages

to be processed and the combat interaction algorithms employed.

4-25

iI
V

REAL WORLD DATA BASE

* Approximately 86 kilobytes of data

* Includes: Blue force table

Red force table

Battle array file

BLUE PERCEIVED DATA BASE

a Approximately 25 kilobytes of data

RFn PFR(FIVFD fATA RASE

@ Approximately 15 kilobytes of data

EVENT TABLE

e Approximately 90 kilobytes of data

s Accormiodates up to 600 scheduled (projected) events at any

given time

* Each scheduled event contains full message content or full

event description

FORMAT SPECIFICATIONS AND DATA ELEMENT DICTIONARY

* Approximately 100 kilobytes of data

a "Read only" storage

e Includes: Standard tactical message formats

Separate dictionaries for all format entry

variables

Rate of advance tables, etc.

Figure 4-3. Sizes of the Major Data Groups.

4 4-26

-.
Examples of unit types one might use in synthesizing a Blue

force are as follows:

0 Mechanized Infantry Company

4 Tank Company

0 Armored Cavalry Troop

•. Arti1lery Battery (Type 1)

* Artillery Battery (Type 2)

o Engineer Company (Type )

* Engineer Company (Type 2)

0 Air Defense Battery

0 • Aviation Company.

Each of these unit types will reflect a different set of mathematical

coefficients to be used in the force balance formulae in the battle

events.

The unit subtable will consist of up to 150 unit entries where

each entry contains all tht data and running variables associated with

a specific company-equivalent unit in the division. The specific data

items necessary to cover all the data and running variables have not

yet been defined, but the following categories of items have been

identified:

• Unit identification and unit type designation

0 Chain of command in the current organization fo- combat

0 Posture state, location, and status of the unit

a Personnel strength and resources.

All categories but the first will be subject to modification or update

during the course of the play. It is estimated that each entry will

require 200 bytes or .2 kilobytes of data space to cover these categories, so that each unit subtable will require altogether .2 x 150 =

30 kilobytes.

The third subgroup in the real world data base will be the battle

array file. This file will contain arrays of data identifying the specific maneuver units and combat support units on each side during the

time the opposing forces are engaged in active combat. Separate arrays

will exist for different battles taking place in different iocations in

the tactical area of play. An individual battle array will be created

whenever, during the course of a simulated exercise, Blue units and

opposing Red units first make contact. The array data will remain on

file until the outcome of the engagement is resolved and the opposing

forces have broken off contact.

4-27
The size of the battle array file is estimated to be 20 kilobytes. The limit parameters on the maximum number of separate arrays

and the maximum number of units on each side that can be engaged have

not yet been determined.

To summarize the sizing and data space requirements of the real

world data base: the basic design will accomodate a Blue force and a

Red force, each consisting of up to 150 company-sized units. The composition of the forces may consist of up to 25 different types of maneuver units, combat support units, and combat service support units.

During an exercise, these forces may be grouped together in a number of

separate battle arrays. The maximum number of arrays and the maximum

number of opposing units in a single array have not been determined.

The data space requirements, based on these subgroups, are as

follows:

Blue force table: 3 + 30 = 33 kilobytes

Red force table: 3 + 30 = 33 kilobytes

Battle array file: 20 = 20 kilobytes

Total Requirement = 86 kilobytes

Perceived Data Bases. The perceived data base on each side consists of the side's perception of its own troop list and operations

SITMAP as well as the enemy order of battle and dispositions. The real

world data base and the separate perceived data bases are conceived as

distinct bodies of information because neither side will ever enjoy true

and full knowledge of the deployment of the units of the other side nor

even up-to-date and precise knowledge of its own troops. Accordingly,

the basic design concept includes a Blue and Red perceived data base

each containing unaggregated information about its own troops and the

enemy forces. During the course of the play, the information in these

data bases will be continually modified by the occurrences of the Class

5 report generation events (see paragraph 4.1.2.5). The occurrences

will usually be followed by corresponding Class 4 events at which times

the staff modules will "receive" tactical information messages. The

messages will be formatted according to standard message formats and

based on data aggregated from the perceived data base. Thus, the "state

of battle" reflected in the information will always be delayed in time

and subject to errors and omissions with respect to the true facts in

the real world data base.

For certain experimental or training purposes it may be desirable

for RED to have access to the undegraded, undelayed data stored in the

real world data base. For such applications, the controller would assume

the functions of the RED player. As controller, he would already have

access to real world information in order to maintain his real world

situation map and could, therefore, play RED with perfect information

(see paragraph 4.2.2 below).

4-28
In concept, the perceived data base will always exist in two

forms: first as tabular arrays of data available ordinarily only to the

controller(s) and/or computer, and second as the series of troop lists,

modified organizations for combat, situation map overlays, numerous files,

etc., set up and maintained by human players in populated staff modules

during an exercise. The first form may be thought of as the body of

facts about the conflict marshalled by the Blue or Red sides, while the

second form will reflect the way the commander and his staff organize,

aggregate, and sift the known facts to facilitate decision making.

The tabular array form may also be used for certain Class 1

events, executed in simulated staff modules. Whenever the simulated

staff section must reference its own files, maps, or charts in order to

respond to staff queries or requests, the simulated action step will

entail the aggregation and formatting of data from the tabular array.

The Blue and Red perceived data bases will exhibit a fundamental

asymmetry in the system design concept. Both data bases will contain

the tabular arrays of unaggregated data covering the status and dispositions of their own units and the garnered intelligence about the opposing forces. But the Blue data base will contain an additional subgroup

of data called the "scratch pad area."

The scratch pad area is conceived as the supplementary data space

that will be required whenever the Blue Staff Modules are played using

Class 6 events under an ADP-assisted staff concept. Although the precise formulation of the decision-making aids are not known at this time,

it is assumed that the field computer system will eventually provide (1)

access to the "raw data" in the tabular arrays and (2) the ability to

aggregate, reorganize, disregard, or extrapolate the information in order

to address tactical decision alternatives. The scratch pad area is the

place where the data formulation will be stored.

The tabular arrays on both sides will consist of two subtables

each. The subtables wll contain 150 entries each. The first subtable

will be the FRENSIT table; the 150 entries will correspond to the 150

unit table entries of the real world data base friendly forces. The

second subtable will be the ENSIT table; its 150 entries will correspond

to the 150 units of the enemy forces. The elementary data items in

FRENSIT and ENSIT tables will consist of "state-of-knowledge" indices*

and data-time-group records of the last (latest) reporting times. It is

estimated that individual entries will require about 50 bytes each, so

that a single full tabular array will have a data space requirement of

150 x (.050 + .050) = 15 kilobytes.

It should be noted that the tabular arrays will contain only the

current, or latest reported, data on friendly and enemy units; they will

*A state-of-knowledge (SOK) index is a one-digit integer whose value

represents the current state of knowledge about an item of friendly or

enemy force information.

4-29

F

r'
not reflect historical or out-of-date information. If out-of-date information is, or becomes, an important part of decision formulation,

these data may be saved for retrieval by "rolling out" the tabular arrays

periodically on magnetic tape.

The scratch pad area on the Blue side is arbitrarily assumed to

require about 10 kilobytes of data-space.

To summarize the sizing and data space requirements of the perceived data bases: the basic design will include separate Blue and Red

perceived data bases whose structure will match any real world data base

force tables. No additional constraints will be imposed beyond those

already cited for the real world data.

The Blue perceived data base, which contains both the tabular

array and the scratch pad area, will have a space requirement

15 + 10 = 25 kilobytes.

The Red perceptions, consisting solely of a tabular array, will have a

data space requirement of 15 kilobytes.

Event Table. The Event Table is a large data storage array

necessary to implement the event-store mechanism on which the battle

simulation will be based. The basic operation of the event-store technique and the role served by the Event Table are described in Section 3.3.

The Table will consist of spaces for up to 600 scheduled events.

A scheduled event is a significant occurrences projected to occur at

some time in the future of the current reading of the simulated clock.

During the course of the play, scheduled events, that is, individual

entries in the Event Table, will be continually extracted and erased,

leaving empty spaces in the table. With the processing of each such

event, new events are usually generated and these newly scheduled events

are put into the table, inserting the data in the firt blank or empty

space encountered. The central problem in implementing the technique

is that of stringing the scheduled events together continually so that

the correct time sequence of event processing is preserved. Under proper sequencing, the "fill" in the Event Table, that is, the number of

non-blank entries, will dynamically change up and down depending on the

particular event threads unfolding in the simulated battle.

Every non-blank entry in the table will contain the following

data items or data subgroup:

0 Event time (measured in minutes) 10 bytes

* Event type index 4 bytes

0 Previous event index 3 bytes

0 Next event index 3 bytes

4-30

p
* Event message content or battle event

description 130 bytes

The further break-down of the event message content or battle event description subgroup has not yet been made. It is proposed, however, that

this subgroup contain sufficient data to fill in all the blanks in a

one-page tactical information message, or alternatively, to provide full

confirmation of the conditions on which a battle event is contingent.

The Event Table, under this scheme of data organization, will

require altogether

600 x (.010 + .004 + .003 + .003 + .130) = 90 kilobytes.

Message Formats, Dictionary, and Other Tables. The last required

major data group is significant primarily because it consists of all the

"hard wired" data in the battle simulation. The basic system design

clearly reflects two distinct kinds of elements: variable elements and

hard wired elements. The variables are the input data, the selectable

configurations of play, the range of alternative scenarios, and the

control parameter settings for alternative research objectives. The

hard wired elements, on the other hand, are the simulation rules, the

sizing parameters, the event threads specifying the logical progenitors

and followers of every defined event, and various categories of fixed

or invariant data. The data categories are all stored together in the

major data group called the format specifications and data element dictionary; they include the repertoire of tactical message formats used

in all information flow in the model, the dictionaries of permissible

words or phrases to oe employed with the formats, the specification of

the five "G" staff elements, rate of advance tables used in simulated

engagements, etc.

Hard wired elements, like the steel and concrete in a building

under construction, represent the underlying structural framework of the

basic design. After the steel framework has been fully assembled and

the concrete finally poured, any modifications or variations in the

structure become a matter of expensive redesign or retrofitting.

SAI believes it is important in the pursuit of any implementation

of the basic design to identify all the hard wired elements in the simulation structure and to document these elements so that they can be

understood by the eventual users.

The hard wired data is estimated to require 100 kilobytes of

data space. The subgroup organization of the formats, dictionaries, and

tables has yet to be specified.

4-31

- p . . . ,,-
4.1.3.2 Preprocessing Functions

Preparation for an exercise of the simulation, regardless of

whether the exercise is directed toward behavioral research, the study

of new tactics, or the training of staff officers, will always have to

cover three phases of preprocessing activities. Assuming the design of

the experiment, the General Situation, the separate Blue and Red Special

Situations have all been specified, the required preprocessing phases

are as follows:

* Phase I - Creation of the Real World Data Base:

- Specification of the Blue divisional forces. - Specification of the Red opposing forces.

- Specification of the tactical area and the deployment of the forces.

* Phase II - Initialization of the Blue and Red Perceived

Data Bases:

- Specification of the state of knowledge held by the

Blue side, consistent with the research objectives

and the Blue Special Situation.

- Specification of the state of knowledge held by the

Red side, consistent with the research objectives and

its Special Situation.

* Phase III - Scenario Event Loading and Setting the

Control Parameters:

- Specification of the exogenous trigger events, consistent with the research objectives and the desired

scenario.

- Adjustment of control parameters to emphasize special

aspects of the basic objectives.

- Creation of the Scenario File.

The final activity of Phase III consists of recording on a permanent

information storage medium (magnetic tape or computer disk) all the information specified under all three phases. The Scenario File then

provides the basis for repeated exercises of the same experiment, carried

out under identical conditions but using different human players.

The preprocessing activities above will be the means for effecting the play of alternative scenarios and a range of different experi--

ments under each scenario. The only constraints imposed will be the

sizing parameters cited in the last subsection. It is visualized that

the users of the integrated simulation will eventually create and keep

on file a number of different experiment/scenario combinations to be

used in various exercises of the model. The materials on file for an

individual combination would include the specification of the design of

the experiment, the General Situation, the Blue and Red Special Situations, and the magnetic tape Scenario File.

4-32

Ae
The use of a computer to assist in the preprocessing activities

would simplify the task of setting up an exercise for play. The computer

could take over entirely the functions of the data organization in the

system data bases, the sizing limitations, and the creation of the Scenario Files. The required phases cited above suggest a preprocessing

system consisting of three computer programs, as illustrated in Figure

4-4. The three programs could perform the separate preprocessing functions specified for Phase I, Phase II, and Phase III. The system, in

effect, could provide for the progressive "building" of the Scenario

File. The first program could generate an output FORCES File containing

the hard wired data of the system and the fully developed Real World

Data Base. The latter major data group could be synthesized by reading

the input data which would contain the desired Blue and Red force information. The second program could take the FORCES File and add to it the

initialized forms of the perceived data bases, creating thereby its output PERFOR File. The biasing of the states of knowledge held by the

two sides could be effected by additional input data. Finally, the

Phase III program could generate the fully initialized SCENARIO File,

based on the scenario trigger events and the control parameter settings

read from the input data.

The preprocessing system would reduce significantly the time and

manpower necessary to set up the model. Furthermore, it would provide

the means for "setting the switches" so that the exercise stemming from

the SCENARIO File reflects the desired research objectives. The system

of three computer programs can be seen to be structured to minimize the

amount of back-tracking necessary to adjust an experiment to emphasize

different aspects of the basic objectives. If the controller/investigator

wishes to replay an exercise and change the time constraints imposed on

a populated staff module for its staff actions, he may do so without any

rebuilding of the SCENARIO File. If he wishes to modify the quality of

the information flowing into a populated staff module, he will be required

to go back to the Phase III preprocessor and create a new SCENARIO File

with modified control parameter settings. If he wishes to modify the

initial states of knowledge if the Blue and Red sides in the simulated

conflict, he will have to go back to the Phase II preprocessor. Finally,

if the experiment(s) is(are) to be oriented within a different scenario

using different compositions of forces, it will be necessary to go back

to the Phase I preprocessor and create a new version of the Real World

Data Base.

4.1.3.3 Interactive Control of the Event-Store Simulator

Any exercise of the battle simulation will be keyed to the initial

conditions and composition of the forces recorded on a fully processed

SCENARIO File. The actual play of the exercise will always be directed

by human controller(s). Controllers will be required not only to assure

that the execution of battle events as well as information flow events

occurs with the desired dynamic realism but also to intervene with certain of these events in order to influence the pursuit of thf baOil ,-

tives.

3I
MOR

c2EE

uj,

V))

V) >-

0-

jt

4-34L
The number of human controllers, and the specific functions they

must perform, depend on the kind of computer assistance they are given

and on the actual procedures followed in playing populated staff modules.

Accordingly, the basic goals of a computerized event-store simulator

are (1) to minimize the number of human controllers required, (2) to

relegate to the computer all the more-or-less mechanical aspects of controlling the play, and (3) to facilitate the controller's intervention

so that he may effectively apply military judgement as well as principles

of behavioral science during the play.

In this framework there are two alternative ways the computer

assistance could be implemented. In the first method, controllers would

be provided with a large number of selectable batch-processing computer

programs where each program separately accessed the real world data base

and the perceived data bases on the SCENARIO File. The individual programs would govern the execution of the battle events and the staff

input/output. The selection of the appropriate programs to run- and the

timing of the runs would be handled manually (by the controllers) on the

basis of a computer-printed schedule of events.

The second method would entail a continuously-running event-store

control program in which the controllers are provided with interrupt/

override controls so that they may insert the decision variables invoked

by populated staff modules and intervene with release events to influence

the information flow input to the staff players. This method would involve computer techniques beyond those of a conventional interactive

program. Once the simulated battle had been set in motion, the method

would have to provide a means for the continuous pace of the battle

events regardless of the time of response reflected by the staff outputs

from the populated modules. In short, the conflict would continue with

the combat units following the most recently received operations orders,

until the engagement was resolved or until the staff modules issued fragmentary orders changing the course of the battle.

Both methods would require some kind of clock display to show

the controllers and populated module players the passage of simulated

time during the play. These clocks, of course, have to be geared to a

real clock in such a manner that the controller(s) could set the simulated clocks so that they ran at slow time, real time, or fast time

according to the basic objectives of the exercise.

Both methods would also have to provide some kind of computer

output media for the exclusive use of the controllers so that the controllers could be kept abreast of the details of the simulated conflict

as it was reflected in the real world data base. The media could be

either an automated situation map display or a printed message log.

Under the latter medium, the controllers would have to set up and maintain their own situation map by preparing overlays or using simple grease

pencil entries based on the tactical message traffic coming out on the

4-35

p.

U
message log. Since the information on the situation map would represent

the ground truth facts about the simulated combat, it would ordinarily

not be made available to players in populated modules.

Finally both methods must include the same logical structure for

Event No. 508, the fundamental engagement event (see paragraph 4.1.2.5).

An engagement event will always be associated with a battle array entry

in the real world data base; the occurrence of the event will determine

(1) whether the combat engagement is resolved or continues, (2) the aggregate force balance ratios obtaining during the engagement period, (3)

the losses in personnel, ammunition, equipment, and the resulting fire

power on both sides during the interval, and (4) the rates of advance

and withdrawal by the opposing forces. In formulating the logical structures for this event, SAI plans to make every effort to effect the transfer of techniques and to use lessons learned from existing battle simulations. Such transfers and lessons, however, will necessarily be interpreted in the light of the differences between the underlying game assumptions of the existing models and those adopted here.

Computerization of the event-store simulator, and the choice

between the two methods described above, clearly depend on the hardware/

software resources as well as the operating system ir the computer facilities designated for system installation. A trade-off also exists

between the number of different functions assigned to the controllers

and the facility with which a small number of qualified personnel could

perform these functions. Any proposed implementation must specify exactly

the particular controller functions and show how the computer hardware/

software can be used to assist the controller(s) in carrying out the

functions without burdening them with esoteric programming details.

4.1.3.4 Interactive Terminal for Players

If the integrated battle simulation is exercised with the assumption that the Blue division staff elements operate under a manual staff

system, the transmission and receipt of tactical information by individual

sections can be simulated by using conventional computer input/output

equipments. A populated staff module will issue its outputs (Class 3

events or certain Class 2 events) by submitting pencil copy or typewritten

copy of the tactical information messages to the controller(s). The

controller(s) will then make the necessary computer data entries representing the message transmission by means of field telephone, tactical

net radio, or teletype or the hand delivery by courier. The populated

module will receive its inputs (Class 4 events or certain Class 2 responses) by means of ordinary teletype printers. Individual tactical

information messages will be printed with their standard formats; the

top line of the printed material will simulate the receipt stamp that is

always associated with incoming messages. Successive messages received

by the players should be torn off as the players embark on the staff

actions associated with the separate inputs.

' ,*. 4-36
In a staff system with field ADP assistance (e.g., TOS), the

battle simulation will have to be expanded to accommodate the Class 6

events and to emulate the tactical data management processes of the

field computer. Populated staff modules will require terminal hardware

beyond that described above. Using these enhanced field ADP facilities,

the players will now not only transmit and receive a large amount of

their own tactical message traffic but also employ computerized decisionmaking aids in executing their staff actions. The precise role of the

tactical communications and the precise nature of the algorithms providing the decision-making aids have not yet been defined, but it is known

that the interactive terminals for the players must match the field

equipment closely with respect to the keyboard procedures, the data

entry language, and the display formats. When the simulation is exercised in a TOS environment, the players in a populated staff module

should see the same kind of data processing equipments and carry out

the same procedures that will ultimately be applied in the field.

SAI recommends that the initial implementation of the basic

design anticipate insofar as possible the data space requirements and

the added simulation rules necessary for simulating division staff sections in the TOS environment, but that incorporation of TOS-emulating

player's terminals be delayed until the properties of the field terminals are better defined. The simulation hardware/software requirements

under a manual staff system can be fully specified at this time; those

for an ADP-assisted staff cannot.

4.1.3.5 Summary Processing

The last area for computer assistance consists of computer programs which would aggregate, summarize, and format for printing the

three classes of output generated by the battle simulation. The programs would accept as input data the detailed simulation results accumulated on temporary disk files from the computerized event-store simulator. They would then summarize and organize the information so that

immediate and assimilable outputs could be printed. The measures of

performance of the Blue Command and Staff would require certain statistical analysis routines. The measures of combat outcome would require

a listing of the state variables as a function of simulated clock time.

The record of Red tactical decisions would simply be a printed log of

the times and new initiatives entered by the Red side.

The software development costs of these programs would be modest,

*once the basic system design and the computerized event-store simulator

have been implemented.

The benefits associated with providing immediate printed results

following an exercise on the battle simulation appear significant.

4-37

'9

ii
4.2 PROPOSED INITIAL IMPLEMENTATION

This subsection presents the key elements of the proposed initial

implementation. The preceding discussion of the basic design concept

pictured a system with six "plug-in" modules. Five of these modules

represent separately the Blue Division Command Group and its four principal staff sections; the sixth module is the Red Command. The system

provides for the play of a division-level war game in which the configuration of play, that is, the combination of populated modules and

simulated modules among the six, can be selected. The play involves not

only the simulated combat between the opposing forces but also the varying states of knowledge the opposing commanders use as the basis for

their tactical decisions. The system handles the information flow of

approximately 75 different kinds of tactical messages between the command

elements and the combat units and provides the realistic time sequencing

of approximately 350 different kinds of defined events, covering the

staff actions, staff coordination, staff output, and staff input, as

well as the simulated battle occurrences. The concept defines a general

interactive war game simulation of sufficient scope and flexibility that

can be applied alternatively to behavioral research, the development and

evaluation of new tactics, or the training of staff personnel.

The proposed implementation of this design is predicted on a

system that can be directed and operated by one, or a most, two human

controllers. As stated in the earlier discussion, the specification of

controller functions must be made in the framework of the actual procedures used in the play of the populated modules and the specific kinds

of computer assistance the controllers are provided with. That specification is given below.

The proposed implementation will impose a constraint on the number of populated modules played in one exercise. The basic design stipulated that any combination of the "plug-in" modules could be selected

(see Table 4-1). This means that the number of populated modules can

vary from zero up to six. Since each populated module implies certain

minimum computer hardware/software requirements as well as a proportionate work load imposed on the controllers, the system will therefore be

limited to no more than two live staff modules in the initial proposed

implementation. The selected modules may be any two out of six, but in

no case may the total exceed two. This constraint limits the configurations of play to 22 out of the 64 alternative choices shown in Table 4-1.

The proposed implementation will be further constrained at this

time to the exercise of Blue staff modules operating under a manual staff

system only. It was shown in the preceding subsection that an interactive simulation of a division staff in a TOS environment required not

only expanded logical rules covering the decision-making aids provided

by the field computer but also interactive terminals for the players in

populated modules. The latter hardware requirement, furthermore, had

4-38
to be a reasonable match with the actual field terminals with respect to

the keyboard procedures, the data entry language, and display formats.

It is proposed, therefore, that the implementation of ADP-assisted staffs

be deferred until the tactical data management functions and the staff

procedures are better defined.

The key elements of the initial implementation are now described

in the framework of these specific constraints. The description begins

with the proposed physical layout of a system involving one or two populated modules and run by one or two controllers. Under this proposed

architecture, the basic procedures for playing live staff modules are

outlined. The description then continues with the key element, the

specification of the controller functions. The role of the controllers

is defined both for setting up an exercise for play and for controlling

the exercise after the simulated clock starts running. The discussion

is concluded with description of the computer programs that will constitute the preprocessing system, and of the interactive executive control

routine that will provide the basis for the controller's functions during the play.

4.2.1 Physical Layout for Two Populated Modules

The proposed physical layout for the integrated battle simulation

is shown in Figure 4-5. The figure gives the basic floor plan for the

system if the simulation were configured for a populated Blue G2 Staff

Module and a populated Red Command Module.*

The layout requires that the controller(s) and the populated

player modules (as well as the computer main frame) occupy separate

rooms during the play. The transactions and communications between the

controller(s) and the player modules will be confined to exchanges of

hand written or printed tactical information messages or documents passed

through the Dutch door access windows. Oral exchanges will be permitted

only if initiated by the controller(s) during a period when the simulated

clock is not running. The display materials in the controller's room:

the controller's situation map, the printed message log, and the cathode

ray tube (CRT) screens should be shielded from the players so that the

players cannot "cheat" by getting access to the real world data.

The basic method of play will be as follows: The staff personnel will execute the appropriate staff actions, where required, and initiate staff outputs (Class 3 events or certain Class 2 queries, respon-

* ses, or requests) by passing pencil copies or typewritten copies of the

Stactical messages through the access windows to the controller(s). The

submission of the hard copy in this manner will represent the staff

section directing its radio telephone operator (RTO) to transmit or dispatch the output. The controller(s), in turn, will effect the actual

*This corresponds to Configuration No. 36, as listed in Table 4-1.

4-39

*0,. ,
:0- 0m

LACA

M m uz :L =1 = t

uj 4cc

CAA Lai LLJ 0 LAJ 0: 0L

0. us 0

I.- 4c.t Uc.~ &n C

cak -I>

tn c 4-40

piC
transmissions by making message data entries on the controllers keyboard.

The staff personnel will receive its staff inputs (Class 4 events or

certain Class 2 responses or information copies) by means of medium

speed* teletype printers located in their separate rooms. The messages

will be printed out in the standard tactical message formats. The top

line of each communication received will contain a representation of the

receipt stamp associated with the incoming message. It will show the

data-time group of the moment the message is being printed. The receipt

of staff inputs will provide some, but not all, of the basic triggers

for the different staff actions. The staff personnel should tear off

the printed messages as they are received prior to embarking on those

actions.

It will be shown that the-controller(s) will have a continuous

display of the running simulated date-time-group at the top of their

CRT. This will provide the controller(s) with a simulated clock. The

players in the staff module rooms, on the other hand, will be required

to judge the passage of simulated time by noting the times received on

the successive input messages coming in on the teletype printers. These

times will be geared to the simulated clock in the computer. Of course,

if the exercise itself is geared to real time (i.e., the speed ratio is

set at 1.0), then the players may synchronize their own watches and wall

clocks to match the clock settings of the messages.

It should be noted that the proposed physical layout will provide

the necessary computer hardware so that the simulation may be adapted

to any of the 22 permissible configuration of play.** Although Figure

4-5 illustrates a system configured for a live Blue G2 Section and a

live Red Command, the layout could be modified simply by rearranging

the furnishing and materials in the player module rooms so that the alternative staff modules had their necessary staff equipments. The teletype printers would remain as shown except that their umbilical connectors to the computer might have to be interchanged.

4.2.2 Controller Functions

The proposed implementation focusses on a system requiring one,

or at most, two human controllers to set up and run exercises in simulated division-level combat. It will be seen that the proposed computer

assistance is oriented to the specific controller functions in ways that

will make the running of exercises entirely manageable by only one or

two qualified personnel.

The key element here is the identification of all functions to

be assigned to controllers. Preparation for an exercise will require

*300 baud.

**The permissible configurations of play are those involving at most two

populated modules. See Table 4-1.

4-41
not only one or more phases of preprocessing activities (as described in

paragraph 4.1.3.2) but also the creation of the controller's situation

map and the preparation and organization of a set of documents to be

handed out to players later during the exercise. After the simulated

clock starts running, the actual play of the exercise will require the

keyboard entry of staff outputs, keyboard intervention on certain release

events, maintenance of the real world situation map, and the passing of

the documents to the players according to the basic schedule of events.

The specification of controller functions and ways the computer

will facilitate their performance are presented below.

4.2.2.1 Preparatory Functions

Every individual exercise of the battle simulation will be rooted

to a unique set of materials consisting of the design of the experiment,

the General Situation, the separate Blue and Red Special Situations, and

the magnetic tape SCENARIO File. The documents will specify the basic

research objectives and the scenario for the exercise; the magnetic

tape will contain data and control parameter settings consistent with

these stated objectives and tactical setting. If the SCENARIO File has

been fully processed, the materials will also include computer listings

stemming from the preprocessing system. Furthermore, if the exercise

has dlready been played, the materials might also include controller

map overlays that were developed during the earlier run.

The controller functions in preparing for the exercise are oriented to this collection of materials. Starting with a complete or partial

set, the controller(s) must perform the following preparatory functions:

0 Generation of the completed form of the SCENARIO File

and-the accompanying computer listings.

0 Validation that the stated objectives and the tactical

situation are reflected in the computer listings.

0 Creation of the real world situation map based on the

computer listings.

* Organization of those tactical documents to be used in

the play into chronological files by staff section.

It should be noted that the first function involves the running of the

computer preprocessing system and that the remaining functions are

wholly dependent on the computer listings stemming from the system.

Although the preparatory. functions will not require direct interactions

with the computer, controller(s) should be familiar with the basic data

card formats and card punch procedures used in the preprocessing system

and should be able to assimilate quickly the printed information on the

listings.

4-42
The basic structure of the proposed preprocessing system is that

described in paragraph 4.1.3.2. This structure provides, through its

technique of progressively building the SCENARIO File, a flexible means

for executing the first preparatory function. The separate printed

listings coming from the Phase I, Phase II, and Phase III Preprocessing

Programs will cover, respectively, the Red and Blue force tables, the

initial states of knowledge held by the two sides, and the exogenous

events and parameter settings for the exercise. These listings, and

the intermediate magnetic tape files, together will provide a basis for

generating new or modified experiment/scenario combinations quickly,

usually without requiring a complete repetition of the entire synthesis

process.

It should be recognized, however, that the logical detail exhibited by the force tables, the state of knowledge tables, and the parameter settings will be complex in aggregate and will require that the

controller(s) possess a reasonable understanding of the overall model

operation.

4.2,2.2 Control Functions

After the stage has been set for an exercise, controller(s) will

run the game using the basic facilities in the controller's room, as

illustrated in Figure 4-5. He (they) will be required to carry out the

following specific control functions, guided by the displays on the CRT

and the printed material on the computer message log:

0 Starting and stopping the simulated clock.

* Keyboard data entry of staff outputs submitted by staff

players.

0 Maintenance of the controller's situation map, as the

simulated combat progresses.

* Keyboard data entry and execution of certain release

events. Release events will be explained further below.

* Logging in/out tactical documents transmitted/received

by the player modules, but not involved directly in the

simulated battle.

These functions are all tied to the proposed interactive executive control routine in which the computer will control the time sequencing of

battle events as well as govern the flow of tactical information to and

from the populated staff modules.

The controller(s) will initiate the routine (but not the simulated clock) by means of a simple keyboard call. This call will evoke

a basic control screen display on the CRT and print header lines on the

controller's message log as well as on the teletype printers in the

p 4-43

I - -
player module rooms. The control screen display, which will be the point

of departure for, and the general basis of, the controller(s) functions

during the play, is shown in Figure 4-6.

A more detailed discussion of the specific control functions is

given below. At this point, however, a few explanatory remarks are injected about the controller's basic display shown in the figure. It

should be said first that the basic display is just one out of many

different formatted screens the controllers will see during the course

of play. It will be shown that while executing their control functions,

the controller(s) will cause the CRT to switch back and forth between a

number of different displays depending on the specific functions they

are addressing. All screens, however, will contain the same three top

lines as those shown- in the figure. These lines will display continuously the following basic items of information about the exercise:

0 The name of the scenario exercise.

0 The current data-time-group (DTG) in the simulation.

* The selected configuration of play.

0 The simulated clock status indicator.

0 The speed ratio setting in the simulation.

The computer will initialize the items from data in the SCENARIO File.

After the simulated clock is set running, the clock status indicator

will change and the DTG will tick off the minutes of simulated time.

Starting/Stopping the Simulation. The controller(s) will execute control of the simulated clock by means of control options (1) and

(5) on the controller's basic display. Whenever the clock status indicator states that the clock is not running, the man at the terminal

keyboard may start the clock by keying the digit "l" followed by a space

and then either the word "END" or else the clock reading he desired for

the next stop. Similarly, when the clock is running, the controller

may stop it simply by keying the digit "5", notwithstanding the previously

entered stopping time.

Whenever the simulated clock is inert, the controller(s) may

also modify the simulation speed ratio or even the configuration of

play by invoking control option (6).

The whole system may be shut down by control option (7).

Keyboard Entry of Staff Outputs. The architecture of the proposed implementation is based in part on the idea that staff outputs -

including the initiation of coordination exchanges with other elements

- are "transmitted" by the players' passing hardcopy messages through

the access windows to the controller(s). The controller(s), in turn,

4-44
VC2

LLLU - 0

LU

cL *u

F-S.

uj LU

4L -j ~ --

-l C)4 C) 0)

CM) LU

: - ' C:)L 

LU LUJ O

L')C' L I

C LU LI) C LA l I

L) CD :c

F- -j U- V) i.- C) LU 

LLLU - ) C)

CL 0 L I- ) LUJ =

F- LAI

0j --- - L.

L) L/ - CL 2f LULU0

C) C) ><

F- V),j V

4-45
must bring about the transmissions by making keyboard data entries on

their terminal. The key-in procedures for these orders, queries, responses, and tactical reports will be of two kinds, depending on whether

the message contains basic decision variables affecting the simulated

battle or is merely a tactical document to be issued by the populated

staff module, but not otherwise involved in the combat simulation. In

the first procedure, the controller(s) must key in the whole message

through the use of a lexicon of special abbreviations and symbols that

will be provided. In the latter case, the controller(s) must simply log

in the document by keying in a short combination of letters and digits

that post the log entry.

The controller(s) may initiate the tactical message data entry

function by invoking control option (2) on the basic screen. The terminal operator may select this option whether the simulated clock is

running or not. He must key in the digit "2" followed by a space and

then a three-digit designator which specifies the type message he wishes

to enter. The keyboard selection will cause the control screen to disappear and be replaced by a different screen format. The new display

will provide the basis for the controller to key in the message. When

the message has been fully entered, its transmission will then be triggered by a special key, following which the message format screen will

disappear and the controllers basic display will return.

Maintenance of the Controller's Situation Map. The real world

situation map, along with the controller's message log, will be the

principal means for observing the unfolding battle outcomes resulting

from the opposing commander's decisions. Controller(s) will maintain

this situation map during the play.

As will be shown in the discussion on release events, the controller(s) will not only update the map from information presented to

them by the computer but also use the map to assist them in feeding

subsequent intervention data back into the computer. Practiced controllers will probably develop their own shortcut techniques for this

purpose, using perhaps grease pencil entries for certain kinds of intermediate battle events and multiple map overlays for different periods

of simulated combat.

Controller Intervention. In the play of an exercise, the tactical decisions imposed by the controller in order to influence the basic

research objectives, the battle events in which the controller must intervene with military judgement, and the arrivals of certain tactical

documents from higher headquarters to the populated staff sections are

all called release events. A release event is any event in the simulation whose execution depends on controller intervention. The intervention, furthermore, should be completed on or before the time of the

event, as measured by the simulated clock. Release events will be

generated and scheduled for occurrence in the event-store simulator

,.4-46 " 

L

iU
about five to twenty minutes (in simulated time) before they actually

occur. The controller(s), having been warned of the forthcoming release,

must effect their intervention during this short interval.

Controller(s) will handle release events by means of control

options (3) and (4) in the basic display. At the time a release event

is first generated, the screen will post a warning to the controller(s)

by incrementing the "release queue number," which is the number exhibited

in parentheses in the middle of the text in control option (3). If the

release queue number is zero (as illustrated), the controller(s) will be

apprised that no release events will be currently forthcoming; if the

queue is 1 or more, they will be alerted to the fact that one or more

interventions will be required within the next few minutes of simulated

combat.

If the terminal operator selects control option (3) by keying

in the digit "3," the basic control screen will disappear and a new display will present the list of forthcoming release events. The list will

be arranged so that earliest forthcoming event appears at the top. The

entries in the list will not only indicate the time of occurrence but

also identify the type of intervention required. After the controller(s)

have reviewed the queue, the operator may then erase the display and

return to the controller's basic screen by pressing a single key.

If a controller selects control option (4), the computer will

automatically institute the associated display format required to effect

the intervention of the first (earliest) release event. The new screens

will involve either simple keyboard instructions or complicated data

entry procedures, depending on the type of intervention being addressed.

After the controller(s) have executed the instructions or procedures,

the spetial screens will disappear and the basic display will return

to the CRT.

Release events associated with the arrival of tactical documents

from corps headquarters or from adjacent divisions will involve only

simple mechanical tasks on the part of the controller(s). At the time

indicated for the event occurrence, the controller(s) must pass the

documents through access windows to players in the staff module rooms.

These actions are essentially the reverse of the procedures cited above

for the keyboard entry of staff outputs.

Release events for imposing tactical decisions or supplementing

the battle event logic, on the other hand, will require evaluation of

the situation at hand and keeping in mind the basic objectives of the

exercise. They will also entail keyboard data entry of more elaborate

scope than that implied above. These types of release events are developed further in paragraph 4.3.6.

4-47

p"
Logging of Tactical Documents. The last control function assigned to the controller(s) has been shown to be subsumed in the procedures

for keyboard entry of staff outputs and the controller intervention pertaining to tactical document arrivals.

4.2.3 What the Computer Will Do

The final key element of the initial implementaion is the computer assistance proposed to facilitate setting up and running the battle

simulation. The physical layout and specification of the controller functions set forth in the preceding paragraphs make reference to, and are

based on, specific computer hardware components and a fundamental computer program structure for the software. The proposed computer programs

consist of the three routines of the preprocessing system and a single

interactive executive control routine (IECR).

The preprocessing system has already been described. The manner

in which the three preprocessors will provide for the organization of

simulation data was presented in paragraph 4.1.3.2, and the ways the

controller(s) will be assisted by the system were shown in paragraph

4.2.2.1. The required elements for programming the system are not pursued further at this point but will be developed later in the next subsection.

The IECR, on the other hand, will be the basis for running the

event-store simulator with a controllable simulated clock such that the

controller(s) may execute their control functions without destroying

the dynamic realism of the model. The IECR represents the second of the

two approaches outlined in paragraph 4.1.3.3. It will provide for the

simultaneous time sequencing of the combat events, the staff input/output

events, and the keyboard data entry implicit in the controller's intervention; it will contain a software mechanism called an asynchronous

trap which will accommodate this simultaneous dynamic portrayal of the

on-going battle and injection of orders, queries, and controller's

release events.

In pursuit of Subtask 1.6 of the basic top-down design, SAI using

a part of its uncompensated efforts, has programmed and tested a skeletal

interactive control system operable on a PDP-11 computer.* This routine

has demonstrated successfully not only the operation of the asynchronous

trap but also the automatic switching required for playing alternative

configuration numbers. As a first stage test program the system merely

emulates the event-store mechanism through a simple four-event scenario,

*SAI's computer routine is called Tactical Information Exchange in a

Division-Level Exercise (TIEDE). The program is evoked by the keyboard

instruction "CALL TIEDE." Explanatory footnote by 2nd and 3rd authors

without the permission of the 1st author.

4-48
but it has shown that the simulation can be geared to any reasonable

speed ratio, giving slow time, real time, or fast time play as desired.

The interactive aspects of the proposed IECR were described in

some detail in the preceding paragraph. A broader perspective on the

war game simulation as a whole is now presented by showing, first, how

the IECR will provide staff element players with their staff inputs

during an exercise, and second, how it will generate at the same time

the battle event entries on the controller's message log. The perspective is based on a hypothetical scenario in which V (US) Corps is attacked

by Warsaw Pact forces as part of a general Pact attack in Central Europe.

The division level exercise is assumed to be configured for a populated

Blue G2 Staff Module and to begin at 0430 hours on I August 1982.

4.2.3.1 Staff Inputs Received on the Teletype Printer

During the first twenty minutes of simulated time, the Intelligence Staff players will receive the staff inputs shown in Figure 4-7.

The figure illustrates four basic entries printed on teletype paper.

The first entry is simply the one-line notification to the players that

the simulated clock in the exercise has begun running. The remaining

entries are individual input tactical information messages that will spur

the staff players to initiate the appropriate actions. The messages

will be printed at different moments in simulated time, so that the

players will "receive" the messages at 0437, 0438, and 0448 hours, respectively, as shown by the top line receipt stamp representations.

The messages are spaced on the paper so that each successive trigger

may be torn off to be used as the basis for the staff action associated

with it.

The three messages shown illustrate three of the many different

types of formats to be used in the IECR.

The first input is a copy of the combat intelligence report filed

by elements of the covering force after initial contact. This type

message (Event No. 444) is a tactical information document which is prepared beforehand as typewritten copy and passed to the players as the

result of a release event execution by the controller(s). Although the

G2 staff must initiate the appropriate action, the contents of the report have no direct bearing on the simulated combat events.

The second input is an information copy of an air defense warning order issued by the (simulated) G3. The message type (Event No.

255) is a Class 2 event stemming from actions by the operations staff.

Receipt of this message reflects the standard procedures that all staff

elements are sent information copies of fragmentary orders or warning

orders issued by the cognizant sections.

4-49
INPUT MESSAGES TO BLUE G? STAFF SECTION

s10430 AUG 1932 SIMULATED CLOCK BEGINS RUNNING.

S010436 AUG 1982 RECEIVED BY BLUE G2 STAFF SECTION.

1010421 AUG 1982 U N C L A S S I F I E D (444)

FROM: 53RD ACR

TO: CG, V CORPS

INFO: 23RD DIV. 62ND DIV, 37TH DIV

TYPE REPORT: COMBAT INTELLIGENCE REPORT

(PICK UP DOCUMENT AT THE WINDOW)

9.

S010438 AUG 1982 RECEIVED BY BLUE G2 STAFF SECTION.

F010437 AUG 1982 UN C L'A S S I F I E D (255)

FROM: CG, 62ND DIV/G3

TO: 2ND BDE

INFO:

TYPE REPORT: AIR DEFENSE WARNING

1. WARNING: RED

2. DIR ATTK: NE

3. SIZE ATTK: FEW

4. PRED TGT: 20W 8DE

5010448 AUG 1982 RECEIVED BY BLUE G2 STAFF SECTIvd.

1010443 AUG 1982 -N C L A S S I F I E D (444)

FROM: ASAC

TO: CG, 62ND DIV/G2

INFO:

TYPE REPORT: COMBAT INTELLIGENCE REPORT

1. TIME: 010350 AUG 1982

2. LOCATION: NA78329640

3. DIR MVMT: WSW

4. RATE MVMT: 5 KPH

5. UNIT SIZE: COMPANY'

6. UNIT TYPE: INF

7. QTY TANKS: NA

8. QTY APCS: NA

9. ARTY TUBES: NA

10. UNK VEHS: NA

11. QTY TROOPS: 125

Figure 4-7. Staff Inputs Received on the Teletype Printer.

4-50
The last input shown for the G2 element is another combat intelligence report, this one coming from the division all-source analysis

center. An enemy LRRP has been discovered as the result of a fire fight

in the 3rd Brigade area. This message (Event No. 444) has been generated

as the result of a whole sequence of battle events that has occurred in

the BOG.

It should be noted that after twenty minutes of play the sum

total of the information on the enemy order of battle and dispositions

held by G2 element will be reflected in the EOB chart, the ENSIT map,

and the various element files as these things have been modified by the

content of the three input messages.

4.2.3.2 Controller's Message Log

During the same twenty minute period of simulated time, the highspeed printer in the controller's room will be listing the entries of

the message log, as illustrated in Figure 4-8. The listing shows ten

significant events about the unfolding simulated combat. The IECR will

have processed the occurrence of as many as 100 to 200 events during

the simulated period, but the message log will exhibit only those events

that are relevant to, and necessary for, the control of the exercise or

the analysis of the results afterwards. A brief description of these

relevant entries follows.

The first entry is simply the one-line notification that the

simulated clock has started running.

The second entry, which will be printed after two minutes of

simulated time, records the receipt of a staff input by a section that

is simulated.

The third entry, printed at 0436 hours, records the receipt by

the live G2 players of the copy of the combat intelligence report from

the covering force to corps. This entry represents a release event

that has already been executed by the controller(s), as described in

the preceding paragraphs. At the time the entry is printed, the controller(s) will transfer the typewritten document from their files to

the players.

The fourth entry, printed after seven minutes of play, is the

first significant evidence to the controller(s) of the progress of the

Warsaw Pact attack. The entry provides a basis for the controller(s)

to address their situation map in anticipati.on of the imminent engagement between Blue and Red forces.

The fifth entry will be printed at the same time as the fourth.

This entry apprises the controller(s) that a simulated staff element has

initiated an action pertinent to the developing conflict.

4-51

-.
CONTROLLERS MESSAGE LOG

S010430 AUG 1982 SIMULATED CLOCK BEGINS RUNNING.

S010432 AUG 1982 BLUE G3 SECTION RECEIVED AIR DEFENSE ALERT (464)

S010436 AUG 1982 RECEIVEn BY BLUE G2 STAFF SECTION.

F010421 AUG 1982 U N C L A S S I F I E 0 (444)

FROM: 53RD ACR

TO: CG, V CORPS

INFO: 23RD DIV. 62ND DIV, 37TH DIV

TYPE REPORT: COMBAT INTELLIGENCE REPORT

(RELEASE DOCUMENT TO PLAYERS)

S010437 AUG 1982 RED AIRMOBILE ELEMS 623 MRR LAND VIC NA69409930.

S010437 AUG 1982 BLUE G3 SECTION ISSUES AD WRNG ORDER 001 (355)

S010439 AUG 1982 RED AIRMOB!LE ELEMS 623 MRR LAND VIC NA69429925

S010445 AUG 1982 ENGAGEMENT PHASE 0; BATTLE ARRAY 0001.

S010448 AUG 1982 RECEIVED BY BLUE G2 STAFF SECTION.

1010443 AUG 1982 U N C L A S S I F I E D (444)

FROM: ASAC

TO: CG, 62ND DIV/G2

INFO:

TYPE REPORT: COMBAT INTELLIGENCE REPORT

1. TIME: 010350

?. LOCATION: NA78329640

3. DIR MVMT: WSW

4. RATE MVMT: 5 KPH

5. UNIT SIZE: COMPANY

6. UNIT TYPE: INF

7. QTY TANKS: NA

8. QTY APCS: NA

9. ARTY TUBES: NA

10. UNK VEHS: NA

11. QTY TROOPS: 125

S010449 AUG 1982 RED ELEMS 627 TKR CROSS PHASE LINE VIC NB601O0100

5010450 AUG 1982 RED AIRMOBILE ELEMS 623 MRR LAND VIC NA6700q900

Figure 4-8. Events on the Controller's Message Log.

4-52 p.

Li0.
The sixth entry, printed two simulated minutes later, shows that

the Red side is beginning to concentrate its airmobile elements.

The seventh entry denotes the first contact between the opposing

forces. The controller(s) will be able to see on their situation map

that the engagement involves the Red airlanded units and the Blue elements of the 2nd Bde. But concomitant with the event printing, the IECR

will post a warning to the controller(s) on the CRT of the forthcoming

release event representing the outcome of the first phase of this engagement. Before the next event associated with the engagement is printed,

the controller(s) will have acted on the posted warning and executed the

release through their terminal.

The eighth entry records the receipt of the combat intelligence

report by the live G2 players. The entry is an exact duplicate of the

staff input printed on the teletype in the player's room. It is part

of the basic record of the tactical information flow to the players by

which the staff performance may be analyzed after the end of the exercise.

The ninth and tenth entries alert the controller(s) of further

developments in the unfolding simulated combat. Nineteen minutes after

the start of the play, elements of the Red tank regiment cross a phase

line and signal to the controller(s) the imminence of a second engagement in the division sector. The last entry in the twenty minute simulated period shows that the Red side is continuing to concentrate its

forces in the area of the first point of contact.

4.2.3.3 Integrated Simulation

The fundamental characteristics of the interactive executive

control routine, i.e., the features that make it the final key element

of the proposed implementation, can be seen by comparing the "state of

the battle" information held by one side (in this case the Blue G2 Staff

Section; Figure 4-7) with the real world state seen by controller(s)/

investigators (Figure 4-8). After twenty minutes of simulated combat,

the G2 players, because of the C3 and reporting delays, are as yet completely unaware of the battle events unfolding in the 2nd Brigade area

and the imminence of more fighting on the left flank. They have been

informed about an enemy LRRP discovered in the 3rd Brigade area, but

remain largely "in the dark" about the rapidly developing situation.

The realistic portrayal of the combat events and the basic control of

the flow of the tactical information to the staff players are the central features of the IECR which will facilitate the running of the simulation exercises.

4.3. BASIC COMPONENTS OF THE FIRST IMPLEMENTATION

This subsection now presents the general approach SAI proposes

to use in implementing the top-down design. The key elements and basic

structure described in the preceding subsection can be implemented most

p 4-53
effectively by using a coordinated approach in which the required software and structured data bases are all developed concurrently. The

following specific tasks are required:

* Concurrent programming, testing, and validation of the

preprocessing system, the interactive executive control

routine, and the magnetic tape SCENARIO File that links

the routines together.

0 Development of the computer-stored tactical message formats and other hard wired data.

0 Structuring of the Real World Data Base for the first

scenario.

* Development of the algorithms for initializing the Perceived Data Bases and for the degradatiun of tactical

message content during the play.

* Development of the random-access Event Table File and

the accompanying event loading routine.

0 Development of the controller release event data entry

procedures and display screens.

These basic components of the integrated simulation are discussed further here in the framework of the specific computer hardware requirements.

It should be borne in mind that the organization of the material

which follows does not imply any particular order of importance to the

various components nor suggest any task sequence in the implementation

effort. The required elements will be developed and fitted together all

at the same time in an integrated system development program. An implementation plan is presented in paragraph 6.6.

4.3.1 Concurrent Development of all Computer Programs

The computer software will be the principal focus of the proposed

coordinated approach. SAI will embark on the development and programming of all computer programs simultaneously by employing the top-down

programming technique of creating "skeletal" computer program framew.;,s

for each of the four routines cited as the key elements of the system.

A skeletal program is a routine containing sufficient computer instructions to demonstrate the overall logical structure of the desired function but without the subroutines necessary for the more subtle logical

details. The technique has been successfully applied in the test program described on page 4-48 as well as in other SAI system development

efforts. The four basic programs are the three routines comprising the

preprocessing system and the interactive executive control routine (IECR).

The skeletal framework that will emerge in the early stages of the integrated approach will be a system capable of creating by successive phases

the fundamental SCENARIO File and then using this file to activate the

IECR.

4-54

%Ar-_
The system flow of the preprocessing system was illustrated in

Figure 4-4.

The system flow of the IECR is shown in Figure 4-9. The operation of this program is conceived to consist of three procedural segments.

In the first segment, the input magnetic tape SCENARIO File will be read

in, and the simulation data on the tape will be reformatted into directaccess disk files, as shown in the figure. The second segment will be

the basic event-store simulator with its asynchronous interactive control. The operation of this segment was described in paragraphs 4.2.2

and 4.2.3. The third segment will be essentially the reverse process of

the first segment. In response to controller commands or to certain

simulated time clock readings, this segment will take the existing data

in the direct-access files and create a new, modified form of the SCENARIO File.

Beginning with these skeletal programs, the coordinated approach

can best be described as the process of puttinq the flesh on the bones

of the skeleton. As the system development proceeds, it will entail

numerous reformulations of the program structures, many separate recompilations, and a large number of validation test runs. The preprocessing programs appear to present only straight-forward programming tasks

except for the basic organization of their end product, the SCENARIO

File. Whenever the IECR design dictates a change in the format and/or

content of its input SCENARIO File, the preprocessing system will have

to be revamped to reflect these new formulations.

The IECR, unlike the preprocessors, combines for the first time

a number of sophisticated techniques in a logical framework tied to the

computer clock. The data space required for this program has been estimated to be 316 kilobytes (see paragraph 4.1.3.1). Furthermore, the

instruction space is estimated to be 1500 kilobytes. These estimates

dictate that the simulation data must be organized into direct access

disk files external to core and that the instructions must be handled

by means of a large number of program overlay segments. The asynchronous

trap that provides for the simultaneous battle event sequencing and injection of orders, queries, and controller release executions under the

timing of the adjustable simulated clock will be part of the root segment for the overlays.

SAI proposes to use its test program (see page 4-48) as the

starting framework for the IECR. This routine has already successfully

demonstrated the operation of the asynchonous interactive control coupled

with event sequence timing based on the computer clock.

The development of the programs will be based on the following

specific computer hardware/software requirements:

, PDP-11 computer with a CPU with sufficient memory management capabilities to provide 64 kilobytes for task areas.

* . 4-55

Ut
-7 

4-

4-)

13 S..

4-)

a)

94-

s--

4 ) 0 S1)

LL c = : 4-

I<- -r-o 0- 0

~LLJ W-~ a) a a

_ OC - S o4 Guil 4-3 L c 

> 

L 

ii"' C-Ca 4-)4-

Lu S.- S- 4-' u~ - 0 cu O

5-4-)

C - 0 *

- so -

0.0

Ln

4-56
* Standard peripherals, including high speed printer,

magnetic tape unit(s), card reader, and disk storage.

This system will require its own disk pack (100 megabytes) as well as a small number of magnetic tapes.

* Three teletype printers.

* One CRT/keyboard terminal, possessing "escape sequence"

controls for locking and unlocking the keyboard, remote

locating and repositioning of the cursor, and clearing

the screen.

0 The RSX-11M V03 Operating System with its standard

utilities.

0 The FORTRAN-IV-PLUS compilers and supporting library.

This compiler requires a floating point arithmetic

hardware unit in the CPU.

All programs, and subroutines except the I/O control and asynchronous

trap routines will be written in FORTRAN-IV-PLUS language.

4.3.2 Tactical Message Formats and Other Hard Wired Data

It was stated previously in this section that the hard wired

data used in the simulation would be stored together in one major repository in the computer. The repository would contain the repertoire

of tactical message formats, the dictionaries of permissible words or

phrases to be used with the formats, the rate of advance and withdrawal

tables, etc. and would require approximately 100 kilobytes of data space.

In the light of the basic design choices made for the implementation these preliminary determinations did not take into account the

CRT screen formats required for interactive control nor the program

overlay structure to be used with the IECR. The screen formats, which

will be collected together within the major repository, may increase

the data space requirement. The individual tactical message formats,

on the other hand, will not be stored together but instead will reside

as hard wired program data in the separate overlay segments.

The tactical message formats to be used in the simulation are

given in Design Note D.

The lists or dictionaries of permissible words or phrases to be

used in the tactical messages will be composed and will be stored as

program data in one or more files external to core.

The tables of combat frontages, troop movement rates, rates of

advance for successful attackers, etc. to be used in executing battle

events will also be composed and stored in external files.

4-57
4.o

A special file will also be created to contain the various screen

formats required to provide the controller/operator with instructions for

data entry.

These data will be fixed or invariant and as internally stored

information will not ordinarily be readily visible to users or players

of the simulated war game. SAI will make every attempt to render the

black box magic as visible as possible by providing printed lists and

parameter tables as part of the basic documentation for the model.

4.3.3 First Scenario

In the integrated approach, SAI proposes to have the first scenario that is developed to exercise the model serve also as the test data

vehicle for the structuring of the Real World Data Base and the composition of the list of exogenous events. Although the basic design will

eventually permit the synthesis and play of any experiment/scenario

combination within the sizing parameter limitation, the computer programs will be developed around this test scenario.

SA[ proposed that this first scenario reflect a European setting

similar to TRADOC's "Standard Scenario for Combat Developments (U)"

(SCORES) with translation sufficient to make the scenario unclassified

as structured and played. In general terms, the scenario will describe

a non-nuclear attack by Warsaw Pact forces ("RED") against the US V Corps

("BLUE") in the Fulda area of West Germany. Blue covering forces are

deployed and make first contact with leading Red elements forward of the

defensive positions of the simulated Blue division. Initial reports and

actions are those found in the sample message log and material presented

in paragraph 4.2.3. The scenario continues to completion with conventional action as the Blue division becomes engaged and fights its battle.

The Real World Data Base for the model will be structured around

the composition of the Blue and Red forces in this scenario. This means

that the input data card formats, the SCENARIO File records, and directaccess files of the IECR will tie together the basic force tables reflecting the Fulda Gap-V Corps division-level combat.

The list of exogenous events associated with the scenario will

likewise provide the basis for the test input data in the Phase III

Preprocessor.

4.3.4 The Perceived Data Base

In the structuring of the perceived data bases for the computer,

SAI proposes to take advantage of the relationship between the FRENSIT

and ENSIT tables in the tabular arrays and the force tables of the Real

World Data Base. Since the unit-by-unit state of knowledge data in the

FRENSIT and ENSIT tables match the unit-by-unit real world status variables, the tabular arrays and the force tables will be combined into a

4-58
single direct-access disk file keyed by a unit index. The structure of

this file is illustrated in Figure 4-10.

The file will consist of 300 records of approximately 300 bytes

or characters each. The records will be keyed by a unit index varying

between 1 and 300. Unit indices 1 to 150 will cover the company-sized

units of the Blue force; the indices 151 to 300 the Red force. Each

record will contain approximately 200 bytes of real world status information plus 50 bytes each for the FRENSIT data and ENSIT data associated

with the unit. In the sample entries shown in the figure, record 53

will contain the status, location, etc. of the 53rd Blue unit as well

as the Blue and Red perceptions of the same unit. Similarly, record 195

will contain the corresponding groups of information for the 45th Red

unit in the war game. The tabular array of data heretofore identified

as the Blue Perceived Data Base in now more fully defined as the FRENSIT

information over the first 150 records and the ENSIT data in the last

150 records. It is shown by the shaded boxes. The Red Perceived Data

Base is simply the remaining unshaded portion on the right.

It can be seen by comparing the relative sizes of the redl world

status variables and the FRENSIT or ENSIT data that the state of knowledge material is stored by the use of special coded variables and is

not simply a biased or degraded version of the same data on the left.

The special variables will consist of state-of-knowledge indices and

reporting time parameters. A state-of-knowledge (SOK) index will be a

one-digit integer whose value will be a quantitative measure of the

current state of knowledge about an item of friendly or enemy force information. The reporting time parameters will be simply the recorded

date-time-groups when the state-of-knowledge indices were last updated

by means of reporting events or intelligence processing events. The

special codes will provide the basis for a compressed data storage format as well as for the algorithms which will govern the biasing or degrading of the tactical information held by the two sides.

The algorithms or routines controlling the SOKs will be rooted

to a set of internal tables relating the sOK values to the amount or

interpretation of the error by which the perceived facts depart from

the real facts. There will be a separate table for each identified item

of friendly or enemy force information. For example, there will be a

location SOK table showing the range of probable location errors ascribed

to each of the ten values of the location SOK index. By reference to

these tables, the routines will be able to generate or change aspects

of the state of knowledge held by the Blue or Red sides.

A special routine of this type will be required in the Phase II

Preprocessor Program because the basic preprocessing function of the

program is the initialization of the SOK indices to reflect the state

of knowledge held by the two sides at the beginning of the simulated

conflict. One feature of this routine will be the use of standardized

4-59

AI
4-'

'aw

a u 0

IVa"

CLa)4-

L'a

(D 0

L..

C.D

-1 4-)

L)m

-SC'CU

0 *1

C..m CD

0 -iF

V)

ca

4-' C ) 4-) 'ai en .* N M . . . 0 . S .. .. 

44.

4-'

4--6
or "default" values for the various categories of the SOK indices. Thus,

if the user/controller wishes to set up an exercise reflecting the standard levels of knowledge held by the two sides, he would not be required

to feed input data cards into the-program. Alternatively, if for the

purposes of a special experiment he wished to slant or bias the states

of knowledge, he would have to have input data cards prepared which

would modify the standard SOK values as desired.

The logical structure of all SOK routines and the internal SOK

tables will end up, like the tactical message formats and battle event

tables, as hard wired elements not readily visible to the users or players of the game. Here again, SAI will describe these otherwise hidden

subtleties of the simulation through the system documentation.

4.3.5 Event-Store Simulator

The direct-access Event Table File shown in Figure 4-9 will provide the continuously changing schedule of events on which the battle

simulation will be based. After the file has been created and loaded in

the first procedural segment of the IECR, the program, during the running

segment, will access and update the file in two separate places in the

basic control loop. The first access and update processes will occur

preparatory to the execution of the occurrence of an event. The second

will occur whenever a newly-generated event must be scheduled for future

occurrence by loading it into the file and then rearranging the time

sequence among all the event records to preserve the correct order of

occurrence.

The first process involves accessing and updating just two records

in the file, while the second will entail numerous random-access reads.

The second process will be embodied in a key subroutine called the event

loading routine. The development of this subroutine will necessarily

depart from the conventional logical structure of event loaders and will

be oriented to an external direct-access file instead of an internally

stored event list.

1.3.6 Release Events

Controller intervention by means of release events is one of the

key features of the model. Although some types of release events are

simply a convenient means for handling certain kinds of staff inputs to

populated modules, the basic reasoning behind most release events is as

follows:

0 Release events provide a means for the investigator/

controller to influence the play in order to direct the

exercise toward the research objectives.

0 Release events provide a means for a human being to

provide certain processes such as terrain analysis,

4-61
identification of routes of advance, etc. which would

otherwise call for much larger computer data requirements.

0 Release events provide a means for the controller(s) to

invoke military judgement in certain parts of the simulated battle.

The implementation of release events will begin by identifying

all those occurrences among the Class 1 and Class 5 events where controller intervention is required. Provision must then be made that the

progenitors of these events trigger the pending action warning to the

terminal operator, as described in paragraph 4.2.2.2. Each identified

release event must then be provided with its own formatted screen and

edit/update routine through which the terminal operator will enter the

requisite data for release.

In the development of the separate edit/update routines and

screens, the trade-off between the human engineering requirements for

simple keyboard procedures and the tight instruction space limitations

in the computer will be addressed. The different screen formats will

be collected together in a file external to core, but the individual

routines will have their own edit tests and input format rules.

4.4 FUTURE EXTENSIONS

This subsection addresses the question of how amenable the proposed system will be to specific future extensions. The preceding discussion has identified three basic areas where the proposed implementation will fall short of the full scope of the design concept and whose

future incorporation in the model might be considered. The areas are

as follows:

0 ADP-assisted staff operations.

0 Postprocessing computer programs providing (1) statistical

summary analysis of the action-handling effectiveness of

live and/or simulated staff sections and (2) event trace

analysis identifying the sequence of events which led to

specific staff actions during the exercise.

* The play of any configuration of populated and simulated

modules, including that of up to 5 live Blue Staff Modules

versus the live Red Command Module.

For each of these areas, the flexibility of the current design structure

is examined to give a perspective on the amount of effort required to

extend the model. The discussions follow below. In the examination of

these areas, or while considering other possible directions for model

extensions, however, the reader is cautioned that in computer simulations of this kind there always exists a point where the most cost/

effective approach to further extensions is simply a new basic design

concept.

-. 4-62
4.4.1 ADP-Assisted Staff Operations

The extension of the model to cover the simulation of ADP-assisted

staff operations will involve computer hardware additions, software changes

in the existing computer programs, additional programming, and the development of new staff action procedures (SOPs) to be followed by the live

staff modules. The following specific items will be required:

* Two ADP-assistance terminals which duplicate, or match,

the terminals to be used in the field with respect to

the keyboard procedures, the display characters, and the

attendant signal lights and switches.

* The definition of the Class 6 events and the specification of the alternative tactical information displays

that will be associated with the events.

0 Modification of the IECR so that the software accommodates

asynchronous interactive data entry from three different

CRT/keyboard terminals.

* Modification of the hard wired event thread sequences so

that a large fraction of the staff input/output now goes

through the player terminals.

* Added programming for the computerized decision-making

aids, including the employment of the "scratch pad" ata

area for the formulation of tactical decision alternatives.

The incorporation of these items will not alter the basic structure significantly, but will clearly change the way the live staff modules will

execute their staff actions. It will also alleviate some of the workload implied in the controller functions, since the controller(s) will

now be required to perform the tactical data entry function for only

the remaining fraction of the staff outputs not handled automatically

by the divisional tactical data system.

It is recommended that when this extension is undertaken, the

new version of the battle simulation be stored on a separate disk pack

independent of the manual staff version described above. This expedient

would provide the means for alternative exercises of simulated combat,

first, under manual staff procedures, and second, under ADP-assisted

staff operations. Such comparisions may serve to identify further some

of the basic features and problem areas of a field ADP system.

4.4.2 Postprocessing Computer Programs

The extension of the model to provide statistical summaries of

simulated and live staff performance and the chains of events whose

simulated occurrences triggered the staff actions will involve little

more than the design and implementation of the supplementary computer

4-63
programs performing these functions. The IECR software will require only

minimal modification to provide a suitable output processed event file

which will serve as the basis for the postprocessing.

The postprocessing functions will be oriented to the measures of

performance described in paragraphs 2.4.4 and 2.4.6, but the computer

programs will stress the statistical population of the measures over the

simulated period of time in which they occurred. Thus the postprocessor

will find the average values and indicated distributions of amounts of

time taken by the separate staff sections to complete their information

processes. The measures will be applied to both simulated and live

modules in order to provide, for comparison purposes, the statistical

norm reflected by simulated staff sections and the actual performance

by populated sections.

The postprocessor will also help identify and analyze the specific sequence of battle events that led up to periods of concentrated

staff activity on the part of populated staff modules. The behavioral

performance measures will be facilitated by the ability to distinguish

between the periods when the staff is merely pursuing routine staff

actions and those times when it becomes heavily loaded with a large

number of required actions at once.

The future development of postprocessing software depends primarily on the identification of the desired performance measures to be

handled in the new computer program. After a certain amount of experience has been attained in running the research tool, the specification

of these desired measures will be better defined. The actual programming and the modifications to the IECR will represent relatively modest

extension efforts.

4.4.3 The Play of More Than Two Populated Modules

The extension of the model so that it permits the play of 3 or

more populated staff modules will involve the reexamination of the controller's functions and the basic computer assistance he (they) are

given. The increased staff output message traffic will probably dictate

a controllers team of more than two people as well as additional hardware to cover the added volume of message data entry traffic. If the

basic architecture were expended to cover 6 player modules (5 Blue Staff

Modules and one Red Command Module), the overall computer hardware requirements for a manual staff version would be as follows:

0 Two or more controller's CRT/keyboard terminals.

0 The message log printer.

0 Six teletype printers for the player's input messages.

This requirement would have to be augmented by the six player's terminals if it also covered the ADP-assisted staff operations.

4-64
Modifications to the IECR software would be required in order to

provide the correct switching and routing of tactical message traffic

among the various devices. Unfortunately, the expanded software would

also require added provision for the coordination of separate control

functions applied at different CRT/keyboard terminals. Programmatic

coordination interlocks of this kind often compound the problems of

software development.

Except for the added computer hardware and software, the extension to accommodate any configuration number shown in Table 4-1 would

not affect the underlying simulation structure described in this section.

4.5 APPLICATIONS OF THE TOP-DOWN DESIGN

Paragraph 2.1 stated that the simulated being developed should

be a cost effective tool for behavioral science research on human performance in the division command group/staff, for combat developments

evaluation of tactics and doctrine, and for training command groups/

staff elements. The applicability of the design to the first of these,

i.e., to behavioral science research is discussed at length in Section

5 as it applied to any populated module. It is discussed again in

Section 6 as it applies to the G2 module. The remainder of this subsection discusses the applicability of the design as a tool for combat

developments, evaluation of tactics, and doctrine, and as a training

tool.

4.5.1 Combat Development Applications

A simulation of the nature described in this section clearly

has application in the general area of evaluation of tactics and doctrine. It is, basically, a simulation that is sensitive in terms of

combat outcomes to the decisions made by a commander and his staff at

division level. These combat outcomes are especially sensitive to decisions that affect:

0 The amount of combat (fire) power applied.

* The conditions under which it is applied (terrain,

posture, etc.).

0 The time and duration of its application.

Because it is an event store simulation, it is very sensitive to the

time of occurrence of battle events and therefore an eminently suitable

vehicle for studying the dynamics of division level combat. It is a

very detailed representation of the command and control processes at

division level and how these are affected by the performance of the

subsystems that comprise the division (maneuver, fire support, intelligence, EW, communications, logistics, personnel, etc.). It is also

sensitive to the interactions among these subsystems that are established

4-65
through decisions affecting organization for combat, fire support management, intelligence, communications, EW, and the other support systems as

well as their interactions with the enemy. It is, therefore, an excellent

vehicle for studying the command and control of division assets, but it

is dependent on inputs to the simulation which specify the performance

parameters of the subsystems being managed. These parameters can be

varied to alter initial performance at the beginning of the simulation

run and will be altered as the battle progresses to reflect changes that

may occur, e.g., attrition. The simulation is not useful for developing

the performance parameters of the building blocks of the model (units

and subsystems that comprise the force). It can, however, be used to

examine how the decision making process is altered as a result of changes

in performance parameters and how the changes affect the outcomes of

combat, e.g., changes in the performance of the information system that

feeds the decision making elements of the staff.

.Figure 4-11 is a representation of a dynamic combat model of the

kind described in the preceding paragraph. The entire friendly and

enemy forces are defined in terms of their personnel, materiel, and operational concepts as these determine their organization and procedures.

Together these determine the performance parameters of the subsystems

that comprise the force. Unless these simulation inputs are modified

by extraneous changes (by players) the interaction between the forces

is a stationary process, i.e., force capabilities are modified only by

interaction with the enemy and the outcome is "limiting" in the sense

that no effort has been made to optimize the outcome by altering operational concepts (tactics and doctrine). If, however, the loop is opened

periodically so that the results of combat are fed back to players who

have an opportunity to alter the operational concepts, and compare them

with old or standard concepts or to co~pare, e.g., Soviet and NATO

organization, tactics, doctrine, and C capabilities and procedures.

For this reason the connection between proposed doctrine and changes to

operational concept is a double headed arrow. Just as important in

such an investigation as the comabt outcomes in terms of area exhanged,

resources consumed, and time expended in terms of probable set of changes

in operational concept developed by an alert enemy as he learns to cope

with new and unexpected threat behavior. The simulation described prevously in this section is precisely of this kind.

Among the kinds of tactical and doctrinal questions that can be

examined effectively by this division level battle simulation are:

0 Maneuver Force

-Task organization

-Missions

-Echelonment

-Dispositions

-TOEs (must first be transformed into performance parameters acceptable by the model, e.g., firepower, movement rates, response time, etc.)

4-66
o rb

LU u N 44- 0 0

u = . a) f w C) - U - 40 C) m(a 00 0 0 410

C U)L. 4 W * CU -)0

= UJ 0 L .- 0.0 4-)d CL j

*LL i S. j0Va0 L)C

X: C:) U44-7

44
* Fire Support Units

-Allocation of artillery support (DS/GS)

-Allocation of Army assets

-Allocation of close air support (CAS)

-Targeting priorities

-TOEs (as reflected in performance parameters)

-Nuclear planning and execution

* Other Support Systems

-Allocation of Intelligence assets

-Intelligence reporting procedures (as reflected in performance parameters)

-Communication policy (as reflected in performance parameters to include effects of enemy jamming)

-EW policy (to include effects on friendly communications)

q -Allocation of Army air assets to transportation tasks.

Since such a simulation is designed to run for periods not normally exceeding 12 hours of combat, it will not be sensitive to most personnel

and logistic decisions except as these influence the status of forces

at the opening of hostilities. Most such decisions, ,xcept for limited

redistribution of assets by Army air, will not affect the battle outcome within such a short time frame.

4.5.2 Training Applications

As has already been discussed in paragraph 2.4.4, the application of such a simulation to the task of training command group/staffs

involves features of the model already discussed and provided for the

first two applications. A simulation is clearly applicable primarily

to those steps in the education process that involve application of

information and principles a student has already learned, to evaluation

of his performance after application, and to reinforcement of such

learning. As such there are two distinct levels of training to which

it would be applicable.

0 Teaching staff procedures and the mechanics of staff

processing.

* Teaching the doctrinal or policy basis for decision making.

These are described in the following subsections.

4.5.2.1 Procedural Instruction

The simulation is obviously applicable for the purpose of teaching a small group of staff personnel the mechanics of routine staff

procedures. It can be used to provide the triggers for generating the

information processing required to produce specified outputs, whether

4-68

L!
these be provided by sources external to the staff module or generated

by the clock and a Standing Operating Procedure. The necessary information inputs can be provided either on an automatic distribution basis

or accessed as required by the students. This can cover as much as or

as little of the available repertoire of message types (decision variables)

as desired.

Evaluation of the performance of individuals within the staff

module or of the entire module involves a combination of measurements

made of individual staff operations procedures and measurements made in

the information stream at the module boundaries. Such measurements can

be made of the time, effort (in terms of man-hours or man-minutes),

completeness, and accuracy of the information outputs, files, or displays.

Paragraph 5.2.1 contains a detailed discussion of the measures appropriate

and available at the boundaries of the module; paragraph 5.2.2 outlines

the techniques for internal measurement of these quantities.

4.5.2.2 Training in Doctrine or Policy

The simulation is also an excellent vehicle for this higher

level of training in that it puts student decision makers into a realistic

combat environment and requires that they make the same kinds of decisions that must be made in actual combat. The evaluation of student

performance and reinforcement of preferred tactis and doctrine are provided through realistic combat outcomes which indicate to the student

the validity of his decisions by showing him their effect on mission

performance. Such a tool will provide far more credible reinforcement

than does the "school solution" in a classroom situation. The applicable combat outcome parameters are also discussed in paragraph 5.2.1.

The strong parallel between evaluation of new tactics and doctrine and

the evaluation of student decision makers should be noted.

4-69
F

Section 5

INSTRUMENTATION OF LIVE MODULES

5.1 COST OF REALISM

In designing the live staff module there is an important tradeoff that must be considered. This tradeoff is between the realism of

the decision-making environment and the size (hence, complexity and cost)

of running the simulation. The facet of realism being addressed here is

the third principle enunciated by Sackman* i.e., the Conversational

Principle. For this application his statement is paraphased as follows:

0 Conversational Principle: Human performance in man/

(simulation) dialog will vary with the similarity of the

responding (simulation) to tne real time exchange characteristics of human conversation ... As (simulation) response time and message pattern deviate increasingly from

real time parallelism ... so will user performance (vary).

The difference in conversational realism occasioned by the size of the

live staff module can be appreciated by comparing two extremes. At one

extreme are the staff section workshops conducted at Ft. Hood in 1974

under the auspices of HQ MASSTER. For these workshops the normal daytime "shift" of a staff section was assembled together with its TOE

equipment down to the last telephone and radio and disposed in replicas

of their vans and tents in the field. The simulation of outside world,

to include other staff sections, was provided by a group of controllers.

Everything was done to try to place the staff section in an environment

that allowed internal data processing to proceed just as it does when

the unit is in the field and which would make the outside world (as

painted by the message traffic) appear as it would in combat. This was

truly an iconic model in that it certainly looked like the real thing.

The conversational principle was adhered to very strictly. However,

the cost of conducting extensive experimentation in this manner is

prohibitive. It required the services of more than 75 military personnel to man one staff section and to provide controllers and data

collectors.

At the other extreme is SIMTOS which required only a single

player within the staff section and virtually no human control. In a

sense, this is not a fair comparison, for the workshops were simulations

that permitted a staff to operate in a manual mode while SIMTOS was a

simulation designed to permit a decision maker to operate aided only

by a computer and I/O devices which could present to him the aggregated,

evaluated, and synthesized information that would have been presented

to him by the other members of his staff. Nevertheless, if one were to

attempt the SIMTOS approach to building a simulation for study of a

staff operating in the manual mode the conversational principle would

certainly be violated. Yet, the operating costs would be minimal.

*H. Sackman. Computers, Systems Science and Evolving Society. New York,

John Wiley, 1967

5-1
r]

The nature of the trade-off can be appreciated by referring to

Figure 2-5. This figure illustrates the nature of the data processes

for both manual and ADP-assisted operations. The interface between

staff and communication processes, i.e., the simulation, occurs at the

bottom of the figure in the purely manual mode. Much of the time and

effort of a manual staff module is consumed in the lower staff processes,

e.g., receiving, transmitting, tagging, sorting, updating, etc. Thus,

if the interface between the simulation and the manual processes is

moved up to the higher process levels, much manpower can be saved, but

the farther one moves the interface in this direction, the less realistic the "manual" operation becomes.

On the other hand, if the live staff module is operating in

an ADP-assisted mode one faces a different design problem. The simulation

must now perform the ADP processing that would be performed by a TOS,

thus, the interface between the live players and the simulation has

moved to the man/machine interface illustrated in the figure. Clearly,

such an ADP-assisted staff can be substantially smaller than a purely

manual staff if the simulation is doing much of the lower level data

processing. The problem now is not one of manpower costs for the oper- ation, but one of accommodating a range of different man-machine interfaces. Presumably, one would want to use such a simulation to investigate the effectiveness of alternative software and hardware combinations. This has already been alluded to in Section 3.4.6. Even

if the rest of the simulation is essentially hard-wired, the software

development costs for simulating a wide range of ADP assistance would

be substantial.

The following approach will be used in addressing these problems. Every effort will be made to design the live staff module so

that it can operate as realistically as possible in both the manual

and ADP-assisted modes. The impact on simulation structure is that

provision must be made for a "perceived data base" for both Blue and

Red in addition to the real data base which will represent ground

truth. Such a perceived data base is required for any ADP-assisted

operation in which the players are permitted to query a data base in

order to retrieve sorted, updated, and aggregated data. This feature

will also be useful in the manual mode if the player wants to query

subordinate units, for example, for such information.

In designing the purely manual module, consideration will be

given to reducing the number of the required players by including

some lower level processing within the simulation. For example, much

of the message traffic which would ordinarily require players to sit

at radio and telephone instruments in order to transcribe or transmit

hardcopy can be provided to or accepted from the players in hardcopy

form. This does not necessarily mean that all traffic with the outside world would be in hardcopy, because that would seriously violate

5-2

p
the conversational principle. Some filing and recording activities

may also be performed by the simulation in order to reduce manpower

requirements.

In designing the ADP-assisted provisions, every effort will

be made to make the basic simulation structure as flexible as possible,

so that many different interfaces can be supported. The initial design

will provide for a minimal number of different kinds of man-machine interfaces with provisions, however, for proliferation later as new problems and funds to support them may arise.

5.2 PERFORMANCE MEASUREMENT

Some of the pertinent considerations affecting live staff performance measurement have already been addressed in paragraph 2.4.4.

There it was pointed out that measurements within the information network are limited to measurements of time and effort associated with

the preparation of specified staff outputs and measurements of information content of such outputs such as completeness, accuracy and validity for a very limited portion. It was further pointed out that

complete measurements of the quality of information content cannot be

made entirely within the information system but must be inferred from

the outcomes of the combat simulation. Points between which certain

classes of measurement can be made were also defined.

In view of the modular nature of this simulation and the basic

design concept which provides that every information transfer across

the boundaries of a staff module must be made explicity, the measurement of staff performance can be divided into measurements made at the

boundaries of live staff modules and measurements within staff modules.

Each of these is discussed in the following subparagraphs.

5.2.1 Measurement Outside the Staff Module

The top-down design outlined in Section 4 provides for the

following kinds of measurements at the module boundaries:

0 Logging the time of entry into the simulation of every

staff output. This includes out puts which are entered

into the computer and those outputs which are simply

recorded and filed.

* Logging the time of delivery of every staff input provided to live players whether those are generated by

the computer or delivered by the controller from the

file of previously prepared written entries.

5-3
0 Recording the content of every staff input and output

whether processed by the computer or hand processed by

Control.

From these recorded data the following kinds of performance measurements can readily be extracted:

0 Time delays between selected inputs and outputs

* Time delays between selected triggers and outputs

0 Completeness of selected staff outputs with respect to

inputs provided

* Accuracy of selected staff outputs with respect inputs

provided

0 Numbers of selected outputs generated

6 Numbers of selected inputs provided

0 Numbers of queries generated for selected classes of

information.

Measurement of the quality of the content of staff module decisions, as evidenced by the outputs, must be made in terms of their

effects on the battle outcome. The discussion at paragraph 2.4.6

indicated the effectiveness measures that can be used to measure the

relative mission accomplishment of alternative solutions to battlefield management. These are:

* Changes in geographic area controlled by each side

* Changes in the resources consumed and available

* Time intervals required to effect above changes

The design delineated in Section 4 provides these output measures as

follows:

* Changes in geographic area are available as unit locations both in the Real Data Base and on the Controllers

SITMAP

0 Changes in resources are available as characteristics

of the units whose status is maintained in the Real

Data Base

5-4
Time to effect these changes is inherent in an event

store simulation which records the time every change

in unit characteristics (to include location) is effective.

5.2.2 Measurements Inside the Staff Modules

Dynamic processes such as the data processing performed within a live staff module can be studied in either or a combination of

two modes: by time of occurrence of observable events, or by observing behavior at time increments. The latter technique is particularly

applicable to the study of human behavior when the subject is engaged

in repetitive, mechanical tasks (time and motion studies) for which

motion pictures provide an excellent recording and measurement medium.

However, this technique has severe limitations when applied to the

study of information processing. It fails to capture significant

data, e.g., the content of the information stream, and the very volume

of data collected poses a formidable data reduction problem.

An alternative, event-oriented approach to the study of information processing has been used with some success in defining such

processes.1 This involved breaking staff processes down into a series

of elementary operations such as those listed at Table 5-1. The initiation and completion of each such elementary operation is an observable event as is entry of an action into a players' queue or removal from queue. Recording the sequence of such operations, the

time required for each, the time spent in queue, the player who performs each and the station at which an operation is performed plus a

copy of the information transferred, recorded, plotted, etc., provides

one useful means for describing the information process. The results

of such a study can be plotted in flow chart form as at Figure 5-1.

Such data are particularly useful for the simulation of information

processes. There remain problems of designing instrumentation which

does not interfere or interact with the information processing.

The discussion at paragraph 2.4.4 has already indicated that

the measurement of data processing is limited to:

* Effort and delay times for individual processes (from

which the process sequence can also be deduced).

0 Completeness of data outputs which are a prioricombinations of input data.

0 Accuracy of data outputs which are a priori combinations

of input data.

ITiede, R. V., et al, "The Integrated Battlefield Control System (IBCS)

Third Refinement Final Report," Science Applications, Inc., 31 March

1975.

5-5

p

I:
Table 5-1. Elementary Operations

THROUGHPUT OPERATIONS

Receive Radio (Rcv Pad): All action steps required to produce a

written copy of an incoming message via radio to include required

radio operating procedures.

Receive Telephone (Rcv TP): All action steps required to produce

a written copy of an incoming message via telephone to include

required telephone operating procedures.

Receive RATT (Rcv RATT): All action steps required to produce a

written copy of an incoming message via RATT to include required

RATT operating procedures.

Receive Aurally (Rcv Aur): Reduction of an oral transmission-to a

written form.

Transmit OrallyL(mit Oral): All action steps required to convey a

written message by unaided, human voice to a predesignated addressee(s).

Plot on Map (Plot): Post or update symbols on map.

Enter in Journal (Enter): Physical process of recording in journal,

workbook or list.

Retrieve (Rtrv): (Must be associated with a specific file or display.)

Locating and extracting from a particular file or display.

Compose: Prepare a draft of a product or portion of a product.

Make Overlay (Overlay): Physical preparation of map overlay.

Post Display (Post): Enter or update data on visual display.

BRANCHING OPERATIONS

Determine Internal Routing LDIR : Read for content and select

addresses/station routing within element for further processing of

that product.

5-6

'U- m a . . . . . .. . .. ... . . . .... .. . . l I I"
Table 5-1. Elementary Operations (Continued).

Determine External Rnl.ting (DER): Pead foi- coo:'tert arid select

external addresse's).

1.-!)roduce, Manual ~~~oVn:Production of an exacthad itn

ccpy (Nay be multiplc copies using carbon pape-r).

R2..roduce, Machine JPeoro, Mach): Production of an exact copy (or

copies) utilizing copy machine.

ype: Production of an exact copy using a typewriter. (May be

multiple copies using carbon paper.)

COLLECTION, OPERATIONS

Consolidate and pproyeIC&A): Accept, integrate, edit portions of

a product produced by more than ore roturce and release final prom;uct

for distribution (normally to external addressees). The same Operation is used for approval only in ahich case the~re is a single' input.

TERMINATING OPERATIONS

File: (Must be associated with a specific station.) To place a

product or extract therefroat in a designated, closed (nondisplayl)

storage place or to update a pertrancrt (nondisplay) rc -.otd

Terminate (Term): This copy goes no fUrther and -is placed in File

13 or covenience file.

Transmit Radio (Xmit 2ad): All action steps required to Lonvoy a

written ime.ssage via radio to a predesirinated addressee to incIlude

requi red radio operating procedures.

Transnit 'Ifl ephon P mit T AllP action steps requrad to con,.ey a

written w~ssage via telephone to a preuc'sigriatcd clddrcssee to in~clude

required telephone operating procedures.

Transnmi I ATT (Xnit',RAII),: All act ioit steph reai red tLu coiivty a

written i:.essage vii RA/TT to a predcsicjnated addressee to include

required Wi)T operating procedures.

Transmit Courier (ritCnr:Picking up an action from an cutbox,

ceur 'icrV, othecr s Laff u'c::,Ki, or self an, del ivoirni it to a predetermined~ .(jIr0SSFC/St,,trOO Clj fl'S1ic

5-7
RAW WIND DATA

DIVARTY

C/F 2 RATT C/F (FM)

(RATT OPR) (OPS NCO)

RCV RATT RCV RAD

GEN AREA

(FSE OPS NCO)

DIR

GFN AREA JOURNAL

(FSF OPS OFF) (CLERK'

DER ENTER

GEN AREA GEN AREA

( ) I (CLERK)

XHIT COUR TERM

GEN AREA

(CML OFF)

DIR

JOURNAL TRIGGER

(CML SPEC) DOWNWIND

ENTER MESSAGE

RAW WiND HILEI

(CML SPEC)

FILE

Figure 5-1. SOP Flow Chart.

5-8
The completeness and accuracy of all other outputs and the validity

of all outputs cannot be measured directly and must be inferred from

the battle outcomes.

One technique that has been used to make time and effort measurements is the installation of time clocks at every operator/station.

The time clock stamp also contains a unique identifier for every

operator/station. The requirement to insert every message into the

time clock for every elementary operation does introduce some extraneous "noise" into the operation, but the alternative problem of

data reduction that accompany collecting such data by means of movie

cameras is indeed formidable. Clearly the time clock technique would

be useful only for tracking the flow of hardcopy. In the same way,

completeness and accuracy of files and displays can also be measured

by comparison with data inputs, but this again is limited to hardcopy.

For special imited applications it would be possible to capture some

of these data by some combination of cameras and sound recording.

For an ADP-assisted staff, the measurement problem is substantially

easier since the I/O devices can be used to collect much of the needed

data.

There is at least one other approach to the study of information processing which concentrates on the process rather than on the

events. This involves some combination of individual interview, group

discussions, questionnaires, etc., to collect data directly from the

subjects. The pitfalls inherent in such subjective and introspective

techniques are only too well known to behavioral scientists if data

collected in this marnier are not confirmed by experimental evidence.

In the case of the study cited above, data were also collected by such

subjective means. Some general observations as to the validity of the

data collected by these means are pertinent.

* The sequence of operations defined in this manner

tended to be very complete, highly stylized, and "by

the book."

* Job assignments were on a basis of primary skills and

an unofficial "pecking order". For example, principal

staff officers did not answer telephones or radios,or

hand-deliver messages.

0 Job assignments were made without regard to individual

loadings on either personnel or equipment. Standing

Operations Procedures (SOPs) indicated, for example,

that all outgoing traffic would be validated by the

senior staff officer present.

The sequence of individual operations tended to be

linear with minimal parallel processing.

5-9

p .: : i
0 In short, SOPs developed in this manner tended to be

idealized representations that could be followed only

under "no-load" conditions.

Experimental data collected by more objective mans showed marked changes

in these procedures when staffs were subjected to live loads.

0 A live load tended to streamline processing procedures.

Unnecessary frills were eliminated and there was evi- dence of much greater parallel processing.

0 Job assignment became much more "democratic". Tasks

tended to be performed by whatever qulaified person

was available. Officers answered telephones and radios.

The sequence of elementary operations was altered to

route traffic around large bottlenecks and long queues

or the sequence was inverted to keep the action moving.

0 More traffic was handled orally.

0 Under severe loading, processing became so curtailed

that significant information was, indeed, ignored and

some queues, e.g., that of the file clerk, became everincreasing.

The above experience does not mean that subjective methods have no

value. They can be of significant help in making preliminary process

definitions, but they must be corroborated or modified as the result

of objective experimentation.

In summary, our consideration of possible alternatives to live

staff instrumentation leads us to the following conclusions:

0 The collection of data regarding player performance in

the manned staff modules can be accomplished either on

a time increment basis or through event-oriented techniques. At this time, some combination of both alternatives seems desirable.

0 Subjective techniques (interview, questionnaires, group

discussions, etc.) may be useful for formulating initial

concepts as to staff behavior, but must be verified or

modified through objective experiment.

5.3 CONTROL PARAMETERS

To be useful for human factors research on the behavior of

decision makers within populated staff modules, the simulation must

5-10

I ...........
provide control parameters to the experimenter that can adjust the

quality and quantity of information used by the decision maker (player).

A number of categories of such control can be identified. These include:

* Control of the amount and kind of information provided

to populated staff modules for a specified scenario.

Control of the availability of "source identity" to a

populated G2 module.

0 Control the time constraints imposed on a populated

staff module for its decision making.

0 Control the quality of the information provided to a

populated staffmodule.

The top-down design described in Section 4 provides one or

more basic control parameters for each of these categories. These are

described in the following paragraphs.

5.3.1 Amount and Kind of Information

The basic control parameters for this category are:

1. Change the distribution of message types provided

automatically to a populated staff module (Automatic

Distribution)

2. Change the message types which can be accessed by a

populated staff module on a query basis (Query Distribution)

3. Change the threshold values for submission of event

triggered reports (Reporting Threshold)

4. Change the period for submission of periodic reports

(Reporting Period)

5.3.2 Availability of "Source Identity"

The basic control parameter for this category is:

5. Selectively delete "source identity" from spot reports

submitted to the populated G2 module (Source Identity)

5.3.3 Time Constraints for Decision Making

I

The basic control parameters for this category are:

5-11

'9

) . -.
6. Change the requirements for submission of "record"

outputs, i.e., outputs that are not entered directly

into the simulation, from a populated staff module

(Record Requirement)

7. Change the pace of the simulated combat by altering the

ratio between game clock time and wall clock time

(Speed Ratio)

5.3.4 Quality of Information

The basic control parameters for this category are:

8. Change the delay times between trigger event and

message receipt (Message Delay)

9 Change the error rate in message generation (Error

Rate)

10. Change the rate at which blank or random alphanumerics

are introducted into messages (Omission Rate)

5.3.5 Research Applications

The ten basic control parameters enumerated above permit a

wide range of research subjects to be investigated by means of the

model. A small number of these is indicated in Table 5-2 together

with the pertinent basic control parameters.

5.3.6 Adaptive Behavior

The discussion of control parameters to this point has been

limited to the study of manual staff performance, i.e., without ADP

assistance. Providing ADP assistance opens up a whole new vista of

staff performance study. In the ADP mode it becomes feasible to

provide the player himself some degree of control over the form in

which it is presented -- normally by means of visual displays. Such

an adaptive capability can be provided by means of adaptive software

that can be made available with "smart Terminals." This capability

will not be incorporated in the intial implementation of the simulation, but can be added later as additional resources become available.

A major advantage of ADP staff operation from the point of view of the

expermenter is that so much of the internal information flow within

the staff module now appears at the I/O terminal provided the player.

Much of the internal instrumentation that had to be superimposed on

the manual staff is now inherent in the terminal which can record

the frequency of access to the data base by information category,

the kinds of and frequency with which information processes are

invoked, and the forms selected by the player for information display.

5-12
i 4

N

nw9

.09

0

a.

W

0)

U,

0 u w

LC)

0 x

- 0

'0x

us i - A i. LLL W Uaz

a U~W 3 U

L& z aCL. u wz 04W IAA -00

0. 0 Q - I- cctf

IL-W 0 IL i - - 0 UZ0 WOz 0.A - -ZW

)- 00. I 00 1.. W 0. X 0 ~ a:

0,U00- 00

w 0a 0 zccw 2 > In

v I.- U. u 0 -j OW LL -3 

.J> a: J~ R! 0 (A -L . 0 t

5-13
Section 6

DESIGN OF THE INITIAL IMPLEMENTATION

(LIVE INTELLIGENCE (G2) MODULE)

This section pulls together the design features that apply

to the initial implementation of the simulation in the configuration

consisting of two live modules (Blue G2 vs Red Command Module --

Configuration Number 36) or one live module (Blue G2 -- Configuration

Number 4). As such it will repeat or reference materiel already

presented elsewhere in the report in the more general context of

multiple configurations.

6.1 PHYSICAL LAYOUT

A feasible physical layout of the simulation in Configuration

Number 36 is shown at Figure 6-1, which is a repetition of the layout

shown at Figure 4-5. At the left of the figure is the live G2 module

showing stations for four personnel and typical equipment (files,

workbook, journal, displays) for operation in the manual mode. The

two pieces of equipment unique to the simulation are the teletype

printer (for incoming traffic generated by the Battle Outcome Generator) and the pass through window for incoming traffic generated

outside the Battle Outcome Generator and for all outputs of the G2

staff module (orders, queries, responses, and requests). The center

section of the figure shows the simulation proper with the computer

at the top and the human controllers in the lower portion. Physical

equipment in the controllers section consists of a cathode ray terminal, a high speed printer, and a Controller's Situation Map. Shown

at the right is the live Red command module. It also contains the

two simulation unique equipments, the teletype printer and the pass

through window.

It should be noted that the initial implementation can also

be played in Configuration 4 (live G2 module only). In this case the

functions of the Red player are taken over by the Controller(s) if the

experiment objective requires interaction on the part of the Red side

i.e., that Red orders, requests, etc. be dependent on the actual

status of the force interactions at any particular time. If Red

interaction is not required, the outputs from the Red side can simply

be scheduled and treated as if they were scenario events.

6.2 PERSONNEL REQUIREMENTS

6.2.1 Blue G2 Module

The TOE of the Ari ored or Mechanized Infantry Division (TOE

17-4H) provides a G2 section consisting of 6 officers and 9 enlisted

men. There is, however, a much larger group within the division

6-1

p.
La LU 0-0

LLS.

CL. -i

tAJ L0

LLJ L'U c-J

F- Lai 20. U

8 cr -)

j,

ac~

-6-2
involved in both intelligence and EW activities, much of it at

division level. This is the Combat Electronic Warfare Intelligence

(CEWI) battalion whose HQ company maintains an Electronic Warfare

Intelligence Operations Center (EWIOC) for the production and dissemination of integrated all-source intelligence, mission management

for intelligence and electronic warfare operations and performance

of the SSO function. As such, this center works closely with both

the G2 and G3 sections of the division general staff. It is profitable to look more carefully at the organization, mission, and functions of the CEWI battalion in order to develop a rationale for how

much of its activities, if any, should be included in the G2 staff

module, quite aside from the pragmatic consideration that the G2

module could easily become so large as to be unmanageable and unaffordable. The following is an extract from the draft document, Training

Text 30-115T, COMBAT ELECTRONIC'WARFARE INTELLIGENCE BATTALION (CEWI

BN) DIVISION, prepared by the US Army Intelligence Center and School,

Fort Huachuca, Arizona, 15 June 1976.

"COMBAT ELECTRONIC WARFARE INTELLIGENCE BATTALION, DIVISION

"2-1. ORGANIZATION. TOE 30-115T was developed in response to the

Chief of Staff's decisions to integrate intelligence and electronic

warfare assets at the tactical echelon. Organic to this battalion

are three companies: Headquarters and Operations Company, TOE 30-

116T; Electronic Warfare Company, TOE 30-117T; and Ground Surveillance Company, TOE 30-118T.

SCEWI BN I

co ,EWO Co

Figure 1-1

"2-2. MISSION. This battalion, organic to an armored or infantry

(mechanized) division, provides combat intelligence and electronic

warfare functions in support of the division.

"2-3. FUNCTIONS. The CEWI battalion provides integrated intelligence

analysis and production, timely intelligence dissemination, integrated

mission planning and management, command and control, centralized logistics and administrative support for intelligence assets, and intelligence skills in the three basis disciplines: HUMINT, Imagery, and

Electromagnetic. The battalion provides electronic warfare planning,

coordination and execution.

6-3

p.

° 9
a. The CEWI Bn supports the division by providing electronic

warfare and combat intelligence in the fields of signals intelligence,

imagery interpretation, interrogation and ground surveillance. The

battalion, through the Electronic Warfare Intelligence Operations

Center (EWI Op Ctr), which is comprised of the Mission Management and

Dissemination Section (MMDS), All-Source Production Section (ASPS)

and the Electronic Warfare Section (EWS), provides electronic warfare

support and integrated all-source intelligence to the commander. In

addition, the functions of counterintelligence (CI) and signals security (SIGSEC) are also provided by elements of the battalion. A US

Air Force Weather Section (USAF WX SEC) is attached to the battalion

to provide weather support for the division.

b. The CEWI Bn provides a single intelligence and electronic

warfare commander who is responsible for the integrated management of

all assets in his command. He is responsible for the execution of

intelligence tasks, to include analysis, production, dissemination,

and collection planning, and for the execution of EW mission planning

and execution. The battalion operates under the general staff supervision of the G2, and responds to the G2 in matters of intelligence

and to the G3 in matters pertaining to EW. The commander also exercises centralized command, control and supervision of the administrative and logistical support functions of the battalion.

c. The battalion provides RATT/AM/SSB communications during

initial employment of the battalion, and as an alternate, FM/AM/SSB

for command and control. Area multichannel communications provided

by the division signal battalion are used to the maximum extent

possible for intelligence operational traffic.

d. This organization is capable of providing direct support

(DS) maintenance on communications and electronic equipment, less

RADIAC, and general maintenance support (GS) on electronic warfare

(EW) equipment. The battalion performs organizational maintenance

on all other items of equipment. The battalion is dependent upon

appropriate elements of the division for medical, religious, financial, legal, and personnel administrative services, the divisional

signal organization for service into the area communications system,

areas."

From the above extract, it is clear that the CEWI battalion

provides a formal structure for two separate but highly integrated

support systems for the division: the intelligence support system

and the electronic warfare support system. Further, the intelligence

system is under staff supervision of the G2 and the EW system under

the supervision of the G3. Thus, the CEWI battalion provides special

staff services and executes operations in much the same way as other

specialized support organizations, e.g., division artillery, the

6-4

i-
engineer battalion, or the signal battalion. The general staff, on

the other hand, assists the commander in carrying out what have been

called the integrating functions: see, plan, allocate, fight, sustain, and communicate. There is, thus, a philosophical basis for

distinguishing between carrying out such integrating functions and

the performance of specialized support functions by the support systems.

This distinction is made clear in the Combined Arms Combat Development

Agencies (CACDA) current approach to the Technical Interface Concept

(TIC) of the Corps Battlefield.'

On this basis, then, there is no more reason for including

elements of the CEWI battalion, to include the all source analysis

and the EW components of the EWIOC, in the general staff modules than

for the engineer battalion or the signal battalion. The simulation

will, therefore, threat the components of the EWIOC as a Part of the

battle outcome generator and not as a component of either the G2 or

G3 staff modules. The activities of the all-source analysis center

will be included in the algorithms which generate the perceived data

base from the real data base.

Having made this design decision, it is clear that no simulated

special intelligence will appear in any of the message traffic generated by the simulation because all of the intelligence produced by

the EWIOC and flowing to G2 will be "sanitized" so as not to disclose

sources of special intelligence. This needs further consideration in

view of Task 2b of the contract which states that, "Explicit consideration shall be given ........ to the tradeoffs involved in the

inclusion of special intelligence." A number of factors apply to

such consideration. The first factor is that current policy provides

that information available at division level from special intelligence

sources of higher HQs will normally be sanitized at corps level (e.g.,

SI from national sources) so that such SI is not normally available

in any case at division level. SI from sources within the division

(CEWI battalion) is, of course, available within the EWIOC and would

normally be accessible to the commander, the G2 and G3. However,

properly processed intelligence will indicate the level of uncertainty

associated with a given report -- a level assigned on the basis of

known performance of the source. It will be assumed that the simulated all-source analysis processing will satisfactorily assign such

uncertainties. It should be pointed out, however, that this does not

preclude consideration of "sources" from the evaluation of G2 module

performance because special intelligence is not the only component

of battlefield intelligence. The G2 must consider dat from many

other sources available to him, e.g., the reconnaissance squadron,

the maneuver units, and division artillery, to name but a few. These,

too, must be evaluated and result in an assignment of uncertainty

ISolicitation Number PAAK 21-79-R-9010, study entitled "Technical

Interface Concept (TIC) on the Corps Battlefield," Harry Diamond

Laboratories, 18 Dec 78.

6-5
based on known performance of such sources, so that availability of

source identity remains a feasible control variable for G2 evaluation.

The task statement cited above also provides that explicit

attention be given to the play of EW in the simulation. It is pertinent to examine the various components of EW as illustrated in

Figure 6-2. The three major components are electronic support measures

(ESM), electronic countermeasures (ECM) and electronic counter-counter

measures (ECCM). As indicated in the figure this activity is under

the staff supervision of the G3 which, in the simulation, means that

staff inputs such as the Enemy Electronic Order of Battle (EEOB)

flow from the EWIOC to the G3 staff module and that decision outputs

to jam appear as frag orders to engage in jamming from the G3 module.

However, as shown in the figure, inputs are required from both ESM

and ECM in order to make decisions as to whether enemy electronic

emitter should be exploited, jammed, or destroyed. Such decisions

involve not only the G3, but also the G2 and the FSE. The necessary

intra-module staff coordination for such decisions is provided by

means of the "request" procedures described in Design Note G. This

procedure provides that a simulated G3 module would provide a copy

of a frag order directing jamming operations to the G2 for concurrence

prior to submitting it to the BPG for implementation. Similarly, FSE

would coordinate with both G3 and G2 prior to issuing a frag order for

destruction of an electronic target. It is also possible for a live

G2 module to write a frag order directing jamming operations to begin

and forward it to G3 tor implementation. This amounts to a recommendation to initiate jamming. In a similar vein, the simulation will

provide that a simulated G3 module will, on receipt of the EEOB from

the EWIOC provide an information copy to the live G2. Thus, although

EW is technically under the purview of the G3, the model does provide

for the live G2 to participate in the EW decision processes.

Having established a sound basis for populating the G2 module

only with TOE personnel, we are finally able to address the question

of the size of the G2 module personnel complement. Something less

than half of the authorized personnel strength (6 officers, 9 enlisted

men) would be on shift at any one time. As has already been discussed in paragraph 3.4.5, providing players with hard copy eliminates

many of the lower level communication and message center processes

required for oral communication, thus further reducing the manpower

requirements. On this basis, we visualize the personnel complement

of the populated G2 module will be from 3 - 5 persons depending upon

the objectives of a given experiment.

6-6
-~

4- 0r 0

o. S.-

a)

4-) _ 0L ( - c- =. E.c

Q U a) In

U a a .- C +- 0U

L- 3 4-) 0 U Sw- m S- 3: 4J0

4- S- C - 0-

C S. - 0L a)-~L

c.- CL 4-) * i I~ I

4-0 -) 0 )0

a) 0 0 0

o -

S..

LUJ

0) 4--

~ S.- S.- 0

.- (u 4-' 0 4-'

Ln S- ) r_

S- a) 0

S.. C c) CL0

0)) O C - E-- 

a)4- 4- 0 LUI C) U 0 c 0.4- 0 S- L.) ._ :3 CL 0 4-'

4- w. C)0-C

4U - L) 0)u

0 _

4-) 4. a)

0 (a'

LU~ - .. 4-

0 on 

S. - x m w

c~ 0 -- 7

V) CA ~ I

(0 . 4-). CD I I

0v 4-3

U 0 N S-

* 4-' S- C -*- *-

S- U0 *.- 4 - S- *C:)

o - e (U ) 4_ -'

CL- 5-) 0)4 -) U C

C 4- 0) C (

uj~ ~ ~ ~ - . LiC-c 

S-(

4-)

LU

6-7
-.- ..--

6.2.2 Control Module

As has already been stated in paragraph 4.2, the proposed

initial implementation is predicated on a maximum of two persons in

the Control module to direct and operate the system. Although some

scenarios could probably be run with only one person in Control, it

is considered unlikely that very many experiments involving interaction between a live G2 and a live Red command module could be run

with less than one controller maintaining the Controller's SITMAP

and another operating the machine terminal.

6.2.3 Red Command Module

For those experiments for which a live Red command module is

required, this module will need-one player. The tactical information

messages to include the possible outputs from and the simulation inputs into the Red Command module have been identified at Design Note

A by an asterisk. This number has been adjusted so that the decisions

required from a Red player should be within the capability of a single

player.

6.3 OUTPUTS AND INPUTS

The specific list of allowable outputs (Class 3 only) of a

live G2 module and the list of possible input messages (Class 4 only)

to such a model is shown at Table 6-1. This has been extracted from

Design Note A. The outputs are at the top of the table and the inputs at the bottom.

The permissible list of modular addressees for the G2 staff

module outputs is shown at Table 6-2. This has been extracted from

Design Note B. Which of these permissible addressees will in fact

receive a copy of a selected output is determined by the players.

Table 6-2 also lists only Class 3 outputs.

The relation between inputs and outputs of the live G2 module

is shown in input/output matrix form in Table 6-3 which had been extracted from Design Note C. This lists all Class 2, 3, and 4 events.

Whether this relation is in fact observed by live players is, of

course, a matter of their choice.

6.4 CONTROL PARAMETERS

To be useful for human factors research on the behavior of

decision makers within the populated G2 module, the simulation will

provide a number of control parameters to the experimenter that can

be used to control the quality and quantity of the information available to the decision maker. These have already been discussed in a

6-8
I-ILU~

0 LUJ F4- <~0

ra LI)' 0 LU F- L/) i-U I

C:) Wz n I-) 

VI) to U,- -- Q- C 0 Vn LLUJ W c LL .J LUJ . 4 (n OWLCD ) 0) L- LUi Q: V) LUGW). 4= - -

c :t C- m) L)-JLLJ LLU4-

a)) -- cr- LL- - _j U 

) <E:LU- LLJ L - a M>' LL e -

2L LL XI) - w >< ~ I GJ

C U W -2:LV) MU V). ZU- LL-a LL L LI= L' C) r C)/ LOf CD -- J U 2- L LUO ) m ULL u V I 0U C) / - =L r_

L)) Ix -I LUJ C)L Q) V) 0U- I'

-J D t LW- -J a- cL4 = u L.) = L J WV - -c LU C- L JL)c F->< L-i 0 I)/ L F- -)L L-

~ -LLu~ ~ LULD U LULJ ELLJ4-

F- (WDQ -----3L< 0W !LU LL<.-J L) -t/ 524-LU~i- =. -D>4 :

lo j - - ( V)LU LL U LJLOL) W C -J0ZLJ E UD LU J

-JV)21 - C <Cl L F V WLLU)L) -n LLJQ. =-4 m..J jJI M

(3 -C: L L LJU LIU L -~LULL - ) I--0L. C

Q) (X"MC ' L ~ .. J )0 UC F L )0 OU -= )WF 0=c - =<C L 0

L LU ~LAC-- 0'JLJL Mw( t= Ed 0-4 LAJOC / LLJJ w a) >- = MM (DL D J L - W Z0- U C)0 : VLL D 0

0 0 w0 -=wL i=r LJWL - =U <( 0D= L

0 :) Or%_jj i ClCJ~ Cl= 0 0 um f V C . C LL >- V L :- i- L L 0 =L)I c- . j> )c W Y - JF L LJW= - D- F OF : w(

Iu W -F )-LL p( )( L l 3

= ) X DLL =2- U L c wXD-C6-9L =C
Table 6-2. Module Outputs and Their Modular Addresses.

ADJ

kACTICAL INFORMATION MESSAGE CORPS DIV 040D FSE1 G2 G3 GIG4 DIV

INTELLIGENCE STAFF

30 QUERY X x x

31 D QUERY

32 FRAG ORDER(I) X XX X X

33D DIV INTSUM X XX X

34 NBC REPORT X'

35 WX FORECAST X X

36 INTELL INPUT TO DIV SITREP

370 INTELL EST xX X

380 INTELL ANNEX

39 REQUEST x X X

40 RESPONSE x

XX RETRANSMIT XX X

6-10
Table 6-3. Input/Output Matrix for Intelligence Staff 1'.1odule

Az

4z

INPUT MESSAGES

OURCE

01 OSUhR' CMD x x Ix I I x

-DT- MAL LMU -x I x Ix

04D CMDR'S GUID I Ix

05 CMDR'S DEC -79D- -r I I

xx RETRANrMTT - CMD -X10 QUERY FSE x x x 7-

1z FRAG OB-n-rF-31- -- FSE--- -r

16 TGT LIST (AATY -M- -T -37

17 EU FIRE SPT CAP Ivsr-- -T1.9 POST STRIKE ANAL -FSE x x

21 RE9 ES FSE x x

22 RESPONSE -Fsr- -x

xx RETRANSRrr- -Tg- x x x

50 QUERY -GT- - -X X- X x

5Z FRAG ORDER (OPS) G3 .y )r- -x

530 DIV SITREP G3 -r -R- -

54 NUC WARNING ORDER- 75- -F -X55 AD WAR-NTNG - G3 x I x x 57D OP PLAN M- x

5 FD- OP EST G3 x

59 INITIAL EN CONT G3 X-

-n- LUU13 x

63 UEST x

Tr- ;E WE -xxx RETRANPTT- -ZT80 QUERY G /G4 x

8Z FRAG 0 TnS) GI/G4 x x x x

'870 CSS EST G 1 /64

89 REIUIST x

RESPOMS E

xx RETRANSRTr- Z7G2F-- - -r

0 GENERAL SIT

D SPECIAL SIT CORPS-,- -- x x

34 NBC REPORT UP3 x

44 CBT INTEn-Wr-ZUM---X -T- x

49D FRAG ORDER (1) C RPS x

34 NBC R PORI UIV x

35 WX FORUM- I V x x I

41 6DE INTTuV- -DTV-'x Ix x

42 SHELL REPORT x x x

43 SPOT REM- DIV x

44 CBT INTML-Ur- IV x x x 45 POST STRIKE DAM RPT uIv x

79- EST OF EN STRENGTH DIV ,F -T- - - -T x

47 TGT LIST (1) -x -T- - -

148 QULR' XT - X

6-11
more general context in paragraph 5.3 but are repeated here for the

sake of completeness. The top-down design described in Section 4

provides the following control parameters:

6.4.1 Amount and Kind of Information

The basic control parameters for this category are:

1. Change the distribution of message types provided

automatically to the populated G2 staff module

(Automatic Distribution)

2. Change the message types which can be accessed by

a populated G2 staff module on a query basis (Query

Distribution)

3. Change the threshold values for submission of event

triggered reports (Reporting Threshold)

4. Change the period for submission of periodic reports

(Reporting Period).

6.4.2 Availability of "Source Identity"

The basic control parameter for this category is:

5. Selectively delete "source identity" from spot reports

submitted to the populated G2 module. (Source Identity)

6.4.3 Time Constraints for Decision Making

The basic control parameters for this category are:

6. Change the requirements for submission of "record"

outputs, i.e., outputs that are not entered directly

into the simulation, from the populated G2 staff

module (Record Requirement).

7. Change the pace of the simulated combat by altering

the ratio between game clock time and wall clock

time (Speed Ratio).

6.4.4 Quality of Information

The basic control parameters for this category are:

8. Change the delay times between trigger event and

message receipt (Message Delay).

6-12
9. Change the error rate in message generation (Error

Rate).

10. Change the rate at which blank or random alphanumerics

are introduced into messages (Omission Rate).

6.4.5 Research Applications

The ten basic control parameters enumerated above permit a

wide range of research subjects to be investigated by means of the

model. A small number of these is indicated in Table 6-4 together

with the pertinent basic control parameters.

6.5 MEASUREMENTS AND EVALUATION

The previous discussion at paragraph 5.2 is equally valid

for the live G2 module and is repeated here for the sake of completeness. Some of the pertinent considerations affecting live staff

performance measurement have already been addressed in paragraph

2.4.4. There it was pointed out that measurements within the information network are limited to measurements of time and effort associated with the preparation of specified staff outputs and measurements of information content of such outputs such as completeness,

accuracy and validity for a very limited portion. It was further

pointed out that complete measurements of the quality of information

content cannot be made entirely within the information system but

must be inferred from the outcomes of the combat simulation. Points

between which certain classes of measurement can be made were also

defined.

In view of the modular nature of this simulation and the

basic concept which provides that every information transfer

across the boundaries of a staff module must be made explicit, the

measurement of staff performance can be divided into measurements

made at the boundaries of live staff modules and measurements within

staff modules. Each of these is discussed in the following subparagraphs.

6.5.1 Measurements Outside the Staff Module

The top-down design outlined in Section 4 provides for the

following kinds of measurements at the live G2 module boundary:

0 Logging the time of entry into the simulation of

every G2 staff output. This includes outputs which

are entered into the computer and those outputs which

are simply recorded and filed.

6-13
C3J I" 1

m 1

a) C9

.9-

4ait I.- :I- A1f

u

Kj K d-4i a 

us- acQ-4p

oL oKX:a C

'U'

a j u C 4 go Z

U.44 0; 1w goW !.0 6- A m0

.- i 0 Wa.9 " 0 a

U.=W 04W 41 a 0"40

6-14
0 Logging the time of delivery of every staff input

provided to the live G2 players whether those are

generated by the computer or delivered by the controller

from the file of previously prepared written entries.

0 Recording the content of every G2 module input and

output whether processed by the computer or hand

processed by Control.

From these recorded data the following kinds of performance measurements can readily be extracted:

0 Time delays between selected inputs and outputs.

0 Time delays between selected triggers and outputs.

* Completeness of selected staff outputs with respect

to inputs provided.

* Accuracy of selected staff outputs with respect

inputs provided.

0 Numbers of selected outputs generated.

0 Numbers of selected inputs provided.

0 Numbers of queries generated for selected classes of

information.

Measurement of the quality of the content of G2 staff module

decisions, as evidenced by the outputs, must be made in terms of

their effects on the battle outcome. The discussion at paragraph

2.4.6 indicated the effectiveness measures that can be used to

measure the relative mission accomplishment of alternative solutions

to battlefield management. These are:

* Changes in geographic area controlled by each side.

* Changes in the resources consumed and available.

0 Time intervals required to effect above changes.

The design delineated in Section 4 provides these output measures

as follows:

0 Changes in geographic area are available as unit

locations both in the Real Data Base and on the

Controllers SITMAP.

0 Changes in resources are available as characteristics

of the units whose status is maintained in the Real

Data Base.

6-15
6.5.2 Measurements Inside the G2 Staff Module

The discussion at paragraph 5.2.2 covered the question of

performance measurements inside the staff module in some detail and

applies equally to the populated G2 staff module. Because of its

length it will not be repeated here.

In summary, SAI's consideration of possible alternatives to

instrumentation inside the live G2 module leads us to the following

conclusions:

0 The collection of data regarding player performance

in the manned staff modules can be accomplished either

on a time increment basis or through event-oriented

techniques. At this time, some combination of both

9alternatives seems desirable.

0 Subjective techniques (interviews, questionnaires,

group discussions, etc.) may be useful for formulating initial concepts as to staff behavior, but must

be verified or modified through objective experiment.

6.6 PLAN FOR INITIAL IMPLEMENTATION

6.6.1 Major Tasks to be Accomplished

1. Prepare Model Description

Description of the model from the user's point of

view. Includes description of the capabilities and

limitations of the prototype version (G2 live), general

information flow, macro-logic, data base organization,

required and feasible pre-play inputs, general operating procedures, model outputs, instrumentation of

live modules, complete listing of all English language

formats.

Level of Effort: 5 TMM

2. Prepare Controller's Manual

Detailed instructions for the Controllers to include:

* Pre-loading instructions, to include terminal

operation

0 Operating instructions, to include terminal

operation

0 Terminating and re-start instructions

6-16
0 Special instructions for Control when Red

command module is simulated.

Level of Effort: 5 TMM

3. Prepare G2 Player's Manual:

Detailed instructions for live players in the G2 module

to include:

* Permissible decision variables

0 Detailed division staff SOP

0 English language input and output formats

Level of Effort: 5 TMM

4. Prepare Red Player's Manual

Detailed instructions for live player in Red Command

module to include:

0 Permissible decision variables

0 Detailed division staff SOP

0 English language input and output formats

Level of Effort: 2 TMM

5. Scenario Preparation

This task involves the following:

* General instructions on preparation of a

scenario (preloading of model) to address

typical test objectives

0 Preparation of a test scenario which addresses

a specific ARI test objective.

Level of Effort: 5 TMM

6. Develop and Test the ADP Portion of the Model

r This task covers the programming and testing of the

ADP software required to load, operate, stop, and

re-start the model, as well as any required postprocessing.

6-17

I -- -
7. Model Demonstration

This model will be demonstrated using the test scenario

in two phases:

* Initial demonstration of SAI facilities

0 Final demonstration of model on ARI facilities

Level of Effort: 10 TMM

8. Prepare Technical Documentation

This task involves preparation of the complete technical

documentation of the ADP programs developed in Task 6

in accordance with prescribed standards.

Level of Effort: 12.TMM

Total Estimated Effort: 66 TMM

Estimated Computer Costs: $10,000.00

6.6.2 Schedule for Completion of Initial Implementation

The tasks listed above would be completed in a period of 18-24

months after initiation. The critical path that determines this time

length involves software preparation (Task 6) and the demonstration

of the completed model (Tasks 7 and 8). The schedule for implementing the initial version of thesimulation is shown at Figure 6-3. This

figure shows the completion schedule for the eight tasks enumerated

above in Gantt Chart form. Also shown are the major milestones.

-
4-1

_ _ _ _ _ _ _ _ _ _ _ * _ _ _ _ _ _ _ _ _ _ _ -

3. N4

E

5--

4.41

C _ _ __ _ _CU

5.4 -. -. -

NV

-0 -' 3 -S 

C4.

o 0.6519
DISTRIBUTION

ARI Distribution List

4 OASD (M&RA) 2 HOUSACOEC. Ft Ord, ATTN: Library

2 HODA IDAMI-CSZ) 1 HOUSACOEC, Ft Ord, ATTN: ATEC- EX-E Hum Factors

HODA (DAPE PBRI 2 USAEEC, Ft Benjamin Harrison, ATTN: Lilirmy

I HODA (DAMA ARI I USAPACOC, Ft Benjamin Harrison, ATTN: ATCP --HR

HODA (DAPE-HRE-PO) 1 USA Comm-Elect Sch, Ft Monimouth, ATTN! ATSN -EA4

I HOOA (SGRD-IDI I USAEC, Ft Montmouth, ATTN: AMSEL CT HOP

I HODA (DAMI.OOT-C) 1 USAEC, Ft Monmouth, ATTN: AMSE L-PA P

1 HODA (OAPC.PMZ-A) 1 USAEC, Ft Monmouth, ATTN: AMSEL-* SI-CB

I HODA IDACH-PPZ-AI 1 USAEC, Ft Monimouth, ATTN: C, Fact 0ev Br

9 HODA IOAPE-HRE) 1 USA Materials Sys Anal Agcy. Aberdeen, ATTN: AMXSY -P

1 HODA (DAPE-MPO-C) 1 Edgewcood Arsenal. Aberdeen. ATTN: SAREA BL H

I HODA (DAPE-OW) 1 USA Ord Ctr & Sch, Aberdeen, ATTN: ATSL-TEM-C

1 HODA (DAPE-HR LI 2 USA Hum Engr Lab, Aberdeen, ATTN: Library/Oir

I HODA (OAPE-CPS) 1 USA Combat Arms Trig Bdt, Ft Banning, ATTN; Ad Supervisor

1 HODA (DAFD-MFAI I USA Infantry Hum Rsch Unit, Ft Bennio. ATTN: Chief

1 HODA (OARD-ARS-Pl 1 USA Infantry Bd, Ft Benning, ATTN: STE BC TE- T

1 HQOAi (OAPC-PAS-AI I USASMA. Ft Bliss, ATTN: ATSS-- LRC

1 HODA IDUSA OR) 1 USA Air Def Seb. Ft Bliss. ATTN: ATSA CTD ME

I IHfDA fDAMO-RORI 1 USA Air Del Sch, Ft Bliss, ATTN: Tech Libi

I HOQIA (DASGI 1 USA Air Del Bd. Ft Bliss, ATTN: FILES

I HOf)A IDAI I'DPl 1 USA Air Del Bd, Ft Bliss, ATTN: STEaD -PO

1 Clt Consult Div IDA-OTSGI, Adelpihi. MD 1 USA Cmd & General Stf College, Ft Leavenworth, ATTN: Lih

1 Mil Asst. Hism Res, ODDR&E, OAD (E&LS) 1 USA Cmd & General Sit Cotlege, Ft Leavenworth, ATTN: ATSW-SE - L

1 HO LISAHAL. APO Seattli'. ATTN: ARAGP-R 1 USA Cmd & Generat Sit Coltege, Ft Leavenworth, ATTN. Ed Advisor

1 HO First Army. ATTN: AFKA-01 TI 1 UISA Combinoed Aims Cmbr 0ev Act, Ft Leavo-itioorth. ATTN: OepCdr

2 HO Fifth Army. Ft Sam Houston I USA Combined Arms Cmbt 0ev Act. Ft Leavenworth. ATTN., CCS

1 Dii, Army Sit Studies Qfc. ATTN: OAVCSA (DSPI 1 USA Combined Arms Cnsbt 0ev Act. Ft Leavenworth. ATTN: ATCASA

1 Oh, Chiel nI Sit, Stdites (1k I USA Combined Arms Cmbt 0ev Act, Ft Leavenworth, ATTN: ATCACO-E

I IiCSP3R, ATTN: CPS/OCP 1 USA Ciomlini-d Arms Cmbot 0ev Act, F't Leavi-nworth. ATTN: ATCACC-4.t

I Thr- Army Lit,, Preiitaron. ATTN: RSB Cief 1 USAFCOM, Night Vision Lab, Ft Beloorvr. ATTN: AMSEL-NV-SD

I The Army Loti, Pentagon, ATTN: ANRAL 3 USA Computer Sys Cmd, Ft Belvoir, ATTN: Tech Library

1 Ofc. Asst Sect of the Army I R&D) 1 USAMERDC. Ft Belvoir, ATTN: STSFB -DO

I Tech Support Olc, OJCS 1 USA Eng Sch. Ft Belvoir, ATTN: Library

I USASA. Arliniiloii. ATTN: IARD-T 1 USA Topographic Lab, Ft Belvoir, ATTN: ETL TO-S

I USA Rsch 0lc, Durhiam, ATTN: Life Scucices Dir I USA Topographic Lab. Ft Belvoir, ATTN: STINFO Center

2 LISARI EM, Nalui.l, ATTN: SGRD-UE CA 1 USA Topographic Lab, Ft Belvoir, ATTN: ETL GSL

I tISAT [C. t I (:loyo, At I I I!; I : MO A I l(NA hfloli-nuo- Ct A, Seli Ft Himicvitnsa ATTN: CTD MS

I USAiMA, Ft Brill.Al N: Al SUCID-UM 1 USA Inlelluqence Cli & Sch, Ft Huachuuca, ATFTN: ATS-CTD-MS

1 USAIMA, Ft Braqq, ATTN: Mariluat Lob I USA Intelligence Cti & Sch, Ft Huachuca. ATTN: ATSI-TE

1 US WAC Ctr & Sch. Ft McClellan. ATTN: Lit) 1 USA Intelligence Ctr & Sch. Ft Huachuca, ATTN: ATSI- TEX--GS

I US WAC Ctr & Scli. Ft McClellan, ATTN: Thul Dir I USA Intelligence Cir & Sch, Ft Huachuca. ATTN: ATSt-CTS--OR

I USA Quartermaster Sch, Ft Lee, ATTN: ATSM-TE I USA Intelligence Ctr & Sch. Ft Huachuca. ATTN: ATSt-CTD--DT

I luiteltigence Material Dry Ole, EWL, Ft Holahurd 1 USA Intelligence Ctr & Scti, Ft Huachuca, ATTN: ATSt-CTO--CS

I USA SE Suquisl Sch Ft Goirdon, ATTN: ATSO EA 1 USA Intelligence Ctr & Sch, Ft h~uachuca, ATTN: DAS/SRD

I USA Chalitaoii Cii & 3,-h. F i Haniiultii, ATTN: ATSC-TF-RD 1 USA Intelligence Cii & Sch. Ft Huachiticii. ATTN- ATSI-TEM

1 USAISCH, Ft Eustis, ATTN: Ediuc Aivisor 1 USA lIntelligence Cti A Sch. Ft Huachuca, ATTN: Library

1 USA War Collegte. Carlisle Biiiacks, ATTN- Lit) 1 CDR, HO Ft Huachuca. ATTN: Tech Ret Div

2 WRAIR, Niurusyrti,utu Div 2 CDR, USA Electronic Prvg Ged, ATTN: STEFP MT-S

I DLI. SDA. M ...iuerrn' 1 HO, TCATA. ATTN: Tech Library

1 USA Concept Anal Acgcy. Bethesda. ATTN: MOCA MR 1 HO, TCATA. ATTN: AT CAT.OP-O, Ft Hood

1 USA Concent Anal Ailey. Bethesda, ATTN: MOCA-JF 1 USA Recruiting Cmd, Ft Sheridan. ATTN: USARCPM-P

IUSA Arctic Test Cir. APO Seattle. ATTN: STEAC-PL-MI 1 Senior Army Adv., USAFAGOO/TAC, Elgin AF Auxn Fid No. g

1 USA Arctic Test Ctr. APO Seattle. ATTN: AMSTE-PL-TS 1 HO, USARPAC. DCSPE R. APO SF 96558, ATTN: GPPE -SE

I USA Armament Cmrt. Redstone Arsenal, ATTN: ATSI(.TEM 1 Stimson Lib. Academy of Health Sciences, Ft Sam Houston

1 USA Armament Cmd, Rock Island. ATTN: AMSAR-TOC I Marine Corps Inst.. ATTN: Dean-MCI

I FAA-NAFEC, Atlantic City, ATTN: Library 1 HO, USMC, Commandant. ATTN: Code MTMT

1 FAA NACEC, Atlantic City, ATTN: Human Engr Br 1 HO, USMC, Commandant. ATT'N: Code MPI-20-28

! FAA Aeronautical Ctr. Oklahoma City. ATTN: AAC-44D 2 USCG Academy, New London, ATTN: Admission

2 USA Fid Arty Sch. Ft Sill. ATTN: Library 2 USCG Academy. New London. ATTN: Library

1 USA Armor Sch, Ft Knox, ATTN: Library 1 USCG Training Ctr, NY, ATTN: CO

1 tISA Armior Sch. Ft Knox, ATT'N: ATSO.0l-F 1 USCG Training Ctr, NY, ATTN: Educ Svc Ole

I USA Armror Sch. I Kniiv, ATTN ATSB DT TP 1 USCG, Psychol Res Bt, DC. ATTN -GP 1/62

I USA Armour Sch. Ft Kiioe. ATTN ATSB-CD-AD 1 HO Mid-Range Br. MC Det. Quantico. ATTN: P&S Div

6-21
I US Marine Corps Liaison Otc. MC. Alexaria. ATTN- AMCGS-r 1 Bet & Civil Inst ol Enviro Medicine. Canada

1 USATRADOC, Ft Monroe. ATTN: ATRO-ED I At R CRESS, Kensington. ATTIC Into Sys Or

6 USATRADOC. Ft Monroe. ATTN: ATPR AD 1 Militaorpsykologisk Tienesae Copenhagen

1 USATRADOC. Ft Monroe. ATTN: ATTS--EA 1 Military Attache, French Embassy. ATTN4: Doc Sec

1 USA Forces Cmd, Ft McPherson, ATTN: Library 1 Modecin Chef, C.E.R.P A.-Aroenel. Toulain/Naval France

2USA Aviation Test Od. Ft Rucker. ATTN: STEBG-PO 1 Prin Scientific 0". Asspl Hum Engr Rsch Div, MinistryI

1 UISA Agcy for Aviation Safety. F t Rucker, ATTN: Library of Defente. New Delhi

IUSA Agcy to, Aviation Safety, Ft Rucker. ATTN: Edsjc Advisor 1 Part Rich Ofc: Library, AKA, Israel Defense Forces

1 USA Aviation Sch. Ft Rucker, ATTN: PO Drawer 0 1 Ministeris van Defenele, OOOPIKL Afd Sociaof

1 HOUSA Aviation Sys Cmd. St Louis, ATTN: AMSAV-ZDR Psychologische Zakert. The HMae Netheirlanrds

2 USA Aiation Sys Test Act., Edwards AFO, ATTN: SAVTE--T

I USA Air Def Sch, Ft ltlrs%. ATTN: A TSA TFll

I USA Air Miilvlly Rsc:b &e Dev Lahn, Motfett Flit. ATTN: SAVDL -AS

1 USA Aviation Sch. Res Tnig Mgt. Ft Rucker, ATTN: ATST-T-RTM

I USA Aviation Sch. CO. Ft Rucker, ATTN: ATST-0--A

1 HO. DARCOM. Alexandria. ATTN: AMXCD -TL

1 HO. DARCOM. Alexansdria. ATTN: CDR

I US Military Academy. West Point. ATT'N: Sels ofiltrh

I US Militery Academy. West Point, ATTN: Sero ill nit

I US Militaiy Academy. West Point. ATTN: MAOR

I USA Standaiditation Gp, UK, FPO NY, ATTN: MASE -GC

I Otc of Navel ich. Ar lington, ATTN: Code 452

3 Ofc of Naval Rich. Arlington. ATTN: Code 458

1 Ofc of Naval Rich. Arlington. ATTN: Code 450

1 Ofc of Naval Rich. Arlington, ATTN: Code 441

S I Naival Aerospc Med Res Ith. Pensacola, ATTN; Acous Sets Div

I Naval Aoroslic Med Res Lab. Pensacola, ATTN: Code L11

I Naval Aerospc Med Res Lab, Pensacola, ATTN: Code 15

I Chief of Navrert, ATTN: Pert-OR

1 NAVAIRSTA. Norfolk, ATTN: Safety Ctr

1 Noy Oceanographic. DC. ATTN: Code 6251, Charts & Tech

1 Center ot Naval Anal. ATTN: Boc Ctr

I NavAirSysCom.r ATTN: AIR--5313C

1 Nay BuMed, ATTN: 713

1 NavHellcopserStl qua 2. FPO SF 9660?

1 AFHRL (FT) Williams AFB

1 AFI4RL (TT) Lowry AFS

I AFHRL JAS) WPAFB, OH

2 AFHRL (DOJZ) Brooks AFS

IAFHRL fDOJNj Lack) and AF8

1 HOUSAF (INYSD)

I HQUSAF IOPXXAI

I AFVTG lRB) Randolph AFS

3 AMRL INE) WPAFB, OH

2 AF inst of Tech. WPAFB. OH, ATTN: E NE/SL

1 ATC )XPTDI Randolph AFC

t USAF Aerulled Lib, Bronkt AFS (SUL 4), ATTN: DOC SEC

I AFOSR INI). Arlington

IAF Log Cmrt. McClellanr AFB, ATTN: ALC/DPCRD

1Air Force Academy, CO, ATTN: Dept of Bel Sen

15 NayPert &e Dev Ct, San Diego

2 Navy Mail Neuropsychiatric Ascii Unit, San Diego

1 Niy Electronic Lab. San Dino ATTN: Res Lab

I Nay TrnqCen. San Diego. ATTN: Code 9000.-- Lib

1 NavPostiGraScfi. Monteirey. ATTN: Code 5SAa

1 NasvPistGr*Sch. Monterey. ATTN; Code 2124

1 NdvTcngEquipCtr, Orlando. ATTN, Tech Lib

1 US Dept ot Labor. DC, ATTN: Manpower Admin

I US Dept of Juttice, DC, ATN: Drug Entorce Admin

I Nat Our of Standards, DC. ATTN: Computer Info Section

1 Nat Clewimng House tor MH - Info, Rockville

1 Denver Federal C0r. Lakewood, ATTN: DIM

12 Defense Documentation Center

4 Dir Psych. Army Hq, Russel Ofcs. Canberra

1 Scientific Advir, Mil Dd, Army Hg, Russell Ofcs, 'ranberre

I Mi1 and Air Attache, Austrian Embassy

1 Crntii. de Recherche Des Facteurs, Htsnaine dr fto Defente

Nationale, Brtissels

2 Canadian ,Jowil Stat) Washington

1 CYAir Staff. Royal Cantadian AF. ATIN Pert Std! Ant! Br

3 Chief. Canadian Or) Atch Stall. ATTN: C/CRDS1WI

4 British flef Staff. British Embass. Washington

6-22