Stop Reason Classification: Operator Codes, Fault Codes or Camera?

Key takeaways

• Use all three, each where it is strong: fault codes for clear faults, the operator for the why, the camera where the signal is blind.
• A fault code says what the machine saw, not why. Map the clear ones and leave the rest to people.
• Keep 10 to 20 codes per line. More than 30 makes picking unreliable.
• Set two numbers: a minimum stop length and a short-stop threshold.
• A camera suggests, the operator confirms in one tap, and the clip stays as evidence.

By the numbers

• Large plants suffer an average of 25 unplanned downtime incidents a month, down from 42 in 2019. (Siemens, 2024)
• 79% of CPG and contract packager respondents name process related issues among their top three causes of downtime. (PMMI, 2026)
• Getting production running again after an unplanned stop takes 81 minutes on average, up from 49 minutes five years earlier. (Siemens, 2024)

Most lines need all three methods, each on the stops it handles well. Map clear machine fault codes to reasons. Let the operator give the why from a short list. Add camera suggestions where no signal or person sees the stop.

Fabrico is a computer vision enabled Manufacturing Performance Platform. Its OEE (overall equipment effectiveness) and light MES (manufacturing execution system) software logs stops automatically. It prices each loss in money and shows OEE live by line and shift.

What are the three ways to classify a stop reason?

The time of a stop is the easy part. The reason comes from one of three places:

• Operator codes: the operator picks a reason from a list on the line screen.
• Machine fault codes: the PLC (programmable logic controller) reports a fault number, mapped once to a reason.
• Camera suggestions: a camera suggests a likely reason from the scene; the operator confirms it in one tap.

A code like "label sensor fault" is a fact about the machine. It does not say whether the sensor failed, got dirty or saw a crooked bottle.

The OPC UA for Machinery standard helps a little. OutOfService means the machine cannot work, for example because of an error. NotExecuting means it is fine but waiting, for material, a changeover or an order. That tells you who owns the stop, not what to fix. New to controllers? Read what a PLC does in manufacturing.

How many stop reason codes should a line have?

Aim for 10 to 20 codes per line. More than 30 makes operator selection unreliable, and "Other" grows.

• Start from the six big losses: breakdowns and setup hit availability, minor stops and slow running hit performance, defects and reduced yield hit quality. Split each into 2 to 5 codes.
• Name what the operator can see, such as "film break" or "no cases", not a root cause.
• Fix each code's OEE bucket in the configuration, not in the operator's head.
• Test the list: give three operators the same five stops and rewrite any pair of codes they confuse.

Our guide to unclassified downtime shows the daily review that keeps "Other" small.

What minimum stop length and short-stop threshold should you set?

No standard sets either number, so your plant decides with the people who run the line.

• Minimum stop length: the shortest pause that counts as a stop. A common rule flags a cycle 1.5 to 2 times longer than the ideal cycle. Shorter pauses are slow running.
• Short-stop threshold: stops below it are counted as short stops, with no question. Stops above it get a reason. Two minutes is a common example.

A minor stop is typically a minute or two. The threshold decides where those minutes land: below it in performance, above it in availability. OEE stays the same; the diagnosis changes.

Do not drop short stops. Our guide to micro stops shows how to find the station behind them.

How do you combine operator codes, fault codes and camera suggestions on one line?

Give each stop one source for its reason, in a fixed order:

1. A clear fault code first. If it maps to one reason, such as "glue temperature low", nobody is asked.
2. A camera suggestion next, at stations the camera covers. The operator confirms or changes it in one tap.
3. An operator code for the rest, picked from the short list right after the restart.
4. Short stops by rule: counted below the threshold, with no question.
5. A daily review of what is still "Other" or unconfirmed.

Put cameras where the signal is blind: manual stations, conveyors that can run empty and machines with no PLC. For the camera setup, see how to connect line cameras to MES downtime codes.

How much "Other" does each method remove? A worked example

Sample line (illustrative numbers, not a customer). A snack bagging line runs 10 shifts in a week at 120 bags a minute. The short-stop threshold is 2 minutes, and the list has 16 codes.

In the week, 90 stops last 2 minutes or longer: 540 minutes. Another 210 short stops, 170 minutes, are counted by rule and left out of the table. Here is the same week handled three ways:

Method note: Sample line, illustrative numbers, not a customer. Every result above comes from the inputs listed and the formula shown with it, so you can repeat the calculation with your own line's numbers.

• Setup 1: 162 / 540 = 30.0% of stop minutes have no usable reason.
• Setup 2: 180 minutes now take their reason from a fault code: 126 minutes operators had coded and 54 that had been "Other". "Other" falls to 108 minutes, or 20.0%.
• Setup 3: cameras over the infeed conveyor and the manual case packing table cover stops no signal or person saw. Confirmed suggestions take 81 minutes out of "Other", leaving 27, or 5.0%.

The largest new reason is the infeed conveyor running empty: 48 of the 81 minutes. At a sample margin of $0.15 a bag (€0.15 in a euro plant), that is 48 x 120 x $0.15 = $864 a week.

That loss used to hide inside "Other". The last 27 minutes go to the daily review; a cause that keeps coming back becomes a new code.

Which stop reason method should you start with?

Start with what you have. If the machines have PLCs, map the clear fault codes first: it costs no operator time. Then cut the operator list to 10 to 20 codes. Add a camera last, where "Other" stays high.

In Fabrico, a machine connects through a PLC, a Fabrico IoT device or an AI camera, and the machine itself needs no PLC. The operator confirms the reason in one tap, and a camera clip can serve as evidence. Fabrico starts with a pilot on one line.

See the three sources on one timeline on the computer vision OEE feature page. Read how a camera feeds each loss in computer vision OEE. There is no free plan and there are no tiers: each plant gets a quote.

Proof from a named plant: ABB reports 20% less downtime with Fabrico. Read the ABB case.

Toyota describes the andon in plain words: when equipment stops, it "lights up to notify workers of the abnormality." (Toyota, Toyota Production System)

Frequently asked questions

What is a stop reason code?

A stop reason code is a short label for why a line stopped, such as "film break" or "no cases". Each code belongs to one OEE loss bucket, so its minutes land in availability, performance or quality the same way each time.

Can PLC fault codes replace operator input?

For clear faults, yes: a code that maps to one reason needs no question. For the rest, no. A fault code says what the machine saw, not why. Many stops, such as waiting for material, carry no fault code at all. Keep the operator for those.

Why do operators pick "Other" so often?

Usually because the list is too long, the question comes too late, or the right code is missing. It is rarely laziness. Shorten the list, ask right after the restart, read the "Other" free text each month and turn the common answers into new codes.

Does a camera need a reason list of its own?

No. It should suggest reasons from the same list the operators use. Then a confirmed camera reason and a typed one land in the same Pareto column. Give the camera stations a few codes a clip can show, such as infeed jam or starved conveyor.