ATIS08-Dynamic Ridesharing Transaction Set Diagram



Get the Source Graphic, a Windows Metafile (WMF), in ZIP format.
More about ZIP files

The following discusses how the National ITS Architecture provides the transportation service described by this service package. Each numbered item describes the operation of that portion of the service package identified with the corresponding number on the transaction set diagram.

Note that this transaction set diagram (TSD) is only 1 of the 3 TSDs and so only a portion of the numbered items below refer to the above TSD.

ATIS08 transaction set diagrams: 1 2 3 Next TSD

  1. The entire process is under the asynchronous monitoring (ISP operations information presentation) and control (ISP operator inputs) by the ISP Operator.

  2. Periodically, possibly by subscription or by regularly scheduled requests (map update request), Information Service Providers may request and download map updates from a Map Update Provider.

  3. Schedule information for alternate mode transportation providers such as train, ferry, air and bus (multimodal information) can be received by Information Service Providers as either direct response to their multimodal information request or as subscription transactions.

  4. Optionally, asynchronously, and as often as desired, a Driver may request (driver inputs) a ride match.

  5. Once a route is requested by the Driver (driver inputs), a continuous cycle occurs (through Step 8), beginning with the driver’s ride-match request being sent (trip request). The ride-match request the Driver enters may be on behalf of the passengers using his shuttle service or it may be his own individual trip.

  6. ISPs may exchange information (ISP coordination) for a variety of reasons: contractual information access restrictions, proprietary data sources, economy of scale, cooperative agreements, etc. This information about traffic conditions, special events, link travel times, etc. may be subsequently used in determining the best ride-match. Potentially, there could be two ISPs offering ride-matching services in a cooperative situation with a driver coming in on one service and a rider on another service. Once a match has been confirmed, then further ISP coordination occurs.

  7. The Information Service Provider sends a suggested ride-match and its associated information (trip plan) back to the Vehicle.

  8. The Vehicle Subsystem presents the ride-match to the Driver (driver updates), and then the Driver either accepts the match (and the cycle stops) or asks for another match (and the cycle repeats – back to Step 5).

  9. Once the Driver has accepted a ride-match, a confirmation that the match has been accepted is sent back to the ISP (trip confirmation).

  10. An ISP may present a request for payment (payment request) and then receive transaction status on that request from a Financial Institution. This would depend upon whether there is a fee for the ride-matching service.

  11. Optionally, asynchronously, and as often as desired, a Traveler (passenger) may request (traveler inputs) a ride-match via personal computing device or kiosk.

  12. Once a ride-match is requested by the Traveler (traveler inputs), a continuous cycle occurs (through Step 16), beginning with the traveler’s match request being sent (trip request).

  13. One way a ride-match request can be satisfied is through paratransit or other demand responsive transit service. If this is acceptable to the Traveler, a demand responsive transit request is sent to the Transit Management Subsystem for a plan. If paratransit services can fulfill the ride request, then a demand responsive transit plan is returned to the ISP.

  14. ISPs may exchange information (ISP coordination) for a variety of reasons: contractual information access restrictions, proprietary data sources, economy of scale, cooperative agreements, etc. This information about traffic conditions, special events, link travel times, etc. may be subsequently used in determining the best ride-match. Potentially, there could be two ISPs offering ride-matching services in a cooperative situation with a driver coming in on one service and a rider on another service, or two riders using different services. Once a match has been confirmed, then further ISP coordination occurs.

  15. The Information Service Provider sends a suggested ride-match and its associated information (trip plan) back to the device that originated the ride-match request (Step 11).

  16. The ride-match is then presented to the Traveler (traveler interface updates), and then the Driver either accepts the match (and the cycle stops) or asks for another match (and the cycle repeats – back to Step 11).

  17. Optionally, in conjunction with the financial transaction with the Financial Institution (step 20 below), a request for payment and corresponding payment may be made using the Traveler Card. If payment is required for the information request, and the Traveler Card is capable of making the payment, the transaction with the Financial Institution may not occur. This Traveler Card payment may be a minimum charge merely required just to use a public device such as a kiosk, and a separate transaction charge may also be required, depending upon the service.

  18. Once the Traveler has accepted a ride-match, a confirmation that the match has been accepted is sent back to the ISP (trip confirmation).

  19. If the ride-match included the use of paratransit or other demand responsive transit (from Step 13), then notification is sent back to confirm that usage and a request to do the pick-up (demand responsive transit request).

  20. An ISP may present a request for payment (payment request) and then receive transaction status on that request from a Financial Institution. This would depend upon whether there is a fee for the ride-matching service.