3 Evaluation Criteria for Protocols that you've Never Seen

If they do then you're not alone!

Ensuring that your BAS can communicate with an existing system is one of the most requested topics here on BAM.

Last week, I touched on the subject of legacy support. This week I will dive into protocols. When you finish this article you will have three steps to ensure your specifications address this pesky little topic.

Are you ready to take your specifications and BAS to the next level? If so join me in the final article of my 10-part series on how to evaluate your building automation systems.

Criteria 10: Supported Protocols

Protocols, protocols, protocols!

I swear, why can't our industry just standardize on a single form of communication! How many projects have you been on where that infamous spec language "shall be integrated by others" has delayed a project and cost you time, dollars, and headaches?

Protocols are defined forms of communications that can help you to tie two systems together and in this criteria we are going to deal with these pesky little buggers once and for all!

The Criteria

#10 Supported Protocols

So what are protocols? How can they help you integration your systems?

And most important of all, how can you ensure that your specifications address these fickle beasts?

It all begins with three fundamental changes in how we write specifications

1. Get rid of to be integrated by others
2. Define who's in charge
3. Layout a data model

Let's dig in!

Get rid of to be integrated by others

Ah, the age-old, blame shifting specification language of "Integrated by others". When in doubt, let others integrate.

I want to be clear, there are good reasons to have subcontractors and manufacturers figure out integration. However, in the case of integration, a little bit more should be added to the specification.

What should be added you ask?

Let's think through a protocol integration. You are taking two systems that supposedly speak the same protocol and tying them together.

Everything should work seamlessly right?

Well, what if the two systems use different versions of the same protocol. Who reconciles this?

Who figures out how to get things to work?

Can you hold a system manufacturer or subcontractor liable if the system they are connecting to does not support the latest version of the protocol being used?

My Recommendation

This is where I recommend the following specification language replace the to be integrated by others language.

ABC system will be the lead system for this integration. XYZ Systems will need to be compatible with the protocol used by ABC system. Manufacturer of XYZ system will be responsible for ensuring this compatibility.

This is a minor tweak on the to be integrated by others language. But it this little tweak creates some very valuable changes.

First, it defines who is the lead system and in turn the lead contractor for the integration. Second, it details that all other systems must be compatible with the main system. Finally, this language details out that the manufacturer shall be responsible for ensuring this compatibility.

Define who's in charge

If you ask my wife, she's the one in charge. That's the way marriages go in America :-D

Well, my friends, when it comes to projects everyone thinks they are in charge. Everyone tends to think their system is the most important system and that it should take the lead.

And that is where the issues start. Imagine this, you have an access control system, that when activated turns on the lights to a building. But wait, the lighting controller also has a sequence to turn on the lights. Oh, and so does the Audio Visual system...

So who wins? How do we make sure that this lighting control sequence doesn't become a crazy, finger-pointing extravaganza of meetings?

We do this by defining the primary and secondary systems.

Do you remember the language I used in my previous section?

Oh come on now, you should remember it, you just read it! Well here it is for you again.

ABC system will be the lead system for this integration. XYZ Systems will need to be compatible with the protocol used by ABC system. Manufacturer of XYZ system will be responsible for ensuring this compatibility.

This language clearly shows that ABC system is the lead system, but what does that mean? Sometimes you need to lay that out, but how?

My Recommendation

I recommend that you detail out the use cases and you detail out a command flow or "Use case model" to show how these systems will talk.

Now some of you are like, um Phil, we are engineers or owners, this is great and all but that's what that the contractors do.

Ok, but what contractor? The BAS contractor? The Security Contractor? The lighting Contractor?

WHICH ONE?

It's tough, I know its tough, but if you are going to have integrated use cases you need to define who is in charge.

Being in charge means that your systems commands have the highest priority level. When you issue a command all other commands will be overridden.

This is a powerful capability, and without proper planning this can cause many post-installation job-site meetings!

Layout a data model

Finally, the last section of the last article! Well, folks this is the final tidbit I will leave you with.

Layout a data model!

For those of you who just said "a data what?", a data model is a way to show how data moves from one system to another.

Data models are becoming increasingly important because systems are becoming IP based and are using protocols and API's to tie to one another. This means that the "designers" need to understand how these systems communicate. The days of simply picking 3 systems based on price are gone.

You now need to consider how a system will communicate. The best way to do this is to layout a data model. Fortunately my next series will be on systems integration and will cover this exact topic.

In order to layout a data model you need to identify each of the systems and then layout how they will communicate and what they will communicate with one another.

Now how in the world can you fit this into a specification?

My Recommendation

My recommendation is that you create a data model whenever an integrated use case is being used. You would show the systems that are being integrated and you would show how they are communicating. The final piece would be to show which system is the lead system.

Will you use this on common every day specifications? Of course not!

But, you definitely should use this on your larger projects. This method will save you so many headaches!