Keywords

1 Introduction

The Simulation Interoperability Standard Organization (SISO) draft of the new standard document [1] states that Command and Control Systems to Simulation Systems Interoperation (C2SIM) is a standard for expressing and exchanging Command and Control (C2) information among C2 systems, simulation systems, and robotic and autonomous (RAS) systems in a coalition context. This new standard for interoperability between C2 and simulation systems can have a huge impact on modern military operations and training, where effective interoperation among coalition systems is critical for military needs like force readiness, situation awareness, operational training, information sharing and decision support [2,3,4,5]. It is not surprising that North Atlantic Treaty Organization (NATO) is interested into the operationalization of C2SIM in several military areas through its Scientific and Technology Organization (STO). STO NATO Modelling and Simulation Group (NMSG) has been cooperating with SISO C2SIM Product Development Group (PDG) [6] for many years [7,8,9] and, more recently, the MSG–145 Operationalization of Command and Control – Simulation Interoperation (C2SIM) Technical Activity [10] has been working in the last three years for the exploration, experimentation, validation and extension of C2SIM in different areas developed as separated use cases. This paper illustrates how the NATO Modelling and Simulation Centre of Excellence (M&S COE), a COE accredited by NATO Allied Command for Transformation (ACT) to provide to the Alliance expertise in M&S field, contributed to these efforts extending C2SIM to the Autonomous Systems (AS) area. As developed, C2SIM messages exchange for robots answers the requirements for an human–robotic interaction which depends more on level of Autonomy of robots than on the technology maturity of robotic platforms, in accordance to ACT conceptualization of AS.

So, this paper presents at first the M&S COE project for research on robotics to explain the rational behind the interest on C2SIM for AS, therefore the process agreeded among MSG–145 group to develop an extension of C2SIM standard is illustrated as applied for AS. Finally, this paper shows the experimental results for C2SIM validation, both in its standard core part and in developed extension. The extension to AS proved to be successfully implemented either in isolation during project testing or in a coalition environment with several different systems during Coalition Warrior Interoperability eXercise (CWIX) and a miniature exercise organized by MSG–145. In conclusions, this paper deals with a complete process to successfully extend the C2SIM standard, with a particular focus on automatization of scenario initialization and C2 messages exchange between humans and simulated or real robots.

2 R2CD2 Project

The C2SIM Autonomous System eXtension (ASX), as it is named according to the three letters SISO convention, has been developed in the wider scope of the “Research on Robotics Concept and Capability Development (R2CD2)” project. The R2CD2 is the M&S COE project on robotics whose aim is to leverage M&S technology in order to perform Concept Development and Experimentation (CD&E) on Unmanned Autonomous Systems (UAxS) employment in the modern urban battlefield. Many studies can be found in literature demonstrating how M&S can be in support of solving military problems concerning autonomous systems employment in different fields, among all [11,12,13,14,15,16,17,18,19,20,21]. The R2CD2 project was designed to support the NATO Transformation with reference to new Autonomous Systems capability, innovative concepts on Autonomy and on countering robotic systems. Moreover M&S COE mission includes both studies and experimentation of interoperability standards in the M&S domain, and supporting technical activity of the STO for this goal is always in its lines of efforts. With these premises, the choice of experimenting the new SISO C2SIM standard for command and control of UAxS, developing an extension of this language tailored for the project, was natural.

The M&S COE level of ambition is to investigate on five main areas relative to near or mid-term future employment of UAxS in urban environment:

  • interaction between human troops and robots – military C2 of robotic units;

  • Verification and Validation (V&V) of AS;

  • Tactics, Techniques and Procedures (TTPs) for UAxS;

  • development of functional requirements of new robotic platforms;

  • countering UAxS;

