APTS04-Transit Fare Collection Management 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 2 TSDs and so only a portion of the numbered items below refer to the above TSD.

APTS04 transaction set diagrams: 1 2 Next TSD

  1. At roadside locations (e.g. a transit stop with a kiosk), a Traveler makes a request for a fare transaction (traveler inputs), which would include the desired destination, to the Remote Traveler Support Subsystem (RTS). The RTS forwards the request (as part of transit fare and passenger status) to the Transit Management Subsystem (TRMS). At this point there are two possible operational concepts. In the first the payment request is forwarded to a Financial Institution, who in real time provides a transaction status indicating if the transaction is approved (it could be either a credit transaction or a debit transaction). The TRMS would forward the transit fare information back to the RTS, which would provide an indication to the Traveler (as part of traveler interface updates) whether their request was successful and possibly provide a ticket or other form of receipt. Alternatively, the request from the RTS is processed by the TRMS in real time and the response sent back to the RTS. The interface to the Financial Institution is a periodic, batch type update. A third concept supported in the diagram is for the Traveler to make the initial request (traveler inputs), but use a Traveler Card for the payment media. In this case the RTS sends a request for payment to the Traveler Card, which responds with the payment information.

  2. Another electronic fare payment concept is for customers of an Information Service Provider (ISP) to request an advanced fare payment (i.e. request a future transit service, such as a demand responsive transit pickup, that could be paid for in advance) through the ISP, who makes the request to the TRMS (a part of the flow transit information request). The TRMS responds with the transit request confirmation.

  3. Electronic fare payment systems may operate within a single agency, or they may be regional in nature. For the latter case agencies provide a form of payment reconciliation where they inform each other of the transactions within their system using cards issued by the other system. The National ITS Architecture represents this as the flows transit fare coordination between TRMS and Other Transit Management. The entity Other Transit Management could also represent a regional reciprocity authority that coordinates fare payments among multiple agencies in a region.

  4. Fare management onboard a transit vehicle is handled slightly differently. One possible fare management concept on a transit vehicle is to carry a list of the invalid fare cards that would be updated at some interval (possibly daily). To obtain this updated list, the Transit Vehicle Subsystem (TRVS) sends the request (request for bad tag list) to the TRMS, which responds with the updated list (bad tag list). As part of managing the fare collection on-board transit vehicles, Transit Operations Personnel can initiate adjustments to the fares charged on various routes (as part of transit operations personnel inputs). This might occur through the changing of a fare scheme (e.g. putting a weekend fare scheme into place during some special weekday event), or through adjustments of individual fares. The TRMS provides this fare management information to the TRVS.

  5. Another supported on-board electronic fare concept supported is to use a Traveler Card for the payment media. In this case the TRVS detects the boarding and alighting of a passenger and sends a request for payment to the Traveler Card, which responds with the payment information. The Traveler may input information to the TRVS about their intended trip such as the destination (traveler inputs). The TRVS then informs the Traveler of the status of the transaction (traveler interface updates). The Traveler Card could be a stored value type card that requires no outside verification, or it could be a credit/debit card that is checked via the invalid tag list discussed above. The TRVS also provides information to the TRMS regarding the on-board fare system (fare collection data). This information includes system status (i.e. the health of the system), transaction status, and even video images associated with fare violations. An alternate operational concept is for the fare collection data to be a periodic, batch type transmission. The information on the fare system is passed along to the Transit Operations Personnel as part of transit operations status. If fare violations are collected, then payment violation notification is sent to the Enforcement Agency.