Solving safety and security risks associated with drones; an IoT Solution Architecture

Solving safety and security risks associated with drones;

an IoT Solution Architecture

SUBMITTED IN PARTIAL FULLFILLMENT FOR THE DEGREE OF MASTER OF SCIENCE

MELISSA KOMEN

10411909

M

I

S

H

C

M

F

S

U

A

July 28, 2016

1st Supervisor 2nd Supervisor

Prof. dr. ing. Z.J.M.H. (Zeno) Geradts. prof. dr. Arnoud Visser

Solving safety and security risks associated with drones;

an IoT Solution Architecture

[Master thesis]

Melissa Komen

University of Amsterdam

Science Park 402, 1098 XH Amsterdam

melissa.komen@student.uva.nl ABSTRACT

In this paper a conceptual foundation is presented of an Internet of Things solution architecture that can be used to diminish some safety and security risks related to drones. Interviews were held with relevant stakeholders to gain insight in what the general functions should be. These were then encapsulated in four potential use cases, which are evaluated for feasibility. For this evaluation a trade-off is made between required technical adjustments, possible resistance from stakeholders and safety or security risks it solves. This research shows that in the described use cases, an IoT based architecture has the potential to solve some of these risks associated with drones. Further research is needed to see if the system is suitable for real world application and whether it would work in other use cases.

Categories and Subject Descriptors

C.0 [Computer Systems Organization]: General— System architectures; E.2 [Data]: Data Storage Representations

Keywords

Drones, system architecture, Internet of Things, Machine Learning, Microsoft technology, analytics

1. INTRODUCTION

In the beginning of 2016 the Dutch National Police and Guard From Above, a company specialized in training raptorial birds, joined forces to find a way to intercept hostile drones (Politie.nl, 2016). Their plan: train eagles to take down drones. A rigorous solution, but one clearly showing how desperate different parties are looking for a solution to gain control over drones and their movements.

In the last couple of years there has been a substantial growth in the use of drones by civilians, companies and government. Civilians mainly use drones for entertainment purposes like making videos of their surroundings, whereas companies and the government are exploring new applications for which drones can be deployed. Examples of this are for agricultural surveillance and decision support (Herwitz et al., 2004) or for disaster management (AUVSI, 2013). Companies like Amazon are exploring the possibilities of using drones for package delivery1. According to the Association for Unmanned Vehicle Systems

1

http://www.amazon.com/b?node=8037720011

International (AUVSI, 2013) roughly 90 percent of the economic activity surrounding drones will come in precision of agriculture and public safety applications.

However, before drones can be deployed on a large scale for such applications, some concerns related to safety and security need to be resolved first. A report from TNO published in March 2016 gives more insight in what these issues and corresponding risks are. Concerns related to the safety risks are particularly related to damage done to other aircrafts, people, infrastructure or other objects, whereas security risks focus more on crime, terrorists’ attacks, and information leaks.

The report concludes with several technical measures that can be taken to decrease these risks related to drones. Neither one could solve the mentioned risks on its own but a combination of several measures might. Two measures in particular are promising: geo-fencing and a Traffic Management System (TMS). Some drone models are already equipped with geo-fencing software or the pilot can make use of no-fly zone applications. However, the problem with these solutions is that the boundaries are static, often not up-to-date or not properly set (Jager, 2016). With regards to creating a Traffic Management System for drones, a first step is set by NASA with their Unmanned Aerial System Traffic Management (UTM) project. In this project they are currently testing several measures and functionalities such as airspace segregation, Vehicle-2-Vehicle-communication (V2V), congestion prediction and integrating other sources like weather (NASA, 2016). What the general functions of such an UTM should be and how obtained data is combined and visualized in a way to quickly give insights in the airspace situation, remains unclear. Furthermore, NASA only focuses on autonomous drones, therefore not keeping in mind the private drone users.

Many of these technical measures require both hardware and software adjustments. Considering that some drones simply do not have the capacity or room for such adjustments and combine that with the fact that drone manufacturers are not gaining anything from these adjustments, will complicate convincing drone manufacturers to co-operate. Interestingly enough, to the best of our knowledge, no publications mention the potential use of an Internet of Things (IoT) network. This is interesting because many drone models are (indirectly) connected to the internet via their native app, allowing them to send data to a central server without extra hardware adjustments to be made.

IoT solution can be used to diminish some of the safety and security risks caused by drones. This research has focused on exploring what the general functions of such an IoT solution should be and work out some use cases. The research is commissioned by Avanade, a business technology solution and managed services provider, with an expertise in Microsoft technologies. The overall quest of the research project can be formulated as follows: “In what way can Microsoft technologies offer an IoT solution to the safety and security problems related to drones? ”. It is hereby important that the system makes use of Microsoft technologies, either for storage, analytics, presentation, or action, as this is the core business of Avanade. Furthermore, it is important to keep in mind that this proposed system must create business value for Avanade’s clients.

2. RELATED WORK

In this section will first be elaborated upon drones and the different types, users and uses of them. After that some related research with regards to technical measures that can be taken to diminish safety and security risks will be discussed. Finally, the idea to make use of IoT will be justified and the important aspects that should be kept in mind when designing an IoT solution are discussed in short.

2.1 Drones

Drones are formally called Unmanned Aerial Vehicles (UAV) or Remotely Piloted Aircraft Systems (RPAS) and were first deployed for military purposes. In the last couple of years drones have become available on the consumer market, causing a shift in its users, shapes and sizes. The North Atlantic Treaty Organisation (NATO) has made a classification based on three distinct weight classes; up to 150 kg, between 150 and 600 kg and above 600 kg (Weimar, Kerkkamp, van de Wiel, Meiler, & Bos, 2016). TNO added a fourth category where NANO drones fall under.

In the Netherlands another, more general distinction is made between private (civilians) and business use (companies, government a.o.). Private drone use falls under the rules and regulations set for model aircrafts2. The same rules apply for business use of drones except that the owner (e.g. company) needs to obtain a RPAS Operator Certificate (ROC). The rules and regulations are mainly focused on limits regarding height (max 120 meters), remain within visual line-of-sight (max 500 meter), and stay out of no-fly zones. These rules apply to all drones up to 150 kg and no distinction is made, with regards to airspace access and rights, between certified pilots and private users.

In the field a different distinction is made were drone usage can be divided into three categories: drone as a toy, lifting platform or racing platform (Angela, 2016). Besides different uses there are also different users. DARPAS has identified the following four: professionals, professional cowboys, serious hobbyist, and private individuals (VnJ, 2016). Especially the professional cowboys and private individuals are groups to be the most concerned about with regards to the potential safety risks. The first is known for not taking set rules and regulations too seriously whereas the second often has less advanced drones and no prior experience with controlling one. A more detailed description of the distinction between users and uses can be found in

2

http://wetten.overheid.nl/BWBR0019147/2015-11-07

Appendix A.

Some drones can fly autonomous and follow a pre-programmed flight path but most drones are still remotely piloted by a controller such as a smartphone or tablet. The controllers typically communicate with the drone by making use of radio waves as drones are run by 2.4 gigahertz radio waves. Many drone controllers use Wi-Fi since most smartphones and tablets can tap into this without any accessories (Pullen, 2015). Furthermore, Wi-Fi can be transmitted on the 2.4 gigahertz spectrum. Drones are equipped with sensors that continuously transmit images and data regarding the drone’s surroundings and its operational status to the operator (e.g. controller) (Lu, Horng, & Chao, 2013).

