An Energy Flexibility Framework on the Internet of
Things
Thibaut Le Guilly
1
, Laurynas Šikšnys
1
, Michele Albano
2
, Per D. Pedersen
3
,
Petr Stluka
4
, Luis L. Ferreira
2
, Arne Skou
1
, Torben Bach Pedersen
1
and Petur Olsen
1
1
Aalborg University, Department of Computer Science, Aalborg, Denmark
2
CISTER/INESC-TEC, ISEP, Porto, Portugal
3
Neogrid Technologies, Aalborg, Denmark
4
Honeywell ACS Global Labs, Prague, Czech Republic
Abstract. This paper presents a framework for management of flexible energy
loads in the context of the Internet of Things and the Smart Grid. The framework
takes place in the European project Arrowhead, and aims at taking advantage
of the flexibility (in time and power) of energy production and consumption of-
fered by sets of devices, appliances or buildings, to help at solving the issue of
fluctuating energy production of renewable energies. The underlying concepts
are explained, the actors involved in the framework, their incentives and interac-
tions are detailed, and a technical overview is provided. An implementation of
the framework is presented, as well as the expected results of the pilots.
1 Introduction
The Internet of Things (IoT) enlarges the Internet to physical objects, extending its
usage to various applications such as Smart Grids. Most of these objects are pervasive
and mainly interact with other Internet devices such as database servers, other objects or
services. With many connected objects
1
, using a variety of heterogeneous technologies
and protocols, managing their interconnection is a challenge.
Service Oriented Architectures (SOA) have been developed to abstract the speci-
ficity of devices and networks and obtain consistent access to functionalities provided
by the objects (e.g. [1]). In addition, a lot of effort has been put into filling the syntactic
and semantic gaps that exist between networks and applications [2, 3], as demonstrated
by the results of the European Connect project [4]. However, a remaining open issue is
how to create smooth interconnection between service providers and consumers in the
IoT. The Arrowhead project
2
aims at providing a solution to this issue, by developing
a framework [5] for IoT applications, including a set of essential services, namely:
– service discovery;
1
Cisco estimates the number of connected objects to reach 50 billion by 2020.
2
www.arrowhead.eu
Stluka P., Le Gully T., Å
˘
aikÅ ˛anys L., Pedersen P., Skou A., Pedersen T., Albano M., Ferreira L. and Olsen P.
An Energy Flexibility Framework on the Internet of Things.
DOI: 10.5220/0006163400170037
In The Success of European Projects using New Information and Communication Technologies (EPS Colmar 2015), pages 17-37
ISBN: 978-989-758-176-2
Copyright
c
 2015 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
17

Energy
Flexibility
Market
Efficient
Production
(manuf/
process)
Energy
Production
Smart
Buildings
Electro-
Mobility
Fig. 1. The five pilot domains of the Arrowhead project.
– authentication;
– authorization.
In fact, if service discovery is sufficient to establish connection between a ser-
vice consumer and provider, authorization is usually required, in particular for Cyber-
Physical Systems (CPS) involving critical components. This is the case in all the pilot
domains of the project, which cover the areas or production, electro-mobility, energy
production, smart buildings and an energy flexibility market (or flexibility market).
These five pilots provide a good sample of the diversity of applications that will be
provided by the IoT. As illustrated by Figure 1, the flexibility market is the common
denominator between the different pilots, and is expected to provide them its services.
This central position of the energy flexibility market illustrates well the fact that
energy will be an important application domain for the IoT, as the challenges that are
faced in this area are essential for the future of our society. A European Union direc-
tive from 2009 requires the EU countries to fulfill at least 20% of their overall energy
needs from renewable sources by 2020 [6]. More recently, Denmark has set a 50%
target by 2020 [7]. To attain these objectives, many European projects [8–10] aiming
at improving and understanding the production and consumption of electricity have
been conducted. Their ambition is to move the current electricity network, the grid, to
a Smart Grid equipped with smart meters and appliances providing measurement and
control capabilities [11].
A main issue with the increasing part of renewable energy sources such as solar
cells and wind turbines, is that production from renewable energy sources fluctuates
and is not available at all time. It is thus necessary to adjust the behavior of consumers
to adapt to the fluctuating production. Solutions to these issues are known as demand
response mechanisms [12], that provide incentives to end users to modify their con-
sumption behavior to better match the production. A common demand response mech-
anism is to increase the price in periods of high demand and low production, and reduce
it in periods of low demand or high production. Several European programs have been
devised and dynamic prices already exist in some countries [13, 14]. Another mecha-
nism, developed in the European project MIRABEL [15], uses the flexibility offered by
18
EPS Colmar 2015 2015 - The Success of European Projects using New Information and Communication Technologies
18

