Inte of Inter of Thi gh an IPv based S ervice nabling - D5.3 -v2.pdf · provide an IPv6‐based Web service allowing access to sensors and actuators connected to the card. In addition,

Univ

Orie

Grant ag

Grant ag

Start da

Project

Contract

Submiss

Version

Respons

Author l

Dissemi

Keyword

versal Inte

ented Arch

greement fo

greement n

ate of projec

Coordinato

t due date

sion date

sible partne

list

nation leve

ds

gration of

hitecture e

or: Collabor

no.: ICT ‐ 288

ct: October

or: Mandat I

Smart Bo

er

l

f the Inter

enabling h

rative Proje

8445

1st, 2011 (3

Internation

De

oard Intel

Version

March

0.8

Techn

Günth

PU

Intern

rnet of Thi

heterogen

ect

36 months d

nal (MI)

eliverable

lligence D

n 0.8 – April

h 31st, 2014

nical Univer

her Gridling

net of Thing

ings throu

neous com

duration)

D5.3

evelopme

l 7th, 2014

4

sity Vienna

g

gs, IPv6, Emb

ugh an IPv

mponents i

ent Report

bedded Linu

v6‐based S

interopera

t

ux

Service

ability

IoT6 D5.3 – Smart Board Intelligence Development Report

2

Table of Contents

1 Executive Summary .................................................................................................................. 4

2 Introduction .............................................................................................................................. 5

3 Related Work: IoT6 Components ............................................................................................. 6

3.1 Smart Board ....................................................................................................................... 7

3.2 IoTSys Legacy Device Gateway .......................................................................................... 8

3.3 Smart Routing .................................................................................................................... 8

4 Basic Software Architecture ..................................................................................................... 9

4.1 Development Environment ............................................................................................... 9

4.1.1 C++ Language ............................................................................................................. 9

4.1.2 Qt Embedded Library ................................................................................................. 9

4.1.3 Java Runtime Environment ...................................................................................... 10

4.2 Launcher Component Structure ...................................................................................... 10

4.3 Overview of Launcher User Interface .............................................................................. 12

4.3.1 Launcher Main Window ........................................................................................... 12

4.3.2 Message Output ....................................................................................................... 13

4.3.3 Floor Plan Display ..................................................................................................... 13

4.3.4 IoT6 Interface ........................................................................................................... 14

4.3.5 IoTSys Configuration Tree ........................................................................................ 15

4.3.6 IoTSys Device Tree .................................................................................................... 16

4.3.7 Local Hosts List ......................................................................................................... 17

4.3.8 Smart Routing Setup ................................................................................................ 17

4.3.9 Known Hosts ............................................................................................................. 17

4.3.10 Control Buttons ........................................................................................................ 18

5 IoT6 Component Integration .................................................................................................. 19

5.1 Integration of IoTSys ........................................................................................................ 19

5.1.1 IoTSys Interface Startup Phase ................................................................................. 19

5.1.2 IoTSys Interface Runtime ......................................................................................... 21

5.1.3 Configuration File ..................................................................................................... 22

5.1.4 Configuration User Interface .................................................................................... 22

5.1.5 IoTSys Process Output .............................................................................................. 24

5.1.6 Client Access ............................................................................................................. 25

5.2 Integration of Smart Routing ........................................................................................... 27

6 Optional Functionality for Demonstration Settings ............................................................... 29


3

6.1 Floor Plan View ................................................................................................................ 29

6.1.1 Locating a Device ...................................................................................................... 30

6.1.2 Updating a Device .................................................................................................... 31

7 Smart Board Deployment within an IoT6 Network ................................................................ 33

7.1 Distribution of Intelligence .............................................................................................. 33

7.2 Information in IoT6 Control and Monitoring Systems .................................................... 33

7.2.1 Individual point ......................................................................................................... 34

7.2.2 Point collection ......................................................................................................... 34

7.2.3 Point history ............................................................................................................. 34

7.2.4 Passive configuration ............................................................................................... 34

7.2.5 Active configuration ................................................................................................. 35

7.2.6 Control and monitoring unit .................................................................................... 35

7.2.7 Control and monitoring preferences ....................................................................... 35

7.2.8 User‐related data ..................................................................................................... 36

7.2.9 Intervention pattern ................................................................................................. 36

7.3 Distribution of Roles and Functions ................................................................................ 36

7.3.1 Functions in IoT6‐based Control and Monitoring Systems ...................................... 37

7.3.2 Control and monitoring system configurations ....................................................... 38

7.3.3 Roles in IoT6‐based Control and Monitoring Systems ............................................. 41

7.4 Routing of Information .................................................................................................... 43

7.4.1 'Smart Routing' mechanism ..................................................................................... 43

7.4.2 Smart Routing Applied to Alert Situations ............................................................... 44

7.4.3 Smart Routing in Topology Abstraction ................................................................... 44

7.4.4 Smart Routing in Fault Tolerance ............................................................................. 45

7.5 Communication Domains within an IoT6 CMS ................................................................ 45

7.5.1 Types of Communication Domains .......................................................................... 45

7.5.2 Information and Intelligence Distribution across Domains ..................................... 46

7.5.3 Domain Security ....................................................................................................... 47

8 Conclusion and Outlook ......................................................................................................... 52

9 List of Figures .......................................................................................................................... 53

10 References .............................................................................................................................. 54


4

1 ExecutiveSummary

The IoT6 project aims to define a possible architecture for the emerging “Internet of Things”, designed on the one hand to overcome most of the limitations of current Internet technology, and on the other hand to integrate recent developments and make use of their potential, in particular IPv6 addressing. (Deliverable 1.1)

Owing to the huge increase in both the number of nodes as well as their diversity in terms of hardware capabilities, basic network infrastructure such as resource discovery or routing will have to be adapted, if not completely re‐designed.

To that end, the IoT6 project proposes a novel and powerful resource discovery mechanism, the `Digcovery' (Deliverable D3.1), which allows global locating and retrieving of information on relevant nodes connected to or services provided by the network.

Furthermore, a content‐based `Smart Routing' mechanism was devised to improve the routing capabilities of the network, allowing in particular for more efficient routing of sensor values.

In addition to the above, any new architecture proposed for the Internet of Things will have to consider the huge number of devices currently deployed within established networks, e. g., in the building automation field. In order to keep the barrier of entry low, it should be possible to integrate such 'legacy' devices into the new architecture without too much trouble, and it should certainly not be a requirement to replace them with IPv6‐enabled sensors.

An IoT6‐based network therefore also comprises a 'Legacy Device Gateway', which can be connected to such legacy devices and networks, providing the necessary protocol translation in a transparent way, making them – in effect – IoT6‐enabled.

As part of the proof‐of‐concept demonstration, an embedded board – the 'Smart Board' – was developed within the project. It was designed to be flexible and powerful enough to handle all the tasks within an IoT6‐enabled network that can reasonably be expected to be assigned to an embedded board. Most importantly, this includes both the Smart Routing as well as the protocol translation described in the above. The board can and will also make use of the Digcovery service.

This report first presents the architecture of the software running on the Smart Board as well as the design decisions involved in developing it, and then describes how it integrates with the rest of the IoT6 framework.


5

2 Introduction

