ARCHITECTURE AND PROGRAMMING MODEL FOR THE SOCIAL INTERNET OF

THINGS

By

AHMED EZZELDIN KHALED

A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL

OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT

OF THE REQUIREMENTS FOR THE DEGREE OF

DOCTOR OF PHILOSOPHY

UNIVERSITY OF FLORIDA

2018

© 2018 Ahmed Ezzeldin Khaled

To my beloved family

4

ACKNOWLEDGMENTS

I agree that there are no words to truly describe the appreciation I have towards those

who supported and helped me. I owe my deepest gratitude to my advisor, Professor Abdelsalam

(Sumi) Helal for his continuous support, advice and help in the past several years. I was fortunate

to have Professor Helal as my supervisor and would like to thank him, first as my committee

chair, on his professional guidance and patience. He supported me a lot during my Ph.D. work.

And second, I would like to thank him as my advisor, for sharing some of his life experiences

that taught me extremely valuable life lessons.

I would like to thank Professor Ahmed Helmy on his valuable support and advice to me,

especially in the tough situations I faced during my Ph.D. journey. I also would like to thank my

committee members, Professor Ahmed Helmy, Professor My Thai, Professor Sartaj Sahni, and

Professor Sherif Ahmed Sherif, for their guidance and constructive comments during this

dissertation research.

Finally, I would like to thank my beloved family, Dr. Ezzeldin Khaled, Dr. Gehan

Hamada, and my brother, Dr. Adham Khaled, for always being there to provide unconditional

support and love.

5

TABLE OF CONTENTS

page

ACKNOWLEDGMENTS ...............................................................................................................4

LIST OF TABLES ...........................................................................................................................8

LIST OF FIGURES .........................................................................................................................9

LIST OF ABBREVIATIONS ........................................................................................................12

ABSTRACT ...................................................................................................................................13

CHAPTER

1 INTRODUCTION ..................................................................................................................15

Motivation ...............................................................................................................................15

Problem Statement and Current Challenges ...........................................................................18 Overview of the Proposed Framework ...................................................................................20 Research Objectives, Limitations and Scope ..........................................................................22

2 LITERATURE REVIEW .......................................................................................................24

Architecting the IoT ................................................................................................................24

Device Description Approaches ......................................................................................24

Device Taxonomies .........................................................................................................27

Atlas Middleware and Sensor Platform ...........................................................................28 Platforms and Architectures ............................................................................................30

Device Provisioning and Management Approaches ........................................................33 Programming the IoT ..............................................................................................................35

SIoT Programming Approaches ......................................................................................35

IoT Programming Models ...............................................................................................37

3 OVERVIEW OF THE PROPOSED APPROACHES ............................................................41

IoT Device Description Language (IoT-DDL) .......................................................................41

Atlas Thing Architecture ........................................................................................................42 Inter-Thing Relationships Programming Framework .............................................................44

Atlas Runtime-Interactive Development Environment (RIDE) .............................................45

4 IOT DEVICE DESCRIPTION LANGUAGE (IOT-DDL) ....................................................46

Thing Anatomy .......................................................................................................................46 Thing Taxonomy ....................................................................................................................47 Thing Definition and Requirements .......................................................................................49 IoT-DDL Specifications .........................................................................................................51

6

Atlas Thing ......................................................................................................................52

Thing Attachment ............................................................................................................54

Thing Entity .....................................................................................................................55 Service .............................................................................................................................55 Relationship .....................................................................................................................56

5 ATLAS THING ARCHITECTURE .......................................................................................57

Overview .................................................................................................................................57

IoT Operating System Services .......................................................................................59 Host Interface Layer ........................................................................................................60 Atlas IoT Platform ...........................................................................................................60

DDL sublayer ...........................................................................................................61 Tweeting sublayer ....................................................................................................61

Interface sublayer .....................................................................................................63 Device Provisioning and Management ...................................................................................65

Atlas Communication Framework ..........................................................................................68 Atlas IoT Topic Hierarchy ...............................................................................................69

Atlas IoT Protocol Translator ..........................................................................................74 Atlas Thing Architecture Interface Sublayer ...................................................................77

Atlas Thing Services ...............................................................................................................78

6 INTER-THING RELATIONSHIPS PROGRAMMING FRAMEWORK ............................82

Framework Primitives ............................................................................................................83

Thing Service ...................................................................................................................83

Thing Relationship ..........................................................................................................85

Recipe ..............................................................................................................................87 Framework Operators .............................................................................................................88

Filter ................................................................................................................................88 Match ...............................................................................................................................89 Evaluate ...........................................................................................................................90

Types of Relationships and Recipes .......................................................................................91 Types of Relationships and Formulizations ....................................................................91 Types of Recipes and Formulizations .............................................................................94

Atlas Application Tree and Semantic Rules ...........................................................................95 Poles of the Programming Model ...........................................................................................98

Vendor .............................................................................................................................98 Atlas Thing ......................................................................................................................98

Developer ........................................................................................................................99

7 ATLAS RUNTIME-INTERACTIVE DEVELOPMENT ENVIRONMENT (RIDE).........100

High-level Architecture of the Atlas RIDE ..........................................................................100

Application Engine ...............................................................................................................103 Application Manifest .....................................................................................................103 On-Cloud Application Generation ................................................................................105

7

Inference Engine ...................................................................................................................106

Relationship Inference Engine ......................................................................................107

Recipe Inference Engine ................................................................................................110 User application preferences ..................................................................................111 Recipe generator .....................................................................................................112 Closeness operator ..................................................................................................113

8 EXAMPLE OF IOT APPLICATIONS ................................................................................116

Application 1: Prepare Morning Coffee ...............................................................................116 Application 2: Someone is Watching Movie, Tilt the Window Blinds Down .....................119 Application 3: Smart Lock and Thermostat for Home Automation .....................................121

9 IMPLEMENTATION AND EVALUATION ......................................................................128

Supported IoT Things ...........................................................................................................128 Implementation of Atlas Thing Architecture and Atlas RIDE .............................................128

Provisioning and Management ......................................................................................129

Supporting Homogenous Communication ....................................................................130 Service Bundles .............................................................................................................130

Communication Interoperability ...................................................................................131 Secure Interactions ........................................................................................................136 Recipe Inference and Closeness Operator .....................................................................137

Evaluating Atlas Thing Architecture ....................................................................................141 Tweet Generation and Secure Interactions ....................................................................143

OMA Device Management and Communication Protocols ..........................................143

Analysis of the Benchmarking Study ............................................................................147

Evaluating Atlas Communication Interoperability ...............................................................150 Benchmarking Code Footprint and Energy Consumption ............................................150

Benchmarking Energy Consumption ............................................................................153 Evaluating Atlas RIDE .........................................................................................................160

10 CONCLUSION AND SUMMARY .....................................................................................174

LIST OF REFERENCES .............................................................................................................177

BIOGRAPHICAL SKETCH .......................................................................................................185

8

LIST OF TABLES

Table page

5-1 Atlas Topics for the MQTT protocol. ................................................................................64

5-2 Atlas Topics for the CoAP protocol...................................................................................65

5-3 Atlas IoT topic hierarchy. ..................................................................................................71

5-4 Translator interface functions. ...........................................................................................75

6-1 Atlas IoT application semantic rules..................................................................................97

9-1 IoT things specifications. .................................................................................................128

9-2 Benchmark time (in microseconds) and energy consumption (in watt seconds). ............144

9-3 Energy consumption (in watt seconds) measurements for OMA device manager

functionalities. ..................................................................................................................144

9-4 Energy consumption (in watt seconds) measurements for the different aspects of

MQTT protocol. ...............................................................................................................147

9-5 Energy consumption (in watt seconds) measurements for the different aspects of

CoAP protocol. ................................................................................................................147

9-6 Code footprint for the different features of the communication framework. ..................150

9-7 Energy consumption (in watt seconds) measurements for MQTT functionalities. .........152

9-8 Energy consumption (in watt seconds) measurements for CoAP functionalities. ...........152

9-9 Energy consumption (in watt seconds) measurements for REST functionalities. ...........152

9-10 The memory footprint of installing the generated Application .......................................166

9-11 Provisioning Generated Application with respect to the established recipe. ...................168

9-12 Expected number of generated recipes with respect to the expected number of

reported primitives by the things and the number of defined preferences. ......................171

9-13 Benchmark study on the recipe generator with different number of services,

relationships and preferences. ..........................................................................................171

9-14 Smart space with seven services and three relationships. ................................................171

9

LIST OF FIGURES

Figure page

1-1 IoT deployment scale. ........................................................................................................16

4-1 Thing structure. ..................................................................................................................48

4-2 Thing-Taxonomy in IoT ecosystem. ..................................................................................50

4-3 IoT-DDL specifications. ....................................................................................................53

5-1 Atlas thing architecture. .....................................................................................................59

5-2 Atlas objects’ tree. .............................................................................................................66

5-3 Device manager and OMA objects. ...................................................................................67

5-4 Smart space broker and HTTP REST-, CoAP- and MQTT- speaking things. ..................70

5-5 CoAP standard multicast and unicast communication.......................................................73

5-6 HTTP REST standard unicast communication. .................................................................74

5-7 Atlas protocol translator. ....................................................................................................75

5-8 Atlas Thing Architecture with focus on the interface sublayer. ........................................78

5-9 API engine structure. .........................................................................................................80

5-10 API structure. .....................................................................................................................80

6-1 Structure of the thing service (TS). ....................................................................................84

6-2 Structure of the thing relationship (TR). ............................................................................86

6-3 Structure of the recipe. .......................................................................................................87

6-4 Algorithmic representation for the Extend relationship.....................................................93

6-5 Atlas IoT application primitives and operator’s tree. ........................................................96

7-1 High-level architecture of the Atlas IoT RIDE. ...............................................................102

7-2 Structure of the application manifest. ..............................................................................104

7-3 Structure of the generated IoT mobile application. .........................................................105

7-4 The Inference Engine of the Atlas RIDE. ........................................................................106

10

7-5 Transitivity property. .......................................................................................................108

7-6 Exchange property. ..........................................................................................................109

7-7 Composition property. .....................................................................................................110

7-8 Proposed taxonomy of the possible human activities in a smart space. ..........................114

7-9 State transition diagram for the operation of Atlas RIDE................................................115

8-1 Prepare morning coffee. ...................................................................................................116

8-2 IoT-DDL snippet for the Beaglebone black Atlas thing with coffee maker entity. .........118

8-3 IoT-DDL snippet for contest relationship between two coffee maker services. ..............119

8-4 The TRa primitive for the support relationship between watching a movie and tilting

window blinds down. .......................................................................................................120

8-5 The Ra recipe to toggle the light of the living room and display the movie on the

screen when someone exists in the room. ........................................................................120

8-6 Atlas IoT application to tilt window blinds when someone is watching a movie. ..........121

8-7 IoT-DDL snippet for the thermostat Atlas thing along with the two offered services. ...123

8-8 Contest type relationship between services offered by different thermostats. .................124

8-9 IoT-DDL snippet for an offered service by the thermostat thing. ...................................124

8-10 The generated C code equivalent for the thermostat service. ..........................................125

8-11 Home automation Atlas IoT scenario. .............................................................................127

9-1 The network manager subsection for a CoAP-speaking Atlas thing. ..............................132

9-2 An off-thing Atlas protocol translator in the thing attachment section in the IoT-DDL

configuration file. .............................................................................................................132

9-3 Algorithmic representation of the communication framework. .......................................133

9-4 The method “Initialize” for the algorithmic representation of the framework. ...............133

9-5 The method “Event Handler” for the algorithmic representation of the framework. ......134

9-6 The method “Interaction Handler” for the algorithmic representation of the

framework. .......................................................................................................................135

9-7 Algorithmic representation of the recipe inference. ........................................................138

11

9-8 The method “Generate Recipes” for the algorithmic representation of the Inference

module..............................................................................................................................138

9-9 The method ‘Closeness operator’ for the algorithmic representation of the Inference

module..............................................................................................................................140

9-10 The method ‘Prune Recipes’ for the algorithmic representation of the Inference

module..............................................................................................................................141

9-11 Time comparison for device manager functionalities. .....................................................145

9-12 Time comparison for the different aspects of MQTT protocols. .....................................146

9-13 Time comparison for the different aspects of CoAP protocols. .......................................146

9-14 Atlas thing initialization phase and duty cycle. ...............................................................148

9-15 Atlas communication framework for homogenous speaking things. ...............................154

9-16 Atlas communication framework for heterogeneous speaking things. ............................156

9-17 Time comparison for the on-/off-thing Atlas translator for non-MQTT speaking

things. ...............................................................................................................................156

9-18 Comparing Atlas communication framework and Eclipse Ponte for homogenous

communicating things. .....................................................................................................158

9-19 Comparing Atlas communication framework and Eclipse Ponte for heterogeneous

communicating things. .....................................................................................................159

9-20 Testing scalability on a CoAP-speaking Atlas thing with on-thing Atlas protocol

translator. .........................................................................................................................160

9-21 The power consumption of an app with no active functionality on our Nexus 9

device. ..............................................................................................................................162

9-22 Explorer Resource Usage with respect to the number of offered services by Atlas

things. ...............................................................................................................................164

9-23 ARU with respect to the number of services in the recipe. .............................................167

9-24 A smart space with seven services and three relationships..............................................172

9-25 The selected subset of services and relationships that match the developer’s

preferences. ......................................................................................................................172

9-26 The generated recipes that follow the developer’s preferences. ......................................172

12

LIST OF ABBREVIATIONS

API Application Programming Interface

CEB Cloud-Edge-Beneath architecture

CoAP Constrained Application Protocol

DDL Device Description Language

DM Device Management

HTTP Hypertext Transfer Protocol

IoT Internet of Things

IPSO IP Smart Object

M2M Machine to Machine

MQTT Message Queuing Telemetry Transport

OMA-LwM2M Open Mobile Alliance Lightweight M2M Protocol

OS Operating System

OSGi Open Services Gateway initiative

REST Representational State Transfer

RIDE Runtime Interactive Development Environment

SIoT Social Internet of Things

SODA Service Oriented Device Architecture

13

Abstract of Dissertation Presented to the Graduate School

of the University of Florida in Partial Fulfillment of the

Requirements for the Degree of Doctor of Philosophy

ARCHITECTURE AND PROGRAMMING MODEL FOR THE SOCIAL INTERNET OF

THINGS

By

Ahmed Ezzeldin Khaled

August 2018

Chair: Abdelsalam (Sumi) Helal

Major: Computer Engineering

The success of Internet of Things (IoT) technology is about expanding ways for people to

interact, engage and program their smart homes or workplaces. Such success cannot be achieved

through simple connections between smart things, but will depend on how these things are

prepared to support this promising vision. We also argue that for the realization of innovative

IoT scenarios, application development environments should not be based only on available

services but also on relationships that logically and functionally tie these services

opportunistically. Social networking concepts converged into a new paradigm named Social IoT

(SIoT). SIoT evolves a social network for smart things through a set of social interactions for

new smart space programmability. However, IoT currently lacks a uniform way of describing the

thing which makes it difficult for the thing to integrate itself with the rest of the ecosystem, or for

the user or programmer to manage, configure and develop applications for such heterogeneous

things. At the same time, the current state of SIoT and smart space programmability present

limited social interactions and relationships that restricts proliferation of new applications.

We present the IoT Device Description Language (IoT-DDL) as a machine- and human-

readable descriptive language, which seeks to achieve thing seamless integration and

homogenization. To utilize such descriptive language, a lightweight architecture named Atlas

14

Thing Architecture is designed and implemented. The architecture provides new layers and

services to existing embedded operating systems, and introduces novel capabilities a thing must

have to be easily configured and managed, and to enable seamless engagement with other things

in powerful IoT scenarios. We introduce a novel inter-thing relationships programming

framework capable of describing how services can be combined to build applications explicitly

or opportunistically through a new set of service-level relationships. Atlas Runtime Interactive

Development Environment (RIDE) was designed, implemented and evaluated based on the Inter-

thing relationships framework to sense surrounding smart space, develop applications, and

glimpse new programming opportunities. Detailed IoT application scenarios are illustrated,

showing how the presented approaches perform within a run-time environment implemented on

real IoT hardware, and how Atlas RIDE supports easy application development by non-

programmer end-users.

15

CHAPTER 1

INTRODUCTION

Motivation

Smart spaces around us are becoming full of things! Things are the main ingredients and

the basic building block of the upcoming post-internet revolutionary technology named the

Internet of Things (IoT). IoT is the umbrella keyword to the new interdisciplinary evolving field

that adds more informative and interactive flavors to our life, enabled by the revolution of the

communication technologies and embedded devices. IoT is transforming the standard vision of

the Internet as a set of digital documents and links into a fully integrated Internet of services and

applications for smarter spaces [1][2][3]. Empowered by the fact that now almost all devices are

Internet connected, the overarching idea of IoT is to extend the Web to include physical devices

as well as cyber elements, combining both digital and physical worlds for a new kind of smart

spaces.

While the IoT is perceived as a generic and generalized concept, in practice, it is not. Its

various specializations and full taxonomy are yet to shape up and be fully learned. The IoT

market [4][5] is now divided according to the deployment scale of things in space and applicable

domains de jour into: personal (e.g., smart homes or connected cars), Industrial (e.g., smart

factory floor or physical plants), and At-scale IoT (e.g., a smart city deployment) illustrated in

Figure 1-1. Many parameters define the power and boundaries of each model; including the type

of things and services, communication technologies, device configuration and management,

processing power and programmability. Classifying IoT in this simple manner at this stage of

evolution of IoT is surely missing many important parameters. However, the classification helps

state the focus and applicability of the current research, which is on the personal IoT, where the

set of things is located in a bounded personal space.

16

Figure 1-1. IoT deployment scale.

On the other hand, the social networking concepts started to converge with IoT

technologies, paving the way for a new paradigm named Social Internet of Things (SIoT) [6][7].

SIoT evolves the definition of a social network for smart things and devices through a new set of

social bonds with respect to the identification attributes (e.g. objects’ proximity, vendor ID) and

a new set of relationships that functionally tie services offered by the things to build applications.

In SIoT, things can query their friends for services and discover new social bonds between their

identification, and relationships between their services.

Such a new Web of things, used to form IoT, along with the evolution from devices with

simple network connectivity into a collection of socially inter-connected smart things, creates a

new ecosystem with endless programmability opportunities. It also allows for innovative

scenarios that enable application developers to discover the true power of the surrounding smart

space and build domain-related applications. Such space programmability that takes advantage of

space things, services, and social interactions can dynamically capture novel engagement

opportunities for new meaningful interactions and applications.

A thing in the IoT ecosystem was defined in a lot of ways from multiple and different

perspectives (e.g. cloud, edge, application). Up to this point in our knowledge, no work discovers

Personal IoT Industrial IoT At-Scale IoT

Internet of Things

17

the thing from its interactions prospective. A thing in a smart space engages with the surrounding

ecosystem and space entities including cloud platforms, edges, users (e.g., end-user, developer)

and space-mates (nearby things in the same smart space, or remote ones in other smart spaces)

through sets of interactions that include identifications, social relationships and bonds,

applications and service-oriented calls (e.g., API), and device management and configuration

interactions.

We argue that the success of IoT cannot be achieved by simply connecting the things

together to form a normal or ad-hoc kind of network. However, solid success will greatly depend

on how the thing is described in the smart space in terms of its services, resources and

capabilities and how the thing itself is architected to explicitly support this promising IoT vision.

At the same time, programming smart space is not only about service discovery and the

interfaces (e.g., APIs) through which applications developers can access the services and

resources of things. However, the promising vision of programming the IoT can be empowered

through the ability of smart spaces and the things themselves in capturing, inferring and

expressing programming and engagement opportunities for applications. Such informative and

interactive capabilities assist the developers to sense the surrounding smart spaces and to build

domain-related meaningful IoT applications [13][51].

The thing must be architected to satisfy: 1) the seamless integration with the IoT

ecosystem, configuration and management with least human intervention, 2) the discovery of

social bonds and relationships besides enabling space knowledge exchange through a set of ad-

hoc interactions, and 3) the establishment of new programed engagement opportunities with

other space entities through different social and meaningful interactions. This prospective drives

18

a set of design challenges on the architecture and programming model we present that can power

such features for more social and interactive entities in smart space.

Problem Statement and Current Challenges

The main constraint of such a new web of things is the wide heterogeneity in

communication technologies, types, operating engines, environments, services and resources,

data generated and measurement capabilities. Such heterogeneity introduces the additional effort

of integrating these things with the surrounding smart space and IoT ecosystem as a significant

challenge. Manually integrating such a wide spectrum of things in the ecosystem requires

considerable effort and limits programming opportunities for smart spaces developers.

IoT currently lacks a uniform lightweight way of describing things in smart spaces in

terms of what a particular thing is (e.g., its components), what it does (e.g., its offered services)

and how it communicates (e.g., what it can say or which protocols it understands). Such lack

introduces further questions: How can space users (e.g., the developer, vendor, and space owner)

manage and configure such wide heterogeneity? How can such fragmented things inter-operate

and interact not only with cloud platforms and space users but also with other things in space? At

the same time, the current approaches in architecting the thing [8][9] do not fully exploit thing

description specifications and attributes for the promising vision of IoT. Such approaches link

the access of things to a central point (e.g., cloud platform, or edge), through which space users

and developers can access resources, services and collect data. Such a restricted paradigm

ignores the distributed nature of IoT, which should also allow things to communicate with one

another in a smart space, forming thing-to-thing as well as thing-to-cloud or thing-to-edge

communication paradigms. At the same time, architecting the thing should reflect how it can be

managed and configured, the different communication languages it supports, and eventually the

19

important IoT semantics of how a thing can be used by other things or utilized within an IoT

application.

On the other side, the recently proposed ideas on social IoT [6][7] are to logically link the

things according to their identification attributes (e.g., things collocated in the same smart space,

things from the same vendor), not on the different services offered by these things. However, the

exploitation of service-level relationships in the context of social IoT adds an effective

programming perspective to such a new evolving paradigm.

But the currently available programming models and frameworks [10][11] have the

following limitations: 1) they are built on top of a restricted set of relationships which we think

are not sufficient to build a wide range of IoT apps. For instance, If This Then That (IFTTT) [12]

only offers apps where one service controls the operation of another service (e.g., prepare coffee

when your Fitbit registers you are awake); 2) ignores the ad-hoc nature of the things, where the

things are prior registered and manually connected to powerful platforms (e.g., the cloud) with

no support to the thing-to-thing communication. (However, enabling both thing-to-thing and

thing-to-cloud interactions empowers the properties of distributed programming environments

[11] that resides in both the things and cloud); and 3) assumes only limited intrinsic capabilities

of the thing, where things are not regarded as anything but passive elements that only process

service calls from app developers with no further potential participation. Upgrading the things to

be more active to discover the smart space and infer new engagement opportunities will

obviously enrich and expand the space of the apps. Such restricted social environments also

narrow down the possible expansion of new relationships between things. That in turns limits the

merging of new applications and restricts the programmability of smart spaces.

20

Overview of the Proposed Framework

The following chapters outline the proposed framework on the research. Chapter 2 is a

literature review, while Chapter 3 provides the proposed research framework. In the following

chapters, these challenges and the requirements to enable the vision outlined in the first three

chapters are addressed through four steps, as follows:

Step 1. In Chapter 4, the different types of things that exist in smart space are classified

and a “thing taxonomy” is provided. We propose a new definition of a thing and an anatomy of

the different parts of the thing. This thing taxonomy, definition and anatomy lead to defining the

requirements about how a thing can then be architected. In this step (Chapter 4) we present our

IoT Device Description Language (IoT-DDL) as an XML-based human- and machine-readable

configuration scheme that is based on and extends the original Atlas DDL [56][57] to describe

the thing in terms of inner components, identity, capabilities, resources, attachments and

services. The IoT-DDL also describes the knowledge (social bonds and relationships) injected or

acquired by the thing, as well as the different interactions that engage the thing with cloud

platforms, edges, users (e.g., end-user, developer) and space-mates (nearby things or remote

ones). Such configuration schemes are created by the thing vendor or owner and this then gets

uploaded to the thing to enable the thing to self-discover its own power and engage with the

surrounding IoT ecosystem.

Step 2. In Chapter 5, we present an architecture, named the Atlas Thing Architecture, that

is based on and extends the Atlas Architecture [50] and its service-oriented nature to address the

specifications of the IoT-DDL. The Atlas Architecture enables the automatic integration of the

devices into the ecosystem and allows the programmer to discover and combine available

services to create applications for the smart space. The Atlas Thing Architecture is a set of

lightweight operating layers that initially aim at turning a thing into a smart stand-alone and self-

21

dependable unit, getting smarter, more social, and more interactive with time. Atlas Thing

Architecture extends the original Atlas architecture to enable the thing to self-discover itself and

announce its presence, services and capabilities to other participants in the smart space. Besides

capturing new engagement and programming opportunities, such knowledge exchange increases

a thing’s awareness of the surrounding ecosystem and enables discovering and building new

social relationships. Along with the provisioning and management capabilities offered by the

Atlas Thing Architecture to the space users and developers, the Atlas Thing Architecture

supports both thing-to-thing and thing-to-cloud communication paradigms through the support of

a set of communication protocols and enabling communication interoperability through protocol

translators. The Atlas Thing Architecture also enables, through the IoT-DDL, the thing to

dynamically define and generate its own services and formulates appropriate programmable

interfaces through which the thing mates can interact and trigger the offered services.

Step 3. In Chapter 6, the inter-thing relationships programming framework which utilizes

our Atlas Thing Architecture as well as the thing IoT-DDL specifications to build a distributed

programming ecosystem for the social IoT, is presented. The framework broadens the social IoT

thing-level relationships (that link the things according to their identification attributes) and

utilizes a set of concrete service-level relationships (that logically and functionally tie the offered

services to build scenarios and applications). We believe this can empower developers to

program a much wider class of meaningful IoT applications. The framework introduces service

(abstraction of the function offered by a thing), relationship (abstraction of how different services

are linked together) and recipe (abstraction of how different services and relationships build up a

segment of an app) as the primitives for the Atlas IoT application. The framework also defines a

set of operators that functionally define how the primitives are wired.

22

Step 4. In Chapter 7, the Atlas RIDE, an interactive development environment for the

mobile user to glimpse and program their smart spaces, is presented. The RIDE extends the inter-

thing relationships programming framework and targets the smart-phone users with no

programming experience to help them master their smart spaces and to build applications with a

few clicks. The developer, through the RIDE, can listen to the smart space to capture the

available services and relationships, establish applications, and set preferences for functionalities

to guide the inference of new applications and engagement opportunities. The RIDE also accepts

the description for application from the developers and generates mobile applications that run

independently from the RIDE and communicate back with the things for the execution of the

application.

Research Objectives, Limitations and Scope

The personal IoT model (e.g. smart home) was targeted within these emerging IoT

markets, where a set of things exists in small-scale space. For time constraints, we implemented

the essential components and sub-layers of the Atlas Thing Architecture (DDL-manager, Atlas

object manager, service generator and API formulation, communication interoperability, device

management, knowledge and tweeting exchange, API interface, and knowledge inference) on

real software and hardware platforms. IoT-DDL and Atlas objects will cover the essential parts

of a thing description (thing identity, entity identity, services) and interactions (device

management, social relationships and small-scale applications). The Atlas protocol translator for

communication interoperability is implemented as an example for the Atlas thing cloud-based

attachments. A subset of the presented social relationships is implemented from each social

relationship category and the essential components of the Atlas RIDE (capturing tweets and

visualizing knowledge, user preferences, relationship inferences, establishing relationships and

23

applications, application descriptions and generation). For time constraints, the social

relationships and meaningful interactions involved the cooperation of up to two things in a smart

space. We also presented a benchmark study of the proposed framework on the real software and

hardware IoT platform to demonstrate the feasibility of the proposed approaches.

24

CHAPTER 2

LITERATURE REVIEW

In this chapter, the related work for the current architecture and platforms for the IoT is

discussed, including device description and management approaches, trends in social IoT besides

smart space programmability, and current programming models.

Architecting the IoT

The state of the art in describing and taxonomizing a thing in the smart space is

presented, followed by the current IoT platforms and architectures, and then the current

approaches to provision and managing things in the smart space.

Device Description Approaches

The Device Description Language (DDL) is a machine- and human-readable XML-based

device description approach developed by the Mobile and Pervasive Computing Lab at the

University of Florida [56][57]. DDL is used to describe the configuration and the properties of a

single type of device that can be sensor, actuator or hybrid type, through defining metadata,

functions and operations. Such descriptive schema is used for the seamless integration of the

device into the smart space as well as for service registration and discovery. DDL was used to

develop the Cloud-Edge-Beneath (CEB) architecture [59][60]. CEB opens access links to

devices from the cloud through the use of the Atlas sensor platform and middleware [61][62].

Atlas middleware, hosted by the Edge (e.g., standalone server), uses the Open Services Gateway

initiative (OSGi) for service discovery and configuration mechanisms to Atlas sensor platforms.

The middleware, when contacted by an Atlas sensor platform, retrieves information from the

DDL descriptor and creates Java bundle for that sensor. The IoT-DDL presented in this work

(Chapter 4) is based on and extends the original Atlas DDL [56][57] to describe the thing in

terms of its inner components, identity, capabilities, resources, attachments and services, as well

25

as the knowledge (social bonds and relationships) and the different interactions that engage the

thing with other things and entities in the smart space.

Amazon Web Services (AWS) IoT [8] is a cloud-based platform that provides bi-

directional communication between the AWS cloud and the things in space (e.g. sensors,

actuators). The AWS primary focus is on collecting and analyzing data reported by multiple

devices in JSON formatted messages. The Thing-registry stores and organizes Thing-related

information and resources, while users can associate up to three custom attributes with each

thing. On the other side, each thing has a thing-shadow that stores thing-state and metadata as a

response to application requests. However, AWS IoT provides a minimal shape of device

management through few attributes, besides restricting the communication channel to exist only

between internet-connected things and the AWS cloud. On the other hand, things in the AWS

ecosystem are solid entities with no social relationships or bonds with other space entities, nor

are there any self-management capabilities.

But a number of companies and organizations have introduced various descriptive

schema platforms. For example, Google introduced Weave as a JavaScript Object Notation

(JSON)-based communication platform allowing mobile phones and cloud services to interact

with things [14]. Weave enables phone-to-device-to-cloud communication schema and user

interaction with the things through mobile devices and web. Weave works in conjunction with

Brillo, Google’s new android-based operating system for embedded development [15]. Besides

push-notifications, Weave cloud-service provides device-discovery, provision, state-subscription

and remote-access. Weave introduces two main ideas of device description schema: 1) Trait,

which describes various functions of the device besides commands and state definitions for

capabilities and behavior; 2) Component, describes the relationships between the different traits.

26

However, Weave assumed all things to be Linux-based and didn’t show the social and self-

management capabilities of the thing.

The Web of Things (WoT) framework by the World Wide Web Consortium (W3C) [9]

[9] is an active research field that explores access to and handling the digital representation of

things through a set of web services. These services are based on event-condition-action rules

that involve these virtual representations as proxies for physical entities. Such objects are

modeled in terms of metadata, events, and actions, along with the RESTful protocol. Servers

provide an interface for instantiating and registering such proxies for the things along with their

descriptions. A client script interacts with these proxies exported by the server, where

applications can register callbacks for events. Darko et. al. [17] utilizes a Thing Description (TD)

to describe the different things in the WoT, in terms of their metadata, how to access them, and

to describe the different events and their corresponding actions. The TD relies on the Resource

Description Framework (RDF) [18] as an underlying data model that can be extended to involve

domain specific information.

C. Chen et al. [16] highlighted a set of standards capable of describing devices and

sensors in smart space. For example, the Energy Conservation and Homecare Network

(ECHONET) standard defines device properties and access methods that enable monitoring and

managing appliances from different vendors. The Device Kit with an XML-based device-kit

markup language is a java Open Service Gateway Initiative (OSGi)-based-approach that allows

applications to interact with the different devices. On the other side comes the Sensor Model

Language (SensorML), developed by the geospatial research community to describe different

types of sensors besides the data models and processing procedures. However, the main focus of

all these descriptive schemas and approaches were to describe the device meta-data, to access

27

methods and configuration, where all devices and sensors communicate with a central station

with no thing-to-thing communication paradigms proposed, and where device management is a

cloud-based task.

Device Taxonomies

Leon Barker et al. [19] divided the objects that appear in the IoT ecosystem into: 1) smart

devices that are uniquely identified, equipped with sensors and able to communicate their own

presence and data to servers and other devices; 2) persistent nodes that provide service or storage

function for the smart devices and access the outer world through gateways; 3) collectables that

represent a wide array of objects that have been assigned a barcode and can associate with other

IoT objects; 4) sentient things (e.g. people, high-intelligence machines) that exhibit free will and

are able to make unprompted decisions about their actions; and 5) semi-autonomous agents that

are capable of initiating actions and conducting tasks once the systems admin has set specific

permissions. It is possible for objects to fit more than one of the categories described. Once a

thing is categorized, it becomes easier to see how objects function within an IoT ecosystem.

Bruno Dorsemaine et. al. [20] described a taxonomy for connected objects in IoT through

energy, communication, functional attributes, hardware and software resources and cost

categories. The objects provide several communication technologies and can communicate with

the pickup points (e.g. gateway). The functional attributes category depends on the object to be a

sensor that extracts data, an actuator that acts within the environment and a hybrid of these two

previous types. Sometimes through local user interfaces, objects can allow direct interaction with

its users or through a gateway. On the other hand, Authors in [22] provided another high-level

taxonomy that is based on applications and technologies. These applications ranged from those

directed to consumers (e.g. connected home) to those directed to businesses (e.g. smart city,

health). The second dimension of the taxonomy is the different technologies that apply to such

28

