SAREF extension for smart grid

Introduction

This document presents the implementation of the SAREF extension for the electric grid domain (SAREF4GRID).

General overview

Figure 1, Figure 2, Figure 3 and Figure 4 present an overview of the classes and the properties included in the SAREF4GRID extension.

Meter

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.

Firmware

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.

Network Interface

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.

Clock

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.

Breaker State

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

Script Table

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.

Scheduled Action

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.

Activity Calendar

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

Power Line Properties

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

Profile Generic

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.

Get service

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.

Set service

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.

Action service

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.

Examples

The example presented in Figure 20 depicts an electric grid meter (ex:Meter1234). It can be described by a set of meter properties (such as the one shown in the figure, ex:ScrollDisplayMode) that are identified by an OBIS code (s4grid:hasObis). Notice that some meter properties do not specify a unit of measure.

SAREF4GRID does not aim to provide an exhaustive definition of all the properties defined in the IEC 62056-6-2:2017. Instead, it defines a set of general properties (those shown in Figure 6, e.g., s4grid:ScreenDisplay in the figure) and specific properties can be related to these general properties using the SKOS ontology. Using SKOS more specific properties can be defined specifying from which general property they are derived (skos:narrower), and which properties belong to a general property (skos:broader).

The example presented in Figure 21 depicts an electric grid meter (ex:Meter1234). It can be described by a set of meter properties (e.g., ex:ActivePowerLimitContract1TariffPeriod1) which are identified by an OBIS code (s4grid:hasObis). The meter properties used to describe a meter are broader than the properties shown in Figure 6 (e.g., s4grid:PowerLimit). Notice that some meter properties specify a unit of measure (e.g., om:watt).

Unlike other SAREF extensions, a meter firmware is not defined by a datatype property. The example presented in Figure 22 depicts a meter firmware (e.g., ex:ActivePLCFirmware) which is represented by an OBIS code (s4grid:hasObis).

Figure 23 contains an example of a network interface (ex:MacAddress1234) defined for a meter. Moreover, the network interface is represented by an OBIS code (s4grid:hasObis).

Figure 24 contains an example of a meter clock (ex:Clock1234). Moreover, the clock interface is represented by an OBIS code (s4grid:hasObis). Notice that the clock is not only represented by a time (s4grid:hasTime), but is also represented by the time zone in which it is located and how the time is changed.

Figure 25 contains an example of a meter brekaer state (ex:CurrentConnectivityState). In this example, it is represented that the meter is physical connected (s4grid:hasOutputState), internal connected (s4grid:hasControlState) and it can be be remotely, manually and locally disconnected (s4grid:hasControlMode). Moreover, the breaker state is represented by an OBIS code (s4grid:hasObis).

Figure 26 contains an example of how scripts (ex:ConnectionScript and ex:DisconnectionScript) are stored in the meter. A script table (ex:DisconnectScriptTable) is needed in order to represents where the scripts are located. Moreover, a single schedule action (ex:DisconnectControlScheduler) is used to represent that a script is going to be executed in a determined date. Moreover, the script table and single scheduled action are represented by an OBIS code (s4grid:hasObis).

Figure 27 contains an example of how an activity calendar (ex:ActivityCalendarContract1-1234) is represented in a meter. This activity calendar is represented by an active season (ex:SeasonActive1) which is described by the date at which it starts and two regular day profiles: one that describes working days (ex:WeekDay) and other that describes weekend days (ex:WeekendDay). Each day profile is represented by when a billing period starts each day (ex:WeekDayTariffPeriod1 and ex:WeekendDayTariffPeriod1) and what scripts need to execute to make the billing (ex:ResetBillingPeriod1 and ex:ResetBillingPeriod2). Additionally, a special day profile (ex:SpecialTariffPeriod1) defines which days are special (e.g., festive) and, therefore, another tariffication is going to be applied. Moreover, the activity calendar is represented by an OBIS code (s4grid:hasObis). Notice that just the active calendar is represented (e.g., the passive calendar associated to the active calendar is not represented) in order to simplify the example.

One of the main functions of electric grid meters is to take measures from a power line in order to control what is happening in the electric grid. Figure 28 presents an example of a power line measurement (ex:TotalIncrementalActiveEnergyImportMeasurement123) for a power line property (ex:TotalIncrementalActiveEnergyImport) that is identified by an OBIS code (s4grid:hasObis).

As with meter properties, SAREF4GRID does not aim to provide an exhaustive definition of all the properties defined in the IEC 62056-6-2:2017. Instead, it defines a set of general properties (those shown in Figure 14 and Figure 15, e.g., s4grid:ActiveEnergy in the figure) and specific properties can be related to these general properties using the SKOS ontology. Using SKOS more specific properties can be defined specifying from which general property they are derived (skos:narrower), and which properties belong to a general property (skos:broader).

Figure 29 presents another example of a power line measurement (ex:MaximumDemandRegisterImportC1TP1Measurement136) for a power line property (ex:MaximumDemandRegisterImportC1TP1) which are identified by an OBIS code (s4grid:hasObis). The power line properties are broader than the properties shown in Figure 14 and Figure 15 (e.g., s4grid:DemandRegister).

Different profile generics can be generated in order to access data groups which are stored in an electric grid meter. Figure 30 presents an example of a profile generic (ex:IncrementalLoadProfile1234) whose objective is to store the incremental energy values that a meter measures (ex:Measurement1 to ex:Measurement6) each hour. Additionally, the profile generic stores the clock (ex:Clock1234) to indicate the time at which the profile generic captures elements, and the AMR status (ex:PropertyValue1) that the meter stores. Moreover, the profile generic is represented by an OBIS code (s4grid:hasObis).

