National Academy of Sciences | 150 Year Anniversary

Questions? Call 800-624-6242

| Items in cart [0]

The National Academies Press

Rights & Permissions

topleft topright

TCRP Report 115: Smartcard Interoperability Issues for the Transit Industry (2007)
Transit Cooperative Research Program (TCRP)

Citation Manager

Transportation Research Board. "5.2 Identification of the Data Types." TCRP Report 115: Smartcard Interoperability Issues for the Transit Industry. Washington, DC: The National Academies Press, 2007.

Please select a format:

BibTeX EndNote RefMan


Page
70
bottomleft bottomright
Page
70
Front Matter (R1-R9)
Summary (1-2)
Chapter 1 - Introduction (3-3)
1.2 Elements of Fare Payment Interoperability (4-4)
1.3 Interoperability Across Regions (5-5)
1.4 Interoperability Beyond Transit (6-6)
1.5.1 Acceptance of Contactless Bank Cards (7-8)
1.5.3 Multiple Payment-Enabled Devices (9-9)
1.6 Hypothetical Examples - Interoperability Between WMATA and TransLink (10-10)
1.6.1 Information to Be Exchanged for Payment (11-12)
1.6.3 Process for Determining the Net-Settlement Position (13-13)
2.1 Management and Organizational Issues (14-14)
2.1.1 Establishing a Governing Body or Project Sponsor (15-16)
2.1.2 Identifying and Mitigating Operational Differences (17-17)
2.1.3 Establishing a Framework for Program Funding (18-18)
2.1.4 Creating a Rollout Schedule (19-19)
2.1.5 Developing a Contracting Strategy (20-21)
2.2.2 Funds Pool Management (22-22)
2.2.3 Financial Exposure and Risk Associated with Advanced Features (23-23)
2.3.2 New Processes (24-24)
2.4 Equipment Design Issues (25-25)
2.5.2 Supplier Behavior (26-26)
2.5.3 Supplier Compliance with Available Standards (27-27)
Chapter 3 - Findings of Peer Review of Interoperable Smartcard Programs (28-28)
3.1.1 SmarTrip (29-33)
3.1.2 TransLink (34-34)
3.1.3 Chicago Card (35-35)
3.1.4 Central Puget Sound Regional Fare Coordination (RFC) Project (36-36)
3.1.5 Go-To Card (37-37)
3.1.6 Orlando Regional Alliance for Next Generation Electronic Payment System (ORANGES) (38-38)
3.1.7 Go Ventura (39-39)
3.1.8 Transit Access Pass (TAP) (40-40)
3.1.9 Compass (41-41)
3.1.10 Octopus (42-42)
3.1.11 EZ-Link (43-43)
3.1.12 Oyster (44-44)
3.2.1 Commonalities and Differences (45-46)
3.2.2 Current Trends and New Developments (47-47)
3.4.2 SmarTrip (48-48)
3.5 Summary (49-50)
4.1 Industry Interoperability Analysis (51-51)
4.2.1 Physical Layer (52-56)
4.2.2 Data Layer (57-59)
4.2.3 Application Layer (60-60)
4.2.4 Security Layer (61-66)
4.3 Gap Analysis (67-68)
5.1 Development of Conceptual Fare Payment System Architecture (69-69)
5.2 Identification of the Data Types (70-70)
5.3.2 Operation Data Flows (71-73)
6.1 Scope of the Data-Management Policy (74-74)
6.2.1 Data Location (75-75)
6.3 Identification of Stakeholders and Their Roles and Responsibilities (76-76)
6.4 Other RequirementsPrivacy (77-77)
6.5 Current Trends (78-78)
7.1 Use of Standard API in Proof of Concept (79-82)
7.2 Development of AFC Simulator (83-84)
7.3 Demonstration (85-85)
7.4 Conclusion (86-86)
Chapter 8 - Conclusions (87-91)
Appendix A - Set of Functionality for a Standard API (92-99)
Abbreviations used without definitions in TRB publications (100-100)

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 70
70 Smartcard Interoperability Issues for the Transit Industry Reader Agency Clearinghouse Clearinghouse Card B B B A Figure 12. Figure data flow logic. 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. Central System Tier Agency Tier Station/ Local Tier Device Tier Card Tier Figure 13. Conceptual smart card system architecture.