1 Introdcution

The legal framework for ECs allows citizens to group up and use energy jointly [7, 8]. In other words, the members of an EC are allowed to buy and sell energy inside their community and make up the energy price on their own. However, the concept of ECs was designed as a pure billing construct. In order to profit from this concept, EC members need to know when other members consume and produce electricity to regulate their consumption behavior. Especially the control of flexible loads like EV charging stations or heat pumps could impact the amount of renewable energy consumption and increase self-sufficiency.

One way to monitor and control flexible loads is to connect energy-related devices to a central optimizer system that observes the energy balance and regulates energy consumption. However, the problem with such systems is the integration process of already existing devices and the interoperability to related platforms and services. Fig. 1 visualizes a typical EC scenario with four detached buildings and various energy-related devices that are connected to a central optimizer. The question marks highlight connection points and indicate possible interoperability problems between devices and services. Especially the diverse landscape of incompatible protocols and standards makes it hard to cover a wide range of energy-related devices.

Fig. 1
figure 1

Typical EC scenario

Full size image

Today, a common solution to this problem is developing a new standard or putting extra effort into integration and onboarding processes. However, new standards may not be compatible with existing communication protocols, integration procedures, or onboarding processes. In the worst case, legacy technology is obsolete, and investments into new technology or infrastructure are necessary. This circumstance jeopardizes technology penetration and hinders a fast implementation of modern ECs.

Consequently, the society needs technical solutions that make devices compatible with each other, enable legacy devices to be integrated, are compatible with future interfaces, and lead to open and expandable software architectures. This paper investigates the stated problems and proposes a backward compatible ICT architecture that focuses on the integration and communication of energy-related devices. The related research question was formulated as “What is a suitable system architecture for an energy optimization scenario inside ECs regarding seamless integration of legacy energy-related devices?” and was tackled by applying the Design Science Research Methodology (DSRM) by Peffers et al. [9]. The contribution is a suitable service-oriented architecture design for ECs that improves interoperability by utilizing the WoT standard for device and service descriptions.

2 Related Work

A popular approach to solve compatibility problems in the Internet of Things (IoT) domain is to rely on communication standards such as the Hypertext Transfer Protocol (HTTP) or the Message Queuing Telemetry Transport (MQTT) [1]. Unfortunately, the use of communication standards only solves particular communication problems and, in most cases, does not provide interoperability on a semantic level. Therefore, research came up with the idea to abstract the communication procedures and describe the properties of a device in a common format.

For example, Jara et al. [5] analyzed different communication mechanisms and proposed a possible way to achieve global interoperability. To reach this, the authors assumed that a common device description abstracts the related device properties and additionally provides information about communication interfaces. The authors’ second assumption is that a small number of technologies will dominate the major part of a specific domain. This means if a common device description can be used to model a subset of major technologies, the communication landscape reaches consensus and converges towards this subset of technologies.

The World Wide Web Consortium (W3C) pursues a similar goal with the development of their WoT standard [6]. Even if WoT is yet another standard, it is located on a descriptive level, decoupled from the actual protocol. In other words, it is used to describe communication properties and device affordances in a common format named WoT Thing Description (TD). More precisely, a TD utilizes the JavaScript Object Notation for Linked Data (JSON-LD) format and specifies a common vocabulary of properties that devices typically implement. For example, the WoT vocabulary contains terms for device affordance and classifies them into the three groups properties, actions, and events. Other devices that are able to read and interpret TD understand the vocabulary and know how to interact with corresponding devices. If a device can not natively communicate with another device, it is at least clear why.

Similar concepts are already brought to the Smart Grid (SG) domain. For example, Caballero et al. [2] occupied heterogeneity of communication technologies in SG. To deal with the diverse communication landscape, the authors developed a five-layered architecture that supports integrating various devices into a common Web of Energy (WoE). The key mechanism of the architecture is to abstract physical devices into virtual objects that can be uniformly accessed. For this purpose, the authors assumed smart gateways that are able to transform respective source protocols into target protocols.

