FAKULTÄT FÜR INFORMATIK

DER TECHNISCHEN UNIVERSITÄT MÜNCHEN

Master’s Thesis in Informatik

Kura Wires: Design and

Development of a Component for
managing Devices and Drivers in
Eclipse Kura 2.0

Amit Kumar Mondal

 FAKULTÄT FÜR INFORMATIK
DER TECHNISCHEN UNIVERSITÄT MÜNCHEN

Master’s Thesis in Informatik

Kura Wires: Design and Development of a

Component for managing Devices and Drivers
in Eclipse Kura 2.0

Kura Wires: Entwurf und Implementierung

einer Komponente für die Verwaltung von
Geräten und Gerätetreibern in Eclipse Kura 2.0

Author: Amit Kumar Mondal

Supervisor: Prof. Bernd Brügge, Ph.D.
Advisor: Zardosht Hodaie
Date: December 15, 2016
I assure the single handed composition of this master thesis only supported by
declared resources,

Munich, December 15, 2016 Amit Kumar Mondal

Acknowledgements

First of all, I would like to express my sincere gratitude to my supervisor Prof.

Bernd Brügge for the support of my thesis research work, for his patience,
motivation, and immense knowledge. His guidance helped me a lot in flourishing
my knowledge on Software Engineering and in writing of this thesis.
Besides my supervisor, I would like to immensely thank my advisor Zardosht
Hodaie for his insightful comments and encouragement in my research work.
He not only helped me in my research but also for the hard questions which
incented me to widen my research from various perspectives. I could not have
imagined having a better advisor and mentor for my thesis research work.
I would like to give my sincere thanks also to Eurotech CTO Marco Carrer,
Senior Software Engineers Cristiano De Alti, Luca Dazi, Stefano Morsen and
Software Engineers Pierantonio Merlino, Matteo Maiero who provided me an
opportunity to join their team as an intern, and gave access to the laboratory
and research facilities. Without their precious support, it would not have been
possible to conduct this thesis work.
I cordially thank my fellow colleagues, especially Prof. Antonio Abramo in
Eurotech for the stimulating discussions we were working together during my
thesis period, and for all the fun we have had in the last couple of months. Also
I thank my friends in my institution for their continuous support.
Last but not the least, I would like to thank my family: my parents, my elder
brother and my girlfriend for supporting me spiritually throughout writing this
thesis and my life in general.
 Zusammenfassung

Ein Internet der Dinge Gateway leitet physikalische Geräte ins Internet über.
Ein solches Gateway isoliert die Entwickler von der Komplexität der Hardware-
Subsysteme. Eclipse Kura ist ein Java- und OSGi-basiertes Open Source Fra-
mework, das eine Plattform für den Aufbau von IoT-Gateways bietet. Es ist
ein Anwendungscontainer, der die Fernverwaltung solcher Gateways ermöglicht
und eine breite Palette an APIs bietet, mit denen Entwickler ihre eigenen IoT-
Anwendungen schreiben und bereitstellen können.
In Fabriken konzentrieren sich Menschen oft auf die Verarbeitung von Daten
physikalischer Geräte und es erfordert eine Arbeitsumgebung um mit den Ge-
räten zu kommunizieren. Gegenwärtig verfügbare Lösungen (OpenMUC, Bosch
ProSyst, Eclipse Kura 1.x) benötigen Kenntnisse über spezifische Framework-
Interna um einen solchen Kommunikationsmechanismus zu entwickeln. Somit
verbringen die Menschen mehr Zeit mit der Programmierung ihrer Service Gate-
ways für bestimmte Gerätekommunikationsszenarien. Dies im Hinterkopf, stellt
Eclipse Kura 2.0 Kura Wires vor um die Entwicklung solcher industriellen An-
wendungen durch visuelles Zusammenfügen von Komponenten zu erleichtern.
Zum Beispiel die Verbindung einer OPC-UA PLC mit Cloud Publisher um die
Verbreitung ihrer Produktionsdaten auf der Cloud-Plattform zu steuern.
Derzeit fehlt Eclipse Kura eine Komponente um einfach mit industriellen Gerä-
ten zu kommunizieren. Eine solche Komponente würde die Kommunikation mit
Geräten ermöglichen, die spezifische Treiber industrieller Protokolle verwen-
den. Das Hauptziel dieser Arbeit ist es Kura Wires zu entwerfen und zu ent-
wickeln, bzw. ein erweiterbares Geräte- und Treiber-Management-Framework
über Eclipse Kura. Der Beitrag beinhaltet auch die Entwicklung von wesentli-
chen logischen Komponenten, logischen Geräten und Treibern für mehrere in-
dustrielle Feldprotokolle (Modbus, OPC-UA und Siemens PROFINET), die in
erster Linie erforderlich für Anwendungen sind um Daten von Industriegeräten
zu verarbeiten. Zum Schluss würden wir gerne den Aufbau einer industriellen
Anwendung demonstrieren um Daten eines industriellen Gerätes durch die vi-
suelle Verbindung von Komponenten unter der Nutzung von Eclipse Kura auf
ReliaGATE Service Gateways zu sammeln.
 Abstract

An Internet of Things (IoT) gateway bridges physical devices to the Internet.

Such gateway isolates developers from the complexities of hardware subsystems.
Eclipse Kura is a Java- and OSGi-based Open Source framework that provides
a platform for building IoT gateways. It is an application container that enables
remote management of such gateways and provides a wide range of APIs for
allowing developers to write and deploy their own IoT applications.
In factories, people often focus on processing data from physical devices and
it requires an environment to communicate with the devices. Currently avail-
able solutions (OpenMUC, Bosch ProSyst, Eclipse Kura 1.x) require knowledge
about specific framework internals to develop such communication mechanism.
And hence, people spend more time programming their service gateways for
specific device communication scenarios. Keeping this in mind, Eclipse Kura
2.0 is introducing Kura Wires to ease such industrial application development
by visually connecting components together. For example, connecting an OPC-
UA PLC to Cloud Publisher to control publishing its production data to cloud
platform.
Currently Eclipse Kura lacks a component to communicate with industrial de-
vices easily. Such component will enable communication with devices using
industrial protocol specific drivers. Hence, the main objective of this thesis
work is to design and develop Kura Wires - an extensible device and driver
management framework on top of Eclipse Kura. The contribution also incor-
porates development of essential logical components, logical devices and drivers
for several industrial field protocols (Modbus, OPC-UA and PROFINET) pri-
marily required for applications to process data from industrial devices. Finally,
we would like to demonstrate building an industrial application to collect data
from an industrial device by visually connecting components using Eclipse Kura
running on ReliaGATE service gateway.
Contents

1 Introduction 1
1.1 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background 3
2.1 OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Eclipse Kura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Dataflow Programming . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Visual Programming . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Edge Computing . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.6 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.6.1 Node-RED . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.6.2 SAM Labs . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Requirements Analysis 9
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 What is missing in Eclipse Kura? . . . . . . . . . . . . . . . . . 9
3.2.1 Application Store for Eclipse Kura . . . . . . . . . . . . 11
3.3 Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Kura Wires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.1 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5 Use Case Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5.1 High-level Use Cases . . . . . . . . . . . . . . . . . . . . 19
3.5.2 Configure Wire Component . . . . . . . . . . . . . . . . 19
3.5.3 Perform Remote Request . . . . . . . . . . . . . . . . . . 21
3.5.4 Filter, Store, Publish and Receive Data . . . . . . . . . . 22
3.6 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6.1 Functional Requirements . . . . . . . . . . . . . . . . . . 23
3.6.2 Nonfunctional Requirements . . . . . . . . . . . . . . . . 24
3.7 System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.7.1 Analysis Object Model . . . . . . . . . . . . . . . . . . . 25
3.7.2 Dynamic Model . . . . . . . . . . . . . . . . . . . . . . . 32

i
4 System Design 36
4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 Subsystem Decomposition . . . . . . . . . . . . . . . . . . . . . 37
4.3.1 Application Logic Layer . . . . . . . . . . . . . . . . . . 38
4.3.2 Storage Layer . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 Hardware Software Mapping . . . . . . . . . . . . . . . . . . . . 40
4.4.1 Third-Party Libraries . . . . . . . . . . . . . . . . . . . . 40
4.5 Persistent Data Management . . . . . . . . . . . . . . . . . . . . 42
4.6 Global Software Control . . . . . . . . . . . . . . . . . . . . . . 43
4.7 Boundary Conditions . . . . . . . . . . . . . . . . . . . . . . . . 43

5 Object Design 46
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2 Data Representation . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3 Wire Component Management . . . . . . . . . . . . . . . . . . . 47
5.4 Asset and Driver Management . . . . . . . . . . . . . . . . . . . 48
5.4.1 Associate Driver with Asset . . . . . . . . . . . . . . . . 49
5.5 Wire Management . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.5.1 Wire Connections . . . . . . . . . . . . . . . . . . . . . . 51
5.5.2 Push Pattern . . . . . . . . . . . . . . . . . . . . . . . . 52
5.5.3 Visitor Pattern . . . . . . . . . . . . . . . . . . . . . . . 52
5.6 External Configuration . . . . . . . . . . . . . . . . . . . . . . . 53
5.7 Remote Communication . . . . . . . . . . . . . . . . . . . . . . 55

6 Summary 57
6.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

A Screenshots 60

B EclipseCON Germany 2016 66

ii
API Application Programming Interface

HTML Hypertext Markup Language

GPIO General-Purpose Input Output

GPS Global Positioning System

GUI Graphical User Interface

GWT Google Web Toolkit

I2C Inter-Integrated Circuit

IBM International Business Machines

IDE Integrated Development Environment

IoT Internet of Things

IIoT Industrial Internet of Things

IP Internet Protocol

JAR Java Archive

Java EE Java Enterprise Edition

JDBC Java Database Connectivity

JNI Java Native Interface

JVM Java Virtual Machine

LED Light Emitting Diode

MQTT Message Queue Telemetry Transport

OPC-UA Open Process Communication Unified Architecture

OSGi Open Services Gateway Initiative

PLC Programmable Logic Controller

PROFINET Process Field Network

PWM Pulse Width Modulation

S7 Siemens Simatic 7

SPI Serial Peripheral Interface

SQL Structured Query Language

TCP Transmission Control Protocol

iii
UI User Interface

UDP User Datagram Protocol

UML Unified Modeling Language

USB Universal Serial Bus

XML eXtensible Markup Language

iv
Chapter 1

Introduction

1.1 Problem
The industrial environment is an evolving enterprise, comprising different types
of sensors, machines and instruments of varying vintage, each with its own de-
mands for monitoring, control and maintenance. Some of these devices are
Internet-enabled either through hardwired connectors or via Wi-Fi. But a
broad range of older devices are not likely to be inherently connectable to a
network. Even the traditional approach to manage these devices manually
prohibits real time processing of the data as it requires human-to-human or
human-to-machine interactions [DXH+ 14]. Yet these traditional approaches of
manually overseeing and managing these devices within an industrial environ-
ment can be improved by configuring these devices into an intelligent connected
ecosystem.
This ecosystem embodies the concept of Industrial Internet of Things or Indus-
trial IoT (IIoT) that uses Internet of Things (IoT) technologies for industrial
purpose such as manufacturing, supply chain monitor and management system.
It is a type of environment architecture that connects a broad community of
industrial devices within a connected network. If these devices are enabled with
computational capabilities, it will create an environment to process data easily
from industrial machineries [DXH+ 14]. These intelligent devices allow harvest-
ing raw data and managing the dataflow, from devices to the data store, to the
analytic systems and also to the data scientists. This dataflow cycle helps the
data scientists to extract prime value from this data.
Currently there exists several solutions that require users to develop custom im-
plementations to accumulate and process data from such devices, for instance,
OpenMUC, Bosch ProSyst, Eclipse Kura 1.x. But these solutions require inten-
sive knowledge of the framework, industrial protocols and primary knowledge
of programming. This makes it very restrictive for users to easily setup and
develop their own Industrial IoT environment to collect and process device
data.

1
 1.2. MOTIVATION

1.2 Motivation
According to the currently available solutions, the implementation of Indus-
trial IoT application scenarios to process data from industrial devices requires
necessary internal knowledge of available frameworks, industrial protocols and
programming experience as a prerequisite. This eventually constrains users to
invest their time on knowing the framework and developing modules to commu-
nicate with industrial devices rather than focusing on the application scenar-
ios. Hence, proposed system - Kura Wires focuses on easing the development
of Industrial IoT application scenarios to accumulate and process data from in-
dustrial machineries with the help of reusable components, for instance, device
drivers to communicate with industrial devices, data filters, publishers to pub-
lish device data to the cloud, and so on. The system also benefits users to build
custom Industrial IoT applications visually without requiring any programming
experience apriori.

