Lessons learned implementing the C2Sim standard in a practical exercise Lessons learned implementing the C2Sim standard in a practical exercise E.M. Bearss 1 , K.G. LeSueur 2 , M.J. O’Connor 3 and R.F. Zinser 4 1 Software Engineer, Trideum, Huntsville, AL 2 Chief Technologist, Redstone Test Center, Huntsville, AL 3 Chief Technologist, Trideum, Huntsville, AL 4 Program 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 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 The US Army Redstone Test Center (RTC) participated in OneSAF behavior inputs had to be hardcoded and were not the 2019 Coalition Warrior Interoperability Exercise able to be controlled through the C2 device. This process (CWIX) designed to evaluate the Command and Control can be improved in the future by allowing more fields in Systems to Simulation Systems Interoperation (C2Sim) the message schema. specification. The draft C2Sim Simulation Interoperability Standards Organization (SISO) standard stimulates The interface also has the ability to generate outgoing simulation behaviors based on C2 system tasks. RTC messages and send them to the C2Sim server using the developed a prototype One Semi-Automated Force HTTP REST protocol. The interface contains the logic in (OneSAF) to C2Sim interface to communicate with a order to translate the OneSAF based structures into an C2Sim server. This prototype focused on three major XML document able to be understood by the C2Sim design goals to demonstrate OneSAF-C2SIM standard. This document is encapsulated into a REST interoperability: Centralized control of simulations from a message and sent to the C2Sim server over HTTP requests. C2SIM Server; provide entity position reports to C2SIM Clients; and initiate simulation behaviors from C2SIM orders. 2.1 Interface Components 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 Fig 1. OneSAF-C2Sim Interface Architecture OneSAF simulation through a standard API. In order to communicate with the C2Sim server, a Simple Text 2.1.1 Initialization Oriented Message Protocol (STOMP) message subscriber implemented by C2SIMCleintLib was used. Received C2SIM clients (as surrogates for tactical C2 Systems or messages are translated and forwarded to the OneSAF event technical control workstations) or the C2SIM Server component responsible for handling the action. Simulation can generate, send, and receive initialization messages. state transitions are sent to the Exercise Control Manager, Initialization messages enable centralized technical directing OneSAF to transition the simulation state as control of distributed simulation systems. In accordance requested. with the C2SIM standard, simulating systems should ingest initialization messages formatted in accordance C2SIM orders are translated into JavaScript Object with standard Military Scenario Definition Language Notation (JSON) and forwarded to the UDG. Due to the (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 Fig 2. MSG-145 Network Architecture for CWIX 2019 unit’s position, orientation, and a ti mestamp. Due to OneSAF simulating at the entity level, we implemented a whitelist filter to only send position reports from specific Due to the small scale of the event and limited entities to represent required units. This drastically development timeframe, BMLC2GUI, developed by reduced the number of unit graphics on the C2 device, George Mason University, was used as a surrogate C2 improving readability. 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 2.1.2 Behavior Creation C2Sim orders, push orders and tasks to simulations, and view position reports coming from the various federates The OneSAF-C2Sim prototype accepted commands from published through C2Sim. The C2Sim server also the C2Sim server over STOMP. The interface translated implemented a connector to SitaWare, allowing sites to and forwarded these messages through the OneSAF UDG view position reports and orders through its interface. in order to create behaviors inside OneSAF. Operators could then modify, stop, and restart these behaviors For this exercise, a global initialization message, sent through the OneSAF Web Control Tool (WCT) as through BMLC2GUI was used to initialize all connected required. The C2Sim interface can also handle C2Sim simulation systems. The current draft implementation of Commands designed to control he simulation state. These C2Sim does not support enough fields to effectively control messages can order connected simulating systems initialize a OneSAF scenario. Currently there is not a good to initialize, start, or pause the simulation and are handed way to create an echelon structure or provide any off to the OneSAF Exercise Control Manager to transition deviations from a standard OneSAF composition. Instead the simulation state if possible. we chose to create and load a OneSAF scenario before the event and discarded the contents of the initialization 4 Experiment message. The 2019 CWIX exercise consisted of a small scenario For this exercise there was no interoperability framework located in Norrkoping, Sweden. The environment included in place. Due to this limitation, each simulating system was various simulation systems including OneSAF, Joint required to simulated both friendly and opposing forces. Semi-Automated Forces (JSAF), and VR-Forces all Simulating systems also had no knowledge of external including interfaces conforming to the C2Sim standard. 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.
Recommend
More recommend