some devices and appliances. For example, a Heating, Ventilation and Air Conditioning
(HVAC) system can be set with a comfort temperature interval in which it can operate
to adjust its consumption pattern. This flexibility can be used to adapt consumption and
better match production, or to offload the grid in peak times. However, in order to make
use of this flexibility, there is a need for measuring, predicting, and planning consumed
and produced energy. We propose in this paper a framework for managing energy flex-
ibility based on so-called FlexOffers, from the end user to a flexibility market where it
is traded and assigned an optimal value. The objective is to enable actors of the energy
domain to buy flexibility and have more freedom in distributing loads in the grid. The
main contribution of this paper is to define the details of this framework, the different
actors, their possible interest and their relationships, and to present the underlying ICT
infrastructure enabling its deployment. Pilot demonstrations currently taking place in
the Arrowhead project are also presented to discuss the applicability of the framework.
The paper is organized as follows. The concept of flexibility and FlexOffer are pre-
sented in Section 2. The framework, the actors that compose it and their interactions are
detailed in Section 3. An overview of the framework implementation architecture is pro-
vided in Section 4. Pilots are presented in Section 5. Finally, related work is discussed
in Section 6, and we conclude and discuss future work in Section 7.
2 FlexOffer Concept
This section introduces the concept of FlexOffer, that encodes necessary parameters
of flexible loads to facilitate their management. Generation and aggregation of such
FlexOffers are then discussed.
2.1 FlexOffer
The flexibility framework presented in this paper is based on the concept of FlexOffer.
As already mentioned, this concept was developed in the European MIRABEL project.
It provides a way to formally represent flexible energy loads in terms of time and energy,
and contains the information necessary to manage them. A visual representation of a
FlexOffer in one of its simplest forms is shown in Figure 2. The bars in this graph
represent a flexible consumption load from a component with flexible consumption
that we name Flexible Resource (FR). Each bar represents the consumption for a given
time slice. The lower area represents the minimum amount of energy the FR needs to
provide its service. The upper area represents an energy interval in which it can change
its consumption while ensuring predefined constraints (e.g. temperature comfort). The
amount of energy consumed at each slice can thus vary within the interval given by the
upper area. Flexibility in terms of energy amounts is referred to as energy flexibility.
Note that this simple FlexOffer contains only positive flexibility, but some FRs can
also contain negative one, representing flexibility in production. The second type of
flexibility is time flexibility, and typically occurs when a given load can be shifted in
time within a given interval, as illustrated in Figure 2. The time shift is constrained
by an earliest start, before which the load should not be assigned, and a latest end at
which it should have been consumed. A baseline is also assigned to each FlexOffer, that
19
An Energy Flexibility Framework on the Internet of Things
19

6 8 10 12 14 16 18
2
4
6
Start
Time
Latest
End
Earliest
Start
Time
Flexibility
Time
Flexibility
Time
Energy
Minimum Consumption Flexible Consumption Baseline/Schedule
Fig. 2. Example of a FlexOffer.
represents the default consumption plan that the associated FR will follow if it does not
receive any update. This baseline schedule can be updated to modify the consumption
pattern within the flexibility domain.
2.2 FlexOffer Generation
Generating sound FlexOffers for FRs is not trivial. For FRs that continuously consume
energy, such as heat pumps, FlexOffers are typically generated on an hourly or daily ba-
sis. Other FRs can emit FlexOffers when needed. Generating a FlexOffer with energy
flexibility for FRs implies predicting the consumption (or production) of an FR required
to satisfy a given set of constraints, as for example a comfort temperature interval. This
is most often done using a model of the FR, its environment including relevant pa-
rameters for the predictions such as temperature or solar radiation, and environmental
constraints such as comfort settings. Using the model, energy and time flexibility are es-
timated using various techniques, such as linear programming. Details about generating
FlexOffer at the device level can be found in [16].
2.3 FlexOffer Aggregation
FlexOffers most often do not represent large flexible loads. Thus, a single FlexOffer is
of little interest to balance energy loads on the grid, where required flexibility is much
higher. At the same time, managing large numbers of FlexOffers is tedious and com-
plex. A common solution to facilitate the management of energy loads is to aggregate
them. Similarly, FlexOffers can be aggregated into aggregated FlexOffers with larger
flexible energy loads. Once an aggregated FlexOffer is assigned a schedule, it needs to
20
EPS Colmar 2015 2015 - The Success of European Projects using New Information and Communication Technologies
20

Aggregation
Disaggregation
Aggregation
Disaggregation
Scheduling
Fig. 3. The workflow of FlexOffer aggregation and FlexOffer schedule disaggregation.
be disaggregated to assign a schedule to each FlexOffer it is composed of. Note that
aggregation can be performed multiple times, meaning that an aggregated FlexOffer
can contain smaller aggregated FlexOffers, as shown in Figure 3. In general, the flexi-
bility of an aggregated FlexOffer tends to be lower than the sum of the flexibility of the
FlexOffers that compose it. This reduction in energy flexibility is however unavoidable
to reduce the complexity of flexibility management and the scheduling problem. Note
also that aggregating flexible loads is a complex task. To optimize aggregation, Flex-
Offers can be grouped based on similarity of consumption pattern. More details about
aggregation and disaggregation of FlexOffers are provided in [17].
3 Flexibility Framework
An overview of the proposed framework is shown in Figure 4. This section describes
its details with the different actors, their interactions and provide examples.
3.1 Flexibility Market
Currently, grid actors trade electricity on existing traditional day-ahead (spot), intra-
day, and regulation energy markets. In this Arrowhead pilot, we also consider a so-
called flexibility market. It is based on a variation of the product-mix auction [18], in
which the commodities are flexible energy loads for specific geographical areas. This
model is designed to deal with the “product mix” problem, in which multiple varieties
of a product with different costs are supplied, but with a constraint on the total capac-
ity. Here the product is flexibility, and the varieties are positive and negative flexibility.
Each bidder can make one or more bids, and each bid contains a set of mutually exclu-
sive offers. Bids in the flexibility market are in fact mutually exclusive, since using both
negative and positive flexibility for a given geographical area would not make sense.
Two types of bids can be made, supply bids, offering flexibility, and demand bids re-
questing it. The auctioneer then selects the market clearing price that for each bid gives
bidders the greatest surplus. Offers with negative surplus are rejected. This is visualized
in Figure 5. In both graphs, a bid is represented by an horizontal segment. The length of
a segment determines the supplied or demanded flexibility amounts, while its position
on the Y axis shows the associated price. On the left side, “Up Bids” correspond to bids
21
An Energy Flexibility Framework on the Internet of Things
21

