Investigation on intelligent building standard ... - Semantic Scholar

Automation in Construction 13 (2004) 607 – 619 www.elsevier.com/locate/autcon

Investigation on intelligent building standard communication protocols and application of IT technologies Shengwei Wang a,*, Zhengyuan Xu a, Heng Li b, Ju Hong b, Wen-zhong Shi c a

Department of Building Services Engineering, The Hong Kong Polytechnic University, Kowloon, Hong Kong b Department of Building and Real Estate, The Hong Kong Polytechnic University, Kowloon, Hong Kong c Department of Land Surveying and Geo-Informatics, The Hong Kong Polytechnic University, Kowloon, Hong Kong

Abstract This paper investigates the frustrating problems of integration and interoperability of Building Automation and Control System (BACS) and presents two possible solutions on the basis of the hierarchy architecture of BACS. One is to employ a unified protocol for the three levels of the BACS networks. The other is the integration at management level. For the first solution, as one candidate, BACnet and its relation with other protocols are evaluated. For the second solution, pros and cons of OPC and Web Services are analyzed and compared. The combination of these two technologies offers good prospects for this solution. A survey on the development of Intelligent Building (IB), the application of IB technologies and the IB standards in China is presented also. D 2004 Elsevier B.V. All rights reserved. Keywords: Building automation system; Intelligent building; Local area network; Protocol; Interoperability; Integration; OPC; Web Services; BACnet; Standard protocol

1. Introduction Over the last two decades, incompatibilities and limited opportunities for the integration of building automation and control systems among products of different vendors have frustrated real estate developers, building owners/operators, consultants, system integrators [1]. Although great progress has been made on the interoperability of Building Automation and Control System (BACS), proprietary protocols still dominate the current BACS market even today [2]. In a typical BACS, different communication protocols

* Corresponding author. Tel.: +852-2766-5858; fax: +8522765-7198. E-mail address: [email protected] (S. Wang). 0926-5805/$ - see front matter D 2004 Elsevier B.V. All rights reserved. doi:10.1016/j.autcon.2004.04.008

are usually employed, even among the products of one company. A popular way to integrate the products of various protocols is to employ gateway [3], which has the role of converting a protocol to another protocol, mapping data points from one protocol to another protocol. But the development of gateway requires significant effort, the developer need to have the technical details of two protocols and understand them as well. One needs a lot of configuration effort to make the gateway 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]. As a practical example, a comprehensive Intelligent Building (IB) system was developed recently in our university teaching laboratory facility. Fig. 1

608

S. Wang et al. / Automation in Construction 13 (2004) 607–619

illustrates the configuration of the system, which includes building automation system (HVAC control), fire security system, security and access control, lighting control and power monitoring. In this system, all sub-systems are integrated into a single Ethernet backbone. Users can supervise and monitor the entire IB system via the management software. Interoperation over different sub-systems could be achieved. Such as the HVAC system will stop and the relevant image of the space can pop-up when a fire alarm arises. Lighting is turned on automatically when an authorized person intends to enter the laboratory identified by the access control panel. The digital CCTV camera can be turned to monitor the delegated locations and start to record the event when a person intends to access the laboratory or if the door is open. The intelligent functions and convenience provided by the integration of the IB sub-systems are amazing. However, every sub-system has different protocols in this IB system. Gateways are needed to realize the conversion of protocols to achieve the total integration of the sub-systems. The management software communicates with sub-systems via relevant drivers. If interoperation among sub-systems is needed, the management software plays the role of ‘‘agent’’. This interoperation is a vendor’s proprietary method only, not a standard method. It is not flexible and much difficulty will be faced if a new third-party sub-system is to be added to the system. Nowadays, the rapid development of information technologies (IT) offers new possible methods and

