command and staff training and the practical use of the … · command and staff training and the...
TRANSCRIPT
Command and Staff Training and the Practical Use of the HLA
John W. OgrenMITRE Corporation
PO Box 3320 Ft. Leavenworth, KS 66027
Keywords:HLA; SIMC4I; Eagle; IBCT; Training.
ABSTRACT: Over the past three years, both the Command & General Staff College and TRADOC Analysis Center atFort Leavenworth, Kansas, along with the TRADOC Army Experiment/Transformation program office have sponsoredmultiple training events using advanced simulations to drive staff training events. The suite of equipment and softwareto drive these events is known as the Digital Leaders Reaction Course (DLRC). The primary objective of the DLRC is totrain the battle staff to leverage the advances in information warfare to win the next war. It provides an environment fortraining leaders on how to visualize the battlespace and make tactical decisions in a time constrained, digitizedenvironment. The challenge is to create this environment in the most cost effective means that will drive the StaffOfficer’s senses such that they feel totally immersed in the on-going battle, making illusion become reality. This paperwill describe this environment, focusing on the use of the High Level Architecture and its importance in facilitating therapid federation of multiple software applications. The context of the paper is the TRADOC Army Transformationinitiative being conducted this fiscal year to develop the Interim Brigade Combat Team (IBCT) Senior Leaders TrainingCourse.
1.0 Introduction
The United States Army’s Training and DoctrineCommand s (TRADOC) Army Experiment (AE) processhas for many years utilized advanced simulations toinvestigate new command and staff training techniques.This year, in line with the Chief of Staff s new thrust totransform the Army into a more agile, responsive force,the Army Experiment Program was changed to the ArmyTransformation Program. Its new focus is to providetraining to the Commanders and principal staff officers ofthe new Brigade Combat Team (BCT) forming at Ft.Lewis, Washington. Simulation technologies and trainingmethodologies developed under the Army ExperimentProgram have been combined and enhanced to provide aportion of this training experience for these officers ofthis new and innovative unit. This paper will focus on thetraining simulation called the Digital Leaders ReactionCourse (DLRC) which was used to drive the capstoneexercise of this BCT Senior Leaders Course (SLC).Specifically, the focus will be on the DLRC simulationarchitecture that is in place and used to support commandand staff training at the Command and General StaffCollege (CGSC) at Fort Leavenworth, Kansas. A fewexamples of previous DLRC based exercises are thecapstone exercises for CGSC advance tactics classes, thetraining of the commander and staff of the 1st Brigade 4th
ID and 1st Brigade, 10th Mountain Division, and theanalytical effort to design the Strike Force headquarters.The flow of information and technical aspects of the HighLevel Architecture (HLA) Federation of Simulations andSimulation to C4I interfaces used to support the trainingof the BCT will be also discussed.
2.0 BCT Senior Leaders Course Objectives
The BCT Senior Leaders Course (SLC) was a forum forthe Army s Training Community to provide an intenseindoctrination of the key operating principals and doctrineof the evolving Operation and Organization Plan to theBrigade Combat Team’s principal commanders and staff.It lasted approximately five weeks and was conducted atForts Lee, Huachuca, Knox, Benning, and Leavenworth.A Kosovo "road to war" tactical scenario was used as acommon thread for all instruction. The course culminatedat Fort Leavenworth, with a simulation driven exerciseusing the DLRC. The exercise was conducted in twophases. The first was a week long exercise (8 - 18 May),conducted as a capstone exercise for the Command andGeneral Staff A311, advanced tactics class. The generalscenarios envisioned for the final exercise were tested andstudents played the command and staff positions of theBCT units. Extensive after action reviews were conductednot only on the performance of the students in fighting the
battle, but also on the scenario designs and the flow ofinformation to the staff sections through the C4Iequipment. The second Phase, was the actual participationof the BCT command and staff in the DLRC on 21through 25 August.
3.0 Digital Leaders Reaction CourseArchitecture
The primary objective of the DLRC is to train a battlestaff to leverage the advances in information warfare towin the next war. It provides an environment for trainingleaders on how to visualize the battle space and maketactical decisions in a time constrained, digitizedenvironment.
To create this environment, the DLRC combines severalsimulations and interfaces them to the following fieldedTactical Command and Control systems: the ManeuverControl System (MCS), the Advanced Field ArtilleryTactical Data System (AFTADS), the All Source AnalysisSystem (ASAS), the Combat Service and Support ControlSystem (CSSCS) and the Air and Missile Defense WorkStation (AMDWS). The core simulation used to drive theDLRC is the Eagle Combat Model. This model combinestechniques normally associated with artificial intelligencefor representing command and control decision makingand classic algorithmic solutions for representing thephysical dynamics of the battlefield. The model representscommanders and staff sections at each level of a tacticalmilitary operation, all performing battle managementtasks based on Operations Orders, driven by combatmessage traffic being passed up and down the chain ofcommand. The DLRC leverages this design by divestingthe cognitive processing of selected simulatedcommanders and staff sections to the live commander andstaff players that are being trained; all other commands,including the enemy, remain in the simulation. The Eaglesimulation allows for dynamic two-way interactionbetween the live staff players and the simulatedsubordinate and superior headquarters in the model.Information is passed to the live players through their C4Iequipment and simulated radio traffic allowing the staffofficers see and hear the battle. Their equipment has beenmodified to allow the staff to communicate directives andrequests to fight the battle to their simulated superiors andsubordinates. The staff can also view the battlefield usinga 3-dimensional viewer made possible by a uniqueprocess that allows disaggregation of the Eagle combatunits into the Distributed Interactive Simulation (DIS)environment. By allowing Eagle s simulated commandsto play those units that are not directly being played bythe live training audience, the normally required supportstaff and personnel are significantly reduced. The DLRCcreates an environment that drives the participant s senses
so that they feel totally immersed in the ongoing battle,yet requires few if any role players and support staff.
Includes a HLA Federation and DIS Interface.
ASAS
1way1way
CMD RADIO
1way
UAV1way 2way1way
ModSAF/SIU
AFATDS
MCS
2way
2way
1wayAMDWS
1way
CSSCS
1way
EAGLE COMBATSIMULATION
1way
INTELGEN 1way
1 way
AAR
HLA - RTIDIS
Figure 1
Figure 1 shows the overall architecture of the DLRC. Allcombat modeling is done in the Eagle simulation. Itoutputs information directly to the staff by stimulating theC4I interfaces and simulated tactical radio via the HLARTI. Selected C4I devices have been modified to provideinformation back to the combat simulation. Eagle alsoprovides information to the After Action Review (AAR)system via the HLA. Eagle outputs sensor informationfrom simulated airborne intelligence gathering assets tothe Intelligence Message Generator (INTEL GEN). TheINTEL GEN accumulates sensor information andprovides intelligence information via the HLA to theASAS. The Eagle simulation also provides unitinformation to the Modular Semi-Automated Forces(ModSAF) Simulation Interface Unit (SIU). The SIUgenerates entity information based on the units and theirformations to drive the simulated video downlink fromthe Unmanned Aerial Vehicle (UAV). Consequently, theUAV can view the Eagle aggregate battle as individualvehicles. The SIU also generates the air track broadcastmessage from simulated airborne sensors to the AMDWS.
We will now take a close look at each element of thisdesign and how we embed the Commander and his staffinto the battlefield using this architecture.
4.0 Eagle Combat Simulation
Eagle was developed in the late 1980 s as a vehicle toinvestigate the application of artificial intelligence toexplicitly model command and control in a combatsimulation. The model s typical combat functionality(such as attrition adjudication) relies on the extensive
DLRC Architecture
combat modeling experience at TRADOC AnalysisCenter (TRAC) and is rooted in standard, validatedalgorithms. The model is categorized as a constructive,aggregate Corps level model with normal resolution tocompany size units. Eagle uses a hybrid event structurethat relies on both the notion of continuous time usingtime steps (1 to 5 min.) and the projecting of specialdiscrete events (such as TBM launches or the penetrationof air defense domes by fixed wing aircraft) at momentsbetween the time steps.
Eagle’s architecture is built on the object-orientedprogramming paradigm. This paradigm is based on aphilosophic focus of data grouped into objects acting onother objects, rather than on the traditional focus onprocesses which act on data.
The data or knowledge representation reflects the uniquerequirements of the military domain. Eagle’s knowledgerepresentation conforms to the user’s understanding of theproblem space in three main areas. First, military units,weapon systems, and munitions are defined as objects.Second, terrain is represented as a network of mobilitycorridors each of which are objects. Third, plans arerepresented in standard five-paragraph field order format,so that the user can specify orders to units in a mission-oriented manner.
Simulated command posts respond to these orders byaccessing its domain knowledge executing the mission asdirected. Decisions are made by the software commanderand the information or directives are passed up and downthe chain of command. This flow of information betweencommand posts (software objects) is very important,because the actions of the units are not scripted based ontime, but occur based on events that cause commanders togive their approval to execute the next portion of the plan.A software commander’s perception of the battlefield isbased solely on what his subordinates and the intelligencesystem are telling him and how it relates to thecommand’s battle plan.
Eagle portrays ground maneuver, attack and lifthelicopters, field artillery, air defense, air and groundintelligence units, engineer units and logistics units. Theprimary emphasis is on Army units and capabilities, yetEagle also plays air force air assets used in support ofground operations. This design has proven to be veryflexible and quite adaptive to the needs of the DLRC.
5.0 Simulation Interfaces to the Army BattleCommand (ABCS) Equipment
As indicated in the description of the combat model Eagleand shown in figure 2, simulated units in Eagle belong to
a tactical organization and communicate with each otherthrough a simulated communications network. Each unit scommunication requirements (defined as the type ofinformation, destination and time to send) is explicitlyrepresented in the unit’s Standard Operating Procedures(SOP). Approximately 25 different message types aredefined within Eagle and each has its own definition ofwhen the message should be sent, who should receive itand content and format. For example in figure 2, TaskForce 23 is sending a maneuver status message to itshigher headquarters. The message is sent based on theconditional that it is to be sent every 10 minutes if one ofits elements has changed. In this case the direct fireintensity that the unit is experiencing has increased toheavy , so the simulated staff forms the message and
sends it on to 1st Brigade. Information flow is controlledwithin Eagle by a communications manager that can delayor prevent a message from being sent based on the groundtruth characteristics of the two units that are trying tocommunicate.
Units have ~25 separate typemessages they pass. Ex: BML Loc. msg = USMTF S507L
TF 23 sends ManeuverMSG to 1_BDE:DTG: 130600REL: ClosingTYPE: Final ObjOBJ: Obj BlueENEMY: YesDF INTENSITY: HeavyIDF INTENSITY: LightAIR INTENSITY: NoneEFF: Marginally Eff.
Simulated Units communicate withhigher and lower units on simulatedradio networks using explicit message types. 1. Command (CMD) NET 2. Fire Support NET
X
XX
I I I I
I I
Company CMD NetCompany FSE Net
Brigade CMD NetBrigade FSE Net
Division CMD NetDivision FSE Net
TF23
1_BDE
EXAMPLE
Figure 2
Messages arrive at the headquarters and are placed in theunit s journals so that rule sets/procedures that representthe various staff officers can use the information in theautomated execution process. However, for thosecommands whose commander and staff are being playedby actual people, information is further sent out to the C4Iequipment associated with that command. Figure 3 showsthis process. In this case, 1st Brigade s TacticalOperations Center (TOC) is being played by real staffofficers. The 1st Brigade TOC also exists in the Eaglemodel. The Software Object that represents thisheadquarters has both physical and cognitive capabilities.
Eagle Tactical Communications
Divest Cognitive Capability
Acquire
AssessDecide
Direct
Normal Commo
X1BDE
Bn s Report Status &receives Orders
Command Unithas
Physical andCognitive
Capabilities
TurnedOff
Information to C4I equip.
Staff Assesses Info. &sends Info. & Directives
to Subordinates
ALL information providedto Staff & ALL directives
are saved for Analysis.
Disk
C4I Displays EagleStatus/Respond
C4I Equip(Amount of
Interaction varieswith type of Equip.)
Live 1st BDE Staff
Figure 3
The 1st Brigade TAC CP in Eagle consists of vehicles thatmove around the battlefield and may have weaponsystems associated with it (such as Air DefenseElements). These physical parts (plus the cognitiveprocesses to make them functional) remain in thesimulation. However, the cognitive processes of thecommander and staff in pursuing the ongoing battle andplanning for the next have been "turned off" andsuperceded by procedures that will send and receiveinformation from the live players. The cognitivecapabilities have been divested to the live players.
As shown in figure 3, Eagle units execute a very simpledecision process. They acquire information, assess it,decide what to do, and then direct units to execute (orrequest information). For those simulated units whosecognitive processes have been turned off, only the assessand decide processes have been overridden. Informationarrives at the simulated TOC and is both saved in thesimulated unit’s journals and sent out to the live staff.Staff officers make decisions and that information is sentback to the simulated TOC in Eagle. The decision isreformatted into a structure that makes it look like thesimulated 1st Brigade Commander made the decision.Again it is logged in the appropriate journals and thensent out. All information in and out of the simulated unitcan be saved for later analysis. Additionally, thisarchitecture allows the flexibility to dynamically turnback on the Eagle Commander’s cognitive processesduring the simulation run. In this case the simulated staffcan pick up the battle based on the message logs. In shortthey know how they got where they are and the plans andoperations they are executing.
Information arriving at those headquarters whosecognitive processes have been divested, must make adecision as to how the information will be delivered to the
actual staff officers. The basic communicationsfoundation for all information flow between the Staffofficers and the units in Eagle is the High LevelArchitecture (HLA). However which C4I device todeliver information to and in what form to deliver thatinformation is controlled by Eagle initialization tables.These tables are tailored for each exercise based on thestaff officer roles being played and the amount ofheadquarters live support personnel available. Theavailable generic type interfaces (shown in figure 4)developed as part of the DLRC are:
1. A direct Data Based input process for the ManeuverControl System. This process developed as a prototypefor a future interface to the Joint Common Data Based(JCDB) allows Eagle to input information directly into theMCS databases replicating the processes used by thenormal e-mail process.
2. A USMTF e-mail process that allows delivery of theinformation via the HLA to the C4I device, then form upan arriving message and locally insert it into the arrivinge-mail message queue.
3. A TACFIRE interface process that allows delivery ofTACFIRE formatted messages to the AFATDS.
Message arrives atsimulated Command
Msg is logged inIF Msg Type = :loc
Send 507L or Eqv.IF Msg Type = :log
Send 507S or Eqv.etc.
EAGLE
InterfaceOptions
AFADTS
ASAS
MCS
CSSCS
AMDWS
EMAIL - USMTF
EMAIL USMTF
TACFIRE
EMAIL USMTF
DIRECT DATA BASE UPDATE
PROTOTYPE FOR** JCDB **
Battle Staff receivesrequired informationto assess & fight
2way
Figure 4
For example, a location message arrives at the divestedCP from an Artillery Unit. Based on the SOP, theinformation will be sent to the TOC Operations MCS as adirect database update, to the assistant Intelligence Officerat ASAS station number two as a USMTF S507L, and tothe TOC FSO at the TOC AFATDS as a TACFIRE unitupdate. If Eagle is playing the TOC enlisted staff, then thelocation message may be directed to other MCS s withinthe same TOC and to the higher HQ, replicating the staff’snormal operations of forwarding information. The goal is
SIMC4I Interface Concept
Information Transfer Options
to allow the principal staff officers to focus on thefighting of the battle, not the mechanics of using aparticular computer.
Figure 5 shows the headquarters and staff positions thatwere divested for the BCT SLC exercise.
ARFOR HQ: Small Staff (6 Officers) to control ARFORcontrolled forces such as the 4th Infantry Division.
OPFOR: Controllers (3 Officers) to control 6 EnemyBrigades size units
BCT Main TOC: All primary and assistant Staff Officerpositions were played
BCT TAC: Commander and all primary Staff Officerpositions were played
Reconnaissance, Surveillance, Target AcquisitionSquadron (RSTA) TAC: Commander and Operations,Intelligence and Fire Support (FSO) Officer positionsplayed
Forward Support Battalion (FSB) Operations: Operations,Logistics, and Intelligence Officer positions were played
O O O
HHC
4 X 120mm
O O OO O O
O O O
2 X 81mm
MGS
SUPPORT
HHC FSB
2 X 120mm
MI
XX(-)
1
ARFOR
(-)
TSCX
IB
X
XXX
1
X X
Majority TaskOrganized down
to Brigades
XX
30MM SPM53
20MM (T)M55
T-55
X
M-80/60
Small Control Staff
BCT TOC STAFFBCT TAC STAFF
RSTA TAC STAFF
ALOC STAFF
Small Control Staff
Figure 5
All other units were played in the simulation, includingthe staff positions at the subordinate battalions that werenot divested. For example the BCT TOC staff may issue aFRAG Order to the 1st Battalion. The simulated 1stBattalion s staff determines the actions of the subordinatecompanies and issues orders. Where as, if the BCT TOCStaff issued a FRAG Order to the RSTA Battalion, theactual staff officers would receive the message and theywould have to plan for their subordinates and issue theorders to the companies. This automation of the unit’s
planning process and the direct flow of informationbetween live players and the simulated units, is the key tothe low overhead characteristic of the DLRC.
6.0 Tactical flow of information
Regardless of the technical merits of the C4I design,unless the simulation and interfaces can get the rightinformation to the right people in a form that is normallyexpected, it is of little value as a training tool. The DLRCattempts to immerse the staff into his environment,stimulating as many of the human senses as possible. Theflow of information is two way.
6.1 Information to the Staff
To create this environment, the DLRC not only deliversinformation to the C4I systems associated with each staffsection, but also delivers information verbally thoughsimulated radios that are monitoring the units commandnet traffic within the simulation and visually through athree dimensional (3D) stealth that is simulating the videodown-link from the unit s UAV. The following is a list ofthe C4I devices and the information sent to them.
6.1.1 To Maneuver Control System (MCS)
Direct Data Base update of friendly situation reportinformation consisting of unit location, effectiveness, andgeneral status information such as speed. Data wouldnormally be from S507L and S302 USMTF messages.
Direct Data Base update of enemy spot report informationconsisting of unit location, estimated effectiveness, andgeneral estimates on the unit’s activities. Data wouldnormally be from S309 USMTF message
Direct Data Base update of a subordinate unit s routeswhen moving. Data would normally be from S301USMTF message.
Direct Data Base creation of a new unit. Used to displayenemy units and friendly units with no UIC in MCS taskOrganization.
Free text Messages - USMTF S302 for general statusinformation.
Unit Orders - USMTF 432 for orders from higher unitssimulated or live when using DLRC communicationsrather than direct e-mail.
BCT SLC Divested Headquarters
6.1.2 To All Source Analysis System (ASAS)
Friendly Locations - USMTF S507L for designated unitsin Task Organization.
TACREP - C111 for enemy spot report information fromhigher and lower units
INTREP - C110 for enemy Humint Information
TACELINT - C131 for information generated fromcommunications and signal sensors.
IPRR/IIR - C100 for information generated from photoand moving target sensors.
6.1.3 To Combat Service Support Control System(CSSCS)
CSSCS database message ASSET7/ UPDATE7 to updatea unit s class 7 (major systems) status. All CSSCS database messages are embedded in a USMTF S302 anddelivered via e-mail.
CSSCS database message ASSET3/CS3-001 to update aunit’s class 3 (Fuel) status.
CSSCS database message ASSET5/UPDATE5 to updatea unit’s class 5 (Ammo) status.
CSSCS database message ASSETP/UPDATEP to updatea unit’s personnel status.
CSSCS database message Battle Damage Report toinform higher of a unit s battle damage.
CSSCS database message Critical Movement Report toinform the Staff of all convoys on the road.
Free Text Message - S302 to inform Staff on unit supplyrequest and convoy requests and general Supply Unitinformation.
6.1.4 To Army Field Artillery Tactical Data System(AFATDS)
TACFIRE AFU Fire Unit Update to update unit locations.
TACFIRE AFU Ammo Report to update ammunitionstatus of a unit.
TACFIRE CFF Call for Fire to request a artillery mission.
TACFIRE MFR Mission Fired Report for end of missiondata from firing battery.
TACFIRE CDR Coordinate Report to notify FSO oftargets being fired in area.
Free Text Message - S302 to inform Staff of firing batteryinformation, target history information and detailed battledamage reports
6.1.5 To Air and Missile Defense Workstation(AMDWS)
Friendly Locations - USMTF S507L for designated ADAunits in Task Organization.
Air Warning Alerts - USMTF E500 from ADA unitsdetecting inbound enemy aircraft.
Free Text Messages USMTF S302 to inform unit of ADABattery status, targeting and Battle Damage reports onfirings.
Air Tracks - F3 from airborne sensors of all air unitsflying in area of operations.
6.1.6 To Simulated Tactical Radio
Simulated units within eagle report their status in amultitude of message types. These messages arestructured with commander decision informationassociated with a commander’s critical informationrequirements. A unit does not report that it is 1.456777kilometers from an object, but that it is closing on hisobjective. In this case the variable name is relationship tothe objective and the possible values based on the SOPare: at, closing, approaching .. . There are approximately50 of these variables, with groups of them associated witha message type. When a message arrives at a divestedheadquarters, the information is always delivered to thelive players as indicated previously. If the unit has asimulated radio, the information is also delivered as aradio message. Each unit within the task organization hasa unique radio voice. Unit designations can be based on aCommunication, Electronic Operations Instruction(CEOI) with call signs varying base on the CEOI, orabbreviated unit names can be used. The following is atypical status message: BCT this is 2 nd Battalion, we areclosing on our final objective, in contact with the enemy,currently effective with 96% equipment. Alpha companyis in contact with 2 enemy units, receiving light indirectfires and medium direct fires, and is reporting an amberstatus, Bravo .. . Over 30 type reports tailored for eachunique situation can be generated. No reports are scripted,all are formed dynamically within Eagle based on thecurrent situation.
6.1.7 To Simulated Video Down Link from UnmannedAerial Vehicle (UAV)
To provide a 3-dimensional look at the battlefield, theDLRC has included a stealth display that can be attachedto any vehicle within the unit. For the BCT this was asimulated video down link from the unit’s two flyingUAVs. Eagle has an extensive interface with a highlymodified ModSAF program that allows Eagle to displayits aggregate units in an entity state. The entities aredynamically created by this interface based on statusmessages from Eagle. They have minimal functionality,in that they will dead reckon, but will not fire or detectother entities (although their counterpart in Eaglemaintains these capabilities). All resolution of combat isdone in Eagle. When entities are killed, ModSAF isnotified and entities will be displayed burning andeventually displayed as dead. When simulated Eagleartillery units fire, the impact of the rounds will bedisplayed. Entities are templated into the ModSAFenvironment based on the operational activity of the unitthey are associated with.
Staff Officers monitoring the Stealth, will see realisticunit formations conducting their normal combatoperations. The stealth display used for the exerciseallows the user to vary the picture between day TV andFLIR, zoom to narrow focus on an area, and designate thecoordinates of a location.
6.2 Information from the Staff
Up to this point, we have focused on the information thatis sent to the staff officers. However, for the DLRC to betruly low overhead , a means must be provided to allowthe staff to communicate directly back to his subordinateunits without the intervention of role players orpucksters . The DLRC has accomplished this with two
two-way interfaces through the MCS and AFATDS.
6.2.1 From the Maneuver Control System
As shown in figure 6, the map application on the MCShas been modified to provide a new menu choice thatallows the staff to issue directives and requests directly totheir subordinate units. The notion is the same as thestandard MCS auto-fill capability provided by themessage processor for sending unit locations. The Staffofficer can select a unit on the map, activate the menu,then fill in a standard template of information and sendthe message. In essence the staff officer is sending ahighly structure message back to the unit in the simulationvia e-mail. Figure 6 shows the basic menu with asubmenu used for issuing a FRAG order to a unit. Othergeneral functionality allowed is:
Requesting detailed unit status information.
Requesting Artillery firing summary information for thepast 30 minutes.
Issuing FRAG Orders. These can include multiple Tasksand be on-order.
Map Application is modifiedto provide structuredorders/directivesto units in simulation.
Eagle
UnitStatus
OrdersDirectives
Figure 6
Create an Artillery Fire Schedule
Change Fire Support Priorities
Issue tasking to Engineer units to breach or createobstacles.
Request Air Force support.
Request Artillery FASCAM missions
Simple Fire Mission requests.
Request supplies from higher HQ or issue supplies tosubordinates.
6.2.1 From Army Field Artillery Tactical Data System
The second two-way interface is through the AFTADS.Figure 7 shows the typical flow of a call for fireoriginating from an forward observer in a simulatedcombat unit. Eagle and its associated TACFIRE interfaceallow for the normal flow of targeting information to theFire Support Officer (FSO) using the AFATDS. The FSOcan use the automated unit selection process of theAFTADS to designated the firing unit for every artillerymission. The call for fire is then forwarded to thesimulated Artillery unit, where the mission is fired. The
Information From MCS to Simulation
mission is closed out with a Mission Fire Report returnedto the AFATDS.
O O O
O O O
Call forfire
EagleEFF
TacFireCFF
Receivessends CFF
AFATDS Processesdetermines Firing Unit
Sends CFF/MTO
ReceivesCFF sends
TacFireCFF
EagleCFF
ACK
TacFireMTO
ReceivesCFF sends
ACK
O O O
Call forfire
Designated FA Unitfires Mission
O O OEOM
EagleMFR
Receivessends Ammo
Receivessends MFR
TacFireMFR
TacFireAFU
Ammo
ProcessProcessTgt. Update
EagleAmmo
The Fire Support Element in Eagle is turned off and all processing must be done by the Staff using the AFATDS
Figure 7
6.3 Information flow summary
The combination of the information flow to the staffofficers and the allowed functionality to return directivesand orders has been very effective in allowing a costeffective solution to the training of units with their C4Iequipment. Figure 8 shows the 29 available messagetypes used in a typical DLRC exercise.
¥ SUMMARY OF MESSAGE TYPES—TACFIRE -- 5 Formats used
¥ AFU.FU, AFU.AR, AFU.MFR, AFU.CDR, FM.CFF.—USMTF -- 9 Formats used
¥ S302, C111, S507R, S507L, E500, A432, C110, C121, C100—CSSCS -- 9 Formats used
¥ ASSET7, UPDATE7, ASSET3, CS3-001, ASSET5, UPDATE5,ASSETP, BTL DAMAGE, CRT MOVEMENT
—FDL -- 1 Format used¥ F3
—MCS SADS Data Base Update -- 5 Formats used¥ Create Unit, Update Friendly Unit, Update Enemy Unit, Create
Graphic, Update Resources
Eagle generates 29 differentMessage types
Figure 8
7.0 HLA Run Time Interface (RTI)Federation
Up to this point we have focused on the tactical flow ofinformation and the functionality of the combatsimulation and C4I devices. The underlying structure thatholds these two elements together and makes the DLRCfunctional is the High Level Architecture.
7.1 C2HLA federation object model
The HLA was used to generate our C2HLA BCT SLCfederation. This federation consisted of seven differenttype federates as shown in figure 9 and described below.
COMBATSIM.
EagleAfter Action
Review Interface toC4I Systems(USMTF/DB)
IntelligenceGenerator(Sensor)
Interface toAFTDS(Tacfire)
SimulatedRadio
(Cmd Net)
RTI
The C2HLA BCT SLC Federationconsisted of 6 different types
of federates.
Figure 9
Eagle Federate: The combat simulation.
Intel Federate: The intelligence generator receivedintelligence sensing information directly from Eagle,processed the information as an intelligence interpreter,generated the appropriate USMTF message and sent theinformation out to the designated ASAS.
AAR Federate: The Eagle after action review process.This federate captured all ground truth information fromthe combat simulation to include locations, tasks,equipment status, direct and indirect firings. It alsocaptured all information coming from the live StaffOfficers to the simulation
C4I Federate: The basic interface to the C4I deviceswhich allows for the direct data base updates to the MCSand USMTF message delivery to the message processorson all C4I devices. This interface is a two-way interfaceon the MCS which also allows for the return ofinformation from the Staff Officer to the simulation.
TACFIRE Federate: The basic interface to the AFATDSfor the delivery of TACFIRE Messages. This interface is
Information From AFATDS to Simulation
Summary of Message Types
Types of Federates in Federation
also a two-way interface allowing for call for fires to besent to designated artillery units.
Radio Federate: The interface to the speech synthesizerwhich was the simulated radio at each of the commandposts.
OBJECTS EAGLE AAR C4I INTELGEN.
TACFIRE
RADIO
Ground Maneuver P SAIR Maneuver P SFix Wing P S
Basic HLA Compliant FederationDISTRIBUTED EAGLE
extended for BCT SLC.(Multiple Eagles were not necessary)
RTI Version 1.3 NG version 3
3 Object Class defined47 Attributes defined for Ground Maneuver & Air Maneuver Classes
45 Attributes defined for Fix Wing Class
P: Publish/ S: Subscribe
Figure 10
The basic HLA compliant federation used wasDISTRIBUTED EAGLE (Nov 1998). It was extended forthis exercise by including the previously describedfederates and upgraded to use RTI Version 1.3 NGversion 3. The size of the exercise did not require the useof multiple Eagle federates; however, the one Eaglefederate did assume that multiple Eagles were presentbecause all objects were required by the AAR to maintainground truth information for the after action reviewprocess. Figure 10 shows the class objects that weredefined. Forty-seven attributes were defined for theground maneuver and air maneuver classes. Forty-fiveattributes were defined for the fix wing class. Allattributes were time stamped ordered and reliabledelivery.
Figure 11 shows the seventeen interaction classes that areused in a DLRC exercise. Actually the federationdeclaration file (fed file) included thirty-seven interactionclasses. The twenty additional interactions are associatedwith distributed Eagle. All seventeen interactions were:receive order, reliable delivery. Basically, the followinginteractions were associated with each type federate:
AAR: 3 interactions to notify the AAR process of allfirings and when Eagle made time advance requests.
RADIO: 1 interaction to deliver the string text which wasthen parsed through the speech synthesizer.
C4I: 7 interactions to deliver and receive informationfrom the C4I devices. Unique interactions were definedfor each type of MCS data base call. However, allUSMTF messages were formatted at EAGLE and onlyone interaction was used to deliver the e-mail traffic to theC4I devices. The type of USMTF message was anattribute of the interaction.
INTERACTIONS EAGLE AAR C4I INTELGEN
TACFIRE
RADIO
AAR DF Attrition P SAAR IDF Attrition P SAAR Current Time P SVoice P SNew Unit P SResource Updates P SFriendly Sit. Updates P SEnemy Sit. Updates P SGraphic P SUSMTF Messages P S PMcs Messages S S PTacFire Update P STacFire Ammo P STacFire MFR P STacFire CDR P STacFire CFF S PTacFire -EFF (CFF) P S
17 Interaction Classes defined (37 with Distributed Eagle)
Figure 11
TACFIRE: six interactions to deliver and receiveinformation from the AFATDS.
7.2 C2HLA federation design
The DLRC federation is normally organized into groupsthat are generally associated with a particular networksegment and TOC configuration.
C4I systems:7 - ASAS19 - MCS4 - AFATDS4 - CSSCS2 - AMDWS
RTI
SIMCELL& RTI EXECFEDEX
3RTIFED
ARFORCELL
2RTIFED
BCTTOC
MAIN
5RTIFED
BCTSUPT/ALOC
4RTIFED
BCTTAC
4RTIFED
RSTA
4RTIFED
OPFOR
1RTIFED
23 Federates in Federation to drive 36 C4I systems in 7 Cells
Federate Types:1 - Eagle - Combat Simulation1 - AAR - After Action Review1 - INTEL GEN - Intelligence Generator3 - TACFIRE - AFATDS Tacfire Interface13 - C4I - USMTF & Data Base Interface
4 - RADIOS - Simulated Radio Interface
Figure 12
Federation Object ModelFederation Object Model
BCT SLC Federation
In the BCT exercise, three network segments wereavailable. Two were dedicated to the tactical network andone to the simulation network. As shown in figure 12 atotal of 23 federates were used in the C2HLA BCT SLCfederation.
The RTI executive, federation execution, Eagle, the IntelGenerator, and the AAR were running on the simulationnetwork. The largest traffic producers were the ModSAFsthat were also running on this network. The only Staffinterfaces on the simulation network were the Stealths.The C4I networks were protected from this ModSAFtraffic because there was no multicast between segments.
The remaining groupings are organized based on thetactical operation lay out of the designated command post.Figure 13 shows the BCT Main TOC federationconfiguration. An important element of the DLRC designis that a single C4I interface can provide interfaces formultiple C4I devices. In this case there are 11 C4I devicesbeing serviced by four federates (five when including theRadio) running on three separate computers. The actualdesign of the number of interface machines and numberof federates required is a trial and error process in thesetting up of the exercise. Typically federates are added ormoved based on the actual flow of information as itevolves during the exercise. Overall, for this experiment,there were 23 federates driving 36 C4I devices and fourradios in seven cells over two network segments. It shouldbe noted that normally an exercise of this type would havehad seven separate network segments, however they werenot available on the local area network.
3 Computers were dedicated to drive TOC Interfaces
RTI
C4I C4I C4I Radio TACFIRE5 Federates wereused to transfer
information
MCS
MCS
AMDWS
CSSCS
MCSMCS
MCS
AFATDS
ASASASAS
ASAS
Multiple Federates run on same computer.Single Federate provides interface for multiple C4I
11 C4I devices provided information to Staff
Speech SynthesisSoftware ran on computer - voice
output to speakers
Figure 12
7.3 C2HLA federation data distribution management
The constraining of the amount of information flowing tothe C4I federates is of prime importance. To manage thisinformation flow two process are used. First, as statedpreviously a single federate can service multiple C4Idevices. To identify a unique C4I device a role is assignedto the device. The DLRC process that runs on the C4Idevice, identifies itself to the C4I federate with this role.The C4I federate maintains a list of those roles that areattached to it. Each interaction that the C4I federatesubscribes to has a parameter to . Eagle maintains a listof these roles and tables that identify message types withparticular roles. These tables are set up based on thedesired flow of information. Eagle will identify themessage with this role in the to parameter. When theC4I federate receives the interaction it will extract theto parameter and send the message on to the DLRC
process running on the appropriate C4I machine. If thesame information is always to be delivered to a group ofmachines attached to the same federate, then they all canhave the same role and the C4I federate will send thesingle RTI message to multiple C4I devices. Second, theHLA data distribution management process of creatingrouting spaces is used. In this case, all C4I and Radiofederates had unique routing spaces. The routing spacedefined was Info_Link which had 17 regions each definedby a point on a linear scale. By using the routing space,information addressed to a C4I federate could be sentdirectly to the one federate needing the information,rather than to all 13 other C4I federates. Eagle maintainedtables that identified C4I device roles with designatedrouting spaces. Through both these constrainingtechniques, network traffic was kept at a minimum. Thisis very important on the tactical networks, where thesimulation traffic is sharing the network capacity with thetactical traffic, and the tactical network traffic haspriority.
MCS
RTI InterfaceWorkstation
INT. PROCESS
FED PROCESS
C4I FederateEagle Combat
Simulation
FED PROCESS
MCS
Federation control workstation #2
Federation control workstation #1
C4I Federate
Figure 13
BCT Main TOC Configuration
C4I Interface Summary
In summary, the DLRC through processes running onmultiple machines manages the information flow toguarantee that the required information gets to therequired C4I device. Figure 14 shows this configuration.For the interfaces associated with the C4I devices thisentailed creating 20 federate processes over 10 machinesand 36 DLRC processes running on the actual 36 C4Idevices. This DLRC process provides the ability to inputinformation into the database or place information on thedevice s e-mail message queue. To manage these multipleprocesses, scripts are developed that allows one person tostart up and monitor all processes from two controlmachines in the simulation cell. The general flow ofinformation can be monitored and as C4I devices fail,color coded windows allow for the quick identification ofproblem machines and the appropriate recoveryprocedures can quickly be initiated.
8.0 Message flow statistics and observations
The actual experiment lasted for approximately sevendays including two days of familiarization with theequipment and interfaces. During the training period fiveseparate scenarios were available for exercising the staffs.The following message traffic statistics were generated onthe fifth day of the preliminary exercise in a "movementto contact" scenario where both the Blue and Red forceswere moving to engagement.
This scenario lasted a little over five hours and figure 15shows the number of object updates and interactions thatEagle sent and received. Eagle initially instantiated 470combat unit objects. This number increased toapproximately 600 during the simulation run due to userinitiated tasks that required logistics convoys, engineerteams or airforce flights to be created. Figure 15 showsthe number of messages sent to each major Blue TOC cellby C4I device. Including the object and interactionupdates, Eagle was sending approximately 500 messagesper minute over the RTI. All this traffic was reliabledelivery. The total number of interactions received byEagle from the C4I devices issuing orders or requestinginformation was 1042. The network load was never afactor in this experiment. Probably the most importantfactor that the DLRC had to deal with when interfacingwith C4I devices is the number and rate of arrival ofmessages to the devices. It is very easy for the Eaglecombat simulation to literally flood a device with so manymessages that the device becomes completely unusable.During this exercise the various machines had no problemwith the rate of messages. The CSSCS figure ismisleading in that all units had a cycle that they reportedlogistics information, so their messages tended to arrive ingroups. The interesting statistic is the rate of messagessent to the MCS. This is a high number and wouldprobably have had a significant impact on the computer, if
they were all e-mail traffic; however this is not the casefor the DLRC interface. The primary input to the MCSwas data base updates which required significantly lessprocessing compared to parsing e-mail traffic. Reliable,timely information could be sent to the MCS because ofthe unique interface which replicates the generalfunctionality available with the new ABCS Block 6xdevices using the Joint Command Data Base.
• Typical Exercise - Defense - 5 hrs 12 min combat• Total Object Updates - 32,559 ~ 105 Obj/Min.• Total Interactions OUT
– To Staff Interface Equipment: 95,402– To AAR: 14,855– Total with Distributed Eagle: 112,906 ~ 362 Int/Min
• Total Interactions from the Staff to Eagle: 1042• Interactions sent to each Cell by BFA:
Does not includestaff initiated email
between C4I devices
0
1000
2000
3000
4000
5000
6000
# Msgs
RSTA TAC TOC ARFOR
MCS ~ 18 Msg/MinASAS ~ 6 Msg/MinAFATDS ~ 4 Msg/MinAMDEWS ~ 2 Msg/inCSSCS ~ 2 Msg/MinRADIO ~ 4 Msg/Min
(18,957) (8,991) (27,074) (8,142)
Figure 14
9.0 Observations and direct for future.
The DLRC has been proven to be an effective means toconduct training for commanders and staff using theirABCS equipment. The flexibility of the simulation andinterfaces lends themselves to react to the unique needs ofa particular experiment or training session. The quick turnaround of resetting the simulation and interface devices toallow for multiple runs of the same scenario vignettes onthe same day, has been very complimentary to theAdaptive Training Methodology used by the college.Exercises are typically run training on a single CombinedArms Event such as "Conduct a Movement to Contact".Mentors provide oversight and if the staff is missing theobjective of the current training session, then a quickAAR can be conducted and the simulation and C4Idevices reset to try again. This continual replaying ofsame vignettes until the training objectives are met is oneof the single most important aspects of this environment.The students don’t leave until they get it right.
The DLRC is typically used in this quick turn around,intense environment. However, it can also be used for alarge continual staff exercise that lasts for weeks. TheStrike Force exercise was an example of this continualtype of exercise. This exercise lasted approximately twoweeks using the same scenario. The simulation was reset
Message Traffic Analysis
each day from a checkpoint that had been conducted theprior evening. Over sixty hours of simulation time wasplayed driving over 64 C4I devices, spread over fourclassrooms, keeping approximately 60 staff officers busy.
The key architecture parts of this environment areconstantly being modified and enhanced. The following isa summary of the direction that the DLRC is proceedingfor the future.
Eagle: The Eagle combat model has extensive capabilitiesthat at present can not be leveraged by the live staff. Acontinual challenge is to determine how this functionalitycan be made available for the use of staff officers. Alsoduring each exercise, the expertise of the students isleveraged and their knowledge is used to enhance Eagle.This is especially true for the embedded doctrine ofoperational tactics and techniques that the automated unitsuse to execute missions from the live players.Additionally, the re-hosting of the Eagle software on a PCis actively being pursued, which will provide a lowerfootprint for the simulation and more flexibility to theusing community.
ModSAF: The detailed terrain resolution and entityrepresentation of the units has undergone extensiverevision over the life of the DLRC. More advancedstealths have been used to give a better picture. Providingfor the display of burning and destroyed vehicles hasinjected more realism. The DLRC is currently looking atenhancing the SIU by using a version of Joint SAF or, asit comes available, One SAF.
HLA: The HLA has proven to be a successfulunderpinning of this endeavor. It is flexible in itsapproach and has allowed for the easy integration offederates into this environment. Although not a part of theBCT SLC, the DLRC has an interface to the Force BattleCommand Brigade and Below (FBCB2). This connectionwas made available with an HLA interface to a simulationinterface call Situational Awareness Tactical Internet DataServer (SATIDS). The integration of SATIDS and Eagletook little or no time and was significantly assisted by thestructure of the HLA. A similar interface was made withCSTAR, which is a intelligence modeling simulation thatwas used in the Strike Force exercise. The overall point isthat federates have been brought in and removed withlittle effort because we rely on the HLA as the basiccommunications architecture for the DLRC. The DLRCwill incorporate each new version of the RTI.
C4I Interfaces: Providing the information to the ABCSequipment is a continual challenge. The ABCS equipmentis evolving to new versions and the DLRC must keep upwith these revisions. The DLRC is an active participant inthe SIMC4I OPT and has preliminary designs and
software to interface with the new Block 6x versions ofthe ABCS. Two important Defense InformationInfrastructure Common Operating Environment (DIICOE) products that are the keys to our interface are theJoint Common Database (JCDB) and the CommonMessage Processor (CMP). The DLRC also requires ameans for the staff to communicate back to the simulatedunits. Current investigation of this capability involves twonew capabilities. First, a menu system is being devisedthat is independent of a particular C4I system. It will usecommon applications and be available for all systems.Second, a voice to text capability is being investigated toallow users to input by voice structured instructions to thesimulated units.
The flexibility of the DLRC and its leveraging of artificialintelligence to replace the normal support personnel hasgreatly enhanced the effective training of these "digitized"staff officers.
Author Biography
JOHN W. OGREN is an Simulation Modeling Engineerworking at the MITRE site at the TRADOC AnalysisCenter, Ft. Leavenworth, KS. He retired from the USArmy in 1993 as a Lieutenant Colonel having spent thelast eight years of his career in the Operations Research &Analysis Field. He began working with simulations whileassigned to the Combat Development ExperimentationCenter (CDEC), at Fort Ord, California. CDEC conductedlive experiments with actual combat equipment, where theresolution of combat was modeling in a central computingfacility. He continued working with Combat Simulationswhile assigned to the Los Alamos National Laboratorywhere he studied artificial intelligence and its applicationto command and control. He began work with TRAC onthe Eagle combat simulation in 1988 and continues toexpand and develop its functionality.