OpenADR Ontology: Semantic Enrichment of Demand Response Strategies in Smart Grids

Demand Response (DR) gains increasing attention as a core building block of smart grids. Advanced ICT systems have been made available in the last decades and have been employed already in commercial energy markets. As more and more hardware and software solutions are flooding the market, the need for interoperability among systems has become a necessity. Building upon OpenADR, a well-known standard for DR, this work presents its semantic enrichment towards transforming it into an ontology (publicly available), which ultimately enables semantic interoperability among various DR stakeholders and systems and other semantic-related features like data validation, reusing terms and integration with other standard ontologies. Following the Linked Open Terms methodology, a detailed description of the main OpenADR services is presented, encoded in OWL, along with needed extensions that derive from other well-known ontologies. By introducing an OpenADR ontology, the adoption and deployment of OpenADR in both research and industrial implementations is expected to expand, ultimately promoting significantly semantic interoperability in DR systems.


A. Motivation
Demand Response (DR) is already part of the energy market in multiple European countries and in many more there are future plans drafted to accommodate this relatively new business model [1]. An increasing number of equipment, services, roles, as well as information exchange have made their appearance in every day energy and financial transactions. Thus, although enabling the participation of customers in DR schemes is becoming a commodity, besides opportunities, it also gives birth to new challenges, one of which is interoperability [2].
The EU Energy Efficiency Directive establishes the requirements and technical modalities for the respective stakeholders among member states towards facilitating the uptake of DR services [3]. Nevertheless, actual deployment of DR has an increasing number of variations in response to different energy market products and regulations amongst member states. This variety of DR programs, where each has its own requirements, highlights the need for clearly defined standards to communicate DR program and market information [4]. Thus, multiple standards have been proposed to describe this domain.
The Energy Market Information Exchange (EMIX 1 ) is a standard for price and product definition. The Universal Smart Energy Framework (USEF [5]) describes the market for flexibility, enabling commoditization and market trading of flexible energy use. The Smart Grid Architecture Model (SGAM [6]) aims to present the design of smart grid use cases from an architectural viewpoint. It consists of five layers representing business objectives and processes, functions, information exchange and models, communication protocols and components. The NAESB Energy Usage Information Model [7] allows utilities and customers to exchange information about electricity usage. These standards describe their corresponding domain and provide their own data model. However, they do not integrate semantics in their specification, as defined by the W3C [8].
OpenADR is intended to benefit utilities and aggregators by facilitating DR communications, encompassing concepts from other DR standards, such as EMIX [9] and the NAESB Energy Usage Information Model [7]. However, the OpenADR standard does not explicitly define how these concepts are integrated. OpenADR expends significant effort in standardising the messages to be exchanged in a DR environment, but there are several unclear relations between concepts. In fact, the lack of formal semantics in OpenADR hinders its reusability and interoperability, even with systems using the same standard, as well as systems using other standards.

B. Background: Ontologies & Semantics
In computer science, an ontology is understood as a formal, explicit specification of a shared conceptualisation [10]. A conceptualisation refers to an abstract model of some phenomenon in the world, including concepts and relationships between them, as well as, constraints related to it. The term formal refers to the fact that an ontology is machine-readable, which excludes natural language. The term explicit means that concepts, relationships and constraints are unambiguously defined. Finally, shared refers to the fact that an ontology captures consensual knowledge that is accepted by a group [10].
An ontology describes concepts in a domain of discourse, properties describing various features and attributes of these concepts and restrictions on properties [11]. There are two main types of properties: 1) object properties that describe the relationships between concepts and, 2) datatype properties that describe relationships between concepts and data values.
Ontologies are used for sharing a common understanding of the structure of information among people or software agents and for making explicit domain assumptions. In conjunction with the formal specification of domain terms, ontologies provide support for semantic interoperability, which allows (software) agents to unambiguously understand the meaning of exchanged data [11]. Notice that the current paper is contextualised in the W3C definition of semantics [8].
Ontological specifications can be published associated to a standard or as a part of one. These ontologies satisfy the requirements associated to the standard's specification. Consequently, they provide an agreed baseline approved by the community that can be used to describe the domain.