The R2CD2 project up to now concentrated into some of these points, dealing with: the interaction between simulated UAxS and real C2 systems; study of UAxS employment in a megacity of the future (for land and air domains); Decision-making support for UAxS—implemented either on an external system or directly on simulated UAxS based on their level of Autonomy. In order to perform experimentation about new UAxS-related concepts and standards, with these objectives in mind, after a first phase of conceptualization [22, 23], a prototype of a scalable and modular demonstrator, based on open standards and selected constructive simulators, was built during the R2CD2 project in collaboration with the Industry and Academia. Thanks to the possibility that M&S technology gives to reuse models, proof-of-concept prototypes, systems, studies, saving precious resources, for this demonstrator the followings elements have been re-used: the Level of Autonomy (LoA), concept developed during the Autonomous Systems Countermeasures (C-UAxS) project of the ACT [24], for the robotic behaviour and degree of human–robot interaction; “Archaria” urban model, a model of a mega city of the future built during the ACT Urbanization Project (UP) [25] by the NATO M&S COE, for the terrain generation.

2.1 Level of Autonomy (LoA)

The LoA concept deserves a brief description and some definitions since it is of central importance for the requirements of the C2 messages exchange and of the demonstrator architecture. Firstly, the focus is an Unmanned Autonomous Systems (UAS), which act without human intervention, opposite to the Manned systems, and which are intelligence-based, can behave as self-directed entities in a non-deterministic way. Based on the interaction with humans, it is possible to distinguish systems with: human-in-the-loop, where humans are in full control of a mission; human-on-the-loop, where humans don’t control but can still veto on machine actions; human-out-of-the-loop, where machines are completely in control. In the scope of the R2CD2 project these ideas were adopted re-using preliminary results on the Levels of Autonomy (LoA) of the Autonomous Systems Countermeasures (C-UAxS) project of the ACT. Conceptually, these LoAs are more based on the mission and the human-machine interaction than on the real skills/features which technology enables to machines. They were seven levels from 0 to 6. Figure 1 shows how all these ideas are correlated.

Fig. 1.
figure 1

Levels of Autonomy and human-machine interaction for AS.

Full size image

Linked to LoA is the idea that Autonomous Functions, which allow to perform a task autonomously, can be separated from platforms. Basically an AS can have autonomous functions and/or automated function (with pre-determined output) as well as a manned system can be characterized by manned, automated and/or autonomous function. According to the LoA of the AS, Autonomous Functions should be assured either by the autonomous platforms or external subsystems. For example in the R2CD2 project, for low LoAs, Autonomy Functions for mission planning are taken over by an external tool, in order to find the best paths for reconnaissance and exfiltration missions, based on information about the terrain and enemy. For this reason a decision making tool was paired with the C2 system in order to generate orders to simulated UAxS. Figure 2 shows LoAs used in the R2CD2 project and their relationship with external decision-making function.

As shown in Fig. 2, in the R2CD2 project the LoAs was grouped into three categories to simplify the UAxS modelling: LOW, MEDIUM and HIGH.

LOW—humans only gather, monitor and analyse data, make decision, while UAxS don’t assist. Neither collision avoidance or environment recognition are implemented in the UAxS behaviour, so they need well defined routes from an external system.

MEDIUM—UAxS gather, monitor, analyze data, but humans interpret them. UAxS assist in ranking task, but humans can veto machine actions and decisions. UAxS have good navigation skills in the environment and collision avoidance is implemented, so few waypoints are necessary in the order.

HIGH—UAxS perform a mission gathering, monitoring and analyzing data; humans are informed only at the end of the mission. UAxS have excellent navigation skills in the environment and collision avoidance is implemented. Only final destination is communicated to the UAxS in the order and they decide all.

Fig. 2.
figure 2

LoA vs external autonomy function

Full size image

3 Autonomous Systems eXtension (ASX)

The methodology/process followed to develop the ASX extension, and consequently to define the architecture of the R2CD2 project demonstrator, is here described. The first step is to search for requirements of the message exchange, the Information Exchange Requirements (IER), using a scenario-based methodology delineated in the SISO Guidelines for Scenario Development (GSD) [26]. The SISO GSD is widely accepted among STO MSG-145 group as the preferred methodology to find the IERs through a scenario-driven process. It was applied for the UAxS use case a first time by M&S COE in collaboration with FKIEFootnote 1 to extract IERs for C-BML messages [27] for UAxS [28], and subsequently used for the same purpose and to built a first version of the R2CD2 project technology demonstrator [29, 30]. This first demonstrator made use of C-BML messages because the C2SIM core was not yet well defined, so it could not be extended. The IERs are the main source for requirements of new data classes necessary for orders, reports and initialization information to build the ASX. Once the IERs are defined, the ASX can be developed.

