IN DEGREE PROJECT INFORMATION AND COMMUNICATION TECHNOLOGY,SECOND CYCLE, 30 CREDITS

, STOCKHOLM SWEDEN 2016

Ranking System for IoT Industry Platform

SOMSHREE MUKHERJEE

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF INFORMATION AND COMMUNICATION TECHNOLOGY

TRITA-ICT-EX-2016:147

Ranking System for IoT Industry Platform

Masters Thesis submitted in partial fulfillment of the requirements for theDegree of Master of Science

in Internet Technology and Architecturefor EIT Digital Masters School

at KTH Royal Institute of Technology, Stockholm

SOMSHREE MUKHERJEE

Supervisor : Dr. Victor KardebyExaminer : Dr. Magnus Boman

Master’s Thesis at Swedish ICT - Acreo, Hudiksvall

Acknowledgement

I take this privilege to express my sincere and heartiest gratitude towards mysupervisor Dr. Victor Kardeby, Swedish ICT - Acreo, Hudiksvall, for supervisingand guiding me throughout the period of my thesis. I would also like to extend mythankfulness to Dr. Magnus Boman, KTH, Stockholm for his insightful suggestionsand constructive criticism.

I would also like to thank Dr. Arshad Saleem and Mr. Fredrik Billing fromKIC InnoEnergy whose encouragement and inputs helped push the project forwardand Dr. Renata Teixeira, INRIA, Paris for encouraging me to pursue this Master’sprogramme in the first place.

My gratitude will remain incomplete without thanking my parents for theiruntiring encouragement, constant guidance, love and care. They are my source ofinspiration and energy, without whom, this work would not have been possible.

Stockholm, August 2016Somshree Mukherjee

iii

Abstract

The Internet of Things (IoT) has seen a huge growth spurt in the last fewyears which has resulted in the need for more standardised IoT technology.Because of this, numerous IoT platforms have sprung up that offer a variety offeatures and use different technologies which may not necessarily be compliantwith each other or with other technologies. Companies that wish to enter theIoT market are in constant need to find the most suitable IoT platform for theirbusiness and have a certain set of requirements that need to be fulfilled by theIoT platforms in order for the application to be fully functional. The problemthat this thesis project is trying to address is a standardised procedure forselecting the IoT platforms. The project aims to suggest a list of requirementsderived from the available IoT architecture models, that must be followed byIoT applications in general, and a subset of these requirements may be specifiedby the companies as essentials for their application. This thesis project alsoaims at development of a Web platform to automate this process, by listingthe requirements on this website and allowing companies to input their choices,and accordingly show them the list of IoT platforms that comply with theirinput requirements. A simple Weighted Sum Model is used to rank the searchresult in order to prioritise the IoT platforms in order of the features thatthey provide. This thesis project also infers the best IoT architectural modelavailable based on a comparative study of three major IoT architectures withrespect to the requirements proposed. Hence the project concludes that thisWeb platform will ease the process of searching for the right IoT platform andthe companies can therefore make an informed decision about the kind of IoTplatform that they should use, thereby reducing their time spent on marketresearch and hence their time-to-market.

Keywords

Internet of Things, IoT architectural models, IoT platforms, Machine-to-machine,IoT-A ARM, WSO2, Reference Architecture, Reference Model, Interoperabil-ity, Context-Awareness, Dynamic Adaptation, Weighted Sum Model

iv

Sammanfattning

Internet of Things (IoT) har utvecklats enormt under de senaste aren vilkethar resulterat i att det behövs mer standardiserad IoT-teknik. Pa grund av det-ta har manga IoT-plattformar framkommit som erbjuder en mängd olika funk-tioner och teknik som inte nödvändigtvis överensstämmer med varandra ellermed annan teknik. Företag som vill komma in pa IoT-marknaden är i ständigtbehov av att hitta de mest lämpliga IoT-plattformarna för sin verksamhet ochde har vissa krav som maste uppfyllas av plattformarna för att deras applikatio-ner ska fungera. Problemet som detta examensarbete försöker ta itu med är attskapa ett standardiserat tillvägagansätt för att välja IoT-plattformar. Projek-tets syfte är att föresla en lista med kravspecifikationer utifran tillgängliga IoT-arkitekturmodeller, som maste uppfyllas av IoT-applikationer i allmänhet. Endel av dessa krav kan anges som väsentliga för företagens applikationer. Dettaexamensarbete syftar ocksa till att utveckla en webbplattform för att automa-tisera denna process genom att lista kraven pa denna webbplats, ge företagenmöjlighet att mata in sina val och därmed visa dem listan över IoT-plattformarsom uppfyller deras krav. En enkel Weighted Sum Model används för att rang-ordna sökresultat för att prioritera IoT-plattformar efter de funktioner som deerbjuder. Detta examensarbete presenterar den bästa IoT-arkitekturmodellenbaserat pa en jämförande studie av tre stora IoT-arkitekturer med avseendepa de krav som föreslas. Projektet drar därfor slutsatsen att denna webbplatt-form kommer att underlätta processen att söka efter den mest passande IoT-plattformen och företagen kan därför fatta ett välgrundat beslut om vilkenslags IoT-plattform som de ska använda och därigenom minska sin tid pa bademarknadsundersökningar och tid till marknadslansering.

Nyckelord

Internet of Things, IoT arkitekturmodeller, IoT plattformerna , Maskin-till-maskin, IoT-A ARM, WSO2, Referensarkitektur, Referensmodell, Interopera-bilitet, Context-medvetenhet, Dynamisk anpassning, Weighted Sum Model

v

Contents

Contents vi

List of Figures viii

List of Tables ix

1 Introduction 31.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Background 72.1 The Internet of Things Platforms . . . . . . . . . . . . . . . . . . . . 72.2 IoT Architecture Models . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 IoT Architectural Reference model (IoT-ARM) . . . . . . . . 102.2.2 WSO2 Architecture for IoT . . . . . . . . . . . . . . . . . . . 142.2.3 IoT Reference Model (Cisco) . . . . . . . . . . . . . . . . . . 16

3 Methodology 193.1 Identification of IoT Business Sectors . . . . . . . . . . . . . . . . . . 193.2 Identification of Properties for IoT Platforms . . . . . . . . . . . . . 213.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.4 Final List of Requirements and Properties . . . . . . . . . . . . . . . 243.5 Assessment of Available IoT Platforms . . . . . . . . . . . . . . . . . 25

4 Design and Implementation 294.1 Use-Case Analysis Diagram . . . . . . . . . . . . . . . . . . . . . . . 294.2 Back-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.3 Weighted Sum Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.4 Front-end . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.5 Usage of the Web Platform . . . . . . . . . . . . . . . . . . . . . . . 37

5 Experiment 415.1 Performance of the Web platform . . . . . . . . . . . . . . . . . . . . 41

vi

5.1.1 Execution Time . . . . . . . . . . . . . . . . . . . . . . . . . . 415.1.2 Average System Load . . . . . . . . . . . . . . . . . . . . . . 42

5.2 Verification of Hypothesis . . . . . . . . . . . . . . . . . . . . . . . . 425.2.1 Case Study : Power2U . . . . . . . . . . . . . . . . . . . . . . 42

6 Results and Discussion 476.1 IoT Platform Feature Requirements . . . . . . . . . . . . . . . . . . 476.2 Comparison of the IoT Architecture Models . . . . . . . . . . . . . . 486.3 Performance of the Web Platform . . . . . . . . . . . . . . . . . . . . 50

7 Conclusions and Future Work 537.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557.4 Reflections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Bibliography 57

A Business Sector Identification 63

B Cost Range 65

C Hardware / Software 67

D Number of Devices 69

E Size of Hardware 71

F Range of Area 73

G Communication Protocol 75

H Functional Requirements 77

vii

List of Figures

2.1 IoT-A architectural reference model building blocks [14] . . . . . . . . . 112.2 High-level representation of the IoT Reference Model and IoT Reference

Architecture dependencies and model influences. [14] . . . . . . . . . . . 122.3 Views and Perspectives of the IoT ARM. [12] . . . . . . . . . . . . . . . 132.4 WSO2 Reference Architecture for IoT. [15] . . . . . . . . . . . . . . . . 152.5 IoT Reference Model proposed by Cisco [16] . . . . . . . . . . . . . . . . 18

4.1 Behavioural Use Case Analysis Diagram for designing the flow of theWeb platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2 Home Page for the Web platform . . . . . . . . . . . . . . . . . . . . . . 374.3 Selecting Requirements and Options based on product need . . . . . . . 384.4 Search Results obtained after clicking “Submit” button . . . . . . . . . 384.5 FAQs Page which describes the categories and options in details . . . . 394.6 Contact Page for users to get in touch with the Admin . . . . . . . . . . 39

5.1 IoT Architecture for Power2U . . . . . . . . . . . . . . . . . . . . . . . . 43

6.1 Execution Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.2 Average System Load over 10000 runs . . . . . . . . . . . . . . . . . . . 51

viii

List of Tables

4.1 List of Requirements and options available for each platform. . . . . . . 334.2 Example for decision criteria without weights. . . . . . . . . . . . . . . . 354.3 Example for decision criteria with weights. . . . . . . . . . . . . . . . . 35

6.1 IoT Requirements vs. IoT Architectures [12] . . . . . . . . . . . . . . . 496.2 IoT Requirements vs. The three major IoT Architectures . . . . . . . . 49

ix

AbbreviationsIoT Internet of ThingsIP Internet ProtocolGDP Gross Domestic ProductQoS Quality of ServiceHTML HyperText Markup LanguageNFC Near Field CommunicationRFID Radio Frequency IdentificationM2M Machine-to-MachineARM Architectural Reference ModelESB Enterprise Service BusMQTT Message Queue Telemetry TransportHTTP Hyper Text Transfer ProtocolXMPP eXtensible Messaging and Presence ProtocolCoAP Constrained Application ProtocolAMQP Advanced Message Queuing ProtocolPEP Policy Enforcement PointSAML Security Assertion Markup LanguageSSO Single Sign-OnXACML eXtensible Access Control Markup LanguagePDP Policy Decision PointLDAP Lightweight Directory Access ProtocolLoRa Long RangeLPWAN Low Power Wide Area NetworkGSM Global System for MobileUML Unified Modeling LaguageSQL Structured Query LanguagePHP Personal Home Page (Hypertext Preprocessor)BLE Bluetooth Low EnergySEK Swedish KronorUI User InterfaceWiFi Wireless Internet for Frequent InterfaceMCDA Multi-critera Decision AnalysisWSM Weighted Sum ModelCSS Cascading Style SheetsJS JavaScriptFAQs Frequently Asked QuestionsKIC Knowledge and Innovation CommunityLSO Local System OperatorMCU Micro-controller UnitASL Average System LoadCPU Central Processing Unit

1

Chapter 1

Introduction

The Internet of Things (IoT), now being commonly referred to as the Internet ofEverything has seen a steep rise in prominence with the increase in applications anddevices being connected to the Internet. As more and more devices and applicationsbecome interconnected, companies are in constant competition with each other toup their game. This has resulted in companies entering the IoT market in a hugeway. Large companies are rushing into the Internet of Things and most companiesplan to deploy IoT in the near future. According to a report published by BusinessInsider UK, 82% of the companies will have IoT implemented in their business insome way or the other by 2017. According to report by Cisco [1], having the Internetof Things involved in some way in a business increases the operational efficiency ofcompanies by 46% [2].

