Nuwan - FYP

INFORMATICS INSTITUTE OF TECHNOLOGY
In Collaboration with
UNIVERSITY OF WESTMINSTER, UK
Metadata model for supporting hierarchical

Edge Device arrangements in an IoT
deployment
A dissertation by
Nuwan Jayawardene
Supervised by
Pumudu Fernando
Submitted in partial fulfillment of the requirements for the

BSc. (Hons) in Computer Science
Department of Computing
May 2019
© The copyright for this project and all its associated products resides with
Informatics Institute of Technology
Declaration
Declaration
I hereby certify that this project report and all the artifacts associated with it is my own work and it has not
been submitted before nor is currently being submitted for any degree program.
Full Name of Student: Nuwan Stanislaus Gomis Abeysingha Jayawardene
IIT Registration No: 2015235
UoW Registration No: W1608508
Signature: ___________________ Date: ____________________
ii Nuwan Jayawardene | 2015235

Abstract
Abstract
More and more "Smart Devices" are coming online every year. These Smart Devices have the ability to
communicate with other Smart Devices across the web, exchange information and make intelligent
decisions. This influx of new devices and connections has caused the central servers that manage those
Smart Devices to come under heavy load. Measures to combat this have inadvertently resulted in increased
network complexity.
This research considers a use-case where such complexity might arise, especially complexity derived from
networks with hierarchical device arrangements. It then points out why addressing that complexity is
necessary. The research thereafter considers several existing IoT products and how network complexity is
handled in them. Those existing products are studied in-depth after a selection based on pre-defined criteria
and their construction analyzed.
Based on the lessons learnt from those findings an approach is formalized to address how the complexity
can be handled in one component within a device network; the central cloud server. After considering the
all the necessary requirements, an architecture is proposed which is derived from the pre-defined approach.
An implementation is created using this architecture with some added functionality that is provided by it.
Supplementary implementations are also developed to complement this architecture and prove its
versatility.
The research concludes by testing and evaluating various aspects of the architectural implementation and
getting feedback on what can be improved. Finally, conclusions are drawn regarding the success of the
project and future development pathways are defined.
Keywords: Fog Networks, Edge Computing, Edge Gateways, Smart City
iii Nuwan Jayawardene | 2015235

Acknowledgement
Acknowledgement
The journey made prior to arriving at the conclusion of this project was a long and arduous one. One that I
wouldn’t have been able to complete without the involvement of several key individuals.
First and foremost, I’d like to thank my project supervisor Mr. Pumudu Fernando. His guidance and
feedback were instrumental in helping me overcome many obstacles. I would also like to thank Mr. Cassim
Farook for providing valuable advice during various stages of the research.
My gratitude also goes to Mr. Sumedha Rubasinghe, for providing invaluable insight into various aspects
of this domain and motivating me when the challenges seemed insurmountable.
None of this would have been possible if it wasn’t for my parents. Their strength was what kept me going
during the most difficult times. It would be true to say that this is as much their achievement as it is mine.
Last but not least, a special mention of someone who shall not be named.
Not for gratitude, acclaim or approval; but for the acknowledgment of what was shared for the briefest of
periods.
I hope the simple truth of it shall not be lost to time, like tears in the rain.
iv Nuwan Jayawardene | 2015235

Table of Contents
Table of Contents
Declaration ............................................................................................................................................. ii
Abstract ................................................................................................................................................. iii
Acknowledgement ................................................................................................................................. iv
Table of Contents .................................................................................................................................... v
Table of Snippets .................................................................................................................................... x
Table of Figures ...................................................................................................................................... x
List of Tables ......................................................................................................................................... xi
Table of Abbreviations .......................................................................................................................... xii
1 Introduction .................................................................................................................................... 1
1.1 Chapter Overview .................................................................................................................... 1
1.2 Background ............................................................................................................................. 1
1.2.1 Edge Computing and the central Cloud Server ................................................................. 2
1.3 Problem and Motivation .......................................................................................................... 3
1.3.1 Problem ........................................................................................................................... 3
1.3.2 Motivation ....................................................................................................................... 3
1.4 Aim and Objectives ................................................................................................................. 4
1.4.1 Aim ................................................................................................................................. 4
1.4.2 Research Objectives ......................................................................................................... 4
1.5 Features of Prototype ............................................................................................................... 4
1.6 Outline of Thesis ..................................................................................................................... 5
1.7 Resource Requirements ........................................................................................................... 6
1.8 Chapter Summary .................................................................................................................... 7
2 Project Management ........................................................................................................................ 8
2.1 Chapter Overview .................................................................................................................... 8
2.2 Software Development Methodology ....................................................................................... 8
2.2.1 Waterfall Development Model ......................................................................................... 8
2.2.2 Rapid Application Development Model............................................................................ 8
2.2.3 Iterative Model ................................................................................................................ 9
2.2.4 Selection of a methodology .............................................................................................. 9
2.3 Work Breakdown Structure.....................................................................................................11
2.4 Gantt Chart .............................................................................................................................11
2.5 Project Risks...........................................................................................................................11
v Nuwan Jayawardene | 2015235

Table of Contents
2.6 Chapter Summary ...................................................................................................................11

3 Literature Review ...........................................................................................................................12
3.1 Chapter Overview ...................................................................................................................12
3.2 High-level IoT architecture .....................................................................................................12
3.2.1 Conceptualizing a High-level architecture .......................................................................13
3.2.2 Layers in a High-level architecture ..................................................................................14
3.3 IoT architectural stacks ...........................................................................................................17
3.3.1 Stack for Edge Devices ...................................................................................................18
3.3.2 Stack for Edge Gateways ................................................................................................19
3.3.3 Stack for Central Cloud ...................................................................................................21
3.4 Reference Architectures ..........................................................................................................24
3.4.1 Microsoft Azure IoT .......................................................................................................25
3.4.2 Mozilla Web Things........................................................................................................28
3.4.3 Eclipse Kapua .................................................................................................................32
3.4.4 Entgra IoT Server............................................................................................................34
3.4.5 Reference Architecture review ........................................................................................37
3.5 Chapter Summary ...................................................................................................................38
4 System Requirement Specification .................................................................................................39
4.2 Stakeholders ...........................................................................................................................39
4.2.1 “Onion Model” Diagram .................................................................................................39
4.2.2 Stakeholder Description ..................................................................................................39
4.3 Requirement Gathering ...........................................................................................................40
4.3.1 Review and Selection of requirement gathering techniques ..............................................40
4.3.2 Execution of requirement gathering techniques ...............................................................42
4.3.3 Conclusion drawn from gathered requirements ................................................................42
4.4 Use Case Diagram ..................................................................................................................43
4.5 Use Case Description ..............................................................................................................43
4.6 Requirements..........................................................................................................................44
4.6.1 Functional Requirements .................................................................................................44
4.6.2 Non-Functional Requirements .........................................................................................45
4.7 Chapter Summary ...................................................................................................................46
5 Design............................................................................................................................................47
5.2 Design Goals ..........................................................................................................................47
vi Nuwan Jayawardene | 2015235

Table of Contents
5.3 Design Methodology ..............................................................................................................47

5.3.1 Object Oriented Analysis and Design (OOD) ..................................................................47
5.3.2 Structured System Analysis and Design (SSAD) .............................................................48
5.3.3 Selection of a design methodology ..................................................................................48
5.4 Approach ................................................................................................................................48
5.4.1 Top – Down Approach ....................................................................................................48
5.4.2 Bottom – Up Approach ...................................................................................................49
5.4.3 Proposal: Hybrid Approach .............................................................................................50
5.5 Architecture ............................................................................................................................51
5.5.1 High - Level Architecture................................................................................................51
5.5.2 Rich Picture ....................................................................................................................51
5.6 Class Diagram ........................................................................................................................52
5.7 Sequence Diagrams ................................................................................................................52
5.8 UI mockups ............................................................................................................................54
5.9 Chapter Summary ...................................................................................................................54
6 Implementation ..............................................................................................................................55
6.2 Derived Architecture ..............................................................................................................55
6.3 Selection of Technology .........................................................................................................56
6.3.1 Preliminary decisions ......................................................................................................56
6.3.2 Review of suitable IoT products ......................................................................................56
6.3.3 Selection and Justification ...............................................................................................58
6.4 Implementation Overview.......................................................................................................58
6.4.1 Product Overview ...........................................................................................................58
6.4.2 Application Stack............................................................................................................59
6.5 Features and Core functionality...............................................................................................60
6.5.1 Server-based implementation ..........................................................................................60
6.5.2 Edge Device implementation ...........................................................................................68
6.6 Chapter Summary ...................................................................................................................71
7 Testing ...........................................................................................................................................73
7.2 Goals of Testing .....................................................................................................................73
7.3 Testing Methodology ..............................................................................................................73
7.4 Execution Environment ..........................................................................................................74
7.5 Test Execution and Results .....................................................................................................74
vii Nuwan Jayawardene | 2015235

Table of Contents
7.5.1 TM1: Unit Testing ..........................................................................................................74

7.5.2 TM2: Integration Testing ................................................................................................75
7.5.3 TM3: Functional Testing .................................................................................................75
7.5.4 TM4: System Testing ......................................................................................................76
7.5.5 TM5: Quality Testing ......................................................................................................77
7.6 Chapter Summary ...................................................................................................................85
8 Evaluation ......................................................................................................................................86
8.2 Evaluation Criteria ..................................................................................................................86
8.3 Prototype Development Evaluation (Qualitative) ....................................................................86
8.3.1 Selection of Evaluators ...................................................................................................86
8.3.2 Summary of questions for Evaluators ..............................................................................87
8.3.3 Summary of Responses ...................................................................................................87
8.3.4 Additional Responses ......................................................................................................89
8.4 Prototype Development Evaluation (Quantitative)...................................................................90
8.4.1 Evaluation of Test results ................................................................................................90
8.5 Project Evaluation ..................................................................................................................95
8.5.1 Schedule .........................................................................................................................95
8.5.2 Project Management Methodology ..................................................................................95
8.5.3 Objectives .......................................................................................................................95
8.6 Critical Evaluation ..................................................................................................................95
8.6.1 Features and Functionality ..............................................................................................95
8.6.2 Functional Requirements .................................................................................................96
8.6.3 Non-Functional Requirements .........................................................................................97
8.7 SLEP Aspect Evaluation .........................................................................................................97
8.8 Chapter Summary ...................................................................................................................98
9 Conclusion .....................................................................................................................................99
9.2 In Retrospect ..........................................................................................................................99
9.2.1 Strengths of the Solution ............................................................................................... 100
9.2.2 Weaknesses of the Solution ........................................................................................... 100
9.3 Challenges Overcome ........................................................................................................... 101
9.3.1 Time Management ........................................................................................................ 101
9.3.2 Learning new technologies ............................................................................................ 101
9.4 Achievements ....................................................................................................................... 101
viii Nuwan Jayawardene | 2015235

Table of Contents
9.4.1 Project Aim Achievements ............................................................................................ 101

9.4.2 Research Objective Achievements................................................................................. 102
9.4.3 Project related Achievements ........................................................................................ 102
9.4.4 Research related Achievements ..................................................................................... 103
9.4.5 Achievements relative to module Learning Outcomes ................................................... 103
9.5 Research Contribution .......................................................................................................... 103
9.6 Future Enhancements ............................................................................................................ 104
9.7 Chapter Summary and Concluding Remarks ......................................................................... 105
A. Appendix – Submitted Review paper ................................................................................................ a
B. Appendix – Submitted Concept Paper ............................................................................................. g
C. Appendix – Gantt Chart................................................................................................................... k
D. Appendix – Work Breakdown Chart ................................................................................................. l
E. Appendix – Paper Acceptance notification ..................................................................................... m
F. Appendix – Use Case Diagram ........................................................................................................ n
G. Appendix – Interview Questions ...................................................................................................... o
H. Appendix – High-Level overview of Hybrid Approach .................................................................... q
I. Appendix – Class Diagram ............................................................................................................... r
J. Appendix – Mock network diagram showcasing parent-child architecture......................................... s
K. Appendix – Approach comparison for implementation ..................................................................... t
L. Appendix – Onion Diagram............................................................................................................. u
M. Appendix – Layers of a Fog enabled IoT Network ....................................................................... v
N. Appendix – Server deployment code in Mozilla Web of Things Gateway ........................................ w
O. Appendix – Reference architecture feature comparison .................................................................... x
P. Appendix – UI mockup of hierarchical visualization ......................................................................... z
Q. Appendix – Metadata acquisition and storage flow ......................................................................... aa
R. Appendix – Software stack vs Architecture layers arrangement ......................................................bb
S. Appendix – DAO layer methods to extract enrollment metadata from persistent storage ................. cc
T. Appendix – API layer code to generate payload required for UI ......................................................dd
U. Appendix – Payload generated for the use of hierarchical visualization library................................ ee
V. Appendix – Front-end code markup ................................................................................................. ff
W. Appendix – Client-side JavaScript code used for UI generation ..................................................gg
X. Appendix – List of module learning outcomes and usages ..............................................................hh
Y. Appendix – Screenshot of Edge Device agent on webOS ................................................................. ii
Z. Appendix – List of selected external Evaluators ............................................................................... jj
AA. Appendix – Questions for selected Evaluators ............................................................................kk
ix Nuwan Jayawardene | 2015235

Table of Snippets
BB. Appendix – System Testing results .............................................................................................. ll

CC. Appendix – OSGi method to retrieve all stored EnrollmentInfo metadata of devices ................ mm
DD. Appendix – OSGi method to return list of upstream parents a child device is connected to ..........nn
EE. Appendix – JavaScript function to retrieve client-secret and client-id ..........................................oo
FF. Appendix – JavaScript function to retrieve refresh token.............................................................pp
GG. Appendix – Detailed Functional test cases ..................................................................................qq
HH. Appendix – Project Risks ........................................................................................................... ss
Bibliography ........................................................................................................................................... tt
Table of Snippets
Snippet 6.1 - Enrollment Response is defined in the interface .................................................................62
Snippet 6.2 - Bean class including EnrollmentInfo metadata and Hierarchical metadata..........................63
Snippet 6.3 - DAO enrollment method declaration from interface...........................................................63
Snippet 6.4 - DAO enrollment method implementation ..........................................................................64
Snippet 6.5 - H2 SQL script used to create DB table for EnrollmentInfo ................................................65
Snippet 6.6 - JavaScript function used to gather user credentials .............................................................70
Snippet 6.7 - JavaScript function used to pass enrollment payload to server ............................................71
Table of Figures
Figure 1.1 - Basic Rich picture of implementation ................................................................................... 5

Figure 3.1 - Traditional IoT architecture .................................................................................................12
Figure 3.2 - IoT architecture for Fog enabled network ............................................................................13
Figure 3.3 - Perception Layer .................................................................................................................14
Figure 3.4 - Network Layer ....................................................................................................................15
Figure 3.5 - Middleware Layer ...............................................................................................................16
Figure 3.6 - Application Layer ...............................................................................................................16
Figure 3.7 - Software stack for Edge Devices (Eclipse Foundation, 2017) ..............................................18
Figure 3.8 - Software stack for Edge Gateways (Eclipse Foundation, 2017) ............................................20
Figure 3.9 - Software stack for Central Cloud (Eclipse Foundation, 2017) ..............................................22
Figure 3.10 - How IoT architectural tiers are arranged in Azure IoT (Microsoft Corporation, 2018) ........26
Figure 3.11 - High level overview of components in Entgra IoT Server ..................................................35
Figure 5.1 - Architecture diagram and data flow of central cloud server ..................................................52
x Nuwan Jayawardene | 2015235

Table of Snippets
Figure 5.2 - Sequence Diagram: Enroll Device .......................................................................................53

Figure 5.3 - Sequence Diagram: Hierarchical data visualization..............................................................53
Figure 6.1 - Software Stack of Entgra IoT server ....................................................................................59
Figure 6.2 - The file structure of a front-end page ...................................................................................67
Figure 6.3 - Final output of the visualization with device details .............................................................68
Figure 7.1 - Performance chart of default product on localhost ...............................................................79
Figure 7.2 - Performance chart of product with proposed architecture on localhost .................................79
Figure 7.3 - Performance chart of default product on remote server ........................................................80
Figure 7.4 - Performance chart of product with proposed architecture on remote server ..........................81
Figure 7.5 - Performance chart for running operations on 5000 devices ..................................................83
Figure 7.6 - Performance chart for running operations on 15000 devices ................................................83
Figure 8.1 - Average response times chart for phase 1 performance tests on localhost .............................91
Figure 8.2 - Average response times chart for phase 1 performance tests on remote server......................92
Figure 8.3 - Average TPS chart for phase 2 performance tests on remote server......................................93
Figure 8.4 - Average response time chart for reliability tests with increasing users .................................94
List of Tables
Table 1.1 - Outline of the Thesis document structure ............................................................................... 6

Table 1.2 - Resource requirement list ...................................................................................................... 7
Table 2.1 - Comparison of Development Methodologies ........................................................................10
Table 3.1 - Factor distribution for selected implementations ...................................................................25
Table 4.1 - Stakeholder Description .......................................................................................................40
Table 4.2 - Description for Enroll Device use case .................................................................................44
Table 4.3 - Description for Display Hierarchical visualization use case..................................................44
Table 4.4 - List of Functional Requirements ...........................................................................................45
Table 6.1 - Merit based IoT Product comparison ....................................................................................57
Table 6.2 - Functionality provided by hierarchy with associated REST endpoint ....................................61
Table 6.3 - Visualization front-end library comparison ...........................................................................67
Table 6.4 - Comparison of features provided by Edge Device platforms .................................................69
Table 7.1 - Selected Testing Methodologies ...........................................................................................74
Table 7.2 - Spec listing of localhost and remote environments ................................................................74
Table 7.3 - Functional Testing results .....................................................................................................76
Table 7.4 - Performance metrics of default product on localhost .............................................................78
xi Nuwan Jayawardene | 2015235

Table of Snippets
Table 7.5 - Performance metrics of product with proposed Architecture on localhost ..............................78
Table 7.6 - Performance metrics of default product on remote server ......................................................80
Table 7.7 - Performance metrics of product with proposed Architecture on remote server .......................80
Table 7.8 - Performance metrics for running operations on 5000 devices ................................................82
Table 7.9 - Performance metrics for running operations on 15000 devices ..............................................82
Table 7.10 - Performance metrics for testing 10 concurrent users ...........................................................84
Table 8.1 - Average response times for phase 1 performance tests on localhost.......................................91
Table 8.2 - Average response times for phase 1 performance tests on remote server ...............................92
Table 8.3 - Average TPS for phase 2 performance tests on remote server ...............................................93
Table 8.4 - Average response time (ms) for reliability tests performed in remote server .........................94
Table of Abbreviations
CPU..................................................................................................................... Central Processing Unit

CSA.................................................................................................................. Client-Server Architecture
ECU ..................................................................................................................... Electronic Control Unit
EMM ..............................................................................................................Enterprise Mobile Manager
GPIO .......................................................................................................... General Purpose Input Output
GUI ....................................................................................................................Graphical User Interface
HAL ............................................................................................................. Hardware Abstraction Layer
I/O ......................................................................................................................................... Input/Output
IoT................................................................................................................................. Internet of Things
MCU ...................................................................................................................... Micro Controller Unit
MVC ................................................................................................................ Model - View - Controller
MVP ...................................................................................................................Minimum Viable Product
OS ................................................................................................................................. Operating System
POC................................................................................................................................ Proof of Concept
RAD ........................................................................................................ Rapid Application Development
RAM ................................................................................................................... Random Access Memory
REST ....................................................................................................... REpresentational State Transfer
SLEP .................................................................................................... Social Legal Ethical Proffessional
SOA .......................................................................................................... Service Oriented Architectures
xii Nuwan Jayawardene | 2015235

Introduction
1 Introduction
1.1 Chapter Overview

The introductory chapter to the thesis will focus on establishing the required domain related information
prior to engaging any in-depth research. This chapter will provide a clear introduction to the overall project,
the background, the need for a solution and the requirements needed to achieve the solution. The chapter
will also focus on clarifying what is within the scope this project.
1.2 Background
More and more "Smart devices" are coming online every year. These Smart Devices have the ability to
communicate with other Smart Devices across the web, exchange information and make intelligent
decisions. More connected Smart devices mean larger streams of incoming data. This influx of new
connections has caused the services that manage those Smart devices to come under heavy load. To combat
this, measures have been taken to process the data as close to its origin as possible. Some of those measures
involve addition of certain "supervisor" devices to the network, in turn causing the networks to increase in
complexity. While advancements are being made in that front, the central servers (the cloud) managing the
entire fleet of devices has not been adequately updated to reflect those advancements. This document
describes the authors' proposal for an Architecture that would enable the cloud to understand complex
networks of devices connected to it.
Before the advent of the Technological Revolution, household items simply performed the tasks they were
built for. They were known as "dumb" things. Then a concept known as the "Internet of Things" (IoT) came
along which made it possible for any end user device to have Internet connectivity. This allowed devices
to connect to other devices and services for extended functionality (Rouse, 2016). Ever since the first
internet accessible Smartphones appeared in the mid-90s, connected devices have increased in complexity
and grown in intelligence (Allaire, 2009). This in turn has caused the networks they were connected to, to
grow in complexity as well.
In traditional IoT architectures, all data generated from connected devices are sent to the central server for
storage and further analysis. The added complexity from new devices that are connecting to the network
has caused additional load to be applied on the central servers orchestrating the communication between
those devices. A new concept known as "Edge Computing" aims to combat this. It refers to the
computational logic that is done close to or at the source of the generated data (Miller, 2018). Edge
Computing proposes that a certain amount of preprocessing be done at the edge without delegating
1 Nuwan Jayawardene | 2015235

Introduction
everything to the central server (Butler, 2017). Fog Computing (via Fog Networks) is one way in which
Edge Computing can be implemented.
1.2.1 Edge Computing and the central Cloud Server

Cloud Computing comprises of a close interplay between both the central cloud and the network Edge.
Both play a part to complement each other’s' feature set.
The best way to understand how Edge Computing and the central cloud servers work in tandem is to study
a Smart City scenario (Zanella, et al., 2014). When taken in the urban context there are several instances
where authorities have decided to use connected devices to observe the state of public services. Some of
the notable situations among those being; Building Monitoring, Waste Management, Smart Parking and
Autonomous Driving (Hammi, et al., 2015). In the case of Building Monitoring, Smart Parking and
Autonomous Driving there can be instances where these services function simultaneously to provide better
value to residents. For example; an autonomous car can be instructed to travel to an apartment complex
with a building monitoring service. Upon arrival the car would connect to the apartment building’s central
monitoring service wirelessly. This monitoring service could be paired with others as in the case of several
apartment complexes in close vicinity, each with their own monitoring system. Finally, all the apartment
complexes can be monitored and maintained through a central server located offsite.
This Smart City example shows that there can be real-world instances where multiple layers of devices
(arranged in a sort of hierarchy) come together to form a complex Fog enabled IoT Network (Aazam &
Huh, 2014). Typically, Fog enabled IoT Networks are formed by Fog Nodes, small pockets of “mini-
networks” comprising of a main Edge Gateway to which child Edge Devices would be connected (Bonomi,
et al., 2012). In this instance, a Fog Node would be formed between a single apartment building’s central
monitoring service and the connected series of autonomous cars.
Good governance within a complex system is maintained by trust among its participants (Tragos, et al.,
2016). If not for this, participants would refrain from participating in the system, making the system a
failure. This applies for IoT Networks as well (Tragos, et al., 2016). In any IoT Network this governance is
upheld by several fundamental characteristics (Patel & Patel, 2016). Those characteristics include; Dynamic
nature, Heterogeneity, Safety, Connectivity etc. These characteristics combine together to create several
crucial umbrella factors such as;
• Security – The security risk of a network goes up significantly with the increase in the number of
devices and in turn, the network complexity (Jing, et al., 2014).

Introduction
• Analytics – Knowledge of the devices within a network gives context to the type of data being
transferred. This further aids in functions such as Edge analytics (Alturki, et al., 2017).
• Diagnostics – Device actions within a network provide insight into what each of their functions
are. Device Management services are used in such instances (Perumal, et al., 2015).
It is by adhering to these factors that good governance within an IoT Network and by extension, its longevity
is maintained. In a complex IoT Network (such as in a Smart City) the weight of these factors is
compounded due to the sheer scale of the network as well as the larger number of participants. Therefore,
adhering to them becomes even more of a priority. The only way in which these factors can be adhered to
is by accounting for each and every Edge device and Edge Gateway within a particular network. Accounting
of devices within an IoT Network can be done by having the main supervisory service (i.e.; the central
cloud server) keep constant track of what devices under its influence are doing.
In order to do so, it is imperative that the central cloud server have a thorough understanding as to how the
devices under its influence are arranged.
1.3 Problem and Motivation
1.3.1 Problem
Based on the Background exploration (section 1.2), it has been established that Edge Computing
(implemented through Fog Networks) aims to reduce the load on the central cloud. But on the flip-side as
more Fog Networks with different devices get added and network structures get more modularized, the
central cloud is left uninformed. Thus, more attention should be given to relationship between the Network
Edge and the cloud than each of those components individually.
As it stands right now, the problem with the current state of IoT is the lack of a method enabling the central
cloud to understand hierarchical Fog Networks/Devices connected to it.
As underlined above, the key point in the problem definition is “hierarchical Fog Networks/Devices”.
Multi-level Fog Networks are born when Edge Gateways are nested one under another while other devices
are also connected to them. This creates pockets of Fog Networks (also known as Cloudlets) that inevitably
increase network complexity.
1.3.2 Motivation
During the Degree required industrial placement the author was given the opportunity to work on an IoT
middleware product. It was during this placement where it was noted that in many industrial IoT use cases,

Introduction
the customers requested some form of autonomy of its' Fog Networks. At the same time, they also wanted
the ability to view and manipulate the network from the central cloud.
Through this the author realized the importance of the cloud to always maintain an understanding of the
Fog Networks connected to it. This idea was further reinforced when a certain Smart City contractor had to
give up on a deployment as they couldn't find any product which gave them the needed feature.
With Fog Networks moving from Industrial IoT to more consumer-oriented areas such as Smart Home and
Home Automation via smart speakers/hubs such as Amazon Alexa, the need for a generalized solution was
increasing. Since such developments were taking place it was understood that a proper solution will aid the
entire IoT industry.
1.4 Aim and Objectives
1.4.1 Aim
The authors' aim is to research, design and develop a generalized solution that would provide the central
cloud/server with an understanding of the hierarchies of Fog Networks/Devices connected to it.
1.4.2 Research Objectives

