KORA Productivity: OEE per shift without manual intervention by the line supervisor

The shift OEE that the line supervisor fills in by hand at 11:40 p.m., before clocking out, is fiction. It rounds stoppages, forgets micro-stoppages, and "quality" is always 100% because nobody counts the rework that has already left the line. Anyone who read the previous articles knows why OEE matters and what to measure. What is missing is the operational level: how the number appears in the shift's Digital Twin without anyone writing it down. In this article, that is resolved in technical detail — from signal acquisition to automatic shift close.

The non-obvious thesis first: the greatest enemy of a reliable OEE is neither the inaccessible PLC nor the old machine. It is the operator who fills it in. Any system that depends on someone confirming "the line stopped at 2:12 p.m. due to a breakdown" will inherit that person's bias — and the bias is always upwards. The right architecture removes the human hand from the measurement of availability and performance, and leaves the human only to classify the cause of the stoppage, never its existence.

There is a second, more political, reason to separate measurement from coding. In a garment factory near Famalicão with 90 sewing machinists and three shifts, the OEE number always ends up in the conversation about the productivity bonus. The moment the operator realises that what they write affects what they earn, the shift sheet stops being a measurement instrument and becomes a negotiation instrument. The only defence is to take the pen away from the factor they have an interest in distorting. Leave them the cause classification — that one actually helps, because nobody knows the machine better than whoever operates it eight hours a day.

1. Recommended architecture

The non-negotiable rule: the detection of machine state (running / stopped) must be automatic; the coding of the cause can be semi-manual. Separating these two things is the most important architectural decision in the whole project. Everything else — the broker, the terminal, the dashboard — is a consequence of this choice. Anyone who inverts it, leaving detection to the person and automating only the report, builds an expensive system to produce fiction faster.

Before designing layers, it is worth looking at the real installed base. In Portugal, a relevant share of industrial SMEs still has no real-time data capture on the shop floor at all. What exists, in most cases, is a financial and sales ERP and a spreadsheet that someone fills in at the end of the month. The distance between that starting point and a reliable OEE is not bridged with one big project all at once — it is bridged in layers, each one delivering standalone value.

The three layers

• Acquisition — digital sensor on the machine's cycle signal, or direct PLC reading via OPC-UA. Where there is no accessible PLC (many garment and cutting machines in the Vale do Ave are 20 years old), an inductive sensor on the shaft or a clamp ammeter on the motor solve 80% of cases.
• Edge — local concentrator that aggregates signals, timestamps, detects state transitions and publishes via MQTT to the broker. This is where the logic of "stopped for more than N seconds = micro-stoppage" lives.
• Application — KORA Productivity consumes the events, calculates OEE in real time, displays it on the industrial terminals and closes the shift. The connection to the MULTI ERP brings in the work order, the item, the target quantity and the theoretical cycle time.

If OEE needs the line supervisor to exist, it is not an indicator — it is an opinion with decimals.

Why the edge layer is not optional

The temptation to save on the local concentrator — read the signal and send everything to the cloud or to the central server — comes up in almost every kick-off meeting. Resist it. The edge layer does three things that the central application cannot do with the same reliability: it timestamps at the exact instant of the transition, it applies the micro-stoppage logic without depending on network latency, and it keeps working when the connection to the server drops.

That last point is decisive in a typical Portuguese factory. The industrial network was not designed by anyone — it grew. A switch here, a cable there, Wi-Fi where no cable reached. When the warehouse Wi-Fi gets overloaded at 3 p.m., the connection wobbles. If state detection lived on the central server, each wobble would produce gaps in the timeline that would later be interpreted as phantom stoppages. With the edge buffering locally, the wobble is lost along the way but the data stays intact — the concentrator resends when the connection returns, without losing a single transition.

Timestamp at source, not on arrival

The timestamp is done at the edge, at the moment of the transition, never when the message reaches the application. In an industrial network with jitter, the difference between timestamping at source and timestamping on arrival can be seconds — and seconds, multiplied by hundreds of micro-stoppages per shift, become minutes of phantom availability. The edge clock synchronises via NTP against an internal server.

