Equipment phase logic is the layer where an ISA-88 batch recipe stops being an abstract sequence and starts driving real valves, pumps, and heaters. Often called the phase logic interface, it is the reusable code that lives in the equipment, listens for phase commands from the sequencer, and translates them into actual I/O. Because it belongs to the equipment rather than the recipe, the same recipe phase can reuse it across many products. It is one of the most commonly misunderstood pieces of batch architecture, and it is easy to confuse with the recipe phase that commands it.
equipment phase logic in one line: Equipment phase logic, also called the phase logic interface, is the reusable code resident in the equipment that responds to commands from the batch sequencer and drives real I/O. It exposes a standard state model - running, holding, held, restarting, stopping, aborting, complete - so that recipe phases can command it in a uniform way, independently of the specific product.
When a recipe reaches a phase such as heat to setpoint, the sequencer does not manipulate valves itself. It sends a start command to the equipment phase logic responsible for heating in that unit, along with parameters such as the target temperature and the hold time. The equipment phase logic then does the concrete work: it opens the steam valve, watches the temperature sensor, closes a loop around the setpoint, times the hold, and reports back when the phase is complete.
This code lives in the controller close to the equipment, typically in a PLC or DCS, because it must react to I/O in real time. It knows the physical details the recipe deliberately omits: which valve, which loop, which interlocks, and how this particular reactor behaves. The recipe stays clean and portable precisely because all of that grubby, equipment-specific detail is pushed down into the phase logic.
Equipment phase logic also owns safety and integrity at the phase level. It enforces the interlocks that keep the equipment safe, responds to hold and abort commands by putting the equipment into a defined state, and refuses commands that would be unsafe. Because it is written and tested once per equipment capability, that safety behavior is consistent no matter which recipe invokes the phase.
Every equipment phase logic module exposes the same state model, the ISA-88 phase states such as idle, running, holding, held, restarting, stopping, and complete, together with the commands that move between them. This uniformity is the whole point: because a heating phase and a charging phase both present the same states and respond to the same start, hold, and abort commands, the sequencer can command any phase without knowing anything about what it does internally.
That shared interface is what makes phase logic reusable across recipes. A single charge phase logic module, written once for a particular dosing header, can be invoked by dozens of recipes that all need to add an ingredient through that header. Each recipe supplies its own parameters, the target quantity and the material, but they all reuse the same tested code. Write the equipment behavior once, and every recipe that needs that capability inherits it.
Reuse also concentrates maintenance in one place. If the dosing hardware changes or an interlock needs tightening, the fix goes into the one phase logic module and every recipe that uses it benefits immediately, with no recipe edits. This is the payoff of decoupling equipment behavior from the recipe: the recipe library stays stable while the equipment layer evolves underneath it.
The recipe phase and the equipment phase logic are two different things that share a name, which is the root of most confusion. The recipe phase is the procedural element inside the recipe: it is the instruction that says perform the charge phase with these parameters at this point in the sequence. It carries no I/O logic. It is part of the procedural model and is portable across equipment.
The equipment phase logic is the code in the equipment that actually carries out that instruction. It is part of the physical control and is bound to specific I/O. When a batch runs, the recipe phase is the caller and the equipment phase logic is the callee: the sequencer takes the recipe phase, finds the matching equipment phase logic in the allocated unit, hands it the parameters, and lets it drive the equipment.
Keeping the distinction sharp clarifies where work belongs. Product-specific choices, what to charge, what temperature to hold, in what order, live in the recipe phase and are edited by recipe authors. Equipment-specific behavior, how to open the valve and close the loop safely, lives in the equipment phase logic and is written by control engineers. The clean seam between the two is exactly what lets one procedure run on different equipment and one equipment capability serve many procedures.
No. A recipe phase is the procedural instruction inside a recipe that says to run a phase with certain parameters; it contains no I/O logic and is portable across equipment. Equipment phase logic is the reusable code in the controller that actually drives the valves and loops when that phase runs. The recipe phase is the caller and the equipment phase logic is the callee.
It runs in the controller close to the equipment, typically a PLC or DCS, because it must respond to real I/O in real time. It knows the specific valves, loops, and interlocks of that unit. The batch sequencer, which may run on a separate server, commands it through a standard phase interface rather than manipulating the I/O directly.
Because a standard state model lets the sequencer command any phase in the same way, no matter what the phase actually does internally. Every phase presents the same states and responds to the same start, hold, and abort commands, so hold and abort behave predictably plant-wide and a single phase logic module can be reused by many different recipes.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.