It is important to keep all these users groups, uses and rules in mind upon designing an IoT Solution architecture.

2.2 Technical measures

In Q2 of 2016 the Dutch government started a campaign to make drone pilots more aware of zones that are prohibited for UAVs, so called no-fly zones. These no-fly zones can either be a control region (CTR), Aerodrome Traffic Zone, EHP (prohibited), EHD (dangerous) or EHR (restricted) zone (Aeret.nl, 2016). There are several apps such as Air-Share or Drone Pre-Flight that provide drone pilots with information on no-fly zones. However, this data is not always up-to-date and does not physically prevent drones from entering this no-fly zone (Jager, 2016). Geo-fencing does physically prevent drones from entering a no-fly zone, but this software makes use of the same database as the applications, and is therefore possibly not up-to-date. Another downside is that this database is static so in case of an emergency the airspace cannot be closed off for these UAVs. Besides that, the only manufacturer who had geo-fencing installed is loosening its restrictive grip and allows users to enter a no-fly zone when they ask for permission3.

White papers from Amazon and Google focus more on the importance of segregating the airspace and coordinating drones by equipping them with sense-and-avoid (SAA) or vehicle-to-vehicle (V2V) technologies, such as an ASD-B (Amazon, 2016a, 2016b; Google, 2016). In the paper of Amazon (2016) the following is suggested: the better your drone is equipped the more airspace access you gain. However, with this responsibility to know where you are and are not allowed remains with the pilot, whereas you would want to have more control over this.

A step further than just airspace segregation is the architecture of Devasia and Lee (2016) in which they propose to set up pre-established routes for UAV to reduce the costs associated with on-board sensing equipment, the so called uNet. Such an architecture would work well if drones only have a few destinations they go to. However, if drones are deployed for package delivery there has to be a route going to every address or they need to leave the pre-established route at some point, which means they need to have on-board sensing equipment again. Furthermore, private users are not taken into consideration.

NASA is the only organization that has actually started building and testing towards an overall solution with their Unmanned Aerial System Traffic Management (UTM)

3

project. This solution is cloud-based and aims to ensure safe and efficient low-altitude operations for all types of UAVs (NASA, 2016). A first field test, focused on reservation of airspace volume, was concluded in august 2015. A second and third field test, scheduled respectively in Q3 2016 and Q1 2018 are focused on beyond-visual line-of-sight operations, tracking, V2V, V2UTM, and internet connection. This step by NASA is one in the right direction, but it mainly focuses on the functionalities of these technologies in respect to the safety risks they solve, rather than combine them and provide clear use cases for when such a system will be used, by whom and for what.

2.3 Internet of Things

Internet of Things (IoT) is a network of everyday objects, equipped with ubiquitous intelligence and embedded with electronics, software, sensors, and network connectivity. Machine to Machine (M2M) connectivity makes it possible for machines, objects and humans to exchange real-time information and interact with systems and applications. An IoT solution architecture typically consist of three key elements: device connectivity, data processing/analytics, and presentation and business activity (Betts, 2016a). In the first element data gets collected from connected devices and sent to a cloud gateway. From there other back-end services process the data and deliver it to other line-of-business applications, dashboards or other devices. IoT enables integration of different systems with regard to communication, control, and information processing, and allows for interaction between vehicle, infrastructure, and users (Ersue, Romascanu, Schoenwaelder, & Sehgal, 2016). Figure 1 shows the general flow of an IoT solution architecture from device data to presentation.

Figure 1: general flow of an IoT solution

IoT is often used for applications related to transportation such as vehicle monitoring (Lingling, Haifeng, Xu, & Jian, 2011), smart traffic control, fleet management, vehicle control and safety assistance (Ersue et al., 2016). The real-time, interactive and relatively low implementation costs make it an attractive choice of technology for such use cases. An important aspect to keep in mind is the scalability of an IoT solution. It should be able to accommodate both current and future needs. Other things to keep in mind are the longevity of the networks technology (e.g. 4G), the device’s expected life span, how easily devices can be added and low maintenance. Security is another important aspect to keep in mind. Unfortunately it is still in its infancy leaving IoT vulnerable for malicious attacks (Maras, 2015).

2.3.1 Machine Learning

The addressed IoT use cases (see 2.3) often make use of Machine Learning models for predictive analytics. Machine Learning models can be of great value in the automotive industry by providing more insights in acquired data from the sensors (Microsoft, 2015). This data can be used to

improve driving experience or gain real-time and predictive insights on vehicle health and driving habits. Incorporating Machine Learning models might make it more attractive for drone manufacturers to participate and make the necessary adjustments. Besides that, it can also be of use for the users to become aware of potential malfunctions. Leaving these undetected could lead to crashing drones, which is a serious safety risk.

3. METHOD

Within this research both qualitative and quantitative research methods were used. To obtain information on the current situation and potential solutions interviews were conducted with several involved stakeholders. These interviews also provided insights in the functions the system should be able to fulfil. All were semi-structured interviews that lasted between 35 and 75 minutes. An oral consent was given to record the interview under the condition that everything discussed is only to be used within this research. The used interview guides and transcripts of each interview are found in Appendix D. Other informal calls and face-to-face meetings were held with specialists from Avanade to acquire more information on the Microsoft technologies.

Desk research was used to design the IoT solution architecture. For this Microsoft documentation, which is available online4 _{for most of their technologies, was}

consulted. Findings were discussed with members of the analytics team of Avanade to figure out if such ideas were technically possible and to gain insight in the limitations of either the Microsoft technology or Avanade’s expertise.

4. PROPOSED SOLUTION

Within this research an IoT solution architecture is proposed to which all operating drones need to connect and send sensory data to. This solution is aimed at providing insight and gaining more control over what is happening in the airspace so that safety and security risks of drones are diminished. For this a few demands are set. The sensory data needs to be processed in real-time and it has to be deployed on an European level, as adjustments are not made by drone manufacturers solely for the Dutch market. Another demand is that it can be operational within a short space of time. Section 4.1 will first discuss two scenarios that give ground for understanding the functions and users of this IoT solution, and what regulatory and technical changes are required before it can be deployed.

4.1 Scenarios

Based on the interviews two scenarios are sketched that indicate the current and possible future problems that are, or will be, encountered if no changes are made in the regulations of drones (VnJ, 2016; van der Pligt, 2016; TNO, 2016; de Boer, 2016).

In the first scenario a drone is flying in a no-fly zone as has happened multiple time at the start of 2016 near Schiphol. What is most worrisome is that the drones were spotted too late and authorities could not intervene with technologies like jammers due to important communication channels used at Schiphol. Furthermore, some drones made use of geo-fencing software and pilots relied on this software

4

to automatically stop them when entering a prohibited area as most pilots are not aware of the boundaries of no-fly zones. However, the database was not up-to-date.

The second scenario is based on a video presented at the Innovation Expo (van der Pligt, 2016). A private and service drone collide and crash because the sense-and-avoid (SAA) technology of the service drone has a malfunction and the other drone is not advanced enough to be equipped with such technology. The pilot of the private drone was not paying attention and was unaware of the presence of the service drone. Thus leaving it to the NFI to examine the debris and figure out who caused the crash. An extended description of the scenarios and encountered problems is found in Appendix B.

