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 subscribers 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.

  • Want to add a field controller? You need a configuration tool.
  • Want to back up a database? You need a configuration tool.
  • Want to adjust graphics and core settings? You need a configuration tool.

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
  • Open Protocol
  • Open Application Programming Interface
  • Open Software

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.


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.


The postivie 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.

[table id=1 /]

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.

[table id=2 /]

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.

[table id=3 /]

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.

[table id=4 /]


#2 Graphics

Graphics, I still remember my first experience with graphics I was asked to design a commissioning interface for an Intel fabrication plant. I was working for Alerton at the time and I remember cutting and pasting about a dozen points for a couple hundred boxes onto a single graphic. In my mind this was a work of art, I mean you could get to everything you needed on this single graphic, it was Epic. Unfortunately, the only epic thing about my graphic was how Epicly it failed to get used.

How many times have you experienced graphics like that? My earlier post on building automation system optimization discusses setting up graphics templates in great detail. I realized, however, there was a need to evaluate graphics. This post will discuss how you measure the functionality of the actual graphics software.

There are three main areas I evaluate when I am looking at graphics packages. These three areas are:

  • Mobile Support, Responsive, HTML Interface
  • Graphics Configuration Software
  • Graphics Library

Mobile Support, Responsive, HTML Interface

Mobile devices are everywhere, ask anyone in the United States, where I live, and they most likely have a smart mobile device. However until just recently Building automation manufacturers support for mobile devices resembled some form of bastardized Frankenstein monster. However in today's day and age you should expect to be able to access your building automation system via your device. But, access is not enough, access isn't worth a damn if the layout sucks and you can't actually get to the data you need! This means that the graphics should be optimized for mobile support and responsive to the device type!

What does responsive mean? Well if you are looking at this screen I'm going to show you the concept of the HTML Box model.

Box Number 1
Box Number 2

If you see the two boxes above on your PC they are set up with what is called a Div tag where the HTML element (fancy way of saying the text) is wrapped in two divs (boxes). Box one is 2/3rds of my screen and the box 2 is 1/3rds of my screen. Now I have my site set up to be mobile friendly and responsive. So if you go open this post up on your mobile device (go try it, I'll wait)....

Did you notice how the boxes went from being side to side to above one another? That is a responsive design, your web browser knew based on my HTML code to stack the boxes instead of displaying them side by side. Cool right?

That is why on some BAS graphics you get all of the elements displayed in really tiny font vs the font size being responsive to your device type!

The HTML/5 portion is the "latest" version of the Hypertext Markup Language (HTML) standard and it supports all sorts of mobile-friendly code options. That is why it is critical your graphics package support HTML/5!

My Recommendation

This is the area you really should not budge on. Look, you can get by without having access to graphics configuration software and with a limited graphics library but how do you fix your BAS software to be mobile responsive? Well, you can buy another software package but that defeats the point of having a BAS and another set of software for graphics... Don't budge on this category, you will regret it!

Graphics Configuration Software

I've seen good and I've seen bad. I've worked with software packages where I literally went pixel by pixel changing the color the duct work on an air handler graphic to make it look like the air handler duct blended seamlessly with the new damper or fan I added. That sucked, and I wasted days of my life doing this. With a good configuration software, you won't have to do this! Surprisingly there are still BAS providers who don't offer their Graphics Configuration Software to customers!

Now, this is bad but it's not that bad! The reality is in my experience it's been 50/50 as to whether a customer would really use the software in the first place. So ask yourself, if you are not going to be creating graphics then you may not need to worry about the graphics software. Also, if you read my post on creating graphics standards then you may not ever need to create graphics again, seriously!

My Recommendation

My recommendation is that you decide really quickly if you will be doing a lot of graphics changes? Do you execute a fair amount of your work in-house? Do you own tenant centric real-estate that is constantly being reconfigured? If so you may want to look into graphics configuration software.

Graphics Library

If you self-execute graphics there is nothing like a good graphics library. A graphics library can make or break your productivity in developing graphics. On the flip side a bad graphics library, well, it sucks! I've worked with graphics packages where literally I had a few boxes and 2 different gauges. It's almost like a game at that point to see what kind of display you can create with boxes and gauges. That's why you need to find out about your BAS providers graphics library, even if your building automation provider has a mobile-friendly, responsive design and some nice configuration software!

My Recommendation

When you look at a graphics library you are really looking for three things. First, is there even a graphics library. Yep, seems obvious but if there isn't a library then you're going to be very limited in what you can produce!

Next, you need to look at what is in the graphics library? Is there a large list of graphics items (stencils)? Or is it 3 boxes and a temperature gauge?

Finally, you should look into whether or not you can add your own graphic stencils and what formats are supported. There are some great graphics providers out there but if you can't bring their graphics into your system then you are really limiting yourself.

How do you evaluate Graphics?

Mobile Support, Responsive, HTML / 5

You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).

