AutomatedBuildings.com Column - Understanding Specifications Part 3 of 3

In this the third of a three-part series on control systems specifications, we now reach the all-important section on Execution, or perhaps more aptly put, How To Get The Job Done! I won’t spend too much time here, for at this point in the series I’d truly rather skip the content and focus my time more on some general thoughts regarding control systems specifications. But alas, I’ll go into this just deep enough to provide a taste of what this section is typically made up of. So here goes…

PART 3 – EXECUTION

GENERAL

This segment lists out some of the general requirements and expectations for the Work performed by this contractor. Following are a few examples of some of the general statements that might be contained in this segment:

“The BAS equipment and wiring shall be designed, installed, and commissioned in a fully operational manner…”

“All electrical installation shall be in compliance with the National Electrical Code, with any and all applicable local building codes, and with Division 26 of this specification…”

“Install equipment, conduits, and raceway parallel to building lines…”

“Verify integrity of all wiring…”

“Comply with acceptable industry specifications and standards…”

PROJECT MANAGEMENT

This segment is not always included, however if it is, then it will read something like this:

“Provide a designated Project Manager, whose responsibilities include but are not limited to:

COORDINATION

This is another segment that is more or less “optional”, and if included, is usually in the form of a generic catchall statement, such as “Coordinate work with other trades…”.

WIRING

This segment will contain the project requirements for wiring, and may include guidelines for wire sizes, color standards, cable types (plenum rated, twisted shielded pair, etc.). This section will also most likely be the place to find the requirements for conduit. Conduit requirements for low voltage control wiring can range from a complete lack of a requirement (highly unlikely), to a partial requirement (conduit in all exposed areas, plenum rated cabling above lay-in ceilings…), to a requirement for all low voltage control wiring to be in conduit, regardless (especially true in major metropolitan areas with strict building codes).

The segment may also lay out some guidelines for control panels. As such, the spec will ask that the wiring within the enclosures is neatly bundled and anchored, with all conductors tagged and color-coded. The spec may also make mention of control panel mounting requirements.

INSTALLATION REQUIREMENTS (DEVICES)

This segment will describe how certain devices should be installed, devices that are “at risk” of being installed incorrectly. The engineer can opt to list out all field devices within the scope of the project, and put forth guidelines on the installation of each and every one of them. However, it is more common to simply list out those items of which, as described above, are susceptible to incorrect installation. Such items will typically include duct averaging sensors, freezestats, duct and building static pressure transmitters, and outside air temperature sensors. Also included in this segment is the requirement for space thermostats to be a specific height above the floor, usually mandated to be 4’0” A.F.F. (Above Finished Floor).

STARTUP AND COMMISSIONING (VALIDATION)

Although sometimes longer and more detailed, this segment can realistically be handled with one or more simple generalities. Some specifications ramble on for paragraphs detailing the commissioning and validation process. This becomes more of an instructional segment, and is fine if the engineer warrants its inclusion. With LEED projects, and projects in which there is a commissioning agent involved, this becomes more or less standard procedure. For those projects that are not going for LEED certification, many engineers will simply write something to the tune of the following:

“The TCC (Temperature Controls Contractor) shall completely check out, calibrate, and test all connected hardware and software so as to ensure that the system performs in accordance with the specifications and the Sequence of Operation.”

[an error occurred while processing this directive] DEMONSTRATION AND ACCEPTANCE

This segment formally covers the turn-over of the completed project to the customer, and will typically take the form of a general statement, such as:

“Provide systems demonstration…”

or

“Demonstrate complete and operating system to the owner (owner walk-through)…”

PART 4 – SEQUENCE OF OPERATION & POINTS LISTS

The final part to any well-written control systems specification, the sequence and points lists will serve to not only provide detailed information required to bid the project, but also to provide the technical information required to design the project. As I’ve recently written columns on both topics, I won’t spend any time on this part, but instead invite you to reference those columns, as you so desire (or not!):

