Broker Architecture for Collaborative UAVs Cloud Computing

Download PDF
4 downloads 79306 Views 423KB Size Report
Comment
Broker Architecture for Collaborative UAVs Cloud. Computing. Sara Mahmoud and Nader Mohamed. The College of Information Technology. UAEU, Al Ain, UAE.
Broker Architecture for Collaborative UAVs Cloud Computing Sara Mahmoud and Nader Mohamed The College of Information Technology UAEU, Al Ain, UAE [email protected]; [email protected] such utilization requires long hours of repetitive, highly focused, and costly flights that place a heavy burden and high risk on the pilots.

Abstract—Unmanned Aerial Vehicles (UAVs) are used, in addition to the military, in various civilian applications. Some UAV applications may involve multiple UAVs working and collaborating together to achieve a common goal. Developing such applications is time and effort consuming due to the heterogeneity of UAVs and the complexity of the operations involved. These UAVs are usually monitored and controlled using peer-to-peer radio frequency communications. This requires either direct links between the UAVs and the ground station, or through multiple hops between them. This approach suffers from many limitations and it forces the user(s) to be at the mission location. In addition, it restricts the mission’s area within the range of UAV communication. Overcome this issue, we propose a platform architecture that integrates the UAVs with the cloud computing paradigm, so that UAVs become as servers and part of the cloud. We modeled the UAVs in a ResourcesOriented Architecture (ROA); they provide their resources and services through the uniform interface RESTful HTTP. For distributed UAVs, we propose a broker architecture to separate the requester side from the provider side. The main purpose of this broker is to assign the requested tasks to the suitable available UAVs. The separation of responsibilities facilitates easier development of UAV applications on top of the platform.

Some UAV applications involve multiple UAVs working together to quickly achieve a specific task [3]. However, controlling and utilizing multiple UAVs that will effectively and concurrently operate and coordinate tasks for a certain problem area requires a huge number of man hours in design, development and testing [4]. This is mainly due to the lack of technologies that can be utilized to effectively coordinate the operations of multiple UAVs. Moreover, a collaborative mission usually consists of multiple tasks that are executed sequentially or concurrently by multiple UAVs to accomplish the mission. These tasks are allocated to UAVs and monitored by either a ground station [5], or autonomously [6][7]. As they need to rely on some form of Radio Frequency RF communication, UAVs applications need to establish direct links among themselves and with the ground station(s). Such links may either be single links or through multiple hops through other communication nodes that may be other UAVs nearby or some intermediate ground stations [8]. However, this peer-to-peer RF communication between ground station and UAVs is not suitable for many of the UAVs dynamic, distributed and heterogeneous operating environment.

Index Terms— UAVs, broker, cloud computing, RESTful, ROA.

I. INTRODUCTION

Our approach integrates UAVs with the Cloud Computing (CC) paradigm, so that UAVs are accessed ubiquitously as cloud resources. CC has been expanded not only for computers and mobile devices but also for embedded systems [9]. Smart objects such as sensors, actuators, and embedded devices are connected to the Internet through the Internet of Things IoT [10]. The main focus of IoT is establishing network connectivity between smart objects and the Internet. While the Web of Things (WoT) builds the application layer on top of the network [11]. Accordingly, the Web tools and protocols can be used for developing and interacting with these objects. Similarly, UAVs have embedded systems that conform to the concept of IoT and WoT, so that they can be connected to the Internet to be accessed and monitored through the Web.

UAVs are aircrafts without human pilots on board. They are controlled remotely by humans on the ground or they run autonomously using an on-board computer. A recent study estimated that in 2017, the civilian UAV market in the United States alone could reach $560 million out of a total of around $5 billion [1]. With recent advances in airframe, flight control, and communication technologies offered in UAVs, manned operations for many applications can be efficiently replaced with UAVs. UAVs have the potential to perform various important and repetitive tasks in an automated efficient manner. This is mainly due to the high accuracy, mobility, and repeatability levels [2]. UAVs can be very useful in several operations such as; agriculture for spraying pesticides or seeds; in search and rescue operations in disasters areas; for capturing large areas for security and surveillance; in environmental monitoring; for large infrastructures monitoring; and in terrain mapping applications. Such tasks require repetitive, hazardous and/or tedious tasks. Although, manned aerial vehicles can be used,

978-1-4673-7648-8/15/$31.00 ©2015 IEEE

