Introduction

The proliferation of interconnected devices within the Internet of Things (IoT) paradigm has paved the way for sophisticated Cyber-Physical Systems (CPS) [2] that bridge the digital and physical realms. These systems promise enhanced automation, efficiency, and user experiences across diverse domains, from smart homes and buildings to industrial control and healthcare. However, the increasing complexity and heterogeneity of devices pose significant challenges [4]. Many IoT devices operate under strict constraints regarding processing power, memory, and energy consumption. Simultaneously, the escalating cost of energy and growing environmental concerns necessitate energy-efficient solutions, particularly in large-scale deployments where cumulative consumption can be substantial. Therefore, minimizing the computational load and complexity on individual devices is paramount for the sustainable development and operation of CPS.

The Web of Things (WoT) initiative [26], spearheaded by the W3C, aims to address heterogeneity and complexity by leveraging established web technologies for IoT integration. Central to the WoT architecture [9] are servients: software stacks that encapsulate the logic for interacting with physical or virtual ’things’. A servient can expose a thing’s capabilities (acting as a server), consume capabilities from other things (acting as a client), or perform both roles as an intermediary. By abstracting device-specific protocols and functionalities, servients simplify interaction and enhance interoperability. However, conventional WoT servient implementations often require embedding server components for each communication protocol they support (e.g., HTTP, MQTT, CoAP). In scenarios with numerous servients and multiple protocols, this leads to a proliferation of server instances, increasing deployment complexity, configuration overhead, and the cumulative resource footprint. While servients offload some tasks from the physical device, the servient itself can still represent a significant computational burden. Lightweight approaches like WoT microservients [22] exist, but often still require careful management of communication resources. This paper addresses this challenge by proposing an architectural approach for developing lightweight WoT servients, named WoT-Core, based on our framework.Footnote 1 Our core idea is to externalize the server-side communication logic from the servient. Instead of each servient running its own protocol servers, we introduce intermediary brokers, one for each supported communication protocol. Servients then act purely as clients, connecting to these brokers to expose their affordances and communicate. This architectural shift introduces a trade-off: it simplifies individual servients but concentrates communication logic in brokers, potentially creating dependencies and communication bottlenecks. While this centralization can be a limitation, as discussed in Sect. “Evaluation”, it also offers distinct advantages in specific scenarios. This architectural shift aims to achieve several objectives:

  • Reduced Deployment Complexity: Significantly decreases the number of server instances required. For example, in a system with 20 servients each supporting HTTP, MQTT, and CoAP, our approach reduces the server count to just 3 (one broker per protocol).

  • Lower Servient Resource Consumption: By offloading server responsibilities (e.g., connection management, request handling) to the brokers, the computational load on individual servients is reduced. This can lead to lower CPU and memory usage, making the approach suitable for more constrained environments, complementing efforts like those in [22].

  • Potential Energy Savings: Reduced processing load on servients translates to potentially lower energy consumption, contributing to system sustainability [4]. Direct device interaction is also mediated, potentially reducing unnecessary device wake-ups.

  • Simplified Servient Development: Developers focus on the core logic of the thing and client-side interaction with brokers, rather than implementing and managing multiple server types within each servient.

Our approach utilizes a centralized configuration mechanism, allowing servients to load their state and broker connection details dynamically. Communication between things, potentially across different protocols, is orchestrated via the brokers and a dedicated internal ‘connector‘ component that manages interaction links. This facilitates complex behaviors and interactions, such as context-aware energy saving strategies (e.g., opening a window instead of activating AC based on external temperature).

The main contributions of this paper are:

  1. 1.

    A layered architecture (WoT-Core) centered around lightweight servients, centralized protocol brokers, a configuration repository, and an orchestrating Core.

  2. 2.

    A mechanism for enhancing standard WoT TD [6] with custom ‘link‘ relations to embed architecture-specific configuration and relationship information.

  3. 3.

    A declarative inter-Thing communication mechanism facilitated by a virtual ‘connector‘ Thing, enabling complex interactions based on configurable links.

  4. 4.

    A quantitative evaluation that analyzes the trade-offs of the proposed architecture, specifically regarding servient resource consumption versus interaction latency, compared to a traditional implementation as the system scales.

In this paper, we elaborate on the system components, the specific use of Thing Descriptions including custom link relations, the system initialization flow, and the mechanism for establishing inter-thing communication links. The proposal’s viability is demonstrated through a smart home application scenario. We posit that this architecture provides a more scalable and maintainable foundation for building complex, heterogeneous CPS, potentially integrating with platforms like Digital Dice [14, 15] for enhanced capabilities.

The remainder of this paper is structured as follows: Sect. “Background and Related Work” discusses the background technologies and relevant related work. Section “Application scenario” presents the application scenario used throughout the paper. Section “Development of lightweight WoT servients” details the proposed architecture and its components for developing lightweight WoT servients. Section “Evaluation” provides a quantitative and qualitative evaluation of the proposed approach. Finally, Sect. “Conclusions and Future Work” concludes the paper and outlines future research directions.

Background and Related Work

This section provides foundational knowledge and reviews related work pertinent to our proposed lightweight WoT servient architecture. We cover the interplay between IoT, WoT, and CPS, delve into design considerations for these systems, examine communication protocols and middleware solutions, and situate our contribution within the existing landscape.

Design of IoT, WoT and Cyber-Physical Systems

