Connecting Arduino Sensors to SensibleThings

(1)

Independent degree project - first cycle

Datateknik

Computer Engineering

Connecting Arduino Sensors to SensibleThings Xiao Guan

(2)

MID SWEDEN UNIVERSITY

Department of Information and Communication Systems (IKS) Examiner: Ulf Jennehag, ulf.jennehag@miun.se

Supervisor: Forsström Stefan, stefan.forsstrom@miun.se Author: Xiao Guan, xigu1500@student.miun.se

Main field of study: Computer Engineering Semester, year: Spring, 2016

(3)

Abstract

The Internet of Things is going to bring the Internet into every objects around us. To enable this ambitious idea, tiny devices have to be connected within the global Internet. Such devices are extreme small so it’s becoming a challenge to connect it to the Internet via TCP/IP. The thesis presents a way of connecting microcontrollers with other devices to jointly form a distributed network.

The thesis investigates and takes advantage of Internet of Things platform to implement the connection. SensibleThings is used as the platform. Limited by the hardware, microcontroller can’t run such a bloated platform. The thesis investigates diﬀerent microcontrollers characteristics and chooses Arduino as a representative in the work. Then it real- izes a bridge connection between Arduino and SensibleThings. Arduino is connected with a single-board computer, Raspberry Pi by a USB cable.

SensibleThings is running on Raspberry Pi to process the network messages. The channel throughput, latency and general usability are measured and interoperated. As a result, the data indicates this is a promising, flexible, cost effective network topology. Microcontroller can join a distributed network by the bridge. Comparing to dedicate hardware solution, the bridge connection cuts down the implementation difficulties and cost. The thesis also covers possible problems in such connection and proposes future work.

Keywords: Internet of Things, SensibleThings, Arduino, Microcontroller, Singleboard Computer, Serial Communication, USB

(4)

The Internet of Things (IoT) is the vision of connecting a network of many different physical objects to evolve a information society and enable more advanced services around people [1]. The term ”Internet of Things” itself is used as an umbrella keyword to cover complicated nature among embedded systems, wireless communication and Internet [2]. Currently, people around the world rely on the Internet for emails, surfing on the World Wide Web, realtime communication, E-commerce, social networks and many other tasks. The vision of IoT is a step forward to enable even small objects to be connected in the Internet to further enrich our source of information and perform various kinds of tasks. It’s foreseeable to have an Internet with such networks of objects as well as traditional Internet working together within the next decade. These networks of objects are built upon actuators, sensors, mobile phones, Radio-Frequency IDentifi- cation (RFID) tags and other objects [2–5].

IoT promises a new world by bringing contents and services close to us, emerging new interaction experiences and paving new applications. De- spite the IoT future images, it has to overcome numerous technical challenges and ethical issues. Since IoT is a vague concept, the regulations, actual deployed devices, technical difficulties and mitigations may diverge development during the IoT revolution. Generally, the challenges come to security, performance, distributed network, privacy, interoperability, legal problems and prices [6, 7]. Along with the difficulties, devices like smart phones, smart watches, activity tracker¹ and other intellectual development boards is becoming smaller and smaller which leads to a harder implementation difficulty while keeping the same level of functionality, privacy and security comparing to high performance devices.

1.1 Background and Problem Motivation

Within just few decades, laptop, smart phones, smart watches are becoming main stream. It’s evidently people want more and more smaller electronic products [8]. This trend also applies to the development of IoT.

Since this kind of small devices are becoming more and more popular, there is the need to communicate with other devices, otherwise it’s useless because one sensor can’t do much in a complicated system. The most powerful functionality always adds up to a conclusive complete service which can be the ﬁnal product selling by a company. In order to achieve building the IoT service, it’s obviously a necessity for a network solution to connect all components together. The network solution is however based on the existing technology. On the one hand, the components have to be physically connected. The connection can be done either by a cable or

1A life saving occasion because of a Fitbit activity tracker. h p://tinyurl.com/zgoel9n

(8)

wireless communication. Many components can be connected by diﬀer- ent technologies as long as it provides their functionality.

These complicated configuration of network is hard to manage for a software developer. Thus the research has so far produced IoT platform as a cornerstone for sharing information and managing the network. These platforms define the rules and construct a way to connect different components based on the rules. The platforms can run on many different devices such as smart phones, single board computers and desktop computers.

Moreover, the platform can provide existing functions as API for other developers to build new applications.

However, small devices are harder to be connected within an IoT network even with the help of an IoT platform. This kind of devices are called embedded devices sometimes since they have a dedicate purpose, limited functionalities and even a limited power source. Therefore, they only offer limited computation power rather than general purpose desktop computers. For this reason, the chance of these devices not having enough abilities to perform well with IoT platforms is high.

1.2 Overall Aim

Internet of Things is an ambitious vision to connect physical objects to existing Internet. However, new devices are becoming smaller and smaller.

On one hand, customers want smaller devices so they can bring them in the pocket. On the other hand, more devices are installed in a limited environment, for example, in the factories. Space and energy constrains on the size of devices. They may have to use a ba ery and wireless communication based on the fact that sites don’t have space for cables.

These constraints promote a harder implementation difficulties. Desktop computers give many more opportunities to application developers because of rapid involving computation power. The same trend also applies to smart phones. In a form of sense, we want IoT devices to be able to perform the same level functionalities as more powerful devices. With the limitation of size, a complex feature may be divided into different devices in reality. The devices can be connected within a distributed network. In coordination with an IoT platform, they can perform their own functionality together to achieve such a complex feature, even they are connected by wireless and used ba ery as the power source. Nevertheless, distributed network is hard to control by applications as well as higher implementation cost. IoT platform is used in such case to help building a distributed network with lots of different devices and provide basic application programing interfaces.

Although exists IoT platform, it’s still hard to connect a lightweight device within a distributed network. An IoT platform may be built upon interfaces the operation system provides. As a ma er of fact, a lightweight

(9)

device may not be able to run a operation system at all. In the other way, these sensors and actuators have to be connected in a IoT network to perform functions which requires them communicate with each oth- ers. As a conclusion, the IoT platform needs to make communicating with lightweight devices possible.

Therefore, the problem I will solve in this thesis is to connect a lightweight computer to the Internet of Things network by an IoT platform as well as evaluation about how the system performs together.

1.3 Concrete and Verifiable Goals

More speciﬁcally, the concrete and veriﬁable goals of the project are:

1. Reading three papers about what is Internet of Things and choosing an IoT platform in this thesis as well as three papers for each IoT platform.

2. Choosing a lightweight computer and reading ﬁve articles about it.

3. Finding two diﬀerent methods to connect the device with the IoT platform.

4. Implementing one of these methods to verify the possibilities for connecting small devices with an IoT platform.

