Why Open Frameworks Matter

This blog post was written by Chris Irwin, VP of Sales EMEA and Asia

When technology is new, it tends to be expensive, proprietary, and difficult to implement. This was certainly true of computers - which were hugely expensive compared to now. Each manufacturer offered systems that were unique to them, because they designed all the elements: the software, firmware and hardware. As we all know, developments by IBM, Microsoft, and the Linux Foundation, as well as the Open Source software movement have led to a very different world for computing technology. For those of you who, like me, have spent our careers in the controls industry will recognise many parallels, and some significant differences.

The use of computers to control buildings was an inevitable consequence of the falling cost of technology and the huge increase in the complexity of the equipment required to achieve comfort in large modern buildings. As with computers, the nascent BMS market was initially supplied by manufacturers who offered highly proprietary systems, which only they could install and maintain. As the technology matured, the software to program the required control logic became easier, so a wider range of people could provide the engineering. Also, pressure from end users, who didn’t want to be tied to one manufacturer, led to the development of open protocol standards; enabling multiple systems to talk to each other.

Because of the way buildings are contracted, each sub-system developed separately, and each discipline developed its own standards. The result today is 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 has not gone away.

Don’t get me wrong, the widespread specification and adoption of the open standards listed above has made life a lot easier for BMS engineers, but such communications standardisation is only solving part of the problem. Whenever two systems try to interact, there’s a lot of engineering time required to ensure that the data from one system is being properly understood by the other. Also, the process of configuring the supervisory software, which manages the building’s performance, requires complex configuration to display floor plans, plant schematics, dashboard, and reports.

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. The key to this, is to provide context to the data which is being communicated between systems; now commonly referred to as “tagging”. Various initiatives have been attempted, and some of the protocol standards such as LONworks and BACnet have developed the concept of profiles, defining much of the metadata associated with a real-world data point. Unfortunately this has not been enough for the computers to fully automate the inter-linking of systems.

Over the last few years, an open source initiative called Project Haystack has sought to fully solve this tagging requirement for buildings, and it is now gaining significant traction globally. There have been great discussions with ASHRAE (the originators of the BACnet standard) and Brick (a more recent IT inspired initiative), to see how a common approach can be agreed upon. In systems in which all the data is tagged, it is then 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.

This is why open frameworks matter. Currently none of the 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. 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. Recently, Tridium has also added a tagging capability with specific support for the Haystack standard. 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. This offers a huge time saving in the engineering of the BMS and related building systems, and creates the potential for new functionality and diagnostics.

Until the advent of tagging and the Haystack standard, the message definition was defined by the protocol used, and these are specific to the building controls sector. Now, open framework software such as FIN can “read” data from any system, regardless of protocol provided it is communicated over IP using an agreed transport mechanism such as MQTT, JSON or a REST API – all standards used by IT systems in many other sectors. 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.

Since buildings last a long time, and installed electronic systems are expected to have a lifecycle of 10-15 years, it is perhaps unsurprising that our industry has been somewhat slow to respond to the changes that have been occurring in the broader computing world. For many years now, computer software has been de-coupled from the hardware by the use of common operating systems such as Windows, Unix and Linux, with JVMs (Java Virtual Machines) providing some assistance with the portability of software onto embedded hardware platforms. This trend has led to an acceleration of innovation and created much more flexibility and competition in the market. In the building controls sector we are, as yet, some way off from embracing this de-coupling shift for most of the products used at the edge (the primary data collection and/or control devices). Although at the global controller level, both Niagara and FIN have been ported by various OEM controls partners.

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, 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.

Find more information about Project Haystack here.