Integrating Real-Intelligence in Energy Management Systems …holisder.eu › reports ›...

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 768614

Integrating Real-Intelligence in Energy Management Systems enabling Holistic Demand Response Optimization

in Buildings and Districts

Copyright © 2018 HOLISDER Project

D4.2 HOLISDER Common Information Model

Version number: 1.0

Dissemination Level: PU Lead Partner: TECNALIA

Due date: 31/07/2018 Type of deliverable: Report

STATUS: Submitted

Ref. Ares(2018)3986364 - 27/07/2018

D4.2 – HOLISDER Common Information Model

2

Published in the framework of:

HOLISDER - Integrating Real-Intelligence in Energy Management Systems enabling Holistic Demand Response Optimization in Buildings and Districts

HOLISDER website: www.holisder.eu

Authors:

Sarah Noyé and Miguel Angel Anton – TECNALIA

Petr Stluka and Jakub Malanik – HONEYWELL

Dimosthenis Tsagkrasoulis – HYPERTECH

M.J. (Mente) Konsman – TNO

Germán Martínez – ETRA

Keko Hrvoje – KONCAR

Revision and history chart:

VERSION DATE EDITOR COMMENT

1.0 27/07/2018 TECNALIA Submitted to the EC

Disclaimer:

This document reflects only the author’s views and neither the Agency nor the Commission are responsible for any use that may be made of the information contained therein.


3

Table of content

1 Executive summary ............................................................................... 8

2 Introduction ......................................................................................... 9

Purpose of the Document ..................................................................... 9

Scope of the Document ........................................................................ 9

Structure of the Document ................................................................. 10

3 Common Information Model Context ..................................................... 11

Overview of HOLISDER Data Exchange Framework ................................ 11

CIM and Data Services ....................................................................... 13

Message Oriented Middleware ............................................................. 16

3.3.1 Purpose of the Middleware .......................................................... 16

3.3.2 Middleware platform ................................................................... 16

3.3.3 Enterprise Service Bus ................................................................ 17

3.3.4 Data Services Server .................................................................. 23

3.3.5 Cassandra NoSQL database ......................................................... 26

4 HOLISDER components of the Data Exchange Framework ........................ 29

Interoperability and Secure Data Management Layer ............................. 29

4.1.1 Energy Management System ....................................................... 29

4.1.2 Observational Framework............................................................ 31

4.1.3 Gateway ................................................................................... 32

4.1.4 JACE Controller .......................................................................... 35

4.1.5 Proprietary Field Area Equipment and Smart Devices/Sensors ......... 37

Local Demand Manager for Implicit Demand Response ........................... 40

4.2.1 Virtual Thermal Energy Storage Module ........................................ 40

4.2.2 Demand Flexibility Profiling Engine Module .................................... 43

4.2.3 Lighting/HVAC System Energy Manager ........................................ 48

4.2.4 Building Monitoring and Control Dispatch Module ........................... 50

Global Demand Manager for Explicit Demand Response ......................... 52

4.3.1 Energy Tariff Emulator Module ..................................................... 52

4.3.2 Flexibility Forecasting, Segmentation and Aggregation Module ......... 56

4.3.3 Portfolio Monitoring and Control Dispatch Module ........................... 60

Building Visualization and User Toolkit ................................................. 64


4

4.4.1 Predictive Maintenance Advisor Module ......................................... 64

4.4.2 Consumer Visualization and Engagement Platform ......................... 67

District Visualization and User Toolkit .................................................. 69

4.5.1 Aggregator Application Module ..................................................... 69

4.5.2 Energy Supplier/Retailer Application Module .................................. 71

External Data Sources Layer ............................................................... 72

4.6.1 Wholesale Energy Market Data .................................................... 72

4.6.2 Weather Monitoring and Forecasting Data ..................................... 74

4.6.3 Energy Distribution System Operator Data .................................... 76

5 Extensions to standard OpenADR 2.0b ................................................... 77

The current state of the OpenADR 2.0 standard .................................... 77

Mapping of OpenADR to CIM – CIM Extensions for OpenADR .................. 79

Implementation of extensions to the OpenADR standard ........................ 82

6 Conclusions ........................................................................................ 85


5

List of tables

Table 1. List of available ESB APIs. ............................................................. 22

Table 2. List of available DSS APIs. ............................................................ 25

Table 3. Structure of "bmsrawdata" table. ................................................... 27

Table 4. Structure of "lastprocessedtimestamp" table. .................................. 28

List of figures

Figure 1. HOLISDER Data Exchange Framework Conceptual Architecture ......... 12

Figure 2. Module-to-module interactions vs. Common API approach ............... 14

Figure 3. Module interaction with the Data Services Server ............................ 15

Figure 4. Data exchange procedure ............................................................ 15

Figure 5. Component based architecture of ESB ........................................... 18

Figure 6. Messaging based architecture of ESB ............................................. 18

Figure 7. Deployed APIs tab in WSO2 ESB GUI ............................................. 20

Figure 8. HOLISDER API resource sequence in Eclipse Developer studio .......... 21

Figure 9. Detailed view of the JSONSequence used in InputDataAPI ............... 21

Figure 10. Detailed view of JSONtoXML datamapper used in JSONSequence .... 22

Figure 11. Overview of the WSO2 Data Services Server architecture ............... 24

Figure 12. Simple illustration of a Cassandra cluster. .................................... 27

Figure 13. OneM2M Functional Architecture (taken from TS-0001-Functional_Architecture-V3_11_0.docx) ...................................................... 33

