Web of Things (WoT) Architecture 1.1

In a deployment of WoT conforming to the WoT Abstract Architecture we see a variety of different device types. They range (sorted in the order of footprint and capabilities) from small embedded node devices to gateways or hubs to powerful edge devices and cloud servers. Interoperability between these devices implies that a core set of features and functionalities is available on all of them.

The following device categories describe the footprint and characteristics of typical representatives of these classes. This is used to identify the possible features and use cases for these device classes.

These categories are aligned with the classes defined by the IETF [ RFC7228 ] for constrained devices, however the classes have been extended to larger devices and bounds on typical sizes of RAM and Flash/ROM are provided. Memory and storage size are both easier to quantify and more limiting than performance, so that is the basis of this categorization. This is not a strict categorization. Categories may overlap and not all memory may be available for user applications.

In the consumer space there are multiple assets that benefit from being connected. Lights and air conditioners can be turned off based on room occupancy. Window blinds can be closed automatically based on weather conditions and presence. Energy and other resource consumption can be optimized based on usage patterns and predictions.

The consumer scenario in this section describes the Smart Home use case.

Figure 1 shows an example of a Smart Home. In this case, gateways are connected to edge devices such as sensors, cameras and home appliances through corresponding local communication protocols such as KNX, ECHONET, ZigBee, DECT ULE and Wi-SUN. Multiple gateways can exist in one home, while each gateway can support multiple local protocols.

Gateways can be connected to the cloud through the internet, while some appliances can be connected to the cloud directly. Services running in the cloud collect data from edge devices and analyze the data, then provide value to users through the edge devices and other UX devices.

Smart home provides consumer benefits such as remote access and control, voice control and home automation. Smart home also enables device manufacturers to monitor and maintain devices remotely. Smart home can realize value added services such as energy management and security surveillance.

The industrial use cases in this section are applicable to different industry verticals.
Due to the nature of overlaps in the application scenarios, different verticals have similar use cases.

4.2.1 Example: Smart Factory

Figure 2 shows an example of a Smart Factory. In this case, field-level, cell and line controllers automate different factory equipment based on industrial communication protocols such as PROFINET, Modbus, OPC UA TSN, EtherCAT, or CAN. An industrial edge device collects selected data from various controllers and makes it available to a cloud backend service, e.g., for remote monitoring via a dashboard or analyzes it for preventive maintenance.

Smart factories require advanced monitoring of the connected manufacturing equipment as well of the manufactured products. They benefit from predictions of machine failures and early discovery of anomalies to prevent costly downtime and maintenance efforts.

Additionally, monitoring of connected manufacturing equipment and the environment at the production facility for the presence of poisonous gases, excessive noise or heat increases the safety of the workers and reduces the risks of incidents or accidents.

Real-time monitoring and KPI calculations of production equipment helps to detect productivity problems and optimize the supply chain.

Monitoring of vehicles, fuel costs, maintenance needs and assignments helps to optimize the full utilization of the vehicle fleet.

Shipments can be tracked to be en-route to ensure consistent quality and condition of the transported goods. This is especially useful to assert the integrity of the cold-chain from warehouses to refrigerated trucks to delivery.

Centralized monitoring and management of stock in warehouses and yards can prevent out of stock and excessive stock situations.

Automated reading of residential and C&I (Commercial and Industrial) meters, and billing offers continuous insights into resource consumption and potential bottlenecks.

Monitoring the condition and output of distributed renewable energy generation equipment enables optimization of distributed energy resources.

Monitoring and remote-controlling of distribution equipment helps to automate the distribution process.

Continuous monitoring of generation and distribution infrastructure is improving safety of utilities crew in the field.

Offshore platform monitoring, leakage detection and prediction of pipelines as well as monitoring and controlling the levels in tanks and reservoirs helps to improve the industrial safety for the workforce as well as for the environment.

Automated calculation of a distributed stock through various storage tanks and delivery pipes/trucks allows for improved planning and resource optimization.

Proactive Asset Monitoring of high value assets such as connected structures, fleet vehicles, etc. mitigates the risk of severe damage and high costs due to predictions and early detection of incidents.

Usage based insurance can be offered with usage tracking and customized insurance policies.

Predictive weather monitoring and re-routing fleet vehicles to covered garages can limit loss due to hail damage, tree damage.

Monitoring for industrial safety reduces the risks of security hazards. Monitoring of assets at construction site can prevent damage and loss.

Soil condition monitoring and creating optimal plans for watering, fertilizing as well as monitoring the produce conditions optimize the quality and output of agricultural produce.

Data collection and analytics of clinical trial data helps to gain insights into new areas.

Remote patient monitoring mitigates the risk of undetected critical situations for elderly people and patients after hospitalization.

Environment monitoring typically relies on a lot of distributed sensors that send their measurement data to common gateways, edge devices and cloud services.

Monitoring of air pollution, water pollution and other environmental risk factors such as fine dust, ozone, volatile organic compound, radioactivity, temperature, humidity to detect critical environment conditions can prevent unrecoverable health or environment damages.

Monitoring of Bridges, Dams, Levees, Canals for material condition, deterioration, vibrations discovers maintenance repair work and prevents significant damage. Monitoring of highways and providing appropriate signage ensures optimized traffic flow.

Smart Parking is optimizing and tracking the usage and availability of parking spaces and automates billing/reservations.

Smart control of street lights based on presence detection, weather predictions, etc. reduces cost.

Garbage containers can be monitored to optimize the waste management and the trash collection route.

Monitoring the energy usage throughout the building helps to optimize resource consumption and reduce waste.

Monitoring the equipment in the buildings such as HVAC, Elevators, etc. and fixing problems early improves the satisfaction of occupants.

Monitoring of operation status, prediction of service needs optimizes maintenance needs and costs. Driver safety is enhanced with notifications of an early warning system for critical road and traffic conditions.