Please detail out how your graphics support a variety of browser and device types, if you graphics package is responsive, and if it supports HTML/5.

The table below details out how you would rank the responses.

[table id=5 /]

Graphics Configuration Software

You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).

Please detail out if your graphics software is available to customers, if it requires HTML expertise, if it supports multiple image types, and if it has a graphics library.

The table below details out how you would rank the responses.

[table id=6 /]

Graphics Library

You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).

Please describe your graphics library that is available to users and if users can add their own stencils to the library

The table below details out how you would rank the responses.

[table id=7 /]


#3 Alarming

When it comes to alarming I've seen the good, the bad, and the just plain weird... I've been to buildings with 50,000 unacknowledged alarms, I've seen customers purposely expose their BAS to the internet just to avoid losing connectivity, and I've seen great setups that prioritize and route alarm messages. In this section, I am going to take that collective knowledge and wrap into three buckets that you can use to evaluate your BAS's alarming capabilities

  • Alarm Prioritization
  • Alarm Sequencing
  • Alarm Transmission

The way I ordered these capabilities is by design. If you can prioritize your alarms then you can properly sequence them to the right person. It is only after you know who the right person to send the alarm to that you can actually send the alarm out effectively.

Alarm Prioritization

Alarm prioritization is all about making sure the important alarms show up and are not crowded out by unimportant alarms. This seems simple in theory but can get complex when the concept of important varies from user to user. For example, power could be a very important measurement point for a plant operator but not for a technician. That is why when I discuss the topic of prioritization I specify that the prioritization must be contextually aware.

This means that the system is aware of who is signed into the system and the points that are important to him/her. This takes some work up front but if you read my article on BAS optimization you will understand how to create these standards.

My Recommendation

My recommendation is that you ensure that any system you put in has the capability at a minimum, to apply prioritization to alarms. You do not want dirty filter alarms reporting at the same priority as a failed plant controller.

Alarm Sequencing

Alarm sequencing involves two things one is repetition and the other is escalation. They both build upon one another. Once the alarm is triggered the person who the alarm is sent to, should have a certain amount of time to acknowledge the alarm, based on the alarms priority level. If this alarm is not acknowledged then the alarm is repeated and escalated to the next level person. This is a very important concept, yet it is one that I've seen very few solutions implement. The reason behind this is that creating and maintaining the escalation map is difficult as people enter and leave the organization.

My Recommendation

My recommendation is that you do not let progress be the enemy of perfection. If you cannot implement alarm escalation, you should at least try to implement alarm repetition. In this case, at least the person who is receiving the alarm will get continuously notified until they address the alarm condition.

Alarm Transmission

In today's day and age, there are so many ways to send information and it seems a new way pops up every day. The good news is that in the BAS world the format in which alarms are transmitted has remained relatively constant. The primary forms of communicating alarms are e-mail, SMS text, paging, and Simple Network Management Protocol. Using these four forms of transmission you can cover the majority of communication methods.

My Recommendation

My recommendation is that you at a minimum support e-mail transmission and one more form of transmission. The reason behind this is if your e-mail server dies, you still have another method of transmitting alarms to you staff.

So how then do you evaluate Alarming?

Alarm Prioritization

You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).

Please detail out how your alarms are prioritized and how your prioritization works

The table below details out how you would rank the responses.

[table id=8 /]

Alarm Sequencing

You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).

Please detail out how your alarms are sequenced and the sequencing capabilities of your alarming system.

The table below details out how you would rank the responses.

[table id=9 /]

Alarm Transmission

You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).

Please detail out your alarms are transmitted and the transmission capabilities of your alarming system.

The table below details out how you would rank the responses.

[table id=10 /]


#4 Trends

Ok, so trends, we've got to have them, their super useful, but so many people don't use them, why?

There's a couple of reasons. First, there is no real training around utilizing trend data. Fortunately, that topic was covered in a series of early posts of mine that you can read here, here, and here.

The second reason, which we will address today, is that some systems seem to have been designed with less than optimal trending capabilities. When you trend something you want the ability to compare past data-points.

For example, if I tracked my outdoor air temperature, my chilled water reset temperature and all of my space temperatures, over time I could infer if my chilled water reset was working.

The problem is, in order to gain insights from this data, your software requires the following key capabilities:

  • The ability to store trend data in a database that is common to the industry
  • The ability to access trend data from inside and outside the BAS
  • The ability to visualize trend data

The way I ordered these capabilities is by design. If you can't even store trend data, then we aren't going to get very far :-D.  Once you have the trend data stored, you need to make accessing the data easy from inside and outside the BAS. Finally, you'll want to visualize (see) the data and how that is done is critically important.

So buckle up and get ready for the journey through trending capabilities!

Storing Trend Data

Storing Trend data is important, I would go as far to say that storing trend data is of critical importance. If you can't store trend data then you can't access or visualize the data. So, what does storing trend data mean.