Figure 14. Example use case (taken from http://www.onem2m.org/application-developer-guide/architecture) .................................................................... 34

Figure 15. OpenADR communication architecture ......................................... 78

Figure 16. Example DR interactions in the OpenADR architecture ................... 78

Figure 17. The OpenADR profiles ................................................................ 79

Figure 18. Graphical XSLT mapping between CIM ResourceDeployment sample message based on IEC 62325-301:2018 and IEC 62746-10-1 EiEvent ............ 81


6

Glossary

Acronym Full name

AMI Amazon Machine Image

AMQP Advanced Message Queuing Protocol

API Application Programming Interface

AWS Amazon Web Services

BEMS Building Energy Management System

BMCD Building Monitoring and Control Dispatch

BMS Building Management System

BPMN Business Process Model and Notation

CAPP Carbon Application Package

CIM Common Information Model

CQL Cassandra Query Language

CSV Comma-Separated Values

DB Database

DER Distributed Energy Resources

DFPE Demand Flexibility Profiling Engine

DOA Description Of the Action

DR Demand Response

DSO Distribution System Operator

DSS Data Services Server

EC2 Elastic Compute Cloud

EDSO Energy Distribution System Operator

EFI Energy Flexibility Interface

EIP Enterprise Integrator Pattern

EM Energy Manager

EMS Energy Management System

ESB Enterprise Service Bus

ETE Energy Tariff Emulator

EP End-Point

FFSA Flexibility Forecasting, Segmentation and Aggregation

HEMS Home Energy Management System

HTTP Hypertext Transfer Protocol


7

HTTPS Hypertext Transfer Protocol Secure

HVAC Heating, Ventilation, and Air-Conditioning

IEC International Electrotechnical Commission

IoT

IT

Internet of Things

Information Technology

JACE Java Application Control Engine

JSON JavaScript Object Notation

M2M Machine-to-Machine

MQTT Message Queuing Telemetry Transport

MW Middleware

OBF Observational Framework

OpenADR Open Automated Demand Response

PMA Predictive Maintenance Advisor

PMCD Portfolio Monitoring and Control Dispatch

REST Representational State Transfer

RM Resource Manager

SAREF Smart Appliances REFerence

SGUI Smart Grid User Interface

SOA Service Oriented Architecture

SOAP Simple Object Access Protocol

SQL Structured Query Language

TC Technical Committee

URL Uniform Resource Locator

USEF Universal Smart Energy Framework

VEN Virtual End Node

VTES Virtual Thermal Energy Storage

VTN Virtual Top Node

WEM Wholesale Energy Market

WMF Weather Monitoring and Forecasting

XML eXtensible Markup Language

XSLT eXtensible Stylesheet Language Transformations


8

1 Executive summary

The HOLISDER project introduces a Holistic Demand Response Optimisation Framework that enables significant energy costs reduction at the building/ consumer side, while introducing small and medium sized buildings (residential and non-residential ones) as a major contributor to energy networks’ stability through optimized energy management in response to network constraints and conditions.

This document is the outcome of the task “T4.2 Common Information Model Adaptation for ensuring semantic interoperability (M4-10)”, framed under “WP4 – End-to-end Interoperability and Data Management Platform (M1-22)”. The goal of this document is the definition of the HOLISDER Common Information Model (CIM), which will semantically and syntactically model all the necessary information needed for the development, installation, deployment and operation of the system.

The CIM is structured to comply with existing and ongoing standardization efforts (OneM2M, SAREF, USEF, OpenADR, IEC-61850…) in order to enable seamless adoption and uptake in the EU energy market. Special attention is paid in incorporating in the CIM appropriate OpenADR extensions, to address semantics for more energy carriers than only electricity, namely gas and district heating, as well as new semantics about human comfort profiles and demand elasticity.

The CIM model establishes the basis upon which the HOLISDER Interoperable Platform and Data Management Framework (Task T4.3) will be developed. The CIM model is based on the research carried out in the project on Open Standards and Interoperability (Task T4.1) and is constructed in parallel and in concordance with the HOLISDER Conceptual Architecture, Functional and Technical Specifications, Communication interfaces and Protocols definition (Task T2.4). The extensions to existing standards, mainly OpenADR, will also be refined (Task T6.6) into a punch-list to be promoted to standardization bodies, committees and working groups (Task T7.4).


9

2 Introduction

The HOLISDER project aims to introduce demand-side flexibility into energy markets. One key enabler is the establishment of end-to-end interoperability between all platforms and devices addressing the needs of the whole demand response value chain through enabling two-way communication, plug-and-play installation and data exchange and integration across brands and protocols. Compliance with open standards is required to ensure end-to-end semantic and technical interoperability, while enabling integration of Demand Response Management Systems, with Building Energy Management Systems (BEMS) and Smart Home components and facilitating communication between the different actors involved in the energy market.

Purpose of the Document

While the overall HOLISDER communication architecture is reported in D2.4, this deliverable reports the HOLISDER Common Information Model (CIM). A Common Information Model is a representation of concepts, relationships, constraints, rules, and operations to specify data semantics. The HOLISDER Common Information Model provides the semantic interoperability for data exchange among the different system components of HOLISDER framework. The HOLISDER framework will be validated in 4 large-scale demonstrators/pilot sites, located in Greece, UK, Finland and Serbia, incorporating diverse building types, heterogeneous home, building and district EMS and devices, a variety of energy carriers and spanning diverse climatic conditions, demographics and cultures.

Scope of the Document

This deliverable presents the results of the task “T4.2 Common Information Model Adaptation for ensuring semantic interoperability (M4-10)”. The HOLISDER Common Information Model provides the HOLISDER framework with data semantic interoperability between the different components in a modular manner and in compliance with EU-wide standardization activities.

In the HOLISDER CIM, the existing data models reported in the previous deliverable “D4.1 Analysis of EU-wide interoperability standards and data models and harmonization requirements” are integrated, harmonized and reused to ensure compliance with legacy equipment and processes.

The CIM is structured to comply with existing and ongoing standardization efforts (OneM2M, SAREF, USEF, OpenADR, IEC-61850…). Besides, extensions to OpenADR 2.0b are defined to incorporate gas and district heating carriers to the


10

standard in addition to electricity. OpenADR 2.0b is also enriched with semantics related to human comfort profiles and demand elasticity.

Although this report is delivered according to the DOA in Month 10, the HOLISDER Common Information Model will follow an iterative process until the middleware and the components are integrated into the pilots. Consequently, this deliverable can be considered as a working document that will guide and track the data interoperability of the different components that comprise the HOLISDER framework.

Structure of the Document

The deliverable is structured and organized in the following chapters:

• Chapter 2 is the introduction of this document, outlining the purpose and the scope of the report.

• Chapter 3 presents the Common Information Model context, including an overview of HOLISDER framework, the Data Services philosophy and the Message Oriented Middleware.

• Chapter 4 presents the HOLISDER components that exchange information using the Common Information Model.

• Chapter 5 describes the extensions to standard OpenADR 2.0b to address semantics for gas and district heating carriers, human comfort profiles and demand elasticity.

• Finally, in Chapter 6 conclusions are drawn for this report, focusing on the interconnection of T4.2 with the upcoming work in the project.


11

3 Common Information Model Context

The next subchapters explain the ideas behind the Common Information Model (CIM) and the data exchange process around the HOLISDER semantic and syntactic model. In addition, a contextualization of the Common Information Model within the whole HOLISDER platform, data services and Message Oriented Middleware, is presented based the HOLISDER business scenarios and use cases shown in “D2.1 End-user & business requirements”.

Overview of HOLISDER Data Exchange Framework

The Data Exchange Framework between all actors involved in the HOLISDER project and pilots span several interrelated areas:

• Physical systems: Buildings and districts along with their energy measurement and control equipment, communications interfaces and energy networks.

• Stakeholders: Dwelling occupants and their behaviour in energy consumption and the flexibility they can offer, facility managers, aggregators, energy suppliers/retailers and maintenance companies.

• Energy markets: Wholesale energy tariffs and its translation to retail tariffs for optimization of demand response strategies.

• Surrounding environment: Weather fluctuations and its impact in the amount of energy generated by renewable sources.


12

Figure 1. HOLISDER Data Exchange Framework Conceptual Architecture

Figure 1 shows the updated conceptual architecture of the HOLISDER Data Exchange Framework, as was developed in Task T2.4 and documented in D2.5 “HOLISDER Framework Architecture including functional, technical and communication specifications”. It contains high level functional constituents that can be split at different deployment levels to address all components that exchange information using the Common Information Model defined in this deliverable.

The HOLISDER interoperable components that compose the Data Exchange Framework are clustered in the following groups:

• Interoperability and Secure Data Management Layer

o Smart Home Energy Management System (EMS) � Observational Framework (OBF) by TNO � Gateway

� Proprietary Field Area Equipment and Smart Devices and

Sensors

o Building Energy Management System (EMS) � JACE Controller by HONEYWELL � Proprietary Field Area Equipment and Smart Devices and

Sensors


13

o District DER Energy Management System (EMS) � JACE Controller by HONEYWELL � Proprietary Field Area Equipment and Smart Devices and

Sensors

• Holistic Demand Response Optimisation and Control Dispatch DSS Layer

o Local Demand Manager for Implicit Demand Response (Building level) � Virtual Thermal Energy Storage Module

� Demand Flexibility Profiling Engine Module

� HVAC/Lighting Energy Resource Managers

� Building Monitoring and Control Dispatch Module

o Global Demand Manager for Explicit Demand Response (District level) � Energy Tariff Emulator Module

� Flexibility Forecasting, Segmentation and Aggregation

� Portfolio Monitoring and Control Dispatch

• Visualization Platform and End-User Toolkit Layer

o Building Visualization and User Toolkit � Consumer Visualization and Engagement Platform for

Dwelling Occupants � Predictive Maintenance Advisor Module for Facility

Managers

o District Visualization and User Toolkit � Aggregator Application Module

� Energy Supplier/Retailer Application Module

• External Data Sources Layer

o Wholesale Energy Market Data

o Weather Forecasting Data

o Energy Distribution System Operator Data (DSO Data)

CIM and Data Services

The idea behind the Common Information Model (CIM) and the associated Data Exchange Framework is to replace module-to-module interactions by a common model and a common API approach. The Data Exchange Framework will provide a single data access point for all the components as seen in Figure 2.


14

Figure 2. Module-to-module interactions vs. Common API approach

Thus, the integration pattern of the Data Exchange Framework within the service orchestration supported by the Message Oriented Middleware provides two communication possibilities as depictured in Figure 3. Option 1 entails the provision of data by the Data Services Server (DSS) to the components through direct End-Point (EP) calls. Another option is to consider the Data Services Server as a component and orchestrate the composition of services through an Enterprise Service Bus (ESB). This implies that the provision of data is handled by the Enterprise Service Bus.

Module 1

Common Data Model

Module 4

Module 2

Module 3

Module 1

Module 4

Module 2

Module 3

Direct module-2-module exchanges

Open API

Open API


15

Figure 3. Module interaction with the Data Services Server

The data exchange process between modules and the service bus entails the next steps developed in parallel with the architecture design and functional specifications (Task T2.4):

1. Identify input data requirements for each module/component. 2. Identify which module or external source produces the data as seen in

Figure 4.

Figure 4. Data exchange procedure

3. As an important assumption, it is considered that the data internally handled by a specific component is not part of the Common Data Model.

Module 1 Module 2Requires

External source

Produces


16

Message Oriented Middleware

The HOLISDER Message Oriented Middleware is based on and will be an extended version of a middleware platform designed for project H2020-MOEEBIUS. Main areas of the extension are standards-based communication and improved message routing capabilities.

The HOLISDER Middleware will consist in an open platform and application software framework that will establish seamless, transparent and homogeneous standards-based (OpenADR 2.0b, USEF) interfaces to all integrated HOLISDER components. Information exchange over the ESB will comply with the HOLISDER Common Information Model (CIM) to enforce semantic and syntactic interoperability across the system.

3.3.1 Purpose of the Middleware

The Middleware will facilitate routing of the messages between individual modules. To allow dynamic routing, the routing sequence inside the ESB maintains a mapping between modules and their respective HTTP addresses. Based on the message destination, it will be possible to transform the contents of the message if needed. Routed messages can also be logged for debugging purposes.

The Middleware also serves as a central data storage platform. It is possible to store data via HTTP POST request or an AMQP/MQTT message. This process is further described below. Stored data can be queried and retrieved either as a specified number of last records or all data for given time range.

Included in the Middleware, there is a RabbitMQ AMQP Message Broker which also supports MQTT messages. All data which are being stored into the Middleware database are instantly cloned and sent to the broker, where by using Publish/Subscribe pattern, are accessible to other modules in real-time. This pattern is also advantageous for actuating, where by subscribing to the corresponding topic, the need for polling the latest control value is avoided and the value is automatically sent where it is needed.

3.3.2 Middleware platform

After exploring available possibilities, we have selected the WSO2 integration platform as the framework for the middleware. The WSO2 integration platform is a mature technology used by a large number of companies. The WSO2 integration solutions are based on WSO2 Carbon which hosts components for integration, security, clustering, governance, statistics, and other features in the middleware space.

The usage of Attune platform built on top of the Tridium Niagara Framework as a middleware framework mentioned in the DOA was not evaluated as the most viable


17

solution when compared to the selected solution. The reasons for this are the following:

• Niagara is a commercial product which may restrict the possibilities due to inability to change the underlying platform and may also incur deployment complications because of licensing issues.

• Attune was intended as a platform for analytics, however since the compilation of DOA, Honeywell strategy has moved a bit here and Attune is no longer a good choice. Moreover – we’d have to deploy the whole Attune production environment (Honeywell proprietary) and make any analytics Attune-compatible. Having an open platform (WSO2), we can avoid obvious problems and take any algorithm from any environment (including Attune) and connect it to our middleware.

• Selecting Attune platform could lead to us experiencing difficulties from currently limited Honeywell support of Attune platform.

Selection of WSO2 integration platform provides us with numerous advantages, some of which are:

• It is 100% open source project which means it is completely free to use. Anybody can view the source code which is beneficial in understanding how the platform works. Additionally, it offers flexibility in configuring and extending the open source code to meet our requirements.

• The componentized architecture spanning the entire breadth of Service Oriented Architecture (SOA) enables us to deploy only what we need when we need it, so we can easily expand the already deployed middleware with new components depending on our needs.

• The WSO2 platform is fully cloud ready.

One of the greatest strengths of the WSO2 platform will be apparent when all the development activities are started and we will be able to easily create and fine-tune the routing sequences, interfaces and APIs required by devices and services developed by various partners. The routing sequences can perform conditional routing based on the message content or type along with message transformation, which allows the middleware to orchestrate operations among multiple services. These changes are made online while the platform is running and can be done either in Management Console in web browser or offline and then uploaded to the platform as a CAPP (Carbon Application Package) package. ESB Tooling plugin is available for Eclipse which adds intuitive graphical user interface for developing of ESB sequences and APIs.

3.3.3 Enterprise Service Bus

WSO2 ESB is a fast, light-weight, and versatile Enterprise Service Bus (ESB). It is 100% open source and is released under Apache Software License Version 2.0,


18

one of the most business-friendly licenses available today. Using WSO2 ESB allows performing a variety of Enterprise Integration Patterns (EIPs) using mediators, including filtering, transforming, and routing SOAP, binary, plain XML, and text messages that pass through your business systems by HTTP, HTTPS, JMS, mail, etc. An overview of the ESB architecture is shown in Figure 5.

Figure 5. Component based architecture of ESB

The following diagram (Figure 6) illustrates how two applications can exchange messages using the WSO2 ESB (the components of the pipes are not in a specific order):

Figure 6. Messaging based architecture of ESB

1. An application sends a message to the WSO2 ESB. 2. The message is picked up by a transport. 3. The transport sends the message through a message pipe, which handles

quality of service aspects such as security. Internally, this pipe is the in-flow and out-flow of Apache Axis2. The WSO2 ESB can operate in two modes: • Mediating Messages - A single pipe is used.


19

• Proxy Services - Separate pipes connecting the transport to different proxy services are used.

4. Both message transformation and routing can be considered as a single unit. As the diagram specifies, there is no clear separation between message transformation components and routing components. In WSO2 ESB, this is known as the mediation framework. Some transformations take place before the routing decision has been made while others take place after the routing decision. This is part of the Synapse implementation.

5. The message is injected to the separate pipes depending on the destinations. Here again, quality of service aspects of the messages is determined.

6. The transport layer takes care of the transport protocol transformations required by the WSO2 ESB.

The above diagram shows how a request propagates to its actual endpoint through the WSO2 ESB using its architecture. Response handling is the reverse of this operation. There are other areas like Working with Scheduled Tasks and Events that are not shown in the diagram. All these components can be analysed and monitored through WSO2 ESB Analytics.

Messages can be sent directly into the WSO2 ESB using rest, by utilizing the API features of WSO2. An API in WSO2 ESB is similar to a web application deployed in the WSO2 ESB runtime: each API is anchored at a user-defined URL context, much like how a web application deployed in a servlet container is anchored at a fixed URL context. An API will only process requests that fall under its URL context. The API defines one or more resources, which is a logical component of an API that can be accessed by making a particular type of HTTP call.

As stated before, once a message is received, it can be further processed (e.g. transformed, filtered or routed) using mediators. WSO2 ESB includes a comprehensive mediator library that provides functionality for implementing widely used Enterprise Integration Patterns. In addition, custom mediators that provide additional functionality can easily be developed, using various technologies such as Java, scripting, and Spring.

Moving one step higher in the messaging architecture hierarchy, a sequence is a set of mediators organized into a logical flow, that allow implementing message pipes and filter patterns. Sequences can be added to proxy services and APIs.

WSO2 ESB version 5.0.0 is deployed in the middleware. WSO2 released new package containing WSO2 ESB, DSS and other similar products called WSO2 Enterprise Integrator, however by the time of the release, the middleware was already deployed and configured.


20

Figure 7 illustrates the Deployed APIs section in WSO2 ESB Graphical User Interface accessible via web browser. Names of the APIs are self-describing – GetDataAPI is used for routing requests for data from Cassandra database (details about the Cassandra database will be given in Section 3.3.5), InputDataAPI routes incoming requests containing new data to be saved into Cassandra database, and RequestRouterAPI reroutes received messages to specific endpoint discerned from the message content.

Figure 7. Deployed APIs tab in WSO2 ESB GUI

The following figure illustrates one of the defined REST API sequences (InputDataAPI). First, the message is logged. Depending on the content-type of the message it is processed either as a JSON or an XML. This processing transforms the message into a format which is accepted by the instance running the WSO2 Data Service Server (described in the next Section) where it is sent. Incompatible content-type results in returning the message immediately. After being processed by the WSO2 Data Services Server (e.g. data is saved to a Cassandra database or retrieved from it) the result is send back to the requesting application.


21

Figure 8. HOLISDER API resource sequence in Eclipse Developer studio

Figure 9 drills down the JSONSequence sequence which is part of one branch of the switch mediator in Figure 8. In this sequence the message is mapped from JSON to XML format accepted by the WSO2 DSS and then sent to the WSO2 DSS endpoint. During this sequence, the message is also cloned and published to RabbitMQ message broker running in the Middleware, to an AMQP topic corresponding to the data pointname.

Figure 9. Detailed view of the JSONSequence used in InputDataAPI

The following figure shows detailed view at the JSONtoXML datamapper, which allows easy mapping from one format of the message to another. There is


22

possibility of using arithmetic operations or parsing from string to number or vice versa.

Figure 10. Detailed view of JSONtoXML datamapper used in JSONSequence

There are multiple publicly accessible similar REST APIs for use with data in the middleware. These APIs are consumed by sending an HTTP request (GET, POST) to the http address of the EC2 (Amazon Elastic Compute Cloud) instance hosting the WSO2 ESB with the URL of the API. EC2 is a web service that provides secure, resizable compute capacity in the cloud. It is possible to send new data to store it in the Apache Cassandra DB (described in the following Section) or to query for data already stored in the same DB. Some constraints for querying can be specified in the request depending on the API. The following table lists the defined API.

Request

type

Endpoint Description

POST http://35.156.215.81:8280/data Stores data in the Cassandra DB.

Table 1. List of available ESB APIs.

Endpoint for inserting new data points located on http://35.156.215.81:8280/data accepts POST requests with body in JSON or XML format. Example of the JSON containing 3 new data points follows.

[{

"pointname": "pointname1",

"countryid": "countryid1",

"buildingid": "buildingid1",

"timestamp": "2017-03-09T13:20:00",

"reliability": "1",

"value": "1.77"

},

{



"buildingid": " buildingid1",

"timestamp": "2017-03-09T13:20:00",


23

"reliability": "1",

"value": "2.88"

},

{



"buildingid": "buildingid1",

"timestamp": "2017-03-09T13:21:00",

"reliability": "1",

"value": "3.99"

}]

3.3.4 Data Services Server

WSO2 Data Services Server (WSO2 DSS) augments service-oriented architecture development efforts by providing an easy-to-use platform for integrating data stores, creating composite data views, and hosting data services. It supports secure and managed data access across federated data stores, data service transactions, and data transformation and validation using a lightweight, developer friendly, agile development approach. It provides federation support, combining data from multiple sources in single response or resource and also supports nested queries across data sources. The internal architecture of the server is illustrated in Figure 11.

Data Services provide a convenient mechanism to configure a Web service interface for data in various data sources such as relational databases, CSV files, Microsoft Excel sheets, Google spreadsheets etc. These data services provide unprecedented data access and straightforward integration with business processes, mashups, gadgets, business intelligence and mobile applications.

We use the WSO2 DSS version 3.5.1 as a part of the middleware to expose the Cassandra database as a REST API.


24

Figure 11. Overview of the WSO2 Data Services Server architecture

We created a Data Service named CassandraService which connects to the Cassandra DB and serves as a gateway to access the database. Datasource was set up and configured with the details of the Cassandra DB like the address, user name, password, cluster name and keyspace. There is a number of queries which correspond to the ESB APIs. At the moment, there is one query for inserting data and multiple queries for data retrieval with different number and types of input parameters. Each query is linked to its resource. The resource serves as an API, where resource paths denote paths of individual APIs. Resource also passes query parameters found in the URL to the queries.

In the following table, the endpoints currently available on the DSS instance are listed. These endpoints are called mostly internally by ESB to access the Cassandra DB.


25

Request

type

Endpoint Description

POST http://35.156.215.81:8280/data Stores data in the Cassandra DB.

GET http://35.156.22.237:9763/services/CassandraService/data

Returns all data points.

GET http://35.156.22.237:9763/services/CassandraService/pointndata?pointname='pointname'&limit=20

Returns up to a specified number (limit) of data points with specified pointname.

GET http://35.156.22.237:9763/services/CassandraService/pointdaterange?pointname='pointname'&startdate='2017-02-14T08:00:00+00:00'&enddate='2017-02-16T20:00:00+00:00'

Returns all data points with specified pointname between start date and end date.

Table 2. List of available DSS APIs.

It is recommended to use APIs located on WSO2 ESB instance described above in the ESB chapter to insert data. The WSO2 ESB API is capable of parsing JSON and XML formatted data and then marshalling the request to WSO2 DSS instance in correct format. However, it is possible to send POST request on WSO2 DSS instance directly in following XML format:

<body xmlns:p="http://ws.wso2.org/dataservice">

<p:insertOperation>

<timestamp>YYYY-MM-DDTHH:MM:SS</timestamp>

<countryid>countyrid</countryid>

<buildingid>buildingid</buildingid>

<pointname>pointname</pointname>

<value>value</value>

<reliability>reliability</reliability>

</p:insertOperation>

</body>

GET requests return list of entries satisfying constraints given by the query parameters. Returned timestamps are in Unix time format. Example response to a request follows.

Request:

http://35.156.22.237:9763/services/CassandraService/pointdaterange?pointname='SI01.BL00.CL01.SM02.EN0

0'&startdate='2017-04-10T12:00:00'&enddate='2017-04-11T00:00:00'


26

Response:

<entries xmlns="http://ws.wso2.org/dataservice/PointnameTimestampRangeQuery">

<entry>

<pointname>SI01.BL00.CL01.SM02.EN00</pointname>

<reliability>1.0</reliability>

<value>328257.0</value>

<countryid>ES</countryid>

<timestamp>1491825808000</timestamp>

<buildingid>BL00</buildingid>

</entry>

… 142 records …

<entry>

<pointname>SI01.BL00.CL01.SM02.EN00</pointname>

<reliability>1.0</reliability>

<value>328258.0</value>

<countryid>ES</countryid>

<timestamp>1491868726000</timestamp>

<buildingid>BL00</buildingid>

</entry>

</entries>

3.3.5 Cassandra NoSQL database

The central data-store is an Apache Cassandra Database version 3.9.1, which is a highly-scalable partitioned row store, where rows are organized into tables with a required primary key. Partitioning means that Cassandra can distribute the data across multiple machines in an application-transparent matter. Cassandra will automatically repartition as machines are added and removed from the cluster. Row store means that like relational databases, Cassandra organizes data by rows and columns. The available Cassandra Query Language (CQL) for querying the DB is a close relative of SQL.

Cassandra is a distributed storage system for managing very large amounts of structured data spread out across many commodity servers, while providing highly available service with no single point of failure. Cassandra aims to run on top of an infrastructure of hundreds of nodes (possibly spread across different data centres). At this scale, small and large components fail continuously. The way Cassandra manages the persistent state in the face of these failures drives the reliability and scalability of the software systems relying on this service. While in many ways Cassandra resembles a database, and shares many design and implementation strategies therewith, Cassandra does not support a full relational data model; instead, it provides clients with a simple data model that supports dynamic control over data layout and format. Cassandra system was designed to run on cheap commodity hardware and handle high write throughput while not sacrificing read efficiency. Figure 12 shows a simple Cassandra cluster.


27

Figure 12. Simple illustration of a Cassandra cluster.

For the purposes of the project we created a Cassandra cluster running on the Amazon Web Services (AWS). We started with Amazon Machine Image (AMI) by Bitnami with preinstalled basic Cassandra setup. It was necessary to edit the “Cassandra.yaml” configuration files to prepare the individual Cassandra instances to form a cluster. This step required the configuration of addresses for the individual instances and specifying the cluster name. The Cassandra cluster which stores data recorded by sensors from various partners consists of 3 nodes. Each node is installed on a different EC2 instance and all the nodes are connected. The resulting cluster maintains some redundancy between individual nodes, which means that when one node fails, the cluster will still contain a copy of the data on another node and to the outside user the operation of the cluster will not change.

Table “bmsrawdata” is designed to be universally used for storing data from various sources. Its structure and data types are detailed in the following table.

Column Type Key

pointname Text Partition key countryid Text Clustering key, ASC ordering buildingid Text Clustering key, ASC ordering timestamp Timestamp Clustering key, ASC ordering value Double reliability Double

Table 3. Structure of "bmsrawdata" table.

Table “lastprocessedtimestamp” is a helper table which stores latest timestamps of data points which were processed by some kind of analytics. The analytics can then later resume calculation where it ended after accumulating more data since the latest run. The analytics has to keep track of the records in this table itself, it


28

is not automated in any way. The structure of “lastprocessedtimestamp” is described in the following table.

Column Type Key

pointname Text Partition key countryid Text Clustering key, ASC ordering buildingid Text Clustering key, ASC ordering timestamp Timestamp

Table 4. Structure of "lastprocessedtimestamp" table.


29

4 HOLISDER components of the Data Exchange Framework

In this chapter, each of the HOLISDER interoperable components that exchange information using the Common Information Model is described. Special attention has been given to Input and Output Interfaces to other specific modules.

Interoperability and Secure Data Management Layer

4.1.1 Energy Management System

Module full

name

Energy Management System

Module short

name

EMS

Objective Building Energy Management System (BEMS) ties into existing energy-related data streams of a building’s infrastructure, such as its heating, ventilation, and air-conditioning (HVAC), lighting, and metering systems, and provides visualization and analysis of energy data to enable better energy-related decision-making.

BEMS system may or may not have the capability to directly manipulate with individual loads. If not, it is necessary to use the Building Management System (BMS) or directly the physical automation infrastructure for this purpose.

Description Many different types of BEMS systems can be found in commercial buildings. The foundation of most advanced BEMS’s are the building management system (BMS) deployed by large companies, such as Johnson Controls, Schneider Electric, Honeywell or Siemens. However, other solutions can be found focusing on supervisory enterprise-level systems that either tie into other enterprise IT systems (such as those provided by IBM and SAP) or serve on a standalone basis. On the utility side, a number of other BEMS vendors provide a range of utility-related services such as demand response (DR), energy procurement, and customer engagement.

For implementation of HOLISDER pilots it is important to consider BEMS that have the capability to manipulate with building loads as it is required in various demand response schemes.


30

Input

Interfaces

Description Module/Element

Control signal coded in one of the supported protocols (BACnet, EIB/KNX, LON, M-Bus, Modbus, or SNMP)

Gateway / Local Demand Manager

Output

Interfaces



Building asset / equipment

Data to be used for visualization of the current energy status (multiple formats supported, including SQL, Oracle, MySQL, oBIX, CSV, or OPC)

Consumer Visualization and Engagement Platform

Data to be used for historization of relevant asset / equipment performance (multiple formats supported, including SQL, Oracle, MySQL, oBIX, CSV, or OPC

Middleware


31

4.1.2 Observational Framework

Module full

name

Observational Framework

Module short

name

OBF

Objective The Observational Framework software module will be deployed on the gateway and will handle all data streams from the sensing and metering equipment installed in the residential premises.

Description The Observational Framework is part of the extended EF-Pi software suite and provides the required communication drivers and messaging interfaces for the communication with the sensing and metering equipment installed in the residential premises.

Input

Interfaces


Smart Home Protocols

Sensing/Metering

Output

Interfaces


OpenADR-compliant messages

Middleware


32

4.1.3 Gateway

Module full

name

Gateway

Objective The gateway component prescribes the hardware infrastructure required to be deployed in the residential pilot assets, in order to establish the communication hub for sensing (weather, occupancy, indoor conditions), metering (consumption) and monitoring (device status and control).

Description As described previously, the gateway component prescribes the hardware infrastructure required to be deployed in the residential pilot assets. It will provide the deployment platform for the software drivers that will communicate with the various devices in the apartments, as well as for the behavioural framework, which takes care of communication with the sensing and metering equipment.

Input

Interfaces


Smart Home Protocols.

Sensing/Metering/Monitoring Devices.

Output

Interfaces


OpenADR-compliant messages.

Middleware, Resource Managers.

4.1.3.1 OneM2M Standard

One of the main software elements to be deployed on the gateway are drivers that will enable the communication with devices supporting the OneM2M standard. To that extent, a description of this is provided below.

Today there are many competing standards and technologies in the Machine-to-Machine (M2M) and Internet of Things (IoT) domains. This diversity hinders the development of large integrated M2M solutions. The OneM2M initiative aims to provide a framework that creates interoperability among M2M/IoT devices and applications. OneM2M is a global organization which was formed by standards development organizations (representing Japan, USA, Europe, India and South Korea) and industry bodies (such as CEN/CENELEC and the Broadband Forum). Currently there are around 200 OneM2M members.


33

4.1.3.1.1 Architecture

The oneM2M architecture is built upon a layered model that consists of three layers: Network Services Layer, Common Services Layer and the Application Layer. Each layer can only see the layer above or below itself. Besides the layers, a distinction is also being made into two domains: The Field Domain and the Infrastructure Domain. The Infrastructure Domain is a central infrastructure that is being managed by a Service Provider, whereas the Field Domain is the domain where the actual M2M/IoT devices reside, e.g. the home domain.

Figure 13. OneM2M Functional Architecture (taken from TS-0001-

Functional_Architecture-V3_11_0.docx)

Figure 13 shows the oneM2M functional architecture with its layered approach and both domains. There are three entity types which can be found in both domains:

• Application Entity (AE). This entity contains the business logic of a particular M2M application. This could in principal be anything. Examples that are provided in the functional architecture document itself are a remote blood sugar monitoring application or a power metering application.

• Common Services Entity (CSE). The CSE provides common services that can be used by the application entities, such as data management, discovery, subscription to M2M services, etc.

• Network Services Entity (NSE). The NSE provides network services to the CSE and maps those on the underlying network technology. The network technology itself is hidden from the CSE.

The actual implementation of the entities is not part of the oneM2M framework but is left to the market. OneM2M restricts itself to defining the interfaces that exist between entities. These interfaces are bundled in reference points: Mcn, Mcc and Mca. All reference points are named Mcx, where Mc stands for ‘M2M


34

communications’. The Mcn reference point describes the communication between a NSE and a CSE. Mca represents the communication between a CSE and a AE and the Mcc the communication between to CSE’s. There is a special reference point for the interfaces that describe the communication between CSE’s in different infrastructure domains which is the Mcc’.

4.1.3.1.2 OneM2M example

On its website oneM2M describes a use case where an application on a smart phone is being used to remotely control the lights in a house, as is shown in Figure 14.

Figure 14. Example use case (taken from http://www.onem2m.org/application-

developer-guide/architecture)

This use case shows the involved AE’s and CSE’s and the nodes they are deployed on. There are three types of nodes which are identified by a prefix: IN, MN and ADN. IN stands for Infrastructure Node, MN for Middle Node and ADN for Application Dedicated Node.

The process starts with the registration of the MN-CSE on the home gateway to the IN-CSE on the Cloud Service Platform (which is hosted by a service provider) The next step is for the IN-AE on the smart phone to also register itself at the IN-CSE on the Cloud Service Platform. Finally, both ADN-AE’s register themselves at the MS-CSE on the home gateway. The IN-AE and the ADN-AE’s are now able to communicate via the services offered by the IN-CSE and the MN-CSE.

For further information on this example case we refer to http://www.onem2m.org/application-developer-guide/architecture.


35

4.1.4 JACE Controller

Module full

name

JACE Controller

Module short

name

JACE

Objective JACE controller will be used as one of the key components enabling to deliver the open and modular end-to-end interoperability and data management framework of HOLISDER. More specifically JACE will be used as a gateway to BMS or BEMS systems deployed in commercial buildings and it will serve as a deployment platform for the Local Demand Manager.

In pilot sites where Tridium Niagara is deployed to automate operation of the local HVAC system, the JACE controller will natively integrate with the existing automation system. In other pilots, it will enable integration through many of the available commercial BEMS and building control protocols, including BACnet, LonWorks, KNX, oBIX, OPC-UA, Modbus, Drivers for IEC 61850-based web communication, and others.

Description

The JACE 8000 is a compact, embedded IoT controller and server platform for connecting multiple and diverse devices and sub-systems. With Internet connectivity and web-serving capability, the JACE 8000 controller provides integrated control, supervision, data logging, alarming, scheduling, and network management. It streams data and rich graphical displays to a standard web browser via an Ethernet or wireless LAN, or remotely over the Internet.


36

JACE 8000 is the latest release in the series of JACE controllers and it features a global design that functions with legacy systems and has the ability to scale for future needs. Standard Wi-Fi offers enhanced wireless capability when interfacing with the next generation of wireless sensors and devices. The JACE 8000 controller also is configurable as an access point so that mobile phones and tablets can display information and advanced graphics.

Input

Interfaces


DR signal coded as an OpenADR message

Global Demand Manager

Output

Interfaces



Building asset / equipment

Data to be used for visualization of the current system status (multiple formats supported, including SQL, Oracle, MySQL, oBIX, CSV, or OPC)


Data to be used for historization of relevant asset / equipment performance (multiple formats supported, including SQL, Oracle, MySQL, oBIX, CSV, or OPC)

Middleware


37

4.1.5 Proprietary Field Area Equipment and Smart Devices/Sensors

Module full

name

Proprietary Field Area Equipment and Smart

Devices/Sensors

Module short

name

Smart Devices/Sensors

Objective Smart devices provide flexibility and are controlled by the higher layers of the HOLISDER architecture. Sensors may provide additional information on devices, or rooms within the building/household.

Description Smart devices and sensor will typically feature a proprietary protocol that has to be used to monitor and control it.

Input

Interfaces


Smart devices receive input from the Observational Framework, e.g. commands to switch on/off, modulate, etc. The following protocols are currently supported by the Observational Framework:

• Serial communication • Modbus (over TCP/IP) • Bluetooth • ZigBee • Smart Grid Ready • Miele@Home • Various HTTP/REST

variants

These protocols have been used to control a range of devices, such as:

• CHP’s • Batteries • Electrical Vehicles • PV panels • Smart Meters • Washing machines • Dryers • Dishwashers



38

• (Hybrid) heat pumps • Electrical boiler • Refrigerators • Smart plugs

It is very well possible that we encounter devices and protocols on pilot locations that are not supported yet. If that is the case, then new drivers for these protocols/devices will be developed within the HOLISDER project.

Building sensors, controllers, and automation devices typically communicate using one of the commonly used communication protocols, such as BACnet, LON, Modbus, or KNX. These interfaces are typically implemented by automation contractors and should be available for distribution of commands and actions (start/stop or set-point adjustments). Alternatively, we will create a new communication link directly from a gateway represented by the JACE controller.

Building/District Energy Management System

Output

Interfaces


Smart devices and sensors send status information to the Resource Managers. With this information a Resource Manager is able to determine how much flexibility a particular device has to offer. Protocols and devices that are already supported are



39

listed above in the “Input Interfaces” section.

In most cases the sensors will be integrated into a device, but is also possible to interact with stand-alone sensors. Low level sensor information will not be shared via the EFI interface. However, Resource Managers that are implemented on EF-Pi feature a separate communication channel for sensor information: the observation framework. Within this framework connectors can be implemented to share the sensor information with other components, such as the ESB module in the HOLISDER architecture.

Building sensors, controllers, and automation devices will communicate their status information and other data using one of the commonly used communication protocols, such as BACnet, LON, Modbus, or KNX. This information will be received by the Energy Management System and further processed. Alternatively, all data will be communicated directly to given gateway.

Building/District Energy Management System


40

Local Demand Manager for Implicit Demand Response

4.2.1 Virtual Thermal Energy Storage Module

Module full

name

Virtual Thermal Energy Storage

Module short

name

VTES

Objective The VTES module sits on top of the building/asset energy management system and or apartment thermostatic control infrastructure and establishes the possible flexibility opportunities that can be offered by the considered asset through preheating/precooling techniques.

Description In essence, the VTES comprises a simplified thermal zone/building model and an energy optimization algorithm.

For computation of the baseline demand, an optimization problem is solved first without considering the thermal capacity capabilities of the building envelope or any other heat storage equipment that may be available in the premises (e.g. hot water storage tanks). Having established such a baseline demand for future timepoints, a second energy optimization is solved, this time taking into account the heat storage possibilities available, keeping of course any temperature and other relative occupant requirements the same.

By making the optimization procedure conscious of the heat storage capabilities, the optimized operational status provides an alternative demand profile. The difference between the two is defined as the available VTES-related flexibility, which is then communicated to the profiling module, so as to consider this on the overall flexibility computations.

The following functionalities are prescribed: 1. Request data for building and device operational and

thermal behaviour. 2. Return upon request the maximum demand flexibility

values for the predefined time period and intervals, offered through preheating/precooling techniques (utilization of building capacity/storage devices).

3. Request through the occupant UI any demand requirements in terms of a schedule for temperature and other needs.


41

Input

Interfaces


Post service for getting occupant thermal constraints – SXD Schema

<xs:schema

xmlns:xs="http://www.w3.org/2001/XMLSchema"

elementFormDefault="qualified"

attributeFormDefault="unqualified">

<xs:element name="thermal_constraints">

<xs:complexType>

<xs:sequence>

<xs:element name="building_id"

type="xs:int"/>

<xs:element name="zone_id"

type="xs:int"/>

<xs:element

name="temperature_constraint"

type="xs:float"/>

<xs:element name="timestamp"

type="xs:dateTime"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

End-user App

Get service for getting building / device thermal parameters – SXD Schema

<xs:schema





<xs:complexType>

<xs:sequence>


type="xs:int"/>


type="xs:int"/>

<xs:element name="capacity"

type="xs:float"/>

<xs:element name="resistance"

type="xs:float"/>

<xs:element name="device_id"

type="xs:int"/>

<xs:element name="cop"

type="xs:float"/>



</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

BEMS


42

Output

Interfaces


Get service for getting VTES-related flexibility – XSD Schema

<xs:schema





<xs:complexType>

<xs:sequence>


type="xs:int"/>


type="xs:int"/>

<xs:element name="flexibility"

type="xs:float"/>



</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

Demand Flexibility Profiling Engine Module


43

4.2.2 Demand Flexibility Profiling Engine Module

Module full

name

Demand Flexibility Profiling Engine

Module short

name

DFPE

Objective The DFPE module is responsible for identifying individual asset related demand flexibility, based on occupant comfort preferences, occupancy and weather information and device operational details. Upon request then, the module can return forecasts of maximum available flexibility that can be offered to the aggregator and/or elasticity that can be offered to the energy supplier from the specific asset, which is subsequently used by the FFSA module.

Description In particular, DFPE is constituted of a number of interleaved components which are responsible for: (a) learning the thermal and visual comfort profiles of the occupants, (b) identifying the occupancy profiles on the monitored zones, (c) estimating the flexibility available for explicit DR, (d) estimating the elasticity available for implicit DR. Each submodule requires a number of past and real-time metering, sensing and actuation data in order to fit the various models. Given the trained models, requests for forecasts are answered with a timeseries of maximum available demand flexibility for a number of predefined time intervals in the future (e.g. estimates for the next 15, 30, 45, 60 minutes).

The functionalities to be offered are the following:

1. Request data for fitting the Occupancy Profile Model. 2. Request data for fitting the Thermal Profile Model. 3. Request data for fitting the Visual Profile Model. 4. Request data for building and device operational and

thermal behaviour. 5. Request data for fitting the elasticity model. 6. Return upon request the maximum demand flexibility

values for the predefined time period and intervals. 7. Return upon request the elasticity of demand and

elasticity of substitution values for the predefined time period and intervals.


44

Input

Interfaces


Post service for occupancy sensor data – XSD Schema:

<xs:schema




<xs:element name="occupancy_event_data">

<xs:complexType>

<xs:sequence>


type="xs:int"/>


type="xs:int"/>

<xs:element name="sensor_id"

type="xs:int"/>

<xs:element name="sensor_type_id"

type="xs:int"/>


type="xs:gMonthDay"/>

<xs:element name="value"

type="xs:boolean"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

Gateway

Post service for the acquisition of environmental events (luminance, temperature, humidity, CO, CO2, tVOC) – XSD Schema:

<xs:schema




<xs:element name="occupancy_event_data">

<xs:complexType>

<xs:sequence>


type="xs:int"/>


type="xs:int"/>

<xs:element name="sensor_id"

type="xs:int"/>

<xs:element name="sensor_type_id"

type="xs:int"/>


type="xs:gMonthDay"/>


type="xs:boolean"/>

<xs:element name="units"

type="xs:string"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

Gateway


45

Post service for user control actions (lighting and HVAC) – XSD Schemas:

<xs:schema




<xs:element name="lighting_event_data">

<xs:complexType>

<xs:sequence>


type="xs:int"/>


type="xs:int"/>

<xs:element name="light_device_id"

type="xs:int"/>

<xs:element name="status_id"

type="xs:int"/>

<xs:element name="dimming"

type="xs:float"/>



</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

<xs:schema




<xs:element name="hvac_event_data">

<xs:complexType>

<xs:sequence>


type="xs:int"/>


type="xs:int"/>

<xs:element name="hvac_device_id"

type="xs:int"/>

<xs:element name="status_id"

type="xs:int"/>

<xs:element

name="hvac_operation_mode_id"

type="xs:int"/>

<xs:element name="setpoint"

type="xs:float"/>

<xs:element name="fanspeed"

type="xs:int"/>



</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

Gateway/BEMS

Post service for Elasticity Training Data – XSD Schema:

<xs:schema




Energy Tariff Emulator / External weather service (ESB)


46

<xs:element name="elasticity_data">

<xs:complexType>

<xs:sequence>


type="xs:int"/>


type="xs:int"/>

<xs:element name="consumption"

type="xs:float"/>

<xs:element name="price"

type="xs:float"/>

<xs:element name="temperature"

type="xs:float"/>

<xs:element name="tariff_scheme"

type="xs:string"/>

<xs:element name="energy_source"

type="xs:string"/>



</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

Get service for VES flexibility –

XSD Schema:

<xs:schema




<xs:element name="elasticity_data">

<xs:complexType>

<xs:sequence>


type="xs:int"/>


type="xs:int"/>

<xs:element name="flexibility"

type="xs:float"/>



</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

Virtual Thermal Energy Storage Module

Output

Interfaces


Get service for Thermal and Visual comfort profile values – XSD schema:

<xs:schema




<xs:element name="comfort_profile_value">

<xs:complexType>

<xs:sequence>


type="xs:float"/>

</xs:sequence>

Flexibility Forecasting, Segmentation and Aggregation Module


47

</xs:complexType>

</xs:element>

</xs:schema>


48

4.2.3 Lighting/HVAC System Energy Manager

Module full

name

Lighting/HVAC System Energy Manager

Module short

name

EM

Objective The particular module should be considered as a “placeholder” for the required resource managers which take care of all communications between the gateway/JACE and the upper level flexibility and control-related components of the LDM. The EM draws heavily from the EF-Pi framework, and translate the various protocols (e.g. ZigBee, Modbus, Bluetooth, etc.) and data models that smart devices use into EFI messages. The EFI messages only describe energy flexibility and provide interoperability between smart devices and the algorithms in the Local Demand Manager. Although attributed to this layer, it must be noted that the EM sits in between this and the interoperability layer.

Description Each smart device will have its own instance of an EM. The manager has the following characteristics:

• It uses a device specific interface and extracts/enriches Energy Flexibility information from it

• It typically has a model of the device and may use external information sources (e.g. weather forecast)

• It is responsible for maintaining user comfort. • It is responsible for staying within the operational

boundaries of a device. • It can also implement interfaces for other purposes, e.g.

home automation or remote maintenance

Input

Interfaces


Control interface, this will differ from device to device

Smart Device / Gateway

EFI Instruction messages (see EFI specification)

Local Demand Manager


49

Output

Interfaces


EFI Registration and Flexibility Update messages (see EFI specification)

Local Demand Manager


50

4.2.4 Building Monitoring and Control Dispatch Module

Module full

name

Building Monitoring and Control Dispatch

Module short

name

BMCD

Objective The key objective of the Building Monitoring and Control Dispatch module is to ensure execution of local DR strategies, whose dispatch was determined by the Local Demand Manager. Once the strategies start to be executed, the BMCD module also continuously monitors potential deviations and makes corrections by implementing adjustments.

The BMCD module is overall responsible for responsible for receiving and breaking down the asset flexibility requirements into the flexibility that can be offered by each load type, through help from the energy managers, which take care of the direct communication to/from the devices.

Description The Building Monitoring and Control Dispatch module operates as the gateway point from/to the local demand manager. On the one side, the module listens for any DR events generated by the portfolio monitoring and control dispatch module. Upon such an event, it initiates the required communication with the device energy managers, in order to verify the best manner of accomplishing the request.

On the other hand, the module is responsible for monitoring the real-time consumption, and based on the baseline, compute whether the request was satisfied. This is reported back to the global demand manager.

Additionally, the module communicates with the end-user app to provide suitable information as well as price information.

The BMCD module will be closely integrated in the Local Demand Manager that will have responsibility for creation of an optimal consumer-level dispatch based on the available global flexibility determined by the Global Demand Manager.


51

Input

Interfaces


The BMCD module will receive inputs from the Portfolio Monitoring and Control Dispatch Module of the Global Demand Manager that will be coded using OpenADR protocol.

The content will differ depending on the type of DR scheme. In case of explicit DR event requests, the input information will include the target reductions to be achieved at selected loads. In case of implicit DR, the input will primarily include price information.

Portfolio Monitoring and Control Dispatch Module

Messages following the EFI specification, transmitting to the module information about available flexibility/elasticity.

Demand Flexibility Profiling Engine

Output

Interfaces


Messages following the OpenADR specification, transmitting to the global demand manager asset flexibility/elasticity information, and reports on DR performance.

Portfolio Monitoring and Control Dispatch Module

Messages following the EFI specification, transmitting to the devices general signals for demand modification.

HVAC/Lighting System Energy Manager


52

Global Demand Manager for Explicit Demand Response

4.3.1 Energy Tariff Emulator Module

Module full

name

Energy Tariff Emulator

Module short

name

ETE

Objective The Energy Tariff Emulator collects and analyses wholesale energy price data, renewables output, along with information about energy networks constraints, to produce real-time retail prices estimations to promote the use of implicit DR programmes to energy consumers.

Description In more detail, the Energy Tariff Emulator will emulate real-time energy retail tariffs for each of the different energy carriers involved in the project, such as electricity, district heating and gas. This will be done depending on the needs of each of the four pilot locations.

The Energy Tariff Emulator will consider the special situations occurring in energy networks and will address them in special tariff schemes such as Critical Peak Pricing (CPP).

The inputs to the Energy Tariff Emulator are the matrix flexibility of prices per hour, the historical and day-ahead wholesale energy prices, the historical renewable energy production data, the weather forecast for the day-ahead (to estimate renewable energy production) and the energy network constraints for electricity, gas and district heating:

• The matrix flexibility of prices per hour in each pilot site is provided by the Demand Flexibility Profiling Engine.

• The historical and day-ahead wholesale energy prices are provided by the utility. Public web sources for electricity carriers in the 4 pilot locations have already been identified. Data sources for gas and district heating carriers have not been identified yet. Maybe, this data could be facilitated by pilot partners.

• The historical renewable energy production data must be provided by pilot partners if available. In the pilot implementation, real-time renewable energy production data will be obtained through OpenADR from the JACE controller in charge of the control/monitoring of the DER Management System.


53

• The energy network constraints will be related to peak energy consumptions, capacity of the different energy carriers and energy balance needs between the different energy sources. Strong feedback from pilot partners are necessary to properly identify them as they can be very different according to each particular pilot.

The destination modules or outputs of the Energy Tariff Emulator are the Flexibility Forecasting, Segmentation and Aggregation Module and the Demand Flexibility Profiling Engine:

• The emulator will feed the Flexibility Forecasting, Segmentation and Aggregation Module in order to support DR optimization strategies through the effective utilization of aggregated DER flexibility.

• The emulator will also support the flexibility profiling activities of the project by feeding real-time pricing data to the Demand Flexibility Profiling Mechanism to identify how user behaviour is transformed on the basis of variable tariffs.

• Historical and current real-time retail prices estimations will be stored in Cassandra database through ESB Middleware to be accessible, for example, by the visualization modules. Historical wholesale energy prices and other relevant information will also be stored in Cassandra database.

Input

Interfaces


Matrix flexibility of prices per hour in each pilot site – See DFPE module format data

Demand Flexibility Profiling Engine module

Historical wholesale electricity, gas and district heating prices for the corresponding pilot countries:

</Publication_MarketDocument>

<sender_ID> 1001A </sender_ID>

<period.timeInterval>

<start>2018-03-24T00:00Z</start>

<end>2018-03-25T00:00Z</end>

</period.timeInterval>

<TimeSeries>

<currency_Unit.name>

EUR

</currency_Unit.name>

Wholesale Energy Market External Data Source


54

<price_Measure_Unit.name>

MWH

</price_Measure_Unit.name>

<Period>

<timeInterval>

<start>2018-03-24T23:00Z</start>

<end>2018-03-25T22:00Z</end>

</timeInterval>

<resolution>PT60M</resolution>

<Point>

<position>1</position>

<price.amount>38.52</price.amount>

</Point>

<Point>



</Point>

…………………..

<Point>



</Point>

</Period>

</TimeSeries>

</Publication_MarketDocument>

Renewable energy production

data using OpenADR standard messages

{

"reportID" : "1234",

"reportName": "reportName1",

"eventID": "123",

"venID": "assetID",

"aggregatedPnode" : "4.2",

"reportedSignals" : [

{

'baseline_power_kw': '15.2',

'mean_power_kw': '43.4',

'current_power_kw': '371.1',

'start_time': 'datetime',

'end_time': ' datetime '

}

]

}

JACE controller in charge of renewable energy sources control/monitoring

Weather prediction (temper., amount of sunshine, wind speed) as well as current and historical weather data – See WMF module format data

Weather Forecasting from External Data Source

Electricity, Gas and District Heating network constraints – See DSO module format data

Energy Network Operator System of each pilot


55

Output

Interfaces


The emulated energy retail prices for electricity, gas and district heating will be sent upon request using a JSON/XML format message. {

"market": "ToU, CPP or RTP",

"carrier": "electricity, gas or district",

"systemUser": "retailer01",

"timestampCreated": "datetime",

“intervalStartTime”: “datetime”,

“intervalEndTime”: “datetime”,

“intervalDuration”: “perhour”

"RetailPriceList": [{

"interval": "0",

"value": "xxxx"

},

{

"interval ": "1",

"value": "xxxx"

},

…….

{

"interval": "23",

"value": "xxxx"

}

]

}

Flexibility Forecasting, Segmentation and Aggregation module

The emulated energy prices for electricity, gas and district heating will be sent upon request using a JSON/XML format message. {


"carrier": "electricity, gas or district",



“intervalStartTime”: “datetime”,

“intervalEndTime”: “datetime”,

“intervalTimeStep”: “perhour”

"RetailPriceList": [{

"interval": "0",

"value": "xxxx"

},

{

"interval ": "1",

"value": "xxxx"

},

…….

{

"interval": "23",

"value": "xxxx"

}

]

}

Demand Flexibility Profiling Engine module


56

4.3.2 Flexibility Forecasting, Segmentation and Aggregation Module

Module full

name

Flexibility Forecasting, Segmentation and Aggregation

Module short

name

FFSA

Objective The functional objective of this module is to support DR optimization and DR strategies optimization through the effective utilization of aggregated DER flexibility.

Description The particular module offers the analytics engine, which in tandem with visualization and interaction UIs offered to Aggregators, Retailers and ESCOs, will enable a multidimensional analysis, correlation and efficient management of prosumer profiles and prosumer flexibility across the aforementioned actors’ portfolios. In particular, the module will support:

• Clustering of consumers/buildings/assets with similar properties under specific pricing schemes or comfort-based and health constraints (e.g. assets with low/high flexibility, assets with high/low response capacity, assets suitable for participation in specific DR programs).

• Overall view of past portfolio performance through suitable KPIs, such as individual and overall response performances, satisfaction rates to DR requests, and spatiotemporal distribution of ranked assets.

• Detection of outliers during DR requests. • Suggestions on suitable clusters of customers to provide

certain flexibility given spatiotemporal, pricing or DR scheme (market) and consumption characteristics.

Through the following functions:

1. Identify optimal portfolio cluster for satisfaction of DR request.

2. Compute optimal demand request for each asset. 3. Compute price value to be communicated to the

consumers (for Implicit DR). 4. Provide visualization data to the aggregator and retailer

apps.


57

Input

Interfaces


The following message is the response of each asset to an explicit DR triggering depending on whether the asset opts in or out of the DR trigger, needed for the consumer performance assessment:

{

"eventID": "123",

"venID": "assetID",

"signalIDs": ["17", "97", "107"],

"optType": "true" OR "false"

}

Building Monitoring and Control Dispatch module

The following JSON object is the reported result – actual flexibility delivered of the explicit DR signal needed for the consumer performance assessment:

{

"reportID" : "1233",

"reportName" : "reportName1",

"eventID" : "123",

"venID" : "assetID",

"aggregatedPnode" : "8.6",

"reportedSignals" : [

{

"signalID" : "17",

"aggregatedPnode" : "8"

},

{

"signalID" : "97",

"aggregatedPnode" : "1.0"

},

{

"signalID" : "107",

"aggregatedPnode" : "-0.4"

}

]

}

Building Monitoring and Control Dispatch module

Output

Interfaces


After filtering, ranking and optimizing for explicit demand response, the asset-specific flexibility request is broadcasted in JSON format:

{

"eiEventDescriptor": {

District Monitoring and Control Dispatch Module


58

"eventID": "1",

"createdDateTime": "2012-12-13T12:12:12"

},

"eiEventSignals": {

"eiEventSignal": [

{

"signalID": "17",

"startTime": "2012-12-13T12:00:00",

"activePeriod": "PT15M",

"eiTarget": {

"venID": "assetID",

"aggregatedPnode": "8"

}

},

…

],

"numDataSources": "3"

},

"activePeriod": "PT45M",

"eiTarget": {

"venID": "assetID",

"aggregatedPnode": "8.6"

}

}

The above JSON object is broadcasted as a list of objects, each one is dedicated to a specific asset, defined by the unique asset key (venID) and represents an explicit DR request to the specific asset (building).

For implicit DR, the FFSA module communicates to clusters of consumers the identified market prices through the following interface:

{




"dsmPriceList": [{

"interval": "0",

"value": "xxxx"

},

{

"interval ": "1",

"value": "xxxx"

},

…….

{

"interval": "23",

"value": "xxxx"

}

]

District Monitoring and Control Dispatch Module


59

FFSA provides to the UI interfaces for reporting details on portfolio flexibility. The JSON body response for explicit DR should have the following format:

{

"market" : "explicit",

“timestampCreated” : “datetime”,

“ParticipationList”: [

{

"assetId": "asset01",

“dsmParticipation” : [

{“interval”: "0",

“value”: “xxxx”,

“cost” : “XXX”},



“cost” : “XXX”},

…



“cost” : “XXX”}

]

},

…

]

}

Aggregator App


60

4.3.3 Portfolio Monitoring and Control Dispatch Module

Module full

name

Portfolio Monitoring and Control Dispatch

Module short

name

PMCD

Objective The functional objective of this module is the provision of services for stable and secure grids, while optimizing the participation of aggregators and retailers in the market.

Description The PMCD module sits between the FFSA engine and the visualization toolkit in order to implement the services and functionalities offered towards aggregators and retailers for monitoring and optimal management of their complete portfolio.

In particular, the module will utilize and process information received by the FFSA and the LDM, for the selection of appropriate aggregated demand side setup to provide specific DR functions, enabling the provision of services, such as balancing, frequency response or voltage regulation, based on input from the respective stakeholder and after performing suitable cost optimization.

Furthermore, the module is responsible for continuously monitoring the progress of the DR event and generate alerts in case that a request is not satisfied as predicted.

Input

Interfaces


The module needs to query the FFSA module for acquiring elasticity or flexibility estimates, either aggregated in portfolio level, or disaggregated in subsets or even individual assets. The same message structure will cover all functionalities.

The JSON body response (simulated) for implicit DR should have the following format:

{

"marketContext" : "Elasticity", “Flexibility”

“timestampCreated” : “datetime”,

“ParticipationList”: [

FFSA


61

{

"assetId": "asset01",



“value”: “xxxx”},



……..


“value”: “xxxx”}

]

},