5. Evaluate how well the system performs in terms of throughput and latency as well as general usability.

1.4 Scope

There are thousands of diﬀerent lightweight devices in the market based on their distinct use cases. There are also hundreds of Internet of Things platforms based on diﬀerent principles. Diversities contributes the development of IoT, but it also takes time to experiment with each. There- fore, because of the limited time, I will choose one lightweight device and one IoT platform. And the thesis are mostly focusing on connecting this lightweight device with one particular IoT platform. The majority focus is to realize and evaluate the connection. Thus the comparison within devices and platforms are moderate. The communication protocol within the devices are meant to demonstrate instead of many premium features.

And the evaluation only concerns the throughput in terms of the number of messages as well as latency. A working application, reliable data transportation and quality of service are beyond the scope of the thesis.

1.5 Outline

Chapter 1 gives an introduction about the Internet of Things and problems which will be solved in the thesis. Goals and scopes are deﬁned in

(10)

this chapter. Chapter 2 introduces related theories used in following chap- ters. Chapter 3 describes how I research the theories and how I implement the connection method. Chapter 4 details the steps of implementation as well as justiﬁed decisions along the development. Chapter 5 demonstrates evaluation results and a technical review to the methods. Chapter 6 sum- marizes the thesis and proposes future work.

(11)

2 Theory

The thesis aims to brining small computer to Internet of Things platform.

Naturally, it covers a huge area of ﬁeld. The major part will focus on the network protocol, hardware and relevant considerations in a scope of chosen devices.

2.1 Internet of Things

Internet of Things is to build a interconnect network for every ordinal objects instead of devices using Ethernet, such as popular widespread Personal Computer (PC). Those physical objects can be devices, vehicles, buildings, electronics, websites and sensors. IoT enables those objects to collect and exchange data, either by wired connection or wireless connection.

IoT objects are used to assist human by monitoring, operating and inter- acting objects which the human is not very good at. Although, they are built around the human experience. Therefore, small objects have to be connected wireless for convenience and environment.

Another fact is IoT is built upon Internet infrastructure. Internet connects diﬀerent sizes of network into a open global network experience. It al- ready comes into major part of world and becoming the cornerstone. In- ternet is mostly encompassed with TCP/IP protocol suites in which operates on diﬀerent levels of OSI model.

OSI defines 7 levels to abstract communication functions. The first layer, Physical layer is responsible for transmission raw bitstreams over a physical medium. For example, Ethernet, ISDN and RS-232. The second layer, data link layers helps transmission of data frames across two identities connected by a kind of physical layer. The third layer, Network layer, offers abilities to manage and connect to a multi-node network. IPv4, is one of important protocol si ing upon Network layer. It’s de facto standard for Internet. IPv4 becomes a standard around 1980 and provides 4.3 billion addresses approximately. Only twenties years later, due to rapid expansion of Internet, IPv4 address is basically exhausted. NAT and CIDR were introduced to ease the intense trend. For that ma er, IPv6 was regu- lated to offer next generation protocol for Network Layer. It has 3.4× 10³⁸ addresses. For enabling IoT, IPv6 has to be widespread. In fact, as of 2016, IPv6 nodes are slowly increased due to the price and many other reasons.

2.2 Internet of Things Platform

Internet of Things Platform is ambiguous as IoT itself is not a standard.

Nor does diﬀerent kinds of hardwares and softwares reach an consensus of implementation. Internet of Things Platform can also be called Internet

(12)

of Things Framework.

[9] would argue Internet of Things Platform may be referred as a system built on speciﬁc hardware and software components. The platform oﬀers cloud ability, deployment, maintenance and network structure. While In- ternet of Things middleware provides network services for the devices to enable common functions of IoT network. In the thesis, Internet of Things Platform are aligned with Internet of Things middleware in terms of that paper.

Internet of Things Platform helps the application connecting and managing devices, reading and monitoring devices and even oﬀering controls over network. With the platform, developers can build an distributed application across a variety of environments.

It can be an open source software running in diﬀerent devices. Those devices works in conjunction with each other to regulate a distributed network upon existing network infrastructure. Many cloud companies also promotes a cloud core for those platform, such as AWS IoT, Google Cloud Platform and Azure IoT. Thus a core backend service can achieve without a strong endpoint. On the other hand, many

The other kind of platform can be based on a local LAN network, such as Apple’s HomeKit.

Many diﬀerent protocols comes about to exchange the data. For example, XMPP is an open protocol and scales very well. REST can be used to present resources based on HTTP for web servers. MQTT builds a publish-subscribe mechanism to decouple the devices for bidirectional communication between the object and brokers.

By all means, being into Internet, one have to access a Internet Service Provider or becoming one of them. Some applications can be restricted in a local area network (LAN). The application can also sends out the data outside LAN to interchange the message. With proper encryption and network infrastructure, the messages can also be transmi ed securely.

Internet relies on TCP/IP stacks to route the packets from the source to the destination. World Wide Web is consumed by millions daily. It’s constructed by web resources and URLs. URLs will need to be translated back to the IP addressed so the client can initial the request. This is achieve by the Domain Name System. In a typical case, the web browser as a client will uses the IP address to initial the request by HTTP.

The mission of Internet of Things platform will be creating a fundamen- tal instruction to allow exchanging message over Internet or in the LAN.

Given the complexity of diﬀerent setup, the size of the nodes and proper- ties of network traﬃc, the complexity can be novel.

(13)

2.3 Single-board Computer

A Single-board computer is a computer built on a small circuit board, with microprocessors, memory, input/output and other features. It’s smaller than a computer, even with less computing power, but essentially it’s a computer of its kind.

2.4 Microcontroller

A microcontroller is usually a small computer with a single core processor, memory, and IO ports. Memory space are often integrated in the chip.

Such a small computer is used by embedded applications. Apart from general computers with many diﬀerent kinds of chips for multiple functionality, it’s designed and programable with embedded application for one solely purpose.

With this embedded context, it has limited resources. For memory Even so, it can’t run a operating system.

Microcontrollers are used in automatically controlled products and devices, such as automobile engine control systems, implantable medical devices, remote controls, oﬃce machines, appliances, power tools, toys and other embedded systems. By reducing the size and cost compared to a design that uses a separate microprocessor, memory, and input/output devices, microcontrollers make it economical to digitally control even more devices and processes. Mixed signal microcontrollers are common, inte- grating analog components needed to control non-digital electronic systems.

Some microcontrollers may use four-bit words and operate at clock rate frequencies as low as 4 kHz, for low power consumption (single-digit milliwa s or microwa s). They will generally have the ability to retain functionality while waiting for an event such as a bu on press or other interrupt; power consumption while sleeping (CPU clock and most peripherals oﬀ) may be just nanowa s, making many of them well suited for long lasting ba ery applications. Other microcontrollers may serve performance-critical roles, where they may need to act more like a digital signal processor (DSP), with higher clock speeds and power consumption.

