Green UT Energy-Aware Facility Networking: a Challenge tothe Standardization of Architecture and its Protocol
Hideya Ochiai
Noriaki Fujiwara
Hiroshi Esaki
The University of Tokyo Panasonic Electric Works The University of Tokyo
jo2lxq@hongo.wide.ad.jp fujiwara@panasonic-denko.co.jp hiroshi@wide.ad.jp

Abstract
This paper describes an activity of architecture andprotocol standardization for energy-aware facility
networking. Standardization allows world-wide productdevelopment by industries with reasonable cost,enhancing the installation of energy-control systems intobuildings, factories and houses. We present the working
status and the overview of the developing standard. Our
work is based on a prototyping and operational
experiences in Green UT project and Live E! sensor
networking project. We are also going to develop
reference codes for the specification in order toencourage industries to develop their own product forthe standard.
Key words: green IT, facility networking, standardization

1. INTRODUCTION
Facility networking in buildings, factories and houses
is widely acknowledged as a promising technology forenergy saving or the reduction of energy wastes. Themajor changes from the traditional facility networking(i.e., building automation) to the energy-aware facility
networking are (1) analytical works on wider range ofdataset, (2) density of deployed sensors and actuators,(3) flexibility of working mode setting and (4)collaborative system operation.
There are many standards for facility networking,which had certainly increased the deployment into
buildings by industries with reasonable cost. However,
the existing standards targeted at building automation
cannot cover our intended energy-aware facility
networking. We urgently need standard architecture andprotocols for this purpose.
We have started a protocol standardization activity. In
this paper, we describe the working status and theoverview of the specification. We develop thespecification, based on a three-tiered architecture asFigure 1. Three-tiered facility networking architecture.

figure 1. This architecture has three types ofcomponents: i.e., (1) gateways and field-buses, (2) data
storage, and (3) application units. Gateways, data
storages, and applications are networked by TCP/IP, andeach component is developed, deployed and operated bydifferent vendors and companies. We describe the detailin section 3.
Standardization of energy-aware facility networking
systems will enhance the installation of energy-reduction
systems more easily. Once we made a standard, any
companies will be able to join in developing a part of thesystem. The industry by several companies continues
developing the system components, which makes theinitial and running costs reasonable for building, factoryand house owners.
The protocol standardization activity in Green UT[1]has started from February 2009. At the first stage of
discussion, we have listed up the system requirements.
Now, at the second stage, we have been developing a
protocol specification in detail. We are also going todevelop an open reference code in Java in order toencourage product development by industries.
In energy-aware facility networking, data analysis
from wide range of dataset is necessary. Most of theanalysis will be statistical-based. For example,
understanding energy-wasting situations will require thetrack of people, the log of light control and HVAC
system over at least one month. In order to manage thosedata, the system needs data storage that archives suchamount of dataset.
Our work is based on the development andoperational experiences on Live E!-based facility
networking system. We have studied lots of issues fromthe prototype operation. This practical study certainly
helps for designing the specification, avoiding systemdesign pitfalls.
This paper is organized as follows. Section 2 describes
related technologies to our work. In section 3, we
present the progress and the overview of ourstandardization activity. In section 4, we describe ouroperational experiences on our prototype system Section
5 gives the conclusion of this paper.

2. RELATED TECHNOLOGY
2.1. Field-bus technologies

grown to 46 pages. Since we cannot describe them all inthis paper, we present the major requirements below.
1.
2.

3.
4.

To archive the historical data of INPUT andOUTPUT devices.
To design communication protocol for large dataset
management (we explicitly state this because mostof the existing protocols do not aware it)
Co-existence of system operators and developersfrom different organizations and policies.
To share semantic information for basic knowledge
exchange among multiple operational domains.

The following requirements are related to 1. and 2.:
5. On-demand transfer (large dataset) for INPUT
dataset6. Event-based transfer for INPUT dataset
7. Configuration method for OUTPUT devices

There are existing standard field-bus technologies.
Lonworks[2] defines device-to-device communication
protocols over twisted-pair lines. Modbus[3] defines acommunication protocol over power lines. Zigbee[4] isfor wireless sensor networking. 1-Wire[5] enables
device networking without power supply using the line
signal as the power source of devices.
These field-bus specifications have enabled the device
development open; any companies can develop theirown products and sell world wide where the protocol isused. However, these field-bus technologies themselvesbasically do not consider IP-networking and datastorage.

The following requirements are related to 3.:
8. User Authentication / Authorization
9. Access Control
10. Access Confliction Management
Access Priority

Mutual Exclusion

2.2. Facility networking over IP

3.2. Architecture

The need of facility networking over IP (e.g., remotemonitoring and control, generalized access for different
types of field-buses, and field-bus clustering at a largebuilding) has motivated the development of standard
access protocols.
BACnet/WS[6] defines device access protocol bySOAP-based web service. oBIX[7] defines anotherdevice access protocol by HTTP-based web service.
Hosts in IP networks can access devices behind
gateways in the same manner. These protocol standards
have allowed any field-bus implementation; however,the protocol itself is not designed for large dataset
management, which must be necessary in energy-aware
facility networking.

The architecture has three components as we havepresented in figure 1: i.e., gateway (GW), data storage
and application unit.
Gateway and field-bus: A gateway provides input
and output (I/O) methods for data points,
encapsulating any concrete field-buses that havereal sensors and actuators. The logs of the input andoutput values should be submitted to storage.
Application units can directly access to a gateway
to read the current value and to write a new value.
Data storage: Storage archives the history ofobserved and setting values of data points.
Application unit: Application units provide
interfaces to the system operator. An application
unit generates monthly report of energy usage,
sometimes with graphical user interface. An
operator configures the schedule of control modesettings via another application unit. Someapplication units might autonomously analyze theenergy wastes and optimize the configuration of