applications. These technologies range from sensing technologies to connectivity technologies

(e.g, ZigBee, Wi-Fi, Bluetooth), data management and storage, cloud services, and middlewares.

Ejaz Ahmed et. al. [21] proposed another taxonomy for IoT based on communication

enablers, network types, technologies, local area wireless standards, objectives, and

characteristics. Communication enablers refer to wireless technologies used to communicate

across the Internet. WiFi is mainly used in smart homes and smart cities. Satellites are used in

smart transportation while 3G and 4G technologies are mainly used in smart grid environments.

On the other hand, smart environments rely on different types of networks to perform the

collaborative tasks, including using wireless local area networks and wireless personal area

networks with different characteristics in terms of size, data transfer and supported reachability.

The third dimension of the taxonomy is the technologies that include sensing, communication,

data fusion, emerging cloud and fog computing, and information security technologies. IoT-

based smart environments, on the other hand, have different predefined objectives including cost

reduction, utilization improvement, proactive maintenance, and minimal user interaction. IoT-

based smart environments also have some unique characteristics, including prediction

capabilities, newly enhanced services, remote monitoring, and decision-making capabilities.

Atlas Middleware and Sensor Platform

The Atlas Architecture [50][92] known as an “integrate once deploy everywhere” system

is an implementation of the service-oriented device architecture (SODA) [93] used to automate

the process of sensor integration and discovery through an Atlas sensor platform and Atlas

middleware. At the same time, the Atlas Architecture enables the programmer to discover the

available services and compose them to create applications. The platform is a combination of

hardware, firmware running on the hardware, and a software middleware that provides services

and an execution environment. Such execution environment is used to integrate devices (e.g.,

29

sensor, actuator) into a network of devices to be controlled through defined interfaces and

programmed into applications. Atlas middleware uses the Open Services Gateway initiative

(OSGi) as its basis to provide service discovery and configuration mechanisms to the Atlas

sensors platform. The middleware includes the APIs and configuration manager required to

create a programmable pervasive space.

Yi Xu and Sumi Helal [59][60] proposed a four-tier architecture named Cloud-Edge-

Beneath (CEB) that utilizes the original DDL [56][57] and extends the original Atlas architecture

[50][92] to enable the integration of sensors to reach the cloud through Edge. Edge as a

standalone server or a computing device is an intermediate layer that runs Atlas middleware to

connect and manage a group of sensors. Cloud is where sensor-based services and applications

are developed and deployed. The term “Beneath” in CEB refers to the physical layer where the

sensor devices and their descriptions reside. Atlas middleware also includes a bundle generator,

which when contacted by an Atlas sensor platform, retrieves information from the DDL

descriptor, and creates a Java bundle for the sensor based on this information. Sensors are

abstracted into sensor service interfaces in the cloud through interlayer collaboration between the

Atlas middleware bundles in the Cloud, the Edge, and beneath. At the cloud layer, a

programming platform and a runtime environment are provided to programmers with different

roles to participate in the development of cloud–sensor systems.

Atlas Thing Architecture, presented in Chapter 5, is based on and extends the idea of the

Atlas architecture to address the thing requirements as well as the IoT-DDL specifications

(Chapter 4), to: 1) enable the thing to self-discover its own identity, capability, attachments and

resources; 2) enable the thing to dynamically generate services and formulate the corresponding

interfaces (APIs); 3) enable the thing to announce its presence in the smart space and to engage

30

through the thing-to-thing and thing-to-cloud communication paradigms with other thing mates

in the smart space in an ad-hoc manner; 4) push the device management and configuration

capability all the way from the cloud to the thing; and 5) raise the smartness and awareness level

of the thing through life-time social and meaningful interactions with surrounding thing mates.

Platforms and Architectures

Brillo [15] is Google’s vision of what an IoT operating system should be – an Android-

based platform designed to run on low-power devices through a slimmer kernel. Brillo offers a

hardware abstraction layer and a development kit, besides offering a few core services including

an over-the-air device management system and an application-level JSON-based communication

platform known as Weave [14]. There are several Brillo compatible boards (e.g., Intelx86 and

MIPS-based architectures), which can be accessed and managed though a Linux developer

machine. IoT applications can be developed directly over Brillo in which development takes

place on the developer machine and the resulting image is flashed on the target hardware. IoT

applications can also be developed over Weave, in which case developing code for apps that

require the Brillo boards, mobile Android devices, and the Google Cloud to “speak together” is

highly facilitated.

Google’s Physical Web [23] [24]extends the power of the Web to include and present

physical objects in the smart space as Web contents that can be browsed. The goal is to interact

with smart physical objects without a dedicated app for each object. Smart objects broadcast

their URLs and nearby mobile browsers use these pushed URLs as links to interact with the

objects. The physical web project is effectively merging the world-wide web with a broad

spectrum of appliances and electronic devices, empowering mobile users to control their devices

through browsers. Discovering proximate objects is built into the browser, which is the key

enabler to creating awareness and presenting the user with descriptions of nearby IoT objects.

31

The project uses an open Eddystone-URL Bluetooth beacon format for discovery and to capture

nearby URLs.

Mbed [25][26] is ARM’s IoT platform that includes a device operating system, a

development kit, and support for cloud service shadowing of the Mbed devices to facilitate and

speed up cloud-based application development and deployment of services implemented within

ARM-based devices. The ARM Mbed platform consists of three key components: 1) Mbed OS

for ARM Cortex-M based IoT devices, which offers light-weight services including

communication, and device management; 2) Mbed Device Server which provides the required

cloud-side technologies to manage Mbed clients and to facilitate the creation of web services that

represent and interact with the Mbed devices; and 3) Mbed tools and services including web IDE

and development kits for building applications before flashing the resulting image onto the

device. The ARM Sensinode NanoService platform (NSP) [27][28] leverages the power of web

technology and standardized IP for rapid deployment of IoT services. The platform provides

semantic lookup for connected devices and resources in a system that is visible for the external

web-applications residing in the cloud.

The Watson IoT Platform [29] [30] is an IBM platform that brings cognitive computing

technologies to the IoT world through infusing intelligence into the physical world. Watson

cloud services shifts the traditional programming of IoT connected devices to discovering new

possibilities for users, through exploring and uncovering patterns from IoT data and other inputs.

IoT devices from the Watson platform perspective includes any internet-connected registered

device that can speak Message Queuing Telemetry Transport (MQTT). Devices do not directly

interact but can accept commands from applications that reside on the Watson platform.

32

Shancang Li et. al. [31] described a generic four-level architecture for IoT. The local

environment as the first level contains the devices that communicate with either wire or wireless

technologies and local pickup points (e.g., computers) that are considered gateways and

interfaces for the devices. The second level is the transport level. This allows the devices or local

pickup points to communicate with the command servers. The storage and data mining appear as

the third level, mainly to process the collected data. This generally takes place in the cloud. The

user and other systems that can access the data through APIs or GUIs is the fourth level of the

architecture. However, only the first level is specific to IoT. The other levels are common with

other types of massive systems and networks and used to handle massive amounts of data.

Rafiullah Khan et. al. [32] proposed a five-layer architecture for IoT. The Perception

layer consists of the physical objects and sensor devices. This layer basically deals with the

identification and collection of objects and specific information by the sensor devices (e.g.

location, temperature). The Network layer then securely transmits the collected information to an

information processing system. This information processing system is a part of the Middleware

Layer, where devices implement different types of services. Each device connects and

communicates only with those devices that implement the same service type. This layer is

responsible for service management and data storage. The Application Layer, as the fourth layer,

provides global management for the different types of applications that are based on the

information processed in the Middleware layer. As the last layer, the Business Layer is

responsible for the management of the overall IoT system including the applications and

services. Based on the data received from the application layer, this layer builds graphs and

flowcharts that can help to determine future actions and business strategies.

33

David Perez et. al. [33] proposed a three-layer architecture to improve the resilience level

of the services and infrastructure of IoT. The architecture layers are the infrastructure, the

middleware, and IoT-services. These layers target the smart city scale paradigm using the cloud

and cloudlets (i.e. Gateways and IoT services). The middleware and the IoT-service layers reside

in the cloud environment. The middleware layer offers a seamless integration of devices besides

common functionalities and abstraction mechanisms that wrap the infrastructure details for

developers and users. IoT-services offer application management tools and services that support

the Smart City, as well as analysis of the data collected from the city. The lower layer deals with

the physical devices that collect data and react to specific situations. Typically, the collected data

is processed and analyzed by the different IoT Services. Gateways at the edge of the network

connect the devices with the Internet. These IoT gateways, together with virtual devices and

services hosted in cloudlets, perform data compression and aggregation.

Device Provisioning and Management Approaches

The oneM2M [35] standard was developed by the European Telecommunication

Standard Institute (ETSI) for the Machine-to-machine (M2M) service layer platforms that resides

in either a gateway or device. The oneM2M device develops technical specifications for common

service entities and interfaces with applications that can be embedded in various hardware and

software. The standard focuses on the service-oriented architecture while relying on data

transport services offered by the underlying network. The oneM2M device is not designed to

reside in constrained devices of IoT. In addition, oneM2M does not propose any new

management mechanism other than adopting the device management standard developed by

OMA for mobile devices and TR-069 protocols for fixed devices.

OMA is an international standard organization for mobile communications that develops

the device management standard for mobile M2M devices, OMA LwM2M [37] is their latest

34

protocol which targets low power and constrained devices management with a low-overhead

RESTful data model and point-to-point communication of client-server fashion. LwM2M Server

interacts with the LwM2M Client [38] that resides in an M2M device, where the client employs

one or more object instances to represent the device under its management. Each object is a

collection of resources that are atomic pieces of information which represent a particular view or

active property of an object. Client objects and resources are accessed through URI and web

APIs such as PUT, POST, GET and DELETE for Read, Write or Execute [35] [36]. The

LWM2M standard defines four logical interfaces: 1) Bootstrap interface for objects initialization

for Server-client communication. 2) Client Registration interface for client’s objects with the

server. 3) Device Management and Service Enablement Interface for operations to handle

resources, objects, and instances, and 4) Information Reporting interface for operations related to

the Observe feature of resources.

IP Smart Object (IPSO) Alliance provides common design patterns and semantic

interoperability across IoT devices and applications [39]. IPSO is developing a LwM2M object

model based on smart objects that employ sensor markup language (SenML) to define sensor

data and measurements metadata. IPSO can be used with protocols that support LwM2M

addressing, data types and content formats (e.g. CoAP, HTTP). LwM2M uses objects with fixed

mandatory resources, while IPSO smart objects use a more reusable design [40] that introduce

the composite objects concept where an object can contain multiple inner objects [34][35].

However, IPSO proposed a limited set of extra objects that do not fulfill Atlas Thing

Architecture goals (as presented in Chapter 5) for stand-alone entities with self-management

angles besides social and meaningful interactions.

35

Programming the IoT

In this section, we present the current trends in social IoT (SIoT) research and concepts

followed by the state of the art on smart space programmability and programming models

research.

SIoT Programming Approaches

Atzori et al. [6] proposed a social network of intelligent objects named the Social Internet

of Things (SIoT) to mimic human behavior. The authors analyzed the types of social

relationships among smart objects to be parental relationships (i.e., built by the same

manufacturer), Co-location and co-work relationship (resides in the same place or periodically

cooperates). The authors presented an architecture for the SIoT that addresses network

navigability, service discovery, and composition. The architecture is made up of server and

objects as the network elements that exist. The server holds the relationship management for a

human-controlled selection of relationships, while the objects are the physical devices located

and reached through their interfaces. The Authors then provided an implementation [42] for the

architecture through a RESTful interface, where a Uniform Resource Identifier (URI) is

associated with each resource. Users register their devices and select the types of relationships an

object can create with peers. The existing approach lacks the support produced by how things

relate in correlation to a single application. They must rely on a central server to apply rules of

relationships and manage objects on social media, which requires manual registration of the

objects. The existing approach lacks the support of how the things can be related in an

application and how they rely on a central server to apply relationships and manually manage

objects.

Holmquist et al. [41] presented a context proximity procedure that creates friendship

between embedded devices, named as Smart-Its. Smart-its are tiny wireless devices, equipped

36

with integrated sensing and processing capabilities in addition onboard accelerometers. The

movement data of the device is captured and broadcast to other Smart-its in range so they can be

compared to their movement patterns. If similar patterns are detected, the former Smart-it is

accepted as a friend and a connection is then established with the other Smart-its. The authors

main concern was on the qualitative and selective connections that can be established between

such smart devices. The authors then proposed some ideas on applications that can utilize the

friendships between such devices (e.g. a child monitor created via two Smart-its enhanced

objects, one worn by a child and the other by a parent, and then shaking them together to

establish a connection). In addition to the limited programmability options, the authors did not

show the feasibly of such an approach to real IoT things that can exist in the smart spaces.

Turcu et al. [43] considered building an RFID-based social network of cognitive robots,

for human-robot and robot-robot social interactions. The authors used Twitter as a social network

to build online communities, where they created Twitter accounts for each robot. A robot’s

behavior is determined according to the RFID-tagged entities that come across its path; the robot

then exhibits a predefined behavior (e.g. love, fear, repulsion). Such behavior is then sent as a

message on Twitter and the robot then waits for a reply to decide what to do next. Robots can

also report the different environment parameters of the area where it operates. However, the

proposed procedure lacks details on how social relationships and robots’ behavior are defined,

beside how these Twitter accounts are structured and parsed on the robot side.

Kranz et al. [44] introduced further steps in integrating IoT with social networks. The

authors also chose Twitter as an online social network, and then created accounts for cognitive

plant controllers. Such controllers are equipped with a Twitter-enabled sensing system that

tweets the humidity information to the plant’s Twitter account. On the other side, users following

37

the plant’s Twitter account can stay informed about the health state of the plants. However, the

research by Kranz et al. is more about reporting information than creating dynamic social

relationships and interactions between all involved entities.

If This Then That (IFTTT) [12][45] is a web-based service that allows users to connect

various Internet-based application services (e.g., Facebook) by creating rules (called recipes).

IFTTT allows two services to be manually combined using simple if-then statements to

accomplish a task. IFTTT utilizes the different APIs offered by services’ vendors (e.g., Twitter,

Instagram) to access the client’s data. As an instance, IFTTT can be used to send files uploaded

into Dropbox to Evernote, the popular note-taking software, automatically. As mentioned earlier,

IFTTT uses recipes to describe actions, where the users of the platform can search existing

preconfigured recipes. The user then needs to give permission for the services to allow IFTTT

access to the personal data associated with the accounts. Recently, IFTTT has been working on

integrating these services with smart products (e.g., Belkin WeMo Home automation, Philips

Hue LED light bulb) through utilizing the open APIs offered by the vendors and manufactures of

the devices.

IoT Programming Models

Geoff Coulson et. al. [46] projected a programming approach that facilitates the

composition of systems that relies on the knowledge of the internals of such systems. The

proposed approach targets self-contained systems (e.g., Wireless Sensor Networks (WSNs)) with

the assumption that such systems interact and compose opportunistically. Such time-bounded

and beneficial interactions raise the composition of the system-of-systems where those systems

discover potential partner systems in their environment. The approach is based on a

programmatic abstraction of a system named a tecton, which is a representation of an

opportunistically interacting system. The interaction between such tectons is managed by

38

programmatic contact-action rules that specify the conditions and the form of such interaction.

Tecton utilizes a service discovery protocol to seek a contact with other tectons and provides the

appropriate corresponding actions.

Stefan Nastic et al. [47] proposed an on-cloud platform named PatRICIA for high-level

IoT programming. PatRICIA is a three-layer architecture and is based on SOA design principles.

The device layer holds a virtualization of the connected devices, the communication protocols

and connectors with the actual devices, and the device manager and service discovery. The cloud

runtime layer provides an execution environment for applications and a data management

module for the collected sensory data. The development support layer contains the development

tools as well as the programming model. The model enables application development through

predefined tasks as outlined by the domain experts. The control task represents actuating steps to

control physical devices, while the monitor task represents processing of sensory data streams.

Each task is represented via intent as a data structure to describe, configure and invoke the

operation of the task, where the execution and processing resides in the cloud.

Jaeseok Yun et al. [48] demonstrated a prototype service named TTEO (Things Talk to

Each Other) that enable users to program IoT through a set of if-then rules. The proposed

architecture is composed of two platforms, the connectivity platform named Mobius and the

smart service server named &Cube. Mobius is the infrastructure domain that resides in an IoT

server, communicate with devices and maintains virtual entities for the devices. The smart

service server is the interaction domain of the solution that allows developers to build new

services that engage the registered devices through a predefined set of rule-based control

statements (if-then rules). The smart service server also holds a data container module for

retrieving the data from Mobius and a rule engine for performing tasks described with the

39

predefined if-then rules. The authors presented a prototype service TTEO, with the main task of

performing rule-based control of the devices.

Chao Chen et. al. [49] proposed an event-driven programming model named E-SODA, as

an extension of the service-oriented device architecture (SODA). SODA focuses on the services

provided by a system, rather than the sensor data streams or active contexts of the environment.

The authors developed a reference implementation of SODA, which features the Atlas sensor

platform and Atlas middleware as proposed in [50]. The Atlas middleware enables service

composition, allows the programmer to find the proper services and arranges the service method

calls to create an application. The service-oriented Atlas sensor platform automatically integrates

these devices and represents them as service bundles in the service layer.

These bundles implement a uniform service interface that abstracts away most of the

physical details and helps programmers concentrate on developing the applications. E-SODA

abstracts sensor data into events while an application follows a rule-oriented processing

paradigm that is composed of list of Event-Condition-Action (ECA) rules. An ECA rule listens

to the occurrence of a predefined event and responds through the corresponding action if the

condition is satisfied. An E-SODA application is a collection of interrelated services working

together to perform the function of rule evaluation. A rule object keeps references of three

different types of services that represent the event, condition, and action components of this rule.

The authors presented the Atlas Reactivity Engine (ARE) as an implementation of the E-SODA

event-driven programming model and an adaptive algorithm that supports dynamic sampling rate

changes and exploits the opportunity for short-cut evaluation.

In this chapter, the state of art for the current IoT platforms along with thing description

and management approaches, the trends in social IoT, and IoT programming models, have been

40

reviewed. In the following chapter, we will present an overview of the proposed approaches that

address our motivation and present solutions to the different challenges discussed in Chapter 1.

41

CHAPTER 3

OVERVIEW OF THE PROPOSED APPROACHES

In this chapter, we present an overview of the proposed approaches that address our

motivation and present solutions to the challenges discussed. First, we present an overview on

the IoT Device Description Language (IoT-DDL) as a schema used to describe the thing in the

smart space. Second, we present an overview on the Atlas Thing Architecture as a set of

operating layers that provide novel capabilities a thing requires to engage and interact with other

things and platforms in the smart space as well as in IoT scenarios and applications. Third, we

present an overview on the Inter-thing relationships programming framework that broadens the

social relationships between the services offered by the things in the smart space for a distributed

programming model for the social IoT. Finally, we present an overview of the Atlas Runtime

Interactive Development Environment (RIDE) for the mobile users to glimpse the smart space

and to build meaningful domain-related IoT applications. The development environment utilizes

semantic measurement methodologies to build and suggest new application nuggets to the

developers dynamically.

IoT Device Description Language (IoT-DDL)

As highlighted in Chapter 2, in the absence of a device description language that supports

basic thing requirements for a smart space, significant effort is required to interact and manage

the wide heterogeneity of things. At the same time, the thing description should be part of the

thing itself to facilitate a thing’s smooth migration from one smart space to another and to enable

thing-to-thing direct ad-hoc interactions.

The IoT-DDL is a machine- and human-readable XML-based descriptive language used

to describe, through a set of attributes and parameters, a thing in the smart space [52][55]. The

IoT-DDL (Chapter 4) is based on and extends the original Atlas DDL [56][57] to describe the

42

thing in terms of the thing’s identity, services, resources, inner entities, cloud-based attachments

along with the knowledge (social relationships) and the different interactions that engage the

thing with cloud platforms, edges, users (e.g., end-user, developer) and space-mates (nearby

things or remote ones). Resources are the operating system’s services a thing requires to be part

of the IoT (e.g., network module). Moreover, thing entities are the physical devices, software

functions, and hybrid devices that can be attached to, built in, or embedded inside the thing. Each

entity provides a set of services to the smart space through a set of well-defined interfaces

(APIs). Furthermore, a thing can have one or more external accessories or attachments. Thing

attachment is a cloud-based expansion of the thing that provides further representations (e.g.,

virtualization) and services (e.g., database) that are considered a heavyweight to be hosted on the

thing or that requires additional resources that are not available on such constrained devices.

Knowledge represents the different social relationships and constraints that shows the social

bonds with other things and how they can engage.

A thing in a smart space engages with thing mates in the IoT ecosystem through a set of

information- and action-based interactions. Information-based interactions (referred to as tweets)

enable a thing to announce its identity, capabilities, and APIs to thing mates. A thing uses a tweet

to describe what it is, what it does, and what it knows to the other thing mates. Action-based

interactions include management commands, lifetime updates, and configurations from

authorized parties as well as the applications that target the thing’s capabilities and services.

Atlas Thing Architecture

The IoT platforms and architectures highlighted in Chapter 2 link the access of things to a

central point (e.g., cloud platforms or edge) where space users can access resources and collect

data. This type of architecture highly facilitates cloud-based application development. On the

other hand, direct communication between things is not supported, and the IoT clouding is

43

mostly vendor-specific. Such vendor-restricted connections narrow down the capabilities of

connecting other types of things from different vendors seamlessly to the smart space. Such a

restricted paradigm ignores the distributed nature of IoT, which requires things to communicate

with other things as well as with cloud platforms and edge for the seamless integration, device

management, and engagement with others in ad-hoc IoT scenarios and apps.

The Atlas Thing Architecture [52][55] is a set of new software operating layers that

utilizes the specifications of the IoT-DDL to provide novel capabilities a thing requires to engage

and interact with other things and platforms in the smart space as well as IoT scenarios and

applications. The Atlas Thing Architecture (Chapter 5) is based on and extends the original Atlas

architecture [50][92] and takes advantage of the thing’s OS services (e.g., network module, I/O

ports and physical interfaces, and its process manager) to provide new functionalities for the

thing to: 1) self-discover its characteristics, resources, and capabilities through the uploaded IoT-

DDL along with the dynamic generation of its own services and the formularization of the

appropriate APIs; 2) open an ad-hoc channel with a device management server for provisioning,

management, and configuration purposes, and 3) enable the secure interactions with thing mates

and engagement in IoT applications and scenarios. The Atlas Thing Architecture also enables the

communication interoperability between the things that speak different communication

languages through Atlas protocol translator thing attachment [53].

The Atlas Thing Architecture takes advantage of device management standards and

object modeling standards to enable thing management and configuration with minimal human

intervention, along with IoT communication standards to empower secure ad-hoc interactions

between the thing and thing mates. The architecture also extends the micro services concept to

enable the dynamic generation of the services by the thing and the formulation of the

44

corresponding APIs for service-oriented ad-hoc meaningful interactions to take place between

the things.

Inter-Thing Relationships Programming Framework

The inter-thing relationships programming framework [54][103] utilizes both Atlas Thing

Architecture and the thing IoT-DDL description language to build a distributed programming

ecosystem for the social IoT. In Chapter 6, the framework broadens the social bonds (thing-level

relationships) between things according to their identification attributes (e.g., vendor, things

collocated in same space) and utilizes a new set of relationships between the offered services that

we believe can empower developers to program a much wider class of meaningful applications.

These relationships logically and functionally tie these services to empower the developers to

build domain-related applications. The framework introduces service (abstraction of the function

offered by a thing), relationship (abstraction of how different services are linked together) and

recipe (abstraction of how different services and relationships build up a segment of an app) as

the primitives for the Atlas IoT application. The framework also defines Filter, Match, and

Evaluate as three operators that functionally define how the primitives are wired. The proposed

framework also facilitates the description of the IoT application through a set of semantic rules,

that evaluate the correctness of the established application by the developer and guide the

execution.

The relationships defined in the framework can be: 1) utilized by vendors in the things’

IoT-DDLs, and 2) utilized by developers while building IoT apps, and 3) dynamically inferred

by the Atlas RIDE from the exchanged knowledge (relationships and social bonds) between the

things. The discovery and inference of links between un-related services suggest the existence of

new engagement opportunities to the application developers. Thing vendor, Atlas thing (a thing

with Atlas thing architecture) and the developer are the main poles of the framework: 1) the

45

vendor builds the IoT-DDL that describes thing’s services and relationships with the other

things; 2) the thing formulates the IoT-DDL and exchanges knowledge with other things; and 3)

the developer utilizes our Atlas RIDE to get the up-to-date exchanged knowledge between the

things and build applications that communicate back with the things for services calls.

Atlas Runtime-Interactive Development Environment (RIDE)

Atlas RIDE is an interactive development environment for the mobile users to glimpse

and program their smart spaces. The RIDE, as described in Chapter 7, extends the Inter-thing

relationships programming framework to build a distributed programming ecosystem for the

newly emerging social IoT paradigm. Atlas RIDE allows the mobile users to build meaningful

IoT applications and empowers the developers to program a much wider class of domain-related

applications. The development environment utilizes semantic measurement methodologies to

build and suggest new application nuggets to the developers.

The developer, through the proposed Atlas RIDE, can: 1) continuously listen to the things

of the smart space to capture and visualize the available services and relationships; 2) establish

relationships and applications; 3) infer the existence of new application nuggets and

opportunities from the available services, relationships and established applications; 4) set

preferences for functionalities, services and application to guide the inference of new

opportunities. The RIDE also accepts the description for application and generates a full mobile

app that runs independently from the RIDE, and communicates back with the things for a service

call (API call). The proposed RIDE targets the smartphone users with no programming

experience to develop IoT applications for their smart spaces easily (with a smartphone touch

interactions).

46

CHAPTER 4

IOT DEVICE DESCRIPTION LANGUAGE (IOT-DDL)

In this chapter, the IoT Device Description Language (IoT-DDL) is discussed, which is

the proposed XML-based schema used by the thing’s vendor or owner to describe the thing in

the smart space. First, the different parts that make up the structure of the thing are presented.

Then the discussion will cover the proposed taxonomy for the things that exist in the smart

space, as well as the different requirements for such things to be part of the IoT ecosystem.

Second, we present the specification of the IoT-DDL showing how it describes the different

aspects of the thing.

Thing Anatomy

The first step in describing a thing in a smart space is through identifying the different

parts that make up its structure. The thing, as illustrated in Figure 4-1, is composed of a set of

resources, entities, attachments and how they connect with thing mates through various

interactions. Resources are the components that shape the operating system’s services that a

thing requires to be part of IoT (e.g., network module, memory unit). Each resource is shaped

through a set of attributes and properties that configure such operating services. Moreover, thing

entities are the physical devices, software functions, and hybrid devices that can be attached to,

built in, or embedded inside the thing.

Each entity also provides a set of services to the other things in smart space through a set

of well-defined interfaces (APIs). Furthermore, a thing can have one or more external

accessories or attachments. Thing attachment is a cloud-based expansion of the thing that

provides further representations (e.g., thing virtualization) and services (e.g., log server,

database, or dashboard) that are considered a heavyweight to be hosted on the thing or require

47

additional resources that are not available on such constrained devices. Thing mates include

cloud platforms, edges, humans (e.g., space users or developers), and other things.

A thing in a smart space engages with thing mates in the IoT ecosystem through a set of

information- and action-based interactions. Information-based interactions (referred to as tweets)

enable a thing to announce its identity, capabilities, and APIs to thing mates. A thing uses a tweet

to describe what it is, what it does, and what it knows to the other thing mates. Action-based

interactions include management commands, lifetime updates, and configurations from

authorized parties as well as the applications that target the thing’s capabilities and services.

Consider a smartphone as an example of a thing in smart space. To be part of the smart

space, a smartphone must be equipped with an internal memory and Wi-Fi network module as

resources. It also contains a set of sensors (e.g., proximity, accelerometer) as embedded entities

that can offer services and functionalities to other things in the smart space. The phone can also

be connected to a cloud attachment for lifetime OS updates, configuration, and management

provided by the vendor.

Thing Taxonomy

Things surrounding us that make spaces smarter, more informative, and interactive are

not only of different characteristics but also of different types. The type of thing is a higher

umbrella that covers different characteristics and properties of the thing in addition to the thing’s

model and services that shape the intent to be part of the social and meaningful ecosystem.

Typical models of things in smart space are: 1) things with sensors that sense and collect

environment parameters; and 2) things with actuators that perform actions that change the state.

48

Figure 4-1. Thing structure.

However, smart spaces are not only full of hardware models of things that offer

hardware-based services, but there are also software models. A software thing is a new type of

thing that represents a different model and offers software-based services and functions. Other

things with hybrid types can offer software-based or hardware-based services or hybrid services

to the space. The type of thing not only draws the kind of meaningful interactions with which a

thing can get involved, but it is also a measure of the thing’s intent to be part of a social network

of smart objects. In terms of how important the different services and resources offered are likely

for powerful things to become engaged with more available things through different and

meaningful social interactions.

Classifying things according to their type is considered an essential step to specify the

different requirements and design principles for a thing and how they can be architected. We

…

…

Entities

Services

…

Attachments

OutputsInteractions Interactions

Inputs

Resources

Thing

…

49

propose a taxonomy of things that shapes our IoT ecosystem with respect to the different types

that coexist in smart spaces. A thing, as shown in Figure 4-2, can be one of the following types:

Bit-Thing. The bit thing is a very small device (e.g. simple sensor and RFID tag) with

limited functionality in terms of memory, power and technologies besides the passive ubiquitous

and communication characteristics. Due to lack of user interfaces and the dedicated functionality

offered, Bit-Things are always attached to other platforms and kits for configuring and

programming purposes.

Soft-Thing. The soft-thing is a software artifact (e.g. script, library and application) that

provides software-based services, which either evolves into local spaces as local service or on

the cloud as a remote service (e.g. application as a service, platform as a service).

Embedded-Thing. The embedded-thing is a higher type of device with respect to

memory, power, and communication technologies. Embedded-Thing holds an operating engine

and processing power. Embedded-Thing can be further classified into three categories:

1. Thing-of-Things as platform or kit (e.g. a sensor platform and sensor mote) that holds one or

more Bit-Things for hardware services and Soft-Things for software services.

2. Powerful-Thing represents interactive personal things and high-end systems (e.g. smart

phone, domestic robots and home appliances).

3. Edge-Thing represents a high power computing station and terminals (e.g. computing

terminal, server and set-top box).

Thing Definition and Requirements

A thing in the IoT ecosystem was also defined through an array of research from multiple

different perspectives (e.g. cloud, edge, application). However, to our knowledge, no work

discovers the thing from the perspective of different social engagements and meaningful

interactions. A thing in a smart space engages with the surrounding ecosystem and space-entities

50

Figure 4-2. Thing-Taxonomy in IoT ecosystem.

through a set of interactions that include identifications, knowledge exchange (set of social

relationships and bonds), applications and service-oriented interactions, device management and

configuration interactions. In our work, we orient a thing in smart space according to three main

dimensions that evolve with time and shape the thing requirements to be an active entity in the

ecosystem:

Thing Description. Thing description is the digital description and metadata that give the

thing the capability to discover itself in terms of its inner components, attachments, resources

and the services it offers. The thing then declares identity, generates services, and formulates

APIs to these services to be announced to other space entities. This dimension is empowered by

the IoT-DDL (the focus of this chapter) and the Atlas Thing Architecture (Chapter 5).

Thing

Soft Thing

Embedded Thing

Thing of Things Powerful Thing Edge Thing

Low-end

Platform

High-end

Platform

Sensor

Mote

Low-end

Platform

High-end

Platform

Bit Thing

-Simple Sensor

-Simple Actuator

-RFID tag

-BLE beacons

-Apps

-Scripts

-Tools

-Libraries

-Arduino

-Libelium

-Beaglebone

-Raspberry Pi

-Smartphone

-Smart Watch

-Tablet

-Google Glass

-Domestic Robot

-WiSense

-MICA

-Smart Car

-Traffic System

-RFID Reader

-Home

Appliance

-Computing

Terminal

-Server

-Set-top box

-Data

warehouse

51

Social Interactions. The social interactions are social bonds with respect to identification

attributes (e.g., things’ vendor, space characteristics) and relationships that show how the offered

services can be logically and functionally tied together to build meaningful applications. This

dimension is empowered by the Inter-thing relationship programming framework (Chapter 6)

and the Atlas RIDE (Chapter 7). Such thing social profile is fed from injected knowledge from

the thing vendor (through the IoT-DDL), dynamically formulated and captured from knowledge

flying in the space (through the Atlas Thing Architecture) and inferred from the exchanged

knowledge (as detailed in Atlas RIDE).

Meaningful Interactions. The meaningful interactions are the applications and scenarios

that target the thing’s resources and services. These interactions may involve the cooperation of a

set of things to hold the required functionality. Such profile makes use of the thing’s description

and APIs, besides the different social relationships which evolved with time to fuel the discovery

of new programmed engagement opportunities and to extend the space of applications. This

dimension is empowered by the Inter-thing relationship programming framework (Chapter 6)

and the Atlas RIDE (Chapter 7).

IoT-DDL Specifications

The IoT-DDL presented in this chapter is based on and extends the original Atlas DDL

[56][57] to address thing requirements and to match the thing anatomy outlined above. The

difference between the original DDL and the proposed IoT-DDL can be summarized as follows:

1) The focus of the DDL is to generate a run-time representation of the thing’s service on the

edge or the cloud for service discovery, whereas the focus of the IoT-DDL is to generate a run-

time representation of the thing on the thing itself to enable the ad-hoc interactions and

interconnections. 2) The DDL focuses on describing the services offered by the thing, while the

IoT-DDL focuses on additional attributes to describe the thing in the smart space according to

52

