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