cloud.iO, An Open-source W3C WoT Compliant Framework

Lucas Bonvin

, Dominique Gabioud

and Michael Clausen

Institute of Sustainable Energy, HES-SO Valais-Wallis, Route du Rawil 47, Sion, Switzerland

Institute of Systems Engineering, HES-SO Valais-Wallis, Route du Rawil 47, Sion, Switzerland

Keywords:

IoT, Interoperability, W3C, Web of Things, Thing Description, Cloud, cloud.iO.

Abstract:

The Internet of Things (IoT) is gaining more and more popularity. It is therefore not surprising that the number

of IoT cloud-based solutions grows accordingly. Most of these solutions have their own semantics and syntax,

hence creating a heterogeneous landscape with a lack of interoperability. W3C works on the Web of Things

(WoT) standardization with the goal of bringing interoperability across IoT solutions. This paper presents how

the interoperability of the open-source IoT solution cloud.iO has been enhanced by making it compliant with

the W3C WoT recommendations.

1 INTRODUCTION

The growth of IoT is characterized by an increased

number of connected devices but also by the mul-

tiplication of the cloud platforms in charge of their

connection. According to Postcapes

, more than 152

platforms are available. To this IoT platforms list, we

can add cloud.iO

, an IoT cloud solution developed

by the Institute of Systems Engineering at HES-SO

Valais-Wallis.

The IoT platforms feature a similar structure:

• The current state of connected Things is mirrored

in digital replicas called digital twins.

• The platforms allow applications to monitor and

control Things through their digital twins.

The IoT platforms, however, use proprietary syntax

and semantics to describe the Things’ data model and

to communicate with their twin. Hence, a given ap-

plication is in practice bound to a single platform, as

cross-platform applications need data conversion and

support of multiple APIs. The resulting fragmenta-

tion of the IoT scene limits the development of IoT

based services.

Interoperability between applications and plat-

forms requires compliance with a homogeneous inter-

face deﬁned in a recognized standard. W3C, through

its Web of Things (WoT) Working Group, has the am-

bition to elaborate such a standard. To this end, it

https://www.postscapes.com/internet-of-things-

platforms/

https://github.com/cloudio-project

has already published the architecture for interopera-

ble platforms in a candidate recommendation.

This paper describes how cloud.iO has been com-

pleted to become compliant with the W3C’s WoT ar-

chitecture.

The structure of this paper is the following: Sec-

tion 2 presents the concept of interoperability in an

IoT environment; Section 3 describes the W3C WoT

vision; Section 4 introduces cloud.iO; Section 5 ex-

plains how cloud.iO was upgraded to become WoT

compliant. Finally, Section 6 concludes this paper

with perspectives on future work.

2 INTEROPERABILITY

Interoperability is the ability of systems and devices

to provide services to and use services from other

systems or devices, so as to enable them to operate

effectively together. IoT interoperability appears in

many contexts like device to device, device to plat-

form, platform to application, and application to ap-

plication. In this paper, the ability for a compliant ap-

plication to be interoperable with compliant platforms

is addressed. The vision is to allow an application to

address IoT devices connected through different plat-

forms without ad hoc adapters.

Interoperability is deﬁned at two levels:

• Syntactic Level: interoperable systems agree on

the format and sequence of exchanged messages.

• Semantic Level: interoperable systems exchange

Bonvin, L., Gabioud, D. and Clausen, M.

cloud.iO, An Open-source W3C WoT Compliant Framework.

DOI: 10.5220/0009470604050411

In Proceedings of the 5th International Conference on Internet of Things, Big Data and Security (IoTBDS 2020), pages 405-411

ISBN: 978-989-758-426-8

405

data with unambiguous, shared meaning. Seman-

tic interoperability may apply to IoT speciﬁc con-

cepts (e.g.”event” or ”action”) or domain-speciﬁc

concept (energy, health ...).

Both the W3C architecture and cloud.iO have sup-

port for domain-speciﬁc semantics. However, this as-

pect is not the focus of this paper.

The targeted interoperability is illustrated in Fig-

ure 1. In this example, two applications can inter-

act with Things connected through three platforms

because all components implement the digital twin

interface. On the other hand, the two applications

can interact together to share access to their Things

through their digital twins. These interactions are

possible since both applications understand the nor-

malized syntax of the digital twins.

Figure 1: Interoperability between applications and IoT

platforms.

Different projects have addressed the application -

platform interoperability question. symbIoTe (

Zarko

et al., 2019) provides an abstraction layer to harmo-

