Integrating Sensor Networks for Energy Monitoring with Service-Oriented Architectures

More accurate predictions of energy consumption are a strong motivator for utility providers to deploy a smart grid infrastructure. However, measurements which only reflect the consumption of a household lose the details associated with the behaviour of individual devices. Finding a flexible and efficient way to process these readings is essential. Using standard application techniques to integrate device-oriented sensor networks and data-oriented applications is a serious challenge due to the architectural gap between the different approaches. Additionally, this device-level information should be shared with the end-users in a trusted manner to increase their energy awareness. We propose a novel platform for the smart grid which enables the seamless integration of sensor networks with a service-oriented architecture approach. The platform hides the device-specific details from the applications and transforms data into a device-independent format. Specifically, we present an in-depth description of the architecture of our platform and a full implementation and evaluation of it in a live residential energy management deployment.


Introduction
Accurate prediction of electricity consumption is a major challenge for utility providers.Even a small increase in accuracy can lead to significant improvements in regulating supply and therefore costs for the utility provider [1].The switch to using smart metering infrastructure has allowed the utility provider to get frequent (typically around every 15 minutes) updates as to the power consumption perhousehold.However, this information only reflects the consumption of the household in total, not the individual devices (e.g., DVD player, TV, fridge, washing machine, etc.).Since each device has a different usage pattern, it is important for accurate predictions to take into account the specific characteristics of each device.
The convergence of consumer electronics and information technology together with the developments in communication systems gave rise to a new range of services, for example, building automation, smart metering, health, fine-grained demand-side management, safety and security, and so forth.In accordance with current best practices in software engineering, a service-oriented architecture (SOA) approach is often used to provide the infrastructure for such interoperating services or applications.SOA is useful as it creates a set of independent, loosely coupled services which communicate with each other through a set of well-defined interfaces.One of the key challenges with developing applications and services that interface to sensor networks is the architectural gap between device-oriented sensor networks and data-oriented applications.For example, the addressable component of a typical sensor network such as ZigBee or Z-Wave is the network interface address of the sensor whereas an application may provide electricity consumption information to an end-user.Therefore, there is a significant difference between the granularity of data produced by the sensors and the data which a SOA system can typically process.
In order to make per-device measurements available to both the utility provider and the end-user for both energy prediction and energy awareness purposes in a trusted way, we present a platform for the smart grid based on a SOA approach which allows the integration of sensors measuring the energy consumption of individual devices.The platform is capable of both supporting the usage of per-device sensors International Journal of Distributed Sensor Networks and also hosting multiple applications which manipulate and visualize the per-device sensor data for the end-users.
In order to bridge such an architectural gap, existing SOA systems typically integrate heterogeneous services by using an Enterprise Service Bus (ESB) [2] in order to create a set of loosely coupled services.However, the protocol-or technology-specific parts of the ESB (also known as binding components) export data-oriented service interfaces rather than device-oriented interfaces.Thus, the challenge remains of how to integrate device-oriented sensor networks into a data-or service-oriented architecture.
The main contributions of this paper are twofold: (1) the design and implementation of a novel platform for the smart grid which enables the integration of perdevice sensor measurements with a SOA approach (Sections 3 and 4); (2) an evaluation of our platform, used as a smart energy monitoring system, in a number of real-world deployments and a selected set of experimental results (Section 5).
In addition, we also present a discussion of the relevant related work in Section 6 and a summary of our insights in Section 7.