This paper continues our previous work [12], where we proposed the general framework of collaborative UAVs through CC. The paper addresses the opportunities of integrating UAVs into the CC paradigm and discusses the challenges facing the integration efforts. In this model, a task is represented as a service provided by UAV resource. For

212

example, UAVs may have one or more sensors, actuators, cameras, and/or storage devices. Any of these are offered as a service to be accessed and requested through the web service interfaces.

of UAVs such as in Amazon Prime Air for delivering products and their use for restaurant services. These varieties of application opportunities of UAVs have attracted researchers and developers to focus on improving efficient frameworks to develop UAV applications easily especially for multiple distributed UAVs that cooperate with each other. Therefore, they have developed different architectures and communication protocols for collaborative UAVs.

In the traditional client-server architecture, the client directly requests the server. Consequently, for distributed UAVs, the client should know all of the UAVs resources and services. This scenario brings the difficulty of developing UAV applications for specific resources. Therefore, the broker architecture aims to separate responsibilities, where UAVs register their resources and services with the broker. Then the request is sent to the broker without having to define specific UAVs. As a result, integrating different services and building new applications on top of this architecture becomes easier. Moreover, adding more UAVs is as simple as plug and play by simply registering them with the broker.

B. Distributed Architecture for Collaborative UAVs In distributed collaborative UAVs, a UAV interacts with all other UAVs to find the required service provider, then interact with it to request and get the service. The service provider could be unable to provide a service such as a storage service with a certain size or it may be busy providing a service for another requester, thus it delays providing the service for a specific time. Furthermore, in case of re-planning the mission, UAVs interacts together for rescheduling. Thus it leads to high communication traffic in distributed collaboration, especially in the case of a mission with a huge number of UAVs. To find a suitable UAV for a task, all UAVs communicate to allocate tasks as specified in [5],[15] and [16].

The rest of the paper is organized as follows. Section II addresses related work, previous efforts and background. Section III presents the issues of integrating UAVs to the cloud. Section IV illustrates the client-server architecture for UAVs. Section V proposes the cloud broker architecture for collaborative UAVs within the CC paradigm. The implementation is shown in Section VI. Finally, Section VII concludes the paper.

In this approach, the mission is divided into tasks and distributed to all UAVs and each UAV chooses the suitable task for itself. Then they negotiate to ensure that all tasks are allocated to UAVs and no task assignment duplications. After that UAVs exchange messages to execute tasks in the right order.

II. RELATED WORK AND BACKGROUND In this section we discuss various examples of related work on UAV missions, UAV applications development, and efforts towards collaborative UAV applications.

When a UAV requests data or service from another UAV it sends requests to all other UAVs, then the suitable UAV that provides that service replies to the requester UAV then they exchange messages to complete the service. Another method is to broadcast information, where each UAV broadcast its services and status to other UAVs such that the requester only sends the request to the provider UAV rather that broadcasting the request [17].

A. UAV Missions There are many applications for collaborative UAVs such as the example in [13], where UAVs are used for rescue operations. UAVs are also used for environmental monitoring such as collecting data on air quality in different layers of the atmosphere as some information cannot be collected by ground systems due to gasses or smoke from the fires. The main mission of the UAVs is to measure pollution and locate its sources in certain areas. The swarm intelligence based strategy can be used as it uses a completely distributed approach.

C. Previous Efforts Toward Collaborative UAVs Middleware Collaborative UAVs can be homogeneous or heterogeneous in their communication, acting, sensing, storage, and processing capabilities as well as their energy levels. While applications that rely on homogeneous UAVs are easier to develop, heterogeneous UAVs can offer great opportunities for providing cost-effective solutions for complex applications that require different capabilities for the various tasks involved. However, developing such applications for UAVs with heterogeneous devices, different energy levels, varying storage, communication, sensing and processing capabilities is a complex task without middleware [18].

Furthermore, Chmaj and Selvaraj [3] addressed a survey about collaborative and distributed UAVs applications. They presented several applications, such as; object detection and tracking, where UAVs search and allocate a specific object then track it using a swarm of UAVs that communicate with each other. Surveillance is one of the most famous applications in UAVs, where multiple UAVs are distributed to cover a large area to monitor. Another important application is data collection through Wireless Sensor Network (WSN). This includes ground sensors as well as UAVs sensors. Then, the collected data is sent to the ground station to be monitored and analyzed. Environmental monitoring has gained high interest in UAV applications. It focuses on forest fire, pollution detection and monitoring as well as storms.

