55 Investigation on Intelligent Building Standard Communication

7/28/2019 55 Investigation on Intelligent Building Standard Communication

1/13

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 ControlSystem (BACS) and presents two possible solutions on the basis of the hierarchy architecture of BACS. One is to employ aunified 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 thissolution. A survey on the development of Intelligent Building (IB), the application of IB technologies and the IB standards inChina 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 andlimited opportunities for the integration of buildingautomation and control systems among products of different vendors have frustrated real estate develop-

ers, building owners/operators, consultants, systemintegrators [1]. Although great progress has been madeon the interoperability of Building Automation andControl System (BACS), proprietary protocols stilldominate the current BACS market even today [2].In a typical BACS, different communication protocols

are usually employed, even among the products of onecompany. A popular way to integrate the products of various protocols is to employ gateway [3], which hasthe 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 thetechnical details of two protocols and understand themas well. One needs a lot of configuration effort to makethe gateway map the data points correctly, this makesgateways expensive. The gateway also slows down theresponse due to the time required for conversion.Furthermore, one can hardly program and configurea controller through a gateway [4].

As a practical example, a comprehensive Intelli-gent Building (IB) system was developed recently inour university teaching laboratory facility. Fig. 1

0926-5805/$ - see front matter D 2004 Elsevier B.V. All rights reserved.doi:10.1016/j.autcon.2004.04.008

* Corresponding author. Tel.: +852-2766-5858; fax: +852-2765-7198.

E-mail address: [email protected] (S. Wang).

www.elsevier.com/locate/autconAutomation in Construction 13 (2004) 607619


2/13


3/13

SOAP and Web Services [10], etc.) can be employedto solve the problem.

This paper presents the survey and analysis on the

standard technologies used to integrate and interoper-ate from different levels, discusses and compares theadvantages and disadvantages of different methods,aiming at giving a better solution. The (BACS) LAN protocols are reviewed and evaluated with focus onthe main features of the communication protocol-BACnet. The methods and technologies for the inte-gration at the management level are investigated bycomparing two different technologies for the integra-tion at this level, analyzing the pros and cons of OPCand Web Services. A survey on the progress and thecurrent status of IB technologies and IB market inChina is presented and the development of Chinese IBstandards is addressed.

2. LAN protocol standards and BACnet

There are a few potential candidates likely to be thefuture unified BACS communication protocols for allthe three levels, such as BACnet, European Installa-tion Bus Object Interface Specification (EIB-ObIS),LonTalk plus LonMark. They are all object-oriented

protocol s or have extension of object-oriented tech-nology [11] . In this session, the issues related to protocol standards are elaborated by addressing main-ly BACnet and the relation and comparison of BAC-net with other protocols.

BACnet is developed under the auspices of theASHRAE [7]. It is an American national standard, aEuropean pre-standard, an ISO global standard and thenational standard of some Asian countries (e.g. Japanand South Korea). The protocol is supported andmaintained by ASHRAE Standing Standard Project

Committee 135. It is the only open protocol that wasdesigned for building automation from the ground up,is the only open protocol that supports high-endfunctions like scheduling, alarming, and trending.

2.1. BACnet protocol architecture

As many other communication protocols, the BAC-net employs the OSI model as its reference model. TheOpen System Interconnection (OSI)-Basic ReferenceModel (ISO 7498) is an international standard that

defines a model for developing multi-vendor computer communication protocol standards. The OSI modeladdresses the general problem of computer-to-com-

puter communication and breaks this very complex problem into seven smaller, more manageable sub- problems, each of which concerns itself with a specificcommunication function. Each of these sub- pro blemsforms a layer in the protocol architecture [6].

However, the OSI model is just a consideratereference model, but never demands to realize allthe layers. B ACnet actually implements a collapsedarchitecture (Fig. 2) . Only selected layers of the OSImodel are adopted by BACnet to reduce messagelength and communication processing overhead.Such a collapsed architecture permits the buildingautomation industry to take advantage o f lower cost,mass-produced processor. As shown in Fig. 2 , BAC-net has only four layers, a collapse of the seven-layer architecture.

