D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICES Deliverables/RESPOND_Deliverable_D5... · 1. INTRODUCTION The goal of WP5 is to enable interoperability between different RESPOND

This project has received funding from the European

Union’s Horizon 2020 research and innovation

programme under grant agreement No 768619

The RESPOND Consortium 2019

Integrated Demand REsponse

SOlution Towards Energy

POsitive NeighbourhooDs

WP5 SYSTEM INTEGRATION AND

INTEROPERABILITY

T5.2 SMART GRID CONNECTIVITY

D5.2 RESPOND CONNECTIVITY

TO SMART GRID SERVICES

WP5 SYSTEM INTEGRATION AND INTEROPERABILITY

D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW

2 | 46

PROJECT ACRONYM RESPOND

DOCUMENT D5.2 RESPOND connectivity to smart grid

services

TYPE (DISTRIBUTION LEVEL) ☒ Public

☐ Confidential

☐ Restricted

DELIVERY DUE DATE 30.09.2019.

DATE OF DELIVERY 30.09.2019.

STATUS AND VERSION Final, version 1.0

DELIVERABLE RESPONSIBLE IMP

CONTRIBUTORS DEX, TEK, NUIG

AUTHOR (S) Lazar Berbakov, Dejan Paunović, Dea Pujić, Marko

Jelić, Andreu Pagès, Iker Esnaola, Francisco

Javier Díez, Federico Seri

OFFICIAL REVIEWER(S) TEK



3 | 46

DOCUMENT HISTORY

ISSUE DATE CONTENT AND CHANGES

0.1 05.07.2019. Table of contents

0.2 08.08.2019. Pupin’s contribution

0.3 28.08.2019. Contribution writing

0.4 05.09.2019. Tekniker’s contribution

0.5 07.09.2019. Pupin’s contribution

0.6 24.09.2019. Dexma’s contribution

0.7 27.09.2019. Internal review by Tekniker

1.0 27.09.2019. Final editing



4 | 46

In this document on “RESPOND connectivity to smart grid services” we summarize the results of

the Task 5.2 from Month 7 to month 24 of the RESPOND project. The goal of Task5.2 was to

support RESPOND platform connectivity through an open Application Programming Interface

(API) and enable exploitation of data provided by smart grid and other third-party services (e.g.

provision of energy prices, weather forecast data, etc.). Besides, this open API will enable the

reuse of the core RESPOND services and provide an easy uptake and replication of the

leveraging concepts. In addition, it will enable the extension of the third-party business processes

and their further integration into the smart grid products and services. Open API has been

designed to enable almost effortless scaling in different directions. Its aim is to attract industry,

energy providers and consumers and, at the same time, to enable RESPOND gaining advantage

and achieving momentum in market penetrations.

Open API is designed to provide single endpoint for programmatic access to RESPOND services

such as: DR optimization algorithms, forecasted energy consumption, performance evaluation,

global ranking, etc. In such a way, it will pave a way for the creation of rich and broad range of

value-added DR supporting products, ranging from personalized client software to analytic tools,

thus increasing the functionality, innovativeness, scope and reach of the platform.

EXECUTIVE SUMMARY



5 | 46

TABLE OF CONTENTS

EXECUTIVE SUMMARY _____________________________________________________________ 4

TABLE OF CONTENTS ______________________________________________________________ 5

LIST OF FIGURES __________________________________________________________________ 6

LIST OF TABLES ___________________________________________________________________ 7

ABBREVIATIONS AND ACRONYMS __________________________________________________ 8

1. INTRODUCTION ___________________________________________________________________ 10

1.1 RELATION TO OTHER RESPOND ACTIVITIES __________________________________________________ 10

1.2 REPORT STRUCTURE ____________________________________________________________________ 10

2. SMART GRID COMMUNICATION TECHNOLOGIES ________________________________________ 11

2.1 OPENADR _________________________________________________________________________ 11

2.1.1 OPENADR DEMAND RESPONSE PROGRAMS _____________________________________________________ 11

2.1.2 OPENADR DEPLOYMENT SCENARIOS ___________________________________________________________ 15

2.1.3 OPENADR DEPLOYMENT SCENARIOS AND DEMAND RESPONSE PROGRAMS ___________________________ 18

2.1.4 OPENADR AND USEF ________________________________________________________________________ 19

2.1.4.1 OPENADR AND USEF DEPLOYMENT SCENARIO ________________________________________________ 19

2.1.4.2 INCENTIVE-BASED PROGRAM ______________________________________________________________ 20

2.1.4.3 TRANSACTION-BASED PROGRAM ___________________________________________________________ 20

2.1.4.4 OVERRIDE PROGRAM_____________________________________________________________________ 20

2.2 LORAWAN ________________________________________________________________________ 20

2.3 OBIX _____________________________________________________________________________ 22

2.4 DEMAND RESPONSE FUNCTIONAL REQUIREMENTS: USEF ___________________________________ 23

2.4.1 USEF ROLES __________________________________________________________________________________ 24

2.4.2 USEF INTERACTIONS ___________________________________________________________________________ 26

2.5 WRAP-UP _____________________________________________________________________________ 27

3. RESPOND THIRD PARTY SERVICES ADAPTERS ___________________________________________ 28

3.1 SMART GRID SERVICE PROVIDER __________________________________________________________ 28

3.2 WEATHER DATA SERVICE PROVIDER ________________________________________________________ 30

3.3 ENERGY PRICES SERVICE PROVIDER ________________________________________________________ 33

4. RESPOND SERVICES OPEN API ________________________________________________________ 36

4.1 DR OPTIMIZATION SERVICE _______________________________________________________________ 36



6 | 46

4.2 ENERGY CONSUMPTION FORECAST SERVICE _________________________________________________ 40

4.3 ENERGY PRODUCTION FORECAST SERVICE ___________________________________________________ 43

4.4 OPTIMIZED CONTROL SERVICE ____________________________________________________________ 44

5. CONCLUSIONS ____________________________________________________________________ 45

REFERENCES _____________________________________________________________________ 46

LIST OF FIGURES

FIGURE 1: OPENADR DIRECT 1 SCENARIO _________________________________________________ 15

FIGURE 2: OPENADR DIRECT2 SCENARIO __________________________________________________ 16



FIGURE 5: OPENADR FACILITATOR SCENARIO ______________________________________________ 17

FIGURE 6: OPENADR AGGREGATOR SCENARIO _____________________________________________ 17

FIGURE 7: OPENADR AND USEF DEPLOYMENT SCENARIO _____________________________________ 19

FIGURE 8: LORAWAN GENERAL ARCHITECTURE ____________________________________________ 21

FIGURE 9: LORAWAN EXAMPLE ARCHITECTURE ____________________________________________ 22

FIGURE 10: OBIX ARCHITECTURE ________________________________________________________ 23

FIGURE 11: SMART GRID SERVICE PROVIDER _______________________________________________ 28

FIGURE 12: DR EVENT DATA FLOW_______________________________________________________ 30

FIGURE 13:DATABASE SCHEMA FOR WEATHERBIT.IO EXTERNAL WEATHER SERVICE _______________ 33

FIGURE 14: OPENWHISK CONCEPTS (SOURCE: IBM CORPORATION) ____________________________ 36

FIGURE 15: SYNCHRONOUS EXPLOITATION OF THE ENERGY CONSUMPTION FORECASTING MODELS __ 41



7 | 46

LIST OF TABLES

TABLE 1: DEMAND RESPONSE PROGRAM AND THEIR POTENTIAL ............................................................. 12

TABLE 2: OPENADR DEMAND RESPONSE PROGRAMS (PART1) .................................................................. 13

TABLE 3: OPENADR DEMAND RESPONSE PROGRAMS (PART 2) ................................................................. 14

TABLE 4: OPENADR DEPLOYMENT SCENARIOS FOR DIFFERENT DEMAND RESPONSE PROGRAMS ........... 18

TABLE 5: USEF INTERACTIONS SUMMARY .................................................................................................. 26

TABLE 6: WEATHER FORECAST API .............................................................................................................. 31

TABLE 7: API ENDPOINT TO SAVE ENERGY PRICING .................................................................................... 34

