internet of things818109/fulltext01.pdf · chapter 1 introduction 1.1 background the internet of...

Internet of Things

Definition, applications and comparison of wifi-based communication protocolsfor implementation of an irrigation system

EMELIE BRUSE

Master of Science ThesisStockholm, Sweden April 2015

Internet of Things

Definition, applications and comparison of wifi-based communication protocols for

implementation of an irrigation system

Emelie Bruse

Master of Science Thesis MMK 2015:21 MDA 449

KTH Industrial Engineering and Management

Machine Design

SE-100 44 STOCKHOLM

Master of Science Thesis MMK 2015:21 MDA 449

Internet of Things

Definition, applications and comparison of wifi-basedcommunication protocols for implementation of an

irrigation system

Emelie Bruse

Approved

2015-04-28Examiner

Martin GrimhedenSupervisor

Bengt O ErikssonCommissioner

KTHContact person

Bengt O Eriksson

AbstractThe aim of this thesis work has been to explore the state of the art of the Internet of Things, IoT.Focus has been put on the role of communication protocols, or middleware, that enablecommunication between node and hub in the IoT architecture.

A literature study has been carried out, where the state of the art of the IoT has been studied. Acomparison of six different pieces of middleware has been made, to use as a reference whenchoosing between communication protocols for a distributed system.

An irrigation system was to be implemented as an example application. It was implemented inthe programming language Golang, using Websockets for communication between a standardlaptop computer and a Raspberry Pi embedded sensor node.

The conclusion of this thesis is that the architecture, hardware and software design for IoTsystems all vary greatly depending on the specific demands of the application. Distributedsystems, having been used for decades in industrial applications, are now increasingly used inmany different fields. A wider adoption and expansion of a standardised and secure IoT has greatpotential to leverage a moderate investment, increasing efficiency, security and quality of lifeglobally.

Examensarbete MMK 2015:21 MDA 449

Internet of Things

Definition, användningsfall och jämförelse av wifi-baserade kommunikationsprotokoll förimplementation av bevattningssystem

Emelie Bruse

Godkänt

2015-04-28Examinator

Martin GrimhedenHandledare

Bengt O ErikssonUppdragsgivare

KTHKontaktperson

Bengt O Eriksson

SammanfattningSyftet med detta examensarbete har varit att utforska state of the art för Internet of Things(sakernas internet, IoT). Arbetet har till viss del fokuserats på de kommunikationsprotokoll sommöjliggör kommunikation mellan nod och server.

En litteraturstudie har utförts, där referensramar har etablerats för IoT. Sex olikakommunikationsprotokoll har jämförts för att skapa ett underlag för design av IoT-system.

Ett bevattningssystem har utvecklats som ett exempelsystem. Det implementerades iprogrammeringsspråket Golang, och använder Websockets för kommunikation mellan enstandardlaptop och en inbäddad Raspberry Pi-nod.

Slutsatsen av arbetet är att arkitektur, hårdvara och mjukvarudesign för IoT-system i hög gradkommer bero av kraven som ställs av de olika användningsfallen. Distribuerade system haranvänts inom industrin i decennier, men växer nu snabbt inom andra fält. Ett standardiserat ochsäkert sakernas internet har potential att ge en hävstångseffekt, så att små investeringar kan gestora förbättringar av effektivitet, säkerhet och livskvalité.

Contents

Contents

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Purpose and definitions . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.5 Structure of this report . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Frame of reference: use cases and IP middleware for the IoT 72.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Application examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 Transport, logistics and infrastructure . . . . . . . . . . . . . 92.2.2 Healthcare . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.3 Smart buildings . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.4 Industrial applications . . . . . . . . . . . . . . . . . . . . . . 132.2.5 Military applications . . . . . . . . . . . . . . . . . . . . . . . 132.2.6 Safety and disaster preparedness . . . . . . . . . . . . . . . . 142.2.7 IoT in agricultural irrigation . . . . . . . . . . . . . . . . . . 15

2.3 Components and architecture of the IoT . . . . . . . . . . . . . . . . 172.3.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4 Middleware for the IoT . . . . . . . . . . . . . . . . . . . . . . . . . 202.4.1 XML-RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.4.2 SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.4.3 Websocket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.4.4 CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.4.5 ZeroC/ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.4.6 DDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.4.7 Evaluation and recommendations for choosing middleware . . 28

2.5 Technical issues and obstacles . . . . . . . . . . . . . . . . . . . . . . 292.5.1 Physical and data link layers . . . . . . . . . . . . . . . . . . 292.5.2 Network layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.5.3 Transport and session layers . . . . . . . . . . . . . . . . . . . 302.5.4 Presentation layer . . . . . . . . . . . . . . . . . . . . . . . . 302.5.5 Application layer . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.6 Security issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.7 Research and standardisation bodies . . . . . . . . . . . . . . . . . . 31

3 Implementation 333.1 Concept generation and evaluation . . . . . . . . . . . . . . . . . . . 333.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.2.2 Performance and technology . . . . . . . . . . . . . . . . . . . 343.2.3 Extended requirements . . . . . . . . . . . . . . . . . . . . . . 353.2.4 User intervention . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.3 Hardware and software development tools . . . . . . . . . . . . . . . 353.3.1 Hardware platform . . . . . . . . . . . . . . . . . . . . . . . . 363.3.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.4 Software implementation details . . . . . . . . . . . . . . . . . . . . . 373.4.1 Using websocket in Go . . . . . . . . . . . . . . . . . . . . . . 373.4.2 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.4.3 Sensor node application . . . . . . . . . . . . . . . . . . . . . 403.4.4 Hub application . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.5 Analysis and results . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4 Discussion 434.1 Research focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2 Features and behaviours of the implemented system . . . . . . . . . 434.3 Hardware and software choices . . . . . . . . . . . . . . . . . . . . . 434.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.5 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Bibliography 49

Abbreviations

3G Third Generation mobile phone communication

6LoWPAN IPv6 over Low power Wireless Personal Area Networks

API Application Programming Interface

ARM Advanced RISC Machines

CDMA Code Division Multiple Access

CeCP CORBA/e Compact Profile

CORBA Common Object Request Broker Architecture

COTS commercial off-the-shelf

CPU Central Processing Unit

CRUD Create, Read, Update, Delete

DDS Data Distribution Service

EPCglobal Electronic Product Code global

EPR Extended Producer Responsibility

ETSI European Telecommunications Standards Institute

FPGA Field-Programmable Gate Array

GPIO General Purpose In Out

GSM Global System for Mobile communications

HTTP Hyper Text Transfer Protocol

HTTPS HyperText Transfer Protocol Secure

ICE Internet Communications Engine

Ice-E Embedded ICE

IEEE Institute of Electrical and Electronics Engineers

IETF Internet Engineering Task Force

IoT Internet of Things

IP Internet Protocol

IPv4 Internet Protocol version 4

IPv6 Internet Protocol version 6

JSON JavaScript Object Notation

M2M Machine to Machine

NFC Near Field Communication

OS Operating System

OSI Open Systems Interconnection

PAN Personal Area Network

PC Personal Computer

QoS Quality of Service

REST Representational State Transfer

RFID Radio Frequency Identification

ROLL Routing Over Low Power and Lossy networks

RPC Remote Procedure Call

RTOS Real-Time Operating System

SOAP Simple Object Access Protocol

SRAM Static Random-Access Memory

TCP Transmission Control Protocol

UDP User Datagram Protocol

UMTS Universal Mobile Telecommunications System

URL Uniform Resource Locator

USB Universal Serial Bus

WLAN Wireless Local Area Network

WPAN Wireless Personal Area Network

WS WebSocket

WSN Wireless Sensor Node, or Wireless Sensor Network

WSS WebSocket Secure

XML Extensible Markup Language

Chapter 1

Introduction

1.1 Background

The Internet of Things, IoT, is a term that describes the connection of previ-ously non-connected electronic devices or data sources (from here on referred toas ’nodes’), to each other, and/or to the Internet. Nodes range from passive tagsand simple sensors and actuators, such as key tags, thermometers, valves, accelerom-eters, light switches or pulse meters, to complex systems such as smartphones, cars,or web Application Programming Interfaces, APIs.

Other components of the IoT are communication gateways and routers tying thenodes to each other or the internet (from here on these components will be referredto as ‘hubs’).

Customized Machine to Machine, M2M, solutions, often GSM-based, have beenin practical use for decades. The idea of building mesh networks, using Zigbee [1],CDMA [2] et cetera, is not new either. The fact that these implementations havegenerally been tailored to fit a certain customer and situation ensures that theywork well for their intended purpose.

The drawback is that they often follow a highly specialised architecture, andimpose strict demands on node compliance. This makes it difficult and costly toincorporate new nodes, but also to interact with other systems or adapt the networkto a new context.

Issues like the ones mentioned above initially drove this thesis work towardsinvestigation of possibilities and limitations associated with the IoT. The resultsare summarised in chapter two, frame of reference.

The IoT is typically exemplified by a hypothetical generic framework for datatransfer between nodes and a central hub (see Figure 1.1, 1.2 and 1.3).

This type of communication between nodes and hub requires agreed-upon stan-dards for communication medium, such as Zigbee, Wifi, Ethernet, GSM, or RFID[3], as well as middleware and data formats.

Diverse basic technologies needed to implement these types of solutions have ex-isted for a long time [4]. The challenge lies in incorporating heterogeneous hardware

1

CHAPTER 1. INTRODUCTION

Figure 1.1. Generic node with sensor and actuator

and software into a cohesive, flexible, resilient, reliable and secure product that alsofulfils the specific demands of the intended use case.

1.2 Purpose and definitions

The topic of IoT was chosen since it is an immature but rapidly growing field. Thegoal was to get an inkling of the future of distributed sensor applications. Thequestions that this thesis set out to answer were:

’What is the state of the art of the IoT?’ ’What kind of communication protocolwould be suitable for node-hub communication in such a system?’ and ’What coulda simple, autonomous irrigation system with sensor feedback look like?’.

The answers to the first two can be found in chapter two, and the last one isexplored in detail in chapter three.

Implementation of the irrigation system encompassed, among other things, selec-tion of a communication mechanism. Data needed to be exchanged between nodesand a central hub. Therefore, the thesis evaluates a number of relevant communica-tion protocols, or middleware, in the context of the type of distributed applicationsthat are typical for the IoT. Application characteristics that determine suitabilitycould be geographic distribution of nodes, reliability requirements and real-timedemands. The chosen middleware represent a great range of complexity levels andmechanisms. The resulting comparison forms a large part of the scientific deliver-