It is worth quantifying. A sewing line with frequent part changes easily accumulates 200 to 400 micro-events per shift. If each one carries a timestamp error of a second and a half because of network jitter, you are introducing between five and ten minutes of uncertainty into each shift's availability. In a calculation where the difference between 64% and 67% of OEE decides whether the line meets the cadence contracted with the parent company, five minutes of noise is no detail — it is the entire margin. Timestamping at source eliminates that source of error at the root, by design, with no need for later calibration.

One broker, not a point-to-point architecture

MQTT imposes itself for a concrete reason: it decouples producers from consumers. The edge publishes the machine's state on a topic; whoever wants to consume it — KORA Productivity, a dashboard, an audit log — subscribes to that topic without the edge needing to know it exists. When tomorrow you want to add a predictive maintenance system that also reads the stoppage events, you add a subscriber. You don't touch the edge, you don't touch the machine, you don't stop production.

The alternative — each system connecting directly to each machine — produces a tangle that nobody can maintain. In a unit with forty machines and three consumer systems, that is one hundred and twenty direct connections to manage, versus forty publishers and three subscribers on a broker. The maths is relentless and explains why the MQTT pattern with a central broker in an industrial DMZ has become the de facto consensus in Industry 4.0.

2. Parameters, metrics and thresholds

Classic OEE is the product of three factors: Availability × Performance × Quality. What distinguishes a serious implementation from a pretty dashboard is the definition of the thresholds. Without explicit thresholds, the number is indefensible in a productivity audit.

The market reference figure that matters here: unplanned stoppages cost the world's 500 largest companies around 1.4 trillion dollars a year, the equivalent of 11% of turnover — up from the 8% estimated in 2019/2020 (Siemens, 2024). Anyone who does not measure availability rigorously does not see where that money disappears.

Break down the three factors before multiplying them

Multiplying the three factors without looking at each one in isolation is the error that hollows out most OEE dashboards. An OEE of 65% can hide opposite operational realities: a line with 95% availability, 72% performance and 95% quality has a cadence problem, not a breakdown problem. Another line with 70% availability, 98% performance and 95% quality has a stoppage problem. The corrective action is completely different — and the aggregate number does not tell you which.

An aggregate OEE is an anaesthetic. Whoever decides acts on the three separate factors — never on their product.

Micro-stoppages: where the Portuguese OEE dies

On a garment line with colour and size changes all the time, the enemy is not the big breakdown — it is the sum of 40-second stoppages that nobody records. Setting the micro-stoppage threshold too high (say 2 minutes) hides that loss in the performance factor; too low (3 seconds) fills the system with trivial events. The balance point sits between 20 and 30 seconds for a sewing machine, lower for automatic cutting.

The physics of the workstation determines the threshold. A machinist who finishes a part, sets it down, picks up the next and positions it under the needle normally takes between ten and twenty seconds — that is a work cycle, not a stoppage. If the micro-stoppage threshold is below that natural handling time, the system will record each part change as a micro-event and flood the analysis with false positives. That is why the calibration has to be born of observing the workstation, with a stopwatch, not from a value copied out of a generic manual.

In automatic cutting the logic reverses. A CNC cutting table has long, predictable cycles; any stoppage of a few seconds within these is anomalous and deserves to be recorded. Here the threshold drops to five or ten seconds. The operational conclusion is that the micro-stoppage threshold is not a global factory parameter — it is a per-resource parameter, and trying to standardise it to simplify configuration is trading correctness for convenience.

Thresholds by sector: one table does not fit all

Footwear from Felgueiras and plastic injection from Marinha Grande live in incompatible production regimes. On the footwear line, the switch between models of a collection with eight hundred to twelve hundred SKU changes the cycle time with every order; setup is frequent and the recordable stoppage threshold has to distinguish the legitimate changeover from the breakdown. In injection, the cycle is stable for hours on end, but a three-second micro-stoppage can mean a cavity failing — and that directly contaminates the quality factor through scrap.

