D4.3 -Preliminary U AIM CONOPS · STELLAR SESAR Tool Enabling coLLaborative ATM Research SWIM...

D4.3 - Preliminary U-AIM CONOPS

Deliverable ID D4.3

Project Acronym DREAMS

Grant: 763671 Call: H2020-SESAR-2016-1 Topic: RPAS-02: Drone information management Consortium coordinator: IDS Edition date: 29th March 2019 Edition: 00.01.01 Template Edition: 02.00.00

EXPLORATORY RESEARCH

EDITION 00.01.01

2

© – 2019 – IDS, TU Delft, EUROUSC, TOPVIEW SRL. All rights reserved. Licensed to the SESAR Joint Undertaking under conditions

Authoring & Approval

Authors of the document

Name/Beneficiary Position/Title Date

Massimo Antonini/IDS Team Leader 29/03/2019

Valerio Paciucci/IDS Contributor 29/03/2019

Marco Di Donato/IDS Contributor 29/03/2019

Reviewers internal to the project


Giuseppe Di Bitonto Project Coordinator 29/03/2019

Costantino Senatore / EuroUSC IT Team Leader 29/03/2019

Approved for submission to the SJU By - Representatives of beneficiaries involved in the project


Giuseppe Di Bitonto / IDS Project coordinator 12/04/2019

Massimo Antonini / IDS Team Leader 12/04/2019

Joost Ellerbroek / TU Delft Team Leader 12/04/2019

Alberto Mennella / TOPVIEW SRL Team Leader 12/04/2019

Costantino Senatore / EuroUSC IT Team Leader 12/04/2019

Rejected By - Representatives of beneficiaries involved in the project


D4.3 - PRELIMINARY U-AIM CONOPS


3

Document History

Edition Date Status Author Justification

00.00.01 29/03/2019 Candidate Draft M. Antonini

V.Paciucci Based on Draft 09

00.01.00 12/04/2019 Final draft version G. Di Bitonto Ready for submission

00.01.01 25/06/2’19 Release candidate M.Antonini Revision after CORUS

feedback

EDITION 00.01.01

4


DREAMS DRONE EUROPEAN AIM STUDY

This study is part of a project that has received funding from the SESAR Joint Undertaking under grant agreement No 763671 under European Union’s Horizon 2020 research and innovation programme.

Abstract

The purpose of the document is to lay down the conceptual foundation for Aeronautical Information Management U-AIM in support of the U-Space operational concept under definition at European Level.

This deliverable (D4.3) is a user-oriented document that describes the characteristics of a system from the user’s and operator’s perspective. The CONOPS is defined in terms of U-Space stakeholders directly addressed by UAS operations, roles and responsibilities, highlighting U-AIM data scope and flows, and related interactions with U-Space actors.

The document is based on the outcomes of the DREAMS project deliverables [6], [7], [8], [9] and [10].

D4.2 Gap Analysis Report ([9]) is the main reference. The preliminary definition of the U-AIM CONOPS (U-Space Aeronautical Information Management CONOPS) starts from the results of the gap analysis between the current available aeronautical information services from manned and unmanned aviation against the demands from drone operators/users.

The document specifically addresses the potential application of SWIM data models for aeronautical information (e.g. AIXM, FIXM, WXXM) and provides a proposal for their adoption in U-Space domain.

Moreover, additional information domains related to Aeronautical Information are analysed within this document in order to assess the influence/impact with other domains and to give to the reader some proposals about the several information data models to be considered in U-Space.



5

Table of Contents

Abstract ....................................................................................................................................4

1 Introduction ........................................................................................................................ 7

1.1 Purpose of the document ...............................................................................................7

1.2 Intended readership .......................................................................................................7

1.3 Abbreviation ..................................................................................................................7

2 Scope and approach ......................................................................................................... 10

3 U Space AIM data scope and stakeholders ..................................................................... 19

3.1 U-AIM intended benefits .............................................................................................. 19

3.2 U-AIM data scope ......................................................................................................... 20 3.2.1 Airspace and flow management data ......................................................................................................... 20 3.2.2 Aeronautical data............................................................................................................................................ 21 3.2.3 Environment and drone data........................................................................................................................ 22

3.3 Key Roles and Main Data Flows..................................................................................... 22 3.3.1 U-Space services, stakeholders and data mapping ................................................................................... 27

4 Information exchange model........................................................................................... 29

4.1 Existing Manned Aviation Information .......................................................................... 29 4.1.1 SWIM Information Exchange Models .......................................................................................................... 31

4.2 U-AIM DATA MODEL..................................................................................................... 34 4.2.1 Airspace and Flow manage ment data model ............................................................................................ 34 4.2.2 Aeronautical data model ............................................................................................................................... 42 4.2.3 Environment and drone data model ........................................................................................................... 51

5 Conclusions ....................................................................................................................... 66

6 References ........................................................................................................................ 67

List of Tables Table 1 - Data comparison between information demand and supply and “gap” identification ......... 18

Table 2 – Roles of U-Space Operational Stakeholders addressed in CORUS CONOPS ([74]) ............... 26

Table 3 - Services vs User Roles vs Data ......................................................................................... 28

Table 4 - Flight plan data model .................................................................................................... 35

Table 5 - Aeronautical data set ..................................................................................................... 43

Table 6 - Geofencing data model .................................................................................................. 49

EDITION 00.01.01

6


Table 7 - User basic data set ......................................................................................................... 52

Table 8 - User additional data set.................................................................................................. 53

Table 9 - Manufacturer data model ............................................................................................... 54

Table 10 - Drone model data model .............................................................................................. 57

Table 11 - Drone data model ........................................................................................................ 59

List of Figures

Figure 1: DREAMS project methodology ........................................................................................ 10

Figure 2: Scenario identification and requirement analysis approach .............................................. 11

Figure 3: Scenario #2 - Example of SORA methodology adoption (Intrinsic UAS Ground Risk Class matrix) ................................................................................................................................................... 12

Figure 4: U-AIM data scope .......................................................................................................... 20

Figure 5: CORUS Project identified Stakeholders ([74]) ................................................................... 23

Figure 6 - U-Space services ........................................................................................................... 26

Figure 7 - SWIM stakeholders ....................................................................................................... 29

Figure 8 - SWIM services.............................................................................................................. 30

Figure 9 - Tracking device ............................................................................................................. 38

Figure 10 - Tracking process......................................................................................................... 38

Figure 11 - AIXM 5.1 extension implementation............................................................................ 44

Figure 12 - Airspace extension ...................................................................................................... 44

Figure 13 - RunwayCenterlinePoint extension................................................................................ 45

Figure 14 - Aeronautical data distribution service .......................................................................... 47

Figure 15: e-Registration process .................................................................................................. 51

Figure 16 - e-Identification process ............................................................................................... 60

Figure 17 - e-Identification ........................................................................................................... 60

Figure 18 - e-Identification message protocol ................................................................................ 61

Figure 19 - e-Identification range .................................................................................................. 61



7

1 Introduction

1.1 Purpose of the document

This document represents the D4.3 contractual deliverable for DREAMS project as reported in the Grant Agreement (Annex 1 – Part 1 - WT2 list of deliverables).


1.2 Intended readership

This document is intended to be used by the DREAMS consortium and by SESARJU members. This document will be exchanged among U-space exploratory research sibling projects that have similar project goals (e.g. IMPETUS) and also with the project in charge of defining the U-Space Concept of Operations (CORUS).

1.3 Abbreviation

Acronym Meaning

ADS-B Automatic Dependent Surveillance - Broadcast

AGL Above Ground Level

AIXM Aeronautical Information eXchange Model

AIP Aeronautical Information Publication

AIRPROX Aircraft Proximity

AIS Aeronautical Information Service

ALARP As Low As Reasonably Practicable

ATC Air Traffic Control

ATM Air Traffic Management

ATZ Aerodrome Terminal Traffic Zone

B2B Business To Business

C&CC2 Communication Command & Control

CAA Civil Aviation Authority

CTR Control Traffic zone

CZML Cesium Markup Language

DAA Detect And Avoid

EDITION 00.01.01

8


DREAMS DRone European AIM Study

DTC Drone Traffic Controller

DTM Digital Terrain Model

EGNOS European Geostationary Navigation Overlay Service

ETSI European Telecommunications Standards Institute

FCU Flight Control Unit

FIXM Flight Information eXchange Model

FTS Flight Termination System

GA General Aviation

GCS Ground Control Station

GML Geography Markup Language

GNC Guidance Navigation Control

GNSS Global Navigation Satellite System

GTRF Galileo Terrestrial Reference Frame

HDOP Horizontal Dilution of Precision

IAB International Advisory Board

ICAO International Civil Aviation Organization

ISO International Organization for Standardization

M2M Machine To Machine

MSL Mean Sea Level

MTOM Maximum Take Off Mass

NAA National Aviation Authority

NAS National Airspace System

OGC Open Geospatial Consortium

QoS Quality of Service

RLOS Radio Line Of Sight

RPA Remote Piloted Aircraft

SES Single European Sky

SESAR Single European Sky ATM Research

SORA Specific Operational Risk Assessment

STELLAR SESAR Tool Enabling coLLaborative ATM Research

SWIM System Wide Information Management

TCL Technical Capability Level

TMA Terminal Areas



9

UA Unmanned Aircraft

UAS Unmanned Aircraft Systems

UML Unified Modelling Language

USS UAS Service Supplier

UTM Unmanned Traffic Management

V2I Vehicle to Infrastructure communication

V2V Vehicle to Vehicle communication

VLL Very Low Level

VTOL Vertical Take Off and Landing

WGS84 World Geodetic System 1984

WXXM Weather Information Exchange Model

XML eXtensible Markup Language

XSD eXtensible Schema Definition

EDITION 00.01.01

10


2 Scope and approach

The DREAMS (DRone European Aeronautical information Management Study) exploratory research project is aimed at contributing to the definition of the European UTM (U-Space) Aeronautical Information Management operational concept by exploring the needs for and the feasibility of new processes, services and solutions for drone aeronautical information management within the U-Space concept. From the perspective of the DREAMS project, U-Space is viewed as the key to enabling the concept for safe integration of drones within Very Low Level1 (VLL) airspace, tailored to the needs of drone operations. U-Space will accommodate various services, including acquisition, quality control and dissemination of relevant information, not limited to the current scope of AIS/AIM, since drones require additional information.

The above-mentioned project goal will be achieved through a series of intermediate results that will bring us closer to the final result in a clear and measurable way. These intermediate results are presented in three phases, namely, information discovery, defining a concept of operations for potential solutions and finally, a validation of the presented solutions. This document, D4.3, tackles the second phase, concept of operations. This document closes the second Phase of the project.

The approach adopted within the DREAMS project is synthetized as shown and briefly described below:

Figure 1: DREAMS project methodology

In the first phase a representative set of operational scenarios and related preliminary requirements of candidate U-space services involved have been identified, starting from the description of the state-of-the-art process that actual (and diligent) UAS operators implement for their aerial work operations, in accordance with applicable local regulations. The step-wise approach is synthetized in the following figure.

1 VLL is defined as the volume of airspace contained within 500 feet Above Ground Level (AGL). This was defined

by the European RPAS Steering Group in 2013.



11

Figure 2: Scenario identification and requirement analysis approach

Moreover an assessment from a safety point of view of the identified scenarios for both VLOS and BVLOS UAS operations has been performed, taking in consideration the services that could be provided to UAS Operators in the U-Space that included:

- a Preliminary Risk Assessment of the generic CONOPS, which is going to be the basis for the actual demonstration scenarios of the DREAMS project;

- verification of the regulatory compliance of the requirements related to U -Space service providers, taking into account current and expected future UAS regulations.

One of the risk assessment methodologies applied to the identified scenarios is SORA , with the high level objectives:

- Evaluating both Ground and Air Risk; - Identifying some general requirements in terms of required barriers (mitigations) and

robustness

As an example, below SORA methodology applied to the scenario#2:

EDITION 00.01.01

12


Figure 3: Scenario #2 - Example of SORA methodology adoption (Intrinsic UAS Ground Risk Class matrix)

In the second phase a catalogue of candidate services for U-Space purposes have been identified, starting from existing service catalogue available to manned aviation in ATM domain. Several information services were derived from SWIM services, open-source aviation services and commercial off-the-shelf services. Similarly, a study was carried out to determine the existing UTM/U -Space services present in the market, and a variety of services were deemed useful for U -Space.

The latest activity performed within the second phase of the project that is the main reference for this document is the Gap analysis. This activity identified the information gap between existing manned aviation and existing and future unmanned aviation and outlined a comprehensive set of solutions in order to bridge the gap, meant as recommendations for SESARJU and CORUS by the DREAMS consortium.

