Luis Gomes

Maxime Lefrançois
email: maxime.lefrancois@emse.fr

Pedro Faria

Zita Vale

Maxime Lefranc ¸ois †

Publishing Real-time Microgrid Consumption Data on the Web of Linked Data

Keywords: Microgrids, Smart grids, Data acquisition, Knowledge representation, Semantic Web, Linked Data Platform

I. Introduction

The power system paradigm started shifting in the last years with the mass adoption of distributed resources in the grid, that enables the division of management and the creation of grid islands [START_REF] Gomes | Domestic consumption simulation and management using a continuous consumption management and optimization algorithm[END_REF]. Microgrids are predicted to have an important role in the future of smart grid [START_REF] Fu | Microgrid generation capacity design with renewables and energy storage addressing power quality and surety[END_REF], and should enable numerous stakeholders to cooperate to manage generation, storage, and consumption of electric energy [START_REF] Khodayar | Integration of high reliability distribution system in microgrid operation[END_REF]. In this new power system paradigm, data is a crucial enabler for advanced microgrid and smart grid management [START_REF] Vaccaro | A Self-Organizing Architecture for Decentralized Smart Microgrids Synchronization, Control, and Monitoring[END_REF], [START_REF] Chen | Intelligent Identification of Voltage Variation Events Based on IEEE Std 1159-2009 for SCADA of Distributed Energy System[END_REF]. Data acquisition systems and the huge amount of data they produce enable applications such as forecasting [START_REF] Ramos | Short-term load forecasting based on load profiling[END_REF], load management [START_REF] Gomes | Distributed intelligent management of microgrids using a multi-agent simulation platform[END_REF], and knowledge extraction [START_REF] Morais | Defining electricity tariffs using the knowledge about the consumers profiles in ELECON project[END_REF].

Some microgrids were implemented in real scale, using new adapted facilities [START_REF] Washom | Ivory Tower of Power: Microgrid Implementation at the University of California, San Diego[END_REF], or adapting old facilities [START_REF] Lee | Preliminary implementation of microgrid with photovoltaic and microturbine for stand alone operation[END_REF]. These microgrids are able to manage their consumption and generation in an individual way. Yet, the data used in these facilities is closed, owned by the microgrid operators, and cannot be reused without great integration work. Such integration work is also needed each time two datasets need to be merged, each time a new data acquisition system needs to be added to the microgrid, or each time a new algorithm uses a proprietary format for input and output data. This lack of interoperability between systems is a burden that slows down the power system paradigm transition.

It has been noted in the literature that ontologies and open (Semantic) Web standards can form a basis for advanced communication architectures in smart grids [START_REF] Fang | Smart gridThe new and improved power grid: A survey[END_REF]. They offer common models and principles that enable to raise the abstraction of data up to the level of knowledge. Their use has been proposed in pilot smart grid projects to combine knowledge from heterogeneous sources [START_REF] Viau | ODAS: A Multi-Agent Architecture for Semantic Interoperability in Industrial Context[END_REF], optimize demand-response [START_REF] Simmhan | Semantic Information Integration for Smart Grid Applications[END_REF], or manage the energy of a building [START_REF] Curry | Enterprise energy management using a linked dataspace for energy intelligence[END_REF]. Other work focused on requirements for using the Semantic Web formalisms in Smart Grids [START_REF] Wagner | Semantic web technologies for a smart energy grid: Requirements and challenges[END_REF]. In the domain of smart buildings, [START_REF] Radulovic | Guidelines for Linked Data generation and publication: An example in building energy consumption[END_REF] proposed guidelines to publish data on the web of Linked Data.

This paper hence focuses on the following research question:

How can one leverage the Semantic Web formalisms to make the data acquired in a microgrid interoperable?

This paper more specifically focuses on the consumption data acquired in real-time in a existing microgrid site. The rest of this paper is thus organized as follows.

• Section II describes the microgrid demonstration site: the installations ( §II-A), its System Architecture ( §II-B), and the data that has been represented and published using the Semantic Web formalisms ( §II-C).

II. The Microgrid Site and the Data

The microgrid on which this work is based is located at the GECAD installations in the Institute of Engineering -Polytechnic of Porto (ISEP/IPP). Consumption data from this microgrid has already been acquired since late 2014.