The terms IoT, WoT, and CPS represent overlapping but distinct concepts crucial for understanding modern connected systems. IoT forms the base layer, encompassing the network of physical devices embedded with sensors, actuators, and connectivity. WoT builds upon IoT, applying web standards (like HTTP, REST APIs, JSON, WebSockets) and architectural patterns to standardize device interactions and enable seamless integration into web applications [26]. CPS represents a higher level of integration [2], combining computational elements with physical processes, often involving feedback loops and complex control logic. CPS frequently utilizes IoT devices as sensors and actuators but emphasizes the tight coupling between the cyber and physical components [11]. Designing robust and scalable CPS requires addressing challenges like heterogeneity, distributed management, and component integration [4].

Effective CPS design necessitates descriptive mechanisms for both individual components and their interactions within the system architecture. The W3C WoT provides specifications for this:

  • WoT Thing Description (TD) [6]: A JSON-based format for describing the metadata and capabilities (properties, actions, events) of a Thing. TDs define interaction affordances and specify the protocols and communication details needed to interact with the Thing.

  • WoT Architecture [9]: Defines the abstract architecture, interaction patterns (e.g., Thing-to-Thing, Remote Access, Digital Twin), and building blocks (like servients) for constructing WoT systems.

Beyond these standards, various approaches aim to simplify WoT and CPS development. Table 1 provides a comparative overview of our WoT-Core architecture against related concepts. Model-driven engineering (MDE) approaches like ThingML [3] or those focused on automatic servient generation [5] simplify development by generating code from high-level models. While effective, they primarily address the creation of individual servients rather than the overarching deployment architecture. WoT Microservients [22] specifically target resource-constrained microcontrollers, optimizing the servient footprint for embedded devices. Our WoT-Core architecture is complementary; it focuses on simplifying servients that may run on more capable edge devices (e.g., Raspberry Pi) by externalizing server logic, thereby addressing deployment complexity and resource management at the system level. WoT-Core’s primary contribution is the architectural pattern of centralized brokerage, whereas other approaches focus on code generation or extreme footprint reduction.

Table 1 Comparison of WoT-Core with related WoT development approaches
Full size table

Communication in CPS

Effective communication is fundamental to CPS [27], enabling interaction between distributed components. CPS deployments often involve a diverse mix of communication technologies [23], spanning different layers of the network stack. The choice of protocols is often dictated by application requirements, legacy system integration, and resource constraints. Our architecture focuses on established protocols like HTTP for its ubiquity in web APIs, MQTT for its efficiency in publish-subscribe messaging for IoT, and KNX to demonstrate integration with a widespread building automation standard. While emerging standards like Matter [16] promise to unify the smart home landscape, supporting established protocols like KNX [20] and Z-Wave remains crucial for interoperability with existing installations. Similarly, although CoAP [24] is highly optimized for constrained devices, MQTT often provides a more flexible solution when a broker-based architecture is already a central part of the system design, as it is in our case.

  • HTTP/HTTPS: Ubiquitous request/response protocol, forming the backbone of the web. Versions like HTTP/2 and HTTP/3 offer performance improvements. Suitable for many interactions but can be verbose and connection management can be resource-intensive for servers handling many clients.

  • MQTT: A lightweight publish/subscribe messaging protocol operating over TCP (typically) [10]. Well-suited for IoT due to low overhead, asynchronous nature, and broker-based architecture. Requires a central broker.

  • CoAP (Constrained Application Protocol): Designed for constrained devices and networks, often running over UDP. Features include asynchronous messaging, reliability options, and resource discovery. Similar to HTTP but optimized for low power and low bandwidth.

  • WebSocket: Enables full-duplex communication over a single TCP connection, ideal for real-time, persistent communication between clients and servers.

  • KNX: A standard for home and building automation [20], often using twisted pair, powerline, RF, or IP tunnelling. It uses a group address communication model on a bus system. Interaction typically requires a gateway.

  • Matter: An emerging application layer connectivity standard aiming to unify smart home ecosystems, built on IP (Wi-Fi, Thread) and Bluetooth LE.

This protocol heterogeneity presents a major integration challenge. The WoT paradigm addresses this by using the Thing Description [6] to abstract the underlying protocols. The TD’s ‘forms‘ element specifies how to interact with an affordance using one or more protocols (e.g., providing URLs for HTTP, MQTT topics, CoAP URIs). WoT Binding Templates [8] further detail protocol-specific information (e.g., HTTP methods, MQTT QoS). Our approach leverages this abstraction but centralizes the handling of these protocols in external brokers, allowing servients to interact via a unified internal mechanism while the brokers manage the diverse external communications. We demonstrate this extensibility by incorporating KNX support via a dedicated broker that encapsulates the gateway interaction logic, using programming patterns similar to those explored in WoTnectivity [13] for protocol adaptation.

Middlewares for Integration in CPS

Middleware plays a crucial role in bridging the gap between diverse applications and underlying heterogeneous hardware and network infrastructure in complex distributed systems like CPS [19]. It provides abstractions and services that simplify development, enhance interoperability, manage resources, and enable value-added functionalities such as data aggregation, event correlation. The architecture of WoT-Core, which uses centralized brokers for communication, aligns closely with Message-Oriented Middleware (MOM) [10]. However, it also shares characteristics with the serverless computing paradigm, particularly function-as-a-service (FaaS). In a serverless model, developers deploy application logic in stateless functions, and the cloud provider manages the underlying server infrastructure. Similarly, our lightweight servients contain the core application logic for a Thing, while the communication server infrastructure is offloaded to and managed by the brokers. This reduces the operational burden on the developer, echoing the goals of serverless. Unlike a pure cloud serverless approach, our brokers can be deployed on-premises or at the edge, providing more control over latency and data privacy, which is often a requirement in CPS.