4.13.1 Connected Car Example

Figure 3 shows an example of a Connected Car. In this case, a gateway connects to car components through CAN and to the car navigation system through a proprietary interface. Services running in the cloud collect data pushed from car components and analyze the data from multiple cars to determine traffic patterns. The gateway can also consume cloud services, in this case, to get traffic data and show it to the driver through the car navigation system.

Telemetry is the monitoring of remove devices, which implies automatic transmission to, and processing of measurements and other data on a Consumer . Data may be transported over various communication channels, both wireless and wired. Examples include GSM networks, Bluetooth, WiFi, Ethernet, and other wired standards.

Remote metering devices include one or multiple sensors, in some cases they also contain an actuator. In many cases the sensor data is transmitted at regular intervals, on a state change, or as a response to a request by the Consumer .

Remote metering devices are frequently small embedded systems with very limited resources, i.e. Class-2 or below. They may be battery powered and have to minimize power consumption through various measures, e.g. sleep modes. These devices will sleep most of the time and won't transmit any data to conserve energy. They only wake up on certain events (e.g. when a switch is toggled). When a device state changes, an event is sent to the consumer. After that the devices goes to sleep mode again.

Typical user scenarios are monitoring of various assets, examples include smart cities, factories, fleets, environmental monitoring and health monitoring. Some deployments may require monitoring of a high number of geographically distributed assets, others only include a few devices, as in a smart home. A common pattern is the one-to-many relationship between a single Consumer and multiple devices ( Things ).

A common deployment pattern is a local device controlled by a user-operated remote controller as depicted in Figure 4 .

A remote controller can access an electronic appliance through the local home network directly. In this case, the remote controller can be implemented by a browser or native application.

In this pattern, at least one device like the electronic appliance has a server role that can accept a request from the other devices and responds to them, and sometimes initiates a mechanical action. The other device like the remote controller has a client role that can send a message with a request, like to read a sensor value or to turn on the device. Moreover, to emit a current state or event notification of a device, the device may have a client role that can send a message to another device, which has server roles.

Figure 5 shows an example of a direct Thing-to-Thing interaction. The scenario is as follows: a sensor detects a change of the room condition, for example the temperature exceeding a threshold, and issues a control message like "turn on" to the electronic appliance. The sensor unit can issue some trigger messages to other devices.

In this case, when two devices that have server roles are connected, at least one device must have also a client role that issues a message to the other to actuate or notify.

This deployment scenario contains a mobile remote controller (e.g., on a smartphone) as shown in Figure 6 . The remote controller can switch between different network connections and protocols, e.g., between a cellular network and a home network, which is using protocols such as Wi-Fi and Bluetooth. When the controller is in the home network it is a trusted device and no additional security or access control is required. When it is outside of the trusted network, additional access control and security mechanisms must be applied to ensure a trusted relationship. Note that in this scenario the network connectivity may change due to switching between different network access points or cellular base stations.

In this pattern, the remote controller and the electronic appliance have a client and a server role as in the related scenario in Figure 4 .

Figure 7 shows a deployment scenario of a Smart Home Gateway . The gateway is placed between a home network and the Internet. It manages electronic appliances inside the house and can receive commands from a remote controller over the Internet, e.g., from a smartphone as in the previous scenario. It is also is a virtual representation of a device. The Smart Home Gateway typically offers proxy and firewall functionality.

In this pattern, the home gateway has both a client and a server role. When the remote controller actuates the electronic appliance, it can connect to the electronic appliance in the client role and to the remote controller with the server role. When the electronic appliance emits a message to the remote controller, the gateway act as server roles for the electric appliance, and it act as client roles for the remote controller.

An Edge Device or Edge Gateway is similar to a Smart Home Gateway. We use the term to indicate additional tasks that are carried out by the edge gateway. Whereas the home gateway in Figure 8 primarily just bridges between the public and the trusted network, the edge device has local compute capabilities and typically bridges between different protocols. Edge devices are typically used in industrial solutions, where they can provide preprocessing, filtering and aggregation of data provided by connected devices and sensors.

A Digital Twin is a virtual representation, i.e. a model of a device or a group of devices that resides on a cloud server or edge device. It can be used to represent real-world devices which may not be continuously online, or to run simulations of new applications and services, before they get deployed to the real devices.

Digital twins can model a single device, or they can aggregate multiple devices in a virtual representation of the combined devices.

Digital twins can be realized in different ways, depending on whether a device is already connected to the cloud, or whether it is connected to a gateway, which itself is connected to the cloud.

5.7.1 Cloud Connected Devices

Figure 11 shows an example where electronic appliances are connected directly to the cloud. The cloud mirrors the appliances and, acting as a digital twin, can receive commands from remote controllers (e.g., a smartphone). Authorized controllers can be located anywhere, as the digital twin is globally reachable.

5.7.3 Legacy Devices

Figure 12 shows an example where legacy electronic appliances are not directly connected to the cloud. Here, a gateway is needed to relay the connection. The gateway works as:

• integrator of a variety of legacy communication protocols both in the physical and logical view
• firewall toward the Internet
• privacy filter which substitutes real image and/or speech, and logs data locally
• local agent in case the network connection is interrupted
• emergency services running locally when fire alarms and similar events occur

The cloud mirrors the gateway with all connected appliances and acts as a digital twin that manages them in the cloud in conjunction with the gateway. Furthermore, the cloud can receive commands from remote controllers (e.g., a smartphone), which can be located anywhere.

Typical IoT deployments consist of multiple (thousands) of devices. Without a standardized mechanism, the management of firmware updates for specific clouds require a lot of effort and hinders wider scale IoT adoption.

The primary benefit of a standardized mechanism for describing devices and device types is the capability of deploying devices to different cloud environments without the need of doing customization at device software / firmware level, i.e., installing cloud specific code to a device. This implies that the solution is flexible enough to describe devices in a way that allows on-boarding and using devices in multiple IoT cloud environments.