1.3 Objectives
The objectives of the proposed system are to:

• Provide a framework for users to build their own Industrial IoT applica-
tion scenarios to process industrial device data visually and programmat-
ically
• Provide necessary reusable device and data management components
(Cloud Publisher, Cloud Subscriber, Data Store, Data Filter, Timer,
Drivers to communicate with industrial devices of different protocols)
• Provide a Composer UI to contain the aforementioned logical components
as visual elements
• Build Industrial IoT application scenarios by dragging the visual compo-
nents onto the Composer UI and connecting them based on user require-
ments
• Provide an extensible system for IoT application developers to develop
further visual components

1.4 Outline
In this chapter, we have discussed the problem that we are aiming to solve
with the development of Kura Wires. Chapter 2 summarizes the necessary
backgrounds for understanding the system in details. In Chapter 3, we analyze
the requirements of the system, including the different scenarios, use cases,
analysis object model and dynamic model. Thereafter Chapter 4 solidifies the
analysis model towards the system design, whereas Chapter 5 provides the
object design and focuses on reusing the application of design patterns. Finally
in Chapter 6, we include the status of the system development and an outlook
of the future work.

2
Chapter 2
Background

2.1 OSGi
Today’s pervasive computing environments are developed with proprietary tech-
nologies. But they seem to lack a long-term vision of evolution to connect a
wide range of devices and services from different manufacturers. They also
inhibit inter-operation with each other [AN10] [Hel10].
Open Services Gateway Initiative (OSGi) is a standard, non-proprietary, soft-
ware component framework for manufacturers, service providers, and devel-
opers. It provides an extensible environment to connect various devices and
services. The framework can dynamically discover devices and services from
different sources. In addition, the connectivity support in OSGi to the outside
world allows remote control, diagnosis and management [LKR+ 06] [Hel10].
OSGi provides a secure environment that executes applications independently
so that these applications cannot harm the environment or interfere with other
applications. These applications are known as Bundles. OSGi enables co-
existence of different bundles in a single Java Virtual Machine (JVM). Multiple
bundles running on same JVM reduce memory footprint and increase overall
performance [DFK+ 02].
The framework comprises an execution environment that manages the lifecycle
of the bundles without restarting the system. It allows bundles to contribute
code as well as specialized application components, known as services to the en-
vironment. Bundles collaborate with each other through services. Such services
are registered with the framework’s service registry. The framework therefore
advertises these services to make them discoverable by other interested bun-
dles [Hel10].
OSGi framework consists of conceptual layers where each layer is dependent on
the layer(s) beneath it. Figure 2.1 shows the layered architecture of OSGi.

3
 2.2. ECLIPSE KURA

Figure 2.1: OSGi Layers

2.2 Eclipse Kura

Creating an IoT ecosystem of interconnected devices requires a gateway that
connects non IP-based devices to the internet [LNH03]. These gateways are
also known as service gateways which are capable of running advanced software
frameworks that isolate developers from the complexities of the hardware and
the networking sub-systems.
Eclipse Kura is an Eclipse IoT Open Source project that provides a platform for
building such service gateways. It is an application container with wide range
of APIs that allows developers to write and deploy their own applications.
Eclipse Kura runs on top of the Java Virtual Machine and uses OSGi to simplify
the process of writing reusable software building blocks. Kura APIs offer easy
access to the underlying hardware systems such as serial ports, GPS, USB,
GPIO, I2 C, and so on. It also offers functionalities to simplify the management
of network configurations.
While several Eclipse Kura components are in pure Java, others are invoked
through Java Native Interface (JNI) and have a dependency on the Linux op-
erating system.
The functional architecture1 of Eclipse Kura is shown in Figure 2.2. The under-
lying functional elements and the primary goals of Eclipse Kura are summarized
as:

• An OSGi-based container running in service gateways: Eclipse

Kura complements Java and OSGi platforms with APIs and services cov-
ering the common requirements of IoT applications. These services are
as follows:

– Drivers: Serial Port, USB, Bluetooth, GPIO/PWM/I2 C/SPI access

1
Functional architecture denotes the overall architecture using functional elements that
are based on system’s functions [BP10]

4
 2.2. ECLIPSE KURA

Figure 2.2: Functional Architecture of Eclipse Kura

– Cloud Services: Store and forward functionality for the telemetry

data2 collected by the gateway and publish to remote servers
– Configuration Management: Easy to use functionality to import
and export configurations of Eclipse Kura components
– Basic Gateway Services: DB Service provides API to connect to
SQL database storage and Clock Service syncs hardware clock with
time servers
– Network Configuration: API to configure the network interfaces
available in the gateway

• Remote access: Eclipse Kura provides the necessary abstractions to

create an application that can be accessed remotely. Eclipse Kura makes
use of MQTT transport protocol for such remote access to leverage the
benefits of low latency, assured messaging and efficient distribution.

• Adoption of existing javax.* APIs: When available, Eclipse Kura

selects an open source implementation of APIs that are compatible with
the Eclipse license. Examples of such APIs are javax.comm, javax.usb,
and javax.bluetooth.

2
Telemetry Data are the physical data measured by sensors at the source

5
 2.3. DATAFLOW PROGRAMMING

• An emulation environment in Eclipse IDE: Developers can build

applications using Eclipse IDE and deploy directly to the target service
gateway.

• An integrated web interface: Eclipse Kura comprises a rich user in-

terface as shown in Figure 2.3, by which users can access all the afore-
mentioned functionalities.

Figure 2.3: Integrated web interface of Eclipse Kura

2.3 Dataflow Programming

Dataflow is a programming model that has been applied for developing several
Wireless Sensor Network applications [UV05]. An application developed using
this programming model is expressed as a directed graph/flow where each node
can have inputs, outputs or both. The output nodes produce data for the
downstream input nodes. Each node executes independently and does not
affect the execution of other nodes [UV05]. Developing an IoT application
using dataflow programming model offers significant advantage by raising the
abstraction level as the underlying hardware, protocols and functionalities are
abstracted as nodes in a flow [GBL+ 15].
Kura Wires incorporates dataflow programming model where the nodes in the
dataflow graph represent specific abstraction of devices or any specific unit of
work.

2.4 Visual Programming

Typically for a user to write a complex program, the user should learn how to
read and write code. It also takes time to learn the syntax details.

6
 2.5. EDGE COMPUTING

But these complexities of reading and writing code, can be simplified using
visual programming. It enables users to implement a program through con-
necting visual elements as a sequence of functionalities, expressed as a visual
dataflow graph. Many modern IoT systems provide a graphical user interface to
construct such visual dataflow graph [GBL+ 15]. Some of these existing systems
are discussed briefly in Section 2.6 (Related Work).
Kura Wires follows similar approach of creating a visual dataflow graph to
develop an Industrial IoT application.

2.5 Edge Computing

In IoT application development, cloud computing allows users to perform com-
puting tasks entirely over the internet. Introducing a centralized cloud-based
solution, the possibilities of unnecessary latency between events and actions
and potential to network failure increase [AH14].
This is not suitable for IoT applications that require processing closer to the
device (edge) and a tighter coupling between events and actions with minimal
latency [AH14]. For example, in case of a virtual switch and a light bulb, the
system should behave like a real physical switch with minimum delay and high
responsiveness.
Furthermore, pushing raw data to the cloud requires high communication cost
and storage needs. To reduce the cost and to increase the overall responsiveness
of the system, many IoT applications require raw data filtering, aggregation and
analysis locally before data is actually pushed to the cloud [Gil16] [AHH14].
Kura Wires allows users to perform computations on device production data at
the service gateway (edge) before the data is uploaded to the cloud.

2.6 Related Work

In this section, we discuss the available tools that are related to Kura Wires ap-
proach. The functionalities and the restrictions of these tools are also analyzed
to motivate the development of Kura Wires.

2.6.1 Node-RED
Node-RED3 is a browser-based, dataflow editing framework for writing pro-
grams visually where nodes represent databases, functions or smart devices.
These nodes can be connected together to build a visual dataflow graph. Nodes
are encapsulated with additional functionalities that makes them flexible for de-
velopers to write their code and add it as a customized node. This way devel-
opers are able to rapidly design a first prototype [BL14]. Graphical illustration
of Node-RED is shown in Figure 2.4.
Although, Node-RED connects smart devices such as light bulbs and switches,
but the user-interface primarily demands developers to write code snippets in
3
https://nodered.org

7
 2.6. RELATED WORK

Figure 2.4: Node-RED

the Node-RED composer UI to define custom functionality inside a node. In

addition, as of now it does not allow communication with industrial devices for
instance, Modbus, OPC-UA, Siemens S7 PLCs etc. and only process data from
a single data source which constrains users to perform aggregation or custom
operation on input data from different sources.
In contrast to Node-RED, Kura Wires supports communication with industrial
devices and data processing from multiple sources.

2.6.2 SAM Labs

SAM4 is an IoT application framework with a set of smart devices where the
devices are connected using Bluetooth Low Energy (LE) and can run au-
tonomously as each device is equipped with its own battery energy source.
Each smart device has simple functionality which can be, for example, buttons,
LEDs, speakers, and so on. The user can arrange these smart devices by means
of a visual programming interface, running on the computer. The program is
using nodes and edges to connect these smart devices and arrange their func-
tions per drag and drop. Aside from hardware integration, SAM also provides
software features such as social media access.
Smart devices of SAM are constrained to basic functions and it is not possible
to integrate advanced smart devices, for instance, industrial devices (Modbus,
PROFINET, OPC-UA, CANbus etc.). Unlike SAM, Kura Wires focuses on
interacting with industrial devices.

4
https://www.samlabs.com

8
Chapter 3
Requirements Analysis

3.1 Overview
In Chapter 2, we discussed the advantages of different approaches needed to de-
velop Kura Wires. With Kura Wires, the development of Industrial IoT applica-
tions to manage data from industrial machineries does not require any program-
ming experience. It consists of few basic visual components such as communi-
cation with database and industrial devices (Modbus, OPC-UA, PROFINET),
cloud publisher, data filter etc. Kura Wires uses these visual components to
collect only the data of importance from the large amount of data produced by
the industrial processes. Such visual components benefit users to perform data
reduction and collection operations.
This chapter analyzes various requirements of Kura Wires. In Section 3.2, the
missing features in Eclipse Kura are explained and an extended functional archi-
tecture of Eclipse Kura with Kura Wires is shown. Section 3.3 lists the glossary
of important terms to help readers understand the requirements specification
of Kura Wires. Necessary scenarios and use cases are discussed in Section 3.4
and Section 3.5, followed by the functional and non-functional requirements
in Section 3.6. Thereafter Section 3.7 presents the object model and dynamic
model of Kura Wires.

3.2 What is missing in Eclipse Kura?

Eclipse Kura provides useful basic functionalities like Cloud Service, Configu-
ration Service, Remote Management, and so on. In industries, people manually
collect, transform, store, and act upon critical data generated from different
industrial devices [LKY14]. With Eclipse Kura, setting up a service gateway
enables non-IP based devices to connect to the cloud to send their telemetry
data for predictive maintenance.

• But it requires intensive knowledge about Eclipse Kura internals, the

field protocols to communicate with industrial devices and good amount
of programming experience. And hence, people spend more time pro-
gramming their service gateways for implementing such applications to
process industrial device data.

9
 3.2. WHAT IS MISSING IN ECLIPSE KURA?

• It still lacks drivers to connect to industrial devices, for instance, OPC-

UA, Siemens S7 etc.

This necessitates the requirement to provide the device and data management
components to accumulate and process industrial device data and implement
custom industrial application scenarios without the need of any programming
experience. A typical use for this requirement would be in intelligent monitor-
ing, whereby entire fields of sensors connected to industrial devices are mon-
itored and the accumulated data are provided to remote cloud platform for
historical and predictive analysis.
Kura Wires introduces a graphical user interface where users can build their own
Industrial IoT applications visually. This requires interactions with industrial
devices and hence, Kura Wires provides such visual elements. We introduce
Asset as a visual element which associates a driver to interact with physical
devices. Kura Wires also provides such drivers to communicate with industrial
devices that Eclipse Kura 1.x does not.
Figure 3.1 shows the extended functional architecture of Eclipse Kura added
with Kura Wires. The functional blocks Kura Wires and Asset are additionally
added compared to Figure 2.2 whereas Drivers functional block is enhanced
with new implementations to communicate with industrial devices.

Figure 3.1: Functional Architecture of Eclipse Kura with Kura Wires

10
 3.2. WHAT IS MISSING IN ECLIPSE KURA?

3.2.1 Application Store for Eclipse Kura

