documentation generated from TS

For the purposes of the present document, the following abbreviations apply:

* BACS: Building Automation Control Systems

* CEM: Customer Energy Manager

* EMS: Energy Management System

* EV: Electric Vehicle

* HBES: Home and Building Electronic Systems

* IoT: Internet of Things

* OM: Ontology of units of Measure

* OWL: Web Ontology Language

* PV: PhotoVoltaic

* QUDT: Quantities, Units, Dimensions and Types 

* RDF: Resource Description Framework

* RDFS: Resource Description Framework Schema

* RM: Resource Manager 

* SAREF: Smart Applications REFerence ontology

* SPINE: Smart Premises Interoperable Neutral-message Exchange

* SPINE-IoT: Smart Premises Interoperable Neutral-message Exchange for IoT

* TNO: Netherlands Organization for Applied Scientific Research

* TR: Technical Report

* TS: Technical Specification

* UML: Unified Modelling Language

* XML: eXtensible Markup Language

* XSD: W3C<sup>®</sup> XML Schema Definition

 No newline at end of file

The present document is a technical specification of SAREF4ENER, an extension of SAREF [[2]](#[2]) that was created in collaboration with  EEBus ([http://www.eebus.org/en](http://www.eebus.org/en)), the major Germany-based industry association, and the Flexiblepower Alliance Network (FAN, [https://flexible-energy.eu/](https://flexible-energy.eu/)) to enable the interconnection of their (different) data models.

 No newline at end of file

# SAREF4ENER ontology and semantics

## Introduction and overview

The present document is a technical specification of SAREF4ENER, an extension of SAREF [1] for the energy domain. The present document was created based on the CENELEC standards EN 50631:2023, parts 1-4 [2] and EN 50491-12-2 [3], in collaboration with the Horizon 2020 project Interconnect [i.8], and with industry associations such as EEBus ([http://www.eebus.org/en](http://www.eebus.org/en)), Energy@Home ([http://www.energy-home.it](http://www.energy-home.it)), KNX ([https://www.knx.org/](https://www.knx.org/)), and the Flexible power Alliance Network (FAN, [https://flexible-energy.eu/](https://flexible-energy.eu/)). 

The SAREF4ENER extension should be used to annotate (or generate) a neutral (protocol-independent) set of messages to be directly adopted by the various smart appliance manufacturers, or mapped to from their domain specific protocols of choice. These messages can be exchanged by energy smart appliances with an Energy Management System (EMS) to efficiently optimize energy consumption and production within the constraints set by the user. 

Two international domain standards guided the work of developing the SAREF4ENER extension: EN 50631 series [2] with a set of data elements called SPINE and SPINE IoT resources and EN 50491-12-2 [3] with data elements called S2 resources [i.5] and [i.6]. Furthermore, new requirements as well as EN 50631:2023, parts 1-4 [2] and EN 50491-12-2 [3] concepts have been elaborated, implemented, and tested in the European Horizon 2020 project InterConnect within about 15 large scale pilots in 7 countries.

Version 1.1 was primarily based on the power profiles as defined in SPINE. Version 1.2 introduces concepts from S2 as well as adding SPINE/SPINE-IoT concepts not previously covered, with the explicit goal of providing interoperability between the two standards. Power Profiles feature in both standard, so they should be uniformly expressed in SAREF4ENER. The PowerLimits of SPINE relate to the PowerEnvelope in S2, so they should similarly be defined in a common way. The other sections of SPINE/SPINE-IoT and S2 that do not have a corresponding concept, were added to achieve technical interoperability. 

The application of SAREF4ENER focuses on demand response scenarios, in which customers can offer energy flexibility to the Smart Home and Smart Grid. Energy smart devices and energy managers communicate with each other to achieve the best possible result. Energy smart devices can express their demand/production and flexibility, energy managers are responsible to find the most optimal measure between energy consumption and energy production of energy smart devices based on the customer's chosen configuration and the characteristics of the devices. Next to self-consumption optimization, the Smart Grid can influence the quantity or patterns of use of the energy consumed by customers when grid-energy-supply systems are constrained, e.g. during peak hours.

This can be realized by connecting a smart home device with an Energy Management System (EMS) (see EN 50631:2023, parts 1-4 [2]) or by means of a Resource Manager (RM) (see EN 50491-12-2 [3]).These scenarios involve (but are not limited to) the following use cases. The SAREF4ENER parts applicable per use case are primarily decided by the types of devices that are involved:

* **Use case 1:** configuration of devices that want to connect to each other in the home network, for example, to register a new dishwasher to the list of devices managed by the EMS.

* **Use case 2:** flexible start of smart appliances. Smart energy management should be able to (re-)schedule appliances in certain modes and preferred times using power profiles to optimize energy efficiency and accommodate the customer's preferences. The user should be able to decide on a preferred interval within which the energy manager computes the starting time that optimizes the energy usage. Interruption options, such as pausing a task, can further optimize the energy usage. 

* **Use case 3:** monitoring and control of the start, status, and power consumption of the appliances. It is essential for an energy manager to be aware of the power consumption of all devices it optimizes for, including devices that are not smart.

* **Use case 4:** reaction to special requests from the Smart Grid, for example, incentives to consume more or less depending on current energy availability, or emergency situations that require temporary reduction of the power consumption.

* **Use case 5:** limitation of power consumption. This use case covers power limits that are sent by the energy manager, as well as power limits set by the manufacturer in the case of a lost connection (fail-safe limits), as well as contractual and nominal power limits.

* **Use case 6:** incentive table. This use case aims to influence the energy usage via a set of incentives that the energy consumer and energy manager negotiate about.

* **Use case 7:** describing the flexibility capacities of any type of device in a (smart) home.

These use cases are associated with the user stories described in [i.3], which include, among others, the following examples:

* User wants to do basic settings of his/her devices;

* User wants to know when the washing machine has finished working;

* User wants the washing done by 5:00 p.m. with least electrical power costs;

* User likes to limit his/her own energy consumption up to a defined limit;

* User allows the EMS to reduce the energy consumption of his/her freezer in a defined range for a specific time, if the grid recognizes (severe) stability issues;

* Grid related emergency situations (blackout prevention).

The prefixes and namespaces used in SAREF4ENER and in the present document are listed in Table 1.

{{table_1}}

 No newline at end of file

# Approach

The approach that was followed to create SAREF4ENER is a combination of bottom-up and top-down steps, as shown in Figure A.1. The (bottom-up) starting point is given by the two existing data models of E@H (an UML class diagram) [i.2] and EEBus (the XSDs specification). These two data models focus on similar concepts, such as the concept of "power profile", but they use different terminologies. For example, E@H defines "power profiles", "modes" and "phases", while EEBus refers to these concepts as "power sequences", "alternatives" and "slots". In order to converge to a shared terminology, experts of EEBus and E@H preliminarily defined a common specification [i.1] that was subsequently used by TNO as basis for creating SAREF4ENER. 

The preliminary phase was followed by a kick-off workshop in which the experts of EEBus and E@H presented the details of their individual data models, i.e. EEBus (XSDs) and E@H (UML), and also their common data model, the EEBus & E@H (UML+XSDs) model. 

<figure id="Figure_A.1">

        <img data-docx-width="15.52cm" src="diagrams/image18.png" alt="Approach"/>

        <figcaption>Figure A.1: Approach</figcaption>

    </figure>

Since the existing EEBus and E@H data models were expressed in different formats, i.e. XSD and UML, and SAREF4ENER had to be expressed in OWL as an extension of SAREF, these data models were first translated into corresponding OWL versions that could be used as intermediate ontologies towards the creation of SAREF4ENER. The transformations UML  OWL and XSD  OWL were performed manually, but existing tools can be used to automate this step (for example, TopBraid Composer™ Maestro Edition). The outcomes of these transformations were the EEBus (OWL) and E@H (OWL) intermediate ontologies in Figure A.1. The reason to create these two separate intermediate ontologies was practical. The common EEBus & E@H data model is a merged model whose parts could be straightforwardly identified as coming either from the EEBus or the E@H data model. Given that the EEBus and E@H experts were not yet (completely) acquainted with ontologies and OWL, their review process was facilitated by separating the generation of an OWL version in two parts. In this way, these experts could focus on their own part, namely EEBus or E@H, instead of having to deal with a single, large and more complex ontology. Moreover, these intermediate ontologies can be reused individually by the two associations if they decide to make use of an OWL version of their own data model in the future.

!!! alert-info "NOTE:"

    TopBraid Composer Maestro Edition™ is an example of a suitable product available commercially. This information is given for the convenience of users of the present document and does not constitute an endorsement by ETSI of this product.

After receiving and incorporating the feedback from EEBus and E@H experts, the two intermediate ontologies were merged into a first version of SAREF4ENER, as depicted by step 3 in Figure A.1. Since this initial SAREF4ENER version was obtained by making a one-to-one mapping of existing data models that were implementation-driven rather than conceptual specifications, it was necessary to:

1. cleanse unnecessary redundancy, e.g. redundancy of data type properties carrying the same semantics, especially when expressing time-related information and unit of measures; and 

1. create axioms that were absent in the original data models. While doing so, a top-down approach starting from SAREF was taken, as depicted by step 4 in Figure A.1. SAREF contains concepts that are rather high-level and needed further specialization into a finer-grained level of detail to accommodate the specific requirements of the EEBus and E@H use cases. 

Therefore, when creating SAREF4ENER, classes and properties of SAREF were reused and specialized where possible, while SAREF was extended with new classes and properties where it did not suffice for the purpose. 

In particular:

* Only a subset of concepts defined in SAREF was reused, i.e. saref:Device, saref:Profile, saref:State, saref:Energy, saref:Power, saref:UnitOfMeasure and saref:Time. 

* The saref:Device and saref:Profile classes were specialized in the more specific s4ener:Device and s4ener:PowerProfile subclasses, respectively. Devices and power profiles in SAREF4ENER have specific properties for EEbus and E@H that do not apply to all SAREF devices and profiles. 

# Bibliography

* ETSI TS 103 267: "SmartM2M; Smart Applications; Communication Framework".

* ETSI TS 102 689: "Machine-to-Machine communications (M2M); M2M Service Requirements".

* ETSI TS 118 101: "oneM2M; Functional Architecture (oneM2M TS-0001)".

* ETSI TS 118 102: "oneM2M; Requirements (oneM2M TS-0002)".

* ETSI, European Commission and TNO: "[Study on Semantic Assets for Smart Appliances Interoperability](https://sites.google.com/site/smartappliancesproject/deliverables)", final report, April 2015.

* Spatial Data on the Web Interest Group: "[Extensions to the Semantic Sensor Network Ontology](https://www.w3.org/TR/vocab-ssn-ext/)", W3C<sup>®</sup> Working Draft, 16 January 2020.

# Change history

<table id="Table_id_unknown" data-docx-preferred-width="3.49cm 2.25cm 11.24cm">

  <caption>label_unknown</caption>

  <tr>

    <th>Date </th>

    <th>Version </th>

    <th>Information about changes </th>

  </tr>

  <tr>

    <td>May 2023</td>

    <td style="text-align:center">V1.1.3</td>

    <td><ul>

<li data-docx-pstyle="TB1">Added Flexibility Profiles Clause</li>

<li data-docx-pstyle="TB1">Added Flexibility Communication Clause</li>

</ul></td>

  </tr>

  <tr>

    <td>May 2023</td>

    <td style="text-align:center">V1.1.3</td>

    <td>Early draft</td>

  </tr>

  <tr>

    <td>September 2023</td>

    <td style="text-align:center">V1.1.4</td>

    <td>Stable draft</td>

  </tr>

  <tr>

    <td>November 2023</td>

    <td style="text-align:center">V1.1.5</td>

    <td>Final draft</td>

  </tr>

</table>