Quite simply, when data is created three things can happen to it:

  1. You can share the data with a user interface
  2. You can do nothing with the data, thus it gets cleared out of memory (deleted)
  3. You can store the data in a storage device

In the case of trend data, the most common form of storage is a database. While this article won't go into an exhaustive look at all forms of databases we will briefly cover the three most common types.

The first database type is the "Flat File' database this is a text file which the data-points are added to.

The second database type is the proprietary database, this is a custom database created by a vendor to store their data-points.

The third database type is the relational database, this is the most common database in the market right now.

There are obviously more database types than these three but in the BAS world, these are the most common.

When trend data-points are created by the BAS two things can happen.

First, they can be streamed directly to the database. This means that the trend data-point is sent to the database as it is created.

The other method for trend data-point storage is called batching. Batching is a process where the trend data-points are collected and stored locally on a BAS supervisory device until a threshold is met. At this point, all of the trends in the batch are sent to the database.

Once the trends reach the database they are stored in the appropriate database so that they can be accessed at a later point.

My Recommendation

My recommendation is that you select a BAS that has a common database like SQL, MySQL, Oracle SQL, or Postgresql. Any of these four database formats will provide you with the capabilities to store massive amounts of trend data. They will also give you the ability to access, query and report on data at a later point.

Accessing Trend Data

Now if you have all of your data-points stored in a database the logical next step is to access your data-points. In order to do this you need two things:

  1. A way to access the data-points
  2. Privilege to access the data-points

When I say you need a way to access your trend data, what I am saying is exactly that. For example, some BAS systems use Microsoft SQL Server to store their trend data. In this case, you need to have the SQL Server software to access the trend data. Some BAS manufacturers have their own database software that is not openly available to the public.

Privilege is another concept to understand. The concept of privilege addresses who can access the trend data and what data they can access. This is an area that can get locked, either intentionally or unintentionally. It is important to address this issue in the specification or RFP process that way the controls manufacturer is contractually required to deliver an open database.

My Recommendation

My recommendation is once again that these capabilities be required as part of a standard BAS scope. Without the ability to access your trend data you will find your ability to analyze historical performance and to troubleshoot issues severely hampered.

Visualizing Trend Data

The final functional area of a system that has good trend data support is the area of visualization. You can have the ability to store and access your trend data and still not be able to make heads or tails of the data. The single greatest factor in effectively using trends for troubleshooting, outside of having the right trends setup in the first place, is how well you are able to visualize your data.

A good trend visualization platform will support:

  1. The ability to segment the trend data by time, type, and value
  2. The ability to present the trend data in multiple formats
  3. The ability to send out the trend data in multiple formats

My Recommendation

You should request samples of any features and functionalities you believe you will be using. Often times vendors can give you access to demo sites as well as screenshots of the actual features you are requesting.

So how then do you evaluate trends?

Storing Trend Data

You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).

Please detail out how your trends data is stored, where it is stored, and what database type is used for storage

The table below details out how you would rank the responses.

[table id=11 /]

Accessing Trend Data

You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).

Please detail out how your trend data can be accessed and who can access it

The table below details out how you would rank the responses.

[table id=12 /]

Visualizing Trend Data

You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).

Please detail out your trend data is visualized by the end-user

The table below details out how you would rank the responses.

[table id=13 /]


#5 Configuration Tools

Really Phil, configuration tools? How the heck can we evaluate something that is vendor specific...

Ah, my friend, it's easier than you think. At the end of the day, configuration tools do three things:

  1. Configure and Program Controllers
  2. Adjust and Customize Settings
  3. Create and Backup Databases

As always, there is a reason for the order I put these capabilities in.

As I looked back at the hundreds of buildings and thousands of projects I've done in my career I noticed there was a process for how I completed tasks.

Whether it was a service call or a new installation, my projects usually started with me configuring or programming the field controller.

From here I would then adjust settings, configure my default set-points, setup new graphics, etc.

Finally, I would either create a database or backup everything I did to the current database.

When I thought about these tasks, I realized there were three distinct tasks that may or may not be in the same tool. So, without further ado let's dive into... Configuration Tools!

Configure and Program Controllers

Have you ever found yourself wanting to change something in your BAS controller?

How much did it irk you to find out that you couldn't get into the controller because the installer or service company before you locked the controller, didn't leave the configuration files, or didn't give you the configuration tool?

Whether you are a vendor or an owner, if you've been in the BAS world for more than a couple of years you have probably encountered this!

The first capability I recommend, for any BAS configuration tool, is the ability to configure and program BAS controllers and supervisory devices.

What does this look like?

The configuration covers everything from addresses, interfaces, naming, and other general settings on a BAS device.

Programming is the ability to connect to the device and to set up logic inside the device. This should include programming whether you are physically connected or remotely accessing the device.

