Introduction to the Web of Things

Victor Charpenay

Outline

  1. Sensors and Actuators
  2. The Idea of a Web of Thing
  3. Representational State Transfer
  4. The W3C Thing Description Model
  5. Semantics for the Web of Things
  6. Affordance Selection and Planning

Sensors and Actuators

The Web of Things is the latest emergence of a long-lasting field of research.

The Web of Things' past; source: (Matthias Kovatsch, 2020)
  • 1948 Cybernetics
  • 1993 Ubiquitous Computing
  • 1998 Ambient Intelligence
  • 2000 Wireless Sensor Networks
  • 2000 Internet of Things
  • 2001 Pervasive Computing
  • 2007 Cyber-Physical Systems
  • 2009 Web of Things

Cybernetics: Science related to the automatic control of systems in a broad sense, from industrial systems to living organisms.

Ubiquitous & Pervasive Computing, Ambient intelligence: Methods of computation that aim at making computing transparent to users as well as aware of the user's environment through autonomous perception.

Mobile applications using GPS traces inherit from that field of research.

Wireless Sensor Networks: Network that take advantage of the availability of cheaper and smaller computational devices.

See e.g. TinyOS and Contiki.

Internet of Things: World-scale network that takes advantage of the availability of Radio-Frequency Identification (RFID) and other sensing technologies.

The term "Internet of Things", introduced by Kevin Ashton, first targeted product tracking in supply chains.

Cyber-Physical (Production) Systems: Systems of arbitrary size combining control components and physical equipment.

A CPS can be defined at the level of an entire supply chain.

Projection of the ISA-95 automation pyramid onto a Service-Oriented Architecture (SOA); source: cited by (Monostori, 2014)
The 5C model for CPSs; source: (Lee et al., 2015)

What, then, is a Thing in the Web of Things?

Any physical object coupled with a computational device or system of any size can be regarded as a Thing.

See device categories listed in the WoT architecture specification.

The Web of Things addresses the main technical problem that comes with increasing numbers of computational devices: interoperability.

The Idea of a Web of Things

"Every kind of thing can have its own kind of reason for being a thing." — Patrick Hayes (Hayes, 1983)

A single Web client can combine heterogeneous Things to build application mashups.

First proposal for a Web of Things; source (Wilde, 2007)
Example of application mashup on an air conditioner; source: (Kovatsch et al., 2015)
source: (Kovatsch et al., 2015)

Build from source code and try it out yourself.

Example of application mashup on a production line; source: (Mayer et al., 2016)
source: (Mayer et al., 2016)

See a similar process with human-machine collaboration in action.

The Web client executes an application mashup as a series of HTTP operations. 

PUT /pwr/switch HTTP/1.1
Host: device.local
ON
PUT /ac/mode HTTP/1.1
Host: device.local
AUTO
PUT /ac/vent HTTP/1.1
Host: device.local
12
POST /fahrenheit2celsius HTTP/1.1
Host: converter.com
83
PUT /ac/target HTTP/1.1
Host: device.local
25
HTTP operations for the air conditioner example
POST /pick-and-place HTTP/1.1
Host: ur5-robot.local
Content-Type: application/json

{ "from": [6, 5.4], "to": [2.4, 7] }
POST /jobs HTTP/1.1
Host: fan-heater.local
Content-Type: application/json

{ "duration": 10 }
POST /pick-and-place HTTP/1.1
Host: ur5-robot.local
Content-Type: application/json

{ "from": [2.4, 7], "to": [2.4, 2] }
POST /move-from-to HTTP/1.1
Host: plcbot.local
Content-Type: application/json

[ [2.4, 2], [5.1, 2] ]
POST /turn-on HTTP/1.1
Host: fan.local
Content-Type: text/plain

20
HTTP operations for the production line example

Various organizations have their own Web APIs for Things:

Find more Web APIs for the IoT in one of the OpenAPI catalogs.

How would you design a Web API for any Thing?

A minimal Web Thing API was proposed in 2015, to update a Thing's properties, invoke its actions and subscribe to its notifications.

