Service Management and Artificial Intelligence

Updated May 12, 2025 at 3:40pm: The text of the summary explaining the motion has been changed.

A motion before the TTC Board meeting on May 14 seeks to have staff examine ways to make service more reliable:

TTC4.9 – Optimizing Scheduling Efficiency and Enhancing Service Planning Using Technology – by Chair Jamaal Myers, seconded by Commissioner Dianne Saxe

Recommendations

Chair Jamaal Myers, seconded by Commissioner Dianne Saxe, recommends that the TTC Board:

1. Direct TTC staff to conduct an analysis of surface corridor TTC routes where multiple TTC routes operate on the same corridor to optimize scheduling efficiency, improve blended headways and customers wait times and identify opportunities and implications for scheduling and operational adjustments that minimize bunching and gapping and enhance coordination between routes serving the same corridor.

2. Direct TTC staff to explore opportunities to use artificial intelligence (AI) and predictive analytics to enhance our service planning and scheduling and management of gapping and bunching, and report back through the Strategic Planning Committee on best practices and priority actions to be integrated in the 2026 Operating and Capital Budgets.

Summary

Original version: This motion directs staff to review bunching and gapping on all routes where multiple TTC routes use the same corridor to explore how scheduling can be optimized to improve headways and reduce bunching and gapping of vehicles. This motion also directs staff to explore how Al and predictive analytics can be used to enhance service planning and the management of gapping and bunches on all routes and make recommendations for priority actions that could be integrated into the 2026 Operating and Capital budgets.

Revised version: Currently, TTC vehicles are not considered “bunched” for purposes of route planning, if multiple buses are traveling together so long as they are representing different bus routes. This motion directs staff to review bunching and gapping on all routes where multiple TTC routes use the same corridor to explore how scheduling can be optimized to improve headways and reduce bunching and gapping of vehicles. This motion also directs staff to explore how Al and predictive analytics can be used to enhance service planning and the management of gapping and bunching on all routes and make recommendations for priority actions that could be integrated into the 2026 Operating and Capital budgets.

There are several problems with this motion, but a few are key.

  • The idea of a “scheduled” time simply does not work especially when service is fairly frequent. Riders care about regularity, not that each bus or streetcar is spot on its assigned time. Yes, of course, if the service were “on time”, it might also be regular, but forcing this to occur is counter-productive. The question is how to ensure reliably even spacing between vehicles.
  • The TTC’s Service Standards and the rules operators are supposed to follow are based on the schedule, but this is not a workable guide to running service under typical conditions found on busy routes. If the TTC really wants evenly spaced service, then this should be the standard the organization aims for.
  • There will always be some variation between ideal and actual vehicle locations whether this is measured by a schedule or by a target headway spacing. That’s the nature of transit even on a completely protected route like the subway. The goal is to control and minimize this variation before small problems become very large ones.
  • Many streets are served by a single route with no branches or overlaid service, and headways are not reliable. This problem shows up throughout the day, not just in periods where external forces such as surge loads, traffic congestion and plagues of frogs can be blamed. The TTC should learn how to run “simple” routes reliably, and then we can talk about more complex route structures.
  • “Artificial Intelligence” does not learn out of thin air, but from a combination of examples and goals. If we train bots on the collected works of Donald Trump, don’t expect Shakespearean verse. So it is with Toronto’s transit. The current system is hardly an example to learn from, and even with input from other cities, the basic question of goals must be answered. If we tell the bot to optimise for general traffic and transit will benefit oh-by-the-way, the bot will quickly say “look at all those cars” and move them as quickly as possible.

I have written many articles reviewing service behaviour on routes, and the problem of irregular service has, if anything, grown worse over the years. In “the old days” there were issues with the adequacy of scheduled travel times combined with growing traffic congestion, and this led to lengthened trips. Even where operators get adequate time for terminal breaks, this does not guarantee reliable service, although it does reduce the need for short turns.

Those short turns are a valid response to service problems. For a time, a simplistic embargo on this service management technique actually worsened bunching because gaps could not be filled by a judicious turnback. Vehicles stayed in bunches.

TTC management, with the tacit approval of the Board if only through their ignorance, produced reports showing that on average the service wasn’t too bad. “TTC’s goal is to have 60% of all trips meet the on-time performance standard.” [Service Standards at p. 15] This is an all-day average and individual periods could vary without affecting the overall metric.

Every rider knows that the “average” service is not what pulls up (or not) to their stop every day.

Quality is measured only from the terminal, and two closely-spaced cars will run nose-to-tail fairly quickly because the first one does all of the work. They will stay together for an entire trip, and possibly the return.

Service standards allow vehicles to be up to five minutes late, but on a frequent route that can mean long gaps are followed by a pair of vehicles. Oddly enough, the standards actual recognize that riders care more about vehicle spacing for frequent services (10 minutes or better) than if buses are on time, and yet the metric routinely used by the TTC is schedule based, not headway based.

