ASHRAE Guideline 36 and Standardised Control Sequences

Ask three controls contractors to implement the same written sequence of operation and you will get three different buildings. Not because any of them is incompetent, but because a paragraph of English prose describing how an air handling unit should behave contains dozens of unstated decisions: what the reset logic does at the limits, how long a delay lasts, what happens on a sensor fault, what order things start in, what the deadbands are. Each contractor fills those gaps from their own house practice, and the resulting building is a one-off that nobody can verify against anything. Guideline 36 is ASHRAE's attempt to close those gaps by publishing the sequences in full.

The message up front: Guideline 36 is a voluntary ASHRAE guideline, not a code and not a mandatory standard, that publishes detailed sequences of operation for HVAC systems with three stated aims: energy efficiency and performance, control stability, and sequences detailed enough to support real-time fault detection and diagnostics. Its practical value to a building owner is less about the energy saving than about verifiability: for the first time you can specify a sequence that has one correct implementation, and then test whether you got it. Its practical cost is that it demands more design definition, more commissioning effort and more capable controls hardware than the loose approach it replaces, and specifying it casually in a tender produces a worse outcome than not specifying it at all.

1. What Guideline 36 is, and what it is not

ASHRAE Guideline 36 is titled High-Performance Sequences of Operation for HVAC Systems. The current edition at the time of writing is Guideline 36-2024, which ASHRAE describes as incorporating 23 addenda to the previous 2021 edition, and the guideline continues to be amended through the normal addendum process, so the edition you specify should be checked against ASHRAE's own standards and guidelines listing rather than taken from any secondary source including this page. Earlier editions exist and are superseded.

Three distinctions matter before anything else:

• It is a guideline, not a standard. In ASHRAE's structure, standards contain mandatory language and are written to be adopted into code. Guidelines are advisory. Guideline 36 therefore carries no legal force anywhere by itself. It becomes binding on a project only because somebody wrote it into a specification, which means the quality of that specification is doing all the work.
• It is a sequence library, not a design method. It does not tell you what plant to select, how to size it, or what the building needs. It tells you how the controls should behave once the plant exists. Design decisions remain design decisions.
• It is not a product. No manufacturer owns it, and a claim that a platform "is Guideline 36" is not meaningful on its own. What is meaningful is whether a given controls platform and contractor can implement the specified sequences faithfully and demonstrate that they have.

2. The problem it is actually solving

The conventional route produces a specific and well-known set of failures, and recognising them is the best argument for the guideline:

• Ambiguous sequences. A prose description that reads clearly to its author leaves the implementer guessing on timing, limits, failure behaviour and order of operations. The building then works in a way nobody specified.
• Unverifiable outcomes. If the sequence does not state precisely what should happen, no test can establish whether it is happening. Commissioning degrades into confirming that the plant runs rather than confirming that it runs correctly.
• House variants. Each contractor's library of standard blocks carries its own assumptions. The same specification implemented by two firms yields two different energy profiles, neither of them wrong against the words.
• Lost intent over time. Five years later, nobody can say whether the current behaviour is the design intent, an optimisation, or a workaround for a fault. The sequence document, if it survives, is too vague to adjudicate.
• Analytics with nothing to compare against. Fault detection needs a statement of correct behaviour to test against. A vague sequence makes automated diagnostics largely guesswork, which is a recurring theme in BMS energy optimisation, FDD and analytics.

That last point is the one I find most persuasive and the one most often left out of the sales conversation. Precision in the sequence is a prerequisite for automated diagnostics, not a nice-to-have alongside it.

3. The three aims, and why the middle one is underrated

ASHRAE states the guideline's purpose in terms of three outcomes: maximising energy efficiency and performance, providing control stability, and allowing for real-time fault detection and diagnostics.

Energy efficiency is the one that gets quoted. Fault detection readiness is the one that matters most over a building's life. But control stability is the one that most deserves attention from anyone who has operated a building, because instability is the mechanism by which good intentions get switched off. A sequence that hunts, cycles plant, or fights between loops produces occupant complaints and mechanical wear, and the operator response is almost always to put something into manual. Once plant is in hand, every efficiency measure above it is irrelevant. Sequences written with explicit deadbands, delays, hysteresis and staging logic are harder to destabilise, and a stable sequence is one that is still running in its designed mode two years later.

4. What changes on a project that specifies it

For a client or facilities team, the visible differences are mostly in process and documentation rather than in plant.

The row that gets cut is commissioning. It is at the end of the programme, it is the first thing compressed when the project is late, and the benefit of the whole exercise lives in it. A project that specifies detailed sequences and then skips their verification has bought the cost and none of the value.

5. Control sequence verification, and how it differs from a loop check

People searching for "control sequence verification" are usually looking for the distinction between three activities that get conflated, so it is worth setting out plainly.

• A loop check proves one point. Apply a known stimulus at the field device, confirm the value appears correctly at the operator front end, or command an output and confirm the physical device moves. It proves the wiring, the device and the scaling. It says nothing about behaviour. The method is set out in BMS points lists and field devices.
• A functional test proves one function. Does the fan start when enabled, does the valve modulate, does the alarm appear. It confirms that individual capabilities work.
• Sequence verification proves the logic. Drive the system through its states, including the transitions and the failure cases, and confirm that it does what the sequence says at each one. Not that the economiser damper moves, but that it moves in the right direction, at the right conditions, with the right limits, and reverts correctly when conditions change back.

