By Johnny Ho, Hong Kong, 852-2579-8524, ho.johnny@pbworld.com

In the early 1980s, microprocessor-based direct digital control (DDC) systems began to appear in the market place. One of their earliest and most successful applications in the building industry was heating, ventilation and air-conditioning control systems (HVAC). DDC systems provided more precise control and better operational flexibility, improved occupant comfort and reduced energy costs in comparison to electronic and pneumatic control systems.

Over the past 15 years or so, DDC systems have been expanded to control additional building services systems, such as electrical, plumbing and drainage, fire services and other mechanical and electrical installations. Special features were also developed to enhance the system functionality, such as trend logging, alarm event reporting, totalization, energy management, graphical user interface and computer generated graphic display. The terms building management system (BMS) or central control and monitoring system (CCMS) were generally given to categorize this kind of installation, particularly for building services control systems.

Figure 1 shows the traditional architecture of BMS/CCMS consisting of DDC and communication bus linked up to each group of application specific controllers and network expansion units to perform the desired operation and control logic. The communication bus is usually a RS-485 distributed network, which was initially designed for industrial application and is a proven communication network based on simple wiring.

The DDCs are high performance, distributed intelligent systems with peer-to-peer field control panels configured to handle a wide array of control duties, including setting up and running all control applications. Using a combination of resident applications and custom user-written programs, DDCs operate the equipment or installation efficiently. The information transfer and sharing between all devices in the system are achieved through the communication network between each DDC and workstation. The typical communication protocol used in early versions of BMS/CCMS was BACnetTM ¹

Figure 1: Typical architecture of DDC systems.

Figure 2: Typical BACnet Architecture

Figure 3: Typical ARCNET Architecture

Figure 4: Typical LonTalk Architecture

Figure 5: A Simplified IBS Architecture

To cope with the rapid development of high rise, super high rise and complex buildings, the demand for precise, efficient, reliable and fast-responding building control systems has grown, as has the need for interoperability for control and monitoring between various sub systems and software applications. Meeting these needs has been made possible through the enhancement of modern information technology (IT) applications as the core of intelligent building systems (IBS) for data exchange and information sharing.

Despite the functionality of BMS/CCMS, some vendors, building owners and system designers still have difficulty distinguishing between BMS, CCMS and IBS.

Control and Communication Protocol

Several international standard open system approaches are commonly deployed in BMS/CCMS to meet the application requirements, such as BACnetTM, ARCNETTM ² and LonTalk³.

BACnetTM . BACnetTM provides a comprehensive set of messages for conveying encoded data between devices for monitoring and control of HVAC and refrigeration equipment. It is intended for use in hierarchical systems composed of computers and intelligent controllers. While the BACnetTM standard could be used for systems other than HVAC, current object definitions do not include many of the devices that are commonly employed and interfaced with the building control systems. An example of BACnetTM architecture is shown in Figure 2.

ARCNETTM. ARCNETTM is a data link layer technology with no defined application layer. System designers write their own application layers to meet the users’ particular needs. ARCNETTM also incorporates a token passing protocol when media access is determined by the station with the token. When a station receives the token, it can either initiate a transmission to another station or it must pass the token to its logical neighbor. All the stations are considered peer-to-peer and no one station consumes all the bandwidth because only one packet can be sent with each token pass. The scheme avoids collisions between packets of data. ARCNETTM offers designers the advantage in real time applications of accurately predicting the time it takes for a particular station to gain access to the network when sending a message. ARCNETTM is also one of the approved data links for BACnetTM protocol. An example of ARCNET architecture is shown in Figure 3.

LonTalk. The LonTalk protocol, developed by Echelon Corporation, offers communications over a variety of media for a wide range of products and systems that utilize a dedicated Echelon very large scale integration (VLSI) component, the neuron chip. LonTalk is a peer-to-peer protocol. The result is a flat network with minimum overhead, allowing intelligent devices to handle information passed on by other devices. Interoperability amongst these devices is ensured via compliance with the LonMark interoperability standards and approval by the LonMark Interoperability Association. Most users agree that LonTalk is a good solution at the device level for a wide variety of system types. Others consider that the lack of overhead that provides flexibility at the lower system levels makes LonMark less well suited for large system use at the data exchange and information sharing level. An example of LonTalk architecture is shown in Figure 4.

Architecture of Intelligent Building System

