This document describes architecture on Web of Things which derived from use cases. The architecture consists of building blocks and the function of each block is explained. And it is also described how to map the WoT architecture to the wide variety of real implementation patterns.

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

Please contribute using Git or the GitHub edit feature.

Introduction

This document is an explanation about the architecture of “Web Of Things (WoT)”.
The purpose of this document is to provide
(a)  a guideline of the mapping between functional architecture and physical devices configuration,
(b)  a description of the role and functionality of each logical module,
(c)  a reference for where should be standardized.

Terminology

This document uses the following terms defined elsewhere.

CoAP
Acronym for Constrained Application Protocol [[!RFC7252]]
WoT Servient
An entity consists of Web client, Web server, and device control capabilities.
WoT Server
An entity consists of Web server and device control capabilities.
WoT Client
An entity consists of Web client and/or device control capability that would be realized in Web browser.
Local Discovery
A discovery method which discover in local networks (e.g. SSDP, mDNS/DNS-SD, ...).
Nearby Discovery
A discovery method where the physical location is considered (BLE, Audio Watermarking, ...).
Remote Discovery
A discovery method which lookup in WoT directories. The end point of the directory must be supported.
Client API
Programming interface that allows scripts to access web client or directly attached hardware through a Physical API depending on the discovery.
Server API
Programming interface that allows scripts to access web server.

Requirement for functional architecture of WoT

Flexibility

There is a wide variety of Physical devices configuration for WoT implementations.
Functional WoT architecture should be able to be mapped to and cover all of the variations.

Compatibility

We have already had many legacy IoT solutions and IoT standardization activities in many business fields.
Functional WoT architecture should provide bridge between legacy IoT solutions and Web technology based on WoT concepts. And it should guarantee to be upper compatible to legacy IoT solutions and current standards.

Safety and Security

Functional WoT architecture should have the room for providing safety and security functionalities.
In the IoT solutions, once cyber security barrier is hacked, it is more easily led to safety issues than conventional web solutions. That is because hacked IoT devices often treat heal cycle such as central heating systems, physical moving devices such as cars.

General Description of WoT Servient

In Web of Things (WoT), functional virtual device is named “WoT Servient” which provides the access to, control and get the status and values from IoT physical devices.
General WoT Servient functional architecture is presented in Fig.1

Functional Architecture of WoT Servient

Fig.1 Functional Architecture of WoT Servient

The role and functionality of each module is as follows;

Server Connector

server Connector accepts requests from networked clients through internet and sends responses to clients.

Examples of protocols between WoT servient and clients include HTTP, CoAP, MQTT and so on.
REST style API can be defined in front of the Server Connector module. This API is named “WoT Interface”. WoT Interface is the subject of the standardization activity.

Client Connector

WoT Servient can access other web servers and/or WoT servients through internet.
In these cases a Client Connector module communicates with other servers via protocols such as HTTP.
When Client Connector modules calls other WoT servients not legacy web servers, the API is provided through WoT Interface.

Legacy Communication

As described before, currently, there are many IoT services and standards proposed by many organizations.
In order to communicate such legacy devices, WoT servient includes legacy communication module for such protocols as Echonet Lite, QNX, ONVIF, DLNA and so on.
Legacy Communication inludes proprietly protocol binding mechanism and resource management defined by each protocol managing organizations.

Protocol Binding

Protocol Binding block converts interactions with devices using information in Things Description in accordance with lower layer protocols such as HTTP, CoAP, MQTT and so on.

Resource Model

Resource Model Provides a common abstraction across the different protocols.
Just like the Web, it allows to identify and address interaction points with URIs.

Things Description

Things Description declares providing API name, parameter type and so on.
External client refers this description to call WoT Interface.

App Script

AppScripts implements application logic in a modular and portable way.
It can access local hardware, locally connected legacy devices, and remote things through the WoT Interface.
For this, the runtime environment must provide the Scripting API (Client, Server, Discovery and Proprietly(if any)).

Runtime Environment