A. The Installations

The microgrid site is composed of three individual and independent buildings, each having its own environment.

• Building F -this building has distributed generation that consists in: (i) an isolated photovoltaic system with 3 panels and a nominal generation power of 600 W; (ii) an isolated wind power system with 1 wind turbine and a nominal generation power of 1 kW. Electric energy can be stored in 24 modules of 24 V storage units divided equitably between the generation systems. The gateway of this building acquires production data every 10 seconds, but the consumption in this building is not yet measured;

B. The System Architecture

Figure 1 illustrates the different layers of the demonstrator microgrid system architecture. This architecture has been developed to test the execution of load management and load forecasting algorithms, to represent the actors/buildings using a multi-agent system, and to enable real-time simulations. This architecture may be transposed outside the demonstration world in real microgrid scenarios.

Let us describe shortly each of these layers.

The Knowledge Layer already implements common microgrid services, which are exposed via web services. Examples include forecasting algorithms, load management and scheduling algorithms, demand response information. These web services may hence be used by any stakeholder, while limiting the computational overhead on their side. Yet, as stated in the introduction, this layer would benefit from a greater inter-operationalization between systems and services.

The Multi-Agent System Layer enables the management of the microgrid by real actors (with real facilities), and simulated actors (with simulated facilities). Each real or simulated actor is represented by an agent, the microgrid is also represented by an agent, and all these agents interact together. Let us note that this layer complies with FIPA standards, and allows for the interaction with external agents, such as aggregators.

The Gateway Layer is the bridge between the building and the microgrid system. It consists in the actual gateways that are installed in the buildings of the microgrid, and that enable agents from the Multi-Agent System Layer to monitor and control services and equipment in the microgrid. Today, the services these gateways expose, and the communication protocols they use, form a mixture of non-interoperable market solutions and custom-made solutions. Hence again, integrating the Multi-Agent System Layer with a new gateway is a burden, and we identify a real need for defining inter-operational, and self-descriptive services.

The Knowledge, Multi-Agent System and Gateway layers are sufficient for microgrid in real uncontrollable environment. However, for demonstration, test, and validation purposes, we use an additional Real-Time Simulation Layer (OPAL-RT). This last layer enables us to simulate different dynamics in the microgrid, or to simulate the addition of capabilities. For instance, we could simulate the integration of a facility such as a wind farm, that otherwise cannot be integrated physically. Finally, this layer enables to simulate the integration of storage units or electrical vehicles.

This microgrid started acquiring consumption data from the GECAD installations late 2014. Since then, the demonstrator microgrid system architecture enabled the group to apply, test and validate management algorithms, and to test the integration of new agents. Today, we face two main needs that motivate the work in this paper:

• We want to start to make our data openly available, so that it may be used to test new services and algorithms for the microgrids. • We want to start working on the inter-operability at the different layers of the system architecture;

C. The consumption data

As a first step, this paper focuses on the description and the publication of the consumption data from building N. A total of four energy analyzers have been installed in the building, each acquiring a total of 35 measures every 10 seconds since late 2014. These energy analyzers measure different zones of Building N, as follows:

• Energy Analyzer 1 -takes measures from 1 office room, 1 server room, and 1 meeting room, with a total of 3 researchers; • Energy Analyzer 2 -takes measures from 3 office rooms, with a total of 6 researchers; • Energy Analyzer 3 -takes measures from 2 bathrooms and 1 common area used by all researchers;

• Energy Analyzer 4 -takes measures from 1 kitchen used daily by all the researchers of the building. Then, as these energy analyzers are originally designed to measure three-phase installations, and as building N is singlephase, each phase of the analyzer observes a different type of loads:

• Phase 1 -measures the consumption of HVAC systems in the zone; • Phase 2 -measures the consumption of ceiling lights in the zone; • Phase 3 -measures the consumption of electrical sockets in the zone. As each analyzer actually analyzes three single-phase installations, then the following 7 measures are irrelevant for our study: THD U12; THD U23; THD U31; U12; U23; U31; IN. On the other hand, measure Freq is assumed to be the same for each of the three phases.