Figure 5 shows a simplified IBS architecture. It generally consists of more than one group of application specific subsystems that perform their specific control and operation functions using the communication and control protocols according to the application characteristics. These various subsystems are interconnected to a common data network platform for data storage and exchange, and centralized control and monitoring. Owing to different communication protocol standards and configurations of each subsystem being used, designers of IBS should be aware of its following crucial elements:

• Common physical layer connectivity
• Networking technology
• Open and standard protocol
• System integration.

Common Physical Layer Connectivity. A generic wiring platform that interconnects various wiring topologies used by the subsystems will provide a common physical layer connectivity. Such connectivity facilitates standardization of wiring methods and thereby simplifies cabling works and helps to reduce running and maintenance costs.

According to specifications of Electronic Industry Association/Telecommunication Industry Association (EIA/TIA) Standards, the structured cabling system (SCS) is designed specifically for providing common connection hardware to suit different wiring topologies by using Balun adapters, converters or transceivers. The unlike signals can be transmitted through various media (the fiber optic cable and unshielded twisted pair (UTP) cable), while at the same time maintaining the signal accuracy and consistency.

The EIA/TIA standard defining the SCS should basically define the subsystems at the campus, equipment, administration, riser, horizontal, and work area levels. The performance specification of SCS supports most of the technical specifications and performance requirements of voice, data and video (analogues and digital) signal transmission, thereby facilitating the use of similar types of wiring, standards and topologies amongst various subsystems.

Network Technology. In order for various and multiple systems to run on a common data highway, the data networks should be developed with sufficient bandwidth to handle worst case conditions for each or all subsystem running simultaneously under maximum data transfer demand. Standard Ethernet (10 Mbps), Fast Ethernet (100 Mbps), ARCNETTM and Token Passing technology have inherent limitations to achieving this objective. Linking multiple networks of different standards requires numerous and expensive bridges, routers and gateways, which are not always capable of delivering a consistent solution to meet these interconnection requirements.

To overcome the networking problem for delivery of a high speed data highway, many of the leading building control systems and electronic systems (such as security and surveillance, access control, audio and visual) vendors have already re-configured their hardware design to be compatible with Transmission Control Protocol/Internet Protocol (TCP/IP) to enable file transfer, data exchange, remote login across large numbers of client server systems in local area network (LAN), wide area network (WAN) and even virtual private network (VPN). With the fading out of fibre distributed data interface (FDDI) and asynchronous transfer mode (ATM), Gigabit Ethernet at 1,000 bps will become the prime s election as the information highway for IBS.

Open and Standard Protocol. In the absence of standard subsystems, vendors have developed proprietary hardware and software solutions. All building control and information systems have proprietary techniques, application program interfaces (API), in order to access the information they contain. The cost of integrating different systems of different protocols and the long-term maintenance cost to support an integrated environment of IBS can be significant. Custom drivers and interfaces can be written, but the variety increase rapidly because of many combinations of different types of control devices and software packages that need to communicate.

The object linking and embedding for object process control (OPC) is currently the most popular and technically feasible solution for standardization of all the objects and applications ready for the realization of a plug and play platform. OPC is an industry standard created with the collaboration of a number of leading worldwide automation and hardware software suppliers working in the cooperation with Microsoft.

OPC is based on a client server architecture providing connectivity to most of the major control system vendors in the market. OPC servers are also available for many systems and protocols, including BACnetTM, LonWork, Modbus and many others. Furthermore, OPC clients can provide more than 100 of ready-to-use applications, including human machine interface, visualization and reporting tools, preventive and predictive maintenance packages, HVAC, lighting controls, security applications, etc. One of the major benefits of using OPC is that the OPC clients will not be obsolete when new functionality is added to the server. OPC standards enable easy extension of the OPC server by adding new component object model (COM) interfaces while keeping all the existing COM interfaces backward compatible.

System Integration. In between protocols, the software, hardware and networking all converge to offer solutions and value to the end users. Systems integration involves developing an open, integrating network architecture. Doing so calls for software development skills, hardware design skills, and a thorough understanding of the functions required of each system in order to assure connectivity, interoperability and usability. Designers must have the ability to tie together a series of products, tools, database formats and communication drivers, thus making all the essential components work together under a single control environment that appears homogeneous to the users and maintains independence and separation of each subsystem’s powers and functionalities.

The key features of system integration should include:
• Integrating various devices and subsystems using multiple communications protocols, both proprietary and standard
• Providing a single user interface and a common method of interaction between different products and subsystems
• Enhancing operational efficiency and improving the grade of services of the subsystems through the technology advancements of IBS by maximizing the resources and information sharing amongst subsystems.

Figure 6: Example of Intelligent Building Management System Architecture

