Tweet

June 2018
Column
AutomatedBuildings.com

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


Back To BASics

– DDC Controllers (Part 2)


Architecture & Interoperability

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]

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:

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. 

[an error occurred while processing this directive]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.

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