Technical Report

Message-oriented middleware
for smart grids

Michele Albano
Luis Lino Ferreira
Luis Miguel Pinho
Abdel Rahman Alkhawaja

CISTER-TR-140803
Version:
Date: 08-21-2014
Technical Report CISTER-TR-140803 Message-oriented middleware for smart grids

Message-oriented middleware for smart grids

Michele Albano, Luis Lino Ferreira, Luis Miguel Pinho, Abdel Rahman Alkhawaja
CISTER Research Unit
Polytechnic Institute of Porto (ISEP-IPP)
Rua Dr. António Bernardino de Almeida, 431
4200-072 Porto
Portugal
Tel.: +351.22.8340509, Fax: +351.22.8340509
E-mail: mialb@isep.ipp.pt, llf@isep.ipp.pt, lmp@isep.ipp.pt, abdel@isep.ipp.pt
http://www.cister.isep.ipp.pt

Abstract
In order to increase the efficiency in the use of energy resources, the electrical grid is slowly evolving into a
smart(er) grid that allows users’ production and storage of energy, automatic and remote control of appliances,
energy exchange between users, and in general optimizations over how the energy is managed and consumed.
One of the main innovations of the smart grid is its organization over an energy plane that involves the actual
exchange of energy, and a data plane that regards the Information and Communication Technology (ICT)
infrastructure used for the management of the grid’s data.
In the particular case of the data plane, the exchange of large quantities of data can be facilitated by a
middleware based on a messaging bus. Existing messaging buses follow different data management paradigms
(e.g.: request/response, publish/subscribe, data-oriented messaging) and thus satisfy smart grids’ communication
requirements at different extents.
This work contributes to the state of the art by identifying, in existing standards and architectures, common
requirements that impact in the messaging system of a data plane for the smart grid. The paper analyses existing
messaging buses paradigms that can be used as a basis for the ICT infrastructure of a smart grid and discusses
how these can satisfy smart grids’ requirements.

© CISTER Research Unit 1

www.cister.isep.ipp.pt
 Message-oriented middleware for smart grids
Michele Albano, Luis Lino Ferreira, Luís Miguel Pinho, Abdel Rahman Alkhawaja
CISTER/INESC-TEC, ISEP, Polytechnic Institute of Porto
Rua Dr. António Bernardino de Almeida, 431
4200-072 Porto / Portugal

{ mialb, llf, lmp}@isep.ipp.pt

Elsevier use only: Received date here; revised date here; accepted date here

Abstract

In order to increase the efficiency in the use of energy resources, the electrical grid is slowly evolving into a smart(er) grid
that  allows  users’  production  and  storage  of  energy,   automatic and remote control of appliances, energy exchange between
users, and in general optimizations over how the energy is managed and consumed. One of the main innovations of the smart
grid is its organization over an energy plane that involves the actual exchange of energy, and a data plane that regards the
Information and Communication Technology (ICT) infrastructure  used  for  the  management  of  the  grid’s  data.

In the particular case of the data plane, the exchange of large quantities of data can be facilitated by a middleware based on a
messaging bus. Existing messaging buses follow different data management paradigms (e.g.: request/response,
publish/subscribe, data-oriented messaging) and thus satisfy  smart  grids’  communication  requirements  at  different  extents.

This work contributes to the state of the art by identifying, in existing standards and architectures, common requirements that
impact in the messaging system of a data plane for the smart grid. The paper analyses existing messaging buses paradigms
that can be used as a basis for the ICT infrastructure of a smart grid and discusses how these can   satisfy   smart   grids’  
requirements.

© 2001 Elsevier Science. All rights reserved

Keywords: AMQP; RabbitMQ; DDS; XMPP; publish-subscribe

energy, as well as store it and exchange it with many

other actors. Different architectural solutions have
1. Introduction been proposed, with the goal of facilitating the
operational control of such increasingly complex
The energy grid has evolved from a unidirectional system. The energy grid can now interact with the
production/transmission/distribution/consumption final user to control his energy consumption, by
pipeline to a complex system where every level of the either direct control on some of his appliances (for
pipeline comprises multiple actors that can produce example, the washing machine) or indirect control,
by providing fine grain resolution on the cost of the normalizing   “how”   the   data   is   exchanged.   The
energy at a given day and time, such that the final communication functionalities of the messaging bus,
user tunes up his own schedule for the energy and the services supporting it, can be entrusted to a
consumption. The grid can also promote cooperation middleware located over the communication stacks
among different prosumers (both producers and but under the business logic of the applications. The
consumers of energy) to enable more efficient energy middleware abstractions facilitate the interaction
usage, particularly in what concerns consuming on between different components, and also between the
the spot for renewable energies. “mechanisms”   elements   and   the   “politics”   elements
Traditional techniques cannot cope with the design of the smart grid, which are the traditional categories
of energy grids, since these are characterized by a used to divide the system components into two sets
large number of actors and mechanisms, controlled performing different functions. The mechanisms
by many different entities, which are kept together by collect data from the surrounding environment, and
a plethora of connections to exchange energy and actuate on the physical world. The politics contain
data.   Thus,   the   paradigm   of   the   “smart   grid”   has   logic to perform computations based on the
emerged, in which the interaction between the information received by the underlying mechanisms.
involved actors is articulated into an energy plane and After retrieving data from mechanisms, and
a data plane, where the latter provides the required processing the data, the politics send commands back
information used to orchestrate the efficient to the mechanisms, to perform energy-efficient and
allocation of energy to different energy-consuming business-efficient actions. Figure 1 highlights the
actors as well as to different storage units. duality between politics and mechanism components.
This smart grid paradigm led to the emergence of
a plethora of systems and architectures, with many P olitics Demand/Response Supervision ….

common points as well as many differences. One of

the common points is related to the size and Mi ddleware

complexity of smart grid systems. In fact, an energy

grid usually serves a large number of users by Mec ha nisms House control Energy Distribution ….

providing them the energy they consume. This

characteristic, together with the fact that each actor is
controlled by an independent entity, leads to organize Figure 1 – Politics/mechanisms duality
smart grids using loosely-connected, service-oriented,
scalable architectures, communicating via standard In the most common type of smart grid, the
protocols [1] and the introduction of a messaging bus sensors and actuators are too limited in computational
[2] can limit the complexity of the system. power to be able to support a complex protocol, like
The smart grid can and must adhere to standards the ones used in the middleware. The topology is
to pursue the three goals [3] of: i) improving centered on a   gateway   installed   in   the   users’   houses
interoperability between neighboring systems; ii) (e.g. the Energy Service Interface (ESI) in the
limiting the complexity of the system when it scales National Institute of Standards and Technology
to a large user base; and iii) opening new markets to (NIST) vision [4], which will be described in
technology providers and utilities companies. Subsection 2). The gateway manages a subset of the
Currently there are (too) many standards that address sensors and actuators deployed in the house, and it is
the smart grid area, focusing on different components connected to the internet to interact with energy
or layers of the grid and providing different views on services via a data plane. This topology carries the
the system, but latest standardization activities are name of Home Area Network (HAN), and in the rest
leading different approaches to convergence on a of  this  work  the  gateway  installed  in  the  user’s  HAN  
common semantics. will be called HAN Gateway, or HAN GW.
While adhering to standards is useful to normalize As far as current smart grids are concerned, a
“what”   is   communicated   in   the   system,   the   user’s   house   usually   hosts   a   number   of   HANs,   one  
introduction of a messaging bus takes care of per each vendor of technology, e.g. one for the solar
panels and one for controlling the Heating, engineering, which considers building systems by
Ventilation and Air Conditioning (HVAC) system. In first providing system architecture, and then refining
this case, the middleware would extend itself only up it into a system design by adding details like data
to the HAN Gateway; the latter would decode the encoding, protocols, etc. We consider that existing
protocol used in the middleware, and then interact standards on smart grids can be categorized in three
with the sensors and actuators associated with it. The sets, depending on the level of detail they provide:
middleware supports multiple event processing Meta-architectures expand the architectural
agents that exchange information between event analysis towards embracing different architectures,
producers, event consumers, and other agents. with the goal of proposing an abstract model which
In this paper, we focus on the approaches for can be mapped onto a family of architectures. A
supporting the data plane dimension of the smart particular architecture is identified as an instance of
grid, and in particular the deployment of message- the family.
oriented middleware. The remainder of the paper is Architectures limit the content of the standards to
organized as follows. Section 2 analyzes current the proposed smart grid architecture and to the
standardization efforts and technical initiatives for functionalities that must be supported.
smart grids and collects the architectural and Design standards go deep into low-level details,
technological requirements. Section 3 presents like data encoding and protocols to be employed in
messaging bus paradigms and architectures that can the smart grid.
potentially satisfy these requirements. Section 4 then Two examples of meta-architectures are the NIST
provides some use cases, while Section 5 discusses Canonical Data Model (CDM), which proposed a
how to select the middleware to be employed to reference model in “NIST  Framework  and  Roadmap  
support the functionalities of a particular standard. for Smart Grid Interoperability Standards, Release
Section 6 draws some conclusions and wraps up the 2.0”   [4], and the joint effort of CEN (European
paper. Committee for Standardization), CENELEC
(European Committee for Electrotechnical
Standardization) and ETSI (European
2. Standardization efforts for smart grids Telecommunications Standards Institute), which led
to a meta-model called Smart Grid Architecture
In the past few years a number of companies, Models (SGAM) [5]. Meta-architectures are too
research centers and standardization bodies worked general to draw clear requirements for the ICT
towards facilitating the design and implementation of middleware that can support it. Anyway, the meta-
smart grids. A number of legacy and closed architectures agree regarding the large scale of the
technologies have created parallel subsystems in the proposed deployments, which leads to the
HANs of final users, and then have been refined into requirement of scalability. Moreover, the actors in
standards. Afterwards standardization activities had the scenario must be able to associate different levels
the goal of organizing existing standards and produce of urgency to their messages, thus the requirement of
best practices to select the right approach to be used providing prioritization in the underlying messaging
in a given smart grid design. bus.
This work is centered on ICT middleware that can Two important design standards are the Common
support the   smart   grid’s data plane, and thus the Information Model (CIM) [6][7] by the International
analysis of the smart grid use case was instrumental Electrotechnical Commission (IEC), and the Smart
for eliciting the requirements for middleware for the Energy Profile version 2.0 (SEP) [8], which is a
smart grid. Not to   be   lost   in   systems’   details, the profile of the ZigBee protocol suite. Both design
internals of existing approaches were disregarded, standards were developed in order to allow effective
and instead the focus has been on intended scenarios data exchange among different information systems,
and requirements of the smart grid. and they mainly specify the interfaces between
An analysis of existing standards for smart grids components of an energy grid, therefore establishing
can be driven, at top level, by the vision of system a common language and protocol for interoperability
between software modules, potentially from different the provided description are scalability and
vendors. As an example, SEP has been developed to dynamicity.
map directly to the Common Information Model Microsoft Smart Energy Reference Architecture
(CIM), and it adheres to the NIST framework, and (SERA) [12] is an architectural standard that
thus SEP inherits CIM characteristics. The approach positions itself as complementary to the NIST
considers that some messages require Quality of initiative. The SERA intends to concoct a bridge
Service (QoS), both in terms of message from NIST standards to related Microsoft products
prioritization and of delivery semantics (e.g. and technologies, by positioning the products in the
delivery guarantees). Finally, the solution must meta-architecture of NIST. Requirements for a
support a scalable and dynamic scenario, since the middleware supporting SERA are scalability, rich
design standards explicitly consider systems where delivery semantics, and the capability to assign
the interacting applications can be switched on or off different priority levels (prioritization) to
while the system is already up and running, the independent information flows.
inclusion of new applications and their online update, The discussion above highlights a trend in current
also very important is the provision of fault tolerance smart grid systems. When analyzed at the same
features. granularity, all of them are subject to the same
Most other standards are part of the requirements: meta-architectures will provide
“architectures”   category.   Examples   from   this   group requirements on the scalability of the system and on
are ETSI M2M (Machine to Machine), defined in support for information flows having different
ETSI Technical Report TR 102691 [9], and Device priority (prioritization); more details on the concrete
Language Message Specification/COmpanion architecture lead to considering the changes in the
Specification for Energy Metering (DLMS/COSEM). topology (dynamicity), and details on the protocol
These are similar in scope, since both address data highlight the importance of rich delivery semantics
exchange for meter reading, tariff and load control. to protect individual communication flows.
Their scenarios comprise energy meters empowered The functional requirements described above can
with real-time transmission of data regarding energy be related to the underlying network, leading to the
consumption, which is then used by the customer to derived requirements on message latency, jitter (also
tune up its energy usage and by the electricity known as time predictability) and Data Bandwidth.
company to manage the electricity distribution. The Latency is the travel time of a message from its
scenario supported by ETSI M2M is thus more source to its destination, and must be under a given
limited and self-contained than the typical smart grid. threshold to ensure the scalability and dynamicity of
The requirements are thus limited to scalability, the system. The jitter is the measure of the variability
while the constraint of being based on REST [10] of the message latency over time, and it must be
bestows limitations on the flexibility that can be under control to ensure correct delivery semantics.
harnessed. Data bandwidth is the total throughput between
The OSGP (Open Smart Grid Protocol) [11] is sender and receiver, and it must be sufficiently large
another design standard published by ETSI. It is for scalability and prioritization. Table 1 summarizes
intended to support communication between large the requirements presented in this subsection.
deployments of smart grid devices and utility Table 1: Middleware requirements
companies for billing purposes, but also to control Prioritization Prioritization of messages
user’s  consumption  in  case  of  energy  shortage,  and  to   Delivery semantics Protection of messages from
provide usage information to the user. From the loss and reordering
analysis of its scenario, it is evinced that the Scalability Support for large user base
requirements for supporting middleware are rich Dynamicity Adaptability to user changes
delivery semantics to protect sensitive Latency Low transmission latency
communications, which can be impacted by attackers Jitter Low latency variability
and network failures. Other requirements derived by Data bandwidth Large data throughput
 Among the functionalities that can be provided by
The requirements are instrumental in selecting the a middleware layer, communication is probably the
right messaging system, which is the single software most prominent. In a smart grid, timely information
component that has the largest impact on the system can improve the efficiency, reliability and security of
performance, but some requirements can profit from energy management. Better efficiency comes from
other characteristics of the platform. Examples are: the overall monitoring of the electricity network, and
i) Scalability can leverage on distributed and cloud from the capability of acting upon loads in order to
computing to harvest computational power to serve better adapt to overall and local energy production
more actors; from traditional and renewable sources, since
ii) Dynamicity can exploit a component-based renewable sources are affected by fluctuating weather
architecture to hide the changes of one subsystem to factors. The increase in reliability and security arises
the rest of the smart grid and hence to ease the from the capacity of real-time monitoring and
integration of new components and the application of actuation over the network.
updates while the system is executing; A middleware layer must satisfy at least to two
iii) Prioritization can benefit from operating different needs of the smart grid:
systems and networks that can enforce QoS, or at i) Communication for decision-making: some of
least to prioritize some of the services and/or the decisions that must be taken in the smart grid
processes. Any guarantee to prioritization depends on depend on information that is not produced locally.
the capabilities of the operating systems and For example, utility companies can decide the energy
networks; price at a given time of the day just some hours in
iv) Delivery Semantics are helped out by a advance. Saving money by consuming energy when
combination of low and high level protocols that it is cheaper can be done only if energy prices are
offer good reliability to the communication. received from the utility companies in a timely
manner.
ii) Cooperation between the smart houses: some
3. Relevant messaging systems level of interaction is needed to orchestrate the
operations of the energy consumers, for example to
A smart grid is a complex system where many switch on/off the appliances of houses at different
actors interact, on both the data plane and the energy times. In fact, should every house switch on/off the
plane. The resulting complexity precludes the appliances using a deterministic algorithm based on
development of monolithic applications, since the global parameters only, like the price of energy,
software would be overcome by a huge quantity of every house would switch on its appliances at the
“housekeeping”   details   (managing   networking,   data   same time, thus creating a hot spot that can result in
storage, interaction with electrical hardware, etc), and black-outs for the excess of energy consumption.
the plethora of device drivers that such application Communication middleware can be categorized as
should include to be able to interact with the Remote Procedure Call (RPC) oriented Middleware,
electrical hardware, since vendors have developed Transaction-Oriented Middleware (TOM), Object-
many custom protocols for their devices. A Oriented/Component middleware (OOCM) and
middleware has the function of providing abstraction Message-Oriented Middleware (MOM). Figure 2
to allow the developer to focus on the business logic displays these categories.
of the application (the intelligence behind the choices
made by the application). The final effect is a lower
time-to-market for applications, and a reduction in
the number of bugs in the released software, since the
mechanisms of the middleware are implicitly
debugged by all the application developers that are
using   the   middleware’s   functionalities   in   their  
projects.
 Middleware Considering the paradigms introduced above, and
the requirements of the smart grid, it is possible to
argue their suitability in middleware for smart grids.
Remote Procedure
Calls
Transaction-
Oriented
Message-
Oriented
Object-Oriented The RPC model is focused on distributed systems
based on client-server model, while it is not a
preferred choice for event-oriented applications, since
Publish Message Message Passing
its interactions are inherently synchronous hence
subscribe Queuing
limiting its scalability to large volumes of data.
Transactional middleware aims at providing safe
Figure 2 - Categories of Middleware interactions with one or at most a small number of
databases, it enriches the data with controls and
A Remote Procedure Call (RPC) middleware redundancies for data safety, and it results in low
provides functionalities and infrastructure to call scalability in both the data volume that can be
procedures on remote systems, without worrying handled, and in the number of interacting actors;
about the communication details. Any API call that moreover, according to [17] the QoS guarantees they
involves RPC interface is synchronous to the user, provide are often unnecessary or undesirable for most
since it waits until the server returns a response; even applications. Object-oriented middleware has
if it is possible to encapsulate the API call in a multi- synchronous requests as its default form of
threaded workflow to asynchronies it, the resulting interaction, however many systems include support
system would be not scalable and with a low fault- for asynchronous communications. Not being
tolerance capability [13]. designed for concurrent event management, these
A Transaction-Oriented Middleware (TOM) is usually do not attain the same level of performance as
used to ensure the correctness of transaction systems explicitly designed for the event-based
operations in a distributed environment. It is interaction paradigm [18]. Since data of smart grids
primarily used in architectures built around database are collected and exchanged as the result of events,
applications [14]. TOM supports synchronous and the interaction paradigm of choice appears to be the
asynchronous communication among heterogeneous Message-Oriented Middleware (MOM) [19].
hosts, and it eases integration between servers and Delving more deeply into MOMs, it appears that
database management systems. they   come   in   different   “flavours”   and   they   can  
An Object-Oriented/Component Middleware support one or more communication paradigms,
(OOCM) is based on object-oriented programming which can be broadly categorized as:
models and supports distributed object request. i) Message Passing, which involves direct
OOCM is an extension of Remote Procedure Calls communication between applications. The interacting
(RPC), and it adds several features that emerge from parties are defined explicitly, and the main
object-oriented programming languages, such as communication abstraction is the channel between
object references, inheritance and exceptions. These two applications. In message passing MOM, the
added features make OOCM flexible, and add to its middleware has the role of facilitating the setup of
expressivity [15]. the  channel,  for  example  by  resolving  “names”  of  the  
A Message-Oriented Middleware (MOM) allows applications to their network addresses, but it does
message passing across applications on distributed not mask the identity of the interacting parties;
systems. A MOM provides several features such as: ii) Message Queuing, where the communication is
i) asynchronous and synchronous communication performed via message queues. The middleware
mechanisms; ii) data format transformation (i.e. a hosts facilities to create and access message queues,
MOM can change the format of the data contained in which are named entities that receive messages from
the messages to fit the receiving application [16]); iii) different applications and dispatch them to all
loose coupling among applications; iv) parallel interacting parties that have subscribed to the queue,
processing of messages; v) support for several levels in a First In First Out (FIFO) manner. A special cases
of priority. of message queuing is Publish/Subscribe, where
messages   are   actually   events   that   are   “published”   to   MOM

peers   that   “subscribed”   to   them.   In   particular,   Subscriber A

Publish/Subscribe systems can be: Topic 1

a) topic-oriented, if subscribers receive all Publisher

Subscriber B

messages published to the topics they subscribed Topic 2

to. In this interaction paradigm the topic takes Subscriber C

the place of the message queue;
b) content-oriented, if messages are delivered
to subscribers based on conditions that filter the Figure 3 - Subscription to topics controls the message types that
events. This can be built using “topic-oriented”   reach each subscriber
systems by considering the pipeline that delivers
the message to the subscriber, and inserting into Figure 3 depicts an example of topic-oriented
it a filtering application that performs deep PSMOM where four applications connect to a MOM
inspection of the messages. broker. The Publisher application sends messages to
c) data-oriented interaction, where parties Topic 1 and Topic 2. The topics operate as relaying
share data structures, and every change to the
systems, forwarding related messages only to
data  is  “published”   to  the  other  parties.  Usually,  
interested subscribers. In the case at hand, Subscriber
a limited set of peers can change the data, and
A subscribes to Topic 1, Subscriber B subscribes to
the rest can only receive data changes. If a new
peer gets into the system: instead of sending him Topic 1 and Topic 2, and Subscriber C subscribes to
all the messages regarding the topics it is Topic 2, and all receive messages according to their
interested into, the middleware can send him just subscriptions.
the final status of the data it subscribed to. The rest of this section will discuss examples of
A Publish Subscribe Message-Oriented MOMs. In particular, Extensible Messaging and
Middleware (PSMOM) encapsulates the Presence Protocol (XMPP) [21] will be the
communication primitives related to that interaction placeholder for message passing systems, AMQP
paradigm, and provides asynchronous and highly [22] will be the representative for message queuing
scalable many-to-many communication model [20]. and PSMOMs, and Data Distribution Service (DDS)
In this scheme, senders and receivers of messages [23] will be used as the data-oriented interaction
interact through an intermediary, the PSMOM. The system of choice. We will not report any content-
sender of the message, called publisher, is not aware oriented message queue system, since they choose the
of the identity of recipients (subscribers), and it message recipient by performing deep packet
publishes its messages to the PSMOM. Subscribers inspection; this latter characteristic leads to high
are enabled to receive the messages from the computational complexity and causes severe
PSMOM by performing subscriptions of the limitations on their performance and scalability, thus
information they are interested in. impeding their market acceptance.
The publish/subscribe scheme concurs to creating
systems decoupled in terms of space, time and 3.1. Extensible Messaging and Presence Protocol
synchronization. Space decoupling means that (XMPP).
publisher and subscriber do not need to be aware of
each   other’s   location   or   identities.   Time   decoupling   The Extensible Messaging and Presence Protocol
means that publisher and subscriber do not need to be (XMPP) is an open eXtensible Markup Language
online and actively collaborating in the interaction at (XML) protocol specified by the Internet Engineering
the same time. Synchronization decoupling allows Task Force (IETF) for near-real-time messaging,
asynchronous notification of subscribers by using presence, and request-response services [21]. This
event services callbacks. protocol is of the message passing kind, since
applications do not abstract from the identity of their
peers. Still, its main applications are based on
extensions to the basic XMPP protocol, and are
 - the creation of multi-user chat rooms, similar called XML stanzas: Message, Presence, and IQ