Each element that a meter stores can be obtained through a get service. Figure 31 presents an example of how it is specified that a COSEM element is going to be obtained. A get service (ex:GetServiceIncrementalLoadProfile) is executed through a get operation (ex:GetOperationIncrementalLoadProfile). This operation indicates the desired input (ex:OperationInputIncrementalLoadProfile), which in this case it specifies the element from which data is going to be retrieved, and the desired output (ex:OutputIncrementalLoadProfile), which in this case specifies the data structure that is going to be given.

Figure 32 presents an example of how it is specified that an attribute of a COSEM element is going to be obtained. Notice that in this example, the attribute corresponds to a datatype property of the SAREF4GRID ontology. A get service (ex:GetServiceCapturePeriodIncrementalLoadProfile) is executed through a get operation (ex:GetOperationCapturePeriodIncrementalLoadProfile). This operation indicates the desired input (ex:OperationInputCapturePeriodIncrementalLoadProfile), which in this case specifies the datatype property of the element from which data is going to be retrieved, and the desired output (ex:OutputCapturePeriodIncrementalLoadProfile), which in this case specifies the datatype that is going to be given.

Figure 33 presents an example of how it is specified that an attribute of a COSEM element is going to be obtained. Notice that in this example, the attribute corresponds to an object property of the SAREF4GRID ontology. A get service (ex:GetServiceDisconnectionScript) is executed through a get operation (ex:GetOperationDisconnectionScript). This operation indicates the desired input (ex:OperationInputDisconnectionScript), which in this case specifies the object property of the element from which data is going to be retrieved, and the desired output (ex:OutputDisconnectionScript), which in this case specifies the data structure that is going to be given.

Property-related services in get operations usually refer to the entire property. However, in the case of certain properties, selective access to only part of the property may be provided. Figure 34 presents an example of how it is specified that a range of values are going to be retrieved from a profile generic. A selective range get service (ex:GetServiceIncrementalLoadProfileRange) is executed through a get operation (ex: GetOperationIncrementalLoadProfileRange). This operation indicates the desired input (ex:OperationInputIncrementalLoadProfileRange), which in this case specifies the element from which data is going to be retrieved, and the desired output (ex:OutputIncrementalLoadProfileRange), which in this case specifies the data structure that is going to be given. Additionally, a selective access with a range descriptor (ex:RangeDescriptor1) indicates that just the entries whose value is between 1 and 10 are going to be retrieved.

Figure 35 presents an example of how it is specified that a range of entries are going to be retrieved from a profile generic. A selective entry get service (ex:GetServiceIncrementalLoadProfileEntry) is executed through a get operation (ex: GetOperationIncrementalLoadProfileEntry). This operation indicates the desired input (ex:OperationInputIncrementalLoadProfileEntry), which in this case specifies the element from which data is going to be retrieved, and the desired output (ex:OutputIncrementalLoadProfileEntry), which in this case specifies the data structure that is going to be given. Additionally, a selective access with an entry descriptor (ex:EntryDescriptor1) indicates that just the top 10 entries are going to be retrieved.

Each element that a meter stores can be modified through a set service. Figure 36 presents an example of how it is specified that a COSEM element is going to be modified. A set service (ex:SetMulticastCommunicationIdentifier) is executed through a set operation (ex:SetOperationMulticastCommunicationIdentifier). This operation indicates the desired input (ex:InputMulticastCommunicationIdentifier), which in this case specifies the element from which data is going to be modified and the data structure that is going to replace the previous data.

Figure 37 presents an example of how it is specified that an attribute of a COSEM element is going to be modified. Notice that in this example, the attribute corresponds to a datatype property of the SAREF4GRID ontology. A set service (ex:SetServiceCapturePeriodIncrementalLoadProfile) is executed through a set operation (ex:SetOperationCapturePeriodIncrementalLoadProfile). This operation indicates the desired input (ex:InputICapturePeriodIncrementalLoadProfile), which in this case specifies the datatype property of the element from which data is going to be modified and the data type that is going to replace the previous data.

Figure 38 presents an example of how it is specified that an attribute of a COSEM element is going to be modified. Notice that in this example, the attribute corresponds to an object property of the SAREF4GRID ontology. A set service (ex:SetServiceDisconnectionScript) is executed through a set operation (ex:SetOperationDisconnectionScript). This operation indicates the desired input (ex:InputIDisconnectionScript), which in this case specifies the object property of the element from which data is going to be modified and the data structure that is going to replace the previous data.

Each element that a meter stores can be affected through an action service. Figure 39 presents an example of how it is specified that a COSEM element is going to be affected by an action. Notice that in this example the input parameter needed to execute the action is simple (e.g., integer, string, etc.). An action service (ex:ResetServiceRegister) is executed through an action operation (ex:ResetServiceOperation). This operation indicates the desired input (ex:ResetServiceOperationInput), which in this case specifies the element that is going to be affected by the action and the value of the parameter needed by the action.

Figure 40 presents an example of how it is specified that a COSEM element is going to be affected by an action. Notice that in this example the input parameter needed to execute the action is a structure. An action service (ex:PresetAdjustingTimeServiceClock) is executed through an action operation (ex:PresetAdjustingTimeOperation). This operation indicates the desired input (ex:PresetAdjustingTime1), which in this case specifies the element that is going to be affected by the action and the values of the parameter structure needed by the action.

Figure 41 presents an example of how it is specified that a COSEM element is going to be affected by an action. Notice that in this example the input parameter needed to execute the action is a structure. An action service (ex:SpecialDayEntryServiceActivityCalendar) is executed through an action operation (ex:SpecialDayEntryOperation). This operation indicates the desired input (ex:SpecialDayEntry1), which in this case specifies the element that is going to be affected by the action and the values of the parameter structure needed by the action.