Recipe Management: Validation, Versions and Batch Records

Recipe management controls how named, versioned production settings become the parameters an application actually uses. The important questions are which values were selected, whether they passed validation, when they became active and which version a particular batch used. A dropdown and a copy operation do not answer all four.

This guide develops a fictional bottling-parameter exercise for South African PLC and HMI learners. It separates drafts, released records, load requests, active settings and batch snapshots. The numbers are classroom examples, not filling instructions, product-quality limits or evidence of a measured production improvement.

For the surrounding sequence logic, use the PLC batch mixing exercise. That exercise studies phases, pauses and counts; the present guide studies how a chosen parameter set should enter such an application.

Practise PLC sequence foundations →

A parameter set is one useful recipe model

A small machine application may call a named set of variables a recipe. Larger batch-control systems also represent procedural and equipment-related information. Avoid assuming that every use of the word means only a flat array of numbers.

The ISA-88 series overview covers batch models, recipe representation, information exchange and batch production records. Our classroom parameter model is narrower than that full scope. It is not presented as an implementation of every ISA-88 requirement.

The CODESYS Recipe Manager documentation provides a concrete example of storing and loading sets of variables. Its commands and error reporting belong to the selected product and configuration. Read those definitions before translating a generic “load recipe” instruction into native code.

For our exercise, the application procedure stays fixed while three numerical parameters vary. If a future product needs a different sequence, additional equipment or a different measurement method, changing numbers alone may not be sufficient. Identify that change in the design rather than hiding it behind another recipe name.

02

Separate five kinds of data

A draft is editable work. A released recipe record is an identified version available for selection. A load candidate is the complete snapshot being checked for a particular request. Active settings are the accepted values available to the application. A batch snapshot records the values selected for a specific batch.

Keeping these separate prevents a common ambiguity: the operator edits a library record while an earlier version is active, but the display changes its label as though the running application had changed too. Show the draft version, requested version and active version independently.

In our exercise, released records are immutable. An edit creates a new version rather than silently changing the meaning of an existing version number. Activating a version copies its values into an active snapshot. Starting a batch copies that active snapshot into the batch record.

Editing a draft does not change either snapshot. A load request does not start a batch. An accepted load also does not prove that a physical product was made correctly. These distinctions make the software behaviour testable without claiming more than the model demonstrates.

Define the fictional parameter schema

Use schema version 1 and recipe IDs SMALL, MEDIUM and LARGE. Each released record includes a positive integer revision, an explicit released status, target volume in ml, nominal rate in ml/s and a maximum duration in seconds. The three numerical process fields must be integers for this exercise.

Recipe ID	Revision	Target volume	Nominal rate	Maximum duration
SMALL	1	250 ml	50 ml/s	8 s
MEDIUM	1	500 ml	100 ml/s	8 s
LARGE	1	1,000 ml	100 ml/s	15 s

The allowed classroom ranges are 100–1,000 ml for target volume, 25–200 ml/s for rate and 2–60 seconds for maximum duration. Bounds are inclusive. Reject missing fields, Boolean values used as numbers, numeric strings and non-integer values rather than silently converting them.

There is also a relationship between the fields. Define the minimum permitted duration as the target volume divided by rate, rounded upward to a whole second, plus two seconds. The configured maximum duration must be at least that amount.

For SMALL, 250 / 50 = 5 seconds, so the required minimum is 7 seconds; its setting of 8 passes. MEDIUM also requires 7 seconds. LARGE requires 10 + 2 = 12 seconds, so its setting of 15 passes.

These calculations check consistency within our invented model. They do not estimate actual filling performance, validate a flowmeter or establish an acceptable product tolerance. In a physical application, parameter limits and relationships come from the process and equipment requirements.

Reject values before they reach active settings

A candidate with 1,000 ml, 25 ml/s and 15 seconds passes each individual numerical range, but fails the relationship: 1,000 / 25 + 2 = 42 seconds. This is why independent minimum and maximum checks are not enough.

A rate of zero must be rejected before division. The text "100" is not accepted as the integer 100 in this schema. A target of 250.5 ml fails the integer requirement even though it lies numerically inside the volume range.

Also reject an unsupported schema, an unknown recipe ID, an unreleased record or a requested revision that differs from the captured candidate. Return a specific result so the learner can explain the failure without guessing which field changed.

03

Capture, validate and activate a complete candidate

The candidate must be a stable snapshot. If the HMI writes fields one at a time directly into active settings, the application may observe a mixture of old and new values. For example, the new volume could arrive before the corresponding rate and maximum duration.

In our software model, one request contains the complete candidate and its metadata. The controller model checks it as a whole. Only a successful decision replaces the complete active snapshot and increments an activation generation number. Rejection leaves the previous active snapshot and generation unchanged.

