A process cell is the level of the ISA-88 physical model where batch production actually gets organized. It gathers together every unit and every piece of equipment required to make one or more batches, drawing a boundary around the resources a batch can use. Because a whole batch is scheduled and coordinated within a single process cell, it is also the natural scope for a batch server. For engineers deciding which equipment a batch application must coordinate, the process cell is the first thing to get right.
process cell in one line: A process cell is the ISA-88 physical-model level that contains all the units and equipment needed to make one or more batches of a product. It is the boundary within which batches are scheduled and coordinated, and a batch typically follows a specific path of units through the cell called a train.
In the ISA-88 physical hierarchy the process cell sits directly below the area and above the unit. Its defining property is completeness: it holds all the units, equipment modules, and control modules necessary to produce at least one batch of a product without reaching outside itself. A reactor, its feed tanks, its transfer lines, and the downstream vessels a batch flows into can all belong to the same process cell.
This completeness is what makes the process cell the batch boundary. A batch is planned, started, and finished within a single cell, and the batch engine treats the cell as the universe of equipment available to that batch. Nothing in a batch reaches into another cell to borrow a unit, because a cell is defined precisely so that it does not have to. Drawing the boundary well means a batch never stalls waiting for a resource that lives somewhere it cannot reach.
The process cell also determines how much equipment a single batch application must coordinate. Everything inside the cell must be arbitrated among competing batches, sequenced, and monitored together. Everything outside the cell is a separate coordination problem. Getting the cell definition right is therefore a scoping decision as much as a physical one: it fixes the span of what one batch server owns.
A process cell often contains more units than any one batch needs, so a batch does not use every unit; it uses a selected sequence of them. A train is exactly that: a specific set of units, in a specific order, that a batch travels through from start to finish. In a cell with two reactors and two blend tanks, one train might be reactor one into blend tank one, while another batch runs the parallel train of reactor two into blend tank two.
Trains let a single cell run multiple batches at once without collision, because each batch is assigned its own train and the units in one train are, for that period, dedicated to that batch. Trains can be fixed by piping or flexible, chosen at run time by the scheduler based on which units are free. Flexible trains are more efficient but demand careful arbitration so two batches never claim the same unit at the same moment.
Because a train is a run-time path rather than a permanent structure, the same physical cell supports many different trains over time. This is where cell design and scheduling meet: a well-designed cell offers enough alternate trains that batches rarely queue, while the scheduler picks trains to keep throughput high and avoid deadlock. The train concept is what turns a static equipment cell into a flexible, high-utilization batch facility.
Because a batch lives entirely within one process cell, the cell is the natural unit of scheduling. A batch server, the software that instantiates control recipes and drives them to completion, typically owns one process cell and arbitrates all the batches contending for that cell's units. Cell-level scheduling decides which batch gets which train and which unit next, resolving contention so that equipment is neither idle nor double-booked.
This one-cell-per-server pattern scales cleanly. A plant with several process cells can run several batch servers, each responsible for its own cell, and coordinate them at the site level for order release and reporting. Keeping arbitration inside the cell keeps the hardest real-time decisions local, while higher-level systems handle the slower business of order planning across cells.
For a cloud SCADA platform monitoring distributed operations, the process-cell concept translates into a useful grouping principle even outside a classic reactor hall. A cluster of field equipment that together completes one production task, and that must be scheduled and monitored as a set, behaves like a process cell. Modeling those clusters explicitly lets the platform arbitrate shared resources, present each cluster's batches coherently, and roll cell-level status up into site-wide dashboards without losing the boundary that keeps coordination tractable.
A unit is a single functional collection of equipment, such as one reactor, that operates on one batch at a time. A process cell is the larger grouping that contains all the units and equipment needed to make a batch. A cell holds many units; a batch is scheduled at the cell level and executes across the units it needs.
A train is the specific set of units, in a specific order, that a batch travels through as it moves from start to finish within a process cell. Trains can be fixed by piping or chosen flexibly at run time. Assigning each batch its own train lets a single cell run several batches at once without two batches claiming the same unit.
Because a whole batch is scheduled, started, and completed within a single process cell, the cell is the complete set of equipment one batch might use. A batch server owns a cell so it can arbitrate all batches competing for that cell's units in one place, keeping real-time scheduling decisions local while site-level systems handle cross-cell planning.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.