Our proposed architecture incorporates elements of both MOM and SOM. The core interaction between servients and the external world (via brokers) relies heavily on protocols often used in MOM systems (MQTT, potentially others like AMQP if brokers were added). The inter-thing communication facilitated by the internal ‘connector‘ also follows an event-driven, message-passing pattern. However, the overall system structure, with distinct components like the Core, Protocol Manager, and Config Repository, and the way Things expose their capabilities via TDs [6], aligns with service-oriented principles. The intermediary brokers themselves can be viewed as specialized communication services.

Compared to existing WoT platforms or frameworks like WoT Store [21], WoTpy [12], or Digital Dice [14], our approach distinguishes itself by its explicit focus on lightweight servients achieved through centralized communication brokerage. While other platforms provide tools for building and managing WoT systems, our contribution lies in the specific architectural pattern designed to reduce servient complexity and resource load by externalizing protocol server logic. This middleware approach aims to support standard WoT interaction patterns defined in the WoT Architecture [9] while optimizing for scalability and maintainability in potentially large, heterogeneous CPS deployments.

Application Scenario

To illustrate the practical application and benefits of our lightweight WoT servient architecture, we present a smart home scenario focused on automating a user’s morning routine while prioritizing energy efficiency. This scenario, depicted in Fig. 1, involves several interconnected smart devices with varying functionalities and potentially different underlying communication protocols. For the evaluation in Sect. “Evaluation”, this scenario is assumed to be deployed in a testbed environment where lightweight servients run on Raspberry Pi 4 devices, and the HTTP and MQTT brokers are hosted on a more powerful local server (e.g., an Intel NUC) on the same network. The Zigbee devices are connected via a Zigbee-to-MQTT gateway.

Fig. 1
figure 1

Application Scenario: A smart home morning routine automation

Full size image

The devices of this scenario are:

  1. (a)

    Two Zigbee bulbs (bedroom and bathroom)

  2. (b)

    A KODI media player (connected via IP, likely HTTP/WebSocket API)

  3. (c)

    An alarm clock (acting as a central coordination point)

  4. (d)

    A movement sensor (e.g., PIR sensor, potentially Zigbee or Wi-Fi)

  5. (e)

    An air conditioning (AC) split unit (e.g., IR controlled via gateway, or direct IP)

  6. (f)

    A shower water heater (e.g., smart plug or direct control)

  7. (g)

    Smart blinds (e.g., Zigbee, Z-Wave, or Wi-Fi)

  8. (h)

    A light sensor (e.g., measuring ambient light, potentially Zigbee or Wi-Fi)

In our proposed architecture, each of these devices would be represented by a Thing, managed by one or more lightweight servients running within the WoT-Core framework. A key component in this scenario is a virtual Thing, the scheduler, notionally deployed on the alarm clock’s servient. This scheduler orchestrates interactions based on events and time, embodying the application logic described in the introductory sections. The desired automation sequence unfolds as follows:

  1. 1.

    Alarm Trigger: When the user-set alarm time arrives, the alarm clock Thing emits an event.

  2. 2.

    Wake-up Sequence: The scheduler servient captures this event. It interacts with the light sensor Thing (h) to check the ambient light level.

    • If it is daytime (high ambient light), the scheduler invokes an action on the smart blinds Thing (g) to open them.

    • If it is dark (low ambient light), the scheduler invokes an action on the bedroom Zigbee bulb Thing (a) to turn it on gradually.

    Simultaneously, the scheduler invokes an action on the KODI media player Thing (b) to start playing nature sounds, perhaps with increasing volume.

  3. 3.

    User Activity Detection: When the user gets out of bed, the movement sensor Thing (d) detects motion and emits an event.

  4. 4.

    Comfort Preparation: The scheduler captures the motion event. It then:

    • Invokes an action on the AC Thing (e) to set a comfortable temperature. (Further logic could check current temperature first).

    • Invokes an action on the shower heater Thing (f) to turn it on.

    • Invokes an action on the bathroom Zigbee bulb Thing (a) to turn it on.

    • Invokes an action on the KODI media player Thing (b) to stop the music.

  5. 5.

    Energy Saving:

    • The AC Thing (e) could have internal logic or be controlled by the scheduler to turn off once the target temperature is reached.

    • The shower heater Thing (f) is only turned on when activity is detected, not pre-emptively.

    • Lights (a) are turned on only if needed based on ambient light (h) or presence detection (d). Blinds (g) are used as an alternative light source.

    • If the movement sensor (d) detects no motion for a period, the scheduler could turn off lights (a) and potentially adjust the AC (e).

Table 2 summarizes the primary interaction affordances and relationships between the devices involved in this scenario.

Table 2 Interaction affordances and relationships of devices in the scenario
Full size table

The scenario highlights the need for an architecture that can seamlessly integrate devices using potentially different protocols (Zigbee, HTTP/WebSocket, KNX if AC/blinds used it, etc.). The lightweight servient approach facilitates this by having dedicated brokers handle the protocol specifics (e.g., a Zigbee broker interacting with a USB dongle/gateway, an HTTP broker, a KNX broker via an IP gateway [20]). The servients themselves, including the one hosting the scheduler logic, interact through a unified internal mechanism (e.g., MQTT messages relayed by the Core/brokers), simplifying the development of the automation logic. The energy savings are achieved not just by device capabilities but by the orchestrated interactions defined in the scheduler, enabled by the underlying communication and integration architecture.

