1	Integrated Dynamic Transit Operations (IDTO): Stakeholder Input on Concept of Operations (ConOps) Development IDTO Stakeholders Meeting January 26 and 27, 2012 in Washington, DC
2	Welcome
3	Announcements Sign-in sheet Agenda Workbook Administrative announcements
4	Key Meeting Elements Information dissemination Full group discussion Group breakout sessions with debriefing Questions and answers
5	Meeting Agenda – Day 1 Welcome and Introductions Workshop Objectives and Desired Outcomes IDTO Overview and Draft Visions BREAK Group discussion of transformative concepts, current status, trends and perspectives Briefing on DMA and Link to IDTO
6	Introductions Name Organization Area of Expertise Meeting Expectations
7	Meeting Outcomes Determine if scenarios are correctly documented and represented Gather detailed input for each scenario to finalize high level User Needs Identify initial “Gaps” that need to be filled for IDTO applications to be operational
8	Goals and Objectives of the Study
9	Goals of the Study Facilitate concept development and needs refinement for IDTO applications Assess relevant prior and ongoing research Develop functional requirements and corresponding performance requirements Develop high-level data and communication needs Assess readiness for development and testing
10	Goals of IDTO Examine what technologies can help people effortlessly transfer from one mode of travel (car, bus, train, etc.) to another for the fastest and most environmentally friendly trip Seek to make cross-modal travel truly possible Enable agencies and companies to manage their systems in light of the fact that people may be changing modes often
11	IDTO Applications Definitions Connection Protection (T-CONNECT) - enable public transportation providers and travelers to communicate to improve the probability of successful transit transfers. This application would potentially include intermodal and interagency coordination. Dynamic Transit Operations (T-DISP) - links available transportation service resources with travelers through dynamic transit vehicle scheduling, dispatching and routing capabilities. It would also enable travelers to make real-time trip requests through personal mobile devices. Dynamic Ridesharing (D-RIDE) - makes use of in-vehicle (drivers) and hand-held devices (riders) to dynamically identify and accept potential ridesharing opportunities along the travel route.
12	T-CONNECT Example
13	T-CONNECT: State of the Practice T-Connect addresses problem of multiple transfers between different transit modes by enabling communications to improve probability of a transfer Exists mostly for bus-to-bus transfers, but limited application of for rail-to-bus Relies on passenger request to driver No US examples of regional, multiple operator connection protection
14	T-DISP Example
15	T-DISP: State of the Practice T-DISP addresses variety of transit services offered in certain conditions and allows travelers to assess their travel options Dynamic transit services operated in numerous locations around the US, but very few employ technology. Use of technology more prevalent in European dynamic transit operations Orlando’s Lynx FlexBus and United We Ride/Mobility Services for All Americans projects will provide valuable information
16	D-RIDE Example
17	D-RIDE: State of the Practice D-RIDE promotes ridesharing through in-vehicle and handheld technologies, and improvements to information available for high occupancy vehicle/toll lanes Various forms of ridesharing since early 1990s, but now new “products” available using current technology Input from Ridesharing Institute (created 2011) and new ridesharing products critical to understand marketplace Limited toll lane and in-vehicle functionality
18	Investigate Answers to Questions Do current practices take full advantage of new transit technologies, tools and data sources? What emerging opportunities exist for the new generation of automated tools to be used to facilitate the deployment of the IDTO applications? Is there strong motivation for a federal role in facilitating the development of new technologies and tools to capitalize on these identified opportunities?
19	Summary of Findings from Scan of Current Practice
20	Findings: Literature Review Academia USDOT Programs United We Ride/Mobility Services for All Americans (UWR/MSAA) Connected Vehicle Program Dynamic Mobility Applications Research conducted by TRB and other associations
21	T-CONNECT Current Practice
22	T-CONNECT Current Practice (cont’d) Several examples in fixed-route implementations. Commonplace with many CAD/AVL systems For example, UTA’s TCP deployment between TRAX light rail and fixed-route buses For example, commuter rail to fixed-route bus in Brampton, Ontario No evidence of direct T-CONNECT implementation, but commuter rail often provides “unconditional” transfers
23	T-CONNECT General Findings Literature limited Evaluation of UTA TCP program revealed that program well-regarded Fixed-route to Fixed-route TCP is only T-CONNECT-type implementation that exists today in the US
24	T-CONNECT Challenges Electronic information exchange necessary, but important to ensure consistency of coordination on business processes related to transfers After-the-fact review of transfer trips should be conducted “Maximum allowed” waiting time should be defined Definition of TCP should be by route, not by vehicle Manual intervention should be allowed Accuracy of real-time vehicle locations must be ensured
25	T-DISP Current Practice Application limited in US: Flexibly-routed service with technology limited No one site with all T-DISP elements: coordination of transportation services, transit technology, technology to provide information to travelers and travel management coordination center Existing programs with some elements: UWR/MSAA initiative FlexBus in Orlando, FL North and East Brainerd routes in Chattanooga Belbus in Belgium and Flexlinjen in Sweden
26	T-DISP General Findings Service coordination challenges are complex Technology alone will not overcome coordination barriers Limited demonstration of technology application and coordination together Travelers and their needs, particularly information, critical part of T-DISP concept Few states that include transit in 511 systems
27	T-DISP Challenges Difficulty in coordinating amount multiple transit agencies, funding programs, and local, state and Federal entities Lack of effective coordination structures has contributed to: Service area gaps Limited services Confusing and low quality customer service Limited deployment of real-time transit information systems
28	D-RIDE Current Practice Pilot in Santa Barbara County through FHWA Value Pricing Pilot Program FHWA-sponsored scan of casual carpooling/ slugging phenomenon Project in San Diego to sync software with in-vehicle computer, and calculate number of passengers Rideshare pilot in Washington State SR 520 corridor Multiple private companies/programs
29	D-RIDE General Findings Wide range of technologies employed, and with more mobile and internet-based technologies Fear of strangers often cited as reason for not sharing rides, so focus on making participants more comfortable Providing familiar meeting points and drop-off locations in addition to users’ homes way to make participants more comfortable Marketing necessary to draw initial crowd Incentives can draw more users
30	D-RIDE Challenges Implementing controls to minimize safety concerns regarding sharing a vehicle with a stranger Lack of established rideshare infrastructure (meeting points and drop-off locations)
31	Group Discussion of Transformative Concepts, Current Status, Trends and Perspectives
32	T-CONNECT Goals and Objectives
33	T-CONNECT Goals Implement a system that improves intermodal transfer connections involving multiple transit agencies Deploy an application that improves the probability of transit connections Improve rider satisfaction regarding transfers
34	T-CONNECT Objectives Implement a system that improves coordination between transit agencies and vehicles by utilizing various technologies such as “Connected Vehicle “ To deploy a system that increases the number of successful transit connections Reduction in overall round-trip travel time for transit riders requiring transfers, and provision of accurate and relevant real-time passenger information
35	T-CONNECT Performance Measures
36	Performance Measures for T-CONNECT Average transfer passenger waiting time (from incoming vehicle) = 3 minutes or less Average in-vehicle passenger waiting time (for the “outgoing” vehicle) = 1 minute or less Average downstream passenger waiting time (for outgoing vehicle) = 3 minutes or less Average Successful Low Latency Connections Achieved = 20% (a connection that occurs within 1 minute or less) Average Successful Mid Latency Connections Achieved = 40% (a connection that occurs within 2 minutes or less)
37	Performance Measures for T-CONNECT (cont’d)
38	T-DISP Goals and Objectives
39	T-DISP Goals Provide travelers with information about transportation options dynamically and in real-time Allow travelers to explore and assess different travel options from multiple transportation providers with predictable time and cost Dynamically schedule and dispatch multiple transportation modes by matching compatible traveler trip requests Reduce cost of providing transit service, especially in areas of low density or dispersed land uses
40	T-DISP Objectives Advance concept of demand-responsive transportation services utilizing personal mobile devices with transportation providers’ on-board and central system technologies Provide a central system, such as Travel Management Coordination Center or decentralized system, to “ease” communications between transportation providers to leverage their services through dynamic routing, dispatching and scheduling based on real-time conditions Maximize use of multiple transportation providers and types of service within a region to provide effective service to the community
41	T-DISP Performance Measures
42	Performance Measures for T-DISP Average time for traveler to make trip request, receive and confirm trip = 45 seconds Number of trips scheduled by the Control Center compared to overall transit ridership (i.e., trips not scheduled through Control Center) per time frame (month, week, day) Average waiting time for a passenger for pickup since the time of trip request (for real-time trips only) Average on-board time for passengers
43	Performance Measures for T-DISP Average boarding time for group trips Number of trips performed by each mode Number of trips performed by each provider, public and private Percentage of no-shows and cancellations Reduction in cost per passenger
44	D-RIDE Goals and Objectives
45	D-RIDE Goals/Objectives Improve feasibility and convenience of non-transit ridesharing options (e.g., car/vanpool) to increase mode-share and lessen congestion To provide secure location-based data and accurate reporting of high occupancy vehicle (HOV) status for HOV and high occupancy toll (HOT) restricted lanes for HOV/HOT occupancy enforcement and improved tolling strategies
46	D-RIDE Performance Measures
47	Performance Measures for D-RIDE Number of participating users (concentration rate): 500 per 1 mile radius of passenger placing trip request 750 per 2 mile radius of passenger placing trip request 1,000 per 3 mile radius of passenger placing trip request Average passenger waiting time (waiting for ridematch vehicle) = 10 minutes or less Average number of ridematches (rate of occurrence): 0-2 passenger to driver matches = < 5% of requests 3-5 passenger to driver matches = at least 95% of requests 6+ passenger to driver matches= 75% of requests Late arrivals (rate of occurrence) = <20% of all arrivals
48	Performance Measures for D-RIDE (cont’d) Average response time to customers about a found ridematch 0-5 minutes = at least 95% of requests 6+ minutes = < 5% of requests Total number of trips with modifications due to accident/incident with a vehicle = <5 per day Percentage of no-shows = <2% no shows = 95% of requests Average on-board time for passengers by vehicle capacity (this is a metric with no preset goals but should have data collected) 1 passenger 2 passengers 3 passengers 4 passengers Number of D-RIDE trips per month with HOV lane utilization HOV 2+ = >75% D-RIDE trips per month HOV 3+ = >80% D-RIDE trips per month
49	Dynamic Mobility Applications Program
50	Dynamic Mobility Applications
51	Dynamic Mobility Applications Vision: Expedite development, testing, commercialization and deployment of innovative mobility applications: Maximize system productivity Enhance mobility of individuals within the system Objectives: Create applications using frequently collected and rapidly disseminated multi-source data from connected travelers, vehicles (automobiles, transit, freight) and infrastructure Develop and assess applications showing potential to improve nature, accuracy, precision and/or speed of dynamic decision making by system managers and system users Identify innovative forms of wireless connectivity supporting applications Demonstrate promising applications predicted to significantly improve capability of transportation system to provide safe, reliable, and secure movement of goods and people
52	Priority Applications
53
54	Meeting Agenda – Day 2 Recap and Description of Breakout Sessions Breakout Sessions: T-CONNECT (facilitated by Carol Schweiger) T-DISP (facilitated by Carrie Butler) D-RIDE (facilitated by Ayeshah Abuelhiga) BREAK Results/Recap of Breakout Sessions Revisit Draft IDTO Visions Wrap Up and Next Steps
55	Purpose of Concept of Operations To Confirm: Stakeholder needs and expectations are captured Implementation is linked to different disciplinary missions, goals and objectives Existing operational environment Where IDTO can enhance operations Potential future operational environment with IDTO (ID necessary functional parts to operate) Establish a list of high level requirements
56	Policy Constraints Policies do not exist for IDTO. Institutional and operational policies will evolve to exploit capabilities of new technologies and tools, but initiation may find resistance to automation of traditional operations Stakeholder commitment to roles and responsibilities is a vital component of the IDTO ConOps and should be embedded into the operational scenarios
57	Operational Constraints Limitations of service provider technologies and connectivity among providers Limitations and gaps in necessary data Limitations in communications interfaces Lack of standardization of data flows Shortages in properly trained personnel Trust of service providers Lack of stakeholder organization and awareness
58	Sample T-CONNECT Capabilities Protect transfer requests between multiple transit modes and agencies Enhance mobility of riders primarily dependent on paratransit services by providing intermodal transfers Bridge gap between transit and non-transit modes Assist with implementation of T-DISP and D-RIDE
59	Sample T-DISP Capabilities Utilize advanced transit ITS systems to enable traveler to request service Dynamically schedule and dispatch, or modify route of in-service vehicle Consider both public and private providers, and multiple modes Consider common platform to provide exchange allowing travelers and operators to trade in transparent market Consider real-time traffic conditions and vehicle capacity
60	Sample D-RIDE Capabilities Mobile platforms Location-aware applications Links to social networking Opportunity for users to rank experiences Create and save user profiles Allow automated financial transactions Provide incentive or loyalty rewards Incorporate information on other modes of transportation Allow users to set preferences Receive audio notifications when match made or vehicle close to pick-up point
61	"Transition" Transition
62	Desired Institutional Changes Coordination among regional institutions and application vendors Change in organizations to participate in IDTO implementation Participating organizations conduct business in a different way Procure technologies/systems jointly Facilitate data exchange among institutions, vendors and travelers Familiarity with coordinated operations by vendors
63	Desired Operational Changes The way agencies schedule and operate their services Provide services under policies and objectives from different governmental and regulatory agencies while satisfying the needs of travelers Nature of interfaces among existing and proposed technology systems Role of each agency in regional transportation system
64	Desired Technical Changes Incorporate old infrastructure into physical and logical architecture Incorporate manual processes Account for individuals without mobile devices to ensure “information equity” Integrate new technologies into organizations Provide technical guidance and information for agency staff Add ITS infrastructure to specific areas (e.g., rural)
65	Answer to Study Question #1 Question #1: Do current practices take full advantage of new transit technologies, tools and data sources? Answer: No. The current state of the practice has yet to exploit the full potential.
66	Answer to Study Question #2 Question #2: What emerging opportunities exist for the new generation of automated technologies/tools to facilitate the deployment of the IDTO applications? Answer: Many opportunities exist, but must consider not only new tools, but legacy systems and integration of both.
67	Answer to Study Question #3 Question #3: Is there strong motivation for a Federal role in facilitating the development of new technologies and tools to capitalize on these identified opportunities? Answer: Yes.
68	User and User Needs
69	What are User Needs? Formally documented customer requirements. These inputs from you would be used as a starting basis for designing the IDTO applications User Needs will become the basis for development of system requirements for IDTO We will be working with the DRAFT User Needs during this meeting in hopes of confirming them before we leave on Friday
70
71	Scenario Analysis Scenarios are diagrammed using high-level system information flow diagrams Needed: Changes to Scenario diagrams, subsystems and data flow information ID gaps in order for IDTO to exist Changes to User Needs
72	Group Discussion Purpose Gather your insights to better understand the critical institutional and operational interactions and decision-making activities that underpin a successful IDTO application
73	Group Discussion Process Work in groups (led by group facilitators) Discussion to complete stakeholder input for each scenario – 1.5 hours Combine comments and modify documents – 30 minutes Debriefing feedback to whole group – 15 minutes/each group Discussion of changes to overall IDTO vision – 15-30 minutes
74	Group Discussion Tasks Review each scenario for accuracy and make modifications where necessary for subsystems and interconnects (who talks to whom), and what type of data will be exchanged Review and provide “User Need” input Provide input to “Gaps” for developing successful IDTO applications
75
76
77
78
79
80
81
82
83
84	T-CONNECT User Needs
85	User Needs
86	User Needs (cont’d)
87	User Needs (cont’d)
88	User Needs (concluded)
89
90	Group Discussion of Modifications Changes to scenario diagram, subsystem and data flow information Gaps in order for T-CONNECT to exist Changes to User Needs
91	BREAKOUT GROUP 2 T-DISP Scenarios
92
93
94
95
96
97
98
99	T-DISP User Needs
100	User Needs
101	User Needs (cont’d)
102	User Needs (concluded)
103
104	Group Discussion of Modifications Changes to scenario diagram, subsystem and data flow information Gaps in order for IDTO to exist Changes to user needs
105	BREAKOUT GROUP 3 D-RIDE Scenarios
106	Scenario 1 – Rideshare Request (Simple)
107	Scenario 1- Assumptions and Elements Assumptions: Ridematch is requested by the passenger using a personal hand-held device application or an internet form. Ridematch is requested by the driver through an in-vehicle application system using DSRC or wireless mobile technology. D-RIDE Data Center is capable of processing various types of data sent through the ridematching applications and can also process payment. D-RIDE Data Center is capable of interfacing with traffic data center’s traffic data for the routes being requested by the travelers. Description of elements: Traveler: Both the passenger requesting a ride as well as the traveler accepting passengers Passenger: Traveler in need of a ride Driver: Traveler in need of passengers D-RIDE Data Center: Processes ridematch requests from requestor route and location data Traffic Data Center: May also be a TMC; provides traffic data
108	Scenario 1- Data Flows Travelers enter trip information into D-RIDE interface system via mobile device (passenger) or in-vehicle system (driver) through wifi, DSRC, or mobile network to D-RIDE data center OR traveler enters trip information into D-RIDE interface system via internet. Information includes: trip plan request, origin and destination (OD) data, traveler profile and preferences, and traffic data (from a traffic data center) The center accepts requests from traveler interface systems for ridesharing as part of a trip plan request. The center processes the requests by balancing the relative benefits of the rideshare to each rideshare participant. The center provides a rideshare match based on data from the travelers proposed trips, any routing constraints, preferences specified by the traveler, compatibility of this rideshare with other travelers, eligibility data, and traffic data. This match is reported back to the travelers. The travelers confirm the rideshare match and the confirmation is sent back to the center. The center stores all rideshare matches and traveler eligibility data and sends a message back to the travelers that their ridematch has been accepted. The center also supports payment transactions for the service.
109	Scenario 2 – Multi-Leg, Multi-Modal Request
110	Scenario 2- Assumptions and Elements Assumptions: Ridematch is requested by the passenger using a personal hand-held device application or an internet form. Ridematch is requested by the driver through an in-vehicle application system using DSRC or wireless mobile technology. D-RIDE Data Center is capable of processing various types of data sent through the ridematching applications and can also process payment. D-RIDE Data Center is capable of interfacing with traffic data center’s traffic data for the routes being requested by the travelers. T-DISP Control Center is equipped with scheduling, CAD/AVL, traffic, and messaging systems that allow for transit trips and/or private modes to be scheduled. In this scenario, the D-RIDE Data Center and the T-DISP Control Center are separate entities that can communicate with one another. An alternative scenario would be that the D-RIDE or T-DISP application could function as one combined control center (not displayed in this scenario). Description of elements: Traveler: Both the passenger requesting a ride as well as the traveler accepting passengers Passenger: Traveler in need of a ride Driver: Traveler in need of passengers D-RIDE Data Center: Processes ridematch requests and requestor route and location data Traffic Data Center: May also be a TMC; provides traffic data T-DISP Control Center: Processes transit and private mode requests from requestor location and route data Transit: Includes fixed-route bus, BRT, rail, DR, flex, and deviated Private Mode: Includes taxi, shuttle, and volunteer services
111	Scenario 2- Data Flows Travelers enter trip information into D-RIDE interface system via mobile device (passenger) or in-vehicle system (driver) through wifi, DSRC, or mobile network to D-RIDE data center OR traveler enters trip information into D-RIDE interface system via internet. Information includes: trip plan request, origin and destination (OD) data, traveler profile and preferences, and traffic data (from a traffic data center) The center accepts requests from traveler interface systems for ridesharing as part of a trip plan request. The center processes the requests by balancing the relative benefits of the rideshare to each rideshare participant. Using traffic data and route optimization, the center picks up that an incident is causing major delays along the passenger’s route and that transit or other private mode (taxi, shuttle) may be the best fastest option to their destination. The center sends a message to the passenger asking if they would like to add a transit leg to their trip.
112	Scenario 2- Data Flows (Cont.) The passenger accepts the addition of the transit leg to their trip. This message is sent to the T-DISP Control Center via internet or wifi/DSRC/mobile network. The T-DISP Control Center utilizes scheduling, CAD/AVL, and messaging systems to schedule a transit or private mode trip. The selected trip is sent to the D-RIDE Data Center to add as part of the overall ridematch output. The center provides a combined driver + transit rideshare match based on data from the travelers proposed trips, any routing constraints, preferences specified by the traveler, compatibility of this rideshare with other travelers, eligibility data, and traffic data. This combined driver + transit rideshare match is reported back to the travelers and accepting transit The travelers confirm the rideshare match and the confirmation is sent back to the center. The center stores all rideshare matches and traveler eligibility data and sends a message back to the travelers that their ridematch has been accepted. The center also supports payment transactions for the service.
113	Scenario 3 –HOV/HOT Lane Enforcement and Tolling Description: In this scenario, the georeferencing mechanism of the D-RIDE application and devices allows the D-RIDE data center to process the location of travelers (in vehicle and in a high-occupancy lane) in order to process HOV/HOT Lane violation citations and appropriate tolling charges.
114	Scenario 3 –HOV/HOT Lane Enforcement and Tolling
115	Scenario 3- Assumptions and Elements Assumptions: D-RIDE applications on both the device and in-vehicle systems are capable of constantly sending location-based information associated with a unique identifier code for each user. D-RIDE Data Center is capable of processing constant flows of information from travelers in motion. D-RIDE Data Center is outfitted with georeferencing to know where HOV/HOT lanes are located and whether or not travelers are riding in the lane. Tolling and Enforcement Center can process e-tolling payments and issue violation citations. Description of elements: Traveler: Both the passenger requesting a ride as well as the traveler accepting passengers D-RIDE Data Center: Processes ridematch requests and requestor route and location data Tolling and Enforcement Center: issues citations for violations and processes e-tolling payments
116	Scenario 3- Data Flows - Enforcement Travelers that have been ridematched turn on their D-RIDE applications (devices and in-vehicle) while en route. The travelers enter into an HOV 2+ lane with their D-RIDE applications still on. These applications emit a unique identifier code that is linked to individual passengers and the driver. This code is sent to the D-RIDE Data Center to process to location of the previously matched travelers which the system recognizes as paired. Using GPS location information from the travelers’ D-RIDE applications, the center recognizes that the travelers have entered an HOV 3+ zone. With only 2 travelers known to the center to be in the ridematch, the center sends a message to the traffic tolling and enforcement center. The Tolling and Enforcement Center sends a citation to the driver’s home using the traveler profile information sent with the violation message from the D-RIDE Data Center.
117	Scenario 3- Data Flows – Tolling Travelers that have been ridematched turn on their D-RIDE applications (devices and in-vehicle) while en route. The travelers enter into an HOT 2+ lane with their D-RIDE applications still on. These applications emit a unique identifier code that is linked to individual passengers and the driver. This code is sent to the D-RIDE Data Center to process to location of the previously matched travelers which the system recognizes as paired. Using GPS location information from the travelers’ D-RIDE applications, the center recognizes that the travelers have entered an HOT 2+ zone. Recognizing the two travelers in the ridematch en route on the HOT @+ lane, the center sends a message to the Tolling and Enforcement Center that the vehicle can be charged $3.25. The Tolling and Enforcement Center process the message and deducts $3.25 from the driver’s account through the driver’s e-tolling pass registered as part of their traveler profile information sent by the D-RIDE Data Center.
118	D-RIDE User Needs
119	User Needs
120	User Needs (cont’d)
121	User Needs (concluded)
122
123	Group Discussion of Modifications Changes to scenario diagram, subsystem and data flow information Gaps in order for IDTO to exist Changes to User Needs
124
125	Group Discussion of Modifications Changes to scenario diagrams, subsystems and data flow information Gaps for all IDTO applications Changes to User Needs
126	Questions?
127	NEXT STEPS… Where do we go from here?
128	Schedule Milestones