Lessons learned implementing the C2Sim standard in a practical - - PDF document

Lessons learned implementing the C2Sim standard in a practical exercise

Lessons learned implementing the C2Sim standard in a practical exercise

E.M. Bearss1, K.G. LeSueur2, M.J. O’Connor3 and R.F. Zinser4

1Software Engineer, Trideum, Huntsville, AL 2Chief Technologist, Redstone Test Center, Huntsville, AL 3Chief Technologist, Trideum, Huntsville, AL 4Program Manager, Trideum, Huntsville, AL

Abstract — This paper discusses the lessons learned creating a Command and Control Systems to Simulation Systems Interoperation (C2Sim) interface in OneSAF and using it in a practical exercise. The primary goal of C2Sim is to support data exchange needed for scenario initialization, tasking, and reporting between C2 devices and simulating

• systems. The prototype OneSAF-C2SIM interface demonstrates each of these capabilities by using a C2 device to

interact with OneSAF rather than using a simulation interactor to control the simulation system. The C2Sim interface not only reduces the need for simulation interactors, but also allows military role-players using an actual C2 devices to control simulation systems.

1 Introduction

The US Army Redstone Test Center (RTC) participated in the 2019 Coalition Warrior Interoperability Exercise (CWIX) designed to evaluate the Command and Control Systems to Simulation Systems Interoperation (C2Sim)

• specification. The draft C2Sim Simulation Interoperability

Standards Organization (SISO) standard stimulates simulation behaviors based on C2 system tasks. RTC developed a prototype One Semi-Automated Force (OneSAF) to C2Sim interface to communicate with a C2Sim server. This prototype focused on three major design goals to demonstrate OneSAF-C2SIM interoperability: Centralized control of simulations from a C2SIM Server; provide entity position reports to C2SIM Clients; and initiate simulation behaviors from C2SIM

• rders.

2 Prototype Development

To construct the prototype interface, a new component was developed and added to the existing OneSAF User Data Gateway (UDG). The UDG was developed to allow web applications such as the Web Control Tool (WCT) and Web After Action Review (WebAAR) to control the OneSAF simulation through a standard API. In order to communicate with the C2Sim server, a Simple Text Oriented Message Protocol (STOMP) message subscriber implemented by C2SIMCleintLib was used. Received messages are translated and forwarded to the OneSAF component responsible for handling the action. Simulation state transitions are sent to the Exercise Control Manager, directing OneSAF to transition the simulation state as requested. C2SIM orders are translated into JavaScript Object Notation (JSON) and forwarded to the UDG. Due to the draft nature of the C2Sim standard, the fidelity of the behaviors generated from the C2 devices were very

• limited. During the translation process, many of the

OneSAF behavior inputs had to be hardcoded and were not able to be controlled through the C2 device. This process can be improved in the future by allowing more fields in the message schema. The interface also has the ability to generate outgoing messages and send them to the C2Sim server using the HTTP REST protocol. The interface contains the logic in

• rder to translate the OneSAF based structures into an

XML document able to be understood by the C2Sim

• standard. This document is encapsulated into a REST

message and sent to the C2Sim server over HTTP requests. 2.1 Interface Components

Fig 1. OneSAF-C2Sim Interface Architecture

2.1.1 Initialization C2SIM clients (as surrogates for tactical C2 Systems or event technical control workstations) or the C2SIM Server can generate, send, and receive initialization messages. Initialization messages enable centralized technical control of distributed simulation systems. In accordance with the C2SIM standard, simulating systems should ingest initialization messages formatted in accordance with standard Military Scenario Definition Language (MSDL). The message and MSDL then creates the

Lessons learned implementing the C2Sim standard in a practical exercise necessary units and entities to support the exercise. The C2SIM server can use a global initialization list to create units on the connected simulation systems. In concept, having a centralized Task Organization and Force Structure that will populate C2 systems and the simulations representing the event entities. The simulation systems can also initialize themselves, then send partial initialization messages to the C2SIM server to create its database of units. 2.1.2 Position Reports To conform to the C2Sim specification, federates must periodically create and send position reports for each simulated entity or unit. The OneSAF-C2Sim interface creates these reports every 30 seconds and contain the unit’s position, orientation, and a timestamp. Due to OneSAF simulating at the entity level, we implemented a whitelist filter to only send position reports from specific entities to represent required units. This drastically reduced the number of unit graphics on the C2 device, improving readability. 2.1.2 Behavior Creation The OneSAF-C2Sim prototype accepted commands from the C2Sim server over STOMP. The interface translated and forwarded these messages through the OneSAF UDG in order to create behaviors inside OneSAF. Operators could then modify, stop, and restart these behaviors through the OneSAF Web Control Tool (WCT) as

