Commissioning: EMS Documentation
Sequences of operation are defined during the design phase of a typical design/bid/build project and revisited periodically as the project proceeds to completion. They are: design specification; shop drawing submittal; control system programming; field start-up; and as-built documents.
In my years of working with EMS systems, both as a designer and as a commissioning consultant, I have found that this process often resembles the childhood game of "telephone." This is the game where we would sit in a line, and the child at one end of the line would whisper a message into the ear of the adjacent child, and so on to the end of the line. The message received by the last child was invariably and hilariously different from the message at the beginning of the line.
With EMS documentation, this is less hilarious than it is frustrating. It is important to maintain ongoing, clear, and well-documented confirmation that the EMS control sequences are progressing towards the engineers' intended operation in order to avoid confusion and conflict regarding "acceptability" at the end of construction.
Keeping it StraightDesign specification. During the design phase, starting to think through and document the intended sequences of operation is best done early instead of late. Sequences of control can be written from system schematic diagrams and don't need to have the full installation design complete. Starting control sequences early will result in the most considered and most system-appropriate sequences for the contract documents. This is important because the contract documents are the basis to which the EMS contractor will be held accountable. If they are ambiguous or poorly coordinated, the EMS contractors could take advantage of that with changeorders or ambiguous documentation of their own.
Shop drawing submittals. In my experience, nine out of 10 EMS shop drawing submittals have sequences of operation that are "copied and pasted" straight from the contract documents. These are easy to review but do raise concerns regarding the level of effort the EMS contractor has put into evaluating exactly how to execute the design given proprietary system constraints and features. The one out of 10 submittals with sequences that deviate in minor ways and/or expand on the design specification requirements are more encouraging to receive because they acknowledge that the sequences may be slightly different (but not unacceptable) and that it is important to document those differences.
Control system programming. This is where the rubber hits the road, and we start seeing the largest deviation from specified operation. The individual actually programming the EMS is typically not the same person who prepared the shop drawings. The levels of programming skill, system knowledge, and personal accountability vary widely.
There are a variety of ways in which programmers translate the information on the EMS shop drawing into code, including: start from scratch; modify similar sequences used in previous projects; or "plug and chug" to set up preprogrammed controllers.
In addition, there are numerous ways in which programmers solicit information to help clarify sequences of operation that aren't completely clear (and they never are). These approaches include: write a request for information to the design engineer; make unilateral assumptions about "what the owner wants;" and assume the solution used in the last project is appropriate for the current project.
Field start-up. When the programs are loaded into the EMS controllers onsite, hopefully they are tested by the contractor, and adjustments are made to coordinate with and compensate for field conditions which aren't exactly as anticipated during the office programming process.
Commissioning functional tests. During the functional testing phase of commissioning, we will discover and demonstrate the variances between the designer's specified sequences and the actual programmed configuration. This is a painstaking and time-consuming process if the sequence modifications made during the programming and start-up phases haven't been well documented - and they typically are not.
As-built documentation. In order to be of benefit to the owner/operator of the systems, the as-built documentation needs to reflect the "as commissioned" state of the sequences and not the "as approved in the shop drawings" state of the sequences. In the August 2003 "Getting it Right" column, we will look at examples of the most frequently encountered "surprises" in control sequence implementation vs. specification.ES