With Kura Wires, the development of an Industrial IoT application can be split
between two classes of developers. The visual component or node developers
can ensure that the nodes needed to communicate with specific devices and their
required protocol implementations are available, while application developers
can focus on connecting the visual elements and creating dataflow graphs.
Eclipse Marketplace5 is an application store for Eclipse-based solutions. Devel-
opers can add their solutions to Eclipse Marketplace as extensions. Kura Wires
is an extensible framework and it packages few device and data management
components. Developers can develop further visual components for Kura Wires
and make them available to be downloaded from Eclipse Marketplace so that
users can install these extensions directly to their Eclipse Kura installations.
5
https://marketplace.eclipse.org

11
 3.3. GLOSSARY OF TERMS

3.3 Glossary of Terms

Composer UI The canvas area of Kura Wires to create a dataflow
graph
Logical Wire Com- A visual element in Composer UI that represents a
ponent node in Kura Wires dataflow graph. In this docu-
ment, the Logical Wire Component and Wire Compo-
nent terms are used interchangeably
Computational A Logical Wire Component, capable of receiving, pro-
Wire Component cessing and emitting data. It can be, for example,
data store, data filter, data publisher etc.
Industrial Device A field device in conjunction with a specific protocol

Asset A Logical Wire Component, able to communicate with

specific sensors and actuators of Industrial Device
Channel A measurement point on an Asset. Each Asset
has multiple Channels for reading and writing data
from/to Industrial Device
Wire A connection between Logical Wire Components that
allows to define a concrete dataflow in Kura Wires
Modbus Device An Industrial Device, working on top of Modbus pro-
tocol
Modbus Asset An Asset to communicate with Modbus Device

OPC-UA Device An Industrial Device that works on top of OPC-UA

protocol
OPC-UA Asset An Asset to interact with OPC-UA Device

S7 Device An Industrial Device, working on top of PROFINET

protocol
S7 Asset An Asset, capable of communicating with S7 Device

DB Store A Wire Component that stores data to a configured

database storage
DB Filter A Wire Component, capable of filtering data from a
configured database storage
Timer A Wire Component that triggers event on every con-
figured time interval
Cloud Publisher A Wire Component that publishes data to a config-
ured Cloud Platform
Cloud Subscriber A Wire Component that subscribes to a configured
Cloud Platform for data

12
 3.4. KURA WIRES

Wire Graph A dataflow graph comprising several aforementioned

Wire Components in Kura Wires
Cloud Platform A platform that enables integration for IoT solu-
tions. Consider, for example, a manufacturing plant
equipped with sensors that monitors parts of the pro-
duction line. Sensor produced information gets aggre-
gated and processed in real time by Cloud Platform
Kura-compliant A third-party application that communicates with
App Eclipse Kura equipped service gateway from remote
location. This communication is mediated by Cloud
Platform as Cloud Platform is the central commu-
nication point. Cloud Platform dispatches all mes-
sages between Kura-compliant App and Eclipse Kura
equipped service gateway. Both Kura-compliant App
and the service gateway must be connected to the
same Cloud Platform
to wire (verb) This verb denotes connecting Logical Wire Compo-
nents

3.4 Kura Wires

In this section, scenarios and use cases of Kura Wires are discussed. The sce-
narios are shown in tabular format as mentioned in [BD10].

3.4.1 Scenarios
Scenario 1 - CollectAndFilterModbusDeviceData

Figure 3.2: Collect and filter data from Modbus Device

This scenario as shown in Figure 3.2, describes the steps involved in collecting
data produced by a Modbus Device and filters it based on user-specific criterion.
The Wire Graph to realize this scenario is illustrated in Figure 3.3.

Figure 3.3: Wire Graph to collect and filter data from Modbus Device

13
 3.4. KURA WIRES

Participating actor in- bob:Industrial Engineer, modbusDev:Modbus Device,

stances db:Database, platform:Cloud Platform
1. bob wants to collect and filter data produced by
modbusDev

2. bob opens up Kura Wires Composer UI

3. bob drags Timer, DB Store, DB Filter, Cloud

Publisher and Modbus Asset to the Composer
UI

4. bob wires Timer with Modbus Asset, Modbus

Asset with DB Store, DB Store with DB Filter
and DB Filter with Cloud Publisher

5. bob configures all the Wire Components in the

Wire Graph - reading Channels of Modbus As-
set, period in Timer, cloud publishing parame-
ters in Cloud Publisher, database table name in
Flow of events
DB Store and database query in DB Filter

6. bob saves the Wire Graph

7. Timer triggers event on every configured inter-

val

8. Modbus Asset reads data from modbusDev on

every periodic event triggered by Timer

9. The data collected by Modbus Asset is emitted

to DB Store for storing in db

10. The data is thereafter emitted to DB Filter that

filters and emits the filtered data

11. The filtered data is published to platform by

Cloud Publisher
Entry Condition 1. Eclipse Kura-equipped service gateway must be
connected to platform
Exit Condition 1. Production data from modbusDev gets accumu-
lated by platform

Scenario 2 - WriteModbusDataToS7Device

Figure 3.4: Collect data from Modbus Device and write to S7 Device

14
 3.4. KURA WIRES

Figure 3.4 illustrates the scenario to write Modbus Device produced data to
specific Channels of an S7 Device. The Wire Graph to express this scenario is
shown in Figure 3.5. The steps are also explained as follows.

Figure 3.5: Wire Graph to write Modbus Device data to Channels of an S7 Device

Participating actor in- bob:Industrial Engineer, modbusDev:Modbus Device,

stances s7Dev:S7 Device
1. bob wants to write data produced by modbus-
Dev to specific Channels of s7Dev

2. bob opens up Kura Wires Composer UI

3. bob drags Timer, S7 Asset and Modbus Asset

to the Composer UI

4. bob wires Timer with Modbus Asset, Modbus

Asset with S7 Asset

5. bob configures all the Wire Components in the

Wire Graph - reading Channels of Modbus As-
set, writing Channels of S7 Asset and period in
Timer

6. bob saves the Wire Graph

7. Timer triggers event on every configured inter-

Flow of events
val

8. Modbus Asset reads data from modbusDev on

every periodic event fired by Timer

9. The data from modbusDev is collected by Mod-

bus Asset and gets emitted to the connected S7
Asset

10. The S7 Asset abstracts all necessary communi-

cations with s7Dev

11. Received data is validated whether the data can

be written to s7Dev Channels

12. If the validation is successful, the data is writ-

ten to the configured Channels of s7Dev by S7
Asset and if not, bob is notified with proper in-
formative message about the error

15
 3.4. KURA WIRES

Scenario 3 - QueryModbusDeviceConnectedLedStatus

Figure 3.6: Query Modbus Device status from remote location

An Industrial IoT environment incorporates the use of several physical devices.

It is also imperative to query the status of these devices from remote location.
This scenario as shown in Figure 3.6 describes the steps in querying a Modbus
Device-connected LED sensor status from a remote location.
To retrieve the status of a Modbus Device, Industrial Engineer creates the Wire
Graph as shown in Figure 3.7.

Figure 3.7: Wire Graph to query the status of connected Modbus Device

Participating actor in- bob:Industrial Engineer, modbusDev:Modbus Device,

stances client:Kura-compliant App, platform:Cloud Platform
1. bob wants to check the status of the
modbusDev-connected LED from his home

2. bob uses client from his home and sends a re-

quest to retrieve the status of the modbusDev-
connected LED

3. Kura Wires receives the remote request

Flow of events
4. Kura Wires queries the configured modbusDev
in the Wire Graph for the status of its connected
LED sensor

5. modbusDev responds to the query with the LED

status

6. Kura Wires sends the response status back to

the client

16
 3.4. KURA WIRES

1. Eclipse Kura-equipped service gateway must be

connected to platform

2. bob has developed a Wire Graph in the Eclipse

Kura-equipped gateway in the factory

3. The Wire Graph comprises Timer, Modbus As-

Entry Condition set and Cloud Publisher

4. bob has configured all the Wire Components -

LED status reading Channel of Modbus Asset,
period in Timer and cloud publishing parame-
ters of Cloud Publisher in the Wire Graph

5. client is connected to platform

Exit Condition 1. bob received status acknowledgment in client

Scenario 4 - ChangeRemoteOpcUaConnectedActuatorData

Figure 3.8: Change OPC-UA Device data from remote location

Industrial IoT applications can be implemented in different factories. This sce-

nario gives an example of inter-communication between two Industrial IoT ap-
plications. A factory implements an application scenario to collect data from a
Modbus Device and publish it to the Cloud Platform as discussed in CollectAnd-
FilterModbusDeviceData scenario. In another factory, another Industrial IoT
application is interested to consume the same Modbus Device produced data
by an OPC-UA Device as shown in Figure 3.8. The corresponding Wire Graph
to realize this scenario is shown in Figure 3.9.

Figure 3.9: Wire Graph to write to specific Channels of a remote OPC-UA Device

The steps involved in data consumption by an OPC-UA Device are described

in the following table.

17
 3.4. KURA WIRES

Participating actor in- bob:Industrial Engineer, modbusDev:Modbus Device,

stances opcUaDev:OPC-UA Device, platform:Cloud Platform
1. bob wants to change opcUaDev-connected actu-
ator data to the data produced by modbusDev-
connected sensor. Both these devices are con-
nected to different service gateways in remote
locations

2. bob opens up Kura Wires Composer UI in both

the gateways

3. bob drags and wires the required Wire Compo-

nents to create a Wire Graph in the gateway
to read modbusDev-connected sensor data and
send it to platform (Timer is wired with Modbus
Asset, Modbus Asset is wired with DB Store,
DB Store is wired with DB Filter and DB Fil-
ter is wired with Cloud Publisher)

4. bob also drags and wires the required Wire

Components to create a Wire Graph in other
gateway to change the opcUaDev-connected ac-
tuator data (Cloud Subscriber is wired with
Flow of events
OPC-UA Asset)

5. bob saves both Wire Graphs in different gate-

ways

6. The Wire Graph that reads modbusDev-

connected sensor data initiates processing and
the sensor data is published to platform

7. The Wire Graph that changes the opcUaDev-

connected actuator data, receives the published
modbusDev data from platform as it is sub-
scribed to platform

8. The received modbusDev-connected sensor data

is emitted to OPC-UA Asset as it is a down-
stream component of Cloud Subscriber in the
Wire Graph

9. opcUaDev now changes its connected actua-

tor data to the data produced by modbusDev-
connected sensor

18
 3.5. USE CASE MODEL

3.5 Use Case Model

In this section, we thoroughly discuss the use cases of Kura Wires.

3.5.1 High-level Use Cases

Developing an Industrial IoT application in Kura Wires to process data from
machineries requires Industrial Engineer to drag the Wire Components to the
canvas area. The canvas area enables users to wire these Wire Components
together and configure them accordingly.
Figure 3.10 describes the high-level use cases to create an Industrial IoT appli-
cation in Kura Wires.

Figure 3.10: Create Industrial IoT Application (UML Use Case Diagram)

3.5.2 Configure Wire Component

As aforementioned, creating an Industrial IoT application in Kura Wires re-
quires Industrial Engineer to drag the Wire Components onto the canvas, wire
and configure them accordingly. There exists different types of Wire Compo-
nents for instance, DB Store, DB Filter, Asset, and so on. Each Wire Component
needs different types of configurations.
Hence, different use cases to configure different Wire Components in Wire Graph
are shown in Figure 3.11. Table 3.1 lists different Wire Components and their
associated configuration properties.

19
 3.5. USE CASE MODEL

Table 3.1: Configuration parameters of Wire Components and Driver

Timer Interval period in milliseconds

DB Store Database table name

DB Filter Database query string

Cloud Publisher Cloud Platform publishing configuration,

such as internet endpoint URL to publish to
Cloud Platform
Cloud Subscriber Cloud Platform subscription configuration,
such as internet endpoint URL to subscribe
to Cloud Platform
Asset Input and output Channels

Driver Serial, TCP or UDP connection configura-

tion

Figure 3.11: Configure Wire Component (UML Use Case Diagram)

20
 3.5. USE CASE MODEL

Configure Asset
Asset is a specialized Wire Component that interacts with physical devices.
Configuring an Asset requires Industrial Engineer to specify the Channels to
read and/or write data from/to Industrial Device. An Asset associates a Driver
to communicate with Industrial Devices that hides the low-level complexities.
Hence, configuring an Asset includes both Driver and Channel configurations.
Figure 3.12 shows the different use cases to configure an Asset in a Wire Graph.

Figure 3.12: Configure Asset (UML Use Case Diagram)

3.5.3 Perform Remote Request

Kura Wires enables Industrial Engineer to send remote requests by means of
Kura-compliant App for performing reading and writing operations on Industrial
Devices. As an example, in Subsection 3.4.1 (Scenarios), we have discussed
QueryModbusDeviceConnectedLedStatus scenario that describes the steps to
query the status of a Modbus Device-connected LED sensor from remote loca-
tion.
In Figure 3.13, the use cases to perform such remote requests on Industrial
Devices are shown. These use cases are,

