5 Things to Know Before Buying Building Management System Training

BEMS, BMS, BAS, EMCS, and this list goes on and on. Welcome to the acronym-filled wasteland know as building automation. You may be wondering, "What is a Building Automation System?"

If you are looking for more details, kindly visit our website.

Even among "building automation" professionals, there's a lack of consensus around what building automation is. And this is exactly why I wrote this guide.

The purpose of this guide is to help you understand what building automation is.

No matter what your role is when you finish this guide you will understand what a building automation system is and how it works.

And that is where most "building automation 101" guides end... But that is not where we end!

By the time you finish this guide you will understand:

• The real-world outcomes you can expect to achieve from a building automation system
• How the modern BAS systems came to be and why you should care
• A process for being able to look at BAS designs and intuitively understand them
• What the different pieces of a BAS system are used for
• The 4 main BAS control modes
• The ins and outs of BAS software
• The stupidity of "cybersecurity fear mongering" and how to secure a BAS
• The secret to upgrading a BAS, without failing repeatedly
• Why trends, alarms, and reports are the most under-utilized feature of a BAS
• How to work with IT groups and why IT isn't your enemy
• How to move into the world of BAS
• How to develop your BAS teams and hire great talent

By now, you may be feeling overwhelmed. You may look at that list and say holy moly, that's a ton of information.

And you know what, you'd be right. Building automation is a complex topic and this isn't some 1,000-word guide designed to grab clicks and teach you nothing.

So here's the deal:

I'm really good at simplifying complex topics, I like to think it's my superpower.

If you stick with me through this whole guide you will leave with a massively increased knowledge of building automation.

Sound good? Let's do this!

So what is a Building Automation System?

Great question right?

After all, that is the point of this guide.

When folks ask me what a building automation system is, I often ask them, what do you want it to be.

I know, that seems like a very evasive way to answer a question but think about it.

How many specifications have you read that called for a BEMS, BAS, BMS, EMS, EBMS, and my favorite the ABMAS (by the way that stands for Advanced Building Management Automation System)?

So what is a BAS?

Well in the simplest terms a building automation system is a system that automates many of the tasks that are required to run HVAC. Yes, I know, why is it called a building automation system? Why don't they just call it an HVAC control system?

Well, you want the truth?

You can sell a heck of a lot more Building Automation Systems then "HVAC control systems".

In an ideal world, a real building automation system would control, HVAC, lights, access control, energy management, and much more.

But we live in the world of segmented contracting models where each manufacturer is contractually isolated from one another and you're lucky if you can get lighting and BAS to talk to one another.

Ok, ok, at this point some of you are getting antsy and want me to tell you more than that a BAS controls HVAC.

So here you go.

A building automation system utilizes a control system to automate the control of various building systems (mainly HVAC). The BAS provides a user interface that allows the end user to adjust the control settings, view the system status, and detect any potential issues related to building system performance.

By the way, we will dive into control systems, user interfaces, and a lot more as we move through this guide.

A building automation system consists of four "layers".

These layers are:

• Server/Application Layer
• Supervisory Layer
• Field Controller Layer
• Input/Output Layer

Each layer of the building automation system serves a purpose and each layer builds upon the layer below it to provide more functionality and automation to the end user.

Outcomes that come from a BAS

(marketing fluff land)

The reality is most BAS are the same.  I can hear it now "Phil, that's not true, my BAS controller has whizbang, Wi-Fi, analytics, SQL features....".

Ok, maybe you do have that.

Give me $500,000 and a development team and I can replicate pretty much any feature you have in your BAS. That is not what makes or breaks a BAS manufacturer.