This drives adoption of Web of Things devices, since it enables easy usage of new devices in an existing deployment, as well as migration of existing devices from one cloud to the other.

A Virtual Thing is a Service that acts as a placeholder for one or more other Things which provides an interface to its consumers .

In a simple case it is an interface abstraction, which defines a common interface to devices, where it is possible to replace a device model with another one without changing the consumer.

In a more complex scenario, a Virtual Thing provides a single interface for multiple devices, and provides a higher level of operations to its Consumers . Individual devices can be replaced, new operations can be provided via software upgrades.

A Virtual Thing will often act as an Intermediary . Examples include Shadows and Digital Twins .

Figure 13 show an example of a cross-domain collaboration. In this case, each system involves other systems in other domains, such as Smart Factory with Smart City, Smart City with Smart Home. This type of system is called "Symbiotic" ecosystem, as shown in [ IEC-FOTF ]. There are two collaboration models: direct collaboration and indirect collaboration. In the direct collaboration model, systems exchange information directly with each other in a peer-to-peer manner. In the indirect collaboration, systems exchange information via some collaboration platform. In order to maintain and continue this collaboration, each system provides the metadata of their capabilities and interfaces and adapts itself to others.

The previous section described various architecture patterns. In these patterns, some functional entities such as the devices including the legacy devices, controllers, gateways and cloud servers are located at physical locations such as inside building, outside buildings, and data centers. Figure 14 is an overview that shows the combinations and communication paths of these entities.

In a transport protocol layer, each entity arbitrarily selects a suitable role for communications. For example, a device may act as a server when the device provides a service to indefinite number of applications. On the other hand, if a device has limited or intermittent network connectivity, they may act as a client and actively send message to an application when network is available. Regardless of this, in application layer, an application sees that a device provides abstract interfaces to interact and the application can interact with the device using their abstract interfaces.

The WoT Thing Description (TD) specification [ WOT-THING-DESCRIPTION ] defines an information model based on a semantic vocabulary and a serialized representation based on JSON . TDs provide rich metadata for Things in a way that is both human-readable and machine-readable. Both the information model and the representation format of TDs are aligned with Linked Data [ LINKED-DATA ], so that besides raw JSON processing, implementations may choose to make use of JSON-LD [ JSON-LD11 ] and graph databases to enable powerful semantic processing of the metadata.

A Thing Description describes Thing instances with general metadata such as name, ID, descriptions, and also can provide relation metadata through links to related Things or other documents. TDs also contain Interaction Affordance metadata based on the interaction model defined in 6.5 Interaction Model ; Public Security Metadata ; and communications metadata defining Protocol Bindings . The TD can be seen as the index.html for Things , as it provides the entry point to learn about the services and related resources provided by a Thing , both of which are described using hypermedia controls .

For semantic interoperability, TDs may make use of a domain-specific vocabulary , for which explicit extension points are provided. However, development of any particular domain-specific vocabulary is currently out-of-scope of the W3C WoT standardization activity.

Three examples of potentially useful external IoT vocabularies are SAREF [ SAREF ], Schema Extensions for IoT [ IOT-SCHEMA-ORG ], and the W3C Semantic Sensor Network ontology [ VOCAB-SSN ]. Use of such external vocabularies in TDs is optional. In the future additional domain-specific vocabularies may be developed and used with TDs .

Overall, the WoT Thing Description building block fosters interoperability in two ways: First, TDs enable machine-to-machine communication in the Web of Things. Second, TDs can serve as a common, uniform format for developers to document and retrieve all the details necessary to create applications that can access IoT devices and make use of their data.

TDs must be known or accessible to be useful to other systems and devices. The WoT Discovery building block, described in more detail below, defines mechanisms by which this may be accomplished for both self-describing devices and for situations (brownfield devices, constrained devices, devices with specialized protocols, sleeping devices, etc.) in which having a separate service providing the TD is more suitable.

The Thing Model defines a template-based model for Thing Description instances. A Thing Model has no instance specific and only partial communication- and security-based information. This kind of information is supplemented by the creation of Thing Description instantiation.

A Thing Model mainly describes the Properties , Actions , and Events and common metadata which then are available in all instantiated Thing Descriptions . This paradigm can be compared with abstract class or interface definitions (~Thing Model) in object-oriented programming to create objects (~Thing Descriptions).Such Thing Models are relevant for, e.g., mass production of IoT devices, onboarding scenarios as in cloud services, or to simulate Devices that have not yet been developed.

The WoT Profile Specification [ WOT-PROFILE ] defines Profiles, Profiles that enable out of the box interoperability among things and devices. Out of the box interoperability implies, implies that devices can be integrated into various application scenarios without deep level adaptations. Typically only minor configuration operations are necessary (such as entering a network key, or IP address) to use the device in a certain scenario. These actions can be done by anyone without specific training.

7.3.1 Profiling Methodology

A profile is a set of constraints and rules, which provide additional semantic guarantees that are applied to the WoT Thing Description specification. These constraints define a subset of valid WoT Thing Descriptions by defining additional rules on various aspects of the WoT Thing Description .

Constraints on	Rationale	Examples
vocabulary of Thing Description classes	guaranteed set of metadata fields	Make specific vocabulary terms mandatory, remove others
class relationships	unambiguous structure	limited cardinality, e.g. only one form per operation per interaction affordance.
values of vocabulary terms	simplified processing	Limit the length of characters per string. Always use arrays, where the spec permits a string or an array of strings.
data schemas	simplified processing	No arbitrary nested objects or arrays of arrays.
security	reduced implementation effort	Only a restricted set of security mechanisms.
protocol binding	guaranteed protocol semantics	limited protocol(s) and protocol features, Example: predefined mapping of http verbs (GET/PUT) to operation verbs, similar constraints for other protocols.