to Internet Relay Chat systems [24] (info/query). The Message stanza is sent from one
- application-layer publish/subscribe systems, entity   to   another,   adhering   to   the   “push”   paradigm,  
where the clients are the interacting parties and among its uses there is instant messaging. The
and the server is the router of the messages Presence stanza is used to publish messages to all
[25] involved subscribers, and it usually manages
In fact, XMPP was originally developed for notifications regarding the applications that are active
instant messaging applications in the project Jabber, in the XMPP network. The IQ stanza is used to send
and it has characterized by the large number of a message that must be followed by a response, like
protocol extension it received. For example, XMPP in REST, and it is used to set up connections for
has been extended to support voice and video streaming of either XML, or out-of-band binary data.
communications. The main implementation of the In fact, while all in-band messages are encoded using
protocol aims at scalability, having the goal of the XML format, out-of-band messages can be used
delivering data from a large number of connected to transport binary data for efficiency reasons.
devices to many user applications. The built-in
functionalities of XMPP include XML streaming, 3.2. Advanced Messaging Queue Protocol (AMQP)
encryption using Transport Layer Security (TLS),
authentication, Unicode support, and information This subsection discusses the Advance Messaging
about   publishers’   and   subscribers’   presence   in   the   Queue Protocol (AMQP) protocol [22], which is our
network. representative for the topic-oriented message queue
paradigm. The well-known publish/subscribe bus
XMPP Server 1 RabbitMQ [26] is an open source messaging broker,
Pub
Topic A Subs 1 and the most popular implementation of the AMQP
Topic B protocol.
AMQP defines the full protocol specification,
XMPP Server 2
comprising both the message encoding, and the
Topic    A’ semantic actions that correspond to the messages.
Topic  B’ Subs 2
Applications can communicate by sending messages
to a server of the AMQP overlay, which acts as
message broker. As shown in Figure 5, the
Figure 4 – XMPP general overview application can subscribe to a given channel, and can
send messages to a channel, which will be delivered
XMPP was introduced to get past the limitations to all the applications that subscribed to the channel.
of the traditional architecture of the internet, which is AMQP divides the brokering task between exchanges
based on cumbersome HTTP-like protocols and and message queues, where the first is a router that
request/response paradigm. XMPP introduces stateful accepts incoming messages and decides which
communication that can keep track of sessions queues to route the messages to, and the message
between the server and the clients. XMPP is based on queue stores messages and sends them to message
the client/server paradigm, and Figure 4 shows its consumers.
general overview. Two applications, identified by a
unique identifier called Jabber Identification (JID), AMQP

can communicate by connecting to a XMPP server Subs 2

and exchanging XMPP messages, which are routed Pub Ex

through   the   servers   down   to   the   message’s   Subs 3

destination.
XMPP specifies that communication happens via
three different kinds of communication snippets
Figure 5 – AMQP general overview
 The message queue abstraction inherently propagating the related changes to the data to all
supports the chain of responsibility design pattern subscribers.
[27], which pipelines a complex task into smaller
steps. Each application in the pipeline acts on the DDS

message along the way, adding to the message and/or Struct

Struct
Subs 2

modifying its form, and finally rejecting it or passing

Struct
ID:
Pub ID:ID:
Value:
Value:
it to the following application via another message
Value:
…
……
Subs 3
queue.
A feature of AMQP is the option to define a
message   as   “persistent”.   This   implies   that   the  
Figure 6 – DDS general overview
message is stored on the AMQP server and,
whenever a new application gets into the system, it
DDS uses a data model based on structures, which
will receive all the persistent messages, to be put on-
are identified by a topic and a type. The topic
track regarding the current status of the distributed
provides a unique identifier to the structure within the
system. This mechanism provides an automatic boot-
global data space. The type provides structural
up mechanism for applications, since they will be
information, needed to inform the middleware on
informed regarding the current status of the system,
how to manipulate the data and to provide type
stored into the persistent messages, and the
safety. When updating a data structure, a client uses
applications will be able to act like applications that
the type information to perform a preliminary check
have been in the system for some time. On the other
on the correctness of the update, and thereafter uses
hand, if too many messages are stored, their delivery
the topic to deliver the update request to the correct
to new applications will create much traffic and
DDS server. The DDS middleware will be in charge
introduce unpredictable delays into the new
of performing sanity checks on the update at hand,
applications’  boot-up.
apply it on the data structure, and contact all
subscribed clients.
3.3. Data Distribution Service (DDS).
DDS provides data structural persistence, meaning
that an application receives at boot time the current
The Data Distribution Service for Real-Time
state of the data it subscribed to. This is more
Systems (DDS) [23] standard has been defined by the
efficient than the mechanisms of message queue
Object Management Group (OMG) organization, to
systems, since the latter ones would deliver a
create a data-oriented messaging system. DDS has
message for each change that has been made to the
been designed with an emphasis on high-performance
data structure.
and predictability, where the former is ensured by a
Apart of its data model, DDS is characterized by
lightweight architecture, and predictability is ensured
its set of QoS policies for guaranteed data delivery,
by its capabilities to reserve resources by enforcing
real-time performance, bandwidth reservation,
prioritization on the communications [28].
redundancy, and data persistence. DDS was
DDS is based on the Data Centric Publish-
standardized to let multiple companies develop their
Subscribe (DCPS) model, which models a distributed
own DDS stack, and the standard addresses the whole
global data space (represented in Figure 6). This
stack, comprising middleware architecture, the
distributed shared memory is reachable by
Application Programming Interface (API) to access
participating nodes via a set of interconnected
its services, and the message formats used in the
servers. Publishers are applications that write
protocols. The goal of this standardization process is
information to the distributed data space, while
to provide interoperability between DDS stack
consumers are applications that are able to read on
produced by different vendors.
the distributed data space. Consumers are registered
onto the DDS middleware, thus when data is created
or modified by the publishers, DDS takes care of
3.4. Differences and convergences between the messaging systems, this section provides some
paradigms examples on middleware designed to support the
smart grid data plane.
The three approaches that were discussed are not
in contrast with each other, and can actually be seen 4.1. Example of an XMPP based system
as mutual refinements.
It is possible to assemble a message queue system The example discussed in this section is part of the
from a message passing system by creating an ad-hoc Arrowhead project [29], which addresses the energy
application having a globally known name, like it is and competitiveness challenges by studying new
done in the case of RabbitMQ solution [26]. The dynamic interactions between energy producers and
application will act as a broker and it will take care of energy consumers, machines, people and systems.
managing subscriptions of queues, with the queue Arrowhead bases its architecture on a Service-
name contained in the payload of the messages. Oriented Architecture, which is regarded as a suitable
Similarly, the broker application will receive data paradigm for collaborative automation in an open-
messages that contain a queue name, and it will relay network environment connecting large quantities of
the  messages  to  all  the  applications  that  “subscribed”   embedded devices [30].
to that queue name. Among the different pilots of Arrowhead, its
Similarly, it is possible to assemble a data-oriented virtual market of energy builds upon the smart grid to
messaging system from a message queue system by implement the flex-offer concept. Figure 7 depicts
simulating the shared memory space via two queues one of the interconnection solutions that can be used
per data structure, one for updating the data structure in an Arrowhead-compliant system using the virtual
and one to receive notifications regarding data market of energy.
structure changes. The queues will communicate with Flex-offers are a type of Demand/Response (DR),
an application that manages the data structure, in which an energy consumer (a device) is capable of
receiving changes and providing updates to the expressing its consumption flexibilities, in terms of
subscribers of the data structure. time and power. A Flex-Offer Agent (FOA) is
It is possible to refine every system under responsible for transmitting flex-offers to an
consideration by adding complexity into the Aggregator, which is then capable of joining flex-
architecture, for example by adding more connected offers from several FOAs and places a larger flex-
server applications for redundancy and high offer on an energy market. If the offer is accepted by
performance. A custom message queue system built the market, the Aggregator replies to the FOA that
on top of other paradigms can present a better controls the device.
performance than COTS message queue systems,
since custom systems are focused on solving the
technical problems of a particular application, while
COTS systems are more generic. Obviously, this kind
of development would take time and programming
and testing efforts. This is a natural trade-off between
the performance of the final system, and the time-to-
market of the application. There is no one-take-all
solution, but every applicative scenario needs its own
technical and economic analysis.
Figure 7 – Arrowhead XMPP-based Architecture

4. Case studies In this architecture the communication between

the Aggregator and the FOAs is implemented using
In order to allow for a better understanding of the XMPP, and exploits the Arrowhead Framework
different nature and applicability context of these
services to establish the most adequate connections the system to be extended by the application of
and to control the connection status. XEPs.
The FOA was designed to be executed as a Most importantly, XMPP is also in a process of
software module, which can run on multiple devices; being standardized as a protocol for the control of
in the case of Figure 7 it is executed on the HAN Demand Response applications for OpenADR [32]
Gateway. The architecture is based on two and on the ISO/IEC/IEEE 21451-1-4 [33] standards.
hierarchical levels. The first level connects the HAN
Gateways with the devices using XMPP extensions 4.2. Example of an AMQP based system
for the Internet of Things (XEP – 0323) [31]. XMPP
is particularly suitable for this scenario due to its The ENCOURAGE project [3] aims at developing
capability to support the Publish/Subscribe user-side smart grid technologies, for the seamless
communication paradigm, which provides an interaction of existing devices by different vendors,
asynchronous and highly scalable many-to-many fine-grained remote control of user's appliances, and
communication model. energy brokerage between neighbours.
Communications between FOAs and Aggregators
is performed on an independent XMPP bus (in Figure
7 named XMPP1), which integrates the Arrowhead
Framework modules for system discovery,
orchestration and authorization. The main advantage
of this architecture relies on its capabilities of
interoperability and on the decoupling between
Publishers and Subscribers, in time, space and
synchronization, which simplifies the implementation
of FOAs and of the Arrowhead Framework modules.
Several types of Aggregators might exist, and
some Aggregators can be more specialized on certain
types of devices. Choosing the most adequate Figure 8 – ENCOURAGE RabbitMQ-based Architecture
Aggregator also depends on the geographical area,
thus to obtain the address of a proper Aggregator, a The ENCOURAGE platform [3] considers the
FOA uses the Service Registry module, to register world divided into macrocells, which are sets of
itself, and the Orchestration module (to obtain an residential and commercial buildings which are co-
Aggregator that matches its criteria). The located in the same area, share the same
Orchestration module contains information about environmental condition (weather), are connected and
connection rules and system configuration. Security can exchange energy. The macrocell is further
services are provided through the Authorization divided into cells, which are residential/commercial
module, which implements authentication supported space that pertains to the same user economically.
on combination of Public key Infrastructure (PKI) The ENCOURAGE architecture, depicted in Figure
and X.509 certificates. All communications can be 8, is articulated into 4 modules:
encrypted by using XMPP [21] over Transport Layer - Energy Brokerage and Business Intelligence
Security (TLS). module, which considers energy usage of the whole
The coexistence of different services on the macrocell, optimizes energy exchanges and
messaging bus, together with the different paradigms consumption schedule, and provides off-line report.
of interaction used (publish/subscribe vs - Supervisory Control module, which works at the
request/response) and to the potential extension in the level of the cell and computes strategies to allocate
direction of adding more services in the system, leads the energy available through the EB&BI module in
to choosing a more general messaging bus, based on the most efficient way, and sends commands to
message passing (XMPP). Moreover, XMPP allows actuators and appliances installed in user's homes.
 - Middleware module, which takes care of Basically, every exchange is substituted by a
connecting the other modules, encoding data in XML distributed namespace having the same name of the
format (CIM based), and delivers data efficiently by exchange, and the routing keys are mapped on the
means of communication through a AMQP-based hierarchical data contained in the namespace.
messaging bus. In the case of the data flow from the Virtual
In particular, the middleware module comprises a Device module up and vice versa, the system requires
Virtual Device (VD) that takes the roles of data communication and a notification system for
- cache, by keeping the current status of each when communication has happened, and these
sensor and actuator in the system, to provide the actions are covered by the DDS messaging bus.
datum to querying components without contacting Communication of data from the HAN to the VD
devices in user homes can be done through basic DDS distributed data
- database handler, by interacting with a database sharing, but the other way around (controls sent from
to keep a historical entry for each message that passes VD to the HAN) must provide an acknowledge
through the middleware mechanism for robustness sake; the latter can be
- router, by relating the unique id of a device to the implemented by another distributed data structure
gateway that must be reached to contact the device used just for acknowledgement notification.
ENCOURAGE provided a fully defined and stable
architecture, being clearly aligned with the
publish/subscribe interaction paradigm, and where
performance was a key driver. Due to this, the choice
was made for a messaging bus specialized for topic-
oriented message queuing communication, which
provides better system performance for messages
exchanged via publish/subscribe, and faster time-to-
market.

4.3. Example of a DDS based system

Figure 9 – ENCOURAGE DDS-based Architecture

This section describes an alternative design for the