4.2 Users

Four different users, each with their own interests, have to be considered upon designing this architecture. The first is private users who’s main concern is that they do not want to be limited too much in their freedom (Angela, 2016). The second user group is business users who want to deploy drones to make operational processes more efficient. Drone manufacturers are considered as a third users group and are mainly focused on improving their service to expand their market share (de Boer, 2016). The last group, authorities (e.g. government), only want to be able to prevent or proactively respond on potential safety and security risks.

4.3 Functions

The scenarios and interviews were used to define the functions the solution should fulfil. There are at least six functions, to know: registration, overview, detect, notify, intervene, and learn. Each will be described in short below.

4.3.1 Registration

To help forensics or police get in contact with the owner of a drone after a wrongdoing has been encountered, a registration platform should be set up. The European Union is currently discussing this and should have a decision ready in 2018 (NOS, 2016). How drones will be registered, whether by serial number or chip, is not of concern for this research. What is important is that information, like the contact details of the pilot and drone type, will be stored in an Azure Table Storage, so it can be used as reference data (see 5.1).

4.3.2 Overview

Since the airspace has no physical boundaries like roads, there is no control over who flies where or has flown somewhere. It is therefore important that the GPS coordinates of all operating drones are mapped. This way authorities can keep track of drones that are in violation of the law and awareness is created under pilots of surrounding drones.

A new aspect, in contrast to current geo-fencing software, is that this IoT solution allows for dynamic no-fly zones information. New or temporary no-fly zones can be added to an Azure Table Storage, which also holds all information of other (static) no-fly zones, and can be used as reference data. Pilots can see these new no-fly zones on the map.

4.3.3 Detect, notify & intervene

When the location of all operating drones is known it will become possible to detect those who are flying in a

prohibited area. These pilots should be notified of their wrongdoing upon entering a no-fly zone so they can respond appropriately. Authorities should also be alerted when such a situation occurs so they can intervene. This notification can also directly be used to intervene; the notification sent to the drone or controller acts as an actuator which evokes a certain response (e.g. return-to-home). This will be dependent on the software changes drone manufacturers are willing to make, unless rules and regulations are set for this.

4.3.4 Learn

The previous discussed functions are mainly focused at getting more grip on where drones fly. However, solely obtaining this new insight does not outweigh the time and required adjustment needed to be made by drone manufacturers. From the learn function both user and manufacturers will benefit as Machine Learning models can be used to improve flight experience and service. Furthermore, Machine Learning can be used for predictive analysis and improve air traffic flow.

4.4 Regulatory and technical changes

Before this IoT solution can be unrolled some regulatory changes have to be made. Ideally, every drone should be equipped with geo-fencing software and it is currently under discussion to make this mandatory (TNO, 2016). However, such a demand does not keep in mind the drone models which are not advanced enough to be equipped with such software. It is therefore unlikely this law is carried out so we propose to set up yes-fly zones. Using yes-fly zones will give users a clear overview of where they are allowed to fly instead of having to keep in mind all kinds of rules about the maximum distance to different objects. As discussed with the Ministry of Safety and Justice and Pieter Elands, access to more airspace should be granted when drones meet certain safety-by-design demands, such as being connected to this IoT network. The four classes of Safe Operations scheme of Amazon can be used as a guidance to set the requirements (Amazon, 2016b). If this law does set geo-fencing software to be mandatory it should be turned around so unauthorised drones are unable to take-off anywhere but in a yes-fly zone. To be able to unroll this solution in the near future it would be simplest to let drones send data through LTE as mobile devices, which are used to control most drone models, already make use of this connection. Ballast and Petersen (2016), safety advisors from Agentschap Telecom, do mention that a special part of the radio spectrum should eventually be made free to enable such a drone network. This is something that has already been discussed at the last World Radio Conference in 2015, and is currently being investigated to see if such a dedicated frequency band is feasible. Ballast and Petersen add that for now they are mainly focussed on ‘larger’ drones that “will fly amidst normal aeroplanes”. However they do believe “that this is something that should be kept in mind, as it is coming and needs to be organized somehow ”. More research should demonstrate if the gain of such a dedicated spectrum outweighs the costs.

Furthermore, it is proposed to make a third distinction besides private and business use (see 2.1). This third category is reserved for drones that are deployed to ensure safety, like for disaster management. Drones within this category should be privileged with more rights such as

Figure 2: proposed IoT Solution Architecture

airspace access and sending commands that will evoke a certain action in the back-end of this solution. This information should be recorded in the registration so it can be used as reference.

5. SOLUTION ARCHITECTURE

There are too many different drone models that each communicate with their controller in a different way to consider them all within this research. To scope this research a decision was made to focus on one type of drone; the DJI Phantom. With the DJI Phantom users control their drone via an app installed on their mobile device. In this use case is worked under the assumption that the native app of the drone forwards data through LTE. Some software adjustments have to be made so the drone can send this data and accept commands coming from the back-end of this solution.

Within this IoT solution architecture all devices are connected to the IoT Hub to which they send their flight data. This data and other data sources are then processed and analyzed via several Stream Analytics jobs and Machine Learning Models. The output from this is stored in either a Blob Storage or Azure Data Warehouse. This data is then aggregated for presentation or consumption in Power BI, an interactive data visualization tool, and to the custom application being the native app of the DJI drone. Figure 2 shows the proposed IoT solution architecture.

As mentioned in section 4.3 this solution should fulfil several functions. These functions are encapsulated in four use cases as described below.

1. Collect coordinates of all drones and visualize their positions in real-time on a map.

2. Notify operating drones of temporal, new or updated no-fly zones and prevent them from entering this zone or making them exit one.

3. Enable V2V-communication so drones can accept commands from service drones.

4. Collect flight data and feed it to machine learning models for predictive analysis.

In sections 5.1 till 5.3 the elements (see 2.3) of this IoT solution architecture and the choice for using specific Azure Services will be explained. Sections 5.4 till 5.7 focus on the data flow of each use case.

5.1 Data streams

Within this solution there are two different types of data sources that are used as input: data streams and reference data. The data stream is data that is collected in real-time from the devices and is sent to the IoT Hub via LTE. Data is send per unit of time of one second. This will allow for a real-time visualization of the situation in the airspace with only a slight delay. The delay is dependent on network latencies. In appendix C an example is presented of the data that is collected from one device.

The second data source is so called reference data. This is slowly changing data and mainly used for look-ups. Within this solution there will be three reference data sources: noflyzonestable, registrationtable, flighthistorytable. The noflyzonetables holds all information on current no-fly zones but can be updated by a third party in case a new or temporarily no-fly zone is set up, for example during the VSV Breda Airshow. In the registrationtable information as recorded upon registration is found, such as contact details of the pilot. The flighthistorytable holds all data of past flights and is used to train the Machine Learning models. All stored data should be in line with the rules of the WBP as set for the processing and storing of data in the Netherlands, and regulations as set in other EU countries.

5.2 Data integration

Data from connected devices can be collected either via an IoT Hub or an Event Hub. Within this solution the IoT Hub is chosen as it enables reliable and secure bi-directional communication between device and application back end. Furthermore, with the IoT Hub it is possible to identify the devices that communicate with the hub, which is an important pre-requisite of this system as will become clear in sections 5.5 till 5.7.