2.4.1 Arduino

Arduino is a so called open source prototyping platform based on a microprocessor development boards. Unlikely the general purpose devices such as a home computer and smart phones, it doesn’t provide much computation power, dedicated user interfaces and softwares. Instead, Ar- duino only has a Atmel 8-bit AVR micro-controller, several digital and analog pins for physical components and a provision to download and run user applications based on serial port. A typical Arduino board only oﬀers 2 KB SRAM, 1KB EEPROM, 32 KB ﬂash memory which made it

(14)

incredibly hard to provide rich services to IoT network. Nevertheless, Ar- duino is quite popular among global communities of makers, especially many researches such as Mechanical Engineering. Inexpensive (less than 50 dollars), easy to program and the highly extensible Arduino kit contributes its prestige.

Arduino UNO is shown as Figure 2.1, only some parts of it are interested in the thesis.

Figure 2.1: An Arduino UNO board¹

Firstly, 14 digital pins are highlighted in red. Those pins can be either input or output according to program controls. The special PWM is Pulse Width Modulation. Some of digital pins can use this on-oﬀ pa ern to simulate analog output. 0 and 1 is used as transmit/receive pins of USB.

Secondly, power pins are highlighted in purple. It’s used for providing power source for external breadboard and ground. Thirdly, analog pins are highlighted in blue. Those pins accepts analog signals. Later, an 10- bit analog-to-digital converter is used to interprets the result which has a resolution of 4.9mV for 5V power supply. Fourthly, ATmega328p is highlighted in orange. It’s the core of Arduino board and also the micro- controller. It’s produced by Atmel and uses AVR. At 20MHz, it can yield 20 MIPS throughput. 2KB SRAM, 32KB ﬂash memory and 1KB EEPROM is included [10]. Fifthly, Atmega16U2 with TX/RX LED is highlighted in green. The chip is another slightly less powerful AVR micro-controller.

It’s programed and used to support serial communication over USB. It’s basically works as a universal asynchronous receiver/transmi er (UART).

1This ﬁgure is modiﬁed based on a photo uploaded to Wikimediaⁱas CC 2.0.

ihttps://commons.wikimedia.org/wiki/File:Arduino_UNO_unpacked.jpg

(15)

Two LEDs are useful for ge ing an clue of transmission. Lastly, USB port is highlight in brown. With USB cable connected, no power supply is needed.

for sharing sensor and actuator information on the Internet, most notably the SensibleThings platform. The SensibleThings platform can run on many diﬀerent devices such as smartphones, Raspberry Pi devices, and desktop computers. However, SensibleThings is far from the only IoT platform on the market [6][11].

The goal of this project is to enable Arduino devices to connect to Sensi- bleThings. The Arduino is however too weak to actually be a part of the SensibleThings DHT, hence some type of device need to act as a gateway.

Preferably a Raspberry Pi could act as this device, but a normal desktop computer might also suﬃce. Hence, this thesis will investigate what is the best way to connect Arduino sensors to the IoT. In detail the evaluation should also determine how well the platforms handles the Arduino sensor devices, in terms of scalability, response times, and overall quality of experience.

2.5 Serial Communication Methods

Serial Communication is one of the most important connection method for computers. It sends data at a per bit basis instead of sending several bits as parallel communication. At a glance, serial seems losing big on throughput over parallel. In practice, serial often outperforms parallel by much higher clock rate. That owes to cheaper implementation and less electrical problem.

There are two kinds of serial communication, one is synchronous, the other is asynchronous. Synchronous may be easier since it requires same clock rate. The “data is sent in a continuous stream at a constant rate.”

[12] Being time, the clock will drifts. So resynchronization is required.

Asynchronous might be another communication methods which requires the start and stop signal for synchronization. Before signaling, the cor- respondents have to agree several signaling parameters. They are full or half-duplex operation, the number of bits per character, endianness, bits per seconds, parity (none, odd or even), the number of stop bits, mark and space symbols.

Comparing to parallel communication, crosstalk happened less. Clock skew can be mitigated by un-clocked asynchronous serial communication links.

Many well-known application adopts serial communication including system bus, peripheral devices connection and peripheral bus, such as PS/2, USB, Ethernet, ISDN, Serial ATA, PCI Express and SPI.

(16)

Serial communications requires physical instruments. That includes different kinds of cables, scaling from jump circuits to complicated twisted- pair cable. Cable is strictly related with its protocol or bus design.

Baud rate is also called symbol rate. It’s the number of symbol changes, waveform changes, or signaling events, across transmission medium per time unit. It’s measured by symbols per second.

2.6 Communication Port (COM)

COM is the original interface on IBM PC-compatible computers. Several years goes by, physical COM ports are long gone on PC. But it appears on Unix like system as a virtual ports. That includes ports for Bluetooth and USB-to-serial devices.

A COM port redirector is a software designed for creating such virtual port. It provides remote serial access. In Unix like system, they may ref- erenced as a y port redirector.

2.7 USB

USB represents Universal Serial Bus, is an standard to connect peripheral devices by deﬁning cables, connectors and communication protocols used in a bus for connection, communication and power supply between computers and electronic devices.

It’s designed to uniform the connection within various kinds of computer peripherals, including keyboards, printers, external disks and portable devices. In practice, USB replaces old interfaces, such as parallel ports and RS-232 serial port.

USB consists of a host and a tiered-star topology. In the tree, a USB hubs can be used to connect more devices into single USB port. USB allows branching into a tree structure with up to ﬁve tier levels, 127 devices in total. Devices are linked though hubs. The hub built into the host controller is the root hub.

A physical USB device may consists of several logical sub-devices called device functions. A device with many functions is called composite device. The alternative is called compound device. The host assigns the address to each logical device.

USB device communication builds upon logical channels called pipes. A device can have 32 pipes (16 IN, 16 OUT). Stream and message are two types of pipe. A message pipe is used to transmit control which sends/get short commands and responses. It’s bi-directional. A stream pipe is a uni- directional. It’s used to transmit data using isochronous, interrupt and bulk transfers. Isochronous transfers often guarantees a data rate but with

(17)

possible data loss. Interrupt transfers is used for ge ing quick responses, i.e. keyboards. Bulk transfers uses all available bandwidth without bandwidth or latency guarantees [13].

2.8 Arduino Serial Communication

Arduino itself doesn’t have enough computation capability to run an operating system or a complete network stack. Thus it either pushed the work to other a ached device called Arduino Shield or it simply connects by a serial communication.

2.8.1 Virtual Serial Communication over USB