According to ‘the father of sensors’, Janus Bryzek, there are a number of factorswhich are spurring the growth of the interest in IoT [3]. Among the most importantfactors is the miniaturization of electronic devices and of course, the new versionof the Internet Protocol IPv6, which will allow 2128 possible IP addresses, enablingalmost an unlimited number of devices to be connected to networks [1][2][4]. Also,according to a forecast by General Electric and Cisco, it is estimated that IndustrialInternet has the potential to add $15-$19 trillion to the global GDP over the next20 years [3].

These positive statistics further justify the fact that more and more companieswill want to enter the IoT market with their products. For any IoT product tofunction properly the correct platform is very essential. Based on the IoT ReferenceModel, which will be explained in further details in the next section, every IoTproduct has specific needs at every layer of the architecture. Moreover, some ofthese layers need to be sorted based on priority which is governed by the typeof product in question. Hence, the next step for these companies is to identifythe correct kind of IoT platforms they want to use for their product. Owing to thehuge heterogeneity in the types of applications, networks, and utilization, companiesneed to pick out the right kind of middleware or platform for their product torun on. Different products can have different kinds of Quality of Service (QoS)

3

requirements such as energy efficiency, performance, latency, security, etc. whichcan be a direct consequence of factors such as the cost, number of sensors, virtualmachines, communication protocol in use, etc. [5].

Since the IoT market is fairly new, it is sometimes difficult to anticipate therequirements of the product or from a more user perspective, it is difficult to under-stand the customer requirements. Also, since the Internet of Things is largely stillunder development, the performance parameters involved may not be very concrete,which means many a time there has to be a trade-off between certain key param-eters. Making this decision is sometimes subjective and might lead to sub-optimalresults. Hence what we currently need is a ranking system for the various IoT plat-forms available, based on the different performance parameters and then to be ableto recommend a suitable platform to the company based on their requirements.

1.1 Problem StatementThere is an overwhelming amount of IoT platforms available to companies. Thismakes it extremely difficult for them to select one that matches their need. Theproblem addressed in this project is to decide which communication platform suitsdifferent companies’ different needs. The needs of the company can vary fromsimply the cost of the components to high performance, security, or efficiency ofthe platform. This ranking system will be based on a variety of input parameters,both qualitative and quantitative, in order to determine the best communicationplatform for the company for its specific product needs.

1.2 GoalThe goal of this project is to build a ranking system, more visually in the formof a Web platform, in order to rank the different IoT platforms based on certainperformance parameters and then consequently recommend the companies of whichcommunication platform or middleware they should use for their IoT-enabled prod-ucts according to requirements provided by them.

1.3 OutlineThis report is divided into seven major sections. The first section is an introductorysection which outlines the problem statement and goals of the thesis project. Inthe second section, some of the background that provides a base to work upon, isdiscussed. In this section we discuss the basic concept of the Internet of Thingsplatform and how it is affected under different factors. We also discuss some of theIoT architectural models that provide us with an insight into the kind of propertiesthat we must consider while looking at different IoT platforms. The third sectiondiscusses the methodology we follow to form our hypothesis and the fourth sectiondescribes the design and implementation of the Web platform developed based on

4

the hypothesis formed in the previous section. In the fifth section we describesome experiments conducted to test the performance of our Web platform andadditionally, a case study to verify our hypothesis. In the sixth section we describethe results obtained and some discussions based on those results. Finally in thelast section we provide some concluding remarks and provide scope for future workbased on this project.

5

Chapter 2

Background

The Internet has been in a constant state of evolution ever since its inception. Begin-ning with the World Wide Web in 1994, a network of static HTML pages developedinto what we know as Web 2.0, allowing better user interaction, participation andcollaboration [6]. The next milestone in the evolution of the Internet was the Se-mantic Web or what was also referred to as Web 3.0 which provided a commonframework allowing data to be shared and reused across applications and enter-prises [7]. In parallel to the development of the Internet technologies, developmentin sensors networks, NFCs, and RFIDs have also evolved. With the convergence ofthe technologies, various new possibilities have come up. The prospect of commu-nication between machines with each other also led to machines being possible toaddress. All of this has led to the development of a huge network of autonomousdevices which led to the more popularly known Internet of Things [6].

The Internet of Things paradigm enables devices and machines to be inter-connected, anytime, anywhere via the Internet. Up until recently and even now,traditional Internet or the World Wide Web has proved useful in almost every as-pect providing users the ability to communicate and interact with the information,services, and rest of the world in general. However, with the advent of new andmore efficient protocols and further research into inter-connectivity on a microscopiclevel, the Internet is no longer only limited to the World Wide Web, but can nowbe extended into many other sector such as manufacturing, security, health care,automation, consumer electronics, smart grids, leading some people to claim thatwith the Internet of Things, the possibilities are endless [8].

2.1 The Internet of Things Platforms

An IoT platform is the support software that connects hardware, access points, andthe network to the rest of the IoT value chain (end-users). IoT platforms act asintermediary between the data collected at edge hardware and the users’ softwareplatform by performing data visualizations and task management, allowing efficientenvironment automation for users. It is for this reason IoT platforms are often

7

called middleware solutions and basically facilitate the entire functioning of the IoT[9].

When we talk about M2M or IoT solutions, we usually talk about the combina-tion of components or solutions from multiple vendors which are also referred to asthe “value chain of IoT”. These components which make up an IoT system include[9]:

• Edge hardware (sensors and actuators)

• A gateway device for data aggregation and transmission to and from thenetwork

• A communication network for sending and receiving data

• Software for data analysis and statistics

• The end-user application service, which is what users actually get to seein the end and which helps the users to control the system

The Internet of Things is a complicated networking environment and hence inan attempt to modularize each component of this system, a huge of number of IoTplatform vendors are now available in the market. Most of these platforms providealmost the same kind of functionality, but some are more specialized to specificbusiness sectors.

When a company wants to decide what kind of platform it needs, the solutionis not so simple. This decision depends on a lot of factors which including specifichardware, network protocols, real-time data streaming, analytics and visualisations,and much more. Hence in order to decide the kind of platform the company wantsto use, they must have an estimate of the following [9]:

• The budget range they are looking into

• The skill-sets that they already have, meaning if they would be able todevelop some of the things in-house or would need to out-source everything

• The kind of business model they operate on

• What vertical industry sector they fall into and accordingly what are theirspecific needs

• Most importantly, whether the companies are looking to save time or savemoney. Highly time efficient platforms tend to be more expensive and maynot be suitable for low-budget companies but at the same time cheaper plat-forms might be difficult to integrate with existing systems, may not be back-ward compatible and might not be easy to upgrade, which could be negativefor the company deploying it, in the long run.

8

According to the report by LinkLabs [9], there are three main types of platforms:

1. Application enablement and development: This is the most sophisti-cated among the different types of platform categories. It includes platformsthat provide templates modules or widgets that assist in the development ofthe actual end-user applications. These platforms can help create raw datainto intelligent and meaningful information, providing interesting statisticsand analytics, and also some form of graphically appealing data visualiza-tions. This category of platforms has a huge number of competitors likeOracle, Wot.io, ThingWorx, etc.

2. Network, data and subscriber management: These platforms aim tosimplify connectivity and interoperability between devices and data so thatcompanies do not have to build all of the network and data infrastructure fromscratch. For example, Cisco and Aeris provide a robust network and devicemanagement platform, whereas Wyless and Jasper provide purely networkmanagement platforms.

3. Device management: These platforms aim more towards the general servic-ing of the end nodes which mostly includes monitoring, troubleshooting andmore commonly maintaining the proper functioning of the endpoints, whichis mainly typical for a lot of hardware involved in IoT. Companies like Intel,Digi, etc. offer device cloud management.

2.2 IoT Architecture ModelsIoT environments are usually characterized by a high level of hardware and soft-ware heterogeneity, including devices with different capabilities or functionalitiesand network protocols. Hence, for this reason, IoT platforms and systems havebeen recently proposed in order to create a layer of abstraction from the technicaldetails of such devices from applications and/or end-users, in order to promote in-teroperability among them, and to contribute and improve the development of IoTapplications [10].

These architectures are mainly intended to [11]:

1. efficiently support the heterogeneity and dynamics of IoT environments

2. provide abstractions over physical devices and services to applications andusers

3. provide device management and discovery mechanisms

4. allow connecting these elements through the network

5. manage large volumes of data

9

6. address security and scalability issues

Usually, in theory, IoT talks about seamless integration and interoperability ofheterogeneous devices and deployment of high-level models for application develop-ment. However, the continuous lack of standardization in IoT, results in differentprogramming models which are not compatible with each other and hence hinderthe interoperability which is so important in this case. Also, scalability, privacyand security are not addressed with as much importance as is necessary. Hence,in order to reduce the impact of these limitations and to mitigate the limitationsthemselves, the need for suitable reference architecture, which can provide the basicfoundation and structure of an IoT application, is very essential [12].

In the following subsections, we talk about three of the most important andpromising reference architectures that have been proposed in recent years.

2.2.1 IoT Architectural Reference model (IoT-ARM)Most smart applications exploit IoT technologies to adopt to a certain level ofinherent intelligence, however, usually these applications are vertical which meansthat specific applications have a specific architecture with hardly any inter-systemcommunication or interoperability. IoT related technologies also involve a high levelof heterogeneity with respect to protocols that were developed only for specific typeof applications, which results in the IoT sphere to look seemingly fragmented.

The Internet of Things IoT-A strives to achieve a high level of interoperabilityat the communication, information, and service level by establishing a commonfoundation for IoT applications to be built on. In order to do this, the IoT-Aproject has defined two steps, firstly to establish a common understanding of theIoT domain which is referred to as the Reference Model and secondly, to provide abase for building IoT system architectures that are interoperable which is referredto as the Reference Architecture. The Architectural Reference Model is currentlybeing developed by the project partners of the European FP7 Research ProjectIoT-A [13].

Figure 2.1 outlines the processes that define the components that make theIoT-A ARM.

According to this, the existing architectures and solutions provide some baselinerequirements and features which can be used as input to the design. The IoT-AARM consists of four parts [13][14] :

1. The Vision provides an overview on the reasons that make the architecturalreference model for the IoT essential. It also describes the usage of the archi-tectural reference model, the methodology involved in the architecture mod-elling and the stakeholders or business scenarios addressed.

2. Business Scenarios defined as requirements by the stakeholders are key tomaking the architecture work. By having the information about the businessrequirements, a high-level overall view of the IoT architecture can be derived.

10

Figure 2.1. IoT-A architectural reference model building blocks [14]

Stakeholder analysis provides an understanding of which aspects of the ARMneeds to be addressed for different stakeholders and hence, this part is basicallya subset of the Vision.

3. The IoT Reference Model provides a high-level of abstraction to define theIoT-A Architectural Reference Model and promotes a common understandingof the IoT domain. The IoT Reference Model consists of an IoT DomainModel for a top-level description, an IoT Information Model which explainshow IoT information is to be modelled and an IoT Communication Modelwhich helps to understand how the communication between many differentand heterogeneous IoT devices works.

