Industry 4.0 and Industry 5.0 on the Shop Floor: What Actually Changes

This page is written the other way round: from the machines and the operators outward.

What Industry 4.0 actually means on a shop floor

Strip the vocabulary away and Industry 4.0 is one shift: from machines that report nothing to machines whose data drives a decision.

Take a press that stops. In a plant without that shift, the stop is written on a shift sheet, keyed into a spreadsheet the next morning, and aggregated into a monthly report as a block of "downtime" with no cause attached. By then the supervisor who knew what happened has forgotten. The number is true and useless.

In a plant that has made the shift, the stop is detected from the PLC within seconds, the operator classifies the reason at the machine while the cause is still visible, the planning system sees the operation will not finish inside its window, and the next order is re-sequenced or the material held back. The same event now has a consequence.

The difference is not the sensor. Most factories already generate far more data than they use; counters, drives and PLCs have been producing signals for years. The difference is the closed loop: data captured at the moment and place of the event, given context, held in a system of record, and consumed by something that acts on it.

Digitisation is not the same thing either: replacing a paper work order with a PDF removes the printer, not the delay. Industry 4.0 starts when data is structured, timestamped and tied to an order, a machine, a tool and an operator — because only then can anything downstream compute with it.

The layers, and where each one sits

Most confusion about Industry 4.0 comes from arguing across layers. ISA-95 gives a usable vocabulary for keeping them apart.

Machine signals — sensors, PLCs, gateways. In a real plant this layer is mixed. Some machines speak OPC UA; older ones speak Modbus, a serial protocol, or a dry contact and nothing else. Closed controllers the vendor will not open need a retrofit sensor on the spindle, the hydraulic circuit or the power line. Expect no single protocol, and budget for the stubborn minority of assets that need external instrumentation. IIoT gateways sit here, and so does RTLS, where you need to know where a trolley, a mould or a batch physically is rather than where the paperwork says it is.

Data capture and context. A raw signal is not information. A counter reading becomes information only when you know which order the parts belong to, which tool made them, who was running the cell and which shift it was. This layer quietly decides whether everything above it works: if context is attached by hand at the end of the shift, everything above it inherits that uncertainty.

MES — execution. This is where the floor is actually run: dispatching orders to cells, confirming operations, recording machine and labour time, capturing scrap and rework with reasons, enforcing routing and setup, and holding the traceability that lets a batch be walked backwards. Quality checks (QMS), maintenance triggers (CMMS) and material movements (WMS) hang off the same event stream. MES is the system of record for what happened on the floor. Analytics can be rebuilt later; the record cannot.

Planning — MRP, APS, SCP. MRP and ERP answer what to make and roughly when, at a resolution of days. APS sequences against finite capacity and the constraints that actually bind: shared tooling, changeover families, qualified operators, drying or curing times. SCP looks further out, across suppliers and sites. Planning quality is capped by execution feedback — a finite-capacity plan built on standard times nobody has re-measured in years will be re-planned by hand within a day.

Analytics, AI/ML and computer vision. This sits on top and is worth very little without the layers below it. With them, it is where a lot of the value is: computer vision for surface defects, presence-and-absence checks and label verification, where a camera is more consistent than an eye at the end of a long shift; AI/ML for anomaly detection in vibration or energy signatures. Energy monitoring belongs here too, and becomes useful when consumption is tied to production output rather than to a meter reading, so energy per part is comparable across shifts and machines.

ERP integration. Strictly this is not a layer but a seam, between execution and the business systems. Orders, BOMs, routings, material masters and confirmations cross it in both directions. It absorbs a large share of project time and is the part most often scoped last.

What Industry 5.0 adds, and what you cannot buy

Industry 5.0 did not come from a vendor roadmap. It came out of European Commission policy work, and reads better as a correction than a successor. Industry 4.0 asked how much can be connected and automated. Industry 5.0 asks what the human's role is in the automated plant (human-centricity), how the plant behaves when supply, demand or energy prices move sharply (resilience), and what production costs in energy and material rather than only in money (sustainability).

This matters because "Industry 5.0" is starting to appear on product pages. You cannot buy Industry 5.0. You can buy things that serve its goals, and it is fair to ask any vendor which of these they actually mean:

