Case Study: Burn-Through Detection Across 6 Agglomeration Machines

30.09.2026

Table of contents

The operational risk came from delayed or missed defects during manual observation.

In agglomeration processes, quality depends on something deceptively simple: stable air flow through the burden layer. When that layer is disrupted, a burn-through event occurs, and sintering quality drops with it. Left uncaught, a burn-through doesn’t just produce a bad batch — it can compound into equipment strain and a run of low-quality agglomerate before anyone downstream notices.

The trouble is that catching a burn-through has traditionally meant someone watching the process. That works, until it doesn’t. People blink, rotate shifts, get pulled onto other tasks, and cover a limited number of pallet zones at a time. This case looks at how a computer vision system was built to watch six agglomeration machines continuously, catch burn-through events as they start, and get that information to an operator fast enough to matter.

Why Manual Observation Wasn’t Enough

Before this system, burn-through detection depended entirely on visual observation — an operator watching the burden layer and recognizing the early signs of disruption. That dependency created three compounding problems.

First, coverage was inherently limited. A person can watch one zone closely, or several zones loosely, but not six machines with the same level of attention at all times. Second, response was delayed by human factors — fatigue, attention lapses, and the simple fact that a person can’t watch a screen without blinking or looking away. Third, there was no structured record of what happened. An event that was caught relied on someone remembering to log it accurately; an event that was missed left no trace until its consequences showed up in output quality.

The result was a production environment where the most damaging events — the ones with the most bearing on quality and equipment health — were being detected inconsistently, at a delay that varied entirely on who was watching and how alert they were in that moment.

How the System Works

The system replaces manual observation with continuous video monitoring across all six machines, structured around a clear sequence: coverage, detection, context, alerting, and a historical record.

Camera Coverage Across Six Machines

The foundation is straightforward but non-trivial at this scale: continuous video coverage of the pallet zones across all six agglomeration machines simultaneously. Rather than a person choosing where to look at any given moment, every machine gets the same level of attention, all the time. This is what makes the rest of the system possible — you can’t detect an event you’re not watching for, and a six-machine operation means six independent, ongoing production processes.

Real-Time Event Detection

With coverage in place, the system analyzes the video streams for the visual features that indicate a burn-through — the same features an experienced operator would learn to recognize, but applied consistently and without the gaps that come from divided attention. Detection happens in near real time, which matters because a burn-through event doesn’t announce itself with a single clear signal; it develops, and catching it early is what turns a manageable adjustment into an avoided quality loss.

Event Context: Aggregation, Machine, Time, and Location

A raw detection isn’t especially useful on its own — what makes it actionable is context. The system aggregates burn-through events and links each one to the specific machine, the time it occurred, and its location within the pallet zone. This turns a bare “something happened” signal into a record an operator or process engineer can actually act on: which machine, where on the pallet, and when it started.

Alerting the Right People, Immediately

Once an event is detected and contextualized, the system sends an instant alert to operators and dispatchers. This is the step that directly addresses the original risk — a burn-through caught by a camera but not communicated to anyone is no better than one that was missed entirely. The alert has to reach a person while there’s still time to respond, not after the event has already run its course.

A Structured Historical Record

Every event, along with its machine, timing, and location data, is stored for further analysis. This closes the loop between catching an individual event and understanding the process over time — patterns across machines, recurring problem zones, or trends tied to specific operating conditions all become visible in a way they simply couldn’t be when the only record was whatever an operator happened to write down.

From First Sign to Operator Alert

The practical value of this system comes down to a short window of time: how long it takes from the first visual sign of a burn-through to an operator actually knowing about it. In this system, that window is under 5 seconds — detection, context, and alert generation happening fast enough that the delay is no longer the bottleneck it was under manual observation.

What the Numbers Show

Three figures anchor this case, alongside the qualitative shift from manual to continuous monitoring:

6 machines — the full scope of coverage, monitored simultaneously rather than sequentially or selectively.

Under 5 seconds — event latency, from the first visual indication of a burn-through to the alert reaching an operator.

96% or higher — detection coverage of actual defects, a figure that reflects consistent, continuous attention rather than the variable coverage of manual observation.

Real-time alerting — the mechanism that turns detection into action, ensuring an event reaching the system also reaches a person able to respond to it.

Seeing It in Practice

On the floor, this looks like continuous camera footage of each pallet zone, with the system flagging a burn-through the moment its visual signature appears — an annotated frame showing the detected event, tagged with an identifier and confidence score, tied to the specific machine and location where it occurred. A simple timeline view makes the value concrete: the gap between the first visual sign of disruption and the alert landing with an operator is a matter of seconds, not the unpredictable delay that comes with waiting for someone to notice.

Where This Leads

If part of your process still depends on someone watching a screen to catch a visual anomaly — a burn-through, a similar disruption, or any defect that shows up visually before it shows up in output — the question is whether that dependency is still serving you, or whether it’s the reason certain events keep getting caught late.

We’re glad to discuss a visual process anomaly that currently relies on continuous human observation, and what it would take to bring the same kind of coverage, detection speed, and structured alerting to your specific process.

Click to rate this post!
[Total: 0 Average: 0]