• GetAllDevices: Industrial Engineer lists all the Assets configured in the

Wire Graph from remote location.

• GetAllChannelsOfDevice: Industrial Engineer lists all the Channels of an

Asset from remote location.

• ReadSpecificChannel: Industrial Engineer reads specific Channels of an

Asset.

21
 3.5. USE CASE MODEL

Figure 3.13: Perform Remote Request (UML Use Case Diagram)

• WriteToSpecificChannel: Industrial Engineer writes to any specific Chan-

nel of an Asset.

3.5.4 Filter, Store, Publish and Receive Data

Considering the previously discussed (CollectAndFilterModbusDeviceData) sce-
nario, Kura Wires allows Industrial Engineer to develop Industrial IoT applica-
tions to collect device data, filter it and publish to Cloud Platform for further
analysis. Referring to ChangeRemoteOpcUaConnectedActuatorData scenario,
Industrial Engineer can receive already published Industrial Device data from
Cloud Platform to process in a remote location.
Figure 3.14 presents the use cases to filter, store, publish and receive Industrial
Device data. These use cases are also discussed below.

• FilterData: Industrial Engineer filters the device data that meet specific
criteria. For instance, Industrial Engineer can filter temperature sensor
data which is more than 20 degrees centigrade. Filters can be written
down using query language in database.

• StoreData: Industrial Engineer stores device data to a database storage.

• PublishData: Industrial Engineer publishes device data to the Cloud Plat-

form for further aggregation and analysis.

• ReceiveData: Industrial Engineer receives already published device data

from the Cloud Platform for further processing.

22
 3.6. REQUIREMENTS

Figure 3.14: Filter, Store, Publish and Receive data (UML Use Case Diagram)

3.6 Requirements
In this section, we infer the functional and non-functional requirements of Kura
Wires after analyzing the different scenarios and use cases as discussed previ-
ously.

3.6.1 Functional Requirements

Functional Requirements refer to the high-level functionalities of the system
[BD10]. In this subsection, we list all the functional requirements of Kura
Wires.

FR1 Composer UI: Eclipse Kura should introduce an interactive canvas to

wire different Wire Components.

FR2 Wire Components: The Composer UI should contain the Wire Compo-
nents to build Industrial IoT applications to communicate with Modbus,
OPC-UA and S7 Devices.

FR3 Drag and Drop of Wire Components to Composer UI: The Com-
poser UI should support drag and drop of available Wire Components to
the Composer UI.

FR4 Connect Wire Components: Wire Components have connectors to

connect to other Wire Components. Hence, the Composer UI should allow
users to connect Wire Components with each other based on user IoT
application scenario.

23
 3.6. REQUIREMENTS

FR5 Configure Wire Components: The Composer UI should enable con-

figurations of all available Wire Components. For example, reading and
writing Channels of Industrial Devices. In Table 3.1, we have earlier men-
tioned the different configurable properties of the Wire Components.

FR6 Read Data from Industrial Device: The framework should support
reading data from Industrial Devices (Modbus, OPC-UA and S7).

FR7 Write Data to Industrial Device: Users should be able to write data
to Industrial Devices (Modbus, OPC-UA and S7).

FR8 Publish Industrial Device Data to Cloud Platform: The frame-

work should allow publishing the produced data from Industrial Devices
to Cloud Platform.

FR9 Filter Device Data: The framework should provide support for filtering
Industrial Device produced data. For instance, Industrial Engineer should
be able to filter out temperature sensor measurement data which is more
than 20 degrees centigrade.

FR10 Remote Access: Users should be able to remotely perform read/write

operations on the Industrial Devices. The framework should support read-
ing/writing data from/to Channels of the Assets configured in the Wire
Graph using Kura-compliant App.

FR11 Inter-Gateway Communication between Wire Graphs: The frame-

work should communicate between different Wire Graphs. One Wire
Graph in a service gateway should be able to emit its dataflow to an-
other Wire Graph implemented in another service gateway. This allows
inter-gateway communication between Wire Graphs in different gateways.

3.6.2 Nonfunctional Requirements

Nonfunctional requirements denote user specific requirements which are not
directly related to functionalities. These are also known as quality attributes of
the system [BD10]. This subsection discusses the nonfunctional requirements
of Kura Wires.

NFR1 Usability: The user must be able to implement an Industrial IoT sce-
nario in Kura Wires without any programming experience.

NFR2 Extensibility: Developers must be able to add new Wire Components

to Kura Wires Composer UI. Such additions require the system not to be
temporarily shut down while new modules get added to the system. In
addition, no modifications of the existing system should be required.

NFR3 Modifiability: Users must be able to modify already implemented In-

dustrial IoT scenario at runtime. This must not require the system to be
temporarily shutdown.

24
 3.7. SYSTEM MODEL

NFR4 Low-Bandwidth Network: The system must respond to remote re-

quests even if it is connected to a network using 56K analog modem.

NFR5 Packaging: The system must be packaged with future Eclipse Kura 2.0
releases.

NFR6 Legal: The system must be licensed under Eclipse Public License v1.0
for open source contribution.

NFR7 Supportability: As discussed in Subsection 3.2.1 (Application Store

for Eclipse Kura), Kura Wires must allow users to discover and install
further Wire Components as extensions listed on the Eclipse Marketplace
portal directly into their Eclipse Kura installations.

3.7 System Model

This section discusses the participating entity, boundary, and control objects of
Kura Wires, and refines them by adding attributes and associations to the anal-
ysis object model. It also identifies inheritance relationships and consolidate
the analysis object model. Finally the activity diagrams to represent activities
of previously identified scenarios are shown.

3.7.1 Analysis Object Model

In this subsection, we introduce the associated entity, boundary and control
objects of Kura Wires.

Entity Objects

Entity objects are the persistent information of a system [BD10]. The objective
of entity objects are to store information after completion of a use case and to
define behaviors for manipulating this information. Here we explore the entity
objects of Kura Wires to build an Industrial IoT application visually.

• Wire Graph and Wire Component: In Kura Wires, the dataflow graph
is persisted as WireGraph entity object. A connection information between two
Wire Components are stored as WireConfiguration and a WireGraph comprises
multiple WireConfigurations that denotes an entire dataflow graph. Each node
in Kura Wires dataflow graph is stored as WireComponent.
There exists two different types of Wire Components - Wire Receiver that only
receives data and Wire Emitter that only produces data. These specialized
types of Wire Components are persisted as WireEmitter and WireReceiver entity
objects.
Every Wire Component is responsible for either producing data for its down-
stream Wire Components or consuming data from its upstream Wire Compo-
nents. This data is encapsulated in WireEvent entity object.

25
 3.7. SYSTEM MODEL

Table 3.2: Entity Objects associated with Wire Graph and Wire Component in Kura
Wires

WireGraph A dataflow graph in Kura Wires

WireComponent A node in a Wire Graph

WireEmitter A WireComponent, capable of emitting data

to its downstream WireComponents
WireReceiver A WireComponent, capable of receiving data
from its upstream WireComponents
WireConfiguration A connection between a WireEmitter and a
WireReceiver
WireEvent A dataflow event that encapsulates the data
produced by a WireEmitter

Figure 3.15 shows these entity objects and their relationships and Table 3.2
gives an overview of these entity objects.

Figure 3.15: Wire Graph and Wire Component (UML Class Diagram)

• Asset and Driver: An Asset is a specialized Wire Component, capable of

communicating with specific sensors and actuators of an Industrial Device. In
Kura Wires, it is represented as Asset entity object which is both WireEmitter
and WireReceiver. Asset associates a Driver that is a protocol-specific imple-
mentation to communicate with Industrial Devices.
In Figure 3.16, the entity objects to express an Asset in a Wire Graph are shown
whereas Table 3.3 lists these objects.

26
 3.7. SYSTEM MODEL

Table 3.3: Entity Objects associated with Asset in Kura Wires

Asset A WireComponent to communicate with In-

dustrial Devices
Driver Specific implementation of a field protocol,
associated with Asset

Figure 3.16: Asset and Driver (UML Class Diagram)

• Specialized Wire Components: The main objective of Kura Wires is to

manage data from Industrial Devices. Kura Wires includes different types of
Wire Components to perform operations on the data, for instance, a DB Store
is used to store data to a database storage whereas a DB Filter filters data from
the stored records in a database using a database query. Communication with

27
 3.7. SYSTEM MODEL

Table 3.4: Entity Objects associated with different Wire Components in Kura Wires

DbFilter A WireComponent to filter data from

database
DbStore A WireComponent to store data to database

CloudPublisher A WireComponent to publish data to Cloud

Platform
CloudSubscriber A WireComponent to subscribe to Cloud
Platform for data
Timer A WireComponent that triggers event on con-
figured time interval

Cloud Platform requires Cloud Publisher and Cloud Subscriber. Additionally,

Timer Wire Component fires events on every configured time interval. Corre-
sponding entity objects of these Wire Components are listed in Table 3.4 and
their associations are shown in Figure 3.17.

Figure 3.17: Specialized Wire Components (UML Class Diagram)

28
 3.7. SYSTEM MODEL

Boundary Objects

Boundary object communicates with the external environment and shows the
interactions between the user and the system [BD10].
Kura Wires uses a Composer UI with which Industrial Engineer is able to im-
plement an Industrial IoT scenario. The Composer UI contains a Canvas to
wire different Wire Components visually. It also contains different Configura-
tionForms to configure aforementioned entity objects (Table 3.2, 3.3 and 3.4).
Earlier in Table 3.1, we also listed different configurable properties of all Wire
Components and Driver. Figure 3.18 shows different boundary objects and their
associations in Kura Wires. In Table 3.5, these boundary objects are discussed.

Figure 3.18: Boundary Objects of Kura Wires and their associations

29
 3.7. SYSTEM MODEL

Table 3.5: Boundary Objects of Kura Wires

Canvas The drawing area of Kura Wires in which In-

dustrial Engineer builds Industrial IoT ap-
plications visually
ConfigurationForm A web form in Kura Wires that allows In-
dustrial Engineer to configure different Wire
Components and Drivers
TimerConfigForm A ConfigurationForm to configure Timer by
providing periodic interval
DbFilterConfigForm A ConfigurationForm to configure DbFilter
by providing the database query
DbStoreConfigForm A ConfigurationForm to configure DbStore
by providing database table name to store
records
CloudPublisherConfigForm A ConfigurationForm to configure data pub-
lishing endpoint URL for publishing data to
Cloud Platform
CloudSubscriberConfigForm A ConfigurationForm to configure data sub-
scription endpoint URL to subscribe to
Cloud Platform
DriverConfigForm A ConfigurationForm to configure Driver, for
instance, TCP, UDP or Serial connection
configuration
AssetConfigForm A ConfigurationForm to configure input and
output Channels of an Asset
ComposerUI The primary user interface of Kura Wires
that comprises the aforementioned boundary
objects such as Canvas and different Config-
urationForms

30
 3.7. SYSTEM MODEL

Control Objects

Control objects provide an overall coordination for a group of boundary and

entity objects. A control object is responsible for accumulating information
from its associated boundary objects and provide these information to the entity
objects [BD10].
In Kura Wires, we identify three control objects. For better comprehension, we
also include the attributes and methods in the following figures (Figure 3.19,
3.20 and 3.21).

• CreateWireGraphControl: This control object is responsible for creat-

ing a WireGraph in the Composer UI. The creation of a WireGraph requires
connections between several Wire Components. This connection is expressed as
WireConfiguration entity object. Figure 3.19 shows the associations among Cre-
ateWireGraphControl and its respective boundary and entity objects to create
a Wire Graph in Kura Wires canvas.

Figure 3.19: CreateWireGraphControl and its associations to create a Wire Graph

(UML Class Diagram)

• RemoteRequestControl: RemoteRequestControl handles remote requests

to perform read and write operations on Industrial Devices. The associations
among RemoteRequestControl and its respective boundary and entity objects
are shown in Figure 3.20. This figure denotes that every remote request is
managed by RemoteRequestControl that internally communicates with Asset
instance to perform requested operation on the Industrial Device.

Figure 3.20: RemoteRequestControl and its association to perform remote request

(UML Class Diagram)

31
 3.7. SYSTEM MODEL

• ConfigurationControl: ConfigurationControl creates instances of entity

objects that are necessary for WireGraph creation. Figure 3.21 identifies the
associations among ConfigurationControl and its respective boundary and en-
tity objects to configure the different Wire Components and Drivers. The con-
figurable properties of all Wire Components and Drivers are also enumerated
earlier in Table 3.1.

Figure 3.21: ConfigurationControl and its associations to configure different Wire