Runtime Environment provides the Scriptiong API
Sever API is the API for creating server functions which accepts request through WoT Interface from other clients.
Client API is the API for creating client functions which utilizes resource model, protocol binding and so on. Client API sometimes includes Physical API to manpulate I2C etc.
Discovery API is utility API to discover other Servers and/or WoT Servients.

Deployment Scenarios

Scenarios utilizing WoT Servient, WoT Server and WoT Client are showed in this section. Each of the scenarios also has explanation of how the discovery and APIs work.

WoT server on device

The first example is WoT server on device as depicted in Fig.2.
In this case, an electronic appliance such as an air conditioner with web server functionality connected directly to local home network. Then a remote controller with WoT client which is realized by a browser application or native application can access the air conditioner through local home network directly.

wot_device

Fig.2 WoT server on device

Discovery:
- WoT client discovers WoT servient locally [Local discovery].

APIs:
- WoT server exposes Server API.
- Script in WoT client accesses WoT server with REST or Client API through IP-based network.

WoT client on Smartphone

The second example is WoT client on Smartphone as shown in Fig.3.
In this case, a browser on smartphone is expanded to include WoT client functionality that can directly or remotely control the air conditioner depending on the network. Wi-Fi or Bluetooth/BLE connection of the smartphone is used for the direct control and cellular network of the smartphone is used for the remote control.

smartphone

Fig.3 WoT client on Smartphone

Discovery:
- WoT client discovers Electronic appliance nearby when the remote controller is placed inside [nearby discovery].
- WoT client discovers WoT servient remotely when the remote controller is placed outside [remote discovery].

APIs:
- Script on WoT client accesses electronic appliances nearby with Client API through physical interface.
- WoT servient exposes Server API.
- Script on WoT client accesses WoT servient with REST or Client API through IP-based network when the remote controller is placed outside.

WoT servient on Smart Home Hub

Fig.4 shows an example of WoT servient on smart home hub.
In this case, a home hub with WoT servient placed between a home network and the Internet that manages electronic appliances in a house. The home hub controls the electronic appliances when remotely receiving a command from a remote controller with WoT Client such as browser application or native application on a smartphone.

homehub1

Fig.4 WoT servient on Smart Home Hub

Discovery:
- WoT servient discovers Electronic appliances nearby [nearby discovery].
- WoT client discovers WoT servient remotely [remote discovery].

APIs:
- WoT servient exposes Server API and Client API. The client API in WoT servient allows script to access Electronic appliances through physical interface.
- WoT client API in WoT client accesses WoT servient with REST or Client API through IP-based network.

WoT servient on Cloud Server

WoT servient on Cloud Server has several variants as follows.

Smart home: WoT device

Fig.5 shows an example of WoT servient on cloud server that controls a WoT device.
WoT servient on cloud serves as device shadows of electric appliances. Then WoT servient controls the appliances when receiving commands from WoT client such as browser or application on a smartphone.

wot_servient_on_cloudserver1

Fig.5 WoT servient on Cloud Server controls WoT device

Discovery:
- WoT servient discovers WoT server remotely [remote discovery].
- WoT client discovers WoT servient remotely [remote discovery].

APIs:
- WoT servient exposes Server API and Client API. The client API in WoT servient allows script to access WoT server through IP based network.
- WoT server exposes Server API.
- WoT client API in WoT client accesses WoT servient with REST or Client API through IP-based network.

Smart home: Legacy device

Fig.6 shows an example of WoT servient on cloud server that controls a legacy electronic appliance through a home hub.
In this case, WoT servient on cloud cashes properties of electric appliances that a home hub manages and acts as an agent that manages them in the cloud in conjunction with the home hub.

wot_servient_on_cloudserver2

Fig.6 WoT Servient on Cloud Server controls legacy device

Discovery:
- WoT servient1 discovers WoT servient2 remotely [remote discovery].
- WoT servient2 discovers Electronic appliances nearby [nearby discovery].
- WoT client discovers WoT servient1 remotely [remote discovery].

