Haystack pillar Buildings City

Your Guide to Choosing the Best Building Automation System

This guide identifies many factors that you need to consider when selecting a new Building Automation System. It's intended to be helpful, so please provide feedback and let us know how we can improve, and extend it.

Factors to consider when selecting a building automation system

CHAPTER 1

Introduction

The decision to purchase a Building Automation System is not usually optional for most new commercial buildings, because the complexity of the installed HVAC and other services related equipment requires the coordination of the various installed equipment, while the demands of the maintenance function frequently require the site’s systems to be remotely monitored. A single automation system that provides centralized control functions such as scheduling, which are easily accessible to the building’s operator(s) therefore becomes an essential requirement. The question then is which one? There are many factors to be considered, which makes this task quite daunting for those who are unfamiliar with the various technologies now available and the wide range of features offered by such systems.

This guide sets out the various factors to consider, in order to help you when specifying or evaluating competing system solution proposals. There are two ways in which competing propositions should be evaluated: according to the benefits they deliver and according to the technology they use to do that. The latter aspect matters because buildings have a long lifespan; automation systems are part of the hard-wired installation, so they are expensive to change and therefore expected to last 10 to 15 years. It is important to choose a technologically modern system so that it does not become out-of-date too quickly or unable to be adapted over time to the new requirements that will no doubt continue to emerge. To illustrate this; within the last 10 years, the IoT (Internet of Things) has some on the scene. At its broadest the IoT is the ability of computerized devices to talk to one another directly, and to share their data, often with the “Cloud” so that people can derive new value from the data to deliver new services and benefits; I will provide examples later on. Building operators are increasingly expecting to be able to integrate IoT type solutions into their BAS installations, but most systems were not designed to enable this, so the integration becomes expensive and painful to achieve, or even impossible, depending on the age of the installed system. Other changes are coming too which will be covered in due course.

First in order to provide context, and because some of you reading this may be faced with what to do about very old automation systems, a short history… Building Automation Systems (BAS) have been available since the late 1980s when computer technology first began to be used to control building services equipment. From there they have evolved significantly following the rapid development of the IT industry. Initially, systems were solely site-based, providing a specially programmed “black box” to achieve the required control, with a local supervisory display screen to provide user access. To meet the demand for remote access to override and/or receive alarms, dial-up modems were used to connect to specialized supervisory software running on a remote PC, for monitoring purposes. The rapid growth of the internet led to this becoming the standard means to connect buildings, while on-site the dramatically falling cost of computing power led to the proliferation of the specialized embedded computers around the building so now every zone has its own microprocessor-based controller (usually located above the false ceilings that are so prevalent in modern building design). As the number of programmable boxes multiplied the requirement to network them together evolved. Initially, every manufacturer developed its own protocol (digital language) to link their products, typically using low voltage twisted pair cabling, but over time building operators demanded some standardization, and start-up initiatives disrupted the market with the concept of standardized communications protocols. As the cost of implementing Ethernet connectivity over CAT5/6 cabling fell, this became increasingly used for inter-controller communication in preference to twisted pair, due to the higher bandwidth and the ability for the BAS to utilize the IT cabling infrastructure that has become ubiquitous. Currently, most BAS manufacturers offer a mix of serial and IP-connected devices, although the trend is strongly towards Ethernet of wi-fi connectivity.

The following diagrams show these evolutionary stages:

 

Dist_BAS_controllers-1

 

Evolution of BAS diagram revised 2-1

 

Dist_BAS_flatIP -1

In parallel with the developments in networking technologies, the need to improve energy efficiency in buildings drove developments in the features offered by the supervisory software. In addition to alarms and scheduling, data logging became mandatory and the ability to visualize the controlled equipment via graphics on screen. As Windows gained dominance, the BAS suppliers redeveloped their supervisors, and as the internet grew they added the ability to achieve some functionality via a web browser so as not to require the specialized software on the PC being used to monitor the system. The diagrams and screenshots below show this evolution and examples of how the software looked at each stage.