Derhamy et al. [3] focused on the protocol transformation process and proposed a service-oriented architecture-based multiprotocol translator with on-demand functionality. The advantage of this approach is that no additional design-time dependencies are necessary, and the translator code can be run in portable environments locally or in the cloud. To make the protocols compatible, the authors propose an intermediary data format to which different device protocols can be mapped. Likewise, the intermediary format can be mapped to specific device protocols as needed. By applying this technique, every protocol only needs two types of translators for transforming data into the intermediary format and back.

The missing part in the transformation process of Derhamy et al. is a flexible way to semantically annotate the data for automatic processing. For this purpose, Desai et al. [4] proposed a Semantic Gateway as a Service solution. The key part of this approach is a multiprotocol proxy that implements various interfaces such as the Constrained Application Protocol (CoAP) or MQTT. Incoming messages to the protocol proxy are semantically annotated and further translated into a JavaScript Object Notation (JSON)-based format. The resulting data can be queried over a Representational State Transfer (REST) interface where data is provided in JSON or the Resource Description Framework (RDF) format.

All the stated solutions show innovative approaches in the energy sector or suggest an improvement in IoT interoperability. However, the authors should have addressed the diverse protocol landscape of energy-related devices and the evolution of the ICT infrastructure in more detail. Therefore the following work shows a modular architecture approach that concentrates on interoperability, extensibility, and integration aspects especially suited for ECs.

3 Proposed solution

In order to investigate the aspect of interoperability, this work refers to a set of non-functional requirements extracted during a requirements engineering process. In detail, the set consists of four non-functional requirements that directly impact the architecture design: confidentiality and access control, extensibility, interoperability, and integration effort. Fig. 2 proposes an architecture design that focuses on these requirements by splitting interoperability concerns into separate services. In detail, the solution consists of the five services Directory Service, Security Service, Network Service, Runtime Service, and Discovery Service. The key element of the architecture is a common understanding of WoT TDs that contains information about the device and especially service affordances. The concrete purpose of a related service is as follows:

  1. 1.

    Directory Service: Provides a directory of available devices and services inside the network. Other participants in the network can query the Directory Service for specific TDs.

  2. 2.

    Discovery Service: Provides various discovery mechanisms to discover new devices and services. If a new device or service is recognized, the Discovery Service generates a TD and registers the document at the Directory Service.

  3. 3.

    Security Service: Provides a central place where access control functionality such as authentication and authorization is managed.

  4. 4.

    Network Service: Provides access from and to different networks and executes the respective firewall rules.

  5. 5.

    Runtime Service: Provides a runtime to execute code. The key task is to create virtualized services and devices that interact with other participants in the network.

Fig. 2
figure 2

Architecture design

Full size image

Every service additionally provides its own TD that Fig. 2 indicates with small sheets beside the respective icon. For example, the Network Service implements an interface to block network requests through an according firewall rule. Therefore, its related TD contains the blockRequest action. Similarly, the Discovery Service provides an interface for starting a discovery process. One associated excerpt from a valid TD is depicted in Listing 3.

Fig. 3
figure 3

Snippet of the Discovery Service’s TD.

Full size image

Other services are able to fetch, read and understand these actions and adjust their interactions accordingly. If a device or service in the network is not interoperable upfront, the minimum requirement is an understandable TD that can be registered in the Directory Service. If the Discovery Service is unable to recognize a device, the fallback solution is that another participant, such as a human or an engineering tool, registers the TD manually. Afterward, other participants know about the device and can initiate interactions. However, if the communication technologies are incompatible, the Runtime Service can be used to instantiate a gateway application that encapsulates the original interfaces and creates a virtualized interoperable device. The virtual device provides its own TD and translates requests from and to the actual device.

