The Sequence of Operations: What the Engineer Gives You and What You Owe Back

The engineer's sequence for the air handler is five sentences. The commissioning agent's functional test for that same air handler will run to dozens of steps, and it will usually be written from whatever sequence you submit. So the five sentences are not really what you will be tested against. Your sequence is. If you submitted the engineer's paragraph back with your logo on it, the test gets written from the gaps, and you find out what the engineer meant on the roof, in front of the owner.

This article covers what the design sequence gives you, what you owe back, how to fill the gaps without changing the design, and where filling gaps stops and asking starts.

What the engineer's sequence gives you

The design sequence lives in a predictable set of places: 23 09 93 for HVAC controls, 25 90 00 when the book uses Division 25, the control descriptions section on a process job, or the control diagrams on the mechanical drawings. Often it lives in two of those at once, and they disagree. Find every copy before you start.

What a design sequence is meant to carry is design intent:

• The modes the equipment runs in: occupied, unoccupied, warmup, economizer, emergency.
• What each mode is trying to hold, and roughly how.
• Safeties and interlocks: freeze protection, high static, smoke shutdown, fan proof.
• Alarms that matter to the owner.
• Sometimes a points list, sometimes setpoints, sometimes neither.

Quality varies more than any other part of the spec. Some sequences are thorough, and some reference a published sequence library such as ASHRAE Guideline 36 for the systems it covers, which hands you detailed, tested logic. Others are boilerplate from a master spec that describes equipment this building doesn't have. Read yours against the drawings before you assume it was written for this job.

What you owe back

Most controls sections require a written sequence as part of the shop drawing submittal, and the requirement is for a sequence specific to this project. Some specs say outright that restating the design sequence doesn't satisfy it. Even where yours doesn't, a reviewer will read a copy of their own words as a package that hasn't been engineered yet.

A submitted sequence should carry, for each piece of equipment:

• Point names as they will appear in the system, matching the points list and the control drawings.
• Setpoints with values, each marked adjustable or fixed.
• Modes and transitions, including what triggers each change and what happens on the way.
• Control loops named, with what each loop measures, what it moves, and what resets it.
• Alarms with limits, delays, and priorities.
• Interlocks and safeties, each marked hardwired or software, because the reviewer needs to know which ones survive a dead controller.
• Failure positions for every output on loss of controller, power, or network.
• What you filled in. Anything the design didn't state that you chose, flagged as proposed.

That last item is what turns the stamp into an answer. A proposed value the engineer stamped is a decision on the record. A value you chose silently is just your guess with an approval stapled to it.

Turning a vague paragraph into points and logic

Work it in the same order every time.

1. Split by equipment and mode. One heading per piece of equipment, one subheading per mode. Vague sequences blur these, and pulling them apart shows the holes.
2. List the points each sentence implies. "Prove fan operation" implies a status input. "Reset discharge temperature based on zone demand" implies every zone's demand is available to the air handler's controller, which is a network design question.
3. Check every point against the drawings and the points list. A sequence that uses a sensor the drawings don't show is a pricing problem as well as a programming one.
4. Fill the details with standard practice, marked proposed. Delays, deadbands, alarm priorities, minimum on and off times.
5. Leave the strategy alone. Filling in means choosing values and details the design left open. Changing means a different control strategy, a different safety, or equipment behaving differently than the engineer described. If you think the design strategy is wrong, propose the alternative separately and let the engineer choose.

Here is one small piece worked through. The design sequence says: Exhaust fan EF-1 shall run during occupied hours and shall alarm on failure. That is a reasonable design sentence and an incomplete sequence. The submitted version:

EF-1  TOILET EXHAUST FAN

Points
  EF-1-SS     Start/stop command            DO
  EF-1-STS    Run status, current switch    DI
  EF-1-FAIL   Failure alarm                 software
  EF-1-HAND   Running without command       software
  BLDG-OCC    Building occupancy schedule   software

Occupied mode
  When BLDG-OCC is occupied, command EF-1-SS on.

Unoccupied mode
  When BLDG-OCC is unoccupied, command EF-1-SS off.
  PROPOSED: a timed override from the operator workstation
  runs EF-1 for 60 minutes, adjustable.

Proof and alarms
  If EF-1-STS does not prove within 30 s, adjustable, of an
  on command, set EF-1-FAIL, priority 2, and keep the command on.
  PROPOSED: if EF-1-STS proves for 60 s, adjustable, while
  commanded off, set EF-1-HAND, priority 3.

Failure position
  On loss of controller or power, EF-1 stops: the start/stop
  relay drops out. Restarts under schedule when control returns.

Nothing in that changes what the engineer asked for. It names the points, sets the values, says what happens when things fail, and marks the two behaviors that went beyond the design so the review can accept or strike them. An air handler takes pages instead of a dozen lines, but the method is the same.

Point names in the sequence should match the points list character for character. The points list format and the BACnet object side of it are covered in the BACnet points list and PICS.

When a gap becomes an RFI

Some gaps are yours to fill. Others are questions about the design, and filling them by submittal is guessing, as laid out in submittal vs RFI. The test is what your answer changes.

Fill it yourself, marked proposed, when the answer is a value or a detail inside the stated strategy: an alarm delay, a deadband, a minimum run time, an override duration.

Send an RFI when:

• The sequence needs a point the drawings don't show. A humidity sensor, a flow station, a status contact on another trade's equipment. Somebody has to buy and wire it.
• The sequence and the drawings disagree. The control diagram shows a valve the sequence never mentions, or the sequence describes an economizer the unit doesn't have.
• A safety has no owner. The sequence says the fan shuts down on smoke detection, but neither the fire alarm section nor yours says who wires the relay.
• A required mode is missing. No generator operation, no smoke control, no freeze protection on a unit with a water coil.
• The equipment can't do what the sequence asks. The packaged unit's factory controller doesn't expose the point the sequence wants to reset.

The rule of thumb: if your answer changes what gets bought, wired, or tested, ask. A sequence built on an RFI answer is a sequence the engineer already agreed to, which makes the review faster, not slower.

After the stamp

The approved sequence keeps working after the review. The commissioning agent writes functional tests from it, so a sequence that names its points and values gives you tests you can predict and pass. Field changes during startup belong in the sequence too. The version in the O&M manual is the sequence as commissioned, not as submitted, as covered in reading 01 78 23. Keep one living copy and mark every change against it, and turnover is an export instead of a rewrite.

How Submittal Kit handles this

A vague design sequence turns into a rejected package when the gaps get guessed instead of asked. In Submittal Kit, a claimed section's demands come back quoted with their article references when you upload the spec book, so the written sequence 23 09 93 asks for is a line you answer, not a paragraph you find late. Bind your sequence as its own named section with a Custom Upload in configure sections, and it compiles into the package in the order you set. When a gap needs the engineer, write the RFI on one page, mark it sent to number it and start the clock, and record whether the answer changes the work. See submittal packages.

Disclosure: I build Submittal Kit. A sequence written this way passes review whatever software compiles it.