The second step is to build an ontology of the C2SIM extension to AS, i.e. the necessary vocabulary and semantic needed to extend the core of the language to add information to messages, suitable for missions of UAxS according to the found IERs. Finally, the C2SIM eXtensible Markup Language (XML) schema of ASX can be obtained applying an eXtensible Stylesheet Language Transformation (XSLT), according to the rules fixed by SISO C2SIM PDG. The XML schema is essential to build orders, reports and initialization files to execute the scenario, and to develop the software for the C2SIM interfaces of all simulators and other elements of the R2CD2 project demonstrator.

3.1 Scenario Development

The scenario development is a multi-step process, starting from the definition of the simulation environment objectives, passing through a conceptual analysis to finish with design and development of the simulation environment. An extended description of an application of this process for an air scenario with UAxS can be found in [31]. Simplifying, as done for the R2CD2 project, an operational scenario is designed based on the simulation objects of a project. This scenario can be expressed in natural language by, for example, operational military personnel. Then a conceptual scenario is derived from it, describing formally the actors, their interactions and flow of actions, making use of the NATO Architectural Framework (NAF). Therefore, IERs for the scenario are derived, describing in a tabular form, the information which are to be conveyed between the logical actors of the scenario. In the following a brief description of the operational and conceptual scenarios are reported.

Operational Scenario. To support the R2CD2 prototype goals the operational scenario is designed with the following simulation objectives:

  • Detection and Identification of enemy robotic units utilizing UAxS and sensors;

  • Situational Awareness augmented with external decision-making support tool;

  • Experiment about defense against UAxS using UAxS;

  • UAxS employed in urban environment both in land and air domain;

  • Distinguish human–robot interaction according to three LoAs.

Based on the above requirements, the designed operational scenario shows an mission for protecting the troops and populations against hostile UAxS in modern urban environment. A team of unmanned ground vehicles (UGV) escorts a human platoon in a city while a swarm of unmanned air vehicles (UAV) performs a reconnaissance of the area searching for threats. As soon as hostile air drones show up, UAVs generate reports on enemy activity for UGVs which activate a two levels defensive system based on a safety bubble where, according to the proximity of the threat, the countermeasures increase from non-kinetic (jamming or capturing) to kinetic (shooting).

Conceptual Scenario. When the conceptual analysis of the scenario is performed, the logical nodes involved are identified, together with their main interactions. These can be seen as logical roles to be played by actors, which on their side are still logical entities, to be realized physically by real or simulated entities or systems. Figure 3 illustrates this high level logical scenario including: a C2 unit, played by a Command Post or C2 system; a Reconnaissance Autonomous Unit, played by a UAV swarm; a Land Protection Forces Unit, played by a UGV team; others actors, like humans and enemy.

Fig. 3.
figure 3

NAF v4 L2 – Logical scenario.

Full size image

Each logical actor performs some actions/tasks, which are linked by triggering relationship, if a cause-effect relationship is present, or simply one follow another. Figure 4 specifies tasks performed by which actor and how they are linked to each other. In this scenario the UAV swarm can perform a reconnaissance, return to base, send both a position report, about their location and status, and an observation report, about the detection and/or identification of a hostile unit. UGV team can return to base and send reports as the UAVs, but the main mission is to escort the human unit. This task is performed more or less autonomously according to the LoA: for high LoA they can decide if attack, firing or jamming, or retreat; for medium LoA they wait for confirmation order to attack or return to base, while autonomously use the jammer if the enemy if farther than a fixed distance or fire if the enemy is closer; for low LoA they need very punctual order like move, jamm or fire.