These constraints and rules fall into two categories:

• constraints on the data model.
• constraints on the protocol binding.

These two categories are orthogonal to each other, i.e. an information model that conforms to a profile can be mapped to different protocols. The protocol binding for each protocol may contain additional (protocol-specific) constraints.

A profile is not exclusive, i.e. a thing may conform to multiple profiles. Profiles can build on top of each other or overlap, extended profiles can be built on top of a baseline profile.

The WoT Discovery specification [ WOT-DISCOVERY ] defines mechanisms for distributing and accessing WoT Thing Descriptions over the network. These mechanisms are meant to simplify access to Things and services and support their integration. WoT Discovery mechanisms are not limited by the bounds of local area networks and can also support remote discovery. They are also designed to act as extensions of existing search and discovery standards.

One of the primary design requirements of the WoT Discovery building block is to protect the security and privacy of both consumers and providers of WoT data and metadata. In particular, WoT Discovery mechanisms are designed not only to protect and control access to WoT Thing Descriptions , but also are designed to protect queries about such data and metadata, and to avoid accidental distribution of direct or inferrable metadata.

In order to accommodate existing discovery technologies while providing strong privacy and security, WoT Discovery uses a two-stage process. In the first stage, an " introduction " is made using one of several first-contact mechanisms. In the second stage, called " exploration ", actual TDs are made available, but only after suitable authentication and authorization.

Two exploration mechanisms are provided, supporting both distribution of single TDs and directory services for multiple TDs:

• An ordinary web resource provided by an HTTP server can be used to distribute a single TD. This can also be used for self-description, to allow a Thing to provide its own WoT Thing Description directly.
• Directory services provide searchable databases of WoT Thing Descriptions. Both lightweight syntactic query mechanisms and more powerful semantic query mechanisms are supported by directory services.

Use of these mechanisms is encouraged, but not mandatory.

The Discovery mechanisms defined in [ WOT-DISCOVERY ] are not mandatory, but they are designed to meet the above requirements and their use will enhance interoperability and usability.

The IoT uses a variety of protocols for accessing devices, since no single protocol is appropriate in all contexts. Thus, a central challenge for the Web of Things is to enable interactions with the plethora of different IoT platforms (e.g., OMA LWM2M, OPC UA, oneM2M) and devices that do not follow any particular standard, but provide an eligible interface over a suitable network protocol. WoT is tackling this variety through Protocol Bindings , which must meet a number of constraints (see 6.7 Protocol Bindings ).

The Binding Templates address the aspect that an application client (a Consumer ) can use the Thing Description to extract the specific metadata of the protocols (e.g. about HTTP, MQTT, Modbus, etc.), payload formats (binary, JSON, CBOR, EXI, etc.) and their usage in an IoT platform context (e.g., ECHONET, OPC UA). The metadata can be passed to a network implementation interface to establish interaction with the Thing and to serialize / deserialize the payload messages. In that context, Binding Templates include three kinds of bindings: Protocol bindings, Payload format bindings, and Platform bindings.

The non-normative WoT Binding Templates specification [ WOT-BINDING-TEMPLATES ] provides a collection of blueprints that give guidance on how to interact with different Things that use different transport protocols , content types or that are different IoT platforms or standards (e.g., OCF, oneM2M, OMA LWM2M, OPC UA) which use certain combinations of transport protocols and content types . When describing a particular IoT device or platform, the corresponding Binding Template can be used to look up the communication metadata that is to be provided in the Thing Description to support that platform.

Figure 31 shows how Binding Templates are used. Based on the protocol, media type or platform binding, a TD is created. The Consumer that is processing a TD implements the required Binding Template that is present in the TD by including a corresponding protocol stack, media type encoder/decoder or platform stack and by configuring the stack (or its messages) according to the information given in the TD such as serialization format of the messages and header options.

The Binding Templates spans three dimensions:

• Protocol

  The Web of Things uses the term transport protocol for the underlying, standardized application-layer protocol without application-specific options or subprotocol mechanisms. The URI scheme found in the form of an Interaction Affordance and the associated protocol endpoint URI contains the information required to identify the transport protocol , e.g., HTTP, CoAPS, or WebSocket through http , coaps , or ws , respectively.

  • Subprotocol

    Transport protocols may have to use information provided by an extension mechanisms to interact successfully. Such subprotocols cannot be identified from the URI scheme alone and must be declared explicitly using the subprotocol field inside forms. Examples for HTTP are long polling [ RFC6202 ] ( longpoll ) or Server-Sent Events [ HTML ] ( sse ).

• Payload Representation

  Representation formats (a.k.a. serializations) used for exchanging data can differ between protocols, IoT Platforms and standards. The media type [ RFC2046 ] identifies these formats, while media type parameters may specify them further. Forms may contain the media type and optional parameters in additional form fields such as a content type field known from HTTP, which combines media type and its potential parameters (e.g., text/plain; charset=utf-8 ).

• Platforms and Standards

  IoT Platforms and standards often introduce specific modifications at the application layer such as platform-specific HTTP header fields or CoAP options. They can also contain specific payload structures on top of the media types that need to be accurately incorporated into each message between the Thing and its Consumer. Both the protocol modification and payload representation specific to different platforms can be represented in TDs using the best practices documented in binding templates for platforms and standards.

The WoT Scripting API is an optional "convenience" building block of W3C WoT that eases IoT application development by providing an ECMAScript-based API [ ECMAScript ] similar to the Web browser APIs. By integrating a scripting runtime system into the WoT Runtime , the WoT Scripting API enables using portable application scripts that define the behavior of Things , Consumers , and Intermediaries .

