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

2. 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

3. Data Exchange Hubs
DRAFT

4. 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

5. 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

7. 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

8. Sample of Notifications

9. Samples of User Interface

10. Samples of User Interface

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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.

17. 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.

18. 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