Recipe management and OEE reporting on a filling and packaging line

Starting point

The line ran with filling, capping, labelling and case-packing units and was mechanically sound. The problems showed up at changeovers and in reporting.

At a product change, every unit’s settings were entered by hand: fill volume, conveyor speed, label position, temperature threshold. Some units took those values from an HMI, others from a physical potentiometer, and the correct values lived in one operator’s notebook. The result: changeover time depended on who was on shift, and the first cases went to scrap because the settings had not settled yet.

On the reporting side, the count produced per shift was known but the cause of downtime was not. There was a record saying “the line stopped for 40 minutes”; whether those 40 minutes came from running out of labels, a jammed cap or waiting on raw material was recorded nowhere. With no cause, improvement work had no target.

Batch traceability was on paper: which raw material lot went onto which pallets was written on a hand-kept form.

The system built

Recipe management. All setpoints for all units were collected into a single recipe record per product. The operator selects the product and the control system distributes the values to the units. Manual adjustment was not removed entirely — a deliberate decision, because some settings genuinely need correction depending on the raw material lot. But every manual change is now recorded with who made it and from which value to which, and it does not touch the recipe itself. Changing a recipe is a separate, authorised action, and every recipe is versioned; without versioning, the settings a past batch was produced with are simply lost.

Batch traceability. The raw material lot is declared at the head of the line, and the production time of every pack leaving the line is linked to it. That answers both directions: from a lot forwards, “which pallets did it go into”, and from a pallet backwards, “which lot did this come from”. In food production the recall scenario alone justifies the capability.

Downtime classification. When the line stops, the control system opens a downtime event automatically and assigns the cause itself where it can (derived from the triggering alarm). Where it cannot, the operator is asked to pick a reason; the list is short and drawn from the line’s real fault vocabulary. A long reason list just means the operator picks the first item every time.

Reporting. The shift report gives the three OEE components separately: availability, performance and quality. A single OEE percentage on its own is not actionable — a number that dropped cannot be read without knowing which component it came from. The report also ranks downtime events by duration, so the most expensive stoppage cause of the week becomes visible.

The hard part

The hardest part was not technical: it was defining when downtime starts. Is a unit waiting 8 seconds with product on the conveyor a stoppage, or a normal part of the cycle? Set the threshold too short and the report fills with hundreds of meaningless micro-stops; too long and the real loss disappears.

We solved it with per-unit thresholds and two categories: waits below the threshold are not counted as downtime but are booked against the performance component of OEE; waits above it become classified downtime events. The thresholds were not guessed — we collected raw wait durations for two weeks and set them from the observed distribution.

The second difficulty was the older units. Some of them only offered dry contact signals and would not accept a setpoint over a network. Communication modules were added to some; for the rest, the honest solution was this: the recipe sends no value to that unit and instead tells the operator on the HMI which setting to make by hand, then asks for confirmation. In the record, the setting appears as “manually confirmed”. Logging a step that is not automated as if it were would devalue the whole traceability chain.

Measurement and acceptance

Acceptance started with definitions: planned versus unplanned downtime, ideal cycle time, and where quality loss is counted. That is the only real precondition for comparing OEE figures; change a definition and the number changes with it, so what looks like an improvement is actually a definition difference.

Then two measurements were taken: a two-week baseline of the existing situation (with the new system only recording, not intervening in the line), and a second measurement after commissioning with the same method. Changeover time was timed by stopwatch, over the same product pairs and on the same shifts.

FAT tested recipe distribution and downtime classification against simulated signals; SAT ran through a full shift of real production, and the report output was compared against the hand-kept records. How the control layer is built is described on the industrial automation page, and the reporting layer on the data acquisition and analytics page.