4. The IoT Reference Architecture provides the guidelines for building IoT ar-chitectures that comply to the IoT Reference Model. It helps provide the“views” and “perspectives” on various architectural aspects that might be ofuse to the IoT stakeholders. The Reference Architecture focuses on the ab-straction of the mechanisms rather than the complete concrete architecture ofthe applications.

Figure 2.2 gives a high level understanding of the dependencies and influencesinvolved in the IoT Reference Model and IoT Reference Architecture. Figure 2.3

11

provides an understanding of the different Views and Perspectives of the IoT Ref-erence Architecture. The architectural views provide descriptions that allow thearchitecture to be viewed from different angles and be used when designing andimplementing a concrete architecture. The perspectives represent the tasks, tactics,directives, and architectural decisions that help ensure that for a given system, oneor more quality attributes shared by multiple architectural views can be accom-plished.

Figure 2.2. High-level representation of the IoT Reference Model and IoT ReferenceArchitecture dependencies and model influences. [14]

1. The Functional View describes nine functionality groups, namely Application,Management, Service Organization, IoT Process Management, Virtual Entity,IoT Service, Security, Communication, and Device. Each of these have theirown set of functional components that help lay the groundwork that definesinteractions among components which are dependant on design decisions inother levels of abstraction.

2. The Information View is concerned about the exchange of relevant informationamong connected smart objects and with the external systems and definingthe components that deal with information and the dynamic information flowswithin the system.

12

Figure 2.3. Views and Perspectives of the IoT ARM. [12]

3. The Deployment and Operation View addresses the issues of using compatibletechnologies to make connected objects to communicate with each other. Italso provides guidelines in the form of different design decisions to developersand architects for the system development process.

The IoT ARM also defines four perspectives namely,

1. Evolution and Interoperability

2. Availability and Resilience

3. Reliability, Security and Privacy

4. Performance and Scalability

The perspectives take into account several quality parameters like,

1. Quality defined by the perspective

2. Requirements relevant for IoT systems

3. Applicability of the perspective to IoT systems

4. Activities suggested to obtain desired qualities

5. Architectural and design tactics that can be used to build the system

13

An important requirement for all companies is for their technologies to complywith standards and the state-of-the-art practices, so that interoperability can beensured. The IoT-A ARM helps companies in this aspect by providing them theguidelines to create IoT architectures in different domains that comply with all thestandards. These IoT architectures are basically just instances from the ReferenceArchitecture with some design choices like considering a strong security feature or astrong device management feature. for overlapping application domains, complianceto the IoT Reference Architecture ensures that solutions remain interoperable at alltimes and hence allows the better cooperation across the different domains [13][14].

2.2.2 WSO2 Architecture for IoT

The WSO2 company has proven expertise in the development of IoT solutions andhas proposed a reference architecture which includes devices along with the requiredserver-side cloud architectures in order to be able to interact with and manage thesedevices [15]. The primary goal of this architecture is to provide developers andarchitects with a starting point that is capable of fulfilling most of the requirementsof IoT systems while also allowing the flexibility of how client-server hardware orcloud architecture should work by not binding the reference architecture to fixedset of technologies or providers [12].

The WSO2 architecture (Figure 2.4) consists of components divided into hori-zontal and vertical layers that provide different functionalities [15].

The horizontal layers include :

1. Client/external communications - Web/Portal, Dashboard, APIs

2. Event processing and analytics (including data storage)

3. Aggregation/bus layer - ESB and message broker

4. Relevant transports - MQTT/HTTP/XMPP/CoAP/AMQP, etc.

5. Devices

The cross-cutting vertical layers include :

1. Device manager

2. Identity and access management

The Device Layer is the bottom most layer of the architecture and representsIoT devices of various kinds that can directly or indirectly communicate with theInternet. Examples of devices that directly connect to the Internet include Arduinowith Ethernet connection or Wi-fi connection and Raspberry Pi connected via Eth-ernet or Wi-fi. Examples of devices that connect to the Internet indirectly include

14

Figure 2.4. WSO2 Reference Architecture for IoT. [15]

ZigBee devices connected via a ZigBee gateway, Bluetooth, or Bluetooth Low En-ergy devices connect via mobile phones and devices communication to a RaspberryPi via low power radios.

The Communication Layer supports device connectivity to the cloud via com-munication protocols such as HTTP/HTTPS, MQTT, and Constrained applicationprotocol (CoAP)

The Aggregation/Bus Layer aggregates and brokers communications betweendevices. It supports HTTP server and MQTT broker to communicate with devicesand has the ability to combine communications from different devices and routecommunication to a specific device via a gateway. It also has the ability to bridgebetween different protocols for easier connectivity between devices and applications.Most importantly, this layer has two important security roles. Firstly, it must beable to act as an OAuth2 Resource Server that can validate Bearer Tokens andassociated resource access scopes. Secondly, it must be able to behave as a policyenforcement point (PEP) for policy-based access.

The Event Processing and Analytics Layer provides the ability to process andexecute upon events taken from the bus. This layer also provides the capabilityfor data storage which is very important to be able to provide relevant data ana-lytics. Hence this layer helps provide scalable data storage for events and complexprocessing of these events for autonomous actions and real-time reactions.

15

The Client/External Communication Layer provides API management by pro-viding developer-focussed portals that not only make it easier to find and exploreAPIs, but also to create and manage the available and published APIs. It also pro-vides a gateway that can manage access to the APIs by performing access controlsand regulating its usage, along with routing and load balancing capabilities. Thisgateway can then publish data to the Analytics Layer where it can be stored andprocessed to get API usage information.

Device management involves two components, namely, the Device Manager andthe Device Management Agents. The Device Manager is a server-side system whichcommunicates with devices via different protocols and also provides remote man-agement of software and applications deployed on the device. Device ManagementAgents on the other hand, vary according the the platforms and device types. To-gether they maintain the list of device identities and manage access controls overdevices.

Identity and Access Management spans vertically across all the horizontal layersprovides different services for them, such as,

• Issue and validate OAuth2 tokens

• Identify incoming requests from the Web layer using identity services such asSAML2 SSO and OpenID Connect

• XACML PDP

• Directory of users (e.g. LDAP)

• Provide access control through policy management (policy control point)

To sum it up, the variety of functionalities provided by these layers, makes theWSO2 reference architecture agile, evolvable, and scalable while also being useful,deployable, and effective [15].

2.2.3 IoT Reference Model (Cisco)

The IoT Reference Model proposed by Cisco consists of seven levels which aredefined in terms of terminology and can be standardised to produce a frame ofreference that is globally acceptable (Figure 2.5).

This reference model allows full freedom in terms of the scope and locality ofits components meaning that elements could be all together in the same room ordistributed across the world. The reference model also allows trivial to complex pro-cessing taking place at each level. The model also describes the way in which thetasks should be executed at each level in order to maintain simplicity, ensure sup-portability and allow complete scalability. Lastly, the model describes the functionsthat are needed in order to fulfil the requirements of an IoT system [16].

The seven layers of the Cisco IoT Reference Model are as follows :

16

Level 1 : Physical Devices and ControllersLevel 2 : ConnectivityLevel 3 : Edge (Fog) ComputingLevel 4 : Data AccumulationLevel 5 : Data AbstractionLevel 6 : ApplicationLevel 7 : Collaboration & Processes

The Physical Devices and Controllers layer is the bottom-most layer of thereference model. It includes the “things” in IoT which are basically the “devices”that are capable of analog to digital conversions, generating data and producingqueries over the Internet. The “things” in this layer may include sensors, machines,intelligent edge nodes, etc.

The Connectivity layer involves the reliable transmission of information betweendevices and networks, across networks, and between the network level and the low-level information processing in the higher layers, with as little lag as possible. Thislayer also includes implementation of various protocols, switching, and routing,translation between protocols, network security, and network analytics.

The Edge (Fog) Computing layer involves the analysis of high volumes of dataand transformation of this processed data for storage and higher level processing.This layer is also involved in filtering, aggregation and cleanup of data, packetinspection, aggregating network and data analytics, and event generation.

The Data Accumulation layer deals with converting data in motion to data atrest. This layer determines if the data is required for short term use or shouldbe kept in a non-volatile memory. This layer also determines if the data needsto be recomputed or not, the kind of data storage required (file system, relationaldatabase, or big data system), and if the data is properly organised or not.

The Data Abstraction Layer enables easier development of applications withhigher performance. This layers is also involved in data aggregation from differentsources and assures data consistency across these sources. This layer is also respon-sible for data virtualisation, appropriate authentication and authorization of thedata and finally verifying if the data is ready to be sent to higher-level applications.

The Application Layer enables the interpretation of data into meaningful in-formation. The applications in this layer may vary based on the vertical marketor the business sector and the nature of the device data involved. The applicationcomplexity may vary based on what kind of functionality users require, for example,monitoring and control, analytics, visualisations, error reporting, interaction basedapplications, etc.

The Collaboration and Process Layer is the topmost layer of this 7-layer archi-tecture. It involves people and business processes which is a key to the Internet ofThings. Applications from the previous layer provide useful information to peopleat the right time in order to enable them to work more efficiently and fulfil their spe-cific needs. Similarly, The applications also require interaction and communicationfrom people in this layer in order to make the IoT useful [16].

17

Figure 2.5. IoT Reference Model proposed by Cisco [16]

As can be seen in the 7-layer reference model, each layer has a very specificfunction with respect to the implementation of an IoT application. The seven layersof the Cisco IoT reference model successfully accommodate most of the features thatpeople look for in an IoT application along with providing some ground breakingfeatures that users probably would not know they needed. This reference modelbasically provides a good baseline for understanding the requirements and potentialof the Internet of Everything [16].

18

Chapter 3

Methodology

This thesis project was carried out for Swedish ICT - Acreo, Hudiksvall, but fromthe KTH, Stockholm premises since the the project did not require the usage of anyAcreo-licensed software or hardware equipment and hence relocation was unneces-sary.

The research methodology for this project was largely dependent on deductiveand inductive reasoning since the research area for IoT is mature enough to conductan in-depth study of the factors affecting it.

The idea behind the project is to build a ranking system for the IoT platformwherein users gets search results based on their input requirements for their IoTapplication. Hence, the first step is to identify the various properties that affectthe usability of different platforms and what makes a unique selling point for theseplatforms. From the three reference models in section 2.2, we can identify numerousproperties in different layers of the architecture where the performance of an IoTproduct may be affected. Hence we combine these properties and then identify themost interesting ones that have the maximum impact on the functionality of anIoT application. We then try to quantify some of these properties and develop acategorisation model for the IoT platforms based on these properties.

3.1 Identification of IoT Business Sectors

M2M solutions currently exist for numerous industry sectors and application sce-narios, some of which are as follows [17]:

• Telematics for cars and vehicles including navigation, remote vehicle diag-nostics, road charging, stolen vehicle recovery, and pay-as-you-drive insuranceschemes

• Metering applications which include remote meter management and datacollection for energy, gas, and water consumption in the utility sector

19

• Remote monitoring which refers to more generalized monitoring of assetsand includes remote patient monitoring as a classic example

• Fleet management includes a number of applications like data logging,goods, and vehicle positioning and security of valuable or hazardous goods