That is why the reference configuration in the table above is a starting point, never a destination. The first week of production with the system installed serves to calibrate, observing where the events accumulate and adjusting the thresholds until the number of events per shift is manageable by the operator and, at the same time, captures the real loss. That tuning week is part of the project, not an optional extra.

3. Practical configuration

The payload the edge publishes must be minimal and self-sufficient. Timestamp at source, resource identification, state and the active order. The cause stays null until the operator codes it on the terminal.

// State transition event published by the edge via MQTT
// topic: fabrica/linha03/maquina12/estado
{
  "ts": "2026-02-18T14:12:07.412Z",  // timestamp AT SOURCE, UTC
  "recurso": "MAQ-12",
  "linha": "L03",
  "estado": "PARADA",                // A_CORRER | PARADA | SETUP
  "ordem_fabrico": "OF-2026-00847",
  "causa": null,                     // filled in later on the terminal
  "duracao_prev_s": null
}

Note the choice of UTC in the timestamp. It seems an academic detail until the first daylight-saving change. Timestamping in local time produces, at the time switch, either a duplicated hour or a non-existent hour in the timeline — and the night shift of that early morning ends up with an OEE impossible to reconcile. Always timestamp in UTC at the edge and convert to local time only on display. It is free to do it right from the start and extremely expensive to fix later with data already accumulated.

On the application side, the shift and threshold definition lives in configuration, never hardcoded. A badly parameterised shift is the silent origin of 90% of the "the OEE is wrong" complaints.

# Shift and threshold configuration (illustrative)
turno_tarde:
  inicio: "14:00"
  fim:    "22:00"
  pausas:                 # planned time — does NOT count as a stoppage
{ inicio: "17:00", fim: "17:20" }
  microparagem_s: 25      # below this = performance loss
  paragem_registavel_s: 120
  pede_causa: true        # triggers coding on the terminal
  fecho_automatico: true  # closes the shift without the line supervisor's intervention

The cause coding on the terminal follows Poka-Yoke logic: a short list of causes per resource, big buttons, no keyboard. The operator does not choose whether there was a stoppage — the system already knows that — only why. It reduces friction and, more importantly, eliminates the temptation not to declare.

The industrial terminal and the real shop floor

The terminal where the operator classifies the cause has to survive the environment. In a dyeworks in the Vale do Ave there is humidity, steam and hands with chemical product; in a cutting hall there is airborne lint that clogs any fan. The screen has to be a capacitive touchscreen that works with a glove, mounted at the right height, with buttons big enough to be hit without stopping what you are doing. A slow, small or badly placed terminal is the number-one reason why cause coding all ends up in "Other".

The practical rule: if classifying a stoppage takes more than five seconds, the operator will choose the nearest button instead of the right one. The interface design is not cosmetic — it is what determines the quality of the loss information that will feed all the subsequent decisions. Big buttons, few options, instant response.

Stoppage causes: short, real, reviewed

The list of causes per resource should be born of a conversation with whoever operates the machine, not from a generic catalogue. Six to eight causes that describe what really happens at that workstation: "no thread", "needle breakage", "bobbin change", "motor breakdown", "lack of upstream parts", "model change". When the causes match the shop-floor language, the operator recognises themselves in them and classifies honestly.

The item's technical sheet is the only legitimate source of the theoretical cycle time. Everything else is the foreman defending his shift.

4. Integrations and dependencies

OEE is only worth something when the theoretical cycle time and the target quantity come from the ERP, and the good parts are reconciled against the warehouse. Without that, you fall into the error described in MES without ERP integration: islands of data that the COO pays for twice.

Reconciliation with batch-by-batch traceability closes the loop: the parts the line declared good have to match what enters the finished-goods warehouse. When it does not match, there is undeclared rework — and that is exactly where the Quality factor of OEE stops being 100%.

The theoretical cycle time is not a number, it is a process

Pulling the theoretical cycle from the ERP assumes that the item's technical sheet is correct and up to date. In many factories it is not — it was filled in years ago, never touched again, and reflects a machine or a method that no longer exists. When the OEE implementation exposes these outdated sheets, a productive tension is created: performance appears systematically above 100%, an unmistakable sign that the theoretical cycle is slower than reality.

