Anticipating congestion at a station involves three elements, and this measure is only one of them. A passenger volume forecast is needed for a useful time horizon, that is, 15 to 60 minutes depending on the area; a trigger threshold based on that forecast rather than on observed density; and an operational decision prepared in advance, with a designated person in charge and a realistic execution timeframe.
Most systems installed today stop at the first element and display real-time density. This display documents congestion as it occurs, but it is invariably too late to prevent it. The shift from observation to anticipation does not depend on the quality of detection; it depends on the forecast horizon and the associated decision-making process.
A useful forecast horizon is one that allows time to act. It is determined by the intended decision, not by the tool’s capabilities.
Opening an additional access control lane, deploying staff to a lobby, or changing a directional sign rarely takes less than ten to twenty minutes from the decision to its implementation on the ground. A five-minute forecast is therefore useless for these decisions, even if it is accurate.
Conversely, certain actions are nearly immediate: temporarily closing an escalator, switching a display, or opening an emergency exit door. For these, a short time horizon is sufficient.
Best practice involves listing the decisions that can be made at the station, measuring their actual implementation time, and using the forecast only for the corresponding time horizons. A station generally needs only two time horizons: a short-term and a long-term one.
A usable forecast combines three sources, and video analysis provides only one of them.
Passenger flows observed upstream of the risk zone: station entrances, exits from platforms, and movement through a transfer corridor. A zone always fills up from somewhere, and that “somewhere” can be measured a few minutes in advance.
The operating schedule: theoretical timetables, current delays, train compositions, and assigned platforms. A long train arriving ten minutes late just as another is scheduled to arrive predictably shifts the peak.
Historical data: the same station, the same day of the week, the same time slot, over several months. It is this component that defines the expected shape of the curve and makes it possible to detect a significant deviation.
A system that ignores the operating schedule makes no predictions—it merely extrapolates. The difference becomes apparent precisely on the days when the forecast matters most—those when operations are disrupted.
Not all areas warrant a forecast. Three criteria help determine which ones to prioritize.
An area poses a real risk when passenger density increases: stairways, underpasses beneath tracks, waiting areas in front of platform doors, and bottlenecks between a station concourse and the platforms.
The area has a course of action available: an alternative route exists, a staff member can be assigned there, or an announcement can direct passengers elsewhere. A congested area with no available course of action does not need an alert—it needs improvements.
The area is adequately covered by an existing camera, with a view that allows for measuring density or throughput rather than identifying individuals.
Three or four zones are generally sufficient for a medium-sized station. A system monitoring thirty zones generates a volume of alerts that the command center will not be able to handle.
A threshold is set based on footage from the specific station in question, never on a generic value. The density perceived as critical depends on the width of the passageway, the presence of luggage, the direction of foot traffic, and the layout of obstacles.
The method involves observing several weeks of data, identifying the periods that staff actually experienced as challenging, and then setting the threshold slightly below those levels. A delay prevents a peak lasting just a few seconds from triggering an alert.
A second, lower threshold serves as a useful warning signal without triggering any action. It allows the command center to monitor an increase in traffic volume without being alerted by a notification.
This is where most projects run into trouble. An alert without a prepared decision creates anxiety, not smooth operations.
For each zone and each threshold, three elements must be defined before the system goes live: the expected action, the person or role that triggers it, and the timeframe within which it must take effect. For example: assign an agent to provide directions at the bottom of the stairs—a decision made by the department head—with the expected outcome within ten minutes.
A fourth element is often overlooked: documentation. Recording whether the action was triggered and what the outcome was allows you to verify after a few weeks that the system is having an effect. Without this documentation, it is impossible to distinguish a useful alert from a meaningless one.
Railway right-of-ways accessible to the public are subject to the video surveillance regime set forth in the Internal Security Code, requiring prefectural authorization, public notification via posted notices, and limited data retention periods.
The addition of algorithmic processing to these images constitutes the processing of personal data within the meaning of the GDPR. It requires a documented legal basis and, given the systematic surveillance of a large-scale, publicly accessible area, a data protection impact assessment.
Measuring density and foot traffic does not require facial recognition, individual identification, or tracking a person from one end of the station to the other. Excluding these functions from the design phase significantly simplifies the approval process and facilitates acceptance of the system. Furthermore, staff members within the cameras’ field of view are subject to the information and consultation obligations applicable to employees.
XXII is a French computer vision software developer. Its CORE platform analyzes footage from existing cameras—without facial recognition—and generates metrics on density, throughput, and travel time by zone. These data sets can feed into short-term forecasting and be integrated into the monitoring tools already used by the command center.
Start with a single high-risk zone where you have real leverage for action. Collect data for several weeks without triggering any alerts to establish a baseline and calibrate the thresholds based on actual events.
Next, document the decision-making process, then activate the alerts. In this order, the system has a chance to change operations. In the reverse order, it simply adds yet another dashboard to a command center that already has several.