the thing’s entities, resources, services, attachments, device management, and communication

protocols. 3) The focus of the DDL is to enable the thing-to-cloud communication paradigm,

whereas the focus of the IoT-DDL is to enable both thing-to-thing and thing-to-cloud

communication paradigms for the seamless build of IoT scenarios that involve different things.

Based on the thing requirements, and the anatomy and structure outlined above, the IoT-

DDL specifications are presented to describe the different parts and accessories of a thing

through a set of attributes, parameters, and properties. Atlas IoT-DDL builder [63] is a web

service tool that allows a thing’s creator (e.g., the original equipment manufacturer (OEM)) or

user (e.g., end-user, vendor) to create, update, or upload an IoT-DDL configuration file to a

thing. The OEM of a thing could be the source of the IoT-DDL; a developer who utilizes space

things’ services and resources might also be the source. Such flexibility facilitates further

adoption of IoT-DDL with changes, and supports thing innovation, where makers or hobbyists

may assemble new things not established by an OEM. An Atlas thing may contain one or more

inner entities along with one or more attachments as discussed in thing anatomy. The IoT-DDL

structure, as illustrated in Figure 4-3, is divided into the Atlas thing, thing entities, and thing

attachment sections. In the next subsection, we detailed the attributes and parameters of each IoT

section. Three detailed examples for full IoT scenarios showing the snippets and examples for

IoT things are also illustrated in Chapter 8.

Atlas Thing

The Atlas thing section of IoT-DDL characterizes the thing as a whole unit, describing its

identity, the different resources, capabilities and components. It is further structured into the

following subsections:

53

Figure 4-3. IoT-DDL specifications.

1. The descriptive metadata section holds the thing’s identification information that includes its

name, model, short description, type (e.g., software, hardware, hybrid), vendor, owner, the

Smart Space ID (SSID) and Atlas Thing ID (ATID). SSID is an identifier for the smart space

as defined by the space owner (e.g., owner name, cell phone number, and zip code of the

space) that ensures the uniqueness of the identity between the different smart spaces. ATID is

<Atlas_ IoT-DDL>

<Atlas_ Thing>

<Descriptive_ Metadata> </Descriptive_ Metadata>

<Structural_ Metadata> </Structural_ Metadata>

<Resources>

<Network_ Properties > </Network_ Properties >

<Memory_ Properties> </Memory_ Properties >

</Resources>

</Atlas_ Thing>

<Thing_ Entities>

<Entity_ 1>

< Descriptive_ Metadata> </Descriptive_ Metadata>

< Services > </ Services >

</Entity_ 1>

…..

<Entity_ n>

</Entity_ n>

</Thing_ Entities>

<Thing_ Attachments>

< Attachment_ 1>

</Attachment_ 1>

…..

<Attachment_ n>

</Attachment_ n>

</Thing_ Attachments>

</Atlas_ IoT-DDL>

Th

ing

Sec

tio

n

Att

ach

men

ts S

ecti

on

E

nti

ties

Sec

tio

n

54

an identifier for the thing defined by the owner or IoT-DDL developer that ensures the

uniqueness of the thing for the same smart space.

2. The structural metadata section highlights the overall structure of the IoT-DDL file as a short

summary of the thing's resources, entities, and attachments in terms of their number and

types (software, hardware or hybrid).

3. The resources section holds the attributes and properties of the underlying operating systems’

services the thing needs to be part of the IoT. The Atlas thing section contains a separate

section for each resource. The current version of the IoT-DDL specifications supports both

network and memory characteristics as the two main resources a thing needs to engage with a

smart space. The network properties subsection describes the network connection capabilities

of a thing in terms of the mounted network module (e.g., Wi-Fi, Bluetooth, Ethernet), and

network access information (e.g., network name, passcode). The subsection (as detailed in

Chapter 5) covers the attributes and properties of the supported communication protocols

(e.g., MQTT, CoAP) as well as the configuration attributes to enable the interoperable

communication channels with the other things. The memory properties subsection highlights

the various memory units available to process applications, to generate service bundles and

formulate APIs, and information regarding the format of the information- and action-based

interactions.

Thing Attachment

The thing attachments section describes the different cloud-based expansions of the thing

that provides further representations (e.g., thing virtualization) and additional services or

resources (e.g., interaction interfaces, translators, log servers, databases, or dashboards) that may

require cloud resources (e.g., memory storage or processing power). Such thing attachments

could either reside on a more powerful platform (e.g., the local cloud or edge) on the same smart

space network with the things, or on a remotely accessible network. The owner of an attachment

(e.g., a consumer electronics thing vendor) provides a well-defined interface to the offered

function, where the function is either: 1) an online resource that the thing can access remotely

(e.g., off-thing translator – as detailed in Chapter 5); or 2) a programmable object that the thing

can download and dynamically integrate and bind with the thing. Each attachment is described

in terms of the type (e.g., data-log server, repository, device management server), the access

55

information (e.g., URI, access name and code), transport layer protocol (TCP, UDP) and

communication protocol (e.g., REST, MQTT).

Thing Entity

The thing entities section describes the different types of entities (hardware, software, or

hybrid) that can be embedded, built in, or connected to the thing. Each entity is detailed in terms

of its descriptive information, the services and functions it offers, and the different social bonds

and relationships it can engage in. Each entity is further divided into components as follows:

1. The descriptive metadata section holds an entity’s identification information that includes

name, model, short description, type (e.g., software, hardware, hybrid), category (built-in,

embedded, attached), vendor, and owner.

2. The service section (described below) holds descriptive information about the different

services offered by the entity in terms of functional descriptions, inputs, and outputs. Each

service input or output is characterized in terms of a short description, data types, units, and

the acceptable range of values.

3. The relationships sub section (described below) holds descriptive information about the

different service-level relationships that demonstrates how the services offered by this entity

is logically and functionally tied to other services in the smart space.

Service

Each service offered by the thing entity (detailed in Chapter 6) is composed of two

members: 1) Attributes describe the characteristics of the service in terms of the identification

information for the offering thing, descriptive information for offered function using a set of

keywords, along with the type of service offered, where the service can be condition, report, or

action as value. Condition is a service that examines specific phenomena and returns domain

value if the condition exists (e.g., check to see whether there is a parking spot, return the spot).

Report is a service that returns a numerical value (e.g., read temperature sensor). Action is a

service that performs an actuation functionality and returns the domain value on a successful call

56

(e.g., turn on electric switch), and 2) Interface, a direct way to execute the service through the

hosting thing. The interface is defined in terms of the function’s name, inputs, and output. Each

input is a data variable defined by a short name, type (e.g., integer) and domain range (the

acceptable input values). The output depends on the type of offered service (condition, report, or

action).

Relationship

Each relationship (as detailed in Chapter 6) is composed of the three members: 1)

Attributes: metadata that declares who established this relationship by name and the type of the

relationship (takes one of the values: control/controlled-by, drive/driven-by, support/supported-

by, extend/extended-by for cooperative relationships, contest, interfere, refine/refined-by, or

subsume/subsumed-by for competitive relationships); and 2) Interface: a direct way to execute

the relationship with inputs, formula, and output. The formula reflects the sequence of how the

inputs (services) are processed and maintains the required dependencies.

57

CHAPTER 5

ATLAS THING ARCHITECTURE

Considering the different types of things and heterogeneity in capabilities, services and

resources as discussed in the previous chapter, besides our motivation to build a more social and

interactive IoT ecosystem, we argue that a space thing must be architected to satisfy three

requirements: 1) The seamless integration with the IoT ecosystem, configuration and

management with the least human intervention, 2) The capability to discover bonds and

relationships besides the enablement of space knowledge exchange through a set of social

interactions, and 3) the establishment of new programed engagement opportunities with other

space entities through the different social and meaningful interactions. Based on these

requirements, in this chapter we present the Atlas Thing Architecture for the thing in the smart

space. Atlas Thing Architecture is a set of new lightweight operating layers that fully utilizes the

specifications of the IoT-DDL (Chapter 4) to provide functionalities and services for the thing to

be part of the IoT ecosystem.

Overview

Atlas Thing Architecture is a new set of lightweight operating layers that targets the

argued requirements (Chapter 4) that a thing should be architected appropriately to allow it to be

an active part of a social and meaningful IoT ecosystem. The Atlas Thing Architecture is based

on and extends the Atlas architecture [50][92] and its service-oriented nature to address the thing

requirements as well as the IoT-DDL specifications (Chapter 4), to: 1) push the device

management and configuration capability all the way from cloud to the thing; 2) enable the thing

to self-discover its own identity, capability, attachments and resources; 3) enable the thing to

dynamically generate services and formulate the corresponding interfaces (APIs); and 4) enable

the thing to interact and engage through the thing-to-thing and thing-to-cloud communication

58

paradigms with other thing mates in the smart space in an ad-hoc manner; and 5) raise the

smartness and awareness level of things through life-time social and meaningful interactions

with surrounding thing mates.

The Atlas Thing Architecture is developed using a vendor’s provided IDE or OS (e.g.

C/C++ for Linux OS-based platforms such as Dragon 410C, Beaglebone, ARM-Mbed; Java/C++

for Android smartphones, Arduino-IDE for Arduino Thing) and flashed on the thing. Once

flashed, the thing is now cast to an Atlas thing that can be part of the Atlas IoT ecosystem. From

the uploaded IoT-DDL configuration file to the thing, the thing starts to discover its identity,

inner entities, attachments, services and resources. The thing also dynamically starts to generate

its own services and formulates the corresponding APIs. Atlas thing then makes its debut in the

smart space by tweeting what it is, what it does, and what it knows. The Original Equipment

Manufacturer (OEM) of thing could be the source of the IoT-DDL. Or a developer who utilizes

the currently referenced Atlas Thing Architecture may be the provider of this file. This role

flexibility is built into the architecture to facilitate its adoption and to support thing innovation, in

which makers or hobbyists may assemble new things, not established OEM.

The Atlas Thing Architecture takes advantage of lightweight device management

standards OMA-LwM2M [37][38], object modeling standard IPSO [39], IoT communication

standards CoAP [66][67] and MQTT [64][65] to enable thing management and configuration

with minimal human intervention, and to empower ad-hoc interactions between the things and

the thing mates. Atlas Thing Architecture, as illustrated in Figure 5-1, consists of three main

layers: 1) the Atlas IoT Platform, 2) Host Interface, and 3) basic services for the Atlas IoT

platform hosted by the OS, named IoT OS services.

59

Figure 5-1. Atlas Thing Architecture.

IoT Operating System Services

IoT OS services are the basic functionalities provided by the thing’s operating engine and

represent a thing’s resources according to the proposed thing anatomy (Chapter 4). Such services

enable the thing to be part of the IoT through its network module, memory units, I/O ports and

interfaces (e.g., I/O, ADC), and its process manager. The process manager is responsible for

offering services for command execution and threading for concurrency if supported by the IoT

OS services. Services may also include hardware-based security if available, such as embedded

secure elements [68].

Interactions and Tweeting Engine

IoT-DDL Manager

API EngineIdentity

Parser

Attachment

Manager

Interface and Communication Engine

Identity and Knowledge

Tweets

API

Tweets

Atl

as I

oT

Pla

tfo

rm

DDL

Sublayer

Tweeting

Sublayer

Interface

Sublayer

Host Interface Layer

Network

Manager

Process

Manager

Memory

Manager

Device Secure

Elements

Services

Interfaces

Main Controller and Messaging Backbone

IoT

OS

Ser

vic

es

Device

Manager

Meaningful

Interactions

Security Engine and

Application Run-Time

Knowledge

Engine

60

Host Interface Layer

The Host interface layer shields the Atlas IoT platform – the logical layer of the Atlas

Thing Architecture as detailed below – and gives it the portability and interoperability it needs. It

also maintains the platform’s light weight by maximally relying on services provided by the

underlying OS (IoT OS services). The host interface layer manages the internal interactions

between the Atlas IoT platform and the set of services provided by the underlying OS. However,

the Host layer takes on the responsibility of providing any services that the underlying OS does

not provide. An extreme case is when there are no underlying OS’s to utilize in a given platform,

in which case the Host layer must implement all required services (e.g. the Arduino sensor

platform).

Atlas IoT Platform

The Atlas IoT platform represents the logical layer of the Atlas Thing Architecture that

runs on heterogeneous things to provide new functionalities and services not currently provided

by the thing’s operating system or engine. Such new services focus on the descriptive and

semantic aspects to better enable the thing to discover its own identity, resources, attachments

and capabilities, generate services and formulate appropriate interfaces (APIs) as well as enable

the thing to engage and interact with thing mates and scenarios through both thing-to-thing and

thing-to-cloud communication paradigms for a distributed interactive and social IoT ecosystem.

The Atlas IoT platform is divided into three key sub-layers: 1) DDL sublayer; 2)

Tweeting sublayer; and 3) Interface sublayer. Each sublayer contains multiple modules that

implement a set of functionalities. We describe these sub-layers in a bottom-up order in the

following sections.

61

DDL sublayer

The DDL sublayer is responsible for mapping and managing the IoT-DDL specifications

and attributes, from the uploaded IoT-DDL configuration file uploaded to the thing, to enable the

thing to discover its own identity, resources, entities, attachments, services and capabilities. This

sublayer is composed of the following modules:

1. The IoT-DDL manager opens a gate to access the uploaded IoT-DDL configuration file,

parses the various sections and subsections (as discussed in Chapter 4), and regulates access

to the IoT-DDL configuration file from the other modules.

2. The identity parser models the identification and descriptive information of the thing and its

entities. This module interacts with the IoT-DDL manager to parse the thing’s metadata for

how uniquely the thing can be viewed through the smart space.

3. The attachment manager parses the information through the IoT-DDL manager that identifies

the different cloud-based attachments linked to the thing as long with the appropriate

configuration and interactions with these attachments.

4. The knowledge engine models and formulates the information through the IoT-DDL

manager that identifies the different thing-level social bonds and service-level relationships

that define how logically and functionally the services can be offered in different ways and

can be linked to others’ services (as detailed in Chapter 6).

5. The device manager opens a communication channel with a device management server that

resides either on the edge or the cloud. This module interacts with the IoT-DDL manager

module to access information regarding the management server (e.g., server IP address and

access parameters). The thing then registers itself as a client at the server side for

provisioning, managing, and configuring the different attributes during the thing’s lifetime,

as well as enabling the authorized management commands (as detailed in the section on

device provisioning and management below).

6. The API engine enables the thing to generate the actual services offered by the thing to the

smart space from the service description. The API then formulates the corresponding

descriptive interfaces (APIs) for the generated services (as detailed in the Atlas thing services

section of this chapter).

Tweeting sublayer

The tweeting sublayer tools the thing with an explicit capability to uniquely define itself

in the smart space, in addition to discovering thing mates and interacting with them. This layer

formulates the thing’s identity besides the generated API, social relationships and bonds from the

62

DDL sub-layer modules (identity parser, knowledge engine and API engine) into tweets for the

Interface sub-layer to inform and share knowledge with other space things. The tweeting sub-

layer also parsers the different tweets received by the Interface sub-layer, extracts information,

and then updates the DDL sub-layer modules with the acquired knowledge (e.g., relationships,

social bonds, other things’ identities and APIs). The tweeting sublayer represents the gateway

that regulates the communication and queries between the interface and DDL sublayers, and is

further composed of the following modules:

The interactions and tweeting engine. This engine models a thing’s descriptive

information about its identity and generated APIs into sets of identity-oriented and API-oriented

tweets, respectively. Identity tweets hold metadata about a thing's identity, description, entities,

attachments and capabilities. API tweets hold metadata about the generated services and the

corresponding APIs. Such tweets are forwarded to the interface sublayer to be announced to

other thing mates in the smart space. At the same time, the engine parses the received

information-based tweets (e.g., other things’ identities, APIs, social relationships) as well as

action-based interactions (e.g., API call, management commands, and configurations). The

engine then forwards the interaction or tweet to the corresponding DDL sublayer modules to

store content.

The security engine and application runtime. This engine decodes received

interactions from thing mates to ensure authorization and authentication and encodes interactions

from the thing to its thing mates. The security engine and applications runtime interface with the

interactions and tweeting engine to build certified interactions from one side and the Atlas Thing

Architecture’s host interface layer from the other side.

63

Interface sublayer

To enable thing-to-thing and thing-to-edge or thing-to-cloud information- and action-

based interactions, the Atlas Thing Architecture exploits widely used communication protocols

for IoT and constrained environments. The interface sublayer holds the different communication

protocols (Message Queuing Telemetry Transport (MQTT) [64][65] and the Constrained

Application Protocol (CoAP) [66][67]) that allows the thing to engage with its mates

dynamically and in an ad-hoc manner (as illustrated below). The interface sublayer announces

the built tweets from the tweeting sublayer to the smart space and captures others’ tweets and

action-based interactions to be forwarded to the tweeting sublayer for processing. This is

described in the following section.

The MQTT. This protocol uses a publish/subscribe architecture on top of the TCP/IP

protocol, in contrast to the HTTP request/response paradigm. An MQTT broker is the central

communication point in charge of dispatching all messages between senders and receivers.

MQTT’s publish/subscribe is an event-driven paradigm that allows clients to publish messages

with topics and to subscribe to topics. The topic routes information for the broker; a client

subscribes to a topic and the broker delivers all messages with the matching topic to that client.

Topics can be organized into a name space of any hierarchical structure. MQTT enables highly

scalable and flexible solutions, where clients only communicate over the topic of interest without

having to know each other. Each MQTT client has a permanently open TCP connection to the

broker. If this connection is interrupted, the MQTT broker can buffer all messages and send them

to the client when it is back online. The network manager subsection of the administrative thing

metadata of the IoT-DDL specification lists the required configuration of MQTT. The

configuration includes the URL to the MQTT broker, listening port, and a list of topics to

subscribe to and publish accordingly. Table 5-1 below lists the different topics the Atlas thing

64

publishes and subscribes to in order to announce its own and receive others’ tweets, respectively.

Furthermore, Atlas things interact using another set of topics that include the things’ IDs. For an

Atlas thing to receive interactions, it must subscribe to an interaction topic that holds its own ID.

To forward an interaction to another thing mate, it must publish a topic that includes the thing

mate’s ID.

The CoAP. This protocol is a specialized web transfer protocol for use with constrained

nodes and constrained networks in a wireless sensor network (WSN) and IoT. CoAP is a

client/server computing model that provides a request/report paradigm model over UDP. To

compensate for UDP’s unreliability, CoAP defines a re-transmission mechanism and provides a

resource discovery mechanism with a resource description. CoAP provides URI and REST

methods such as GET, POST, PUT, and DELETE to access the various resources. The Atlas

Thing Architecture uses CoAP protocol support for multicasting, which allows things to

broadcast tweets for all listening things. The network manager subsection of the thing Resources

metadata of the IoT-DDL specification lists the required configuration of CoAP. The

configuration includes the listening port, a list of RESTful methods, and the corresponding

resources. Table 5-2 lists the resources an Atlas thing uses to announce its own tweets and ask

for others’ tweets. At the same time, Atlas things interact using another set of resources that

include the thing mates’ IDs.

Table 5-1. Atlas Topics for the MQTT protocol.

Atlas IoT Interactions Publish Topics Subscribe Topics

Information-based Interaction

(Tweet)

Tweet/Thing/Identity

Tweet/Entity/Identity

Tweet/API

Tweet/Thing/Identity

Tweet/Entity/Identity

Tweet/API

Action-based Interaction Interaction/ (ThingMate-ID) Interaction/(ThingMate-ID)

65

Table 5-2. Atlas Topics for the CoAP protocol.

Atlas IoT Interactions Thing Resources (URL) REST Method

Information-based Interaction

(Tweet)

Tweet_ThingIdentity

Tweet_EntityIdentity

Tweet_API

GET

Action-based Interaction Interaction_(ThingMate-ID) POST/PUT

The interface sublayer also supports the interoperability between the different

communication protocols (as detailed in Atlas communication interoperability section).

Device Provisioning and Management

In this section, we target the essential requirement of the seamless integration of the thing

into the ecosystem along with the ability to be managed and configured with minimal human

intervention. The Atlas Thing Architecture adopts two widely used standards for device

management and object modeling: 1) the Open Mobile Alliance Lightweight M2M (OMA-

LwM2M) [37][38] and 2) the IP Smart Object (IPSO) Alliance [39][40], respectively. As

detailed in the implementation and evaluation of the Atlas Thing Architecture (Chapter 9), the

architecture extends the implementation of the standard to allow the management not only for

device management standard objects supported by OMA but also for the different aspects of IoT-

DDL configuration files. OMA objects are a set of programmed objects defined by OMA

protocol and represent the different aspects of a device (e.g. connectivity monitoring,

connectivity statistics, location, firmware update).

The Atlas Thing Architecture translates the different sections and subsections of IoT-

DDL into a set of dynamic objects, called Atlas objects. Atlas objects, as shown in Figure 5-2,

represent the different entities, services, resources, and attachments of an Atlas thing. Atlas

objects are based on the object resource data representation model proposed by OMA-LwM2M

and utilize the IPSO idea of composite objects for higher modular object design. Extending the

66

broad standard for OMA with Atlas objects allows seamless engagement of Atlas things with

OMA-LwM2M/IPSO-powered entities in a smart space.

The device manager module of the DDL sublayer in the Atlas Thing Architecture, as

shown in Figure 5-3, creates and manages both OMA standard objects and Atlas objects through

an object engine. Atlas object creation and management occur on demand when IoT-DDL is

uploaded to the thing and during lifetime updates. At the same time, authorized lifetime

management and updates from the management server trigger the device manager’s object

engine module to maintain the corresponding objects and enables the authorized dynamic

updates to the IoT-DDL parameters and attributes during the lifetime of the thing.

Figure 5-2. Atlas objects’ tree.

Descriptive

Metadata

Structural

Metadata

Thing ObjectThing-entity

“n” ….

Attachments

Memory

Manager

Network

ManagerAdministrative

Metadata

Attachment 1

Attachment n

….

Descriptive

Metadata

Functions &

Services

Thing-entity “1”

AttachmentsAttachment 1

Attachment n

….

Function 1

Function n

….

Constraints

and Injected

Knowledge

RelationshipsSocial

Interactions

Entity 1 ref

Entity n ref

….

67

Powering up an Atlas thing starts the device manager module of the DDL sub-layer,

which in turn opens a communication channel with an OMA device management server. The

server either resides in a space thing (e.g. Edge-thing type) or the cloud. The device manager

module then communicates with the IoT-DDL manager module to access information about the

management server (e.g. server IP address and access parameters). The Atlas thing registers itself

as an OMA client, and then registers a tree for its programmed objects (both OMA standard

objects and Atlas objects) at the server side. The server can provision the thing, besides being

able to read and update the different objects of the client during the thing’s lifetime.

Figure 5-3. Device manager and OMA objects.

IoT- DDL

Manager

IPSO

OMA LwM2M

OMA standard and Atlas

Objects

Atl

as T

hin

g A

rch

itec

ture

Authorized Device Management Commands and Configurations

Ob

ject

s R

epo

sito

ry

Create/Update/Manage

Higher Layers of Atlas Thing Architecture

Device

Manager

Commands Parser

Objects Engine

IoT-DDL

Configuration File

68

Atlas Communication Framework

The Atlas Thing Architecture, as mentioned before, utilizes MQTT and CoAP

communication protocols to enable the thing to establish a wide range of interactions and

interconnections with other things in the smart space. Each protocol is designed for a specific set

of application requirements and aspects of IoT communications, such as low-power operation,

lightweight headers, semantic intent-oriented messaging, service discovery and orientation,

bootstrapping, and statelessness [71]. Such communication protocols blur the lines between

messaging mechanisms and semantic-based computation. However, the wide heterogeneity in

types and communication capabilities makes the participation of things in a smart space a

significant challenge and restricts service and application development that can benefit from

heterogeneous things. Thus, interoperability has the potential to homogenize things that speak

different communication languages so that they can interact and cooperate.

In this subsection, the Atlas communication framework is presented for an interoperable

distributed IoT ecosystem. The proposed framework enables seamless interaction between

homogenous things that speak similar languages as well as heterogeneous things that speak

different communication languages in a smart space with minimal human intervention. In

addition, the framework does not additionally tax performance of the homogenous

communicating things. This framework is composed of three parts:

1. Atlas topics empowered by the idea of MQTT topics to create a set of common channels for

things to discover other things and services in the smart space, as well as to enable peer-to-

peer interactions.

2. The Atlas protocol translator (as a thing attachment, which can be either off-thing, residing

on a cloud platform or edge, or an on-thing service running within the Atlas Thing

Architecture) provides translation service to the thing through a set of well-defined

interfaces, allowing the thing to communicate and interact with heterogeneous things.

69

3. An extended version of the interface sublayer of the Atlas Thing Architecture to enable

seamless interoperability between things that use both similar and different communication

protocols.

The framework utilizes the widely adopted CoAP, MQTT and HTTP-REST [70][71] IoT

communication standards for application-layer network protocol interoperability. The framework

utilizes the minimum delimiter among the various communication protocols to provide

homogenous communication links and promotes topics as a suitable mechanism to link topic-

oriented protocols (e.g., MQTT) with URL-oriented protocols (CoAP, HTTP-REST).

Atlas IoT Topic Hierarchy

The framework features the idea of MQTT topics to create a set of common channels

(“Atlas topics”) on which HTTP REST-, CoAP- and MQTT-speaking Atlas things can

communicate, advertise, and interact. The framework utilizes three main attributes in the Atlas

thing subsection of the IoT-DDL specifications:

1. Smart Space ID (SSID), the identifier for the smart space defined by the space owner (e.g.,

owner name, cell phone number, and zip code of the space) that ensures the uniqueness of the

identity between the different smart spaces.

2. Atlas Thing ID (ATID), the identifier for the thing defined by the owner or IoT-DDL

developer that ensures the uniqueness of the thing for the same smart space.

3. Smart Space Broker (SSB), that defines the access interface to a broker provided by the space

owner or offered by a third party (e.g., Eclipse MQTT sandbox [72], MQTT-HiveHQ [73]).

Learning the SSB is an essential step to establishing an initial shared communication

medium through which smart space things which speak in different communication languages

can sense their mutual presence and communicate. On powering up an Atlas thing, as illustrated

in Figure 5-4, the thing connects to the default broker that is indicated by the SSB of IoT-DDL

and subscribes to the Atlas topics. MQTT-speaking things connect directly to the broker, while

the non-MQTT-speaking things (HTTP REST- and CoAP-speaking thing) utilize their own Atlas

70

protocol translator to connect and subscribe to this broker. To keep the communication channels

secure and private, or to utilize a required broker, the framework lets the space owner

dynamically assign a new broker to the smart space through one of the shared Atlas topics. The

new broker can be an Atlas thing with high capabilities (e.g., memory or a power source) that

offers broker service to the smart space. The Atlas things in the same smart space must have the

same SSID and SSB values to ensure that they can communicate and interact with the same

broker using the same channels.

Figure 5-4. Smart space broker and HTTP REST-, CoAP- and MQTT- speaking things.

To ensure uniqueness, the framework uses the Atlas_(SSID) topic as the root of the

hierarchy under which all Atlas things communication and interactions take place. The root

topic, as illustrated in Table 5-3, is further divided into network, multicast, and unicast subtopics.

MQTT-speaking

thing

Smart space broker (SSB)

CoAP-speaking

thing

Off-thing

Atlas protocol

translator

APINotifications

Data

HTTP REST-speaking

thing

On-thing

Atlas protocol

translator

Smart space with ID (SSID)

71

Such subtopics enable things in a smart space to sense the network for the presence of MQTT

clients and any required broker that replaces the default broker. The subtopics, detailed below,

also allow things to multicast packets and perform peer-to-peer interactions.

Table 5-3. Atlas IoT topic hierarchy.

Root Topic Sub-topic

/Atlas_(SSID) /Network /MQTT_Client

/Private_Broker

/Multicast /Thing_Identity

/Thing_API

/Unicast /Interaction_(ATID)

The network topic. The network topic keeps the thing’s attention on network updates

through two subtopics: 1) The MQTT_Client topic indicates the existence of at least one MQTT-

speaking Atlas thing in the smart space. After powering up, an MQTT-speaking thing publishes

“true” to the MQTT_Client to mark the existence of an MQTT thing in the smart space. At the

same time, non-MQTT-speaking things subscribed to the topic hierarchy detect the presence of

MQTT client(s) in their smart space and route all future unicasting with intended MQTT peers

through the broker, which requires an Atlas protocol translator. Similarly, multicasting of non-

MQTT-speaking things is also routed through the broker. The content of the MQTT_Client topic

is empty by default to indicate that no MQTT-speaking things exist in the smart space initially;

and 2) The Private_Broker topic holds the access information (e.g., URL, IP, and port) for an

optional new broker assigned to the current smart space by the space owner. The Private_Broker

topic enables the space owner to specify an alternative broker for the space things to use, other

than the default broker defined by SSB of the IoT-DDL. If the content of the topic is null by

default, no private broker exists, and Atlas things will use the default broker. Such a powerful

Atlas thing (which offers broker service) publishes the access information of the offered broker

72

service to the Private_Broker topic. All other subscribed Atlas things are notified of the new

broker, disconnected from the default broker defined by the SSB identified in IoT-DDL, and

connected and subscribe to the same topic hierarchy on the new broker.

The multicast topic. The multicast topic is the topic channel where Atlas things can

propagate information-based interactions to all other Atlas things in the smart space. An Atlas

thing announces its presence, identity, and internal entities on the Thing_Identity topic, and APIs

for its offered resources to other things in the smart space on the Thing_API topic. The multicast

topic, which all Atlas things are subscribed to, not only allows an Atlas thing to announce its

presence and capabilities, but also enables an Atlas thing to discover other things and the

distributed services offered by them. However, an Atlas thing can unicast an API call for a

service offered by another thing on a separate dedicated channel linked to the peer’s ID, which

guarantees that no other things are listening to the conversation.

The updates on the topics listed under “Network Topic” shape two cases for multicasting.

The existence of MQTT-speaking things in the smart space indicated by the MQTT_Client topic

(as the first case), requires the MQTT-speaking things to affect a multicast through the broker

and the non-MQTT-speaking things to utilize the translator to multicast through the broker. The

absence of MQTT-speaking things, on the other hand (as in the second case), triggers CoAP-

speaking things to utilize the UDP multicasting capability of the CoAP standard on the same

multicast topics, as illustrated in Figure 5-5.

The unicast topic. The unicast topic of the Atlas topic hierarchy is the topic channel

where an Atlas thing can initiate peer-to-peer, action-based interactions in the form of API calls.

The action-based interactions enable an Atlas thing to request a specific service or call for an

API offered by another Atlas thing in the smart space. With the presence of MQTT-speaking

73

things in the smart space, indicated by the MQTT_Client topic (as in the first case), each non-

MQTT-speaking thing through its translator as well as MQTT-speaking thing subscribes to its

Interaction_(ATID) topic on the broker. Including ATID as part of the topic name ensures that

each thing has a unique channel through which other things can initiate a private unicast. An

Atlas thing that initiates a unicast interaction publishes to the unicast topic of the corresponding

peer using the peer’s ATID to ensure that no other things are listening to the conversation. The

absence of MQTT-speaking things (as in the second case) triggers non-MQTT-speaking things to

utilize the UDP unicasting capability of the CoAP standard on the same topic of the peer (in the

case of CoAP-speaking things) and the TCP unicasting capability of HTTP (in the case of

HTTP-speaking things), as illustrated in Figure 5-5 and Figure 5-6, respectively. The payload of

the unicast interaction contains the API call for the service in addition to the API’s required

arguments for the other thing to handle the execution.

Figure 5-5. CoAP standard multicast and unicast communication.

Smart space broker (SSB)

CoAP-speaking thing

Off-thing

Atlas protocol

translator

APINotifications

Data

Smart space with ID (SSID)

CoAP communication

CoAP-speaking thing

74

Figure 5-6. HTTP REST standard unicast communication.

Atlas IoT Protocol Translator

The Atlas protocol translator provides MQTT translation service for a non-MQTT-

speaking thing through a set of well-defined programmed interfaces for the seamless interaction

with MQTT things. The proposed translator is a thing attachment that can either be an off-thing

accessory residing on a remote platform (e.g., cloud platform or edge device) or an on-thing

service that is executed by the thing itself. In either case, the thing interfaces with its own

protocol translator and asks the translator to (a) connect to the broker identified by SSB and

subscribe to the Atlas topic hierarchy; or (b) multicast or unicast data on specific topics through

the interface functions depicted in Table 5-4. The translator notifies the thing of updates

published to Atlas topics and interactions destined to the thing’s unicast topic through the

appropriate interface function.

Smart space broker (SSB)

REST-speaking thing

Off-thing

Atlas protocol

translator

APINotifications

Data

Smart space with ID (SSID)

HTTP REST communication

REST-speaking thing

75

Table 5-4. Translator interface functions.

Method Input

EstablishConnection [translator IP and Port]

BrokerSettings [SSB and Atlas Topic Hierarchy]

MulticastPublish [Multicast Topic]

UnicastPublish [Unicast Topic]

The Atlas protocol translator, as illustrated in Figure 5-7, is composed of the following 6

modules.

Figure 5-7. Atlas protocol translator.

Translator gateway. The gateway accepts translation requests received from the

connected non-MQTT-speaking thing through the interface function EstablishConnection and

hands them to the packet dispatcher and response builder module. The gateway module also

opens a communication channel with the broker indicated by the parameters of the

EstablishConnection request and hands the responses from the packet dispatcher and response

builder module back to the connected thing.

Packet analyzer and response builder. The analyzer and response builder performs two

functions. First, it interprets the received translation request on the interface functions. The

request can be to (a) establish a connection with a broker and subscribe to the topic hierarchy

