Why queues are a forecasting problem, not a sensor problem
A queue at a security lane, an immigration hall, or a check-in island is the visible end of a chain that started weeks earlier. The flight was booked, the load factor settled, the schedule changed once, the school holiday landed in week three, the connecting bank tightened by ten minutes, the rain came in, and on the morning of the day, all of that arrived at a single bottleneck inside a finite footprint. By the time a queue is forming, the airport's room to respond is small. Open another lane and you need a roster that already has the staff. Move passengers to a different hall and you need signage and a contingency plan already in place. The decisions that matter were made four weeks ago.
That is why airport queue prediction is a forecasting problem first, and a sensor problem second. A live count at the lane is essential, but it tells you what is already true. A useful prediction tells you what will be true on a Tuesday morning four weeks from now, accurate enough that the operations director can write a staff roster, the airline can plan check-in opening times, and the security supplier can request the right number of officers from a contract that requires notice. The numbers in this piece are illustrative ranges. They describe the shape of the problem, not Ariadne-measured results.
The Heathrow-scale problem
A large hub processes a passenger volume in the tens of thousands per peak hour across several terminals. The security operation at a hub like Heathrow is one of the most-studied queueing problems in transport, because the cost of getting it wrong is concrete: every minute of average wait above a service standard pulls airline contract penalties, drives complaints into the regulator, and pushes passengers to plan earlier arrivals that crowd the landside ahead of the security lane and shift the problem upstream.
Heathrow is cited here as a public industry-scale reference point because the airport publishes service standards and discusses them openly in regulatory submissions. The point is not that Ariadne runs at Heathrow. The point is that any airport at that scale, and any airport scaled down from it by a factor of two or five, faces the same forecasting problem and needs the same modelling discipline to solve it. The patterns below apply at a primary hub, at a large regional gateway, and at a busy secondary airport once the booked-passenger volume crosses the threshold where eyeballed rostering stops being good enough.
What a 4-week-ahead queue forecast actually needs
A useful four-week forecast at an airport security or immigration hall is not a single number. It is a curve, hour by hour, for each day of each week ahead, for each control point. The model that produces that curve takes five families of input. Any forecast that misses one of them will fit some weeks well and embarrass itself on the rest.
Booked-passenger feeds
The single most important input is the booked-passenger volume by departing flight, by hour, four weeks out. This comes from a feed against the departure control system or the airline's PNR-derived counts, refreshed daily as the booking curve fills in. A 28-day-out booking is informative but incomplete. Walk-up rates have collapsed in most markets but not to zero, group bookings can land late, and tour operator allocations release on their own clock. The model has to know not only how many seats are sold today, but how the booking curve typically completes in the remaining four weeks for that route, that day-of-week, and that season. Two flights with the same 28-day-out booking can land at very different load factors.
Historical curves at the control point
Booked passengers tell you how many people will fly. The historical curve tells you when they will arrive at the security lane. Passengers do not arrive uniformly between check-in opening and gate closing. They follow a show-up curve that peaks for a short-haul economy route around 90 to 120 minutes before departure, for a long-haul route earlier, and for premium passengers later again. The shape of that curve is specific to each route group, each terminal, and each season. A long-haul morning bank produces a sharper arrivals peak at the security lane than the same booked passenger count spread across a short-haul evening of point-to-point flights.
Without a route-by-route historical show-up curve, even a perfect booked-passenger count produces a poor lane-level forecast, because the same passengers can arrive in two completely different shapes.
Day-part and day-of-week patterns
Stack the booked passengers onto the show-up curves, sum across flights, and you have the rough hourly inflow at the control point. The rough number then needs to be conditioned by patterns that are stable enough to model and obvious enough to miss if you do not look for them. The Monday morning before a school half-term is not the Monday morning of any random week. The Friday afternoon at the start of a long weekend is not a normal Friday. Outbound holiday Saturdays in late July and early August carry a passenger mix with more checked bags and more group bookings per flight, which slows the lane even at the same passenger count. The day-part profile shifts with the schedule, and the schedule shifts seasonally.
Weather
Weather affects airport queues from both directions. On the landside, severe weather can delay arrivals to the airport and compress the inflow into a shorter window, which is worse for the queue than a steady volume even when the total passenger count is the same. On the airside, weather can delay flights, which holds passengers on the wrong side of security longer than planned and changes the steady-state occupancy of the departures hall. The model does not need a perfect meteorological forecast at 28 days, but it does need to ingest the medium-range forecast as it sharpens, re-condition the inflow shape on it, and re-issue the queue prediction daily as confidence improves.
Event calendar
A major sporting fixture, a public holiday in a destination country, a school-holiday calendar across multiple catchment regions, a strike action elsewhere in the network: each of these moves passenger volume against an otherwise unremarkable date. An event calendar is not a single column in a spreadsheet. It is a structured set of features that the model can use to shift demand for a specific terminal, route, or day. Hubs with a high transfer share need event calendars for the major origin and destination markets, not only the home market.
These five inputs feed a model that produces an hourly inflow forecast at each control point, four weeks out, refreshed daily. The output is a curve, with uncertainty around it, and the planning use of the forecast depends on reading both the curve and the uncertainty.
The processing side of the queue
Inflow at a security lane is half of the queueing problem. The other half is processing throughput: how many passengers per hour the open lanes can clear. A queue forms when inflow exceeds throughput in a window. Forecasting only the inflow without forecasting throughput will under-call the queue on busy days when fewer lanes are open and over-call it on quiet days when the operation has slack.
Throughput at an airport security or immigration lane depends on the number of lanes open, the technology in each lane, the officer-to-lane ratio, the passenger mix arriving at it, and the time of day relative to officer break rotations. A useful queue forecast at four weeks therefore needs to be coupled with a roster forecast for the same period. The simplest version uses a per-lane average throughput rate. A better version conditions throughput on the passenger mix arriving in that window, since a lane processing mostly business passengers with hand luggage only runs faster than the same lane processing summer-holiday family groups with checked bags.
The queue length, and therefore the wait time, is the integral of the difference between inflow and throughput over the window in question. The forecast does not have to be perfect to be useful. It has to be accurate enough at 28 days to drive a roster, accurate enough at 7 days to adjust it, and accurate enough at 24 hours to issue the operating plan.
How live counts close the loop
A 4-week forecast is a plan. Like any plan, it survives contact with the day in proportion to how quickly it can be corrected. The mechanism that corrects it is live measurement at the control points, fed back to the forecasting model so the prediction for the rest of the day, and for the same day next week, gets better.
Three live measurements matter most.
- Inflow at the lane, by minute. The actual count of passengers arriving at the queue entry, compared to the forecast inflow for that minute. A persistent under- or over-shoot in the first 30 minutes of a bank is usually the leading signal that something specific to that day is happening, whether a road delay, an upstream flight push, or a misread show-up curve for a particular route. The forecast for the rest of the bank can then be re-issued.
- Throughput at the lane, by minute. The actual processing rate per open lane, conditioned on the lanes that are open. A throughput shortfall against plan is a different signal than an inflow surge, and it asks a different question of operations: open another lane, swap an officer, move a passenger stream.
- Queue length and wait time, by minute. The output. The actual queue length and the implied wait time, compared to the forecast. The gap is what the operations director acts on, and the size and persistence of the gap tells the forecasting team how much to weight today's data when retraining the model for next week.
The point of closing the loop is not only to react better today. It is to reduce the error of next week's forecast at the same lane, on the same day-of-week, with the same booking curve, so that next week's roster is closer to right before the day starts.
Where the count comes from
All of the above assumes the live count at the lane is itself accurate. A queue forecast that is corrected by a noisy real-time count will be corrected toward noise. Two properties of the counting layer matter most at an airport control point.
- Group counted as a group, not as separate passengers. A family arriving together at a security lane is one decision and several passengers. If the counter splits them into two or three independent counts at the entry to the queue, the inflow curve will look spiky in a way the forecast cannot match, and the lane-throughput rate per officer will appear to fluctuate when it has not. Group sizing at the queue entry, derived from patented signal sensing rather than camera-based group detection, removes that noise from the loop.
- No personal data at the sensor, by design. An airport control point is one of the more sensitive measurement locations in any building. A counting method that captures no images, no faces, and no device identifiers by default is much easier to defend to a data protection authority and to a passenger advocacy group than a method that captures a video feed and then anonymises it. There is nothing to anonymise later because nothing identifying was captured to begin with.
Ariadne measures this with Hybrid Fusion, its patented camera-free method. Time-of-Flight depth sensing counts every visitor at the entrances, capturing geometry rather than images, while patented phone signal sensing follows movement through the interior, detecting the signals a phone emits even in airplane mode. The sensor streams both feeds to Ariadne, where Hybrid Fusion combines them into one trajectory per visit and computes counts, dwell, and paths. The streams carry no identifier: no MAC address, no device ID, no biometric data, and no camera is involved. Identifiers are stored only when a visitor explicitly opts in, which keeps the method GDPR-friendly and outside biometric territory.
For an airport queue forecast, Ariadne contributes the part of the stack that has to be right first: a per-minute inflow count at each control point, group sizing at the queue entry, and live occupancy across the departures or immigration hall, all without personal data at the capture point. The forecasting model, the rostering tool, and the regulator-facing wait-time reporting sit on top of that count inside the airport's own analytics environment or alongside the wider people counting stack. The sensor lineup is documented at the Ariadne hardware page, and the data handling is set out in the privacy policy.
Common modelling mistakes that produce a confident but wrong forecast
Four mistakes recur in airport queue forecasting, and each one will produce a model that looks good in backtest and breaks the first time it meets a real day at scale.
- Treating the booked-passenger feed as the inflow. Booked passengers are not the same as people in the queue. A forecast that maps the booking directly to the lane, without a route-specific show-up curve, will be late by an hour for short-haul morning banks and early for long-haul afternoon departures.
- Averaging the show-up curve across all routes. A single airport-wide arrival profile is the wrong granularity. The curve is different for short-haul versus long-haul, for premium versus economy, and for business versus leisure days of the week. Pooling them produces a curve that is correct in expectation and wrong every day.
- Forecasting inflow without forecasting throughput. A queue is a difference. Predicting one side of it and assuming the other is a constant produces a wait-time prediction that is the right shape and the wrong size.
- Reading the daily total instead of the bank. An airport with a smooth daily passenger total can still have brutally peaked banks. The relevant unit of operation at a security lane is the bank and the hour, not the day. A daily forecast hides exactly the moments the operation has to plan for.
What the operations team gets out of a useful forecast
A 4-week-ahead queue forecast that is actually used inside an airport operation produces four practical outputs. None of them are exotic. Together they are the difference between a roster that responds to demand and a roster that constantly trails it.
- A roster. Officer hours and lane openings by 15- or 30-minute slot, four weeks out, refreshed weekly as bookings sharpen and the medium-range weather forecast tightens.
- A passenger-facing wait estimate. A defensible expected wait time, hour by hour, available to airline partners and to the airport's own communications team, with an uncertainty range rather than a single false-precision number.
- A flex plan. A pre-agreed sequence of operational responses for each control point if the live inflow runs above or below the forecast: which lane opens first, which officer moves where, which passenger stream gets redirected.
- A regulator-facing record. A clean dataset of forecast, actual, and gap for each control point, by minute, that supports the airport's own performance reporting and any external service standard the airport is held to.
FAQ
How far ahead can an airport realistically forecast queue length?
A useful planning horizon at a large hub is four weeks, with a daily refresh and a sharper update at one week and at 24 hours. The 28-day horizon is what supports the roster. The 7-day horizon is where the medium-range weather forecast becomes specific enough to re-shape inflow. The 24-hour horizon is where the operating plan is issued. A forecast longer than four weeks is mostly the seasonal expectation. A forecast much shorter than 24 hours is mostly a live measurement.
Why not just rely on real-time counts to manage the queue?
Because by the time a queue is forming in real time, the airport's response options are limited. Officers cannot be summoned from off-duty. Lanes that depend on equipment cannot be opened in five minutes. Passenger streams cannot be re-signed without notice. A live count tells you what is already happening; a forecast tells you what to staff for so that the response is already in place when the inflow arrives. The two work together, with the forecast driving the plan and the live count correcting the rest of the day.
What data does an airport need to start building a 4-week forecast?
At a minimum, three datasets: a daily-refreshed booked-passenger feed by flight and hour, a historical inflow count at each control point at a minute granularity for at least a full year, and a roster log showing which lanes were open when and which officers were on each lane. With those three the model can learn show-up curves per route group, per-lane throughput by passenger mix, and the gap between forecast and actual that drives weekly improvement. Weather, event, and school-calendar features are added on top.
Does Ariadne use cameras to count passengers at security lanes?
No. Ariadne counts with Hybrid Fusion: Time-of-Flight depth sensing plus patented phone signal sensing, never cameras. Time-of-Flight captures geometry rather than images, and signal sensing captures no MAC address by default, so the measurement involves no video, no faces, and no biometric data.
How does the model handle disruptions like flight delays or strikes?
A disruption is treated as a re-conditioning event for the forecast, not as a reason to discard it. A flight delay shifts a slice of passenger inflow forward in time and changes the queue shape in a known way; the model re-issues the inflow curve for the affected window. An event like a strike at an upstream connection shows up first in the booked-passenger feed (cancellations, rebookings) and second in the live inflow count, and the model retrains on both. The point of closing the loop with live measurements is exactly to absorb these events as the day unfolds, rather than waiting for the next weekly cycle to learn from them.
