Smartcard Interoperability Issues for the Transit Industry (2006)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

This chapter identifies the data that need to reside on a smartcard and the information that needs to be exchanged between participating agencies. There are two types of information flows in an interoperable smartcard system: • Institutional Information-Related to the business rules and policies that provide the guide- lines for participation in the smartcard system. The institutional information is discussed in detail in Chapter 2. • Transaction Processing Information-Consists of the following data as depicted in Figure 12: – Resides on the card, – Flows between the card and reader, – Flows between the reader and agency, – Flows between the agency and clearinghouse, and – Flows between clearinghouses. To prepare the transaction-processing information flows, the following tasks must be completed: • Development of a conceptual fare payment system architecture, • Identification of the data types, and • Analysis of the data flows. 5.1 Development of Conceptual Fare Payment System Architecture A smartcard fare payment system architecture consists of the following five functional tiers: 1. Card or Data Input Tier-Data repository for holding the value required to acquire the ser- vices desired; 2. Device Tier-Reads the card and conducts the transaction according to the business rules embedded in the software; 3. Station or Local (Garage or Depot) Tier-Manages the assigned devices and consolidates and transfers the transactions to the next tier; 4. Agency Tier-Manages the transfers of device configuration data and the transactions with the central system and may also be used as the agency interface with the central system for sys- tem management and reporting; and 5. Central System Tier-Primarily responsible for clearing and settlement; the database also sup- ports the card services operation. This five-tier model is referenced for most of the standards development efforts in the United States and Canada, particularly the APTA Universal Transit Farecard Standards UTFS). Figure 13 illustrates the five tiers of an interoperable regional smartcard fare payment system. 69 C H A P T E R 5 Findings of Data Flows Between Agencies

Depending on agency size and the supplier’s system design, the functionality of the station/local tier and the agency tier can be consolidated into a single server or workstation (com- puter). A typical smartcard fare payment system is an off-line system; data are stored at each tier and periodically forwarded to the next tier or to the central system. In contrast, credit and debit card transactions are conducted on line; the transaction is authorized before approval. 5.2 Identification of the Data Types The following two types of data flow among the five tiers: • Configuration Data-Includes all data a device needs to conduct a secure and appropriate fare payment transaction and • Usage Data-Primarily consists of the transaction records associated with each device, but includes any recorded alarms or events. All data transferred between each tier in the system architecture may be categorized as con- figuration or usage data. Configuration data are generally transferred to the device tier at the start of operation. For buses, start of operation may occur when a driver logs on before pulling out of the depot. On a gated rail system, start of operation may begin before trains begin the morning rush hour. Usage data are transferred at the end of an operating cycle and at a predetermined cut-off time. Usage data need to be transferred to the central system in sufficient time to allow processing and settlement to be completed according to agency requirements. 70 Smartcard Interoperability Issues for the Transit Industry Figure 12. Figure data flow logic. Central System Tier Agency Tier Station/ Local Tier Device Tier Card Tier Figure 13. Conceptual smart card system architecture. Card ReaderB Agency B Clearinghouse B Clearinghouse A

Table 15 provides an overview and examples for each type of data that flows through a smart- card fare payment system. 5.3 Analysis of Data Flows Because of the performance requirements of transit operations, the smartcard does not per- form any calculations with the exception of dynamic encryption. Dynamic encryption occurs as the data are transferred between the card and reader. The card-based microprocessors are not fast enough to conduct card-based fare calculations at this stage of technology development while passengers are boarding a bus or passing through a faregate. In the transit environment, the smartcard serves as a secure data repository for fare value. 5.3.1 Data on the Smartcard Table 16 lists the minimum data required on the card to clear and settle transactions for an interoperable smartcard payment system. This also assumes that the physical and security layers are compatible. A detailed discussion of the information exchange layers between the card and reader is provided in Section 4.2. These minimum data requirements are based on analysis con- ducted as part of the design-review process for projects such as TransLink. 5.3.2 Operation Data Flows The operation data flows provide the basis for identifying the functionality that the API will need to accommodate. The API functional requirements will be identified in Appendix A. Fig- ure 14a shows the data flows that occur during normal system operation and identifies the tiers relevant for each data element. Figure 14b provides a functional description of each tier and iden- tifies where the data elements reside in the system architecture flow. Findings of Data Flows Between Agencies 71 Configuration Data Description/Examples Description/Examples • Business Rules • Fare Policies and Transfer Rules • Software Version Control • Software in Device, Valid Device in System • Hot List • Bad Cards • Action List • Prepaid Autoload • Localization Rules • Rules that Apply to Specific Services Such as Express Bus • Device Configuration • Ensure Bus Device is for Bus • Security Keys • Keys to Unlock Data on Card for Write Function Usage Data • Fare-Payment Value • Amount Deducted from Card • Fare-Payment Type • Stored Value, Monthly Pass • Add Value • Amount Added to Card • Autoload • Amount Automatically Loaded • Event • Pass-Back Disabled to Conduct Multiple Transactions • Alarm • Bad Card, Hotlisted Card Detected Table 15. Configuration and usage data matrix.

72 Smartcard Interoperability Issues for the Transit Industry Central System Tier Agency System Tier Station/ Local Consolidation Tier Device Tier Card Tier Configuration Data Hot List Action List Software Version Control Security Keys Device Configuration Localization Rules Transactions Autoload Events Alarms Usage Data Configura Data Usage t Figure 14a. Data flow analysis. Card Data Product Data Journey Data • Card Identification Number • Card Issuer Identification • Patron Profile Code • Card Validity Period • Product Identification Number • Product Validity Period • Electronic Purse • Agency Identification Number • Date and Time of Journey Event • Entry and Exit Location of Journey • Route Number Table 16. Minimum data required on card.

Findings of Data Flows Between Agencies 73 Figure 14b. Functional data flow matrix. Central System Tiertr l t i r Clearing and settlementFunds transfer l ri s ttl t s tr sf r Configuration Data (CDfi r ti t ( Hot list Software (application management) Device configuration Localization rules Business rules t list oft are (application anage ent) evice configuration Localization rules usin ss r l s Usage Data (UD) t ( ) System management Reporting Transaction record – Payment – Addvalue – Autoload Events r ns cti n record – ay ent – ddvalue – utoload v ts Agency System Tier t i r Agency wide consolidation Device management cy i c s li ti evice anage ent CD Pass through to local tier Local device management ass through to local tier Local device anage ent UD Pass through for local tier to central system Event data Alarm Maintenance actions ass through for local tier to central syste vent data lar aintenance actions Station/Local Consolidation Tier t ti / l li ti i r Local consolidation – Transactions “agency” validation System management – Systems configuration – Local device management Reporting System monitoring Fare table management CD Device Configuration Device validity Software version Hot list vice figurati evice validity oft are version ot list UD Payment location (vehicle, station) Payment time and date Device ID Added value y t l c ti (v icl , st ti ) ay ent ti e and date evice I dded value Device Tieri i r Transaction processingTransaction consolidation ransaction processing ransaction consolidation Card configuration Card validation (security) CD Card validity Remaining value Autoload rd v lidity i i g v l utoload UD Fare payment value Fare payment type Added value are ay ent val ar y t ty dded value Card Tierr i r Device authentication Transit application data storage Key evice authentication r sit lic ti t st r y Usage Data (UD) value configuration Configuration Data (CD)