This not a scheduling problem, but a policy and management that aim low. It’s easy to get a gold star on an exam where you can be almost correct, and then only 60% of the time.

Traffic congestion, construction delays and special events generating surge loads are predictable to a point, although traffic accidents are not. The question is how the TTC deals with these events. Either all schedules are padded on spec in case of delays, an expensive way to deal with an issue that does not affect most routes at most times, or there has to be a recognition that scheduling alone will not solve the problem.

Blended Services

As for corridors with overlapping services, there are three major groups, and some of these overlap.

  • The simplest case is a route with an “A” and “B” branch. They start from a common origin, typically a subway station, but go to different destinations. On the outbound trip, uniform service is a question of evenly spaced terminal departures. On the inbound trip there is a greater challenge because the branches should merge on an even headway. This does not happen and there are many examples where bunching occurs regularly.
  • Where there is an express and local branch, self-evidently they will not run on an even spacing except from a common dispatch point. By definition, the express buses will pull away from the locals. The uneven spacing should only affect riders at common stops where they have the option of taking either service, but the individual services can themselves be uneven. The time saved by an express might be less than the extra time awaiting its arrival.
  • Where multiple routes overlap, typically on major corridors leading to subway terminals, the scheduled frequency of each route is rarely the same. Buses will show up irregularly even if they are precisely on time. Where they do share a common headway, then they could be scheduled to blend but this is not the typical case.

Examples of each type of service pattern are easy to find. Some are relatively simple such as a route with two alternating destinations. Other routes have multiple branches or turnback points where the level of service drops off on outer segments. A few routes have “branches” that exist in name only because their headways are not blended with the primary route, and these are effectively separate routes. Those buses will show up at odd intervals because they have not been integrated in the route overall. Improving service so that all branches blend on paper will not guarantee they will on the street, and could be a waste of resources.

Some routes that formerly shared a route number now operate as separate services. For example, the 70 O’Connor had two branches, one to Eglinton and one to Warden Station. The blended service, especially inbound to Coxwell Station could be quite erratic even though on paper everything looked fine. Now the 70 O’Connor runs to Eglinton and the 8 Broadview runs to Warden Station with no attempt at blending the infrequent 8 with the more frequent 70.

The 54 Lawrence East bus has two branches, the 54A to Starspray Loop and the 54B which turns back at Morningside. Inbound from Starspray, the service is already ragged with the standard deviation of headways being over 5 minutes most of the time. This means that the service from the terminal widely varies from the TTC’s own standards. By Markham Road when the two branches should be blended, the actual headways range from almost 0 to 15 minutes and more on what is supposed to be a blended service. By Yonge Street, the average headway and the standard deviation are equal showing that the buses are running in pairs. The situation is only slightly better eastbound, and pairs of buses are common leaving Eglinton Station.

Again, the schedule shows a regular headway, but the actual operation does not.

The situation is more complex on routes with multiple branches like 52 Lawrence, and on routes that branch at both ends like 504 King. Pairs of King cars from each branch are quite common.

A schedule designed for a “typical” day will have problems when demand is heavier, or there are special events or diversions or bad weather. If too much padding is used to offset the worse days, then vehicles run unusually slowly if they are to stay “on time”, and queues at terminals can foul operations.

Many of the problems lie not with the schedules, but with the real world in which the service operates, and in the degree to which, if any, the TTC actually attempts to provide regularly spaced service. It is easy for a route to go from being just a little bit “off” to having a major failure in service quality if nothing is done to correct problems as they develop.

The Role of Artificial Intelligence

A basic point with any analysis, be it human or computer-driven, is the goal or premise one seeks to achieve or prove. If the underlying assumptions are faulty, and unless the analysis asks whether we are really looking at the right problem, it can fail. Even worse, if the tool becomes more important than the task, the analysis can be skewed to fit what the tool can do, or at least the claims for what it can achieve.

As a starting point, does the TTC even know and acknowledge how bad service really is at the granular level of individual routes, times of day and location? Monthly Key Performance Indicators summarize “on time performance” across all routes. In January 2025, TTCRiders and I both published analyses of detailed on time data and the results were not happy reading. See Delving Into TTC “On Time” Performance.

The premise of the motion before the TTC Board is that there are issues of both scheduling and service management that could improve operations. What is missing is the basic question of whether we have a valid model for what “better service” might look like? How would this fit into a real-world operating environment? Are we prepared to invest resources in real service improvement rather than assuming we can simply tweak current operations and schedules to yield noticeably better service?

Is this a question of poorly used or inadequate resources? If we devote more resources to “management”, what should they manage? What are their goals? What are they trying to fix?

There is an inherent conflict between “scheduling” and “managing” service. One lives in an artificial world where conditions never change – buses and streetcars take their assigned times between points “A” and “B”. The real world is dynamic and never quite the same two days, nay even two hours, in a row. No schedule can be built for all conditions, and managing to the schedule will only work for conditions close to those the schedule foresees.