My Recommendation

My recommendation is that at a bare minimum you should have the ability to configure devices.

You should also have the ability upload/download programs to and from the devices. Some folks will want to go a step further and include the ability to actually program the devices.

Adjust and Customize Settings

While adjusting and customizing settings is similar to the configuration of devices it does differ just enough to be its own category. When I say adjust and customize settings what I am referring to is the ability to change hard-coded settings.

The difference between hard-coded settings and regular set-points are that hard-coded set-points are set in programming.

An example of this would be calibration factors for air-balancing. You don't want just anyone to be able to log into your BAS and start changing air-balancing values.

In order to accomplish, this you need the ability to connect to the existing database and/or field controller to configure these settings.

My Recommendation

If you self-perform a lot of your BAS tasks, I recommend that your BAS have the capability to adjust hard-coded settings. This will allow you to avoid costs associated with re-configuring systems.

Just do me a favor, don't try to overcome this limitation by making your settings adjustable through your graphics, I've done too many service calls to fix these kinds of issues..

Create and Backup Databases

If there is one area that has caused me more heartburn than any other, its databases.

In the beginning, I didn't realize the importance of saving early and saving often...

Learning that hurt...

But, without the ability to create and backup databases you are effectively dead in the water.

Let's say you want to be able to create an off-line version of your database to test changes. Well, you need the ability to both backup the current database and create a new database.

Every project begins and ends with a database, whether it is a retrofit or new construction project. So then doesn't make sense to make sure you can access the database capabilities of your BAS?

My Recommendation

Even if you don't self-perform a single task you still need this capability. Let's say that you were relying on the vendor to back up your databases.

What if their system crashes?

With some systems, if you don't have the ability to back up your databases those databases can be lost.

Configure and Program Controllers

You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).

Please detail out how your configuration tools allow users to configure and program controllers

The table below details out how you would rank the responses.

[table id=14 /]

Adjust and Customize Settings

You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).

Please detail out how your configuration tools allow users to adjust and customize settings

The table below details out how you would rank the responses.

[table id=15 /]

Create and Backup Databases

You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).

Please describe how your configuration tool allows users to create and backup databases

The table below details out how you would rank the responses.

[table id=16 /]


#6 Controls Architecture

In my experience, controls architecture is something that is not often considered. This is unfortunate as the architecture of the BAS can impact the entire life-cycle of the control system.

To counter this, I am going to teach you the following three key criteria related to controls architecture:

  1. Designing the Right Amount of Capacity into your Architecture
  2. Ensuring that your Architecture Provides Redundancy
  3. Building in the Ability to Expand your BAS in the Future

As always, there is a reason for the order I put these capabilities in. So, rather than belaboring the point I'm going to jump right into each of the criteria.

Designing the Right Amount of Capacity into Your Architecture

Have you ever gone to expand your BAS system only to find out the supervisory device is over capacity?

Doesn't that suck?

I remember one time where a project manager and I spent all night at a commercial office building switching out a supervisory device. This device had been installed at 120% of its design capacity, how does that even happen?

I'll tell you how it happens.

It happens because the capacity is not properly specified in the project. But how can the designer know how much to capacity to add?

Furthermore, how can the owner know that excess capacity isn't being added just to inflate a contractors scope?

This, my readers is where the project standards come in handy.

If you have established naming and point standards then you can ensure that you know exactly how many points you have on a system.

At that point, it's as simple as specifying that all new controls designs include a certain excess capacity %.

If you haven't established standards, I have an article that walks you through that process. You can read it right here.

Some of you might be asking, the capacity of what?

Good question.

Most BAS devices have capacity limitations. These limitations dictate:

  • How many points can be mapped to the supervisory device
  • How many trends, graphics, and alarms can be created in a supervisory device
  • How many physical inputs are left on a field controller

The thing is, these limitations often aren't considered.

So, then how do we determine what a good capacity threshold is?

My recommendation is to include 10% excess capacity.

If you have a 50,000 point system (which is the equivalent of a large commercial office building or large hospital) then you would basically be including 1 additional supervisory device and about 20 additional field controllers.

My Recommendation

As I said earlier, my recommendation is that you consider 10% as your baseline capacity threshold. This will give you about 500 points on each supervisory controller and about 3 extra inputs and outputs on an average field controller.

This will allow you to add occupancy sensors or energy meters at a later date.

Ensuring your Architecture Provides Redundancy

I once worked on a data center that housed the server for all of American Idol's online traffic. The downtime of this server was around $3M per minute. No one at procurement thought twice when we proposed duplicate servers and controls for system redundancy.

With the appropriate ROI redundant architecture is not a problem.

I'm not going to cover how to calculate ROI or how to determine if your risk value is high enough to justify building redundancy into your architecture. If you'd like to learn about that be sure to check out my article where I cover disaster recovery and risk.