• Security applications include those related to home alarms and surveillancesolutions

• Automatic Teller Machines

In many aspects, IoT and M2M communication might look quite similar sinceboth essentially involve connecting sensors and devices via wired or wireless net-works. However, IoT also refers to the connection of such systems and sensors tothe broader Internet, as well as the use of general Internet technologies. IoT isabout the technology and about where this technology is applied [17]. Some of theemerging application domains that are driven by trends and interests are as follows[17]:

1. Consumer Electronics (Connected gadgets, Wearables, Robotics, Partici-patory sensing, Social Web of Things)

2. Automotive Transport (Autonomous vehicles, Multi-modal transport)

3. Retail Banking (Micro payments, Retail logistics, Shopping assisstance)

4. Environmental (Pollution, Air-Water-Soil, Weather and Climate, Noise)

5. Infrastructures (Buildings and Homes, Roads and Rails)

6. Utilities (Smart Grids, Water Management, Gas-Oil and Renewables, WasteManagement, Heating and Cooling)

7. Health and Well-being (Remote monitoring, Assisted Living, Behavioralchange, Treatment compliance, Sports and fitness)

8. Smart Cities (Integrated environments, Optimized operations, Convenience,Socio-economics, Sustainability, Inclusive living)

9. Process Industries (Robotics, Manufacturing, Natural resources, Remoteoperations, Automation, Heavy machinery)

10. Agriculture (Forestry, Crop and Farming, Urban agriculture, Livestock andFisheries)

20

3.2 Identification of Properties for IoT PlatformsIn Section 2.1 and Section 2.2, we identified the functional and non-functional re-quirements of IoT applications while in Section 3.1, we identified the major businesssectors where IoT applications are growing in number. Hence collectively from thesesections, we identified the following properties that an IoT based application wouldneed and also the ones that are currently available with existing IoT platforms

Business Sector : A lot of the IoT platforms available cater only to veryspecific business sectors. Some of these platforms already provide ready-to-usesolutions for certain business types. Others allow you to build applications for anygeneric business type. Hence categorising the platforms by the business sectors theycan cater to, helps companies to look into only the relevant platforms instead ofbeing proposed a plethora of IoT platforms that would be a waste of their time.

Cost Range : Most of the IoT platforms have a pay-per-use kind of service.Some of them offer basic features for free which can be upgraded to paid plans.Others have payment structure based on cloud storage requirements, number ofconnected devices involved, etc. Some of these platforms are also open-source,meaning the source code and APIs are freely available for reuse, modification, andredistribution.

Hardware / Software Availability : Some IoT platforms provide only soft-ware support in the form of APIs and cloud storage, whereas some platformsalso provide hardware along with software support. Hence, companies can choosewhether they only want software support or require hardware and software both.

Number of Connected Devices : Connected devices refer to any kind ofhardware that may be inter-connected among themselves or connected to the Inter-net. Connected hardware can include the sensors, microcontroller units, computers,and display units. Companies can have different requirements for the number ofconnected devices that would be involved based on the size of the product or systemthey are building and also based on the business sector they are aiming for. Forexample, the number of sensors and other connected-hardware involved in a smarthome will be much less than the number of sensors and hardware involved in aprocessing and manufacturing industry or a large commercial space like the mall orairport. Certain IoT platforms have a fixed capacity of how much data and trafficthey can handle or how much they can help scale for the companies.

Size of Hardware : For companies with specific requirements on the sizeof their product, the size of the sensors and microcontroller units is an importantfactor. For a consumer electronic product like wearables hardware needs to be smalland sleek, while for a smart grid, the hardware maybe moderately larger in size.

Range of Area in Focus : The size of the area in focus is closely related to thenumber of connected devices. the larger the area to be covered, the more numberof connected devices involved. Although it may be possible that a small smart

21

vehicle may involve more number of sensors than a smart home. Also the coveragemay be determined by the kind of communication protocol being used. An IoTarchitecture that involves Zigbee technology [18][19] will be good only for shortercoverage areas like a Medical Unit with smart health monitors. WiFi has a widercoverage area than Zigbee and is the most widely used communication protocol still,for the Internet of Things [19][20][21]. The latest is LoRa technology, which is atype of Low Power Wide Area Network (LPWAN) [20][22][23][24]. It is still fairlynew and under-developed but has a much larger range and will be better suited forIoT applications in smart grids, large factories, malls, and airports [25][26][27][28].

Power Consumption : For most companies looking to enter the IoT market,power consumption is always a major concern since no consumers want to buypower-hungry products. Hence it is important to select the right kind of platformthat supports low-power technologies.

Communication Protocol : IoT architecture essentially involves hardwarebeing connected amongst themselves and to the Internet, which means the rightkind of communication protocol is key to the products being IoT-enabled in thefirst place. Some of the plug-and-play IoT hardware available supports single veryspecific protocol while others can support a variety of protocols. Some of the com-munication technologies commonly used for IoT enabled products are GSM, 3G/4G,Bluetooth Low-Energy, Zigbee, Wi-fi, Ethernet, Thread, Sigfox, Z-Wave, LoRa,etc. [20]. As already discussed above, the communication protocol is usually de-cided based on the business sector the product falls into, the size of the area infocus, power consumption requirements of the product, data rate, bandwidth, andinteroperability requirements.

Data Reliability : Data collection, streaming, and analysis is a major partof IoT applications and hence in order for the application to be truly successful,reliability of the data is important. For example, for applications that involve datastreaming, the data must be in order and for correct data analysis, the source ofthe data must be authentic.

Data visualisation : This is an important feature that most companies nowwant for their IoT application. With all the data collected from different sources, itis important to make sense of all the data for further use. Hence most IoT platformsavailable provide some form of data analytics and visualisation which range fromvery basic to highly graphical user interfaces.

Data Storage and Management : With the collection of huge amount ofdata from sensors and various other sources, data storage and management becomesan essential part of the IoT architecture. For this purpose, most IoT platforms allowcloud storage facility usually through third party providers usually on a pay-per-usage basis.

Context Awareness : This is an important feature relevant to most IoTapplications, specially the ones that use sensors and sensor data. A system is said

22

to be context-aware if it uses a relevant context to provide useful information andservices to users based on what the user wants the system to do [29][30]. This canbe derived from hardware and software sensors to provide information and servicesto a user, automatically perform some services based on their preferences or indexinformation for retrieval later for further use [31][32]. Overall context awarenessbasically involves the the collection, aggregation, management and processing ofcontext-based information for user’s relevancy [12].

Dynamic Adaptation : This is an extremely important feature that is ofutmost necessity for an IoT platform, because it helps ensure the availability andquality of applications at all times during execution [12].

Interoperability : One of the most important challenges being faced by theInternet of Things is the lack of seamless interoperability. The lack of standardsand fragmentation contributes to the slow evolution towards the interoperabilitygoal. Although many “things” are able interact and operate with each other today,interoperability is still in its early stages and remains proprietary and resource-intensive. More and more companies are coming up with interoperability solutionsthrough open-source development. Third party associations like IEEE and con-sortiums like Qualcomm’s “AllJoyn” and the Allseen Alliance are working towardsstandardization and to facilitate collaboration. They define open source projects toprovide software frameworks that enable interoperability across operating systems,devices, and applications. For example, Axeda is working towards developing a“device agnostic” infrastructure in which their cloud platforms try to connect asmany different device standards as possible [33].

Device management : Being able to control all hardware centrally is animportant feature most companies want to have in their applications and hencemost IoT based platforms provide the option to control and manage all the inter-connected devices involved.

Scalability : Every company which wants to enter the IoT market definitelystarts with a small prototype and then extend that to a fairly sized group, with acertain amount of homogeneity. However, in order to survive in the rapid-increasingand highly competitive IoT market it is also important to be able to scale to a largerand more heterogeneous world. Hence, it is extremely important that the IoTplatform they choose should be able to support the size of the target audience thatthe company wants to focus on, which means that the IoT platform should be ableto accommodate hardware, storage, and management while also not compromisingon the security and reliability of the data.

Security, Privacy and Integrity : As already discussed before, for any IoTapplication, security of the data and network is the foremost requirement. Compa-nies need to be able to trust the platform with a lot of sensitive data and if any ofsecurity, privacy, or integrity of the system is compromised, it can result in hugelosses for the company. In case of smart homes, for example, the data collected from

23

smart devices in a house, should be secure, since otherwise it may lead to breach ofprivacy of the home owner and the home may become an easy target for burglars.

Latency and Real-time data streaming/analysis : In IoT applications, itis sometimes quite important for a company to have data streaming from hardwareor software to the cloud and vice-versa in real-time without any lag and latency isa parameter that almost no application can afford to have. Hence most IoT plat-forms advertise themselves as having minimum latency and real-time data streamingcapabilities.

3.3 AssumptionsOut of the properties described in the above section 3.2, it is not possible for us to in-clude latency and real-time data streaming as one of the properties of IoT platformsin our requirements list, even though they are quite important requirements that acompany would need. This is because in order to fairly judge the extent to whichthese properties are offered by the platform, we would have to test each and everyone of them, which has not been possible for this project. Also, after discussionwith customer service for some of these IoT platforms, it has come to notice thatmany of these platforms advertise real-time streaming of data and correspondingvisual analytics, while in reality the data is only streamed and aggregated hourly oreven six-hourly, which further suggests that without having first hand-experienceof these platforms, it is impossible to use latency and real-time streaming as fairparameters.

When it comes to power consumption, every company wants to be able to pro-vide IoT applications that consume the least power. But size of hardware, commu-nication protocol, and range of focus area can contribute to higher than expectedpower consumption. Hence we do not use power consumption as a parameter either,since it is affected by the other parameters and not platform itself, and hence is notrequired to be explicitly input by the user, who will obviously always tend to input“lowest power consumption”.

Hence for our Web platform, we firstly, assume that for now we cannot providelatency and real-time data streaming as metrics to the users, and secondly, weassume that all users want the solution with the lowest power consumption, butother functionalities being more important, decide how much power is ultimatelyconsumed by the application.

3.4 Final List of Requirements and PropertiesBased on the analysis in section 3.2 and 3.3, we propose that the requirementsshould be divided into two types :

1. Objective Requirements : These are the type of requirements that can bequantified or concretely decided based on the IoT application. These require-

24

ments provide the basic infrastructure for the IoT application to be developedupon. This includes requirements based on Cost, Hardware/Software avail-ability, Number of Connected devices, Size of Hardware, Size of Focus Area,and Communication Protocols.

2. Functional Requirements : These are the type of requirements which pro-vided added functionality to the IoT application besides just connecting de-vices to the Internet. This includes requirements related to Data Reliabil-ity, Data Visualization, Data Storage, Interoperability, Device Management,Context Awareness, Dynamic Adaptation, Scalability, and Security-Privacy-Integrity. We also add Open Source availability and Documentation avail-ability as functional requirements since these allow developers to freely andeasily build upon their IoT applications and allow them to implement addedfeatures.

Besides these two types of requirements, we separately includeBusiness Sectoras a primary requirement, since it is the foremost requirement of the IoT platformto be compliant with the business sector that the user is aiming for.

