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.
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:
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.