PeerEnergyCloud Architecture
Sensor networks have successfully been deployed for various and different use cases.These include controlling and monitoring industrial plants, supervising weather stations, and military purposes.However, with declining hardware costs, sensor networks also find their way into private homes.
Corresponding research projects focus on monitoring those homes concerning energy consumption as well as security and safety reasons [3].Furthermore, actuators allow for home automation based on measured sensor values or user input.
One such project is PeerEnergyCloud (PEC) [4], which specifically focuses on the energy domain.The importance of sensor networks for PEC lies in the detailed logging of energy consumption on a per-device level (e.g., refrigerator, television, and washing machine).Analyses of logged values furthermore provide the opportunity to predict future consumption values and hence an in-depth planning of energy production on the utility provider's side.
The architectural framework of PEC including the key components is shown in Figure 1.
In the architecture drawing, all components except the private home installations are located in the Cloud.Cloud computing allows for the abstraction from real IT infrastructures and hence supports elastic scalability for the handling of big data.That is, computing power and storage may be easily increased or decreased depending on the current sensor data load.This is an important feature since for the described use case the load varies, for example, depending on the time of day.Algorithmic frameworks such as MapReduce support elasticity and scalability when deployed in the Cloud.
Concerning PEC, algorithms specifically attract notice when it comes to predicting energy consumption which will be performed by the energy trading agents.
An important component of the architecture is the Backend which represents the point of contact between the private home installations and the different parts of the PEC architecture.
The private home installation is displayed on the lower left.It consists of a Home Gateway which represents the coordinator between the network and sensors/actuators.All sensors and actuators are connected to the Home Gateway and regularly provide it with measured values.Deployed sensor types include so-called smart plugs for the energy measurement, temperature sensors, light intensity sensors, air pressure sensors.These data will be pushed to the different parts of the PEC architecture through the Backend.
With regard to the user's privacy settings, the Backend pushes selected sensor data to the trusted smart grid datastore (TSGD), registered valued-added services, and its energy trading agent.The TSGD is responsible for managing data from all connected smart homes and provides access to this data for valued-added services which the user has registered to.
Value-added services may include energy analysis tools, home security management, and intelligent automation applications.
Energy trading agents use the detailed consumption data in order to predict future energy requirements and to place contracts for energy purchase through the marketplace.Such a system allows for explicit energy management and the easy integration of customer-owned energy generators, such as solar panels or wind engines.
Figure 1 provides an outlook for the overall system complexity.It also shows the importance of a reliable sensor network with detailed measurements.
With the overall picture in mind, the following sections will describe the Smart Home Subsystem which includes the Sensor Network, the Home Gateway, and the Backend.

Smart Home Subsystem Design
The overall Smart Home Subsystem architecture is depicted in Figure 2, whereas Figure 1 provides the deployment view of the end-to-end PEC architecture where the software components that comprise the Backend system have been deployed using Cloud technologies.Figure 2 shows the component view of the introduced platform in terms of the functional components of the system and their interconnections.
The architecture comprises a set of sensors/actuators (e.g., smart plugs), one or more Gateways, a Backend, a Frontend, and one or more client applications.All the parts of the architecture are independent from each other; in this way it is possible to modify/update each of them without the need of updating or rebuilding the whole architecture.
Users can benefit from such an architecture due to the fact that it allows a simple connection of new devices (enabling in this way the possibility to increase the number and the variety of connected devices), and developers can exploit the ease of implementing new applications thanks to the abstraction provided, without worrying about the hardwarespecific details of the devices.
In the following, we describe in detail the components of the architecture.

Sensors and Actuators.
In general, the network connecting sensors/actuators can be realized by using wireline or wireless technology.Wireline communications have the advantage of using the existing wiring infrastructure and can have higher data rate as compared to wireless technologies, but some technologies, such as Power Line Communications [5], are exposed to varying channels conditions which depend on the number and type of appliances connected to the power line.Other wireline technologies, such as KNX, require dedicated infrastructure to be installed.
One of the main advantages in using wireless sensors and actuators is that there are less restrictions regarding where the sensors have to be installed.This is a real benefit in deployment scenarios in hazardous or irregular environments.However, the lack of cabling introduces some challenges related to the energy consumption of the wireless nodes.

Gateway.
The Gateway provides an interface between the sensor network and the rest of the system.This means not only bridging the gap between the likely short-range network used by the sensors, but also the device-specific details present in the Gateway and the higher-level, device-agnostic middleware in the Backend.
The Gateway for this solution provides an abstraction layer which removes the device-specific details of the sensors and offers the gathered data in a standardized, deviceindependent way.The Gateway also handles the management of the devices which are attached to it, for example, managing the registration of new devices, security provisioning, and fault detection.The Gateway's functionality should be extensible during the deployment lifetime of the Gateway and the gathered data should also be stored in a cache on the Gateway for optimization purposes.
The Gateway design is split into three main components (see Figure 2).