That discovery is one of the most valuable collateral benefits of the project. Forcing the review of the item's technical sheets improves costing, improves planning and improves quoting to customers. The integration between KORA Productivity and MULTI ERP is not just a data channel — it is the mechanism that makes visible the divergence between what the factory thinks it does and what it actually does.

Multi-plant: when the active work order has to travel in real time

In a group with several units — the parent company in Guimarães, the subcontracting in Barcelos, the finishing in Vizela — the active work order moves from workstation to workstation several times a day. If a machine's terminal does not know in real time which work order is running, it attributes production to the wrong order and the OEE per item becomes fiction. MULTI Connect ensures the active work order is pushed to each resource the instant it is launched, keeping consistency between central planning and the reading of the distributed shop floor.

From event to BI: closing the decision loop

KORA Productivity calculates and shows OEE in real time on the terminal, but the management decision lives in the history. It is in Qlik Sense that the industrial director compares the morning shift's OEE with the night's, item A with item B, resource 12 with resource 15. Without that analysable history, real-time OEE serves the operator but does not serve the strategy. The bridge between the two levels — operational and decision-making — is what separates a data-capture project from a productivity-improvement project.

Security and network segregation

The OT network (shop floor) does not talk directly to the IT network. The MQTT broker sits in an industrial DMZ, with TLS, and remote access for maintenance goes through a VPN. This is not excessive zeal: the NIS2 Directive (EU Directive 2022/2555), transposed into national law, has extended cybersecurity obligations to many medium-sized industrial companies that previously did not even consider themselves a target. ISO 27001 as a baseline for information security management has ceased to be a multinational's luxury.

The point many industrial directors underestimate: connecting machines to the network to capture OEE increases the attack surface. A production line stopped by ransomware costs far more than the availability loss that OEE measures. OT/IT segregation, TLS on the broker and controlled remote access are not audit bureaucracy — they are the condition for the digitalisation project not to turn into the entry point for an incident. ENISA has been documenting the consistent growth of attacks directed at industrial environments, and the national transposition of NIS2 places responsibility for this segregation directly on management.

5. Operational pitfalls

What separates a project that delivers from one that rots in permanent pilot is these details. All seen in production, all anonymised.

• Planned break counted as a stoppage. The shift has a 20-minute break; if you do not declare it as planned time, the OEE drops artificially and the line loses faith in the number within the first week. Parameterise the breaks in the shift, as in the snippet above.
• "Optimistic" theoretical cycle time coming from the line. When the theoretical cycle is whatever the foreman thinks, the performance factor sits near 100% and hides the real loss. Always pull it from the item's technical sheet in the ERP.
• Unsynchronised clocks between edges. Two concentrators with a 4-second drift produce overlaps and gaps in the timeline. Internal NTP mandatory, audited weekly.
• Cycle signal that counts twice. A badly positioned inductive sensor fires on both the advance and the return of the shaft — double counting, OEE above 100%. Debounce on the edge and validation against warehouse reconciliation.
• Cause coding the operator dispatches in a single button. If "Other" is the most-used cause, the loss analysis is useless. Limit the list to 6–8 real causes per resource and review monthly which ones the operator avoids.
• Shift close dependent on the line supervisor. The fecho_automatico exists for a reason: at 11:40 p.m. the number written by hand is the number that suits. Automate the close and force the coding of stoppages during the shift, not at the end.
• Item change not reflected in the theoretical cycle. On a multi-reference footwear line with 800+ SKU, changing model changes the cycle. If the active work order does not follow, the performance becomes absurd. The MULTI Connect integration has to push the active work order in real time.
• Setup not distinguished from a stoppage. A quick changeover (SMED) is value work, not a breakdown. Treat the SETUP state separately, otherwise you penalise whoever does the changeover well.

If the most frequent stoppage cause is "Other", you do not have a machine problem — you have a trust problem with the system.

The eternal pilot pitfall