APIs:
- WoT servient1 exposes Server API and Client API. The client API in WoT servient1 allows script to access WoT servient2 through IP based network.
- WoT servient2 exposes Server API and Client API. The client API in WoT servient2 allows script to access Electronic appliances through physical interface.
- WoT client API in WoT client accesses WoT servient1 with REST or Client API through IP-based network.

Smart Factory

Fig.7 shows an example of Smart Factory that utilizes the WoT servient.
In this case, WoT servient 1 and 2 control factory equipment with legacy communication such as RS-485 or EtherCAT. Then WoT servient 3 on the cloud collects data from the WoT servients. Services on WoT servient 3 analyze the data and can provide the dashboard. Users can monitor the dashboard from a browser.
Note that placing the WoT servient on the cloud is not mandatory and the WoT servients would be placed only on the local network because of the security reason.

smartfactory

Fig.7 Smart Factory utilizing WoT Servient

Discovery:
- WoT servient3 discovers WoT servient1 and WoT servient2 remotely [remote discovery].
- WoT servient1 and WoT servient2 discover factory appliances nearby [nearby discovery].

APIs:
- WoT servient3 exposes Server API and Client API. The client API in WoT servient3 allows script to WoT servient1 and WoT servient2 through IP based network.
- WoT servient1 and WoT servient2 expose Server API and Client API. The client API in WoT servient1 and WoT servient2 allows script to access factory appliances nearby.
- Browser monitors WoT servient3 through REST.

Connected Car

Fig.8 shows an example of Connected Car that utilizes the WoT servient.
In this case, WoT servient is placed on a gateway that is connected to car devices through CAN and car navigation system.
Then services on WoT client in the cloud collects data from WoT servient and analyzes the data from cars. The service shows the recommendation to the driver through the car navigation systems.

connectedcar

Fig.8 Connected Car utilizing WoT Servient

Discovery:
- WoT servient discovers car devices nearby [nearby discovery].
- WoT client discovers WoT servient remotely [remote discovery].

APIs:
- WoT servient exposes Server API and Client API. The client API in WoT servient allows script to access car devices through physical interface.
- WoT client API in WoT client accesses WoT servient with REST or Client API through IP-based network.

Thing to Thing control

Fig.9 shows an example of Thing to Thing control that utilizes the WoT servients.
A scenario depicted in Fig.9 is as follows: when a sensor detects room temperature and surpassing the threshold e.g. 25 degree C, control agent issue a command of power-on to an air conditioner.
In this case, a temperature sensor is connected to WoT Servient 1 and control agent that monitor the threshold is also working on the WoT Servient 1. On the other hand the air conditioner is connected to WoT Servient 2 and act as a server that controls the air conditioner.

t2t

Fig.9 Thing to thing control

Discovery:
- WoT servient1 discovers WoT servient2 remotely [remote discovery].

APIs:
- WoT servient1 and WoT servient2 exposes Server API and Client API. The client API in WoT servient1 allows script to access WoT servient2 through IP based network.
- WoT servient2 API exposes Server API and Client API.
The client API in WoT servient2 allows script to access thing through physical interface.

Mapping variations

In real world, there are many variations for mapping logical WoT servient to physical devices structure.
This chapter tries to list up informative mapping samples.

Simple Use case

Simple use case

Fig.10 Simple use case

Fig.10 shows very simple use case such that a browser accessed WoT Servient to get some information of legacy device and/or put some parameters to control legacy device.
In this use case, browser’s App Script refers Things Description of WoT servient and get information of who it is, what kind of APIs it provides.
Then App Script calls client API provided by RunTime Environment and through resource model block and protocol binding block, the request is mapped on internet protocol such as HTTP, CoAP and so on.
The protocol accesses Server Connector block of WoT servient through WoT Interface. After that the request is transferred to App Script in WoT servient through protocol binding block and resource model block.
App Script understands what kind of request comes from browser and according to the request, App Script controls legacy device through Runtime Environment. In Fig.10 case, runtime environment calls legacy communication and access legacy device.

