Design and implementation of wireless sensors and applications for the Internet of Things

(1)

July 2014

UNIVERSITY OF PISA

PhD School of Engineering “Leonardo da Vinci”

PhD program in

APPLIED ELECTROMAGNETISM IN ELECTRICAL AND

BIOMEDICAL ENGINEERING, ELECTRONICS, SMART

SENSORS, NANO-TECHNOLOGIES

PhD Dissertation

DESIGN AND IMPLEMENTATION OF

WIRELESS SENSORS AND

APPLICATIONS FOR THE INTERNET

OF THINGS

Author:

Ing. Elisa Spanò ______________________

Advisor:

(2)

(3)

(4)

(5)

ABSTRACT

In the internet of things vision, devices and objects will be connected to the Internet and will be able to communicate with each other and with humans in real time and to make autonomous decisions. While continuous communication capabilities improve, wireless sensor networks and smart devices usually communicate and share data with a central base station and using a dedicated platform developed for a specific application. Developing a new application that is interoperable with existing devices or integrating composite applications into an existing platform is today a hard and challenging task requiring advanced development experience.

The lack of a common platform with well-defined interoperability interfaces has made heterogeneous sensors networks and smart devices hard to integrate into composite applications and into the Internet, slowing the diffusion of Internet of Things applications.

This research focuses on the design of wireless sensors and applications based on a new open, complete, flexible and scalable platform for the Internet of Things.

The main contributions of this thesis are:

1. The proposal of a platform able to integrate heterogeneous devices and sensor networks, communication protocols and multiple applications and to be easily deployed and reconfigured with no need of modifying the existing infrastructure.

2. The design and implementation of a Smart Grid power metering system allowing non-technical users to control energy consumption and production, and to securely exchange power usage data at the proper level of granularity with energy providers and distributors. 3. The design and implementation of a Remote Health monitoring for

long-term high-quality non-intrusive ECG monitoring, where a wide coverage and a low cost is required (at home or in a nursing home). Based on the IoT platform the system offers the possibility to combine and integrate health sensors with smart home sensors, while ensuring secure and differentiated access to data. It also provides access to historical data and to real-time data.

(6)

(7)

i

1 INTRODUCTION

1.1 Motivation

Recent advances in research on semiconductors, microelectronics, radio communications and materials are driving the development of sensor networks, and have made the wireless sensor networks (WSN) a premier research topic since the nineties.

The growth of interest on WSN has led to a wide market diffusion of a new generation of microcontroller chips, radio and sensors having increased computational capabilities, more features and interfaces, lower cost and lower power requirements than those available 5 years ago.

Consequently, electronic devices, able to interact autonomously with the physical environment, are penetrating in numerous applications in our daily life. These devices, generally capable to communicate to other devices or networks via low-power network protocols such as ZigBee [1], WiFi, 3G, EnOcean, 6LoWPAN [2], [3], IEEE 802.15.4, or other proprietary standards, are called “smart” devices. It is considered that they will have a central role in the upcoming age of ubiquitous computing [4] and of the Internet of Things [5].

In the internet of things vision, devices and objects will be connected to the Internet and will be able to communicate with each other and with humans in real time, and make autonomous decisions.

Thanks to a continuous improvement of communication capabilities, today’s wireless sensor networks and smart devices usually communicate and share data with a central base station and using a dedicated platform developed for a specific application. Realizing a new application interoperable with existing devices or integrating composite applications into an existing platform is today a hard and challenging task requiring significant development experience. The lack of a common platform with well-defined interoperability interfaces has made heterogeneous sensors networks and smart devices hard to integrate into composite applications and into the Internet, therefore slowing down the expansion of Internet of Things.

Our research focuses on the design of a single open platform for the Internet of Things, capable to integrate different applications and heterogeneous networks as a single large net.

1.2 Problem space

Smart devices with connectivity capabilities are increasing their presence in several applications in our homes, cities, society, and personal live activities. Numerous monitoring and control systems in use today do not allow

(10)

2

integration of different existing sub-systems and are able to cover only a limited number of user applications. As a consequence, many homes host more than one home automation system, unable to interoperate with each other.

The possibility of having a single common infrastructure capable to integrate, manage and coordinate multiple applications, heterogeneous sensors and sub-systems from different vendors would reduce total setup and maintenance cost with an increase of smart environment deployments in many real life applications. In addition, such architecture would give the user the opportunity to add new sensors, networks, or applications on an existing infrastructure, with limited cost.

1.3 Thesis Contributions

This dissertation proposes wireless sensors and applications based on a new open, complete, flexible and scalable platform for the Internet of Things.

1.3.1 Platform

Our proposed platform can integrate heterogeneous devices and sensor networks, communication protocols and multiple applications and can be easily deployed and reconfigured with no need of modifying existing infrastructure.

Our platform has four main advantages:

1. It seamlessly integrates several concurrent applications,

2. It can gather data from heterogeneous sensor communication protocols,

3. It ensures secure and customized access to data,

4. It allows to univocally map each sensor and actuator to a common abstraction layer on which additional applications can be built. The design of such a platform has required a multi-disciplinary approach, from electronic design to information systems, at different levels of abstractions, from the physical sensors up to the application level.

We focus on two sets of applications that are built on the platform:  Smart Grid Power Metering;

 Remote Health monitoring.

They are significant development in themselves, compared to existing dedicated applications, and are relevant demonstrators and complete implementations of the IoT platform.

(11)

3

1.3.2 Smart Grid Power Metering

The design of a control system of household energy consumption is one of the goal of the customer domain (Figure 1) of the smart grid conceptual model (illustrated in Figure 2) proposed by NIST (National Institute of Standards and Technologies) [6].

Figure 1: Customer domain of the smart grid conceptual model

Figure 2: Smart Grid NIST Conceptual model

Smart Grid is an advanced electrical grid integrating a bidirectional information network and a two-way energy-flow network, which allows a smarter and more efficient management of the electricity network. In this context, our contribution is a system allowing non-technical users to control energy consumption and production, and to securely exchange power usage data at the proper level of granularity with energy providers and distributors. In order to facilitate broad adoption, the system has been designed and implemented with the constraint of requiring low capital expenditure and maintenance cost.

