How building automation, controls help HVAC systems

Learn how buildings can become smarter using building automation systems and building controls

By Ionel Petrus, PE, CEM, LEED AP BD+C, SmithGroup, Washington, D.C. November 17, 2022
Figure 1: BACnet device profiles. Courtesy: SmithGroup

 

Learning Objectives

  • Understand what BACnet, ASHRAE 135 and the BACnet Standard are.
  • Identify what may help a building be classified as a smart building or a green building.
  • Review a building automation example.

Building automation insights

  • Smart buildings and building automation have become an important part of having an efficient building.
  • ASHRAE 36 — a guideline for HVAC operations — is meant to help encourage the standardization of certain operations across all buildings, with the exception of residential buildings.
  • An important part of improving efficiency is using fault detection to discover inconsistencies with operations and fix them.

The technological advances in the heating, ventilation and air conditioning industry over past two decades has helped building systems operate in a more energy-efficient manner. There is no shortage in the building industry of buzz words such as “smart buildings” or “green buildings.”

However, it is important to note that, regardless how energy-efficient a building is, if the building is not a net zero building, then the systems within that building will still use energy and, in many cases, significant amounts of energy. The latest draft version of the 2018 Commercial Buildings Energy Consumption Survey issued by the U.S. Energy Information Administration states that since 2012,

 “The number of buildings has grown by 6% and floorspace by 11% and newer buildings are larger, on average, than older commercial buildings. The total energy consumption by the residential and commercial sectors includes end-use consumption and electrical system energy losses associated with retail electricity sales to the sectors. When electrical system energy losses are included, the residential and commercial sectors accounted for about 21% and 18%, respectively — 39% combined — of total U.S. energy consumption in 2021.”

Also, per EIA, “… in 2021, renewable energy sources accounted for about 12.2% of total U.S. energy consumption and about 20.1% of electricity generation.’”

This imbalance between the amount of renewable energy being generated in the U.S. and the total energy being used by residential and commercial building will continue to have a significant negative impact on the environment. It is important to note that a net zero building is not a building that uses no energy; a net zero building is a building that, on an annual basis, uses an energy amount that is less than or equal to the amount of renewable energy that it produces onsite.

Although design engineers and building owners strive to design and install energy-efficient HVAC equipment (i.e., chillers, heat pumps, etc.) and lighting fixtures, just by having this efficient equipment in a building it is not an indication that the building will be an energy-efficient building. Providing a building with energy-efficient equipment could be considered as a first step toward having an energy-efficient building; the building automation system plays a crucial role in the overall energy consumption levels of a building.

Up until the late 1980s and, on rare occasions, through the early 90s, the HVAC controls system in a commercial building was mostly pneumatic based. This type of pneumatic based control was, in its most simplistic form, an on/off type of a control system in which pumps and fans were left “riding their curves” based on the load. Variable frequency drives and implicitly, the concept of varying the speed of a pump moor or a fan motor based on the load was a relatively novel concept in the HVAC industry and one of the reasons behind this was the relatively high total cost of a VFD.

Similarly, the concept of having a building engineer receive alarms and notifications by the BAS was in its early stages. Looking back at these antiquated methods of controlling and operating building systems, one could assume that building systems could have performed better and use less energy.

The advent of direct digital control systems in the mid-80s and the publication of the BACnet Standard for building automation and control system networks, ANSI/ASHRAE 135-1995 provided the building industry with the potential and tools for reducing the amount of energy that is being used by building systems.

BACnet, known as a building automation and control network, is a BAS communication protocol developed by ASHRAE. The standard is continuously maintained by the ASHRAE SSPC-135 committee.

It is common for building DDC systems to talk with the cloud and with myriad apps, each marketed with various promises to support the sustainability of the building, provide better control over the environment in the building and, for building engineers and commissioning professionals, to provide more information (i.e., alarms, trends, diagnostics, energy performance, etc.) about the operation of the building systems.

Smart buildings and building automation

Are smart buildings automatically energy-efficient buildings? What makes a building smart? A simple web search of this terminology shows as many definitions as there are web links in the results page.

For example, a provider of internet of things devices may define a smart building as “a building that uses IoT devices to monitor various building characteristics, analyze the data and generate insights around usage patterns and trends that can be used to optimize the building’s environment and operations.”

Similarly, a provider of information technology networks may define a smart building as a building that “converges various buildingwide systems — such as HVAC, lighting, alarms and security — into a single IT managed network infrastructure.”

Adapting a widely used saying to the industry, we could infer that what makes a building smart is in the mind of the beholder. The same could be inferred when using the term energy-efficient building; to establish that a building is energy-efficient, we need to clarify what deficient baseline (i.e., reference) has been used to make the determination that a building is indeed energy-efficient.