(the BrokerSettings interface function), (b) publish data to a specific multicast topic (the

Translator Gateway

Packet Analyzer and Response builder

Multicast

Handler

Unicast

Handler

Connection

Manager

Proxy Client

76

MulticastPublish interface function), or (c) unicast an interaction topic (the UnicastPublish

interface function). The packet analyzer submodule forwards the request to the connection

manager, multicast handler, or the unicast handler, respectively. The module’s second function is

to capture MQTT responses on these requests from the broker and map them to the connected

thing through the interface functions. It should be noted that each interface function request is

processed on a separate thread, in which the thread is blocked until the packet dispatcher and

response builder returns the response.

Connection manager. The connection manager handles the requests from non-MQTT-

speaking things to establish a connection with a broker and to subscribe to topic hierarchy

(specified from the inputs to the BrokerSettings interface function). The manager also handles

new connections to new private brokers that publish their existence to the Private_Broker topic.

The MQTT acknowledges the broker connection and subscriptions as well as the point at which

data notifications are handed back to the response builder submodule to notify the connected

thing.

Multicast handler. The multicast handler translates data posting requests to a multicast

topic (the MulticastPublish interface function) into the MQTT publish requests to the proxy

client and hands the acknowledgment back to the response builder submodule.

Unicast handler. The unicast handler translates the interaction requests to the unicast

topic (the UnicastPublish interface function) into MQTT publish requests to the proxy client, and

then hands the acknowledgment back to the response builder submodule.

Proxy client. The proxy client is a lightweight client process that handles the connection,

subscription, and publishing of MQTT packets to the broker specified by the connected thing

through the gateway module. The proxy client also hands acknowledgments and data

77

notifications back from the broker to the connection manager, multicast handler, and unicast

handler modules according to the content.

Atlas Thing Architecture Interface Sublayer

We extended the current interface sublayer of the Atlas Thing Architecture with further

capabilities to enable the seamless interaction between the things that speak similar languages as

well as things that speak different languages. The original interface sublayer of the Atlas Thing

Architecture (the focus of this subsection), through which the communication protocols the thing

speaks to engage and interact, currently supports only homogenous communication. Figure 5-8

illustrates the architecture with a focus on the interface sublayer with extended capabilities.

The extended interface sublayer of the Atlas Thing Architecture is composed of the

following 5 modules:

1. The packet sniffer senses communication packets and classifies them as either homogenous

packets of the same language that the thing speaks, or heterogeneous packets received from

the connected Atlas protocol translator.

2. The primary packet engine handles the homogenous requests and interactions received and

builds the corresponding responses to the requesters.

3. The proxy packet engine handles the heterogeneous requests and interactions destined for the

translator manager and captures the responses to the requesters.

4. The translator manager is either an on-thing attachment of the Atlas protocol translator or an

off-thing attachment of the same. In the latter case, the translator manager opens and

manages a communication channel with the protocol translator through the well-defined

interfaces depicted in Table 5-4.

5. The topic repository keeps track of the latest published values to the various Atlas topics and

interacts with the tweeting sublayer of the Atlas Thing Architecture to access both

information-based and action-based tweets and interactions.

78

Figure 5-8. Atlas Thing Architecture with focus on the interface sublayer.

Atlas Thing Services

The API engine of the DDL sublayer through the uploaded IoT-DDL configuration file

enables the thing to dynamically: 1) discover the different services it offers to the thing mates in

the smart space; 2) dynamically generate a bundle (code and resources) of the actual service

through the microservices framework; and 3) formulate and generate the appropriate

programming interfaces (APIs) to access the offered services by the thing. The API engine, as

illustrated in Figure 5-9, consists of four sub-modules:

Bundle and API generator module. The bundle and API generator interacts with the

IoT-DDL manager to parse services’ information (inputs, outputs, data types, value ranges,

Identity and Knowledge TweetsAPI TweetsA

tlas

Io

T P

latf

orm

Inte

rfac

e S

ubla

yer

Host Interface Layer

Network

Manager

Process

Manager

Memory

Manager

Device Secure

Elements

Services

Interfaces

Main Controller and Messaging Backbone

IoT

OS

Ser

vic

esInteractions

DDL Sub-layer

Tweeting Sub-layer

Topics Repository

Primary Packet Engine

Packet Sniffer

Homogeneous Packets

Translator

Manager

Heterogeneous Packets

Proxy Packet Engine

79

descriptions, and functionality) stored in the IoT-DDL. The module converts service descriptions

(as shown in Chapter 4) into executable packages (bundles), interacting with the compiler service

provided by the IoT OS Services of the Atlas Thing Architecture. The module then formulates a

descriptive API for each of the generated service bundles as a way for the thing mates to trigger

the offered functionality through the thing.

Each API, as Figure 5-10 illustrates, has three parts: 1) function name as a short

description of the offered service; 2) list of inputs to the service, where each input is represented

in a tuple that holds an input description, data type, and value range; and 3) the expected output

of executing the service, where the output is represented in a tuple that also holds the description,

data type, and value range. The engine then exposes the generated APIs to the tweeting sublayer

of the Atlas Thing Architecture for advertisement to thing mates through tweets. On the other

hand, an application (API call) is captured and parsed in the architecture’s tweeting sublayer that

in turns forward the received API call to the API parser and validator module of the engine. This

API call holds the function name, followed by a list of values representing the corresponding

inputs to the service.

API parser and validator. The API parser parses the received applications (API calls)

from thing mates, and checks their structure validity as well as input types and ranges. The

module then hands the API call to the bundle repository.

Bundle repository. The repository stores and manages the generated bundles and

handles bundle execution through the service execution sub-module.

Service execution. The service execution module oversees packaging the relevant input

values, sending them to the running bundle, and retrieving the resulting values before handing

them off.

80

Figure 5-9. API engine structure.

Figure 5-10. API structure.

The Atlas Thing Architecture (as detailed in Chapter 9) utilizes the Apache licensed

Mircro Services framework [74] in the API Engine to facilitate dynamic service generation,

Bundle Repository

Bundle and

API Generator

Service Execution

API Parser and Validator

APIAPI call and

ApplicationResult(s)

Interactions and

Tweeting Engine

Security Engine and

Application Run-Time

IoT-DDL Manager

AP

I E

ng

ine

IoT-DDL

Services’ sections

DDL

Sublayer

Tweeting

Sublayer

Function Name : [Inputs Tuples] : (Output Tuple)

(Description, Type, Range), ... , (Description, Type, Range)

(Description, Type, Range)

Input 1 Input n

81

registration, discovery and service-oriented APIing. The Atlas thing dynamically generates a

software bundle for each service described by the vendor in the thing’s IoT-DDL. The Micro

Services project aims to allow for the creation of service-based applications based on the

dynamic module system of OSGi [75]. Each microservice, called a bundle, is a specially-

packaged shared library object that runs in its own context within the microservices framework.

The state of these bundles can be managed dynamically during the lifetime of the Atlas thing.

The bundle is a package containing the actual code and resources a thing needs to provide

the described functionality. The creation of the bundles, as well as installing (adding) and

uninstalling (removing) them from a pool of bundles is maintained by the thing through the

microservices framework at runtime. Each thing service is represented as an independent

microservice bundle and can be executed through a single call to the corresponding API taking

inputs and returning outputs as specified by the IoT-DDL. Before a thing’s services can be run,

their bundles are dynamically generated by the API Engine of the Atlas Thing Architecture from

the specification of the uploaded IoT-DDL. Once the Atlas Thing Architecture has parsed the

IoT-DDL, the inputs and outputs are mapped to their corresponding native types and the generic

actions are mapped to platform-specific function calls. The API Engine handles the execution of

the bundle upon receiving the corresponding API call from other things in the smart space.

82

CHAPTER 6

INTER-THING RELATIONSHIPS PROGRAMMING FRAMEWORK

In this chapter, we present the Inter-thing relationship programming framework that

utilizes both the Atlas Thing Architecture (Chapter 5) and the thing IoT-DDL project (Chapter 4)

for a distributed programming model for the social IoT. The framework broadens the social IoT

thing-level relationships that logically link the things according to their identification attributes

(e.g., things from the same vendor) with a set of concrete relationships between the services

offered by the things that could logically and functionally tie these services together. We believe

that the exploitation of service-level relationships in the context of social IoT adds an effective

programming perspective to the social IoT and empower the developers to program a much

wider class of meaningful IoT applications.

The framework introduces three primitives to build the IoT application: 1) Thing Service

(TS) – an abstraction of the service offered by a thing to the smart space; 2) Thing Relationship

(TR) – an abstraction of how the different TSs are linked together; and 3) Recipe – an abstraction

of how the different TSs and TRs build up a segment of an app (an Atlas IoT app is a sequence

of recipes). The framework also outlines Filter, Match, and Evaluate as three operators that

define how the primitives are wired. The thing vendor, Atlas thing (a thing that runs the Atlas

Thing Architecture) and developer are the main poles of the framework. This chapter presents

the framework’s primitives and operators and highlights the different relationships that can take

place between the services along with the different recipe types. This chapter then presents the

semantic rules that govern the establishment of applications as well as the roles of the main poles

in establishing the IoT app at runtime.

83

Framework Primitives

The proposed framework introduces Thing Service (TS), Thing Relationship (TR), and

Recipe as the three primitives to build an Atlas IoT application.

Thing Service

Thing service is an abstraction of a service that an Atlas thing offers to the smart space

things and developers. The vendor describes the services offered by an Atlas thing through the

IoT-DDL to be uploaded to the thing (Chapter 4). The Atlas thing—when powered up or when

any change to the service description occurs—parses the IoT-DDL and creates a run-time

programmable abstraction for each service it offers, named Thing Service (TS) in the knowledge

engine of the DDL sublayer of the Atlas Thing Architecture. The TS represents the

characteristics of the service in terms of the offered functionality, who is offering it, and how it

can be accessed. The Atlas thing then advertises these TSs (one TS for each offered service) to

thing mates and saves received mates’ TSs. It is worth mentioning that the TS object uses the

assets and ideas in service discovery protocols defined by SOA [50][92]. The same idea is used

in the current research in a slightly different way to enable the dynamic declaration of

relationships between the different TSs in a distributed programming ecosystem. Each TS, as

illustrated in Figure 6-1 below, describes the service through a set of attributes (Attributes) and

an interface to access the offered service (Interface) as follows:

Attributes. The attributes are the metadata that describe the characteristics of the service

in key-value pairs. The attributes are sub-divided into three groups: a) Identification information

for the thing with “Space ID,” “Thing ID,” “Name,” “Vendor,” and “OS” as the keys. The values

of the keys are extracted from the uploaded IoT-DDL (e.g., identity attributes for a thing that

offers GPS can be {(Name, nuvi58LM), (Vendor, Garmin)}); b) Descriptive information that

describes the offered functionality using a set of words declared in the IoT-DDL, with

84

“Keywords” as the key, (e.g., descriptive information for a navigation service could be

Keywords: {Location, Map, Route}); and c) Type of offered service, where the key “Type” takes

either condition, report or action as a value. Condition is a type of service that examines specific

phenomena, returning a domain value if the condition exists and false otherwise (e.g., Check to

see if there is a parking spot, return the available spot). Report is a type of service that returns a

numerical value (e.g., read a temperature sensor, return the value). Action is a type of service

that performs an actuation function, returning a domain value upon a successful call and one that

is false otherwise (e.g., turn on the electric switch, return true if the function was triggered).

Figure 6-1. Structure of the thing service (TS).

Interface. The interface provides a direct way to trigger the service on the hosting thing.

The interface, from the IoT-DDL, is defined in terms of the function’s name, inputs, and output.

Each input is a data variable that is defined by a short description, data type (e.g., integer, float

point) and domain range (the acceptable input values). The output depends on the type of offered

Structure TS (Thing Service)

1- Attributes

• Space ID

• Thing ID

• Name

• Vendor

• OS

• Keywords

• Type

2- Interface

• Name

• Inputs

• Output

/ /ID for the smart space where the thing coexists

/ /ID for the thing that offers the service

/ /Name of the thing

/ /Name of the thing vendor

/ /The operating system the thing is running

/ /Descriptive attributes in terms of a set of keywords that

describes the offered service

/ /condition, report or action

/ /Name of the function

/ /Data variables

/ /Domain value if successful execution, and false otherwise

85

service (condition, report or action). The API Engine of the Atlas Thing Architecture (as detailed

in Chapter 5) handles the dynamic generation of the services, formulation of the appropriate

programmable interfaces (APIs), routing of API calls, and performing the corresponding check

on the expected inputs’ types and ranges.

Thing Relationship

An abstraction of a connection between TSs that defines how two or more services are

logically and functionally tied to build meaningful applications. The relationships defined by the

framework can be: 1) utilized by the vendor in the thing’s IoT-DDL as prior knowledge to the

thing, 2) utilized by the developer while building applications, and 3) inferred as new

programming opportunities by the development environment from the exchanged knowledge

between the things (as detailed in Chapter 7). The Atlas thing—when powered up, or after any

change to the relationship description—parses the IoT-DDL and creates a programmable object

named a Thing Relationship (TR) for each relationship established by the vendor in the IoT-

DDL. The Atlas thing then advertises such TR(s) to thing mates, while the Atlas RIDE – at the

same time – collects and saves received mates’ TRs (as detailed in Chapter 7).

However, due to the lack of knowledge about all services offered by things ahead of their

announcements, vendors require a way to establish a TR between an offered service (TS) and an

unbounded service (UB). A UB enables the relationship establisher to describe a service, which

may not yet be announced by a thing in the smart space, to be matched with one of the TSs

offered by an Atlas thing later in time. During the execution of an application, the offered TSs

are checked for the closest matches to the UB(s).

When a match occurs (as a detailed framework operator subsection), the UB is replaced

with a reference (space id, thing id, and TS name) to the closest matched TS (in case of a tie, the

first match will be selected). The evaluation of such a TR is enabled only when there is a match

86

for each UB defined in it. Each UB is described in terms of the expected vendor of such service,

the service type (e.g., report), a set of descriptive words for the functionality, and the acceptable

value of the match with a TS. The acceptable value of the match reflects how similar a TS should

be to replace the UB. Each attribute of the UB may accept the wildcard as input (e.g., to match

any TS’s vendor, the UB vendor holds * as a value).

Figure 6-2. Structure of the thing relationship (TR).

Each TR, as illustrated in Figure 6-2, describes the characteristics of the relationship

through a set of attributes (Attributes), a set of unbounded services defined by the relationship

vendor (UBs), and an interface to access the relationship (Interface).

1. Attributes, metadata in key-value pairs that declare who established this relationship with

“Name” as the key and the type of established relationship with “Type” as the key (takes one

of the following values: control, drive, support, or extend for cooperative relationships, or

contest, interfere, refine, or subsume for competitive ones – detailed later in this chapter).

2. UB(s), one or more unbounded services defined in the TR, each defined with a vendor, type,

keywords and match value.

Structure TR (Thing Relationship)

1- Attributes

• Name

• Type

2- UB(s)

• Vendor

• Type

• Keywords

• Match

3- Interface

• Formula

• Inputs

• Output

/ /Name of the establisher (e.g., Samsung)

/ /Control, drive, support, or extend for cooperative relations, or

contest, interfere, refine, or subsume for competitive relations

/ /The expected service vendor (e.g., Philips)

/ /Condition, report or action

/ /Set of keywords that describes the service

/ /Acceptable match with TS attributes

/ / Inputs order and dependencies

/ /TS(s), UB (s), Data variable(s)

/ /Domain value if successful execution, and false otherwise

87

3. Interface, a direct way to execute the relationship with inputs, formula, and output. The

interface input can be a TS or UB, or a data variable defined by a description, type, and

domain. The formula reflects how the inputs are processed (detailed later in this chapter).

The relationships are evaluated independently, even if a single TS is involved in multiple

relationships.

Recipe

A recipe is a connection between different TSs and TRs to build up a segment of an

application, where an IoT application is a sequence of one or more recipes. It is worth

mentioning that the term Recipe is also used in If This Then That (IFTTT) [45] to describe an

application. In this dissertation, the same term is used to describe a sequence of TSs and TRs

and evaluated sequentially. Each Recipe, as illustrated in Figure 6-3, describes a segment of an

application through a set of attributes (Attributes) and an interface through which this recipe is

accessed (Interface).

1. Attributes, metadata in key-value pairs that declare who established the recipe with “Name”

as the key and the type of recipe with “Type” as the key (either simple or conditional –

declared later in this chapter).

2. Interface, a direct way to execute the recipe in terms of the inputs, formula, and output. Each

input can be TR or TS. The formula reflects the sequence of how the inputs are processed

and maintains the required dependencies between them (detailed later in this chapter).

Figure 6-3. Structure of the recipe.

Structure Recipe

1- Attributes

• Name

• Type

2- Interface

• Formula

• Inputs

• Output

/ / Name of the recipe establisher

/ /Simple or conditional

/ /Inputs order and dependencies

/ /TS(s), TR(s)

/ /Domain value if successful execution, and false otherwise

88

Framework Operators

The framework defines Filter, Match, and Evaluate as three operators that logically and

functionally define how the primitives are wired. In this section, we will detail the operations and

the attributes that configure each of the three operators.

Filter

This operator accepts a set of TSs and selects a subset according to preferences. A

preference (declared in Equation 6-1) is a key-value pair that represents one of the TS attributes’

keys (e.g., service type, service vendor) while the value is declared by the operator establisher

(e.g. developer). The filter operator accepts (as declared in Equation 6-2) n TSs and m

preferences then selects the subset of TSs that follows the input preferences (e.g., for TSs from

“Philips,” the establisher uses (Vendor, “Philips”) as the preference – where Vendor is one of the

TS’s attributes while “Philips” is the value declared by the establisher). The operator can be

extended to accept a set of TRs and select a subset (e.g., get all relationships established by

“Samsung” as Name – where Name is one of the TR’s attributes). The preference, through the

filter operator, can: 1) be optionally negated using the logical negation (). Thus the logical

negation of the preference (Vendor, “Philips”) selects services from all vendors other than

“Philips;” and 2) can be accumulated with other preferences using the logical AND (∧), OR (∨),

and XOR (⊕) operators to select one or more TSs. Thus, as illustrated in Equation 6-2, the

operator filters a set of n TSs {TS1, TS2, … TSn} into either: 1) {TSi, TSj, … TSk} as the subset

of services that follows the logically linked and optionally negated m preferences (P1, P2, … Pm),

where i, j, and k are the indexes of the selected TSs in the original set, and 1 ≤ i, j, k ≤ n; or 2) an

empty set {∅} when no service from the n TSs follows the preferences.

𝑃𝑟𝑒𝑓𝑒𝑟𝑒𝑛𝑐𝑒 𝑝 = (𝐾𝑒𝑦, 𝑉𝑎𝑙𝑢𝑒), 𝑤ℎ𝑒𝑟𝑒 𝐾𝑒𝑦 ∈ {Name, Vendor, OS, Type, Keywords} (6-1)

89

𝐹𝑖𝑙𝑡𝑒𝑟( 𝑝1) ⊝ ( 𝑝2) ⊝ … ( 𝑝𝑚) {𝑇𝑆1, 𝑇𝑆2, … 𝑇𝑆𝑛}𝑤ℎ𝑒𝑟𝑒 𝑖𝑠 𝑎𝑛 𝑜𝑝𝑡𝑖𝑜𝑛𝑎𝑙 𝑎𝑛𝑑 ⊝ ∈ {∧,∨,⊕}

= {{𝑇𝑆𝑖, 𝑇𝑆𝑗, … 𝑇𝑆𝑘}, 𝑇𝑆𝑠 𝑓𝑜𝑙𝑙𝑜𝑤 𝑡ℎ𝑒 𝑝𝑟𝑒𝑓𝑒𝑟𝑒𝑛𝑐𝑒𝑠 𝑤ℎ𝑒𝑟𝑒 1 ≤ 𝑖, 𝑗, 𝑘 ≤ 𝑛

{∅}, 𝑜𝑡ℎ𝑒𝑟𝑤𝑖𝑠𝑒 (6-2)

Match

This operator measures the similarity between an unbounded service UB declared in a TR

and a TS offered by an Atlas thing in the smart space through two methods. The first method

(Equation 6-3) accepts a UB and a TS as input and measures the similarity between the

attributes’ values (vendor, type, keyword). The calculated match value (initially zero) is

increased by a constant value V1 (defined in the framework), for each match in the vendor or the

type. The value is also increased by a constant value V2 (defined in the framework) for each

word in the UB’s keywords that exists in the TS’s keywords.

The two positive constant values (V1 and V2) are declared and configured by the

development environment that implements the proposed programming model (e.g., Atlas RIDE –

detailed in Chapter 7) to reflect the weight of each of the attributes (vendor, type, keyword) on

the calculated match value. The two positive constant values (V1 and V2) can be set as required

by the development environment or the developer’s preferences. The match value is then

compared to the acceptable match value defined in the UB object. The higher the match value is,

the closer the TS is to replacing the UB.

𝑀𝑎𝑡𝑐ℎ (𝑈𝐵, 𝑇𝑆) = 𝑚𝑣𝑎𝑙𝑢𝑒, 𝑤ℎ𝑒𝑟𝑒 𝑚𝑣𝑎𝑙𝑢𝑒 =

{

𝑚𝑣𝑎𝑙𝑢𝑒 + 𝑉1, 𝑖𝑓 𝑈𝐵 𝑎𝑛𝑑 𝑇𝑆 𝑎𝑟𝑒 𝑜𝑓 𝑠𝑎𝑚𝑒 𝑉𝑒𝑛𝑑𝑜𝑟 𝑚𝑣𝑎𝑙𝑢𝑒 + 𝑉1, 𝑖𝑓 𝑈𝐵 𝑎𝑛𝑑 𝑇𝑆 𝑎𝑟𝑒 𝑜𝑓𝑠𝑎𝑚𝑒 𝑇𝑦𝑝𝑒 𝑚𝑣𝑎𝑙𝑢𝑒 + 𝑉2, 𝑓𝑜𝑟 𝑒𝑎𝑐ℎ 𝑐𝑜𝑚𝑚𝑜𝑛 𝑘𝑒𝑦𝑤𝑜𝑟𝑑 𝑖𝑛 𝑈𝐵 𝑎𝑛𝑑 𝑇𝑆

, 𝑤ℎ𝑒𝑟𝑒 0 ≤ 𝑉1𝑎𝑛𝑑 0 ≤ 𝑉2 (6-3)

In order to find a match to a UB, the development environment should apply the first

method (Equation 6-3) on each of the available TS in the smart space. However, the second

method utilizes the available relationships in the smart space for an efficient search for a match.

For a smart space with n TSs and m TRs, if a UB is related to TSx (x is the index of this TS in the

90

n TSs where 1≤ x ≤ n) through a relationship TRi, (i is the index of this TR in the m TRs where

1≤ i ≤ m), this method (Equation 6-4) first checks whether TSx also exists in another relationship

TRj (j is the index of this TR in the m TRs where 1≤ j ≤ m and i ≠ j); that is: 1) of inverse type

with TRi (control/controlled-by, support/supported-by, extend/extended-by or drive/driven-by for

cooperative relationships, or refine/refined-by or subsume/subsumed-by for competitive ones –

detailed later in this chapter); or 2) of same type with TRi (both are either contest or interfere – as

detailed later in this chapter). This method then applies the first method (Equation 6-3) between

the UB declared in the TRi and the other TS(s) declared TRj for a probabilistic match.

𝑀𝑎𝑡𝑐ℎ (𝑇𝑅𝑖, 𝑇𝑅𝑗) =

𝑀𝑎𝑡𝑐ℎ (𝑈𝐵, 𝑇𝑆𝑦) 𝑤ℎ𝑒𝑟𝑒

{

𝑇ℎ𝑒𝑟𝑒 𝑖𝑠 𝑎 𝑐𝑜𝑚𝑜𝑛 𝑠𝑒𝑟𝑣𝑖𝑐𝑒 (𝑇𝑆𝑥) 𝑖𝑛 𝑏𝑜𝑡ℎ 𝑇𝑅𝑖 𝑎𝑛𝑑 𝑇𝑅𝑗

𝑇𝑅𝑖 𝑎𝑛𝑑 𝑇𝑅𝑗 𝑜𝑓 𝑖𝑛𝑣𝑒𝑟𝑠𝑒 𝑡𝑦𝑝𝑒𝑠 || 𝑏𝑜𝑡ℎ 𝑎𝑟𝑒 𝑐𝑜𝑛𝑡𝑒𝑠𝑡 𝑜𝑟 𝑖𝑛𝑡𝑒𝑟𝑓𝑒𝑟

𝑈𝐵 𝑖𝑠 𝑑𝑒𝑐𝑙𝑎𝑟𝑒𝑑 𝑖𝑛 𝑇𝑅𝑖 𝑇𝑆𝑦 ∈ 𝑠𝑒𝑟𝑣𝑖𝑐𝑒𝑠 𝑑𝑒𝑐𝑙𝑎𝑟𝑒𝑑 𝑖𝑛 𝑇𝑅𝑗1 ≤ 𝑖, 𝑗 ≤ 𝑚 𝑖 ≠ 𝑗 1 ≤ 𝑥, 𝑦 ≤ 𝑛 𝑥 ≠ 𝑦

(6-4)

Evaluate

This operator accepts either a TS or a TR (as declared in Equation 6-5) and triggers the

interface member defined in the corresponding object. A TS’s Interface (as illustrated in Thing

Service subsection) provides a way (API call) to trigger the offered service on the hosting thing.

Such an API call is defined in terms of the function’s name, required inputs (data variable

defined by a description, type, and domain), and expected output. The TS is evaluated by an

announcement to the thing that offers the service with the API call, where the API Engine of the

architecture of such a thing (as detailed in Chapter 5) routes the captured API call and performs

the corresponding check on the expected inputs’ types and ranges. It then triggers the

corresponding service. At the same time, a TR’s Interface (as illustrated in the Thing

Relationship subsection) details a way to evaluate the relationship. Such an interface is defined

in terms of the expected inputs (TS or UB, or a data variable defined by a description, type, and

91

domain), the formula that reflects how the inputs are processed, and the expected output.

Evaluating a TR first requires finding a match (through the match operator) for each UB defined

as input to the TR. If there is a match for each declared UB, then – according to the relationship

formula and type – evaluating TR requires the evaluation (Equation 6-5) to each TS defined in

the input and also each TS that replaces a declared UB (as detailed in Equation 6-3). Thus, for a

smart space with n services and m relationships, to evaluate TRi (i is the index of this TR in the

m TRs where 1≤ i ≤ m) with p input TSs (where 1 ≤ p ≤ n) and q input UBs (where 1 ≤ q), the

evaluate operator: 1) applies either the first or the second match methods to find a match for each

of the q UBs from the available n TSs; and 2) triggers a recursive evaluative call for each of the

input p TSs and the q matched UBs, as detailed in the interface’s formula and relationship type.

𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑒 (𝑝𝑟𝑖𝑚),𝑤ℎ𝑒𝑟𝑒 𝑝𝑟𝑖𝑚 ∈ {TS, TR} =

{𝑖𝑛𝑖𝑡𝑖𝑎𝑡𝑒 𝑠𝑒𝑟𝑣𝑖𝑐𝑒 𝐴𝑃𝐼 𝑐𝑎𝑙𝑙 𝑓𝑜𝑟 𝑡ℎ𝑒 𝑜𝑓𝑓𝑒𝑟𝑖𝑛𝑔 𝑡ℎ𝑖𝑛𝑔, 𝑖𝑓 𝑝𝑟𝑖𝑚 𝑖𝑠 𝑇𝑆

( 𝑡𝑟𝑖𝑔𝑔𝑒𝑟 𝑎 𝑀𝑎𝑡𝑐ℎ 𝑓𝑜𝑟 𝑒𝑎𝑐ℎ 𝑖𝑛𝑝𝑢𝑡 𝑈𝐵𝑟𝑒𝑐𝑢𝑟𝑠𝑖𝑣𝑒𝑙𝑦 𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑒 𝑒𝑎𝑐ℎ 𝑖𝑛𝑝𝑢𝑡 𝑇𝑆 𝑎𝑛𝑑 𝑚𝑎𝑡𝑐ℎ𝑒𝑑 𝑈𝐵

) , 𝑖𝑓 𝑝𝑟𝑖𝑚 𝑖𝑠 𝑇𝑅 (6-5)

Types of Relationships and Recipes

The framework so far has introduced TS, TR and Recipe as the primitives of an app with

Filter, Match and Evaluate as the operators used to wire these primitives. In this section, we

introduce the types and formulas of the different relationships and recipes defined in the

framework.

Types of Relationships and Formulizations

A relationship between two or more services is either cooperative (control/controlled-by,

drive/driven-by, support/supported-by, or extend/extended-by) or competitive (contest, interfere,

refine/refined-by, or subsume/subsumed-by) as follows:

Control/Controlled-by. The control relationship evaluates TSb (Equation 6-6) if

evaluating TSa results in a logical true result for condition C. The control condition C, utilized by

92

the relationship establisher, either reflects the successful evaluation of TSa (e.g. Pressure sensor

checks the existence of someone in the room, the Philips hue turns on the light accordingly) or

the numerical output of evaluating TSa is mathematically comparable to an input real or decimal

value. As declared in Equation 6-6, TSa is said to control TSb (TSb is said to be controlled-by

TSa). Control can be extended (Equation 6-7) to either evaluate TSb or TSc if evaluating TSa

results in a logical true or false manner for condition C, respectively. The indices a, b and c refer

to the first, second and third TS respectively in the input set of TSs to the TR’s interface. Control

can be extended to sequentially evaluate a set of services based on the evaluation of condition C.

𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑒 (𝑇𝑆𝑎) 𝐶 → 𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑒 (𝑇𝑆𝑏),𝑤ℎ𝑒𝑟𝑒 𝐶 = {

𝑆𝑢𝑐𝑐𝑒𝑠𝑠𝑓𝑢𝑙 𝑐𝑎𝑙𝑙 𝑓𝑜𝑟 𝑇𝑆𝑎

𝑇𝑆𝑎. 𝑜𝑢𝑡𝑝𝑢𝑡 ∘ 𝑣𝑎𝑙𝑢𝑒, ∘ ∈ {=,≠,<,>} (6-6)

𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑒 (𝑇𝑆𝑎) 𝐶 → 𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑒 (𝑇𝑆𝑏); 𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑒 (𝑇𝑆𝑐) (6-7)

Drive/Driven-by. The drive relationship feeds the output of evaluating TSa (Equation 6-

8) to the input (for the TS’s interface member) required for the evaluation of TSb (e.g. Read the

value of temperature sensor and turn on AC accordingly). As declared in Equation 6-8, TSa is

said to drive TSb (TSb is said to be driven by TSa). The indices a and b refer to the first and

second TSs respectively in the input set of TSs to the TR’s interface. The drive can be extended

(Equation 6-9) for a nested sequence of output-input feeds.

𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑒(𝑇𝑆𝑏. 𝐼𝑛𝑡𝑒𝑟𝑓𝑎𝑐𝑒. 𝐼𝑛𝑝𝑢𝑡( 𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑒 ( 𝑇𝑆𝑎 ))) (6-8)

𝐸𝑣𝑎𝑙𝑢a𝑡𝑒(𝑇𝑆𝑛. 𝐼𝑛𝑡𝑒𝑟𝑓𝑎𝑐𝑒. 𝐼𝑛𝑝𝑢𝑡(… (𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑒(𝑇𝑆𝑎)))) (6-9)

Extend/Extended-by. The extend concatenates the interfaces of TSa and TSb (Equation

6-10) into the interface of a newly created TS (TSextended), for instance, A DVR that records a TV

channel, thereby enriching the functionalities of a smart TV that can display channels. As

declared in Equation 6-10, TSa is said to extend TSb (TSb is said to be extended-by TSa). The

93

indices a and b refer to the first and second TSs respectively in the input set of TSs to the TR’s

interface. The operation of Extend is algorithmically illustrated in Figure 6-4.

𝑇𝑆𝑒𝑥𝑡𝑒𝑛𝑑𝑒𝑑. 𝐼𝑛𝑡𝑒𝑟𝑓𝑎𝑐𝑒(𝑇𝑆𝑎. 𝐼𝑛𝑡𝑒𝑟𝑓𝑎𝑐𝑒, 𝑇𝑆𝑏 . 𝐼𝑛𝑡𝑒𝑟𝑓𝑎𝑐𝑒) (6-10)

Figure 6-4. Algorithmic representation for the Extend relationship.

Support/Supported-by. The support enables the evaluation of TSa (Equation 6-11) to be

the pre-condition for the evaluation of TSb (e.g. the proper display of an indoor TV requires the

window blinds to close; thus the window blinds support the indoor TV). As declared in Equation

6-11, TSa is said to support TSb (TSb is said to be supported-by TSa). The indices a and b refer to

the first and second TSs respectively in the input set of TSs to the TR’s interface.

𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑒(𝑇𝑆𝑏), 𝐼𝑓 𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑒(𝑇𝑆𝑎) 𝑖𝑠 𝑡𝑟𝑢𝑒/𝑠𝑢𝑐𝑐𝑒𝑠𝑠𝑓𝑢𝑙 (6-11)

Contest and Interfere. The contest refers to two or more TSs that provide mutually

exclusive solutions to the same problem (e.g. Garmin as a GPS device, and a smartphone

offering GPS service through Google maps), while Interfere refers to two or more TSs which are

considered inappropriate or insecure to coexist at the same time and space (e.g. Turn off smoke

detector and turn on the oven). Both types follow the same formula (Equation 6-12), where the

The interface of Extend relationship

• Inputs: inputs for TSa and inputs for TSb

• Output: Result_Set, false by default

• Formula

Resulta = Evaluate (TSa)

Resultb = Evaluate (TSb)

If Resulta is false OR Resultb is false then //unsuccessful evaluation

exit

else

add both Resulta and Resultb to Result_Set //successful evaluation of both

end if

94

relationship establisher (e.g., developer, vendor) filters a set of n competitive TSs through a set

of m preferences (Equation 6-1), then evaluates the resulting TS. (In a case where more than one

TS is filtered, the formula selects the first one in the filtered set to evaluate).

𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑒 (𝐹𝑖𝑙𝑡𝑒𝑟𝑝 1, 𝑝 2,… 𝑝 𝑚 (𝑇𝑆1, 𝑇𝑆2, . . . 𝑇𝑆𝑛)) (6-12)

Refine/Refined-by and Subsume/Subsumed-by. The Refine refers to the TSa that offers

more specific functionality compared to TSb (e.g., Wifi triangulation for indoor positioning, and

proximity beacons for indoor positioning), and Subsume refers to TSa that offers functionality

which is included within that offered by TSb (e.g. a stand lamp turns on the light, and the Philips

hue controls the brightness). Both types follow the same formula (Equation 6-13) where an

evaluation call for TSa is triggered if both TSa and TSb are currently offered by Atlas things in

the smart space. The indices a and b refer to the first and second TSs respectively in the input set

of TSs to the TR’s interface.

𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑒 (𝑇𝑆𝑎), 𝑖𝑓 𝐵𝑜𝑡ℎ 𝑇𝑆𝑎 𝑎𝑛𝑑 𝑇𝑆𝑏 𝑎𝑟𝑒 𝑎𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒 (6-13)

Types of Recipes and Formulizations

This section introduces the different types of recipes and the corresponding formulas

defined in the interface member of the recipes.

Linear. The linear type evaluates one or more services and relationships sequentially

(Equation 6-14). The indices a and n refer to the first and last primitives respectively in the input

set to the recipe’s interface. The linear recipe (Equation 6-15) can also accumulate the output

results of evaluating the input primitives using the logical AND, OR and XOR operations.

{𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑒 (𝑝𝑟𝑖𝑚𝑎),… 𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑒(𝑝𝑟𝑖𝑚𝑛)}, 𝑤ℎ𝑒𝑟𝑒 𝑝𝑟𝑖𝑚 ∈ {TS, TR} (6-14)

{𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑒 (𝜙 𝑝𝑟𝑖𝑚𝑎) ⊝ … 𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑒(𝜙 𝑝𝑟𝑖𝑚𝑛)},

𝑤ℎ𝑒𝑟𝑒 𝑝𝑟𝑖𝑚 ∈ {TS, TR}, ⊝ ∈ {∧,∨,⊕}, 𝜙 ∈ {¬,∅} (6-15)

95

Conditional. The conditional type evaluates one or more application primitives (TS, TR)

if the logical result of evaluating the first app primitive (TS, TR) is true/successful (Equation 6-

16). The indices a, b and n refer to the first, second, and last primitives respectively in the input

set to the recipe’s interface.

{𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑒 (𝑝𝑟𝑖𝑚𝑏),… 𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑒(𝑝𝑟𝑖𝑚𝑛)},

𝐼𝑓 𝐸𝑣𝑎𝑙𝑢𝑎𝑡𝑒 (𝑝𝑟𝑖𝑚𝑎) 𝑖𝑠 𝑠𝑢𝑐𝑐𝑒𝑠𝑠𝑓𝑢𝑙 𝑤ℎ𝑒𝑟𝑒 𝑝𝑟𝑖𝑚 ∈ {TS, TR} (6-16)

Atlas Application Tree and Semantic Rules

Figure 6-5 below illustrates the app primitives that build up an IoT app in a top-down tree

fashion and how such primitives are connected through the defined operators (filter, match and

evaluate). The recipes (the high level of the tree) are established by the app developer or inferred

by Atlas RIDE (as detailed in Chapter 7) where each recipe (linear or conditional type) is

composed of one or more TRs. The TRs (the middle layer of the tree) are either established by

the vendors through the IoT-DDLs, established by the developer through the Atlas RIDE

(detailed in Chapter 7), or dynamically inferred by the RIDE from the exchanged knowledge

between the Atlas things. Each TR (cooperative or competitive type) is composed of one or more

TSs. The TSs (the low level of the tree) are established by the vendors through the things’ IoT-

DDLs and are created by the Atlas things from the uploaded IoT-DDLs.

96

Figure 6-5. Atlas IoT application primitives and operator’s tree.

For a uniform way to establish and evaluate the validity of an Atlas IoT applications, we

present the semantic rules (Table 6-1) that describe applications in terms of the services,

relationships, and recipes that formulate their structures. The rules are to: 1) describe the

application in terms of its individual services, relationships, and recipes; 2) ensure the

