Connecting Smart Grid Protocol Standards

A Mapping Model Between Commonly-used Demand-response Protocols OpenADR

and MIRABEL

Sevket G

okay, Markus C. Beutel, Houran Ketabdar and Karl-Heinz Krempels

RWTH Aachen University, Information Systems, Ahornstr. 55, 52074 Aachen, Germany

Keywords:

Mapping Model, OpenADR, MIRABEL, Interoperability.

Abstract:

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 signiﬁcantly, which results in a lack of inter-connectivity among

themselves. Connecting these commonly used standards makes it possible to beneﬁt 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.

1 INTRODUCTION

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 signiﬁcant eco-

nomic potentials for both manufacturers and users.

In a ﬁrst step, we study the modeling of OpenADR

and MIRABEL to ﬁnd similarities and differences in

roles, processes and information exchange concepts.

In a nutshell, we will ﬁnd out that there are three com-

parison levels: Operation/service, operation message

and message ﬁeld. 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-

ﬂects the contributions and describes upcoming future

work.

2 RELATED WORK

This section gives a general impression of related

work done in the ﬁeld 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 efﬁciency aspects of MIRA-

BEL. (Koch and Piette, 2007) enable a wider range of

facilities to leverage the beneﬁts 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-

operability.

As a preliminary conclusion, there is no solution

382

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.

3 DEMAND RESPONSE

PROTOCOLS

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., speciﬁcations.

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 speciﬁes four

application-ready services, on which we focus in this

work:

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): Deﬁnes peri-

odic or one-time information on the state of a re-

source.

VTN VTN

VTN

VEN

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 identiﬁes following services, planned for

future releases: Enrollment, market contexts, quote

or dynamic prices, availability.

On a technical level, OpenADR speciﬁes data

models (deﬁned in XML schemata) for messages to

be transmitted via either simple HTTP or XMPP

transport.

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.

3.2 MIRABEL

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 ﬂexibility concept

of electricity demand and supply. This concept de-

ﬁnes that producers or consumers (prosumers) can

offer possible changes to time periods and energy

amounts (i.e. ﬂexibilities) of both load generation and

consumption (Figure 2). In this regard, ﬂexOffer mes-

sages are exchanged indicating these ﬂexibilities. An-

other actor is the Balance Responsible Party (BRP).

The BRP is responsible of aggregating the ﬂexOffers,

scheduling them based on market situation, availabil-

ity of energy, etc. It negotiates the price, the use and

timing of ﬂexOffers with the prosumers (Verhoosel

et al., 2011). The BRP can accept an offer and send a

ﬂexOfferAcceptance. This only signiﬁes that the BRP

is going to make use of it at some point in time (within

http://ec.europa.eu/research/fp7

ConnectingSmartGridProtocolStandards-AMappingModelBetweenCommonly-usedDemand-responseProtocols

OpenADRandMIRABEL

383

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

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

real-time.

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

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 deﬁned time frame in ﬂexOffer). The actual de-

cision of energy usage proﬁle (time, energy, costs)

is communicated with a ﬂexOfferAssignment message

afterwards. In Figure 3, prosumer is depicted as the

issuer of ﬂexibility and BRP as the acquirer of ﬂexi-

bility. The speciﬁcation mentions many more roles of

energy domain that can interact via MIRABEL, but

the focus is on prosumer and BRP.

In summary, MIRABEL only deﬁnes one service

with ﬂexOffer being the request and ﬂexOfferAccep-

tance or ﬂexOfferAssignment the responses. On a

