An Adaptive Energy Management System Using Heterogeneous Sensor/Actuator Networks

1. Introduction

Global energy consumption has been increasing over the past half century, mainly due to increasing populations and economic development around the world. Although the development of low-consumption appliances, highly efficient heat pump systems (such as Ecocute), and smart meters that identify consumption in more detail than conventional meters contribute in no small part to reducing the emission of greenhouse gases in homes and office buildings, it is important to understand that the rapid growth in ubiquitous comfort services is resulting in higher power consumption. In the future, there may be more convenient appliances coming on the market to create a ubiquitous smart infrastructure.

Even though individual appliances might be ultra-low power, the amount of energy consumption in buildings will increase as the number of these appliances increases. There has been research in the field of home/building energy management systems (HEMS/BEMS) (Cao et al., 2006; Inoue et al., 2003; Kushiro et al., 2003; Zhao et al., 2010), but integrating new devices on the market is not easy. Moreover, it is difficult to develop appropriate systems for different lifestyles. For example, a building's carbon footprint is the product of complex interplay between the buildings' structural and infrastructure characteristics, operational patterns and business processes, weather and climate dynamics, energy sources, and workforce commute patterns. Because these disparate factors can change daily, any recommendation based on a snapshot will rapidly become invalid.

Therefore, we believe the key feature of next-generation HEMS/BEMS is adaptability. If the systems are able to use information from multi-vendor sensors/actuators in heterogeneous networks, we can develop more adaptable energy management systems for visualizing and controlling the living climate appropriately. We feel this would enable us to create ubiquitous services for a more convenient, eco-friendly lifestyle.

We have developed an adaptive energy management system (A-EMS) for controlling energy consumption by converging heterogeneous networks (Mineno et al., 2010) such as power line communications (PLC), Wi-Fi networks, ZigBee, and future sensor networks. We created a prototype system that enables users to freely configure a cooperative network of sensors and home appliances from a mobile device. Although there are many similar technologies for integrating multi-vendor devices (IEEE 1451; Sensor Model Language; Device Kit; Chen, et al., 2009), we used P2P Universal Computing Consortium (PUCC) technology, which enables sensors and other devices to connect to each other. PUCC has the advantage of detecting services and devices using a P2P network. We developed our middleware with Java, which can work as a bundle on an Open Services Gateway initiative (OSGi) framework (OSGi Alliance). Experimental results demonstrated that the proposed system can easily detect wasted electrical energy that has never been noticed before.

The rest of this chapter is organized as follows. Section 2 outlines heterogeneous network convergence as related work. In Section 3, we describe the features of our proposed A-EMS in detail. Section 4 discusses the implementation of our prototype and section 5 shows the experimental results. Section 6 concludes the paper with a brief summary and mentions future work.

2. Related work

There are currently many electrical devices connected to networks. However, many types of networks coexist, and they all use different communication protocols. Therefore, a technology to integrate different networks is needed to provide services and control various devices connected to different networks. In the same vein, sensor/actuator devices also have a networking function and can be used to construct a smart system (Tzeng et al., 2008; Han et al., 2010; Park et al., 2007; Son et al., 2010; Suh et al., 2008). However, most services for and studies on sensor networks are limited to a particular sensor network. If it were possible for sensors/actuators to communicate with several types of networks, various devices could use heterogeneous sensor data.

Because the Internet Protocol (IP) horizontally integrates the control mechanism between heterogeneous networks and their extensions, heterogeneous network convergence would provide a tremendous opportunity for future advanced infrastructure management. The trend with sensor/actuator networks is the same. Recent developments with small sensor nodes that can be connected to a network have spurred studies on integrating non-IP-based sensor networks, which function by connecting several nodes, in which IP-based sensor gateways are being developed as common interfaces for connecting devices.

