This will be part one of a two-part article where we discuss the three different kinds of openness and the specific specification language for achieving openness on projects.

Topic No. 1, open protocols

When folks want systems to communicate, they enter the design process with a sense of blind trust that the manufacturers will get it right. They assume that all systems will work together, and by the time the project’s finished, everything will talk with one another.

The reality is, this almost never seems to be the case. Some piece of hardware, protocol gateway, license, or form of technology is missed. And when this happens, the finger-pointing starts, and everyone gets irritated with one another. When approaching openness, you need to consider that open communication between two systems depends on those systems being able to communicate with one another. On the surface, that seems like a really obvious statement; however, the reality is a lot of folks don’t realize the ramifications of open protocols.

Protocols, quite simply, are a way of formatting communication. A sentence such as, “The dog bit Johnny,” follows a specific structure. An object — in this case a dog — performs an action. It bites, and it performs that action against someone, Johnny. Now, if we fail to follow the normal grammatical structure of a sentence, and we said, “Johnny bit the dog,” the sentence takes on a completely different meaning even though we’re using the same words in the sentence.

So, how do we resolve this?

Today’s technology systems communicate with one another; yet, in many cases, they’re doing so by utilizing different communication formats. This is where protocols come in handy. The problem with protocols is that some are not deemed open protocols. Now, this is becoming less and less of an issue as our industry continues to evolve, but in the early 21st century, right around 2000-2002, the forms of communication that would enable interoperability between systems and their availability was very limited.

Nowadays, we have LON, Modbus, and BACnet, each of which have their strengths and weaknesses. As a specifying engineer, it’s important for you to understand the capabilities of these protocols and what they enable you to do from an integration perspective. I’m not saying engineers need to be experts on these protocols; however, they do need to realize that BACnet/IP is not going to seamlessly integrate with LON/IP or Modbus/IP. Those three protocols will not seamlessly talk to one another. This point seems to be missed on many project designs and specifications.

We address this in our online course, BAS Protocol Fundamentals, and, unfortunately, not a lot of folks are talking about this. Despite this, protocols are still an incredibly important topic for specifying engineers who want to ensure that their systems are interoperable.

Next comes open procurement. As I mentioned, the word openness means different things to different folks. From a technologist perspective, I’m thinking about open protocols or open systems, but from a procurement perspective, my mind focuses on open procurement models. You see, one of the exciting things that is happening in our industry right now is the availability of control products lines that are independent of OEM requirements. What do I mean by that? In the past, there were some robust OEM product lines for control systems. The problem was that no one could actually procure these systems unless they were the OEMs.

Nowadays, we have systems that can be procured directly through distribution and supply channels that are open to pretty much anyone. Because of this, these products, when selected for a project, can provide multiple service options. This reduces both installed costs as well as life cycle costs. They give the owner a greater level of independence from a specific manufacturer. A lot of owners find this very attractive in that it enables them to avoid the dreaded 40-50 percent margin for post-installation service calls because there is more competition, and this has the effect of driving down the cost of service. We address this in our article, “How to Evaluate a Building Automation System.”

It’s important to remember to define what openness means to your end customers. In next month’s article, we will be discussing open systems and how to specify openness in your projects.