{

"assetId": " asset02",






……



]

},…

]

}

The message above indicates that flexibility and elasticity estimations are provided day ahead, per hour, for a complete day. This could be finetuned.

In order to identify the demand profiles, the module will need to query the FFSA module for aggregated demand and consumption profiles.

Message type:

{ "forecast": {

"1507154400":22.544, "1507158000":21.438, "1507161600":12.242, "1507165200":12.116, "1507168800":10.985, "1507172400":12.235, "1507176000":9.152, "1507179600":58.837, "1507183200":65.365, "1507186800":22.05, "1507190400":38.03, "1507194000":8.861, "1507197600":1.071, "1507201200":15.919, "1507204800":20.187, "1507208400":16.721, "1507212000":9.775,

FFSA


62

"1507215600":2.027, "1507219200":4.288, "1507222800":3.249, "1507226400":6.186, "1507230000":2.068, "1507233600":3.909, "1507237200":2.478

}, "units":"kW"

}

The USEF ontology must define

the interchange of information between the DSO and the aggregator (and retailer in case of hybrid DR schemas) (e.g. bidding and requests for flexibility.

From/to the DSO

The module will need to be informed about wholesale and current retails prices from the tariff emulator.


Output

Interfaces


The output interfaces from the PMCD module towards the local demand manager, depend on the DR event type (explicit or implicit). In both cases, the signal will be compliant with the OpenADR protocol.

Example of JSON message for transmitting information about prices to the consumer:

{

"marketContext": "ToU, CPP or RTP?",


“targetUsers”: [{“asset01”}, {“asset02”}, …],

"activePeriods": [{ "datetimestart", "datetimeend"},

{"datetimestart", "datetimeend"}, …],

"priceList": [{“value": "xxxx"}, {"value": "xxxx"},…]

]

}

Example of JSON message for transmitting information about

Building Monitoring and Control Dispatch Module


63

demand modification to the consumer:

{

"marketContext": "Short-Term",”Mid-Term”, …

"systemUser": "aggregator01",

“targetUsers”: [{“asset01”}, {“asset02”}, …],

"activePeriods": [{ "datetimestart", "datetimeend"},

{"datetimestart", "datetimeend"}, …],

"demandModification": [{“value": "xxxx"}, {"value":

"xxxx"},…]

}


64

Building Visualization and User Toolkit

4.4.1 Predictive Maintenance Advisor Module

Module full

name

Predictive Maintenance Advisor

Module short

name

PMA

Objective The predictive maintenance engine will provide capabilities for systematic monitoring of equipment performance, detecting and diagnosing specific mechanical faults, detecting anomalous behaviour, identifying Indoor Air Quality (IAQ) violations and recommending optimized maintenance actions, which will be based on prediction of the future equipment performance.

The applicability of the predictive maintenance engine will primarily be on all major HVAC equipment (such as boilers, chillers, air handling units, fan-coils, fans, pumps, heat exchangers, dampers, valves, while potentially incorporating other types of devices), and it will provide information about the detected faults (e.g. valve stuck) and deteriorated performance (e.g. boiler running at the efficiency 5% lower than expected due to likely fouling).

Description The workflow of the predictive maintenance engine will include the following steps:

(i) Monitoring of time series of important process parameters (temperatures, flow rates, IAQ parameters), control signals (from the automation system) and electricity consumption (metering system),

(ii) Calculation of suitable performance indicators that characterize performance of the system or its individual components

(iii) Systematic comparison of these indicators with the values predicted by a model,

(iv) Processing of all detected deviations and other symptoms using a rule-based engine,

(v) Compiling a list of performance issues and faults, each being accompanied with an indication of fault severity and potential financial impact;

(vi) Generating a list of recommended actions to prioritize work of servicemen and technicians when maintaining the building systems


65

For selected known degradation processes happening in building, specific performance indices will be defined and those will be calculated based on available data streams (step ii). Once given threshold or sudden change is detected, an alarm will be issued to inform facility manager (step v) about likely fault or malfunction.

Input

Interfaces


BMS sensor readings related to a specific piece of HVAC equipment. These should be (near) real-time data that will be historized by the HOLISDER framework.

BMS, or direct reading from building controllers

Electricity metering data related to a specific piece of HVAC equipment. These should be (near) real-time data that will be historized by the HOLISDER framework.

BMS or direct sensor reading

Electricity metering data related to a specific piece of HVAC equipment. These should be (near) real-time data that will be historized by the HOLISDER framework.


Comfort data (temperature, potentially also humidity) for all interior spaces served by the HVAC system. These should be (near) real-time data that will be historized by the HOLISDER framework.



66

Output

Interfaces


1. Identified abnormal situations in the systems with the associated timestamp. Example:

• Event ID: 2b24b68e-1459-431a-a760-536810fdas690d

• Time: 2019-10-19T22:17:36.384Z

• Site ID: Caverion bldg • Equipment ID: AHU 01a • AnomalyType:

degradation|fault • Description: "fouled

heating coil" • Probability: 70%

2. Recommended maintenance actions. Example:

• Due date: 2019-10-29 • Task ID: T26 • Contractor: ATS • Site ID: Caverion bldg • Equipment ID: AHU 01a • Symptoms: takes

significantly more time to heat the space

• Description: likely fouled heating coil

Consumer visualization and engagement platform


67

4.4.2 Consumer Visualization and Engagement Platform

Module full

name


Module short

name

Consumer App

Objective To offer a friendly interface to the end-user for increasing awareness and understanding on consumption patterns and flexibility potential, while enabling non-intrusive communication of DR signal, personalized guidance & advice provision and automated control signal dispatch over selected loads.

Description The Consumer Visualization and Engagement Platform will offer to the Consumers a friendly and responsive web interface for being able to interact in real time with their smart devices, to know their current energy behaviour and also see their historical data, among other functionalities.

It will directly interact with some of the other modules of the HOLISDER Conceptual Architecture for getting the needed data to be displayed to the consumer:

• Demand Flexibility Profiling Engine (DFPE) • Middleware (MW) • Observational Framework (OBF) • Virtual Thermal Energy Storage module (VTES) • Energy Tariff Emulator (ETE)

Input

Interfaces


Retail energy prices Energy Tariff Emulator module

Flexibility information Demand Flexibility Profiling Engine

Flexibility offered by the considered building through preheating/precooling techniques

Virtual Thermal Energy Storage module

Automated control signal dispatch over selected loads.

Portfolio Monitoring and Control Dispatch

Status and information of the different sensorized devices

Proprietary Field Area Equipment and Smart Devices/Sensors


68

Local generation output and the flexibility offered by the thermal storage capabilities of buildings and available equipment

Building Monitoring and Control Dispatch

Mechanical faults or discrepancies, anomalous behaviour and defective equipment/ materials

Predictive Maintenance module

Current and predicted weather Weather data Output

Interfaces


Web/Mobile application


69

District Visualization and User Toolkit

4.5.1 Aggregator Application Module

Module full

name

Aggregator Application

Module short

name

Aggregator App

Objective To offer a user interface to the end-users for handling with the management of the portfolio, the clusterization of flexibility, and monitoring the DR strategies implementation.

Description Aggregators and Retailers will be offered the same web application for interacting with the modules conforming the HOLISDER architecture, having each one their own functionalities.

In the case of the Aggregators, the tool will allow them to interact with their own portfolio for displaying statistical and analytic information about it and/or the customers on it, in addition to being able to create clusters (taking into account different criteria) and manage them. It will also be used for the management of the DR campaigns.

For doing so, it will directly interact with some of the other modules of the HOLISDER Conceptual:

• Flexibility Forecasting, Segmentation and Aggregation Module (FFSA)

• Middleware (MW)

Input

Interfaces



When an alert is generated, the Flexibility module should invoke this service with the content of the alert, so the user interface can react immediately for displaying it to the user:

{

"_id": "123"

"timestamp": "2018-07-03 10:05:00"

"type": "type"

"message": "this text that should be human-

readable"

Flexibility, Forecasting and Aggregation module


70

}

DR strategies Portfolio Monitoring and

Control Dispatch Wholesale energy prices Wholesale Energy Market

data Current and predicted weather Weather Monitoring and

Forecasting data Output

Interfaces




71

4.5.2 Energy Supplier/Retailer Application Module

Module full

name

Supplier/Retailer Application

Module short

name

Retailer App

Objective To offer a user interface to the end-users for analysing the portfolio flexibility, and improved energy trading

Description Aggregators and Retailers will be offered the same web application for interacting with the modules conforming the HOLISDER architecture, having each one their own functionalities.

The application for the Retailers will allow the interaction with the energy markets for being able to offer prices for the next hours. In addition to this, a tariff editor will be added for creating the tariffs to be offered to the users.

For doing so, it will directly interact with some of the other modules of the HOLISDER Conceptual:

• Energy Tariff Emulator (ETE) • Middleware (MW)

Input

Interfaces



Flexibility information Flexibility, Forecasting and Aggregation module

DR strategies Portfolio Monitoring and Control Dispatch

Wholesale energy prices Wholesale Energy Market data

Current and predicted weather Weather Monitoring and Forecasting data

Output

Interfaces




72

External Data Sources Layer

4.6.1 Wholesale Energy Market Data

Module full

name

Wholesale Energy Market

Module

short name

WEM

Objective Provide historical and real-time wholesale energy data for electricity, gas and district heating.

Description Historical and real-time/day-ahead wholesale energy prices for electricity, gas and district heating in each pilot site need to be obtained from sources external to the HOLISDER project. The external sources comprise publicly available data sources, websites of the energy carriers/utilities or/and data provided by the pilot partners themselves. The wholesale energy prices will mainly feed the Energy Tariff Emulator module.

Input

Interfaces

None

Output

Interfaces


Historical and day-ahead wholesale electricity, gas and district heating prices [e.g. External data for wholesale electricity prices ENTSO-E website https://www.entsoe.eu/ ]:

<Publication_MarketDocument>

<sender_ID>

1001A

</sender_ID>

<period.timeInterval>

<start>2018-03-24T00:00Z</start>

<end>2018-03-25T00:00Z</end>

</period.timeInterval>

<TimeSeries>

<currency_Unit.name>

EUR

</currency_Unit.name>

<price_Measure_Unit.name>

MWH

</price_Measure_Unit.name>

<Period>

<timeInterval>

<start>2018-03-24T23:00Z</start>



73

<end>2018-03-25T22:00Z</end>

</timeInterval>

<resolution>PT60M</resolution>

<Point>



</Point>

<Point>



</Point>

…………………..

<Point>



</Point>

</Period>

</TimeSeries> </Publication_MarketDocument>


74

4.6.2 Weather Monitoring and Forecasting Data

Module full

name

Weather Monitoring and Forecasting

Module short

name

WMF

Objective The establishment of a database including outdoor weather data (temperature, humidity), both measured and forecasted is required for the successful realization of comfort and flexibility profiling, and consequently for the establishment of the DR service offerings.

Description An external weather monitoring and forecast service needs to be established in the HOLISDER framework, so that all modules that require that data can depend only on queries towards the centralized Cassandra database to acquire this information. In more detail, external weather data is required for the processes of elasticity and comfort-based flexibility estimation (since it affects predictions on energy consumption), as well as for informative purposes by the visualization toolkit.

Input

Interfaces

None

Output

Interfaces


Various available services are available online for the acquisition of weather data. The APIs for current and forecasted weather from https://openweathermap.org/current follows:

Get https://samples.openweathermap.org/data/2.5/weather?id=2172797&appid=b6907d289e10d714a6e88b30761fae22 With the following JSON response

{"coord":{"lon":145.77,"lat":-16.92},

"weather":[{"id":802,"main":"Clouds",

"description":"scattered clouds","icon":"03n"}],

"base":"stations",

"main":{"temp":300.15,"pressure":1007,

"humidity":74,"temp_min":300.15,"temp_max":300.15},

"visibility":10000,"wind":{"speed":3.6,"deg":160},


75

"clouds":{"all":40},"dt":1485790200,

"sys":{"type":1,"id":8166,"message":0.2064,"country":"AU","su

nrise":1485720272,"sunset":1485766550},

"id":2172797,"name":"Cairns","cod":200}

https://samples.openweathermap.org/data/2.5/forecast?id=524901&appid=b1b15e88fa797225412429c1c50c122a1 With the following JSON response

{"cod":"200","message":0.0036,"cnt":40,

"list":[{"dt":1485799200,"main":{"temp":261.45,"temp_min":25

9.086,"temp_max":261.45,"pressure":1023.48,"sea_level":1045

.39,"grnd_level":1023.48,"humidity":79,"temp_kf":2.37},

"weather":[{"id":800,"main":"Clear","description":"clear

sky","icon":"02n"}],"clouds":{"all":8},"wind":{"speed":4.77,"deg

":232.505},"snow":{},"sys":{"pod":"n"},"dt_txt":"2017-01-30

18:00:00"},

{"dt":1485810000,"main":{"temp":261.41,"temp_min":259.638,

"temp_max":261.41,"pressure":1022.41,"sea_level":1044.35,"g

rnd_level":1022.41,"humidity":76,"temp_kf":1.78},"weather":[{

"id":800,"main":"Clear","description":"clear

sky","icon":"01n"}],"clouds":{"all":32},"wind":{"speed":4.76,"de

g":240.503},"snow":{"3h":0.011},"sys":{"pod":"n"},"dt_txt":"201

7-01-30 21:00:00"},

...


76

4.6.3 Energy Distribution System Operator Data

Module full

name

Energy Distribution System Operator

Module short

name

EDSO

Objective Provide energy network constraints about the capacity of the different energy carriers: electricity, gas and district heating and the energy balance between them.

Description The energy network constraints will be related to peak energy consumptions, capacity of the different energy carriers (electricity, gas and district heating) and energy balance needs between the different energy sources. Strong feedback from pilot partners are necessary to properly identify them as they can be very different according to each particular pilot.

Input

Interfaces

None

Output

Interfaces


Current electricity, gas and district heating consumption

<NetworkSystem>

<sender_ID>

1234

</sender_ID>

<carrier>

“electricity”,”gas” or “district”

<\carrier>"

<timestamp>

2018-03-24T09:28Z

<\timestamp>

<reportedPowerComsuption>

<base_power_kw>32.1<\base_power_kw>

<mean_power_kw>32.1<\ mean_power_kw>

<current_power_kw>32.1<\ current_power_kw>

<\reportedPowerComsuption>

</NetworkSystem>



77

5 Extensions to standard OpenADR 2.0b

The current state of the OpenADR 2.0 standard

The OpenADR standard is an open-source smart grid communications standard used for demand response applications. The work on this standard started by the OpenADR alliance, with an aim to reach a non-proprietary, open, and tightly standardized DR interface that allows electricity providers to communicate DR signals directly to existing customers using a common language and existing communications such as the Internet, in a quick, fail-safe, consistent and bidirectional manner. The OpenADR standard is designed to be used in explicit demand response scenarios, when specific signals are sent to cause devices to be turned off during periods of higher demand.

To realize the DR services in such a setting, with automated decisions and actuation, OpenADR has to ensure a reliable communication channel between a large variety of stakeholders: from power generation facilities, possibly through aggregators, to consumers. In general, the most relevant points of OpenADR are:

• Continuous, secure, and reliable communication. • Translation of DR event information to continuous Internet signals. • Automation: the receipt of the external signal is designed to directly

initiate automation through the use of pre-programmed demand response strategies determined and controlled by the end-use participant.

• Opt-Out provided in the standard, an override function to disable the DR responses on behalf of the end users when these are not desirable.

• Complete Data Model that describes an architecture to communicate price, reliability, and other DR activation signals.

• Scalable Architecture. • Open Standards based.

In OpenADR, all interactions occur between entities called Virtual Top Nodes (VTNs) and Virtual End Nodes (VENs). The VTNs send demand response signals to the VENs and there is a hierarchical relationship between VTNs and VENs. The VENs respond to the signals sent to them by the VTNs.

It is common that a same node is both a VEN and a VTN in different contexts (Figure 16), acting as a VEN for the hierarchically higher VTN, and then disseminating the DR signals to the VENs in a hierarchically lower level. This model therefore supports the notion of intermediaries such as aggregators, which makes it applicable within the contexts of intermediaries and facilitators.


78

Figure 15. OpenADR communication architecture

Figure 16. Example DR interactions in the OpenADR architecture

Two profiles of OpenADR have been developed with the third one in the pipeline. Profile A is targeted towards low end devices and is limited to a simple implementation of OpenADR, while Profile B is targeted toward fully functional control systems and devices and enable feedback and additional services. Profile

C is in development and specifically aimed at aggregators and similar entities.

The list of services supported by OpenADR 2.0b profiles is the following:

• EiEvent – for notifying VENs of upcoming DR events and sending demand-response signals from the VTN to the VEN.

• EiOpt – used by the VEN for opting in/out of DR events. • EiReport – used by the VEN for reporting information to the VTN. Such

information is typically used by the VTN to both predict and monitor the behaviour of the demand-side loads associated with the VEN.


79

• EiRegisterParty – used to establish communications between a VEN and a VTN.

The limited OpenADR 2.0a profile only supports a simple implementation of EiEvent, and for the OpenADR 2.0c profile four additional services are planned: EiEnroll, EiMarketContext, EiQuote and EiAvail. Figure 17 illustrates the scope of the OpenADR profiles, and their relation to OASIS Energy Interoperability 1.0 standard. OpenADR as a whole is designed to fit within the scope of the OASIS Energy Interoperability 1.0 standard.

Figure 17. The OpenADR profiles

The OpenADR standard is currently being adopted by the IEC within the IEC 62746 - Systems interface between customer energy management system and the power management system series of standards. In particular, the OpenADR 2.0b profile is practically adopted as IEC 62746-10. This standard provides technical specification and architecture for the management of DR, leverages other IEC standards (primarily IEC 61850). The standard defines a minimal data model and services for DR, pricing, DER communications etc.

In OpenADR, two fundamentally different types of signals can be used: prices and load dispatches. Prices implicitly incentivize the demand-side resource to change its load profile, and a load dispatch is a completely explicit instruction on what the load profile should be.

Mapping of OpenADR to CIM – CIM Extensions for OpenADR

The Common Information Model (CIM) model is one of the main Smart Grid standards used today. CIM model was developed by the electric power industry and afterward it was officially adopted by the IEC. It started with the objective of


80

developing a common power system network model to exchange information, and nowadays it is a de facto standard adopted by most vendors and utilities. It has since been extended to cover tasks related to electric power industry, such customer billing, work scheduling and asset tracking.

Within the IEC 62746 series of standards, there is a standard defining the mapping of OpenADR to the CIM standard. It is the IEC 62746-10-3 1 - Systems interface between customer energy management system and the power management system – Part 10-3: Open automated demand response – Adapting smart grid user interface to IEC common information model.

This document actually defines the methodology to define adapters to carry out core transformations between the CIM-based utility systems using CIM profiles supporting CIM demand response and distributed energy resources (that is, CIM DR profiles), and smart grid user interface (SGUI) bridge standards that bridge to the customer facility domain. It is therefore wider in scope and not only covering the OpenADR: the document actually defines a standard method to achieve interoperability for the semantics and mapping of message payloads.

In that document, as an example for the definition of the adapters, the interoperation between a specific CIM DR profile and the IEC 62746-10 (i.e. essentially the OpenADR standard) is provided. Such interoperation is two-way: the example shows a DR event produced by a CIM-based system communicated by means of an adapter to the virtual end node. Essentially, this document shows how to define adaptors so that CIM is applicable to the OpenADR as well.

There are four steps for creating an adapter:

1) Determining the information model on the SGUI end (the SGUI-faced endpoint of the adapter, in this case, the OpenADR side).

2) Determining the information model on the grid operations end (the CIM-facing endpoint of the two-way adapter).

3) Build the XML schema for the CIM DR profile. 4) Build the XML transformation between grid operations and SGUI sides of the

adapter; in common business applications such adapters are implemented as XSLT transformations.

1 IEC TS 62746-3:2015. Systems interface between customer energy management system and the power management system - Part 3: Architecture. https://webstore.iec.ch/publication/23488


81

Figure 18. Graphical XSLT mapping between CIM ResourceDeployment sample message based on IEC 62325-301:2018 and IEC 62746-10-1 EiEvent

As an example, the figure above shows a graphical illustration of the mapping of the CIM ResourceDeployment sample message and the OpenADR / IEC 62746-10-1 EiEvent message. This was the result of the work of IEC PC118. In this project, we propose providing similar mappings for the proposed usages of OpenADR, including the extensions to the OpenADR to address additional semantics.


82

Implementation of extensions to the OpenADR standard

In this project, the semantics for other energy carriers, besides electricity should be covered. It is true that the OpenADR is obviously designed with electricity in mind, however it is not a matter of just adding the explicit notions of other carriers in the future revisions of OpenADR. The scope covered by the OpenADR standard provides the DR message exchange and not the DR application logic. For the automated DR to operate, the application logic reacting to the received DR signal has to be implemented in the VEN, and this is not covered by the scope of the standard, as this is highly application-specific. Essentially this means the OpenADR standard should be extended with the communication extensions necessary to work with other energy carriers, while leveraging the existing generalized concepts to the maximum extent possible to avoid cluttering of the standard.

The OpenADR Alliance provides documents such as the OpenADR 2.0 Demand Response Program Guide2, which is essentially a cookbook for recommended practices on implementing the OpenADR standard. The target audience for the program guide is utilities planning to deploy DR programs based on OpenADR 2.0 for communicating between the utility and downstream entities, and the manufacturers of equipment that facilitate that communication exchange.

Profile specifications of the OpenADR clearly define the expected behaviour when exchanging DR event related information, however there is enough optionality in OpenADR that the deployment of servers (VTNs) at the utility and clients (VENs) at downstream sites is not a plug-n-play experience, even when only the electricity is considered.

Its characteristics such as event signals, report formats, and targeting must be specified on a DR program-by-program basis and there is no such thing as a standardized DR program. Each DR program has its specifics, fitting the structural and regulatory requirements of the geographic region it is deployed in. There are numerous stakeholders involved and very different positions of these stakeholders with regards to DR programs.

Such variability is an obvious inhibitor to deployment of DR and the use of OpenADR. However, as with any standard, this is a trade-off. Inevitably, a standard that allows a wide range of flexibility would fall short of defining the deployment requirements explicitly. On the other hand, an overly constrictive standard that overprescribes the requirements disallowing stakeholder specifics would be even harder to implement and would deservedly face stakeholder opposition.

2 The OpenADR Alliance: OpenADR 2.0 Demand Response Program Guide https://www.openadr.org/assets/openadr_drprogramguide1.0.pdf


83

For this reason, the OpenADR alliance keeps the OpenADR standard as general as possible, and to mitigate the difficulties in implementation, it provides the cookbooks in the form of program guides. The program guide defines a small set of standard DR Program templates modelled after the common characteristics of the most popular DR programs implemented to date, and a small set of deployment scenarios modelled after real world deployments, with actors and roles clearly identified. These are essentially a set of OpenADR success stories converted into “recipes” for deployment, with best practices recommendations for OpenADR characteristics specific for each of the DR Program templates.

The emphasis in the guide is on keeping things simple by providing a small set of clear recommendations that will address most of the details required to deploy a DR program.

Even though the OpenADR DR program guide covers an extensive range of DR scenarios, it does not go beyond electricity as the energy carrier. The goals of the HOLISDER project include covering the flexibility restrictions guided by the user comfort, and the project has to address semantics for other energy carriers and to lead the transition from price and explicit control commands to the instructions and guidelines understandable and actionable by human beings.

This will be done in two general steps: by extending the mapping of CIM model to OpenADR to address semantics for other energy carriers, and by incorporating semantics about human comfort profiles.

The proposed approach for the introduction of OpenADR extensions is to firstly leverage the existing concepts to the maximum extent possible. In other words, instead of trying to clutter the standard, the HOLISDER project will try to provide a guide, as close to the cookbook as possible, on how to leverage the existing concepts in OpenADR.

It may prove necessary that extensions to the standard are still required. In this case, extensions to the standard will be proposed, with the primary goals of the standard in mind. The principal means of doing so will be through KONČAR experts. As Croatian representatives in the IEC TC 57 PC118 dealing with the IEC 62746 series of standards, and also as participants in the CIM working groups, they are well positioned to adequately impact both sides of this problem.

Therefore, the proposed strategy for the extensions to the OpenADR standard is as follows:

- Reuse the existing concepts to the maximum extent possible. - Provide the cookbook-style implementation guide which will stem from the

OpenADR use within the HOLISDER infrastructure.


84

- Define the CIM mapping to the OpenADR implemented above so that the grid side can adapt the relevant messages.

- Where necessary, propose the extensions to the base underlying standards.


85

6 Conclusions

This deliverable describes the Common Information Model (CIM) structure of the HOLISDER project, the interoperable components of the Data Exchange Framework focusing on the Input and Output Interfaces to other specific modules and the extensions to the standard OpenADR 2.0b protocol for supporting gas and district heating carriers, human comfort profiles and demand elasticity.

This document is the final result of Task T4.2 for developing a Common Information Model to ensure semantic interoperability and for adapting communication standards in order to enable Demand Response (DR) in residential and tertiary buildings. This implementation will guarantee the scalability and open approach of the HOLISDER Communication Framework.

The CIM of Task T4.2 is complemented by the work done in parallel in Task T2.4 to develop the HOLISDER Communication Architecture, its functional and technical specifications, its interfaces and the definition of protocols. Both Task T4.2 and T2.4 results will be used in the development of the HOLISDER Interoperability and Data Management Framework carried out in Task T4.3. This communication and data management framework for DR will enable end-to end interoperability between modular components using well-known standards.

The extensions to the standard OpenADR 2.0b protocol defined in this document and the feedback obtained in the pilot implementations will be later gathered in the form of standardization recommendations in Task T6.6 Scaling-up and Replication Roadmap. A standardization punch-list will also be prepared and promoted to standardization bodies, committees and working groups in Task T7.4 Standardization Activities.

Date post:	31-May-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Integrating Real-Intelligence in Energy Management Systems …holisder.eu › reports ›...

Documents