Perimeter & border deployments

Turning a fence line, a checkpoint or a restricted area into events, using the same four calls everything else uses. Includes the things that go wrong at 3am, which is when security deployments are actually judged.

Why this SDK suits the work#

Three properties matter more here than anywhere else, and they are the ones this SDK was built around:

The primitives, mapped#

Most of physical security falls out of four calls:

1. Perimeter intrusion#

A directed tripwire just inside the fence line, not on it.

/* Inside the fence, running parallel to it. */
int32_t line_id = -1;
xcaicx_stream_add_line(stream, "north-fence",
                       (xcaicx_point){0.08f, 0.62f},
                       (xcaicx_point){0.94f, 0.48f}, &line_id);

if (e->kind == XCAICX_EVENT_LINE_CROSS && strcmp(e->zone_name, "north-fence") == 0) {
    if (strcmp(e->detail, "a_to_b") == 0) alarm_ingress(e->track_id, e->pts_us);
    else                                   log_egress(e->track_id, e->pts_us);
}

Direction is the difference between an alarm and a log line. A patrol walking out should not raise what a breach raises.

Tuning for a fence line#

2. Restricted areas and loitering#

const xcaicx_point sterile[] = {
    {0.30f, 0.40f}, {0.92f, 0.34f}, {0.96f, 0.95f}, {0.26f, 0.98f}
};
int32_t zone_id = -1;
xcaicx_stream_add_zone(stream, "sterile-area", sterile, 4,
                       /*dwell_seconds=*/30, &zone_id);

Zone membership is tested at the midpoint of the bottom edge of a track — the ground contact point. Draw zones on the floor plane as they exist in the world; a zone drawn around where a person's torso appears in the image will never trigger.

DWELL_EXCEEDED fires once per visit. Someone crossing the area produces enter and exit; someone stopping in it produces enter, dwell, and later exit. That distinction is usually the whole alarm policy.

3. Border segment monitoring#

The same tripwire, with two differences in practice:

• Group crossings. Each person is a track with an id, so a group is a countable set of LINE_CROSS events rather than one. Deduplicate on track_id, not on time.
• Long, shallow fields of view. Objects are small at range. Analysis runs at 320px on the long side, so a person who occupies fewer than roughly ten pixels of height at that scale will not be detected. That is a lens, mounting and camera-count question, not a tuning one — work it out before installation rather than after.

4. Vehicle checkpoints#

cfg.modules = XCAICX_MODULE_DETECT | XCAICX_MODULE_ANPR;

Plate localisation runs on any build. Reading the characters requires a production build with the text model — the reference backend returns the plate box with empty text and detail = "plate_candidate". Check for that in bring-up so you do not mistake a working pipeline for a working reader.

for (size_t i = 0; i < res->detection_count; ++i) {
    const xcaicx_detection *d = &res->detections[i];
    if (d->source != XCAICX_MODULE_ANPR) continue;
    if (d->text && d->text[0]) check_against_list(d->text, d->text_score);
    else                       log_plate_seen_but_unread(d->box);
}

Add a zone per lane for occupancy and dwell, and the same frames produce throughput reporting with no extra hardware.

5. Night, thermal and IR#

Detection is luma-based and runs on XCAICX_PIX_GRAY8 with no special handling — a thermal or IR stream works.

6. Unmanned and remote sites#

Substations, pipeline stations, relay huts, remote border posts.

cfg.license_path = "/etc/xcaicx/unit.token";   /* minted offline, device-bound */
cfg.state_dir    = "/var/lib/xcaicx";          /* persistent, survives reboot */
cfg.offline      = 1;                          /* never opens a socket */

Build with -DXCAICX_WITH_TLS=OFF and the HTTP client is not linked into the binary at all — a claim the customer's own security team can verify with ldd and strings rather than taking your word for it.

Usage still accrues to state_dir/usage-spool.jsonl for collection on a service visit. See Air-gapped deployment for the provisioning and renewal workflow, and plan the licence term against the site's maintenance schedule rather than the calendar — an annual term on a site reachable once a year gives you a zero-day margin.

7. Sizing and placement, before you install#

The questions that decide whether a deployment works, in the order they bite:

1. Pixels on target. At 320px analysis, how tall is a person at the far end of the field of view? Under ~10px and the answer is a different lens or another camera.
2. Where does the tracker get its run-up? Boundaries need a few frames of visible approach.
3. What is the frame budget? Measure total_ms on the real board with the real model and a busy scene. An empty corridor is cheap and tells you nothing.
4. Is state_dir genuinely persistent? On a read-only rootfs, confirm it is a real writable overlay and not tmpfs — otherwise every reboot re-activates and consumes a unit.
5. What happens when analytics stop? The video path must keep recording. A camera that stops recording because a licence lapsed is a warranty claim.

8. What this is not#

Next#

• Zones, tripwires & events — the event semantics in detail
• Air-gapped deployment — offline provisioning and renewal
• Security & threat model — what to hand a customer's security team
• Performance & tuning — fitting the budget on the real board