DR (Demand Response) programs have a big potential in the residential sector to reduce peak energy demands. However, the poor user-engagement is one of the main barriers of their adoption and success. The RESPOND H2020 project aims to bring DR programs to neighbourhoods across Europe and in this article, focus is placed on the approach implemented to solve the challenging integration of building topological data and data produced by IoT systems within houses including sensors, meters and actuators. In this regard, RESPOND leverages Semantic Technologies to represent building data, while it uses Time Series Databases (TSDB) to store IoT data. The combination of these technologies is expected to enhance the data querying, which is of utmost importance for its display in the RESPOND mobile app.
Peak energy demand has a negative impact on many aspects including energy
grid capital, operational cost and environmental pollution. This is a direct
consequence of the carbon-intense generation plants that grid operators deploy in
order to satisfy energy demand during peak periods [
DR programs traditionally had a bigger presence on the industrial sector
compared to residential or commercial sectors, considering that buildings such
as industrial plants are extensive energy consumers [
Renewable Energy Sources (RES) are increasingly penetrating the energy production side, and in combination with DR programs and improvement in energy storage options, could contribute to signi cantly reduce peak demands. However, the integration of the di erent systems and technologies involved in the distributed energy consumption and generation is a big challenge. Moreover, due to the intermittent nature of RES, their availability commonly does not match the distribution of energy demand in time, which may hinder their management and exploitation.
Being able to accurately predict the amount of energy to be produced over a period of time, and knowing in advance when demand peaks will occur, can de nitely contribute to a better management of their disparity, thus allowing the suggestion of the most suitable DR programs to end-users. Likewise, this helps improving end-users' engagement, which is the key to the success of DR programs. However, the successful implementation of DR programs in the residential sector is a problematic scenario with yet many unsolved challenges. The RESPOND H2020 project aims to bring DR programs to neighbourhoods across Europe and in special, delve into the adaptation of energy demand to the renewable energy produced locally. In this article, focus is placed on RESPOND's approach towards the integration of building topological data and data produced by IoT systems including sensors, meters and actuators.
The rest of the article is structured as follows. Section 2 introduces the RESPOND project. Section 3 presents RESPOND's approach to integrate building data with IoT data. Section 4 describes the semantic representation of the pilot sites. Finally, the conclusions of this work are presented in Section 5. 2
The RESPOND (integrated demand REsponse Solution towards energy POsitive NeighbourhooDs) project2 funded by EU's H2020 program3, aims to deploy and demonstrate an interoperable, cost e ective, user centred solution, entailing energy automation, control and monitoring tools, for a seamless integration of cooperative DR programs into the legacy energy management systems. In this endeavour, RESPOND will be leveraged upon an integrated approach for realtime optimal energy dispatching, taking into account both supply and demand side, while exploiting all energy assets available at the site. 1 http://ec.europa.eu/eurostat/statistics-explained/index.php/Energy_ consumption_in_households 2 http://project-respond.eu 3 https://cordis.europa.eu/project/rcn/212867_en.html
The RESPOND solution being developed is foreseen to be exible and scalable, thus being capable of delivering a cooperative DR both at building and district levels. Furthermore, in order to enable the integration of the DR enabling elements and ensure a high replicability, RESPOND is based on open standards. Likewise, the use of these open standards enables the interoperability with smart home devices and automation systems, as well as the connectivity and extendibility towards smart grid and third-party services such as weather forecasting services and energy price providers.
Underpinned by the smart energy monitoring infrastructure, RESPOND will leverage data coming from heterogeneous sources to perform various data analytics tasks. On the one hand, sensing, metering and actuating devices deployed in pilot houses will be exploited to develop energy demand forecasting services and ensure dwellers' comfort levels. On the other, the monitoring and forecasting of outdoor conditions will enable the estimation of renewable energy production. Ultimately, the overall objective of all these data analytic tasks is to detect potential energy conservation opportunities, and to adapt in real time to the operational environment.
With the purpose of demonstrating the RESPOND solution, it is being implemented in di erent types of residential buildings (i.e. apartments, single-family and multi-family houses), situated in di erent climate zones (i.e. Mediterranean, oceanic and humid continental climate), having di erent forms of ownership (i.e. rental and home-ownership), population densities and underlying energy systems. Namely, the three RESPOND pilot sites are located in Aarhus (Denmark), the Aran Islands (Ireland) and Madrid (Spain).
Having such a heterogeneous group of end-users hinders the di usion and impact of DR solutions, and it makes more di cult to ensure sustained user engagement with DR programs. This is why, interaction with end-users is recognized as a key point in the RESPOND project. Consequently, a set of tools and services are planned to deliver measurement driven suggestions to end-users for energy demand reduction and in uence their behaviour making them an active indispensable part of DR loop. One of these tools is a multilingual and crossplatform mobile app which is expected to contribute in the user-engagement matter. One of the app's functionalities includes the display of house information, the deployed IoT devices and their measurements (e.g. a dishwasher's energy consumption or the kitchen temperature). The display of this information requires from a previous integration of building topology and IoT data, which is this article's focal point. Furthermore, this data integration enables many data analytic tasks such as energy demand and user comfort forecasting. 3
Energy consumption is an outcome of performing everyday practices like
showering, cooking and laundering. Usually people do not recognize energy consumption
as an activity in itself, and they often nd it di cult to establish the link between
daily practices and the corresponding energy consumption [
The mobile app relies on the available data to display relevant information to the dwellers. This data includes, on the one hand, the topological information of a house which gives insight of its distribution, the appliances installed, and the di erent monitoring and actuating devices deployed in the house. And on the other, the measurements registered by these IoT devices including an appliance's energy consumption, a room's humidity or a window's state (i.e. opened or closed).
The advent of BIM (Building Information Model) supports the representation
of the former data source, that is, building information. BIM is a process used
by di erent stakeholders involved in the construction process of a building, and
deals with the digital representation of functional and physical characteristics of
a building [
Even with the development of BIM, the current practice of architectural
design and construction still relies on conventional document-centric approaches [
With regards to the IoT devices, they generate time series data which
commonly consists of at least 2 parts: time and value. Despite this simple structure,
IoT data is characterized by its abundance and it is estimated that in 2019 the
IoT will generate more than 500 zettabytes in data [
Summarizing, the RESPOND mobile app will leverage building information data and IoT data. The former data will be stored in an RDF Store and the latter in a TSDB towards an optimal data management and querying performance. 3.1
In order to implement the presented approach, rst of all each pilot site's
characterization was performed. This task was undertaken by the RESPOND
partners in charge of these pilot sites, who had no previous knowledge of
Semantic Technologies. Therefore, an intermediate step was found necessary prior to
representing building information with appropriate ontological terms. Previous
experiences of RESPOND partners [
An Excel le was created for every pilot site, and in each of them, meters, sensors and actuators deployed in pilot houses were represented with the following information: { Identi er of the device. { Gateway to which the device is connected to send gathered data. { Location of the device in terms of building, house and room. { Location of the device within the room (e.g. oor or east wall). { Type of device (e.g. humidity sensor or smart plug actuator). { For actuators, the type of appliance controlled, its brand and model. { The label and URI of the quality measured or controlled by the device (e.g.
temperature or energy consumption). { Query to retrieve data gathered by the device stored in the TSDB. Once pilot houses are characterized, this information needs to be semantically annotated using appropriate ontology terms. For this purpose, the RESPOND ontology was used, which is available online in https://w3id.org/respond.
Ontologies must be carefully designed and implemented, as these tasks have
a direct impact on their nal quality. Therefore, the use of well-founded ontology
development methodologies is advised. For the development of the RESPOND
ontology, the NeOn Methodology [
The reuse of ontological resources built by others that have already reached
some degree of consensus is a good practice in ontology development processes [
Following these best practices, the RESPOND ontology's core is built by reusing and extending three well-known ontologies: BOT to represent the dwelling topology, and SAREF and SEAS Feature Of Interest ontologies to represent devices, features of interest and qualities monitored and controlled by sensors and smart appliances. The selection of these ontologies was based on a study of related ontologies, which is out of the scope of this article.
BOT. The Building Topology Ontology4 [
BOT describes sites comprising buildings, composed of storeys which have spaces that can contain and be bounded by building elements. Sites, buildings, storeys and spaces are all non-physical objects de ning a spatial zone. These basic concepts and properties make the schema no more complex than necessary and this design makes the ontology a baseline extensible with concepts and properties from more domain speci c ontologies. Therefore, BOT serves as an ontology to be shared. As a matter of fact, BOT is aligned with other related domain ontologies including ifcOWL, which provides an OWL representation of the EXPRESS schemas of the open standard IFC (Industry Foundation Classes) developed by buildingSMART5.
SAREF. The Smart Appliances REFerence (SAREF) ontology6 [
The modular conception of the ontology allows the de nition of any new device based on building blocks describing functions that devices perform. As previously stated, for the building-related concepts SAREF provides the link to the FIEMSER data model. Furthermore, SAREF can be specialized to re ne the general semantics captured in the ontology and create new concepts. The only requirement is that any extension/specialization may comply with SAREF.
One of these specializations is the SAREF4ENER ontology7, which focuses on the energy domain. However, at the moment of writing this article, this ontology was inconsistent.
SEAS Feature of Interest. The SEAS Ontology8 [
On top of these core modules, several vertical SEAS ontology modules are de ned, which are dependent of a speci c domain. Moreover, the SEAS ontology o ers a set of alignments to ontologies like SOSA/SSN and QUDT.
The RESPOND ontology reuses BOT, SAREF and SEAS Feature of Interest ontologies. Furthermore, some terms from QUDT UNIT ontology13 are reused to 6 http://ontology.tno.nl/saref 7 https://w3id.org/saref4ener 8 https://w3id.org/seas/ 9 https://portal.etsi.org/STF/STFs/STFHomePages/STF556 10 https://w3id.org/seas/FeatureOfInterestOntology 11 https://w3id.org/seas/EvaluationOntology 12 https://w3id.org/seas/SystemOntology 13 http://qudt.org/1.1/vocab/unit represent units of measurements (e.g. unit:DegreeCelsius ) and other terms from M3-Lite taxonomy14 to represent qualities observed or controlled by installed devices (e.g. m3-lite:Humidity ). However, there are other RESPOND requirements that remain unsolved and a set of new axioms had to be de ned to satisfy them by extending these reused ontologies.
On the one hand, the list of appliances de ned by SAREF was extended to represent new ones including air conditioner (respond:AirConditioner ) and tumble dryers (respond:TumbleDryer ). Furthermore, the list of qualities provided and the list of units of measurements provided by M3-lite and QUDT Unit respectively were not su cient to represent all the use cases within the RESPOND pilots. Therefore, these ontologies were extended with the de nition of new qualities such as gas consumption (respond:GasConsumption) and new units of measurements such as parts per million (ppm) (respond:ppm ).
On the other, there are requirements that are intrinsic to the RESPOND project and which existing ontologies do not satisfy. In the context of the project, it is essential to know which is the gateway to which each device is connected in order to send their measurements or control actions. This relationship is represented with the de nition of the respond:connectsToInternetThrough object property and a new class respond:Gateway as a subclass of saref:Device. Furthermore, it is necessary to know how to query data gathered by a given device which is stored in a TSDB. This information can be represented leveraging respond:hasDBQuery data property, and its subproperty respond:hasIn uxDBQuery for In uxDB TSDB. As for assigning the icons to be shown in the mobile app, the respond:hasIcon data property relates a resource with its corresponding icon. Regarding the representation of space features such as the volume or area, a set of data properties (e.g. respond:hasNetVolume) has been de ned inspired by the IFC4 speci cation. The representation of these data properties is expected to be addressed by the W3C LBD (Linked Building Data) Community Group's15 future PROPS ontology16.
Figure 2 shows the RESPOND ontology's main classes and properties. 4
With regards to the semantic representation of pilot sites, an application based on Apache Jena17 was developed. Apache Jena is a free and open source Java framework for building Semantic Web and Linked Data applications. The developed Jena service extracts the information contained in the Excel sheets, semantically annotates it with appropriate ontology terms, and stores it into an RDF Store where it will remain accessible via SPARQL queries. Firstly, this information was stored in a Stardog18 version 6.0.1 repository, but due to the 14 http://purl.org/iot/vocab/m3-lite 15 https://www.w3.org/community/lbd/ 16 https://github.com/w3c-lbd-cg/props 17 https://jena.apache.org/ 18 https://www.stardog.com/ cease of its Community version after 31 March 2019, this information is now stored in an Openlink Virtuoso Server19 version 07.20.3217. Figure 3 depicts the representation of a Smart Plug developed by Develco Products20 and deployed to measure the electric consumption and control the activation and deactivation of a dishwasher installed in the kitchen of a pilot house in Denmark.
Both practice and research suggests the use of a graph-based format to capture
building data, nevertheless keeping numeric data explicitly out of the semantic
graph for computational performance reasons [
In order to hurdle the inherent di usion and impact problems of DR solutions in heterogeneous group of end-users, the RESPOND project plans to develop a set of tools and services. These ones are expected to deliver measurement driven suggestions to end-users for energy demand reduction and in uence their behaviour making them an indispensable active part of DR loop.
One of these tools is a mobile app developed both for iOS and Android and available in three languages to ease interaction with end-users from the pilot sites: in English, Danish and Spanish. The mobile app will o er di erent functionalities that require from an integration of building topology and IoT data, which has been tackled in previous sections of this article.
One of the app's functionalities displays users the list of devices installed within their houses, as shown in Figure 4. The display of this information is based on a SPARQL query executed over the RDF Store that contains the building topological information. Namely, the SPARQL query executed for this purpose is shown in Listing 1.1, where the wild card $HOUSE ID is replaced by the corresponding user's house ID.
PREFIX dc : < http :// purl . org / dc / terms / > PREFIX bot : < https :// w3id . org / bot # > SELECT DISTINCT ? deviceID WHERE { ? space dc : i d e n t i f i e r $H OU SE _I D ;
bot : hasSpace */ bot : h a s E l e m e n t ? deviceID . Listing 1.1. SPARQL query to retrieve all the sensors and actuators deployed within a house.
Users can also check data collected by deployed meters, sensors or actuators deployed in their houses. For example, Figure 5 displays the electric consumption of a Spanish pilot house in real-time shown by the RESPOND mobile app. The electric consumption of a house, which is gathered by an electricity meter, is stored in In uxDB. However, in order to query this information, it is necessary to know how to get the values of the electricity meter at hand. To do so, the SPARQL query shown in Listing 1.2 is executed, where the wild card $HOUSE ID is replaced by the corresponding user's house ID.
PREFIX respond : <https :// w3id . org / def / respond #> PREFIX seas : <https :// w3id . org / seas #> PREFIX dc: <http :// purl . org /dc/ terms /> PREFIX saref : <https :// w3id . org / saref #>
WHERE { ? device saref : measuresProperty ? property ; dc: identifier ? deviceID . ? property rdf : type respond : ElectricConsumption ; seas : isPropertyOf ? foi ; respond:hasDBQuery ?dbQuery.
? foi dc: identifier $HOUSE_ID . }
Listing 1.2. SPARQL query to retrieve the TSDB query retrieving a house’s electricity consumption.
DR programs in residential buildings have a big potential in terms of maximizing the exploitation of locally produced renewable energy. Likewise, the exploitation of this type of energy paves the way for reducing peak energy demands. However, DR programs' success in this sector is scarce mainly due to user's lack of engagement. The RESPOND mobile app is developed as a way to increase user-engagement with DR programs.
This mobile app leverages both building and IoT data, which are two disparate data sources that need to be carefully managed. In order to avoid a problematic document-centric approach, RESPOND proposes the use of Semantic Technologies to represent building data. More speci cally, building topological data is represented using appropriate ontological terms coming from well-known ontologies, and it is stored in a Virtuoso RDF Store. With regards to the abundant IoT data, RESPOND leverages the In uxDB TSDB with the objective of obtaining an enhanced performance. Finally, the proposed approach is aimed at easing the scalability of the approach, as it enables the distribution of the data according to speci c needs. 5.1
So far, the RDF Store used in RESPOND hosts the topological information of a limited number of test houses. Whether it could a ord storing information for thousands of houses while ensuring a high querying e ciency, still remains an open issue. This aspect deserves further research in future stages of RESPOND.
Furthermore, at the moment of writing this article, all RESPOND mobile app's functionalities are not developed. The personalized DR suggestion to users or the ability to activate or deactivate appliances are just some of the services that are being developed and are expected to further increase the userengagement with DR programs.
Last but not least, the research of integrating IoT data with data sources containing more complex building information (e.g. BIM models) is of interest.
This work has received support from H2020 project RESPOND (integrated demand REsponse Solution towards energy POsitive NeighbourhooDs) with grant agreement number 768619.
This work was conducted using the Protege resource, which is supported by grant GM10331601 from the National Institute of General Medical Sciences of the United States National Institutes of Health.