Designing a smart building might be an effort that could start with a set of general requirements set by the building’s owner, while recognizing that an energy-efficient or net zero building does not necessarily mean that the building needs to be a smart building. Similarly, designing a smart building does not mean that the building is an energy-efficient building.

A couple of examples of a type of broad performance requirements set by the building’s owner regarding what constitutes a smart building could be as follows:

BAS shall use the BACnet communication protocol and shall use smart sensors and actuators. The BAS sequences of operation shall be based on ASHRAE Guideline 36: High-Performance Sequences of Operation for HVAC Systems.

BAS shall use the BACnet communication protocol, use edge control devices and be connected to the cloud. The BAS sequences of operation shall be based on the ASHRAE Guideline 36. The data from the building automation system shall be used by cloud-based applications such as analytics, anomaly detection and artificial intelligence algorithms for the control of building systems

The BAS shall be integrated with the building lighting control system such that information related to occupancy levels, occupancy detection and lighting levels is shared between the two systems. The BAS shall then monitor and control the HVAC system based on the actual occupant load and lighting levels in the building with the overall intent of reducing the energy consumption of the HVAC systems by minimum 25% when compared with the energy consumption levels of the same HVAC systems when the referenced information is not shared between the BAS and the building lighting controls system.

The overall intent behind the use of the BACnet Standard as a performance requirement is to provide the potential controls contractor(s) with a clear and concise set of requirements that must be met by any manufacturer of controls devices. It will not matter to an owner who makes the controls device for a lighting controls system and for an HVAC control system, as long as controls devices carry a BACnet listing, said devices will speak the same language.

How to design a building automation system

Figure 1: BACnet device profiles. Courtesy: SmithGroup

Figure 1: BACnet device profiles. Courtesy: SmithGroup

The BACnet Standard defines eight profiles for controls devices, as shown in Figure 1; the first three devices are typically used to access the entire BAS via a graphical user interface. Out of the first three device profiles, the BACnet advanced operator workstation is the most robust; a B-AWS provides the user with a complete engineering tool for the monitoring and configuration of the BAS and any systems (e.g., HVAC, lighting, etc.) controlled by it; consider the B-AWS as a computer provided with a relatively easy to use GUI.

Further, the B-AWS and its tools allows for future system changes under proper password protection including dynamic creation, deletion and modification of all configuration parameters, programs, graphics, trend logs, alarms, schedules and every BACnet object used in the installed system.

For each device profile, the ANSI/ASHRAE 135 standard defines a minimum set of requirements that the device must meet to be formally listed as a BACnet device. It is important to note the difference between BACnet “listed” control devices and BACnet “compatible” control devices. The fact that various manufacturers may claim that their product is BACnet compatible, it does not mean that said control device is also a BACnet listed device. At best, the claim may mean that the control devices can communicate with other BACnet devices.

For a control device to be BACnet listed, it must carry the BACnet Testing Laboratories stamp, which is an indication that the device has been tested by a BACnet certified laboratory and certified under the BTL Certification Program. The BTL website maintains a public list of all BACnet listed control devices.

Each BACnet listed device is required to be provided with protocol implementation conformance statement, which is a document that describes the options specified by BACnet that are implemented in the device.

Figure 2: Sample BACnet network diagram. Courtesy: SmithGroup

Figure 2: Sample BACnet network diagram. Courtesy: SmithGroup

A sample network architecture of a BAS based on the BACnet communication protocol is shown in Figure 2.

The BACnet master slave/token passing (MS/TP) communication protocol is a peer-to-peer, multiple-master protocol that shares data by passing a token, or permission to “speak”’ across the network, between control devices (masters) that authorizes the holder device to initiate communication on the MS/TP network; master devices send requests and slave devices submit responses.

Further, master devices can only request services from slave devices if they have an available token; if master device does not have a token, it must wait for a token to be passed on to it. This is one of the main reasons for an MS/TP network to become slow, in particular when there is a high number of devices (more than 50) on the same bus. The control devices on an MS/TP network are connected in series via shielded twisted pair cable and the communication speed across the network is typically limited to 0.1 MB per second.

Unlike the devices on an MS/TP network, the devices on a BACnet internet protocol network are connected via Ethernet cable and the network speed is typically greater than 100 MB per second.

A standard analog sensor (e.g., air temperature, chilled water temperature, etc.) can send an analog signal (typically resistance or volts) only to a BACnet control device. The control device then uses the analog signal for control of the HVAC equipment or shares (via BACnet communication protocol) the associated values from the sensor with the other BACnet devices. The same principle applies to standard actuators; they are typically controlled by a BACnet control device via a 0- to 10-volt signal or 4 to 20 milliampere signal.