(12)

4

1.3.3 Remote Health monitoring

The second application with consider is the monitoring of vital signs, such as electrocardiogram (ECG), in a non-hospital environment. We consider the existing gap between devices and services for chronically ill people, and non-medical devices focused to healthy people either generally physically active ( e.g. the clamp to measure the pulse during a race ). Between these two extremes there are many people suffering from small health problems that may benefit from devices and systems permitting them to monitor and manage their health.

In this context, we have designed and implemented a demonstrator on the IoT platform capable of integrating multi-user monitoring devices that transmit continuously with relatively high data rate and can cover a wide area (home, building, big nursing home, etc.) while maintaining a low cost. Moreover, the system offers the possibility to combine and integrate health sensors with smart home sensors, while ensuring secure and differentiated access to data. It also provides access to historical data and to real-time data.

1.4 Thesis Outline

The thesis is organized as follows.

We present in Chapter 2 the complete architecture of the IoT platform. Then in Chapter 3 we present a smart grid system in the customer domain and in Chapter 4 the ECG monitoring application. Finally, in Chapter 5 we present our Conclusion.

(13)

5

2 A PLATFORM FOR THE INTERNET OF THINGS

The term Internet of Things is coined in 1999 by Kevin Ashton, executive director of the Auto-ID Center [7]. In the vision of Internet of Things (IoT) all electronic devices act as nodes in a networked physical world and every object can be, remotely and contactless, detected, identified, addressed, interrogated, monitored and controlled [8], [9], [10].

In order to realize the idea of IoT it is necessary that sensor/actuator networks do not remain confined to a small system but became able to interact with other networks based on different protocols and can be connected through the Internet to remote applications and/or users.

2.1 State of the art

In recent years, the research community has been extremely active in the neighboring fields of WSN and IoT. Academic and industrial Research groups have presented several solutions for sensor network monitoring and remote management, and devices for enabling Internet connectivity. Many of them are designed for specific networks or applications, so difficultly extensible to heterogeneous networks or further applications.

MoteView [11] is, as the authors say, a “scalable software framework for managing, monitoring, and visualizing sensor network deployments”. It is designed to work with the MoteWorks architecture, which includes hardware that has to be designed as Crossbow motes, a dedicated network stack and an operating system running on each network node. The MoteView framework can be used to manage multiple sensor data streams of supported sensor boards but can be hardly extended to or integrated with applications requiring the collection of data from heterogeneous networks.

Other solutions have been proposed, that are not linked to a specific protocol. Octopus [12], an open-source dashboard to visualize and to control a wireless sensor network, can work with any hardware that run TinyOs 2.x [13] and can be used with different protocols. The disadvantages of this system is that it allows the choice of the protocol of communication only in a static way during code compilation, so can only be used in standalone applications linked to a single WSN protocol.

The need to collect and manage data from different sensors and heterogeneous networks has been considered in [14], [15] and [16]. In [14] a complex middleware, named Lamses, is proposed to manage information collected from heterogeneous sensor nodes and mobile RFID systems. This middleware allows real-time sensor data collection and event processing and provides query requests and sensor control to different types of client applications and services. However, it is a stand-alone solution requiring prior hardware information about sensor nodes and sensor networks from a client. In addition, it deals only with information management and does not explain,

(14)

6

for example, how to implement interfaces between Lamses and the different groups of sensor nodes, one the one hand and between Lamses and clients on the other.

The system presented in [16] proposes a three-layer service-oriented architecture (SOA) which allows the integration of various WSNs deployed in large-scale environments as a single stand-alone system able to perform complex applications. The architecture collects data from a network based on multiple proprietary technologies and customized platforms, delegating to a gateway the task of converting the data into a universal format independent of network protocol.

The solution proposed in adopts a middleware for sensor network message processing and interpretation with the main goal to “decouple low-layer network details from application layer”. Even if it offers a bidirectional communication between system and network node, the gateway is also here responsible for managing two-way translations between the specific network protocol and the XMPP protocol implemented on top of the system client. Both these “gateway-based” approaches allow abstracting from the underlying hardware and software platforms connected to the system but in this way prevent direct access to the information sources.

The lack of reusability of standalone WSN management tools in new systems’ development has motivated the work in [17]. Indeed, the proposed H-WSNMS system aims to “facilitate the reuse of each individual WSN’s preliminary management command service as much as possible, and at the same time, present to users a unified management interface across multiple WSNs”. This tool, as with the one in [16], does not allow multiple applications to run on top of the same sensor network.

A Microsoft Research project, SenseWeb [18] aims to provide a platform for developing sensor applications that use the shared sensing data from sensors deployed by contributors across the globe. Using the SenseWeb platform each contributor can registers her data sources and publish live sensor data on the web. Users can build useful services on top of these data sources, with queries based on keywords, sensor types, and geographic regions or routes. Even if this solution allows concurrent applications to share sensor data, it does not allow to directly access the information sources.

A bidirectional management architecture for heterogeneous Wireless Sensor Networks – allowing direct access to sensors - was proposed in [19], but it requires a specific firmware running on each node, and therefore does not allow for interoperability of different sensor node types.

Out of academic and industrial research, there several platforms for IoT or WSN have been proposed in the market, mostly positioned at a higher abstraction layer. While there is no dominant solution, the most popular today are:

(15)

7  Nimbits Data Logging on the Cloud  ThingSpeak Internet of Things  The iDi Device Cloud

 The SensorCloud by MicroStrain  The Sen.Se Internet of Everything

 The Exosite One Platform and Portals for Cloud-based data and device management

 EVRYTHNG software engine and platform  Paraimpu – The social tools for Things

 Manybots – Collect and manage information from apps and devices Although they have different characteristics, all these platforms provide API or tools and software samples to program and configure the devices one wants to connect to the platform. In addition, APIs are provided to realize custom applications retrieving data exchanged between a device and the platform. The need to customize the device and its communication protocol to fit the IoT platform limits the possibility of using the platforms with sensors of limited capability or that simply cannot be reprogrammed or reconfigured. As a consequence, each IoT device currently is actually part of the platform.

