This document presents the implementation of the SAREF extension for the electric grid domain (SAREF4GRID).
Figure 1, Figure 2, Figure 3 and Figure 4 present an overview of the classes and the properties included in the SAREF4GRID extension.
Figure 5 provides an overview of how to represent an electric grid meter using the s4grid:Meter class. The representation of electric grid meters and their properties has been extracted from the DLMS/COSEM standard (IEC 62056)
Unlike in other SAREF extensions, meter-specific information is not defined using properties from SAREF. This is because the DLMS/COSEM standard defines the data structures to model meters from simple up to very complex functionality (IEC 62056-6-2:2017). Moreover, each piece of information within the metering equipment has a unique identifier called OBIS (OBject Identification System) which identifies the instance of a COSEM object (IEC 62056-6-1:2017). This data includes not only measurement values, but also abstract values used for configuration or for obtaining information about the behaviour of the metering equipment.
For this reason, the characteristics of the meter are represented as properties that are not observable by the meter (s4grid:MeterProperty, fully represented in Figure 6), i.e., they are not measurements (saref:Measurement). The properties of a meter are defined by a value (s4grid:PropertyValue) and some are complemented with a unit of measurement (saref:UnitOfMeasure).
Meters store internal configuration parameters. The DLMS/COSEM standard (IEC 62056) defines properties related to the configuration of a meter that are necessary to ensure its correct operation. SAREF4GRID categorises the main properties related to the configuration of a meter (s4grid:MeterProperty): screen display configuration (s4grid:ScreenDisplay), electric threshold values (s4grid:Threshold), time from which a measure has to be outside the threshold before to be considered a quality issue (s4grid:TimeThreshold), number of voltage sags (s4grid:VoltageSagNumber), number of voltage swells (s4grid:VoltageSwellNumber), number of long power failures (s4grid:LongPowerFailuresNumber), information provided by the manufacturer (s4grid:Manufacturer), turn ratio of the transformer (s4grid:TransformerRatio), communication configuration (s4grid:Network), status of meter profiles (s4grid:ProfileStatus), client power limits (s4grid:PowerLimit), references values for power quality (s4grid:PowerQuality), client billing periods (s4grid:BillingPeriod), information about the electric grid phase (s4grid:Phase), information about the electric grid phase angle (s4grid:PhaseAngle) and electric quadrant (s4grid:Quadrant). It should be noted that in SAREF4GRID only the general properties are being defined. In order to use a more specific property it is advisable to indicate the general property it comes from (if it exists). These properties are depicted in Figure 6.
SAREF4GRID allows describing the identification information related to administration and maintenance of meters by means of the s4grid:Firmware class, as presented in Figure 7. They are not communication parameters but support device management. The representation of the firmware of a meter has been extracted from the IEC 62056-6-2:2017.
A meter firmware may be described by its: version (s4grid:hasFirmwareVersion), unique vendor identifier (s4grid:hasVendorId) and unique product identifier assigned by the vendor (s4grid:hasProductId). Besides, a firmware can be related to an electric grid meter by means of the s4grid:hasFirmware property.
SAREF4GRID allows describing the MAC address of the physical device (or, more generally, of a device or software) by means of the s4grid:NetworkInterface class, as presented in Figure 8. There shall be an instance of this class for each network interface of a meter. The representation of the network interface of a meter has been extracted from the IEC 62056-6-2:2017.
SAREF4GRID allows describing the clock of a meter by means of the s4grid:Clock class, as presented in Figure 9. This clock manages all information related to date and time including deviations of the local time to a generalized time reference (UTC) due to time zones and daylight-saving time schemes. The representation of the meter clock has been extracted from the IEC 62056-6-2:2017.
A meter clock may be described by its: time (s4grid:hasTime), time zone where the meter is located (s4grid:hasTimeZone), clock status maintained by the meter (s4grid:hasStatus), date at which the local time starts to deviate from the normal time (s4grid:hasDaylighhtSavingsBegin), date at which the local time ends to deviate from the normal time (s4grid:hasDaylighhtSavingsEnd), deviation in generalized time (s4grid:hasDaylightSavingsDeviation), if the daylight savings time feature is enabled (s4grid:hasDaylightSavingsEnabled) and where the basic timing information comes from (s4grid:hasClockBase). Besides, a clock can be related to an electric grid meter by means of the s4grid:hasClock property.
As it can be observed in Figure 10, the modelling of states in the SAREF4GRID ontology mostly relies on the state model proposed in SAREF.
SAREF allows to define the state in which a device can be found. However, the SAREF4GRID extension also requires to be able to define the possible transitions between states and complex states. Therefore, the s4grid:BreakerState class has been defined according to the IEC 62056-6-2:2017.
A meter breaker state represents the internal or external disconnect unit of the meter (e.g., electricity breaker, gas valve) in order to connect or disconnect the premises of the consumer to/from the supply. A meter breaker state may be described by its: physical state (s4grid:hasOutputState), internal state (s4grid:hasControlState) and the possible transitions between states (s4grid:hasControlMode).
As it can be observed in Figure 11, the modelling of scripts in the SAREF4GRID ontology mostly relies on the service model proposed in SAREF. In order to reduce duplication with SAREF documentation, the reader is referred to the SAREF specification for details about service modelling including here details only for the new concepts.
SAREF allows to define the functions which accomplish the task for which a device is designed. However, the SAREF4GRID extension also requires to be able to define the triggering of a series of actions by executing scripts, and where those scripts are stored. Therefore, the s4grid:ScriptTable class has been defined according to the IEC 62056-6-2:2017.
A script table represents a table of script entries. Moreover, the s4grid:Script class defines a series of action specifications. An action specification activates a method or modifies an attribute of a COSEM object within the logical device. Besides, a script table can be related to an electric grid meter by means of the s4grid:hasScriptTable property.
SAREF4GRID allows the execution of periodic actions within a meter by means of the s4grid:SingleScheduledAction class, as presented in Figure 12 ; such actions are not necessarily linked to tariffication. A scheduled action describes the script, which is stored in a script table, that is going to be executed at a determined date. The representation of the meter scheduled action has been extracted from the IEC 62056-6-2:2017.
A meter single scheduled action may be described by its: execution time (s4grid:hasExecutionTime) and what script is going to be executed (s4grid:executesScript). Besides, a single schedule action can be related to an electric grid meter by means of the s4grid:hasSingleScheduledAction property.
SAREF4GRID allows modelling the handling of various tariff structures in the meter by means of the s4grid:ActivityCalendar class, as presented in Figure 13. An activity calendar provides a list of scheduled actions, following the classical way of calendar-based schedules by defining seasons, weeks, etc. The representation of the meter activity calendar has been extracted from the IEC 62056-6-2:2017.
An activity calendar is active (s4grid:hasCalendarNameActive) if it is currently used for billing. Each active calendar has an associated passive calendar (s4grid:hasCalendarNamePassive) and its function is to allow to modify the parameters of the active calendar on a date prior to its activation date (s4grid:hasActivatePassiveCalendarTime). Activation date is the date from which the meter will use the passive calendar parameters and, therefore, they become active calendar parameters. An active calendar is compound by active seasons (s4grid:hasActiveSeasonProfile) and a passive calendar is compound by passive seasons (s4grid:hasPassiveSeasonProfile). Notice that there is no distinction between an active calendar and a passive calendar because together they represent an activity calendar and they share the same OBIS code.
A season profile (s4grid:SeasonProfile) represents periods of time during the year when billing conditions are always the same. A season is characterized by a start date (s4grid:hasSeasonStart) and seven day profiles (s4grid:hasDayProfile) to apply, which together represents a week (there is one day profile for each day of the week). A season finishes when the next season begins.
A day profile (s4grid:DayProfile) represents the discrimination of time along the day. Moreover, the seven day profiles together represents a period during the week when billing conditions are always the same. There are two day profiles: regular days (s4grid:RegularDayProfile) which represents not festive days, and special days (s4grid:SpecialDayProfile) which represents at which date there is a festivity, i.e. normal day behaves as a special day (s4grid:hasScpecialDayDate). A day profile is characterized by a day schedule (s4grid:hasDaySchedule).
A day schedule (s4grid:DaySchedule) defines the activation of certain scripts during the day, which can perform different activities inside the meter. For each day schedule, a list of scheduled actions is defined by a script to be executed (s4grid:executesScript) with the corresponding activation time (s4grid:hasStartTime).
As it can be observed in Figure 14 and Figure 15, the modelling of measurements in the SAREF4GRID ontology mostly relies on the measurement model proposed in SAREF. In order to reduce duplication with SAREF documentation, the reader is referred to the SAREF specification for details about measurement modelling including here details only for the new concepts.
The DLMS/COSEM standard (IEC 62056) defines the measurements that a meter must take from a power line. It should be noted that in SAREF4GRID only the general properties are being defined. In order to use a more specific property it is neccesary to indicate the general property from which it comes from. The properties that are defined in SAREF4GRID, which are measured from a power line (s4grid:PowerLine), are depicted in Figure 14 and Figure 15.
SAREF4GRID categorises the main properties related to the enregy an power measurements of a power line (s4grid:EnergyPowerProperty): active energy measurements (s4grid:ActiveEnergy), reactive energy measurements (s4grid:ReactiveEnergy), apparent power measurements (s4grid:ApparentPower), demand register measurements (s4grid:DemandRegister), active power measurements (s4grid:ActivePower), reactive power measurements (s4grid:ReactivePower), current measurements (s4grid:Current), voltage measurements (s4grid:Voltage) and power factor related measurements (s4grid:PowerFactor).
SAREF4GRID also categorises the main properties related to quality measurements of a power line (s4grid:QualityProperty):duration of voltage sags (s4grid:DurationVoltageSag), duration of voltage swells (s4grid:DurationVoltageSwell) and duration of long power failures (s4grid:DurationLongPowerFailure).
SAREF4GRID allows modelling the storing, sorting and accessing of data groups or data series (i.e., capture objects in COSEM) in the meter by means of the s4grid:ProfileGeneric class, as presented in Figure 16. Capture objects are specific attributes or elements of (an) attribute(s) of COSEM objects. The capture objects are collected periodically or occasionally. The representation of the profile generic of a meter has been extracted from the IEC 62056-6-2:2017.
A profile generic is represented by the objects that it captures (s4grid:Clock, s4grid:PropertyValues and s4grid:Measurements). These capture objects are collected in each period defined in the s4grid:hasCapturePeriod property.
Figure 17 provides an overview of the modelling of get services (s4grid:GetService). A get service is performed through get operations (s4grid:GetOperation). The get operation modelling involves two main concepts, namely s4grid:CosemOperationInput and s4grid:GetOperationOutput. As can be seen in the figure, the modelling of get services totally relies on the service model proposed in ONEM2M. The representation of the inputs and outputs of a get service has been extracted from the IEC 62056-6-2:2017.
A get operation needs one input which represents what is going to be retrieved (the whole instance or just a property of the instance). Therefore, the input of a get operation can be either a class, the range of datatype property, or the range of an object property. The s4grid:CosemOperationInput class specifies the instance from which data is going to be retrieved by indicating the OBIS code (s4grid:obtainInputFromObis). If only the OBIS code is specified, it is understood that the whole instance is going to be retrieved. Moreover, the s4grid:GetOperationPropertyInput class specifies the object/datatype property of an instance from which data is going to be retrieved by indicating the OBIS code and the name of the object/datatype property (s4grid:obtaintInputForProperty). If the OBIS code and the property name are specified, it is understood that just the range of a property of the instance is going to be retrieved.
A get operation is going to generate one output which represents the type of what is going to be retrieved. The output of a get operation (s4grid:GetOperationOutput) can be either a class or a datatype. The s4grid:GetOperationDataOutput specifies that the output is going to be a datatype. In this case the type of the output is defined using the s4grid:hasOutputDataType property, indicating the name of the datatype. The s4grid:GetOperationObjectOutput class specifies that the output is going to be a class. In this case the type of the output is defined using the s4grid:hasOutputObjectType property, indicating the name of the class.
Additionally, in the case of a get service of a s4grid:ProfileGeneric class a selective access (s4grid:SelectiveAccess) can be specified. This indicates the range of entries to be retrieved (s4grid:EntryDescriptor) or the range of values (s4grid:RangeDescriptor) to be retrieved from a s4grid:ProfileGeneric class.
Figure 18 provides an overview of the modelling of set services (s4grid:SetService). A set service is performed through set operations (s4grid:SetOperation). The set operation modelling involves one main concept, namely s4grid:CosemOperationInput. As can be seen in the figure, the modelling of set services totally relies on the service model proposed in ONEM2M. In order to reduce duplication with the ONEM2M documentation, the reader is referred to the ONEM2M specification for details about service modelling. The representation of the inputs and outputs of a set service has been extracted from the IEC 62056-6-2:2017.
A set operation needs two inputs: the element that is going to be modified and the new data that is going to replace the old data. The element that is going to be modified is represented by a class meanwhile the new data is represented either by a class, the range of a datatype property, or the range of an object property (depending on if the whole instance is going to be modified or just a property). Therefore, the s4grid:CosemOperationInput class specifies the instance from which data is going to be modified by indicating the OBIS code (s4grid:obtainInputFromObis) and the new data is represented either by the s4grid:SetOperationObisInput, s4grid:SetOperationObjectInput or s4grid:SetOperationDataInput classes. The s4grid:SetOperationObisInput class indicates that the whole instance is going to be modified. In this case the type of the input is defined using the s4grid:hasInputObjectType property, indicating the name of the class expected to modify the instance. The s4grid:SetOperationObjectInput class indicates that just the range of an object property of the instance is going to be modified. In this case the type of the input is defined using the s4grid:obtainInputForProperty, which indicates the name of the object property whose range is going to be modified, and the s4grid:hasInputObjectType property, indicating the name of the class expected to modify the range of the object property. The s4grid:SetOperationDataInput class indicates that just the range of a datatype property of the instance is going to be modified. In this case the type of the input is defined using the s4grid:obtainInputForProperty, which indicates the name of the datatype property whose range is going to be modified, and the s4grid:hasInputDataType property, indicating the name of the datatype expected to modify the range of the datatype property.
Figure 19 provides an overview of the modelling of action services (s4grid:ActionService). An action service is performed through action operations (s4grid:ActionOperation). The action operation modelling involves one main concept, namely s4grid:CosemOperationInput. As can be seen in the figure, the modelling of action services totally relies on the service model proposed in ONEM2M. In order to reduce duplication with the ONEM2M documentation, the reader is referred to the ONEM2M specification for details about service modelling. The representation of the inputs and outputs of an action service has been extracted from the IEC 62056-6-2:2017.
An action operation needs two inputs: the element that is going to be affected by an action and the parameters necessary for the action to be executed. The element that is going to be affected by an action is represented by a class and the parameters are either represented by a class or a value. Therefore, the s4grid:CosemOperationInput class specifies the instance that is going to be affected by the action by indicating the OBIS code (s4grid:obtainInputFromObis) and the parameters are represented either by the s4grid:SimpleActionOperationInput or the s4grid:ComplexActionOperationInput. The s4grid:SimpleActionOperationInput class indicates that the parameter needed by the action to operate is simple (i.e., integer, string, etc.). In this case the value of the parameter is defined using the s4grid:hasActionValue property. The s4grid:ComplexActionOperationInput class indicates that the parameter needed by the action to operate is complex (i.e., structure). There are two cases of complex parameters: s4grid:PresetAdjustingTime class, which is needed by a s4grid:Clock to modify the time, and s4grid:SpecialDayEntry class, which is needed by an s4grid:ActivityCalendar to adding a new special day.