To create IP-based sensor gateways, we can use a number of proposed standards to describe devices and enable their integration (Chen et al., 2008). For example, IEEE 1451 describes a set of open, common, network-independent communication interfaces for connecting devices to microprocessors, instrumentation systems, and control/field networks. SensorML focuses on creating measurement models using sensors and instructions for deriving more accurate information from observations. Device Kit, following SODA (Chen, et al., 2009), is an OSGi-enabled technology that can interface with hardware devices using Java. It enables the development of applications for devices when hardware-specific information is unknown. Although these standards model devices all have various advantages, we used PUCC specifications because they enable sensors and all other devices to connect to each other. PUCC has the advantage of detecting services and devices through a P2P network such as an UPnP network.

3. Adaptive energy management system (A-EMS)

3.1. Installation level

Although there has been previous research on HEMS/BEMS, it has been limited to “detect something and notify or control predefined action.” These systems are not versatile.

Figure 1.

Overview of proposed adaptive energy management system (A-EMS) and its implementation levels.

Moreover, it is not easy to integrate a vendor's new device after deployment, and it is difficult to develop appropriate systems for users with different lifestyles. Fig. 1 shows an overview of our proposed A-EMS and its implementation levels. We designed the A-EMS on the basis of a sensor cloud as a feedback system. In the proposed system, a PUCC P2P network is established among IP-enabled nodes. If the sensor gateway of another domain network acts as the PUCC P2P node, the PUCC P2P network incorporates the heterogeneous network and allows P2P nodes and sensor gateways to access the connected network adaptively.

The system can be installed in a phased manner depending on the required energy management level and available sensor/actuator devices. Level 1 visualizes the living climate. We can visualize the transition of unknown information, such as living climate data and someone's presence or absence, by installing different types of sensor nodes that sense illuminance, temperature, humidity, and motion. Level 2 visualizes the energy consumption. We can determine the effect of energy-saving actions by revealing the correlation between life pattern and energy consumption via additionally installed smart power strips instead of existing power strips. In this work, we assume the smart power strip is an electrical meter that can remotely report the power consumption in addition to power factor, electrical current, and pressure of connected devices. Level 3 controls the legacy appliances. If the smart power strip can turn on/off the connected devices remotely, we can execute basic living climate control for energy saving, such as turning off the standby power of appliances. Level 4 controls the appliances that have an infrared remote (IR) control function. There are many devices in homes that have this function, so we can include multi-vendor devices as controlled objects if such an actuator node is installed in our system. Level 5 achieves coexisting. If healthcare sensors, such as body temperature, heartbeat, or weight, are installed in the system, it can execute personal living climate control based on different comfort levels and conditions. Then, at level 6, the living climate control is consciously aware of the balance between natural and artificial control because it takes advantage of information on heterogeneous networks as well as information from the weather sensor and micro-grid (solar, heat, gas, and fuel cell).

3.2. PUCC overlay sensors/actuator network

The PUCC is a standard-setting organization that develops technologies to connect and operate many types of devices on P2P overlay networks. By forming an overlay network using PUCC protocols, we can seamlessly connect devices in a heterogeneous network environment. PUCC protocols are defined on an application layer as an upper-level protocol of existing communication protocols like TCP/IP and ZigBee.

The PUCC platform provides these protocols as general-purpose middleware independent of any specific application. Various P2P protocols necessary for P2P communication can be implemented in this platform. A middleware application programming interface (API) enables access to P2P protocols. By installing PUCC middleware on every device or gateway that communicates with other devices, various functions are provided in addition to P2P communication (Kato at el., 2009). We developed a library for communication using PUCC protocols that provides the API which device can participate in the PUCC network and uses methods to enable cooperative behavior with other devices. Methods that are central to our system include the discovery, subscribe, notify, and invoke methods.

The discovery method enables us to obtain information about a device in the network. This information is described in a PUCC format. The subscribe method enables us to know of changes in devices states. The device monitors its own status, and if it changes, it announces the change by using the notify method. The invoke method enables us to execute services involving a device: e.g., turning on an appliance.

The PUCC P2P and gateway nodes have metadata to describe information on published services (Fig. 2). If the gateway node has several devices/nodes connected to another domain network, the gateway might describe several services as either one or several sets of metadata. A metadata sample is shown in Fig. 3.

3.3. Mutually complementary communication

