IT training scalable architecture for the internet of things khotailieu

1 Introduction to IoT 1 The Architecture of a Data-Driven Solution 4 Evaluation Criteria for IoT Platforms 12 Active Load Control Case Study 14 Summary 22 2.. In addition, we’ll examine

Trang 1

Ervin Varga, Draško Drašković,

& Dejan Mijic

Trang 3

Ervin Varga, Draško Drašković,

and Dejan Mijić

Scalable Architecture for the Internet of Things

An Introduction to Data-Driven

Computing Platforms

Boston Farnham Sebastopol Tokyo

Beijing Boston Farnham Sebastopol Tokyo

Beijing

Trang 4

[LSI]

Scalable Architecture for the Internet of Things

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

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 (http://oreilly.com/safari) For more information, contact our corporate/institutional sales department: 800-998-9938 or

corporate@oreilly.com.

Editor: Brian Foster

Production Editor: Melanie Yarbrough

Copyeditor: Jasmine Kwityn

Proofreader: Charles Roumeliotis

Interior Designer: David Futato

Cover Designer: Karen Montgomery

Illustrator: Rebecca Demarest February 2018: 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.

Trang 5

Table of Contents

Preface v

1 Internet of Things (IoT) 1

Introduction to IoT 1

The Architecture of a Data-Driven Solution 4

Evaluation Criteria for IoT Platforms 12

Active Load Control Case Study 14

Summary 22

2 Amazon Web Services (AWS) IoT 25

Introduction to AWS IoT 25

Overview of the Architecture 27

Setting Up the Ecosystem 31

Event Management and System Dashboards 39

Application Integration Layer 40

Security 41

Building an End-to-End Example 41

Summary 42

3 Microsoft Azure IoT Suite 45

Introduction to Microsoft Azure IoT Suite 45

Security 70

iii

Trang 6

Summary 74

4 Mainflux 77

Introduction to Mainflux 77

Security 86

Summary 94

5 EdgeX Foundry 97

Introduction to EdgeX Foundry 97

Security 109

Summary 112

A Conclusion 117

iv | Table of Contents

Trang 7

The Internet of Things (IoT) is heralded as the fourth industrialinternet, and participate in machine-to-machine and machine-to-person use cases on a massive scale The common trait of all theseIoT use cases is to efficiently handle the following essential jobs:connecting and managing billions of devices, transferring data overthe 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 servicesthat were not possible before

Any cutting-edge technology/paradigm, like IoT, is surrounded by avivid, dynamic, and growing community The participants seek togain 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’tsurprising 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 onehand, and Invisible Computing, Transparent Computing, EdgeComputing, and Fog Computing on the other (these are some of themost popular phrases) Our aim is to find a common denominatoramong 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 power network technologies into the following broad categories:unlicensed spectrum for short-range and mixed-performance com‐

low-v

Trang 8

munication (WiFi, Bluetooth, Zigbee, etc.), unlicensed spectrum formixed-range and low-performance communication (SIGFOX,LoRa, etc.), and cellular for mixed-range and mixed-performancecommunication (EC-GSM, LTE-M, NB-IoT, etc.) Regardless ofwhich category they belong to, all of these technologies seek to bal‐ance dependability, performance (throughput and latency), andcost/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 workregarding devices as well as data analytic capabilities An IoT plat‐form is like middleware for distributed applications IoT platformsare the topic of this report, and are superb examples of scalablearchitectures 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 inthis short report Instead, we have chosen to focus on the followinggoals:

• Teach you how to become proficient with some concrete IoTplatforms

• 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 industrialIoT platforms

vi | Preface

Trang 9

This work is structured as a report rather than a

full-blown 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 summarizethe IoT platform discussed therein (using the set of evaluation crite‐ria set forth in Chapter 1) There is also a Conclusion that wraps upthis report

Preface | vii

Trang 11

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

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 theIoT (in this case, in the smart grid domain)

Introduction to IoT

What does it mean to be driven by data? Data-driven business andengineering 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 data-gathering efforts were This manual labor had obvious scalabilityissues The appearance of a difference engine (an automaticmechanical calculator) in the 19th century heralded a new age fromthe point of view of computing.1 The early attempts to build viablemechanical automata ran into serious problems, and the mechanicalapproach was abandoned in the favor of an electrical variant Inboth 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

Trang 12

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.

communication technologies, especially the emergence of the inter‐net, enabled data to emanate from everywhere This significantlypushed our attention toward distributed solutions for reasons ofperformance, scalability, dependability, and data storage capacity.2Nevertheless, the confinement of computing power inside large datacenters 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 performingcomputation everywhere, preferably near data (this is also related toedge computing), opens novel data-processing possibilities Thedesire to encompass as much data as possible drives our thinkingtoward ingenious scalable solutions

It is easy to apprehend the truism that more data means biggerpotential to discover new facts and expand knowledge Naturally,the abundance of data demands more complex and performantcomputations The overarching goal is to gain a competitive advan‐tage either in research or business Figure 1-1 shows an indefinitedata-driven computing cycle, where data denotes raw ingredients,and computation represents a goal-oriented activity to synthetizehigher level inferences

Figure 1-1 Data-driven inference cycle

Let’s review each phase of the cycle shown in Figure 1-1:

2 | Chapter 1: Internet of Things (IoT)

Trang 13

Specify objectives

Data collection and handling must be based on use cases It can‐not happen by chance just by listening on any conceivable datasource, and piling up records The data should have a clear pur‐pose that gives meaning to the associated computation Thisplanning phase can be carried out either by a human, or amachine governed by artificial intelligence

Acquire data

Data gathering shall be economical from the viewpoint of bothresources and time Moreover, it must be technically feasible,resulting in data of proper quality The data acquisitionendeavor 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 ofthese 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 arerun against the collected data The set of programs may includereporting tools, machine learning facilities, data transformationpipelines, and the like The outcome is usually a new set of datathat 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 withpossibly elevated expectations This is the final phase before anew cycle begins, bootstrapped by the results of the one beforeit

The following well-known axioms are fundamental in every datamining work:

• With great power comes great responsibility

• Correlation does not mean causation

The aim of empowering the data-driven inference cycle is to reapbenefits 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 withoutbeing aware of the dangers of early conclusions may induce more

Introduction to IoT | 3

Trang 14

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

harm than advantages There are ample examples on the internet ofhow things may go wrong (some of the most embarrassing mistakeswere 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 Youcan 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 isimportant to bring in technological considerations early in thearchitecture One viable approach to craft a proper architecture ofthis type may revolve around Architecture Tradeoff AnalysisMethod (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/processingplatforms, 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 centrallocation (usually a cloud-based data center) Figure 1-2 depicts themodule decomposition view of a typical data-driven solution For agood 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 byDavid Hanes et al (Cisco Press)

Trang 15

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.

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 communicationpaths between tiers and marks the level of achieved computationaldistribution If the edge is on the far left, then it entails autonomous,smart devices (like smartphones) with decent computing power torun complex applications In converse, the devices are dumb datasources 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 querywould instigate needless data transfers over the network; thisapproach 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 anisolated fashion, or connect with peers forming a dynamic meshnetwork A group of devices can constitute a swarm, where eachmember acts according to both the global objective, and the action/state of its neighbors.4

An IoT platform is primarily responsible for composing the datasegment, and computing that segment into a unified element TheIoT platform may execute on-premises, and/or in the cloud Theprincipal responsibilities of the platform are as follows:

• Provides communication bindings with devices

The Architecture of a Data-Driven Solution | 5

Trang 16

5An 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.

• Implements the rules engine for data segmentation andresponse 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 expresscondition→action relations The rules may be predefined, or self-managed through machine learning mechanisms Rules may alsogovern 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 dataaffinities The case study we’ll examine at the end of this chapterexemplifies the benefits of interoperation of IoT platforms

A custom IoT application that uses the publicized services of an IoTplatform may focus on business use cases instead of dealing withdevice 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 isimportant to remember that the same data channel could participate

in multiple verticals at the same time For example, weather forecastdata is useful in many realms Furthermore, the same device candeliver different data for a multitude of verticals A smartphone can

be a data source for many healthcare functions5 while executingother disparate IoT-related applications in parallel

Figure 1-2 is a logical view of a data-driven system, since multipledeployments are possible For example, a powerful device may host

Trang 17

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.

an IoT platform to perform locally as much data processing as possi‐ble It is also conceivable to bundle together an IoT platform withapplications on the same computer However, the crucial point ispertaining to efficient interconnectedness of components both logi‐cally and physically The deployment scenario must support thisambition The merit is perhaps best codified in a variant of Metcal‐fe’s law, which states that the value of such a networked solution isproportional 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 byDirk 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 aremainly embodied by the IoT platform (see Figure 1-2) For adescription 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 torequirements, stated and implied.” The second part of the definitionaddresses potential requirements errors; thus, quality isn’t onlyabout adhering to specified stuff, nor is a narrow view toward func‐tional requirements The focus here is on important product7 non-functional requirements embodied by an architecture of the data-

driven system These quality characteristics are known as -illities,

although there are exceptions, like performance

Trang 18

The quality model cannot be expressed by simply including all functional requirements Some quality attributes support each other,and others are in opposition A canonical example for the latter issecurity and usability Table 1-1 gives a sample of the trade-offmatrix for some common quality attributes relevant for IoT plat‐forms The double-sided arrow designates a typically supportingpair, while the cross sign marks a typically conflicting combination(empty cells mean indifference) Adaptability and usability are uservisible; the rest are internally visible Efficiency belongs to both cate‐gories.

non-Table 1-1 Trade-offs among various quality attributes

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 datahandled per unit of time Eliminating redundant data movementssurely benefits throughput; the same is true for data processingspeed Latency becomes critical in real-time IoT systems, where thelaw of physics (speed of light) also kick in This parameter dictatesthe responsiveness of the data-driven architecture, and can berelated to the length of a feedback loop (i.e., the round-trip timebetween 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 computingreduces data response times (the segments referred to on the pictureare data and compute) As the computation moves toward thesource of data, there is less latency between event (message) genera‐tion and handling This reaction time is especially crucial in real-time systems, where late responses are useless (for the sake ofsimplicity, further classification into hard and soft real-time systems

is skipped)

Trang 19

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 complementsthe features available in the IoT platform The following list showsthose 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 virtualizationtechnologies (for example, by using the Java Virtual Machine),

or packing the deliverable into host operating system obliviousform (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 anadaptable IoT platform The possible usage scenarios are vast,and cannot be predetermined in advance

Trang 20

The IoT platform should never do something it isn’t supposed

to do The principal game changer regarding software in thedomain of IoT is safety coupled with accountability and respon‐sibility Any applied automation through an IoT solution meansthat we have faith in the system and trust that it will never doharm in the environment

Security

The IoT platform must ensure proper device management (viaauthentication and authorization mechanisms), data privacy,integrity, and confidentiality via secure communication andencryption 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 attributesshould be balanced against the intended usage, and incorporatedinto 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 sectiongives a briefing about some wide-ranging device communicationprotocols (peculiar edge protocols—such as BACnet, DLMS/COSEM, OSLP, Modbus, etc.—are omitted):

HTTP

The protocol of the web Many devices are directly or indirectlyaccessible via SOAP or REST; indirection relies on intermedia‐ries, like the Echelon SmartServer

WebSocket

Enables bidirectional communication between parties over asingle TCP connection The primary objective is to eliminatethe client’s need to open multiple HTTP connections toward theserver

Message Queuing Telemetry Transport (MQTT)

This is a lightweight publish/subscribe messaging protocol

Trang 21

Constrained Application Protocol (CoAP)

A specialized web transfer protocol for use with constrainednodes and unreliable networks It mimics the REST API forsmall devices

It is also possible to extend the set of fieldbus protocols to includenon-IP variants Such extension is plausible in supporting legacydevices, 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 FrancisdaCosta (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 Knowingwhen to use them is essential to achieve proper reaction times,increase dependability, and improve performance

The request/response mechanism requires an established channelbetween parties It may be used for individualized informationexchanges (such as asking the central node for a security key, orretrieving “personalized” schedules from the coordinator node) Therequest/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 thematching command to each device

• Send the event to the central node, and let it notify relevantdevices in sequence

The publish/subscribe pattern is inherently decentralized Figure 1-4shows a sequence of actions that accompany this mechanism Thepublish/subscribe mode creates fast, local action loops that don’tswamp 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 efficientlyhandle registrations and notifications

Trang 22

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 non-functional aspects Security is separately emphasized, because of itsimportance (it is a subcategory of dependability) Each subsequentchapter concludes with concrete values for these properties, in rela‐tion to the corresponding IoT platform:

Trang 23

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 derivedvalues 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 (forexample, 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 triggeralarms, and rules to associate actions with events, is of utmostsignificance Hardcoding these (or using similarly rigid con‐structs) isn’t an option Domain-specific languages are anattractive choice here

Security

The set of supported security technologies by an IoT platform.This covers securing device–platform, platform–platform, andplatform–application communication channels, controllingaccess 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

Trang 24

capacity) Obviously, keeping the determined number of serv‐ices up also improves availability.

Device data persistence

Defines what database technologies (or other data storagemechanisms) are used by an IoT platform to store raw devicedata

Management database

Defines what database technologies (or other data storagemechanisms) are used by an IoT platform to storemanagement-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 withdevices (like Sensor Markup Language)

Active Load Control Case Study

The smart grid (one of the research areas of the authors) is anundoubted vertical domain that benefits from IoT This case studygives a compelling insight into how IoT may transform the electricalpower system More specifically, the following topics are exempli‐fied:

• The centralized, top-down, and rigid non-IoT solution, and theproblems 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 hierarchicalcontrol loops

• The power behind efficient IoT analytics

• IoT’s stratified architectural style, and the potential extensionsenabled by such design

• Multidomain applications that leverage IoT interoperability

Trang 25

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 apattern 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 samplingperiod) Each LP is tightly linked to its context (a.k.a as the loadcondition), 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, isused for short-term and long-term planning purposes The aim is tokeep production in sync with demand Any serious disbalance mayendanger the stability of the power grid

Balancing production with demand is a function of available powergenerator types For example, it is quite expensive to follow hugevariations in demand with thermal power stations On the otherhand, renewable energy sources (like wind and solar) are of lowercapability 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 Peaksare especially troublesome; thus, most control actions target themfirst

Active Load Control Case Study | 15

Trang 26

Figure 1-5 Load control and planning based upon LPs

Non-IoT Traditional Grid

In a traditional power grid, the basic idea is to drive only the mostinfluential appliances (water heater, electric heater with thermalaccumulation, air conditioning unit, etc.) via predefined schedules

A schedule contains instructions on when to turn on/off the specificsort of appliance throughout a day Appliances cannot be individu‐ally modeled (for reasons that will become apparent from the equa‐tions we’ll look at momentarily), hence they are grouped by type.The aspiration is to shape the actual LPs to conform with the plan‐ned ones

An effectual load management initiative must include flexible pric‐ing, too Balancing the power grid alone cannot justify the requiredinvestments, as the profit margins would be negligible for moststakeholders Nonetheless, extending the model to discuss dynamicpricing would make it overly complex

The management of the power grid is organized in a federated fash‐ion, as depicted in Figure 1-6; there are multiple levels of planningand control The global load control management (LMC) is dealingwith countrywide strategic activities The distribution LMC is han‐dling state (region)-wide tasks Finally, the local LMC is coveringsome municipal area Each level coordinates the execution of itssubordinate entities The control flow is from top to bottom, whilestatus feedback flows upward Each level does possess someautonomy, but pricing and generation facilities are treated on the

Trang 27

8 There is a substantial nerd factor in this section, but you surely don’t need to under‐ stand the equations to comprehend the material These are put here only for illustra‐ tion purposes, to signify the amount of hassle associated with fixed, centralized load control management.

top Moreover, below LLMC everything runs in passive mode (wedisregard any local controller inside an appliance, like a thermostat)

Figure 1-6 Hierarchical load control management

The active load control job can be formulated as a linear program‐ming problem using the following set of expressions:8

Objective function: minP p

The unknown peak load after applying control actions

Trang 28

The effect of applying control on appliances of type u at interval

i using scheme j(u)

x

The variable number of appliances of type u that should be con‐

trolled by scheme j(u)

The number of appliances of type u

An additional concern is how to model each appliance type Appli‐ances capable of accumulating energy tend to consume a lot ofpower (for a short period) after being switched on again This must

be considered to avoid excessive peaks This phenomenon is illus‐trated in Figure 1-7 All in all, averaging the behavior of all applian‐ces of a given type, under some generic scheme, introducesadditional inaccuracy in the planning process

Trang 29

9 It is possible to leverage an iterative interior point primal-dual algorithm (like Karmar‐ kar’s), but this may only shift the limits by some modest amount.

Figure 1-7 The outcome of turning on an appliance that stores energy

We can formulate the following conclusions about this non-IoT sce‐nario:

• Control is unidirectional (from a utility company toward cus‐tomers), although it may leverage some mechanism to remotelycommand appliances

• Appliances are modeled using crude approximations

• It is hard to optimally cope with unpredictable production that

is introduced by alternative energy sources

• The method has serious scalability deficiencies, as the sheernumber of appliances may easily render the linear program‐ming approach inapt.9

• Integration with other vertical domains can only occur at thenearest LMCs, which are far away from end users

• There is no way to establish autonomous, local electricity mar‐kets with real-time pricing

• Planning and control must involve humans; it isn’t possible tohave entirely machine-to-machine (M2M) use cases

Trang 30

IoT-Enabled Smart Grid

Perhaps the best way to highlight the crucial differences is to refor‐mulate the previous list in light of an IoT-driven grid:

• Planning and control is obeying the context; it is based onactual power usage data fully considering current load condi‐tions

• The behavior of appliances is inferred, rather than modeledbeforehand, using local historical data via the analytics module

of an IoT platform

• It is manageable to optimally cope with irregular production;for example, a smart house may administer its generation capa‐bilities autonomously, and align it with local consumption

• The method has no inherent scalability deficiencies, as the pro‐cessing is distributed, and happens near data

• Integration with other vertical domains can occur at any level

• It is possible to establish autonomous, local electricity marketswith real-time pricing

• Planning and control don’t solely rely on humans; it is possible

to have M2M use cases

The feedback control loops are hierarchically arranged, and resem‐ble the tree structure shown in Figure 1-6; the boxes there should besubstituted in the following manner: LLMC→smart house,DLMC→microgrid, and GLMS→smart grid The main point is thatthe intelligence is distributed, and upper layers send hints to subor‐dinate elements regarding how to behave But the lower layers don’tpassively wait for commands They act according to the local condi‐tions In some way, the IoT decommissions the command-and-control management of the power grid in favor of a morecooperative and flexible style

A smart house may store excessive energy (usually gained throughsolar panels) in electric vehicles This accumulated power can be uti‐lized when prices are high, or to compensate for a sudden increase

in load without pulling power from the neighborhood It is also pos‐sible to establish dynamic energy markets inside a microgrid Thesmart meters may negotiate the energy exchange circumstancesalone There is an interesting initiative to leverage blockchain tech‐nology to record such transactions For more information, refer to

Trang 31

Energy Trading for Fun and Profit by Morgen E Peck and David

Wagman (IEEE Spectrum)

It is also possible to coordinate electricity and gas consumptions byestablishing data exchanges between vertical domains The electric‐ity and gas smart meters may communicate price information toevaluate and control the spending of various energy types to reduceexpenses The weather forecast data (another domain) may help inpredicting future energy demands; a smart meter may decide that it

is now better to keep the stored energy instead of pumping it backinto the grid

An excellent example of a completely integrated multidomain IoT

solution is known as the smart city It is oriented toward tracking

and coordinating consumption of various resources (like electricity,gas, water, etc.), monitoring traffic conditions, alerting about envi‐ronmental hazards, and more The goal is to use disparate sources ofinformation to align individual behavior with the interests of all

benefactors It is a well-known fact from the tragedy of the commons

economic theory that purely local optimizations may negativelyimpact the group

Open Smart Grid Plaform

The Open Smart Grid Platform (OSGP) is a freely available based IoT platform for the smart grid It provides a set of SOAP-based web services (each service’s API is specified in WSDL), thatcover the major business areas of a smart grid These APIs are lever‐aged by custom applications, shielding them from device handlingresponsibilities The following domains are exposed by the platform:

Tariff switching

Allows tariff switching

Microgrids

Monitors and controls microgrids

Trang 32

OSGP is comprised of the following layers:

Summary

The IoT revolves around structured and mesh device and IoT plat‐form networks to deliver functions that are greater in scope than thesum of its parts (reflecting each element’s capability separately) Theconstituent technologies cannot be admired as sensational or revo‐lutionary Most of them have existed for quite a long time Nonethe‐less, their judicious assembly into a unified whole radiates withsupremacy The vast possibilities offered by the IoT are still onlybeginning to be exploited

This chapter barely scratches the surface of this topic, and insteadoffers easily digestible learning material about the IoT It is sprinkledwith references for your own continuous study The power gridcomparative case study illuminates how IoT profoundly changes thescene; it realizes concepts and ideas that were inconceivable in thepast The following chapters briefly introduce some popular IoTplatforms to make the IoT exposition even more pragmatic andcomprehensible

Trang 33

There are many further variations on the theme of the IoT Forexample, the application of advanced web technologies (such aslinked data and the semantic web) on top of the IoT is called theWoT It additionally boosts the IoT’s integrability and interoperabil‐ity possibilities by letting the machines themselves figure out themeaning of events (messages) You can read more about WoT in

Building the Web of Things with Examples in Node.js and Raspberry

Pi by Dominique D Guinard and Vlad M Trifa (Manning)

A related development in enhancing M2M interoperations is thesemantic sensor network It benefits devices by increasing their abil‐ity to create ad hoc mesh networks For more information, you

should read the Internet of Things: From Internet-Scale Sensing to Smart Services by Dimitrios Georgakopoulos and Prem Prakash

Jayaraman (Computing, Springer)

In the following chapters of this report, you will find descriptions ofconcrete IoT platforms that will make this general introductionmore tangible We will elaborate on two commercial cloud-centricproducts (with proprietary edge extensions), an open source sus‐tainable and unified IoT platform (it can execute on the edge, onpremises, and in the cloud), and a special edge component (whichaims to standardize the edge of the network) Each of the subse‐quent chapters will include practical instructions to become produc‐tive with the corresponding IoT product

Summary | 23

Trang 35

CHAPTER 2

Amazon Web Services (AWS) IoT

This chapter focuses on the Amazon Web Services (AWS) IoT plat‐form We will provide an overview of the architecture and discusssteps for setting up the ecosystem, event management and systemdashboards, the application integration layer, and security We willconclude by building an end-to-end example

Introduction to AWS IoT

AWS IoT is Amazon’s cloud-based IoT platform Its main purpose is

to gather data from a myriad of devices into the cloud for furtherprocessing in a scalable fashion AWS IoT supports the followingkey use cases, as depicted in Figure 2-1:

Communicate

Enables devices to securely communicate with cloud applica‐tions and each other using HTTP or MQTT (directly, or viaWebSocket) protocols AWS IoT may act as a protocol bridge, sodevices can talk to each other even if they don’t quack the sameprotocol The communication is usually bidirectional; devicesdeliver their telemetry data into the cloud, and receive controlcommands from the cloud

Execute Data Analytics

This is the core strength of AWS IoT, since data may be filtered,transformed, and acted upon using AWS’s scalable and rich set

of services AWS IoT may be interrelated with services, likeAmazon Simple Notification Service, Amazon Simple Queue

25

Trang 36

Service, Amazon Simple Storage Service, Amazon DynamoDB,Amazon Kinesis, Amazon Machine Learning, and AWSLambda More fine-tuned views can be implemented by lever‐aging Amazon Athena and Amazon QuickSight Such higher-level intelligences are invaluable for better decision making andsupervision of remote processes.

Manage Device

AWS IoT buttresses device shadowing, which emulates a virtuallive device for applications Under the hood, AWS IoT stores thelatest state of a device, and exposes it for read/write operations.Applications are oblivious as to whether the target device isonline or offline In the latter case, the AWS IoT will sync thevirtual state with the device once it appears online

Figure 2-1 Major use cases and actors of AWS IoT These use cases are applicable across many IoT platforms, so they are rather universal.

All interactions between actors and uses cases in Figure 2-1 happen

in a secure manner AWS IoT relies on certificates to authenticateparties, and uses AWS’s security features to enforce authorization.All external communication channels are encrypted for ensuringconfidentiality, integrity, and privacy of data

26 | Chapter 2: Amazon Web Services (AWS) IoT

Trang 37

AWS IoT should be treated as a special service that

interconnects devices with the rest of the AWS world

Therefore, it is possible to develop data lineage–agnos‐

tic applications that rely solely on background Amazon

cloud services Most often the solution utilizes both

AWS for advanced data analytics, and AWS IoT for

device management (to optimally govern devices’

behavior)

Overview of the Architecture

Figure 2-2 shows the major constituent elements of an AWS IoT sol‐ution:

Device (Thing)

This is the component (for example, sensor, actuator, smartappliance, microcontroller) that interacts with a physical envi‐ronment, and is interconnected to the AWS cloud The devicehosts a simple embedded application, which uses the AWS IoTDevice SDK to send/receive messages to/from AWS IoT

AWS IoT Edge (Greengrass stack)

AWS Greengrass is a reduced AWS ecosystem close to thematching set of devices The AWS Greengrass consists of theGreengrass core software (engine) and the associated SDK Thiscore may be deployed on a node-neighboring target device Thepertinent devices must form a Greengrass group with this dedi‐cated node The group appears as a unified device inside AWSIoT Devices may interact inside this group even while it is dis‐connected from the cloud The Greengrass core supports theAWS Lambda facility, so it is possible to develop applications toreact on locally important events, or filter traffic between devi‐ces and the cloud

Overview of the Architecture | 27

Trang 38

Rules Engine

Filters, transforms, and reacts to messages emanated from devi‐ces Its role is to decide what happens next based upon the mes‐sage payload (it supports an SQL-like language to peek into thecontent) One possibility is to forward the message furtherdown the AWS chain, and/or to emit a new message via themessage broker to relevant subscribers

Security Layer

Contains common security-related services to realize authenti‐cation, authorization, and secure communication between par‐ties (both externally and internally)

Device Registry

Stores pertinent resources interrelated with a device (like certifi‐cates, MQTT client identifiers, custom attributes) Registeringyour devices enhances security, and lessens the overall devicemanagement burden

Device Shadow & Service

Stores device state inside the cloud, and manages that state.Thanks to this service, a virtual device may appear for applica‐tions as a continuously online device

AWS and Applications

These are all the components that exist in the AWS irrespective

of AWS IoT The only exception is the class of AWS IoT–awareapplications that use the AWS IoT API or SDK

Trang 39

Figure 2-2 The architecture of the AWS IoT solution

The elements in Figure 2-2 are grouped, depending on where dataprocessing occurs, into the following categories:

• Device

• AWS IoT Edge

• AWS IoT

• AWS and applications

The ordering of groups is fundamental to understand scalability.Each bears a separate feedback loop, from fastest (device) towardslowest (AWS and applications) Let’s take a look at a concrete exam‐ple to better understand this Suppose you have a smart houseequipped with smoke detectors and sprinklers managed by a micro-controller (it could perform as a group coordinator) Here are themain responsibilities of each group for this circumstance:

Smoke Detector (Device)

Send regular health status information toward the group coor‐dinator Detect smoke In case of smoke, turn on the siren onthe detector, and publish an alarm message

Overview of the Architecture | 29

Trang 40

Sprinkler (Device)

Send regular health status information toward the group coor‐dinator Listen to published smoke alarm messages In case of asmoke alarm, open a valve to discharge water

Greengrass Group Coordinator (AWS IoT Edge)

Monitor the health status of devices In case of device malfunc‐tion, send an alert message toward AWS IoT Function as a mes‐sage broker In case of a smoke alarm, forward the messagetoward AWS IoT

AWS IoT

In case of a smoke alarm, initiate an automatic call to the firedepartment, and send a text message to the house owner Incase of a device failure, send a text message to the house owner.Persist unusual events into Amazon DynamoDB

AWS and applications

Provide various reports about unusual events

Figure 2-3 shows a sequence of actions in case of a fire Local actionsexecute much faster than background tasks inside the cloud Noticethat opening a valve happens in parallel to the stuff inside the AWScloud The cloud-induced latency can be critical in some use cases.For example, it would be too late to inform yourself about a fire bylooking at the database report

Định dạng
Số trang	129
Dung lượng	13,24 MB