This results in a total of 12 measure points, phase j of analyzer i measuring measure point 3(i -1) + j. Each measure point having a total of 10 measures, and adding the date and time of the measure, this results in 121 values. Assuming every value is stored as a 4 bytes float in an information system, 1 year of data acquired every 10 seconds (i.e., 3,153,600 records) hence corresponds at the very least to 100 MB of raw data. As the data is stored in a MySQL database table, and even though the type of this type is the lightweight MyISAM, the size of the table is around 200 MB. III. Publication of the Dataset as Linked Data This section presents our work in publishing the consumption data as Linked Data. Let us first recall some notions of the Semantic Web and the Linked Data.

A. Overview of the Semantic Web

In the domain of Smart Grids, a huge amount of knowledge is available and produced in heterogeneous and distributed manner. Knowledge Engineering and the Semantic Web actually aim at answering generic needs that arise from the production of knowledge. For instance: one may want to represent, manipulate, exchange, query, reason with, update, validate the knowledge.

Figure 2 represents the stack of Semantic Web formalisms. The first step towards inter-operationalization of data is to unambiguously name things with a Universal Resource Identifier (URI). For example, the following URI represent the unit Watt:

<http://qudt.org/1.1/vocab/unit#Watt>
URIs can be shortened with prefixes for readability, for example given prefix declaration: @prefix qudt-unit: <http://qudt.org/1.1/vocab/unit#> .

Then the URI above can be shortened as follows:

qudt-unit:Watt Then, the Resource Description Format (RDF) 1 enables to describe anything in terms of a set of triples (subject, predicate, object), i.e., the knowledge is described as an oriented acyclic graph. For example, the following RDF graph represents a quantity of type power, with a value of 150 W, using the QUDT ontology2 .

1 @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . 2 @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . 3 @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . 4 @prefix qudt: <http://qudt.org/schema/qudt#> . 5 @prefix qudt-quantity: <http://qudt.org/vocab/quantity>. 6 @prefix qudt-unit: <http://qudt.org/1.1/vocab/unit>. 7 8 <#quantity> rdf:type qudt:Quantity . 9 <#quantity> qudt:quantityValue <#value> . 10 <#quantity> qudt:quantityKind qudt-quantity:Power . 11 <#value> qudt:unit qudt-unit:Watt . 12 <#value> qudt:numericValue "150"ˆˆxsd:double .

The above example, and subsequent example, is a Turtle document 3 , Turtle being one concrete syntax to write RDF, among other (the original concrete RDF syntax was built on XML, as suggested by Figure 2, and is almost never used anymore). We will not redefine the already mentioned prefixes. <#quantity> is a relative URI, that needs to be resolved against a so-called base URI, which is classically the URL where the RDF document is located.

RDFS 4 and OWL 5 add semantics to RDF, with constructors (e.g., allValuesFrom) and axioms (e.g., subClassOf). For example, the following RDFS axioms define the domain and range of property qudt:unit. Inference engines (or reasoners), may then be built to understand such axioms and infer new knowledge (or reason) with RDF graphs. For example, a RDFS reasoner could use the union of the previously defined graphs and infer that qudt:Unit is a class, and that qudt-unit:Watt is an instance of this class.

Hence, RDF enables to represent knowledge about things that are identified by URIs, and ontologies enable to capture the semantics of this knowledge, and to reason. The Linked Data initiative leverages this, and defines four simple principles to publish RDF knowledge on the web [START_REF] Berners-Lee | Linked Data -Design Issues[END_REF]:

1) Use URIs as names for things 2) Use HTTP URIs so that people can look up those names.

3) When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL) 4) Include links to other URIs. so that they can discover more things.

B. The SEAS-eval Ontology

Time series are at the heart of most descriptions in and beyond the context of this work. Some ontologies have already been defined to represent quantities, such as QUDT 6 , or OM7 . Their differences have been described in the literature [START_REF] Rijgersberg | Ontology of units of measure and related concepts[END_REF]. In this work we reuse the QUDT ontology because it enables to lead dimensional analysis, but our work could be adapted to use the OM ontology instead.

In QUDT, a quantity is an instance of qudt:Quantity, has a certain quantity kind (e.g., qudt-quantity:Power), and is associated through property qudt:quantityValue to instances of qudt:QuantityValue, which comprise a double (e.g., "150"ˆˆxsd:double) and a unit (e.g., qudt-unit:Watt). The QUDT description does not enable the description of timevarying quantities. On the other hand, the ontology in [START_REF] Radulovic | Guidelines for Linked Data generation and publication: An example in building energy consumption[END_REF] does not enable the representation of aggregated quantities (e.g., "this consumption value is the sum of these consumption values").

