Important considerations from the history of modern building control systems
Building controls technologies, open communication protocols and networked internet protocol evolved to create a relatively easy means to integrate multiple control systems
Control system insights
- Building control systems have evolved over several years from simple systems that control one aspect of a building to more modern, complex systems that control everything.
- Integrated control systems cannot only control all the engineered systems within a building, they can enhance security and sustainability.
Heating, ventilating and air conditioning (HVAC) control systems, also known as building management systems (BMS) or building automation systems (BAS), have changed significantly over the years. The primary function of the BMS is to control air handling units, boilers, chillers, cooling towers, space temperature controls and other related building HVAC control systems.
As buildings evolve and are increasingly more sophisticated, the requirements of integrating additional control systems to the BMS also increases. This can include lighting control, electrical power monitoring systems and plumbing equipment. Understanding how these various systems can be connected to a seamlessly integrated control system can increase building performance.
Evolution of BMS control system solutions
One of the most noticeable evolutions with building control systems, is the way information is transferred within their controllers and displayed on the graphical user interface (GUI), such as an operator workstation (OWS) or a thin client. See Figure 1 for an example of a proprietary BMS network architecture diagram. During the development of the various BMS control systems, it was up to each independent BMS vendor to determine the communication method and protocol in which data would be sent and received.
For example, unique communication protocols would not allow the control system of Vendor “A” to transfer data to the control system of Vendor “B.” As a vendor’s proprietary solution, these communication protocols can be very restrictive. Therefore, a building owner who would like a BMS installed at a facility would need to decide which BMS vendor should be selected, understanding that this would require a long-term commitment. If a building owner later decided to use another BMS, it would be expensive to replace the existing controls in the building, including the BMS controllers, field devices, OWS and wiring.
Alternatively, a communication gateway could be installed to translate the BMS information between two different control systems. This solution would require a significant amount of programming to configure communication links and could have reliability issues, as the gateway is a single point of failure.
An owner might decide to change BMS vendors if they were not satisfied with the control system performance or if there were issues with the service agreement, such as high cost or slow response time. This is not the most desirable solution due to the expense of additional changes to an existing control system. Since there would not be any competition in the selection of a controls system contractor for renovation work, this is typically subject to increased cost for services as well.
Owners of larger facilities could decide to use multiple control systems, which would allow for competition between the vendors. However, this solution can be cost prohibitive as well, since this would require the duplication of the OWS, communication wiring, spare parts and potentially another programming language.
The answer to these common challenges was the creation of a nonproprietary “open” protocol that could be shared among all BMS manufacturers, leading to BACnet International.
Creation of BACnet
Building automation and control networks, or BACnet, was developed by ASHRAE in the 1980s as the open protocol solution for BMS control systems. ASHRAE allowed for the sharing of the BACnet protocol amongst all BMS vendors, as documented in ASHRAE Standard 135: BACnet — A Data Communication Protocol for Building Automation and Control Networks, which granted building owners more flexibility. To ensure compliance of BACnet communication among the various BMS vendors, the BACnet Testing Laboratories was established as an independent organization to verify that the control devices meet the ASHRAE Standard 135 requirements and confirm communication inoperability.
Both BMS vendors and equipment manufacturers could reap the benefits from using BACnet. For example, the BMS could use the BACnet protocol to communicate with the manufacturer’s factory installed control systems for boilers, chillers and variable frequency drives. Using the BACnet communication with third party equipment is a more cost-effective option, since a communication wire could transmit multiple control signals associated with equipment parameters, whereas previous monitoring of HVAC equipment would require a dedicated wires for each control signal or a communication gateway. See Figure 2 for an example BACnet BMS network architecture diagram.
Even though the BACnet protocol allows for a nonproprietary communications protocol, it still has limitations. While the use of BACnet establishes a common protocol for communication, it does not solve the problem of allowing building users to modify the system on a controller level. The BMS vendor would still use proprietary software to startup and commission the system, which will not allow the end user to adjust later, on the local controller level. The owner would only have access for adjusting via the GUI. For some building owners that might not be an issue. However, for buildings that have ongoing renovations, this would be detrimental.
There are other protocols that are considered ‘open’ that can be used in BMS networks. One such protocol is Modbus, which was developed by Modicon for industrial programmable logic controllers in 1979. For the commercial HVAC control system industry, Modbus is used for communication with electrical equipment, such as automatic transfer switches, switchgears, emergency generators and electric meters.
The next progression in creating a truly open hardware system, which could entail hardware solutions, software solutions or both that addresses the limitations of BACnet and other open protocols is seen in the implementation of the Tridium Niagara system.
Tridium Niagara open software solution
Tridium created a software solution, called Niagara, that is an open programming platform. The Niagara framework is an operating system that is installed on controllers and servers. Tridium also offers a hardware product, called a Java Application Control Engine (JACE) that the Niagara framework is installed on. However, this framework can be installed on any manufacturer’s controllers. Many of the major BMS providers will carry two product lines: one proprietary system and one Niagara system.
For example, Johnson Controls has their proprietary offering, the Metasys system, and also has a Niagara offering, Facility Explorer. Certain verbiage needs to be incorporated into the specifications to prevent contractors from installing proprietary software on Niagara devices. This is important to guarantee that downstream controllers are programmable from the workbench and that the system remains fully open. This also prevents the contractors from being able to ”lock out” competing vendor controllers from communicating with each other. This verbiage is called the Niagara Information and Conformance Statement (NICS) and is provided by Tridium.
The advantage of many different manufacturers offering a Niagara solution is that all can bid on the same project, with the same solution, while providing a future-flexible hardware environment. When bidding on new projects with the option of either a proprietary system or an open system, there may be an additional upfront cost for an open system that the owner should be aware of.
However, after the open system is installed, it will provide more competitive bidding on future projects and can thereby decrease future cost, since any Niagara certified manufacturer can service the system and controllers. Owners are not locked into one provider. In the event an owner becomes unsatisfied with the service that is being provided from a service provider, the owner can engage with a different Niagara certified service provider that may offer a more satisfactory response.
This is also an advantage when working with a customer with a large global footprint who is looking to maintain consistency across their portfolio. The customer can standardize using Niagara and the system can be installed by any Niagara certified branch, instead of being limited to only local branches in the area the buildings are located.
By allowing open programming, Niagara provides the ability to integrate with many different manufacturer’s products and communication protocols. The Niagara framework can be configured and customized to suit the needs of the project. Third-party communication drivers can be installed on the controllers to enable communication with proprietary controllers with protocols from Siemens, Trane, Johnson Controls and others.
This is a powerful feature, particularly during retrofit projects. For instance, an owner may wish to upgrade the BMS, but have a prohibitive budget, making it unreasonable to replace all front-end equipment and field level controllers at one time. Niagara could be used as a potential solution to implement an incremental modernization of the equipment.
A JACE could be used to first replace the supervisory level controllers. The JACE can be equipped with drivers installed to integrate with legacy field controllers in the building. There may be different manufacturers’ controllers in the building that can be integrated to the Niagara front-end. Once this process is complete, the remaining legacy controllers in the building can be replaced over the years as the budget allows.
Another benefit of a Niagara system is the ability to connect to legacy systems and controllers. The Niagara system can either communicate to the controllers through a JACE or a Niagara computer server or supervisor. The legacy controllers may have proprietary software installed, which can limit some of the functions available with a JACE, but these can still be integrated into the Niagara system using drivers. However, a JACE controller that has the Niagara workbench installed will provide more flexibility and enable the end user to use all Niagara benefits.
The flexibility of integrating different manufacturers building automation controllers and packaged mechanical equipment controllers can also be applied to different technologies. Additional gateways may be required, whether it be lighting controls, power monitoring, security or an access control system. The open platform solution of Niagara can again be used as the framework where these systems can all communicate and be visualized at a central location. See Figure 3 for an example of a Tridium Niagara network.
Tridium provides the option for customers to opt in to a Niagara Service Maintenance Agreement (SMA). The Niagara SMA is an offering that continuously provides technology updates and feature improvements to the system. This enables existing systems to be updated to fix software bugs and to be upgraded to the latest technological developments. While Niagara provides a powerful solution with many different capabilities, there are some factors that need to be considered before pursuing this product.
Major BAS providers will typically provide a line of Niagara controllers, yet these are often installed by independent contractors. These independent contractors do not always have the same accountability offered by the main manufacturer branches. The level of expertise of the independent contractors also may not be held to the same standard as a major distributer with local branches.
Additionally, Niagara has many different capabilities and functions, which must be established during design by the engineer of record or building commissioning agent for a project. The contractor must effectively implement the desired features defined by the engineer of record and tested by the commissioning authority during installation. This increases the importance of interviews during the bid process to ensure a contractor is qualified to complete the project.
When dealing with a project involving multiple different control systems, such as building automation, security and lighting, a single source control system manufacturer or vendor can streamline coordination and problem-solving. Although Niagara provides the ability for these different systems to communicate, there are challenges that can be encountered when dealing with multiple manufacturers. Coordination between the numerous parties involved can make it difficult to determine who has ownership when an issue arises. A single source vendor that can provide the different control systems involved has the potential to alleviate this issue.
Each device that the Niagara workbench is installed on, whether it be a server, JACE controller or Edge device, requires a license. The licenses are provided based upon device counts and point requirements. Each of these licenses comes with a software maintenance agreement that provides the updates and improvements previously mentioned. The cost of these licenses and maintenance agreements can add up when there are a lot of controllers in the building. First cost and total cost of ownership should both be presented to the client and should be considered when comparing open versus proprietary systems.
BMS integration and BACnet
BMS communication protocols and their ability to be integrated with other control systems has dramatically changed over the years, from the initial creation of the BMS vendor proprietary protocols to the “open” systems approach that allows inoperability with a multitude of control systems. When designing and specifying a control system for a project, there is no advantage of using a proprietary protocol for new construction.
However, it might be required in a renovation project for the controls to be easily integrated into the existing facility’s control system. This will need to be reviewed with the building’s owner. In some cases, it would make sense to remove the existing control system and install a new one, especially if the BMS is outdated and potentially obsolete. The most desirable solution for the BMS communication protocol is BACnet. This allows for the most flexibility with communication to a multitude of BMS vendors and mechanical equipment vendors.
After selecting BACnet as the BMS communication protocol, the owner still needs to decide which BMS platform to use. The BMS platform components include the BMS OWS and BMS controllers. Vendor-specific and Niagara platforms are the most common platforms used. The vendor-specific platform is provided by the control vendors such as Johnson Controls, Siemens and Honeywell and uses their proprietary software.
The Niagara platform is provided by Tridium with “open” software capabilities, called Workbench, which can be supported by numerous control vendors. Some additional items to consider when deciding on which type of BMS platform to specify are:
Does the building need to integrate with control systems from different vendors?
Will the BMS need to expand, such as at a campus or is it restricted to a small environment?
Is it important to have the freedom to select a BMS service provider and not be locked into a specific vendor?
For any new project, even where there is not a known need for the integration to multiple vendor platforms and the building owner is agreeable with selecting one BMS service provider, having a vendor-specific platform solution might prove to be best choice. For a building owner who would like the freedom to choose a BMS vendor for service and where there is a requirement to integrate to a multitude of unique control systems, the Niagara platform should be considered.
This would allow the owner to have multiple BMS vendors bid their services, leading to a competitive price. The ability to have an open bid situation for BMS vendors can only be achieved if the building is equipped with controllers that do not use proprietary software, as these would require the use of the Niagara Workbench devices. While vendor-specific and Niagara platforms are both viable solutions, each option should be reviewed and considered with the building owner and a subject matter expert.