Compiled by Benjamin Brits
Controllers are the core around which HVAC systems are able to provide the required outcome of temperature, pressure and humidity control while maintaining energy efficiency.
Analog controllers are some of the youngest technologies in modern day engineering. Many reports reveal the invention of these devices was around the mid to late 1960s, preceding the release of the commercial computer in fact. As progression to digital has come about with all electronic devices, there are very few elements in the HVAC/R sector today that do not make use of one or other type of this technology as an essential tool to complete a system and achieve optimal operating conditions.
The role of any controller is to execute a particular function or set of functions at a particular time and based on particular circumstances.
Sitting in a comfort cooled (or heated) office, visiting a supermarket or working in a high precision plant, the control methodology of any system most often does not even make it into anyone’s thoughts, but let something go wrong and it is the first thing that everyone will point to, highlighting the importance of these ‘behind the scenes’ devices.
Creating and maintaining an environment where a HVAC/R system is required, must take multiple factors into account in both the outdoor and indoor conditions and is of course, dependant on the specific application. Considerations around the main elements include all, or particular attention in, temperature, humidity, air movement, extraction and air quality that require continual management.
Each industry sector will also have differing needs – from the agricultural and food industry to data centres, to various manufacturing, commercial and medical facilities – these all demand varying outcomes, quality, and precision in order to meet their own functionality.
Application-specific control needs to also fall within an acceptable tolerance range while there are very different criteria for refrigeration, comfort environments and processing facilities – that for example require the delivery of extremely accurate system management in milliseconds – rather than seconds or minutes as acceptable in other functions. This then alludes to the range and quality of controllers available for their specific requirement as well as their capabilities and complexities.
Controller needs are further said to be a direct correlation to the asset value, and it makes sense that one would not install a R600 device in a R10-million plant or apply this logic to a billion-rand processing facility. It would also be important to understand elements such as device inputs and outputs, compatibility with other sub-system controls, and other features such as connectivity or reporting.
When systems are integrated, each one operates more efficiently. Photo by Trend Controls
A closer overall look at control
As we have established, the built environment has a range of controllers that are specific to managing the built environment, and this is the same for refrigeration or any industrial process.
Why have all these different ranges of controls you may be wondering? Why isn’t there just one type of control that can be applied across the board? Well, the answer is quite simple and relates to the aforementioned link of a price point against the asset value, but further the more complicated a system becomes, the more complexity is required, and the greater the possible control to be implemented (sometimes extremely sensitive control is demanded).
If a fridge as an example has a temperature deviation of half a degree with a controller scanning the temperature every half-second to make system adjustments or execute a set action, this would likely result in a problem as the compressor and fan would continually be switched on an off causing premature wear.
The failure on control products is really around failure of implementing correct design and engineering methodologies.
Conversely, looking into an automation system in the built environment, a one-second response time to a deviation is too long because the various valves that are opening and closing require a real-time scan and output response. This essentially would mean a controller with features capable of managing 100 or 200 milliseconds should be selected.
If you then take that same controller into an industrial process, even 100-millisecond control is just too long, and you would need to respond a lot quicker to changes given the possible implications that deviation could spoil an entire production run or batch.
Naturally, this all means that the complexity of the equipment involved in any system increases as you need to delivery faster and more accurate cycles, and with the advanced algorithms, the price of the unit increases. System designers therefore need to make sure that the specified controller does the required job, and for the best possible price both up front and over the plant lifespan.
Controllers, in the context of this article, should also not be confused with building management systems (BMS) as these advanced devices extend to, and fulfil, a different function and include many more elements or sub systems within a building that can be monitored and controlled to create overall building efficiency. This topic will be covered in a future feature in the RACA Journal.
HVAC system control and communication
Focussing on the HVAC systems in a building, these are categorised into two functional areas, namely the primary plant operation and secondary plant operation. The primary plant is what provides pre-conditioned bulk supply and secondary plant is what provides fine control for the particular space and is needed to match occupant requirements through specific set points.
Plant controllers overall may have many inputs and outputs and can perform significant processing functions. Because the primary plant has a lot more important elements under control, these devices tend to be more costly than secondary plant controllers that require fewer functions to be delivered and are thus simpler and smaller.
Now, when it comes to controller communication, it is useful to understand a little about the history and lead-up to the technology one has access to today, and to be aware of factors such as compatibility – essentially the ‘language’ of these devices that enable them to be incorporated into the larger scope that is building management.
As these devices were developed by various suppliers over time, they each had their own logic to clearly separate brands from one another through their unique coding concept. This naturally became a problem for the industry as what resulted is known as ‘supplier lock-in’ – meaning that system owners could not incorporate different brands together (for possibly pricing and practicality reasons), therefore having to stick to one supplier throughout their system.
Photo by i4 Group / iLED
This proved an unfavourable condition for the clients who were not free to choose, and so in the interest of transparency, and because of the facts around the way the world was progressing in terms of technology development, the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) intervened, and through various research and collaborations introduced open protocol.
The idea behind open protocol was that the communication language would not be owned by any particular company or manufacturer. It would be an industry standard and be based on the overall interest of that industry. In simple terms this open protocol was the establishment of a common communication language that different brand’s devices would use to talk to each other, and so was developed into what is known as BACnet (abbreviated from building automation and control network).
Today you will find other communication protocols in the built environment such as Modbus, KNX, LON as a standardised communication language that was developed and implemented into the industry over time. Having this universal open protocol created the environment where different brands would be able to be successfully installed in a single system.
The next challenge in the open protocol development was that although each brand’s controller would be able to communicate with another, the way in which each brand is engineered and commissioned required different programming tools and training.
In a building with ten different suppliers, this proved to be a persisting problem. This results in the technician requiring ten different engineering tool sets, and knowledge of all the different brand devices which is impractical in anyone’s book but remained a challenge. Therefore, for engineers and technicians alike, it became critical to be aware of device compatibility.
Today as technology has developed and gone through a process of natural evolution, controllers, for the most part, apply similar hardware interfaces (BACnet MSTP or BACnet IP) although some differing interpretation still occurs between brands. This has been driven primarily by the computer sector that followed a similar path, but for some time has required not only adequate communication but advanced connectivity and integration functionality.
In between the progression, product engineers had to establish new communication protocols to be able to tie devices into global networks such as MQTT and RESTful API – essentially making controllers capable of translating data into the same format of computers to be able to use this data for other processing and analysis. Long past then are the days of a simple MSTP hardwire bus, as most sectors have got to a point where IoT or 4IR has become mainstream and because better efficiency is sought out.
This conversion was achieved through JACE or EC-BOS connector boxes (still used as default in South Africa) that converted the controller language to standard internet protocol. This development had a significant impact onto the controller industry as advanced features became possible such as visuals and reporting, speed of data transfer rates increased, and costs were lowered.
With the latest technology and communication protocols available, if you are in the position of quoting on any automation system, there are now far more elements to consider when looking at, and understanding, the technology architecture as well as price implications of selecting cheap solutions now, versus the ability to leverage IoT/4IR over the lifespan of the facility or plant.
The advancements of computer engineering, that has access to far more R&D funding, will no doubt continue to advance and offer many new solutions soon, but will further be driven by overarching international trends in building systems.
Controller capacity
As mentioned previously, all controllers exist to carry out particular functions and are highly dependent on the process application. There are different types of devices that a controller can be connected to. There are inputs and outputs that measure either analog or digital. An analog device would measures things like temperature, pressure, or humidity at a particular value. Digital devices measure and control an open/closed, or on/off status.
In an example of determining the capacity of the controller required, one would need to evaluate the plant system. You may have two temperature sensors, two valves, a heater bank that is either on or off, a fan, a pressure switch, and a static supply pressure. Simply taking the input/output (I/O), one would partner a controller that has a minimum of the I/O that are required to be controlled.
Typically, it is also common practice to accommodate spare I/Os. A consultant would specify that there must be a 10 or 15% spare capacity included, so that sensors can be added for future expansion. For the IT orientated individuals, controllers can be likened to a network switch where all the endpoint devices are tallied that need to be connected, and the same principle of sizing is applied.
Controller programming
Who does the controller programming? Well, this is in fact a very good question and I believe one worth getting your input on!
There is an assumption from various perspectives that when for example an air handling unit arrives on site, it will already be “set up to function correctly” within the system and include all the necessary controls. Similarly, a chiller would be supplied “complete with controls”. All supplied units, generally, are delivered with the control programming already uploaded. The question then is, who in fact owns that programming and who carries out the programming for these units?
The more complex a system becomes, the more likely it is that a professional building management system technician will need to be appointed to do the setup and make the entire system function correctly by tying in each piece of equipment into a central controller or BMS. When it is assumed that everything is ready when it gets to site, more often than not, no time is allocated to programming needs, testing, and ensuring each separate piece of equipment works correctly.
Perhaps a deeper discussion is required here between consultants, specifiers, controller/BMS suppliers and technicians and I welcome your feedback on this. Open protocol has perhaps created a void where there is misalignment or fragmented roles around who is ‘supposed to’ fulfil certain functions within the control environment. Does each party know where their role starts and ends in the cycle? This is not always clear.
Maintenance and repair
Open protocol has created the environment for mixing and matching of controllers as required to complete a system. This has also led to what can perhaps be classed as an ‘un-maintainable’ system because working on each system requires multiple tool sets if this mix and match strategy is applied in a plant installation.
Each of the controller brands, having their own interpretations, essentially means that there is a different programming and maintenance tool set that the technicians need to know to be able to apply to configure, or if they need to do any additions to a system. This is true for maintenance and any service work to clean up the data tables and so on.
For this reason, it is recommended that specifiers consider selecting a common control family across the entire building or asset. This will also prevent multiple tool sets having to be learned by the maintenance staff or facility managers.
An example of a master communications unit (MCU). Photo by Rickard Air Diffusion
Supplier differentiation
It would be fair to state that most major manufacturers produce good products. The failure on control products is really around failure of implementing correct design and engineering methodologies, indicating that controllers, no matter what brand, do perform their intended functions correctly based in accordance with the manufacturer’s guidelines of use.
In a competitive environment such as this, controller manufacturers tend to specialise in certain industries where they can perfect their product offering rather than try and be all things to all people. In order to differentiate brands from one another that service the same sector, several factors should be considered.
These include detailed local technical support and local backup, locally available training in the local language and in the correct local time zone. Further factors to consider are the availability in stock holding and the ability to respond timeously to any client needs.
It is also an important consideration to select a supplier that has multiple system integrators. Locally represented manufacturers that handle import, distribution, training, and technical support are also recommended as preferred suppliers as there is recourse with the manufacturer should anything happen to go wrong – system integrators that also import, fall short on this, leading to the potential for client lock-in that has historically proven to be unfavourable.
Technology improvements and essential inclusion
By now everyone would know we are already in the fourth industrial revolution (4IR) and technology continues to improve in all spheres of the built environment, be this on the IT side, building automation and control, primary or secondary plant control or even on the user interface element.
Technology is also continually advancing, and it is vitally important that building owners are advised accordingly to make their decisions based on the products that are leading the technology curve. It is evident by the pace at which transitioning is happening around the world that controller technology will play a significant role in all future efficiency, and it is not merely a case of ‘perhaps’ they will.
Those that choose to not implement technology are, at the end of the day, shooting themselves in the foot as adoption, particularly in the aspect of a digital transformation strategy will be critical to incorporate smarter systems into a bigger picture asset management objective. This would include the addition of various IoT devices as well as cloud connectivity considerations of future conditions.
Ensuring clients are well informed regarding the latest available technology is as important as no longer specifying a BACnet MSTP controller in a new building today and transitioning to products that allow delivery of cost-effective service in the HVAC ecosystem.
Article Sources
- Ivan Potter CEO i4 Group and MD of Iled
- Carel Controls
