IT training scalable architecture for the internet of things khotailieu

Scalable
Architecture for the
Internet of Things
An Introduction to Data-Driven
Computing Platforms

Ervin Varga, Draško Drašković,
& Dejan Mijic



Scalable Architecture for
the Internet of Things

An Introduction to Data-Driven
Computing Platforms

Ervin Varga, Draško Drašković,
and Dejan Mijić

Beijing

Boston Farnham Sebastopol

Tokyo


Scalable Architecture for the Internet of Things
by Ervin Varga, Dejan Mijić, and Draško Drašković
Copyright © 2018 O’Reilly Media, Inc. All rights reserved.
Printed in the United States of America.

Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA
95472.
O’Reilly books may be purchased for educational, business, or sales promotional use.
Online editions are also available for most titles ( For more
information, contact our corporate/institutional sales department: 800-998-9938 or


Editor: Brian Foster
Production Editor: Melanie Yarbrough
Copyeditor: Jasmine Kwityn
Proofreader: Charles Roumeliotis
February 2018:

Interior Designer: David Futato
Cover Designer: Karen Montgomery
Illustrator: Rebecca Demarest

First Edition

Revision History for the First Edition
2018-02-13: First Release
The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Scalable Architec‐
ture for the Internet of Things, the cover image, and related trade dress are trade‐
marks of O’Reilly Media, Inc.
While the publisher and the authors have used good faith efforts to ensure that the
information and instructions contained in this work are accurate, the publisher and
the authors disclaim all responsibility for errors or omissions, including without
limitation responsibility for damages resulting from the use of or reliance on this
work. Use of the information and instructions contained in this work is at your own
risk. If any code samples or other technology this work contains or describes is sub‐

ject to open source licenses or the intellectual property rights of others, it is your
responsibility to ensure that your use thereof complies with such licenses and/or
rights.

978-1-492-02412-5
[LSI]


Table of Contents

Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
1. Internet of Things (IoT). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Introduction to IoT
The Architecture of a Data-Driven Solution
Evaluation Criteria for IoT Platforms
Active Load Control Case Study
Summary

1
4
12
14
22

2. Amazon Web Services (AWS) IoT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Introduction to AWS IoT
Overview of the Architecture
Setting Up the Ecosystem
Event Management and System Dashboards
Application Integration Layer

Security
Building an End-to-End Example
Summary

25
27
31
39
40
41
41
42

3. Microsoft Azure IoT Suite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Introduction to Microsoft Azure IoT Suite
Overview of the Architecture
Setting Up the Ecosystem
Event Management and System Dashboards
Application Integration Layer
Security
Building an End-to-End Example

45
46
52
58
63
70
73
iii

Summary

74

4. Mainflux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Introduction to Mainflux
Overview of the Architecture
Event Management and System Dashboards
Security
Building an End-to-End Example
Summary

77
78
83
86
88
94

5. EdgeX Foundry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Introduction to EdgeX Foundry
Overview of the Architecture
Setting Up the Ecosystem
Event Management and System Dashboards
Application Integration Layer
Security
Building an End-to-End Example
Summary

97
99
102
104
107
109
110
112

A. Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

iv

| Table of Contents


Preface

The Internet of Things (IoT) is heralded as the fourth industrial
internet, and participate in machine-to-machine and machine-toperson use cases on a massive scale. The common trait of all these
IoT use cases is to efficiently handle the following essential jobs:
connecting and managing billions of devices, transferring data over
the network, storing data, and processing data. Apparently, data has
a central place, so we may freely announce that IoT is data-driven.
Computing associated with data is there to squeeze out knowledge,
and provide the ability to automate many aspects of our environ‐
ment. The objective is to deliver new value-added business services
that were not possible before.
Any cutting-edge technology/paradigm, like IoT, is surrounded by a

vivid, dynamic, and growing community. The participants seek to
gain knowledge and experience in the novel domain. The interrela‐
ted environment is permeated with various overlapping technologi‐
cal alternatives that are frequently accompanied by hype. It isn’t
surprising then to encounter terms like Massive IoT, Industrial IoT,
Critical IoT, Web of Things (WoT), and Internet of Everything
(IoE). Furthermore, we encounter stuff like digitization on one
hand, and Invisible Computing, Transparent Computing, Edge
Computing, and Fog Computing on the other (these are some of the
most popular phrases). Our aim is to find a common denominator
among these elements, rather than delve into a convoluted elabora‐
tion of how to properly classify them.
For example, in terms of device connectivity we may classify lowpower network technologies into the following broad categories:
unlicensed spectrum for short-range and mixed-performance com‐

v


munication (WiFi, Bluetooth, Zigbee, etc.), unlicensed spectrum for
mixed-range and low-performance communication (SIGFOX,
LoRa, etc.), and cellular for mixed-range and mixed-performance
communication (EC-GSM, LTE-M, NB-IoT, etc.). Regardless of
which category they belong to, all of these technologies seek to bal‐
ance dependability, performance (throughput and latency), and
cost/complexity. If you want to learn more about how cellular net‐
works are adapted to the needs of IoT, read the Ericsson whitepaper
Cellular Networks for Massive IoT.
A principal enabler of massive adoption of IoT use cases is the exis‐
tence of an efficient IoT platform. It combines device connection/
management and service enablement functions. It may be treated as

a key building block in IoT solutions. Custom applications are craf‐
ted on top of an IoT platform that handles all the mundane work
regarding devices as well as data analytic capabilities. An IoT plat‐
form is like middleware for distributed applications. IoT platforms
are the topic of this report, and are superb examples of scalable
architectures for IoT. For a good commentary about the importance
of IoT platforms and data management in IoT, refer to The Platform
Transformation—How IoT Will Change IT, and When by Matthew J.
Perry (O’Reilly).
It is impossible to provide exhaustive coverage of IoT platforms in
this short report. Instead, we have chosen to focus on the following
goals:
• Teach you how to become proficient with some concrete IoT
platforms.
• Help you sharpen your knowledge by suggesting many refer‐
ences for further study.
• Offer different perspectives on IoT topics.
• Provide some comparative analysis between various industrial
IoT platforms.

vi

|

Preface


This work is structured as a report rather than a fullblown book. Consequently, its content is presented in a
condensed form with many references for further
reading. We have tried to provide enough content for

you to understand the material even without consult‐
ing outside resources. Nonetheless, to gain deeper
knowledge you will need to review the various books,
webinars, and blogs we highlight throughout this
report.

Contents of This Book
This report is comprised of five chapters:
• Chapter 1 is a general introduction into the world of IoT.
• Chapter 2 presents Amazon’s AWS IoT platform.
• Chapter 3 presents Microsoft’s Azure IoT platform.
• Chapter 4 presents the Mainflux IoT platform.
• Chapter 5 presents the EdgeX Foundry edge component.
Chapters Chapter 2 through Chapter 5 follow a similar outline, and
a table is provided at the end of each of those chapters to summarize
the IoT platform discussed therein (using the set of evaluation crite‐
ria set forth in Chapter 1). There is also a Conclusion that wraps up
this report.

Preface

|

vii



CHAPTER 1

Internet of Things (IoT)

This chapter provides a general overview of the Internet of Things
(IoT). We will cover the data-driven computing paradigm and asso‐
ciated architectures, desired quality attributes of an IoT platform,
and evaluation criteria for IoT platforms. In addition, we’ll examine
a comparative case study showing the transformative power of the
IoT (in this case, in the smart grid domain).

Introduction to IoT
What does it mean to be driven by data? Data-driven business and
engineering solutions are becoming the norm in our modern soci‐
ety. Only a couple of centuries ago, counting and calculation (a syn‐
onym for computing at that time) were done manually, just as datagathering efforts were. This manual labor had obvious scalability
issues. The appearance of a difference engine (an automatic
mechanical calculator) in the 19th century heralded a new age from
the point of view of computing.1 The early attempts to build viable
mechanical automata ran into serious problems, and the mechanical
approach was abandoned in the favor of an electrical variant. In
both cases the principal goal was to boost the computing power.
Computing is meaningless without data; thus, data must be some‐
how coupled with computing nodes. The recent advancements in

1 Let us disregard some ancient calculators, like abacuses, to make the discussion more

focused.

1


communication technologies, especially the emergence of the inter‐

net, enabled data to emanate from everywhere. This significantly
pushed our attention toward distributed solutions for reasons of
performance, scalability, dependability, and data storage capacity.2
Nevertheless, the confinement of computing power inside large data
centers cannot alone handle ever-increasing data volume. The net‐
work would become a clear bottleneck for data movement scenarios
of such magnitude. Pervasive computing (a.k.a. ubiquitous comput‐
ing) tries to disseminate computational capability into end devices,
which are frequently sources of data, too. The notion of performing
computation everywhere, preferably near data (this is also related to
edge computing), opens novel data-processing possibilities. The
desire to encompass as much data as possible drives our thinking
toward ingenious scalable solutions.
It is easy to apprehend the truism that more data means bigger
potential to discover new facts and expand knowledge. Naturally,
the abundance of data demands more complex and performant
computations. The overarching goal is to gain a competitive advan‐
tage either in research or business. Figure 1-1 shows an indefinite
data-driven computing cycle, where data denotes raw ingredients,
and computation represents a goal-oriented activity to synthetize
higher level inferences.

Figure 1-1. Data-driven inference cycle
Let’s review each phase of the cycle shown in Figure 1-1:

2 Moore’s law isn’t sustainable anymore, because of physical limitations of electronic cir‐

cuits. The industry solution is provided in the form of parallelism revolving around
multiple processing units (multicore CPUs, GPUs, computing clusters, etc.) that obey
Amdahl’s law.

2

|

Chapter 1: Internet of Things (IoT)


Specify objectives
Data collection and handling must be based on use cases. It can‐
not happen by chance just by listening on any conceivable data
source, and piling up records. The data should have a clear pur‐
pose that gives meaning to the associated computation. This
planning phase can be carried out either by a human, or a
machine governed by artificial intelligence.
Acquire data
Data gathering shall be economical from the viewpoint of both
resources and time. Moreover, it must be technically feasible,
resulting in data of proper quality. The data acquisition
endeavor must also include an analysis of required data trans‐
formations, propose a viable data serialization format, and spec‐
ify the necessary communication channels/protocols. Many of
these aspects should be considered during the previous plan‐
ning phase, as a kind of feasibility study.
Compute
This is the data-crunching activity, where various programs are
run against the collected data. The set of programs may include
reporting tools, machine learning facilities, data transformation
pipelines, and the like. The outcome is usually a new set of data
that properly encodes the synthetized knowledge.

Incorporate result
The new knowledge, gained by doing the previous computation,
should trigger appropriate actions, and give rise to plans with
possibly elevated expectations. This is the final phase before a
new cycle begins, bootstrapped by the results of the one before
it.
The following well-known axioms are fundamental in every data
mining work:
• With great power comes great responsibility.
• Correlation does not mean causation.
The aim of empowering the data-driven inference cycle is to reap
benefits by discovering patterns in data. These patterns usually indi‐
cate some significant relationships between entities/events repre‐
sented by data. Executing extensive data analysis operations without
being aware of the dangers of early conclusions may induce more
Introduction to IoT

|

3


harm than advantages. There are ample examples on the internet of
how things may go wrong (some of the most embarrassing mistakes
were even made by data scientists). For example, if you find a corre‐
lation between shoe sizes and intelligence, then it doesn’t imply that
a person with bigger feet is smarter than a person with smaller ones.
In this case, age as a latent variable is missing from the model. You
can find more information in Practical Statistics for Data Scientists
by Andrew Bruce and Peter Bruce (O’Reilly).

The Architecture of a Data-Driven Solution
The architecture plays a central role in any data-driven software sys‐
tem. The architecture bundles together pertinent quality attributes
of the system,3 and allows reasoning about the system before build‐
ing it. As data-driven computing tackles innovative technologies it is
important to bring in technological considerations early in the
architecture. One viable approach to craft a proper architecture of
this type may revolve around Architecture Tradeoff Analysis
Method (ATAM) 3.0. ATAM 3.0 combines an analysis of both qual‐
ity characteristics and technology. This is explained in detail in
Designing Software Architectures: A Practical Approach by Rick Kaz‐
man and Humberto Cervantes (Addison-Wesley).
The IoT embraces devices, connectivity, data acquisition/processing
platforms, and custom applications to realize the data-driven com‐
puting paradigm. Edge computing is a strategy that delivers com‐
puting near data instead of moving everything into a central
location (usually a cloud-based data center). Figure 1-2 depicts the
module decomposition view of a typical data-driven solution. For a
good introduction into IoT, with many examples of vertical seg‐
ments benefitting from IoT, consult IoT Fundamentals: Networking
Technologies, Protocols, and Use Cases for the Internet of Things by
David Hanes et al. (Cisco Press).

3 For an overview, consult the ISO/IEC 25010 standard quality model.

4

|

Chapter 1: Internet of Things (IoT)


Figure 1-2. The three-tiered conceptual model of a data-driven system.
This nicely illustrates the device handling (left side) and service enable‐
ment (right side) functions of an IoT platform.
The bidirectional arrow in Figure 1-2 signifies the communication
paths between tiers and marks the level of achieved computational
distribution. If the edge is on the far left, then it entails autonomous,
smart devices (like smartphones) with decent computing power to
run complex applications. In converse, the devices are dumb data
sources with intermediary hubs passing data in both directions to/
from applications. This situation is reminiscent of a desktop data‐
base application (for example, implemented in Microsoft Access)
with a remote database file lurking on a file server. A regular query
would instigate needless data transfers over the network; this
approach cannot scale.
A device may take the following three roles in a combined fashion:
data source, data processor, and data sink. Devices could run in an
isolated fashion, or connect with peers forming a dynamic mesh
network. A group of devices can constitute a swarm, where each
member acts according to both the global objective, and the action/
state of its neighbors.4
An IoT platform is primarily responsible for composing the data
segment, and computing that segment into a unified element. The
IoT platform may execute on-premises, and/or in the cloud. The
principal responsibilities of the platform are as follows:
• Provides communication bindings with devices
4 A swarm may be controlled via the swarm programming technique. You can try out the

freely available Buzz programming language designed for robot swarms. It supports
both bottom-up and top-down approaches of swarm programming, depending on
whether the focus is on individual robots, or on the group.

The Architecture of a Data-Driven Solution

|

5


• Implements the rules engine for data segmentation and
response processing
• Stores temporary and permanent data
• Executes various analytics, and generates reports
• Exposes service APIs for management, supervision, interopera‐
bility, and custom application development
The rules engine may employ a domain-specific language to express
condition→action relations. The rules may be predefined, or selfmanaged through machine learning mechanisms. Rules may also
govern input data classification and routing; events (messages)
arriving on various communication channels may have different pri‐
orities, meaning, and response timeliness.
Multiple IoT platforms could be interlinked for data sharing pur‐
poses. Applications built on top of such interconnected IoT plat‐
forms may combine data from different domains, and leverage data
affinities. The case study we’ll examine at the end of this chapter
exemplifies the benefits of interoperation of IoT platforms.
A custom IoT application that uses the publicized services of an IoT
platform may focus on business use cases instead of dealing with
device management and raw data handling. Applications are segre‐

gated into verticals, each concerned with the matching domain
(smart grid, healthcare, autonomous vehicles, agriculture, etc.). It is
important to remember that the same data channel could participate
in multiple verticals at the same time. For example, weather forecast
data is useful in many realms. Furthermore, the same device can
deliver different data for a multitude of verticals. A smartphone can
be a data source for many healthcare functions5 while executing
other disparate IoT-related applications in parallel.
Figure 1-2 is a logical view of a data-driven system, since multiple
deployments are possible. For example, a powerful device may host

5 An interesting IoT use case from the healthcare sector is published in A Software

Shrink: Apps and Wearables Could Usher in an Era of Digital Psychiatry by John Torous
(IEEE Spectrum). The idea is to use an IoT platform inside a smart house to control the
inner environment, depending on the patient’s physical condition. The input is pro‐
vided by a smartphone. For example, ambient light may turn off during periods of
sleep, or an emergency call could be initiated in case of a serious health situation
requiring immediate treatment.

6

|

Chapter 1: Internet of Things (IoT)


an IoT platform to perform locally as much data processing as possi‐
ble. It is also conceivable to bundle together an IoT platform with
applications on the same computer. However, the crucial point is

pertaining to efficient interconnectedness of components both logi‐
cally and physically. The deployment scenario must support this
ambition. The merit is perhaps best codified in a variant of Metcal‐
fe’s law, which states that the value of such a networked solution is
proportional to the square of its connected elements.
Currently, there are two IoT-specific formal development methods,
both of which stress the importance of architecture: Ignite and IoT
Methodology. You may read more about Ignite in Enterprise IoT:
Strategies and Best Practices for Connected Products and Services by
Dirk Slama et al. (O’Reilly). The IoT Methodology introduces the
IoT OSI reference model. It is comprised of five layers (the IP hour‐
glass model has only four6). These layers are device, connectivity,
middleware, services, and applications. The three middle layers are
mainly embodied by the IoT platform (see Figure 1-2). For a
description of how to reuse practices from various methods through
essentialization, refer to Is There a Single Method for the Internet of
Things? by Ivar Jacobson et al. (Communications of the ACM).

Desired Quality Attributes of an IoT Platform
To avoid confusion regarding the word quality, we will use Steve
McConnell’s practical and succinct definition: “Conformance to
requirements, stated and implied.” The second part of the definition
addresses potential requirements errors; thus, quality isn’t only
about adhering to specified stuff, nor is a narrow view toward func‐
tional requirements. The focus here is on important product7 nonfunctional requirements embodied by an architecture of the datadriven system. These quality characteristics are known as -illities,
although there are exceptions, like performance.

6 In this model, the IP sits in the middle, with a multitude of link layer protocols below

it, and different transport and application protocols above it. Such an arrangement is

visually evocative of an hourglass.

7 There are also project characteristics (such as predictability, repeatability, visibility), but

these are not relevant when analyzing the development processes of data-driven solu‐
tions.

The Architecture of a Data-Driven Solution

|

7


The quality model cannot be expressed by simply including all nonfunctional requirements. Some quality attributes support each other,
and others are in opposition. A canonical example for the latter is
security and usability. Table 1-1 gives a sample of the trade-off
matrix for some common quality attributes relevant for IoT plat‐
forms. The double-sided arrow designates a typically supporting
pair, while the cross sign marks a typically conflicting combination
(empty cells mean indifference). Adaptability and usability are user
visible; the rest are internally visible. Efficiency belongs to both cate‐
gories.
Table 1-1. Trade-offs among various quality attributes
Adaptability
Portability ↔

Portability.

Usability

↔

Security

❌

❌

Usability

❌

❌

Safety

❌

Security
Safety

↔

Efficiency

❌

❌

Instead of just declaring the significant attributes of an IoT platform,
it is important to study the reasons behind the selection. Our start‐
ing point is performance as a function of throughput and latency.
Throughput is a generic indicator pertaining to the amount of data
handled per unit of time. Eliminating redundant data movements
surely benefits throughput; the same is true for data processing
speed. Latency becomes critical in real-time IoT systems, where the
law of physics (speed of light) also kick in. This parameter dictates
the responsiveness of the data-driven architecture, and can be
related to the length of a feedback loop (i.e., the round-trip time
between the device and application). For a good overview, consult
Responsive Data Architecture for the Internet of Things by David Lin‐
thicum (IEEE Computer).
Figure 1-3 shows how applying the principles of edge computing
reduces data response times (the segments referred to on the picture
are data and compute). As the computation moves toward the
source of data, there is less latency between event (message) genera‐
tion and handling. This reaction time is especially crucial in realtime systems, where late responses are useless (for the sake of
simplicity, further classification into hard and soft real-time systems
is skipped).
8

|

Chapter 1: Internet of Things (IoT)


Figure 1-3. The liaison between the distance of segments, and latency
The computation in this case is represented by facilities offered by
an IoT platform. The intelligence built into the device complements

the features available in the IoT platform. The following list shows
those high-priority quality attributes that buttress the deployment of
an IoT platform in multiple places:
Portability
The IoT platform must be portable if it is destined to heteroge‐
neous nodes. This may be achieved by leveraging virtualization
technologies (for example, by using the Java Virtual Machine),
or packing the deliverable into host operating system oblivious
form (like the Docker image).
Adaptability
To support an extensive list of devices, and provide more ser‐
vice APIs for integration purposes, it is mandatory to have an
adaptable IoT platform. The possible usage scenarios are vast,
and cannot be predetermined in advance.
Usability
To reduce the deployment hassle, and quickly get users up and
running with an IoT platform, it must be in a user-friendly form
in multiple aspects. This includes the management, supervision,
and reporting facilities.
Efficiency
The IoT platform should ideally have a small footprint, employ
advanced data storage technologies, and require adequate hard‐
ware resources to be usable in both real time and regular con‐
texts. To move the computation near devices it should run on
less capable hardware (for example, inside a smart meter or
smartphone).
The Architecture of a Data-Driven Solution

|

9


Safety
The IoT platform should never do something it isn’t supposed
to do. The principal game changer regarding software in the
domain of IoT is safety coupled with accountability and respon‐
sibility. Any applied automation through an IoT solution means
that we have faith in the system and trust that it will never do
harm in the environment.
Security
The IoT platform must ensure proper device management (via
authentication and authorization mechanisms), data privacy,
integrity, and confidentiality via secure communication and
encryption of data. Security is especially crucial for an IoT plat‐
form, as it will rely more on automated security.
Additionally, an IoT platform must be highly available, and main‐
tainable (includes the testability property). All these attributes
should be balanced against the intended usage, and incorporated
into the architecture. The chapters that follow describe some con‐
crete IoT platforms that balance these quality characteristics in dif‐
ferent ways.

Universal Device Communication Protocols
IoT is predominantly about devices and their data. This section
gives a briefing about some wide-ranging device communication
protocols (peculiar edge protocols—such as BACnet, DLMS/
COSEM, OSLP, Modbus, etc.—are omitted):
HTTP
The protocol of the web. Many devices are directly or indirectly

accessible via SOAP or REST; indirection relies on intermedia‐
ries, like the Echelon SmartServer.
WebSocket
Enables bidirectional communication between parties over a
single TCP connection. The primary objective is to eliminate
the client’s need to open multiple HTTP connections toward the
server.
Message Queuing Telemetry Transport (MQTT)
This is a lightweight publish/subscribe messaging protocol.

10

|

Chapter 1: Internet of Things (IoT)


Constrained Application Protocol (CoAP)
A specialized web transfer protocol for use with constrained
nodes and unreliable networks. It mimics the REST API for
small devices.
It is also possible to extend the set of fieldbus protocols to include
non-IP variants. Such extension is plausible in supporting legacy
devices, and for those that cannot afford to implement a full-blown
IP stack. You may read about an interesting proposal, based upon
the chirp device data stream format, in Rethinking the Internet of
Things: A Scalable Approach to Connecting Everything by Francis
daCosta (Apress). Another possibility is to leverage IoT-customized
IP variants, like IPv6 with the LoWPAN adaptation layer.

Key communication patterns
Most machine-to-machine (M2M) protocols support request/
response and publish/subscribe communication modes. Knowing
when to use them is essential to achieve proper reaction times,
increase dependability, and improve performance.
The request/response mechanism requires an established channel
between parties. It may be used for individualized information
exchanges (such as asking the central node for a security key, or
retrieving “personalized” schedules from the coordinator node). The
request/response mode isn’t plausible when some condition (event)
must trigger dozens of devices to execute an action. In this case,
there are two general choices (both suffer from scalability issues,
and introduce a single point of failure):
• Let the initiating device loop over its device list, and send the
matching command to each device.
• Send the event to the central node, and let it notify relevant
devices in sequence.
The publish/subscribe pattern is inherently decentralized. Figure 1-4
shows a sequence of actions that accompany this mechanism. The
publish/subscribe mode creates fast, local action loops that don’t
swamp the central node. Moreover, a triggering device doesn’t need
to maintain a separate device list for each event. The protocol layer
is optimized to manage the device network; thus it can efficiently
handle registrations and notifications.

The Architecture of a Data-Driven Solution

|

11

Figure 1-4. UML sequence diagram illustrating the pub/sub pattern

Evaluation Criteria for IoT Platforms
Besides the previously enumerated quality attributes, there should
be well-defined IoT platform evaluation criteria for comparison pur‐
poses. The next set of traits include both functional and nonfunctional aspects. Security is separately emphasized, because of its
importance (it is a subcategory of dependability). Each subsequent
chapter concludes with concrete values for these properties, in rela‐
tion to the corresponding IoT platform:
Device bindings
This specifies the supported communication protocols of an IoT
platform regarding devices (for example, HTTP, MQTT, etc.).

12

|

Chapter 1: Internet of Things (IoT)


Analytics
The type of technology used to perform analytical calculations.
Analytics is the mechanism to synthetize higher-level knowl‐
edge from raw data. Rules may be associated with such derived
values. For more information, you may read Internet of Things
and Data Analytics Handbook by Hwaiyu Geng (Wiley).
Visualization
This defines the offered technologies for data visualization (for

example, an HTML5-based UI dashboard).
Rules engine and alarming
Elaborates how rules and alarms are defined on top of accumu‐
lated data. The ability to easily customize conditions to trigger
alarms, and rules to associate actions with events, is of utmost
significance. Hardcoding these (or using similarly rigid con‐
structs) isn’t an option. Domain-specific languages are an
attractive choice here.
Security
The set of supported security technologies by an IoT platform.
This covers securing device–platform, platform–platform, and
platform–application communication channels, controlling
access to data via authentication/authorization, and so on. For
an excellent treatment of IoT security, consult Abusing the Inter‐
net of Things by Nitesh Dhanjani (O’Reilly), as well as The Inter‐
net of Risky Things by Sean Smith (O’Reilly).
License
This defines the type of license attached to the IoT platform
(like Apache 2.0), and whether an IoT platform is freely avail‐
able or not.
Deployment technology
Describes the applied deployment technology (for example,
Web archive, Docker image, operating system dependent pack‐
age manager file, etc.).
Auto-scaling
Enrolls the set of technologies and techniques that allows scal‐
ing of an IoT platform. This aspect is tightly related to availabil‐
ity. If an internal service or component becomes unresponsive,
then such a condition must be auto-detected and acted upon
(typically by summoning a new instance to preserve the desired

Evaluation Criteria for IoT Platforms

|

13


capacity). Obviously, keeping the determined number of serv‐
ices up also improves availability.
Device data persistence
Defines what database technologies (or other data storage
mechanisms) are used by an IoT platform to store raw device
data.
Management database
Defines what database technologies (or other data storage
mechanisms) are used by an IoT platform to store
management-related data, including derived values.
Implementation language
Specifies the main implementation programming language for
an IoT platform (for example, Go, Java, etc.).
Data model
Describes the event (message) format for communicating with
devices (like Sensor Markup Language).

Active Load Control Case Study
The smart grid (one of the research areas of the authors) is an
undoubted vertical domain that benefits from IoT. This case study
gives a compelling insight into how IoT may transform the electrical
power system. More specifically, the following topics are exempli‐
fied:

• The centralized, top-down, and rigid non-IoT solution, and the
problems engendered by following this approach
• The tiered, bottom-up, and flexible IoT solution, and the associ‐
ated benefits
• The idea behind IoT distributed intelligence, and hierarchical
control loops
• The power behind efficient IoT analytics
• IoT’s stratified architectural style, and the potential extensions
enabled by such design
• Multidomain applications that leverage IoT interoperability

14

|

Chapter 1: Internet of Things (IoT)


Due to space limitations, the text here contains gross
simplifications; the goal is to err on the side of accu‐
racy to bring forward the essential points in a straight‐
forward manner. For a broader overview of IoT case
studies and protocols (including an extensive treat‐
ment of the smart grid), refer to The Internet of Things:
Key Applications and Protocols by Olivier Hersent et al.
(Wiley).

Electricity consumption is represented by a load profile (LP). It is a
pattern of electricity usage for a customer, or a group of customers,
over some period. Usually LPs are created daily with 15-minute res‐

olution (mirroring the consumption measurement sampling
period). Each LP is tightly linked to its context (a.k.a. as the load
condition), which characterizes the matching period (for example,
price of electricity, power network condition, season, etc.). Individ‐
ual LPs may be aggregated; this is how a region’s behavior is estima‐
ted. The accrued historical power usage data, in the form of LPs, is
used for short-term and long-term planning purposes. The aim is to
keep production in sync with demand. Any serious disbalance may
endanger the stability of the power grid.
Balancing production with demand is a function of available power
generator types. For example, it is quite expensive to follow huge
variations in demand with thermal power stations. On the other
hand, renewable energy sources (like wind and solar) are of lower
capability and volatile. Therefore, it is desirable to smooth out fluc‐
tuations in load by influencing the consumption. This can be done
by switching on/off the appliances according to some logic.
Figure 1-5 shows a good (conceived) and bad LP from the viewpoint
of harmonizing production with demand. It also illustrates an allow‐
able range of alterations of the actual LP from the devised one. Peaks
are especially troublesome; thus, most control actions target them
first.

Active Load Control Case Study

|

15