technical level, MIRABEL speciﬁes data models (de-

ﬁned 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 deﬁne their data models in XML

schemata and use XML messages.

3. Both use similar roles, which allow a general

mapping without extensive modiﬁcations in this

area (Table 1).

4. OpenADR deﬁnes 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 deﬁnes its data types in much more de-

tail than MIRABEL.

6. Whereas in MIRABEL, prosumers send their ﬂex-

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-

versed.

Table 1: Comparison of MIRABEL and OpenADR roles.

MIRABEL role Corresponding OpenADR role

Consumer VEN

Producer VEN

BRP VTN

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.

4 MAPPING

After having established the direction of mapping

(MIRABEL to OpenADR), we can now look at the

ﬁne-grained comparison of message types. The in-

tention is to bridge the gap between MIRABEL’s one

service and OpenADR’s EiEvent and EiOpt services

since they convey DR information. Figure 4 illus-

trates the general idea of message ﬂow and the func-

tion of our tool as a MIRABEL BRP and OpenADR

VEN to mediate between MIRABEL prosumers and

OpenADR VTNs.

Communication with the Prosumer

The mapping tool accepts ﬂexOffer messages, pro-

cesses and maps them to OpenADR messages, com-

municates with a VTN and based on the outcome

of the communication sends ﬂexOfferAcceptance and

ﬂexOfferAssignment to the prosumer. This is basically

the working principle of the solution.

SMARTGREENS2015-4thInternationalConferenceonSmartCitiesandGreenICTSystems

384

Mapping Tool

flexOffer

BRP Prosumer

oadrRequestEvent

oadrDistributeEvent

oadrCreatedEvent (optIn)

oadrResponse

oadrCreatedEvent (optOut)

oadrResponse

flexOfferAcceptance

(accepted=false)

VEN

internal

decision

logic

VTN

flexOfferAcceptance

(accepted=true)

flexOfferAssignment

oadrCreateOpt

oadrCreatedOpt

flexOfferAcceptance

(accepted=true)

flexOfferAssignment

Figure 4: Overview of message ﬂows.

Communication with the VTN

As mentioned, we have a work ﬂow mismatch: ﬂex-

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 ﬂexOffer.

A. If the ﬂexibility 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 ﬂexOfferAcceptance with accepted

ﬁeld 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 ﬂexOffer (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 ﬂexOffer-

Acceptance with accepted ﬁeld set to false to

prosumer (Figure 4C).

In any case, if the reply from VTN indicates that re-

quest cannot be accepted, ﬂexOfferAcceptance with

accepted ﬁeld 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 ﬁelds within the MIRABEL data

model to those in the OpenADR data model.

Trivial ﬁelds (such as IDs of messages, involved

parties, etc. and some meta information) can be

mapped and handled easily. Other ﬁelds, 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 ﬂexibility 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

ConnectingSmartGridProtocolStandards-AMappingModelBetweenCommonly-usedDemand-responseProtocols

OpenADRandMIRABEL

385

VTN

VEN

Module

BRP

Module

Message

Mediator

eiEvent

Store

OpenADR

Processor

eiEventFlexOffer

Matcher

MIRABEL

Processor

Mapping Tool

flexOffer

flexOfferAcceptance

flexOfferAssignment

Prosumer

Figure 5: Components overview of the mapping tool.

the bounds:

min value

MIR

≤ value

OADR

≤ max value

MIR

More granular mapping principles are summa-

rized in Table 2. It should be mentioned, that pre-

deﬁned EiEvent signals from (Zuber et al., 2013) are

advisory and deployments can deﬁne 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

ﬂexOffer 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 ﬂexOffers will not

be accepted. In that way, the tool deals with EiRegis-

terParty internally without outside interference.

5 IMPLEMENTATION

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

http://eclipse.org/jetty/

http://resteasy.jboss.org/

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 ﬁrst.

eiEventFlexOfferMatcher includes the decision logic

and MessageMediator coordinates the whole opera-

tion.

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 ﬂexOffers 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.

6 CONCLUSION

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 ﬁnd an easy solution.

While OpenADR speciﬁes DR events which are de-

ﬁned ahead of time and communicated for the partic-

ipation, MIRABEL targets near real-time negotiation

of energy usage, time period and price. Moreover,

the deﬁnition 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://

sourceforge.net/projects/openadr2vtn/

SMARTGREENS2015-4thInternationalConferenceonSmartCitiesandGreenICTSystems

386

Table 2: Matching of FlexEnergy and EiEvent ﬁelds.

FlexEnergy ﬁeld EiEvent ﬁeld Description

type eiEventSignal.signalName

AND

eiEventSignal.signalType

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

eiEventSignal.currentValue

Aggregation over values of events with the signal

name CHARGE STATE.

totalPriceConstraint SUM of

eiEventSignal.currentValue

Aggregation over values of events with the signal

name ENERGY PRICE.

energyConstraintProﬁle eiActivePeriod OR

eiEventSignal.intervals

For the ﬁelds related to time schedule, the cor-

responding information can be read from eiAc-

tivePeriod or from one event.

energyConstraintProﬁle.

EnergyConstraint

eiEventSignal.currentValue Value of an event with the signal name

CHARGE STATE.

energyConstraintProﬁle.

PowerConstraint

eiEventSignal.currentValue Derived from events with the signal name

LOAD DISPATCH.

tariffConstraintProﬁle 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.

ACKNOWLEDGEMENTS

This work was funded by the Excellence Initiative of

the German State and Federal Government (Project

Urban Future Outline).

REFERENCES

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

Standards.

GWAC (2008). GridWise Interoperability ContextSetting

Framework.

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 Veriﬁcation 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 ﬂexibility 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 Proﬁle Speciﬁcation B Proﬁle.

ConnectingSmartGridProtocolStandards-AMappingModelBetweenCommonly-usedDemand-responseProtocols

OpenADRandMIRABEL

387