correctness and compatibility of the application with respect to the current smart space; and 3)

govern the execution. The application is composed of one or more sequential recipes. The recipe

is a sequential set of one or more resources, where the resource can either be a relationship or a

service. A relationship is either a cooperative or competitive connection between two resources

(service or another relationship). Such a hierarchy enables the seamless composition of different

types and complexities of applications ranging from a simple service to a composite relationship

(a relationship that imposes on another relationship).

Ser

vic

e(s)

TS1 TS2 TSn

….Rec

ipes

(s)

TRk

Match Operator

Evaluate Operator

….

Rel

atio

nsh

ip(s

)

Filter Operator

TR1

Match Operator

Evaluate Operator

Filter Operator

TR2

Match Operator

Evaluate Operator

Filter Operator

• Established by vendors

through IoT-DDLs

• Created by things from

uploaded IoT-DDLs

• Established by vendors

through IoT-DDLs

• Created by things from

the uploaded IoT-DDLs

• Inferred by Atlas RIDE

• Established by developers

through Atlas RIDE

• Established by developers

through Atlas RIDE

• Inferred by Atlas RIDERecipe1

Evaluate Operator

Recipe2

Evaluate Operator

Recipem

Evaluate Operator

Atlas IoT App

97

Table 6-1. Atlas IoT application semantic rules

Semantic Rule Description

App = {Recipe}+ Atlas IoT app is a sequential set of one or more Recipes

Resource = Relationship | Service Resource can be either a Service or Relationship

Recipe = {Resource}+

|C→ {Resource}+

|C→ {Resource}+; {Resource}+

Recipe is a sequential set of one or more resources

Execute set of resources for a true evaluation of

condition C

Execute the first resource set if condition C is evaluated

to true or the second set otherwise

Relationship =

Resource Connection Resource

Relationship is a connection between two resources that

indicates how these resources are executed

Connection =

{Control|Support|Extend| Drive}

or{Subsume|Refine|Interfere|Contest}

The cooperative and competitive relationships.

Service = Report

| Action

| Condition

Returns a numerical value

Performs actuation service

Checks the occurrence of a specific event

C = True

| False

| Not C

| A OPR A

| C OPL C

| Evaluate Service Type Condition

Logical True

Logical False

Negation of expression

Apply relational operator on arithmetic expressions

Apply logical operator on logical expressions

The result of evaluation a Service of Type Condition

A = n

| A OPA A

| Evaluate Service Type Condition

| Evaluate Service Type Report

| Evaluate Service Type Action

Holds a numerical value

Applies arithmetic operator on arithmetic expressions

The result of evaluation a Service of Type Condition

The result of evaluation a Service of Type Report

The result of evaluation a Service of Type Action

OPA = + | * | / | -

The arithmetic operations

OPR = < | > | == | !=

The relational operations

OPL = AND | OR | XOR

The logical operations

98

Poles of the Programming Model

The poles of the framework to build an IoT app are the thing’s vendor, the Atlas thing, and

the developer. In this section, the role of each pole is explained in detail.

Vendor

The Vendor utilizes the Atlas IoT-DDL web tool (as explained in Chapter 4) to declare

an IoT-DDL to be uploaded to the thing. Such IoT-DDL reflects the thing’s identity, entities,

services, and relationships. The vendor also utilizes the OMA-DM device management server (as

explained in Chapter 5) to send authorized updates during the lifetime of the Atlas thing through

the device manager module of the Atlas Thing Architecture.

Atlas Thing

The Atlas Thing creates, at runtime, a TS programmable object for each service it offers

and a TR object for each declared relationship. Such runtime objects reside in the Knowledge

Engine of the Atlas Thing Architecture. The thing creates information-based messages (tweets)

describing the newly created TS(s) and TR(s) through the tweeting sublayer of the Atlas Thing

Architecture, then utilizes the interface sublayer of the Atlas Thing Architecture to announce

those tweets to other things in the smart space. At the same time, the thing creates a local graph

in the knowledge engine of the Atlas Thing Architecture with TSs as vertices and TRs as edges.

This graph is updated with the received TSs and TRs from other things, and from the lifetime

updates sent by the thing’s vendor. The graph enables the thing to keep track of the available

services and relationships in the smart space and to route the API calls to the API engine of the

Atlas Thing Architecture for the services hosted by the thing. The API Engine dynamically

creates the services from their description in the IoT-DDL, formulates programmable interfaces

for the services, captures API calls, performs checks on the expected inputs’ types and ranges,

and evaluates the service with respect to the inputs (as detailed in Chapter 5).

99

Developer

The developer utilizes the Atlas RIDE (as detailed in Chapter 7) to: 1) build IoT apps; 2)

sense the currently available primitives and operators; 3) establish TRs and recipes, and build up

an IoT app tree as illustrated in Figure 6-5. The tool captures announced knowledge about TS(s)

and TR(s) from the things. The RIDE, from the exchanged knowledge between the things, can

dynamically infer the existence of new relationships as new programming opportunities for the

developer. The discovered relationships reflect how the current services can be further related to

each other and enrich the programmability of the space for the developer with new service

engagement opportunities.

100

CHAPTER 7

ATLAS RUNTIME-INTERACTIVE DEVELOPMENT ENVIRONMENT (RIDE)

In this chapter, we present the Atlas RIDE – an interactive development environment for

the mobile users to glimpse and program their smart spaces. The RIDE extends the Inter-thing

relationships programming framework (Chapter 6) to build a distributed programming ecosystem

for the newly emerging social IoT paradigm. The RIDE targets the smartphone users with no

programming or hands-on experience to sense their smart spaces, visualize the available services

and the different relationships that tie them, establish their own applications with a few clicks

and receive programming opportunities dynamically. The RIDE: 1) continuously listens to the

things of the smart space for announcements about their services and relationships; 2) infers the

existence of new service-level relationships; 3) enables the developer to establish relationships,

recipes and applications; 4) also enables the developer to set preferences for functionalities,

services and application categories to guide the inference of new application nuggets and

opportunities from the current available services, relationships and recipes, and accepts the

developers’ feedback on inferred applications; and 5) accepts the established and inferred

applications, and generates full mobile applications.

High-level Architecture of the Atlas RIDE

In this section, we start with presenting a high-level architecture for the proposed RIDE

with a detailed description of the functionality of each module, then present the generation of IoT

application and the inference of new relationships and application opportunities. Atlas RIDE, as

illustrated in Figure 7-1, is composed of five modules.

Explorer. The explorer captures multicast tweets from Atlas things in a smart space. The

tweets reveal the thing’s identity and the different services that the thing offers as well as the

different relationships that link such service with others’ services. Thing identity, capabilities,

101

services and relationships are established by the things’ vendors through the IoT-DDL. When the

Atlas thing is powered up, it parses the uploaded IoT-DDL, discovers its onboard and attached

capabilities, and multicast tweets to identify itself.

Repository. The repository keeps a record for each of: 1) the available Atlas things’

services and relationships captured by the Explorer; 2) the different recipes and relationships

established by the developers through the Development Interface; 3) the inferred recipes and

relationships suggested by the Inference Engine; and 4) the developers’ preferences for certain

application categories and functionalities in terms of descriptive keywords to guide the inference

of new application opportunities.

Development Interface. The development interface is the backbone and the interface

through which the developer can: 1) visualize the available services, relationships and recipes

from the Repository; 2) establish new relationships, recipes and applications; 3) state preferences

on functionalities to the Repository; 4) interact with the Inference Engine through feedback on

the inferred programming opportunities; and 5) forward the established applications to the

Application Engine for the generation of IoT mobile Apps.

Inference Engine. The inference engine discovers the existence of new application

nuggets (relationships and recipes) and engagement opportunities for new IoT apps. The engine

depends on the developers’ preferences, available resources (services, relationships and recipes),

previously established applications, and the developers’ feedback, to shape future suggestions.

Application Engine. The application engine accepts established applications from the

developer through the Development Interface and inferred applications by the Inference Engine

and generates executable Atlas IoT mobile apps. The dynamically generated app can run

independently from the RIDE and communicate back with the things for service API calls.

102

Figure 7-1. High-level architecture of the Atlas IoT RIDE.

For the rest of this chapter, we refer to the: 1) Developer as the user of the RIDE who can

establish applications to the smart space; 2) Service to be the thing service announced by an

Atlas thing in the smart space and captured by the RIDE through multicast tweets; 3) Established

Relationship/Recipe to be the relationship/recipe that the developer developed using the RIDE

from the available services; 4) Received Relationship to be the relationship defined by the

vendor in the IoT-DDL of an Atlas thing and captured by the Explorer module through the

multicast tweets; and 5) Generated Applications to be the mobile apps that are either established

by the developer through the Development Interface or inferred by the Inference Engine, and

generated by the Application Engine.

Development Interface

Application

Engine

RepositoryRecommender

Engine

Explorer

• Applications

• Results

• Recommendations

• Feedback

• Established Primitives

• User PreferencesPrimitives

Atl

as I

DE

Developers

• App Development

• Preferences

• Recommendations

• Programming Opportunities

Unicast

InteractionsMulticast

Tweets

Atlas Things

….App 1

Directory of developed and generated

Atlas IoT apps

App 2 App n

103

Application Engine

As illustrated in Figure 7-1, the application developer, through the Development

Interface, utilizes the available primitives (services, relationships and recipes) from the

Repository to establish IoT applications, as detailed in the next subsections. The Inference

Engine, which is also detailed in the next subsection, discovers the existence of new application

nuggets (relationships and recipes) and engagement opportunities for new IoT apps. The

application (either established or inferred) as a set of services, relationships and recipes is

governed by a set of semantic rules, as detailed in Table 6-1. These rules are: 1) to describe the

application in terms of individual services, relationships and recipes; 2) to ensure the correctness

of the described application; and 3) to govern the application execution. The application is

composed of one or more recipes that are executed sequentially. The recipe is a sequential set of

one or more resources, where the resource can either be a relationship or a service. A relationship

is either a cooperative or competitive connection between two resources (service or another

relationship). These semantic rules enable the composition of different types and complexities of

IoT applications, ranging from simple service to a composite relationship (a relationship that

imposes upon another relationship).

Application Manifest

RIDE’s Application Engine accepts the application (either established by the developer

through the Development Interface, or inferred by the Inference Engine – as detailed in the next

subsection), checks the validity and correctness through the application semantic rules (Table 6-

1) and then generates an executable Atlas IoT mobile app. For the Application Engine to

generate a mobile app for an application under development in RIDE (either established or

inferred), the engine first transforms the structural representation of the application into a

descriptive XML-based manifest, named the application manifest.

104

Figure 7-2. Structure of the application manifest.

The application manifest (Figure 7-2) details the identity of the application (e.g., name,

description, developer) and the different components (services, relationships and recipes) that

shape such application. The manifest includes the identification information for: 1) each service

(e.g., name, vendor, API, description keywords for the functionality); 2) each relationship

included within the application and ties to these services (e.g., type, category, vendor,

description); and 3) each recipe that ties these services and relationships (e.g., type, name,

developer, description) to create a segment of the applications. (An Atlas IoT application is a set

of one or more recipes executed sequentially.)

105

On-Cloud Application Generation

The Application Engine utilizes an on-cloud service to generate a fully integrated mobile

app from the application manifest. The engine passes the XML-based application manifest to the

on-cloud service and receives the executable application to install and then run on demand on the

developer’s smartphone. The generated mobile app, as illustrated in Figure 7-3, is composed of:

1. User interface for the user to run the app, control inputs and view details.

2. An execution engine that checks the availability of the application’s services in the current

smart space and regulates the execution of the application (as detailed in the application

manifest and governed by the semantic rules –detailed in Table 6-1) through the execution of

the inner recipes, relationships and services, as detailed in Chapter 6.

3. A gateway to interact back with Atlas things in the smart space for service calls (API calls).

The application is executed as a set of services’ calls (API calls) to the Atlas things that offer

the corresponding services defined in the application.

Figure 7-3. Structure of the generated IoT mobile application.

<App><----->

……

</----></App>

Manifest

User Interface

Gateway

App

Unicast

Interactions

Atlas Things

Atl

as I

oT

Ap

p

Execution Engine

106

Inference Engine

The Inference Engine of the RIDE utilizes applications established by the developer

through the Development Interface along with the available services, relationships and recipes

from the Repository to discover the existence of new programming opportunities. Such

opportunities in terms of new relationships reflect how the smart space services can be further

related to each other, and in terms of new recipes reflect how the available services and

relationships can be united for new IoT applications and scenarios. The developers’ preferences

for certain functionalities and application categories as well as the developers’ feedback on the

inferred programming opportunities shape the operation of the engine for future suggestions.

Figure 7-4. The Inference Engine of the Atlas RIDE.

The engine (illustrated in Figure 7-4) is composed of two modules: The Relationship

Inference module and Recipe Inference module for the dynamic infer of new relationships and

Transitivity

Operator

Composition

Operator

Exchange

Operator

Relatio

nsh

ip

Inferen

ce Mo

du

leR

ecipe In

ference M

od

ule

Inferred

Relationships

Established/Received

Relationships

Generated

Recipes

User

Preferences

Relationship

Repository

Recipe Generator

Service

Repository

Closeness OperatorRecipe

Repository

User Feedback

Inferred

Recipes

Selected Relationships

Established/Received

Recipes

Received

Services

107

recipes respectively. In this section, the details of the Relationship Inference Module are

presented first and then the operation of the Recipe Inference Module is covered, including the

capability of the developer to state preferences, the generation of new programming

opportunities, and the semantical measure of the closeness between the inferred recipes and

developer’s preferences and their previously established applications. We also provide an

algorithmic representation of the module, for a precise and clear definition of the operation of the

Recipe Inference Module.

Relationship Inference Engine

The engine infers the presence of new relationships, as detailed in Chapter 6. These

include both cooperative (control, support, drive, extend) and competitive (subsume, refine,

interfere, contest) relationships between the services in the Repository. The discovered

relationships reflect how the current services can be further related to each other and enrich the

programmability space to the developer with new service engagement opportunities. As detailed

below, the module utilizes the Transitivity, Exchange, and Composition properties to discover

new relationship instances from the previously established relationships by the developer and the

received relationships from Atlas things. The newly discovered relationships are added to the

RIDE Repository along with the established and received relationships to expand the search

space for relationships. It is worth mentioning that these properties (composition, transitivity and

exchange) are logical properties that deal with the available relationships and services as black

boxes to suggest the probabilistic existence of new relationships. The current version of these

properties doesn’t consider the linguistic meaning nor the semantic structure that define these

service and relationships.

Transitivity Property. If Service A is in a cooperative relationship (types: Control,

Support, Drive, or Extend) with Service B, and Service B is in a cooperative relationship of the

108

same type with Service C, then the existence of a cooperative relationship of the same type is

inferred between Service A and Service C (Figure 7-5). The same property works for

competitive relationships (types: Contest, Interfere, Subsume, or Refine). Taking the following

examples to illustrate the usage of this property for both cooperative and competitive

relationships respectively: 1) If an alarm clock A controls a coffee maker B and the coffee maker

B controls a toaster oven C, then the alarm clock A can control the toaster oven C; and 2) If a

Garmin GPS A contests a smart phone offering of a GPS service B and the GPS service B

contests a TomTom GPS C, then the Garmin GPS A can contest the TomTom GPS C.

Figure 7-5. Transitivity property.

Exchange Property. If Service A is in a cooperative relationship (types: Control,

Support, Drive or Extend) with Service B and Service B is in a competitive relationship (types:

Contest, Interfere, Subsume or Refine) with Service C, then the existence of a cooperative

relationship of the same type is inferred between Service A and Service C (Figure 7-6). The

following example illustrates the usage of this property: If an alarm clock A controls a Bosch

Service

A

Service

C

Cooperative /

Competitive

Relationship

Service

B

Cooperative /

Competitive

RelationshipEstablished or Received Relationship

Inferred Relationship

Service

A

Service

C

Service

B

Cooperative /

Competitive

Relationship

Cooperative /

Competitive

Relationship

Cooperative /

Competitive

Relationship

109

coffee maker B and the Bosch coffee maker B has a contest relationship with a Keurig coffee

maker C, then the alarm clock A can control the Keurig coffee maker C.

Figure 7-6. Exchange property.

Composition Property. If Service A is in a cooperative relationship (type: Extend) with

Service B and Service B is in a cooperative relationship (types: Control, Support, or Drive) with

Service C, then the existence of a cooperative relationship of the same type is inferred between

the Service C and the resulting extension of Service A and Service B. The same property works

for competitive relationships (types: Contest, Interfere, Subsume or Refine) between Service B

and Service C, where the existence of a competitive relationship of the same type is inferred

between the Service C and the resulting extension of Service A and Service B (Figure 7-7). The

following example illustrates the use of this property: a DVR that records TV channels

enriches/extends the functionalities of a smart TV to be merged together as one extended service.

If the Window blinds support the smart TV for better movie-watching experience, then the

window blinds also support the extended service of DVR along with the smart TV service.

Service

A

Service

C

Cooperative

Relationship

Competitive

Relationship

Service

B

Cooperative

Relationship

Service

A

Service

C

Cooperative

Relationship

Competitive

Relationship

Service

B

Established or Received Relationship

Inferred Relationship

110

Figure 7-7. Composition property.

Recipe Inference Engine

The recipe inference engine dynamically infers new recipes to the developer based on: 1)

available services along with the established, received, and inferred relationships from the

Repository; 2) previously established recipes by the developer through the Development

Interface; and 3) the developers’ preferences for certain functionalities and application categories

(detailed below). The module generates a set of possible recipes that are semantically close to the

developers’ preferences and the previously established recipes. The module accepts the

developers’ feedback on the generated recipes. The developer can accept the recipe, reject the

recipe or accept after editing the recipe (e.g., change order of services and relationships that form

a certain recipe, add a service, remove a relationship).

Upon receiving positive feedback (accept the recipe or accept after editing the recipe), the

generated recipe (as illustrated in Figure 7-4) is added to the Repository to expand the search

space of recipes and is passed to the Application Engine to generate an IoT mobile app. Upon

receiving negative feedback (reject the recipe), the module starts pruning other generated recipes

that are semantically close to the rejected recipe by the developer.

Service

A

Service

C

Cooperative

Relationship

Cooperative

Relationship

Service

B

Established or Received Relationship

Inferred Relationship

Service

A

Service

CCooperative

Relationship

Cooperative

Relationship

Service

B

111

In this section, we first present how a developer can define preferences for certain

functionalities and application categories. Then the procedure for generating new recipes is

presented which measures the semantic closeness between the inferred recipes and the

developer’s preferences along with their previously established applications.

User application preferences

User preferences are considered a wish list of future applications and functionalities of

interest that may be present in the smart space to the developer. Authors in [101][102] present

different taxonomies for mobile and pervasive applications, focusing on the abstraction of

application characteristics to guide the development of new apps, and to capture patterns of user

interaction. These taxonomies organize such characteristics into dimensions such as usage

patterns related to time and location [98][99][100], or the interaction between the user and the

service provider (the vendor) [100]. Such taxonomies can be further extended in the context of

IoT to include the user’s ability to program the smart space through their description of services

and functionalities of interest. Such preferences guide the operation of the Recipe Inference

module to generate new recipes that follow the user’s desires. In this section, we utilize these

taxonomies to propose five dimensions we believe cover the main characteristics of an IoT

application and its recipes. Through these dimensions, which can be further updated and

extended with new characteristics and properties, a developer can describe a preference for

behaviors of interest. The proposed dimensions are described as follows:

1. Temporal dimension: the application is either scheduled to run within certain time slots (e.g.,

before the arrival of the user, after leaving the home, while sleeping, when the user wakes

up) or directly run when triggered by the user.

2. Location dimension: the IoT application either requires the location information of the user

to capture surrounding services or the functionality of the application is related to specific

locations (e.g., living room, kitchen).

112

3. User Keywords dimension: keywords defined by the developer to describe specific

functionalities of interest.

4. User Vendors dimension: the developer’s preferred set of vendors who may offer services of

interest to the smart space.

5. App Category dimension: applications for a personal smart space can be taxonomized

according to the different activities the user can perform.

In this section, we also propose a simple taxonomy that spans the App Category

dimension. This covers a range of services or activities that a user may program into a smart

space recipe. The proposed taxonomy can be further updated and optimized with new activities

the user can engage in. Each category, as illustrated in Figure 7-8, is described with a name and a

set of keywords that describe possible functionalities and services that may exist under the

category. Such keywords can be extracted from domain-related ontologies or determined by the

development environment.

Recipe generator

As mentioned previously, the Recipe generator module considers the currently available

services as well as the previously established, received and inferred relationships to build a set of

new recipes. A recipe, as detailed in Chapter 6, is a set of relationships and services that forms a

segment of the IoT application, where an application is a sequential set of recipes. For the Recipe

generator to generate an initial set of possible recipes for a smart space with S services and R

relationships (where 0 ≤ S and 0 ≤ R), the generator first selects the services S’ that match the

application categories of the developers’ preferences (where 0 ≤ S’ ≤ S), where the metadata of

the service contains the application category and a set of keywords that describes the

functionalities offered by such service. From the selected services, the generator considers the

relationships R’ that tie and engage these services with other services in the smart space (where 0

≤ R’ ≤ R). From the selected subset of services and relationships, the generator module considers

113

the different combinations of these services and relationships as possible recipes R’ (where R’ =

2S’ + R’). A newly generated recipe is considered a valid recipe if: 1) the services in the recipe are

not competing (contest, interfere, subsume, or refine) together, and 2) there is no duplication

between the services considered for the recipe and those defined in the relationships considered

for the recipe.

Closeness operator

The operator measures how a generated recipe is semantically close to a previously

established recipe from the developer along with the developer’s preferences. The operator, from

the repository that stores a meta-data record for each received service and received, established

and inferred relationships, represents such services and relationships in both the generated and

the established recipe as follows:

1. Each service is represented by a tuple that holds keywords which describe the functionality,

the application category (as illustrated in Figure 7-8), and the vendor.

2. Each relationship is represented by a tuple that holds the category (cooperative, competitive),

type and description.

3. Each user preference is represented by a tuple that holds a set of keywords defined by the

user for specific functionalities, the category of the application and the corresponding set of

keywords that define such categories, along with a set of vendors considered by the user.

The operator calculates the semantic similarity between the corresponding elements of

these tuples, between the services and relationships with the generated recipe and the established

recipe along with user preference. A weighted average is calculated out of the accumulated

semantic metric, reflecting how similar the different services and relationships described in the

generated recipe are to the previously established recipe and the desired preferences. The

semantically close generated recipes are then suggested to the user for feedback, where the

accepted recipes are added as input to the module to expand the search space of recipes. Upon

114

receiving negative feedback, the inference module starts pruning other generated recipes that are

semantically similar to the rejected recipe.

Figure 7-8. Proposed taxonomy of the possible human activities in a smart space.

To illustrate the operation of the recipe inference module, consider the following example

with three services and two relationships. Service 1 triggers an alarm clock with an app category

of Time Alarms; Service 2 prepares coffee with an app category of Eating; and service 3

prepares toast with an app category Eating. Relationship R1 is a control relationship between

Service 1 and Service 2, and relationship R2 is a control relationship between Service 1 and

Service 3. The developer establishes an application that utilizes the first relationship to prepare

coffee in the morning and a stated preference to the app categories for Time alarms and Eating.

Ap

pli

cati

on

Cat

egor

y

Ambience (e.g., Thermostate Control, Air purifier, AC)

Automation (e.g., Power Save, Human presence detection)

Wellness (e.g., sleep quality, Physical activity)

Lighting (e.g., Standlamp, Window Blinds)

Health (e.g., Medical Kit, Emergency, Oximeter, Blood pressure sensor)

Personal Assistance

(e.g., Weather Monitor, Calendar, Reminders, Shopping list)

Safety (e.g., Door Lock, Garage, Survellance Camera, Baby Monitor)

Entertainment (e.g., Media, Music, Games, Movie)

Environment Monitor

(e.g., Water Quality, Smoke Detection, Room Temperature)

Time Alarms (e.g., Relax, Quiet)

Hygeine (e.g., Bathing, Toileting)

Eating (e.g., Oven, Toaster, Microwave, Fridge)

Cleaning (e.g., Vacuum, Washing Machines, Dishwasher)

Office (e.g., Reading, Studying, Working)

115

The recipe generator generates the possible subsets as possible applications ({R1}, {R2}, {R1,

R2}). The closeness operator then measures how close each of the generated recipes is to

previously established recipes and preferences. The operator finds that recipe {R1, R2} (prepare

coffee and breakfast toast by the morning alarm clock) is semantically closest to the preferences

and established recipes.

Seeking a clear illustration of the operation of the proposed Atlas RIDE, we provide the

transition state diagram in Figure 7-9 to summarize the operation of the different modules. For a

precise and clear definition of the operation of the Recipe Inference Module, in Chapter 9, we

provide an algorithmic representation of the module in terms of generating recipes, the operation

of Closeness Operator and pruning generated recipes based on the developers’ feedback.

Figure 7-9. State transition diagram for the operation of Atlas RIDE.

Update

Repository

Explore the

smart space

Inferred

ApplicationDevelop / Establish

Application

Generate Atlas App in the

IoT App Directory

Initialize IDE modules,

Load saved primitives

and user preferences

• User Preferences

• Received Service

• Received/Established/Inferred

Relation/Recipe

Positive

Feedback

Update

Inference

Engine

Negative

Feedback

Power on Atlas IDE

116

CHAPTER 8

EXAMPLE OF IOT APPLICATIONS

In this chapter, three scenarios are presented that engage a number of things to illustrate

how the proposed approaches (IoT-DDL, Atlas Thing Architecture, Inter-thing relationship

programming framework, and Atlas RIDE) work and engage to build real domain-related

applications for the social IoT.

Application 1: Prepare Morning Coffee

This scenario (as illustrated in Figure 8-1) utilizes two things in a smart space: 1)

Raspberry Pi model B sensor platform running Raspbian OS; and 2) Beaglebone Black sensor

platform running Angstrom OS. The Beaglebone Black thing is connected to an on/off circuit

with a coffee maker as an attached hardware entity, while the Raspberry Pi thing offers an alarm

clock service as a built-in software entity.

Figure 8-1. Prepare morning coffee.

IoT-DDL

IoT

DDL

Identity Tweets

APIs Tweets

Application

{ Prepare

Coffee by

7:00 AM }

OMA and Atlas

Objects

Set Alarm 7:00

Alarm 7:00

Beaglebone

Atlas Thing

Architecture

Raspberry-PIInteractions

Atlas Thing

Architecture

OMA and Atlas

Objects

Thing A Thing B

117

The IoT-DDL configuration files are developed and uploaded on both things. These files

indicate the identity of each thing, including their inner entities, resources, and services. The

Beaglebone Black thing, as illustrated in Figure 8-2, offers two services, one to start brewing

coffee and staying on for a specific time duration, and the other for switching off the coffee

maker with a specific service type as action. The descriptive keywords list the offered

functionality and service. The Raspberry Pi thing, on the other hand, offers one service to set the

alarm clock entity to trigger on a specific hour.

When both things are powered, the Atlas Thing Architecture in both things starts parsing

the different sections and subsections of the uploaded IoT-DDL. Each thing now identifies itself,

discovers the different services and functions it can offer to the smart space, and starts generating

service bundles (as detailed in the next IoT scenario) and the corresponding access interfaces

(APIs). Each thing starts looking for thing mates by broadcasting its identity tweet, entity

identity tweet, and generated API tweet.

The prototype assumes that an IoT application in the Beaglebone Black thing requires

turning on the coffee maker when the alarm triggers. Both things register themselves as OMA

clients that can connect to the OMA server and register their OMA standard objects and Atlas

objects. On the server side, an authorized user can browse different connected clients, view a list

of registered objects, and update their attributes. Figure 8-3 shows the relationship section

established by the vendor for the coffee maker entity to describe a contest relationship with

another coffee maker that offers the function “prepare coffee service.” As illustrated in Figure 8-

3, the UB service describes the other service from Hamilton as the vendor, with any type

(condition, action or report), and coffee and prepare as the descriptive keywords. The acceptable

match with an offered service is of value 80. The relationship between the offered service (the

118

first service defined in the coffee maker entity) and the declared UB is of type contest and

established by Bosch. The relationship accepts the service and the UB as the two inputs.

Figure 8-2. IoT-DDL snippet for the Beaglebone black Atlas thing with coffee maker entity.

Beaglebone Black Atlas thing with coffee maker entity <Atlas_IoT-DDL>

<Atlas_Thing> <Descriptive_Metadata>

<Name> Beaglebone Black </Name> <Short_Description> Sensor Platform </Short_Description>

<ATID> AT128 </ATID> <SSID> SS326 </SSID>

…. </Descriptive_Metadata>

…. <Resources>

<Network_Properties>

<Module> Wifi </Module>

<Type> External USB </Type>

….

</Network_Properties>

….

</Resources>

</Atlas_Thing>

<Entity_1>

<Descriptive_Metadata> < Name> Coffee Maker </ Name>

< Category> Hardware </ Category> < Type> Attached </ Type>

< Description> Prepare Coffee </ Description> ….

</Descriptive_Metadata> < Services>

<Service_1>

< Description> Turn on for duration </ Description>

< InputTypes> Integer </ InputTypes>

< InputDescription> Duration in Minutes </ InputDescription>

< InputRange> [0:59] </ InputRange>

< OutputTypes> Integer </ OutputTypes>

<Type> Action</Type>