TABLE 8: API ENDPOINT TO FETCH ENERGY PRICING .................................................................................. 35

TABLE 9: THE LIST OF PARAMETERS WHICH CAN BE USED WHEN INVOKING AN ACTION ........................ 38

TABLE 10: TYPES OF RESPONSES RECEIVED WHEN INVOKING WEB ACTIONS ........................................... 38



8 | 46

ABBREVIATIONS AND ACRONYMS

ADS Active Demand & Supply

API Application Program Interface

BMS Building Management System

BRP Balance responsible party

CLI Command-Line Interface

CPB Capacity Bidding Program

CPP Critical Peak Pricing

DDC embeddeD Digital Controls

DER Distributed Energy Resources

DLC Direct Load Control

DR Demand Response

DSO Distribution system operator

ESCO Energy Service Company

EV Electric Vehicle

HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

HVAC Heating, Ventilation, and Air Conditioning

ICT Information and Communication Technology

IP Internet Protocol

JSON JavaScript Object Notation

LPWAN Low Power Wide Area Network

MQTT Message Queuing Telemetry Transport

PV Photo-Voltaic

REST Representational State Transfer



9 | 46

SaaS Software as a Service

SOAP Simple Object Access Protocol

STC Solar Thermal Collector

TCP Transmission Control Protocol

TOU Time of Use

TSO Transmission system operator

VEN Virtual End Node

VTN Virtual Top Node

WS Web Services

XML Extensible Markup Language



10 | 46

1. INTRODUCTION

The goal of WP5 is to enable interoperability between different RESPOND platform components

and system integration. This document presents the results of Task 5.2, which deals with

connectivity to smart grid and external services and systems. As it has been described in

Description of Work (DoW), the goal of Task 5.2 is to support platform connectivity through an

open Application Programming Interface (API), thus enabling exploitation of data provided by

smart grid and third-party services as well as offering RESPOND analytic service capabilities to

wider community. This open API model is designed to allow effortless implementation and ensure

easy market uptake of the RESPOND platform by attracting different market players such as:

industry, energy providers and consumers. In order to achieve this goal, a single end point for

programmatic access has been developed that permits access to DR optimization algorithms,

forecasted energy production and consumption, performance evaluation, etc.

1.1 RELATION TO OTHER RESPOND ACTIVITIES

The output of Task 2.1, which lasted from Month 1 to Month 12 of the project, is the architecture

of the RESPOND platform and preliminary specification of various system components. Besides,

Task 2.5 which partially run in parallel with Task 5.3, has focused on the development and

implementation of RESPOND cloud-based platform which includes services developed within

Work Package 4. That work package contains the tasks devoted to the development of analytic

services, which also enable programmatic access through the Open API presented in this

document.

1.2 REPORT STRUCTURE

In this document, which presents the results of Task 5.2, we provide more information regarding

connectivity to smart grid and RESPOND Open API. In Section 2, we provide an overview of the

smart grid communication technologies. Then, in Section 3, we focus on third-party services

developed within the project. In particular, we present implementation of adapters towards smart

grid, weather and energy prices services. Next, in Section 4, a description of Open API for the

analytic services developed within the project. Finally, in Section 5, we conclude the document

with the summary of the outcomes of Task 5.2.



11 | 46

2. SMART GRID COMMUNICATION TECHNOLOGIES

In this section the most relevant communication protocols for demand response have been

analysed: OpenADR, LoRaWAN, and oBIX. Standard protocols such as IEC 60870 or custom-

made protocols are also used, however, in the present document, what is expected to be the

future trend, is explained for RESPOND platform. OpenADR is a solution more used for the

upstream communication between the Demand Response (DR) module and the aggregator, while

the other two (i.e. LoRaWAN and oBIX) are more focused for the communication at building level

between the controllable loads and the BMS for instance. It has been decided to analyse these

protocols since they could offer a high range of standardization. Nevertheless, there has not been

a standardization process in DR protocols especially in Europe among all the aggregators.

Therefore, the USEF framework is explained at the last section to understand the DR ecosystem,

and also as a guideline for standardization of smart grid communications.

2.1 OPENADR

OpenADR stands for Open Automated Demand Response. It is an open and interoperable

information exchange model and emerge Smart Grid standard developed by the OpenADR

Alliance. This alliance was created to foster the development, adoption, and compliance of the

proposed standard. The solutions based on OpenADR will standardize, automate, and simplify

the use of Demand Response worldwide. It makes Demand Response a more reliable and cost-

effective resource to help electric market actors coping with growing demand for energy and

giving Prosumers greater control over their energy. Despite the benefits of spreading Demand

Response programmes are obvious, the industry to date has lacked an organization responsible

for education, training, testing, and certification needed to bring this technology to market and

make it scalable.

The OpenADR Alliance is an initiative backed by over 100 members including utilities, software

suppliers, device manufacturers, laboratories, Demand Response Aggregators, testing and

certification institutions, system integrators and consulting firms.

2.1.1 OPENADR DEMAND RESPONSE PROGRAMS

OpenADR proposes the following Demand Response programs with different features (structure,

target market, etc.) from its guideline [4] :

a) Critical Peak Pricing (CPP)

• Rate and/or price structure

• Reduce consumption during high prices or system contingencies

• Wholesale market

• Pre-set a high rate or price for some days or hours

b) Capacity Bidding Program (CPB)

• Load reduction at a price

• Retail and wholesale markets



12 | 46

c) Thermostat Program (Thermostat)/Direct Load Control (DLC)

• Control customer’s electrical equipment

• Short notice

• Controlled by the program sponsor (Aggregator)

• Market: residential and small commercial

d) Fast DR Dispatch (Fast DR)/Ancillary Services Program

• Situation: Emergency Event

• Incentive payments to Fast DR customers

e) Residential Electric Vehicle (EV Charging) DR Program

• Cost of charging is modified to shift consumption patterns

f) Public Station Electric Vehicle (EV Charging) Real-Time Pricing Program

• A cost-effective charging process

g) Distributed Energy Resources (DER) DR Program

• Smooth the integration of DER into the smart grid

The following table displays the potential of each different OpenADR program for a DR ICT

solution.

TABLE 1: DEMAND RESPONSE PROGRAM AND THEIR POTENTIAL

OpenADR DR program Potential for

Future DR

applications

Why?

Critical peak pricing Low Implicit DR

Capacity bidding Very high Explicit and for aggregators

Thermostat or Direct Low For residential

Fast DR dispatch High Explicit and for aggregators,

but fast-reaction loads are

needed

Residential EV Time of

Use

Low Implicit DR

Public EV Real Time

Pricing

Low Implicit DR

Distributed Energy

Resources (DER)

Medium For customers with storage

The next tables show more details about each OpenADR program:



13 | 46

TABLE 2: OPENADR DEMAND RESPONSE PROGRAMS (PART1)

Program Critical peak pricing Capacity Bidding Thermostat or direct

Objective Peak reduction • Peak reduction

• Resource adequacy Peak reduction

Type of DR Implicit Explicit Explicit

Primary

Drivers

• CAPEX reduction

• Reduce energy costs

• CAPEX reduction


• CAPEX reduction


Program

Description

• High wholesale market prices

• Power system emergency conditions

Used by utilities to

obtain pre-

committed load shed

from aggregators or

self-aggregated

customers

• High wholesale market prices

• Power system emergency conditions

Customer

Incentive

Discounts during non-

peak times

• Availability or capacity payment

• Energy payment

• Discounts on purchased ADS

• Annual stipend for continued enrolment

Rate Design Rates increase during

critical peaks

Through Capacity

bidding

• Free or discounted ADS

• Periodic stipend for energy reduction

Target

Customer

• Residential

• C&I

• Aggregators

• Self-aggregated C&I customers

• Residential

• Small commercial

Target Load Any Any HVAC

Prerequisites • Interval metering

• Meet a demand criterion for C&I customers

• Interval metering

• Meet a demand criterion for C&I customers

None

Program

Time Frame

Monthly Anytime Monthly

Event

Constraints

Workdays Workdays Workdays

Event Days 9-15 per year Max 30 hours/month 9-15 per year

Event

Duration

4-6 hours per event 1-8 hours per event 2-4 hours per event