Distributed UAV applications development, deployment, operations, and management are generally very complex tasks. However, Service-Oriented Architecture (SOA) can be used to reduce the complexity [19]. The Video Exploitation Tools in [20] is an example of SOA application for UAVs. SOA allows viewing different UAV functions as services. For example, the sensing that is considered as one of the most important functions of UAVs can be viewed as a service.

Mohammed et al. [14] referred to UAV applications for smart cities. They addressed safety applications such as traffic and crowd management as well as urban security especially for big public events. They also discussed the business application

213

Earlier, de Freitas et al. [21] studied the UAV sensing network specifically for surveillance applications through middleware. In surveillance applications, UAVs cooperate with ground nodes to cover the surveillance area. de Freitas et al. focused on providing an intelligent communication between a) UAVs and ground station, b) UAVs and ground nodes and c) among each other, taking into account the limited resources and capabilities of them. First, de Freitas et al. proposed braking down the mission into a set of sub-missions that can be allocated to individual nodes. These sub-missions run over the middleware. This paper detailed the three components and layers of the middleware, beginning with the bottom layer, Infrastructure layer, in which all hardware and resources are managed by the operating system. Then, the Common service layer, that are common in different applications, regardless of the mission such as networking management. Finally, the top layer, the Domain-services layer, to support application services according the domain, nevertheless, it can be reused among different applications. A minimal set of middleware services was installed in UAVs and nodes called kernel to perform the basic services that support UAVs. Simulation results were provided to measure the efficiency of the proposed middleware. The simulation shows the distribution of nodes and the selected ones for mission. The simulation demonstrated the number of engaged nodes regardless the discovery method and how to integrate them. In sum, no clear selection based or allocation approach.

designed for UAVs. This model differs from traditional networks, Mobile Ad-hoc Networks (MANETs) and Vehicular Ad-hoc Networks (VANETs) in terms of connectivity and routing capabilities. UAVs can be considered to be modeled as Flying Ad Hoc Networks (FANET), however the main challenge issue facing FANET is routing as the network topology changes dynamically and rapidly. UAV communications can be either UAV-to-UAV communication where UAVs communicate with each other or UAV-toInfrastructure communication where UAVs communicate with fixed infrastructure locations such as ground stations. MANET uses mobile nodes in random network topology that changes rapidly; therefore, it can be used in UAV FANET to make routing easier and to improve the performance of wireless communication systems. To increase FANET communication performance we need to decrease transmission power by communicating with the closer UAVs. As a result, MANET routing mechanisms are preferred in FANET but they are not directly applicable. Peer-to-peer communication and radio frequency transmission suffers from many limitations such as restricted range of communication and difficulty programing and developing new applications depending of the UAV's language and commands. In addition, this approach does not support the heterogeneity of UAVs, where each UAV could have a different operating system and different command syntax and interfaces. It restricts the location of the ground station to the mission's location and requires UAVs to be in direct line of sight of the ground station to maintain communication and control. In addition, the control and monitoring of UAV applications become more complicated and limited to specific devices that UAVs are connected to.

The SOA model proposed in Mohamed’s work [15] is based on the concept that every UAV has a global view of all other UAVs. However, this concept has a poor scalability. As a result, Mohamed et al. discussed having a broker service in each UAV to maintain the information about other UAVs regarding their services, capabilities, location, power level and other details. Then UAVs exchange their information by advertising and requests. Advertising is broadcasting the services of the UAV to others. Requests are invocations from the consumer to the provider to get a specific service. Mohamed et al. categorized invocation services into synchronous service and asynchronous service. The former maintains an active connection between the requester and provider till the provider returns a result. While the later, the connection may be terminated after the request is sent, then another connection is established when the provider responds back, which is more efficient in unreliable connectivity. Finally, the Service-Oriented Middleware (SOM) services are integrated to develop collaborative services and applications to be reused without the need to implement it from scratch for every application.

As a result, we proposed Cloud Computing architecture to communicate with different UAVs. That is a ResourceOriented Architecture. In a UAVs environment, UAVs do not only provide services but also resources information such as the UAV's location and energy levels. This facilitates the monitoring task of multiple UAVs at the same time. B. UAV Resources and Services One of the concerns of integrating UAVs to the cloud is the connectivity. Most UAVs support Wi-Fi connection, therefore it can be used to connect to the internet. In addition, recently, the 3G/4G technology supports not only mobile devices but also embedded systems using external shields connected to the embedded system. By this connection, the UAV gets a unique IP address, so that it has a unique identification over the internet. The assumption of the connection availability is valid in many application fields such as smart cities. However, considering satellite connectivity opens broader application fields.

