A food and beverage manufacturer was running a packaging line at twelve hundred units per minute. If you've never stood next to a line running at that speed, it is genuinely disorienting — products moving so fast that individual units are a blur, the line an almost continuous stream of material traveling from filling to capping to labeling to case packing in a matter of seconds.

The manufacturer had invested in a machine vision system to perform label inspection on that line. The system used a camera mounted above the conveyor to capture an image of each unit as it passed, analyze the image for label placement, print quality, and barcode readability, and trigger a pneumatic reject mechanism to divert any unit that failed inspection. The entire sequence — capture, analyze, decide, reject — had to complete in fifty milliseconds. At twelve hundred units per minute, a unit crosses the reject gate every fifty milliseconds. Miss the window and you either reject the wrong unit or let the bad one pass.

The manufacturer's IT department, in the middle of a broader cloud migration initiative, proposed routing the vision system's image analysis through the company's cloud analytics platform. The argument was sensible on its face: the cloud platform had more processing power, more sophisticated AI models, and a centralized management interface that the IT team could maintain from headquarters. Running the vision system locally meant maintaining dedicated compute hardware on the factory floor, which the IT team wanted to eliminate in favor of centralized cloud resources.

They ran the pilot. The results were immediate and unambiguous. Cloud round-trip latency — the time from image capture to analysis result returned — averaged one hundred and forty milliseconds on a good network day. On a congested day it climbed past three hundred. The fifty-millisecond decision window the vision system required was simply not achievable through the cloud. Every attempt to run the analysis in the cloud either missed reject windows entirely or introduced reject timing errors that sent good product to the waste stream and let bad product through.

The IT team, to their credit, recognized the result for what it was: not a technology failure but a physics lesson. The cloud was not too slow because the technology was inadequate. It was too slow because the speed of light has limits, and routing data from a production floor in Ohio to a data center in Virginia and back — even at network speed — takes longer than the production process is willing to wait.

They rebuilt the vision system with a local compute platform mounted in the control panel adjacent to the line. Inference ran locally. Results were logged to the cloud. Management happened centrally. The fifty-millisecond decision window was met consistently. The line ran at full speed. The cloud did what cloud does well. The edge did what only the edge can do.

That story is a precise illustration of why edge computing is not optional in a connected factory. It is a consequence of physics. And understanding the physics is the beginning of understanding the architecture.

Welcome back to The Connected Frontier. I'm Katherine Blough, and this is Episode 4 of The Connected Factory. I've spent most of my career at the intersection of networking, operations technology, and manufacturing — and edge computing is the topic where all of those domains converge most directly. Today I want to take you through the technical and architectural reality of edge computing in manufacturing, with enough specificity to be genuinely useful and without the vendor framing that usually surrounds this conversation.

The Physics of Manufacturing Decisions

The word "latency" is used constantly in technology conversations and understood precisely by very few people outside of networking. In the context of manufacturing, understanding it precisely is not optional — it is the foundation of every architectural decision about where computation should happen.

Latency is the time between a stimulus and a response. In a networked system, it is the time between sending a piece of data and receiving the result of processing that data. It has a floor — a minimum that cannot be improved by better software or faster processors — determined by the physical distance the data must travel and the speed at which electrical signals or light pulses move through the medium carrying them. Light travels through fiber optic cable at roughly two-thirds the speed of light in a vacuum, which works out to about five microseconds per kilometer of fiber. A round trip from a factory in Ohio to a data center in Northern Virginia — a common cloud pairing — covers approximately eight hundred kilometers of fiber path each way, producing a floor latency of around eight milliseconds just for the physics of propagation, before accounting for any processing time, routing delays, or network congestion.

Eight milliseconds sounds fast. For many decisions, it is fast enough. But manufacturing decisions span an enormous range of time requirements, and understanding where eight milliseconds — or the more realistic one hundred to three hundred milliseconds of actual cloud round-trip latency — falls on that range is what determines which decisions can be made in the cloud and which cannot.