We proposed the use of a mutually complementary communication protocol (MCCP) for indoor sensor/actuator networks based on multi-interface communications (Sawada et al., 2011). The MCCP uses several metrics of link quality indicator (LQI) in each interface to cognize the state of the path and tracks the variation of the network topology for transmitting data. Each node periodically informs the LQI values of each interface, each node is able to select the better interface for transmitting data to the neighbor nodes. The protocol basically follows the link state routing protocol which is well used in the computer communication network.

Figure 2.

Overview of PUCC metadata.

Figure 3.

Sample of PUCC metadata.

The LQI value varies according to the communication environment, that is, the high LQI value shows the environment is good for communication, and the low LQI value shows the environment is bad for communication. Therefore, simply comparing the LQI of all interfaces and select one of them which shows the highest LQI value is one method of switching the interface. The MCCP converts LQI into packet reception rate (PRR) for comparing the interface in the same scale.

In routing, the MCCP follows not only the shortest path routing method but also a policy to select a path which has totally the most high quality links. To increase the choices of the path selection, the protocol is used to consider redundancy paths to a destination as much as possible. Moreover, the MCCP adapts to the variation of topology by updating the routing table dynamically. The network consists of a top router, routers, and end devices. The top one not only routes data to other routers but also manages the whole network. The role of the router is only to route data to other routers. End devices, which are sensor or actuator nodes, send data directly to a router. One router and some end devices are connected in a star topology and make up a subnet. Each subnet is connected with each router in a tree topology.

Each router, including the top one, has its own neighbour table, which is constructed by exchanging hello packets with each one-hop neighbour routers. The hello packet, the structure of the neighbour table, and their usage basically follows the TBRPF neighbour discovery (TND) protocol (RFC 3684). The switching method, which means how to select the interface for transmitting, uses the field of 'Metric' of the neighbour table. The neighbour table is also used for finding out the disconnected link with the neighbour router. If a router finds a disconnected link, it sets the link state information to its neighbour table, and advertises the information to its routing path.

The MCCP uses a table-driven routing method. Each router in the network has its own routing table. The routing table is constructed when the router joins the network, then it updates its own routing table dynamically by exchanging topology update packets periodically with its neighbour routers. When a router joins the network, it constructs a routing table as follows. First, when the router finishes its initialization, it broadcasts a 'Top Router Join' packet to send it to the top router by multi-hop. When the top router receives the 'Top Router Join' packet, it broadcasts a 'Top Router Offer' packet to send it to the router by multi-hop. At this time, the router identifies the shortest path to the top router by counting hop counts of the 'Top Router Offer' packet. The router then sends a 'Top Router Confirm' packet to the top router to advertise that the router could join the network. After joining the network, routers exchange topology update packets with neighbour routers to keep the latest link state consistent.

A network of the MCCP is able to function as an overlay network that consists of multiple networks of different interface. With the overlay approach, user applications do not have to factor in which interface to use when transmitting data. Moreover, as the number of interfaces, redundant paths also increase.

4. Prototype development

4.1. Prototype hardware platform

We gradually developed various sensor/actuator nodes and several enhancement modules to use in our proposed A-EMS. Fig. 4 shows some of the developed prototype hardware.

The ZigBee sensor node (a), the first we developed, is equipped with three sensors for temperature, illuminance, and motion. It can be operated with 4 AAA batteries or an AC adapter. We used Renesas Technology Co.'s MCU as the ZigBee modem module. The user application and device driver programs are also implemented on this MCU.

The power consumption measurement module (b) is one of the enhancement modules we developed that can be connected through the UART serial interface with a ZigBee sensor node. We used a PIC16F877 as the MCU of this enhancement module. This module can measure instantaneous voltage and current values at the same time with a transformer (VT) and a current transmission (CT), respectively, as well as active power, reactive power, apparent power, current consumption, and moment of force. The average power consumption is calculated for the product of the instantaneous value of the measured voltage for four cycles and the instantaneous value of the measured current. The measured precision is within ±2% by using various loads from a low to high power factor that are then compared with Yokogawa Electric Works, Ltd.'s WT230, which is a highly accurate power meter.

