Almost every scheduling and planning vendor now sells "AI". Some of it is genuinely new: machine learning models that predict running times by time band, or ridership models that estimate the effect of a network change before it goes live. Some of it is decades-old operations research with a new label. And some of it, especially anything described as "real-time network rebalancing", is still mostly at the pilot stage.
For a transit agency or operator, the useful question is not "should we use AI?" but "which planning task, which algorithm, fed by which data?". The answer to the last part is the same almost every time: the algorithm is only as good as the actual (as-run) data coming out of the AVM system. An optimiser fed with scheduled running times, rather than measured ones, will produce a very precise answer to the wrong question.
This article separates what is operational today from what is marketing, with verified examples from Barcelona, Dublin, the Nordic capitals, London and Chicago.
What "AI" actually covers in bus planning
| Planning task | Typical technique | Maturity in operations | Data it depends on |
|---|---|---|---|
| Running-time calibration | Statistical analysis, machine learning on historical trips | Mature, widely used | AVM segment running times by time band |
| Vehicle and crew scheduling (blocking, duties) | Mathematical optimisation (operations research) | Mature since the 1990s | Timetable, running times, labour rules |
| Frequency setting | Load profiles plus optimisation or rules | Common, often semi-manual | APC loads, ticketing, AVM punctuality |
| Demand and ridership forecasting | Machine learning, travel models, third-party mobility data | Growing, used for scenarios | Ticketing, APC, census, mobile data |
| Network redesign | Human-led design supported by scenario tools | Tools mature, design remains human | All of the above |
| Real-time rebalancing (holding, short-turning, extra vehicles) | Rules, decision support, some ML | Controller-led today, algorithmic control mostly in pilots | Live AVM positions, headways, loads |
Two points stand out. First, the most mature "AI" in the table, crew and vehicle scheduling, is classic optimisation, not machine learning. Second, every row depends on as-run data. Without it, none of these tools has anything real to learn from.
Running times: where the data problem starts
Running-time calibration is the least glamorous task and the one with the clearest return. Times that are too tight mean buses late all day; times too generous mean early running and paid hours the operator does not need.
This work predates the AI label. GIRO's HASTUS-ATP module, documented in 2011 and developed with Transports Metropolitans de Barcelona and the University of Barcelona, calculates optimum run times and minimum layovers from historical AVL records. In London, TfL's iBus system, which covers more than 8,000 buses, has been used to compute actual run times between timing points by time-of-day period so that operators can submit more realistic schedules, as described by Hounsell, Shrestha and Wong in Transportation Research Part C (2012).
What machine learning adds is finer granularity and the ability to combine more variables: historical running times, traffic patterns, weather, school calendars, all by segment and time band. Predictive running-time features are now offered by most scheduling and planning tools. When a recalibrated route improves, though, the decisive input is rarely the model. It is a season of clean, trip-level positioning data on the routes that matter, cross-checked against what the AVM recorded.
Be careful, too, with how gains are reported. A punctuality rate that rises from 80% to 90% is a 10 percentage point improvement, but a 12.5% relative increase. Both figures are correct; they are not the same number, and tender evaluations should state which one is meant.
Garbage in, garbage out is measurable
The typical failure modes are well known to anyone who has audited an AVM feed. Position update intervals that are too long make stop arrival and departure detection unreliable. Low driver login rates leave many trips impossible to match to a vehicle. Geofence-based stop detection can distort both punctuality figures and measured run times.
Feed a running-time model with those errors and it will confidently recommend schedules calibrated to artefacts. This is the core point of the whole topic: AI planning tools do not fix bad AVM data; they amplify it.
The reverse is also true. In the Helsinki region, HSL publishes positions with most vehicles reporting once per second, together with stop arrival, departure and door events: that is the level of detail a running-time model can actually learn from.
Network redesign and demand forecasting: tools assist, people design
The best-known network redesigns of the last decade were not produced by algorithms. In Dublin, the National Transport Authority's BusConnects redesign started from a 2017 options report by consultants Jarrett Walker + Associates, went through several rounds of public consultation from mid-2018, and has been rolled out in phases since June 2021. In its March 2025 progress report, the NTA stated that passenger numbers in areas where the new network had been implemented had increased by 48% by the end of 2024, against 8% on the rest of the network. Barcelona's Nova Xarxa, an orthogonal network studied by Badia, Argote-Cabanero and Daganzo (UC Berkeley, 2016), attracted more demand than the old network, with around 26% of trips involving a transfer by the end of 2015.
Where software now helps is in scenario testing. Current planning tools can estimate the ridership effect of a network change from observed trip data, and some display observed stop-by-stop run times directly in the timetable editor, so planners see where actual departures diverge from planned ones. Vendors increasingly package these functions as "AI platforms" covering planning, scheduling and operations. The useful test for a buyer stays the same: which data feeds each prediction, and how recent it is.
Demand forecasting also depends on what the vehicle measures. Ruter in Oslo began installing automatic passenger counting and other sensors on more than 400 buses from 2016, then moved towards an open ITxPT-based onboard architecture. HSL's high-frequency feed in Helsinki also carries an occupancy field alongside door events. That kind of granular, standardised feed is what makes load-based frequency setting credible rather than guesswork.
The honest summary: machine learning improves the forecast for each scenario. Choosing the scenario (coverage versus frequency, where to force transfers, what to tell the public) remains a political and professional decision.
Scheduling and blocking: the mature part
Vehicle blocking and driver duty construction are where optimisation has been embedded longest. Scheduling and planning tools, HASTUS among the longest established, solve large combinatorial problems (which vehicle covers which trips, how duties respect labour agreements, relief points and depots) to save vehicles and paid hours.
Two caveats matter for buyers. First, the optimiser treats running times and layovers as inputs. If those inputs come from the old timetable rather than measured data, a "more efficient" block can simply mean removing recovery time that the road network does not actually allow, which then shows up as lateness and lost trips. Second, newer generative AI features (natural language queries, assisted setup) change the interface, not the underlying maths.
Real-time rebalancing: what exists today and what is still a pilot
This is where the gap between marketing and operations is widest.
What is standard today. Control rooms already rebalance service in real time: holding a bus at a timing point, curtailing (short-turning) a late bus to fill a gap in the opposite direction, inserting a spare vehicle, or switching a high-frequency line to headway-based regulation. TfL describes curtailments as decisions where "circumstances will normally determine the best course of action", in response to a Freedom of Information request. These decisions are made by controllers using AVM displays, rules and experience. Software increasingly suggests actions, but a human decides.
What has been tested in the field. Stockholm ran regularity-driven (headway-based) operation trials on its trunk bus lines, analysed by Oded Cats in Transport Policy (2014), who concluded that regularity requires changes across planning, operations and monitoring, not only a control algorithm. More recently, the Chicago Transit Authority tested a headway control decision support system on Route 81 (October 2022, terminal holding) and Route 66 (November 2023, en-route holding). Wait times fell by 8.7% in the AM peak and 19.9% in the PM peak on Route 81, and by 5.8% in the PM peak on Route 66, with 90th percentile loads down 5.5%. But driver compliance with holding instructions was only 35% on Route 81 and 56.9% on Route 66, and experienced drivers complied least.
What is still mostly research. Reinforcement learning for bus holding and fleet control is an active academic field, but the large majority of published results are simulations. Fully automated rebalancing, where an algorithm dispatches extra vehicles or short-turns buses without controller approval, is not standard practice at any large network we could verify.
| Real-time action | Status in 2026 | Main constraint |
|---|---|---|
| Controller holding, curtailment, spare bus insertion | Everyday practice | Controller workload, visibility |
| Headway-based regulation on frequent lines | Deployed on some lines | Driver acceptance, labour rules |
| Algorithmic holding recommendations | Field pilots (e.g. CTA) | Compliance, trust, data latency |
| Fully automated dispatching and short-turning | Research and simulation | Safety, accountability, data quality |
Surveys on both sides of the Atlantic point the same way. UITP, the international public transport association based in Brussels, found in its study "Moving Forward with Artificial Intelligence in Public Transport" (February 2020, 48 responding public transport organisations) that real-time operations management and customer analytics were the most common AI applications, each used, tested or offered by 25% of respondents, while network planning and route design still had relatively low uptake. Six years later, APTA's AI primer (May 2026), based on a survey of 32 North American member agencies, describes agencies as "piloting, learning, and scaling", with operations among the areas of highest planned adoption, not current maturity.
What this means for an operator or transport authority
Before buying an AI planning module, check the foundations:
- Measure running times by segment and time band, not only end-to-end, and over enough weeks to separate recurring patterns from incidents.
- Audit AVM data quality: position update interval, trip assignment rate (driver login), stop detection method, share of trips with complete records.
- Link loads to trips: APC or ticketing data only supports frequency decisions if it is matched to the trip actually operated.
- Close the loop: compare each new timetable with as-run performance after it goes live, and feed that back into the next calibration.
- Treat real-time AI as decision support first: design for controller and driver acceptance, as the CTA pilots show compliance is the binding constraint.
This is also where the AVM earns its place in the planning chain. An AVM does not redesign the network, but it produces the as-run data (trips operated, segment running times, punctuality by stop and time band, kilometres) that every planning tool, AI or not, needs to be right. In Pysae, that data comes from Operations, the real-time AVM module, while Network is the module where transport plans are edited with AI assistance and exported in GTFS and NeTEx.
FAQ
Can AI design a new bus network on its own?
No. Tools can generate and evaluate scenarios and forecast ridership, but the redesigns that worked, such as Dublin's BusConnects or Barcelona's Nova Xarxa, were led by planners making explicit trade-offs with public input.
What data do I need before using predictive running times?
Trip-level AVM records with accurate stop arrival and departure times, a high share of trips correctly matched to vehicles, and at least one full season of history per route and time band.
Is real-time rebalancing by AI in use today?
Controllers rebalance service every day with AVM tools. Algorithmic recommendations have been tested in field pilots such as CTA's in Chicago. Fully automated dispatching remains research.
Sources: Hounsell, Shrestha, Wong, "Data management and applications in a world-leading bus fleet", Transportation Research Part C (2012); TRID, "ATP: Run-time analysis and improved punctuality" (GIRO, 2011); National Transport Authority, "BusConnects Network Plan sees spike in passenger numbers in Dublin" and BusConnects Dublin Progress Report (March 2025); Badia, Argote-Cabanero, Daganzo, "Network effects in bus transit: evidence from Barcelona's Nova Xarxa" (UC Berkeley, 2016); HERE, "What Oslo's buses can teach us about data collection" (Ruter); Digitransit, HSL high-frequency positioning API; TfL FOI response on bus curtailment (WhatDoTheyKnow); Cats, "Regularity-driven bus operation", Transport Policy 36 (2014); Rodriguez et al., "Deploying robust decision support systems for transit headway control", arXiv 2509.08231 (2025); UITP, "Moving Forward with Artificial Intelligence in Public Transport", Action Points (February 2020); APTA, AI and ML in Public Transit primer (May 2026).