2.2 Platform Design criteria and features

The proposed solution responds to four different requirements:

1. It seamlessly integrates multiple different applications. Considering, as example, the smart grid application, we assume that the typical early adopter of a last-meter smart grid is also a user of smart home applications (dedicated to security, entertainment, home automation, personal health care et cetera). Therefore, it is desirable – to avoid duplication and to enable possible synergy – to provide a platform that can support both smart grid and other smart home applications. Moreover, it should allow an easy way to integrate new multiple applications that one might want to deploy on the platform infrastructure.

2. It can gather data from heterogeneous sensor communication protocols. An IoT platform should be able to integrate sensor network pre-existing infrastructures, without requiring a sensor reprogramming or a network redesign. Therefore, its architecture allows different wireless or wired protocols to be used for communications between meters, users, and other parts of the system.

3. It provides secure and differentiated access to data. Network owners should have complete fine-grained access to their own data, and should be able to enable access to data and devices by third parties. On the other hand, services providers should be able to receive coarse-grained and aggregated statistical data.

(16)

8

4. It allows to univocally map each sensor and actuator to a common abstraction layer. To simplify interaction with non-technical users, sensors and actuators should be also described at a high abstraction level, independent of the physical details and of the communication protocols, which can be used by developers and businesses to provide additional services.

The proposed platform has a number of features as a consequence of these design criteria:

 Data control: users can control and decide who gets access to their data  Data sharing: Different concurrent applications can share customer and

sensor data, if access is granted.

 Secure communication: data communication and data accessibility have a level of security higher than AES-128.

 Multi-protocol and multi-systems integration: the platform does not require specific network connection other than TCP/IP. By encapsulating data in TCP/IP packet, each device can communicate with the IoT server using its own communication protocol.

 Long- term data accessibility: data can be stored and queried for more than one year.

 Real-time communication: user can view and control devices in real-time.

 Open platform: new network types and devices can be added to the platform. Quick and Easy Setup Zero configuration required for connecting a new device of known protocol.

2.3 Platform architecture overview

We have developed a platform for the Internet of Things (IoT) that can seamlessly support an in-home Smart Grid, Health monitoring, and Home Automation and can leverage other services and functionalities available on the same platform. Its architecture is that of a scalable distributed system on which different concurrent applications for remote monitoring and control can run. The platform architecture is illustrated in Figure 3 and consists of three main parts:

 the sensor and actuator networks;  the Internet of Things (IoT) server;

 the user interfaces for visualization and management.

Sensors and actuators nodes communicate in a reliable bidirectional way with nearby nodes and with the IoT server, sending data and receiving commands and configurations.

(17)

9

The communication interface between nodes (using a gateway if needed) and the IoT server follows the TCP/IP client-server model. Networks send node messages in their native format to the IOT server, over an encrypted TCP stream.

The IoT server converts the raw payload, containing information from heterogeneous nodes, into a standard format, containing object identifier, object type, measurement unit, and data field, geographical position, and timestamp. In this way, data can be easily represented, manipulated and aggregated without considering the communication protocol of the originating source.

Figure 3: Block diagram of the Internet of Things platform

A web-based graphical interface allows users to access real time and historical sensor data. The same interface allows users with administration privileges to manage networks and single nodes. Third-party software can access the platform using a REST API [20].

(18)

10

Due to the possibility of using the system to collect sensitive and confidential data, the platform ensures an adequate security level both to end-to-end communications and to data access. For this reason, users need to be authenticated before they can access the platform and can only access specific sets of sensor data through HTTPS.

The IoT server supports multiple encryption protocols (AES-128, SSH). The choice of the security level and protocol is made during the initial gateway/server communication configuration and is mainly dependent on the gateway capabilities.

At a finer level of detail, the Internet of Things platform consists of several hardware and software main components, each described by its functions and its interfaces with others components. In this way, the architecture is easily scalable and robust. Any main component can be modified, redesigned, and extended with minimum impact on the rest of the system. Main components are indicated in Table 1 and are described in more detail in the following sections.

Table 1: Main components of the Internet of Things platform

Parts Main components

Sensor and actuator

networks  Sensor and actuator nodes  IP gateways

IoT Server

 Message dispatcher

 Data management unit and sensor database

 Configurator unit and database  Secure access manager User interfaces

 Visualization interface  Configuration interface

 Applications using the REST API

2.4 Sensors and actuator Networks

2.4.1 Sensor and actuator nodes

The sensor and actuator nodes can be part of networks implemented with wired (CAN, power line, etc.) or wireless (ZigBee, WiFi, Bluetooth) network protocols. The architecture is designed to accommodate different and heterogeneous sensor and actuator networks. The data management unit is responsible for translating information to the format required by the sensor database.

On the other hand, bidirectional communication channels to the nodes enable the IoT server to interrogate, configure, and program them. Configuration

(19)

11

messages mainly carry node-specific information (measurement thresholds, alarm settings, etc.) or a new version of the program running on the node. Even if specific node characteristics depend on the network implementation, the proposed architecture supports the possibility to add or remove any network component in real time. Indeed, any node can join the system requiring no modification to network implementation. For this reason, any new node that joins a network connected to the platform is automatically identified and immediately accessible from the network administration interface for registration and configuration. Similarly, updating or un-joining nodes are automatically referred to the IoT server. The interface between sensor networks and the platform is based on a communication protocol between the gateway and the IoT server defined by API specifications.

Each node has to be uniquely identified to ensure global device accessibility. However, node addresses in typical sensor networks may change over time and are often unique only within a single network. For this reason, the IoT server assigns to each node of the network a unique ID (for example an octet string based on the 64-bit Extended Unique Identifier (EUI-64) specified by IEEE) and maintains the mapping between such ID and the one provided by the local sensor network coordinator. When a node sends a message to the server, the gateway translates its network address into the unique ID, and vice versa for messages from server to nodes.

2.4.2 IP Gateway

