For many of us involved day to day with the design, installation, and operation of BAS, it often seems like there has been little in terms of new products and innovation. But, if we step back and look at it from a broader perspective, there are actually a series of dramatic changes underway that are leading us to the next generation of building control systems. This next generation has the potential for improved control and efficiency and also to serve as a data source to enable improved decisions on facility operation and optimization. This evolution will ideally provide for systems that are more effective while being more secure and can help alleviate many of the potential cybersecurity risks that may exist in today’s installations. 


Transition to Internet Protocol (IP) Controls

For many years, the “typical” architecture for most BAS installations has had PC workstations, servers, and a few building level controllers that were installed on an Internet Protocol (IP) network. The rest of the controllers were then connected to a dedicated field bus, such as BACnet MSTP or LonTalk FTT-10.

A few years ago, vendors started offering the option to connect more powerful controllers, such as those used to control air handlers and chiller plants, with an option to connect on an IP or field bus. This resulted in systems that had much faster performance and were more “IT friendly.” See Figure 1.

FIGURE 1. A typical BAS controls architectureFIGURE 1. A typical BAS controls architecture.


Vendors are now tackling the challenge of moving smaller, less expensive terminal unit controllers onto the IP network, allowing for installations that are all network connected. There have been several challenges to this latest transition. First, the cost to make a device IP-capable used to be very high. Today, that is no longer the case as the cost of processing and communications has dropped, largely driven by the development of mass-market Internet of Things (IOT) products.

Second, the cost to connect controllers to an IP network is too expensive compared to the cost of a conventional field bus. The reason for this is that most networks utilize architecture where all network devices are connected by homerun wiring to a dedicated network switch port. Locating network switches out in the space can reduce the cost of this homerun wiring, but it is still a complicated and expensive solution as compared to the low cost of daisy chain field bus architectures. Vendors have found several clever solutions to provide IP-connected controllers at a cost that is competitive with field bus. See Figure 2 for an example of an integrated architecture. These include:

A typical integrated architectureFIGURE 2. A typical integrated architecture. Courtesy of Pacific Northwest National Laboratory.


  • Wi-Fi connections — The use of a Wi-Fi-connected terminal unit controller eliminates the need to connect a network cable. However, the use of Wi-Fi does require some additional setup and configuration and can raise concerns about cybersecurity.

  • Dual switch port controllers — Most of the new IP-enabled controllers come with an embedded Ethernet switch as part of the controller. Two ports are provided to plug in network cables, and a third port connects the controller to the network. Some vendors have designed these switches so that they can continue to connect the switch ports even when the controller is not powered. System designers and integrators are now able to select several approaches on how to design a network to accommodate these controllers. Options include:

  • Star topology — Utilize a traditional hub and spoke network with a dedicated cable from a network switch port to each controller. This leaves the second port available for a technician to plug in a laptop or service tool to access the system. The star topology is considered the most reliable and secure option, but it is also the most expensive since it typically requires more switches and cabling. Note that this is the only option that also supports the use of power over ethernet (POE).

  • Daisy-chain topology — Connect the controllers one to the next in a daisy-chain architecture, using a network cable that goes between every two controllers. This approach dramatically reduces the cost of cabling and the number of network switches; however, it also introduces a risk that a broken cable or controller failure could cause communications to fail. To help reduce this risk the system can be installed using spanning tree protocol (STP)-compliant network switches (IEEE 802.1D). STP controllers are installed in a loop with the first controller connected to a network switch on one port and to the next controller from the second port. The final controller in the chain is then connected back to a second designated port on the network switch. The use of STP provides the logic to first recognize that this is not a loop (which is not a good thing in networking) as well as how to recognize a network break in one direction and automatically reroute in using the alternate connection.

See Figure 3 for an example of an STP architecture. While this approach is not fail proof, it should provide better reliability than MSTP at a competitive cost. Designers should also note that there are limitations on both the number of controllers that can be daisy chained and the maximum length of the cables.

A typical spanning tree protocol connection. Courtesy of Distech ControlsFIGURE 3. A typical spanning tree protocol connection. Courtesy of Distech Controls.


  • POE — The same cable that provides for network communications also has the ability to carry a small amount of DC power. This solution, called POE, has long been used to power IP phones and network access points. This same solution has now been extended for use in lighting control (and some fixtures) as well as on some BAS terminal controllers. Utilizing POE has the advantage of not needing to run both power and communications, lowering the installation cost. The drawback with POE is that it requires special network switches and has a very limited power capacity (note that the original POE standard was limited to 15 watts, while new proposed variations can go as high as 100 watts). POE should also only be applied in hub-and-spoke architecture and not with daisy-chained controllers.


Cyber Secure Systems