Development of Lightweight WoT Servients

This section details the proposed architectural solution for developing and integrating lightweight WoT servients. We present the overall architecture (named WoT-Core), outline its core functionalities, elaborate on the structure and use of Thing Descriptions within this architecture, describe the system initialization process, and explain the mechanism for establishing communication links between Things.

Architectural Solution: WoT-Core

The WoT-Core architecture, depicted in Fig. 2, is designed as a layered system with distinct components collaborating to manage lightweight servients and their interactions. The primary layers and components are:

Fig. 2
figure 2

WoT-Core Architecture Overview

Full size image
  1. 1.

    Config Repository: This layer serves as the central storage for all static configuration data required by the system.

  • Thing Descriptions (TDs): Contains the standard W3C Thing Description files [6] for all physical and virtual Things managed by the system. These TDs define the capabilities and interaction mechanisms of each Thing. Includes standard TDs and potentially custom ones incorporating specific link relations (see Sect. “Information included in the Thing Description”).

  • Things UIs: A repository storing UI templates (e.g., HTML/JS components) associated with specific Thing types. These templates can be dynamically loaded by front-end applications or management consoles to provide user interfaces for interacting with Things. Links to these UIs can be included in the TDs using the ‘renderedBy‘ relation.

  • Servient Configs: Holds configuration files specific to each servient instance. This includes details about the Things the servient exposes and consumes, persistent state information, and crucially, the connection details for the necessary intermediary brokers. Virtual Thing implementations or behavior configurations might also reside here or be linked from here.

  • Core Configuration: Defines system-level settings. This includes a list of servients (both standard and system-specific) to be automatically started, configurations for system services (like authentication or discovery), and potentially pre-defined inter-Thing communication links to be established by the ‘connector‘ component upon startup. It also dictates the operational mode of the connector (centralized vs. distributed).

  • Thing Descriptions (TDs): Contains the standard W3C Thing Description files [6] for all physical and virtual Things managed by the system. These TDs define the capabilities and interaction mechanisms of each Thing. Includes standard TDs and potentially custom ones incorporating specific link relations (see Sect. “Information included in the Thing Description”).

  • Things UIs: A repository storing UI templates (e.g., HTML/JS components) associated with specific Thing types. These templates can be dynamically loaded by front-end applications or management consoles to provide user interfaces for interacting with Things. Links to these UIs can be included in the TDs using the ‘renderedBy‘ relation.

  • Servient Configs: Holds configuration files specific to each servient instance. This includes details about the Things the servient exposes and consumes, persistent state information, and crucially, the connection details for the necessary intermediary brokers. Virtual Thing implementations or behavior configurations might also reside here or be linked from here.

  • Core Configuration: Defines system-level settings. This includes a list of servients (both standard and system-specific) to be automatically started, configurations for system services (like authentication or discovery), and potentially pre-defined inter-Thing communication links to be established by the ‘connector‘ component upon startup. It also dictates the operational mode of the connector (centralized vs. distributed).

  • Thing Descriptions (TDs): Contains the standard W3C Thing Description files [6] for all physical and virtual Things managed by the system. These TDs define the capabilities and interaction mechanisms of each Thing. Includes standard TDs and potentially custom ones incorporating specific link relations (see Sect. “Information included in the Thing Description”).

  • Things UIs: A repository storing UI templates (e.g., HTML/JS components) associated with specific Thing types. These templates can be dynamically loaded by front-end applications or management consoles to provide user interfaces for interacting with Things. Links to these UIs can be included in the TDs using the ‘renderedBy‘ relation.

  • Servient Configs: Holds configuration files specific to each servient instance. This includes details about the Things the servient exposes and consumes, persistent state information, and crucially, the connection details for the necessary intermediary brokers. Virtual Thing implementations or behavior configurations might also reside here or be linked from here.

  • Core Configuration: Defines system-level settings. This includes a list of servients (both standard and system-specific) to be automatically started, configurations for system services (like authentication or discovery), and potentially pre-defined inter-Thing communication links to be established by the ‘connector‘ component upon startup. It also dictates the operational mode of the connector (centralized vs. distributed).

  1. 2.

    Execution Boundary: This logical layer encompasses the running instances of the WoT servients. Each servient instance manages one or more Exposed Things (representing device functionalities it provides access to) and Consumed Things (representing external Things it interacts with). Crucially, these are lightweight servients, containing primarily the application logic and client-side code for broker interaction, not embedded protocol servers. System-level servients providing core functionalities (e.g., the connector, authentication handlers) also reside here.

  2. 3.

    Protocol Manager: This component acts as an abstraction layer for communication protocols. It comprises:

  • Protocol Bindings: Definitions specifying how WoT interactions map to concrete protocol operations. This includes standard WoT binding templates [8] and potentially custom extensions (e.g., for KNX) defining protocol-specific metadata like HTTP methods (‘htv:method‘), KNX group addresses (‘knx:group‘), or data types (‘knx:datatype‘).

  • Protocol Implementations / Brokers: These are the intermediary brokers responsible for handling the server-side aspects of each protocol. Examples include an HTTP/WebSocket broker, an MQTT broker, and potentially a dedicated KNX broker that interfaces with a KNX IP gateway [20]. Servients communicate *through* the Core and Protocol Manager, which directs interactions to the appropriate broker based on the TD ‘forms‘ and binding information.

  1. 4.

    Device Boundary: Represents the actual physical devices (sensors, actuators) or external virtual/emulated devices that the WoT-Core system interacts with. Communication crosses this boundary via the Protocol Manager and its brokers.

  2. 5.

    Core: The central orchestrator of the system. Its responsibilities include:

  • Reading configurations from the Config Repository.

  • Instantiating and managing the lifecycle of servients within the Execution Boundary.

  • Mediating interactions between servients and the Protocol Manager/Brokers based on TD information [6].

  • Managing the instantiation and configuration of inter-Thing communication links via the ‘connector‘ component.

  • Performing data validation based on schemas defined in TDs for inputs (to consumed things) and outputs (from exposed things).

  • Coordinating with system services like authentication and discovery.

  1. 6.

    Core Communication Servers: While individual servients don’t host protocol servers, the WoT-Core system itself may expose APIs for management, monitoring, or external interaction. These could be implemented using standard servers like HTTP or rely on the MQTT broker for asynchronous event notifications. This differs from the protocol brokers which handle device-level communication. This architecture centralizes protocol handling in brokers, allowing servients to remain lightweight and focused on application logic and client-side communication. The Core orchestrates the system based on declarative configurations (TDs, Servient Configs), promoting modularity and maintainability.

