Last month, 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 “interoperability?”

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:

• Zone controllers (e.g., for VAV boxes) that do not have time clocks must rely on a higher-level controller (e.g., for the associated AHU) to write to the controllers’ occupied/unoccupied objects based on the higher-level controller’s time clock and schedule. This “Write service” is not needed for zone controllers that have time clocks.

• Trend data can be gathered by the operator interface by reading (another communications service) the relevant object information at the specified interval. BACnet also allows for the use of COV (change of value) reporting in which the controller with the trended data pushes object values up to the operator interface whenever the data changes by a specified amount (this is yet another type of communications service).

• AHU controllers (if they are B-AAC or BC listed) are required to be able to report alarms up to the operator interface (yet another communications service). However, BACnet does not require that this service be used in lieu of the operator interface regularly reading all object data needed for alarming (i.e., the alarm logic resides in the operator interface and not the AHU controller).

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 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) continue to be an (unfortunate?) rarity.