WoT servient on device

WoT Servient on device itself

Fig.11 WoT Servient on device itself

The first example is WoT servient on device itself. This is referred as “WoT Device”.
The right most WoT servient in Fig.11 shows an LED Light which has rich CPU and large memory and provides web server functionality connected directly to internet.
Then the leftmost browser and/or another application on internet can access the LED light through internet directly.

WoT servient on Smartphone

The second example is WoT servient on Smartphone.
Smartphone becomes very popular and it provides gateway functionality which bridges between internet and legacy device without any intermediate hardware.

WoT servient on Smartphone (A)

Fig.12 WoT servient on Smartphone (A)

Fig.12 shows an example of WoT servient on Smartphone. In Fig.12, there are independent 2 software modules, one is browser which has user experience to provide interaction, the the other is WoT servient which might not have any user interface and it provides gateway functionality to access legacy device.

WoT servient on Smartphone (B)

Fig.13 WoT servient on Smartphone (B)

Fig.13 shows another example of WoT servient mapped on smartphone.
In this mapping case, a browser is expanded to include WoT servient functionality. Then there is no need for an app script to call web server block. Instead the client API should be called directly inside.

WoT servient on Smart Home Hub

WoT servient on smart home hub

Fig.14 WoT servient on smart home hub

Fig.14 shows an example of WoT servient on smart home hub.
Smart home hub is usually introduced home automation and/or home energy management solution.
Looking at consumer electronics, there are very wide variety of physical communication format such as WiFi, 802.15.4g, Bluetooth low energy, HDPLC and so on. In order to normalize those variations, almost all home systems introduce a smart home hub.
In Fig.14, WoT servient wraps the difference of communicating legacy devices and provides to other clients a universal devices accessing method.
In home inside, as the communication method between WoT servient on smart home hub and clients, WiFi is usually adopted.

WoT servient on Cloud Server

Client Apps can control devices at home through WoT servient on a Smart Home Hub. But the location of client Apps is restricted within home because physical communication path “WiFi” and/or wired Ethernet between smart home hub and client apps such as browser is limited inside home.
So, controlling devices at home from outside the house, WoT servient from a smart home hub should be mapped to a globally accessible cloud server.

WoT Servient on Cloud Server

Fig.15 WoT Servient on Cloud Server

Fig.15 shows an example of WoT servient on a cloud server.
In Fig.15 case, a browser accesses WoT servient on the cloud Server named “platform”. This WoT servient provides Things Description through internet globally. So, wherever browser user is, he/she can access this WoT servient.
WoT servient on "platform" accepts browser and/or other application’s request through HTTP, CoAP and so on. Then WoT Servient on the cloud server finds out the route to access the WoT servient on a smart home hub. In Fig.15 case, Things Description of WoT Servient on cloud server is mirror of that on the smart home hub.
After finding out the route, WoT Servient on the cloud server transfer browser’s request to WoT Servient on the smart home hub.
After that, the smart home hub processes the request according to Fig.14 case.
In this Fig.15 case, the smart home hub works as
a)    Unifier of very wide variety of legacy communication protocols both in the physical and logical view;
b)    Firewall between internet as WoT Servient on the cloud server and legacy connected devices at home;
c)    Privacy filter which substitutes real image and/or speech, and logs data at home to symbols;
d)    Autonomous WoT Servient which provides house inside the server, even if the connection is shut down between internet and the smart home hub;
e)    Emergency Apps running in a local environment when the fire alarm and similar event occur.

Conclusion

A functional architecture for WoT Servient is introduced in Fig.1. This functional architecture can explain well a wide variety of different WoT application scenarios.
As the next stage of the standardization, we should standardize the following 3 items.
1)    Protocol mapping for HTTP and so on that enable communication between a client and WoT Servient;
2)    Things Description to declare properties and capabilities of WoT Servient to the Web;
3)    Script APIs in runtime environment for Server, Client and Discovery to enable App scripts.

Acknowledgements

@TODO decide whether needed...

Change History

@TODO decide whether needed...