...
Flexible
Resource
Flexible
Resource
Flexible
Resource
Prosumer 1
Flexible
Resource
Flexible
Resource
Prosumer n
Aggregator 1
Aggregator k
...
Flexibility
Market
FlexOffers
Supply Bids
Demand Bids
BRPs
DSOs
Fig. 4. Overview of the flexibility framework.
for negative flexibility, while “Down Bids” are for positive one. The market clearing
price is found at the intersection between demand and supply lines. Supply bids above
this line are rejected, similar to demand bids under it. All accepted bids are traded at
the market clearing price. In the current implementation of the market, clearing is per-
formed every 15 minutes, but could be adapted to match different needs.
3.2 End Consumer/Producer
The basic elements of the framework are FRs that produce and consume electricity,
giving the name prosumers to FR owners. A first example is a household, in which we
can identify a number of FRs. The Heating, Ventilation and Air Conditioning (HVAC)
system is a first important one. If a user agrees to let such systems be controlled flex-
ibly, meaning setting intervals for the different comfort settings, it is possible to gen-
erate useful FlexOffers from them. Generating FlexOffers from this type of system is
the objective of one of the pilots of the Arrowhead project, which will be discussed
in Section 5.1. Similarly, fridges and freezers can be operated in a given interval to
offer flexibility. Another type of system that can offer flexibility is an appliance such
as a washing machine, tumble dryer or dishwasher. In general, such appliances fol-
low a fixed consumption pattern, that could thus only be shifted in time. This could
be achieved by asking users to specify an interval during which they should operate,
or a deadline by which a given operation should be terminated. However, at the mo-
ment, few of these appliances provide remote control capabilities, making it difficult to
explore the applicability and acceptance from users.
22
EPS Colmar 2015 2015 - The Success of European Projects using New Information and Communication Technologies
22

0 20 40 60
0.08
0.1
0.12
0.14
0.16
0.18
Quantity kW h
P rice DKK/kW h
Up Bids
0 20 40
0.05
0.1
0.15
0.2
0.25
Quantity kW h
P rice DKK/kW h
Down Bids
Supply Demand
Fig. 5. Visualization of market clearing price.
Electric cars are also interesting, since their numbers is expected to increase in the
near future. In fact, they can be charged in a very flexible manner, and can even be used
as storage facilities. In addition, they are a real issue for existing grid infrastructures that
in some cases will not support convoluted charges. It is also important that user con-
straints can be enforced, such as ensuring a minimal charge for emergency situations.
A pilot on this topic is expected to take place in the context of the Arrowhead project.
Nowadays, houses are getting more equipped with production units such as Photo-
Voltaic panels or wind turbines. These can be used to increase the flexibility offered by
equipped houses. These units thus provide negative flexibility. Combining information
from producing and consuming units makes it possible to generate FlexOffers with large
amounts of both positive (consumption) and negative (production) flexibility. Finally,
as local storage units are becoming more affordable, they could also be of interest to
the framework.
Another type of FRs are public buildings that are essentially equipped with similar
type of devices than houses, but with larger capacities, both in terms of production and
consumption. The project includes two pilots with buildings equipped with innovative
technologies that can be used to generate FlexOffers, and will be discussed in Section 5.
The last important type of prosumer are industrial actors. Industrial processes are in
fact using large amounts of energy for manufacturing goods. The consumption patterns
of these processes can in some cases be adjusted, by shifting production schedules
23
An Energy Flexibility Framework on the Internet of Things
23

or throughput. Industrial actors need to play an important role in the green transition,
and tools such as FlexOffers can facilitate their integration to the Smart Grid. In the
framework, only this type of prosumers are expected to participate in the flexibility
market. Smaller ones will interact with it through an Aggregator.
3.3 Aggregator
An aggregator is a business entity that makes money by aggregating FlexOffers from
several FRs and selling them on the flexibility market. It essentially acts as a Commer-
cial Virtual Power Plant (CVPP), providing load-shifting options and (near) real-time
control of many FRs on the energy market. As already mentioned, small Prosumers, as
for example a household, do not provide large enough flexible loads to be of interest
for a market. An Aggregator thus makes a contract with a number of these Prosumers,
giving it the right to control their FRs based on the FlexOffers they emit. In exchange,
it must reward the offered and used flexibility with a previously agreed price scheme.
We propose that the actual reward be calculated based on:
– The number of FlexOffers issued by a Prosumer;
– The amount of flexibility offered by the prosumer, both in time and energy amounts;
– The amount of flexibility used by the Aggregator to balance loads in the grid;
– Other parameters such as number of actual activations, accuracy with which sched-
ules are followed, etc.
Once a contract is agreed upon between an Aggregator and a Prosumer, the gener-
ation, aggregation and schedule of energy loads can start. The interaction between an
Aggregator and an FR is shown in Figure 3.3. When an FR sends a FlexOffer to an
Aggregator, the first step the Aggregator takes is to check for validity. Essentially this
means ensuring that the time intervals of the FlexOffer are consistent. It then decides,
based on the state of the grid and other parameters, if the FlexOffer is useful for its
needs. If it is, the Aggregator accepts it, notifies the FR and aggregates the received
FlexOffer with other ones, to produce one or more aggregated FlexOffers. During plan-
ning, the Aggregator can update the baseline of the FlexOffer by assigning it a schedule.
Scheduling can be performed multiple times to react to planning changes, up to a time
included in the FlexOffer. After this time, the FlexOffer is executed by the FR, meaning
that it consumes (or produces) electricity following the assigned schedule. The con-
sumption (or production) is measured to ensure that the schedule is respected by the
FR. In the billing phase (every month), the Aggregator computes all of its revenues,
losses and bills.
In the planning phase, an Aggregator uses the pool of aggregated FlexOffers to
generate bids for the flexibility market. For each aggregated FlexOffer, it sends one
supply bid with two offers. One for positive flexibility and one for negative. Recall that
among these two offers only one can be accepted. Winning offers result in assignments
of schedules to corresponding aggregated FlexOffer. The Aggregator can also trade
on other existing power markets (e.g., ELSPOT or ELBAS) and enter into bilateral
agreements with other parties such as Balance Responsible Parties. The Aggregator
business model is shown in Figure 6.
Aggregators can also be specialized based on the type of FRs they handle. As al-
ready mentioned, aggregation can be optimized by grouping similar FlexOffers.
24
EPS Colmar 2015 2015 - The Success of European Projects using New Information and Communication Technologies
24

