doc generated from pipeline

saref-pipeline.jar

target

ts

documentation/ts_*

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">

<figure>

        <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:"

!!! alert 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.

# Change history

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

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

  <caption>label_unknown</caption>

  <tr>

    <th>Date </th>

An overview of the SAREF4ENER (V1.2.1) ontology is provided in Figure 1. In the image, classes are represented as rectangles. Relationships (object properties) between entities are represented as arrows. Arrows are additionally used to represent some RDF, RDF-S and OWL constructs, more precisely: plain arrows with white triangles represent the rdfs:subClassOf relation between two classes. The origin of the arrow shall be considered as the subclass of the entity at the destination of the arrow. Dashed arrows accompanied by the expression rdf:type are used to indicate that the individual at the origin of the arrow is an instance of the class placed at the end of the arrow. Datatype properties and class restrictions are presented as plain text and positioned within the boxes of the rectangles. The green color is used to distinguish SAREF core entities. The blue color is used for highlighting the classes and properties already existing in the previous version of SAREF4ENER (V1.1.2). The white color is used to denote the classes and properties that have been added in the SAREF4ENER version specified in the present document (V1.2.1). Note that Figure 1 aims at showing a global overview of the main classes of SAREF4ENER and their mutual relations. More details on the different parts of Figure 1 are provided in the other subclauses of clause 4.2.

<figure id="Figure_1">

<figure>

        <img data-docx-width="17.01cm" src="diagrams/Overview.png" alt="SAREF4ENER overview"/>

        <figcaption>Figure 1: SAREF4ENER overview</figcaption>

    </figure>

This extension adds several properties to the existing `saref:Device` which may be used to describe additional device details on top of the properties already defined in SAREF core. 

<table id="Table_2" data-docx-preferred-width="5.98cm 11.06cm">

<table data-docx-preferred-width="5.98cm 11.06cm">

  <caption>Table 2: Properties of a Device</caption>

  <tr>

    <th>Property</th>

The SAREF4ENER extension defines different energy flexibility profiles that can be offered by a `saref:Device`. They are: `s4ener:PowerProfile`, `s4ener:PowerLimitProfile`, `s4ener:DemandDrivenProfile,` `s4ener:OperationModeProfile`, `s4ener:FillRateBasedProfile`, `s4ener:IncentiveBasedProfile,`and `s4ener:PowerEnvelopeProfile`. They are all subclasses of `s4ener:FlexibilityProfile` which is in turn a subclass of `saref:Profile`. 

<figure id="Figure_2">

<figure>

        <img data-docx-width="14.13cm" src="diagrams/FlexibilityProfiles.png" alt="SAREF4ENER Flexibility Profiles"/>

        <figcaption>Figure 2: SAREF4ENER Flexibility Profiles</figcaption>

    </figure>

The profile contains a set of `saref:Actuators` that describe the various ways that the demanded energy can be provided. These actuators may be (part of) the actual `saref:Device` that offers this profile. The forecast of the average demand rate (i.e. the amount of energy, heat, and any other resource that needs to be produced by a device in the near future) can be expressed by defining time series (`s4ener:TimeSeries`). 

<figure id="Figure_3">

<figure>

        <img data-docx-width="10.85cm" src="diagrams/DemandDriven.png" alt="Demand Driven Profile"/>

        <figcaption>Figure 3: Demand Driven Profile</figcaption>

    </figure>

<table id="Table_3" data-docx-preferred-width="5.18cm 11.81cm">

<table data-docx-preferred-width="5.18cm 11.81cm">

  <caption>Table 3: Property of Demand Driven Profile</caption>

  <tr>

    <th>Property</th>

<table id="Table_4" data-docx-preferred-width="5.27cm 11.99cm">

<table data-docx-preferred-width="5.27cm 11.99cm">

  <caption>Table 4: Actuator of a Demand Driven Profile</caption>

  <tr>

    <th>Property</th>

<table id="Table_5" data-docx-preferred-width="4.74cm 12.11cm">