The router node (c) consists of a main application board with a ZigBee module and a power line communication (PLC) module. The application layer and the device driver program manage these modules using a real-time OS, Renesas Technology Co.'s M3T-MR30/4, to conform to the μITRON 4.0 specifications. Our connected medium-speed PLC modem enables PLC at about 400 kbps with a frequency band of 2 to 9 MHz.

Recently, we developed power-saving, small-sized IEEE 802.15.4 sensor nodes (d) (e) (f). They work in combination with replaceable boards such as network, living climate sensor, IR remote control, and smart power strip boards. We used a Renesas Technology Co.'s R8C as an MCU. These nodes can be operated with either CR2 batteries or an AC adapter. They can also be connected to additional sensors, such as soil moisture and CO2, via I2C bus.

The sensor node (d) is equipped with four types of sensors for temperature, humidity, illuminance, and motion. The standby power is about 37 μA and the operating power is about 26.8 mA. If we assume intermittent operation with 10-minute intervals, 80% battery efficiency of the 750 mA CR2 battery, and 2.7 V stable operating voltage, the sensor node runs approximately 602 days.

The IR control node (e) has one IR receiving part and four IR emitting parts. This node, which can record 20 IR signal patterns via the IR receiving part, is used to operate appliances that operate via IR control, including TVs, HDD recorders, and air conditioners.

The smart power strip node (f) has the same function as the power consumption measurement module (b). This node can remotely turn on/off connected appliances by attaching a solid state relay (SSR) module. We used a Panasonic Electric Works Co.'s AQA611VL as the SSR. The load current was 40 A.

Fig. 5 shows the block diagram of our developed network board. Each type of sensor node consists of the combination of replaceable boards and it has self-networking and communication abilities. The network infrastructure is deployed through router nodes that can create a multi-hop network by wireless or power line communication. The system is useful for improving network facilities in old buildings or houses that do not have enough network cables.

4.2. Prototype implementation

We implemented a prototype system based on our design shown in Fig. 6. The left side of the figure shows the overlay sensor/actuator network. The sink and coordinator nodes are connected to the sensor gateway, which integrates sensing data from different sensor networks and either stores it or passes it on to client devices or other devices equipped with a PUCC application. To integrate multiple sensor devices, which can be of different types, all sensing data that is not required for real-time features is stored in an integrated DB (a PostgreSQL in this prototype). Information about the sensor device is stored in the metadata and a table for the sensing data is created in the integrated database (DB).

Figure 4.

Developed hardware platform.

Figure 5.

Developed hardware platform.

The actuator controller module monitors the sensing data selected by the client device and checks if the event occurrence condition is satisfied. If the sensing data satisfies the occurrence condition, the controller module informs the service management module. In addition, if a sensor device that has been monitored is pulled out of the network, this module informs the service management module that event detection has become impossible.

The actuator controller module enables composite event detection using sensing data that belongs to a different sensor gateway. This module executes parsing, creates an event tree for a composite event, and facilitates the monitoring of the selected sensor device. If the sensing data satisfies the event occurrence condition, this module checks whether the value satisfies the service execution condition based on the event tree. If it does, the service management module is informed. If not, this module tells other sensor gateways that have not yet satisfied the event condition that its sensor gateway satisfied the event occurrence condition. On the other hand, if the sensor data falls outside the range of the event occurrence condition, this module informs every sensor gateway related to the composite event.

Figure 6.

Prototype implementation.

The sensor gateway processes messages generated when a gateway communicates with other PUCC nodes, such as a client device, through the PUCC platform. On the basis of the sent message, the appropriate process is executed to refer to a DB table or request a definition of services and events from the service management module.

Although the PUCC P2P nodes function as the sensor gateway and the mobile phone in this prototype system, we can freely configure the cooperative behavior of sensors and actuators from any mobile device. It is easy to integrate other new devices after deployment and to develop appropriate systems for indivisuals with different lifestyles through the PUCC platform.

4.3. Controller user interface