What really matters is the people and the processes. How you train and develop your people and how you execute your projects will allow you to outperform almost any technology (that is unless you're still installing modems and Windows 95).

Being that most BAS are the same, we can, or at least I can agree that the outcomes we will see from a BAS are largely the same.

Based on my experience working with tons of different BAS manufacturers across hundreds of projects I've discovered that the outcomes break down into four major areas.

These areas are:

• Life safety
• Uptime
• Energy savings
• Staff efficiency

So what do each of these outcomes mean?

Life Safety

Life safety is the ultimate purpose of any building system. At the end of the day if a system negatively impacts life safety then that system needs to be overhauled and fixed. Life safety quite simply is making sure that the health and well-being of building occupants are protected.

Uptime

Uptime is the amount of time that your BAS or the systems controlled by the BAS are up. When a system is down it's called downtime.

There are two types of downtime:

• Planned downtime
• Unplanned downtime

Planned downtime is ok, it's not ideal but it is necessary to perform maintenance. Unplanned downtime is BAD, this is when things are down because of failures or unplanned events.

Energy Savings

Energy savings, depending on where your building is this may or may not be a very important factor. The fact is energy savings, as an outcome ebbs and flows.

The outcome here is that the BAS will allow you to visualize and manage your building systems in such a way that you can create energy savings.

Staff efficiency

Finally, you have staff efficiency.

This is the ability of the staff to perform their day-to-day tasks in such a way that they are efficient and productive. Training has a huge factor in the success of staff efficiency. I address staff training in my article How to create the ultimate project training plan.

Control System vs a BAS

So you've heard me mention automated building controls and the term control system and you may be wondering, "What is a control system and how is it different than a BAS?"

As I described above, a building automation system automates the functionality of a control system and provides a visualization component (think user interface and reporting).

These features allow building operators to know what is going on with their systems.

A control system is a subset of the automation system and is capable of operating independently of the building automation system.

I've actually seen a control system in a complex central plant use a time clock for scheduling and function completely independent of the building automation system.

Control systems exist to "control" the input/output and the field controller layer.

Depending on the type of control system you have a couple of different device types.

However, there are some common "pieces" that you can expect to find:

Every control system, and ultimately almost every technology-centric system, follows a pattern of Input => Process => Output. Control systems are no different.

In a control system, an input device provides a status or feedback signal to a "controller".

Depending on the control system type this could be a direct digital controller (these are the modern-day BAS field controllers) or it could even be a simple pneumatic accumulator.

From here the "controller" will drive an output to perform a task.

It could be something as simple as turning a fan on when a wall switch is flipped. Or it could be as complex as controlling a wall of individually regulated fans (fan wall) based on the average of several different pressure sensors. Ultimately it doesn't matter, it all follows the pattern of:

Input => Process => Output

Pay attention because if you grasp what I say next you will be massively farther ahead in your knowledge of BAS than your peers.

It doesn't matter what type of control system you have.

You will be able to make sense of the system as long as you understand what type of inputs there are, what process they feed into (most likely a controller of sorts), and what output they connect to.

The era's of control systems and what they mean to you

Ok, so what are the different flavors of control systems. So far I've named two of them, and in this section, I'm going to unpack the rest of them.

The control systems you will commonly encounter are:

• Pneumatics
• Analog
• Electromechanical
• Digital
• DDC
• The Future of Controls

Pneumatics

Pneumatics were one of the first original control systems. Pneumatics operate by compressing air which is then dried (to remove moisture) and sent down piping called main lines.

Along these main lines, there are devices. These devices will consume airflow from the main line and regulate the pressurized air leaving them through a branch.

At the most basic level, the pressurized air from the main line will move through a sensing device like a thermostat. The thermostat will allow a certain amount of pressure out via its branch lines.

The branch line will act as a control signal to a device, like an actuator, and will regulate the amount of main line air that is entering the actuator. This is how the actuator is controlled.

Analog

Analog systems are quite simple to describe you've probably used one today and not even been aware of it.

Have you ever changed the heat level on your toaster using a turn-knob? If so congratulations you've used an analog control system!

Analog control systems used to be quite prevalent but are slowly disappearing in favor of digital and electromechanical controls. You still see them in some situations mainly on ceiling mounted unit heaters and radiant heater coils that line the windows of buildings.

Analog systems work by injecting resistance upon a circuit.

This resistance then causes the control device (valve, relay, etc) to react. This is a really simple description but the reality is that these systems are really simple. Often analog systems are combined with electromechanical systems.

Electromechanical

Electromechanical control systems utilize mechanical changes to control their devices.

An example of this is The ceiling mounted unit heater described earlier. This unit heater will have a temperature element that reacts to changes in temperature.

Once the temperature changes enough the element will expand or contract to close or open a circuit. This will, in turn, cause the unit heater to turn on or off.

Digital

Now, this is something I know you've worked with!

You are using digital systems every day.

Digital systems are things like your microwave, smart thermostat, car radio. Essentially you have a microprocessor board that receives the signal from a button push or from some other action and then commands a corresponding output.

Digital systems, when networked, form Direct Digital Control (DDC) systems.

DDC

DDC is also known as direct digital control is the primary control system utilized today. When you talk to folks who have worked in the BAS industry for a long time they tend to define time periods by pre-DDC and post-DDC.

There are two big differences that DDC brought to the market:

The first capability that was introduced was direct digital control, I know obvious right?

Up until this point, several systems relied on analog inputs. These inputs were prone to calibration errors that could result in readings that were several degrees off. Imaging cooling a space down to 72 degrees when in actuality the space temperature was 66 degrees.

I've been to tons of buildings that are cold and humid due to subcooling, often times the problem is inaccurate sensor readings from poorly calibrated pneumatic systems.

While not perfect DDC did reduce the variables related to proper sensor readings. With DDC a facility operator simply needs to maintain the 'offset' on his or her temperature sensor. This is a massive shift from having to maintain main trunk pressure, a temperature sensor, and branch pressure.

The second capability that was introduced by DDC was microprocessor control.

It's hard to imagine but less than 30 years ago control systems utilized dip switch settings and slot cards to create programs, and those were the premium control systems! The average user had to rely on a set of solenoids, relays, and timers to 'drive' their control system.

With the advent of DDC systems, software programs could be written that would take the electro-mechanical relay funfest and convert it to software. This was huge!

Controls technicians and facility operators could now make changes to control sequences by simply changing the code. They no longer had to rewire circuits and install/remove relays.

The software-centric nature of DDC had another unforeseen benefit.

Since all the programs were 'software' data could be quickly exchanged between controllers. These air handler controllers could share their valve position to chilled water plants allowing the chillers to reset their chilled water setpoint.

In many ways, this was the first Internet of Things.

From a technical perspective, DDC control systems have a CPU, known as a microprocessor and a series of digital inputs and outputs. They are typically powered by 24 volts Alternating Current (AC) but they can also be powered by direct current voltage.

DDC controllers will typically have some sort of communications trunk to facilitate communications between the field controllers and a centralized supervisory device. The main communication standard used by DDC controllers was and is RS-485 (which is a twisted pair 3 or 4 wire cable).

This 'wired network' is daisy chained between controllers meaning it connects from one controller to another in a row.

However, there are newer communication designs that are being used for DDC controllers. The two most common communication designs are wireless, and hard-wired IP (which has 3 different design patterns itself; ring, bus, and daisy chain).

Diving even deeper, there are two main forms of wireless designs. These are 802.11 wireless (also known as Wi-Fi) and wireless mesh.

Wired IP networks can also use another technology called Power over Ethernet, also known as 802.3at provides around 25 to 30 watts of power over a traditional Cat 5E Ethernet cable. Cisco has a version of PoE called UPoE which provides up to 60 watts of power.

While these communication designs are new to DDC they are not new to the IT industry and the jury is still out as to which approach will win. Side note, I personally prefer wireless as it provides more flexibility and is a lower total cost, when you factor install, wiring, and switchgear.

The Future of Controls....

What does the future hold, that is the multi-billion dollar question?

I often tell the folks I work with that I believe the future of controls is a world where 80% of projects are smart equipment and the rest are IoT devices like Arduino or Raspberry Pi boards with a common programming language.

Right now the profit margins are still high enough to justify creating multiple brands of controls but how long will that be the case?

We are getting to the point where there really isn't much more you can pack into a controller. Think about it, once the controller is wireless, which is my preferred approach, you will have freed yourself from all physical constraints except for power cabling.

I imagine inputs (thermostats, flow sensors, pressure sensors) and outputs (actuators, relays, etc) that have gotten low enough in cost and high enough in reliability to be wireless as well. Power will be locally sourced from the equipment or through batteries.

The end devices and field controllers will be smart enough to identify where they are and what system they should connect to. The BAS professionals job will switch from being focused on the physical installation of systems to being focused on IT systems like databases, analytics, and system integration.

Even that will eventually be replaced by self-learning systems that can sense the health of an entire building and adjust settings based on millions of variables.

Google is a great example of this technology in a very different field. Google processes 3 Trillion searches a year. 15% of these searches have never been seen before. Google has written programs powered by artificial intelligence that analyze millions of variables and determine the best search results to provide.

Is it unreasonable to think that we could take all of the knowledge we have around building systems into a computer program and that computer could analyze the performance of thousands of buildings to "learn" how to best control your building?

I definitely think that is a possibility. But don't worry, we will still need people to install and service this technology and these next generation "building automation programmers" will need to understand IT, programming, and other skills.

How far away is this future? It could be 50 years it could be 5 years. All it takes is someone like Elon Musk realizing that there is an industry ripe for change, choosing to enter the market.

A deeper look at a building automation architecture (from the top down)

Earlier in this guide, I discussed how there are four layers in a modern building automation system. In this section, we are going to take a much deeper look at each of these layers and how they function within a building automation system.

The Layers

To recap there are four layers in a modern building automation system architecture those layers are:

• Server/Application Layer
• Supervisory Layer
• Field Controller Layer
• Input/Output Layer

Server/Application Layer

The server/ application layer serves to consolidate data from multiple different supervisory devices. It then delivers this data to the end user through the user interface (UI), often known as clients.

The server will also store trend, alarm, and schedule data in a database. This database can be used for reporting. The final thing the server can be used for is, is for serving up the API for the building automation system.

Supervisory Layer

The supervisory layer is where the supervisory devices sit. Supervisory devices are kind of like your home router. They collect all of the traffic from the field controllers and consolidate this traffic.

These devices serve to manage your communication trunks. Communication trunks allow your field controllers to connect to one another and allow your supervisory devices to collect information from the field controllers.

Some supervisory devices can also act as user interfaces for the BAS. Typical features that exist in the supervisory device are:

• User interfaces
• Trending, scheduling, alarming
• Global logic
• Communication Trunk management

Field Controller Layer

Field controllers look at data from inputs (temperature sensors, switches, etc) and then control outputs (actuators, relays, etc). BAS companies will use programming tools (usually developed by the BAS vendor) to program these field controllers.

The controller's programs will look at what the inputs are doing and then they will control the outputs.

Input/Output Layer

The final piece of the puzzle is the input and output layer. This is where the sensors and control devices exist. There isn't a ton to add here except that you are starting to see IP-enabled sensors that use Ethernet or Wi-Fi for their communications.

These kinds of sensors will require a completely different approach and as of the time I wrote this guide, it's yet to be seen how all of this will shake out.

Making sense of the different pieces of controls

Ok, so now you have an understanding of the different layers that make up a building automation system and the difference between a control system and a building automation system.

Now we are going to explore the physical pieces of the BAS.

From a physical perspective, the BAS consists of:

• Servers
• Supervisory Devices
• Field Buses
• Controllers
• Inputs
• Outputs

Servers

Servers are machines that collect and serve up the BAS data. These servers will either take the form of a desktop machine or a rack-mounted server. These servers will run the BAS software and will connect to the network using network interface cards (NIC)

Supervisory Devices

Supervisory devices can be either software or hardware based. Software supervisory devices are often known as soft-supervisors, where the supervisory software exists inside a server instead of a dedicated device, are becoming more common.

Soft-supervisors will utilize communication cards so that they can communicate with field buses.

Physical supervisory devices, where the supervisory device software is installed in a dedicated device, are still the most common devices. These devices will typically have an Ethernet NIC and a field trunk port (to connect field buses).

Field Buses

Field buses are the way building automation field controllers communicate back to supervisory devices. There are two prominent field buses right now. These are BACnet MS/TP and LON FT-10. These field buses connect field controllers back to the supervisory device using a daisy chain architecture.

If you're wondering what a daisy chain architecture looks like, just picture a set of Christmas lights. Each light is connected to the other light in a chain of lights. This is what modern field buses look like.

The supervisory device that connects these field controllers together will send messages across the field bus and will receive messages from the field controllers on the network.

Controllers

Controllers are potentially stand-alone devices that control systems. An example of a system would be an air handler unit or a central plant. These controllers are programmed using programming software.

This programming software is usually specific to each individual vendor and can only be used on their field controllers.

There are two main types of field controllers:

• Free programmable
• Application specific

Free programmable field controllers are able to be freely programmed. I know you're like "thanks, Phil that helps a lot...". Seriously though, back in the day, you couldn't configure a field controller. Nowadays you can log into a field controller and configure it to perform any control sequence you want it to.

On the other end of the spectrum, you have application specific field controllers. These controllers are specific to a single application. You cannot program these controllers you can only adjust preprogrammed settings.

Inputs and Outputs

I'm not going to spend a ton of time explaining what inputs and outputs (I/O) are, as I'm pretty sure you can figure this one out on your own.

Here's the down and dirty about I/O. You BAS controller will take signals from inputs (things like pressure or temperature sensors). Then the program inside the controller will decide to do something based on the value of these inputs.

Once that thing action is determined the BAS controller will command an output (actuator, relay, etc).

Pretty easy right.

Control Modes

At the end of the day building automation controllers exist to control outputs based on inputs. It really is that simple. To achieve that a BAS controller utilizes a variety of control modes.

Control modes are nothing more than a way of controlling outputs. And in the world of BAS there are 4 main control modes. Rather than making this post even longer then it already is I'm simply going to include a link to past articles that describe each of the four control modes  The four control modes are:

• Binary, also known as on/off control
• Floating Control
• Sequenced Control
• Proportional Integral Derivative (PID) control

The trick to making sure your BAS provides excellent control is to make sure that you are matching the correct control mode to the output you are controlling. I cover that in each one of the articles I linked above.

The softer side of BAS software

Ok, I'll admit I'm not quite sure what the softer side of BAS means but it sure sounded good so let's go with it. We've already dug into the physical aspects of BAS now we're going to look at the software side of things.

In the world of BAS software breaks out into three main buckets:

• Databases
• Configuration software
• User Interfaces

Now you may be wondering why I am not addressing server software. The reason is that I've already covered that earlier in this guide. With that being said let's dive in.

Databases

Database software stores information. But they do soo much more than that. Whether you knew it or not databases are the lynchpin of your BAS.

How so you ask? Well, let me tell you the ways!

Databases store your configuration, schema, graphics, and so much more! All the bits and pieces that make your BAS your BAS are often stored in databases.

Databases collect invaluable information and store it for later use. Trends, alarms, schedules, setpoints, and more! They are all stored in databases.

And the really cool thing about this is that if you understand databases and the query languages that support them you can start to dig deep into your BAS to pull out past "trends" of your BAS performance.

I just so happened to write two very in-depth articles about how to do exactly that. You can read them here and here.

Configuration Software

There's a ton of different BAS manufacturers in the market and as a result, there's a ton of different types of BAS configuration software out there. But at the end of the day, the software can be broken down into two buckets. Database configuration software and programming software.

Database configuration software is used mainly to configure servers and supervisory devices.

Warning... Uber geek moment. The majority of BAS are built using a three-tier software architecture (user interface, application, database). This is very similar to the MVC framework used by many modern web applications. Because of this the settings that determine the configuration of the BAS are kept in a database and are called up by the BAS application as required. Now, this has slightly changed with the introduction of HTML/5 user interfaces because those use a web server to render HTML files for the end user.

Ok, with that uber nerdy expedition over with. Let's talk about programming tools.

Programming software exists to allow the configuration of the field controllers. One of the biggest issues faced by BAS companies is that each company has its own programming tool. Because of this, only those with the programming tool can configure the controllers. This leads a lot of customers to feel as if they are stuck with the BAS company who provided the controls.

Now as you can imagine there is a ton to know about programming a BAS. Because of that, I've spent a lot of time creating a vendor agnostic guide that dives deep into the concept of programming a BAS.

User interfaces

When it comes to user interfaces you have two real options. Those UI options are known as thick-client and thin-client. A thick-client is the traditional method that is used for connecting to building automation systems.

This is where you would either install an application or download an application that would run on your computer. The reason this is called a thick-client is that there is actually an application running our your laptop. The problem with thick-client applications was

The problem with thick-client applications was they were usually dependent on some form of software (e.g. Java). When you would upgrade the building automation system, the version of this software dependency would change and this would often break the thick-client (meaning it wouldn't work anymore).

To solve this problem the BAS world has largely shifted to using thin-clients.

Thin-clients, on the other hand, utilize web browsers to access the building automation system. The thought behind using web browsers like Google Chrome or Internet Explorer was that they would break the dependency on software like Java.

While this is true, they've introduced a new issue which is IT troubleshooting. Now instead of the BAS manufacturer having full control over their user interface, they are at the mercy of the web browser's code, which they may or may not understand.

Cybersecurity and building automation, (why people secretly think you're stupid if you say Target was a BAS hack)

Target had nothing to do with the BAS system. And IoT devices like IP cameras and baby-monitors are not even within the same continent as BAS devices.

There you go, I've just dispelled the two most common myths about cybersecurity.

Ah, if it was only that easy.

Here is what you need to know about cybersecurity:

Nothing is 100% secure

That's just the cold hard truth. Anyone who tells you their BAS is secure and unhackable, is full of it. Anything can be hacked, given enough time, money, and skill.

Cybersecurity is the process of identifying the cybersecurity risk that your system has and then implementing controls to mitigate that risk.

But what does that mean?

Well what happens, at least in the IT world, is that a professional assessor will "assess the IT systems" and identify potential vulnerabilities.

A vulnerability is a risk that can be exploited by an attacker.

Then a monetary impact is assigned to the vulnerability based on the likelihood of that vulnerability being exploited.  From there the customer will select a set of controls to mitigate the vulnerabilities.

In the world of IT, the term controls describe steps that are taken to address the vulnerabilities. There are multiple types of controls but that is beyond the scope of this guide.

I tell you all of that so that you understand what the IT folks are talking about when they ask you questions around cybersecurity.

The trick to cybersecurity is being more secure than the other guys.

How can you do this?

Well, it's actually quite easy.

In my IT for BAS Professionals training program, I teach several actions that you can take to secure your BAS. I've included three of these tasks below.

If you do these things you will massively increase the security of your BAS.

These BAS securing tasks are:

• Have a unique username and password for each user
• Enforce password complexity
• Enable a firewall and close unused ports

Have a unique username and password for each user

I know, it's shocking to think that you would actually need to tell someone this. However, I've been to dozens of sites where the entire facility team uses the same username and password.

Not only does this put the BAS at risk from someone getting the "keys to the castle" but it also creates a problem with the users themselves. Because everyone uses the same username and password you have no idea as to who actually made any changes to the building automation system.

That's a double uh oh!

Enforce password complexity

I know how annoying it is to have to change your password all the time. I'm constantly having to change my password at work and gosh is it aggravating.

But the reality is, your username and password are the best defense you can have because they work even if someone has physical access to the  BAS server, well most of the time...

I've linked to an article on creating complex passwords rather than boring you with a detailed explanation on how to create complex passwords.

Enable a firewall and close unused ports

Finally, we have a firewall. A firewall is a piece of software that allows and deny's network traffic from moving across the network. A firewall is like a security guard who decides which people get access to a building.

One of the most common security issues with a BAS is that it has a lot of software ports that are open to the world. But before I describe how to fix that issue, let's discuss what a port is.

The software needs to send certain types of traffic to other software. Ports allow the software to categorize and segment the data they are sending rather than just sending a huge blob of data.

When BAS folks install a BAS they tend to disable the firewall that way they don't have to worry about having the right ports open. This creates a huge hole in the network that attackers can exploit.

To avoid this, I teach that you should understand what ports your BAS needs open and only open up those ports on the Firewall. This is actually easier than it sounds.

You simply reach out to your manufacturer, ask them what ports to have open, and then you close down all the ports except for those ports.

If you do these three things you will massively increase the "secureness" of your BAS.

Upgrading a BAS, how to not screw it up

If you asked me what single task has the greatest likelihood to really mess up your BAS I'd say upgrading.

Hand's down upgrading a BAS can be the most tricky project you'll ever take on.

So how can you go about taking on a BAS upgrade project successfully?

Well, it just so happens I spend a quite a bit of time on upgrading a BAS in my Building Automation Systems A to Z training program. Here's a video from the program that goes through the "upgrade process".

In the video, above I took you through a lot of the things you need to think about when you are upgrading a BAS. I also briefly talked through my process for performing BAS upgrades.

Here is a list of the steps you should take when you are performing a BAS upgrade.

• Step 1: Decide on what day you will complete the project
• Step 2: Verify the job site systems and applications
• Step 3: Ensure you have the access you need
• Step 4: Identify the systems that will be affected
• Step 5: Decide on your upgrade strategy
• Step 6: Determine the people or groups that will be involved
• Step 7: Write out your upgrade plan
• Step 8: Put the systems in hand
• Step 9: Execute your plan
• Step 10: Document your changes
• Step 11: Verify proper operation
• Step 12: Check the opposite season control

As you can imagine each one of the steps has their own nuances. But the good news is that the steps I describe above are fairly intuitive. I shared these steps with you because I wanted you to have both eyes open when you decide to take on an upgrade project.

Trends, alarms, and reports...How to take your building from oh crap, to oh yeah

So, contrary to popular belief you don't need to spend tons of money on an analytics solution. A building automation system is chock full of features that allow you to analyze the current and historic status of your BAS.

But the sad reality is so many building operators are not using their BAS to its full potential. The first step to taking your BAS to the next level of functionality is to level set on what these features are.

What are trends, alarms, and reports?

Ok pay attention, this section is important:

As I mentioned, a BAS has many features, and most of the features are left unused or misused by building operators. You've probably guessed by now that the often unused features of a BAS are Trends, Alarms, and Reports.

Trends

Trends are data points that are collected and stored for later recall. There are two main types of trends:

• Interval Trends
• Change of Value Trends

Interval Trends are trends that are collected at a predictable interval. Pretty simple right? The good news is the majority of trends are interval trends, easy to set up, reliable, but limited to the time slice you setup.

This means that if you are collecting trends at 15-minute intervals. there will be no record of if something rapidly changes between those 15 minutes. This is why I cringe most of the time when I see a specification that says every point shall be trended at "15-minute intervals".

Change of Value Trends record a value when the value of a point changes by a specific value. Hence the term change of value. These trends can be immensely useful when you are troubleshooting a specific issue or you are trying to measure a point that changes by very minute details.

However, you need to be careful when you use change of value trends as they can take up a lot of storage space if you set the change of value threshold to tight or you use too many change of value trends.

I wrote up three articles on how you can use trends to perform basic fault detection for three of the most common BAS issues:

• Simultaneous Heating and Cooling
• Out of Control Outdoor Air Economizer
• Over-cycling chillers

Alarms

Alarms are one of the most mismanaged functions of a BAS. Period! Oh, if I had a dollar for how many times I've visited facilities that had over 10,000 unacknowledged alarms. I remember this one customer I visited. Their central plant, yes the chillers! Where down for almost an hour before someone took notice. The reason why?

They had so many filter status and space temperature alarms coming in that the single chiller alarm got missed in the massive influx of alarms.

So if you are sitting on one of these ticking turd time bombs what can you do? How can you go and take a horribly implemented alarming strategy and turn it around?

Here are two steps you can take right now.

Step one: Do something crazy

I'm going to say something drastic but, here it goes.

Get rid of alarming. Yep, delete all your alarms. Poof gone.

Now, at the same time list out the systems that are absolutely critical. For most buildings (hope you noticed that caveat) your list should look something like this.

Chillers, boilers, air handlers, pumps, and maybe the temperatures in the networking/server rooms.

What it shouldn't look like is alarms on every friggin point. There's no reason to have sensors on filter statuses and common corridor space temperatures. I know that this flies in the face of the alarm everything strategy but as you'll see in a second there are things that are more effective than alarming. Alarming should be for failure conditions not hot or cold calls or clogged filters.

Step two: Create some standards!

I am a fan of standards, if you've been reading my blogs or listening to my podcast for any amount of time then you've heard me hammering this topic over and over. But what does that look like?

Here's an excerpt from my book Building Automation Systems A to Z, that discusses standards.

Standards they make the world go round. Could you imagine if you went to Home Depot and each store called lights something different? Maybe one store feels like lights should be called glimmers, and another store wants to call them shiners. Imagine your confusion as you tried to communicate what you wanted to buy. BAS standards are the same way. A BAS standard, done right, can tell folks exactly how you want your BAS to work! - Pg 194-195 Building Automation Systems A to Z, 1st Ed.

When it comes to standards there are several different things you want to address. One of those "things", as you might guess, is alarms. But how? How does one create a standard around alarming?

Once again we turn to my book, Building Automation Systems A to Z, to find the answer.

So basically, you define the point list by the system, and then you apply the alarm thresholds based on if the system is critical.

But.... (side note, I sure use that lead in a lot don't I? I almost feel like a Sham-wow salesman, but wait, there's more!)

How do you determine if a system is critical?

Simple my friends, and for that, we once again turn to my book and take a look at my system criticality matrix. You'll find this on page 213.

Basically, you are going to rank the overall impact on three areas with a rank of 5 to 1. After you've ranked the three areas you sum up your ranking matrix and then use that to prioritize systems. You can see what this looks like in the image below.

As you can see the matrix has been filled in for a central plant with a total ranking of 15. This would then be prioritized and any system that falls above a threshold determined by you would be a candidate for alarming.

Going and getting your alarming under control can be a huge undertaking. I've written a quick post to help you with this. You can read it right here.

Reports

Remember earlier when I said there were ways other than alarming to determine if things were out of whack. Well, my friends, reporting is that way.

• Want to know when any space has been greater or less than setpoint by more than four degrees for more than two hours? Reports can do that.
• Want to see all of the filters that have had a filter plugged status for more than 3 days? Reports can do that.
• Want to know all of the fans that have exceeded a run hour threshold by 10%? Reports can do that as well.

Reports should be your main go-to strategy when you are trying to avoid nuisance alarms. As a matter of fact, reports can be a great strategy for prioritizing maintenance efforts. Yet in so many of the sites, I've visited reports are seldom if ever used. Why is that?

In my experience, it's because we have trained ourselves and our teams to believe that the only way to catch a problem is with alarms. Add to this that very few sites prioritize their systems as I described earlier and you have a recipe for everything being critical. And we all know we have to use alarms for critical things...

That is why before starting on your trend/alarm/report journey you absolutely must identify what equipment is critical and what equipment is not.

Working with IT and the Zen of networked buildings

Back in I first started in building automation IT was something that was on the fringes. Fast forward 10 years and IT is involved in almost every aspect of building automation. From servers to IP-enabled sensors, if you are hoping to avoid IT you're out luck.

When it comes to IT there are two areas that seem to challenge BAS folks. The first area is interacting with IT and the second area is all of the "technical" mumbo jumbo.

Fortunately for you, I've got some great stuff on both.

How to interact with IT

When I was launching my online IT training program, I rolled out a webinar to help folks solve the number one problem most BAS folks talk about. Dealing with IT. Even though the webinar has long since passed, I recorded the three strategies I taught to the webinar attendees. Here's a summary of the recordings:

Here's a summary of the recordings:

• In the first recording, I teach you how an IT group is structured, this is critical to making sure you are talking to the right person
• In the second recording, I teach you my secret question that will help you get what you need from IT
• In the third recording, I discuss exactly what you need to learn so you're not spending years learning things you don't need to know

As I mentioned I recorded these videos and you can check them out below.

Video 1: How IT groups are organized

Video 2: The Secret Question

Video 3: What you need to learn about IT

Resources for you to learn IT

I've been on a bit of a mission lately to help folks learn IT. The world we exist in right now is only becoming more and more dependent on technology. That world is bleeding into the BAS world more and more every day. That's why a large amount of the content I've produced has focused on IT. But sometimes it can be hard to sort through all of the great content I've created. That's why I've taken the time to segment out all of the content in some easy to access links below:

Networking

• Network Fundamentals
• The basics of subnetting
• An overview of the TCP/IP Stack
• The OSI Model
• The basics of IP Addressing

Servers

Servers run your BAS and ultimately run the Internet. You're actually using a server right now to access my WordPress site that is hosted on a cloud-based server.

• The basics of Web Servers
• Podcast: The fundamentals of servers

Databases

Databases are one of the core technologies that power building automation systems. Yet so few people seem to understand how they work.

• SQL Overview
• SQL Commands for your BAS

CyberSecurity

There are so many misunderstandings when it comes to cybersecurity. And it doesn't help that companies are putting out "expert" opinions that couldn't be anything further from the truth.

• The truth about recent hacks
• How a hack happens

API's and Integration-

Systems integration is near and dear to my heart. It's one of the three things that helped catapult my career. It also seems to be one of the topics that confuses BAS professionals the most.

• The non-techie guide to API's
• My complete guide to systems integration

Now I realize that this was and is a ton of information and a lot of it requires you to have the initiative and discipline to create a learning plan and perform a ton of self-study. If you'd like to shortcut that whole process and learn exactly what you need to know about IT in days vs. years then be sure to check out my self-paced online IT training program. It will literally save you years of studying and thousands in travel costs.

How to enter the world of BAS and develop the people you have

So you're excited. You've learned more from this single guide then you've learned at any training you've ever attended (that is unless you've attended my training programs). And now you want to either enter the world of BAS or get your team up to speed.

But how?

Well, just so happens I've put together a ton of stuff on this exact topic.

Becoming a BAS professional

In order to enter into the field of BAS you need to have one of the three skills (HVAC, electrical, or IT). Yes, that even applies to sales folks and project managers. But what exactly do you need to know?  And what can you expect when you go to your first interview? Well, my friends, you are in luck because I answered those exact questions in past articles and episodes of my podcast. Check them out below:

• You're new to BAS, here's what to do
• 7 things you must know when you start your career in BAS
• You can have a career in BAS, and here's how
• 7 tips to pass your BAS interview
• You've got a job in BAS now what?

Developing your team and hiring talent

Man, if there is one thing I know, it's that good BAS folks are hard to come by. There's just not a lot of good programs out there to develop talent. That's the whole reason why I started this blog and created my training programs.

So how can you get started on developing your team?

This is a question I get on an almost daily basis.

Developing a building automation team consists of 3-steps.

Step 1: Assess

You need to know where you're at to know where you're going. That's why so many large scale organizations have yearly assessments. Unfortunately, these assessments often test for qualitative things (like how a manager feels an employee is doing).

That's why we developed an online quantitative assessment that we use with our corporate customers to identify their skill gaps. You can learn more about our assessment by clicking here.

Based on these assessment results you can tell where the skillset of your team is compared to the skills of our over 7,000+ students.

Step 2: Train

Once you have identified these gaps you need to train your team. This is where our industry really falls flat. Outside of our online training programs you have three options.

1. Manufacturer training which only trains on tools.
2. Trade schools which take to long and often train on obsolete equipment.
3. Doing your time in the field, which takes time you don't have.

We provide proven, turnkey, training programs that deliver results for our customers.

P.S. We offer corporate deals - Talk to us to learn more.

Step 3: Measure

Finally, you must have a way to measure that your employees are actually improving so that you can ensure your training program is working.

We solve this problem by conducting an exit exam after every course and a final exam at the end of our course tracks. We are looking into adding proctored exams that require hands-on setup of systems as well.

Conclusion

So there you have it, you just read the most complete guide to building automation systems you will find anywhere on the Internet. I'm sure you have questions after reading this so drop down in the comments section and ask away, I'd love to hear from you.

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?

You will get efficient and thoughtful service from Dolang.

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.

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

Open Procurement Ranking

Ranking Score

Ranking Description

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

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

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

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

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.

Mobile Support, Responsive, HTML/5 Ranking

Ranking Score

Ranking Description

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.

Graphics Configuration Software

Ranking Score

Ranking Description

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.

Graphics Library

Ranking Score

Ranking Description

#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 , 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 transmission and one more form of transmission. The reason behind this is if your 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.

Alarm Prioritization

Ranking Score

Ranking Description

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.

Alarm Sequencing

Ranking Score

Ranking Description

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.

Alarm Transmission

Ranking Score

Ranking Description

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.

Trend Data Access

Ranking Score

Ranking Description

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.

Trend Data Visualization

Ranking Score

Ranking Description

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

Configure and Program Controllers

Ranking Score

Ranking Description

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.

Adjust and Customize Settings

Ranking Score

Ranking Description

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.

Create and Backup Databases

Ranking Score

Ranking Description

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

System Redundancy

Ranking Score

Ranking Description

#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!

AHHHH!

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.

General Support Capabilities

Ranking Score

Ranking Description

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.

Regional Support

Ranking Score

Ranking Description

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.

Training Availability

Ranking Score

Ranking Description

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

Tailored Training Levels

Ranking Score

Ranking Description

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.

Training Plan Creation

Ranking Score

Ranking Description

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.

If you are looking for more details, kindly visit Building Management System Training.