Development of an AI system for detecting human presence in hazardous areas

We design and implement turnkey video analytics systems: the system detects a person in a hazardous area at the moment of entry, and the signal is sent to a security control room or dispatch center. We eliminate false alarms during setup; personnel receive regulations and a clear action plan.
Frequently Asked Questions

Detection of people in hazardous zones: where the system breaks

Detection of people in hazardous zones breaks more often not on the model, but on the geometry of coverage and site conditions.

One camera per bay leaves blind spots behind stacks, columns, and in the dead angle under the crane boom — that is exactly where a person ends up when machinery starts moving.

The second source of failures is false alarms. Movement of machinery, thermal reflections from metal, steam, dust, and chips produce a surge of triggers, and the signal stops meaning anything.

Industry incident reviews (LSEG) show the same picture: automation formally triggered, but it was switched off or thresholds were lowered because the noise interfered with work.

Operator fatigue adds to this. Keeping watch at the video wall by the end of a shift is physically impossible: attention drops, reaction stretches out, and the decision is made no longer by the person, but by habit.

Alert delay consists of the frame queue, model recalculation, signal transmission, and operator confirmation — in the real loop these are noticeable seconds during which machinery travels several meters.

Hence the conclusion: reliability is provided not by one "smart" camera, but by a combination of coverage zones, noise immunity, and a fast signal path to the mechanic. We'll break down how this is covered.

Measurable effect: reaction time and eliminated failure classes

The effect of detection of people in hazardous zones is measured by four values taken from a working loop: time from event to signal, share of false alarms, share of misses, and operator workload.

Below are typical before and after values taken at sites with similar zone geometry and a similar shift profile.

What changes in numbers

  • System reaction time. Before: an episode was found during archive review — from several minutes to the end of the shift. After: the signal is sent within 1–2 seconds after entering the zone, inference is computed locally on NVIDIA modules, so the delay does not depend on the external communication channel.
  • Reduction of false alarms. Triggers on movement, shadows, and glare fall from tens of percent to single digits: a filter by the "person" class and track retention cut off machinery, animals, and weather interference before the signal reaches the operator.
  • Miss rate. Before: up to a third of episodes in blind spots and at coverage obstructions. After: single-digit percentages — due to camera overlap and the rule of track confirmation in two zones.
  • Operator relief. The number of confirmations per shift is reduced severalfold: instead of continuous viewing — targeted reaction to an event with a ready recording fragment.

These four numbers also cover the failure classes that used to be the norm: late detection, misses due to obstructed coverage, and the shift's refusal to react to a stream of identical triggers.

Infrastructure failures remain — a blinded camera, loss of connection to the archive — but they are caught by monitoring of the system itself, not by a review after an incident.

Architecture options: comparison of approaches and limitations

The detection scheme is determined not by the model, but by site conditions: geometry of the hazardous zone, lighting, stability of the communication channel, and requirements for the evidence base. Below are five approaches that are realistically chosen between at hazardous facilities.

Option When it fits Limitations
On-site video analytics Reaction within seconds is needed, communication is unstable A compute unit is needed next to the cameras
Server-side processing Multiple zones, a unified picture and history are needed Depends on the channel: if it breaks, detection stops
Infrared presence sensors Simple zones, the fact of entry is sufficient False alarms on equipment heating
Personnel tags Binding to a specific employee is needed Work only on those who wear the tag
Combined scheme The cost of a false miss is high More nodes, more complex setup and maintenance

What determines the choice

We look at the zone: if a person can linger in it, an infrared sensor is not enough — video analytics is needed that distinguishes a silhouette, not heat.

Then we check the communication channel and the permissible reaction delay: where the channel is unstable, processing is moved on-site. And third — whether binding to a specific employee is needed or the fact of presence is enough.

How to combine options

The most reliable is a combined scheme: video analytics confirms presence, a tag or infrared sensor provides independent confirmation. Two sources reduce the number of false alarms, and the zone does not remain without control if one of them fails.

Implementation stages: from site survey to handover

