Project CAMELOT is result of an international cooperation between several European entities and is funded by the European Union's Horizon 2020 research and innovation programme under grant agreement no. 740736. In its essence, CAMELOT responds to the H2020-SEC-2016-2017 call, namely the Sub-topic 2 (Enhanced command and control systems for the surveillance of borders in a 3D environment Autonomous surveillance) of the SEC-20-BES-2016 topic.
With 22 beneficiaries from 11 European Union member states or associated countries (Portugal, Spain, Belgium, France, Greece, UK, Ireland, Poland, Romania, Bulgaria and Switzerland), CAMELOT has a total budget of 9.9 Million Euros, funded at a 70% rate for Industrial partners and at a 100% rate for non-profit organisations, such as research centres and governmental entities.
The topics under this section will further describe the project in terms of its motivation, objectives and organisation, as well as expected outcomes.
Ability of commanding and controlling multiple UxVs as well as other sensors and delivering complex services
Traditionally, Unmanned Vehicles (UxVs) were procured with their own stovepipe control segment (Ground Control Station or GCS). These GCS were, and in many cases still are, typically closed systems utilizing proprietary interfaces. The proliferation of stovepipe control systems on a single C2 system raises issues concerning interoperability, training, capital investment, adaptation work, footprint and logistic support among others. Therefore, it becomes essential for end-users to develop the ability of commanding and controlling multiple UxVs as well as other sensors and delivering complex services (such automatic asset tasking, mission planning and re-planning or 3D representation of threats to name a few) using the same systems and environments (to rationalize costs and improve efficiency). This enables future capability upgrades in cost effective fashion and reuse of selected C2 components which can be sourced from multiple vendors.
Although there have been several efforts and work done in the domain of command and control systems (in particular control segments for UxVs in the defence domain), a lot remains to emerge into a single widely supported standard. Furthermore, it makes little sense for end-users and practitioners to develop and maintain their own large software repositories associated with the C2 capabilities (it would be easier to maintain a list of available services with associated metadata). Industry also has incentives to adopt such standards: namely that services or modules developed on an industry wide accepted model would be easier to integrate with a standard compliant system. Specialist providers (in particular SMEs) can supply niche components without the need to invest in gaining expertise on the complete range of system interactions. This model has proven to work before, for example the adoption of NATO standard STANAG 4586 (UAS interoperability) by component suppliers of vehicles and sensors.
Prototyping different advanced command and control service modules for multiple platform domains
CAMELOT (C2 Advanced Multi-domain Environment and Live Observation Technologies) aims at addressing the challenges and fill this gap by carrying out a number of activities to prototype, test and demonstrate different advanced command and control service modules for multiple platform domains based on a state-of-the-art architecture. The overarching purpose will be 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 and specified interfaces. In addition to multiple testing of the different modules, a final demonstration involving a great number of the modules is envisaged, involving end users and relevant stakeholders. This will allow CAMELOT project to achieve TRL6 maturity levels.
The practitioners of CAMELOT have identified common challenges in the evolution and adaptation of existing assets and systems to the evolving challenges witnessed across EU:
Employing unmanned systems in support of surveillance activities – The engagement of manned aircraft, ground vehicles and/or vessels to carry out surveillance is expensive, dangerous and resource heavy. The capability to engage unmanned systems (of whichever type) to perform surveillance can increase the range and coverage while reducing operational costs and enabling manned assets to perform more vital activities such as interception and rescue.
Integrating new assets and sensors into existing communications and information infrastructures – As the range and type of sensors increases, the variety of assets and the area of operations grow, the need to integrate new types of data coming from heterogeneous sources and the capability to adequately control and command assets grows accordingly. This is problematic if sensors and platforms all use different (and often proprietary) data models, protocols and control segments.
Assimilating increasingly complex situational pictures in 3 dimensional space – As the size, type and capability of assets increase and become more varied and as the same happens with potential threats, it becomes even more important to be able to present information in simple, accurate ways, allowing decisions makers and operators to correctly interpret situations, assess risks and determine best reactions
Filling the gaps
CAMELOT intends to fill these gaps in terms of standards for C2 systems for heterogeneous platforms and sensors (with an emphasis on UxVs) by validating enhanced capabilities and new functionalities built upon frameworks following open and well defined interfaces. This will help practitioners and member states rationalize their investments in new C2 infrastructure (allowing for either a “pick and mix” type of approach or completely new developments supported by a large set of EU industry) and take advantage of niche components developed by specialist companies. CAMELOT will achieve this by prototyping service modules exploiting partners’ background that complying with an architecture that will be chosen during the project. This selection will be based on a survey of existing standardization efforts. All modules support directly needs expressed by at least one CAMELOT practitioner. The proposed CAMELOT modules and scope is represented in the schematic of Figure 1 and will be explained in the next paragraphs.
Need to manage gradual abolition of border controls between member states
The free movement of persons and goods within the European Union 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. Recent events (such as the correlated waves of illegal immigration and refugee crisis or the attacks in France, Belgium, Germany and other European countries) have contributed to increase the pressure and stress put on the external borders of the EU. To put things in perspective, according to FRONTEX, 283000 migrants entered the EU irregularly in 2014 (source: FRONTEX). In 2015, this number almost quadrupled to approximately 1 Million migrants (according to IOM and UNCHR). The other largest challenge in addition to illegal immigration is smuggling. During 2014 and 2015, various national authorities working in collaboration apprehended over 19 tonnes of cocaine and 85 tonnes of cannabis in the Atlantic and Mediterranean regions (source: MAOC).
Single widely supported or adopted standard for multi-platform, multi-domain and multi-service Command and Control
Each member state and border practitioner exploits its own set of assets in their goal of border surveillance and control. States have invested significantly on these assets and the infrastructures necessary to manage and control them. As new capabilities and assets become available (e.g. unmanned systems which are frequently based on stove piped control segments) and, as current Command and Control (C2) systems (some of which are proprietary, use closed interfaces and are monolithic) become older, border control practitioners are faced with the increasing challenge of how to integrate new assets and command and control 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. To compound these issues, there is currently no single widely supported or adopted standard for multi-platform, multi-domain and multi-service Command and Control. Current challenges for border practitioners in terms of C2 of border surveillance can be summarised by the following:
- Need to rationalize new investments in both assets and C2 systems not to jeopardize the significant previous investments in infrastructure and sensors;
Need to integrate new, often heterogeneous, assets in a coherent and consistent way with the existing C2 border surveillance systems;
Desire for widely supported standardized multi-platform, multi-domain and multi-service Command and Control;
Desire for reduction of footprint/space, power, logistic support and other costs associated with the acquisition and integration of unmanned vehicles from more than one operating domain in current border surveillance systems;
Desire for increased interoperability between border surveillance assets and systems in line with the vision of EUROSUR;
Ultimately, the capability to adequately address an increasingly complex threat environment.
The overarching scope of CAMELOT expressed above can be broken down into the following high level objectives:
Derive user requirements for a Multi-Service Multi-Domain Command and Control System (MSMDC2) for border surveillance (by involving at least 14 practitioners including partners and external entities);
Analyse and trade-off available MSMDC2 architectures and interface standards and select those more appropriate for a modular and scalable command and control system (a minimum of 7 architectures shall be analysed and considered);
Prototype service modules based on partners background that comply with the chosen architecture and support directly a border control user need (a minimum of 15 shall be considered;
Promote periodic integration, testing and validation cycles involving relevant end users to improve the human-machine interfaces and maximise service usability (minimum integration with 2 existing systems shall be pursued);
Design, prepare and run a demonstration campaign, involving the end users and relevant stakeholders to showcase the different services (minimum of 2 demonstrations – one on land and another at sea will be carried out and a minimum of 12 practitioners will be invited to observe);
It is important to highlight that the prosecution of the objectives above will require on the one hand the implementation of tools and frameworks over which the modules will run (as mentioned, there is currently no widely adopted standard meaning CAMELOT will need to carry out targeted development in this area) and on the other hand limited research and development in some modules which currently present a lower TRL but have been considered extremely relevant by end-users.
The work plan of CAMELOT reflects the activities considered essential to accomplish its objectives. As such it is organized in a straightforward way to enable the consortium to implement the blocks of CAMELOT in the shortest possible time span without generating undue pressure. The consortium has applied two drivers in the definition of the work plan:
Capability to map directly from objectives and proposed capabilities and services to palpable activities (this facilitates both the management and the reviewers’ jobs of verifying that the project delivers);
An organization that enables partners to progress independently (according to their own needs and resources) or in cooperation without jeopardizing the goal of demonstrating and validating the technical and economic viability of the services proposed.
By allocating one task to the deployment of each module the CAMELOT work plan fulfils the first bullet above. The inclusion of a WP specifically dedicated to testing and demonstration (WP9) complies with one of the requirements of the call and contributes to verifying another of the fundamental objectives of CAMELOT. Individual module functionality and implementation testing starts during implementation (WP4 through 7) and continues throughout the integration (WP8) and demonstration (WP9) where simple short workflows consisting of a couple of modules will be tested with existing C2 systems and larger demos with more complex workflows will be demonstrated. The grouping of modules into blocks fulfils the organization bullet enabling partners to cooperate by having them work under the same leadership in each WP and providing common timeframes while still providing the liberty for each to pursue their contributions according to their resources and needs.
In order to adequately implement the CAMELOT vision, two extremely relevant aspects remain to be tackled: the construction of the underlying environment and common tools which the modules need to run (the CAMELOT C2 framework) and how everything will come together for the demonstration and testing. The main constraint on the C2 framework is that it must be ready for use by the time the consortium aims to test and demonstrate the service modules. Hence, all framework aspects have been condensed in WP3, which runs in parallel to the service modules WPs. This work will be strongly influenced by WP2 and by running it in parallel modifications can be envisaged based on the progress of the service modules. A significant amount of time will be dedicated to the integration of the framework, tasking and service modules (WP8). This coincides with campaigns for the collection of real data for more realistic testing (WP9). Testing of simple short workflows involving a small number of services and more complex workflows (all designed in collaboration with the practitioners in WP2 and WP9) will follow. By this time the consortium can be fairly confident that the modules fulfil their functionalities and that the framework is capable of providing the underlying environment they need. While not all combinations of services and all types of workflows will be validated (not all will be relevant either), the CAMELOT consortium believes this approach is consistent with the objectives, possible H2020 timeframe and budgets. A timeframe of 45 months was considered sufficient for implementing the modules and adequate for keeping in pace with competing or similar efforts worldwide (i.e. no loss of market relevance). While CAMELOT does have a large number of WPs, the 11 proposed were considered an absolute minimum taking into account the width of services covered. The following figures provide a graphical representation of the WBS (Work Breakdown Structure) components and how they inter-relate.