For every drone an identity needs to be created in the identity register of the IoT Hub, where properties as deviceID, authentication keys, and connection status code are stored (Betts, 2016c). To add a device to the IoT Hub an Azure SDK is used, such as the graphical Device Explorer tool (for Windows) or command-line iothub-explorer tool (other platforms) (Betts, 2016b).

Figure 3: flow request token and connect to IoT Hub

These tools generate a device specific connection string which needs to be copied in the source code of the application running on the device. To ensure only authenticated devices can connect to the IoT hub a Token Service is set up. For this an IoT Hub shared access policy with DeviceConnect

permissions needs to be created. Using tokens signed with a shared access policy key grants the device access to all functionalities associated with the shared access policy permissions (Damaggio, 2016). A token is created when the device identity is authenticated with the identity registry. Figure 3 shows this process.

With Azure Active Directory (Azure AD) all identities are managed. Azure AD allows for role based access control. This solution knows at least two roles: user and manager. Those who are assigned to role of manager can gain access to all data needed to prevent an occurring safety risk. Users only see data relevant to them, such as the GPS coordinates of surrounding drones. These roles can also be used to grant certain drones (e.g. service drones) access to (temporary) no-fly zones.

5.2.1 Messaging

For the device to send and receive messages, respectively the send device-to-cloud and receive cloud-to-device device endpoints are used. Delivery latency is of concern within this solution as messages have to be sent and received in real-time. The best communication protocol to use is therefore either MQTT or AMQP of which the latter is preferred by Microsoft (Betts, 2016c). AMQP allows for multiple devices to connect via the same TLS connection, whereas MQTT requires a separate TLS connection for each device. For the applications back-end to communicate with the devices two service endpoints are used. These endpoints also use the AMQP communication protocol. For reading all message sent by a device this is the receive device-to-cloud messages endpoint, and for sending reliable messages and corresponding delivery this is the send cloud-to-device messages and receive delivery acknowledgments endpoint. All endpoints use TLS protocol, which is designed to prevent security threats such as message tampering (IETF, 2016).

5.3 Analytics

Microsoft offers two real-time analytics platforms: Stream Analytics (SA) and Apache Storm (AS). Both are used

to detect anomalies, trigger alerts when errors occur, and feed real-time dashboards. In this solution SA is chosen, but AS might be preferred in a later stage. This because within Apache Storm the user is not limited to the SQL language for writing queries, but can also use java, c] or use Trident API’s, which allows for more advanced analysis (Stokes, 2016). However, SQL suffices for the queries used within this solution. Besides that, SQL offers an easy way to join two data sets or to extract a specific element to run further analysis on. This is something often used within this solution, as will become clear in section 5.4 till 5.7. Two downsides of SA are that it is limited to 50 Streaming Units, which affects the scalability, and a maximum size of 100 MB is set for reference data. AS does not have these limitations plus it allows for more data sources to be used as input such as Service Bus, and unsupported connectors can be implemented via custom code. On the other hand, AS charges are based on running time instead of processed volume. Weighing all pros and cons of both analytics platform, and considering that first a proof of concept has to be built to test, evaluate and reiterate the four use cases, the choice fell on using SA. The added complexity of setting up an AS environment does only outweigh the limitations of SA when more complex analysis are needed and the turning point is reached where run times charges become less expensive due to the growing volume of data.

5.3.1 Lambda Architecture

To allow for real-time analytics a Lambda Architecture can best be used. By using a lambda architecture the IoT architecture is split into three layers: a batch, speed, and serving layer (see figure 2). The Batch layer is suited for handling large volumes of data over an extended period of time. In this layer all drone telemetry data gets stored in the flighthistorytable (see 5.1) in Data Lake, which feeds it on a daily basis to the Machine Learning Models to train and improve them. The rules coming from these models are stored in Azure Data Warehouse and used as input for Stream Analytics to perform analytics with high velocity over the real-time data. The output of these two layers is stored in the serving layer to report the data (e.g. Power BI).

5.3.2 Scale and costs

To handle the high data throughput the solution has to be scaled correctly. Scalability is an important aspect to keep in mind to keep costs and latency of throughput at a minimum but efficiency and speed at its best. Azure sets throttling limits to protect against usage peaks and prevent servers to go down, so proper operations of the IoT Hub are ensured. If the limits are reached, it will cause a delay in the throughput, which affects the real-time aspect of this solution. To size an IoT solution the traffic on a per-unit basis has to be evaluated. The current situation in the Netherlands, with regard to the amount of operating drones, is used to gain some insight in the scale of this solution and associated costs.

As of now there are one hundred thousand drones in the Netherlands. These have an average flight time of twenty minutes. Based on some drone fora’s most users fly their drone on average three times a week, which would mean ≈40.000 drones a day. It is unclear how many of these are for private or business purposes, so for the convenience

it is split in half. An assumption is made that private drones are operating after working hours (17:00-21:00) and the rest during work hours (08:00-17:00). This leads to an average of at most ≈5.000 an hour or ≈1.670 per twenty minutes. It is unlikely a situation occurs where the amount of operating drones is evenly distributed, so in this calculation we evaluate a scenario where twice that amount of drones, so ≈3.500, are connected to the IoT Hub and ingest their data every second. To control the throughput the following operations throttles need to be considered to decide how scalable the solution has to be (Berdy, 2016):

• Device connections are throttled based on how many expected devices connect at any given time to the IoT Hub. Based on the situation sketched above this will be less than one per second, under the assumption of an even distribution under the amount of drones connecting every second. One S1 unit suffices, as this allows a throughput of 12/sec/unit.

• Device-to-cloud telemetry is throttled based on the amount of messages send per device. If 3.500 drones send a message every second this would lead to 210.000 message per minute. A message is around 7.3 KB but messages are metered in blocks of 4 KB, causing the amount of messages to be 420.000 per minute. A S1 unit can handle 12 device-to-cloud messages per second per unit, a S2 unit 120/sec/unit, and a S3 unit 6000/sec/unit (Betts, 2016c). Device data needs to be ingested into the IoT Hub in real-time and without delay. To enable this this solution requires either 584 S1 units, 59 S2 units or two S3 units, of which the latter is the cheapest (≈ 8.000 euro a month). • Cloud-to-device commands are throttled based on the

amount of messages send from the application back end to the devices. As only under certain conditions messages to connected device are sent, the two S3 units needed to enable a real-time throughput of device-to-cloud telemetry should suffice.

Expected is that the use of drones will grow exponentially in the coming years. To be able to handle the increasing throughput consequentially the number of IoT Hubs units has to be scaled up. Combining the costs for the units and all other used services, such as data storage and retrieval, a rough estimation of the monthly costs is set between the five and fifty thousand a month for the first year5_{. This}

is dependent on the amount of connected devices and total flight time. The costs will grow exponentially as more data is collected, stored and processed. These costs could be split under all users (see 4.2). As an example; private and business users can pay a yearly fee to make use of the airspace (similar to road tax), whereas drone manufacturers pay for the Machine Learning Service.

5.4 Use case 1: Real-time overview

The first functionality of this IoT solution is to provide pilots and authorities with an overview on which operating drones are shown in real-time. For this the following Microsoft technologies are used: IoT Hub, Stream Analytics, Power BI, see figure 4. The device sends data to the IoT Hub using the send device-to-cloud endpoint. In order

5

https://azure.microsoft.com/en-us/pricing/calculator/