Based on the onboard converter chip, it’s easier for any hosts to talk within that serial port. Thus a application protocol is feasible to achieve tasks with Arduino. By connecting IoT platform within hosts, those host will become the bridge towards Arduino.

There are many ways to communicate with serial port on a operating system. For this thesis, it bases on RXTX which available on Java and a working Unix like operating system.

2.8.2 Arduino UNO's Serial Communication over USB

Arduino UNO board has a ATmega16U2 chip acting as a bridge between the computer’s USB port and the main processor’s serial port ². It runs a software called firmware. By rewriting the firmware, Arudino devices can appeared as MIDI devices defined by USB.

Figure 2.2: Virtual Serial Communication over USB

Since personal computer or Single-board computer don’t have a serial port at all. They will emulate a virtual serial port by using USB cable. This piece of software reuses the TCP/IP on the host machine. On Arduino side, that ATmega16U2 was programmed to be a USB-to-serial converter.

2h ps://www.arduino.cc/en/Hacking/DFUProgramming8U2

(18)

A complete breakdown of USB cable connection is shown as Figure 2.2.

2.8.3 GPIO

A General Purpose Input/output (GPIO) is a generic pin on the microcon- trollers to allow programs to control its input and output behavior. Rasp- berry Pi and Arduino both have GPIO.

2.9 Serial Communication Protocol

Data link and hardware is clearly deﬁned. But it doesn’t guarantee data integrity. Application may also needs a way to communicate in certain way. There are many existing protocol, like Firmata, Ardulink and ASIP.

Firmata is based on MIDI but Ardulink and ASIP is deﬁned as ASCII text.

2.10 Related Work

In here, the thesis presents some related work as the references.

2.10.1 Arduino Service Interface Protocol

The ASIP (Arduino Service Interface Protocol) is an software abstractions to expose small hardware components, such as sensors by micro-controller as services in order to achieve hardware agnostics protocol and reusing source code [14]. Further, it investigates the networking support by different strategies [15].

2.10.2 XBee

XBee is an coin sized modules to enable ZigBee network protocols. It supports a large quantitive devices, including Arduino and Raspberry Pi.

An environmental monitoring project uses this modules to achieve an advanced mesh networks [11].

(19)

3 Methodology

I will do my thesis work in Mid Sweden University. Students and pro- fessors at Mid Sweden University conduct many researches in Internet of Things as well as IoT platforms. I can ask and get support from them for this thesis. More speciﬁc, I also make use of following methodology to work on this thesis.

3.1 Learn Internet of Things

Firstly, goal 1 is to get preliminary knowledge about Internet of Things which helps further investigation and decision towards choosing an IoT platform. Internet of Things, however, is a vague term used to cover the universal research. In order to orient direction of this thesis work, I will start the survey in the beginning. I will search Google Scholar for ”Internet of Things” to ﬁnd out several most cited papers. After skipping through diﬀerent survey papers, I can dig into their references in university library about most interesting parts related to my thesis. In the end, I will limit my work in one IoT platform. Then I will read papers and documentation about the platform to understand the big picture which is helpful jumping around the code.

3.2 Choose Devices

Secondly, goal 2 is to choose device and to understand its underlying design. They are not strictly only presented in papers. However, because small development boards are meant to be sold in public, I will search Google for online news posts about development boards, especially in Gizmodo and SitePoint based on the fact that they are focused in this area.

After comparison, I will choose one device for further investigation. In particular, oﬃcial websites, tutorials, books, papers and other sources of information will be collected and studied in which they are public available online most cases.

3.3 Investigate Connection Methods

Thirdly, goal 3 is to investigate how to connect the device with the IoT platform. I will read the source code of IoT platform if available. Then writing sample applications helps understanding how it works. On the other hand, the device needs a careful examination. Physical components may be quite limited and many background electronic knowledge is required. The development boards are often sold by a company. Therefore, companies provide tutorials, libraries, sample applications and documentation. I will read the introduction and tutorials to know what the device it is. After I made a decision to devices for thesis, I will continue to look into sample applications and documentation to understand how to program

(20)

in this development board. In the end, I will build naive communication between the device and the IoT platform in order to get more knowledge about diﬀerent communication methods and evaluation aspects.

3.4 Implement Connection

Fourthly, goal 4 is to connect the device with IoT platform. In this step, I’ll read publications about IoT platforms. If it’s open source framework, I’ll read its code to see how it works. Related algorithm and papers will also be read. Later, I’ll look into the protocol and connection mechanism of this IoT platform. I will write example code to test the connection and understand its characteristics. In the end, I’ll look into how the bridge devices can proxy the connection for small devices in IoT platform. I’ll draw topology and ﬂow chart to understand how it works. Some more samples will be wri en to grasp the structure.

3.5 Evaluate Results

Lastly, goal 5 is to evaluate results in terms of performance and stability.

They are evaluated as throughput and latency. The throughput and latency both shows connection performance. While standard deviation and parameters are the metric to address stability. The throughput is measured by the number of messages exchanged. The latency is measured by the round-trip time. It’s a continuation to implementation. I’ll populate a ﬂow chart to initiate, test chosen characteristics. The data is collected and plo ed so that it can be easily understand. I will compare collected met- rics. Also, an sample application will be formulated to test how this can work in production. Then I can describe the overall experience, quantitive results.

(21)

4 Implementation

Internet of Things got the a ention from all technical communities since the concept is brought up. It’s been a wide ﬁeld for a long time. As a result of limited time, the thesis focuses on implementing one connection method to an IoT platform.

The software has to be build upon a specific hardware or a hardware architecture. In a sense of IoT, the software design have to consider the network architecture. Anticipating features and performance requirements. Those characteristics and demands are further used to build software abstractions and layers. Many solutions are emerging along the IoT evolution, including IoT platforms. The underlying obstacle is that IoT devices can be small as fingernail. The size constraints the computation power as well as hardware features. Or it’s ba ery powered and even passible so that it could be fairly hard to sense those devices. And hardwares in real world application may scales up to a data center. All those hardwares should be able to communicate with each other to form a distributed network to enable IoT. On the other hand, the framework development may restrict its features according to hardware features. Such trades-off and large distributed computing environment is extremely hard to develop application upon. One of among is to connect a micro-controller with a full-stack Eth- ernet capable Internet of Things platform.

Figure 4.1: Logical Distributed Network for Internet of Things

This thesis follows a top-down approach. It investigates the vision of In- ternet of Things and how diﬀerent hardwares can be structured by soft-

(22)

ware, for example, Internet of Thing platforms. Then it follows a comparison survey of IoT platforms, in which examines the diﬀerent approaches towards distributed network for small sensors. At last, the detail of micro- controller is derived and the connection is investigated. The logical structure of thesis will achieve is shown as Figure 4.1.