Based on our knowledge, there is no matured cloud computing architecture for distributed UAVs that utilize the web technology to develop services and applications through the cloud.

The IoT studies the connectivity of smart objects and providing them with addresses as well as applying the IPv6 for them. Integrating UAVs with the Cloud means that the UAV and its resources become available in the Internet to be accessed in a ubiquitous manner to a client user. The client could either be a human using web browsers and applications, a UAV accessing another one's resources or any embedded devices that use the same protocol. Therefore, the most

III. INTEGRATING UAVS TO CLOUD COMPUTING A. Radio Frequency Communication Limitations One of the main technical requirements of collaborative UAVs is the availability of communication facilities among them. A lot of research has been done on traditional radio communication. In [22], an Ad-hoc Network model was

214

important step is to identify the resources and services that should be made available to the clients.

more bandwidth and considered more complicated. Similarly, Guinard et al. [25], compared the two approaches (the standard WS* web services and the RESTful web services) for the WoT. They found that the SOAP architecture is a complicated approach. Although it is suitable for digital services with emphasis on business architecture, it is not suitable for the physical world. In addition, it requires high computing power, bandwidth and storage. On the other hand, the RESTful architecture is a reusable, loosely coupled set of web services, and easier to learn and use. Furthermore, the authors recommended the use of the RESTful web service for the WoT rather than the standard WS* web server unless the application has advanced security and quality of service requirements. Similarly, UAVs provide not only services but also data such as UAV status or the resource information. Moreover, due to the limited capabilities and resources of UAVs such as energy level and processing, a simple lightweight web service architecture such as RESTful is more suitable than the heavyweight complex web service like the WS*. As a result, ROA is more applicable for UAVs than SOA. RESTful is the implementation of ROA.

UAVs define their resources and services that vary from one to another due to the heterogeneity of UAVs. However, each UAV should have uniform interfaces to enable the client to: x

Monitor the UAV itself. This involves monitoring the UAV's status (i.e. whether it is idle or on a mission), the current status of the UAV's storage, the UAV's flight conditions, the direction and orientation of the UAV, the UAV's speed, the energy level and the current position coordinates; altitude, the latitude and longitude values.

x

Access the UAV resources. This usually involves issuing requests to collect some information such as sensors readings (e.g. temperature, pressure, or humidity sensors), radar data, camera images or videos, thermal camera images, and time of day information. Services offering this type of information may require some input such as specifying the time, location or size of data requested. Other services may also generate some form of action by the UAV or the devices onboard. For example, a client request may require the UAV to change flight direction, speed, or altitude, request some pictures or video to be taken, activate certain devices such as sprayers, or some sensors, or activate certain activities onboard the UAV. These services usually require some parameters such as what to do, when, how long, or where.

x

D. RESTful for Resource-Oriented-Architecture The central concept of REST [26] is that the resources are any component that worth being uniquely identified and linked to. REST is described as:

Monitor the UAV resources' status. This involves keeping track of the different resources onboard such as finding out if a certain resource is available, currently in use or damaged. Another example is determining the remaining amount of fuel during the mission.

C. Web Service Architectures UAV cloud are modeled as request/respond architecture as web services. There are different architectures for web services on the Cloud. First, in the standardized WS* web service architecture, the client requests and the service response objects are encapsulated using Simple Object Access Protocol (SOAP) and transmitted over the network using XML. Second, the Representational state transfer (RESTful) architecture is a web service architecture that identifies resources through a uniform interface using Uniform Resource Identifiers (URI) and Hypertext Transfer Protocol (HTTP) service interface. The resources are represented in different media types, such as Hyper Text Markup Language (HTML) and JavaScript Object Notation (JSON).

x

Resource identification: that is the Uniform Resource Identifier (URI) to identify the resource of each UAV.

x

Uniform interface: resources are available for interaction through uniform interfaces with wellidentified interaction semantic which is HTTP. HTTP has a set of operations that are GET, POST, PUT and DELETE to optimize interactions with the resources.

x

Self-describing message: the representation massage along with the HTTP interactions. The client and server exchanges messages in an agreed format. In machine oriented services, there are two media types supported by HTTP; XML and JSON. JSON format has gained widespread support for embedded systems due to its readability for both human and machine, lightweight and the direct parsing to JavaScript compared to XML.

x

