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 83
Findings of Proof of Concept Using Standard API 83 7.2 Development of AFC Simulator The simulator is designed to perform the AFC functions such as processing the fare tickets based on the type of tickets, the issuing agencies, validation periods, reading and updating purse balances, and issuing the fare tickets. Three types of fare tickets (i.e., trip-based, time-based, and purse) can be processed with the simulator. The data structure design of each type of ticket is based on the minimum data requirement of transit fare ticket and is a set of common data derived from an analysis of the four primary standard specifications: Regional Interoperability Standard for Electronic Transit Fare Payments (RIS), ITSO, CEN, and RKF. Table 19 shows the data fields of the card. The data structure has been implemented on both a Philips Mifare DESFire smartcard and Philips Mifare UltraLight smartcard. Because of the differing capabilities of the operating sys- tems of each card, the fare ticket's data structure is implemented differently on each type of card. The DESFire Card Operating System (COS) supports a file structure, and the data structure of the fare ticket on this card is implemented as a file system with a security key on each file. Access- ing and updating the card's information requires authentication of the security key. Because of the secure file system feature, the electronic purse fare product is implemented on this card. Trip-based pass and time-based pass products have also been implemented on the DESFire card for use as reusable fare tickets. Figure 16 shows the file structure of fare tickets on Mifare DESFire card. The Philips Mifare UltraLight COS supports a memory block architecture to store the data. The fare ticket's data structure is implemented as a block, and can be configured to be irreversible when the card is issued from the AFC simulator. Since the fare ticket information on this card Table 19. Data fields of fare tickets. Card Holder Information Fare Ticket Information Transaction Information · Unique Card Number · Ticket Type · Date and Time · Name · Balances · Type of Transaction · Birth Date · Validity Period · Transaction Amount · Profile Code · Issued Agency · Original Balance · Card Validity Period · Electronic Purse Fare Ticket Directory File 1 File 5 Card Holder Information Transaction Information · Name · Date and Time · Birth Date · Type of Transaction · Profile Code · Transaction Amount · Card Validity Period · Original Balance · Type of Fare Ticket File 2 File 3 File 4 Time-Based Pass Trip-Based Pass Electronic Purse · Validity Period · Trip Balance · Current Issued Agency Code Issued Agency Code Balance Issued Agency Code Figure 16. File structure of fare ticket on Mifare DESFire card.
OCR for page 84
84 Smart Card Interoperability Issues for the Transit Industry cannot be changed once it is written, the card can be issued as a one-time used-fare ticket. The trip-based and time-based pass products on this card are designed to be used up to the maxi- mum number of trips issued or within a period of time that has been written to the card. Because of the lack of data security, the electronic purse should not be implemented on this card. Infor- mation sensitive to the privacy of the cardholder or issuing agency should not be implemented on this card because the data can be read without requiring any authentication. In the AFC sim- ulator, the irreversible data setting was disabled to limit the consumption of UltraLight cards during demonstration. Figure 17 shows the simulator program flow. Business Rule application during transaction processing with the Mifare DESFire is shown in Figure 18. Business Rule application during transaction processing with the Mifare UltraLight is shown in Figure 19. An overview of the soft- ware architecture for the simulator is displayed in Figure 20. Select a reader. Initialize Initialize reader 1. reader 2. Select product type and agencies to accept. Poll for card until card detected by reader. Card Found. Business Rules Display transaction information. Figure 17. Simulator program flow chart.