More than one facility executive has gone with high hopes into the process of getting a building automation system only to come away disappointed. With faster hardware, more sophisticated software, Internet access and open protocols, building automation systems promise a range of benefits that includes improvements in comfort, control, flexibility, operating costs and productivity. But facility executives may miss the benefits they are looking for unless the system is based on a well-written performance specification. And to get that, facility executives should be prepared to invest time in detailing performance goals — also known as design criteria or standards — for the building automation system.
The most effective specifications are based on technical descriptions of minimum and maximum performance levels of hardware and software system components at their functional levels. Well-written performance specifications concisely and clearly describe what the user wants in system hardware and software functional performance, open communication protocols and communication applications. The desired levels of performance are achieved by carefully selecting system components with attributes that meet or exceed performance goals. Those goals are set to conform to specific recognized standards and regulations, thereby reducing technical conflicts between rival building automation system manufacturers and equipment suppliers while supporting a competitive bidding process.
Unfortunately, specification writers often dive into the process of developing the formal written specs without first documenting their specific technology performance goals. This approach typically results in delivery of a system that fails to meet the owner’s performance expectations. In construction, technical specifications are written primarily to and for contractors. These specifications are often divided into logical sections that are again subdivided to direct specific trades to provide materials or perform work in a precise manner. The specifications must identify end devices, control panels, control software, operator computer workstations, system graphics, third-party equipment interfaces, network communication media and communication protocols.
The specifications also must detail how these components will be assembled, installed, tested, commissioned and demonstrated to operate in an integrated manner. Ultimately, the specifications must be clear and concise to enable rival building automation system manufacturers and equipment suppliers to submit competitive bids for a system that will perform as required. Here lies a fundamental problem: Without technical expertise in writing performance-based specifications for integrated building automation systems, it is very difficult to incorporate all integrated system attributes in a single spec without generating confusion and technical conflicts between rival building automation systems.
As a result of the inherent difficulty in writing these technical specifications, many facility executives have relied on vendor-provided specifications. These specifications are created and developed solely around a particular vendor’s operating system, using a specific communication protocol. There are several drawbacks to this approach. For one thing, these documents usually guide potential users to technology that is supported by that vendor’s operating system. Vendor-provided specifications ignore new technologies from rival building automation system suppliers if the vendor does not yet support those technologies.
Moreover, vendor-provided specifications rarely contain language that guarantees that hardware, software or system communication repairs, including the correction of defective work, will be done by the vendor at no cost to the owner.
To avoid these problems, it is essential for facility executives to set and document specific technology performance goals. Commonly known as standards or design criteria, performance goals for integrated building automation systems are created to help internal and external design consultants develop a design philosophy that will satisfy specific system design requirements on a corporate level. For example, the design criteria used to establish minimum and maximum accuracy tolerances of room temperature and humidity levels in a microchip manufacturer plant will be different than those required for an elementary school.
A well-written design standard conveys the expected level of quality, performance, reliability, flexibility and economical operating requirements to meet corporate facility needs. A design standard should answer the following questions:
This information need not be conveyed in technical language. What is important is that the written standard be specific and clear about the attributes the owner seeks in the system. Once the written design standard is complete, the owner should select a knowledgeable system engineer with expertise in the design of integrated building automation systems — either an in-house engineer or a professional consulting engineering firm — to develop the construction bid documents. The engineer will use the written design standard as a guide to develop the technical specifications of equipment quality, features and performance.
Several resources are available to aid in preparing technical specifications. The Construction Specifications Institute (CSI) publishes a master list of section titles using a unique numbering scheme. The CSI format, called Master Format, is widely used by design professionals.
Each CSI division comprises three main subsections. Section 1 describes general requirements that must be met prior to and during the process of executing the work. Here the specification writer usually includes a concise written scope of work, cross references to related CSI divisions or sections, warranties, code references, bidding requirements and other contract conditions, including method of payment, record drawing and submittals.
Section 2 generally describes products and materials to be used in the work. Here, the writer will define the end devices, control panels, control software, operator computer workstations, system graphics, third-party equipment interfaces, network communication media and communication protocols for the integrated building automation system.
Section 3 describes the execution of the work. Here the writer will technically describe how the system is to be physically installed and wired in a code-compliant manner, while meeting manufacturer’s system installation guidelines and owner’s written design standards.
The American Institute of Architects (AIA) also has a specification format, which has its own merits. In particular, there is an effective language contained in forms covering general conditions, owner/engineer-architect agreements, and engineer-architect/contractor agreements. It can be effective to use the CSI spec format as the basic document and to supplement it with selected AIA forms.
The specification writer also should consult additional industry resources for technical standards pertaining to specific communication protocols. In particular, the writer should consult the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) Guideline Project Committee 13 (GPC-13) for standards related to the BACnet communication protocol.
Developed under the auspices of ASHRAE, BACnet is an American national standard, a European pre-standard, and an International Organization for Standardization (ISO) global standard. The protocol is supported and maintained by ASHRAE Standing Standard Project Committee 135. Specification writers for facility executives with global properties should be familiar with ISO standards, in particular ISO Technical Committee 207 (TC207) on Environmental Management and its global insight on sustainable design issues. In addition, become familiar with commercial system vendors, including Echelon Corp. for LonWorks communication protocols.
Plans, specifications, shop drawings and other contract documents are intended to describe the work completely. Deviations among them easily can, and do, arise. Specification writers should anticipate deviations and include language that directs the contractor, engineer and architect in resolving them.
Unfortunately, specification writers often use confusing phrases, which lead to further misunderstandings on the part of bidders or contractors. For example, the phrase, “unless otherwise shown or directed” — the catch phrase that sums up the worst in spec writing — can still be found in technical specifications today.
After reading this phrase, the typical bidder will immediately ask him or herself what it means: Does a detail exist in the specification or a drawing that is different from all other similar details? Does it mean that the engineer may arbitrarily require some construction different from that shown or specified? Are bidders expected to hunt through all the documents looking for such exceptions to the general rules?
Phrases that create doubt in the mind of the bidder or contractor will always cause confusion, often leading to higher costs or requests for change orders later. In extreme cases, they can lead to lawsuits.
To avoid confusion, a good specification writer clearly describes the responsibilities of the various parties in the event of a deviation within or among the various documents. Typically, it should read something like this: “If a conflict, error, omission, or lack of detailed description is discovered in the contract documents, the Contractor shall immediately notify the Engineer (Architect) and request clarification. The Engineer (Architect) will resolve the conflict and make any corrections or interpretations necessary to fulfill the intent of the plans and specifications.”
Facility executives can take advantage of the next wave of open system integration opportunities. Extensible Markup Language (XML), an advance over HTML, has become a standard way to exchange information in IT environments that do not share common platforms. Integrated building automation systems with formerly incompatible communications protocols, that is, BACnet and LonTalk, can now communicate with one another. (There is a lot of information on the Web about XML, including a site maintained by the non-profit Organization for the Advancement of Structured Information Standards.
Various Web-based applications known as “middleware” have been developed to allow rival building automation systems to communicate with one another by providing a communication bridge.
The development of open communications protocols offers other benefits to facility executives. For example, an engineer might design an automated building control system to program setpoints based on information from a building’s outside air temperature and humidity sensor.
Alternatively, the engineer can program the system to access the National Weather Service database and download climate data using XML. Moreover, use of XML as a communications platform also has advantages for an owner with multiple sites. It would allow different sites to communicate with one another even though some of these sites contain devices with older communications technology. This is a cost-effective alternative to upgrading existing hardware and software.
Carlos Petty is an associate partner and group manager in the New York City office of Syska Hennessy Group, a consulting, engineering, technology and construction firm.