Hence we identified a need for an ontology that enables to qualify the link between a quantity and its time-varying value, and aggregated quantities. In the context of the ITEA2 SEAS project (Semantic Energy Aware Systems), we developed such an ontology, named SEAS-eval. SEAS-eval enables to describe varying quantities, their composition, aggregation, and to reason with them. The full rationale of SEAS-eval and the thorough description of its concepts and semantics is out of the scope of this paper. Let us simply overview the main concepts of the SEAS-eval ontology that are important to understand how we represent the consumption data in the GECAD microgrid.

a) The namespace: First, let us define a namespace and its prefix for the SEAS-eval ontology: @prefix seas-eval: <http://purl.org/NET/seas/eval#> .

This ontology is actually published at its URL following the Linked Open Vocabularies best practices. Readers can browse its HTML documentation, and machines can access its formal definition in Turtle. The server chooses which representation of the ontology it should serve using Content Negociation 8 . b) Temporal entities and instants: A temporal entity is described as an instance of class seas-time:TemporalEntity, and is linked to:

• a start (property seas-time:start, range xsd:dateTime); • a duration (property seas-time:duration, range xsd:duration);

• an end (property seas-time:end, range xsd:dateTime). The semantics of the class seas-time:TemporalEntity is defined in a way that these three properties are coupled: given two values out of three, one may infer the third. The class of seas-time:Instant is equivalent to the class of seas-time:TemporalEntity that have a duration of exactly zero seconds, i.e., "PT0S"ˆˆxsd:duration 9 . c) Evaluations: As illustrated on Figure 3, an instance of seas-eval:Evaluation is used to describe the evaluation of quantities:

• that was generated at a certain time (property seas-eval:generatedAtTime, range xsd:dateTime); • that is valid over a given temporal context (property seas:temporalContext, range seas-time:TemporalEntity). It generalizes concepts of forecast, planning, (if the generation time is before the end of the temporal context), measures history, and observations (if the generation time is equal to the end of the temporal context). An evaluation may be composed of other evaluations (property seas-eval:composedOf) generated at the same time and with the same temporal context. For example one record of the analyzer is described as one evaluation, composed of multiple quantity evaluations, as described in paragraph e.

d) Instantaneous evaluations:

An instance of seas-eval:InstantaneousEvaluation is a seas-eval:Evaluation that is linked to a seas-time:Instant instance through the seas-eval:temporalContext.

Property seas-eval:time can then be used as a shortcut for the start and end of the 8 Content Negociation in HTTP -http://www.w3.org/Protocols/rfc2616/ rfc2616-sec12.html 9 See the definition of the xsd:duration data type -http://w3.org/TR/ xmlschema-2/#duration. temporal context. Hence a program may rely on the inference capabilities of a dedicated reasoner to infer all of the "implicit" knowledge about the temporal context of the evaluation.

e) Single quantity evaluations: A seas-eval:Evaluation is associated with values when and only when it qualifies a single quantity, and when and only when each of the evaluations it is composed of qualifies a single quantity with the same exact same dimension. The class of such evaluations is seas-eval:QuantityEvaluation, and is a sub class of seas-eval:Evaluation.

An instance of class seas-eval:QuantityEvaluation is associated to:

• A quantity with functional property seas-eval:quantity;

• The dimension of the quantity kind of this quantity through functional property seas-eval:dimension. A seas-eval:QuantityEvaluation associates multiple values to this quantity over the temporal context. The semantics of this association is provided by the following properties:

• seas-eval:averageValue describes the average value of the quantity over the given temporal interval. • seas-eval:minimalValue describes the minimal value of the quantity over the given temporal interval. • seas-eval:maximalValue describes the maximal value of the quantity over the given temporal interval. • seas-eval:sumValue describes the sum of the quantity over the given temporal context. The dimension of the unit used for the sum value is the time primitive of the seas-eval:dimension of the evaluation. These values and the temporal context of the evaluation are coupled by the semantics of the SEAS-eval ontology. For instance, the sum value could be computed from the average value and the duration of the temporal context. f) Evaluations and its sub-evaluations: A seas-eval:Evaluation may be decomposed on the temporal dimension in a closed set of evaluations of the same quantities with inner temporal contexts. Property seas-eval:subEvaluations is used to link an evaluation to the closed set of its sub-evaluations.