The approach to researching and implementing the solution would be separated into four distinct elements;
1. To propose a generalized solution that satisfies identified properties – The solution should
be generalized so as to not contradict existing standards in IoT networks.
2. To research and develop the proposed architecture – This is done in order to check how
feasible different approaches are to implement the Architecture.
3. To perform additional implementations to simulate the Network Edge and platform
relationship. – Developments on other aspects (such as Edge Devices) of the network would
be required to show the full breadth of the Architecture.
4. To write a documented specification about the proposed Architecture. – The Architecture
is conceptual and product agnostic. Therefore, it should be well documented so that others can
understand it properly and if needed, integrate it into their own products
1.5 Features of Prototype

In the initial state of the project, the author plans to have the following features available in the prototype.
It should be noted that these features are intended to be user facing, therefore would not go into more
obscure technical functionality which will be discussed in the subsequent chapters.

Introduction
1. A deployable server: The author plans for the architecture to be implemented on a deployable
server. This would mean that the final prototype would be able to function similar to a web server
and run either locally and localhost or
2. Device enrollment capability: An Edge Device should be able “connect” with a server and
establish a relationship.
3. Ability to view enrolments: The server should display the list of enrolled devices along with the
associated device information.
4. Ability to show network related information: The final prototype should include some
functionality to aid the user in providing an easy-to-use way to understand the state of the network.
Accordingly, a very basic Rich Picture diagram shown below in Figure 1.1 has been created to showcase
the preliminary arrangement of the authors implementation.
Figure 1.1 - Basic Rich picture of implementation
It should be noted that the above rich picture diagram is supposed to be very basic and a more descriptive
diagram will be discussed in the forthcoming chapters (refer section 5.5). It should also be noted as
suggested from the above figure that the author hopes to maintain the scope of this project on changes made
and suggested to the central cloud server.
1.6 Outline of Thesis

Table 1.1 shown below provides an overview of how the chapters are arranged within this document and
what aspects each one will focus on in relation to the project.

Introduction
Chapter 2: Project Management This chapter elaborates on how different methodologies were
followed for various aspects of the project such as research
methodologies, software engineering etc.
Chapter 3: Literature Review A complete analysis of the research related to the domain that
is being studied by the author as well as an in-depth look into
existing solutions.
Chapter 4: System Requirement This chapter will focus on how the different requirements
Specification were gathered for the project and how the stakeholder were
identified. In addition, required UML diagrams will be used
to clarify aspects of the project.
Chapter 5: Design Specification Will focus on the using the information about gathered
requirements to design an Implementation
Chapter 6: Implementation Will solely focus on implementing the design elements
therefore it will be more technical oriented. Output would be
a functioning prototype
Chapter 7: Testing The prototype that has been thus developed would be tested
on different environment using a variety of testing strategies
Chapter 8: Evaluation The results obtained from the tests performed would be
analyzed and scrutinized qualitatively and quantitatively
Chapter 9: Conclusion The project will be concluded with the mentioning of lessons
learnt and future works
Table 1.1 - Outline of the Thesis document structure
1.7 Resource Requirements

Resources are needed for the successful completion of any project. Table 1.2 shown below provides the
resources the author believes are needed for this project.
Hardware Requirements Software Requirements
Quad Core Processor Unix based Operating System

To run the server with multiple threads Ideally Apple macOS or a Linux distribution

Introduction
8GB minimum RAM Oracle Java SE Development Kit (JDK)

To run the server effectively without To launch and run the server as it consists of Java
crashing applications
5GB disk space Apache Maven

For storage of log files, databases etc. To build the server and its components
Git
To safely preserve the source code in a version control
system
Web Browser
To access and view the GUI components of the deployed
server
Microsoft Word/G Suite

For document preparation purposes
Table 1.2 - Resource requirement list
1.8 Chapter Summary

This chapter involved a clear description of the project and the authors intentions. The case was made as to
why the author is pursuing a research in this domain and a problem was posed which the author is hoping
to answer the conclusion of this project. The scope of the project was roughly discussed, and a very brief
overview of the intended solution was showcased. The next chapter will go over the various methodologies
that will aid in managing the workload and bringing this project into fruition.

Project Management
2 Project Management

With the project Introduction and Background discussed in the previous chapter, this chapter will focus on
the methodologies that will be followed in order to bring the expected implementation to life. It will consist
of research methodologies, software engineering methodologies, testing methodologies and other methods
that would be helpful in organizing the project. In addition to this the project plan, possible risks and
associated mitigation scenarios would also be discussed.
2.2 Software Development Methodology

Apart from the actual research work involved, one of the main components of this project involves
developing a prototype that would showcase the viability of the author’s proposed solution. In order to
achieve the required functionality within the limited time allocated, a Development Methodology needs to
be followed. To select a one that is best suited for this project, the author picked several established
methodologies and compared them based on the requirements needed for this project.
Firstly, the development methodologies will be individually considered briefly relative to how their features
relate to the authors’ project. Thereafter the methodologies will be compared, and a suitable selection
performed based on the on with more merit.
2.2.1 Waterfall Development Model

The Waterfall development model is a time-tested software development methodology that has been present
for several years. It is noted for its very linear development flow that is reminiscent of how a building
construction takes place.
When considering the author’s project something that stands out is the limited time frame. The waterfall
development model is best suited for projects that aren’t as constrained in this regard. Additionally, given
the its’ sequential nature of development, the requirements of the project should be set in stone prior to
starting actual development. This is not ideal for research-based projects as requirements are subjected to
change based on new findings.
2.2.2 Rapid Application Development Model

This development model is a more modern software development approach in the regard that it focuses on
getting an MVP ready as quickly as possible. This is more suited for projects such as app development
where a certain client may expect to see a working demo to get a better feel for the final output. This also

Project Management
means that the requirements are malleable as the client can request changes that can then be integrated into
the prototype. This is also more suited for projects were the initial requirements are very minimal.
In research-based projects such as the one the author is engaged in; the prototype is meant to complement
the project and prove that the proposed solution is functional and practical. In short; the project is not
centered around the prototype, but rather the prototype implementation is formed based on the discoveries
made during the research process. In such a scenario it seems that the Rapid Application Development
methodology falls short. Conversely, RAD encourages quick development cycles which is very valuable in
situations with limited time frames.
2.2.3 Iterative Model

Similar to the RAD model, the Iterative model too has a focus on delivering an MVP in a short period of
time. But unlike RAD, it has a more progressive approach of modularizing a project, then working on each
module to completion prior to moving onto to the next module. This flow ensures that there’s a constant
state of growth in the project as complexity is added incrementally.
The Iterative model seems to take the best of both worlds or RAD and Waterfall methodologies. This means
that the prototype remains ready to a certain extent at any point during the project and that space is given
to new discoveries made during the research phase as well the learning curve required by new technologies.
For this authors project this would prove to be invaluable as there’s a high risk involved when working with
new technologies and the ideal methodology should be able to accommodate it. However, the Iterative
model also demands that the progress made with the implementation have a clear vision and path as
retconning can be costly and time consuming.
2.2.4 Selection of a methodology

With methodologies discussed in brief, the pros and cons of each can now be compared as in Table 2.1 and
at its’ completion a selection made based on what was identified.
Pros Cons
Waterfall • Simplistic and straightforward in • Difficult to perform any changes

Methodology nature once any progress has been made
• Clear designation of work and • Noticeable results can only be
progress that should be achieved seen much later in the project.
in each stage

Project Management
Rapid • Quick development cycles mean • Prototype driven instead of

Application an MVP can be achieved in a short research driven.
Development period of time. • Not ideal for projects with
Methodology • Updating requirements is easy. established requirements.
• Progress is only made from
feedback by stakeholders.
Iterative • Modular structure is flexible and • Must be vigilant of the progress
Model easy to follow. made as losing track can cause
• Enables the creation of an MVP in component redundancies.
a short amount of time.
• Can work with established
requirements as well as
requirements that change.
Table 2.1 - Comparison of Development Methodologies
By considering the above, several key points were formulated;
• The Waterfall methodology was proven to be inefficient due to long development cycles and the
generally favoring projects with extended development periods. However, the Waterfall
methodology did receive attention for its clear-cut development flow.
• The Waterfall model does not place much attention on user feedback until the latter parts of the
flow. This can become prove to be difficult to for a research project as new suggestions from
stakeholders could come in at any point during the process.
• The RAD model was abandoned due to the fact that it relied too much on stakeholder feedback and
was more prototype centric than what was required.
• The Iterative model provided the right mix of Waterfall and RAD such that it enables quick
development cycles and a faster path to an MVP as well a clear-cut flow to the development work.
• The Iterative model also caters well to established requirements being updated to accommodate
new discoveries in the research.
Accordingly, it was realized that the Iterative model was most suitable for the authors’ project.

Project Management
2.3 Work Breakdown Structure

A Work Breakdown Structure (WBS) helps a project manager clearly understand what phases a certain
project comprises of and decompose each to its bare essentials. Accordingly, a WBS chart was also made
for this project to aid the author in bringing it to completion.
The finalized WBS chart is located in Appendix – Work Breakdown Chart.
2.4 Gantt Chart

Similar to how a WBS chart helps maintain an arrangement of how a project is structured, a Gantt chart
allows a clear view of the timeline for a time period that a project should be accomplished within. This is
mostly created at the very onset of a project so as to have a clear idea about which stage the project should
be in at any given time. This is especially true for research projects where too much time languishing on
one aspect would take away from the time allocated for a later phase. Thus, a Gantt chart is a valuable tool
to have for time management purposes.
A Gantt chart for the authors’ project was created as well due to the same reasons. It can be found at
Appendix – Gantt Chart.
2.5 Project Risks

The list of project risks that were identified during the course of this project as well as relevant mitigation
procedures are indicated in the table found at Appendix – Project Risks.
2.6 Chapter Summary

This chapter focused on creating a clear plan required to proceed with the project. It involved identifying
the most crucial components in this project, identifying the involved risks and formulating mitigation plans
for those risks assuming the worst-case scenarios. The following chapter will focus on the very initial
research conducted regarding the project with the Literature Review and study of existing products.

Literature Review
3 Literature Review

This section of the document provides literature evidence of the multiple tiers in a typical IoT network
(Eclipse Foundation, 2017). Those tiers are;
1. The central cloud

2. Edge Gateways
3. Edge Devices
The literature review will further explore and investigate existing research on these topics as well as IoT
architectures that combine all of them together.
Prior to discussing research of existing architectures, the various components terminology associated with
an IoT network and the different software stacks of the three IoT tiers will be explored. This will allow for
additional understanding of what those layers are comprised of as well as deconstructing what needs to be
adjusted in them to accommodate a proposed architecture. Those stacks will be understood using the scope
of a generic IoT architecture.
3.2 High-level IoT architecture

Traditional IoT architectures share much in common with standard Client-Server arrangements. Figure 3.1
below indicates how a traditional IoT network is arranged.
Figure 3.1 - Traditional IoT architecture
Similar to a regular Client-Server network, traditional IoT architectures have many devices connected to a
central server. In IoT nomenclature those client devices are known as "edge devices". The basic structure

Literature Review
is pretty straight forward and easily understandable. Due to the similarities with CSAs (Client-Server
Architectures), traditional IoT architectures do not require heavy customizations. Hence the reason why
they are easier to implement.
This contrasts to an IoT architecture with Fog Networks.
Figure 3.2 - IoT architecture for Fog enabled network
As indicated by Figure 3.2, the Fog enabled network contains significantly more devices. As discussed
previously; when the number of devices in a network increases, so does the network complexity (Milito, et
al., 2014).
3.2.1 Conceptualizing a High-level architecture

Although today's' Internet still works on most of the same TCP/IP network technology that was proposed
at its' very inception, much has changed since then. As more and more technologies were miniaturized, the
number and the types of smart mobile devices have grown drastically. The challenges faced today are much
different than those faced at that time. Issues such as Interoperability, Scalability and Reliability are much
more pronounced than they've ever been.
This generic high-level architecture has been proposed as a radical rethinking of the age-old TCP/IP
technology. While at its' roots it is the same as the old system, it has been arranged at a high level to bridge
the new and the old to create a better foundation overall (Khan, et al., 2012).
Since this research is on Architectures based on Fog networks, that is where the main focus will be on. The
basic deconstruction of a Fog enabled network is indicated in the figure located in Appendix – Layers of a
Fog enabled IoT Network.

Literature Review
Individual layers can now be broken down starting from the bottom layer and making way to the top.
While a traditional IoT networks contains only three layers; the Perception layer, Network layer and
Application layer, a Fog enabled network contains an extra two. Those are the Business and Network layers
(Aazam & Huh, 2014). The reasons for the addition of the two new layers will be explored as the chapter
progresses.
3.2.2 Layers in a High-level architecture

The explanations of each layer are as follows;
1. Perception Layer - This is the layer closest to the network Edge. For this reason, it can also be
called the Device layer. As suggested by the name; its' primary purpose is to perceive the
environment via Edge Devices (Aazam & Huh, 2014).
As indicated by Figure 3.3 it could be said that this layer is the one with the most diverse
components. The devices inhabiting the Perception layer could range from mere sensors to ultra-
powerful Smartphones. In most cases the data sourced from devices in the Perception layer is raw
and un-processed. This layer also includes the various discoverability options for the devices. These
include location-based discovery using methods like geo-fencing and other forms such as RFID
sensors and QR codes (Khan, et al., 2012).
This collected data is then forwarded to the Network layer for further transmission.
Figure 3.3 - Perception Layer
2. Network Layer - The data sourced from the Perception layer is received by the Network layer.
This layer could also be referred to as the Transmission layer as well since it acts as the glue
between the lower level and the higher middleware level. The functionality of the Network layer is
equivalent to that of the Network and Transport layers in the OSI model (Aazam & Huh, 2014).
This layer is composed of two main components; Transmission Media and Network Devices.
Transmission Media can be further subdivided into wired and wireless(3G, Wi-Fi, Bluetooth,
ZigBee etc.) as indicated in Figure 3.4. The actual transmission medium depends mainly on the
kinds of devices the specific Network layer is interacting with in the Perception layer, as sensors
and other Edge devices have varying technologies (Khan, et al., 2012).

Literature Review
Network Devices are the actual devices facilitating the function of the Network layer. The feature
that makes the Network layer unique to Fog enabled architectures lies here. Edge Gateways are the
supervisory devices that act as middlemen in Fog enabled networks. They directly interface with
both the Network layer as well as Middleware layer, policing and monitoring the data being passed
between the two. Sometimes Edge Gateways come with integrated network management and
information processing features.
It should be noted that similar to traditional IoT architectures in some instances, Fog enabled
networks also ignore the Network layer and connects the Perception layer directly to the
Middleware layer.
Figure 3.4 - Network Layer
3. Middleware Layer - The Middleware layer is the ultimate governor of the entire network. It
receives the partially processed or raw data pushed forward by the lower Network or Perception
layers. As indicated by Figure 3.5; the functions of the Middleware layer include (Aazam & Huh,
2014);
a. Service Management
b. Storage of data
c. Information Processing
Service Management includes the entire suite of subsystems used for managing Devices as well
users in the network. This function is responsible for upholding the required permission levels and
restricting or allowing access to certain operations.
Storage includes having databases for any and all user allowed data that passes through the network
and storing them safely. This stored data can be exposed for internal or external use via the Service
Management function.
Information Processing is the most important function performed by Middleware Layer. As the
central hub where the majority of information passes through, it is the task of the Middleware layer
to decipher and understand that flow. Doing so allows higher level decisions to be taken by the
system administrators upon viewing analytics.

Literature Review
Figure 3.5 - Middleware Layer
4. Application Layer - Once the data has been retrieved, stored, deciphered and processed it needs
to be presented in a meaningful manner. That is the function of the Application Layer.
The actual human interaction with the central server takes place via this layer. The Application
layer obtains the information from the Middleware layer and presents it using GUI or other means
for ease of understanding. In more generic terms, the Applications layer mainly consists of UI
components such as dashboards for displaying all the data generated within the network.
As indicated by Figure 3.6, the Application layer could also be further expanded to broader “Use
Case” scenarios such as Smart City, Intelligent Transportation infrastructure, Smart Home etc.
(Aazam & Huh, 2014)
Figure 3.6 - Application Layer
5. Business Layer - Unlike the other layers, the Business layer does not directly deal with any data
generated from the network. It in fact does not deal with data at all. The Business layer is a recent
introduction to the field of IoT
It is an indisputable fact that in the modern world "Data is the fuel we use to make decisions"
(Olson, 2003). Organizations who have gathered vast amounts of data have identified this and are
working to monetize the information generated from that data. The Business layers further enables
to intercept information generated from the Application layer and create additional services which
can directly impact the business model of an organization (Khan, et al., 2012). In summary, the job
of the Business layer is to make money for the organization by using its existing IoT infrastructure
and the data gathered via that infrastructure.
While the Business Layer is a valuable addition to the field of IoT, for the purposes of this research it will
be ignored as it is of no relevance to the topic.

Literature Review
In Summation; the Edge Device and Edge Gateway tiers are maintained by the Perception and Network
layers respectively, while the central cloud is the combination of the Middleware and Application layers.
As the Fog enabled architecture has now been explored functionality-wise for each tier, the author will now
attempt to deconstruct the Software stacks of each tier individually.
3.3 IoT architectural stacks

While the High-level Architecture discussed up to now is mostly theoretical, a means is required to
implement is practically. This is where “stacks” come into play.
Typically, in Computer Science and Software Engineering, a "stack" refers to a group of programs that
work together to achieve a common goal. More often than not, each layer in a stack has a designated
function. Upon completion of this function the handled data is passed onto the next layer of the stack for
further operations. Stacks are found in many diverse areas within the field including but not limited to Web
Development, Operating Systems and Networking. A notable example is the OSI model that functions as
the backbone of the entire internet infrastructure.
The reason that stacking architectures are more common is because of the benefits it provides. Those
include;
• Leanness - Ability to achieve the required goal with minimum software overhead. This results in
high performant systems.
• Modularity - With jobs designated according to stacks it is very easy to mix and match based on
needs.
• Configurability - Along with modularity comes the ability to easily configure the system to run
on any environment.
The above benefits indicate that software stacks would be ideal when it comes to performance heavy
environments. This is especially true for distributed systems running on middleware platforms. By having
software stacks in scenarios where aspects like Atomicity, Synchronicity and Availability are crucial;
highly responsive systems that require low maintenance can be created (Astley, et al., 2001).
This case remains true for IoT as well.
In IoT, software stacks are implemented in the three architectural tiers. As discussed in the generic
architecture, each tier can be deconstructed into layers that have its own unique set of duties that need to
be fulfilled. Each stack is specialized in achieving those assigned duties. Exploring the nature of these
stacks will aid in understanding how each participant in the network contributes to the whole and how each
duty is achieved in a practical manner.

Literature Review
The stacks will be discussed starting from the lower level of the architecture with Edge Devices followed
by Edge Gateways and finally the central cloud.
3.3.1 Stack for Edge Devices

Edge Devices can be called the smallest units in an IoT network. They are also the most varied.
Some can be extremely powerful capable devices while others can be very constrained in terms of resources.
Some can be mobile while others are geographically fixed.
The most common Edge Device that almost everyone interacts with on a daily basis is the Smartphone.
Despite the wide variety in devices, the general software stack remains the same. But there are certain
details that are often taken into consideration when developing software stacks for Edge Devices. Those
include;
1. Constrained Resources - When developing software for many devices the rule-of-thumb is to
consider the lowest common denominator. In the case of Edge Devices those happen to be Sensors
and other embedded MCUs. Since these types of hardware have very limited resources(processing
power, memory) the software has to be fine-tuned to be as lenient as possible.
2. Limited Power - While there are devices that have a continuous source of energy many Edge
Devices happen to be mobile. Which means they rely on battery power. Hence it is of utmost
importance for the software not to abuse this limited energy.
By looking at the above conditions it can be understood that software stacks in Edge Devices should be as
efficient and lightweight as possible. They are also designed from the beginning to be specialized for a
specific task and be easy to mass produce at low cost (Eclipse Foundation, 2017).
Figure 3.7 - Software stack for Edge Devices (Eclipse Foundation, 2017)
As depicted in Figure 3.7; the layers in the Edge Device stack are as follows;

Literature Review
1. Operating System - Often this is an extremely bare bones system. These OSs are most suited for
small constrained devices with a very limited number of functions (Eclipse Foundation, 2017).
Linux is often an OS of choice on such hardware. At the same time, Edge Devices like Smartphones
have fully-fledged OSs like Android since they have more powerful hardware. In recent years,
manufacturers have taken an interest in retrofitting Smartphone OSs to work on constrained
devices. Such examples are Google's Android Things and Microsoft's Azure Sphere.
2. Hardware Abstraction - While the Operating System takes care of lower level functions such as
memory management and services, a HAL (Hardware Abstraction Layer) exists to manage I/O
related functions. Ports such as GPIO ports and serial interfaces are managed by the Hardware
Abstraction layer (Eclipse Foundation, 2017).
3. Communication Support - Edge Devices have many forms of communication. Multiple drivers,
protocols and technologies coexist in each device. Among the many forms of communication are
Bluetooth, Z-wave, Wi-Fi, HTTP, MQTT etc. (Eclipse Foundation, 2017). There may even be
wired media such as Ethernet. All those modes are managed by this stack.
4. Remote Management - Alongside all the other stacks lies a Remote Management agent monitoring
and manipulating the behaviors of the device. It can lookup factors such as the firmware version or
even the battery level if needed (Eclipse Foundation, 2017). In some devices this is built into the
OS itself.
Recalling back to the Perception layer in the high-level architecture, its' the author's belief that this aspect
could be integrated into the HAL stack(as all sensory accessories are I/O to the device). It could even be
delegated to a separate sub-stack, but that would go against the "lean" ethos when developing software for
constrained devices.
3.3.2 Stack for Edge Gateways

Edge Gateways are what makes Fog Networks possible.
Edge Gateways bring the power of the cloud closer to the Edge of the network. While not having the entire
feature set of the central cloud, they perform an integral role in coordinating the connectivity of lower level
devices and with the central cloud. Even though these devices have more supervisory role in the network,
from the perspective of the server they are also an Edge Device albeit one with more privileges. Edge
Gateways also share many similarities with typical Edge Devices.
An Edge Gateway can take many forms. Some can be implemented strictly using software(such as a proxy
server) while others can be hardware-based devices. These hardware-based devices are often referred to as

Literature Review
Field Gateways as they are deployed in the actual geographic location. It is these Field Gateway type that
will be used in this research.
Much like Edge Devices, Edge Gateways can also be mobile or stationary. Stationary Gateways are used
in Industrial IoT use cases. They sometimes even mesh together with each other to perform elaborately
choreographed actions using the Edge Devices connected to them (Eclipse Foundation, 2017). Edge
Gateways can also be mobile.
Smart cars that have been extremely popular among consumers nowadays are essentially Edge Gateways
on wheels. They have a plethora of sensors constantly taking in its' environment which is ever changing. In
situations like Autonomous driving, high response time is crucial. Therefore, the built in ECU (which is
vastly more powerful than a regular car) takes real-time decisions regarding the cars' performance while
simultaneously updating the central cloud.
Where Edge Gateways and Edge Devices differ drastically is from their software. Edge Gateway stacks are
much denser and more complicated than Edge Devices. Edge Gateway software stacks are designed to
support localized storage, fast networking and some rudimentary Edge analytics.
Figure 3.8 - Software stack for Edge Gateways (Eclipse Foundation, 2017)
As depicted in Figure 3.8; the layers in the Edge Gateway stack are as follows;
1. Operating System - Similar to Edge Devices, this is often a very stripped-down OS running on
Edge Gateways. Linux is the system of choice mainly due to the stability it offers (Eclipse
Foundation, 2017). Some OEMs provide their own custom Gateway OS that works seamlessly with
their own cloud offering. There are even instances when OEMs open source their gateway code to
further accelerate adoption.

Literature Review
2. Application Runtime - Unlike regular Edge Devices, Edge Gateways have more resources to
spare. They also don't have the same constraints such as Power usage either. Hence user made
applications can be run on them. Normally, lightweight runtimes such as JVMs or Node are
perfectly suited for such environments (Eclipse Foundation, 2017). Depending whether the
Gateway itself is intended to be run headless, the applications along with the OS itself can be
designed with or without a GUI. By enabling applications to run on Edge Gateways, functionality
that is not natively present could be implemented. Examples for such functionality include Edge
Analytics via embedded stream processors.
3. Communication and Connectivity - Since the primary role of Edge Gateways is to interface with
Edge Devices, it should have the necessary tools to accomplish that task. One of those tools is
protocols. In order to effectively communicate with each of its' child devices, Edge Gateways need
to support a variety of different protocols such as Bluetooth, Bluetooth LE, Wi-Fi, Wi-Fi Direct,
ZigBee etc. (Eclipse Foundation, 2017). They also should support a variety of different networking
options such as Ethernet or Cellular.
4. Data Management and Messaging – By design, Edge Gateways must have some form of
autonomy from the central cloud. To achieve this, Gateways often have localized storage and
caching mechanisms to persist a certain amount of data. Having data stored locally allows for
reduce network latency as well as real-time Edge Analytics (Eclipse Foundation, 2017).
5. Remote Management - Similar to regular Edge Devices, Edge Gateways also include a Remote
Management agent to keep tabs on aspects of the device. This agent can be used to update firmware,
add new features, provision new roles to the Gateway and sometimes even to activate/deactivate
entire Fogs in the network altogether.
3.3.3 Stack for Central Cloud

The Central Cloud (also referred to as the IoT Cloud Platform) is the central orchestrator of the entire
network.
If the closest biological analogy to an IoT network was the central nervous system, then the central cloud
would indefinitely be the brain. This would mean that the central cloud remains aware of every single
operation taking place within the network.
Recalling what was previously discussed, the Middleware and Application layers in the High-level IoT
architecture perform many functions related to network governance. The central cloud is the real-world,
practical implementation of those layers. Therefore, the software stack in the central cloud is required to
perform all the theoretical functions dictated by the Middleware and Application layers of the High-level
architecture.

Literature Review
As such, the central cloud includes the complete infrastructure required to maintain a complex IoT device
network. Aspects of such an infrastructure are;
• Device Management
• User Management
• Application Management
• Service Management
Cloud Platforms can be developed atop a variety of different runtimes like JVM and Node. In such cases
the majority of the core logic would be written in the respective languages but given the complexity and
the large number of components in the central cloud, in reality many other technologies come into play.
An IoT Cloud Platform is intended to be run on specialized cloud infrastructure (Eclipse Foundation, 2017).
This can either be done on premise or deployed remotely. Some companies (OpenShift, AWS, Microsoft
Azure, Cloud Foundry etc.) provide PaaS features by hosting their proprietary cloud products on their own
servers and giving access to consumers for a fee. This makes certain aspects such as resiliency and fault
tolerance come in as standard, so consumers won't have to worry about it.
In this manner it could be seen that central cloud platforms could be deployed in a multitude of different
ways depending on different use cases and requirements.
Figure 3.9 - Software stack for Central Cloud (Eclipse Foundation, 2017)
As depicted in Figure 3.9; the layers in the Central Cloud stack are as follows;