Core Bundles.
The core bundles perform the majority of tasks carried out by the Gateway.The set of Core Bundles comprises the following components.
(i) The Device List which should handle joins and leaves of the devices to and from the sensor network so that the registration and subsequent deregistration of devices can be pushed to the Backend.(ii) Sensor Data and Descriptions: the attached sensors need to be described in a device-independent way so that the Backend can manipulate the data and descriptions without need of having explicit knowledge of the underlying implementation details of the various sensors.(iii) Cache Manager: to guard against failures of network connectivity, the Gateway needs to cache sensor data temporarily until connectivity has been restored.The data needs to be kept in a cache for a predetermined amount of time before being removed.should have a number of device-specific protocol adaptors so that a number of different devices using different networking technologies can be attached to the Gateway in a modular fashion.Each protocol adaptor should completely encapsulate the device-specific details of the sensor, leaving the rest of the Gateway to operate in a generic way as possible.
The protocol adaptor will handle the actual interface to the sensor network in order to receive data and all associated additional device-specific functionalities such as sending commands to the sensors for both actuation (where available) and management purposes.

Platform Services.
Platform Services are generic housekeeping services to manage the Gateway as a service platform.In order for the Gateway to be upgraded during its deployment lifecycle, it must be implemented in a modular way.These modules must be "hot pluggable, " meaning that they can be dynamically upgraded without having to stop the running system.In order to achieve that, a set of Platform Services must be present providing an appropriate system and service platform which enables such hot plugging of software components.

Backend.
The Backend hosts both data processing and data management functionalities (see Figure 2).Complying strictly to the idea of loosely coupled systems, the Backend has been designed based on an ESB architecture.That is, various service-oriented components communicate through the ESB to exchange data without relying on objects of other components.The Backend is designed to work with sensor data in a generic, high-level fashion.
Depending on the accessing components, the Backend is typically subject to two different information processing flows.
The first information processing flow is initiated by the Gateway whenever a new sensor reading comes in through the Backends Data Push Interface.This reading is then pushed on the ESB and consumed by the Sensor Data Parser.The parser transforms the data into a valid format and pushes it back to the bus.Finally, the Persistence Connector accesses the sensor data and persists it in the corresponding table of the Sensor Data Repository.
In addition to the persistence connector, a Complex Event Processing (CEP) engine receives the incoming sensor data [6].The CEP engine allows to run continuous queries on the incoming data, like filtering, aggregation, or pattern matching.Outputs of the CEP engine are filtered or aggregated sensor data as well as higher level events that are derived from a set of multiple sensors values.
The aggregated sensor data and the events produced by the CEP are again pushed on the bus.From there, they can be forwarded to the applications using the Data Push Interface.
The second information processing flow is initiated by the Frontend through the Aggregate Sensing/Actuation Interface.This interface allows the applications to access aggregated sensor data as well as events that have been produced by the CEP.Moreover, it allows the applications to access the Gateway forwarding the requests from the Backend to the Gateway using the ESB.This enables the applications to actuate and configuring devices as well as administrate the Gateway itself.Thereby, the Aggregate Sensing/Actuation Interface enriches the transmitted data with data already stored in the Backend repository.If, for example, a list of all devices connected to a Gateway is requested, the interface adds metadata about the sensors taken from the repository (e.g., the units that the sensors measure in).In addition, the interface also provides basic functions to administrate the CEP.
Another feature that can be activated using the Aggregate Sensing/Actuation Interface is the Replay Control service, which can be used for analyzing stored data and testing features.It is activated when an application sends a specific replay command (including a timestamp and a time duration) through the interface.The interface then pushes this command to the ESB in order to activate the Replay Control.Once this happen, the Replay Control service accesses the database through the Persistence Connector and requests all the data stored after the specified timestamp and before the end of the time duration.The Replay Control then produces sensor data messages from these stored data and sends the messages in the same interval they have been received.Moreover, it uses the same format and access mechanism requested by the Data Push Interface.Only the timestamps are updated to the current values; this means that all of the other services cannot distinguish the replayed data from the real current sensor data.Thereby, every action that usually would be executed, including persisting the data, is executed as well.

