Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Transport-as-a-Service (TaaS) - How we build next generation plug-and-play IT-systems for public transport (ITxPT) at Ruter

699 views

Published on

The digitalization of everyday life, where the average bus passenger would rather ignore the surroundings and stare blankly into his phone for snapchat updates, creates great opportunities for digitalization of public transport, as well as some challenges. Ruter, Norway’s largest public transport authority, is putting significant effort into improving digital services for customers. However, the current technology stack behind Ruter's operations, is not able to provide the necessary real-time information.

In this talk I will explain how Ruter is participating in the development of new European standards for information technology for public transport (ITxPT), and how Apache Kafka and Kafka streams serve as the core components in building "Transport-as-a-Service".

Presented at Berlin Buzzwords 2018 https://berlinbuzzwords.de/18/session/transport-service-taas-how-we-build-next-generation-plug-and-play-it-systems-public

Published in: Technology
  • Be the first to comment

Transport-as-a-Service (TaaS) - How we build next generation plug-and-play IT-systems for public transport (ITxPT) at Ruter

  1. 1. Christoffer Vig 11 June 2018 Plug-and-play IT systems for public transport using ITxPT + Kafka @Ruter Traffic-as-a-service: Plug-and- play IT systems for public transport
  2. 2. AgendaAgenda Ruter ITxPT - Information Technology for Public transport TaaS - Transport as a Service Kafka
  3. 3. 4 Ruter Largest public transport authority (PTA) in Norway 2017 371 million registered passenger boardings Ruter serves Oslo + surroundings (Akershus): 1,5 million people
  4. 4. 5
  5. 5. 6
  6. 6. 7 Insert picture Mobility as a tranquil service https://disruptionhub.com/mobility_service/
  7. 7. 8
  8. 8. 9
  9. 9. 1 0 12:06 Planned time table
  10. 10. 1 1 12:07 Estimated Departure times
  11. 11. 1 2 Reality Tram at stop at 12:07
  12. 12. 1 3 Ruter - current situation - Trip planning apps do not use real time information - Departure Times show «real time» information - Physical signs at Stop place show somewhat improved «real time» - Too short dog walks.
  13. 13. 1 4 Ruter - current situation Operators (PTO) own data Ruter can not directly access data from vehicles. «Real time» data available via third-party (Entur)
  14. 14. 1 5 Operators control vehicles + data • PTA - Public Transport AUTHORITY (Ruter/ VBB) • Responsible for public transport in an area • Planning - time tables • Marketing, public information • Order services from PTO • PTO - Public Transport OPERATOR (Unibuss, Nobina, Oslo Sporveier/ BVG, DB) • Responsible for operation of traffic • Owns vehicles and employs staff - drivers, service personell
  15. 15. 1 6 Operators control vehicles + data • PTA - Public Transport AUTHORITY (Ruter/ VBB) • Responsible for public transport in an area • Planning - time tables • Marketing, public information • Order services from PTO • PTO - Public Transport OPERATOR (Unibuss, Nobina, Oslo Sporveier/ BVG, DB) • Responsible for operation of traffic • Owns vehicles and employs staff - drivers, service personell
  16. 16. 1 7 APC Project - Automatic Passenger Count Started in 2016 Passenger counting sensors installed in 400+ buses.
  17. 17. 1 8 APC Project - Automatic Passenger Count Started in 2016 Passenger counting sensors installed in 400+ buses.
  18. 18. 1 9 Information technology for Public Transport ITxPT
  19. 19. 2 0 ITxPT European initiative - standards for plug-and-play IT- systems applied to public transport
  20. 20. 2 1 ITxPT members
  21. 21. 2 2 ITxPT Specifications S01 – Installation Requirements S02 – Onboard Architecture S03 – BackOffice Architecture S04 – Over the Air Architecture Deployment guidelines 13 working groups Technical committee https://www.itxpt.org
  22. 22. 2 3
  23. 23. 2 4 ITxPT Modules - S02 OnBoard Architecture DPI - Dynamic Passenger Information AVMS - Advanced Vehicle Monitoring System ASP - Automatic Signal Prioritization APC - Automatic Passenger Counting GPS - Global Positioning System MADT - Multi Application Driver Terminal FMStoIP/VEHICLEtoIP - Fleet Management System to IP
  24. 24. 2 5 DPI - Dynamic Passenger Information
  25. 25. 2 6 AVMS - Advanced Vehicle Monitoring System Keeps track of vehicle progress: Driver information (PTO responsibility) Passenger information (PTA responsibility) Calculate time to next stop, etc.
  26. 26. 2 7 ITxPT S03 - BackOffice Transmodel - Abstract Reference Data model for public transport NeTEx - (Network Exchange) - concrete implementation of XML for planned data (routes, stops, journeys, time tables) SIRI (Service Interface for Real Time Information) - Real Time Information SIRI describes changes to NeTEx data
  27. 27. 2 8 ITxPT S04 - Over the Air Communication between vehicle and back office MQTT bridge Using 3G, 4G, LTE Allows real time data exchange
  28. 28. 2 9 Ruter’s implementation of ITxPT TaaS: Transport-as-a-Service
  29. 29. 3 0 TaaS - Transport as a Service Ruter’s initiative to create an implementation of ITxPT Romerike tender: 400 new buses to be delivered in 2019 IT specs based upon ITxPT Open source components
  30. 30. 3 1 Assumption: all vehicles are always online
  31. 31. 3 2 Assumption: vehicles are NOT always online AVMS - Automated Vehicle Monitoring - load journey info from back office when bus starts at depot - bus-computer tracks progress - Hard to update
  32. 32. 3 3 Assumption: all vehicles are always online - continuous stream of data from bus to back office - computing happens in back office - Everything is dynamic - Allows for heavy computing. - machine learning
  33. 33. 3 4
  34. 34. Blocks - how to know who drives where Block: RUT:Busoperator:2 - Service journey 1. - Dead run 2 - Service journey 3 - ...
  35. 35. 3 8 Kafka
  36. 36. 3 9 - Publish and subscribe to streams of records, similar to a message queue or enterprise messaging system. - Store streams of records in a fault-tolerant durable way. - Process streams of records as they occur. - Kafka streams - join and process topics to generate new topics.
  37. 37. 4 0 Traffic Plan System TPS
  38. 38. 4 1 TPS Traffic Plan System information on time tables, stops, routes. Follows the Norwegian variant of the NeTEx standard - Network Timetable Exchange (http://netex-cen.eu/) If all vehicles always were on time, we did not need any real time information. Then TPS would be the single source of truth.
  39. 39. 4 2 Tps - GraphQL GraphQL - NeTEx query linesForStopPlace($stopPlaceId: String!) { stopPlace(id: $stopPlaceId) { id name { value } passengerStopAssignments { scheduledStopPoint { stopPointInJourneyPattern { order journeyPattern { route { id name { value } line { id publicCode } } } } } } } }
  40. 40. 4 3 Tps2Kafka Information derived from TPS is batch published to Kafka topics every night. Avoids 7 levels of joins..
  41. 41. 4 4 Examples
  42. 42. 4 5
  43. 43. 4 6 Sign on - vehicle assignment ruter/<sender>/<vehicle id>/itxpt/ota/signon/json { "eventTimestamp": "2017-10-31T12:45:50Z", «vehicleNumber": "12345", "blockId": "1234:34", «vehicleJourneyId": "RUT:ServiceJourney:3574-109438-12114360", " }
  44. 44. 4 7
  45. 45. 4 8 Dated Vehicle Service Journey - from TPS - (Planned time table){ "datedVehicleJourneyRef": "RUT:ServiceJourney:76-246", "routeName": "Mortensrud T-Helsfyr T", "routeId": "RUT:Route:76-29", "journeyPattern": "RUT:JourneyPattern:76-29", "quayStops": [ { "stopId": "NSR:StopPlace:5690", "stopName": "Mortensrud T", "quayId": "NSR:Quay:10426", "latitude": 59.84988, "longitude": 10.828818, "order": 1, "arrivalTime": null, "departureTime": { "string": "08:09+01:00" } }, { "stopId": "NSR:StopPlace:5716", "stopName": "Dalsåsen", "quayId": "NSR:Qu
  46. 46. 4 9 Signon + Service Journey -> Signed On Journey Joined in Kafka streams Signon (KStream) + Service Journeys (GlobalKTable) - -> new Kafka topic: SignedOnJourneys = Vehicle Service Journey Planned Time table
  47. 47. 5 0 GPS - from vehicle ruter/<sender>/<vehicle id>/itxpt/ota/avl/json { "eventTimestamp":"2017-10-31T12:45:50Z", "seqNumber":0, "latitude":60.25255, "longitude":11.0567, "heading": 0.5, "speedOverGround":34.5, "signalQuality": "AGPS_QUALITY", "numberOfSatellites":4, "gnssType": "GPS", "gnssCoordinateSystem": "WGS84", "deadReckoning": false, "positionIsSimulated": false
  48. 48. 5 1 GPS + SignedOnJourney = Real time update Kafka streams processing. Gps (Stream) -joined with SignedOnJourney(KTable) - both keyed by vehicleId Using GPS we can figure out - Bus location on Journey. - Next Stop Combining GPS, current time with expected departure times, we can find - Estimated time to Next Stops - Delay
  49. 49. 5 2 Subheading- Click to add text • First level • Second level • Third level • Fourth level
  50. 50. 5 3 ITxPT + Kafka enables real time data processing for public transport
  51. 51. 5 4 Mobility as a service improves animal welfare
  52. 52. 5 5 Christoffer Vig Twitter: @babadofar christoffer.vig@gmail.com
  53. 53. makingwaves.com

×