WoT-Core Functionality Overview

The WoT-Core component acts as the central orchestrator, managing the lifecycle and interactions within the lightweight servient architecture. Its functionality spans both the initial system setup and ongoing runtime operations, as summarized in Fig. 3.

Fig. 3
figure 3

Functionalities of the WoT-Core component on system startup and runtime

Full size image

At system startup, WoT-Core is responsible for bootstrapping the entire environment. This involves retrieving the overall application description, loading the relevant Thing Descriptions and servient configurations from the repository, and initiating the lightweight servient instances within the execution boundary. Following servient startup, it establishes the crucial communication links between Things using the configured Connectors, as detailed in Sect. “Communication of Things via Connectors”. Furthermore, the startup phase critically handles security foundations by managing credential acquisition, setting up necessary authorization policies and trust relationships between components, and configuring authentication mechanisms to ensure secure communication channels.

During runtime, WoT-Core transitions to managing the dynamic operation of the system. A core function is the Things dispatcher, which routes interactions and data flow related to Thing affordances. Continuous system health and performance are tracked through integrated system monitoring and accounting services. WoT-Core also supports the dynamic nature of CPS by providing discovery services to locate Things or services, alongside capabilities to add or remove Things gracefully while the system is running. Essential infrastructural support includes maintaining directory services for resource lookup and managing an event register for handling asynchronous notifications across the system. These runtime functions ensure the operational integrity, adaptability, and observability of the WoT-based CPS.

Information Included in the Thing Description

The Thing Description (TD) [6] remains the cornerstone for describing devices within our WoT-Core architecture, adhering to the W3C standard. TDs provide a machine-readable format detailing a Thing’s identity, metadata, security requirements, and interaction affordances (properties, actions, events). The ‘forms‘ array within each affordance specifies the necessary communication metadata (e.g., protocol, target URL/topic, content type, protocol-specific details via binding templates [8]) for interaction. In addition to standard TD elements, our WoT-Core architecture leverages the ‘links‘ array within the TD to encode architecture-specific relationships and metadata, enhancing discoverability and system configuration. While the W3C TD specification [6] defines standard link relation types (e.g., ‘alternate‘, ‘icon‘), it allows for custom relations via URIs or registered strings. Our approach defines several custom relations, summarized in Table 3, to embed structural and configuration information directly within the TD:

Table 3 Custom link relation types used within WoT-Core TDs
Full size table

Listing 1 shows an example snippet from a light sensor TD, illustrating the use of ‘renderedBy‘ to link to its UI and ‘connectedTo‘ to indicate relationships with a smart blind and a light bulb Thing, potentially used by the scenario’s scheduler.

Listing 1
figure a

Example TD ’links’ array snippet for a Light Sensor.

Full size image

By embedding this information in the TD ‘links‘, we allow the WoT-Core system (specifically the Core component) to automatically discover related resources, configurations, and dependencies during initialization and runtime, facilitating dynamic setup and potentially enabling richer interaction patterns based on these declared relationships. This approach keeps essential configuration pointers close to the Thing’s definition while remaining compliant with the standard TD structure [6].

Initialization of the Servient From the TD

The initialization process within the WoT-Core architecture ensures that all components, lightweight servients, and their associated Things are correctly configured and started. Figure 4 illustrates the sequence of steps involved. The different steps are:

Fig. 4
figure 4

WoT-Core System Initialization Sequence