2

1.3. IMPLEMENTATION

Figure 1.2. Generic system: hub with one node

ables for this thesis work. This material is meant to function as a reference whenchoosing between communication protocols for distributed applications. Based offof this comparison, the most suitable protocol for this specific implementation waschosen.

The system hardware components, sensors, embedded computers, routers andthe like, should mainly be commercial off-the-shelf (COTS) products.

1.3 Implementation

One purpose of this thesis is to create a proof of concept for an irrigation system,consisting of at least one remote node and a hub (see Figure 1.4). The hub willexchange data with the node via Ethernet or wireless communication compliantwith the IEEE 802.11 standard. The irrigation system will be designed for use ina private garden, public park or agriculture of a drought sensitive crop like lettuce.This system would serve as an example application of the IoT.

The function of the system is autonomously optimising soil moisture levels whilereducing water consumption. Keeping the soil from drying out too much betweenwaterings is essential to ensure good cultivation results [5]. Drought sensitivitydiffers widely between crops, and can also vary between growth stages of a singlecrop. In case of a water shortage, it is important that correct priorities be made, orthe yield of sensitive crops will decrease dramatically. While an irrigation system

3


controlled by a simple timer may be good enough to fulfil basic crop needs, such asystem would likely waste water during cool and rainy periods, and it might stilllet the soil dry out too much when the weather is hot and dry.

Figure 1.4. Irrigation system flowchart

Closing the control loop by adding a moisture sensor will improve soil moisturestability considerably. The addition of an internet connection enables feed forwardcontrol based on weather forecast, which will save water by stopping irrigation ifrain is expected in the near future. It also makes it possible to survey and controlsystem status and behaviour remotely.

The implemented system will independently make irrigation decisions severaltimes a day, based on the combination of time of day, input from soil moisturesensors, and weather data from a web API. The gathered data will be evaluatedand weighted based on an algorithm input by the user.

The system should be autonomous, meaning that it should be able to operateand make decisions based on preset rules without user interference. It should alsobe able to adjust irrigation according to data gathered from different sources. Thesesources will, for the purposes of the prototype, be a moisture sensor and a weatherforecast service.

The user interacts with the system through a web based interface, which presentsthe user with configuration options, such as setting threshold values for differentparameters, as well as diagnostic and statistical system data. The user should also

4

1.4. DELIMITATIONS

be able to override the watering algorithm, turning watering on, or off, at any time.

1.4 DelimitationsThe goal is limited to a frame-of-reference literature study of the IoT, a comparisonof IP-based communication protocols or middleware, and one specific, non-genericimplementation as a proof of concept.

The frame of reference is focused mainly on application examples and technicalobstacles for the IoT.

The number of middleware in the comparison is limited to six. For a definitionof middleware as used in this report, see section 2.4.

An important aspect of the subject is which requirements can reasonably beimposed on hardware, such as sensors and actuators, for example in terms of batterylife, range, reliability, response time, and precision. This is excluded from the scopeof the implemented system.

No mechanics or specific node hardware are included, aside from the RaspberryPi embedded computer and Wifi antenna.

The software developed for the prototype supports only one sensor/actuatornode. The system could be implemented with an arbitrary number of nodes. Thiswould require some changes to the user interface and the part of the code thathandles hub-node communication.

There are other delimitations of the implemented system regarding reliabilityguarantees, encryption (of the communication between node and hub, as well asbetween the hub and the internet), error handling, and redundancy.

1.5 Structure of this reportThe report is divided into four chapters. The first chapter, Introduction, is followedby a Frame of reference chapter, chapter two, discussing technical and safety issues,possible architectures and application examples of the IoT. This chapter also in-cludes a comparison of six different communication protocols, as well as the stateof the art of networked irrigation systems. Chapter three describes the practicalimplementation of such an irrigation system, along with analysis and results. Thefourth chapter of the report, Discussion, provides answers for the research ques-tions, and details the results of the implementation work. The achievements andconclusions of the thesis work are summarised, and suggestions are given for futurework in the field.

5


Figure 1.3. Generic system: hub with several nodes

6

Chapter 2

Frame of reference: use cases and IPmiddleware for the IoT

2.1 BackgroundComputers have been connected to each other for many years through the internet.The next step in this direction involves objects (things) around us that have notpreviously been able to communicate remotely. The Internet of Things (IoT) is aconcept that involves the connection of various devices to each other, and/or tothe Internet. These devices will be referred to as nodes. A node can be a simplesensor or actuator, such as a thermometer, valve, accelerometer, light switch orpulse meter, or even an RFID, Radio Frequency ID, tag. Node can also refer to acomplex system such as a smartphone, car, or web API.

Other architectural elements of the IoT are communication gateways and routerstying the nodes to each other and to the internet. These components will be referredto as hubs, see Figure 1.2.

The term IoT was introduced in 1999 by Kevin Ashton [6]. It is closely relatedto the pre-existing concept of Machine-To-Machine (M2M), which could be seenas a subset of IoT. Often, the terms IoT and M2M are used interchangeably [7].However, when M2M first appeared decades ago [7], it was mainly in the contextof industrial applications, whereas the IoT has conceivable applications in virtuallyevery field.

M2M systems are usually

• Based on wired communication or cellular networks

• Used in industrial contexts

• Connected to a hub, but not to the internet1http://www.kpcb.com/blog/how-kleiner-perkins-invests-in-the-internet-of-things-picking-the-

winners2http://www.capgemini.com/blog/capping-it-off/2014/02/things-on-the-internet-to-the-

internet-of-things

7

CHAPTER 2. FRAME OF REFERENCE: USE CASES AND IP MIDDLEWARE FORTHE IOT

Figure 2.1. IoT illustration 1

IoT systems are typically

• Geared towards flexibility, scalability and usability

• Based on IP communication

• Integrated into other systems online

• Hardware platform agnostic, allowing for low-power, or even passive sensors

2.2 Application examplesIoT solutions are currently largely employed, and growing, in areas like smart build-ings, transport and infrastructure, industry, healthcare, safety and preparedness,and the military. Applying the IoT in relevant fields could vastly improve safety

8

2.2. APPLICATION EXAMPLES

Figure 2.2. An example of IoT architecture 2

and health for people all over the world. Many of these systems will, at least in thenear future, be attainable only for inhabitants of developed countries and for thewealthy. However, there are applications which could be used to leverage limitedresources in order to save lives and decrease suffering of people in the developingworld. Examples are basic health monitoring and natural disaster warning systems,infrastructural elements where a relatively minor investment could help many.

There are also considerable economic gains that come with increased efficiencyin fields like industry, transport, healthcare and agriculture.

2.2.1 Transport, logistics and infrastructureIn the field of assisted driving (see Figure 2.3), smart, sensing, interconnected vehi-cles and roads could minimize collision risks and enable smoother traffic planningand flow [3]. IoT in transport will enable dynamic control of origin-destination routechoice behavior for optimal traffic flow through an area [8]. It is also likely thatIoT type solutions will take the place of existing sensor systems at light-controlledtraffic intersections [8]. At present, the standard solution involves inductive loopvehicle detectors that keep track of approaching traffic and transmit the data onlyto the closest stop light via wired communication. Data exchanged between allintersections in an area could allow better decisions and decrease traffic congestion.

IoT might also be used for improved efficiency of the food supply chain. Keepingtrack of parameters like temperature and humidity during transport will help in

3http://www.driverlesstransportation.com/wp-content/uploads/2014/12/20110620_ITSDOT_0375_HIR.jpg

9


Figure 2.3. Smart traffic illustration 3

assessing and preserving the freshness of sensitive goods like fruit, dairy, and meat[3].

IoT systems also find increasing application in reliable supply and quality controlof drinking water. This is achieved through interconnected sensors at critical points,for example where contaminated water might flood drinking water reserves [8].

Smart grid is a new term in the context of M2M. When applied in power manage-ment, the grid assesses power consumption patterns through interconnected smartmeters, and regulates production and distribution accordingly. Peaks in power us-age can be cut by suggesting suitable times to run appliances, encouraged by powerproviders using dynamic pricing models [9]. Three task forces are currently devel-oping IEEE P2030 SG (Smart Grid) standards for power engineering, informationand technologies [9]. The technology is already in use for load balancing of energygrids [8].

2.2.2 Healthcare

In a near future, IoT systems in hospitals are likely to enhance identification andflow of patients, scheduling of physicians and procedures and inventory tracking[3]. Dynamic medical records, vital sign and status monitoring and centraliseddosage control will lead to improved patient safety [3] and treatment efficiency.These strategies could be used to improve and extend healthcare reach in developingcountries, making the most of strictly limited resources.

4http://vertassets.blob.core.windows.net/image/4f1cdc06/4f1cdc06-a44f-4748-9de9-0a87208761b8/iot_healthcareimage.jpg

10


Figure 2.4. IoT in healthcare illustration 4

It is estimated that the mortality from complications due to pregnancy or child-birth is about 2.5 percent worldwide, and in some countries it is the cause of deathfor as many as one in seven women. Furthermore, many preventable deaths in theseareas are caused by different forms of cancer, which are often curable if they arefound in time. Rohokale et al [10] propose a cooperative multi-hop model for sen-sor communication in areas that lack both a local hospital and a reliable internetconnection [10]. Multi-hop, in this context, means that data is relayed via one orseveral identical nodes towards a sink node, which is internet connected and makesdata available for remote viewing by a physician. In this scenario, each patient hasa personal sensor node periodically measuring parameters like blood pressure andblood glucose levels. Based on this data, the physician can quickly and efficientlyscreen a large number of patients and make informed decisions concerning follow-upand care.

Outside of the hospital, internet connected sensor networks might improve re-sponse times to health events like stroke or heart attack, where timing is criticalif the patient is to survive [9]. Even for less acute conditions, it could be possibleto decrease human suffering along with healthcare costs by suggesting adequatepreventive care based on sensor readings.

To enable physicians to monitor patients’ health status remotely in order to getcontinuity between visits , BANs, Body Area Networks, are being developed [9].

11


A BAN could be incorporated into a smart watch or a piece of clothing, or evenembedded under the patient’s skin.

2.2.3 Smart buildings

Figure 2.5. Smart home illustration 5

Homes and offices will likely be equipped with more advanced networked sensorsystems, see Figure 2.5. These could help inhabitants with anything from keepingtrack of RFID tagged personal items, like glasses and keys, to warning people andauthorities in case of fire or burglary [11].

