Skip to main content

Currently Skimming:


Pages 3-13

The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.


From page 3...
... • Chapter 3 identifies the data elements and information exchanged that are critical for implementing smartcard interoperability. • Chapter 4 delineates the necessary information flows as follows: – Information flows that define the requirements for developing the API and APDU, – Information that needs to reside on the card, and – Data flows between each level in the system architecture.
From page 4...
... 1.1 Interoperability Defined For this research project, TRB defines interoperability as "the ability of different agencies to coordinate and share information so that passengers can travel in a seamless fashion."Travel may occur on public transit, on a toll road or toll bridge; it may include the use of a parking facility. Travel in a seamless fashion is primarily driven by these factors: • Coordination of transfer points; • Schedule coordination; • Simplified and coordinated tariff structures; • Transfer facilities design; • Consistent passenger processes and operational procedures, – Boarding, – Fare payment, and – Fare inspection; • Common interoperable fare media; and • Convenience in obtaining fare or payment media.
From page 5...
... • Items controlled by participants; • Dispute resolution; and • Legal framework. The Participation Agreement drives the information requirements for institutional interoperability.
From page 6...
... suppliers have to work together to accomplish inter- and intra-regional interoperability, particularly when there is a significant generation gap in the technologies employed. 1.4 Interoperability Beyond Transit The financial services industry anticipates two types of interoperability opportunities with transportation participants: • "Real Estate" Sharing on the Card -- There are two models.
From page 7...
... • Procedures for exchanging data, and • Processes for clearing transactions. The primary reason interoperability has not proliferated beyond transit is the proprietary nature of fare payment systems.
From page 8...
... The transit application residing with a credit card application on the same chip has been the vision for smartcards since the early 1990s. Though technically feasible, the institutional barriers still make this configuration economically infeasible.
From page 9...
... The primary characteristic of this architecture is the disaggregation of payment from the ridership information. Similar to a retail transaction where the cash register calculates the sale, the faregate or farebox conducts the sale.
From page 10...
... to provide merchants with maximum flexibility to choose which contactless payment products to accept. 1.6 Hypothetical Examples -- Interoperability Between WMATA and TransLink To determine what information must be exchanged between systems to create interoperability, two real-world systems were selected for the following hypothetical examples: • Using a TransLink Card from the San Francisco Bay Area Region to pay for riding a Washington Metropolitan Area Transit Authority (WMATA)
From page 11...
... To identify the minimum information required to allow financial settlement between two or more participating entities, which may include a non-transit merchant, the following examples have been developed for each distinct process: • Information to be exchanged for payment only, NO card loads; • Information to be exchanged for loading value, NO payment transactions; and • Process used to determine settlement position by a participant, the aggregation of payments and loads. 1.6.1 Information to Be Exchanged for Payment Figure 5 identifies the minimum information to be exchanged between each element of a fare payment system -- from the inception of the transaction between the card and reader, through Introduction 11 *
From page 12...
... 12 Smartcard Interoperability Issues for the Transit Industry Trans # Card # Date & Time Load Value $ WMATA Terminal # k niLs narT met syS WMATA Load Transactions d eri uqeR n oit a mr of nI Time Date Location (terminal number) Load Value $ Card type Card number sk naB TransLink Central Processor WMATA Central Processor Settlement File SmarTrip Card TransLink Bank WMATA Bank $ k niLs narT met syS d eri uqeR n oit a mr of nI sk naB Figure 6.
From page 13...
... transfer of funds to the agency bank. This hypothetical example isolates the logic and dataflow to payment transactions only; no loads take place.


This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More information on Chapter Skim is available.