At the fastest end of the spectrum are safety-critical control decisions. The emergency stop circuit that cuts power when a guard door opens while a machine is running. The servo drive that corrects position error in a CNC machine thousands of times per second to maintain dimensional accuracy. The pressure relief logic that vents a hydraulic system before it reaches a dangerous state. These decisions are made in microseconds to single-digit milliseconds. They are made by embedded control systems — PLCs, servo drives, safety relays — that are designed and certified specifically for deterministic real-time response. No general-purpose computer, no cloud platform, and no edge server participates in these decisions, nor should one. They belong to dedicated control hardware that has been engineered to meet specific safety and timing standards and is not part of the general connected factory architecture.

One step above the control layer are the decisions that quality vision systems like the one in my opening story make. Inspection and detection decisions — accept or reject, alarm or continue, flag or pass — that need to be made within the cycle time of the process being monitored. At twelve hundred units per minute, that cycle time is fifty milliseconds. At sixty parts per minute on a slower line, it is one second. At one part per hour on a very slow precision process, it might be minutes. The appropriate architecture for these decisions depends entirely on the cycle time: fast processes require local compute with subsecond response; slow processes can potentially route to cloud if the network is reliable.

Further up the time hierarchy are process adjustment decisions — identifying that a process is trending toward an out-of-control condition and adjusting parameters before defects occur. These decisions can typically tolerate latency of seconds to minutes, which opens more architectural options. An edge server on the plant network can serve these decisions effectively even without a cloud round-trip — local inference on streaming process data, with results fed back to the control system as setpoint adjustments.

Planning and scheduling decisions tolerate latency of minutes to hours and are well-served by cloud infrastructure: complex optimization algorithms running on large datasets, accessing enterprise data from ERP and supply chain systems, producing outputs that are consumed by humans who then configure the production environment. These are the decisions that cloud-first architectures handle best, and they represent a significant portion of the analytical value that connected factory programs aim to capture.

The architectural principle that falls out of this hierarchy is simple in concept and often violated in practice: match the processing location to the decision time requirement. Decisions that cannot wait go at the edge, close to the process. Decisions that can wait go where processing power is most cost-effective — which is usually, but not always, the cloud. And the edge and cloud work together as a system rather than competing as alternatives.

The End of the Air Gap — What It Changed

To understand why edge computing has become a critical topic in manufacturing specifically, you need to understand something about how manufacturing technology environments were structured for most of the past three decades, and what changed.

For most of the history of industrial automation, operational technology — the PLCs, SCADA systems, historians, and control networks that ran the production floor — was physically separated from information technology — the enterprise networks, ERP systems, and business applications that ran the rest of the company. This separation, called an air gap, was not originally a security design decision. It was an accident of history: OT systems used proprietary communication protocols that were incompatible with IP networks, ran on operating systems that predated modern networking, and were designed by vendors who had no reason to think about enterprise integration. The air gap was simply the natural consequence of OT and IT being built in different eras with different assumptions.

Over time, the air gap became a deliberate security posture. OT systems run production. Production downtime is expensive, sometimes catastrophically so. The more isolated the OT network from the outside world, the less exposure it had to the viruses, intrusions, and ransomware attacks that increasingly plagued IT networks. The air gap was inconvenient for information flow but reassuring for operational security.

The air gap is now largely gone. Not because anyone made a strategic decision to eliminate it, but because business requirements created pressure to connect OT and IT systems that proved stronger, over time, than the operational inertia keeping them separate. Remote monitoring by equipment vendors required network connectivity to OT systems. ERP integration with production execution required data flows between OT historians and IT databases. IoT sensors required IP connectivity to transmit data. Corporate IT consolidation programs extended enterprise network infrastructure to the plant floor. Each of these pressures opened connections, and the cumulative effect of years of these individual decisions has been that most manufacturing facilities now have OT networks that are connected — directly or indirectly — to corporate IT networks and, through them, to the internet.