This history matters because those making specification decisions are faced with a variety of BAS types that have elements from previous technology generations; most are not yet offering fully up to date solutions. As buildings have a long lifespan and automation systems are expected to last 10 to 15 years it is important to choose a technologically modern system so that it does not become out-of-date too quickly or unable to be adapted over time to the new requirements that no doubt continue to emerge.

So to summarize; a BAS, at its current evolutionary stage is now a collection of microprocessor-based controllers that are wired to the various types of equipment requiring control to ensure the environmental conditions in the building are maintained. This is principally the HVAC equipment, but increasingly also the lighting and shading. In order to provide monitoring of energy performance, BAS can include connection to utility metering devices (but still frequently does not). These controllers are networked together on either a wired serial or IP network (usually a combination), and sometimes wirelessly, to Windows software running locally on a PC or server and/or at a remotely located monitoring center, usually called a NOC (National Operating Center) in the US or a bureau in the UK.

Appendix 1 provides a list of BAS manufacturers, which is not 100% comprehensive but covers most suppliers.

Now for some definitions.

We have been speaking about BAS, but here are other terms used as well; BMS (Building Management System) and BEMS (Building Energy Management System). Whilst the terms used to denote a different set of functions in the system, for the purpose of this book we can regard them as interchangeable since most systems now have energy functions and all provide some degree of management as well as automation. We also need to define the types of buildings we are covering in this discussion; BAS is normally installed in medium and large commercial, public sector, and light industrial buildings. The minimum size of building that justifies a BAS has fallen over time; the lower threshold is more easily defined in terms of energy spend rather than building size, but also building usage and climate influences the choice to install BAS or not. It varies from country to country, but in the USA one can say that any building spending more than $20K per year on energy will probably have a BMS. The growth of smart thermostats which have Cloud connectivity is blurring this, so almost any building could be said to justify a BAS if one broadens the definition of such a system to include one or more smart devices connected to the Cloud that are able to operate in a coordinated way. 

 

The Potential Benefits of BAS

CHAPTER 2

I use the word “potential” because sadly most installed BASs fall far short in delivering on their potential for a combination of reasons which we will discuss below.

1) Comfort control 2) Optimizing energy efficiency 3) Reducing operational and maintenance costs 4) Enabling better decision-making about future investments 5) Enabling IoT deployments to deliver business improvements

1) Comfort control

In order for building occupants to feel comfortable, any heating or air-conditioning system needs to be controlled so as to maintain a constant temperature. The desired temperature is called the set-point and is generally in the range of 19 – 22 degC although in some countries a higher upper threshold is acceptable in summer months. Most modern commercial buildings operate in a sealed way in that the windows are not designed to be opened, or if they are this too is controlled by the BAS. Ducting the air supply into the building requires that the percentage of fresh air is controlled to meet local and national regulatory and health requirements. In many buildings the relative humidity (RH) is also controlled, generally in the range 40 - 60%. The ability of the BAS to maintain a stable conditions depends critically on the quality and design of the installed HVAC equipment; it is all too common for building operators to blame the control system for failing to maintain comfortable working conditions, when it has no chance to do so if the AC equipment is undersized or poorly designed. Having said this, the way the BAS is installed and configured (programmed) also has a huge impact on how well comfort is achieved. If sensors are positioned in the wrong places or the control logic is poorly designed then the desired conditions will not be maintained. Maintenance also plays a role as if failed sensors or stuck damper actuators required as part of the BAS are not replaced, then a previously working system can decline in effectiveness. The good news is that all contemporary BAS installations have the ability to record the temperature conditions, so if anyone is tasked to review the logged data it is possible to diagnose such problems. This then brings us to the issue of who is responsible for the maintenance and optimization of the BAS once the building is operational. From this we can conclude that the design and quality of the BAS is only one aspect of whether it achieves its objectives, but there are features in its design that can help or hinder its effective use. Whether building occupants feel comfortable in a building is also a matter of psychology; generally, people feel better when they have some measure of control over their environment. Historically for heating/cooling this was provided by a set-point adjustment knob or slider mounted on the zone temperature sensor, allowing a user to adjust the temperature up and down by maybe 2-3 oC (4-5 oF) but when this was an analog device there was no means to re-set it to the center of “normal” position, which could lead to excessive energy usage and discomfort if left in the highest setting. Newer versions use digital encoders to detect the knob position, or a display with push-button selection is used, so that the system can re-set the ‘normal’ set-point typically 21°C each night. With the widespread adoption of smartphones, there is now the expectation that occupants can adjust such local environmental settings on their phone screen so BAS’s are now required to offer a mobile interface so this can be done is a user-friendly way. As a smartphone screen allows far more possibilities the UI designs can now enable not only temperature adjustment but also control of lighting level and blind position, in addition to various other functions as desired by the building operator.