nize IoT platforms. Compliant platforms can reg-

ister their resources to symbIoTe. Applications can

then discover resources using the symbIoTe semantic

search engine and later on access them in a homo-

geneous way. symbIoTe recognized the importance

of standardization since its Core Information Model

is based on the Semantic Sensor Network Ontology,

a W3C recommendation, and on the OGC Sensor-

Things API.

Another project proposing interoperability for IoT

is BIG IoT (Jell et al., 2017). BIG IoT’s goal is to

build an IoT ecosystem with multiple IoT platforms,

services, and applications through the deﬁnition of a

uniform platform interface known as BIG IoT API.

The BIG IoT API and its information models have

been built in collaboration with the W3C’s Web of

Things Interest Group.

These projects and others paved the way for in-

teroperability. However, large-scale deployment re-

quires a stable interface deﬁnition backed by a recog-

nized standardization body like W3C.

3 WEB OF THINGS

The W3C standardization work related to IoT is held

by the Web of Things (WoT) Interest Group (WoT

IG) and the Web of Things Working Group (WoT

WG). The latter has released two candidate recom-

mendations: the Web of Things (WoT) Architecture

(Kovatsch et al., 2019) and the Web of Things (WoT)

Thing Description (Kaebisch et al., 2019).

The WoT architecture is made up of four building

blocks:

• The WoT Thing Description deﬁnes an informa-

tion model for Things based on a semantic vo-

cabulary and a serialized representation based on

JSON.

• The WoT Binding Templates specify syntactic

and protocol-related information for Thing ac-

cess.

• The WoT Scripting API proposes a program-

ming interface that allows applications to dis-

cover, fetch, consume, produce, and even expose

WoT Thing Descriptions.

• The WoT Security and Privacy recommendation

provides security-related guidelines for all com-

ponents.

The main concepts of the WoT architecture are ex-

plained in this paragraph. A normalized digital twin

is called a Thing and is deﬁned as “the abstraction of

a physical or virtual entity (...) described by standard-

ized metadata”. The latter are registered in a JSON

formatted Linked Data document named Thing De-

scription (TD). The entity interacting with a TD is

called a Servient. It is deﬁned as a software com-

ponent that implements one or many WoT building

blocks. Servients can be Consumers, which are en-

tities “that can process TDs (...) and interact with

Things”. TDs allow Consumers “to identify what ca-

pabilities a Thing provides and how to use the pro-

vided capabilities” (Kovatsch et al., 2019). Inter-

action Affordances link the “what” and the “how”

for each capability. “Whats” are named Interac-

tions, whereas “hows” are Protocol Bindings follow-

ing WoT Binding Templates.

3.1 Things Description (TD)

A TD is basically a collection of Interaction Affor-

dances. Three types of Interactions sufﬁce to model

nearly all Interactions found in IoT devices and ser-

vices:

• A Property describes a state of a Thing. A Con-

sumer can read it and possibly also write it.

IoTBDS 2020 - 5th International Conference on Internet of Things, Big Data and Security

406

• An Action refers to a function on a Thing. Invok-

ing an Action can change the state of a Thing.

• An Event describes an asynchronous data ex-

change initiated by a Thing.

The following use case illustrates how a TD pro-

vides access to a Thing representing a smart heating

system with ambient temperature measurement and a

temperature set point. In the TD, both the real and tar-

get temperatures are Properties that can be accessed

by a hypothetical HTTP operation. The heating regu-

lation can be switched on and off. This is represented

by an Action in the TD. Finally, our heating appliance

can detect and announce changes in the ambient tem-

perature. This is transposed as an Event in the TD.

Listing 1 represents a basic TD implementation for

this smart heating system.