In particular, the gap (difference between supply and demand of data services) analysis ( [9]) captured data services that enable safe drone operations at Very Low Level (VLL) altitude airspace. The analysis concluded a gap in a wide range of data services within the information categories of: flow management, meteorological, environment, flight, surveillance, communication and drones (UAV) and proposed potential solutions to bridge the identified gaps.

One of the main outcomes of the gap analysis task ([9]) is that a significant gap in the desired and available information services required for safe drone operations in low altitude airspace does indeed exist. A thorough review of existing data services from manned and current UTM service providers was performed in D4.1 ([10]). The former and latter were then compared against the demands from drone operators/users identified from a targeted extensive online survey, a comprehensive reference scenario analysis (performed in [7]), the high-level U-Space services and lastly the consortium expertise. To bridge this gap in drone information services requirements for safe drone flight operations in very low altitude airspace, a set of proposed solutions have been outlined. The key outcomes of gap analysis activity are summarized below:



13

• Drone operator/user requirements were formulated with respect to a systems engineering approach which comprised of unique identifiers and with specific lexicon. This was a request from SESARJU to encode requirements in such a manner.

• The aeronautical information supply comprised of defined and implemented aviation data services provided by SWIM (for SESAR demonstrations only) and Open Source services and existing unmanned data services from UTM/U-Space services providers.

• The drone information demand for safe flight operations in very low altitude operations was amalgamated from the drone operator/user requirements from an extensive survey analysis, a comprehensive reference scenario analysis and the consortium’s expertise on the subject matter.

• The information supply and demand were compared in order to determine gaps in the data services.

• Attention was given to urban environment operations since it is deemed the most challenging to execute due to the large number of constraints such as dense obstacles both static and dynamic, uncertain urban atmospheric conditions and uneven terrain layouts.

• One of the many gaps identified is the provision of information real-time manned traffic. Ensuring safe separation between unmanned and manned traffic is critical with respect to safe integration. This gap is even more evident in an urban environment, especially at VLL in uncontrolled airspace. In this situation, it would be challenging to capture in real-time the position of manned traffic, especially helicopters which are not fitted with ADS-B transmitters. This problem can be solved by mandating all aircraft flying in VLL to be equipped with ADS-B transmitters.

• An important gap that needs to be addressed by U-Space are the data services required to achieve capacity management of high-density traffic. A proposed solution to this is: Geovectoring. As geofencing and geocaging tells a drone “where to fly”, geovectoring tells a drone “how to fly”. The data protocols for geovectoring will urgently need to be addressed for information exchange in order for geovectoring to be implemented as a mandatory service for drone flights. This protocol would be similar to the geofencing/geocaging, albeit with additional information on speed vectors.

One of the outcomes of the gap analysis task is synthetized in the following table. The green shaded cells in represent information that is sufficiently available and could be re-used for drone flight. Contrarily, the amber shaded cells indicate the available information is insufficient/inadequate or, it would need additional refinement for safe drone flight operations by additional requirements coming from U-Space community. The two information supply columns of manned aviation information and information by UTM service providers indicate that the data services are available only if it is marked in green. Similarly, the column of “U-Space services” represents information services that would enable or fulfil the respective U-Space deployment level. Finally, the two remaining columns represent the explicit demands derived from the survey analysis and the scenario identification process. Importantly, the table highlights some of the identified gaps in the data supply.

EDITION 00.01.01

14


Information categories Information supply Information demand

Manned aviation UTM

Service Provider

U-Space Services

Survey results

Scenario Identification

Air

spac

e an

d fl

ow

man

agem

ent

dat

a

Air

spac

e m

anag

em

en

t d

ata Controlled airspace

data AIXM X U1 X X

Hyperlocal airspace data

X

Flig

ht

Pla

nn

ing

and

Flo

w M

anag

em

en

t d

ata

Urban airspace

capacity management

U3 X

High-density traffic management

X

De-confliction management

FIXM X U1/U2 X X

Congestion management

FIXM X

Urban airspace intrinsic and strategic conflict risk reduction

X

First/Last 50ft operations

X



15

Drone delivery hub capacity management

X

Advisory of

uncontrolled traffic X

Flight planning assistance X X U2 X X

Flight risk analysis X

Optimal altitude allocation

X

Vertical separation guidance

X

Horizontal separation guidance

X

ATM-UTM sector boundaries awareness

X U1 X

Real-time telemetry X

Contingency management

U2 X X

Emergency management

NOTAM U2 X

Real-time unmanned traffic

data

X U2 X X

Real-time manned traffic data

Open source data – ADS-B

data U2 X X

EDITION 00.01.01

16


Traffic monitoring (state and intent information)

Open source data (manned traffic)- ADS-B

data

X U2 X X

Aer

on

auti

cal d

ata

Stat

ic A

ero

nau

tica

l d

ata

Permanent obstacle data AIXM X U1 X X

Airports/Heliports AIXM X U1 X

Static geofencing AIP ENR 5 X U1/U2 X X

Dyn

amic

Ae

ron

auti

cal

dat

a

NOTAM management

NOTAM X

Non-permanent obstacle data NOTAM U2 X X

Dynamic geofencing NOTAM/Digital

NOTAM X U3 X X

Dro

ne

Ae

ron

auti

cal

dat

a

Hyperlocal airspace data

X



17

Envi

ron

men

t an

d d

ron

e d

ata

Envi

ron

me

nt

dat

a

Past, present, future

hyperlocal weather information

WXXM X U2 X X

Sudden atmospheric

warning: wind gusts U2 X X

3D elevation maps State

provisioning

Open source

services X

Population density of overflown areas

X

GNSS coverage map AIXM/XML X X

4G/5G coverage map

X X

Dro

ne

typ

e c

har

acte

rist

ics

and

pe

rfo

rman

ce d

ata

ATC-Drone

operator/User communication link

U2 X X

U-Space user chat service

X

High quality video datalink

X

Law enforcement U1 X X

Authorities U1

Drone incident support

X

Vehicle performance characteristics

X X

Vehicle

specifications X

EDITION 00.01.01

18


Vehicle serial number

X

Maintenance checklist

X X

Battery health status X X

Mission planning X U1 X X

Mission logbook X U1 X

Table 1 - Data comparison between information demand and supply and “gap” identification



19

3 U Space AIM data scope and stakeholders

3.1 U-AIM intended benefits

The U-AIM is conceived to deliver consistent, accurate and up-to-date UTM data set for the U-Space Stakeholders with the following direct benefits:

• Reduced Safety Risks: Potential hazards can arise from inconsistencies in U-space services information, from difficulties in interpreting multiple data sources, from out of date information and from the lack of dynamic updates in digital data sources. Having consistent, complete, accurate and up-to-date information will reduce the likelihood of such hazards arising for U-Space. The provision by the U-AIM of advanced pre-flight capabilities (based on the availability of digital static and dynamic data (e.g. NOTAMs, integrated MET and geo-referenced maps) will also reduce the risk of drone pilots missing safety critical NOTAM information and will increase their awareness.

• Increased Efficiency: Inclusion of all needed static and dynamic information in the digital data sets will enable automated systems to improve airspace access possibilities and drone flight efficiency, which may be due to imprecise information. The intent of U-AIM is to offer functional and operational benefits, both tangible and intangible, to the U-Space community:

- digital format of aeronautical data and information allows a fast dissemination of digital data and information, to maintain the integrity of the data and to tailor the information according to the different U-Space stakeholders, thus increasing operational value;

- the adoption of open standards and SWIM data models makes information more readily integrable with other information sources and other information domains, thereby increasing the operational value of the information;

- Geo-referenced maps and graphics contribute to guarantee coherence between information elements and between different information layers, thus increasing operational value and achieving greater transparency into data quality issues;

- shared situational awareness to ready access to aeronautical information by all (authorized) stakeholders;

- better situational awareness and hence decision making by drone pilots based on the availability during in-flight phase of more real-time and relevant aeronautical information

- different economic models in the provision of U-Space aeronautical information domain contribute to keep aeronautical information affordable to its end users;

- more precise dynamic data contribute to improve the accuracy of the performance calculations done by drone operators and their service providers;

- enable U-airspace management solutions to achieve the most efficient use of airspace by providing consistent up-to-date airspace situation;

- improve the ability of drone operators to take advantage of airspace availability based on accurate and updated airspace status information.

- enhanced planning and pre-flight services featuring static and dynamic digital data (e.g. NOTAM), weather data, and graphical displays;

EDITION 00.01.01

20


- Improve airspace planning activities U-airspace manager in order to enhance available capacity and reduce the need for airspace restrictions.

- Increase consistency and quality of the U-AIM data for all U-Space actors resulting in data fit for daily drone operations;

- Enable a reliable airspace demand and capacity calculation thus allowing the effective detection and resolution of capacity imbalances.

3.2 U-AIM data scope

From a top-level perspective the U-AIM data scope can be broken down as shown in the following figure:

Figure 4: U-AIM data scope

3.2.1 Airspace and flow management data

Such category is divided into the following data:

• VLL Airspace management data is the dynamic airspace and drone corridors/routes management data, such as:

o VLL airspace reservation or drone corridors/routes data, which can be allocated after a coordination /negotiation in a flexible way on the basis of U-Space stakeholders needs or without prior coordination/negotiation

o dynamic activation, de-activation or real-time reallocation of portion of VLL airspace according to priorities and airspace users privileges

• Flight planning and flow management data: the Flight planning and flow management data is

the data used by U-AIM stakeholders for flight planning and flow management purposes. These data rely on or are strongly correlated with the Aeronautical data and are made up of consistent, coherent, and complete information necessary for flight plan validation and for Trajectory computation, where applicable, to quantify traffic demand and to resolve potential capacity imbalances.



21

3.2.2 Aeronautical data

The Aeronautical data includes:

• Static aeronautical data by national AISP up to date to the current AIRAC cycle. This includes the subset of data of interest for drone operation in U-Space domain, and related portions of airspace. A non-exhaustive list is reported below :

o Airport ARP;

o CTR;

o Civil and military ATZ;

o Prohibited areas

o Restricted areas

o Dangerous areas;

o TMA;

o Paratroopers activity areas;

o Military shooting polygons;

o Aerobatic flight activity areas;

o Aeroclub activity areas;

o National park areas;

• Dynamic aeronautical data by national AISP: NOTAMs impacting drone operations in U-space. This may include:

o the establishment of a new restricted, dangerous, prohibited, etc. area or navigation warning, which did not exist as a published (static data) airspace;

o the establishment of a new temporary ATS area, which did not exist as a published (static data) airspace. This can take the form of a specified airspace type (such as a CTR);

o the temporary closure of an airport/heliport. The closure can be total (any traffic is forbidden) or partial (with the exception of particular operations, flights or aircraft categories).

o The temporary closure of a runway. The closure can be total (any traffic is forbidden) or partial (with the exception of particular operations, flights or aircraft categories).

o The establishment or withdrawn of a new temporary or permanent vertical obstacle.

NOTAM related to the temporary opening or closure of one or more route portions or the unavailability of a ground based radio navigation equipment and service and other NOTAM types are outside the scope of U-AIM.

• Drone aeronautical data can include:

o drone specific restrictions triggered by non-aviation related events. This data can include temporary or permanent No-Fly zones and U-NOTAM for example due to, for

EDITION 00.01.01

22


example, a crowded event or sensitive areas (e.g. power plants, archaeological sites, …).

o Protection area around Airports without ATZ and take-off and landing surfaces to avoid potential interference with approaching and/or departing manned aircrafts.

o VLL Airspaces and drone routes/corridor data defined, validated and published within U-Space domain, in coordination with ATM/ASM, where needed.

3.2.3 Environment and drone data

• A non-exhaustive list of data types included in the Environment data category is reported below:

o digital terrain and permanent and non-permanent obstacle data (e.g. DTM; DSM) for the drone operation, with different precisions from different sources;

o nowcast weather information and weather forecast for small drones operations in VLL airspace related to turbulence/wind/wind shear, barometric pressure, icing, precipitation, temperature, visibility;

o geomagnetic data (e.g. Kp index disturbance index) that can provide useful information related to potential disturbance on GNSS-based drone navigation capabilities;

o cellular network coverage and related service level data; o density of population data.

• Drone type characteristics and Performance data includes model, characteristics and performance publication that enable the implementation of several U-Space services and stakeholders (e.g.: e-registration, Drone operation plan processing, Police or security agent) and that, where needed, can be used for flight trajectory computations.

3.3 Key Roles and Main Data Flows

Before identifying the U-space stakeholders addressed in the present CONOPS, below the list of operational stakeholders and roles addressed in the CORUS Project CONOPS ( [74]) is reported. A stakeholder is a party that has an interest in U-Space. Operational stakeholder, are those actively consuming and/or providing services of U-space. For this class of stakeholders, roles have been identified.



23

Figure 5: CORUS Project identified Stakeholders ([74])

EDITION 00.01.01

24


Stakeholders Role

Drone pilot aka UAS Pilot, Pilot in Command (PIC) or Remote Pilot, It is responsible for the safe execution of the flight according to the U-space rules, whatever it is recreational or professional with one of the different license levels, according to the typology of the drone used. (Recreational Drone Pilot, Professional Drone Pilot). It expects:

• more efficient flight preparation, including getting permission (easier, quicker and more efficient);

• safer and more efficient flight execution due to improved situational awareness in all operations – VLOS and BVLOS

The person being registered in the pilot registry. A pilot is a human being, currently. The registry should be able to record some information about the pilot’s qualification; mentions different levels of qualification. The drone pilot should be able to update some parts of his/her registry entry, such as changing his/her address and he/she may be allowed to create the record initially. How he/she interacts: User of geo-fence definitions during flight; User of situation awareness computed from the dynamic online traffic situation based on maintained tracks; User of weather nowcast to assist him in the in-flight phase; the person receiving warning and alerts from the monitoring service.

Drone crew The drone pilot or any person following the drone’s progress during flight. This term generalises the pilot, any kind of dispatcher, any mission specialist. Additional recipient of messages about flights. Drone Pilot Assistant. It is assisting the piloting in its duty. Observer. It is assisting the piloting in its duty, e.g. during EVLOS operations.

Drone operator representative

Aka UAS operator being registered in operator registry. An operator representative is a legal entity; meaning a natural person or a business. An operator representative has contact details. How he/she interacts: User of geo-fence definitions during flight planning, User of situation awareness computed from the dynamic online traffic situation based on maintained tracks, Generalised actor that submits a flight plan, the person receiving warning and alerts from the monitoring service.

Drone owner representative

When any drone is registered, it will have a registered owner. An owner is a legal entity; meaning a natural or a business. An owner representative has contact details. How he/she interacts: User of drone registration.

ATS Operator ATS should have access to the air-situation generated from e-identification reports, with the usual controller-working-position tools to filter out those of no interest, give conflict alerts and so on. Main roles: AT Controller, Tower Supervisor, Tower Runway controller, Tower Ground controller, (A)FIS and RIS Operator. How he/she interacts: User involved to achieve the interface with ATS.



25

Police or security agent Security actors would be interested in the air situation, to identify operators and to apply relevant procedures. Law enforcement Unit, responsible to develop law enforcement methods related to illegal drone use. How he/she interacts: User of registration, e-identification and interested in the situational awareness and monitoring alerts.

Pilot It is the pilot of glider, parachutist, paraglider, ballon, GA, military flight which share the airspace (even if occasionally) in VLL operations. How he/she interacts: In some environments, user of situational awareness and monitoring alerts.

Citizen Generic person who wants to be aware of drone operations impacting its privacy. How he/she interacts: a kind of authorised viewer of air situation

Registrar A registrar has a legal duty to operate a registry securely, reliably and adequately. The registrar will be a legal person, probably with staff. How he/she interacts: who may intervene in case of problems in the registration.

Accredited registry updater

This category groups together pilot training schools, LUC issuers, nominated agents of the courts and any others who have the power to create, read, update or delete registry entries in any way – which may be very restricted for some. How he/she interacts: User of (operator/school/pilot) registrations.

Accredited registry reader

This category groups the police, accident investigators, other agents of the authorities or anyone else who might need – and be given permission - to look into the registry. (or registries). How he/she interacts: Who may query registration information.

Drone Aeronautical Information Manager

A body that is independent of the Aeronautical Information Office and allows drone specific aeronautical information to be registered, combines the information and then published the result.

Drone specific aeronautical Information originator

The person or representative of the organisation that creates drone specific aeronautical information. This actor is accredited and trained in the processes of creating, updating or deleting drone specific aeronautical information. This is reflecting the possibility to have a different originator of “constraints” for drones.

Authorised viewer of air situation

This groups actors like U-space operators, city authorities and some others such as researchers who can be trusted with the commercially sensitivities of the overall air situation. How he/she interacts: Who may be allowed to have a situational awareness according to privileges and privacy.

USSP Supervisor Being the level of automation high, it is not envisaged the role of “Controller”. Nevertheless, it has been envisaged a person who will arbitrate or impose a solution in some cases (in case of escalation required) who may intervene manually imposing ad-hoc solutions or taking over other USSP roles.

Authorization Workflow Representative

A person having the rights to participate in the authorization workflow (e.g. when local authority/USP/NAA must express the approval or does not object).

Capacity Authority A person receiving warning and alerts from the monitoring service Responsible for setting the minimum safe operating conditions that

EDITION 00.01.01

26


determine the capacity of an airspace or an aerodrome due to safety Responsible for setting noise level limits that limit capacity due to noise footprint and “dose”

Drone Manufacturer Representative

It is responsible for drone registration and using the system for all other obligations the drone manufacturer must comply (e.g. drone model/characteristics/performance publication).

Airport Operator Representative

It is responsible for interacting with the system to protect airport perimeter (anti drone) to contribute to the safe integration of drones in airspace, especially in airport vicinity. It will responsible to establish proper coordination with other relevant stakeholders.

Table 2 – Roles of U-Space Operational Stakeholders addressed in CORUS CONOPS ([74])

Below the list of operational stakeholders addressed by the present preliminary U -AIM CONOPS. The list includes a subset of the stakeholders listed in [74] and other actors defined within the present document:

Figure 6 - U-Space services



27

3.3.1 U-Space services, stakeholders and data mapping

Service Stakeholder Data

e-Registration Drone pilot Drone operator Drone owner Registrar Accredited registry updater Drone Manufacturer Police or security agent

User Data Drone Data

e-Identification Police or security agent Drone Data User Data Flight Plan Data

Geofencing Pre-tactical Tactical

Dynamyc

Drone operator Drone pilot Drone specific aeronautical Information originator

Geofencing Data

Drone Aeronautical Information Drone pilot Drone operator ATS Operator Drone Aeronautical Information Manager Drone specific aeronautical Information originator

Aeronautical data in several format (AIXM, GeoJson, KML, CSV, map,…)

Weather Information Drone pilot Drone operator ATS Operator

Weather data in several format (WXXM, Json, Map, …)

Tracking Police or security agent Tracking Data

Flight Planning Drone pilot Drone operator Drone crew Authorization Workflow Representative

Flight Plan data

Strategic Deconfliction Authorization Workflow Representative

Monitoring Authorised viewer of air situation ATS Operator Police or security agent Pilot Capacity Authority Airport Operator Representative

Emergency Drone pilot Drone operator

Traffic information Authorised viewer of air situation Citizen ATS Operator Police or security agent

Traffic Data

EDITION 00.01.01

28


Pilot

Procedural Interface with ATC Airport Operator Representative

Collaborative interface with ATC Airport Operator Representative

Tactical de-confliction USSP Supervisor Capacity Authority Drone pilot

Flight Plan data

Dynamic capacity management USSP Supervisor Capacity Authority

Table 3 - Services vs User Roles vs Data



29

4 Information exchange model

One of the high level principles of U-Space at architectural level, is the adoption of a component-based architecture that relies on published or standardized interfaces based on SWIM principles.

We consider existing System Wide Information Management (SWIM) information exchange model, such as the Aeronautical Information Exchange Model (AIXM) for aeronautical data exchange (e.g. NDZ, LDZ,….), Flight Information Exchange Model (FIXM) for flight data exchange (e.g. manage and represent drone flight plans and flight traffic data) and other structured EUROCONTROL Surveillance Information eXchange (ASTERIX) as technical enablers for drone traffic management in U-Space. One of the main benefits, is to ease the connection with existing ATM systems and to contribute to integration and interoperability between the manned and the unmanned world.

The results of the analysis related to the potential adoption of SWIM data exchanges models ( AIXM, WXXM and FIXM) in U-Space domain, is reported at par. 4.2.

4.1 Existing Manned Aviation Information

With the implementation of SWIM, existing manned aviation information services are currently undergoing a paradigm shift in how information is managed along its complete life-cycle and across the European ATM system.

The implementation of SWIM has been conceived to enable all stakeholders to share the right information to the right stakeholders at the right time. The SWIM stakeholders are depicted in Figure 7 and further described below.

Figure 7 - SWIM stakeholders (by EUROCONTROL)

The type of information shared on a SWIM network include:

• Aeronautical – information originating from the assembly, analysis and formatting of aeronautical data;

• Flight trajectory – detailed 4D route data of aircraft;

EDITION 00.01.01

30


• Aerodrome operations (Environment) – status of various aspects of the airport, including approaches, runways, taxiways, gate and aircraft turnaround time information;

• Meteorological – information on the past, current and future state of earth’s atmosphere relevant for air traffic;

• Air traffic flow – network management information required to understand the overall air traffic and air traffic services situation;

• Surveillance – positioning information from radar, satellite navigation systems, aircraft datalinks (ADS-B transmitters);

• Capacity and demand – information on the airspace users’ needs of services, access to airspace and airports and the aircraft already using it.

Figure 8 summarizes the above enlisted SWIM services into a concise diagram.

Figure 8 - SWIM services (by EUROCONTROL)

The objective of SWIM is to improve interoperability in ATM using common technologies, standards and best practices. Examples of these are AIXM, common Internet Protocols and web services, and a common Service-Oriented Architecture. Interoperability is achieved through the use of common specifications to implement the service interfaces used for information exchange among ATM stakeholders. The coordinated development of these specifications is achieved through common governance, undertaken by SWIM stakeholders. In addition, there are common infrastructure components that support the implementation of SWIM. Such common infrastructures include the SWIM service registry, and the Public Key Infrastructure. The latter SWIM service registry is used for publication and discovery of information comprising of service consumers/providers, the logical information model, SWIM enabled services, business, technical, and policy information. At present, there exist various registries operating under their own governance in d ifferent regions. For this reason, there are efforts on the way to create compatible registries following the guidance laid forth by ICAO SWIM document in order to reduce costs and maximize competition between the information providers and allowing them to be global. The concept of SWIM is progressively being implemented by various regulatory bodies in Europe and in the US by EUROCONTROL and the FAA.



31

4.1.1 SWIM Information Exchange Models

In order to enable exchange of the SWIM information amongst the stakeholders, three data exchanges models are used: AIXM, WXXM and FIXM.

4.1.1.1 AIXM

The aim of the Aeronautical Information Exchange Model (AIXM) is to enable the provision in digital format of the aeronautical information that is in the scope of Aeronautical Information Services (AIS). These AIS information/data flows are increasingly complex and made up of interconnected systems that involve a variety of factors, including multiple suppliers and consumers. In addition, globally there is a growing need in the global ATM system for high-quality data and at the right cost.

To meet the demands of this increasingly automated environment, AIS is gravitating towards digital data. The AIXM therefore supports this transition by enabling the collection, verification, dissemination and transformation of digital aeronautical data throughout the data chain and especially in the segment that connects AIS with the next intended user.

Within the scope of AIXM there exist seven key information areas:

• Aerodrome/Heliport including movement areas, services, facilities, etc.

• Airspace structures

• Organisations and units, including services

• Points and Navaids

• Procedures

• Routes

• Flying restrictions

AIXM takes advantage of established information engineering standards and supports current and future aeronautical information system requirements.

The latest version can be found at http://aixm.aero/page/aixm-51-511

4.1.1.2 FIXM The Flight Information Exchange Model (FIXM) is a data exchange model capturing Flight and Flow information that is globally standardized. FIXM was developed to support information exchange for Flight and Flow data identified by ICAO as part of the Flight and Flow Information for a Collaborative Environment (FF-ICE) concept. In addition, the evolution of FIXM is linked to the ICAO vision for the development, review, approval, publication and applicability of FF-ICE packages.

FIXM can be compared as an equivalent to the flight domain of AIXM and WXXM in which both were developed to achieve global interoperability for, respectively, AIS and MET information exchange. Therefore, FIXM is part of a family of technology-independent, harmonized and interoperable information exchange models developed to satisfy the information needs of Air Traffic Management. Importantly, FIXM is one of the models that belong to the Information Exchange Models layer in the SWIM global interoperability framework.

http://aixm.aero/page/aixm-51-511

EDITION 00.01.01

32


Hence, FIXM consists of flight information items that satisfy ICAO requirements for flight information exchanges. These include:

• Flight plans

• Flight trajectories

• Aircraft information

• Equipment compatibility etc.

The current release of FIXM is 4.1.0 and it can be found at: https://www.fixm.aero/fixm_410.pl

4.1.1.3 WXXM

The Weather Information Exchange Models and Schema (WXCM-WXXM-WXXS) are designed to enable a platform independent, harmonized and interoperable meteorological information exchange covering all the needs of the air transport industry. WIXM was developed by the US FAA and the European Organisation for the Safety of Air Navigation (EUROCONTROL) with support from the international community.

This WXXM specifications support the data-centric environment. It supports MET information collection, dissemination and transformation throughout the data chain.

Moreover, WIXM has three primary components:

• The conceptual Information Model (WXCM)

• The Logical Data Model (WXXM)

• The Exchange Schema (WXXS)

The WXCM-WXXM-WXXS capitalizes on existing and emerging information engineering standards and supports current and future aeronautical meteorological information system requirements.

The major principles are:

• Support for the latest ICAO and other user requirements for meteorological information by one single representation;

• Alignment with ISO standards for geospatial information, including the use of the Geography Markup Language (GML);

• Alignment with OGC best practices for geospatial information, including the Observation and Measurement model;

• Modularity to support future requirements.

The core idea behind WXXM is to have standard data containers such as weather observations and weather reports that satisfy the needs of the aviation industry but also serve some of the needs from future specifications. WXXM includes some top-level data containers which represent all standard airport weather reports that are in use for example METARs and TAFs. These two standard weather reports are equivalent to the typical en-route weather reports such as the SIGMETs.

https://www.fixm.aero/fixm_410.pl



33

Moreover, WXXM are communicated using an XML schema and many of the providers of weather information use generic standards at the service interface level making their interfaces compatible with Web Features Service (WFS).

The latest version of WXXM can be found at: http://wxxm.aero/page/documents-0

http://wxxm.aero/page/documents-0

EDITION 00.01.01

34


4.2 U-AIM DATA MODEL

In the framework of this paragraph, the proposal of data model for each category identified in Figure 4 is provided. In the next sub-paragraphs are included only those data models that have been deemed involved in the scope of DREAMS project, which belongs to the Topic 02: Drone Aeronautical Information Management. They are a subset of data identified in the paragraphs 3.2.1, 3.2.2 and 3.2.3.

As described in Chapter 2, Figure 1, the data model defined shall be used to feed the final phase of the project, in particular the Validation activities. Indeed such data model shall be subject to development and implementation in the simulation platforms used to execute validation exercises.

Such data models can be applied to one or more U-space service.

4.2.1 Airspace and Flow management data model

4.2.1.1 Flight Plan Data

This service covers the reception of a flight notification or a flight plan and provides the appropriate answer according to the characteristics of the mission and applicable regulations.

This service receives flight plans from operators, performs a validation using configured rules defined by the CAA regulation and answer the operators with an approval (authorization to fly) or a rejection (motivated with the list of violated constraints) of the submitted flight plan. In the following table is reported the not exhaustive list of properties to be considered for the flight plan data model.

Property Type Constraints Description

id Integer not null, unique Numeric identifier by the flight plan (generated by the system)

name string not null Mnemonic description of the flight plan

description string Textual description of the flight plan

operationType enumeration not null It can be: VLOS, EVLOS, BVLOS, AUTONOMOUS

flightType enumeration not null It can be: RECREATIONAL, PROFESSIONAL

etd date not null Estimated takeoff time

duration integer not null Duration of the flight (min)

altitudeMax integer not null Max altitude of the flight (ft)

status enumeration not null Flight Plan status. It can be: DRAFT, DECLARED, WAIT_FOR_AUTHORIZATION, AUTHORIZED, NOT_AUTHORIZED, REJECTED,



35

CANCELLED, ACTIVE, SYSTEM_ACTIVE, PAUSED, EXPIRED, COMPLETED, SYSTEM_COMPLETED

ownerId string not null Identifier of the owner of the flight plan

ownerUsername string not null Name of the owner of the flight plan

locationType enumeration not null Type of flight plan geometry. It can be: POINT, LINESTRING, CIRCLE, POLYGON

geom geojson not null Geometry description of the flight plan

radius Integer The radius of the circle in case of circular area (m)

center geojson The center pont of the circle in case of circular area

droneId string not null Identifier of the drone

droneName string not null Mnemonic name of the drone

droneSN string not null Drone serial number

pilotId string not null Identifier of the pilot

pilotUsername string not null Username of the pilot

pilotPhoneNr string not null Reference phone number of the pilot for this flight plan

Table 4 - Flight plan data model

Example

{ "id": 951, "name": "Power line Inspection", "description": null, "operationType": "VLOS", "flightType": "RECREATIONAL", "etd": "2019-03-22T10:34:26.551Z", "duration": 30, "altitudeMax": 200, "status": "DRAFT", "ownerId": "IT-FDSA-4WETRE534R", "ownerUsername": "user", "locationType": "POLYGON", "geom": { "type": "Polygon", "coordinates": [ [

EDITION 00.01.01

36


[ 12.145042419433594, 42.062803063740546, 0 ], [ 12.213020324707031, 42.05362648434583, 0 ], [ 12.214393615722654, 42.032719325654824, 0 ], [ 12.151222229003906, 42.01563154037739, 0 ], [ 12.119979858398438, 42.04087903536128, 0 ], [ 12.145042419433594, 42.062803063740546, 0 ] ] ] }, "radius": null, "droneId": "IT-LMJH-8F9G00EER", "droneName": "MyDrone", "droneSN": "SN-900378", "pilotId": "IT-GK5K-KIRNM6MQ2", "pilotUsername": "user", "pilotPhoneNr": "+393201837564" }

4.2.1.2 Tracking Data

The tracking is the ability of a service provider to maintain track-identity of individual drones. It relies on ground and air systems. The performance requirements of the service will vary in accordance with the specific requirements of each application.

Unlike the e-Identification, for which it is required to identify the drone at low distance, the tracking allow users to monitor drone position for any kind of operations (VLOS, EVLOS and BVLOS). To reach this goal, other kind of technologies have been analysed in order to satisfy at least the following requirements:

• Tracking device shall be installed on C1, C2 e C3 UAS class (ref. EASA Opinion 2018/01)

• Tracking device shall support one or more of the following communication devices: LORA, Wifi, Bluetooth, 3G/4G LTE, IRIDIUM



37

• Tracking device weight shall be ALARP taking into account that it will be installed on UAS with MTOW>250g

• Tracking device shall be installed in a way that does not compromise stability of UAS

• Tracking device shall include an accessible (e.g. USB) re-chargeable power supply

• Tracking device shall be compatible with UAS operations from electromagnetic point of view (no interference)

• The configuration of Tracking device shall be executed by UTM Client through at least one of the following channel: USB, Bluetooth, Wi-fi.

• Tracking device shall calculate its own position through GNSS (GPS, GLONASS, Galileo, EGNOS)

• Tracking device shall provide its own height referenced to a specific Reference level (MSL, AGL,...)

• Tracking device shall be able to fix its position with an accuracy less than 9.99m in 95% of time

• Tracking device shall be equipped with sensors able to determine Barometrical Altitude and Height to the ground (AGL).

• Tracking device shall be equipped with Inertial reference Unit

• If no connection is possible, the system shall buffer the data and transmit it when the connection shall be available again

• Tracking device during BVLOS scenarios shall provide the following data for tracking purposes:

✓ timestamp; ✓ ID; ✓ position in Latitude and Longitude; ✓ Altitude ✓ UTM link quality ✓ status of UAS (normal/Emergency)

Taking into account these requirements three type of tracking device versions have been identified based on the performance required for the type of the flight/operation to be execute: Basic, Advanced and Professional version. The figure below shows the differences of the three versions.

EDITION 00.01.01

38


Figure 9 - Tracking device

The tracking data can be sent via different channels/protocols like Bluetooth, LoRa and Wi-Fi using a Gateway receiver on ground, equipped with 4G/LTE connection to transmit the data over the network, or directly by 4G/LTE on board capability. Once the tracking data has been received on ground, it’s sent to the Tracking service provided by DTM Platform for allowing correlation of data like Drone detail, Operator information, Flight Plannning and Authorizations.

Figure 10 - Tracking process



39

During the DREAMS validation exercises might be used also alternative tracking solution provided by exchange protocols provided by GCS service.

EDITION 00.01.01

40


4.2.1.3 Traffic Data

Once the drone identification and position data has been received and elaborated by the Tracking service, it has to be distributed to all the stakeholders with a specific data model. The service which has in charge this task is the Traffic information service.

4.2.1.3.1 Manned tracks

During the Gap analysis, we identified for manned tracks an open source service ( OpenSky Network) which will be used for validation purpose

The OpenSky Network is a community-based receiver network which continuously collects air traffic surveillance data. Unlike other networks, OpenSky keeps the collected raw data forever and makes it accessible to researchers. With over ten trillion ADS-B and Mode S messages collected from more than 1000 sensors around the world, the OpenSky Network exhibits the largest air traffic surveillance dataset of its kind. The documentation can be found at https://opensky-network.org/

There are several functions available to retrieve state vectors, flights and tracks for the whole network, a particular sensor, or a particular aircraft.

Example query with bounding box covering Switzerland:

https://opensky-network.org/api/states/all?lamin=45.83&lomin=5.99&lamax=47.82&lomax=10.52

The response is a JSON object with the following properties

Property Type Description

time integer The time which the state vectors in this response are associated with. All vectors represent the state of a vehicle with the

interval [time−1,time][time−1,time].

states array The state vectors.

The “states” property is a two-dimensional array. Each row represents a state vector and

contains the following fields:

Index Property Type Description

0 icao24 string Unique ICAO 24-bit address of the transponder in hex string representation.

1 callsign string Callsign of the vehicle (8 chars). Can be null if no callsign has been received.

2 origin_country string Country name inferred from the ICAO 24-bit address.

https://opensky-network.org/

https://opensky-network.org/apidoc/index.html#state-vectors

https://opensky-network.org/api/states/all?lamin=45.83&lomin=5.99&lamax=47.82&lomax=10.52

https://opensky-network.org/apidoc/index.html#state-vectors



41

Index Property Type Description

3 time_position int

Unix timestamp (seconds) for the last position update. Can be null if no position report was received by OpenSky within the past 15s.

4 last_contact int

Unix timestamp (seconds) for the last update in general. This field is updated for any new, valid message received from the transponder.

5 longitude float WGS-84 longitude in decimal degrees. Can be null.

6 latitude float WGS-84 latitude in decimal degrees. Can be null.

7 baro_altitude float Barometric altitude in meters. Can be null.

8 on_ground boolean Boolean value which indicates if the position was retrieved from a surface position report.

9 velocity float Velocity over ground in m/s. Can be null.

10 true_track float True track in decimal degrees clockwise from north (north=0°). Can be null.

11 vertical_rate float Vertical rate in m/s. A positive value indicates that the airplane is climbing, a negative value indicates that it descends. Can be null.

12 sensors int[] IDs of the receivers which contributed to this state vector. Is null if no filtering for sensor was used in the request.

13 geo_altitude float Geometric altitude in meters. Can be null.

14 squawk string The transponder code aka Squawk. Can be null.

15 spi boolean Whether flight status indicates special purpose indicator.

16 position_source int Origin of this state’s position: 0 = ADS-B, 1 = ASTERIX, 2 = MLAT

EDITION 00.01.01

42


4.2.1.3.2 Unmanned tracks

Regarding the Drones tracks information distribution, DREAMS has implemented a service that will be used for the validation exercises and that provides the following data set.

Property Type Description

identifier string Unique Drone Identifier

time_position int Unix timestamp (seconds) for the last position update.

longitude float WGS-84 longitude in decimal degrees. Can be null.

latitude float WGS-84 latitude in decimal degrees. Can be null.

baro_altitude float Barometric altitude in meters. Can be null.

status int Drone status (Authorized, Unauthorized, …)

Flight Plan Id int Flight Plan Identifier

OperatorId Int Operator identifier

PilotId Int Operator identifier

OwnerId Int Owner Identifier

4.2.2 Aeronautical data model

4.2.2.1 Aeronautical data

Regarding the aeronautical data, the standard format currently used in the manned aviation is the AIXM 5.1. The U-Space aeronautical data identified in the chapter 3.2.1 are partially covered by the AIXM 5.1 data model. The following table shows the coverage of the AIXM 5.1 with the aeronautical features needed for U-Space:



43

Table 5 - Aeronautical data set

For the new features, the outcome of our analysis is that the AIXM 5.1 can be still used for b2b data exchange, to implement the new features or for extending the existing ones for the following reasons:

• It uses OGC GML 3.2.1 (for complex geometry specification) (ISO 19136) • It implements the temporality model • It implements Metadata (ISO 19139) • It defines Feature Identification and Reference • It is natively extensible (for adding new attributes on current features or adding new

features) • It is ADQ compliant • It is self-documented (by XSD schema) • It supports additional complex constrains (by business rules)

Of course, due to its complexity and verbosity it is not the best choice for web/mobile/on board device data exchange for which we think it is better to make use of more compact data format like GeoJson or CZML resolving all the complexity of AIXM information server side. To support this thesis, hereafter It is reported an example of implementation of a new aeronautical feature identified for U-Space needs using AIXM 5.1 format and GeoJson format.

EDITION 00.01.01

44


4.2.2.1.1 AIXM 5.1 implementation

In order to extend AIXM 5.1 Default features or for defining new ones, it is necessary to create an extension of the basic AIXM 5.1 schema as shown in the following example; a new extension file (DREAMS_extension.xsd) has been created in order to define 5 types of extension related to Airspace, AirportHeliport, Runway and RunwayCenterLinePoint features:

Figure 11 - AIXM 5.1 extension implementation

After that, we can use the new extensions of the features as shows in the following figures related to Airspace and RunwayCenterLinePoint:

Figure 12 - Airspace extension



45

Figure 13 - RunwayCenterlinePoint extension

4.2.2.1.2 GeoJson implementation

As we stated before, it is possible to implement the same features using another data format (e.g GeoJson) for “thin client” data exchange purpose. In this case the service providing this kind of data has in charge to resolve all the aspects related to “temporality” validity of the data (timeslices), data interpretation (BASELINE, PERMDELTA, TEMPDELTA), unit of measure conversions according to specific unit of measurement reference (e.g. feet, wgs84, date format), geometry resolution (especially for compound airspaces), metadata and extra data (managed by AIXM 5.1 extensions). Hereafter is an example in geoJson format of the same Airspace and RunwayCenterlinePoint described in the previous figures:

Airspace { "id": "02ad4faf-07f5-4d96-8165-cf9da499b387", "designator": "LIPO", "type": "ATZ", "name": "BRESCIA MONTICHIARI", "valid_from": "2016-10-28T00:00:00", "valid_to": null, "lower_limit_ft": 0, "upper_limit_ft": 500, "txtrmk_loc": "1) WI Verona CTR", "geom": { "type": "Polygon",

EDITION 00.01.01

46


"coordinates": [ [ [ 8.699722222, 45.73110722655348 ], [ … ], … ] ] } }

RunwayCenterlinePoint { "id": "0404db6f-3507-4e69-9b1c-9938cd6f2a6a", "designator": "LIPO", "role": "THR", "valid_from": "2016-10-28T00:00:00", "valid_to": null, "location": { "type": "Point", "coordinates": [ 12.739911111, 41.995052778 ] }, "takeOffAndLandingArea": { "type": "Polygon", "coordinates": [ [ [ 10.378330556, 45.390101667 ], [ … ], … ] ] } }

A service providing Aeronautical data has to be polyglot in terms of data formats that is able to handle, in order to satisfy client requests as at least the two data formats described above (AIXM and GeoJson).

The Aeronautical data service used for the DREAMS validation exercises make use a customization of Geoserver in order to be able to provide data in several geospatial formats. In particular, an AIXM plugin has been developed in order to handle this format for the features considered for the exercises.



47

Figure 14 - Aeronautical data distribution service

4.2.2.2 Geofencing Data

The service provides the operator with geo-information about predefined restricted areas (prisons, etc.). According to the EASA NPA 2015-10 regulation, Geofencing means automatic limitation of the airspace a drone can enter. In principle, the feature is already embedded in some commercially available drones. There are relatively simple two-dimensional (2D) solutions possible requiring some manual update, and in the future the principle might be applicable in a dynamic way to support operators and pilots in complying with temporarily limitations or even local needs, e.g. to create a safe bubble around a rescue helicopter when landing at the accident site.

To ensure safety, environmental protection, and security and privacy, the competent authorities can define ‘no-drone zones’ where no operation is allowed without authority approval, and ‘limited-drone zones’ where drones must provide a function to enable easy identification and automatic limitation of the airspace they can enter and should have a limited mass.

According to the EASA regulation opinion (No 01/2018) [38], the term geo-awareness will be used as synonym of U-Space Pre-tactical geofencing because this function is for awareness only, to support the remote pilot in complying with the limitations in the area defined by the MSs. The term ‘geo-fencing’ has been replaced by ‘geo-awareness’ to better reflect the nature of the requirement already proposed in the NPA. It is preferable to give to the UAS operator full responsibility for flying the UA in areas away from prohibited or restricted zones.

EDITION 00.01.01

48


In order to satisfy the geofencing service needs, the following requirements have been identified:

1. Definition and management of “no-drone zones” and “limited-drone-zones” through:

a) Airspaces information relevant for Drone operation (from 0 to 500 ft) coming from Aeronautical Information Publication.