Full size image
  1. 1.

    System Startup: The process begins with the launch of the central Core component. The Core first initializes essential system services, such as the necessary communication brokers (e.g., MQTT broker, HTTP server for internal APIs) managed by the Protocol Manager, and potentially system-level servients like a Thing Directory or Thing Identity Service (TIS) if used for discovery or security. Configuration for these core services is loaded from the Core Configuration in the Config Repository.

  2. 2.

    Servient Configuration Loading: The Core reads the Core Configuration to identify the list of lightweight servients that need to be instantiated within the Execution Boundary. For each servient listed, the Core fetches its specific configuration file(s) from the Servient Configs repository. These files contain references to the TDs of the Things the servient will expose and/or consume, broker connection details, and any persistent state information.

  3. 3.

    Servient Authorization (Optional): If a security mechanism involving a TIS is employed, the Core interacts with the TIS to register each new servient instance. The TIS would generate credentials (e.g., API keys, tokens) required for the servient to securely communicate with brokers or other services, returning these credentials to the Core. (Note: Detailed security mechanisms are beyond the scope of the initial description but are crucial for production systems).

  4. 4.

    Servient Instantiation and Initialization: The Core uses the loaded configurations (and credentials, if applicable) to instantiate each lightweight servient process within the Execution Boundary. During initialization, the Core provides each servient instance with:

    • The TDs [6] of the Things it needs to manage (both exposed and consumed).

    • Connection information for the required protocol brokers (obtained from the servient’s config).

    • Security credentials (if used).

    • Configuration for any pre-defined inter-Thing links it participates in, derived from the Core Configuration or its own configuration.

    The servient then uses this information to establish client connections to the relevant brokers and prepare to handle interactions for its assigned Things. The Core monitors the startup status of each servient, potentially implementing retry logic for failures.

  5. 5.

    Servient Exposition: Once initialized, the servient registers its presence and the Things it exposes with the relevant system components (e.g., Core, potentially a Thing Directory). For exposed Things, it starts listening for commands or requests relayed *from* the protocol brokers (via the Core). For consumed Things, it prepares to send requests *to* the brokers (via the Core) based on its internal logic or triggers. Communication primarily occurs via client connections to the brokers specified in the TD forms (e.g., subscribing to MQTT topics, preparing to make HTTP requests via the HTTP broker).

  6. 6.

    Establishing Inter-Servient Communication Links: After individual servients are running, the Core (or a dedicated ‘connector‘ servient, depending on the configuration) uses the link configurations (from Core Config or Servient Configs) to establish communication pathways between Things, potentially managed by different servients. This involves setting up subscriptions and routing logic, often utilizing the MQTT broker for asynchronous event propagation between servients within the same Execution Boundary. This process is detailed further in Sect. “Communication of Things via Connectors”.

This structured initialization process ensures that lightweight servients are correctly configured with their TDs, broker connections, and interaction links, enabling them to participate in the overall CPS functionality orchestrated by the WoT-Core.

Communication of Things via Connectors

A key aspect of the WoT-Core architecture is enabling interaction between different Things. To manage these interactions without embedding complex routing logic within each servient, we introduce a specialized virtual Thing called the connector. This section is broken down to detail its mechanism.

Connector Role and Actions

The connector acts as a dedicated mechanism for establishing, managing, and tearing down communication links between affordances of different Things. It operates based on configuration provided by the Core, derived from the Core Configuration or specific servient configurations. The connector itself is typically implemented as a system-level servient within the Execution Boundary. The core functionality is exposed through two primary actions of the connector Thing:

  • ‘link’ action: This action establishes a directed communication pathway from a source affordance (typically an event or property update of one Thing) to one or more target affordances (typically an action invocation or property write on other Things).

  • ‘unlink’ action: This action removes a previously established link, stopping the propagation of events or data between the specified source and target(s).

Link Configuration and Data Flow

The ‘link’ action takes parameters specifying the source, the target(s), and the nature of the relationship, as shown in the example configuration in Listing 2. This example links a switch’s ‘onChangeStatus’ event to a light bulb’s ‘status’ property. The ‘relationType: "forever"’ ensures this link is persistent. Table 4 summarizes the key parameters used to configure a ‘link‘ action.

Listing 2
figure b

Example Connector Configuration Snippet, e.g., ‘relationType: "forever"’.

Full size image
Table 4 Summary of parameters for the Connector’s ‘link‘ action
Full size table

The connector essentially acts as a configurable event router or workflow engine operating at the WoT interaction level, enabling complex emergent behaviors from simpler, lightweight servient components. It relies on the underlying asynchronous messaging infrastructure (MQTT managed by a core broker [10]) for communication between the involved servients and the connector servient itself.

Evaluation

This section evaluates the proposed WoT-Core architecture. We first present a quantitative analysis to measure the trade-offs in resource consumption and latency as the system scales. Following this, we provide a qualitative discussion of the benefits, limitations, and key considerations such as security and reliability.

Quantitative Analysis

To validate our claims, we conducted an experiment to measure how system performance scales with an increasing number of devices. We compared two implementations running on a Raspberry Pi 4 (4GB RAM), where each "device" is a virtual light bulb Thing that can be controlled:

  • Traditional Servient: A Python servient using the ‘wotpy‘ framework [12]. For each device added, a new server binding (e.g., an HTTP endpoint) is created within the same process, increasing its complexity and resource load.

  • WoT-Core Lightweight Servient: Our proposed lightweight Python servient, which manages all devices within a single process. For each device added, only a new set of MQTT topic subscriptions/publications is created; no new server infrastructure is required.

We scaled the number of devices managed by a single servient instance from 1 to 20 and measured the steady-state CPU and Memory usage of the servient process, and the average end-to-end latency for a control command.

Resource Consumption

Figure 5 shows how the resource consumption of the servient process scales. The results are stark. The Traditional Servient’s CPU and memory usage grow substantially with each added device, as the overhead of managing multiple server endpoints accumulates. In contrast, the WoT-Core servient’s resource footprint grows at a much slower, more linear rate. This is because adding a device only requires lightweight client-side resources (topic handlers) rather than heavyweight server-side components. This demonstrates the superior scalability of our approach in terms of resource efficiency, especially in deployments with a high density of Things.

Fig. 5
figure 5

Comparison of servient resource consumption as the number of managed devices increases

Full size image

Response Latency

