How to Evaluate Building Automation Systems Part 1
Smart Buildings Academy
Our training programs will increase the profitability and efficiency of your BAS employees.
Are you overwhelmed with how fast the BAS market is changing?
Do you find yourself struggling to keep up with systems and how to evaluate them?
Are you looking for an easy way to consistently evaluate BAS's that is vendor neutral?
If so you are in the right spot.?
I remember when I first started in the BAS space, I struggled to put things together and understand all the intricacies of systems. If it wasn't for a network of mentors I wouldn't be where I am today. I've been in your shoes and I am going to show you a sure-fire way to evaluate BAS's to make sure you select the system that is right for you.
I've gotten multiple e-mails from our customers asking me how to evaluate building automation systems. I searched Google high and low and while there was plenty of "sponsored" articles there were no agnostic articles that laid out the facts and only the facts.
Fortunately, that's why you all have me. As you know, I am the voice in the wilderness, reaching out and teaching our community.
Ok, enough of the cheesy metaphors.
Seriously though, there weren't any independent articles that I could find and everything I did find was written by a manufacturer
The Framework
Our industry needs a framework to guide it in selecting control systems based on facts and not emotions and flashy sales pages. Therefore, over the next several months I will be building out a framework that you can use to evaluate building automation systems. This framework will enable you to make wise decisions and compare systems based on quantitative rankings (facts), not fluff.
In each of the sections of this document I will detail out what the criteria is, what it means, and a ranking table for how to rank the criteria.
Criteria 1: Openness?
In this criteria, we will discuss the concept of openness and many of the misconceptions that exist around this concept. When you finish this section you will understand the core aspects of an "open" system. You will also understand how to quantitatively evaluate and rank systems based on their openness.
Criteria 2: Graphics?
Graphics are a criteria that many owners consider critical when evaluating building automation systems. But how do you evaluate graphics? Since every person has a different interpretation of what "good" is how can you quantitatively rank graphics? I tackle this question head-on in Criteria #2!
Criteria 3: Alarming?
Alarming, no single characteristic of Building Automation Systems has caused more problems than alarms. However, many of these problems can be avoided, if you know upfront what you want in regards to capabilities. In Criteria #3 I will give you this knowledge!
Criteria 4: Trends?
Trends are powerful, you hear?the term everywhere. Phrases like "Look at the latest trends", or "such and such is trending" are quite common, but what does trending mean? Trends track the performance of data-point(s) over a period of time. When you compare this performance you are able to then infer certain facts based on the data. For the rest of this article, I will use the term data-point and trend interchangeably.
Criteria 5: Configuration Tools?
Configuration tools, they make or break your ability to do just about everything you want to do with your BAS.
If you're like me you're noticing a trend here! Configuration tools are critical to the operation of your BAS.
Criteria 6: Controls Architecture?
Controls architecture?is?the fundamental design structure that determines if your BAS can grow with you and can expand beyond its current usage. A design structure is a framework or blueprint for how something will be built.
In this criteria, we are going to cover how a good controls architecture can build?capacity, redundancy, and expand-ability into your BAS.
Criteria 7: Support Infrastructure?
Support infrastructure, this name is really a misnomer as this topic is about so much more than support infrastructure, but hey, we got start somewhere…
In this criteria, we will cover support infrastructure but we will go even deeper.
This topic will bring together some of the concepts we’ve covered in earlier criteria and will also cover some new concepts.
At its core, this topic will teach you how to ensure you get open systems that you can support in-house or externally.
It will also cover, how to go about getting trained on these solutions and ensuring that you have consistent standards across your post-installation support.
Criteria 8: Training?
Training, there are three things that make training good.
First training must be aligned with the level of the user. Second, training must be delivered in a clear, concise manner where the topics build upon one another. Finally, the trainer must be able to engage the audience.
I'm not here to help you with that last one, but the other two, I can help you with those!
In this criteria,?I am going to teach you how to take your training to the next level. Whether you are the trainer or the trainee you will get something of value from this post!
Criteria 9: Legacy Support?
Legacy support, what does that term even mean?
To some, that means the BAS will support all forms of its older self...
Is that reasonable?
I mean, the current trend?is disposable systems that focus on software more than hardware.
But how does that coincide with BAS?
How can we balance the need to adapt to technological advances, while continuing to support customers installed systems?
This is a challenging topic, it's even more challenging when you look at it through the eyes?of the?specifying engineer.
How can this one person be expected to understand if your installed BAS, some of which aren't even around anymore, will tie into your new BAS?
Is it reasonable to expect the engineer to know this?
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
#1 Openness
Openness, ah the elusive term, I'm not even sure where this term came from, to be honest. I will tell you thing though, it seems as if everyone wants their system to be "Open" but when asked what open means you get several different responses. Therefore, prior to detailing out how to compare openness, I'm first going to discuss the multiple versions of what "Open" means.
As I see it, there are really four forms of openness and I have listed them in order of frequency that I hear them mentioned. These four forms are:
Open Procurement
Ah, the good ole' I don't want to be locked into a specific vendor fear. This is a valid fear, I mean if you're getting shitty service or ripped off by your controls contractor the quickest way to counter that is to have multiple buying options. So when most customers say they want an open system, what they are really saying is they want an open procurement model. There are pros and cons to being able to buy an offering from multiple suppliers. Let's discuss those.
Pros
With multiple suppliers, you will have cost pressure and competitive pressure to your advantage. In addition to this, you will have multiple places from which to source your controllers. Finally, you will have the ability to source from a wider pool of talent for your controls work.
Cons
The positive aspect of?having multiple suppliers can easily become a con when you start to have projects outside of a specific geography and this is because you will often lose consistency if you have multiple contractors executing across a geography. In addition to this if you buy multiple offerings you will have to learn multiple platforms, even with a platform like Tridium you will still have nuances for the different brands of a Tridium solution.
My Recommendation
My recommendation is to select a vendor you like and to go and request open book pricing from that vendor. Often times if you ask you can buy directly from that vendor's supply chain. This may take a little bit of Googling on your part but I've yet to find a vendor where you couldn't source controls direct from their factory if you talk to the right person. The reason I recommend selecting a single vendor is that it allows you to master a product and to provide self-executing support. However, I realize some customers may not want to self-execute. In that case, it makes sense to evaluate 2-3 brands, but do yourself a favor, look at only 2-3 brands rather than 8-10 and make sure the brands aren't all from the same company.
Open Protocol
Next on our list is the concept of Open Protocol. Open Protocol is another loaded term. I mean how many times have you heard someone say, I want my system to support open protocols! Um, ok, I want an ice cream sundae...
I mean really folks, do you want HTTP?
Do you want TLS?
Or are we talking about BACnet/IP?
The problem with this statement is that it assumes by saying the phrase "Open Protocol" the buyer will receive a solution that can play nice with other systems.
领英推荐
My Recommendation
However, this simply is not the case!
Action #13 in my article The Building Automation Optimization Checklist details out an upgrade process. The first step I mention is to detail out your existing systems.
Well, here is a contrarian approach to the current "Open Protocol" hype. Instead of specifying that protocols be open, list out your existing systems and state that the new system must provide an integration path or have native connectivity to each system.
Open Software
Quick, what programming tool do you use to connect to your Building Automation System?
If you and none of your people know, then you probably don't need to care about open software.
I see so many specifications that discuss providing open software or open configuration tools to the end-customer. The problem is we know most of our customers will rarely if ever log into the software. Therefore, you're paying for stuff your never gonna use. In the infamous words of Mugatu from Zoolander 1, "I feel like I'm taking crazy pills here!". (by the way, if you haven't seen Zoolander 1 go watch it, it's a funny movie).
Now, for those of you who are using the software here's a secret. You can often contact the company directly to buy their software. On a side note, I'll tell you, I'm just dumbfounded that I've yet to see any major company out there who shows how to use their tools online. We as an industry need to pressure our suppliers to catch up to the Internet Age.
That being said, open software is software you can purchase openly. Just because you have to pay a yearly license does not make the software closed. The software is closed if you can't buy it.
My Recommendation
Determine if you need and will actually use the software. If you will actually use the software then determine how you can procure it and what kind of licensing costs it may have.
Open Application Programming Interface
Finally, the most and least important definition of "Open" is an Application Programming Interface (API) or Software Development Kit (SDK). The API/SDK allows the end-user to develop integrations between devices and the building automation system. Think about it this way, imagine you are in Italy and you want to bake some bread. Don't ask me why you're baking bread in Italy but you are, just go with it.....
So, you need to go and talk to this Italian baker dude, and he's speaking Italian telling you how to bake. You don't understand Italian, but you do have a guide that you got from his website. It tells you that when he says farina it means flour, and so on. You then begin to build a recipe using this guide and next thing you know you've built an awesome loaf of bread.
Well, API's are like that they give you the ability to interpret and access data inside your building automation system so you can develop applications using that data. When folks are asking for an open API they are asking for the ability to access data and then a guide as to what that data means.
My Recommendation
Find out if an API exists, if it does exist find out if documentation and sample applications exist for this API as well. Finally, find out if there is a licensing cost for using this API (sometimes this is called a developer license).
So how then do you evaluate Openness?
Alright, this is all well and good but how do you take these concepts and rank the controls provider? Well, you're in luck as we discussed earlier in the article, we will be ranking each item on a scale of 0 through 3. I will detail out what a 0 and what a 3 looks like for each category.
Open Procurement
You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).
Please detail out how we can purchase future products for this building automation system.
The table below details out how you would rank the responses. (sorry Tables don't show up well on LinkedIn)
Open Procurement Ranking
Ranking Score / Ranking Description
0 You cannot purchase the controls except through a proposal from a sales person
1 You can purchase the controls, but only by going through the local branch or re-seller
2 You can purchase the controls from multiple re-sellers
3 You can purchase the controls direct from the factory
Open Protocol
You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).
Please detail out how you will integrate to the following systems (list systems and versions here). Please be clear if this will be a native integration or will require additional devices.
The table below details out how you would rank the responses.
Open Protocol Ranking
Ranking Score / Ranking Description
0 They cannot integrate or connect with any of the systems
1 The contractor can connect with less than 50% of the systems
2 The contractor can connect with greater than 50% of the systems but only using other products
3 The contractor can connect with greater than 50% of the systems natively ?
Open Software
You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).
Please detail out how we will purchase your configuration software and any and all licensing costs for this software. Please also detail out any software we cannot have or any limitations to our version of the software.
The table below details out how you would rank the responses.
Open Software Ranking
Ranking Score / Ranking Description
0 The contractor will not provide you with their configuration software
1 The contractor will provide you with a limited version of their configuration software
2 The contractor will provide you with a full version of their software but it requires a yearly license
3 The contractor will provide you with a full version of their configuration software for a one-time cost ?
Open Application Programming Interface
You would put the following verbiage in your request for proposal or request for qualification.
Please detail out if you have an open Application Programming Interface. Please also detail out if this API has documentation, sample applications, and if the API requires a developer license.
The table below details out how you would rank the responses.
Open API Ranking
Ranking Score / Ranking Description
0 The building automation provider has no API
1 The building automation provider has an API with no documentation
2 The building automation provider has an API with documentation, but it requires a developer license
3 The building automation provider has an API with documentation and it does not require a developer license ?
Follow our page to see the other 8 criteria in the coming weeks.
?
Building Controls Estimator, Pianist, Birdwatcher
2 年This is exactly what I've been looking for. Thank you for sharing!
BAS Estimator, BAS Designer, BAS Techincal Expert, Low Current Systems Sales Specialist
2 年Thanks for sharing