Public transport route optimization: where the plan breaks down
The route network plan is almost always calculated on averages: average headway, average daily passenger flow, average travel speed.
On the street the picture is different — uneven passenger flow means the morning peak takes a quarter of the daily volume, and at transfer hubs boarding comes in waves of 5–7 minutes.
A headway that is even on paper falls apart during peak hours: one delay at a hub pulls the next one, and after two runs, paired vehicles and gaps of 20 minutes appear on the route.
Deviations from the schedule accumulate in a cascade because the schedule accounts for neither the turnaround time at the terminus nor the actual dwell time for boarding. The dispatcher closes gaps manually — shifts a trip, shortens a run, puts a spare vehicle into service.
Each edit lives in a separate spreadsheet, versions diverge, and within a season no one can say which one is current.
Data diverges from reality no less: gaps in vehicle tracks, missing validator records, seasonality coefficients calculated once and never revised.
Errors accumulate from season to season, and public transport route optimization slides back into working on averages that do not exist on the street.
We break down how this is closed — from consolidating actual data into a single model to recalculating headways and schedules for real flow.
What changes after implementation: headways, service, failures
The effect of implementation is visible not in a report but in the schedule and at the stop. Below are the checkpoints we use to verify the result: each is calculated on real data extracts and compared with the state before launch.
We take benchmarks from industry measurements, not presentations — for example, regularity and waiting time indicators according to UITP.
If a metric does not move, the passenger flow forecasting model failed to account for local factors, and we retrain it on data from the specific fleet.
| What we check | How we measure | What we consider normal |
|---|---|---|
| Headways | deviation of actual headway from planned for each trip | the spread shrinks severalfold, "train" bunching of two vehicles on the route disappears |
| Service on the line | comparison of the number of vehicles on the route with hourly passenger flow forecast | during peak, service increases; during off-peak and on late trips it decreases without overcrowding |
| Passenger flow forecast | day-ahead and week-ahead forecast error versus actual validator data | the error stays within limits at which the service decision is not manually overridden |
| Waiting time at the stop | share of waits longer than the stated headway | long waits cease to be widespread on regular routes |
| Eliminated failure class | analysis of off-route incidents: schedule disruption, headway gaps, insufficient service | these failures leave the regular set; external causes remain — accidents, weather, roadworks |
We verify the checklist on pilot routes before scaling: if headways and service behave predictably on two or three corridors, the model is transferred to the entire network.
System design options: from schedules to a digital twin
The fork at the start is not "which algorithm is more accurate" but which control loop you are prepared to maintain continuously. The four options differ in data source, recalculation frequency, and who makes the final decision: the dispatcher or the system.
| Option | When it fits | Limitations |
|---|---|---|
| Manual schedule | Network of up to a dozen routes, even passenger flow, edits twice a year | Cannot keep up with deviations: every failure is handled manually, quality depends on one specialist's experience |
| Historical forecasting model | Need to recalculate headways from accumulated data, no proprietary telemetry yet | Does not see the current situation: during a road closure or failure, the forecast diverges from reality |
| Digital twin of the route network | There is a stream of current traffic data, decisions need to be tested before service on the line | Requires more support resources: network model, up-to-date reference data, update regulations |
| Hybrid control mode | Some routes are automated, the rest remain with the dispatcher | A clear boundary of responsibility and a handover procedure are needed |
The options are not mutually exclusive: a manual schedule grows into a forecasting model, which grows into a digital twin when a stable data stream appears. The choice is fixed at the survey stage — it determines the scope of work and which checks go into acceptance.
How implementation proceeds: stages of engineering work
Implementation proceeds in waves: first we fix what data the system will calculate on, and only then do we change schedules. The order of stages is not rearranged — a model configured on inconsistent data produces beautiful reports and incorrect headways on the line.
-
Data source audit. We review validator logs and vehicle tracks, work orders, current schedules, and passenger complaints. We check completeness by day of week and season, consistency of trip counts, time drift across different vehicles, duplicates, and recording gaps.
The output is a list of suitable sources, their update frequency, and a list of discrepancies to close before launch.
-
Route network schema. We build a graph of stops and segments, travel time by segment broken down by hour of day, boarding and alighting time, transfer points, and shared segments.
We coordinate disputed segments with dispatchers — they know where the schedule diverges from reality.
-
Model setup. We define the objective function: waiting at the stop, number of transfers, adherence to headways. We separately specify constraints — vehicle allocation to the route, driver working hours, capacity.
-
Forecast validation on historical slices. We run the model on past periods and compare with actuals, not theory. We look at deviation from schedule, average waiting, share of trips with transfers; where the discrepancy is persistent, we rebuild the input data.
-
Dispatcher panel setup and training. We show how to read recommendations, what to do when sensors fail, and how to return to manual mode. We conduct debriefs on disputed situations and leave short shift regulations.
-
Handover to operation. We fix roles and access, the model update schedule, and the data quality control procedure. Then we provide support: we fine-tune weights based on feedback from the line and analyze deviations that accumulate between schedule revisions.
What the customer retains: models, regulations, documentation
The route optimization system lives not only in code — it relies on data, access, and regulations.
We hand over everything needed for independent operation and development: no component remains a "black box" that cannot be checked, reconfigured, or replaced by your own team.
What exactly the customer retains:
- System configuration — weights of calculation criteria (travel time, number of transfers, vehicle occupancy), planning horizons, schedule formation rules. Parameters are moved to separate files rather than hardcoded: editing does not require a rebuild and release.
- Route network schemas — topology of stops and connections between them, service zones, restrictions by rolling stock type. In machine-readable form with format description, so the network can be edited and checked automatically.
- Access policies — dispatcher, analyst, and administrator roles, boundaries of their rights, access granting and revocation procedure, action logging. It is visible who changed the schedule or calculation parameters and when.
- Data update regulations — frequency of loading passenger flow, street geometry, and traffic situation data, persons responsible for each source, system behavior when data is unavailable or inconsistent.
- Dispatcher instructions — how to read schedule deviations, when to trigger manual recalculation, what to do during a failure or mass event, how to record an incident and pass it on.
- Exchange interface descriptions — export and request formats for adjacent systems (ticketing, navigation), examples of correct responses, and typical errors.
- Recovery scenarios — backups of configurations and models, procedure for rolling back to the previous schedule version, criteria under which a rollback is considered successful.
Case study: how schedule deviations were reduced on a city network
A city network operator — several dozen routes and hundreds of trips per day.
By evening the schedule diverged from reality: dispatchers adjusted the timetable manually, schedule deviations accumulated up to 6–8 minutes, and failed trips were covered by spare vehicles "as needed".
What we found in the data
We collected telemetry for a month for each trip: actual headways, travel time by segment, dwell times and layovers at turnarounds.
More than half of the deviations were caused not by traffic jams but by a mismatch between the plan and the flow — planned travel time on four segments was shorter than actual. The forecast model by hour of day and day of week separated predictable dips from one-off failures.
What we changed and what the measurements showed
We rebuilt the schedule for actual travel time profiles, added a rolling reserve on routes with a wide headway spread, and set up dispatcher alerts when a trip goes beyond the deviation corridor. Metrics before and after:
- trip regularity: 82% → 96% completed on schedule;
- headway spread on peak segments: ±7 minutes → ±2.5;
- failed trips on the line: 4.1% → 0.8% of service;
- share of trips covered by spare vehicles "after the fact" decreased fourfold.
A quarter later, the result was confirmed by an independent measurement: inspectors from Urban Transport Management Center rode routes according to the schedule and compared actuals with the plan — the discrepancy stayed at the same level and did not return after a month. We consider the implementation case closed when the metric is visible not only to the contractor.
How a digital twin of the route network differs from a conventional model
A statistical model relies on historical statistics: it averages passenger flow by hour, day of week, and season and builds demand forecasts on that basis. Such a forecast honestly describes demand that has already formed, but it does not know that the network itself has changed.
Move a stop, add a dedicated lane, shorten a headway — the model will continue calculating from the old profile until new history accumulates.
A digital twin is a connected dynamic copy of the network: routes, schedules, rolling stock allocation, transfer hubs, and actual passenger flow live in one model and are recalculated as data arrives. Historical statistics are not discarded but become a baseline profile that current events adjust.
The key difference is scenario testing. The twin runs a schedule variant or a new route before it goes on the street and shows how flows will redistribute, where waiting time will increase, and which hubs will become overloaded.
A statistical model cannot answer such a question: history has no data about what has not yet happened.
The twin has limits of applicability. It requires frequent telemetry and regular passenger flow measurements: with sparse or incomplete data, the model begins to refine itself and produces a confident but incorrect result.
One-off events — road closures, accidents, mass events — enter it as external disturbances, not as part of the forecast.
The choice here is not "twin or statistics" but "at what horizon the answer is needed." For planned service, a historical model is sufficient; for decisions that change the network, a twin with scenario testing is needed.
Technical concerns: data, accuracy, integrations
Technical concerns are usually the same: whether there is enough data, whether the forecast can be trusted, and how to integrate the system into the current control loop. We address them with concrete checks, not promises.
Inputs include vehicle tracks, actual schedules, validator records, weather, and city events. We take history from several past periods so the model sees weekdays, weekends, holidays, and peaks rather than an average day.
Data is scattered across systems and manual spreadsheets — where do you start?
With a source map: what already exists, in what form, and how often it is updated. Then a layer that brings route, stop, and time data to a single schema. Manual spreadsheets are replaced by automated export — otherwise calculations run on outdated slices.
How is forecast accuracy checked if no one measures it now?
By retrospective backtesting: the model trains on an old period and predicts the next one, which we already know. We calculate error separately for peak hours, off-peak, and weekends.
Seasonal spikes — school year, vacations, holidays, mass events — are separate features, not an eyeball adjustment.
How does the system integrate with the dispatch center, and can it be launched in parts?
Through an exchange layer: the system reads the current state and provides recommendations without breaking the existing loop. The dispatcher sees the proposal next to the actual picture and can reject it — the reason for rejection returns to the model. Expansion is gradual: first one corridor in advisory mode, automation after stable results.
Let's discuss the task: where work on the system begins
Work begins with a pre-project meeting: we discuss what task the system should solve — reduce waiting time, relieve transfer hubs, or redistribute rolling stock between routes.
At the same meeting, we record what data you already have and in what form, and what will have to be collected.
Next, a data list is needed — without it, any estimate will be approximate:
- Movement data: stop passage records, history of delays and schedule deviations over several seasons, including periods of failure.
- Current schedules and route service allocations — in the form in which the dispatch service provides them.
- Network schema: stops, segments, transfer hubs, restrictions on dedicated lanes, turnarounds, and operating hours of segments.
- Passenger flow by stop and hour of day — even approximate, it is needed to test hypotheses before work begins.
- Acceptance criteria: what exactly we consider improvement — headway evenness, travel time, share of failed trips, or transfer connectivity.
Based on this picture, we return with an estimate and work plan: scope, stage order, dependencies, and risks. The first step is a pilot area on several routes, where hypotheses are tested on a live schedule and the actual effect is visible.
The order of expansion to the entire network is determined based on pilot results, not in advance on paper.
Describe the task and what data you already have — we will return with an estimate and work plan.