Figure 6 presents the average end-to-end latency as the system scales. The WoT-Core architecture consistently exhibits higher latency due to the additional communication hops through the central broker and connector. Both approaches see a slight increase in latency as the number of devices and overall system traffic grows. This result reinforces the fundamental trade-off of our architecture: gaining significant resource scalability at the cost of higher, though relatively stable, response times. This makes the architecture well-suited for applications where resource efficiency at scale is more critical than millisecond-level latency.

Fig. 6
figure 6

Comparison of end-to-end interaction latency as the number of managed devices increases

Full size image

Potential Benefits

The quantitative analysis supports the primary motivation for this architecture: creating more manageable and resource-efficient WoT systems. The key benefits, framed by our evaluation, are:

  • Reduced Complexity and Overhead:

    • Deployment: Centralizing protocol server logic into fewer broker instances significantly simplifies deployment compared to embedding servers in each of potentially hundreds or thousands of servients. Managing 3 brokers (HTTP, MQTT, KNX) is substantially easier than managing 60 servers (20 servients * 3 protocols) in the example scenario.

    • Development: Developers are shielded from the intricacies of server-side protocol implementation for multiple protocols within each servient, potentially speeding up development and reducing errors, aligning with goals of model-driven approaches like [5].

  • Resource Efficiency and Scalability:

    • Servient Footprint: As demonstrated in Fig. 5, offloading server tasks leads to a verifiable and dramatic reduction in CPU and memory requirements as the system scales. This makes the approach highly suitable for environments where servients on constrained edge devices must manage a high density of Things, a goal similar to that of [22].

    • Energy Consumption: Reduced computational load, as measured, directly translates to potential energy savings at the servient level [4]. This is crucial for sustainable CPS development, especially in large-scale deployments.

  • Enhanced Interoperability and Flexibility:

    • Protocol Mediation: The brokers act as natural points for protocol mediation. The declarative linking mechanism via the connector allows interactions between Things that might natively use different protocols (e.g., Zigbee to KNX [20]), as long as a broker exists for each protocol.

    • Dynamic Reconfiguration: The reliance on configuration files (Servient Configs, Core Config) and the connector mechanism allows for dynamic changes in system behavior (e.g., adding/removing links, enabling/disabling features) often without requiring code changes or redeployment of the servients themselves.

Limitations and Challenges

Despite the potential advantages, the proposed architecture also introduces limitations and challenges that must be considered:

  • Broker as Single Point of Failure/Bottleneck: Each protocol broker represents a potential single point of failure. If a broker fails, all communication using that protocol ceases. Similarly, brokers can become performance bottlenecks if they cannot handle the aggregate load from all connected servients. High availability and scalability solutions (e.g., clustered brokers, load balancing) are essential for robust deployments, adding complexity to the broker infrastructure itself.

  • Increased Latency: As shown in our quantitative analysis (Fig. 6), introducing intermediary brokers inevitably adds latency to the communication path. While acceptable for many applications, this makes the architecture unsuitable for hard real-time CPS applications where deterministic, low-latency responses are required.

  • Dependence on Network Connectivity: The model relies heavily on reliable network connectivity between servients and their respective brokers. Network partitions or instability can significantly impact system functionality.

  • Connector Complexity: While the connector simplifies inter-Thing logic within servients, the connector itself (or its configuration) can become complex to manage as the number of links and the intricacy of interaction patterns grow. Debugging issues within the connector’s logic or configuration might be challenging.

Security Considerations

Centralizing communication through brokers alters the security landscape and requires a structured architectural approach. While it simplifies security on the lightweight servient (which only needs to manage client-side credentials), it makes the brokers and the configuration repository critical security assets that must be robustly protected. A comprehensive security model for WoT-Core should be based on the principles of zero trust, where trust is never assumed and must be explicitly verified.

Threat Model

Key threats in this architecture include:

  • Broker Hijacking: An attacker gaining control of a broker could intercept, modify, or inject malicious messages (man-in-the-middle attack), compromising the entire system.

  • TD Tampering: A malicious actor could modify a Thing Description in the repository to redirect clients to a malicious endpoint or alter security metadata to bypass controls.

  • Unauthorized Access: A compromised or malicious servient could attempt to access affordances it is not authorized to use, or an external client could try to bypass the broker infrastructure.

Conceptual Security Architecture

To mitigate these threats, a multi-layered security architecture is proposed:

  • Authentication: All communication channels must be secured using transport-level encryption (e.g., TLS 1.3). For broker-servient communication, mutual TLS (mTLS) is recommended. This ensures that the servient authenticates the broker (preventing connections to rogue brokers) and the broker authenticates the servient (ensuring only legitimate servients can connect), using cryptographically signed certificates.

  • Authorization: Authentication alone is insufficient. Fine-grained authorization is needed to enforce what a legitimate servient is allowed to do. This can be implemented using a token-based system, such as OAuth 2.0, integrated with the Core. In this model, a servient would first authenticate with a central Authorization Server to receive an access token. This token, containing specific scopes (e.g., ‘write:lightbulb1:status’), would then be presented to the protocol brokers with each request. The broker would validate the token and its scopes before relaying the request, thus enforcing the principle of least privilege.

  • Integrity and Access Control: To prevent TD tampering, the Config Repository must be a secure service with strict access controls. Furthermore, Thing Descriptions should be digitally signed. When the Core or a servient fetches a TD, it must verify its signature to ensure it has not been altered, thus establishing a chain of trust. For external communication, brokers must enforce strict access control lists (ACLs), for example, by mapping MQTT topics or HTTP endpoints to specific, authorized client IDs or tokens.