Stateless Interactions: that is the server doesn't hold previous interaction information that affects the followed requests. Therefore, each request contains all the information required to serve that request. The request information is contained in the HTTP using Self-describing message by the JSON object. IV. COLLABORATIVE UAVS AS PART OF THE CLOUD

Integrating UAVs with the Cloud makes the UAVs part of the Cloud. UAVs can then be accessed through web services. ROA is a client-server architecture, where the UAV is the back-end server that provides its resources, while the front-end is the requester (client side) of application. In ROA this is implemented using RESTful HTTP requests (see Figure 1.)

In [23] a comparison between distributed architecture is discussed for SOA, ROA and Object Oriented Architecture. The author concluded that the applicability of architecture depends on the application scenario and the system. Then, a comparative study was done for mobile host [24]. In this scenario, the author illustrated the preferences of REST architecture due to its loosely coupled, flexibility and lightweight compared to the SOAP architecture that consumes

215

A. UAVs Back-End The UAV is the back-end server that provides its services and resources to clients. The UAVs’ services can be developed in different languages that support RESTful web services such as NodeJS, Ruby and rails, python or PHP. The variety of programming languages that develop a uniform protocol facilitates the development of heterogeneous systems to collaborate easily.

{“id: 2, “name”: “temperature”, “status”: “available”, “value”:30} B. Front-end Application The client application is a lightweight user interface to request a mission on a browser. It can be written in JavaScript, HTML5 or Java. The front-end application allows the client to establish a UAV mission. This application is deployed to connect to the Cloud having a user friendly interface that is designed mainly for web browsers. This interface provides users with the ability to easily monitor the mission (see Figure 2.)

For the UAVs back-end development, first, it is necessary to identify the resources’ URIs for the UAVs. A URI is expressive and presents its meaning for human interpretation. Then, we represent the UAV’s information as a JSON object that could be easily parsed into JavaScript and be readable for humans. The received JSON message can then be presented in the browser for the user in an HTML file. For example, each UAV is given a unique identifier and a name. Then it holds its current parameters such as energy level, location coordinates and operational status. Moreover, each UAV identifies its resource representation including the ID, name, status, value, and requester. Requesting the UAV’s URI using GET: http://.../UAV Returns the following response:

Figure 1. ROA for integrating UAVs to the cloud.

HTTP/1.1 200 OK

V. CLOUD BROKER ARCHITECTURE FOR COLLABORATIVE UAVS

Content-Type: application/json

One of the considerations in integrating UAVs to cloud computing is the distribution of UAVs and being scalable to offer their services and resources through APIs to multiple clients. Although, ROA is client-service architecture, the RESTful implementation supports the loosely coupled, usability and flexibility service. Therefore, these properties facilitate cooperating these resources and services using broker architecture.

{“id” : 1, “Name” : “uav1”, “services” : [“camera”, “temperature”], “energy level” : 85, “status” : “available”, “orientation”: 61.5 , “location”: [{“latitude”: 36.872, “longitude” : 140.0704, “altitude” : 260}]} Similarly, requesting a GET to a resource URI; http://.../UAV/services/ temperature

A broker is a middle agent that receives advertisements from service providers regarding their capabilities and provision of services. After that, a requester sends a request to the broker specifying the service needed and its parameters. Then the broker compares the requested against all advertisements available and determines the provider whose capabilities best match the request. The broker contacts the provider and requests the service. If the provider accepts the request for the service, it performs the service and returns the result to the broker. Next, the broker returns the result to the requester [27].

Returns a JSON object of the temperature resource under the services resource of UAV; HTTP/1.1 200 OK Content-Type: application/json {“id:2, “name”: “temperature”, “status”: ”available”, “value”: 28.5} Requesting a service requires a header and body of the POST request. For example, requesting the temperature sensor for specific location using POST:

The development of collaborative UAVs architectures implies the development of three main decision making abilities: mission planning, task allocation, and coordinated task achievement.

http://.../UAV/services/ temperature with the JSON body of the request is defined as:

As we proposed in our previous work [12], the user applies for a mission using Software as a Service (SaaS) that is the front-end application through the cloud. Then the next layer, in the Platform as a Service (PaaS), the mission organization service analyzes and plans the mission into sequences of tasks according to the required services. It constructs a description of services flow and sends it to the next layer, the broker layer. This layer is responsible for registering then discovering and

{“location”: [{“latitude”: 12.8145, “longitude”:45.64827, “altitude”: 87.91}]} Returns the JSON object with the new values: HTTP/1.1 200 OK Content-Type: application/json

