To protect charging stations from copper theft, vandalism, and intrusions, an AI-powered video analytics solution must be able to do three things: detect human presence around the equipment outside of a plausible charging session, identify prolonged tampering with a cable or connection point, and send an actionable alert at night, when the site is unstaffed. Dashboards and reports come next.
On paper, the offerings look similar. The differences come down to six verifiable criteria: compatibility with existing cameras, the exact nature of the detections, the system’s performance under nighttime conditions, the location where data streams are processed, the monitoring of a distributed fleet, and the applicable legal framework. This article details these criteria and how to test them in the field. XXII, a French computer vision provider, addresses this need with its CORE platform, which does not use facial recognition.
A charging station does not present the same risk profile as a fueling station. Vehicles park there for tens of minutes, the equipment remains exposed at all times, and the cables contain copper, the value of which is enough to motivate a nighttime break-in.
Four situations occur regularly: the cutting of a charging cable—a quick operation that leaves the charging station out of service until a technician intervenes; the forced opening of a hatch or equipment cabinet; and the vandalism of a screen or badge reader. Finally, the prolonged occupation of a charging spot by a vehicle that is not charging—an operational issue rather than a security one, but one that directly impacts service availability.
These four situations do not require the same detection rules. A severed cable occurs in a matter of seconds and requires an immediate alert. Unauthorized occupancy is measured over time and is the subject of a daily report. A solution that fails to distinguish between these two scenarios ultimately drowns out the real emergencies in a flood of false alarms.
This is the factor that most significantly changes a network’s economic equation. A software-based solution connects to the video feed from existing cameras—either via the local network or through the DVR—and requires no changes to the existing equipment. A solution tied to proprietary hardware requires replacing the cameras, site by site.
Three points must be verified before making any commitment. The software supports the protocols and codecs commonly used in the market. The resolution and framing of existing cameras must allow for distinguishing between a person and a cable within the useful field of view, which often excludes cameras mounted very high or very low to the ground. Finally, accessing the video stream is technically possible without requiring a major reconfiguration of the recorder.
On a network, this verification is performed at a site representative of the most common constraints—never at the best-equipped site. The results obtained there provide a realistic estimate of the adaptation work to be expected elsewhere.
The difference between a conventional motion detector and a computer vision model lies in how the scene is characterized. A motion detector signals any change in the image, including a shadow, a car’s headlights on a neighboring road, or a curtain of rain. A computer vision model distinguishes a person from a vehicle, measures the duration of presence, and recognizes a posture or a repeated gesture.
Ask for a detailed list of available detection types, and especially their definitions. The term “intrusion” covers very different scenarios: human presence within a polygon during a specific time window, crossing a virtual line, or a person remaining in a location beyond a certain duration threshold. These three rules do not generate the same volume of alerts or provide the same operational value.
Also verify what the solution does not do. Detection of a cable-cutting gesture, for example, is rarely available as a standalone feature. What works in practice is the combination of an abnormal presence and prolonged manipulation in contact with the terminal.
This is the criterion that determines whether the system will actually be adopted. A system that triggers too often ends up being ignored, which is the same as not having installed it at all.
A valid test must be conducted at your site, not during a demonstration. A rainy night, partial lighting, nearby traffic, and insects drawn to a floodlight constitute the true test. Count the alerts received over a continuous period of at least two weeks, distinguish between justified and unnecessary alerts, and compare this number to the number of operators available to handle them.
Also ask how the settings can be adjusted. A solution that offers no way to adjust a threshold, zone, or time range after installation will leave you with no recourse if the system proves to be overly sensitive.
Processing performed locally, as close as possible to the cameras, minimizes the required bandwidth and allows the system to continue operating in the event of a network outage. At remote sites with limited connectivity, this is a critical factor.
Centralized processing simplifies updates and pools computing power, but requires continuously uploading video streams. Several vendors offer both modes, sometimes combined: local analysis, with only events and their associated images being uploaded. Ask explicitly how much data leaves the site and where it is sent.
Once you have more than a few locations, operations become the main focus. Four functions are truly essential.
Checking the status of the camera network to see, from a single screen, which camera is no longer transmitting and how long it has been down. Deploying an update or a new rule without on-site intervention. Routing alerts to the correct recipient based on the time and location—whether it’s the monitoring center, on-call staff, or local operator. Finally, exporting events to your own tools via an API to coordinate them with maintenance tasks.
Without these four features, a multi-site deployment quickly turns into a collection of independent installations that no one manages.
The GDPR applies whenever personal data is processed, and the image of an identifiable person falls under this category. A solution that does not use facial recognition avoids the biometric data regime set forth in Article 9 of the GDPR—which is reserved for special categories of data—and significantly simplifies the data protection impact assessment.
The standard obligations remain: informing individuals through a visible notice stating the purpose and their rights, a clearly defined and non-misused purpose, and a limited and documented retention period. The CNIL has published a position paper on so-called “augmented” cameras, which is useful for precisely defining the intended use. When employees are involved, consultation with employee representative bodies is required under the conditions set forth in the Labor Code.
One final point should be raised with the supplier: where the data is hosted, and under what legal framework. For a public operator or local government, the answer to this question often carries as much weight as the detection performance.
Identify two or three priority detection scenarios—those whose absence is currently the most costly. Deploy these detection features at a representative site, using the existing cameras. Measure, for at least two weeks—both day and night—the number of valid alerts and the number of false alarms. Then compare providers based on this data, not on their brochures.
XXII’s CORE platform was designed for this type of gradual rollout on an existing camera infrastructure, with local or centralized processing depending on site constraints.