Tweet

June 2017
Column
AutomatedBuildings.com

[an error occurred while processing this directive]
(Click Message to Learn More)


Upgrading Old BASs

Is a Gateway in Your Future?

Is it time for a total system replacement or a phased approach?

Ira Goldschmidt

Ira Goldschmidt, P.E., LEEDŽAP
Engineering Consultant,
Goldschmidt Engineering Solutions
ira.goldschmidt@comcast.net

Contributing Editor

As published
Engineered Systems 
June Issue - BAS Column

Articles
Interviews
Releases
New Products
Reviews
[an error occurred while processing this directive]
Editorial
Events
Sponsors
Site Search
Newsletters
[an error occurred while processing this directive]
Archives
Past Issues
Home
Editors
eDucation
[an error occurred while processing this directive]
Training
Links
Software
Subscribe
[an error occurred while processing this directive]

In the last two columns, I explored BAS integration to factory mounted controls and for the controls additions to existing BASs. This month I will cover the last major reason for considering integration: upgrading old BASs.

Why? Old BASs don’t fail in totality; instead partial system failures typically become more frequent and/or more challenging to resolve. Also, many components such as sensors, wiring/conduit…, and even some controllers may still be usable. So, while a total and all-at-once system replacement may sound like a good idea, financial considerations may dictate otherwise. Therefore, it makes sense to consider a phased approach to the upgrade and/or an upgrade which retains some of the existing controllers. So upgrading an old BAS often involves integration to a new BAS.

What’s Involved?

If the BAS uses BACnet communications, then the upgrade should be simpler, though most older systems probably use proprietary communications. If so, using the same manufacturer ideally should lead to a reasonably straightforward approach, assuming that their newest-generation BAS is designed to be backward compatible. However, the client may want the upgrade bid on by multiple manufacturers which complicate the question of “backward compatibility.”

Therefore there’s a good chance that a gateway will be needed. “Gateways” (often called “drivers”) provide communications protocol conversion. They are needed to integrate to an older proprietary BAS though they also are used to connect a LonTalk system to one that uses BACnet.

Gateways get a bad rap mostly due to the fact that protocol conversion can never be perfect. The reason is that a communications protocol is designed to support the data that is deemed to be important to BAS operations. This involves many subjective choices with results that will vary depending on the designer. Therefore, the big difference between protocols can be about what data is or is not supported.

Why is this a challenge?
The first step is to determine whether the old system has an available integration path. Unfortunately, a gateway (typically to BACnet) may not be available for older proprietary systems. In this case, it would be best to
all at once entirely replace the old BAS . A second choice would be to replace it in phases with the understanding that there will be two separate BAS’s (with two separate operator interfaces) in use during the transition.

[an error occurred while processing this directive]A gateway to an old, proprietary system is often only available via the same manufacturer (i.e., using the “backward compatibility” of their latest generation BAS). If so, the project delivery choices are expanded to include sole-sourcing it to the same manufacturer. The next question is whether the gateway fully supports all important BAS functions or not. The best way to determine this is to view an actual operating system that uses the same old and newer BAS’s. If the gateway clearly doesn’t do very much (i.e., the old system’s operator interface needs to be retained and used on a regular basis), then the fully replaced route is probably the best choice.

If the BAS uses BACnet communications beware that most early BACnet systems unintentionally implemented the protocol in various non-standard ways. This could lead to unexpected integration issues with any current BACnet-based system. Again, seeing an example of this integration combination should help to define the risks and/or shortcomings.

Lastly, the same challenges with specifying the integration as discussed in the two previous columns apply here. Namely, the objects to be shared and the services to be used need to be specified.  This is necessary to assure that the old and new BASs are made to work together as a unified system. If the new BAS will be bid on by multiple manufacturers, it is not reasonable to expect a designer to research the objects and services variations between each new BAS choice. Therefore a “basis of design” approach may be beneficial.

What’s the Solution(s)?
Clearly, the best approach to upgrading an old BAS is via a complete, all-at-once replacement. However financial considerations may dictate a partial or phased approach. Unfortunately, there is no simple integration solution to these latter approaches and, in fact, each situation needs to be uniquely researched. Either way, there’s probably a gateway in your future!

footer

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]

Events

Want Ads

Our Sponsors

Resources