Abstract
This chapter is designed to help energy managers understand some of the fundamental concepts of Building Automation Systems (BAS). A BAS is used to control energy consuming equipment—primarily for heating, ventilating and air conditioning (HVAC) equipment and lighting controls. We thoroughly examine each component of a BAS in today’s BAS technology and what a BAS might look like in the future. The BAS of tomorrow will rely heavily on the Web, TCP/IP, high-speed data networks, and enterprise level connectivity.
INTRODUCTION
The combination of low-cost, high-performance microcomputers together with the emergence of high-capacity communication lines, networks, and the Internet has produced explosive growth in the use of Web-based technology for direct digital control (DDC) building automation systems (BAS).1 Many of these current BAS systems use a proprietary information structure and communications protocol that greatly limits the plug-and-play application and addition of interchangeable components in the system. Control solutions such as BACnet and LonWorks have helped this situation somewhat, but they have also introduced their own levels of difficulties. The BAS of the future will integrate state-of-the-art information technology (IT) standards used widely on the Internet today. These new IT-based systems are rapidly overtaking the older BAS systems. All of the established BAS companies are quickly developing ways to interface their systems using IT standards to allow the use of Web browsers such as Internet Explorer and Netscape Navigator.
This article will examine all facets of a BAS, from field controllers to the front-end interface. The emphasis is on understanding the basic BAS components and protocols first, and then examining what a BAS might look like in the future based on the influence of IT standards. Finally, this article will discuss upgrade options for legacy BAS systems and BAS design strategies.
Even though we will be referring exclusively to the term BAS in this chapter, the building automation controls industry also uses the following terms interchangeably: direct digital control (DDC), energy management system (EMS), building automation and
Keywords: Building automation systems, BAS; Direct digital control, DDC; Internet; LonWorks; BACnet.
control system (BACS), and building management system (BMS).
THE BASICS OF TODAY’S BAS
At a minimum, a BAS is used to control functions of a heating, ventilating, and air conditioning (HVAC) system, including temperature and ventilation, as well as equipment scheduling. Additional basic features include the monitoring of utility demand, energy use, building conditions, climatic data, and equipment status. Even basic BAS are generally expected to perform control functions that include demand limiting and duty cycling of equipment. Building automation systems report outputs can show the facility utility load profiles, the trends and operation logs of equipment, and the generation of maintenance schedules.
More elaborate BAS can integrate additional building systems—such as video surveillance, access control, lighting control, and interfacing—with the fire and security systems. However, in large organizations and on campuses today, it is still more common to see dedicated systems for these additional building systems due to divisions in management functional responsibility, code issues, and the features and performance of dedicated systems.
Today’s BAS are expected to receive and process more sophisticated data on equipment operation and status, such as data from vibration sensors on motors, ultrasonic sensors on steam traps, infrared sensors in equipment rooms, and differential pressure sensors for filters. Top-of-the-line BAS today also have additional capabilities, such as chiller/boiler plant optimization, time schedule and setpoint management, alarm management, and tenant billing to name a few. Most BAS manufacturers today have started to offer some form of Web-based access to their existing control systems and are actively developing Web-based capability for their future products.
CONTROLLER-LEVEL HARDWARE AND SOFTWARE
Controller Hardware
Building automation systems controllers are used to provide the inputs, outputs, and global functions required to control the mechanical and electrical equipment. Most BAS manufacturers provide a variety of controllers tailored to suit the specific need. Shown below is a list of the most common BAS controllers.
Communications interface: Provides the communication interface between the operator workstation and the lower-tier controller network. On a polling controller network, a communications interface is used to transfer data between the controllers.
Primary controller: Provides global functions for the BAS control network that can include real-time clocks, trend data storage, alarms, and other higher-level programming support. Some BAS manufacturers combine all these functions into one primary controller, while other manufacturers have separate controllers that are dedicated to each global function.
Secondary controller: Contains the control logic and programs for the control application. Secondary controllers usually include some on-board input/output (I/O) and may interface to expansion modules for additional I/O. Inputs include temperatures, relative humidity, pressures, and fan and pump status. Outputs include on/off and valve or damper control. Also included in this group are application-specific controllers that have limited capability and are designed for a specific task. Examples include controllers for variable air volume terminal unit (VAV) boxes, fan coil units, and multistage cooling and heating direct-expansion (DX) air conditioning systems.
Controller Programming
Building automation systems controllers typically contain software that can control output devices to maintain temperature, relative humidity, pressure, and flow at a desired setpoint. The software programming can also adjust equipment on/off times based on a time-of-day and day-of-week schedule to operate only when needed.
The software used to program the controllers varies by BAS manufacturer and basically falls into three categories:
Fill-in-the-blank: This type of programming uses precoded software algorithms that operate in a consistent, standard way. The user fills in the algorithm configuration parameters by entering the appropriate numbers in a table. Typically, smaller control devices use this type of programming, like those that control a fan coil or VAV box controller. These devices all work the same way and have the same inputs and outputs.
A few manufacturers have used fill-in-the-blank programming for devices that are more complex with which a variety of configurations can exist, such as air handlers. Standard algorithms are consistent for each individual component. As an example, the chilled-water valve for an air-handling unit is programmed using the same standard algorithm with only the configuration parameters adjusted to customize it for the particular type of valve output and sensor inputs. Programming all of the air-handler devices using the appropriate standard algorithm makes the air-handling unit work as a system.
The advantage of fill-in-the-blank standard algorithms is that they are easy to program and are standard. The downside is that if the standard algorithm does not function as desired, or if a standard algorithm is not available, the system requires development of a custom program.
Line-by-line custom programming: Control programs are developed from scratch and are customized to the specific application using the BAS manufacturer’s controls programming language. In most cases, programs can be reused for similar systems with modifications as needed to fit the particular application.
The advantage of line-by-line custom programs is that technicians can customize the programs to fit any controls application. The disadvantage is that each program is unique, and troubleshooting control problems can be tedious, because each program must be interrogated line by line.
Graphical custom programming: Building automation systems manufacturers developed this method to show the control unit programs in a flowchart style, thus making the programming tasks more consistent and easier to follow and troubleshoot.
Below are some additional issues to consider regarding control unit programming:
• Can technicians program the control units remotely (either network or modem dial-in), or must they connect directly to the control unit network at the site?
• Does the BAS manufacturer provide the programming tools needed to program the control units?
• Is training available to learn how to program the control units? How difficult is it to learn?
• How difficult is it to troubleshoot control programs for proper operation?
Controller Communications Network
The BAS controller network varies depending on the manufacturer. Several of the most common BAS controller networks used today include RS-485, Ethernet, attached resource computer network (ARCNET), and LonWorks.
RS-485. This network type was developed in 1983 by the Electronic Industries Association (EIA) and the Telecommunications Industry Association (TIA). The EIA once labeled all its standards with the prefix “RS” (recommended standard). An RS-485 network is a half-duplex, multidrop network, which means that multiple transmitters and receivers can exist on the network.
Ethernet: The Xerox Palo Alto Research Center (PARC) developed the first experimental Ethernet system in the early 1970s. Today, Ethernet is the most widely used local area network (LAN) technology. The original and most popular version of Ethernet supports a data transmission rate of 10 Mb/s. Newer versions of Ethernet called “Fast Ethernet” and “Gigabit Ethernet” support data rates of 100 Mb/s and 1 Gb/s (1000 Mb/s).
ARCNET: A company called Datapoint originally developed this as an office automation network in the late 1970s. The industry referred to this system as ARC (Attached Resource Computer) and the network that connected these resources as ARCNET. Datapoint envisioned a network with distributed computing power operating as one larger computer.
LonWorks: This network type was developed by Echelon Corporation in the 1990s. A typical node in a LonWorks control network performs a simple task. Devices such as proximity sensors, switches, motion detectors, relays, motor drives, and instruments may all be nodes on the network. Complex control algorithms, such as running a manufacturing line or automating a building, are performed through the LonWorks network.
Controller Communications Protocol
A communications protocol is a set of rules or standards governing the exchange of data between BAS controllers over a digital communications network. This section describes the most common protocols used in a BAS.
BACnet: A data communication protocol for building automation and control networks is a standard communication protocol developed by the American Society of Heating, Refrigerating, and Air-Conditioning Engineers (ASHRAE) specifically for the building controls industry. It defines how applications package information for communication between different BAS. The American National Standards Institute (ANSI) has adopted it as a standard (ASHRAE/ANSI 135-2001).
LonTalk: An interoperable protocol developed by Echelon Corporation and named as a standard by the Electronics Industries Alliance (ANSI/EIA-709.1-A-1999). Echelon packages LonTalk on its “neuron chip,” which is embedded in control devices used in a LonWorks network.
Proprietary RS-485: The protocol implemented on the RS-485 network is usually proprietary and varies from vendor to vendor. The Carrier Comfort Network (CCN) is an example of a proprietary RS-485 communications protocol.
Modbus: In 1978, Modicon developed the Modbus protocol for industrial control systems. Modbus variations include Modbus ASCII, Modbus RTU, Intel® Modbus RTU, Modbus Plus, and Modbus/IP. Modbus protocol is the single most-supported protocol in the industrial controls environment.
TCP/IP: Transmission Control Protocol/Internet Protocol (TCP/IP) is a family of industry-standard communications protocols that allow different networks to communicate. It is the most complete and accepted enterprise networking protocol available today, and it is the communications protocol of the Internet. An important feature of TCP/IP is that it allows dissimilar computer hardware and operating systems to communicate directly.
ENTERPRISE-LEVEL HARDWARE AND SOFTWARE
Client Hardware and Software
Normally, a personal computer (PC) workstation provides operator interface into the BAS. The PC workstation may or may not connect to a LAN. If a server is part of the BAS, the PC workstation would need LAN access to the server data files and graphics. Some smaller BAS use standalone PCs that have all the BAS software and configuration data loaded on each PC. Keeping the configuration data and graphics in sync on each PC becomes problematic with this design.
A graphical user interface (GUI) is one of the client-side software applications that provide a window into the BAS. The GUI usually includes facility floor plans that link to detailed schematic representations and real-time control points of the building systems monitored by the BAS. The GUI allows technicians to change control parameters such as setpoints and time schedules, or to override equipment operations temporarily. Other client-side software applications include the following:
• Alarm monitoring
• Password administration
• System setup configuration
• Report generation
• Control-unit programming and configuration.
Server Hardware and Software
Servers provide scalability, centralized global functions, data warehousing, multiuser access, and protocol translations for a midsize to large BAS. Servers have become more prominent in the BAS architecture as the need has grown to integrate multivendor systems, publish and analyze data over an intranet or extranet, and provide multiuser access to the BAS. While having a central server on a distributed BAS may seem contradictory, in reality, a server does not take away from the standalone nature of a distributed control system. Servers enhance a distributed control system by providing functions that applications cannot perform at the controller level. In fact, a BAS may have several servers distributing tasks such as Web publishing, database storage, and control system communication.
Servers provide the ability to control a BAS globally. Facilitywide time scheduling, load shedding, and setpoint resets are examples of global functions a BAS server can perform. Because these types of functions are overrides to the standard BAS controller-level programs, having them reside in the server requires that steps be taken to ensure continued control system operation should the server go down for any length of time. The distributed BAS should have the ability to “time out” of a server override if communications with the server is lost. When the server comes back online, the BAS should have rules that govern whether the override should still be in effect, start over, or cancel. Servers also can perform computational tasks, offloading this work from the BAS control units.
BAS DESIGN ISSUES
Aside from the impact that IT will have on future EMS, there are some fundamental characteristics that owners have always desired and will continue to desire from a BAS:
• Having a single-seat user interface
• Compatible with existing BAS
• Easy to use
• Easily expandable
• Competitive and low cost
• Owner maintainable.
There have been several changes made by the BAS industry to help satisfy some of these desires. The creation of “open” protocols such as LonWorks and BACnet has made field panel interoperability plausible. The development of overlay systems that communicate with multiple BAS vendor systems has made a single-seat operation possible. However, each has introduced its own levels of difficulties and additional cost.
Users that master their BAS are more likely to be successful than users that delegate the responsibility to someone else. The BAS vendor should be a partner with the owner in the process, not the master.
New-Facility BAS Design
There are two strategies available for the design and specification of BAS for new facilities:
1. Specifying a multivendor interoperable BAS
2. Standardizing on one BAS manufacturer’s system.
Specifying a multivendor interoperable BAS is probably the most popular choice among the facility design community. The engineer’s controls design is more schematic and the specifications are more performance based when this approach is used. In other words, the engineer delegates the responsibility of the detailed BAS design to the temperature controls contractor because the engineer does not actually know which BAS vendor will be selected. Even if only one BAS vendor was selected, it is very rare that the engineer would be intimately knowledgeable with this system anyway. Therefore, the resulting BAS design is by nature somewhat vague and entirely performance based. The key to making this approach successful is in the details of the performance specification, which is not a trivial task. Competition results from multiple BAS vendors bidding on the entire BAS controls installation.
The second approach is based on standardizing on one BAS manufacturers system. To create competition and keep installation cost low, the engineer must create the BAS design as part of his or her design documents and prescriptively specify all components of the BAS. This allows multiple temperature control contractors to bid on the BAS installation (wire, conduit, and sensor actuators)— everything outside of the BAS field panel. Everything inside the BAS field panel is owner furnished. Contractors familiar with the owners’ BAS, or the owners’ own technicians, perform the controller wire termination, programming, and startup. This approach is successful when all parties work together. The design engineer must produce a good BAS design. The temperature controls contractor must install the field wire, conduit, sensors, and actuators properly. Finally, the BAS contractor must terminate and program the BAS panel correctly. A successful project is a system that integrates seamlessly with the owners’ existing BAS.
Upgrading an Existing BAS
Most users already own and operate a legacy BAS that they might desire to upgrade from a standalone BAS to a network-based system.[2] The benefits of a network-based BAS appear as better standard operational practices and procedures, opportunities to share cost-savings programs and strategies, and wider access to building control processes. The key to justifying the costs associated with networking a BAS is that it can be done at a reasonable cost and is relatively simple to implement and operate.
There are three main strategies available when upgrading a BAS from a standalone system to a network-based system:
1. Remove the existing BAS and replace it with a new network-based BAS.
2. Update the existing BAS with the same manufacturer’s latest network-based system.
3. Install a BAS interface product that networks with an existing BAS.
The first upgrade strategy is simply to replace the existing BAS with a newer network-based BAS that has been established as a standard within your company. The cost for this option is solely dependent on the size of the BAS that will be replaced. However, this approach might be justified if the existing BAS requires high annual maintenance costs or has become functionally obsolete.
The second upgrade strategy available is to contact the original BAS manufacturer and request a proposal for its upgrade options. Most BAS manufacturers have developed some form of Ethernet network connectivity. Typically, some additional hardware and software is required to make the system work on an Ethernet network. The cost for this might be very reasonable, or it could be very expensive. It all depends on how much change is required and on the associated hardware, software, and labor cost to make it all work.
The third upgrade strategy involves the installation of a new network-based system that is specifically designed to interface with different BAS systems. These systems typically have dedicated hardware that connects to the BAS network and software drivers that communicate with the existing BAS controllers. The new BAS interface controllers also have an Ethernet connection so they can communicate on the corporate LAN. Users view the BAS real-time data by using Web browser software on their PC. The advantage of this strategy is that a multitude of different BAS systems can be interfaced. The disadvantage is that the existing BAS software must still be used to edit or add new control programs in the existing BAS field controllers.
FUTURE TRENDS IN BAS
The future of DDC in BAS can be found on the Web. Most BAS manufacturers see the need to move their products to the Internet tremendous economies of scale and synergies can be found there. Manufacturers no longer have to create the transport mechanisms for data to flow within a building or campus they just need to make sure their equipment can utilize the network data paths already installed or designed for a facility. Likewise, with the software to display data to users, manufacturers that take advantage of presentation-layer standards such as Hypertext markup language (HTML) and Java can provide the end user a rich, graphical, and intuitive interface to their BAS using a standard Web browser.
So where do we go from here?
Faster, Better, Cheaper
Standards help contain costs by not reinventing the wheel every time a new product is developed or brought to market. While there is a risk of stagnation or at least uninspired creativity using standards, Internet standards have yet to fall into this category, due to the large consumer demand for rich content on the Internet. A BAS, even at its most extensive implementation, will use only a tiny subset of the tools available for creating content on the Internet.
When a BAS manufacturer does not have to concentrate on the transport mechanism of data or the presentation of that data, new products can be created at a lower cost and more quickly. When the user interface is a Web browser, building owners can foster competition among manufacturers because each BAS system is inherently compatible with any competitors at the presentation level. All that separates one BAS from another in a Web browser is a hyperlink.
Another area where costs will continue to fall in using Internet standards is the hardware required to transport data within a building or a campus. Off-the-shelf products such as routers, switches, hubs, and server computers make the BAS just another node of the IT infrastructure. Standard IT tools can be used to diagnose the BAS network, generate reports of BAS bandwidth on the intranet, and back up the BAS database.
Owners will reap the benefits of Internet standards through a richer user interface, more competition among BAS providers, and the ability to use their IT infrastructure to leverage the cost of transporting data within a facility.
The Enterprise
Extensible markup language (XML): XML is an Internet standard that organizes data into a predefined format for the main purpose of sharing between or within computer systems. What makes XML unique is that data tags within the XML document can be custom or created on the fly and, unlike HTML tags, are not formatted for presenting the data graphically. This makes XML a great choice for machine-to-machine (M2M) communication.
Why is M2M so important? Because the next wave of BAS products will include “hooks” into other Internet-based systems. Building automation systems have done a great job of integrating building-related components together. BACnet, LonWorks, and Modbus provide the capability of connecting disparate building components made by different manufacturers, so that a lighting control panel can receive a photocell input from a rooftop building controller or a variable-frequency drive can communicate an alarm on the BAS when a failure occurs.
The future will require a BAS to connect to enterprise-level systems, not just building-level systems. This is where M2M and Web services come into play. Web services can be thought of as plug-ins allowing a BAS to communicate with a Web-based system or server. An example of this would be time synchronization. The Internet has many time servers that can provide the exact local time as well as greenwich mean time (GMT). A BAS can have a Web service that would plug into the BAS, synchronizing all of the time clocks within a facility with the atomic clock in Boulder, Colorado. Another example would be obtaining the outside air temperature from the local weather service. Instead of the BAS just measuring the outside air temperature at a local controller, a Web service could provide the outside air temperature, humidity, barometric pressure, and any other weather-related data. Now the BAS can make more intelligent decisions on using outdoor air for comfort cooling, determining wet-bulb setpoints for cooling towers, or even announcing that a storm is imminent.
More enticing than connecting to weather and time servers is the promise of connecting to a facility’s enterprise data. The BAS of the future must become an integral part of the decision-making for allocating personnel, budgeting maintenance and upgrades, purchasing energy, and billing those that use the energy. Most larger facilities have departments that provide these types of services, yet the BAS has always stood alone, providing input through exported reports, system alarms, or human analysis. Enterprise-level integration would create Web services to connect directly to these systems, providing the data necessary for making informed decisions about capital investments, energy, or personnel. See Fig. 1 for what a BAS might look like in the future.
The good news is that XML and Web services have gained market acceptance to become the standards for enterprise-level connectivity. The bad news is that this is still in its infancy for most BAS vendors. It is a very costly effort to create an enterprise-level Web service today. Even though Web services are supported by Microsoft Corporation, Apple Computer, Sun Microsystems, and others, they can still be custom solutions tailored to a specific accounting, maintenance management, or energy procurement system. For Web services to become mainstream in the BAS world, common services will need to be created that can be used by all BAS vendors. In addition, for Web services to be implemented properly in facilities, the skill set for BAS programmers and installers will need to include XML and a basic understanding of IP. If facility managers and technicians are to be able to make changes, adjustments, and enhancements to their enterprise system, they too will require this skill set.
Fig. 1 Future building automation systems (BAS) network schematic.
The future will also need to better define the decision logic and troubleshooting tools when implementing Web services. When the BAS sends duplicate alerts to a maintenance management system, where does the logic reside to send only one technician to the trouble call? This is currently undefined. Standard tools for testing scenarios online and offline need to be developed. Even though Web services typically rely on XML, which is a self-documenting standard, XML can be very verbose. Tools need to be created to help technicians discover and correct errors quickly. When a facility decides to change its accounting system to a newer version or a different vendor, will the BAS be able to adapt? Conversion and upgrade tools need to also be considered when defining BAS Web services.
Even without all the tools identified, enterprise-level connectivity is moving ahead rapidly. The benefits of integrating BAS data within a facility’s other systems can outweigh the immediate need for a complete set of tools. Web services through XML place the BAS directly into the facility data infrastructure. That’s a good place to be for an energy manager wanting to maximize the investment in a facility’s BAS.
CONCLUSION
The BAS of old relied heavily on a collection of separate systems that operated independently, often with proprietary communication protocols that made expansion, modification, updates, and integration with other building or plant information and control systems very cumbersome, if not impossible. Today the BAS is expected not only to handle all of the energy- and equipment-related tasks, but also to provide operating information and control interfaces to other facility systems, including the total facility or enterprise management system.
Measuring, monitoring, and maximizing energy savings are fundamental tasks of all BAS, and are the primary justification for many BAS installations. Improving facility operations in all areas, through enterprise information and control functions, is fast becoming an equally important function of the overall BAS or facility management system. The Web provides the means to share information more easily, quickly, and cheaply than ever before. There is no doubt that the Web is having a huge impact on the BAS industry. The BAS of tomorrow will rely heavily on the Web, TCP/IP, high-speed data networks, and enterprise-level connectivity. If you have not done so already, it is a good time for energy managers to get to know their IT counterparts at their facilities, along with those in the accounting and maintenance departments. The future BAS will be here sooner than you think. Get ready—and fasten your seat belts!