<table data-docx-preferred-width="4.74cm 12.11cm">

  <caption>Table 5: Operation Mode of a Demand Drive Profile</caption>

  <tr>

    <th>Property</th>

The `s4ener:FillRateBasedProfile` can be used for devices that can store energy (`s4ener:Storage`), such as heat pumps with a buffer, EVs, batteries, and even fridges and freezers. The `saref:Actuators` associated with this fill rate based profile can consume energy to fill the buffer. The information regarding the leakage behaviour of the storage and its fill level (i.e. a measure expressing how full the storage is) can respectively be defined through the classes `s4ener:LeakageBehaviour` and `saref:Measurement` via the properties `s4ener:hasLeakageBehaviour` and `s4ener:presentFillLevel`, respectively. The `s4ener:LeakageBehaviour` is always associated with an _element_ detailing the leakage behaviour of the storage (`s4ener:LeakageBehaviourElement`). Ultimately, certain storage devices might have a fill-level target profile (`s4ener:FillLevelTargetProfile`) with its associated `s4ener:FillLevelTargetProfileElement`.  

<figure id="Figure_4">

<figure>

        <img data-docx-width="17.00cm" src="diagrams/FillRate.png" alt="Fill Rate Based Profile"/>

        <figcaption>Figure 4: Fill Rate Based Profile</figcaption>

    </figure>

<table id="Table_6" data-docx-preferred-width="4.42cm 12.32cm">

<table data-docx-preferred-width="4.42cm 12.32cm">

  <caption>Table 6: Properties of Fill Rate Based Profile</caption>

  <tr>

    <th>Property</th>

<table id="Table_7" data-docx-preferred-width="4.99cm 11.75cm">

<table data-docx-preferred-width="4.99cm 11.75cm">

  <caption>Table 7: Properties of Storage</caption>

  <tr>

    <th>Property</th>

<table id="Table_8" data-docx-preferred-width="5.74cm 10.97cm">

<table data-docx-preferred-width="5.74cm 10.97cm">

  <caption>Table 8: Properties of Leakage Behaviour</caption>

  <tr>

    <th>Property</th>

<table id="Table_9" data-docx-preferred-width="4.09cm 12.65cm">

<table data-docx-preferred-width="4.09cm 12.65cm">

  <caption>Table 9: Properties of Leakage Behaviour Element</caption>

  <tr>

    <th>Property</th>

The Actuator of a Fill Rate Based Profile is identical to table 4 (Actuator of a Demand Driven Profile).

<table id="Table_10" data-docx-preferred-width="5.34cm 11.40cm">

<table data-docx-preferred-width="5.34cm 11.40cm">

  <caption>Table 10: Operation Mode of a Fill Rate Based Profile Actuator</caption>

  <tr>

    <th>Property</th>

<table id="Table_11" data-docx-preferred-width="4.09cm 12.65cm">

<table data-docx-preferred-width="4.09cm 12.65cm">

  <caption>Table 11: Operation Mode Element of a Fill Rate Base Profile Operation Mode</caption>

  <tr>

    <th>Property</th>

An incentive table based profile can be used with any type of device. 

<figure id="Figure_5">

<figure>

        <img data-docx-width="17.00cm" src="diagrams/IncentiveTable.png" alt="Incentive Table Based Profile"/>

        <figcaption>Figure 5: Incentive Table Based Profile</figcaption>

    </figure>

<figure id="Figure_6">

<figure>

        <img data-docx-width="17.00cm" src="diagrams/PowerPlan.png" alt="Power Plan associated with an Incentive Table"/>

        <figcaption>Figure 6: Power Plan associated with an Incentive Table</figcaption>

    </figure>

<table id="Table_12" data-docx-preferred-width="3.97cm 12.52cm">

<table data-docx-preferred-width="3.97cm 12.52cm">

  <caption>Table 12: Properties of Incentive Table Based Profile</caption>

  <tr>

    <th>Property</th>

<table id="Table_13" data-docx-preferred-width="4.65cm 11.62cm">

