What Industry 4.0 Scale Actually Requires

ReadStats & TrendsInfographicBest Practices
Written By Jeff Winter

I made an Industry 4.0 graphic and somehow did not mention AI once. In 2026, that almost feels irresponsible. 😂 But it was intentional.

AI can classify defects, predict failures, optimize schedules, recommend actions, and increasingly act on its own. None of that answers the harder questions. Can the second plant connect its equipment without rebuilding the integration? Does “downtime” mean the same thing in Ohio and Germany? Who may act on a recommendation during night shift? What happens when the model, CMMS, operator, and production schedule disagree?

A pilot gets attention. Scale gets exposed to normal operations, which is where every hidden assumption comes out of hiding.

I see five layers between a promising pilot and repeatable performance: operational foundation, context, decisions, workflows, and replication. Some enabling technologies are mature. Some standards are established. Other pieces are actively being worked through by initiatives such as CESMII’s i3X and the Linux Foundation’s Margo project. The mistake is waiting for the industry to solve everything before starting, or pretending everything is already solved because the demonstration ran twice without freezing.

Operational Foundation (Layer 1): Give the Use Case Somewhere Solid to Live

The operational foundation is everything required to reliably create, move, protect, and preserve industrial data. Sensors, controllers, drives, cameras, industrial networks, wireless systems, gateways, edge computers, servers, cybersecurity controls, monitoring tools, and the people responsible for all of it belong here.

There is plenty in this layer that industry understands extremely well. We have been building reliable automation systems for decades. Industrial Ethernet is mature. Modern wireless can be extremely dependable when designed correctly. We have proven architectures for redundancy, network segmentation, remote access, protocol conversion, time synchronization, buffering, and asset monitoring. NIST SP 800-82 Revision 3 gives useful guidance specifically for OT environments, while IEC 62443 provides a substantial body of work around industrial automation and control system cybersecurity.

Where things get ugly is the actual plant you already own. Brownfield facilities accumulate infrastructure over decades. One line was installed in 1998. Another got upgraded in 2014. Someone added wireless sensors during COVID. An integrator installed a gateway during a project three years ago. Corporate cybersecurity added monitoring tools last year. Now somebody wants machine vision, edge analytics, remote service, and a historian pulling higher-resolution data.

Industrial networks deserve much more attention here than they usually get. A network designed primarily for PLC programming, HMI traffic, and basic supervisory control can behave very differently once cameras, high-frequency data collection, wireless devices, cybersecurity monitoring, mobile workers, and edge applications arrive. Before scaling anything, document the bandwidth, latency, availability, redundancy, segmentation, and recovery requirements of the use cases you expect the network to support. Then actually verify the infrastructure against those requirements.

For every data source, a few good things to define include:

  • Sampling rate and unit of measure

  • Timestamp source and synchronization method

  • Expected operating range

  • Calibration responsibility

  • Behavior during a communication interruption

  • Recovery process after device replacement

Industrial networks deserve much more attention here than they usually get. A network designed primarily for PLC programming, HMI traffic, and basic supervisory control can behave very differently once cameras, high-frequency data collection, wireless devices, cybersecurity monitoring, mobile workers, and edge applications arrive. Before scaling anything, document the bandwidth, latency, availability, redundancy, segmentation, and recovery requirements of the use cases you expect the network to support. Then actually verify the infrastructure against those requirements. NIST SP 800-82 Revision 3 is a useful guide because it treats OT security alongside the reliability, performance, and safety requirements that make factory infrastructure different from office IT.

This reminds me of a plant tour I had at aa high-speed assembly plant in Wisconsin a few years ago. A technician opened an electrical cabinet and it was just an absolute mess. Cables everywhere, several unlabeled, and an unmanaged Ethernet switch sitting in the middle of it all. He stared at it for a second and said, genuinely surprised, “I don’t remember putting that switch in there.” That is manufacturing in one sentence. Nobody wanted to touch it because five machines appeared to depend on it, which is a very effective way for a $70 piece of hardware to become mission-critical infrastructure.

So start with a physically verified asset inventory. Record manufacturer, model, firmware, protocol, network location, physical location, operational criticality, owner, backup method, and replacement procedure. For critical signals, define engineering units, expected ranges, sampling rates, timestamp sources, quality indicators, and behavior during communication loss.

And please test failure scenarios before rollout. Restart the gateway. Disconnect the network. Restore the configuration. Replace the device. Introduce clock drift. Test expired credentials. Factories are remarkably creative at discovering the one scenario nobody thought was worth testing.

Context Layer (Layer 2): Make the Data Mean the Same Thing Somewhere Else

The context layer explains what the data represents and how it relates to the operation around it. A raw value becomes genuinely useful when we can associate it with an asset, process, material, recipe, product, batch, order, operating state, location, and point in time. A temperature reading of 81.6 tells me very little. Knowing it is the discharge temperature of Dryer 2, in Celsius, while running recipe 14B for lot 73018 tells me quite a bit more.