Components and Drivers (UML Class Diagram)

3.7.2 Dynamic Model

Dynamic Model focuses on the behavior of the system. It serves to demon-
strate more complex system behaviors [BD10]. Activity diagrams are one of
the several ways (state machine diagram, sequence diagram) to represent dy-
namic models. It is a simple and intuitive illustration of what happens in a
workflow.
Earlier we have identified the entity, boundary and control objects participat-
ing in the aforementioned use cases. In this subsection, previously discussed
scenarios are described with activity diagrams.
Figure 3.22 shows the high-level overview of activities to create a Wire Graph
for collecting and filtering Modbus Device produced data (CollectAndFilter-
ModbusDeviceData scenario). Industrial Engineer drags and drops the required
Wire Components onto the Composer UI that include a Timer, DB Store, DB
Filter, Asset associated with Modbus Driver and Cloud Publisher. To accumu-
late and filter data, Timer is wired with Asset, Asset is wired with DB Store

32
 3.7. SYSTEM MODEL

and DB Store is wired with DB Filter. Finally to publish data to Cloud Plat-
form, DB Filter is also wired with Cloud Publisher. After connecting these Wire
Components, they are configured accordingly. For reference, the configurable
properties of Wire Components and Driver are listed in Table 3.1.

Figure 3.22: Activities of an Industrial Engineer to create a Wire Graph for collecting
and filtering Modbus Device data (UML Activity Diagram)

Figure 3.23 captures the activities to model the dataflow in the created Wire
Graph.

Figure 3.23: Activities and events in a dataflow of a Wire Graph to accumulate and
filter Modbus Device data (UML Activity Diagram)

Timer initiates dataflow in the Wire Graph when it triggers event every specific
time interval. Its downstream Wire Component Asset receives the event, reads

33
 3.7. SYSTEM MODEL

the configured input Channels and finally fires an event encapsulating the mea-
surement data. This event is then received by DB Store that stores the data
to a database storage and forwards it to DB Filter to execute a database query
for filtering records. The filtered data, thereafter, is emitted to the downstream
Cloud Publisher for publishing to the Cloud Platform.
In Figure 3.24, the activities to query status of an Industrial Device from remote
location are shown. For this activity diagram, we consider previously discussed
scenario - QueryModbusDeviceConnectedLedStatus. This scenario explains the
steps to query the status of a Modbus Device-connected LED sensor. Industrial
Engineer creates a Wire Graph with the required configurations of the Wire
Components and Driver. From remote location (for instance, home), Industrial
Engineer sends a status query request using Kura-compliant App that is received
by the Wire Graph. Wire Graph queries the configured Asset for the status of
its connected LED and responds to the requester Kura-compliant App with the
status information.

Figure 3.24: Interactions of an Industrial Engineer with a Wire Graph to read the
status of Modbus Device-connected LED from remote location (UML
Activity Diagram)

Figure 3.25 describes the activities to achieve inter-gateway communication

between Wire Graphs. These activities are also explained in a previously
discussed scenario - ChangeRemoteOpcUaConnectedActuatorData. To provide
an overview of this scenario, inter-communication between two different Wire
Graphs requires Industrial Engineer to create two Wire Graphs in different ser-
vice gateways. One of the Wire Graphs implements a scenario to collect and
publish data of an Industrial Device and the other one subscribes to Cloud
Platform for data that the previous Wire Graph publishes. This communication
between two Wire Graphs is mediated by Cloud Platform, the central communi-
cation point. Cloud Platform dispatches the messages between Cloud Publisher
and Cloud Subscriber, and hence establishes inter-gateway communication be-
tween Wire Graphs.

34
 3.7. SYSTEM MODEL

Figure 3.25: Interactions of an Industrial Engineer with two different Wire Graphs
for inter-gateway communication (UML Activity Diagram)

35
Chapter 4
System Design

4.1 Overview
In this chapter, we explain all the essential activities required for Kura Wires
system design. In Section 4.2, we ensure that the system addresses all the
nonfunctional requirements and can account for any constraints during the
implementation phase. Section 4.3 decomposes the system into coherent sub-
systems and in Section 4.4, we examine carefully the allocation of subsystems to
computers and the design of the infrastructure for supporting communication
between subsystems. Thereafter in Section 4.5, we identify the different objects
eligible to be persisted and follow storage management strategy as mentioned
in [BD10] to select persistent storage for Kura Wires. Section 4.6 considers the
requirements for designing the Global Control Flow of Kura Wires, followed by
the identification of boundary conditions in Section 4.7 that leads to inclusion
of new use cases to the use case model.

4.2 Design Goals

• Develop Industrial IoT Application Visually: To minimize the need
to develop an Industrial IoT application to process industrial device data
programmatically, visual dataflow programming approach is used. As
Kura Wires is developed on top of Eclipse Kura, we utilize Eclipse Kura
integrated web interface. This design goal is a refinement of nonfunctional
requirement of “usability” of the Kura Wires problem statement.
• Low Operating Cost: To reduce the need to hire a skilled programmer
to develop an Industrial IoT application programmatically, we select vi-
sual paradigm for Kura Wires. This design goal is achieved by addressing
non-functional requirements of “usability”, “extensibility” and “modifiabil-
ity”.
• Ease of Adding New Wire Component and Driver: Kura Wires
enables developers to add new Wire Component and Driver that can easily
be adapted to the system. We identify this design goal to further refine
the nonfunctional requirement of “extensibility”.
• Ease of Auto-Deployment of Industrial IoT Scenario: Kura Wires
allows auto-deployment of Industrial IoT scenarios at runtime. That is,

36
 4.3. SUBSYSTEM DECOMPOSITION

any modification to already implemented scenario in Kura Wires does

not require the system to be temporarily shutdown. This design goal
addresses the nonfunctional requirement of “modifiability”.

• Documentation for Open Source Development: The organization

and documentation of Kura Wires make it easier for new developers to
contribute features to the code. This includes source code documentation
that supports low-level changes and improvements, as well as a good
architecture-level documentation that supports addition of new features.
This design goal further refines the “legal” and “packaging” nonfunctional
requirements.

• Install Wire Component and Driver from Eclipse Marketplace:

Users can extend their own Kura Wires installations by adding new Wire
Component and Driver listed on Eclipse Marketplace portal. This design
goal is a refinement of the nonfunctional requirement of “supportability”.

• Remote Communication Mechanism: Kura Wires handles remote

requests even if it is connected to network using 56K analog modem.
As Eclipse Kura uses industry-standard MQTT6 as the default transport
protocol for device connectivity purposes, we select MQTT protocol as
a transport layer in Kura Wires. This design goal is a refinement of the
nonfunctional requirement of “low-bandwidth network”.

• Reusable Architecture: To allow developers to add or modify function-

alities to the system without reworking on the entire application, we select
a three-tier architecture for Kura Wires. Further discussion of this layered
architecture is continued in Section 4.3. This design goal is achieved by
addressing non-functional requirements of “extensibility” and “supporta-
bility”.

4.3 Subsystem Decomposition

We first identify subsystems from the initial requirements and the analysis
model of Kura Wires. The purpose of this activity is to decompose the sys-
tem in self-contained components to be managed by individuals [BD10]. This
subsystem decomposition are further discussed in Subsection 4.3.1 and 4.3.2.
Referring to the design goal of “reusable architecture”, we have selected a three-
tier architectural style for Kura Wires as it allows developers to make changes
on presentation layer without affecting the other two (application logic and
storage) [BD10]. The layered architecture of Kura Wires is shown in Figure
4.1. These subsystems and their relationships are identified after considering
the cohesive packages and their dependencies from the analysis model of Kura
Wires.
6
http://mqtt.org

37
 4.3. SUBSYSTEM DECOMPOSITION

In this layered architecture, KuraWiresClient subsystem provides an user in-

terface for users to initiate all aforementioned use cases (Section 3.5 Use Case
Model).

Figure 4.1: Kura Wires Subsystem Decomposition

4.3.1 Application Logic Layer

Application Logic subsystem of the architectural design shown in Figure 4.1 is
the domain logic layer. The following subsystems are identified after analyzing
the analysis model as discussed in Section 3.7 (System Model).
• WireComponentManagement: Kura Wires consists of different Wire Com-
ponents such as Timer, DB Store, DB Filter, and so on. After configuring these
Wire Components, WireComponentManagement manages these Wire Component
instances.
• WireManagement: WireManagement component provides services to man-
age (create and remove) connections between Wire Components in a Wire Graph.

38
 4.3. SUBSYSTEM DECOMPOSITION

These connections are persisted as WireConfiguration entity objects in Kura

Wires.
• AssetManagement: Communicating with Industrial Devices in Kura Wires
requires the use of an Asset. Asset is configured with input Channel to read
data from Industrial Device and output Channel to write data. In Kura Wires,
Asset associated Channels are managed by AssetManagement component.
• DriverManagement: An Asset is a specific Wire Component in a Wire
Graph that communicates with an Industrial Device. It associates a protocol-
specific implementation, known as Driver that enables Asset for such commu-
nication. Kura Wires initially provides few Drivers - Modbus, OPC-UA and S7.
DriverManagement subsystem is responsible for performing reading and writing
operations on Industrial Devices.
• RemoteRequestManagement: Kura Wires allows Industrial Engineer to
send remote requests to query the status of gateway-connected Industrial De-
vices. In Kura Wires System Model (Section 3.4), we have identified Re-
moteRequestControl to handle these remote requests. RemoteRequestManage-
ment component manages these remote requests to perform operations on In-
dustrial Devices.

4.3.2 Storage Layer

Storage subsystem of the architectural design shown in Figure 4.1 is the data
access layer. This layer consists of different storage options with which the
application logic cooperates.
• WiresStorage: WiresStorage subsystem persists configuration information
of different entity objects that we have discussed in Section 3.7 (System Model).
These configurations are, for example, the Channel configurations in Asset, a
database query in DB Filter or a table name in DB Store.
• DatabaseStorage: Kura Wires requires WiresStorage to store different con-
figurations. However, DatabaseStorage component is essentially used by DB
Store to store records to a database storage or by DB Filter to execute a
database query to filter data from stored records.
• IndustrialDevice: Kura Wires communicates with Industrial Devices using
Assets. IndustrialDevice component is used by Asset to read or write data
from/to Industrial Devices.
• CloudPlatform: Industrial IoT environment makes use of remote Cloud
Platfrom to perform predictive maintenance and analysis tasks on the teleme-
try data produced by Industrial Devices. Cloud Publisher and Cloud Subscriber
interacts with this CloudPlatform subsystem that primarily aggregates and ac-
cumulates data from remote service gateways.

39
 4.4. HARDWARE SOFTWARE MAPPING

4.4 Hardware Software Mapping

Hardware software mapping activity is essential to address performance or re-
liability issues of the system [BD10]. Therefore, we need to examine carefully
the allocation of existing subsystems to the processors.
Kura Wires is a distributed system as users can use it in factories as well as
from remote location. Users are also able to send remote requests to Eclipse
Kura-equipped service gateway to query status of the connected Industrial De-
vices. To facilitate such remote communication, it is essential to have internet
connection in the service gateway in which Eclipse Kura with Kura Wires is
installed. It therefore enables users to use Cloud Publisher to publish Industrial
Device data to Cloud Platform for further aggregation, analysis and predictive
maintenance.
Considering the use cases, we select EclipseKuraGateway (Figure 4.2) to host
all the subsystems that are shown in Figure 4.1. In an installation of Kura
Wires with all the Drivers and Wire Components, all subsystems are collocated
onto a single EclipseKuraGateway. In Figure 4.2, the WiresApplication sub-
system incorporates the nested components as shown in the Application Logic
subsystem in Figure 4.1.

4.4.1 Third-Party Libraries

For the realization of Kura Wires, we select OSGi framework to build the com-
plete Kura Wires application on top of Eclipse Kura. In Chapter 2 (Back-
ground), we explained the advantages of OSGi to build complex modular ap-
plications like IDEs (Eclipse), application servers (GlassFish, IBM Websphere,
Oracle Weblogic, JBoss), application frameworks (Spring), industrial gateways,
phones, and so on. A software module is a deployable, manageable and reusable
unit. The best candidate of the unit of modularity on the Java platform is the
JAR file [Kno12]. The de facto standard module system on the Java platform
is OSGi and Kura Wires takes advantages of its runtime capabilities. It will
also be easier to maintain the framework as it evolves.
Consequently, KuraWiresClient is a web application on top of Eclipse Kura built
upon GWT7 and JointJS8 . GWT benefits us to use Java EE specifications for
a full-fledged web application in OSGi environment whereas JointJS is used to
create a Wire Graph visually. JointJS is a modern HTML 5 JavaScript library
for visualization and interaction with diagrams and graphs. KuraWiresClient
accesses WiresApplication through the inbuilt Jetty9 server packaged in Eclipse
Equinox10 OSGi implementation.
Eclipse Kura provides a built-in support to communicate with Cloud Platform
using MQTT. It also offers a JDBC connection to store records to database
storage. This JDBC connection in the framework can be configured to connect
7
http://www.gwtproject.org
8
http://jointjs.com
9
http://www.eclipse.org/jetty
10
http://www.eclipse.org/equinox

