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 and 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:

ASCs 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 ASCs communicate via MS/TP though versions using IP are appearing.

AACs 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 ASCs). MS/TP and IP communications are often both available. Some AACs might be better classified as ASCs due to the use of factory-programmed sequence choices (i.e., for RTUs), while other AACs provide more flexibility (i.e., for custom AHUs). Some manufacturers may even offer models that cover both approaches to an AAC.

BCs are the top-level controller category and are 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 ASCs/AACs (e.g., scheduling, trending, alarming) or may merely act as an information router. BCs 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 PLCs. 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.

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 BCs and perhaps some or all of the lower-level controllers, though the latter and former may not be the 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 two next month.