Production monitoring and OEE

We deploy a production monitoring system that takes its data straight from controllers and sensors, calculates OEE and shows where the machine hours went during the shift. The software and the deployment are delivered together with our manufacturing partner in Türkiye; the contract, the invoice and the project management are Polish, from a Polish company.

The problem

Production data usually exists. It just is not where it is needed, at the time it is needed. Stoppages go on a sheet of paper, the shift log reaches a spreadsheet the next day, and OEE is produced once a month — mostly as material for an argument about whether it can be trusted. A downtime reason is often a single word, "breakdown", and a week later nobody can tell whether it lasted five minutes or fifty. Scrap is counted at the end rather than at the machine that produced it.

The consequence is always the same: the conversation about throughput runs on impressions, and the investment case rests on a number nobody can defend. Before you buy another machine it is worth knowing how many hours a day the one you own stands still, and why.

How a production monitoring system works

Data collection. Machine states, piece counters and alarm signals come from Simatic S7 controllers over Profinet and OPC UA. Machines without a controller are described with signals added on site — a separate subject, covered on the machine data collection page. States are split into running, stopped, changeover and no order, because without that split every indicator can be disputed.

Calculating the indicators. OEE is the product of three factors and says something only when it is broken down into them.

Alongside OEE we report maintenance indicators: MTBF, the mean time between failures, and MTTR, the mean time to repair. The first shows how often a machine fails, the second how long it takes to get it running again; the two lead to entirely different decisions, which is why we keep them apart.

The reason, at the machine. A stop longer than an agreed threshold has to be closed with a reason. The operator picks it on the panel from a list agreed in advance with maintenance and process engineering — not from a vendor's ready-made dictionary. Where the controller supplies an alarm code, the reason is proposed automatically. An andon call sits next to it: one press notifies the mechanic, the setter or quality control, and the system measures the response time.

Reports and the bridge to plant systems. The shift ends with a report nobody has to retype: output against plan, the list of stoppages with durations and reasons, scrap, and OEE per machine, per cell and for the whole shop. What is exchanged with the ERP system — orders one way, output and scrap the other — is agreed during the pre-implementation analysis, because the boundary between the shop floor and the ERP sits in a different place in every plant.

Which plants it suits

• Food — throughput of packing and filling lines, washdown and changeovers as separate time categories, scrap counted at the machine.
• Glass — a continuous process where rate stability and the share of rejects after annealing decide the result.
• Foundries — availability of moulds and furnaces, maintenance stops planned from history, energy per tonne.
• White goods and assembly — line takt, micro-stops at stations and the response time to an andon call.
• Packaging — changeover time as the main component of availability, plus batch and run tracking.

It does not pay off for everyone. With three machines, one shift and one-off production a shift log can be enough, and the deployment only pays back once you add a shift or more machines. We say so on the first call, before we price anything.

Deployment step by step

• Definition workshop. We agree planned time, the nominal cycle of each machine, the threshold above which a stop is recorded, and the list of reasons. It is the most important day of the project: the numbers are exactly as credible as the agreement on the definitions.
• Pilot on three to five machines. Connection, verification of the counters against the machine counters and the shift log, corrections. The pilot lasts as long as it takes for the data to match what the supervisor sees.
• Agreeing the reports. We add views for the supervisor, the production manager and maintenance, and remove the ones nobody opens.
• Roll-out and training. The remaining machines, instruction for operators and supervisors in Polish, and the as-built documentation handed over.

What it costs

We publish no price list, because the cost depends on things that cannot be guessed from a desk: the number of machines and their age, the number of signals per machine, the state of the shop-floor network, the number of operator stations and boards, the scope of ERP integration, and whether you want us to run the system afterwards. The quote follows a machine survey and a technical call, and separates licences, implementation work, hardware and support. Without those lines no two offers can be compared — it is usually the first question we are asked, and the first one we answer with numbers from your plant rather than a market average.

Funding

Ready-made production software is a mandatory component of a project under the Dig.IT programme run by ARP, where the grant reaches 50% on a de minimis basis and hardware and training carry a separate share limit. The deployment is also eligible in the implementation module of Ścieżka SMART. The conditions depend on company size and plant location and the calls change, so the current state is kept on the automation and digitalisation funding page. We are not a licensed grant adviser: we check whether the scope fits the programme and work with the adviser on your side.