Key decisions
Start with operating decisions, not a list of protocols
- Describe what the machine must do when upstream starves, downstream blocks, product runs low or a pack is missing.
- Separate recipe parameters from protected engineering settings and record authorised changes.
- Define each inter-machine signal, owner, safe state, timing and acceptance test.
- Choose production and diagnostic data that supports a real decision or investigation.
- Control remote access, accounts, backups, updates, retention and network responsibility with the site’s IT and engineering teams.
Write the operating-state model first
Define stopped, ready, starting, running, starved, blocked, held, faulted, emergency-stopped, cleaning and manual states as relevant. For each state, describe container movement, product dosing, valve and pump behaviour, alarms, status indication and permitted operator actions. This becomes the basis for PLC sequence, HMI wording and line integration.
A simple run signal is rarely enough for a connected line. The filler may need to finish a dose before stopping, preserve container tracking, inhibit release or reject an interrupted pack. Use the line integration guide to define these state transitions with retained equipment.
| Controls topic | Define in the requirement | Acceptance evidence |
|---|---|---|
| Recipes | Named products/formats, editable values, limits, access level and change record. | Recall, compare and run representative recipes without hidden engineering changes. |
| Line signals | Signal name, direction, meaning, safe state, timing, owner and physical/network interface. | Blocked, starved, fault and recovery tests with connected equipment. |
| Container tracking | Identity or position method, interrupted-pack rule and reject confirmation. | Known outcome for packs inside the line during stops and faults. |
| Alarms and diagnostics | Cause, location, operator instruction, history and escalation. | Fault simulation and evidence that the displayed action is correct. |
| Production data | Count definition, good/reject basis, reason codes, timestamps and retention. | Reconciliation with an observed run and agreed report. |
| Remote access | Purpose, approval, account, network path, logging, disablement and support boundary. | Controlled connection test and documented ownership. |
Create recipes that support controlled changeover
Recipes can store dose, speeds, timing, nozzle positions and format selections, but only values appropriate for the machine should be exposed. Set sensible limits and access levels. Identify which mechanical change parts must be checked before a recipe can run and how the operator confirms the correct product and pack.
Back up the approved recipe set with software and parameter versions. Record changes made during trial, FAT, commissioning and SAT. The cleaning and changeover guide helps connect recipe selection with line clearance and first-off approval.
Define data from a business question
Counts and runtime are useful only when their definitions are clear. Decide whether production counts represent dosing cycles, containers entering, good packs leaving or accepted cases. Define rejects, rework, manual removals and resets. For downtime, use a manageable reason structure that operators can apply consistently.
Diagnostic data may include alarm history, state, recipe, selected process values and maintenance counters. Retain only what supports quality, maintenance, capacity or traceability decisions. Agree timestamps, retention, export and ownership instead of collecting signals without a use.
Plan external interfaces and cybersecurity boundaries
If the machine connects to SCADA, MES, ERP, cloud services, cellular routers, cameras or remote support, define the data direction, protocol, network zone, account management, update responsibility and what happens when the connection is lost. A remote feature should not be assumed safe or supportable merely because the controller has an Ethernet port.
Use the site’s IT and operational-technology policies. Provide a controlled way to disable or authorise remote access and retain connection logs where required. Avoid publishing credentials in drawings, code or public documentation. The machine should continue in its defined safe operating mode when non-essential data services are unavailable.
Test controls with realistic failures and recovery
FAT and SAT should simulate missing containers, low product, sensor faults, upstream starvation, downstream blockage, communication loss and power interruption where they fall within scope. Check the machine state, HMI message, container outcome and restart sequence. Confirm that counters and reports reconcile with the observed run.
Use the FAT and SAT guide to link each test to an approved requirement. Changes after acceptance should follow controlled software, risk and validation processes rather than ad hoc online editing.
Controls and data requirement
- Operating states and transition rules.
- Recipe list, parameters, limits and access levels.
- Inter-machine signal and responsibility schedule.
- Container tracking, reject and recovery rules.
- Alarm, diagnostic and maintenance information.
- Production counts, reason codes and report definitions.
- Network, remote access, accounts and cybersecurity ownership.
- Software backups, version control and FAT/SAT tests.