The smart home or office could track and optimise factors like temperature, airquality and humidity, in living spaces as well as storage spaces and refrigerators.Tagged groceries could communicate their respective contents, expiration dates, andamounts, and suggest shopping lists along with recipes to reduce waste. [3] [12]

Creativity, productivity and comfort could be boosted by creating quiet zonesusing active noise cancellation.

Museums are another category where benefits could be reaped from automatedsensing and control. Here, IoT could be used for stabilising of environmental pa-rameters, and for security surveillance, around sensitive and precious pieces [3].

5http://www.mit.edu/~georgios/figures/iot.jpg

12


2.2.4 Industrial applications

Figure 2.6. Industrial IoT illustration 6

In production industry, while M2M solutions have been used for some time, IoTcould add more extensive real-time monitoring possibilities as costs, and sizes, ofsensors and tags drop. Following the flow through every link in the supply chain,from raw materials to finished product, enables traceability of individual goods andshorter response times to market events [3]. Aside from shorter lead times, trackingof every part might also give insight into workflow inefficiencies and shed light oncauses for quality issues.

Examples of factors that can be monitored include torque and vibrations, whichcan reveal a need for maintenance (e.g. modification of intervals between lubrica-tions and changing of tool tips), as well as timing factors that can improve through-put and utilisation for a bottleneck in a production chain.

Another area where there is room for improvement is sustainability. Recy-cling will be easier and more efficient if complex products are equipped with RFIDtags detailing the materials in them. Extended Producer Responsibility (EPR) isan environmental policy approach formulated by the Organisation for EconomicCo-operation and Development (OECD), where manufacturers are assigned moreresponsibility for handling their products at the end of their life span7. Traceabilitythrough RFID tags would help in the enforcement of EPR policies.

2.2.5 Military applicationsThe US Army uses an IoT system aiming to give an overview of friendly troops anddecrease the risk of friendly fire in chaotic battle situations. The GPS-based system

6http://www.iebmedia.com/images/art_images/IEB76_p32_35_2.jpg7http://www.oecd.org/env/tools-evaluation/extendedproducerresponsibility.htm8http://www.mpdigest.com/issue/Articles/2015/Jan/adi/fig1.jpg

13


Figure 2.7. IoT in the military illustration 8

is called Blue Force Tracker (BFT) and is mainly used for tracking of units andindividual soldiers [9]. It can also be used for communication via text messages,and for tracking materials in the battle field supply chain, the last steps of whichare otherwise very inefficient and costly due to rapidly changing locations and needs[13].

Future Force Warrior is a related project which also measures and communicatesthe biometric status of the soldiers, for example body and skin temperature andhydration [9] (for an illustration, see Figure 2.7).

IoT/M2M systems are also thought to become useful for the military within thefields of automated border surveillance and vehicle diagnostics and maintenance [9].

2.2.6 Safety and disaster preparedness

Distributed sensor systems could give warnings in real-time for natural catastropheslike tsunamis (see Figure 2.8), earthquakes, floods, volcanic eruptions and forestfires.

The remote sensor readings that IoT systems make possible can provide eas-ier access to various types of measurements from inhospitable environments, whereit would not be safe or practical to send a human observer. Some examples are

9http://newsimg.bbc.co.uk/media/images/40740000/gif/_40740353_warningsystem.gif

14


Figure 2.8. IoT tsunami warning illustration 9

pollution levels and wildlife counts on the ocean floor and in remote areas, or mon-itoring of radiation levels in and around failed nuclear reactors. After the tsunamiand subsequent nuclear plant disaster in Fukushima, Japan 2011, a few differentsensor networks have been set up to monitor variation of radiation levels aroundthe country [14]. The idea is to overlay a map with a mesh of frequently updatedradiation measurements, allowing authorities, residents and others to monitor localfluctuations in radiation levels, and their development over time.

Video enabled IoT is another field where great strides are expected to be takenin the next decade [8]. This technology could be used for security surveillance.

2.2.7 IoT in agricultural irrigation

Wireless sensor systems are not currently widely used for agricultural irrigation (seeFigure 2.9), but several such systems have been studied and deemed promising [15][8]. An estimated 70 percent of freshwater in the world is used for agriculture [15].A growing population puts increasing demands on crop yield, consequently urginga more rational use of water.

Irrigation has been used for thousands of years, the earliest evidence showingwater basins being used for irrigation in Egypt and Mesopotamia around 6000 b.c.

Automatic control has revolutionised almost all engineering fields, but it has not

10http://media.ofcom.org.uk/files/2015/smart-irrigation.gif

15


Figure 2.9. IoT irrigation illustration 10

yet had a corresponding impact on the field of agriculture [15]. Simple automatedirrigation systems use open loop control, simply dispensing a set amount of waterper square metre and day. This approach may yield acceptable results in terms ofcrop growth, but is likely less than optimal and may lead to a waste of freshwater,which is drained away.

The open loop irrigation can be improved upon by implementing sensors thatclose the feedback loop, for example soil moisture sensors. Continuous advancesin wireless technology facilitate this shift. Zigbee is a popular wireless standard,which, due to its relatively low power consumption, enables sensors to run on solaror battery power.

Several commercial irrigation systems exist, which work with thresholds for thefeedback signal and on-off control. They do potentially save water compared totimer based systems, provided that the thresholds are suitably set. Even morewater can be conserved if a rain sensor is implemented alongside the soil moisturesensor [15] [16]. This is the basic approach chosen for the present implementationwork described in the next chapter, with the addition that rainfall probability forthe next 24 hours will also be taken into account in the watering decision.

Parameters that could be used for an even more precisely targeted control strat-egy include plant measurements, such as sap flow, tissue water status, dendrometry,and stomatal conductance. These are promising, although there are practical hur-dles to overcome [15].

There are a handful of mathematical models, developed between the years of1989 to 2004, for water dynamics in the soil-plant-air system and crop yield. Thesemodels make it possible to simulate control strategies before applying them in the

16

2.3. COMPONENTS AND ARCHITECTURE OF THE IOT

field.Romero et al [15] describe how they implemented and compared two strategies,

one model based, and one PID controller. The results of the simulations wereadequate for both systems, however the model based strategy proved superior interms of following the reference. This effect was especially visible after predictedheavy precipitation.

2.3 Components and architecture of the IoT

2.3.1 Hardware

The nodes of the IoT can be divided into two groups: active sensor and/or actuatornodes, most commonly wireless, and passive nodes, like standard RFID tags.

Active wireless nodes generally consist of sensors, actuators, interfaces (typi-cally A/D converters [8]), power supply, an embedded processor and communicationhardware.

RFID comes in two varieties - passive and semi-passive. The passive tag caneasily be added to virtually any product, and has functionality equivalent to that ofa barcode. It is powered only by the energy from the radio signal transmitted by thereader. Passive RFID tags require a reader close by (the range is typically measuredin centimetres), since the reply signal transmitted by the chip is very faint. It canbe packaged as an adhesive sticker, or enveloped in plastic for applications like keysand access cards.

Semi-passive RFID units have some measure of internal power supply, whichenables longer range and processing capabilities. These fit better, functionality-wise,in the wireless sensor node category, as they are not strictly passive. NFC, or NearField Communication, is a growing technology, with similar functioning and uses toRFID. The range is even shorter, often to the point of requiring that transmitterand receiver physically touch. Many newer smartphones are NFC enabled.

Smart phones represent the powerful end of the node spectrum, and are easyto incorporate in IoT systems as nodes, or even as hubs. They generally containseveral sensors and are easy to connect directly to the internet, either over thecellphone network, or via an IEEE 802.11 [17] compatible access point. In addition,they can usually connect via bluetooth or even NFC to other phones, or a hub.The major drawbacks are that phones are unnecessarily complex and powerful, andtherefore expensive, to use as a simple sensor node, and that they are not optimisedfor energy efficiency.

Power supply

Wireless technologies, as a rule, require considerable amounts of power [12], and thisis especially true for WLAN. Wifi chip current is constant, rather than proportionalto data throughput [12]. Also, the peak current is higher than a typical coin batterycan supply [12].

17


Energy consumption in this context tends to be measured in power per bit [12].A lot of research has gone into energy efficient communication schemes [8]. Alterna-tives for power supply in wireless sensor nodes are using disposable or rechargeablebatteries, and the latter could be used in combination with energy harvesting mech-anisms, for example solar cell arrays [12].

Power over ethernet, where the ethernet wire is used both for data transfer andas a power source [18], is another possibility which could be useful for applicationslike routers, cameras streaming video, and point-of-sale systems (i.e. cash registers).

Power line communication (PLC) is sometimes used in the context of IoT, no-tably in power grid applications [12] [19]. IEEE 1901 is one of the standards forthis type of communication. The node is connected to the power grid, and thecommunication signal is superpositioned over the supply voltage.

2.3.2 Software

Ad-hoc, or spontaneous, deployment of nodes is the most common approach [8],and control of routing and the MAC layer is vital for scalability and robustness ofthe network. Regardless of node-to-node and node-to-hub communication style, thehub would typically need an internet compatible communication stack in order tofunction as a gateway between the local network and the internet [8].

The communication requirements for a given system differ depending on com-munication characteristics, like frequency and size of typical messages, and howcritical and/or timing sensitive the application is.

For a comparison of middleware for the IoT, see section 4 of this chapter.

Physical and data link layers

Wireless communication typically involves radio communication standards with sub-groups, like WPAN (e.g. Zigbee and Bluetooth), WLAN (e.g. Wifi) and variouscellular technologies.

Wireless Personal Area Networks (WPAN or just PAN), like Zigbee, Bluetooth,or 6LoWPAN, follow the 802.15 standard. The range is shorter than for WLAN, butthe power consumption can be several orders of magnitude smaller in applicationswith low data rates.

Most of the wireless sensor nodes on the market today are based on 802.15.4, astandard for low speed, energy conserving wireless communication [3]. The standarddefines only the physical and MAC layers [3].

Wireless local area networks (WLAN), like Wifi, based on the 802.11 standard,are convenient because of compatibility with existing networks. WLAN communi-cation is not as energy efficient as GSM or 802.15. WLAN was developed with astandard internet architecture in mind, where powerful devices, plugged in to wallsockets, share what is in this context to be considered as very large amounts ofdata.

18

2.3. COMPONENTS AND ARCHITECTURE OF THE IOT

Mobile cellular network technologies, like GSM, have been a popular choice forM2M communication in industrial settings. CDMA and UMTS (third generationof mobile network technology) are also in this category.

Network layer

