Ref. Ares(2020)2817484 - 31/05/2020
Project number: 723509
Project duration: June 2017 – May 2020
Project Coordinator: Technische Universität Braunschweig
Deliverable ID:
D3.7
Cooperative Surveillance of low flying drones
Horizon 2020: Mobility
for Growth
SyGMA-ID
Preparation date:
26.05.2020
Title:
Validation Report
Breakthrough innovation
Abstract:
This report contains the final description of the validation exercises and the achieved results based on
earlier criteria given by the other project partners.
Organizing and planning validation
Dissemination level
PU
CO
CI
X
Public, fully open, e.g. web
Confidential, restricted under conditions set out in Grant Agreement
Classified, information as referred to in Commission Decision 2001/844/EC
Deliverable type
R
DEM
DEC
OTHER
Document, report (excluding the periodic and final reports)
X
Demonstrator, pilot, prototype, plan designs
Websites, patents filing, press & media actions, videos etc.
Software, technical diagram, etc.
Authorship and Approval Information
Prepared by
Role
Name and organisation
Date
Editor
Matthijs Nederveen, UAV International B.V. (UNL)
22.05.2020
Role
Name and organisation
Date
Reviewers
Silvio Semanjski, RMA
30.05.2020
Reviewers
Roger Borre, ROB
30.05.2020
Reviewers
Jiri Karpeta, RDE
30.05.2020
Reviewers
Björn Blom, TUBS
30.05.2020
Reviewers
Lubos Korenciak, HRO
30.05.2020
Role
Name and organisation
Date
Coordinator
Björn Blom
Blom, TUBS
30.05.2020
Contributors
Contributors
Reviewed by
Approved by
2
Organizing and planning validation
Release
Date
number
issued
1.0
26.05.2020
Initial Release version
1.1
29.05.2020
Scenario descriptions added
Milestone
Doc.
Release description /changes made
version
3
Organizing and planning validation
Table of contents
References ................................
................................................................................................
.............................................. 5
1
2
2.
Introduction ................................
................................................................................................
...................................... 6
1.1
Purpose ................................
................................................................................................
............................................................ 6
1.2
Scope ................................
................................................................................................................................
................................ 6
1.3
Definitions & Acronyms ................................................................................................
................................. 7
1.3.1
Definitions ................................
................................................................................................
................................................ 7
1.3.2
Acronyms ................................
................................................................................................
................................................. 8
Validation ................................
................................................................................................
......................................... 9
1.1.
Validation 1 ................................
................................................................................................
...................................................... 9
1.2.
Validation 2 ................................
................................................................................................
...................................................... 9
2.1.1
Scenario 1 (Stationary Drone) ................................................................
............................................... 9
2.1.2
Scenario 2 (Crossing Drone) ................................................................
................................................ 11
2.1.3
Scenario 3 (Head
(Head-on) ............................................................................................
............................ 12
2.1.4
Scenario 4 (Multiple Drones) ................................................................
............................................... 13
2.1.5
Scenario 5 (Geofence) ................................................................
.......................................................... 14
2.1.6
Scenario 6 (Deviating Drone) ................................................................
.............................................. 15
Validation ................................
................................................................................................
....................................... 16
2.1.
3.
Substitute activities and tests for validation 2 .........................................................
................................
16
Conclusion ................................
................................................................................................
...................................... 22
4
Organizing and planning validation
References
[RD1]
CORUS ‘Concept of Operations for U
U-space’
[RD2]
JARUS 'RPAS
RPAS Required C2 Performance (RLP) Concept
Concept'
[RD3]
SESAR JOINT UNDERTAKING 'U-space Blueprint'
5
Organizing and planning validation
1 Introduction
The number of drones or equivalently Unmanned Aerial Vehicles (UAV) is expected
to rise dramatically over upcoming years, what is driven by high economic
opportunities represented by their potential commercial use. However, the rising
number of drones posess risks to existing aerospace users and objects on the
ground as a crash with a drone can cause severe damage or even death. Hence,
there is a need to develop services and specific procedures designed to support
safe, efficient, and secure access to airspa
airspace
ce for large numbers of drones [RD3]
similar to Air Traffic Management (ATM) for manned aircraft. These services and
procedures are referred to as U
U-space
space or Unmanned Traffic Management (UTM). For
more information please refer to [RD3].
1.1 Purpose
One of the targets of the MObile
MObile-Nework
Nework Infrastructure for cooperative surveillance
of low FLYing drones (MoNIfly) project is to validate such infrastructure within a
concept for unmanned traffic management (UTM) system, i.e., low
low-level air-traffic
management
ent system for drones.
The purpose of this document is to report on the validation exercises and the
achieved results.
1.2 Scope
This document presents the performed validation activities and includes the
conclusion for the MoNIfly concept based on validation
validations.
6
Organizing and planning validation
1.3 Definitions & Acronyms
1.3.1 Definitions
Term
Definition
ADS-B
is a surveillance technology based on periodic broadcast of the
In/Out
own positional information (obtained mainly from GNSS and
barometer)) to surrounding traffic. There are two main pieces of
equipment associated with ADS
ADS-B: ADS-B
B Out transmitter is a
device that broadcasts the ADS
ADS-B
B messages from a vehicle to be
visible for other traffic, and ADS
ADS-B In receiver is a device to receive
ADS-B messages from surrounding vehicles equipped by ADS
ADS-B
Out to locate them.
C2 link
is the datalink used for the purpose of command and control
Hovering
is a stationary flight.
Loitering
is flying for a certain amount of time over a small region.
LTE
is telecommunication standard for high-
functions in unmanned aircraft systems. [[RD2]
speed wireless communication almost matching requirements of
4G standard.
U-space/
UTM
5G
is a set of new services and specific procedures designed to
support safe, effic
efficient
ient and secure access to airspace for large
numbers of drones. [[RD3]
is proposed next
next-generation
generation telecommunication standard
succeeding 4G standard.
7
Organizing and planning validation
1.3.2 Acronyms
Term
Explanation
ATC
Air Traffic Control
ATM
Air Traffic Management
ADS-B
Automatic Dependent Surveillance – Broadcast
C2
Command-Control
CORUS
Concept of Operation for EuRopean UTM Systems
DL
Data Link
FCC
Flight-control
control Computer
5G
Fifth Generation of cellular mobile communications
GNSS
Global Navigation Satellite System
GCS
Ground Control Station
LTE
Long-Term
Term Evolution
LoS
Loss of Separation
MA
Manned Aircraft
MP
Mission Plan
MoNIfly
MObile-Nework
Nework Infrastructure for cooperative surveillance of low
FLYing drones
NB
Notebook
NOTAM
NOTice to Airmen
PPR
Prior Permission Request
PVT
Position Velocity Time
SM
Separation Management
UAV
Unmanned Aerial Vehicle
UTM
Unmanned Traffic Management
8
Organizing and planning validation
2 Validation
1.1. Validation 1
The first validation activity of MoNIfly in Twente, the Netherlands, was held between
the 11th of November and 22nd of November, 2019 (and near Prague on 18th of
December 2019).. During the validation activity, the milestone 7 of MoNIfly, the
demonstration of the conflict detection with geofences (and other aircraft) was
successfully completed. Results for validation 1 are described in D3.4 Evaluation of
test [D25].
1.2. Validation 2
Validation 2 was planned to take place at Twente airport during week 14 and 15 of
2020.
Scenarios planned for validation 2:
2.1.1 Scenario 1 (Stationary Drone)
Drone is stationary at the Intersection between the runway and the taxiway. The
Cessna is approaching from the northwest, making the drone evade to either
northeast or southwest. Drone should travel ~700m to avoid.
Proposed safety radii & altitudes:
Cessna: 500m, Drone 200m
Proposed altitudes:
Cessna 2000' MSL (~1500' AGL, ~500m)
Drone: 250' AGL (~80m)
Cessna Waypoints:
10 Minutes @100kts GS:
52°33'38.6" N 6°35'13.5" E
52.560709°, 6.587083°
5 Minutes 100kts GS:
52°25'07.9" N 6°44'24.7" E
9
Organizing and planning validation
52.418873°, 6.740186°
Target Point:
52°16'11.2" N 6°53'27.8" E
52.269773°, 6.891053°
Drone Waypoints
52°16'28.3" N 6°53'09.5" E
52.274523, 6.885957
10
Organizing and planning validation
2.1.2 Scenario 2 (Crossing Drone)
Drone
e is flying along the runway (Heading Southwest), with a medium speed. Cessna
is approaching from the northwest, flying perpendicular to the runway.
Proposed safety radii:
Cessna: 500m, Drone: 200m
Proposed altitudes:
Cessna: 2000' MSL (~1500' AGL, ~500m)
Drone: 250' AGL (~80m)
Cessna Waypoints:
10 Minutes @100kts GS:
52°33'38.6" N 6°35'13.5" E
52.560709, 6.587083
5 Minutes @100kts GS:
52°25'07.9" N 6°44'24.7" E
52.418873, 6.740186
Target Point:
52°16'11.2" N 6°53'27.8" E
52.269773, 6.891053
Drone Waypoints
Drone Speeds
Starting Point:
Drone Speed for 10 Minute approach:
52°16'47.4"N 6°53'54.0"E
1,5m/s (11min to intersection)
52.279837, 6.898338
Drone Speed for 5 Minute approach:
3m/s (~5,5 min to Intersection)
Target Point:
52°16'09.7"N 6°52'26.2"E
52.269346, 6.873930
11
Organizing and planning validation
2.1.3 Scenario 3 (Head-on)
on)
Drone is flying along the runway (Heading Southwest), with a medium speed. Cessna
is approaching from the southwest, flying along the runway.
Proposed safety radii:
Cessna: 500m, Drone: 200m
Proposed altitudes:
Cessna: 2000' MSL (~1500' AGL, ~500m)
Drone: 250' AGL (~80m)
Cessna Waypoints:
10 Minutes @100kts GS:
2°04'48.8"N 6°26'28.1"E
52.080225, 6.441129
5 Minutes @100kts GS:
52°10'40.0"N 6°39'58.5"E
52.177781, 6.666262
Target Point:
52°16'47.4"N 6°53'54.0"E
52.279837, 6.898338
Drone Waypoints:
Drone Speeds
Starting Point:
Drone Speed for 10 Minute approach:
52°16'47.4"N 6°53'54.0"E
1,5m/s (11min to intersection)
52.279837, 6.898338
Drone speed for 5 minute approach:
3m/s (~5,5 min to Intersection
Target Point:
52°16'09.7"N 6°52'26.2"E
52.269346, 6.873930
12
Organizing and planning validation
2.1.4 Scenario 4 (Multiple Drones)
Parallel flying drones, followed by faster aircraft, which is slightly offset.
Proposed safety radii:
Cessna: 500m, Drone: 200m
Proposed altitudes:
Cessna: 2000' MSL (~1500' AGL, ~500m)
Drone: 250' AGL (~80m)
Cessna Waypoints:
10 Minutes @100kts GS:
5 Minutes @100kts GS:
52°04'48.8"N 6°26'28.1"E
52°10'40.0"N 6°39'58.5"E
52.080225, 6.441129°
52.177781, 6.666262°
2°
Target Point:
52°16'47.4"N 6°53'54.0"E
52.279837, 6.898338
Drone Waypoints:
Drone Speeds
Drone 1
Starting Point:
Drone Speed for 10 Minute approach:
52°16'09.1"N 6°52'32.2"E
1,5m/s
52.269202, 6.875605
Drone speed for 5 minute approach:
3m/s
Target Point:
52°16'45.4"N 6°53'56.6"E
52.279266, 6.899044
Drone 2 (2 or 1 minute(s) later, depending on approach length)
Starting Point:
Drone Speed for 10 Minute approach:
52°15'56.6"N 6°52'44.4"E
1,5m/s
52.265728, 6.878994
Drone speed for 5 minute approach:
3m/s
Target Point:
52°16'33.4"N 6°54'09.9"E
52.275943, 6.902757
13
Organizing and planning validation
2.1.5 Scenario 5 (Geofence)
Proposed safety radii & altitudes:
Geofence: 500m, Drone: 200m
Proposed altitudes:
Drone: 250' AGL (~80m)
Geofence
Center:
52°16'27.4"N 6°53'44.6"E
52.274279, 6.895719
14
Organizing and planning validation
2.1.6 Scenario 6 (Deviating Drone)
Drone 1 will deviate manually from its mission plan. Drone 2 should evade.
Proposed safety radii:
Drones: 200m
Proposed altitudes:
Drone: 250' AGL (~80m)
Drone Waypoints:
Drone Speeds
Drone 1
Starting Point:
Drone Speed: 5m/s
52°16'05.8"N 6°52'17.4"E
Deviation at:
52.268277, 6.871509
52°16'11.5"N 6°52'30.7"E
52.269854, 6.875199
Target for Deviation:
52°16'24.8"N 6°53'56.7"E
52.273567, 6.899085
Target Point:
52°16'55.3"N 6°54'12.3"E
52.282028, 6.903411
Drone 2
Starting Point:
Drone Speed: 3 m/s
52°15'56.6"N 6°53'42.0"E
52.265729, 6.895002
Target Point:
52°16'46.8"N 6°53'41.5"E
52.279674, 6.894871
15
Organizing and planning validation
2. Validation
As a result of the coronavirus outbreak precautionary measures have been put in
place to prevent the spread of the virus in Europe. In the Netherlands an intelligent
lockdown has been implemented with several restrictions which included no
traveling abroad,, keeping a safe distance from others and gatherings with a
maximum of three (3) persons.
All activities in preparation to validation 2 (approvals for test flights, communication
procedures, authority approvals and safety and security measures) took place before
the implementation of the coronavirus outbreak precautionary measures.
Because there were some UTM components worth testing (e.g., newly implemented
or changed based on the outcomes of validation 1) the MoNIfly consortium decided
to organize a local flight-test
test with drones in Czech Republic (where Honeywell and
Robodrone are located) despite challenging situation with COVID
COVID-19.
19.
2.1. Substitute activities and test
tests for validation 2
The objectives for MoNIfly consortium were to test the fixes of issues identified in
the first validations. This was partially successful. To
o the best of our knowledge the
causes of the issues were correctly identified and the implemented fixes were
successful in mitigating the issues described in deliverable D3.4. However, there
were just a few flights performed so we cannot tell for sure that the fixes were
successful.
Moreover, the consortium wanted to gather some more data for analysis of SM and
mobile network interface of the MoNIfly UTM concept (MUTM). The results of these
activities are elaborated below.
Separation Management Testing
Unfortunately for the separation management (SM) part of the project, there was a
problem unidentified in the tests before. Different to the flight trials in Twente, this
time the separation
ion management application was running on the UTM server (not on
a remote computer), with the major difference to Twente that the application was
running continuously. It was not programmed that the software representations of
the vehicles were to be delet
deleted
ed after a specific time without updates or any other
condition. Therefore, the older flights were considered to be flying forever by the
software (they were just frozen in their last position).
16
Organizing and planning validation
There was one scenario for testing SM prepared for the flight
flight-tests:
tests: it was intended
to have one drone being stationary and the second one approaching. We performed
one flight, but there were several tries to perform the planned scenario. The
separation management was issuing separation commands too early. In discus
discussions
with the involved persons and thanks to extensive simulator trials from Honeywell,
the cause could be isolated to the data artifacts that remained in the separation
management software.
Unfortunately, the increasing wind intensity ruled out additiona
additionall flights and no more
flight data for validation of SM could be collected (even though there was a correct
suspicion and the SM was restarted at the test site, what would solve the problem in
new flights).
). More useful flight validation data were obtained ffrom the first
validation and are discussed in the respective document. The flight
flight-tests in
Olomouc were helpful to reveal previously undiscovered bug and to improve quality
of the SM.
Latency of Mobile-Network
etwork Downlink (MUTM)
During the first validations, the SM was always executed on a computer rather than
on the UTM server (see Fehler! Verweisquelle konnte nicht gefunden werden.
werden.),
because the drone operator interface was not fully implemented at that time.
Running the SM in a notebook (NB) on the testing site was helpful, becau
because the
graphical user interface of the SM could be used to track the behavior of the SM.
However, that architecture had also disadvantages:

There was larger communication delay between UTM modems and SM,
because we had to use LTE network two times – for communication
ommunication between
UTM modem and UTM server; and between UTM server and the NB on testing
site.

Moreover, we could not estimate the mobile-network-downlink
downlink latencies
(from the UTM server to UTM modem), because the logging counted on SM to
be on the UTM server.
17
Organizing and planning validation
Figure 1: MoNIfly UTM architecture used in the first validations
For the flight-test
test in Olomouc, the MoNIfly consortium wanted to test the SM
running on the UTM server and measure the MUTM downlink. Due to strong wind, it
was possible to perform just one flight with the SM (MUTM downlink is used when
SM sends commands a drone). Unfortunately, there was an issue with one log file1
(otherwise the communication infrastructure was working correctly) on the UTM
modem that was receiving the SM c
commands.
ommands. Because of the missing log file,
file we
could not directly evaluate the MUTM downlink. This issue was identified right after
the flight, but the weather did not allow us to make another flight. However, we
were able to estimate the MUTM downlink using following ways:

We obtained logs from fflight-control
control computer (FCC) of respective drone and
computed latency between sending of SM command from the UTM server
until it was received on the FCC. This latency should be slightly larger than
MUTM latency only because we include also AUTM (interface between the FCC
1
This was occurrence of the same issue as in the first trial. The issue was connected to vibrations
of the SD cards in UTM modems. We mitigated the issue by gluing the SD card in advance to
eliminate the vibrations. Unfortunately one SD card needed to be ex
exchanged
changed at the test sit with
no glue available. This SD card had incomplete log, but the other SD card was OK. This supports
the suspition that problem is caused by vibrations and that one of the possible solutions is to
glue the SD card.
18
Organizing and planning validation
and UTM modem) downlink latency. However, there could be clock shifts
between UTM server and FCC thus all the latencies provided below are just
estimations of MUTM downlink latencies (the numbers can be larger or lower
than the real latencies).
es).
maximal latency
1480 ms
minimal latency
53 ms
mean latency
94.35 ms
latency jitter
43.78 ms
Figure 2: Timeline of sum of MUTM and AUTM downlink latencies [ms] in Olomouc flight

