How to select a building automation system
Explore the specification of standard, open and proprietary building automation systems
- Learn how to specify standard building automation systems.
- Understand the differences and considerations when specifying open or proprietary building automation system.
- Become familiar with software, cybersecurity and communication issues.
A building automation system, often known as a building management system, is a computer-based control system installed in buildings that controls and monitors the building’s mechanical and electrical equipment such as ventilation, lighting, power systems, fire systems and security systems.
As such, a BAS may also include a variety of devices (e.g., controllers, chillers, fans, sensors, lighting controllers, lighting fixtures, heating, ventilation and air conditioning devices, etc.) configured to facilitate monitoring and controlling the building systems.
Considering the available options, specifying a BAS can be a daunting task, even for a seasoned engineer.
Unless a building owner has a specific requirement for a communication protocol, the engineer can select from three options: BACnet, Modbus and LonWorks. The focus of this article is on specifying automation systems that use a BACnet communication protocol.
A standard Construction Specifications Institute specification section has three parts:
- Part 1 — General.
- Part 2 — Products.
- Part 3 — Execution.
CSI master specification, known as MasterSpec, describes the performance requirements and network architecture of the BAS in Part 2 of the specification; however, said paragraphs could also be in Part 1 of the specification. Regardless of where these two main paragraphs are located (Part 1 or in Part 2), they are essential to having a complete and robust BAS specification.
The performance requirements paragraph describes the core requirements that a BAS vendor must meet to be allowed to bid the project. A sample introductory subparagraph may be:
“The BAS direct digital controls shall consist of native BACnet, microprocessor-based, peer-to-peer, networked, distributed devices using the BACnet communication protocol in an open, interoperable system. The BAS also includes operator interface devices, programming and configuration software applications, DDC input/output devices, non-DDC automatic temperature controls, enclosures and interconnecting conduit and wire. The BACnet operating stack must be embedded directly in every device at the board level and in all operator interface software packages.”
Similarly, it is important that all BAS controllers are tested, certified, clearly stamped and listed by the BACnet Testing Laboratories; this will allow the engineer to examine the protocol implementation conformance statement for details about the BACnet functionality that the controller can support.
Specifying building automation systems
It is important to note that most of the BAS vendors offer their controllers with preprogrammed generic sequences of operation, typically referred to as “canned sequences of operation.” These “canned” sequences are not necessarily preloaded on the controller, but are loaded during programming and system setup.
Although this approach may be suitable for simple BAS designs, most often than not the field technicians end up spending significant amounts of time editing the canned sequences to support the specific conditions of the project. An engineer may insert a paragraph in the specification that prevents a vendor from using canned sequences.
This paragraph could be:
“All BAS DDC devices at all levels shall be fully custom-programmable in the field using the standard operators workstation software. No configurable, canned program controllers will be permitted.”
Another performance requirement that should not be omitted from the specification is the behavior of all controllers upon startup after a loss of power. As such, it is important that the BAS prevents all controlled equipment from simultaneously restarting after a power outage. The order in which equipment (or groups of equipment) is started, along with the time delay between starts, should be user selectable.
Lastly but not less important, the specification should require that, at minimum, the BAS manufacturer natively supports the following BACnet data links as defined in the ASHRAE Standard 135-2016: A Data Communication Protocol for Building Automation and Control Networks:
- Master slave/token passing, known as MS/TP.
- Ethernet (ISO 8802-3).
- BACnet internet protocol.
In addition to ASHRAE Standard 135-2016, the engineer may also specify compliance with the following standards and guidelines:
- National Institute of Standards and Technology NISTIR 6392 Annex B: Profiles of Standard BACnet Devices.
- UL 916: Standard for Energy Management Equipment.
- UL 864: Standard for Control Units and Accessories for Fire Alarm Systems.
- Federal Communications Commission.
The engineer will need to be extremely careful when specifying compliance with UL 864, as this standard will add significant cost to a BAS. Typically, compliance with UL 864 is required when the BAS is used for the control and operation of smoke management systems.
Another important performance criterion that needs to be addressed in the specification is the speed of the BAS as whole. ASHRAE Guideline 13: Specifying Building Automation Systems references the following response time of connected I/O devices/sensors:
- Analog input point values connected to DDC system should be updated at least every five seconds for use by DDC.
- Binary input point values connected to DDC system should be updated at least every five seconds for use by DDC.
- Analog input points connected to DDC system shall begin to respond to controller output commands within two seconds.
- Binary output point values connected to DDC system shall respond to controller output commands within two seconds.
Specifying faster response times will most likely lead to additional cost being incurred by the project. Regarding the display of connected I/O devices, ASHRAE Guideline 13 recommends:
- Analog point change of value connected to DDC system should be updated and displayed at least every 10 seconds for use by operator.
- Binary point change of value connected to DDC system should be updated and displayed at least every 10 seconds for use by operator.
- Alarms of analog and digital points connected to DDC system should be displayed within 45 seconds of activation or change of state.
- Graphic display refresh should update within 8 seconds.
- Point change of values and alarms displayed from workstation to workstation when multiple operators are viewing from multiple workstations should not exceed the graphic refresh rate associated with each I/O.
The network architecture paragraph of the specification describes the primary components of the BAS. At minimum, this paragraph describes the following:
- BACnet advanced operator workstation software, known as B-AWS.
- Remote B-AWS.
- Portable operator workstation software.
- Building controllers.
- Building advanced application controllers.
- Building application-specific controllers.
In some instances, the owner may have a requirement for a web-based BAS or a web-compatible BAS. It is important to note that a web-based BAS is not the same as a web-compatible BAS. Under a web-based BAS, the operators have complete access to the BAS via a web browser. No special software other than a web browser should be required to access graphics, point displays and trends; to configure trends, points and controllers; and to edit programming. Under a web-compatible BAS, the operators, using a standard web browser, are typically able to access control graphics and change adjustable set points.
Typically, a BAS is comprised of two networks: an enterprise-level communication network and a building-level communication network. The enterprise-level communication network typically consists of high-speed BACnet/IP local area network to host operators workstations, building controllers, building-level communication networks and web-enabled remote connectivity. The building-level communication network typically consists of a BACnet internetwork to host field-level DDCs.
Understanding the BAS platform
Part 2 of the specification typically includes the performance requirements for all hardware, software, sensors and actuators that will be a part of the BAS, including the performance requirements for the BAS controllers and the operator workstation.
The B-AWS platform provides complete configuration, monitoring, modification and operation of the entire DDC system by advanced building operators and technicians; it typically resides on the enterprise-level communication network. In addition to specifying the hardware requirements for the B-AWS, the engineer will also need to specify the software requirements.
Typically, the B-AWS is provided as a complete engineering tool for the configuration of the system; this approach will allow 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.
Further, the engineer should require that the BACnet advanced operator workstation software shall comply with the minimum requirements of ASHRAE Standard 135 for a B-AWS and shall be certified and listed by the BACnet Testing Laboratories as a B-AWS.
BACnet building-level controllers typically are used to control major mechanical equipment (e.g., chilled water plants, heating hot water plants, large air handling units, etc.) and execution of BAS global strategies for the BAS based on information from any object in the internetwork. Building-level controllers typically support local hardware I/O by the use of onboard I/O and/or I/O expansion modules.
It is important to note that for small heating hot water plants, one does not need a BACnet building-level controller. Typically, and in addition to the controls sequences internal to the boiler, the onboard boiler controllers can also control pumps, boiler isolation valves and makeup air dampers. Further, one of the boiler controllers is designated as the master controller while the other boiler controllers are designated as slave controllers. In this scenario the BAS needs only to send enable/disable commands to the master boiler controller for the plant as a whole to operate. All other points (i.e., boiler inlet and outlet temperatures, alarms etc.) could be mapped via a BACnet MS/TP or IP connection.
BACnet advanced application controllers have slightly fewer capabilities than building-level controllers; they are typically used for small- or medium-sized mechanical systems.
Recognizing that there is no formal definition of what constitutes a large, medium or small air handling unit, the engineer should specify when a BACnet building controller or a BACnet advanced application controller should be us
For example, a specification paragraph that addresses these potentially conflicting requirements could be:
“Provide one building-level controllers with expansion modules to control the chillers and chilled water pumps. Provide one building-level controllers with expansion modules to control the cooling towers and condenser water pumps. Provide one building-level controllers for each air handling unit with a capacity equal to or larger than 20,000 cubic feet per minute and one BACnet advanced application controllers for each air handling unit with a capacity less than 20,000 cfm.”
BACnet application specific controllers are typically used to control terminal devices such as but not limited to variable air volume air terminal units, series and parallel fan-powered VAV ATUs, unit heaters, unit ventilators, fan coil units and individual fans.
Specifying open BAS
For the purposes of this article, an open BAS is defined as a peer-to-peer networked, stand-alone, distributed control system using open protocols to create an automation infrastructure. An open BAS supports a multivendor environment/network architecture and requires all equipment furnished by all vendors be fully programmable and from a single software tool such that only one software license is required to program and control the entire multivendor network. An open BAS should be specified in a very similar manner to a standard BAS, but with modifications as described in this section.
An open BAS can provide value to an owner by allowing for more competitive bids on controls for new work, renovations and service contracts, due to the fact that proprietary controllers, user software tools and their associated license fees, which typically allow an entrenched vendor with an existing presence in the building or campus to create a noncompetitive bidding environment are prohibited.
An item to note is that an open BAS is not entirely open. It allows for multiple vendors to coexist in a controls network; however, the controllers from each vendor must all tie into a single high-level framework with an associated user interface and software licenses — this high-level framework and user interface will be referred to as the “head end” system.
An overall standard defining the requirements for controller programmability, user tools and license requirements does not exist in the industry; therefore, to create a multivendor environment each head end vendor must define these requirements for themselves and create a unique specification to dictate the compatibility requirements of vendor controllers with the head end system through strength of brand.
When specifying an open BAS, it is important to require that any controller used in the building comply with the head end vendor’s specifications. In addition, the head end vendor will likely require that one or more proprietary controllers, often classified as building-level controllers, serving an integration function be provided. The specification for the devices serving an integration function should be coordinated with the head end vendor.
In some regions, open BASs are less commonly specified than standard BASs and, as a result, local vendors may be hesitant, not adequately incentivized, not adequately trained or even lack the controller hardware required to provide an open system in compliance with the head end vendor’s specification.
The current building controls market is extremely competitive with most jobs being awarded based on low bid. As a result, many vendors bid jobs at razor thin or nonexistent profit margins with the knowledge that, once their equipment is implemented in the building, money will be earned through license fees and service contracts for many years to come.
For a project with an open BAS specification, the license fee and service contract incentive for the non-head end vendors is smaller, which can lead to higher first costs as compared to a project with a standard BAS specification. Before specifying an open BAS, at least three local vendors should be capable and willing to bid the specification.
Specifying proprietary BAS
One of the more recent developments in proprietary HVAC controls is the ability to create a controls system that is predictive instead of reacting with preset sequences. Predictive controls enable HVAC systems to quantify and anticipate relationships between equipment and factors external to the building systems.
For example, a predictive controls system could, in conjunction with reading space data, trend sun pathing throughout the day and preemptively change temperature setpoints of a VAV box depending on whether the zone it serves will be under daylight or shade. This predictability allows the controls system to function as an autonomous building control system. In this instance, autonomous building controls are defined as systems that use various artificial intelligence algorithms to control the building systems. Said systems are capable of self-learning and self-adjusting with minimal or no interference from operators.
In contrast, traditional, sequence-driven BAS are automated with little flexibility to operate outside their sequences of operations. If a traditional sequence of operation is not optimized by design or during coding, this could lead to an unnecessary waste of energy. As international and local climate goals are set, there is a call to look at the energy wastage of the built environment and the waste of energy caused by a poorly optimized BAS. The easy access to digitalize the built environment and the need for more efficient systems is why there is a movement from automated rule-based building controls to autonomous building controls.
How stand-alone software works
The method by which the data are aggregated, how the trends are analyzed and dashboarding (user interface) is where software vendors can differ, but the general process is largely the same. The software process of predictive controls is:
- First, all the sensor data of a building is “onboarded.” All controls points are recreated into a “digital twin,” or digital replica of the building model on the cloud that can be read by the computing software. For building systems, a digital twin is a virtual, living model of the building that trends, saves and locates all of the building’s data components such as sensors, equipment feedback and meter readings. Within this reconstructed model, many companies in this stage offer a live dashboard to easily view the raw data, history and location of the sensors. This digital twin is where physical data is transformed into an “internet of things” system.
- After all the controls points have been recreated, readings from all the points are trended and filtered. This happens simultaneously with step 3.
- Third-party data such as weather, air quality, sun pathing, traffic, etc. are downloaded into the system from the internet.
- The artificial intelligence algorithms, created by the manufacturer, examines these building and external values for trends within and between the two sources to create optimal solutions. For example, the algorithm can determine an ideal temperature setpoint for a room based on correlations between weather data, sensor trends or occupant input via temperature setpoint adjustment.
- If any solutions conflict with one another or causes financial or energy efficiency trade-offs, the algorithm takes this into account and can come up with a compromise. Some vendors work with the user to fine-tune the threshold for these trade-offs.
- After compromises are considered, the software communicates solutions with the operator (or any party who has access to view and change the controls system). The operator can remotely take any of the recommended course of action for the BAS using the software. Many software vendors provide a secure application programming interface to facilitate this communication process. An API is the communication between commands sent by the software and/or operator to the physical equipment in the BAS. If there is a larger issue, such as an alarm is detected, if equipment is approaching end of life or if a filter needs to be replaced, the software will notify all associated parties and facilitate the process for an on-site maintenance visit.
Understand software, security issues
It is important for mechanical engineers to start considering software-related topics when designing controls systems. Because the technology is so new, there are few standards and codes that govern cloud integration and predictive controls. This is made even more complicated by the fact that the analysis software is a black box.
Outside the HVAC industry, ISO/DIS 23247-1 is under development for the digital twin framework in manufacturing processes. Within the HVAC industry, ASHRAE 223P: Designation and Classification of Semantic Tags for Building Data is a proposed standard that outlines the process and requirements for creating a unified naming convention for data and processes within the digital twin. In this instance, a potential best practice as an engineer for now is to specify a digital building platform that uses a nomenclature and data aggregation structure of the proposed standard.
For design guides, ASHRAE Handbook for HVAC Applications mentions little on how to design HVAC systems around predictive controls, but goes over the different software methods of predictive fault detection. Due to a lack of dedicated predictive controls standards and best practices in the HVAC industry, engineers should pull from numerous sources when writing the specification.
At minimum, the specified cloud software should meet NIST SP 800-82: Industrial Control Systems Security and ISO 16484-5: Building Automation and Control Systems. Users and their information technology departments should be trained in recognizing cybersecurity threats, especially because internet of things framework is not inherently secure to hackers or malware. Cybersecurity should be continuously checked; even adding a small sensor during the construction administration phase of the project and forgetting to change its default encryption can pose a cybersecurity risk.
If the stand-alone software should fail or have bad readings, one mitigation strategy is to take the stand-alone system offline for maintenance or ignore requests if the system. Another pitfall of cloud computing could be the potential for the cloud to go offline. In these instances, it is important to have a backup plan.
The best practice would be to create a failure mode that functions similarly to a standard BACnet sequence. The equipment should not rely on communication with the cloud alone. Additionally, one of the issues with cloud communication is the latency or delay of communication between software to equipment and/or cloud data to computing software. Traditional BACnet systems poll input points for data.
Because stand-alone software reads data from the BAS points via push service, polling data in the cloud is limited by the polling speeds of the traditional BACnet systems. For this reason, it is best to use a peer-to-peer protocol between controllers and avoid slower, traditional MS/TP connections where possible to cut down on polling time.
Additionally, API communication between the cloud and BAS is another point of latency. This cannot be circumvented in a cloud to device system; it is best practice to specify that testing is conducted as soon as possible to assess time delays. For existing buildings that do not have a limited timeline, some vendors provide optional plug-and-play indoor air quality sensors to trend a sample space for several months before digitizing the rest of the building to give insight of the time delays to the cloud, start the digital twin process and create a history of sensor data for analysis.
On this note, specifying design testing and field testing is important for setting clear expectations and documentation of the interface, inputs, outputs, functions and conditions the software vendor should test for. For example, testing of how sensor data is represented/trended, the conditions that automatically call for a maintenance visit and latency between sensors and actuators are variables that can be tested and changed accordingly.
Proprietary packaged solutions thrive on the notion that a unified whole is greater than the sum of its parts as they provide hardware that is integrated with its software services. The software works in about the same general way as the stand-alone cloud-based software. It creates a digital copy of the building, filtering, storing and learning trends between the sensors and external sources.
The benefit to these systems is that their hardware can be smarter, more unified and even self-federating. This means some vendors provide sensors that can read multiple types of data, detect each other, read each other’s values and determine which one is to function as the master unit autonomously.
Another benefit to this technology is some vendors send commands to actuating devices from integrated local controllers rather than the cloud. This local, edge-based approach minimizes latency between the cloud/device and also means the system can function if the cloud is down. The cloud exists just for data management and dashboarding for the users. Some systems are also physically consolidated by combining electrical panels with communication wiring in the same controller. The controller even can even provide readings for all attached sensors, reducing the number of screens.
Designing for proprietary solutions lacks a unified approach in that each vendor is different. As such, it is important to ensure the project’s specifications match the vendor’s specifications, and also be open enough for multiple bidders. However, again, there are few standards and codes for packaged systems as well as limited documents from manufacturers.
This can cause issues when specifying a proprietary system because it can be difficult to add on controls provided by other vendors in the future. Other challenges include: a change in basis of design for a proprietary controls package, the system needs repair/maintenance but cannot be serviced by a third party or if the vendor has a limited selection on devices. As such, it is imperative to communicate with the building owner if you intend to specify a proprietary solution.