The most expensive pitfall of all does not appear in the list above because it is not technical — it is project management. The pilot that runs well on two lines and never scales to the remaining twenty is the fate of a significant percentage of OEE projects. The causes are known: nobody was assigned clear responsibility for the expansion, the return of the two pilot lines was not measured in a way that justified the next investment, or the initial enthusiasm ran into the resistance of the lines that did not take part in the pilot.

The defence is to define, from the outset, the pilot's success criterion in measurable terms and the expansion decision date. "If within eight weeks the measured OEE is within three points of the warehouse reconciliation, we expand to the entire hall." Without that criterion and that date, the pilot becomes a comfortable permanent state — it measures something, nobody commits to more, and the investment in sensors for the other lines stays frozen forever.

The resistance of the warehouse manager and the foreman

Any rollout that touches the shop floor's rhythm meets predictable resistance. The warehouse manager in the Lousada/Paços corridor will not let go of the radio for more than two hours for training, and he is right — the operation does not stop just because there is a new project. The foreman who used to fill in the OEE by hand loses, with automation, a margin of manoeuvre that was useful to him. Ignoring this internal politics is the surest way to guarantee that the system is technically perfect and operationally sabotaged.

The approach that works recognises the competence of whoever is already there. The foreman with fifteen years of knowledge of that line is the best ally for calibrating thresholds and designing the list of causes — if involved as an expert and not imposed upon as a target of control. The OEE number is not a weapon against him; it is an instrument that takes off his shoulders the tedious task of filling in sheets and gives him arguments to request the maintenance or the feeding that he always knew were needed.

6. Final technical decision

No hedging. The right architecture depends on size and machine base, not on the software budget.

The cross-cutting golden rule: start with automatic state detection and only then sophisticate the cause coding. An implementation that measures real availability on six lines is worth more than a complete Digital Twin that never leaves the pilot. And do not wait for the perfect PLC — the 40-euro inductive sensor solves the essentials while the investment in APS and fine planning matures.

Phasing by return, not by ambition

The implementation sequence that delivers results early has a return logic, not a completeness one. First phase: automatic state detection and calculation of availability and performance on the most critical lines — the bottleneck ones or the ones that serve the most demanding customer. This phase delivers, on its own, visibility over where capacity is lost, and pays for itself quickly.

Second phase: cause coding with Poka-Yoke and integration of the ERP's theoretical cycle, to turn that visibility into actionable loss analysis. Third phase: quality reconciliation with the warehouse and history in BI, closing the OEE triangle. Only then, and only if the complexity justifies it, does it make sense to move on to fine-planning orchestration with APS. Inverting this order — starting with the ambition of the complete Digital Twin — is the recipe for the eternal pilot described above.

Where funding helps and where it gets in the way

The PT2030, PRR, COMPETE 2030 and Norte 2030 instruments fund investment in industrial digitalisation, and an OEE capture project fits the Industry 4.0 typologies these programmes support. The risk is not in eligibility — it is in the calendar. A project designed to the pace of the incentive tends to buy too many sensors, to cover lines all at once to maximise eligible expenditure, and then to run into the real absorption capacity of the shop floor. The technical report ends up looking good, the execution ends up hostage to the reporting deadline.

The discipline we recommend: design the phasing by operational return and fit the funding into that phasing, never the other way round. A well-used incentive accelerates a plan that already made sense; a badly-used incentive funds a plan the factory cannot digest.

National context that makes this urgent: in 2025, only 53.7% of companies in Portugal used an ERP and 45% did data analysis (INE, 2025). Real-time data capture on the shop floor is still the exception — and with productivity per hour worked at around 67% of the EU average (Eurostat, 2022), every point of OEE recovered counts. In a sector such as textiles and clothing, worth around 11% of GVA and 20% of manufacturing employment (ATP), with two-thirds of production destined for export, the difference between measuring and guessing the OEE is the difference between meeting or missing the delivery to the parent company.

What the parent company now demands