Frontend and Client Applications.
The generic access of sensor data through the Backends Aggregate Sensing/Actu-ation Interface allows the development of arbitrary Frontend applications.
In the case of residential energy management, examples of applications include monitoring energy consumption (how much energy is currently consumed by the devices?), analyzing energy usage history (which is the most expensive device?), recording temperature fluctuation (is the heater working well?), and switching devices on and off (comfort).

Smart Home Subsystem Implementation
4.1.Sensors and Actuators.In our implementation, we use ZigBee devices [7].ZigBee is a low-power wireless mesh network standard based on IEEE 802.15.4 standard for wireless personal area networks, and it is commonly used in building automation deployments.Compared to other competing technologies, such as X10 and KNX, which typically use dedicated wiring for communication, ZigBee has the advantage of being wireless.Additionally, unlike Z-Wave or EnOcean, it is an open standard and offers a high level of configurability that is critical for a research project.Finally, it provides comprehensive security features compared to competing technologies [8].
In particular, in our deployments we have used XBee devices, working in the 2.4 GHz ISM band [9], in a mesh topology with the Personal Area Network (PAN) coordinator located in the Gateway.

Gateway.
In order to meet the requirements described in the previous section and satisfy the modularity and extensibility needs, we chose to build the Gateway using the OSGi service framework [10].OSGi provides a platform where Java modules (called bundles in OSGi) can be dynamically installed, stopped, started, updated, and uninstalled.By offering a service-oriented architecture, bundles can register themselves as services, discover existing services, and bind to listening services.These factors together mean that the functionality of the Gateway can be modified during its deployment life-cycle, thereby meeting our requirements.
We created the following services in Java on top of OSGi.
The XBee protocol driver implements the XBee specific driver and performs the following functions: (i) device discovery: it discovers XBee devices in the network; (ii) data handling: data is received from the attached devices, and the payload is parsed and sent to the Cache Manager and also to the Data Push Interface so that the data can be forwarded to the Backend for further processing; (iii) actuation: if an application wishes to switch a device on or off, then the XBee protocol driver creates the appropriate message to be sent to the device so that it can be activated or deactivated.
The Sensor Data and Descriptions are a set of high-level descriptions of the sensors themselves and the data they collect.The sensor descriptions are used by the Gateway to keep track of which sensors are attached to the Gateway at any particular time as we typically have sensors of multiple types in a deployment.The sensor data descriptions are used to convert the data sent by the sensors into a format which can be used by the Backend and thereby the rest of the system.
When a message arrives from a sensor, it is processed by the Gateway and the relevant data is extracted.A single sensor device can send messages with different types of data as it may have multiple sensors onboard (e.g., temperature, light, humidity, etc.), so the Gateway needs to be aware of the different types of data that can be expected from the sensors.Box 1 shows an example of the unformatted sensor data as it arrives from the sensor at the Gateway.The Gateway parses this data and creates an internal representation of this data using the sensor data itself, information from the packet header, and the time and date when the packet has been received.
This internal representation is then converted into a JSON stanza which is then sent to the Backend for processing.An example of the JSON stanza is shown in Box 2.
The Cache Manager interacts with a local database (e.g., PostgreSQL) to temporarily store the gathered sensor data.The database is also accessible via the Sensing/Actuation Interface so that the applications can access the cache if necessary.
The Representational State Transfer (REST) Interface is the implementation of the interfaces used by the Gateway to interact with the Backend.It provides the following features: getting the latest data from the database for a specific device, turning the relay of a device on or off (actuation capabilities), and sending gathered data from a sensor to the Backend.
The REST Interface is implemented using the JAX-RS framework [11] and formats the payload of the REST calls in a JavaScript Object Notation (JSON) format [12].