HTTP Method Resource
GET {wt}
GET {wt}/model
GET {wt}/properties
GET, PUT {wt}/properties/{id}
GET {wt}/actions
GET, POST {wt}/actions/{id}
GET, PUT, DELETE {wt}/actions/{id}/{actionId}
GET, POST {wt}/subscriptions
Web Thing API; source: (Trifa et al., 2015)

What operations of the Web Thing API are also available in previously defined APIs?

Defining a Web interface to Things does not solve all interoperability problems between Things and clients, though.

  1. Can some Thing of any size interoperate with any other device?
    Embedded Web
  2. Can clients execute mashups without prior knowledge of the Things?
    Semantic Web of Things (SWoT)

Representational State Transfer

Representational State Transfer (REST) is a set of architectural constraints for "network-based software" (Fielding, 2000).

  1. client-server architecture
  2. stateless communication
  3. cache
  4. uniform interface
  5. layered system
  6. (code-on-demand)

The REST constraints have conditioned much of HTTP/1.1, including:

  • Cookies and session tokens
  • Cache control
  • Content negotiation
  • Proxies and reverse proxies

The uniform interface constraint is specific to REST (and the Web).

What are the main pillars of the architecture of the Web?

  1. Identification with URIs
  2. Interaction with HTTP
  3. Data Formats incl. hypermedia controls

These are the main sections of the 2004 reference specification: Architecture of the World Wide Web.

These pillars translate into 4 sub-constraints in REST:

  1. identification of resources
  2. manipulation of resources through representations
  3. self-descriptive messages
  4. hypermedia as the engine of application state (HATEOAS)

Linked Data interfaces are RESTful by construction.

Navigation graph built from browsing history
Part of navigation graph for an integrated hypermedia ecosystem (emse.fr)

You can render your own navigation graph with the Web Navigation Window browser extension (available for Chrome and for Firefox).

How to design cyber-physical systems that are not RESTful?
  • Remote procedure calls are e.g. not stateless.
  • Publish-subscribe has no mechanism for resource manipulation (in the general case).

Try to design a non-RESTful architecture for the production line mash-up (last section).

Web clients can do hypermedia navigation by following links and submitting forms.

Web clients can discover properties exposed by Thing as links.

Web clients can discover actions exposed by Things as forms. 

GET / HTTP/1.1
Host: device.local
HTTP/1.1 200 OK
Content-Type: application/json

[{ "@type": "Link", "href": "http://device.local/pwr", "rel": "ssn:hasSubSystem" },
 { "@type": "Link", "href": "http://device.local/ac", "rel": "ssn:hasSubSystem"  }]
GET /pwr HTTP/1.1
Host: device.local
HTTP/1.1 200 OK
Content-Type: application/json

[{ "@type": "Link", "href": "http://device.local/pwr/switch", "rel": "ssn:hasProperty" }]
GET /ac HTTP/1.1
Host: device.local
HTTP/1.1 200 OK
Content-Type: application/json

[{ "@type": "Link", "href": "http://device.local/ac/mode", "rel": "ssn:hasProperty" },
 { "@type": "Link", "href": "http://device.local/ac/vent", "rel": "ssn:hasProperty" },
 { "@type": "Link", "href": "http://device.local/ac/target", "rel": "ssn:hasProperty" }]
Hypermedia-driven discovery of available properties for the air conditioner example
GET / HTTP/1.1
Host: ur5-robot.local
HTTP/1.1 200 OK
Content-Type: application/json

[{ "@type": "Form", "href": "http://ur5-robot.local/pick-and-place", "op": "td:invokeAction" }]
POST /pick-and-place HTTP/1.1
Host: ur5-robot.local
Content-Type: application/json

{ "from": [6, 5.4], "to": [2.4, 7] }
HTTP/1.1 201 Created
Location: http://ur5-robot.local/pick-and-place/invocation1

[no content]
Hypermedia-driven discovery of available actions for the production line example

The dominant protocol on the IoT is MQTT. Could REST principles be applied to MQTT?