When you build a redundant architecture you are looking for redundancy in 3 key areas:

  • Redundant Servers
  • Redundant Field Controllers and/or Equipment
  • Redundant Supervisory Devices

Redundant Servers: is the first level of redundancy and is often the easiest of the three to implement. With server redundancy, you will be focused on "virtualizing" your server. This means you will put your server on a virtual machine, which will allow you to easily "bring back up" a server if another server fails.

Redundant Field Controllers and/or Equipment: is the second level of redundancy. At this level, you identify critical spaces and/or equipment. You then serve this space with two identical sets of equipment. This equipment will often function in what is called a lead-lag scenario (this also called M+1, meaning mechanical device + 1). If the lead device fails the lag device will take over. This is usually done via hardwired alarming.

Redundant Supervisory Devices: is the third level of redundancy and is the most costly to achieve. In this scenario, the entire supervisory device and all of its field controllers are replicated. Only the most critical of spaces warrant this kind of investment. In my experience, I've only seen two buildings implement this scenario and I can't name either of those buildings.

My Recommendation

In most cases simply virtualizing the servers will do. However, you must ensure that the BAS can support virtual servers. You must also verify that the BAS can support lead-lag control, which most modern BAS can

Building in the Ability to Expand your BAS in the Future

This is less of a technical requirement and more of a combination of previous categories, because of this I will not be including specification language for this category. The important point when it comes to being able to expand your BAS in the future is that you are able to procure materials, utilize field tools and perform configurations.

Each of these topics has been previously covered in this article.

My Recommendation

My advice is that you decide early on if you will ever be expanding your system. To be clear, I am talking about large-scale expansions. This is different than adding a sensor or a new VAV box.

If you will be expanding your system then you need to consider the points I mentioned earlier around your ability to procure materials, utilize field tools and perform configurations.

Designing the Right Amount of Capacity into Your Architecture

You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).

Ensure that the BAS has 10% additional logical and physical capacity

There is no table as this is purely specification requirements language.

Ensuring your Architecture Provides Redundancy

You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).

Please detail out how your BAS supports redundancy (e.g Virtual Servers, Dual-Field Controllers, etc.)

The table below details out how you would rank the responses.

[table id=17 /]


#7 Support Infrastructure

Support infrastructure is where companies seem to fall flat.

I very rarely go onto a job and hear that a company was terrible at order parts or installing the thermostats. Usually, what I hear from folks, is that the company just disappeared or that the installer made it so that no one but them could work on the BAS installation.

For some reason in the BAS space, companies seem to be either good at installation or good at service.

Every once in a while you will find a company that is great at both. I think this has to do with the fact that installation and service require completely different skill-sets, but that's another topic for another time.

When it comes to post-installation support  there are 3 areas that need to be addressed:

  1. An open system, that allows you to work on your BAS
  2. A regional organization with consistent design principles
  3. The ability to get on-demand, just-in-time training

Let's jump into the areas!

An open system, that allows you to work on your BAS

I'm not going to go super deep on this area. After all, we spent an entire Criteria, Criteria #1 Openness, on this area.

So, why am I bringing this area up again?

In the world of BAS, you can't support what you can't access and some folks have a nasty habit of holding onto or locking up key information.

Examples of this would be, locking or retaining a key database that is required to upgrade a BAS or not providing the end-user with the code for the field controllers.

This results in a service call whenever the end-user needs to make changes to their system. As you can imagine, this gets very old, very fast.

The problem I've seen is that folks will often misdiagnose this as a product problem.

What do I mean by that?

What I mean, is that folks will get a vendor who doesn't share the database or code with them or who locks the system to a certain access level. They then assume the BAS is the cause of this issue.

It is, but then it isn't.

See, if you simply go and specify a different system you aren't fixing the issue. The issue is not the system.

The issue is the practices.

And that is why I am going to make the following recommendation.

My Recommendation

In order to support your installation past warranty, you need some basic things. These things are:

  • Make sure you get all the files you need. Databases, controller code, configurations, as-builts, don't let a job complete without them!
  • Ensure you have full access. Do not accept anything less than administrator access on your BAS. Even if you never use the administrator account, make sure you have access
  • Get the tools you need. I recommend that if you plan on doing any self-support you at a bare minimum get the configuration and programming tools for your BAS

A regional organization with consistent design principles

ZN-T, RM-T, TEMP....

Ahhh standards drive me bat-crap crazy!

Seriously, there is nothing worse than showing up on a job and having a different naming standard for each building.

Oh, wait, I lied...

There is something worse than not having standards. Do you know what that is?

It's having standards and then having your support people across the country starting to change them!


Seriously, this is a massive problem. So many folks will work on creating standards for their BAS only to have them messed up on the first controller replacement.

This my friends is a big issue and its one, that not properly dealt with can make your life miserable.

That is why, if you have an installation that stretches outside of the geography of your service provider, I recommend you do one of two things.