Notification Day ahead Depends on the capacity

contract

From 10 minutes to 24

hours before

Operation

Behaviour

Customers not required

to participate in events

Depends on the capacity

contract

• Customers not required to participate in events

• Automatically opted in, unless manually stopped



14 | 46

Certification

Events

None Two per year None

TABLE 3: OPENADR DEMAND RESPONSE PROGRAMS (PART 2)

Program Fast DR Dispatch Residential EV Time Of

Use

Public EV Real Time

Pricing

Distributed

Energy

Resources

(DER)

Objective Load response in “real-time”

(2 secs -10 mins)

Change consumption

patterns through cost-

effective EV charging

Change

consumption

patterns through

cost-effective EV

charging

Smooth

Renewable

Energy

integration

Type of DR Explicit Implicit Implicit Implicit /

Explicit

Primary

Drivers

• Grid reliability

• Ancillary services

• Avoid evening peaks Reduce EV

charging cost

• CAPEX reduction


Program

Description

• Used by utilities to obtain pre-committed load response for Primary Reserve

• Dispatched to increase or decrease load

• Charge EVs at off-peak

• Lower cost for EV owners

• Reduce demand

• Real-time prices before charging

• Make a better decision before charging

• Customers with DER

• Store the excess and use it for DR

Customer

Incentive

• Availability or capacity payment

• Energy payment

Less expensive charge Less expensive

charge

Cost control during

high electricity

prices

Rate Design Through Capacity bidding Time of use (TOU):

• Mid-day peak

• Morning and evening mid-peak

• 12 AM – 5 AM off-peak

• Prices vary hourly

• Same price rate once the car has started charging

Regarding

electricity rates

Target

Customer

• Aggregators

• Self-aggregated C&I customers

EV owner with a load

profile that peaks in the

evening

Anyone with an EV that

needs to charge while

away from home

With storage

resources

Target Load Loads with 2 secs -10

mins response time

EV chargers Public EV

chargers

Any

Prerequisites • Interval metering

• Minimum load size

• Response time: 2 secs – 10 mins

• Real-time telemetry

• Smart meter

• EV

• OpenADR2.0 certified

OR

• Connected to an OpenADR2.0b VEN gateway

Energy

storage

resources

Program

Time Frame

Anytime All-year All-year Any time



15 | 46

Event

Constraints

None None None None

Event Days None Every day, or weekdays

only

Every day, or

weekdays only

Everyday

Event

Duration

Less than 30 minutes 5-8 hours per day 1 hour or longer 24 hours

Notification None • Informational monthly bills with costs

• Day-ahead

The customer is

notified before plug in

the car.

Day ahead

Operation

Behaviour

Customers are opted in by

default

Contract change as it is

done with a utility

Customers may opt out

deciding not to charge

A best effort

program

Certification

Events

1 per year None None None

2.1.2 OPENADR DEPLOYMENT SCENARIOS

There are six scenarios proposed by OpenADR. Four scenarios are organized directly (Direct)

between the Resource Party (Prosumer) and the DR Program Party; another through a Facilitator;

and the last one through an Aggregator.

I. Direct 1

The enrolment process is done by the Resource Party

(Prosumer) and the VEN (Virtual End Node) receives

directly the signal in this scenario. However, the signal is

not directly done by the VEN since the load controller is

the responsible for that.

II. Direct 2

FIGURE 1: OPENADR DIRECT 1

SCENARIO



16 | 46

The load controller decides the action to be taken and

there are independent controls for each load. This

scenario is ideal for large buildings with a BMS which

controls HVAC, lightning, industrial processes, etc.

III. Direct 3

In this case the signal is directly sent to the resource

(Prosumer) and its controller. Besides, a direct

interaction with the grid entities exits and the devices act

per price signals (‘price to devices’).

IV. Direct 4

Direct 4 has been designed for scenarios without a

Building Management System (BMS). In this scenario,

the VENs (Virtual End Nodes) are controlled by the

resource party (Prosumer).

V. Facilitator

FIGURE 2: OPENADR DIRECT2 SCENARIO


SCENARIO


SCENARIO



17 | 46

The facilitator is an intermediary party that usually works

on behalf of the Resource Party (Prosumer). In this case

the Resource Party settles the Demand Response

enrolment. Regarding the VEN, it is usually installed in

the cloud, which is the Facilitator Intermediary

Infrastructure. This Facilitator offers a SaaS to the

Resource Party. It has been designed for industrial

control intermediaries, ESCOs, cloud-based appliance

and device management systems, and vendors that

manage the facilities for large commercial chains.

VI. Aggregator

In this situation, all the assets are aggregated or

gathered in on a Resource which is the Aggregator

Party. All the actions pass through the Aggregator.

FIGURE 5: OPENADR FACILITATOR

SCENARIO

FIGURE 6: OPENADR AGGREGATOR

SCENARIO



18 | 46

2.1.3 OPENADR DEPLOYMENT SCENARIOS AND DEMAND RESPONSE

PROGRAMS

According to OpenADR different scenarios can be linked to different Demand Response

programs. The following table shows the relationship between the scenarios and the programs:

TABLE 4: OPENADR DEPLOYMENT SCENARIOS FOR DIFFERENT DEMAND RESPONSE PROGRAMS



19 | 46

2.1.4 OPENADR AND USEF

OpenADR is an open and standardized way for electricity providers and system operators to

communicate DR signals with each other and with their customers, using a common language

while USEF delivers the integrated market structure, the tools and rules for commoditization and

trading of flexible energy use, as well as a universal framework to accommodate and monetize

DR.

Both, OpenADR and USEF have been collaborating since November 2015. Together they have

developed and added a USEF deployment scenario and three new Demand Response program

templates to standardize the use of OpenADR within the USEF framework.

2.1.4.1 OPENADR AND USEF DEPLOYMENT SCENARIO

• Demand Side Infrastructure: a flexibility resource is linked to the Resource Party or

Prosumer in this section. Each Active Demand & Supply (ADS) resource is linked to a Virtual

End Point (VEN) and the total is enrolled into the Demand Response programs managed by

the Aggregator.

• Aggregator infrastructure: it is the infrastructure where all the flexibility information is

gathered through the Virtual Top Node (VTN). The Aggregator is responsible for this section

and must hold agreements with Prosumers or Resource Parties, TSOs, DSOs, and BRPs. It

is also sharing communication with the TSO, DSO and BRPs to provide the requested

flexibility to the system.

• BRP, DSO and TSO infrastructure: this block requests flexibility from the aggregator when

needed.

FIGURE 7: OPENADR AND USEF DEPLOYMENT SCENARIO



20 | 46

2.1.4.2 INCENTIVE-BASED PROGRAM

It was created to encourage consumption or production changes during periods of high wholesale

prices or grid contingencies by imposing a rate or price for a certain period (days or hours).

2.1.4.3 TRANSACTION-BASED PROGRAM

The transactions occur between the Aggregator and the Prosumer (Resource Party). The

Prosumer is rewarded for flexibility delivery or penalized if not.

2.1.4.4 OVERRIDE PROGRAM

The Aggregator controls the devices or connection capacities to activate flexibility. It is a control

between the Aggregator and the Prosumer.

2.2 LORAWAN

LoRaWAN™ is a Low Power Wide Area Network (LPWAN) determination proposed for remote

battery worked Things in a local, national or worldwide system [5]. The Aggregator Activity is

using this IoT protocol for Demand Response purposes. LoRaWAN targets key necessities of

Internet of Things, for example, secure bi-directional correspondence, portability and confinement

administrations. The LoRaWAN detail gives consistent interoperability among shrewd Things

without the need of complex neighbourhood establishments and gives back the flexibility to the

client, designer, organizations empowering the take-off of Internet of Things.

LoRaWAN organize engineering is commonly laid out in a star-of-stars topology in which

passages is a straightforward scaffold transferring messages between end-gadgets and a focal

system server in the backend. Doors are associated with the system server by means of standard

IP associations while end-gadgets utilize single-bounce remote correspondence to one or

numerous passages. All end-point correspondence is for the most part bi-directional, additionally

bolsters operation, for example, multicast empowering programming overhaul over the air or

different mass dispersion messages to diminish the on air correspondence time.

