Predicting Production Defects with Machine Learning

In many factories, defects only show up at the end of the line or in the quality lab. By then the raw material, energy, and machine hours are already spent. If test results arrive hours later, a whole batch may already have been produced with the same problem.

Predicting production defects with machine learning moves that warning earlier. A model learns from the process data you already record, such as temperature, pressure, speed, and raw material, and estimates the risk of a defect while the product is still being made. This article covers how it works, the data you need, the steps to build a model, and its limits.

How defect prediction works

Product quality depends on the process conditions at the time the product was made. When process data and quality results are recorded together, machine learning can learn the link between them:

1. Collect process data from sensors and PLCs, with timestamps or batch numbers.
2. Link it to quality results, such as pass or fail at inspection, or lab test values for the same batch.
3. Train a model to recognise combinations of process conditions that often end in defects.
4. Run the model during production, so every batch or period gets a risk score before its test results come back.

For quality values usually measured only in the lab, such as moisture content or viscosity, a model can also estimate the value continuously from process data. This approach is often called a soft sensor.

Example processes and the data they use

The table below shows general examples, not case studies. The variables that matter always need confirming with the process team at your plant.

Process	Process data	Quality result predicted
Plastic injection moulding	Melt temperature, injection pressure, hold time, mould temperature	Shape defects, such as parts that are not completely filled
Oven drying	Temperature, humidity, conveyor speed	Product moisture content
Batch mixing	Temperature, mixing time, raw material lot	Viscosity or lab test results
Welding	Current, voltage, weld time	Joint strength test results

The data you need

• Process data with accurate timestamps. Clocks on sensors, PLCs, and servers must agree. A gap of a few minutes can pair process data with the wrong batch.
• Quality results that can be matched to a batch. This is the most common obstacle: test results still sit on paper or in spreadsheets without a clear batch number or production time. The guide to digitising production logsheets covers how to fix that.
• Enough examples of defects. A model learns from defect events. If defects are very rare, start with anomaly detection on the process, which only needs to learn normal behaviour.
• Production context. Product type, raw material lot, shift, and machine setting changes. Without this context, a model may mistake a product changeover for a sign of defects.

Steps to build the model

1. Pick the single most expensive defect. Look at reject data from the last few months and start with the defect that costs the most, not all defects at once.
2. Collect and link the data. Make sure process data and quality results for the same period exist and can be matched.
3. Train and test on historical data. Test the model on a period it was not trained on, so the results reflect real conditions.
4. Run it alongside QC. For a few weeks, compare the model's predictions with actual inspection results before asking operators to act on the score.
5. Monitor and retrain. New raw materials, serviced machines, or new products can change the pattern. Retrain the model when its accuracy drops.

Do not be fooled by accuracy

As an illustration, suppose 2 in 100 products are defective. A model that always answers "not defective" is right 98% of the time, yet never catches a single defect. So judge a model by two questions: of all the warnings raised, how many were real defects (precision), and of all defective products, how many were flagged (recall). The balance between the two comes down to cost: which is more expensive, stopping the line for a false alarm or letting a defect through.

Limits to understand

• A model gives probabilities, not certainty. Quality inspection is still needed, especially at the start.
• A model only reads causes that are recorded. If defects are driven by something unmeasured, such as humidity in the raw material store, predictions stay weak until that data is added.
• The best results come from working with the process team. The variables a model ranks as most important need checking for technical sense, not accepting at face value.

Frequently asked questions

How is this different from SPC (statistical process control)?

SPC usually monitors each parameter against its own control limits. Machine learning looks at combinations of many parameters at once and links them directly to quality results. The two complement each other.

How much data is needed?

It depends on the process and how often defects occur. What matters is not just the number of data rows, but the number of defect events recorded together with their process data. Data sufficiency should be assessed before promising any result.

Do we need to install new sensors?

Not necessarily. Many process parameters are already recorded in PLCs and can be read through a gateway. New sensors are needed only when an important parameter is not measured yet.

What about camera-based visual inspection?

That is a different approach: cameras check how the finished product looks. Prediction from process data works earlier, while the product is still being made. The two can be used together.

Predicting production defects with INCLUDE

On the INCLUDE AIoT platform, process data from sensors and PLCs comes in over MQTT, HTTP OpenAPI, or IncludeGateways for Modbus devices. Historical data can be imported through Settings, Telemetry, Import Data (Pro plan and above) without triggering alarms, so past production records can be used to train the model.

The model is built through our predictive analytics and machine learning services: starting from the business question and a data review, then testing the model against your historical data and going through the results with your team. Once running, risk scores appear on the dashboards and alarms of the same platform, and accuracy is monitored over time. If quality results are still recorded by hand, the IoT & AI software development team can build a quality data entry app linked directly to the process data.