Internet of Things intends to connect physical objects to the Internet so that Internet can comes closer to people. Devices are becoming smaller and smaller. They also become smarter, especially the smart phone evo- lutionary. A number of public cloud services are developed to support diﬀerent services. Though, IoT still has a long way to go. Devices can be extremely small until ﬁngernail size to be integrated with daily objects. Thus researches want to achieve communication over the Internet since it’s the most powerful and open network solution for connectivity.

When low cost, high performance and low power consumption have to be achieve at the same time, the implementation diﬃculties can be novel.

4.1 Devices

Given the huge amount of available devices, the thesis focuses on the representatives. Production devices might be compact in size and integrated with highly-customized chips which dramatically changes the performance and features of a board. Thus, the thesis is not considering different kinds of add-ins. Their performance and usability may need to be measured on its own. For example, Google accelerates their machine learning algorithm with an custom chip in which the performance will be quite diﬀerent than general purpose hardware. In a way, micro-controller or single-board computer are designed and work in a special application.

But the thesis is concerning general hardwares instead so the conclusion can apply to special hardware. Therefore, those many devices are categorized into 3 categories, micro-controller, single-board computer and computer (Personal Computer or Workstation). Their hardware and software capability is compared as Table 4.1 shown. Micro-controller and Single- board computer may be called embedded devices sometimes.

Table 4.1: Comparison of 3 Major Kinds of Digital Devices

Device Microcontroller Single-board Computer

Performance Slow Average Fast

Power Low Middle High

Operating System No Yes Yes

Customizability High Average Low

Board Design Vendor Vendor Standard

Peripheral Size Tiny Small All size

Representative Arduino Raspberry Pi PC

(23)

4.1.1 Computer

Personal computer has widely accepted for two decades. In general, it can be either a laptop or desktop computer, even a workstation. They are much more powerful than single-board computer in many senses. Lying between of single-board computer and computer, it may has many more emerging devices, such as smart phones and tablets. In the thesis, a Mac- Book Pro is used as the computer. The model is described in Appendix B.

4.1.2 Single-board Computer

Single-board computers can be small as credit card. But it’s also strong enough to run popular general-purpose operating system, for example, Linux. It may provides diﬀerent kinds of peripheral port for communication, especially HDMI, USB and Ethernet. Some of them may support GPIO for direct sensor installation and usage. Additional computation power, small size and peripheral ports made the single-board computer much suitable for IoT development. Single-board computers can be helpful to be the bridge or proxy device for micro-controller given the fact it has enough computation functionality to run the operating system and Ethernet protocol stacks. A software framework can be deployed to the devices and push the messages to micro-controller accordingly. Then, the message can be collected by the device and forward to the network. Micro- controller in this kind of bridge can either be transparent as sensors and actuators or be public as a node where it delegates all sorts of network protocol to the bridge.

There are many kinds of single-board computers. VoCore is a Ethernet port sized block single-board computer which runs Linux and features the WiFi connection¹. Another kind of 15 US dollars single-board computer, Pine64 features the 64-bit microprocessor².

Raspberry Pi is used as the single-board computer for the experimental evaluation. Raspberry Pi is a series of single-board computers which becomes popular among the hackers, scientists and engineers since 2012. It has a great community to ask questions and solutions to many problems.

It’s no large than a credit card but provides many exciting functionalities. There are a variety of models available featured in diﬀerent size of RAM, ARM CPU, peripheral ports and even graphical chip. The thesis uses a Raspberry Pi Model B. It has an single core ARM11 microprocessor running at 700 MHz, 512 MB RAM, 2 USB 2.0 ports and Ethernet which is powerful enough for this thesis. And its size is nether big to bring it around nor small to operate. The model is described in Appendix B.

1http://vocore.io/store/index

2http://pine64.com/

(24)

4.1.3 Microcontroller

Micro-controller usually consists of central processing unit, volatile memory, ﬂash memory, clock generator and some input/out pins.

It’s low-level so every peripheral devices might need to be programmed carefully. Additional hardware components are connected by digital or analog pins. Some components may need more than 1 pin. Those hardware components are driven by the micro-controller directly. The software is also low-level. It may interactive with hardware interrupts or wrapped as input/output functions to the application. Without program- ming correctly or connecting devices by wrong parameters may result in unsuccessful setup or even destroy the device physically.

Micro-controller has extremely low power consumptions. Thanks to its limited functionalities, the chip may be speciﬁed to the application. For example, motes, sensor nodes are widely adopted by wireless sensor network. MICA2 is one type of mote which features an embedded system, TinyOS and wireless communication. TMS1000 developed by Texas In- struments in 1974 for the electronics industries which features 256 bits RAM and 1K bits of RAM. Though beyond the scope of the thesis, other companies may oﬀer additional modules to provide extra features. For example, XBee board by Digi is only a coin size in which it supports Zig- Bee network protocol.

In the thesis, Arduino UNOv3 board is used as the micro-controller. Being released for many years and enjoyed by scientists, engineers and hackers.

It is a widespread and enjoys a global community to share the knowledge. The community also grows with increase number of devices. Ar- duino boards typically uses a AVR micro-controller with different sets of configuration. Each one of them is customizable and the hardware like sensors can be directly connected to pins or a breadboard. Libraries, protocols and researches are built around the projects are huge. The size of the board is rather big comparing to other micro-controllers. However, it’s be er for prototype and research where hardware and software re- configuration is needed. It’s not either fast than other micro-controllers with an AVR micro-controller at 16 MHz and 2 KB SRAM. Unlike production microcontrollers, Arduino can be power hungry as it’s not design for production usage. Other production microcontrollers may have different strategies to reduce power drain. But Arduino offers the needed features and easier to debug thus it’s a representative example of microcontrollers. Thus the measurements taken in the thesis is comparable to another micro-controllers.

Arduino has a number of devices now in which there is a popular model called Arduino UNO. The current version of Arduino UNO is ver3. It might be called Genuino UNO outside the United States.

(25)

4.2 Internet of Things Platform

Computers and single-board computer are capable of running an operating system thus the requirement of TCP/IP protocols are guaranteed to be supported. While micro-controllers may not be supported depending on their chip design. In a real working scenario with many devices joining the distributed network, one device can be in charge of communicating with one or more micro-controllers. All incoming and outgoing messages, other maintenance overhead, deployment and continuos monitoring can be delegated to the single-board computer.

In this thesis, an IoT platform will be chosen to build such an network backbone for demonstration. But it will also compare some other solutions. IoT platforms or IoT frameworks can be characterized as cloud- based, web-based and fully-distributed. They can also be categorized based on its license, proprietary or open-source. ThingWorx, Xively and Sinsi- bleThings are 3 IoT platforms to be examined.