Correspondence between end-gadgets and portals is spread out on various recurrence channels

and information rates. The choice of the information rate is an exchange off between

correspondence range and message term. Because of the spread range innovation, interchanges

with various information rates do not meddle with each other and make an arrangement of "virtual"

channels expanding the limit of the entryway. LoRaWAN information rates extend from 0.3 kbps

to 50 kbps. To augment both battery life of the end-gadgets and general system limit, the

LoRaWAN organize server is dealing with the information rate and RF yield for each end-gadget

separately by method for a versatile information rate (ADR) conspire.



21 | 46

National wide systems focusing on web of things, for example, basic framework, classified

individual information or basic capacities for the general public has an exceptional requirement

for secure correspondence. This has been settled by a few layer of encryption:

• One of a kind Network key (EUI64) and guarantee security on system level

• One of a kind Application key (EUI64) guarantee end to end security on application level

• Gadget particular key (EUI128)

LoRaWAN has a few distinct classes of end-guide gadgets toward address the diverse needs

reflected in the extensive variety of utilizations:

• Bi-directional end-gadgets (Class A): End-gadgets of Class A consider bi-directional

correspondences whereby each end-gadget's uplink transmission is trailed by two short

downlink get windows. The transmission space planned by the end-gadget depends all

alone correspondence needs with a little variety in view of an irregular time premise

(ALOHA-kind of convention). This Class An operation is the most minimal power end-gadget

framework for applications that lone require downlink correspondence from the server not

long after the end-gadget has sent an uplink transmission. Downlink interchanges from the

server at whatever other time should hold up until the following planned uplink.

• Bi-directional end-gadgets with booked get spaces (Class B): notwithstanding the Class

An arbitrary get windows, Class B gadgets open additional get windows at planned

circumstances. All together for the End-gadget to open its get window at the booked time it

gets a period synchronized Beacon from the passage. This permits the server to know when

the end-gadget is tuning in.

• Bi-directional end-gadgets with maximal get openings (Class C): End-gadgets of Class

C have almost consistently open get windows, just shut when transmitting.

FIGURE 8: LORAWAN GENERAL ARCHITECTURE

Figure 8 shows a general LoRa schematics while Figure 9 has a greater level of accuracy

considering the internal communication between the LoRa elements.



22 | 46

FIGURE 9: LORAWAN EXAMPLE ARCHITECTURE

2.3 OBIX

oBIX (OASIS Open Building Information eXchange Technical Committee) is an industry-wide

initiative to define XML- and Web services-based mechanisms for building control systems. oBIX

will instrument the control systems for the enterprise and can be used for such applications as

Demand Response since it is bidirectional.

The purpose of the OASIS Open Building Information Exchange (oBIX) TC is to define a standard

web services protocol to enable communications between building mechanical and electrical

systems, and enterprise applications. This protocol will enable facilities and their operations to be

managed as full participants in knowledge-based businesses. In the case of Demand Response,

it will enable the communication to send ADS information and receive set points which need to

be delivered to each ADS through a gateway in most of the cases.

The oBIX specification will utilize web services for exchange of information with the mechanical

and electrical systems in commercial buildings. Consequently, it is the connection protocol

between the cloud level and the building.

Presently most mechanical and electrical systems are provided with embedded digital controls

(DDC). Most of these devices are low cost and not enabled for TCP/IP. They are installed with

dedicated communications wiring. Larger DDC controllers provide network communications for

these dedicated controllers. There are several well established binary protocols (BACnet,

LonTalk, Modbus, DALI, etc.) that are used on these dedicated networks in addition to numerous

proprietary protocols. While these binary protocols can be used over TCP/IP networks - they have

challenges with routers, firewalls, security, and compatibility with other network applications.

There is an added challenge in that the industry is split between several largely incompatible

protocols.

Because oBIX integrates with the enterprise, it will enable mechanical and electrical control

systems to provide continuous visibility of operational status and performance, flagging problems

and assuring effective Demand Response actions.



23 | 46

oBIX provides a technology that enables facilities operators, owners and tenants to make

decisions based on a fully integrated consideration of all life-cycle, environmental, cost, and

performance factors.

The scope of the oBIX TC is to develop a publicly available web services interface specification

that can be used to obtain data in a simple and secure manner from HVAC, access control,

utilities, and other building automation systems, and to provide data exchange between facility

systems and enterprise applications. In addition, the TC will develop implementation guidelines,

as needed, to facilitate the development of products that use the web service interface. Work

outside of the above will be considered out of scope for the TC.

oBIX is unique since it is binding agnostic. Not

only is there a SOAP binding so oBIX can

interoperate with WS-* (the Web services stack),

there is an HTTP binding making oBIX a

RESTful standard. REST, or Representational

State Transfer, is the architectural style of the

World Wide Web. While not a standard itself, it

is best described as the set of standards that

make the web successful. HTTP, URL, XML

and HTML are some of those standards. oBIX

is built upon these standards; it identifies objects

with URLs, represents object state with XML,

and transfers objects using the Hyper Text

Transfer Protocol (HTTP is the mechanism for

transferring web pages). oBIX servers can be

accessed with a web browser and therefore can

be indexed by search engines, linked to by other

web pages and basically interoperate with any other mainstream web technology.

There is another similar standard to oBIX called BACnet/WS (Building Automation and Control

Network – Web Services). According to [6], oBIX is of particular interest due to its extensible data

model compared with BACnet/WS.

2.4 DEMAND RESPONSE FUNCTIONAL REQUIREMENTS:

USEF

To set a clear Demand Response scenario it has been decided to follow the framework proposed

by USEF. USEF stands for the Universal Smart Energy Framework developed by the USEF

Foundation. It has been developed to interconnect innovative services and propositions in a

uniform way with new technologies that are introduced into the electric market.

Currently, the grid configuration has been changing since power flows in different directions and

not in one as it was. Before, electricity was generated at large scale power plants and it was

transmitted through the transmission and distribution lines to the consumption points.

Nevertheless, with the introduction of more distributed energy systems, consumers can inject

FIGURE 10: OBIX ARCHITECTURE



24 | 46

electricity into the grid and they have become Prosumers. The new paradigm has changed the

electricity market scenario and USEF has proposed a set of roles to deal with it.

The proposed ICT architecture by USEF provides a coherent set of functional building blocks of

the system and a minimal set of specifications for the functionality within, and the interaction

between the building blocks, including a logical description of the interfaces.

The introduction of smart grids is accompanied with an explosion of captured energy data,

potentially providing a source of valuable information. Nonetheless, valorisation strongly depends

on the trust and security of the system that are easily undermined by the weakest link of the

system. USEF is therefore designed with privacy & security in mind.

2.4.1 USEF ROLES

The proposed market actors or the roles for USEF:

• Producer: Central generators functions are to generate electrical energy,

contribute with inertia to ensure sufficient frequency quality (since a

higher inertia will yield a slower frequency change) and provide ancillary

services to ensure the system stability.

• Transmission system operator (TSO): the TSO is responsible for the

balance between load and generation in the transmission power grid. The

TSO also reports the transmission capacity to the market operator so that

the market auctions and clearance do not violate any transmission

constraints. The TSO operates the grid in real time and based on the

frequency deviation, balancing power is activated.

• Distribution system operator (DSO): The DSO oversees distributing

the electricity to the load, and ensures that the required grid capacity is

available to perform this service properly with the expected level of

quality. The DSO could be responsible for the metering consumption

and/or production of a certain grid, and afterwards it would send this

information to the pertinent actor.

• Supplier: The main task of a supplier is to provide clients with electricity.

To do this, they acquire the electricity from traders and/or generators, and

then they sign wholesale agreements with their clients. So that, the

supplier is responsible for sourcing, supplying, and invoicing energy to its

customers. The supplier has obligations when supplying clients with

electricity and for each supplier there must be a balance responsible

party (BRP).

• Balance responsible party (BRP): The balance responsible party

receives the generation schedule plan; the demand forecast and with this

information resolves any unbalance between them. After operation, the



25 | 46

BRP collects meter data from the suppliers and generators and then

invoices the energy balance of the suppliers and generators.

• Aggregator: Not all buildings can take advantage of demand response