Aggregator
Flexible Resource
Fig. 6. Aggregator business model.
3.4 Distribution System Operators
A Distribution System Operator (DSO), is responsible for operating, maintaining, and
when necessary developing the distribution system in a given area, delivering (and
possibly receiving) electricity to (from) end users. This is in contrast to a Transmis-
sion System Operator (TSO) that have similar responsibilities for the transmission sys-
tem, delivering electricity from large generation units to industrial consumers and local
transformers. In Denmark for example, DSOs operate under 65kV while TSOs operate
above.
The increasing number of energy consuming devices and appliances, including heat
pumps and electric cars, lead to an increase of the load on the distribution grid. The
addition of Distributed Energy Resources (DER) connected to it such as wind turbines
puts even more pressure on existing installations. However, most issues arise during
peak periods. To solve them, DSOs thus have two options:
– Strengthen the grid or
– Smoothen the load.
Strengthening the grid requires large investments from DSOs. Smoothening the load
is more cost effective and can be used in addition to strengthening the grid. The flexi-
bility market can be used by DSOs to that effect. They access the market by expressing
interest in flexibility for specific geographical areas in which they operate. For example
a DSO can emit a bid expressing interest in positive flexibility in a given area, to reduce
congestion points. The interaction between DSOs and the energy market is as follows.
Step 1. Forecast of the loads on the grid and identification of possible bottlenecks. The
baseline loads of Aggregators are queried and used to improve the accuracy of
forecasting and congestion detection.
25
An Energy Flexibility Framework on the Internet of Things
25

Step 2. During market opening time, for each bottle-neck point, a bid with several
offers is generated, with different demands for flexibility at different prices. Each
offer can for example represent a potential solution for a bottle-neck in the grid.
Step 3. If an offer is accepted, the DSO enters into an agreement with the wining party
(for example an Aggregator) to make use of its flexibility.
Step 4. The DSO updates the load forecasts to mirror the deviations of the winning
bids and re-computes bottle-necks.
Alternatively, or additionally, they can also make bilateral agreements with large pro-
sumers to exclusively handle their FlexOffers.
3.5 Balance Responsible Party
Balance Responsible Party (BRP) is a delegated role from a TSO to ensure balance in
the transmission grid, e.g. ensuring fitness between consumption and production. Today
this is done by trading on existing energy markets, based on expected production and
consumption. The main task of the BRP is to predict hourly energy flow up to 36 hours
ahead and trade electricity accordingly. However, with fluctuating energy sources like
wind turbines and PVs this is becoming more difficult. The interest from the BRP in a
flexibility market is to “buy” flexibility from industrial FRs and Aggregators to balance
power within their respective grid area. Interaction between BRPs and the market place
is similar to the DSOs interaction.
4 Software Architecture Overview
The flexibility framework introduced in the previous section, to be put in practice, is
supported by a number of software components and ICT solutions enabling information
exchange, FlexOffer generation, aggregation and control of FRs. These components are
implemented in Java, following a set of pre-defined interfaces. They are supported by
the Arrowhead core services, a set of management services designed to facilitate the de-
ployment of IoT applications. It aims at facilitating interconnection between systems of
different application domains (e.g.: industrial automation, airplane maintenance, energy
production, home automation, smart grids). The objective is to enable cross-domain
applications, among which energy is a central point. Figure 7 illustrates the different
system components as well and their interconnections, that will be described in this
section.
4.1 Arrowhead Framework
The Arrowhead core services facilitate interactions between the different systems im-
plementing the framework. The Service Registry service allows service providers to
advertise their services, and service consumers to look them up.
The Orchestration service allows to automatically connect a service provider to a
service consumer. This is based on a query from the latter, containing requirements
that the service should satisfy. The Orchestrator essentially performs a look up of the
26
EPS Colmar 2015 2015 - The Success of European Projects using New Information and Communication Technologies
26