to visualize all operating drones in one overview the GPS coordinates are needed. A Stream Analytics query is used to extract the droneID, latitude, longitude, and EntryTime from the IoT Hub. Before the location of the drone can be pinpointed on the map, the latitude and longitude column need to be combined. This because the Bing map6can only interpret a string of “latitude, comma, longitude” to find the corresponding location (Hart, 2016; Rad, 2015). For this a second Stream Analytics query is needed with the following statement: SELECT CONCAT(latitude, longitude) AS droneLocation. The output job of Stream Analytics then serves as an input for Power BI.

Figure 4: flow use case overview

As of now Power BI can only visualize data points as a dot on the map in a so called bubble map. The Bing map is used as a background allowing the user to zoom in and out and see where drones are in relation to other geographical features. The users’ own drone will be displayed in the center of the map. Such visualization will suffice for pilots as it will create more awareness of surrounding drones. To integrate the map into the mobile app, the Power BI API can be used. For authorities additional information would be desirable such as visual cues (e.g. heatmaps) that indicate unsafe situations and information on drone type and its pilot. For this a custom visualization need to be created. Rules for when a situation is seen as unsafe, for example when too many drones are cluttered in one location, has to be decided upon. This visualization can be used by authorities or others with a manager role (see 5.2) as a reference for when an alert is issued. A hybrid solution will have to be created to provide both users with required information.

5.5 Use case 2: new and temporary no-fly zones

The second functionality of this solution is to make no-fly zones dynamic so that new or temporary no-fly zones can quickly be communicated to operating drones and potential safety risks evaded. To detect drones that entered a new no-fly zone a Stream Analytics query is used. This query joins the reference data set called noflyzonestable, which contains all coordinates of no-fly zones (see 5.1), against the stream data containing the GPS coordinates of all operating drones. The query will compare for every row in the noflyzonestable if the latitude and longitude columns match with the latitude and longitude values as sent by every connected device. When they match an output file

6_{Bing is integrated in Power BI and provides default map}

Figure 5: flow use case dynamic no-fly zones

is created. This message contains the droneID and states the desired action. This file is sent to a Service Bus topic. All devices are subscribed to topics relevant to them. In this example there is a topic ‘no-fly zones’ to which all devices are subscribed. By defining a filter the device will only receive messages that are relevant for them. Relevant messages are those where the property droneID matches with the device’s ID. Figure 6 gives a visual representation of this. This message will evoke a certain action in the drone. The implementation of this actuator lies with the drone manufacturer; a warning message can be presented on the native app or it can directly trigger the desired behaviour in the drone, like hover or return-to-home.

Figure 6: flow sending message to relevant receivers

For autonomous drones being able to accept commands should be set as one of the safety-by-design demands. It is likely that such a demand would lead to resistance under private users as it can be seen as an infringement of their rights, plus DJI has announced it will allows users to enter no-fly zones upon entering their phone number. It is therefore important that authorities get notified when drones remain in a no-fly zone for an extended period of time, say thirty seconds. By storing the SA output file in a storage blob it is possible to track its status, and if it is not resolved within thirty seconds a warning message can be send to authorities, see input stream ]3 of figure 5.

In figure 5 Data Factory is added to the architecture. This is because the noflyzonestable reference data is stored in Azure Table Storage (ATS) which is not a valid input for Stream Analytics. With Azure Data Factory Pipeline Copy

function a copy of this table is made and stored in Blob Storage, which is a valid SA input, when data has changed. The data stored in the noflyzonestable ATS needs to be visualized on the same map as discussed in the real-time overview use case (see 5.4). It is not possible to combine the bubble map and the shape map, used to plot the outline of no-fly zones, into one map. A custom visualization has to be made that can take in two different data sources and visualize them on the same map in a different way. For now an option is that both maps get integrated into the native app via the Power BI API and the user can toggle between the two. For the shape map a refresh schedule has to be configured as it does not take in streaming data. For this a visual container refresh is most suited as it updates the visuals when data changes (Saxton, 2016). The shape map will create awareness under pilots to see when they are near a no-fly zone.

5.6 Use case 3: send and accept commands

The third functionality of this solution is for drones to communicate and send message to each other, similar to V2V communication. This message will then be interpreted and triggers the desired action, such as return-to-home. Figure 7 shows the flow of this use case.

The IoT Hub allows for two types of message to be send: data point messages and interactive device-to-cloud messages. Data point messages hold all sensor and flight information and are only used for analytics, whereas interactive device-to-cloud messages can directly trigger a set of actions in the applications back end. As discussed in section 4.4 is proposed to make a third distinction under drones besides private and business use. Service drones should be able to send interactive device-to-cloud messages that can be used for example to overrule the flight path of surrounding drones when a safety or security risk is at hand. To determine the relevant receivers of this message a Stream Analytics job is used to calculate the distance between two drones using the SQL Server geography data type. Another way is to work with a geographical grid. This output is sent to Service Bus for processing, where the message will

be delivered to the right drone(s) via the cloud-to-device endpoint.

Figure 7: flow use case ‘sent and accept commands’

Upon evaluating this use case, several concerns were raised. Within this solution messages are sent via LTE, where network latencies are not uncommon. Letting such messages be solely dependent on a stable connection can be risky and does not ensure the avoidance of potential safety risks. It might be best to use this as a redundant technology besides direct V2V-communication as an extra check or to overrule commands in extreme and exceptional cases. However, creating a function that could overrule other commands, and basically allows one to hack and gain control over drones, leads to a high security risk. For these reasons was decided not to follow up on this use case.

5.7 Use case 4: Machine Learning

Up till here the use cases are mainly focused on creating awareness under users and providing more insights to authorities about the situation in the airspace. As mentioned, this solution cannot come about without the help of drone manufacturers. It is therefore important that they will gain something too.

Using Machine Learning will be beneficial for all users of this system. Azure Machine Learning allows for scalable, timely, proactive, and actionable anomaly detection and predictive analysis. Drone manufacturers will learn and gain more insight in the performances of their drones, which will allow them to make improvements. Consequently, potential safety and security risks can be detected in advance so users can react proactively on them in case of a malfunction or malicious attack. This way users will not have to fear their drone crashes. Furthermore, Machine Learning can also be used to make business processes that make use of drones, more efficient and therefore faster and cheaper. The possibilities of Machine Learning applications are endless, but the two most interesting for diminishing safety and security risks will be described in sections 5.7.1 and 5.7.2.

5.7.1 Anomaly detection model

The goal of this model is to detect anomalies in device data such as changes in dynamic range, spikes and dips that might indicate security attacks or malfunctioning hard-or software. Azure Machine Learning has an Anomaly Detection API which can be used to detect anomalies. This API can best be used in cases where no prior information is known as what is seen as normal asset values. The model is trained by determining what constitutes as a ‘normal’ asset value. After that, a distance metric is used to identify cases that represent anomalies. In figure 8 a 45 second long time

series is shown with the corresponding altitude of the drone. The dots represent the beginning of a distinct level change, in this case a drone that is slowly taking off. The arrows represent a spike, and clearly show abnormal values on that specific time.

Figure 8: visual representation of collected altitude data of a drone over time

The Anomaly Detection API can be used for detecting anomalies in single assets such as battery temperature. However, there might also be a correlation between assets that could indicate anomalies. For example a correlation might exist between the three assets CENTERBATTERY.voltageCell2, OSD.isNotEnoughForce, and OSD.motorStartFailedCause or battery temperature is high but outside temperature is low. The built-in Principal Component Analysis (PCA) algorithm in Azure can be used to detect negatively correlated assets.