programs because their curtailment volume (measured in kWh, kW) does

not meet minimum load requirements. Therefore, aggregators’ task is to

accumulate flexibility from different prosumers. Buildings that could not

otherwise participate can now reap the benefits of load response

programs through an approved aggregator. Third-party aggregators

enlist end users to participate in demand response curtailment and sell

the combined load reduction to utilities and TSOs.

• Prosumer: the role of the consumer is transformed into prosumer since

residential end users and small and medium-sized enterprises (SMEs)

become energy generators due to resources such as their own

distributed energy systems. Besides, they can provide their flexibility for

Demand Response purposes while optimizing their energy efficiency

performance. Not all consumers are expected to transform in prosumers,

but to simplify the role model, traditional consumers may be considered

as prosumers who consume but do not produce energy.

• Energy Service Company (ESCo): USEF differentiates between an

Aggregator and an ESCo. It offers auxiliary energy-related services but it

is not directly active in the Demand Response scenario. However, it can

provide insight and management services.

• Active Demand & Supply (ADS): this is a different kind of role inside

the Demand Response scenario since it refers to energy-consuming or

producing appliances that can increase, decrease, or shift their energy

consumption or production. ADS unleashes the potential flexibility for

Demand Response mechanisms.



26 | 46

2.4.2 USEF INTERACTIONS

The following table summarizes the proposed interactions within the USEF framework.

TABLE 5: USEF INTERACTIONS SUMMARY

Interacting roles Interaction Description

Supplier Prosumer Contract • 3rd parties may operate with Supplier’s

permission

• Supplier is the main responsible

• DR operation conditions settled

Supplier Aggregator Contract • One contract per Prosumer serviced by

Aggregator

• DR operation conditions settled

Aggregator ADS Control • Demand forecasting

• Supply profiles to optimize the flexibility

Prosumer ADS Settings • Different levels of flexibility

BRP Supplier Contract • Commercial conditions for energy

demand/supply sourced by the BRP

• BRP and Supplier are the same in some

countries

BRP Aggregator Agreement • Optimize their portfolios

• Imbalance compensation mechanism

definition in some countries

BRP Producer Contract • BRP portfolio optimization

• Generation definition for the next period

• Dispatch power plant

TSO BRP Validation • TSO validates the BRP’s E-program

• BRP enables flexibility on the Imbalance

market

TSO DSO Validation • TSO validates T-program

• Transport energy

DSO Supplier Agreement • Define conditions for Aggregator-DSO

agreement

• Distribute energy

• Capacity Management

DSO Prosumer Validation • DSO validates D-program

• Distribute energy



27 | 46

DSO Aggregator • Provide flexibility to the DSO

o Activation of flexibility options

o Procure flexibility on a local

market

• Capacity Management

ESCo ADS Control • Optional

• ESCOs retrieve data from the ADS

• Control ADS

ESCo Prosumer Agreement • Optional

• Insight services to the Prosumers

• Enable Prosumers’ flexibility

• Ancillary services

2.5 WRAP-UP

In this subsection, a brief conclusion is written after presenting the main communication

technologies for DR that could be applied to residential sector.

First of all, due its characteristics, it can be stated the oBIX and LoRa are protocols more related

to the field level. This means that they are more interesting for IoT solutions or in a lower level to

gather data. In RESPOND project, these protocols are defined by Energomonitor and Develco,

and later MQTT is used for the common data sharing.

On the other hand, OpenADR along with USEF framework are widely spread methodologies

already used by more than one aggregator, so that it is more likely that future organizations move

towards these protocols.



28 | 46

3. RESPOND THIRD PARTY SERVICES ADAPTERS

3.1 SMART GRID SERVICE PROVIDER

From DEXMAs’ point of view, considering the above explained USEF framework, there is a gap

in the overall architecture that RESPOND platform could fulfil. In this position, the platform would

interact with three main USEF roles: i) aggregators, ii) ESCOs, and iii) Prosumers

FIGURE 11: SMART GRID SERVICE PROVIDER

On the proposed approach, the RESPOND platform would interact between the Energy Service

Companies and the end user for residential environments, while allowing other third parties such

as aggregators, to track events and the energy consumption.

In order to be able to fill this gap, the platform should be able to perform the following actions

properly:

• Set capacity scenarios

• Measure and monitor

• Send DR orders

• Acknowledge DR orders

• Track DR events

On RESPOND project some of the actions will be implemented in the platform and other will be

emulated in order to be further developed and improved during the exploitation stage of the

project.

Set capacity scenarios:



29 | 46

It is probable that in further stages of RESPOND, aggregators and ESCOs will have different

kinds of contracts to define their commercial relation. These contracts will include the DR

commitments that must be followed by the communities using the RESPOND platform.

The Analytical Services will be in charge of calculating the best opportunities for the monitored

facilities according to historic and forecasted data (energy and environmental) and data that

aggregators or ESCOS provide to the platform, which will depend on these DR contracts.

Main parameters required from these contracts in order to do the calculations are:

• Capacity commitment for community

• Number of DR activations per period

• Time response flexibility to achieve the capacity

• Minimum activation time

• Maximum activation time

However, as this information is still not defined for residential sector, future conversations with

external parties will be hold to fine tune the settings available for these agents. By now, the setting

will be included in Analytical Services backend to emulate different use cases.

Measure and monitoring:

Measure and monitoring are required for the external parties to validate if the contract

commitments have been achieved or not.

For measure and monitoring RESPOND project has already implemented different solutions. As

a main data base, with all energy and environmental (temperature & humidity) data and metadata

regarding the buildings, DEXMA has configured a RESPOND account on DEXCell Energy

Management System (as it can be seen in Deliverables D2.5 [1] and D5.4 [2]). The information

can be displayed on the same platform or retrieved thorough Dexma API (following the security

measures). Also, for Analytical Services to work properly, an InfluxDB is hosted in PUPIN. This

data base can also be used as a backup.

Send DR orders:

In order to meet the contract and aggregator requirements, the DR actions should be carried out

automatically or semi-automatically (meaning the user has to allow each action). The DR orders

will be generated in the Analytical Services module and displayed to the final user on the Mobile

App.

Acknowledge DR orders:

The aim of the acknowledge DR orders is to validate if the system has already carried out the DR

action. For the first approach of the project there is no expectancy of getting ack messages, since

it would require too much effort on standardization and development of the processes. Instead,

the DR events will be tracked and its impact will be assessed later, on the analysis stage.

Track DR Events:

Having historic DR event information will be very useful for the external parties as well as for

energy managers. This information will include what type of DR order was sent, when it was sent,



30 | 46

and to who. Combined with the monitoring, this will give insight of the compliance with the DR

contracts and will also allow to optimize them in future versions.

In Figure 12, we present a sequence diagram describing the flow of DR events through the

RESPOND platform. As we can see, the DR event is received from a third party provider

(aggregator/utility) and relayed through the MQTT message broker to other parts of the

RESPOND system:

• Data repository, to save it and make such information available to analytic services (e.g.

optimization),

• DexCell, where data related to DR event are stored in DexCell cloud platform and

displayed, e.g. overlayed on the energy consumption chart,

• Mobile application, where the information related to DR event can be shown in a form of

notification or displayed to the user via appropriate mobile application widget.

External service adapter

MQTT Broker DEXCell Mobile application

Aggregator/UtilitySends DR event

DR Action proposal

DR Action proposal

DR Action proposal

The proposed DR action is displayed

on an energy consumption chart

The proposed DR action is displayed

on a mobile application

Data repository

DR Action proposal

FIGURE 12: DR EVENT DATA FLOW

3.2 WEATHER DATA SERVICE PROVIDER

A backend application has been developed using CakePHP web development framework, with

the goal of querying the external weather service Weatherbit.io. The weather service provides

weather forecast for the following 16 days on daily precision, 48 hours in hourly precision and

current weather conditions for each hour. The data are fetched from the provided API endpoints

and saved in the MySQL database. A cronjob has been scheduled to fetch the data once a day

(for daily weather forecast) and hourly (for current weather observations and hourly weather

forecast). In Table 6, we provide the list of end points:



31 | 46

TABLE 6: WEATHER FORECAST API

