Eleven thousand five hundred and twenty. That is the number of units the Auto Parts customer (Client A) runs through inspection per day per production line across six lines. Ninety-nine percent detection rate across 8,000 product variants, all running on a single 12-megapixel industrial camera per station. The prior setup on each of those six lines ran two cameras and two lights per station, sourced from the hardware-locked incumbent platform. That setup was not replaced because the detection accuracy was inadequate. It was replaced because the changeover overhead had grown to consume 30 percent of production time.
The eight-thousand-SKU line is not a harder version of the eight-SKU line. The detection problem at the unit level is similar. The operational problem at the line level is categorically different: every product changeover requires the inspection station to reconfigure for the new variant's acceptable-variation profile, its defect-class taxonomy, and its optical geometry. On a hardware-locked platform where each of those configurations is hand-tuned by an inspection engineer, the per-changeover cost scales linearly with changeovers per shift. At thirty or more changeovers per shift across six lines, that cost consumes the operational efficiency the inspection station was supposed to deliver.
This post is the Client A deployment story — the problem architecture, the displacement, the PLC integration, and the numbers that resulted.
The changeover problem at SKU scale
When Client A reached 8,000 product variants across the six production lines, the inspection-changeover overhead had become the binding operational constraint. Each changeover on the prior setup required a calibration cycle on both cameras, a recipe load for the new variant, and a validation run before the line could resume production. Average changeover time: 45 minutes per line, per product change. At a modern automotive parts operation with frequent multi-OEM scheduling, 30-plus changeovers per shift across six lines is not unusual.
The math is direct. Thirty changeovers at 45 minutes each, across six lines, runs to roughly 22 hours of changeover time per shift across the facility. On an eight-hour shift, that is impossible to satisfy without either drastically reducing changeover frequency (constrained by the OEM scheduling), running lines uninspected during changeover (constrained by quality requirements), or accepting significantly lower actual throughput than the line's design rate.
The first two hardware-locked vision vendors evaluated the line at 8,000 SKUs and reached the same conclusion: the auto-switching requirement at that variant scale was outside the architecture's capability. Both declined to commit to a deployment that would satisfy the changeover frequency. Client A had tried. The deployments had run at lower variant counts and performed adequately. At 8,000, the configuration overhead was the ceiling.
How PLC auto-switching changes the changeover architecture
HyperQ AI Vision's bi-directional PLC integration changes the changeover from an operator-manual task to a system-automated handoff. The production-line PLC holds the product-recipe register. When the PLC signals a product change — the same signal it uses to reconfigure every other piece of production equipment on the line — the inspection layer reads the product identifier and selects the corresponding inference configuration from the on-device library. The model weights, threshold parameters, defect-class taxonomy, and LOT-level data schema for the new variant are all on the edge device. The switch is sub-second.
The operator's changeover role on the inspection side becomes zero. The PLC changeover triggers the inspection station's reconfiguration in the background, at the same time the mechanical changeover is being completed. By the time the first part of the new variant reaches the camera, the inspection station has already reconfigured. The 45-minute engineering task becomes a background system operation.
Across six lines at 30-plus changeovers per shift, the recovered production time is the number that dominates the TCO calculation — not the hardware cost delta, not the labour savings, but the throughput that was being consumed by manual configuration overhead and is now available for production. The 270 units per hour post-deployment rate against 60 units per hour on the prior bundled system is partly attributable to the detection architecture, but a material fraction is the changeover overhead that was eating the prior system's effective throughput.
The camera consolidation
The two-camera-two-light configuration was the incumbent vendor's solution to the mixed-material inspection problem. Client A's product families include metal-and-plastic assemblies and metal-and-rubber components — surfaces with very different reflectivity profiles that a single light angle cannot simultaneously illuminate at adequate contrast for both materials. The incumbent vendor's architecture required two cameras at different angles with different lighting geometries to handle the mixed-material surfaces. Two cameras per station across six lines meant twelve cameras under the incumbent vendor's service agreement, at the incumbent's hardware pricing per unit.
HyperQ AI Vision handles the mixed-material surface in the inference layer. The model is trained against the actual range of surface variation the line produces — metal, plastic, rubber, and the transition zones between them — under a single structured illumination setup. The optical geometry is calibrated once for the line's actual product range rather than once for metal and again for plastic. A single 12-megapixel camera per station replaced the two-camera setup on every line. The hardware cost on the camera-and-light line dropped to commodity pricing on a single industrial camera per station.
The 30-to-50 percent hardware savings versus hardware-locked ecosystems we quote as a portfolio-level figure was achieved at the higher end of that range on this deployment, given the two-to-one camera-count reduction on top of the commodity-versus-proprietary pricing delta. The capital cost of the initial six-line deployment was significantly below what the equivalent hardware-locked setup would have cost at standard pricing.
The numbers that resulted
Six lines producing 11,520 units per day each at 99 percent detection. The client subsequently expanded to six additional lines on the same platform — twelve lines total, the same architecture, the same PLC auto-switching mechanism scaled to 8,000 variants across the full twelve-line footprint. The expansion took four weeks from contract signing to live production, with two days on-site for each group of three lines.
The detection rate at 99 percent across 8,000 variants represents a different kind of achievement than 99 percent on a single-variant, well-characterised defect class. At 8,000 variants, the model is generalising across surface profiles, defect-class distributions, and acceptable-variation envelopes that span the full product range. The anomaly-detection architecture — model trained on the good distribution per variant, flagging anything outside it — handles the generalisation that a per-class supervised model would need 8,000 separate training cycles to approximate.
The resolution at 10 micrometres on Full HD imaging ensures that the defect classes that matter on precision automotive parts — micro-scratches at tolerances measurable in microns, burrs at the edge of machined features, surface contamination at the sub-millimetre scale — are within the optical resolution the camera and inference combination can reliably detect.
What the displacement pattern tells the next buyer
The pattern at Client A repeats across the Hypernology portfolio on high-mix lines. The displacement from hardware-locked platforms is not driven by detection accuracy superiority on a specific defect class — the incumbent platforms detect adequately on the defect classes they were configured for. It is driven by the operational ceiling the recipe-configuration architecture imposes at high variant counts, and by the auto-switching capability that removes that ceiling.
For buyers evaluating this at the procurement stage, the right question is not "what detection rate does each platform achieve on defect class X." The right question is "what detection rate does each platform achieve on defect class X across the full product range, including the variants that were introduced after the initial deployment, without a reconfiguration event." The answer on the second question is what the Client A numbers are measuring. We covered the broader evaluation framework in the post on how to evaluate AI vision vendors without proprietary lock-in.