Detecting such spikes can make users aware of potential spoofing attacks or failing components so they can react immediately and prevent safety risks. This model can further be extended by combining the data with other data sources such as weather conditions like past geomagnetic storms or by looking at time and place the anomalies were detected. This way more insight is gained in factors that might influence a drone’s flight. For example, it could be that too many drones in one area could lead to disturbance. When this is known in advance the flight path of drones can be adjusted accordingly. Drone manufacturers can use these new insights of how for example weather influences a drone’s flight to improve and make its hardware more resistant in such conditions.

5.7.2 Predictive maintenance model

Considering that drones will be deployed for business uses like in agriculture it can be troublesome if this process is delayed due to mechanical problems. Being able to proactively prevent such situations can diminish safety risks, as a crash can be prevented, and cut costs. The predictive maintenance model aims to predict the probability a drone will fail based on the failure of particular components. Drone manufacturers that offer drone models able of doing such predictions will have a competitive advantage.

To train this model, at least three data sources are needed. The first is historical data of known machine or component failures, which is used by the predictive model to learn. This will have to be obtained from drone manufacturers. The second is real-time telemetry data from the drone such as its altitude or battery temperature. The last data source is information on drone features such as make and model as is stored in the registrationtable (see 5.1).

For the model as multi-class logistic regression can best be used as the probability at a specific outcome of dependent variables has to be predicted based on a set of independent

variables, making it a multi-class classification problem. Before the model can be trained, features need to be created that describe a drone’s health condition at a given point in time. A suitable method would be to calculate lagging features which aggregates telemetry data over a specified time window. Other methods are to be determined and depend on the properties of each data source.

6. DISCUSSION

With this paper a proposal for a IoT solution architecture was made that can be established with a minimum amount of adjustments needing to be made in the soft- and/or hardware of drones. However, more adjustments can allow for better and faster analysis of streaming data. An example is the use of a field gateway, which can run edge analytics, minimizes latency, conserves network bandwidth, act upon data locally, provides encryption, and identity services (Betts, 2016d). It can be particularly useful for scenarios where a system failure is imminent and milliseconds might matter, such as in the scenarios described under section 5.7.2. A field gateway sits between the device sensor and the IoT Hub and can therefore also allow drones that are not connected to a mobile device to send their data. It would be highly recommended to set this as a safety-by-design demand as the gains outweigh the effort of placing it. Using a field gateway can also cut costs as less data has to be sent via LTE. For example, autonomous drones can send one data file containing its entire flight path to the IoT Hub so only divergent data has to be sent via LTE during its flight.

From this, a second limitation of this research becomes apparent. As mentioned before, only the DJI Phantom was taken into consideration while designing this IoT Architecture, since this was the only drone of which data could be obtained7. The Stream Analytics Queries and Machine Learning Models are based on the type, labeling and structure of the data coming from the DJI. It is plausible that other drone models use different labels for data columns such as latitude or height. This is something that has to be considered during the implementation phase of this architecture, unless international standards are set. The Stream Analytics queries should either take all different labels into consideration or a separate model for each type of drone has to be created.

Related to that is the need for drones to be able to interpret messages sent by service drones or the applications back-end. For this international standards need to be set as well to ensure interoperability between all types of drones.

Another limitation of this research was the lack of a data set with actual flight data. Due to this, many assumptions were made in this research. For example the asset values were decided based upon common sense, such as altitude is a interval variable. However, it might be that the variable ‘SMARTBATTERY.seriousLowWarningLanding’ does not have a value on or off, but is numerical too. This would mean that the chosen Machine Learning algorithm has to be revised.

Furthermore, the knowledge about the capabilities of Microsoft Azure technologies, and in particular those related to IoT solution, is limited to a few use cases often related to the transport, health and finance sector. A new use

7_{Only headers of variables were obtained as actual values is}

privacy-sensitive data

case, such as this, can often only be validated during the implementation phase. All discussed within this paper is underpinned by Microsoft documentation or related use cases. However, it might be that different technologies or services need to be used. To add to that, Microsoft Azure Services and revenue models change frequently. This could cause this IoT architecture to become out-dated with regards to some specific implementation solutions. However, the general functionalities and flow will remain the same.

7. CONCLUSION

In this paper a conceptual foundation for an IoT solution architecture is laid out and insight is gained in what way Microsoft Technology can be used to offer a solution to the safety and security related risks drones cause. In order for this architecture to be deployed, some technical and regulatory changes have to be made. With regard to regulatory changes, it is proposed to set yes-fly zones where all drones are allowed to fly. Drones that meet certain safety-, and security-by-design demands can gain access outside of these predefined yes-fly zones. The demands are related to the technical adjustments that have to be made in order for the drone to be able to connect to IoT Hub, send GPS coordinates and if possible other flight data via LTE, accept commands, and visualize information coming from the back-end of this solution.

In this paper four potential uses for this IoT solution architecture are explored of which three show potential for real world application. First, it gives authorities more grip on what is happening in the airspace by providing them an overview that maps all operating drones. This overview allows them to intervene timely in case a potential safety risk arises and creates awareness among pilots of these restricted areas. Furthermore, it allows for dynamic no-fly zones. This will allow a part of the airspace to be closed off in case of an event. Finally, with this IoT solution safety or security risks can be prevented before they unfold. This is achieved by using Machine Learning models which provide insight in the data collected from all devices so that malfunctions or malicious attacks can be detected in time.

A fourth use allowed for drones to communicate with each other by sending interactive messages that would trigger a desired behaviour in the receiving device. Although potential safety risks can be evaded with such messages, there are several reasons why it has no potential. By enabling a function that can overrule the flight path of other drones an even bigger security risk is at hand in case of a hack. Furthermore, it is best to send such important messages directly to other drones (e.g. beacons), instead of via LTE, which can be subject to network latencies.

These four uses provide a first insight in the possibilities of this IoT based solution in solving several of the safety and security risks related to drones. A next step is to implement and test this proof of concept and research other potential use cases. It is then up to the government to set clear guidelines for drone manufacturers so they can make the necessary adjustments, and interoperability is ensured.

8. FUTURE WORK

This research was a first step to a more tangible and practical solution that, when deployed, can help diminish some of the safety and security risks of drones. As

mentioned, a next step is to move from design to the implementation phase so the use cases can be tested. However, some unresolved issues need to be addressed beforehand.

Within this research only the DJI Phantom was taken into consideration. It is therefore important to do an extensive research to the different types of drones, how they communicate and what adjustments would have to be made to enable them to connect to the IoT Hub. This research can then serve as input for setting the rules and regulations regarding the requirements of drones in both soft- and hardware so that interoperability is assured. Drone manufacturers need to be able to make the necessary adjustments before this solution is deployed. In this research some safety-by-design requirements are already laid out, but these can be further elaborated upon. For example, map all areas that can be considered a yes-fly zone.

Consequently, a next step is to gain more insights in the exact data that these drones collect. For this the cooperation of drone manufacturers is required that will hand over historical data. Data has to be anonymized so privacy is of no concern. From DJI it is known that they collect data of their users’ drone flights, but this is unknown for other drone models. If not, an application that can simulate flights has to be built so data is obtained to train the Machine Learning models. Important to consider is that the model might become overtrained and is not representative for real world situations. However, it is a first step and the model can be refined later with actual data coming from connected drones.