<table data-docx-preferred-width="4.65cm 11.62cm">

  <caption>Table 13: Properties of Incentive Table Slot</caption>

  <tr>

    <th>Property</th>

<table id="Table_14" data-docx-preferred-width="4.21cm 12.28cm">

<table data-docx-preferred-width="4.21cm 12.28cm">

  <caption>Table 14: Properties of Incentive </caption>

  <tr>

    <th>Property</th>

<table id="Table_15" data-docx-preferred-width="3.59cm 12.65cm">

<table data-docx-preferred-width="3.59cm 12.65cm">

  <caption>Table 15: Properties of Power Plan</caption>

  <tr>

    <th>Property</th>

Devices that offer the `s4ener:operationModeProfile` can control the amount of power that they generate and/or consume, such as diesel generators and variable electrical resistors. The states in which devices fall in, such as "running at reduced power" or "running at full power", can be described as operation modes (`s4ener:OperationMode`). These operation modes have therefore been modelled as subclasses of `saref:State`. Transitions between operation modes can be defined as `s4ener:Transition` with associated timers (`s4ener:Timer`) that specify the minimum duration of a particular operation model. 

<figure id="Figure_7">

<figure>

        <img data-docx-width="17.00cm" src="diagrams/OperationMode.png" alt="Operation Mode Profile"/>

        <figcaption>Figure 7: Operation Mode Profile</figcaption>

    </figure>

<table id="Table_16" data-docx-preferred-width="5.41cm 11.08cm">

<table data-docx-preferred-width="5.41cm 11.08cm">

  <caption>Table 16: Property of Operation Mode Profile</caption>

  <tr>

    <th>Property</th>

<table id="Table_17" data-docx-preferred-width="4.79cm 11.69cm">

<table data-docx-preferred-width="4.79cm 11.69cm">

  <caption>Table 17: Properties of Operation Mode</caption>

  <tr>

    <th>Property</th>

<table id="Table_18" data-docx-preferred-width="4.78cm 11.75cm">

<table data-docx-preferred-width="4.78cm 11.75cm">

  <caption>Table 18: Properties of Timer</caption>

  <tr>

    <th>Property</th>

<table id="Table_19" data-docx-preferred-width="4.79cm 12.02cm">

<table data-docx-preferred-width="4.79cm 12.02cm">

  <caption>Table 19: Properties of Transition</caption>

  <tr>

    <th>Property</th>

The minimum and maximum amount of power that can be generated and/or spent by a device in a certain timespan can be set by instantiating the `s4ener:PowerEnvelope` and its corresponding `s4ener:PowerConstraint`. Power constraints are always bound to the allowed power limit ranges of a device (`s4ener:AllowedLimitRange`). The energy level of the `s4ener:PowerEnvelope` can be defined by using `s4ener:TimeSeries`. The type of the _allowed limit ranges_ of a device (i.e. upper limit or lower limit) can be defined through the class `s4ener:PowerEnvelopeLimitType`. Commodity quantities _relating to_ `s4ener:PowerEnvelope` can be described through the class `s4ener:CommodityQuantity`. 

<figure id="Figure_8">

<figure>

        <img data-docx-width="17.00cm" src="diagrams/PowerEnvelope.png" alt="Power Envelope Profile"/>

        <figcaption>Figure 8: Power Envelope Profile</figcaption>

    </figure>

<table id="Table_20" data-docx-preferred-width="4.30cm 12.69cm">

<table data-docx-preferred-width="4.30cm 12.69cm">

  <caption>Table 20: Property of Power Envelope Profile</caption>

  <tr>

    <th>Property</th>

<table id="Table_21" data-docx-preferred-width="4.24cm 12.75cm">

<table data-docx-preferred-width="4.24cm 12.75cm">

  <caption>Table 21: Properties of Power Envelope</caption>

  <tr>

    <th>Property</th>

<table id="Table_22" data-docx-preferred-width="4.65cm 12.33cm">

