Lessons le learned im implementing the C2Sim standard in in a practical exercise
C2Sim Introduction Most current simulation systems can not directly interface with a Command and Control (C2) system, they rely on a human operator to translate the Mission Command intent to the simulation. This presents issues maintaining accurate overlays, graphic control measures, and translating tactical tasks into behaviors for simulated forces. Solution Automate this translation by providing a standard for expressing and exchanging force structure and task information between the C2 and simulation systems
C2Sim Architecture
C2Sim Message Types • Initialization • Military Scenario Definition Language (MSDL) • Used to initialize entities, units, supplies and other scenario parameters • Required to instantiate the C2Sim database • Position Reports • Generated from simulation systems to report on simulated entities • Reporting rate and fidelity controlled by the simulating system • Orders • Orders generated from C2 devices • Simulating system is responsible for translating to behaviors • Simulation Control • Used to control the simulation state of connected systems
OneSAF-C2Sim Interface
OneSAF-C2Sim Interface • Initialization • Ability to generate a C2Sim initialization message from locally simulated entities • Currently does not support initialization of a OneSAF scenario from C2Sim • Position Reports • Generated for all entities and units every 30 seconds • Added a white-list capability to reduce volume of reports • Orders • Received orders are translated into JSON messages compatible with existing UDG interface. • Many behavior defaults were assumed due to field limitations • Simulation Control • Received transitions are checked for validity then forwarded to the Exercise Control Manager to transition the simulation state
CWIX 2019 Network Architecture
CWIX 2019 • Simulation Systems each implemented C2Sim interface • One Semi-Automated Force (OneSAF) • Joint Semi-Automated Forces (JSAF) • VR-Forces • No Interoperability protocol used • Simulation systems had no knowledge of each other. Each system was responsible for simulating friendly and enemy entities. • BMLC2GUI was used in place of real C2 devices • Situational awareness provided by SitaWare
CWIX 2019 Operational Area
Example C2Sim Order • Task Name Code • Desired Simulation behavior • Currently supports • Move • Occupy • Attack • Start Time • A point in time to automatically execute this behavior • Performing Entity • List of entities/units to execute the behavior • Location/Route • A list of points for the behavior • This can be used as a route, point, or area depending on the behavior • Name • The name to assign the behavior and related graphics in the simulation system
OneSAF Behavior Execution
Constraints and Limitations • Create initialization messages using the simulating systems • Using a global initialization file requires a very large amount of data to be sent. • Building the scenario file on each system and sending a partial initialization message would require much less information exchange. • C2Sim uses XML Schema Definition (XSD) to enforce a rigid schema • Time consuming to add new fields to the schema. • Field re-use confounds documentation and message layout. • Manual UUID assignment
Example OneSAF Entity/Unit Complexity
Recommended Improvements • Mature the C2SIM order/task messages to better support simulation behaviors • Mature the C2SIM initialization messages to include existing tactical platform or unit IDs (URN, FMID, etc) • Explore implementation of existing C2 system messaging into the C2SIM standard • Expand the use of C2 systems during CWIX tests
Conclusion • Redstone Test Center supports SISO efforts to improve and mature the C2SIM Standard • Redstone Test Center supports other users interested in extending the OneSAF-C2SIM proof of principle code and methodology
Recommend
More recommend