Integrating autonomous system of systems in the Royal Netherlands Navy.

- Future naval operations will increasingly incorporate Maritime Unmanned Systems (MUS). Embedding autonomous MUS in a military organization has its challenges. To overcome these challenges the Royal Netherlands Navy has started the development of a general system of systems architecture, GENIUS. A general outline and functions are described in this paper as well as the current state and its future configurations in the Royal Netherlands Navy.


I. INTRODUCTION
he Royal Netherlands Navy faces future challenges where tasks become more complex. At the same time finding well trained personnel will become more difficult. This motivates the increasing interest in applying autonomous unmanned systems. The potential of these systems is widely recognized but there are challenges getting them militarily operational. In order to overcome these challenges a general architecture is under development named GENIUS which stands for Gateway Encoder Network Interface for Unmanned Systems. It operates using the task-based methodology implementation as proposed by de Vos from MAR-IT 1 . The challenges identified are listed below:  There are many different unmanned platforms, of different types made by different manufacturers which makes integration a costly and lengthy process.  The technological developments on the platforms, autonomy and sensors are moving very rapidly. Currently when a system becomes operational, its technology is already considered to be outdated.  Cyber security is a very critical aspect. Being able to apply security measures and update them constantly in an integral way is crucial.  Allowing multiple autonomous MUS to work together in heterogeneous teams.  Scalability issues. The current situation is not designed to accommodate multiple MUS simultaneously. This will result in resource problems when the number of MUS increases.  Facilitating interoperability with multiple systems such as the Integrated Mission Management System (IMMS) of the Royal Netherlands Navy fleet, New Integrated Marines Communications and Information System (NIMCIS) of the marine corps and the Battle Management System (BMS) of the Royal Dutch Army.  Providing for onboard processing, which is essential for data fusion, situation awareness, task assessment and operating as teams.

II. GENIUS
The main purpose of the GENIUS architecture is to facilitate the collaboration of different (heterogeneous) MUS. The autonomous MUS can eventually work together cooperatively in a heterogeneous team to complete the mission objective collectively. The first implementation of GENIUS architecture uses dedicated hardware, the GENIUS-Blade.
The GENIUS-Blade can be physically installed on any unmanned system providing it with the ability to run the GENIUS software framework and use the communication network in a cyber-secure manner. The GENIUS-Blade has the capacity to process the Observe, Orient, Decide and Act (OODA) loop for command and control of the platform and the payload, communicates with other assets in the team and (re-)plan itself. The MUS upgraded with GENIUS-Blade and software for autonomy is referred to as a PERFORMER. Multiple unmanned systems equipped with GENIUS-Blades will be allowed to communicate all the relevant information required by the mission planner to carry out its mission and re-plan in-mission if necessary to adapt to changing conditions. A group of self-organizing PERFORMERs can be seen as a single entity and is referred to as a SQUAD. Communication between the MUS assets and the ship is done through the GENIUS software framework.
The GENIUS system of systems architecture will provide for the following functionalities:  Task Preconditions: MUS -> PERFORMER In this section a closer look is taken at a MUS and its payload and the preconditions that have to be met in order to work within the GENIUS architecture.
The three different types of Command and Control (C2) configurations considered in this paper are illustrated in Figure  1, in summary: 1. PILOT oriented: Manually controlled/navigated platform with separate manual sensor control (if applicable). Most of the current unmanned systems without GENIUS-Blade. 2. SENSOR oriented: Sensor oriented is when the payload onboard the platform is controlled, by a single operator, as an integral part of the MUS.
3. MISSION oriented: An autonomous MUS with a GENIUS-Blade is self-aware of its capabilities, has situation awareness and is able to execute an OODA loop. Multiple PERFORMERs can operate together cooperatively to achieve their mission objective collectively. In a PILOT oriented C2 configuration the platform is controlled manually or navigated automatically by waypoints by the operator. The payload is not connected to the onboard autopilot but is manually operated by the sensor operator. Many current systems in operation in the Royal Netherlands Navy operate in this manner. A typical input for a PILOT orientated system, in the case of manual control, is stick input from a handheld controller or in the case of automatic control; waypoints are inputted to navigate the platform. In a PILOT oriented C2 configuration the pilot and sensor operator will have to work closely together to achieve higher level tasks such as 'inspect object X'. In challenging conditions this can be highly intensive for both MUS operators and the CMS operator on the ship. Another way to describe PILOT oriented is that the platform's reference frame is relative to the world as can be seen in Figure 1, by (xp, yp, zp). In a SENSOR oriented system the platform and payload controls are interconnected and a single operator can control the system. The autonomous system is self-aware of its payload capabilities and orientation and the platform movements. The input to a SENSOR oriented system can be for example 'inspect object X'. The inspection task description will be standardized in the GENIUS architecture and therefore read the same by all platforms. However how the platform will perform the inspection varies per platform. For example a multi-rotor system or helicopter system can hover above the target object in contrary to a fixed wing platform which will loiter around the target and will have to orient the payload accordingly. In Figure 1 the SENSOR oriented reference frame is xs, ys, zs relative to the world xw, yw, zw. In technical terms, for example a video payload, relative position and orientation to the platform is accompanied by camera parameters such as field of view and resolution. In a MISSION oriented system the GENIUS-Blade onboard the autonomous platforms will have additional GENIUS software functionality for (multi-platform) mission management. The team of MUS platforms receives high level mission objective from the CMS onboard the ship. The GENIUS mission management software determines the tasks for the individual assets. When an autonomous system is MISSION oriented it becomes a PERFORMER. A PERFORMER is self-aware of its capabilities, has situation awareness and is able to execute an OODA loop.

