update documentation from TS

<div class="alert-warning">NOTE: The text in this section is extracted from ETSI TS 103 410-12 (V2.1.1) <a href="#[0]">[0]</a>, and therefore falls inside the <a href="https://www.etsi.org/intellectual-property-rights">ETSI IPR Policy</a></div>

[The technical specification ETSI TS 103 410-12](#[0]) is a technical specification of SAREF4GRID, an extension of SAREF for the Smart Grid domain. This extension has been created by investigating resources from potential stakeholders of the ontology, such as standardization initiatives, associations, and existing ontologies and standards, as reported in ETSI TR 103 904 [[i.1]](#[i.1]). In addition, the use cases defined in ETSI TR 103 904 [[i.1]](#[i.1]) were also considered, namely:

* **Use case 1**: Remote management of meters.

* **Use case 2**: Management of tertiary sensor devices.

* **Use case 3**: Management of OLTC transformers.

* **Use case 4**: Detection of meter connectivity.

SAREF4GRID is an OWL ontology that extends SAREF and reuses two other ontologies. SAREF4GRID includes 56 classes (41 defined in SAREF4GRID and 15 reused from the SAREF and oneM2M), 50 object properties (28 defined in SAREF4GRID and 22 reused SAREF from and oneM2M), 45 data type properties (43 defined in SAREF4GRID and 2 reused from SAREF and oneM2M), and 28 individuals.

SAREF4GRID focuses on extending SAREF in order to create a common core of general concepts for smart grid data oriented to the IoT field. The main idea is to identify the core components, as mentioned, that could be extended for particular smart grid subdomains, for example, for high voltage networks.

The prefixes and namespaces used in SAREF4GRID and in [the technical specification ETSI TS 103 410-12](#[0]) are listed in [the Namespace Declarations section](#namespacedeclarations).

- [Raúl Garcia-Castro](http://www.garcia-castro.com/foaf.rdf#me) ([Universidad Politécnica de Madrid](http://www.oeg-upm.net/))

- [Sergio-Mario Carulli-Pérez](https://www.linkedin.com/in/sergio-mario-carulli-p%C3%A9rez-7632b5217/) ([Universidad Politécnica de Madrid](http://www.oeg-upm.net/))

- [Maria Poveda-Villalon](https://w3id.org/people/mpoveda/) ([Universidad Politécnica de Madrid](http://www.oeg-upm.net/))

<div class="alert-warning">NOTE: The text in this section is extracted from ETSI TS 103 410-12 (V2.1.1) <a href="#[0]">[0]</a>, and therefore falls inside the <a href="https://www.etsi.org/intellectual-property-rights">ETSI IPR Policy</a></div>

This clause shows different examples of how to instantiate the SAREF4GRID extension of SAREF. 

The example presented in [Figure 20](#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](#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 IEC 6205662 [[i.4]](#[i.4]). Instead, it defines a set of general properties (those shown in [Figure 6](#Figure_6), e.g. [s4grid:ScreenDisplay](#s4grid:ScreenDisplay) in the figure) and specific properties can be related to these general properties using the SKOS ontology [[i.5]](#[i.5]). 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>

    <img src="diagrams/SAREF4GRID_Example_meter_1.png" alt="Example of electric grid meter information I"/>

    <figcaption id="Figure_20">Figure 20: Example of electric grid meter information I</figcaption>

    </figure>

The example presented in [Figure 21](#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](#s4grid:hasObis)). The meter properties used to describe a meter are broader than the properties shown in [Figure 6](#Figure_6) (e.g. [s4grid:PowerLimit](#s4grid:PowerLimit)). Notice that some meter properties specify a unit of measure (e.g. [om:watt](http://www.wurvoc.org/vocabularies/om-1.8/watt)).

<figure>

    <img src="diagrams/SAREF4GRID_Example_meter_2.png" alt="Example of electric grid meter information II"/>

    <figcaption id="Figure_21">Figure 21: Example of electric grid meter information II</figcaption>

    </figure>

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

<figure>

    <img src="diagrams/SAREF4GRID_Example_firmware.png" alt="Example of electric grid meter firmware"/>

    <figcaption id="Figure_22">Figure 22: Example of electric grid meter firmware</figcaption>

    </figure>

[Figure 23](#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](#s4grid:hasObis)).

<figure>

    <img src="diagrams/SAREF4GRID_Example_network_interface.png" alt="Example of electric grid meter network interface"/>

    <figcaption id="Figure_23">Figure 23: Example of electric grid meter network interface</figcaption>

    </figure>

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

<figure>

    <img src="diagrams/SAREF4GRID_Example_clock.png" alt="Example of electric grid meter clock"/>

    <figcaption id="Figure_24">Figure 24: Example of electric grid meter clock</figcaption>

    </figure>

[Figure 25](#Figure_25) contains an example of a meter breaker state (ex:CurrentBreakerState). In this example, it is represented that the meter is physically connected ([s4grid:hasOutputState](#s4grid:hasOutputState)), internally connected ([s4grid:hasControlState](#s4grid:hasControlState)), and it can be remotely, manually and locally disconnected ([s4grid:hasControlMode](#s4grid:hasControlMode)). Moreover, the breaker state is represented by an OBIS code ([s4grid:hasObis](#s4grid:hasObis)).

<figure>

    <img src="diagrams/SAREF4GRID_Example_breaker_state.png" alt="Example of electric grid meter breaker state"/>

    <figcaption id="Figure_25">Figure 25: Example of electric grid meter breaker state</figcaption>

    </figure>

[Figure 26](#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 represent where the scripts are located. Moreover, a single scheduled 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](#s4grid:hasObis)).

<figure>

    <img src="diagrams/SAREF4GRID_Example_script.png" alt="Example of electric grid meter script table and scheduled action"/>

    <figcaption id="Figure_26">Figure 26: Example of electric grid meter script table and scheduled action</figcaption>

    </figure>

[Figure 27](#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 profile (ex:SeasonActive1) that 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 be executed to make the billing (ex:ResetBillingPeriod1 and ex:ResetBillingPeriod2). Additionally, a special day profile (ex:SpecialFriday1) 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](#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.

<figure>

    <img src="diagrams/SAREF4GRID_Example_activity_calendar.png" alt="Example of electric grid meter activity calendar"/>

    <figcaption id="Figure_27">Figure 27: Example of electric grid meter activity calendar</figcaption>

    </figure>

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](#Figure_28) presents an example of a power line observation (ex:TotalIncrementalActiveEnergyImportObservation123) for a power line property (ex:TotalIncrementalActiveEnergyImport) that is identified by an OBIS code ([s4grid:hasObis](#s4grid:hasObis)). 

As with meter properties, SAREF4GRID does not aim to provide an exhaustive definition of all the properties defined in IEC 62056-6-2 [[i.4]](#[i.4]). Instead, it defines a set of general properties (those shown in [Figure 14](#Figure_14) and [Figure 15](#Figure_15), e.g. [s4grid:ActiveEnergy](#s4grid:ActiveEnergy) in the figure) and specific properties can be related to these general properties using the SKOS ontology [[i.5]](#[i.5]). 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>

    <img src="diagrams/SAREF4GRID_Example_measurement_1.png" alt="Example of electric grid meter observations I"/>

    <figcaption id="Figure_28">Figure 28: Example of electric grid meter observations I</figcaption>

    </figure>

[Figure 29](#Figure_29) presents another example of a power line observation (ex:MaximumDemandRegisterImportC1TP1Observation136) for a power line property (ex:MaximumDemandRegisterImportC1TP1) that is identified by an OBIS code ([s4grid:hasObis](#s4grid:hasObis)). The power line properties are broader than the properties shown in [Figure 14](#Figure_14) and [Figure 15](#Figure_15) (e.g. [s4grid:DemandRegister](#s4grid:DemandRegister)).

<figure>

    <img src="diagrams/SAREF4GRID_Example_measurement_2.png" alt="Example of electric grid meter observations II"/>

    <figcaption id="Figure_29">Figure 29: Example of electric grid meter observations II</figcaption>

    </figure>

Different profile generics can be generated in order to access data groups that are stored in an electric grid meter. [Figure 30](#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:Observation1 to ex:Observation6) 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](#s4grid:hasObis)).

<figure>

    <img src="diagrams/SAREF4GRID_Example_profile.png" alt="Example of electric grid meter profile generic"/>

    <figcaption id="Figure_30">Figure 30: Example of electric grid meter profile generic</figcaption>

    </figure>

Each element that a meter stores can be obtained through a get service. [Figure 31](#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 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>

    <img src="diagrams/SAREF4GRID_Example_get_1.png" alt="Example of electric grid meter get service I"/>

    <figcaption id="Figure_31">Figure 31: Example of electric grid meter get service I</figcaption>

    </figure>

[Figure 32](#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>

    <img src="diagrams/SAREF4GRID_Example_get_2.png" alt="Example of electric grid meter get service II"/>

    <figcaption id="Figure_32">Figure 32: Example of electric grid meter get service II</figcaption>

    </figure>

[Figure 33](#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.

<figure>

    <img src="diagrams/SAREF4GRID_Example_get_3.png" alt="Example of electric grid meter get service III"/>

    <figcaption id="Figure_33">Figure 33: Example of electric grid meter get service III</figcaption>

    </figure>

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](#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>

    <img src="diagrams/SAREF4GRID_Example_get_4.png" alt="Example of electric grid meter get service IV"/>

    <figcaption id="Figure_34">Figure 34: Example of electric grid meter get service IV</figcaption>

    </figure>

[Figure 35](#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.

<figure>

    <img src="diagrams/SAREF4GRID_Example_get_5.png" alt="Example of electric grid meter get service V"/>

    <figcaption id="Figure_35">Figure 35: Example of electric grid meter get service V</figcaption>

    </figure>

Each element that a meter stores can be modified through a set service. [Figure 36](#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>

    <img src="diagrams/SAREF4GRID_Example_set_1.png" alt="Example of electric grid meter set service I"/>

    <figcaption id="Figure_36">Figure 36: Example of electric grid meter set service I</figcaption>

    </figure>

[Figure 37](#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>

    <img src="diagrams/SAREF4GRID_Example_set_2.png" alt="Example of electric grid meter set service II"/>

    <figcaption id="Figure_37">Figure 37: Example of electric grid meter set service II</figcaption>

    </figure>

[Figure 38](#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.

<figure>

    <img src="diagrams/SAREF4GRID_Example_set_3.png" alt="Example of electric grid meter set service III"/>

    <figcaption id="Figure_38">Figure 38: Example of electric grid meter set service III</figcaption>

    </figure>

Each element that a meter stores can be affected through an action service. [Figure 39](#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>

    <img src="diagrams/SAREF4GRID_Example_action_1.png" alt="Example of electric grid meter action service I"/>

    <figcaption id="Figure_39">Figure 39: Example of electric grid meter action service I</figcaption>

    </figure>

[Figure 40](#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>

    <img src="diagrams/SAREF4GRID_Example_action_2.png" alt="Example of electric grid meter action service II"/>

    <figcaption id="Figure_40">Figure 40: Example of electric grid meter action service II</figcaption>

    </figure>

[Figure 41](#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.

<figure>

    <img src="diagrams/SAREF4GRID_Example_action_3.png" alt="Example of electric grid meter action service III"/>

    <figcaption id="Figure_41">Figure 41: Example of electric grid meter action service III</figcaption>

    </figure>

### Normative references

* <a id="[0]">[0]</a> [ETSI TS 103 410-12 (V2.1.1)](https://www.etsi.org/deliver/etsi_ts/103400_103499/10341012): "SmartM2M; Extension to SAREF; Part 12: Smart Grid Domain".

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

* <a id="[2]">[2]</a> [ETSI TS 118 112 (V3.7.3)](https://www.etsi.org/deliver/etsi_ts/118100_118199/118112/03.07.03_60/ts_118112v030703p.pdf): "oneM2M; Base Ontology; (oneM2M TS-0012 version 3.7.3 Release 3)".

### Informative references

* <a id="[i.1]">[i.1]</a> ETSI TR 103 904 (V1.1.1): "SmartM2M; SAREF extension investigation; Requirements for the Smart Grid domain".

* <a id="[i.2]">[i.2]</a> IEC 62056-1-0:2014: "Electricity metering data exchange - The DLMS/COSEM suite - Part 1-0: Smart metering standardisation framework".

* <a id="[i.3]">[i.3]</a> IEC 62056-6-1:2017: "Electricity metering data exchange - The DLMS/COSEM suite - Part 6-1: Object Identification System (OBIS)".

* <a id="[i.4]">[i.4]</a> IEC 62056-6-2:2017: "Electricity metering data exchange - The DLMS/COSEM suite - Part 6-2: COSEM interface classes".

* <a id="[i.5]">[i.5]</a> W3C® Recommendation 18 August 2009: "SKOS Simple Knowledge Organization System - Reference", A. Miles and S. Bechhofer.