Cover Image

Not for Sale



View/Hide Left Panel
Click for next page ( 46


The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 45
Findings of Peer Review of Interoperable Smartcard Programs 45 HCRs, Ticket machines, Ticket office machines, and Back office and central system equipment. Oyster's plans include expanding beyond transit by adding an open e-purse to the card and moving outside London by integrating with other railways in the United Kingdom. 3.1.12.1 Fare Policies The following fare policies and customer features define the Oyster program: Card Fee--3 for pre-pay, 7-day, and bus passes, all others free; Fare Products--e-cash, passes; Fare Categories--Adult, senior/disabled freedom pass, employee; and Other Features--Balance protection, station-specified recharge, and Internet loads. In addition to TVMs and ticket offices, Oyster cardholders can add value to their card via tele- phone and Internet and at participating retail outlets. 3.1.12.2 Transit Benefits Programs A voucher program provides an Oyster card to employees of employers who participate in the program. The employer covers the cost of the Oyster card. The employer is then reimbursed through interest-free employee payroll deductions. 3.1.12.3 Loyalty Programs A loyalty program was launched that deducts 2003 adult single fares for trips taken in 2004 on the Tube and DLR. Plans include "Pre Pay Capping," which will establish a maximum amount a traveler pays on any one day. 3.2 Findings The single commonality for all regional fare payment systems implemented is the proprietary nature of the design. Most contactless smartcards issued are proprietary (i.e., either Sony Felica card in Asia or CTS Go CARD in The United States and Canada). All of the interfaces to the back office system are considered proprietary. The security architecture is unique to each supplier. The lack of open specifications is the primary barrier to interoperability and the use of a transit pay- ment card for non-transit applications across the world. Suppliers continue to refuse to publish the interface documentation necessary to allow broad participation in an interoperable smart- card system. The only way interoperability has been achieved is by forcing the use of a single smartcard fare payment system supplier across a region. 3.2.1 Commonalities and Differences Critical information necessary to achieve transit fare payment interoperability may be grouped into the following elements: Physical Elements-Mechanical and electro-physical characteristics of the contactless smartcard; Data Elements-Minimum information stored on the card that allows fare calculations to be conducted; Application Elements-Transit-specific data elements that facilitate transit operator-specific data needs for special services or reporting;

OCR for page 45
46 Smartcard Interoperability Issues for the Transit Industry Security Elements-Methodology used to secure the data on the card from unauthorized access and manipulation; and Optional Data Elements-Information required to increase the utility of the card for other uses than fare payment. The findings of the survey are discussed within the context of the interoperability elements. In order to achieve interoperability, all five elements have to be defined and complied with by all participants in a smartcard system. This rule applies to both transit and non-transit participants. 3.2.1.1 Physical Elements To achieve physical interoperability, a common set of physical characteristics for the smart- card needs to be defined, particularly if physical manipulation is required, such as insertion into a slot or automatic dispensing. The most common physical specification is conformance to ISO 14443 Part 1 contactless interface standard. Though not fully ISO 14443 Type A or Type B com- pliant, virtually all projects profiled use ISO 14443 Part 1 conforming cards. 3.2.1.2 Data Elements Tables 7, 8, and 9 make clear that, with few exceptions, the agencies profiled exchange the fol- lowing data: Card ID number, Card issuer identification, Patron profile code, Fare product ID number, Fare product validity period, Agency identification, Date and time of specific transaction, Entry and/or exit location of patron, Hotlist number, and Transaction value. The exceptions result from the level of functionality required by the fare payment system, whether the card includes a stored-value purse or just passes. These data are the minimum required to process inter- and intra-agency fare payment transactions. The data elements accom- modate existing fare structures and transfer agreements through the use of a common fare media--the contactless smartcard. 3.2.1.3 Application Elements A standard "application elements" definition for transit does not exist today in a published specification available to the public. Although interoperability exists within smartcard imple- mentations, the application is proprietary and specific to the region's implementation. As an example, although the CTA Chicago Card application and the WMATA SmarTrip application use the Go CARD platform, the SmarTrip application is not supported within the CTA system, nor is the Chicago Card application supported within the WMATA system. Similarly, although the San Francisco TransLink application and the Go Ventura application use the MV5000 series plat- form, the two applications are not interchangeable. Therefore, despite interoperability within specific regional implementations, there is no non-proprietary, open standard application defi- nition that provides interoperability across a single supplier. However, applications such as SmarTrip, TransLink, and Chicago Card have integrated their employee benefits program with their card technology and therefore exchange of such data between operators is possible. The data exchange of these benefits is at the discretion of the transit properties. Other agencies, such as in San Diego and Los Angeles, are considering this