We performed a hardware in the loop simulations of the Olomouc flight
flight-test
scenario and recorded MUTM downlink times. The latencies should be lower
than latencies recorded in a flying drone because of poorer network
connection in higher altitudes. But again, the numbers provided below are
influenced by a clock shift between UTM modem and UTM server and may be
larger or smaller than real latencies.
maximal latency
3229 ms
minimal latency
103 ms
mean latency
184.14ms
latency jitter
121.03
19
Organizing and planning validation
Figure 3: Timeline of latencies [ms] of MUTM downlink in HIL simulation
20
Organizing and planning validation
We performed also analyses of MUTM uplink and updated the table of deliverable
D3.5.
metric
value
maximal (from all entries and flights) uplink latency
5.49 s
maximal (from all entries and flights) uplink throughput
0.35 Mbps
maximal (from all flights) mean uplink latency
0.58 s
minimal (from all flights) mean uplink latency
0.22 s
maximal (from all flights) uplink jitter
0.092 s
maximal (from all entries and flights) downlink latency
5.86 s
maximal
(from
all
entries
and
flights)
downlink 0.004 Mbps
throughput
maximal (from all flights) mean downlink latency
0.18 s
minimal (from all flights) mean downlink latency
0.03s
maximal (from all flights) downlink jitter
0.12 s
Table 1
21
Organizing and planning validation
3. Conclusion
As already discussed in D3.4, there were some software problems present during
the validation. It is therefore unfortunate, that the second validation activity had to
be cancelled due to the spread of Covid
Covid-19,
19, because the problems were positively
identified after the first validation and fixes for these problems were introduced
prior to the second validation, but their effects could not be tested appropriately.
The development of the MoNIfly concept and demonstrated tests and validation
proofed to serve as a system that allows safe and aviation
aviation-harmonized
harmonized drone
operations in low altitude airspace.
The validation activities in MoNIfly showed that the mobile network infrastructure
deployed in the field today can be used effectively for monitoring of low altitude
airspace and drone activities. Even separation management se
services could be
deployed with the present technology, only requiring minor changes to hard
hardware
and software of drones.. Of course, especially the switching of control of drones
between the operators and a separation management service needs more
investigation,
on, as navigating obstacles and power management are just two
challenging tasks that need to be dealt with. Due to the cancellation of the second
validation activity, not much data is available from the project compared to the
intended investigations, but the working cooperation between the different
components of the MoNIfly concept show that especially for higher traffic volumes
in low altitude airspace, automatic solutions are viable and can be developed.
The mobile network infrastructure used in MoNIfly delivered mostly reliable data
communication between the drones and the UTM server. The identified risks of
larger outages could be mitigated using various approaches described in deliverable
D3.5. It is expected that upcoming 5G networks could greatly mi
mitigate the risk of
network outages without any changes to their proposed design. There is potential
for future research in this area.
From the results of MoNIfly, it can be stated that the separation management
developed within the MoNIfly project reduces the risk of collisions of drones with
static obstacles as well as other airspace users and could form an essential part for
the implementation of U-Space
Space (U3 and U4).
22
Organizing and planning validation
This project has received funding from the European
Union´s
s Horizon 2020 research and innovation
programme under grant agreement No 723509.
23