BAS/EMS: Performance-based system specs spell success.
September 01, 2004
Appeared in Building Operating Management/FacilitiesNet
During the boom years of the early 1980s, when PC-based direct digital control systems were young, spec writers understood that the most effective specifications were based on technical descriptions of minimum and maximum “performance levels” of hardware and software system components at their functional levels. Since that time, performance-based specifications also have become the standard written vehicle to define integrated building automation system hardware and software components.
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 system technology performance goals. System performance 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 sub-divided to direct specific trades to provide materials or perform work in a precise manner. Therefore, 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 together 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 “Fundamental Problem Number 1”: Unless one has 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 managers and owners 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. These documents usually “guide” potential users to technology that is supported by that vendor’s operating system. Here lies “Fundamental Problem Number 2”: 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. Either of these fundamental problems can, and commonly does, lead to selection of a system that does not measure up to the owner’s performance expectations.
Start with Clear Goals
To avoid these problems, it is essential for facility executives to begin the process by setting and documenting specific technology performance goals. Commonly known as “standards” or “design criteria”, performance goals for integrated building automation systems are created to assist internal and external design consultants toward 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 building needs. A written design standard should answer the following questions:
- What must the system accomplish?
- What is the desired communication method?
- What features should be incorporated to ensure energy efficiency?
- What design constraints must be met by the new integrated system?
- Which facility building systems will be integrated?
- How will alarms be reported?
- Which system functions should be included in the system integration process?
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 developing the technical specifications of equipment quality, features and performance.
Several resources are available to aid in preparing technical specifications. The Construction Specifications Institute (CSI; see www.csinet.org/s_csi) publishes a master list of section titles using a unique numbering scheme. The CSI format is widely used among design professionals. Related construction products and activities are divided into 16 sections called divisions. The two divisions most commonly used to specify integrated automated building systems are Division 15, Mechanical; and Division 16, Electrical.
A less frequently used section, Division 17, is intended for specifying integrated fire life safety, security and IT systems. Although not formally recognized by CSI, this author has found Division 17 effective for specifying integrated building automation systems. Many controls vendors immediately recognize Division 17 as a straight automation spec, where the control vendor is requested to submit a bid as the prime contractor. In 2004, CSI will soon release an update of their MASTERFORMAT™ that will provide expansion of each division to be more acceptable to building engineering disciplines. Still in draft form, CSI will create a Facility Construction Subgroup under Division 15, possibly in the 30 series, where integrated building automation systems will be described as a facility service.
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; see www.aia.org) also has a specification format, which has its own merits. In particular, there is very effective language contained in forms covering general conditions, owner/engineer-architect agreements, and engineer-architect/contractor agreements. It can be very effective to use the CSI spec format as the basic document, and 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 (see www.bacnet.org). Specification writers for owners with global properties should be familiar with ISO standards, in particular ISO Technical Committee 207 (TC207) on Environmental Management and their global insight on sustainable design issues (see www.iso.ch). In addition, become familiar with commercial system vendors including Echelon Corporation for LonWorks communication protocols (see www.echelon.com).
Garbage In, Garbage Out
Plans, specifications, shop drawings and other contract documents are intended to completely describe the work. Deviations among them easily can, and do, arise. Specification writers should anticipate deviations and include language that directs the contractor and engineer/architect in resolving them. Unfortunately, specification writers often use confusing phrases, which lead to further misunderstandings on the part of bidders/contractors. For example, the phrase, "unless otherwise shown or directed”—the catch phase 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? Am I 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/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."
The Next Wave
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, at www.xml.org). 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
building owners and managers. For example, an engineer might design an automated
control system to program set-points 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
climate data using XML. Moreover, use of XML as a communications platform
also enables an owner with multiple sites to communicate with one another
some of these sites contain devices with older communications technology.
This is a cost-effective alternative to upgrading existing hardware and software.
The evolution of integrated building automation systems continues to proceed at a fast pace, making use of the advances in the larger IT world. To ensure top performance, rely on a clear set of design standards, the latest industry information, and an experienced systems engineer in developing performance-based specifications.
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 that provides technical solutions in such areas as building automation system design, facilities management, energy management, life safety, critical/hypercritical facilities™ consulting/engineering, and turnkey design/build services.