<table data-docx-preferred-width="4.65cm 12.33cm">

  <caption>Table 22: Properties of Power Constraint</caption>

  <tr>

    <th>Property</th>

<table id="Table_23" data-docx-preferred-width="6.12cm 10.69cm">

<table data-docx-preferred-width="6.12cm 10.69cm">

  <caption>Table 23: Properties of Energy Constraint</caption>

  <tr>

    <th>Property</th>

<table id="Table_24" data-docx-preferred-width="5.59cm 11.40cm">

<table data-docx-preferred-width="5.59cm 11.40cm">

  <caption>Table 24: Property of Allowed Limit Range</caption>

  <tr>

    <th>Property</th>

SAREF4ENER further specifies _allowed limit ranges_ through the classes `s4ener:ContractualPowerLimit`, `s4ener:NominalPowerLimit`, and `s4ener:FailsafePowerLimit`. They are all subclasses of `s4ener:PowerLimit` which is the general upper-class of power limits. Power limits can be toggled active or inactive via the `s4ener:isActive` property. A device has nominal power consumption and/or production values (s4ener:NominalPowerLimit) when the manufacturers define quantifiable and measurable limits that has not to be exceeded. The failsafe values provided by the manufacturers has to be given as instances of `saref:Measurement`_._ In case the communication between a device and the energy manager is interrupted, the device enters a fail-safe state (`s4ener:FailsafeState`). Fail-safe values (`s4ener:FailsafePowerLimit`) apply until the communication is re-established, with an optional minimal duration of the fail-safe state given in the `s4ener:hasFailsafeDuration`. Ultimately, a `saref:Device` is always _bound to_ a `s4ener:ContractualPowerLimit` (which is defined in a specification by the manufacturers) and _limited by_ a `s4ener:FailsafePowerLimit`. 

<figure id="Figure_9">

<figure>

        <img data-docx-width="17.00cm" src="diagrams/PowerLimit.png" alt="Power Limit Profile"/>

        <figcaption>Figure 9: Power Limit Profile</figcaption>

    </figure>

<table id="Table_25" data-docx-preferred-width="4.32cm 12.17cm">

<table data-docx-preferred-width="4.32cm 12.17cm">

  <caption>Table 25: Power Limit Profile</caption>

  <tr>

    <th>Property</th>

<table id="Table_26" data-docx-preferred-width="4.49cm 12.50cm">

<table data-docx-preferred-width="4.49cm 12.50cm">

  <caption>Table 26: Power Limit</caption>

  <tr>

    <th>Property</th>

<table id="Table_27" data-docx-preferred-width="4.49cm 12.50cm">

<table data-docx-preferred-width="4.49cm 12.50cm">

  <caption>Table 27: Failsafe State</caption>

  <tr>

    <th>Property</th>

The `s4ener:AlternativesGroup` consists of one or more power sequences (`s4ener:PowerSequence`) and, inversely, a `s4ener:PowerSequence` belongs to only and exactly one `s4ener:AlternativesGroup`. The `s4ener:PowerSequence` consists of one or more slots (`s4ener:Slot`) and, inversely, a `s4ener:Slot belongs` to only and exactly one `s4ener:PowerSequence`. 

<figure id="Figure_10">

<figure>

        <img data-docx-width="5.33cm" src="diagrams/PowerProfileOverview.png" alt="Power Profile Overview"/>

        <figcaption>Figure 10: Power Profile Overview</figcaption>

    </figure>

<figure id="Figure_11">

<figure>

        <img data-docx-width="17.00cm" src="diagrams/PowerProfileAlternativesGroup.png" alt="Power Profile and Alternatives Group"/>

        <figcaption>Figure 11: Power Profile and Alternatives Group</figcaption>

    </figure>

<table id="Table_28" data-docx-preferred-width="6.17cm 10.68cm">

<table data-docx-preferred-width="6.17cm 10.68cm">

  <caption>Table 28: Properties of a Power Profile and an AlternativesGroup</caption>

  <tr>

    <th>Property</th>