There are already strong foundations for this. ISA-95 has spent decades giving us models and terminology for manufacturing operations and enterprise integration. OPC UA Companion Specifications provide standardized information models for specific equipment and domains. Sparkplug adds structure and state management to MQTT-based architectures. The Asset Administration Shell is another important effort around standardized digital representations of industrial assets.

So the industry is hardly starting from zero. The harder part is agreeing on your meaning:

  • What exactly constitutes downtime? When does a production cycle start? What does “starved” mean?

  • What is the difference between idle, blocked, waiting, and planned stop? Should an asset retain the same identifier after a major rebuild?

  • What happens when equipment moves to another line?

I have watched way too many OEE discussions develop the emotional intensity of a family argument about politics. Don’t believe me? Make a post on LinkedIn about OEE and watch what happens! 🤣 One plant considers any machine stop downtime. Another excludes micro-stops. Another measures only lost scheduled production. All three can explain why their approach makes perfect sense.

That is why companies need a canonical model. Establish persistent asset identifiers, equipment hierarchies, units, standard machine states, downtime categories, product relationships, and time rules. Decide where enterprise consistency matters and where sites can extend the model because their processes truly differ. For scalable use cases, I strongly recommend a data contract. Document the source, owner, schema, unit, expected latency, quality threshold, retention requirement, security classification, and versioning process. That way, when someone changes a field name six months later, twenty downstream applications do not discover the change simultaneously at 6:07 Monday morning.

Another major issue has been platform portability. Companies can create good contextual models inside one vendor’s platform and then discover that applications depend heavily on proprietary APIs. CESMII’s i3X is interesting here because it provides an open, common API for accessing contextualized manufacturing information across compliant platforms. CESMII released i3X 1.0 in 2026, which moves the discussion from conceptual interoperability toward something developers can actually implement. It does not eliminate the need to model the plant. Somebody still has to decide what a production order means and whether LINE_04_FILLER_A is actually the same asset everyone else calls “Filler 7.”

My favorite test for this layer is simple: bring in a competent engineer who was not involved in the pilot and ask them to trace a defective lot through the equipment and conditions that produced it. If their first step is asking, “Who built this originally?” you still have work to do.

Decision Layer (Layer 3): Figure Out Who Is Supposed to Do Something

The decision layer defines how information changes what happens in the operation. It answers who owns the decision, what triggers it, which evidence is required, how quickly action must occur, what authority exists, and how escalation works. This layer is interesting because many of the technical tools have existed for a long time. Manufacturing has decades of experience with alarms, statistical process control, rules engines, optimization, automated control, and safety systems.

What is becoming more difficult is the growing use of probabilistic recommendations and automated decisions. Suppose a model predicts a bearing failure with 78% confidence. Great. Now what? Do you stop production? Inspect during the next break? Wait until the next planned shutdown? Order a replacement bearing? Reduce speed? Ignore it because you have three spares and a redundant pump?

The model score is one input. The operational decision depends on consequence, production demand, inspection cost, maintenance capacity, spare availability, safety exposure, and reversibility. Before building another dashboard, write a decision specification. Define the trigger, required inputs, owner, available actions, response deadline, escalation path, override authority, and evidence needed to close the issue. Also define the cost of false positives and false negatives. This is huge! A quality model that catches virtually every possible defect by rejecting 20% of good production may receive enthusiastic applause from the data-science team and a very different reaction from the CFO.

I also like explicitly defining levels of authority. The system might inform, recommend, prepare an action, execute within defined limits, or eventually operate with minimal intervention. New models can run in shadow mode first so their recommendations can be compared with actual human decisions.

For AI-specific governance, the NIST AI Risk Management Framework is a useful reference. RACI and RAPID remain surprisingly effective for the far less glamorous question of figuring out who gets to decide what.

My test here is the night-shift supervisor. Can that person explain what the system detected, why it matters, what options they have, and what happens if they disagree with the recommendation? If the answer requires waking up the engineer who built the pilot, congratulations: you have created a very sophisticated pager.

Workflow Layer (Layer 4): Follow the Decision Until the Work Is Actually Finished

The workflow layer is what carries a decision through the organization. It includes assignments, approvals, system updates, scheduling, exceptions, handoffs, evidence, and feedback. This is where beautiful analytics often encounter the spectacularly unglamorous machinery of getting work done.

Imagine your predictive-maintenance application identifies an emerging bearing problem at 2:13 a.m. That sounds impressive in the case study. In the factory, somebody now has to validate the condition, assess the risk, check whether a spare exists, create a work order, find someone with the correct skills, negotiate a production window, complete the repair, document the finding, and somehow feed the result back into the analytics system.