You either, create standards that you can share with multiple companies or you get a service provider that can service across your entire geography.

By the way, I discuss how to write standards in my Optimizing a BAS article

My Recommendation

You need standards, you desperately need standards.

Not just for install but for post-install as well. At the end of the day, there's really only 3 post-install tasks you need standards for:

  1. Replacing Controllers
  2. Adding Controllers
  3. Changing Points and Graphics

Spend the time to detail out your naming standards and to detail out how these three processes take place.

You will thank me for this.

The ability to get on-demand, just-in-time training

Training? Hmm, isn't training Criteria #8 in this series?

Yes, you're right, but we aren't talking about how to make training effective. We are talking about something completely different.

In order to ensure that you are able to support your BAS you need to have just-in-time training.

This can come in many forms, but the most common I've found are:

  • On-demand video training
  • A robust class library, augmented by on-site classes
  • A robust document library

Each one of these is important in their own right.

But if I had to pick one it would be a robust document library. I am still amazed by how many businesses hide their technical documents from the world.

Literally, with some companies, I feel like I'm playing "Hide and go Google" just to find their technical documents. I don't get why these companies make it so damn hard to find their technical publications...

My Recommendation

My recommendation is that you ensure that any controls solution you want to pursue has a good amount of technical documents readily available.

I also recommend that this controls company provides you the ability to get just-in-time training via on-demand learning and regularly scheduled classes.

An open system, that allows you to work on your BAS

You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).

Please detail out the level of access to the system and the tools that will be provided to the owner at the completion of this job.

[table id=18 /]

A regional organization with consistent design principles

You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).

Please detail out how you will install and/or support installations outside your region. How will you coordinate with other vendors post installation?

The table below details out how you would rank the responses.

[table id=19 /]

The ability to get on-demand, just-in-time training

You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).

Please describe what kind of training and technical documentation is available for the user

The table below details out how you would rank the responses.

[table id=20 /]


#8 Training

In this post, I am going to address the 3 primary points of failure I see in most training programs, especially those programs that are cobbled together at the end of a project, come on you know you've experienced that before :-D

The three points I will cover are:

  1. Multiple Levels of training for your team
  2. A clear thought out training plan
  3. Self-Guided Training Programs

Let's dig in!

Multiple Levels of training for your team

You need to set the right level of training for your team.

But how do you do this?

The process I used has two parts, "The Context" and "The Build".

The first part I'm going to address is context. When you are training folks you need to understand the level of the audience. That is why whenever I would do training I would send out a pre-training form to my customer. You don't fill it out, I don't train you. Now granted, you have to have management support on this cause people will fight this at first.

But here's the deal.

If I am going to ask for 40 hours of your time, shouldn't I know where you are at with your knowledge? I mean if you've been installing and programming controls for 20 years and I come in and say here's a schedule and this is what it does. I've lost you, at that point your gone, and I'm going to struggle to regain you.

If my survey shows that a third of the group is at a beginner skill level, one third is at an intermediary skill level, and the final third is at an expert skill level then wouldn't it be better if I broke my training into three groups?

Here's a concept, would it be better for me to know where you are and divide my 40 hours across the different types of people?

This is what I call the build.

My Recommendation

My recommendation is that you first send a survey to your audience.

With the survey results, you will be able to profile your audience. Then work with the client and tell them you will be holding three classes across, their three skill levels.

Side note, you will be surprised how many folks are grateful that you are training by skill level.

Now for the build, I've hinted at it and now I am going to cover it.

When you train a group of folks at different skill levels you want your training to naturally build upon itself.

For example, you may start off with the fundamentals of point commands, scheduling, etc. Then these will build into graphics creation and modification, which may then building into basic programming.

You get the point, lay the foundation and then build upon it.

Set natural breaks in the training so that the intermediary and advanced folks can join at the right point.

A clear thought out training plan

How many times do you show up to training at the end of a project and the trainer says something to the effect of

"Ok, what would you all like to cover today?"

Come on, I can see some of you wincing out there. You've either sat in this kind of training or you've been the trainer yourself.

That's ok. After today you will have a clear plan.

So what makes a good plan?

In my experience, there are 3 levels of a BAS technician's career and at each of those levels, there are 6 things you need to know. So get your pen and paper out, or maybe just highlight and print these next few paragraphs.

The New Tech

  1. How to command points
  2. How to schedule points
  3. How to view alarms
  4. How to override points
  5. How to access graphics
  6. How to view trends

The Experienced Tech

  1. How to modify graphics
  2. How to set up trends and alarms
  3. How to create interlocks and global logic
  4. How to perform basic programming
  5. How to add points and controllers
  6. How to backup databases

The Master Tech

  1. How to create graphics
  2. How to perform complex programming
  3. How to "pull-in" integrations
  4. How to create new databases and backup existing ones
  5. How to backup controllers and add in third-party controllers
  6. How to work with IT, databases, server setup, IP addressing, subnetting, etc.