Application Systems
AAA
Service
Registry
Orchestration
Core Systems
AggregatorResource
Lookup Aggregators
DNS-SD
HTTP/XMPP
FlexibleResource
DNS-SD
HTTP_XMPP
HTTP
HTTP
Obtain Aggregator
XMPP Network
Obtain Market
MarketResource
DNS-SD
HTTP_XMPP
HTTP
Register
F
l
e
x
O
ff
e
r
s
B
i
d
s
Register/Lookup
Authenticate
and Authorize
Fig. 7. Software architecture of the Virtual Market of Energy.
information stored in the Service Registry, to find the best service to satisfy a given
query. Note that orchestration can return a simple service (e.g.: an AggregatorResource
specialized into heat pumps) or a composed service (e.g.: a set of MarketResources to
be used in round robin, or at different time of the day).
The Authentication, Authorization and Accounting (AAA) service enables verifica-
tion of component identities, access control to functionalities and accountability mea-
sure in case of misuse. This is essential in the framework as malicious actions could
lead to damages to grid infrastructure. As an example, criminals could impact grid
operations by misbehaving in the framework, or taking financial benefit by claiming
dishonest information.
The Arrowhead core services were instrumental in easing the implementation of
the flexibility framework, and to ensure a good level of performance and security for
the interacting systems, by providing a Service Oriented platform to support all the
interactions for the functioning of the systems at hand.
4.2 Market Resource
The MarketResource component encapsulates functionalities of the flexibility market.
The architecture allows for multiple markets to be defined, which could correspond
to different geographical areas or type of flexibility traded. After authentication, the
27
An Energy Flexibility Framework on the Internet of Things
27

Fig. 8. FlexOffer visualization in an FR graphical user interface.
market makes its interface available to authorized bidders. It then conducts the auction
as already described in Section 3.1.
The current implementation of the Market Resource provides a graphical user in-
terface enabling its management and monitoring. It consists of a web application and
includes for example the visualization of market clearings shown in Figure 5.
4.3 Flexible Resource
As already mentioned, FRs are implemented in a software component of the same name.
The functionalities handled by the FR component are:
FlexOffer Generation. Sending FlexOffers to an Aggregator;
Consumption Management. Following assigned consumption schedule.
To enter the framework, an FR needs to authenticate to the AAA service, and be
an authorized entity. It can then look up an adequate Aggregator with respect to its
flexibility and geographical area using Service Registry or Orchestration services. The
returned information enables it to connect to an Aggregator, if authorized by this one.
This means that there exists an agreed contract between Aggregator and FR, as men-
tioned in Section 3.3.
The currently implemented FR components generally provide two user interfaces
(UIs), mostly through web applications. A first one is used to set configuration param-
eters for FRs, such as user constraints. Examples will be shown in Section 5. A second
UI is used to monitor flexibility of the system, and is common to all FRs. It contains for
example a visual representation of FlexOffers, illustrated by Figure 8, or information
on generated FlexOffers and rewards as shown in Table 1.
28
EPS Colmar 2015 2015 - The Success of European Projects using New Information and Communication Technologies
28

Table 1. Example of information about generated FlexOffer provided in FR graphical user inter-
faces.
Item Value Price
Number of FlexOffers 20
Fixed reward for providing flexibility 10 DKK
Total Time Flexibility 289 time units (15min.) 28.90 DKK
Total Energy Flexibility 409,137.63 Wh 40.91 DKK
Number of baseline updates 3 15 DKK
Used time flexibility 3 time units (15min.) 9 DKK
Used energy flexibility 10,232.91 Wh 21.44 DKK
4.4 Aggregator Resource
The Aggregator Resource component implements the functionalities offered by an Ag-
gregator. It acts as a service provider towards FRs, enabling them to submit generated
FlexOffers, informing them on their status, and sending back consumption schedules
when FRs baseline consumption patterns are modified through wining bids and disag-
gregation. After authenticating, it advertises its service to the Service Registry so that
it can be found by relevant FRs. If multiple markets are available, it can also use Or-
chestration or Service Registry to find the most relevant one for the flexibility it has to
offer. It also uses AAA services to ensure that only authorized FRs can connect to it.
Finally, Aggregators offer UIs similarly to FRs, offering visualization and management
of FlexOffers, contracts and price information.
4.5 Communication Infrastructure
Interaction between the different components is implemented using different approaches
based on communication requirements and component specificities.
Arrowhead Core Services are generally provided over the HTTP protocol. An exception
is the Service Discovery that uses DNS-based Service Discovery [19].
Web Interfaces are also provided by each component over HTTP. This makes it easy to
access them from any Web compatible device.
Framework Components communicate using HTTP over XMPP [20]. The reason for
this choice is that as HTTP is already used for communication with the Arrowhead core
services and web applications, reusing it for component communication enables reuse
of interfaces, and consistent error handling. However, HTTP makes it difficult to estab-
lish two way communications. This is often in houses of buildings where FRs are lo-
cated, due to Local Area Networks (LAN) and firewalls that prevent incoming connec-
tions to networked devices. Using XMPP as an underlying communication layer makes
this possible, in addition to enforcing communication encryption. In addition, XMPP is
being considered as a transport method for the second version of the Open Automated
Demand Response (OpenADR), and the ISO/IEC/IEEE 21451-1-4 [21] standards.
29
An Energy Flexibility Framework on the Internet of Things
29