III. FUNCTIONALITIES AND CHARACTERISTICS
Task-based operation [1] In this paragraph task-based operation is explained and terminology is defined as used by MAR-IT. Task-based operation uses platform independent objectives which make it suitable for the GENIUS architecture's objectives.
A task-based approach starts with a goal, which is defined as "a clearly attainable world state". In order to achieve this end world state a transformation is needed. This transformation of the world state is achieved through a task. The definition of a task is an "Activity to be done or undertaken in order to achieve or contribute to achieving a goal". Figure 2: Illustration of the essence of a task, which is a transformation of a world state to a desired world state. For example: "escort object x, out of a specific area". When a task is "high level" or complex this is referred to as a mission. A mission can be "decomposed" into tasks or subtasks. [1] The GENIUS enabled autonomous MUS will execute missions. From the mission definition a mission planner can generate a set of tasks for the assets in the team. Where a task plan is defined as "A proposed, context sensitive order of tasks which, when performed in the specified order, achieves a goal". The set of tasks is distributed to the PERFORMERs which translate it internally to platform specific commands. Platform independence Varying platform types and configurations means difference in size, speed, domain, endurance, payload, level of onboard autonomy and means of communication.
The platform specific characteristics of each PERFORMER will be taken into consideration in the joint missionplanner so that the PERFORMER will never be allocated a task it cannot complete. The GENIUS system of systems architecture supports different levels of onboard autonomy and available means of communication as explained in the following paragraph.

Level of onboard Autonomy vs Communication requirements
The level of onboard autonomy influences the communication requirements. Communication requirements can be seen in terms of bandwidth, latency and security.
1) When a single autonomous MUS has the onboard "PERFORMER" processing power and cognitive reasoning capabilities and is given all context information needed to adapt to new conditions, the PERFORMER needs minimal communication to complete its own tasks contributing optimally to the collective completion of the mission objective. 2) When a MUS has minimal onboard processing power and cognitive reasoning capabilities the GENIUS architecture provides the option to utilize spare processing capacity from other PERFORMERs in the heterogeneous team, including the control station. The use of external processing capacity will increase the communication requirements.
Both situations can be illustrated by using PERFORMERs operating in a different domain: In the underwater domain communication is very challenging, which requires the underwater vehicle to have a high level of onboard autonomy. The Unmanned Underwater Vehicles (UUV) have to react to changing conditions on their own to complete their mission.
To the contrary, in the air domain a line of sight connection with a relatively high bandwidth is easily established, so for an aerial system the need for autonomy is less. For aerial vehicles payload is costly since it has to be kept in the air. Therefore it could be desirable to relay its data to another PERFORMER to minimize the disadvantages and fully benefit from the advantages of the different types of platforms. Unmanned Surface Vehicles (USV) typically combine long endurance (power supply) with heavy payload sensor and communication equipment. The surface can link the high bandwidth aerial communication network with the underwater vehicle communication systems. The surface vehicle can be equipped with a physical or tethered-drone mast for extended range communication (relay) and sensor coverage. The onboard autonomy of the surface vehicles can make use of relatively heavy computing power capacity creating a PERFORMER which could share capacity with other vehicles.
The GENIUS architecture provides flexibility so that the PERFORMER capability to contribute to the mission objective is optimally used. The first option is autonomous MUS vehicles making use of onboard processing power for autonomy, the second option is MUS vehicles making use of higher communication bandwidth to exchange data with another PERFORMER to process this data with its spare processing power.