The semantics of the SEAS-eval ontology enables in some cases to infer the values of the evaluation, given the values of each of its sub-evaluations.

For example, Code 1 is a Turtle document that describes the active power of measure point 3 (i.e., electrical sockets in zone 1) at times 2015-10-01T10:00:00Z and 2015-10-01T11:00:20Z, and the sum value. As we shall see in the next section, this example is extracted from the actual publication of the consumption data at the URL given in the caption. g) Aggregated quantities: A closed set of quantity evaluations with equivalent temporal contexts and the same dimension may be aggregated in an evaluation of a new quantity with the same dimension. An example of such an aggregated quantity is the average power factor of the HVAC in all the zones of the building, or the sum of the active power of all the load types in a zone.

Property seas-eval:averageOf and seas-eval:sumOf link a seas-eval:QuantityEvaluation to a closed set (i.e., a rdfs:List of quantity evaluations). The semantics of the SEASeval ontology enables to infer the value of the aggregated quantity, given the values of each of its aggregating quantities.

C. Publication as Linked Data

This section describes how the consumption data is published as Linked Data on the data sub-domain of the ITEA2 SEAS project's website http://data.the-smart-energy.com.

One approach could have been to form a single RDF Graph from all of the data, and to publish it as a single Turtle document, potentially compressed. This approach is interesting because all the data would be in one single document, but it has two main drawbacks. First, the size of such a document would most likely be of a few GigaBytes. Second, consumption data is still acquired every 10 s. This approach may be used in subsequent work to publish dumps (e.g., yearly), but as a first step, we wanted a solution that integrates new data on the fly, so that the RDF dataset keeps growing and becoming more and more useful with time.

We hence chose to publish the data following the Linked Data principles, on what resembles to a RESTful web service that serves and consumes RDF. Actually, a recent W3C recommendation, named Linked Data Platform10 , defines a set of rules for HTTP operations on web resources, to provide an architecture for read-write Linked Data on the web. The server where we expose the consumption data is to undergo further development so that it conforms with the Linked Data Platform recommendation.

The endpoint of the web service is the following URL.

http://data.the-smart-energy.com/gecad/ Let us use this URL as a base URL in the rest of this section. Meaning that a relative URI such as <Analyzer/1/U1N> must be resolved against the base URI, and leads to: http://data.the-smart-energy.com/gecad/Analyzer/1/U1N h) Analyzer data: We chose to expose separately the data from the analyzers, and the data from the microgrid measure points. We further assumed that, if each analyzer could actually expose its measures as a RESTful web service, it would only expose its last measures. Relative URI template <Analyzer/{i}> simulates this, and identifies the latest measure of analyzer i. When operating a HTTP GET with the HTTP Header option Accept having value text/turtle, i.e., the Internet Media Type of the Turtle syntax, a HTTP client retrieves a RDF Turtle document. The RDF graph of this document has main topic a resource with URI <Analyzer/{i}#evaluation>, and lists the different evaluations this main evaluation is composed of.

As recommended by the 4 th Linked Data principles, the URIs of these evaluations are in the form <Analyzer/{i}/{name}#evaluation>, and when a client follows this link with a similar HTTP request, it retrieves another RDF Turtle document that specifically describes latest measure name of analyzer i. The values used for name are exactly those in the first column of table I.

