IMPETUS Key Results

Drone information needs and service concepts

The bottom-up domain analysis captured users’ needs and characterised data requirements through specific use cases. Although many UTM service providers already compete on the market, they would benefit from a central U-space authority and harmonised structures throughout all of Europe.

Apart from the aeronautical data, most other information services would require higher fidelity information and/or additional service functions. Several gaps were also identified concerning some drone specific information categories, which neither existing data services in manned aviation, nor currently available UTM service providers covered.

One major conclusion was that many of the ‘apparently’ big differences between ATM and U-space have to do mainly with scale aspects and not so much with the nature of the functions and services involved in the operational picture.

One key of such specificities is the fact that the pilot, being remotely located, is deemed not to be able to safely handle safety-critical in-flight contingencies, which drives another major conclusion, that is the inescapable need for autonomy; however, any autonomous drone behaviour should be deterministic and predictable

Scale effects also require that the aeronautical, geospatial and weather information be significantly more detailed and diverse than the analogous information in use in manned aviation.

Logical and system micro-service-based architecture

There is an alignment between the needs of U-space (from both services and the different roles participating) and the objectives that an architecture built on micro-services aims to achieve (and that, using the proper configuration, can be implemented). The information processing capabilities, the high performance and the multiple connections between the consumers and data providers can be supported with an architecture based on micro-services in which each functionality can be atomized as estimated.

This requirements include:

• The capability of offering a common interface for clients and data sources based on a defined standard;
• The existence of a common information exchange layer which receives the information and, based on a set of predefined rules, redirected it to the proper consumer of information;
• The service discovery module in constant communication with the API gateway as a support to detect the new services available;
• A service layer in which containers are deployed, offering a certain functionality (or set of capabilities) in each module;
• The prerequisite that services’ internal structures can be implemented using different business approaches, depending on the interests of the U-space service provider;
• Storage units should be divided into a temporal cache for real-time processing, ensuring the availability of information and low latencies for crucial U-space services;
• An authentication layer must be provided, acting as a registration module in which the services, clients and data sources must be validated to be part of the ecosystem; and
• A configuration layer, in which the rules of the architecture are defined and the configuration parameters are set, so the system is capable of self-managing its own operation.

Experiments to test specific U-space services in a micro-service-based architecture

By design, the microservice-based architecture addresses most of the principles of the U-space architecture, that is, the proposed architecture is service-oriented, modular, or technology agnostic.

The U-space architectural principles which were further investigated by IMPETUS were:

Results per U-space Service tested

Probabilistic micro-weather service

Monitoring and traffic information service

Flight planning management service

Tactical de-confliction service

Although other algorithms could be used to implement dynamic separation, IMPETUS experiments allow detailing the key parameters which should be considered for the definition of separation standards.