### General Overview

This documentation 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), Energy@Home (http://www.energy-home.it), KNX (https://www.knx.org/), and the Flexible power Alliance Network (FAN, 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.

The main addition that SAREF4ENER provides on top of SAREF Core is a set of saref:Profiles that describe the energy flexibility capabilities of a device (see clause 4.2.3). These profiles are drawn from the SPINE/SPINE IoT [2] and the S2 data model [3], with some occurring in both and some in either. For example, the Power Profile flexibility type is described in both S2 and SPINE/IoT, so is merged into a single SAREF representation (see clause 4.2.3.6). The S2 Power Envelope and SPINE Power Limits also show enough similarities for an implementation with several shared concepts (see clause 4.2.3.5). The remaining types of flexibility are unique to either S2 or SPINE: Incentive Tables are defined in SPINE, whereas Operation Mode, Fill Rate Based, and Demand Driven energy flexibility are control types defined in S2 [i.5].

The SAREF4ENER extension additionally describes flexibility instructions (see clause 4.2.5) separately from the flexibility profiles. These instructions describe the communication taking place between a device and the EMS to decide on the energy flexibility plan, such as offers from the device and requests from a EMS. A real-time check on the monitoring of power consumption is facilitated via the reuse of the main SAREF module and the load control use case (see clause 4.2.4). Finally, the SAREF4ENER extension provides a modelling approach for data points and time series (see clause 4.2.6), which is necessary for modelling the various forecasts and data elements involved.

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 1: SAREF4ENER overview

### Device

A s4ener:Device is a subclass of a saref:Device, i.e. it inherits the properties of the more general saref:Device and extends it with additional properties that are specific for SAREF4ENER. The s4ener:Device class is shown in Figure 3.

### Demand Driven Profile

The s4ener:DemandDrivenProfile can be used for devices that can consume different types of energy resources such as electricity or natural gas, but that lack a way of buffering that energy. This may for example be a hybrid heat pump that is powered using either electricity of gas. The power demand is determined by the device, but the customer energy manager can choose how to generate that power.

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 2: Demand Driven Profile overview

### Fill Rate Based Profile

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 2: Fill Rate Profile overview

### Operation Mode Based Profile

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 2: Operation Mode Based Profile overview

### Incentive Table Based Profile

The s4ener:IncentiveTableBasedProfile can be used to describe an incentive table, compiled of incentive table slots (s4ener:IncentiveTableSlot) as well as a power plan (s4ener:PowerPlan). Both are used to negotiate the allocation of upcoming energy usage of a device between the energy manager and the device. The incentive table is used by the energy manager to express the availability of energy via real and/or artificial incentives or costs over time. The device itself uses the table to negotiate the own demand and request the allocation by sending the resulting power plan to the energy manager.

Incentive types can be expressed in the form of relative costs (s4ener:RelativeCost), absolute costs (s4ener:AbsoluteCost), CO2 emissions (s4ener:CO2Emission), and renewable energy percentage (s4ener:RenewableEnergyPercentage). An incentive table also defines a scope type (s4ener:ScopeType) to indicate whether it is a preliminary (s4ener:Preliminary) or committed version (s4ener:Committed).

An incentive table consists of a number of slots (s4ener:IncentiveTableSlot) where each slot may contain a series of incentives (s4ener:Incentive) representing various tiers (s4ener:Tier). Each tier may be linked to a particular energy source, such as the grid, solar panels, or surplus power. Each incentive describes the cost, expressed as a unit applicable to the s4ener:IncentiveType, for that power source in the particular (time) slot. The lower and optional upper boundary (s4ener:DataPoint) describe for each incentive at which level of power consumption it becomes applicable.

The power plan of a device is defined by a series of sets of data points (s4ener:TimeSeries). Each set of data points contains a time interval (time:Interval), a relation to a property (s4ener:Power), a binding to a minimum (s4ener:Minimum), average (s4ener:Average) or maximum (s4ener:Maximum) value and the value itself (saref:Measurement). Finally, it also contains a scope type (s4ener:ScopeType) to indicate whether it is a preliminary (s4ener:Preliminary) or committed value (s4ener:Committed).

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

Figure 2: Incentive Table Based Profile overview

### Power Limitation Based Profile

#### Power Envelope Based Profile

A saref:Device offers a s4ener:PowerEnvelopeBasedProfile when the device is operating within a minimum and maximum amount of power for energy production and/or consumption per time block, but the production or consumption cannot be directly regulated by the energy manager. A PV panels inverter is a typical example, because the energy produced is dependent on the amount of sunshine. The EMS may constrain the power production of the PV panels below its potential to lower a peak.

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 2: Power Envelope Based Profile overview

#### Power Limit Profile

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 2: Power Limit Based Profile overview

### Power Profile

This clause presents the classes of interest for smart energy management. These classes are used to schedule devices in certain modes and preferred times using power profiles to optimize energy efficiency and accommodate the customer's preferences (i.e. use case 2). These classes are s4ener:PowerProfile, s4ener:Alternative, s4ener:PowerSequence and s4ener:Slot, which are shown in Figure 4.

A s4ener:PowerProfile is a subclass of a saref:Profile, i.e. it inherits the properties of the more general saref:Profile extending it with additional properties that are specific for SAREF4ENER. The s4ener:PowerProfile is used by a s4ener:Device to expose the power sequences that are potentially relevant for the CEM. A s4ener:Device can expose a s4ener:PowerProfile, which consists of one or more alternative plans (s4ener:AlternativesGroup class). A s4ener:AlternativesGroup consists of one or more power sequences (s4ener:PowerSequence class), and a s4ener:PowerSequence consists of one or more slots (s4ener:Slot class). Inversely, a s4ener:Slot belongs to only and exactly one s4ener:PowerSequence, which, in turn, belongs to only and exactly one s4ener:AlternativesGroup, which, in turn, belongs to only and exactly one s4ener:PowerProfile. A s4ener:PowerProfile belongs to only and exactly one s4ener:Device.

Figure 4: Power Profile and Alternatives Group Overview

#### Power Sequence

The s4ener:AlternativesGroup consists of one or more power sequences (s4ener:PowerSequence class) and, inversely, a s4ener:PowerSequence belongs to only and exactly one s4ener:AlternativesGroup. Figure 5 shows the details of the s4ener:PowerSequence class.

Figure 5: Power Profile Alternatives Group

#### Slot

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

#### Load control

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

The s4ener: LoadControlEventData class is used to represent overload warning severity level and related load control commands to a device. It is characterized by an event ID and a timestamp that represents the time the event information instance was created or received, and the time period that denotes the period of validity of the event. For example, 5 minutes ago an event was received which says that it shall take effect tomorrow from 14:00 to 15:30. In this event the timestamp is "5 minutes ago" and time period is "tomorrow from 14:00 to 15:30".

The s4ener:LoadControlEventAction class expresses the type of actions to be performed as a consequence of a load control event. A s4ener:LoadControlEventAction can be of type "consume" or "produce" to denote consumption or production of energy or power. Values for both consume and produce actions can be s4ener:emergency, s4ener:increase, s4ener:normal, s4ener:pause, s4ener:reduce, s4ener:resume.

The s4ener: LoadControlStateData class expresses the data about the state of an event and is characterized by the same event ID used in the s4ener:LoadControlEventData class, as well as a timestamp, and it is associated to the class s4ener:LoadControlState, which can be of type "consume" or "produce" - analogously to a load control event action – and expresses the possible states of a load control event. Values for both consume and produce load control states can be s4ener:eventAccepted, s4ener:eventStarted, s4ener:eventStopped, s4ener:eventRejected, s4ener:eventCancelled, or s4ener:eventError.

Figure 7: Load control