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.