<Keywords> Coffee, Prepare, Morning </Keywords>

…. </Service_1>

<Service_2> < Description> Turn Off </ Description>

< OutputTypes> Integer </ OutputTypes>

<Type> Action </Type>

….

</Service_2>

< /Services>

</ Entity_1>

</Atlas_IoT-DDL>

119

Figure 8-3. IoT-DDL snippet for contest relationship between two coffee maker services.

Application 2: Someone is Watching Movie, Tilt the Window Blinds Down

The second scenario is to tilt down the slats of horizontal window blinds when someone

is watching a movie in the living room. The scenario utilizes three things: 1) home stand lamp

that checks if the light is on (service TSa) and toggles the light (service TSb); 2) motor-controlled

window blinds that tilts the blinds down (service TSc); and 3) HDMI monitor that plays a movie

on the screen (service TSd). This scenario focuses on showing how the Inter-thing programming

framework primitives are instantiated and wired to build a meaningful IoT app.

The vendor of the HDMI monitor thing, in the IoT-DDL, declares a support relationship

with UB that controls window blinds. When the things are powered, each thing now identifies

itself, discovers the services it offers from the uploaded IoT-DDL configuration file, and then

generates and advertises the TS(s). Additionally, the HDMI monitor thing generates the TRa that

reflects the support relationship with an UB as illustrated in Figure 8-4.

Competitive relationship between coffee prepare services

<Thing_Relationship>

<Relation_1>

<Establisher_Name> Bosch </Establisher_Name>

<Type> Contest </Type>

<Unbounded_Services>

<UB_1>

<Vendor> Hamilton </Vendor>

<Type> * </Type>

<Keywords> Coffee, Prepare </Keywords>

<Match_Required> 80 </Match_Required>

</UB_1>

</Unbounded_Services>

<Relation_Name> Coffee makers </Relation_Name>

<Inputs> Service_1, UB_1 </Inputs>

<OutputTypes> Integer </OutputTypes>

</Relation_1>

</Thing_Relationship>

120

Figure 8-4. The TRa primitive for the support relationship between watching a movie and tilting

window blinds down.

The HDMI monitor thing then starts matching the UB with TSs received from things,

which is then replaced with a reference to TSc. The developer, through the IDE, starts capturing

announced knowledge about TSs and TRs, and establishes a new conditional recipe (Ra). Ra, as

detailed in Figure 8-5, toggles the light and evaluates the TRa relationship if the light in the room

is on.

Figure 8-5. The Ra recipe to toggle the light of the living room and display the movie on the

screen when someone exists in the room.

The developed IoT app tree (Figure 8-6) is of one recipe, and the RIDE parses the tree in

a top-down approach (as detailed in Chapter 7). Ra is evaluated by evaluating TSa and evaluates

the second part of the formula if the TSa is successfully evaluated. The second part of the

formula is to evaluate TSb and TRa sequentially. The TRa is evaluated by evaluating the TR’s

Support relationship between watching a movie and tilting window

blinds Attributes:

UB1:

Interface:

(Name, Vendor 1), (Type, support)

(Vendor, *), (Type, action), (Keywords, ‘blinds, tilt’), (Match, 20)

Formula: {Evaluate (TSd)}, If Evaluate (UB1)

Inputs: TS: {TSd} and UB: {UB1}

Output: true (successful execution) or false

Recipe to toggle the light and display the movie, when someone occupies

the room

Attributes:

Interface:

(Name, Developer1), (Type, Conditional)

Formula: {Evaluate (TSb), Evaluate (TRa)}, If Evaluate (TSa)

Inputs: TS: {TSa, TSb, TSc and TSd} and TR: {TRa}

Output: true (successful execution) or false

121

formula, where TSd is evaluated if evaluating TSc is successful. Evaluating the service takes

place by sending tweets to the offering thing. The thing then utilizes the API engine of the Atlas

Thing Architecture to evaluate the call and return the result back to the RIDE.

Figure 8-6. Atlas IoT application to tilt window blinds when someone is watching a movie.

Application 3: Smart Lock and Thermostat for Home Automation

The third scenario illustrates the capability of the Atlas Thing Architecture to generate

service bundles from the IoT description. The presented application is a home automation

scenario where the smart door locker senses that no one is present in the home. The scenario

utilizes three things: 1) a smart lock that locks the home door if no one is home (service TS1); 2)

a thermostat that adjusts room temperature (service TS2); and 3) motor-powered window blinds

that tilt the blinds down (service TS3).

Ra

TRaType

Support

{Evaluate ( TSb ), Evaluate ( TRa )},

If Evaluate ( TSa )

{Evaluate ( TSd )},

Precond Evaluate ( TSc )

Check if the

light is on

Toggle the

light

Tilt the

blinds down

Play a movie

on the screen

122

The vendor of each thing, in the corresponding IoT-DDL, declares the services offered by

the things. As an example, take a thermostat hardware entity for the second Atlas thing. The IoT-

DDL’s descriptive metadata and services sub-sections, as illustrated in Figure 8-7, enable the

thing to create a TS that represents each of the offered services. The descriptive metadata sub-

section (line 2 to 9) represents the identification attributes for the offering thing. The services

subsection (line 11 to 32) represents the parameters and attributes for the two services offered by

the thermostat (reading and setting room temperature) in terms of the inputs (types, descriptions,

ranges and units) and outputs. Each service is further described in terms of a set of descriptive

keywords (line 19 and line 30) and the service type (line 18 and line 29).

Consider an expanded IoT-DDL for the thermostat example with a thing relationship sub-

section to describe a contest relationship with another Atlas thing, a thermostat from Nest. As

illustrated in Figure 8-8 below, the other thermostat is described as a UB (lines 7-10) to be from

Nest as “Vendor,” with any type (condition, action or report), and ambience and AC as the

“Keywords.” The defined UB is to be compared for a match with the TSs offered by other Atlas

things in the smart space. The acceptable match (to replace the UB with TS) is of value 80. The

relationship is of type contest (line 4) and is established by Honeywell (line 3). The relationship

accepts the service offered by the thing (defined in Figure 8-8) and the declared UB as the two

inputs (line 14).

Consider a detailed thermostat service in which the user passes the desired temperature

value, as shown in Figure 8-9. The service takes a floating-point value, issues the command over

an SPI interface, and returns a success value on another GPIO pin. From the created TS object

from the IoT-DDL, the API Engine generates the bundle for this service in terms of executable

code along with the appropriate resources. The bundle interface is synthesized using the given

123

names and types, and the code is generated by mapping the IoT-DDL tags in the formula to

executable code provided by the host interface layer of the Atlas thing architecture. The result is

a valid C function performing the equivalent operations, as seen in Figure 8-10.

Figure 8-7. IoT-DDL snippet for the thermostat Atlas thing along with the two offered services.

IoT-DDL for a thermostat hardware entity along with the offered

services

1. <Entity_1>

2. <Descriptive_Metadata>

3. <Name>Thermostat</Name>

4. <Vendor>Honeywell</Vendor>

5. <ATID>AtlasThing128</ATID>

6. <SSID>SmartSpace326012</SSID>

7. <Description>Manage House Temperature</Description>

8. …

9. </Descriptive_Metadata>

10. <Resource_Service>

11. <Service_1>

12. <Name>Read Temperature</Name>

13. <OutputType>Real</OutputType>

14. <OutputName>Temperature Value</OutputName>

15. <OutputRange>[0:100]</OutputRange>

16. <OutputUnit>C</OutputUnit>

17. <InputType>NULL</InputType>

18. <Type>Report</Type>

19. <Keywords>read, ambiance, AC</Keywords>

20. …

21. </Service_1>

22. <Service_2>

23. <Name>Set Temperature</Name>

24. <InputType>Real</InputType>

25. <InputName>Temperature Value</InputName>

26. <InputRange>[0:100]</InputRange>

27. <InputUnit>C</InputUnit>

28. <OutputType>NULL</OutputType>

29. <Type>Action</Type>

30. <Keywords>adjust, ambiance, AC</Keywords>

31. …

32. </Service_2>

33. </Resource_Service>

34. </Entity_1>

124

Figure 8-8. Contest type relationship between services offered by different thermostats.

Figure 8-9. IoT-DDL snippet for an offered service by the thermostat thing.

Contest relationship between services offered by thermostats

1. <Thing_Relationship>

2. <Relation_1>

3. <Establisher_Name>Honeywell</Establisher_Name>

4. <Type>Contest</Type>

5. <Unbounded_Services>

6. <UB_1>

7. <Vendor>Nest</Vendor>

8. <Type>* </Type>

9. <Keywords>ambience, AC</Keywords>

10. <Match_Required>80</Match_Required>

11. </UB_1>

12. </Unbounded_Services>

13. <Name>Adjust Room temperature</Name>

14. <Inputs>Service_1, UB_1</Input>

15. ….

16. </Relation_1>

17. </Thing_Relationship>

An IoT-DDL snippet representing a service offered by a thermostat thing

1. <Service>

2. <Description>Set Temperature</Description>

3. <Name>SetTemperature</Name>

4. <InputType>Float</InputType>

5. <InputName>TempCelsius</InputName>

6. <OutputType>Integer</OutputType>

7. <OutputName>Success</OutputName>

8. <Formula>

9. <SPIWrite channel=1>TempCelsius/100 +0.5</SPIWrite>

10. <DigitalRead pin=12>Success</DigitalRead>

11. </Formula>

12. <Type>Action</Type>

13. <Keywords>Control, Temperature, Thermostat</Keywords>

14. </Service>

125

Figure 8-10. The generated C code equivalent for the thermostat service.

The software bundles, once created, can be loaded (installed) and unloaded (uninstalled)

according to the dynamic features of the API calls and the established applications to provide the

required services to other things in the smart space. Bundles are loaded as dynamic libraries, and

can be utilized on any device running the Atlas thing architecture. The self-contained nature of

bundles allows for easy transfer of services, enabling things which cannot generate their own

bundles to still obtain dynamic functionality. Once loaded, a bundle exists independently

alongside previously created bundles on the thing. These may then be searched for and

referenced from the framework by its interface. At this point, the bundle itself is transparent to

the rest of the Atlas Thing Architecture and can be called in the same manner as any normal

functionality by the framework and other things.

The vendor of the smart lock thing, in the IoT-DDL, declares a control relationship

(Relationship TR1) with UB that adjusts the room temperature. The vendor of the thermostat, in

the IoT-DDL, declares a support relationship (Relationship TR2) with a UB that adjusts the

window blinds as a post-condition for adjusting the thermostat. When the things are powered on,

each thing identifies itself, discovers the services it offers, and generates and advertises its TS(s).

Each thing, through the API engine and the microservices, creates a bundle with actual code for

the service along with the appropriate programmable interface (API). The smart lock thing

The generated C code equivalent for the thermostat service

1. int SetTemperature(float TempCelsius) {

2. int Success;

3. float data = TempCelsius / 100.f + 0.5f;

4. spi_write(1, (byte*)&data, sizeof(float));

5. Success = digital_read(12);

6. return Success;

7. }

126

generates a TR1, that reflects the control relationship with a UB for a thermostat service. The

thermostat thing also generates a TR2 that reflects the support relationship with a UB that adjusts

the window blinds as a precondition for adjusting the thermostat. The smart lock thing then starts

matching its UB with TSs received from other Atlas things, which is then replaced with a

reference to TS2. The thermostat thing also matches its UB with the TSs for the window blinds

control functionality, which is then replaced with a reference to TS3.

The developer, through the RIDE, starts capturing announced knowledge about the TSs

and TRs, and establishes a conditional recipe R1. R1 evaluates TR2 if the evaluation of TR1 is

successful (no one exists in the room and the thermostat is adjusted). The developed IoT app tree

(Figure 8-11) consists of one recipe, and the RIDE parses the tree in a top-down approach. R1

requires evaluating TR1 first, and if a successful evaluation took place, the recipe then evaluates

TR2, where a relationship is evaluated through the interface’s formula with respect to the

interface’ inputs and expected output. If evaluating TS1 is successful for TR1, TS2 is then

evaluated. TS2 should be true as a precondition to evaluate TS3 for TR2. Evaluating the service

takes place by sending a request to the offering thing; that thing then utilizes the API engine of

the Atlas Thing Architecture to evaluate the API call and return the result back to the RIDE.

127

Figure 8-11. Home automation Atlas IoT scenario.

Recipe R1:Conditional

{Evaluate ( TR2 )}

If Evaluate ( TR1 ) is true

{Evaluate ( TS3 )},

Precond Evaluate ( TS2 )

Service TS1: Lock

door if no one at home

Service TS2: Adjust

room temperature

Service TS3: Tilt

the blinds down

Relation TR1:Type Control

Relation TR2:Type Support

{Evaluate ( TS2 )},

If Evaluate ( TS1 ) is true

128

CHAPTER 9

IMPLEMENTATION AND EVALUATION

In this chapter, we present the implementation details along with a benchmark study in

terms of time latency, memory footprint, and energy consumption to demonstrate the validity

and feasibly of the presented framework as a lightweight solution on real IoT platforms.

Supported IoT Things

The IoT things used in the implementation of the proposed Atlas Thing Architecture, as

well as its evaluation, are Raspberry Pi Model B, Qualcomm Dragon Board 410C and

Beaglebone black sensor platforms with the specifications listed in Table 9-1 below.

Table 9-1. IoT things specifications.

Specifications Raspberry Pi Model B Dragon Board 410C Beaglebone

Black

OS Raspbian Debian Angstrom

Processor 900-MHz Quad-Core

ARM Cortex A7

1.2-GHz Quad-Core

ARM Cortex A53

Snapdragon

1-GHz Sitara

AM3359 ARM

Cortex A8

Network Module Raspberry Pi Wi-Fi

adapter 2.4-GHz CanaKit

Integrated Digital core

2.4

Edimax USB

Wi-Fi 2.4 GHz

RAM 1GB 1GB 512MB

Flash Storage 4GB SD card 8GB eMMC 4GB eMMC

At the same time, we targeted Android-based smartphones in the implementation of the

proposed Atlas RIDE. The evaluation targets Nexus 9 (Android version 6.0.1, Battery type

Lithium Polymer, Battery capacity 6700 mAh, Voltage 3.7 V, RAM 2 GB) to benchmark the

feasibility of the proposed RIDE on a real smartphone.

Implementation of Atlas Thing Architecture and Atlas RIDE

In this section, we describe the implementation details of parts of the Atlas Thing

Architecture that address the different aspects of the IoT-DDL and thing requirements as part of

129

the IoT ecosystem (as discussed in Chapter 4). The Atlas Thing Architecture takes advantage of:

1) the Open Mobile Alliance Lightweight M2M (OMA-LwM2M) [36][37] which is a

lightweight device management standard that targets low-power and constrained devices with the

low-overhead REST data model and point-to-point communication in a client-server fashion in

the Device management module of the DDL sublayer; 2) IP Smart Object (IPSO) [39][40] that

provides common design patterns and semantic interoperability across IoT devices that supports

LwM2M for a more reusable design to composite modular objects; 3) CoAP [66][67],

client/server IoT communication protocol that provides a request/report paradigm model over

UDP and interoperates with HTTP and the RESTful Web through simple proxies in the interface

sublayer; 4) MQTT [72][73], one of the most widely-used IoT communications protocols that

uses a publish/subscribe architecture on top of the TCP/IP protocol in the interface sublayer; and

5) CPP Microservices framework [74][75] in the API Engine of the DDL sublayer to facilitate

the dynamic service generation, service registry and service discovery.

Provisioning and Management

The first requirement for a thing to be part of the IoT ecosystem is that it must be

seamlessly integrated into the ecosystem, so it can be managed and configured with minimal

human intervention. In this section, we target this essential requirement using two widely used

standards for device management and object modeling: OMA-LwM2M and IPSO, respectively.

Liblwm2m is an open source implementation for OMA-LwM2M developed by the

Wakaama project in Eclipse [76][77]. The Atlas Thing Architecture extends Liblwm2m to allow

device management [78][79] not only for OMA standard objects but also for the Atlas objects

that represent the different aspects of IoT-DDL (as detailed in Chapter 5). Atlas objects are based

on the object resource data representation model proposed by OMA-LwM2M and utilize the

IPSO idea of composite objects for higher modular object design.

130

Supporting Homogenous Communication

The Atlas Thing Architecture exploits widely used communication protocols for IoT and

constrained environments: MQTT and CoAP. The interface sublayer of the Atlas Thing

Architecture adopts the open-source C/C++ implementation of MQTT developed by the Paho

project in Eclipse [65]. The implementation allows Atlas things to connect to an MQTT broker,

subscribe, and publish with respect to a predefined set of topics. As a proof of concept, the Atlas

Thing Architecture utilizes a connection with the cloud-based MQTT broker HiveMQ dashboard

[80] to publish and subscribe to the different topics (as detailed in Chapter 5).

The interface and communication engine of the Atlas Thing Architecture also adopts the

open-source C++ implementation of CoAP developed by the Noisy Atom [81]. This

implementation allows Atlas things to tweet and interact with respect to a predefined set of

resources (as detailed in Chapter 5). The Atlas Thing Architecture uses CoAP protocol support

for multicasting, which allows the thing to broadcast tweets for all listening things. We extend

the imported library with Unix multicast sockets to enable the CoAP multicast feature.

Service Bundles

The Atlas Thing Architecture adopts the Apache licensed C++ Micro Services project

[74] for the dynamic generation of bundles that represents the services offered by the thing to the

smart space. The C++ Micro Services project could allow for the creation of service-based

applications based on the dynamic module system of OSGi [75]. Each microservice, called a

bundle, is a specially-packaged shared library object that runs in its own context within the

microservices framework. The state of these bundles can be managed dynamically during the

lifetime of the Atlas thing. The Atlas Thing Architecture uses C++ Micro Services to allow

loading, running, and uninstalling its service bundles throughout execution, and to access the

running bundles’ functionalities through a generic interface.

131

Communication Interoperability

The framework adopts the open source C++ implementation of CoAP developed by

Noisy Atom [81], C/C++ implementations of MQTT developed by the Paho Eclipse project [65],

and HTTP REST developed by the C Curl library [82]. The framework also utilizes a connection

with the cloud-based MQTT broker HiveMQ dashboard [80] as the default broker defined by

SSB in the Atlas thing IoT-DDL.

The network manager subsection of the Atlas thing section of IoT-DDL specifications, as

illustrated in Figure 9-1 below, describes the network connection capabilities in terms of the

mounted network module (e.g., Wi-Fi or Bluetooth) and network access information (lines 3–5).

The network manager lists required attributes and properties of the communication protocol that

the thing speaks (lines 6–10). The network manager section also includes the configuration of the

SSB broker for the thing to initially connect to, as well as Atlas topics (lines 11–17) for the thing

to subscribe to, either directly (for the MQTT-speaking things) or through the Atlas protocol

translator (for the non-MQTT-speaking things). The thing attachment section of the IoT-DDL

specifications includes the protocol translator for CoAP- and REST-speaking things. The

protocol translator subsection includes different attributes and parameters to configure the

translator (in case of an on-thing translator) or to create a communication channel with the

translator (in case of an off-thing translator. See Figure 9-2.)

Seeking a precise and clear definition of the presented heterogeneous communication

framework (the Atlas IoT topic hierarchy, the Atlas IoT protocol translator, and the extended

interface sublayer of the Atlas thing architecture), we provide an algorithmic representation of

the framework in Figure 9-3 below. The supporting algorithm Initialize, as illustrated in Figure

9-4, configures the different modules of the interface sublayer of the Atlas Thing Architecture

according to the uploaded IoT-DDL.

132

Figure 9-1. The network manager subsection for a CoAP-speaking Atlas thing.

Figure 9-2. An off-thing Atlas protocol translator in the thing attachment section in the IoT-DDL

configuration file.

IoT-DDL snippet for a CoAP-speaking Atlas thing.

1. <Administrative_Metadata>

2. <Network_Manager>

3. <Module>Wifi</Module>

4. <Type>External USB</Type>

5. <Network_Name>ATLAS</Network_Name>

6. <Transport_Protocol>TCP</Transport_Protocol>

7. <Communication_Protocol>CoAP </Communication_Protocol>

8. <Mulicast_Address>266.1.1.1</Multicast_Address>

9. <Listen_Port>5755</Listen_Port>

10. <Interaction_Port>4322</Interaction_Port>

11. <SSB>broker.hivemq.com:1883</SSB>

12. <Topic_Root>Atlas</Topic_Root>

13. <Network_MQTTClient>/Network /MQTT_Client </Network_MQTTClient>

14. <Network_PrivateBroker>/Network /Private_Broker </Network_PrivateBroker>

15. <Multicast_ThingIdentity>/Multicast/Thing_Identity </Multicast_ThingIdentity>

16. <Multicast_API>/Multicast/Thing_API </Multicast_API>

17. <Unicast>/Unicast/Interaction</Unicast>

18. ….

19. </Network_Manager>

20. ….

21. </Administrative_Metadata>

Off-thing Atlas protocol translator

1. <Thing_Attachment>

2. <Protocol_Translator>

3. <Type>off-thing</Type>

4. <Description>Atlas protocol translator</Description>

5. <Translator_URL>192.168.0.4</Translator_URL>

6. <Translator_PORT>57577</Translator_PORT>

7. <Transport_Protocol>TCP</Transport_Protocol>

8. <Availability>Enabled</Availability>

9. .... 10. </Protocol_Translator>

11. .... 12. </Thing_Attachment>

133

Figure 9-3. Algorithmic representation of the communication framework.

Figure 9-4. The method “Initialize” for the algorithmic representation of the framework.

The supporting algorithm Event_Handler, as illustrated in Figure 9-5, initializes

communication channels and creates event call-back functions that are triggered on specific

events (e.g., a packet is received, the broker connection is down, or a MQTT client is in the

smart space), as specified below. The event listener is a call-back mechanism used and

Atlas thing communication framework

Algorithm:

*SSID //Smart space id, default empty

*ATID //Atlas thing id, default empty

*MQTT_ Exist //MQTT client exist, default false

*Current_Broker //Broker access info, default empty

*Native_Language //Communication protocol, default empty

*Topic_Map //record for each topic, default empty

*Translator_settings //Atlas translator info, default empty

1. Powering Atlas thing

2. Call Initialize method

3. Call Event_Handler method

4. while true do

5. Call Interaction_Handler method

6. end while

Method Initialize: Initialize interface sub-layer, communication channels

and event listeners

1. Read SSID, ATID, Current_Broker, Native_Language and Translator_settings parameters

from the uploaded IoT-DDL

2. If the Atlas thing provides private broker service then

3. Connect to the Current_Broker

4. Publish broker access information to Private_Broker

5. Disconnect from the Current_Broker

6. Change Current_Broker to the new broker

7. end if

134

developed by the communication standards (MQTT, CoAP, and HTTP REST) to track specific

events. The supporting algorithm Interaction_Handler, as illustrated in Figure 9-6, builds

multicast and unicast interactions as well as interactions’ responses to other things.

Figure 9-5. The method “Event Handler” for the algorithmic representation of the framework.

Method Event_Handler: Initialize communication channels and listeners

for events.

1. If Native_Language is MQTT then

2. Connect to the Current_Broker

3. Set MQTT_Exist to true

4. Publish true to MQTT_Client topic

5. Subscribe to Atlas topic hierarchy

6. else if Native_Language is CoAP or HTTP-REST then

7. Connect to translator using Translator_settings

8. Subscribe to Private_Broker and MQTT_Client topics

9. Set an event listener (MQTT_Client topic update)

10. Set MQTT_Exist to true

11. Subscribe to multicast topics and the unicast topic

12. end if

13. //the above if-else statements handle both MQTT and non MQTT speakers differently

14. //the next events’ call back functions handle both similarly

15. Set an event listener (Packet received)

16. Call Interaction_Handler method

17. Set an event listener (Private_Broker topic update)

18. Disconnect from the current broker

19. Change Current_Broker to the new broker

20. Call Event_Handler method

21. Set an event listener (Broker is down)

22. Set Current_Broker to the default SSB broker of IoT-DDL

23. Call Event_Handler method

135

Figure 9-6. The method “Interaction Handler” for the algorithmic representation of the

framework.

Method Interaction_Handler: Creates outgoing interactions and processes incoming

interactions.

1. If new interaction then //Creating outgoing interaction

2. Build up the interaction

3. If Multicast interaction then

4. If MQTT_Exist then

5. If Native_Language is MQTT then

6. Publish interaction to the corresponding multicast topic

7. Else if Native_Language is CoAP or HTTP then

8. Publish interaction through translator to the corresponding multicast topic

9. end if

10. else if Native_Language is CoAP then

11. CoAP UDP-multicast the interaction to the corresponding multicast topic

12. end if

13. else // Unicast interaction

14. If Native_Language is CoAP & peer is CoAP then

15. CoAP UDP-unicast the interaction to the corresponding unicast topic

16. else if Native_Language is HTTP & peer is HTTP then

17. HTTP-REST TCP-unicast the interaction to the corresponding unicast topic

18. else if Native_Language is CoAP & peer is non CoAP then

19. Post the interaction through the Atlas protocol translator to the unicast topic

20. else if Native_Language is HTTP & peer is non HTTP-REST then

21. Post the interaction through the Atlas protocol translator to the unicast topic

22. else //MQTT speaking thing

23. Publish interaction to the unicast topic

24. end if

25. end if

26. else //Processing an incoming interaction

27. Parse request

28. If (Multicast interaction) then

29. Update the Topic_Map

30. else //unicast interaction received on Interaction_(ATID)

31. Build up the corresponding response interaction

32. Jump to line 14

33. end if

34. end if

136

Secure Interactions

As mentioned earlier, the third essential requirements for things to be part of the

ecosystem is the capability to interact with thing mates in a secure way that enables both the

authorization and authentication aspects of communication. The Atlas Thing Architecture

exploits the lightweight symmetric key [87] encryption of AES to create secure dynamic

communication channels between things and thing mates.

AES is a widely used symmetric lightweight block cipher security protocol [87][88][89].

For AES, the default block size is 128 bits or 16 bytes. A mode of operation describes how to

repeatedly apply a cipher's single block operation to securely transform amounts of data larger

than a block. Each mode requires an initialization vector (IV) to ensure distinct ciphertexts are

produced, even when the same plain text is independently encrypted multiple times with the

same key. In the cipher block-chaining (CBC) mode of operation, each block of plaintext is

XORed with the previous ciphertext block before it is encrypted. This way, each ciphertext block

depends on all plaintext blocks processed up to that point. CBC is the most commonly used

mode of operation.

The Atlas Thing Architecture utilizes AES with CBC as the mode of operation using the

Crypto++ library [90]. The security engine of the tweeting sublayer assumes a master secret key

and IV, and encryption/decryption methods are securely stored within the device secure elements

of the OS services. These security elements are unique to Atlas things in smart spaces, where the

space owner can generate a new master key and IV to be securely deployed to the things through

the device management server. The security engine generates dynamic session keys from the

symmetric predefined master key. Atlas thing A and Atlas thing B can establish a session key as

follows:

137

1. Thing A generates a random number (R1) and encrypts a message holding its own ID and R1

using the master key.

2. Thing B decrypts the message using the predefined master key, saves R1, and generates a

new random number (R2).

3. Thing B encrypts a message holding its own ID and R2 using the master key.

4. Thing A and thing B each encrypt a concatenated value of R1 and R2 using the master key

and generate a session key.

Recipe Inference and Closeness Operator

For a precise and clear definition of the operation of the Recipe Inference Module

(Chapter 7), we provide an algorithmic representation of the module in terms of the generating

recipes, the operation of the Closeness Operator and pruning generated recipes based on the

developers’ feedback. The module operates on the services, relationships, and recipes available

in the Repository. Upon receiving a new service or new relationship (received from the Atlas

thing, established by the developer, or inferred by the Relationship Inference Module), the

Recipe Inference Module then generates possible recipes, applies the closeness operator between

the generated recipes and the previously established recipes, suggests the new recipes to the

developer and ask for the developer’s feedback, as illustrated in Figure 9-7. At the same time, the

supporting algorithm Generate Recipes, as illustrated in Figure 9-8, first selects services with

application categories that match the developers’ preferences. The generator also considers the

relationships that engage the selected services with other services in the repository. When a

relationship is considered, the services defined within such relationships are implicitly

considered. From the selected services and relationships, the generator considers a subset as a

possible recipe as detailed in Chapter 7.

138

Figure 9-7. Algorithmic representation of the recipe inference.

Figure 9-8. The method “Generate Recipes” for the algorithmic representation of the Inference

module.

Recipe Inference Algorithm

*Primitives_List //Available Services, Relationships and Recipes in the Repository

*Generated_List //List of Generated Recipes, default empty

1. Set an event listener (Received Service or Received/Established/Inferred Relationship)

2. Call Generate_Recipes method on Generated_List

3. For each generated recipe X in Generated_List and established recipe Y in Primitives_List

4. Call Closeness_Operator method on recipe X and recipe Y

5. If Positive output from the operator, then

6. Ask the developer’s feedback on the recipe X

7. If Positive feedback, then Add the recipe X to the Primitives_List end if

8. else

9. Call Prune_Recipes method on recipe X and recipes in Generated_List

10. end if

11. end for

Method Generate_Recipes

*Candidate_Primitives //Primitives to consider in generating recipes, default empty

*Preferences //Available developers preferences in the Repository

1. For each Preference Z in Preferences and Service X in Primitives_List do

2. If Service X App category matches the App Category of preference Z, then

3. For each Relationship Y in Primitives_List that involves Service X do

4. Add Relationship Y to Candidate_Primitives

5. end for

6. If Service X is not competing with other services in Candidate_Primitives and is not

duplicated with services defined in relationships add to Candidate_Primitives then

7. Add Service X to candidate_Primitives

8. end if

9. end for

10. For each Subset S of Candidate_Primitives do

11. Add S to Generated_List

12. end for

139

The supporting algorithm Closeness Operator, as illustrated in Figure 9-9, calculates the

semantic similarity between a generated recipe and an established recipe along with the

developers’ preferences. The operator measures how a generated recipe is semantically close to a

previously established recipe from the developer along with the developer’s preferences. The

operator utilizes a Radial Basis Function (RBF) network trained on the English Open Word List

(EOWL), while the categories for each word from the Extracting DIstributionally-related words

using CO-occurrences (DISCO) semantics were calculated [83][84]. The operator, from the

repository that stores a meta-data record for each received service and received, established and

inferred relationships, represents such services and relationships in both the generated and the

established recipe as follows: 1) Each service is represented by a tuple that holds keywords that

describes the functionality, the application category and the vendor; 2) Each relationship is

represented by a tuple that holds the category (cooperative, competitive), type and description;

and 3) Each user preference is represented by a tuple that holds a set of keywords defined by the

user for specific functionalities, the category of the application and the corresponding set of

keywords that define such a category, and a set of vendors considered by the user.

The operator calculates the semantic similarity between the corresponding elements of

these tuples, between the services and relationships, the generated recipe and the established

recipe, along with the user preference. A weighted average is calculated out of the accumulated

semantic metric, reflecting how similar the different services and relationships described in the

generated recipe is semantically close to the previously established recipe and the desired

preferences. The semantically close generated recipes are then suggested to the user for

feedback, and the accepted recipes are added as input to the module to expand the search space

140

of recipes. Upon receiving negative feedback, the inference module starts pruning other

generated recipes that are semantically like the rejected recipe, as illustrated in Figure 9-10.

Figure 9-9. The method ‘Closeness operator’ for the algorithmic representation of the Inference

module.

Method Closeness_Operator: Accepts a generated Recipe (Recipe1) and an established Recipe (Recipe2)

*R_Similarity = 0 //Semantic similarity between Recipe1 and Recipe2, takes value between 0 and 1

*P_Similarity = 0 //Semantic similarity between Recipe1 and user preferences, takes value between 0 and 1

*O_Similarity = 0 //Overall Similarity (Recipe1, Recipe2 and user preferences), takes value between 0 and 1

*N_Established //Number of previously established recipes

*N_Preferences //Number of established user preferences

1. for each Service X in Recipe1 do

2. Service X metadata tuple: [Description Keywords, App Category, Vendor]

3. for each Service Y in Recipe2 do

4. Service Y metadata tuple: [Description Keywords, App Category, Vendor]

5. Apply the semantic similarity measure on the two tuples, Service X and Y

6. Retain the MAX similarity measure so far between services in Recipe2 and Service X

7. end for

8. Accumulate R_Similarity with the retained MAX similarity measure

9. for each Preference Z in UserPreference do

10. Preference Z metadata tuple is: [User Keywords, App Category and Keywords, User Vendors]

11. Apply the semantic similarity measure on the two tuples, Service X and Preference Z

12. Retain the MAX similarity measure so far between preferences in UserPreference and Service X

13. end for

14. Accumulate P_Similarity with the retained MAX similarity measure

15. end for

16. for each Relationship X in Recipe1 do

17. Relationship X metadata tuple: [Type, Category, Description]

18. for each Relationship Y in Recipe2 do

19. Relationship Y metadata tuple: [Type, Category, Description]

20. Apply the semantic similarity measure on the two tuple, Relationship X and Y

21. Retain the MAX similarity measure so far between relationships in Recipe2 and Relationship X

22. end for

23. Accumulate R_Similarity with the retained MAX similarity measure

24. end for

25. R_Similarity = R_Similarity / (Number of Services and Relationships in Recipe1)

26. P_Similarity = P_Similarity / (Number of Services of Recipe1)

27. O_Similarity = (N_Established x R_Similarity + N_Preferences x P_Similarity) / (N_Established +

N_Preferences)

28. If Overall_Similarity > System_defined_bound then return positive value

29. else return negative value

30. end if

141

Figure 9-10. The method ‘Prune Recipes’ for the algorithmic representation of the Inference

module.

Evaluating Atlas Thing Architecture

In this section, we provide a benchmarking study to measure the performance of the Atlas