Some General Remarks Regarding Specifications

Specifications are documents that outline the requirements of a project. They are put together by the consulting engineer, in addition to the other contract documents (drawings, etc.). A common method of developing a specification for a particular project, as was discussed in Part 1 of this three-part series, is to start with a “master spec”, which is a generic framework of modules that typically compose a specification. The modules are each tailored to the project at hand, so that the proper details are included, and items irrelevant to the project are left out. This is academically the best method of developing a written specification.

Often an engineer will take specs that have already been written for particular projects, and piece them together to fit another project. While this “cut and paste” method is theoretically acceptable, it does sometimes lead to discrepancies. Care must be taken, as with any method of creating a specification, to avoid omission of pertinent items, inclusion of items that don’t apply, contradictions with the drawings, and even contradictions within the specification itself.

I have taken the liberty of omitting many items from the content of this three-part series, to keep it short, however omission of certain clauses and phrases from these articles does not necessarily mean that said clauses are unimportant. On the contrary, many of these clauses that I speak of must be included in a specification. A project specification is a legal contract document, and if/when problems and/or disputes arise, the specification is the first point of reference for settling the contention.

Other items that have been omitted from this series are items that may be more so engineer’s preferences or product attributes, items whose omissions will not necessarily detract from the intent of the project, nor lower the value and/or functionality of the finished product. Engineers all have their own preferences for certain items, and depending upon the project, the customer, the budget, and other variables, these items may or may not be required for a fully functional temperature control system, one that still meets the engineer’s fundamental intents. For instance, a requirement for a dedicated controller for each major component of a boiler/chiller/pumping plant may be “specified overkill”, if the entire plant can be handled by a single controller. The end user does not necessarily gain any additional value of multiple controllers serving his plant, for the added cost of multiple controllers versus one controller.

This series of articles has laid out the “typical” formatting of a temperature controls specification. It is important to understand that there are deviations from this format. Therefore, it is imperative to read a specification for a project in its entirety. Sometimes engineers will “hide” clauses in places that you wouldn’t expect to find them. They don’t do this on purpose. It’s more a result of the nature of the written specification not being completely standardized.

In addition to reading through the entire specification, it is also important to understand the jargon. The terminologies used in a specification sometimes cause vagueness and ambiguity (not to mention headache and nausea!). The interpretation of clauses and descriptions within a spec is perhaps a learned skill. Hopefully this series of articles has helped teach that skill. To understand the jargon, and to recognize what’s important to system design, operation, etc. To know what is pertinent to the project, and to know what to dismiss as generic filler or irrelevant fodder. To interpret the engineer’s ink and align your thought processes with the engineer’s basic intents.

For those of whom write specs, a word or two of advice from those of us that have to read them: Keep It Short, When You Can! It is very difficult to read through a 100 page temperature controls spec and still focus on what’s important. A well-written 30-page document tailored specifically for a project will likely benefit the project more than one with pages and pages of hardware specs and archaic clauses. If the individual preparing the specification is intimately familiar with the ins and outs of the project at hand, then it shouldn’t be that difficult to write a custom spec for the project, leaving all of the usual filler and disclaimer material on the cutting room floor.

Project specifications are a part of any “plan and spec” project. They need to exist, for the good of the customer. Specifications should be kept clear and concise. They should demonstrate accuracy and consistency, and should be developed on a per-job basis. Strict attention should be paid to the development of specs, as they can be a benefit or a detriment to a given project. The well-written spec can add value to a project, in terms of engineering, coordination, expectations, etc. The poorly written spec can hurt even the simplest project.

The engineer’s written specification should be looked upon as a contract document that will assist all parties involved with a project, at the same time guaranteeing that the customer will get what is value to him. The specification should not be looked upon as, often as it is, a “necessary evil”.

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

Events	Want Ads
Our Sponsors	Resources