solutions to overcome these difficulties. To have a more clear understanding of the problem, the hierarchy model of BACS network is used as a reference. BACS network can be divided into three levels management level, automation level and field level [5]. Different functions are needed at different levels. Integration and interoperability can be addressed at different levels. One can achieve integration and interoperation at all three levels starting from the bottom (field level) or achieve integration and interoperation at a high level. This provides us two possible ways to solve the problems in interoperation and integration. One is to employ the same communication protocol in all the three levels. ISO and CEN have been paying efforts on this work. They are trying to make a unified protocol (i.e. prEN ISO 16484-5) from field level to management level to increase the interoperation of BACS [5]. The prEN ISO 16484-5 basically refers to BACnet-A Data Communication Protocol for Building Automation and Control Networks presented by the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) [6,7]. However, with a view to the current status that different protocols are in use nowadays and the need for integrating BACS and other business system such as Management Information System (MIS) and Enterprise Resource Planning (ERP) [8], another way is to employ standard protocols at the upper level (e.g. management level) to avoid handling the difference of the lower level protocols directly. For example, OPC [9] and some emerging IT technologies (e.g. XML,

Fig. 1. An integrated Intelligent Building system.


SOAP and Web Services [10], etc.) can be employed to solve the problem. This paper presents the survey and analysis on the standard technologies used to integrate and interoperate from different levels, discusses and compares the advantages and disadvantages of different methods, aiming at giving a better solution. The (BACS) LAN protocols are reviewed and evaluated with focus on the main features of the communication protocolBACnet. The methods and technologies for the integration at the management level are investigated by comparing two different technologies for the integration at this level, analyzing the pros and cons of OPC and Web Services. A survey on the progress and the current status of IB technologies and IB market in China is presented and the development of Chinese IB standards is addressed.

2. LAN protocol standards and BACnet There are a few potential candidates likely to be the future unified BACS communication protocols for all the three levels, such as BACnet, European Installation Bus Object Interface Specification (EIB-ObIS), LonTalk plus LonMark. They are all object-oriented protocols or have extension of object-oriented technology [11]. In this session, the issues related to protocol standards are elaborated by addressing mainly BACnet and the relation and comparison of BACnet with other protocols. BACnet is developed under the auspices of the ASHRAE [7]. It is an American national standard, a European pre-standard, an ISO global standard and the national standard of some Asian countries (e.g. Japan and South Korea). The protocol is supported and maintained by ASHRAE Standing Standard Project Committee 135. It is the only open protocol that was designed for building automation from the ground up, is the only open protocol that supports high-end functions like scheduling, alarming, and trending. 2.1. BACnet protocol architecture As many other communication protocols, the BACnet employs the OSI model as its reference model. The Open System Interconnection (OSI)-Basic Reference Model (ISO 7498) is an international standard that

609

defines a model for developing multi-vendor computer communication protocol standards. The OSI model addresses the general problem of computer-to-computer communication and breaks this very complex problem into seven smaller, more manageable subproblems, each of which concerns itself with a specific communication function. Each of these sub-problems forms a ‘‘layer’’ in the protocol architecture [6]. However, the OSI model is just a considerate reference model, but never demands to realize all the layers. BACnet actually implements a collapsed architecture (Fig. 2). Only selected layers of the OSI model are adopted by BACnet to reduce message length and communication processing overhead. Such a collapsed architecture permits the building automation industry to take advantage of lower cost, mass-produced processor. As shown in Fig. 2, BACnet has only four layers, a collapse of the seven-layer architecture. In fact, it requires more system resource and more cost to implement all the seven layers in practice. It is also not always a good choice to implement all the layers. Therefore, many protocols do not implement all the layers, such as the popular TCP/IP (Internet). In the building automation and many other control industries, it is not needed to implement all the seven layers. The four-layer collapsed architecture was chosen after careful consideration of the particular features and requirements of BACS networks, including a constraint that protocol overhead needed to be as small as possible. The use of readily available, widespread technologies, such as Ethernet, ARCnet, and LonTalk, will lower the cost, increase the performance, and open new doors to system integration [6]. 2.2. Can BACnet device interoperate LonWorks device? One might think that BACnet devices should be able to interoperate with LonWorks devices as BACnet has included LonTalk. It is not right in reality. BACnet adopts the subnet of LonTalk only, not all layers. Only the LonTalk Physical Layer and LonTalk Data Link Layer are adopted as one option of its five alternative transportation technologies. The other layers of BACnet and LonWorks are completely different. Therefore, BACnet devices and LonWorks devices are not interoperable.

610


Fig. 2. BACnet collapsed architecture.