Literature Review
1. Connectivity and Message Routing - IoT Cloud platforms should be able to communicate with a
large number of Edge Devices and Edge Gateways using different data formats and multiple
protocols (Eclipse Foundation, 2017). Additionally, cross stack communication should also be
possible. While the Connectivity stack will be in charge of the handling communications with
external devices, the Message Routing stack will be managing cross stack data exchanges. In most
cases a Messaging Bus will be used in such an instance.
2. Device Management and Device Registry - With so many devices getting connected to the central
cloud there should be a means by which all those connections can be tabulated. This is where the
Device Management and Registry stacks come into play. The Device Management stack is in
charge of maintaining the enrolled devices while the Device Registry stack maintains a central
registry of the exchanges between devices as well as exchanges with the server (Eclipse
Foundation, 2017). The Device Management stack often taps the resources from the Device
Registry to perform its' tasks.
3. Data Management and Storage - In any Cloud platform there's a vast amount of auxiliary data
accompanying the Device data. This data includes User data, Session data, Tenancy related data
and more. While the Device Management and Registry stacks are specialized to deal with Device
related data, the Data Management and Storage stacks deal with all other auxiliary data.
While in this Cloud platform stacked layout the Device Management stack exists below the Data
Management and Storage stacks, it is the authors' belief that it should be in reverse. That is; the
Data Management and Storage stacks should exist below the Device Management stack. The
Device Registry's location is unchanged. By arranging the layout in this manner, the functions can
be further modularized. So, for any persistent data retrieval or storage jobs the Device Management
stack will first communicate with the Data Management stack which will then perform the required
function on the Device Registry.
4. Event Management, Analytics and UI - Even with Edge Analytics running on Edge Gateways
almost all of data from the entire IoT network eventually makes it way to the central cloud. With
so much of data passing through the central cloud, steps should be taken to perform "data mining"
to better understand what that data represents. This is where the Event Management and Analytics
stack comes in. It is used for scalable event processing as well as to consolidate and analyze data
(Eclipse Foundation, 2017). Often in cases such as this, a stream processor is used for real time
data analysis. Furthermore, the best way for users to understand that analysis is through pictorial
representations. The Application layer that was discussed in the High-level architecture achieves
this in a theoretical sense. It is implemented using a UI sub-stack. The UI could also be delegated
to a separate stack if the need arises.

Literature Review
5. Application Enablement - In today's connected world, SOAs (Service Oriented Architectures) are
proliferating in almost every field imaginable. Organizations are working hard to expose their
services and their infrastructure for external consumption. Some are even undergoing massive
cultural changes to accommodate this shift. A popular example is Amazon with their AWS
platform. The Application Enablement stack helps in this aspect. It enables services and data within
the architecture to be exposed in a safe and scalable manner to external and internal consumers.
Furthermore, as discussed in the Business layer in the High-level architecture, once these services
have been exposed the organization can monetize them. Not only would this aid in the adoption of
the services more widely, it would also bring in more revenue and additional value to the services
provided.
3.4 Reference Architectures

In the previous sections (3.2 and 3.3) a High-level IoT architecture and the IoT architectural stacks for each
tier in the network were discussed.
The High-level architecture provided a theoretical view of the functions of each tier in the IoT network.
The IoT architectural stacks in the succeeding chapter deconstructed those functionalities further and
implemented them in a practical form. This deconstruction and understanding of functionalities at their
basic levels provided an in-depth view of how an IoT architecture is organized. Creating a product
combining the IoT layers and stacks in different configurations could be termed as an "IoT implementation".
With the current knowledge in hand, it is possible to now look at existing IoT implementations and review
them. As this research focuses primarily on the IoT Cloud platforms(central cloud) and its' association with
Edge Gateways, that is the area of these IoT implementations that will be studied in depth.
The author has identified three notable factors to consider when choosing current implementations for
reviewing purposes. Those factors and the reason for taking them into account are as follows;
1. Edge Gateway support - This is a crucial requirement when choosing an IoT implementation for
this research. The reason for this being that the author's research is based on proposing changes to
the existing cloud infrastructures that support Fog Networks. As discussed in the previous sections,
Edge Gateways are what makes Fog Networks possible.
2. Open Source - In order to effectively review the makeup of the IoT cloud platform and it's devices
peering into the code is needed. This is only made possible if the project is Open Source.
3. Transparent IoT Architecture - In keeping with the primary purpose of this research, the Cloud
platform architecture should be clear. Only then can its' structure be reviewed in an effective
manner.

Literature Review
As with most distributed systems, there are several products which have varying degrees of the above
factors. To further diversify the research the author has picked implementations with a mix out of those
different factors. The factor distribution and the respective implementation/product is as follows.
Edge Gateway support Open Source Transparent IoT Architecture Selected product
Microsoft Azure IoT
Mozilla Web Things
Eclipse Kapua
Entgra IoT Server
Table 3.1 - Factor distribution for selected implementations
Each implementation can now be considered individually and reviewed briefly by considering the pros and
cons of each. The central cloud architecture and the Edge Gateway relationship with the cloud is what will
be put under the spotlight.
3.4.1 Microsoft Azure IoT

Azure is Microsoft's in-house cloud service. Azure IoT is the connected device division provided by that
service.
The Azure IoT architecture has been built on several foundational principles. These principles are as follows
(Microsoft Corporation, 2018);
• Security - Having security and privacy measures across all tiers of the IoT architecture.
• Heterogeneity - The architecture must accommodate a variety of different use cases with a vast
number of environments, devices and standards.
• Scalability - Services that scale; starting with a small number of device situations like POCs and
then expanding as the demand increases.
• Flexibility - Services being built as easily composable blocks that can be mixed and matched
according to the situation
Furthermore, communication across subsystems take place over REST/HTTP using human readable data
formats such as JSON. The architecture is built to support Edge Compute strategies with some processing
expected to happen on the cloud itself. (Microsoft Corporation, 2018).

Literature Review
A high-level view of how the different IoT network tiers are arranged in Azure IoT is shown in Figure 3.10;
Figure 3.10 - How IoT architectural tiers are arranged in Azure IoT (Microsoft Corporation, 2018)
3.4.1.1 Network Edge arrangement

By studying diagram Figure 3.10 it becomes clear that there are four ways to connect with the Azure cloud
platform. Those are;
1. Direct device connectivity to the Cloud

2. Connectivity via a Field Gateway
3. Connectivity via a custom cloud Gateway
4. Connectivity via a Field Gateway and a custom cloud Gateway
Of these four the focus of this research will be on type 2.
According to Azure IoT documentation, there are three different types of Field Gateways that connect other
Edge Devices to the central cloud (Gremban, et al., 2017). Those are namely;
• Transparent - The Gateway simply passes communications between the devices and the Azure
IoT cloud. That is, downstream Edge Devices have no awareness that they are interacting with an
intermediary Edge Gateway (Gremban, et al., 2017).
• Protocol translation - Sometimes, devices do not support the commonly used protocols such as
MQTT and HTTP. In those cases, a gateway is used to interpret and understand what those
downstream devices are communicating. In situations like this, the Azure IoT cloud only sees the
data as coming directly from the Edge Gateway device (Gremban, et al., 2017). It is not made aware
of the downstream devices.

Literature Review
• Identity translation - Devices that are unable to create and maintain a consistent connections with
Azure IoT cloud connect to Edge Gateways on its behalf. Downstream devices are seen by the
Azure IoT cloud as first-class devices with twins and methods (Gremban, et al., 2017). The
downstream Edge Devices and their users are unaware of the Edge Gateway acting as an
intermediary as all the features of the cloud are available to them.
Of these three types of Edge Gateway configurations, the Protocol translation configuration is the only one
that hides the identities of the downstream devices to the Azure IoT hub. In the other two(Transparent and
Identity translation) the Azure cloud has total awareness of the Edge Gateway as well as the downstream
devices connected to it, albeit in both instances the downstream devices themselves are unaware of the
intermediary Edge Gateway.
As only some partial parts of Azure IoTs' Edge Device and Edge Gateway agents are open source it is not
possible to get a complete view as to how interactions between devices take place beyond what is dictated
in the documentation.
3.4.1.2 Central cloud architecture

In order to understand the data of devices connected to it Azure IoT cloud maintains an entity store with
Device and Application models. This allows for features such as defining business rules, performing
searches, understanding context of analyzed data and building intricate user interfaces (Microsoft
Corporation, 2018).
In relation to the authors' research, the Azure IoT Cloud has device models that include the following;
• A schema to maintain device metadata (Microsoft Corporation, 2018). Metadata is data regarding
a certain component in a network that is not essential to the devices primary functions but crucial
in understanding the devices' identity in the network.
Such metadata include; device type, make, model, serial number etc.
• Device topology data, such as relationships between devices and other services. Often these
topologies follow a domain model.
As such, in a building management system the domain model includes entities such as building
complex, building, floor, room etc.
To combat the complexity that comes with such a domain model either a hierarchical structure or graph
topology is used (Microsoft Corporation, 2018). In most cases such a topology is maintained within the
Device Management stack. The schema will be maintained within the Device Registry stack.
This allows other authorized stacks to securely access this data and while data is kept safe from tampering.

Literature Review
Since the entire Azure IoT cloud architecture is closed source it is not possible to get a full view as to how
the data is arranged within it beyond what is explained in the documentation. This can be cited as a research
limitation.
3.4.1.3 Review and Summary

The Azure IoT stack contains some very interesting ideas.
The different Edge Gateway configuration is one notable point that is unique to this IoT implementation. It
not only addresses different types of requirements but also the wide variety of devices that could be
encountered in an IoT network. Although this could lead to some confusion when implementing the
network in real life. As in, there exists some redundancy with each type of configuration. For example; the
Identity translation configuration also supports protocol translation similar to Transparent configuration
while at the same time having additional features such as Identity to downstream devices. In the authors'
eyes, this might cause conflict in some instances. The context-based domain model in the central cloud is
also a noteworthy feature.
Based on the initial impressions it can be seen that the Azure IoT stack is very feature packed. While for
most use-cases it could prove to be enough, for the purposes of this research there are some significant
drawbacks that should be mentioned.
• The black-boxed nature of the Azure IoT architecture is a major drawback. Given Microsoft’s
history as mainly a proprietary and closed source software developer it has followed the same
philosophy into its cloud offering. While it does indeed have open source components such as the
Azure IoT Edge (Ramel, 2018), it is very tightly bound with their own cloud services to such an
extent where the open source nature feels more like an afterthought. This leads to the next
drawback…
• Vendor lock-in is legitimate concern when it comes to closed source vendors like Microsoft. They
maintain quite stringent limitations on which technologies are used and how the products operate.
Due to the above reasons the author has concluded that Azure IoT is not a viable implementation to use in
this research.
3.4.2 Mozilla Web Things

Web Things is Mozilla's interpretation of how an IoT network should exist. Unlike other vendors, Mozilla
plans to propose their IoT implementation as more of a standardized set of rules than an actual platform.
They believe that the internet depends on the proliferation of Open Standards. Hence why Web Things has
been designed with URLs, standardized data models and extensible APIs in mind.

Literature Review
Mozilla describes their mission as "…to ensure the Internet is a global public resource, open and accessible
to all. An Internet that truly puts people first, where individuals can shape their own experience and are
empowered, safe and independent." In keeping with this philosophy, they have made the decision to use
existing web technologies such as REST, HTTP, JSON and Web Sockets to build their architecture
(Francis, 2017).
Mozilla has identified three integration patterns when it comes to current IoT networks. They are;
1. Direct Integration - This is the simplest form of integration that allows an Edge Device to directly
connect with Mozilla's Web of Things API. Mozilla acknowledges that this type of integration is
not suited for a home network as it could expose Edge Devices to direct threats from the Internet.
2. Gateway Integration - The Edge Gateway itself runs an HTTP server that bridges Edge Devices
connected to it to the web.
3. Cloud Integration - This is similar to an Edge Gateway, only the Edge Gateway is not existing as
physical hardware. Here, the Web of Things API is exposed by a separate Cloud Server which acts
as
By studying these three integration patterns Mozilla has come up with their own framework titled "Project
Things" to help developers connect Edge Devices.
Mozilla has taken inspiration from the Gateway Integration pattern and developed their own Edge Gateway
solution. The entire Project Things endeavor has three components. Those are;
• Things Gateway
• Things Cloud
• Things Framework
As Project Things is still under development, a majority of documentation as well as the implementation is
still a work in progress and being continuously iterated by the developer community.
3.4.2.1 Central cloud architecture

Not much about Mozilla's Things Cloud has been revealed as of the time this research was conducted. Blog
posts by the project maintainers as well as the W3C draft specification was used to understand the
functionalities and the underlying architecture.
Despite this some aspects can be assumed. One such detail is how gateways get registered with the Things
Cloud. This can be obtained via a REST API specification included in one of the Mozilla IoT GitHub

Literature Review
repositories.
By studying it, the following information can be gained;
1. All requests are GET type requests.

2. Only Edge Gateways have the ability to subscribe with the server.
Since the server has no front-end interface, nor an active development community it has become
challenging to gather more information regarding it. This can be cited as a research limitation.
3.4.2.2 Network Edge arrangement

Mozilla's Project Things has put a lot of emphasis on its Edge Gateway development. Compared to the
lackluster attention given to the Things Cloud, Things Gateway has well updated and maintained
documentation and an active community. Additionally, the emphasis on Things Gateway can also be seen
in the feature-set provided by their Edge Gateway platform when compared to other vendors. Notable
features provided by the Gateway include;
• Custom Capabilities for Edge Gateways - This allows unrestricted access to custom Web Thing
Types (Francis, 2018). Through this, developers have the freedom and flexibility to add support for
a variety of different devices beyond the pre-defined set.
• Actions and Events with logs
• Powerful Rule engine - A GUI based rule engine that allows users to compose complex sequences
of conditional operations based on inputs from downstream devices.
• Smart Assistant integration - An interactive "Assistant" that consumes basic voice or textual
commands to manipulate downstream devices.
By studying the above, it becomes apparent that Mozilla's Things Gateway stands out among other
implementations.
What makes Things Gateway even more intriguing is how it has been designed from an architectural
standpoint. When discussing the Edge Gateway stack, it was understood that the system included a remote
management agent that allowed the gateway's functions to be manipulated externally. It was also understood
in the High-level architecture that the gateway associated Network Layer has its role designed specifically
to transfer data from the lower Perception Layer to the higher Middleware Layer. What makes Things
Gateway unique in this regard is that in Mozilla's implementation acts as an Edge Gateway and a server.
This becomes apparent when the Open Source Things Gateway code is studied as shown in the code snippet
located in Appendix – Server deployment code in Mozilla Web of Things Gateway.

Literature Review
Things Gateway consists of an image that can be flashed onto a development board such as Raspberry Pi.
Upon activation the device deploys a NodeJS server with that can be accessed through the local network.
The newly activated Things Gateway can thus be configured and even assigned a custom sub domain under
mozilla-iot.org (Francis, 2018).
Mozilla has also paid special attention to how Edge Devices in its' IoT implementation are created. Unlike
other vendors who have their own Agents for different platforms, Mozilla's "Things" (as its' Edge Devices
are known) rely on libraries supporting a variety of different languages. Most of these languages have been
proven popular in IoT use cases and include JavaScript (on NodeJS runtime), Python, Java and Rust. By
having libraries instead of straight forward agents increases the likelihood that developers will take up the
platform and start experimenting with it.

When comparing Mozilla's Project Things IoT platform with other comparative Open Source alternatives
many things stand out.
The Things Gateway is a main point of interest. Mozilla's implementation considers Edge Gateways as
primary participants in the whole infrastructure and not an auxiliary device. By effectively bringing the
functionality of an entire server to the Edge Gateway they have effectively combined the Network Layer
and the Middleware Layer in the earlier discussed High-level architecture. This has both its pros as well as
its cons.
On the upside this makes setting up and maintaining Edge Gateways a lot easier. Since the network structure
is very straight forward, hackers can easily go about porting and extending the Gateways functionalities
and platform presence/support. This further aids Mozilla's goals of standardizing the IoT field into a more
interoperable and open space. Plus, since Things Gateways does not rely on a complex server stack on the
cloud end to function, in the rare(but quite possible) case of a cloud outage it could easily maintain
autonomy.
On the downside lies the hardware constraints. Even though Edge Gateways have more resources than Edge
Devices, they still are severely under powered when compared to a cloud server. If unaddressed, this could
become a massive bottleneck that would impact performance intensive tasks such as Edge Analytics. Since
Edge Analytics is one of the primary objectives of an Edge Gateway, in Mozilla's implementation this could
prove to be a problem.
Additionally, scalability can also be affected. Regardless of the number of protocols and technologies, there
are only so many devices that a single Edge Gateway can maintain. This combined with the already
constrained resources can have a drastic impact of overall network performance.

Literature Review
The approach to have Edge Devices be implemented using libraries is also very noteworthy. These re-
usable components make it easier for developers to write clients on all forms of devices that can connect
with Mozilla's "Web Thing API". This kind of implementation meshes well with the entire ethos of Project
Things being an effort to standardize IoT to be more open and community based.
Given the amount of capability given to the Things Gateway component already in the Author's view it
could be very precarious to identify and address what functionality should be delegated to the Things Cloud.
Given the vagueness and lack of documentation of the latter, it could be said that Mozilla is focusing more
on creating an Edge Gateway based IoT network than a cloud centric one. The same sentiment is reflected
from the developers of the project as well.
Mozilla Web Things was one of the more interesting IoT implementations that was studied during this
research. While quite novel in nature, it did have drawbacks that didn’t allow it from being eligible for
further development.
• The unique Gateway centric nature of the implementation is both a positive as well as a negative.
Since the author’s research is based primarily on changes associated with central cloud this is a
major drawback.
• The current state of the project is also another cause of concern. Given the novel nature of the
existing product along with rapidly changing features (with old ones being deprecated and new
ones being added constantly) it is extremely difficult to gauge what kind of path the implementation
will go in. This changing of features can be noticed especially in areas such as exposed APIs. With
each new software version release the API formats as well as exposed functionality changes. In a
more mature implementation while updates would be unavoidable, drastic changes would not take
place in such close release proximities.
3.4.3 Eclipse Kapua

Kapua is the Eclipse Foundation’s implementation of an IoT central cloud. It is an active open source
project with the might of industry juggernauts such as Redhat behind it. The Eclipse Foundation does not
attempt to do anything pioneering with Kapua but rather sticks to a very traditional middleware/server
implementation. Although not explicitly said so, the design principles of Kapua are based on it being lean,
open and modular (Eclipse Foundation, 2017). In this sense, Kapua exists as a framework that provides a
set of functions essential for an IoT network to operate. Those functions are:
• Device Registry
• Device Management Services
• Data Management

Literature Review
• Messaging
To achieve the above, Kapua exposes three basic services. These are the interfaces through which the
functionality of the implementation gets exposed. Those services are as follows (Eclipse Foundation, 2017):
• Messaging service
• RESTful APIs
• Web Administration Console
Similar to Mozilla’s implementation Kapua does not require Edge Devices to have any custom clients to
be able to communicate with the central cloud. It has a series of APIs that expose almost all required
functionality.

Eclipse Kapua is one of the more traditional IoT implementations that was encountered during this research.
It follows a very lean “no-nonsense” design that is engineered to be as modular as possible. One of the
places this becomes especially apparent is how it handles Edge Gateways.
Kapua does not natively support Edge Gateways. Rather it uses another Eclipse project titled Kura for this
purpose. Eclipse Kura is another standalone project of the Eclipse Foundation that has been built to be a
cloud agnostic gateway solution (Eurotech, 2013).
Kura is not intended to be run headless and has a user accessible web console that provides several important
features. Features included out-of-the-box include the ability to configure the gateway, connect to a remote
cloud and even a visual data flow programming tool to dictate the data collection and processing pipelines
of devices connected to it (Eclipse Foundation, n.d.). Kura even has its own central repository with plugins
that add more functionality. Kura is perfectly capable of being run in isolation. But if ever the need arises
that a Kura gateway needs to be accessed remotely, it needs to be paired with a cloud connection. Thus, it
can be understood that Kura and Kapua are two different products that can work separately, but provide
additional functionality when combined together.
Since both Kapua and Kura are open source projects, much can be gained through developer documentation
and sources such as mailing lists and forums. While certainly quite capable as noticeable from the plethora
of features that each offer, it should be noted that neither seem to include any support (in its current state)
enabling nested gateways or hierarchical networks.

Literature Review
Eclipse Kapua is one of the more traditional implementations that was encountered in this research. It
checks all the required boxes needed for this research (as depicted in
Table 3.1) and is also very straightforward in its approach. Despite this, the author identified several
drawbacks that made it ineligible for further usage in this research.
• The barebones nature of the implementation is significant downside. As mentioned earlier, Kapua
is more of a lean framework than a full-fledged IoT implementation. This means the product is
intended to be built upon depending on a use case than used straightaway as it is. Aspects where
this is noticeable is in user management and multi-tenancy, which apparently it does not support.
While this is extremely useful in making it bloat free, for the requirements of this research it is not
ideal.
• The non-native support of the Edge Gateways is also a problem. As discussed, Kapua makes use
of another Eclipse project to achieve its Edge Gateway requirements; Eclipse Kura. That in itself
would have been fine but the problem lies in that Kura also has significant feature overlap with
Kapua. This would prove to be problematic as sometimes it can be difficult to locate where the
ideal place would be implement a certain component of an ideal solution.
From the authors’ perspective using a barebones implementation is problematic for this research as it
hinders the amount of changes that could have been executed otherwise. Given the time constraints on this
project as well as the features of the architecture, the more control that can be obtained and more features
that are available the better. Additionally, having a non-native Edge Gateway brings forth several issues.
Since the main scope of this research is changes done to a central cloud solution, having a, Edge Gateway
that also doubles on certain features of the central cloud is confusing. Hence the author decided to pass on
this product for implementing a solution of this research
3.4.4 Entgra IoT Server

Entgra IoT Server is another completely open source IoT implementation that has a bit of history that wasn’t
present in the other products.
For one, it was initially named the WSO2 IoT Server and belonged to a different vendor completely. This
vendor; WSO2, is an open source middleware company that already serves four other products (WSO2,
2018) focusing on different aspects of enterprise middleware. Those products along with their intended
functions are as follows;
• WSO2 Enterprise Integration - Integration of apps, data and systems

• WSO2 Identity & Access Management – Authentication and Identity management
• WSO2 API Management – Deploying, Managing and governance of APIs

Literature Review
• WSO2 Stream Processing – Monitoring of real time streaming analytics
WSO2 refers to this as their “Integration Agile Platform”. All of these products are extremely well focused
and very specialized in the functions allocated to them. What makes the IoT Server interesting is that it is
a collective amalgamation of all those four products. Therefore, it is highly modular and built as components
which according to companies own material “can be used individually, or as a cohesive integration-agile
platform.”
The IoT Server takes the functionalities brought on by all the components and distinguishes them into three
distinct sections (WSO2, 2018). Those are;
1. The Core – The main device management center which includes all related functionality.
2. IoT Analytics – Analytics on the data and devices is done via this section
3. Extended Platform – Non-crucial functionality depending on use case and domain is handled by
this section.
While serving the purpose of providing device monitoring functionality, the Entgra IoT Server is also
designed to serve strictly as an EMM (Enterprise Mobile Manager). An EMM refers to a purpose-built
central cloud server that’s designed to manage fleets of Enterprise grade devices (ideally organization issue
smartphones etc.) remotely and monitor them.
As discussed, prior, the Entgra IoT Server has been built by mixing and matching several components
provided by other WSO2 middleware products. While those components aren’t IoT centric they have been
combined together like LEGO bricks in a way that’s more ideal for an IoT central cloud environment.
Figure 2.14 indicates what those connections are like at a high level.
Figure 3.11 - High level overview of components in Entgra IoT Server

Literature Review
If we recall the IoT stacks discussed earlier, the component structure of the IoT Platform shown in Figure
3.11 is quite reminiscent of the stacks of the central cloud. More specifically, the Device Management Core
component is in charge of several duties such as;
• Device Management
• Operation Management
• User Management
• Certificate Management
that were all pointed out as crucial factors in the Central Cloud stack.

Other than Eclipse Kapua, the Entgra IoT Server is another more traditional IoT implementation that was
encountered during this research. Although unlike Kapua it is very feature rich and extensive.
As reviewed earlier, Eclipse Kapua was more of a barebones IoT implementation that needed much of the
setup to be done by the user depending their use case. In stark contrast to this, the Entgra IoT Server product
is packed from the get-go. This also has bit of a downside as in, it is somewhat bloated and heavy in
comparison. That’s not to say that it is not extensible. There’s a very robust plugin system that enables
additional user specific functionality to be added post deployment if ever the need arises
Another notable factor is that Entgra IoT is designed to be run with Enterprise grade standards. Hence it
has a majority of very important features relevant in an Enterprise environment backed-in. Those include;
• Multi tenancy
• GDPR compliance
• Multi process friendly
When focusing on the network Edge there are significant differences from the other IoT implementations.
While all the other implementations included libraries (Web Things) or integrated procedures (Azure) for
Edge devices to communicate with the cloud, Entgra IoT Server relies on device specific agents to get this
done. This is somewhat in keeping with the EMM sensibilities of the product which relies on full device
access (as in the case of Android or iOS devices) via agents to achieve its Enterprise management functions.
This has both upsides and downsides to it.
As an upside it is very easy to monitor devices and get real time information when an agent is running
within it, whereas a downside would be that in order to gain very detailed information and deep access on

