Writing clear sequences of operation

The sequence of operation is the instruction set for an HVAC system. It tells the controls contractor what the system should do in every mode, it tells the commissioning agent what to test, and it tells the operator how the building is supposed to behave years later. Yet sequences are often the weakest part of a mechanical design package: vague phrases like "control to maintain setpoint" or "provide economizer operation" leave every important decision to the programmer, and the result is a building that works differently from what the designer intended.

This guide explains how to structure a sequence, what it must contain, and how to write language that is clear enough to program and test.

Why sequences matter

A large share of the deficiencies found during commissioning and retro-commissioning trace back to controls: loops fighting each other, simultaneous heating and cooling, economizers that never open, resets that were never programmed. Many of these come from ambiguous sequences rather than poor programming. When a sequence is clear, the programmer has less to interpret, the commissioning agent has a script to test against, and arguments about intent disappear.

Energy codes also depend on sequences. NECB and ASHRAE 90.1 require features such as setpoint deadbands, setback, economizer controls, supply air temperature reset and static pressure reset. If the sequence does not specify them clearly, they may not be delivered.

Structure of a good sequence

Organize sequences by system, then by mode and function. A typical structure for an air handler:

1. System description: what the system serves, its major components, and a reference to the points list and control schematic.
2. Operating modes: occupied, unoccupied, warm-up, cool-down, setback, economizer, smoke control, fire alarm shutdown, and any special modes such as wildfire smoke mode.
3. Start and stop: schedules, optimal start, interlocks and proving.
4. Control loops: each controlled variable, its sensor, its setpoint, the device that controls it, and the reset logic.
5. Safeties and interlocks: freezestats, high and low static limits, smoke detectors, fire alarm interfaces.
6. Alarms: conditions, delays, priority and who is notified.
7. Failure modes: what happens on sensor failure, loss of communication, power failure and restart.
8. Points and trends: which points must be trended and at what interval, and which must be visible on graphics.

What every control loop must define

For each loop, the sequence should answer these questions:

Ranges, limits and defaults should be stated as numbers, marked as adjustable where appropriate. "Adjustable" alone is not enough: the programmer needs a default value and the operator needs to know the allowable range.

Writing clear language

Use consistent, defined terms

Define terms such as "occupied mode", "proven on" or "zone request" once, then use them consistently. If a sequence says "fan status", "fan proven" and "fan running" in different places, a programmer may implement three different checks.

Be specific about conditions and timing

Instead of "when the outdoor temperature is low, open the preheat valve", write: "When outdoor air temperature is below 2 °C (36 °F, adjustable) and the supply fan is proven on, modulate the preheat valve to maintain preheat coil leaving air temperature at 7 °C (45 °F, adjustable)." Include delays and hysteresis to avoid short cycling: "Enable after 5 minutes (adjustable) of continuous request; disable when request has been absent for 10 minutes."

Describe the sequence of devices

Where several devices serve one loop, state the order clearly, for example a single loop output split into ranges: heating valve from 100 percent to 0 percent, then economizer dampers from minimum to full open, then cooling valve from 0 to 100 percent. Split-range or sequenced control prevents simultaneous heating and cooling.

Avoid control by description of hardware

"Use a PID loop" says little. Specify what is controlled and how it responds. Leave loop tuning parameters to field tuning, but require that loops be tuned for stable response and documented. See PID control loops and tuning.

Avoid contradictory requirements

Read each mode against the others. A fire alarm shutdown sequence that conflicts with stairwell pressurization, or an unoccupied mode that conflicts with freeze protection, will cause problems. Life safety interfaces should be coordinated with the fire alarm designer and tested under CAN/ULC-S1001 integrated testing where applicable.

Use standard sequences where you can

ASHRAE Guideline 36 provides tested, detailed sequences for common air handling and terminal unit systems, written to be programmed directly. Referencing Guideline 36 and stating any deviations can save significant design effort and improve consistency. See ASHRAE Guideline 36 high-performance sequences. Custom systems such as laboratories, data centres and cleanrooms still need project-specific sequences.

Common mistakes

• Missing modes, especially warm-up, unoccupied, and recovery after power failure
• Setpoints stated without units, defaults or ranges
• No definition of how zone requests or demand signals are generated
• Fixed setpoints where codes require resets
• Alarms that fire constantly because they lack delays or are not suppressed during start-up
• No specification of what happens when a sensor or communication link fails
• No trend requirements, leaving operators blind after turnover

Making sequences testable

Write each requirement so a commissioning agent can verify it with a pass or fail result. A useful test is to ask, for each sentence: what would I observe to confirm this works? If the answer is unclear, rewrite the sentence. Functional test scripts can be built directly from well-written sequences, which shortens testing and reduces disputes. See functional performance testing.

Sequences should also be kept current. When the system is modified, the as-built sequence in the O&M manual should be updated, and the BAS program should match. Our control system verification work frequently starts by comparing the programmed logic with the written sequence.

Key takeaways

• A sequence of operation should define every mode, loop, interlock, alarm and failure response for each system.
• State setpoints with units, defaults and adjustable ranges, and include delays and hysteresis.
• Use consistent defined terms and describe the order of devices to avoid simultaneous heating and cooling.
• Reference ASHRAE Guideline 36 where it fits, and document deviations.
• Write every requirement so it can be tested, and keep the sequence updated after changes.