EUROCAE ER-031 PDF

This document is split into two parts: the first one covering a technical investigation of the current status of the services expected to be provided in a U-Space airspace, although many can be envisaged in any airspace, even if not dedicated to unmanned traffic; and a second part focused on a technical justification on the need and convenience of creating an Interface Control Document defining a set of interfaces for the exchange of messages with information provided by the network identification services which could be used with either a distributed or centralised architecture solution for U-space systems.

SCOPE OF THE PART I: TECHNICAL INVESTIGATION

The focus is on the data required by regulation to be shared by USSPs, i.e., USSP interoperability: Network Id, UAS Flight Authorisations, Conformance Alerts (when the conformance monitoring service is required), and USSPs U-space services degradation States. However, other additional relevant data exchanges among stakeholders are also included, such as Geographical and Airspace Data, Airspace Permission and identity management.

Concerning USSP interoperability, there are two possible solutions: the exchange is done directly between USSPs (distributed or federated architecture), or indirectly through some common component (centralised architecture). Each Member State can select its architecture for USSP interoperability.

Decentralised/distributed architecture is assumed to follow the ASTM standards or at least their logic for the unspecified aspects of ASTM.

In order to have maximum interoperability across architectures of Member States for U-space systems, a set of common interfaces for each data flow would be necessary. The key point is to have a common Data Model and message format, but allowing, when deemed necessary, certain flexibility in terms of technical protocols to suit each solution in terms of performance and efficiency.

The scope is split between:

- Identity Management

- Geographical and Airspace data

- Traffic and telemetry

- Flight Authorisation

The responsibility/accountability of the various parts of the system are beyond the scope of this document, although they might differ from country to country, depending on the architecture chosen.

SCOPE OF THE PART II: TECHNICAL JUSTIFICATION OF A NEW ICD

This part presents the arguments discussed and agreed on the need and convenience of creating an Interface Control Document (ICD) defining a set of interfaces for the exchange of messages with information provided by the network identification services which could be used with either a distributed or centralised architecture solution for U-space systems.

The set of interfaces of the ICD, although designed to be compliant with the European regulatory framework for U-space, could be useful for exchanges of this information in other contexts where such exchanges are needed or convenient, such as outside U-space airspace in Europe, or in other types of airspace volumes anywhere, in the context of what is generically called UAS Traffic Management (UTM).