Furthermore, the model can be extended with other Machine Learning models or use cases. For example it can be important to train a model that can predict the flight path of a drone. This way a prediction can be made of the drone’s location in case of a loss of link. The algorithms discussed in this paper are just one way to obtain the required information. Future research should also focus on finding other algorithms and use a scoring model to determine which performs best. Dependent on whether or not international standards are set for data type and labels, one model should suffice. A use case that can be further elaborated upon is to give drones that fly within a certain radius of a no-fly zone a preliminary warning. Research can look in to using a geographical grid so relevant drones can quickly be determined.

Another suggestion is to perform tests to measure the time it takes for data to be sent to the IoT Hub into the applications back-end and back to the device. Real-time is an important component of this architecture so any delay could result in a safety risk. Research should focus on discovering what causes network latencies, how to overcome them, and how to detect network latencies so they can be considered as input for building the rules that are used to perform real-time analytics over the drone telemetry. Tests can also be done to see which of the Microsoft technologies give the fastest results. It might be that Apache Storm is quicker than Stream Analytics at processing all collected data. To add to that, it is important to gain insight in when the limits of Stream Analytics’ capabilities are reached and the potential of Apache Storm outweighs the added complexity of setting it up.

9. ACKNOWLEDGMENTS

I would like to thank Peter Meij for his guidance and support in completing this research. I would also like to thank Zeno Geradts for his supervision and everyone who made their time available for interviews or contributed to this research in any other way.

References

Aeret.nl. (2016). Handleiding drone preflight. Retrieved 2016-5-9, from http://www.aeret.nl/wp-content/ uploads/2015/06/Handleiding-Drone-PreFlight-1.06.pdf

Amazon. (2016a). Amazon revising the airspace model for the safe integration of suas 1. Retrieved 2016-7-3, from https://utm.arc.nasa.gov/documents.shtml Amazon. (2016b). Determining safe access with a

bestequipped, best-served model for small unmanned aircraft systems. Retrieved 2016-7-3, from https:// utm.arc.nasa.gov/documents.shtml

Angela, H. (2016). Senior analist and data engineer at avanade.

AUVSI. (2013). The economic impact of unmanned aircraft systems integration in the united states. Arlington, USA: Association for Unmanned Vehicle Systems International.

Ballast, A., & Petersen, G. (2016). Advisors space communications at agentschap telecom.

Berdy, N. (2016). Iot hub throttling and you. Retrieved 2016-7-1, from https://azure.microsoft.com/en-us/blog/iot-hub-throttling-and-you/

Betts, D. (2016a). Azure and internet of things. Retrieved 2016-7-5, from https://azure.microsoft.com /en-us/documentation/articles/iot-suite-what-is-azure-iot/

Betts, D. (2016b). Azure/azure-iot-sdks. Retrieved 2016-6-29, from https://github.com/Azure/azure-iot-sdks/blob/master/doc/setup-iothub.md Betts, D. (2016c). Azure iot hub developer guide.

Retrieved 2016-6-13, from https://azure.microsoft .com/en-us/documentation/articles/iot-hub-devguide/

Betts, D. (2016d). Design your solution. Retrieved 2016-6-13, from https://azure.microsoft.com/en -us/documentation/articles/iot-hub-guidance/ Damaggio, E. (2016). Use iot hub security tokens

and x.509 certificates. Retrieved 2016-6-16, from https://azure.microsoft.com/en-us/documentation /articles/iot-hub-sas-tokens/security-token-structure

de Boer, T. (2016). Rpas pilot/engineer dutch drone group. Devasia, S., & Lee, A. (2016). A scalable low-cost-uav traffic

network (unet). CoRR, abs/1601.01952 . Retrieved from http://arxiv.org/abs/1601.01952

Elands, P. (2016). Projectmanager of a four year research program on ’unmanned aerial vehicles’ commissioned by the ministry of defense.

Ersue, M., Romascanu, D., Schoenwaelder, J., & Sehgal, A. (2016). draft-ietf-opsawg-coman-use-cases-01 - management of networks with constrained devices: Use cases. Retrieved 2016-7-5, from https://tools.ietf.org/html/draft-ietf-opsawg-coman-use-cases-01

Google. (2016). Google uas airspace system overview. Retrieved 2016-7-3, from https://utm.arc.nasa. gov/documents.shtml

Hart, M. (2016). Tips and tricks for power bi map visualizations - microsoft power bi. Retrieved 2016-6-20, from https://powerbi.microsoft.com/ en-us/documentation/powerbi-service-tips-and-tricks-for-power-bi-map-visualizations/ Herwitz, S., Johnson, L., Dunagan, S., Higgins, R.,

Sullivan, D., Zheng, J., . . . Aoyagi, M. e. a. (2004). Imaging from an unmanned aerial vehicle: agricultural surveillance and decision support. Computers and Electronics in Agriculture, 44 (1), 49-61. doi: 10.1016/j.compag.2004.02.006

IETF. (2016). Rfc 5246 - the transport layer security (tls) protocol version 1.2. Retrieved 2016-6-16, from https://tools.ietf.org/html/rfc5246

Jager, W. (2016). Drone-app hover toont nu ook nederlandse no-flyzones. Retrieved 2016-5-9, from http://www.dronewatch.nl/2016/02/24/drone-app-hover-toont-nu-ook-nederlandse-no-flyzones/ Lingling, H., Haifeng, L., Xu, X., & Jian, L. (2011). An

intelligent vehicle monitoring system based on internet of things. 2011 Seventh International Conference on Computational Intelligence and Security. doi: 10.1109/cis.2011.59

Lu, J.-L., Horng, R.-Y., & Chao, C.-J. (2013). Design and test of a situation-augmented display for an unmanned aerial vehicle monitoring task 1. Perceptual and Motor Skills, 117 (1), 145-165. doi: 10.2466/26.22.pms.117x10z7

Maras, M.-H. (2015). Internet of things: security and privacy implications. International Data Privacy Law , 5 (2), 99-104. doi: 10.1093/idpl/ipv004

Microsoft. (2015). Vehicle telemetry analytics. Retrieved 2016-7-5, from https://gallery. cortanaintelligence.com/SolutionTemplate/ Vehicle-Telemetry-Analytics-2

NASA. (2016). Unmanned aircraft system (uas) traffic management (utm). Retrieved 2016-7-3, from https://utm.arc.nasa.gov/index.shtml

NOS. (2016). Nieuwe campagne: vliegvelden zijn niet voor drones. Retrieved 2016-6-1, from http://nos.nl/artikel/2108449-nieuwe-campagne-vliegvelden-zijn-niet-voor-drones.html

Politie.nl. (2016). Wereldprimeur: politie zet roofvogels in om drones uit te schakelen. Retrieved 2016-2-9, from https://www.politie.nl/nieuws/2016/januari/31/ wereldprimeur-politie-zet-roofvogels-in-om-drones-uit-te-schakelen.html

Pullen, J. (2015). This is how drones work. Retrieved 2016-3-9, from http://time.com/ 3769831/this-is-how-drones-work/

Rad, R. (2015). How to do power bi mapping with latitude and longitude only. Retrieved 2016-6-29, from http://www.radacad.com/how-to-do-power-bi-map ping-with-latitude-and-longitude-only

