Automation in Construction 16 (2007) 112 – 121 www.elsevier.com/locate/autcon
A middleware for web service-enabled integration and interoperation of intelligent building systems Shengwei Wang a,⁎, Zhengyuan Xu a , Jiannong Cao b , Jianping Zhang c a
Department of Building Services Engineering, The Hong Kong Polytechnic University, Kowloon, Hong Kong b Department of Computing, The Hong Kong Polytechnic University, Kowloon, Hong Kong c Department of Civil Engineering, Tsinghua University, Beijing, PR China Accepted 10 March 2006
Abstract This paper describes a middleware framework for integrating heterogeneous building automation systems (BAS) on the Internet. The proposed framework combines OPC (OLE for Process Control) and Web Services to integrate data and services on the Internet. It utilizes the OPC technologies in LAN and the powerful communication capability of Web Services to accommodate different communication interfaces/protocols and provide public Web Services methods. These public Web Services methods can be invoked by heterogeneous BAS or other enterprise applications to realize BAS integration and interoperation with enterprise applications on the Internet, thus filling the gap between BAS control network and data communication network. The design and implementation of the middleware technology are presented in this paper. Experiments and evaluation on performance of the middleware are also conducted and presented. © 2006 Elsevier B.V. All rights reserved. Keywords: Building automation system; Integration; Interoperation; Intelligent building; OPC; Web Services
1. Introduction Nowadays, there exist two challenges in Intelligent Building (IB) integration research. One is how to overcome the incompatibilities and limited opportunities for the integration of building automation systems (BAS) among products of different vendors. Another is how to integrate BAS with the Internet and enterprise applications. These challenges have frustrated real estate developers, building owners/operators, consultants and system integrators [1]. In a typical BAS setup, different communication protocols are employed, even among the products from the same company. A popular way to integrate the products using various protocols is to employ the hardware gateway method [2]. The hardware gateway plays the role to convert a protocol to another protocol by mapping data points from one protocol to another protocol [3]. However, the development of the hardware gateway requires significant efforts and the developer needs to understand the ⁎ Corresponding author. E-mail address:
[email protected] (S. Wang). 0926-5805/$ - see front matter © 2006 Elsevier B.V. All rights reserved. doi:10.1016/j.autcon.2006.03.004
technical details of the two protocols for conversion. Considering so many protocols existing currently (mainly proprietary protocols) and protocols-specific character of gateway, the development of gateways is very costly. A lot of configuration efforts are needed for the gateway to map the data points correctly. This makes gateways expensive. The gateway also slows down the response due to the time required for conversion. Furthermore, one can hardly program and configure a controller through a gateway [4]. Another approach (the best approach) is to try to employ open and standard communication protocols to uniform the communication process from bottom layer to top layer. Several open solutions have become available in recent decades. One such solution is provided by BACnet™: The Building Automation and Controls Network [5]. BACnet is a standard for computers used in building automation and controls systems that has been developed by ASHRAE. In 1995, BACnet was also adopted by ANSI, and is now an American National Standard (ANSI/ASHRAE 135-1995) and ISO Standard (ISO 16484-5) [6]. Another completely different solution is called LonWorks which has been marketed for several years. Various vendors have used LonWorks successfully in recent years to
S. Wang et al. / Automation in Construction 16 (2007) 112–121
provide solutions for small controls systems applications, in some cases involving multiple vendors [1,7]. Great progress has been made on standard communication protocols of BAS. BACnet has developed the full-fledged international standard, having the capabilities from bottom layer (field layer) to top layer (BAS layer) for intelligent building application. In the period of this research, ASHRAE has issued BACnet Web Services Interface Specification for Public Review [37]. However, proprietary protocols still dominate the current BAS market even today mainly due to business reasons according to the Frost and Sullivan Report A143-19, namely, “North American Building Automation Protocol Analysis” [30]. The LonWorks camp has accommodated part of their products with Web Services interface as well [38]. As a result, the endeavor to solve the integration and interoperation problem from bottom layer to top layer using a common protocol seems to have a long way to go. In such situation, developing a middleware technology to achieve integration among BASs on higher layer, namely, BAS layer is very useful besides the two ways mentioned above. This middleware technology will focus on integration and interoperation on BAS layer; it will not substitute or influence the manufacturer-specific products, protocols, and configuration tools. That means, on the automation layer and field device layer, the control networks can keep running on the original protocols, the controllers can be configured by the original configuration tools from the manufacturers. In a modern complex, usually multiple sub-systems from various manufacturers are installed. Sub-systems are supervised via their own BAS software systems. These BAS software systems from different manufacturers are based on various hardware platforms and Oss, providing different communication interfaces. In order to realize integration and interoperation among these different subsystems, developers have to make various BAS software systems communicate effectively. Middleware technologies, including DDE, COM/DCOM [31], OPC [10], CORBA [11], and JAVA/RMI [12] have been developed to establish the communication among applications. Among them, DDE has been gradually phased out for its poor performance. N. Lu et al. [32], Y. Wang and Z.Y. Wang [34] and H. Guo et al. [33] have completed the primary design about CORBA used on IB system. However, little information on deep implementation has been published. RMI can be seen on some mobile IB applications and agent applications [38]. Probably due to the broad use in the automation industries and the popularity of Windows platform, some manufacturers have applied OPC technology on BAS integration [13]. It seems OPC has broader use than the other middleware technologies mentioned above. During the past years, BASs have been increasingly seen as part of a much larger information system. Facilities Facility managers now routinely resort to specialized software for managing their tenant spaces, their assets, their equipment maintenance, and even for their energy procurement [14]. Facilities owners today are looking for a BAS as a data source to help them better run their business based on the infrastructure of their existing Intranets and Internet and the same standards as other IT devices [15]. The requirements for “information
113
integration” are now much broader than those in the past. In particular, the broad acceptance and ever lowering cost of Ethernet/Internet/XML/Web Service communications is finding its way into IB industry [15]. Broader “information and services” integration and more powerful function integration among BASs or even with other enterprise applications on the Internet become more and more important today. The currently-used integration software systems usually realize integration and interoperation of BASs in the LAN. Internet access to building management system (BMS) is provided by browsing web page on the gateway computer too. However, these solutions haven't truly achieved the integration based on Internet. They integrate sub-systems based on LAN, only providing a remote access method, which provides a serial of Web pages which end-user can use to access the BAS by web browser over the Internet. They cannot realize communication among BASs distributed on Internet. It is an interactive interface to end-user, not an interactive way among BASs. It maybe more suitable to call them “user web-access” or Webenabled. In order to realize integration and interoperation among applications on Internet, XML and Web Services technology [16] is put forward by World Wide Web Consortium (W3C) [16] organization. As a new generation Internet communication technology, Web Services has its identity on BAS integration field. However, Web Services seems more suitable for management level and automation level, especially communication over the Internet, instead of field level since its complexity. Monitoring and controlling the field devices or BAS networks still need to resort to field bus communication protocols or communication software. How to combine Web Services and the BAS field bus networks/BAS software by middleware technologies is a problem not adequately addressed at the beginning of this research. There is a pressing need to develop a middleware solution to combine these technologies to realize the integration and interoperation of BASs on the Internet. This paper attempts to provide a solution, addressing two important issues as listed below: i. Integration and interoperation among heterogeneous BAS systems; ii. Integration of various BASs with enterprise applications on the Internet. Considering that most OS platforms of BASs are Windows platforms (which OPC bases on) and OPC has more application than other traditional middleware technologies, for example, RMI, CORBA, we present a solution — a middleware which is based on combining OPC and Web Services. The advantage of this combination is their mutual complement that OPC and Web Service have different characteristics and application environment. In Intranet, OPC configuration and security can be addressed relatively easily in comparison with the case on Internet. OPC can achieve better communication performance in Intranet compared with Web Service. OPC is a good and frequently-used choice in Intranet. The OPC interfaces for several mainstream protocols, including BACnet, Modbus and LonMark can be got easily from the automation industry [40]. However, when it is extended to Internet, Web Services can
114
S. Wang et al. / Automation in Construction 16 (2007) 112–121
provide better security and flexible integration compared with OPC. Therefore, it is a better way to combine OPC and Web Services when the TCP/IP-based control network is connected to Internet. This paper presents the development of a middleware framework using these most updated technologies, i.e., OPC, XML and Web Services to realize integration and interoperation of intelligent building system. This proposed middleware framework aims to realize information and services integration among BASs over the Internet, not just providing web pages for Internet user access which exists popularly at current. The framework design and implement of this middleware technology and its performance evaluation will be discussed. The paper is organized as follows. Section 1 is the introduction part. Section 2 introduces the issues and difficulties in current IB integration and existing works. Section 3 presents the framework of this middleware technology. Section 4 presents the implementation of the middleware technology. Section 5 presents the experiments results. The conclusions and discussions are presented in Section 6. 2. Background and related work We first present two issues, which have to be addressed on designing an integration middleware. The first issue is to realize communication among subsystems with different communication protocols and various BAS software systems in a distributive, flexible, scalable way. The protocol drivers or BAS software maybe are distributed on various computers which require the middleware to have distributed process capability. New sub-systems should be easy to add to this middleware system and therefore the system must be flexible and scalable. Traditional methods are either to resort to gateways or to install respective drivers on the central management host. The prior is not good as discussed above. The latter method will lead to too many drivers in one host and it is a centralized way and not easy to add new devices. The application of the OPC standard interface makes interoperability possible between various systems in the BAS management level. Traditionally, each software or application
developer was required to write a custom interface, or server/ driver, to exchange data with hardware field devices. OPC eliminates this requirement by defining a common interface that permits this work to be done once, and then easily reused by HMI (Human Machine Interface), SCADA (Supervisor Control and Data Acquisition), control and custom applications [29]. The integration implementation based on OPC is illustrated in Fig. 1. BAS 1 and BAS 2 software systems have provided the OPC server interface, so BAS station software and Web applications can communicate with them via the OPC interface. Another situation is that the OPC server driver is provided with a device. In this case it is easier for the devices being connected directly via OPC server driver. The OPC drivers and BAS software with OPC interface can be distributed on different computers, so it is a distributed system. New components/ devices with OPC interface/driver can be added with little difficulty for the unified interface. However, this implementation with OPC still has problems as discussed below. OPC uses COM/DCOM as the core technology for the software interface. Therefore, when an OPC client on a computer connects to an OPC server located on another computer, the DCOM security must be configured correctly. Many installers experienced this requirement as a problem. As a result, DCOM security is often disabled, leading to severe security risks. Obviously, it gets even more risky when using an OPC server over the Internet [18]. As OPC DCOM interaction over Internet will result in severe security problem, it is not practical to use it over the Internet. XML technology has been used to fill these gaps in a new development of OPC technology. The newest progress is the new OPC XML-DA standard. In this new standard, OPC allows manufacturers to process data which can be accessed via the Internet. In this case, the OPC server is configured as a Web service [19]. However, only OPC DA has been extended with XML capability, the remains of batch specifications of OPC have not been extended yet [10]. Another problem of using OPC DCOM servers is that they cannot be accessed from non-Windows system, OPC DCOM clients cannot communicate with non-Windows system. Therefore, they cannot be used on other platforms. So “bridge” or other software of this kind is needed when communicating between
Web Web Server Server
BAS Station
OPC Client Interface
OPC Client Interface
LAN BACnet OPC Driver
BACnet Devices
LonWorks OPC Driver
OPC Server Interface
OPC Server Interface
BAS1 Software
BAS2 Software
Control Net
Control Net
LonWorks Devices
BAS 1 Fig. 1. BAS integration via OPC.
BAS 2
S. Wang et al. / Automation in Construction 16 (2007) 112–121
various platforms. For tracking and monitoring software in BAS, it is important that all data are received by the application without interruption. When an application experiences a bad connection or even gets disconnected, OPC is not able to automatically try to reconnect [18].This problem of OPC in BAS applications needs to be addressed in the future development. The second issue is to realize powerful communication and integration capability on the Internet. At present, end-users need to access BAS remotely. However, the communication platform deals with various BASs exchange information and services on the Internet. Furthermore, the integrated BAS can even communicate with other Internet applications, i.e., providing remote monitoring and controlling to or getting data from other Internet applications. There is a trend to integrate BASs and other enterprise applications, e.g., MIS (Management Information System), ERP (Enterprise Resource Planning). To realize this aim, a promising technology in IB integration is XML and Web Services technology. Donlon M. claimed “Finally, using TCP/IP connections, protocols like XML will dominate the future of interoperability among embedded devices — even in building automation.” [20]. Craton and Robin appealed to construct information models based on Web Service [14]. They also claimed that “it might be possible to expose information as XML at a building-controller level, it would not be practical to do so at a zone or unitarycontroller level.” The Continental Automated Buildings Association (CABA) has formed a committee (CABA XML/Web Services Guideline Committee) which “will address the application of new communication standards for Web-based communications such as XML, SOAP and Web services within building control systems” [21], now this committee formed as a technical committee, namely, oBIX (OASIS Open Building Information eXchange Technical Committee), at the Organization for the Advancement of Structured Information Standards (OASIS) [39]. Using the Web Service technology, BAS systems from different vendors, even on different platforms can be integrated easily. Fig. 2 is a proposed approach, in which BASs and other applications communicate by Web Services in the future. As shown in Fig. 2, the Portal application can access different BASs via Web Services, the non-BAS systems can be easily integrated as well. For example, a weather bureau could offer a Web service that allows a building automation system to automatically retrieve temperature forecast data for use by various control algorithms. Similarly, the building automation system itself could offer a Web service that allows a tenant's accounting
BAS 1
Web Services
BAS 3
BAS 2
Integration Application Portal
Web Services
Weather Weather Report
Fig. 2. Integration of BAS systems using Web Services.
115
system to obtain up-to-the-minute figures on energy consumption [14]. However, since the SOAP request/response is enveloped in XML format, it will be too complex to be used in the communication of field level control in some situation and will increase the need to the processor power and additional response time. Therefore, it is not suitable for field level up to now since much traffic overhead [22]. With the development of microcomputer technologies and the usage of more and more powerful embedded systems in the market, Web Services may push its applications to field device level. Up to the beginning, practical research about Web Service application on IB is not sufficient, especially how Web Services combine with field level devices by middleware technologies and the communication performance is not addressed in detail. 3. The middleware framework There are several middleware technologies which can be used to integrate BASs, such as CORBA, JAVA/RMI, COM/ DCOM. However, OPC as a variant of DCOM was developed specially for automation applications from the original. Current mainstream BASs have provided OPC interface. On the other hand, Windows is also a popular platform. Therefore, we selected OPC as our BASs integration technology in LAN. 3.1. System model In order to validate this approach, we developed an integration and management platform based on the technology proposed in our laboratory. Fig. 3 shows the system model of the platform. In LAN, OPC is employed to integrate different BASs. Generally, an OPC interface can be provided by three ways in BAS. One way is through the OPC server interface provided by the third-parties BAS management software. The second way is the standalone OPC driver (server) related to the controllers. The third way is to transfer other protocols, such as DDE, to OPC. The OPC servers may be distributed on different computers. The OPC client components are responsible for communicating with OPC server. In this figure, the Building Management System (BMS) based on LAN is a full-functional BAS software of LAN version which provides building management functions on LAN mainly based on OPC technologies. It provides DCOM interfaces of real time data access and historical data access, too. This DCOM interfaces are wrapped as Web Services in another server which we call Web Services server for it provides public Web Services for Internet access. Users can easily develop their own applications so as to access the Web Services to supervise and control the BAS system via Internet. As an example, here we develop some web applications stored in one server to invoke Web Services, which we call “building management web server”. Users can manage, monitor and control the connected BASs by browsing the web pages. This is a multi-tier architecture, shown as Fig. 3. 3.2. Architecture and components Fig. 4 illustrates the software component architecture of the IB integration middleware. BMS (version LAN) functions as an
116
S. Wang et al. / Automation in Construction 16 (2007) 112–121
Convert Non-OPC Interface to OPC
LAN OPC driver for Controllers
BMS (LAN version) & BAS Functions Components
HMI Application
Control Net BAS Software 1 with Non-OPC Interface
DCOM Internet Internet
SOAP Internet Internet Control Net Building Management Web Server
Web Services Server BAS Software 2 with (Web Server+ Web OPC Interface Services)
Database
Control Net
Fig. 3. BAS integration combining the use of OPC and Web Services.
HMI front end while back end functions are achieved by BAS Functions Components. BAS Functions Components resort to OPC Client Components to communicate to various OPC servers, realizing real time data access, historical data access and alarms and events process functions. Afterwards these functions are wrapped as public Web Services methods. Here the Web Server deployed in Web Services server is not mainly for web page storage and access. Instead, it is used for http protocol parser since the transportation method for Web Services adopted
here is the http protocol. It is responsible for parsing the Web Service request from http messages and forward the request to the Web Service applications. The customer application, in this case the “building management web server”, invokes the Web Services public methods and provides web interface to users. BASs from different manufacturers and with various protocols are all connected by unified OPC interfaces using various ways, including the OPC server interface provided by the BAS software, the OPC driver coming with the devices or
Building Management Web Server
Web Services Server Web Server Web Services
BMS (LAN version)
COM/DCOM
COM/DCOM
BMS Functions Components
Historical Data Access
OPC Client Components OPC Data OPC Interface
Historical Data Third-party’s Software and System
OPC Data
OPC Data
OPC Driver
OPC Gateway
Other Interfaces Controllers
Fig. 4. IB Integration middleware based on OPC and Web Services technologies.
S. Wang et al. / Automation in Construction 16 (2007) 112–121
117
Management [5]. In implementing this middleware, real time data access is accomplished by OPC DA, historical data access by OPC HDA, alarms and events by OPC AE. Then these functions are wrapped as public Web Services for Internet communication and integration. Fig. 5 shows various interfaces connection and functions blocks in this middleware.
the OPC server interfaces conversed from other drivers or other interfaces. Usually the third-parties' BAS software provides, at least, one of the OPC interfaces, DDE interface or other COM/ DCOM interface, such as Honeywell EBI providing OPC Server interface, Cimetrics providing BACnet OPC Server interface, LonMaker providing DDE interface. Real time data from OPC Client Components can be recorded into a historical database. The historical database can be read by HDA client through OPC HDA server.
4.1. Functions realization The communication transportation of Web Services is based on http or other Internet protocol. This communication process belongs to the so-called “Pull” technology. That is, only the client can initiate the process to get information from the server, the server cannot send messages to the client automatically. In the BAS communications, most functions except the alarm and event function are those clients request data from servers (control and monitoring). In the services provided by the Web Services server, most of them can be realized by this “pull” means. The clients (i.e., “building management web server”) submit services requests to the Web Services server, the Server will execute the specific services and return the result to the clients. However, some functions need servers to send data automatically in case of certain events, such as Alarm/Event (A/E) and Change of Value (COV) event. When the events come out, client should be notified immediately if the client has subscribed them. One way is to refresh the web page quickly so as to keep updated, i.e., “pull” continuously, but this will result in serious network traffic problems.
4. Prototype implementation The middleware platform can be divided into several components, i.e., OPC Servers, Historical Database, BMS Function Components, BMS HMI (LAN version), Web Services server and “building management web server”. OPC Servers are distributed on various PCs in LAN. BMS Function Components executes the tasks of real time data access, alarms and events process, historical data access, scheduling, trending and provides COM/DCOM access interface. BMS HMI (LAN version) realizes the BAS functions in the LAN. Web Services server converts the COM/DCOM interfaces to Web Services interfaces. Kits of Active Service Pages (asp) and dynamic link library (.dll) files are deployed in “building management web server” to communicate with Web Services server and provide user access interface (web pages) to users. There are several important functions that should be implemented in BASs, such as real time Data-sharing, Alarm/ Event, Historical Data and Trending, Scheduling, Network
Building Management Web Server Web Service Methods
BMS HMI (Based on LAN)
Web Services Server
DCOM/COM Real Time Data Access Module
DCOM/COM
Historical Data Access Module
Event / Alarm Module
Schedule Module
BMS Functions Components
Unified OPC Interface (OPC Client Components) Historical Data
OPC Server Side
OPC HDA Server OPC DA/EA Server
OPC Server Driver
BACnet Driver
LonWorks Driver
BAS (OPC Interface) Devices
Other Interface
BAS (DDE Interface) BACnet Devices
Control Net
DDE Interface
BAS (Other Interface)
LonWorks Devices Control Net
Fig. 5. Prototype implementation.
Control Net
118
S. Wang et al. / Automation in Construction 16 (2007) 112–121
Can we make the Web Services server send out A/Es message to clients by Web Services method initially? “Reverse” Web Service can be used to realize the “Push” technology. Using this method, the “building management web server” is also configured as a Web Services provider, but its services only include the services to deal with A/E and COVevents. Because of this it might be called a mini-Web Services. Its operation process is illustrated in Fig. 6. Firstly, the “building management web server” subscribes the A/Es and COV events as client to Web Services server, the Web Services server will maintain a subscriber table, which contains the subscribers' IP and events subscribed. Then, when the events fire out and the Web Services server needs to send notifications to the “building management web server”, it sends a “reverse” Web Service Request to the “building management web server” to notify the events. The “building management web server” will analyze the event type and deal with it, then return an ACK (acknowledgement) Web Service message to the Web Services server. The advantage of this method is that it has no need to employ an additional communication means besides the existing Web Services technology. On the duration of this project, OPC foundation has published the newest OPC XML DA. OPC XML DA is Web services based. However other OPC specifications do not extend to XML yet. In OPC XML DA [35], “Server initiated callbacks are not possible; the client has always to poll the server for new data”. Therefore, we present this “reverse” Web Service technology to transfer Event/Alarm messages. This method is based on Web Services technologies, outside of the OPC XML DA framework. 4.2. HMI (front-end) realization Web browser is a user-friendly interface tool. By using the generally-used web browser, one can finish configuration, monitor status, control actuators, receive and acknowledge A/
Es, and view trend log of data points. These are mainly webpage authoring work. However, in order to achieve good performance and low traffic, two problems need to be considered: how and where to compose the web pages and how to update real time data and A/Es in a browser. The first problem is addressed in this study using the method shown in Fig. 7. The “building management web server” stores a bunch of web pages. When the web browser submits a request to the “building management web server”, the “building management web server” will process this request and send the request to invoke the Web Services in the Web Services server and then get the XML response from the Web service Server. The XML message includes BAS information which a user requests. In order to show this message to the users, the XML message should be transformed to html with an Extensible Style Sheet Language Transformations (XSLT) file as template. There are two methods to realize the transformation. One is to transform to a html file in the “building management web server”, then send the html file to the web browser. Another is to send XML and XSLT files to the web browser, then comprise the html file in browser. The latter is chosen for the middleware development in our study. In this case, the XML response returned from Web Services server is forwarded to a browser by the “building management web server”. This XML file will include a XSLT URL (Unified Resource Location), the browser will try to get XSLT file to compose the html file in the web browser. When the XSLT file was accessed before and not changed, the browser will use the XSLT file in cache. Because XSLT files do not change frequently, usually only the XML file needs to be updated. This will decrease the amount of traffic greatly as compared with the first method. The second problem addressed in this study is the use of the ActiveX control technology. In fact, there are two ways to keep the HMI data updated and A/Es notification as briefly below. Control Net
Web Browser BAS1 Software
Internet Internet
Reverse Request
Web Services Server1 Control Net
Internet Internet Building Management Web Server (+mini Web Services)
ACK Response
BAS2 Software Web Services Server Server2
Control Net Fig. 6. Alarm/Event transferred by Web Services.
S. Wang et al. / Automation in Construction 16 (2007) 112–121
Web Browser
Request
1
Building Management Web Server (+mini Web Services)
2
119
Web Services Server
SOAP Request XML Response Request XSLT file HTML
SOAP Response 3
XSLT file Fig. 7. The procedure of comprising web page in browser.
IFrame can be employed to restrict the range of refresh. For example, code bP ALIGN=centerNbIFRAME SRC=“foo.html” WIDTH=300 HEIGHT=100Nb/IFRAMENb/PN will restrain the content to foo.html in this Iframe. If foo.html includes an automatic refresh code, it will only refresh the Iframe and will not affect the contents outside of the Iframe.
The ActiveX control technology is selected due to lower traffic, which is an important concern for the application. i. ActiveX control or Applet technology: ActiveX control or Applet are applications embedded in web page, they can refresh themselves and “pull” data from the server periodically, or they can keep a connection and listen (as a server) to the messages coming from the server, such as an A/E message. ii. Browser refresh method: By adding the tag bMETA HTTP− EQUIV=REFRESH CONTENT=“time; URL=url”N in the web page, a browser refreshes the page according to the preset time. This tag also can be sent by ASP program from server, such as “Response.Write bMETA HTTP− EQUIV=REFRESH CONTENT=“time; URL=url”N”.
4.3. Interoperation among BASs Besides the integration, interoperation is another important problem for BASs. This middleware platform realizes the interoperation among various BASs integrated using two approaches for two applications cases as described below. The first case is the interoperation among BASs which are connected to a Web Services server. This interoperation is realized internally by the server using OPC communication, no SOAP communication involved. This can be done by conventional OPC method and therefore it is not presented here in detail. The second case is the interoperation among the BASs connected to different Web Services servers. In this case, the
ReFresh of full page will lead to traffic problems, especially when loading large-size pictures. In order to decrease traffic, one should limit the range of refresh, such as only refresh one ASP URL to finish the request. The web page technologies such as
1: DP1=ON Web Browser
2 Web Services Server1
Control Net BAS1 Software
Internet Internet Control Net
Building Manager Web Server (+mini Web Services)
4:DP2=? Control Net
3
BAS2 Software
Web Services Server2 Control Net
Fig. 8. Interoperation among different Web Services servers.
120
S. Wang et al. / Automation in Construction 16 (2007) 112–121
interoperation will take place among Web Services servers with “building management web server” as an agent as illustrated in Fig. 8. This procedure involves “reverse” Web Services described in Section 4. In Fig. 8, an interoperation example is given to illustrate this method. When DP1 changes to ON, the Web Services server 1 will notify “building management web server” this change by “reverse” Web Service method, then the “building management web server” will send the request to Web Services server 2 to operate as the interoperation table defined in “building management web server”. For engineers, besides the interoperation table, the definition job also includes the condition definition of event firing which is used to notify “building management web server” of the change of data. 5. Experiments and evaluation On the basis of the middleware framework, a software platform was developed, which integrated four BA systems from four different vendors in our IB Laboratory. Integration and interoperation of different vendors' systems are realized over campus network. Tests were conducted to verify and confirm the integration capability compatibility, interoperability, stability and flexibility of the middleware framework as well as the technologies associated. In particular, to verify the response speed of the middleware framework developed, experiments to test the performance this model were conducted. In those response speed experiments, we used a “round trip time testing client” in the “building management web server” to read an item in the OPC Server Simulator located in our IB Laboratory in Hong Kong. The OPC Server Simulator used is a free software package available on Internet [36], which comprises a serial of groups and items. In the first test, the “building management web server” was located in Mainland China (Shenzhen) connecting to the Internet via cable modem provided by public services provider. In the second test, “building management web server” was located in a building out of the university campus connected to the Internet via a public broadband service. The response speed of the middleware framework was compared also with that of the framework when replacing the Web Services method with another common and popular communication way, plain text on TCP on Internet. Therefore, in the experiments, from the OPC Server Simulator to Round Trip Time Testing Client, we implemented two communication ways: OPC with Web Services (SOAP messages) and OPC with plain text over TCP as illustrated in Fig. 9. In the experiments, SOAP is realized based on Microsoft SOAPSDK 3.0 and IIS 5.0. Round Trip Time OPC-Web Testing Client Services Server SOAP Messages Internet Internet Building Management Web Server
OPC Sever Simulator
IIS Server LAN
Fig. 9. Illustration of experiment setup.
Table 1 A comparison of round trip time of middleware developed over Internet
Between Mainland China and Hong Kong Within Hong Kong Within campus network XML-DA to OPC DA server (between Europe and US) [35]
Average of first accesses (ms)
Average of consecutive accesses (ms)
6122
673.3
1612 737.5 1200
300.5 218.3
The values of the round trip time measurements are presented in Table 1. Examining the data listed in the table, the round trip time of access from Mainland China was 6.85 and 0.71 s, respectively, for the first and consecutive communications. The round trip time of access between the middleware framework and the remote client in Hong Kong was 1.612 and 0.301 s, respectively, for the first and successive communications. The round trip time of access between the middleware framework and the client within the university campus network was 0.738 and 0.218 s, respectively, for the first and successive communications. It can be observed that the first communication took more time and the consecutive round trip time of Web Service was significantly less. Response speed of the remote access within Hong Kong was noticeably slower than that of the access within the campus network, but the difference is not significant. The response speed of the remote access between Mainland China and Hong Kong was significantly slower. In fact, it is generally believed that the efficiency of the Internet connection between Mainland China and Hong Kong is rather low. The efficiency of the Internet connection between USA/ Europe and Hong Kong could be much better. Nevertheless, the test results show that the response speed of the developed middleware framework based on Web Services is satisfactory for BAS applications for both remote applications within a city and between different countries. These results can also be compared with the round trip time of the Internet access from client in USA to server in Europe using XML-DA Gateway to OPC DA Server, which belongs to OPC XML-DA as described in Section 2. The reported round trip time was 1.2 s [35]. Therefore, the response speed of the middleware framework developed in this study is noticeably faster than that from the available benchmark besides its benefits in BAS applications as described in Section 2. 6. Conclusion and discussion The middleware presented in this paper employs standard communication protocol and technologies, namely, OPC and Web Services, realizes data and services integration and interoperation among distributed BASs on Intranet/Internet. The middleware technology utilizes the flexibility and universality of the OPC interface to implement the integration and interoperation of BASs in LAN. In the meantime, it avoids the security risk of deploying OPC on the Internet directly. In the middleware, various communication interfaces are accommodated and
S. Wang et al. / Automation in Construction 16 (2007) 112–121
conversed into the unified interface, i.e., OPC interface. With the help of the powerful communication capability of Web Services on a heterogeneous platform and the Internet, the middleware technology becomes a seamless integration platform on the Internet. The combination of OPC and Web Services fills the gap of BAS control network and data communication network. The Web Services methods provided by the Web Services server in this middleware can be invoked by other related facility management applications as well. For example, FDD (Fault Diagnosis Detect) applications can read real time data from the BASs and historical data from Historical Database from the Web Services server by web methods. In application, the middleware might be used to integrate other services or to be integrated by other services on the Internet, such as a weather report service. A HVAC system can optimize its control according to the data obtained from the web services of the Bureau of Weather. Maintenance application can read specification data and manual of devices from manufacturers. By the same way, ERP application can get enterprise energy consumption. It is needed to implement and test the load-balancing and antifailure scheme for the middleware in a real wide-area environment before practical applications can be put into operation. For example, load should be moved possibly from one Web Services server to another to keep load-balancing among various servers, when some servers are heavily loaded or not working properly. Measurements of load will be defined to provide an assessment for the load-balancing schemes. Load distribution strategy will be determined according to the measurements. If faster communication service is required by data points, a load measurement that puts higher weight on communication bandwidth will be selected. Thus, a Web Services server with greater communication bandwidth can be selected to connect to the data points. Acknowledgements The research presented in this paper was financially supported by a grant of the Research Grants Council (RGC) of the Hong Kong SAR and a research grant of The Hong Kong Polytechnic University. References [1] D.M. Fisher, BACnet and LonWorks: A White Paper, July 1996, http:// www.bacnet.org/. [2] S.W. Wang, J.L. Xie, Integrating building management system and facility management on internet, Automation in Construction 11 (6) (2002) 707–715. [3] S.W. Wang, Z.Y. Xu, H. Li, W.Z. Shi, Investigation on intelligent building standard communication protocols and application of IT technologies, Automation in Construction 13 (5) (2004) 607–619. [4] S.T. Bushby, Communication gateways: friend or foe? ASHRAE Journal 40 (4) (April 1998) 50–53. [5] ANSI/ASHRAE Standard 135-2001: BACnet® — a data communication protocol for building automation and control networks, Atlanta, Georgia: American Society of Heating Refrigerating, and Air-Conditioning Engineers, 2001. [6] ASHRAE SSPC 135, http://www.bacnet.org/ as viewed on October 10, 2004.
121
[7] EIA Standard “Control network protocol specification” EIA/CEA-709.1-B (Revision of EIA-709.1-A), Jan., 2002. [10] The OPC Foundation, http://www.opcfoundation.org/ as viewed on October 10, 2004. [11] Object Management Group, http://www.omg.org/ as viewed on October 10, 2004. [12] RMI Specification, http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/ rmiTOC.html as viewed on October 10, 2004. [13] John Controls, Inc., “Product Information”, http://cgproducts.johnsoncontrols. com/tree.asp as viewed on October 10, 2004. [14] E. Craton, D. Robin, Information Model: The Key to Integration, Jan. 2002 http://www.AutomatedBuildings.com. [15] Ehrlich P. “Guideline for XML/Web Services for building control”, BuilConn 2003, Dallas, April, 2003. [16] The World Wide Web Consortium, http://www.w3.org/ as viewed on October 10, 2004. [18] E. Claus, Synchronic Extending Interoperability and Connectivity, http:// www.AutomatedBuildings.com, March 2002. [19] G. Baumann, M. Damm, Industrial communication system — independent and flexible, PRAXIS Profiline-OPC, vol. 1, Vogel Verlag, Wuerzburg, Jan. 2003, pp. 43–46, http://www.is.siemens.de/data/presse/docs/ isfb01033112e.pdf. [20] M. Donlon, Standard internet protocols in building automation, Engineered Systems 19 (2) (Feb. 2002) 61–68. [21] The Continental Automated Buildings Association (CABA), CABA XML/ Web Services Guideline Committee States Mission and Objectives, July 15 2003, http://www.caba.org. [22] International Business Machines Corporation, http://www-128.ibm.com/ developerworks/library/x-jaxmsoap/index.html as viewed on October 10, 2004. [29] FieldServer Technologies, http://www.ahrexpo.com/showpreview/ buildingautomationcontrol.php, February 7–9, 2005. [30] Frost, Sullivan, North American Building Automation Protocol Analysis, Frost and Sullivan Report A143-19, May 2002. [31] Microsoft Corporation, “Understanding the Distributed Object Component Model (DCOM) Architecture”, http://www.microsoft.com/ntserver/techresources/appserv/COM/DCOM/1_Introduction.asp as viewed on October 10, 2004. [32] N. Lu, J. Liang, J. Y. You, Dept. of Computer Sci. and Eng. Shanghai Jiaotong Univ., “Design and implementation of building intelligent management system”, Journal of Shanghai Jiaotong University, July, 2000. [33] H. Guo (Fuzhou University); R. Chen, L.M. Hu, “Research on integrated model based on XML, CORBA and agent”, Proceedings of the International Conference on Computer Supported Cooperative Work in Design, pp. 344–348, July, 2001. [34] Y. Wang, Z.Y. Wang, Design and implementation of intelligent building management system (IBMS) based on CORBA, Computer and Digital Engineering 29 (2) (2001) 16–22. [35] Technosoftware Inc., XMLDA.NET White Paper, http://www.technosoftware. com/driver.aspx?Topic=WhitePaperXMLDANET as viewed on October 10, 2004. [36] ICONICS, Inc. ICONICS OPC Server Simulator, http://www.iconics.com/ as viewed on October 10, 2004. [37] The Cover Pages Web Site, “ASHRAE Releases BACnet Web Services Interface Specification for Public Review“, http://xml.coverpages.org/ ni2004-10-22-a.html, October 22, 2004. [38] Echelon Corporation, “i.LON 100 Internet Server User's Guide”, https:// www.echelon.com/support/documentation/manuals/078-0287-01A.pdf as viewed on October 10, 2004. [39] OASIS Open Building Information eXchange Technical Committee, “History of oBix”, http://www.obix.org/ as viewed on October 10, 2004. [40] The OPC Foundation, “Product Vendor List”, http://www.opcfoundation. org/Products/Products.aspx?STX=Category%3aServer%23 as viewed on October 10, 2004.
