CORDIS

The free movement of persons and goods within the EU has led to the gradual abolition of border controls between Member States through the Schengen agreement. This has led to new challenges concerning the security of European external borders, and the need for a more effective cooperation among Member States. At the same moment, we see an increasing rationalization of the public spending in Security, hence an increasing need for cost-effective assets.

It has been within this context that procurement for unmanned vehicles has seen a constant growth. However, up to this point, each Member State has been exploiting its own set of assets to achieve their goal of border surveillance and control. With an increasing cooperation among EU Member States, the need for new, cost-effective and standardized assets is becoming more and more evident. As new capabilities and assets become available and, as current C2 systems (some of which are proprietary, use closed interfaces and are monolithic) become older, practitioners are faced with the increasing challenge of how to integrate new assets and C2 all of them (old and new) in a coordinated and coherent way without having to invest in a completely new C2 systems built from the ground up.

CAMELOT aims at addressing these challenges by carrying out a number of activities to prototype, test and demonstrate different advanced C2 service modules for multiple platform domains based on a SoA architecture. The overarching purpose is to validate the technical and financial viability of the modules (which will be based on modifications and maturing of previous work from partners) as well as to achieve an exploitable model based on a standardized architecture with well defined interfaces. A final demonstration involving a great number of the modules is envisaged, involving end users and relevant stakeholders.

CAMELOT started in May 2017. The present report comprises the period of work until Jul 2018. It has been compiled be TEKEVER, the initial coordinator of CAMELOT, which was terminated during RP2. During RP1 the consortium has focused on WP2 (User requirements and architecture) and WP3 (C2 Framework).

In WP2, the practitioners have identified requirements, through the employment of questionnaires and consultations with external advisors, making use of a simple random sampling process to obtain an unbiased group of individuals. These requirements were then prioritized with the MoSCoW approach, and use-cases for maritime and land border scenarios defined. Alongside with this work, the technical partners focused on the trade-off analysis of software architecture for multi-service multi-domain C2 (MSMDC2). The surveyed architectures were the ASTM F2541-06, POSIX, STANAG 4586, STANAG 4817, MDA, FACE, GOA, AFUS, JAUS, GVA, MAPLE and ROS. Following this trade-off the consortium decided that the best framework for CAMELOT was the STANAG 4817. The technical partners started drafting an architecture based on STANAG 4817 focusing on scalability, availability and security (main design requirements from the practitioners). The core architecture consists of four main services that will be developed in the various work packages of the project (WP3–WP7).

In WP3, the technical partners have started specifying the technical details for the CAMELOT architecture. These include hardware, middleware and interfaces. In terms of middleware the consortium has benchmarked several possibilities, such as DDS, RabbitMQ+JSON, ZeroMQ+Proto-Buffers, ECOA, JAUS and Kafka, taking into account a pre-defined set of requirements. For hardware, a distributed architecture has been proposed. Concerning the interfaces, an Interface Control Document (ICD) is currently being built based on the SAE UCS3.4 and inputs from each technical partner.

In WP4 (Automatic asset tasking and control), the work has been focused on agreeing on an internal architecture for the module, as well as defining the inputs and outputs that the service will require, directly feeding the ICD. The same approach has been followed on WP5 (Mission-related modules), WP6 (Visualisation and display modules), and WP7 (Sensing and detection modules). WP8 (Integration) and WP9 (Testing and Demo) haven't got results in this reporting period. In WP10 (Dissemination and Exploitation), the partners have created all online accounts for CAMELOT, including the project website and social media accounts (LinkedIn, Facebook, Twitter and ResearchGate). WP11 (Ethics requirements) comprises all the ethical screening performed throughout the lifespan of the CAMELOT in the Research with Humans, Data Privacy and Operations with UAVs.

As an Innovation Action dealing with high TRL technologies, CAMELOT possesses an extensive background. In fact, CAMELOT arises from past R&D initiatives that have led to the need for an MSMDC2 framework. In this sense, the contribution of CAMELOT to the current SoA is focused on three lines of research aiming at:
1. Achieving a MSMDC2 station, capable of operating unmanned land, maritime and aerial vehicles;
2. Developing multiple services to enhance the functionalities of current C2 operations; and
3. Enabling seamless integration with legacy C2 systems.

1. Taking into account the recent developments in NATO studies, namely the STANAG 4817, the CAMELOT consortium has decided to base its architecture on the proposition of this study, which is based on the SAE UCS3.4. Being designed for the aerial domain, the main work of CAMELOT lies in the extension of UCS3.4 to the land and maritime domains. To achieve interoperability among all platforms, in spite of their domain, the consortium proposes the existence of an adaptor layer, which converts proprietary protocols (e.g STANAG 4586, JAUS, JANUS, ROS) to the CAMELOT data model. The definition of technical specifications necessary to successfully achieve this (middleware, interfaces and hardware) clearly consists a progress beyond the current SoA.

2. CAMELOT foresees the development of services that will enhance the capabilities of a C2 station and reduce the mental workload of border guards. Such services include automatic tasking and control; mission planning and replanning; visualisation and display modules; and sensing and detection modules. The work on the add-on services is still in early stages, having only internal architectures, inputs and outputs defined. The consortium expects to have a first subset of functionalities working by Feb 2019 when the first software prototype of the CAMELOT system is internally demonstrated. The full set of service modules shall be ready by May 2019, and integrated in the CAMELOT system by Aug 2020.

3. One of the objectives of CAMELOT is to rationalize investments by developing a technological solution that integrates with external systems, and that is capable of operating unmanned assets already in the ranks of border guards. Hitherto, the CAMELOT beneficiaries are making use of the knowledge acquired in project EUCISE 2020 to implement the necessary data structures to ensure that high-level information can be shared between CAMELOT and the DG MARE CISE. This consists a highly desired progress, and will be achieved in two phases. All data structures necessary to communicate with external systems will be defined, implemented in the CAMELOT framework and tested with simulated data by Feb 2019, and a live interaction with at least one external systems will be demonstrated at M36.