Saxton, A. (2016). Data refresh in power bi. Retrieved 2016-6-30, from https://powerbi.microsoft.com/ en-us/documentation/powerbi-refresh-data/types -of-refresh

Stokes, J. (2016). Help choosing a streaming analytics platform: Apache storm comparison to azure

stream analytics. Retrieved 2016-6-22, from https://azure.microsoft.com/en-us/documentatio n/articles/stream-analytics-comparison-storm/ TNO. (2016). Technical aspects concerning the safe and

secure use of drones.

van der Pligt, C. (2016). Senior advisor industrial automation at rijkswaterstaat.

VnJ. (2016). Beleidsadviseur. Ministerie van Veiligheid en Justitie.

Weimar, P., Kerkkamp, J., van de Wiel, R., Meiler, P., & Bos, J. (2016). Miniature uavs: an overview. TNO.

APPENDIX

A. USERS AND USES OF DRONES

With regard to the rules and regulations regarding drones in the Netherlands a division is made between private use and professional use, and the weight of the drone. However, more should be kept in mind like why the drone is used, who is the pilot and how it is controlled.

A.1 Drone as a platform

According to Heinrich Angela, senior analyst at Avanade and serious drone hobbyist, drones can be divided in three categories: drone as a toy, lifting platform or racing platform. Toy drones are for those who are new to the game. They require no assembly, are harder to control and have little room for additional features and expansions. Drones within the category lifting platform are often more expensive multirotors and used for industrial purposes. They can be equipped with different payloads and have advanced features like return-to-home and autonomous flight path. The final category, drone as a racing platform, is very modular offering complete freedom for choice of components.

A.2 Drone users

DARPAS has identified four different types of drone users. The smallest group is that of the professional users who meet all accreditation and use it for industrial purposes. Then there is a small group called professional cowboys who have set up some business to make money from the use of drones, and is known for not taken the rules set by the government all too seriously. The third group is that of the serious hobbyist. This type of user often builds their own drones and is known to the potential risks they possess. They have their own fora and take the set regulations very seriously as they do not want to risk losing their drone. The final, and largest group, is that of private individuals, who are often not aware of the rules and just use it for fun or shoot some pictures of their surroundings.

In table 1 the drone uses as identified by Heinrich Angela and the drone users are combined. A + indicates that the majority of the users would use their drone either as a toy, lifting- or racing platform. The - means that it is uncommon use for these type of users and the +/- indicates that they might use their drones in such a way.

Drones that are used as a toy are the one to be most concerned about since they are harder to control, making them more vulnerable to crashing and other potential safety risks. Especially, since they are not equipped with features like return-to-home or hover in case of a loss of link between the drone and its controller. The relatively cheap character of drones falling within this category makes them interesting

Toys Lifting Platform Racing Platform Professionals - + +/-Professional cowboys +/- + +/-Serious hobbyist + +/- + Private Individuals + -

+/-Table 1: different type of users and uses of drones

for private individuals to buy. However, this is exactly the type of drone user who is not familiar with controlling a drone, increasing the change of potential safety risks.

B. SCENARIOS AND ENCOUNTERED PROBLEMS

The main concerns of the government and other involved stakeholders regarding drones will become more apparent by sketching two scenarios and indicating what problems were encountered. These scenarios are fictional but based on the problems drones caused as mentioned during some of the interviews.

B.1 Scenario 1

In the first scenario a drone is spotted flying a few meters from the Zwanenburg runway of Schiphol. Police forces are alarmed and are trying to find the pilot. The police could have used jammers to take the drone down, but an airplane was about to land. Since it is uncertain how the drone would react, the risk was to big too use this technic. Besides that, jammers could disrupt other crucial communication channels used at Schiphol. All parties involved wonder how it is possible the drone could have gotten this close without being spotted sooner. After ten minutes the police finds the drone’s pilot and arrests him. The pilot states that he did not know Schiphol was a no-fly zone and just wanted to take some photos of the landing airplane.

B.1.1 Encountered problems

This first scenario is based on true events that have happened nearby Schiphol beginning of 2016. Although up till now no collision between a drone and an airplane has occurred, this situation does make clear that there is a potential safety and security risk when drones are spotted too late. And even when a drone is spotted on time, the pilot needs to be found too before they can safely take down the drone. Especially in areas that rely heavily on radiofrequency, such as Schiphol to enable communication between the Aircraft Control Room (ACR) and airplanes, using technics to overtake drones, such as jammers or spoofing, could lead to even greater safety or security risks. Furthermore, the pilot was not notified about entering a no-fly zone even though his drone was linked to the no-fly register. However, current no-fly zones not accurate enough. Problematic as well is that according to the current laws and regulations in the Netherlands, a drone is not allowed to fly over buildings and roads, but this law cannot remain when plans are being made to use drones for package delivery and other services. This would imply that exceptions should be made for some drones, which complicates and makes matters

about what is and is not allowed even more unclear, as is why within this research is plead to set up yes-fly zones.

B.2 Scenario 2

In the second scenario a private individual is flying with his new drone on an open field close to a forest. He is showing off his drone to his friends, who keep asking questions about the drone. This slightly distracts the pilot. While answering one of the questions, he is unaware that he steered his drone up a bit. According to the altimeter the drone now flies at 130 meter while only 110 meter is allowed. The airspace between 110 and 150 meter is reserved for service and professional drones. The forest is blocking some of his view and he notices too late that a service drone, on its way to deliver an organ transplant to a nearby hospital, is crossing his drone at a high speed. The drones collide and both crash, causing a small fire in the forest. The pilot is afraid he would get in trouble with the police so he ran and left everything behind.

B.2.1 Encountered problems

This second scenario is hypothetical but plausible considering the staggering and continuous growth of drones over the last couple of years. According to the FAA (2016) the amount of operating drones in the U.S alone will have trebled by 2020 to 4.3 million civilian drones and 2.7 million commercial drones. We can assume that a similar growth will be seen in Europe. The first concern that is raised within this scenario is one specifically for the Forensic Institute and police department, because they have no way of determining who can be held responsible for the crash and additional damage it caused. Furthermore, both drones were unable to react autonomous to prevent a collision for when the drone’s pilot is not paying attention to his surroundings or is not notified of an approaching drone.

Another currently hypothetical, but plausible aspect of this scenario is that of airspace division. As mentioned in the report of TNO and presented at the innovation expo by Cees van der Plight from Rijkswaterstaat, a plan is to divide the airspace into so called corridors, which are simply put highways for drones. This would work well for professional and service drones that have a clear destination. However, this does not apply for private drone use as this would extremely limit their ‘playing’ field. Not keeping in mind this group of drone users when establishing these corridors, while this is group with the least advanced drones, just causes some of the current concerns to remain.

Furthermore, something can be said about the materials the drones are made of and how drone should be designed in such a way that they do not easily combust upon impact. However, this is in the hands of drone manufacturers, which, in their turn, are in need of clear guidelines that are yet to be determined by the government or European Committee (Elands, 2016). Unfortunately, too little research has been done in this field to understand to potential safety risk of drones (TNO, 2016). However, this is something that is currently being researched by a workgroup from the European Committee (Ballast & Petersen, 2016), and falls out of the scope of this research examine in more detail.

C. EXAMPLE OF STREAMING DATA