The phases of factory digitisation: how a manufacturing plant moves from connected sensors to adaptive control

The idea that factories are analogue is thirty years out of date. Almost every plant is already computerised — the PLCs are modern, the drives are digital, the CNC machines have controllers with more compute than the site's first ERP server. What is missing at phase 1 is not computation but egress. A PLC holds the truth for a few milliseconds and then overwrites it, and unless something is deliberately taking a copy, that truth is gone. This is why acatech treats computerisation and connectivity as two separate development stages: having a computer on the machine and having its data leave the machine are unrelated achievements.

The work here is unglamorous and physical. Somebody has to walk the asset register with the maintenance planner and decide, per machine, how the data gets out: a spare PLC word read over Ethernet/IP, an OPC UA server that the OEM will licence, a serial bus that needs a converter, a machine with no spare port at all where the only honest answer is a non-intrusive retrofit — a current clamp on the drive, a vibration puck on the gearbox, a photo-eye counting product past a point. On assets under an OEM service contract there is a warranty conversation before there is an engineering one, and on assets in a regulated process there is a change-control conversation before either.

The cost shape is what surprises people. Phase 1 is priced per asset, not per plant, and the tenth asset costs roughly what the first one did because every asset is its own negotiation: its own protocol, its own access window, its own controls engineer. The dominant constraint is not money but planned downtime — you cannot tap a machine that is running, and on a plant at ninety per cent utilisation the queue for a two-hour access window is measured in months.

Visibility is the phase where digitisation feels like it is working and stops paying. The screens are up, the numbers refresh, the plant manager can see line 4 stopping from the office, and executives who funded the programme see exactly the artefact they were promised. What has not happened is a change in any decision. A digital shadow is a mirror: it faithfully reflects the current state and holds no model of the thing it is reflecting, so it can tell you the line is down and it cannot tell you which of eleven candidate causes stopped it.

The structural reason is naming. In a plant at phase 2 the tags are named for wiring, not for meaning — an address, a rack, a data block, a word offset — and the semantics live in the head of the controls engineer who commissioned the line. Two lines built five years apart, by two integrators, name the same physical signal differently, so any comparison across lines is a manual reconciliation. Each individual dashboard is correct; the estate is incomparable. This is why the second site's dashboard costs almost as much as the first one did, which is the moment programmes start to look expensive.

Time spent at phase 2 is not neutral. Operators learn quickly that the boards are for management, and each new screen has a lower marginal readership than the last. Meanwhile the running cost grows on its own: historian and platform licensing is usually priced by tag count, so a plant that keeps connecting assets without leaving visibility pays a rising bill against a flat benefit. Plants that sit here for three years are harder to move than plants at phase 1, because the organisation has already learned what digitisation delivers, and what it learned is screens.

Transparency — the phase this page calls contextualised — is where digitisation stops being an IT project and becomes an engineering standard. The deliverable is an asset hierarchy and a naming convention: a document, not a product. It is the least celebrated artefact in the entire programme and the highest-leverage one, because every phase above it consumes it. A forecast needs to know which asset it is forecasting, in what state, on which product. A closed loop needs to know which setpoint on which unit. Neither can be built on a tag called DB12.DBW4.

The work is negotiation rather than technology. Does the labeller belong to the filler's line or to packaging? Is the shared vacuum pump an asset of the line it usually serves, or of the utilities area? When two lines share a palletiser, whose downtime is it? Every one of these has an accounting consequence, because OEE denominators and maintenance budgets follow the hierarchy. This is exactly why anchoring to ISA-95's equipment hierarchy model is worth the effort — it supplies the vocabulary and the precedent, so the argument is about your plant rather than about first principles, and the answer survives the next MES upgrade.

The cost shape inverts here. Phases 1 and 2 scale with the number of assets; phase 3 scales with their variety. A plant with three identical lines gets contextualisation almost free once it has done one. A specialty plant with forty unique machines pays forty times, because each machine needs its own state model and its own loss vocabulary. The payoff is equally structural: the reconciliation meetings stop. When maintenance, production and quality all resolve to the same hierarchy, arguments about whose number is right are replaced by arguments about what to do, which is the argument you wanted.

Prediction is the first phase where the plant buys the future rather than the past, and the modelling is the smallest part of it. The binding question is lead time. A bearing model that gives five days of notice is worthless in a plant whose maintenance planning cycle is fourteen days and whose shutdown calendar is quarterly — not because the model is wrong, but because there is no window in which its answer changes anything. Phase 4 work therefore starts from the maintenance and scheduling calendar and works backwards to the horizon the model must hit, which frequently changes what is worth modelling at all.

Manufacturing prediction is also statistically unusual, and teams arriving from consumer machine learning are routinely caught out. Labels are rare by construction — failures are the thing you are trying to avoid, so the positive class is thin and expensive. The data-generating process is deliberately and repeatedly reset by maintenance, changeovers and recipe changes, so a naive model learns the maintenance schedule rather than the degradation. And the physics is known: for rotating equipment, thermal processes and filtration, physically informed features and a survival framing consistently outperform a generic anomaly detector pointed at raw tags. The contextualised record from phase 3 is what makes those features expressible.

The remaining constraint at phase 4 is human. Every prediction terminates in a person deciding to act, so the plant's response rate is bounded by planner and technician capacity, not by model quality. That is very often the right place to stop: for a regulated process or a safety-critical asset, phase 4 is the correct terminal state and going further would be an error. The question of whether to move to phase 5 is a risk-appetite decision made with process engineering and safety, not a technical one made by the analytics team.

Adaptability is far narrower than the brochures suggest. It is a list of setpoints, not a self-driving factory. Blend ratios inside a validated band, oven or kiln profile trims, line speed within an engineered range, replenishment triggers, energy scheduling against a tariff, buffer levels between asynchronous units — these are the decisions that qualify. Safety instrumented functions, critical process parameters under a validated pharmaceutical or food-safety regime, and anything inside a pressure-equipment or explosive-atmosphere envelope stay human, correctly and permanently. A plant with six setpoints under bounded automatic adjustment and a hard boundary around everything else is at phase 5. A plant claiming an autonomous factory usually is not.

By this point the modelling is largely solved and the binding constraints are safety and security. Any closed loop means something above the control layer writes down into it, which crosses the OT/IT boundary — Purdue level 3.5 — and a write from an enterprise-side model into control is a safety and security event before it is a feature. This is the phase where ISA/IEC 62443 zone and conduit design and NIST's operational technology security guidance stop being compliance documents and become the design. The write path needs an authenticated, logged, rate-limited conduit through the DMZ, an engineered clamp in the control logic that rejects out-of-range values regardless of what the model asked for, and a reversion that a shift supervisor can trigger without calling anyone.

Sustaining adaptability is a change-control discipline rather than an engineering one, and it is the phase most likely to regress quietly. Bounds validated against one product mix silently stop being valid when the mix changes, a feedstock supplier changes, or an asset degrades past the condition the bounds assumed. The loop keeps running and stops being right, which is worse than failing. The operational signal to watch is escalation rate: when the share of out-of-bounds decisions rises, the world has moved outside the policy's validity and the bounds need review before an incident forces one.