Development of an AI System for Abandoned Object Detection

Abandoned object detection: where the system breaks

Abandoned object detection runs into a simple thing: it is a static object — a bag, a backpack, a box by the wall.

Classic motion-based video analytics does not see it, because the detector reacts to movement, not to the appearance of a new stationary object in the monitored area. The event surfaces tens of minutes later, when an operator notices it by chance — or does not surface at all.

Then occlusions interfere. A person blocks the bag with their body for a few seconds, the tracker loses the connection between “the person was there” and “the item remained,” and the object goes into the background of the scene.

If the model keeps the object in memory too long, the opposite extreme begins: false alarms on every briefcase that its owner put next to themselves and stepped a couple of meters away.

The cost of both modes is the same. Either a missed event in a monitored area where delay is most expensive, or a stream of false alarms after which the shift stops responding to signals at all.

On top of that is the gap between the event and the response: a detected object must be brought to the duty officer with an image, camera reference, and timestamp, otherwise it remains a line in the log.

We integrate this logic into an already operating video circuit, including systems of the Milestone level, rather than building a second parallel circuit with separate cameras.

Below we break down how this is addressed in practice: object ownership logic, thresholds for stationary time, and binding to the boundaries of the monitored area.

What implementation delivers: measurable effect for the facility

At a facility without configured analytics, an abandoned item is noticed by a human — and not always noticed.

The system turns this into a rule: the object remains in the area of interest longer than a set threshold and there is no movement nearby — an alarm is generated with time and camera reference.

Security response time drops from several minutes to tens of seconds, because the operator receives a ready event rather than a video stream.

Operator workload is determined not by the number of cameras, but by the number of false alarms.

Thresholds are selected for the specific scene: separately for an outdoor area with vegetation, separately for a checkout area and entrance group, separately for places with changing lighting.

After such tuning, one post confidently handles three times as many cameras, and the share of missed events decreases because attention is not scattered by noise.

Video analytics quality grows along with the accumulated event archive. Each false alarm is reviewed and goes into retraining, so after several weeks of operation, accuracy at the specific facility is higher than that of a typical model.

The event archive stores not only clips but also metadata: event type, zone, interval, processing status. Incident review takes minutes — the needed fragment is found by filter, not by scrubbing through a day of recording.

We work on professional Hikvision equipment, so the system integrates into an already installed surveillance network without replacing the camera fleet.

Detection options: local, server-based, hybrid

In all three schemes the source is the same — the camera stream; only the location of frame processing differs: a compute node at the facility, a server, or both levels at once.

The choice is determined by the number of cameras, channel stability, video storage requirements, and how quickly the alarm must reach the operator.

The system's limitations do not disappear when the scheme changes — they are redistributed. Hybrid offloads the channel at the cost of a second update point; server-based analytics simplifies model management but makes the site dependent on connectivity.

That is why we test the choice on recordings from the specific site: we count the share of missed abandoned objects and the number of false alarms in night footage, under occlusions, and in areas with dense foot traffic.

The scheme is suitable if the metrics hold under all these conditions, not only on a daytime test clip.

Implementation stages: from site survey to handover

Abandoned object detection is not bought as a ready-made box: trigger rules depend on the hall geometry, traffic density, and the facility's operating mode.

That is why implementation follows a fixed sequence — at each step it is clear what has already been verified and what remains to be configured.

1. Site survey. We walk the zones together with the security service and compare the floor plan with the camera layout: we mark blind spots, overlapping angles, and places where no camera can see an abandoned item.
2. Placement scheme and areas of interest. We define controlled areas and exceptions — exits, escalators, areas of constant movement. Camera angles and a set of rules for each zone are mapped.
3. Rule configuration. We set the stationary time, minimum object size, and schedule for different shifts. We separately distinguish an item left by a person from an object that stands for a long time according to regulations.
4. Test period. The system operates in observation mode: operators record triggers, we review each one and adjust thresholds — removing false ones without losing real ones.
5. System acceptance. We review measurable indicators: share of missed events, number of false alarms per shift, time from object appearance to signal. The result is documented in a protocol.
6. Handover to operation. We train operators, provide the alarm response regulation and instructions for changing zones during reconfiguration.

Each stage ends with an artifact — a scheme, rule configuration, or protocol. The customer can see at which step the project is and what will happen after handover.

Scope of delivery: configurations, schemes, and regulations

The delivery is structured so that the system remains operational without us: everything that describes behavior is stored in text configurations and schemes, not in the engineer's head.

Below is what exactly transfers to the customer's team and what can be done with it independently afterward.

• Detection configurations — sensitivity thresholds, minimum time an object remains in the zone, list of object classes, and exclusion zones. Edited without rebuilding the model; changes take effect after verification on a test set of recordings.
• Camera placement scheme — floor plans with installation points, viewing directions, overlap zones, and clearly marked blind spots. It shows why this geometry was chosen and which places remain outside control.
• Response regulation — who receives the alarm, within what time, what the operator does before the group arrives, under what conditions an event is closed as false, and to whom it is escalated.
• Documentation — description of integration with the existing video system, storage structure for events and video fragments, instructions for operator and administrator, and model update procedure.
• Access rights — role matrix: who sees the stream, who changes thresholds, who exports the archive, who manages zones. Separation prevents rule edits by those who only monitor the shift.
• Test scenarios — a set of recordings with abandoned objects and difficult cases: shadows, reflections, people standing nearby. Any configuration change is verified against it before being put into operation.
• Configuration version log — what changed, when, and with what result on the test set, so you can roll back to the previous rule set in one operation.