The explanation is not difficult to understand. BACnet only adopts LonTalk Physical Layer and Data Link Layer as its transportation mechanism; the upper layers are completely different. Similar to the case that letters of different languages are put into ‘‘envelops’’, envelops can be the same but the letters are written in different languages (Fig. 3). Only BACnet devices can

Fig. 3. BACnet transportation on LonTalk.

read BACnet messages. Similarly, only LonWorks devices can read LonWorks messages [12]. 2.3. Object functions of BACnet BACnet, LonMark Functional Profiles and European Installation Bus Object Interface Specification (EIB-ObIS) are object-orient communication protocols [11]. They provide a serial of objects. ‘‘Objectorient’’ is one of the important features of BACnet. BACnet defines standard object types that represent the commonly used objects found in many automation systems available in the market. BACnet objects are collections of properties each representing some piece of information or parameter. BACnet defines not only what the properties of standard objects are, but also what types of behavior are to be expected from each property [1]. In LonMark, ‘‘a functional profile defines a template for a functional block. Each functional profile consists of a profile description and a specified set of network variables and configuration properties designed to perform a single function on a device. A functional block is an implementation of a functional profile. A standard functional block is also known as a LonMark object. A standard or user functional block is also known as an object’’ [13].


Table 1 presents a comparison between the standard object functions provided by BACnet and LonMark [5]. Both have realized a series of standard objects, especially BACnet, has included some highend functions, such as scheduling, alarm management, trend, etc. LonMark seems to solve interoperability at the component level. BACnet addresses interoperability at a controller level, which concerns a larger scope where most interoperability is between controllers and higher level devices. Another goal of BACnet is extensibility, including connection with other protocols. EIBA has been assigned a unique BACnet vendor ID (74, decimal) by the ASHRAE organization. This vendor ID must be used for the mappings of EIB applications to BACnet. The document ISO/TC205WG3 BACnet draft addendum H.5 describes how EIB Functional Blocks, which are part of Object Interface Specifications (ObIS) of the Interworking Model defined by the EIB Association (EIBA), are mapped to the corresponding Building Automation and Control networks (BACnet) object model [14]. 2.4. Interoperability of BACnet The BACnet approach to realize interoperation is a very general purpose and therefore a broadly applicable interoperability [15]. To make sure the interoperability of BACnet devices, five ‘‘interoperability areas’’ (IAs) are defined, i.e. data sharing, alarm and event management, scheduling, trending, and device and network management. Each IA is a group of related functions that define what represents the core

Table 1 BACnet/LonMark object functions

611

of interoperability. BACnet Interoperability Building Blocks (BIBBs) are defined as collections of one or more BACnet services. These are prescribed in terms of an ‘‘A’’ and a ‘‘B’’ device. Both of these devices are nodes on a BACnet internetwork. In most cases, the ‘‘A’’ device will act as the user of data (client), and the ‘‘B’’ device will be the provider of this data (server) [6]. BACnet defines standardized BACnet devices: BACnet Operator Workstation (B-OWS), BACnet Building Controller (B-BC), BACnet Advanced Application Controller (B-AAC), BACnet ApplicationSpecific Controller (B-ASC), BACnet Smart Actuator (B-SA) and BACnet Smart Sensor (B-SS). The listing of BACnet capabilities for each of these ‘‘standard BACnet devices’’ is called a ‘‘device profile.’’ The profile indicates which BIBBs must be supported by each device type for each interoperability area [6]. This is really different from approach of LonWorks towards interoperability. LonWorks controllers that make use of LonWorks can communicate with each other through what LonWorks calls ‘‘Standard Network Variable Types’’ or SNVTs (pronounced ‘‘snivets’’). The SNVT method is a different approach to defining data objects that requires a detailed knowledge on the part of the sender and receiver of what the structure of each SNVT is. SNVTs are identified by a code number that the receiving controller can use to determine how to interpret the information presented in each SNVT. LonWorks does not define what a particular SNVT code represents. It is possible, and regrettably commonplace, for LonWorks systems from different vendors to use the same SNVT code to mean different things. To solve this problem, the LonMark Consortium was formed with the intention to agree upon some rules for how LonWorks should be used, and to agree on a common set of SNVT codes and their associated meanings. The documents that they have produced are also commonly referred as LonMark. Controllers compliant to LonMark can be made to interoperate with each other [1]. 2.5. IP compatibility of BACnet BACnet devices are easy to connect to Intranet or Internet. They have various choices of devices, i.e.