C. Related work
This section presents a review of DR standards, as well as, ontologies that are relevant for smart grids and other overlapping domains. Table I provides an overview of several topics that are tackled by the surveyed works.
In the context of smart grids, several ontologies have been proposed that vary significantly in regards to the topics they cover. On the one hand, there are ontologies that are very restricted, since they account only for measurements (OntoEnergy [12]), or measurements and equipment (CIM ONTOLOGY 2 , MAS2TERING [13], ThinkHome [14]). On the other hand, there are ontologies that cover additional topics, such as events (MIRABEL 3 ) or geolocation (BOn-SAI [15], SEMANCO 4 , SESAME 5 ). Lastly, SAREF4ENER 6 and OEMA 7 are notable examples of ontologies that cover the largest set of topics as they also account for stakeholders participating in smart grids. However, despite their semantic properties, none of these ontologies model DR.
On the other side of the spectrum, several standards, which have no semantic properties as they are not ontologies, have been developed providing data schemas for various topics related to smart grids. The CENELEC family of standards (EN 16836-2 8 , EN 50491-11 9 , EN 50631-1 10 ) covers topics related to measurements, equipment, energy products and events (EN-61970 11 ), while only EN 50090-1 12 accounts also for DR. Similarly, the IEC family of standards (CIM, 62056 COSEM 13 , 62746 14 ) covers a variety of topics, including DR.
Regarding other standards that allow for DR, there have been several proposals throughout the years, notable examples of which are Energy@home 15 , USEF [5], EFI 16 , FSGIM 17 and OpenADR 18 . From these, OpenADR has been selected for investing upon as it has gained worldwide acceptance with deployments all around the world that have demonstrated significant results for issues, such as peak load reduction [16].
Nevertheless, neither OpenADR, nor any of the other standards explored (presented in Table I), to the knowledge of the authors, provide semantic properties in the context of DR.

D. Contribution & Organisation
The main contribution of this paper is the semantic enrichment of the OpenADR standard into an ontology, i.e., a formal specification of a shared conceptualisation [10] that eliminates ambiguities and provides the necessary building blocks for semantic interoperability. The methodology followed for developing the OpenADR ontology is detailed and the benefits of its semantic properties are illustrated, i.e., data validation, reusing terms and integration with other standards.
The manuscript is organized as follows: Section II introduces the methodology for developing the OpenADR ontology, followed by its detailed description in Section III and the clear benefits of OpenADR's semantic enrichment in Section IV. Finally, Section V concludes the manuscript.

II. METHODOLOGY
This section presents Linked Open Terms (LOT), the ontology development methodology that was employed to develop the OpenADR ontology. LOT was first introduced in [18] and was further developed in [19]. The LOT methodology is built on top of the ontological engineering activities defined in the well-known NeOn methodology [20]. It is based on agile techniques allowing the ontology development to be organised into iterations and, thus, facilitating the evaluation and continuous improvement of the ontology providing techniques for: 1) reusing existing terms published in other ontologies, which increases interoperability of the resulting ontology and maximises its alignment with existing ones and, 2) publishing a developed ontology according to the Linked Data 19 principles. LOT supports the entire workflow of ontology development by providing tools, recommendations and iterations over the following activities:  Implementation: INDICATES THE IMPLEMENTATION TYPE THAT  CAN BE AN ONTOLOGY OR THE DATA SERIALIZATION FORMAT. THE LAST ROW OF THE TABLE DESCRIBES THE OPENADR ONTOLOGY PROPOSED HERE.   Topics  Data Model Location Equipment Measurements Events Stakeholders Demand Response Implementation SAREF4ENER 6 Ontology MAS2TERING [13] Ontology OEMA 7 Ontology CIM Ontology 2 Ontology OntoENERGY [12] Ontology ThinkHome [14] Ontology BOnSAI [15] Ontology Mirabel 3 Ontology SEMANCO 4 Ontology SESAME-S 5 Ontology SGAM [17] UML IEC CIM 13 15 XML NAESB [7] XML eMIX [9] XML USEF [5] XML EFI 16 XML OpenADR Ontology Ontology • Implementation: The ontology is implemented using a formal language (e.g., OWL [8]) based on the requirements identified in the previous activity. During this activity, the ontology is also evaluated in order to guarantee its technical quality. • Publication: The aim of this activity is to make the ontology available online both as a human-readable documentation and in a machine-readable format. The machinereadable format is obtained during the implementation activity. The human-readable documentation should be carried out during this activity by describing, in HTML pages, the content of the ontology with diagrams and examples to improve its readability and reusability. • Maintenance: During this activity, the ontology is updated with new information, which may be needed after new requirements or defects have been identified.
Taking as input the specification of OpenADR 18 and following the LOT methodology, the proposed OpenADR ontology was developed using the Web Ontology Language (OWL), so as to be machine-readable. In addition, the ontology is published in HTML format and, thus, it is also human-readable. Moreover, following the LOT methodology, the proposed OpenADR ontology was evaluated in order to ensure that it satisfies all the requirements of the OpenADR specification and that there are no modelling errors. More information related to the LOT methodology for developing ontologies is available online 20 .

