Ensure Legacy System Support with these 3 Questions

How can you ensure that your investment into a BAS will be around 5 years from now?

Can you determine if your new BAS will work with your legacy systems?

How do you manage software upgrades and critical system patches?

A building automation system is a life-cycle investment. However, the BAS is often only evaluated based on first cost.

I've been on too many projects where I've been expected to tie a BAS into a system that does not have an integration path. I've also sat with frustrated owners who couldn't determine whether the BAS they were buying today would be around 5 years from now.

With the advent of IoT the issue of legacy support has becoming even more critical.

The pace at which new features and functionalities are being released is increasing and BAS manufacturers are adopting shorter product life-cycles in order to keep up.

In this article, I will discuss how you can address legacy support and future-proofing..

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

This article will be a little bit different in that it will not provide any specification language recommendations.

Rather this article is going to address the topic of legacy systems, by answering some of the most common questions I get e-mailed to me everyday.

Let's do it!

Criteria 9: Legacy Support

Legacy support, what does that term even mean?

To some that means the BAS will support all forms of its older self..

Is that reasonable?

I mean, the current trend is disposable systems that focus on software more than hardware.

But how does that coincide with BAS?

How can we balance the need to adapt to technological advances, while continuing to support a 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?

The Criteria

#9 Legacy Support

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

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

At this point you have a choice to make.

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

Those questions are:

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

Let's dig in!

What systems are supported

Where to begin?

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

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

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

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

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

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

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

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

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

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

My Recommendation

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

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

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

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

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

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

How are those systems supported

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

These methods are:

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

Gateway Method

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

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

On the surface this method has many benefits.

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

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

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

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

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

Add-On Method

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

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

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

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

Rip and Replace Discount Method

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

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

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

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

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

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

My Recommendation

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

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

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

How is the BAS product life-cycle managed

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

I mean really, how can you?

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

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

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

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

A product life-cycle, is a series of stages from the development to the end-of-life stage that determine where a product is. As a product is end-of-life'd a new product is brought out to the market.

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

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

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

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

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

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

My Recommendation

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

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