If your facility currently has a legacy control system that needs upgrading but you don’t have the capital budget for a full retrofit, you are likely considering some form of building automation system integration. By integration, we are referring to an approach that would leverage some portion of your existing system while likely changing out some of the higher-level components such as the front-end software and/or parent-level controllers. Integration is a logical choice in this situation but before moving forward with this approach, there are some important elements that you should fully understand.

BAS Integration Basics

First, you’ll want to have some basic knowledge of building automation protocols and the capabilities of these systems to share and normalize data from other manufacturers. Many older (and some new) systems utilize manufacturers’ proprietary protocols. Before BACnet became the ubiquitous open protocol of the controls industry, this was common practice.

This poses the problem of communication between disparate systems. Most system integrators will take one of two approaches in this scenario: 1. a complete retrofit (get rid of the old controllers altogether) or 2. use a translator of some kind to change the proprietary messages from your legacy controllers to BACnet or their own proprietary protocol which will allow you to monitor those points from the new front-end software.

Existing Legacy BAS Architecture (click to enlarge)

Possible Initial Integration Architecture (click to enlarge)

What level of control will you have?

One of the most important questions to ask your service partner is what level of control you’ll have of your legacy controllers after the integration is complete. In many cases, your existing controllers will continue to run with the same programming that they have always had and can only be monitored through the front-end software. The reason for this is that they may require a proprietary tool that your new service partner does not have access to. With that said, going back to your previous service partner to make these programming changes could be costly if you can get their help at all.

Another approach you might come across is having all of the programming for the legacy devices stored in the front-end software. While this may give you better control, you have to consider the risk of having all of that information stored in what could be a single point of failure. If your front-end computer or translator fails, all of the legacy devices would stop working instantaneously. The preferred method would be to have the programming distributed amongst the parent-level controllers.

What will the user experience be like?

Just because you have all of your controllers on a single front-end does not mean it will be a seamless experience when driving your new software. Often times the points on the legacy controllers will reside in a different section of the software from the points on your new controllers. This can be cumbersome to manage and keep track of. You’ll want to make sure your service partner can provide you with a smooth user experience regardless of the controllers being utilized.

What is your pathway forward?

Your integration is complete! You have full control of both your new and legacy devices on a single front-end, but one of your legacy sub-controllers or sensors fails. What happens next?

This is a question you’ll certainly want to have answered before the situation arises. The likelihood of your new service partner having a sub-controller that can sit on the same communication trunk as the failed legacy device is slim to none. The approach will likely be to run a new communication wire to their replacement sub-controller or rip out the trunk altogether and replace it with a new BACnet trunk with all new devices. But isn’t that what you were trying to avoid by choosing the integration approach in the first place?

BAS Integration Architecture with Replacement Sub-Controllers (click to enlarge)

What is best for your building long-term?

Along the same lines as knowing your pathway forward, you’ll want to know if certain devices are not worth saving before agreeing to an integration.

A prime example would be a BAS that utilizes RS-485 wire from the front-end computer to the parent-level controllers. Modern building automation systems utilize CAT 5/6 cable in this part of the system architecture because of the amount of traffic passing through. RS-485 simply does not provide enough bandwidth to efficiently pass the number of messages required through at a reasonable speed. While you may be able to communicate with these parent-level controllers through integration, you’ll have the same issues with network speed that you had previously.

Having said that, you can likely find a system integrator that can utilize your existing sub-controllers using the existing RS-485 communication. The devices produce less traffic and therefore are likely worth being carried over.

Band-aid or Bona Fide?

While integrating your legacy building automation system can be extremely effective when done right, you can see that there are a number of potential pitfalls with this method. When discussing a potential building automation system integration project with service partners, make sure to address the issues above and get some references with whom they have completed similar projects.