Content

The demo works. A camera or vibration sensor detects a fault on one production line. Nine months later, the same model is still running on a box someone carried into the plant, connected to a historian export and relying on a firewall exception the plant security team wants closed.

The model did not fail. The infrastructure designed to feed it, deploy it, and keep it separated from the control network never became a production-ready system.

That is the usual pattern when an edge computing manufacturing project stalls. Computing next to the process is not the problem. The real problem is that three critical contracts often have no clear owner at kickoff: OT data that can be used for training and replay, a latency budget tied to an actual decision, and a DMZ path that security will allow to remain after the pilot.

HiveMQ’s 2026 industrial AI survey, based on a vendor-published sample, illustrates the scale of the gap. Only 7% of respondents reported having AI embedded in core operational processes, while 68% were still in pilots, proofs of concept, limited deployments, or research. In addition, 48% identified legacy-system integration and data silos as a leading barrier (Industrial AI Pilot: Why 68% of Manufacturers Can’t Scale Past the POC | HiveMQ).

Treat those findings as a vendor viewpoint, not a census of every manufacturing plant. Even so, they describe a familiar failure pattern.

The Data Contract Comes Before the Model

Plant data is typically structured for control systems and operator screens. Models require identity, units, timing, and operational context. Those are different requirements.

The same gaps repeatedly consume project timelines: three production lines with three different tag conventions and no mapping to a common asset; integers with no documented scale or unit; and PLCs, historians, cameras, and gateways operating on clocks that have drifted apart, making it difficult to reconstruct cause and effect.

Historian deadbands and one-minute averages may look acceptable on a trend chart while erasing the transient event a detector needs. A 100-millisecond scan gets sampled every five seconds, and the algorithm is then blamed for what it misses.

Define the data contract before the first training run. Document the required signals, sample rates, units, quality flags, acquisition and ingest times, retention periods, and identifiers for the asset, batch or lot, shift, recipe, and machine state.

Without those identifiers, a model cannot distinguish a real fault from a normal changeover, and the quality team will have little reason to trust the output.

A shared time source across controllers, edge nodes, and cameras is not a minor detail. It is the difference between a properly labeled event and a coincidence.

Assume that you may not be allowed to modify a validated control program. Design around that limitation by using read-only OPC UA access, mirrored tags, or a parallel sensor path.

When the PLC cannot provide data at a usable rate, add independent vibration, electrical-current, thermal, or camera sensing. That is IoT and edge instrumentation, not a wholesale PLC replacement.

If the workload involves computer vision, establish a defect taxonomy with the quality team, capture real variation across shifts and suppliers, and retain the original image frames. The remaining steps are covered in the automated visual inspection playbook.

Latency is a Budget, Not a Slogan

“Low latency” is not a complete requirement. A real requirement connects a specific amount of time to a specific decision.

Break the complete loop into stages: capture, transfer, preprocessing, inference, decision, and actuation.

Teams often budget for inference time and then lose the remaining margin during data transfer and preprocessing. It is also important to separate three related properties.

Mean delay is latency. Variation in that delay is jitter, and a reject mechanism tied to an encoder position may care more about jitter than the average response time. A timing limit that cannot be missed requires determinism. Shared plant Ethernet does not provide that automatically.

Once the decision and timing requirements are clear, system placement becomes easier:

Closed-loop control stays in the PLC or motion controller.
Inline inspection and high-rate condition monitoring run beside the production line.
Cross-line correlation and OEE context sit on plant-level infrastructure.
Model retraining, fleet comparisons, and long-term analytics remain centralized.

NVIDIA’s manufacturing edge guidance makes a similar point about inspection workloads. Throughput and production-cycle requirements often place inference close to the camera rather than requiring a cloud round-trip (Manufacturing the Future of AI with Edge Computing | NVIDIA).

This is vendor guidance, so the production line must still demonstrate its own end-to-end timing at peak speed, with every camera streaming—not just one laboratory image.

Design the edge node for the cabinet it will actually occupy. Consider DIN-rail mounting, ambient temperature, fanless cooling, IP rating, vibration, and available power. Then work backward from the required frame rate, image resolution, and enough capacity to support a second model.

A store-and-forward buffer must also be included in that design. A temporary WAN outage should result in delayed data delivery, not a stopped production line.

This follows the same placement principle described in the live data backbone discussion: data cadence should follow the decision being made, not a universal “real-time” label.