Literature Review
a device, platform specific agents would need to be written. This would prove to be somewhat cumbersome
in the long run. That is not to say agents are the only way in which Edge devices are accessible. The Entgra
IoT Server also includes a very flexible “Custom device” creation tool that enables easy creation of device
types on the server end which enables Edge devices to access the server through REST endpoints. While
not as effective as agents, it gets the job done for the most part. What offsets the agent implementation
somewhat is that all agents (other than the iOS version) is open source and freely available.
While the central cloud component has been well documented, what the Entgra IoT Server seemingly lacks
is a proper Edge Gateway solution. While there is an Android based Edge Gateway, which uses a Gateway
agent, it is not as extensive or feature rich as expected.
Entgra IoT Server has a lot of things to be interested about. It is built with Enterprise grade environments
in mind therefore is rock solid and has a component-based model which is very easy to customize and
maintain. Yet, despite this, there are several downsides as well that cannot be ignored when discussing this
implementation.
• The lackluster support for Edge Gateways is a point of concern that needs to be addressed. As
discussed earlier the Edge Gateway solution in Entgra IoT is not up to par with other solutions of
a similar grade. This is not to say that the available solution is bad, it does have several features
such as edge analytics built in. But it is not on par with the rest of the Enterprise grade sensibilities
of the project.
• The need for agents to gain maximum access over Edge Devices is another point of concern. While
in other implementations that have been studied in this research the main method through which
devices accessed the central cloud server was through API endpoints or some proprietary means.
Having platform specific agents can be somewhat cumbersome both for implementation and
research.
3.4.5 Reference Architecture review

The table located in the Appendix – Reference architecture feature comparison provides a comparison of
the most preferred IoT implementations out of the ones discussed in sections 3.4.1, 3.4.2, 3.4.3 and 3.4.4.
In conclusion, the following points could be drawn based on that comparison;
• With regards to Azure IoT, because of the black boxed nature, it is extremely difficult to gauge
how the architecture is arranged. This would in turn prove to be very cumbersome as a possible
architectural change would require knowledge of the entire stack. Additionally, due to the concerns

Literature Review
of vendor lock in it is not advisable to test out platform agnostic architectures in such a limiting
environment.
• As mentioned earlier, the author’s research goal is to create an architecture which is platform
agnostic. This would imply that whatever platform is being used to demonstrate this architecture is
both well understood, accepted and with a concrete design. Mozilla Web Things fails to meet both
these requirements due its unfortunate drawbacks.
• The author has stressed in the in-scope of this research that the focus will mostly be on changes
made to the central cloud. In that case the downsides of the Entgra IoT Server product (lack of a
proper Edge Gateway solution) are mostly mitigated as they won’t be causing that much of trouble.
Additionally, the presence of a custom way to create endpoints for device types that enable Edge
Devices to access the central server without an agent is also very promising.
3.5 Chapter Summary

In this literature review, multiple aspects of an IoT Network implementation were studied.
First the author went through the conceptual high level of how an implementation is organized. Within that
the different layers that make up the implementation along with what roles each of those layers play was
discussed. This gave a framework for potential IoT implementations to follow when coming up their
products. Then the author provided a way in which the high-level view that was discussed prior could be
created in a practical sense. For this, “software stacks” were used for each of the different tiers in an IoT
Network implementation.
Afterwards the author picked several reference implementations that already exist based on a set of pre-
defined criteria. The selected reference implementations were thereafter studied in-depth and reviewed
based on what each of them offered. The different benefits and drawbacks of each were pointed out which
would either support or inhibit the progress of this research.
Finally, the author compared and contrasted three of the most suitable reference architectures and pointed
out an ideal one that would best fit the requirements of this research.

System Requirement Specification
4 System Requirement Specification

The previous chapter included a comprehensive literature review of all research material found in the
project domain. The focus of this chapter will be on identifying stakeholders and gathering the requirements
for the project. Different requirement gathering techniques will be scrutinized and a suitable one will be
selected that is ideal for the needs of this project. Thereafter Use-Cases will be developed upon which
Functional and Non-Functional Requirements can be defined.
4.2 Stakeholders
A project of this scale requires stakeholders to be targeted towards. First and foremost, the stakeholders
need to be identified. This is done via methods such as Onion models and Stakeholder descriptions.
4.2.1 “Onion Model” Diagram

Any project or organization has stakeholders. These are the people invested in the project and those who
are looking forward to it succeeding. A stakeholder Onion diagram is a visualization tool used to identify
and categorize stakeholders related to a certain endeavor. As presumable from the name, an Onion diagram
comprises of multiple layers. Each of the layers represent a level of association a stakeholder has with the
project. Typically, when being drawn the center represents the product or solution.
The immediate layer following the center is the Business System. It includes the stakeholders who have
direct interaction with the product/service. In the case of the author’s product (the Hierarchical Fog Network
architecture) that would include the System Administrators.
Following the Business System layer is the Organization. Stakeholders in this layer are not directly involved
with the product yet have control over the final output. They are called “Functional Beneficiaries”. In the
case of the author’s project it includes the Management, Tech Leads and System Architects.
The last and outermost layer in the Onion diagram is the Environment. It includes stakeholders that reside
outside the organization but are still invested in the progress and final outcome of the product. They are
neither functional beneficiaries nor have any operational involvement in the organization. As per the
author’s project it includes Clients and End-Users who would be using the product.
4.2.2 Stakeholder Description

Table 4.1 showcases the descriptive layout of the stakeholders that were identified in the Onion diagram
the Onion diagram located in Appendix – Onion Diagram.

Direct Engagers
Stakeholders Description
System Admins Will monitor network using hierarchy visualization

Functional Beneficiaries
Will guide developers to generate useful data from

Tech Lead architecture based on requirements
Management Will focus on Management level operations
System Architects Will make design decisions based on requirements

Outer Beneficiaries
Clients Will provide funds and provide requirements

End-Users Will use the end product
Table 4.1 - Stakeholder Description
4.3 Requirement Gathering
4.3.1 Review and Selection of requirement gathering techniques

Requirement gathering is what is used tabulate what would ultimately provide value and utility to the
intended audience of a product or service (Young, 2002). In order to gather said requirements there are
several methods. The most notable of them being (Young, 2002)
• Interviews
• Document Analysis
• Prototyping
• Questionnaires
• Brainstorming
Out of the above the Document Analysis method has been covered significantly in the Literature Survey
section of this research. Therefore, the author intends to focus on the Questionnaire, Interview and
Brainstorming methods moving forward. The author would be considering the strengths and weaknesses of
each method and deliberate which is most suitable.

As identified via the Onion diagram, the target audience of the author’s solution are System Administrators.
Other auxiliary stakeholders such as System Architects and Tech Leads exist in the immediate vicinity.
Accordingly, when discussing the requirement gathering methods the author will base them around those
stakeholders specifically.
1. Brainstorming involves gathering a group of individuals specializing in the domain so that ideas
can be generated and refined in a community environment (Young, 2002). This type of requirement
gathering technique is especially important when deliberating about concepts and ideas since its
more likely that someone is bound to find a fault or gap in the logic that you or others might have
missed. A notable downside to this technique can be the unnecessary convolution of ideas.
Considering the author’s research is about a conceptual architecture it is important that multiple
viewpoints on it be taken from industry experts. This is also due to the fact that the domain (IoT)
has multiple co-related components such as Central Servers, Edge Devices etc. which the author
has touched on previously.
2. Questionnaires imply a series of written or printed questions to be answered by informants

(Surbhi, 2016). They are regularly used to get a larger number of responses in a shorter period of
time. While conditions can be put in place to limit access the results are still mostly impersonal and
lack the identities of informants. Due to the close ended nature there can also be answers which are
quite objective and with a high no-response rate for certain questions. Despite this, since this
technique provide a higher yield of responses economically it is quite attractive for most
requirement gathering surveys.
Questionnaires are mostly used to gather customer feedback for end-user products. As mentioned
prior, since the author’s target audience includes individuals that do a niche role such as System
Administrators, Tech Leads and System Architects; distributing a generalized questionnaire will
not yield the most accurate answers.
3. Interviews are formal conversations between an interviewer and respondent taking place in a
question and answer format (Surbhi, 2016). Unlike questionnaires they are far more personal and
open-ended. This also means the answers can be subjective to a certain extent. At the same time
the questions can be targeted to the most suitable informants and get real-time one-on-one feedback
for the posed questions. Despite this, the most notable disadvantage is the costliness and time-
consuming manner of the technique.

Even though the interviewing technique does incur a significant amount of time, it is the author’s
view that the positives outweigh the negatives. This is considering factors such as;
I. The final implementation of the research having a very specific technical oriented
audience
II. The research being mostly conceptual and not intended for generic end users/consumers
III. Certain concepts being very specific and might not be clearly explained via a
questionnaire thus resulting in incorrect answers due to misunderstandings.
Additionally, the author has also noted that Brainstorming can also have a significant impact in the
requirement gathering process of this research. Accordingly, due to the above-mentioned reasons the author
has concluded that for this research the ideal manner through which requirements can be gathered is via
Interviews and Brainstorming.
4.3.2 Execution of requirement gathering techniques
4.3.2.1 Interviewing
Prior to performing interviews, several questions were formulated with the intention of being brought up
during the interview sessions. These questions were formulated by mapping them with the Research
Objectives of the project. The objective to question mapping can be found at Appendix – Interview
Questions.
Those questions were asked during interviews with 10 individuals all working in the domain of IoT,
middleware and connected devices but with roles at different levels in their respective organizational
structure. This number was derived at the point where all the answers had similar themes which were
reaching saturation. This number of interviewees is also backed by research on data saturation in
requirement gathering setups (Guest, et al., 2006).
4.3.2.2 Brainstorming
In addition to Interviews Brainstorming sessions were also conducted in the presence of some of the
interviewees. Many new approaches and techniques were brought up in these sessions with several
downsides also being addressed.
4.3.3 Conclusion drawn from gathered requirements

Upon the completion of the requirement gathering the following conclusions were reached;
• Increase of complexity with increase in devices has been mentioned as one of the largest issues
faced when dealing with IoT Networks.

• To handle this complexity most developers, resort to handling the complexity using Edge analytics
via Edge Gateways and Fog Networks.
• Interviewees also noted that despite this addition of extra devices (Edge Gateways) to the network,
the IoT central cloud servers managing these haven’t been updated to reflect their inclusion.
• It was also brought up that complexity has not been addressed from a usability perspective to make
it easier for System Administrators.
Additionally, they also mentioned that preference was given to Open Source products when it comes to the
IoT domain as it enabled better integration with existing infrastructure and products and also allows for
better customization depending on the use-case.
4.4 Use Case Diagram

Based on the answers gathered thus far, a use case diagram was created for the showcase the functionality
of the proposed Architecture implementation. The diagram is located in Appendix – Use Case Diagram.
4.5 Use Case Description

Use Case Enroll Device
Description A device is enrolled with the central cloud server via an agent or endpoint
Actors System Admin
Pre-Conditions A Device Type needs to be created including the properties of the device being enrolled
• Display Hierarchical visualization
• Display Hierarchy related info
Extending
• Change device status
• Disenroll device
• Identify Device parent
Including • Build EnrollmentInfo
• Save to Databased
System Admin
1. User logs into system with proper Device
credentials 4. Identify device parent within
Main Flow 2. User creates a device type with hierarchy
properties of a certain device. 5. Build object with device
3. Device is enrolled based on the EnrollmentInfo
previously created device type

1. Maven project with relevant device properties is installed

Alternative
2. User logs into system with proper credentials
Flow
3. Device is enrolled based on the previously created device type
Exceptions N/A
Post-Conditions Enrolled device details are saved in the database
Table 4.2 - Description for Enroll Device use case
Use Case Display Hierarchical visualization

A GUI visualization of how the IoT network is arranged is indicated in the console for
Description
the central cloud server
Actors System Admin
Pre-Conditions At least one device needs to be enrolled in the server
Extending • Enroll Device
Including N/A
1. User logs into system with proper credentials
Main Flow
2. User views hierarchical visualization
Alternative
N/A
Flow
Exceptions N/A
Post-Conditions N/A
Table 4.3 - Description for Display Hierarchical visualization use case
4.6 Requirements
4.6.1 Functional Requirements

FR No. Functional Description Use Case Priority
1 Get the credentials of user logged into Authenticate User High

the session and current tenant
2 Allow the user to enroll a device with Enroll Device High

the IoT server

3 Extract Device information from the Enroll Device, Identify Device High
enrolled device Parent, Build Device Enrolment
Info
4 Persist enrolled device details on a Save to Database High

database
5 Save hierarchy related metadata in Identify Device Parent High

database along with enrolled device
6 Change device status based on the last Change Device status High
contact time of an enrolled device
7 Display a Hierarchical visualization of Display Hierarchical Visualization High

the arrangement of enrolled devices in
the IoT network
8 Retrieve data related to the hierarchical Display Hierarchical related info High
arrangement such as list of children of
a parent device
9 Disenroll an enrolled device Disenroll device Low
Table 4.4 - List of Functional Requirements
4.6.2 Non-Functional Requirements

• NFR1 – Reliability: The central server must run reliably without crashing and expose the required
endpoints for devices to enroll with and perform other functions.
• NFR2 – Performance: The system must be robust enough to work at a reasonable speed without
having lag and slowdowns hinder the usability.
• NFR3 – Extensibility: The system should support inclusion of additional features without them
affecting existing functionality in a negative manner.
• NFR4 – Usability: The system should not be over complicated but should comprise of clean user-
interfaces which are easy to understand and navigate.
• NFR5 – Security: With many users using the services of the central server, user data should
remain accessible to only the relevant parties without the risk of breach.

4.7 Chapter Summary

The focus of this chapter was on the requirement gathering and requirement analysis components of this
research. The requirement elicitation was followed by defining Use Cases which included the Use Case
diagrams and Use Case descriptions. This allowed the Functional and Non – Functional Requirements to
be clearly understood. The following chapter will be used to formulate the system design specification
which will ultimately aid in the prototype implementation.

Design
5 Design

The previous chapter was focused on identifying stakeholders of the research, the ideal use-cases and the
functional & non-functional requirements concerning them. The current chapter will build upon what was
learned and focus on how the functionality of the proposed solution will be practically achieved. This
chapter will also elaborate on the design goals of prototype, its architecture, relevant UML diagrams and
UI mockups.
5.2 Design Goals

As in any research there are goals that are decided beforehand to be achieved by the conclusion of the
prototype development. In the case of this research they include;
• Usability: While the technical outcome of the project is to come up with an architecture, the final
goal is to breakdown complexity brought on by devices arranged in a hierarchical manner in an IoT
network. The best way this can be achieved is by providing the ability for users to visualize the
hierarchical data.
• Extensibility: The author’s architecture is intended to be a template. That is, it is platform and
product agnostic. Therefore, it is imperative that it be designed from the beginning to be easily
extensible. This includes having clean code, a well-organized architecture as well as
documentation.
• Documentation: At the conclusion of the research, the author intends to have a well-organized
documentation set to accompany the prototype.
5.3 Design Methodology

Two system design methodologies were considered for the designing component of this research. They
were the Object-Oriented Design (OOD) methodology and the Structured System Analysis Design (SSAD)
methodology. The two were reviewed objectively and each of their upsides as well as downsides considered
for the final decision.
5.3.1 Object Oriented Analysis and Design (OOD)

A battle tested methodology with many loyal followers, OOD has its basis on code re-usability. This
methodology is extremely popular among the software industry mainly because of this reason. The
methodology revolves around four key concepts (Din & Idris, 2009). They are;
• Encapsulation

Design
• Inheritance
• Abstraction
• Polymorphism
OOD aims to treat components within a system as objects and provides a way to add interactions among
those objects. This makes the systems highly modular.
5.3.2 Structured System Analysis and Design (SSAD)

While OOD prefers to break apart functionality into objects and interactions, SSAD follows a more
traditional flow which relies on a sequence of events happening in a predefined order. It is closely related
to the waterfall model in this regard. Unlike OOD, SSAD maintains focus on the data itself rather than how
it is manipulated within the system. This makes it extremely useful within systems that prioritize efficiency.
5.3.3 Selection of a design methodology

As mentioned in the Design Goals portion of the document, the author’s final implementation and prototype
are highly reliant on being extensible. Additionally, given the architectural basis of the implementation, it
would require that various aspects of the system be modularized so as to better streamline the final output.
It is also worth noting that more priority is given to the structural arrangement of the system than the actual
data being passed within it. Therefore, considering these factors and the overall goal the author’s project is
attempting to achieve, it can be concluded that the Object-Oriented Analysis and Design (OOD)
methodology would best suited for this research.
5.4 Approach
The primary goal of this research is to solve the inability of central cloud servers to understand hierarchical
device arrangements under it influence. Ideally this solution should be generic, easily replicable and
modifiable so as to ease adoption. Additionally, the solution should also be platform or technology agnostic.
Initially two approaches were identified as being best suited for this scenario. These approaches were
created upon studying existing IoT products/solutions and the methods those had taken to address network
complexity. This was performed in the Literature Survey component of this research.
5.4.1 Top – Down Approach

The Top- Down approach starts from the central cloud/server and makes it way down to the Edge Devices
located at the fringes of an IoT Network (RP, 2018). Here, device identification is taken place from the
perspective of the central cloud server. This is the more widely chosen approach as most IoT
implementations and products are Cloud centric (as in the case of Eclipse Kapua (Eclipse Foundation, n.d.)
and Microsoft Azure (Microsoft Corporation, 2018)).

Design
By using this approach, it is agreed upon that the central cloud server maintains a ledger on the exact
location of where a particular Edge Device exists within the network. This would ideally be similar to how
URLs enable locating web pages within a web server (Smith, 1996) and exposing their functionality via
endpoints. While not cloud centric, Mozilla’s Web of Things implementation had a similar feature where
devices connected to its Edge Gateways and even the Gateways themselves were exposed through REST
endpoints (Francis, 2017). This implementation is favorable due to its straightforward nature and the battle
tested principle of having resources being discoverable via URLs being implemented in the World Wide
Web already.
The main issue that arises in such an approach is scalability. In the case of Mozilla’s implementation, it is
ideal as it has an Edge Gateway centric philosophy without a central cloud (Francis, 2017). It has been built
with the intention of being small scale thus massive scalability won’t be an issue.
Enterprise grade central cloud servers and cloud centric IoT implementations do not have this luxury as
they involve massive amounts of devices being handled simultaneously.
5.4.2 Bottom – Up Approach

The inverse of the Top- Down approach involves taking the perspective of Edge Devices and Edge
Gateways when developing a hierarchical model (RP, 2018). This approach takes the liberty of making the
Edge Gateways maintain a record of all the immediate child devices connected to it (devices connected to
the Edge Gateway in the immediate lower level of the hierarchy). As per the example on Fig. 3; gateway1
would maintain a record of gateway2, device2 and gateway3. Microsoft’s Azure IoT implementation went
about this by having different Edge Gateway configurations (Transparent and Identity Translation) that
either masked the downstream devices by exposing only the Edge Gateway or masked the Edge Gateway
by making it an extension for connecting downstream Edge Devices with the central cloud (Microsoft
Corporation, 2018). As it can be implied from Microsoft Azure’s usage, this approach is ideal for Enterprise
grade central cloud implementations due to its extreme scalability.
The potential downside to this approach is the complexity that it incurs. Both the Edge Gateways and the
main central cloud should be in sync with the statuses of Edge Devices in the lower levels of the IoT
Network. Additionally, since the central cloud does not maintain a ledger of the devices’ location within
the network as in the Top- Down approach a mismatch can cause unforeseen issues.

Design
5.4.3 Proposal: Hybrid Approach

By studying the pros and cons of both aforementioned approaches, the author has concluded that a Hybrid
approach would be ideal for this research. This Hybrid approach aims to build upon the advantages of the
Top- Down and Bottom- Up methods and alleviate the downfalls as much as possible. Thus, the Hybrid
approach suggests that;
1. Similar to the Bottom- Up approach, Edge Gateways in the network track the immediate child
devices connected to a particular Gateway.
2. As in the Top- Down approach, the central cloud maintains a ledger of device details. Only, instead
of maintaining the location of devices within the network it stores metadata about the relationships
among devices.
Figure 4.1 indicated in the high-level architecture section showcases how the hybrid approach is intended
to function in a general sense. With the combined model of the two approaches, the central cloud is able to
maintain an understanding of the hierarchical arrangement with more integrity than found within a singular
approach. This is due to the fact that the Edge Device metadata stored within the central cloud can be
verified using the device records stored by Edge Gateways within the network.
The advantage of this Hybrid approach would be that it can work seamlessly with existing hardware
infrastructure (Edge Devices, Edge Gateways) with a majority of changes being required only on the central
cloud server middleware. Additionally, since this approach is system agnostic, it can be implemented as
seen fit within any product.
Additionally, by providing the central cloud with an understanding of how a hierarchical network is
arranged, functionality such as the following can be achieved;
• Ability to maintain a relational “map” of how the devices are arranged within the network.
• Ability to visualize how the devices are arranged via a “tree” map of sorts in the GUI to get a bird’s
eye view of the entire network.
• Ability to quickly detect and diagnose faults in both individual devices as well as entire Fog sub-
networks.

Design
5.5 Architecture
5.5.1 High - Level Architecture

By following the aforementioned hybrid approach, the author was able to create an architecture that satisfies
the problem identified. As the architecture itself is theoretical, in order to properly showcase its’
capabilities, the final prototype has been developed to include the following features.
• Ability for a central cloud server to understand hierarchy device arrangements under its influence.
• Ability to visualize the network arrangement.
• Ability to show real-time status of devices in the network via the visualization.
As mentioned at the end of the Literature Review section, the author selected an existing IoT product
(Entgra IoT Server) to build the architecture on. This selection was made based on several factors that were
discussed in that chapter.
The figure located in Appendix – High-Level overview of Hybrid Approach, showcases the high-level
arrangement of the architecture for the overall network.
While the hybrid approach suggested above gives a general idea as to how this architecture was created,
there are several other design decisions that were also taken upon the completion of the Literature Survey
by studying existing IoT products. Those design decisions are as follows;
• All devices directly or indirectly maintain persistent connections to the central cloud.
• Edge Devices (including Edge Gateways) can maintain only a single connection with another
device in the immediate upper layer of the hierarchy (a parent device).
• Relationships between devices existing in the same layer of the hierarchy are not acknowledged by
the central cloud server.
• Edge Gateways maintain some record of the Edge Devices (child devices) connected to them.
It should be mentioned that while some of these design decisions do involve the Edge Device and Edge
Gateway tiers as well, the focus of this research continues to lie on the changes made to the central cloud
server.
5.5.2 Rich Picture

Figure 5.1 shown below indicates how the architecture is arranged within the central cloud server. For the
purpose of modularity, the functionalities have been distributed into self-contained stacks. These stacks are
most analogous to that of an MVC model most often seen in web applications (Paul & Altar, 2013).

Design
Figure 5.1 - Architecture diagram and data flow of central cloud server
5.6 Class Diagram

Since the design methodology used for this research was Object Oriented, it is required that class diagrams
be used to describe the components required to create the prototype. The figure located in Appendix – Class
Diagram, shows the final class diagram used for the prototype.
5.7 Sequence Diagrams

There are 2 primary sequential flows that are involved in this architecture. Those flows have been identified
as primary due to the crucial functionality they provide for the proper functioning of the final prototype.
Those are;
1. The device enrollment flow – The flow used to connect a device with the central cloud server
2. The hierarchical data visualization flow – The flow used to retrieve hierarchical metadata from a
saved set of devices and present it in a meaningful manner.
The sequence diagrams have been designed to match these flows.

Design
Figure 5.2 - Sequence Diagram: Enroll Device
Figure 5.2 indicates the flow followed during the enrollment process of a device. The agent within a device
or another Edge Gateway initiate first contact with the server via an exposed public endpoint. This is with
the enrollment payload already prepared. The enrollment payload includes device data as well as
hierarchical metadata needed by the server. First the server will verify the credentials of the device to ensure
access rights, then the actual enrollment procedure will be initiated. The procedure includes extracting the
data within the enrollment payload and the forwarding it to the relevant CRUD operands.
Figure 5.3 - Sequence Diagram: Hierarchical data visualization

Design
Figure 5.3 showcases the flow followed when retrieving stored hierarchy related device metadata. First a
request is sent to a dedicated endpoint requesting data. This prompts a class in the Computation Layer to
run a method retrieving all the relevant stored data via a CRUD operation. Once obtained, the computation
layer performs some functions to make it presentable to the requirement. Any additional formatting is
performed on the Presentation Layer based on the needs of the requirement, be it the structural formatting
or streamlining the payload.
5.8 UI mockups
As mentioned in the Design Goals section of this document, one of the ways in which the author expects to
present the features afforded by the architecture is to have a UI visualization of the network structure. Prior
this implementation a UI mockup was created in order to showcase what the final output would look like.
The figure located in Appendix – UI mockup of hierarchical visualization, indicates such a mockup created
to get a sense of what the final output.
When selecting a particular visual style to showcase the network arrangement, the author took inspiration
from the Mind Map knowledge representation tool (Wickramasinghe, et al., 2011). This style was selected
due to its established pedigree as a method that enables understanding complex concepts easily and in a
short period of time (Eppler, 2006).
5.9 Chapter Summary

This chapter outlined the Design aspect of this research. First the design goals of the research were discussed
followed by the selection of the most suitable design methodology. Thereupon, the approaches followed by
the author when coming up with the architecture were discussed. The author also elaborated a new hybrid
approach and the decisions taken when coming up with it. This led to the discussion of the actual
architecture and how the network structure is arranged. A Rich-Picture diagram provided additional context
to how the central cloud was arranged within the architecture as that is the focal point of this research.
Thereafter class diagrams and sequence diagrams were brought forward. The chapter concluded with a UI
mockup showcasing what the final hierarchical visualization would look like.
With the completion of the Design chapter, the following chapter will focus on the actual implementation
of the prototype based on the goals and decisions outlined in this chapter.

Implementation
6 Implementation

In the previous chapter the Design decisions taken with regard to the final prototype were discussed. This
chapter will build upon that discussion and elaborate on the implementation of the actual prototype. This
chapter will also focus on the algorithms and other programmatic decisions that were taken during
implementation. Any problems encountered will also be discussed and the steps taken to mitigate and
address them would be taken into attention as well.
6.2 Derived Architecture

As mentioned in the Design chapter, the Hybrid approach for developing the architecture included 2 rules.
They were;
1. Edge Gateways in the network tracking the immediate child devices connected to a particular
Gateway.
2. The central cloud maintains a ledger of device details. Only, instead of maintaining the location of
devices within the network it stores metadata about the relationships among devices.
By following these rules, the author was able to create an architecture consisting of a parent-child
association between devices in the network. This is also where the “metadata” component comes in. Any
single piece of equipment that carries a set of pre-defined identifiers and can connect with the server would
be acknowledged by the central server as a “Device”. The metadata in question would include;
• Details about the identity of each Device in the network.