Backend.
In order to implement the service-oriented architecture as shown in the previous section, we implemented the Data Processing Tier of the Backend using ServiceMix 4.4.2[13].This allows reliable messaging using Apache ActiveMQ, routing using Apache Camel, and the relatively simple creation of complex RESTful interfaces using Apache CXF and JAX-RS.Thereby, the ActiveMQ allows the fast transportation of messages using the Java Messaging Service (JMS) which enables the communication using several protocols such as Stomp or OpenWire.
On top of that, ActiveMQ supports a wide number of language clients besides Java, for example, Ajax, C#, PHP, and Ruby.Thanks to it, applications can easily be integrated into the system.
The integration framework Apache Camel then allows the definition of routing and rules on top of the messaging.Therefore, several domain-specific languages, for example, Spring, Fluent API, or Scala DSL, can be used.As Apache Camel uses URIs, it can work directly with messaging models as HTTP, JMS, and ActiveMQ.
The Sensor Data Repository has been realized using a PostgreSQL 9.1 database [14].It has been integrated into Ser-viceMix using the EclipseLink 2.3.2 implementation of the Java Persistence API.As a low-memory alternative, we also implemented a Sensor Data Repository using PostgreSQL and JDBC.The chosen data exchange format is again the JSON due to its lightweight data exchange format which requires less resources when compared to certain XML formats.
CEP is implemented based on the open-source solution ESPER [15].This engine provides high throughput and supports an expressive declarative language for complex event queries.The engine is wrapped as a service and receives all incoming sensor data from the bus in a push-based manner.Incoming sensor data are encoded in JSON format.The wrapper maps the data to an internal Plain Old Java Object (POJO) representation of raw events, and a sensor stream is created for each sensor type.CEP queries can be defined over these streams or any combination of them via the ESPER query language.Query results are continuously pushed to listeners, which transform the results into a JSON representation and push them to the bus.Thereby, filtered sensor data and derived high level events are made available in the Frontend.

Frontend and Applications.
To enable interaction with the overall system through a variety of end devices from smart phones to desktop PCs, we have decided to use a web application server to implement the Frontend.
The Frontend provides an interface which client applications can use to access the sensor data of the system in a user-friendly way.In particular, we used the Apache [13] HTTP Server for the server-side, and we have implemented sample Web applications on the client-side using a dedicated JavaScript framework which supports touch devices.

Smart Home Subsystem Evaluation
5.1.Deployment Description.In order to evaluate the platform, we have developed an energy usage management application based on our architecture and tested it in a field trial.Using this application, one can identify large consumers and unnecessary energy consumption in order to reduce overall electricity consumption.It also provides an interface for remote monitoring and control of the appliances.We tested this application in a field trial where the sensors were deployed in a private household.In order to collect energy consumption values and control the appliances, we used smart plugs with metering and actuating capabilities.All the smart plugs were connected to the Gateway using ZigBee, establishing a mesh topology network, and the smart plugs reported current consumption data to the Gateway every 2 seconds.Their distance to the Gateway was ranging from less than one meter (line-of-sight connection) to around ten meters, in which case radio signal was propagating through two inner walls and one inner floor of the house.Good radio propagation conditions resulted in a long-term stable operation of the sensor network, in our experience.
All the measurements related to the energy consumption were sent to the Backend which was hosted in a Cloud environment built with virtual machines in a remote data center.In addition, we implemented a web-based Frontend that provides the user with statistics over the collected sensor data.Examples of charts reported are shown in Figures 3  and 4. Specifically, Figure 3 shows the average consumption during days of a week at the trial household over a four-week period, and Figure 4 drills down into the devices'-specific consumption for a more detailed analysis.
Figure 3 reveals two consumption peaks, that is, one smaller peak after lunchtime and a higher peak in the evening.Drilling down into the devices'-specific consumption (see Figure 4) explains these peaks.Among the observed devices, there are a freezer and a fridge that run through regular cooling cycles during the day and explain a large   percentage of the energy consumption.After lunch, a TV is switched on for a few houses, resulting in the first peak.A second and bigger peak occurs in the late afternoon, when the TV is switched on in combination with further entertainment electronics (i.e., a second TV set and a stereo).These statistics enable the user to get detailed feedback about the energy usage and show potential for energy saving, for example, by adapting the behavior or replacing energy consuming devices with more efficient ones.For instance, Figure 4 shows that, among the two TV used, the less energy efficient one is used more frequently than the other and swapping the two would result in savings.

