Yes, you can predict scrap before it happens, and modern machine learning makes it practical for most factories running MES-connected equipment. Napovedovanje izmeta (Slovenian for “scrap prediction”) uses process data, production models like XGBoost, CatBoost and decision trees to flag at-risk production cycles before they finish. A Slovenian master’s thesis on Talum’s aluminium casting lines demonstrated this in a real factory setting, and the approach translates to most discrete and process manufacturing.
Start with three things this week:
Done properly, this typically cuts undetected scrap incidents and shortens the time between a defect forming and someone noticing it, with Mestric’s real-time tracking acting as the delivery layer for the alerts.
Scrap prediction works when clean cycle-level data, an interpretable model and a trusted alert pathway all operate together, not in isolation.
| Point | Details |
|---|---|
| Start with tree ensembles | Random forests and XGBoost balance accuracy and interpretability better than deep neural networks for most factories. |
| Fix your data first | Cycle-level PLC integration and consistent scrap labelling matter more than algorithm choice. |
| Pilot on one line | Test predictions against real outcomes for 4 to 8 weeks before touching plant-wide rollout. |
| Choose thresholds by cost | Bias towards recall when missed defects cost more than false alarms. |
| Mestric closes the loop | Its MES connects PLC data to real-time alerts, turning predictions into operator action on the shop floor. |
A DKUM-published master’s thesis built predictive models for Talum, the Slovenian aluminium producer, aiming to reduce izmet (scrap) in casting production. The thesis used exploratory data analysis, feature engineering from process parameters, and k-fold cross-validation to test several algorithms against real production records.
The researchers reported that tree-based and neural network approaches, including decision trees, deep neural networks, XGBoost and CatBoost, achieved strong accuracy predicting scrap in aluminium casting. A separate steel production analysis found a genetic-programming model outperformed simple linear regression by roughly 1.57 times on its test dataset, a reminder that non-linear methods often earn their complexity in scrap prediction work.
Three lessons carry over to almost any factory:
Pro Tip: Before you touch an algorithm, replicate the thesis’s exploratory data analysis step on your own data. You will usually find your biggest quality gaps before you find your biggest modelling gains.
Most factories should start with tree ensembles, not neural networks. Decision trees and random forests handle mixed sensor and categorical data without heavy pre-processing, and they show you which features drove a prediction, something operators actually trust on the shop floor.
XGBoost and CatBoost push accuracy further once you have clean, labelled data, often matching or beating the accuracy reported in the Talum thesis for casting scrap. Deep neural networks can outperform both when you have very large datasets and complex, non-linear interactions between process variables, but they cost more to maintain and are harder to explain to a line supervisor asking “why did it flag this batch?”
| Model family | Interpretability | Data needed | Maintenance effort |
|---|---|---|---|
| Logistic regression | High | Low | Low |
| Decision trees / random forest | High | Moderate | Low to moderate |
| XGBoost / CatBoost | Moderate | Moderate to high | Moderate |
| Deep neural networks | Low | High | High |
Begin with a random forest or logistic regression baseline. Move to XGBoost only if accuracy plateaus and you have the labelled volume to support it.
Pro Tip: Explainability isn’t a nice-to-have here. If an operator can’t see which parameter tripped the alert, they’ll ignore the next ten alerts too.
Reliable scrap forecasting, sorry, reliable scrap forecasting for factories depends entirely on the quality of what you feed the model. Weak inputs produce a model that looks precise and predicts nothing useful.
Capture these signals as a minimum:
Build your pipeline in this order:
Scrap events are usually rare compared to good production, so class imbalance needs deliberate handling: resampling techniques or cost-sensitive training rather than a plain accuracy target. Direct PLC capture through your MES matters because batch-level logs hide the micro-fluctuations that actually cause defects, and cycle-level resolution is what separates a useful model from a decorative one.
Accuracy alone will mislead you. If only 3% of cycles produce scrap, a model that predicts “no scrap” every time scores 97% accuracy and catches nothing.
Precision tells you how many flagged cycles were genuinely scrap; recall tells you how many actual scrap events the model caught. For scrap detection, recall usually matters more, missing a real defect costs more than double-checking a false alarm, but pushing recall too far floods operators with noise. F1 and AUC give you a single number to compare model versions over time.
| Metric | What it measures | Best used for |
|---|---|---|
| Precision | Share of flagged cycles that were true scrap | Reducing false alarms |
| Recall | Share of actual scrap events caught | Minimising missed defects |
| F1 score | Balance of precision and recall | Comparing model versions |
| AUC | Overall separability of scrap vs non-scrap | Threshold tuning |
Set your decision threshold based on cost, not convenience: if a false negative costs ten times more than a false positive, bias the threshold towards recall. Validate with time-series splits rather than random k-fold alone, since production data drifts, and always hold out a genuinely unseen production period as your final test. Once the model performs, translate results into material cost saved and rework hours avoided so finance sees the same numbers engineering does.
Moving from a promising model to a working plant system takes discipline, not speed. Rush the rollout and you’ll get an alert system nobody trusts by week three.
Each phase needs a gate: a data quality gate before modelling starts, a baseline accuracy gate before the pilot goes live, and a safety gate before any closed-loop action touches equipment automatically. Assign a data engineer for pipeline work, an automation engineer for PLC integration, a process engineer or line manager who understands the physical process, a QA lead for label accuracy, and an IT/OT liaison to keep both worlds talking. Present every prediction as a recommendation for a human to check first: the Talum research itself treated predictions as triggers for operator review, not unsupervised machine control, and that framing earns operator buy-in faster than any accuracy figure will.
Most failed pilots die from data problems, not algorithm problems. Sensor drift, where a calibration slips slowly over months, can quietly poison months of training data before anyone notices the pattern has shifted.
Watch for these specific failure modes:
Retrain on a fixed schedule rather than waiting for performance to visibly degrade, and monitor prediction distributions for drift between retraining cycles. Set conservative thresholds early and loosen them only as operator trust grows, otherwise alert fatigue kills adoption faster than any technical flaw. When an early warning fires, pair it with a targeted mechanical check, a press force balance or guide wear inspection, because many real-world defects trace back to mechanical interactions a sensor alone won’t catch.
Pro Tip: An alert that fires correctly but too often is functionally the same as an alert that never fires. Tune for precision on the alerts operators actually act on.
The models rarely fail on the shop floor. The rollouts fail when nobody trusts the alert enough to act on it. A rapid data audit that flags gaps in week one saves months of wasted model tuning later, and operators who help label early scrap events end up defending the system to their own colleagues.
A model sitting in a data scientist’s notebook doesn’t stop scrap. Mestric is built to close that gap: it connects directly to your machinery, pulls PLC signals in real time, and displays quality KPIs alongside AI-driven alerts your line supervisors can actually act on during a shift, not after it.
Three things change once predictive analytics runs inside your MES rather than beside it:
If you want to see how connected machinery and real-time analytics work together on an actual production line, book a Mestric demonstration and bring your own process data to the session.
Can small manufacturers use napovedovanje izmeta without a data science team?
Yes, provided your MES already captures PLC signals. A tree-based baseline model needs less expertise than a neural network, and many MES platforms now package the modelling layer directly into the dashboard.
How much historical data do you need before training a model?
It depends on scrap frequency rather than calendar time. If defects are rare, you need enough cycles to capture dozens of scrap events, not just months of general production data.
Does napoved izmeta replace manual quality inspection?
No. The Talum research and industry practice both treat predictions as a trigger for operator review, not a replacement for physical inspection or mechanical checks.
What is the realistic timeline from pilot to full production use?
Expect roughly three to five months from data audit to a working single-line pilot, with closed-loop automation only after that pilot proves reliable over multiple production runs.
Which excrement prediction methods, sorry, which scrap prediction methods handle multiple product variants best?
Ensemble models like XGBoost or CatBoost generally cope better with product mix changes than a single decision tree, provided the training data includes examples from each variant.
069 763 552