Questions to ask:

  • How well can the system log data, and display it in useful ways to the building operator(s)?
  • How well designed are the control strategies for controlling the comfort conditions?
  • How easy is it to view and manipulate the system data? - how intuitive is the user interface (UI) and how much skill is required to “drive” the BAS’s supervisory software application?
  • Does the system enable users to easily adjust set-points and other parameters on their smartphones and local touchscreen displays?
  • Does the system enable maintenance staff to access all aspects of the system on their smartphones or tablets?
  • Does the system have the ability to send alerts and alarms in a flexible and easily reconfigurable way, plus the ability to automatically escalate such alarms if they are critical?
  • Does the system have the ability to automatically generate status reports and send by email or other messaging technology (e.g. instant messaging) on a scheduled basis?
  • Does the system include any analytics software that can be set-up to automatically diagnose and report faults and inefficient equipment behavior?

2) Optimizing energy efficiency

As buildings typically cost a lot to light and either heat or cool, increasingly the BAS is expected to monitor the electricity, gas, oil and other utility usages, although many buildings have a separate system to achieve this, known as an EMS (Energy Management System). EMSs evolved as historically BAS’s were well suited to the utility monitoring function as they lacked the specific visualization, data integrity checking, data aggregation and reporting features needed to provide useful management information on energy performance. Now though, the more advanced BAS software does possess these features so the cost of specifying and installing a separate system can be avoided, provided a careful check is made as to whether the BAS can deliver the required functionality.

Questions to ask:

  • Does the BAS support integration of networked metering devices via all the required open standard protocols? Electricity meters typically use Modbus (either serial or IP), but sometime BACnet, while heat meters generally use M-Bus
  • Do the BAS controllers have a way to properly time stamp the utility data being recorded?
  • When monitoring meters using hard-wired pulse connections, how do the BAS data collection devices handle the loss of meter data in the event of device failure? Some supervisory software can interpolate the data but how this is done varies a lot between different manufacturers' systems.
  • Does the BAS software include the ability for the building operator to create their own dashboards to show the metered data in ways that are most useful to them? Some BAS software requires a skilled engineer to create the dashboards meaning that the users are constrained as to how the data is presented.
  • Does the BAS software include the ability to design and automatically generate & send reports on utility usage in PDF and other formats?
  • Can the data collected by the BAS be easily exported to other systems in a range of data formats including Haystack, CSV, JSON, MQTT, etc.?

3) Reducing operational and maintenance costs

As the BAS is by definition controlling the HVAC and other equipment it has useful data as to the equipment status and its operating parameters. Combining this with the various sensor logs enables diagnosis of fault conditions and inefficiencies in the way the control logic has been configured. A classic example of the former is if an AHU heating coil valve has got stuck, the control logic will increase the cooling to compensate to maintain comfort conditions, which results in a significantly higher energy usage than necessary. This can be identified either by a skilled technician viewing the logged data form the AHU, or by a specially configured software algorithm that can raise an alert if this condition arises. In other situations, the fault condition such as a faulty VAV damper will compromise occupant comfort directly. The BAS can be set-up to create an alarm to alert those responsible for maintenance so that they can respond more quickly than just waiting for occupants to start calling the Help Desk to complain about the A/C not working. It is also possible to predict failure modes, which allows preventative maintenance actions to be better-planned, and can reduce the capital costs associated with equipment failure, as well as mitigating the consequential costs of a building area having to be closed if the A/C or lighting fails without warning. A well-configured system can enable a building to operate with lower maintenance costs and higher occupant satisfaction.