Figure 3: Sample for protocol implementation conformance statement for a BACnet smart sensor. Courtesy: SmithGroup

Figure 3: Sample for protocol implementation conformance statement for a BACnet smart sensor. Courtesy: SmithGroup

Figure 3 shows a sample PICS for a BACnet smart sensor. The main difference between a BACnet smart actuator and B-SS and a standard analog or digital sensor or actuator is that the B-SAs and B-SSs are provided with a control board that allows them to be connected to a BACnet network and communicate with other BACnet devices on the network.

Lastly, but not less important, BACnet listed smart sensors and actuators are significantly more expensive than standard sensors and actuators, typically by an order of three or more.

Figure 4: Sample control diagrams using standard sensors/actuators and BACnet smart actuator/BACnet smart sensor. Courtesy: SmithGroup

Figure 4: Sample control diagrams using standard sensors/actuators and BACnet smart actuator/BACnet smart sensor. Courtesy: SmithGroup

Figure 4 shows two controls diagram for the same variable air volume box. In the diagram on the left of the figure, the control and monitoring of the VAV box and associated zone is done via standard analog and digital sensors and actuators while in the diagram on the right side of the figure, the control and monitoring of the VAV box and associated zone is done using a combination of standard analog and digital sensors and actuators and B-SS and B-SA.

ASHRAE Guideline 36

ASHRAE Guideline 36 is a repository of sequences of operation applicable to HVAC systems that are typically installed in most buildings, except residential buildings.

The intent of this guideline is to encourage engineers, contractors and building owners to use standardized sequences of operation that have been proven over time to be reliable and to operate systems in an energy-efficient manner. These proposed control sequences are sensor and actuator agnostic. In the context of this example, being sensor and actuator agnostic means that it does not matter if a building automation system is provided with standard sensors and actuators or with B-SAs and B-SSs; the outcome (i.e., the energy consumption of the building systems) will most likely be the same.

Referring back to the first example of broad requirements set by the building’s owner regarding what constitutes a smart building and assuming that the building HVAC systems are programmed to operate based on the sequences of operation defined in ASHRAE Guideline 36, what value will the owner get if the energy efficiency of the building will be the same, regardless of what type of sensors are being used? It may be that an owner may find the marketing aspect of using smart sensors as extremely valuable, in addition to the value of having an energy-efficient building. One could reasonably infer that the building by itself did not become smarter due to the use of BACnet listed B-SSs and B-SAs. Engineers and design professionals should inform the owners about any potential risks and benefits before recommending the use of B-SSs and B-SAs.

Figure 5: Sample BACnet network diagram with edge control devices. Courtesy: SmithGroup

Figure 5: Sample BACnet network diagram with edge control devices. Courtesy: SmithGroup

Figure 5 shows a sample BAS network architecture connected to the cloud. In this scenario, the local controllers, typically the BACnet application specific controllers are connected to the BAS network and also to the cloud. What makes these controllers edge controllers is the fact that they are located at the edge (periphery) of the BACnet network. These types of controllers are provided with significantly more capabilities (i.e., memory, processing speed, storage capacity, etc.) than typical B-ASC controllers; this is because they must be able to execute the standard proportional-integral-derivative loops required to control the associated HVAC equipment and, in the same time, must be able to respond to the requests (i.e., sending data) from the cloud-based applications.

An application programming interface is typically needed to facilitate the communication between the cloud-based applications and the edge controllers. An API can be viewed as a collection of software applications required to collect and prepare the data before sending it to the cloud-based applications. Although building automation systems are provided with the capability to store, trend data and provide alarms with the operator, anomaly detection applications are typically cloud-based. This is because they typically require more computational power (to execute various algorithms) that cannot be supported by typical BACnet building controllers.

Defining fault detection

Fault detection and diagnosis is the process of identifying or detecting deviations from normal or expected operation (faults) and resolving (diagnosing) the type of problem or its location.

Figure 6: Example of a simple anomaly in building automation system trends. Courtesy: SmithGroup

Figure 6: Example of a simple anomaly in building automation system trends. Courtesy: SmithGroup

Figure 6 shows an example of an anomaly in the operation of the VAV box shown in Figure 4. At a certain time during the day, the VAV box leaving air temperature has exceed an expected maximum value of 85°F. It is important note that the BAS also could issue an alarm once it detects this condition; however, in the case of a more complex scenario (as shown in Figure 7) the BAS may not be able to detect the anomaly.

Figure 7: Example of a more complex anomaly in the operation of a variable air volume box. Courtesy: SmithGroup

