The Trip Exchange Software for Sharing Trips among DRT Providers Northwest Denver MSAA Project

Background The challenge: How to improve and replicate a coordination system that allows providers to share trips? Via Mobility Services and RTD showed that sharing trips improved productivity and lowered cost/trip. The challenge was to expanded this to other Call-n-Ride service areas and other providers. The project: An FTA Mobility Services for All Americans MSAA) grant funded a project to develop a data exchange system Expansion required a different approach than the initial model Trip Exchange software was developed to automatically exchange trips among providers The way in which DemandTrans Solutions and RouteMatch made it work is not an efficient design, and not one that it is desirable to replicate. We needed a broader approach. To enable trip exchanges between different providers we need to address institutional issues and practical considerations A key objective is to reduce the manual labor / increase the automation Needs to be part of regular dispatch flow Needs to function without a full-time mobility coordinator Needs “filters” to identify trips to automatically move

Data Exchange Hubs DRAFT

Data Exchange Hubs Are used in many industries to exchange information: Connecting across different software platforms Connecting entities in different locations The Trip Exchange is a data exchange hub capable of: Storing information relevant to the scheduling and delivery of DR trips. Responding to messages from host systems. It has basic functionality with more planned It is in use by 4 providers The Trip Exchange is web-hosted, connects via APIs, and is open-source. The scheduling software systems need to be able to produce a clean data stream to send to the hub and

Trip Discovery and Trip Transactions Discover providers Identify constraints Plan trip ✔ Schedule trip ✔ Schedule vehicle ✔ Deliver trip Process fare Bill 3rd party Individuals or agencies seeking trips Providers - Schedule trip - Pay for trip - Approval for charges - Collect fare

The Trip Exchange Includes Data fields – defined for all needed instances Messages, e.g. Trip reservation request Trip scheduling acceptance Trip completion/execution Notifications to providers, e.g. “Partner updates a trip ticket” or “New trip claim awaiting approval” A user interface Reporting function Resources: data field matrix, details on messages and notifications, API list, and user manual

Sample of Notifications

Samples of User Interface

Samples of User Interface

The Trip Exchange Characteristics The Trip Exchange is a decentralized system: Partner agencies post trips they are unable to serve; these can be viewed and accepted by other agencies in the service area. Partner agencies retain control over acceptance of trips (and therefore their resources). Scheduling vendors adapted their software to automatically produce and consume data streams for the Trip Exchange. (RouteMatch and Mobility DR) Scheduling / dispatch interface Driver manifest Reporting The scheduling software systems need to be able to produce a clean data stream to send to the hub and

Potential for Trip Exchange Connecting diverse software scheduling systems API connections would be needed for each system. Each would also need modifications to be able to create, read, and act on data streams from the Trip Exchange. Connecting to other types of software (e.g. eligibility, reporting, or financial.) This would require expansion of data fields, messages, and other activities. The system could be adapted to answer key questions for providing efficient regional trip services: Are there enough trips in a corridor to make it financially feasible to establish a vehicle run on a given day? The scheduling software systems need to be able to produce a clean data stream to send to the hub and

Issues Expanding to additional providers added complexities Building a common understanding and working toward a common goal was challenging. The providers have different interests, objectives, & approach than the vendors. The stakeholders each have different perspectives, language, agendas, skills, knowledge, and understanding Planners Funders Managers Software developers Scheduler RM Software Reps

Issues Agencies must actively work with a complex technical system (not just buying it off the shelf and making do) Requires training to expand the core competency of staff There is not a plan for creating an ecosystem around the hub Multiple installations will be needed to grow and sustain this software

Lessons Learned The project was a success because: The stakeholders were trusted partners committed to success The project was grounded in reality The team was pragmatic and disciplined enough to maintain a narrow focus The team used an Iterative Development Process. They Developed a Shared Vision They Explored New Ground together. They created a Common, Technology Vocabulary for their work

Next Steps Ongoing implementation among four operators in Northwest Denver Completion of financial component and implement automatic payment for trips Denver Regional Council of Governments (DRCOG) is defining how the Trip Exchange may be used in a regional program.

Returning to Mobility as a Service Mobility as a Service brings every kind of transport together into a single intuitive mobile app. It seamlessly combines transport options from different providers, handling everything from travel planning to payments.  The MaaS concept was born in Finland where it already plays a key role in the national transport policy. It is widely recognized as a disruptive innovation, which will change the entire transportation universe through digitalization and combining the best of existing apps. Europe is far ahead of the US in this arena. Finland, Denmark, and Germany are leaders.

Can you imagine? “NEW legislation comes into effect in Finland this month, which sets an international precedent for the availability of data on transport services. Through its Act on Transport Services, the government seeks to provide a legal basis for digitalisation and new business models in the transport sector by introducing provisions on the interoperability of data and information systems. This does away with mode-specific regulations on transport service information and provides a level playing field for all operators. The new law will allow Uber to begin operating in Finland, but like every other transport operator in the country, it will need to open its Application Programming Interface (API) and its data. It will also have to allow third party providers to buy and resell Uber rides through their own applications.” -International Railway Journal, January 2018