The gateway is the element connecting a sensor/actuator network - if it has no direct IP capability - to the IoT server via an IP link. The gateway is bidirectional: for uplink communication it collects data received from the network nodes, performs reformatting/encapsulation if required, and sends them over a secure TCP/IP link to the message dispatcher. For downlink communication, it forwards to the receiver node(s) the commands received from the IoT server.

We propose a different gateway concept with respect to the one commonly used to integrate heterogeneous networks with an external network [16], [21] and [22]. These systems use a gateway-based approach [23], where the gateway performs a conversion of data into a universal format.

In our architecture, instead, the IoT server performs such operation. Therefore, the gateway sends network packets over TCP/IP in the native format and both the gateway and the message dispatcher are transparent at the logical communication level between nodes and IoT server. Our approach is similar to [24] where the IoT gateway encapsulates the ZigBee packets in IPv6 UDP packets.

(20)

12

i) The gateway can have reduced hardware requirements and computational complexity. Our gateway has only to ensure an IP connection, to implement the encapsulation of the nodes’ native protocol into TCP/IP packets, and to ensure the security level required by the specific application.

ii) Different applications and of new functionalities can be developed and added without modifying the gateway,

iii) The user side of the platform can communicate at the application level directly with network nodes.

As a validation of this concept, the gateway is currently implemented with Cortex-M3/M4 microprocessors. It is designed for easy deployment in a typical home LAN, which uses private non-routable addresses and is connected to the Internet through a router able to perform Network Address Translation (NAT). The machines on such LAN cannot receive incoming TCP connection from a remote server without a manual configuration of the router. To avoid this user configuration, our gateway implements the client side of a TCP connection to the IoT server and always initiates the communication with the message dispatcher (Figure 4); if the connection fails, the gateway retries at regular intervals until the connection is established. If the gateway is not equipped with a real time clock, it must synchronize its clock with the remote message dispatcher.

Figure 4: Client/Server Communication between gateway and IoT Server

2.5 IoT Server

2.5.1 Messages dispatcher

The message dispatcher manages the bidirectional communication between each gateway and the rest of the system. It only deals with low-level communications from nodes (through the gateways) to the data management unit and from the configurator unit to the nodes.

It has the main task of listening to new connections from IP nodes that want to join the system. For every connection, it decrypts all incoming packets and

(21)

13

forwards them to the data management unit, for interpretation and storage. In the other direction (downlink), it encrypts and encapsulates all messages from the configurator unit into a TCP message, and forwards them to the destination gateway.

2.5.1.1 Gateway/IoT Server Communication protocol

We defined a simple communication protocol between gateway and messages dispatcher.

The packet structure is illustrated in Figure 5.

Each packet contains of a payload field, augmented with a Start-Of-Frame field, a fixed-size Header, a padding field and an End-Of-Frame field. The same format is used in both communication directions.

The Start-Of-Frame field indicates the beginning of the message. It is used for synchronization.

Figure 5: Structure of the TCP/IP packet of the communication protocol between gateway and message dispatcher

The Header field contains the following fields:

 Flag (8 bit): the 8-bit flag field indicates the type of the message. For example, a flag byte of hex value 0x42 indicates that the packet contains an encrypted binary message.

 Length (16-bit): The Length field specifies the total size of the packet in octets, including header, padding and end of frame fields.

 Sender address (64 bit): The 64-bit source address field contains the MAC address, which uniquely identifies the originating network/device of the packet. This field is filled by the gateway and is used by the server to assign a unique identifier to the network connected to the gateway. It can be the 64-bit network address of the wireless network (for example ZigBee) or another unique identifier such as the 48-bit MAC address of the gateway padded with zeros.

 Opcode (32 bit): The opcode field contains a 32-bit operation code specifying the operation to be performed by the message receiver.

(22)

14

 Timestamp (32 bit): The timestamp field contains the packet sent time. The timestamp is formatted as an unsigned 32-bit integer indicating the number of seconds corresponding to UNIX time (time 00:00:00 UTC on 1 January 1970). A value of zero indicates that the timestamp is unknown. When the message comes from server to gateway, this field can be used by the gateway to update its internal clock, if needed.

 Serial number (32 bit): The serial number is mainly used for debugging purpose, to identify missing packets in transmission. The serial number is an unsigned 32-bit integer initialized to zero and incremented at each sent packet.

 Payload Length (16 bit): The payload length specifies the total number of bytes of the payload.

The Payload field contains the device message in raw format. It is Payload

Length bytes long.

The Padding field: The padding field is used to ensure that the part of the packet that would be encrypted (from the byte number 5 to byte Total Length

- 3) ends on a 16-bit boundary. The padding can have a size between 0 and

15 and is composed of zeros.

The End-of-Frame field indicates the end of the message. Table 2 summarizes the packet fields and possible values.

Table 2: TCP/IP fields and possible values

FIELD BYTES COMMENTS POSSIBLE VALUES

SoF 2 Start of Frame 0x2A3B Flag 1 Message type.

- 0x40: unencrypted binary msg - 0x41: unencrypted ASCII msg - 0x42: encrypted binary msg - 0x43: encrypted ASCII msg Length 2 Pkt size in bytes

Sender

Address 8

unique

device/gateway identifier

- 64-bit net addr of the wsn - MAC addr of the net interface - another unique identifier Opcode 4 Operation Code

Timestamp 4 packet sent time Unix Time Serial

Number 4 increased every sent packet Payload

Length 2 Payload size in bytes Payload variable Payload Padding Variable Adjust the dimension of the packet for encryption 0x00

(23)

15 2.5.1.1.1 Packet Encryption

Each packet can be sent in clear or can be encrypted, depending on the settings on the server and the gateway. The five bytes at the beginning of the packet and the two bytes at the end are always unencrypted. All the other bytes can be encrypted using AES-128 or AES-256 [79], depending on the settings of the server and the gateway.

2.5.1.1.2 Operation Code

Packets can be divided in two main classes:  administration packets

 data relay packets

The packet function is defined by the opcode.