Figure 7: Example of a more complex anomaly in the operation of a variable air volume box. Courtesy: SmithGroup

In this scenario, even though the VAV box reheat control valve is almost fully open, the actual VAV box leaving air temperature is below an expected range. This may be an indication that either more airflow is going through the box than expected (even though damper is not as open) or the temperature of the water entering the coil is not as warm as expected, which, in turn, has caused a reduction in the heating capacity of the VAV box. The output from an anomaly detection software application may be a series of actions for the user to implement; the intent of said actions is to help the user determine the actual cause of the anomaly.

Anomaly detection applications can play a significant role in the operation of building HVAC systems; anomalies that go undetected can result in systems using more energy than expected. For example, an owner may use the output from a predictive energy model as a reference to predict future operating costs; anomalies (e.g., chiller plant uses 20% more energy than predicted) may negatively impact an owner’s cash flow models. Undetected anomalies can also affect the preventive maintenance efforts of the facilities team by reducing the useful life of equipment; this, in turn, may also negatively impact an owner’s cash flow models associated with the operation of the building.

An overview of the application of AI-based algorithms for the control of building systems is available in the article “Using artificial intelligence to control building systems.” Referring back to the second example of broad requirements set by the building’s owner regarding what constitutes a smart building, are analytics, anomaly detection and AI based applications enough to classify a building as being a smart building or a green building?

For this example, neither the BAS nor the other three types of applications (analytics, anomaly detection and AI-based algorithms) can help in identifying what caused an anomaly. Giving a building automation system user a series of actions to execute to find the cause of the anomaly is helpful, however implementing the actions takes time and, when the facilities teams is short-staffed, finding the cause of the anomaly and then fixing the issue may not prevent the building as a whole from running in an energy-inefficient manner for prolonged periods of time.

Figure 8: Limitations of standard applications. Courtesy: SmithGroup

Figure 8: Limitations of standard applications. Courtesy: SmithGroup

Identifying the cause behind an anomaly will most likely require the implementation of causal algorithms in addition to the three types of applications previously mentioned. AI Algorithms by themselves are not enough to make a building smart. Causal algorithms are not AI algorithms. AI algorithms take data input at face value; said algorithms assume that the input is correct (I.e., garbage in, garbage out). AI algorithms cannot determine if a portion of the training data is incorrect or if it includes anomalies. Causal algorithms are used to find the cause behind an anomaly, with minimal to no human intervention. Causal algorithms are extremely difficult to program at scale and the industry is just not there; my overall message with this article is that AI algorithms to control building systems are simply not enough to make a building smart and to minimize the impact on the environment. The industry needs to keep pushing for more advanced algorithms, i.e., causal algorithms.

Example building automation success

Figure 9: Causal discovery workflow. Courtesy: SmithGroup

Figure 9: Causal discovery workflow. Courtesy: SmithGroup

Causal algorithms are typically used in biomedical research to discover causal relationships from biomedical data. Causal models can be build using prior data or, in the case of building systems, data stored by the BAS. A sample process for causal inference is shown in Figure 9.

A causal model is typically build using a direct acyclic graph, aka DAG, which is a graph between a set of variables connected by arrows. A path in a directed graph is a nonrepeating sequence of arrows that have endpoints in common; in a DAG a variable cannot have a path toward itself.

Figure 10: Variable air volume box causal model. Courtesy: SmithGroup

Figure 10: Variable air volume box causal model. Courtesy: SmithGroup

Figure 10 shows a sample causal model for the VAV box shown in Figure 4; each variable in the DAG represents all historical values available at the BAS and filtered by a desired timeframe (i.e., the time interval starting with one hour before the anomaly as occurred and up to two hours, for a total of three hours). The purpose of the graph is to identify what may have caused the VAV box supply temperature to go outside of its expected range (the cause behind the anomaly). An arrow from one variable to another variable — from F1 to T1 — represents that F1 is a direct cause for T1.

For example, if the reheat valve doesn’t continue to open, an increase in airflow of the VAV box has a direct effect on the VAV box supply air temperature. The causal model also includes the air handling unit supply air temperature (variable T2), which has a direct effect on T1 and an indirect effect on T1 (via variable V1). The outcome from this causal model may be that the AHU supply temperature has changed unexpectedly. The causal algorithm will then create a new causal model of the AHU as whole to identify what may have caused the AHU supply air temperature to drop.

Causal models used with high-performing building automation systems (including analytics, anomaly detection and AI algorithms) have the potential to help facility operators better maintain the building systems and operate them in the most energy-efficient way possible and/or meet owner’s requirements.


Author Bio: Ionel Petrus is principal and mechanical discipline leader of the Washington, D.C., office of SmithGroup.