Try the dangerous boundary case before writing the normal sequence: start filling to 120 L, then edit the next recipe to 80 L while the measured volume is 90 L. If the running sequence reads the editable field directly, it may suddenly declare filling complete. A snapshot makes the accepted job stable. Record the recipe version so an operator can explain why the running batch still targets 120 L.
A recipe describes a product; equipment performs the work
A mixing tank can fill, agitate and drain. Product A needs one quantity and mixing duration; product B needs another. The tempting implementation is two almost identical programs named MakeA and MakeB. Soon every valve repair requires editing both.
Separate product intent from equipment capability. The equipment layer knows how to admit material through a particular valve, verify flow and report failure. The recipe supplies validated quantities and process targets. The batch procedure chooses when to invoke those capabilities and records what happened.
This separation does not mean every recipe is merely a list of numbers. Some products need different operations or ordering. Begin with the actual product family and decide which variation belongs in parameters and which requires a different approved procedure. A Boolean named SpecialProductMode is often an undocumented procedure hiding in configuration.
Use standards as a vocabulary, not a badge
ISA88 provides models and terminology for batch control, including equipment, procedures and recipes. Its series also addresses data structures and batch production records. Those distinctions help teams discuss whether a problem belongs to the product definition, equipment behaviour or execution record. Consult the ISA88 series overview.
Our small example borrows the useful separation of concerns; it is not a complete implementation or compliance claim. A real project must select the applicable documents and site requirements. Do not rename a state machine ISA88 and assume the engineering is finished.
Give one batch a frozen specification
Imagine a training mixer making a 250-kilogram aqueous blend. An approved recipe requests 220 kilograms of water, 30 kilograms of a training additive, and 120 seconds of mixing after the required conditions are established. These are invented teaching quantities, not a manufacturing formula.
Use three distinct records:
| Record | Purpose |
|---|---|
| Candidate recipe | Editable proposal awaiting validation and approval |
| Active batch recipe | Accepted snapshot used by this particular batch |
| Batch result | What actually happened, including deviations and completion |
The active snapshot has a recipe identifier and revision. Editing the candidate must not alter a running batch. If controlled mid-batch changes are a real requirement, design their approval and recording explicitly rather than allowing every numeric field to remain writable.
Validate relationships, not only individual limits
Water between zero and 250 kilograms and additive between zero and 250 kilograms are individually plausible ranges. Together they can request 500 kilograms from a vessel intended for 250. Validate relationships such as total quantity, permitted ratio, minimum operating volume and equipment compatibility.
The following body excerpt assumes previously defined recipe structures and one-cycle AcceptRecipePulse. It illustrates validation and snapshot copying; it is not a complete recipe-management system. Finite-number checks, authorisation, identifiers and target-specific storage handling belong in the complete boundary.
StartBatchAccepted := FALSE;
ProposedTotal_kg := Candidate.Water_kg + Candidate.Additive_kg;
RecipeValid := (Candidate.Water_kg >= 0.0)
AND (Candidate.Additive_kg >= 0.0)
AND (ProposedTotal_kg >= 100.0)
AND (ProposedTotal_kg <= 250.0)
AND (Candidate.MixDuration >= T#30s)
AND (Candidate.MixDuration <= T#10m);
IF AcceptRecipePulse AND BatchIdle AND RecipeValid THEN
ApprovedRecipe := Candidate;
RecipeAccepted := TRUE;
END_IF;
IF StartBatchPulse AND BatchIdle AND RecipeAccepted THEN
ActiveRecipe := ApprovedRecipe;
StartBatchAccepted := TRUE;
END_IF;The first assignment makes StartBatchAccepted a one-cycle pulse. Define the lifecycle of RecipeAccepted when an approved recipe changes and consume the start pulse in the batch state machine. The excerpt highlights the data boundary; do not copy it into a machine without completing those state contracts.
Reject invalid recipes with actionable reasons. “Total exceeds vessel limit” is more useful than “Recipe error.” Silent clamping can change product composition, so it is generally the wrong response to an invalid approved formulation.
Build the procedure from verifiable operations
A simple batch might prepare the vessel, add water, add additive, mix, verify completion and discharge. Each operation needs entry conditions, active actions, success evidence, timeout or deviation handling, and a defined response to hold or abort.
For material addition, completion might mean the measured mass increase reaches the target within tolerance and flow has stopped. A valve command becoming false is not proof of delivered mass. For mixing, decide when time counts: only while the agitator reports running, while the vessel is within a temperature band, or under some other specified condition.
If a 120-second mixing requirement means accumulated valid mixing time, a standard nonretentive timer driven by MixConditionsGood may restart after every interruption. If the requirement means 120 uninterrupted seconds, restarting is correct. The words in the process requirement determine the timer design.
Hold, stop and abort need real meanings
For this example, define Hold as a controlled interruption from which a reviewed continuation may be possible. Define Abort as ending this execution and recording the batch as incomplete. A site may use additional states and more precise semantics. The important point is to specify the physical actions and recovery evidence rather than relying on the label alone.
Holding a fill could close an inlet and preserve delivered quantity. Holding a mixing operation might continue agitation to protect product quality, or stop it for another process reason. There is no universal “turn every output off” interpretation that suits every batch process.
Power interruption creates a harder problem. The retained step number says what the program last intended. It does not prove what material moved during coast-down or what an operator did while power was absent. Reconcile quantities, equipment state and batch identity before allowing further action.
Record deviations while they are explainable
Store target and actual additions, start and finish times, accepted recipe revision, holds, operator-authorised changes and the final disposition. Include the source and quality of measurements. A perfect-looking report built from invalid scale values is not traceability.
For the training blend, suppose water overshoots by 3 kilograms. Automatically adding extra additive to restore a ratio may exceed the vessel limit or violate the approved process. Treat compensation as a defined recipe capability if it is permitted, with limits and a recorded result. Otherwise hold the batch for disposition. Arithmetic alone cannot authorise a product change.
Try it
A recipe requires 90 seconds of uninterrupted mixing with confirmed agitation. The agitator runs for 50 seconds, loses feedback for three seconds, then runs for another 40. A developer reports 90 seconds total and completes the batch. What is wrong, and what should the operator see?
Work through the answer
The implementation counted accumulated running time, while the requirement specifies an uninterrupted interval. The first 50 seconds do not satisfy that interval after feedback is lost. The sequence should follow the agreed interruption policy: restart the qualification timer when valid mixing resumes, or enter a hold requiring review if the interruption is not automatically recoverable.
Show the reason and the relevant time honestly: “Mix qualification restarted after agitation feedback loss,” with the current uninterrupted duration. Preserve the interruption in the batch result. If the process owner actually intended accumulated time, change and approve the requirement; do not silently reinterpret it in code. Good batch programming keeps product decisions visible to the people responsible for them.