40
 4.4. HARDWARE SOFTWARE MAPPING

to any remote SQL database storage as well. To realize communication with

Modbus Devices, we reuse the available software library j2mod11 . To commu-
nicate with OPC-UA Devices, we use Eclipse Milo12 library as it is the only
Open Source implementation of OPC-UA in Java as of now. For PROFINET
communication with Siemens S7 Devices, s7connector13 library is used in Kura
Wires.

Figure 4.2: Kura Wires Hardware Software Mapping (UML Deployment Diagram)
11
https://github.com/steveohara/j2mod
12
https://github.com/eclipse/milo
13
https://github.com/s7connector/s7connector

41
 4.5. PERSISTENT DATA MANAGEMENT

4.5 Persistent Data Management

Having identified the subsystems, and the hardware software mapping, we now
focus on persistency management.

Identifying persistent objects

Kura Wires deals with sets of configurations and objects that need to be stored.
The first set includes the objects that are managed by aforementioned Wire-
ComponentManagement and WireManagement subsystems. The different Wire-
Component instances to create a Wire Graph need to be persisted with all of its
configurations. Furthermore, the WireManagement subsystem needs to persist
the WireConfiguration instances that represent the connections between Wire
Components. Accumulating data from Industrial Devices requires the use of As-
set and an Asset associates a protocol specific Driver. Considering AssetMan-
agement and DriverManagement subsystems, the configurations of input and
output Channels of an Asset and connection specific configurations of Driver
need to be stored in a persistent storage as well.
On the other hand, the requirement to store Industrial Device data using a DB
Store requires the use of specific database storage.

Selecting a storage strategy

Selecting a persistent storage strategy during system design enables us to deal

with other issues related to storage management, such as concurrency control
and crash recovery [BD10].
To minimize operating costs, Kura Wires uses flat files for storage. Such a
system is installed easily, since there is no database management system to
configure or to manage. Of course, we require the database management system
to store machine production data to a specific database storage. However, we
need flat files to manage the persistent objects.
To achieve our goals, we use the default mechanism provided by Eclipse Kura.
Configuration of component instance in Eclipse Kura is managed in flat XML
structured files, known as Snapshot. These snapshot files are primarily required
to store and retrieve configurations of every configurable component instance
in Eclipse Kura. This mechanism is never used to perform any complex query
to retrieve data. Snapshot is imperative to store only configurations so that
during every system restart the component instances are recreated from the
stored configurations.
Snapshot mechanism in Eclipse Kura works in combination with OSGi inbuilt
mechanism to store configurations in flat files. This mechanism captures con-
figurations of component instances at any point of time. This also provides
the ability to use any previously stored snapshot or to rollback to any older
version of snapshot. In addition, snapshot mechanism allows configuration to
be managed remotely through the Cloud Platform services, that is, from Cloud

42
 4.6. GLOBAL SOFTWARE CONTROL

Platforms, the user can remotely update the configuration of component in-
stances.

4.6 Global Software Control

WireManagement subsystem is responsible for managing the established Wires
or connections between different Wire Components in a Wire Graph. After
analyzing the different mechanisms (Procedural-driven control, Event-driven
control and Threads) as stated in [BD10], we select the event-driven mechanism
for WireManagement subsystem so that the connected Wire Components start
processing as soon as they receive data from their upstream Wire Components.
This way the data processed by a specific Wire Component is dispatched to the
connected Wire Component(s) to start further processing.
The RemoteRequestManagement subsystem receives remote requests to per-
form read and write operations on the Industrial Device and dispatches the
operation request to the AssetManagement subsystem. The RemoteRequest-
Management subsystem hence waits for requests. Upon receipt of any remote
request, the subsystem processes the request and sends it to the AssetManage-
ment subsystem to perform, thus resulting in an event-based control flow.
Considering Kura Wires subsystem decomposition as shown in Figure 4.1, Wire-
Management subsystem relies on services provided by AssetManagement sub-
system. Similarly AssetManagement uses the services provided by DriverMan-
agement subsystem. As we have selected event-based control flow for both the
WireManagement and RemoteRequestManagement subsystems, it is inherent
that the subsystems that WireManagement and RemoteRequestManagement
depend on, also result in an event-based control flow.

4.7 Boundary Conditions

During this activity, we review the design decisions made so far and identify
additional use cases. This section examines the different types of failures that
Kura Wires can encounter and addresses the initiation and finalization of the
system.

Exception use cases

Kura Wires can encounter the following system failures:

• Loss of configuration data due to exceptional conditions, such as system
reboot in case of operating system malfunction
• Connection failure to the Industrial Device
• Exceptions occurred while reading or writing data from/to the Industrial
Device as a result of Channel malconfiguration
These system failures result in three additional use cases that are illustrated in
Figure 4.3.

43
 4.7. BOUNDARY CONDITIONS

Figure 4.3: Kura Wires boundary use cases to handle exceptional conditions (UML
Use Case Diagram)

• StoreConfigurationInSnapshot: The system enables Industrial Engineer

to store the configuration of the current persistent objects anytime to a
snapshot file. Additionally, Eclipse Kura incorporates default mechanism
to automatically store the configurations of persistent objects as soon
as any configuration in the system is changed. This eventually makes it
highly unlikely to lose any configuration data even when some exceptional
condition occurs.

• ValidateConnectionToIndustrialDevice: Kura Wires validates the con-

nection to the Industrial Device, configured in the Wire Graph. It also
notifies Industrial Engineer with proper error message in the event of
connection failure.

• ValidateChannelConfiguration: Kura Wires checks the validity of the

provided Channel configurations of the Assets in the Wire Graph. In
case of malconfiguration, it also notifies Industrial Engineer with proper
error message.

44
 4.7. BOUNDARY CONDITIONS

Figure 4.4: Kura Wires boundary use cases to handle startup and shutdown condi-
tions (UML Use Case Diagram)

Startup and Shutdown use cases

Here we describe what has to be done while starting or ending Kura Wires.
This results in two additional use cases.

• StartupAndLogin: Kura Wires is packaged as a standalone application on

top of Eclipse Kura. When an Industrial Engineer logs into Eclipse Kura,
he has the list of menu options to select from. The list comprises Wires
which refers to the system - Kura Wires. After selecting Wires from the
menu, the Canvas area and a toolbox to use the Wire Components appear.

• Shutdown: Kura Wires is shutdown if Industrial Engineer performs this op-

eration voluntarily. In the event of operating system malfunction, it is
possible to encounter system restarts but such use case does not cause
harm to the system. This use case has already been addressed in the
exception boundary use cases.

45
Chapter 5
Object Design

5.1 Overview
This chapter discusses Kura Wires object design and the application of well-
known design patterns to it. Section 5.2 explains how data is represented in
Kura Wires. We separate the object designs into various cohesive figures. From
Section 5.3 to Section 5.5, we provide the object designs of identified subsystems
of Kura Wires. Section 5.6 provides an overview of how configurations are
managed, followed by MQTT communication mechanism in Section 5.7.

5.2 Data Representation

Data Type

Wire Components can only understand specific data types, and are therefore
restricted in what data they can process. Figure 5.1 shows the different data
types required for connected Wire Components to communicate with each other.

Figure 5.1: Data types for communication between Wire Components (UML Class
Diagram)

46
 5.3. WIRE COMPONENT MANAGEMENT

Figure 5.2 shows the relevant classes and their associations that describe data
processed by the Wire Components. It represents the data that flows in a Wire
Graph.

Figure 5.2: Data in dataflow of Wire Graph (UML Class Diagram)

5.3 Wire Component Management

In Section 4.3 (Subsystem Decomposition), we have decomposed Kura Wires
into cohesive subsystems. The intent of WireComponentManagement subsys-
tem is to manage configured Wire Component instances. This is achieved by
using OSGi Wire Admin specification.

OSGi Wire Admin

OSGi Wire Admin, a specification in OSGi that enables OSGi services to gener-
ate data and send it to the services interested in the same data. Interested ser-
vices therefore receive new data regularly from the OSGi services that produce
data. For instance, a physical device produces information about its current
status. Data consumers such as an user interface, detector etc. consume this
information to know the status of the device.
Figure 5.3 shows the significant APIs of OSGi Wire Admin specification.

Figure 5.3: OSGi Wire Admin specification (UML Class Diagram)

WireComponentManagement subsystem and its association with OSGi Wire

Admin specification are shown in Figure 5.4.

47
 5.4. ASSET AND DRIVER MANAGEMENT

Figure 5.4: WireComponentManagement subsystem (UML Class Diagram)

5.4 Asset and Driver Management

In Kura Wires, an Asset, a specific Wire Component in a Wire Graph, commu-
nicates with an Industrial Device. It is configured with input Channel to read
data from Industrial Device and output Channel to write data. Configuration of
the Channels are managed by AssetManagement component that is presented
in Figure 5.5.
A Driver is an implementation of a field protocol that is associated with an As-
set. DriverManagement subsystem performs the reading and writing operations
on the Industrial Device that is shown in Figure 5.6.

Figure 5.5: AssetManagement subsystem (UML Class Diagram)

48
 5.4. ASSET AND DRIVER MANAGEMENT

Figure 5.6: DriverManagement subsystem (UML Class Diagram)

5.4.1 Associate Driver with Asset

Now we concentrate on the procedure that Kura Wires follows to associate a
Driver with an Asset. Figure 5.7 shows how a Driver instance is injected to an
Asset using OSGi Whiteboard Pattern.

Figure 5.7: Associate Driver with Asset (Dependency Injection)

Whiteboard Pattern

It is an inversion of control in which the service requester publishes a handle of

the requested service. The service registry notifies the service provider about

49
 5.5. WIRE MANAGEMENT

Figure 5.8: Whiteboard Pattern

the interested consumers. The provider then binds to the requester by invoking
the service handle [KH04]. Figure 5.8 provides an overview of this mechanism.
In this figure, a Component is an object that implements a number of service
roles, potentially from different services. A service component can depend on
a number of other services and uses any number of implementation classes.
Kura Wires uses OSGi Declarative Service specification [All07] to dynamically
inject service dependencies.

5.5 Wire Management

Earlier in Section 4.3 (Subsystem Decomposition), we have identified WireM-
anagement subsystem to manage the connections between Wire Components.
As discussed, Kura Wires uses OSGi Wire Admin specification to manage the
Wire Component instances. In addition, OSGi Wire Admin also enables OSGi
services to receive the new data regularly from the OSGi services that produce
data. Therefore in Kura Wires, OSGi Wire Admin also contributes to the man-
agement of connections between Wire Components.

Managing Dataflow between Wire Components

Figure 5.9 shows the object design of WireManagement subsystem to emit or

receive data in Wire Graph.

50
 5.5. WIRE MANAGEMENT

Figure 5.9: WireManagement subsystem to emit/receive data (UML Class Diagram)

5.5.1 Wire Connections

In Figure 5.3, the relevant APIs of OSGi Wire Admin specification are pre-
viously shown, that Kura Wires uses for connecting and managing the Wire
Components.
OSGi Wire Admin connects a Producer and a Consumer by creating a Wire
instance. According to Figure 5.4, a WireEmitter is also a Producer and a
WireReceiver is a Consumer. If the Consumer and Producer are connected,
OSGi Wire Admin calls the consumersConnected(Wire[]) method on the Pro-
ducer object and producersConnected(Wire[]) method on the Consumer object.

Figure 5.10: WireManagement subsystem to manage Wire Configurations (UML

Class Diagram)

To simplify new connection creation between a WireEmitter and a WireRe-

ceiver or to delete an existing one, the relevant API methods are provided by
WireService (Figure 5.10).

51
 5.5. WIRE MANAGEMENT

5.5.2 Push Pattern

In Kura Wires, the communication between Wire Components occurs in a Push-
based pattern. That is, the data as emitted by a WireEmitter is pushed to its
connected WireRecievers. As OSGi Wire Admin works as a mediator between
WireEmitter and WireReceiver, they are not tightly coupled.
In Figure 5.11, we illustrate the high-level overview of the dataflow communi-
cation mechanism between WireEmitter and WireReceiver instances.

Figure 5.11: Dataflow Communication between Wire Emitter and Wire Receiver
(UML Sequence Diagram)

