June 2017 |
[an error occurred while processing this directive] |
Upgrading Old BASs
Is a Gateway in Your Future? Is it time for a total system replacement or a phased approach? |
Ira Goldschmidt, P.E., LEEDŽAP 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!
[an error occurred while processing this directive]
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]