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. "1.3 Interoperability Across Regions." 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
5
bottomleft bottomright
Page
5
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 5
Introduction 5 Visual Visual Ticket Ticket Inspection Inspection Manual Manual System System Collect Collect Paper Paper Media Media Participant Participant Agreements Agreements All Single Single Source Source No All Agencies Agencies Procure ­ ­ Reliant Reliant onon one one supplier supplier Procure ­ Equipment Equipment From From ­ Supplier Supplier hashas $ $ power power Is the One ­ ­ Little Little incentive incentive to to innovate innovate IsIs the the One Supplier Supplier Automatic System Automatic Fare Fare System System Collection Collection System System Standard Inter- or Inter- Proprietary? operable? Multi-Sourcing Multi-Sourcing All All Agencies Agencies ­ ­ Increased Increased competition competition Adopt Adopt AA Common Common ­ ­ Product Product improvements improvements Data Data Format Format ­ ­ Greater Greater flexibility flexibility in in Yes standard participation participation Figure 1. Interoperability model. · Items controlled by participants; · Dispute resolution; and · Legal framework. The Participation Agreement drives the information requirements for institutional interop- erability. Chapter 1 discusses the issues associated with institutional interoperability in detail. The next step is to define the technical information required to achieve interoperability. The business rules articulated in the Participation Agreement define the information to be exchanged by the interoperable smartcard system. At a minimum, the card-to-reader data for- mat and the data format for transferring the transaction records to a central clearinghouse need to be defined. The minimum requirements for implementing an interoperable smartcard system can be accomplished by using one of the following approaches: 1. Procuring the technology from a single supplier, similar to Washington, DC, with the EZ Pass Interagency Group (IAG) 2. Developing an interface specification that defines the requirements with which each partici- pant's supplier has to comply, similar to what is done in the financial services or telecommu- nications industries 1.3 Interoperability Across Regions Most regional systems implemented across the United States and Canada use a single sup- plier for a specific region. Each system has unique characteristics and features. To achieve intra- regional interoperability, the business rules and technology need to be synchronized. Figure 2 illustrates the process for analyzing and identifying gaps in the business rule and technology for a specific group of regions. Each time a new region is added, the entire process needs to be repeated. The primary factor for intra-regional interoperability is the cost of making the nec- essary systems modifications. The most difficult situation to manage is where two competing