Because of the LoAs, also the Command Post needs to specialize the orders based on the LoA of UAVs or UGVs. As shown in Fig. 2, for lower LoA the Command Post must be assisted by an external decision-making function to find the best route to perform the mission and to provide the necessary waypoints if the navigation skills of the UAxS are not adequate enough to avoid obstacles. Once defined who are the players of the scenario and what they do, the temporal sequence of actions and interaction can be defined by a logical L6 as shown in Fig. 5 per a medium LoA scenario. In verbose mode, the logical sequence can be described as following:

  • Command post receives Air and Ground mission orders and send UAV and UGV orders with computed optimized routes for UAV swarm and UGV team respectively;

  • UAVs perform reconnaissance of the Area Of Interest (AOI); UGVs escort the human platoon leading the column of vehicles; they have good level of navigation skills to optimize a route between waypoints and avoid crashes, or following roads, open terrain, bridges, tunnels, etc.;

  • Reports are generated containing information about general status of UAxS;

  • As soon as hostile units are detected and/or identified, observation reports are generated; UAxS suggests following tasks, but waits for human confirmation (order). UAVs send report and suggest action;

  • UAVs receive the order to exit the area according to a computed route;

  • UGVs receive the order to escort the human platoon out of danger zone according to a computed route; they autonomously perform jamming as soon as enemy enters area of defence 1 or fire as soon as it enters area of defence 2.

Fig. 4.
figure 4

Logical actors with tasks/actions.

Full size image
Fig. 5.
figure 5

NAF v4 L6 – Logical sequence.

Full size image

The actors’ activity flow can be isolated, together with the logical data which are accessed in write or read mode to perform each action, as shown in Fig. 6. The logical data, here orders and reports, are to be implemented with real physical messages in XML format according to the C2SIM ASX schema.

Fig. 6.
figure 6

NAF v4 L4 – Logical activity.

Full size image

Information Exchange Requirements. According to the identified messages to be exchanged to allow the execution of the scenario, a series of tables can be built with a row for each message, reporting: type of message; producer; consumer; format; frequency; information contained. Table 1 is an example for the first phase of the scenario with the UAV reconnaissance and ground movement. All these tables constitute the Information Exchange Requirements.

3.2 Ontology and XML Schema

As already introduced, to build the C2SIM ASX, the standard C2SIM core for orders, reports and initialization of scenarios, needs to be enriched with new data elements peculiar to Autonomous Systems scenario. So, ASX was developed on top of the core, the Standard Military eXtension (SMX), which is part of the standard, and Land Operation eXtension (LOX), which is considered the first extension developed directly by C2SIM PDG, according to the information exchange requirements for the R2CD2 demonstrator. What was followed is general two-step process, meaning that it can be followed for whichever C2SIM extension. These two steps are building an ontology and generating an XML schema.

Table 1. Information exchange requirements – UAV reconnaissance and ground movement—node interaction (NAV v4 L3)
Full size table

Ontology. Building the ASX ontology means to extend the objects and their properties, data and their properties, contained in the basement made by the core+SMX+LOX ontology. For this goal the Protégé [32] software can be employed, as recommended by SISO C2SIM PDG. Their guidelines must be followed, avoiding repetitions and definitions of elements not peculiar to AS domain.

XML Schema. After building an ontology, the XML schema for an extension can be generated applying the standard SISO C2SIM XSLT. This is exactly what was performed to derive the ASX XML schema from ASX ontology. Some refinements could be necessary to avoid useless duplications in the definitions of simple types, elements, complex types and model groups derived from the ontology. It is noteworthy that the described process for schema development is a continuous one: the ASX schema should automatically include any changes in the core+SMX+LOX schema, and also eventual modifications in the ASX ontology, based on the modifications on the scenario requirements. Figure 7 shows these two-step process to generate the ASX XML schema.

Fig. 7.
figure 7

Extension ontology building and XML schema processing.

Full size image

4 ASX Experimentation

After being developed, the ASX was tested during the R2CD2 project implementation of the demonstrator and immediately afterwards in the context of a join coalition during NATO Coalition Warrior Interoperability eXercise (CWIX) 2019 and a miniature exercise organized by MSG–145 group. In this section details about this ASX experimentation are reported.

4.1 R2CD2 Demonstrator