III. OPENADR ONTOLOGY DESCRIPTION
The code and documentation for the proposed OpenADR ontology are available at GitHub 21 and are also published online 22 . Figure 1 illustrates an overview of the OpenADR ontology. White and grey rectangles represent classes and white tipped arrows represent the subClassOf relation between two classes, i.e., a hierarchy. The origin of the arrow is the class to be declared as a subclass of the class at the tip of the arrow. Filled tipped arrows are used to represent object properties between classes. The ontologies in which each concept or relation are defined is indicated by the use of prefixes, e.g., oadr:Event is defined in the https://w3id.org/def/openadr# namespace.
The ontology defines concepts that support the four services defined by the  the EiReport service, 3) the EiRegisterParty service and, 4) the EiOpt service. To enrich the OpenADR ontology with regards to temporal and spatial context, e.g., the schedule of a node or the geographical situation of a service area, other wellknown and publicly available ontologies were reused, such as OWL-Time [21] for temporal terms and GeoSPARQL [22] for geospatial data. Therefore, instead of defining these temporal and geospatial terms from scratch, they are reused from already published ontologies, as suggested by LOT.

A. EiEvent Service
The EiEvent service is used to communicate DR events containing signals for, e.g., energy curtailment request or electricity prices. Virtual Top Nodes (VTNs) generate events and transmit them to Virtual End Nodes (VENs), which have to confirm or reject their participation. The proposed OpenADR ontology includes classes related to this service, such as Event, VTN, VEN and Signal, as illustrated in Figure 1. An Event is related to an Event Descriptor, which describes its characteristics. An Event can be related to one or more targets, which can include a VEN, a Resource, an Asset or a Service Area. A Signal is applicable during one or more time periods (SignalInterval) and is measured in particular units (ItemBase).
The proposed ontology allows the generation of payloads for OpenADR data exchange. Listing 1 presents a payload example using JSON-LD, which is a lightweight format for representing linked data based on the JSON standard [23]. In this format, the payloads have two main sections. In @context (lines 1-7), namespaces are declared from which classes are used/imported in the rest of the payload. The @graph section (lines 8-81) encodes the data as an array of linked classes, each of which contains: 1) @id, which is the object's unique identifier in the context of the payload and, 2) @type, which indicates the class and the namespace variable from which it is imported (this property is mandatory but can be omitted if it is specified in the @context section). The remaining properties are class-specific.
Listing 1 provides an example payload for the EiEvent service that uses the classes and properties of the OpenADR ontology to describe an Event. This payload is issued by a VTN, whose identifier is "example:VTN1" (line 10), to a VEN, whose identifier is "example:venID 1234" (line 29). The event description contains its priority, which is 0 (line 36), as well as its status, which is currently set to active (line 38). The event includes one signal, which is encoded by the object with identifier "example:ElectricityPriceSIG 01" (line 26). This is a specific DR use case of an electricity price signal (or Time of Use tariff), as specified by its type, which is used towards implicitly incentivizing end-users to modify their consumption patterns. The signal active period is defined by the time interval with identifier "example:ActiveInterval" (line 23). During this interval, the new electricity price provided is 0.10 USD per kWh, as specified by the signal properties and links to the remaining objects (lines 69 and 73). Payloads following the OpenADR ontology can encode multiple events, each of which has multiple signals. Each signal may define different DR requests (e.g., electricity prices, setpoints, etc.) over (potentially multiple) disjoint time periods, thus, allowing for fully dynamic DR strategies by aggregators and retailers.