Internet Protocol (IPv4 and IPv6) is used for routing and identification of deviceson the internet. 6LoWPAN, short for IPv6 over low power wireless personal areanetworks, is a version of IPv6 developed with the IoT in mind. 6LoWPAN basedIoT networks are currently used in many different projects aimed towards areas likeoptimisation of waste management, livestock monitoring and home automation [20].

Transport and session layers

TCP and UDP are the most commonly used technologies for use on top of IP, butthere are several other alternatives. They provide an abstraction layer that makesit possible for applications to communicate in larger chunks than IP allows.

UDP or equivalent protocol will be a better fit for the typical low bitrate, energyefficient IoT applications. It is connectionless, and has low latency and messageoverhead. However, for applications which require security or with larger amountsof data, like video streaming [21], TCP might be better suited.

Presentation layer

This layer is exemplified by HTTP, REST, JSON, msgbus, SOAP, et cetera. Forthis level, there are hundreds of communication protocols/middlewares to choosefrom.

Application layer

Applications will need to have very different features, depending on whether themain objective is smooth streaming of large data or, in the opposite end of thespectrum, shaving off nanowatts from the average energy consumption.

Computing power and memory resources at sensor node level varies from closeto none in passive or very low-power devices, to arbitrarily large amounts. The low-powered devices are therefore limited to small amounts of resource efficient codeexpressed in low-level languages, while nodes on the other end of the spectrum canhandle, independently process, and act upon large amounts of data and complexcode, expressed in any language.

Along with access to massive amounts of raw data come the challenges of makingsense - and use - of it. Data mining and handling strategies will be needed forlarger systems that gather lots of data. The data should typically be accessiblefrom multiple platforms, and presented and refined in such a way that it is easy forusers to digest and interpret.

19


2.4 Middleware for the IoT

Figure 2.10. OSI model illustration 11

Middleware is needed in the IoT in order for heterogeneous components to forma cohesive whole [22]. The types of middleware reviewed in this section provide anAPI, Application Programming Interface, for the transport layer and add the levelsof abstraction needed between that and the application. This enables a degreeof modularity which potentially brings systems closer to plug-and-play. For anillustration of the layers of abstraction in a TCP communication stack, see Figure2.11.

The choice of middleware partly defines the application. A limited feature setmeans limited liberties for the programmer while designing the system. On theother hand, ease of use is a relevant factor, especially in a smaller project and/orwhere a developer might have to put a lot of time into learning a specific protocol.Middleware demands on memory, OS, and CPU capacity also need to be consideredin relation to the corresponding hardware, as incompatibilities between protocol

11 http://gargasz.info/wp-content/uploads/2010/01/OSI_model_LAN.jpg12http://what-when-how.com/data-communications-and-networking/network-and-transport-

layers-data-communications-and-networking/

20

2.4. MIDDLEWARE FOR THE IOT

Figure 2.11. Illustration of the levels of abstraction in a TCP based commu-nication stack 12

and certain types of hardware or software architectures might disqualify a protocolright off the bat. For any safety critical system, reliability, real-time propertiesand guarantees built in to a given protocol will be the highest priority, beforecomplexity and cost. Middleware licenses range from free under Creative Commons[23] to quite costly. Six protocols was studied in detail, namely XML-RPC, SOAP,Websocket, ZeroC/ICE, CORBA and DDS. Websocket was used for implementationof the irrigation system described in the following chapter, mostly due to ease of use,programming language compatibility (Golang) and the full-duplex communicationcapabilities.

2.4.1 XML-RPC

XML-RPC fits into the application layer (layer seven) of the OSI model (OpenSystems Interconnection, see Figure 2.10), and provides an interface between webservices and clients. First developed in 1998, it is the predecessor to SOAP, Simple

21


Object Access Protocol, which will be discussed in the next section.The acronym XML-RPC stands for Extensible Markup Language – Remote

Procedure Call. As the name implies, it uses XML encoding for messages, whichare then sent using HTTP, Hyper Text Transfer Protocol. This means that XML-RPC requires an HTTP stack.

The MinML-RPC implementation uses 512 kilobytes of RAM13.XML-RPC is simpler to get started with than SOAP, since it has less encod-

ing and security options and does not support WSDL (Web Services DescriptionLanguage) [24]. As a result it is also limited in terms of functionality. As a compar-ison, XML-RPC is somewhat more complex than using the Representational StateTransfer, REST, architecture. REST or similar architectures could therefore bepreferable for simple CRUD (Create, Read, Update, Delete) operations.

XML-RPC provides reliable, synchronous communication, and has support for aplethora of programming languages. However, it uses about four times the amountof bytes for encoding an object compared to plain XML, which in turn, unlesscompressed, uses significantly more memory than for example JavaScript ObjectNotation (JSON).

2.4.2 SOAP

Like its predecessor, XML-RPC, SOAP belongs in the OSI application layer. It wasdesigned in 1998 by a team at Microsoft.

SOAP stands for Simple Object Access Protocol, and is a standard mostly usedwithin web services for sending messages over HTTP port 80. The SOAP standardis defined by the World Wide Web Consortium, W3C. SOAP follows a client-serverarchitecture, and works as the interface between web services and clients.

SOAP converts data to XML, which is quite verbose, before transmission. Ituses application layer protocols, such as Hyper Text Transfer Protocol, HTTP,Simple Mail Transfer Protocol (SMTP), Transmission Control Protocol (TCP) orJava Message Service (JMS) for message transmission. HTTP is the most widelyused, since SOAP is mostly used for web services, where HTTP communication isthe standard.

SOAP is more lightweight and easier to set up than CORBA, but more complexthan for example XML-RPC. It is operating system and language independent,and there are many libraries for different languages. Implementations exist, likeRomXOAP Embedded Toolkit, which claim to work on any 16-, 32-, or 64-bit pro-cessor, regardless of OS, TCP/IP stack and file system14. The lightweight gSOAP15

implementation has a 150 kilobyte total memory footprint.SOAP is generally firewall compatible. It is well documented, widely used and

time proven, and there is a lot of information about it available online.

13 http://www.xml.com/pub/r/371 2015-03-1814http://www.allegrosoft.com/embedded-soap 2013-06-2815http://www.cs.fsu.edu/~engelen/cases03.html#tth_sEc4 2015-03-21

22


Soap would not be an option for real-time applications, due to limitations inspeed and dependability. Message delivery using HTTP is best-effort, which meansthere is no guarantee that a given piece of data will be received. SOAP does notsupport transactions.

The downside to the firewall compatibility of SOAP over HTTP is that thereis more room for errors leading to security breaches, compared to CORBA forexample. When using SOAP, security needs to be implemented on the applicationlevel in order to obtain a satisfactory result16.

Source-code portability between SOAP implementation vendors is poor, withthe exception of Java implementations, for which SOAP has a predefined languagemapping.

2.4.3 Websocket

Websocket corresponds to the OSI session layer (layer five). It is a connection-oriented socket protocol, which provides a two-way communication channel viaTransmission Control Protocol, TCP, connection. Websocket message parsing addsa layer of abstraction to TCP, which only transmits a stream of bytes. Websocketis HTTP compatible, in that it has a compatible handshake protocol, which allowssocket connections to share a port with an HTTP web server. The HTTP server isnot involved in the websocket communication beyond the initial handshake.

Websocket was standardised by the Internet Engineering Task Force, IETF,in 2011, as an alternative to the HTTP mechanisms of polling, long polling andstreaming for providing full-duplex communication. Predecessors to Websocket, i.e.protocols for achieving full-duplex communication on port 80, include a numberof different technologies under the umbrella term Comet, also known as HTTPstreaming, as well as a handful of other names. Websocket generally provides easierimplementation and less HTTP header overhead than these techniques.

WebSocket Secure,WSS, is an encryption enabled version of WebSocket, analo-gous with the HyperText Transfer Protocol Secure, HTTPS.

The symmetrical bidirectionality of the websocket connection means that it lendsitself to applications which have frequent traffic that does not necessarily conformto the request-reply or publish-subscribe formats. As an example, websocket con-nections are often used for continuous server-client communication in online com-munities and games with frequent updating and/or real-time requirements17.

Getting started is comparable to setting up an HTTP web server and client18.There are a number of server and client implementations. However, far from all

implementations provide both server and client functionality. Though the subse-quent communication will be symmetrical, the server-client distinction is necessarywhile establishing a connection.

16http://searchsoa.techtarget.com/answer/Are-there-any-security-problems-related-to-SOAP2013-06-28

17 http://www.websocket.org/demos.html , http://demo.kaazing.com/livefeed/ 2013-06-2818 http://wickedlysmart.com/getting-started-with-html5s-web-sockets/ 2013-06-28

23


There are implementations specifically targeted at embedded devices19, likecWebsocket20, which can run on an Arduino, placing its memory footprint in therange smaller than 32 kilobytes.

Websocket allows for immediate updating without polling, and has less band-width overhead than HTTP (bytes rather than kilobytes)21. It also has lower latencycompared to HTTP, as there is no need to establish a new connection before eachmessage.

The technology is somewhat immature and untested. For example, there is arisk that security holes in Websockets communication could be exploited by hack-ers. Most firewall vendors have not addressed any of the potential security issuespertaining to Websockets, since it is relatively new and not nearly as commonlyused as HTTP22.

Websocket has no automatic timeout discovery. Hence, it might not be the bestchoice for applications with unreliable connections. Keep-alive messages have to besent if the traffic is low to prevent an idle timeout.

In order to guarantee reliability, the system would have to be implementedto send an acknowledge message for each received message, which would increasebandwidth usage23.

2.4.4 CORBA

CORBA covers the session, presentation and application layers of the OSI model(layers 5-7) [25].

CORBA, Common Object Request Broker Architecture, emerged in the mid1990s, and was one of the first standardised pieces of middleware for distributed sys-tems. The communication typically follows a client-server architecture, but CORBAdoes have publish-subscribe features as well24.

CORBA is widely used today, due in part to its getting a relatively early start.It is used in a wide array of applications, which are often safety critical, such as 3Gbase stations (third generation mobile phone communication), banking, air trafficcontrol, defence and aerospace programs (e.g. the Hubble space telescope), research,healthcare, robotics, data storage, and measurement systems.

CORBA is generally considered complex 25, and the learning curve is very steepfor new users26.

19 https://github.com/m8rge/cwebsocket 2013-06-2820https://code.google.com/p/cwebsocket/ 2015-03-1521 http://www.slideshare.net/ffdead/the-html5-websocket-api 2013-06-2822 (http://www.esecurityplanet.com/browser-security/html5-websockets-identified-as-security-

