Sequence Recovery Logic: Commissioning and Acceptance Checklist

Sequence recovery logic is the control-system function that returns a material handling operation to a known and consistent state after an abnormal interruption. It is not a safety function, a quick restart utility, or a substitute for operator judgment. Rather, it is a structured process of reconciliation between the physical world of the programmable logic controller (PLC) and the informational world of the warehouse control system (WCS). Commissioning and acceptance of this logic are frequently incomplete because teams test normal operation and safety stops in depth, but they do not test the intermediate message flows, the state transitions, or the evidence that is generated when a sequence breaks. This article explains the operating context, the component interactions, the observable symptoms, and the evidence that must be collected, and then provides a practical commissioning and acceptance checklist for warehouse operators, maintenance engineers, and controls teams.

Operating Context and Purpose of Sequence Recovery Logic #

In a conveyorized or automated storage and retrieval environment, every physical movement is expected to mirror a logical movement in the WCS. When the system is running normally, the PLC receives a transport request, executes the movement, and reports success. The WCS updates its database of load locations, carriers, and orders. Sequence recovery logic exists for the moment when that mirror relationship breaks. The break may be caused by an unexpected power loss, a jam that exceeds a timeout, a sensor failure, a network interruption, or an operator intervention that moves a load by hand.

The purpose of sequence recovery is not to resume at any cost. It is to re-establish a single source of truth about where every load is, what state every movement is in, and whether the next command can be issued safely and without duplication. The logic must distinguish among three possible outcomes: an automatic resume when the state is fully known and deterministic; an assisted resume when an operator must confirm a limited number of positions or counts; and a full reconciliation when the logical and physical states cannot be aligned without a systematic inventory refresh.

Acceptance of sequence recovery logic therefore requires an understanding of which of these outcomes should occur for each type of interruption. A system that always attempts automatic resume is unsafe. A system that always requires full reconciliation is inefficient. The accepted behavior is the one that has been deliberately designed, tested, and documented for the specific equipment and message flows at the site.

It is essential to state the boundary clearly: sequence recovery logic operates after a safe state has been reached and after relevant site procedures have been followed. This article does not provide instructions for bypassing safety devices. Site procedures, lockout requirements, OEM documentation, and competent engineering judgment take priority over any general guidance presented here.

Component Interaction and Message Flow #

Sequence recovery involves two control planes acting on the same physical equipment. The PLC owns the deterministic control: sensor inputs, actuator outputs, motion state machines, and the near-real-time tracking of load positions. The WCS owns the orchestration layer: order allocation, destination decisions, carrier identities, and the long-term database of load locations. The interface between the two planes is a message channel that may be implemented with discrete I/O, fieldbus, OPC UA, or a REST-based API. Regardless of the transport mechanism, the message flow follows a cadence that can be described abstractly.

A typical transaction consists of four beats. First, the WCS sends an assignment that describes a load, a source, and a destination. Second, the PLC acknowledges acceptance of the assignment. Third, the PLC reports execution, either as a movement started or a movement completed. Fourth, the WCS confirms that its database is updated and the transaction is closed. Sequence recovery logic is essentially the handling of broken or ambiguous beats in this cadence.

Important message types that should be named in the acceptance documentation include:

• Assignment or transport request
• Acknowledgment of assignment acceptance
• Status report from PLC to WCS
• Completion report with load and location identifiers
• Clear or cancel command
• Request for resynchronization
• Resynchronization data payload
• Heartbeat or supervision message

The central design principle is that the system must accept the as-found state, not the as-planned state. When a sequence breaks, the planned state in the WCS database may be wrong. The PLC tracking may also be wrong if a sensor failed or a load moved during the interruption. Recovery logic must gather all available evidence from both planes and converge on a defensible state. If it cannot, it must stop and request operator assistance rather than impose an assumption.

Sequence Recovery Triggers and Response States #

Sequence recovery is triggered by events that the normal movement logic cannot handle within its standard error path. Common triggers include unexpected power loss during a movement, a conveyor jam detected by a photoeye timeout, a communication drop between PLC and WCS, a carrier identification failure, a presence mismatch at a transfer point, a fieldbus interruption, or a rescuer intervention that physically relocated a load without a corresponding WCS transaction.

The PLC typically enters a dedicated recovery state, separate from faulted state. In a faulted state, the system declares an issue and waits for a reset that often clears all tracking memory. In a recovery state, the system preserves memory, freezes motion, and executes a defined sequence of evidence collection and state settlement. The distinction is critical. A fault reset that clears tracking memory may appear to solve the problem, but it destroys the very information needed to reconcile load positions.

The WCS, upon detecting the interruption or being informed of a PLC recovery state, should freeze its allocation engine and prevent new assignments that touch the affected zone. It should then respond to the PLC’s recovery request with the relevant database records: which loads were assigned, which were reported complete, and which were still in transit. The interaction can be described by a limited set of response states:

• Automatic resume: The PLC has deterministic tracking and the WCS records agree. The system re-issues a continuation command and accepts that no physical verification is required. This state is only acceptable when the evidence is complete.
• Assisted resume: The PLC has partial certainty, or the WCS has a small number of ambiguous records. The system presents a list of positions or loads for operator confirmation on an HMI. After confirmation, the sequence resumes.
• Full reconciliation: The evidence is inconsistent, incomplete, or contradicted. The system requires a zone-wide inventory read, a manual audit, or a deliberate database correction under change control.

Acceptance testing must verify not only that these states exist in the software, but that the system enters the correct state for each trigger scenario. The most common commissioning failure is not whether recovery logic executes, but which recovery state it selects.

The Acceptance Checklist #

A practical acceptance checklist does not ask only whether the system works. It asks whether the system establishes the correct known state and whether it produces the evidence needed to prove that the known state is correct. The checklist below is organized into static checks, dynamic message-level checks, and recovery scenario tests. It is general and must be adapted to the specific equipment and site procedures. It is not a substitute for the OEM’s commissioning plan.

Pre-Power and Static Checks #

• Verify that sequence recovery logic is not reachable through a normal restart path that would bypass its evidence-collection steps. A standard fault reset must not silently convert into a recovery resume.
• Confirm that all site lockout and tagout procedures are completed before any physical work on equipment involved in recovery testing.
• Verify that the PLC code version on the controller matches the as-built documentation and that the WCS application version matches the configuration baseline. Recovery logic is highly sensitive to version drift between the two planes.
• Confirm that the PLC clock and the WCS server clock are synchronized and that timestamps are generated in a consistent time zone. Sequence-recovery evidence is almost useless without reliable time correlation.
• Review the alarm and event log mapping. Every recovery trigger, every recovery state entry, and every recovery state exit must be an analyzable event with a clear English or localized description. If recovery events appear as generic “unknown fault” entries, acceptance has already failed.
• Check the HMI presentation. Operator screens that display the recovery state must be distinguishable from alarms and faults. The screen should indicate which response state is being executed: automatic, assisted, or full reconciliation.
• Confirm that no safety-related functions are part of sequence recovery logic. The recovery function must not be able to override a safety device state, reset a safety relay, or command motion without the normal safety chain being satisfied.

Dynamic and Message-Level Checks #

• Define and test the message timeout behavior. If the WCS does not respond to a recovery request within a specified time, the PLC must enter a defined wait-state and notify the operator. It must not re-send its own assumed state.
• Test duplicate and out-of-order messages. The PLC should reject a stale assignment that was already acknowledged and completed. The WCS should reject a completion message for a load that it no longer tracks.
• Verify PLC restart persistence. When the PLC restarts while the WCS remains online, the WCS must not need to re-create lost assignments from memory. It should query the PLC for current state and reconcile from there. If the PLC loses tracking memory on restart, the WCS must treat all loads in the affected zone as unverified.
• Check tracking agreement at transfer points. During a paused sequence, the states of the leading-edge, presence, and exit sensors must be consistent with the PLC internal load-tracking registers. Minor disagreement indicates the need for an assisted resume; major disagreement indicates the need for full reconciliation.
• Verify the behavior of acknowledged versus unacknowledged assignments. A load whose assignment was acknowledged but never executed must not move on a vague “continue” command. The PLC should require a specific re-issued assignment or an operator-confirmed position.

Recovery Scenario Testing #

The scenario list should be derived from the site’s actual operating risks. The following scenarios are typical and should be adapted:

• Power loss occurs while a carrier is in the middle of a transfer between two conveyors. On restoration, the operator expects that both the PLC and the WCS agree on which side of the transfer the load is on. Record the evidence and the required recovery state.
• The WCS server fails over or restarts while the PLC continues running. The PLC should not continue an unconfirmed sequence if the WCS interface was lost. Any loads moved during the gap are suspect.
• The PLC restarts while the WCS is alive. The WCS should not blindly resend all open assignments, because the PLC may have completed some of them before losing power. The system must reconcile on the basis of the last confirmed completion message.
• A sensor fails at a handoff point, so the PLC never sees the leading edge of a load. The PLC must declare an ambiguous point and request verification. It must not assume that the load continued to the next zone.
• Communication drops between PLC and WCS for a period longer than the heartbeat timeout, then restores. The system should not automatically resume from a bad state; the operator or the WCS must first confirm that no unlogged movement occurred during the drop.

For each scenario, the acceptance record should include a description of the setup, the expected response state, the actual observed state, the timestamped evidence collected, the pass or fail outcome, and the signature of the responsible engineer. A recovery test that is performed without evidence capture is not a test; it is an anecdote.

Practical Diagnostic Table #

The following table summarizes commonly observed symptoms, the most likely process layer that is failing, the evidence that should be collected, and the decision boundary that separates an operator fix from an engineering escalation. The table is intended to guide structured discussion during troubleshooting, not to replace site-specific diagnostics.