Most production floors already have cameras. The question is whether those cameras are generating intelligence or just recording footage that no one watches. A real-time production monitoring with AI setup built on existing CCTV infrastructure costs a fraction of a greenfield sensor deployment and can be live in four to eight weeks on a typical shop floor.
This guide covers how to design, deploy, and validate a real-time production monitoring system using cameras you already own.
What does real-time production monitoring require from existing cameras?
Not every camera on a production floor is usable for monitoring without adjustment. Before deployment, audit your existing infrastructure against these four requirements:
Coverage angle. A camera mounted to cover a wide aisle provides poor machine-state visibility. Monitoring requires cameras positioned to observe the machine’s working area, specifically the point where product enters and exits the process, and any operator interface.
Frame rate. Most security CCTV cameras run at 15-25 frames per second, which is sufficient for state classification. Cameras running below 10fps may miss short-cycle events on high-speed lines.
Resolution. 1080p or higher is preferred. 720p works for line-level state monitoring but loses accuracy on detailed process compliance checks.
Network connectivity. Cameras need to route footage to edge processing hardware. In most plants, this is already in place through existing NVR networks.
In practice, 60-70% of cameras in a typical plant can be repurposed for production monitoring without repositioning. The remaining 30-40% may need angle adjustments or supplementary cameras at specific machine stations.
Step-by-step deployment sequence
Week 1: Baseline audit. Map every machine and line against your camera inventory. Identify coverage gaps. Define the monitoring scope: which machines, which metrics, which thresholds matter most for your OEE improvement target.
Week 2: Edge hardware installation. Place edge computing devices on the network segments serving the target cameras. For most deployments, one edge device handles 8-12 camera feeds simultaneously. No PLC connections are required at this stage.
Week 3: Model calibration. AI models need to learn each machine’s visual signature for its running, stopped, and transition states. On a well-lit floor with consistent machine positioning, calibration takes 4-8 hours per machine type, not per machine. A press shop with 20 presses of the same model calibrates once.
Week 4: Dashboard configuration and threshold setting. Build the OEE dashboard around your production team’s actual decision points. Define alert thresholds based on your current baseline, not theoretical targets. An alert for “OEE below 85%” on a line that averages 72% is useless; an alert for “OEE dropped more than 8 points in the last 30 minutes” is actionable.
Weeks 5-8: Validation and tuning. Compare AI-classified events against manual observations and shift logs. Expect 5-10% false positives in the first two weeks, reducing to under 2% after model tuning. The tuning phase is where monitoring becomes reliable enough to drive decisions rather than supplement manual observation.
What metrics should real-time monitoring surface?
At the machine level: running state (yes/no), current cycle count, cycle time versus standard, cumulative downtime by reason category, and micro-stoppage count.
At the line level: throughput versus takt target, WIP accumulation at each station, bottleneck machine identification, and shift-to-date OEE with component breakdown.
At the plant level: shift summary by line, planned versus actual output, and top five loss events by time impact.
Common deployment mistakes to avoid
Setting too many alerts at launch. Start with three to five critical alerts per line. Expand after the team has built the habit of responding to them. Alert proliferation is the single fastest way to make a monitoring system irrelevant.
Measuring machines without context. A machine running at 80% utilisation on a line where the downstream station runs at 60% is not a problem. Monitoring without a constraint map generates attention on the wrong machines.
Skipping the shift handover integration. Real-time monitoring data is most valuable when it structures the shift handover conversation. If the outgoing supervisor hands over monitoring data to the incoming supervisor, the monitoring system becomes part of operations rather than a parallel reporting layer.