Linköpings universitet SE–581 83 Linköping
Linköping University | Department of Computer and Information Science
Master’s thesis, 30 ECTS | Datateknik
2019 | LIU-IDA/LITH-EX-A--19/067--SE
Cloud Services for Building the
Modern Internet of Things
–
An Examination of IoT Cloud Service Providers
Alexander Sääf
Supervisor : Jonas Wallgren Examiner : Christer Bäckström
Upphovsrätt
Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publicer-ingsdatum under förutsättning att inga extraordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka ko-pior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervis-ning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säker-heten och tillgängligsäker-heten finns lösningar av teknisk och administrativ art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-nens litterära eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.
The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.
According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.
For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
Abstract
As the Internet of Things (IoT) has grown in popularity, modern Cloud Providers have begun offering IoT-specific features. These features could provide IoT developers with a lot of aid, but they are new and relatively unexplored. This study aimed to explore these IoT-specific features in order to build a better foundation for developers looking to leverage them to improve their IoT systems or development process. To do this, a literature study combined with a case study was carried out. The literature study gives insight into the current research around IoT and IoT cloud providers, for example with common issues and possible applications. The case study provides a reference implementation of how a simple proof-of-concept system can be developed using two of the available providers: AWS IoT and Azure IoT.
Acknowledgments
I would like to thank my examiner Christer Bäckström and supervisor Jonas Wallgren for the help and feedback throughout the thesis work. I would also like to thank Pär Wieslander for help and advice on the implementation built and in decisions along the way, as well as Attentec for making this thesis possible, even when our first idea didn’t work out.
Lastly, I would also like to thank my family, friends, and girlfriend for all the support through-out the thesis work. It has meant more than you might think.
Contents
Abstract iii
Acknowledgments iv
Contents v
List of Figures vii
Acronyms viii 1 Introduction 1 1.1 Background . . . 2 1.2 Aim . . . 2 1.3 Research questions . . . 2 1.4 Delimitations . . . 2 2 Theory 3 2.1 Internet of Things . . . 3 2.2 Cloud computing . . . 4 2.3 MQTT . . . 4 2.4 REST-API . . . 4
2.5 Amazon AWS IoT . . . 5
2.6 Azure IoT . . . 5 3 Method 6 3.1 Literature study . . . 6 3.2 Implementation . . . 7 4 Results 9 4.1 Literature study . . . 9 4.1.1 IoT . . . 9
4.1.2 IoT Cloud Services . . . 11
4.2 Specification of example system . . . 12
4.3 Implementation of example system . . . 13
4.3.1 Shared parts . . . 13 4.3.2 AWS IoT . . . 15 4.3.3 Azure IoT . . . 18 4.3.4 Experiences . . . 21 5 Discussion 23 5.1 Results . . . 23 5.2 Method . . . 24
5.4 Future work . . . 26
6 Conclusion 27
List of Figures
4.1 Typical IoT Architecture . . . 10
4.2 Example system . . . 13
4.3 The visualization page . . . 15
4.4 Architecture of the system developed with AWS IoT . . . 16
Acronyms
AMQP Advanced Message Queuing Protocol.
BLOB Binary Large Object.
MQTT Message Queue Telemetry Transport.
REST Representational State Transfer.
1
Introduction
The Internet of Things (IoT) allows us to connect people and devices in a completely new way, as it enables connections between physical devices and virtual applications, allowing for transfer of data from the real world to the virtual world [16]. Its biggest strength is that it has the potential to affect our lives in such a variety of ways. It has interesting uses for both private and business users, ranging from e-health and enhanced learning to industrial manufacturing and logistics [2]. The importance of IoT was even recognized by the National Intelligence Council as it was part of their list of "Disruptive Civil Technologies" [6]. They believed that the combination of technological advances and demand would drive the de-velopment forward, and that by the year 2025, common items such as for example furniture, could have become connected to the internet. This will lead to a huge amount of connected devices, and Ericsson predicts that by 2022 there will be around 18 billion connected devices related to the IoT [9].
Another interesting area which has grown is cloud computing, which allows users to reach applications through the cloud as a service, instead of running the applications on their own machines [5]. Cloud computing has also allowed developers who previously could not afford the infrastructure and expense to operate it to actually develop their systems, as they no longer need to pay up front [1]. Cloud computing has enabled the ability to scale systems to demand, meaning that resources do not need to be allocated when they are not being used. As cloud computing is suitable for IoT, cloud providers have started offering IoT-specific features [20]. Examples of providers that provide such features are Amazon, Microsoft, and Google.
Being able to leverage these services to build better and cheaper solutions could be very beneficial, but it also requires knowledge about the services. What do they offer? What is required of the developer? What are the drawbacks, risks, and costs? As there are a large number of providers available, choosing which one to use is also not trivial. It suddenly be-comes important to not only have knowledge about the IoT itself, but also about the services which can be used to run it. This thesis will take a deeper look at these cloud services in order to build knowledge and gather experience surrounding them.
1. INTRODUCTION
1.1
Background
Attentec is a IT consulting company based in Linköping, Sweden. Its main areas of expertise are streaming media and the IoT. In its IoT work, it has commonly used cloud providers to host their solutions. However, Attentec has never used the IoT-specific features of these cloud providers, and is interested in finding out if using these can improve its solutions or decrease the time required to develop them. The cloud providers which Attentecs customers most commonly wish to work with is Amazon (AWS) and Azure. Therefore, the IoT-specific features of these two providers are of extra interest.
1.2
Aim
The aim of this study is to explore and investigate IoT cloud platforms in two ways. First, the study aims to explore the area in a broad way, by examining the research available surround-ing IoT cloud platforms. The goal of this is to build a general understandsurround-ing of the area. Second, the study will attempt to examine how systems are actually developed using IoT cloud platforms, in particular two platforms of particular interest, AWS IoT [14] and Azure IoT [17]. This will be done by developing an example IoT system in the two platforms, and drawing experiences from this process.
1.3
Research questions
As the thesis is split into two parts, the research questions naturally have different focuses. The first is related to the literature study, while the second is centered around the exploratory implementation part of the project, where a simple application is developed.
1. What does the current research say about the IoT and Cloud IoT Providers in terms of architecture, functionality, applications and common challenges?
2. How can a simple IoT proof-of-concept system be developed by using the Cloud IoT providers AWS IoT and Azure IoT?
1.4
Delimitations
The proof-of-concept system is developed in two cloud IoT platform s, AWS IoT and Azure IoT, while other IoT platforms are only considered through literature review. This decision was taken to keep the size of the work manageable, and the selection of platforms was made according to the interest of Attentec and their customers. The implementation part also looks at a small example of an IoT system, not a full IoT system, in order to keep the work reason-able in size. One alternative considered was to attempt to port an actual project into the cloud platforms, but this was deemed to be too large in scope.
2
Theory
This chapter will introduce relevant background knowledge necessary to understand the rest of the report. This includes an introduction to the Internet of Things and Cloud Computing, as well as a description of AWS IoT and Azure IoT.
2.1
Internet of Things
There are many different definitions of the Internet of Things around. This is something that Atzori et al. note in their survey of the IoT [2] could make it difficult to understand what the IoT actually is. They believe that one reason for this confusion is that there are different perspectives on IoT, depending on the background of the stakeholder, and they identify three such perspectives on the IoT. The two most obvious perspectives are Things oriented and Internet oriented. Things oriented visions focus on the things that are to be connected, and are often concerned with e.g. sensors and RFID tags. Internet oriented visions are more focused on the networks used to connect all these things and handle communication between them all. The third perspective, the Semantic oriented, relates to the issue of having such a huge, world-wide network where a large number of unique types of objects are connected. Such a network requires smart solutions to handle for example representation of things and unique addressing of such things.
Atzori et al. examined different definitions of IoT, specifically their similarities, in an at-tempt to find a common ground [3]. They identified a number of features that appeared in many of the definitions. These features included for example a focus on everyday objects, the requirement of a global network infrastructure and heterogeneity of technologies involved. However, if all these features were to be seen as requirements for a system to qualify as IoT, many of the systems today considered IoT systems would not qualify. The researchers sug-gest that IoT should instead be viewed as a conceptual framework, with a looser definition. They define it as:
a conceptual framework that leverages on the availability of heterogeneous devices and interconnection solutions, as well as augmented physical objects providing a shared infor-mation base on global scale, to support the design of applications involving at the same virtual level both people and representations of objects.
2. THEORY
This definition is very broad and will thus hopefully cover many of the systems considered to be IoT systems. It embraces the fact that IoT is not actually a new technology, but instead a use of existing technologies in a new way. It is also very open to the fields of application of IoT, meaning that different areas of use are still covered by the definition.
There are many possible applications for the IoT, in different areas, both personal and industrial. One such area is smart buildings, where IoT solutions can be used to improve the efficiency of buildings by for example regulating heating better or turning off unused lighting [18]. Another area where IoT could be used is agriculture, where a network of sensors collecting different data could help farmers increase their productivity by giving them a better view on the state of their farm [16]. IoT can also be used to improve automation in industrial plants by for example monitoring health data of industry robots, automatically shutting down robots that are showing dangerous values and notifying staff of the incident. Connecting the entire plant will also allow managers to get a much more detailed view of the plant, helping them plan and improve production [2].
2.2
Cloud computing
The Cloud promises to allow users to access their applications from anywhere in the world [5]. This means a shift of development focus. Instead of developing applications that run on the user’s computer, developers must now build services that can handle a large amount of users connecting to them. Today, there are clouds available to use by anyone, typically with a pay-as-you-go payment model [1]. The users of these clouds are usually SaaS (Software as a service) providers who in turn provide applications to their users. For these SaaS providers, making use of a cloud service helps in several ways. It means that they do not need to buy a large set of servers and infrastructure to get going. In addition, they get what seems to be infinite resources, allowing their applications to handle fluctuating loads.
2.3
MQTT
Message Queue Telemetry Transport (MQTT), is a lightweight communication protocol which is commonly used in IoT [15]. A big reason why it is so suited to IoT is that it is a publish/subscribe protocol, meaning that the devices do not need to request updates or respond to requests. This saves on network traffic, computational resources, and battery con-sumption. When a client wants to publish something, that message is sent to a server which then distributes that message to clients who have subscribed to the topic of the message.
2.4
REST-API
An API is considered a REST-API if it fulfills the five required principles of the Representa-tional State Transfer (REST) architectural style, originally described by Fielding [10]. These principles are:
• Client-Server - In order to improve portability and scalability, UI and data storage con-cerns should be separated.
• Stateless - The server should not store any context about the client or the session. • Cache - The server should explicitly state if the content of a response is cacheable or not. • Uniform interface - The interface between components should be uniform in order to
simplify the architecture.
• Layered system - The architecture should be built in layers, where each layer cannot "see" any layers other than the ones they are directly interacting with.
2.5. Amazon AWS IoT
2.5
Amazon AWS IoT
AWS, or Amazon Web Services, is a collection of cloud services offered by Amazon [12]. It promises to deliver low cost, high security and an agile and flexible platform. It delivers a number of features to its customers, including website hosting, application hosting, data storage and content delivery.
AWS IoT is a part of AWS which allows developers to connect internet-connected devices to applications running in the cloud [14]. This allows the applications to collect data and to control the connected devices. The communication between the devices and applications is handled by the AWS IoT system, for example through a MQTT Message broker which for-wards messages from the devices to the related applications. AWS IoT also allows developers to define "rules". These rules can be used to perform actions if the data in a message matches a rule. For example, this could be used to trigger an alert if a value is not within some interval. Amazon supplies Device Software Development Kit (SDK) libraries to allow developers to make their programs running on the devices connect and authenticate themselves to the cloud. They are available for different programming languages, such as C, JavaScript, and Python. These libraries enable communication with the cloud through MQTT, HTTP or WebSockets. [13]
2.6
Azure IoT
Azure IoT is Microsoft’s collection of services to connect and control IoT devices [17]. It con-tains several different services, which vary in how much control is wanted by the developers, and some of the services are built on other services. At the core of this is the IoT Hub, to which devices can connect. From the hub, devices can be monitored and controlled. Several other services build upon this hub such as for example the IoT Central, which is suitable for simple applications without high needs for customization.
In order to help with building applications for devices, Azure also provide Device SDK libraries which allow the applications to communicate with the cloud easily [17]. These li-braries support a number of programming languages, including C, Python, and C#, and they communicate with the IoT Hub through the HTTPS, Advanced Message Queuing Protocol (AMQP) or MQTT protocols. There are also SDK libraries intended for building back-end applications to interact with the IoT Hub and the connected devices.
3
Method
The method of the research was split in two parts, a literature study and the implementation of a proof-of-concept system. This chapter will outline the literature study and specify the proof-of-concept system implemented.
3.1
Literature study
The literature study was performed in a rather informal way, by performing searches on the topics identified as interesting. Research papers were selected depending on how well cited they were and what topics they discussed. In order to cover the aim and research questions of the thesis, a couple of topics were selected as particularly interesting for the literature study. The main topics identified for the search were:
• Internet of Things
In order to build a better understanding of the importance of the features that cloud services offer for the IoT, a more thorough study of the IoT was conducted. This in-cluded looking at common issues, architectures and applications, as well as looking for available and upcoming standards.
• IoT Cloud Services
Next, IoT Cloud Services and their providers themselves were studied in more detail. This search included looking at the two providers of special interest to the implemen-tation part of the study, but also other providers and services. Once again, common issues and applications of IoT Cloud Services were of interest, as well as:
– Integration: What are the challenges of combining the IoT with Cloud Computing and what are the benefits?
– Available providers/platforms: What functionality do the providers offer? How similar is the functionality of the different systems? What kinds of applications are they suited for?
These topics were used to guide the search for papers, especially the initial search. Another way of exploring the topics was to look at citations of papers found, identifying more papers
3.2. Implementation
that related to the same topic. The search was performed by using Google Scholar and the digital library of Linköping University.
3.2
Implementation
The second part of the thesis was to implement an example system in two of the IoT cloud services available, AWS IoT and Azure IoT. The first step towards doing this was to build a specification of the system to be built. This was done in collaboration with IoT experts at Attentec, with some guidance from the litterature study as well. When specifying this system, special consideration was taken to make sure that it represents common IoT systems which Attentec have previously worked with. A number of common features, or requirements, for IoT systems were identified. These were:
• Telemetry
There are a couple of things that the devices in the system need to be able to contin-uously communicate to the cloud system. The first and most basic piece of data are measurement values, accompanied by timestamps. This could be a temperature, vibra-tion or any other measured value. The devices also need to be able to send events and alarms as they occur on the device. This could be an alert stating for example: "Fridge door left open" or "Component X malfunctioning". Lastly, the device also needs to be able to send information on the current device configuration and status.
• Data visualization
The system will need to be able to visualize data from connected devices. The scope of this feature varies, ranging from simply showing a graph for one device to showing aggregated graphs for several devices, or long periods of time. This is not very specific for the IoT, but it is still an important aspect of IoT systems.
• Alerts and notifications
The system should be able to handle Alerts, either raised by the devices themselves, or raised when a measurement value passes a certain threshold. These Alerts should have different levels of severity, and administrators should be notified via email when an alert occurs.
• Device management
The system should be able to handle configuration of devices, both single devices and batches of devices. There also needs to be some kind of grouping of these devices, for example per customer or site.
• User management
The system should be able to handle different kinds of users. For example, some users should only have access to certain devices or groups of devices. There should also be a difference between administrators and regular users, in terms of for example adding and removing devices.
One important thing to note here is that these features do not include being able to control devices directly through the system. This is due to the fact that most systems that Attentec have actually worked on mainly focus on collecting, monitoring and visualizing data from devices, not controlling them. It also helps limit the size of the example system, meaning that more time can be allocated to look at each feature actually included. It was also decided that Device and User management were not as important as the other parts for the actual implementation. They were however kept in mind when developing the system, and the features available in those areas were briefly examined.
3. METHOD
These features were seen to be important regardless of the domain. For example, it does not matter if the measurement values sent from the devices are temperature values, battery percentage, or any other type of value. It also does not matter what the actual events and alerts mean, as long as their content can be customized to fit the domain. The same goes for the alerts that are raised on measurement values. As long as they can be modified, the system could fit most domains. However, in order to make the example system easier to understand, an example domain was chosen. The example system is described in section 4.2. No real devices were used, both to save time and because it does not affect the system if the values are real sensor measurements or generated values. The device components were run from a development laptop and sent randomly generated data.
This system was then implemented in AWS IoT and Azure IoT in parallel. The imple-mentation was designed with an attempt to take advantage of every shortcut available through the two systems, in order to not miss important features. Details regarding this implementation can be found in the result chapter.
4
Results
4.1
Literature study
This section presents the results of the literature study, divided into the two main areas: IoT and IoT Cloud Services. There will be some topics discussed that relates to more than one of these areas, but it will be discussed under the most relevant section.
4.1.1
IoT
There are several surveys on the IoT, and one of the most cited ones is The Internet of Things: A survey by Atzori et al. [2]. It discusses the enabling technologies for IoT, which were split into two main categories: Identification, sensing and communication technologies and Middleware. In the first category, RFID tags and sensor networks are mentioned as important components, and researchers point out that the reduction of size, weight and energy consumption will enable us to reach the vision of connecting everything. The middleware consists of all the software which runs between the devices and the IoT applications. The researchers note that the most common approach for building IoT systems is to build a Service Oriented Architecture. They also describe four typical layers of an IoT architecture. At the top of the system sits the Application Layer. This layer is responsible for exposing the system’s data and functionality to the final user in different ways. The next three layers are what are typically counted as the middleware. At the bottom is the Object Abstraction Layer, which is responsible for providing a common way to access a large number of different types of devices. Above the Object Abstraction Layer sits the Service Management Layer. This layer provides basic services, which cover the most basic interactions with the objects. At the top of the middleware is the Service Composition Layer, which allows composition of the simple services in the layer below. By composing these simple services, more complex services can be built. This layer is never concerned with devices, thanks to the two layers below which abstract it from the actual devices.
The concept of a middleware exists in many studies, although varying somewhat in def-inition and name [3, 8, 16, 19]. The architectures proposed in these papers all rely on some kind of middleware to sit between the devices and the applications of the system. Figure 4.1 shows a typical architecture for IoT, into which most of these architectures fit. There are
4. RESULTS
Figure 4.1: Typical IoT Architecture
of course exceptions, but they are mainly in what parts are named and how detailed the architectures are described. For example, the architecture suggested by Datta et al. [8] does not have an explicit device layer or network layer, but it does contain the parts that would be grouped into those layers, such as sensors, actuators, gateways and network connections. These parts also fill the same functions as in the other architectures. Patel et al. [19] suggest an architecture very similar to figure 4.1, but have named their layer corresponding to the middleware layer Service Support and Application Support Layer. The role of the layer remains the same.
The future challenges and trends of the IoT are also discussed in the research. Two such issues which are commonly discussed are security and privacy [2, 11, 16, 19]. One of the reasons why this is considered so important is that if the public is not convinced that the IoT will not harm their privacy, it will most likely be less interested in adopting the technology [2, 21]. Atzori et al. [2] note that the IoT is vulnerable in its nature. The wireless communica-tions which the IoT relies on are easy to listen in to, the devices themselves usually have very limited computing resources, and the devices are often left on their own out in the world, leaving them open to attacks. The devices’ limited resources means that they will be unable to handle any advanced security schemes.
Porambage et al. [21] note that as the IoT varies a lot, for example in what data they collect, the privacy issues also vary a lot. An example is healthcare, where IoT solutions can allow automatic collection of health data through wearable devices. As this is sensitive data, it is important that it is properly protected, and that it is clear to the patients why the data is being gathered. Another example of privacy issues in IoT is smart homes. If others are able to get access to the data gathered by smart home applications, they could use this data to learn the residents’ habits. Porambage et al. also discuss IoT privacy frameworks, identifying a number of important characteristics, such as:
• Transparency
It should always be explained to the users what, why and how data is collected, as well as who will have access to it.
4.1. Literature study
• Access Control
Users should be able to control who can access their data. • Identity, Location and Query Privacy
It should never be possible to profile users based on their identities, geographical loca-tion or the queries they make.
Standardization and interoperability are also mentioned as challenges for the future [2, 7, 16, 19]. Da et al. [7] even note that proper standards might be the key to ensuring the spread of the IoT. They also note that the standardization will help make the IoT more accessible to users and service providers. Khaan et al. [16] also note that standardization will help to improve the interoperability of objects from different manufacturers, which has previously been difficult.
Other challenges discussed are for example how to handle addressing of all the devices [2, 16], how all the data will be handled [16] and energy consumption [7, 11, 16]. Energy consumption is discussed both from the practical perspective of supplying the devices with power [11] and from the perspective of the increased amount of energy consumed by the entire network [16]. Routray and Sharmila [23] note that energy efficiency is not only an economical question, as the energy consumed by the IoT will have an important effect on the environment. They also note that there has already been a lot of work done to improve energy efficiency.
4.1.2
IoT Cloud Services
In the report A survey of IoT cloud providers, Pflanzner and Kertesz examine some of the available IoT cloud providers, such as Amazon, Azure, Google and Heroku on a very basic level [20]. They note that the competition between the providers has lead to them using different standards which are not compatible with one another. They also note that as the IoT-specific features offered by the providers are relatively new, they have not yet been explored thoroughly. The comparison looks at a couple of different basic properties of the cloud providers in order to help researchers and developers make decisions about which provider to use. Some of these properties are not specifically related to the IoT features but the providers in general, e.g. if the service is open source, which types of servers are used and what programming languages are supported. IoT specific properties were for example which protocols were used to send messages, if push notifications were supported and if vi-sualization was available. Many of the systems have similar properties, and some properties are the same in all systems. All providers support data storage, and almost all providers support Binary Large Object (BLOB) storage, push notifications and automatic triggers on received messages. There were a couple of different protocols used, with the most common one being REST. The researchers argue that an IoT platform should at least support one IoT-oriented protocol, such as MQTT, which many of the platforms lack. The two providers of extra interest in this thesis, Azure and Amazon, have a very similar set of features in the survey. They both support almost all of the features the researchers examined, with the only one missing being Visualization in the case of Azure. They both support the MQTT and REST protocols, although Azure also supports the Advanced Message Queuing Protocol (AMQP). Another survey paper on the area is A survey paper of IoT cloud platforms, by Ray, in which 26 IoT cloud platforms are examined [22]. Ray notes that there are many more platforms than these 26 available, that did not make it into the study due to time constraints. These platforms are evaluated in the context of ten application domains, which were chosen based on what IoT cloud solutions are typically used for. Some examples of domains are: Applica-tion development, Device management, System management and Data management. The platforms
4. RESULTS
are judged by whether they would work in the given domains, and what their pros and cons are. The results suggest that some domains are much better covered by the platforms than others. Domains that were well covered by many platforms were device management, data management and application management, while domains like analytics and visualization were less covered. Ray also notes that IoT cloud platforms that work well for research are few, and that there is a need for more such platforms. The research also makes it obvious that the platforms differ heavily in how many domains they are applicable in, some of them being very specialized and others being applicable for a larger number of domains. Ray also discusses some common issues of the IoT cloud platforms, such as the fact that they do not yet follow standards in terms of for example communication and security, and that they do not have the ability to handle the heterogenity required by the IoT.
In Integration of Cloud computing and Internet of Things: A survey, Botta et al. discuss what they call CloudIoT: the integration of cloud computing and IoT [4]. They begin by motivating why the integration is useful and wanted, and note that both IoT and Cloud computing have a lot to gain from the integration of the two. The IoT is very constrained when it comes to resources, like storage and processing power. The Cloud on the other hand, has unlimited resources available. Thus, combining these two can compensate for the limitations of the IoT. The combination of the two also gives the cloud a better ability to interact with the real world, reaching new domains. They also discuss the applications that will be greatly improved through CloudIoT, such as healthcare, smart cities, smart vehicles and smart energy and environmental monitoring. The authors also bring up some of the challenges that they see in combining the cloud and the IoT. These include for example performance, reliability and security, as well as the legal aspects that will become an issue as the CloudIoT systems span several countries, each with their own laws. Finally, the researchers describe what they conclude are the biggest open issues of CloudIoT, such as lack of standardization, energy efficiency, pricing and network communication.
Tärneberg et al. [24] noticed that while there had been a lot of success stories of using public clouds IoT systems for small-scale scenarios, there was a lack of knowledge of how they would work in larger scale scenarios. To test this, they decided to build a cloud-based system for dynamic vehicle traffic control using AWS. In short, the system is intended to control traffic lights based on information from sensors in the road as well as in busses, in order to decrease the wait-time for commuters. Their requirements on the system included: Real-time, Scalable and No operations. The implemented system uses a number of AWS ser-vices, such as AWS IoT, AWS Lambda functions and AWS Dynamo DB. To evaluate their architecture, the researchers built a simulation environment which sent simulated data to the system, and developed a representative scenario with a number of intersections, traffic lights and sensors. They found that while AWS IoT can support a large amount of devices, actually managing those devices can be a bit difficult, both in terms of interacting with them through the AWS interface, and in terms of adding new devices, as each device/sensor needs to store credentials locally to be able to communicate with AWS IoT.
4.2
Specification of example system
The example system revolves around connected vending machines. An abstract figure of the system can be found in figure 4.2. There are a couple of interesting pieces of data to collect and monitor from these vending machines. The first thing to collect is the temperature inside the vending machine. This measured value should be collected once per minute, and if it passes below or above a certain threshold, an alert should be triggered. The vending machines are also supposed to send events when an item is close to running out and when it actually runs out. These messages should also trigger alerts, of two different severities. When the alerts
4.3. Implementation of example system
Figure 4.2: Example system
are triggered, an email should be sent to staff members registered. The email should contain details and a severity class, either Warning or Alarm.
4.3
Implementation of example system
This section describes the implementation of the example system in both cloud platforms. Some parts of the systems are very similar, or the same, and are thus described in their own sections.
4.3.1
Shared parts
Data generation and messages
The devices send two types of messages: temperature readings and events. The messages are very simple and are in JSON format. Listing 4.1 and 4.2 show an example temperature read-ing message and event message respectively. There are three fields which are sent in both messages: the device that sent the message, the time it was sent and the type of the message. Then, they also add the data unique to each type of message. For the temperature reading messages, this means a simple temperature value, while the event messages add a descrip-tion and a level. The level states how important, or urgent, the event is, which decides how the event will be handled by the cloud system. Two types of events are generated:
• A product is almost out - Warning level event, a normal email is be sent to notify ad-ministrators.
• A product is out - Alarm level event, a priority email is sent to notify administrators. As no real devices are used, the data sent is generated randomly. Once every minute, the device components generate a new temperature value for a new temperature reading mes-sage. At the same time, they also generate events based on a probability value, for example 20% chance of a warning message and 5% chance for a alert message. This means that all messages are generated at a 60 second interval.
4. RESULTS
Listing 4.1: A temperature reading message { " d e v i c e I d " : " d e v i c e 1 " , " time " : " 2019´03´22 1 0 : 3 0 : 0 0 " , " type " : " temperatureReading " , " temperature " : 15 }
Listing 4.2: An event message {
" d e v i c e I d " : " d e v i c e 1 " ,
" time " : " 2019´03´22 1 0 : 3 0 : 0 0 " , " type " : " event " ,
" d e s c r i p t i o n " : "A product i s almost out " , " l e v e l " : " warning "
}
Data Visualization
The data is visualized in a web application built in React, which is a JavaScript library used to build user interfaces such as web pages1. The visualization page allows a user to choose which device to show data for, and between which times. It also has an option to quickly switch between showing data from AWS and Azure. When the user has made these decisions, the page fetches the data from the REST-API of the selected system and displays it in a simple line graph. The REST-APIs also supply methods to fetch a list of all devices connected to the system and update their threshold values. The page uses these methods to display a list of devices, allowing the user to modify and save their threshold values. Figure 4.3 shows how the visualization page looks, with temperature values for the device exjobb-device loaded.
REST-API Specification
In order for the visualization page to work with the systems, they need to have some routes available in their REST-APIs. How these are implemented will be described under each sys-tem’s section, but the functions they need to supply are described below:
• Fetch temperature data
Fetches temperature data from the database for the given device, between the given times, and returns them as a list of temperature-timestamp pairs.
• List devices
Returns a list of all devices in the system, complete with the alert levels for each device. • Set device alert levels
Updates the alert levels for a single device to the specified values. Must be able to update both max and min values for both warning and alarm level. If a value is not specified in the request, it should not be changed.
4.3. Implementation of example system
Figure 4.3: The visualization page
4.3.2
AWS IoT
This section will describe the implementation of the example system implemented with AWS IoT. First, the overall architecture will be described, and then details about specific parts will be described.
Figure 4.4 shows the general architecture of the system implemented with AWS IoT. The most central part is the AWS IoT Core, which collects the messages sent from the devices through the AWS IoT Device SDK. From there, the messages are passed onto the AWS IoT Rule Engine which filters the messages and outputs them to different endpoints based on the type and content. For example, temperature messages are passed on to an AWS Lambda function which stores the temperature data in the SQL database. Another important part is the REST-API, which gives the visualization page access to temperature data and device information. These parts will be described in more detail below.
Device
The device component uses the AWS Device SDK for Python to handle communication with the cloud system. It consists of a single script, plus a couple of additional files for authen-tication. These additional files store the private key and certificate for the device, but also a certificate to allow the Device SDK to verify that the server it is talking to is actually an
4. RESULTS
Figure 4.4: Architecture of the system developed with AWS IoT
Listing 4.3: Connecting to AWS IoT myAWSIoTMQTTClient = AWSIoTMQTTClient ( c l i e n t I d ) myAWSIoTMQTTClient . c o n f i g u r e E n d p o i n t ( host , p o r t )
myAWSIoTMQTTClient . c o n f i g u r e C r e d e n t i a l s ( rootCAPath , privateKeyPath , c e r t i f i c a t e P a t h )
myAWSIoTMQTTClient . co n ne ct ( )
Listing 4.4: Sending temperature message = { }
message [ ’ d e v i c e I d ’ ] = d e v i c e I d
message [ ’ type ’ ] = " temperatureReading "
message [ ’ time ’ ] = s t r( d a t e t i m e . d a t e t i m e . now ( ) )
message [ ’ temperature ’ ] = BASE_TEMP + ( random . r a n d i n t ( ´ 5 , 5 ) ) messageJson = j s o n . dumps ( message )
myAWSIoTMQTTClient . publishAsync ( " d e v i c e /temperature " , messageJson , 1 , a c k C a l l b a c k =customPubackCallback )
AWS server. These are used when setting up the AWS IoT MQTT Client, which is shown in Listing 4.3. The AWS IoT MQTT Client is used to send messages, but also to subscribe to topics and receive messages from those topics. A topic is a simple name which can be used to filter which messages are interesting for the particular device/application. In this case, the device does not need to receive messages from the system, and thus does not need to subscribe to any topic. When sending messages, the topic sent to is decided by the type of message. Temperature readings are sent to the device/temperature topic and events are sent to the device/event topic. Listing 4.4 shows an example of a temperature message being sent. Each device in AWS IoT has a shadow, which is a JSON document which contains infor-mation about the device. This can be used to store the state or configuration for that specific device, and can be accessed through AWS IoT SDK. In this system, shadows are used to keep
4.3. Implementation of example system
Listing 4.5: A typical device shadow { " d e s i r e d " : { " alarmTempMax " : 2 2 , " alarmTempMin " : 1 2 , " warningTempMax " : 2 0 , " warningTempMin " : 14 } }
Listing 4.6: Checking temperature for alarms
SELECT * FROM ’ device/temperature ’ WHERE aws_lambda ( " arn : aws : lambda : us´west ´ 2 : 9 9 3 7 4 7 7 4 7 3 5 6 : f u n c t i o n : CheckError " , { " temperature " : temperature , " d e v i c e I d " : d e v i c e I d } ) . body . alarm = 1
track of alert levels for the devices, which will be described in more detail in later sections. Listing 4.5 shows such a device shadow looks.
Alert handling
To check if an alarm or warning should be sent when a message is received from a device, the AWS IoT Rules2are used. The rules are written with a SQL-like syntax, and select messages both on topic and conditions on the actual message content. When a message matches the rule, one or more actions are performed. AWS IoT Rules are also used to pass data to storage, which will be discussed later.
To handle alarms and warnings, two rules are used, one for each type of alert. These rules examine the contents of the incoming messages to determine if they require an alert to be sent. How this is determined depends on what type of message is examined. If the message is an event message, the rule will simply check the level of the event and depending on that make the decision to send an alert or not. If the message is a temperature reading, the decision is a little bit more complicated. The temperature levels for alarms and warnings are stored in the device shadows, as discussed earlier under Device, and the rules cannot access these values directly. They can however make calls to AWS Lambda functions3, which are pieces of code which run in the AWS cloud. For this system, all lambda functions used were written in Python. When the rule checks a message, it calls a lambda function called CheckError, passing the temperature value and the id of the device that sent the message. When CheckError receives the call, it starts by fetching the device shadow for the device id received through the AWS SDK for Python, Boto34. Once it has the device shadow, it simply compares the temperature received with the alarm and warning levels set in the shadow and responds with a simple JSON string with a field for warning and alarm respectively, which are either 0 (not triggered) or 1 (triggered). Listing 4.6 shows the rule used to catch alarms. Once a rule is triggered, it will send a message to an AWS SNS5 (Simple Notification Service) topic. AWS SNS is a service to handle notifications both to other AWS services and directly to users through for example email. When SNS receives the message, it distributes
2https://docs.aws.amazon.com/iot/latest/developerguide/iot-rules.html 3https://aws.amazon.com/lambda/
4https://github.com/boto/boto3 5https://aws.amazon.com/sns/
4. RESULTS
the message to all users subscribed to that particular topic, which in this case are the email addresses of concerned administrators.
Storage
The temperature data is stored in an SQL database which is hosted with Amazon RDS (Rela-tional Database Service)6. The database has a single table which stores the temperature value, the id of the device that sent the data and the timepoint of the temperature reading. The first component used to store the data in the database is an IoT rule. The rule is very simple, as it does not need to actually filter the data, it simply needs to get all the messages that are received in the device/temperature topic. Thus, the statement only needs to state the topic it wants to select messages from: SELECT * FROM "device/temperature". These messages are then passed on to a lambda function which is responsible for updating the database. This lambda function simply formats the data from the message and inserts it into the database, through a database connection which is kept open between calls in order to avoid opening and closing the connection for every message received.
REST-API
The REST-API used to fetch data and modify alert-levels is built using AWS API-Gateway7 and lambda functions. The AWS API-Gateway is used to set up the REST-API routes spec-ified previously and connect them to their respective lambda function. The API-Gateway supports authorization through a number of security methods, but in this project the routes are accessible without any kind of authorization. The functions used are briefly described below:
• FetchData
Activated when an HTTP request is made to the route /temperaturereadings. Reads the parameters specified (deviceId, fromTime, toTime) in the request and with them makes a simple query to the database.
• FetchDevices
Makes use of Boto3 to retrieve a list of all devices from AWS IoT. As it is not possible to get a list complete with device shadows, this function also makes separate calls through Boto3 to retrieve each devices’ shadow and add it to the list.
• UpdateDeviceAlarmLevels
Also uses Boto3 to update the shadow of the specified device with the specified alarm levels.
4.3.3
Azure IoT
This section will describe the implementation of the example system developed with Azure IoT. First, the overall architecture will be described, and then details about specific parts will be described.
Figure 4.5 gives an overview of the system developed with Azure IoT. At the core of the system is the Azure IoT Hub, which is where the data from the devices first arrive, before it is handled further. The devices make use of the Azure Device SDK to connect and send their messages to the IoT Hub. Once the messages arrive at the IoT Hub, they will be processed in different ways depending on their type and content. This includes sending alerts and
6https://aws.amazon.com/rds/ 7https://aws.amazon.com/api-gateway/
4.3. Implementation of example system
Figure 4.5: Architecture of the system developed with Azure IoT
storing temperature data. The REST-API interacts with the IoT Hub and storage to allow the visualization page to access the system.
Device
The device component consists of a single Python script which makes use of the Azure Device SDK for Python. This makes connecting and sending data to the IoT Hub a very simple task. Listing 4.7 shows the creation of the IoT Hub Client, which is used to communicate with the IoT Hub. In order to connect, the only things required is a connection string and to specify which protocol to use, in this case MQTT. The connection string is a unique key for the pair of hub and device, and follows the pattern: HostName=<Host Name>;DeviceId=<Device Name>;SharedAccessKey=<Device Key>. This key is used to identify and authenticate the device.
Once the IoT Hub Client has been created, it can be used to send messages to the IoT Hub. Creating and sending messages is as simple as connecting, and a simple example is shown in Listing 4.8. In this case, the message sent is an event which states that the vending machine is out of an item. This is considered an alarm level message, and thus, the custom property level on the message is set to alarm. This property will help sort the messages later on. In the call to send the message, a callback function is also supplied. This callback will be called when the IoT Hub acknowledges that the message has been received properly. All devices registered in the IoT Hub have a device twin, which is very similar to shadows in AWS: simple JSON documents containing information such as for example configuration and metadata. These can be accessed and modified through the Azure IoT SDKs as well as through other IoT Hub components. In this system, device twins are used to keep track of temperature alert levels for each device. These levels are stored under the desired properties of the device, and their usage will be described more later.
4. RESULTS
Listing 4.7: Connecting to the IoT Hub CONNECTION_STRING = [ Connection s t r i n g here ] PROTOCOL = IoTHubTransportProvider .MQTT
def c l i e n t _ i n i t ( ) :
c l i e n t = IoTHubClient (CONNECTION_STRING, PROTOCOL)
r e t u r n c l i e n t
Listing 4.8: Sending an event message
EVENT_MSG = ’ { " d e v i c e I d " : "%s " , " time " : "%s " , " type " : " event " , " d e s c r i p t i o n " : "%s " , " l e v e l " : " % s " } ’
eventMsg = IoTHubMessage (EVENT_MSG % ( " t e s t D e v i c e " , d a t e t i m e . d a t e t i m e . now ( ) . s t r f t i m e ( "%Y´%m´%d %H:%M:%S " ) , " Out o f item " , " alarm " ) )
eventMsg = IoTHubMessage ( jsonMessage ) eventMsg . p r o p e r t i e s ( ) . add ( " l e v e l " , " alarm " )
c l i e n t . send_event_async ( eventMsg , s e n d _ c o n f i r m a t i o n _ c a l l b a c k , None )
Alert handling
To find the messages that should trigger an alert, the system uses IoT Hub Routing Queries, which are SQL-like queries which new messages are passed through. There are two routes used to check for alerts, which can also be seen in figure 4.5; Warning and alarm. These queries select messages on both the message property level and the field temperature of the message body. For the level property, the queries simply check if it is set to alarm or warning respectively. The temperature value is compared with the alert levels specified in the twin of the device that sent the message. The routing queries have simple access to this twin, making the query very simple. Listing 4.9 shows the routing query for checking messages for alarms. When a message matches the query, it will be routed to a specified endpoint. In this system, the endpoints used are Service Bus Queues8, one for each alert route. These queues work as queues usually do, in a first in, first out manner. They are used to simply hold the messages until they are processed by the next part of the system, which will actually send the alerts. To achieve this, Azure Logic Apps9 are used. Logic apps are an Azure cloud service which allows developers to automate workflows by using available services. They are constructed by using blocks that either control the flow (e.g. loops and conditionals) or interface with some service. The vending machine system uses two logic apps, one for each of the alert routes. In this case, the logic apps used are very simple, as their only task is to send an email message. These logic apps check for new messages in their respective queue every X minutes, and if new messages have arrived, they use the gmail10 service to send an email message. The interval for checking the queues can be configured in the logic app, depending on the needs of the situation. Checking more often will ensure quick response, but also leads to a higher cost. The email message contains the message that was sent from the device, and the logic app for the alarms also set the priority of the email to high.
8https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-queues-topics-subscriptions 9https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-overview
4.3. Implementation of example system
Listing 4.9: Routing query for alarm route
( $body . temperature > $twin . p r o p e r t i e s . d e s i r e d . alarmTempMax ) OR ( $body . temperature < $twin . p r o p e r t i e s . d e s i r e d . alarmTempMin ) OR
l e v e l = " alarm "
Storage
The temperature data received from the devices is stored in an SQL database hosted by Azure. The database itself is very similar to the one presented for the AWS example system, with a single table storing device ID, temperature value and timepoint of each temperature reading. To store the data in the database, a Stream Analytics Job11is used. Azure Stream Analytics is used to process large data streamed from devices. It takes data from some source, for example the IoT Hub, applies some transformations to the data and then forwards the data to some output. In this case, it takes all incoming messages to the IoT Hub, selects which data is interesting, and then inputs the message into the database. Event messages are automatically filtered out since they do not match the transformation that the job applies.
REST-API
The REST-API used to access the devices and their data is built by using Azure functions12, which are functions that run in the Azure cloud. These functions can be activated in a number of different ways, for example when a message is put on a queue, on a set timer, or in this case, when an HTTP call is made. These functions were written in C#, as that gave the best support for use of the Azure functions web editor. Each function listens to a certain URL, and thus, we have separate functions for each route needed in the REST-API. As these URL:s are automatically generated by Azure for each function, they do not have the names of the routes specified earlier. The three functions used are described briefly below:
• FetchData
Uses the built in C# SQL client library to read data from the SQL database with a simple select query with the parameters specified deviceId, from, to in the request. Returns the results as a JSON array.
• ListDevices
The IoT Hub SDK allows querying of the IoT Hub for different types of data, such as for example device twins. This function makes use of this to make a very simple query (SELECT * FROM devices) which selects all device twins registered in the IoT Hub. As this list contains the twins, all details regarding alert levels are already included, meaning that the function simply passes the list on to the caller.
• SetDeviceAlertLevels
Makes use of the IoT Hub SDK to update the device twin of the specified device with the specified alert levels.
4.3.4
Experiences
This section will briefly describe some of the experiences learned from the implementation, both when it comes to implementation difficulties and differences between the two systems. These are not necessarily unique to IoT cloud providers, but they may still have an impact on the choice of technology for an IoT system.
11https://docs.microsoft.com/en-us/azure/stream-analytics/stream-analytics-introduction 12https://docs.microsoft.com/en-us/azure/azure-functions/
4. RESULTS
• Similarity of the examined systems
The two developed systems differ in many ways, but overall, they are relatively sim-ilar. When comparing the two architecture figures, it becomes clear that many of the components fill the same role, although perhaps with some extra steps or differing de-tails. Device twins and shadows are almost identical, and work the same way in the two systems. Routing queries and IoT Rules are used in a very similar way, except for the work-around to check alarm levels. The device SDKs are also very similar, but with small differences such as topics and custom properties for messages.
• Choice of technology
When using the IoT features of a cloud provider, the choice of technologies is some-what limited. For example, the SDKs provided may not be available in the preferred programming language. In this project, this was mainly noticed when building the storage component of the AWS system. The preferred database technology was SQL, mainly because this is what Attentec most commonly use. However, the main option available through AWS IoT was the key-value database Amazon DynamoDB13. An IoT rule can automatically input data into a DynamoDB database, with minimal setup. If an SQL database is required, this turned out to be a little bit more tricky, leading to the lambda function and separate database setup described earlier. While this was not a huge part to develop, it would require separate lambda functions for each new type of message to be stored. In comparison the system built using Azure could easily add more types of data and store them in the SQL database by extending the Stream Ana-lytics job somewhat.
• Ease of debugging
One difference noticed in the development of the two systems was how difficult it was to debug the different parts of the systems. An example of this was the interface used to construct the Message Route queries in Azure, in comparison to the interface to con-struct rules in AWS. The Azure interface has a test-concon-structor where a message can be defined and tested against the query, giving appropriate feedback (e.g. Message matched/didn’t match the query or Syntax error). While it was possible to send test mes-sages in AWS, this required these mesmes-sages to actually be sent through the IoT core (and thus possibly triggering other rules), and the rule interface did not offer as simple feedback.
• Issue of missing documentation
Some parts of the systems were lacking in proper documentation, and there were also limited resources outside of the resources provided by the cloud providers themselves. The most prominent example of this is the possibility of calling lambda functions from IoT Rules in AWS. This is not described in the official documentation for the IoT Rule Engine or for lambda functions. The only mention of it found is a brief description in a document stored in a github repository with IoT samples. This caused serious delays in the work, as this functionality was not found initially and a work-around was developed.
5
Discussion
This chapter will discuss the results of the study, both the literature study and the implemen-tation. It will also discuss the method of the study, as well as the ethical and societal aspects of the work.
5.1
Results
The literature study of IoT and IoT cloud services revealed a number of different points. It in-cluded a look at the common ways to describe and build IoT Architectures, future challenges of IoT and surveys of IoT Cloud providers/platforms. The typical architecture discussed seemed to be relatively similar in most of the examined papers, but with some differences in terminology and details. While it is a good sign that the overall architecture descriptions are similar, it would be even better to standardize the terminology to make research and development in the field simpler. Standardization and interoperability was also pointed to by researchers to be one of the challenges for the IoT in the future. As for other challenges, many researchers pointed to security and privacy being very important. One interesting aspect mentioned here is the fact that the public is not likely to adapt the IoT unless they are convinced that it will not harm their privacy [2, 21]. This means that the IoT does not only need to handle privacy in a good way, it needs to make sure that this is obvious to its users as well.
The research available on IoT Cloud providers was a bit more limited, but a number of interesting reports were found. Pflanzner and Kertész [20] made a shallow comparison of a number of number of IoT Cloud providers, by classifying them by their features. The com-parison gave an overview of which features and protocols were commonly used, and could be very useful for a developer trying to decide on a provider to use. Ray [22] took a look at a larger number of platforms, assessing which domains they were suitable for. As with general IoT, standardization was pointed out as a common issue for IoT clouds. Botta et al. [4] proposed a new term: CloudIoT to describe the integration of cloud and IoT. It described the motivation for this integration, mainly that IoT and Cloud computing complement each other well, meaning that both areas can gain from the integration. Once again, standardiza-tion is among the identified issues.
5. DISCUSSION
Reading the research on IoT cloud providers made it obvious how difficult the area is to research properly. The providers are constantly changing their platforms, and there are a large number of them available. These three survey papers had some overlap in the providers they discussed, but the total number of platforms was still too large to cover in not included. For example, Ray [22], examined 26 platforms, and still noted that there were many platforms that were skipped. There were also a couple of challenges that appeared in many studies, the most common one being standardization. It is clear that researchers demand standardization, but that the cloud providers themselves have not chosen to prioritize this. There could be many reasons for this, but one possible reason is that they do not see the value of standardization for themselves. They want customers to keep using their system, and conforming to standards would most likely mean that it would be easier for customers to change platform.
Both the implemented systems fulfil the requirements of the specified example, and make use of a number of different services of AWS and Azure. Looking at the two architectures, they are similar in many ways. The IoT Hub and the IoT Core fill roughly the same role as the central "hub" of the systems - collecting messages from devices and passing them on. Rules in AWS and Routing Queries in Azure are also quite similar, and fill a similar role. There were however some differences between the two. One big difference was that Azure Routing Queries could access the device twin of the device that sent the message, while AWS Rules did not have any access to the device shadow. This became a problem as the natural place to store alarm levels for the devices is in the device shadows/twins. To solve this, two alternatives were identified. The first was to entirely stop using rules to filter messages, and instead build a single rule which passed all messages to a lambda function that handled filtering the messages and calling the appropriate services. This would however mean that the system would not at all make use of the simplicity that rules offer, in terms of selecting messages and automatically calling other services. Regardless, this solution was at first seen as the only option, as no alternatives were found. The reason for this was noted earlier under Experiences: missing documentation. The second solution, which is the one finally used in the system, makes use of AWS Rules’ ability to call lambda functions. This was however not documented in any of the documentation pages for AWS Rules, which meant it was not found out before the first alternative had been partially developed, costing large amounts of development time.
Another difference between the two systems is how temperature data is stored in the database. In Azure, the stream analytics job can automatically format and input the data into the SQL database, but in AWS, the only action rules can trigger to store data is to store in AWS DynamoDB. This meant that a work-around had to be built, by letting the rule call a lambda function which then connects to the database which is running in AWS RDS. As noted under experiences, this works and is not very difficult to build, but it does impose an issue for larger systems with many different types of messages that need to be stored in the database. They would require either new lambda functions for each type of data to store, or to extend the existing lambda to check which type of data it is sent and handle it accordingly.
5.2
Method
The method used in this study focuses on a small example system which is built by using two cloud providers. This example was specified from a list of points which IoT Developers at Attentec believed were central for IoT system. This process could have been improved by using more literature to specify the example problem, or possibly by involving more IoT
5.3. The work in a wider context
developers from different companies and fields. Doing so could have resulted in a different example problem, which could have included features which were now skipped, such as being able to directly control the devices. The size of the example is also an issue, as it is possible that many issues do not become obvious with such a small system. The method did not include any testing with a large number of devices connected, which could also show more issues. It should be possible to replicate the results of the study, by using the implementation part of the results as a guideline. While the exact code is not described, the general architecture, the services used and the connection between them is described well enough for someone to emulate the solutions. In terms of reliability however, it is very possible that someone who performs the same study with the same example system would end up with a different result. The way that the system was implemented in AWS and Azure in this paper is of course not the only way possible, and different decisions could reveal different results. For example, one could chose to handle alarm levels through other means than device shadows/twins, meaning that the difference in access to these does not matter as much.
Most sources used in this paper are peer-reviewed papers. They were selected because they matched the topic and also based on the number of citations. For example, the article The internet of things: A survey [2], while somewhat old, had over 10000 citations, and ap-peared in most other IoT-related papers found. Special care was also taken to make sure that as many claims as possible were backed up by more than one source, to further improve the reliability of the claims. There are some exceptions, such as the National Intelligence Coun-cil´s list of Disruptive Civil Technologies [6] and Ericsson´s prediction of connected devices [9], but these are only used to motivate the importance of the area. There are also a number of sources on details and parts of AWS and Azure. For these, the official documentation supplied by the companies was used as much as possible, with occasional references to other sources like github repositories. It was assumed that the official documentation, while sometimes not complete, was correct.
5.3
The work in a wider context
There are a number of interesting implications of both the IoT itself and the use of cloud providers in IoT. The literature study revealed some of these areas. One of the most obvious areas to keep in mind is privacy. The IoT seeks to collect large amounts of data which can in many cases be sensitive. This data could be related to anything from healthcare to automated homes and connected cars. The data collected about users and their use of services and devices needs to be handled carefully, as it could be used in a number of malicious ways. Even data which at first might not seem very harmful and very useful to the application can end up being used. Porambage et. al [21] mention the example of a smart home recording the times a resident leaves for work in the morning and returns home in the evening, which could for example be used to learn the resident´s habits to plan a burglary. As a developer, collecting this data might sound very tempting, as it could allow the smart home to warm up the house or start brewing coffee at the correct time, and the risks might not be completely obvious. This is an important lesson to remember when building with IoT solutions. When building the IoT system through cloud providers, developers must also be aware that their user data is now handled and stored by some other company. This means that it is important to keep track of which companies are responsible for storing what data, and to make sure that those companies handle the data properly.