{

"@context": "https://www.w3.org/2019/wot/td/v1",

"id": "urn:heater",

"title": "myHeater",

"securityDefinitions": {

"basic_sc": {

"scheme": "basic",

"in": "header"

}

"security": ["basic_sc"],

"properties": {

"temperature": {

"type": "integer",

"forms": [{

"href": "https://myHeater.com/get"

}]

"targetTemperature": {

"type": "integer",

"forms": [{

"href": "https://myHeater.com/set"

}]

}

"actions": {

"toggleRegulation": {

"forms": [{

"href": "https://myHeater.com/toggle"

}]

}

"events": {

"temperatureChange": {

"data": {"type": "integer"},

"forms": [{

"href": "https://myHeater.com/change",

"subprotocol": "longpoll"

}]

}

Listing 1: TD example of a heating system.

Apart from the Interaction Affordances, a TD

must contain four mandatory JSON objects all present

in Listing 1: @context, title, security, and

securityDefinitions. @context is a JSON-LD

speciﬁc name whose corresponding value refers to

the TD ontology deﬁnition. The title ﬁeld pro-

vides a human-readable title to the Thing. Finally, the

security object refers to securityDefinitions

deﬁned in the TD. To access a resource, the conditions

of the mentioned security deﬁnition must be fulﬁlled.

4 cloud.iO

cloud.iO is a scalable open-source IoT cloud-based

platform developed and maintained by the Institute

of Systems Engineering at HES-SO Valais Wallis.

cloud.iO has been used in several projects, includ-

ing the European FP7 SEMIAH and at the European

Horizon 2020 GoFlex projects (Roduit et al., 2019)

for monitoring and control of energy and heating in

hundreds of buildings.

cloud.iO provides the following services:

• Property Access: Things properties can be read

and written using different models.

• Directory: The list of Things with their informa-

tion model can be browsed and searched.

• Historian: The history of Things’ properties is

made available.

• Remote Job Execution: Things local tasks can be

started remotely.

cloud.iO also lets Things owners deﬁne privacy

rules for their Things down to the property level.

4.1 Roles

cloud.iO deﬁnes two roles: Endpoint and User.

An Endpoint is an IoT device hosting one or

more Things. Each Endpoint has its own informa-

tion model, published, stored, and made available in

the cloud. An Endpoint sends messages to the cloud

upon status changes of hosted Things. Conversely,

Things’ properties can be remotely modiﬁed by in-

coming messages. Every change on Things properties

is stored in a time-series database.

Users are Endpoints owners. In the cloud.iO

ecosystem, a User is indifferently a real person or

an application. A User has full access on its Things’

properties and may delegate read or read/write access

for a given property to another User.

Users may:

cloud.iO, An Open-source W3C WoT Compliant Framework

407

• Browse and search a Thing information model di-

rectory,

• Monitor and control Endpoints in real-time,

• Access Endpoints’ past states (historian) through

ﬁltering, and

• Request the execution of jobs on Endpoints.

4.2 Architecture

The core of cloud.iO is composed of two open-

source frameworks: the application for micro-

services Spring

and the message broker RabbitMQ

cloud.iO is made up of a set of independent, mostly

stateless, low-complexity micro-services interacting

through the message broker (see Figure 2). These ar-

chitectural choices - message-driven processing and

micro-services - make cloud.iO a simple, scalable,

and extensible IoT platform.

Figure 2: cloud.iO complete architecture.

Micro-services implement the following func-

tions: database access, Endpoints and Users manage-

https://spring.io

https://www.rabbitmq.com

ment, privacy rules deﬁnition, and REST services im-

plementation.

Endpoints establish a TLS-secure MQTT link

with the message broker. X509 certiﬁcate-based End-

point authentication is mandatory. High-level Java

and Python Endpoint libraries are provided for efﬁ-

cient Endpoint development.

Users can interact with Things either through mes-

saging (AMQP, MQTT) or through a RESTful API.

4.3 Endpoint Data Modeling

Data modeling in cloud.iO is based on three concepts:

1. An Attribute represents an atomic property of a

Thing (e.g. a numerical value).

2. An Object is a collection of Attributes forming a

coherent unit (e.g. an analog measurement made

up of Attributes for numerical value, engineering

unit, quality...).

3. A Node is a collection of Objects modeling a sub-

system of an Endpoint.

The cloud.iO data model is represented in the

UML class diagram of Figure 3.

Attribute

type: AttributeType

constraint: AttributeConstraint

timestamp: Double

value: Any

Object

objectLabel

Node

nodeLabel

Endpoint

Uuid

1..n

Figure 3: cloud.iO class diagram for an Endpoint.

cloud.iO Objects in an Endpoint have a tree-

shaped structure, with Attributes as leaves.

The elements composing a Node or an Object can

be either freely deﬁned or comply with a semantic

data model speciﬁc to an application domain.

IoTBDS 2020 - 5th International Conference on Internet of Things, Big Data and Security

408

A cloud.iO Attribute contains four ﬁelds. The

Type ﬁeld indicates the format of the Value ﬁeld by

reference to a JSON type (Boolean, integer, number,

string). Values are associated with a Timestamp in

epoch format. Finally, the Constraint ﬁeld deﬁnes the

category of the Attribute, and indirectly its read / write

access mode. A Constraint may take one of the ﬁve

following value:

• Static: Read-only, static value.

• Status: Read-only, computed value.

• Measure: Read-only, measurement result ac-

quired by a sensor on a physical process.

• Parameter: Read/write, conﬁguration parameter

acting on the Endpoint’s behavior. Persists after

reboot.

• SetPoint: Read/write, target value for an actuator,

non-persistent.

Endpoints feature globally unique identiﬁers

(UUIDs). Nodes, Objects, and Attributes have each

a label with a local scope. Consequently, each At-

tribute can be referred to by a full label obtained by

the concatenation of the names of its containing ele-

ments.

Listing 2 presents the cloud.iO data model for

a Node modeling the above-described heating sys-

tem. The myHeater Node contains a single Object

(temperatures) with two Attributes representing the

instantaneous ambient temperature (Measure) and the

target temperature (SetPoint).

{

"myHeater": {

"implements": [],

"objects": {

"temperatures": {

"conforms": null,

"objects": {},

"attributes": {

"temperature": {

"constraint": "Measure",

"type": "Integer",

"timestamp": 1.57476099056E9,

"value": 25

"targetTemperature": {

"constraint": "SetPoint",

"type": "Integer",

"timestamp": 1.57476098001E9,

"value": 24

}

Listing 2: Digital twin of cloud.iO Node.

4.4 cloud.iO Operation

Attributes can be classiﬁed in two overlapping cate-

gories: readable Attributes and writable Attributes.

An Endpoint monitors its readable Attributes lo-

cally. Any signiﬁcant change of a value triggers the

emission of an MQTT message with a topic con-

taining the Attribute’s full label and a message body

made up of the JSON representation of the Attribute’s

ﬁelds. Conversely, a write operation on an Attribute is

triggered by the reception of an MQTT message with

a similar structure.

Users can perform read operations on Attributes

(HTTP) and write operations on Attributes (MQTT,

HTTP). They can also subscribe to Attributes updates

and be notiﬁed on Attribute changes (MQTT, HTTP

long poll).

5 cloud.iO AND WEB OF THINGS

The cloud.iO data model is ﬂexible enough to repre-

sent the digital twin of any Thing. However, as it is

speciﬁc to cloud.iO, applications (Users) must also be

cloud.iO speciﬁc. Hence application - platform inter-

operability as deﬁned in Section 2, is not ensured. To

open the cloud.iO platform to WoT compliant appli-

cations, cloud.iO data models must be translated into

WoT TDs. Figure 4 illustrates a micro-service hosting

and exposing a WoT Thing for an application acting

as Consumer.

Thing

WoT Servient

WoT Thing

Description

Expose

Application

WoT Servient

Interact

Consume

TD Consumer

Figure 4: Interaction between cloud.iO and a Consumer.

The core of the translation from cloud.iO data

models to WoT TD is the implementation of the dif-

ferent Interactions Affordances. Those are built ac-

cording to the following guidelines:

• A cloud.iO Node is mapped to a TD Thing.

• A cloud.iO Attribute is mapped to two TD Inter-

actions: one of type Property and a second of type

Event.

cloud.iO, An Open-source W3C WoT Compliant Framework

409

• A TD Consumer performs a read or write opera-

tion on a cloud.iO Attribute through its Property

representation.

• A TD Consumer is notiﬁed of a Attribute change

through its Event representation.

Listing 3 presents the Property Affordance related

to the targetTemperature Attribute.

{

...

"properties": {

...

"property-endpointUUID.myHeater.

,→ temperatures.targetTemperature": {

"type": "object",

"properties": {

"constraint": {

"type": "string",

"enum": ["SetPoint"]

"type": {

"type": "string",

"enum": ["Integer"]

"timestamp": {"type": "number"},

"value": {"type": "number"}

"required": ["constraint", "type", "

,→ timestamp", "value"],

"forms": [{

"href": "https://cloud.iO:8081/api/

,→ v1/getAttribute/endpointUUID.myHeater.

,→ temperatures.targetTemperature",

"op": "readproperty",

"contentType": "application/json"

{

"href": "mqtts://cloud.iO:8883/@set/

,→ endpointUUID/myHeater/temperatures/

,→ targetTemperature",

"op": "writeproperty",

"contentType": "application/json"

{

"href": "https://cloud.iO:8081/api/

,→ v1/setAttribute/endpointUUID.myHeater.

,→ temperatures.targetTemperature",

"op": "writeproperty",

"contentType": "application/json"

}]

}

...

}

Listing 3: Property Affordance of heating System target

temperature.

Listing 4 shows the Event Affordance (linked to

the targetTemperature Attribute).

{

...

"events": {

...

"event-endpointUUID.myHeater.temperatures.

,→ targetTemperature": {

"data": {

"type": "object",

"properties": {

"constraint": {

"type": "string",

"enum": ["SetPoint"]

"type": {

"type": "string",

"enum": ["Integer"]

"timestamp": {"type": "number"},

"value": {"type": "number"}

"required": ["constraint", "type", "

,→ timestamp", "value"]

"forms": [{

"href": "https://cloud.iO:8081/api/v1/

,→ notifyAttributeChange/endpointUUID.

,→ myHeater.temperatures.targetTemperature

,→ ",

"op": "subscribeevent",

"subprotocol": "longpoll",

"contentType": "application/json"

{

"href": "mqtts://cloud.iO:8883/@set/

,→ endpointUUID/myHeater/temperatures/

,→ targetTemperature",

"op": "subscribeevent",

"contentType": "application/json"

}]

}

Listing 4: Event Affordance of heating System target

temperature.

Generating a TD from a cloud.iO data model is a

four-step process:

1. One Thing per cloud.iO Node is created, with the

Node’s full label as TD ﬁeld id.

2. Two Interaction Affordances per cloud.iO At-

tributes are created. Both contains the Attribute’s

full label in their key of Interaction Affordance

map.

3. The (unique) schema for an Attribute is associated

to each Interaction.

4. cloud.iO Attributes access deﬁnition, which is im-

plicit in cloud.iO data models, is made explicit as

WoT Protocol Bindings.

IoTBDS 2020 - 5th International Conference on Internet of Things, Big Data and Security

410

Native and TD based cloud.iO services are equiv-

alent. Note that cloud.iO was made WoT compliant

just by translating its native data model into a TD.

Access to Endpoint resources did not require changes

as it could be expressed by legacy TD Interaction Af-

fordance.

6 CONCLUSION

In this article, we presented how cloud.iO has been

upgraded to become a platform compliant with the

W3C Web of Thing Candidate Recommendations.

We applied the principle of a WoT Servient to

cloud.iO by implementing one of the WoT building

blocks: the Thing Description.

The implementation consisted of an automated

translation of its native data model to a WoT TD docu-

ment: cloud.iO Attributes were converted into TD In-

teraction Affordances and, by doing so, exposing the

cloud.iO API. This straightforward conversion high-

lights the fact that an existing IoT cloud-based plat-

form can be retroﬁtted with a limited effort.

6.1 Future Work

First, new versions of the still evolving WoT can-

didate recommendation will be implemented in the

cloud.iO platform, thus turning it into a test and val-

idation platform for the WoT architecture. Secondly,

we intend to deploy an interoperability test bed where

applications interact with several WoT compliant IoT

platforms. Finally, the TDs will be complemented

with an application level ontology like SAREF

REFERENCES

Zarko, I. P., Mueller, S., Płociennik, M., Rajtar, T., Jacoby,

M., Pardi, M., Insolvibile, G., Glykantzis, V., Antoni

A., Ku

sek, M., and Soursos, S. (2019). The symbiote

solution for semantic and syntactic interoperability of

cloud-based iot platforms. In 2019 Global IoT Summit

(GIoTS), pages 1–6.

Jell, T., Br

oring, A., and Mitic, J. (2017). Big iot – intercon-

necting iot platforms from different domains. In 2017

International Conference on Engineering, Technology

and Innovation (ICE/ITMC), pages 86–88.

Kaebisch, S., Kamiya, T., McCool, M., Charpenay, V., and

Kovatsch, M. (2019). Web of Things (WoT) Thing

Description. Retrieved November 25, 2019, from

https://www.w3.org/TR/wot-thing-description/.

https://ontology.tno.nl/saref/

Kovatsch, M., Matsukura, R., Lagally, M., Kawaguchi, T.,

Toumura, K., and Kajimoto, K. (2019). Web of Things

(WoT) Architecture. Retrieved November 25, 2019,

from https://www.w3.org/TR/wot-architecture/.

Roduit, P., Gabioud, D., Basso, G., Maitre, G., and Ferrez,

P. (2019). cloud.io: A decentralised iot architecture to

control electrical appliances in households. In Don-

nellan, B., Klein, C., Helfert, M., and Gusikhin, O.,

editors, Smart Cities, Green Technologies and Intelli-

gent Transport Systems, pages 67–89, Cham. Springer

International Publishing.

cloud.iO, An Open-source W3C WoT Compliant Framework

411