What would be needed for MQTT to become RESTful is:

  • a URI scheme
    (an unofficial scheme exists)
  • request-response interactions
    (available in MQTT v5)
  • a hypermedia data format
    (say, RDF)

REST over MQTT would allow for large-scale asynchronous communication between clients and servers.

An extension to REST integrates further asynchronous operations to REST: A+REST.

In REST over MQTT, clients can only receive a single response after a request on some resource.

In A+REST, clients can watch the resource, receiving arbitrarily many notifications that the resource representation has changed.

A+REST was first described in (Khare, 2004).

CoAP, the Constrained Application Protocol embraces the A+REST architectural style, with the OBSERVE flag on GET operations.

The Hypermedea agent framework also follows the principles of A+REST.

The W3C Thing Description Model

The World Wide Web Consortium (W3C) has initiated a standardization effort to facilitate automated mashups based on semantic descriptions of Things.

What do existing standards such as OpenAPI lack to describe WoT Things?

A translation from W3C WoT Thing Descriptions to OpenAPI and AsyncAPI exists.

But there is no standard that captures both synchronous and asynchronous operations, as in A+REST.

See playground.thingweb.io for examples with OpenAPI and AsyncAPI.

REST is (theoretically) independent of the communication protocol.

A WoT standard should target as many IoT and industrial protocols as possible.

  • CoAP (is used e.g. by oneM2M and OMA LWM2M)
  • MQTT (is the de facto IoT protocol)
  • Modbus (is important in industry automation)
  • BACnet (is important in building automation)
  • ...
publicly available Modbus and BACnet devices; source: censys.io

Two more examples:

  • The IT'm factory in Saint-Étienne has a (TCP) OPC-UA interface only.
  • The Espace Fauriel building in Saint-Étienne has an automation system (from 1991) with a KNX interface only.

The W3C Web of Things working group has thus decided to:

  1. capture abstract REST principles in the Thing Description model
  2. provide a mechanism for providing various protocol bindings

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

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

Semantics for the Web of Things

The Open Geospatial Consortium (OGC) first used the Web to publish sensor measurements in a unified manner.

source: (Botts et al., 2013)

The OGC Simple Observation Service (SOS) offers sensor observations and measurements in a standard XML format (O&M). 

<om:OM_Observation gml:id="obsTest1">
  <om:phenomemonTime>
    <gml:TimeInstant>
      <gml:timePosition>2010-03-08T16:22:25.00</gml:timePosition>
    </gml:TimeInstant>
  </om:phenomemonTime>
  <om:observedProperty xlink:href="http://sweet.jpl.nasa.gov/2.0/hydroSurface.owl#WaterHeight"/>
  <om:result uom="cm">28</om:result>
</om:OM_Observation>

Example of an O&M observation in XML; source: opengis.net

SOS, O&M and other OGC standards are collectively referred to as the Sensor Web Enablement (SWE) framework.

SWE then combined with Semantic Web technologies has become the Semantic Sensor Web.

The Semantic Sensor Web has led to the standardization of the Semantic Sensor Network (SSN) ontology.

O&M instances extended with other semantic models; source: (Seth et al., 2008)
SOS is enriched with semantic annotations; source: (Seth et al., 2008)

On the Semantic Sensor Web, inference rules are used to enrich sensor observations may.

Such inference rules may be relatively simple. 

	Observation(?obs) &
	described(?obs, ?weather) &
	FreezingCondition(?weather) &
	HighWindCondition(?weather) &
	SnowCondition(?weather) & 
		=> BlizzardCondition(?weather)

Example of inference rule for weather monitoring; source: (Seth et al., 2008)

Key is not the complexity of inference but the completeness of the knowledge.

Hence, the idea of ubiquitous computing.

Now, what about
an "Actuator Web Enablement"?

Now, what about
a "Thing Web Enablement"?

There is no standard Web model to specify the effects of an actuation.

It is however possible to provide semantics to Things by publishing Thing Models to online repositories.

See the WoT catalogue for a list of model repositories.

Affordance Selection and Planning