When a technology is new, it tends to be expensive, proprietary, and difficult to implement. This was certainly true of computers and it has also been true of building automation systems. As the computer industry has followed Moore’s law with exponentially increasing computing power, the cost of computer hardware has fallen dramatically, while the software running on it has increased hugely in complexity and capabilities. Meanwhile, there has been a similar decline in hardware costs in the building automation market, but the reduction in cost has not been as dramatic as in the computing world. This is because for the most part manufacturers have offered systems for which they have designed all the elements: the software, firmware and hardware. In the computing world, developments by IBM, Microsoft, and the Linux Foundation, as well as the Open Source software movement have led to a very different progression, as hardware, communications, and software platforms have become more standardised and “open”. Those of us who have spent our careers in the controls industry can recognise many parallels, and some significant differences.
Whilst it has suited BMS and other building related system manufacturers to offer proprietary solutions, pressure from end users, who don’t like to be tied to one manufacturer, has led, eventually to the widespread adoption of open protocol standards at least in the BMS, lighting and electrical markets; enabling multiple systems to talk to each other. However, because of the way buildings are contracted, each sub-system has developed separately, and each discipline has developed its own standards. The result today is a plethora of “standard” protocols which are used by the various sub-systems in a building; BACnet for HVAC, DALI and KNX for lighting, Modbus for electrical metering and power management, M-Bus for heat metering etc. Some protocols like LONworks managed to gain traction in multiple segments, but its adoption has declined in recent years. So, although people still dream of having “one standard to rule them all” the reality is much messier, and the challenge of how to get systems talking to one another remains. Actually, the advent of wireless and IoT technologies has further compounded the issue.
So whilst automation systems hardware costs have fallen over time, the configuration costs required to deliver the building solution have not. This is because skills required of the engineers has become higher, due to the increasing system complexity, and both control strategies and supervisory graphics are still created manually pretty much as they have been for the last 30 years. There have been various attempts at using standard applications, but these have been manufacturer specific and less than wholly successful.
To properly address the multi-protocol issue an open framework platform is needed, enabling the data from various sub-systems to be “normalised”, so it can be processed in a common way. In the North American market, and to a lesser extent in some European markets, Tridium’s Niagara Framework has become a popular way to deal with the integration challenges in modern buildings, hugely helping controls specialists to deliver a single supervisory solutions across multiple sub-systems. However, Niagara has not provided the whole answer, as there has been an increase in the complexity for the engineering required for integrations. As the existing protocol standards do not communicate the meta data or context associated with all the measured and controlled parameters in a common way, human engineering effort is still needed to “join the dots” and enable the systems to interact in a meaningful way. What has been missing is data tagging, since it is this that can provide the context needed for software to understand the meaning of the data. Recognising the significance of tagging led the founders of the Project Haystack to create this open source project back in 2013. Since then many companies are beginning to see the value of standardising the meta data associated with their products so that easy interoperability between disparate systems can become a reality. The latest version of Niagara (v4) has added a Haystack tagging capability, it requires additional work to implement, and so far it has not been able to leverage the benefits of tagging much in reducing the time spent on configuration. In contrast, the more recently developed FIN Framework and the SkySpark analytic platform have been based entirely on Haystack tagging so they can use this valuable meta data to automate many of the engineering processes.
In the building automation world, before the advent of tagging, the engineers configuring the systems have had to rely on the data labels (usually a single text field of 16-32 characters) to understand where the connected device fits into the system. Whilst humans can mostly figure out the meaning of the abbreviations used in such labels, the automation software cannot, since there has been no labelling standard. Typically each project uses a different syntax depending on the specific consultants and engineers working on job. The consequence of this situation is that automation software that natively supports tagging provides a huge advantage; enabling most of the otherwise manually engineered tasks associated with configuring a system to be automated, saving as much as 80% of the engineering time on some tasks.
Imagine a world in which such inter-communication between systems happened automatically without requiring manual intervention, and all the building’s data can be visualised in the required format with relatively little engineering effort. Haystack tagging used within an open framework makes this possible. In systems in which all the data is tagged, it is possible to almost fully automate the generation of plant schematics, floorplans, dashboards, alarms and energy reports, as well as deliver real-time fault and performance analytics, across different functional systems, not just the BMS.
The Haystack Project is now gaining significant traction globally and there are now formal discussions with ASHRAE (the originators of the BACnet standard) and Brick (a more recent IT inspired initiative), to evolve a common approach for the future. As the use of Haystack grows, the scope of the agreed tags will extend well beyond building services systems, to encompass business software such as meeting room and hot desk booking, CAFM/CMMS, asset management, car parking, etc.
This is why open frameworks and tagging are vital for the future of the building automation industry and its integration with the increasing range of business and IoT solutions being deployed in buildings. Currently none of the major BMS, lighting, fire detection, and other manufacturers have developed software in their proprietary systems that natively enable such tagging, nor do they provide a way to automate the management of the data from multiple system sources. In contrast, open frameworks are designed from the ground up to handle data from multiple sources and protocols, which makes the process of engineering integrated systems with common visualisation much easier. The increasing use and specification of the Niagara Framework from Tridium and its partners, is testimony to the success of the open framework approach. Meanwhile, J2 Innovations’ FIN Framework takes this to another level, as it has been developed completely based on the concept of tagging using Haystack. For the first time, automation of the graphics creation, alarms, dashboards and reports has become a reality. The huge time saving in the engineering of the BMS and related building systems, as well as the potential for new functionality and diagnostics is a gamechanger for automation industry.
There is now little doubt that the future for the buildings sector will be open systems using a tagging standard connected via IP networking and IT derived messaging standards, with hardware largely independently available from the software that provides the application. The current paradigm proposed by the big controls players, such as Honeywell and Schneider, which uses proprietary hardware and software which requires intensive system engineering and locks-in the customer for the maintenance and upgrades, will give way to systems that use open framework software to “glue” multiple devices and systems together, with largely automated configuration processes.
For more information about the benefits of Haystack and tagging:
https://www.linkedin.com/pulse/strategy-payoffs-meta-data-tagging-b-scott-muench/
https://project-haystack.org/file/22/CABA-White-Paper-on-Project-Haystack.pdf