Traditionally, IoT device logic is implemented in firmware, which results in productivity constraints similar to that of embedded development, including a relatively complex update process. The WoT Scripting API in contrast enables implementing device logic by reusable scripts executed in a runtime system for IoT applications. It is similar to that of a Web browser, and aims to improve productivity and reduce integration costs. Furthermore, standardized APIs enable portability for application modules, for instance, to move compute-intense logic from a device up to a local gateway, or to move time-critical logic from the cloud down to a gateway or edge node.

The non-normative WoT Scripting API specification [ WOT-SCRIPTING-API ] defines the structure and algorithms of the programming interface that allows scripts to discover, consume, and expose WoT Thing Descriptions . The runtime system of the WoT Scripting API instantiates local objects that act as an interface to other Things and their Interaction Affordances ( Properties , Actions , and Events ). It also allows scripts to expose Things , that is, to define and implement Interaction Affordances and publish a Thing Description .

Security is a cross-cutting concern and should be considered in all aspects of system design. In the WoT architecture, security is supported by certain explicit features, such as support for Public Security Metadata in TDs and by separation of concerns in the design of the WoT Scripting API . The specification for each building block also includes a discussion of particular security and privacy considerations of that building block. Another non-normative specification, the WoT Security and Privacy Guidelines [ WOT-SECURITY ], provides additional cross-cutting security and privacy guidance.

The behavior defines the overall application logic of a Thing , which has several aspects:

It includes autonomous behavior of Things (e.g., sampling of sensors or control loops for actuators), the handlers for Interaction Affordances (i.e., the concrete actions taken when an affordance is activated), Consumer behavior (e.g., controlling a Thing or realizing mashups), and Intermediary behavior (e.g., simply proxying a Thing or composing virtual entities). The behavior implementation within a Servient defines which Things , Consumers , and Intermediaries are hosted on this component.

Figure 32 depicts Servients that are implementing the optional WoT Scripting API building block, where portable application scripts written in JavaScript [ ECMAScript ] define the behavior. They are executed by a scripting runtime system that is part of the WoT Runtime (when providing the WoT Scripting API or any other script-based API). They are portable, as they are written against the common WoT Scripting API definitions, and hence can be executed by any Servient featuring this building block. This makes it possible to shift application logic between system components, for instance moving a Consumer from the cloud to an edge node to meet networking requirements, or to move an Intermediary to the cloud to fulfill growing resource demands. Portable applications enable to 'install' additional behavior after the deployment of a Servient.

In principle, any programming language and API can be used in order to define the behavior of a Thing, as long as the Interaction Affordances are presented externally through a WoT Interface . The adaption between application-facing API and the protocol stack is handled by the WoT Runtime . See 8.8.1 Native WoT API for behavior implementation without the WoT Scripting API building block.

Technically, the Thing abstraction and its Interaction Model is implemented in a runtime system. This WoT Runtime maintains the execution environment for the behavior implementation and is able to expose and/or consume Things , and hence must be able to fetch, process, serialize, and serve WoT Thing Descriptions .

Every WoT Runtime has an application-facing interface (i.e., an API) for the behavior implementation. The optional WoT Scripting API building block shown in Figure 32 defines such an application-facing interface that follows the Thing abstraction and enables the deployment of behavior implementations during runtime through application scripts. See 8.8.1 Native WoT API for alternative APIs, which can also only be available during compile time. In general, application logic should be executed in sandboxed execution environments that prevent unauthorized access to the management aspects of the WoT Runtime from the application code, in particular the Private Security Data . In multi-tenant Servients , different tenants should also be prevented from accessing each other's data without authorization.

A WoT Runtime needs to provide certain operations to manage the lifecycle of Things , or more precisely their software abstractions and descriptions. A lifecycle management (LCM) system may encapsulate those lifecycle operations within a Servient and use internal interfaces to realize the lifecycle management. The details of such operations vary among different implementations. The WoT Scripting API includes LCM functionality, and hence represents one possible implementation of such a system.

The WoT Runtime must interface with the protocol stack implementation of the Servient , as it decouples the behavior implementation from the details of the Protocol Bindings . The WoT Runtime usually also interfaces with the underlying system, for instance, to access local hardware such as attached sensors and actuators or to access system services such as storage. Both interfaces are implementation-specific, yet the WoT Runtime must provide the necessary adaption to the Thing abstraction it implements.

The WoT Scripting API building block defines an ECMAScript API that closely follows the WoT Thing Description specification [ WOT-THING-DESCRIPTION ]. It defines the interface between behavior implementations and a scripting-based WoT Runtime . Other, simpler APIs may be implemented on top of it, similar to, for instance, jQuery for the Web browser APIs.

See [ WOT-SCRIPTING-API ] for more details.

The WoT Runtime instantiates software representations of Things based on their TDs . These software representations provide the interface towards the behavior implementation.

The Exposed Thing abstraction represents a Thing hosted locally and accessible from the outside through the protocol stack implementation of the Servient . The behavior implementation can fully control Exposed Things by defining their metadata and Interaction Affordances , and providing their autonomous behavior.

The Consumed Thing abstraction represents a remotely hosted Thing for Consumers that needs to be accessed using a communication protocol. Consumed Things are proxy objects or stubs. The behavior implementation is restricted to reading their metadata and activating their Interaction Affordances as described in the corresponding TD . Consumed Things can also represent system features such as local hardware or devices behind proprietary or legacy communication protocols. In this case, the WoT Runtime must provide the necessary adaptation between system API and Consumed Thing . Furthermore, it must provide corresponding TDs and make them available to the behavior implementation, for instance, by extending whatever discovery mechanism is provided by the WoT Runtime through the application-facing API (e.g., the discover() method defined in the WoT Scripting API [ WOT-SCRIPTING-API ]).

When using the WoT Scripting API , Exposed Thing and Consumed Thing are JavaScript objects, which can be created, operated on, and destroyed by application scripts. However, access may be restricted through a security mechanism, for instance, in multi-tenant Servients .

