This month’s tip: Get prescriptive.

Last month, we shared with you some of our controls design insights born from not just our actual project experience, but also from the unique experience of helping to develop the ASHRAE guideline for specifying DDC systems. In that column, we listed our first three key lessons about designing building controls the controls design is much more than just the specification; the design needs to fit the project; and know when to be performance-based. To continue this discussion…
  • Be prescriptive for key elements.
While we are proponents of controls specifications that are generally performance-based, some portions of any design need to be highly prescriptive. Open/standard communications protocols are probably the most important example of where a specification should contain explicit, prescriptive requirements. This is especially true in projects involving integration with an existing BAS. Specifications not only need to be detailed about the type of protocols and their options for each portion of the system, but they should also cover the proper protocol conformance testing and certification to which the controls must conform.

Further, today’s BAS involve the integration of controls elements spread throughout many specification sections (e.g., controls provided with mechanical equipment and/or systems in other divisions such as lighting control). This trend has shown that, for each “element” in the system, we need to very carefully and explicitly define the following.
  • The communications protocol to be used (which must be specified in both the building automation section and the other mechanical/electrical equipment sections).
  • How the elements are connected (e.g., what type of wiring and/or LAN technology is to be used). In some cases, an owner’s Ethernet/IP infrastructure can be used, but this oftentimes carries with it constraints concerning proper use of the infrastructure that should be specified.
  • What data is to be shared (and whether the data needs to be controlled or, more technically, writeable by the BAS).
  • How the joint sequence of operations is to be divided between the BAS and mechanical/electrical equipment. For example, what are the chiller controls responsible for vs. the BAS?
  • Finally, detail about the division of responsibilities between the various contractors/suppliers involved in providing and making these controls elements work together as a system (sorry, but the temperature controls contractor can’t possibly be responsible for everything involved with integrating mechanical equipment-mounted controls).
Unless the above details are spelled out, you can be pretty well assured that the low bidders for the various controls elements will not have everything required for the full integration effort included in their prices! Given the variation in protocols and protocol options supported by all of the control element bidders, it would seem an impossible task to develop a specification that covers all possible bidder combinations.

However, this where the use of the basis of design for each mechanical/electrical piece of equipment involved can come to the rescue (e.g., the design should be based on the protocol and protocol options used by each mechanical/electrical equipment basis of design, with a clear requirement about what the other bidders must include in the price should they not comply).
The development of a good controls design can often mean the difference between a conflict-prone and smoothly run BAS installation. This is becoming more and more critical every day as the various building automation controls elements are increasingly being provided under many of the other mechanical/electrical specification sections. We encourage everyone in our industry to find a way to spend more time on controls design, an effort that involves not just the controls specification but all of the key elements involved in the design of an automated building. ES