To produce new data, every WireEmitter must override the polled(Wire) ab-
stract mehtod which is used by Wire object in WireConfiguration to poll new
data from WireEmitter and push it to the connected WireReceiver. When
the WireEmitter produces new data, the WireEmitter calls the update(Object)
method on the Wire object. The Wire object implementation must then call the
updated(Wire, Object) method on the WireReceiver instance which internally
creates WireEnvelope object from the received data and invokes onWireRe-
ceive(WireEnvelope) method on the same WireReceiver instance.

5.5.3 Visitor Pattern

According to the object design of WireManagement subsystem (Figure 5.9),
WireEmitter does not declare any specific method for emitting data.
Every WireEmitter therefore must override the polled(Wire) abstract method of
Producer to emit data. To make it easier for implementors to conform to Kura
Wires data model (Figure 5.2), WireSupport provides emit(List<WireRecord>)
method. However, a WireEmitter is not restricted to emit a specific type of
data, but it can optionally use an instance of WireSupport to emit WireRecords
to be compliant with the current data model of Kura Wires.
WireEmitter does not contain any emit(List<WireRecord>) method, rather it
is kept separated in WireSupport. This is because future extenders of Kura
Wires can make use of another data model instead of using WireRecords. If
WireEmitter would have contained such emit(...) method, introducing new data
model in Kura Wires would have introduced new overloaded emit(...) method in
WireEmitter. This might have caused problem for all the previous implemen-
tations of WireEmitter as they depend on the previous version of WireEmitter.
This eventually violates Open/Closed principle [Kno12].

52
 5.6. EXTERNAL CONFIGURATION

To achieve an extensible design, we applied visitor pattern, that allows devel-

opers to define new operations without changing the classes of the elements on
which it operates [Sar16]. Figure 5.12 provides an overview of visitor pattern.

Figure 5.12: Visitor Pattern (UML Class Diagram)

The participants classes in visitor pattern are:

• Visitor: An interface to declare visit operations for different types of visitable

classes

• Visitable: The class to be visited by visitors

Visitor pattern is useful when similar operations have to be performed on ob-

jects of different types [Sar16].
In Figure 5.9, we have separated emit(...) method in WireSupport. This is be-
cause WireSupport acts as a visitor and the data models that WireSupport emits
are visitable classes. Extenders can now easily introduce a new data model in
Kura Wires by adding a new overloaded emit(...) method in WireSupport.

5.6 External Configuration

In Kura Wires, the components are configured using OSGi Metatype specifi-
cation [All07]. This specification allows a module to be configured in runtime
across environmental context [Kno12].

53
 5.6. EXTERNAL CONFIGURATION

The Drivers and Wire Components of Kura Wires are configured in runtime
using OSGi Metatype specification. The configuration properties for each Wire
Component and Driver are described in metadata that complies with the OSGi
Metatype specification. Listing 5.1 shows a metatype configuration file of a
Heater Wire Component.

Listing 5.1: Heater Wire Component containing metatype configuration file

1 <MetaData xmlns="http://www.osgi.org/xmlns/metatype/v1.2.0"
localization="en_us">
2 <OCD id="org.eclipse.kura.heater.wire.component" name="Heater"
3 description="Heater Wire Component Configuration">
4 <AD id="type"
5 name="type"
6 type="String"
7 required="true"
8 default="Celsius"
9 description="Temperature Type">
10 <Option label="C" value="Celsius"/>
11 <Option label="F" value="Fahrenheit"/>
12 </AD>
13 <AD id="temperature.setpoint"
14 name="temperature.setpoint"
15 type="double"
16 required="true"
17 default="20"
18 description="Temperature Setpoint"
19 min="1"/>
20 </OCD>
21 </MetaData>

For a better comprehension, these metatype tags are also described:

• OCD: Object Class Definition (OCD) element contains a set of configuration

properties with an identifier and, optionally, a name and a description

• AD: Attribute Definition (AD) denotes elements for each configuration prop-
erty. Each attribute needs an identifier and optionally a name and a de-
scription. Specifying a type allows the runtime environment to validate
the input for that type. Specifying a useful default value allows configu-
ration to be set to the default value if any previous configuration is not
found.

Eclipse Kura provides an implementation of OSGi Metatype specification and

such aforementioned XML schema is therefore used to describe the properties
to editors and validators in the framework. Eclipse Kura web interface can
provide a nice form-based user interface for configuring OSGi services only if
we provide sufficient metadata for service properties. Using this metadata,
Eclipse Kura web interface knows how to display, for example, a label for each
property, display a text box for simple string data, display a combo box for
choosing a value from a list and validating input data based on the type it
expects. This metadata is defined using the OSGi Metatype specification.
Additionally, this is also integrated with the inbuilt mechanism of Eclipse Kura
to persist configurations in snapshot files - that we have previously discussed
in Chapter 4 (System Design).

54
 5.7. REMOTE COMMUNICATION

5.7 Remote Communication

The default communication protocol in Eclipse Kura is MQTT. Hence, com-
munications with the Cloud Platform in Eclipse Kura make use of the built-in
services to connect using MQTT protocol.
In Kura Wires, we also use this built-in support to establish communication with
the Cloud Platform. Such remote communication is required in the following
cases:

• Publishing data to Cloud Platform using Cloud Publisher

• Subscribing to Cloud Platform using Cloud Subscriber

• Performing remote request to query the status of Industrial Device

It is imperative to know how MQTT topic namespace works in Eclipse Kura.

Eclipse Kura publishes and receives MQTT messages using a topic namespace
following a structure as:

Listing 5.2: Topic Namespace in Eclipse Kura

1 CTRL−PREFIX/account−name/gateway−id/app−id/app−topic

These namespaces are discussed below:

CTRL-PREFIX: an optional prefix to denote topic for reserved entities, such

as a group of companies, an agency, and so on

account-name: a unique identifier that represents a group of gateways

gateway-id: a unique identifier within an account that identifies a single gate-

way device

app-id: an identifier to denote an application running on the gateway de-

vice. For example, in Kura Wires, the remote requests to query Industrial
Device status is managed by an application with an appId of ASSET-
CLOUDLET

app-topic: custom application specific topic to identify resource(s) (sensors,

actuators, local files etc.) that is owned and managed by a particular
application

Every application (for instance, Kura-compliant App) must comply with these
topic namespace scheme to communicate with Cloud Platform. Figure 5.13
shows the various topic namespaces to perform remote requests in Kura Wires.
In this figure, let us consider, we have a gateway with identifier set to MyGate-
way. Now, to access any Industrial Device from remote location, users can use
the endpoints- GET/assets, GET/assets/assetID, and so on.

55
 5.7. REMOTE COMMUNICATION

Figure 5.13: Remote Requests in Kura Wires

The MQTT topics that Kura Wires understands and processes are,

• wires/MyGateway/ASSET-CLOUDLET/GET/assets: It lists all the Assets

configured in the Wire Graph

• wires/MyGateway/ASSET-CLOUDLET/GET/assets/MyAsset: It lists all

the associated channels of an Asset with an identifier set to MyAsset

• wires/MyGateway/ASSET-CLOUDLET/GET/assets/MyAsset/10: It reads
MyAsset associated Channel with a unique identifier of 10

The abovementioned MQTT topics and the namespaces are mapped as follows:

• CTRL-PREFIX: null

• account-name: wires

• gateway-id: MyGateway

• app-id: ASSET-CLOUDLET

• app-topic: GET/assets, GET/assets/MyAsset and GET/assets/MyAs-

set/10

Eclipse Kura has extended the flexible concept of MQTT topics to follow this
schematic pattern. Based on this MQTT namespace, an application running on
Eclipse Kura can be viewed in terms of its resources that it owns and manages.
Kura Wires being an application on top of Eclipse Kura leverages this feature
to realize remote MQTT communication.

56
Chapter 6
Summary

This chapter summarizes the thesis, discusses its findings and contributions,
points out limitations of the current work and also outlines directions for future
research. We have demonstrated dataflow programming approach to be a means
of implementing Industrial IoT scenarios to process data from field devices.
However, many extensions of this research deserve further consideration.

6.1 Contributions
In this thesis work, we developed a framework that enables users to build their
own Industrial IoT applications to process data from industrial machineries.
Basic functionalities to build such framework are, for instance, I/O services,
cloud communication, network management, and so on. To prevent rewrit-
ing these functionalities from scratch, we selected Eclipse Kura Open Source
framework as the foundation for Kura Wires.
Kura Wires incorporates a dataflow programming model that raises the ab-
straction level of the underlying IoT systems to ease the development task.
In this dataflow programming model, the underlying hardware, protocols and
functionalities of IoT systems are abstracted as nodes in a flow. If developers
require more flexibility or functionalities than what the current nodes offer, new
custom nodes can be developed in Kura Wires.
As an initial contribution, we created a composer canvas that allows users to
build their Industrial IoT applications visually. In addition, we have provided
preliminary device and data management nodes or more specifically Wire Com-
ponents. The detailed information of the Wire Components is given in Chapter
3 (Requirements Analysis).
The realized goals are summarized as follows:

• Users can make use of Kura Wires to build Industrial IoT applications
visually to process machine production data

• Users can accumulate data from Modbus, S7 and OPC-UA devices

• Users can publish machine production data to Cloud Platform for further
historical and predictive analysis

57
 6.2. FUTURE WORK

• Users can filter machine production data before publishing to Cloud Plat-
form

• Users can perform inter-gateway communication between remote Indus-

trial IoT applications deployed in different service gateways

• The system is extensible: IoT application developers can develop custom

Wire Components and Drivers

• The system is usable: Users do not require additional training to build

their own Industrial IoT applications in Kura Wires

The open goal:

• Drag and Drop support of Wire Components onto Composer UI is not

realized. This requires further development of an extension to JointJS
library that we have selected for the canvas development in Kura Wires.
As this is beyond the scope of this thesis work, therefore it is not realized.

6.2 Future Work

While this thesis has introduced a framework to develop Industrial IoT appli-
cations by visually connecting components, many opportunities for extending
the scope of this thesis remain. This section presents some of these directions.

• Visual SQL Query Builder: Configuring DB Filter in Wire Graph re-

quires users to provide SQL queries. This constrains people without any prior
SQL experience. A possible future work would be to introduce a visual query
builder user interface to create such SQL queries for DB Filter.

• Computational Wire Component: Currently Kura Wires provides few

device and data management components. However, performing basic math-
ematical operations on the data are still not possible. Such Computational
Wire Component will allow users to perform further customized operations on
machine production data.

• Programmable Wire Component: Kura Wires facilitates the visual de-

velopment of Industrial IoT applications. The main objective of Kura Wires is
to provide users the opportunity to build their own Industrial IoT applications
without any programming experience. However, a specialized programmable
Wire Component will allow JVM-based language (Scala, Groovy) code to be
run against the data that are passed in.

• Context Information in Industrial Device Data: The data that gets

accumulated from field devices does not incorporate any context information
such as device type, location and specific situation in which the data is collected.
We believe that provisioning the device data with such context information
would be beneficial in many Industrial IoT scenarios.

58
 6.2. FUTURE WORK

There exists a number of approaches to provide context information [PZC+ 13]

[SLP04]. A future work could be to select a suitable context modeling language
that fits the common requirements of Industrial IoT solutions. In addition,
other Wire Components can make use of such information to perform different
operations. For example, let us consider a temperature sensor physical device.
With Kura Wires, retrieving temperature data from this sensor can be achieved
through the use of an Asset with an I2 C Driver. If the data associates context
information, then a special purpose temperature converter Wire Component can
convert the retrieved temperature in degree centigrade to Fahrenheit and vice
versa.

• Integration with Eclipse Kapua: Eclipse Kapua14 is an Eclipse IoT

project which aims to provide an integration platform for IoT gateways. It
focuses on archiving aggregated real-time data for historical and predictive
analysis. It can also route the data streams to enterprise IT systems. Fig-
ure 6.1 illustrates an Industrial IoT ecosystem and the relevant Open Source
frameworks for respective layers.

Figure 6.1: Industrial IoT Ecosystem with Eclipse Kura and Eclipse Kapua

Eclipse Kapua-equipped Cloud Platform manages the connectivity for IoT gate-
ways through a different set of protocols. The platform also offers device man-
agement capabilities to introspect gateway configuration, update gateway ap-
plications and firmware, and control the gateway remotely.
To enable the development of Wire Graphs in Eclipse Kapua requires the inte-
gration of Kura Wires. This benefits users to directly deploy Wire Graphs into
the managed service gateways from remote location.

14
https://eclipse.org/kapua/

59
Appendix A
Screenshots

• Kura Wires Composer UI: Kura Wires Composer UI is accessible from

Eclipse Kura web interface. Composer UI contains the user interface elements
to visually build an Industrial IoT application. Figure A.1 shows this Composer
UI in Eclipse Kura.