Detection of people in hazardous zones is not limited to installing cameras with ready-made settings. First we record the geometry of zones and scenarios, then choose observation points, and only then configure the logic. Each stage ends with an artifact that the customer can check.

  1. Site survey — we walk the site together with an occupational safety engineer, noting sources of false alarms: welding glare, steam, dust, machinery movement, obstructions by racks. Separately, we look at where people appear for seconds and where they stay permanently.
  2. Equipment layout plan — based on the survey, we prepare a plan: viewing angles, mounting height, overlap zones, power points, communication channels. We agree on the plan before installation: moving a camera after commissioning means a repeat visit and rechecking the zones.
  3. Trigger rules — we set the boundaries of the hazardous zone, the presence time before alarm, and the shift notification procedure. Exceptions are specified explicitly: work under a permit-to-work must not raise the siren.
  4. Testing under real conditions — a run in live mode: day and night, lighting changes, peak load, machinery movement. We count misses and false alarms, adjust thresholds; acceptance is based on actual results, not a demonstration.
  5. Shift training — we show operators how to react to a signal, confirm or reject an alarm, and what to do in case of failure. A separate instruction is for the on-duty technician.
  6. Handover of the result — accesses, scheme, trigger rules, inspection log, and maintenance regulations. We record who is responsible for changing settings when zones are re-planned.

Handover of the result: regulations, schemes, documentation

The system cannot be considered implemented while knowledge about it lives only in the contractor's head.

Therefore handover is not a demonstration of "look, a box appeared", but a set of artifacts by which your shift works independently: marks the zone, analyzes an incident, changes the trigger threshold, and understands where to look for the cause if detection of people in hazardous zones stops triggering on a specific camera.

What remains at the site

  • Configurations: control zones, model confidence thresholds, activity schedules, and false alarm suppression rules — with an explanation of why each parameter is needed and what will break if it is changed.
  • Control zone scheme: a site plan with coordinates of hazardous zones, blind areas, and coverage obstructions — if equipment is rearranged, the marking can be repeated without us.
  • Access policies: roles of operator, duty officer, and manager, what each sees, who can export fragments, and who is allowed to edit settings.
  • Event log: recording format, retention period, and alarm composition — time, zone, model confidence, link to the fragment — as well as the export procedure for analysis.
  • Response regulations: who receives the alarm and within what time, under what conditions escalation is activated, and what to do if the notification channel fails.
  • Operator instruction: analysis of typical and false triggers, confirmation and rejection procedure, actions when communication with the camera or model is lost.

How we hand over

Artifacts are useless without a run-through: we hold a training session with the duty shift, analyze recorded incidents, and ensure that the operator changes settings and reads the log without prompts.

After that, the documentation lives with you — when zones or thresholds change, we update it together with the configuration so that six months later it describes the real site, not the initial project.

Case study: reduced false alarms in production zones

At a continuous-cycle site, cameras looked at three hazardous zones: the press, the feed conveyor, and the forklift exit. Detection of people in hazardous zones worked, but signals came so often that the operator stopped reacting to them. The analysis began with the event log — it showed that most triggers occurred in the same areas.

Initial situation

The zones were marked with rectangles "by eye": the hazardous area included the passage to the panel and the unloading point, where people are present according to regulations.

The detector caught reflections from the wet floor and shadows of moving parts, and made a decision based on a single frame. The share of false alarms stayed around 65%, operator reaction time stretched to 3-4 minutes, and real entries were lost in the stream of notifications.

What was changed and what was achieved

The zones were marked according to actual trajectories: entry line separately, presence zone separately, hazardous zone separately, passages excluded.

The decision was switched to confirmation by a series of frames with a confidence threshold and minimum time in the zone — a single appearance of a person no longer gives a signal.

The share of false alarms dropped to 9%, operator reaction time decreased to 30-40 seconds, and misses of hazardous entries became isolated per shift.

The rules and settings are recorded in the site event log: when the layout changes, they are revised without retraining the model.

How does video analytics differ from infrared presence sensors?

An infrared presence sensor is a threshold device: it reacts to a change in thermal contrast in its sector and does not distinguish who exactly created that change. Video analytics selects an object in the frame, classifies it, and tracks its trajectory.

Therefore the detection accuracy of these solutions differs not in percentages, but by class of tasks: the sensor reports "heat moved", analytics reports "a person entered the hazardous zone and is standing at the conveyor".

The difference manifests primarily in lighting and environmental conditions. A passive infrared sensor depends on air temperature, clothing, and background surfaces: a heated equipment housing or a flow of warm air causes a false alarm, while thick workwear causes a miss.