Operator interfaces designed around the person doing the job rather than the database schema — few steps, at the machine, giving something useful back in return for what is entered.

Energy measured per order and per machine, so a process change can be judged on consumption as well as cycle time.

Planning that can be re-run against a changed constraint — a lost supplier, a down line, a pulled-in delivery date — fast enough to be used in the meeting where the decision is made.

Traceability good enough to support a targeted recall rather than a whole-batch write-off.

Human-centricity is the part most often skipped, and it is the part that decides adoption. A system that treats the operator as a data-entry device gets worked around within a month.

Where to start, and how not to buy a platform that sits unused

Sequencing is the real question. A workable order:

Start from a constraint, not a technology. Name the bottleneck cell, the line with the most unexplained downtime, or the product family with the worst scrap. If the project cannot be stated as "we do not know X about Y, and not knowing it costs us Z", it is not ready.

Get ground truth before insight. Machine state and stop reasons, captured automatically where possible and classified by the operator where not. Almost every later capability depends on this.

Run execution before analytics. MES and the shop-floor record come before dashboards and models. A model trained on data retyped from a shift sheet will learn the shift sheet.

Scope the ERP seam at the beginning. Decide who owns the material master, how work order numbering works on both sides, which system is authoritative for BOM changes, and what happens when the two disagree. Leaving this until after the pilot is the most common cause of a stalled rollout.

Choose a pilot designed to scale. One line, but one whose machine types and product flow resemble the rest of the plant — with written exit criteria and a named rollout owner agreed before it starts.

Modularity is the practical defence against shelfware: a platform you switch on one module at a time costs less to abandon if you are wrong, and is easier to fund in stages.

What goes wrong

Data nobody trusts. Two systems report different numbers for the same shift, and the production meeting becomes an argument about the number instead of the loss behind it. The fix is unglamorous: before rollout, in writing, agree one definition of each KPI — including how OEE treats planned downtime and rework — and name one system of record.

Operators work around the system. The terminal is far from the machine, the confirmation takes more steps than the task it records, and nothing comes back to the person entering it. If the fastest way to finish the shift is to backfill everything at the end, that is what happens, and the timestamps become fiction. Time the entry steps yourself, during a real changeover.

A pilot that never leaves one line. Pilots get funded by curiosity; rollouts need a budget, an owner and floor time. Without exit criteria written in advance, a successful pilot becomes a permanent demonstration.

Integration scoped as an afterthought. Units of measure that do not match, part numbers differing by a suffix, a BOM maintained in two places. None of it is difficult, and all of it takes longer than the software.

A platform bought for a problem nobody named. If the business case is "we need to be Industry 4.0", the system gets installed, demonstrated, and slowly stops being opened.

Telling a real project from a dashboard project

Dashboards are fine. They are the visible part, and if they are the whole thing you have bought a mirror. Six questions separate the two:

1. Does any number cause an action, or does it only cause a human to notice something? 2. Is data captured at the moment and place of the event, or retyped later from notes? 3. When the floor changes, does the plan change — or does it stay as printed while reality diverges? 4. Is there a system of record for what happened, or only a view over other systems? 5. Would it survive the person who built it leaving? A dependency on one maintained spreadsheet is a warning. 6. What happens when the network drops for an hour — does the edge buffer and reconcile, or is the shift lost?

If the honest answers are "notice", "retyped", "stays as printed" and "only a view", the project is reporting. Reporting is useful. It is not the shift described at the top of this page.

Where Meta Smart Factory fits

Meta Smart Factory is a modular platform covering the layers above: MES, APS and MRP, SCP, WMS and Logistics, Quality (QMS), Maintenance (CMMS), Computer Vision, AI/ML, Energy, IIoT hardware, RTLS and ERP integration — deployed on-premise or as SaaS.

The reason to name the modules is the sequencing argument above: you can start with one of them against one named constraint — machine data capture on a bottleneck cell, or quality at the operation where scrap concentrates — and add the next once the first is genuinely being used, rather than committing to a full stack before anyone has entered a single stop reason.

Nothing in the platform removes the parts that are actually hard: agreeing what the numbers mean, cleaning master data, and designing entry steps operators will perform without being asked twice. Those are shared work, and talking through the sequencing for a specific plant is a more useful first conversation than a product demonstration.