Questions to ask:

  • Does the BAS specification require the installer to set up alerts and alarms that will help with the maintenance and operational efficiency of the building(s)?
  • Is the BAS supervisory software able to display the alerts and alarms in a user-friendly way on a browser?
  • Are the alerts and alarms automatically re-transmitted if unacknowledged to escalate appropriately?
  • Can the BAS software allow alerts and alarms to be acknowledged and commented on a smartphone or tablet as well as on a PC browser?
  • Does the BAS software include the ability to create rules-based analytics (algorithms) to automatically detect fault conditions and inefficient equipment operation?
  • Are the BAS alarm features easy to set-up and change or do they require the controls specialist engineer to manually change alarm thresholds in every device in the system each time a change is required?
  • Is the BAS software able to automatically generate and send summary reports about the alerts and alarms in a given period?

4) Enabling better decision-making about future investments

The equipment used to maintain a comfortable environment in a building is expensive and consumes an increasing share of a building's construction budget. Typically such heating, cooling or ventilation equipment such as chillers, boilers and AHUs have a life expectancy much less than that of the building itself and replacement costs are considerable. Currently, most maintenance regimes consist of periodic inspections and reactive maintenance when problems occur. More enlightened building operators realize that this is not the most efficient way to maximize the usefulness of the equipment assets, so there is trend towards predictive maintenance, using data from the controls to identify issues in advance and to monitor the equipment’s utilization (hours run) since this has a major impact on its effective life. Nearly all equipment has moving parts which implies mechanical wear, which leads ultimately to failure, and there are multiple other causes such as corrosion an material degradation (eg.metal fatigue). Fortunately, most failure modes are well known and with suitably placed sensors and appropriately “smart” software to analyze the sensor data, alerts can be raised to trigger maintenance interventions ahead of catastrophic failure modes occurring. This can significantly extend the life of the equipment which has huge implications for the capital expenditure required to maintain the building. Sadly, although all this is all possible it is not yet common practice for the majority of buildings. Tendered FM contracts are most frequently based on activity; an engineer’s site visit is billable and therefore the incentive to improve diagnosis remotely or to reduce the frequency of site attendance is lacking.

To compound this the analytics software capable of automatically diagnosing and, sometimes, correcting problems is not yet widely deployed. Traditionally when a control system is commissioned alarm thresholds are configured which frequently leads to an overload of alarms being reported to the monitoring staff who react by ignoring or turning off the alarms. Because the alarms are “dumb” they do tell the recipient what has caused the alarm. When a fault condition occurs it can trigger multiple alarms leading to “clutter” than makes it harder for monitoring staff to understand what is actually going on. What is needed are smart alarms that apply logic-based or pre-knowledge of the failure modes that are likely to occur; only generating an alarm once multiple conditions occur that are consistent with a real problem, and pointing the recipient towards the root cause of the alarm. Trends in performance degradation over time can also be monitored and alerts raised prior to actual fault alarms occurring. A reduction in performance efficiency is frequently a symptom of an underlying issue with the equipment, but without the smart software would not actually cause a fault alarm or be visually obvious by an inspection visit. So implementing smart alarms and employing predictive analytics, as step change in the quality of site maintenance is achievable. Provided this is coupled with appropriate follow-up actions to fix reported issues before they become more serious, the life of HVAC and other equipment can be significantly extended, reducing capital expenditure on its replacement.

In many multi-site portfolios such as retail chains, analytics software can also be used to benchmark equipment performance, comparing the efficiency and reliability of different manufacturers’ equipment to inform future buying decisions. Typically, multi-site building operators follow procurement policies that specify a particular manufacturer’s product so achieve some consistency and to get the best price deal e.g. a VRF a/c unit required for cooling required on every shop premises. When such policies have changed from one manufacturer’s product to equivalent from another the two “estates” can be compared over time to see which performs better. Although manufacturer A’s product may be cheaper, if its performance and reliability are worse then it may be better to purchase the more expensive product in the future from manufacturer B.