612


BACnet router, BBMD, BACnet PAD, even BACnet device themselves (native Ethernet 8802-3 devices, native BACnet/IP devices). There are two kinds of technologies for BACnet to realize an IP connection. One is BACnet/IP PacketAssembler-Disassembler (PAD) router technology which specified in Annex H.3 [6] of ANSI/ASHRAE Standard 135-2001. PAD router is placed on every BACnet network that is to be connected over an IP network to another BACnet network. When it receives a BACnet message for a device on another BACnet network which is reachable only through an IP internetwork, it puts the BACnet message into a UDP/IP message with the IP address of the PAD device on the destination BACnet network and sends the message over the IP network. The receiving PAD removes the BACnet message and transmits the message on the local network. Since the PAD sends the message directly to a known IP of another PAD, this requires that the PAD maintains a table of its peer PAD devices [16]. Unfortunately tunnel routers have several significant configuration issues and require a lot of expert manual configuration (maintaining the tables) to work correctly. Another problem is the addition of a single BACnet device to a BACnet system via an IP internetwork would require either that the device itself pro-

vides the PAD service or the addition of another device that provides the PAD service. This would significantly increase the cost [16]. BACnet has improved significantly overcoming these limitations by adopting the second technology for BACnet to realize an IP connection, i.e. BACnet/ IP defined in Annex J [6] of ANSI/ASHRAE Standard 135-2001. Basically, BACnet/IP devices communicate using IP messages in lieu of BACnet messages, allowing the devices to be easily added to any IP internetwork [16]. This is implemented by defining a new protocol layer called the ‘‘BACnet Virtual Link Layer’’ or BVLL. Broadcast management is accomplished by defining the capabilities of a new device called a BACnet Broadcast Management Device (BBMD). Alternatively, IP multicast may be used. This method allows devices to enter the system from anywhere in the IP internetwork. It supports ‘‘native IP’’ BACnet devices such as unitary controllers which send and receive BACnet messages within IP frames. Therefore, BACnet devices effectively use IP internetworks as BACnet local area networks (LANs) [16]. Fig. 4 shows the connection between BACnet and Internet and how to access BACnet devices by browser [17].

Fig. 4. Connection between the BACnet and the Internet.


2.6. International standardization of BACS Up to now, BACnet is an American national standard, an ISO global standard, and a European pre-standard as well as a national standard in Japanese and Korean. There is a unanimous positive output from CEN/TC247 balloting adopting prEN ISO 16484-5 (BACnet 2001) as BACS standard that ran in parallel with the ISO enquiry. So the way is now clear for BACnet to be recognized as an official European Norm (EN) [7]. EIB Functional Blocks have a mapping to BACnet object. The document ISO/TC205 WG3 BACnet draft addendum H.5 describes how EIB Functional Blocks are mapped to the corresponding BACnet object model is in public review [7]. LonTalk is the standard of ANSI/EIA709.1-A-1999.1 as the standard of consumer electronics [18], CEN pre-standard for BACS. 2.7. Application of BACnet and other protocols BACnet, with its focus on efficiently transmitting data over high-speed local and wide area networks, functions well at passing large blocks of data. The system can efficiently handle centralized control functions in large buildings or in multiple buildings. LonTalk, with its focus on the individual devices connected to the system, is an efficient system that provides a relatively easy way to implement communications between controllers and devices [19], is suitable for home automation, component-level (field control) control of BACS. Although BACnet has many features to be suitable to BACS, but due to lack of developing tools and effective promotion in the market, there are not as many products available as LonWorks products in the BCAS market. Up to now, no BACnet product has yet been produced in China. On the contrary, LonWorks development tools and products are widely available. In addition, the LonTalk protocol has been effectively implemented in firmware. This makes it a more popular application in China as it provides the platform and tool for new BACS manufacturers to enter the market quickly. In fact, there are many third parties manufacturing Lon-based products in China.

613