• Details about the immediate parent [Device] a certain device is connected to.
This metadata would be passed to the server at the moment of first contact and enrollment. This bundle of
metadata would be referred to as an “enrollment payload”. A simulated network located in Appendix –
Mock network diagram showcasing parent-child architecture, depicts this “child-parent” arrangement as
well as the manner in which the metadata is arranged within devices as well as the central server. Ideally a
Device would communicate to the central server who its’ parent is at the time of first contact. But this is
not enforced strictly and is rather a design choice.
Once the connection has been made and the device successfully enrolled, the central server stores the
association as hierarchical metadata. This is performed on the Persistent Storage layer that was mentioned
in the Design chapter. It should also be noted that it isn’t always mandatory for the actual Edge Device to

Implementation
be the one passing the enrollment payload. In instances with weak devices (such as Micro-Controllers with
little processing power) the parented Edge Gateway would perform the enrollment on behalf of the device.
By using this “parent-child” approach the central server can maintain a map on the entire network
infrastructure under its influence. It can also dynamically adjust it depending on changes in the network
such as a single device or whole fog network (controlled by a gateway) going down.
The activity diagram located in Appendix – Metadata acquisition and storage flow elaborates on how the
sequence of events take place starting from the point of enrollment of a device up to the metadata being
persisted in the central server persistent storage.
If looked at it closely, one can notice that the activity diagram in Appendix – Metadata acquisition and
storage flow, is actually one half of the data flow described in the architecture diagram shown in Figure
5.1. The execution begins once a device requests enrollment. After credential verification takes place the
actual enrollment payload is received by the server. Then the payload is deserialized and the contents
extracted to be passed onto the CRUD layer. This is where finally the required operations will be performed,
and the extracted metadata will be stored in the Persistence layer.
6.3 Selection of Technology
6.3.1 Preliminary decisions

With the architecture established and the basic logical flow figured out, it is now possible to consider
options for implementation.
When it comes to the prototype, the author can take dual approaches. Either a brand-new implementation
can be made from scratch including all the aspects of the architecture, or an existing IoT product can be
modified to include the architectural implementation. The review of these approaches can be observed in
Table located in Appendix – Approach comparison for implementation.
Upon studying the advantages and disadvantages provided by each approach, the author has evaluated that
the pros provided by implementing the architecture on an existing product outweigh the cons. This would
obviously need to come at the condition that the selected existing IoT product be open source so as to allow
changes to the codebase.
6.3.2 Review of suitable IoT products

In the Literature Survey of this research the author studied several existing IoT products and noted each of
their features. Thereafter those products were compared and contrasted, and their features were considered
based on the advantages and disadvantages they provided. The IoT products that were studied were;

Implementation
• Microsoft Azure IoT

• Mozilla Web of Things
• Eclipse Kapua
• Entgra IoT Server
The purpose of that study was to identify how Fog Networks were implemented and handled in existing
IoT products. The findings provided by the Literature Survey enabled the author to formulate a hybrid
approach to come up with a viable architecture that was discussed in the Design and the Implementation
(current) chapters respectively. Additionally, this study provided insight into what products would be most
suitable when it comes to implementing the authors’ proposed architecture. A quick summary of the insights
(which were previously observed in-detail in Appendix – Reference architecture feature comparison) are
reconsidered below in Table 6.1 with more detail provided to the pros and cons. It should be noted that the
Microsoft Azure IoT product has been dropped from this shortlist as it fails the requirement of being open
source.
Mozilla Web Things Eclipse Kapua Entgra IoT Server
Pros • Product uses a novel • Standardized and well • Standardized and well
Gateway based approach. established. established.
• Simplistic design and • Build atop proven and well • Build atop proven and well
technology stack. tested technologies. tested technologies.
• Well documented and
maintained code
Cons • Gateway based approach • Default product is very • No standard support for
might be too novel and barebones. Edge Gateways.
controversial. • Not well documented. • Complex and dense stack
• Still relatively new and • Complicated and dense with several inter-reliant
growing. technology stack which is technologies.
reliant on other Eclipse
based technologies for
proper functioning.
Table 6.1 - Merit based IoT Product comparison

Implementation
6.3.3 Selection and Justification

By considering all the above pros and cons the author has concluded that the Entgra IoT server is the most
ideal product to base the architecture on. This decision was based on several factors in addition to the pros
mentioned above. Those include;
• A strong platform presence – Of all the open source products that were observed Entgra IoT
server had the strongest positioning as a platform as well as being an IoT middleware product. This
is extremely useful for the purposes of this research implementation as it supports the architectures’
Design goal of being extensible.
• An analogous software stack – As showcased in Figure 5.1, the functionality of the architecture
was scattered across several layers to improve modularity. Entgra IoT server consists of a software
stack that is very similar in nature to this layered arrangement. This further aids in the
implementation as the functionality in the layers can be matched 1 to 1 with the existing stacks
without overlap or conflict. These stacks and their functionality will be discussed in the upcoming
sections. This brings up the next point…
• A traditional application structure – Entgra IoT server comprises of a class middleware structure
with a stacked arrangement. Unlike Mozilla’s novel implementation or Kapuas’ barebones
structure, the traditional arrangement works to the advantage of the architecture. This is due to the
fact that this prototype would work as a blueprint which can be used by other potential products to
base the architecture on. This aids in the author’s Design goal of the architecture being easily
adoptable.
6.4 Implementation Overview

Following the choice of IoT product made the author will now be attempting to deconstruct the contents of
the Entgra IoT server product in order to go about implementing the proposed architecture.
6.4.1 Product Overview

Before dwelling into the software stack, first the construction of the product needs to be discussed. Entgra
IoT server consists of 3 Maven repositories which need to be built in sequence in order to get a final built
“pack” of the product. The repositories each have their own delegated purpose. They are as follows, the
order being the sequence by which each repo should be built;
1. carbon-devicemgt: This repository contains the core functionality such as Device Management,
User management etc.

Implementation
2. carbon-devicemgt-plugins: This repository contains the “plugins” that provide platform

specific functionality to be consumed by Edge Device agents. Supported platforms include
Windows and Android.
3. product-iots: This repository contains additional components offering additional functionality
and the integration tests for the APIs created in the carbon-devicemgt repo.
Since the author’s implementation would be working at the core level with the architecture residing and
accessing functionality at the very lowest layers, the majority of development will be taking place on the
carbon-devicemgt repository, with some additions to the other repos based on need.
The technology usage of the product is as follows;
• Predominantly used backend language – Java

• Predominantly used front-end language – JavaScript
• Dependency management and build system – Maven
• Database storage – H2 database
• API endpoints – HTTP REST
6.4.2 Application Stack
Figure 6.1 - Software Stack of Entgra IoT server
As mentioned prior, Entgra IoT server consists of a stack that is very much similar in nature to layered
architecture the author is proposing. Figure 6.1 showcases an overview of how the software stack in the

Implementation
product is arranged. The similarities between the stacks and the architectures is also studied in the table
located in Appendix – Software stack vs Architecture layers arrangement.
Prior to starting actual development work, the author specified several rules to be followed when
implementing the architecture atop the Entgra IoT server product. Those rules are as follows;
1. The inclusion or implementation of the hierarchical device architecture should not conflict with or
interfere with the existing functionality of the product.
2. The features provided by the proposed architecture should complement the existing feature set.
3. The newly coded components need to conform to the programming paradigms already established
by the developers of the product.
4. None of the existing Edge Device agents (Android) should require to be significantly altered to
accommodate the inclusion of the new hierarchical architecture.
The purpose of creating these rules is to establish the newly added author’s architecture as a complimentary
part of the product and not a hindrance or barrier to already existing features. If otherwise, the architecture
would fail the author’s predefined design goals of being product and platform agnostic.
6.5 Features and Core functionality

When implementing the prototype, the author had to consider 2 individual components with regard to the
actual functions they perform. They are;
1. Server based implementations to integrate the proposed hierarchical architecture onto the Entgra
IoT server.
2. Edge Device based implementation to showcase how an Edge Device functioning within a
hierarchical device arrangement performs when interacting with the new architecture.
First the server-based implementation would be discussed as it is the core aspect of this research, followed
by the Edge Device implementation which provides additional context.
6.5.1 Server-based implementation

As mentioned earlier when it comes to the functionality, each function is defined and exposed via an
independent REST endpoint. The reason for using REST is due to the fact that the Entgra IoT server already
uses HTTP REST (WSO2, 2018) to expose functionality to external parties. Accordingly, when the initial
planning was being performed the functionality that was going to be provided by the hierarchical
architecture were listed down and matched with an associated endpoint. Table 6.2 shown below lists down
2 of the major functionalities provided by the hierarchy against their associated REST endpoint.

Implementation
Functionality Associated Endpoint
Get a visualization of the https://...url.../hierarchy/graph

hierarchical arrangement of the
network.
Get all the upstream parent https://...url.../hierarchy/{deviceId}/upstream

devices a child is connected to
in the hierarchy
Table 6.2 - Functionality provided by hierarchy with associated REST endpoint
While many other functionalities can be implemented and exposed by use of the proposed architecture (i.e.:
getting the immediate parent a device is connected to, getting list of child devices connected to a parent
device) the author decided to elaborate specifically on the 2 shown above due to the fact that they better
emphasize its capabilities better.
Other than the 2 functionalities mentioned above which are strictly related to the hierarchical architecture,
there also is an endpoint to enroll devices. While that endpoint is already existing within the product, it has
been updated and altered to accommodate the newly added hierarchical metadata that would be passed to
it (via the enrollment payload) when a new device is being enrolled.
With the main functionalities provided by the architecture established the focus can now be put squarely
on how the implementation was done. This will be done step-wise with the 2 most important functionalities
crucial for the architecture being used to describe how the implementation was done. The 2 most crucial
functionalities being;
1. Enrolling a device to Entgra IoT server

2. Acquiring a visual overview of the hierarchical device arrangement to be presented via a GUI.
6.5.1.1 Enrolling a Device

The purpose of this function is to enroll a new device with the server. This includes accepting the enrollment
request, receiving the enrollment payload and manipulating the metadata acquired. The first step of this
process is obviously involving the exposed REST endpoint which is used by new devices to enroll with the
server. Therefore, the author will be going through the analysis the device enrollment functionality
beginning from the API layer and making way down to the Storage layer (DB).
Swagger annotations are used to define the scopes and the root paths of the endpoints. To provide some
context, Swagger is a tool used by developers to design, build and document RESTful web services

Implementation
(Maltseva, 2018). The Entgra IoT server also happens to use this framework for defining endpoints as it is
very robust and easy to use.
This is all done within a Java interface class. The response is also defined within the same interface right
after the annotations as show in Snippet 6.1.
Snippet 6.1 - Enrollment Response is defined in the interface
Thereafter a class implementing that interface is defined. It is within this that the actual implementation of
the response method is placed. This interface-implementation programming model is followed throughout
the Entgra IoT product including the classes in the OSGi layer and CRUD layer.
As it can be seen when studying the code, the Device parameter is actually a Java bean class the device
metadata payload is deserialized into. This makes it easier to manipulate within the code. But it includes all
Device related metadata. Including the hierarchical metadata among this would make the payload bloated
and increase confusion.
Fortunately, the Entgra IoT server product contains additional metadata related to the enrollment within
this device metadata payload. Therefore (with respect to the rules established in section 6.4.2) the author
decided to include the required hierarchical metadata within this existing payload. While the actual payload
will be studied in more detail in the section about the implementation of the Edge Device agent, for the
time being, the server-side manipulation of the metadata can be discussed.
The Java bean class which includes the hierarchy specific metadata in shown in Snippet 6.2. Since this class
did exist prior to implementing the architecture, the author merely required to add the metadata attribute
referred here as parentId. It can be seen additionally that this class can been annotated with JAX-RS
annotations. JAX-RS is a Java API that supports creating web-services, which includes easily manipulatable
object classes that can be used for serialization and deserialization. Hence, also why this class implements
the Serializable interface native to Java.

Implementation
Property that defines the enrollment

ID of the associated parent device
Snippet 6.2 - Bean class including EnrollmentInfo metadata and Hierarchical metadata
With the data received, it can now be computationally operated on. After the OSGi level enrollment method
is declared via an interface and it is implemented with the actual logic. An object based on the class
EnrollmentInfo is used by a DAO method for this purpose. This is the OSGi layer communicating with the
CRUD layer of the product (also referred to as the DAO layer) to save the received enrollment metadata in
the persistent storage.
This of course leads us to the CRUD layer of the product. It is here that actual SQL operations are run on
data.
Snippet 6.3 - DAO enrollment method declaration from interface

Implementation
Code portion that

accommodates the
newly added parentId
field into the DAO
method
Snippet 6.4 - DAO enrollment method implementation
As it can be seen from Snippet 6.4 (which has been implemented from the Java interface method in Snippet
6.3), after the data has been extracted from the payload and set into an object of type EnrollmentInfo,
that metadata (which is stored volatile in-memory) is extracted once again from that object and saved in
persistent storage. The attribute that is necessary for the hierarchical implementation; parentId, can either
be set as null or if empty or set with the value retrieved.
The purpose of supporting the null value is due to the fact that sometimes devices connect that do not have
a parent device. Here, it can be logically implied that the parent device is in fact an instance of the Entgra
IoT server itself therefore the device is directly connecting to the server. By setting this null value as a 0, it
becomes extremely easy to identify the hierarchical “root” when generating visualizations later.
All these operations performed by the DAO layer are finally run on DB tables which are created by
scripts at the point of server startup. Those scripts have been accordingly updated to include the

Implementation
hierarchical metadata required by the architecture. The script used by the EnrollmentInfo storage table is
shown in Snippet 6.5.
Parent ID field added to the DB

script so that an extra column can
be created when the script is
initialized on first server start-up
Snippet 6.5 - H2 SQL script used to create DB table for EnrollmentInfo
With this the process of enrolling a new device with the server is concluded. If successful, each method so
far interacted with will pass the success return type up the stack which will finally be output as a HTTP
code:200 response from the API layer. If otherwise, an appropriate error response (either 404 or 500) will
be returned (Mozilla Developer docs, 2019).
With the Edge Device enrollment flow established, attention can now be given to the flow used for
retrieving the hierarchical visualization.
6.5.1.2 Generating payload for Visualization of network Hierarchy

The purpose of this function is to generate a visualization of the hierarchy similar what was depicted in the
UI mockup shown in Appendix – UI mockup of hierarchical visualization. This flow includes
1. Gathering the stored hierarchical metadata from DB tables

2. Extracting the relevant table data
3. Computing the metadata
4. Formatting metadata and presenting to the UI layer
It should be mentioned that in this scenario, the formatting and final output of the data is highly reliant on
the tools and libraries that was used to generate the hierarchical visualization. More details on the tools
would be discussed in the upcoming sections in this chapter. It should also be noted that similar to the
enrollment methods (and most other methods in the product) the methods involved with the hierarchical

Implementation
generation also follow the interface-implementation structure. Only the code snippets involving the
implementation has been included here due to space constraints.
As mentioned above, the first order of business is to extract the data stored in the DB tables.
2 methods have been shown in the code snippet located in Appendix – DAO layer methods to extract
enrollment metadata from persistent storage. While there are other methods written specifically to extract
all Device related metadata etc. these methods have been specifically written for the purpose of extracting
the hierarchical metadata. This extracted data is called by methods existing in the OSGi layer.
The code in Appendix – OSGi method to retrieve all stored EnrollmentInfo metadata of devices, shows the
DAO method mentioned prior being executed by the OSGi layer to gather the required stored metadata.
Additionally, the code in Appendix – OSGi method to return list of upstream parents a child device is
connected to, showcases a more computationally complex function that is used to gather the list of upstream
parent devices a child device is connected to and the associated “state” of those upstream parents. As a
thumb rule, a significant portion of the computation work was worked within the OSGi layer to decrease
response times and increase performance in general.
After all the required data has been gathered and put into relevant data types/formats it can now be accessed
by the API Layer code.
The code in Appendix – API layer code to generate payload required for UI, shows the final implementation
of the API level code used to push a formatted JSON payload to the front-end UI. Although previously it
was stated that the architecture was written to be as product agnostic as possible, in this case that rule had
been violated due to technical constraints. While the presented JSON payload which is generated from this
endpoint is highly dependent on the requirements of the front-end it should be noteworthy that the developer
has the freedom to customize the payload however required. Therefore, the author would prefer to
categorize it as a compromise that has occurred when developing the prototype.
An example of what of the generated JSON payload would look like (as obtained from the console log in a
browser) is shown in the code snippet located in Appendix – Payload generated for the use of hierarchical
visualization library.
6.5.1.3 Visualization generation

The author decided to delegate a separate section for the UI generation component as it exists as a separate
entity from the rest of the functionality of the central server.
To start off, the author had intended that the UI be as similar in appearance to the mock shown in Appendix
– UI mockup of hierarchical visualization as possible. Therefore, a visualization front end library capable

Implementation
of the requirement had to be found. Upon doing some research 2 ideal libraries were shortlisted as suitable
for this use-case. Those 2 libraries were compared based on the merits they provided in order to better judge
what the most suitable one would be.
SigmaJS vis.js
Pros • Lightweight • Feature rich

• Specialized specifically for • A lot of options and functionality that can
network visualization use- be used for visualizations
cases • Straightforward HTML <canvas> based
implementation
• Better documentation
Cons • Low on features • Less performant (consumes more

• Not-so-straightforward resources)
implementation • Somewhat less stable
Table 6.3 - Visualization front-end library comparison
Based on the above comparison it was clear to the author that the vis.js library would prove to better for
this implementation simply due to the fact that it had a lot of well documented components and had more
features and flexibility with regards to the actual UI generation.
After the library selection, attention can now be given to the complete frontend development. As mentioned
in the initial thumb-rules, it was the authors intention to not make the existing features redundant or conflict
with them. The front-end was written by respecting these preset rules as much as possible.
Figure 6.2 - The file structure of a front-end page

Implementation
Entgra IoT server makes use of a front-end templating framework known as UUF (Perera, 2018). This
framework is actually built atop another templating engine known as handlebars.js. The files using it have
the extension; .hbs. The purpose of using such a tool is to accomplish the goal of having dynamic elements
in web pages (Manricks, 2013).
UUF requires that individual pages displayed at Entgra IoT server runtime conform to a structure as
depicted in Figure 6.2. Here, the actual front-end code is located in the device-hierarchy.hbs file and the
client-side JavaScript code included in client-script.js file.
As mentioned in Table 6.3, the vis.js library is perfectly capable of working on a <canvas> HTML
element. This is indicated in the code shown in Appendix – Front-end code markup. All the components
thereafter are manipulated and controlled via the client-side JS script.
As indicated in the code in Appendix – Client-side JavaScript code used for UI generation, the Entgra IoT
server front-end contains a native function known as invoker-util which enables the front-end to access and
use APIs without the constant need to generate refresh tokens. In the code that’s shown, the invoker-util
function is used to call the hierarchy visualization generation endpoint which retrieves the required payload.
This is then formatted some more based on the requirements of the library and finally visualized as shown
in Figure 6.3.
Figure 6.3 - Final output of the visualization with device details
6.5.2 Edge Device implementation

With the basic implementation of the Server-side established, it is now possible to look into how the Edge
Device agent was implemented to simulate the functionality provided by the architecture.

Implementation
The Entgra IoT server supports a variety of different Edge Device platforms such as Android, iOS and
Windows. There are pre-made agents (apps) that run on these devices which communicate with the server.
However instead of working with an existing agent, the author decided to try a different approach. The
author concluded that it would be more ideal to implement the Edge Device agent on a lesser known
platform. By doing this the author suggests that it would better emphasize the architectures’ ability to work
with the lowest common denominator and a variety of different variables. This would in essence strengthen
the case of true product agnosticism the author is seeking to achieve with his solution.
The author identified 2 such lesser known platforms that were deemed most suitable for the implementation
of the mock Edge Device agent. Those 2 platforms were compared based on their merits to properly judge
which would be most suitable one.
LG webOS Open Source Edition Samsung TizenOS
Pros • Strong developer documentation • Running on several Samsung

• Stable and rich development tools products therefore quite stable
• Easy development process for apps • More modern
• Specialized for IoT devices
Cons • Lacking in certain features • Weak documentation
• Extremely stringent hardware • Not a very strong suite of Developer
requirements tools
• Not a large developer community
Table 6.4 - Comparison of features provided by Edge Device platforms
Upon further deliberation the author decided that the platform of choice would be LG webOS Open Source
Edition. There are multiple reasons for selecting this platform beyond the pros mentioned in Table 6.4.
• Although it is lesser known there’s a large developer community surrounding it. This has resulted
in lot of well documented code and online support.
• While previously it was a closed source proprietary product that was owned by Palm.inc and later
acquired by LG electronics, recently it was made completely Open Source under the Apache 2.0
license. This further aids in the fact that there is first party support for developers who like to
experiment with the platform.
• It is an extremely easy platform to develop on as apps can be simple web apps written using web
technologies such as JavaScript and HTML.

Implementation
After the platform selection the author began development on the Edge Device agent. As this is a mock
application and beyond the actual development scope of the project, the author intended to include the basic
functionality required and avoid any superfluous features.
Accordingly, the most basic functionality that could be achieved by an agent on an Edge Device would be
enrollment with the Entgra IoT server. This functionality can be broken down into a sequence of events as
follows;
1. Pass user credentials to server and obtain client key and secret – Since APIs cannot be given access
freely (as it can cause a security issue) in order to access them an oAuth app must be created with
the authorized user credentials (Chen, et al., 2014). This outputs a sort of username and password
in the form of client id and secret respectively which allow access to this app and the APIs that
have subscribed to it. It is in this step that the User Verification discussed in Figure 5.2 takes place.
2. Use the obtained client secret and id to get a refresh token – Once the client secret and id are
retrieved they can be used to obtain a refresh token. This refresh token can thereafter used to
communicate with the server and access endpoints.
3. Pass the enrollment payload to the server – By using the refresh token that was obtained in the
header, a payload can be passed to the Entgra IoT server via an exposed endpoint to complete the
enrollment procedure.
As mentioned previously, since the webOS apps can be developed on web technologies, JavaScript was
used to write a programmatic flow for each of the above steps.
Snippet 6.6 - JavaScript function used to gather user credentials
Snippet 6.6 shown above showcases how the entered user credentials are retrieved from the UI and passed
to the function responsible for retrieving the client secret and id.

Implementation
After the client secret and id are retrieved as show in the function in Appendix – JavaScript function to
retrieve client-secret and client-id, the immediate next step is to obtain a refresh token so that the actual
enrollment can be performed by passing the data to the relevant endpoint.
Once the refresh token has been obtained successful as depicted in Appendix – JavaScript function to
retrieve refresh token, finally enrollment payload can be sent to the server with all the relevant device
details to complete the full enrollment procedure.
Payload
consisting of
device details
Snippet 6.7 - JavaScript function used to pass enrollment payload to server
Snippet 6.7 denotes the actual enrollment payload that had been referenced prior in sections 6.5.1.1 and 6.2.
This payload consists of the actual device details that have been populated using data obtained from native
methods. The highlighted portion contains the field through which the parent ID field is passed. This field
can be also left empty or completely removed (as in the case of a device that directly connects with the
Entgra IoT without an intermediary parent). The final UI of the developed IoT Server is as indicated in the
figure in Appendix – Screenshot of Edge Device agent on webOS running on an emulated device provided
by the webOS SDK.
6.6 Chapter Summary

This chapter covered several of the design decisions that were taken with regards to the implementation of
the prototype for this research. Initially the complete proposed architecture was discussed and the various

Implementation
approaches that can be taken to implement it were discussed and argued. Thereafter the various IoT products
that could be used to support this architecture were elaborated and a suitable product chosen at the end
based on suitable merit. The main core functionalities were elaborated on with the programmatic
contributions in each being shown using code snippets. At the conclusion of the chapter, a working version
of the prototype was implemented successfully.
The next chapter would be involving Testing and how the implemented architecture was tested. It would
describe the testing methodologies followed, the test cases and the final results obtained.

Testing
7 Testing

In the previous chapter the implementation of the prototype required for the author’s research was focused
on. With its conclusion, the implementation was finalized. Now what remains is to study it’s effectiveness
by the use of testing, which would be the focus of this chapter. Effective testing not only helps understand
the success or failure of a project but also helps improve on the discovered deficiencies and amend them.
This chapter will discuss the testing methods and strategies that were used as well as the results that were
obtained against what was tested.
7.2 Goals of Testing

As mentioned previously, the main goal of testing is to verify whether the system is working as intended.
In a micro level this means the relevant input should result in the intended outputs. Considering that the
author’s architecture has also been implemented within an existing product that wasn’t designed to support
it natively, bugs and errors are bound to pop-up. The following goals have been identified to be achieved
in order to reduce the amount of software faults as much as possible.
• Satisfying the Functional Requirements

• Completion of the stated Non-Functional requirements
• Satisfying additional project specific requirements
7.3 Testing Methodology

Before committing to the actual testing first a testing methodology needs to be formulated. This helps
structure which tests need to be performed first and gives the procedure some order. Table 7.1 given below
is a summary of the testing methodologies that were followed for testing the functionalities of the prototype
TM No During Development
TM1 Unit Testing
TM2 Integration Testing
TM No After Development
TM3 Functional Testing
TM4 System Testing

Testing
TM5 Quality Testing
1. Performance Testing
2. Usability Testing
3. Reliability Testing
Table 7.1 - Selected Testing Methodologies
7.4 Execution Environment

Entgra IoT server is both optimized to work on a relatively capable PC with mid-tier specs as well as on
high end server grade equipment. Due to variety of tests involved, some were accordingly performed on
the authors’ own personal laptop and others on a remote server instance. The specs of both environments
are depicted in Table 7.2.
localhost remote
Processor Intel Core i5 – 2.2GHz Intel Xeon – 2.5GHz
Memory 12GB 15GB
Storage 10GB Dynamic
Table 7.2 - Spec listing of localhost and remote environments
7.5 Test Execution and Results

This section studies how the previously discussed test methodologies were followed, how the tests were
conducted, and the results gained. In some instances, the measures taken the accomplish the tests would
also be discussed.
7.5.1 TM1: Unit Testing

This was the most initial type of testing that was performed. The most fundamental operation within the
Entgra IoT server product are the ones located in the DAO layer that communicates with the DB tables. By
unit testing components and methods in this layer much of the issues that can arise from higher layers (such
as the API layer) can be mitigated. This is due to the fact that most often errors can occur to do simple
factors such as incorrect exception handling. A simple error in the lowest level of the program could cause
a snowball effect, with cascading errors that might hinder other unrelated parts of the system as well. Proper
unit testing would address that.