Fig. 9. Screenshot of the application to set interval comfort temperature and obtain visualization
of corresponding reward.
5 Pilots
This section introduces three pilots of the Arrowhead project that are currently being
developed to explore the applicability of the flexibility framework in different use cases.
5.1 Heat Pumps
The first pilot consists of an individual control of heat pumps installed in occupied
residential houses. Each household is provided access to a web application through
an FR component, enabling setting of comfort temperatures and visualize associated
reward, as shown in Figure 9.
The idea behind the pilot is that a heat pump can be controlled flexibly both in time
and energy consumption, while ensuring user constraints such as comfortable tempera-
ture interval of the house. The process used in this pilot is as follows:
– Create a model which can predict the energy demand of the house;
– Calculate day-ahead the cheapest energy plan to secure comfort using spot-price;
– Every 15 minute issue a FlexOffer describing the options for decreasing/increasing
power consumption;
– Wait for an eventual FlexOffer schedule.
The data used for modelling are historical data for:
– Delivered heat in the house;
– Used energy for hot water;
– Indoor temperature;
– Power consumption of the heat pump;
– Weather data.
30
EPS Colmar 2015 2015 - The Success of European Projects using New Information and Communication Technologies
30

Fig. 10. Overview of the energy grids and resources in the UCEEB building.
Forecasting data are:
– The model;
– Weather forecast;
– User comfort criteria.
To apply assigned consumption schedules, heat pumps are operated via a relay, that
can be used to stop them. However, it is not possible to force a heat pump to run.
5.2 Load Management in a University Building
The second pilot is being implemented in the new building of the University Center
for Energy Efficient Buildings (UCEEB). It is located in B
˘
ust
˘
ehrad, a small town near
Prague, Czech Republic. The UCEEB building serves as a complex experimental plat-
form for all research fields related to the area of energy efficient buildings. It integrates
a variety of spaces, including open space office, smaller office rooms, large halls and
laboratories. It is also an experimental facility with multiple local energy sources inte-
grated into respective distribution grids. As shown in Figure 10, it includes three energy
grids, one for electricity, one for heat and one for cold. Energy resources include:
– two photo voltaic fields producing electricity (35 kWp and 12 kWp),
– a combined heat and power (CHP) unit producing heat and electricity,
– two charging stations for electric cars,
– storage units for heat and cold,
– two gas boilers, and
– two chillers.
31
An Energy Flexibility Framework on the Internet of Things
31

Prior to the implementation of the FlexOffer concept, a simulation study was con-
ducted to assess suitable scenarios, and determine how the building system could oper-
ate in combination with FlexOffers:
– Adjusting the HVAC system set points based on FlexOffers, ensuring the comfort
temperature while maximizing the economic benefit for supplying flexibility to the
market;
– Enable generation of FlexOffers by manipulating the temperature of hot and cold
water;
– Using strategies such as dynamic pre-cooling or pre-heating to increase the flexi-
bility of the HVAC system during periods of peak consumptions.
Following this study, several rooms with associated electric heaters and fan-coil
units were selected for the pilot implementation so that experimentation could be con-
ducted both during hot and cold seasons. An important part of the pilot is a software
application connected to the Building Management System (BMS) and a database con-
taining historical data. It is used by the building operator to control the process of Flex-
Offer generation. This human supervision is essential because specific adjustments of
HVAC system operations can potentially lead to uncomfortable situations for the occu-
pants of the building. The building operator is able to balance between comfort level
and economic benefits. When the operator interacts with the application, the following
functions are provided:
Precool: specifies a time interval in which pre-cooling of the building is allowed;
Duty Cycle: enforces a specified cycling pattern on the functioning of the HVAC sys-
tem, which can be used to provide flexibility;
Full Flexibility: leaves full control of the system to the flexibility framework for a
given time period, thus ignoring any comfort setting;
Adjust Set Points: allows manipulations of room temperatures in the building, but in
this case the flexibility is specified by the operator himself.
The objective of this pilot is to experiment with the application of FlexOffers in-
line with the existing control system of the building, to assess potential benefits and
application constraints. Some initial learnings are summarized here:
– The FlexOffer concept presents similarities with applications of Automated De-
mand Response (ADR) in commercial buildings. One possible difference is that
today ADR always triggers a firmly defined load shedding strategy, while FlexOf-
fers are assuming more degrees of freedom in building operation. For this reason it
seems important to have a human operator responsible for assessing of how much
flexibility may be offered under given conditions, and thus, supervising the overall
process of generating flex-offers.
– Operating the HVAC system flexibly implies compromising between maximizing
economic benefits and energy savings and overall comfort constraints in the build-
ing. For this reason only relatively short alterations of the default control strategy
are desirable. This applies primarily to the strategies related to duty cycling and
set point adjustments, which both should not span long time intervals. An example
of a load shedding strategy implemented using FlexOffers, lasting over 4 hours is
32
EPS Colmar 2015 2015 - The Success of European Projects using New Information and Communication Technologies
32

Fig. 11. User Interface used by building operators to specify flexibility parameters.
shown in Figure 12, which shows a systematic reduction compared to the estimated
baseline.
– The economic benefits of FlexOffers need to be further studied. A first reason is the
so-called rebound effect, already known from ADR projects. It occurs when occu-
pants temporarily increase their heating/cooling demands after the completion of
a schedule inducing reduction of comfort level to compensate the possibly experi-
enced discomfort. This can increase energy consumption and operational costs and
reduce the overall economic benefits. However, FlexOffers spanning an entire day,
with relational constraints between time slices, could be used in the optimization to
take into account such effects and help to determine their financial cost.
– Finally, it is important that building owners participating in the flexibility frame-
work receive enough incentives to maintain their interest.
5.3 PVCC
PhotoVoltaic Comfort Cooling (PVCC) is a Danish project that aims at combining tech-
nologies with an innovative energy management system to improve the current cooling
system of a bank building in Hadsund, Denmark. An overview of the setting is shown
in Figure 13. The system is composed of:
Photovoltaic Panels: (PVs) producing electricity from solar energy.
33
An Energy Flexibility Framework on the Internet of Things
33

