A control recipe describes how a batch should be made, but something has to actually walk through that recipe step by step, decide when each step is done, and tell the equipment what to do next. That something is the batch sequencer. It is the runtime engine that executes a recipe's procedural logic, coordinating phases across units while staying separate from the equipment logic that drives the hardware. This guide explains what a batch sequencer does, how it issues phase commands and evaluates transition conditions, how it handles parallel and serial branches and synchronisation, and what a dedicated batch engine adds over hand-coded step logic in a PLC.
batch sequencer in one line: A batch sequencer is the runtime engine that executes a control recipe by walking through its procedural steps in order, issuing commands to the phases, evaluating the conditions that determine when to move on, and coordinating parallel and serial branches across units. It tracks which steps are active, synchronises steps that must line up between units, and enforces the recipe's logic, while the equipment phase logic separately drives the actual valves and setpoints. It is the conductor that runs the recipe, not the hardware logic that carries out each action.
A control recipe is a structured plan of procedural elements, but it is static until something runs it. The batch sequencer is that runtime engine. When a batch is started, the sequencer takes the control recipe and begins executing its procedural logic from the top, advancing through the procedure, unit procedures, operations, and phases in the order and structure the recipe defines. It is the active agent that turns a recipe on paper into a batch in progress, keeping track at every moment of exactly where in the recipe the batch is and what should happen next.
As it walks the recipe, the sequencer's central job is to command the phases and to know when each is finished. It issues the commands that start a phase, and it watches for the phase to report that it has completed, at which point it moves on according to the recipe's structure. The sequencer holds the state of the whole batch, which steps are active, which are done, which are waiting, and it uses that state to drive the batch forward one step at a time. It is, in effect, continuously answering the question of what this batch should be doing right now and issuing the commands to make it so.
Crucially, the sequencer does this without itself driving the equipment. It commands phases; the equipment phase logic driven by those phases is what actually manipulates valves, pumps, and setpoints. This separation means the sequencer is concerned with the recipe's logic, the order, the conditions, the coordination, while the physical action is delegated downward. The sequencer is the conductor keeping the whole performance in order; the equipment logic is the musicians playing the notes. Keeping that division clear is what lets one recipe engine coordinate many different pieces of equipment coherently.
Moving from one step to the next is governed by transition conditions, and evaluating them is one of the sequencer's core responsibilities. A transition is the logic that must be satisfied before the batch advances, such as a phase reporting complete, a measured value reaching a target, or a time elapsing. The sequencer continuously evaluates the transitions relevant to the currently active steps, and only when a transition is satisfied does it move the batch on. This is what makes execution responsive to the real process rather than a blind march: the sequencer advances when the conditions say the process is ready, not merely on a fixed schedule.
Recipes are rarely a single straight line, and the sequencer handles the more complex structures they contain. Steps can run in series, one after another, or in parallel, several at once, and the sequencer manages both, tracking multiple active steps simultaneously when a recipe branches into parallel paths and bringing them back together where the recipe rejoins. It handles the divergence into branches and the convergence out of them, ensuring that parallel activities proceed independently where they should and wait for one another where the recipe demands. Managing several concurrently active steps correctly is a substantial part of what a sequencer does.
Synchronisation between units is a particularly important case of this. A batch often spans several units whose activities must line up, for example one unit must not begin a transfer until another unit is ready to receive it. The sequencer coordinates these dependencies, holding one unit's progress until the condition in another is met, so that the batch's cross-unit logic is honoured. This coordination across units is precisely the kind of thing that is awkward to hand-code and that a dedicated sequencer is built to handle, because it maintains the state of the whole multi-unit batch and can enforce the timing relationships the recipe specifies between its parts.
It is fair to ask what a batch sequencer adds over simply writing step logic directly in a PLC, for instance as a sequential function chart. An SFC can certainly march through steps and evaluate transitions, and for a simple, fixed sequence on one machine it may be all that is needed. The difference emerges as soon as the batch becomes recipe-driven, spans multiple units, or must be reconfigured for different products. A hand-coded chart bakes a specific sequence into the equipment, whereas a batch sequencer executes a recipe that is data rather than code, so the same engine can run many different recipes without reprogramming.
The separation of recipe from equipment is the heart of the advantage. With a dedicated sequencer, the recipe, the order of steps, the parameters, the branching, lives as configurable data that the engine interprets, while the equipment phase logic lives separately and is reused across recipes. Changing how a product is made becomes a matter of editing a recipe rather than rewriting PLC logic, and the same equipment can make many products by running different recipes through the one sequencer. A hand-coded SFC ties the sequence and the equipment together, which is workable for one fixed process but does not scale to a plant that must make many products flexibly.
A dedicated batch engine also brings the surrounding machinery that batch operations need and that a bare SFC lacks. It maintains the state of the whole batch in a way that supports pausing, holding, and restarting the entire recipe, it records what happened for the batch history, and it coordinates across units in a managed way. It typically pairs with recipe management, batch scheduling, and reporting so that the whole life of a batch, from selecting a recipe to producing a record, is handled coherently. All of that can in theory be built by hand around SFCs, but a batch sequencer provides it as a designed capability, which is why recipe-driven, multi-product plants reach for a dedicated engine rather than assembling equivalent behaviour from raw step logic.
Because the sequencer holds the live state of the entire batch, it is also the richest source of information about how a batch is progressing. At any moment it knows which steps are active, which transitions are pending, which branches are running in parallel, and how the units are synchronised, which together form a precise, structured picture of the batch. Exposing that picture to a supervisory layer turns a running batch into something observable, so operators and engineers can see not just individual process values but where the batch is in its recipe and why it is waiting or advancing.
For operations that run batches across multiple sites or coordinate many units, presenting sequencer state centrally is what makes distributed batch operation manageable. A cloud SCADA platform such as Merobix can surface the batch's active steps, its progress through the recipe, and the process data behind it, so a team watching remotely can follow the batch as the sequencer walks it, seeing which phase is running on which unit and whether the batch is proceeding, held, or waiting on a synchronisation point. The structured, step-by-step nature of sequenced execution is exactly what allows a clear remote view, because the batch's state can be described in the recipe's own terms rather than as a wall of raw tags.
This central visibility complements rather than replaces the sequencer's authority. The sequencer remains the engine that enforces the recipe's logic and coordinates the units, executing reliably close to the equipment; the supervisory layer observes and records what it is doing and makes that legible to people who are not on site. For a distributed operation, that combination, autonomous, recipe-driven sequencing at each location and consolidated, structured visibility across all of them, is what lets a small team oversee many batches running in many places, trusting the sequencer to run each recipe correctly while keeping a clear, shared picture of every batch in flight.
A batch sequencer is the runtime engine that executes a control recipe by walking through its procedural steps in order, commanding the phases, evaluating the transition conditions that decide when to advance, and coordinating parallel and serial branches across units. It tracks which steps are active and synchronises steps that must line up between units, enforcing the recipe's logic while the separate equipment phase logic drives the actual hardware.
A sequential function chart hard-codes a specific sequence into the equipment, which is fine for one fixed process on one machine. A batch sequencer instead executes a recipe that is configurable data, so one engine can run many different recipes without reprogramming, separate recipe logic from reusable equipment logic, coordinate across multiple units, and support holding, restarting, and recording whole batches. That flexibility and coordination is what a dedicated engine adds over hand-coded step logic.
The sequencer maintains the state of the whole multi-unit batch and enforces the timing relationships the recipe specifies between units. It can hold one unit's progress until a condition in another is met, so that, for example, a receiving unit is ready before another begins a transfer. By tracking all active steps across units and evaluating the transitions that link them, it manages the synchronisation and branching that would be awkward to hand-code across separate equipment.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.