Table of Contents - APTAStandards.com

More documents

Recommendations

Info

emergency routine activities (e.g. start of business day, end of business day, operator logged-on, device access door opened), that will serve as the diary for device actions. Subtype 5, device event with status, conveys more information about an event in the device. The event code is supplemented with a status field, as well as the standard UD record header fields. This type of message is used to report information on configuration errors, with the additional status field providing type of the error. The device event with data messages, Subtype 16, has a variable amount of accompanying data. In addition to specifying the underlying event, this UD record provides additional details. For example, where “valid maintenance card presented” is a device event code, “Card Serial Number” would be the additional event data that is sent in the UD. The interpretation of the data is specific to a particular event being reported. 4.7.4.5 Peer-to-Peer Clearing and Settlement TransLink ® does not provide any messages for peer-to-peer clearing. The system is designed and implemented based on a regional settlement approach. 4.7.4.6 Additional Messages Offered TransLink ® does not define any additional messages. 4.7.5 Data Elements Listed below are the standard data types used to represent TransLink tion data: ® card data, usage data and configura • ASCII • Bitmap • Binary TransLink lements is provided in Appendix C) ® data elements cover a majority of the data elements supported by the UTFS Workpackage 1. (A full list of data e 4.7.6 Message Sequences Not part of the documents reviewed. 4.7.7 Security Requirements To achieve high data integrity both parties involved in a communication session authenticate each other through three-pass authentication scheme using MAC. Page 56
Following the authentication process a session key is generated for each transmission. All data transfers are also encrypted against eavesdropping. 4.7.8 Timing and Routing The TransLink ® system architecture i l structure with the TransLink ® Central System (TCS) at the top. The T d to all platforms at the next tier rough Headquarter Computer Systems (HCS). An HCS has connections to, and anages many TransLink ® s a hierarchica CS is connecte th m Data Servers (TDS). The TDS manages one or more Card Interface Devices (CID) or Distribution Devices (AVM). Each node at a tier in the system communicates to all subordinate nodes and has a single connection to the next higher tier. This requires all transactions in the TransLin Fare Payment System (FPS) to be transported through each processing tier before arriving at the TCS. The processing requirements of each level determine what transactions are filtered and formatted into database structures. All messages must be forwarded to a higher level until they reach the TCS. For example, a message generated at a device is submitted to the TDS then forwarded to the HCS. The HCS then has the responsibility for sending its transactions to the TCS. provides four different date definitions in operation cycle as follows: TransLink ® • Operating Date • Business Date • Reconciliation Date • Settlement Date T he current operating date is a date tha t may be different from the current calendar date. For example, the current cal endar date may already be 18 February 2004, at 1:00 am, but the current operating date is still 17 February 2004 because the operating date changes eve ry day at 3:00 am. The transaction business date is generated by a device, and added to the transaction at the TDS level. It is the current operating date of the device or TDS acquiring the device UD. Typically, business dates reflect the operational business date of a transit operator—the period of their normal daily business hours. For example, if a transit oper ator operates from 6:00 am to 2:00 am, (their business day), the business date changeover will occur at 2:00 am. This allows the system to generate operational reports that reflect transaction/passenger loads tied to their operational schedules. The business date usually is applied at the devices or the TDS because these nodes typically operate offline. The business date is typically incremented during the transit operator end-of-day process. The reconciliation date is added to the transaction at the transit operator level. It is the current operating date on the transit operator’s central system. This date is used to Page 57 k ®
Page 1 and 2:
SMART CARD STANDARDS AND SPECIFICAT
Page 3 and 4:
4.4.7 Security Requirements........
Page 5 and 6:
Document History Revision Reason Fo
Page 7 and 8:
Acronym List UTFS Universal Transit
Page 9 and 10: technology to achieve interoperabil
Page 11 and 12: This report encompasse s the review
Page 13 and 14: Identify S m art Card Indust ry S t
Page 15 and 16: The standards and specifications th
Page 17 and 18: These standards and specifications
Page 19 and 20: Although there is no “one-to-one
Page 21 and 22: 4.1.4.2 Card Management Data The st
Page 23 and 24: with ISO/IEC 7816-6, there is no re
Page 25 and 26: these messages constitutes a file.
Page 27 and 28: Phone interviews and/or email corre
Page 29 and 30: The ITSO message body consists of i
Page 31 and 32: Exhibit 4.2-2 Product Types Type Co
Page 33 and 34: Capability Values or RFU Product Pr
Page 35 and 36: opted to contract these services ou
Page 37 and 38: e given careful consideration for a
Page 39 and 40: - Transaction date and time - Trans
Page 41 and 42: cardholder related data as in the c
Page 43 and 44: CLIENT Exhibit 4.3-9 OFX Security S
Page 45 and 46: may well be eliminated if, and when
Page 47 and 48: Exhibit 4.4-4 Condition Dialogue St
Page 49 and 50: 4.4.7 Security Requirements The Mes
Page 51 and 52: Application Retailer Product Retail
Page 53 and 54: Exhibit 4.6-1 CID Edge Interface Me
Page 55 and 56: 4.6.8 Timing and Routing The CID Ed
Page 57 and 58: 4.7.4.1 Transaction Data The “Far
Page 59: 4.7.4.3 System and Device Data The
Page 63 and 64: Data” transaction messages propos
Page 65 and 66: Field Name Description reading the
Page 67 and 68: 4.8-7 Product Transactions Usage Me
Page 69 and 70: 4.8.4.5 Peer-to-Peer Clearing and S
Page 71 and 72: standard does not mandate the compl
Page 73 and 74: Item Number Exhibit 4.9-2 Part 1 Fi
Page 75 and 76: 4.9.4.2 PICC Scheme Control Message
Page 77 and 78: • Registration • Negative List
Page 79 and 80: 5.0 FINDINGS This section presents
Page 81 and 82: Exhibit 5-2 illustrates the relevan
Page 83 and 84: Required. This set of specification
Page 85 and 86: Project/Specification/Standard Spon
Page 87 and 88: APPENDIX B COMPLETED CRITERIA FORMS
Page 89 and 90: ISO/IEC 8583 Criteria Transaction D
Page 91 and 92: TRANSLINK ® Criteria Transaction D
Page 93 and 94: RIS PART 4 Criteria Transaction Dat
Page 95 and 96: ITSO DATA ELEMENTS Message Type Dat
Page 101 and 102: Amount Net Reconciliation Receiving
Page 103 and 104: TRANSLINK Message Type Data Element
Page 105 and 106: Autoload non-purse counter remote l
Page 107 and 108: card status failure reason Business
Page 109 and 110: RIS PART 4: FOR A LIST OF DATA OBJE
show all

Table of Contents - APTAStandards.com

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?