Predictive Quality in Manufacturing: What Siemens Changed
// SUR CETTE PAGE 09
- 01 The Siemens bottleneck was a quality process that worked
- 02 Predictive quality starts before the defect exists
- 03 Why 100% inspection can still be the wrong operating design
- 04 The model needs connected process context
- 05 Accuracy is not the business metric
- 06 A safe route from pilot to production
- 07 The real lesson from Siemens
- 08 FAQ
- 09 Sources
The most valuable quality-control project may not inspect products faster. It may change which products need the final inspection at all.
That is the operational lesson from Siemens’ Electronics Works Amberg. The factory used data generated during PCB production to predict whether solder joints were fault-free and whether an end-of-line X-ray test was necessary. The test had become a bottleneck. A model built around upstream process conditions gave the team another way to protect quality while increasing flow.
The distinction matters. Much of the conversation about AI quality control in manufacturing focuses on cameras replacing human visual inspection. Amberg shows a different pattern: use the production process itself as evidence. Instead of waiting until the final station to discover whether a product is good, estimate quality from how it was made.
That can release capacity, reduce unnecessary testing and improve visibility. It also creates a new responsibility. A manufacturer must know when the model is confident, when conventional inspection remains mandatory and how to detect when process conditions have changed.
Predictive quality is therefore an operating-model decision before it is a modelling exercise.
The Siemens bottleneck was a quality process that worked
The Amberg plant produces SIMATIC industrial automation products. Siemens reports roughly 17 million components per year, around 1,200 product variants and a quality standard of 99.9990%. The factory evaluates tens of millions of process and product data points while handling hundreds of production changeovers each day.
Its PCB process included X-ray testing to verify solder contacts. The inspection performed an important job, but it took long enough to constrain production throughput. Siemens stated that adding another X-ray machine would have required approximately €500,000 in capital expenditure plus integration into the manufacturing environment.
This is a useful starting point because the process was not obviously broken. The quality station protected a demanding product standard. The question was whether every PCB required the same inspection path when upstream data already contained evidence about likely quality.
Siemens collected information from solder-paste printing, solder-paste inspection, pick-and-place, the oven and automated optical inspection. The team trained an AI algorithm on those process parameters and deployed the resulting model at the edge. The model predicted whether solder joints were fault-free and, consequently, whether the end-of-line X-ray test was needed.
The production constraint gave the project a measurable purpose: relieve X-ray capacity without weakening quality assurance. That is much stronger than beginning with “we need an AI use case.”
Predictive quality starts before the defect exists
Traditional end-of-line inspection answers a late question: does this finished product conform to requirements?
Predictive quality asks an earlier one: given the material, equipment settings, environmental conditions and sequence of events, how likely is this unit to meet those requirements?
Tercan and Meisen’s systematic review defines predictive quality as using machine-learning or deep-learning methods to estimate product-related quality from process and product data, with the aim of deriving quality-enhancing insights. Their review covered 81 scientific publications from 2012 to 2021 and found applications across processes including cutting, joining, forming and additive manufacturing.
The data can include temperatures, pressures, tool forces, vibration, cycle times, machine states, recipes, material batches, operator interventions and intermediate measurements. The target remains a real quality outcome: a defect class, dimensional measurement, surface characteristic, weld strength or pass/fail result.
The model is useful only when its estimate arrives early enough to change a decision. That decision could be to adjust a parameter, stop a machine, quarantine a batch, route a part to deeper inspection or allow a low-risk unit to continue.
In Amberg, the operational action was selective end-of-line testing. In another plant it may be in-process adjustment rather than inspection routing. The technology is similar; the value depends on the workflow.
Why 100% inspection can still be the wrong operating design
“Inspect everything” sounds safer than “inspect selectively.” In regulated, safety-critical or contractually controlled processes, it may also be mandatory. Predictive quality should never be used to quietly bypass those requirements.
Outside those constraints, however, blanket inspection can create three problems.
First, it treats all products as if they carried equal risk. A stable unit produced within a well-understood process window receives the same testing effort as one produced after a material change, equipment alarm or unusual parameter combination.
Second, end-of-line inspection finds the result after value has already been added. If an upstream condition is creating defects, the plant can continue producing bad material until the final station reports it.
Third, the inspection system itself can restrict throughput. Adding production capacity upstream has limited value if every unit queues at the same final test.
Predictive quality introduces prioritisation. High-confidence, low-risk units follow the approved reduced-inspection path. Uncertain or high-risk units receive full inspection. The operating policy determines the thresholds; the model supplies evidence.
This is not a philosophical argument against testing. It is a case for allocating quality resources according to measured risk.
The model needs connected process context
The hardest part is rarely choosing an algorithm. It is creating a trustworthy relationship between upstream process history and downstream quality results.
For each unit or batch, teams need to connect the events that describe how it was produced with the inspection result that says what quality was achieved. Timestamps alone are often insufficient. Product identifiers, routing steps, machine identifiers, tool states, material lots and recipe versions must line up.
Many factories hold those signals across PLCs, SCADA historians, MES platforms, quality-management systems, laboratory systems, maintenance records and spreadsheets. An ERP may record the production order and inventory movement without preserving the high-frequency process evidence needed for quality prediction. This is one of the practical limitations of treating an ERP as the whole operating picture.
A useful data foundation needs:
- Traceability. Every quality label can be joined to the correct process history.
- Context. Tags and measurements have business meaning, units and valid ranges.
- Time integrity. Clocks, sequences and changeovers are represented correctly.
- Representative outcomes. Training data includes normal operation, known defects and unusual conditions.
- Governance. Teams know who owns each signal, transformation and quality rule.
This is where DataCore fits the problem: not by replacing plant systems, but by connecting their operational context into a governed layer that analysis can use.
Accuracy is not the business metric
A model can report impressive accuracy and still be unsafe or economically irrelevant.
Defects are usually rare. A naïve model that predicts “good” for every unit may look accurate while missing the failures that matter. Quality teams should examine false negatives, false positives, precision, recall, calibration and performance by product family or operating regime.
The cost structure matters too. A false negative may release a defective unit. A false positive may send a good unit through an unnecessary test. Those outcomes do not carry the same consequence.
The operating threshold should reflect that asymmetry. For a critical characteristic, the model may be allowed only to recommend additional inspection. For a mature, stable characteristic, it may support a reduced-inspection route after validation. When confidence is low or data is incomplete, the system should fail safely back to the established control.
NIST’s Augmented Intelligence for Manufacturing Systems programme makes the same broader point: manufacturing AI should combine data-driven methods with measurement science, physics and periodic verification. Trust comes from the system around the model, not from a single validation score.
Measure the project with operational outcomes:
- inspection utilisation and queue time;
- throughput at the constrained step;
- escaped defects and customer complaints;
- scrap, rework and first-pass yield;
- false-negative and false-positive cost;
- percentage of units routed automatically versus conservatively;
- model drift and fallback frequency.
These metrics keep quality and capacity in the same conversation.
A safe route from pilot to production
Siemens’ example came from a highly digitised factory built over years. That does not mean a mid-market manufacturer must reconstruct Amberg before starting. It does mean the pilot should begin with a bounded process and a credible data trail.
Our diagnose-first method uses the following sequence.
1. Find a quality constraint with economic weight
Look for slow inspection, expensive testing, high rework, unstable yield or a defect that is found too late. Establish the baseline in time, cost, capacity and quality.
2. Map the real decision
Specify what changes when the prediction arrives. “Show a risk score” is incomplete. Decide whether the action is to inspect, quarantine, adjust, stop or escalate.
3. Build traceability before modelling
Join process variables to actual quality outcomes at the correct unit, batch or time window. Resolve missing IDs, clock errors and undocumented transformations.
4. Establish a shadow period
Run predictions without changing production. Compare them with established inspection results across normal runs, changeovers, maintenance events and unusual materials.
5. Introduce conservative decision thresholds
Begin where uncertainty is lowest and the fallback is clear. Preserve mandatory inspections and require human approval where risk warrants it.
6. Monitor the operating system
Track data availability, prediction confidence, drift, overrides and outcomes. Retraining is a controlled change, not an invisible background event.
7. Expand only after the workflow holds
A validated model in a notebook is not a production capability. Scale after the data pipeline, decision rule, ownership and fallback have worked together.
The real lesson from Siemens
The headline is not that AI eliminated inspection. Siemens used process data to make a better decision about inspection.
That framing protects manufacturers from two common errors. The first is buying a vision system because “quality control” sounds like a computer-vision problem. The second is training a model without redesigning the bottleneck it is meant to improve.
Amberg began with a concrete constraint, connected upstream evidence to a quality outcome, deployed the model close to production and used its prediction inside a defined route. Capacity and quality were evaluated together.
For manufacturers with constrained test stations, costly destructive testing or long feedback loops, predictive quality can be a strong first industrial-AI application. The opportunity becomes real when the team can answer four questions:
- Which decision will change?
- Which process signals explain the result?
- What error can the business safely tolerate?
- What happens when the model is uncertain?
The answers form the operating design. The algorithm comes after them.
FAQ
What is predictive quality in manufacturing?
Predictive quality uses process and product data to estimate a unit’s likely quality before or during production. The estimate supports an operational action such as parameter adjustment, selective inspection, quarantine or escalation.
How did Siemens use AI for quality control at Amberg?
Siemens combined data from several PCB-production stages and trained a model to predict whether solder joints were fault-free. The prediction helped determine whether an end-of-line X-ray test was necessary, relieving a documented inspection bottleneck.
Does predictive quality replace end-of-line inspection?
Not automatically. Mandatory, safety-critical and high-risk tests remain in place. A validated predictive system can focus inspection according to risk, with conservative thresholds and a conventional fallback whenever confidence or data quality is insufficient.
What data is needed for manufacturing quality prediction?
Useful inputs may include machine parameters, sensor readings, material lots, recipes, timestamps, tool states and intermediate measurements. Those records must be traceable to a reliable final quality outcome at unit or batch level.
How should a manufacturer start?
Start with one costly or capacity-constrained quality decision, measure its baseline and run the model in shadow mode against existing controls. Change the workflow only after the model, data pipeline, thresholds, ownership and fallback have been validated together.
Sources
- Siemens, Electronics Works Amberg.
- Siemens, How we applied Industrial Edge and AI in our factory in Amberg.
- Hasan Tercan and Tobias Meisen, Machine learning and deep learning based predictive quality in manufacturing: a systematic review, Journal of Intelligent Manufacturing, 2022.
- NIST, Augmented Intelligence for Manufacturing Systems.
- NIST, 2026 Roadmap on Artificial Intelligence and Machine Learning for Smart Manufacturing.
- NIST, Industry Forum for Monitoring, Diagnostics, and Prognostics for Manufacturing Operations, 2024.
Book a free AI assessment to identify where process data could remove a quality or throughput constraint in your operation.
PUBLICATION ORIGINALE
Cet article a d'abord été publié sur embiggenx.com