b) Additional “no-drone zones” and “limited-drone-zones” defined by competent Authorities

2. Publication of “no-drone zones” and “limited-drone-zones” through a web service in order to allow operators, applications and drones to consume such information.

In the following table is reported the not exhaustive list of properties to be considered for the geofencing data model.



49


Id Integer not null, unique Numeric identifier of the geofencing area (generated by the system)

name string not null Mnemonic description of the geofencing area

source enumeration not null Origin of the geofencing area definition. If can be: FIRE_DEPARTMENT, POLICE_DEPARTMENT, CIVIL_PROTECTION, LAW_ENFORCEMENT, LOCAL_AUTHORITY, CAA, OTHER

description string Textual description of the geofencing area

Owner string not null Owner (username) of the geofencing area

Status enumeration not null It can be: DRAFT, PUBLISHED

minAltitude date not null Min altitude of the geofencing area (ft)

maxAltitude integer not null Max altitude of the geofencing area (ft)

startTime integer not null Effective Start date/time of the geofencing area

endTime enumeration not null Effective End date/time of the geofencing area

locationType enumeration not null Type of flight plan geometry. It can be: POINT, LINESTRING, CIRCLE, POLYGON

Geom geojson not null Geometry description of the flight plan

Radius Integer The radius of the circle in case of circular area (m)

Center geojson The center pont of the circle in case of circular area

Table 6 - Geofencing data model

EDITION 00.01.01

50


Example

{ "id": 1001, "name": "Coverage", "source": "FIRE_DEPARTMENT", "description": null, "owner": "nfz", "status": "PUBLISHED", "minAltitude": 50, "maxAltitude": 150, "startTime": "2019-03-08T17:22:26.754", "endTime": "2019-03-29T17:22:00", "locationType": "POLYGON", "radius": null, "geom": { "type": "Polygon", "coordinates": [ [ [ lon, lat ] ] ] } }



51

4.2.3 Environment and drone data model

4.2.3.1 e-Registration Data

The e-registration service enables the registration of the operator/pilot/drone with the appropriate information according to Regulation. A level of security of the service will be defined. According to the EASA regulation opinion (No 01/2018) [38], the registration would only be mandatory for UAS operators who conduct UAS operations using UAS with MTOMs greater than 250 g (classes C1, C2, C3 and C4). Registrations of single UA will no longer be required, unless, following the risk assessment required for operations in the ‘specific’ category, a certificate of airworthiness (CofA) of the UA is required. The very minor additional action and cost that operators would face would be for the fire-resistant placard that they would need to apply to the UA. Since it is expected that some of the services offered by U-Space will also require the unique identification of the UA, a standardised format for the UA SN has to be clarified in the technical requirements of EASA regulation UAS operators that use a UAS with an MTOM, including payload, of more than 250 g, shall:

1. register themselves, in a manner and format established by EASA (e.g. 10-digit UAS operator

registration number) 2. register the UA when the UAS concerned has been issued a certificate of airworthiness or a

restricted certificate of airworthiness (only for UAS operations in the ‘SPECIFIC’ category) 3. update their registration every time data is changed and renew the registration as required

by the competent authority 4. display the registration information on the UAS 5. ensure that this information is inserted into the electronic identification system, if available

on the UA or on an add-on device in order to be transmitted during the flight.

In order to satisfy the registration needs, it was identified the following process.

Figure 15: e-Registration process

Figure 12 shows the following steps:

1. Drone is purchased (with its own unique SN) 2. Drone Operator register himself using the online Certificate Authority e-Registration service. 3. Certificate Authority validates the operator’s email address, phone number, name, and

address. Certificate authority issues an PKI certificate for that operator.

EDITION 00.01.01

52


The certificate includes a unique identifying number, e.g. 10-digit UAS operator registration number and a fully qualified domain name, known as a Remote ID URL, where authorities can access basic information about the registrant (city, state, country).

4. The operator registration number is inserted into the electronic identification system, if available on the UAS or on an add-on device

5. The operator can now start flying being sure that the drone will transmit its identification data in broadcast

6. Any other Drones purchased subsequently by the same operator can be inserted the same operator registration number into the electronic identification system.

4.2.3.1.1 User Data

In this section is reported the set of data to be considered for the user registration according to his/her role.

The Basic data set is reported in the following table.

Table 7 - User basic data set

Additional data set can be defined for pilot/operator users – see following table.


company string Company name company_address string Company address

company_mail string Company mail address cc_number string Credit card number


Id String not null, unique User identifier (created by the system)

username string not null, unique Mnemonic string identifier

firstname string User first name lastname string User last name

email string not null User email address phone_number string User phone number

email_certified boolean Specify if the email address is certified

Id_front_image byte array Identification document front image

Id_back_image byte array Identification document back image

image byte array User profile image

activated boolean not null Specify if the account is active

authorities list of string List of system roles associated to the user



53

cc_expiration_date date Credit card expiration date

cc_cvv int Credit card CVV number

licence_number string User licence

licence_country_of_issue string Country of issue of the licence

licence_issue_date date Licence issue date

licence_expiration_date date Licence expiration date insurance_company String Insurance company

insurance_number String Insurance number insurance_expiration_date date Insurance expiration

date Table 8 - User additional data set

Example of Basic data (Json format)

{ "activated": true, "authorities": [ "PILOT" ], "email": "[email protected]", "emailCertificated": false, "firstName": " Katherine", "id": "IT-KMF-9FMST4T", "image": "iVBORw0KGgoAAAANSUhEUgAAAm8AAACWCAYAAACING9wAAAABHNCSVQICAgIfAhkiA…",

"lastName": "Wilson", "username": "kwilson", "phoneNr": "+39 0633217450" }

EDITION 00.01.01

54


4.2.3.1.2 Drone Data

The data set to be considered for the drone registration are the drone manufacturer, the drone model and the drone itself. Therefore, during the drone registration the user has to specify from a prepopulated catalogue, which is the manufacturer and the model of the drone that he intends register. The following sections describe these three data models.

4.2.3.1.2.1 Manufacturer


id integer not null, unique Manufacturer numeric identifier (created by the system)

name string not null, unique Manufacturer string identifier

type string Manufacturer company type industry string Type of industry

addressHeadquarter string Manufacturer headquarter address

adddressLegalSite string Manufacturer legal site address

registeredMail string Manufacturer email vatCode string Manufacturer vat code

establishYear integer Manufacturer establish year founder string Name of the founder

ceo string Name of the CEO

divisions string Divisions of the company shareCapital real Share Capital (k$)

revenue real Revenue (k$) employNumber enumeration It can be: 1-10, 11-100, 101-500,

500+

qualityCetification string Description of quality certification

website string web site address

contacts string Any contact logo byte array Manufacturer logo image

Table 9 - Manufacturer data model

Example

{ "id": 2, "name": "DJI", "type": "", "industry": "Unmanned aerial vehicle, Propulsion system, Flight platform", "addressHeadquarter": "14th Floor, West Wing, Skyworth Semiconductor Design Building, No.18 Gaoxin South 4th Ave, Nanshan District, Shenzhen, China, 518057", "addressLegalSite": "14th Floor, West Wing, Skyworth Semiconductor Design Building, No.18 Gaoxin South 4th Ave, Nanshan District, Shenzhen, China, 518057", "registeredMail": "", "vatCode": "", "establishYear": 2006,



55

"founder": "Frank Wang", "ceo": "Frank Wang", "divisions": "China, Japan, North America, Europo, Chile", "shareCapital": 100000, "revenue": 5000, "employNumber": "OVER500", "qualityCertification": "", "webSite": "http://www.dji.com", "contacts": "Phone: +86 (0)755 26656677 E-mail: [email protected]", "logo": "/9j/4AAQSkZJRgABAQAAAQABAAD/2wCEAAkGBwgHBgkIBwgKCgkLDRYP… " }

EDITION 00.01.01

56


4.2.3.1.2.2 Drone Model performance


Id integer not null, unique Model numeric identifier (created by the system)

buildType enumeration not null It can be: QUADCOPTER, HEXACOPTER, FIXED_WING, GENERIC

code string not null Model code connectivityNotes string Notes of connectivity capability

fcsModel string Model of the Flight Control System

flightRange string Flight range (km)

gcsModel string Model of the Ground Control station

gcsNotes string Note of GCS

generalNotes string General notes height real Height of the drone model (cm)

horizHoverAccGPS real Horizontal Hover Accuracy GPS (m)

horizHoverAccVision real Horizontal Hover Accuracy Vision (m)

imagingNotes string On board Camera notes imagingPresence Boolean not null Is camera on board?

length real Length of the drone model (cm)

manufacturerId integer not null Identifier of the manufacturer of the drone model