According to the Document of Work, Work Package 5 (WP5, `Smart board and intelligence distribution') is concerned with “physical layer heterogeneity and the distribution of intelligence”. It is to integrate results from Work Packages WP2, WP3, and WP4, and should provide an IPv6‐based Web service allowing access to sensors and actuators connected to the card. In addition, the Smart Board should be able to function as a “Smart Router” based on the Smart Routing concept developed in Task 3.2.

This report describes the work done within Task 5.2 (T5.2, `Smart board intelligence development') of WP5, which according to the Document of Work comprises the following two sub‐tasks (IoT6‐DoW):

“Develop a local rule manager enabling distribution of intelligence, including basic data recognition, interpretation, data filtering and differentiated addressing. The card should be able to interact with several control and monitoring systems in parallel, with a distribution of the roles and functions among those control and monitoring systems. It should be easily configurable and portable for the need off the research.

Develop and integrate an IPv6 web service on the multi protocol card to enable decentralized interactions with it from different IP clients. The web server should enable interaction with the card’s components such as sensors and actuators controlled by the card. This task will be coordinated with T2.2 from WP2 regarding the security mechanisms to implement in order to filter and prevent unauthorized access to the card.”

The second sub‐task is handled by the IoTSys multi‐protocol integration component. The implementation effort of the multi‐protocol translation was shared between WP4 and WP5, with WP5 contributing implementation of the various technology adaptors and deployment in the Smart Board environment. However, both the development and implementation of the IoTSys are described in a separate, dedicated document (Deliverable D4.3), as it did not make much sense splitting it between two different documents. For information about the IoTSys and its implementation and validation, we refer the reader to the aforementioned deliverable.

This leaves three main requirements for the task to be described in this document:

Deploying the IoT6 architecture components

The IoT6 components developed in WP2 to WP4 need to be either installed on the Smart Board, or must be accessible from it. This includes setting up the necessary software infrastructure as well as providing a means to start them. The rule manager mentioned in the Document of Work is the configuration of the Smart Routing component, as it provides the functionality described there.

Providing a central control and monitoring environment

As the IoT6 components are working together in demonstration and validation scenarios, the software application to be developed for this purpose should act as a global UI for the


6

components on the Smart Board. It therefore needs to interface to them, providing means for launch and visualization of output. It also needs to parse any possible error messages produced by those components and present them to the user within the graphical user interface. This provides the configuration component mentioned in the Document of Work.

Demonstrating some of the features of the IoT6 stack

To facilitate demonstration of some of the advanced features of an IoT6 network, it was decided to incorporate some basic client‐side functionality. Within the context of the entire project, this sub‐task may seem redundant, as the client‐side functionality will be demonstrated by the related work package efforts. However, in trade‐fair like settings (in particular Future Internet Assembly 2014, where the IoT6 project had a booth), where many demonstrations compete for the attention of interested visitors, a certain degree of horizontal replication of functionality across the individual parts of the project that are on display might make sense, as it could help grab some additional attention.

It should be emphasized that the software developed here is not a reference implementation, but intended to be used for proof‐of‐concept demonstrations of the results. Therefore, the software architecture will not be presented in great detail, as it consists mostly of standard user interface implementation procedures.

In the following, we will first briefly describe those parts of the IoT6 project that are being deployed on the Smart Board – and are thus particularly relevant in this context – in Section 3. After that, Section 4 gives an overview of the basic architecture of the Launcher, while Section 5 will give an overview of its core functionality, which is to integrate the various IoT6 components, as well as provide a graphical user interface for them. Section 6 will present some of the optional functionality the Launcher software provides. Lastly, Section 7 will give a brief overview of possible deployment scenarios of the Smart Board with the IoTSys in the context of the IoT6 network.

3 RelatedWork:IoT6Components

This section contains a very brief summary of other components of the project that this task relies upon. It is included for reference, to provide a basis for the description of the inter‐component interfaces to follow later. For detailed description of those components, we refer the reader to the related deliverables.

Subsection 3.1 gives a short description of the Smart Board, as it provides the hardware environment for the software developed in this task and therefore determines many of the choices made in developing the User Interface.

As to external software components, the main contribution is the IoTSys, which is described in Subsection 3.2. Lastly, a short overview of the Smart Routing component is given in Subsection 3.3.


7

3.1 SmartBoard

This chapter shall provide a brief description of the Smart Board and its features; for details, we refer the reader to the related documentation (Deliverable D5.2).

The main CPU of the Smart Board is the SPEAr320s (DS6590) from ST Microelectronics. It is an ARM926 implementation, i.e., an ARM9 core implementing the armv5 architecture. While it is not the most powerful architecture in terms of processing speed – a current, full‐featured Web browser, for example, will not run acceptably fast on it –, it was chosen for its good performance to power consumption ratio, which on an embedded system routinely should have priority over raw computing power.

A notable feature this core shares with other ARM architectures is the so‐called 'Jazelle technology', which provides hardware‐supported execution of Java byte code. A very important feature for embedded boards in general, it is particularly relevant in the context of the IoT6 proof‐of‐concept implementation, as the IoTSys is a sizeable Java application which needs to be deployed on the Smart Board.

The relatively small on‐chip memory of 32 KB boot‐ROM and 8 KB RAM is of course insufficient, and therefore external memory was added. Currently, the board is populated with 128 MB DDR2 RAM, with footprints provided for an extension to 256 MB. In terms of non‐volatile memory, a small serial FLASH of 8 MB is provided, but the main on‐board program memory is provided by a NAND FLASH of 512 MB size.

While those 512 MB are certainly sufficient for a wide range of embedded applications, a software environment with an embedded Linux plus a few sizeable applications could still push that limit. Nevertheless, the current amount of FLASH makes sense considering that the board has a USB subsystem, meaning it is possible to extend the space for a file‐system with a standard USB memory device. In fact, the current software setup is quite rich in features, including the Java environment and even an X‐windows environment for various tests with embedded Web browsers. Since it is a proof‐of‐concept and demonstration setup, it is not really optimized for small memory footprint, therefore exceeding that 512 MB limit. However, it has been installed on and run from an external USB drive with no problems.

Additional functionality of the Smart Board is provided by the STM32W108 controller connected to the main CPU. It contains an IEEE 802.15.4 wireless transceiver, which – together with a software implementation of the 6LoWPAN protocol – could allow the Smart Board to function as a border router, connecting low‐power wireless devices to the IPv6‐enabled IoT6 network. In the current demo setup, however, 6LoWPAN connectivity and routing is provided by an external gateway node.

As for the operating system used, due to the fact that the main CPU is the SPEAr320 from ST Microelectronics, and the board architecture itself naturally derives much of the standard circuitry from the SPEAr320 reference implementations, there is a certain degree of similarity between the Smart Board and evaluation board implementations provided by ST Microelectronics, in particular the EvalSPEAr320S in its HMI version. Since ST Microelectronics provides a Linux variant for their boards called STLinux (RN0080) (UM0851), it seemed like an obvious choice to use that on the Smart Board. In fact, STLinux can be deployed with some


8

modifications and some additional software packages; the basic installation procedure has been described in the related IoT6 Deliverable D5.2.

3.2 IoTSysLegacyDeviceGateway

A project that aims to define a possible architecture for the future Internet of Things based on the IPv6 addressing standard will have to consider the innumerable devices that are already deployed, and provide some means to integrate them into the network. This is the main motivation for the IoTSys component (Deliverable D4.3), which allows to connect various legacy protocols – most of which are related to the home and building automation domain – with an IPv6‐enabled network and hence the IoT6.

The IoTSys is a command‐line Java‐application that can be accessed via CoAP over IPv6, and which uses custom technology adaptor components to provide protocol translation between CoAP/IPv6 and a particular legacy bus system, e.g., KNX or BACnet. Each such technology adaptor can have a number of different connectors, which are responsible for attaching one legacy bus system of the given type to the IoTSys, thereby making it accessible via CoAP.

A configuration file in XML format defines the available technology adaptors as well as the connectors each of them has installed. Furthermore, it defines additional information for each device, as most of these legacy devices were never meant to be accessed via CoAP and thus do not provide sufficient information on their own. The data provided for each device consists of a device name, a reference name under which it can be accessed from the CoAP side of the network, and various optional pieces of information, like device type or location.

3.3 SmartRouting

The Smart Routing developed in WP3.2 (Deliverable D3.2) is a source‐based routing mechanism based on ip6tables.

The sender of a message indicates – by setting the flow label accordingly – how a message is to be routed. E. g., in the current demonstration setup, there are two possible destinations for a temperature value message: One for values that are within the expected range, and one for values that exceed that range. Whether a value is out of range is determined at the sender, and the flow label is set, and the message is sent to a Smart Board set up to operate as a smart router.

Upon receiving a message, a Smart Board configured to be a smart router will inspect the content of the message and retrieve the flow label. If it contains one of the pre‐defined destination codes, then it will replace the receiver address with the address assigned to that destination code. Finally, it will forward the message to that destination address.


9

4 BasicSoftwareArchitecture

The IoT6 Launcher described in this document is intended to automatically start on the Smart Board upon power‐on; it was designed mostly for the following two application scenarios:

Providing an environment to set up and launch the IoTSys Gateway as well as the Smart Routing feature during routine testing and development work on either of the involved components.

To facilitate a demonstration of some features of an IoT6 network – mostly those that are directly related to the Smart Board, that is, multi‐protocol integration and Smart Routing, but to some degree also other features like Digcovery.

4.1 DevelopmentEnvironment

The choice of development environment was very much influenced not just by the requirement to run the IoTSys and the Smart Routing, but also by the Smart Board hardware – in particular the availability of a 640x480 full color screen as well as the fact that the main processor was chosen for its power‐efficiency, which results in a somewhat limited computing performance.

4.1.1 C++Language

It should be emphasized that the IoT6 Launcher is designed for internal use as well as demonstrations during the lifetime of the project; the actual design of the embedded software in a real‐world deployment will very much depend on the particular applications and the environments available at the time.

In addition to that, the IoTSys is already taking up a considerable amount of resources both in terms of memory as well as computing power, depending on the complexity of the interfacing it has to provide.

With this in mind, efficiency both in runtime speed and memory consumption was prioritized over portability, and it was therefore decided to use C++ instead of Java in the implementation. The reduced runtime overhead of C++ will result in somewhat higher performance and a more compact memory footprint, which leaves some room for any possible additional requirements that might come up late in the project.

Note that the Launcher could of course share the Java runtime environment that is already used for the IoTSys, which would make the memory footprint of a Java implementation more favorable than a stand‐alone version in comparison to a C++ implementation. However, the Launcher provides the option of having the IoTSys run on an external server, or on a second, dedicated Smart Board, in which case the Java environment would not necessarily be available.

4.1.2 QtEmbeddedLibrary

For the usage as a setup and configuration utility, a simple interface – even a command‐line‐based one – would certainly have been sufficient; however, in the context of a demonstration, it is of vital importance that the application provides a reasonably appealing interface in terms of visual appearance. In order to ease the task of providing the application with such a graphical


10

user interface within a reasonable time frame, it was decided to use the Qt Embedded library (qt.digia.com).

This library provides a set of classes for basic functionality required to develop a graphical user interface – support for basic user interface elements like window frames, buttons, check‐boxes, and so forth. In addition, it contains classes which help in interfacing with the underlying operating system – in terms of access to the network subsystem, for example.

4.1.3 JavaRuntimeEnvironment

As described in the above, the Launcher in itself makes no use of Java, as C++ was chosen for its implementation. However, in order to run the IoTSys reference implementation on the Smart Board, a Java environment is required.

The Java implementation that was chosen for the Smart Board is the Java SE Embedded as provided by Oracle (Java SE Embedded). It provides a small enough footprint, and is available for the armv5 architecture employed on the Smart Board. Currently version 7 update 10 is installed, and has proven to be sufficient to run the IoTSys.

Note that the SE Embedded does not include a Java compiler, so the IoTSys Java source code needs to be compiled on a host PC.

4.2 LauncherComponentStructure

The Launcher has to interface to various software components, the obvious ones being the IoTSys and the Smart Routing. However, as it provides some information to help set up the IPv6 configuration, it also needs to interface to the underlying network. The basic structure of the software is shown in Figure 1.

The launcher core contains most of the actual program logic. The user interacts with it through the various parts of the User Interface – the IoTSys setup, the Smart Routing setup, the Network setup, and the Query interface. All of these are located in different panes of the main application window, some of them in different tabs, to save screen space.

On the other hand, the launcher core utilizes the process interface to start and control various sub‐processes – most notably the IoTSys, but also the ip6tables‐ and the ping6‐commands.

In order to setup the IoTSys and provide the user the means to review its configuration, the launcher will parse the IoTSys configuration file (the default name of which is 'devices.xml') and present it in a tree structure for easy access and review. There, the user can modify parts of the configuration and write back the configuration file.

The individual interfaces between these components are described in more detail in the following sections.

IoT6 D5

.3 – Smart BBoard Intelli

igence Deve

Figure 1

elopment Re

11

1: Component D

eport

Diagram


12

4.3 OverviewofLauncherUserInterface

The Launcher is provided with a graphical user interface containing multiple panes, some of them tabbed. Both for the originally intended usage of the Launcher as well as the size of the screen, it is somewhat overloaded – production software for this environment would likely be somewhat simpler and better organized. However, as mentioned before, the Launcher is not designed for permanent use, but rather to be able to show a good amount of functionality during a very brief demonstration.

4.3.1 LauncherMainWindow

A screenshot of the main window the user is presented with upon startup is provided in Screenshot 1. It is vertically partitioned into three main areas: The message output pane on top, which is flanked by the two logos; the actual IoT6‐related area in the middle, which initially shows the floor plan view and the IoT6 configuration tree; and finally the setup support area at the bottom.

Screenshot 1: Launcher Main Window

The various panes located within the main window areas are briefly described in the following.


13

4.3.2 MessageOutput

This pane provides generic user feedback concerning the IoT6 components running on the board itself as well as any external ones.

Screenshot 2: Message Pane

In particular, error messages produced by the processes related to IoTSys or Smart Routing are displayed here. In addition to that, it will also show some relevant feedback about the state of the IoTSys, e. g., watch messages. Since the latter in particular can arrive quite frequently, in order to provide a clean overview of important messages, the message pane has been split into two different panes sharing the same screen space, a ‘general’ one (G), and a ‘verbose’ one (V), which can be switched using the tabs at the right side of the pane.

4.3.3 FloorPlanDisplay

This part of the main window shows a mock‐up floor plan.

Screenshot 3: Floor Plan Pane

The point of this feature is supposed to provide a somewhat appealing demonstration of an IoT6 network's intrinsic ability to discover resources and provide information about them, in this case related to building automation devices. It works in concert with the device tree view, which will be described below.


14

4.3.4 IoT6Interface

This pane, which shares a tab area with the floor plan view, is meant to provide access to the IoTSys, the Digcovery, and the STIS (Deliverable D6.1) (Deliverable D6.3).

Screenshot 4: IoT6 Interface Pane

Either of these interfaces is assigned a checkable group frame, which can be used to switch between them. Pressing the ‘Query’ button will then issue the query to the activated IoT6 service.

In the case of IoTSys access, it provides an entry field for the address of a GET request, and a second one to enter a payload for PUT requests. The large text output field in the right half will show the result of the query.

For Digcovery access, an entry field for a generic query is provided; the result will again be printed to the output field on the right‐hand side.


15

4.3.5 IoTSysConfigurationTree

Upon startup, the right‐hand side of the main window will show the IoTSys configuration tree, representing the hierarchy of technology adaptors, connectors, and devices the IoTSys is set up with.

Screenshot 5: IoTSys Configuration Tree

All information contained in it is parsed from the IoTSys configuration file devices.xml. It lists in its root the device loaders and the technology adaptors. The latter can be opened to show the individual connectors for each technology, as well as the individual devices assigned to each of them.

An IoTSys device can be configured with location information in the configuration file, since legacy devices usually have no means to provide such information. If a device is provided with location information, upon clicking on the device, the Launcher will display it in the floor plan, by zooming and panning to the device's location.


16

4.3.6 IoTSysDeviceTree

Sharing a tabbed pane with the configuration tree, the device tree displays the actual devices as reported by the IoTSys in response to the initial oBIX lobby request sent by the Launcher.

Screenshot 6: Device Tree

Each device node in the tree has one or more child nodes, which represent the individual values reported by the IoTSys for that particular object. Apart from the value name, the Launcher will create an appropriate user interface control element – e. g., in the case of a bool value, it will be a button, and in the case of an int or real value, it will be a slider control (cf. Screenshot 7).

Screenshot 7: Device Tree ‐ Interaction Controls


17

4.3.7 LocalHostsList

At the bottom right of the main window, the Launcher reports all the IPv6‐enabled hosts it could detect on the main network interface. This supports the setup and configuration of the local IPv6 network segment for testing purposes.

4.3.8 SmartRoutingSetup

In the demonstration setups currently envisioned, the Smart Routing component has to relay messages originating from a temperature sensor differently, depending on the content of the message's flow label field.

Screenshot 8: Smart Routing Setup

The user interface for the Smart Routing component allows the user to set the two possible destination addresses, one for 'normal' values, and one for 'high' values. The distinction is made based on the flow label, which the sender of the message has to set.

4.3.9 KnownHosts

A minimal demonstration setup comprises various building automation devices with a local Gateway, possibly a laptop PC, an optional second Smart Board, and – again optionally – a Digcovery server and an STIS server. To support the setup of such a system, the Launcher can be configured to periodically check whether the IPv6 address of each of these hosts is reachable.

Screenshot 9: Known Hosts Access

If the group frame check box is active, every two seconds the Launcher will send a ping to each of these known hosts in sequence. If a response is received, the checkbox for that host is checked, otherwise it is cleared.

Again, this feature was intended to help set up the network connectivity; it is usually not needed and can therefore be switched off by un‐checking the group box.

IoT6 D5

4.3.10 C

Lastly, th

The 'Reconfigurchooses

.3 – Smart B

ControlBu

he main win

load' buttoration have s to do so in

Board Intelli

uttons

ndow shows

n will shut been made a confirma

igence Deve

s two user b

down and e. The 'Exittion dialog

Screensho

elopment Re

18

buttons in t

restart the' Button wiwindow, als

ot 10: Control B

eport

he bottom

IoTSys; thiill shut dowso the entir

Buttons

right corner

is can be uswn the Laune Linux syst

r (cf. Screen

sed if changncher and, item.

nshot 10).

ges in the f the user


19

5 IoT6ComponentIntegration

The IoT6 Launcher's main purpose is to run the IoTSys and the Smart Routing feature on the Smart Board, and to provide access to them via a graphical user interface. In the following, we will describe how these two components have been integrated into the Launcher environment.

5.1 IntegrationofIoTSys

The biggest external component in terms of resource usage is the IoTSys. It is a – for an embedded environment quite extensive – Java application using the Apache Felix package.

The integration of this IoTSys component is done by means of a 'wrapper process', which starts the application as a child process, providing input parameters as required, and parses the output of that child process, which is then used to provide the user with feedback about the state of the IoTSys subsystem.

5.1.1 IoTSysInterfaceStartupPhase

The startup sequence for the IoTSys process interface is shown in Figure 2 below as a state diagram.

Figure 2: IoTSys Integration, Startup Phase

For added flexibility, it is possible to configure the launcher for the use of an external IoTSys, by providing the IP of a server where an instance of the IoTSys is running: In this case, upon startup the launcher will issue a query to that server; if an acceptable IoTSys response is received, this server address will continue to be used.

If no response is received, the launcher will attempt to start a local IoTSys, by spawning a process and issuing the appropriate command line. The standard and error output of the process are monitored, and if an error occurs, the IoTSys interface is disabled.

Startup

Entry / initializeEntry / query IoTSys

No IoTSysresponse

Read lobby

Entry / issue queryResponsereceived

Launch IoTSys

Entry / start processDo / parse outputExit / emit signal

IoTSys startconfirmed

Create lobby list

Entry / parse responseEntry / query 1st device

Lobby datareceived

Read device

Entry / parse dataEntry / create itemEntry / query next

Device datareceived

No startconfirmation

Create device list

Entry / create listEntry / create controlsExit / emit signal

IoTSys running

Entry / set flagDo / parse output

No datareceived

Datareceived

IoTSys stopped

No datareceived


20

If either the external IoTSys responded or the local IoTSys was started successfully, a message is sent requesting the oBIX lobby. The response is parsed and a list of known oBIX objects is generated from it, which is the basis of the 'devices' list shown in the user interface. Then, for each of the objects successfully parsed, an individual request for the object's values is sent. Again, the response messages are parsed, and the values recognized are added to the corresponding object structure.

If either no lobby data is received, or all requests for object data failed, the IoTSys interface is disabled.

Figure 3: Device List, oBIX Object Setup

A sequence diagram of the query process for a single object is shown in Figure 3.


21

5.1.2 IoTSysInterfaceRuntime

Once the lobby and its objects are successfully retrieved, the IoTSys interface enters runtime mode, as shown in Figure 4.

Figure 4: IoTSys Integration, Runtime Phase

During runtime, the output of the IoTSys process is continually monitored and checked for error messages. In addition, watch messages are retrieved from it, as those are written to one of the standard outputs by the IoTSys executable.

If the user interacts with one of the user interface elements connected to an oBIX object value, the appropriate message will be sent to the IoTSys, and a state is entered in which a response is expected. If no response arrives, or if the content of the response does not match the value set by the preceding request, then an error is reported.

It is also possible to issue a query manually, that is, enter a request address (for a GET request) and optionally some payload data (for a PUT request) and issue them directly to the IoTSys. Again, a state is entered where the launcher waits for a response. However, in this case the response is merely printed out in the response window.

In addition to the IoTSys watch mechanism (which is received through the process output), the launcher implements its own polling watches. An object can be set to be polled periodically. Similar to an oBIX object interaction, when the timeout occurs, a request is sent to read the current value of the given oBIX object value, and a waiting state is entered until the response is received. If the response is parsed successfully, the user interface object associated with the given oBIX object is updated accordingly – which can be a user interface element in the device tree display, or an object in the floor plan display (more on that below).

IoTSys running

Entry / set run flagDo / parse outputDo / check processExit / clear run flag

Shutdown IoTSys

Entry / kill processDo / parse outputExit: print result

Stoprequested

IoTSys stopped

ProcessErrordetected

Device interaction

Entry / issue queryDo / parse output

Manual interaction

Entry / issue queryDo / parse output

Error handling

Entry / print warningDo / state checkExit: print result

Watch handling

Entry / update objectDo / parse output

No validconfirmation



UI control operated

Watch update received

Confirmation received

Query entered



Spurious response

State check OK

Start IoTSys

Entry / start processDo / setup UI env.Do / monitor process

RestartShutdown

Process error detected

No processerror

State check FAIL


22

If the user indicates they wish to exit the launcher, the IoTSys process is terminated, and any error messages that are received from it are reported.

In case the user merely wishes to reload the IoTSys, which will usually be in order to read in a modified configuration file, then after terminating the old process, the startup phase according to Figure 2 is entered once again.

5.1.3 ConfigurationFile

The IoTSys subsystem is configured by an XML file named 'devices.xml'. This file describes the three classes of components used in an IoTSys setup: The technology adaptors, the connectors, and the devices that are connected to them.

Adaptor definition

Adaptors define various legacy protocols – for example, there might be an adaptor for KNX and one for BACnet. For each protocol to be integrated into the IoT6 network, a dedicated adaptor must be implemented.

Connector definition

A connector can be seen as an instance of an adaptor, connecting one individual subnet of the technology type defined by the parent adaptor to the common, IPv6‐based network, providing the necessary protocol translation.

Device definition

Lastly, individual devices are defined for each connector. The definition of a device in the XML file provides for two requirements: One is that protocol‐related information must be provided in order for the connector to be able to access the device – e. g., some form of device address or ID. Secondly, the device definition must provide default values for information an IoT6‐enabled device can be expected to provide – e. g., the location of a device within a local installation. While the former is necessary to make the device accessible in the first place, the latter in effect turns the device into an IoT6‐enabled one.

5.1.4 ConfigurationUserInterface

The IoTSys requires a decent amount of configuration – after all, it has to connect legacy devices which are not IoT6‐ or even IPv6‐enabled to an IoT6 network, which means it must not only translate the protocol in both directions, but must also substitute some basic configuration data for these devices.

5.1.4.1 ConfigurationviatheDeviceDescriptionFileThe IoTSys can and has been configured by manually editing this XML file, but this requires some knowledge of its inner working. In order to allow some configuration to be done by someone not familiar with the implementation of the IoTSys, the Launcher parses the XML file and offers basic setup capabilities. Most of the information provided in the XML is parsed and then displayed in the user interfaces as a tree, which can be navigated by the user, providing means to (re‐)configure the IoTSys from the GUI.


23

The device loaders are included in the tree merely for information purposes, to be able to verify that all required loaders are configured. No interaction is possible.

For the other elements, the possible interactions can be selected from a context menu which can be opened by either right‐clicking them with the mouse or double‐tapping them on the touchscreen.

The following options are provided for adaptors:

Enable This allows to enable or disable the adaptor by checking or un‐checking it, which is generally used to enable or disable an optional part of a demonstration setup.

Reload Adaptors can also be reloaded by selecting this menu item. Note that the reload of an adaptor is asynchronously issued to the IoTSys process. The adaptor will appear inactive (greyed out) in the tree, and will change back to active once it is reloaded.

Reloading an adaptor will of course reload all its associated connectors.

Connector list Like adaptors, connectors can be individually enabled or disabled, which is often used to switch a configuration between two different settings.

Now, it would certainly make sense to use the same user interface – that is, checking or unchecking an enable item in their associated context menus. However, a typical XML configuration file can contain a large number of connectors, only a small subset of which are used at any given time. Even in their disabled state, each of them would have to be displayed in the configuration tree, to provide a way to access the context menu and re‐enable it.

To make the tree more compact, it was therefore decided to move that functionality up to the adaptor they are assigned to; that way, it is not necessary to show disabled connectors in the tree, which simplifies the tree considerably.

The possible interactions for connectors are very similar to those available for adaptors described in the above.

Enable The context menu of a connector provides an entry to disable it by un‐checking the item. However, note that this will make the connector disappear from the configuration tree, and it can only be re‐enabled by opening the ‘connectors’ submenu in its parent adaptor and checking it there.

Reload Individual connectors can be reloaded by selecting the 'reload' item. Similar to the way it works with adaptors, it is an asynchronous action: The connector – and all devices assigned to it – will be greyed out in the tree while the reload is in progress. The connectors will be activated again once it is loaded, and subsequently connection to the devices will be re‐established.

Device list As is the case with connectors and adaptors, each connector can have a large number of devices configured, only a small subset of which may be active in a particular setup. Therefore, the


24

context menu of the parent connector contains a sub‐menu with a list of the devices assigned to this connector, where each device has a checker to enable or disable it. Note that the enabled state of devices can be written to the XML configuration file, which is currently not the case for adaptors and connectors.

Lastly, a context menu is provided for the individual devices:

Enable Similar to a connector, a device can be disabled by un‐checking this item, which will remove it from the configuration tree, so it can only be re‐enabled from the devices submenu of the connector it is assigned to.

Modify Selecting this menu item will open a dialog window showing the configuration of the device and providing a means to modify it. Pressing the 'Apply' button in that dialog will reload the connector this device is assigned to.

Add new This menu item will bring up a dialog window similar to the above. Here, a new device can be entered, along with the desired configuration data. Pressing the 'Apply' button will create an appropriate entry in the devices XML file and once again reload the associated connector.

5.1.4.2 IoTSysProcessCommandLineThe command line used to start the IoTSys process merely provides the Java Environment with the name of the jar‐file containing class and resources for the Apache Felix environment, which is in turn set up to initialize the IoTSys‐related classes.

Currently, the XML file described in the above provides all device configuration information the IoTSys needs for its operation, so there are no device‐related parameters used in the launch command at this point.

5.1.5 IoTSysProcessOutput

During a typical run, depending on the specific configuration, the IoTSys can write a large amount of information to the standard and error output channels. As described in the above, this output is read and parsed by the Launcher. The most important items that are parsed and derived from the process' output are as follows:

Devices detected Any report of a detected device is parsed for the unique href of the device, which is then used to find the associated connector. For each active connector, the number of currently detected devices is shown in the IoTSys Configuration Tree.

Watches reported If a watch is set up for a particular oBIX object value, the IoTSys will periodically report the current value. These reports are parsed and the state of the object in the Launcher's internal data structured is updated accordingly. For devices which are configured with a location, these


25

messages can be used to update the state of the associated graphical item in the floor plan view.

Error messages Naturally, error messages are parsed as well. There is a number of messages reported by IoTSys, but only a subset of them is actually relevant to the user, so only those are parsed and printed in the general message display of the Launcher main window.

5.1.6 ClientAccess

Normally, the IoTSys interaction described previously would be quite sufficient for the Launcher software, as it enables it to start the IoTSys and have it perform its protocol integration for various clients connected to the Smart Board via IPv6.

However, as mentioned earlier, it was decided to incorporate some additional functionality into the Launcher, to provide a minimal show case for IoT6 functionality in constrained setups that may lack the resources to provide a full‐fledged demonstration.

Therefore, in addition to the above, the Launcher also utilizes the interface that a normal client would use to access legacy devices via an IoTSys Gateway, by issuing HTML POST/PUT messages and receiving the responses. This is used mainly in two ways – to access individual oBIX object values through the graphical user interface, and to augment the floor plan with position and state information on individual devices, as described in the following.

A third way of interaction with the IoTSys is the generic IoT6 component interface, where GET or PUT requests can be typed in manually.


26

5.1.6.1 DirectValueControlUIManual control of devices – or rather their values – is possible through the device tree tab. In that tree structure, each device is represented as a root node, with a child node for each value defined in the associated oBIX object. Depending on the type of the object value, a suitable user interface element for controlling the value state is created next to the value name – e. g., for bool values, it will be a button representing the state of the value, and for int or real values, it will be a slider.

Figure 5: Device List, Control Interaction

Any interaction with one of these user interface controls will prompt the Launcher to assemble a HTML PUT message to the address given by the associated oBIX object's unique href, with a


27

payload created from the value's definition and state. A sequence diagram of such an interaction is shown in Figure 5.

In order to avoid spamming the IoTSys with messages – in particular those that are created from moving a slider for real or int values – these messages are put in a queue and issued to the IoTSys with a fixed time period, which is currently set to 250 ms. Moving a slider may produce value change requests at a much higher frequency internally, but before a message is queued, the current queue is checked for messages concerning that particular value. If one is found, then no new message is queued, and instead the value in the one already present in the queue is updated. This way, update requests for any particular value are guaranteed to be sent at most every 250 ms.

Once a message is sent, the Launcher expects to receive a confirmation from the IoTSys. This means it sets an internal state flag such that any incoming message over this particular connection will be checked and matched with the most recently sent PUT request. If the message is not a syntactically correct value PUT confirmation, or the state of the value in the confirmation message does not match the state set by the PUT request, a warning is reported.

5.1.6.2 ManualCompositionofIoTSysRequestsFrom the IoT6 components pane, which shares a tabbed area with the floor plan, it is possible to directly enter text for GET and PUT commands, which can then be issued to the IoTSys.

5.2 IntegrationofSmartRouting

As described in Section 3.3, Smart Routing can relay messages to different destinations based on the flow label set by the sender of a message. In order to provide a configuration interface for it, access to the ip6tables rules is required.

To keep the interface as robust as possible, the same mechanism is used as in the case of the IoTSys component above, namely a wrapper process around the ip6tables command. This command is basically used as a stable, well‐defined interface to the underlying configuration files of the Linux networking subsystem.

At this point, Smart Routing is used mainly to relay sensor messages to one of two different destinations: One for values that are classified as 'normal', that is, values that are within an expected range depending on the type of value and the type of sensor, and another one for values classified as 'alert', which are those that lie outside this expected range.

Therefore, currently an interface is provided to allow for the configuration of the IPv6 addresses for these two hosts. Upon entry of an address, the wrapper process is set up to call the ip6tables command with the following command line:

ip6tables ‐t raw ‐L

This will produce as output the list of rules currently set in the raw table. This list is then parsed to check whether a destination for the given value class is already configured in the PREROUTING chain. If that is the case, the process is called again with a command line set up to delete the respective line in the PREROUTING chain:


28

ip6tables ‐t raw ‐D PREROUTING <RULE_NUMBER>

The RULE_NUMBER will be the one retrieved from the output of the list command issued earlier.

After that, or if there was no rule to begin with, a rule for the new destination is added to the PREROUTING chain, using a shell process with the following command line:

ip6tables ‐m u32 ‐‐u32 "0&0xF=0x<CLASS>" ‐t raw ‐I PREROUTING

‐i eth0 ‐d <SB_IPv6> ‐j RAWDNAT ‐‐to‐destination <DEST_IPv6>

Here, CLASS is the identifier for the value class, i. e., whether it concerns 'normal' or 'alert'

values, SB_IPv6 will be replaced with the relevant network interface on the Smart Board, and

DEST_IPv6 will be the destination address entered by the user.

Figure 6: Smart Routing Setup, Rule Added

A sequence diagram of the insertion process is shown in Figure 6.

For all these commands, the output is parsed and checked for possible errors, which are reported to the user.


29

6 OptionalFunctionalityforDemonstrationSettings

So far, most of what has been presented can be considered core functionality of the Launcher; it provides a basic graphical user interface to the underlying components, which can be important, if only in terms of accessibility and appearance during demonstrations.

In this section, we will describe some of the optional functionality, which was not originally part of this task, but was later added.

6.1 FloorPlanView

The main component of that optional functionality is the floor plan view, which although unrelated to the core functionality expected from the Launcher, helps to demonstrate how devices using a variety of different protocols can be integrated into the same IoT6 network, and how the representation of a building automation network can be enhanced with the ubiquitous access to device information provided by the Digcovery.

Figure 7: Floor Plan View

An example of the floor plan view as it might be presented to the user upon startup is shown in Figure 7.

It presents the user with an abstract and simplified floor plan view of a hypothetical building, in which some of the devices configured in the demonstration are supposed to be installed. The view can be freely zoomed and panned.

This view is intended to provide a demonstration of IoT6 functionality in the context of a building automation environment.

There are currently two floor plan related features implemented that can be used to demonstrate IoT6 functionality: Locating a device and updating a device’s status.


30

6.1.1 LocatingaDevice

In order to locate a device in the floor plan, it can be activated in the configuration tree by clicking on it. The Launcher will then retrieve the href from the IoTSys as an identifier and in turn access the Digcovery to retrieve the device's coordinates. The floor plan view then pans and zooms the component's location into view and marks it with an animated circle.

Figure 8: Floor Plan, Locating a Device

A sequence diagram of the process used to locate a device in the floor plan view is shown in Figure 8.

This feature can be used to point out the ubiquitous availability of per‐device information provided by the Digcovery component: The Launcher software, which in this case represents some generic client software component, can use the known, unique identifier of a device – in this case its href – in order to retrieve additional information from the Digcovery – here, the device's location within the building.


31

6.1.2 UpdatingaDevice

The Launcher can also automatically update a device’s representation according to a change in its state. Currently, this is only implemented for ‘door open’ sensors, which should be sufficient to demonstrate the concept.

This update of a device’s state can be prompted by using the IoTSys watch mechanism, which prompts the IoTSys to send a message whenever a device value changes. The sequence for this is shown in Figure 9.

Figure 9: Floor Plan, Watch Update

The Launcher also implements a polling mechanism for device states, where it periodically requests the state of a device value by issuing a GET request to the IoTSys, and parsing the response message for the current value, as shown in Figure 10.


32

Figure 10: Floor Plan, Polling Update


33

7 SmartBoardDeploymentwithinanIoT6Network

In the previous sections, we gave a brief overview of the IoT6 components deployed on the Smart Board, as well as the software that was developed for the Smart Board specifically to integrate and control those components.

In the following section, we would like to show possible use case scenarios for the functionality provided by the Smart Board within the context of an IoT6 network. To that end, we will give an overview of possible IoT6 setups, in particular with respect to the ‘Things’ part of the network, that is, the control and monitoring aspect of it.

It should be emphasized that these are just possible configuration scenarios intended to show some of the potential of an IoT6 network; the actual demonstration use case and component setup will be described in the related deliverables of Work Package 7 (Deliverable D7.2) (Deliverable D7.3).

7.1 DistributionofIntelligence

In order to make a network as robust as possible against failures of individual nodes, essential services and information should be distributed, eliminating single points of failure as far as possible. In theory, standard redundancy mechanisms can be applied and should make sure the network can tolerate local failures; however, as with any other network, an IoT6 network will have to compromise when the accumulated cost of redundancy is figured in. In any realistic setting, due to limited resources, a potential for failures that may cause downtime for some services will still remain. The key design issue, however, is to make sure that local errors can have at worst local consequences; whatever the failure mode is, the failure of a particular node should only impact services in the immediate topological neighborhood.

In the context of IoT6 control and monitoring systems, the main enabler of intelligence distribution is the UDG; the mechanisms used in the distribution of intelligence are described in a separate document (Deliverable 4.2). At the low level, a form of ‘embedded’ intelligence is provided by the oBELIX mechanism, which is part of the IoTSys (Deliverable D4.3).

7.2 InformationinIoT6ControlandMonitoringSystems

The IoT6, being based on the concept of the 'Internet of Things', unifies two different network domains, namely the Internet and a generic networked control and monitoring system integrating legacy components.

With regards to the Internet aspect, there is little choice as to what type of information will be distributed through it. It would be extremely hard, if not impossible to impose noticeable restrictions in the IoT6 as compared to the current Internet, as these might create severe acceptance barriers. Of course, an important part of the IoT6 is additional security mechanisms, and increased security often brings with it some unwanted restrictions for authorized uses. However, these must be implemented very carefully, or they will be either circumvented, or even outright rejected. For a discussion of the general security mechanisms in IoT6 networks, see the related document (Deliverable D2.2).


34

In the control and monitoring domain, some classification of information is possible, based on the functionality provided by IoT6‐based distributed control and monitoring systems.

7.2.1 Individualpoint

Being the smallest unit of information in the control and monitoring domain, data point and set point values are the basis for all feedback control loops, which represent the lowest level of functionality in a control and monitoring system.

Individual values are also structurally the simplest type of information. At the extreme end, it might just be a single numerical value – as long as the interpretation of the value, that is, the semantic context of this data point is implicit. Somewhat more complex, such a low level value can also be augmented by explicitly providing the semantic context via properties like units or association with other concepts.

7.2.2 Pointcollection

For monitoring purposes, it will often be useful to transmit a whole collection of data and/or set points, representing a ‘snap shot’ of the current state of some section of the system. As those values will generally not be fed back into the controlling loops, they could be considered less critical; on the other hand, they represent a collection of multiple individual values, so security requirements could be assumed to be the same.

7.2.3 Pointhistory

Much like accumulated point information, point history would be a set of individual point information units; the difference would be semantic, as in this case, the points represent different states of the same point accumulated over time, not states of different points within a certain area. Security requirements should be at the same level as in the case of point collections.

7.2.4 Passiveconfiguration

More advanced legacy devices, but especially IoT6‐enabled devices, will often provide some form of configuration option. This could be scaling of the sensor or set point value, e.g., temperature values in degree centigrade or Fahrenheit. Essentially, the passive configuration describes the semantics of a point information unit.

This type of information is more sensitive than the values themselves in that it has a larger influence on the device’s behavior. This is of course the major feature of such configuration, but unfortunately, as always it works both ways: A fault during transmission or programming will introduce a persistent fault. For example, an unintended change in the scaling of a value could permanently impact operation of a feedback control loop involving that value, by changing the semantic context of the data point. For that reason, configuration information should be considered a different class of information than basic data point or set point values, and security requirements should be higher in this case.


35

7.2.5 Activeconfiguration

The above configuration information is considered 'passive' in the sense that it changes the interpretation of actual values used in communication with the device – e.g., it may change the value’s scaling; or it may add some additional static information for later retrieval – e.g., a device name string.

There is, however, another class of configuration information, namely that which influences the active behavior of a device. For example, a sensor could provide an option to have it periodically report its value, without having to request it each time. This should be considered an even higher class of information not only because it influences the active behavior of a device, but also because any fault related to such active device behavior can have much farther reaching consequences: If, for example, a time‐triggered report feature is used, but due to a fault during configuration, it is set to report every millisecond instead of every second, this can cause unnecessarily high load in some segment of the network, which may negatively impact the performance of all devices connected to it.

7.2.6 Controlandmonitoringunit

The hierarchical layering of control and monitoring systems imposes a hierarchy of information as well. Specifically, the values used in individual feedback control loops at the lower levels will naturally be abstracted and merged into sets reflecting individual hierarchical units in the control and monitoring system, e.g., all the point information units that are related to a particular room in a building are mapped into a control and monitoring unit.

These information units of course inherit the properties of their constituents; they merit a distinction as a separate class of information mostly in order to reflect the mapping between individual control loops and the abstract view of the control and monitoring environment.

Note that these are somewhat similar to point collections; the distinction is two‐fold: Firstly, collections are just sets of individual point information units, whereas control and monitoring units may apply some abstraction – e.g., a subset of the feedback loops might be condensed into a single, abstract set point. Secondly, generic collections are not related to abstraction domains in the control and monitoring system. As such, they will generally be used mostly for snap shots of the current state of some sensors. Control and monitoring unit information, on the other hand, will often be used as abstract, high‐level set points for the respective domain.

7.2.7 Controlandmonitoringpreferences

This is actually a subset of the above control and monitoring unit information, containing the set values for the given hierarchical unit. These should naturally be distinguished because a lot of the user or administrator input at this level will be such collections of set points for a given hierarchical unit, together forming a preference set, e.g., for a specific occupant.


36

7.2.8 User‐relateddata

Another obvious form of information is related to the users of a control and monitoring system. It will be necessary to assign unique identifiers to them, which can be used by the system to retrieve associated data like preferences of the given user. In addition to that, user information also comprises security information, e.g., authentication information and assigned privileges.

Naturally, this kind of information is highly sensitive; while compromised security in the case of control and monitoring unit information may put a room out of its intended comfort zone setting, in the case of user information, it becomes a privacy issue. Through unauthorized access to user information, not only could private information be obtained, it could also become possible to impersonate a particular user.

7.2.9 Interventionpattern

Whenever there is a preference setting for a control and monitoring unit like an office room, and in particular if the preference setting is modeled after some department‐wide default setting, individual users will introduce some deviation from the default. Additionally, they might also override the automatic control in some circumstances.

Comparing the default values with the actual values set by the user will yield a usage differential, which is a special type of information. It could – in theory – be used to add a layer of security, by monitoring intervention patterns and scanning for outliers, which would indicate that something out of the ordinary is happening at these points. Such a use is not currently considered for IoT6, as it can produce a high number of false positives, and is also somewhat intrusive.

However, one should be aware that such intervention patterns could be generated by an intruder, and could allow them to determine room usage, or even the presence of a particular user, merely by sniffing the communication between two IoT6 control and monitoring components. This means that is not necessarily sufficient to keep an intruder from introducing forged messages by way of secure authentication, but messages should be encrypted as well, even if the content of each individual message in itself may not be sensitive.

7.3 DistributionofRolesandFunctions

The IoT6 network concept defines a range of different components and services, suited to different network purposes and configurations. Some of them, like the Digcovery, provide essential services for even the most basic IoT6‐enabled network, and will therefore be present in any such IoT6 network, even a somewhat restricted network that is merely used as a local LAN, connecting various workstations to provide for data exchange between them.

Other components are optional and will only be deployed in scenarios requiring their particular services. This is true for the Universal Device Gateway and for the Smart Board / IoTSys Legacy Device Gateway.

As the name implies, both these components offer gateway functionality. However, while the Smart Board with an IoTSys installed specializes in providing translation to and from a variety of legacy protocols, the UDG offers high‐level control and monitoring support. This functionality is


37

probably not essential for any generic IoT6‐based network; however, once the "Internet of Things"‐aspect comes into play, some form of control and monitoring will be necessary.

Individual control and monitoring system adaptations are presented in the related document (Deliverable 4.2). In the context the present document, configurations concern hierarchies of individual control and monitoring systems.

7.3.1 FunctionsinIoT6‐basedControlandMonitoringSystems

Despite the inevitable variability in both the network topologies as well as in the distribution of tasks among the individual components, there are some fundamental functions that can be identified, and will in one form or another be present in most IoT6 network configurations that aim to provide control and monitoring. Those fundamental functions are as follows:

7.3.1.1 Resourcediscovery

Even in current networks, the ability to find and identify the provider of a particular service or a particular piece of information is a crucial feature of a network. In the current version of the Internet, this ability is made available through a variety of means, from the Address Resolution Protocol and DNS servers up to highly complex search functionality as provided by Google.

However, one of the important changes the Internet of Things will bring is an enormous increase number of nodes though integrating large‐scale sensor/actuator systems, which in turn will drastically increase the topological complexity of the network.

To handle the increased amount of information about individual services, as well as make it available when and where it is needed, a distributed, scalable resource discovery service will be essential. In an IoT6 network, this service is provided by the Digcovery, as described in (Deliverable D3.1).

7.3.1.2 SmartThingsInformationService

In an IoT6 network, the Smart Things Information Service (STIS), in some way complements the Digcovery service. Especially since small sensor and actuator devices will to a large part contribute to the increase in network nodes, a quick and easy way to identify them without the time‐consuming and error‐prone need for visual identification and consultation of a datasheet can be considered a mandatory requirement. Since there are already systems in place that assign unique identifiers to individual devices, which are stored in a machine‐readable way in or on the device, it made sense to integrate those systems into the IoT6. That way, it is possible to, for example, simply read the RFID tag of a device, query the STIS for information about it, and then have that information registered with the Digcovery, so it is available in the IoT6 network without any further manual intervention. Basically, the STIS provides integration for various legacy identification mechanisms.

7.3.1.3 Protocoltranslation

This is the lowest level function an IoT6‐enabled control and monitoring system will provide. It should be noted at this point, however, that low level in this case certainly does not imply low complexity. We refer the reader to the related document (Deliverable D4.3), which describes the difficulties involved in the protocol conversion task.


38

Obviously, to provide this functionality, different legacy protocols need to be translated in both directions. In addition to that, and somewhat less obvious, it also involves supplying for the individual devices connected to the legacy networks all the information that a 'smart' component might be expected to provide ‐ e. g., type of device, type of sensor value, or location. This can be seen as complementing the resource discovery ‐ the information provided can be entered manually and directly registered with the Digcovery if necessary, but could also come by way of scanning the device and querying the STIS.

In the IoT6, the Smart Board with an IoTSys is a dedicated component to handle this legacy protocol translation; the UDG can also provide this functionality, in addition to controlling and monitoring functions.

7.3.1.4 Monitoring

The ability to inspect the state of the network or parts of it is of course a fundamental feature. In some form or another it is available in most current widely used networks, be it the current Internet, or the various legacy networks in the automation domain, for example. In an IoT6 network, monitoring needs to be possible on various levels; at the lowest level, it is the ability to observe the state of selected sensors, while on a higher level it can mean the ability to review the configuration and settings for the usage of an entire building.

7.3.1.5 Control

Naturally, an Internet of Things type network like the IoT6 will require some form of feedback control capability. After all, the Internet only becomes the Internet of Things by integrating the vast number of currently installed sensor/actuator networks, e. g., in the field of building or factory automation.

In the IoT6, this controlling function is provided by the Universal Device Gateway (UDG). To that end, it incorporates a powerful and flexible mechanism providing dynamic control rules (Deliverable 4.2). In particular, it may be deployed in a multi‐stage, hierarchical configuration, which means it is by design adaptable to a wide variety of control loops, from lowest‐level, direct control of an actuator set point, to high‐level control like keeping a room with all its various properties in the comfort zone set by the user.

Note that this multi‐stage approach is the key enabler of the distribution of intelligence in an IoT6 network.

7.3.2 Controlandmonitoringsystemconfigurations

The distribution of intelligence described above provides an IoT6 network implementing control and monitoring functionality with remarkable flexibility. Given the functions and components of an IoT6 network described, there are different possible configurations for control and monitoring systems, which can be deployed in order to adapt the network to different scales or use case scenarios.

Now, flexibility is of course vital, but one must take care that the complexity of the network scales down with the complexity of the task. All too often, flexibility is paid for by having drastically over‐engineered environments when applied to a small‐scale system.


39

The IoT6, with its fundamentally distributed nature, allows for a reduction in complexity to adapt the network to small‐scale, local control and monitoring systems. Some example configurations that could be set up within an IoT6‐based control and monitoring system are shown below.

7.3.2.1 SingleUDGasCompleteControlandMonitoringSystem:

The UDG is designed to handle all the tasks a control and monitoring system can be expected to handle. It also can interface to legacy devices directly, so no additional Legacy Device Gateway is needed. This would be the setup of choice if legacy components are not in use, as the UDG can provide a full‐featured CMS.

Figure 11: Single UDG as Complete CMS

7.3.2.2 LegacyDeviceGateway(SmartBoard+IoTSys)asaBasicCMS:

Alternatively, it is also possible to use a Smart Board with the IoTSys installed in configurations that comprise only legacy devices, as the IoTSys incorporates a basic rule manager. While this configuration is very flexible in terms of different technologies that can be integrated, the capabilities in terms of control and monitoring tasks would be somewhat limited to mostly low level functionality, as compared to the system shown before. Still, for smallest scale legacy‐bound systems, this would be an option.

Figure 12: Single IoTSys as a Basic CMS

More complex configurations, which can be considered 'standard' configurations given the average complexity of automation tasks, are of course also provided for. Examples are as follows:

UDGas

Singular CMS

IoT6device

Legacydevice

IoTSysas

Minimal CMS

Legacydevice

Legacydevice


40

7.3.2.3 UDGasCMSutilizingSlaveLegacyDeviceGateways

In this setup, the UDG is responsible for the high‐level controlling and monitoring tasks; the more basic, low‐level controlling tasks are handled by one or more Smart Boards running the IoTSys. The latter will of course also provide the Legacy Device Gateway functionality.

Figure 13: UDG as CMS utilizing Slave Legacy Device Gateways

7.3.2.4 Multi‐levelUDGControlandMonitoringSystem

This configuration represents a larger‐scale control and monitoring scenario, e. g., a large building split into different, independently controlled areas, with a top‐level controlling system and multiple 'slave' systems, which can, however, operate their assigned sub‐areas autonomously. Of course, at the lowest level, Legacy Device Gateways can be employed.

Figure 14: Multi‐level UDG Control and Monitoring System

UDGas

Master CMS

IoT6device

Legacydevice

IoTSysas

Legacygateway

Legacydevice

IoT6device

UDGas

Meta CMS

Legacydevice

IoTSysas

Legacygateway

Legacydevice

IoT6device

UDG asSlave CMS

+Master CMS

UDGas

Slave CMS

IoT6device

Legacydevice

Legacydevice


41

7.3.2.5 SaaSconnectingtoseveralmulti‐levelUDGControlandMonitoringSystems:

For the most complex control and monitoring tasks, a configuration like this can be used. Here, several multi‐level UDG‐based control and monitoring systems as described above are deployed for large‐scale sub‐tasks, and they are all tied together by a cloud‐based SaaS control and monitoring system. This enables such systems to cover a global scale, and provide ubiquitous access, as long as access to the cloud is provided.

Figure 15: SaaS connecting to several multi‐level UDG Control and Monitoring Systems

7.3.3 RolesinIoT6‐basedControlandMonitoringSystems

In order to provide the utmost flexibility, IoT6 allows for a wide variety of different control and monitoring system topologies, by selecting and combining the various functions mentioned above in ways that are suited to the task at hand.

While it is perfectly possible to set up a local, centralized CMS as depicted in Figure 11 or Figure 12, the system can be scaled up to a large scale involving cloud‐based services, as shown in Figure 15 above.

Now, depending on which kind of topology is used, each IoT6 component ‐ and in particular, each CMS variant ‐ has a one or more specific roles assigned. In the example configurations shown above, we have different types of control and monitoring systems, depending on the specific way the controlling is set up:

UDGas

Meta CMS

Legacydevice

IoTSysas

Legacygateway

Legacydevice

IoT6device

UDG asSlave CMS

+Master CMS

UDGas

Slave CMS

IoT6device

Legacydevice

Legacydevice

UDGas

Master CMS

IoT6device

Legacydevice

IoTSysas

Legacygateway

Legacydevice

IoT6device

SaaSas

Meta CMS

IoT6device

IoT6device


42

7.3.3.1 SingularCMS

A singular CMS is one which encompasses all the necessary feedback control in one IoT6 function component. While it will of course be accessible by a user or administrator and accept rule settings, all the control loops it implements only go through the one CMS and the devices attached to it, with no further IoT6 component involved.

7.3.3.2 SlaveCMS

A slave CMS is similar to a singular CMS in that it contains all the necessary logic to handle control of the sensors/actuators attached to it. However, it will provide an interface for device and open loop control access, which can be used by a another CMS‐capable component to form a cooperative, closed control loop containing the device, the slave CMS, and itself.

7.3.3.3 MasterCMS

A master CMS is one that has devices attached to it, which it controls locally, but also controls at least one slave CMS, by using device values reported together with the open loop control set point interface.

7.3.3.4 MetaCMS

When a CMS does not control any devices directly, but only connects to slave CMS for cooperative control loops, it becomes a Meta CMS. The distinction is relevant in that a Meta CMS does not require low‐level bindings to individual devices, much less legacy ones, which should free up a considerable amount of resources.

Master CMS

Slave CMS

authenticationconnector

slaveconnector

legacyconnector


masterconnector Legacy

device

Figure 16: Master Role

Meta CMS

Slave CMS


slaveconnector


masterconnector

Figure 17: Meta Role


43

7.3.3.5 CloudCMS

The highest level at which a CMS can be placed in an IoT6 network is, indeed, the cloud. A Cloud CMS will almost always be a meta CMS; while it is of course possible to equip a cloud‐based service with connectors to low‐level devices, usually it will make sense to let a slave CMS handle the low‐level control loops, and even local configuration, and have the Cloud CMS provide global control and monitoring functions.

7.4 RoutingofInformation

In Section 7.3.2, we have given an overview of the structure of a CMS in an IoT6 network, along with the various functions and roles individual components can be assigned. Section 7.2 attempted to classify the information that is exchanged between the various components of an IoT6 network. It is of course possible to relay that information by using standard routing mechanisms; however, an IoT6 network provides some additional routing capability, namely the 'Smart Routing'.

7.4.1 'SmartRouting'mechanism

The Smart Routing mechanism devised in T3.2 of this project and described in the related deliverable (Deliverable D3.2) is intended to support distribution of intelligence, i.e., the feature concerning "basic data recognition, interpretation, data filtering and differentiated addressing" as mentioned in the DoW.

This mechanism has been briefly described above, but we may need to elaborate on it somewhat here:

Each IPv6 packet contains, among many others, a field reserved for a 'flow label' (IETF, RFC6437). Its purpose is to group individual packets together to form a 'flow', i.e., a sequence of packets sent from a particular source to a particular destination over a particular transport connection.

The Smart Routing mechanism now makes use of that flow label in that it provides a basic semantic extension of the addressing: Instead of sending a packet to the IPv6 address of a particular destination, it is sent to the IPv6 of a Smart Board set up to work as a smart router. In addition, the flow label is set to a pre‐determined value designed to indicate what type of content is contained in the packet, and how it is supposed to be routed.

The current demonstration uses this mechanism in the context of a temperature sensor transmitting value messages. Two flow labels are defined: The first one indicating a 'normal' value, that is, one that lies within a pre‐defined range which is considered standard for the given sensor. The second possible flow label indicates the value was outside of that range, and this is to be forwarded to a different address.

An important property of this smart routing mechanism is that it is source‐based: While the sender does not directly set the actual destination address, it has to do so indirectly by setting the flow label to a pre‐determined value, which has been agreed upon to implicate a particular destination address. Most importantly, the smart router itself does not examine the content of


44

the packets, apart from reading the flow label field. This means the main purpose of the 'local rule manager' becomes to assign flow labels to destination addresses.

This source‐based nature of the routing mechanism implies a distribution of intelligence in a sense: Instead of having centralized routing rules, which are set up locally at individual routers, each node using the network has a say in the routing decision, by sending an appropriate routing hint along with a message to a Smart Router, which will then evaluate that hint and forward the message accordingly.

There are many ways the smart routing feature described above can be used, some of which will be explored below.

7.4.2 SmartRoutingAppliedtoAlertSituations

An application of Smart Routing that is part of the demonstration use case is the alert routing as depicted in Figure 18, which has already been described: If a smart sensor (or a legacy device in combination with a legacy gateway like the UDG or the IoTSys) detects that the current value is outside of some pre‐determined acceptable limit, it could set the flow label to, say, 0x0B instead of the normal value of 0x0A. The router would then examine the message’s flow label and relay it to the appropriate server.

Figure 18: Smart Routing ‐ Values

7.4.3 SmartRoutinginTopologyAbstraction

Smart Routing can also be used to insert a layer of abstraction into CMS addressing, by placing a Smart Router between a master and slave CMS (Figure 19).

Figure 19: Smart Routing ‐ Topology Abstraction

Smart Router Master CMS

Slave CMS1st floorroom A

0x1A

0x2B

0x1B

0x2A

0x1B → 1st floor, room B

Slave CMS1st floorroom B

Slave CMS2nd floorroom A

Slave CMS2nd floorroom B

Smart Router

IoT6device

LegacyGateway

StandardServer

AlertServer

0x0A

0x0B


45

The master CMS would then use the routing hint, i.e., the flow label, as an identifier for a control and monitoring sub‐area, without actually having to distinguish individual slaves by their IPv6 addresses. The Smart Router would be configured to forward messages containing a particular set of area identifiers to a specific slave CMS. It would then be possible to assign a slave to multiple sub‐areas, and later on split responsibility for these areas up between two or more slaves, merely by changing the routing table.

7.4.4 SmartRoutinginFaultTolerance

A Smart Router could also help implement safety and security measures. E. g., if a master CMS is addressing its slaves through domain identifiers rather than directly, then the Smart Router could be connected to multiple, redundant slave CMS, either in hot or cold standby mode (Figure 20).

Figure 20: Smart Routing ‐ Fault Tolerance

The Smart Router could then periodically monitor and evaluate the individual slaves: First of all, it could request cryptographic identification, and if a slave fails to comply, eliminate it from the routing table, implicitly re‐routing the master traffic to the remaining, known good slave CMS.

In addition to that, it could also evaluate the response times, and use its routing ability to introduce load‐balancing between the slaves.

7.5 CommunicationDomainswithinanIoT6CMS

These different types – or roles – of a complex, distributed control and monitoring system, in combination with the different fundamental functions provided by IoT6 network components, establish different communication domains within such a network.

7.5.1 TypesofCommunicationDomains

Based on the functions and roles described, one can identify different domains; in turn, for each of these domains, one can identify different properties and requirements.

7.5.1.1 Legacydomain

Here, an IoT6 component has to connect legacy devices to the IoT6 network, which of course implies that legacy bus systems and protocols must be utilized. Even though the Legacy Device Gateway is the master in this communication, it can exert very little control over specific properties such as error control or security, as it must follow the legacy protocol, and the devices will usually provide an interface limited to what the protocol defines. Possible faults or intrusions are restricted to providing false current value readings or false set point values

Smart RouterMaster CMS+

+++

0x0A → domain A

Slave CMSdomain Ainstance 1

Slave CMSdomain Ainstance 2

monitoring & evaluation


46

issued; while it is inside the control loop, the capabilities of the devices in this case are severely limited compared to an IoT6 component, and monitoring is relatively powerful. Therefore, the potential effects of faults and/or intrusions are limited.

7.5.1.2 Closeddomain

This refers to the connectivity between a singular CMS and its attached devices. Communication in this domain is mostly restricted to a low‐level exchange of current sensor values received by the CMS, and actuator set point values sent by it. Of course, if the set of devices contains a non‐empty subset of legacy devices, then the closed control domain will contain a legacy domain as well. However, the communication domain is still restricted to one IoT6 component and its attached devices, whether IoT6‐enabled or legacy type device. The potential for faults and intrusions is similar to the legacy domain, although IoT6‐enabled devices can be much more complex than most legacy devices, and therefore the effects of faults or intrusions are increased.

7.5.1.3 Metadomain

Referring to the connectivity between a Master and Slave CMS, this is the first domain where the control loops themselves are opened up to outside access within the IoT6 network, as the Slave must provide an interface for the Master to be able to form a closed feedback loop. Naturally, this means that the requirements for access control are somewhat higher ‐ after all, these open control loops will generally be used to form more complex closed control loops. These provide more functionality, but also more potential for things to go wrong, as the fault/intrusion entry point is now inside this closed control loop, between two fully‐fledged IoT6 components.

Note that we do not distinguish a master control domain, as it is just a combination of the meta domain and the closed domain, with the meta domain of course dominating in terms of communication properties.

7.5.1.4 Clouddomain

The cloud‐based CMS provides ubiquitous access to its control and monitoring capabilities, which is often considered a mandatory requirement for services in the Internet of Things. The associated communication domain is the most powerful one, but consequently also the one that is most open to intrusion.

7.5.2 InformationandIntelligenceDistributionacrossDomains

IoT6 aims to capitalize on the intrinsic robustness of a distributed architecture, which is enabled by the UDG's flexible connectivity. Its ability to perform both as a slave or a master system allows a classic layering of a given control and monitoring architecture into sub‐systems with local scope. On the other hand, its adaptability to different levels in the communication stack, from the cloud interface down to the lowest level of individual smart sensors and actuators, allows for a vertical integration of a layered system, e. g., to establish a guard system to improve fault detection and fault tolerance.


47


In the legacy domain, the vast majority of the information exchanged will be point values and some – mostly passive – configuration information. Semantic content will be relatively low; on the other hand, the number of individual messages exchanged will routinely be higher than in the other domains, since in the legacy domain comprises a large number of simple devices which need to be continually monitored by the gateway.

As far as the distribution of intelligence is concerned, in this domain it refers to the availability of simple yet flexible local rules, which can combine different data or set points using Boolean functions as described in the IoTSys document (Deliverable D4.3). This functionality is mainly provided by the oBELIX component of the IoTSys, but also by the dynamic rule component of a UDG, which can also be deployed as a legacy gateway.


In addition to legacy domain information, the closed domain also comprises connections between control and monitoring systems and IoT6‐enabled devices, and will therefore contain more elaborate configuration information – specifically, a higher percentage of active configuration information.

Again, the intelligence in this domain is provided by the oBELIX part of IoTSys as well as the rule system of the UDG, although here, the latter will likely be deployed more often.

7.5.2.3 Metadomain

As the point of a meta CMS is usually to add a higher layer of abstraction, information transmitted within the meta domain will be on a higher semantic level. There will be very little individual, but likely some amount of point collection and point history information. Naturally, a high percentage of meta point information can be expected in this domain, dominating the security requirements.

Providing the local intelligence is up to the UDG, as an IoTSys cannot be deployed as a (fully IoT6‐enabled) meta CMS.

7.5.2.4 Clouddomain

In the cloud domain, some point information may still be present – for example, to implement vertical fault monitoring across selected parts of the hierarchy. Mostly, however, it will be meta point information as well as point collection and point history information to allow users and administrators to review the state of the system.

The intelligence in the cloud domain is available through the various IoT6‐related SaaS systems provided by RunMyProcess (Deliverable D6.5).

7.5.3 DomainSecurity

The aforementioned communication domains can be ordered according to the relative size of their sphere of influence within an entire network, with the legacy domain having the smallest scope, and the cloud domain the largest. Security measures to be deployed in each of these domains should be selected based on this relative scope of influence, as well as the relative


48

amount of the different types of information, which all can be assigned certain security requirements.

Generally speaking, security measures should of course always be as strong as possible; however, compromises in terms of computing power – in particular when it comes to computationally expensive encryption mechanisms ‐ may ultimately have a strong influence on the total cost of deployment. Simply expecting or demanding the maximum in security measures that is technically achievable to be implemented may even be counter‐productive: If security is associated with excessive cost, more cost‐effective solutions – with reduced security ‐ will likely emerge. All too often, the cost of security is only re‐evaluated once an incident has occurred.

For detailed investigation of the security aspect, we refer the reader to another document produced within this project, which deals specifically with security in the context of IoT6 (Deliverable D2.2).

Coming back to the communication domains described earlier, some general observations and recommendations for further safety and/or security measures can be made. Note that these are listed as recommendations here because they strongly depend on the actual system being implemented, and a useful, generic implementation cannot necessarily be provided.


In this domain, communication is comparatively limited, with a strong master‐slave component. Thanks to legacy devices usually being quite limited in functionality, the potential consequences of faults are also limited. Still, a legacy type sensor may of course report erroneous values, and a legacy type actuator may just ignore the set point value, or get stuck at an arbitrary value.

To counter such problems, it could be useful to enhance a sensor device's representation in legacy gateway configurations with certain properties concerning their value output. Some examples:

Authentication:

In the legacy domain, options for introducing additional layers of safety and/or security

are somewhat limited, as the given legacy protocol must be used in order to integrate

legacy devices in the first place. If possible, authentication of messages should of course

be used; if not, some plausibility checks like the ones mentioned below could be

considered to at least verify values introduced into the CMS at this level.

Verification of set points:

Since in the legacy domain, the options to introduce enhanced security below the link

level are limited due to the fact that the legacy protocol must be used, a gateway could

check for spurious changes of set points. Whenever a value is set, it could verify if the

value that was issued previously is still present. If not, it could raise an alert indicating

suspicion of tampering.

Maximum expected rate of change:


49

If the maximum rate of change is known, then any time the gateway receives a value, it

could compute a plausibility window from the previous value(s), and check the new

value against it. That way, a sensor fault or tampering could be detected, even when it

does not lead to an obvious fault.

Typical expected variation:

If it is possible to provide an expected variation of a sensor value, the gateway could

determine if a sensor is stuck at a value. For example, in many areas, the value of an

outside temperature sensor can be expected to change a few degrees centigrade in a

day/night cycle. If that change does not occur during an entire cycle, the gateway could

perhaps determine that the sensor is faulty, even when at a momentary glance the value

seems plausible.


For closed domains, the security recommendations would mostly be similar to the ones mentioned above. A possible further security mechanism could be implemented with respect to IoT6‐enabled devices, that is, devices that are connected directly to the CMS without the need of a protocol translation layer. Due to the fact that direct connection to a network via IPv6 usually requires more elaborate hardware, such devices are likely to be more functional than their legacy counterparts. This means that they are also likely to have more options in the way of profiles to be stored, or maybe features like automatic sending of value updates.

The possible risk here is that such configuration options introduce 'sticking' faults: Once a configuration is faulty – whether through a transmission error, a flaw during the programming cycle, or even malicious tampering ‐ an otherwise fully functional device might exhibit faulty behavior permanently, due to the fact that the fault has been stored and is now determining the device's behavior in a way that the controlling IoT6 component is most likely not aware of.

Enforced periodical re‐configuration

A recommendation to counter such problems would be to require any automatic

configuration of otherwise 'dumb' devices by an IoT6 component to be refreshed after a

certain period of time; the time would have to be chosen taking into account parameters

such as network load or maximum allowed write cycles for the device configuration. This

would make sure that even if a fault or an intruder causes a device to be programmed

with a flawed configuration once, after that period, it will be automatically corrected.

7.5.3.3 Metadomain

As we are moving up to the large scope domains, the potential consequences of faults and/or intrusions become rather scary ‐ so let us once again emphasize at this point that for any communication between IoT6‐enabled components, the security measures recommended by (Deliverable D2.2) must be in place, of course.

Up in the meta domain, and even more so later on in the cloud domain, it is hard to identify any particular security risks, simply due to the fact that the communication is much more complex,


50

making it harder to pinpoint individual fault possibilities. However, the recommendations made above may still apply to a certain degree, and a few further recommendations can still be made:

Agreement on behavioral limits

In the meta domain, communication takes place between two IoT6 components, each of

which is a very complex and powerful system in itself. This, in turn, will make

communication between them also powerful and complex. Rather counter‐intuitively, it

might make sense for any particular interface between two such components to set up a

priori limits on the use of the interface. For example, it could be agreed upon that a

particular set point value will 'usually' not be changed more often than, say, once an

hour; or that a set point will 'usually' not be changed by more than a fixed percentage

over the precious value. In this context, 'usually' indicates that a certain number of

exceptions will be allowed in a specific time frame. That way, by keeping track of the

history of set point changes, the window of opportunity for a random, spurious

message ‐ which might occur due to a bug in the master's software, or due to some

unauthorized person tampering with the master's user interface ‐ will raise a flag of

suspicion at the slave.

Periodical identification

Since the communication partners in the meta domain will be relatively high

performance systems, a requirement could be made for each of them to request

identification from the other periodically, by way of a cryptographic question. The

identity should then be associated with the source address, which should be routinely

checked (but could of course be spoofed by an attacker).

Proof of Work

Slave CMSs should also periodically trigger a proof of work protocol with their master

CMSs, in order to decrease the likelihood of denial of service attacks. This would be on

top of the aforementioned behavioral limits, which should also help against DOS attacks,

but might still make it impossible for the actual master to get through to the slave.

It must be noted that any such limit on the communication would have to be selected carefully, so as to not interfere with normal operation of the system. It should therefore also be re‐evaluated periodically, which could be done automatically or semi‐automatically. Furthermore, an override should definitely exist, but should of course require special privileges.


51

7.5.3.4 CloudDomain

The main difference between the meta‐domain and the cloud domain is that the latter is even more open to possible intruders. While the recommendations made for the smaller scope domains will in many cases still apply to the cloud domain, there is one important recommendation we can make here.

Limit features

Since authorized access via the cloud can originate from a vast variety of devices, and

from many different clients, it is more open to safety and security problems than the

other domains. A recommendation here is to be as conservative as possible with

exposing functionality to the cloud, despite the fact that limitations often end up

irritating legitimate users. Here, some degree of irritation may have to be accepted in

order to avoid the most severe security issues.

Implement special cloud privileges

Any IoT6 component providing an interface for administrative access must of course

identify the source of the access request. If such an access request is made from the

cloud ‐ or, indeed, from an unknown location, but by an authorized user ‐ there should

be a separate ‐ and more restricted ‐ set of valid actions that may be executed during

this access.


52

8 ConclusionandOutlook

This document summarized the work done in the first part of Task 5.2 of the IoT6 project, which was related to deploying the Smart Board within the IoT6 framework.

In order for the Smart Board to fulfill its task of hosting the IoTSys as well as the Smart Routing components developed in the IoT6 project, a dedicated software application was required to handle their configuration and launch. Sections 0 through 6 attempted to give a brief overview of the features provided by this IoT6 Launcher Software developed as part of Task 5.2 of WP5, and to present the reasoning for the selection of features that were implemented in this application.

Section 7 was concerned with the integration of the Smart Board and its software components into the frame of an IoT6‐based control and monitoring system. The different functions that are provided by IoT6 components as well as the different roles that they can assume were presented, and the possible uses of the Smart Board were pointed out. Furthermore, some possible example configurations these components could be used in were briefly described.

The second and major part of Task 5.2 comprised the implementation efforts concerning the multi‐protocol integration, namely the implementation of the IoTSys architecture designed in WP4, and the deployment on the Smart Board. However, the results of this part of the task are described in another document (Deliverable D4.3), in order to integrate all IoTSys‐related documentation in one deliverable for easier reference.

Further work to be done in this task will be mostly concerned with further testing and validation in the context of the global validation process, as well as investigating scalability, in particular with respect to the IoTSys component.


53

9 ListofFigures

Figure 1: Component Diagram ....................................................................................................... 11

Figure 2: IoTSys Integration, Startup Phase ................................................................................... 19

Figure 3: Device List, oBIX Object Setup ........................................................................................ 20

Figure 4: IoTSys Integration, Runtime Phase ................................................................................. 21

Figure 5: Device List, Control Interaction ....................................................................................... 26

Figure 6: Smart Routing Setup, Rule Added ................................................................................... 28

Figure 7: Floor Plan View ................................................................................................................ 29

Figure 8: Floor Plan, Locating a Device .......................................................................................... 30

Figure 9: Floor Plan, Watch Update ............................................................................................... 31

Figure 10: Floor Plan, Polling Update ............................................................................................. 32

Figure 11: Single UDG as Complete CMS ....................................................................................... 39

Figure 12: Single IoTSys as a Basic CMS ......................................................................................... 39

Figure 13: UDG as CMS utilizing Slave Legacy Device Gateways ................................................... 40

Figure 14: Multi‐level UDG Control and Monitoring System ......................................................... 40

Figure 15: SaaS connecting to several multi‐level UDG Control and Monitoring Systems ............ 41

Figure 16: Master Role ................................................................................................................... 42

Figure 17: Meta Role ...................................................................................................................... 42

Figure 18: Smart Routing ‐ Values .................................................................................................. 44

Figure 19: Smart Routing ‐ Topology Abstraction .......................................................................... 44

Figure 20: Smart Routing ‐ Fault Tolerance.................................................................................... 45


54

10 References

(TBD). (2014). Deliverable D6.5.

Business Protocol Management tools and Cloud computing applications integration

report.


Components Instantiations and validation report.


Smart IPv6 building deployment, test and recommendation report.

Amante, S., Carpenter, B., Jiang, S., & Rajahalme, J. (2011). IETF, RFC6437.

Flow Label Specification.

Digia. (2013). qt.digia.com.

IoT6‐DoW. (2011). Document of Work.

Jara, A., Skarmeta, A., López, P., Fernandez, D., Krco, S., Pokric, B., et al. (2012).

Deliverable D3.1.

Look‐up, discovery, context‐awareness, and resource/services directory.

Jung, M. (2014). Deliverable D4.3. Multi‐protocol Integration Report.

Kim, D., Kim, S. H., Im, J., Byun, J., Nam, G., & Lee, K. (2012). Deliverable D6.1.

Unique identifier analysis report and STIS, ONS, IoT6 integration.

Kim, S. H., Nam, G., Kwon, K., & Le, T. (2013). Deliverable D6.3.

Interface between IoT6, STIS and ONS Validation Report.

Mandat International. (2012). Deliverable 1.1.

IoT6 use‐case scenario and requirements definition report.

Melakessou, F., Cholez, T., François, J., & Panchenko, A. (2013). Deliverable D3.2.

Smart Routing Mechanisms Design.

Melakessou, F., Cholez, T., François, J., Palattella, M., & Panchenko, A. (2013). Deliverable D2.2.

Distributed IPv6‐based Security, Privacy, Authentication and QoS.

Olivieri, A., Rizzo, G., Bocchi, Y., Morard, F., & Jara, A. J. (2013). Deliverable 4.2.

Multi‐protocol architecture and system development report.

Oracle. (2014). Java SE Embedded.

http://www.oracle.com/technetwork/java/embedded/overview/javase/index.html.


55

Rey, J.‐P., & Hervé, D. (2013). Deliverable D5.2.

Smart Board Design And Realization Report, Including Board Prototype Validation Tests.

ST Microelectronics. (2010). UM0851.

Linux support package (LSP) v2.3 for SPEAr.

ST Microelectronics. (2011). DS6590.

Embedded MPU with ARM926 core, optimized for factory automation and consumer

applications.

ST Microelectronics. (2011). RN0080.

Linux support package for SPEAr (LSP) v 2.3.2.

Documents

Inte of Inter of Thi gh an IPv based S ervice nabling - D5.3 -v2.pdf · provide an IPv6‐based Web service allowing access to sensors and actuators connected to the card. In addition,