Activation is allowed only when the exercise is idle and no batch is active. This is our chosen policy, not a universal rule for every process. A different machine may support controlled parameter changes during operation, but it needs an explicit design for those changes.

If transferring data across a real HMI, controller and database, identify the actual consistency mechanism. Staging buffers, transfer acknowledgements, version checks and supported copy operations may be relevant. A generic structure assignment is not proof that a distributed operation is atomic under interruptions.

Report the result of the operation

Rockwell's FactoryTalk View SE RecipeProDownload reference documents a status tag for the download result and an optional tag for the downloaded recipe name. The existence of a request command is distinct from observing its result.

For our exercise, use a receipt containing request ID, outcome, recipe ID, revision and activation generation where applicable. Display “requested” while the outcome is unknown. Display “active” from the acknowledged active snapshot, not from the operator's most recent dropdown choice.

The HMI tag-binding guide explains how a displayed label can drift from the value actually bound to it. Recipe displays need the same care, particularly when a request is rejected or a response arrives late.

Repeated requests need a defined rule

Suppose a client sends a load request, the operation succeeds, and the reply is lost. Sending the same request again should not create a second activation merely because the client did not see the first reply.

Our model keeps a receipt indexed by a request ID. Repeating that ID with exactly the same payload returns the original receipt without changing active settings or adding another activation record. Reusing the ID with a different payload produces RequestConflict and leaves the original receipt intact.

A rejected request is also remembered. If request 102 was rejected because the exercise was busy, replaying request 102 later returns that rejection. A new deliberate attempt uses a new request ID. This keeps a retry of an old operation separate from a new operation under changed conditions.

Request IDs are identifiers, not authentication. The model assumes requests arrive through an authorised teaching interface. A real system must scope IDs to the appropriate sender or operation and define retention, restart recovery and access control. An in-memory lookup alone does not provide durable exactly-once execution across power failures.

Worked load and retry trace

Begin with no active recipe and generation zero. All candidates below are released revision 1 records from the table. Except where stated, the exercise is idle, no batch is active and the model can record the result.

Step	Request	Action or condition	Result	Active settings
1	101	Load SMALL	Applied, generation 1	SMALL v1
2	101	Repeat identical payload	Original receipt	SMALL v1
3	101	Substitute LARGE payload	RequestConflict	SMALL v1
4	102	Load LARGE while busy	Busy rejection	SMALL v1
5	102	Repeat after becoming idle	Original Busy rejection	SMALL v1
6	103	New request to load LARGE	Applied, generation 2	LARGE v1
7	101	Replay original SMALL request	Original generation-1 receipt	LARGE v1
8	—	Start batch B01	Capture batch snapshot	LARGE v1
9	104	Load MEDIUM during B01	BatchActive rejection	LARGE v1
10	—	Finish B01	Preserve completed record	LARGE v1
11	105	Load MEDIUM; recording unavailable	RecordingUnavailable	LARGE v1
12	106	New MEDIUM request after recovery	Applied, generation 3	MEDIUM v1

Step 7 is particularly important. The receipt confirms that request 101 previously applied SMALL at generation 1. It does not say SMALL is still active, and replaying it does not roll the application back. The current active snapshot remains LARGE at generation 2.

In step 11, our model does not activate the candidate because its required recording facility is unavailable. It returns the failure without storing a receipt. The trace uses a new request after recovery. Document this distinction from remembered terminal results such as the Busy rejection.

04

Preserve the batch's actual parameter snapshot

Batch B01 started after LARGE v1 was activated at generation 2. Its snapshot contains that identity and the actual values: 1,000 ml, 100 ml/s and 15 seconds. It remains the same when MEDIUM v1 becomes active later.

Now create a MEDIUM v2 draft with a different rate. Neither the active MEDIUM v1 snapshot nor the completed B01 snapshot changes. Merely storing the recipe name would not be enough to explain which values B01 used if the library later changed.

For an assessment, export the batch identity, recipe revision, activation generation and values together. Distinguish the intended settings from actual process measurements and quality results. A snapshot says what the software selected; it does not prove that a valve delivered that quantity or that the batch met its acceptance criteria.

If a batch is interrupted, define how its identity and snapshot persist or are recovered. Starting a new batch with the same display name should not silently overwrite the previous record. The recovery policy needs to address incomplete records explicitly.

Audit records explain decisions and changes

An activation record should make its meaning clear: who or what requested the operation, the request identifier, recipe identity and revision, outcome, time information and resulting generation. Record the relevant previous identity when investigating a change between active settings.

