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.
The gap analysis revealed that similar information is available in manned aviation, but not always sufficient for a direct usage in drone operations
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.
By bringing together all the information compiled bottom-up the analysis unveiled the so-called ‘domain invariant’
This allowed for the elaboration of a paradigmatic ‘drone operation life cycle’ that largely resembles that of a manned aerial operation except for some specificities inherent to UAS
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
An specificity of drone operations is the concern about security, privacy and insurance issues in addition to safety, which drives the need for U-space to consider mission-specific aspects of drone operations to the extent needed to cope with such new concerns.
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.
A key output of the project regarding micro-services was the elaboration of a list of requirements for the U-space architecture and the elicitation of its key features
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:
- Based on evolutionary development
- Feasible and cost-adaptive
Results per U-space Service tested
Probabilistic micro-weather service
The use of probabilistic micro-weather service, showed significant improvements over current, static weather forecast accuracy at 3h look-ahead time
Monitoring and traffic information service
Standardization in U-space environment is mandatory toallow users to have a complete, clear view of thescenario in which they are operating
Flight planning management service
The flight planning management service provided the minimum information on where a flight plan is in conflict with another, without the need to provide potentially business-sensitive data, all the while leaving the final decision on how to update the flight plan with the affected operator.
Tactical de-confliction service
IMPETUS provided some examples of how tactical de-confliction could be achieved for ‘Zu’-airspace. IMPETUS proposed a dynamic de-confliction which is based on the positive field theory concept. This concept consists of adding virtual “weights” to each drone depending on a series of characteristics, which in turn define the separation criteria
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.