This is not inherently bad. Connection enables the digital thread, the data flows, and the analytical capabilities that the connected factory depends on. But it does mean that the security assumptions that governed OT design for decades are no longer valid, and that the architectural question of where processing happens is now a real question with real consequences — rather than being settled by default by an air gap that kept everything local.

The end of the air gap is what makes edge computing an active architectural choice rather than a given. When OT and IT were separated, everything that happened on the production floor happened locally by definition. Now that the connection exists, organizations have to decide: which processing should stay local, which should go to the cloud, and what infrastructure do we need to support each? The air gap used to answer that question by force. Edge architecture answers it by design.

What Edge Computing Actually Is

Edge computing is an architectural concept, not a product category. This distinction matters because the technology market has attached the "edge" label to a wide variety of products — from ruggedized servers to industrial PCs to smart switches to purpose-built inference accelerators — in ways that can make the concept feel more exotic and more product-specific than it actually is.

At its most basic, edge computing means computation at or near the point where data is generated and where decisions need to be made. In manufacturing, that means on the production floor, close to the equipment, inside or adjacent to the control environment. The "edge" in edge computing refers to the edge of the network — the boundary between the controlled production environment and the broader IT and cloud infrastructure beyond it.

It helps to think about the computing environment in manufacturing as a hierarchy with several layers, each with different characteristics and appropriate workloads. At the bottom is the embedded control layer: the PLCs, servo drives, and dedicated safety systems that run inside machines and control loops. These are deterministic, real-time, and closed — they do not participate in the general data and analytics architecture. They run the process.

Above the control layer is what I think of as the near-edge: compute resources that are physically close to the production equipment, often mounted in control panels or in enclosures on the production floor. This is where real-time inference, high-frequency data collection, and local decision logic happen. Near-edge hardware needs to be ruggedized for industrial environments — tolerant of temperature variation, vibration, dust, and humidity that would compromise standard IT equipment. It needs to be highly reliable, because downtime of near-edge infrastructure typically means downtime of the process it supports. And it needs to be relatively simple to manage, because the people closest to it are often operations and maintenance technicians rather than IT administrators.

Further up the hierarchy is the plant-level edge, sometimes called the far-edge or the on-premises data center: a rack or cluster of servers in a plant control room or data room that aggregates data from multiple production lines, runs more computationally intensive workloads, and serves as the local repository for operational data. Plant-level edge infrastructure is less ruggedized than near-edge hardware but more capable — it can run complex analytics, host local versions of MES applications, and provide the buffering and processing that allow operational data to be normalized and enriched before it flows to the cloud.

At the top of the hierarchy is the cloud: the central data repository, the training environment for AI models, the home of enterprise analytics, the integration point for supply chain and customer data, and the management plane for the entire edge infrastructure. The cloud is not absent from the connected factory architecture — it is essential. But it is present in a specific role that is complementary to, not a replacement for, the edge layers beneath it.

Understanding this hierarchy — and being specific about which layer different workloads belong on — is what separates a coherent edge architecture from the ad hoc accumulation of connected devices that characterizes most manufacturing environments today. The question is not "edge or cloud?" It is "which layer of this hierarchy is right for this workload, and what does that imply about the infrastructure I need to put in place?"

Edge AI — Where Intelligence Meets Physics

Artificial intelligence at the edge is one of the most actively developed areas in manufacturing technology, and it is also one of the most frequently misunderstood. The misunderstanding usually takes the form of treating edge AI as simply a matter of moving AI workloads from the cloud to a local server. In reality, edge AI requires a fundamentally different design than cloud AI, and understanding the differences is essential for anyone making decisions about how to deploy AI in a manufacturing environment.

