Ayonix Video Analytics

Deployment architecture

Edge deployment: process where the cameras are

In short

Edge deployment runs analytics on hardware at the site, next to the cameras. Video never leaves the local network, only events and aggregate series traverse the WAN, and detection continues during a network outage. Ayonix states that its systems are built to run at the edge as well as on-premise and air-gapped.

Who this suits

  • Remote sites with constrained or expensive backhaul, such as substations and outstations
  • Multi-site estates where sending every camera stream to a central location is impractical
  • Sites where an alert must still be raised when the WAN link is down
  • Environments where video is not permitted to leave the local network
  • Deployments where per-site independence matters more than central processing efficiency
Conceptual compact edge AI appliance mounted beside a security camera
Conceptual edge appliance illustration — not a photograph of ATLAS AIBOX. AI-generated conceptual image, not a customer deployment.

Architecture

How it is put together

  • Cameras stream locally over RTSP or ONVIF to an edge node on the same network segment.
  • Detection, tracking and rule evaluation run entirely on the edge node.
  • Events, evidence references and aggregate series are the only data that leaves the site.
  • A central management layer distributes configuration and collects health and events.
  • Local delivery paths — a VMS on site, a beacon, a local operator queue — continue working without the WAN.
Edge video analytics architecture diagram

Characteristics

What this model means in operation

The properties below are what actually differentiate the deployment models from each other.

Bandwidth
Lowest of any model. Continuous video stays local; only events, small evidence artefacts and aggregate series cross the WAN. A site with dozens of cameras can typically report over a connection that could not carry one continuous stream.
Latency
Lowest of any model for local action. Detection to local alert involves no WAN round trip, which matters wherever a beacon, barrier or on-site operator is the responder.
Privacy
Strongest default position. Continuous video remains within the site network, which frequently resolves the data-residency and data-minimisation questions that block other models.
Resilience
Highest per-site independence. A WAN outage stops central reporting but not local detection and alerting. Conversely, an edge node failure affects only its own site.
Central management
Configuration, rule templates and software versions are distributed centrally, with health and events collected back. Sites continue operating on their last known-good configuration during a disconnection.
Software updates
Staged rollout by site group with the ability to hold a version on a site that must not change. Update windows should be scheduled around each site’s operational pattern rather than applied estate-wide at once.
Health monitoring
Per-node and per-camera health reported centrally: stream availability, decode errors, processing headroom, blocked views and node reachability. A site that stops reporting is itself an alert.
Logging
Structured local logs with central aggregation of operational events. Media never appears in logs, and personal data is redacted before any log leaves the site.
Backup
Configuration and rule definitions are backed up centrally so a replaced node can be restored to its previous state. Local event evidence follows the site retention policy.
High availability
Achieved by node redundancy at sites that justify it, with camera groups able to fail over between nodes. Most sites accept single-node deployment because the failure domain is already limited to one site.
Scaling
Scales by adding sites rather than by growing a central cluster. Per-site camera capacity is bounded by the node, so a site that grows beyond its node needs a second one.

Planning

Sizing inputs, cost and limitations

Hardware sizing inputs

  • Number of camera streams per site and their resolution
  • Analysis frame rate required by each intended rule
  • Number and type of concurrent rules per camera
  • Retention required for local event evidence
  • Whether a VMS or other software shares the same hardware
  • Environmental constraints — temperature, mounting, power availability

Sizing is done against your actual stream profiles and rule set by Ayonix. No channel-count or throughput figure is published on this site, because none has been supplied.

Cost considerations

  • Hardware cost per site, which is the dominant factor in a multi-site estate
  • Reduced WAN cost, frequently the largest saving and sometimes the whole business case
  • Site visits for installation and hardware replacement
  • Central management platform cost, amortised across sites
  • Longer hardware refresh cycles at sites with stable requirements

Limitations

  • Per-site capacity is fixed by the hardware installed, so growth needs planning rather than a configuration change.
  • Physical access is needed for hardware faults, which matters at genuinely remote sites.
  • Analysis spanning multiple sites must happen centrally on aggregate data, not at the edge.
  • Environmental conditions at some sites constrain what hardware can be installed at all.

Frequently asked questions

How many cameras can one edge node handle?

That depends on resolution, analysis frame rate, and how many rules run per camera, so it is a sizing exercise rather than a fixed number. Ayonix has published no channel-count figures and this site will not invent any. Sizing is done against your actual stream profiles and rule set.

What happens when the WAN link drops?

Detection, rule evaluation and local delivery continue. Central reporting pauses and resumes when connectivity returns. For unmanned sites this is usually the deciding advantage over any centrally-processed model.

Can analytics share hardware with a VMS?

Often yes, and it is common in Nx deployments. The hardware must be sized for both workloads — under-sizing produces dropped frames that degrade detection in ways that look like an analytics fault rather than a capacity one.

Compare with other models

Author
Gabriel Bamola, Chief Marketing Officer, Ayonix
Technical review
Dr Sadi Vural, Founder and Chief Executive Officer, Ayonix
Published
Last reviewed

Get an architecture review for your estate

Site count, connectivity, data-residency constraints and whether alerting must survive an outage decide the model. An architecture review works through those with you and produces the sizing inputs Ayonix needs.

Request an architecture review Compare all deployment models