Testing
Since the product the author decided to build the architecture on (as discussed in section 6.3.1); Entgra IoT
server, is already large and complex and is production grade, it already utilizes tools to perform unit testing.
One such tool is a TestNG. It is a testing framework for Java based projects. TestNG allows for unit testing
to be performed easily and also to automate tests. Accordingly, the product is designed such that unit tests
are run during the Maven build and unless all tests pass the final pack is not created. Additionally, since the
developers of the Entgra IoT server had already created several unit tests to check the functionality of
existing features they needed to be modified accordingly to support the inclusion of the architecture without
resulting in build failure. The author also wrote additional unit tests to check newly created DAO methods
that were used by the architectural implementation.
This kind of testing can be mostly attributed to White Box testing
7.5.2 TM2: Integration Testing

Similar to unit testing, the Entgra IoT server also comes pre-loaded with a way to perform integration tests
as well. While unit testing checks the functionality of micro level functions taking place in the lower layers
of the product, integration tests cover more macro level operations and the best way through which these
can be reached is using the exposed APIs.
While the unit tests that were covered earlier was relegated to White Box testing, the integration tests can
be assigned to Black Box testing as the tester need not be aware of the actual logic that is taking place
inside. A simple tool such as a CURL or Postman can be easily used to manually test the functionality of
each exposed endpoint one by one. But given that Entgra IoT server contains over 40 different endpoints,
the manual process becomes tedious.
Fortunately, similar to how unit testing was automated; the Entgra IoT server also includes a way in which
integration testing could be done autonomously. By use of a Java testing framework known as JMeter the
product tests each of the endpoints during the Maven build. More specifically, the tests are run once all the
repos (as mentioned in section 6.4.1) have been built and testing framework temporarily starts up the server
to run the integration tests. If even one fails, the entire build fails. Accordingly, as per the thumb-rules
outlined in section 6.4.2, the author implemented JMeter test scripts for the newly implemented architecture
related endpoints to be run alongside the already existing scripts.
7.5.3 TM3: Functional Testing

Functional testing is directly related to the main functionalities expected out of a certain system. It is a form
of Black-Box testing that goes through each feature of the solution on per-functionality basis testing one
after another (Guru99, n.d.). Functional testing ensures that the final prototype operates in conformance
with what was outlined in the Requirement Specification (see Chapter 4). It does not focus on the accuracy

Testing
of the results or any performance metrics, rather it simply checks if there are any errors of defects with
regards to the output received.
When taken in terms of the author’s research it tests all the main functions of the proposed architectural
arrangement that was outlined in the SRS. It does not require all components be fully integrated but given
the nature of the implementation of this research (which is an existing IoT product with components having
inter-related functionalities) the integration was prevalent regardless in most instances. In some instances,
it can be seen that there is some overlap of the tested functionalities with the functional requirements testing
in the system testing section. This is to be expected since sometimes some core functionality has been in
fact defined as functional requirements beforehand. The functionalities tested are outlined in Table 7.3
given below.
An in-depth version of this table can be found at Appendix – Detailed Functional test cases.
Id Functionality Test Case Result Pass rate
F1 Verifying user credentials Sending enrollment request to server with Pass 100%
of device user credentials from Edge Device
F2 Enrolling a device Sending enrollment payload to server from Pass 100%

Edge Device
F3 Retrieving enrolled Accessing required REST endpoint to Pass 100%

device provide device details
F4 Retrieving hierarchical Retrieving all upstream parents of an Pass 100%

metadata from enrolled enrolled device
device
F5 Visualizing hierarchical Getting hierarchical network arrangement Pass 100%

network arrangement under the influence of the server
Table 7.3 - Functional Testing results
7.5.4 TM4: System Testing

System Testing is Black-Box testing method used to test a fully integrated prototype with ideally all
functionality operational. It most often is tested against the functional requirements pre-defined in the
project requirement specification. The table given in Appendix – System Testing results summarizes the
outcomes of the System Testing that was carried out in the prototype for the author’s research.

Testing
7.5.5 TM5: Quality Testing

With the Functional Requirements tested and results gathered, it is now possible to move onto the Non-
Functional requirements. This is where Quality testing is performed. Out of the Non-Functional that were
discussed by the author in section 4.6.2, the testing would focus on those coming under the areas of
Performance testing, Usability testing and Reliability testing. Each of those testing setups would be
performed in while comparing to the Non-Functional Requirement the methodology most closely relates
to.
Prior actually performing the test, it should be mentioned that the author implemented the proposed
architecture via an existing IoT product (known as Entgra IoT server) for reasons mentioned in section
6.3.1. Therefore, unlike implementing the architecture on a standalone product, where the performance
metrics are directly related to the actual implementation, in this case special care had to be taken not to
degrade the current performance of the product. This mindset was established while going about the
implementation in addition to the implementation specific rules that were outlined in section 6.4.2.
7.5.5.1 Performance Testing – Phase 1

In the Non-Functional Requirement list, Performance is mentioned as NFR2. It is accompanied with the
description that the final prototype would require to function effectively without any lag or slowdowns.
Therefore, this is what would be tested in this section to see if the inclusion of the hierarchical architecture
within the product has affected the previous values. While testing these metrics in an isolated environment
running as localhost on the author’s personal computer is possible it provides only a partial picture. Also,
with such a setup the range of the metrics that can be obtained is also limited given hardware constraints.
Therefore, while some of the tests were performed on localhost in the author’s machine, others were done
on a remote server with significantly more processing power as noted in Table 7.2.
The Performance test works by running a test script on a deployed server simulating the required tasks. The
tasks that are tested by the server are as follows;
1. Register App
2. Generate Access token
3. Enroll device
4. Run operation
The response times were then recorded for each task. The test was performed in 3 rounds on a product pack
(refer section 6.4.1), one containing the architecture implementation and another that has been untouched.

Testing
The test was also conducted on both localhost and remote server environments. To maintain consistency
the versions of both tested packs were also kept the same.
Testing on localhost
As mentioned earlier, due to the hardware limitations the flexibility of testing that could be performed on a
localhost were low. Hence the no. of scripted devices that were being enrolled to test response times were
limited to 1000.
Round 1 Round 2 Round 3 Average
Register App 1492 1239 1167 1299.333
Generate Access Token 302 283 297 294
Enroll Device 71 52 63 62
Run Operation 37 26 24 29
Table 7.4 - Performance metrics of default product on localhost
Register App 1429 1255 1328 1337.333
Generate Access Token 290 290 291 290.3333
Enroll Device 81 51 69 67
Run Operation 48 23 27 32.66667
Table 7.5 - Performance metrics of product with proposed Architecture on localhost
The data shown in Table 7.4 and Table 7.5 indicate the metrics obtained by running the script on a product
pack as default and with the proposed hierarchical architecture respectfully. It should be reiterated that all
data mentioned is indicated in millisecond units. A graphical representation of this data is indicated below
in Figure 7.1 and Figure 7.2.

Testing
Performance metrics of default product on

localhost - (ms)
2000
1500
1000
500
0
Register App Generate Access Token Enroll Device Run Operation
Figure 7.1 - Performance chart of default product on localhost
Performance metrics of product with proposed

architecture on localhost - (ms)
1600
1400
1200
1000
800
600
400
200
0
Figure 7.2 - Performance chart of product with proposed architecture on localhost
Testing on remote server

With the testing on the localhost complete, it was time to compare performance of both versions of the
Entgra IoT server in a remote server. For this test, the same scenarios as the localhost testing were followed
with the only differences being that;
1. It was run on an AWS (Amazon Web Services) instance

2. The number of devices being mocked and tested was increased to 20000 (up from 1000) due to the
additional performance afforded by the more powerful hardware.

Testing
Register App 1336 1050 1175 1187
Enroll Device 60 54 55 56.33333333
Table 7.6 - Performance metrics of default product on remote server
Register App 1470 1235 1137 1280.667
Enroll Device 55 49 50 51.33333
Table 7.7 - Performance metrics of product with proposed Architecture on remote server
The data shown in Table 7.6 and Table 7.7 indicate the metrics obtained by running the script on the remote
server. A graphical representation of this data is indicated below in Figure 7.3 and Figure 7.4.
Performance metrics of default product on remote server

- (ms)
1600
1400
1200
1000
800
600
400
200
0
Figure 7.3 - Performance chart of default product on remote server

Testing
Performance metrics of product with proposed

architecture on remote server - (ms)
1600
1400
1200
1000
800
600
400
200
0
Figure 7.4 - Performance chart of product with proposed architecture on remote server
7.5.5.2 Performance Testing – Phase 2

The second type of Performance testing will measure the impact the hierarchical architecture would provide
to the server when working in conjunction with Edge Computing.
Edge Computing basically means the offloading of processing power closer to the edge of an IoT network.
This is done by federating some of the functionality of the server to supervisor devices in the network called
Edge Gateways. Even though this is beyond the scope of this research the contribution it provides to overall
performance of the IoT server cannot be understated.
Since it is not possible to test the performance explicitly due to the complexities involved, it can be done
based on some assumptions as well as facts associated with Edge Computing. They are;
• The author would assume that 5000 Edge Gateways have been enrolled with the Entgra IoT server
instance.
• The author would assume that 2 Edge Devices per 1 Edge Gateway has been connected. In total
this would equate to 15000 Devices enrolled with the server (5000 Edge Gateways + 10000 Edge
Devices).
• Each Edge Gateway the Edge Devices are connected to has the ability to perform some form of
processing locally. This means that if the server needs to pass an operation for a device it only
needs to contact the associated Edge Gateway to so.
While the number of enrolled devices in both scenarios are the same (with the support of hierarchical
architecture vs without the architecture), the number of devices the server is actually communicating is

Testing
vastly different due to the presence of Edge Gateways, 5000 vs 15000 to be exact. Therefore, the test would
be performed to see how the number of devices the IoT server is interacting with affects performance.
Unlike the previous performance test which studied response times, this Performance test would study the
TPS (Transactions Per Second) that take place between the server and the devices. The reason for the change
in units is that the author believes this would better emphasize the performance gain or deficit as the test
observes the actual operations that are being passed.
The test tasks have also been adjusted accordingly. They are;
1. Device operation is initiated

2. Operation completed response
Similar to the earlier Performance test the tasks would be run in 3 rounds with the product version being
the same to maintain consistency. However, the entire test would be performed on the remote server as it
would better reflect the results that would be typically seen in a real-life scenario.
Device operation is initiated 277.1 402.4 383.1 354.2
Operation completed response 281.4 414.1 394.9 363.4666667
Table 7.8 - Performance metrics for running operations on 5000 devices
Device operation is initiated 357.4 402.4 405.8 388.5333
Operation completed response 366.7 409.7 415.6 397.3333
Table 7.9 - Performance metrics for running operations on 15000 devices
The data shown in Table 7.8 and Table 7.9 indicate the metrics obtained by running the script on the remote
server. A graphical representation of this data is indicated below in Figure 7.5 and Figure 7.6.

Testing
Performance metrics for running operations on

5000 devices - (TPS)
Average
Round 3
Round 2
Round 1
0 100 200 300 400 500 600 700 800 900
Device operation is initiated Operation completed response
Figure 7.5 - Performance chart for running operations on 5000 devices
Performance metrics for running operations on

15000 devices - (TPS)
Average
Round 3
Round 2
Round 1
0 100 200 300 400 500 600 700 800 900
Device operation is initiated Operation completed response
Figure 7.6 - Performance chart for running operations on 15000 devices
7.5.5.3 Usability Testing

In the Non-Functional Requirements list, the author noted the existence of a clean and simple interface in
NFR4. This was accomplished as along with the Hierarchical Architecture; the author also implemented a
novel Visualization interface to showcase the arrangement of the IoT network which was explored in detail
in section 6.5.1.3.
This Visualization interface was not intended to replace the existing interfaces of the Entgra IoT server (and
also developed in keeping with author defined guidelines outlined in section 6.4.2) but rather complement
them while also surfacing hierarchy related device details that would otherwise be hidden. The author also

Testing
proposed it as a tool that would enable to quickly diagnose inactive devices and debug network issues more
swiftly.
In tests that were conducted with a pool of participants that belonged to the pre-identified stakeholders (see
section 4.2) it could be seen that by using the Hierarchical Visualization UI against the existing device
listing UI there was on average a time reduction of 15% - 25% when detecting network issues, especially
ones caused by misbehaving devices. It should be noted that the individual times that were clocked differed
based on particular users’ familiarity with the interface of the product.
7.5.5.4 Reliability Testing

In the Non-Functional Requirements list, the author noted that the implementation should be reliable and
stable in NFR1. To test this an Entgra IoT server pack with the proposed hierarchical architecture
implemented was deployed on a remote cloud instance and tested using a script. The script went through
an initially defined set of tasks and tested them concurrently on several threads. The threads were intended
to simulate a number of concurrent users who would be accessing and running operations on the server
simultaneously. The set of pre-defined tasks included;
1. Register App
2. Generate Access token
3. Enroll device
4. Run operation
The response times were recorded as it provided a better indication of how much the system was straining
to maintain stable performance as opposed to a measurement like TPS. The test was performed in 3 rounds.
One could even call these “stress tests” as they attempt to overwhelm the server with multiple users and
requests to see how it would handle the load. The thread count was increased gradually from 10 to 30 to 60
to satisfy a realistic no. of concurrent users and to showcase how a product integrated with the proposed
architecture reliably handles increased load.
Register App 2425 2778 2346 2516.333333

Generate Access Token 291 294 291 292
Enroll Device 58 48 39 48.33333333
Table 7.10 - Performance metrics for testing 10 concurrent users

Testing
Register App 2588 2503 2361 2484

Enroll Device 61 63 46 56.66667
Run Operation 37 50 35 40.66667

Register App 2619 2559 2411 2529.667
Generate Access
Token 300 312 296 302.6667
Enroll Device 57 42 43 47.33333
Run Operation 55 71 52 59.33333
Table 7.10, Table 7.11 and Table 7.12 shown above showcases how the response times changes
dynamically based on the number of concurrent users simulated by the different thread counts.
7.6 Chapter Summary

The main focus of this chapter was testing the functionalities of the implemented prototype. The tests were
run against pre-defined quality criteria based on the Functional and Non-Functional Requirements specific
to this project. The errors and bugs that were identified in this chapter were taken care of promptly after
detection. The chapter also focused on aspects of Performance testing and Usability testing that went
beyond the standard Black-Box and White-Box tests followed in typical software development scenarios.
While this chapter emphasized the results that were obtained from the tests, the next chapter would be the
evaluation on what those results mean and an overall evaluation of the authors’ entire research project.

Evaluation
8 Evaluation

In the previous chapter the prototype was put through rigorous testing. The results of those tests were then
obtained and in some instances shown graphically by use of charts. This chapter will be a complete
evaluation of the Architectural proposal made by the author. This evaluation will be on the idea formulation
process, research process, development and testing results. All this will be followed up by a critical
evaluation.
8.2 Evaluation Criteria

Before beginning the evaluation, first the aspects that are going to be evaluated need to be clarified. When
taken as a whole this research project could be decomposed into 2 components; they are:
• Prototype development evaluation - includes all components that were relevant in bringing a
working implementation of this research to life and testing to see its’ functionality.
• Project evaluation - includes the initial literature survey, research, justifications, technology
selections etc.
Both of these components can be viewed in a quantitative and qualitative lens. Regardless, both will be
evaluated in an objective manner.
8.3 Prototype Development Evaluation (Qualitative)

The prototype evaluation has both a quantitative aspect to it and a qualitative one. A quantitative aspect can
been seen due to the fact that various parts of it could be measured numerically and a qualitative aspect
since external feedback can be received from evaluators about their personal thoughts. Since the data
relevant to the quantitative aspect has been gathered already via the testing performed in section 7.5, the
author went forward with gathering feedback from external evaluators.
8.3.1 Selection of Evaluators

In order to receive some un-biased feedback and qualitative evaluations about the prototype, the author
needed the help of external evaluators who were not directly involved with this project. When selecting
such evaluators, the author mapped them with the stakeholders identified in section 4.2 so that it better
reflects the thoughts of those the project is actually targeted at. Additional evaluators were also chosen
based on their current role they held and the contribution they could provide to the project.
The evaluators were each given an introduction about the research project followed by a quick demo which
involved enrolling a device and seeing the hierarchy related data visualized in the GUI.

Evaluation
The selected evaluators are as indicated in the table located in Appendix – List of selected external
Evaluators.
8.3.2 Summary of questions for Evaluators

In order to better focus the feedback received, the author formulated several open-ended questions based
on different aspects of the prototype and the project. The table in Appendix – Questions for selected
Evaluators, lists those questions that were posed.
8.3.3 Summary of Responses

The responses below have been arranged based on the feedback provided by the evaluators selected in the
table in Appendix – List of selected external Evaluators for the questions posed to them in Appendix –
Questions for selected Evaluators.
8.3.3.1 Responses for Concept and Approach

• “Not all products have this, as graphical representation of network components is not something
imperative in day to day life of most domains involving IoT (most devices connect in a flat
structure). When you go past a certain number of devices and have fog gateways with changing
hierarchies, this sort of representation becomes important. As of this moment, the biggest issue,
with existing hierarchical views is performance when dealing with millions of devices.”
- Evaluator 1
Evaluator 1 provides a sentiment that was shared among a majority of other evaluators as well; that handling
hierarchical device arrangements on the server end becomes important when a certain threshold of devices
is reached. He also stresses that one of the biggest issues that hierarchical device arrangements face comes
in handling millions of devices. While performance testing done on several thousand devices (see section
7.5.5.2) indicated that there is definitely a performance gain when the architecture is combined with Edge
Computing, when it comes to the actual visualization it is heavily dependent external factors such as the UI
library that is used.
• “It’s good because, if it is developed as a standalone demo without using an existing product,
it could be thrown away after the intended purpose. However, since its built-on top of a real
product, this feature will add the value to the product and can be benefited to those who require
the function in production after getting this added to the actual product release.”
- Evaluator 3

Evaluation
• “There is no point in re-inventing the wheel a lot of effort and time would have been wasted
had the student tried to implement everything from scratch. So the decision to go with an open
source product currently being used in the industry as the base, is commendable.”
- Evaluator 9
Both Evaluators 3 and 4 agreed that implementing the architecture on an existing product was beneficial
both for its’ functionality as well as the functionality of the product. As mentioned previously, by
successfully implementing on an existing product, the author also satisfied many of the design goals that
were established early on.
8.3.3.2 Responses for Usability

• “It will be affect usability positively, as a user of the system at a glance can identify the structure
by which the link between the server and device has been established. This can be beneficial
when programming for fail safes and in the case of devices with erratic connectivity patterns
to deliver files and configurations such as firmware updates. i.e. firmware update commands
can be issued to the gateway devices, so that the next time the edge device connects to the
gateway, relevant commands will automatically get propagated.”
- Evaluator 7
Evaluator 7 elaborates well on the usability afforded by the hierarchical visualization of the network
arrangement. However, some of the points he recommends still haven’t been implemented in the prototype
and is delegated to future work. Despite this, many of those recommendations are certainly useful.
8.3.3.3 Responses for Limitations and Future enhancements

• “Need convincing color patterns to show the current state of the connected devices. The
scalability of the implementation. What if there are 1k to 10k devices and how it is going to
represent in this diagram. Improve some meta data about the selected device and link it to
actual device (to device-view page) if someone needs to see more details. Load data
dynamically using web sockets rather than relying on page refreshes.”
- Evaluator 6
Evaluator 6 emphasizes the need for more clarity in the hierarchy visualization aspect of the project. He
brings up several important points such as how the visualization would scale for a large number of devices
and about displaying more metadata and device details. While these are all valid points, the author believes
that the current state of the visualization is more of a proof-of-concept. After all, the main purpose of the
research was proposing an architecture for hierarchical device arrangements, the visualization was a value

Evaluation
addition afforded by it. The author hopes to take these suggestions to heart and implement them in future
iterations.
8.3.4 Additional Responses

While the research was ongoing the author wrote and submitted 2 research papers to a number of
conferences. One of them being a Review paper and another being a Concept paper (refer Appendix –
Submitted Review paper and Appendix – Submitted Concept Paper). The review feedback that was received
from those conferences provided a very objective academic look into the author’s Literature Survey and
Architectural concept. Since most review processes were single blinded or double blinded the author has
no knowledge of who the reviewers were or what their roles are. However, it can be agreed that they are
somewhat academically competent given the status of these conferences.
Some portions of these reviews have been cut to better emphasize the feedback given regarding the overall
research and not the paper specifically.
• “The work is interesting, but it is not the first time that I've seen proposals to have a more
structured, distributed, knowledgebase built around a complex IoT network. I would advise to make
a wider literature review and look beyond today's leading vendor solutions”
- Reviewer F (2019 IEEE 5th World Forum on Internet of Things)
The feedback suggests that the gap the author is trying to fulfill is considered a genuine problem and there
have been prior attempts to solve it. However, he also mentions a “knowledgebase built around a complex
IoT network” which is not related to any aspect of the research. The suggestion to look into more futuristic
implementations is quite relevant but given as the authors’ main purpose was to study existing IoT products
and find how they tackled the issue of hierarchical network arrangements is based on current technology.
Therefore, the author believes that relying on futuristic attempts too much would hurt the adoptability of
the architecture which is mentioned as a Design goal (see section 5.2).
• “In this manuscript, the authors gave a review of existing IoT products, and the measures taken
within them to combat complexity in IoT networks especially of those formed due to Fog Networks.
The review is very meaningful for the following study and the writing of the paper is quite good.”
- Reviewer B (2019 7th International Conference on Smart Computing & Communications)
This reviewer has provided a positive feedback regarding the project and has satisfied his doubts regarding
what it was hoping to achieve.

Evaluation
• “This paper addresses a fairly current context in the computational area - the connected use of
intelligent devices. The proposal of localising data traffic is certainly useful.”
- Reviewer D (2019 Global IoT Summit)
This reviewer believes that the problem the author is trying to tackle and the gap that is being attempted to
be filled is quite relevant and current in context. The statement about localizing data traffic is a bit confusing
as that is not one of the primary focuses of this research. Yes, it is true that processes such as Edge
Computing enable localized data processing and in essence better performance however the author’s
architecture is suggested as a complimentary solution created by Edge Computing, not a replacement.
In addition to these reviews, a review paper that was written (refer Appendix – Submitted Review paper)
regarding the project was accepted at a conference and was given feedback. That feedback and the
acceptance notification can be found at Appendix – Paper Acceptance notification.
8.4 Prototype Development Evaluation (Quantitative)

Even though the results were obtained from the testing performed in the previous chapter it was not
analyzed or studied. This section is dedicated to the evaluation of those results, specifically those containing
performance metrics.
8.4.1 Evaluation of Test results
8.4.1.1 Performance test evaluation

Phase 1
The performance testing was conducted in 2 phases. The first phase being the tests run to check the impact
that the existence of the author’s architecture would have on the current performance of Entgra IoT server
and the second phase being the tests that were run to simulate what performance differences the architecture
would bring to the product when combined with Edge Computing.
The testing was performed on 2 environments to better gauge the fact that the product could be deployed
in different hardware types. First the results were shown in tabular form after which they were graphically
represented on charts to better visually elaborate the results obtained. However, taking the results
individually provides little insight into the differences. Hence it is more ideal to make a comparison with
the gathered data.
Average of default Average with proposed

(ms) Architecture (ms)

Evaluation
Register App 1299.333333 1337.333333

Generate Access Token 294 290.3333333
Enroll Device 62 67
Run Operation 29 32.66666667
Table 8.1 - Average response times for phase 1 performance tests on localhost
Table 8.1 shown above is a summary of the averages that were gathered from Table 7.4 and Table 7.5. Even
so it is not immediately apparent if there is an overall gain or loss based on just first viewing.
Figure 8.1 showcases the data of Table 8.1 in graphical form. As it can be seen the differences in
performance are close to negligible. Even the difference that shows the most visible increase in response
time (Task 1: Register App) is ~3% (2.92%) of the time taken on the product without the architectural
implementation included. Additionally, this data is measured in milliseconds and a 38ms (which is what
the ~3% equates to) gap is barely noticeable. Hence it can be confidently claimed that the author’s
architectural implementation has no degradation on performance when measured on localhost.
Comparison of average response times on localhost (lower

is better)
1600
1400
1200
1000
800
600
400
200
0
Average of default Average with proposed Architecture
Figure 8.1 - Average response times chart for phase 1 performance tests on localhost
Average of default (ms) Average with proposed

Architecture (ms)
Register App 1187 1280.666667

Generate Access 362.6666667 289.6666667
Token
Enroll Device 56.33333333 51.33333333

Evaluation
Run Operation 21 19
Table 8.2 - Average response times for phase 1 performance tests on remote server
Having the tests performed on a remote server provides better insight into how the architecture would
perform on a typical production grade environment. Table 8.2 shows a summary of the average response
times that were collected and Figure 8.2 showcases those results in graphical form.
The graphical form indicates that running the tests on the remote server seem to have incurred a higher
performance gap than on the localhost. The biggest differences can be seen in Task 1: Register App and
Task 2: Generate Access Token. More specifically, Task 1 saw a performance deprecation of ~ 8% (7.89%).
This is much more of a gap when compared to the results in the localhost. However, in Task 2 the tests run
on the remote server indicated a performance increase of ~ 20% (20.12%). While there are several factors
that can impact the results when run on a remote server it can be claimed that the 2 performance differences
balance each other out. Additionally, the instance of performance deprecation is in fact, very low at 93ms
(where 1 millisecond is 1 thousandth of a second) to be noticeable by a user.
Comparison of average response times on remote server

(lower is better)
1400
1200
1000
800
600
400
200
0
Average of default Average with proposed Architecture
Figure 8.2 - Average response times chart for phase 1 performance tests on remote server
Phase 2
Phase 2 of the testing involved considering how the performance of the Entgra IoT server with the integrated
hierarchical architecture would be affected when combined with Edge Computing. For this the performance
test was conducted assuming that 5000 Edge Gateways would be connected to an instance deployed on a

Evaluation
remote server and 2 Edge Devices would be connected to each Gateway. Table 7.8 and Table 7.9 showcased
the results obtained in tabular form. However, to better gauge the difference the averages of the two were
extracted onto a new table.
Average of Average of
5000 devices 15000 devices
Device operation is initiated 354.2 388.5333333
Operation completed response 363.4666667 397.3333333
Table 8.3 - Average TPS for phase 2 performance tests on remote server
Unlike in the Phase 1 performance tests which where the response times were measured in milliseconds, in
the Phase 2 performance tests the measurement was the number of operations exchanged between the server
and the connected devices hence was denoted in TPS (Transactions Per Second). This change in units was
performed as it better showcases the performance gap as opposed to the response times. While Table 8.3
shown above does indicate a noticeable difference in performance, it is far better noticed when elaborated
graphically as in Figure 8.3.
Comparison of average Transactions per Second