While a full implementation of this security model is a subject for future work, this conceptual framework provides a robust foundation for building trust in the WoT-Core architecture.

Reliability and Edge Cases

For CPS, reliability is paramount. The centralized broker model introduces specific reliability challenges:

  • Broker Failure: As a single point of failure, broker downtime must be addressed. Production deployments would require a high-availability broker cluster (e.g., an MQTT cluster with shared state) with automatic failover mechanisms. Servient clients should also be implemented with robust reconnection logic to handle transient broker unavailability.

  • Network Partitions: If a group of servients becomes disconnected from the central brokers but can still communicate with each other, they lose all functionality. To mitigate this, a more resilient topology could be employed. For example, edge deployments could utilize a hierarchical or federated broker model. A local broker at the edge would handle interactions within its local network, allowing local functionality to persist during a partition from the central cloud broker. This local broker would then federate with the central broker to sync state once connectivity is restored. Furthermore, servients could be designed to cache essential TDs to maintain a limited, degraded mode of operation, though this adds state management complexity.

Final Remarks

The proposed lightweight servient architecture presents a clear trade-off: it simplifies individual servient components and verifiably reduces their resource footprint by centralizing communication handling, but at the cost of increased latency and the introduction of brokers as critical infrastructure. Our quantitative, scaling results support this conclusion. This trade-off is likely beneficial in scenarios where:

  • The number of servients/Things is large.

  • Protocol heterogeneity is significant [23].

  • Resource constraints on the nodes running servients are a primary concern, as validated by our measurements, especially in high-density deployments [22].

  • Centralized management and configuration are desirable.

  • Moderate latency increases are acceptable and the application is not time-critical.

Conversely, for systems with few devices, low protocol heterogeneity, or extremely strict low-latency requirements, a more traditional approach with embedded servers or direct peer-to-peer communication might be more suitable.

The use of standard WoT Thing Descriptions [6], augmented with custom link relations (Table 3), provides a good balance between standardization and architecture-specific configuration. The connector mechanism offers a powerful, declarative way to define complex interactions, moving beyond simple device control towards orchestrated CPS behaviors [2].

Furthermore, the versatility of the WoT-Core architecture extends beyond the smart home domain. In Industrial IoT (IIoT), for example, a factory floor may contain thousands of sensors and actuators using diverse legacy and modern protocols (e.g., Modbus, OPC-UA, MQTT). A WoT-Core approach could run lightweight servients on edge gateways, with centralized brokers handling protocol translation and data aggregation, significantly reducing the management overhead and resource load on each gateway. Similarly, in connected healthcare, the architecture can manage a multitude of patient monitoring devices with varying communication standards, ensuring data is routed securely through auditable central brokers. In smart cities, it can orchestrate interactions between disparate systems like traffic control, public lighting, and environmental sensors, where scalability and centralized management are far more critical than microsecond latency.

Conclusions and Future Work

This paper introduced WoT-Core, an architectural solution for implementing lightweight Web of Things servients designed to address complexity and resource consumption in Cyber-Physical Systems. By externalizing server functionalities into intermediary brokers, our architecture redefines servients as pure clients. This approach significantly reduces their individual resource footprint, a claim we have substantiated with a quantitative evaluation showing superior resource scalability compared to a traditional implementation as the number of devices grows.

Our evaluation also confirmed the primary trade-off of this design: the significant gains in resource efficiency and scalability come at the cost of increased, though stable, end-to-end communication latency. This finding clarifies the impact of the architecture and defines its ideal application domains-namely large-scale, heterogeneous, and non-time-critical systems where simplified deployment, maintainability, and resource efficiency on edge nodes are paramount. The declarative ‘connector‘ mechanism further enhances the system by enabling the definition of complex, orchestrated behaviors without embedding interaction logic within the servients themselves. We have shown that this architectural pattern provides a viable, albeit with clear trade-offs, foundation for building scalable and maintainable CPS.

However, the approach also introduces challenges, primarily concerning the reliability, scalability, and potential performance bottlenecks of the centralized brokers, increased end-to-end latency due to the intermediary hops, and the complexity of securing the distributed system components. Future research and development should focus on several key areas:

  • Quantitative Evaluation: Further performance analysis is needed to compare the lightweight architecture with other approaches under diverse loads and network conditions, extending the scaling analysis presented in this paper.

  • Broker Scalability and Reliability: Design and empirically test high-availability and load-balancing strategies for the protocol brokers to mitigate single points of failure. Techniques like broker clustering, replication, and federated architectures should be investigated to ensure robustness and horizontal scalability.

  • Security Enhancements: Develop and integrate a comprehensive, end-to-end security framework based on the detailed model proposed in Section “Security Considerations”, covering robust authentication (mTLS), authorization (token-based), and data integrity (signed TDs). A thorough evaluation of its performance impact is also required.

  • Advanced Connector Features: Explore more sophisticated linking capabilities within the connector, such as conditional logic, data transformation functions, and integration with external rule engines or workflow systems.

  • Tooling and Usability: Develop tools, potentially graphical editors or code generators, to simplify the creation and management of Thing Descriptions, servient configurations, and connector links, lowering the barrier to adoption.

  • Scalability Analysis: Further investigate the scalability limits of the overall architecture, particularly the Core and connector components, as the number of Things and interaction complexity increases. Integration with highly scalable servient implementations like Digital Dice [15] could be explored to handle numerous concurrent requests effectively.

By addressing these areas, the WoT-Core architecture can be evolved into a highly robust and practical solution for the next generation of scalable, maintainable, and efficient Cyber-Physical Systems.