The core distinction is between training and inference. Training an AI model is the computationally intensive process of exposing a model architecture to a large dataset and adjusting the model's parameters until it produces useful outputs. Training requires enormous amounts of labeled historical data, significant compute resources — typically GPUs in a cloud data center — and time measured in hours, days, or weeks. Inference is the process of applying a trained model to new data to produce a prediction, a classification, or a decision. Inference is computationally much lighter than training and can often run on relatively modest hardware, including the ruggedized edge platforms appropriate for a production floor environment.

Edge AI, properly understood, means inference at the edge — applying trained models locally, close to the process, to enable decisions at the time and place they need to be made. Training still happens in the cloud, where the data, the compute, and the tooling are available. The trained model — a much smaller artifact than the training infrastructure — is packaged and deployed to the edge platform. At the edge, it runs inference on live data from sensors, cameras, and control systems, producing outputs that feed back into the control environment or alert the right people.

This model — train centrally, infer locally — is elegant in concept and nontrivial in execution. The first challenge is model optimization. A model that runs well in a cloud data center with high-end GPUs may not run acceptably on the constrained hardware of an industrial edge platform. The model typically needs to be compressed and optimized for the target hardware — a process called quantization and pruning — which reduces its computational footprint while attempting to preserve its predictive accuracy. Finding the right balance between model size, inference speed, and accuracy for a specific edge hardware target is a discipline in itself.

The second challenge is model lifecycle management. A model deployed to the edge is not static. The process it is monitoring changes over time — materials change, equipment ages, product mixes shift — and a model that was accurate when it was deployed will gradually become less accurate as the world it was trained on diverges from the world it is running in. Managing the lifecycle of edge AI models — monitoring their performance, detecting degradation, retraining with current data, and redeploying updated versions — requires infrastructure and discipline that most organizations are only beginning to build. In a facility with dozens of edge AI models running across multiple production lines, model lifecycle management is a significant ongoing operational commitment.

The third challenge is data representation. A model trained on data collected under one set of conditions may perform poorly when deployed to a production environment where conditions differ from the training data. If the training data was collected from a machine in excellent condition and the deployment target is a machine that is somewhat worn, the model may behave unexpectedly — detecting anomalies that reflect normal variation in the deployed environment rather than genuine problems. Bridging the gap between training conditions and deployment conditions requires careful attention to how training data is collected and curated, and ongoing evaluation of model performance in the actual deployment context.

Despite these challenges, the value case for edge AI in manufacturing is compelling and increasingly well-demonstrated. Vision-based quality inspection running at production speed. Acoustic anomaly detection that hears bearing degradation before it shows up in vibration data. Process optimization models that adjust setpoints in real time to maintain quality as material properties vary. Energy management that shifts loads in response to real-time production conditions and utility pricing. Each of these applications requires inference at the speed the process demands, and each delivers value that is difficult or impossible to achieve through human attention alone. The edge AI challenge is not whether the value is there. It is building the infrastructure, the operational discipline, and the organizational capability to capture it reliably.

OT Connectivity — The Last Mile That Defines Everything

I want to spend significant time on what I think is the most underappreciated technical challenge in building the connected factory: the problem of connecting operational technology devices to the data infrastructure that the rest of the architecture depends on. Because no digital thread, no edge AI, no connected factory program of any kind can deliver value if the devices that generate the operational data cannot be reached.

The challenge is that manufacturing equipment speaks many languages. Not metaphorically — literally. The communication protocols used by industrial devices to send data and receive commands are enormously diverse, and most of that diversity reflects decisions made by equipment vendors decades ago that were never designed for interoperability.

Modbus, developed in 1979, is still running on production floors around the world — in everything from temperature controllers to variable frequency drives to older PLCs. PROFINET is the dominant protocol in Siemens-centric automation environments. EtherNet/IP — which, despite the name, is not standard Ethernet — is the protocol of choice in Rockwell Automation environments. PROFIBUS, DeviceNet, CC-Link, and a dozen other fieldbus protocols serve specific automation ecosystems and geographies. Most large manufacturing facilities have equipment running several of these protocols simultaneously, reflecting different eras of capital investment and different vendor choices made by different engineering teams at different times.