4.2.1 ThingWorx

ThingWorx builds a platform including Machine-to-Machine (M2M) and application lifecycle management features. ThingWorx can be deployed on the cloud or embedded devices. ThingWorx oﬀers visualized development environment and semantic data storage which features their model driven development. REST endpoints, MQTT, CoAP, WebSockets are supported transportation mechanism [9, 16, 17].

4.2.2 Xively

Xively is a PaaS IoT solution with provided SDK. Wireless serial gateway can also join the network. Device communication is done by REST endpoint but no deployment and management tools are provided. MQTT and websockets are supported. [16–18]

4.2.3 SensibleThings

There are multiple IoT platforms to be chosen. For my purpose, I would choose one can run upon small single-board computers in which it should has ability to run a Unix like system.

SensibleThings is a fully distributed and open source IoT platform. It doesn’t have a single point of failure and all nodes are equal. The underlying DHT supports Kelips and Chord algorithms. The kelips will be used.

All tests will be performed in a LAN environment. Actual communication is implemented upon transport layer protocols. It supports TCP, RUDP and proxy. RUDP builds upon UDP protocol which features fragment, rate control and acknowledgment to provide reliability. Proxy is used to exploit NAT in the router which sometimes prevent the connection.

(26)

Figure 4.2: SensibleThings DHT

IoT platform usually oﬀers communication abilities among diﬀerent networks across LAN and Internet. While micro-controller may not run an operating system at all. Hence, it’s almost always connected with another devices as backend which simply pushes communication among the network to this device. This pa ern will be called bridge.

By using a so called bridge, Raspberry Pi will run as a SensibleThings node. Arduino delegates all kinds of network requests to Raspberry Pi.

Arduino itself can connect to Raspberry Pi in numerous ways. Arduino can appear as transparent in the SensibleThings network by registering its pins or hardware components as UCI. UCI is an arbitrary string stored across the DHT represents a sensor or an actuators. Physical IP address is also presents in the underlying dissemination core of SensibleThings. But it’s transparent to the application scenario.

4.3 Arduino Serial Communication

In such a bridge, Arduino has to be connected with Raspberry Pi. The most easy way is the serial communication. Serial communication over- comes many disadvantages of parallel communication to become main- stream. It’s cheaper and easier to control.

Arduino has adopts serial communication enabled by ATmega16U2 chip which creates the serial port virtually by USB cable. The jump circuits can be used to connect 0/1 digital pins to GPIO in the Raspberry Pi which is similar to the USB scenario. Other communication depends on Arduino board conﬁguration. Or it’s extended by hardware modules, so called Ar- duino Shield. They can be directly connected to pins for Ethernet, Blue- tooth, ZigBee support. Serial communication over USB will be the tested

(27)

communication technique.

Serial Communication is one of the most important connection method for computers. It sends data at a per bit basis instead of sending several bits as parallel communication. At a glance, serial seems losing big on throughput over parallel. In practice, serial often outperforms parallel by much higher clock rate. That owes to cheaper implementation and less electrical problem.

There are two kinds of serial communication, one is synchronous, the other is asynchronous. Synchronous may be easier since it requires same clock rate. The “data is sent in a continuous stream at a constant rate.”[12]

Being time, the clock will drifts. So resynchronization is required. Asyn- chronous might be the alternative way to send the data. It consists of data, start bits and stop bits which doesn’t needs to be synchronized.

Arduino boards have at least one serial port (UART or USART). Digital pins 0 and 1 are used as receiving and transmi ing port. The board has a USB connector for the connection. Arduino Uno in particular has a At- mega16U2 programmed as a USB-to-serial converter instead of FTDI USB- to-serial driver chip on prior models. But the UART TTL (5V) serial communication is enabled by main chip, ATmega328 over digital pins 0 and 1.

Using a USB cable on Arduino should have the best possible connection performance which can be used as a baseline reference. To enable UART, both ends have to programmed accordingly. Based on the characteristics of UART, the sender and the receives needs to agree upon on Start, Parity and Stop bits. The transmission between two opponent can be full-duplex.

4.3.1 Protocol

UART represents physical layer towards data link layer in the OSI model.

Since Arduino is low level, many protocols are developed to reduce the programing diﬃculties, such as Firmata and ASIP.

In the thesis, Ardulink protocol will be used to build the communication.

Ardulink protocol deﬁnes several commands as URL for clarity. It’s a text-based stream protocol.

Table 4.2: Example Power Level Switch Command

Bytes 0 1 2 3 4 5 6 7 8 9 10 11

Stream a l p : / / p p s w / 9

Explanation Stands for Ardulink Toggle Pin Pin

Component Protocol Command Pin

A example power switch command is shown as Table 4.2. It toggles power pin a ached at 9. There are several commands available in Ardulink protocol which all composite as the same as table shown. If a device wants

(28)

to receive the message from Arduino, listen commands have to be used in the front. A typical message will be around 11 bytes.

Other protocols are also available. Firmata library provides a message protocol based on MIDI. While ASIP claims a smaller memory compared to Firmata. It works ﬁne as of Python client but is rather wrong as of my Java client implementation. Such diﬃculties are occurred many times as the text steam starts to be out of order and the protocol and device behavior goes wrong. This error is not recoverable for Arduino.

Nanopb is a minimized C implementation of Protocol Buﬀers aimed at 32 bit microcontrollers. As its design goal, the model might be reusable for microcontroller but it also requires a number of processing power and memory footage³.

4.3.2 Deployment

Arduino is built upon a AVR micro-controller. Its executable program is not huge but rather small as less than 2 MB. While dynamic configuration of pins and hard-to-read text description like ASIP, a meta-compiler seems feasible to generate firmware. Single-board computer usually have enough power to compile and upload the firmware. As the time limitation, this is a future work.

4.4 Evaluation

A direct connection is conducted. Then the bridge set-up will be used to test IoT scenario. Hereby, the thesis tests the throughput and latency. The throughput is deﬁned as the message being transferred per second. The serial communication is full-duplex. So messages sent and received are counted separately. The latency is deﬁned as round trip time.

4.4.1 Direct Connection

In the direct connection, the USB cable is used to connected between Ar- duino and Raspberry Pi or a computer. In each computer, a SensibleThings platform is running as a kelips bootstrap node at their own IP address.

Only 1 node is presented in the network.

The throughput and latency is evaluated. The throughput is defined as the number of messages per second for 120 seconds. The link channel is firstly set-up and running for 10 seconds to prevent connection failures. After a short break, the computer will start to flood the Arduino by flipping digital pin at 9 which connected to a LED. Value changed event at 9 and analog event are generated from analog pin 0. Though, the analog pin is connected with a knob. ADC will yield some twitching when quantize its volts which simulates a sensor. But the general idea is to exhaust the link