maxAscentSpeed real Max Ascend Speed (m/s)

maxDescentSpeed real Max Descend Speed (m/s) maxFlightTime integer not null Max Flight Time (min)

maxHorizontalSpeed real not null Max Horizontal Speed (m/s) maxHumidity real Max Humidity (%)

maxPayload real Max payload (kg) maxServiceAltitude real Max Service Altitude (m)

maxTakeoffAltitude real Max Takeoff Altitude (m)

maxTemp real Operational max temperature (°C)

minTemp real Operational min temperature (°C)

model string not null String identifier of the drone model

mtow real not null Max Takeoff Weight (kg)

picture byte array Drone model image powerSupply enumeration not null It can be: ELECTRIC,

COMBUSTION, HYBRID

satPositioningGLONASS boolean not null GLONASS drone model capability



57

satPositioningGPS Boolean not null GPS drone model capability

satPositioningGalileo boolean not null Galileo drone model capability vertHoverAccGPS real Vertical Hover Accuracy GPS (m)

vertHoverAccVision real Vertical Hover Accuracy Vision (m)

weight real Drone model weight

width real Drone model width windToleranceGusts real Wind Tolerance Gusts (m)

windToleranceSteady Real Wind Tolerance Steady (m) Table 10 - Drone model data model

Example { "id": 2, "model": "Phantom 4", "code": "P4", "weight": 1.4, "maxPayload": 0.5, "mtow": 1.9, "maxHorizontalSpeed": 20, "maxAscentSpeed": 6, "maxDescentSpeed": 4, "length": 35, "width": 35, "height": 30, "buildType": "QUADCOPTER", "maxFlightTime": 28, "powerSupply": "ELECTRIC", "satPositioningGPS": true, "satPositioningGLONASS": true, "satPositioningGalileo": false, "vertHoverAccGPS": 0.5, "horizHoverAccGPS": 1.5, "vertHoverAccVision": 0.1, "horizHoverAccVision": 0.3,

EDITION 00.01.01

58



Id string not null, unique

Drone identifier (created by the system)

Name string not null, unique

Mnemonic name of the drone

serialNumber string not null, unique

Serial number of the drone

uasCode string Drone code identifier (generated by the system)

uasCodeGenTime date Drone code generation date usage enumeration not null It can be: RECREATIVE,

PROFESSIONAL

status enumeration not null It can be: READY_TO_FLY, DEACTIVE, UNDER_ MAINTANANCE

fcsSerialNumber string not null Flight Control System serial number

gcsSerialNumber string not null Ground Control Station serial number

owner string not null Drone owner (username)

qrCodeImage byte array QR Code image

qrCodeGenTime date QR Code generation date paymentStatus enumeration not null Registration payment status. It can

be: NONE, COMPLETE, EXPIRED

paymentTime date Registration payment date

"minTemp": 0, "maxTemp": 40, "windToleranceSteady": 10, "windToleranceGusts": 10, "maxHumidity": null, "flightRange": 5, "maxTakeoffAltitude": 2500, "maxServiceAltitude": 3000, "fcsModel": "FCSModel2", "gcsModel": "GCSModel2", "gcsNotes": "", "imagingPresence": true, "imagingNotes": "Sensor 1/2.3 CMOS Effective pixels:12.4 ImageSize: 4000x3000 Video UHD: 4096x2160 (4K) 24 / 25p", "connectivityNotes": "", "generalNotes": "", "picture": null, "manufacturerId": 1 }

4.2.3.1.2.3 Drone



59

administrativeStatus enumeration not null Administrative status of the Drone registration. It can be: OK, NOT_OK

modelId integer Model Identifier Table 11 - Drone data model

Example { "id": "IT-GFD-4TRE5GB", "name": "MyDrone", "serialNumber": "SN-900378", "uasCode": “ITA1234567”, "uasCodeGenTime": “2019-03-22T10:34:26.551Z”, "usage": "PRIVATE", "status": "READY_TO_FLY", "fcsSerialNumber": "SN-847563", "gcsSerialNumber": "NS-548473", "owner": "user",

"qrCodeImage": "/9j/4AAQSkZJRgABAQAAAQABAAD/2wCEAAkGBwgHBgkIBwgKCgkLDRYP… ", "qrCodeGenTime": “2019-03-23T12:24:06.001Z”, "paymentStatus": "NONE", "paymentTime": null, "administrativeStatus": "OK", "modelId": "432" }

4.2.3.2 e-Identification Data In this chapter will be described one possible solution for e-Identification based on an open solution able to satisfy the requirements for this topic.

Regarding the e-Identification, we based on the following requirements:

• Identification is needed for the following reasons:

✓ SAFETY: manned aviation, population, infrastructures

✓ SECURITY: zone infringements, malevolent acts, privacy

• Identification enforces registration

• Registries are managed at national level (short term) and/or at international level (mid/long term). Common information will be accessible by other nations, specific information remains restricted to a nation

• Basic information for e-Identification: ID, position, Altitude/Height, timestamp, Remote ID ULR (service URLS for identification details)

• Data integrity, cyber-security, data protocol

• E-Identification can be an add-on or built-in device of the drone based on private key certificates that can be loaded by the manufacturer.

EDITION 00.01.01

60


In order to satisfy the e-Identification needs, it was identified the following process:

Figure 16 - e-Identification process

1. Drone broadcasts a digitally signed identifying number, Remote ID URL, location, and timestamp to those on the ground. An internet connection, such as LTE, can also be used, but local broadcast allows for data exchange in areas with limited or no data coverage.

2. Users may view the drone’s ID number and Remote ID URL. Members of the general public can use the drone’s ID number to report issues to authorities, but cannot access personally identifying operator details.

3. Based on the accessibility of the network connection, it will possible by law enforcement to have detail information on UAS and its operator through the Operator, Drone and Flight Planning registries.

Taking into account these requirement and statements, we identified a possible solution described in the next chapter.

4.2.3.2.1 Open Drone ID

Open Drone ID is a project to provide a low cost and reliable “beacon” capability for drones so that they can be identified when within range of a receiver. The current specification is based on Bluetooth* Legacy Broadcasts Packets (Advertisements), the new Bluetooth 5 (long range) Advertising Extensions, and WiFi implementation advertisements based on Neighbor Awareness Network protocol. A network access APIs are under development.

Such advertisements can be used by the general public, law enforcement, critical infrastructure managers, ATC, or other drones to give better situation awareness of the airspace around them.

Figure 17 - e-Identification



61

The information (messages) sent is divided into static and dynamic data where the static data is broadcast less frequently than dynamic data. These messages are “connectionless advertisements” that do not require any acknowledgement from the receiver.

Figure 18 - e-Identification message protocol

While WiFi and Bluetooth Legacy has a range limit of 200-400m (depending on obstructions and radio interference), Bluetooth 5 long range can go 4x the distance. In the Open Drone ID Bluetooth Broadcast specification, the intent is to broadcast in a way that basic receivers (like current cell phones) will work as well as (high gain) ground-based and new phone receivers that can take full advantage of the range improvements with the newer standards.

Figure 19 - e-Identification range

This project will provide an open specification as well as code examples to enable quick implementation of the specification.

4.2.3.3 Weather data

Another important data set to be considered in U-Space is the weather (now cast and forecast).

Many official weather service providers available on the web distribute their weather data mainly in Json or map formats in order to be easily consumed by any client. For this reason, even though the WXXM still remain a valid and standard format for distributing this information in ATM and that can

EDITION 00.01.01

62


be reused in U-Space, we considered as valid alternative the Json and map ones because are easier to use and can give several type of information compared by the ones provided by WXXM.

For the DREAMS validation exercises, we decided to use OpenWeatherData as weather service provider of which we report the subset of information we used.

4.2.3.3.1 OpenWeatherData

• Current weather data

API call: api.openweathermap.org/data/2.5/weather?lat={lat}&lon={lon} Examples of API calls: api.openweathermap.org/data/2.5/weather?lat=35&lon=139 API response:

{

"coord":{"lon":139,"lat":35},

"sys":{"country":"JP","sunrise":1369769524,"sunset":1369821049},

"weather":[{"id":804,"main":"clouds","description":"overcast clouds","icon":"04n"}],

"main":{"temp":289.5,"humidity":89,"pressure":1013,"temp_min":287.04,"temp_max":292.04},

"wind":{"speed":7.31,"deg":187.002},

"rain":{"3h":0},

"clouds":{"all":92},

"dt":1369824698,

"id":1851632,

"name":"Shuzenji",

"cod":200

}

• 5 day / 3 hour forecast data

You can search weather forecast for 5 days with data every 3 hours by geographic coordinates. All weather data can be obtained in JSON and XML formats.

API call: api.openweathermap.org/data/2.5/forecast?lat={lat}&lon={lon} Examples of API calls: api.openweathermap.org/data/2.5/forecast?lat=35&lon=139

http://samples.openweathermap.org/data/2.5/weather?lat=35&lon=139&appid=b6907d289e10d714a6e88b30761fae22

http://samples.openweathermap.org/data/2.5/forecast?lat=35&lon=139&appid=b6907d289e10d714a6e88b30761fae22



63

API response:

{"city":{"id":1851632,"name":"Shuzenji",

"coord":{"lon":138.933334,"lat":34.966671},

"country":"JP",

"cod":"200",

"message":0.0045,

"cnt":38,

"list":[{

"dt":1406106000,

"main":{

"temp":298.77,

"temp_min":298.77,

"temp_max":298.774,

"pressure":1005.93,

"sea_level":1018.18,

"grnd_level":1005.93,

"humidity":87,

"temp_kf":0.26},

"weather":[{"id":804,"main":"Clouds","description":"overcast clouds","icon":"04d"}],

"clouds":{"all":88},

"wind":{"speed":5.71,"deg":229.501},

"sys":{"pod":"d"},

"dt_txt":"2014-07-23 09:00:00"}

]}

4.2.3.3.2 IBL

IBL's “Visual Weather” (https://www.iblsoft.com/ ) is the flagship software for weather data processing, and most importantly it is already used by number of weather services and ATM operators within Europe. As one of its most important features, it has built-in OpenGIS services for on-line integration of weather data into other systems, including aviation industry applications.

https://www.iblsoft.com/

EDITION 00.01.01

64


For this SWIM Master Class 2014 IBL provides Visual Weather web services with live data, including the first implementation of WCS 2.0.0 MetOcean Extension and WMS 1.3.0 MetOcean Best Practice. Using these, a real-time queries can be made for current and forecasted weather situation as graphical maps, or as gridded information hypercube.

Interface Operation GetMap Description This is a request for actual image. The request parameterization consists of several logical parts: service, layers, dimensions, geolocation and output. Sample Request https://swim.iblsoft.com/wxmaps?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&LAYERS=temperature&CRS=CRS:84&BBOX=-180,-90,180,90&WIDTH=800&HEIGHT=480 Service SERVICE is always set to WMS, REQUEST to GetMap, VERSION to any of supported (described in response to GetCapabilities request). Dimensions Available dimensions varies over different layers. They are stated in more detail in the response to GetCapabilities request). They typically select particular data in time and vertical extent:

• time - a time in ISO 8601 format for which the data is valid (for example 2014-06-23T14:15:00Z)

• elevation - elevation in units of isobaric surface [hPa] (for example 850) • reference_time - a time in ISO 8601 format at which a numerical weather prediction

model was computed (for example 2014-06-23T14:00:00Z)

Dimensions follow the OGC Best Practice for using Web Map Services (WMS) with Time-Dependent or Elevation-Dependent Data (1.0).

http://www.google.com/url?q=http%3A%2F%2Fswim.iblsoft.com%2Fwxcube&sa=D&sntz=1&usg=AFQjCNHUg9nNAj2gcHP_dA9UO3_e7D-r0g

http://www.google.com/url?q=http%3A%2F%2Fswim.iblsoft.com%2Fwxmaps&sa=D&sntz=1&usg=AFQjCNGbDo2yLiBLwTTy0yXIaWEFSN4O5Q

http://www.google.com/url?q=http%3A%2F%2Fswim.iblsoft.com%2Fwxmaps&sa=D&sntz=1&usg=AFQjCNGbDo2yLiBLwTTy0yXIaWEFSN4O5Q

https://www.google.com/url?q=https%3A%2F%2Fswim.iblsoft.com%2Fwxmaps%3FSERVICE%3DWMS%26VERSION%3D1.3.0%26REQUEST%3DGetMap%26LAYERS%3Dtemperature%26CRS%3DCRS%3A84%26BBOX%3D-180%2C-90%2C180%2C90%26WIDTH%3D800%26HEIGHT%3D480&sa=D&sntz=1&usg=AFQjCNFw7jysdq7OLRvUjuJ1X8QlB5et8g

https://www.google.com/url?q=https%3A%2F%2Fswim.iblsoft.com%2Fwxmaps%3FSERVICE%3DWMS%26VERSION%3D1.3.0%26REQUEST%3DGetMap%26LAYERS%3Dtemperature%26CRS%3DCRS%3A84%26BBOX%3D-180%2C-90%2C180%2C90%26WIDTH%3D800%26HEIGHT%3D480&sa=D&sntz=1&usg=AFQjCNFw7jysdq7OLRvUjuJ1X8QlB5et8g



65

Layers One or more layer names may be specified as argument to LAYER parameter.

1. Observations and Remote Sensing Data

Layer Name Layer Title

metar METAR and SPECI Observations

at-radar-reflectivity-maximum

Real Time Weather Radar Maximum Reflectivity

at-radar-reflectivity-cappi Real Time Weather Radar Constant Altitude Reflectivity

2. Aviation Hazard Products

Layer Name Layer Title

sigwx-kkci-swh WAFC Washington SIGWX High Levels

sigwx-kkci-swm WAFC Washington SIGWX Medium Levels

sigmet Graphical SIGMETs

airmet Graphical AIRMET

volcanic-ash-advisory Volcanic Ash Advisories

tc-advisories TC Advisories

EDITION 00.01.01

66


5 Conclusions


In par. 3.2, the U-AIM data scope has been defined by arranging three main categories:

• Airspace and flow management data, which includes Airspace management, Flight planning and flow management;

• Aeronautical data, which includes Static, Dynamic and Drone aeronautical data;

• Environment and drone data.

The mapping among such data categories and the operational stakeholders, who actively consume and/or provide services of U-space has been performed in order to identify the typical data flow.

Starting from the analysis conducted in D4.2 “Gap Analysis report” and the existing manned aviation information models, a set of U-AIM data models has been defined.

The proposal of data model for each category identified in Figure 4 is provided. In particular, only those data models that are involved in the scope of DREAMS project, (Topic 02: Drone Information Management) have been included. They are a subset of data identified in the paragraphs 3.2.1, 3.2.2 and 3.2.3. The data models defined shall be used to feed the final phase of the project, in particular the Validation activities. Indeed, such data model shall be subject to development and implementation in the simulation platforms used to execute validation exercises. These activities shall be documented in D5.1 “Platform updating and integration report”.

Specifications of data model have been proposed, using also practical examples in different protocols/languages.

This document might provide useful information for:

• Contributing to the next version(s) of CORUS CONOPS;

• DTM platform provider, to benefit of the analysis conducted in order to define the data set needed to implement (as provider or consumer) a specific U-space service;

• Other stakeholders (e.g. drone operator, data source provider, Regulatory body) to identify potential standard to be applied on data and services of U-space ecosystem.



67

6 References

[1] SESAR U-space Blueprint, http://www.sesarju.eu/sites/default/files/documents/reports/U-space%20Blueprint.pdf

[2] SESARJU, European ATM Master Plan: Roadmap for the safe integration of drones into all classes of airspace, https://www.sesarju.eu/sites/default/files/documents/reports/European%20ATM%20Master%20Plan%20Drone%20roadmap.pdf

[3] Mckinsey, 2017. Commercial drone are here: The future of unmanned aerial systems. https://www.mckinsey.com/industries/capital-projects-and-infrastructure/our-insights/commercial-drones-are-here-the-future-of-unmanned-aerial-systems (16 August 2018).

[4] SESAR, SJU, 2016. European drones outlook study 2016. https://www.sesarju.eu/sites/default/files/documents/reports/European_Drones_Outlook_Study_2016.pdf

[5] Global UTM Association, 2017. Global UTM Association – UAS Traffic Management Architecture.

[6] DREAMS, Web survey results about drone operations, 2018. Deliverable ID: TN3.1, Edition 2, Topic: RPAS-02: Drone information management.

[7] DREAMS, Scenarios identification and requirement analysis. Deliverable ID: D3.1, Edition 1, Topic: RPAS-02: Drone information management.

[8] DREAMS, Preliminary safety assessment and regulatory compliance report. Deliverable ID: D3.2, Edition 1, Topic: RPAS-02: Drone information management.

[9] DREAMS, Gap Analysis Report. Deliverable ID: D4.2, Edition 1, Topic: RPAS-02: Drone information management.

[10] DREAMS, Data and Service catalogue. Deliverable ID: D4.1, Edition 1, Topic: RPAS-02: Drone information management.

[11] The Transition from AIS to AIM, CANSO 2013 [12] Metts C, Bowman M, Lineberger R.S, and Hussain A. “Managing the evolving skies: Unmanned

aircraft system traffic management (UTM), the key enabler”. Deloitte. July 2018. [13] EUROCONTROL, SWIM, 2018. System Wide Information Management (SWIM).

http://www.eurocontrol.int/swim (02 August 2018) [14] EUROCONTROL, AIM, 2018. Aeronautical Information Management.

http://www.eurocontrol.int/aim (04 August 2018) [15] EUROCONTROL, D-NOTAM, 2018. Digital NOTAM.

http://www.eurocontrol.int/articles/digital-notam-phase-3-p-21 (04 August 2018) [16] SESAR Joint Undertaking, MET Services, 2018. Delivering Tailored MET information with The

4DWXCUBE and MET-GATE. https://www.sesarju.eu/highlights/Delivering%20tailored%20MET%20information%20with%20the%204DWxCube%20and%20MET-Gate (10 August 2018)

[17] SESAR, 4DWeatherCube and MET-GATE, Fact Sheet. https://www.sesarju.eu/sites/default/files/documents/concepts/Fact_sheet_on_METGATE.pdf (10 August 2018)

[18] SESAR, Meteorological Information. https://www.sesarju.eu/sites/default/files/documents/concepts/leaflet_on_TOPLINK_MET_services.pdf (10 August 2018)

http://www.sesarju.eu/sites/default/files/documents/reports/U-space%20Blueprint.pdf


https://www.sesarju.eu/sites/default/files/documents/reports/European%20ATM%20Master%20Plan%20Drone%20roadmap.pdf

https://www.sesarju.eu/sites/default/files/documents/reports/European%20ATM%20Master%20Plan%20Drone%20roadmap.pdf

https://www.mckinsey.com/industries/capital-projects-and-infrastructure/our-insights/commercial-drones-are-here-the-future-of-unmanned-aerial-systems%20(16

https://www.mckinsey.com/industries/capital-projects-and-infrastructure/our-insights/commercial-drones-are-here-the-future-of-unmanned-aerial-systems%20(16

https://www.sesarju.eu/sites/default/files/documents/reports/European_Drones_Outlook_Study_2016.pdf

https://www.sesarju.eu/sites/default/files/documents/reports/European_Drones_Outlook_Study_2016.pdf

http://www.eurocontrol.int/swim%20(02

http://www.eurocontrol.int/aim%20(04

http://www.eurocontrol.int/articles/digital-notam-phase-3-p-21%20(04

https://www.sesarju.eu/highlights/Delivering%20tailored%20MET%20information%20with%20the%204DWxCube%20and%20MET-Gate

https://www.sesarju.eu/highlights/Delivering%20tailored%20MET%20information%20with%20the%204DWxCube%20and%20MET-Gate

https://www.sesarju.eu/sites/default/files/documents/concepts/Fact_sheet_on_METGATE.pdf%20(10

https://www.sesarju.eu/sites/default/files/documents/concepts/Fact_sheet_on_METGATE.pdf%20(10

https://www.sesarju.eu/sites/default/files/documents/concepts/leaflet_on_TOPLINK_MET_services.pdf%20(10

https://www.sesarju.eu/sites/default/files/documents/concepts/leaflet_on_TOPLINK_MET_services.pdf%20(10

EDITION 00.01.01

68


[19] Petrovsky A, Doole M, Ellerbroek J, Hoekstra J.M., and Tomasello F. “Challenges with Obstacle Data for Manned and Unmanned Aviation”, The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol. XLII -4/W10, 2018, 13th 3D GeoInfo Conference, Delft, The Netherlands.

[20] CORUS, Concept of Operations (ConOps) for U-Space, SESAR, D6.1, June 2018. [21] Stevens N M and Atkins M E. “Geofencing in Immediate Reaches Airspace for Unmanned

Aircraft System Traffic Management”. AIAA SciTech Forum, 2018, Kissimmee Florida, USA [22] Doole M, Ellerbroek J and Hoekstra J. “Drone delivery: Urban airspace traffic density

estimation”. 8th SESAR Innovation Conference, 2018, Salzburg, Austria [To be submitted]. [23] Stolaroff J, Samaras C, O’Neill E, R, Lubers A, Mitchell A, S, and Ceperley D. “Energy use and

life cycle greenhouse gas emissions of drones for commercial package delivery”, Nature communications, Nature, 2018.

[24] Sunil E, Ellerbroek J, and Hoekstra J.M. 2014. “Metropolis- Urban airspace design”, Scenario definition report.

[25] Schneider O. 2014. “Metropolis – Urban airspace design”, Concept design report. [26] Sunil E, Hoekstra J, Ellerbroek J, Bussink F, Nieuwenhuisen D, Vidosavljevic A and Kern S. 2015.

“Metropolis: Relating Airspace Structure and Capacity for Extreme Traffic Densities”, Eleventh USA/Europe Air Traffic Management Research and Development Seminar.

[27] Doole M. “PhD Research 6th Month Progress Report”. 2018. Faculty of Aerospace Engineering, Section Control and Simulation, Delft University of Technology, Delft, The Netherlands.

[28] Krishnakumar et al., 2017. “Safe Autonomous Flight Environment (SAFE50) for the Notional Last “50ft” of Operation of “55 lb” Class of UAS”, AIAA SciTech Forum, Grapevine, Texas, USA.

[29] Hoekstra J.M, Ellerbroek J, Sunil E and Maas J. 2018. “Geovectoring: Reducing Traffic Complexity to Increase Capacity of UAV airspace”, ICRAT, Barcelona, Spain.

[30] GUTMA UTM https://www.gutma.org/docs/Global_UTM_Architecture_V1.pdf [31] SESAR U-Space Workshop 20 April, 2017 The Hague:

https://www.sesarju.eu/sites/default/files/documents/events/SESAR%20U-Space%20Workshop.pdf

[32] SESAR U-space Blueprint http://www.sesarju.eu/sites/default/files/documents/reports/U-space%20Blueprint.pdf

[33] Drone rules: https://ec.europa.eu/easme/en/news/drone-rules-all-one-place [34] TOPIC RPAS-01 (CORUS) http://cordis.europa.eu/project/rcn/211096_en.html [35] TOPIC RPAS-04 (CLASS) http://cordis.europa.eu/project/rcn/210633_en.html [36] SESAR at World ATM Congress 2016 - Spectrum workshop

https://www.slideshare.net/SESAREuropeanUnion/sesar-at-world-atm-congress-2016-spectrum-workshop

[37] EASA Regulatory framework for the operation of drones https://www.easa.europa.eu/document-library/notices-of-proposed-amendment/npa-2015-10

[38] EASA Opinion 01/2018 on UAS operations in the ‘open’ and ‘specific’ categories https://www.easa.europa.eu/document-library/opinions/opinion-012018#group-easa-downloads

[39] Eurocontrol European AIS: http://www.eurocontrol.int/articles/ais-online [40] Aerion ADS-B satellite based surveillance system

https://www.enav.it/sites/public/en/Servizi/AIREON.html [41] DJI AEROSCOPE:

https://www.dji.com/newsroom/news/dji-unveils-technology-to-identify-and-track-airborne-drones https://www.theregister.co.uk/2017/10/27/dji_aeroscope_short_range

https://www.gutma.org/docs/Global_UTM_Architecture_V1.pdf




https://ec.europa.eu/easme/en/news/drone-rules-all-one-place

http://cordis.europa.eu/project/rcn/211096_en.html

http://cordis.europa.eu/project/rcn/210633_en.html



https://www.easa.europa.eu/document-library/notices-of-proposed-amendment/npa-2015-10

https://www.easa.europa.eu/document-library/notices-of-proposed-amendment/npa-2015-10

https://www.easa.europa.eu/document-library/opinions/opinion-012018#group-easa-downloads

https://www.easa.europa.eu/document-library/opinions/opinion-012018#group-easa-downloads

http://www.eurocontrol.int/articles/ais-online

https://www.enav.it/sites/public/en/Servizi/AIREON.html

https://www.dji.com/newsroom/news/dji-unveils-technology-to-identify-and-track-airborne-drones

https://www.dji.com/newsroom/news/dji-unveils-technology-to-identify-and-track-airborne-drones

https://www.theregister.co.uk/2017/10/27/dji_aeroscope_short_range



69

[42] LAANC: https://www.faa.gov/uas/programs_partnerships/uas_data_exchange/; http://www.airtrafficmanagement.net/2017/03/faa-outlines-laanc-automated-drone-ops/; https://skyward.io/answers-to-your-questions-about-laanc-skyward/; https://www.airmap.com/airmap-unmanned-traffic-management-utm-matt-koskela-product/; https://www.airmap.com/airspace-authorization/;

[43] ICAO UTM, INTERNATIONAL REGISTRY: https://www.icao.int/Meetings/UAS2017/Documents/UAS2017_RFI.pdf; http://www.unmannedairspace.info/utm-industry-leader-interview/suddenly-local-police-politicians-cheering-utm-benoit-curdy-global-utm-association/

[44] NTU and CAAS UTM program https://i-hls.com/archives/73933; http://media.ntu.edu.sg/NewsReleases/Pages/newsdetail.aspx?news=20327ba4-b019-4a38-a86f-47e64d89ba0d.

[45] NTU uses 4.5G network for UTM https://www.uasvision.com/2017/12/11/ntu-singapore-uses-4-5g-network-for-drone-traffic-management/

[46] Nokia smart city test at Twente airport https://mobileeurope.co.uk/press-wire/nokia-s-drones-take-off-at-twente-airport-in-traffic-management-test; https://www.nokia.com/en_int/news/releases/2016/09/26/nokia-and-europes-first-drone-based-smart-city-traffic-management-test-facility-collaborate-to-ensure-safe-global-aerial-operations

[47] Deutsche Telekom air traffic control project https://www.telekom.com/en/media/media-information/archive/high-level-cooperation-443952; https://mobileeurope.co.uk/press-wire/deutsche-telekom-to-test-connected-drones-in-air-traffic-control-project; https://www.microdrones.com/en/content/deutsche-flugsicherung-deutsche-telekom-and-dlrg-choose-microdronesr-to-jointly-test-the-remote-con/

[48] NTU and CAAS UTM scenario https://i-hls.com/archives/73933; http://media.ntu.edu.sg/NewsReleases/Pages/newsdetail.aspx?news=20327ba4-b019-4a38-a86f-47e64d89ba0d

[49] AirMap and Rakuten Japan UTM joint project https://global.rakuten.com/corp/news/press/2017/0315_01.html; https://www.rakuten-airmap.co.jp/english-information/

[50] U-space U1 and U2 capabilities demonstrations https://www.airmap.com/switzerland-u-space-skyguide-demo/; https://www.suasnews.com/2017/09/skyguide-and-its-project-partners-announce-first-live-demonstration-in-europe-of-u-space-capabilities/

[51] Blockchain capability https://www.coindesk.com/press-releases/3-problems-blockchain-solves-commercial-drone-market/; http://www.distributedsky.com/; https://docs.google.com/document/d/1yWD74LIEOqEDJ7_16rELTSFjkFE-ZDjKQwtpGF0Bwp8/edit.

[52] Unmanned Aircraft Cloud Services https://droneregulations.info/China/CN.html?altLang=default#country-search; http://true.kaist.ac.kr/research-blog-traffic-management--control/unmanned-aircraft-system-traffic-management-utm-in-china

[53] Commercial UAV market analysis

https://www.faa.gov/uas/programs_partnerships/uas_data_exchange/

https://skyward.io/answers-to-your-questions-about-laanc-skyward/

https://www.airmap.com/airmap-unmanned-traffic-management-utm-matt-koskela-product/

https://www.airmap.com/airmap-unmanned-traffic-management-utm-matt-koskela-product/

https://www.airmap.com/airspace-authorization/

https://www.icao.int/Meetings/UAS2017/Documents/UAS2017_RFI.pdf

http://www.unmannedairspace.info/utm-industry-leader-interview/suddenly-local-police-politicians-cheering-utm-benoit-curdy-global-utm-association/

http://www.unmannedairspace.info/utm-industry-leader-interview/suddenly-local-police-politicians-cheering-utm-benoit-curdy-global-utm-association/

https://i-hls.com/archives/73933

http://media.ntu.edu.sg/NewsReleases/Pages/newsdetail.aspx?news=20327ba4-b019-4a38-a86f-47e64d89ba0d


https://www.uasvision.com/2017/12/11/ntu-singapore-uses-4-5g-network-for-drone-traffic-management/

https://www.uasvision.com/2017/12/11/ntu-singapore-uses-4-5g-network-for-drone-traffic-management/

https://mobileeurope.co.uk/press-wire/nokia-s-drones-take-off-at-twente-airport-in-traffic-management-test

https://mobileeurope.co.uk/press-wire/nokia-s-drones-take-off-at-twente-airport-in-traffic-management-test

https://www.nokia.com/en_int/news/releases/2016/09/26/nokia-and-europes-first-drone-based-smart-city-traffic-management-test-facility-collaborate-to-ensure-safe-global-aerial-operations



https://www.telekom.com/en/media/media-information/archive/high-level-cooperation-443952

https://www.telekom.com/en/media/media-information/archive/high-level-cooperation-443952

https://mobileeurope.co.uk/press-wire/deutsche-telekom-to-test-connected-drones-in-air-traffic-control-project

https://mobileeurope.co.uk/press-wire/deutsche-telekom-to-test-connected-drones-in-air-traffic-control-project

https://www.microdrones.com/en/content/deutsche-flugsicherung-deutsche-telekom-and-dlrg-choose-microdronesr-to-jointly-test-the-remote-con/



https://i-hls.com/archives/73933



https://global.rakuten.com/corp/news/press/2017/0315_01.html

https://www.rakuten-airmap.co.jp/english-information/


https://www.airmap.com/switzerland-u-space-skyguide-demo/

https://www.suasnews.com/2017/09/skyguide-and-its-project-partners-announce-first-live-demonstration-in-europe-of-u-space-capabilities/

https://www.suasnews.com/2017/09/skyguide-and-its-project-partners-announce-first-live-demonstration-in-europe-of-u-space-capabilities/

https://www.coindesk.com/press-releases/3-problems-blockchain-solves-commercial-drone-market/

https://www.coindesk.com/press-releases/3-problems-blockchain-solves-commercial-drone-market/

http://www.distributedsky.com/

https://docs.google.com/document/d/1yWD74LIEOqEDJ7_16rELTSFjkFE-ZDjKQwtpGF0Bwp8/edit

https://docs.google.com/document/d/1yWD74LIEOqEDJ7_16rELTSFjkFE-ZDjKQwtpGF0Bwp8/edit

https://droneregulations.info/China/CN.html?altLang=default#country-search

http://true.kaist.ac.kr/research-blog-traffic-management--control/unmanned-aircraft-system-traffic-management-utm-in-china

http://true.kaist.ac.kr/research-blog-traffic-management--control/unmanned-aircraft-system-traffic-management-utm-in-china

EDITION 00.01.01

70


http://www.businessinsider.com/commercial-uav-market-analysis-2017-8?IR=T; BVLOS Capability https://www.enac.gov.it/Home/Strillo_Primopiano/info-292671043.html; http://www.unmannedsystemstechnology.com/2017/03/airobotics-granted-approval-fly-fully-automated-commercial-drones/; http://www.unmannedsystemstechnology.com/2017/12/american-robotics-announces-new-autonomous-drone-based-precision-agriculture-solution/; http://www.unmannedsystemstechnology.com/2017/06/commercial-drone-completes-30-mile-bvlos-flight-via-3g/; http://www.bmvi.de/SharedDocs/EN/Articles/LR/clear-rules-for-the-operation-of-rules.html; http://www.quadricottero.com/2017/02/sensefly-con-il-drone-ebee-autorizzato.html

[54] DREAMS D2.1 Project Master Plan 01.00.00 [55] UML 2.0 http://www.uml.org/what-is-uml.htm [56] Integrated UTM/ATM solutions for UK - Tablet application: https://www.altitudeangel.com/ [57] DJI Drone manufacturer https://www.dji.com/ [58] ETH PX4 project: https://www.dronecode.org/ http://px4.io/ http://ardupilot.org/ [59] MAVLINK protocol http://qgroundcontrol.org/mavlink/start [60] IRIDIUM NEXT Low Earth Orbit SATCOM constellation

https://www.iridium.com/network/iridium-next/ [61] Annex I -Technical Specifications CEF-SESAR-2018-1-Final [62] RAKUTEN-AIRMAP DASHBOARD

https://www.airmap.com/rakuten-airmap-launches-utm-platform-for-japan/ [63] E. Sunil, J.M. Hoesktra, J. Ellerbroek, F. Bussink, D. Nieuwenhuisen, A. Vidosavljevic, and S.

Kern, Metropolis: Relating Airspace Structure and Capacity for Extreme Traffic Densities, ATM seminar 2015, 11th USA/EUROPE Air Traffic Management R&D Seminar (2015)

[64] Y.I. Jenie, E. van Kampen, C.C. de Visser, J. Ellerbroek, and J.M. Hoekstra, Selective Velocity Obstacle Method for Deconflicting Maneuver Applied to Unmanned Aerial Vehicles, AIAA Journal of Guidance, Control, and Dynamic, Vol.38, No 6, pp 1140-1146 (2015)

[65] G. Mercado Velasco, C. Borst, J. Ellerbroek, M. van Paassen, and M.Mulder, The Use of Intent Information in Conflict Detection and Resolution Models Based on Dynamic Velocity Obstacles, Intelligent Transport Systems, IEEE Transactions on 16, 2297 (2015)

[66] NASA UTM documents https://utm.arc.nasa.gov/documents.shtml

[67] RAKUTEN-AIRMAP Joint Venture: https://www.rakuten-airmap.co.jp/english-information/

[68] Verdantix Drone Market Size and Forecasts http://research.verdantix.com/index.cfm/papers/Products.Details/product_id/1066/drones-market-size-and-forecast-2017-2037-europe-/-

[69] Gartner https://www.gartner.com/newsroom/id/3602317 [70] Economist, Technology Quarterly

http://www.economist.com/technology-quarterly/2017-06-08/civilian-drones [71] Assure Suas Airborne Collision Report

http://www.assureuas.org/projects/deliverables/sUASAirborneCollisionReport.php?CFA=1; [72] GoldmanSachs Technology Driving Innovation. Drones, Reporting for Work

http://www.goldmansachs.com/our-thinking/technology-driving-innovation/drones/ [73] Pwc Drones as a Data Service

http://usblogs.pwc.com/emerging-technology/a-look-at-drones-as-a-data-service-infographic/

http://www.businessinsider.com/commercial-uav-market-analysis-2017-8?IR=T

https://www.enac.gov.it/Home/Strillo_Primopiano/info-292671043.html

http://www.unmannedsystemstechnology.com/2017/03/airobotics-granted-approval-fly-fully-automated-commercial-drones/

http://www.unmannedsystemstechnology.com/2017/03/airobotics-granted-approval-fly-fully-automated-commercial-drones/

http://www.unmannedsystemstechnology.com/2017/12/american-robotics-announces-new-autonomous-drone-based-precision-agriculture-solution/

http://www.unmannedsystemstechnology.com/2017/12/american-robotics-announces-new-autonomous-drone-based-precision-agriculture-solution/

http://www.unmannedsystemstechnology.com/2017/06/commercial-drone-completes-30-mile-bvlos-flight-via-3g/

http://www.unmannedsystemstechnology.com/2017/06/commercial-drone-completes-30-mile-bvlos-flight-via-3g/

http://www.bmvi.de/SharedDocs/EN/Articles/LR/clear-rules-for-the-operation-of-rules.html

http://www.quadricottero.com/2017/02/sensefly-con-il-drone-ebee-autorizzato.html

http://www.uml.org/what-is-uml.htm

https://www.altitudeangel.com/

https://www.dji.com/

https://www.dronecode.org/

http://px4.io/

http://ardupilot.org/

http://qgroundcontrol.org/mavlink/start

https://www.iridium.com/network/iridium-next/

https://utm.arc.nasa.gov/documents.shtml


http://research.verdantix.com/index.cfm/papers/Products.Details/product_id/1066/drones-market-size-and-forecast-2017-2037-europe-/-

http://research.verdantix.com/index.cfm/papers/Products.Details/product_id/1066/drones-market-size-and-forecast-2017-2037-europe-/-

https://www.gartner.com/newsroom/id/3602317

http://www.economist.com/technology-quarterly/2017-06-08/civilian-drones

http://www.assureuas.org/projects/deliverables/sUASAirborneCollisionReport.php?CFA=1

http://www.goldmansachs.com/our-thinking/technology-driving-innovation/drones/





71

[74] CORUS, Concept of Operations (ConOps) for U-Space, SESAR, Intermediate ConOps D6.2, Edition date: 1 Mar 2019, Edition: 00.02.RC1

EDITION 00.01.01

72


D4.3 -Preliminary U AIM CONOPS · STELLAR SESAR Tool Enabling coLLaborative ATM Research SWIM...

Documents

Transcript of D4.3 -Preliminary U AIM CONOPS · STELLAR SESAR Tool Enabling coLLaborative ATM Research SWIM...