Command and Control C2 Of Distributed Synthetic Environment Infrastructure

1
Command and Control (C2)Of Distributed Synthetic
Environment Infrastructure
2004 SPRING SIW

• Bob Patelski
• US Army Electronic Proving Ground
• Starship Test C2 Suite

Approved for Publication Distribution is
Unlimited OPSEC Review Completed 11Mar04
2
Command and Control (C2) of Distributed Synthetic
Environment Infrastructure

• The modern Army challenge Do more with less
• Enter MS Use sophisticated communications
  technology, distributed simulations and
  automation instead of troops and equipment
• Dilemma How to command control a synthetic
  environment over a widely distributed network
• Case Study Electronic Proving Grounds (EPG)
  Starship Test C2 Suite used in the Armys Virtual
  Proving Ground (VPG) Synthetic Environment
  Integration Test-bed (SEIT)

3
VPG Synthetic Environment Integration Testbed
(SEIT)

• Simulates physical environment influences
• Natural
• Manmade
• Networks an array of
• Simulations, Applications, Computer generated
  force models, as well as live assets.
• Connected via the Defense RE Network (DREN)

4
Virtual Proving GroundSynthetic Environment
Integrated Testbed
5
Starship Operational Concept Projecting the
Decision-Maker into the Exercise
Situation Awareness for the Test Director
Enhances the test directors ability to observe,
orient, decide and act (OODA) by providing high
fidelity access to the ground truth of the test
or exercise
Starship
6
Command Control (C2)

• Definition
• The Joint Chiefs of Staff (JCS) Pub 1-02 defines
  C2 as the exercise of authority and direction by
  a properly designated commander over assigned and
  attached forces in the accomplishment of the
  mission. C2 functions are performed through an
  arrangement of personnel, equipment,
  communications, facilities, and procedures
  employed by a commander in planning, directing,
  coordinating, and controlling forces and
  operations in the accomplishment of the mission
• Fundamental C2 Process Orient Observe
  Decide Act
• Communications Extends the Commanders
  Visibility and Span of Control

7
Generic C2 Process - OODA Loop
Common TacticalPicture
DeriveKnowledge
Sense, Process
Observe
Orient
SituationalAwareness
Actions In TheBattlespace
Act
Decide
Execute
Make Decisions
CommandersIntent Orders
The OODA Loop was developed by COL John R. Boyd,
USAF (Ret), "An Organic Design for Command and
Control," A Discourse on Winning and Losing.
Unpublished lecture notes, August 1987. OODA is
an acronym for Observe-Orient-Decide-Act.
8
Starship Testing C2 Paradigm
9
Instrumentation
GPS Tracker/Tactical Radio Enclosure (GTT)
(RICS)2
Remote Reconfigurable Intelligent Instrumentation
to Control, Collect, Simulate and Stimulate
(RICS)2. Multiple Child processes
Provides TSPI Data
Remote Operator Console (ROC)
Starship Test C2 Suite
Starship Can Communicate with Anything with a
Defined Interface or API
10
Visualization - Tabular Displays

• Users easily group entities corresponding to
  scenario needs.

• Users can set Multiple thresholds for any
  reported parameter.

11
Visualization - Logical Network Display
12
Visualization - Map Displays

• .

• Map Windows (with Pan, Zoom functionality) that
  display selected groups.

13
Visualization Real-time Incident Logging
14
Test Planning Execution Control User Interface
15
Starship Distributed System Design A Network of
Starship Exercise Managers
Control Center
Starship
Web Client
Starship
Control Center
Control Center
Starship
Starship Outside-World Communications
Starship Intercommunications
16
Starship System Design System Design Exercise
Manager Major System Activities
Starship Exercise Manager
Ingest
Distribute
Status and Notifications
Starship Display Applications Tables Maps Timeli
nes Networks
Exercise Range Assets
Process
Distribute
Ingest
Exercise Management
17
Starship CommunicationsA Network of Starship
Exercise Managers
Starship
Web Client
Starship
Communications Extends the Test Directors
Visibility and Span of Control
Starship
Starship Outside-World Communications
Starship Intercommunications
Implemented with TENA and Other Standard
Mechanisms
18
Test and Training Enabling Architecture (TENA)
Middleware

• Enables Starship communication over a widely
  distributed network
• Passes data between Starship instances
• Uses publish and subscribe
• Proven in multi-proving-ground tests
• Use Case DTC SEIT Distributed Test Exercise
• TENA Middleware used to distribute data
  acquired by Starship
• Master Starship at WSMR retrieved status from
  EPG instrumentation located at WSMR, Dugway,
  EPG, Yuma, ATC, and RTTC
• Starship running at WSMR shared its view of
  instrumentation status with Slave Starships at
  other SEIT Test Centers
• Additional experiments run with Master
  Starship at ATC in Maryland

19
Sharing Starship Entities
Publisher-side behavior Entity Publisher
acquires entity state through the Façade Entity
Publisher creates and publishes SDOs that reflect
the state of the entities Entity Publisher
monitors the exercise for changes in state and
creates or updated SDOs
Reflected Entities
Subscriber-side behavior Entity Subscriber
receives SDOs, extracts entity state, and inserts
reflected entities in the remote exercise Entity
Subscriber receives updates and modifies the
state of reflected entities accordingly Clients
of the remote exercise observe and interact with
the reflected entities as if they were local
20
Remote Command Processing
Publisher-Side Behavior Starship Client selects
reflected entity and invokes command Reflected
entity repackages command for transport and
places it in the queue Command Publisher dequeues
command, creates SDO, and publishes it
Starship Client Application
Test Instrument

Virtual Exercise (with real entities)
TENA Middleware
Entity
Command Queue
Entity
Command Subscriber
Entity
Entity
Command Publisher
Entity
Entity
Command Injector
Virtual Exercise (With Reflected Entities)
Subscriber-Side Behavior Subscriber receives
SDO, extracts command, and passes it to Command
Injector Command Injector repackages command and
hands it to real entity Real entity
communicates command to the (really real) test
instrument
21
Summary

• C2 functionality is just as relevant to the TE
  Community as it is to the Warfighter.
• As test and evaluation enters into the synthetic
  environment realm, interconnected by a widely
  dispersed infrastructure, the need for adequate
  Testing C2 functionality becomes more evident.
• The EPG has adapted the militaries theory and
  process for C2 into its Starship Testing C2
  Suite.
• There are still challenges ahead but Starships
  experience with SEIT and in the future with the
  InterTEC effort will produce a test tool that
  will provide enabling test C2 functionality for
  the test director over any distributed test
  infrastructure.

22
Questions Answers

• For Additional Information Contact the Following
  
• Janet McDonald, U.S. Army Electronic Proving
  Ground at Fort Huachuca, AZ. Program Manager for
  portions of the EPG C4ISR Toolkit Suite including
  Starship
• Tel [phone] DSN 879-4958
• Email Janet.McDonald_at_epg.army.mil
• Joseph Benischek, Senior Scientist with
  Technologies Engineering Inc., Severna Park, MD
  and Chief Architect for Starship
• Tel [phone] Ext 101
• Email BenischekJ_at_TecEngInc.com
• Bob Patelski, Senior Communications Engineer with
  Technologies Engineering Inc. Severna Park, MD
  and Program Coordinator for the Next Generation
  Starship
• Tel [phone] Ext 104
• Email PatelskiB_at_TecEngInc.com