Connecting Smart Grid Protocol Standards
A Mapping Model Between Commonly-used Demand-response Protocols OpenADR
Sevket G
okay, Markus C. Beutel, Houran Ketabdar and Karl-Heinz Krempels
RWTH Aachen University, Information Systems, Ahornstr. 55, 52074 Aachen, Germany
Mapping Model, OpenADR, MIRABEL, Interoperability.
Heterogeneous smart grid systems operate with different and incompatible protocols. MIRABEL and Open-
ADR are prominent examples, providing intelligent demand respond functionalities. In principle of opera-
tion as in complexity, both protocols differ significantly, which results in a lack of inter-connectivity among
themselves. Connecting these commonly used standards makes it possible to benefit from different proto-
col advantages and prevents from reconstructing whole smart grid systems for consolidation. Furthermore, it
holds potentials for interoperability of individually produced smart grid components. This work contributes a
conceptual mapping model between OpenADR and MIRABEL on the basis of a detailed protocol analysis, as
well as an initial implementation.
Smart grids leverage communication technology to
act on information about the behaviors of power sup-
pliers and consumers (Farhangi, 2010). Related func-
tionalities are provided via different sorts of proto-
cols. As a result of different protocol standards,
there is a lack of inter-connectivity among hetero-
geneous smart grid systems. Developing a mapping
tool, which connects the prominent protocols Open-
ADR and MIRABEL, prevents from changing the
whole system structure in case of a grid consolida-
tion. Above that, realization of interoperability be-
tween smart grid components offers significant eco-
nomic potentials for both manufacturers and users.
In a first step, we study the modeling of OpenADR
and MIRABEL to find similarities and differences in
roles, processes and information exchange concepts.
In a nutshell, we will find out that there are three com-
parison levels: Operation/service, operation message
and message field. Operation/service level similari-
ties and differences will be semantic, and the remain-
ing two will be mostly syntactic. Afterwards, we pro-
totype a mapping tool, which connects the mentioned
standards and describe early evaluation results.
The work is structured as follows. Section 2 ex-
plains related mapping efforts. Moreover, Section 3
gives an overview of demand response protocols, be-
fore Section 4 describes the contributed approach and
Section 5 presents the current status of the imple-
mentation and the evaluation. Finally, Section 6 re-
flects the contributions and describes upcoming future
This section gives a general impression of related
work done in the field of interest.
(Ghatikar et al., 2014) concentrated on the map-
ping between constitutive OpenADR versions. Basi-
cally, this work helps to get insights about the techni-
cal compatibility of each version. Furthermore, (Mc-
Parland, 2011) focused on the development of an im-
plementation of OpenADR for smart grids. (Fischer
et al., 2013) describes efficiency aspects of MIRA-
BEL. (Koch and Piette, 2007) enable a wider range of
facilities to leverage the benefits of demand response.
(GWAC, 2008) proposes a general framework to or-
ganize concepts and terminology for interoperability
issues. This framework basically focuses on a high,
organizational level.
(Rumph et al., 2013) classify existing technolo-
gies to enable the interoperability of energy manage-
ment systems. Moreover, they outline a conceptual
model, which focuses on the semantic level of inter-
As a preliminary conclusion, there is no solution
Gökay S., C. Beutel M., Ketabdar H. and Krempels K..
Connecting Smart Grid Protocol Standards - A Mapping Model Between Commonly-used Demand-response Protocols OpenADR and MIRABEL.
DOI: 10.5220/0005486503820387
In Proceedings of the 4th International Conference on Smart Cities and Green ICT Systems (SMARTGREENS-2015), pages 382-387
ISBN: 978-989-758-105-2
2015 SCITEPRESS (Science and Technology Publications, Lda.)
that enables interoperability among the examined pro-
tocols on both the semantic and the syntactic level.
Demand response (DR) is a technology developed
to cope with the increasing energy demands with-
out increasing the energy generation (Mashima et al.,
2014). DR plays an important role to manage and op-
timize volatile loads of renewable energy sources. It
enables to maintain a balance between power genera-
tion and load distribution with demand, without any
manual intervention. This is usually realized by a
communication protocol between the energy provider
and consumer in which the endpoints negotiate the
electricity demand, price and respective time periods.
This section gives a brief overview of two such
DR protocols, OpenADR and MIRABEL. For further
explanations, the reader is advised to look at respec-
tive resources, e.g., specifications.
3.1 OpenADR
Open Automated Demand Response (OpenADR) fa-
cilitates sending and receiving DR signals from a util-
ity or independent system operator to electricity cus-
tomers (Zuber et al., 2013). It is led by North Amer-
ican research labs and companies. Principally, it is
a two-way signaling system between a server (Vir-
tual Top Node - VTN) and client (Virtual End Node -
VEN). VTN publishes DR signals to clients and VEN
controls the electric energy demand in response to DR
signals. The VEN may be either a producer or con-
sumer of energy. It is possible for a VEN to take on
the role of VTN to distribute DR signals (Figure 1).
These nodes are called aggregators.
The latest version OpenADR 2.0b specifies four
application-ready services, on which we focus in this
1. Registration (EiRegisterParty): VENs have to be
registered by VTNs before any other interaction.
2. Event (EiEvent): This is the main service of the
protocol to communicate DR information models
and event functions for price signals. Events are
generated and maintained by VTNs and sent to
VENs for them to accept.
3. Reporting or Feedback (EiReport): Defines peri-
odic or one-time information on the state of a re-
Figure 1: Possible relationship between VENs and VTNs.
4. Opt or Override (EiOpt): Communicates opt-
in and opt-out schedules based on short-term
changes in availability of a resource.
It also identifies following services, planned for
future releases: Enrollment, market contexts, quote
or dynamic prices, availability.
On a technical level, OpenADR specifies data
models (defined in XML schemata) for messages to
be transmitted via either simple HTTP or XMPP
PUSH/PULL Operations. OpenADR can be used
in a PULL mode, where the VEN asks for updates
from the VTN, or in a PUSH mode, where the op-
eration is initiated by the VTN to a VEN.
MIRABEL stands for Micro-Request-Based Aggre-
gation, Forecasting and Scheduling of Energy De-
mand, Supply and Distribution. It is intended to bal-
ance the available supply of renewable energy sources
and current demand (Verhoosel et al., 2011). It is
supported by the European Commission’s Seventh
Framework Program (FP7)
MIRABEL revolves around the flexibility concept
of electricity demand and supply. This concept de-
fines that producers or consumers (prosumers) can
offer possible changes to time periods and energy
amounts (i.e. flexibilities) of both load generation and
consumption (Figure 2). In this regard, flexOffer mes-
sages are exchanged indicating these flexibilities. An-
other actor is the Balance Responsible Party (BRP).
The BRP is responsible of aggregating the flexOffers,
scheduling them based on market situation, availabil-
ity of energy, etc. It negotiates the price, the use and
timing of flexOffers with the prosumers (Verhoosel
et al., 2011). The BRP can accept an offer and send a
flexOfferAcceptance. This only signifies that the BRP
is going to make use of it at some point in time (within
MIRABEL WP7 Standardization, Dissemination and Exploitation
Deliverable D7.5: MIRABEL-ONE: Initial draft of the MIRABEL Standard
D7 5 MIRABEL-ONE v1 0 final.docx Public Page 8
Copyright MIRABEL Consortium 2010-2012
4 Flexibility concept
The flexibility concept assumes that parties connected to the grid produce offerings of
flexibility in load and (distributed) generation. Thereby, so-called flex-offers are issued
indicating these power profile flexibilities, e.g. shifting in time or changing the energy
amount. In the flex-offer approach, consumers and producers directly specify their
demand and supply power profile flexibility in a fine-grained manner (household and SME
level). Flex-offers are dynamically scheduled in near real-time, e.g. in case when the
energy production from renewable energy sources, such as wind turbines, deviates from
the forecasted production of the energy system.
4.1 The Flex-offer in the energy system
The central concept of our approach is the flex-offer specification. Essentially, a flex-offer
is a request for demand or supply of energy with specified flexibilities as shown in Figure
1. The bars represent an electricity profile which is split into six time intervals. The
flexibility in time is represented by the minimal and the maximal start time. The white, light
grey and dark grey sections of the bars visualize the flexibility of the amount. The given
flexibilities enable the scheduling of requests on higher hierarchy levels.
Figure 1: General example of a flex-offer specification.
On the prosumer level and within its EMS, a flex-offer is bound to a device consuming or
producing electricity, e.g. a dishwasher, dryer, washing machine, swimming pool pump,
electrical heating, heat pump device, charging of an electric vehicle, and combined
generation of heat and power. The profile of the flex-offer corresponds to the profile of the
device (and its flexibility).
Energy management for consumers and producers is realized at the lowest level of the
hierarchy, and it uses functionality either provided by a smart meter or a separate energy
management system. From the perspective of metering and data management, we
distinguish between demand and supply. The system stores historic data and uses it to
forecast demand and supply for the near future in prosumer profiles (i.e., day ahead and
intra-day). Prosumers can issue flex-offers usually one day ahead or intra-day, i.e. near
The Balance Responsible Party (BRP) further aggregates the flex-offers, schedules them
depending on several factors like the current market situation, the availability of
renewable energy and the energy prices, and negotiates the price, the use and timing of
flex-offers with the prosumers. By using schedulable flex-offers, a BRP is able to use
Figure 2: Flexibility in MIRABEL with dimensions time
and energy amount (Verhoosel et al., 2011).
MIRABEL WP7 Standardization, Dissemination and Exploitation
Deliverable D7.5: MIRABEL-ONE: Initial draft of the MIRABEL Standard
D7 5 MIRABEL-ONE v1 0 final.docx Public Page 21
Copyright MIRABEL Consortium 2010-2012
Issuer of flexibility Acquirer of flexibility
Party connected to the grid: consumer BRP
BRP Party connected to the grid: producer
BRP Balance supplier
BRP Market operator
BRP System operator
Table 2: Issuers and acquirer of flexibility; mapping on ENTSO-E role model.
Therefore, in the remainder of this document we will use the general terms issuer and
acquirer of flexibility. Figure 10 provides a schematic view on the functionalities of
acquirers and issuers of flexibility in load and/or generation. In general, any number of
issuers of flexibility can interact with any number of acquirers of flexibility. However, both
the technical as well as the commercial setting may limit the number of issuers and/or
acquirers. In this context, an arbitrary number of parties connected to the grid (many
issuers) offer flexibilities to their balance responsible party (the single acquirer).
Figure 10: Schematic view of the issuer and acquirer actors.
Issuers of flexibility control one or more devices that demand energy or resources that
supply energy. This control is executed either directly or indirectly and allows control of
the power profiles of these devices and resources. The issuers decide what flexibility is
offered; based on e.g. technical, financial and/or comfort grounds. Thus, the flexibility-
issuer remains autonomous in its decision making.
Acquirers of flexibility have a use for the ability to control the power profiles of these
devices and resources as offered by the flexibility-issuers. This includes e.g. the ability for
a balance responsible party to achieve the schedules submitted to a system operator as
in the ENTSO-E scheduling system with a substantial amount of intermittent energy
sources in their portfolio.
Offerings of flexibility need to be accepted (or rejected) by the acquiring party. When
flexibility offered is accepted, a profile assignment must be provided by the acquiring
party to indicate the desired behaviour. This profile assignment must comply with the
limits of the flexibility offered; e.g. no higher power output then offered, no temporal shift
beyond the temporal bounds offered, etc.
Figure 3: Roles in MIRABEL (Verhoosel et al., 2011).
the defined time frame in flexOffer). The actual de-
cision of energy usage profile (time, energy, costs)
is communicated with a flexOfferAssignment message
afterwards. In Figure 3, prosumer is depicted as the
issuer of flexibility and BRP as the acquirer of flexi-
bility. The specification mentions many more roles of
energy domain that can interact via MIRABEL, but
the focus is on prosumer and BRP.
In summary, MIRABEL only defines one service
with flexOffer being the request and flexOfferAccep-
tance or flexOfferAssignment the responses. On a
technical level, MIRABEL specifies data models (de-
fined in XML schemata) for messages but not the un-
derlying transportation protocol.
3.3 Protocol Comparison
At this point, we don’t want to discuss protocol char-
acteristics in close detail, but rather describe similar-
ities and differences which are most relevant for up-
coming mapping efforts. An in-depth analysis leads
to following conclusions:
1. Since MIRABEL does not specify a transport pro-
tocol, we can accept simple HTTP communica-
tion as a common ground.
2. Both standards define their data models in XML
schemata and use XML messages.
3. Both use similar roles, which allow a general
mapping without extensive modifications in this
area (Table 1).
4. OpenADR defines four services whereas MIRA-
BEL only one. The OpenADR services EiRegis-
terParty and EiReport have no logical equivalents
in MIRABEL. See Section 4.2 for workarounds.
5. OpenADR defines its data types in much more de-
tail than MIRABEL.
6. Whereas in MIRABEL, prosumers send their flex-
ibilities and BRP can accept that or assign a new
energy usage/schedule, in OpenADR VTNs dis-
tribute possible events to VENs and VENs can
decide on accept/opt-in/opt-out. So, there is a
conceptual difference that the deciding role is re-
Table 1: Comparison of MIRABEL and OpenADR roles.
MIRABEL role Corresponding OpenADR role
Consumer VEN
Producer VEN
This situation shapes the relation between both pro-
tocols: OpenADR has a comprehensive feature set
and MIRABEL is a simpler protocol in comparison.
Many operations and messages of OpenADR do not
exist in MIRABEL or the differences are so big that a
workaround cannot be applied. Therefore, it is only
possible to map from MIRABEL to OpenADR but
not the other way around. In other words, our aim
is to make MIRABEL OpenADR-compatible.
After having established the direction of mapping
(MIRABEL to OpenADR), we can now look at the
fine-grained comparison of message types. The in-
tention is to bridge the gap between MIRABELs one
service and OpenADR’s EiEvent and EiOpt services
since they convey DR information. Figure 4 illus-
trates the general idea of message flow and the func-
tion of our tool as a MIRABEL BRP and OpenADR
VEN to mediate between MIRABEL prosumers and
Communication with the Prosumer
The mapping tool accepts flexOffer messages, pro-
cesses and maps them to OpenADR messages, com-
municates with a VTN and based on the outcome
of the communication sends flexOfferAcceptance and
flexOfferAssignment to the prosumer. This is basically
the working principle of the solution.
Mapping Tool
BRP Prosumer
oadrCreatedEvent (optIn)
oadrCreatedEvent (optOut)
Figure 4: Overview of message flows.
Communication with the VTN
As mentioned, we have a work flow mismatch: flex-
Offer proposes a schedule and/or energy usage, but
a VEN can only ask for events (schedules) with
either oadrPoll (periodically) or oadrRequestEvent
(one-time) messages in PULL mode. Both message
types serve the goal to acquire applicable events (oad-
rEvent) from VTN which is realized by oadrDistribu-
teEvent message. Afterwards, a VEN can decide to
opt-in or opt-out events and transmit the decision.
The Decision Logic
The way the mapping tool works is upon receiving
oadrEvents from VTN, it compares the schedules,
energy amounts and pricing from these events with
those from the received flexOffer.
A. If the flexibility offer is within acceptable bounds,
i.e. one of the events completely overlaps the of-
fer, it sends oadrCreatedEvent with optIn state
to VTN and flexOfferAcceptance with accepted
field set to true to prosumer (Figure 4A).
B. If there is only a partial overlap, it overrides one
OpenADR event, depending on the factor which
requires the least extension, by sending oadrCre-
ateOpt and accepts the flexOffer (Figure 4B).
C. If there is no match, it sends either no message
or (if the event requires a response) oadrCreat-
edEvent with optOut state to VTN, and flexOffer-
Acceptance with accepted field set to false to
prosumer (Figure 4C).
In any case, if the reply from VTN indicates that re-
quest cannot be accepted, flexOfferAcceptance with
accepted field set to false is sent to prosumer.
4.1 Mapping of Fields
The two elements, which contain DR information,
in aforementioned messages are FlexEnergy and
EiEvent. This section provides an overview of the
mapping of the fields within the MIRABEL data
model to those in the OpenADR data model.
Trivial fields (such as IDs of messages, involved
parties, etc. and some meta information) can be
mapped and handled easily. Other fields, including
time periods, pricing and amount of energy have to
be derived and their mapping is worth mentioning.
First of all, in accordance with its flexibility con-
cept MIRABEL allows the use of both single val-
ues and range values (min-max, upper-lower, after-
before) rather than just single values as in OpenADR.
Therefore, in case of a range, the OpenADR value has
to be always checked whether it is contained within
Mapping Tool
Figure 5: Components overview of the mapping tool.
the bounds:
min value
max value
More granular mapping principles are summa-
rized in Table 2. It should be mentioned, that pre-
defined EiEvent signals from (Zuber et al., 2013) are
advisory and deployments can define their own cus-
tom signals which facilitates the interoperability be-
tween both protocols.
4.2 Workarounds
Since MIRABEL does not support querying the ac-
tual energy usage, we cannot provide a workaround
for EiReport. On the other hand, we propose that the
mapping tool tracks the prosumers it communicates
with and stores them in a database. After receiving a
flexOffer from a new, unknown prosumer, it automati-
cally registers the prosumer using the EiRegisterParty
service by the VTN. If the VTN decides to cancel reg-
istration anytime, the mapping tool can mark this pro-
sumer as canceled and subsequent flexOffers will not
be accepted. In that way, the tool deals with EiRegis-
terParty internally without outside interference.
We started developing the mapping tool as a Java
server application running on Jetty
and leverag-
ing RestEasy
for Web services and clients. The
XML messages are exchanged using HTTP POST.
We used OpenADR XML schemata downloaded from
the OpenADR alliance website and MIRABEL XML
schemata extracted from the documentation.
An overview of the architecture can be seen in
Figure 5. The modules consist of client and service
parts and are responsible for communicating with the
remote endpoints via the Internet. The processors
serialize/deserialize requests and responses. In or-
der to reduce the remote calls to VTN, eiEventStore
caches the distributed eiEvents for local lookup first.
eiEventFlexOfferMatcher includes the decision logic
and MessageMediator coordinates the whole opera-
For the evaluation purposes, we installed the
OpenADR VTN developed by EPRI
and set up the
mapping tool to communicate with it. Unfortunately,
there is no obtainable implementation of MIRABEL.
We therefore had to fall back on manually generating
the flexOffers and analyzing the responses from the
tool. In this regard, the fact that incoming and out-
going messages are validated against the respective
XML schemata during runtime, helped immensely as
a guidance. First evaluation runs showed expedient
data exchange. Therefore, we assume a working map-
ping logic.
In this work, we studied two DR protocols, OpenADR
and MIRABEL, which are used in smart grid systems
and investigated their interoperability. We compared
the two protocols on a semantic as well as syntac-
tic level. Even though they aim to achieve similar
goals, their different working principles and varying
complexities make it hard to find an easy solution.
While OpenADR specifies DR events which are de-
fined ahead of time and communicated for the partic-
ipation, MIRABEL targets near real-time negotiation
of energy usage, time period and price. Moreover,
the definition of multiple functionalities and com-
plex data types of OpenADR and rather simplistic
nature of MIRABEL make it impossible to come up
with a complete, one-to-one mapping. Our mapping
Electric Power Research Institute. http://
Table 2: Matching of FlexEnergy and EiEvent fields.
FlexEnergy field EiEvent field Description
type eiEventSignal.signalName
Depending on the signal category it can be de-
cided whether this signal relates to production or
consumption of energy.
sourceType - No match
totalEnergyConstraint SUM of
Aggregation over values of events with the signal
totalPriceConstraint SUM of
Aggregation over values of events with the signal
energyConstraintProfile eiActivePeriod OR
For the fields related to time schedule, the cor-
responding information can be read from eiAc-
tivePeriod or from one event.
eiEventSignal.currentValue Value of an event with the signal name
eiEventSignal.currentValue Derived from events with the signal name
tariffConstraintProfile eiEventSignal.currentValue There is no explicitly declared tariff concept in
OpenADR, but tariffs can be computed from val-
ues of signals with signal type priceMultiplier.
logic effort shows that interoperability is possible and
serves as a starting point.
6.1 Limitations and Future Work
Due to the dissimilar characteristics of both proto-
cols, the mapping is limited in operational scope. Fu-
ture work primarily consists of solving the incompat-
ibilities and broadening the extent of functionalities
(e.g., reporting). In this prototypical phase, we con-
centrated on the functional evaluation of the mapping
logic rather than other aspects such as performance
and speed. In addition, we acknowledge that our eval-
uation lacks a sound approach and the moving parts
for integration testing. These are part of future work.
This work was funded by the Excellence Initiative of
the German State and Federal Government (Project
Urban Future Outline).
Farhangi, H. (2010). The path of the smart grid. Power and
Energy Magazine, pages 18–28.
Fischer, U., Kaulakiene, D., Khalefa, M. E., Lehner,
W., Pederson, T. B., Siksnys, L., and Thomsen, C.
(2013). Real-time Business Intelligence in the MIRA-
BEL Smart Grid System. Springer.
Ghatikar, G., Riess, D., and Piette, M. A. (2014). Analysis
of Open Automated Demand Response Deployments
in California and Guidelines to Transition to Industry
GWAC (2008). GridWise Interoperability ContextSetting
Koch, E. and Piette, M. A. (2007). Architecture Concepts
and Technical Issues for an open, Interoperable Auto-
mated Demand Response Infrastructure. In Grid In-
terop Forum.
Mashima, D., Herberg, U., and Chen, W. (2014). Enhancing
Demand Response Signal Verification in Automated
Demand Response Systems. In Innovative Smart Grid
Technologies Conference (ISGT), pages 1–5.
McParland, C. (2011). OpenADR Open Source Toolkit:
Developing Open Source Software for the Smart Grid.
In IEEE Power & Energy Society General Meeting,
Detroit, MI.
Rumph, F., Huitema, G., and Verhoosel, J. (2013). To-
wards interoperability of energy management sys-
tems using flexibility through conceptual modeling.
In IFIP/IEEE International Symposium on Integrated
Network Management (IM 2013), Ghent.
Verhoosel, J., Rothengatter, D., Rumph, F., and Konsman,
M. (2011). Initial draft of the MIRABEL Standard.
Zuber, J., Herberg, U., and Bienert, R. (2013). OpenADR
2.0 Profile Specification B Profile.