Private security data, such as a secret key for interacting with the Thing, is also conceptually managed by the WoT Runtime , but is intentionally not made directly accessible to the application. In fact, in the most secure hardware implementations, such Private Security Data is stored in a separate, isolated memory (e.g., on a secure processing element or TPM) and only an abstract set of operations (possibly even implemented by an isolated processor and software stack) is provided that limit the attack surface and prevent external disclosure of this data. Private Security Data is used transparently by the Protocol Binding to authorize and protect the integrity and confidentiality of interactions.

The protocol stack of a Servient implements the WoT Interface of the Exposed Things and is used by Consumers to access the WoT Interface of remote Things (via Consumed Things ). It produces the concrete protocol messages to interact over the network. Servients may implement multiple protocols, and hence support multiple Protocol Bindings to enable interaction with different IoT Platforms .

In many cases, where standard protocols are used, generic protocol stacks can be used to produce the platform-specific messages (e.g., one for HTTP(S) dialects, one for CoAP(S) dialects, and one for MQTT solutions, etc.). In this case, the communication metadata from the Thing Description is used to select and configure the right stack (e.g., HTTP with the right header fields or CoAP with the right options). Parsers and serializers for the expected payload representation format (JSON, CBOR, XML, etc.) as identified by the media type [ RFC2046 ] can also be shared across these generic protocol stacks.

See [ WOT-BINDING-TEMPLATES ] for details.

An implementation of a WoT Runtime may provide local hardware or system services to behavior implementations through the Thing abstraction, as if they were accessible over a communication protocol. In this case, the WoT Runtime should enable the behavior implementation to instantiate Consumed Things that internally interface with the system instead of the protocol stack. This can be done by listing such system Things, which are only available in the local WoT Runtime , in the results of the discovery mechanism provided by the application-facing WoT Runtime API.

A device may also be physically external to a Servient , but connected via a proprietary protocol or a protocol not eligible as WoT Interface (see 6.7 Protocol Bindings ). In this case, the WoT Runtime may access legacy devices with such protocols (e.g., ECHONET Lite, BACnet, X10, I2C, SPI, etc.) through proprietary APIs, but may again choose to expose them to the behavior implementation via a Thing abstraction. A Servient can then act as gateway to the legacy devices. This should only be done if the legacy device cannot be described directly using a WoT Thing Description .

The behavior implementation may also access local hardware or system services (e.g., storage) through a proprietary API or other means. This is, however, out of scope of the W3C WoT standardization, as it hinders portability.

The WoT Scripting API building block is optional. Alternative Servient implementations are possible, where the WoT Runtime offers an alternative API for the application logic, which may be written in any programming language.

Furthermore, devices or services unaware of W3C WoT can still be consumed, when it is possible to provide a well-formed WoT Thing Description for them. In this case, the TD describes a WoT Interface of a Thing that has a black-box implementation.

8.8.1 Native WoT API

There are various reasons why a developer may choose to implement a Servient without using the WoT Scripting API . This may be due to insufficient memory or computing resources, so the developer cannot use the required software stack or a fully-featured scripting engine. Alternatively, to support their use case (for example, a proprietary communications protocol) the developer may have to use specific functions or libraries only available through a particular programming environment or language.

In this case, a WoT Runtime can still be used, but with an equivalent abstraction and functionality exposed using an alternative application-facing interface instead of the WoT Scripting API . Except for the latter, all block descriptions in 8. Abstract Servient Architecture are also valid for Figure 33 .

8.8.2 Thing Description for Existing Devices

It is also possible to integrate existing IoT devices or services into the W3C Web of Things and to use them as Things by creating a Thing Description for these devices or services. Such a TD can either be created manually or via a tool or service. For example, a TD could be generated by a service that provides automatic translation of metadata provided by another, ecosystem-dependent machine-readable format. This can only be done, however, if the target device is using protocols that can be described using a Protocol Binding . The requirements for this are given in 6.7 Protocol Bindings . Much of the previous discussion also implies that a Thing provides its own Thing Description . While this is a useful pattern it is not mandatory. In particular, it may not be possible to modify existing devices to provide their own Thing Description directly. In this case the Thing Description will have to be provided separately using a service such as a directory or some other external and separate distribution mechanism.

A Servient in the role of a Thing creates an Exposed Thing based on a Thing Description (TD). TDs are published and made available to other Servients that are in the roles of Consumers or Intermediaries . TDs may be published in various different ways: the TD might be registered with a management system such as a Thing Description Directory service, or a Thing may provide the requesters with a TD upon receiving a request for a TD. It is even possible to statically associate a TD with Thing in certain application scenarios.

A Servient in the role of a Consumer obtains the TD of a Thing using a discovery mechanism and creates a Consumed Thing based on the obtained TD. The concrete discovery mechanism depends on the individual deployment scenario: It could be provided by a management system such as a Thing Description Directory , a discovery protocol, through static assignment, etc. As discussed elsewhere, use of the Discovery mechanisms defined in [ WOT-DISCOVERY ] is recommended whenever possible.

However, it should be noted that TDs describing devices associated with an identifiable person may potentially be used to infer privacy-sensitive information. Constraints on the distribution of such TDs must therefore be incorporated into any concrete TD discovery mechanism. If possible, steps to limit the information exposed in a TD may also have to be taken, such as filtering out IDs or human-readable information if this is not strictly necessary for a particular use case. Privacy issues are discussed at a high level in 11. Privacy Considerations and a more detailed discussion is given in the [ WOT-THING-DESCRIPTION ] specification and are addressed in the [ WOT-DISCOVERY ] specification.

Internal system functions of a device, such as interacting with attached sensors and actuators, can also optionally be represented as Consumed Thing abstractions.

