Remote and unmanned site security monitoring

An unmanned site inverts the usual security problem. There is no one to respond, no one to check the cameras, and frequently no connection worth the name. Whatever you deploy has to decide for itself whether something matters, and then be right often enough that somebody still believes it at 3am six months later.

Why cloud-first does not fit this shape

The standard architecture — ship the video somewhere, analyse it there — breaks on three constraints at once.

Bandwidth. A single camera streaming continuously at a usable quality will saturate a modest cellular link. Four cameras at a compound is not a tuning problem, it is an arithmetic one.

Cost. Per-site, per-month data on a cellular tariff, multiplied by dozens of sites, tends to exceed the cost of the security system itself.

Availability. Links to remote sites drop. If detection stops when the link stops, you have bought a system that fails exactly when a site is most isolated.

Running the analysis on an appliance at the site solves all three. Detection continues regardless of the link; what travels is a notification with a frame, and a clip when someone asks for one.

What “many small sites” changes

An estate of forty compounds with four cameras each is a very different project from one site with a hundred and sixty cameras, even though the camera count matches.

Deployment cost dominates. The visit, the mounting, the power and the commissioning happen forty times. Anything that reduces per-site setup time matters more than almost any feature.

Configuration must be repeatable. Forty bespoke configurations will not be maintained. A standard pattern, applied with site-specific areas, will be.

Maintenance is a travel problem. A camera that fails at a remote compound stays failed until someone drives there. This makes camera-health alerting worth more here than anywhere else — it turns an unplanned emergency visit into a line on a planned route.

Power is a real constraint. Some compounds have limited or intermittent power. That is a hardware conversation to have before the software one.

What to detect, and what to ignore

Keep it narrow. On an unmanned site the useful questions are few:

• Is there a person inside the boundary? The primary event, almost always.
• Is there a vehicle at the perimeter or the gate, outside a booked visit?
• Has a camera stopped working, been moved or been obscured?
• Did a gate open when nothing was scheduled?

That is usually the whole list. Resist adding analytics because they are available; every extra event type is more volume reaching a person who cannot easily verify it.

Night is the whole question

On an unlit compound, what the camera can resolve after dark decides whether the system works at all. A detector cannot find what the sensor did not capture.

The options, in order of how well they tend to work:

1. Add light. A floodlight triggered by detection both improves the image and deters the person. It is usually the cheapest effective answer.
2. Match the lens to the distance. A narrower field of view on the approach beats a wide view of the whole compound.
3. Thermal, where budget allows, for long boundaries with no prospect of lighting.

What does not work is lowering a confidence threshold to compensate. It produces nuisance events every night and trains the on-call person to ignore the one that mattered.

Deterrence without a person on site

Where speakers and floodlights can be fitted, an unmanned site can respond even though nobody is there: the light comes on, a recorded warning plays in that area, and the camera now has a lit image of whoever is standing in it.

For a lot of remote estates this is the single highest-value addition, because most intrusions are opportunistic and end the moment the site stops looking unattended.

Before an estate rollout, pilot three sites

Pick your best-connected site, your worst, and one in the middle. Over a month, record:

• Events per night per site, and how many warranted a dispatch.
• Night image usability on every boundary camera, judged by eye.
• Actual data consumed per site per day against your tariff.
• Behaviour across a link outage — does detection continue, do notifications queue and deliver.
• Time from detection to the on-call person holding the frame.
• Per-site deployment hours, which is the number that decides whether forty sites is affordable.

The worst-connected site is the important one. If the design works there, the rest of the estate is straightforward; if it only works at the good site, you have not tested the thing that will actually bite.

One thing to be clear about

A system like this is not a monitoring service and not an alarm receiving centre. It raises better events, with a picture attached, for whoever already does your responding — your own team, or the provider you use. If a vendor blurs that line, ask exactly who is watching at 3am, and what their contractual obligation is when they do.