The responsibilities of VD are as follows: router to
ENCOURAGE middleware for smart grids. The
relate device name (id) to the correct HAN, register
usage of DDS as the messaging bus underlying data
for online devices, caching of current values,
exchange can provide easier implementation of data
interaction with DB for storage of data historicals.
dissemination and outsources its efficiency to the
While the caching of current value can be done
mechanisms provided by DDS, while not impacting
directly by the messaging bus, storing historical data
much over the functioning pertaining to the
directly in the distributed data space can lead to low
request/response paradigm. Still, the system designer
performance since the distributed data space would
has to relinquish the control over to the messaging
become very large; thus, there is still the need for an
bus; even the large configuration space of DDS
application to store data on a DB. Registry and
cannot compete with providing one own's
routing functionalities can be implemented through a
implementation on the application layer. Thus, the
distributed namespace, even though the logic for the
optimal solution to this trade-off depends on how
wiring of the connections (choosing the correct
much the stress is on the fine grain control on data
elements in the distributed namespace) would have to
communication and on the side effects to be
be moved to each component; the other option is to
performed together with communication.
have the logic kept into a specific component. Thus,
Let us consider the design presented in the
the VD cannot be substituted directly by the
previous subsection and let us remap it over a DDS-
messaging bus, at least for sake of performance.
based middleware, starting the analysis from the
Should performance not be an issue, VD could be
communication between the components.
completely disregarded, by moving its logic into the ordering and dropping messages. Publishers assign
middleware library used by the components to relative priorities to their messages, to control the
implement their interaction with the messaging bus. broker’s   queues;;   subscribers   allocate   the relative
The design presented in this case study was based priorities among their subscriptions.
on an analysis that showed that not only it was In XMPP, Resource Application Priority extension
possible to limit the interaction paradigm to protocol (XEP – 0168) [34] allows a client to specify
publish/subscribe, like in the previous case study, but the priority of an application, over other applications
also that some functionalities of the system could be of the same client, with the purpose of assigning
simulated directly by a specialized messaging bus. more (network) resources to more important
While in the comparison between message passing applications.   The   XMPP   “application”   definition   is  
(XMPP) and topic-oriented message queuing deliberately loose and defined by examples (possible
(AMQP) the trade-off was flexibility vs performance applications are messaging, voice chat, collaborative
and time-to-market, this time a more specialized data- editing, etc.). XMPP has not a mechanism to
oriented message queuing messaging bus led to less prioritize routing in multi-hop paths, hence the
code to be developed, and thus faster time-to-market priority   involves   the   first   “hop”   only,   and   after   a  
and better maintainability, since some functional message is sent, the rest of the delivery mechanism is
requirements were already satisfied by the underlying plain TCP/IP.
messaging system and needed no component; on the In systems built over AMQP, a publisher
other hand, data-oriented message queuing buses prioritizes messages by assigning a value from 0 to 9
such as DDS do not allow fine grained control on the to each message, to specify that the message must be
actions to be performed after each event, thus transferred between queues before lower priority
impeding optimization of the system and potentially messages. This mechanism in not related to a single
causing performance loss. client, and it is instead imposed on a global level,
hence all the elements of the distributed system must
agree on common values for the same levels of
5. Evaluation of messaging systems on a smart priority.
grid scenario DDS provides QoS policies for the definition of
message transport priority. The transport priority QoS
The particular requirements of smart grids impact policies allow a DDS application to deliver messages
on the definitions of the layers supporting them. The with different priorities. DDS has got the advantage
capabilities of a message oriented-middleware of proposing different means to cope with message
(MOM) play a critical role in the overall system priorities and ordering, while XMPP and AMQP
performance especially with the increasing demand propose basic approaches to prioritize messages. The
from applications that require soft real-time flexibility of DDS can be interesting for a variety of
publish/subscribe services. Thus, the data plane of a applications but, in the case of smart grids, prioritized
smart grid needs to grant correctness and time message delivery is required only for fast and time
predictability to the information it transports. predictable delivery of commands to appliances, and
In the discussion that follows, we elaborate on the to specify looser time constraints for historical data
analysis of Section 2, which provides a set of transfers. Thus, AMQP and DDS are the best
requirements for middleware supporting a smart grid mechanisms as far as this metric is concerned, since
(Table 1), by analyzing the MOMs described in XMPP  only  prioritizes  the  first  “hop”  from  the  source  
Section 3 in relation to: prioritization, delivery to the destination.
semantics, scalability, latency, time predictability Delivery semantics involves mechanisms to
(low jitter), dynamicity, and data bandwidth. protect communication from message losses,
Expressing and implementing politics regarding duplicated messages, and messages re-ordering. By
Prioritization is important in time-critical distributed bestowing the responsibilities on Delivery Semantics
systems. The requirement of message priority on basic network mechanisms, like the IP layer, as it
mechanisms impacts on the broker decisions on happens with UDP, best effort delivery semantics is
prone to all the problems related to best effort towards the service centers, and one-to-one to deliver
communications, which means that there is no the commands from the service centers to the HANs.
reliability guarantee and messages can be duplicated These requirements favor systems that provide an
and re-ordered. While direct communication can abstraction over the identity of the subscribers, like
easily implement delivery semantics by for example message queues and data-oriented systems, since it
using TCP mechanisms, publish-subscribe disencumbers clients from maintaining a list of the
communication must use more refined techniques for peers that subscribed to their data. Except for the
message re-transmission. In the case of smart grids, discussion on the programmability of scalable
Delivery Semantics allow the subscriber to maintain systems, the efficiency of the systems reduces to
a logical order over changes made by multiple three views, the network point of view, the publisher
publishers to the virtual representation of a smart grid point of view, and the subscriber point of view.
element, combined with using timestamps on As far as network is concerned, latency relates to
produced messages to take care of re-ordering. the time that the message takes to be transported over
In XMPP, the Advanced Message Processing the network. From the publisher side, the delivery
(AMP) (XEP – 0079) [35] protocol allows publisher time of the messages can be critical since some
and subscriber to define additional delivery semantics messages, such as control messages (e.g. to take care
for advanced processing of XMPP message stanzas, of potential outages), are useful only within a
including reliable data transport. Anyway, concurrent bounded amount of time. Important aspects related to
changes to common data structures can impact the publish/subscribe   systems’   latency   are   the   topology  
correctness of distributed applications, since the final of   the   system,   the   routing   protocol,   and   the   broker’s  
states of semantically identical applications can be workload. In fact, the topology gives an assessment
different. of how many brokers exist in the path between
AMQP uses queues with guaranteed delivery to a publisher and subscriber, and what is the impact of
single recipient. Since messages have to get through the MOM layers in this delay. The routing protocol
bottlenecks represented by queues, concurrent influences the latency since the travel time among
changes to a resource are implicitly serialized. different hops can vary, depending on how the
AMQP ensures content ordering by exploiting the overlay network routes messages among nodes [36].
TCP/IP transport layer. Messages are delivered in the Finally, part of the latency is not caused by network
order in which they are sent. transmission, but instead it is the time a message
DDS provides a QoS policy for reliability that spends in each broker waiting to be processed, and it
specifies two different data delivery guarantee depends  on  the  broker’s  load.
modes,  named  “Reliable”  and  “Best  Effort”.  Reliable   The XMPP protocol is basically a best effort
guarantees  mean  that  all  messages  in  a  “Data  Writer”   protocol with an Extension Protocol (XEP) that
history   will   be   delivered   to   the   correspondent   “Data   supports QoS functionalities. XEP – 0203 [37]
Reader”.  Best  effort  indicates  that  a   message  is only provides timestamp information regarding stored
sent once, and should the transmission fail, the messages, which can be useful in case of late
message will be lost. Moreover, DDS provides QoS delivery, so that if a message is delayed, the original
policies to control the order of received messages. send time can be determined.
XMPP appears worse off with respect of this Beside time-stamping messages to measure
metric, while AMQP and DDS are both capable of latency, AMQP uses a method called "pre-fetch" to
expressing Delivery Semantics that are rich enough determine how many messages will be sent before the
for smart grid application. customer acknowledges a message. The objective is
The functional requirement of Scalability and the to send message data in advance, to reduce latency
network behavior in terms of network Latency and [22].
time predictability (low jitter) differ from the case The DDS protocol aims at low message latency
of usual internet communication. In fact, smart grid and jitter by using fewer layers in comparison with
communications are many-to-some for data other middleware technologies. DDS supports a
collection from the Home Area Networks of the users number of QoS policies, providing guarantees on the
maximum latency for data delivery, latency budget, reboot some important data structures, and act like
reliability of data delivery, priority of data delivery, XMPP for the rest of the distributed state.
and deadline policy; if used in the correct way, this DDS is data-oriented, hence it keeps trace of the
set of QoS policies can reduce latency and jitter current state of shared data structures. The internals
significantly. The latency-budget policy defines the of DDS keep trace of shared structures, and provide
maximum acceptable delay from the time the data is persistency to them instead of the messages related to
sent until the data is received by a subscriber data changes. The result is that a much lower traffic
application. The deadline policy specifies the is generated for each persistent data structure.
maximum inter-arrival time between messages, and it With respect to this metric, DDS is a clear winner.
defines the maximum duration that a “Data   Reader”   Anyway, if the system maintains virtual
expects to elapse between the change of a value, and representations of smart grid devices, there are
the update of the values contained in each probably applications updating the state of the
subscriber’s  instance.   devices, and these applications could use databases or
XMPP does not have active control on latency and log files to save their state, hence implementing a
jitter. AMQP has mechanisms to improve (minimize) data-oriented persistence, limited to data actually
latency. On the other hand, DDS goes one step requiring it.
further by making efforts to cope with time The overall Data Bandwidth of the system
predictability by enforcing reliability in the depends on the throughput of the broker and the size
communication, at the cost of a more complex of each message. In this case publishers can identify
programming of the system. the upper and lower bounds for the output stream and
Supporting Dynamicity implies that the system is a subscriber can limit the maximum bandwidth used
able to perform fast reconfiguration as the smart grid for receiving the messages. The different paradigms
participants change over time. Apart from the limits we considered in the last sections are not focused on
of the underlying network, which are related to the maximizing Data Bandwidth, still it is interesting to
available bandwidth, the requirement of Dynamicity analyze the mechanisms and functionalities available.
copes with fast adding and removal of elements in the These are representative of the communication
network, and with fast recovery of the shared state of paradigms and hence they can provide insights
the distributed system into the new element of the regarding what can be done to improve Data
network. Bandwidth while still abiding to the rules of a
XMPP does not have the concept of distributed communication paradigm.
state. Interactions are performed by means of remote The protocol defined by XMPP XEP – 0138 [38]
procedure calls, and a new peer must contact defines an extension standard for negotiating
explicitly other elements to retrieve data regarding compression of XML streams that supports a wide
current distribute state. This implies a burden on the range of compression algorithms, and early
programming, and the need to implement primitives measurements showed that it can reduce bandwidth
that are native in other communication paradigms. usage up to 90% [21]. The protocol Jingle RTP
AMQP uses different delivery modes for different Sessions (XEP – 0167) [39] enables applications to
kinds of data, to specify if a message needs communicate through negotiated sessions that use the
persistence.   “Persistent”   messages   are provided to Real-time Transport Protocol (RTP) to exchange
new peers by saving them in a log file, and sending voice or video data, which has the drawbacks of best
them to each application that associates to the effort protocols, but it is lightweight, minimizing
middleware in the future. If the system selects delay and maximizing data bandwidth.
persistency for many messages, every time that a new The RabbitMQ implementation of AQMP
client associates to the system a large amount of provides facilities to multiplex several connections
traffic is generated to deliver every persistent into one TCP/IP channel, making efficient use of the
message to the new client. An alternative is to save network ports, and allowing the available bandwidth
only a few messages into the persistent log file to fast to be shared among concurrent activities at the
application layer.
 DDS controls network bandwidth by using the This paper surveys paradigms and technologies