Loads are not the only events worth considering. Draft edits, releases, rejected requests, batch starts and recovery actions can all matter to the application's traceability requirements. Choose records that answer real operational questions, rather than assuming one free-text line proves the entire history.

Our pure software exercise treats a successful state update and its activation record as one model transition. This does not demonstrate a real database transaction spanning a PLC and HMI. If an actual recording operation fails after a controller change, the system needs a defined reconciliation state; inventing a success record afterward would obscure the failure.

A timestamp alone also does not establish reliable ordering between systems. Include identifiers or sequence information, document clock handling and preserve the event outcome. A login label supplied by an unverified text field is not evidence of an authenticated person's action.

This guide does not claim that a particular log format satisfies every South African industry or export-market requirement. Match the records, approvals, retention and validation to the actual process and applicable obligations. A useful learning portfolio describes its limits clearly.

05

Checksums do not replace validation or authorisation

A checksum or CRC can help detect certain accidental changes when calculated over a precisely defined representation. It does not prove that parameter values are appropriate, that the record was authorised or that an attacker could not replace both the data and checksum.

A correctly stored record containing a rate of zero still fails this exercise. A record can also pass individual ranges while failing the volume-rate-duration relationship. Integrity checking and semantic validation therefore answer different questions.

If using a checksum in an implementation, define field order, encoding, numerical representation and which fields are included. Do not casually calculate over a structure containing its own stored checksum and expect a meaningful comparison. Native padding, byte order and format changes can affect the byte sequence.

For our worked model, correctness comes from explicit schema and value checks plus a stable snapshot. We do not claim to have implemented cryptographic authenticity, durable storage or a native controller's retention behaviour. Those require their own design and verification.

Test the rejected paths as carefully as the happy path

Start with a valid SMALL load and capture the complete active snapshot. Then submit each invalid candidate and compare the complete state afterward. Checking only a “load failed” lamp can miss a partial update that already changed one active field.

Test exact boundaries and values just outside them. Include a non-integer, a Boolean masquerading as a number, an unknown schema, an unreleased revision and a duration that fails the cross-field rule. Check that rate zero is rejected without evaluating division.

Repeat the request trace with a lost reply, a duplicate request and an ID reused with different content. Confirm that a replay of an old successful request does not reactivate its recipe. Start a batch, attempt a load, and verify that the batch snapshot remains unchanged.

The PLC program testing resource is a relevant foundation for repeatable expected-versus-observed checks. Native recipe transfer, persistence and failure recovery must also be tested in the environment that implements them.

For implementing the validation logic, review Structured Text programming fundamentals. These links support programming practice; they are not a claim that the product includes this exact recipe server, audit store or request protocol.

06

What to ask a South African recipe-management course

For training in Johannesburg, Pretoria, Durban, Cape Town or online, request the actual recipe exercise and software platform. Ask whether learners edit parameters, validate a candidate, observe a transfer result and reconstruct which version a batch used.

A short PLC course may focus on variable sets and HMI interaction. A batch-control course may go further into procedures, equipment relationships and production records. Compare the practical syllabus rather than assuming the two course titles promise identical depth.

The process-control training guide helps place this lesson in a wider learning plan. Learners working with supervisory systems can also compare SCADA training topics. Choose the next course according to the task you need to perform and the evidence you need to produce.

Do not accept an unsupported claim that recipe selection cuts every changeover from a particular number of minutes to a few seconds. Measure the relevant activities: selection, transfer, physical adjustments, cleaning, verification and production restart. Faster parameter entry may reduce one activity while others still determine the changeover duration.

Common recipe-management questions

Can I change a recipe while a batch is running?

The exercise rejects activation during an active batch. A real process may define a different controlled-change policy. Specify which settings can change, who can request that change and how the batch record captures it before implementing the behaviour.

Is a recipe name enough for traceability?

A name identifies a label, but the values behind it may evolve. Record the revision and relevant parameter snapshot with the batch. In our example, B01 retains LARGE v1 even after a later MEDIUM version is selected or edited.

Does a passed CRC mean the recipe is safe to load?

No. It does not replace type, range, relationship, version or authorisation checks. It also does not validate the physical process. The 1,000 ml, 25 ml/s, 15-second example fails the stated relationship despite individually acceptable ranges.

Why use a request ID instead of only a Load button?

A request ID lets the application distinguish a repeated delivery from a new operation. Our model returns the original receipt for an identical retry and rejects conflicting reuse. The actual implementation still needs defined storage and recovery behaviour.

What should an HMI show after a rejected load?

Show the requested recipe and the rejection reason while keeping the actual active identity visible. Do not update the active label merely because the operator selected a different recipe. Display the acknowledged result and current generation separately from an older receipt.

Practise structured PLC logic →