216

allocating tasks to the suitable UAVs according to the required services.

UAVs register themselves to the broker using a RESTful HTTP request of the broker for registering including the UAV information such as the POST method in the following HTTP:

A. Database for UAVs UAVs reserve their information internally in their storage. However, UAVs have limited storages and processing capabilities. Therefore, a database could be used to store the information and services of each UAV as well as a log track of UAVs identified by timestamps.

http://mybroker.com/UAV/register

Figure 3. A client-server web architecture with broker web service.

and the JSON body of the request is defined as: {"name" : "uav1", "services" : ["camera", "temperature"], "energy level" : 85, "status" : "available", "orientation": 61.5 , "location": [{"latitude": 36.872, "longitude" : 140.0704, "altitude" : 260}]}

Figure 2. A user friendly interface on browser of the client application for monitoring two UAVs.

The broker returns the following response to that UAV: HTTP/1.1 200 OK

This database is useful for fetching UAVs’ services and resources as well as recording the log data and mission information. Furthermore, it simplifies monitoring the status and changes about UAVs through the mission time-line to be retrieved later on.

Content-Type: application/json {"id": 1} This indicates that the UAV is registered and added to the database with an id =1.

B. Broker Web service The broker is a web service that is responsible for storing and retrieves UAVs’ information in/from the database. The broker web service manages the process of collaborative UAVs including task allocations and monitoring executions. Therefore, the UAV back-end and the application front-end do not have direct connections to request a service or to retrieve resource information. This process is done through broker web service, as shown in Figure 3.

After all UAVs are registered and recorded in the database, the broker is able to allocate a specific task to a suitable available UAV. Moreover, the client application monitors and tracks the process through the broker service. The broker receives a request of a resource or a service from the user application or from another UAV. In this scenario, the broker fetches the database for the UAVs who had registered that service. Then the broker requests these UAVs to check their availability, energy and locations. When the broker gets the information of these UAVs, it calculates the distance between the current location and the specified requested location. After that, the broker requests the nearest UAV with applicable energy level to perform the service. Consequently, the requested UAV perform the service and return the results to the broker which accordingly returns that information to the requester. These information and log data are stored on the database by the broker.

For the collaborative mission, the broker performs the following: x

UAVs register their information and services to the UAV broker. This information will be added to the database.

x

The broker receives a resource or service request along with parameters if applicable.

x

The broker discovers the suitable UAV from the database for a certain task.

x

It requests the discovered UAVs using the uniform interface giving the suitable parameters.

x

Then the broker may change the status of that UAV in the database according to the request type.

x

The broker manages the order of execution and accumulates the results.

During the mission, UAVs updates their information to the broker. There are two designs for updating the information of UAVs: the comet model and the AJAX model [28]: 1) Comet model: The broker requests a resource with an event or threshold value. Then, the UAV pushes the data to the broker when those events occur. It could either be a resource value or the UAV state.

217

includes a table for UAVs information, a second table for UAVs services and a third table for requests log.

In this scenario, the UAV requests the broker giving the new values in JSON body message. This model is suitable for monitoring different UAVs; they request the update when a specific event occurs. Also, this model is suitable for returning the result or notifying the requester at the end of a task that takes time such as spraying an area.

Then we built a broker service using the NodeJS platform8 in the JavaScript language. The broker was connected to the database using its configurations parameters to read and write different values. RESTful APIs were built for the broker to allow users to request the needed services or resources. One example of these requests is,

2) AJAX model: Asynchronous JavaScript and XML (Ajax) has proven to be a good way of transferring some of the UAV server workload to the broker side. In this model, the broker pulls data from UAVs. For example, getting the current location of a UAV or requesting a task from it.

Get http://mybroker.com/service/tempereture The “temperature” was taken as a value in which it will be fetched in the database to get the list of possible providers. The provider with the highest energy level will be initially selected to provide the service. After that, the broker requests the service of that provider using its URI and gets the response value. The broker was tested using the Postman service to send requests to the broker without specifying a specific UAV. The broker provides the separating of responsibilities such that the integration of services is built on top of the broker rather than being among the UAVs themselves.

VI. IMPLEMENTATION The proposed model was tested by implementing different resources and providing RESTful APIs to them. Then the broker service was implemented and connected to a database. First of all, the UAV was built as shown in Figure 4. We used the Arduino1 board as a UAV that is the main on-board device, and then sensors were connected to the Arduino such as DHT112 sensor for temperature and humidity, ultrasonic and light sensor. In addition, a led was used to represent an actuator. Then, for internet connectivity, the Adafruit CC30003 was used to connect the Arduino to the Internet and get an IP address.