Data relay packets are used to forward the messages from nodes to server and vice-versa. For every type of local sensor network protocol included in the platform two opcodes are defined, one used for the upstream and one for the downstream data transmission. In Table 3 an example of two opcode used in a communication between a ZigBee network and the IoT server.

Table 3: Opcode for BeeStack ZigBee Test Client Protocol

Opcode Hex value Direction Function

ZTCA 0x5A544341 DOWN Forward ZTC packet to ZigBee _{sink node} ZTCR 0x5A544352 UP Forward ZTC packet to the server

In upstream direction when the gateway receives data from the network, it encapsulates the native data in a packet marked with the upstream network opcode, and sends it to the message dispatcher. In the other direction, when the gateway receives from the message dispatcher a message containing a ZTCR opcode it extracts the payload and forwards it to the ZigBee sink. Administration packets are used for configuration and maintenance of the gateway. It is possible to turn encryption on and off, update gateway firmware, get status, identification and debug information, configure network parameters and restart the gateway. In Table 4 an example of administration packet opcodes.

Table 4: Examples of administration packet opcode

Opcode Hex value Direction Function

PING 0x50494E47 BOTH Keep connection alive and used for _{debugging purpose} DOOM 0x444F4F4D DOWN Gateway reset

UEAB 0x55454142 DOWN Turn on AES encryption UDAB 0x55444142 DOWN Turn off AES encryption

(24)

16

As the administration packets do not depend on the network communication protocol, the addition of a new local sensor and actuator network requires only the addition of two new opcodes to the protocol.

2.5.2 Data management unit and database storage

The Data management unit is a collection of software modules, each able to manage the messages of a specific sensor network type. These components receive node packets in their native format and extract their payload. Depending on the payload, two different storing mechanisms are used: • If the payload contains measurement data from a sensor or an event

notification by an actuator, data are stored in a unique format in a streaming sensor database.

• If the payload contains specific network messages (configuration, management information, communication channel, node address, etc.), messages are stored in the original format into the configurator database.

The presence of the sensor database decouples data collection from data processing and visualization, so that users do not interrogate nodes directly. This approach is useful especially when sensor networks are heterogeneous. It is also very useful when nodes are battery-operated devices. Decoupling allows nodes to stay most of the time in sleep mode and periodically wakeup to receive commands and configurations and to send measurement and status data.

2.5.2.1 Virtual object representation

In the sensor database, sensor data are represented as virtual object, with a unique format, independent of the local sensor network protocol, and are univocally associated to the physical nodes through the unique OBJ_ID (Table 5).

Table 5: Virtual object representation in the Sensor Database

OBJ_ID TYPE UNIT DATA GPS _POSITION TIMESTAM_P

7777770000c25000 TEMP °C 18,4 Lat: 43.710329, _{Long: 10.339061} 2014-11-07 _09:41:57.0 7780770000c25054 POWER W 25 Lat: 43.710329, _{Long: 10.339061} 2013-01-07 _11:37:16.0 4477770065c78000 REED STRING ON Lat: 43.710329, _{Long: 10.339061} 2014-01-14 _17:04:37.0 5656347612c78076 ECG mV 2,8 Lat: 43.710329, _{Long: 10.339061} 2014-01-14 _17:04:37.0

(25)

17

In this way, data can then be easily accessed by performing a simple query to the database, processed and visualized independently of the characteristics of the physical source.

Unlike sensor data, configuration variables and messages can be completely different for nodes of different type and network protocol. Storing configuration messages with no protocol conversion avoids possible loss of information. Both sensor and configuration information are stored in remote databases. This makes the system easily scalable and does not impose limitations on the data volume a node can send to the server.

2.5.3 Configurator unit and database

The configurator unit configures networks and nodes according to inputs from users and authorized applications and according to the system status stored in the configuration database. The configurator unit is also a collection of software components, each dedicated to a specific type of sensor/actuator network. From received instructions, it creates the correct sequence of messages required to configure the targeted nodes and networks. For any new added sensor network protocol, dedicated modules must be added to the configurator unit.

Each message ready to be sent will be stored in a database table called

command table accessible from the message dispatcher.

2.5.3.1 Command Table

The command table includes the following fields:  NET_ID (integer , network ID )

 NTYPE (string, type the network " ZTC " for example)  timestamp

 command (string a maximum of 512 characters)

The command field contains the command message formatted in the receiver device language and inserted into a JSON string contains an object with a single member, with key "data". In Table 6 an example of command table fields is presented.

Table 6: Example of Command Table Fields

SEQ

NUM NET_ID NTYPE TIMESTAMP COMMAND

34 1 ztc 2013-10-23 _13:04:37.0

{"data":

"70500f0200000000000000 000806000800002b"} 34 2 uni 2013-10-23 _13:05:24.0 {"data": "XXXXXXXXXXX"}

(26)

18

The field NTYPE the database table indicates the "family" of the package. In the example in Table 6:

 ZTC: indicates that the packet is a hex encoded message that must be sent 'as is' to the gateway.

 UNI: it is used for “universal” packets, those that do not depend on a specific protocol but are addressed directly to the gateway and interpreted by it. They are used to send gateway configuration/reprogramming commands.

Each child process of the message dispatcher reads the command from the database for the network associated with itself (identifiable by net_id). Every five minutes the lines older than 15 minutes are deleted from the database. If the child process terminates for any reason, it deletes all rows from the database associated with itself before dying.

2.5.4 Secure access manager

A secure access manager that ensures privacy and data protection coordinates all communication between end-users and the IoT server. It provides access to stored information and network configuration only to authorized users or third-party applications, based on a database of users and their permission to each resource (networks, node). By default, networks owners have administrator rights on their networks. They have access to all information, can manage access rights to nodes and data and configure alarms and event triggers.

2.5.4.1 Network and device visibility

The platform allows the administrator to restrict the external visibility of each network/device specifying one of the three possible visibility statuses:

 public: visible to everyone (even non-registered users)  private: visible only to those who have administrator rights

 restricted: only visible to a certain number of users explicitly specified by the administrator