Fig. 12. Example of load shedding implemented using FlexOffers compared to estimated base-
line.
A Heatpump: converting the electricity produced by PVs into cool air.
An Ice Bank: that can be used to store thermal energy in the form of ice.
A HVAC: used to control indoor climate.
A Controller: monitoring the different components and control energy production from
the PVs and consumption from the heat pump. Its objective is to ensure system sta-
bility and improve energy consumption while maintaining a comfortable climate
for building workers.
The controller receives information from the Danish Meteorological Institute to bet-
ter anticipate PV production, thermal changes and optimize energy consumption. It can
also receive external control commands from remote clients through the Internet. The
system has been deployed for more than a year, and has drastically improved the com-
fort level of the building. In fact, due to its outside being composed mainly of glass, the
sun heating it rapidly increased indoor temperature in summer. Due to the presence of
both consuming and producing components, as well as energy storage, this pilot is now
being investigated to generated interesting FlexOffers from it, that could be traded on
the flexibility market.
6 Related Work
There has been a number of projects exploring the use of flexible loads to solve bal-
ancing issues on the grid. Already mentionned, the MIRABEL project [15] introduced
the notion of FlexOffer reused in the presented framework. A similar flexibility market
has previously been proposed in the iPower project [22]. It provides an overview of the
possible interactions between DSOs and Aggregator, detailing their interaction process
using a market and contracts to ensure application of the assigned schedule. Here we
have provided a more general overview of the components and actors that constitute
our proposed framework. Our approach also differs by the use of the FlexOffer con-
cept, as well as the application and implementation of the product-mix auction in the
market. In addition, we have provided details about concrete implementations of an ICT
infrastructure enabling the deployment of such a market.
34
EPS Colmar 2015 2015 - The Success of European Projects using New Information and Communication Technologies
34

Heat
Pump
Ice
Storage
HVAC
Control
Weather Forecast
Solar Panels
Inverter
Remote Control
Via Internet
Fig. 13. Overview of the PVCC pilot.
Powermatcher [23] is also an auction based framework for energy balancing using
load shifting. FRs are referred to as device agents while Aggregators are referred to
as concentrators. It provides an open source library to implement the framework using
web sockets over HTTP for communication. Here the integration with the Arrowhead
core services and the use of XMPP aims at providing necessary services for facilitat-
ing interconnection of the components and security and accountability measures. The
CITIES project [24] explores energy flexibility at the city level, and has shown interest
in the presented framework.
There is in general active research in the area of energy flexibility. Neupane et al.
evaluate the value of flexibility on current regulation markets. Valsomatzis et al. [25]
discuss how to compare energy flexibility, a useful technique for managing FlexOffers
at the FR or Aggregator level.
Finally, a technical overview of the framework was presented in [8]. Here we have
presented a more general overview of the framework, and more details about the flexi-
bility market.
7 Conclusion and Future Work
In this chapter we have presented a framework to leverage flexible energy loads from
consuming and producing devices, aggregate them and make them available on a flexi-
bility market for interested parties. We have described the different actors of the frame-
work and detailed their interactions and interest in it. The software components and
ICT infrastructure enabling the deployment of the framework were also presented. This
includes interaction with the Arrowhead core services, that facilitate integration into the
Internet of Things. Finally, we have presented three pilots where the presented frame-
work is currently experimented, that provides a perspective of its possible application
in concrete scenarios.
35
An Energy Flexibility Framework on the Internet of Things
35

Further work will first consist in consolidating the framework, trying to converge
to a standardized approach to trading flexibility and finding synergies with similar ap-
proaches. This also includes the ongoing standardization process of the FlexOffer con-
cept, as well as in the interaction between the actors, in collaboration with industrial
partners to ensure feasibility of the approaches. The underlying ICT infrastructure is
still ongoing further development, with a goal to release an open implementation of the
framework providing all necessary services. Research in generation, aggregation and
improvement of the flexibility market is also expected to continue to increase flexibil-
ity offered by FRs and Aggregators, thus strengthening the interest of the framework.
Finally, the flexibility market will also be improved, both from a theoretical and appli-
cation point of view.
Acknowledgements. This research was supported by the European project Arrowhead.
References
1. Le Guilly, T., Olsen, P., Ravn, A., Rosenkilde, J., Skou, A.: Homeport: Middleware for
heterogeneous home automation networks. In: Pervasive Computing and Communications
Workshops (PERCOM Workshops), 2013 IEEE International Conference on. (2013) 627–
633
2. Issarny, V., Bennaceur, A., Bromberg, Y. D.: Middleware-layer connector synthesis: Beyond
state of the art in middleware interoperability. In Bernardo, M., Issarny, V., eds.: Formal
Methods for Eternal Networked Software Systems. Volume 6659 of Lecture Notes in Com-
puter Science. Springer Berlin Heidelberg (2011) 217–255
3. Blair, G. S., Paolucci, M., Grace, P., Georgantas, N.: Interoperability in complex distributed
systems. In Bernardo, M., Issarny, V., eds.: Formal Methods for Eternal Networked Software
Systems. Volume 6659 of Lecture Notes in Computer Science. Springer Berlin Heidelberg
(2011) 1–26
4. Issarny, V., Steffen, B., Jonsson, B., Blair, G., Grace, P., Kwiatkowska, M., Calinescu, R., In-
verardi, P., Tivoli, M., Bertolino, A., Sabetta, A.: CONNECT challenges: Towards emergent
connectors for eternal networked systems. In: Engineering of Complex Computer Systems,
2009 14th IEEE International Conference on. (2009) 154–161
5. Blomstedt, F., Ferreira, L., Klisics, M., Chrysoulas, C., Martinez de Soria, I., Morin, B.,
Zabasta, A., Eliasson, J., Johansson, M., Varga, P.: The Arrowhead approach for SOA ap-
plication development and documentation. In: Industrial Electronics Society, IECON 2014 -
40th Annual Conference of the IEEE. (2014) 2631–2637
6. European Parliament and Council of the European Union: Directive 2009/28/ec of the Eu-
ropean parliament and of the council of 23 april 2009 on the promotion of the use of energy
from renewable sources and amending and subsequently repealing directives 2001/77/ec and
2003/30/ec. Official Journal of the European Union 52 (2009) 16–62
7. The Danish Ministry of Climate, Energy and Building: Energy policy report (2013)
8. Albano, M., Ferreira, L., Le Guilly, T., Ramiro, M., Faria, J., Perez Duenas, L., Ferreira,
R., Gaylard, E., Jorquera Cubas, D., Roarke, E., Lux, D., Scalari, S., Majlund Sorensen, S.,
Gangolells, M., Pinho, L., Skou, A.: The encourage ict architecture for heterogeneous smart
grids. In: EUROCON, 2013 IEEE. (2013) 1383–1390
9. Pedersen, T., Ravn, A., Skou, A.: INTrEPID: A project on energy optimization in buildings.
In: Wireless Communications, Vehicular Technology, Information Theory and Aerospace
Electronic Systems (VITAE), 2014 4th International Conference on. (2014) 1–4
36
EPS Colmar 2015 2015 - The Success of European Projects using New Information and Communication Technologies
36