The pressure that accelerates these projects rarely arises inside the factory — it comes from outside, from the customer who subcontracts. The international parent companies that place production in the north of the country have stopped asking only for price and deadline; they ask for traceability, production data and, increasingly, proof of compliance with the criteria of the EU Strategy for Sustainable and Circular Textiles. The factory that measures its OEE rigorously has, for free, much of the data infrastructure these demands require — batch traceability, production times, history by item. The one that guesses the OEE will have to build all that in a hurry when the buyer asks, usually with the order already on the table and the deadline running.

7. How INFOS implements

We implement KORA Productivity from what the factory has, not from what we would like it to have: a cycle signal from a sensor where the PLC is dumb, OPC-UA where the base is modern, an edge with timestamping at source and MQTT publishing. We connect to the MULTI ERP so that the theoretical cycle and the work order come from the right source, we reconcile counts with the warehouse and we take the history to Qlik Sense for analysis by shift, item and resource. The line supervisor stops filling in the OEE — they start reading it. And the industrial costing decision finally gains a denominator it can trust.

The working method reflects thirty-five years implementing software in Portuguese industry: we start with a technical assessment of the machine base and the network, we design a proof of concept on one or two representative lines, and only after the reconciliation matches the warehouse do we propose the expansion. We involve the foreman and the line supervisor from day one — not as targets of the system, but as owners of the knowledge that calibrates it. That is how an OEE project stops being a dashboard nobody consults and becomes the number on which the factory bases shift, maintenance and costing decisions.

Sources

• Siemens, True Cost of Downtime 2024 — estimate of the cost of unplanned stoppages at the world's 500 largest companies.
• INE — Statistics Portugal, Information and Knowledge Society — Survey on ICT Use in Enterprises, 2025 (ERP use and data analysis).
• Eurostat — Labour productivity per hour worked, 2022.
• ATP — Portuguese Textile and Clothing Association — the sector's weight in GVA, in industrial employment and in exports.
• Directive (EU) 2022/2555 (NIS2) — cybersecurity requirements for essential and important entities.
• ENISA — European Union Agency for Cybersecurity — threat trends in industrial environments.
• ISO/IEC 27001 — information security management system.

Frequently asked questions

What is the shift OEE that the line supervisor fills in manually?

It is the manual record of availability, performance and quality that the line supervisor completes before leaving, usually at 11:40 p.m. The article considers it "fiction" because it rounds stoppages, forgets micro-stoppages and ignores rework that has already left the line, always introducing an upward bias into the numbers.

What is the biggest problem with an OEE that depends on the operator?

Human bias. When the operator realises that the numbers they write affect their productivity bonus, the shift sheet stops being a measurement instrument and becomes a negotiation instrument. The operator has an interest in distorting the data that works against them.

How is measurement separated from coding in the KORA system?

The automatic detection of machine state (running or stopped) is done by sensors and PLC, never manually. The coding of the stoppage cause can be semi-manual, leaving the operator only to classify the reason, not its existence. This removes the bias from the measurement.

What are the three layers of the recommended architecture?

Acquisition: a sensor or PLC reading that captures the cycle signal. Edge: a local concentrator that aggregates signals, timestamps and detects state transitions. Application: KORA Productivity which consumes events, calculates OEE in real time and closes the shift automatically.

Why is the edge layer not optional?

The edge timestamps at the exact instant of the transition, applies micro-stoppage logic without depending on network latency, and keeps working when the connection to the server drops. In a factory with an unstable industrial network, the edge buffers data locally and resends when the connection returns, avoiding phantom stoppages.

What is the difference between timestamping at source or on arrival?

Timestamping at source (on the edge, at the moment of the transition) eliminates errors caused by network jitter. On a line with 200 to 400 micro-events per shift, timestamp errors on arrival can introduce five to ten minutes of uncertainty into availability, affecting critical decisions about meeting cadence.

Why is MQTT better than a point-to-point architecture?

MQTT decouples producers from consumers. The edge publishes events on a topic; any system (KORA, dashboard, predictive maintenance) subscribes without the edge needing to know it exists. It allows new systems to be added without touching the machine or stopping production.