Now obviously you can't cover all of these topics in a 40-hour training session.

This is where the survey from the previous criteria comes into play.

If you survey your customer/technicians, then you can show them these levels and say rank your abilities on a scale of 1-10. Then as you build your training schedule you can bucket the skills that you need to teach.

My Recommendation

Take your survey results and bucket the skills that your customer\technicians need. Then look at the skills that logically build on one another.

Ask yourself questions like "Can you perform complex programming if you ranked yourself a 1 on basic programming?"

Most of this stuff is common sense but then common sense isn't common is it?

Self-Guided Training Programs

At the end of the day, you are going to have folks who are going to forget 80% of what they learned in training.

How do I know this?

I'm one of those people!

Look, you go back to work from training and immediately your sent to work on a chiller that no matter what just keeps short-cycling. After spending 3 weeks to find out that the sequence of operations never would work, you return to your regularly scheduled job to work on the BAS.

If you're like me, you're excited, you're ready to show off those new skills.

But... You've forgotten what you learned.

This is where self-guided training comes in. If you had training you could access after your training was done then you could simply look up what you needed to know.

My Recommendation

You should work with your BAS provider.

Ask if you can record the training. Store that training for a later date.

Or better yet, here's an idea I used to use!

Go to your vendor's service group. Sit down with the salesperson and set up a training agenda. Then buy some block hours and start recording the training. Build up a training library and host it on a private YouTube Channel.

You now have a training program that you can put your technicians through!

Multiple Levels of training for your team

You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).

Please detail out your process for identifying the levels of training required for our team.

[table id=21 /]

A clear thought out training plan

You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).

Please detail out how you will develop your training plan.

The table below details out how you would rank the responses.

[table id=22 /]

Self-Guided Training Programs

You would put the following verbiage in your Request For Proposal (RFP) or Request For Qualification (RFQ).

Please describe the availability of on-demand training for our team.

The table below details out how you would rank the responses.

[table id=23 /]


#9 Legacy Support

Legacy support.  At some point in your career, you are going to have to deal with legacy issues. Funny enough, it was this exact topic that springboarded my career forward.

You see, most folks don't have a solid plan for supporting their legacy BAS. This is because the only way you learn about legacy BAS is through experience.

At this point, you have a choice to make.

You can figure it out as you go, or you can join me in exploring the 3 questions that I ask when I am evaluating legacy support.

Those questions are:

  1. What systems are supported?
  2. How are those systems supported?
  3. How is the BAS product life-cycle managed?

Let's dig in!

What systems are supported

Where to begin?

Unpacking what systems are supported is like trying to decide what food to eat first at the Chinese buffet, there's just so many choices! The first thing we can explore is the meaning of legacy systems.

From my perspective, a legacy system is a system that is no longer produced, marketed, and sold by a company.

For example, the first company I worked for was Alerton. At the time they were ending support for their IBEX system. IBEX was an older BAS that Alerton had produced.

Alerton used the gateway method, covered later in the article, for supporting the older installed IBEX product. This meant that folks like myself would have to go and survey the installed solutions.

I would then go and create a bill of materials for "integrating" the legacy solution into the new one.

The trick is how do you know what legacy systems you have in the first place?

At first glance, this main seem like an easy question to answer. However, when you start to evaluate what BAS systems you have installed it becomes quite a task.

Here is the best way I have found to understand what systems you have.

  1. Index your mechanical equipment, detail out where any of your HVAC systems are
  2. Visit each piece of equipment and check whether you have any controls installed
  3. Write down each controller version and address, if available
  4. Find the supervisory device for each controller(s) and upload the database
  5. Look at the code in the supervisory controller(s) and make sure that there are not any intergration(s) to other systems
  6. If integration(s) exist, detail out the connection type and settings for the integration(s)

If you follow those 6 steps you will be able to provide an adequate list to the whoever is designing your new system.

My Recommendation

Do not wait until you need to add a new system to your campus. Index your legacy controls right now. 

But Phil, I've got maintenance and trouble calls, and I just don't have time to do this!

Ok, but when you're doing maintenance on an AHU can you look at its controller?

What about when you hop into the ceiling, can you look at the VAV controller info and write that down?

Look, you can make it easy or hard on yourself, I can't recommend enough how important it is to have an index of what systems are installed.

Would you let your electrician install breakers in your house and not write down what circuit they go to?

How are those systems supported

Next, we come to the topic of supporting these legacy systems. There are three main methods for supporting legacy systems.

These methods are:

  • The Gateway Method
  • The Add-On Method
  • The Rip and Replace Discount Method

Gateway Method

The Gateway Method is one of the most prevalent methods right now. It's a toss-up between the gateway and the rip and replace method as to which one is more popular.

