Sequential Control, Interlocks & Permissives

Sequential control answers a different question from regulatory control. A PID asks “what continuous output reduces this error?” A sequence asks “what state are we in, what may happen next, and how do we recover when the expected event does not occur?” Reliable automation makes that state and its transition evidence explicit.

State, transition, action #

A useful state has an invariant and observable entry/exit criteria. Starting is better than Step 12 because it says what the equipment is trying to establish. A transition fires only when its source state is active and its guard is true. Actions may execute on entry, continuously while active, or on exit, but output ownership must remain unambiguous.

For a pump, a compact model might be:

$$\text{Stopped} \rightarrow \text{Starting} \rightarrow \text{Running} \rightarrow \text{Stopping} \rightarrow \text{Stopped}.$$

The Starting → Running guard is physical feedback, not elapsed time alone. A start timeout sends the sequence to Faulted, records first-out evidence, and removes the run command. “Wait five seconds, then assume running” turns missing feedback into false state.

Commands, modes, and states are different #

Conflating them creates impossible combinations such as Auto = false meaning stopped, or Start = true meaning running. A momentary start request can be accepted, rejected with a reason, or queued according to policy. The state then evolves independently while the mode controls which requests and transitions are permitted.

Permissive, interlock, and trip #

Terminology varies by organization, so define it in the project control philosophy. A useful operational separation is:

Permissive

A condition that must be true before an action starts or a state is entered. Loss after start does not automatically define the response.

Interlock

A condition or logical constraint that prevents an incompatible action or forces a defined operational response while equipment is active.

Trip

A protective action that drives equipment or process toward a specified safe state, commonly latches, and requires an explicit reset/restart procedure.

For a start request,

$$\text{AcceptStart}=\text{StartReq}\land\text{Auto}\land\text{Ready}\land\bigwedge_i P_i.$$

Once running, the command may be

$$\text{RunCmd}=\text{RunningState}\land\neg\bigvee_j I_j,$$

but the response to each lost condition must be specified individually. Low suction pressure might block start, then initiate a delayed operational stop after start. A guard-door interlock may require immediate controlled stopping and prevention of restart. A high-high process trip may belong in a separate safety instrumented function.

ISO 14119 addresses devices associated with guards and defeat resistance; IEC 61511 addresses safety instrumented systems in the process sector. Both boundaries are larger than a software contact in the basic control program.

Latching and reset #

Latch evidence when a transient fault would otherwise disappear before the operator can diagnose it. Store the first cause that initiated a trip, not merely every downstream symptom. Reset should clear memory only when:

1. the initiating condition is no longer present or a documented override is active;
2. the process is in a state from which reset is allowed;
3. the person or system requesting reset has authority;
4. reset does not itself restart hazardous motion or energy.

Acknowledgement, reset, and restart are three separate acts. Acknowledgement says a person has seen an alarm. Reset clears a latched condition after its criteria are met. Restart applies energy and therefore needs its own permissives.

Timeouts are requirements, not magic numbers #

Every transition waiting for physical change needs a timeout derived from equipment behavior and measurement delay. Record the expected range, warning threshold, hard timeout, and abnormal destination. A valve may need travel time plus position-switch debounce; a motor may need contactor delay plus acceleration and feedback filtering.

Timeouts also reveal missing states. If Starting can time out, the design needs Faulted or a defined rollback path. If Stopping can time out, the final action may be more severe than repeating the stop command.

SFC execution and state-machine discipline #

IEC 61131-3 SFC provides initial steps, steps, transitions, actions, alternatives, and parallel branches. PLCopen explains that the enclosing POU evaluates the chart once per invocation: active steps and transitions are evaluated, actions execute, and the active-step set is updated according to the defined semantics. The chart advances only as the POU is repeatedly scheduled.

Whether implemented in SFC, ST, LD, or FBD, preserve the same invariants:

• exactly the intended set of states can be active;
• every transition has one source, destination, and testable guard;
• each output has one owner or explicit arbitration;
• parallel branches have a defined synchronization point;
• abort, hold, stop, and reset behavior is defined from every reachable state;
• physical feedback reconciles retained software state after restart.

Overrides and maintenance #

An override changes the control contract and should be visible, bounded, authorized, timed, and audited. Record who applied it, why, which condition it bypasses, when it expires, and what state change is allowed. Do not implement an override by silently forcing the final output: that bypasses the very sequence state needed to diagnose and recover.

Test from transitions outward #

Test every normal transition at its boundary, then every rejected command, timeout, interlock loss, restart, and simultaneous event. Verify first-out capture before secondary alarms appear. Exercise feedback disagreement—commanded on but no run feedback, feedback on while commanded off—and prove the output state after controller or remote-I/O restart. A sequence is complete only when its abnormal exits are as explicit as its happy path.