Post on 30-May-2020
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
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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 3: OPENADR DIRECT 3 SCENARIO _________________________________________________ 16
FIGURE 4: OPENADR DIRECT 4 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
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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.
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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:
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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
• Reduce energy costs
• CAPEX reduction
• Reduce energy costs
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
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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
• Reduce energy costs
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
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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
FIGURE 3: OPENADR DIRECT 3
SCENARIO
FIGURE 4: OPENADR DIRECT 4
SCENARIO
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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.
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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.
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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.
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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.
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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.
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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:
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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,
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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:
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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"
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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: {
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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
weather_location_idFK
DailyWeatherForecast
idPK
weather_location_idFK
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.
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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"}]
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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"}]
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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)
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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.
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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)
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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/
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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.
{"Version": "_version",
"Processor": "_processor",
"Parameters": [
{"Name": "_paramName", "Type": "_paramType", "Subtype": "_paramSubType",
"Timestamp": "_paramTimestamp", "Value":"_paramValue", "Description": "_paramDesc"},
…}
]
}
LISTING 2: JSON TEMPLATE FOR DATA EXCHANGE
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
42 | 46
In this JSON payload, the following objects are defined:
• Version: Defining the JSON template version.
• 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.
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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.
{"Version": "_version",
"Model": "_model",
"Parameters": [
{"Name": "_paramName", "Type": "_paramType", "Subtype": "_paramSubType",
"Timestamp": "_paramTimestamp", "Value":"_paramValue", "Description": "_paramDesc"},
…}
]
}
LISTING 5: JSON TEMPLATE FOR INPUT DATA FOR ENERGY PRODUCTION FORECAST SERVICE
This JSON object contains the following data:
• Version: Defining the JSON template version.
• 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:
▪ forecasted weather conditions for next 24h – humidity, wind speed and
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)
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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.
{"Version": "_version",
"Model": "_model",
"Parameters": [
{"Name": "_paramName", "Type": "_paramType", "Subtype": "_paramSubType",
"Timestamp": "_paramTimestamp", "Value":"_paramValue", "Description": "_paramDesc"},
…}
]
}
LISTING 6: JSON TEMPLATE FOR INPUT DATA FOR ENERGY PRODUCTION FORECAST SERVICE
This JSON object contains the following data:
• Version: Defining the JSON template version.
• 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);
▪ 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);
▪ 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)
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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.
WP5 SYSTEM INTEGRATION AND INTEROPERABILITY
D5.2 RESPOND CONNECTIVITY TO SMART GRID SERVICESDELIVERABLE D5.2 TEK REVIEW
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