1 / 32

CEN TC 278 WG3 SG5 Interoperable Fare Management System Architecture

CEN TC 278 WG3 SG5 Interoperable Fare Management System Architecture. US / CEN Workshop on Fare Management System. David Sentinella Department for Transport. Workshop Agenda. - David - Trond - David - Trond - David - David - Trond. Overview, context setting

sidone
Download Presentation

CEN TC 278 WG3 SG5 Interoperable Fare Management System Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CEN TC 278 WG3 SG5Interoperable Fare Management System Architecture US / CEN Workshop on Fare Management System David Sentinella Department for Transport

  2. Workshop Agenda - David - Trond - David - Trond - David - David - Trond • Overview, context setting • Roles and responsibilities • UK example • Norwegian example • Use Cases • Interfaces • Identification and Security

  3. Operator 3 Operator 4 Operator 2 Operator x Operator 1 Operator y Interoperability - a customer‘s perspective Customer Media Interoperability provides the customer with a seamless journey using one Customer Media independent of the transport means and service providers

  4. Norway UK Denmark Germany France Italy Spain Europe 2000 - Without Interoperability

  5. European Requirements • Interoperability • Hardware & supplier independent interface description • Functionally neutral to specific transport organisation structures • Recognise and prevent internal and external fraud attacks (Security) • Integrity of data • Easy and Fair Settlement, independent of commercial agreements • Flexibility to cover existing and new tariff systems (products) • Compliance with data protection and financial services laws • Multi application customer media

  6. Multi-application Directory - ACCESS E-Europe TB7 / ISSS URI National Project Local ‘existing’ ticketing E-purse Storage ISO 14443 Grammar Application Related TC224 WG11 IOPTA / EN1545 System Related TC278 WG3 ‘FRAMEWORK’ ISSS FASTEST / E-Europe TB9 Directory Products Words Actors TC278 in context - WHY the IFM...

  7. Significant Member Contributions • 15 Members are participating in CEN TC278 WG3 (SG5) • France • Germany • Great Britain • Netherlands • Norway • Switzerland • UIC • Announced schedule for the standard: • work started in May 2000 • Document for formal vote 2004/05

  8. Europe 2004 - interoperability with IFM base Translink Nortic ITSO VDV-Kernapplikation Intercode + interbob Austria

  9. Reduced Maintenance costs Seamless Journey Simplify commercial agreements Competitive procurementsReduced costs Remove barrier to implementation Easy and Fair Settlement Easy Access Increase Boarding capacity Reliable data for Transport planning Easy to extend to larger transport areas and new services Customer adapted Products Enlarged Tariff Product Range Benefits of an IFM User Authority Operator

  10. Scope of the IFM • To provide the basis for multi-operator/multi-service Interoperable Public Transport Fare Management Systems (IFM) on a national and international level. • to define a reference functional architecture • to identify the requirements that are relevant to ensure interoperability between several actors in the context of the use of electronic tickets. • To extend existing international standards to describe ticketing requirements

  11. Functions of the IFM • The IFM system includes all the functions involved in the fare management process such as • Management of Application • Management of Products • Security management • Certification, Registration and Identification

  12. The IFM Standard • Identification of the different functional entities in relation to the overall fare management system. • Definition of a generic model describing the logical and functional architecture. • Use cases describing the interactions and data flows between the different functional entities. • Description of security requirements.

  13. Product owner Application owner SecurityManager Application Retailer Collection & Forwarding Product Retailer Registrar Customer service Service Operator The IFM Model Customer

  14. Roles and Responsibilities

  15. IFM model applied in the UK

  16. Set Of Rules A real IFM system + =

  17. UK Department for Transport Progress “We are actively promoting smartcard technology which will bring the possibility of a whole new range of ticket products, with far more flexibility than is possible at present.”John Spellar, Bus Partnership Forum Feb 03

  18. Realism How to achieve it…. • Buy-in from existing schemes • Local control • Competitive procurements • Appropriate interoperability • Ensure competitive advantage • Consistent customer handling procedures • The any time, any where principle for the customer

  19. The Environment Member organisation Operating Rules Specification management Product registration Security infrastructure Organisation registration Component / system certification Security Management

  20. CEN SETTLEMENT COLLECTION FORWARDING BUY Product Owner USE ITSO Functions Registration Testing Security

  21. Current Priorities • Interoperable supplier tests - PROVEN • Specification Published - March 04 • Legacy and “early adopter schemes” - Summer 2004 onwards • ITSO mandated for Local Authority spend • Co-operation across Government Departments • European Standardisation

  22. Joining up • Transport ticketing Application • Traveller Information • Other applications • Card independence - a ‘family of cards’ • Issues / Opportunities • card sharing / costs…. • Cross fertilisation (specification, commercials, security & testing) • Infrastructure roll out...

  23. IFM model applied in Norway

  24. The IFM - Use Cases

  25. Use Case Descriptions • Use Cases describe a toolbox for the ‘functional’ implementation of IFM systems. • 38 separate Use Cases cover the following areas: • Certification • Registration • Management of Application • Management of Product • Security Management • Customer Service Management

  26. Certification of Product Specification & Template Registration of Product Template Dessemination of Product Template Regular and Forced Termination of Product Template Registration of Product Product lifecycle in the systemCertification & Registration

  27. Example Use Case

  28. Interfaces

  29. Interfaces within IFM • Information flow through IFM • Two types - • interfaces to general IFM functions [registration and security] • interfaces between entities in the IFM • Examples…..

  30. Thank you David Sentinella david.sentinella@dft.gsi.gov.uk

  31. Potential Barriers • Common fare structure - competition law issues • potential for incompatibility between multiple business cases from different providers • Ability to organise numerous organisations • Integration perceived winners and losers • Operators use wide range of old equipment and non computerised processes • eMoney regulations • Senior executive knowledge base • Investment by small operators, specifically with regard to back office development

More Related