Figure A.1: Kura Wires Composer UI

60
• Create Driver: Figure A.2 shows the user interface to instantiate a Driver.

Figure A.2: Create Driver

• Configure Modbus Driver: The user interface to configure a Modbus

Driver is shown in Figure A.3.

Figure A.3: Configure Mosbus Driver

61
• Create Asset: Figure A.4 shows the user interface to create an Asset.

Figure A.4: Create Asset

• Process Data from Modbus and OPC-UA Devices: Figure A.5 presents
a Wire Graph that reads data from specific Channels from Modbus and OPC-
UA PLCs. This data is accumulated and published to the Cloud Platform for
further analysis.

Figure A.5: Process data from Modbus and OPC-UA PLCs

62
• Configure Wire Components: In Figure A.6 to A.10, user interfaces to
configure different Wire Components are shown.

Figure A.6: Configure Timer

Figure A.7: Configure Modbus Asset

63
Figure A.8: Configure OPC-UA Asset

Figure A.9: Configure Cloud Publisher

64
Figure A.10: Configure DB Filter

65
Appendix B
EclipseCON Germany 2016

Figure B.1: Talk on Kura Wires in EclipseCON Germany 2016

On October 25, 2016, we presented Kura Wires in EclipseCON Europe 2016

which was held in Ludwigsburg, Germany. The topic of the talk was “Kura
Wires: Industry 4.0 with Eclipse Kura” 15 . During the talk, we also demon-
strated previously defined scenarios - CollectAndFilterModbusDeviceData and
QueryModbusDeviceConnectedLedStatus. For this purpose, we used the fol-
lowing accessories:

ReliaGATE 20-25 Gateway: An industrial gateway equipped with Eclipse

Kura

EDC Devkit: Device working on Modbus protocol

Custom Dashboard Application: A Kura-compliant App to send remote re-

quests to the gateway

In general, Kura Wires received a very positive feedback from the audience
and representatives of companies such as Bosch Software Innovations, Deutsche
Bahn, Porsche AG. They also expressed their willingness to collaborate in in-
tegration and further development of the framework. Due to the recent intro-
duction of Eclipse Kapua project, the integration of Eclipse Kapua with Kura
Wires was a topic of discussion. To give an overview, a possible integration
15
https://www.eclipsecon.org/europe2016/session/industry-40-eclipse-kura

66
with Eclipse Kapua platform would allow Industrial Engineer to create Wire
Graphs from remote location and deploy it remotely to the edge IoT gateways.
This integration is thoroughly discussed in Section 6.2 (Future Work).

67
List of Figures

2.1 OSGi Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Functional Architecture of Eclipse Kura . . . . . . . . . . . . . . 5
2.3 Integrated web interface of Eclipse Kura . . . . . . . . . . . . . 6
2.4 Node-RED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1 Functional Architecture of Eclipse Kura with Kura Wires . . . . 10

3.2 Collect and filter data from Modbus Device . . . . . . . . . . . 13
3.3 Wire Graph to collect and filter data from Modbus Device . . . 13
3.4 Collect data from Modbus Device and write to S7 Device . . . . 14
3.5 Wire Graph to write Modbus Device data to Channels of an S7
Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6 Query Modbus Device status from remote location . . . . . . . . 16
3.7 Wire Graph to query the status of connected Modbus Device . . 16
3.8 Change OPC-UA Device data from remote location . . . . . . . 17
3.9 Wire Graph to write to specific Channels of a remote OPC-UA
Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.10 Create Industrial IoT Application (UML Use Case Diagram) . . 19
3.11 Configure Wire Component (UML Use Case Diagram) . . . . . . 20
3.12 Configure Asset (UML Use Case Diagram) . . . . . . . . . . . . 21
3.13 Perform Remote Request (UML Use Case Diagram) . . . . . . . 22
3.14 Filter, Store, Publish and Receive data (UML Use Case Diagram) 23
3.15 Wire Graph and Wire Component (UML Class Diagram) . . . . 26
3.16 Asset and Driver (UML Class Diagram) . . . . . . . . . . . . . . 27
3.17 Specialized Wire Components (UML Class Diagram) . . . . . . . 28
3.18 Boundary Objects of Kura Wires and their associations . . . . . 29
3.19 CreateWireGraphControl and its associations to create a Wire
Graph (UML Class Diagram) . . . . . . . . . . . . . . . . . . . 31
3.20 RemoteRequestControl and its association to perform remote re-
quest (UML Class Diagram) . . . . . . . . . . . . . . . . . . . . 31
3.21 ConfigurationControl and its associations to configure different
Wire Components and Drivers (UML Class Diagram) . . . . . . 32
3.22 Activities of an Industrial Engineer to create a Wire Graph for
collecting and filtering Modbus Device data (UML Activity Di-
agram) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.23 Activities and events in a dataflow of a Wire Graph to accumulate
and filter Modbus Device data (UML Activity Diagram) . . . . 33

68
 LIST OF FIGURES

3.24 Interactions of an Industrial Engineer with a Wire Graph to read

the status of Modbus Device-connected LED from remote loca-
tion (UML Activity Diagram) . . . . . . . . . . . . . . . . . . . 34
3.25 Interactions of an Industrial Engineer with two different Wire
Graphs for inter-gateway communication (UML Activity Diagram) 35

4.1 Kura Wires Subsystem Decomposition . . . . . . . . . . . . . . 38

4.2 Kura Wires Hardware Software Mapping (UML Deployment Di-
agram) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3 Kura Wires boundary use cases to handle exceptional conditions
(UML Use Case Diagram) . . . . . . . . . . . . . . . . . . . . . 44
4.4 Kura Wires boundary use cases to handle startup and shutdown
conditions (UML Use Case Diagram) . . . . . . . . . . . . . . . 45

5.1 Data types for communication between Wire Components (UML

Class Diagram) . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.2 Data in dataflow of Wire Graph (UML Class Diagram) . . . . . 47
5.3 OSGi Wire Admin specification (UML Class Diagram) . . . . . 47
5.4 WireComponentManagement subsystem (UML Class Diagram) . 48
5.5 AssetManagement subsystem (UML Class Diagram) . . . . . . . 48
5.6 DriverManagement subsystem (UML Class Diagram) . . . . . . 49
5.7 Associate Driver with Asset (Dependency Injection) . . . . . . . 49
5.8 Whiteboard Pattern . . . . . . . . . . . . . . . . . . . . . . . . 50
5.9 WireManagement subsystem to emit/receive data (UML Class
Diagram) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.10 WireManagement subsystem to manage Wire Configurations (UML
Class Diagram) . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.11 Dataflow Communication between Wire Emitter and Wire Re-
ceiver (UML Sequence Diagram) . . . . . . . . . . . . . . . . . . 52
5.12 Visitor Pattern (UML Class Diagram) . . . . . . . . . . . . . . 53
5.13 Remote Requests in Kura Wires . . . . . . . . . . . . . . . . . . 56

6.1 Industrial IoT Ecosystem with Eclipse Kura and Eclipse Kapua 59

A.1 Kura Wires Composer UI . . . . . . . . . . . . . . . . . . . . . . 60

A.2 Create Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
A.3 Configure Mosbus Driver . . . . . . . . . . . . . . . . . . . . . . 61
A.4 Create Asset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
A.5 Process data from Modbus and OPC-UA PLCs . . . . . . . . . . 62
A.6 Configure Timer . . . . . . . . . . . . . . . . . . . . . . . . . . 63
A.7 Configure Modbus Asset . . . . . . . . . . . . . . . . . . . . . . 63
A.8 Configure OPC-UA Asset . . . . . . . . . . . . . . . . . . . . . . 64
A.9 Configure Cloud Publisher . . . . . . . . . . . . . . . . . . . . . 64
A.10 Configure DB Filter . . . . . . . . . . . . . . . . . . . . . . . . . 65

B.1 Talk on Kura Wires in EclipseCON Germany 2016 . . . . . . . . 66

69
Bibliography

[AH14] Mohammad Aazam and Eui-Nam Huh. Fog Computing and Smart
Gateway Based Communication for Cloud of Things. In Future Inter-
net of Things and Cloud (FiCloud), 2014 International Conference on.
IEEE, 2014.

[AHH14] Mohammad Aazam, Pham Phuoc Hung, and Eui-Nam Huh. Smart
Gateway Based Communication for Cloud of Things. In Intelligent
Sensors, Sensor Networks and Information Processing (ISSNIP), 2014
IEEE Ninth International Conference on. IEEE, 2014.

[All07] OSGi Alliance. OSGi Service Platform Service Compendium (Release

4, Version 4.1). Createspace, 2007

[AN10] Sarfraz Alam and Josef Noll. Enabling Sensor as Virtual Services
through Lightweight Sensor Description. In Sensor Technologies and
Applications (SENSORCOMM), 2010 Fourth International Conference
on. IEEE, 2010.

[BD10] Bernd Bruegge and Allen H. Dutoit. Object-Oriented Software En-

gineering Using UML, Patterns, and Java. Prentice Hall Press, 3rd
Edition, 2010.

[BL14] Michael Blackstock and Rodger Lea. Toward a Distributed Data Flow
Platform for the Web of Things (Distributed Node-RED). In Proceed-
ings of the 5th International Workshop on Web of Things. ACM, 2014.

[BP10] Sjaak Brinkkemper and Stella Pachidi. Functional Architecture Mod-

eling for the Software Product Industry. In Proceedings of the 4th Eu-
ropean conference on Software architecture, ECSA’10, Springer, 2010.

[DFK+ 02] Pavlin Dobrev, David Famolari, Christian G. Kurzke, and Brent A.
Miller. Device and service discovery in home networks with OSGi. In
IEEE Communications Magazine, IEEE, 2002.

[DXH+ 14] Li Da Xu, Wu He, and Shancang Li. Internet of Things in Industries:
A Survey. In IEEE Transactions on Industrial Informatics, IEEE, 2014.

[GBL+ 15] Nam Ky Giang, Michael Blackstock, Rodger Lea, and Victor C.M.
Leung. Developing IoT applications in the Fog: A Distributed Dataflow
approach. In Internet of Things (IOT), 2015 5th International Confer-
ence on the. IEEE, 2015.

70
 BIBLIOGRAPHY

[GD11] Kiev Gama and Didier Donsez. Applying dependability aspects on top
of “aspectized” software layers. In Proceedings of the tenth international
conference on Aspect-oriented software development, AOSD’11, ACM,
2011.

[Gil16] Alasdair Gilchrist. Industry 4.0 The Industrial Internet of Things.

Apress, 2016.

[Gui09] Dominique Guinard. Towards the web of things: Web mashups for
embedded devices. In MEM 2009 in Proceedings of WWW 2009. ACM,
2009.

[Hel10] Sumi Helal. The Landscape of Pervasive Computing Standards. Morgan

and Claypool Publishers, 2010.

[KH04] Peter Kriens and B Hargrave. Listener Pattern Considered Harmful:

The “Whiteboard” Pattern. Technical whitepaper, OSGi Alliance, 2004.

[Kno12] Kirk Knoernschild. Java Application Architecture: Modularity Pat-

terns with Examples Using OSGi. Prentice Hall Press, 2012.

[LKR+ 06] Seungkeun Lee, Intae Kim, Kiwook Rim, and Jeonghyun Lee. Ser-
vice Mobility Manager for OSGi Framework In International Confer-
ence on Computational Science and Its Applications. Springer, 2006.

[LKY14] Jay Lee, Hung-An Kao, and Shanhu Yang. Service Innovation and
Smart Analytics for Industry 4.0 and Big Data Environment. Procedia
CIRP, 2014.

[LL06] Seungkeun Lee and Jeonghyun Lee. OSGi based service mobility man-
agement for pervasive computing environments. In Proceedings of the
24th IASTED International Conference on Internet and Multimedia
Systems and Applications, IMSA’06, ACTA Press, 2006.

[LNH03] Choonhwa Lee, David Nordstedt, and Sumi Helal. Enabling Smart
Spaces with OSGi. In IEEE Pervasive Computing, IEEE, 2003.

[PZC+ 13] Charith Perera, Arkady Zaslavsky, Peter Christen, and Dimitrios
Georgakopoulos. Context Aware Computing for The Internet of Things:
A Survey. In IEEE Communications Surveys & Tutorials, IEEE, 2013.

[Sar16] Vaskaran Sarcar. Java Design Patterns. Apress, 2016.

[SLP04] Thomas Strang and Claudia Linnhoff-Popien. A Context Modeling

Survey. In Workshop on Advanced Context Modelling, Reasoning And
Management, UbiComp, 2004.

[UV05] Tarmo Uustalu and Varmo Vene. The Essence of Dataflow Program-
ming. In Central European Functional Programming School. Springer,
2005.

71