The News Room The News Room The News Room
Industry highlights Jan 05, 2022

Control of sustainable success: Guiding specifications

Each of these common adages reinforce the importance of practice on the outcome in competition. Well-designed and executed practice routines during which athletes systematically and diligently iterate on improving core fundamentals have a direct influence on results. Practice is predictive of success. Wanting to win is important. Leaving it all on the field, floor, or ice is imperative. But competitions are often won or loss before they begin. As an athlete practices, performance improves, and the likelihood of success increases. Developing skills and improving performance through practice are actions that can be taken proactively to influence and control the outcome.

The same philosophy is true in business and engineering. Success can be achieved periodically simply as a consequence of the market. A reactive focus on bidding open-tender projects and responding to requests for proposals are analogous to showing up on game day and hoping for the best. When there is a surplus of opportunities, a business can thrive by simply being a consumer of the marketplace. When the marketplace grows lean, opportunities wane, and peers proliferate though, this strategy becomes risky at best. While few businesses are immune to the whims of the marketplace, sustainable success in the ever-changing built environment industry can be achieved through the practiced leverage of activities that can influence the outcome, activities that are predictive of success.


Integrated Design Process

How did you learn what you know about building automation? Possibly through formal education, training, and research. Likely through experience. Almost certainly, another person, or many other people influenced your edification and development.

Design consultants, portfolio managers, and facility executives are expected to make purchasing decisions about building automation systems every day; decisions that will have a lasting impact on their facility and their day-to-day lives. Very few of these consumers are building automation professionals, very few are current on the best practices of the industry, very few are qualified to make these decisions on their own. In many cases, when a built environment consumer expresses a preference for a design trait or feature, it is because someone else has first introduced and promoted the idea to them.

Reflect: Who is educating your marketplace? Who is coaching your consumers? Ultimately, who is curating the knowledge that influences the decisions in your marketplace? In almost every case the answer is at least our peers. The logical follow-up question then is: Are we educating our marketplace? Are we coaching our consumers? Are we curating the knowledge that influences the decisions?

The previous installment of insight provided a reminder of the predictive influence which involvement in an integrated design process can leverage in favor of sustainable success. A related method that can be PREDICTIVE OF SUCCESS is providing project design assistance to consultants, portfolio managers, and facility executives.


Project Design Assistance

Contract documents such as Owner’s Project Requirements (OPR), Basis of Design (BOD), Commissioning Plans (CxP), Project Specifications and drawings, together with Sequences of Operation are commonly the framework for articulating the specific technical parameters and design intent for a construction project. These documents form the foundation for the construction process. As is true of the integrated design process, the experienced professionals of the global, independent Reliable Controls Authorized Dealer network are ideally positioned to provide concise, specialized, up-to-date support and assistance in the design and deployment of a modern automated building.

Design consultants, portfolio managers, and facility executives establish project requirements in a way common to how you learned automation. Through education, some research, hopefully experience, and almost certainly with the assistance and influence of a specialist. Most with experience in the built environment industry have read construction documents that are seemingly written for a very specific product or vendor, almost as if a vendor wrote the relevant specification articles. In many cases, that similitude is because they did.

It is very common for vendors and manufacturers to provide guide specifications; that is, project specifications designed to guide the procurement process right back to themselves. Specification clauses that speak to the best interest of the Owner, and genuinely seek the good of the organization and facility, can be a valuable instrument to expressing the OPR. However, in many cases, specmanship can creep in: presenting technical data out of context to enhance the perception of value or performance. This strategic misdirection is often achieved by presenting a valid technical characteristic or feature without perspective to a real-world benefit. In some cases, the performance might not be attainable or sustainable in a real-world application. In others, the feature might have no actual bearing on realized performance. This method can artificially increase perceived value without increasing actual, beneficial worth.

Manufacturer-influenced specifications requiring 24- or 32-bit input A/D resolution for DDC controllers is one example. In most applications this is a specification that is equally impressive as it is irrelevant to traditional indoor environmental comfort control application. Does the space temperature require 322 sample steps? What is the accuracy and precision of the sensor connected to the input? How is the sensor connected to the input? To what level of noise will the input be subjected? How will an owner benefit by this specification?

Chasing specific features of other products and specifications influenced by our peers is not sustainable, and it is not a solution that provides control of our success; indeed, it turns control of our success over to our peers. Focusing on the differentiated value proposition we bring to each specific consumer is how we wrest control from our peers. Educating consumers and proactively providing project design assistance is one way to take control of our success. Cultivating mutually beneficial solutions is often predictive of sustainable success. Consider a few examples of design traits that are mutually beneficial.



The communication protocol is the underlying foundation of a building automation system and directly defines effective ownership and sustainable access. Proprietary products and protocols can limit the owner to a specific contractor, manufacturer, vendor, or product in perpetuity. The absence or limitation of options and competition can also lead to greater support and lifecycle costs.