10. Catalin Felix, C., Mircea, A., Julija, V., Anna, M., Gianluca, F., Eleftherios, A.,
Manuel Sanchez, J., Constantina, F.: Smart grid projects outlook 2014. Technical report,
European Comission (2014)
11. Albano, M., Ferreira, L., Pinho, L.: Convergence of smart grid ICT architectures for the last
mile. Industrial Informatics, IEEE Transactions on 11 (2015) 187–197
12. Balijepalli, V., Pradhan, V., Khaparde, S., Shereef, R.: Review of demand response under
smart grid paradigm. In: Innovative Smart Grid Technologies - India (ISGT India), 2011
IEEE PES. (2011) 236–243
13. Torriti, J., Hassan, M. G., Leach, M.: Demand response experience in europe: Policies,
programmes and implementation. Energy 35 (2010) 1575 – 1583
14. Teixeira, C., et al.: Convergence to the European energy policy in European countries: case
studies and comparison. Journal of Social Technologies 4 (2014) 7–24
15. Boehm, M., Dannecker, L., Doms, A., Dovgan, E., Filipi
ˇ
c, B., Fischer, U., Lehner, W., Ped-
ersen, T. B., Pitarch, Y., Šikšnys, L., Tušar, T.: Data management in the MIRABEL smart
grid system. In: Proceedings of the 2012 Joint EDBT/ICDT Workshops. EDBT-ICDT ’12,
New York, NY, USA, ACM (2012) 95–102
16. Neupane, B., Pedersen, T., Thiesson, B.: Towards flexibility detection in device-level energy
consumption. In Woon, W.L., Aung, Z., Madnick, S., eds.: Data Analytics for Renewable
Energy Integration. Volume 8817 of Lecture Notes in Computer Science. Springer Interna-
tional Publishing (2014) 1–16
17. Siksnys, L., Valsomatzis, E., Hose, K., Pedersen, T.: Aggregating and disaggregating flexibil-
ity objects. Knowledge and Data Engineering, IEEE Transactions on 27 (2015) 2893–2906
18. Klemperer, P.: The product-mix auction: a new auction design for differentiated goods.
Journal of the European Economic Association 8 (2010) 526–536
19. Cheshire, S., Krochmal, M.: DNS-Based Service Discovery. RFC 6763 (2013)
20. Waher, P.: HTTP over XMPP transport. XEP 0332, XSF (2013)
21. Group, X.X.I.W.: P21451-1-4 standard for a smart transducer interface for sensors, actuators,
and devices based on the extensible messaging and presence protocol (XMPP) for networked
device communication. Ieee, IEEE Standard Association (2008)
22. Zhang, C., Ding, Y., Ostergaard, J., Bindner, H., Nordentoft, N., Hansen, L., Brath, P., Cajar,
P.: A flex-market design for flexibility services through DERs. In: Innovative Smart Grid
Technologies Europe (ISGT EUROPE), 2013 4th IEEE/PES. (2013) 1–5
23. Kok, J. K., Warmer, C.J., Kamphuis, I.: Powermatcher: multiagent control in the electricity
infrastructure. In: Proceedings of the fourth international joint conference on Autonomous
agents and multiagent systems, ACM (2005) 75–82
24. Herrmann, I., O’Connell, N., Heller, A., Madsen, H. In: CITIES: Centre for IT-Intelligent
Energy Systems in Cities. (2014) 1–8
25. Valsomatzis, E., Hose, K., Pedersen, T. B., Siksnys, L.: Measuring and comparing energy
flexibilities. In: Joint EDBT/ICDT PhD workshop. (2015) 78–85
37
An Energy Flexibility Framework on the Internet of Things
37