<table id="Table_29" data-docx-preferred-width="6.01cm 10.42cm">

<table data-docx-preferred-width="6.01cm 10.42cm">

  <caption>Table 29: Properties of the PowerSequence </caption>

  <tr>

    <th>Property</th>

<table id="Table_30" data-docx-preferred-width="5.11cm 11.13cm">

<table data-docx-preferred-width="5.11cm 11.13cm">

  <caption>Table 30: Properties of a Slot </caption>

  <tr>

    <th>Property</th>

This clause presents the part of SAREF4ENER that defines how to model events used in, for example, a direct load management or power curtailing scenario (i.e. use case 4). The classes of interest are `s4ener:LoadControlEventData`, `s4ener:LoadControlEventAction`, `s4ener:LoadControlStateData` and `s4ener:LoadControlState`. 

<figure id="Figure_12">

<figure>

        <img data-docx-width="16.97cm" src="diagrams/LoadControl.png" alt="Load Control "/>

        <figcaption>Figure 12: Load Control </figcaption>

    </figure>

This clause presents how flexibility requests can be modelled in SAREF4ENER. This message can be sent by a EMS to a device to inquire for the flexibility it can offer. A flexibility requests can be defined by using the `s4ener:FlexRequest` class. Flexibility requests can _include_ a `s4ener:IncentiveTable`, `s4ener:FlexibilityProfile`, `s4ener:TimeSeries` and `s4ener:Datapoint`. An `s4ener:FlexRequest` can be produced by an agent (`foaf:Agent`) or device (`saref:Device`) and be sent to either an agent or device. An s`4ener:FlexRequest` always has an effective period and a creation time expressed through the Time ontology. 

<figure id="Figure_13">

<figure>

        <img data-docx-width="17.00cm" src="diagrams/FlexibilityRequest.png" alt="Flexibility Request"/>

        <figcaption>Figure 13: Flexibility Request</figcaption>

    </figure>

<table id="Table_31" data-docx-preferred-width="4.24cm 12.75cm">

<table data-docx-preferred-width="4.24cm 12.75cm">

  <caption>Table 31: Flexibility Request</caption>

  <tr>

    <th>Property</th>

This clause presents how flexibility offers can be modelled in SAREF4ENER. This message can be sent by a device to the EMS as a response to a Flexibility Request, indicating the device's flexibility potential. Flexibility offers can be defined by using `s4ener:FlexOffer`. Flexibility offers can _include_ a `s4ener:IncentiveTable`, `s4ener:FlexibilityProfile`, `s4ener:TimeSeries` and `s4ener:Datapoint`. `S4ener:FlexOffer` can be produced by an agent (`foaf:Agent`) or device (`saref:Device`) and be sent to either an agent or device. Flexibility offers relate to flexibility requests (`s4ener:FlexRequest`). A `s4ener:FlexOffer` always has an effective period and a creation time expressed through the Time ontology.

<figure id="Figure_14">

<figure>

        <img data-docx-width="17.00cm" src="diagrams/FlexibilityOffer.png" alt="Flexibility Offer"/>

        <figcaption>Figure 14: Flexibility Offer</figcaption>

    </figure>

<table id="Table_32" data-docx-preferred-width="4.21cm 12.53cm">

<table data-docx-preferred-width="4.21cm 12.53cm">

  <caption>Table 32: Flexibility Offer</caption>

  <tr>

    <th>Property</th>

This clause presents how flexibility instruction can be modelled in SAREF4ENER. This class describes the instruction that an EMS sends to a device about how it should operate according to the EMS optimization plan. Flexibility instruction can be defined by using `s4ener:FlexibilityInstruction`. Flexibility instructions have an activation plan expressed in time-series (`s4ener:TimeSeries`) and a cost defined as a datapoint (`s4ener:DataPoint`). `s4ener:FlexInstruction` can have an execution time, period of validity, instructionID defined as datatype values. The operation mode factor and the presence of abnormal condition can be specified through the datatype properties `s4ener:abnormalConditionOnly` and `s4ener:operationModeFactor`. Flexibility instructions relate to flexibility requests (`s4ener:FlexRequest`). An `s4ener:Flexinstruction` can be produced by an agent (`foaf:Agent`) or device (`saref:Device`) and be sent to either an agent or device. An `s4ener:FlexInstruction` always has an effective period and a creation time expressed through the Time ontology. 

