Last month we shared with you some of our controls design insights born from, not just our actual project experience, but also the unique experience of helping to develop the ASHRAE guideline for specifying DDC controls. In that column we listed our first three key lessons about designing building controls:

1)  The controls design is much more then just the specification
2)  The design needs to fit the project
3)  Know when to be performance based

[an error occurred while processing this directive]

To continue this discussion…

4)  Be prescriptive for key elements

While we are proponents of controls specifications that are generally performance based, there are portions of any design that needs to be highly prescriptive. Open/standard communications protocols is probably the most important example of where a specification should contain explicit, prescriptive requirements. This is especially true in projects where integration with an existing BAS is being undertaken. Specifications not only need be detailed about the type of protocols and their option for each portion of the system, but should also cover the proper protocol conformance testing and certification to which the controls must conform.

Further, today’s building automation systems involve the integration of controls elements spread throughout many specification sections (i.e., 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 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 (i.e., 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 building automation system).

• How the joint sequence of operations are to be divided between the building automation system and mechanical/electrical equipment. For example, what are the chiller controls responsible for vs. the building automation system?

• Finally, detail needs to be provided 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).

[an error occurred while processing this directive] Unless the above details are spelled 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 equipment involved can come to the rescue (i.e. 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 building automation system 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.

About the Authors

Paul and Ira first worked together on a series of ASHRAE projects including the BACnet committee and Guideline 13 – Specifying DDC Controls. The formation of Building Intelligence Group provided them the ability to work together professionally providing assistance to owners with the planning, design and development of Intelligent Building Systems. Building Intelligence Group provides services for clients worldwide including leading Universities, Corporations, and Developers. More information can be found at www.buildingintelligencegroup.com  We also invite you to contact us directly at Paul@buildingintelligencegroup.com or ira@buildingintelligencegroup.com

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

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]