3http://koti.kapsi.fi/jpa/nanopb/

(29)

to see the overall throughput. Sending and receiving is done by diﬀerent threads. The hardware setup is shown as Figure 4.3.

Figure 4.3: Direct Connection for Throughput Test

For testing round trip latency, I watched the event happened at digital pin 3. While the computer sends the message to pin 9, it will generates the output to pin 3 which will generate the digital pin value changed event.

The message is transmi ed back to the computer. The sending moment and the received moment are used to get the round trip time.

Figure 4.4: Direct Connection for Latency Test

4.4.2 Bridge in SensibleThings

In the bridge connection, the throughput and latency is evaluated. Their deﬁnitions are regulated as the same fashion as direct connection. Ex- cept, the topology is more completed. The USB cable is used to connected

(30)

between Arduino and Raspberry Pi. This is the same as previous test.

Raspberry Pi connects to the router as well as a computer. SensibleThings platform is running on both computers. But a kelips bootstrap node is now located in the laptop.

The message is sent from the laptop towards an UCI registered by Rasp- berry Pi. Once upon a message, Raspberry Pi forwards the message in Ardulink protocol to Arduino and also transmit it back towards the laptop. This process implements the bridge connection for Arduino in Sensi- bleThings. The network topology is shown as Figure 4.5.

Figure 4.5: Bridge Topology

The detailed hardware and software environment is described in the Ap- pendix B.

4.5 Sample Application

The sample application is built to examine the usefulness of design. A Sen- sibleThings network is constructed with Arduino, Android App, Rasp- berry Pi and the gateway in a laptop. The structure is shown as Figure 4.6.

(31)

Figure 4.6: Application Structure

Arduino is connected with a LED, potentiometer and a servo. The servo can be set to a precise angle. The potentiometer is used to control that speciﬁc angle. The angle control is done by Raspberry Pi. The Rasp- berry Pi reads the incoming number and manipulate the value in a safe range. Moreover, the angle is controlled by a software switch. The software switch is dedicated in the Android app. Once it’s enabled, the Rasp- berry Pi will issue the command to the servo. Otherwise, the servo main- tains a default position. The gateway is constructed as a data collection point. All the commands and potentiometer reading will be sent to the gateway. The gateway pushed the message to a message broker. Those messages can be further received, processed and analyzed, probably in the cloud.

(32)

5 Results

Results are included based on the tests described by Chapter 4. In the beginning, Arduino is connected with laptop and single-board computer separately. This test is called Direct Connection. Then Arduino is connected to the single-board computer. The single-board computer and laptop is connected in the same LAN environment. Both tests address throughput and latency.

5.1 Direct Connection

Direct connection shows the how it’s bridge device can aﬀects channels and Arduino performance.

5.1.1 Throughput

The Throughput conducts in two environments, one is Raspberry Pi, the other one is Macbook Pro.

Figure 5.1: Throughput when Arduino is connected with each device

Due to duplex characteristics, the serial channel can transmit two streams at the same time. The test puts the strong noise on Arduino and made the micro-controller overwhelms. When the laptop starts to transmit, the Arduino replies less comparing to Raspberry Pi. That is caused by hardware interrupt. The UART receives a full package and validates the result.

Then it invokes the hardware interrupt to notify the Arduino to capture the message which is shown as Figure 5.1.

(33)

Raspberry Pi has twitching over time. A possible cause is the JVM garbage collection. JVM stops the program and reclaims used variable memory.

During this time, the messages stops to send. Arduino returns less messages at the same time may caused by less packages to flip the LED. Ana- log events on the test are caused by ADC errors, comparing to fast flipping actions and notification messages. It may not enough to fill the small gap.

Overall, it doesn’t aﬀects general throughput.

All sending packages have a shape curve in the beginning, that may caused by underlying buﬀers in RXTX library. To be notice, RXTX is a old library which doesn’t receive a patch version update since almost 10 years ago.

Especially it can not handle Linux serial port automatically. One of alter- natives, Java Simple Serial Connector (jSSC) can be a good choice. ASIP is using jSSC for their Java client.

Received messages are not dramatically diﬀerent. That’s because serial event is a hardware interrupt which prevents Arduino enter processing logic where checks the previous state and generates the reply. Since the test is to exhaust the link, Arduino is actually trying its best to receive as much messages as possible. It may receives many messages as it can actually process the messages so those messages may lost. And no message will be sent back to the host.

Table 5.1 show the throughput information in terms of Ardulink messages.

Table 5.1: Statistics among 10 Tests

Scene Average Standard Deviation

Mac, send 775 0.41

Mac, receive 441 4.33

Mac, all 1216 3.94

Pi, send 482 0.76

Pi, receive 467 0.24

Pi, all 949 0.78

5.1.2 Latency

The latency is deﬁned as the round trip time of messages. The host send a message to change one pin status in Arduino. It deliveries the data back to the host. This time is the latency deﬁned.

All tests conﬁrm a huge increase at the same point for Raspberry Pi which may caused by JVM GC event. With powerful CPU, the latency on the link can be slightly reduced as Figure 5.2 shows. Beyond that, the latency is rather stable and is below 10ms.

(34)

Figure 5.2: Round-trip latency when Arduino is connected with each device

Table 5.2 show the latency towards two devices. Mac achieves 4.032 ms round trip latency and Raspberry Pi achieves rather double as Mac, at 8.266 ms.

Device Average Standard Deviation

Mac 4.0 0.020

Pi 8.3 0.004

5.2 Bridge Connection

As of the bridge connection, the message sent is simply the value from the Macbook Pro transferred across the network. The message will eventu- ally forward to the Arduino by the bridge. The received message is prop- agating from Arduino by the bridge. Based on implementation of Sensi- bleThings, the frame size of messages varies. Overheads maintained the DHT is not counted.

5.2.1 Throughput

SensibleThings is set to be TCP and RUDP. Figure 5.3 shows the throughput using RUDP over 2 minutes, in which only 9ms and 12.5ms are shown in the result. The number of time is the sending interval of Macbook Pro.

(35)

Figure 5.3: Bridge Throughput using RUDP with 9ms and 12.5ms Interval

In RUDP, conceivable loss can be observed if the interval is shorter than 9ms. The detailed information is shown in Table 5.3. At 9 ms, 11 ms and 12.5 ms, it has a relative stable received result. But in the Figure 5.3, two spikes are shown as it could be buﬀer implementation of JVM or operating system.

Table 5.3: Average Messages per second at Diﬀerent Sending Intervals (ms) using RUDP

Intervals 4 8 9 9.5 10 11 12.5 15 20

Send 218 112 100 89 179 81 70 60 46