For example, the following Turtle document describes the latest U1N value measured by Analyzer 3 (i.e., the document has been retrieved at URI <Analyzer/3/U1N#evaluation>)

1 @base <http://data.the-smart-energy.com/gecad/> . i) Measure points data: We simulate the fact that a Resource Manager somehow retrieves the data exposed by each of analyzer, stores it, and expose it along with previous measures at URIs that start by <Microgrid/1/MeasurePoint/{i}>, where i is the number of the measure point as described in Section II.

Currently, the server serves the following information. In all these template URIs, is the number of measure point between 1 and 12; name is one of: freq, i thd, u thd, i, u, pf, s, p, q, actener; and time must be a valid lexical form for the xsd:dateTime XML Schema 2 Datatype.

• <Microgrid/1/MeasurePoint/{i}/{name}/{time}>, exposes the measure of quantity name at time time and at measure point i;

• <Microgrid/1/MeasurePoint/{i}/{name}> takes as additional URL query parameters start and end, which must be valid lexical forms for the xsd:dateTime XML Schema 2 Datatype, and limit, which limits the number of individual evaluations. The RDF document exposed at this URI a summary of at most limit measures of quantity name and at measure point i, that have been taken between dates start and end. Furthermore, the minimum, maximum, average, and sum of the global evaluation is provided, regardless of its pertinence; • <Microgrid/1/MeasurePoint/{i}> takes again additional URL query parameters start, end, and limit. The RDF document exposed at this URI describes a summary of at most limit measures at measure point i, that have been taken between dates start and end.

For instance, a summary of the 360 first measures (equals 1 hour of measures) that were taken after 2015-10-10T12:00:00Z at measure point 11 (i.e, the consumption of ceiling lights in the kitchen) can be retrieved at the following URI (locally appending Microgrid/1 to the base declaration): <MeasurePoint/10?start=2015-10-10T12:00:00Z&limit=360> j) In practice: In practice, the Gateway Layer reads the values from the energy analyzers, and sends them to the Multi-Agent System Layer. The representative agent of building N then constructs a HTTP POST requests and pushes the new record of consumption data to the URI <Microgrid/1 of thesoon to become-Linked Data Platform. The Server then reads this new record, and adds a row in the dedicated database table.

Figure 4 illustrates the use of this API to report on the consumption of the electrical sockets in the kitchen (measure point 12). The relative URI used is <Microgrid/1/MeasurePoint/12>, with URL query parameters start=2015-09-15T11:30:00Z, end=2015-09-15T14:30:00Z, and limit=1080. One may identify the periodic consumption of the fridge and the microwave used during the lunch hour.

IV. Conclusion

This paper reported on the beginning of the transition of the GECAD microgrid demonstrator towards the adoption of open (Semantic) Web Formalisms, and Linked Data publication principles. This work was originally motivated by a need of enhancing the inter-operability of the different layers of the system architecture, and a wish of making the consumption data openly available, so that it may be used to test new services and algorithms for the microgrid management.

We reported on the development of the SEAS-eval ontology, that is specifically developed to represent evaluations of quantities, their aggregation, and their decomposition on the temporal dimension. We described the initial development stage of a RESTful Web Service to serve RDF documents in conformance with the Linked Data principles. And we illustrated how this service can be used to analyze the consumption in the microgrid.

This work validated our expectations for using the Semantic Web formalisms and the Linked Data principles to expose data from the microgrid. Hence in future work we want to augment this dataset with the other consumption, storage, and production data of the microgrid.

This first API serves the need for exposing all of the consumption data, no matter how many HTTP requests are needed. And this is the purpose of the work in this paper. Now, it is to be noted that the server under active development, and more functionalities are to be added before 2016: One last possible outcome of this work could be the organization of a challenge for other teams to use this data. Such a challenge could encourage participants to combine the already published knowledge with its acquisition context, and data from different information systems, and various topics (e.g., weather forecast, traffic information, day-ahead market prices).

Fig. 1 .

 1 Fig. 1. Microgrid system architecture.

Fig. 2 .

 2 Fig. 2. The stack of Semantic Web standards.

1

  qudt:unit rdf:type rdf:Property . 2 qudt:unit rdfs:domain qudt:QuantityValue . 3 qudt:unit rdfs:range qudt:Unit .

Fig. 3 .

 3 Fig. 3. Illustration of an evaluation.

17

 17

18 <Analyser/ 3 /

 3 U1N#quantity> qudt:quantityKind seas-quantity:Phase1ToNeutralVoltageRMSAmplitude .

•

  The new web services <Microgrid/1/HVAC/{name}>, <Microgrid/1/lights/{name}>, and <Microgrid/1/sockets/{name}>, to showcase the representation of aggregations, and to model common requests from the clients of the API; • The server currently shows memory limitations, and we shall change it and optimize the API and the database storage; • We will introduce a new parameter, granularity, which