The functions supported by the Consumed Thing are provided to the Consumer 's behavior implementation through a programming language interface. In the WoT Scripting API , Consumed Things are represented by objects. The behavior implementation (that is, the application logic) running in a Thing can engage through Interaction Affordances with Consumers by using the programming language interface provided by the Exposed Thing .

A Thing does not necessarily represent a physical device. Things can also represent a collection of devices, or virtual services running in a gateway or in the cloud. Likewise, a Consumer may represent an application or service running on a gateway or cloud. Consumers can also be implemented on edge devices. In Intermediaries , a single Servient performs both the roles of a Thing and a Consumer simultaneously which are sharing a single WoT Runtime .

Various topologies and deployment scenarios of WoT systems are discussed in this section. These are only example patterns and other interconnection topologies are also possible. The topologies described here are derived from the Web of Things Use Cases and Requirements [ WOT-USE-CASES-REQUIREMENTS ].

9.2.1 Consumer and Thing on the Same Network

In the simplest interconnection topology, illustrated by Figure 35 , the Consumer and Thing are on the same network and can communicate directly with each other without any intermediaries. One use case where this topology arises is when the Consumer is an orchestration service or some other IoT application running on a gateway and the Thing is a device interfacing to a sensor or an actuator. However, the client/server relationship could be easily reversed; the client could be a device in the Consumer role accessing a service running as a Thing on a gateway or in the cloud.

If the Thing is in the cloud and the Consumer is on a local network (see Figure 1 for an example in a Smart Home use case) the actual network topology may be more complex, for example requiring NAT traversal and disallowing certain forms of discovery. In such cases one of the more complex topologies discussed later may be more appropriate.

9.2.2 Consumer and Thing Connected via Intermediaries

An Intermediary plays both Thing and Consumer roles on the network and supports both the Exposed Thing and Consumed Thing software abstractions within its WoT Runtime . Intermediaries can be used for proxying between devices and networks or for Digital Twins .

9.2.2.1 Intermediary Acting as a Proxy

One simple application of an Intermediary is a proxy for a Thing . When the Intermediary acts as a proxy, it has interfaces with two separate networks or protocols. This may involve the implementation of additional security mechanisms such as providing TLS endpoints. Generally proxies do not modify the set of interactions, so the TD exposed by the Intermediary will have the same interactions as the consumed TD, however the connection metadata is modified.

To implement this proxy pattern, the Intermediary obtains a TD of a Thing and creates a Consumed Thing . It creates a proxy object of the Thing as a software implementation that has the same Interaction Affordances . It then creates a TD for the proxy object with a new identifier and possibly with new communications metadata ( Protocol Bindings ) and/or new Public Security Metadata . Finally, an Exposed Thing is created based on this TD, and the Intermediary notifies other Consumers or Intermediaries of the TD via an appropriate publication mechanism.

9.2.2.2 Intermediary Acting as a Digital Twin

More complex Intermediaries may be known as Digital Twins . A Digital Twin may or may not modify the protocols or translate between networks, but they provide additional services, such as state caching, deferred updates, or even predictive simulation of the behavior of the target device. For example, if an IoT device has limited power, it may choose to wake up relatively infrequently, synchronize with a Digital Twin , and then immediately go to sleep again. In this case, typically the Digital Twins runs on a less power-constrained device (such as in the cloud or on a gateway), (c.f. Device Categories ) and is able to respond to interactions on the constrained device's behalf. Requests for the current state of properties may also be satisfied by the Digital Twins using cached state. Requests that arrive when the target IoT device is sleeping may be queued and sent to it when it wakes up. To implement this pattern, the Intermediary , i.e., the Digital Twin needs to know when the device is awake. The device implementation as a Thing may need to include a notification mechanism for that. This could be implemented using a separate Consumer / Thing pair, or by using Event interactions for this purpose.

9.2.3 Devices in a Local Network Controlled from a Cloud Service

In Smart Home use cases, devices (sensors and home appliances) connected to a home network are often monitored and, in some cases, also controlled by cloud services. There is usually a NAT device between the home network to which the devices are connected and the cloud. The NAT device translates IP addresses as well as often providing firewall services, which block connections selectively. The local devices and cloud services can only communicate with each other if the communication can successfully traverse the gateway.

A typical structure, adopted in ITU-T Recommendation Y.4409/Y.2070 [ Y.4409-Y.2070 ] , is shown in Figure 37 . In this structure there is both a local and a remote Intermediary . The local Intermediary aggregates the Interaction Affordances from multiple Thing into a (set of) Exposed Things , which can all be mapped onto a common protocol (for example, HTTP, with all interactions mapped to a single URL namespace with a common base server and using a single port). This provides the remote Intermediary with a simple way to access all the Things behind the NAT device, assuming the local Intermediary has used a converged protocol that can traverse the NAT device and has some way to expose this service to the Internet (STUN, TURN, dynamic DNS, etc.). In addition, the local Intermediary can function as a Thing proxy, so even when the connected Things each use a different protocol (HTTP, MQTT, CoAP, etc.) and/or a different set of ecosystem conventions, the Exposed Thing can converge them into a single protocol so that Consumers do not need to be aware of the various protocols the Things use.

In Figure 37 , there are two clients connected to the remote Intermediary , which has aggregated the services that reside behind the NAT border and may provide additional protocol translation or security services. In particular, the local Intermediary may be on a network with limited capacity and making that service directly available to all users may not be feasible. In this case access to the local Intermediary is only provided to the remote Intermediary . The remote Intermediary then implements a more general access control mechanism and may also perform caching or throttling to protect the consumer from excess traffic. Those consumers also will use a single protocol suitable for the open Internet (e.g., HTTPS) to communicate with the Intermediary , which makes the development of clients much simpler.

In this topology there is NAT and firewall functionality between the consumers and things, but the local and remote Intermediaries work together to tunnel all communications through the firewall, so the consumers and things need to know nothing about the firewall. The paired Intermediaries also protect the home devices by providing access control and traffic management.

