XXII | Blog

How can you monitor multiple industrial sites in real time using video analytics?

Written by Alicia | Oct 12, 2026, 10:40:06 AM

Monitoring multiple industrial sites in real time using video analytics relies on four architectural decisions: where image processing is performed, what data is actually sent back to the central level, to whom each alert is directed, and how a single configuration is applied to a group of sites without having to be replicated site by site.

These decisions matter more than the performance of the detection model. An algorithm that works at one site runs into entirely different problems by the third or fourth site: uneven network connections, heterogeneous camera fleets, local teams with different work habits, and the lack of a single location where sites can be compared against one another.

Where should image processing be performed?

In most industrial settings, processing is performed on equipment installed on-site, as close as possible to the cameras. There are three reasons for this.

Volume. Continuously transmitting streams from dozens of cameras to a central location consumes bandwidth that few production sites or logistics platforms actually have available.

Latency. An alert regarding a person in a restricted area or a pedestrian on a vehicle aisle is only useful if it reaches the operator within a few seconds.

Data control. Local processing ensures that only measurements—and, if necessary, a thumbnail associated with an alert—are sent off-site, which significantly simplifies compliance documentation.

The central level then receives events and measurement data sets, not continuous video streams. It is this approach that makes multi-site monitoring feasible over a standard connection.

What should be sent to the central level?

Three data streams are sufficient, and it is best to distinguish them clearly.

Alerts, which require immediate action by a designated person. Their number must remain low per site and per day; otherwise, they will no longer be processed.

Operational metrics, aggregated by zone and time slot: occupancy, durations, traffic flows, and queues. These do not require an immediate response and facilitate comparisons between sites.

The technical status of the system: cameras out of service, interrupted data streams, processing halted, desynchronized clocks. This third data stream is most often overlooked, yet it is the one that determines the level of trust placed in the first two. An indicator that drops because a camera has gone down looks very similar to an indicator that drops for a genuine reason.

Who should receive the alerts?

An alert without a designated recipient is not an alert—it’s a notification. Before going live, each type of event must be associated with a role, a channel, and an expected response time.

Role: dock manager, team leader, security desk, on-call staff. Channel: supervision screen, message on a mobile device, or escalation to the incident management tool already in use on-site. Response time: a nighttime security alert and a zone congestion alert do not require the same level of responsiveness.

Two settings prevent most issues. The first is the trigger threshold, which should be calibrated based on actual site footage rather than a default value. The second is the delay, which prevents a single event from generating a series of notifications while it is already being addressed.

Finally, measure the alert qualification rate—that is, the percentage of alerts actually handled by the teams. A drop in this rate signals that a setting needs to be reviewed well before users start complaining.

How can you avoid having to reconfigure each site manually?

This is the factor that determines the actual cost of a deployment across a fleet. Three mechanisms to look for during evaluation.

Reusable configuration templates: a single set of rules, standard zones, and thresholds applicable to a family of comparable sites, with the ability to make local adjustments without losing the link to the template.

Remote deployment of updates, by site group, with the option to revert to the previous version.

A documented procedure for adding a site, including the time required, the skills needed locally, and a list of network prerequisites. Request this procedure in writing: its level of detail provides a better indication of a solution’s maturity than any demonstration.

How can sites be compared with one another?

The main benefit of centralized monitoring is comparison. It is only valuable if it is valid.

Two sites can only be meaningfully compared if the measured areas have the same definition and if the metrics are based on the same calculation rules. A dock occupancy rate calculated based on total area at one site and on active berths at another results in a discrepancy that says nothing about actual operations.

A useful practice is to establish a standardized set of indicators before deployment: name, definition, reference area, calculation method, and aggregation period. This document prevents endless debates about the reliability of the figures once the dashboards are in use.

How can video analytics be integrated with existing tools?

Video analytics does not replace industrial monitoring, warehouse management tools, or maintenance management. It provides them with a metric they lack: a measure of what is physically happening in areas where no sensors are installed.

The most useful integrations are often the simplest: sending events to the tool already used by teams, exporting measurement data to the group’s data warehouse, and providing a documented programming interface. Check this last point early in the evaluation, because a closed-system solution forces you to maintain yet another dashboard.

What XXII Offers

XXII is a French computer vision software developer. Its CORE platform analyzes feeds from cameras already installed—without facial recognition—and allows you to monitor multiple sites from a single interface, with configurations that can be reused across sites and metrics fed into existing management tools.

What deployment sequence should be chosen?

The process consists of three phases. A pilot site, chosen because it is representative rather than because it is easy, with two or three metrics and a fixed dictionary. Next, a group of three to five sites, which reveals the real deployment challenges: network issues, camera heterogeneity, and the availability of local teams. Only then should the system be rolled out to the entire fleet.

The tipping point is not technical. It is reached when local teams check the metrics without being asked, and when an unaddressed alert becomes an anomaly rather than the norm.