A permit given to a network extends to all sensors. At any given time, the visibility status of a sensor is the most restrictive between the status set for the sensor and the one for the network.

2.5.4.2 User platform accessibility

Users can access the platform though the user interface. The platform supports three different user profiles:

(27)

19

 Network Administrator: Has full access to the network and determines who can access the devices connected to it, and with which rights.

 Member: Authorized to read and/or send any command to the devices to which she has access rights.

 Unregistered visitor: Can only view data associated devices with public visibility status.

When registering, users automatically receive administrator privileges for your user networks and network standards of others.

The owner of a network or can choose to assign to another user the owner of the rights to your network.

The main privileges are:  reading

 writing  administration

2.6 User interfaces

Users, service providers, and application developers can interact with the platform through user interfaces (web-based or API). The user interface offers two main functionalities related to two main client profiles: Standard users and administrators. Standard users can access sensor data and can send command to actuators. Administrator users have superior access: they can also see the configuration and the status of the nodes and dynamically configure them.

The interaction between users and the platform through the web user interface can be modeled as a finite state machine. In this representation (illustrated in simplified form in Figure 6), circles represent states and arrows represent valid transitions from a state to another. Transitions are triggered by IoT node events and client requests, and depend on user permissions.

The initial state is the login page.

Non-registered users can see only public sensor data but cannot send commands or configure nodes and networks.

(28)

20

Figure 6: User interface State machine diagram. Blue circles represent states of the administration interface; red circles represent states of the visualization

interface.

Registered users have access to the user home page (e.g. Figure 7).

Figure 7: Home page example

Starting from this state, two main parts make up the web interface: a visualization interface and an administration interface.

(29)

21

2.6.1 Visualization interface

The visualization interface displays current and historical information from sensors and actuators is a series of pages. In addition, the visualization interface allows authorized users to send commands to actuators. User can create custom data views and visualization pages, send commands, set rules and alarm notifications.

2.6.2 Administration interface

The administration interface provides users with the possibility to remotely manage and configure their networks. In addition, users can set data visibility of their own sensors and manage third part access and privileges to their nodes. The layout and the fields included in the administration interface pages depend on the type of networks and on the corresponding protocols.

Administrator interface is also used to easily and remotely register new gateways and configure new network connections.

2.6.2.1 Initial configuration and connection setup

To establish the connection, the gateway needs to know the network name and IP address of the message dispatcher, the port number on which it accepts connections and the network AES security key. For this reason, it has to be registered and configured.

Using the web user interface the administrator users can add a new network on their admin page, by inserting the gateway address, selecting the type of network and assigning a name, a description and a network location. The server will generate a network security key (ex. AES key) and will save it in the user database along with the network information. The gateway has then to be configured with the server name (IP address), the connection port and the security key. The gateway own IP address can instead simply be assigned using DHCP. The gateway can accept an incoming configuration connection from an application running on a PC connected to the same LAN.

After the configuration, the gateway connects to the server sending a request connection. The server processes the request, spawns a new process and lets it communicate directly with the gateway. This task acquires the network information from the configuration database and informs the gateway it can begin the encrypted communication.

After the communication is setup, the network appears on the configuration page of the user's network.

(30)

22

Figure 8: Gateway-Server Initial communication

2.6.3 Web service API

Web service APIs open the platform to service providers and new client applications (as for example an Android app as in Figure 9). APIs offer an easy and unified way to retrieve information collected from heterogeneous sources.

Service providers, utilities and third part can use the API to obtain single, multiple or aggregated measurement data, useful to develop new services. To protect sensitive information, the sensor owner can define third part accessibility and the visibility level of collected data. Only registered end-users and authorized third-party applications can retrieve sensor data from the sensor database though the API.

Figure 9: Example of a sensor data visualization using a smartphone and web service API

(31)

23

3 IN-HOME SMART GRID PLATFORM DESIGN AND

IMPLEMENTATION

We have designed and implemented an in-home prototype on the IoT platform, building dedicated hardware and software. Our system connects smart homes to the smart grid (Figure 10) creating a new potential for optimizing energy consumption, saving money and actively participating to demand-response policies.

Figure 10: Last-meter Smart Grid System

Such implementation minimizes the need for additional infrastructure, enables integration with smart home applications, ensure secure and differentiated access to data.

This first prototype only includes a ZigBee network connected to the IoT server though a ZigBee IP gateway. The sensors are smart plugs, placed between home appliances and the wall socket, and able to collect real-time power consumption data from the loads.

Customers can have a visual feedback of their energy consumption and can remotely control each load.

(32)

24

3.1 ZigBee Smart Plug design and implementation

The smart plug is a single-phase energy meter. As shown in Figure 11, it is enclosed in a plastic case with a plug and a socket section and can be easily inserted in a standard wall socket.

Figure 11: Smart Plug prototype

The smart plug collects load information from the attached electrical equipment. Information includes single-phase active, reactive, and apparent power; power factor; sampled waveforms; RMS current and voltage; and on/off load status.

The smart plus is also an actuator, since it can switch the power to the load on and off.

Our smart plug has no buttons and can be completely configured and controlled through the user interface.

3.1.1 Smart Plug circuit

The smart plug is composed by the following main blocks:  Energy measurement

 ZigBee transceiver  Microcontroller unit  Relay

(33)

25

In the current design, a Freescale MC13224 SoC [25], equipped with a two-way AES128 encryption engine, provides the communication with the ZigBee network.

In Figure 12 a block diagram of the smart plug circuit is presented.

The board includes a 32-bit TDMI ARM7™ processor with 128KB of Flash, 96KB of RAM and 80 Kbyte of ROM memory. An Analog Devices ADE7953 [26] is used for energy measurement. It interfaces to the microcontroller through a serial interface (SPI). The current sensing is achieved with a shunt resistor placed on the phase wire, while the voltage sensing is achieved with an attenuation network between phase and neutral.

Figure 12: Smart plug block diagram.

Power connection/disconnection to the load is implemented using a single pole bistable 12 V relay supporting loads up to 16 A. The board includes a power supply unit, which provides the operational voltages of 12 V for the relay and 3 V for the ADE7953 IC and the MC13224 SoC.

