Over a number of years I have seen HVAC controls evolve from analogue systems through to highly intelligent digital control systems.  Initially all manufacturers pretty much had their own proprietary systems with no common language, whereas now the market is heading firmly down the open protocol path.  The question for me is whether any one protocol is good enough for a whole building, and should there be a common tool for all manufacturers. In this article I will summarise some of the protocols I have worked with and their strengths and weaknesses, before summing up my approach to intelligent and energy efficient building design.

MODBUS
MODBUS was one of the first protocols that enabled interaction between different vendors equipment, and indeed this is still a popular protocol for devices such as meters and variable speed drives.  The only problem with MODBUS is that some vendor’s implementation is different than others; this means that often it’s not practical to place devices from multiple vendors on the same cable.  MODBUS despite all its benefits and uses is not necessarily a protocol designed for complete building automation.   http://www.modbus.org/

LON
One of the first systems that offered a truly open system with a single integrated engineering approach was LON.  LON had great potential to be an excellent solution for fully integrated buildings, however a number of issues prevented this in my opinion.

Firstly was the per node royalty that Echelon required, this meant that on top of the initial cost of the hardware, installers needed to allow extra costs for the per node royalty, this soon mounted into a fairly high cost on projects.

The next issue was that too many manufacturers added their own manufacturer specific communication objects to devices; this restricted the ability for other vendors to interact with these devices.

And finally I believe the tooling itself was a barrier to larger success, at least within the UK market. The tools had reasonably high initial costs and the engineering was quite time intensive, and the tools also had to use the Echelon LNS database software. Later tools from other manufacturers offered better engineering, but I think these came too late.

Finally, I think the last problem was entirely down to installers and not manufacturers or Echelon. This was the actual installation itself, in too many cases I found LON networks installed that exceeded the system limits, used incorrect cable or were lacking the required bus terminator.

The end result of all this is that LON is still in the market but in some countries has quite a low market acceptance.   http://www.echelon.com/   http://www.lonmark.org/

KNX.
Another system offering a fully integrated solution is KNX. This solution has many advantages over LON in my opinion. 

The first and key advantage is that device certification is much more rigorous and allows less manufacturer specific communication objects.  The tooling for KNX is also improved over that experienced with LON.  The only tool is the one available from the KNX association, and whilst it has a fairly high initial cost there is no per node royalty, just a one of payment for the tool.  By taking and passing a KNX basic training course users can also get a significant discount on the tool cost.

In my opinion the skills required to use the KNX tool are lower than LON, this is possibly demonstrated by looking at the high numbers of KNX partners who are certified partners worldwide.

KNX has grown from a small system used predominantly for lighting to a highly capable system capable of controlling most parts of building.  However, for me the real strength and power of KNX is at the room level. KNX offers a superb platform for integrated rooms; these integrated rooms combine lighting, blind and HVAC elements into a single energy efficient strategy.

The area that I feel KNX handles less well is the complex main plant on larger projects, some of the chiller and boiler schemes on large office buildings would be harder to implement in a purely KNX system.  But don’t get me wrong, many manufacturers offer controls that would allow a small to medium building with a simple heating and cooling system to be achieved via KNX.

KNX is a technology that I feel has the potential to offer some very innovative and energy efficient solutions for all elements of a building at room level.   http://www.knx.org/

BACnet.
Then we can move on to BACnet, this is one of the current big trends in the building controls industry and most manufacturers have a range of BACnet solutions.

The key difference between BACnet and LON or KNX is that whilst the protocol is an open standard, the tools are supplied individually by each manufacturer.

Firstly let's discuss the protocol and the devices.

For a device to be certified and able to carry the BACnet logo it needs to tested and certified by BACnet, this ensures that all devices have a basic level of common ground but also leaves space for some manufacturer specific functions.  This certification has meant that many consultants and end users are happy to specify that projects must be BACnet as they know that the devices used should be able to interact regardless of manufacturer. 

The lack of common tooling is I believe both a strength and a potential area for criticism. This sounds contradictory so let me expand. Each manufacturer focuses on specific market segments, by doing their own tools they can focus on innovation in both application and engineering.  For example a manufacturer of intelligent room thermostats can focus on the best way to engineer and only worry about the functions needed for that device.

The downside of this approach is that if you choose devices from multiple manufacturers you will need multiple tools and will need to coordinate the interaction and configuration on the network.
There are some common test tools that can be used to verify BACnet systems and operation, these BACnet browser enable installers to verify that each installed device is coexisting happily all other devices.

However despite this lack of common tooling I believe BACnet is the ideal protocol and system for the more complex parts of our buildings, it can easily handle any heating or cooling scheme and also allows relatively straightforward linking between systems on site. For example a fire system with a BACnet controller and a HVAC system with BACnet controls can share information to ensure the fire operation is easily planned and implemented.

There are BACnet options for most parts of a building meaning it can be used to achieve a fully open building.   http://www.bacnet.org/   http://www.big-eu.org/
 
DALI.
Finally it's worth mentioning DALI, whilst not a protocol that is intended for building wide use it is rapidly becoming the standard for lighting control.  This solution offers install and configuration benefits.

There are other solutions for lighting but this is one of the best known.  A key benefit is the monitoring and reporting of ballast and lamp failures and automation of emergency light testing.   
http://www.dali-ag.org/

Conclusions
[an error occurred while processing this directive] So in summing up my thoughts I am led to a number of conclusions that you can either take as recommendations or simply accept as my own thoughts and preferences.

Firstly, I do not believe that any one protocol is the secret to success in a building; my personal thoughts are that the secret to success lies in choosing the right protocol for the right part of a building.  For example the building management system should be a BACnet client and the main plant systems could utilise BACnet controls, at room level a combination of KNX and DALI (Digital addressable Lighting Interface) would give a flexible and efficient solution. In this solution there may well be MOBDUS or M-Bus integrations for field devices.  All these elements should be connected and coordinated to provide a single seamless system to the user.

Secondly I think the issue of common tools could potentially be a blind alley that distracts people from the real benefits of open protocols. I have worked on LON, KNX and BACnet systems and experienced good and bad in all of them. For me LON tools are not a good solution and promised more benefits than they delivered. KNX is better, and I feel the KNX tools offer a pretty good solution, with better coordination between tools and products than LON.  With BACnet it's different tools for every manufacturer, and I like this as the constant developments that are going on drive manufacturers to keep improving and re-assessing their tools and workflows. A single tool would stall this creativity and take away some of the market forces that keep manufacturers motivated to improve.

The final point on this topic is that I believe BACnet is too far along to introduce a new tool, it would be a massive effort to get all manufacturers to drop their tools and go with a single tool, and the end result would potentially be damaging to the market.

My final comment then is that open protocols are a real asset to the buildings industry and all manufacturers should embrace them.  The protocol governing bodies and organisations should work together to ensure they can all be implemented and interact on projects with the minimum of hassle.  Manufacturers and organisations such as the BCIA and CIBSE also have a key role in this on going challenge, and indeed events such as the connect-fest at the BCIA conference show a desire to get the industry working together.

About the Author

Andy Davis, Product Manager for Siemens Building Technologies.

I have over 22 years experience now having worked initially with Staefa Control Systems, and been through a number of mergers and acquisitions until becoming part of Siemens.  My main area of expertise is room automation, which involves lights, blinds and HVAC control, but I have extensive knowledge of main plant control as well.  I provide training and support on many products and am also a KNX certified trainer.