VII. CONCLUSION AND FUTURE WORK In this paper, we proposed a different way of monitoring and accessing UAVs resources and services using the CC Paradigm. To facilitate this approach we proposed and described a broker web server to manage the processes required for collaborative UAV applications. Traditional peer-to-peer RF communication showed numerous limitations and restrictions. The user location has to be within the mission area. Moreover, it restricts UAVs to be in a nearby area to be in a line of communication with the ground station. This is unsuitable for the dynamic UAVs environments where UAVs have to spread across large areas and may not have a direct line of communication with the ground station or among themselves. Therefore we proposed integrating UAVs with the Cloud. In this model, we consider UAVs to be the web server part of the cloud to gain the benefit of the ubiquity of cloud computing as well as facilitating the use of web tools to develop collaborative UAV applications.

The Arduino was developed using the Arduino software4 in the C language with the Adafruit CC3000 library5 to read the request. Each resource was implemented with a RESTful API.

RESTful is a lightweight, reusable and loosely coupled web service. It is more suitable for UAV limited resources compared to the standardized heavyweight and complex WS* web services. Therefore, we designed the UAVs using ROA implemented in RESTful web services to offer their resources and services using uniform interfaces.

These resources and services where tested by requesting them using Postman Chrome extension6. After that, database tables were implemented in PostgreSQL database7. The database

The proposed architecture was initially implemented to show the separating responsibilities and facilitates building applications and integrating services on top of it.

Figure 4. Arduino board with DHT sensor, led and Adafruito CC3000 board representing a UAV and resources.

Due to the loosely coupled services and to gain the benefit of separating responsibilities, we proposed a broker architecture which is a web service on the cloud. The broker is connected to a database that holds the information about the registered UAVs and their resources, so that the user

1

http://www.arduino.cc/ 2 https://github.com/adafruit/DHT-sensor-library 3 https://www.adafruit.com/products/1469 4 http://arduino.cc/en/main/software 5 https://github.com/adafruit/Adafruit_CC3000_Library 6 https://www.getpostman.com/docs/requests 7 http://www.postgresql.org/

8

218

https://nodejs.org/

application is built upon it to request and monitor the process of the mission.

[13]

This architecture opens the ability for application to integrate not only UAVs but also ground nodes that uses the same protocol. Therefore, the application combines multiple resources. In addition, another layer is required to decompose the user mission into set of tasks to be requested to the broker.

[14]

This architecture does not specify the controlling aspects of flight path. We assumed that the resource specifies the destination location to provide the service regardless the path plan of the flight.

[15]

ACKNOWLEDGMENT

[16]

This work is supported in part by UAEU-NRF Research grant number 3IT045. REFERENCES [1] [2]

[3] [4] [5]

[6]

[7]

[8]

[9] [10]

[11] [12]

[17]

B. Wagner, “Civilian market for unmanned aircraft struggles to take flight,” Natl. Def. Mag., 2007. G. M. Saggiani and B. Teodorani, “Rotary wing UAV potential applications: an analytical study through a matrix method,” Aircr. Eng. Aerosp. Technol., vol. 76, no. 1, pp. 6– 14, 2004. G. Chmaj and H. Selvaraj, “Distributed processing applications for UAV/drones: a survey,” in Progress in Systems Engineering, Springer, 2015, pp. 449–454. W. L. Teacy, J. Nie, S. McClean, G. Parr, S. Hailes, S. Julier, N. Trigoni, and S. Cameron, “Collaborative sensing by unmanned aerial vehicles,” 2009. A. Ryan, J. Tisdale, M. Godwin, D. Coatta, D. Nguyen, S. Spry, R. Sengupta, and J. K. Hedrick, “Decentralized control of unmanned aerial vehicle collaborative sensing missions,” in American Control Conference, 2007. ACC’07, 2007, pp. 4672–4677. N. Mohamed and J. Al-Jaroodi, “Service-oriented middleware for collaborative UAVs,” in Information Reuse and Integration (IRI), 2013 IEEE 14th International Conference on, 2013, pp. 185–192. A. Ryan, X. Xiao, S. Rathinam, J. Tisdale, M. Zennaro, D. Caveney, R. Sengupta, and J. K. Hedrick, “A modular software infrastructure for distributed control of collaborating UAVs,” in Proceedings of the AIAA Conference on Guidance, Navigation, and Control, Keystone, CO, 2006. O. K. Sahingoz, “Mobile networking with UAVs: opportunities and challenges,” in Unmanned Aircraft Systems (ICUAS), 2013 International Conference on, 2013, pp. 933– 941. P. Mell and T. Grance, “The NIST definition of cloud computing,” 2011. J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami, “Internet of Things (IoT): A vision, architectural elements, and future directions,” Future Gener. Comput. Syst., vol. 29, no. 7, pp. 1645–1660, 2013. D. Zeng, S. Guo, and Z. Cheng, “The web of things: A survey,” J. Commun., vol. 6, no. 6, pp. 424–438, 2011. S. Mahmoud and N. Mohamed, “Collaborative UAVs Cloud,” in Unmanned Aircraft Systems (ICUAS), 2014 International Conference on, 2014, pp. 365–373.