• required. The C2Sim interface can also handle C2Sim

Commands designed to control he simulation state. These control messages can order connected simulating systems to initialize, start, or pause the simulation and are handed

• ff to the OneSAF Exercise Control Manager to transition

the simulation state if possible.

4 Experiment

The 2019 CWIX exercise consisted of a small scenario located in Norrkoping, Sweden. The environment included various simulation systems including OneSAF, Joint Semi-Automated Forces (JSAF), and VR-Forces all including interfaces conforming to the C2Sim standard.

Fig 2. MSG-145 Network Architecture for CWIX 2019

Due to the small scale of the event and limited development timeframe, BMLC2GUI, developed by George Mason University, was used as a surrogate C2

• system. This software was used to generate mission tasks

and represented basic C2 situational awareness for the event participants. This GUI allowed users to create C2Sim orders, push orders and tasks to simulations, and view position reports coming from the various federates published through C2Sim. The C2Sim server also implemented a connector to SitaWare, allowing sites to view position reports and orders through its interface. For this exercise, a global initialization message, sent through BMLC2GUI was used to initialize all connected simulation systems. The current draft implementation of C2Sim does not support enough fields to effectively initialize a OneSAF scenario. Currently there is not a good way to create an echelon structure or provide any deviations from a standard OneSAF composition. Instead we chose to create and load a OneSAF scenario before the event and discarded the contents of the initialization message. For this exercise there was no interoperability framework in place. Due to this limitation, each simulating system was required to simulated both friendly and opposing forces. Simulating systems also had no knowledge of external federates, and situational awareness was provided only by the BMLC2GUI and SitaWare systems. The RTC OneSAF federate simulated a single Motorized Infantry Company, including its subordinate platoons and sections, and several platoons of dispersed infantry enemy

• forces. The company’s mission was modeled using three

OneSAF behaviors: move tactically along a designated route, assault an area, and occupy position after the assault. Each of these behaviors was tasked through the BMLC2GUI without manual intervention in OneSAF.

Lessons learned implementing the C2Sim standard in a practical exercise

Fig 3. SitaWare view

In addition to accepting task from C2Sim, OneSAF successfully broadcasted whitelisted entity and unit position reports throughout the experiment. Location populated icons on BMLC2GUI maps and the SitaWare suite.

5 Conclusion

The OneSAF-C2SIM prototype developed for the CWIX 2019 experiment clearly demonstrated the benefits of enabling the transfer of C2 Tasks and Orders directly to Simulation systems. This functionality could greatly reduce the overhead normally associated with simulation exercises where simulation operators and military commanders must continually enter data in separate systems to execute common tactical tasks. The C2SIM standard requires additional development and implementation guidance in order to enable a more complete initialization message consistent with OneSAF entity and unit compositions. Ongoing efforts to implement global force management identification for platforms and units will likely contribute to the synchronization needed to fully implement the C2SIM initialization protocols.

Acknowledgements

We would like to thank Dr. Mark Pullen and Douglas Corner for their coordination of the CWIX exercise and troubleshooting issues during development of the OneSAF prototype.

References

[1] Command and Control Systems Simulation Systems Interoperation Product Development Group: “Standard for Command and Control Systems – Simulation Systems Interoperation Version 1.0” [2] Command and Control Systems Simulation Systems Interoperation Product Development Group: “C2SIM Server Reference Implementation Documentation– Version 4.6.3.6 -1”

Author/Speaker Biographies

Edwin Michael Bearss received his Master of Science degree in Computer Science at the Georgia Institute of Technology in 2018. He is currently a software engineer at Trideum Corporation with more than 5 years of experience in the modeling and simulation (M&S) field.

• Dr. Kenneth G. LeSueur serves as the chief technologist
• f the Modeling &

Simulation Division at the US Army Redstone Test Center (RTC). His work and research have been concentrated in HWIL testing, distributed testing, and modeling and simulation. Michael J. O’Connor is Chief Technologist at Trideum Corporation with more than 25 years’ experience in Modeling and Simulation (M&S). He is currently the Chairman of the SISO Executive Committee. He has served as the chair of the I/ITSEC Simulation Subcommittee and the I/ITSEC Training Subcommittee. Roy F Zinser III is M&S Integration Lead and Simulation-Mission Command Interoperability Architect at Trideum Corporation with more than 15 years’ experience in Modeling and Simulation (M&S) and Mission Command Information Systems. He has supported M&S in multiple domains including Training, Experimentation, and Test & Evaluation.