CMS independence
The current fleet of the Royal Netherlands Navy is equipped with a CMS named Guardion, in which all sensors of the ship are ingested and applications are developed to create situation awareness. The new generation fleet will be equipped with an IMMS which will allow for the integration of (autonomous) MUS as well. The GENIUS architecture facilitates the integration of heterogeneous unmanned systems at different levels of autonomy. Other users use similar systems to fulfil their specific needs, for example BMS for the Royal Dutch Army and NIMCIS for the marine corps. GENIUS is intended to be interoperable in all these different management systems by using NATO STANAG compliant interfaces.

Inter-platform communication
The GENIUS-Blade hardware and software configuration provide a secure connection over a (mesh)-network with high level (cooperative) interaction between PERFORMERs. Because the PERFORMERs are connected through a mesh network, it is possible to share the platform status, payload status, the observations made and task progress assessed.

Task progress assessment
The individual PERFORMERs of the team will assess their own task progress and share this information with the team. The shared information is required for the joint mission-monitoring and joint mission-planning.

Joint mission-monitoring
The PERFORMERs will collectively assess their progress in achieving the mission objective of the team by combining the individual task progress assessment reports.

Joint mission-planning and re-planning
In the GENIUS architecture, teams of MUS vehicles have collective mission planning and re-planning capability which can generate individual task plans for each vehicle to contribute as a PERFORMER to the team. In order to benefit from the full potential of autonomous unmanned systems they have to work together in cooperative manner as a team of (heterogeneous) assets, referred to as a SQUAD. A SQUAD is a group of self-organizing PERFORMERs sharing the collective mission planning capability generating the task plans which collectively achieve the mission objective. During a mission of the self-organizing SQUAD the collective mission re-planner will assess the mission progress and recalculate task plans accordingly to complete the mission objective within the set constraints. The adaptive re-planner provides the SQUAD with resilience for changing conditions. Sandbox for autonomy algorithms for payload and platform control GENIUS will include a 'sandbox' development environment with simulation capability in which autonomy algorithms can be tested to command and control the PERFORMERs. This sandbox is a separate environment within the GENIUS software framework in which new autonomy algorithms can be evaluated offline. This allows for the flexibility needed to keep up with the rapid technological developments with minimal modification to the system.

Integral applicable security measurements
Security measures are more important for unmanned systems than for manned systems. When during a mission the system has been out of line of sight for a long period of time, it is necessary to have confidence in the system's integrity. Functionally it can be described in the following aspects:  Authentication; certainty that it is the system that is in communication with the operator.  Integrity; certainty that the system has not been hacked, high jacked or compromised.  Secure communication; certainty that no unauthorized party can listen in on the communication and prevent intervention.  Secure onboard data; in the event of an asset being captured, no sensitive data is accessible on the asset itself.
In order to meet these functional requirements security measures will have to be regularly updated. A general architecture would significantly help as it would allow for an integral security application. Moreover the GENIUS software will run on both sides of the data link allowing for 'pairing' and therefore offering a means of identity verification. Figure 4: current state of 6 UAS systems.

Current state
In the current state, as shown in Figure 5, six UAS systems are collectively deployed receiving task plans from the mission planner connected through a secure communication link of the 'paired' GENIUS-blades onboard the UAS systems. This mission planner defines the task plans for the assets and can be seen as a functionality that will be integrated in the IMMS in the future. Below an example mission is discussed.
Search and inspect mission  Goal: SEARCH area is searched for objects and all found objects are inspected.  The mission is: SEARCH the mission area and identify the detected objects.  Constraint input is: The mission area.  The SQUAD consists of 6 autonomous unmanned systems: o 5 UAS equipped with object detection algorithms referred to as SEARCH PERFORMER 1-5 o 1 UAS equipped with a high resolution payload referred to as the INSPECTION PERFORMER.