Data URL

Current

weather

observatio

n:

"http://api.weatherbit.io/v2.0/current?key=".$KEY."&units=M&lat=".$LAT."&lon=".

$LON

Hourly

weather

forecast:

"https://api.weatherbit.io/v2.0/forecast/hourly?key=".$KEY."&units=M&lat=".$LAT.

"&lon=".$LON

Daily

weather

forecast:

"https://api.weatherbit.io/v2.0/forecast/daily?key=".$KEY."&units=M&lat=".$LAT."

&lon=".$LON

where $KEY is an API key used for authorization, issued by Weatherbit upon account registration,

whereas $LAT and $LON represent the latitude and longitude for the selected pilot location

(Madrid, Aarhus or Aran Islands).

An example of the response provided for Weatherbit API call is as follows:

{

"data":[

{

"wind_cdir":"NE",

"rh":59,

"pod":"d",

"lon":"-78.63861",

"pres":1006.6,

"timezone":"America\/New_York",

"ob_time":"2017-08-28 16:45",

"country_code":"US",

"clouds":75,

"vis":10,

"wind_spd":6.17,

"wind_cdir_full":"northeast",

"app_temp":24.25,

"state_code":"NC",

"ts":1503936000,

"h_angle":0,

"dewpt":15.65,

"weather":{

"icon":"c03d",

"code":"803",

"description":"Broken clouds"



32 | 46

},

"uv":2,

"aqi":45,

"station":"CMVN7",

"wind_dir":50,

"elev_angle":63,

"datetime":"2017-08-28:17",

"precip":0,

"ghi":444.4,

"dni":500,

"dhi":120,

"solar_rad":350,

"city_name":"Raleigh",

"sunrise":"10:44",

"sunset":"23:47",

"temp":24.19,

"lat":"35.7721",

"slp":1022.2

}

],

"count":1

}

Where the description of different fields in JSON object is as follows:

• count: Count of returned observations.

• data: o lat: Latitude (Degrees). o lon: Longitude (Degrees). o sunrise: Sunrise time (HH:MM). o sunset: Sunset time (HH:MM). o timezone: Local IANA Timezone. o station: Source station ID. o ob_time: Last observation time (YYYY-MM-DD HH:MM). o datetime: Current cycle hour (YYYY-MM-DD:HH). o ts: Last observation time (Unix timestamp). o city_name: City name. o country_code: Country abbreviation. o state_code: State abbreviation/code. o pres: Pressure (mb). o slp: Sea level pressure (mb). o wind_spd: Wind speed (Default m/s). o wind_dir: Wind direction (degrees). o wind_cdir: Abbreviated wind direction. o wind_cdir_full: Verbal wind direction. o temp: Temperature (default Celsius). o app_temp: Apparent/"Feels Like" temperature (default Celsius). o rh: Relative humidity (%). o dewpt: Dew point (default Celsius). o clouds: Cloud coverage (%). o pod: Part of the day (d = day / n = night). o weather: {



33 | 46

▪ icon: Weather icon code. ▪ code: Weather code. ▪ description: Text weather description.

o } o vis: Visibility (default KM). o precip: Liquid equivalent precipitation rate (default mm/hr). o snow: Snowfall (default mm/hr). o uv: UV Index (0-11+). o aqi: Air Quality Index [US - EPA standard 0 - +500] o dhi: Diffuse horizontal solar irradiance (W/m^2) [Clear Sky] o dni: Direct normal solar irradiance (W/m^2) [Clear Sky] o ghi: Global horizontal solar irradiance (W/m^2) [Clear Sky] o solar_rad: Estimated Solar Radiation (W/m^2). o elev_angle: Solar elevation angle (degrees). o h_angle: Solar hour angle (degrees).

As it has been previously said, the data are stored in a MySQL database which is configured as

a part of RESPOND cloud platform, where the tables responsible of storing such data are

presented in Figure 13.

WeatherLocation

idPK

latitude

longitude

city

WeatherObservation

idPK

weather_location_idFK

HourlyWeatherForecast

idPK


DailyWeatherForecast

idPK


FIGURE 13:DATABASE SCHEMA FOR WEATHERBIT.IO EXTERNAL WEATHER SERVICE

3.3 ENERGY PRICES SERVICE PROVIDER

Information regarding energy pricing is crucial in energy management systems and it allows

optimal scheduling of energy consumers by also considering the forecasted energy prices. Based

on this requirement of the RESPOND project, a custom API module has been developed, which

allows the energy providers for all pilot sites to input the current and future energy prices. This

information is stored once a day in a RESPOND platform’s central database, and it is made

available to other platform and external services via secure API. Currently, two end points have

been established, and they will be described in sequel.



34 | 46

API endpoint to save energy pricing

TABLE 7: API ENDPOINT TO SAVE ENERGY PRICING

Type of request POST

Url https://respond.imp.bg.ac.rs/daily_energy_prices/json_input_prices

Request header x-api-key: API_KEY

Content-Type: application/json

where API_KEY is a secret key known only to authorized developers

Request body A JSON array with the following elements:

weather_location_id: PILOT_ID

date: YYYY-MM-DD

hour_0: PRICE_0

hour_1: PRICE_1

….

hour_23: PRICE_23

Where weather_location_id is set to PILOT_ID, which is an integer

number standing for the pilot identifier (1-Ireland, 2-Denmark, 3-Spain).

date is the corresponding day formatted as described. Finally, hour_i

denotes the pricing from i-th to (i+1)th hour during that particular day.

An example of the request body is given as follows:

[{"weather_location_id":"3","date":"2019-05-

07","hour_0":"5.00","hour_1":"6.00","hour_2":"7.00","hour_3":"0.00","hour_4":"0.00", "hour_5":"0.00","hour_6":"0.00","hour_7":"0.00","hour_8":"0.00","hour_9":"0.00","hour

_10":"0.00","hour_11":"0.00","hour_12":"0.00",

"hour_13":"0.00","hour_14":"0.00","hour_15":"0.00","hour_16":"0.00","hour_17":"0.00",

"hour_18":"0.00","hour_19":"0.00","hour_20":"0.00",

"hour_21":"0.00","hour_22":"0.00","hour_23":"0.00"}]



35 | 46

API endpoint to fetch energy pricing

TABLE 8: API ENDPOINT TO FETCH ENERGY PRICING

Type of request GET

Url https://respond.imp.bg.ac.rs/daily_energy_prices/list_all/PILOT_ID,

where PILOT_ID denotes aforementioned pilot identifier (1-Ireland, 2-

Denmark, 3-Spain).

Request header x-api-key: API_KEY

where API_KEY is a secret key known only to authorized developers

Response body A JSON array with the following elements:

timestamp: Unix timestamp in miliseconds

measurementIndex: 1

measurementID: energy_price

deviceID: MADRID_MARKET_APP, DENMARK_MARKET_APP or

IRELAND_MARKET_APP

value: price of energy in EUR/MWh

The response body is in accordance with Canonical Data Model,

described in Deliverable D2.1 [3].

An example of the response received is given as follows:

