Defect detection for 8,000+ SKUs: how PLC auto-switching ended manual recipe configuration
Eight thousand product variants. Six production lines. Eleven thousand five hundred and twenty units per day per line. Two hundred and seventy units per hour at line speed, against 60 units per hour on the prior hardware-locked microscope inspection station and 40 units per hour on the manual inspection workstation it had replaced earlier. Ninety-nine percent defect detection across the variant mix. Two days on-site for installation and commissioning. A single 12-megapixel industrial camera replacing the two-camera, two-light setup the prior incumbent vision platform had proposed.
The deployment is the Auto Parts customer (Client A), running HyperQ AI Vision against an IATF 16949 quality system on an automotive precision-parts line. The headline metrics are the easy part of the story. The architectural change underneath the metrics is the part this post is about, because it is the change that makes the headline metrics reachable at all. The two largest hardware-locked machine vision vendors in the industry had both bid the line, both attempted deployment, and both walked away. We covered the broader pattern in the post on what the world's two largest machine vision companies could not solve. This post is the architectural detail of the specific deployment that closed the displacement.
What 8,000 SKUs actually means on a single line
The shorthand "high-mix manufacturing" undersells the operational reality of a line running thousands of distinct product variants. Each variant has its own dimensional spec, its own acceptable-variation envelope, its own defect classes, and its own inspection rule set. A line cycling through fifty variants per shift produces a recipe-configuration cadence that ends up consuming most of the production engineering team's time. A line cycling through 200 variants per shift produces a cadence that no manual reconfiguration regime can keep up with.
The hardware-locked vision platforms in the category were architected around a smaller scale of variant mix. The recipe per product is hand-tuned by the inspection engineer. The threshold values, the contrast settings, the lighting compensation, the region-of-interest masks — each of these is configured by a human at deployment time and maintained by a human at changeover time. The architecture works on a line running ten to fifty variants. It runs out of operator hours on a line running eight hundred to eight thousand.
The supplier ran into this constraint as the customer base diversified across multiple OEM platforms and multiple model years. The inspection station became the bottleneck on every product changeover. Operators were reconfiguring recipes during the changeover window, which extended the changeover and reduced the line's overall equipment effectiveness. Defects from the prior product family occasionally carried into the new product family because the inspection had not been fully re-keyed. The throughput on the affected lines dropped to roughly 60 units per hour despite the bundled-vendor hardware that should have run at twice that rate.
The line was not under-equipped. It was running on the wrong architecture for the variant scale it had grown into. The reconfiguration overhead was eating the deployment.
What the bi-directional PLC integration actually does
The architectural change that makes the 8,000-variant deployment work is the bi-directional integration between the inspection layer and the production-line PLC. The PLC owns the product-changeover state. The inspection layer subscribes to the changeover event. The inspection model and the inference parameters auto-switch when the line cuts over to the next variant.
The mechanism is concrete. The PLC's product-recipe register holds the current product identifier. The inspection layer reads the identifier through an industrial protocol on the local network — Modbus TCP, EtherNet/IP, or Profinet, depending on the controller — and selects the inference configuration that corresponds to that identifier from the on-device library. The configuration includes the model weights for that variant's good distribution, the threshold settings for the variant's acceptable variation, the defect-class taxonomy for the variant's spec, and the audit-trail metadata for the LOT data the MES is recording.
The result is that the human operator's role in the changeover collapses. The operator initiates the product change at the PLC HMI as part of the standard changeover workflow. The inspection station auto-switches in the background, with no operator action and no reconfiguration window. The line continues at production rate. The audit trail records the product change, the inspection-configuration change, and the resumption of inspection events under the new variant's identifier — all timestamped, all auditable, all recoverable.
This is the architectural pattern that allows the same hardware deployment to run across 8,000 variants without the configuration overhead that would have scaled with the variant count. The variant scale becomes a property of the on-device library, not a property of the human reconfiguration budget. The Production Equipment Integration capability is also what produces the audit trail that survives the IATF 16949 audit we covered in detail in the post on AI quality inspection for APAC automotive manufacturing, with the same data path that supports the broader MES integration we wrote about in the post on connecting AI vision into MES and ERP infrastructure.
The single-camera substitution
The second architectural simplification on the deployment is the camera count. The prior hardware-locked vision platform had been specified with a two-camera, two-light setup to handle the mixed-material parts on the line — metal-and-plastic assemblies, metal-and-rubber components, and the reflective-and-matte surface combinations that any single-light single-camera configuration would have struggled with. The bundled-vendor logic was to throw more sensor coverage at the problem.
The HyperQ AI Vision deployment used one 12-megapixel industrial camera with structured illumination. The learned model handles the mixed-material surface response inside the inference layer rather than requiring multiple sensor geometries to disambiguate. The capital cost on the camera and lighting line drops by roughly a half. The maintenance burden drops with the camera count. The deployment footprint shrinks at the inspection station, which matters on a line where the station has to fit between specified production-machinery clearances.
The single-camera substitution is also the architectural pattern that generalises. The Semiconductor Parts customer (Client B) is the cleanest version of the same pattern at a different scale. The Korea plant of a Japanese semiconductor parts vendor was facing a similar bid pattern — the hardware-locked vendors had proposed an expensive 3D vision rebuild as the answer to the irregular defect signatures on small product geometries; the alternative AI vendors in the bid had echoed the 3D recommendation. HyperQ AI Vision delivered the inspection on a 2D vision setup at roughly a third of the proposed 3D capital cost, with the on-site setup completed in two days. The architectural lesson is the same: the learned model absorbs the variation that the hardware-bundled platforms try to solve through more hardware.
What the throughput numbers actually mean
The 270-units-per-hour rate is what makes the deployment economically defensible against the manual-inspection baseline at 40 units per hour. The 6.75-times throughput ratio resolves the headcount-replacement arithmetic at almost any reasonable wage rate. The four-hundred-plus percent improvement in daily output that the deployment delivered against the prior bundled-vendor inspection station is the other side of the same number — the line ran four times as much production through inspection on the same shift coverage that the prior system had supported.
The throughput is not the result of a more accurate model. The detection accuracy on the variant mix runs at 99 percent on most defect classes and at 99.9 percent on a specific semiconductor inspection subset on adjacent lines. The throughput is the result of the architectural changes above — the auto-switching that eliminated the changeover-driven reconfiguration burden, and the single-camera substitution that simplified the inspection station's mechanical and optical profile. Each removed a class of operational overhead that had been eating the bundled-vendor deployment's effective throughput.
The 60-units-per-hour rate the prior hardware-locked microscope was running at is also worth naming explicitly. The platform itself was capable of higher rates on paper. The deployment was running at 60 because the reconfiguration overhead between product variants was extracting time from every shift. The same hardware on a different architecture would not have produced the 270-units-per-hour rate; the architecture had to change for the throughput to reach what the line was structurally capable of.
What the deployment looks like at the level of operations
The on-site deployment ran two days. Day one was the camera installation, the structured-illumination configuration, the PLC integration testing, and the initial inference deployment against the variant library that had been prepared in the weeks before. Day two was the validation against the customer's labelled defect samples, the audit-trail configuration against the customer's MES schema, and the operator-side training on the review interface.
The training-data preparation in the weeks before deployment was concrete. The customer's QA team captured roughly 1,000 images per product family of acceptable variation under the line's actual lighting and camera conditions, with the defect examples drawn from the historical reject samples the team had retained from prior production. The model was trained against the captured good distribution and the seed defect set, with the variant-conditioning configured so that the inspection model auto-switches against the PLC's product-change signal.
The handover to the customer's QA team after go-live was the operational mechanism that has held the deployment over the years since. New defect types observed on the line are captured by the QA team, labelled on the review screen, validated against a held-out sample, and incorporated into the next retraining cycle. The platform supplies the labelling tools and the model versioning. The vendor relationship is the platform and the model; the data is the customer's.
What you can verify before any commitment
The 8,000-variant pattern is answerable in advance. Send a representative sample of inspection data covering the variant range the line currently produces, the PLC product-change signal map, the current changeover overhead the line is running, and the inspection-throughput history under the existing setup. Within two weeks, we return four artefacts. A confusion matrix per defect class on a representative variant subset of your data, with false-positive and false-negative rates measured against your labels. The variant-onboarding cost in image-count and engineering hours derived from your data rather than a vendor average. A PLC integration map showing the protocol stack and the signal flow from the controller to the inspection layer on your specific architecture. A written throughput model comparing the prior baseline against the deployment, with the architectural sources of the throughput uplift named line by line.
Deployment timeline runs four to eight weeks from contract signing to live operation, with two days on-site for installation and PLC integration. Hardware footprint runs 30 to 50 percent lower than hardware-locked vision ecosystems. The retraining workflow is owned by the customer's QA team after handover, which keeps the SPC and audit-trail control under direct supplier ownership.
The 8,000-variant line is not a harder version of the 8-variant line. It is a different architectural problem, and the deployment that closes the gap is the deployment built around the architectural difference rather than around a faster version of the same recipe-configuration regime.