This scope gives the customer the ability to develop the system on their own: fine-tune zones, change the regulation for a security shift, connect new cameras — and come back to us only for changes to the abandoned object detection logic.

Case study: how response time was reduced at a warehouse

A distribution warehouse with receiving, storage, and shipping in one circuit: an abandoned pallet or box in a drive aisle blocks a forklift, and the dispatcher learns about it from a shift worker by phone — by the time of response, the item has already been in the zone for several minutes.

What pre-implementation measurements showed

We started with two weeks of observation: an event was considered missed if the operator did not respond while the item remained in the drive aisle. The missed share held at about 30%, and average response time was 4–6 minutes.

The cause is not people: one operator physically cannot keep attention on a wall of screens for an entire shift; by the third hour it drops.

What was changed

Detection was built on YOLO, with the model fine-tuned on recordings from the same site — so it knows local container types and does not confuse a pallet standing in a rack cell with one left in the drive aisle.

The alarm triggers not on the appearance of an object, but on its immobility in a prohibited zone longer than a threshold tied to the unloading pace. The operator receives not a video stream but an alarm queue: camera, fragment around the event, and an “in progress” mark.

What the metrics became

The share of missed events dropped below 2%: almost all are reviewed while the item is still in the drive aisle.

Average response time was reduced from 4–6 minutes to 20–40 seconds, and false alarms — from 15–20 per shift to 2–3 after tuning zones and thresholds together with the shift supervisor.

The shift spends the freed attention on processing the alarm queue instead of searching for violations by eye.

What to do if cameras are already installed at the site

In most cases there is no need to replace the camera fleet when launching abandoned object detection: analytics is installed as a separate layer that receives the stream from already installed cameras and passes events further into the surveillance circuit.

The bottleneck here is not sensor resolution but three things — stream stability, zone viewing angle, and lighting. A camera that “sees” the passage but records in stutters or points at the floor will produce false alarms regardless of model quality.

Before starting, our engineers take inventory: camera models, available streams, network and storage load, archive depth, and placement scheme. If the cameras output a stream in a standard network format, they are suitable, and the question comes down to load calculation.

If the stream is closed inside a recorder without the possibility of output, we consider a gateway on the recorder side or partial replacement by zones.

Phased modernization looks like this: first a pilot on two to four cameras in the most sensitive zones — we calibrate control zones and object retention time, and count the share of false alarms on real shifts.

Then we expand to the remaining cameras where stream quality allows, and only after that do we replace individual cameras that do not meet viewing requirements.

The recorder remains in the circuit: events arrive in it, the operator works in the familiar interface, and recording and archive are not restructured.

Common technical doubts and engineers' answers

Before the pilot, the customer checks not the model's accuracy but the system's behavior in the real hall: false alarms on passersby, occlusions by columns and shelving, loss of communication with a camera, and planned reconfiguration. We address these doubts specifically.

What happens if communication with a camera or server is lost?

A stream break is a separate event, not silence: the operator sees which channel is lost and that the area is not being monitored. Frame processing continues on the local node, the buffer is saved and uploaded after the channel is restored. Camera states and active alarms are synchronized — no duplicates occur.

We are planning a reconfiguration — will the system have to be redone?

Areas of interest, rules, and schedules are stored separately from the model, as configuration. Moving shelving, narrowing a passage, or changing the hall's purpose can be done without retraining — it is enough to re-mark the zones on the new plan.

Changing a camera angle requires recalibrating the scene, and during occlusions the object track is restored, so a single person passing does not break the observation history.

Let's discuss the task: what is needed to start work

It is easier to discuss a task specifically when there is concrete input: then project estimation relies on facts, not assumptions. Below is the minimum of source data that removes clarifying iterations and allows an immediate work plan to be assembled.

• Cameras and zones: where equipment is installed, which areas overlap, where blind spots remain — platforms, racks, exits.
• What we consider an event: an unattended bag, a box by the fence, a cart; after what time an item is recognized as abandoned.
• Existing infrastructure: video server, access control system, security console — where it is logical to send the alarm so as not to create a second parallel interface.
• Response rules: who receives the notification and within what time, whether escalation is needed, whether an operator action log is maintained.
• Privacy and storage: retention period for fragments, face masking, role-based access separation.
• Acceptance criteria: permissible share of false alarms, time from event appearance to alarm, set of scenes for testing.
• Access to a test environment: archive of recordings or a stream from one camera, a separate circuit that does not affect live video surveillance.

Describe the task in this scope — we will return with a project estimate, solution scheme, and staged work plan, and agree on the launch procedure.