As control systems become more network-enabled, they’re also at a heightened risk and become targets for cyberattacks. Attackers  could attempt to use a building control system as an entry point into other systems or to override functionality either for malicious control or for ransom. Fortunately, so far, there have been few successful attacks on building control systems. This is an area of risk, and as we move to more connected systems, the risk becomes even greater.

There are several options that control system designers and integrators need to be using to mitigate these risks.  Many of these are documented in the “best practices” that most BAS vendors provide. This includes commonsense approaches, such as the use of a dedicated operational technolgy. (OT) network, using the network to protect communications (called a VLAN), and changing default passwords.

The longer term solution involves the use of encrypted communications for control systems, and there is work underway in ASHRAE to develop a new option for BACnet that features secure communications. The proposed approach will provide a method to encrypt and secure BACnet communications with the use of the same technology that is already in place for tasks such as online banking. This approach should also simplify the challenge of getting approval to place BACnet devices onto enterprise networks, since their communication will be similar to other network connected devices. The ASHRAE BACnet  committee has developed a draft document that was put out for public review earlier this year. Secure communications is expected to become part of BACnet soon. Several vendors have indicated that they intend to support this new option for their BACnet products shortly after it is approved. Adding secure communications to an existing system will require, at minimum, a software update and additional configuration, but for older systems, it may also require hardware updates as well.


Network Design Challenges

When we only had a few devices in a building connected to a network, there was little reason to focus on the network design. It was adequate to specify a basic Ethernet switch or to state that the network ports would be provided by the owner’s IT group. The movement toward systems that are all IP, and be cybersecure, requires special attention to how the network is designed starting with a decision if it should be a standalone (often called an air-gapped network) OT network, converged on an enterprise network, or hybrid with a firewall between the OT and IT networks. If the design is primarily on the owner’s IT network, then the control system designer will need to coordinate closely with the network designer and/or the owner’s IT group. If it is a standalone OT or hybrid system, then it will require a detailed design including selection of switches, cabling methodology, and configuration details. Many vendors and integrators are working on enhancing their skills in networking, but this transition does have some technical challenges that need to be addressed.


Improved System Performance

Commercial building control systems are often designed and deployed to operate in a manner that is less than optimal in terms of efficiency. There are many efforts underway to help designers, contractors, and owners achieve improved system performance. Here is a summary of these efforts:

  • ASHRAE Guideline 36 “High Performance Operation of HVAC Systems” — This is an effort from ASHRAE to develop recommended optimal sequences for selected systems. The first version of the guideline was published earlier in 2018 and provides sequences specific for air handlers and VAV systems. The process included not only industry experts but also research projects to verify the sequences. The document includes an explanation of the recommended sequences as well as suggested points for alarming and fault detection and diagnostics. Future releases of this guideline are anticipated to include additional systems such as chiller plants. Guideline 36 is an invaluable tool for system designers to use to improve how they specify control sequences. It’s also likely that in the future vendors will be able to offer products and systems that are designed around the sequences in the guideline.

  • Advanced research projects — There are a series of research projects underway to provide for open source tools for advanced design of control sequences as well as new methods to set up and optimize building systems. This work is taking place in the U.S. Department of Energy (DOE) National Labs with federal and state funding. One example is the “Open Building Control” project, which is developing a tool that can be used to model control sequences to evaluate their efficiency and then to communicate the sequence to the contractor in an electronic format that can readily be translated and downloaded into a controller. This will ideally allow for improved design as well as reduced cost and complexity of programming and documenting systems.

The initial library for this project will be supporting the sequences from ASHRAE Guideline 36 and will be able to be extended to cover other standard and custom sequences. Other projects such as adaptive control for building energy efficiency are focused on the use of artificial intelligence and machine learning to automatically determine the optimal operating parameters for a control system as well as improved methods for fault detection and diagnostics.

  • Semantic tagging — One of the big challenges for control systems is being able to understand the relevance of the data. For example, if we have a point called “room temperature,” what does that mean? What room is it? What are the units? Is it above or below set point? For most systems, these questions can be answered by the operator’s experience, often with support of system tools such as graphics. But if we want to use this data for other purposes, such as fault detection, diagnostics, analytics, maintenance, or optimization, then having better documentation of the semantics is crucial.

There are several efforts underway to help develop solutions for semantic tagging. This includes the work done through Project Haystack. ASHRAE is now working on developing a standard for semantic tagging that will be coordinated with several industry efforts and will also connect in with BACnet. Systems that are designed with semantic tags are easier to configure and program and can readily provide information to other necessary building services making the BAS more valuable over time.



The changes that are occurring with commercial building control systems, in many ways, seem like they are incremental and not revolutionary. But, taken together, they are  enabling a dramatic  transition of BAS from being just a control system to being a system that both provides controls and also serves up data that can be used for other critical  functions. This will help building owners accomplish improved efficiency, comfort, and reliability as well as a reduced overall cost of ownership.



Back To Top