3. Standard protocols and IT technologies for integration at management level The integration at management level is basically the communication of applications [14]. Many technologies can be used for that. A majority of products have adopted proprietary communication protocols while Microsoft DDE technology was used to achieve the communication between different software. However, due to the poor performance of DDE, this technology has been phased out. Various communication technologies have been developed to achieve convenient communication among applications, such as RMI, COM/DCOM, CORBA and Web Services. These IT technologies [14] have great influence and are adopted to BACS field, such as OLE for Process Control (OPC), the Web Services technology. The integration technologies at management level can not only allow the integration of different BACSs, but also allow the integration of BACS and other enterprise applications (e.g. ERP). 3.1. OPC technology Based on Microsoft’s OLE, Component Object Model (COM) and Distributed Component Object Model (DCOM) technologies, OPC consists of standard interfaces, properties and methods for the use in process control and manufacturing-automation applications. One of the valuable features of OPC is that it provides a common interface for communicating with diverse process control devices, regardless of the controlling software or protocols used in the process. Before OPC became available, application developers had to create specific communications drivers for each control system with which they wanted to connect. With OPC, application vendors no longer need separate drivers for each new processor or protocol. Instead, the manufacturers create a single optimized OPC driver for their product [20], as illustrated in Fig. 5 [21]. OPC can play an essential role in the integration of different vendors’ BA systems or devices. For example, in Fig. 6, BACS 1 and BACS 2 software has provided the OPC server interface, so Intelligent Building Management System (IBMS) station software and Web applications can communicate with

614


Fig. 5. Communication of automation systems using OPC.

them via OPC interface. It is easier if the OPC server driver is provided by a device, the device can be connected directly via OPC server driver. However, OPC still has problems to solve as discussed below. As discussed earlier, OPC uses COM and DCOM as the core technology for the software interface. Therefore, when one uses an OPC server located on a machine different from yours, he must configure the DCOM security. Many installers experienced this as a problem particularly on Windows 95 and Windows 98

machines as there is a security infrastructure in these versions of Windows, different from Windows NT/ 2000/XP. As a result, DCOM security is often disabled, which leads to severe security risks. It gets even more risky to use an OPC server over the Internet [20]. As OPC DCOM interaction over the Internet will result in severe security problem, it is not practical to be used. However, XML technology can be used to fulfill these gaps. It is overcome by the new OPC XML-DA standard. In the new standard, OPC allows manufacturing and process data to be accessed via the

Fig. 6. BACS devices/systems integration via OPC.


Fig. 7. Integration among different platforms.

Internet for the first time. In this case, the OPC server is configured as a Web service [22]. 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. For the tracking and other monitoring software in BACS, 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 cannot automatically try to reconnect [20]. It is another problem of OPC in BACS applications which needs to be addressed in further development. 3.2. Web Service technology Web Service is a new and powerful model for creating applications from reusable software models supported on the Internet or control networks using HTTP technology, which provides loosely coupled, flexible, and dynamic solutions by using emerging techniques as SOAP, WSDL and UDDI. These technologies are designed on the basis of existing Web technologies. Web Services are self-contained, selfdescribing, modular applications that can be published, located, and invoked across the Web [23]. The core technologies of the Web Service are listed below: (i) XML. XML was developed first. Web Service was developed on the basis of XML. All Web Service definition and messages are in the form of XML.

615

(ii) Universal Description, Discovery and Integration (UDDI). UDDI provides the protocol to register and find a Web Service in a public UDDI directory. (iii) Web Service Definition Language (WSDL). WSDL is an XML Document Type Definition (DTD) that defines standard format of describing a Web Service. Documenting a Web Service in WSDL provides a big room for future automatic client site Web Service stub generation or using GUI application to configure/plugin Web Service. (iv) Simple Object Access Protocol (SOAP). SOAP is also an XML DTD that defines how a message will be sent across the wire. As long as you sent a service request in SOAP, no matter how the Web Service is constructed, it will serve you [24]. SOAP offers vendor, platform and language independence. With SOAP, developers can easily bridge applications written with COM, CORBA or Enterprise JavaBeans. Fig. 7 [25] shows integration among different platforms. Web Service adopts common Internet protocols (HTTP, HTTPS, SMTP. . .) as its basic communication framework. These protocols ports usually are open by firewall, so Web Services are Internet-friendly. Using the Web Service technology, BACS systems from different vendors, even on different platforms can be integrated easily, as illustrated in Fig. 8. As shown in the figure, the Portal application can access different BACS via Web Services and the nonBACS systems can be easy to be integrated as well. For example, a weather bureau could offer a Web