Video analytics with infrared illumination maintains coverage both in darkness and in backlight, and sensitivity here is configured by zone, rather than set once.

Dust, steam, and obstructions are handled differently by the two approaches. A dusty window of an infrared sensor means loss of the sector without a fault signal: the system formally works, there are no triggers.

A camera in a protective housing maintains coverage, and obstructions are compensated by zone masks and trajectory checking — it is not movement that is cut off, but the object itself.

System maintenance differs in scope of work. There are usually dozens of infrared points: each is cleaned, replaced according to service life, and checked with a control test, and during work the area remains unprotected.

Video analytics has fewer control points, zones are edited remotely, and the state is visible from the image itself — but stable power and image quality control are required.

Compatibility with already installed equipment often decides the choice. If the site has cameras, analytics connects to the existing fleet: some computations run on the server, some on the recorder, and there is no need to pull new cable runs through the shop. Infrared sensors will require separate wiring and cabinets.

Implementation concerns: addressing technical questions

Concerns at the start are usually not about the model itself, but about the modes where the system performs worst. Five questions that technical managers ask before work begins — with substantive answers.

How does the system behave on the night shift?

At night contrast drops, and illumination produces a washed-out image without details. We set a separate profile for dark hours: infrared or thermal imaging channel, and trigger thresholds are recalculated for night noise. This way shadows, steam, and insects near the lens do not turn into a stream of false alarms.

What to do if coverage is obstructed by a stack or machinery?

A stack, column, or parked machine covers part of the zone, and full-frame detection does not work there. During the survey we take a plan of obstructions, mark zones of interest, and add a second observation point covering blind areas. Where it is physically impossible to see — we record this in the scheme and do not promise control.

Can access levels be differentiated?

Yes, roles are configured according to the site regulations: the operator sees the alarm and a short fragment, the engineer sees zone and threshold settings, security sees only events in their zone. Archive viewing and record export are logged, so for an incident it is visible who looked at what.

Will the system trigger on machinery movement?

A forklift in the frame produces movement that can easily be mistaken for a person. We cut it off by silhouette, speed, and time in the zone, and add a "person outside the cab" rule: an event is counted only if the object appears in the pedestrian zone. Thresholds are selected on real recordings from the site, not on demonstration ones.

How does this integrate with the current alarm system?

The system does not replace existing loops but integrates into them: the alarm goes out via relay output or through the recorder to the security post, and the fragment before and after the event goes there as well.

We test the interface on a bench before putting it into operation, including behavior during communication loss and equipment restart.

Let's discuss the task and return with an implementation plan

We start by discussing the task: where exactly the hazardous zones are located, who must react to an alarm and how quickly, and what happens now when a person ends up inside.

The answers determine both the detection logic and the trigger threshold, and where the signal goes — to the security post, to a siren, or to the equipment control loop.

To return not with general words, but with an estimate, scope of work, and stage timelines, we need initial data from the customer:

  • a scheme of hazardous zones with boundaries on the shop or site plan — we use it to mark zones of interest;
  • access to video streams: addresses, accounts, viewing rights, and an archive of recordings for a typical shift;
  • shooting conditions — angles, mounting height, day and night lighting, obstructions by machinery and people;
  • reaction requirements: permissible delay from a person's appearance to the signal and the point where the signal must arrive;
  • permissible level of false alarms — the choice of model and alarm confirmation mode depend on it;
  • regulations for personnel actions upon triggering and security service requirements for event storage;
  • site restrictions: downtime windows for installation and configuration, rules for admitting engineers to the site.

After reviewing the initial data, we return with an implementation plan: preparation of the loop, configuration and additional training of the model on your recordings, integration with the notification system.

We record stage timelines in the plan, and agree on the acceptance procedure in advance — we measure quality on a held-out sample from your archive, review disputed frames together, and only after that put the system into operating mode. Describe the task — we will return with an estimate and a plan.

AI Development Areas

Latest works

  • Development of a web application for FEEDME
    Development of a web application for FEEDME
    1394
  • Development of an online store for the company FURNORO
    Development of an online store for the company FURNORO
    1369
  • B2B Advance company logo design
    B2B Advance company logo design
    816
  • Development of a web application for Enviok
    Development of a web application for Enviok
    1141
  • AIDER company logo development
    AIDER company logo development
    1059
  • CRM development for Chasseurs
    CRM development for Chasseurs
    1153