domOS Streamlining the roll-out of smart energy services in buildings

Buildings and smart energy services
Collectively, buildings in the EU are responsible for 40% of the energy consumption and 36% of greenhouse gas emissions1. Therefore, buildings must do their share in the transition to a more sustainable and resilient energy system. Deep renovation is surely the way to go, but better performance can also be achieved in a much shorter time and with less investment with smart energy services.

Smart energy services improve the energy efficiency or the energy flexibility of buildings.

1.  Open-loop services provide building occupants or facility operators with contextual information helping them to adopt more energy-cautious behaviours or supporting them in their decision to invest.
2.  Closed-loop services use control algorithms to improve energy transformation or distribution inside the building.

Energy flexibility services use the intrinsic flexibility of energy processes to increase self-consumption, to avoid congestion on distribution grids, or to perform market operations. Heating, cooling, and EV (Electrical Vehicle) charging are typical flexible processes.

Status of digitalisation and smartness in buildings
Digitalisation is progressing in buildings, like in all other sectors: heat pumps, solar inverters, white appliances, thermostatic valves, blinds, lights, and even coffee machines feature nowadays a communication interface. But digitalisation progresses chaotically: each appliance/device comes with its application, generally made available by the manufacturer. While providing some level of smartness, this situation is not optimal for three reasons:

•  Building occupants or facility operators must deal with multiple applications, each one featuring its user interface and access control scheme.
•  Energy management requires the coordinated orchestration of multiple appliances. A silo approach prevents the implementation of such scenarios.
•  Smart services can't be readily deployed over multiple models of a given appliance type.

Larger buildings – typically those used in the tertiary sector – are equipped with building automation systems orchestrating energy, security, and comfort. Those systems are too expensive for smaller buildings, which accommodate independent energy appliances of different generations. For these buildings, costs must be reduced to boost the roll-out of smart energy services. Low costs can only be achieved if appliances of different types and manufacturers can be integrated in a "plug-and-play" manner.

Decoupling the in-building infrastructure and the smart services
Today, buildings accommodate independent appliances and their apps (Figure 1 (a)). The objective is to decouple the smart services and the in-building infrastructure (Figure 1 (b)).

Several approaches can be considered for integration:

1.  implement the same communication standard in all participating appliances,
2.  develop appliance model-specific drivers in smart services, or
3.  personalise a universal driver with appliance-specific configurations.

Approach 1 requires that manufacturers agree on a common communication scheme. Such an expectation is not realistic, at least in the short/mid-term. Moreover, a new scheme would not be able to integrate the large basis of installed appliances. The Matter>sup>2 specification for smart homes promoted by the big internet players uses this approach, which is in this context reasonable as smart home products are comparably newer and less expensive.

Approach 2. requires the development of new drivers – i.e., new software code – to integrate new appliance models. This is the approach used by today's multiappliance services. The drawback is that the development of drivers requires many resources. Therefore, this approach misses the low-cost objective required for large-scale roll-out.

The advantage of approach 3 is that the integration of an appliance requires only a configuration document whose generation can be assisted. The challenge is the development of a universal parametrizable driver. The domOS approach, which is defined in the so-called domOS ecosystem, belongs to this category.

A glimpse into the domOS ecosystem
The specification enabling the decoupling between in-building infrastructure and smart services is called the "domOS ecosystem". It is made up of two components:

1.  The protocol abstraction component: Energy appliances or devices speak Modbus, M-Bus, HTTP, MQTT and more communication protocols. To expose a uniform model to services, a component (driver) must translate a given protocol into a uniform model. In the domos ecosystem, this issue, which is not specific to the smart building domain, is handled by the World Wide Web Consortium (W3C) in its Web of Things (WoT) architecture. A WoT-compliant library act as “universal driver”. Appliance-specific configuration documents are called Thing Description (TD) in the context of WoT. A TD instructs a WoTcompliant library on how to concretely access the monitoring and control points of an appliance.
2.  The nomenclature component: In itself, protocol abstraction is not sufficient to enable interoperability: the services and the in-building infrastructure must in addition share a vocabulary, with commonly understood definitions. In the domOS ecosystem, each participating building has a digital twin called Building Description (BD). A BD contains metadata associated with references to monitoring and control points in TDs. BDs are machine-readable documents written in a dedicated language (ontology) named domOS Common Ontology (dCO). Metadata are static description data like building location, size and category, constraints on building operation, features of the heat generation and/or distribution... Metadata elements can be linked to monitoring and control points in TDs.

domOS ecosystem-compliant platforms power the five domOS demonstrators. domOS partners in charge of demonstration contribute to the design of the ecosystem and provide feedback on its applicability in concrete use cases.

Demonstrators in Paris (F), Sion (CH), Aalborg (DK), Skive (DK) and Neuchâtel (CH) deal with multiple energy carriers, with multiple services and multiple IoT platforms with centralized (cloud) or decentralized (edge) architectures. This development process helps to define specifications adapted to the concrete situation of buildings in Europe.