Building a connected factory on top of this protocol diversity requires a connectivity layer — hardware and software that can speak the native protocols of OT devices and translate their outputs into a common format that edge and cloud platforms can process. This connectivity layer is often called an industrial gateway or a protocol converter, and its capabilities vary enormously. Some gateways translate a single protocol into IP. Others handle dozens of protocols and expose a normalized data stream. The right choice depends on the specific protocol mix in a given facility and the architecture of the systems receiving the data.

The most important development in industrial connectivity standards over the past decade is OPC Unified Architecture, universally called OPC-UA. OPC-UA is an open standard — developed and maintained by the OPC Foundation, a consortium of industrial automation vendors — for machine-to-machine communication in industrial environments. It defines not just a communication protocol but a data modeling framework: a way of representing the structure, semantics, and relationships of industrial data that goes beyond simple value transmission to convey meaning. An OPC-UA data stream does not just tell you that a temperature sensor read 847 degrees. It tells you that this temperature sensor is of type "forging die thermocouple," is located on press P7, measures in degrees Celsius, has a calibration expiration date of March 2026, and its current value is 847, with a timestamp of 14:23:07 and a quality indicator of "good." That richness — data with built-in semantic context — is the difference between a data stream that requires significant post-processing to become useful and one that arrives in a form that the receiving system can immediately interpret.

OPC-UA adoption has accelerated substantially in recent years, and it is increasingly the connectivity standard that equipment vendors, automation platform providers, and connected factory architects converge on. But it is not yet universal, and in most existing facilities, OPC-UA represents a layer that needs to be added to existing equipment rather than something that was built in from the start. Adding OPC-UA connectivity to older PLCs and control systems typically requires either a firmware update — if the equipment vendor supports it — or an external gateway device that bridges between the device's native protocol and OPC-UA. Both approaches work. Neither is trivial at scale.

There is one more connectivity dimension worth naming: the wireless question. Most existing manufacturing facilities have wired connectivity for their automation infrastructure — Ethernet cables running from control panels to network switches to plant servers. Adding connectivity to devices that are not wired — mobile equipment, handheld tools, sensors added to existing machines that were not designed with network connectivity in mind — requires wireless infrastructure. Industrial wireless environments are more demanding than office wireless environments: interference from motors and variable frequency drives, metal structures that reflect and absorb signals, environments where connectivity interruptions have operational consequences. Wi-Fi 6 and private 5G networks are both increasingly used for industrial wireless applications, each with different trade-offs in coverage, capacity, latency, and management complexity. The choice between them, and the design of the wireless infrastructure that supports connected factory operations, is a significant engineering decision that deserves the same careful attention as the wired connectivity architecture.

The Unified Edge — Architecture Over Products

I want to close the technical content of this episode with a concept that I think is more important than any specific technology choice: the idea of the unified edge.

A unified edge is not a product. It is an architectural outcome — the condition in which an organization's edge computing infrastructure, across all of its production lines and facilities, is managed as a coherent, consistent environment rather than as a collection of independent, individually configured systems. It is the difference between a factory where every production line has its own unique compute setup, maintained by whichever engineer or integrator built it, running software that was configured to work in that specific context and may or may not be compatible with anything else — and a factory where every edge node is managed centrally, runs a consistent software stack, and can be monitored, updated, and configured from a single management plane.

The operational case for the unified edge is compelling. Consider what happens when an edge server on line three needs a software update, or when a new AI model needs to be deployed to all vision inspection systems across the facility, or when a security vulnerability is discovered in the operating system running on edge platforms. In an unmanaged edge environment — which describes most manufacturing facilities today — each of these operations requires manual intervention at each individual edge node. In a large facility with dozens of edge systems, manual-at-scale is an operational burden that quickly becomes unsustainable. In a unified edge environment, software updates are pushed centrally. Model deployments are managed through a single interface. Security patches are applied across the fleet simultaneously. The operational overhead of managing edge infrastructure scales with the size of the management plane, not with the number of edge nodes.