B. EiReport Service
The EiReport service is used by VENs and VTNs to publish periodic or one-time reports regarding the state of resources.
The proposed OpenADR ontology defines several classes related to this service, such as Report and its derived classes, i.e., Metadata report and Data report. To describe the reporting capabilities of VTNs/VENs, a Metadata report has a Report Descriptor property. This descriptor contains information regarding the type of the report (e.g., reading, usage and setpoint), the type of the reported reading (e.g., baseline, usage and powerFactor) and the units for the data in the report (e.g., current, voltage and energyReal), among others. A Data report specifies data points in a particular report instance.

C. EiRegisterParty Service
The EiRegisterParty service is employed to register a VEN to a VTN and must be invoked prior to any interaction. The VEN needs to be configured out of band with the address of the VTN and the information exchanged revolves around the profiles and transports used by the VEN to communicate with the VTN, as well as, any potential supported extensions.
The proposed OpenADR ontology defines datatype properties regarding the hasProfileName, i.e., which version of OpenADR the VTN/VEN is compliant with (e.g., 2.0b), the hasTransportName (e.g., HTTP) and whether XML signatures are supported. Lastly, the ontology defines the hasReportOnly property, a boolean value indicating whether a VEN is only able to issue reports, i.e., its inability or unwillingness to participate in DR events.

D. EiOpt Service
The EiOpt service is used to create and communicate temporal availability (OptIn) or unavailability (OptOut) schedules from a VEN to a VTN. These schedules may be related with specific market contexts and provide the necessary means to a VTN to have a more specific picture regarding the willingness of a VEN to participate in DR events.
As depicted in Figure 1, the proposed OpenADR ontology includes the Opt class, which is related to the Schedule of a target. The Opt class also has a particular marketContext that should be considered in order to infer the target's availability.

IV. BENEFITS OF THE USE OF W3C SEMANTICS
The adoption of semantics to express formal models entails a set of immediate benefits, namely: a) Data Validation: Data modelled by an ontology can be automatically validated by means of a reasoner, which checks the absence of inconsistencies in the data, or SHACL shapes [24], which check a set of restrictions involving content and model. While languages like XML Schema are limited to tree structures, SHACL supports the validation of graphbased data, where any node can link to any other node, thus, allowing richer conditions to be validated. This validation mechanism adds a security layer, which ensures that data only contain relevant information. SHACL shapes for the proposed OpenADR ontology can be found in our Github repository 23 . For instance, they allow to validate that the type of the element that sends the "Event091214 043741 028 0" (Listing 1) is of type VTN and the target of the event is of type VEN. b) Integration with other standards: The adoption of W3C semantics allows the definition of mappings [8], i.e., equivalences between two ontologies. For instance, a term defined in SAREF 24 , which is an ontology for describing smart applications, can be linked directly to an OpenADR term of the proposed ontology.
c) Reusing other ontologies: Ontologies can be linked with each other to reuse existing terms preventing information duplication, diminishing development effort and establishing a common vocabulary. As an example, in Listing 1 the active interval of the Event091214 043741 028 0 (line 42) is a TimeInterval defined in the OWL Time ontology.

V. CONCLUSIONS
This work describes the process used to develop an ontology for the OpenADR standard, which provides the foundations required to implement semantically interoperable DR systems. Since no other ontologies for DR exist in the literature to the authors knowledge, it can be concluded that DR is still a new field that does not exploit the benefits of ontologies, e.g., formal data validation, extensibility by reusing other existing standards and ontologies, while also easing the integration with systems that are developed based on other standards. Furthermore, Semantic Web technologies are the pillars for implementing architectures in which systems are semantically interoperable. Therefore, the lack of ontologies entails a lack of adopting these semantic technologies and, hence, a lack of semantic interoperable systems as defined by the W3C [8]. The presented ontology addresses all these issues providing the required enrichment for supporting semantic interoperability in the context of DR.
Future work will be oriented to the development of an architecture in which systems are semantically interoperable, allowing the transparent exchange and consumption of data between standards, such as USEF and the proposed OpenADR ontology.