documentation generated from TS

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

* CEM : Customer Energy Manager

* E@H : Energy@Home association

* EEBus : EEBus initiative

* OM: Ontology of units of Measure

* OWL: Web Ontology Language

* SAREF: Smart Applications REFerence ontology

* TNO: Netherlands Organization for Applied Scientific Research

* TR: Technical Report

* TS: Technical Specification

* UML: Unified Modeling Language

* XSD:	W3C 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 Energy@Home ([http://www.energy-home.it](http://www.energy-home.it)) and EEBus ([http://www.eebus.org/en](http://www.eebus.org/en)), the major Italy- and Germany-based industry associations, 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 [2] that was created in collaboration with Energy@Home ([http://www.energy-home.it](http://www.energy-home.it)) and EEBus ([http://www.eebus.org/en](http://www.eebus.org/en)), the major Italy- and Germany-based industry associations, to enable the interconnection of their (different) data models. The Energy@Home association, abbreviated in the rest of the document as E@H. E@H aims at developing and promoting technologies and services for energy efficiency in smart homes, based upon the interaction between user devices and the energy infrastructure. The E@H data model is described in [i.2]. EEBus is an important initiative in the area of the Internet of Things, which has its roots in the sector of smart and renewable energy. EEBus developed a standardized and consensus-oriented smart grid and smart home networking concept. The EEBus data model is described in [1]. SAREF4ENER is meant to enable the (currently missing) interoperability among various proprietary solutions developed by different consortia in the smart home domain. By using SAREF4ENER, smart appliances from manufacturers that support the EEBus or E@H data models will easily communicate with each other using any energy management system at home or in the cloud. 

Towards this aim, SAREF4ENER should be used to annotate (or generate) a neutral (protocol-independent) set of messages to be directly adopted by the various manufacturers, or mapped to their domain specific protocols of choice.

SAREF4ENER is an OWL-DL ontology that extends SAREF with 63 classes, 17 object properties and 40 data type properties. SAREF4ENER focuses on demand response scenarios, in which customers can offer flexibility to the Smart Grid to manage their smart home devices by means of a Customer Energy Manager (CEM). The CEM is a logical function for optimizing energy consumption and/or production that can reside either in the home gateway or in the cloud. Moreover, the Smart Grid can influence the quantity or patterns of use of the energy consumed by customers when energy-supply systems are constrained, e.g. during peak hours. These scenarios involve the following use cases:

* **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 CEM;

* **Use case 2:** smart energy management/ (re-)scheduling appliances in certain modes and preferred times using power profiles to optimize energy efficiency and accommodate the customer's preferences;

* **Use case 3:** monitoring and control of the start and status of the appliances; 

* **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.

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 CEM 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) 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 [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/image9.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. 

# Additional concepts

This annex presents some additional concepts concerning how devices can exchange configuration information on their mutual functionality in order to connect to each other (i.e. use case 1), and how the start and status of the appliances can be monitored and controlled (i.e. use case 3). These use cases are elaborated in clause 5.1.1 in ETSI TR 103 411 [i.4]. Note that the concepts described in the present annex are NOT part of the current release of SAREF4ENER, since at the time of publication of the present document they are under discussion between the Energy@Home and EEBus associations, and NOT yet included in their common specification in [1]. Note also that the concepts shown in this annex still use the prefix `s4ee:` because they are part of the first extension created for the Energy@Home and EEBus associations that was called SAREF4EE. These SAREF4EE concepts are not part yet of the extension that is now called SAREF4ENER, therefore they keep the `s4ee:`prefix. 

The classes of interest for the use case 1 are `s4ee:Device`, `s4ee:Address`, `s4eeDeviceConnection`, `s4eeDeviceConnectionSetup`, `s4eeNativeSetup`, `s4eeCandidateSetup`, `s4eeScanSetup` and `s4eeJoinModeConfiguration`, as shown in Figure B.1.

<figure id="Figure_B.1">

        <img data-docx-width="13.51cm" src="diagrams/image10.png" alt="Configuration "/>

        <figcaption>Figure B.1: Configuration </figcaption>

    </figure>

The classes of interest for the use case 2 are `s4eeAppliance`, `s4eeApplianceParameter`, `s4eeApplianceParameterTable`, `s4eeParameterTablePoint`, `s4eeValue`, `s4eeApplianceParameterState`, `s4eeApplianceWorkingMode`, `s4eeApplianceParameterSet`, `s4eeApplianceParameterSettings`, `s4eeExpression`, `s4ee`ApplianceParameterCompatibilityAction, `s4ee`ApplianceControl and `s4eeApplianceMonitor`.

A `s4eeAppliance` is as a specialization of a `s4eeDevice`and therefore also a specialization of a `saref:Device`, as shown in Figure B.2.

<figure id="Figure_B.2">

        <img data-docx-width="13.44cm" src="diagrams/image11.png" alt="Appliance "/>

        <figcaption>Figure B.2: Appliance </figcaption>

    </figure>

A `s4eeAppliance` is linked to parameters , available working modes, controls and measurements, as follows:

* It has a list of zero or more parameters (`s4eeApplianceParameter` class in Figure B.3), each representing a particular function mode such as "Temperature", "Spin", "Prewash" or "Iron Min":

    * Each s4eeApplianceParameter is described by s4eeParameterTable, which can be of type s4eeStepParameterTable, s4eePointwiseParameterTable, s4eeBooleanParameterTable or s4eeDateParameterTable. All these tables define the type of permission for a certain parameter (i.e. "read only", "write only" or "read and write") and its unit of measure (saref:isMeasuredIn property). The s4eeStepParameterTable is additionally characterized by at least one minimum value, number of set points and steps. The s4eePointwiseParameterTable is characterized by a point with one or more values (s4eehasPoint min 1 property) described by the s4eeParameterTablePoint class. 

    * Each s4eeApplianceParameter is associated to a state (saref:hasState exactly 1 s4eeApplianceParameterState) which can be used to represent the actual parameter values by means of the s4eeApplianceMonitor class, and to set new values by means of the s4eeApplianceControl class.

<figure id="Figure_B.3">

        <img data-docx-width="15.06cm" src="diagrams/image12.png" alt="ApplianceParameter "/>

        <figcaption>Figure B.3: ApplianceParameter </figcaption>

    </figure>

* It has a list of zero or more working modes (`s4eeApplianceWorkingMode` class in Figure B.4) each representing a particular working mode such as "Synthetics", "Mix 30" or "Super Cool":

    * A working mode has an ID (`s4eeworkingModeId exactly 1` property), a name (`saref:hasName exactly 1` property) and a list of zero or more sets (`s4eeApplianceParameterSet` class) representing the sets of enabled parameters for that working mode. A `s4ee:ApplianceParameterSet` can have zero or more settings (`s4eeApplianceParameterSettings` class)and is selected according to certain conditions defined in the `s4eeExpression` class. The set "0" is the default set and is selected when no condition is true:

        * The `s4ee:ApplianceParameterSettings` class is characterized by the parameter ID (`s4eeparameterId exactly 1` property) and a number of values for that parameter that are subclass of the `s4eeValue` class, i.e. `s4eeAvoidedValue` (list of not admitted values), `s4ee:DefaultValue` (default value of the parameter), `s4eeMaxValue` (maximum value that the parameter could be set) and `s4eeMinValue` classes (minimum value that the parameter could be set). The `s4eeApplianceParameterSettings` class also has a boolean property to specify whether the settings under consideration are active or not (`s4eeisActive` property).

        * The s4ee`:Expression` class is characterized by a value (`s4eehasValueType exactly 1` property), the parameter ID (`s4ee`parameterId exactly 1 property) that identifies the parameter whose current set point has to be compared, a math operator `s4eemathOperator exactly 1` property) such as "==" , "!=" , ">" , "<" to define set points equal, different, above or below the expression value, and logical connectives (`s4eelogicalConnective min 0` property) such as "AND" and "OR" that could be used to connect different expressions.

<figure id="Figure_B.4">

        <img data-docx-width="15.91cm" src="diagrams/image13.png" alt="ApplianceWorkingMode "/>

        <figcaption>Figure B.4: ApplianceWorkingMode </figcaption>

    </figure>

* It has a list of zero or more actions to be executed in case of incompatibility with other parameters (`s4ee:ApplianceParameterCompatibilityAction` class in Figure B.5):

    * The `s4eeApplianceParameterCompatibilityAction` class specifies incompatible parameters (`s4eehasAffectedParameter min 1` property), and has at least one expression (`s4eehasExpression min 1` property). If this expression turns TRUE, then one of the following types of actions will be executed:

        * s4eeaction_1_reset_to_OFF_value (reset).

        * s4eeaction_2_disabled (disabled).

        * s4eeaction_3_set_to_MaxValue (set to maximum value).

        * s4eeaction_4_set_to_default_value (set to default value). 

The property `s4eehasValue min 0` `s4eeMaxValue` expresses the maximum value to be used in case of `s4eeaction_3_set_to_MaxValue`.

<figure id="Figure_B.5">

        <img data-docx-width="15.91cm" src="diagrams/image14.png" alt="ApplianceCompatibilityAction "/>

        <figcaption>Figure B.5: ApplianceCompatibilityAction </figcaption>

    </figure>

* It has a list of zero or more measurements that represent the actual parameter values for the appliance (`s4eeApplianceMonitor` class in Figure B.6). These measurements can be sent by the appliance automatically as a status notification, or after a specific request from the CEM. The notification contains the information related to the current state of the appliance, i.e. parameter ID, its current value and, optionally, the maximum and minimum values that the parameter can assume.

* It has a list of zero or more control actions (`s4eeApplianceControl` class in Figure B.6), such as command actuation or the setting of working modes and parameters, to control zero or more states of the appliance (`s4eeApplianceParameterState` class). The `s4eeApplianceControl` class also has a boolean property to specify whether the controls under consideration are active or not (`s4eeisActiveyioy` property). 

<figure id="Figure_B.6">

        <img data-docx-width="15.91cm" src="diagrams/image15.png" alt="ApplianceMonitor and ApplianceControl "/>

        <figcaption>Figure B.6: ApplianceMonitor and ApplianceControl </figcaption>

    </figure>

# 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", final report, April 2015.

!!! alert-info "NOTE:"

    Available at [https://sites.google.com/site/smartappliancesproject/deliverables](https://sites.google.com/site/smartappliancesproject/deliverables).