In fact, it requires more system resource and morecost to implement all the seven layers in practice. It isalso not always a good choice to implement all thelayers. Therefore, many protocols do not implement all the layers, such as the popular TCP/IP (Internet).

In the building automation and many other controlindustries, it is not needed to implement all the seven

layers. The four-layer collapsed architecture was cho-sen after careful consideration of the particular fea-tures and requirements of BACS networks, includinga constraint that protocol overhead needed to be assmall as possible. The use of readily available, wide-spread technologies, such as Ethernet, ARCnet, andLonTalk, will lower the cost, increase the perfor-mance, and open new doors to system integration [6].

2.2. Can BACnet device interoperate LonWorksdevice?

One might think that BACnet devices should beable to interoperate with LonWorks devices as BAC-net has included LonTalk. It is not right in reality.BACnet adopts the subnet of LonTalk only, not alllayers. Only the LonTalk Physical Layer and LonTalk Data Link Layer are adopted as one option of its fivealternative transportation technologies. The other layers of BACnet and LonWorks are completelydifferent. Therefore, BACnet devices and LonWorksdevices are not interoperable.

S. Wang et al. / Automation in Construction 13 (2004) 607619 609


4/13

The explanation is not difficult to understand.BACnet only adopts LonTalk Physical Layer and DataLink 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 indifferent languages (Fig. 3) . Only BACnet devices can

read BACnet messages. Similarly, o nly LonWorksdevices can read LonWorks messages [12].

2.3. Object functions of BACnet

BACnet, LonMark Functional Profiles and Euro- pean Installation Bus Object Interface Specification(EIB-ObIS) are object-orient communication proto-cols [11] . They provide a serial of objects. Object-orient is one of the important features of BACnet.

BACnet defines standard object types that repre-sent the commonly used objects found in manyautomation systems available in the market. BACnet objects are collections of properties each representingsome 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 tem-

plate for a functional block. Each functional profileconsists of a profile description and a specified set of network variables and configuration propertiesdesigned to perform a single function on a device.A functional block is an implementation of a func-tional profile. A standard functional block is alsoknown as a LonMark object. A standard or user functional block is also known as an object [13].Fig. 3. BACnet transportation on LonTalk.

Fig. 2. BACnet collapsed architecture.

S. Wang et al. / Automation in Construction 13 (2004) 607619610


5/13

Table 1 presents a comparison between the stan-dard o bject functions provided by BACnet and Lon-Mark [5]. Both have realized a series of standard

objects, especially BACnet, has included some high-end functions, such as scheduling, alarm management,trend, etc. LonMark seems to solve interoperability at the component level. BACnet addresses interoperabil-ity at a controller level, which concerns a larger scopewhere most interoperability is between controllers andhigher level devices.

Another goal of BACnet is extensibility, includingconnection with other protocols. EIBA has beenassigned a unique BACnet vendor ID (74, decimal) by the ASHRAE organization. This vendor ID must be used for the mappings of EIB applications toBACnet. The document ISO/TC205WG3 BACnet draft addendum H.5 describes how EIB FunctionalBlocks, which are part of Object Interface Specifica-tions (ObIS) of the Interworking Model defined by theEIB Associat ion (EIBA), are mapped to thecorresponding Building Autom ation and Control net-works (BACnet) object model [14].

2.4. Interoperability of BACnet

The BACnet approach to realize interoperation is a

very general purpos e and therefore a broadly applica- ble interoperability [15]. To make sure the interoper-ability of BACnet devices, five interoperabilityareas (IAs) are defined, i.e. data sharing, alarm andevent management, scheduling, trending, and deviceand network management. Each IA is a group of related functions that define what represents the core