3.5 Assessment of Available IoT PlatformsAfter looking into over 100 IoT platforms, we use the following 85 IoT platformsfor this project. These platforms were selected on the basis of effective customersupport availability in English and sufficient information available on their Websitealong with documentation. In order to determine this, the companies were contactedvia electronic mail and live chat support, in order to receive the product catalogueand detailed information about their platform and their unique selling point.

1. Aeris

2. Alleantia

3. Allseen Alljoyn Alliance

4. Allthings Talk Cloud

5. ARM

6. Arrayent

7. AT&T

8. Attunix

9. Autodesk Fusion Connect

10. AWS IoT

11. Axeda by ptc

12. Axonize

13. Azure IoT Hub by Microsoft

14. Base n

15. Bluemix by IBM

16. Bolt

17. Brightwolf

18. Brillo & Weave by Google

19. Bug labs

20. Carriots Cloud Platform

21. Citrix

25

22. Cloudplugs

23. Crowsnest

24. DG Logik

25. Evrything

26. Exosite - One Platform

27. extremeiot

28. FIWARE

29. Freeboard

30. Glassbeam

31. GroveStreams

32. Hackster

33. HyperCat

34. iDigi Device Cloud

35. Iotivity by Intel

36. IoTool

37. IPSO

38. Jasper by Cisco

39. Kaa

40. Kamstrup

41. Kii

42. Libelium

43. Litmus Automation

44. Marvell

45. Mbed

46. Mnubo

47. mydevices

48. Nimbits

49. n.io

50. Node+

51. Octoblu

52. OneM2M Standards

53. OpenIoT

54. OpenRemote

55. Open.sen.se

56. Oracle

57. ProxPlatform by Neuaer

58. PubNub

59. Semtech

60. SensibleThings

61. SensorCloud

62. Sensorflare

63. ServIoTicy

64. SicsthSense

65. Sierra Wireless

66. Silicon Labs

67. Skkynet’s Secure Cloud Service

68. Thingsquare

69. ThingLogix

70. Twilio

71. Texas Instruments

72. The Internet of Things Council

73. thethings.io

74. The Things Network

75. Thingspeak

76. Thingworx

26

77. Vortex platform by PrismTech

78. Weaved

79. WindRiver Helix

80. wot.io

81. Wyless

82. Xively

83. Yaler

84. Zater

27

Chapter 4

Design and Implementation

4.1 Use-Case Analysis Diagram

In order to design the Web platform, Unified Modeling Language (UML) has beenused. UML is a general developmental modeling language commonly used in soft-ware engineering, which provides a standard way to visualize and design the system

In order to design the flow of the Web platform, we first design a behaviouraluse-case diagram from a user perspective (Figure 4.1).

4.2 Back-end

The back-end for the Web platform consists of a simple mySQL database (MySQL5.5) containing a table with 18 columns and 85 tuples and is connected to thefront-end using a PHP script (PHP 7.0.0) over an Apache Server (Apache 2.2.29).

On the basis of the discussion in section 3.2 and 3.3, we identify the follow-ing properties which can be used to categorise the available IoT platforms thatcompanies could potentially use to build their applications :

1. Business sector

2. Hardware/Software

3. Cost range

4. Number of connected devices

5. Size of hardware

6. Range of the physical area

7. Communication protocol

8. Data reliability

29

Figure 4.1. Behavioural Use Case Analysis Diagram for designing the flow of theWeb platform

9. Data visualisation

10. Data storage and management

11. Context Awareness

12. Dynamic Adaptation

13. Interoperability of devices

14. Device management

15. Scalability

16. Security, privacy and integrity

17. Open-source

18. Documentation availability

We add these properties as filters on our Web platform for users to choose whichof these are more important to their application or business and which of these theycould afford to not consider. On the basis of these filters a list of potential IoT

30

platforms will be generated for their situation. We use these properties as columnsfor our table of IoT platforms.

The above filters can take the following values :

1. Business sector : Consumer Electronics, Automotive Transport, Re-tail Banking, Environmental, Infrastructure, Utilities, Health &Well-being, Smart Cities, Process Industries, Agriculture, Others

2. Hardware/Software : Software Platform, Hardware also

3. Cost range : High/Medium/Low

4. Number of connected devices : High/Medium/Low

5. Size of hardware : Small/Medium/Large

6. Range of the physical area : Small/Medium/Large

7. Communication protocol : BLE, GSM, 3G/4G, Zigbee, Thread, Z-wave, LPWAN, WiFi, Ethernet, Others

8. Data reliability : Yes/No

9. Data visualisation : Yes/No

10. Data storage and management : Yes/No

11. Context Awareness : Yes/No

12. Dynamic Adaptation : Yes/No

13. Interoperability : Yes/No

14. Device management : Yes/No

15. Scalability : Yes/No

16. Security, privacy and integrity : Yes/No

17. Open-source : Yes/No

18. Documentation availability : Yes/No

The options for business sector are as mentioned in section 3.1.For the cost range of the platforms, the cost has been divided into three

groups - High, Medium and Low. On the basis of cost range of the 85 platformsin the database, prices could be categorised into three groups, where Low categoryconsists of platforms that offer services for free or upto 500SEK per month. TheMedium category consists of platforms that offer services int the price range of500SEK to 2000SEK per month and the High category consists of platforms that

31

offer services for more than 2000SEK per month. The price of the platform isusually on a pay-per-use model and depends on a number of different factors likethe number of connected devices and hence the number of IP addresses required,amount of cloud storage space required, the amount of data analytics required, etc.Most of these platforms offer a basic plan for limited time with limited features, forfree, and then this can be upgraded to more expensive plans with more functionalityand lesser limitations as the requirements increase.

For the number of connected devices, we divided it into three categories -High, Medium, and Low. This categorisation was done on the basis of the averagenumber of connected devices involved in the most common and popular IoT appli-cations in various sectors like smart homes, consumer electronics, utilities, processindustry, etc. On the basis of this, Low category consists of products or systemsthat require less than 25 connected devices. The Medium category can be used todenote products that require approximately between 25 to 200 connected devices,while the High category can be used to denote products that would involve morethan 200 connected devices.

For the size of the hardware involved, this would depend on whether thecompany requires external hardware other than personal computers and UI devices,like sensors, micro-controller units, etc. The sizes have been categorised as Small,Medium, and Large which is based on the average sizes of hardware available fordevelopment of IoT products. The Small category includes hardware which is smallthan 2cm, while the Medium category includes hardware which ranges between 2cmand 10cm, and finally the Large category includes hardware which has a size largerthan 10cm.

For the range of the physical area in focus, we again categorise as Small,Medium, and Large, where Small range implies a small area equivalent to a singleapartment or less, Medium range implies a single building with many apartments ora small-scale factory and Large range implies bigger areas like commercial spaces,large factory, large residential area with many apartment buildings, malls, airports,or even larger areas.

When it comes to communication protocols, the protocols that support IoTdevelopment are Bluetooth Low-Energy (BLE), GSM, 3G/4G, Zigbee, Thread, Z-wave, Low Power Wide Area Network (LPWAN), WiFi, and Ethernet. Hence weuse these as categories for communication protocol requirements.

The 85 IoT platforms identified in section 3.4, populate the table in the form ofunique records or tuples (Table 4.1).

4.3 Weighted Sum Model

The weighted sum model [34] is one of the simplest and most popular multi-criteriadecision analysis (MCDA) methods for evaluating different alternatives for a deci-sion criteria.

To describe the basic method, for a given multi-criteria decision situation, we

32

Table 4.1. List of Requirements and options available for each platform.

S.No. Requirements Available options

1 Business Sector Consumer Electronics, Automotive Transport,Retail Banking, Environmental, Infrastructure,Utilities, Health and Well-being, Smart Cities,Process Industries, Agriculture, Others

2 Cost Range High (>2000SEK pm), Medium (500-2000SEK pm),Low (<500SEK pm)

3 Hardware/Software Software Platform, Hardware also

4 Number of connected devices High (>200), Medium (25-200), Low (<25)

5 Size of hardware Small (<2cm), Medium (2-10cm), Large (>10cm)

6 Range of physical area Small, Medium, Large

7 Communication Protocol BLE, GSM, 3G/4G, Zigbee, Thread, Z-wave,LPWAN, WiFi, Ethernet, Others

8 Data Reliability Yes/No

9 Data Visualisation Yes/No

10 Data storage and management Yes/No

11 Interoperability Yes/No

12 Device Management Yes/No

13 Context Awareness Yes/No

14 Dynamic Adaptation Yes/No

15 Scalability Yes/No

16 Security, Privacy and Integrity Yes/No

17 Open-source Yes/No

18 Documentation Availability Yes/No

33

have p alternatives and q decision criteria. If wj represents the relative weight ofimportance of a criteria Cj and aij is the performance value of alternative Ai whenevaluated in terms of Cj , then the total importance of alternative Ai, which is theweighted sum model score for Ai (AW SM−score

i ) is defined as follows :

AW SM−scorei =

q∑j=1

wjaij for i=1,2,3...p.

The best alternative is the one that returns the maximum total performancevalue, for the maximization case.

Here we assume that we only have benefit criteria which means that higher thevalue, the better it is [35][36][37].

For our case, for each alternative (which are the IoT platforms), we have 18different decision criteria (which are the requirements) that may or may not befulfilled by the IoT platform. Based on an extensive literature study conductedon these platforms as mentioned in section 3.5, we assign a value of ‘1’ when ancriteria is fulfilled by the IoT platform and a value of ‘0’ if a criteria is not fulfilled.Each of the criteria are equally important and are hence assigned the same weightof ‘1’. It is the users who decides which of the criteria are important to them andhence deciding on “priority-based weights” for different criteria becomes redundant.Hence the final weighted sum for a decision criteria is simply the summation of allthe weights for different criteria for that particular IoT platform alternative.

Based on the criteria that the user selects in the Web front-end, the searchoperation queries all the platform alternatives that fulfill the user requirements andthen the final list of search results is displayed in descending order of the weightedsum for the alternatives. This implies that platforms with higher weighted sumscores fulfill more number of criteria as requested by the user and are hence displayedbefore the the ones with lower weighted sum scores.

As an example, we can assume that we have IoT platforms alternatives A1, A2,A3 and A4 that may or may not fulfill the decision criteria C1, C2 and C3.

• Platform A1 fulfills criteria C1 and C3 but not C2.

• Platform A2 fulfills criteria C1 and C2 but not C3.

• Platform A3 fulfills criteria C2 and C3 but not C1.

• Platform A4 fulfills all three criteria C1, C2 and C3.

This is denoted as in Table 4.2.Now supposing the user inputs his or her requirements are C1 and C3, then the

basic query results in the following output :

1. A1

2. A4

34

Table 4.2. Example for decision criteria without weights.

C1 C2 C3A1 1 0 1A2 1 1 0A3 0 1 1A4 1 1 1

Now if we take into consideration the Weighted Sum Model, then we include theweights as in Table 4.3.

Table 4.3. Example for decision criteria with weights.

C1 C2 C3 WS − score

Weight 1 1 1A1 1 0 1 2A2 1 1 0 2A3 0 1 1 2A4 1 1 1 3

And now if the user were to input his or her requirements as C1 and C3, thenthe search result outputs :

1. A4

2. A1