As shown in Fig. 7, we implemented the user interface on a client's device. In this case, we controlled the camera based on the status of the sensor nodes. Each element in the system works as described below. We used a Nexus One smart phone equipped with the Android OS and installed our developed PUCC middleware. With this middleware, the user can configure an event detected by a sensor and the service provided by a device.

The client device finds the devices by using a discovery method and generates a GUI from the collected information. The client can then use the GUI to define the event condition (such as temperature > 30 degrees) that sensors can detect. After defining the event condition, the user can also select a service for this condition. When the user finishes the configuration, the middleware sends the event condition to the sensor gateway. When sensors satisfy it, the middleware receives the notify message and then sends an invoke message to the home appliance gateway to execute the service.

The sensor gateway has metadata, information about the device itself, and sensors collecting data, so the client device is able to know what types of sensors are connected to the gateway. When the gateway receives a subscribe message from other devices, it analyzes the event condition and determines if the sensor data matches the condition. If it does, the gateway notifies the user or other gateways with a notify method.

The home appliance gateway has metadata, information about the device itself, and a connected appliance, so the client device is able to know what kind of service is at the connected appliance. When this gateway receives an invoke message from other devices, it analyzes the messages and determines which service to execute.

Figure 7.

Controller user interface on mobile phone.

4.4. Visualization user interfaces

We developed several Web interfaces to convert the information gathered by sensors into user-friendly formats, as shown in Figs. 8 and 9. When a user accesses the interface to view selected records (Fig. 8), he or she inputs the ID for the selected sensor, a start and finish period, and the number of records requested (distributed evenly in the time period) with a check box that can handle two or more selsections. Options include light, motion sensor, temperature, humidity, battery power, power consumption, measured voltage, and power factor. This sample shows the trend charts of light, motion, temperature, and power consumption with an amChart [9] that can display the graph with JavaScript and Flash.

The volume of information from the sensors is huge, so when all the information is downloaded for each case, the infrastructure between the Web server and the PostgreSQL server is overloaded. To solve this problem, we implemented a function inside the PostgreSQL server that requests only the required amount of data. The ID, term, and amount of desired data are then transmitted to the PostgreSQL server from the Web server PHP. The selection function gathers the requested information from the tables on the PostgreSQL database in accordance with the timestamp and then sends it back to the PHP. The PHP makes an XML file from the PostgreSQL data and reads it with a drawing program.

Figure 8.

Visualization user interface for each sensor node.

Fig. 9 shows another visualization user interface for grasping an entire area. The color of each rectangle indicates the measured temperature of each sensor node. Blue is colder and red is hotter. The size of the center circle within each rectangle shows the activity level based on the detection conducted every 15 minutes. The blue color of each center circle depicts the detection of the motion sensor. The small circle on the upper left of each rectangle shows the someone's presence or absence at each work space predicted by simple data mining. This interface reports increasing activity as the circle gets bigger. Users can observe the living climate at any time through the Web browser.

5. Experimental results

5.1. Experimental environment

We deployed our developed nodes in our laboratory as shown in Fig. 10. We installed 54 ZigBee sensor nodes (Fig. 4(a)) on the ceiling, ten power consumption measurement nodes (Fig. 4(b)), six ZigBee router nodes, and a sensor gateway connected to the ZigBee coordinator and the sink nodes. The appliances connected to the power consumption measurement nodes included printers, a refrigerator, a microwave, an electric pot, a plasma display, circuit breakers, and power strips. We installed two types of power consumption measurement nodes: one for plugging appliances (Fig. 11(a)) and the other for attaching to a

Figure 9.

Visualization user interface for grasping entire area.

circuit breaker (Fig. 11(b)). This experimental environment corresponds to the second installation level of our A-EMS.

To evaluate the accuracy of our developed power consumption measurement node, we also installed another electric power meter (SyoeneNavi, CK-5 and WHM3-SP01, made by Chugoku Electrical Instruments) in the circuit breaker in room J1407.

5.2. Validation of our power consumption measurement module

