Understanding Communication Protocols Is Like The Tower of Babel
You proba
bly know the story of the Tower of Babel. The people tried to build a structure that would reach the heavens, but since they all spoke different languages they were unable to communicate and the project failed.
Building automation today can be a lot like that. For a building to operate, all of its parts need to communicate with the rest of the system. From HVAC thermostat sensors and lights, to equipment such as chillers, boilers, air handlers and electrical panels—everything must be linked and in communication with monitoring dashboards that give managers visibility and control.
And, like the Tower of Babel, there are many different languages in building automation. These protocols determine how devices talk to each other. Simply put…if you populate a building with equipment that uses incompatible protocols, you’ll have a building that can’t communicate.
Open Communication Protocols
Over the years, dozens of protocols have been developed for building automation. Some protocols, like BACnet and LonWorks, are made for nearly every type of building automation equipment. This is why most building automation systems will be based on one of these two protocols. Other protocols are more specialized. For example, the DALI protocol was created just for lighting systems, and Modbus was designed primarily for industrial control.
Making things even more complicated, sometimes different protocols can work together and sometimes they can’t. For example, BACnet and LonWorks can both work with DALI lighting systems, but not with each other (at least not easily). Then there is a separate category of wireless protocols, for those devices such as occupant sensors and room controllers that communicate using RF signals. You need to be sure the wireless protocols you use will work with the rest of the building (fortunately, most wireless devices will work with your building automation backbone).
Simple Steps Toward Seamless Communication
Where do all these protocol choices leave the building owner or operator who wants to install building automation equipment? Don’t despair, it’s not as bad as it sounds. Here are some tips for dealing with protocols in your building:
First, choose products that use an open protocol, meaning one that is used by many different vendors. This will give you more choices going forward than if you choose a proprietary protocol (one controlled by a single company).
Second, choose products with a protocol that is widely used, at least in your area. This is important because some protocols are global while others are restricted to specific regions. For example, Clipsal C-Bus is popular in Australia, and M-Bus is used mostly in Europe.
Third, rely on a partner—a major vendor or a systems integrator—who can consult with you and guide you through the choices.
Fourth, ask questions. You don’t need to be an expert on protocols to choose a building automation system, you just need to be able to ask the right questions. Such as:
- How many vendors support this protocol?
- Will it work with the equipment I already have?
- Will it be easy to add new devices later?
- What are the plusses and minuses of choosing products with this protocol?
The building automation experts at Schneider Electric recently released this Guide to Understanding Open Protocols in Building Automation. It gives a layman’s overview of the major protocols, pros and cons of each, regional relevance and more. It also includes a high-level mapping of which Schneider Electric building solutions speak which protocol languages.
Understanding the role of protocols in building management will help your facility seamlessly communicate, which is crucial in a facility manager’s quest toward building optimization.
Let me know what you think – leave me a comment below!
Conversation
Stephane Rozand
8 years ago
Hello,
Your article is very interesting but I would like to know your opinion about the KNX protocol in building automation?
Thank you for your answer
Regards
Jaimie Giarrusso
8 years ago
Hello Stephane,
I am not a KNX expert, however, I’ve asked my colleague to reply to your question. Watch for his comment very soon! Also, watch for a revised version of the protocols guide to be released shortly. We have updated the KNX and C-Bus pages.
Thanks very much,
Jaimie
Thomas Rohde
8 years ago
Hello Stephane,
KNX is succesful used in residential upto midsize commercial buildings since many years. It is a reliable system supported by many vendors and especially by a huge amount of partner.
For sure, the datarate of 9600Bit/s isnt incredible but with the use of an KNX-IP-Backbone you can transfer data as well in a big buildings with the right performance.
KNX can be easily integrated in a BMS with the use of gateways (spaceLYnk BACnet KNX).
Thank You,
Thomas Rhode
Schneider Electric
W. John Ruffing
8 years ago
Those are some interesting examples.
It seems worth noting other examples such as SNMP (Simple Network Management Protocol) TR069 which tend to focus on IT equipment, as well as protocols like RESTful and MQTT (examples of popular Internet of Things protocols).
However, OPC-UA is, perhaps, one of the more interesting protocols when discussing interoperability because it was designed to provide a common protocol language for the various industrial control manufacturers and other related fields.
One product I have found equally intriguing in terms of interoperability is a software product from Kepware which supports a wide range of industrial and IT protocols and facilitates interoperability among them and supports many of the well-know protocols out there.
That said, the lower-level standards from physical infrastructure, such as UTP cabling 1000-Base-T and its fore bearers, standards defining Ethernet and Industrial Ethernet, and wireless standards such as defined by the 802.11 family of specifications along with, perhaps, the most impactful protocol of all: IP, have been major contributors to where we find ourselves today.
I’m old enough to remember Arcnet, Thinnet, and Thicknet, Token Ring, ATM, and the list goes on. However good it may feel to have those days behind us, there is still a lot of work to do when discussing interoperability because it really impacts every layer of communication.
Even now, we still see industry leaders refusing to loosen their death-grip on the idea of a closed, proprietary system architecture.
However, the era where that kind of thinking was advantageous has come and gone. CTOs are less willing to link their career to a single manufacturer and hope for the best. The various vertical markets are converging at a rate too fast for there to be a clear single winner, nor does there need to be just one. If anything, open standards have helped drive economic success.
Companies whose only method of keeping customers is by locking them into a closed proprietary architecture instead of constantly innovating in order to continuously prove to their customers WHY they are the best value will find themselves discarded along the side of the road to progress. The demise of Nortel is but one example of a company failing to innovate and embrace open standards until it was too late.
On the other end of the spectrum is Tesla Motors’ recent release of its patents in order to drive the industry forward – realizing that a healthy ecosystem is more financially beneficial to them in the long run than to sit on this technology while the industry struggles to grow.
So yes, open standards ultimately deliver for more value to OEMs, integrators and customers, than they may cost OEMs in terms of opening up competition. In the end, it will be the companies that realize this the soonest and act accordingly who will be left standing – regardless of the industry.
In the end, the old axiom of history repeating itself when ignored continues to ring true.
W. John Ruffing
Jaimie Giarrusso
8 years ago
Thank you for your thoughts, John! Great information, indeed! I agree that there are many more examples or open protocols and that the speed of convergence is accelerating. Open protocols are simply not a choice anymore. This particular guide is focused primarily on industry-standard protocols in building automation. However, I will certainly take into account the protocols you mention in my next revision. Thanks again for sharing your great thoughts!