1 / 48

Using technology to enhance bus services

Explore how Transport for London leverages technology to optimize bus services, monitoring performance metrics, enhancing reliability, and improving overall operational efficiency.

lsylvestre
Download Presentation

Using technology to enhance bus services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Using technology to enhance bus services Nigel Hardy ‘Formerly of’ Transport for London

  2. Transport for London • Population 8.6 million (2030, 10 million+) • TfL: 28,000 employees, 2015-16 budget £11.6bn • Delivers Mayor of London’s transport strategy • Mix of fares, central govt funding, borrowing • London Underground, Rail, Crossrail, Surface Transport • Surface Transport: Buses, roads, trams, taxis, river, cycle hire, walking & cycling strategies • Buses: 24/7 operation, 700+ fixed routes, ~9,000 buses, 19,000 stops, 25,000 bus drivers • 21 Bus Operators, 90 garages • TSG: technology arm of Buses

  3. Daily journeys in London • 30 million journeys in total • 6.5 million journeys are made on London’s buses • half of all public transport use by Londoners • 3.4 million on the Underground (Metro) • 2.9 million on other rail • 6.2 million on foot • 0.6 million by bicycle • 10.2 million car / motorcycle trips

  4. Technical Services Group, Buses • 2003-2017: delivery of iBus project (£119m) & ancillary products, now <100 people. • Procurement, requirements, delivery • Radio & AVL system (supplied by Trapeze) • Navigation • Equipment rollout & maintenance • Networks • Service Control • Base data, schedules, routes/stops • Historic data & reports • Ticketing, CCTV • Rationalisation, Systems analysis, Future requirements

  5. iBus Business Model & Technology tools Tendering & Schedules Contracts On-Bus R.T.I (fixed signs, mobile web) Passengers Passenger Data Analysis Network Planning/ Development Radio & Service Control Operations Passengers Performance Monitoring Historic Reports Operator Payments £1.6 billion per year

  6. About me…. • Technical analyst • Performance assessment, navigation, prediction • Software design/test (iBus performance reports) • Benefits realisation programme for iBus

  7. 1) Automating bus performance monitoring

  8. Bus Service Metrics - Reliability Aggregation: London network, Operator, Garage, Route, Bus Stop

  9. Bus Service Metrics - Operated mileage • ‘Mileage Operated’ % = km operated / km scheduled • Reasons for lost mileage (TfL use 20 different categories) • ‘Deductable‘ lost mileage: ~0.5% (the Bus Operator is at fault) • Mechanical failure (0.4%) • Staff shortages (<0.1%) • Other deductable (<0.1%) • ‘Non-deductable’ lost mileage: ~1.8% (the Bus Operator is not at fault) • Traffic (~1.8%) • Other non-deductable (<0.1%)

  10. Organisation of buses in London

  11. Bus contracts over time • Route by route basis, 5 year rolling programme (2 year extension) • Gross contract 1985 - 95 : operated mileage paid pro rata • Net contract 1995 - 99 : revenue growth retained by Operator • QICS 2000 – present: minimum reliability performance standards, 70% cost recovery

  12. Payments to Bus Operators • Total value of contracts = £1.6 billion/year (R27.9 billion/year) • Quality Incentive Contracts (QICS) route based (700+ routes) • Mileage paid by the kilometre • Incentives for meeting reliability targets (-10% to +15%)

  13. Payments to Bus Operators

  14. Other performance monitoring • TfL monitors a range of outputs; • Safety, and accidents/incidents • Driving standards and drivers’ working hours • Engineering standards • Environmental reporting • Various monitoring tools are used and supported by audit. • Results from Customer Satisfaction Survey, Mystery Traveller Surveys and other surveys feed into contract management.

  15. Old survey method (1977-2012) 200 full time traffic recorders

  16. Potential benefits of iBus data Excluded data (3.5%) • Sample size 1% (old) to 97% (iBus) • Contract & performance management • Continuous incentivisation • Schedule optimisation • Improved reliability • Manual surveys decommissioned • Operational issues (police, road, driver) • Ancillary uses of data: • bus speeds • scheme evaluation • raw data for other systems (modelling etc) • customer enquiries

  17. Initial specification, 2005

  18. Specification, 2007 • appeals process

  19. Specification, 2010 • & appeals process

  20. What were the problems? • & appeals process points of failure: On-bus hardware, GPS/navigation issues, depot WLAN, base data (schedules), bus operations, driver error, agreeing on what we wanted!

  21. Major impact on reporting • Technical (data quality) • data availability (‘missing data’) • manual coding of lost mileage trips • imputation & exclusions for QSI’s • accuracy (route termini) • latency • Other (changes to calculation) • new calculations, weightings & results • 15 different changes to method • analysis & negotiation with Operators • exclusion of ‘bad’ data automatically& appeals process

  22. The perfect world… • 4.5 million potential timestamps per weekday! • appeals process

  23. The real world • All these missing sections of trip need assigning a ‘lost mileage cause code’! • New codes introduced (‘technical error, bus ran section of trip’)

  24. Challenges – Missing Data (mileage reporting) • Problem: • 4.5 million stop_trip records per day • 17% trips affected • (from 37% in 2010) • 20,000 trips per day to code • 1.5 people per Garage • Solutions: • ‘Auto-coding’ facility • Faster fault resolution • Components replaced • Future solutions: • Use alternative data to ‘cover’ • Real-time coding by Service Controllers

  25. Solutions – Missing Data (‘auto-coding’)

  26. Challenges - Missing Data (High Freq reliability) • Problem: • results extremely sensitive to missing data • bias is away from Operators • High volumes of excluded data • Solution: • Imputation algorithm with no bias • For each location & 3 hour time period: • If > 20% missing data for technical reasons, exclude data set • Else: impute value, using headway value (90th percentile headways) + previous observed trip time

  27. Solutions – Missing Data • Orange = auto-coding (as mileage that ran) • Green = Imputed times • Strikethrough = Exclusion (for Service Reliability reports)

  28. Data Exclusions • Imputation exclusions (Missing Data issues - high levels of missing data at bus stop_time period level). 4% down to 3% • Automatic exclusions (Road network issues - low levels of observed buses) 1.5% • Manual exclusions (Regional or London-wide issues manually applied) 1.5% • Problem: • time-consuming negotiations between TfL and Bus Operators still occur • Solution: • More intricate ‘Auto Exclusion’ • algorithm

  29. Challenges – Data Accuracy • Problem: • Local configuration • not possible to have a one fits all approach • Route termini • 5,500 unique timing points (‘Route - Bus Stop’ combination) • Solutions: • Detailed analysis case by case • Early Departure Zone • Move timing points

  30. Project timeline Contractual ‘go-live’ (QSI – Night routes) Contractual ‘go-live’ with iBus Mileage Reports iBus contract signed Database & Key Reports development Operator trip coding ‘go-live’ Contractual ‘go-live’ (QSI - High Frequency reports) Contractual ‘go-live’ (QSI - Low Frequency routes) Legacy surveys ended iBus QSI reports release Initial reporting requirements Vehicle rollout Presentations & negotiations with Bus Operators Dual reporting begins Aggregation method designed First investigations into causes of missing data Reliability reports release (internal) Last major software update Formal comparison of iBus and legacy methods Imputation algorithms designed Automatic exclusions designed New requirements & reports....

  31. Dual running of legacy & iBus • Problem: • 15 different calculation changes • stakeholder buy-in • Solution: • Detailed route analysis, presentations, negotiations

  32. Benefits by day & hour • Improved performance at new locations and hours monitored • HF routes • -7% EWT • LF routes + 2% On-Time

  33. Costs & benefits (2005-2015) Time savings (4.2secs per passenger journey realised, but by different mechanism!)

  34. The twist…

  35. Drivers of customer satisfaction Since 2013, journey times have increased, reliability & patronage have fallen...

  36. Next steps? • Prioritise internal Journey Time metric? • More bus priority measures? • Award bonuses for good driving and vehicle standards? • Or, contract extensions based on driver, vehicles, safety? • Or, reliability bonus only payable if pre-set driver and vehicle standards are met?

  37. 2) The provision of next bus arrival information to all bus stops in London

  38. ‘Countdown II’ project • Business case 2007, implementation 2011-12 • Replace existing 2500 RTI displays at bus stops • Delivery of RTI to all 19,000 stops • Web pages (Sept 2011) • (PC-based) • ‘Accessibility’ • Mobile phone • SMS (October 2011) • API (June 2012) • Mobile phone applications (‘apps’) • Other • (companies, public services, academia)

  39. Release of data to 3rd parties • Similar functionality • Also integration with; • Journey planner • ‘Get home’ facility • Underground • Fares • Cycle hire • Journey time estimate • Download sales • 200k – 1 million • (Android only) • Other uses Image sources: mbarclay.net, fastchicken.co.nz - tablet applications, public services, academia

  40. Expected project outcomes • Usage (2007 Business Case) • SMS 2.6% journeys • Web 0.16% year 1, 0.3% year 2 • Benefits • Reduced wait time • Improved perception of safety • Meets rising expectations of RTI • Improved service status information • Available for Olympic Games

  41. RTI usage, by channel (2012) 2017: 37% to 50% journeys accessing RTPI, mainly apps

  42. Web demand by day type & hour

  43. Usage by bus stop Web demand (total) Web demand (% journeys) - central locations - peripheral locations - rail, bus interchanges - town centres (shopping) • higher frequency bus services - lower frequency bus services

  44. RTI usage at bus stops • RTI demand at stops with Countdown signs = 3.7% journeys, at stops without signs = 6.3% • Implies use away from bus stop, to check services or save time • ~20% ‘sessions’ show requests for >1 bus stop • proactive searching for alternative routes?

  45. Key benefits, reduced travel time Travel Time = Time to stop + Wait time at stop + Journey time

  46. Customer research • Estimated time saving benefits 1.1x Automated Performance Monitoring

  47. The future…? • Revenue streams under pressure • Central govt funding decreasing • Fares revenue decreasing • Current Mayor has frozen fares Technology led solutions to optimise performance? • Passenger counting (planning, real time info) • Automating/optimising some service control decisions? • Dynamic scheduling, Demand Responsive Transport? • First/last mile? • Highly subsidised routes • More efficient means of moving people around • Mobility as a Service • Driverless vehicles…

  48. nigelhardy88@gmail.com Simon.Reed@tfl.gov.uk

More Related