Time line of Search and inspect mission:
1) The mission planner will initialize the SQUAD and allocate tasks to the different assets.
2) The mission area is distributed into search areas for the SEARCH PERFORMERs. The INSPECTION PERFORMER remains on standby. 3) On the GENIUS onboard of the UAS the search area is translated into a flight plan which contains a search pattern, consisting of waypoints, take-off and return to launch commands and payload control, using standardized language. This flight plan is then executed by the autopilot. 4) This mission is started and the SEARCH PERFORMERs will execute their task plans with for each UAV there is a flight path and object detection processing task for the payload sensor data feed. 5) When an object is detected, a message is sent to the system and the GENIUS will allocate a new task the INSPECTION PERFORMER: 'Inspect object at location (x,y)'. The GENIUS will translate this into a flight plan for the autopilot. When the mission area is searched and all the detected objects have been inspected by the SQUAD. The SQUAD has reached the desired goal and it starts its return to base protocol.
To illustrate the ability of the GENIUS to adapt, consider the following two situations: 1) One of the SEARCH PERFORMERs has a problem and is taken out of the mission. GENIUS will recognize the situation by a status change and reallocate the other SEARCH PERFORMERs to cover the area. This way the mission for the SQUAD remains the same, but individual plans to the SEARCH PERFORMERs have been updated. 2) One could state that for a search mission the most time-efficient is that all the individual SEARCH PERFORMERs are finished at the same time. This is due to the logic that if one PERFORMER finishes earlier it could help another PERFORMER to complete the mission. An autonomy algorithm running on the GENIUS architecture could perform these calculations and re-plan the PERFORMERs when conditions are changing so that all PERFORMERs finish simultaneously. In Figure 5 each UxS orange box is a PERFORMER which can be part of a self-organizing SQUAD. The dashed line defines the complete SQUAD. The IMMS on the ship interacts with the GENIUS software to control the SQUAD, and receives updates and status of the mission progress of the SQUAD. The individual PERFORMERs will exchange their status through the GENIUS-Blades which monitors the mission process. The first configuration shown in Figure 6a is where the SQUAD consists of external unmanned systems only and is commanded by the ship. Figure 6b shows a different configuration where GENIUS will receive non-organic unmanned assets handed over by another ship. For example the assets from the mine countermeasure vessel could be controlled by for example the M-Frigate. Figure 6c shows a configuration where GENIUS will allow the mother ship to function together with the unmanned assets as a single SQUAD. This includes manned-unmanned teaming, external sources and will work together with the capabilities of the mother ship such as its sensors and applications on the IMMS.

V. CONCLUSION
For embedding autonomous unmanned systems in the Royal Netherlands Navy different challenges have been identified. In order to deal with these challenges a general system of systems architecture GENIUS is under development. GENIUS works on the task-based methodology which uses the goal as a starting point and unmanned systems execute tasks to achieve this goal. GENIUS-Blade hardware has been developed to provide autonomous unmanned systems with onboard processing capability and provide the team of assets with secure mesh network communication interaction capability. The onboard processing power allows the unmanned system to perform the OODA loop. The GENIUS-Blade allows the autonomous MUS to become a PERFORMER. The self-organizing SQUAD have as additional capabilities; self-awareness, task assessment, joint missionmonitoring, re-planning capability. The additional capabilities allow the SQUAD to collectively achieve the mission objective.
Currently the Royal Netherlands Navy is testing GENIUS on aerial vehicles and plans to expand this to other types of platforms, USVs and UUVs and unmanned ground vehicles (UGVs) of the Army. In the future it is foreseen that with a higher degree of integration non-organic assets can be incorporated as well as the mother ship itself, acting as part of the SQUAD.

Term Definition collaboration
Working together to achieve a goal collectively Acting as a group cooperative involving mutual assistance in working towards a common goal.

GENIUS
Product developed by the Royal Netherlands Navy which consists of a general system of systems architecture for autonomous unmanned systems. GENIUS-Blade Dedicated hardware to be installed on the unmanned system. Goal A clearly defined, desired and attainable world state. Mission A high-level, composite task allocated to an entity or group of entities. A mission can be decomposed into subtasks. PERFORMER Autonomous unmanned systems which can perform the OODA loop. This can be seen as a MISSION oriented system facilitated by GENIUS. Plan A proposed, context sensitive order of tasks which, when performed in the specified order, achieves a goal. Self-aware The system is self-aware when has knowledge of its capabilities and characteristics. Situation awareness the perception of environmental elements and events with respect to time or space, the comprehension of their meaning, and the projection of their future status [2]. SQUAD Self-organizing team of PERFORMERs that collectively achieve a mission objective. Task An activity to be done or undertaken in order to achieve or contribute to achieving a goal. UAS System decomposed in Air Vehicle, Payload, Data Link and (Ground) Control Station World state State of the world as can be observed by the PERFORMER.