Send Std. 4.12 1.60 0.96 1.02 2.47 0.98 0.76 0.91 0.58

Receive 11 32 85 85 86 81 83 88 93

Recv. Std. 38.60 47.70 35.87 26.80 93.53 26.66 20.33 22.47 22.91

All 229 144 185 175 264 172 152 148 139

All Std. 38.01 47.17 35.94 26.87 93.62 26.73 20.47 22.63 22.93 The TCP test is conducted as the same as previous RUDP test. But sending interval is much longer if no signiﬁcant loss. As shown in Figure 5.4, the throughput is less than RUDP in general.

(36)

Figure 5.4: Bridge Throughput using TCP with 20ms and 22.5ms Interval

In TCP, conceivable loss can be observed if the interval is shorter than 9ms. The detailed information is shown as Table 5.4. At 9 ms, 11 ms and 12.5 ms, it has a relative stable received result. But in the Figure 5.4, the received messages has many twitching, and it generally achieves less data rate than RUDP. What’s worse, it not stable. The detailed information is shown in Table 5.4.

Table 5.4: Average Messages per second at Diﬀerent Sending Intervals (ms) using TCP

Intervals 15 17.5 20 22.5 25 27.5 30 35 50

Send 60 51 45 40 36 33 31 27 19

Send Std. 0.67 0.76 0.67 0.56 0.48 0.58 0.58 0.39 0.44

Receive 14 20 22 31 41 50 56 66 91

Recv. Std. 14.62 15.56 13.10 16.98 19.63 21.32 24.37 22.97 28.29

All 74 70 66 72 77 83 88 92 110

All Std. 14.64 15.76 13.18 17.08 19.68 21.47 24.28 22.99 28.30

5.2.2 Latency

The latency is performed in the similar way as direct connection. The message is sent from MacBook Pro. While the Raspberry Pi receives the message and convert the message to Arduino, then the response is converted back to Macbook Pro by Raspberry Pi. As shown in the Figure 5.5, the spike of around 200ms and the other around 100ms should be JVM GC event on the Raspberry Pi node.

(37)

Figure 5.5: Throughput bridge is connected with each device

Table 5.5 show the latency details for bridge connection. It is roughly 2 times more than direct connection with Mac. However, the link is rather stable.

Average Standard Deviation

19 0.29

The complete data of all tests are plo ed. See the Appendix C for ﬁgures.

5.3 Sample Application

According to the Section 4.5, a distributed network is connected by Sensi- bleThings. Arduino operates the servo and reading from the potentiometer but the control work is done by Raspberry Pi which is also a node in the network. The Android app controls whether servo can be operated.

The sink can collect data to further process.

The sample application runs successfully with a minor package loss since RUDP implementation is not solid. The control panel in the Android is shown as Figure 5.6. If the bu on is toggled, the message will be sent to Raspberry Pi node since it registers the corresponding UCI for Arduino as well as the gateway for log aggregation. Arduino connects every devices as Figure 5.7.

The gateway receives logs and delivery it to the message broker which are shown as Figure 5.8 and Figure 5.9.

(38)

Figure 5.6: Control panel in an Android app Figure 5.7: Arduino UNOv3 with the a ached hardware component

Figure 5.8: Arduino UNOv3 with the a ached hardware component

Figure 5.9: Received pending messages in the message broker

Therefore, the working distributed application is feasible and can be easily done.

Sample code and test code are available as Appendix A shows.

(39)

6 Conclusions

In this thesis, I investigated the general concept of Internet of Things as well as other IoT platforms. SensibleThings is chosen as the tested IoT platform since it provides distributed DHT and open source. I made the comparison among various of devices, among them I chose the micro- controller and single-board computer as the experimental conﬁguration.

Given the community popularity, Arduino is used as micro-controller device. Raspberry Pi is used as single-board computer. SensibleThings is running on the computer and Raspberry Pi for the speciﬁc experiments.

With the Raspberry Pi, I used it as a bridge device to enable Arduino to connect with other nodes in SensibleThings network. As of the bridge connection, serial communication over GPIO and USB is investigated. I used the USB virtual serial communication port to conduct a series test about throughput and latency. In the beginning, a set of direct connection is investigated as a reference. Later, the bridge connection is conducted in the same way. As a result, by using RUDP, we can hold around 170 messages transmi ed or received within 18 ms latency which is acceptable for advanced controls. With such performance, micro-controller is proven ap- plicable to join a high-level Internet of Things platform. It opens a boarder application possibilities.

6.1 Ethical Consideration

As the small micro-controller can be easily embedded into daily objects, it raises the privacy concern. Unlike a RFID tag, it’s passive and often requires another devices to read it. Thus potential users are fully informed of its existence. But a micro-controller might just a ached with a sensor and sampling the temperature. Moreover, image collection is also possible. In the worse case, the device can be too small so the user might not notice that. To some extend, it might collect enough data to recover a case where privacy is a concern. Law can enforce a consensus use case but the clause should not restrict on its power consumption, size, communication methods and abilities. Otherwise, a micro-controller is just useless comparing to other solutions. Such loss may impact possible production innovation a lot.

Considered the fact the distributed network can operate many physical components, misbehavior may cause property loss, even human death.

Fault tolerance is hard to achieve by a general policy. Thus the physical component as well as micro-controllers should be designed in a fault- tolerant way. Even parts or all distributed network refuses to work, the physical objects can be retain a safe position or raise the conﬁrmation from human operator.

Besides its disadvantage, it shows a promising future. Cheaper hard-

(40)

wares often results in more interesting application development. Micro- controllers are usually cheaper than single-board computer or more advanced devices. Installation like a main host with several micro-controller components are likely to be useful to cut down some extra costs and provide customization. It would be good to see a complicated surgery devices can be installed depend on situation with cheap deployment cost. Thus it certainly opens up more possibilities.

6.2 Future Work

Arduino can be connected with additional hardware to extend its functions. Those devices are called Arduino Shield. They are directly connected by pins or connected by serial communication. Some Shield provides IEEE 802.11 network or Ethernet. The performance will varies since additional hardware is connected. Those modules may not be powerful enough to run SensibleThings. But it can be still connected with a device as bridge, for example, Raspberry Pi. If time permits, I can build such bridge as the same as this thesis by replacing Ardulink with libraries communicating with shield instead. And I can expect reduced performance in wireless communication and more or less similar performance in Ether- net.

A JSON ﬁle can describe services on Arduino and its underlying pins.

A meta-compiler can generate client code for single-board computer and microcontrollers. It generally isolates different layers of abstraction and can offer ability to deploy new firmware for microcontrollers in a existing network. For Arduino, a meta-compiler can generate and cross-compile a C++ protocol class with other code. Then it can be delivery to the connected bridge where the firmware can be uploaded.