In more difficult cases the NAT and firewall traversal may not work exactly as shown. In particular, an ISP may not support publicly accessible addresses, or STUN/TURN and/or dynamic DNS may not be supported or available. In this case the Intermediaries may alternative reverse the client/server roles between them to set up an initial connection (with the local Intermediary first connecting to the remote Intermediary in the cloud), then the pair of Intermediaries may establish a tunnel (using for example, a Secure WebSocket, which uses TLS to protect the connection). The tunnel can then be used to encode all communications between the Intermediaries using a custom protocol. In this case the initial connection can still be made over HTTPS using standard ports, and from the local Intermediary to the remote Intermediary identically to a normal browser/web server interaction. This should be able to traverse most home firewalls, and since the connection is outgoing, network address translation will not cause any problems. However, even though a custom tunneling protocol is needed, the remote Intermediary can still translate this custom protocol back into standard external protocols. The connected Consumers and Things do not need to know about it. It is also possible to extend this example to use cases where both Things and Consumers can connect on either side of the NAT boundary. This however also requires a bidirectional tunnel to be established between the two Intermediaries .

9.2.4 Discovery Using a Thing Description Directory

Once local devices (and possibly services) can be monitored or controlled by services on cloud, a variety of additional services can be built on top. For example, a cloud application could change a device's operating condition based on an analysis of collected data.

However when the remote Intermediary is a part of a cloud platform servicing client applications, the clients need to be able to find device information by, for example, accessing a directory of connected devices. For simplicity in the figure below we have assumed all local devices are implemented as Things and all cloud applications as Consumers . To make the metadata of local devices implemented as Things available to the cloud applications, their metadata can be registered with a Thing Description Directory service. This metadata is specifically the TDs of the local devices modified to reflect the Public Security Metadata and communication metadata ( Protocol Bindings ) provided by the remote Intermediary . A client application then can obtain the metadata it needs to communicate with local devices to achieve its functionality by querying the Thing Description Directory .

In more complex situations, not shown in the figure, there may also be cloud services that act as Things . These can also register themselves with a Thing Description Directory . Since a Thing Description Directory is a Web service, it should be visible to the local devices through the NAT or firewall device and its interface can even be provided with its own TD. Local devices acting as Consumers can then discover the Things in the cloud via a Thing Description Directory and connect to the Things directly or via the local Intermediary if, for instance, protocol translation is needed.

9.2.5 Service-to-Service Connections Across Multiple Domains

Multiple cloud eco-systems each based on different IoT platforms can work together to make a larger, system-of-systems eco-system. Building on the previously discussed structure of a cloud application eco-system, the figure below shows two eco-systems connected to each other to make a system-of-systems. Consider the case in which a client in one eco-system (i.e., Consumer A below) needs to use a server in another eco-system (i.e., Thing B below). There is more than one mechanism to achieve this cross eco-systems application-device integration. Below, two mechanisms are explained, each using a figure, to show how this can be achieved.

9.2.5.1 Connection Through Thing Description Directory Synchronization

In Figure 39 , two instances of a Thing Description Directory synchronize information, which makes it possible for Consumer A to obtain the information of Thing B through Thing Description Directory A. As described in previous sections, remote Intermediary B maintains a shadow implementation of Thing B. By obtaining the TD of this shadow device, Consumer A is able to use Thing B through the remote Intermediary B.

9.2.5.2 Connection Through Proxy Synchronization

In Figure 40 , two remote Intermediaries synchronize device information. When a shadow of Thing B is created in remote Intermediary B, the TD of the shadow is simultaneously synchronized into remote Intermediary A. Remote Intermediary A in turn creates its own shadow of Thing B, and registers the TD with Thing Description Directory A. With this mechanism, synchronization between Thing Description Directory services is not necessary.

Ideally, accessibility should be thought of from the beginning of the development of a component in any greenfield WoT system. If the component's hardware has its own display or other form of physical user interface, this must be as accessible as possible. If it cannot be made accessible (for example, due to screen size limitations), then equivalent functionality should be made available over the network so an accessible interface (such as a web or voice interface) can be used instead. When the component is accessed over the network, provisions must be made for accessible web interfaces whether hosted directly on the device or provided by another component (such as a dashboard). Situations where the on-board hardware is the only option for interfaces, such as during onboarding, should be carefully designed to be made as accessible as possible.

• For web-based user interfaces, relevant guidance on accessibility can be found in W3C Web Content Accessibility Guidelines [ WCAG22 ].
• More generally, EN 301 549 [ etsi-en-301-549 ] provides guidelines for hardware and other user interfaces, especially for software/firmware running on "closed functionality" devices.

In general, a Thing should always have at least one user interface (either direct or network-based) that is fully accessible according to WCAG and EN 301 549. Accessibility must be applied to the interfaces made available for all types of users: manufacturers, installers, device owners, end users.

The accessibility status of the user interfaces for a Thing should be declared in the Thing’s metadata, so that users can pick the user interface that is most appropriate for them. If the Thing has a web interface, existing mechanisms to describe web interfaces should be used. To better support the connection between the web and physical interfaces, affordances described in a WoT Thing Description should be annotated in such a way that their relation to the physical interface on the device can be understood.

Components that do not directly offer a user interface must still support accessibility by providing suitable data and functions. For example, developers of public Things (e.g. a ticket machine or an ATM) should consider a locator function by which a user can physically identify and locate the Thing by auditory, visual or other signaling.

Brownfield applications of WoT cover situations where WoT metadata is used to describe an existing device, but WoT was not considered during its design. In this case many of the above provisions still apply. For example, a web interface provided by another system to monitor or control the device should follow the guidelines in WCAG, and the Thing Description should annotate affordances appropriately. If a device's own physical interface provides an accessibility challenge, there is the potential to overcome it with an alternative interface based on its network affordances.