“time-based-filter”   policy,   which   defines   the   that support the MOM communication paradigm. Our
minimum inter-arrival time between messages. Also, analysis led us to the conclusion that XMPP has not
DDS   uses   the   “resource-limit”   policy   to   control   the   been developed in order to support real-time
amount of message buffering in the queues. These constraints, and it mostly targets best-effort
policies concur to save network bandwidth, and applications. The applicability of XMPP to smart grid
potentially can provide high throughputs [40]. scenario depends on the usage of extensions to the
Moreover, the time-based-filter policy allows protocol, which bring this simple protocol to the level
handling different production and consumption rates of the more complex AMQP and DDS. AMQP is
without overflowing consumers. All of the discussed used for high performance distributed system
systems are good candidates for smart grids with applications, and it is an open cloud messaging
respect to this metric. platform for real-time on a global scale. On the other
Table 2 summarizes the discussion of this section hand,   AMQP’s  focus  is   mostly  on  high  performance  
regarding the relative merits of the different and not on predictability. DDS targets distributed
messaging buses. real-time systems [41] and therefore it is capable of
addressing complex distributed applications, where
Table 2 Merits of the messaging buses with respect to the prioritization requirements have to be guaranteed.
middleware requirements In the case of smart grid applications, message
XMPP AMQP DDS queues and data-oriented middleware are both viable
Prioritization XEP - 0168 Yes Yes approaches. The data-oriented middleware we
Delivery Semantics XEP - 0079 Yes Yes considered (DDS) is much more complex but it
Scalability, XEP - 0138 Yes Yes provides many QoS policies to be used for improved
Latency reliability of the middleware, which are not required
Time Predictability XEP - 0167 No Yes in the case of smart grid applications. On the other
(Jitter) hand, in the scenarios at hand, data-oriented
Dynamicity No No Yes approaches support more dynamic scenarios, and
Data Bandwidth Yes Yes Yes message queues should be enriched by applications
maintaining shared data structures to fill the gap and
be at the same level of data-oriented middleware.
6. Conclusions Apart for message queues needing to maintain
shared data structures, topic-based message queuing
Ensuring high performance and advanced appears to be as good as data-oriented middleware.
communication capabilities for bidirectional data Having ruled out basic XMPP that does not employ
flows in the middleware layer is a key requirement XEP extensions, the choice between DDS and
for systems requiring high scalability, such as smart AMQP has to be solved by using different criteria,
grids. In this paper, we described the main features of like monetary cost for using the middleware as
different categories of middleware, and identified codebase of a system, and the current expertise of the
reasons to prefer Message-Oriented Middleware developer with the messaging paradigms. When XEP
(MOM) over the other categories. To effectively take extensions are taken back into the picture, XMPP
advantage of distributed communication through a takes the form of many different protocols, depending
MOM, a large-scale data infrastructure must employ of which XEP are in use, and it must be analyzed as a
a scalable data middleware. The selection of the most different protocol for each XEP configuration in use,
adequate MOM technologies for Smart Grid while losing its most appealing characteristic, which
middleware is not a trivial task since the choice is its extensive use, even across application domains.
depends on the grid requirements and the features
they need, such as scalability, reliability, flexibility,
security and real-time data.
Acknowledgments [13] K.   Geihs,   “Middleware   challenges   ahead”,   IEEE   Computer,  
June 2001, 34(6): 24--31
[14] L.  Capra,  W.  Emmerich,  C.  Mascolo,  “Middleware  for  Mobile  
This work was supported by National Funds Computing”,   UCL   Research   Note   RN/30/01,   Submitted   for  
through FCT (Portuguese Foundation for Science and publication, July 2001
Technology) and by the EU ARTEMIS JU funding, [15] R.   Nunn,   “Distributed   Software   Architectures   Using  
within ENCOURAGE project, ref. Middleware”,  3C05  Coursework 2
ARTEMIS/0002/2010, JU grant nr. 269354, and [16] E.  Curry,  D.  Chambers,  and  G.   Lyons,  “Extending  Message-
Oriented Middle-ware  using  Interception”,  presented  at  Third  
within Arrowhead project, ref. ARTEMIS/001/2012, International Workshop on Distributed Event-Based Sys-tems
JU grant nr. 332987. This work was also supported (DEBS '04), ICSE '04, Edinburgh, Scotland, UK, 2004
by National Funds through FCT and by ERDF [17] V. Issarny, M. Caporuscio,  N.  Georgantas,  “A  Perspective  on  
(European Regional Development Fund) through the Future of Middleware-based   Software   Engineering”,  
COMPETE (Operational Programme Thematic Future of Software Engineering, IEEE-CS Press, 2007
[18] E. Tokunaga, A. Zee, “Object-Oriented Middleware
Factors of Competitiveness), within SENODs Infrastructure for Distributed Augmented   Reality”,   ISORC
(FCOMP-01-0124-FEDER-012988) project. 2003
[19] E. Curry, "Message-Oriented Middleware", in Middleware for
Communications, Q. H. Mahmoud, Ed. Chichester, England:
References John Wiley and Sons, 2004, pp. 1-28
[20] P. T. Eugster, P. Felber, R. Guerraoui, A-M. Kermarrec,  “The  
Many Faces of Publish/Subscribe”,  ACM  Computing Surveys
[1] R. DeBlasio, C. Tom,  “Standards  for  the  Smart  Grid”, Proc. of
35(2), 2003, pp. 114-131
IEEE Energy 2030 Conference (ENERGY 2008), pp. 1-7, 17-
[21] P. Saint-Andre, K. Smith, and R. Troncon,   “XMPP:   The  
18 Nov. 2008
Definitive  Guide”,  O’Reilly,  2009
[2] S. Rusitschka, K. Eger, C. Gerdes,  “Smart Grid Data Cloud: A
[22] AMQP Advanced Message Queuing Protocol, Protocol
Model for Utilizing Cloud Computing in the Smart Grid
Specification, Version 0-9-1, 13 November 2008,
Domain”, Proc. of First IEEE int. conf. on Smart Grid
http://www.rabbitmq.com/resources/specs/amqp0-9-1.pdf
Communications (SmartGridComm 2010), pp. 483-488, 4-6
[23] Object   Management   Group,   Inc.   (OMG),   “Data   Distribution  
Oct. 2010
Service for Real-Time Systems   Specification”,   Version   1.1,
[3] M. Albano et al, “The   ENCOURAGE   ICT   architecture for
December 2005
heterogeneous   smart   grids”,   IEEE   Eurocon   Conference
[24] P. Saint-Andre,   “XEP-0045: Multi-User   Chat”,   8   February  
(Eurocon 2013), Zagreb, Croatia, 1-4 July, 2013
2008, http://xmpp.org/extensions/xep-0045.html
[4] “NIST Framework and Roadmap for Smart Grid
[25] P. Millard, P. Saint-Andre, R. Meijer,   “XEP-0060: Publish-
Interoperability Standards”, Release 2.0, 28 Feb. 2012
Subscribe”,   12   July   2010,   http://xmpp.org/extensions/xep-
[5] CEN/CENELEC/ETSI, “TR  50572:2011  Functional reference
0060.html
architecture for communications  in   smart   metering   systems”,
[26] A.  Videla,  J.W.   Williams,  “RabbitMQ  in  Action:  Distributed  
December 2011
Messaging   for   Everyone”   MEAP   Edition,   Manning   Early  
[6] International   Electrotechnical   Commission,   “IEC 61970-301,
Access Program, 2011
Energy management system application program interface
[27] S. Vinoski, "Chain of responsibility," IEEE Internet
(EMS-API) - Part 301: Common information model (CIM)
Computing, vol.6, no.6, pp.80-83, Nov/Dec 2002
base”,  June  2011
[28] H.P. Tijero, J.J. Gutiérrez, “On the schedulability of a data-
[7] International  Electrotechnical  Commission,  “IEC 61968-11 –
centric real-time distribution middleware”, Computer
Common Information Model (CIM) Extensions for
Standards & Interfaces 34(1): 203-211 (2012)
Distribution, ed. 2.0”,  March  2013
[29] Luis Lino Ferreira et al, "Arrowhead Compliant Virtual
[8] ZigBee  Alliance,  “Smart  Energy  Profile 2.0, draft 0.9, Public
Market of Energy", 9th IEEE International Conference on
Application  Profile”,  2010
Emerging Technologies and Factory Automation (ETFA
[9] European Telecommunications Standards Institute, “ETSI  TR
2014), Barcelona, Spain, Sep. 19-21 2014
102691, Machine-to-Machine communications (M2M); Smart
[30] Fredrik Blomstedt et al, "The Arrowhead Approach for SOA
Metering  Use  Cases”,  May  2010
Application Development and Documentation", 40th Annual
[10] R. T. Fielding, “Architectural Styles and the Design of
Conference of IEEE Industrial Electronics Society (IECON
Network-based Software Architectures”, Ph.D. thesis, Univ.
2014). 2014. Dallas, U.S.A.
of California, Irvine, 2000
[31] P.   Waher,   “XEP-0323: Internet of Things - Sensor Data”,  
[11] European   Telecommunications   Standards   Institute,   “ETSI
http://xmpp.org/extensions/xep-0323.html, April 2014
Group specification GS OSG 001: Open Smart Grid Protocol,
[32] OpenADR Alliance, http://www.openadr.org/
v.  1.1.1”,  January  2012
[33] “ISO/IEC/IEEE  P21451-1-4 Standard for a Smart Transducer
[12] Microsoft, “Smart Energy Reference Architecture (SERA)”,
Interface for Sensors, Actuators, and Devices based on the
2009
 eXtensible Messaging and Presence Protocol (XMPP) for [37] P. Saint-Andre, “XEP-0203:   Delayed   Delivery”,  
Networked   Device   Communication,”   Available   online   at   http://xmpp.org/extensions/xep-0203.html, September 2009
http://wiki.xmpp.org/web/Tech_pages/IoT_Sensei, accessed [38] J. Hildebrand, P. Saint-Andre,   “XEP-0138: Stream
April 2014. Compression”,   http://xmpp.org/extensions/xep-0138.html,
[34] P. Saint-Andre, J. Hildebrand,   “XEP-0168: Resource May 2009
Application   Priority”,   http://xmpp.org/extensions/xep- [39] S. Ludwig, P. Saint-Andre, S. Egan, R. McQueen, D. Cionoiu,
0168.html, September 2008 “Jingle   RTP   Session”,   http://xmpp.org/extensions/xep-
[35] M. Miller, P. Saint-Andre,   “XEP-0079: Advanced Message 0167.html, December 2009
Processing”,   http://xmpp.org/extensions/xep-0079.html, [40] A. Cosaro, L. Querzoni, S. Scipioni, S. Piergiovanni and A.
November 2005 Virgillito,   “Quality   of   Service   in   Publish/Subscribe  
[36] S.  Rhea,  D.  Geels,  T.  Roscoe  and  J.  Kubiatowicz,  “Handling   Middleware”,   Global   Data   Management   ,   IOS   Press,2006,  
churn  in  a  dht”,  ATEC’04:  Proc.  of  the  annual  conference  on   pp.20- 20.
USENIX Annual Technical Conference (Berkeley, CA, [41] T. Guesmi,  R.  Rekik,  S.  Hasnaoui  and  H.  Rezig,  “Design  and  
USA), USENIX Association, 2004, pp. 10–20 Performance of DDS-based Middleware for Real-Time
Control  Systems”,  2007