AutomatedBuildings.com Column - Back To BASics

DDC Controllers not only execute the algorithms that form the basis of DDC (control loops) but they also perform the entirety of the BAS sequences of operation. They are literally the brains behind BAS operation. DDC controllers vary in processing power, point capacity, point types, the sequences that can be executed, the programming language used, use of BACnet/IP and/or MS/TP communications and the BACnet services supported. Other capabilities may include alarming, trending, scheduling and even the ability to serve up graphic screens. These variations depend on the controller’s purpose/cost, BTL listing, and how it fits into a manufacturer’s BAS architecture.

Controller Types – A good BAS specification includes controller categories based on the variations in purpose & capabilities. There is no categorization standard, but it is convenient to use something similar to BACnet’s device types: Application Specific Controller (ASC), Advanced Application Controller (AAC) and Building Controller (BC). However, do not base these categories solely on BACnet’s definitions since the definitions are mainly concerned with the communications services the types support and do not fully address the other controller capabilities mentioned above. The following is an overview of how manufacturer’s controllers might fit into these BACnet-based categories:

ASC’s are meant for a specific application (e.g., VAV boxes) and therefore have a point count/type meant for that purpose. They may come with a fixed set of factory-programmed sequence choices, though some manufacturers provide more flexibility than this. They also vary in the degree that they can operate autonomously. Some have time clocks for start/stop scheduling, capacity for trending and/or the ability to generate alarms. Almost all ASC’s communicate via MS/TP though versions using IP are appearing.

AAC’s have a wider range of point counts/types along with point expansion capabilities. They should support scheduling, and may also have trending and alarming capabilities (especially if needed for associated ASC’s). MS/TP and IP communications are often both available. Some AAC’s might be better classified as ASC’s due to the use of factory-programmed sequence choices (i.e., for RTU’s), while other AAC’s provide more flexibility (i.e., for custom AHU’s). Some manufacturers may even offer models that cover both approaches to an AAC.

BC’s are the top-level controller category and is used for routing information between controllers and users (i.e., via IP communications to an operator interface). Otherwise, their other capabilities can vary greatly: some have no point capacity, and provide “supervisory” control of the ASC’s/AAC’s (e.g., scheduling, trending, alarming) or may merely act as an information router. BC’s with point capacity may not be much different than a flexible AAC.

Programming – The programming language(s) used to create the sequences executed by DDC Controllers are unique to each manufacturer. This is in stark contrast to the standardized “Ladder Logic” programming used for many industrial PLC’s. The programming editor is usually not built into a controller, but it is so fundamental to its functionality that it can be viewed as an integral part of the controller’s capabilities.

[an error occurred while processing this directive]The major variation in a programming language is whether it is application-specific vs. general-purpose. “Application Specific” programming provides only a limited set of sequences for the intended applications and the editor typically uses a Q&A or template approach. “General-Purpose” allows for nearly any imaginable sequence within the limits of the language’s toolset, and they tend to come in two styles: line-oriented (which uses text elements like “BASIC”) or visual (which uses a graphical environment to manipulate the program elements).

Every BAS has a “General-Purpose” language that is used for BC’s and perhaps some or all of the lower-level controllers, though the latter & former may not be same languages. If an ASC or AAC uses a “General-Purpose” language, then this controller will “provide more [sequence] flexibility” as noted earlier. An “Application Specific” language may be used for some or all of the lower-level controllers. Finally, some manufacturers use the same “General-Purpose” for all of their controllers.

Clearly, there is great variation in how DDC controllers are programmed!

The Challenge? No DDC Controller categorization scheme works perfectly for all manufacturers. This makes open BAS specs difficult to write and enforce. Using BACnet device types as the categories is helpful as long the specifications address capabilities outside the scope of BACnet. Then there’s the question of how this affects interoperability – see Part 2 next month.

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

Events	Want Ads
Our Sponsors	Resources