Table of Contents - APTAStandards.com
Table of Contents - APTAStandards.com Table of Contents - APTAStandards.com
4.5 CEN TC278 – Interoperable Public Transport Fare Management System Architecture (IFMSA) 4.5.1 Description of the Standard CEN TC278 provides the basis for the development of a multi-operator/multi-modal interoperable Public Transport Fare Management System (IFM). The IFM system provides a reference functional architecture for electronic fare payment systems and identifies requirements that are relevant to ensure interoperability between the entities in the system. The IFM system addresses all the functions involved in the fare management process including: • Management of application(s) • Management of products • Security management • Customer management • Inspection/enforcement • Reporting and monitoring When completed, this standard will comprise several parts; currently only Part 1 is available in draft format. Part 1 describes the following main elements: • Identification of the different functional entities in relation to the overall fare management system • Definition of a generic model of IFM system describing the logical and functional architecture and the interfaces within the system and with other IFM systems • Use cases describing the interactions and data flows between the entities • Definition of the security requirements 4.5.2 Applicability to UTFS Effort Although IFM provides a well-defined model for the management of an interoperable transit fare collection system, it is an incomplete draft as of today. In its current form, IFM is a high level document and does not include the level of detail that APTA is looking for and therefore is not applicable to APTA’s scope of work. On a higher level, this document is useful in defining the components and entities involved in an electronic fare payment system as illustrated in Exhibit 4.5-1. Page 46
Application Retailer Product Retailer Custome r Exhibit 4.5-1 IFM Components Product Owner Customer Service Applic Application ation Owner Collection & Forwarding Service Operator Security Manager Registrar Roles and responsibi lities of each entity and the flow of information between entities have clearly been defined on a summary level. Lower level details of the interfaces between entities are to be addressed by upcoming parts of the standard. 4.5.3 Common Message Structure IFM does not specify common message structure in its current form. 4.5.4 Message Types IFM does not specify message types in its current form. 4.5.4.1 Transaction Data IFM does not specify transaction data in its current form. 4.5.4.2 Card Management Data IFM does not specify card management data in its current form. 4.5.4.3 System and Device Data IFM does not specify system and device data in its current form. 4.5.4.4 Event Data IFM does not specify event data in its current form. Page 47
- 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: 4.4.7 Security Requirements The Mes
- 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 and 60: 4.7.4.3 System and Device Data The
- Page 61 and 62: Following the authentication proces
- 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 97 and 98: ITSO DATA ELEMENTS Message Type Dat
- Page 99 and 100: ITSO DATA ELEMENTS Message Type Dat
Application<br />
Retailer Product<br />
Retailer<br />
Custome<br />
r<br />
Exhibit 4.5-1 IFM Components<br />
Product<br />
Owner<br />
Customer<br />
Service<br />
Applic Application ation<br />
Owner<br />
Collection<br />
&<br />
Forwarding<br />
Service<br />
Operator<br />
Security<br />
Manager<br />
Registrar<br />
Roles and responsibi lities <strong>of</strong> each entity and the flow <strong>of</strong><br />
information between entities<br />
have clearly been defined on a summary level. Lower level details <strong>of</strong> the interfaces<br />
between entities are to be addressed by up<strong>com</strong>ing parts<br />
<strong>of</strong> the standard.<br />
4.5.3 Common Message Structure<br />
IFM does not specify <strong>com</strong>mon message structure in its current form.<br />
4.5.4 Message Types<br />
IFM<br />
does not specify message types in its current form.<br />
4.5.4.1 Transaction Data<br />
IFM does not specify transaction data in its current form.<br />
4.5.4.2<br />
Card Management Data<br />
IFM does not specify card management data in its current form.<br />
4.5.4.3 System<br />
and Device Data<br />
IFM does not specify system and device data in its current form.<br />
4.5.4.4 Event Data<br />
IFM<br />
does not specify event data in its current form.<br />
Page 47
Change language