Fig. 8. BACS systems integration using Web Services.

616


Fig. 9. BACS integration combining the use of OPC and Web Services.

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 system to obtain up-to-the-minute figures on energy consumption [11]. However, since the SOAP request/response is enveloped in XML format, it will be too complex

for the control communication in some situations and will increase the need for processor power and additional response time. 3.3. Discussion On Intranet, OPC configuration and security can be addressed relatively easily in comparison with the case on the Internet. OPC can achieve better commu-

Fig. 10. IB Integration middleware based on OPC and Web Services technologies.


617

nication performance on Intranet compared with Web Service. Therefore, OPC is a better choice on Intranet. However, when it is extended to Internet, Web Services can provide better security and integration performance compared with OPC. In conclusion, the best way is to combine OPC and Web Services in application when the TCP/IP-based control network is connected to the Internet. Fig. 9 shows a schematic of an IB system integration and management tool developed in our IB laboratory. OPC is employed in the TCP/IP network, integrating the control networks at a lower level. The OPC client components are wrapped to the campus network (or public) as Web Services. Users can access the Web Services to supervise and control the BACS system via campus Intranet/Internet. Fig. 10 illustrates the IB integration middleware architecture of the tool based on OPC and Web Services technologies to realize the integration and interoperability among BACS systems.

cost of RMB 1.6 billion (1 USD=8.2 RMB). Its investment on IB system accounts for RMB 100 million [26]. Table 2 shows a summary of the investment on real estate development in Mainland China in the period between 1997 and 2001, according to the data from the China National Statistical Bureau. The investment on real estate property development is up to RMB 2,204.222 billion in that period and was being accelerated in these 5 years. Assuming that one-fourth of the developments were equipped with BACS/IB systems spending 6% of total investment on the BACS/ IB systems in average, the total investment on BACS/ IB reached RMB 33 billion in these 5 years. After China joined the WTO, the internationalization process makes her have higher requirement on intelligent building, not only for newly constructed buildings but also for the renovation of existing buildings. From this, it is obvious that there is great potential for the development of Intelligent Buildings in China [27].

4. Development of intelligent buildings in China

4.2. Applications of BACS protocols and IT technologies

4.1. Current status Intelligent Buildings, as a concept, attracted the attention of the industry and public in China in 1990. Since then, it is being quickly developed all over the country. The building ‘‘Beijing Development Building’’ might be the first building to be considered as an intelligent building in China. After that, a number of intelligent buildings using more technologies were constructed, such as Shanghai Jinmao Building (88F), Shenzhen Diwang Building (81F), Guangzhou Zhongxin Building (80F), Nanjing Jinying International Commercial Building (58F). According to some statistics of not very high accuracy, over 2000 so-called intelligent buildings will have been constructed by the end of 2002. These buildings were normally high-class commercial buildings which were designed, constructed and managed using the same requirement for services used in developed countries. Nowadays, there is a trend wherein the intelligent building is changing its market to large public buildings, such as exhibition centers, libraries, stadiums, culture and art centers, museums, etc. For example, the ‘‘Shenzhen Library and Art Center’’ was built at a