The Gateway Method uses a software gateway that normalizes or "translates", the data from your legacy system into a format that your new system can use.

On the surface, this method has many benefits.

For one, you often do not have to replace controllers. You can also deploy this method quickly. Finally, you can often install this method without having to shut down existing systems.

There is a dark side to this method. While this method does work, you need to be cognizant of the potential downsides this method has.

Here is what I would ask to determine if this method is for you:

  • Are you using a gateway to bring one vendor's legacy systems into another vendor?
  • Is the gateway made by a third-party?
  • Are the protocol(s) that the gateway is using proprietary?

If the answer to any of these questions is yes,  I would be extremely careful. It is my experience that these three questions indicate high-risk scenarios that often lead to installations that are only semi-functional.

Add-On Method

This method is similar to the gateway method, with one major difference. In order to connect the legacy system to the new system, the add-on method uses new software and/or hardware added directly to the legacy system.

In this method, an adapter, either software or hardware, is added to a supervisory device. This supervisory device then acts as a bridge between the legacy and new system.

You will see this method used with systems that use older protocols or communication methods. You also see this method used with legacy systems that have resource limitations (CPU, Storage, Memory).

This method has been largely replaced by the Gateway and Rip and Replace models.

Rip and Replace Discount Method

Ah, the good ole' rip and replace method, but this one's even better because there is a discount added to it :-D.

I've seen this method used a lot lately. Controls companies are beginning to realize that supporting controllers from the 1970's is not a badge of honor rather it's self-induced pain.

Seriously, should Blu-Ray players support VHS? I mean that sounds pretty dumb right?

Well, folks are getting wise to this and they are recommending, for the real dinosaur systems, that owners rip and replace the controls. The rip and replace method is where the controls provider would go and pull out all of the legacy controllers and would replace them with new controllers.

Often times this approach will be met with either a discount on new products or a discount on the proposal. If you don't see this discount just ask, often times it's not mentioned.

The important thing to note with this method is to make sure that you check if you can reuse the power, sensor, and communication wiring. Often times you can reuse wiring and this will significantly lower your overall cost.

My Recommendation

It is my recommendation that you use the rip and replace method if you can afford it. If you cannot afford the rip and replace method then I recommend the strategic use of the gateway model starting first with your core systems (chillers, boilers, major air handlers).

I also recommend that you do not do all of your systems in one project.

Rather, I recommend that you gradually add systems providing a few weeks between each upgrade to make sure the install "sticks". I also recommend that you monitor the communication and compute (CPU, memory) health of your legacy BAS as you perform these tasks.

How is the BAS product life-cycle managed

So how can you evaluate the life-cycle of your BAS product?

I mean really, how can you?

Product road-maps are some of the most protected pieces of information in the BAS space.

How then can you recommend or make choices on a BAS solution without knowing if the product is going to be end-of-life'd over the next 6 months?

These are questions I see folks struggle with every day and here is how I help them answer these questions.

First, let's define what a life-cycle is.

A product life-cycle is a series of stages from the products initial development to it's end-of-life stage that determines where a product is. As a product is end-of-life'd a new product is brought out to the market.

That last sentence is very important because it really helps you know what solutions are likely to be supported.

For example, Tridium just released N4 to the market, should folks be buying Tridium AX?

If you follow the product life-cycle you could reasonably infer that an end-of-life notice for AX will be coming in the next year or two.

In the BAS world, the lifecycle for a product seems to be around 10 years. However, I believe with the new entries that BAS solutions are going to have increasingly shorter life-cycles.

I want to note, that while I have used the new release method to accurately determine product end-of-life timing, this method does not apply to new offerings that build upon the existing solution.

For example, if a product provider releases a product that adds analytic or visualization capabilities to its existing solution, this does not indicate an impending end-of-life scenario.

My Recommendation

My recommendation is that you understand when the product was released to market and when it was last updated. These two metrics are indicators of where a product is in its life-cycle.

You should be cautious if a new offering was released and/or an older offering has not been upgraded in a long time. These actions may indicate that the current offering is going to be end-of-life'd in the near future.


#10 Supported Protocols

So what are protocols? How can they help you integrate 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

I recommend that you use the following specification language below to replace the "to be integrated by others" specification 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?


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 lay out 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 for common everyday specifications? Of course not!

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


There's a ton to building automation systems.

And every day there is something new being released to the market. For many, this can be overwhelming. The good news is that it doesn't have to be.

If you understand the fundamentals of building automation systems then you will be prepared no matter what the market throws at you.

The question then becomes how do you get knowledge?

Don't spend years trying to learn from trial and error. Shortcut that entire process and purchase my Building Automation Training Program. This program will give you a solid overview of the building automation system industry and much more!

Check out the program by clicking right here. I look forward to you becoming one of my over 2,100+ customers.

Phil Zito

Written by Phil Zito

Want to be a guest on the Podcast?