The DMZ is a Data Path, Not a Ticket

A late security review can end an edge program even when the model performs well. Design the network crossing at the same time you design the edge node.

NIST SP 800-82 Rev. 3 is a public reference for protecting operational technology while accounting for its unique performance, reliability, and safety requirements. It also discusses common OT topologies, threats, vulnerabilities, and security countermeasures.

Use it as a design reference, not as a list of clause numbers to check off.

AWS guidance on manufacturing OT security also provides useful vendor terminology for Purdue-style IT and OT boundaries and industrial DMZ architecture. It should not be treated as independent proof.

Patterns that are easier to carry through a security review include:

Place a broker in the industrial DMZ and allow OT-side clients to publish outbound only.
Do not allow direct inbound sessions into control levels. Administrative access should pass through a recorded jump host.
Use store-and-forward capabilities on the edge node so a network interruption does not stop production.
Use certificate-based identities and signed software images and model artifacts.
Allow an OT-side agent to pull approved updates rather than pushing updates directly into the plant.

Write-back requires a separate contract. Creating an MES event or CMMS request is not the same as opening a session into a controller.

If a reject mechanism or setpoint is included in the scope, define the permitted operations, the fail-safe response when inference produces no result, and who has authority to bypass the system.

Forescout Vedere Labs’ 2025 roundup, which is based on vendor telemetry, reported that attacks using OT protocols increased by 84% year over year. Modbus accounted for 57% of the OT-protocol attacks observed in its dataset (2025 Threat Roundup | Forescout).

Do not treat those numbers as a census of manufacturing plants. Do treat the exposure of unencrypted legacy protocols through a newly opened network path as a design concern, not a surprise discovered in week twelve.

Give the security team a reviewable architecture, not simply a ticket. Document the zone and conduit, source, destination, protocol, port, direction, connection initiator, certificate owner, patch owner, log destination, and retention period.

Requests written with that level of detail are easier to evaluate and approve.

Prove it on Your Variation, Then Fund the Second Line

Vendor demonstrations run on clean data. Your production line operates through lighting changes, supplier lots, different shifts, and changing equipment conditions.

Require proof using actual production images and signals. Test across a shift change, a SKU change, and a deliberate network interruption. Measure the false-reject rate at the threshold the plant would actually use, not only the overall accuracy shown in a presentation.

A write path into the MES or CMMS requires the same level of testing. It should be idempotent, reversible, and auditable.

Establish the baseline before mounting the edge device. Measure first-pass yield, scrap, current false-accept and false-reject rates, and unplanned stops associated with the selected asset. If those numbers do not exist, the business case for the second phase remains only a story.

Separate the build-versus-buy decision by layer. Use established products for the node operating system, device management, and standard MLOps capabilities. Build the data contract, protocol translation, and the workflow that produces a result an operator can act on.

That final layer is often where off-the-shelf products stop. It is also where Softarex works within manufacturing operations: deploying inference on plant hardware, operating inside the plant network, and integrating MES, ERP, and OT systems through industrial protocols.

One public Softarex example provides useful scope, but it should not be treated as a universal benchmark.

Softarex’s real-time defect-detection case study describes an on-premises computer-vision system with a dedicated scanning station. The system processed more than 30 images per second and inspected one bearing ring in approximately three to five seconds.

Those numbers describe that specific system. The transferable lesson is the architecture: imaging, inference, operator review, data storage, and production constraints were designed together rather than added after the laboratory model was complete.

Start with a scope narrow enough to finish: one production line, one decision, one data contract, one DMZ pattern, and one named owner with a rollback plan.

Replicate the system at a second plant only after the contract has survived different tag conventions and a different PLC mix. That is how an edge computing manufacturing pilot becomes a repeatable deployment instead of remaining a permanent one-off.

Computer vision belongs within this architecture as both a sensor and an edge workload, not as a separate demonstration.

The Operating Test

Take the most recent successful edge demonstration and trace three things:

Which OT record trained or triggered it?
Which latency budget did it have to meet?
Which DMZ rule still allows it to operate?

If any of those three paths ends at a personal laptop, a one-time firewall exception, or a nightly CSV export, the gap is in the infrastructure—not the model.

If you are deciding whether to fund the next production line, begin with an assessment of the OT data path, latency budget, and DMZ architecture for one candidate process.

Softarex can scope that assessment around the actual PLC mix, camera or sensor environment, and the one operational decision that would justify deploying the edge node.