ANSI/ASHRAE 135 BACnet: A Data Communication Protocol for Building Automation Control Networks, is an international communication standard that was expressly designed in the interests of the facility Owner to deliver future-proof extensibility and multivendor interoperability.



BACnet was developed, and is under continuous maintenance, using an open consensus process where any interested party is welcome and may participate without fees (BACnet International, 2014). While more than 15 years and tens of millions of devices attest to its viability, BACnet is not a standard of quality. Manufacturers and vendors are free to implement the communication protocol as they wish. There is a wide spectrum of functionality, interoperability, and quality available in devices that are described as BACnet. Mutually beneficial deployment of BACnet requires consideration of some basic concepts in a project specification.

Any deployment that does not comply with the established ANSI/ASHRAE standard, becomes a non-standard implementation that gives the vendor or manufacturer ultimate control of the deployed product rather than the owner. Non-standard implementations, even minor partial proprietary deployments, can limit life cycle ownership and control while adding complexity and expense.

Ambiguity in intent or verbiage opens the specification to interpretation by the contractor or vendor during bid preparation and deployment. Imprecise terms like open protocol, open standard, BACnet compliant, or supports BACnet should be avoided. Instead:

A specification should clearly and consistently reinforce that the only acceptable communications protocol for all communication, including workstations, is BACnet.

This is a protection for the owner and the designer as well as the efficacy and efficiency of the construction process and the life cycle of the facility.


BACnet Testing Laboratories

The BACnet standard defines a standardized Protocol Implementation and Conformance Statement (PICS) datasheet for disclosing how BACnet features are implemented which is intended to be useful to third-party vendors, consumers, and consultants. However, the PICS are a form of self-reporting.



BACnet International has established a global, independent third-party testing and listing program for BACnet devices that outlines a rigorous classification methodology for defining device capabilities. Devices that have been successfully tested according to the standard test criteria (ASHRAE 135.1) bear the BTL Mark awarded by the BACnet Testing Laboratories (BTL) (BACnet International, 2014).

A specification should clearly and consistently reinforce that any device that communicates on the internetwork must be BTL-listed.

While specifying BTL-Listed devices does not guarantee functionality; it is evidence of successful, independent, third-party testing of a device and its BACnet functionality. BTL-Listed products and PICS are kept current on the BTL website and cannot be argued; eliminating ambiguity. In the first quarter of 2018 there were 858 products from 171 manufacturers bearing a BTL-Listing. Requiring all components to be BTL-Listed is an important protection to the Owner without imposing an unnecessary restriction to freedom of choice and/or competition.


Native BACnet

Protocol translation gateway devices are still used by manufacturers to deploy entire field-level networks of proprietary terminal unit devices and networks. This strategy effectively binds the owner to a single manufacturer in perpetuity, with a single BACnet communication gateway and hundreds or thousands of proprietary nodes.

A specification should clearly require every DDC device to utilize a native bacstack embedded at the media access control level.

This clause can be used to protect the Owner and to expressly exclude the deployment of proprietary protocols from being installed (or bundled) beneath a BACnet gateway, server, or workstation.


BACnet Data Links

A data link is the network layer that defines how BACnet data is transported on a specific physical layer, or communication infrastructure. There are several data links defined in the BACnet standard that are neither widely deployed nor adopted by multiple vendors. For example, BACnet over ARCNET, BACnet over LonTalk, and BACnet over ZigBee. BACnet International even acknowledges that these data links are supported by “a limited number of vendors”, “allows the transport component…to carry BACnet messages. However, the two protocols are not interoperable”, and “used as a gateway to…devices and not as a native BACnet transport” (BACnet International, 2014). Utilizing a data link that is narrowly deployed by only one or two vendors can severely impact the life cycle by limiting an Owner to the vendor(s) that supports the specific infrastructure.


A specification should clearly prescribe that only the most common data link layers are acceptable for the project: B/IP, B/ETHERNET, and MS/TP.

 Most, if not all, BACnet vendors support the most common BACnet data links: BACnet/IP, BACnet/Ethernet, and MS/TP. Prescribing specific data links in the project execution is an important protection to the Owner without unnecessary restriction to freedom of choice and/or competition.



In the past two decades manufacturers have increasingly used the United States Digital Millennium Copyright Act (DMCA) to argue that consumers do not own the software and programming that operates things like computers, smart phones, appliances, vehicles, and farm equipment. In recent years, companies like General Motors and John Deere have leveraged this philosophy to prevent owners from accessing diagnostic software and modifying programming to optimize performance (Weins, 2015).


The operation of modern facilities is reliant upon the programming that executes the sequences of operation. There are already black-box optimization routines and facility analytics suites in the built environment industry that assume ownership of facility data and controls or precludes access by the owner. System, programming, and information ownership is likely to be one of the most important concepts in building automation for the next 5–10 years, particularly with the proliferation of solutions like integral Software as a Service (SaaS) or cloud-based third-party analytics and optimization.

