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.