The security case for the unified edge is equally compelling. Consistent configuration management means that security policies are applied uniformly rather than depending on the individual judgment of whoever configured each system. Centralized monitoring means that anomalous behavior on any edge node is visible to the security operations function rather than invisible until a local operator notices something wrong. Centralized patch management means that the time between vulnerability discovery and remediation is measured in hours rather than weeks. These security properties are increasingly important as OT networks become connected — because a connected edge that is not managed as a coherent security environment is a connected attack surface that is difficult to defend.

Building toward a unified edge does not require replacing all existing edge infrastructure simultaneously. The path forward is typically incremental: establish the management architecture first, then bring new edge deployments into it from the start, and migrate existing deployments as they are refreshed or upgraded. Over time, the proportion of edge infrastructure under centralized management grows, and the operational and security benefits compound as coverage increases.

One organizational question that the unified edge forces into the open is the question of who owns the edge. This is the IT/OT convergence question in its most specific form. OT teams own the production floor and are responsible for the availability and performance of the systems that run it. IT teams own the network and compute infrastructure and are responsible for its security and manageability. The edge sits at the intersection of both domains. Managing it effectively requires both OT expertise — understanding the production environment and its requirements — and IT expertise — understanding the network, the security posture, and the management tools. Organizations that try to solve this by assigning edge ownership entirely to one side or the other typically end up with infrastructure that is either operationally excellent but poorly managed, or well-managed but operationally disruptive. The organizations that get it right build a genuinely collaborative model — joint ownership with clear accountabilities — that brings both disciplines to bear on the decisions that require both.

What Edge Makes Possible — The Bridge to AI

This episode has been about infrastructure — the compute and connectivity foundation that makes real-time operational intelligence possible in a manufacturing environment. And infrastructure, by its nature, is a prerequisite rather than a destination. The destination is what the infrastructure enables.

What the edge enables, at its most consequential, is AI that works in the factory floor environment rather than despite it. Every AI application that requires real-time response — vision inspection, process monitoring, anomaly detection, immediate quality feedback — depends on edge infrastructure to deliver that response within the time window the process allows. The edge is not just a performance optimization. For these applications, it is the condition of possibility.

But as we'll discuss in the next episode, edge infrastructure — however well-designed — is not sufficient to make AI succeed in manufacturing. The most common failure mode in manufacturing AI is not inadequate infrastructure. It is deploying AI into an organization that is not ready to use it well. Episode 5 is about what organizational readiness for AI actually requires, why it is the prerequisite that gets skipped most often, and why skipping it is expensive in ways that are predictable and, with the right preparation, avoidable.

The argument is one I've made before, in our first series. But the version of it I want to make in Episode 5 is more specific — grounded in what we've built together across the first four episodes of this series — and I think it will land differently with the digital thread and the data and the edge architecture in place as context.

Closing

A personal note to close. I spent years working in networking and operational technology, and the question of how computing infrastructure should be distributed between the factory floor and the broader enterprise was a live and contested one for most of that time. The answer has become clearer as the technology has matured — not simpler, but clearer. The edge and the cloud are not competitors. They are complementary layers in an architecture that needs both to work, and understanding the role of each is what allows organizations to make investments that build on each other rather than investments that have to be undone and redone when the architecture doesn't fit the operational reality.

The physics are not negotiable. But the architecture is very much a choice. And the organizations that make that choice deliberately — with a clear understanding of what processing belongs where and why — build edge infrastructure that pays dividends across every connected factory capability that depends on it.

I'm Katherine Blough — and this is where strategy meets reality.