There is a reasonable expectation that the owner should have exclusive legal rights to all materials developed specifically for a project, and its resultant data; that these effectively become tangible components of the facility. Third-party and/or vendor ownership of facility data, databases, licensing, application programming, etc. should be considered a violation of the implied rights of ownership by the individual or organization that purchased the system. Without proper and indisputable ownership, the owner can be exposed to unexpected and undisclosed costs or can be prevented altogether from repairing, modifying, or operating the system.

A specification should clearly prescribe that all graphics, record drawings, database, application programming code, and documentation become the exclusive property of the owner upon project acceptance.

A clause of this nature is not intended to include ownership of source code for operating systems and building automation firmware or software; rather, to protect the owner by ensuring legal right to the application programming deployed, and the resultant data gathered, for the facility.



Many manufacturers significantly limit feature set, functionality, networking, integration, and database size through complex software and hardware licensing. Licenses can often add operational cost to a building automation system, particularly if annual licenses are required to be maintained for a product to function. It is common for licensing costs, even those required for delivery of the system as intended, to be concealed from the owner as part of a bid/tender strategy to artificially reduce initial cost.

A specification should prescribe that all products are licensed to, and become the property of the owner, neither prescribe nor restrict access to specific vendors, contractors, or service providers, and that all the costs associated with licensing to comply with the requirements of this specification be included in the tender.

OEM Responsibility

It is extremely common for contractors and vendors to provide components that are intended to be integrated with the system without any binding requirement to comply with the system specification or to coordinate with the system contractor. In these scenarios the component vendors often provide products that are expeditious or least expensive with little regard to compatibility with the requirements of the system or the owner. This often leads to substantial delay and costs associated with trying to coordinate responsibility for functionality. While the contractor should be ultimately responsible for the system and resolution of systems integration; all entities providing components of the system should be required to comply with the system specification. This is in the best interest of the project, the owner, and the contractor.

A specification should clearly require that all original equipment manufacturer and package DDC devices or systems provided must completely comply with all of the requirements of the specification. The OEM vendor should bear exactly the same burden of responsibility for products provided as the system contractor.

A clause of this nature simply requires that OEMs are held to the same standard of quality and responsibility as all the project stakeholders. Expensive, expansive experience proves that this clause is mutually beneficial to the owner, the consultant, the project, and the contractor.



Project documentation is only valuable to the owner if it is thoughtfully developed and strictly enforced. It is common for manufacturers and contractors to ignore clauses and articles of a specification with which they do not, or choose not to, comply with an attitude of buyer beware. Project documentations are designed to reduce risk to the owner and to the project, not to introduce risk. Requiring a statement of compliance can put the manufacturer or contractor at risk for non-compliance. Properly executed, a statement of compliance reduces the burden and risk to the consultant, the project, and the owner.

A specification should clearly require the contractor to submit a comprehensive and binding statement of compliance with the specification requirements.

Even if local contract law precludes or limits actionable recourse to a violation of contract documents, a statement of compliance can help the consultant, contracting officer, and owner to make an informed, comparative decision.


Reliable Controls Guide Specification Library

These are only a few examples of specification techniques that can be mutually beneficial: providing tangible benefit to the owner, the consultant, the project, and the Reliable Controls Authorized Dealer. ASHRAE Guideline 13 Specifying Building Automation Systems provides a designer of a building automation system (BAS) with background information, recommendations for good practice, project considerations, and detailed discussion of options with respect to the design of a BAS.

Reliable Controls Authorized Dealers are never alone. A major revision to the Reliable Controls Guide Specification Library has recently been released and is available in the Engineer tab of the Support Center.



The library incorporates the concepts described in this article and many more in a comprehensive specification for a BTL-Listed, native BACnet DDC system based upon the concepts outlined in ASHRAE Guideline 13-2015. The library also includes stand-alone, product-oriented specifications, and an annotated guide specification that describes the design intent in detail. The Reliable Controls Guide Specification Library has been carefully developed to deliver a mutually beneficial specification providing tangible benefit to the owner, the consultant, the project, and the Reliable Controls Authorized Dealer.


Lead the way

Chasing specific features of other products and specifications influenced by our peers is not sustainable. Focusing on the differentiated value proposition we bring to each specific consumer is how we wrest control from our peers. Educating consumers and proactively providing project design assistance is one way to take control of our success. Reliable Controls Authorized Dealers are ideally positioned to cultivate mutually beneficial design solutions.

Practiced repetition of determined efforts that are predictive of success is a proven strategy for taking control of a future outcome. Success can be sustainable and is within our influence, not merely at the whim of an ever-changing marketplace or in the control of our peers. We each can take control today of our success tomorrow.

BACnet International. (2014). Introduction to BACnet For Building Owners and Engineers (1.0 ed.). Marietta, Georgia, USA: BACnet International. Retrieved March 27, 2018, from

Weins, K. (2015, April 21). WE CAN’T LET JOHN DEERE DESTROY THE VERY IDEA OF OWNERSHIP. Retrieved March 27, 2018, from Wired: