A tier-1 automotive supplier we worked with was losing $2.4M annually to unplanned downtime on a single assembly line. Their existing dashboard showed historical OEE numbers updated hourly. The data was clean but useless for real-time decisions. By the time a dip showed up, the line had already been down for 45 minutes.
We built them an AI manufacturing dashboard that ingests sensor data at 200ms intervals, runs anomaly detection on edge devices via ONNX Runtime, and surfaces actionable alerts in Grafana with sub-second latency. In the first quarter after deployment, defect rates dropped 34% and unplanned downtime fell 52%. This post is the technical blueprint for that build.
- Data Ingestion: Apache Kafka 3.6.0 on the factory floor for sensor streams. 10 partitions per production line. Retains 7 days of raw data for replay and model retraining.
- Edge Inference: ONNX Runtime 1.16.3 on Jetson Orin NX modules. Runs a lightweight XGBoost classifier for anomaly detection. Inference latency averages 12ms per prediction.
- Time-Series Database: TimescaleDB (PostgreSQL 16 + pgai) for aggregated metrics. Handles 50,000 writes/second with 20ms query latency on 90-day windows.
- Dashboard Layer: Grafana 10.2.3 with custom React panels for real-time OEE, downtime heatmaps, and model confidence scores. Alerts via PagerDuty with 3-minute acknowledgment SLA.
Why Traditional Manufacturing Dashboards Fail
Most factory dashboards are retrospective. They show you yesterday's yield, last week's downtime, last month's OEE. By the time you see a problem in a traditional dashboard, the defect has already been produced, the machine has already failed, and you've already lost the production window.
The fundamental shift in an AI manufacturing dashboard is from reactive to predictive. Instead of asking "what happened?" you ask "what's about to happen?" This requires three capabilities that most legacy SCADA systems lack: real-time ingestion at sub-second intervals, edge inference that doesn't depend on cloud connectivity, and a feedback loop that retrains models on actual outcomes.
The automotive supplier's existing system polled PLCs every 60 seconds. That's 60 seconds of data loss per cycle. At a line speed of 120 parts per minute, they were blind to 120 parts between each poll. A single drift in temperature or vibration that lasts 45 seconds is completely invisible.
- 1
Instrument the Data Pipeline
Install edge gateways (we used Siemens IOT2050 gateways at $450/unit) that connect to existing PLCs via OPC-UA. Each gateway publishes sensor readings to a local Kafka broker every 200ms. We used Confluent's Kafka Connect with the OPC-UA source connector to avoid custom polling logic.
- OPC-UA to Kafka via Confluent MQTT Proxy or custom connector
- Schema Registry for Avro serialization (compresses sensor payloads 40%)
- Partition by production line ID for horizontal scaling
- 2
Train the Anomaly Detection Model
We trained an XGBoost classifier on 6 months of historical sensor data (temperature, vibration, torque, current draw) labeled with known fault events. The model predicts probability of imminent fault within the next 10 minutes. Feature engineering was critical: we created rolling windows of 30 seconds, 2 minutes, and 10 minutes for each sensor.
- Train set: 1.2M labeled sensor windows from 6 months of logs
- Feature vector: 48 features per prediction (16 sensors x 3 windows)
- F1 score: 0.94 on holdout test set. False positive rate: 2.3%
- Export to ONNX via xgboost.onnx for edge deployment
- 3
Deploy Edge Inference
Each production line gets a Jetson Orin NX (8GB, $499) that runs the ONNX model. The edge module subscribes to its line's Kafka topic, runs inference on each 200ms reading, and publishes predictions back to a separate Kafka topic. This decouples inference from the dashboard and keeps the factory floor operational even if the cloud database goes down.
- Inference time: 12ms average, 28ms p99
- Memory usage: 180MB resident, leaves room for model updates
- Failover: model runs locally; dashboard degrades gracefully if cloud is unreachable
- 4
Build the Real-Time Dashboard
Grafana connects to TimescaleDB which stores aggregated metrics (OEE, downtime events, defect counts by shift) and prediction confidence scores. We built custom React panels for the three most-viewed screens: live OEE gauge with 10-minute rolling average, downtime heatmap by machine and shift, and anomaly trend chart with model confidence overlay.
- Grafana 10.2.3 with PostgreSQL data source (TimescaleDB)
- Custom React panels using @grafana/data 10.2.0 SDK
- Alert rules: prediction confidence > 0.8 triggers PagerDuty with 3-min acknowledgment SLA
- Dashboard renders in under 500ms on initial load, 150ms on subsequent refreshes
- 5
Close the Feedback Loop
Every time an operator confirms or dismisses a fault alert, that feedback is written back to a labeled events table in TimescaleDB. Weekly batch jobs retrain the XGBoost model with new labeled data and compare F1 scores against the production model. If the new model performs better on a 7-day holdout window, it gets deployed automatically to the edge modules via a secure MQTT update queue.
- Operator feedback stored in alert_feedback table (alert_id, confirmed_fault: boolean)
- Weekly retrain: 30-minute Spark job on 5-node EMR cluster ($12/job)
- Automated A/B test: new model vs production on 7-day holdout. Deploy if F1 improves >= 0.02
Keep edge inference fully offline-capable
The factory floor can't stop when your cloud database has a hiccup. Default the dashboard to degrade gracefully: show historical averages and last-known predictions, but never display a blank screen. A red "cloud disconnected" banner is better than a loading spinner that never resolves.
Use TimescaleDB's continuous aggregates
Querying raw 200ms sensor data over 90 days is expensive. TimescaleDB's continuous aggregates precompute 1-minute, 10-minute, and 1-hour rollups automatically. This turns a 90-day OEE query from 12 seconds to 180ms. Worth the 15 minutes of setup.
- Raw retention: 7 days in Kafka, 90 days in TimescaleDB hypertable
- Aggregates: 1-min, 10-min, 1-hour windows with avg, min, max, stddev
- Queries against aggregates: < 200ms for any time window
Alert on prediction confidence, not just thresholds
Simple threshold alerts produce too many false positives. Instead, alert when the anomaly detection model's confidence score crosses 0.8 AND the prediction is sustained for at least 3 consecutive 200ms readings (600ms total). This filters out sensor noise and gives operators alerts they actually trust.
- Confidence threshold: 0.8 (empirically determined from 2-month production test)
- Sustain window: 3 consecutive readings x 200ms = 600ms
- Resolve alert only after 10 consecutive readings below 0.5 confidence
Model retraining must be automated and measured
Manual retraining doesn't happen. Connect your training pipeline to the alert feedback table and run it on a cron schedule. Compare new model vs production with a clear metric (F1 score) and auto-deploy if better. We use MLflow 2.8.0 to track experiments and register production-ready models.
- Auto-deploy threshold: F1 improvement >= 0.02 on 7-day holdout
- Rollback mechanism: previous model stays in S3, deployable via single API call
- Monitor for model drift: compare weekly F1 on streaming data vs training set
Design the UI for the factory floor, not the boardroom
The people who need this dashboard most are shift supervisors and maintenance leads wearing work boots. Use large fonts (minimum 18pt), high-contrast color schemes (avoid red-green for colorblind users), and touch-friendly buttons. Every screen should be readable from 6 feet away on a 24-inch monitor mounted 3 feet above the factory floor.
- Font size: 18pt minimum, 24pt for primary metrics
- Color palette: use yellow/blue instead of red/green for accessibility
- Touch targets: minimum 48x48px for operators wearing gloves
Budget for data labeling, not just infrastructure
The model is only as good as your labeled data. Expect to spend 40-60 hours per production line manually labeling the first 6 months of sensor data with known fault events. This is the single most expensive and underestimated part of the project. A good rule: spend 30% of your total dashboard budget on labeling and model validation.
- First labeling pass: domain expert + data engineer, 2 weeks full-time
- Ongoing labeling: shift supervisors confirm/deny alerts via dashboard (2 min per alert)
- Label quality monitoring: random 5% audit weekly by maintenance lead
Start with one production line, not your whole factory
A single production line gives you clean training data, a contained feedback loop, and a measurable ROI story. Prove the dashboard on one line for 3 months before scaling. In IRPR's experience, lines with the highest downtime and lowest OEE are the best candidates. The automotive supplier started on their highest-value assembly line and expanded to 4 lines within 6 months.
Building on cloud-only inference
Factory floors lose internet connectivity. Routers reboot. VPNs timeout. If your anomaly detection depends on a cloud API call, your dashboard goes dark exactly when operators need it most. Always deploy edge inference that runs locally and can queue predictions for sync when connectivity returns. The Jetson Orin NX at $499 per line is cheaper than one hour of downtime on most lines.
Using raw sensor data without feature engineering
Throwing raw temperature and vibration readings at a neural network produces a mediocre model. The signal you care about is in deltas and rolling statistics: rate of temperature change over 30 seconds, variance in vibration amplitude over 2 minutes, deviation from the 30-minute rolling average. Feature engineering is the difference between an F1 of 0.72 and an F1 of 0.94. Invest in it upfront.
Treating the dashboard as a one-time build
A dashboard without a retraining pipeline is a dashboard that gets worse every week. Sensor drift, seasonal production changes, and new fault modes all degrade model performance over time. Build the feedback loop from day one. Without it, your model's F1 score will drop 10-15% in the first 3 months as production patterns shift.
Month 1: Data Foundation
Install edge gateways on one production line. Instrument OPC-UA to Kafka pipeline. Validate data quality (sampling rate, sensor accuracy, missing values). Begin labeling 6 months of historical sensor data with your maintenance team. Full-time: 1 data engineer, 1 domain expert (shift supervisor or maintenance lead).
Month 2: Model Training & Validation
Train first XGBoost model on labeled data. Establish baseline F1 score. Run 2-week shadow mode where predictions are logged but not acted upon. Compare model alerts against actual faults. Refine feature engineering and threshold tuning. Target: F1 >= 0.85 on shadow mode data.
Month 3: Dashboard Build & Edge Deployment
Deploy Jetson Orin NX with ONNX model. Build Grafana dashboards with custom React panels. Configure alert routing to PagerDuty. Train production team on alert response workflow. Go live on one production line. Week 1-2: monitor alert quality daily. Week 3-4: reduce false positive rate below 5%.
Month 4: Feedback Loop & Optimization
Implement operator feedback capture in dashboard. Run first automated retraining job. Measure baseline OEE, defect rate, and downtime metrics. Compare against pre-dashboard 3-month average. Calculate ROI: for the automotive supplier, this month showed $80K in reduced scrap costs.
Month 5-6: Scale to Additional Lines
Expand edge gateways to 3-4 additional production lines. Deploy pre-trained models (use models from line 1 as starting point, then fine-tune on each line's first 2 weeks of labeled data). Validate that retraining pipeline handles multiple models independently. Total infrastructure cost for 5 lines: approximately $25K in hardware ($450 gateway + $499 Jetson per line).
The Dashboard That Pays for Itself
The automotive supplier's AI dashboard paid for its hardware cost in the first 10 days of operation. A single fault prediction on a $400K press that would have caused a 4-hour rebuild saved $32K in downtime and spare parts. That one alert validated the entire project.
This approach works because it respects the constraints of the factory floor: unreliable connectivity, noisy sensor data, operators who need information in seconds, not minutes. Edge inference, Kafka streaming, TimescaleDB aggregations, and Grafana dashboards form a stack that's durable, fast, and maintainable by a small engineering team.
If your manufacturing operation is losing money to downtime and defects, you don't need a data science team and a 12-month roadmap. You need a single production line, an edge gateway, and a feedback loop. IRPR builds these systems in 8-12 weeks on a fixed-price model. If you want a dashboard that actually ships, book a discovery call.
The IRPR engineering team ships production software for 50+ countries. Idea → Roadmap → Product → Release. 200+ products live.
About IRPR