[{"timestamp":1557187200000,"measurementIndex":1,"measurementID":"energy_price","devi

ceID":"DENMARK_MARKET_APP","value":"5.00"},{"timestamp":1557190800000,"measurementInd

ex":1,"measurementID":"energy_price","deviceID":"DENMARK_MARKET_APP","value":"6.00"},

{"timestamp":1557194400000,"measurementIndex":1,"measurementID":"energy_price","devic

eID":"DENMARK_MARKET_APP","value":"7.00"},{"timestamp":1557198000000,"measurementInde

x":1,"measurementID":"energy_price","deviceID":"DENMARK_MARKET_APP","value":"7.00"}]



36 | 46

4. RESPOND SERVICES OPEN API

The aim of this section is to describe an open API which will offer the services developed by

RESPOND consortium to other interested parties. Basically, each service will be run as a

separate software module which will have its own API (preferably REST based), with the definition

of inputs and outputs.

4.1 DR OPTIMIZATION SERVICE

DR optimization service is developed using Python programming language and deployed on

Apache OpenWhisk platform. OpenWhisk is an open source, distributed Serverless platform that

executes functions in response to events at any scale. OpenWhisk manages the infrastructure,

servers and scaling using Docker containers so that developers can focus on building efficient

applications.

The OpenWhisk platform supports a programming model in which developers write functional

logic (called Actions), in any supported programming language, that can be dynamically

scheduled and run in response (using Rules) to associated events (via Triggers) from external

sources (Feeds) or from HTTP requests. The project includes a REST API-based Command Line

Interface (CLI) along with other tooling to support packaging, catalogue services and many

popular container deployment options.

Figure 15 illustrates the relationship among the four OpenWhisk concepts.

FIGURE 14: OPENWHISK CONCEPTS (SOURCE: IBM CORPORATION)



37 | 46

To support different environments, OpenWhisk provides a generic REST API in Open-API

(formerly Swagger) format. Like all the REST APIs, various functionalities are accessed using

URLs as entry points. The generic format of the OpenWhisk entry point is:

https://{APIHOST}/api/v1/namespaces/{NAMESPACE}/{ENTITY}/...

where the names in curly braces are placeholders for specific values the user can specify. The

{APIHOST} is where the OpenWhisk installation is running. The namespace is a name that is

assigned and is used as a common prefix for a set of OpenWhisk entities. The REST API places

all the operations under the {NAMESPACE} because all the operations that refer to the {ENTITY}

are restricted to entities present only in that namespace. After the namespace, the entity can be

specified to operate with. Currently, the available entities are actions, triggers, rules, packages,

and activations. After the entity name, there are specific parameters for each entity. HTTP

methods (like GET, POST, PUT, and others) can be used operate on each entity, by providing a

JSON payload that is different for each entity.

All the capabilities in the system are available through a REST API. There are collection and entity

endpoints for actions, triggers, rules, packages, activations, and namespaces.

https://$APIHOST/api/v1/namespaces/{namespace}

https://$APIHOST/api/v1/namespaces/{namespace}/actions/[{packageName}/]{actionName}

https://$APIHOST/api/v1/namespaces/{namespace}/triggers/{triggerName}

https://$APIHOST/api/v1/namespaces/{namespace}/rules/{ruleName}

https://$APIHOST/api/v1/namespaces/{namespace}/packages/{packageName}

https://$APIHOST/api/v1/namespaces/{namespace}/activations/{activationName}

The namespace and activation endpoints support only GET requests. The actions, triggers, rules,

and packages endpoints support GET, PUT, and DELETE requests. The endpoints of actions,

triggers, and rules also support POST requests, which are used to invoke actions and triggers

and enable or disable rules.

The easiest way to enable an OpenWhisk action to be accessible via REST interface is to create

it as a web action by providing the --web flag with a value of true or yes, executing wsk command:

wsk -i action create RespondDROptimization --docker

dpaun/respond_dr_optimization_runtime

/home/respondservice/DROptimization/droptimization.zip –-web true

A web action can be invoked using a URL that is structured as follows:

https://{APIHOST}/api/v1/web/{QUALIFIED ACTION NAME}.{EXT}

The fully qualified name of an action consists of three parts: the namespace, the package name,

and the action name. The last part of the URI, the extension, is the desired content type of the

request. It is typically .http although other values are permitted, such as .json, .html, .svg or .text.

For convenience, the .http extension is assumed when no extension is detected.

Web Actions broadly provide the following features:

• A public, anonymous URL for invoking the action.



38 | 46

• A way to return more than just plain JSON data. Web Actions can return headers, headers

and data, and non-JSON data, such as HTML and binary data. The ability to return headers

is crucial for client-side web applications.

• Actions invoked as web actions also get access to request information about how they

were invoked. This includes request headers, CGI query string and path information, and

the raw body of the request.

• A way to modify their behaviour depending on how they are called. For example, by

manipulating the URL, a user can ask for a portion of the data returned instead of the entire

set.

• Finally, web actions with default parameters are considered protected, which means that

they are still considered a parameter but can’t be overridden by the user calling the action.

Essentially, they are “read-only” parameters that can’t be changed.

By default, a web action can be invoked by anyone having the web action's invocation URL. The

require-whisk-auth web action annotation needs to be used to secure the web action. When the

require-whisk-auth annotation is set to true, the action will authenticate the invocation request's

Basic Authorization credentials to confirm they represent a valid OpenWhisk identity.

The parameters which can be used when invoking an action are shown in the following table:

TABLE 9: THE LIST OF PARAMETERS WHICH CAN BE USED WHEN INVOKING AN ACTION

Name Description

blocking string (query)

Blocking or non-blocking invocation Default is non-blocking

Result string (query)

Return only the result of a blocking activation Default is false

timeout integer (query)

Wait no more than specified duration in milliseconds for a blocking response Default value and max allowed timeout are 60000

Payload object (body)

The parameters for the action being invoked Content type: JSON

namespace string (path, required)

The entity namespace

packageName string (path, required)

Name of package that contains action

actionName string (path, required)

Name of action to fetch

Different types responses which can be received when invoking web actions are shown below:

TABLE 10: TYPES OF RESPONSES RECEIVED WHEN INVOKING WEB ACTIONS

Code Description



39 | 46

200

Successful activation

202

Accepted activation request { "activationId": "string" }

401 Unauthorized request { "error": "string", "code": "string" }

403 Unauthorized request { "error": "string", "code": "string" }

404 Item not found { "error": "string", "code": "string" }

408 Request timed out

429 Too many requests in a given time period

500 Server error { "error": "string", "code": "string" }

502 Activation produced an application error

DR optimization service exchanges the data using JSON format, which is delivered in the body

of a HTTP POST request. The Listing 1 below shows the template, representing input data.

{"Version": "_version",

"Parameters": [

{"Name": "_paramName", "Type": "_paramType", "Subtype": "_paramSubType",

"Timestamp": "_paramTimestamp", "Value":"_paramValue", "Description": "_paramDesc"},

…}

]

}

LISTING 1: JSON TEMPLATE FOR INPUT DATA FOR DR OPTIMIZATION SERVICE

This JSON object contains the following data:

• Version: Defining the JSON template version.

• Parameters: The set of data to be exchanged (assuming horizon of 24h with 1h resolution

hence 24 samples of each relevant variable are considered)

o arbitrary indicator of which pilot model is to be optimized (could be integer, string,

etc. denoting which predefined topology is used)



40 | 46

o forecasted demand curve (arrays of 24 non-negative float values, one array for

each load type, i.e. electric, thermal, heating, etc.)

o forecasted renewable generation availability i.e. PV production, STC production,

etc. (arrays of 24 non-negative float values, one array for each renewable

generation type if multiple are present)

o (optional) criterion function/energy carrier pricing (arrays of 24 non-negative float

values, one array for each load type)

o (optional) demand response (DR) event indicators (arrays of 24 boolean values

denoting whether or not the DR event is active for a given load type at a given

time, one array for each load type)

o (optional) requested load profile (arrays of 24 non-negative values defining the

required power in case a DR event is active at a given time, one array for each

load type)

JSON format is also used to exchange the service output data, in which case it delivers results of

the optimization, the optimal load curve (arrays of 24 non-negative float values, one array for each

load type).

4.2 ENERGY CONSUMPTION FORECAST SERVICE

The predictive models for the energy consumption forecasting are developed in R, and therefore,

they are executed in an Rserve server1. Rserve is a TCP/IP server which allows other programs

to use facilities of R from various languages without the need to initialize R or link

against R library. However, due to RESPOND’s approach, these models could be developed in

any other language including Python or Rapidminer. This is the rationale behind RESPOND’s

proposal for a generic approach to execute the energy consumption forecasting services, which

will be detached from the service’s underlying technology or language. To do so, it proposes the

design of a modular and multiplatform architecture for the exploitation of predictive models. Figure

15 depicts the proposed architecture for energy consumption forecasting service exploitation.

1 https://www.rforge.net/Rserve/

https://www.rforge.net/Rserve/



41 | 46

FIGURE 15: SYNCHRONOUS EXPLOITATION OF THE ENERGY CONSUMPTION FORECASTING MODELS

The synchronous and asynchronous data will be stored in their corresponding data storage

system. For example, sensor data will be stored in the InfluxDB Time Series Database, while the

building topological data will be stored in the Virtuoso RDF Store. The description of the process

for storing this data is considered to be out of the scope of this deliverable.

In order to make the system multiplatform, it is necessary to define an interface which can be, on

the one hand, implemented in different programming languages, and on the other, invoked

remotely. Taking into consideration its wide interoperability and performance, a REST service has

been chosen. Likewise, the exchange of data, will be made in JSON format. Namely, the JSON

template proposed for such an exchange of data is shown in Listing 2. Additionally, it is worth

mentioning that the invocation of the service is made by HTTP POST method, which will send the

mentioned JSON object.


"Processor": "_processor",

"Parameters": [



…}

]

}