The third is the one that is usually missing, and it is the only one that validates the thing you specified. A verification plan worth the name covers, for each sequence: normal operation at the design condition, operation at the boundaries where logic changes state, every mode transition including the ones that only happen seasonally, the specified response to each sensor and device failure, and the correct release of any override. The practical difficulty is that some of these conditions cannot be waited for, so they have to be simulated by overriding inputs, which has to be done carefully and then undone completely.

6. What it does to the points list and the procurement

A detailed sequence references specific measurements, and a sequence that references a measurement you did not buy cannot run. So specifying published sequences has a direct effect on instrumentation scope, and this is where tenders go wrong: the sequences are specified, the points list is inherited from a previous project, and the two do not match. The contractor then either prices the extra points as a variation or implements a reduced version of the sequence, and the second is more common because it is invisible.

What I would insist on, from the procurement side rather than the engineering side:

• Derive the points list from the chosen sequences, in that order. Not the reverse, and not in parallel by two different parties.
• Require a written cross-reference from each sequence to the points it needs, as a submittal. Any sequence with a missing input is then visible on paper before it is invisible in the building.
• Confirm controller capability explicitly. Detailed sequences assume the controller can execute the logic, hold the parameters, and expose them. Not every terminal-unit controller in every product range can, and discovering this after award is expensive.
• Require the parameters to be exposed and adjustable at the front end, with their names matching the sequence document. A sequence whose tuning parameters are buried in compiled logic cannot be adjusted by anyone but the original programmer, which returns you to the lock-in question discussed in BMS service contracts.
• Put the verification records in the payment milestones. Commissioning evidence that is not tied to money arrives as a tick sheet.

The specification wording for most of this belongs with the rest of the controls clauses, covered in BMS specification clauses.

7. Where it fits, and where it does not

The guideline's most developed material is on air-side systems, and the natural fit is a new-build or major-refurbishment project with multiple-zone air handling plant and zone terminal units, where the design team has the capacity to define the sequences properly and the programme has room for real commissioning. If you are unfamiliar with the plant it addresses, the background is in what an air handling unit is and what a VAV system is. Because editions expand the scope, the current table of contents is the authority on exactly which systems are covered rather than anything stated here.

The situations where I would not push for it:

• A small building with simple plant. The overhead in design definition and commissioning is real, and on a handful of simple units it can exceed any benefit. A clear conventional sequence, properly verified, is a perfectly respectable outcome.
• A controls retrofit onto existing instrumentation where the points needed are not present and cannot economically be added. A partially implemented detailed sequence is worse than a well-implemented simpler one, because the documentation then describes a building that does not exist.
• A project with no commissioning budget or programme. As above: all cost, no benefit.
• A design team with no experience of it. Specifying a library nobody on the team has implemented tends to produce a specification that references it without using it, which contractors price as ambiguity.
• Plant types where the guideline's coverage is thin. Specifying it as a blanket requirement across a mixed estate, including systems it does not address, produces clauses that cannot be complied with.

8. The common ways specifying it goes wrong

This is the section I would most want a client to read, because these failures are all procedural and all avoidable.

• The blanket reference. A single line requiring compliance with the guideline, with no sequence selection, no parameters and no points cross-reference. This transfers all the definition work to the contractor while sounding rigorous, and the contractor will quite reasonably interpret it in whatever way is cheapest to defend.
• Specifying it and then value-engineering the instrumentation. The points go, the sequences stay in the document, and the building is handed over with sequences that cannot execute as written.
• No parameter values. Published sequences are parameterised; somebody has to choose the project values. Left blank, they arrive as whatever the contractor's library defaults to, which is the exact outcome the exercise was meant to prevent.
• No submittal review. The software submittal is the one opportunity to catch a divergent implementation on paper. Accepting it unread converts the whole approach into paperwork.
• Commissioning compressed to a demonstration. Discussed above, and the most common of all.
• No retest after post-handover changes. Sequences get adjusted in the first year as complaints arrive. Without a retest discipline, the verified state is historical within months and nobody knows what the building is currently doing. This is the operational habit set out in BMS maintenance, servicing and lifecycle, where an annual sequence review is the mechanism that keeps the documented intent and the running logic from diverging.

The idea to walk away with

The real contribution of published, detailed control sequences is not that they are more efficient than what a good engineer would design. It is that they are precise enough to have exactly one correct implementation, which makes them the first control sequences in most buildings' history that can be tested rather than merely described. Everything useful downstream, stable operation, meaningful commissioning evidence, automated fault detection, an auditable statement of design intent, depends on that precision.

So the decision is not really whether to specify Guideline 36. It is whether your project has the design definition, the instrumentation and the commissioning programme to use it. With all three, it is a strong choice. With none of them, naming it in a specification buys a longer document and a weaker building, and a clear conventional sequence that is actually verified would serve you better.

Final thoughts

If you are in operations rather than on a project, the useful version of this is smaller and immediately actionable. Find the sequence of operation for one of your air handling units. Read it, and mark every sentence where two engineers could reasonably differ. Then compare it with what the plant is currently doing. That exercise, on one unit, tends to reveal more about the state of a building's controls than any report, and it makes the case for precision far better than any guideline reference can.

It also tends to surface the real question, which is not about sequences at all: whether anyone currently knows what the building is supposed to be doing. Where the answer is no, that is the thing to fix first, and it costs nothing but attention.

Related reading: BMS in HVAC: controls and sequences, BMS commissioning and graphics, BMS points lists and field devices, BMS energy optimisation and FDD, BMS specification clauses, What a VAV system is.