We measured the accuracy of our power consumption measurement node with SyoeneNavi. Fig. 12 shows the measured power consumption of a circuit breaker in room J1407 from midnight to 11 p.m. on March 23, 2010. Fig. 12(a) shows the power consumption result without any tuning. As for the transition time of power consumption, almost the same results are obtained, though an offset average of a 17 Wh increase is caused overall compared with SyoeneNavi. Fig. 12(b) shows subtracks of offset processing. There was a difference from -33.6 Wh to 24 Wh at the location in which a power consumption of 400 Wh was exceeded through measurements of SyoeneNavi. The result for power consumption of less than 400 Wh with our developed node and SyoeneNavi were the same. It was 5,953 Wh in our developed node and 5,876 Wh in the SyoeneNavi measurement when the entire amount of power consumption on this day was calculated. To make the measurement equal to SyoeneNavi, we should add the offset processing when the error margin rate based on SyoeneNavi is within 1%.

5.3. Evaluation of detailed breakdown function of electric energy

We evaluated the function that breaks down in detail the amount of power consumption. Fig. 13 shows a detailed breakdown of hourly electric energy for each time zone. The bar

Figure 10.

Experimental environment in our laboratory.

Figure 11.

Power consumption measurement nodes.

Figure 12.

Validation of our developed power consumption measurement module.

graph indicates individual energy consumption of the connected appliances (refrigerator, electric pot, power strips, etc.) to the power consumption measurement nodes. The maximum value is the measured electric energy at the circuit breaker in room J1407.

We can see an individual's behavior such as turning on a PC, LCD, or printer, from 9 a.m. to 6 p.m. The power consumption of the equipment connected to the power consumption measurement nodes is indicated as part of the power strips. The other parts in Fig. 13 show the power consumption of equipment connected to the buried outlets that were not directly connected to the power consumption measurement node, such as a miniature heater, the access point of a wireless LAN, two cordless handsets, a plasma display, and so on. The data from 6 o'clock to 11 p.m. suggests that the individual's behavior is not seen because the electric energy is lower than 190 Wh. The consumer electronic products with the highest consumption are a refrigerator and an electric pot. The average electric energy of the refrigerator was about 100 Wh and the electric pot was about 62 Wh.

The result of visualizing the individual energy consumption led us to conclude that reducing the power consumption of an electric pot is an energy-saving action, as has been widely alleged. When nobody is using it, the power supply of an electric pot should be unplugged and kept warm for a shorter time. Fig. 13(b) shows the effect of energy-saving actions, such as unplugging an electric pot from 5 p.m. to 9 p.m. The amount of power saving per month was about 29.5 KWh. This enables us to save 649 yen a month based on the charge unit price of 22 yen, the average unit price of the nationwide electric power company. This amounts to electric bill savings of about 8,000 yen per year.

The experimental results showed that a detailed breakdown of the amount of electric energy for each time zone can reveal the waste of power consumption in our daily life. It also gives us the chance to think of better energy consumption habits.

Figure 13.

Detailed breakdown of electric energy data at circuit breaker.

6. Conclusion

We proposed an adaptive architecture for A-EMS that can control energy consumption by maintaining a certain installation level through converged heterogeneous networks. We developed various types of evaluation nodes and several enhancement modules to deploy the proposed A-EMS. We also developed a prototype system that enables users to configure a cooperative network of sensors and actuators from a mobile device. If several multi-vendor sensors/actuators in heterogeneous networks are able to communicate with each other, information that sensors have could be used extensively by many ubiquitous services for a more eco-friendly lifestyle.

Experimental results for our prototype system showed that it is possible to adaptively improve energy efficiency using the proposed A-EMS. For example in our laboratory, the amount of power saving per month was about 29.5 KWh. This enables us to save 649 yen a month based on the charge unit price of 22 yen, the average unit price of the nationwide electric power company. This amounts to electric bill savings of about 8,000 yen per year.

In our future work, we plan to deploy a controlling function based on data mining to activate installation level 3 or more. We will quantitatively evaluate the reduction in energy consumption, and we aim to make out A-EMS a more versatile system by deploying different types of sensors and actuators, developing device searching that uses the location information of the device, and increasing the number of services a user can request.