The firmware running on the smart plug is implemented using the Freescale BeeStack protocol stack [29], [30]. The BeeStack architecture is built on the ZigBee protocol stack [1] and defines additional services to improve the communication between layers of the ZigBee protocol stack.

3.1.2 Smart Plug Calibration

The SPI interfacing the ADE7953 to the smart plug microcontroller has been used to calibrate various error components of the meter, including gain, offset, and phase errors.

(34)

26

The smart plug has been calibrated using as a reference meter the tabletop power meter PCE-PA 6000 [27] (Figure 13).

Figure 13: tabletop power meter and calibration Setup

Calibration coefficients are calculated based on the smart plug measurements, and transferred to the meter ADE7953 IC registers through the ZigBee radio. The ZigBee smart plug has an accuracy of 1.1% (post-calibration) (Figure 14).

(35)

27

3.2 ZigBee/Ethernet Gateway

As the power meter is a ZigBee device, a ZigBee/IP gateway is needed to allow communication with the IoT server. The gateway is composed by an Ethernet interface, a microcontroller, and a ZigBee RF transceiver.

In principle, several commercial ZigBee Ethernet boards could be used to implement a gateway able to connect a ZigBee network to the IoT server. However, they are usually oversized, being designed to process all received data, or they are closed and use proprietary firmware that cannot be modified. Following what we wrote in Section 2.4.2, the gateway can have reduced hardware requirements, and can be implemented using a low cost microcontroller, a wireless radio and an Ethernet controller. In order to reduce chip count, and hence cost, we have selected a microcontroller with an on-chip Ethernet controller, which slightly increases the processor hardware requirements.

3.2.1.1 Hardware

In the current design, the ZigBee Ethernet gateway is based on an ARM microcontroller with integrated Ethernet capabilities and hardware encryption and is equipped with a coordinator ZigBee node. Among several suitable microcontrollers, we choose the Freescale Kinetis K60 microcontroller. It includes a 32-Bit ARM Cortex M4 processor, hardware encryption and integrated Ethernet controller. The microcontroller exchanges information with the ZigBee chip, through UART communication at the maximum baud rate of 115200 (Figure 15).

(36)

28

The board measurements are about 120 mm x 56 mm.

3.2.1.2 Firmware

The gateway firmware is based on the lwIP TCP/IP stack [28]. When connected to a LAN equipped with a DHCP server (like most of home ADSL modem/routers) it can auto-configure its network interface. All the messages exchanged between the server and the gateway can be optionally encrypted using AES.

3.3 IoT Server and User interface implementation

3.3.1 Message dispatcher

The message dispatcher is implemented as a multi-process application written in C running on a Linux machine. The main application task continuously listens to new possible connections from gateways or other IP nodes. Every time a new TCP connection is established, a new process is created and remains active until the connection is closed by the gateway or a timeout occurred. This new process saves received packets in a UNIX named pipe, which is read by the data management unit. Moreover, the process collects from the config DB downstream data addressed to the gateway and delivers it.

3.3.2 Data collection and storage

The data collection unit is implemented using the CoMo platform software [31]. CoMo has been originally developed for the fast prototyping of network data mining applications and has been used in large testbed deployments, such as PlanetLab [32]. It is therefore scalable to very large systems and very high data rates.

The CoMo architecture presents an abstraction layer for the network interface and for the IoT server. Developers can implement new algorithms for processing sensor network data streams without any explicit knowledge of the internals of the monitoring system, transport media as well as memory and storage organization.

CoMo follows a classical modular approach that has proven to be successful in similar contexts [33]. The core system provides an API to enable the development of modules for each packet stream. Each module uses a common data model and specifies the information of interest (together with its resolution and accuracy) and the system identifies if that information is available. CoMo converts all incoming data streams in a unified packet stream that is then delivered to the subsequent processing queries [31].

(37)

29

In the context of the IoT platform, each CoMo module interprets the packets of a specific type of sensor network and extracts data to be further included in the sensor database or in the config database.

3.3.3 User interface, Configurator unit, Secure access module

The implemented web interface provides a subset of the functionalities defined by the architecture. We have chosen an implementation that

I. is easily scalable to many concurrent client connections, II. implements user authentication, and

III. is friendly to inexperienced users on different form-factor devices.

The web interface, configurator unit, and secure access module are based on Tornado [34], an open-source scalable non-blocking web server and web application framework written in Python. The graphical interface is responsive and rests on Twitter Bootstrap [35], a set of ready-to-use graphical elements. Among the many services, which could be provided by our architecture, we have implemented five main user interface functionalities:

• View sensor data: As shown in Figure 16, this page allows the user to visualize in a graphical way real-time and historical collected data of a sensor. The page provides a chart where data are plotted as a function of time and in the bottom a temporal range selector. On the right, a timepicker allows an easy selection of measurement period.

Figure 16: Example of the visualization of data from a smart meter in the implemented smart metering system

• Register and configure new networks: The administrator users can register and configure new network through dedicated pages (Figure 17). The network configuration is saved in the configurator database and an AES key

(38)

30

is generated and saved in the gateway and in the configurator database. This is the only action required to an administrator user to make its network visible.

Figure 17: New network registration page

• Network configuration and rights management: The network configuration page is shown in Figure 18. It allows the administrator (by three separate panels) to assign access rights with different privileges, to modify specific network options (netID, communication channel, security level, etc.) and to manage sensors visibility, grouping, and security.

(39)

31

• Register new sensors: The system automatically recognizes unregistered sensors sending data through a registered network/gateway. As shown in Figure 19, administrators can see unregistered sensors appearing on the very same page that lists all manageable sensors of the same network/gateway.

Figure 19:Unregistered sensors are automatically recognized

• Send commands: Authorized users can send commands to actuators, without dealing with the details of the communication protocol or of the physical node characteristics. All nodes are represented as one or more virtual devices (Figure 20) that can possibly accept commands. If this is the case, the command interface is visible to authorized users. When a command is sent through the user interface a JSON message is created containing the recipient ID and the command. This message is then converted into the correct sequence to be sent to the node. All messages are stored in a configuration database that is continually read by the message dispatcher.