based on no. of devices (lower is better)
Average of 15000 devices
Average of 5000 devices
330 340 350 360 370 380 390 400 410
Operation completed response Device operation is initiated
Figure 8.3 - Average TPS chart for phase 2 performance tests on remote server
Upon studying the chart depicted in Figure 8.3, it becomes apparent that there is a significant deprecation
in performance when the server transitions into 15000 devices from 5000 devices. More specifically, the
TPS increase for Task 1: Device operation is initiated is ~9% (9.31%) and for Task 2: Operation Completed
response is ~10% (9.75%) when the number of devices increased by 200%. Since the TPS is directly related
to the CPU usage and Memory usage that means when the increase in devices resulted in the usage of both
going up by 9% - 10% approximately. While this increase isn’t that significant for server grade hardware

Evaluation
to handle, in the long term as devices and users increase that can change very quickly. This proves that by
use of the author’s hierarchical architecture features such as Edge Computing can be implemented which
can drastically reduce server load especially with regard to RAM and CPU usage.
8.4.1.2 Reliability test evaluation

The reliability testing was performed by running a set of tasks for 3 rounds on a product pack with the
hierarchical architecture included on a remote server. Variations were done on the number of concurrent
thread counts that the tasks were running on to simulate a varying number of users. The ultimate goal was
to see how the architecture integrated server would handle the mounting load created by an increasing
number of users. The testing was performed for 10, 30 and 60 threads and gained results were depicted in
Table 7.10, Table 7.11 and Table 7.12 respectfully.
Avg for 10 threads Avg for 30 threads Avg for 60 threads

Register App 2516.333333 2484 2529.666667
Generate Access Token 292 307.6666667 302.6666667
Enroll Device 48.33333333 56.66666667 47.33333333
Run Operation 25 40.66666667 59.33333333
Table 8.4 - Average response time (ms) for reliability tests performed in remote server
A summary of the response time averages that were gathered form the three different thread counts is shown
in Table 8.4. While the results aren’t exactly clear when shown in tabular form, it becomes far more
apparent when shown graphically.
Comparison of Avg. response time with

increasing number of users
3000
2500
2000
1500
1000
500
0
Avg for 10 threads Avg for 30 threads Avg for 60 threads
Register App Generate Access Token

Enroll Device Run Operation
Figure 8.4 - Average response time chart for reliability tests with increasing users

Evaluation
As it is clear from Figure 8.4 that the hierarchical architecture enabled server scales to the load gradually
without causing any significant bottlenecks. This can be said due to the fact that the line depicted in the
chart is close to being straight line, inferring that the servers’ response time, and in essence the performance,
has maintained constant throughout.
8.5 Project Evaluation

A complete evaluation of the project involves studying the decisions taken at various points in the project’s
timeline. It is also a study on how those decisions impacted the final outcome and whether they were the
most suitable for the project overall.
8.5.1 Schedule
A project schedule was formulated very early on to properly plan and manage the work load. This was done
using a Gantt chart as indicated in Appendix – Gantt Chart. One of the main factors that aided in the
successful completion of the project was the timely manner in which each of the stages stated in the Gantt
chart was followed. By breaking down the entire length of the project into manageable chunks enabled it
to be easily digestible and comprehensive enough to be done within the limited time period.
8.5.2 Project Management Methodology

During the project planning phase (see chapter 2) it was understood that the best methodology suitable for
the author’s project was the Iterative Model. The decisions were based on a number of points in relation to
the project such as; learning about the technology as the project was progressing and the freedom it provided
when it came to satisfying requirements. In the long run, this proved to be a very wise decision as it enabled
further improvement of components with each iteration which allowed to have a presentable prototype
ready in no-time. Additionally, not all components needed to be finalized to continue with the project
therefore progress was made in its own time without rushing.
8.5.3 Objectives
The objectives that were defined very early on in the project were satisfied quite successfully within the
established time frames.
8.6 Critical Evaluation
8.6.1 Features and Functionality

The author’s final goal in this research was to come up with an architecture that would enable a central
cloud server to understand a hierarchical device arrangement that would be under its influence. Given this

Evaluation
is mostly a conceptual project, what was needed from the final prototype was to prove that the proposed
architecture was functional and practical enough to be implementable.
After the initial research to gather in-depth knowledge about the domain a literature survey was conducted
to study existing IoT solutions (see section 3.4). The purpose of this study was to understand how
established products as well as new, up-and-coming ones has tackled the issue of complex IoT device
networks. This survey revealed that most if not all products (which had a transparent architecture) had no
solution to arrange hierarchical device arrangements. The most that was implemented was with Edge
Gateways that provided at best a single layer hierarchy. This literature survey opened the door to the author
by not only revealing what deficiencies they possessed but also providing insight into how existing IoT
products were built. This proved extremely important when it came to the actual implementation.
In addition to this, the author also planned from the onset to adhere to the Design Goals (see section 5.2) as
much as possible. The entire approach to the implementation was duly performed by implementing the
architecture on an existing IoT product to better emphasize those aforementioned Design Goals. The author
believes that rather than implementing a whole new product from scratch, the implementation on an existing
product was more complex and challenging. This was due to fact that the integration needed to be done
seamlessly without interfering with the existing code base or breaking any of the existing features. The
author also made it a point to follow several guidelines when it came to actually developing the
implementation so that features and functions of the existing product were respected (see section 6.4.2).
However, despite the challenge posed by integrating the proposed architecture on an existing solution, in
the end the author believes that it actually helped the final outcome. It not only showed that the architecture
was truly product agnostic as the author initially intended but also added value to an existing product as
seen in the performance evaluation section; 8.4.1.1. It also enriched the feedback received in the evaluation
component (see section 8.3.3) as it was given from the very developers that developed and designed the
original product.
8.6.2 Functional Requirements

Functional Requirements were stated at the onset of the project (see section 4.6.1). Of those requirements,
several proved to very challenging to implement. The most difficult being the extraction of the hierarchical
metadata from the enrollment payload sent by a device. As with any research project there were several
attempts performed with many false leads which lead to even more dead ends. What made it even more
difficult was that it was all implemented on an existing solution. Therefore, instances of reinventing the
wheel or breaking the code base were always a looming concern.

Evaluation
Despite this a majority of the requirements were successfully implemented and tested in the end. Given this
was more of an architectural implementation than a product or solution, the author decided to keep most of
the requirements as high priority. This was due to the additional fact that all of them were important to
showcase the capabilities of the architecture and they were all inter-dependent.
8.6.3 Non-Functional Requirements

5 Non-Functional Requirements were stated at the onset of the project (see section 4.6.2). Even thought
they were not as much of a priority as the Functional Requirements the author paid close attention to them
regardless. Listed below are those requirements and how each was satisfied during the course of the
implementation.
• NFR1 – Reliability – As shown in the Testing section and studied in the Evaluation section (7.5.5.4
and 8.4.1.2 resp.) the reliability of the server with the hierarchical architecture integrated was
maintained well even with increased load. This was achieved by having a lean code base for the
implementation that avoided code smells (Atwood, 2006).
• NFR2 – Performance – Also shown in the Testing section and studied in the Evaluation section,
performance was tested in 2 phases. One indicated that the performance of the existing product was
not hindered in any way and the second phase indicated that there would be a significant
improvement to performance when the architecture is put to full use via the aid of Edge Computing.
• NFR3 – Extensibility – While the architecture enabled the basic features that showcased its’ ideal
use case it added some additional features to the final output via a graphical visualization of the
network arrangement.
• NFR4 – Usability – The previously mentioned hierarchical visualization can be cited here as well
it provides an extremely easy to understand overview of how the network is arranged in real time
as well as a brief summary about device details and states.
• NFR5 – Security – Security was unfortunately the only requirement that was not least prioritized
due to the low impact it had on this research. However, prior to making the architecture market
ready this aspect is also planned to be completed in advance.
8.7 SLEP Aspect Evaluation

Ethical aspects of a research project include the following components, in no specific order; Professional,
Ethical, Legal, and Social.
The reason for enforcing them is so that sensitive user data is not mismanaged but is used responsibly by
the relevant parties. The Author’s project does not deal with any pre-collected user data nor does it depend
on collecting user data for functioning.

Evaluation
Despite this, it should be mentioned that connected devices are frequently subject of controversy due to
privacy concerns. Therefore, even though it is out-scope, the Author has taken special measures on the Edge
Device end to inform users prior to having contact with the server for any data exchange. That is, there will
be full transparency and users will be fully aware when their Edge Device will contact the server and how.
Additionally, all research used for the Literature Review was taken legally from publicly available sources
with relevant credit being given where it is due.
The author also took care to obscure personal details about corporate individuals who were contacted to
provide feedback for the qualitative evaluation component. Accordingly, they are only referred to as
Evaluator 1, 2 etc. with only the designation being the identified factor.
Additionally, the author took special care when selecting technologies that complied with SLEP principles.
Accordingly, the existing IoT product used for implementing the architecture is fully compliant with the
European GDPR standards (WSO2, 2018). In addition to this, the product is also completely open source
and licensed under Apache 2.0 (Entgra.io, 2019). This means that all integrated architectural changes are
entirely within ethical limits and the product was also acquired legally.
8.8 Chapter Summary

In this chapter the author evaluated the progress made in the complete project for proposing a metadata-
based architecture for supporting hierarchical Edge Device arrangements in an IoT deployment. Different
components of the project were evaluated including those related to the prototype and other logistical
aspects. The quantitative results that were obtained during the testing portion of the prototype were studied
and their outputs observed in an objective manner. In addition, feedback was obtained from outsiders with
regard to their thoughts on the overall concept and the prototype. When it comes to the requirements and
objectives that were defined at the onset of the project, it can be seen that almost all of them have been
successfully satisfied. In addition, the testing performed, and the evaluation done on the results further
establishes that the project was a success.
The next chapter will conclude this project by discussing the lessons learned by the author while engaging
in it and proposing future enhancements.

Conclusion
9 Conclusion

In the previous chapter the results that were gained from the testing phase was evaluated and studied. This
chapter would essentially be the concluding chapter of this project. It would include a summarization of
accomplishments made during the course of this research and highlight the findings and conclusions
reached. The chapter will also consider the achievements obtained, the objectives reached and challenges
that were met and addressed. The learning outcomes that were satisfied will also be elaborated.
9.2 In Retrospect
This research project was started because the author discovered a gap with how hierarchical Fog
Networks/Device arrangements were handled in central cloud servers (see section 1.2). An extensive
literature survey was thereafter conducted to gather more research on the subject. This included studying
terminology and technologies related to the domain and looking into existing IoT products. Those IoT
products were then studied in depth and their pros and cons identified. Those products were also compared
to see how each stacked up against each other.
After the literature survey and review were concluded the requirement gathering phase began. For this
stakeholders were identified and questioned to gather their input. It was identified that the best method
through which requirements can be gathered is via Interviewing and Brainstorming, therefore it was
conducted as such. The functional and non-functional requirements were also established. After the
requirements were gathered it was time to move onto the design phase.
The design phase involved using all the gathered requirements and coming up with a non-technical way to
achieve them. This involved deciding on a proper design methodology to begin with and then coming up
with a practical approach to go about it. Design diagrams such as sequence and class diagrams were used
to provide a better picture into this thinking. A rich picture was also used for additional context.
With the competition of the designing components, the implementation was initiated. It involved creating
an actual working prototype of the earlier formulated designs. This was achieved by recalling all learnt
knowledge as well as new insights gained during the earlier phases. This prototype was then tested, both
by standard methods as well as methods specific to the domain and use case the author was focusing on.
Those results were then evaluated both quantitatively and qualitatively in the evaluation phase. This phase
also took in feedback about the prototype from external evaluators based on how well they related to the
previously defined stakeholders (see section 4.2).

Conclusion
Throughout every phase the entire research process was documented, and progress shared with the project
supervisor.
9.2.1 Strengths of the Solution

Based on the feedback received from evaluators and comparisons with existing products there were several
strong points that the author has identified in the implemented solution.
• Product Agnostic: From the very onset itself the author planned the architecture to be product or
technology agnostic. This was also considered when design decisions were taking place as well.
The author was also successful in showcasing this in the implementation by using an existing
product the base the architecture on.
• Hybrid Approach: The architecture uses a hybrid approach (see section 5.4) that takes the best of
both worlds with regard to how devices in the hierarchy can be identified. This ensures that the
hierarchical representation of devices in the central server can be verified with the data in the Edge
Devices.
• Ability to work with existing technology: This was also cited as one of the main goals at the very
onset of the research. It was achieved in the implementation phase by integrating the architecture
onto an existing product without conflicting with any of its existing features.
• Network Visualization: As seen in section 6.5.1.3 one of the advantages the architecture afforded
is the ability to visualize how the device layout in the network is arranged. This proves to be
invaluable when it comes to quickly gaining insight into the health and behavior of devices.
9.2.2 Weaknesses of the Solution

Along with strengths, there were also weaknesses that the author identified. The reasons for having these
weaknesses range from them being out of scope elements to time constraints.
• Entire research based on central cloud server: As mentioned in section [], the scope of this
research was delegated to the central cloud server. More specifically; the entire research revolved
around changes made to central cloud server. This meant that certain changes on Edge Devices that
could have resulted in better features weren’t implemented.
• Single Parent hierarchy: In its’ current form the architecture has been formulated assuming that
each Edge Device is connected to only parent device in the hierarchy.
• Heavy Resource requirements: The product that was selected to implement the architecture by
nature requires a very performant machine to run the server.

Conclusion
9.3 Challenges Overcome
9.3.1 Time Management

Given that this is the first time the author has worked on a solo research project that spanned several months,
time management was always a crucial factor that needed to be accounted for. This was achieved somewhat
due to the work done on the project management aspect of the research as noted in chapter 2. However,
there were several factors both external and internal that could not be accounted for such as;
• Gathering the necessary requirements for the requirement specification phase of the project
• Getting feedback from external evaluators on their thoughts about the project
• Preparing all the required research material needed for the literature survey
• Learning the architectural arrangement of an existing product from scratch
While all of these did pose setbacks in some portions of the research, the author managed to quickly
overcome them by either moving onto the immediate next task that is not reliant on the issue at hand or
finding alternatives that either provided a similar outcome in the same time.
9.3.2 Learning new technologies

Another challenge that was encountered during the course of this project was the need to learn the entirety
of a new product from scratch. As discussed in section 6.3.3, an existing IoT product was used to implement
the proposed architecture. This meant the complete product stack was needed to be understood in order to
successfully integrate the architecture into it. What made it even more challenging was the fact that a none
of the existing features or functionality could be impacted whatsoever due to its integration.
How the author overcame this is by approaching the development in phases. Each functionality was
implemented by studying its usefulness to the implementation as a whole and its relationship with other
components. This flow as also aided by use of the iterative project management model. If ever there was a
block in one segment of the implementation, the author defaulted to using alternatives methods or brute
forcing until it was solved.
9.4 Achievements
9.4.1 Project Aim Achievements

As mentioned in section 1.4.1, the aim of this research project was to,
“research, design and develop a generalized solution that would provide the central cloud/server with an
understanding of the hierarchies of Fog Networks/Devices connected to it.”

Conclusion
Upon extensively studying existing IoT products it was understood that this solution would be a generic
metadata-based architecture. This research also paved the way into executing the implementation in a
correct manner much later in the project as well.
After obtaining the needed requirements from stakeholders and creating the proper design documentation,
the implementation was created by basing it on top of one of the aforementioned existing products.
Accordingly, an architecture was successfully implemented that also satisfied the design goals set at the
very onset of the research. Additional feedback from evaluators who were mapped based on the pre-
identified stakeholder also reinforced that the proposed architecture was a success.
Therefore, it can be safe to say that the project aim has been met successfully.
9.4.2 Research Objective Achievements

As mentioned in section 1.4.2, four research objectives were stated as needing to be achieved in this research
project. Those objectives and how they were achieved are as follows;
1. To propose a generalized solution that satisfies identified properties – A generalized

metadata-based architecture was proposed based on findings from existing IoT products and
related research.
2. To research and develop the proposed architecture – The proposed architecture was
developed successfully atop an existing IoT product and evaluated with feedback from external
evaluators.
3. To perform additional implementations to simulate the Network Edge and platform
relationship. – Development was done to simulate an Edge Device on a lesser known platform
and successfully enroll with the central server.
4. To write a documented specification about the proposed Architecture. – A fully
documented specification was created in the form of this thesis report that completely
encapsulates all aspects of the architecture.
9.4.3 Project related Achievements

In addition to the project specific achievements there were also other experiences that were gained during
the course of this project. Those achievements and experiences as well as the skills they entail are as
follows;
1. Improved requirement gathering and analysis skills.

2. Learnt extensively about IoT products and each of their limitations and functionalities.
3. Learnt how an enterprise grade central server product was created and developed.

Conclusion
4. Improved documentation and time logging skills.

5. Improved time management ability
6. Learnt how to work on an Open Source product and communicate with the associated developer
team.
9.4.4 Research related Achievements

Researching and making new discoveries was also a key component of this project. It was so important that
it provided the preliminary foundation for the latter part of the project including the implementation.
Accordingly, the research related achievements that this project allowed were also numerous.
1. Improved overall researching ability.

2. Gave insight into how research problems should be stated and introduced.
3. Motivated to write multiple research papers which also in return enhanced the final thesis
document (see Appendix – Submitted Review paper and Appendix – Submitted Concept Paper).
4. Learnt the process through which research papers get published and reviewed.
5. Received constructive feedback about the concept from established review panels from the
submission of those research papers.
9.4.5 Achievements relative to module Learning Outcomes

The Final Year project module mentions 7 learning outcomes that need to be satisfied at its completion.
Those learning outcomes and how they were accomplished are indicated below in the table located in
Appendix – List of module learning outcomes and usages.
9.5 Research Contribution

The ultimate goal of any research is to provide a value addition to a certain subject area or domain. In the
case of the author’s research, it is to the domain of IoT. In this regard the author believes that this project
has been successful in providing a value addition in multiple aspects.
• Architecture – The main purpose of this research was to come up with a solution to solve the
complexity issue of hierarchical device arrangements in IoT networks. That solution was the
authors’ proposed parent-child architecture. However, what makes the architecture even more
alluring is its technology and product agnosticism. By choosing the implement it upon an existing
product (see section 6.3) it was made apparent that almost anyone willing can integrate this
architecture into their own product. Therefore, it can be claimed, that the architecture by nature is
extensible and easily adoptable.

Conclusion
• Performance – As observed during the performance test evaluation, testing was done with several
variations (see section 8.4.1.1). Tests that benchmarked how the architecture performed against the
same product without the architecture indicated that having the architecture doesn’t incur any
performance degradation whatsoever. However, the most noticeable difference was seen in how
the architecture performed when combined with Edge Computing with a significant increase being
observed. This too can be cited as a resulting contribution as the Edge Computing capabilities that
the authors’ architecture unlocks also helps the central cloud server perform better.
• User Experience – The majority of this research focused on the back-end portion of the central
cloud server due to the architectural nature of the implementation. However, one way the authors’
project manages to stand out is due to a particular GUI component that aids the user experience
aspect. Even though this project is more theoretical and conceptual, the very nature of the parent-
child architectural arrangement enables a visual representation of an IoT network to be generated.
This allows for rich user engagement features such as easy viewing of device details, quick
identification of the device location within a network and quick identification of defective devices.
9.6 Future Enhancements

Like many research projects while much has been achieved in its current state, there is more that can be
done. For the author’s project, they are as follows;
1. Supporting Multiple parents: In its current state the architecture only supports a device
arrangement where each device is connected to a single parent in the in the immediate
upstream. There may be instance were an Edge Device may be connected to several parent
devices concurrently. This is what the author is hoping to improve on in future iterations of the
architecture.
2. Richer UI: One of the standout features afforded by the architecture was the interactive
hierarchical UI. It provided a complete visual representation of the network arrangement at a
particular time. It also provided a brief summary of real time details regarding each and every
device. The author hopes to expand upon this and create a more intuitive UI as an improvement.
This may include a real-time representation of how devices are communicating with the server
etc.
3. Additional Metadata fields: In the current state the architecture only included a single
parentId field as metadata about the hierarchical arrangement. This provided a way through
which the hierarchical representation could be created on the server. However, in order for the
server to have more richer picture about the hierarchical arrangement more fields need to be

Conclusion
included. The author hopes to test different types of fields and identify the most crucial ones
that would provide a better picture of the hierarchy.
4. Better Edge Gateway integration: Since the in-scope of this research was the changes being
done to the central server, much was focused on it and not the Edge Devices or Edge Gateways.
In future versions the author hopes to have the Edge Gateways perform a larger role in the
architecture along without associated methodologies such as Edge Computing.
5. Improved Security: While the current prototype does have a significant amount of security,
due to time constraints certain aspects were left out when it was felt that it didn’t provide a
significant enough impact to the main goal. The author hopes to amend this in future iterations
and provide rock-solid security when it comes to the architecture; both on the server side and
the client-side with Edge Devices and Gateways.
9.7 Chapter Summary and Concluding Remarks

At the very beginning of this research project the author established that its’ aim is to “research, design and
develop a generalized solution that would provide the central cloud/server with an understanding of the
hierarchies of Fog Networks/Devices connected to it”. The author confidently believes that this was
achieved through the proposed metadata model based hierarchical device architecture. In achieving this the
author also successfully met the pre-defined design goals. Subsequent testing and evaluation of the
prototype was also indicative that the architecture provided added benefits of performance beyond what
was originally intended.
Overall, it can be said that all tasks were completed in the allocated time frame and all objectives met,
which in the author’s eyes is considered a successful conclusion to the project.

Appendix – Submitted Review paper
A. Appendix – Submitted Review paper
a Nuwan Jayawardene | 2015235

b Nuwan Jayawardene | 2015235

c Nuwan Jayawardene | 2015235

d Nuwan Jayawardene | 2015235

e Nuwan Jayawardene | 2015235

f Nuwan Jayawardene | 2015235

Appendix – Submitted Concept Paper
B. Appendix – Submitted Concept Paper
g Nuwan Jayawardene | 2015235

h Nuwan Jayawardene | 2015235

i Nuwan Jayawardene | 2015235

j Nuwan Jayawardene | 2015235

Appendix – Gantt Chart
C. Appendix – Gantt Chart
k Nuwan Jayawardene | 2015235

Appendix – Work Breakdown Chart
D. Appendix – Work Breakdown Chart
Final Year Project
Literature Review Requirement Prototype Analysis

Prototype Testing and Finalizing the
Project Initiation and Requirement Gathering & and
Implementation Evaluation project
Gathering Analysis Documentation
Create High level

Select Research Conduct Literature Gathering Prepare Draft Final
Architecture Code Review Unit Testing
Domain Search Requirements report
diagram
Collect
Conduct Literature Designing the Submit prototype Submission of the
Select project Idea Information from Integration Testing
Review Prototype report Final report Draft
domain Experts
Analysing and Initial Getting document

Prepare Literature Changes to
Prepare Draft PID Evaluating implementation of Bug Fixing checked by
Review prototype build
collected data Prototype Supervisor
Prepare software
Submit Draft LR to Prepare interim Submission of
Submit Draft PID requirements
Supervisor progress report Final report
specification report
Discuss regarding Discuss progress

Submit Literature
Prepare final PID SRS with report with
Review
Supervisor Supervisor
Further Research Submit interim

Submit final PID Submit SRS report
on Domain progress report
Evaluate
Modifications of
requirements
the LR
against prototype
l Nuwan Jayawardene | 2015235

Appendix – Paper Acceptance notification
E. Appendix – Paper Acceptance notification
m Nuwan Jayawardene | 2015235

Appendix – Use Case Diagram
F. Appendix – Use Case Diagram
n Nuwan Jayawardene | 2015235

Appendix – Interview Questions
G. Appendix – Interview Questions

Research Objectives
Derived Questions
Sub Objectives
- - What are the main issues you have

encountered when dealing with large
IoT networks?
To propose a generalized - How do you plan to handle complex

solution that satisfies device hierarchies that might arise in
identified properties Industrial IoT and Smart City
scenarios?
- What solutions have you come

across that enable complex device
hierarchies to exist in an IoT
network
To research and develop the To find a suitable IoT central cloud What do you expect from an
proposed architecture server to base the architecture on established IoT central cloud server?
What features do you think are

crucial for an IoT central cloud
server?
To develop suitable value additions What would you say are "nice-to-
incorporating the new architecture have" features in an IoT central
cloud server?
To make the architecture extensible Would you say extensibility and

and modular modularity are an import component
when developing IoT solutions?
How would you accomplish

extensibility and modularity when
o Nuwan Jayawardene | 2015235

Appendix – Interview Questions
dealing with a component for an IoT

central cloud server or IoT solution?
To perform additional To test how devices in the Network What would you say are the
implementations to simulate Edge would work with implemented regularly encountered types of
the Network Edge and architecture devices which connect to an IoT
platform relationship. central cloud server?
How did those devices typically

interact with their supervising IoT
central cloud server from a software
perspective?
To write a documented - What do you typically expect when

specification about the studying documentation for a new
proposed Architecture. feature on an IoT central cloud
server?
Have you had any bad experiences

with documentation in the past?
If so, what do you think should be

fixed those bad documentation
examples?
p Nuwan Jayawardene | 2015235

Appendix – High-Level overview of Hybrid Approach
H. Appendix – High-Level overview of Hybrid Approach
q Nuwan Jayawardene | 2015235

Appendix – Class Diagram
I. Appendix – Class Diagram
r Nuwan Jayawardene | 2015235

Appendix – Mock network diagram showcasing parent-child architecture
J. Appendix – Mock network diagram showcasing parent-child architecture
s Nuwan Jayawardene | 2015235

Appendix – Approach comparison for implementation
K. Appendix – Approach comparison for implementation
Implementing architecture from scratch Building architecture on existing

using a standalone product product
Pros • Complete freedom to implement • Can understand how the architecture

architecture however necessary. performs within an existing
• Much easier approach since the end established product environment.
objectives are clearly understood hence • Can get constructive feedback from
the implementation can be tailored to industry and domain experts
those objectives. regarding the viability of the
architecture for actual use cases.
• Can see how well the architecture
interacts with other components in
the existing product (User
Management, Device Management
etc.)
Cons • Implementation decisions will be based • Much harder approach since

on the architectural decisions. This will architecture would need to
go against the entire idea of product accommodate the existing codebase.
agnosticism intended by the author. • The existing features and abilities of
• Will lack many crucial features found the product should not be broken or
standard on existing IoT products. hindered in any way.
• Won’t be able to judge how the
architecture would function within a
production grade environment.
• Will lack support from a variety of Edge
Device platforms (Operating Systems)
due to time and development constraints.
t Nuwan Jayawardene | 2015235