Fig. 4 .

 4 Fig. 4. Three hours consumption (Three hour electrical socket consumption of the kitchen

  • Building I -this building daily hosts students and more than 12 researchers. It is composed of 1 classroom with a capacity slightly above 50 students, 1 server room, 3 office rooms, 2 meeting rooms, 2 bathrooms and 2 common areas. The consumption data of the building is acquired globally by a custom-made gateway that uses ZigBee. The acquisition period is 10 to 15 seconds, depending on the sleep cycle of the modules that are used;

• Building N -this building daily hosts more than 20 researchers. It is composed of 7 office rooms, 1 server room, 1 meeting room, 2 bathrooms, 1 kitchen and 2 common areas. The building allows the on/off control of the HVAC systems, with the exception of the server room due to security reasons. The building has it own photovoltaic generation with 20 panels and a total nominal generation power of 5 kW. The generated power is injected directly in the building grid. The consumption data and generation data is acquired every 10 seconds.

  Table I lists the measurement capabilities of each analyzer.

	Name	Unit	Description
	Freq	Hz	Grid frequency (measured in U1N)
	THD I1	%	Phase 1 Current, total harmonic distortion
	THD I2	%	Phase 2 Current, total harmonic distortion
	THD I3	%	Phase 3 Current, total harmonic distortion
	THD U1N %	Phase 1 to Neutral Voltage, total harmonic dist.
	U2N %	Phase 2 to Neutral Voltage, total harmonic dist.
	THD U3N %	Phase 3 to Neutral Voltage, total harmonic dist.
	THD U12	%	Phase 1 to 2 Voltage, total harmonic distortion
	THD U23	%	Phase 2 to 3 Voltage, total harmonic distortion
	THD U31	%	Phase 3 to 1 Voltage, total harmonic distortion
	I1	A	Phase 1 Current, RMS Amplitude
	I2	A	Phase 2 Current, RMS Amplitude
	I3	A	Phase 3 Current, RMS Amplitude
	PF1	-	Phase 1 Power Factor (+/-)
	PF2	-	Phase 2 Power Factor (+/-)
	PF3	-	Phase 3 Power Factor (+/-)
	S1	VA	Phase 1 Apparent Power
	S2	VA	Phase 2 Apparent Power
	S3	VA	Phase 3 Apparent Power
	P1	W	Phase 1 Active Power (+/-)
	P2	W	Phase 2 Active Power (+/-)
	P3	W	Phase 3 Active Power (+/-)
	Q1	var	Phase 1 Reactive Power (+/-)
	Q2	var	Phase 2 Reactive Power (+/-)
	Q3	var	Phase 3 Reactive Power (+/-)
	U1N	V	Phase 1 to Neutral Voltage, RMS Amplitude
	U2N	V	Phase 2 to Neutral Voltage, RMS Amplitude
	U3N	V	Phase 3 to Neutral Voltage, RMS Amplitude
	U12	V	Phase 1 to Phase 2 Voltage, RMS Amplitude
	U23	V	Phase 2 to Phase 3 Voltage, RMS Amplitude
	U31	V	Phase 3 to Phase 1 Voltage, RMS Amplitude
	IN	A	Neutral Current, RMS Amplitude
	ActEner1	Wh/10 Phase 1 imported active energy
	ActEner2	Wh/10 Phase 2 imported active energy
	ActEner3	Wh/10 Phase 3 imported active energy
			TABLE I
			Reading values of one analyzer.

RDF -Resource Description Format -http://w3.org/TR/rdf11-concepts/

QUDT -Quantities, Units, Dimensions, and Data Types Ontologies -http: //qudt.org/

Turtle -Terse RDF Triple Language -http://w3.org/TR/turtle/

RDFS -RDF Schema -http://w3.org/TR/rdf-schema/

OWL -Web Ontology Language -http://w3.org/TR/owl2-overview/

QUDT -Quantities, Units, Dimensions, and Data Types Ontologies -http: //qudt.org/

OM -Ontology of units of Measure -http://wurvoc.org/vocabularies/om-1.

8/

Linked Data Platform -http://w3.org/TR/ldp/

Acknowledgment

This work has been partially funded by the ITEA2 12004 SEAS (Semantic Energy Aware Systems) project -http:// the-smart-energy.com.