of interoperability. BACnet Interoperability BuildingBlocks (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 devicesare nodes on a BACnet internetwork. In most cases,the A device will act as the user of data (client), andthe 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 Ap- plication Controller (B-AAC), BACnet Application-Specific Controller (B-ASC), BACnet Smart Actua-tor (B-SA) and BACnet Smart Sensor (B-SS). Thelisting of BACnet capabilities for each of thesestandard BACnet devices is called a device profile. The profile indicates which BIBBs must be supported by each device type for each inter-operability area [6].

This is really different from approach of LonWorkstowards interoperability. LonWorks controllers that make use of LonWorks can communicate with eachother through what LonWorks calls Standard Net-work Variable Types or SNVTs (pronounced sniv-ets). The SNVT method is a different approach todefining data objects that requires a detailed knowl-

edge on the part of the sender and receiver of what thestructure of each SNVT is. SNVTs are identified by acode number that the receiving controller can use todetermine how to interpret the information presentedin each SNVT.

LonWorks does not define what a particular SNVTcode represents. It is possible, and regrettably com-monplace, for LonWorks systems from different ven-dors to use the same SNVT code to mean different things. To solve this problem, the LonMark Consor-tium was formed with the intention to agree upon

some rules for how LonWorks should be used, and toagree 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 tointeroperate 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.

Table 1BACnet/LonMark object functions



6/13

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 torealize an IP connection. One is BACnet/IP Packet-Assembler-Disassembler (PA D) router technologywhich specified in Annex H.3 [6] of ANSI/ASHRAEStandard 135-2001. PAD router is placed on everyBACnet network that is to be connected over an IPnetwork to another BACnet network. When it receivesa BACnet message for a device on another BACnet network which is reachable only through an IP inter-network, it puts the BACnet message into a UDP/IPmessage with the IP address of the PAD device on thedestination BACnet network and sends the messageover the IP network. The receiving PAD removes theBACnet message and transmits the message on thelocal network. Since the PAD sends the messagedirectly to a known IP of another PAD, this requiresthat the PAD maintains a table of its peer PAD devices[16]. Unfortunately tunnel routers have several signif-icant configuration issues and require a lot of expert manual configuration (maintaining the tables) to work correctly. Another problem is the addition of a singleBACnet device to a BACnet system via an IP internet-work would require either that the device itself pro-

vides the PAD service or the addition of another device that provides the PAD ser vice. This wouldsignificantly increase the cost [16].

BACnet has improved significantly overcomingthese limitations by adopting the second technologyfor BACnet to realize an IP connection, i.e. BACnet/ IP defined in Annex J [6] of ANSI/ASHRAE Stan-dard 135-2001. Basically, BACnet/IP devices com-municate using IP messages in lieu of BACnet messages, allowing the devices to be easily addedto any IP internetwork [16]. This is implemented bydefining a new protocol layer called the BACnet Virtual Link Layer or BVLL. Broadcast manage-ment is accomplished by defining the capabilities of a new device called a BACnet Broadcast Manage-ment Device (BBMD). Alternatively, IP multicast may be used.

This method allows devices to enter the systemfrom anywhere in the IP internetwork. It supportsnative IP BACnet devices such as unitary control-lers which send and receive BACnet messages withinIP frames. Therefore, BACnet devices effectively useIP internetw orks as BACnet local area networks(LANs) [16]. Fig. 4 shows the connection betweenBACnet and Intern et and how to access BACnet devices by browser [17].

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



7/13

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 Japaneseand Korean. There is a unanimous positive output from CEN/TC247 balloting adopting prEN ISO16484-5 (BACnet 2001) as BACS standard that ranin parallel with the ISO enquiry. So the way is nowclear for BACnet to be recognized as an officialEuropean Norm (EN) [7].

EIB Functional Blocks have a mapping toBACnet object. The document ISO/TC205 WG3BACnet draft addendum H.5 describes how EIBFunctional Blocks are mapped to the co rrespondingBACnet object model is in public review [7]. LonTalk is the standard of ANSI/EIA709 .1-A-1999.1 as thestandard of consumer electronics [18], CEN pre-stan-dard for BACS.

2.7. Application of BACnet and other protocols

BACnet, with its focus on efficiently transmit-ting data over high-speed local and wide areanetworks, functions well at passing large blocksof data. The system can efficiently handle central-

ized control functions in large buildings or inmultiple buildings. LonTalk, with its focus onthe individual devices connected to the system,is an efficient system that provides a relativelyeasy way to implement communications betweencontrollers and devices [19], is suitable for homeautomation, component-level (field control) controlof BACS.

Although BACnet has many features to be suit-able to BACS, but due to lack of developing toolsand effective promotion in the market, there are not

as many products available as LonWorks products inthe BCAS market. Up to now, no BACnet product has yet been produced in China. On the contrary,LonWorks development tools and products are wide-ly available. In addition, the LonTalk protocol has been effectively implemented in firmware. Thismakes it a more popular application in China as it provides the platform and tool for new BACS man-ufacturers to enter the market quickly. In fact, thereare many third parties manufacturing Lon-based products in China.

3. Standard protocols and IT technologies forintegration at management level

The integration at management l evel is basicallythe communication of applications [14]. Many tech-nologies can be used for that. A majority of productshave adopted proprietary communication protocolswhile Microsoft DDE technology was used toachieve the communication between different soft-ware. However, due to the poor performance of DDE, this technology has been phased out. Variouscommunication technologies have been developed toachieve convenient communication among applica-tions, such as RMI, COM/DCOM, C ORB A and WebServices. These IT technologies [14] have great influence and are adopted to BACS field, such asOLE for Process Control (OPC), the Web Servicestechnology.

The integration technologies at management levelcan 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 Microsofts OLE, Component Object

Model (COM) and Distributed Component Object Model (DCOM) technologies, OPC consists of standard interfaces, properties and methods for theuse in process control and manufacturing-automa-tion applications.

One of the valuable features of OPC is that it provides a common interface for communicating withdiverse process control devices, regardless of the con-trolling software or protocols used in the process.Before OPC became available, application developershad to create specific communications drivers for each

control system with which they wanted to connect.With OPC, application vendors no longer need separatedrivers for each new processor or protocol. Instead, themanufacturers create a single optimized OPC driver for their product [20], as illustrated in Fig. 5 [21].

OPC can play an essential role in the integrationof different vendors BA systems or devices. For example, in Fig. 6, BACS 1 and BACS 2 softwarehas provided the OPC server interface, so Intelligent Building Management System (IBMS) station soft-ware and Web applications can communicate with



8/13

them via OPC interface. It is easier if the OPCserver driver is provided by a device, the device can be connected directly via OPC server driver. How-ever, OPC still has problems to solve as discussed below.

As discussed earlier, OPC uses COM and DCOM asthe core technology for the software interface. There-fore, when one uses an OPC server located on amachine different from yours, he must configure theDCOM security. Many installers experienced this as a problem particularly on Windows 95 and Windows 98

machines as there is a security infrastructure in theseversions of Windows, different from Windows NT/ 2000/XP. As a result, DCOM security is often disabled,which leads to severe security risks. It gets e ven morerisky to use an OPC server over the Internet [20].

As OPC DCOM interaction over the Internet willresult in severe security problem, it is not practical to be used. However, XML technology can be used tofulfill these gaps. It is overcome by the new OPCXML-DA standard. In the new standard, OPC allowsmanufacturing and process data to be accessed via the

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

Fig. 5. Communication of automation systems using OPC.



9/13

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 isthat they cannot be accessed from non-Windowssystem, OPC DCOM clients cannot communicatewith non-Windows system. Therefore, they cannot be used on other platforms.

For the tracking and other monitoring software inBACS, it is important that all data are received by theapplication without interruption. When an applicationexperiences a bad connection or even gets disco nnect-

ed, OPC cannot automatically try to reconnect [20]. It is another problem of OPC in BACS applicationswhich 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 modelssupported on the Internet or control networks usingHTTP technology, which provides loosely coupled,flexible, and dynamic solutions by using emerging

techniques as SOAP, WSDL and UDDI. These tech-nologies are designed on the basis of existing Webtechnologies. Web Services are self-contained, self-describing, modular applications that can be published,located, and invoked across the Web [23]. The coretechnologies of the Web Service are listed below:

(i) XML. XML was developed first. Web Servicewas developed on the basis of XML. All WebService definition and messages are in the formof XML.

(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 describ-ing a Web Service. Documenting a Web Servicein WSDL provides a big room for futureautomatic client site Web Service stub genera-tion or using GUI application to configure/plug-in Web Service.

(iv) Simple Object Access Protocol (SOAP). SOAP isalso an XML DTD that defines how a messagewill be sent across the wire. As long as you sent aservice request in SOAP, no matter how the WebService is constructed, it will serve you [24].SOAP offers vendor, platform and languageindependence. With SOAP, developers can easily bridge applications written w ith COM, CORBAor Enterprise JavaBeans. Fig. 7 [25] showsintegration among different platforms.

Web Service adopts common Internet protocols(HTTP, HTTPS, SMTP . . .) as its basic communica-tion framework. These protocols ports usually are

open by firewall, so Web Services are Internet-friend-ly. Using the Web Service technology, BACS systemsfrom different vendors, even on differe nt plat formscan be integrated easily, as illustrated in Fig. 8 .

As shown in the figure, the Portal application canaccess different BACS via Web Services and the non-BACS systems can be easy to be integrated as well.For example, a weather bureau could offer a Web

Fig. 7. Integration among different platforms.

Fig. 8. BACS systems integration using Web Services.



10/13

service that allows a building automation system toautomatically retrieve temperature forecast data for use by various control algorithms. Similarly, the building automation system itself could offer a Webservice that allows a tenants accounting system toobtain u p-to-the-minute figures on energy consump-tion [11] .

However, since the SOAP request/response isenveloped in XML format, it will be too complex

for the control communication in some situations andwill increase the need for processor power and addi-tional response time.

3.3. Discussion

On Intranet, OPC configuration and security can beaddressed relatively easily in comparison with thecase on the Internet. OPC can achieve better commu-

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

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



11/13

nication performance on Intranet compared with WebService. Therefore, OPC is a better choice on Intranet.However, when it is extended to Internet, Web Serv-

ices can provide better security and integration per-formance compared with OPC. In conclusion, the best way is to combine OPC and Web Services in appli-cation when the TCP/IP-based control network isconnecte d to the Internet.

Fig. 9 shows a schematic of an IB system integra-tion and management tool developed in our IB labo-ratory. OPC is employed in the TCP/IP network,integrating the control networks at a lower level.The OPC client components are wrapped to thecampus network (or public) as Web Services. Userscan access the Web Services to supervise and con trolthe BACS system via campus Intranet/Internet. Fig.10 illustrates the IB integration middleware architec-ture of the tool based on OPC and Web Servicestechnologies to realize the integration and interoperability among BACS systems.

4. Development of intelligent buildings in China

4.1. Current status

Intelligent Buildings, as a concept, attracted theattention of the industry and public in China in 1990.Since then, it is being quickly developed all over thecountry. The building Beijing Development Build-ing might be the first building to be considered as anintelligent building in China. After that, a number of intelligent buildings using more technologies wereconstructed, such as Shanghai Jinmao Building(88F), Shenzhen Diwang Building (81F), GuangzhouZhongxin Building (80F), Nanjing Jinying Interna-tional Commercial Building (58F). According to

some statistics of not very high accuracy, over 2000so-called intelligent buildings will have been con-structed by the end of 2002. These buildings werenormally high-class commercial buildings which weredesigned, constructed and managed using the samerequirement for services used in developed countries. Nowadays, there is a trend wherein the intelligent building is changing its market to large public build-ings, such as exhibition centers, libraries, stadiums,culture and art centers, museums, etc. For example,the Shenzhen Library and Art Center was built at a

cost of RMB 1.6 billion (1 USD=8.2 RMB). Itsinvestm ent on IB system accounts for RMB 100million [26].

Table 2 shows a summary of the investment on realestate development in Mainland China in the period between 1997 and 2001, according to the data fromthe China National Statistical Bureau. The investment on real estate property development is up to RMB2,204.222 billion in that period and was being accel-erated in these 5 years. Assuming that one-fourth of the developments were equipped with BACS/IB sys-tems 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 pro-cess makes her have higher requirement on intelligent building, not only for newly constructed buildings but also for the renovation of existing buildings. Fromthis, it is obvious that there is great potential f or thedevelopment of Intelligent Buildings in China [27].

4.2. Applications of BACS protocols and IT technologies

BACnet has been promoted successfully in certaincircumstances in China. The Chinese version of BAC-

net was released in November, 2000. A number of well-known BACnet vendors have set up their branches inChina. A few companies in China are developingBACnet products. BACnet in China m ailing list (http://groups.yahoo.com/group/BACnet/ ) has beenset up in 2001 with over 100 subscribers today. Somelarge real estate developments have deployed BACnet-compliant products, such as the Shanghai Science andTechnology Museum, which is the largest scientificand technical museum in Asia. It uses BACnet tointegrate over 3200 control points and 1000 monitoring

Table 2Real estate investment (100 million RMB) in Mainland China between 1997 and 2001

Year Resident building

Office building

Commercial building

Others Total

1997 1539.38 388.98 425.85 824.16 3178.371998 2081.56 433.80 475.83 623.04 3614.231999 2368.48 338.60 484.33 641.79 4103.202000 3318.74 292.57 547.75 742.68 4901.742001 4278.74 318.00 720.80 927.94 6244.68

http://%20http//groups.yahoo.com/group/BACnet/http://%20http//groups.yahoo.com/group/BACnet/http://%20http//groups.yahoo.com/group/BACnet/


12/13

points into a single Web-Accessible controls system.AHUs, chillers, pumps, lighting, elevators, fire, secu-rity, and other building systems supplied by nine

different vendors are mo nitor ed and controlled by aunified operator interface [28].At the same time, other protocols such as Lon-

Works have also been widely used. Using the Neuronchips located in LonWorks devices, they allow man-ufacturers to enter the BACS production market easily. It is probably why LonWorks products nowhave a significant market share in China.

A few universities and enterprises are developingBuilding Management Systems based on OPC andWeb Services technology, such as The Hong KongPolytechnic University. There are a few software providing OPC interface. Some products have beenused in actual real estate development projects. Theresearch on Web Services hasnt entered commercialapplication, but is keeping up with internationaldevelopment.

4.3. National and regional standards and regulationson intelligent building

In the early phase of development, research onintelligent building standards has only just started,

with a lack of openness and unity. These directlyimpacted the healthy development of the market. In1995, the Communication Engineering Committee of the Chinese Construction Standard Association issueda Design Guide on Construction and Structure Ca- bling. Due to the lack of national standards, someregional authorities issued local standards, such asShanghai Intelligent Building Design Standard(DBJ08-47-95) in 1995, Jiangsu Building Automat-ed Design Standard (DB32/1811998) in 1998.These regional standards provide the guide for the

plan, design and construction of BACS, motivatingthe progress of intelligent building technology inChina.

Intelligent Buildings spread rapidly along with theUpsurge of Property Development in China in1990s. Many system integration companies were set up. As a consequence, there was much confusion andmisunderstandings on Intelligent Building. After that,the Ministry of Construction (MOC) issued a series of standards and regulations including Draft Regulationof Building Automation System Engineering Design

and Management in 1997, and Draft Regulation of Qualification Management of Building AutomationSystem Design and System Integration Engineering

in October, 1998. These regulations defined the entryqualification for BACS business and, therefore, stan-dardized the market and ensured the quality of con-struction development. By the end of 2001, 905companies have received licenses from the MOC.

In 1999, MOC issued Key Points and TechnologyGuide on National BACS Demo Projects for Resi-dential Estates (draft version) which plans to com- plete the demo projects in 5 years starting from 2000.The demonstration projects are categorized into threeclasses, i.e. Class 1, Class 2 and Class 3. This planintends to promote the use of Intelligent Buildingtechnology 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 Pre-Standard by Ministry of Construction, being validsince October, 2002. In the same year, the Ministryof Information Industry issued the Structured Ca- bling Design Regulation on Building and Complexand Regulation on Testing and Acceptance of Struc-tured Cabling in Building and Complex. Thesenational 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 Tong-fang. This standard definitely makes the content,configuration and acceptance of BACS clearer.

In November 19, 2002, a committee on NationalStandards of Applications of Building and Residen-tial Estate Digital Technologies was founded inBeijing. 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 stan-dard for all levels of BACS, there are several choicesnowadays. BACnet is one candidate and it has beenaccepted as an ISO standard. Other protocols likeEIB-ObIS, LonTalk plus LonMark and Profibus mayalso find their position in the industry particularly in



13/13

the IB industry. To achieve the total integration of IBsystems, 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 tomarket reasons. Therefore, the integration at manage-ment level is also necessary. Both OPC and WebServices are good candidates for achieving integrationand interoperation at the management level, althoughthey have some disadvantages. However, combining both of them to overcome most of their disadvantages,is the best solution today. Although BACnet includesthe functions at management level function, it is also beneficial for it to collaborate with OPC and WebServices to achieve more powerful integration andInternet applications, even integration with other en-terprise-level applications.

Acknowledgements

The research work presented in this paper wasfinancially supported by a research grant from TheHong Kong Polytechnic University.

References

[1] D.M. Fisher, BACnet and L onWorks: A White Paper, 1996July, http://www.bacnet.org/ .

[2] Frost, Sullivan, North American Building Automation Proto-col Analysis, Frost and Sullivan Report A143-19, 2002 May.

[3] S.W. Wang, J.L. Xie, Integrating building management systemand facility management on Internet, Automation in Construc-tion V11 (6) (2002) 707715.

[4] S.T. Bushby, Communication gateways: friend or foe? ASH-RAE Journal 40 (4) (1998 April) 5053.

[5] H.R. Kranz, Standard protocols: what is their influence on theworld of building automation? Proceedings of Clima2000,

Napoli, Italy, 2001 Sept.[6] ANSI/ASHRAE Standard 135-2001: BACnet R , A data com-munication protocol for building automation and control net-works, American Society of Heating Refrigerating, and Air-Conditioning Engineer s, Atlanta, GA, 2001.

[7] ASHRAE SSPC 135, http://www.bacnet.org/ .

[8] Koch C., What is ERP?, http://www.darwinmag.com/learn/ curve/column.html?Arti cleID=39 .

[9] The OPC Foundation, http://www.opcfoun dation.org/ .[10] The World Wide Web Consortium (W3C), http://www.w3.org/ .

[11] Craton E., Robin D., Information Model: The Key to Integra-tion, 2002 Jan., http://www.AutomatedBuildings.com .

[12] Z.Y. Xu, S.W. Wang, BACnet, LonWorks and BACS Com-munication Standard, Building Intelligence V27 (2) (2003Feb.) 3237.

[13] Echelon, LonMark Application-Layer InteroperabilityGuidelinesVersion 3.3, San Jose, CA, 95126, USA, 2002Oct.

[14] H.R. Kranz, O. Gisler , Standardization and IT Technolog yShape BACS Industry, http://www.automatedbuildings.com .

[15] BACnet Manufacturers Association, Interoperability: GoingBeyond 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.) 1018.

[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 OperatingManagement V48 (8) (2001 Aug.) 4245.

[20] Claus E., Synchron ic Extending interoperability and con nec-tivity, Mar., 2002, http://www.AutomatedBuildings.com .

[21] Chisholm A., OPC Data Access 2.0 Technical Overview, 199 8Oct., http://www.opcfoundation.org/04 _ tech/opcae-short.ppt .

[22] G. Baumann, M. Damm, Industrial communication system

independent and flexible, PRAXIS Profiline-OPC, v ol. 1,Vogel Verlag, Wuerzburg, 2003 Jan., pp. 4346, http:// www.is.siemens.de/data/presse/docs/isfb01033112 e.pdf .

[23] Li T., Web Services Technology, 2001 Nov., http://www.acssnl.org/acssnlnews/liting.pdf .

[24] Zhang M.J., Web S ervice, Part 1 Dissect ApacheSOAP, 2001 Sept., http://www.emoxie.com/whitepapers/ WebServices-I-DisectApa cheSOAP-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 build-ing, 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 Automa-tion System, 2002 Sept.

[28] Tom S. , Web Accessible Control SystemsLessonsLearned, http://www.automatedlogic.com/alcinternet.nsf/ webview/Lessons _ Learned .

http://%20http//www.bacnet.org/http://%20http//www.bacnet.org/http://%20http//www.bacnet.org/http://%20http//www.bacnet.org/http://%20http//www.bacnet.org/http://%20http//www.bacnet.org/http://%20http//www.opcfoundation.org/http://%20http//www.opcfoundation.org/http://%20http//www.w3.org/http://%20http//www.w3.org/http://%20http//www.AutomatedBuildings.comhttp://%20http//www.automatedbuildings.comhttp://%20http//www.automatedbuildings.comhttp://%20http//www.automatedbuildings.comhttp://%20http//www.AutomatedBuildings.comhttp://%20http//www.AutomatedBuildings.comhttp://%20http//www.AutomatedBuildings.comhttp://%20http//www.opcfoundation.org/04_tech/opcae-short.ppthttp://%20http//www.opcfoundation.org/04_tech/opcae-short.ppthttp://%20http//www.opcfoundation.org/04_tech/opcae-short.ppthttp://%20http//www.opcfoundation.org/04_tech/opcae-short.ppthttp://%20http//www.opcfoundation.org/04_tech/opcae-short.ppthttp://%20http//www.is.siemens.de/data/presse/docs/isfb01033112e.pdfhttp://%20http//www.is.siemens.de/data/presse/docs/isfb01033112e.pdfhttp://%20http//www.acssnl.org/acssnlnews/liting.pdfhttp://%20http//www.acssnl.org/acssnlnews/liting.pdfhttp://%20http//www.acssnl.org/acssnlnews/liting.pdfhttp://%20http//www.emoxie.com/whitepapers/WebServices-I-DisectApacheSOAP-v2.pdfhttp://%20http//www.emoxie.com/whitepapers/WebServices-I-DisectApacheSOAP-v2.pdfhttp://%20http//joung.im.ntu.edu.tw/teaching/distributed_systems/2002EMBA/web_services.pdfhttp://%20http//joung.im.ntu.edu.tw/teaching/distributed_systems/2002EMBA/web_services.pdfhttp://%20http//joung.im.ntu.edu.tw/teaching/distributed_systems/2002EMBA/web_services.pdfhttp://%20http//www.automatedlogic.com/alcinternet.nsf/webview/Lessons_Learnedhttp://%20http//www.automatedlogic.com/alcinternet.nsf/webview/Lessons_Learnedhttp://%20http//www.automatedlogic.com/alcinternet.nsf/webview/Lessons_Learnedhttp://%20http//joung.im.ntu.edu.tw/teaching/distributed_systems/2002EMBA/web_services.pdfhttp://%20http//www.emoxie.com/whitepapers/WebServices-I-DisectApacheSOAP-v2.pdfhttp://%20http//www.acssnl.org/acssnlnews/liting.pdfhttp://%20http//www.is.siemens.de/data/presse/docs/isfb01033112e.pdfhttp://%20http//www.opcfoundation.org/04_tech/opcae-short.ppthttp://%20http//www.AutomatedBuildings.comhttp://%20http//www.automatedbuildings.comhttp://%20http//www.AutomatedBuildings.comhttp://%20http//www.w3.org/http://%20http//www.opcfoundation.org/http://%20http//www.darwinmag.com/learn/curve/column.html?ArticleID=39http://%20http//www.bacnet.org/http://%20http//www.bacnet.org/

Documents

55 Investigation on Intelligent Building Standard Communication