What Should an IBS Look Like?

Certain BMS and CCMS vendors claim their products and systems are distributed and intelligent and, therefore, should be functionally regarded as IBS. The prime function of BMS or CCMS is, however, for building control functions. Although data sharing and exchange amongst the system components is evident, it is done without a compatible and standardized data exchange platform, such as using OPC. As such, it may not be appropriate to categorize the intelligent BMS or CCMS as IBS because the data exchange is not processed through an integrated environment. IBMSs possess file exchange and data sharing capabilities with other subsystems while ordinary BMSs and CCMSs do not. An example of IBMS architecture is shown in Figure 6.

The data exchange of the IBMS architecture relies on the gateway computers installed with specific custom written software to convert the data for a group of subsystems or application to a compatible format for the entire system, but not using an open and standard protocol, unlike OPC. The past experience of using gateway computers is that data accuracy is not 100 percent guaranteed because the database conversion program is custom written and would be different in every other case. Data structure is not transparent and open standards are not available, plus the processing time can be unpredictable. In most cases, the system applications and interfaces will become obsolete over time due to the lack of backward compatibility and missing of database records. Obviously, this architecture is fundamentally deviated from the concept of a true IBS architecture.

The Current Situation and Problems Encountered

Arguments on the definition of IBS, standard specifications, why and when we need to implement IBS in building control systems are abundant in the building industry.

Definition of IBS. The first questions that the building owners, designers and vendors may ask are: What is the definition of IBS? How do I know that the IBS I am getting is the system that I want? Currently, it is not easy to source the materials, specifications, design guide and standards with sufficient details to define the IBS. This is because there exists a wide variety of combinations of subsystems, methodologies, and interpretations of IBS—whether the ‘I” means integrated, interfaced or intelligent! Further discussion to lay down the standard definition amongst affiliations, vendors, and institutions seems necessary.

Why and When We Need IBS. IBS has its distinctive features and offers greater flexibility and functionality in implementing new applications in comparison with BMS/CCMS, but it has some drawbacks as well. A successful development of IBS requires additional cost, time and extra effort due to collaboration of manufacturers, vendors, and designers. Many people question why and when we need to develop IBS. The fact is, for certain small- and medium-scale building control systems, BMS or CCMS will meet the requirements, while implementing an IBS seems unnecessary. Luckily, experience has shown that the technology life cycle for control systems is typically 3 to 5 years and getting shorter because of the increased rate of advancement of technology, reduction of equipment manufacturing cost, increasing demand of add on requirements from the users, and the lack of spare parts of old systems and equipment due to the seemingly endless introduction of new systems and equipment. With this well established trend, one can predict that IBS will become the popular technology in the years to come as it can provide a full range of system compatibility, adaptability and integration ability.

Figure 7: Expanded IBS Architecture

Hardware and Software Compatibility

Complex and mega scale systems (involving a great number of components supplied by different vendors in their respective proprietary standard and specifications) require some sort of standard communication protocol and platform for successful integration. When proceeding with system integration, system integrity is a paramount requirement. For example, through the use of an OPC client, accessing various subsystems through the OPC server for data retrieval has been proven to be reliable and mature. Extra care is required for integrated systems (for remote control functions with the subsystems through local or remote network connection) under either OPC, or another standard protocol such as BACnetTM or Ethernet, because some control algorithms or functions may fail to perform the desired result or the control function cannot be operated at all.

Table 1: Comparision of Different Technologies for System Integration

It appears that some of the leading equipment manufacturers and vendors are not willing to fully follow the design specification of an open protocol standard or certain control features are being disabled in order to maintain their competitiveness in the market place, although it is difficult to find hard evidence to prove this statement. Another reason they may not fully follow these specifications is that some control algorithms require real-time hardware signal handshaking and software interlocking, to which some communication protocol structures or application interfaces cannot adequately respond after the construction of the OPC database. Some subsystems and applications are purposely designed to limit system integration or physical link up with other subsystems under an open platform due to security reasons. An example of expanded IBS architecture is shown in Figure 7.

Comparison of Different Technologies for IBS System Integration

Table 1 summarizes the strength, weakness and other characteristics of BACnet, OPC and proprietary technologies for system integration of IBS. BACnetTM and OPC technologies have shown their strength and capabilities for system integration as part of an IBS, although they have their inherent constraints on certain aspects. When comparing with proprietary technologies, BACnetTM and OPC are still in the highest ranking as the solution for an integrated IBS. In some cases, both BACnetTM and OPC can co-exist in the same system.

Conclusion