Appendix – Onion Diagram
L. Appendix – Onion Diagram
u Nuwan Jayawardene | 2015235

Appendix – Layers of a Fog enabled IoT Network
M. Appendix – Layers of a Fog enabled IoT Network
v Nuwan Jayawardene | 2015235

Appendix – Server deployment code in Mozilla Web of Things Gateway
N. Appendix – Server deployment code in Mozilla Web of Things Gateway
/**
* Creates an HTTPS server object, if successful. If there are no public and
* private keys stored for the tunnel service, null is returned.
*
* @param {}
* @return {Object|null} https server object if successful, else NULL
*/
function createHttpsServer() {
if (!TunnelService.hasCertificates()) {
return null;
}
// HTTPS server configuration
const options = {
key: fs.readFileSync(path.join(UserProfile.sslDir, 'privatekey.pem')),
cert: fs.readFileSync(path.join(UserProfile.sslDir, 'certificate.pem')),
};
if (fs.existsSync(path.join(UserProfile.sslDir, 'chain.pem'))) {
options.ca = fs.readFileSync(path.join(UserProfile.sslDir, 'chain.pem'));
}
return https.createServer(options);
}
w Nuwan Jayawardene | 2015235

Appendix – Reference architecture feature comparison
O. Appendix – Reference architecture feature comparison

Azure IoT Mozilla Web of Things Entgra IoT Server
Autonomy Edge Gateways have Things Gateways do not rely The Edge Gateway is fairly
limited autonomy beyond on a complex server stack on limited in its functionality.
what can be done via the the cloud end to function, in Although it is not very
cloud. Compared to the rare (but quite possible) capable the open source
Mozilla's implementation case of a cloud outage it nature allows it to be easily
it has very weak autonomy could easily maintain customized to achieve some
autonomy. form of autonomy.
Scalability The different Edge In this implementation the While the Edge Gateway is
Gateway configuration Edge Gateway has a limited, the central cloud is
addresses different types significantly large role to vastly more powerful and can
of requirements but also play. This could adversely scale easily. Given its
the wide variety of devices affect the stability of the Enterprise grade design, it is
that could be encountered entire network due to unlikely to get bogged down
in an IoT network. bottlenecks. easily.
Extensibility Azure IoT has certain In contrast to Microsoft, While coming out-of-the-box
aspects of the Gateway Mozilla is an open source with many features built in, a
agents open sourced, the organization by heart. Not robust plugin system allows
cloud is more the most part only is their own project for additional functionality to
a black box. This is not open source but it is also be implemented with ease.
very developer friendly in built upon other open source
the long run. projects.
Specialty Azure IoT has identified The approach to have Edge The Enterprise grade
pain points in existing IoT Devices be implemented implementation means that
implementations and using libraries is also very the entire system is resilient in
addressed them. This is all noteworthy. These re-usable most system failures and the
maintained by a central components make it easier extensive component-based
cloud which is for developers to write design means that
unfortunately proprietary clients on all forms of functionality can be added or
and closed source. devices that can connect removed quite easily.
x Nuwan Jayawardene | 2015235

Appendix – Reference architecture feature comparison
with Mozilla's "Web Thing

API".
Identified The closed source nature With the inherent limitations The need for platform specific
issues leaves developers at the an Edge Gateway possesses agents to gain full access over
mercy of Microsoft and compared to an entire central Edge Devices can become
can quickly lead to the cloud server this cumbersome and prove
much dreaded "vendor implementation might be difficult to maintain in the
lock-in" scenario prone to unseen issues. long run.
Supports None of the implementations support any form of Hierarchical device organization up to
Hierarchical any extent
device
arrangement
y Nuwan Jayawardene | 2015235

Appendix – UI mockup of hierarchical visualization
P. Appendix – UI mockup of hierarchical visualization
z Nuwan Jayawardene | 2015235

Appendix – Metadata acquisition and storage flow
Q. Appendix – Metadata acquisition and storage flow
aa Nuwan Jayawardene | 2015235

Appendix – Software stack vs Architecture layers arrangement
R. Appendix – Software stack vs Architecture layers arrangement

Product Stack Analogous architectural Function
layer
Database Layer Persistence Layer Providing a storage medium for extracted device
metadata as hierarchical metadata to be used later
either for post-processing or other functions
DAO Layer CRUD Layer Used to execute operations on the Persistence layer
via some Query language.
OSGi Layer Computation Layer Where many of the computational operations as well
as resource allocation is performed. Many other
functions of the server (such as User Management,
multi-tenancy etc.) can be accessed directly via this
layer without taking a roundabout route and
accessing the exposed endpoints.
API Layer Presentation Layer Used to securely expose the services of the server to
external parties. This same presentation layer serves
the native UI of the server (the one accessed by
logging into localhost). Individual functionalities are
exposed using separate endpoints.
UI Layer Application Layer This layer works atop the Presentation Layer to
deliver the user with a rich UI consisting of graphical
elements. Ideally, the architecture should function
without the Application Layer as well. The reason
that this layer isn’t given much prominence is
because anyone could integrate the endpoints in the
Presentation Layer with their own GUI and
completely ignore the natively provided one.
bb Nuwan Jayawardene | 2015235

Appendix – DAO layer methods to extract enrollment metadata from persistent storage
S. Appendix – DAO layer methods to extract enrollment metadata from

persistent storage
cc Nuwan Jayawardene | 2015235

Appendix – API layer code to generate payload required for UI
T. Appendix – API layer code to generate payload required for UI
dd Nuwan Jayawardene | 2015235

Appendix – Payload generated for the use of hierarchical visualization library
U. Appendix – Payload generated for the use of hierarchical visualization

library
ee Nuwan Jayawardene | 2015235

Appendix – Front-end code markup
V. Appendix – Front-end code markup
ff Nuwan Jayawardene | 2015235

Appendix – Client-side JavaScript code used for UI generation
W. Appendix – Client-side JavaScript code used for UI generation
gg Nuwan Jayawardene | 2015235

Appendix – List of module learning outcomes and usages
X. Appendix – List of module learning outcomes and usages

Criteria Usage
LO1 Select, justify and apply appropriate A problem was identified with regard to how hierarchical
methods, techniques and tools for device arrangements were handled by central IoT servers.
tackling the problem related to the An extensive research was done in this domain and
project. findings gathered. (refer chapter 1)
LO2 Collect and analyze the requirements A thorough requirement gathering session was
of the project using appropriate performed. It included requirements gathered from
techniques and tools stakeholders and UML diagrams to better understand the
project. (refer chapter 4)
LO3 Develop a project plan that schedules A project management plan was established by
their own activities and time within the considering the various complexities of the author’s
given timescale. research project. Risks were also identified along with
necessary mitigation options. (refer chapter 2)
LO4 Research and collate relevant Extensive research was performed to gain additional
information on a given topic from background knowledge about the domain. This was also
various sources and critically evaluate accompanied by research about existing IoT products.
the findings (refer chapter 3)
LO5 Analyze a complex task, carry out the Upon completion of the requirement gathering and
activities involved in its investigation. design phases an implementation was performed. The
outcome of which was the final prototype which was
thereafter tested and evaluated to see if it stacks against
the established standards. (refer chapters 6, 0 and 8)
LO6 Identify and take account of any legal, All social, legal, ethical and professional aspects related
social, ethical or professional issues to the project were identified and also considered during
relevant to the project topic. the duration of the research. (refer section 8.7)
LO7 Produce a well-structured and A finalized document including all findings, research and
coherent report which documents and implementation details was compiled in the form of this
critically evaluates the work carried thesis report. In addition to it, 2 research papers were also
out, the new skills which have been written to further enhance the richness of this research
acquired and the effectiveness of the project (see Appendix – Submitted Review paper and
project plan. Appendix – Submitted Concept Paper)
hh Nuwan Jayawardene | 2015235

Appendix – Screenshot of Edge Device agent on webOS
Y. Appendix – Screenshot of Edge Device agent on webOS
ii Nuwan Jayawardene | 2015235

Appendix – List of selected external Evaluators
Z. Appendix – List of selected external Evaluators
Mapped Stakeholder Name Role
System Admin Integration Developer at a leading educational institute

Evaluator 1 in Australia
Software Engineer at a leading IoT company in Sri

Evaluator 2 Lanka
Software Engineer at a leading IoT company in Sri

Evaluator 3 Lanka
Software Engineer at a leading technology company in

Evaluator 4 Sri Lanka
Technical Lead Associate Technical Lead at a leading IoT company in

Associate Technical Lead at a leading middleware

Evaluator 6 company in Sri Lanka
Associate Technical Lead at a leading IoT company in

System Architect Evaluator 8 Technical Lead at a leading IoT company in Sri Lanka
Associate Technical Lead at a leading IoT company in

Management Evaluator 10 Founder & CEO at a leading IoT company in Sri Lanka
- Evaluator 11 Researcher at a leading University in Australia
jj Nuwan Jayawardene | 2015235

Appendix – Questions for selected Evaluators
AA. Appendix – Questions for selected Evaluators
Evaluation Criteria Question No. Question
Concept and Approach 1 What are your thoughts on hierarchical network

implementations in current IoT products?
2 What are your thoughts on the parent-child

architecture that has been implemented?
3 What are your thoughts on the prototype that was

developed?
4 How would you believe the features that the

prototype brings would impact the product?
Usability 5 How would you think the hierarchical

visualization UI would affect usability?
Limitations and Future 6 What limitations can you identify in the

enhancements prototype?
7 What features do you think can be added to the

prototype (either overall architecture or UI
component)?
kk Nuwan Jayawardene | 2015235

Appendix – System Testing results
BB. Appendix – System Testing results
FR No. Requirement Description Priority Status
1 Get the credentials of user logged into the session and current High Pass
tenant
2 Allow the user to enroll a device with the IoT server High Pass
3 Extract Device information from the enrolled device High Pass
4 Persist enrolled device details on a database High Pass
5 Save hierarchy related metadata in database along with enrolled High Pass
device
6 Change device status based on the last contact time of an enrolled High Pass
device
7 Display a Hierarchical visualization of the arrangement of enrolled High Pass

devices in the IoT network
8 Retrieve data related to the hierarchical arrangement such as list of High Pass
children of a parent device
9 Disenroll an enrolled device Low Pass
ll Nuwan Jayawardene | 2015235

Appendix – OSGi method to retrieve all stored EnrollmentInfo metadata of devices
CC. Appendix – OSGi method to retrieve all stored EnrollmentInfo

metadata of devices
mm Nuwan Jayawardene | 2015235

Appendix – OSGi method to return list of upstream parents a child device is connected to
DD. Appendix – OSGi method to return list of upstream parents a child

device is connected to
nn Nuwan Jayawardene | 2015235

Appendix – JavaScript function to retrieve client-secret and client-id
EE. Appendix – JavaScript function to retrieve client-secret and client-id
oo Nuwan Jayawardene | 2015235

Appendix – JavaScript function to retrieve refresh token
FF. Appendix – JavaScript function to retrieve refresh token
pp Nuwan Jayawardene | 2015235

Appendix – Detailed Functional test cases
GG. Appendix – Detailed Functional test cases
Id Functionality Test Case Result Pass

rate
F1 Verifying user credentials of device 100%
F1.1 Accept User A payload with user credentials is sent to the Pass
credentials server and accepted
F1.2 Extract User details Extracts the relevant user details from the Pass
from payload payload to identify the user
F1.3 Verifies service Verifies of the user of the device requesting Pass
accessibility enrollment has authorization to access the
server
F2 Enrolling a device 100%
F2.1 Issue client tokens The server issues client secret and id token Pass
to the user credentials provided
F2.2 Issue refresh token Based on client tokens, the server issues a Pass
refresh token that allows device to access
services of the server through endpoints.
F2.3 Accept enrollment Accept the enrollment payload sent to the Pass
payload server from the device
F2.4 Save details Save device metadata from in the enrollment Pass
payload in persistent memory in the server
F3 Retrieving enrolled device 100%
F3.1 Secured REST Deploy secure but accessible REST endpoint Pass
endpoint
F3.2 Expose device data Expose device data to authorized parties via Pass
that REST endpoint
qq Nuwan Jayawardene | 2015235

Appendix – Detailed Functional test cases
F4 Retrieving hierarchical metadata from enrolled device 100%
F4.1 Access device data Access enrolled device metadata/data from Pass
persistent storage
F4.2 Format retrieved data Format retrieved data in a presentable Pass

manner such as JSON
F4.3 Present data Present the formatted data via REST Pass
endpoints to be accessed by the UI or
external parties
F5 Visualizing hierarchical network arrangement 100%
F5.1 Extract metadata Extract all relevant hierarchical device Pass

metadata from persistent storage
F5.2 Format retrieved data Format retrieved data in a presentable Pass

manner such as JSON
F5.3 Expose data Expose the data via a REST endpoint Pass
F5.4 Draw Hierarchical Render the hierarchical visualization on the Pass

visualization front-end using a dedicated library
rr Nuwan Jayawardene | 2015235

Appendix – Project Risks
HH. Appendix – Project Risks
Risk Risk Risk Description Risk Mitigation

ID Category
1 Requirements Needing to make drastic Have a well-established and
changes to the requirements thought-out set of
requirements before
beginning development work
2 Technical Failing to stay updated with Converse with experts in the
the technologies associated field and get thorough
with the field feedback on the state of
technologies
3 Technical Being unable to achieve the Doing research beforehand to
required level of find alternative methods to
functionality to showcase the achieve a problematic area
performance of the
architecture
4 Technical Losing data due to Taking regular backups and
unforeseen hardware or increasing the backup
software failures and issues frequency with the
immediacy of the deadline.
5 Planning Failing to complete the Having a clear plan as to
required components in the which components of the
allocated time frame research have the highest
priority so those can be
completed at the earliest
6 Planning Getting stuck on a certain Sticking to the project plan
component during prototype and taking immediate
development measures either to bypass or
find alternative methods to
complete the task at hand.
ss Nuwan Jayawardene | 2015235

Bibliography
Bibliography
Aazam, M. & Huh, E.-N., 2014. Fog Computing and Smart Gateway Based. Barcelona, IEEE Computer
Society.
Aazam, M., Hung, P. P. & Huh, E.-N., 2014. Smart Gateway Based Communication for. Singapore,
IEEE.
Allaire, J., 2009. The first 'Internet Phone' circa 1996. [Online]
Available at: https://www.brightcove.com/en/blog/2009/03/first-internet-phone-circa-1996
[Accessed April 2018].
Alturki, B., Reiff-Margeniec, S. & Perera, C., 2017. A Hybrid Approach for Data Analytics for Internet of
Things. Linz, s.n.
Astley, M., Agha, G. A. & Sturman, D. C., 2001. Customizable Middleware For Modular Distributed
Software. Communications of the ACM, 44(5), pp. 99-107.
Atwood, J., 2006. Code Smells. [Online]
Available at: https://blog.codinghorror.com/code-smells/
[Accessed 10 April 2019].
Beck, M. T., Werner, M., Feld, S. & Schimper, T., 2014. Mobile Edge Computing: A Taxonomy. Lisbon,
Portugal, IARIA.
Bonomi, F., Milito, R., Zhu, J. & Addepalli, S., 2012. Fog computing and its role in the internet of things.
Helsinki, Finland, s.n.
Butler, B., 2017. What is edge computing and how it’s changing the network. [Online]
Available at: https://www.networkworld.com/article/3224893/internet-of-things/what-is-edge-computing-
and-how-it-s-changing-the-network.html
[Accessed July 2018].
Chen, E. et al., 2014. OAuth Demystified for Mobile Application Developers. Scottsdale, ACM.
Desai, P., Sheth, A. & Anantharam, P., 2015. Semantic Gateway as a Service architecture for IoT. New
York, IEEE.
Din, J. & Idris, S., 2009. Object-Oriented Design Process Model. IJCSNS International Journal of
Computer Science and Network Security, 9(10), pp. 71-79.
Eclipse Foundation, 2017. Eclipse Kapura Github repository. [Online]
Available at: https://github.com/eclipse/kapua
[Accessed 11 12 2018].
Eclipse Foundation, 2017. The Three Software Stacks Required for IoT Architectures. 1st ed.
s.l.:eclipse.org.
Eclipse Foundation, n.d. Eclipse Kapua Github repository. [Online]
Available at: https://github.com/eclipse/kapua
[Accessed 11 12 2018].
tt Nuwan Jayawardene | 2015235

Bibliography
Eclipse Foundation, n.d. Eclipse Kura™ Documentation. [Online]

Available at: https://eclipse.github.io/kura/intro/intro.html
[Accessed 12 12 2018].
Entgra.io, 2019. Community. [Online]
Available at: https://entgra.io/community
Eppler, M., 2006. A Comparison between Concept Maps, Mind Maps, Conceptual Diagrams, and Visual
Metaphors as Complementary Tools for Knowledge Construction and Sharing. Information Visualization,
5(3), pp. 202-210.
Eurotech, 2013. Kura - OSGi-based Application Framework for M2M Service Gateways. [Online]
Available at: https://www.eclipse.org/proposals/technology.kura/
[Accessed 12 12 2018].
Francis, B., 2017. Building the Web of Things. [Online]
Available at: https://hacks.mozilla.org/2017/06/building-the-web-of-things/
[Accessed 8 September 2018].
Francis, B., 2018. How to build your own private smart home with a Raspberry Pi and Mozilla’s Things
Gateway. [Online]
Available at: https://hacks.mozilla.org/2018/02/how-to-build-your-own-private-smart-home-with-a-
raspberry-pi-and-mozillas-things-gateway/
Francis, B., 2018. Things Gateway 0.5 packed full of new features, including experimental smart
assistant. [Online]
Available at: https://hacks.mozilla.org/2018/08/things-gateway-0-5-features-experimental-smart-assistant/
Gremban, K., Street, C., Shahan, R. & Vaes, K., 2017. How an IoT Edge device can be used as a
gateway. [Online]
Available at: https://docs.microsoft.com/en-us/azure/iot-edge/iot-edge-as-gateway
[Accessed 6 9 2018].
Guest, G., Bunce, A. & Johnson, L., 2006. How Many Interviews Are Enough?: An Experiment with
Data Saturation and Variability. Field Methods 2006, 18(1), pp. 59-82.
Guru99, n.d. What is Functional Testing? Types & Examples (Complete Tutorial). [Online]
Available at: https://www.guru99.com/functional-testing.html
Hammi, B. et al., 2015. Internet of Things (IoT) Technologies for Smart Cities. IET Research Journals,
pp. 1-14.
Jing, Q. et al., 2014. Security of the Internet of Things: perspectives and challenges. Wireless Networks,
20(8), p. 2481–2501.
Khan, R., Khan, S. U., Zaheer, R. & Khan, S., 2012. Future Internet: The Internet of Things Architecture,
Possible Applications and Key Challenges. Islamabad, IEEE.
uu Nuwan Jayawardene | 2015235

Bibliography
Maltseva, D., 2018. Why use Swagger for creating and documenting APIs. [Online]
Available at: https://dev.to/dianamaltseva8/why-use-swagger-for-creating-and-documenting-apis-115l
Manricks, G., 2013. Instant Handlebars.Js. 2 ed. s.l.:Packt Publishing.
Microsoft Corporation, 2018. Microsoft Azure IoT Reference Architecture. 2.0 ed. s.l.:Microsoft.
Milito, R., Natarajan, P., Zhu, J. & Bonomi, F., 2014. Fog Computing: A Platform for Internet of Things
and Analytics. In: N. Bessis & C. Dobre, eds. Big Data and Internet of Things: A Roadmap for Smart
Environments. s.l.:Springer International Publishing, pp. 169-186.
Miller, P., 2018. What is edge computing?. [Online]
Available at: https://www.theverge.com/circuitbreaker/2018/5/7/17327584/edge-computing-cloud-
google-microsoft-apple-amazon
[Accessed July 2018].
Mozilla Developer docs, 2019. HTTP response status codes. [Online]
Available at: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
Olson, J. E., 2003. Data Quality: The Accuracy Dimension. s.l.:Elsevier Science.
Patel, K. & Patel, S., 2016. Internet of Things-IOT: Definition, Characteristics, Architecture, Enabling
Technologies, Application & Future Challenges. International Journal of Engineering Science and
Computing, 6(5), pp. 6122-6131.
Paul, D. & Altar, A., 2013. Designing an MVC Model for Rapid Web Application Development. Zadar,
Curran.
Perera, R., 2018. Story of the Unified UI Framework (UUF). [Online]
Available at: https://medium.com/@rasika90/story-of-the-unified-ui-framework-uuf-42457db018a
Perumal, T., Datta, S. K. & Bonnet, C., 2015. IoT Device Management Framework for Smart Home
Scenarios. s.l., s.n.
Ramel, D., 2018. Azure IoT Edge Now Generally Available and Open Source. [Online]
Available at: https://visualstudiomagazine.com/articles/2018/06/28/azure-iot-edge.aspx
[Accessed 31 12 2018].
Rouse, M., 2016. Internet of Things(IoT). [Online]
Available at: https://internetofthingsagenda.techtarget.com/definition/Internet-of-Things-IoT
[Accessed April 2018].
RP, S., 2018. How To Choose Your IoT Platform Architecture?. [Online]
Available at: https://www.expresscomputer.in/news/how-to-choose-your-iot-platform-architecture/18291/
[Accessed 20 1 2019].
Satyanarayanan, M., 2017. The Emergence of Edge Computing. Computing in Science & Engineering,
January, pp. 30-39.
vv Nuwan Jayawardene | 2015235

Bibliography
SCOTT , L., 1998. Frameworks for Component-Based Client/Server Computing. ACM Computing
Surveys, 30(1), pp. 3-27.
Shi, W. et al., 2016. Edge Computing: Vision and Challenges. IEEE INTERNET OF THINGS JOURNAL,
3(5), pp. 637-646.
Smith, T. S., 1996. UNIFORM RESOURCE LOCATORS (URLs): POWERFUL REFERENCE TOOLS
FOR LIBRARIANS AND INFORMATION PROFESSIONALS, Kent: Kent State University .
Surbhi, 2016. Difference Between Questionnaire and Interview. [Online]
Available at: https://keydifferences.com/difference-between-questionnaire-and-interview.html
[Accessed 3 March 2019].
Tragos, E. Z. et al., 2016. Trusted IoT in the Complex Landscape of Governance, Security, Privacy,
Availability and Safety. Singapore, s.n.
Wickramasinghe, A. et al., 2011. Effectiveness of mind maps as a learning tool for medical students.
South East Asian Journal of Medical Education , 1(1), pp. 30-32.
WSO2, 2018. General Data Protection Regulation for WSO2 IoT Server. [Online]
Available at:
https://docs.wso2.com/display/IOTS330/General+Data+Protection+Regulation+for+WSO2+IoT+Server
WSO2, 2018. The WSO2 Integration Agile Platform - Overview. [Online]
Available at: https://wso2.com/platform
WSO2, 2018. WSO2 IoT Server documentation - Overview. [Online]
Available at: https://docs.wso2.com/display/IOTS330/Overview
Young, R. R., 2002. Recommended Requirements Gathering Practices. In: Risky Requirements. s.l.:s.n.,
pp. 9-12.
Zanella, A. et al., 2014. Internet of Things for Smart Cities. IEEE INTERNET OF THINGS JOURNAL,
01(1), pp. 22-32.
ww Nuwan Jayawardene | 2015235

Nuwan - FYP

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Nuwan - FYP

Uploaded by

Copyright:

Available Formats

INFORMATICS INSTITUTE OF TECHNOLOGY

Metadata model for supporting hierarchical

Submitted in partial fulfillment of the requirements for the

Full Name of Student: Nuwan Stanislaus Gomis Abeysingha Jayawardene

IIT Registration No: 2015235

UoW Registration No: W1608508

Signature: ___________________ Date: ____________________

ii Nuwan Jayawardene | 2015235

Keywords: Fog Networks, Edge Computing, Edge Gateways, Smart City

iii Nuwan Jayawardene | 2015235

iv Nuwan Jayawardene | 2015235

v Nuwan Jayawardene | 2015235

2.6 Chapter Summary ...................................................................................................................11

vi Nuwan Jayawardene | 2015235

5.3 Design Methodology ..............................................................................................................47

vii Nuwan Jayawardene | 2015235

7.5.1 TM1: Unit Testing ..........................................................................................................74

viii Nuwan Jayawardene | 2015235

9.4.1 Project Aim Achievements ............................................................................................ 101

ix Nuwan Jayawardene | 2015235

BB. Appendix – System Testing results .............................................................................................. ll

Figure 1.1 - Basic Rich picture of implementation ................................................................................... 5

x Nuwan Jayawardene | 2015235

Figure 5.2 - Sequence Diagram: Enroll Device .......................................................................................53

Table 1.1 - Outline of the Thesis document structure ............................................................................... 6

xi Nuwan Jayawardene | 2015235

CPU..................................................................................................................... Central Processing Unit

xii Nuwan Jayawardene | 2015235

1.1 Chapter Overview

1 Nuwan Jayawardene | 2015235

1.2.1 Edge Computing and the central Cloud Server

2 Nuwan Jayawardene | 2015235

1.3 Problem and Motivation

3 Nuwan Jayawardene | 2015235

1.4 Aim and Objectives

1.4.2 Research Objectives

1.5 Features of Prototype

4 Nuwan Jayawardene | 2015235

Figure 1.1 - Basic Rich picture of implementation

1.6 Outline of Thesis

5 Nuwan Jayawardene | 2015235

Table 1.1 - Outline of the Thesis document structure

1.7 Resource Requirements

Hardware Requirements Software Requirements

Quad Core Processor Unix based Operating System

6 Nuwan Jayawardene | 2015235

8GB minimum RAM Oracle Java SE Development Kit (JDK)

5GB disk space Apache Maven

Microsoft Word/G Suite

Table 1.2 - Resource requirement list

1.8 Chapter Summary

7 Nuwan Jayawardene | 2015235

2.1 Chapter Overview

2.2 Software Development Methodology

2.2.1 Waterfall Development Model

2.2.2 Rapid Application Development Model

8 Nuwan Jayawardene | 2015235

2.2.3 Iterative Model

2.2.4 Selection of a methodology

Waterfall • Simplistic and straightforward in • Difficult to perform any changes

9 Nuwan Jayawardene | 2015235

Rapid • Quick development cycles mean • Prototype driven instead of

Table 2.1 - Comparison of Development Methodologies

By considering the above, several key points were formulated;

Signature: _ Date: __