risk.html , http://www.infoq.com/news/2012/03/websockets-security 2013-06-28)23 (http://blog.kaazing.com/2012/02/28/html5-websocket-security-is-strong/ 2013-06-28)24 (http://www.ciaranmchale.com/corba-explained-simply/publish-and-subscribe-services.html

2013-06-28)25 (http://queue.acm.org/detail.cfm?id=1142044 , http://ovir.icp.ac.ru/corba/books/Teach14/ch01/ch01.htm

http://www.field-theory.org/articles/corba/ 2013-06-28)26 (http://queue.acm.org/detail.cfm?id=1142044 2013-06-28)

24


CORBA transmits data via the Internet InterORB Protocol (IIOP) throughTCP/IP connections.

CORBA was designed with a high degree of language and OS independencein mind. Many programming languages are currently supported by a number ofCORBA vendors, Java being the most popular. Other supported languages areC++, C, SmallTalk, Python, Perl and Ruby, and many more. There exists areduced-footprint version of the CORBA standard, called CORBA/e Compact Pro-file (from here on called CeCP, where the ’e’ stands for embedded). There are severalimplementations of CeCP which can provide real-time, deterministic execution ofcommunication or signal processing on a standard 32-bit microcontroller equippedwith a Real-Time Operating System, or RTOS. The CORBA/e Micro Profile is aneven smaller standard, which does not, however, feature real-time support27.

Its strengths are best used in large, complex systems distributed over differentplatforms (operating systems as well as hardware) and written in different pro-gramming languages. CORBA can provide security and high performance, but asan effect of its multitude of features, there would be a disproportionate amountof overhead in smaller, non-safety-critical projects. A system comprised of a singlecomputer, or limited to a single OS, would probably benefit from a more lightweightcommunication standard. A lack of experienced CORBA developers within theproject may be another disincentive to choosing the protocol.

CORBA gives low bandwidth use, compared to SOAP, for example, thanks toefficient data marshalling. It is well documented, time-proven and secure28. Otheradvantages include transaction support, persistence and location transparency. Im-plementations compliant with the RT-CORBA (Real Time CORBA) standard pro-vide hard real-time support. The lightweight version CORBA/e has a minimummemory footprint in the range of tens of kilobytes29.

ORBexpress is a CORBA implementation from OIS, that has a real-time version,as well as one that can be run on FPGA hardware (Field-Programmable GateArray)30.

2.4.5 ZeroC/ICELike CORBA, the Internet Communications Engine, ICE, spans the OSI levels 5-7,i.e. session layer, presentation layer and application layer.

ICE is a modern, object oriented protocol and API library, supporting multiplemodes of communication. It was developed at ZeroC in 2003 by some of the originalCORBA developers31. The design was influenced by CORBA, but ICEis much morelightweight32.

27 http://www.rtcmagazine.com/articles/view/100752 , http://www.corba.org/corba-e/ 2013-06-28

28 http://docs.oracle.com/cd/E13203_01/tuxedo/tux80/security/overview.htm 2013-06-2829 http://www.corba.org/corba-e/ 2015-02-1530 http://www.ois.com/Products/communications-middleware.html 2013-06-2831 http://www.zeroc.com/documents/ieee.pdf32 http://doc.zeroc.com/display/Ice/Ice+Architecture 2013-06-28

25


Like CORBA, ICE works well with heterogeneous node networks, where appli-cations run on different operating systems, and are implemented in different pro-gramming languages33. It uses Remote Procedure Call, RPC, and follows a publish-subscribe model of communication. ICE communication can be bidirectional, as theserver can send a callback message over the original connection created by the client.This feature is useful when traversing a firewall that is set to only accept outgoingconnections34.

ICE is used within areas like healthcare, research, robotics, traffic information,access control and surveillance, real-time process control, banking and trading35.

Setup is relatively simple and well documented for Windows, Linux, OS X, andSolaris. ICE also works on Android 2.3 or later. The embedded version, Ice-E,works on Windows Mobile 6 Professional as well as some versions of Windows andLinux36. ICE has language mappings for C++, C#, Java, Python, and Objective-C.On the client side, PHP and Ruby are supported.

It is well documented37, but there is little material about ICE online from othersources than ZeroC. It performs well in terms of round trip latency, scalability andoverhead generation compared to CORBA and .NET38.

The required memory size for an ICE implementation is a few hundred kilo-bytes39.

With exception of Ice-E, it supports SSL, IPv4 and IPv6. Ice-E supports onlyIPv4. Ice-E provides real-time support, while standard ICE does not.

The IceGrid version of ICE has grid computing support. ICE is licensed underthe GNU GPL (GNU’s Not Unix General Public License), but is controlled byZeroC.

2.4.6 DDS

Data Distribution Service, DDS, was developed specifically for distributed embed-ded systems and covers OSI levels four through seven. The first version of thespecification was approved by the Object Management Group, OMG, in 2003.

DDS lies between the application and the operating system within each nodein a distributed system, where it provides an application programming interface,API, for data-centric publish-subscribe, DCPS, with highly configurable levels ofquality of service, QoS. DDS avoids having a single point-of-failure by substitutingthe frequently used message broker architecture with a system where each publisherand subscriber shares meta-data about every other node in the network.

33 http://doc.zeroc.com/display/Ice/Ice+Architecture 2013-06-2834 http://doc.zeroc.com/display/Ice/Overview+of+the+Ice+Protocol 2013-06-2835 http://www.zeroc.com/customers.html 2013-06-2836 http://www.zeroc.com/icee/platforms.html 2013-07-0437 http://doc.zeroc.com/display/Ice/Ice+Manual 2013-06-2838http://www.ijcaonline.org/volume3/number11/pxc3871105.pdf,

http://www.zeroc.com/documents/ieee.pdf 2013-06-2839 https://www.zeroc.com/forums/help-center/1720-all-right-ice-hello-demo-such-size-memory-

usage.html 2015-02-20

26


DDS nodes can also be used within one single process, for communication be-tween threads. The process could be running on one computer, or distributed overseveral different ones40.

DDS is mainly used for distributed systems with strict QoS requirements. Thereis less setup needed than for client-server solutions in complex systems, and DDSscales well with the number of devices. Automatic failover is easy to implement,since all communication is peer-to-peer.

DDS is most commonly used with UDP/IP41, but it works with various transportmechanisms, including shared memory and specialised, non-IP networking technolo-gies like InfiniBand and StarFabric42.

MicroDDS is the smallest footprint implementation43, which is possible to im-plement on 8-bit microcontrollers with 2 kilobytes static random-access memory(SRAM) and 32 kilobytes read-only memory (ROM). Only publishing (not sub-scribing) is supported by MicroDDS. RTI Connext Micro works on embedded 16-bitARM microcontrollers, and provides baseline publish-subscribe functionality. How-ever, most implementations are intended for systems with pentium-class CPUs andmemory in the hundreds of kilobytes or more. The lightweight implementations canrun without an OS, while the others support an array of operating systems. In mostcases this includes at least Linux, Windows and VxWorks.

DDS is not well suited for synchronous communication, request-reply servicesand file transfer. It has limited support for transactions44.

Developers are given the possibility to control, on a per-message basis, configu-ration and QoS parameters for transmission as well as reception of messages. Thereare 22 QoS parameters available controlling, among other things, data availability,delivery, timeliness and resource consumption.

DDS is geared towards efficient bandwidth utilisation, and has fewer features andlow overhead in the main request path compared to middleware like CORBA. DDSis dynamically scalable and flexible, meaning that new network nodes with differentroles, as well as new message types, may be added or removed in runtime. Thecommunication can be one-to-one, one-to-many, many-to-one, and many-to-many,and DDS allows for configuring different nodes to have different subscription rates.This means that variation in connection speeds between nodes does not generallypose a problem.

Many implementations don’t cover the entire spec, and information on exactcoverage is sparse. Most implementations are poorly documented. As of now, twoopen source implementations exist; OpenSplice DDS and OpenDDS. Interoperabil-ity between different implementations has been an issue in the past, but this seems

40 http://www.omgwiki.org/dds/sites/default/files/DDS_Architectural_Overview.pdf 2013-06-28

41 http://blogs.rti.com/2011/03/30/tcp-transport-for-dds/ 2013-11-2542 http://www.rtcmagazine.com/articles/view/100492 2013-06-2843 http://www.icoup-consulting.com/microdds.html 2013-06-2844 http://portals.omg.org/dds/sites/default/files/Comparison_of_DDS_and_JMS.pdf, p28,

2013-06-28

27


to have been mostly resolved45.

2.4.7 Evaluation and recommendations for choosing middleware

For applications with hard real-time requirements, for example in the medical andindustrial sectors, CORBA and DDS are the only suitable candidates out of the sixprotocols that have been studied. They both give real-time guarantees and offerfine-grained control over quality of service parameters. For comparison, Websockethas no real-time guarantees, but is often used for example in timing sensitive onlinegames thanks to efficient, symmetrical communication that bypasses the typicalrequest-reply communication structure.

QoS for the four protocols lacking real-time guarantees, that is XML-RPC,SOAP, Websocket and ICE, is determined by the guarantees built into the under-lying transport mechanism, TCP being the most common.

The major drawback of CORBA and DDS is their complexity. In addition, DDSdocumentation online is scarce. For CORBA, there are a myriad implementations,and the majority don’t cover all the functionality described in the standard, and itis not a trivial task to figure out which one covers the needs of a specific project. De-velopers need to be experienced in order to achieve reasonable system developmenttimes. ICE, while inspired by CORBA and built in part by the same developers, iseasier to use, more flexible and has more language mappings. There is one completeICE implementation with a few variations, including one geared towards embeddedsystems.

XML-RPC andWebsocket, on the other end of the spectrum, are the easiest onesto get started with. However, these protocols, along with SOAP, were developedfor use in web applications rather than embedded systems, and all three need anHTTP enabled platform. This group is more suited for use in powerful nodes, likesmartphones, that have looser demands on power conservation and relatively largeramounts of memory.

The largest of the middleware, ICE and XML-RPC, require roughly ten timesmore memory than the lightweight versions of Websocket, CORBA and DDS, whosetotal memory footprints are measured in tens of kilobytes. A lightweight SOAP im-plementation falls somewhere in between the extremes, with a 150 kilobyte footprint.

For very small, simple nodes, there are implementations of DDS and SOAP thatcan run on embedded 16-bit systems. DDS even has an 8-bit implementation, albeitwith very limited functionality (only publish, no subscribe). DDS would be a goodchoice for an implementation with small, simple, battery powered sensors and strictQoS demands.

45http://portals.omg.org/dds/content/document/dds-interoperability-demo-rti-prismtech-twinoaks , http://portals.omg.org/dds/content/blog-feed-item/multi-vendor-dds-interoperability-here 2013-06-28

28

2.5. TECHNICAL ISSUES AND OBSTACLES

2.5 Technical issues and obstaclesThere is a lack of compatibility between the numerous communication paradigmsfor IoT devices. There is at present no generalised, easy to use framework whereusers can plug in any device. The plug-and-play solutions that do exist are notcross-compatible with other networking technologies [26] and applications. Settingup an IoT system is still rather complex, unless a package solution intended forthat certain purpose is chosen. Documentation, for protocols as well as hardware,is often scarce.

Trade-offs will have to be made in any battery driven implementation, wherefactors like communication capacity and processing power are weighed against bat-tery life. Specialised devices will be a preferred choice for many applications, whereenergy consumption per node is measured in micro- or even nanowatts at 3 volts (atypical voltage for the type of coin cell batteries that are often used in IoT nodes46).Since the market is divided into so many standards with slightly different demandson hardware and firmware, the small production volumes render specialised devicesexpensive.

Longevity and self-sufficiency of permanent installations will become an issue assystems grow larger - human intervention is expensive, and the failure rate of anindividual node multiplied with the total number of devices gives an inkling of themaintenance needs of a system.

Additionally, as will be discussed in the next chapter, developing high quality,standardised security solutions covering all layers of the OSI stack will be both achallenge and a priority.

The remainder of this section will be organised according to the layers of theOSI model, and will especially highlight some of the difficulties that standardisationefforts will meet.

2.5.1 Physical and data link layers

WPAN (e.g. Zigbee and Bluetooth), WLAN (e.g. Wifi) or cellular technologiesmake up this layer. This is the first crossroads of many in the communicationstack, and interoperability between the different options is very limited.

2.5.2 Network layer

The Internet Protocol version 4 (IPv4) is currently used for over 90 percent of therouting and identification of devices on the internet. The 32-bit address space,with over 4 billion unique addresses, has already run out. Its lifespan has beenextended through various workarounds, but in the long term IPv4 will not be ableto accommodate the billions of uniquely identified nodes of the IoT. The successorto IPv4 is IPv6, which has 128-bit addresses, giving 3.4 ·1038 unique identifications.

46http://www.em.avnet.com/en-us/design/technical-articles/Pages/Articles/Internet-of-Things-Designing-Sensor-Based-Devices-with-Coin-Cell-Batteries.aspx

29


2.5.3 Transport and session layers

TCP is resource expensive (in terms of battery, CPU, and memory) but full featured,while UDP is more lightweight but lacks a lot of features, like security, that arebuilt into TCP. There are also lesser known and used alternatives, which may beproblematic to use with restrictive firewalls that are configured to accept only themost common standards.

2.5.4 Presentation layer

There is a lack of standards and interconnectivity between the hundreds of alter-natives on this level, such as HTTP, REST, JSON, msgbus and SOAP. This meansthat the engineer tasked with implementing a system first needs to study some likelyalternatives in order to understand their capabilities and limitations, and to assesstheir compatibility with any existing hardware or software. Once a standard hasbeen chosen and built into a product, it will be cumbersome to change standards.One proposed step towards plug-and-play is semantic web, where data is tagged ina standardised way in order to make it easier to parse [27]. For example, a nodethat has temperature, air moisture and wind speed sensors might have a server thatpublishes measurements in the form of a human readable web page, where eachdata point is also associated with tags like geographic location, unit, type of sensor,altitude and time.

2.5.5 Application layer

Here also, there is a lack of joint effort between suppliers, which makes it hardfor consumers and customers to interconnect networks. This is a difficult problemto solve; applications in domains such as med tech, banking, public relations andsocial networking will have widely varying degrees of complexity and security levelsamong other things.

2.6 Security issuesConfidentiality and authenticity are critical criteria that need to be fulfilled beforethe IoT can be officially adopted by key entities like governmental institutions orlarge companies [11].

For the IoT to be useful, a trade-off will be necessary between user integrity andthe free flow of data for statistical and other purposes. There is a lot of research tobe done in the fields of encryption, access control and authentication, and “digitalforgetting” [11] [8]. The latter term describes the possibility for the original posteror owner to remove information or media from digital records.

The IoT architecture is typically sensitive to attacks, like man-in-the-middle,where the attacker intercepts and relays or alters the communication between twonodes by impersonating them both.

30

2.7. RESEARCH AND STANDARDISATION BODIES

Up until now, security for the IoT has mostly been implemented using ad hocapproaches [11]. The relatively small and cohesive applications and diverse tech-nologies have largely allowed the systems to fly under the radar. Several differentagents cooperatively implementing the IoT on a large scale and in safety criticalapplications, like in finance, the military or even healthcare, will make these systemsattractive and accessible targets for prospective attackers all over the world.

Personal integrity has already sprung up as an issue with the internet and smart-phones. Today, internet service providers and cellphone operators can access per-sonal data and communication sent over the internet as well as current location ofan individual while carrying a smartphone or similar device. In a future of ubiq-uitous networked sensors and tags, even more of that kind of information mightbecome available to many more parties, without the awareness or consent of thedata owner. As an example, at the time of writing, the Japanese company Hitachihas managed to produce a passive RFID tag that is only 0.4 x 0.4 x 0.15 millimetres[3], and could be surreptitiously included in almost any material or product.

2.7 Research and standardisation bodies

There seems to be a consensus that a lack of cohesive standardisation efforts im-pedes the development and adoption of IoT [6]. For example, the development ofRFID based IoT is moving slowly due to an excessive number of individual, smallstandards for frequencies, communication protocols and data formats [3]. Variousorganisations have developed standards, policies and recommendations for the IoT.Some of the most relevant standardisation activities include 6LoWPAN, ROLL,GRIFS, the EPCglobal framework, NFC, Wireless Hart and ZigBee. Among themost prominent standardisation bodies are Auto-ID Labs, ETSI, CEN, CENELEC,ITU, ISO, EPCglobal, and IETF.

Below is a summary of important organisations categorised according to geo-graphic area.

In the EU, the IoT European Research Cluster (IERC) have funded researchprojects on IoT. The European Telecommunications Standards Institute (ETSI)makes IoT-related policies [6] and has a Machine-to-Machine Workgroup [3]. TheEuropean Committee for Electrotechnical Standardization (CEN/CENELEC) andETSI have developed standards for some of the basic components of the IoT, likeWSN and RFID [6].

The Japanese initiatives “u-Japan x ICT” and “i-Japan strategies” explored usesfor the IoT [6].

The US based Information Technology & Innovation Foundation (ITIF) havegreat hopes for IoT influence on innovation and productivity. Their main focuslies on energy, broadband technologies, health information technologies and ruralutilities services [6].

South Korea has the “New IT Strategy” program for development of IoT infras-tructure [6].

31


The China Communications Standards Association (CCSA) and the China Elec-tronics Standardization Institute (CESI) are working on IoT standards. There isalso a project called “Sensing China” which focuses on object identification andoptimisation [6].

There are several international organisations working on IoT standards. Amongthese are the International Telecommunication Union (ITU), the Electronic ProductCode global (EPCglobal), the International Electro-technical Commission (IEC),the International Organization for Standardization (ISO), the Institute of Electricaland Electronics Engineers (IEEE), and Auto-ID Labs all over the world [3]. Workinggroups within the Internet Engineering Task Force (IETF) have developed two ofthe most promising standards [3], 6LoWPAN and ROLL.

32

Chapter 3

Implementation

3.1 Concept generation and evaluationAs has been described in section 3.2.7, IoT type solutions can be used to improveon conventional irrigation systems. Making irrigation simpler and cheaper whilereducing water consumption and optimising crop growth could make a great differ-ence, in developing and drought stricken countries especially. The purpose of theimplemented prototype is to control smaller-scale watering, with one sensor andactuator pair covering an area of approximately five by five metres. The system isintended to promote optimal plant growth while limiting wasteful water consump-tion. It is mainly intended for non-commercial use, and is not geared towards anyspecific type of crop.

Basic control system principles are applied in order to regulate soil water con-tent, with a moisture sensor providing a feedback signal. Weather forecast datafrom an external web service is used for feed forward control. The system makes ir-rigation decisions a few times a day or as often as once a minute, depending on userpreferences. The decisions are based on sensor input, rain forecast and user definedmoisture threshold values. Romero et al [15] showed improved system behaviour, interms of following a reference soil moisture value, using feedback control, comparedto the open loop type control systems (see section 3.2.7) that are most commonlyused today.

3.2 Requirements

3.2.1 FeaturesUser should be able to

• Setup system of one sensor and actuator node, and a controller hub

• Read moisture sensor node from web interface

• Configure system behaviour

33

CHAPTER 3. IMPLEMENTATION

• See logged weather, moisture and actuation data in graph form

• Select geographic location for weather forecast

• Control actuator (valve or pump) from web interface

• Switch actuator on or off for a set amount of time from web interface

• Set up moisture threshold values as a basis for actuation decisions

System should

• At regular intervals (at least four times every 24 hours), check soil moistureand rain forecast and compare them to threshold values, turning on wateringfor a period of time if irrigation criteria are fulfilled

• Turn on watering for a chosen number of minutes if user clicks manual overridebutton in the web interface

• Pause watering for a chosen number of minutes if user clicks override button

• Save minutes watered, soil moisture and rain forecast to log file at regularintervals

• Be remotely configurable via the internet

3.2.2 Performance and technology• Wireless (WLAN or WPAN) communication

• Hub and node powered via wall socket

• Communication protocol

– Low initial experience threshold for person setting up communication– Preferably bi-directional communication rather than classic client-server

or publish-subscribe (example: see section 2.4.3)– Technologies used should be IEEE 802.11 compatible– Acceptable built-in QoS guarantees

• System is not safety critical

• Soft real-time

• Closed loop control with long sampling times (minutes to hours)

• Capacity for sampling at least 1 time/minute and communication at least 4times/minute

• System should be able to reboot and resume operation without interventionafter power outage

34

3.3. HARDWARE AND SOFTWARE DEVELOPMENT TOOLS

3.2.3 Extended requirements• Advanced error handling

• Handling of maintenance/service

• Remote software updates

• Maximum litres/day setting

• User input warnings (0 or 100 percent target soil moisture, too low rain thresh-old)

• Failure indication

• Failure recovery

• Hub stops receiving data from weather station

– Try reestablishing connection periodically– Carry on using only sensor data– Alert user via web interface– Expected amount of rain defaults to zero

• Hub loses connection with node:

– Hub tries to reestablish connection periodically– Alert user via web interface– Alert user via mail

• Node loses connection with hub:

– Node tries to reestablish connection periodically– Independent actuation based on default schedule– Alert user via mail

3.2.4 User interventionUser intervention will be needed for any mechanical or electronic issue (faulty sensoror other components, faulty pump or valve).

3.3 Hardware and software development toolsThe idea of creating a generic, plug-and-play solution has led the design choicesin a platform and software agnostic direction. The hardware is intentionally over-dimensioned for the implemented functionality in terms of memory resources andprocessing power. Emphasis was put on hardware and software being readily avail-able, well-documented, and widely used.

35


3.3.1 Hardware platform

The general purpose WSN platform Z1 from Zolertia1 was considered for the nodehardware, along with a specialised operating system for the IoT called Contiki2. TheOS, however, was deemed too immature to use without first essentially contributingto finishing the Contiki project itself. It was not very well documented, and issuedcode examples were largely incomplete.

Arduino was another contender. It is cheaper, but not as polished and completeas the Raspberry Pi. There are operating systems for Arduino, but they are still inthe prototype stages. It also lacks the theoretical pros of the Z1 mote, which hasan even lower cost, and better energy efficiency, partly thanks to low-power Zigbeecommunication.

The Z1 was also developed specifically for IPv6 addressing. The possibility ofusing IPv6 was evaluated, but eventually, IPv4 was used instead. The corporatefirewall allotted to this project was not configured to allow IPv6 traffic, and thisproved difficult to bypass.

In the end, Raspberry Pi Model B3 was chosen, a small computer but withseveral operating systems available (any OS with a small enough footprint that iscompatible with the ARM processor architecture). The computer is compatiblewith almost any software and programming language, including high-level ones.It is also Ethernet and Wifi enabled. Any ARM compatible libraries included inDebian can be used.

The Raspberry Pi has connectors for keyboard and screen so that it can be usedas an ordinary PC, although with more limited resources in terms of memory andCPU. It also has several different kinds of ports, including USB and digital generalpurpose in/out (GPIO) pins.

Since development time is by far the biggest cost for small series products,using a general purpose computer, like Raspberry Pi, that supports higher levelabstractions, translates into a significant cost reduction for most projects at thebeginning of their lifetimes. The cost per unit might become an issue, however, ifthe system is to be mass produced.

The chosen platform was installed with a lightweight linux distribution, Rasp-bian4, which is the recommended OS for Raspberry Pi. Raspbian is an open sourceeffort by an independent team of developers. It is an adaptation of the Linuxdistribution Debian, optimised for running on the Raspberry Pi hardware.

Wifi connection is enabled by a generic Wifi 802.11 USB dongle and correspond-ing access point.

Moisture sensor data was simulated for the purpose of testing the code. Fora full-scale implementation including mechanics, a simple moisture sensor might

1 http://zolertia.com/products/z1 2014-01-152http://www.contiki-os.org/ 2015-03-013 http://www.raspberrypi.org/ 2014-01-20, http://www.raspberrypi.org/faqs 2014-01-204 http://www.raspbian.org/ 2014-01-20

36

3.4. SOFTWARE IMPLEMENTATION DETAILS

be used5. It has both analog and digital outputs, and requires a supply voltagebetween 3.3 and 5 volts.

3.3.2 Software

Websocket6 (WS) provides full duplex communication, meaning that following theinitial http handshake, both client and server can push data without first havingreceived an incoming request. It is well documented and not overly complicated toimplement, features that were weighed against fine grained QoS control and powerconservation abilities of other middleware detailed in the frame of reference. Asstated in that chapter, safety is another main concern for a growing IoT. Robustencryption and security features are built into the secure version of websockets,WSS. DDS, see section 2.4.6, was an interesting middleware alternative, with at-tractive features like fine-grained QoS control, but was too poorly documented.

The code was written in Golang7, a simple yet powerful language that the authorwas well acquainted with. JSON encoding was used for data marshalling. JSON isstandardised, well supported and documented, and is well integrated with Golang.The graphs shown in the user interface were implemented using Javascript8, which,like JSON, is Golang compatible and well documented.

3.4 Software implementation details

The software consists of three main parts: user interface, node application and hubapplication. The source code can be found at https://github.com/emelor/raspberry.

3.4.1 Using websocket in Go

The following ’hello world’ code example is intended to show the relative simplicityof setting up websocket communication between a server (hub) and client (node) inGo.

5http://www.uctronics.com/soil-hygrometer-detection-module-soil-moisture-sensor-p-1439.html 2014-01-15

6 code.google.com/p/go.net/websocket 2014-01-147 https://golang.org/ 2015-03-308 http://www.chartjs.org/docs/ 2015-03-30

37


Server code:

1 package main23 // Import l i b r a r i e s4 import (5 " net /http "6 " github . com/ g o r i l l a /websocket "7 " l og "8 )91011 // Set b u f f e r s i z e s12 var upgrader = websocket . Upgrader{13 ReadBuf ferS ize : 1024 ,14 Wr i teBuf f e rS i ze : 1024 ,15 }161718 func handleWS(w http . ResponseWriter , r ∗http . Request ) {19 //Upgrade from HTTP to Websocket connect ion20 conn , e r r := upgrader . Upgrade (w, r , n i l )21 i f e r r != n i l {22 http . Error (w, e r r . Error ( ) , http .

S ta tu s In t e rna lS e rv e rEr r o r )23 return24 }25 // Write a message to the c l i e n t26 e r r = conn .WriteJSON(map [ s t r i n g ] s t r i n g {27 "Message " : " He l lo world ! " ,28 })29 i f e r r != n i l {30 log . Fa ta l f ( "WriteJSON f a i l e d : \%v " , e r r )31 }32 }3334 func main ( ) {35 // Handle a l l r e q u e s t s to por t 8080 us ing handleWS36 http . ListenAndServe ( " :8080 " , http . HandlerFunc (handleWS) )37 }

