RTC Magazine

A building automation system can save money by lowering labor, power and other costs. It can also enhance occupants’ enjoyment of the space through optimized climate control, a more secure environment, etc. This translates into potential economic benefits of higher rents and/or a lower vacancy rate. When asked why a building automation system has not been installed, an owner will typically point to one obstacle: cost. This cost typically stems from three sources: hardware, installation and integration. The price of hardware has fallen in recent years, so specialized labor generally accounts for the largest share of deployment cost.

New wireless technologies offer breakthrough savings on installation and maintenance, but bring their own troubles. In particular, new protocol support demands integration and human intervention for interoperability between devices and networks. Current solutions to protocol integration, such as Tridium’s Niagara AX or Schneider’s TAC Vista, rely on a central, shared platform in the form of a dedicated server or networking device. This approach works best for large implementations that can justify up-front costs of setup, software licensing and dedicated hardware. It leaves an underserved market of properties that require small-scale, retrofit/expansion and local deployments of wireless building automation systems.

If we assume that building automation systems will leverage the benefits of wireless communication, then we must ask what protocol(s) best delivers the needed reliability, interoperability and flexibility? What combination of network architecture, hardware and software is ideal, given limited capital budgets and lack of dedicated system administration staff in smaller-scale deployments?

From this examination, a picture emerges of building automation that is radically different from the current approach. A key part of the solution is decentralization, with system “intelligence” devolved to controllers. Another guiding idea is embedded—all formerly server-based functions, including control, communication, protocol integration and even data management, are incorporated within controllers’ real-time software. Another characteristic is multi-protocol, with the system leveraging the best features of heterogeneous standards (namely ZigBee, EnOcean, CANbus and BACnet/IP).

The Challenge: Control System Functions

Conceptually, a Control System performs four functions: data management, communication, control and “intellectualization,” as shown in Figure 1. Data management involves storing and retrieving data for internal (network) and external (user) needs, and presenting selected data to users. This is typically performed by a server-based database and client software. Local data storage at the controller level is generally limited to control variables. Communication implies data exchange between network components as well as between networks. Dedicated networking devices manage communications and are overseen by the server. Interconnection between networks and/or protocols may involve additional dedicated equipment (bridge, bus) or software. Control is performed at the field level. Dedicated controllers are used to implement command strategies and interact with the physical world. And finally, intellectualization is the “intelligence” needed by a system to solve, interpret or otherwise translate inputs into a command or an action.

A Control Network also traditionally combines multiple “control levels,” each requiring a different type of equipment. A typical architecture calls on three general types of equipment:  server, networking and controller. Figure 2 illustrates several of the major cost factors in traditional building automation. First, all those varied pieces of hardware must be purchased! Second, skilled personnel are needed to make devices talk to each other by wire or wirelessly. Note that the control functions shown in Figure 1 are spread out across the different levels and devices of Figure 2. Data management “lives” on the server. Control resides within the controller. With every new deployment, integration must take place both within the communication function (cross-network / cross protocol integration) and between functions (network / device integration).

Figure 1
Functions performed by a Control System

Figure 2
Figure 2: A control network’s multiple levels

Yet another implied cost in Figure 2 is bandwidth. Most existing controllers are dumb, relying on round trips to the server or PLC for changes in variables and any other “intelligence.” Protocol integration is performed on the server, so that system functions requiring interoperability must communicate through this central point. Bandwidth demands can quickly overwhelm the resources offered by ZigBee and other wireless personal area network (WPAN) standards.