We present an architecture based on Social Linked Data (Solid) and W3C Web of Things (WoT) that enables controlled access to composite IoT devices and their data. The architecture allows for stakeholders to interact with the composite device and to read and write data, provided they are authorized. For ifne-grained access control, data is stored in nested Linked Data Platform ( LDP) containers that reflect the structure of the composition itself. The composition structure is derived from a hierarchy of WoT Thing Descriptions (TDs). The architecture relies on an orchestration component to couple IoT devices and the Solid data store and is straightforward to implement with existing software.
The Internet of Things (IoT) is a key technology for industrial automation. IoT devices can be simple standalone devices, such as individual sensors and actuators, or more complex composite devices, such as a conveyor belt composed of motors and sensors. Individual IoT devices and the subsystems that form a composite produce dynamic data at runtime and have associated static data, such as datasheets, maintenance or usage instructions, but are constrained by their limited processing power, storage capacity and power supply.
As a result, data of standalone and composite IoT devices cannot be made available to stakeholders on the devices themselves. Data must be ofloaded to other components of an IoT system. These components must provide fine-grained access control to manage the data, given the involvement of multiple stakeholders with varying levels of authority and responsibility. For example, an external maintenance worker should not have access to all data, unlike the owner of a machine. The system also needs to be able to control and orchestrate composites and their standalone IoT devices to perform tasks.
The benefit of long-term storage of data generated by and associated with an IoT device combined with fine-grained access control is that smart factories can continuously analyze and monitor operational data to identify trends, make data-driven decisions, and share their data with internal or external stakeholders while ensuring data security and privacy.
Implementing an IoT system with access control for data exchange requires overcoming several challenges. First, the system must uniquely identify which individual users are authorized to access which data. Second, the system must be able to integrate dynamic data, such as raw sensor data in various formats from diferent sources, and static data. Finally, the system must be easy to set up and be able to integrate diferent IoT devices from diferent vendors using diferent protocols.
To implement a system that can operate in such a heterogeneous environment, we propose
to use the Web of Things (WoT) Architecture [
A Solid Pod is a data store that resembles a file system, exposes a REST API with controlled access to the data. Solid implements relevant LDP concepts, namely LDP containers, which correspond to file system directories, and (non-container) LDP resources, which correspond to ifles.
The contribution of this work is an architecture that is (i) extensible in terms of server components, with the orchestrator as a coupling client in between, (ii) eases implementation by using existing server software, and which (iii) builds on established Semantic Web technologies such as WoT and Solid to facilitate system and data integration.
The running example is an industrial machine comprising motors and sensors. A motor moves a conveyor belt, while a sensor is placed next to a conveyor belt to detect workpieces on the belts. Examples for workpiece detection sensors are color sensors or ultrasonic sensors. Each sensor and motor is associated with exactly one conveyor belt. The conveyor belts can be placed in series to move workpieces between locations. A series of conveyor belts is an instance of a composite Thing.
Ramachandran et al. [
Moons et al. [
POST actions
GET tasks, POST TDs, composition hierarchy,
PATCH sensor data
POST tasks HTTP
user Solid Pod Thing(s) with TDs in the Pod that is updated with new data. The gateways are akin to the orchestrator proposed in our work. Since our architecture covers composite Things with actuators, the orchestrator also ofers interactivity and creates a directory structure based on the device composition to enable controlled access to device data.
Bader and Maleshkova [
The lowest-level components of the architecture are the standalone Things, i.e., the sensors and actuators. We assume that these Things are constrained in terms of energy, computation, and storage. In the example of a series of conveyor belts, the standalone Things are motors and sensors. The individual conveyor belts represent the subsystems of the composite series of belts, and each belt comprises a motor and a sensor.
Actuators take commands as input, e.g., run the motor. Sensors and actuators produce output: sensors measure the environment, e.g., a distance value, while actuator output is the current state of the device, like whether a motor is stopped. Such outputs are dynamic Thing data.
In our architecture, we assume that, since standalone Things are the most constrained components, they only interact with one central component, the orchestrator. The orchestrator interacts with the Things to implement specific functionality. Third parties cannot interact with Things directly. This limitation means that dynamic data is only available in real-time on the orchestrator. Sensors and actuators can optionally have associated data that does not change, such as datasheets, manuals, or repair guides, which we refer to as static data. Both static and dynamic Thing data can be linked together and made available to stakeholders as part of our architecture.
The orchestrator is a client that uses the TDs of standalone Things and subsystems to interact
with them. In the WoT, interactivity is based on interaction afordances, which are invitations
to read, write, or observe properties, invoke actions, or subscribe to events [
The orchestrator is initially aware of all TDs through some discovery mechanism. Details on the creation and discovery of TDs are out of scope for this short paper.
In our conveyor belt series example, the sensors and motors are connected to an intermediary entity that translates low-level interactions to HTTP. As a result, sensors and motors take the role of an HTTP server, while the orchestrator is an HTTP client. The intermediary enables reading a sensor’s current value through a property, running the motor through actions and reading the current state (as a property) of the motor. The sensor and motor TDs reference the corresponding conveyor belt using the controlledBy link relation. The link relation leads to a TD that serves as an identifier for the conveyor belts.
The orchestrator is a constrained device with limited computing capabilities and storage capacity, but is not energy constrained, i.e., not battery powered. An example of such a device is an embedded or industrial computer. The orchestrator is the central component of the architecture and acts as a client to the standalone Things and to the Solid Pod.
The orchestrator directly interacts with the Pod and Things and is thus referentially (i.e., it needs to be aware of all IoT devices and the Pod) and temporally (i.e., it initiates all communication and waits for responses) coupled to all entities in the architecture. This coupling enables extensibility, since the Pod can change independently of IoT devices and vice versa. Due to the usage of WoT, the system implementer can focus on implementing the domain logic, and network protocol-specific implementation details are abstracted away.
In general, the orchestrator fulfills two roles. The first role is to act as a relay for data generated by standalone Things: the orchestrator reads raw data from standalone Things and writes this data to the Solid Pod via HTTP. Consequently, the data generated by Things is materialized in the Pod. The orchestrator and the Pod are separate hosts in diferent networks. The orchestrator pushes data to the Pod periodically due to computational and/or connectivity constraints. The static data of the Things, like a PDF-formatted datasheet, is pushed to the Pod during the initialization process and is therefore available as soon as the orchestrator is initialized.
The dynamic and static Thing data is subject to fine-grained access control. The owner of the machine can give stakeholders access to the data of standalone Things or whole subsystems. To achieve controlled access, the orchestrator creates an LDP container tree on the Pod, where nesting corresponds to the compositional hierarchy, i.e., the relationships between standalone Things and subsystems found in TDs. This LDP container tree is created during the orchestrator’s initialization process, i.e., the orchestrator is already aware of all TDs. Each subsystem of the composite has an LDP container with the subsystem’s TD, and the standalone Things are the leaves of the LDP container tree. In such a leaf LDP container, the orchestrator pushes the relevant dynamic and static Thing data and corresponding TDs.
To facilitate the processing and integration of the collected dynamic data in the LDP container,
the orchestrator maps raw data to RDF before pushing the data to the Pod. Following existing
recommendations [
In the conveyor belt example, the LDP container tree is instantiated by creating an LDP container for each conveyor belt (./ConveyorBelt[N]/). Inside each of those LDP containers, the orchestrator creates two LDP containers, one for the belt’s sensor and one for the belt’s motor (./ConveyorBelt0/motor/). When the LDP container tree is created, the orchestrator pushes all static data into the respective LDP containers. Note that the orchestrator should remove all interaction forms from TDs written to the Pod, as only the orchestrator should be able to interact with standalone Things. The orchestrator pushes dynamic Thing data to the Pod while executing tasks or after a task is finished with HTTP PATCH.
The second role of the orchestrator is to read and execute tasks that were written by
stakeholders to a task queue LDP container. The idea of a task queue is similar to an inbox as defined by
Linked Data Notifications ( LDN) [
The orchestrator periodically fetches the latest task and orchestrates the composite based
on the task and the orchestration logic. The orchestrator fulfills tasks by interacting with
the standalone Things that comprise the composite Thing based on interaction afordances
described in TDs. The interaction sequence is implemented as orchestration or control logic.
The orchestrator for the conveyor belt example is implemented using the WoT Scripting API
[
The Solid Pod is the only unconstrained component in the architecture. The Pod acts as the data store for all dynamic and static data of the Things and the corresponding TDs. The Pod also hosts the task queue to link the task history to the Thing data. Stakeholders cannot write to the data user
tasks Pod + data integrator Orchestrator interaction affordances task queue or read any dynamic or static data, unless the machine owner adds the stakeholders’ WebID to an access control list (ACL). Each LDP container and resource has an ACL, or inherits the ACL from parent LDP containers. ACLs can change over time, enabling the machine’s owner to revoke access.
Since the orchestrator is using existing NodeJS libraries1 to interact with the Solid Pod, the Solid server software needs to be compatible with these libraries. Furthermore, Solid does not provide a built-in mechanism to give users access to only the files that they created, by default stakeholders cannot read their already written tasks. To solve this issue, a task’s creator may append their WebID to the task. The orchestrator then modifies the ACL of the corresponding LDP resource. To do so, the orchestrator needs to be able to change ACLs and thus needs full access to the Pod. On an Enterprise Solid Server, client credentials2 can be used to generate credentials for applications like the orchestrator.
The orchestrator pushes Thing data to the Pod periodically due to resource constraints. Each push incurs network latency (i.e., the delay between orchestrator and Pod) because the Pod is assumed to be unconstrained and hosted on a diferent network. The sum of network latency and time between pushes provides an upper bound for the staleness of the data.
Removing the influence of the interval between pushes on staleness requires multiple aspects to change. Because the alternative to pushing Thing data is polling, the Pod (acting as a client when polling) and the orchestrator (acting as a server when polling) need to become servients (server and client at the same time). Polling increases implementation complexity, as the orchestrator needs to act as a server and the Pod needs to be modified to act as a client.
The orchestrator periodically polls the task queue on the Pod for new tasks in case the orchestrator is idle. In case the orchestrator is busy, the polling happens immediately after ifnishing a task. Once a task is being executed, the orchestrator does not poll for new tasks. In the idle case, time to task execution is delayed by the network latency and the polling interval. In the busy case, the time for the remaining tasks and the task fetch time (network latency) delay a new task’s execution. An alternative is to push tasks directly to the orchestrator and persisting 1https://github.com/inrupt/solid-client-js 2https://docs.inrupt.com/ess/latest/services/service-application-registration/ them there. Saving tasks requires the orchestrator to have enough storage for the full task history. This approach also requires orchestrator and Pod to be servients, as the communication pattern is polling instead of pushing.
If the task queue is moved from the Pod to the orchestrator, then the only aspect that still couples Pod and orchestrator together is the Thing data that is exchanged between Pod and orchestrator. Easing constraints further, if the Things can handle a high data query frequency and concurrent queries from both the orchestrator and the Pod, the Pod may directly query the Things and act as a query forwarder that can save data but also fetch the most recent data if requested. Fig. 2 shows this resource-intensive approach, where both orchestrator and Pod must be servients. This approach minimizes delays due to fewer intermediaries between IoT devices and end users (i.e., stakeholders).
In the example of an industrial machine, the owner of the machine can naturally access all data. Customers wanting to use the machine, on the other hand, only have high-level access to the task queue. All stakeholders can expect the orchestrator to give read and write access exclusively to the submitter of a task. Another use case is maintenance work being done on the machine by an external party. The owner can give selective access to relevant data to this third party. For example, if a conveyor belt that is part of the machine is broken, the repair process can be made easier by providing access to the motor and sensor data of that conveyor belt. The machine owner simply gives read access to the relevant LDP container. Access can also be revoked at a later time, enabling, for example, temporary authorization based on the duration of contracts.
This short paper presented an architecture and corresponding implementation that uses Semantic Web technologies to enable access to data of composite machines with fine-grained access control. WoT TDs ease system integration and RDF is used for data integration. An orchestrator component enables access-control on a data store by mirroring the hierarchical relationships between standalone devices and subsystems that form the composite to the data store. The owner of the machine can give specific stakeholders access to relevant parts of the data based on the hierarchy. The architecture provides a mechanism to enable stakeholders to interact with the composite machine. The composite Thing and the data store can both evolve independently, as they are decoupled. However, the orchestrator, which implements control functionality and is responsible for moving data, is coupled to the composite Thing and the Pod. Future work includes applying the architecture to more use cases, evolving the architecture, and an empirical evaluation of the performance characteristics beyond theoretical latency bounds. Acknowledgements This work was funded by the German Federal Ministry for Economic Afairs and Climate Action (BMWK) through the Antrieb 4.0 project (Grant No. 13IK015B).