[18]

[19] [20]

[21]

[22]

[23] [24] [25]

[26] [27] [28]

219

G. Varela, P. Caamamo, F. Orjales, A. Deibe, F. López-Peña, and R. J. Duro, “Swarm intelligence based approach for real time UAV team coordination in search operations,” in Nature and Biologically Inspired Computing (NaBIC), 2011 Third World Congress on, 2011, pp. 365–370. F. Mohammed, A. Idries, N. Mohamed, J. Al-Jaroodi, and I. Jawhar, “UAVs for smart cities: Opportunities and challenges,” in Unmanned Aircraft Systems (ICUAS), 2014 International Conference on, 2014, pp. 267–273. N. Mohamed, J. Al-Jaroodi, I. Jawhar, and S. LazarovaMolnar, “Middleware requirements for collaborative unmanned aerial vehicles,” in Unmanned Aircraft Systems (ICUAS), 2013 International Conference on, 2013, pp. 1051– 1060. T. Lemaire, R. Alami, and S. Lacroix, “A distributed tasks allocation scheme in multi-UAV context,” in Robotics and Automation, 2004. Proceedings. ICRA’04. 2004 IEEE International Conference on, 2004, vol. 4, pp. 3622–3627. N. Mohamed, J. Al-Jaroodi, I. Jawhar, and S. LazarovaMolnar, “A service-oriented middleware for building collaborative UAVs,” J. Intell. Robot. Syst., vol. 74, no. 1–2, pp. 309–321, 2014. S. Hadim, J. Al-Jaroodi, and N. Mohamed, “Middleware issues and approaches for mobile ad hoc networks,” in The IEEE Consumer Communications and Networking Conf.(CCNC 2006), 2006, pp. 431–436. Q. Zhang, L. Cheng, and R. Boutaba, “Cloud computing: state-of-the-art and research challenges,” J. Internet Serv. Appl., vol. 1, no. 1, pp. 7–18, 2010. S. Se, C. Nadeau, and S. Wood, “Automated UAV-based video exploitation using service oriented architecture framework,” in SPIE Defense, Security, and Sensing, 2011, p. 80200Y–80200Y. E. P. de Freitas, A. M. Ferreia, C. E. Pereira, and T. Larsson, “Middleware support in unmanned aerial vehicles and wireless sensor networks for surveillance applications,” in Intelligent Distributed Computing III, Springer, 2009, pp. 289–296. O. K. Sahingoz, “Mobile networking with UAVs: opportunities and challenges,” in Unmanned Aircraft Systems (ICUAS), 2013 International Conference on, 2013, pp. 933– 941. J. Thelin, “A comparison of service-oriented, resourceoriented, and object-oriented architecture styles,” in OMG Workshop, Munich, Germany, 2003. K. Wagh and R. Thool, “A comparative study of soap vs rest web services provisioning techniques for mobile host,” J. Inf. Eng. Appl., vol. 2, no. 5, pp. 12–16, 2012. D. Guinard, V. Trifa, T. Pham, and O. Liechti, “Towards physical mashups in the web of things,” in Networked Sensing Systems (INSS), 2009 Sixth International Conference on, 2009, pp. 1–4. A. Rodriguez, “Restful web services: The basics,” IBM Dev., 2008. M. Fasli, Agent technology for e-commerce. John Wiley & Sons Chichester, 2007. S. Duquennoy, G. Grimaud, and J.-J. Vandewalle, “The Web of Things: interconnecting devices with high usability and performance,” in Embedded Software and Systems, 2009. ICESS’09. International Conference on, 2009, pp. 323–330.