Learn How to Evaluate Controls Architectures in 3 Easy Steps

How do you know if your BAS is designed efficiently?

Does your BAS have the correct capacity to grow with you?

These are questions that every building owner and controls contractor face at some point in their career. Up until this point there really hasn't been an answer to these questions.

In this article though, these questions will be answered!

So if you're ready to learn how to select a system that is designed to operate efficiently and grow with you then read on!

If so join me in the six article of my 10-part series on how to evaluate your building automation systems.

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.

The Criteria

#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 to 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 comes 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 simply 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, 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 ;-D.

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 the Evaluating a BAS series.

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