We have plenty of mature systems here: CMMS, MES, ERP, quality platforms, workflow engines, service-management systems. BPMN gives organizations a useful standard for modeling processes across people and systems. The problem usually lives between them. Go follow a real event. Literally follow it. Sit beside the planner. Watch the emails. Look at the spreadsheets. Listen to the radio calls. Find the duplicated data entry. Ask why someone printed a report from System A and typed the numbers into System B.

There is almost always a person somewhere who has become an unofficial middleware layer through years of accumulated knowledge. Everyone knows that Sharon fixes it every morning. Sharon may be fantastic. Sharon is also not an API.

For each workflow step, establish an owner, required information, expected completion time, output, and escalation path. Model exceptions because exceptions are where real plants spend their lives: the spare is missing, the technician is unavailable, production refuses the maintenance window, the inspection is inconclusive, or the machine magically starts behaving normally five minutes before engineering arrives.

And don’t forget to close the feedback loop! If the system predicted bearing degradation, capture what maintenance actually found. Was the bearing damaged? Was the severity estimate accurate? Did the intervention prevent downtime? That information needs to return to the analytics process so the company can improve thresholds and understand whether the system is genuinely helping.

Replication Layer (Layer 5): Package the Thing So It Can Survive Without Its Parents

The replication layer is where the architecture, data model, decision logic, workflow, governance, deployment process, support model, and economics become something another plant can actually adopt.

I consider this the hardest layer because it forces companies to turn the expertise embedded inside a pilot team into a repeatable capability. Software has given us plenty of useful practices: version control, automated testing, containerization, observability, release management, infrastructure as code, platform engineering, and product ownership. Industrial environments make applying those practices considerably messier. Equipment generations vary. Connectivity can be intermittent. Vendors restrict access. Maintenance windows are limited. Safety matters. Some machines will still be running when today’s cloud platform has been renamed four times.

Industrial edge application management is one area where the technology itself is still maturing. Historically, different combinations of hardware, operating systems, applications, and orchestration platforms have required different deployment and lifecycle approaches. The Margo initiative is working on an open specification, reference implementation, and compliance tooling to improve interoperability across industrial edge environments. That could remove a significant amount of friction from multi-vendor deployment.

Inside the company, though, I would manage every serious scaling candidate as a product. Give it an owner, roadmap, release cadence, funding source, support model, service levels, and retirement criteria. Set pilot exit requirements before everyone celebrates the pilot. Define the minimum expectations for cybersecurity, reliability, data quality, measured value, workflow adoption, documentation, training, backup, recovery, and support. Then build a scale package. Include the reference architecture, approved hardware and software versions, connectors, security controls, data contracts, semantic models, workflows, test scripts, commissioning procedures, training, monitoring, troubleshooting guidance, rollback procedures, and support responsibilities. Decide what sites can configure themselves and what remains standard. KPI definitions, security requirements, data contracts, logging, and lifecycle ownership may stay common. Thresholds, asset mappings, language, shift schedules, and local endpoints may vary.

I also like grouping plants into a small number of archetypes. A highly standardized modern facility should not receive the same deployment plan as a 30-year-old brownfield site held together by legacy controls and what appears to be an unreasonable amount of electrical tape. Classify plants by controls environment, network maturity, cybersecurity readiness, workforce capability, process type, and existing systems.

Then rank rollout candidates by value and readiness. Look at throughput, yield, downtime, labor, energy, inventory, service, and risk for value. For readiness, assess network capacity, data quality, semantic maturity, cybersecurity, workflow ownership, skills, and local leadership.

One trap I see constantly is deploying where it is easiest because easy deployments make the roadmap look wonderfully green. Six low-value deployments are still six low-value deployments.

A central product or platform team should own reusable architecture, shared components, vendor qualification, releases, advanced support, and the roadmap. Site teams should own local process design, deployment, training, and adoption. Team Topologies offers some useful thinking around platform teams and reducing cognitive load.

AI Is Not Missing. It Is Inside the System.

AI can contribute across every one of these layers. It can help identify weak signals in the operational foundation, infer relationships in the context layer, improve recommendations in the decision layer, assist people through workflows, and even make deployments easier to configure and support.

Its usefulness grows dramatically when the environment around it is dependable. That is why I left AI off the graphic. I wanted the five layers to focus on the things that determine whether any Industry 4.0 capability can survive beyond the pilot: infrastructure that holds up, data that means something, decisions that have owners, workflows that reach completion, and a deployment model another plant can actually use.

The real test comes six months later. The original engineers are working on something else. The plant replaces a controller. A new supervisor takes over night shift. Product mix changes. Someone modifies a workflow. Nobody has prepared for a demo. And it still works. That is when I would finally call it scaled.

References:

Jeff Winter
Next

Where AI Is Really Taking Hold Across the United States