Thing Architecture in terms of various time latencies and energy consumption rates of the

different components and aspects of the architecture. The study, which is developed and

conducted on the heterogeneous IoT things illustrated in Table 9-1, aims to show the feasibility

of deploying the architecture on real platforms. The aspects benchmarked are the thing’s

capability to generate tweets, to encrypt and decrypt action-based interactions, to be configured

and managed, and to interact using widely accepted communication protocols. For a unified

measurement, we uploaded the same IoT-DDL configuration file (the coffee machine entity of

Chapter 8) to the three things. The uploaded IoT-DDL shows that the thing contains an attached

Method Prune_Recipes: Accepts a Recipe (R1) and an array of Recipes, and removes

Recipe (R2) from the array, if R2 is semantically like R1

*R_Similarity = 0 //Semantic similarity between two Recipes, takes value between 0 and 1

1. For each Service X in R1 do

2. Service X metadata tuple: [Description Keywords, App Category, Vendor]

3. for each Service Y in R2 do

4. Service Y metadata tuple: [Description Keywords, App Category, Vendor]

5. Apply the semantic similarity measure on the two tuples, Service X and Y

6. Retain the MAX similarity measure so far between services in R2 and Service X

7. end for

8. Accumulate R_Similarity with the retained MAX similarity measure

9. End for

10. For each Relationship X in R1 do

11. Relationship X metadata tuple: [Type, Category, Description]

12. for each Relationship Y in R2 do

13. Relationship Y metadata tuple: [Type, Category, Description]

14. Apply the semantic similarity measure on the two tuple, Relationship X and Y

15. Retain the MAX similarity measure so far between relationships in R2 and Relationship X

16. end for

17. Accumulate R_Similarity with the retained MAX similarity measure

18. end for

19. R_Similarity = R_Similarity / (Number of Services and Relationships of R1)

20. If R_Similarity > System_defined_bound then Remove R2 from Generated_List end if

142

coffee maker as a hardware entity that provides two services (turn on for a certain duration and

turn off). The code footprint of the IoT-DDL in addition to the current version of the Atlas Thing

Architecture that imports the OMA-LwM2M standard and AES protocol and supports both

CoAP and MQTT communication standards is approximately 13 megabytes. The code footprint

– the actual machine instructions that reside in the flash memory – shows the light weight of the

proposed framework to fit constrained devices. Such a small code footprint also reflects that the

actual running code does not occupy too much RAM memory to execute.

Time is measured using the Unix-Chrono library for a high-resolution clock cast to

microseconds. Energy consumption is measured using a PowerJive USB-based device that

calculates voltage and capacity [85]. To avoid data outliers, the time measurement of a single

operation is averaged over five measurements. The energy consumption of a single operation is

the average value obtained from running the operation a large number of times in a 10-minute

period. The energy consumption of the processes running in the background of the thing’s OS is

also calculated and is subtracted from the calculated energy consumption of the operation.

First, we provide a benchmarking study that focuses on the functionalities of both

tweeting and DDL sublayers of the Atlas thing architecture, where we measure – in terms of the

time performance and energy consumed (Table 9-2) – the Atlas thing’s capabilities to generate

tweets and to encrypt and decrypt action-based ad-hoc interactions. In the second subsection, we

provide a set of experiments to benchmark both time performance (Figure 9-11) and energy

consumption (Table 9-3) of the different device management capabilities supported by the Atlas

Thing Architecture. The device management capabilities include the ability of the thing to

generate the different Atlas objects, connect to the OMA server and register the objects. Second,

we provide a set of experiments to benchmark both time performance and energy consumption to

143

adopt the widely-accepted IoT communication protocols MQTT (Figure 9-12 and Table 9-4) and

CoAP (Figure 9-13 and Table 9-5). The communication capabilities include the different

functionalities required by the thing to send tweets and listen to tweets from thing mates in the

smart space. Finally, analysis and discussion are provided on the benchmarking study for the

different functionalities and capabilities of the Atlas Thing Architecture required by the thing to

engage in a wide range of interactions and interconnections with other things in the smart space

during the thing’s lifetime.

Tweet Generation and Secure Interactions

The first set of measurements focuses on the functionalities of both tweeting and DDL

sublayers of the Atlas thing architecture. These functionalities exist in terms of the thing’s

capability to generate tweets and to encrypt and decrypt action-based interactions. The generated

tweets are about thing identity (64 bytes), thing entity (64 bytes), and the generated API for each

of the two services (60 bytes each). The size of the generated tweets and APIs depends on the

developed IoT-DDL for the Atlas thing. However, we limited the sizes to 64 and 60 bytes for

unified measurements of time and energy on the different sensor platforms. The secure action-

based interaction (API call forwarded by the thing or received from a thing mate) applies the

AES-CBC mode of operation. AES uses a key and IV, each at 16 bytes, to encrypt and decrypt a

60-byte interaction. Table 9-2 shows the measurements of both time (microseconds) and energy

consumption (watt-seconds) on the different hardware platforms.

OMA Device Management and Communication Protocols

The second set of experiments focuses on the Atlas Thing Architecture’s management

and communication functionalities. These functionalities are in terms of OMA device

management aspects as well as the different communication protocols supported by the Atlas

Thing Architecture.

144

After IoT-DDL is uploaded to the thing, the thing starts generating Atlas objects for the

corresponding IoT-DDL sections. The device manager module communicates with the IoT-DDL

manager module to access information about the OMA management server (e.g., server IP

address and access parameters). The Atlas thing then registers itself as an OMA client at the

server, where the registration process requires the thing to register a tree of its programmed

objects (both Atlas objects and standard OMA objects) on the server side. For the sake of

simplicity, we limit Atlas object generation to the descriptive metadata of the thing, the entity,

and the attachments. Figure 9-11 compares the three sensor platform things we used in terms of

the time required to create Atlas objects on the one hand, and connecting to the OMA server on

the local network and registering the objects' tree, on the other hand. Table 9-3 illustrates the

energy consumption rate of these functionalities in terms of the consumed watts per second on

the different sensor platforms.

Table 9-2. Benchmark time (in microseconds) and energy consumption (in watt seconds).

Interaction

Encryption

Interaction

Decryption

Tweet

Generation

Raspberry Pi Model B Time 2152 947 128484

Energy 7.4e-5 7.8e-5 0.014

Dragon Board 410C Time 1438 916 26159

Energy 4.5e-5 5e-5 0.03

Beaglebone Black Time 3277 1414 54298

Energy 0.000114 0.000116 0.0506

Table 9-3. Energy consumption (in watt seconds) measurements for OMA device manager

functionalities.

Generated Atlas objects Connect to OMA server, then register objects

Raspberry Pi 0.0032 0.0157

Dragon Board 0.00073 0.003845

Beaglebone Black 0.00147 0.010613

145

Figure 9-11. Time comparison for device manager functionalities.

Furthermore, the Atlas Thing Architecture supports the widely accepted IoT

communication protocol, MQTT, and utilizes a connection with the cloud-based MQTT broker

HiveMQ dashboard to publish and subscribe to the different topics. Figure 9-12 compares the

three sensor platforms in terms of the time (in microseconds) required to connect to the MQTT

broker, publish a 64-byte tweet, subscribe to a topic, and then get a 64-byte tweet from a thing

mate. Table 9-4 illustrates the energy consumption in terms of the consumed watts per second of

the different supported MQTT functionalities on the different sensor platforms. Figure 9-13

compares the three sensor platforms in terms of the time (in microseconds) required to create a

CoAP server for the thing and wait for a tweet from a thing mate from one side. Then the time to

create a client side that connects to the CoAP server of a thing mate is evaluated, which sends a

64-byte tweet from the other side. Table 9-5 illustrates the energy consumption in terms of the

consumed watts per second of the different functionalities on the different sensor platforms. It

0 40000 80000

Raspberry PI

Dragon Board

Beaglebone Black

Create Atlas Objects

Connect to OMA-Server

and Register Objects

Time (Microseconds)

146

should be noted that this set of experiments depends mainly on the network connection and

network module used.

Figure 9-12. Time comparison for the different aspects of MQTT protocols.

Figure 9-13. Time comparison for the different aspects of CoAP protocols.

0 3000000 6000000

Raspberry PI

Dragon Board

Beaglebone Black

Connect to MQTT

broker

Publish Tweet

Subscribe and Get

Tweet

Time (Microseconds)

0 300000 600000

Raspberry PI

Dragon Board

Beaglebone Black

Create Server and Wait

for Tweet

Connect to CoAP-Server

and Send Tweet

Time (Microseconds)

147

Table 9-4. Energy consumption (in watt seconds) measurements for the different aspects of

MQTT protocol.

Open TCP connection

with MQTT broker

Publish single

tweet (64-bytes)

Subscribe and receive

single tweet (64-bytes)

Raspberry Pi 0.222 0.301 0.561

Dragon Board 0.251 0.108 0.2729

Beaglebone Black 0.464 0.112 0.1098

Table 9-5. Energy consumption (in watt seconds) measurements for the different aspects of

CoAP protocol.

CoAP server listens and receives

single tweet (64-bytes)

CoAP client connects to server and

sends single tweet (64-bytes)

Raspberry Pi 0.020 0.007

Dragon Board 0.000633 0.003267

Beaglebone Black 0.00287 0.00634

Analysis of the Benchmarking Study

We analyze the results of our benchmarking study in terms of time performance and

energy consumption. We start first with the energy analysis. Understanding an Atlas thing duty

cycle, which is based on the Atlas Thing Architecture, helps in analyzing the measured energy

data. As Figure 9-14 illustrates, an Atlas thing goes through an initialization phase, followed by

one or more Atlas thing duty cycles until thing termination (e.g., battery capacity).

The initialization phase starts with powering up the Atlas thing until it is ready to engage

with its thing mates and the device management server. In this phase, the Atlas thing initializes

the architecture and verifies that the IoT-DDL is uploaded. The Atlas thing generates Atlas

objects, registers itself to the OMA server specified in the IoT-DDL, and then generates tweets

and APIs for the offered services. Directly after the initialization phase, the Atlas thing starts

engaging with thing mates through tweets and actionable interactions through the Atlas thing

duty cycle. The duty cycle starts running a concurrent (threaded) server and client processes to

receive and send interactions, respectively. Receipt of a management command triggers updates

148

of Atlas and OMA objects, as well as tweets and APIs, while receipt of an interaction requires

decrypting the interaction, and mapping them, then executing the corresponding API.

Figure 9-14. Atlas thing initialization phase and duty cycle.

We can calculate battery lifetime in terms of hours to run an Atlas thing continuously

using Equation 9-1 as follows:

𝐵𝑎𝑡𝑡𝑒𝑟𝑦 𝑙𝑖𝑓𝑒𝑡𝑖𝑚𝑒 ≅ 𝑇𝑖𝑚𝑒 𝑜𝑓 𝐷𝑢𝑡𝑦 𝐶𝑦𝑐𝑙𝑒 × (𝐵𝑎𝑡𝑡𝑒𝑟𝑦 𝐶𝑎𝑝𝑎𝑐𝑖𝑡𝑦× 𝐵𝑎𝑡𝑡𝑒𝑟𝑦 𝑣𝑜𝑙𝑡𝑎𝑔𝑒

𝐸𝑛𝑒𝑟𝑔𝑦 𝑐𝑜𝑛𝑠𝑢𝑚𝑒𝑑 𝑝𝑒𝑟 𝐷𝑢𝑡𝑦 𝐶𝑦𝑐𝑙𝑒) (9-1)

where battery lifetime is calculated in hours, battery capacity is in milliamp hours (mAh), and

battery volt is the battery’s initial voltage. The main assumption is that the battery is capable of

maintaining voltage level with time to operate the thing. The duty cycle includes the Atlas thing

duty cycle in addition to the background running processes of the thing’s underlying OS. As an

149

example, Rayovac 4AA alkaline batteries with six volts and 2400 mAh capacity can run

(according to Equation 9-1) a Beaglebone Atlas thing for 28 hours, a Dragon Board Atlas thing

for 12 hours, and a Raspberry Pi Atlas thing for 7.5 hours. Such large differences are due to the

processes running in the background of the thing’s OS and the high capabilities of the Dragon

Board and the Raspberry Pi (e.g., keyboard, mouse) compared to Beaglebone Black. To

demonstrate the accuracy of the proposed equation for battery lifetime, Rayovac 4AA batteries

were able to run Raspberry Pi (which requires a minimum of 2000 mAh and five volts to operate

with full peripherals) for approximately six hours. The difference between the expected and the

real value for the battery lifetime is due to the drop of battery voltage below five volts. Such a

drop forces the Raspberry Pi to shut down connected peripherals (e.g., the Wi-Fi module).

However, most of the real life examples of things that exist in smart spaces either have their own

continuous source of power (e.g., smart home appliances) or efficient power management

modules (e.g., smartphones).

Time performance is discussed next. The differences in the measured time for the

features and functionalities of the Atlas Thing Architecture depends on the specifications of each

platform as mentioned in Table 9-1. For the first set of measurements, the time to complete the

operation mainly depends on the clock frequency of the processor as well as the available RAM

to keep track of different internal operations and results. Dragon Board 410C with 1GB of ARM

and 1.2GHz quad-core performs faster compared to the other platforms on the same set of

operations. For the second set of measurements, the time to complete the operation mainly

depends on the network connectivity and the current traffic as well as the properties of the

different Wi-Fi modules mounted on each platform. It is worth noting that the Dragon Board

150

410C with an integrated 2.4GHz Wi-Fi module on board performs better compared to the other

platforms that use external USB Wi-Fi modules.

Evaluating Atlas Communication Interoperability

In this section, we provide a benchmarking study to measure the memory footprint, time

latency, and energy consumption of the different Atlas communication framework aspects to

enable communication interoperability.

Benchmarking Code Footprint and Energy Consumption

To characterize our proposed framework in terms of concrete metrics, we measured its

various code footprints and the energy cost of all its basic operations. We measured the code

footprint of the different features of the proposed Atlas communication framework. The code

footprint depicted in Table 9-6, in kilobytes, represents the compressed version of the code files

and libraries of the proposed framework components and features.

Table 9-6. Code footprint for the different features of the communication framework.

Feature Code footprint (in kilobytes)

Atlas thing architecture

MQTT client library

85

525

CoAP library 76

REST library 12

On-thing Atlas protocol translator 540

Off-thing Atlas protocol translator 565

Ponte [91] is an Eclipse IoT project that offers uniform open APIs to let developers create

applications supporting CoAP, MQTT, and HTTP REST communication protocols through an

independent module for each protocol. The Ponte gateway can reside in a server or edge where

clients with different communication protocols can communicate. Ponte provides a centralized

solution for interoperability, where the smart space resources reside in the cloud and can be

151

accessed from different clients. Data collected from the three modules is stored in the SQL or

NoSQL database; therefore, no matter which protocol clients utilize for communication, they can

access the same resources. Our communication framework loaded with IoT-DDL, in addition to

the specific lightweight communication library (MQTT, CoAP or HTTP-REST) is evidently

small in size, designed to fit many of the available IoT platforms. Our framework footprint also

compares favorably when compared to existing related work. In fact, the Atlas Thing

Architecture with a CoAP library and an on-thing translator (which is about 700 KB – the

highest footprint among all features in our framework) records a slightly smaller footprint when

compared to the 710 KB of the Eclipse Ponte framework in addition to the CoAP client library

for communication.

To benchmark energy consumption characteristics of the homogenous basic

communication functionalities of our framework (where things that speak similar languages can

interact), we measured the energy consumed under CoAP, HTTP and MQTT protocols on the

two different IoT platforms described in Table 9-1. Basic functionalities, as depicted in Table 9-

7, Table 9-8 and Table 9-9, enable the thing to:

1. Announce their presence (64 bytes) and own APIs (64 bytes) to the Atlas multicast topics,

through publishing to the broker (in case of MQTT speaking thing), UDP GET on a multicast

IP address (in case of CoAP speaking thing) or TCP POST on the thing mate’s IP address (in

case of HTTP-REST speaking thing). It should be noted that MQTT speaking things affect a

multicast through the broker, whereas the CoAP standard protocol is equipped with UDP

multicast feature in which the homogenous CoAP-speaking things can join the same

multicast group to receive such announcements. However, HTTP-REST utilizes TCP for

communication that does not enable a multicast feature. Thus, an HTTP-REST speaking

thing can only utilize a unicast POST on other peers’ IP addresses.

2. Interact with a thing mate in a peer-to-peer fashion (e.g., API call) on the Atlas unicast topic

through publishing, UDP GET unicasted on the mate’s IP address, and TCP GET on the

mate’s IP address in cases of MQTT, CoAP and HTTP-REST speaking things, respectively.

Energy consumption is measured using PowerJive – a USB-based device that measures

voltage and capacity. For each operation in Table 9-7, Table 9-8 and Table 9-9, we measured the

152

total energy consumed in executing a loop consisting of only this operation for 10 minutes. To

factor out energy consumed by background OS processes, we measured their total energy

consumption over the same 10 minute duration, which we then subtracted from that of the

operation to obtain the approximated total energy consumed by the operation. A first average

was taken by dividing the adjusted total energy by the number of times this operation was

completed within the 10 minute duration. The whole process was repeated three times for each

operation and a second average was calculated over the three measurements. Table 9-7, Table 9-

8 and Table 9-9 show the measurements of energy consumption (watt-seconds) on the two

hardware platforms with respect to the basic communication functions under MQTT, CoAP and

HTTP-REST protocols, respectively.

Table 9-7. Energy consumption (in watt seconds) measurements for MQTT functionalities.

Connect to SSB broker Publish Receive and process message

Raspberry Pi 0.2985 0.03947 0.0399

Beaglebone Black 1.2739 0.16689 0.1507

Table 9-8. Energy consumption (in watt seconds) measurements for CoAP functionalities.

Multicast (POST) Unicast (GET) Receive and process message

Raspberry Pi 0.00025 0.00247 0.00053

Beaglebone Black 0.000790 0.00340 0.00160

Table 9-9. Energy consumption (in watt seconds) measurements for REST functionalities.

Unicast (POST) Unicast (GET) Receive and process message

Raspberry Pi 0.01813 0.0165 0.0078

Beaglebone Black 0.02885 0.0209 0.0327

It should be noted that basic measurements obtained in Table 9-7, Table 9-8 and Table 9-

9 could vary if we change the type of network used, the processor clock frequency or the amount

of RAM used. However, these measurements are critical to designing a battery-operated thing in

153

a given use scenario with a targeted thing-operational lifetime. It should also be noted that the

more powerful the platform – the Raspberry Pi with 1GB of RAM and quad-core processor –

consumes less energy for all basic operations as compared to the Beaglebone Black platform.

CoAP that utilizes UDP is also shown to be a lightweight communication protocol compared to

both MQTT and REST which utilize TCP on both Raspberry Pi and Beaglebone Black.

Benchmarking Energy Consumption

Unlike the previous subsection, in which we measured the energy consumption of each

individual operation in our communication framework, in this section we measure the energy

consumed in full-interaction scenarios from the point of view of one thing in a network of four or

more things. Two main scenarios were examined: homogeneously communicating things and

heterogeneously communicating things. We also compared energy consumption of our

communication framework with Eclipse’s Ponte system.

And finally an examination was made of the scalability of our proposed approach as the

number of communicating Atlas things in a smart space increases. For the above scenarios, we

set up a network of four Atlas communicating things (two Raspberry-Pi’s and two Beaglebone

Black’s). Each Atlas thing interacts with thing mates by generating random interactions that

follow a uniform distribution process with a mean interval of 5 seconds, for a period of 10

minutes. Interactions are limited to only identity announcements or unicast interactions (e.g.,

API calls) with another thing. Each thing also listens to other things’ announcements and API

calls.

If configured to speak HTTP REST or CoAP, an Atlas thing can be further configured

with either an on-thing or off-thing Atlas protocol translator attachment. No attachments are

necessary if an Atlas thing is configured to speak MQTT. In case of the off-thing attachment, the

Atlas protocol translator resides on a Linux Ubuntu machine on the same local network as the

154

Atlas things. Only the Raspberry Pi was reported on even though we have conducted

experiments for the Beaglebone Black as well.

Experiment 1 - Homogenous things scenario. In this experiment we measure the

energy consumed by an Atlas thing when it engages within a homogeneous network of four

things. In this experiment an arbitrary thing is chosen at random to take the measurements. As

shown in Figure 9-15, MQTT-speaking things are found to consume more energy, as an MQTT

client requires a long-term TCP connection to be maintained with the broker. In the case of

CoAP or HTTP REST, an Atlas thing can talk in discontinued sessions with other things over

UDP and TCP channels respectively. Figure 9-15 shows that an Atlas MQTT-speaking thing

consumes around 8% more energy than an HTTP REST-speaking thing, and around 20% more

than a CoAP-speaking thing for a homogenous things scenario.

Figure 9-15. Atlas communication framework for homogenous speaking things.

Experiment 2 - Heterogeneous things scenario. In this experiment we measure the

energy consumed by an Atlas thing when it engages within a heterogeneous network of four

things (two MQTT-speaking, one CoAP-speaking, and one-HTTP REST speaking). The

experiment shows the energy difference between utilizing an on-thing and off-thing Atlas

155

protocol translator for the non MQTT-speaking things to engage with other things through the

SSB broker. As it uses no translators, MQTT thing’s energy consumption is not measured in this

experiment. The on-thing Atlas protocol translator – as listed in Table 9-6 – taxes an extra code

footprint on the Atlas node, however it saves energy that would be consumed by the thing to

create a connection and to listen to notifications from an off-thing Atlas protocol translator, as

shown in Figure 9-16. It is worth mentioning that with 540 more kilobytes of code, the on-thing

Atlas protocol translator saves around 7% in energy. Such small amounts of energy saving could

add up in a real-life scenario over a much longer duration.

In this experiment we also measured the time required for the non-MQTT speaking thing

to utilize the Atlas protocol translator (on-thing and off-thing) to multicast an announcement.

Time was measured using the Unix-Chrono library for a high-resolution clock cast to

microseconds. The off-thing translator takes more time, as would be expected, as shown in

Figure 9-17, as it receives a request from the connected thing to send an announcement to the

smart space. The time difference between the off-thing and on-thing is not significant, though.

The off-thing translator takes more time because, upon receiving a request, it must build the

MQTT packet and announce it using the Atlas IoT topic hierarchy (detailed in Chapter 5). It

should be noted that this set of experiments shows a slight increase in latency mainly because the

four Atlas things and the off-thing Atlas protocol translator (on a Linux Ubuntu machine) reside

in the local network with a low traffic load. However, the time difference between utilizing the

on-thing and off-thing translator for a multicast announcement would increase proportionally to

the network traffic when more things are added into the smart space. Supporting both on- and

off-thing translator in our approach would therefore allow the framework to be configured

appropriately based on the scale of the smart space deployment.

156

Figure 9-16. Atlas communication framework for heterogeneous speaking things.

Figure 9-17. Time comparison for the on-/off-thing Atlas translator for non-MQTT speaking

things.

Experiment 3 - Atlas framework vs Eclipse Ponte. In this experiment we compared

energy consumption by our Atlas communication framework with Eclipse’s Ponte framework in

157

both homogenous and heterogeneous scenarios. Eclipse Ponte offers a set of APIs that enable

MQTT, REST-HTTP and CoAP speaking things to communicate through a centralized gateway

that speaks all these languages. Eclipse Ponte requires the space owner to dedicate a powerful

edge device (e.g., a server) that hosts the gateway with a continuous source of power that

guarantees gateway availability. Our framework, on the other hand, utilizes the cloud-based

MQTT broker HiveMQ dashboard as the default broker defined by SSB in the Atlas thing IoT-

DDL. Such cloud-based broker alleviates the requirement on the space owner to set up a

centralized gateway dedicated to the smart space and reduces the effort to create a shared

channel for things to communicate.

For this experiment, we installed Eclipse Ponte on a Linux-Ubuntu workstation

connected to the local network and which utilized MQTT client, CoAP client and HTTP-REST

client on things listed in Table 9-1. We also utilized a network of 4 things (2 MQTT things, one

CoAP thing and one HTTP REST thing). For homogenous speaking things, as shown in Figure

9-18, MQTT-speaking things that utilize Atlas framework consumes more energy as the SSB

broker is an online cloud broker compared to the Ponte workstation that exists on the local

network. The homogenous things that speak CoAP or HTTP within the Ponte framework

consume more energy, as such things require a continuous connection to the centralized gateway

for notifications and updates from other things that announce their presence or those that initiate

unicast interactions (e.g., API calls). However, the advantage of our framework in the

homogeneous case is shown clearly in the CoAP and HTTP REST cases. Our framework

consumes 22% less energy for CoAP things, and 17% less energy for HTTP-REST things. This

homogeneous advantage is critical in planned spaces where it is more likely to find

homogeneously communicating things than heterogeneous.

158

For heterogeneous speaking things, as shown in Figure 9-19 (notice MQTT is not

presented as it does not use attachments), our framework and Ponte consume almost the same

energy in the case of on-thing attachments (actually our framework is slightly better in the CoAP

case, and slightly over in the HTTP-REST case). In the case of off-thing attachments, our

framework consumes only 5% and 8% more energy than Ponte in the CoAP and HTTP REST

cases, respectively. It should be noted that our framework does not impose the use of a

centralized gateway dedicated to the smart space to host Eclipse Ponte. This is a heavy

requirement imposed on the space owner. In contrast, our framework configures the Atlas things

– through the IoT-DDL– to utilize any readily available standardized broker. In this work we

used the HiveHQ broker to enable a seamless interoperable smart space with the least human

intervention and effort on the part of the space owner.

Figure 9-18. Comparing Atlas communication framework and Eclipse Ponte for homogenous

communicating things.

159

Figure 9-19. Comparing Atlas communication framework and Eclipse Ponte for heterogeneous

communicating things.

Experiment 4 - Atlas framework scalability. In this experiment we examined the

scalability of our proposed framework by increasing the number of Atlas things that engage with

each other in the smart space. However, in order to manage the experiment, we ran 5, 10 and 15

concurrent Atlas thing processes (virtual things) on a shuttle Linux-Ubuntu machine (a portable

server machine). One Raspberry Pi Atlas thing that speaks CoAP and utilizes an on-thing Atlas

protocol translator was used as a point of measurement, and was connected to a network of 6, 11,

and 16 things running the same interaction scenario. Figure 9-20 shows the energy consumed by

the Raspberry Pi Atlas thing. As shown in Figure 9-20, the Atlas thing can interact and engage

with a large number of thing mates that speak similar or different languages, and exhibit only a

small increase in the consumed energy. In fact, such small increases in consumed energy seem to

decrease gradually with the number of communicating Atlas things in the smart space. Doubling

the number of things from 5 to 10 increased energy consumption by only 19%. Adding 50%

more nodes (from 10 to 15) increased energy consumption by only 8%. The scalable increase in

160

energy consumption reflects the energy spent in listening to announcements and learning APIs of

the IoT as it grows and expands.

Figure 9-20. Testing scalability on a CoAP-speaking Atlas thing with on-thing Atlas protocol

translator.

Evaluating Atlas RIDE

In this section, we provided a benchmarking study to measure the performance of the

Atlas RIDE in terms of energy consumption, time performance and memory footprint

characteristics. The developed version of the Atlas RIDE is for Android-based smartphones,

where the established, inferred and generated Atlas IoT apps are full Android applications (as

detailed in Chapter 7). Thus, for a true evaluation of the performance and the feasibility of such

an interactive application development environment, the experiments should answer a set of

essential questions to both the layman mobile user and the application developer. In this section,

we describe a set of experiments to benchmark time latency, the memory footprint and energy

consumption, along with estimated complexity measurements for the features of the proposed

RIDE to answer the following questions: a) what is the correlation between the background

resource usage of the explorer and the number of things tweeted in the smart space? (Experiment

1); b) what is the memory footprint of the full RIDE, and the memory footprint of a typical IoT

161

app generated by the on-cloud app generator and installed on the smartphone? (Experiment 2); c)

what is the energy cost of hosting an IoT app that interacts with the smart space at the runtime?

(Experiment (3); d) will the developer receive the generated application from the on-cloud app

generator, in a reasonable time and with reasonable energy costs, after describing the application

on the RIDE? (Experiment 4); e) how does the resource usage of both the recipe generator and

inference engine scale with the number of available services and relationships? (Experiment 5).

The experiments detailed below, as mentioned early this chapter, target Nexus 9 (Android

version 6.0.1, Battery type Lithium Polymer, Battery capacity 6700 mAh, Voltage 3.7 V, RAM 2

GB) to evaluate and benchmark the feasibility of the proposed RIDE on a real smartphone. To

benchmark certain features of the Atlas RIDE, the function of interest was placed into a separate

computing thread (referred to as the worker thread) that can run repeatedly while another thread

samples resource usage (time, memory, or energy) over time. Time measurement is

benchmarked using the nanotime method of the System API [94] to record the time window for

the operation of the function of interest. For interactions with external processes, such as the

cloud app generator, the Unix-time utility [95] is used as a supplement for a high-resolution

clock monitoring. Memory measurement is benchmarked using the Android runtime API [96] to

record the difference in the available heap memory between the start and the end of the execution

for the function of interest. To avoid data outliers, both time and memory measurements of a

single function were averaged over several measurements.

Power consumption for Android devices with a battery fuel gauge (that is available on the

selected Nexus 9) was measured using the Android Battery Manager API [97] queried at fixed

intervals to determine the charge level during execution. Due to the unreliable nature of the

battery API over short periods, the tests were run repeatedly over a 10-minute time period (for

162

Experiments 2, 3 and 4) and over a 6-hour time period (for Experiment 1), and an average was

calculated using the number of iterations and the total change in battery charge level. The energy

consumption of the background OS processes and tablet hardware was also used as a baseline.

These values were measured by recording the power consumption of an “empty” app (Figure 9-

21), one which has no functionality beyond the default activity view. The baseline was then

subtracted from the experimental results to determine the power consumed by the RIDE

components themselves. For experiments utilizing the on-cloud app generator, the service to

convert applications manifests into Atlas IoT Android applications which were run on an edge

device in the same local network as the RIDE and smart space things – a 2014 MacBook Pro

with 2.5 GHz CPU and 16GB RAM.

Figure 9-21. The power consumption of an app with no active functionality on our Nexus 9

device.

Experiment 1 - Explorer Resource Usage (ERU). ERU benchmarks the run-time

correlation between the background resource usage of the explorer module and the number of

things in the smart space. In this experiment, the explorer (with no other portions of the RIDE

active) ran in a simulated smart space to determine the energy consumption resulting from

0

5

10

15

20

25

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Wat

t-H

ours

Time (Hours)

Remaining Battery Energy (Watt-Hour)

163

sensing and analyzing available services. Six model tweets—covering thing identity, services,

and relationships—were developed and sent at a rate of one tweet per minute to represent an

average thing. To simulate an entire smart space, the interactions of this average thing were

duplicated and varied slightly to represent a varying number of things tweeting their identities,

capabilities, services and relationships.

The reported benchmark (Figure 9-22) monitored a fully charged device over a six-hour

period in a simulated smart space with up to 30 things, showing the energy required by the

explorer to listen to and maintain awareness of the surrounding things. In an empty smart space

(zero things), the explorer must still listen and wait for potential tweets, resulting in a small

energy cost. As the number of things increases, the energy consumption also increases, albeit at a

decreasing rate; while the difference between one and ten things is about 3 watt-hours, the

difference between 10 and 30 is only about 2 watt-hours. Following this trend, larger numbers of

things will likely continue to have smaller increases in total energy consumed. This benchmark

affirms that the resource usage incurred by the explorer is within acceptable boundaries, drawing

only about 28% of the device’s battery in a six-hour period while receiving almost 200 tweets a

minute.

Compared to the baseline energy consumption shown in Figure 9-21, actively listening to

a smart space of 30 things consumed about twice as much energy as an idle application. While

such consumption is not insignificant, these results are bound to the tested device, including its

hardware and the year it was built (2014), as well as our current RIDE architecture and

algorithms. These measurements do, however, paint a clear picture of which portions of the

RIDE incur the greatest cost, and set the stage for promising future improvements. Another way

to put the current ERU energy consumption rate in prospectus is to compare it to other currently

164

available applications (e.g. Facebook). Over the duration of six hours, an idle web view

displaying a Facebook feed consumed around 4 watt-hours, which is nearly 80% of the energy

required by the Atlas RIDE to listen to a smart space of 10 things.

Figure 9-22. Explorer Resource Usage with respect to the number of offered services by Atlas

things.

Experiment 2 - Generated Application Memory Footprint (GAMF). GAMF

benchmarks the memory footprint of a generated Atlas application after it has been installed on

the device, with respect to the number of relationships and services that it consists of.

To facilitate this experiment, along with Experiments 3, 4 and part of 5, we constructed a

benchmark that spans a range of realistic scenarios. The intention was to obtain measurements

over a space of parameters (the benchmark) rather than selecting ad-hoc points in the

experimentation space that may lead us to non-conclusive evidence. Our benchmark assumes the

following S services and R relationships combinations in the smart space: (S, R) {(2,0), (4,1),

(6,2), (8,3), (30,10)}. Recipes generated according to this benchmark range from simple ones

0

10

20

30

40

50

60

70

80

90

100

0

1

2

3

4

5

6

7

8

0 1 10 30

Per

cen

tag

e

Wat

t-H

ou

rs

Number of Things

Energy Consumption (Watt-Hour) Battery Percentage

165

with only two services to more complex recipes with up to 30 services and 10 relationships. Such

recipes were then passed through the application generator and installed on the device.

The Android system utilities were used to determine the in-memory size of all generated

recipes (as shown in Table 9-10). By inspecting the generated code, it was evident the bulk of the

generated portion (the initial logic to create the service and relationship structures) constituted

the majority of the memory footprint (about 80%). An anatomy analysis of one of the generated