The simulation environment to execute the described UAxS scenario was designed and realized. The MSG–145 choice for distributing the C2SIM messages was to adopt a simulation architecture based on Web Services using a client–server solution, with one or more servers and a client for each C2 or simulation system. Each system which participates to the coalition scenario has a C2SIM interface connected as client to the so-named C2SIM Reference Implementation Server [33]. It answers REST [34] requests to receive and store orders and reports, while it makes available C2SIM messages over STOMPFootnote 2 to all clients. The R2CD2 demonstrator makes no difference and it represents a little distributed simulation environment. The logical actors are realized with simulation entities with their own coded model. Each model is associated with one or several behaviours to perform requested tasks and interact with the external environment according to the LoA to be implemented. Two different simulators are employed for the two different operational domains of the scenario: air and land. So, one simulator runs models for UAVs and hostile drones and the other those for UGVs and human platoon. All interactions between the two simulators which are out of the scope of C2SIM standard are managed through an HLA [35] federation. The Command Post functions are distributed between two systems: a GUIFootnote 3 tool for editing the orders and displaying the report information on a map, like a C2 system, since a real C2 system with a C2SIM interface is not currently available for most of the MSG–145 members; a separate software for decision-making support to UAxS for path computing in case of low LoA according to information about terrain and enemy units. Obviously, all systems share the same urban terrain (piece of Archaria) and geographical coordinate system.

In details, as shown in Fig. 8, the R2CD2 project demonstrator is made of:

  • BMLC2GUI of the George Mason University (GMU) as open source C2SIM order editor and displayer of reports [36];

  • open source C2SIM Reference Implementation Server, developed by GMU [36] and customized for handling the ASX schema;

  • VT MÄK VRForces as simulator of air domain;

  • MASA Sword as simulator of land domain;

  • C2SIM interface for VRForces simulator for handling the ASX schema to generate tasks of entities and producing position and observation reports;

  • C2SIM interface for Sword simulator for handling the ASX schema to generate tasks of entities and producing position and observation reports;

  • Tactical Decision Support System (TDSS) of the University of Defence in Brno (CZE) as external software for decision-making support, fully supporting the C2SIM ASX to enrich orders with detailed paths to follow for missions to low LoA UAxS and to read reports produced by UAxS.

To make clearer how all the systems interact during a simulation, Fig. 9 shows the initialization phase when the order of battle (units with their organization, locations and some simulation parameters – ORBAT) is shared among all systems. The BMLC2GUI edits or opens an C2SIM initialization file to push it to the server (through RESTful service), therefore the server can share it to simulators and TDSS (through STOMP service). Figure 10 illustrates the C2SIM messages exchange during the scenario execution for tasking and reporting.

Fig. 8.
figure 8

Technology view reporting resource structure & connectivity (NAF v4 P2-3)

Full size image

With this demonstrator the ASX was tested successfully in isolation, meaning that only messages formatted according to the ASX schema were exchanged. Actually this experimentation allowed already to test that mixed tasks both for traditional land units (according to LOX) and for UAxS (according to ASX) could coexist in the same order. For tests involving different kinds of systems and messages in a join coalition environment, part of the demonstrator was employed during CWIX and the mini-exercise.

4.2 CWIX 2019

CWIX is the NATO venue focused on interoperability to explore, experiment and examine systems. MSG–145 group participate at the 2019 edition with the intent to test the version 9 of the C2SIM standard core together with SMX and LOX to start the validation process for the SISO balloting process of the standard. The ASX was added to the equation. Figure 11 shows the network diagram of the MSG-145 participation to the exercise.

Fig. 9.
figure 9

NAF v4 P6 – Systems message exchange during initialization.

Full size image
Fig. 10.
figure 10

NAF v4 P6 – Systems message exchange during tasking/reporting.

Full size image
Fig. 11.
figure 11

CWIX 2019 diagram of the C2SIM testing

Full size image