LISTING 2: JSON TEMPLATE FOR DATA EXCHANGE



42 | 46

In this JSON payload, the following objects are defined:


• Processor: Defining the predictive model.

• Parameters: The set of data to be exchanged, including additional information such as the

name, the type and subtype, the timestamp, the value(s) and the description.

The proposed JSON element will be used to exchange data for various purposes. On the one

hand, this JSON will be used to pass the necessary inputs to a predictive model. Listing 3 shows

an excerpt of a JSON payload used as input for a predictive model forecasting the energy

consumption of a given air conditioner. The JSON specifies the predictive model

“./energyForecastingAirconditioner03” and a set of inputs including the type of day (e.g. working

or non-working day), the external temperature and the indoor temperature for the last two hours.

{"Version": "0.0.1",

"Processor": "./ energyForecastingAirconditioner03",

"Parameters": [

{"Name": "OutdoorTemperature", "Type": "array", "Subtype": "double", "Timestamp":

"2019-05-28", "Value": [26.965011500000006, 27.470008500000000], "Description":

"outdoorTemperaturedata"},

{"Name": "IndoorTemperature", "Type": "array", "Subtype": "double", "Timestamp":

"2019-05-28", "Value": [23.56, 23.12], "Description": "indoorTemperaturedata"},

{"Name": "WORKDAY", "Type": "array", "Subtype": "double", "Timestamp": "2019-05-28",

"Value": [1], "Description": "workingDayType"},

…

]

}

LISTING 3: JSON ELEMENT AS INPUT FOR AN ENERGY CONSUMPTION FORECASTING PREDICTIVE

MODEL.

On the other hand, the proposed JSON element will also serve to exchange the predictive model

output data. Listing 4 shows an excerpt of a JSON where the result of a predictive model is shown.

In this case, the estimated energy consumption of a given air conditioner in a given moment of

the future.

{"Version": "0.0.1",

"Parameters": [

{"Name": "PredictedEnergy", "Type": "array", "Subtype": "double", "Timestamp": "2019-

05-30", "Value": [298.2867], "Description": "outdoorTemperaturedata"}

]

}

LISTING 4: JSON ELEMENT AS OUTPUT FOR AN ENERGY CONSUMPTION FORECASTING PREDICTIVE

MODEL.



43 | 46

4.3 ENERGY PRODUCTION FORECAST SERVICE

The Energy production forecast service is developed using Python programming language and

deployed on Apache OpenWhisk platform in the same manner as the DR optimization service,

which is described in section 4.1. It uses OpenWhisk REST interface and exchanges the data

using JSON format, the most widely used data format for data interchange on the web. Service

invocations are made using HTTP POST methods. JSON object, carrying input data, is delivered

in the body of a request. The Listing 5 below shows the template, representing input data for the

Energy production forecast service.


"Model": "_model",

"Parameters": [



…}

]

}

LISTING 5: JSON TEMPLATE FOR INPUT DATA FOR ENERGY PRODUCTION FORECAST SERVICE



• Model: Defining the model to be used (PV forecaster, STC forecaster).

• Parameters: The set of data to be exchanged

o In case of PV forecaster:

▪ forecasted weather conditions for next 24h – humidity, wind speed and

direction, pressure, UV, temperature, cloud coverage and ghi (arrays of 24

float values, one array for each weather parameter)

o In case of STC forecaster:


direction, pressure, UV, temperature, cloud coverage, ghi, dhi, dni, dew

point, accumulated snowfall, accumulated precipitation (arrays of 24 float

values, one array for each weather parameter)

▪ production of the renewable source for previous 5 hours

Similarly to input data, JSON format is also used to exchange the service output data. This JSON

object contains the following data:

• In case of PV forecaster:

o forecasted production with horizon of 24h with 1h resolution (array of 24 float non-

negative samples)

• In case of STC forecaster:

o forecasted production with horizon of 24h with 1h resolution (array of 24 float non-

negative samples)



44 | 46

4.4 OPTIMIZED CONTROL SERVICE

The core model of the Optimized control service sits statistically in the application as an FMU

file. This contains the equations, libraries and solvers to run each building model, so no critical

dependencies or external firmware needs to be run. A Python programming language script and

the FMU will be deployed on Apache OpenWhisk platform in the same manner as the DR

optimization service, which is described in section 4.1. It uses OpenWhisk REST interface and

exchanges the data using JSON format, the most widely used data format for data interchange

on the web. Service invocations are made using HTTP POST methods. JSON object, carrying

input data, is delivered in the body of a request. The Listing 5 below shows the template,

representing input data for the Optimized control service.


"Model": "_model",

"Parameters": [



…}

]

}

LISTING 6: JSON TEMPLATE FOR INPUT DATA FOR ENERGY PRODUCTION FORECAST SERVICE



• Model: Defining the model to be used (Building1Aran, Building1Aarhus,…).

• Parameters: the set of input data to be exchanged

▪ Hourly optimal thermal energy demand profile per dwelling for the next day

(RESPOND Optimization service, string of 24 float values)

▪ Forecasted thermal energy demand profile per dwelling for the next day

(RESPOND Demand forecast service, string of 24 float values);


direction, pressure, UV, temperature, cloud coverage and ghi (arrays of 24

float values, one array for each weather parameter);

▪ Thermal comfort settings per hour/day/week used by the dwelling owner as

hard constraints for the service (focus group interview, static values);

Similarly to input data, JSON format is also used to exchange the service output data. This JSON

object contains the following data:

▪ Heating/cooling profile for the next 24h (arrays of 24 float values, one array

for on/off heating/cooling and one for indoor air temperature set point)



45 | 46

5. CONCLUSIONS

In this report, we have presented the results of Task 5.2, which aims to enable connectivity to

smart grid and external services and systems through an Open API. In such a way, RESPOND

will be able to exploit the data provided by smart grid and third-party services. Besides, the

proposed Open API will also be used to offer RESPOND analytic service capabilities to wider

community and developers. It is designed to ease the implementation and ensure easy market

uptake of the RESPOND platform and to attract different market players such as: energy

providers, consumers, industry etc.

Firstly, we presented the smart grid communication technologies. Next, we described different

adapters which are used to enable RESPOND’s connection to third party services such as smart

grid, weather data services and energy prices service providers. Finally, we provided the

specification of the RESPOND OpenAPI, and gave more details of its implementation in DR

optimization service, energy consumption forecast service, energy production forecast service

and optimized control service.



46 | 46

REFERENCES

RESPOND DOCUMENTS

[1]D2.5 Deployment of RESPOND cloud-based platform

[2]D5.4 Desktop dashboard and smart mobile client

[3]D2.1 RESPOND system reference architecture

EXTERNAL DOCUMENTS

[4]OpenADR 2.0 Demand Response Program Implementation Guide, [Online]. Available:

https://www.openadr.org/assets/openadr_drprogramguide_1_1.pdf

[5]Ducrot, N.; Ray, D.; Saadani, A.; Hersent, O.; Pop, Gabor; Remond, Guillaume; “LoRa Device

Developer Guide. Orange Connected Objects & Partnerships”; Orange; April 2016

[6]Matthias Neugschwandtner, Georg Neugshwandtner, and Wolfgang Kastner; “Web Services

in Building Automation: Mapping KNX to oBIX”; IEEE; 2007

https://www.openadr.org/assets/openadr_drprogramguide_1_1.pdf

Documents

D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICES Deliverables/RESPOND_Deliverable_D5... · 1. INTRODUCTION The goal of WP5 is to enable interoperability between different RESPOND