packages (before installation) revealed it consisted of approximately 2.8 MB of compiled code,

500 KB of resources, and 100 KB of metadata. Table 9-10 shows the increase in memory from a

recipe with two services to one with 30 services and 10 relationships, which is about 6 KB or

0.4%. As a result, it is safe to conclude that the final generated code size for a personal IoT

application will be relatively similar regardless of the number of services and relationships.

As a baseline to compare against, an app mirroring the functionality of the generated app

with two services was written, with manually created interfaces and application logic (as

opposed to the auto-generated nature of the experimental applications). The installed size of this

application measured 12.66 MB, which is very close to the size of the generated application due

to method by which the application logic is generated. Most of the functionality is fixed,

including managing the services and relationships and communicating with the relevant things.

Overall, the benchmarked memory footprint shows that the installed generated applications

consume a small percentage of available storage space, considering the commonly available

storage capabilities of current smartphones (e.g., 16, 32, or 64 GB). Additionally, the Atlas RIDE

itself consumes an acceptable amount of storage, measuring 48.4 MB on our device’s external

storage.

166

Table 9-10. The memory footprint of installing the generated Application

Characteristics of the generated application recipe Memory footprint for installing the

generated application (MB)

2 services and no relationships 12.75

4 services and 1 relationship 12.76

6 services and 2 relationships 12.76

8 services and 3 relationships 12.76

30 services and 10 relationships 12.81

Experiment 3 - Application Resource Usage (ARU). As mentioned earlier, the on-

cloud application generator converts an application manifest into an Atlas IoT application to be

downloaded and installed on the user’s device. ARU benchmarks the runtime energy

consumption of the installed generated application when it is executed – the power required to

communicate back and forth with other Atlas smart space things that offer the required services

via API calls. Parameters are sent to a thing and a response value is received before repeating

this interaction with the next endpoint until all services in the recipe have been executed. The

aim here is to verify that the energy consumption behavior of the generated apps is not abnormal

and within what would be expected from other optimized, non-generated apps. That is, the app

generation process is reasonable and does not introduce any excessive or unnecessary energy

overhead. To calculate this resource usage, the recipe of each generated app was executed

several times, recording the total energy consumption and dividing by the number of recipe

executions.

Figure 9-23 illustrates energy consumption (in watt-hour) for the generated application as

one unit, where the generated application is composed of S services as per the benchmark

outlined in Experiment 2. In addition to consuming negligible energy per invocation, a generated

app does not appear to present any abnormal or excessive overhead. As mentioned in Experiment

167

2, only the initialization portion of the app—which creates the service structures based on the

original recipe created in RIDE—is generated. As a result, the runtime overhead incurred by a

generated application should be the same as a non-generated one using the same structures. To

test this, we developed a non-generated app invoking two services, which consumed about 1.9e-7

watt-hours per invocation; nearly the same as the generated variant (within 5%). Like the ERU

benchmark, these results are again bound to our testing environment, depending mainly on the

device’s network module and connection.

Figure 9-23. ARU with respect to the number of services in the recipe.

Experiment 4 - Provisioning Generated Application (PGA). PGA measures both the

time and energy requirements for generating an Atlas IoT application using the on-cloud

generator. After the application developer describes the application in terms of the desired

recipes, relationships, and services, the RIDE interacts with the cloud server to create a new

package and install it on the device. These steps include: 1) generating the app manifest (as

detailed in Chapter 7); 2) pushing the manifest to the on-cloud app generator service to formulate

0.00E+00

5.00E-07

1.00E-06

1.50E-06

2.00E-06

2.50E-06

3.00E-06

2 4 6 8 30

Wat

t-H

ou

rs

Number of Services

Energy Consumption per Invocation (Watt-Hour)

168

the android application; and 3) downloading the generated application, ready for installation on

the original device. PGA benchmarks the cost of these actions in terms of time latency and

energy consumption (shown in Table 9-11). Additionally, PGA records the server time the on-

cloud generator takes to formalize and create the android package, allowing for comparison

between computation time and network time. To avoid outliers, these benchmarked values are

averaged over multiple trials.

As the complexity of the desired recipe increases, both time latency and energy

consumption increase slightly. Overall power consumption is relatively low as only the manifest

creation and communication is handled by the device itself; most of the heavy lifting is done by

the cloud server. Like ARU and ERU, these results are again closely bound to the networking

capabilities of the test device, as well as the capabilities of the cloud server.

Table 9-11. Provisioning Generated Application with respect to the established recipe.

IoT application recipe Average total

generation time

(seconds)

Average server

time

(seconds)

Average power

consumption

(watt-hours)

2 services and no relationships 6.112 5.744 9.496e-3

4 services and 1 relationship 5.961 5.511 9.126e-3

6 services and 2 relationships 6.513 6.185 1.024e-2

8 services and 3 relationships 6.282 5.962 1.283e-2

30 services and 10 relationships 6.512 5.937 1.764e-2

Experiment 5 - Recipe Generator Monitor (RGM). RGM benchmarks time, memory,

and energy consumption for inferring relationships and generating recipes with respect to the

number of available services, relationships and user preferences. The complexity of the

relationship inference module is the combined complexity of transitivity property, exchange and

composition properties detailed in Chapter 7. For X cooperative relationships and Y competitive

relationships (where 0 ≤ X and 0 ≤ Y), the following complexities were examined: 1)

169

Transitivity property is to infer a new cooperative/competitive relationship between two

cooperative/competitive relationships with complexity equals to the max of (X2, Y2); 2)

Exchange property is to infer a new cooperative relationship between cooperative and

competitive relationships with complexity of XY; and 3) Composition property is to infer new

cooperative relationships between two cooperative or between one cooperative and one

competitive relationship with complexity equals to the max of (X2, XY). Thus, the Complexity

of the Relationship Inference module is the max of (X2, Y2).

With that in mind, along with the personal smart space benchmark created before (a

smart space with S services, R relationships and U user preferences), the recipe generator first

selects S’ services (0 ≤ S’ ≤ S) that match app categories defined in U. The generator then selects

R’ relationships (0 ≤ R’ ≤ R) that engage these S’ services in established, received or inferred

relationships with other services in the repository. With P primitives of S’ services and R’

relationships, 0 ≤ (P = S’ + R’) ≤ (S + R), the generator prunes services from set S’ if such

services are competitive or duplicated with services already included within the relationships in

set R’. The recipe generator then generates the possible subsets of the P primitives, where each

subset represents a possible recipe. Thus, the number of possible recipes to be generated equals

2P (where 0 ≤ 2P).

To estimate the number of possible recipes to be generated in the domain of a personal

smart space, we first need to state the expected number of things in the personal smart space, and

the expected number of services and relationships reported by each thing. In this experiment, we

used an estimation of the expected number of primitives (services and relationships) reported by

an Atlas thing in a smart space, where an Atlas thing can offer—with equal probabilities—1, 2,

or 3 services and report 0, 1 or 2 relationships. The calculations of these primitive estimates for

170

3, 5 and 10 Atlas things are straightforward and are shown in the second column of Table 9-12.

The selected services, S’ (0 ≤ S’ ≤ S), are the services with application categories that match the

defined user preferences (0 ≤ U), U. Thus, the number of recipes generated is reduced from all

possible subsets of the primitives to only the possible subsets involving the selected services and

the available relationships. For a personal smart space with 3, 5 or 10 Atlas things, as illustrated

in Table 4, the expected number of generated recipes ranges from 10 to 1038 recipes.

However, with the closeness operator and the developers’ possible overrides, the number

of generated recipes could be pruned further. Table 9-13 illustrates the benchmark study in terms

of the time latency (in microseconds), heap memory consumption (in bytes) and energy

consumption (watt-hour) we have on running the recipe generator on a set of S services, R

relationships and U preferences. As illustrated in Table 9-13, with a slight increase in time

latency, memory and energy, RIDE utilizes the recipe generator to suggest more recipes and

application nuggets to the developer when more services and relationships are available.

Taking the following example to illustrate the operation of the Recipe Inference Module

with the following services and relationships in a smart space (illustrated in Table 9-14 and

Figure 9-24). The developer defined the preferences to be the time alarm and automation. The

generator selects the matched services and the corresponding relationships, as illustrated in

Figure 9-25. The generator selects the services that match the user preferences according to the

app category (Set n = {S1, S4}). For each service in set n, the generator considers the different

relationships that engage such service with other services (Set m = {R1, R2}). From the initial

set of primitives P = {S1, S4, R1, R2}, the generator prunes services from set n if such services

are already included within the relationships in set m (the updated set P = {S4, R1, R2}). From

the updated set of primitives, the generator creates the possible subsets and the possible

171

combinations: = {{S4}, {R1}, {R2}, {R1, R2}, {S4, R1}, {S4, R2}, {S4, R1, R2}}, and then

measures the semantic closeness between the generated recipes and preferences. It then selects

the highly matched recipes, as illustrated in 9-26.

Table 9-12. Expected number of generated recipes with respect to the expected number of

reported primitives by the things and the number of defined preferences.

The number of

Atlas things

Expected number of

reported Primitives

(S+R)

Expected number of

generated recipes for

U = 1

Expected number of

generated recipes for

U = 2

3 9 10 12

5 15 36 39

10 30 1031 1038

Table 9-13. Benchmark study on the recipe generator with different number of services,

relationships and preferences.

S services, R relationships, and

U preferences

Time latency

(Microseconds)

Heap Memory

Consumption

(Bytes)

Energy

Consumption

(watt-hour)

S = 2, R = 0 and U = 1 13.2 1638 8.39e-9

S = 4, R = 1 and U = 1 28.2 1854 2.34e-8

S = 6, R = 2 and U = 1 35.9 1984 3.66e-8

S = 8, R = 3 and U = 1 59.2 3485 5.45e-8

S = 30, R = 10 and U = 1 20891.4 48667 1.57e-5

Table 9-14. Smart space with seven services and three relationships.

Services Relationships

Service 1: Trigger alarm – Category: Time Alarms

Service 2: Prepare Morning Coffee – Category: Eating

Service 3: Prepare Breakfast toast – Category: Eating

Service 4: Turn off kitchen switch – Category:

Automation

Service 5: Control Window blinds – Category: Lighting

Service 6: Watch movie on the monitor - Category:

Entertainment

Service 7: Record Channel - Category: Entertainment

Relation 1: Control relationship

between Service 1 and Service 2

Relation 2: Control relationship

between Service 1 and Service 3

Relation 3: Support relationship

between Service 5 and Service 6

172

Figure 9-24. A smart space with seven services and three relationships.

Figure 9-25. The selected subset of services and relationships that match the developer’s

preferences.

Figure 9-26. The generated recipes that follow the developer’s preferences.

To prove that the Recipe Inference module generates space-related meaningful

applications to the Atlas IoT RIDE users, we first need to define what a “meaningful app” is. A

173

meaningful app, from our prospective, is the app that: 1) satisfies user preferences; 2) infers from

established recipes by the developer; and 3) utilizes reputable services and maintains the

available relationships between such services. Based on the benchmark outlined in Experiment 2,

consider a smart space with a set of 4 different services {A, B, C, D} and 1 relationship R1

between service C and service D. Further, assume the developer has defined 2 preferences {P1

follows category of service A, P2 follows category of service B and C}. From the services and

relationships that follow the defined preferences (A, B and R1), the Recipe Generator first starts

with generating the possible subsets of the available primitives: {{A}, {B}, {R1}, {A, B}, {A,

R1}, {B, R1}, {A, B, R1}} as candidate recipes. The candidate recipes that semantically follows

only P1 and semantically follows only P2 are {A} and {B} respectively, representing 2/7 of the

generated recipes. At the same time, the candidate recipes that semantically follow one or both of

the defined preferences along with more functionalities in terms of other related services are

{{R1}, {A, B}, {A, R1}, {B, R1}, {A, B, R1}}, representing 5/7 of the generated recipes. Thus,

if the developer established a meaningful application X of services {A, B} that follows his own

preferences, the engine generates meaningful applications that contain the same services along

with other functionalities (service D through relation R1). The user’s preferences represent 2/3 of

the possible preferences for the generated candidate recipes {A, R1} and {B, R1}, and represent

3/4 of the possible preferences for the generated candidate recipe {A, B, R1}.

174

CHAPTER 10

CONCLUSION AND SUMMARY

In this research, we argue that the promise and transformative success of the IoT vision

will greatly depend on how its main ingredient – the thing, is prepared, aligned and made able to

engage in such a mission. The fragmented nature of IoT things requires significant efforts to

integrate, manage, and configure such a wide heterogeneity of things. We first propose IoT-

DDL, a machine- and human-readable descriptive language that tools a thing to self-discover and

share its own capabilities, entities, services, and the various cloud-based resources that could be

attached to it to extend it over time. Making things describable using IoT-DDL enables self-

discovery so the thing itself becomes self-aware of what it can offer and what its capabilities are.

It also empowers the seamless integration, configuration, and management of things with

minimal human intervention and enables the various secure interactions that support the

distributed nature of IoT.

We also presented the Atlas thing architecture, which fully exploits the goals of the IoT-

DDL and its specifications. The Atlas Thing Architecture goes beyond and above standard

embedded OS services to provide new layers and services with novel capabilities necessary for

things to be part of the IoT. In addition, the Atlas Thing Architecture takes advantage of widely

used device management, security, and IoT communication standards to enable thing

engagement in secure ad hoc interactions with thing mates and space users. At the same time, the

Atlas Thing Architecture utilizes the microservices framework to enable the thing, through the

service description in the IoT-DDL, to dynamically generate the services it offers to the smart

space and to formulate appropriate interfaces (APIs) for thing mates to access such offered

services.

175

Next, we proposed the Atlas communication framework that enables distributed

interaction between things that speak similar or different IoT communication languages. The

proposed framework does not tax the performance of the homogenously communication things.

The framework offers lightweight IoT interoperability through a protocol translator that resides

either on the cloud platform or on the thing itself. The protocol translator enables seamless

communication between heterogeneous things through a set of well-defined interfaces. The

proposed Atlas communication framework enables the real participation of heterogeneous things

in a smart space with minimal human intervention and the seamless integration of new things.

Our proposed framework also opens the door for programming opportunities that may involve

things that utilize different communication languages to cooperate and interact.

We also proposed an inter-thing relationships programming framework that utilizes our

Atlas Thing Architecture and the thing IoT-DDL project as a basis for a distributed programming

ecosystem. The framework proposes a set of powerful relationships that tie the services offered

by the things in the smart space opportunistically and which can be exploited by developers to

build meaningful IoT apps. We then proposed the Atlas RIDE as the interactive development

environment that enables mobile users to sense the surrounding smart space, develop domain-

related applications and glimpse the existence of programming opportunities dynamically. Atlas

RIDE listens to the surrounding smart space, captures information announced by the smart things

regarding their identities, services and capabilities, and then infers the existence of new

engagement opportunities between the announced services for new and innovative scenarios and

applications for the developers. Atlas RIDE casts the developer’s established applications and

the inferred applications that follows the developer’s preferences into full mobile applications

that run independently from the development environment.

176

We presented three detailed IoT scenarios that engage daily IoT devices and smart things

around us, showing how the proposed approaches cooperate. The scenarios illustrate the

capability of the thing to: 1) self-discover its own identity and capabilities; 2) announce its

presence to the smart space; 3) present the IoT attributes into descriptive objects and interact

with the device manager; 4) communicate with other things in the smart space that speak the

same communication language or a different one in an ad-hoc manner; 5) generate its own

services as well as the appropriate access interfaces (APIs); and 6) create a programmable

objects that represent the different relationships that tie its services with the services of others.

We then demonstrated the implementation details and proved the feasibility of deploying the

proposed approaches on real IoT through a benchmarking study. The study measures time

performance, memory footprint, and the energy consumption rate of the main features.

177

LIST OF REFERENCES

[1] Want, R., & Dustdar, S. (2015). Activating the Internet of Things [Guest editors'

introduction]. Computer, 48(9), 16-20.

[2] Gubbi, J., Buyya, R., Marusic, S., & Palaniswami, M. (2013). Internet of Things (IoT): A

vision, architectural elements, and future directions. Future generation computer

systems, 29(7), 1645-1660.

[3] Miorandi, D., Sicari, S., De Pellegrini, F., & Chlamtac, I. (2012). Internet of things: Vision,

applications and research challenges. Ad hoc networks, 10(7), 1497-1516.

[4] Atzori, L., Iera, A., & Morabito, G. (2010). The internet of things: A survey. Computer

networks, 54(15), 2787-2805.

[5] Tan, L., & Wang, N. (2010, August). Future internet: The internet of things. The 3rd IEEE

International Conference on Advanced Computer Theory and Engineering (ICACTE), 5,

V5-376.

[6] Atzori, L., Iera, A., Morabito, G., & Nitti, M. (2012). The social internet of things (siot)–

when social networks meet the internet of things: Concept, architecture and network

characterization. Computer networks, 56(16), 3594-3608.

[7] Atzori, L., Iera, A., & Morabito, G. (2011). SIoT: Giving a social structure to the internet of

things. IEEE communications letters, 15(11), 1193-1195.

[8] Amazon AWS IoT (2016). From http://aws.amazon.com/iot/

[9] Web of Things at W3C (2017). From https://www.w3.org/WoT/

[10] Nastic, S., Sehic, S., Vogler, M., Truong, H. L., & Dustdar, S. (2013, December).

PatRICIA--A Novel Programming Model for IoT Applications on Cloud Platforms.

In Service-Oriented Computing and Applications (SOCA), 2013 IEEE 6th International

Conference on (pp. 53-60). IEEE.

[11] Namiot, D., & Sneps-Sneppe, M. (2016, November). On Internet of Things Programming

Models. In International Conference on Distributed Computer and Communication

Networks (pp. 13-24). Springer, Cham.

[12] Ur, B., Pak Yong Ho, M., Brawner, S., Lee, J., Mennicken, S., Picard, N., ... & Littman, M.

L. (2016, May). Trigger-action programming in the wild: An analysis of 200,000 IFTTT

recipes. In Proceedings of the 2016 CHI Conference on Human Factors in Computing

Systems (pp. 3227-3231). ACM.

[13] Helal, S., & Tarkoma, S. (2015). Smart Spaces [Guest editors' introduction]. IEEE

Pervasive Computing, 14(2), 22-23.

178

[14] Google Weave (2016). From http://developers.google.com/weave/

[15] Google Brillo (2016). From http://developers.google.com/brillo/

[16] Chen, C., & Helal, S. (2008). Sifting through the jungle of sensor standards. IEEE Pervasive

Computing, 7(4).

[17] Kaebisch, S., & Anicic, D. (2016). Thing Description as Enabler of Semantic

Interoperability on the Web of Things. In IoT Semantic Interoperability Workshop.

[18] Hasemann, H., Kroller, A., & Pagel, M. (2012, October). RDF Provisioning for the Internet

of Things. In Internet of Things (IOT), 2012 3rd International Conference on the (pp. 143-

150). IEEE.

[19] Barker, L., White, M., Curran, M., Patoli, Z., Huggins, B., Pascu, T., & Beloff, N. (2014).

Taxonomy for Internet of Things-Tools for Monitoring Personal Effects. In PECCS (pp. 67-

71).

[20] Dorsemaine, B., Gaulier, J. P., Wary, J. P., Kheir, N., & Urien, P. (2015, September).

Internet of things: a definition & taxonomy. In Next Generation Mobile Applications,

Services and Technologies, 2015 9th International Conference on (pp. 72-77). IEEE.

[21] Ahmed, E., Yaqoob, I., Gani, A., Imran, M., & Guizani, M. (2016). Internet-of-things-based

smart environments: state of the art, taxonomy, and open research challenges. IEEE

Wireless Communications, 23(5), 10-16.

[22] Lefkowitz, P. M. (2015). Making Sense of the Internet of Things. Boston Bar J., 59, 23.

[23] Want, R., Schilit, B. N., & Jenson, S. (2015). Enabling the internet of

things. Computer, 48(1), 28-35.

[24] Google Physical Web “Walk up and use anything,” (2016). From google.github.io/physical-

web.

[25] ARM Connected Community (2016). From https://community.arm.com/

[26] ARM white paper “An Introduction to the ARM mbedTM IoT Device Platform,” October

2014.

[27] ARM SensiNode IoT technology Whitepaper “NanoSeviceTM Solution: Optimized Web

Service Technology for an Embedded World,” 2014.

[28] ARM SensiNode IoT technology Whitepaper “Running Sensinode NanoService using mbed

Platform,” 2014.

[29] IBM “How IBM Sees the Internet of Things,” from ibm.com/internet-of-things, 2015.

179

[30] IBM “Watson IoT welcome to the era of cognitive IoT,” 2015.

[31] Li, S., Da Xu, L., & Zhao, S. (2015). The internet of things: a survey. Information Systems

Frontiers, 17(2), 243-259.

[32] Khan, R., Khan, S. U., Zaheer, R., & Khan, S. (2012, December). Future internet: the

internet of things architecture, possible applications and key challenges. In Frontiers of

Information Technology (FIT), 2012 10th International Conference on (pp. 257-260). IEEE.

[33] Abreu, D. P., Velasquez, K., Curado, M., & Monteiro, E. (2017). A resilient Internet of

Things architecture for smart cities. Annals of Telecommunications, 72(1-2), 19-30.

[34] Robles, M. I., & Jokela, P. (2015). Design of a Performance Measurements Platform in

Lightweight M2M for Internet of Things. In IRTF & ISOC Workshop on Research and

Applications of Internet Measurements (RAIM).

[35] Robles, M. I., D'Ambrosio, D., Bolonio, J. J., & Komu, M. (2016, March). Device group

management in constrained networks. In Pervasive Computing and Communication

Workshops (PerCom Workshops), 2016 IEEE International Conference on (pp. 1-6). IEEE.

[36] Putera, C. A. L., & Lin, F. J. (2015, December). Incorporating OMA Lightweight M2M

protocol in IoT/M2M standard architecture. In Internet of Things (WF-IoT), 2015 IEEE 2nd

World Forum on (pp. 559-564). IEEE.

[37] Rao, S., Chendanda, D., Deshpande, C., & Lakkundi, V. (2015, August). Implementing

LWM2M in constrained IoT devices. In Wireless Sensors (ICWiSe), 2015 IEEE Conference

on (pp. 52-57). IEEE.

[38] Klas, G., Rodermund, F., Shelby, Z., Akhouri, S., & Höller, J. (2014). Lightweight M2M:

enabling device management and applications for the internet of things. White Paper from

Vodafone, Ericsson and ARM, 26.

[39] Jimenez, J., Koster, M., & Tschofenig, H. (2016). Ipso smart objects. In Position paper for

the IOT Semantic Interoperability Workshop.

[40] Koster, M. (2015). IPSO Smart Objects for IoT. OMA lwM2M workshop - IPSO alliance

objects.

[41] L. Holmquist, F. Mattern, B. Schiele, P. Alahuhta, M. Beigl and H. Gellersen (2001). Smart-

Its Friends: A Technique for Users to Easily Establish Connections between Smart artefacts.

In international conference on Ubiquitous Computing (pp.116-122). Springer, Berlin,

Heidelberg, 2001.

[42] Girau, R., Nitti, M., & Atzori, L. (2013, July). Implementation of an experimental platform

for the social internet of things. In Innovative Mobile and Internet Services in Ubiquitous

Computing (IMIS), 2013 Seventh International Conference on(pp. 500-505). IEEE.

180

[43] Turcu, C., & Turcu, C. (2012, October). The Social Internet of Things and the RFID-based

robots. In Ultra Modern Telecommunications and Control Systems and Workshops

(ICUMT), 2012 4th International Congress on (pp. 77-83). IEEE.

[44] Kranz, M., Roalter, L., & Michahelles, F. (2010, May). Things that twitter: social networks

and the internet of things. In What can the Internet of Things do for the Citizen (CIoT)

Workshop at The Eighth International Conference on Pervasive Computing (Pervasive

2010) (pp. 1-10).

[45] Ovadia, S. (2014). Automate the internet with “if this then that”(IFTTT). Behavioral &

social sciences librarian, 33(4), 208-211.

[46] Coulson, G., Blair, G., Elkhatib, Y., & Mauthe, A. (2015, June). The design of a generalised approach to the programming of systems of systems. In World of Wireless, Mobile and Multimedia Networks (WoWMoM), 2015 IEEE 16th International Symposium on a (pp. 1-6). IEEE.

[47] Nastic, S., Sehic, S., Truong, H. L., & Dustdar, S. (2013). Patricia-a novel programing

model for iot applications on cloud platforms. In In 6th IEEE International Conference on

Service-Oriented Computing and Applications (SOCA), 53-60

[48] Yun, J., Ahn, I. Y., Choi, S. C., & Kim, J. (2016). TTEO (Things Talk to Each Other):

Programming smart spaces based on IoT systems. Sensors, 16(4), 467.

[49] C., Xu, Y., Li, K., & Helal, S. (2010, July). Reactive programming optimizations in

pervasive computing. In Applications and the Internet (SAINT), 2010 10th IEEE/IPSJ

International Symposium on (pp. 96-104). IEEE.

[50] King, J., Bose, R., Yang, H. I., Pickles, S., & Helal, A. (2006, November). Atlas: A service-

oriented sensor platform: Hardware and middleware to enable programmable pervasive

spaces. In local computer networks, proceedings 2006 31st IEEE conference on (pp. 630-

638). IEEE.

[51] Helal, S. (2005). Programming pervasive spaces. IEEE Pervasive Computing, 4(1), 84-87.

[52] Khaled, A. E., Helal, A. S., Lindquist, W., & Lee, C. (2018). IoT-DDL—Device

Description Language for the “T” in IoT. IEEE Access, 6 (1), 24048-24063.

[53] Khaled, A. E., & Helal, S. (2018). Interoperable communication framework for bridging

RESTful and topic-based communication in IoT. Future Generation Computer Systems.

[54] Khaled, A. E., & Helal, S. (2018, February). A framework for inter-thing relationships for

programming the social IoT. In IEEE 4th World Forum on Internet of Things (WF-IoT), 670-

675.

[55] Helal, S., Khaled, A. E., & Gutta, V. (2017, October). Atlas Thing Architecture: Enabling

Mobile Apps as Things in the IoT. In Proceedings of the 23rd Annual International

Conference on Mobile Computing and Networking (pp. 480-482). ACM.

181

[56] Chen, C., & Helal, A. (2009, July). Device integration in SODA using the device

description language. In Applications and the Internet, 2009. SAINT'09. Ninth Annual

International Symposium on (pp. 100-106). IEEE.

[57] Mobile and Pervasive Computing Laboratory University of Florida, Device Description

Language Specification (Version 1.2), Nov. 2008.

[58] Device Description Language specification (2008). From

https://www.cise.ufl.edu/~helal/atlas/ddl/DDL-Spec-1.2.2.pdf.

[59] Xu, Y., & Helal, A. (2016). Scalable cloud–sensor architecture for the Internet of

Things. IEEE Internet of Things Journal, 3(3), 285-298.

[60] A. Helal and Y. Xu. (2015). Scalable and energy-efficient cloud-sensor architecture for

cyber physical systems. NSF Workshop on Big Data Analytics in CPS: Enabling the Move

from IoT to Real-Time Control, Seattle, 2015.

[61] Bose, R., King, J., El-Zabadani, H., Pickles, S., & Helal, A. (2006, June). Building plug-

and-play smart homes using the atlas platform. In Proceedings of the 4th International

Conference on Smart Homes and Health Telematic (ICOST), Belfast, the Northern

Islands (pp. 265-272).

[62] Chen, C., Bose, R., & Helal, A. (2009). Atlas: An open model for automatic integration and

tele-programming of smart objects. In Proceedings of the 3rd International Workshop on

Design and Integration Principles for Smart Objects (DIPSO 2009), In conjunction with

Ubicomp.

[63] Atlas IoT-DDL builder web tool (2016). From

https://cise.ufl.edu/~aekhaled/AtlasIoTDDL_Builder.html

[64] MQTT is a machine-to-machine (M2M)/"Internet of Things" connectivity protocol (2014).

From http://Mqtt.org.

[65] Eclipse Paho open-source implementation of MQTT project. From https://eclipse.org/paho/

[66] The Constrained Application protocol (CoAP). From http://coap.technology/

[67] The Constrained Application protocol (CoAP) IETF standards track 2014. From

https://tools.ietf.org/html/rfc7252

[68] NXP A700X_Family for secure authentication microcontroller. From

https://www.mouser.com/ds/2/302/a700x_fam_sds-1187735.pdf

[69] Hypertext Transfer Protocol HTTP v1.1 rfc. From https://tools.ietf.org/html/rfc2616

182

[70] Feng, X., Shen, J., & Fan, Y. (2009, October). REST: An alternative to RPC for Web

services architecture. In Future Information Networks, 2009. ICFIN 2009. First

International Conference on (pp. 7-10). IEEE.

[71] Karagiannis, V., Chatzimisios, P., Vazquez-Gallego, F., & Alonso-Zarate, J. (2015). A

survey on application layer protocols for the internet of things. Transaction on IoT and

Cloud Computing, 3(1), 11-17.

[72] Eclipse MQTT sandbox. From https://iot.eclipse.org/

[73] HiveHQ Enterprise MQTT broker. From http://www.mqtt-dashboard.com/

[74] C++ Micro Services. From http://cppmicroservices.org/

[75] Open Services Gateway initiative Alliance. https://www.osgi.org/

[76] Eclipse Wakaama. From https://www.eclipse.org/wakaama

[77] Wakaama implementation of the Open Mobile Alliance’s lightweight M2M. From

https://github.com/eclipse/wakaama

[78] LightweightM2M editor for OMA objects and resources. From

http://devtoolkit.openmobilealliance.org/OEditor.

[79] LwM2M XML Schema from Editor schema. From

http://technical.openmobilealliance.org/tech/profiles/LWM2M.xsd.

[80] HiveMQ MQTT Dashboard. From www.mqtt-dashboard.com/

[81] CoAP implementation by Noisy Atom. From https://noisyatom.com/examples/cpp-coap-

library/

[82] Libcurl—The multiprotocol file transfer library. https://curl.haxx.se/libcurl/

[83] DISCO Compute Semantic Similarity between words,

http://www.linguatools.de/disco/disco_en.html

[84] P. (2008). Disco: A multilingual database of distributionally similar words. Proceedings of

KONVENS-2008, Berlin, 156.

[85] PowerJive USB Voltage/Amps power meter.

http://www.measuringsupply.com/artifact/1402679/

[86] M. Katagi and S. Moriai. 2008. Lightweight cryptography for the Internet of Things. Sony

Corporation, 7-10

183

[87] Gaurav, K., Goyal, P., Agrawal, V., & Rao, S. L. (2015, October). Iot transaction security.

In Proceedings of the 5th International Conference on the Internet of Things (IoT 2015).

[88] Ebrahim, M., Khan, S., & Khalid, U. B. (2014). Symmetric algorithm survey: a comparative

analysis. arXiv preprint arXiv:1405.0398.

[89] Thakur, J., & Kumar, N. (2011). DES, AES and Blowfish: Symmetric key cryptography

algorithms simulation based performance analysis. International journal of emerging

technology and advanced engineering, 1(2), 6-12.

[90] Crypto Library of cryptographic schemes. https://www.cryptopp.com

[91] Eclipse Ponte. http://www.eclipse.org/ponte/

[92] J. King, R. Bose, H. Yang, S. Pickles and A. Helal (2006). Atlas – A Service-Oriented

Sensor Platform. Proceedings of the first IEEE International Workshop on Practical Issues

in Building Sensor Network Applications (SenseApp 2006). Tampa, Florida, 2006.

[93] de Deugd, S., Carroll, R., Kelly, K., Millett, B., & Ricker, J. (2006). SODA: Service

oriented device architecture. IEEE Pervasive Computing, 5(3), 94-96.

[94] Android Developer System Class.

https://developer.android.com/reference/java/lang/System.html#nanoTime()

[95] Linux User Manual for Time. http://man7.org/linux/man-pages/man1/time.1.html

[96] Android Developer Runtime Class.

https://developer.android.com/reference/java/lang/Runtime

[97] Android Developer BatteryManager Class.

https://developer.android.com/reference/android/os/BatteryManager

[98] Dombroviak, K. M., & Ramnath, R. (2007, March). A taxonomy of mobile and pervasive

applications. In Proceedings of the 2007 ACM symposium on Applied computing (pp.

1609-1615). ACM.

[99] Nickerson, R., Muntermann, J., Varshney, U., & Isaac, H. (2009). Taxonomy development

in information systems: Developing a taxonomy of mobile applications. In European

conference in information systems.

[100] Heinonen, K., & Pura, M. (2006). Classifying mobile services. Helsinki Mobility

Roundtable, 1-2.

[101] Kennedy-Eden, H., & Gretzel, U. (2012). A taxonomy of mobile applications in tourism.

184

[102] Lara, O. D., & Labrador, M. A. (2013). A survey on human activity recognition using

wearable sensors. IEEE Communications Surveys and Tutorials, 15(3), 1192-1209.

[103] A. Khaled, W. Lindquist, S. Helal (2018). Service-Relationship Programming

Framework for the Social IoT. The Open Journal of Internet Of Things (OJIOT) and to be

presented in the International Workshop on Very Large Internet of Things (VLIoT 2018) in

conjunction with the 2018 VLDB Conference, Brazil.

185

BIOGRAPHICAL SKETCH

Ahmed E. Khaled received the B.Sc. and M.Sc. degrees in computer engineering from

Cairo University, Egypt in 2011 and 2013, respectively. His current research interests include

Internet of Things (IoT), smart spaces, and ubiquitous computing. His Ph.D. work focused on

architectural designs supportive of creating novel programming models for the social IoT.

Seeking an academic career, he accepted an Assistant Professor position in the Department of

Computer Science at the Northeastern Illinois University, starting in August 2018.