Figure 20: Authorized uses can see possible commands that can be sent to each device functionality.

(40)

32

The user database and the config database are implemented with MySQL. The MySQL database is organized structure is shown in Figure 21.

Figure 21: MySQL Database main structure

The Tornado backend exposes direct access, after authentication, to the sensor data through HTTP. This makes conveniently easy to ask for sensor data directly from the JavaScript frontend through Ajax requests.

The Query returns sensor data for a given network id, sensor id and time range as an array of <timestamp, measure> tuples.

(41)

33

3.4 Experimental demonstrator

We have performed several extensive tests of the implementation to verify operation and reliability. Each element has been individually tested and validated. All sensors have been calibrated as described in Section 3.1.2. A complete demonstrator including all elements of the implementation and more than 10 sensors has run continuously for more than three months without loss of data in a laboratory setting, with quasi-daily addition and removal of sensors. As an example, data extracted from the demonstrator in a time span of about three hours from three smart meters are plotted in Figure 22.

Figure 22: Power consumption data collected from 3 common household loads and partial sum.

Data from a small refrigerator, an electric heater, and an expresso coffee maker show the typical features of the corresponding power loads.

3.5 Comparison with Related Works

Comparison with related works must consider recent literature in the neighboring fields of distributed sensor networks, home automation and smart grids. We can loosely classify the large number of related papers in two groups.

A set of papers focuses on the automation of the complete power distribution grid, of which the “last-meter” smart grid is only a subsystem. In this case, the complete grid includes power generation plants, transmission and distribution

(42)

34

networks, and “smart” consumers, with local generation capabilities, flexible usage and sometimes energy storage capacity. This large infrastructure is usually managed by a central server/data storage or SCADA system [36]-[38]. For obvious reasons, the proposed systems are described only at the architectural level, with an extensive discussion of the goals and objectives but with few details of the implementation. They also require substantial investments in infrastructure, especially for data transmission from the customer site to the last node of power distribution (“last meter”). Many transport options are typically proposed, such as the use of dedicated lines, to POTS/modem, power line communications (PLC), wireless links [39], [40]. Most of these projects include a “smart meter” used for both data collection and billing [9], which can be deployed only by the power distributor or in strict coordination with it. A pilot project deployed by a power distributor [41] required an investment of 10 M€ for the territory covered by a single primary distribution transformer (about 30 MVA). It is worth noting that deployed smart metering networks are usually based on PLC links [42].

With respect to this set of papers, the advantage and the uniqueness of our approach are apparent. Our proposal is “customer centric”, as opposed to “distribution centric”, in the sense that favors ease of deployment and user acceptance, leveraging the smart home trend to enable the merging of smart grid and smart home applications in customers’ homes. Indeed, our proposal focuses on the customer domain of the smart grid, possibly leaving the domains more evidently controlled by the utilities, such as transmission and distribution, to a “distribution-centered” treatment.

There is also another set of papers presenting home automation systems for power metering and analysis, which are therefore closer to the present paper. While [43] and [44] provide mostly an architectural description, [45]-[48] and [52], provide implementation details and a demonstration.

Most of the proposed implementations connect the home sensor or automation network to the wide area network or to a central server by means of a complex gateway, with large computational power (several MB of RAM and FLASH and a complete operating system) [48], [49]. Communication can occur for example via ZigBee and 6LoWPAN [47], [48], [52] but also dedicated point-to-point radio links are proposed in [45] and in [49]. The installation and configuration of this device makes the deployment of the system out of the reach of many end users. Ref. [48], [50] and [51] implement the data storage, analysis and user interface by means of a local server, assigning to the user the task to maintain and configure the system.

With respect to this other group of papers, the advantages of our proposed architecture and implementation consist in their intrinsic scalability to large-scale deployment. This is enabled by the choice of low-cost gateway and power meter (the bill of material of each is less than 15$), and by the accent on deployment by non-technical users.

(43)

35

4 HEALTH

CARE

AND

HOME

MONITORING

APPLICATION

According to a recent research by Raftery et al., the world's population is aging faster as expected and the number of people over 85 years will be larger than expected in 2000 [54]. By 2030, one in five US residents will 65 and older [55] and by 2050, in the world there will be more people aged 65 and older than those who have less than 15 years [54]. This trend is expected to increase the demand for healthcare and to increase governments’ expenditure on healthcare services.

A Brookings Institution analysis undertaken by Robert Litan in 2008 found that remote monitoring technologies could save as much as $197 billion (in constant 2008 dollars) over the next 25 years in the United States [56]. He found that cost savings were especially important in the case of chronic diseases.

To date, health devices and services, provided by medical device makers, are mainly targeted to chronically ill patients. On the other hand, in recent years, an increasing number of consumer electronics companies are developing health-monitoring devices targeted to healthy people, generally physically active, and very health conscious.

There is a gap between devices for seriously ill patients and those for healthy people [57]. Between these two extremes, there are the vast majority: overweight, hypertensive, diabetic, elderly people, that could benefit from devices and services enabling them to better manage their own health (Figure 23, taken from [57] ).

In the scientific and technical literature, many devices and solutions for monitoring health condition have been proposed. Almost all of them focus on specific technologies for a given health problem and try to solve the individual device-specific problems or propose solutions that are not easy-to-use by non-technical consumers.

Moreover, most at-home monitoring and test or diagnostic devices and systems in use today (glucose meters, thermometers, blood pressure cuffs, bathroom scales, etc.), even if sometimes wirelessly connected to a smartphone, are generally lacking direct Internet connectivity and are not able to communicate and interact with each other.

Thanks to recent advances in microelectronics and in wireless protocols, device connectivity can be added at very limited cost.

The above considerations motivated our idea to use the IoT platform discussed in Section 2, to design a system for heath home monitoring mainly addressed to elderly patients and non-technical consumers who need a long-term heath monitoring in non-clinical environments and in a noninvasive way.