38

3.4. SOFTWARE IMPLEMENTATION DETAILS

Client code:1 package main23 import (4 " fmt "5 " github . com/ g o r i l l a /websocket "6 " l og "7 )89 func main ( ) {10 //Send an HTTP r e q u e s t to s e r v e r and upgrade connect ion to

Websocket11 conn , _, e r r := websocket . De f au l tD ia l e r . Dia l ( "ws :// l o c a l h o s t

:8080 " , n i l )12 i f e r r != n i l {13 log . Fata l ( e r r )14 }15 // A l l o c a t e an empty hash map16 msg := map [ s t r i n g ] s t r i n g {}17 //Read JSON message from the connect ion i n t o the hash map18 i f e r r := conn .ReadJSON(&msg) ; e r r != n i l {19 log . Fata l ( e r r )20 }21 // Print message22 fmt . Pr in t ln (msg)23 }

3.4.2 User interface

The web interface, see Figure 3.1, is the main interface for the user. It displaysuseful information and allows the user to configure the system according to theirneeds. It allows the user to change general settings, like location and thresholdvalues, as well as to choose a time period for the history graph. The interfacealso displays logged data for the chosen period, current status for the system, andcurrent weather information.

Information displayed by the user interface

• Weather conditions

• Current moisture levels

• Logged data (moisture, rain, minutes watered)

• Current moisture and rain thresholds

• Current weather service URL address

• Options

39


Figure 3.1. Draft for the user interface. The graph shows minutes wateredsince last data point (blue), rain forecast (pink), and soil moisture (yellow).

Actions available via the interface

• Configure a system of nodes connected to the hub

• Configure desired moisture levels

• Set up other rules for actuation based on sensor values (such as maximum andminimum values for moisture)

3.4.3 Sensor node application

The node application (see Figure 3.2) registers with the hub and initiates a Web-socket connection. It logs moisture sensor data, and gets weather report data (mil-limetres of rain per time unit) and user configuration (threshold values, weatherURL, manual override of watering logic) from the hub. This happens any timethe weather report is refreshed, i.e. once every hour, or whenever new settings areinput through the web interface by the user. The node also saves weather data andnumber of minutes watered since last update in log files that can be requested by

40

3.5. ANALYSIS AND RESULTS

the hub application. At a set interval, the node makes an actuation decision andcontrols the actuator accordingly.

Figure 3.2. Node software flowchart. Blue ovals signify functions that are runin their own go routines (I.e. threads). The polygon shapes represent func-tions. The arrows are function calls, labeled, when applicable, with functionparameters. The websocket connection is represented by the red circle.

3.4.4 Hub applicationThe hub software (see Figure 3.3) gathers weather data from web service. Weatherdata and user configuration are then exported to the node. The user interface isdisplayed by the hub. Any time it gets a page request, it requests data logs forrelevant dates from node in order to draw the history graph.

3.5 Analysis and resultsA prototype of the system software has been produced. Simple testing has showedthat the system fulfils the basic functionality requirements. Features that have yetto be implemented are listed in section 4.5, Future work.

41


Figure 3.3. Hub software flowchart. Blue ovals signify functions that are runin their own go routines. The polygon shapes represent functions. The arrowsare function calls, labeled, when applicable, with function parameters. Thewebsocket connection is represented by the red circle.

42

Chapter 4

Discussion

4.1 Research focusThe work has focused on the state of the art for the Internet of Things, as well asthe relevant properties of communication protocols, and how they compare to eachother.

The irrigation application was chosen as an example of how the IoT could beused. In the context of this watering system, the largest part of the work revolvedaround system design choices; which physical architecture should be chosen, whatmechanical parts and hardware are needed? Which software architecture, and whichcommunication protocol should be chosen? Which control principles should be usedfor the irrigation task?

These questions will be answered in the following sections.

4.2 Features and behaviours of the implemented systemAn irrigation decision is made every 60 seconds, or once per period set by the user,unless the system is currently in a manual irrigation mode. Before a decision ismade, the soil moisture sensor is read. This value is compared to a threshold valueinput by the user, and the rain forecast is compared to a rain threshold. If both rainforecast and soil moisture fall under their respective thresholds, watering is carriedout for a set duration. If either of them exceeds the threshold value, watering willnot be carried out. The system sleeps for a set period of time before making a newevaluation.

The system has been verified by simple manual testing.

4.3 Hardware and software choicesThe Raspberry Pi gave the freedom to choose programming language, and enabledwriting of code that is not platform specific, except for code specifically related toI/O (In/Out) pins. However, adapting the code to a platform with considerable

43

CHAPTER 4. DISCUSSION

Figure 4.1. Irrigation decision logic

restrictions in memory and CPU power would most likely require starting fromscratch. Smaller, cheaper hardware is available that might be more suitable forimplementing a low-cost, very low-power system with many nodes.

The general tendency of companies and researchers implementing IoT-type sys-tems seems to be towards smaller, more energy efficient battery powered nodesutilising lighter communication technologies like 6Lowpan and Zigbee. Neither Wifinor Raspberry Pi allow for optimal energy conservation, but the power consumedby actuation, especially for a pump solution, arguably renders that point moot inthis case. Wifi is practical and simplifies installation of the system, since it can

44

4.4. CONCLUSIONS

often use an existing infrastructure. Using Wifi also makes it possible to use almostany PC as a hub.

Golang is simple to work with and has a thorough Websocket integration.

4.4 Conclusions

Below, brief answers will be provided to the questions posed in section 1.2.’What is the state of the art of the IoT?’The IoT shows great promise, it is growing in many fields, but some aspects of

the technology are still quite immature. Security, like encryption and authentica-tion, needs to be addressed, as well as standardisation of components and interfaces.

’What kind of communication protocol would be suitable for node-hub commu-nication in such a system?’

The answer to this question depends on hardware, energy efficiency demands,transport mechanism, amount of data exchanged, and system architecture amongother things. Trade-offs will have to be made in order to meet the requirements inorder of priority.

’What could a simple, autonomous irrigation system with sensor feedback looklike?’

For one answer to this question, see chapter 3.The IoT is a very large topic. Application requirements vary greatly; at one

extreme, a museum, for example, provides clean, dry, open spaces for a stationarywireless node network, and allows for a good wifi range. At the other extreme, atrain bogie sensor system has to withstand dirt, moisture, oil, and constant move-ment and vibrations. Wifi might not work at all because of the materials and thecramped geometry under the train. However, the literature shows that while theinfrastructure and standardisation work is still immature, one-size-fits-all solutionsare in the works for subsets of possible applications.

This thesis has achieved

• Frame of reference literature study

• Comparison of protocols

• Implemented an RPC on top of the Websocket layer

• Software for node and hub of an irrigation system

• Websocket communication of JSON encoded data between node and hub

Figure 4.2 shows a side-by-side comparison of the middleware studied in section3.4.

45

CHAPTER 4. DISCUSSION

Figure 4.2. Comparison of middleware/communication protocols for the IoT

4.5 Future workOne improvement on the system described in chapter 3 would be expanding the codeto handle several nodes in parallel. A few minor changes to the existing softwarecould produce a star network, where all nodes communicate directly with the samehub. Enabling a mesh infrastructure, where nodes also communicate with eachother, could be useful for extending the range of the system, but would require aconsiderable amount of work.

Other features that would be useful include more advanced error handling, alongwith an interface that provides more options (e.g. a daily water consumption limit)and feedback (e.g. failure indications and user input warnings for high and lowthreshold values).

Reliability guarantees, encryption of communication, and redundancy are otherimportant aspects to consider before deploying the system.

In order to carry out thorough testing, mechanics (i.e. moisture sensor andpump) would have to be included in the setup. After running the system completewith hardware for a few days or weeks, the algorithm could be tweaked to furtherimprove soil moisture level response and stability.

With the enormous amounts of raw data that a large-scale IoT will likely yield, itwill be an ideal context for further research on data mining and artificial intelligence.Developing software capable of discerning useful patterns in large collections of datapoints will likely be one of the bigger challenges in the process of harnessing the

46

4.5. FUTURE WORK

full potential of the IoT. Examples of pattern recognition could be finding the soilmoisture curve leading to optimal growth for a certain crop, or critical points in citytraffic where seemingly insignificant disturbances frequently trigger traffic jams.

The limits of the IPv4 address space will be increasingly obvious, and this willforce a transition to IPv6 within the next few years. The main factor that isstopping this development is the initial cost involved in adapting current softwareand hardware to IPv6 addressing.

IoT will find applications everywhere. One futuristic application which shouldnot be too far off, given the latest venture in the area by American company Google1,is self-driving vehicles on public roads.

As the IoT will tie the internet more closely to the physical world, there will bemore of the kinds of security and privacy issues that have already arisen. Securitystandards, regulations and legislation will inevitably lag behind.

The ongoing standardisation efforts described in section 2.7 are necessary forinteroperability and security reasons. However, as the IoT approaches technicalmaturity, the development will likely lead to several standards for each architec-tural element. This is due to the diversity of the potential applications and theirassociated requirements.

The development of standardisation points towards an IoT that builds on COTScomponents, with plug-and-play interoperability. In a few years, this might rendersetting up and using distributed systems as available to the general population aspersonal computers and smartphones have become already.

1 http://www.technologyreview.com/news/530276/hidden-obstacles-for-googles-self-driving-cars/

47

Bibliography

[1] Paolo Baronti, Prashant Pillai, Vince W.C. Chook, Stefano Chessa, AlbertoGotta, and Y. Fun Hu. Wireless sensor networks: A survey on the state ofthe art and the 802.15.4 and zigbee standards. Computer Communications,30(7):1655 – 1695, 2007. Wired/Wireless Internet Communications.

[2] Andrew J. Viterbi. CDMA: Principles of Spread Spectrum Communication.Addison Wesley Longman Publishing Co., Inc., Redwood City, CA, USA, 1995.

[3] Luigi Atzori, Antonio Iera, and Giacomo Morabito. The internet of things: Asurvey. Computer Networks, 54(15):2787 – 2805, 2010.

[4] Tom Seymour and Ali Shaheen. History of wireless communication. Review ofBusiness Information Systems (RBIS), 15(2):37–42, November 2011.

[5] Robert E. Sharp, Valeriy Poroyko, Lindsey G. Hejlek, William G. Spollen,Gordon K. Springer, Hans J. Bohnert, and Henry T. Nguyen. Root growthmaintenance during water deficits: physiology to functional genomics. Journalof Experimental Botany, 55(407):2343–2351, November 2004. PMID: 15448181.

[6] Shancang Li, LiDa Xu, and Shanshan Zhao. The internet of things: a survey.Information Systems Frontiers, 17(2):243–259, 2015.

[7] Jan Holler, Vlasios Tsiatsis, and Catherine Mulligan. From Machine-to-Machine to the Internet of Things : Introduction to a New Age of Intelligence.Academic Press, Jordan Hill, GBR, 2014.

[8] Jayavardhana Gubbi, Rajkumar Buyya, Slaven Marusic, and MarimuthuPalaniswami. Internet of things (iot): A vision, architectural elements, andfuture directions. Future Generation Computer Systems, 29(7):1645 – 1660,2013. Including Special sections: Cyber-enabled Distributed Computing forUbiquitous Cloud and Network Services amp; Cloud Computing and ScientificApplications — Big Data, Scalable Analytics, and Beyond.

[9] Chanakya Kumar and Rajeev Paulus. A prospective towards m2m communi-cation. Journal of Convergence Information Technology, 9(2), 2014.

49

BIBLIOGRAPHY

[10] Vandana Milind Rohokale, Neeli Rashmi Prasad, and Ramjee Prasad. A co-operative internet of things (iot) for rural healthcare monitoring and control,2011.

[11] Daniele Miorandi, Sabrina Sicari, Francesco De Pellegrini, and Imrich Chlam-tac. Internet of things: Vision, applications and research challenges. Ad HocNetworks, 10(7):1497 – 1516, 2012.

[12] Daniel Minoli. Building the Internet of Things with IPv6 and MIPv6 : TheEvolving World of M2M Communications. John Wiley & Sons, Somerset, NJ,USA, 2013.

[13] Tom Andel. The military’s war on invisibility. 59(1):26, 2004.

[14] Nobuo Nakajima. Radiation distribution measurements in fukushima prefec-ture. IEICE Transactions on Communications, E97.B(9):1752–1758, 2014.

[15] R. Romero, J. L. Muriel, I. García, and D. Muñoz de la Peña. Research onautomatic irrigation control: State of the art and recent results. Agriculturalwater management, 114:59–66, 2012.

[16] B. Cardenas-Lailhacar and M. D. Dukes. Precision of soil moisture sensorirrigation controllers under field conditions. 97(5):666–672, 2010.

[17] B.P. Crow, I. Widjaja, Jeong Geun Kim, and P.T. Sakai. Ieee 802.11 wirelesslocal area networks. Communications Magazine, IEEE, 35(9):116–126, Sep1997.

[18] Sanjaya. Maniktala. Power over ethernet interoperability. New York : McGraw-Hill Education, New York, 2013.

[19] Xavier CARCELLE and Thomas BOURGEAU. The Internet of Things: Con-necting Objects to the Web, chapter 4. Hoboken, NJ, USA: John Wiley & Sons,Inc., Hoboken, NJ, USA, 2010.

[20] Isam Ishaq, David Carels, Girum Ketema Teklemariam, Jeroen Hoebeke, FlorisVan Den Abeele, Eli De Poorter, Ingrid Moerman, and Piet Demeester. Ietfstandardization in the field of the internet of things (iot): a survey. Journal ofSensor and Actuator Networks, 2(2):235–287, 2013.

[21] Jie Xu, Yiannis Andrepoulos, Yuanzhang Xiao, and Mihaela van Der Schaar.Non-stationary resource allocation policies for delay-constrained video stream-ing: Application to video over internet-of-things-enabled networks. IEEE Jour-nal on Selected Areas in Communications, 32(4):782–794, April 2014.

[22] Soma Bandyopadhyay, Munmun Sengupta, Souvik Maiti, and Subhajit Dutta.Role of middleware for internet of things: A study. International Journal ofComputer Science and Engineering, 02(03):94–105, 2011.

50

BIBLIOGRAPHY

[23] https://creativecommons.org/.

[24] Sanjiva Weerawarana, Francisco Curbera, Frank Leymann, Tony Storey, andDonald F. Ferguson. Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging and More. Pren-tice Hall PTR, Upper Saddle River, NJ, USA, 2005.

[25] F. Bolton. Pure Corba. Pearson Education, 2001.

[26] M. Kolberg, E.H. Magill, and M. Wilson. Compatibility issues between ser-vices supporting networked appliances. Communications Magazine, IEEE,41(11):136–147, Nov 2003.

[27] Payam Barnaghi, Wei Wang, Cory Henson, and Kerry Taylor. Semantics forthe internet of things: Early progress and back to the future. 8(1):1–21, 2012.

51

internet of things818109/fulltext01.pdf · chapter 1 introduction 1.1 background the internet of...

Documents