Establishing a Smart Grid Node Architecture and Demonstrator in an Office
Environment using the SOA Approach
Dagmar Koß, Florian Sellmayr, Steffen Bauereiß, Denis Bytschkow, Pragya Kirti Gupta, Bernhard Schätz
fortiss GmbH, Technical University of Munich
Munich, Germany
{koss,bytschkow,gupta,schaetz}@fortiss.org, {sellmayr,bauerest}@in.tum.de
Abstract—The introduction of low-cost renewable energy
production, e.g., by photovoltaic, has turned classical grid nodes
like homes and offices in prosumers, taking an active role in
smart energy systems by merging home-automation and energy
production functionality. However, to become a self-balancing
element of a stable smart grid, supporting the energy-aware
cooperative production, storage, and consumption, a scalable
software is needed tailored for smart micro grids and their
integration in large-scale systems. In the following, the implementation of a layered SOA-based distributed architecture is
presented, that provides open interfaces simplifying the plugand-play of hardware and software components, allows the runtime adaption of its reactive behavior to incrementally enhance
its intelligence, and uses an interaction paradigm supporting
an open and distributed form of cooperation.
Keywords-Smart Grid, Demonstrator, Smart Energy, Layered Architecture, Office Automation, System Architecture,
SOA, OSGi, ActiveMQ
I. I NTRODUCTION
The increasing integration of renewable energy from private households and companies, which are connected to the
medium and low voltage level, starts to change our energy
system drastically. New challenges in the energy system
include not only the balancing of volatile, largely distributed,
small-volume energy production and consumption, but also
a shift of centralized overall control infrastructure to more
localized and decentralized approaches. This requires new
energy systems, which will enable decisions and the management of available energy production and distribution on
the local level.
This paper focuses on establishing new system architectures and their implementation by providing a realization
in form of a demonstrator for an element in distributed
energy systems, forming an intelligent node in a smart grid
infrastructure environment. Smart grid nodes include energy
consumption, production, buffer capacity, sensors and ICT
components. In order to achieve smart grid requirements like
integration and independence of electrical devices including
plug and play capabilities, scalability, distributable, robustness and self-recovery, the developed smart node architecture is designed maximal flexibility. Besides the control
of heterogeneous devices, the architecture also covers the
integration of sensors, in order to enable control mechanisms
for energy efficiency and the possibility to run a wide variety
of different application scenarios, providing a Living Lab to
evaluate the applicability of the architecture.
Our smart grid node demonstrator provides the needed
infrastructure to integrate several heterogeneous devices in
an office space environment (such as smart meters, home automation units, sensors, solar panels, batteries, air-condition
etc.). The smart node enables metering/monitoring, storing,
processing, and analyzing the status and data of individual
devices, aggregating it into the status of the overall smart
grid node. The demonstrator also includes methods to decide
on and perform actions to achieve a better energy efficiency
(e.g., turning off unused lights). Besides basic energy saving
the Living Lab can be used to demonstrate methods, which
are currently investigated in the smart home research community. This includes optimization and control of appliances
(like dish washer, washing machine, refrigerator, smart home
devices etc.), which can use energy at times when the energy
prices are lower or can be rescheduled to another time to
smooth unexpected energy peaks, as it was shown in [1].
One of the main challenges to establish a demonstrator
that offers lots of interoperability was the integration of different devices. Most of the devices in the Living Lab provide
different interfaces and data structures. For example: The
home automation devices are communicating via EnOcean
[2], messages while the smart meters have either a built-in
web front-end (IPswitch [3]) or communicate via modbus
(PacSentron[4]). Right now, there is not yet a common
interface to access the devices data that can be used to
establish a smart building, without the need for components
that translate between different protocols.
The developed Living Lab enables the collection of real
life data, which is important to find out what kind of data is
needed, how much data is produced by the different devices
and what monitoring frequency is required for the system to
control the different devices. The collected data will help to
get a deeper understanding about the data processes in smart
nodes, which will be needed in the future. Our smart grid
node Living Lab will also provide the possibility to connect
to other smart grid demonstrators.
This paper is structured as follows: the next section will
provide a short overview of the Living Lab demonstrator
environment. Afterwards, the developed smart node architecture is described in section III, while section IV demonstrates
its implementation. The paper continues with experiences in
section V and finishes with a conclusion and an outlook in
Section VI.
II. L IVING L AB
A. Demonstrator Hardware Plattform and Environment
The goal of Living Lab smart grid node is the definition
of a flexible prosumer node architecture, merging energy
management and home automation aspects and facilitating
the integration of different device types, providing an extensive set of data. Furthermore, providing a layered, distributed
architecture, its control functionality can be easily extended.
As a Living Lab, the demonstrator is implemented as part of
the regular office space of fortiss. The general installation
and the existing energy and data flow is shown in figure 1.
As the core elements of the technical platform, four major
categories of devices are installed. The first group of devices
is related to the energy production and storage. A 5 kWh
photovoltaic system is installed on the roof of the building.
In addition to the solar panels, a battery system including
an intelligent charge controller provides sufficient capacity
to supply a set of offices with energy running in island mode
(i.e., decoupled from the metropolitan grid). The data from
the photovoltaic system is gathered by a data logging device
and provided via web interface.
To support usage scenario of a work-place setting, an
office room and a meeting room are part of the Living
Lap. Both rooms are equipped with devices of the second
category: actors and sensors of the EnOcean [2] familiy,
which represents the home automation part of our Living
Lab. EnOcean devices are wireless and powerless home
automation components. The sensors, which are installed
within our office space, are: Temperature sensors (indoor and
outdoor), occupancy sensors, window sensors and lightness
sensors (indoor and outdoor), switches for the blinds and
lights. To control devices like blinds or lights, actors were
installed, which receive the signals either from the switches
itself, or from an EnOcean gateway via Ethernet.
The third category of installed devices are smart meters.
One Siemens PacSentron 4200 [4] smart meter is installed
in the office space and measures both demonstrator rooms.
Another PacSentron is installed in the server room and
measures the consumption of two air conditioner units. For
a fine-grained monitoring of consumption data, three further
PacSentrons are installed to measure all other office rooms,
which are currently not integrated into the demonstrator.
All PacSentrons are connected via Ethernet (ModBus via
Ethernet) to the office LAN and answer to a gateway,
translating the ModBus data from the meters into IEC 61850
[5] conform data.
The category of smart meters also includes an IPswitch
meter [3]. This IPswitch is comprises three electric meters
which measure the energy consumption of high-end computing servers (including a switch and a big data-storage
device) and the interruptible power supply (UPS) backup
system. A three phased meter is connected to one UPS, two
other two phased meters are connected to the servers. The
IPswitch provides an Ethernet interface to the local network
and has a built-in web server, which presents the current
energy consumption on a web page. Additionally, there is
one electric meter from EnOcean. It measures the energy
consumption of the lights in the meeting room.
The fourth category of devices is an air conditioner control
management system for the two air conditioner units in
the server room. The data (like temperature, cooling hours,
status, etc.) of the air conditioner units is distributed over
Ethernet via a web-interface, which allows their monitoring
and control.
All devices of the Living Lab are connected via Ethernet.
This Ethernet serves as communication backbone for the developed architecture, described in Section III. The developed
software, which collects and monitors the data and controls
the devices is discussed in Section IV.
B. Related Work
In the field of smart homes, substantial research including
the implementation of demonstrators has been performed [1]
[6]. It includes integration of intelligent household appliances, solar panels, a combined heat and power plant (CHP)
and an e-car battery into a smart home. The demonstrators
investigates the management of the energy demand in future
smart grid, implementing an observer/controller architecture
to achieve the goal of adaptation and automatic control. The
architecture was chosen from the context of organic computing [7][8], whereas our focus is more based on service
orientation to build up a flexible, distributed platform of
COTS technology for further research activities, facilitating
device integration and system interoperability.
In the home automation domain, a wide variety of smart
devices and corresponding approaches for load-balance &
price-efficient techniques inside a residential building have
been investigated, e.g., [9] [10] [11]. There has been research
going on for automation of smart office buildings [12]
[13]. [14] points to the effort in building energy efficient
office infrastructure based on dynamic pricing and operation
scheduling using predefined policies, implemented by a set
of rules that must hold for the operation of each associated
device. In this paper, we propose policies for the operation
of devices, but do not coupled those policies with the
devices. The rule system component – described in detail
in SectionIV – supports user-defined rules, which can be
changed at run-time.
On the architectural level, there have been attempts to
use SOA for smart homes based on OSGi capability. [15]
proposes a SOA architecture for smart homes based on
OSGi with Mobile-Agent technology. Mobile Agents (MAs)
Figure 1.
The Living Lab Demonstrator including information and energy flow
are the software modules, which support the automatic
interaction between various components of the system. As
pointed out in there, the inability of the MAs to handle
unexpected exceptions makes them less applicable. [16]
propose a similar approach as presented here. That approach
emphasized on using UDDI and SOAP via XML, with the
disadvantage that UDDI has inefficient mechanism to handle
service publishing and discovery. In our proposed architecture, we use OSGi as principle runtime environment and
Apache ActiveMQ for the interaction between the services.
III. A RCHITECTURE
To build up the demonstrator, a layered architecture was
developed, specifically providing functionality for smart grid
nodes. The layered architecture reduces the complexity of
the system, while supporting a large set of heterogenous
devices (with different interfaces installed in different locations). It enables the user to easily integrate new devices
into the system, support the communication, and process
large amounts of data. For the support of decision making
and control of the system, a rule system was integrated.
A. Layered Architecture
A smart grid node architecture needs to combine two
goals. It has to work in a heterogeneous hardware landscape
while providing a generalized interface for usage in higher
level domains such as data-analysis, event-processing and
control applications. To combine these two goals the architecture can be divided into layers. We use three layers: A de-
vice layer, a communication layer, and a processing/control
layer, which is shown in figure 2.
The device layer deals translates the device specific protocols into a device independent internal protocol, using an
event-based communication paradigm. This encapsulation
facilitates the implementation of higher-level functionalityby abstracting all hardware-dependent details (e.g. vendorspecific protocols). Moreover, extending the system to a new
set of devices is supported by developing a wrapper that
implements an interface (see IV-B). By providing such a
wrapper, adding new hardware to the node can be performed
in a plug and play-fashion.
To integrate the heterogeneous components, a service
bus provides the necessary communication layer. It enables components to interact either in a one-to-one or
publish/subscribe manner depending on the use-case: Oneto-one communication enables the interaction with a specific
endpoint (e.g. controlling a specific device), while a publish/subscribe mechanism enables to broadcast events, which
are useful for a set of components (subscribers) within the
system (e.g. sensor-data to be sent to a decision-making as
well as a logging component). This layers also provides the
mechanims to connect the node to other systems including
a billing system or other smart grid elements.
On top of the communication layer, high-level services
provide more complex functionality. It includes a service
for persisting all events in a database for analysis. The
rule system as a more advanced service provides a decision
system for the control of the node using a set of predefined
Figure 2.
Architecture of the fortiss Living Lab demonstrator
strategies (e.g. to turn off certain devices when a smart meter
reports high energy costs).
B. Design Principles
1) Event-driven communication: Sensor hardware provides its information either pull based (e.g. displayed on an
HTML page like IPswitch) or pushed based (e.g. EnOceanGateways which stream EnOcean messages into the system
as they arrive). To provide a consistent and simple interface
for all devices, one of those approaches had to be chosen
for the system.
In a push-based architecture, poll-based devices would
be polled by the wrappers in the device layer and an
event would be generated after each poll or under certain
conditions (i.e. the difference between the current sensor
value and the last was above a certain threshold). In a pullbased architecture the device layer components for pushbased devices would need to cache the most recent events
from all their devices and provide them until being polled.
The push-based (or event-driven) approach has several
advantages for our purpose:
•
•
•
New sensor-data is propagated almost instantaneous
and without the overhead produced by polling
No effort has to be made to cache push-based devices
information for polling
No additional polling logic is required for implementation of higher-level components
One potential drawbacks of such a design is the fact
that the system does not provide an inherent sense of its
current state, requiring higher level components to track
such information. However, the persistency service of the
proposed architecture responsible for storing events proved
to be sufficient for the implemented functionality, including
all kind of user interfaces and other higher-level services as
the rule system described in see IV-D3, which requires a
higher performance that could not be achieved by polling
either.
2) Service Oriented Architecture: The most important
aspect of SOA is the service: A service is typically a
component within the system that provides a clearly defined,
single functionality (such as “long term persistence of sensor
data”) and encapsulates all logic and data necessary for this
task [17].
Such a component must not to be confused with a technical service (e.g. access to a database): A SOA should be
technology-agnostic, leaving technical details to the service
implementation.
To access data or logic represented by a service, the service provides a high-level service contract and an interface
that provides all information, which is necessary to work
with it. This service interface reflects application domain
principles, not technical ones (e.g., “give me the most recent
sensor value for sensor42”, not “execute SELECT . . . ”).
This facilitates to interact with services without knowledge
about their internal structure and to replace a service imple-
mentation without interfering with other components [18]
(4.3.2 and 5.1).
Services can provide basic functionalities (such as exposing a certain piece of hardware via a clearly defined
interface, providing historic sensor data or information about
relationships between devices) or use other services to provide more high level functionalities such as controlling the
node by consuming the services of wrappers and components
providing historic values or information on the relationships
between devices.
Note that the terms of “basic” or “higher level” services do
not necessarily match the architecture layers: For example,
a persistence service is a “basic” service since it does not
consume any other service but is nevertheless situated in the
highest layer since it provides information for processing
functionality.
IV. I MPLEMENTATION
The following section provides an overview of how the
design mentioned before was implemented in the Living Lab
demonstrator. We describe the most important technical infrastructure before providing more detail about the interfaces
that describe sensor data and actor control information. The
last subsection outlines in more detail the components that
provide the abstract services described above.
A. Technical Infrastructure
1) Service-Bus: The current implementation of the communication layer uses Apache ActiveMQ [19] as a servicebus implementing the Java Message Service standard [20]
and utilizing SOAP for message encoding. This makes
all components accessible in a web-service-like manner
and provides one-to-one as well as the publish-subscribe
communication mechanisms as mentioned above.
By using Enterprise Integration frameworks such as
Apache Camel [21] it is also possible to integrate external
components that were not built for a service-bus architecture
(as a proof-of-concept, an off-the-shelf alarming system
developed by an external vendor was integrated using this
technique).
2) Component Platform: While the system is prepared
to run in a highly distributed environment, hosting it on
a single platform makes it much easier to maintain. It
currently runs in an OSGi [22] environment as a component
platform, which enables us to activate, deactivate or deploy
system modules easily, providing a platform on which new
components can be integrated in a plug and play fashion.
While [15] uses an OSGi-based agent-oriented approach for
adding new devices, the Living Lab does not rely on specific
extension of the OSGi platform to keep the design as flexible
and technology independent as possible.
While implementation as a distributed system are not
fully exploited at this point with all hardware and software
components locally integrated, in a more advanced scenario
with a distributed collection of devices or a microgrid of
smart nodes can run their own rule systems.
B. Interfaces
The core services of the Living Lab demonstrator are
the services for processing sensor data and controlling the
actors.
The first service is provided by the communication layer,
which allows the wrappers in the device layer to trigger
events, i.e., messages indicating updated sensor values. The
wrappers in the device layer provide a service for processing
commands, i.e. processing messages to control a certain device. Interfaces to both services are designed symmetrically.
At the moment, established interface standards exist only
for a subset of the functionality, which is required for a
smart grid node. E.g., the IEC 61850 [5] based interface
describes aspects of power consumption very well, but is
much less suitable for other sensor families, such as temperature sensors, and does not address controlling devices at
all. Thus, an interface specification had to be defined to suit
all these requirements. In principle, the definition of such
an interface can follow two design paradigms: Generalized,
with a very basic and simple interface, or specialized, with
a lot of domain-knowledge modeled into the interface.
A specialized approach has the advantage of a more
expressive semantics, that can be used to clearly classify
an event (e.g. “light-switch 3 changed to state down”).
However, such an interface definition requires a mature domain model. Since domain engineering was not the primary
objective of this research, a generic approach was chosen.
Sensor data is described as a simple event, which is based
on primitive data types:
• A double-event for measurements including a unit and a
value for precision of information such as temperature,
position of blinds, energy consumption, lightness. . .
• A boolean-event for on/off type events such as state
of a button, or true/false events such as window
closed/opened, room occupancy true/false. . .
• A toggle-event for events without any semantics, e.g.
pushing a stateless button
Such an interface definition covers all essential event classes
needed in a smart grid node setting, and can be easily
extended by adding a more domain-specific model along
the lines of IEC 61850 on top of it.
Events corresponding to commands to devices are defined
in a similar way. They also include additional attributes to
delay or group events. E.g., a boolean command to a light
would switch a light on or off, while a double command to
the blinds could trigger the actor to move the blinds to 25%.
Finally, state change events are provided to describe
changes in the system. They can, e.g., used to describe
‘virtual commands’ to keep track of actors that are triggered
outside of system control. For example, in case a light
switch is directly coupled to light-actor, the actor is triggered
directly by the switch without rule system involvement.
Thus, the system can record the switch-event as well as the
triggered action with its boolean-event, bringing the system
state back in sync with the real world. This mechanism with
controlled and observed actions and state changes can be
used to make sure basic functions can still be controlled
manually in case of a system malfunction or maintenance.
To announce the existence of new devices, the interface
also defines a newDevice event. Thus, new wrappers only
need to be configured to know the systems service-bus and
send such an event to be incorporated into the system.
Adding a discovery mechanism (which is currently not
implemented but possible with the underlying service bus
implementation), prepares the system for complete plug and
play (always assuming the device does speak the described
protocols or a wrapper was created for it).
C. Device Addressing
In a pure service-oriented approach, every single device
(every light, button, air conditioner,. . . ) would expose and
consume services and thus be addressed individually on the
service-bus. This approach was found to be highly inefficient
in early prototype benchmarks since current frameworks
were not designed for such a large number of endpoints.
Thus, devices in the system are addressed with a combination of their wrappers endpoint-address (e.g. EnOcean1)
and a device-ID that uniquely identifies the device within
the wrapper. Such a device-ID could either be the devices
real ID as defined by the vendor (e.g. 010088C8) or the
ID is defined by the user when configuring the device
(e.g. officelight152 1030). Note that IDs are primarily of
technical nature. More human readable names can be defined
in a meta-data storing component (see section IV-D).
D. Components
1) Wrappers: In the lowest layer, the wrappers act as
a source of information for the system. The amount of
information (data points) pushed to the system as events
depends on the device capabilities and the implementation
of the wrapper. Some devices periodically push their data to
connected listeners, whereas others send data upon changes
only. The wrapper can listen for any data and forward
this information as events. If necessary periodically pushed
information can be held back by the wrapper and forwarded
upon changes only. Another device type has to be polled
by the wrapper. When designing the wrapper a pollingrate suitable for the type of the device should be chosen.
In the Living Lab wrappers for EnOcean, IPswitch, air
conditioner control and PacSentron are collecting data from
the connected devices. EnOcean follows the push approach,
while the other three wrappers are polling their devices.
2) LocationManager: To be able to control the smart grid
node effectively, additional metadata about all devices, their
relationships and their environment is necessary for easier
configuration and maintenance of the system (also in regard
of the rulesystem see section IV-D3). Such metadata includes
a unique device name, device type and physical location.
Relationships between devices are associations influencing
for the system behavior (e.g. “EnOcean1?010088C8 must
switch toshibaAC?srv1” or “toshibaAC?srv1 is in datacenter”) or model connections in the physical world the system
must be aware of (e.g. “EnOcean1?01003F84 directly wired
to EnOcean?officelight225 1030”). Basically, part of the
information could be hard-wired via the individual wrappers
on the device layer. However, the set of metadata required
also contains information, for which the wrapper is not
responsible for, such as human-readable names and relationships between devices of different classes and vendors (e.g.
EnOcean sensor triggers air conditioner).
To avoid dispersion of information over several components and to support a more structured represenation of
information (e.g., grouping of devices to rooms, floors,
etc.), the responsibility for such metadata was delegated
to a separate component, the LocationManager. It uses the
graph database neo4j [23] to model all associations between
devices, rooms and possibly different buildings in a graph.
Additionally neo4j offers a key-value store for every node,
used for storing the device-specific information. Figure 3
shows how the devices described above can be modeled in
the LocationManager.
3) Rulesystem: To control the smart grid node, in the
approach presented here, a set of rules (i.e., a set of actions
executed upon the satisfaction of their triggering conditions).
In the current implementation, the Rulesystem component
registers with the service-bus to receive all events issued in
the system. Upon receiving one of the events the component
uses the JBoss Drools rule engine [24] to process the
event and act accordingly. A simple rule for turning on
the air conditioner in case the temperature rises above 25
degrees Celsius is given in Figure 4. This rule controls
every air condition system that has been connected to a
certain temperature sensor, ensuring that air condition is
turned on as soon as a sensor sends a temperature event
with a value above the defined threshold. It relies on the
LocationManager component to identify which air condition
unit will be activated, using the information about the
devices and their relationships. This enables the user to
write rules in a generalized fashion, avoiding to duplicate
similar device-specific rules for each applicable combination
of sensors and actors. This reduces the complexity of the rule
system, which would result in an bloated rule base hard
to maintain, slowing down the system, and increasing the
probability of contradictory rules.
4) Persistence: The Persistency component registers with
the service-bus as an event handler. All information from
received events is written to a relational database and can
be queried using the services offered by the persistency component. The component represents the central data collection
id: toshibaAC?srv1
id: EnOcean1?officelight225 1030
devType: AC
devType: light
hrName: main AC in Server room
hrName: light at windowside
CONTAINS
ASSOC
id: datacenter
CONTAINS
CONTAINS
id: room225
EXTERNAL
CONTAINS
id: EnOcean1?010088C8
id: EnOcean1?01003F84
devType: tempSensor
devType: lightswitch
hrName: Temp. Sensor behind Server 3
hrName: upper Lightswitch
Figure 3.
Schematic example for a graph stored in the LocationManager
vendors do not provide any defined API, making it necessary to implement fragile web-scraping solutions to get
the necessary data. Other vendors appear to provide such
interfaces but do not test or define them very well: We had
to deal with firmware that was unsuitable for some common
use-cases, software that became unstable when running over
longer periods of time and gaps, errors or inconsistencies in
protocol or interface-specifications.
Clearly defined standards would certainly help to make
building automation devices more interoperable.
B. Amount of Gathered Data
Figure 4. Example of a rule, turning on the air-conditioning when the
temperature raises above a certain level.
and accumulation. The collected data features an average of
14.000 data points collected during a single day in our Living
Lab. This large amount of data is due to a detailed generation
of events in the current setup. All events from push-based
devices are passed on as events, while wrappers that require
polling are typically generating a full set of events when
being polled (e.g. every 10 seconds). The amount of data can
be reduced significantly by filtering duplicate events within a
certain time frame or reducing the overall polling frequency.
V. E XPERIENCES
A. Hardware Pitfalls
When implementing the wrappers for the device layer
we repeatedly experienced that some hardware is not yet
prepared to be integrated into a heterogeneous system or
even integrated with other software at all: Some hardware
As mentioned in section IV-D4, the system gathers several
millions of data points in a few weeks. While this is not
an issue in terms of storage, impacts on query-performance
can already be experienced on the demonstrator. Here, more
efficient ways to aggregate and persist the data need to
be added. To that end the necessary degree of detail of
the sampled data has to be investigated, needed for the
application scenarios. Here, strategies with different time
windows with different levels of details for different sets of
data including corresponding aggregation techniques must
be provided.
C. Efficiency of Communication Protocols
We chose SOAP as a communication protocol primarily
for its flexibility and ease of use when developing additions
to the system independent of the technical details. However,
SOAP is by far inferior to other message encoding methods
in terms of efficiency due to the costs of XML marshaling
and remarshaling [25].
At this point, such costs are not yet a problem for the
basic system-functions, such as gathering sensor data or
control, but they are already visible to the user in the form
of a sluggish response, e.g. when metadata for a number of
devices has to be pulled from the LocationManager via the
Service Bus.
Thus, it should be investigated whether the high flexibility, which SOAP provides, is really necessary and can be
justified for all requirements.
D. Basic Data-Type Interface
The lack of a domain-specific data model providing a
more specific semantic interpretation of events (see section
IV-B) did not pose a problem concerning the incremental
extension of the node architecture. Different extensions were
implemented on top of the existing architecture by different
user groups with only minimal training efforts.
Our experience shows that within the context of a prosumer node the need for additional semantic information
about data (e.g. “the event came from a light switch”)
typically correlates with the need for additional metadata
about the device itself (e.g. a location or a connection to
other devices, “which devices are connected to the light
switch”), which in turn is provided by the Location Manager component described in Section IV-D. This component
proved sufficient in our setting to provide the necessary
semantic meaning for basic data-type events (such as the
type of device an event originated from). However, for the
overall grid architecture, a more elaborate data model is
likely to be necessary.
VI. C ONCLUSIONS / O UTLOOK
This paper introduces an architecture for smart grid nodes
using a layered, service-oriented approach. The implementation in form of a Living Lab demonstrator has sown the
suitable of three distinct layers: (i) a device layer, which
includes all devices with their corresponding wrappers, (ii)
a communication layer, which enables the communication
over an enterprise bus, and (iii) a processing and control
layer, which includes event handlers, a database, and a
connection to all higher layer services. The architecture was
implemented in a real life office environment to demonstrate
the effective handling of the system. The architecture proved
sufficiently flexible, e.g., to efficiently integrate new devices
by the use of wrappers, which abstract the device specific
elements. Plug and Play capability was achieved by integrating wrappers into an OSGi environment and providing an
open communication backbone with clear interfaces for services. All control and processing components are developed
device-independent and can reuse services from existing
components. For the definition of the control functionality,
a rule-based system allowing modifications at run-time is
provided.
The Living Lab with is flexible architecture provides a
suitable framework for further investigation of smart grid capabilities, addressing different uses cases. The combination
of production units together with storage capacity is used to
demonstrate self-balancing of the power within the smart
node, increasing the usage of own energy resources and
reducing disturbances of the external grid. The inclusion of
additional elements, like electric vehicles, will be addressed
in an extension of the demonstrator. External data (e.g.
price signals or weather forecasts) will also be integrated
to optimize aspects like costs or reliability. User-interfaces
for different devices like smart phones, tablet PCs or web
front-ends are currently implemented to provide a suggestion
mechanism to inform the user about the possibilities how
energy can be saved. To ensure the reliability of the system
– specifically when extending the rule system with more
rules to provide better energy efficiency – a rule-checking
mechanism is implemented to avoid the creation of unsound
rule combinations. Furthermore, security concerns have to
be improved as currently security was not the scope of the
demonstrator. The architecture will be expanded to support
security aspects as well, providing suitable roles and rights
and access control mechanisms.
Finally, to better evaluate the suitability the architecture
concerning its embedding in grid of prosumer nodes, future
work will also focus on connecting the demonstrator with
other demonstrators in Europe, as well as connecting the
Living Lab to smart-grid simulation frameworks.
ACKNOWLEDGEMENT
The authors would like to thank the EIT ICT Labs for the
support to build up the demonstrator.
R EFERENCES
[1] B. Becker, F. Allerding, U. Reiner, M. Kahl, U. Richter,
D. Pathmaperuma, H. Schmeck, and T. Leibfried, “Decentralized energy-management to control smart-home architectures,” in Architecture of Computing Systems - ARCS 2010,
ser. Lecture Notes in Computer Science, C. Mller-Schloer,
W. Karl, and S. Yehia, Eds. Springer Berlin / Heidelberg,
2010, vol. 5974, pp. 150–161.
[2] EnOcean. (2012) EnOcean homepage. [Online]. Available:
http://www.enocean-alliance.org/
[3] SMS-Guard. (2012) IPswitch-SG Anleitung. [Online].
Available:
http://www.sms-guard.org/downloads/
IPswitch-SG-Anleitung.pdf
[4] Siemens. (2012) SENTRON power monitoring device
SENTRON PAC4200 - system manual. [Online].
Available:
https://www.swe.siemens.com/portugal/web
nwa/pt/PortalInternet/QuemSomos/negocios/Industry/BT/
LowVoltage/Documents/Sentron20PAC4200 brochura EN.
pdf
[5] IEC. (2012, February) IEC 61850-SER ed1.0 Communication networks and systems in substations. [Online]. Available: http://webstore.iec.ch/Webstore/webstore.
nsf/Artnum PK/33549
[6] R. Ulrich, K. Mattias, T. Leibfried, A. Florian, and S. Hartmut, “Meregiomobil-labor - entwicklungsumgebung fr zuknftige smart-homes.” in VDE Kongress 2010 - E-Mobility,
2010, p. N/A.
[7] F. Allerding and H. Schmeck, “Organic smart home:
architecture for energy management in intelligent buildings,”
in Proceedings of the 2011 workshop on Organic computing,
ser. OC ’11. New York, NY, USA: ACM, 2011, pp. 67–
76. [Online]. Available: http://doi.acm.org/10.1145/1998642.
1998654
[20] “JSR-000914 Java Message Service Specification Final Release 1.1,” http://download.oracle.com/otndocs/jcp/
7195-jms-1.1-fr-spec-oth-JSpec/, 04 202.
[8] K. Bao, F. Allerding, and H. Schmeck, “User behavior
prediction for energy management in smart homes,” in Fuzzy
Systems and Knowledge Discovery (FSKD), 2011 Eighth
International Conference on, vol. 2, july 2011, pp. 1335 –
1339.
[22] R. S. Hall, K. Pauls, S. McCulloch, and D. Savage, OSGi in
Action : Creating Modular Applications in Java. Manning,
2011.
[9] C.-S. Choi, J. Han, W.-K. Park, Y.-K. Jeong, and I.-W. Lee,
“Proactive energy management system architecture interworking with smart grid,” in Consumer Electronics (ISCE), 2011
IEEE 15th International Symposium on, june 2011, pp. 621
–624.
[10] G. Giaconia, G. Fiscelli, F. Bue, A. Di Stefano, D. La Cascia,
and R. Miceli, “Integration of distributed on site control
actions via combined photovoltaic and solar panels system,”
in Clean Electrical Power, 2009 International Conference on,
june 2009, pp. 171 –177.
[11] K. Kok, S. Karnouskos, J. Ringelstein, A. Dimeas, A. Weidlich, C. Warmer, S. Drenkard, N. Hatziargyriou, and V. Lioliou, “Field-testing smart houses for a smart grid,” in 21st
International Conference and Exhibition on Electricity Distribution (CIRED 2011), Frankfurt, Germany, 6-9 June 2011.
[12] J. Ma, S. Qin, B. Li, and T. Salsbury, “Economic model
predictive control for building energy systems,” in Innovative
Smart Grid Technologies (ISGT), 2011 IEEE PES, jan. 2011,
pp. 1 –6.
[13] H. Vogt and H. Weiss, “A client architecture for marketbased grid integration of smart environments.” in PerCom
Workshops’10, 2010, pp. 642–647.
[14] I. Georgievski, V. Degeler, G. A. Pagani, T. A. Nguyen,
A. Lazovik, and M. Aiello, “Optimizing offices for the smart
grid,” Distributed Systems Group, Institute for Mathematics
and Computer Science, University of Groningen, Tech. Rep.,
November 2011.
[15] C.-L. Wu, C.-F. Liao, and L.-C. Fu, “Service-oriented smarthome architecture based on osgi and mobile-agent technology,” Systems, Man, and Cybernetics, Part C: Applications
and Reviews, IEEE Transactions on, vol. 37, no. 2, pp. 193
–205, march 2007.
[16] C. Liu, T. Reynolds, and H. Bao, “Research on SOA-based integrated strategy to enable the smart grid,” in Cyber-Enabled
Distributed Computing and Knowledge Discovery (CyberC),
2010 International Conference on, oct. 2010, pp. 506 –509.
[17] T. Erl, SOA Design Patterns, 1st ed.
NJ, USA: Prentice Hall PTR, 2009.
Upper Saddle River,
[18] D. S. Dirk Krafzig, Karl Banke, Enterprise SOA: ServiceOriented Architecture Best Practices. Prentice Hall PTR,
2004.
[19] Apache. (2012) Apache ActiveMQ homepage. [Online].
Available: http://activemq.apache.org/
[21] Apache. (2012) Apache Camel
Available: http://camel.apache.org/
homepage.
[Online].
[23] neo4j. (2012) neo4j homepage. [Online]. Available: http:
//neo4j.org/
[24] JBoss. (2012) JBoss Drools Homepage. [Online]. Available:
http://www.jboss.org/drools
[25] D. Davis and M. P. Parashar, “Latency performance of soap
implementations,” in Proceedings of the 2nd IEEE/ACM
International Symposium on Cluster Computing and the
Grid, ser. CCGRID ’02. Washington, DC, USA: IEEE
Computer Society, 2002, pp. 407–. [Online]. Available:
http://dl.acm.org/citation.cfm?id=872748.873215