top of page

Traditionally, Unmanned Vehicles (UxVs) were being purchased with their own stovepipe control segment (Ground Control Station or ‘GCS’). These GCS were, and in many cases still are, typically closed systems utilising 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 rationalise 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 undergone 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.


The CAMELOT platform architecture is based on a distributed system that will offer 1) scalability, 2) availability and 3) security capabilities, as required by the end-users. The core of the system will be designed in a flexible and modular framework so that the implementation of new functionalities is easy and cost effective.


The high-level CAMELOT architecture is depicted in the below figure.

high-level CAMELOT architecture

The main modules integrated within the CAMELOT framework are:

  • Automatic Asset Tasking and Control (AATC) exposes different methods to control different assets connected to the platform.

  • Data Manager and Analytics (DMA) brings to the platform a set of advanced analysis and data management functionalities.

  • Camelot Core Layer contains all internal functionalities required by the platform to perform CAMELOT main capabilities. This module includes Mission-Related Services (MRS), Visualisation and Display Services (VDS) and Sensing and Detection Services (SDS).

  • Adapters ensure communication with assets that make use of different protocols and avoid ad-hoc implementation of the CAMELOT data model every time a new asset from a different provider is added to the system, protocol, adapters from the CAMELOT data model to a large set of protocols will be implemented.

  • Middleware will allow the CAMELOT beneficiaries to dene several OSI layers without having to manually program each one. This will allow faster implementation of the CAMELOT platform, guaranteeing the scalability, modularity and distributed characteristics that the consortium desires. Services will be accessible to the outside trough a pub/sub end point.

  • Camelot Authorisation Layer. The platform will expose different interoperability services accessible through a Virtual Private Network (VPN) that will allow the different C2 systems and GCSs to interact with the platform feeding and retrieving information or even consuming the available services.

  • Rest API Gateway allows to receive requests from both public internet and internal services and forward them to the best suited microservice instance. API Gateway come with a specific and helpful tool such as an authorisation module. It provides a solid layer of defence against user authentication or data validation.

  • C2 system allows end users to view and receive information from the different services available on the platform through a Pub/Sub EndPoint or Rest API Gateway. Within the platform there will be the possibility of interacting with the existing C2 that will have access to the services they are able to manage. On the other hand, CAMELOT's own C2 has been specifically developed so that it is compatible with all the services available within the platform.

bottom of page