Toronto plans to implement an AI-based system to manage traffic signals. There is an important difference here. The system will adapt to current conditions rather than attempting to force the traffic to behave in some pre-ordained way. Moreover, the signal programming would be based on how the network behaves as well as past experience with similar conditions.

The transit component, however, belies a car-oriented outlook for the system’s goals. Transit vehicles will get priority if they are “late”, but otherwise will take their chances. This effectively locks in a schedule design that could be overly generous assuming traffic will always be in the way and is more important most of the time.

On King Street, we had a brutal example of the combined effect of laissez-faire management with changes in traffic conditions. Even before the worst of hour-long trips across the core, the effect of traffic diversion from Adelaide and occasional lane blockages on King pushed the street beyond its limits.

The largest problem was “box blocking” by motorists entering but not clearing intersections. This was fixed with the low-tech solution of police and traffic wardens who simply enforced the rules and restored lost capacity to intersections. AI driven traffic signals would not, could not have achieved the same effect.

There is a danger that TTC will launch into a study without addressing basic questions about where service problems arise. How much can they, could they control? How much really is due to external factors, some random, some as predictable as the sunrise? Even worse, Toronto could descend into the dreaded realm where “we’re studying it” and nothing happens pending the outcome.

A thorough study of how transit service works, or doesn’t, is long overdue, but this should not assume that a magic bullet called AI that will eliminate problems, especially if service metrics continue to hide what is happening in the day-to-day world of transit riders.

8 thoughts on “Service Management and Artificial Intelligence

  1. I have always thought that Myers and Saxe were among the most ‘aware’ “Commissioners” and (like you) was somewhat disappointed to see them wanting more effort to improve ‘schedules’ rather than to look at proper route management. It also seemed unwise to start this process by looking at the more complex streets with multiple routes than to learn from the simplest ones before venturing into the most difficult.

    Steve: Coming soon: a review of 7 Bathurst which has no branches and a simple 10-minute all day schedule. Reality is somewhat different.

    Like

  2. Steve, allow me to quibble with you regarding one point you raise.

    I grew up in the Ottawa burbs, but now live in the Toronto core. I agree with you that in the core regularity and headway are more important than schedule … especially on (streetcar) lines with frequent service.

    However in the burbs with relatively infrequent service I think schedule is more important. It’s no fun, especially in winter, to be peering down the road wondering where the scheduled bus is (been there, done that!) Granted, mobile real time GPS transit apps mitigate this to some degree.

    Steve: I agree, and make that point in the article. However, the majority of TTC service are supposed to run every 10 minutes or better, but do so only on average.

    Like

  3. AI: it’s a floor wax and a dessert topping!

    It may be possible that AI can help in some aspects, but it will not be as simple as going to ChatGPT and querying “How can I make my TTC route work properly?” Not nearly that simple, nor that inexpensive.

    Like

  4. Once again, Steve has showed up the complexities of the existing service as well as any efforts to improve it, and it is a rather large and sprawled motoropolis to try to service. So, with these degrees of challenge, it’s not so surprising that the drive-by-downsized Council is struggling to get atop the issues, where the carservatives are happy to have made a big mess of it all, because we want to bury billions in less-wise projects as another way to bankrupt the systems. So can we ask for AI to design a subway project or three? Also, perhaps a typo in this: ” the bot will quickly say “look at all those cars” and move them as quickly as possible.” Did Steve mean BoT?

    Liked by 1 person

  5. The question we should be asking AI is how to move “people” more efficiently, not how to move “vehicles”. Since a streetcar can carry between 70 to 200 people, versus a SUV that carries between 1 to 5 people, priority should be given to the vehicle that carries more people.

    Steve: Of course AI’s ability to do this depends on knowing about passenger loads. “You’ve got to be carefully taught” as the song goes.

    Like

  6. I have been watching some YouTube vids of trams in The Hague. On the dash there sits a display that seems to show a count that move from red to green, and in numbers that seem to relate to time (minutes I think.) I don’t know if it is tied to the schedule or to the spacing to the next tram. However, the operator will run slower when the numbers are green (or hold at a platform) and then will run faster when the numbers are in the red.

    Could a system based on route and GPS be used to “space” buses and trams in Toronto? Could a digital record of the drivers “in the zone (+/- 5 min.)” be used to offer a performance bonus?

    Steve: The dashboard displays in Toronto already have a vehicle position display, but the TTC’s metric is “on time” even though this can conflict with evenly spaced service. In reply to a previous comment on the Bathurst bus thread, I noted that there are many factors to be considered including how TTC measures service quality, as well as rules for crewing and relief breaks. TTC already flags early terminal departures, but this is a tiny part of a much bigger problem. For example, if every bus on a route is 10 minutes late, the riders still see regular service, but the TTC’s on time stats will be crap. There will be no departure management at terminals because everyone’s behind schedule. It is not a simple problem, and requires change on many fronts, not to mention the acknowledgement that change is necessary.

    Like

Comments are closed.