BACnet has been promoted successfully in certain circumstances in China. The Chinese version of BACnet was released in November, 2000. A number of wellknown BACnet vendors have set up their branches in China. A few companies in China are developing BACnet products. ‘‘BACnet in China’’ mailing list (http://groups.yahoo.com/group/BACnet/) has been set up in 2001 with over 100 subscribers today. Some large real estate developments have deployed BACnetcompliant products, such as the ‘‘Shanghai Science and Technology Museum’’, which is the largest scientific and technical museum in Asia. It uses BACnet to integrate over 3200 control points and 1000 monitoring Table 2 Real estate investment (100 million RMB) in Mainland China between 1997 and 2001 Year

Resident building

Office building

Commercial building

Others

Total

1997 1998 1999 2000 2001

1539.38 2081.56 2368.48 3318.74 4278.74

388.98 433.80 338.60 292.57 318.00

425.85 475.83 484.33 547.75 720.80

824.16 623.04 641.79 742.68 927.94

3178.37 3614.23 4103.20 4901.74 6244.68

618


points into a single Web-Accessible controls system. AHUs, chillers, pumps, lighting, elevators, fire, security, and other building systems supplied by nine different vendors are monitored and controlled by a unified operator interface [28]. At the same time, other protocols such as LonWorks have also been widely used. Using the Neuron chips located in LonWorks devices, they allow manufacturers to enter the BACS production market easily. It is probably why LonWorks products now have a significant market share in China. A few universities and enterprises are developing Building Management Systems based on OPC and Web Services technology, such as The Hong Kong Polytechnic University. There are a few software providing OPC interface. Some products have been used in actual real estate development projects. The research on Web Services hasn’t entered commercial application, but is keeping up with international development. 4.3. National and regional standards and regulations on intelligent building In the early phase of development, research on intelligent building standards has only just started, with a lack of openness and unity. These directly impacted the healthy development of the market. In 1995, the Communication Engineering Committee of the Chinese Construction Standard Association issued a ‘‘Design Guide on Construction and Structure Cabling’’. Due to the lack of national standards, some regional authorities issued local standards, such as ‘‘Shanghai Intelligent Building Design Standard’’ (DBJ08-47-95) in 1995, ‘‘Jiangsu Building Automated Design Standard’’ (DB32/181—1998) in 1998. These regional standards provide the guide for the plan, design and construction of BACS, motivating the progress of intelligent building technology in China. Intelligent Buildings spread rapidly along with the ‘‘Upsurge of Property Development’’ in China in 1990s. Many system integration companies were set up. As a consequence, there was much confusion and misunderstandings on Intelligent Building. After that, the Ministry of Construction (MOC) issued a series of standards and regulations including ‘‘Draft Regulation of Building Automation System Engineering Design

and Management’’ in 1997, and ‘‘Draft Regulation of Qualification Management of Building Automation System Design and System Integration Engineering’’ in October, 1998. These regulations defined the entry qualification for BACS business and, therefore, standardized the market and ensured the quality of construction development. By the end of 2001, 905 companies have received licenses from the MOC. In 1999, MOC issued ‘‘Key Points and Technology Guide on National BACS Demo Projects for Residential Estates’’ (draft version) which plans to complete the demo projects in 5 years starting from 2000. The demonstration projects are categorized into three classes, i.e. Class 1, Class 2 and Class 3. This plan intends to promote the use of Intelligent Building technology in China and show to the public what Intelligent Building is as well. ‘‘Intelligent Building Design Standard’’ (Code No. GB/T50314-2000) was endorsed as the National PreStandard by Ministry of Construction, being valid since October, 2002. In the same year, the Ministry of Information Industry issued the ‘‘Structured Cabling Design Regulation on Building and Complex’’ and ‘‘Regulation on Testing and Acceptance of Structured Cabling in Building and Complex’’. These national standards have benefited the development of Chinese BACS industry significantly. In early 2002, the ‘‘Code for Acceptance of Quality of Intelligent Building Systems (Evaluation Version)’’ (GB 50307-2002) was compiled by Tsinghua Tongfang. This standard definitely makes the content, configuration and acceptance of BACS clearer. In November 19, 2002, a committee on National Standards of ‘‘Applications of Building and Residential Estate Digital Technologies’’ was founded in Beijing. It is planned that a standard can be ready by the end of 2004.

5. Conclusion The best way towards integration and interoperability is to implement a unified communication standard for all levels of BACS, there are several choices nowadays. BACnet is one candidate and it has been accepted as an ISO standard. Other protocols like EIB-ObIS, LonTalk plus LonMark and Profibus may also find their position in the industry particularly in


the IB industry. To achieve the total integration of IB systems, which seems to be the trend now, further extension of BACnet needs to be concerned. In practice, various communication protocols, even proprietary ones may exist for a long time due to market reasons. Therefore, the integration at management level is also necessary. Both OPC and Web Services are good candidates for achieving integration and interoperation at the management level, although they have some disadvantages. However, combining both of them to overcome most of their disadvantages, is the best solution today. Although BACnet includes the functions at management level function, it is also beneficial for it to collaborate with OPC and Web Services to achieve more powerful integration and Internet applications, even integration with other enterprise-level applications.

Acknowledgements The research work presented in this paper was financially supported by a research grant from The Hong Kong Polytechnic University.

References [1] D.M. Fisher, BACnet and LonWorks: A White Paper, 1996 July, http://www.bacnet.org/. [2] Frost, Sullivan, North American Building Automation Protocol Analysis, Frost and Sullivan Report A143-19, 2002 May. [3] S.W. Wang, J.L. Xie, Integrating building management system and facility management on Internet, Automation in Construction V11 (6) (2002) 707 – 715. [4] S.T. Bushby, Communication gateways: friend or foe? ASHRAE Journal 40 (4) (1998 April) 50 – 53. [5] H.R. Kranz, Standard protocols: what is their influence on the world of building automation? Proceedings of Clima2000, Napoli, Italy, 2001 Sept. [6] ANSI/ASHRAE Standard 135-2001: BACnetR, A data communication protocol for building automation and control networks, American Society of Heating Refrigerating, and AirConditioning Engineers, Atlanta, GA, 2001. [7] ASHRAE SSPC 135, http://www.bacnet.org/.

619

[8] Koch C., ‘‘What is ERP?’’, http://www.darwinmag.com/learn/ curve/column.html?ArticleID=39. [9] The OPC Foundation, http://www.opcfoundation.org/. [10] The World Wide Web Consortium (W3C), http://www.w3.org/. [11] Craton E., Robin D., Information Model: The Key to Integration, 2002 Jan., http://www.AutomatedBuildings.com. [12] Z.Y. Xu, S.W. Wang, BACnet, LonWorks and BACS Communication Standard, Building Intelligence V27 (2) (2003 Feb.) 32 – 37. [13] Echelon, ‘‘LonMark Application-Layer Interoperability Guidelines—Version 3.3’’, San Jose, CA, 95126, USA, 2002 Oct. [14] H.R. Kranz, O. Gisler, Standardization and IT Technology Shape BACS Industry, http://www.automatedbuildings.com. [15] BACnet Manufacturers Association, ‘‘Interoperability: Going Beyond the Standard’’, Maintenance Solutions, 2000 Sept., pp. 16 – 17. [16] R.A. Fellows, Connecting BACnet to the Internet, HPAC, Heating, Piping, Air Conditioning Engineering V72 (3) (2000 March) 65 – 71. [17] S.T. Bushby, H.M. Newman, ‘‘BACnet Today’’, Supplement to ASHRAE Journal (2002 Oct.) 10 – 18. [18] EIA Standard ‘‘Control Network Protocol Specification’’, EIA/CEA-709.1-B (Revision of EIA-709.1-A), 2002 Jan. [19] J. Piper, Understanding open protocols, Building Operating Management V48 (8) (2001 Aug.) 42 – 45. [20] Claus E., Synchronic Extending interoperability and connectivity, Mar., 2002, http://www.AutomatedBuildings.com. [21] Chisholm A., OPC Data Access 2.0 Technical Overview, 1998 Oct., http://www.opcfoundation.org/04_tech/opcae-short.ppt. [22] G. Baumann, M. Damm, Industrial communication system— independent and flexible, PRAXIS Profiline-OPC, vol. 1, Vogel Verlag, Wuerzburg, 2003 Jan., pp. 43 – 46, http:// www.is.siemens.de/data/presse/docs/isfb01033112e.pdf. [23] Li T., Web Services Technology, 2001 Nov., http://www. acssnl.org/acssnlnews/liting.pdf. [24] Zhang M.J., Web Service, Part 1 Dissect Apache SOAP, 2001 Sept., http://www.emoxie.com/whitepapers/ WebServices-I-DisectApacheSOAP-v2.pdf. [25] CERN, ‘‘Web Services’’, http://joung.im.ntu.edu.tw/teaching/ distributed_systems/2002EMBA/web_services.pdf. [26] W.L. Lu, Asia situation and development of intelligent building, Engineering Design CAD and Intelligent Building V67 (6) 2002 June. [27] R.L. Xu, H. Du, Opportunity and challenge of intelligent building development in China, City and Building Automation System, 2002 Sept. [28] Tom S., ‘‘Web Accessible Control Systems—Lessons Learned’’, http://www.automatedlogic.com/alcinternet.nsf/ webview/Lessons_Learned.