3. GREEN UT SPECIFICATION
3.1. System Requirement
We have discussed six months for summarizing system
requirement carefully, and the working document has

The following requirements are related to 4.:
11. Search (or lookup) method
12. Location naming
13. Measurement unit naming
14. Data type identification (boolean, integer, etc.)
15. Other application specific semantics

Figure 2. Data transfer

control. To perform these tasks, application units
retrieve data from the storage and sometimes fromsensors directly, and submit new setting to thegateways.

2.

periodically to update the lifetime of the query holdin the provider.
The provider notifies to the callback location when
it has observed the updates that match the query.

3.3. Data Transfer

4. PROTOTYPE EXPERIENCES

We present data transfer protocol for INPUT dataflow
as an example of the specification. In transferring data,
we assume requester and provider (Figure 2); requester
submits query that describes the range of interested
dataset, and provider returns the body of data. GWs,
storage and application units can work both as arequester and a provider.
We define two types of data transfer modes: ondemand transfer and event-based transfer. On-demandtransfer is for retrieval of the existing data: i.e., current
data or archived data that stored in memory space orstorages. Event-based transfer is for notification of thedata updates: i.e., data transfer when the timestamp haschanged or the value has changed. On-demand transfer
request will be made mainly on GWs and storage, andevent-based transfer request will be made mainly on
GWs. On-demand transfer mode should be able to work
even at the large data scale.

Along with our standardization activity, we have beenpractically working on our Live E!-based prototype
facility networking system and studying the issues on theexperiences, which helps for avoiding the pitfalls insystem designs. Figure 3 shows the configuration of ourprototype system.
The total number of data point is 1609 as of
September 2009. Most of the data points are associatedto the devices deployed in Eng Bldg. 2 in the Universityof Tokyo. 868 points are for electric power management,
40 points are for lighting control, 669 points are for
HVAC systems.
7 companies' field-buses have joined to this facility
networks. They use BACnet, Lonworks, and otherprotocols at their field-bus level. Gateways encapsulate
those differences and submit the historical data to a Live
E! database[8].
The dataflow going into the database is about 788,000
records per day. Some data points submit data every
minute, others every thirty minute and so on. The size ofdataflow certainly changes depending on the frequencyof data submission.
Live E! database[8] was originally designed forweather data collection from internet weather stations. Infact, facility networking is different from weather sensor
networking, and we learned lots of issues from theoperational experiences on this prototype.

3.3.1. On-Demand Transfer
1. A requester calls read procedure at a provider. The
requester submits the range of dataset by a queryand acceptable data size.
2. The provider returns the corresponding data to thequery. Here, if the data size exceeds the acceptabledata size, it returns a part of the dataset and a handle
associated to the succeeding dataset.
3. If the requester received a handle, it calls readprocedure again with the handle. Go to 1.
4. If not, all the data are retrieved, and it finishes.
3.3.2. Event-Based Transfer

Figure 4. Description of the same roomby different operators.
Figure 3. Prototype System

1.

A requester calls subscribe procedure at a provider.
It also submits query, the validity time of the query,and callback location. This call should be madeData structure needs to be modified so that
operators can handle them more easily in facility
networking. Live E! database is designed genericfor any data types and it can import any types ofsensor data. However, dataset is structured so that

5. CONCLUSION

Figure 5. Description of system status
by different operators.

We have been developing standard protocols forenergy-aware facility networking. Our standard
considers the use of IP and data storage, which isessential to energy-aware facility networking.
The standardization activity has stared on February
2009, and we have already summarized basic
requirements for the specification. As of September
2009, we are now designing the specification, anddeveloping reference codes for the specification.
This specification is based on our prototype
experiences in Green UT project.

Acknowledgement
Along with authors, Cisco, Daikin Industries, Digital
Electronics Corp., IEIEJ, Keio University, Kajima Corp.,
NTT facilities, Shimizu Corp., Toshiba, Ubiteq,
Yamatake Corp. involve in this standardization activity.

References

Figure 6. Sequence pattern for consumed energy.

operators can handle them easily in weather sensorapplications.
The retrieval interface must support large datasetretrieval. Live E! database provides RPC-based
data retrieval interface. When a user inquires alarge dataset, it takes a long time and sometimes
fails before returning the requested data.
We have to manage semantic information space totell background information of points to otherdomain systems. This leads to the semantics
modeling part in the specification.

Without managing semantics, the following threetypes of issues have certainly happened.
Operators have described each data point
differently in their own manner, which madeapplications difficult to search the data points(Figure 4).

Different field-buses used different expressions fordata values (Figure 5).
Even for the same category's data point, thedetailed meanings were different among different
companies (Figure 6).

[1] Green UT Project, http://www.gutp.jp/[2] Lonworks, http://www.echelon.com/[3] Modbus, http://www.modbus.org/[4] Zigbee, http://www.zigbee.org/[5] 1-Wire, http://www.maxim-ic.com/products/1-wire/[6] BACnet/WS, http://www.bacnet.org/[7] Open Building Information Xchange(oBIX),
http://www.obix.org/[8] H. Ochiai, S. Matsuura, H. Sunahara, M. Nakayama,and H. Esaki, "Operating architecture and multi-attributesearch for wide area sensor networks", Transaction onCommunications, IEICE, Vol.J91-B, No.10, pp.1160-1170, October, 2008