BTL Mark: Resolve interoperability issues & increase buyer confidence
Back To BASics
– DDC Controllers (Part 2)
Architecture & Interoperability
Ira Goldschmidt, P.E., LEEDŽAP
June Issue - BAS Column
I presented a DDC Controller categorization scheme to show how their
capabilities can vary greatly between manufacturers. The
unfortunate reality revealed is that no reasonable categorization
approach can ever accurately reflect all variations between
manufacturers’ controller capabilities. The conclusion was that a
BAS spec’s controller requirements will always contain some (or a lot
of) inaccuracies for the chosen manufacturer. This also means
that enforcement of the spec during construction may be a bit
challenging. Why do these variations exist and what does this say
about the goal of BACnet to provide “Open Systems” and
BAS Architecture – DDC controllers, are designed to fit into a manufacturer’s BAS architecture. “Architecture” normally refers to how the various controllers are physically connected together. For example, a VAV AHU controller might be connected via BACnet MS/TP wiring to the AHU’s associated VAV box controllers, and then in turn connected via BACnet/IP to the rest of the BAS, etc. However, most manufacturers have a fairly flexible physical architecture such that these choices are not normally a challenge for apples-to-apples bidding.
Instead, it is the “Application Architecture” that is the real issue. This architectural view deals with, in the case of a BACnet BAS, such things as where time-based logic is executed, what services the operator interface uses to collect trend data and capture alarms, and what services the higher level controllers use to interact with their associated lower-level controllers. A few examples will make these “application architecture” issues more meaningful:
These and other types of choices are
made by a manufacturer to create the unique “application architecture”
for their BAS. In other words, the specific capabilities of a DDC
controller are not chosen in a vacuum but are instead made so that the
BAS works as a seamless system without the need for the installer to
deal with “application architecture” choices. That’s why a
single-manufacturer BAS will almost always be easier to specify/upgrade
than one with DDC controllers from multiple manufacturers.
Open Systems & Interoperability – Consider an addition to an existing BAS that uses controllers that all have time clocks. If a BACnet B-ASC listed controller (i.e., without a time clock) is chosen for the addition, then the contractor will be confronted with additional programming efforts to ensure that the BAS writes to the controllers’ occupied/unoccupied modes according to schedule. Does this mean that the use of BACnet does not result in a truly “open system”? No, BACnet provides choices to its “open system” capabilities that are not constrained by a single mandated “application architecture.” This was an explicit goal of BACnet that continues to confound our industry to this day.
Conclusion - BACnet’s “Open System” flexibility means that the design of a multi-manufacturer BAS needs to include the specific BACnet services to be used for scheduling, alarming, trending, etc. based on what the actual controllers involved need to use in order to work as a “system.” A specification with these requirements is a challenge to develop (due to engineering fee and BACnet expertise limitations), and so BASs that use interoperating controllers from multiple manufacturers (except within the Tridium platform, but that’s a unique case) continues to be an (unfortunate?) rarity.
[Click Banner To Learn More]
[Home Page] [The Automator] [About] [Subscribe ] [Contact Us]