A further way in which the equipment can be better managed is by uploading to the BAS or separate analytics software the manufacturer’s own design performance parameters. The system can then report on deviations from the expected performance, which can help with warranty claims and early diagnosis of incorrect installation issues.

Such performance analysis is only possible if the building's systems are providing data in a usable format and analytics software is employed to automatically process this data, turning it into useful management information to inform decision-making and investment allocations.

Questions to ask:

  • Do the terms of the FM contract incentivize remote monitoring of alarms and the use of analytics software to reduce call-outs and improve maintenance quality?
  • Does the BAS software have the ability to program smart alarms to reduce alarm clutter and improve diagnostics or is separate analytics software required?
  • Is the configuration of smart alarms and predictive analytics mandated in the system installer’s contract terms?
  • Does the controls contract require consultation with equipment manufacturers to obtain their design performance metrics so that these can be used to identify deviations in real-world usage?

5) Enabling IoT deployments to deliver business improvements

Conventional proprietary BAS manufacturers have not, until recent years, made much provision to easily include data from other systems. Integration of third party devices has typically required the use of gateways as such systems tend to support only a limited number of open protocols. Various businesses have grown up to meet this need, enabling translation of one protocol to another so that metering or other sensor data can be incorporated within the main BAS. The use of open framework software such as Niagara or FIN has helped significantly in reducing the cost of such integrations by enabling multiple protocols to be handled by one platform rather than requiring multiple gateway devices.

Now that wireless sensors and other smart devices which can be connected to cloud services and smartphone apps are being increasingly deployed in buildings to meet a wide variety of uses cases, which include room booking, hot desk management, indoor positioning, space utilization planning, asset tracking, locker reservations, air and light quality monitoring for well-being there are new integrations with BAS required.

As this range of IoT type solutions rapidly expands the industry faces new challenges because the type of protocols used by these require IT-oriented web services integrations which conventional automation systems have not been designed for. Increasingly the building services specific protocol standards commonly used are regarded as either outdated (e.g. Modbus) or unduly “heavyweight” (e.g. BACnet) so use of RESTful API based integrations and MQTT based protocols now emerging as more relevant for IoT applications. The problem with the new approaches is that they require bi-lateral interaction between the vendors of the two systems being integrated in order to fully define the application layer communication, as there is not yet a universally accepted standard way of understanding the message exchanges. Only one initiative so far has sought to comprehensively address this issue; Project Haystack is an open-source standard that has defined tags for all aspects of devices and parameters used in HVAC control systems, and tag definitions for other related systems such as lighting, shading and security as well as the more IoT type applications are also being worked on. The Haystack standard when used in conjunction with a transport layer such as MQTT provides IoT “friendly”, fully defined protocol that makes integration of multiple systems very easy. Multiple manufacturers who are licensees of the FIN framework are already able to use Haystack over MQTT, but there is a need for market education amongst solutions vendors to achieve widespread adoption. Current formal discussions between Project Haystack and the ASHREA committee that manages the BACnet standard offers the prospect of a much wider awareness of the merits of tagging and the haystack standard, but is currently focused only on the building services requirements. Further effort is needed to raise awareness amongst IoT solutions providers whose current approach is in many cases quite siloed – their won devices connect directly to the cloud with no provision for a standard way to interact with the BAS or other IoT providers. Sadly this siloed approach to technology deployment seems to be the norm since it is far easier to sell the ROI on a simple proposition than attempt the more complex task of persuading end-users of the value of more holistic approaches. Making systems work is an order of magnitude more difficult than making a product work due to the inherently complex nature of system components’ interconnections, but it can be made simpler by common standards and approaches such as proposed by Project Haystack.