Fig. 4 indicates how the modular services can be deployed in a diverse EC setup with four different levels of interoperability (1)–(4). The example assumes that every EC member owns an Internet router that is capable of running the required services. The deployment structure of the necessary services is represented by small icons in each house:

  1. 1.

    The EC member provides a fixed setup with a legacy inverter and a modern EV charging station. In this case, the Runtime Service instantiates a gateway app to transform the inverter’s messages into an understandable format. The Network Service bridges the connection to the optimizer while the Security Service manages access to the devices. Further, all devices are registered in the Directory Service to enable convenient device lookups. New devices are registered manually by the EC member.

  2. 2.

    Similarily to (1), the Network Service and the Security Service care for establishing a connection to the optimizer. However, the inverter is assumed to communicate with the optimizer without protocol translation, so no Runtime Service is needed. Instead, the EC member prefers low effort in onboarding procedures and hence uses the Discovery Service to identify new devices.

  3. 3.

    This setup indicates a basic setup with a modern inverter only. The inverter can communicate using the optimizer’s protocols but needs the Network Service to establish a connection and the Security Service to manage access.

  4. 4.

    The devices implement technology that is fully interoperable with the optimizer’s interfaces. No additional services are needed in this case.

Fig. 4
figure 4

Service deployment example

Full size image

4 Implementation

A Docker-based environment acted as a testbed to implement the proposed architecture and perform exemplary scenarios. Fig. 5 shows the concrete setup. In general, the testbed was used to deploy the services from Fig. 2 in a local network and divide it from the energy optimizer in the cloud. To connect the devices throughout the different networks, the Network Service implemented a private WireGuard® network that proxied requests with an extensible firewall-like concept.

Fig. 5
figure 5

Docker-based testbed environment

Full size image

Besides the service implementation, the technology analysis was performed in an exemplary manner. As a result, the process selected HTTP for communication, Multicast DNS (mDNS) with Domain Name System Service Discovery (DNS-SD) and well-known Uniform Resource Identifier (URI) for discovery, W3C’s WoT for describing device affordances, JSON Web Tokens (JWT) for authorization, NodeJS for the runtime environment and an individual vocabulary with terms from the SunSpec specification for semantic description. These technologies were further selected to support the integration process of legacy devices. After implementing the testbed with the selected technologies, two simulated scenarios were demonstrated.

In the first scenario, it was shown how an interoperable EV charging station with an understandable TD can communicate via HTTP with the optimizer system in the cloud. In this case, no interaction of external parties was required, and communication could be established automatically.

In the second case, a legacy device in the form of an inverter was integrated. The inverter device was simulated by a NodeJS application that provided a Modbus Transmission Control Protocol (TCP) interface where SunSpec data was available. In this case, the Discovery Service found the SunSpec device by utilizing a port scan and registered the related TD at the Directory Service. An app on the user’s smartphone recognized the new device but needed the data in proper JSON format over HTTP. Consequently, a script was deployed to encapsulate the inverter’s interface and create a virtual device that the smartphone can interpret.

An excerpt of the respective gateway instantiation process is visualized in Fig. 6. For the sake of simplicity and space, the diagram focus on one sequence with the most important parts. The process starts by deploying a suitable app to the Runtime Service where a gateway is instantiated. Next, the gateway generates a suitable TD and sends it to the Directory Service. After instantiation, every request to the virtual device is translated inside the Runtime Service and forwarded to the legacy inverter.

Fig. 6
figure 6

Gateway instantiation process

Full size image

5 Conclusion

In short, the proposed service-oriented architecture is able to separate concerns of a monolithic ICT infrastructure in ECs. Even if the implementation overhead upfront might be higher, the dependency on specific systems is reduced, and vendor lock-ins are mitigated. WoT connects the separated services and devices and provides a flexible foundation for related interfaces and protocols.

Further work will include a detailed design of the Runtime Service and the related interfaces. Additionally, it is interesting how novel technologies such as WebAssembly could replace the script functionality with a performant and interoperable executable format.