This is ordered by the weight, and hence A4 appears before A1, meaning A4 notonly fulfills the user requirements but also provides an extra feature which is C2(since we have already established that all of the decision criteria involved in ourplatform are equally important for an IoT application) and hence the user can easilyunderstand that A4 is a better choice than A1.

4.4 Front-endThe Web front-end consists of the IoT platform property filters on the home page,for users to enter their requirements, following which the properties of the IoTplatforms in the database will be matched with the requirements input by the userand then the corresponding IoT platform list will be displayed. The company canalso leave some of the fields blank where they are not sure what kind of requirementsthey would like. Also, all the limitations and details of the options available for eachproperty, as explained in section 4.1 are explained in an FAQ section on the Webplatform.

The Web front-end has been implemented using Bootstrap for HTML, CSS andJavascript/JQuery.

35

The following components/plugins have been used:

• Bootstrap v3.3.7

• Waypoints 3.0

• Modernizr 3.3.1

• animate.css (http://daneden.github.io/animate.css/)

• Bootstrap Hover Dropdown plugin (https://github.com/CWSpear/bootstrap-hover-dropdown)

• Bootstrap Slider (https://github.com/seiyria/bootstrap-slider)

• Google maps API

The fonts used in the front-end are as follows:

• Font awesome (http://fontawesome.io/icons/)

• Roboto (https://www.google.com/fonts/specimen/Roboto)

The Web platform is responsive and scales perfectly for mobile devices. Theplatform has been tested to work perfectly for Chrome, Firefox and Safari Webbrowsers on Windows 8, Linux (Ubuntu 16.04), and Mac OS X (Version 10.10.1).

Bootstrap

Bootstrap was created at Twitter in mid-2010. It is a popular HTML, CSS, and JSframework that is used for fast and easy development of responsive Web platforms.It can efficiently scale Websites and application on any output device of any sizefrom a single code using CSS media queries [38].

Waypoints

Waypoints is a plugin that allows developers to execute functions on scrolling to anelement. On-scroll animations are quite popular and gives Websites a more fluidand dynamic appearance [39].

Modernizr

Modernizr is a collection of super-fast tests which run as the Web page loads, helpingto customise the Web experience for the user.

Differences in browsers, devices and operating systems causes differences in howa Web platform may be visible to users and can sometimes result in disruptive userexperience. This is usually because of different feature sets that newer versions of

36

browsers can support but not the older browsers, yet a Web platform has to berobust enough to support older versions as well as new.

Modernizr makes it easy to provide satisfactory user experience by making use oflatest features in newer versions of browsers for those who use it while also providingusers having older browser, with a pretty decent Web experience.

Modernizr is basically a piece of JavaScript code that is able to automatically“detect” the the next-generation Web technologies available in the user’s browsersand by using feature detection techniques, allows developers to customise the user’sexperience according to the user’s browser capabilities [40].

4.5 Usage of the Web PlatformIn order to use the Web platform, users have the home page where they haveoptions for selecting their Business Sector, Objective Requirements and FunctionalRequirements (Figure 4.2). According to their requirement, they can select therespective options and if they are satisfied with their selection, they can click the“Submit Button” or choose to “Reset” all the selected options and start again(Figure 4.3). Based on the user’s selections, the Web page fetches the results mostrelevant to the kind of product and requirements they are looking for (Figure 4.4).Additionally, the Web platform has an FAQs page where the categorisations andoptions are explained and a Contact page if they have any questions (Figure 4.5,4.6).

Figure 4.2. Home Page for the Web platform

37

Figure 4.3. Selecting Requirements and Options based on product need

Figure 4.4. Search Results obtained after clicking “Submit” button

38

Figure 4.5. FAQs Page which describes the categories and options in details

Figure 4.6. Contact Page for users to get in touch with the Admin

39

Chapter 5

Experiment

5.1 Performance of the Web platformIn order to assess the performance of the Webplatform, some automation testingwas conducted on the following hardware system :

Darwin Somshrees-MacBook-Air.local 14.0.0 Darwin Kernel Version 14.0.0:Fri Sep 19 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64

Model Name: MacBook AirModel Identifier: MacBookAir6,2Processor Name: Intel Core i5Processor Speed: 1,4 GHzNumber of Processors: 1Total Number of Cores: 2L2 Cache (per Core): 256 KBL3 Cache: 3 MBMemory: 8 GBBoot ROM Version: MBA61.0099.B16SMC Version (system): 2.13f15

These tests were conducted for the following two performance parameters :

1. Execution Time

2. Average System Load

5.1.1 Execution Time

We calculate the execution time for every run of the Web platform that fetches somesearch results. We use the microtime function for PHP which returns the currentUnix timestamp in microseconds [41].

41

<?php$start_time = microtime(true);$end_time = microtime(true);$time_elapsed = $end_time - $start_time;echo $time_elapsed;?>

>> 0.0012569427

We conduct this experiment for 10000 automated runs of the Webplatform andfinally calculate the average execution time taken by the Website to return thesearch results.

5.1.2 Average System LoadWe also map the average system load for each run of the Webplatform. We usethe sys_getloadavg function for PHP which returns three samples representing theaverage system load over the the last 1, 5 and 15 minutes respectively. The averagesystem load here refers to the number of processes in the system run queue [42].This experiment was also conducted for 10000 automated runs of the Webplatform.

<?php$load = sys_getloadavg()echo $load[0]. " " .$load[1]. " " .$load[2];?>

>> 2.693359375 2.2026367188 2.0874023438

5.2 Verification of HypothesisIn order to verify our hypothesis of the 18 properties identified as key to a company‘sIoT business, we conducted a qualitative analysis in the form of a case study witha startup aiming to bring their product to the IoT market.

In this case study, we describe the IoT requirements of a company primarily inthe Infrastructure and Utilities Sector.

5.2.1 Case Study : Power2UPower2U is an energy startup within the incubation of KIC InnoEnergy, Stockholm.The startup is working to build a Local System Operator (LSO) where they willdesign and operate sustainable local energy systems (nano and micro grids).

The LSO concept involves local generation and storage of energy and thus op-timise price, quiality and efficiency of current energy systems. It integrates an IoT

42

platform as well to measure and manage the energy consumption by means of ana-lytics and data visualisations and in doing so they aim to creat a new energy marketfor themselves.

IoT Requirements of the Company

A major part of the company’s value proposition is its Energy metering systemand data visualization for users. As can be seen in the company’s IoT architecture(Figure 5.1), it involves sensors, micro-controllers, an IoT gateway and the cloudwhere the collected data will be processed and sent to users.

Figure 5.1. IoT Architecture for Power2U

The company wants to have a scalable solution which can be used for a singlebuilding, a large residential area consisting of many buildings or even larger spaceslike malls and airports. A robust communication protocol is key here. Not only doesthe company want excellent connectivity at all times, they also want a wide rangeprotocol that can cover small and large areas both. Since their product is not reallya micro-sized consumer electronic product, the sensors involved do not need to betiny. Moderately sized sensors would work fine for the company. An importantconstraint for the company is also the low power consumption of the sensors andthe communication protocol enabled micro-controller chip. Afterwards they wouldalso like to have an efficient cloud solution for data analytics and visualisation. Ahigh level of network and data security is essential since the company deals withsensitive home and building data which could be disastrous in the wrong hands.For the company, the cost is not too much of a constraint but they would of course,like to keep it towards the lower end.

Based on section 3.1 and 3.2 and the above mentioned requirements the companyhas the following solution constraints or filters :

43

1. Business sector : Environmental, Infrastructure, Utilities

2. Hardware/Software : Software Platform, Hardware also

3. Cost range : Medium

4. Number of connected devices : Medium, High

5. Size of hardware : Medium

6. Range of the physical area : Medium, Large

7. Communication protocol : Zigbee, WiFi, LPWAN

8. Data reliability : Yes

9. Data Visualisation : Yes

10. Data storage : Yes

11. Interoperability : Yes

12. Device Management : Yes

13. Context Awareness : No

14. Dynamic Adaptation : No

15. Scalability : Yes

16. Security, Privacy and Integrity : Yes

17. Open-source : Yes

18. Documentation Availability : Yes

Possible IoT Solutions for the Company

Based on the requirements provided by the company, we can provide a manualanalysis of the possible solutions that would be interesting for the company to workwith. For example, if we consider the physical area that the company wishes tofocus on, power consumption, security, and communication protocol requirements,Zigbee, WiFi, and LPWAN (LoRa) [20] are the most suited for the task that thecompany is trying to achieve. However when we compare these three protocols,we come to understand that Zigbee is quite short range and hence in order tocover the company’s large area coverage, more number of sensors would have to bedeployed to form a bigger mesh network for Zigbee to work properly. So in thiscase WiFi and LPWAN technologies seem to be quite promising [27]. Also since thecompany will be dealing with sensitive home data which could be quite dangerouswith respect to security breaches in the wrong hands, a good level of security is

44

paramount. Zigbee is much less secure than WiFi and hence not really a very goodoption for us in this case [18][19][43]. LPWAN is quite new in the market and wouldrequire some number of years before all devices and homes can be LPWAN-enabled[23][24][26]. Hence even though LoRa and Sigfox which are LPWAN technologiespromise seamless integration [22][25], there might still be interoperability issuesand lack of tech support as they are not as well developed as WiFi [18][19][20][21].Also it makes sense to use WiFi enabled technology, specially in residential areaswhere WiFi is easily available and accessible and so the company does not have tospend on building a new network [18][19]. The only drawback WiFi has for nowis its significantly higher power consumption in comparison to Zigbee and LPWAN[18][19][28], but it is a reasonable tradeoff considering the other advantages thatWiFi provides [20]. After an extensive market survey it was found that there aresome low power WiFi-enabled MCUs available from Texas Instruments which couldbe a good option to cut down on the energy consumption while still making use ofall the advantages of WiFi [44].

By using the Web platform and providing the above requirements, the companyreceived a list of suggestions. This included the following :

1. Iotivity by Intel

2. Silicon Labs

3. Kamstrup

4. Texas Instruments

5. Axeda by PTC

6. Carriots Cloud Platform

7. Brightwolf

8. Base n

Out of these, the company is already using products from Iotivity by Intel andTexas Instruments for their initial prototyping. After receiving the above searchsuggestions, they were particularly interested in Kamstrup which has a dedicatedIoT platform for smart meters which they had missed out in their market research.

45

Chapter 6

Results and Discussion

The results from this project can be discussed in three parts. In the first part (sec-tion 6.1), we discuss the pros and cons of the three IoT Architecture Models. In thesecond part (section 6.2), we discuss the IoT feature requirements that companiesaiming to enter the IoT market must keep in mind. These requirements have beenderived from the IoT architecture models and hence form the obvious second stepfor this project. In the third part (section 6.3), we discuss the performance of theWeb platform designed on the basis of the previous two parts (section 6.1 and 6.2).

6.1 IoT Platform Feature RequirementsFrom the investigation of the three major IoT architectures as detailed in section 2.2,we identified some of the most important features that we believe an IoT platformmust provide in order for the IoT application to run efficiently. A structure wasproposed for the requirements, that companies in any vertical industry can use todecide the right IoT platform for their IoT application.

These requirements are :

1. Business Sector

• Consumer Electronics• Automotive Transport• Retail/Banking• Environmental• Infrastructure• Utilities• Health Well-being• Smart Cities• Process Industries

47

• Agriculture

2. Objective Requirements

• Cost• Hardware/Software• Number of Connected devices• Size of Hardware• Size of Focus Area• Communication Protocols

3. Functional Requirements

• Data Reliability• Data Visualization• Data Storage• Interoperability• Device Management• Context Awareness• Dynamic Adaptation• Scalability• Security, Privacy & Integrity

These requirements were successfully implemented on the Web platform for usersto select, after which they get a list of IoT platforms that match their requirementssorted in the order of the maximum number of functional requirements in a platform.

So instead of looking for a suitable IoT platform for their business, companiescan now look through a condensed list of only the most relevant platforms and selectthe best one for their applications.

6.2 Comparison of the IoT Architecture ModelsThe identification of the most important features based on the three major IoTarchitectures resulted in an extension to the results proposed by E. Cavalcanteet.al. in [12] where they compare the IoT Architectural Reference Model and theWSO2 Reference Model with respect to only seven features. The comparison asdone by E. Cavalcante et.al. is outlined in table 6.1.

In the comparison table they useXsymbol to indicate that the requirement is ful-filled, the © symbol to indicate that the requirement is partially fulfilled and the× symbol to indicate that the requirement is not fulfilled at all.

48

Table 6.1. IoT Requirements vs. IoT Architectures [12]

Requirements IoT ARM WSO2Interoperability X XDevice discovery & management × ©Context-awareness × ©Scalability X XManagement of large volumes of data × ©Security, privacy and integrity X XDynamic adaptation × ×

According to their comparison, they suggested WSO2 as being marginally betterthan IoT ARM, since it provided marginally better features (more number of Xand©symbols).

Since we proposed nine features as key to an IoT platform, we use these ninefeatures instead of seven, to compare three IoT architectures instead of just two(Table 6.2). This provides a much wider and complete comparison of the threemajor IoT architectures available. We use the same symbols to indicate whetherthe requirements are completely fulfilled, partially fulfilled or not fulfilled at all.

Table 6.2. IoT Requirements vs. The three major IoT Architectures

Requirements IoT ARM WSO2 CiscoData Reliability X X XData Visualisation × © XData Storage × © XInteroperability X X XDevice Management × © XContext Awareness × © XDynamic Adaptation × × ©Scalability X X XSecurity Privacy Integrity X X X

As is clear from the table 6.2, the IoT Architecture proposed by Cisco not onlyprovides the basic features but also ones like Data Visualisation, Data Storage,Device Management, Context Awareness and Dynamic Adaptation which were notprovided or even considered by the previous IoT architectures, but are extremelyimportant for IoT application today. The Cisco IoT Architecture hence fulfillsalmost all the requirements that an IoT platform should possess and is clearly muchbetter than IoT ARM and WSO2 architecture. Therefore, we can say that the Ciscoarchitectural model is a good starting point to use as a reference for development ofIoT platforms to support IoT based applications. The Cisco architecture can providea standardised set of requirements that should be fulfilled by an IoT platform torun smoothly and efficiently.

49

6.3 Performance of the Web PlatformWith respect to the Web platform that provides companies with a set of require-ments and options that they can choose from, we performed some automation testsas already described in section 5.1.

The first test was for the time taken to execute the queries based on the userinput. We calculate the time that a random user input for requirements will taketo query and display the search results. We finally find the execution time averagedover 10000 runs of the Web platform. The graph (Figure 6.1) shows the executiontime plotted for each run and then a straight line which shows the average executiontime for the Web platform.

Figure 6.1. Execution Time

Based on this test we get an average execution time of 0.000923 microsecondswhich is quite good since this means that users would not have to wait for too longto receive the final search results based on their inputs.

The second test calculates the average system load on the system hardware.This is also done for each run and then averaged over 10000 total runs. The graph(Figure 6.2) shows the average system load over the last 1 minute, 5 minutes and15 minutes respectively, plotted for each run.

Based on this test we get an overall average system load of 2.612611 for the last1 minute, an overall average system load of 2.190953 for the last 5 minutes and anoverall average system load of 2.083461 for the last 15 minutes.

50

Figure 6.2. Average System Load over 10000 runs

51

Chapter 7

Conclusions and Future Work

This chapter discusses the Conclusions and Reflections based on this project. Somefuture work has also been suggested as a next step for this project.

Section 7.1 discusses how the goals stated in the initial part of the report havebeen fulfilled and the conclusions drawn from the experimentation and results ob-tained for this project. Section 7.2 outlines some of the limitations faced duringthe research and for the results. Section 7.3 provides some suggestions for futurework that can be done in order to improve the results for this project. Section 7.4describes some of the relevant ethical, social, and sustainability aspects of the work.

7.1 Conclusions

The primary goal of this project was to provide a system that is capable of rankingavailable IoT platforms in a reliable manner such that companies that are lookingto enter the IoT market can get relevant search results for relevant platforms basedon their specific requirements. In order to do this the currently available and mostpopular IoT architectures were studied and compared, and based on this, the mostrelevant features of an IoT platform were obtained. On the basis of these properties,the IoT platforms were categorised and a Website was built. The Weighted SumModel was also implemented in order to rank the relevant platforms in order ofthe quality. The quality of an IoT platform was decided based on the availabilityof extra features besides the ones the user wants, since we established that all thefeatures derived from the study of the IoT architecture were extremely importantin an IoT platform and hence, more the number of features that a platform canprovide, the better it is. A basic automation testing of the Website yielded anaverage execution time of 0.000923 microseconds and an average system load of2.612611 which is basically the number of processes in the system run queue whichimplies that the back-end is structured well enough for the querying and executionto not take a lot of time or use too much CPU in order to return the search results.

Based on the extensive literature study on the IoT reference models and ar-chitectures, a subjective and objective comparison of the three most popular and

53

comprehensive IoT architecture models as an extension of the preliminary compari-son already conducted by E. Cavalcante et.al. in [12], resulted in an obvious winneramong three architectures which is the IoT Reference Model by Cisco. Not onlydoes it allow for more functionalities that are important in the Internet of Thingsdomain, it also structures the layers in much more logical manner. It hence easierto understand and the different functionalities of an IoT application can be easilydivided into these seven layers.

With respect to the requirements of an IoT application, we concluded 18 prop-erties as detailed in section 4.2, that can be used to categorise the IoT platforms inan objective manner and based on the company’s requirements, they can use theseproperties to decide what kind of functionalities they require for their application.

After an extensive study of over 85 IoT platforms with respect to these 18properties, we can conclude that very few platforms provide "Context Awareness"and “Interoperability” as a feature since these are the most difficult to provide for theInternet of Things which is comprised of way too many heterogeneous devices andprotocols. “Security & Privacy” and “Data Reliability” are features that majority ofthe platforms provide since it is very important that the data that passes through theIoT application is not susceptible to attacks and hacking. “Data Visualisation” and“Device Management” are popular features that most companies look for in an IoTplatform, and owing to this demand, majority of the platforms provide interestingand aesthetically appealing data visualisation tools and easy device managementfeatures.

A lot of IoT platforms available are now open source which means that it be-comes easier for developers to try out new application ideas without having to payfor the API services. This leads to free flow of ideas and hence more innovation inthe Internet of Things. Also, a lot of consortium and councils have been establishedin recent years to structure the framework for IoT architectures and more impor-tantly to formulate standards that can be used in IoT applications that will allowmaximum interoperability and high level of security for the hardware and software.

The biggest challenge facing the Internet of Things, however, is still “Interop-erability” and “Security” of hardware and software involved in IoT applications.People are still not comfortable using IoT based applications for fear of sensitiveand personal data being collected and monitored while users are unaware of such athing happening, and collection of data forms a major part of an IoT application inorder for it to function. Also, from a development point of view, the “things” arestill not completely interoperable at times and may be restricted by communica-tion protocols, hardware, or software. Because of these restrictions IoT applicationssometimes end up losing out in the this fast market.

More and more companies are now opting to build their own IoT platform fromground-up so that they do not have to worry about the interoperability of theirdevices limited by a pre-programmed IoT platform. Also, using third-party cloudservices provided by the IoT platform, can sometimes pose the risk of the companynot being in full control of their data. Usually companies want to be able to havefull access to their data without sharing it with anyone else, which is sometimes

54

restricted by the IoT platforms. The platforms need all the data to be passedthrough their cloud servers in order to be able to process it further which canbecome a serious security threat for sensitive IoT applications. Hence the obviousnext step for IoT platforms to remain in the game would be to provide absoluteinteroperability by using standards proposed by the IoT council and consortium andalso allow companies full freedom of opting for their own servers to process the dataor the IoT platform’s cloud servers. Nevertheless, the IoT platforms are providingsome of the coolest features, each one better than the other, that has enabled lots ofcompanies to reduce their time-to-market by already providing them with the basicinfrastructure and thereby enabling innovative IoT solutions and hence making theInternet of Things marketplace all the more exciting.

7.2 Limitations

Some limitations were encountered during the research and implementation of thisproject. Firstly, while categorising the available IoT platforms, around 100 plat-forms had to be dealt with. Out of this around 20 were considered unfit for categori-sation due to lack of documentation or language constraints. Out of the remaining85 platforms, it was not possible to sample each and every one of these platforms dueto time constraints and more importantly because not all are open-source. Hencefor some of these platforms, the categorisation was based on a subjective and ob-jective study of the information on their Website and the available documentations.Also, due to limited knowledge of machine learning, it was not possible to imple-ment better ranking algorithms for the platform, which could have provided bettersearch results.

7.3 Future Work

As an extension to this work, the future versions of this Web platform couldhave more refined search filters with more sub-categorised details. Furthermore,a smoother Web interface with lesser latency will be essential to make the Websitescale with the increase in companies wanting to enter the IoT market as well asthe increasing availability of newer IoT platforms. The use of ElasticSearch[45][46]on the back-end is suggested in order to provide near real-time search and mul-titenancy[47] in order to make the Web platform robust. Furthermore, allocatingdynamic weights to the different requirements based on user inputs in other sec-tions of the webpage, could allow for a better representation of the search resultswhich are better suited for the user’s needs. As a further development to this, theWeb interface could be modified to allow Web crawling and data mining so thatthe interface will not be limited to the updating of a defined database from time totime but will be able to provide available results from anywhere on the Internet.

55

7.4 ReflectionsThe ethical aspect of this project can be considered in two ways. Firstly, carefulcategorisation of the IoT platforms into different properties was essential so as tonot provide any kind of misinformation regarding the platforms, which could yieldwrong results and might lead to companies following this system to choose thewrong platform and thereby incur losses. Secondly, it is important for companies toknow which of the IoT platforms that they might be looking into, provide Security,Privacy and Integrity as an essential feature since, the IoT application may involvesensitive and personal user data which should not be subject to any kind of outsideattacks or hackers who might misuse this data leading to a disaster.

The social aspect of this project is that this Website allows companies to choosefrom a much smaller set of prospective IoT platforms which would fit well for theirspecific IoT application instead of having to go through each and every IoT platformon the Internet and having to make manual comparisons to decide the best option.Hence this Website helps reduce their time spent on market research and they candecide an IoT platform much more easily, thereby allowing them to concentrate onbuilding their application without having to to worry about the IoT infrastructure,which reduces their time-to-market as well.

The sustainability aspect of the project is that this Website provides a faircategorisation of IoT platforms based on a reliable IoT architecture by Cisco, whichhas not been done before. Hence, this lays the groundwork for further developmentof this Web platform to allow implementation of better ranking algorithms whichcan provide better search results. In the future these categorisations can also beused as a base for categorisation of sub-products available on the IoT platforms,allowing even better results.

56

Bibliography

[1] T. Danova, “The Internet Of Everything”, 2014. [Online]. Available:http://www.businessinsider.com/the-Internet-of-everything-2014-slide-deck-sai-2014-2?IR=T-18. [Accessed: 27- Mar- 2016].

[2] “13 Mind-Boggling Internet Of Things Statistics”, Link Labs, 2015. [Online].Available: http://www.link-labs.com/Internet-of-things-statistics/. [Accessed:27- Mar- 2016].

[3] G. Press, “Internet of Things By The Numbers: Market Es-timates And Forecasts”, Forbes.com, 2016. [Online]. Available:http://www.forbes.com/sites/gilpress/2014/08/22/Internet-of-things-by-the-numbers-market-estimates-and-forecasts/7abdcbfb2dc9. [Accessed: 23-Mar- 2016].

[4] D. Evans, “The Internet of Things [INFOGRAPHIC]”, blogs@Cisco - CiscoBlogs, 2016. [Online]. Available: http://blogs.cisco.com/diversity/the-Internet-of-things-infographic. [Accessed: 23- Mar- 2016].

[5] L. Xu, W. He and S. Li, “Internet of Things in Industries: A Survey”, IEEETransactions on Industrial Informatics, vol. 10, no. 4, pp. 2233-2243, 2014.

[6] A. Whitmore, A. Agarwal and L. Da Xu, “The Internet of Things - A Survey ofTopics and Trends”, Information Systems Frontiers, vol. 17, no. 2, pp. 261-274,2014.

[7] “Semantic Web”, Wikipedia, 2016. [Online]. Available:https://en.wikipedia.org/wiki/Semantic_Web. [Accessed: 23- May- 2016].

[8] R. Want, B. Schilit and S. Jenson, “Enabling the Internet of Things”, Computer,vol. 48, no. 1, pp. 28-35, 2015.

[9] “IoT Platforms: What They Are & Why They're Important”, Link Labs,2015. [Online]. Available: http://www.link-labs.com/what-is-an-iot-platform/.[Accessed: 23- Mar- 2016].

[10] T. Teixeira, S. Hachem, V. Issarny, and N. Georgantas, “Service-oriented Mid-dleware for the Internet of Things: A perspective”, Proc. of the 4th European

57

Conf. on Towards a Service-Based Internet, volume 6994 of Lecture Notes inComputer Science, pp 220-229. Springer-Verlag Berlin Heidelberg, Germany,2011.

[11] S. Bandyopadhyay, M. Sengupta, S. Maiti and S. Dutta, “Role Of MiddlewareFor Internet Of Things: A Study”, International Journal of Computer Science& Engineering Survey, vol. 2, no. 3, pp. 94-105, 2011.

[12] E. Cavalcante, M. Alves, T. Batista, F. Delicato, P. Pires, “An Analysis ofReference Architectures for the Internet of Things”, CobRA ’15 Proceedings ofthe 1st International Workshop on Exploring Component-based Techniques forConstructing Reference Architectures pp. 13-16, 2015.

[13] A. Bassi, “Enabling Things to Talk”. Springer Berlin Heidelberg, Germany,2013.

[14] Iot-a.eu, “Introduction to the Architectural Reference Model for the Inter-net of Things”, 2016. [Online]. Available: http://www.iot-a.eu/public/public-documents/copy_of_d1.2. [Accessed: 02- Aug- 2016].

[15] P. Fremantle, “A Reference Architecture for the Internet of Things”, Version0.8.2. Whitepaper, WSO2, 2014.

[16] “The Internet of Things Reference Model - Cisco”, 2016. [Online]. Available:http://cdn.iotwf.com/resources/71/IoT_Reference_Model_White_Paper_June_4_2014.pdf. [Accessed: 23- May- 2016].

[17] J Holler, V. Tsiatsis, C. Mulligan, S. Karnouskos, S. Avesand, D. Boyle, “FromMachine-to-machine to the Internet of Things”. Elsevier, 2014.

[18] “The ZigBee Vs WiFi Battle For M2M Communication”, Link Labs, 2015. [On-line]. Available: http://www.link-labs.com/zigbee-vs-wifi-802-11ah/. [Accessed:23- May- 2016].

[19] “Difference between Zigbee and WiFi Technologies | Zig-bee vs WiFi”, Engineersgarage.com, 2016. [Online]. Available:http://www.engineersgarage.com/contribution/zigbee-vs-wi-fi. [Accessed:23- May- 2016].

[20] “Selecting a Wireless Technology for New Industrial Internet of Things Prod-ucts : A Gude for Engineers and Decision Makers”, Link Labs, 2016.

[21] “Z-Wave vs. Zigbee - Link Labs”, Link Labs, 2015. [Online]. Available:http://www.link-labs.com/z-wave-vs-zigbee/. [Accessed: 23- May- 2016].

[22] “What Is LoRaWAN?”, Link Labs, 2015. [Online]. Available: http://www.link-labs.com/what-is-lorawan/. [Accessed: 23- May- 2016].

58

[23] “LPWAN Suddenly Needed for IoT”, connectcompute, 2016. [Online]. Avail-able: http://connectcompute.com/2016/01/11/lpwan-suddenly-needed-for-iot/.[Accessed: 23- May- 2016].

[24] “A Comprehensive Look at Low Power, Wide Area Networks For ’Internet ofThings’ Engineers and Decision Makers”, LinkLabs, 2016.

[25] M. Bor, J. Vidler, U. Roedig, “LoRa for the Internet of Things”, MadCom,2016.

[26] “A Technical Overview of LoRa and LoRaWAN”, LoRa Alliance, November2015.

[27] “LPWA Technologies : Unlock New IoT Market Potential”, LoRa Alliance,November 2015.

[28] L. Vangelista, A. Zanella, M. Zorzi, “Long-Range IoT Technologies : The Dawnof LoRa”, Institute for Computer Sciences, Social Informatics and Telecommu-nications Engineering, 2015.

[29] C. Perera, A. Zaslavsky, P. Christen and D. Georgakopoulos, “Context AwareComputing for The Internet of Things: A Survey”, IEEE Communications Sur-veys & Tutorials, vol. 16, no. 1, pp. 414-454, 2014.

[30] A. Dey and G. Abowd, “CybreMinder: A context-aware system for supportingreminders”, In Proceedings of the International Symposium on Handheld andUbiquitous Computing, pp. 172-186, 2000.

[31] C. Perera, A. Zaslavsky, P. Christen and D. Georgakopoulos, “CA4IOT: Con-text Awareness for Internet of Things”, Proceedings of the IEEE InternationalConference on Green Computing and Communications pp 775-782, 2012.

[32] A. Dey and J. Häkkilä, “Context-Awareness and Mobile Devices”, User inter-face design and evaluation for mobile technology, vol I, pp. 205-217, 2008.

[33] “Interoperability: The Challenge Facing the Internet of Things| Altimeter Group”, Altimetergroup.com, 2016. [Online]. Available:http://www.altimetergroup.com/2014/02/interoperability-the-challenge-facing-the-internet-of-things/. [Accessed: 29- Jun- 2016].

[34] L. Guzman, “Multi-Criteria Decision Making Methods: A ComparativeStudy”, Applied optimization, Kluwer Academic Publishers, Journal of Multi-Criteria Decision Analysis, vol. 10, no. 3, pp. 175-175, 2001.

[35] “Weighted Sum Model”, Wikipedia, 2016. [Online]. Available:https://en.wikipedia.org/wiki/Weighted_sum_model. [Accessed: 02- Aug-2016].

59

[36] F. Helff, L. Gruenwald1, L. d’Orazio, “Weighted Sum Model for Multi-Objective Query Optimization for Mobile-Cloud Database Environments” ,Workshop Proceedings of the EDBT/ICDT 2016 Joint Conference on CEUR-WS.org, March 2016.

[37] R. Marler and J. Arora, “The Weighted Sum Method for Multi-objective Op-timization: New Insights”, Struct Multidisc Optim, vol. 41, no. 6, pp. 853-862,2009.

[38] Mark Otto, “Bootstrap - The World’s Most Popular Mobile-first and Re-sponsive Front-end Framework.”, Getbootstrap.com, 2016. [Online]. Available:http://getbootstrap.com/. [Accessed: 08- Aug- 2016].

[39] “Getting Started - Waypoints”, ImakeWebthings.com, 2016. [Online]. Avail-able: http://imakeWebthings.com/waypoints/guides/getting-started/. [Ac-cessed: 08- Aug- 2016].

[40] “Modernizr: The Feature Detection Library for HTML5/CSS3”, Modern-izr.com, 2016. [Online]. Available: https://modernizr.com/. [Accessed: 09- Aug-2016].

[41] “PHP: microtime - Manual”, Php.net, 2016. [Online]. Available:http://php.net/manual/en/function.microtime.php. [Accessed: 09- Aug-2016].

[42] “PHP: sys_getloadavg - Manual”, Php.net, 2016. [Online]. Available:http://php.net/manual/en/function.sys-getloadavg.php. [Accessed: 09- Aug-2016].

[43] M. Smith, “Researchers Exploit ZigBee Security Flaws that Compro-mise Security of Smart Homes”, Network World, 2016. [Online]. Available:http://www.networkworld.com/article/2969402/microsoft-subnet/researchers-exploit-zigbee-security-flaws-that-compromise-security-of-smart-homes.html.[Accessed: 23- May- 2016].

[44] “Embedded Wi-Fi Chips | Low Power Wi-Fi | Wi-Fi Modules | Wi-FiMicrocontrollers | Overview | TI.com”, Ti.com, 2016. [Online]. Avail-able: http://www.ti.com/lsds/ti/wireless_connectivity/embedded_wi-fi/overview.page. [Accessed: 23- May- 2016].

[45] “Elasticsearch | Elastic”, Elastic.co, 2016. [Online]. Available:https://www.elastic.co/products/elasticsearch. [Accessed: 23- Aug- 2016].

[46] O. Kononenko, O. Baysal, R. Holmes, M. Godfrey, “Mining Modern Reposito-ries with Elasticsearch”, 11th Working Conference on Mining Software Reposi-tories, Hyderabad, India, 2014.

60

[47] “Advantages of Elastic Search”, 3Pillar Global, 2016. [Online]. Available:http://www.3pillarglobal.com/insights/advantages-of-elastic-search. [Accessed:23- Aug- 2016].

61

Appendix A

Business Sector Identification

63

64

Appendix B

Cost Range

65

66

Appendix C

Hardware / Software

67

68

Appendix D

Number of Devices

69

70

Appendix E

Size of Hardware

71

72

Appendix F

Range of Area

73

74

Appendix G

Communication Protocol

75

76

Appendix H

Functional Requirements

77

78

www.kth.se