<figure id="Figure_15">

<figure>

        <img data-docx-width="14.76cm" src="diagrams/FlexibilityInstruction.png" alt="Flexibility Instruction"/>

        <figcaption>Figure 15: Flexibility Instruction</figcaption>

    </figure>

<table id="Table_33" data-docx-preferred-width="5.16cm 11.49cm">

<table data-docx-preferred-width="5.16cm 11.49cm">

  <caption>Table 33: Flexibility Instruction</caption>

  <tr>

    <th>Property</th>

The s4ener:DataPoint is defined as a subclass of saref:Measurement and, as such, inherits the saref:hasValue and saref:hasTimestamp properties. Therefore, if the combination of a value and timestamp is sufficient to represent a datapoint, then the SAREF concepts for measurement can be directly reused. However, it can be noticed that often, especially when representing timeseries of datapoints in a forecast, a number of additional properties are needed.

<figure id="Figure_16">

<figure>

        <img data-docx-width="17.00cm" src="diagrams/DataPoint.png" alt="Time Series and Data Point"/>

        <figcaption>Figure 16: Time Series and Data Point</figcaption>

    </figure>

<table id="Table_34" data-docx-preferred-width="4.83cm 11.74cm">

<table data-docx-preferred-width="4.83cm 11.74cm">

  <caption>Table 34: Time Series</caption>

  <tr>

    <th>Property</th>

<table id="Table_35" data-docx-preferred-width="4.56cm 12.17cm">

<table data-docx-preferred-width="4.56cm 12.17cm">

  <caption>Table 35: Data point</caption>

  <tr>

    <th>Property</th>

<table id="Table_36" data-docx-preferred-width="4.60cm 12.14cm">

<table data-docx-preferred-width="4.60cm 12.14cm">

  <caption>Table 36: Gaussian data point</caption>

  <tr>

    <th>Property</th>

### Normative references

# References

## Normative references

* <a id="[0]">[0]</a> [ETSI TS 103 410-1 (V1.2.1)](https://www.etsi.org/deliver/etsi_ts/103400_103499/10341001/01.02.01_60/ts_10341001v010201p.pdf): "SmartM2M;; Extension to SAREF; Part 1: Energy Domain".

* <a id="[1]">[1]</a>	[ETSI TS 103 264 (V3.1.1)](https://www.etsi.org/deliver/etsi_ts/103200_103299/103264/03.01.01_60/ts_103264v030101p.pdf): "SmartM2M; Smart Applications; Reference Ontology and oneM2M Mapping".

* <a id="[3]">[3]</a>	[EN 50491-12-2:2022](https://standards.cencenelec.eu/dyn/www/f?p=CENELEC:110:::::FSP_PROJECT,FSP_ORG_ID:69013,1258281&cs=197399B06850C0E168124734149EE5EB5): "General requirements for Home and Building Electronic Systems (HBES) and Building Automation and Control Systems (BACS) - Part 12-2: Smart grid - Application specification - Interface and framework for customer - Interface between the Home / Building CEM and Resource manager(s) - Data model and messaging" (produced by CENELEC).

### Informative references

## Informative references

* <a id="[i.1]">[i.1]</a>	TNO, EEBus, Energy@Home: "[SAREF4EE : The extension of SAREF for EEBus and Energy@Home](https://w3id.org/saref4ee)".

* <a id="[i.2]">[i.2]</a>	Energy@home: "[Energy@home Data Model](http://www.energy-home.it/Documents/Technical%20Specifications/E@h_data_model_v2.1.pdf)", v2.1, October 2015.