Questions to ask:

  • Have the project specifiers been briefed to consider the value propositions offered by IoT solutions and required that these be integrated with the building’s automation systems so that all building data is easily accessible in a common way?
  • Does the BAS support REST API or MQTT integrations that will enable easy integration with future IoT solution deployments?
  • Does the BAS support Haystack tagging, and specifically the use of Haystack over MQTT?
  • Has the specification included a requirement that the installation company configures the BAS with wizards that simplify the integration of third-party devices?

Conclusion

CHAPTER 3

There are many factors involved in creating a smart building, and selecting the BAS that will be central to managing the building services equipment.

BAS was originally primarily concerned with controlling to achieve comfort conditions but has now become much more concerned with monitoring the equipment and building status so as to optimize the performance and efficiency of the site. As its role has expanded the need to integrate data from multiple systems has become far greater and with the emergence of IoT technologies, this trend has only accelerated. The emergence of protocol standards, especially BACnet, has contributed significantly in enabling integration between different manufacturers’ BAS’s without resort to multiple gateways, and the increasing use of IP connectivity has also helped. However, to achieve integration between the BAS and other systems and applications which employ different protocol standards, it is open frameworks that hold the most promise as a way to address the challenges of diverse data sources, by normalizing the data to a common format. The Niagara framework achieves this by normalizing to a proprietary data layer, while FIN Framework is more open as it utilizes the Haystack tagging standard. Semantic tagging such as promoted by Project Haystack enables the abstraction of data from its source(s) by preserving its context, thereby enabling applications to consume the data from multiple systems without any direct knowledge of what they are. This simplifies integration, while the use of tagging also opens up the potential for greater automation in the configuration of building automation systems. This significantly reduces the cost of engineering and opens the potential to deploy BAS technology in many more buildings where it would previously have been too costly. Meanwhile, the rise of a variety of IoT type solutions which offer new value propositions beyond the management of energy & operational costs is beginning to be widely adopted. For these to “play well” with the BAS requires significant change in the BAS software architecture. The disruptive influence of IoT technologies could lead to a dis-aggregation of the building automation system as manufacturers no longer supply the whole system end to end but instead installing companies (Systems Integrators) select best of breed products which they integrate and configure with open framework type software from different vendors. Applications for various desired functions such as energy management, asset tracking, tenant billing, room booking and many others will also increasingly be supplied by specialist vendors.

So in summary, the core questions to ask of any company promoting a BAS for your project are:

  • Is the system fully IP so as to be able to take advantage of the flat architecture and universal device addressing that this offers?
  • Does it support multiple open standards so as to be flexible and as far as possible future-proof?
  • Is it based on the use of tagging to enable automation of the engineering tasks and to facilitate easy integration with diverse systems and application software?
  • Are the visualization graphics fully responsive HTML5 with a good mobile experience (since this is how the system data will be increasingly accessed)
  • Does the BAS software support user-friendly dashboards
  • Does the BAS software include analytics capability to automate fault diagnostics and trend exception analysis

Appendix 1

LIST OF BAS MANUFACTURERS (not including equipment manufacturers)

  • Alerton
  • ASI Controls
  • Automated Logic
  • Automatrix
  • Bastec
  • Beckhoff
  • Carrier
  • Centraline
  • Computrol
  • Coster
  • Cylon
  • Delta Controls
  • Deos
  • Distech Controls
  • Domat
  • EasyIO
  • Fidelix
  • GC5
  • GFR
  • IMIT
  • Intellienergy
  • Honeywell
  • Johnson Controls
  • Kieback & Peter
  • KMC
  • Lynxspring
  • Loytec
  • Neptronic
  • Novar
  • Ontrol
  • Ouman
  • Phoenix Contact
  • Priva
  • Prolon
  • RDM
  • Regin
  • Sauter
  • Schneider Electric
  • Saia
  • Siemens Building Technologies
  • Solidyne
  • TCS Basys
  • Teletrol
  • Trane
  • TrendControl Systems
  • Vykon
  • Wago
  • Webeasy

Jump To Section:

Download the white paper
Background of blue lines blurred letters falling

Download your free Guide to Building Automation Systems