How to Read a Control Sequence of Operation

Why this matters

A sequence of operation is written in paragraphs, which makes it read like description and hides the fact that it is a specification. Everything you need to test a control system is in there, and none of it is in a form you can test directly. Techs read it once, take away a general impression of how the thing works, and then diagnose off that impression, which is how a unit gets condemned for failing to do something it was never written to do. Converting the prose into a step table takes a few minutes and turns a narrative into a list of things you can watch, measure, and time.

Before you observe a live sequence

Watching a sequence run means watching energized equipment, so decide how you will observe before you decide what to observe.

Take every observation you can from outside an energized enclosure first: the controller's own status display or diagnostic output, indicator lights visible through a window, the thermostat or user interface, audible and visible state changes. Most sequences can be walked most of the way this way.

Where you must measure inside an energized control enclosure, that is energized electrical work. Use test leads and probes rated for the circuit and the environment, keep your other hand out of the enclosure, wear the protective equipment the task requires, and never defeat a door interlock to keep a circuit made while you work. Where the observation can wait until the equipment is off, de-energize the branch circuit at the disconnecting means and apply your own lock and tag, which is what 29 CFR 1910.333(b)(2) requires for work on or near electrical conductors in general industry and 29 CFR 1926.417 requires on construction work, then prove dead per NFPA 70E-2021, 120.5 by testing your meter on a known live source, testing the conductors, and re-testing the meter.

If your test involves forcing the machine into a state rather than watching it, de-energize and lock or tag before servicing where unexpected energization or the release of stored energy is possible, which is 29 CFR 1910.147, and discharge capacitors, relieve pressure to zero on a gauge, and block spring tension before anything is opened. Never induce a fault on a combustion path, a pressurized path, a refrigerant-bearing path, or any device serving a relief or protective function. Those are the paths where a test that goes wrong does not give you a second attempt.

What a sequence of operation actually is

It is a state machine written in English. The equipment occupies one state at a time, advances to the next when specific conditions are satisfied, and takes a defined branch when they are not. Everything in the document serves that structure, even where the prose disguises it as narration.

Read it that way and two things follow. Every state has an observable, because a state the equipment can be in is a state you can catch it in. And every transition has a cause, so the question "why is it not advancing" always has a bounded answer.

The six elements to pull out of every sentence

Each sentence in a well-written sequence carries some subset of six elements. Your job is to name which ones it carries and which it leaves to be inferred.

1. Trigger - what starts this step. A call, a schedule, a completed prior step, a measured value crossing a setpoint.
2. Permissive - what must already be true for the step to be allowed. Safety devices closed, a prior proof still holding, an interlock made.
3. Output - what the controller energizes, de-energizes, or modulates.
4. Proof - what must report back to confirm the output produced its effect, and within what window.
5. Timing - delays, minimum on and off times, purge periods, interstage delays, retry intervals.
6. Failure response - what happens if the proof does not arrive: retry, hold, alarm, lock out.

A sentence that carries an output and no proof is telling you the controller advances blind at that step. That is worth noticing rather than assuming the document is incomplete.

Sentences that hide a permissive

Permissives are the element most often buried, and they hide in three phrasings.

"Provided the safety circuit is satisfied" reads as a qualifier and is a hard gate. "On a call for operation, and with no active alarm" puts the permissive after a comma where it scans as an aside. And "under normal conditions" is a permissive with its content deleted, which means the conditions are stated elsewhere, usually in a separate alarm or limits section, and you have to go get them.

Anything you cannot express as a device that is either made or not made is not yet a permissive you can test. Push until it resolves into one.

Timing is where the prose goes thinnest

Sequences routinely name a delay without giving its value, because the value lives in a controller parameter list rather than in the narrative. Every unspecified delay is a blank in your table, and a blank in your table is a measurement you cannot judge. Collect the values from the controller's parameter documentation before you start timing anything, or you will record a purge period with nothing to compare it against.

Converting prose to a table

Work one sentence at a time, in document order, and give each state its own row. Where a sentence describes two states, split it. Where two sentences describe one state, merge them. Then fill the six columns, and mark every cell you had to infer rather than read, because those are the cells to verify before you rely on them.

The artifact: a converted sequence

Here is the output for a generic staged appliance with a prove-before-advance chain. The pattern applies across trades: a heating appliance, a refrigeration circuit with a flow proof, and a pumped system with a pressure proof all share this skeleton. Timing values below are illustrative and would come from the controller's parameter list on a real unit.

Seven working states plus a lockout state, and every one of them observable.

Now read the arithmetic out of the table, because that is what the table is for. From the call at step 2, the earliest the primary output can be proven is the 30-second purge plus up to a 10-second proof window, so 40 seconds. Stage 2 is gated 5 minutes, 300 seconds, after the stage 1 output. So the earliest stage 2 can appear is 340 seconds after the call, which is 5 minutes 40 seconds. A tech who waits 5 minutes flat, sees one stage, and writes up a failed second stage has diagnosed a fault that does not exist. That single number is the most common reason a staged unit gets a part thrown at it.

The failure side is equally checkable. Three trials before lockout, each carrying a 30-second purge and a 10-second trial window, is at least 3 times 40 seconds, so 120 seconds, 2 minutes, to reach lockout, and longer if the controller runs an interpurge between trials. A unit that locks out in well under 2 minutes is not running the trial count this sequence describes. Either the controller's parameters do not match the document, or you are watching a different fault path entirely, such as a safety-string opening at step 2 rather than a proof failing at step 4. Both are useful findings and neither is available to someone who has only read the prose.

Mark the inferred cells. In the table above, the permissive in row 6 ("stage 1 proven and running") is inferred rather than stated, because the source prose said only that the second stage follows after a delay. That is exactly the cell to confirm, because whether stage 2 is gated on stage 1 still proving changes what a stage 2 failure means.

Where the written sequence and the installed controller disagree

A sequence of operation is usually written by whoever specified the system, and the controller is usually shipped by whoever built the equipment. Those two are frequently not the same, and the gap shows up in predictable places.

Timing values are the first. Purge periods, interstage delays, and minimum run times are nearly always field-adjustable parameters, and a unit that was commissioned by somebody who changed one is running a sequence the narrative no longer describes. The narrative does not get updated when a parameter does.

Configuration is the second. A sequence written for a two-stage machine and installed on a single-stage one still reads as authoritative, and the step it describes simply never occurs. Count the stages, the pumps, or the circuits in front of you against the count in the document before trusting the step numbering.

A retrofitted controller is the third and the worst, because it brings its own sequence and its own parameter set while the original narrative stays in the binder. Where the two disagree, the controller governs the behavior and the narrative governs what somebody expected, and the difference between those is often the complaint you were called about.

Resolve it by reading the controller's own parameter list as the primary source and the narrative as intent. Record the as-found parameter values in the equipment record before you change any of them. That record is the only way the next person can tell a deliberate commissioning decision from a value somebody nudged during a callback.

References

• 29 CFR 1910.333(b)(2) and 29 CFR 1926.417, requirements to de-energize and lock or tag before work on or near electrical conductors in general industry and in construction
• 29 CFR 1910.147, control of hazardous energy for servicing where unexpected energization or release of stored energy is possible
• NFPA 70E-2021, 120.5, the test-before-touch sequence for verifying an electrically safe work condition
• Manufacturer control documentation conventions for sequences of operation and controller parameter lists
• See related: The Sequence of Operation as a Diagnostic Instrument