Computer vision for industrial safety: what it takes to run on a real site

Object detection on a clean image is a commodity. If your project is "detect whether a person is wearing a hard hat", the modelling is the easy part and it will be done in the first week.

Everything that determines whether the system is still switched on six months later happens elsewhere.

The camera is the model

Detection accuracy on a real site is dominated by physical installation, not by architecture choice. A well-placed camera with an ordinary model beats a poorly placed one with the best model available, every time.

• Angle. Cameras mounted high for theft deterrence look down at heads and shoulders — a poor view for judging whether a harness is clipped or a vest is fastened.
• Occlusion. On a working site people stand behind machinery, pallets, and each other for most of the shift.
• Lighting. Mixed daylight and sodium lamps, headlights sweeping across the frame, and shift changes at dusk are where accuracy collapses.
• Weather and lens condition. Outdoor cameras get dust, rain, spiderwebs, and glare, and nobody is assigned to clean them.
• Resolution at distance. A person forty metres away occupies too few pixels for a reliable equipment judgement, regardless of the model.

Alert fatigue kills more deployments than false negatives

A system that flags every infraction on a busy site will generate hundreds of alerts a day. Operators will mute it within a fortnight, and then it detects nothing regardless of how accurate it is.

A muted system has an effective accuracy of zero. Alert volume is a safety parameter, not a configuration detail.

The containment patterns are mostly about aggregation and consequence:

1. Aggregate rather than alert per frame. "Zone B: 14 PPE exceptions this shift, trending up" beats fourteen interruptions.
2. Escalate on persistence, not on instance. Someone unclipped for two seconds while adjusting kit is not the same as unclipped for ninety.
3. Reserve real-time alerts for genuinely immediate danger — an intrusion into an active machine zone. Everything else is a report.
4. Tune the threshold against operator tolerance, and re-check it monthly. It drifts as the site changes.

Privacy and the workforce conversation

This is the constraint that most often stops an otherwise working system, and it is rarely on the original project plan. Continuous monitoring of identifiable workers engages data protection law, and in many jurisdictions requires consultation with a works council or union before deployment.

• Detect states, not identities, wherever the use case allows. "A person in zone B without a helmet" is a far easier system to defend than one that names them.
• Decide the retention period for footage and detections deliberately, and keep it short. Indefinite retention is the default and it is the wrong answer.
• Be explicit about whether output can be used in disciplinary processes. Workforce trust collapses the first time it happens unannounced, and takes the system with it.
• Involve safety representatives during design rather than presenting a finished system. A system framed as protecting people is accepted; the same system framed as monitoring them is fought.

Why this usually runs on-premise

Streaming continuous video from twenty cameras to a cloud endpoint is expensive in bandwidth, fragile on industrial connections, and frequently prohibited outright by the privacy constraints above.

So inference generally runs on-site, which shapes the whole architecture: a smaller model, a hardware budget per camera group, an update mechanism that works over an unreliable link, and monitoring that tells you a camera has been offline for three days. Our Open Vision PPE system runs fully on-premise for exactly these reasons — boundary surveillance, PPE compliance, and intrusion detection with no cloud dependency.

The general question of where inference is allowed to happen is covered in private and on-premises LLM deployment; the same reasoning applies to vision, with bandwidth added to the constraint list.

Measuring whether it worked

Safety outcomes are, fortunately, rare events, which makes them statistically awkward to attribute. Incident counts will not move measurably within a pilot window, and claiming otherwise is not credible.

Measure leading indicators instead: exception rate per zone over time, time-to-correction after an exception, near-miss detections, and camera uptime. Those move within weeks and are defensible.

The same infrastructure does more than safety

Once cameras, on-site inference, and an alerting pipeline exist, the marginal cost of additional detections is low: bay occupancy, queue length, process step timing, obstruction of emergency routes. Safety is often the easiest case to fund and the best foundation to build from — and it connects naturally to production systems like Factory OS, where milestone planning and floor-level status already live. More on the manufacturing page.

• computer vision
• manufacturing
• safety
• industry