Well-designed practice routines, during which athletes iterate on improving core fundamentals, have a direct influence on results. Practice is predictive of success. Wanting to win is important. But competitions are often won or lost before they begin. As an athlete practices, performance improves, and the likelihood of success increases. Developing skills and improving performance through practice are actions you take to influence and control an outcome.
The same is true in business and engineering. Success is sometimes achieved as a consequence of the market. A reactive focus on bidding open-tender projects and responding to requests for proposals is like showing up on game day and hoping for the best. When there is a surplus of opportunities, a business can thrive just by being a consumer of the marketplace. When the marketplace grows lean, this strategy becomes risky. While few businesses are immune to the whims of the marketplace, sustainable success in the built environment industry can be achieved through the practice of activities that 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, other people influenced your development.
Design consultants, portfolio managers, and facility executives are expected to make purchasing decisions about building automation systems every day, decisions that have a lasting impact on their facility and their day-to-day lives. Very few of these consumers are building automation professionals, are current on the best practices in the industry, or 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’s because someone else introduced the idea.
Ask yourself: Who is educating your marketplace? Who is coaching your consumers? Who is curating the knowledge that influences the decisions in your marketplace? In almost every case the answer is your peers. Are you educating your marketplace, coaching your consumers, and curating the knowledge that influences decisions?
Involvement in an integrated design process is a factor to sustainable success. Another method 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, commissioning plans, project specifications and drawings, and sequences of operation provide the framework for the technical parameters and design intent of a construction project. As is true of the integrated design process, Reliable Controls Authorized Dealers are ideally positioned to provide concise, specialized, up-to-date support and assistance in the design and use of an automated building.
Design consultants, portfolio managers, and facility executives establish project requirements in a way similar to how you learned automation: through education, some research, hopefully experience, and almost certainly with the assistance of a specialist. Most people with experience in the built environment industry have read construction documents for a specific product or vendor, almost as if a vendor wrote the relevant specification articles. In many cases they did.
It is common for manufacturers to provide guide specifications—project specifications designed to guide the procurement process back to themselves. Specification clauses that speak to the best interest of the owner and seek the good of the organization and facility can be a valuable instrument to expressing the owner’s project requirement. But 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 feature without a real-world benefit. Sometimes the performance is not attainable or sustainable in a real-world application. Other times the feature has no actual bearing on realized performance. This method can artificially increase perceived value without increasing actual worth.
Manufacturer-influenced specifications that require 24- or 32-bit input A/D resolution for direct digital controllers is one example. In most applications this specification is equally impressive as it is irrelevant to traditional indoor environmental comfort control. 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? What level of noise will the input be subjected to? How will an owner benefit from this specification?
Chasing specific features of products influenced by your peers isn’t sustainable and isn’t a solution that provides control of your success. Focusing on the value proposition you bring to each consumer, educating consumers, and providing project design assistance are ways to take control of your success. Consider a few examples of mutually beneficial design solutions.
BACnet
The BACnet communication protocol is the foundation of a building automation system. Proprietary products and protocols 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 higher support and life cycle costs.
ASHRAE Standard 135, BACnet—A Data Communication Protocol for Building Automation Control Networks, is an international communication standard designed in the interests of the facility owner to deliver extensibility and multivendor interoperability.
BACnet was developed using an open consensus process where any interested party is welcome and may participate without fees. Although 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 some basic concepts in a project specification.
Any use that doesn’t comply with the ASHRAE standard becomes a nonstandard implementation that gives the vendor or manufacturer, rather than the owner, control of the product. Nonstandard implementations, even minor proprietary ones, can limit life cycle ownership and control while adding complexity and expense.
Ambiguity in intent opens the specification to interpretation by the contractor or vendor during bid preparation. Imprecise terms like open protocol, open standard, BACnet compliant, or supports BACnet should be avoided. Instead, a specification should clearly reinforce that the only acceptable communication protocol is BACnet. This protects the owner and 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 includes a Protocol Implementation and Conformance Statement (PICS) datasheet to disclose how BACnet features are implemented. It is meant to be useful to third-party vendors, consumers, and consultants, but the PICS are also a form of self-reporting.
BACnet International has an independent third-party testing and listing program for BACnet devices that outlines a rigorous classification system for device capabilities. Devices that have been successfully tested according to the standard test criteria (ASHRAE 135.1) bear the BTL logo awarded by BACnet Testing Laboratories.
A specification should clearly reinforce that any device that communicates on the internetwork must be BTL Listed. Specifying BTL Listed devices doesn’t guarantee functionality, but 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. Requiring all components to be BTL Listed is an important protection to the building owner without imposing unnecessary restriction on freedom of choice or competition.
Native BACnet
Protocol translation gateway devices are still used by manufacturers to deploy field-level networks of proprietary terminal unit devices and networks. This strategy 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 direct digital control device to use a native bacstack embedded at the media access control level. This clause can protect the building owner by preventing 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 physical layer or communication infrastructure. Several data links are defined in the BACnet standard that are neither widely used nor adopted by multiple vendors, such as BACnet over ARCNET, BACnet over LonTalk, and BACnet over ZigBee. BACnet International acknowledges these data links are supported by a limited number of vendors, allow the transport component to carry BACnet messages even when the two protocols are not interoperable, and are used as a gateway to devices and not as a native BACnet transport. Using a data link that is deployed by only one or two vendors can severely impact the life cycle by limiting an owner to the vendor that supports the specific infrastructure.
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 for the owner without restricting their freedom of choice.
Ownership
In the past two decades, manufacturers have increasingly used the U.S. Digital Millennium Copyright Act to argue that consumers do not own the software and programming that operates things like computers, smartphones, appliances, vehicles, and farm equipment. In recent years companies like General Motors andJohn Deere have leveraged this philosophy to prevent owners from accessing diagnostic software and modifying programming to optimize performance.
Building operation relies on the programming that executes a sequence of operation. Some black-box optimization routines and facility analytics suites in the built environment industry assume ownership of facility data or preclude access by the owner. System, programming, and information ownership is one of the most important concepts in building automation, particularly with the proliferation of solutions like software as a service or cloud-based analytics.
There is a reasonable expectation that the owner should have legal rights to all materials developed for a project and its resultant data—that these become tangible components of the facility. Third-party or vendor ownership of facility data, databases, licensing, and application programming should be considered a violation of the implied rights of ownership by the individual or organization that purchased the system. Without ownership, the building owner can be exposed to unexpected costs or prevented from repairing, modifying, or operating the system.
A specification should clearly prescribe that all graphics, drawings, databases, application programming code, and documentation become the exclusive property of the owner on 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 but to protect the owner by ensuring their legal right to the application programming and data for the facility.
Licensing
Many manufacturers significantly limit features, functionality, networking, integration, and database size through complex software and hardware licensing. Licenses often add operational cost to a building automation system. It is common for licensing costs to be concealed from the owner as part of a bid or tender strategy to artificially reduce initial cost.
A specification should prescribe that all products are licensed to and become the property of the building owner. The license should not restrict access to specific vendors, contractors, or service providers, and all the costs associated with licensing should be included in the tender.
.
Manufacturer responsibility
It is common for contractors and vendors to provide components intended to be integrated with the system without any binding requirement to comply with the system specification or coordinate with the system contractor. The component vendors often provide products that are the least expensive with little regard to compatibility with the requirements of the system or owner. This can lead to substantial delay and costs. While the contractor should be responsible for the system, all entities that provide components should be required to comply with the system specification. This is in the best interests of the project, owner, and contractor.
A specification should require that all original equipment manufacturer and package direct digital control devices or systems must comply with all requirements of the specification. The equipment vendor should bear the same burden of responsibility for products as the system contractor.
A clause of this nature requires that vendors are held to the same standard of quality and responsibility as all project stakeholders. This clause is mutually beneficial to the owner, consultant, project, and contractor.
Compliance
Project documentation is valuable to the owner only if it is thoughtfully developed and strictly enforced. It is common for manufacturers and contractors to ignore clauses of a specification with which they do not comply with an attitude of buyer beware. Project documents are designed to reduce risk to the owner and project, not to introduce risk. Requiring a statement of compliance puts the manufacturer or contractor at risk for noncompliance. Properly executed, a statement of compliance reduces the risk to the consultant, project, and owner.
A specification should clearly require the contractor to submit a comprehensive, binding statement of compliance with the specification requirements. Even if local contract law limits actionable recourse to a violation of contract documents, a statement of compliance helps the consultant, contracting officer, and owner make an informed decision.
Reliable Controls Guide Specification Library
ASHRAE Guideline 13, Specifying Building Automation Systems, provides a designer of a building automation system with background information, recommendations for good practice, project considerations, and discussion of building automation system designs.
Reliable Controls Authorized Dealers are never alone. The Reliable Controls Guide Specification Library is available under the Engineer tab in the Support Center.
The library uses the concepts in this article and many more in a comprehensive specification for a BTL Listed, native BACnet direct digital control system based on ASHRAE Guideline 13-2015. The library also includes standalone, product-oriented specifications and an annotated guide specification that describes the design intent in detail. The Reliable Controls Guide Specification Library provides benefit to the owner, consultant, project, and Authorized Dealer.
Lead the way
Chasing features of other products and specifications influenced by your peers isn’t sustainable. Focusing on the differentiated value proposition Reliable Controls brings to each consumer is how you can take control from your peers. Educating consumers and providing project design assistance is one way to take control of your success. Reliable Controls Authorized Dealers are ideally positioned to cultivate mutually beneficial design solutions.
Repetition of efforts that are predictive of success is a proven strategy for taking control of a future outcome. Success can be sustainable and is within your influence, not merely at the whim of the marketplace or your peers. Take control of your success today.