Support for Electricity Demand Prediction.
As already shown previously, the proposed platform was developed in the context of the PEC project [4], where one of the aims is to improve the electricity demand prediction for private households.In the PEC architecture, trading agents use our system for collecting sensor data as input to their prediction models (see Figure 1).Fine-grained devices'-specific measurements can improve the accuracy of short term forecasts as illustrated in Figure 5. Specifically, the figure shows a sevenhour snapshot of data from our field trial.The displayed curves are the individual load profile (average weekday load of the specific household over 4 weeks), the real load, the predicted load using a persistent prediction, and load prediction based on device-specific measurements and machine learning techniques (ML based) [16].
The results show that the actual load drastically diverges from the long-term average.However, the prediction mechanisms both provide a good match for short-term forecasts [17].The highlighted parts in the figure mark where the persistent prediction and the ML-based prediction differ.As one can see, the ML-based prediction that uses devicespecific sensor data adapts better to sharp drops in the load  and provides better matches to short spikes.This results in an overall better prediction accuracy that is enabled by our sensing solution.

Performance Evaluation Results
. Since the typical deployment has multiple Gateways connected to one Backend, we expect the Backend to be the bottleneck of the system.For that reason, the evaluation presented in this section focuses on this component.Another critical component impacting on the performance of the system as a whole is the sensor network.However, its performance evaluation is not closely related to the software architecture, but it is rather in the domain of the radio propagation, which is out of scope for this paper.
For the performance evaluation of the Backend, we studied an urban site comprising 50 households (i.e., 50 Gateways), each of them equipped with 15 smart plugs reporting electricity consumption.Each message delivering the consumption report was 192 bytes long.We used JMeter [18] to emulate the data and signaling load going to the Backend REST interface.The JMeter engine was running on a dedicated server machine connected to the same Gigabit Ethernet segment as the Backend server machine.All the operating system tasks that were irrelevant to the load test were dormant, while network traffic on the Ethernet segment was monitored by Wireshark.
In the first test plan, we emulated only the traffic coming from the Gateway with the updates from smart plug measurements, and in the second one, we evaluated the performance of the system under mixed traffic coming from the Gateways and from the applications reading the measured consumption values.

Test Plan 1.
In order to measure the performance under different load intensities, we varied the frequency of smart plug measurements updates as presented with the black curve (target traffic) in Figure 6.In a real deployment (i.e., a production environment), the Backend will be required to demonstrate robustness to varying loads.Accordingly, we chose a stepwise pattern for the load test, rather than reset the Backend to a clean state before setting a particular load.This approach is useful in understanding the steady-state behavior of the system and for assessing the stability of the system's performance for different (steady-state) load levels, until the system reaches saturation.Specifically, with the last step of the target traffic shape we evaluate how the system recovers after operating in saturation.
As a primary measure of performance, we analyzed the rate of HTTP responses and the response time as a function of the load.Figure 6 depicts the rate of HTTP requests to the Backend REST interface over time.In the first 4 levels of the load (up to 100 requests/s), the rate of HTTP responses matches the input load.As the target input load grows further up to 140 requests/s, the total measured rate does not grow anymore, and the processing time at the Backend increases.This clearly indicates that the system is in saturation.As the load drops down to 70 requests/s, the system recovers very fast (within seconds) and continues to respond to all the incoming HTTP requests.
Figure 7 shows measured response time as a function of time, and therefore, load.We observed a steady performance for the first four levels of load which clearly deteriorates as the load increases (i.e., when the system is saturated).This clearly demarcates the good operational region of the system in terms of load and also provides insight into the scale-out properties of the system.

Test Plan 2.
The tests performed in the second stage had the goal to evaluate the performance of the Backend under more realistic conditions.The traffic generated by JMeter was a mix of HTTP requests coming from the Gateways (writing the sensor measurements) and from applications (reading them from the Backend).We used the same setup as in Test Plan 1, and in addition we assumed 50 applications (one for each household).The total target traffic for the Gateways was kept constant to 60 requests/s, as shown in Figure 8, whereas the applications traffic is changed stepwise from 30 to 140 requests/s and dropped to 70 in the last stage (see Figure 9).The grey curves in Figures 8 and 9 show the traffic that can be successfully handled by the Backend.As it is possible to see, the traffic coming from the Gateways can be handled throughout the whole duration of the test plan.On the other hand, the traffic coming from the applications cannot be handled at a rate higher than 100 requests/s, that is, when the Backend reaches saturation.Similar to the first test plan, the system recovers very fast once the rate of HTTP requests is reduced.What is also interesting to note is that the traffic from the Gateways has higher variance from minute 8 of the test, which corresponds to the saturation point.Figures 10  and 11 show the response time of the HTTP requests from the Gateways and from the applications.Delayed response by the Backend from minute 8 until minute 16 confirms that the Backend is in saturation at this point.Also, once the load from the applications drops to 70 requests/s, the response time is reduced as well.
In order to have an overview on the number of HTTP requests affected by high delay, in Figures 12 and 13 we show the response time distribution for both Gateway and applications requests, respectively, during the whole duration  of the test plan.As it is possible to see, the majority of queries show a response time below 100 ms, that demonstrates again the good operational region of the system in terms of load.Since the database represents the crucial component for our system's performance, we performed some measurements of the PostgreSQL that are reported in Tables 1 and 2. Looking at Table 1, we notice that the average duration time of the queries is 5 ms whereas the minimum and maximum duration is below 1 ms and 216 ms, respectively.The maximum duration has been achieved with a queries peak of 787 queries/s.As expected, SELECT queries last more than INSERT queries due to the fact that the SELECT function includes also a search inside the database, while the INSERT is only an operation of "append." In order to have insight about the high values of delay perceived during the phase of system saturation, we report in Table 2 some measurements related to the database checkpoint.A checkpoint is a point in time where all modified or added data in the system's memory are guaranteed to have been written to the disk.In case the database is written too heavily, such as in our case, it is possible to suffer from significant delay (many seconds long) during the periodic database checkpoints [14].As it possible to see, during our evaluation time a recycling checkpoint (meaning that after the writing procedure, an old log segment file no longer needed is renamed to be used afterwards), lasting about 184 s, has been performed.During this time, the system performance is affected causing the delayed response by the Backend described previously.

Related Work
The last years have shown a growing trend toward interconnecting devices to cooperate with each other to fulfill complex functionalities.Several systems integrating sensor networks with energy management systems at the consumer premises have been proposed so far.In [19], the authors evaluate the performance of an in-home energy management system based on a ZigBee wireless sensor network.The focus here is on the performance of the system on the application level, meaning the investigation of potentials of both energy management and demand management.Without going into details of the architecture of the underlying software or its performance, evaluation that has been performed is based on simulation results, and not on real network deployments in households as in our work.
Similarly, in [20], energy management in homes has been investigated, but based on a pilot consisting of only 3 households in Sacramento.The solution has been implemented using off-the-shelf components based on power line communication, and it included a web-based monitoring and control of home appliances.
In [21], the authors provide a set of algorithms and systems for enabling energy saving in a smart home.This work also makes use of the OSGi service platform; however, the authors do not focus on how the data gathered by their system could be reused by multiple applications nor do they provide details on how their system is implemented or how well it performs.
Closing the gap between the diversity of sensors, actuators, network technologies, and the ease of new application development, have been widely explored in the last few years, but there is still lacking a widely accepted solution and a robust set of implementations.
One of the first efforts to provide a higher level of abstractions for applications, development in wireless sensor network domain has been done in [22] where authors introduce a simple service-oriented model in which the responsibility for handling the service requests is delegated to an external entity acting as a bridge between external requestors and internal system functionalities.An adaptive middleware supports mechanisms for cooperative data mining, self-organization, networking, and energy optimization to build higher-level service structures.Whilst the concepts are promising, no implementation has been done for validating the presented concepts.
In the work presented in [23], service-oriented models, in particular web services approaches, have been applied to WSN.This is similar to our work (e.g., RESTful web services and JSON data format for data exchange), but this proposal lacks a real implementation which can unveil realworld problems related to the adoption of the proposed architecture.The same is the case for the work presented in [24], where a middleware service for sensor networks is proposed.Moreover, services on the sensor networks do not follow the conventional request/response service model which is widely accepted in SOA applications, and to this purpose new solutions should be developed.
In [25], the idea of providing an abstraction between the devices and the applications has been applied to a real use case: technology in the home.Specifically, authors propose HomeOS which represents the first architecture capable of providing a PC-like abstraction for home technology.Users and applications can find, access, and manage these devices via a centralized operating system.This operating system also simplifies the development of applications abstracting differences among devices and homes.The HomeOS project has a different focus to our work as it concentrates more on general consumer services rather than energy-specific services.Additionally, they do not provide a similar set of Backend features such as a CEP engine which is necessary for performing real-time analytics.
An IP-based smart monitoring system where nodes send data using web services is presented in [3].In particular, authors use the REST-based web services onto the 6LoWPAN architecture, allowing a direct IP access to the sensor network.This work looks more into the routing aspects of the wireless sensor network, which is a different angle to the work presented in this paper.Additionally, they work more with the REST API on the devices, rather than having a REST service on the Gateway and the Backend.Finally, the CEP engine integration which provides a great deal of functionality to our system is also not present in this work.
A Distributed Operating System (DOS) to support peer Internet access to home network devices is proposed in [26].Besides cache management, it schedules access to device services in coordination with their power saving policies and realizes resource control policies.Whilst the project is promising, there are very little details provided about the implementation details, and there appears to be no plans for a large-scale field trial such as the one underway as part of the PEC project that this work is part of.
An architecture for an adaptive system comprising selfadaptive gateways and sensors is proposed in [27].A middleware layer employs machine learning mechanisms to detect recurring event patterns.Contextual information (e.g., temperature, humidity, etc.) conveyed by the sensors drive the dynamic selection of the appropriate service, thus enabling adaptation.This approach focuses on evaluating a selfclustering (i.e., adaptive) protocol in the sensor network to optimize its power usage.Whilst there are architectural similarities between the design of their work and the work presented in this paper, our implementation efforts go significantly further.In particular, we provide a full implementation of our Backend system and show how it can be used in a live deployment.

Conclusions
We presented a novel platform which enables a smooth integration of sensors/actuators (e.g., smart plugs) with a SOA approach.The proposed platform hides the device-specific details and transforms data into a device-independent format, giving the possibility to use a variety of different applications on top of the platform.As an example, an application for energy consumption monitoring and its prediction for the optimization of the processes of utility companies has been presented.As a proof of concept, we have shown implementation and evaluation of our platform when used for residential energy monitoring.
For future work, we are deploying our system in a field trial where 100 households will be equipped with a residential energy monitoring system.This system will use the software presented in this paper and a variety of sensors, and it will offer a number of value-added services running on top of the platform.In particular, data analytics over the data set collected by the households will be investigated in order to provide support for value-added services.Coupled to this, another topic of our future work will be in the area of security and privacy, which is a prerequisite for a wider deployment of such a system.

Figure 4 :
Figure 4: Measured consumption on one day.

Figure 5 :
Figure 5: Demand forecast with smart building sensors.

Figure 6 :
Figure 6: Test Plan 1: target traffic sent from the HTTP traffic emulator and the rate of HTTP responses.

Figure 9 :Figure 10 :
Figure 9: Test Plan 2: target traffic sent from the application HTTP traffic emulator and the rate of HTTP responses.

Figure 11 :Figure 12 :
Figure 11: Test Plan 2: end-to-end response times for the application requests over time.

Figure 13 :
Figure 13: Test Plan 2: end-to-end response time distribution for the application requests over time.