Skip to content
General Tech Automation
Get A Free Quote
Application example

OEE and Downtime Monitoringon a Production Line

Automatic Counting • Stop Reasons • Loss Analysis • Shift Reporting • UAE

On the line
  • Machine PLCs: read by, Edge device
  • Machines with no PLC signal: fitted with, Photocell and run contact
  • Handwritten shift note: replaced by, Stop-reason terminal
  • Machines and settings: left as they are, Nothing fitted

Every plant has a line everybody knows is underperforming, and every plant has three confident and incompatible explanations for why. Maintenance says it is the operators, operations says it is breakdowns, and planning says it is changeovers. The shift report records total output and a hand-written note about the afternoon, which is enough to sustain all three theories indefinitely.

Downtime monitoring replaces the theories with a record. The line counts itself, every stop longer than a few seconds is captured automatically, and the operator attributes a reason to it from a short list. Within a couple of weeks the losses are ranked by the hours they actually cost, and the argument is over — usually with an answer nobody had put first.

On the line

The line counts itself

Nothing inside the machines is changed. The monitoring sits alongside them and reads, taking signals from the PLC where there is one and from a sensor where there is not, and the operator adds the one thing a sensor cannot: the reason.

  • Signal
  • FMeasuring point
  • What we fit
  1. UCount and state from the PLCRun, fault and count signals the machine already produces, taken from a few terminals in the existing panel.
  2. XSRun contactEstablishes running and stopped on a machine that offers no signal, without touching its own controls.
  3. QPhotocell on the productCounts what actually leaves the line, which is what the performance figure is built from.
  4. HSStop reasonMounted where the stop happens, so the operator picks a reason from a short list in two taps.
  5. KHours lost, by reasonThe edge device times every stop, and the losses are ranked by the hours they actually cost, per shift.
How it works

From a stopped machine to a ranked list of losses

The counting is automatic; the reason is not. That division of labour is what makes the data both accurate and meaningful.

  1. Count and state from the machineAn existing PLC signal, or a photocell and a run contact where there is none
  2. Fieldbus or hardwiredEdge device on the lineDetects a stop the moment it happens and starts timing it
  3. Shop-floor terminalThe operator names the stopA short list of reasons, chosen in seconds, not a free-text box
  4. Ethernet or Wi-FiLoss analysisAvailability, performance and quality, and the top losses by hours lost
  5. Scheduled reportA shift review that has evidenceThe same numbers for every shift, produced without anyone compiling them

Keep the reason list short and written in the operators' own words. A list of forty options is a list that gets scrolled past, and the reason chosen becomes whichever one is at the top.

What it takes to instrument a line

Far less than most people expect. The machines already know almost everything the system needs.

Signals the line already produces

A run contact, a fault output and a count pulse are usually available from an existing PLC or starter, and taking them costs a few terminals. Where a machine offers nothing, a photocell on the product stream and a current sensor on the motor will establish running and counting without touching the machine's own controls at all.

A terminal the operator will actually use

Mounted where the stop happens, not in an office. Stops appear on it as they occur, unattributed ones queue up, and a reason is two taps away. If naming a stop takes longer than clearing it, the data will be attributed to whatever is quickest rather than to what happened.

Availability, performance and quality

OEE split into its three components, because the composite number on its own tells you that the line is at sixty-one per cent and nothing about what to do. The useful output is the ranked loss list underneath it: which reason, how many hours, on which shift.

4

Reporting into the routine that exists

A shift handover report and a weekly loss summary, produced automatically and formatted for the meeting that already happens. A system that requires a new meeting to be useful tends not to survive its first busy month.

How it runs

Getting numbers people believe

The technical work is straightforward. The part that decides whether it succeeds is getting the shop floor to trust what it says.

01 / 04 STAGES
  1. Agree

    Define a stop and agree the reasons

    How long a pause has to last before it counts, what the ideal cycle rate is, and the short list of reasons — written with the operators and in their language. Definitions imposed from an office produce numbers the floor disputes, and disputed numbers change nothing.

  2. Connect

    Take the signals

    Count and state from the existing controls where possible, sensors where not. Nothing is changed inside the machines; the monitoring sits alongside them and reads.

  3. Run

    Two weeks with no targets attached

    Data collected and shown to the line, with the explicit understanding that nobody is being measured yet. This is when miscounts and misattributions get found and fixed, and it is when the shop floor decides whether the system is a tool or a stick.

  4. Use

    Attack the top loss, then re-measure

    The ranked list is worked from the top, one loss at a time, and the effect is visible in the same numbers. Doing this once in public is what makes the system permanent — everybody sees a change they made move the figure.

A monitoring system introduced as a performance-management tool measures how well operators can defeat a monitoring system.

What the data settles

Which losses actually cost hours, ranked, rather than which ones are most visible or most recently complained about.

Whether the problem is breakdowns, minor stops, changeovers or speed loss — four different problems that a single output figure hides.

How the same line performs across shifts and products, which is often where the largest and least discussed variation sits.

Whether an improvement worked, measured on the same basis as before it.

A defensible baseline for capacity planning, so a decision about buying another machine starts from the real number.

Where it fits

Lines where the output is lower than it should be

Manufacturing

Assembly and process lines where the shift report has been a total and a comment for as long as anyone can remember.

Food and Beverage

High-speed packing lines that lose most of their capacity to short, frequent stops nobody logs individually because each one is trivial.

Automotive

Cells with a fixed takt time, where a small persistent loss compounds across a shift and shows up as a shortfall against plan.

Questions

Common questions about OEE monitoring

That depends entirely on how it is introduced. A system presented as a way of proving which machine keeps letting the shift down gets cooperation; one presented as a way of seeing who is slow does not, and it will produce data to match. The two-week period with no targets attached exists for exactly this reason, and skipping it is the most reliable way to make the project fail.

No. The signals are read from what the machines already produce — a run contact, a fault relay, a count pulse — or picked up by sensors mounted on the outside. Nothing is changed inside a machine's own controls, which also means no supplier warranty is affected and no machine has to be re-proved.

The composite number is often less useful than its parts, and on some lines it is actively misleading — a line deliberately run below capacity to match demand will score poorly while doing exactly what it should. The ranked downtime list is valuable on almost any line; the single OEE figure is worth reporting only where somebody will act on it.

Get in touch

Point us at the line everyone argues about, and we will let it settle the argument.

A survey of the available signals, a reason list agreed with your operators, and two weeks of data before anyone sets a target.