Blast Furnace Vision & Analytics Platform
Furnace operators relied on aging cameras with no analytics, tracking instability events in spreadsheets after the fact.
Computer Vision • Distributed Systems • Industrial Analytics • Edge Computing • Event-Driven Architecture • High-Throughput Streaming
Background
The blast furnace is a critical system in steel manufacturing. Key health indicators like blockages and flow changes occur in extreme conditions that are difficult to observe. A missed early warning can escalate to a breakout or extended unplanned shutdown.
The existing cameras were aging and vendor-locked, failing regularly with no path to repair. Their built-in analytics were limited and unreliable, forcing operators to manually reconstruct events in spreadsheets during daily meetings. This produced inconsistent data, limited visibility into trends, and delayed awareness of issues that occasionally had safety implications.
The Solution
I replaced the camera system with a structured vision pipeline that turns video into usable process data. I owned the system architecture, detection design, and data pipeline from edge to reporting.
The system was designed to detect early signs of furnace instability and present them as clear, actionable signals. It also produces daily reports and historical trends so decisions are based on data rather than recall.
Deep Dive: System Architecture & Data Pipeline
Architecture
I structured the system so each camera runs its own C++ process handling acquisition, analysis, and video output. Each process connects to a FLIR GigE machine vision camera, runs detection and analysis, and pipes frames to FFmpeg.
Two FFmpeg outputs run per camera: one RTSP re-stream feeding the client's existing recording infrastructure, and one HLS stream for the web interface. Results are published over MQTT to a Python post-processing service that applies thresholds and writes data and events to a MySQL database.
Kubernetes isolates failures and makes per-camera scaling predictable. Each C++ process runs as its own pod, so a failure in one stream does not propagate, and adding cameras does not require re-architecting. The full stack runs on an isolated plant network.
Each camera sits in a custom enclosure designed to fit the furnace mounting points, with Peltier element cooling to handle ambient heat near the furnace shell.
Detection Approach
I separated feature extraction from learning. Raw frames alone did not produce stable results. Events were sparse, and the model struggled to learn consistent patterns across long sequences and changing conditions.
I extract simple signals from each frame, such as intensity regions, spatial patterns, and temporal changes. These features are processed in a way that reduces sensitivity to camera angle and lighting, capturing consistent furnace behavior across setups.
The neural network receives both the frame and these signals. It focuses on classification rather than extracting structure from raw pixels. This made predictions stable across all 24 cameras.
Most tuning happens in the image analysis rather than the model, so thresholds and weights can be adjusted without retraining. I built Python scripts to test parameter sets and guide tuning when conditions change or new hardware is installed.
This separation kept the system predictable, reduced retraining, simplified debugging, and made behavior easier to explain to operators.
What Didn't Work Initially
Temporal and frame-averaging approaches. Early attempts used temporal differencing for fast-moving events and frame averaging for gradual spatial intensity changes. Both produced too many false positives due to the furnace's dynamic environment.
Neural network and LSTM without structured features. Training a network on raw frames produced noisy confidence scores. Adding an LSTM for temporal memory did not help. Without structured per-frame features, events were too sparse across long sequences for the LSTM to accumulate meaningful signal.
What worked: separating feature extraction from learning. Once image analysis handled the structured inputs, the neural network only needed to learn decision boundaries rather than both spatial patterns and temporal dynamics from raw pixels. This separation delivered consistent resultsacross cameras despite varying conditions.
Challenges
Isolated deployment. The plant network has no internet access. All container images, dependencies, and updates are built on a connected machine and transferred offline. This constraint shaped the entire toolchain: local registries, offline-capable Jenkins pipelines, and scripted rollbacks for every component.
Scaling to 24 concurrent streams. The prototype validated detection on a few cameras. Scaling to 24 required measuring CPU, GPU, memory, PCIe bandwidth, and network throughput under load. After optimization network and compute resources were profiled and scaled to handle all camera streams on a single server.
Building for daily use. Dashboards, event graphs, and reporting formats went through multiple iterations driven by operator and supervisor feedback. Operators explained process behavior that clarified what detected events actually meant, which fed directly back into detection tuning. Event frequency, severity, and duration displays had to match how decisions are made during shifts and daily meetings before the system was trusted.