Edge AI for Quality Inspection: Why Inspection Data Should Stay in the Plant

Edge AI for manufacturing means running the model where the data is produced: on a GPU server in the plant, a couple of switches away from the camera and the PLC. For quality inspection that’s less a design preference than something the line forces on you.

A camera on a fast line produces a continuous, full-resolution image stream. Somewhere downstream there’s a reject gate, a flagger or a robot that needs a decision before the part or the web gets there. Every millisecond spent shipping images off-site comes out of that window, and every dependency on a WAN link is one more way for the line to lose inspection on a Tuesday night.

If you’re the CTO, director of engineering or IT/OT lead who has to sign off on an AI inspection project, here’s what the architecture looks like and what we’d want settled with you early.

The time budget comes from the conveyor

Take the distance from the camera to the reject point and divide it by line speed. What you get is the total time for capture, transfer, inference, the decision and the PLC signal. That number is fixed by the conveyor and the station layout, long before anyone picks a GPU.

Tristar has deployed on lines running up to 1,600 feet per minute and on stations inspecting multiple parts per second. At those rates the window is tight, and it has to be met on every frame, including the frame that arrives during a network hiccup. A round trip to a data center, with variable delay you don’t control, won’t fit inside it reliably, which is why the GPU server sits on the plant floor on a network segment you manage.

Image streams are heavy

Resolution comes from the camera, which is chosen for the smallest defect you need to catch. For a line-scan camera, the raw data rate is pixels per line, times lines per second, times bytes per pixel. On a wide web at speed, with fine resolution, that product becomes a very large, continuous stream. Multiply it by 2–3 cameras per station and several stations per plant, and pushing all of it upstream ranges from expensive to impractical.

An edge server processes the frames where they land and keeps only what’s useful: defect crops, results, roll maps and whatever image retention your policy sets.

There’s also the uplink itself. If the WAN drops, an on-premises station keeps inspecting and rejecting as though nothing happened. A cloud-dependent one either stops the line or lets uninspected product through, and no plant manager will sign up for either.

What sits where

A Tristar station has a small number of components, all inside the plant:

The cameras are off-the-shelf hardware, so IT isn’t signing up to support proprietary sensors that go obsolete on one vendor’s schedule. For what happens inside that loop between the trigger and the reject, see how AI defect detection works on a production line.

Keeping images and quality data at home

Production images are sensitive. They show your products, your tooling and, on assembly lines, your process. Defect records are sensitive in a different way, since they end up as evidence in customer disputes and audits.

With Tristar, processing runs on the edge inside the plant and nothing needs to go to the cloud. That changes the security conversation in a few concrete ways.

• Images and results stay inside your boundary, stored where your retention and access rules already apply.
• The attack surface is small and familiar: a GPU server, cameras and a PLC interface on a segment you control, managed under your existing OT policies.
• Private hosting is the default design. Nobody’s negotiating for a “private” tier of a cloud service.
• Scaling to another plant doesn’t create a new dependency. Each site runs its own inspection loop, so a network problem at one plant never touches inspection at another.

That last point is what makes a design copyable. A VP of operations wants to know whether the station proven at one site can go into the next without a fresh IT project, and with standard hardware and a local loop, it usually can. Our plastic film article shows what that looks like on high-speed web lines.

Can it run on a one-way or segmented network?

Yes, and this is the part of the first IT conversation that deserves the most time.

Plenty of plants separate OT from IT with firewalls and a DMZ. Some regulated or high-security sites go further with one-way networks (data diodes), so data can leave the OT zone and nothing can come back in. An inspection station fits that model well, because its real-time loop is entirely local: camera, edge server, PLC, operator alert. None of it crosses a boundary to work.

Some things do cross, and each needs a decision:

• Reporting. Leadership dashboards and roll reports may need to reach users on the IT network. A one-way flow out of OT can serve them.
• Learning after go-live. The model improves as your team reviews flagged images with Tristar, so agree how those images reach reviewers and how updated models get installed under your change control.
• Support. Decide whether remote support is allowed and through which approved path, or whether support happens on site only.

Questions to settle with IT before the station is designed

Answers vary by site. What matters is that each one has an owner before anyone orders a camera, and that the answers travel with the rest of your buyer’s checklist when you compare vendors.

1. Which segment do the cameras, the edge server and the PLC interface sit on, and does anything change in the existing firewall rules?
2. What leaves the OT zone, if anything: results, images, reports? In which direction? Does policy require a one-way network?
3. Can we confirm the station runs fully with the internet unplugged?
4. Which PLC, which tags and signals, who owns the logic change, and how is it tested before it drives a reject?
5. Which MES/ERP records need to link defects to lot, and where do they get written?
6. Who patches the server’s OS, who monitors the hardware, and what are the power, cooling and dust conditions where it’ll sit?
7. How are model and tolerance updates validated and deployed, and who approves them?
8. Is remote access allowed, and if so, through which approved path?
9. How long are images and results kept, where, and who can see them?
10. How will the same design be copied to the next line and the next plant?