The capabilities (systems) involved were:

  • USA – BMLC2GUI of GMU, for simulation control, monitor and dislayer, on site in the CWIX Unclassified Network

  • DEU – Kora simulator and BMLC2GUI, on site in the CWIX Unclassified Network;

  • Italy – C2SIM server and BMLC2GUI, in Roma (ITA) at NATO M&S COE

  • Italy – Sword and VRForces simulators, in Roma (ITA) at NATO M&S COE;

  • GBR – JSAF simulator and BMLC2GUI, in Portsdown West, Fareham (UK), at Defence Science and Technology Laboratory (DSTL);

  • USA – C2SIM server, back-to-back connected to the server in Roma to be the front-end of an US-only enclave, in Fairfax, VA (USA);

  • USA – SitaWare HQ and VRForces, in an US-only enclave, in Monterey, CA (USA) at Naval Postgraduate School (NPS);

  • USA – SitaWare HQ and OneSAF, in an US-only enclave, in Huntsville, AL (USA) at Army Test and Evaluation Command (ATEC);

The US-only enclave was necessary for license issues linked to the US Sitaware HQ C2 system. It is worth mentioning that this system is the first commercial C2 system compliant with C2SIM standard, even if it is able to read reports and not to edit orders. Another peculiarity is that JSAF simulator produced reports in IBML09 format, while it could be initialized and receive orders in C2SIM. The C2SIM server took care of the IBML09/C2SIM translation. The R2CD2 project demonstrator participated as capability CC-298 NATO MSCOE C2SIM R2CD2 EVO 2.0. As for all the tests during CWIX, each trial is basically a message transmission with a producer, one or more consumers and eventually a distributor or mediator. CC-298 did 9 successful tests, as producer or consumer or in both roles. The test successfully proved that ASX can be employed in a coalition environment with a server supporting it and distributing C2SIM messages for all the systems connected and formatted according the C2SIM standard, whose the ASX is a peculiar subset.

4.3 MSG-145 Mini-exercise

During the miniature exercise a more appropriate common coalition scenario was executed with the MSG–145 partners participating. The experimentation was conducted in the form of a distributed mission planning exercise, at brigade-level, supporting a fictional nation called “Bogaland” [37]. The network diagram for the exercise is represented in Fig. 12, where one more nation (New Zealand) participated remotely connected adding the VBS3 simulator to the C2SIM-compliant systems family. The systems which were on site at CWIX moved to Roma (ITA) at the M&S COE, who hosted the activity. The mini-exercise allowed to test a complex scenario with a lot of messages flowing between different systems at the same time. This coexistence of messages, with orders and reports formatted according to slightly different schemas, proved that ASX was well developed, avoiding conflicts with messages supporting only core+SMX+LOX.

Fig. 12.
figure 12

Mini-exercise diagram of the C2SIM testing

Full size image

5 Conclusions

In conclusions, this paper illustrated a complete process to successfully extend the C2SIM standard to a specific area. In particular, this paper dealt with the ASX extension and how it can be used to initialize a simulation scenario and to exchange C2 messages between humans and simulated or real robots. In details, the results reported in this paper are summarized here:

  1. 1.

    R2CD2 project

    • ASX successfully implemented with a process compliant with SISO C2SIM PDG guidelines

    • Three C2SIM client interfaces developed and experimented supporting ASX for the following systems:

      • MASA Sword

      • VT MÄK VRForces by Antycip Simulation (two versions supporting both HLA and DIS [38])

      • TDSS by University of Defence, Brno (CZE)

  2. 2.

    CWIX 2019

    • CC-298 NATO MSCOE C2SIM R2CD2 EVO 2.0 did 9 successful tests, as producer or consumer or in both roles

    • VR-Forces and Sword simulators performed as expected exchanging orders and reports with BMLC2GUI through C2SIM server using ASX schema

  3. 3.

    MSG-145 mini-exercise

    • ASX successfully deployed in Coalition Distributed Simulation with VR-Forces and Sword

5.1 Way Ahead

Future improvements are already on their way for realization through collaboration with national industry. In particular:

  1. 1.

    CD&E on UAxS capability and countermeasures (requirements; TTPs)

  2. 2.

    Cyber domain to protect and/or counter UAxS, including a communication and network simulator in the demonstrator architecture, according to the idea in [39]

  3. 3.

    adopting the M&S as a Service paradigm [40], migrating all R2CD2 project demonstrator element in the MSaaS OCEAN infrastructure [41]

  4. 4.

    use of Artificial Intelligence (AI) to support decision making in an operational scenario dominated by robots, for speeding up the choice of the proper countermeasure or secure exfiltration path or attack route, based on near real time information.