ISO 24014-1:2015
(Main)Public transport - Interoperable fare management system - Part 1: Architecture
Public transport - Interoperable fare management system - Part 1: Architecture
ISO 24014-1:2015 provides the basis for the development of multi-operator/multi-service Interoperable public surface (including subways) transport Fare Management Systems (IFMSs) on a national and international level. ISO 24014-1:2015 is applicable to bodies in public transport and related services which agree that their systems need to interoperate. While ISO 24014-1:2015 does not imply that existing interoperable fare management systems need to be changed, it applies so far as it is practically possible to extensions of these. ISO 24014-1:2015 covers the definition of a conceptual framework which is independent of organisational and physical implementation. Any reference within this part of ISO 24014 to organisational or physical implementation is purely informative. The objective of this part of ISO 24014 is to define a reference functional architecture for IFMSs and to identify the requirements that are relevant to ensure interoperability between several actors in the context of the use of electronic tickets. The IFMS includes all the functions involved in the fare management process such as - management of application, - management of products, - security management, and - certification, registration, and identification. This part of ISO 24014 defines the following main elements: - identification of the different set of functions in relation to the overall fare management system; - a generic model of IFMS describing the logical and functional architecture and the interfaces within the system and with other IFMSs; - use cases describing the interactions and data flows between the different set of functions; - security requirements. ISO 24014-1:2015 excludes consideration of the following: - the physical medium and its management; - the technical aspects of the interface between the medium and the medium access device; - the data exchanges between the medium and the medium access device; NOTE The data exchanges between the Medium and the Medium Access Device are proposed by other standardization committees. ? the financial aspects of fare management systems (e.g. customer payments, method of payment, settlement, apportionment, reconciliation).
Transport public — Système de gestion tarifaire interopérable — Partie 1: Architecture
L'ISO 24014-1:2015 fournit les bases pour développer des systèmes billettiques interopérables (IFMS, Interoperable Fare Management System) multi-opérateurs/multi-services pour le transport public (y compris les métros), tant à l'échelle nationale qu'internationale. L'ISO 24014-1:2015 s'applique aux organismes de transport public et aux services connexes qui conviennent que leurs systèmes doivent être interopérables. L'ISO 24014-1:2015 n'implique pas qu'il soit nécessaire de modifier les systèmes billettiques interopérables existants, elle s'applique, dans toute la mesure du possible, à leurs extensions futures. L'ISO 24014-1:2015 couvre la définition d'un cadre conceptuel, qui est indépendante de la mise en ?uvre organisationnelle et physique. Toute référence à la mise en ?uvre organisationnelle et physique dans l'ISO 24014-1:2015 est purement informative. L'objectif de l'ISO 24014-1:2015 est de définir une architecture fonctionnelle de référence pour les systèmes IFMS et d'identifier les exigences de nature à assurer l'interopérabilité entre plusieurs acteurs dans le contexte de l'utilisation de titres de transport électroniques.
General Information
Relations
Frequently Asked Questions
ISO 24014-1:2015 is a standard published by the International Organization for Standardization (ISO). Its full title is "Public transport - Interoperable fare management system - Part 1: Architecture". This standard covers: ISO 24014-1:2015 provides the basis for the development of multi-operator/multi-service Interoperable public surface (including subways) transport Fare Management Systems (IFMSs) on a national and international level. ISO 24014-1:2015 is applicable to bodies in public transport and related services which agree that their systems need to interoperate. While ISO 24014-1:2015 does not imply that existing interoperable fare management systems need to be changed, it applies so far as it is practically possible to extensions of these. ISO 24014-1:2015 covers the definition of a conceptual framework which is independent of organisational and physical implementation. Any reference within this part of ISO 24014 to organisational or physical implementation is purely informative. The objective of this part of ISO 24014 is to define a reference functional architecture for IFMSs and to identify the requirements that are relevant to ensure interoperability between several actors in the context of the use of electronic tickets. The IFMS includes all the functions involved in the fare management process such as - management of application, - management of products, - security management, and - certification, registration, and identification. This part of ISO 24014 defines the following main elements: - identification of the different set of functions in relation to the overall fare management system; - a generic model of IFMS describing the logical and functional architecture and the interfaces within the system and with other IFMSs; - use cases describing the interactions and data flows between the different set of functions; - security requirements. ISO 24014-1:2015 excludes consideration of the following: - the physical medium and its management; - the technical aspects of the interface between the medium and the medium access device; - the data exchanges between the medium and the medium access device; NOTE The data exchanges between the Medium and the Medium Access Device are proposed by other standardization committees. ? the financial aspects of fare management systems (e.g. customer payments, method of payment, settlement, apportionment, reconciliation).
ISO 24014-1:2015 provides the basis for the development of multi-operator/multi-service Interoperable public surface (including subways) transport Fare Management Systems (IFMSs) on a national and international level. ISO 24014-1:2015 is applicable to bodies in public transport and related services which agree that their systems need to interoperate. While ISO 24014-1:2015 does not imply that existing interoperable fare management systems need to be changed, it applies so far as it is practically possible to extensions of these. ISO 24014-1:2015 covers the definition of a conceptual framework which is independent of organisational and physical implementation. Any reference within this part of ISO 24014 to organisational or physical implementation is purely informative. The objective of this part of ISO 24014 is to define a reference functional architecture for IFMSs and to identify the requirements that are relevant to ensure interoperability between several actors in the context of the use of electronic tickets. The IFMS includes all the functions involved in the fare management process such as - management of application, - management of products, - security management, and - certification, registration, and identification. This part of ISO 24014 defines the following main elements: - identification of the different set of functions in relation to the overall fare management system; - a generic model of IFMS describing the logical and functional architecture and the interfaces within the system and with other IFMSs; - use cases describing the interactions and data flows between the different set of functions; - security requirements. ISO 24014-1:2015 excludes consideration of the following: - the physical medium and its management; - the technical aspects of the interface between the medium and the medium access device; - the data exchanges between the medium and the medium access device; NOTE The data exchanges between the Medium and the Medium Access Device are proposed by other standardization committees. ? the financial aspects of fare management systems (e.g. customer payments, method of payment, settlement, apportionment, reconciliation).
ISO 24014-1:2015 is classified under the following ICS (International Classification for Standards) categories: 03.220.01 - Transport in general; 35.240.60 - IT applications in transport. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO 24014-1:2015 has the following relationships with other standards: It is inter standard links to ISO 24014-1:2021, ISO 24014-1:2007. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO 24014-1:2015 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 24014-1
Second edition
2015-10-15
Public transport — Interoperable fare
management system —
Part 1:
Architecture
Transport public — Système de gestion tarifaire interopérable —
Partie 1: Architecture
Reference number
©
ISO 2015
© ISO 2015, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2015 – All rights reserved
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Terms and definitions . 2
3 Abbreviated terms . 4
4 Requirements . 4
5 Conceptual framework . 5
5.1 Description of IFM-roles . 6
5.2 Basic framework of the generic IFM functional model . 8
6 Use Case description for the IFM functional model . 9
6.1 Certification . 9
6.1.1 Certification of Organization .10
6.1.2 Certification of Components .10
6.1.3 Certification of Application Specification and Template .10
6.1.4 Certification of Product Specification and Template .11
6.2 Registration .11
6.2.1 Registration of Organization .11
6.2.2 Registration of Component .12
6.2.3 Registration of Application Template .12
6.2.4 Registration of Application .12
6.2.5 Registration of Product Template .12
6.2.6 Registration of Product .13
6.3 Management of Application .13
6.3.1 Dissemination of Application Template .13
6.3.2 Acquisition of Application .14
6.3.3 Termination of Application Template .14
6.3.4 Termination of Application .15
6.4 Management of Product .16
6.4.1 Dissemination of Product Template .16
6.4.2 Termination of Product Template .17
6.4.3 Management of Action List .17
6.4.4 Acquisition of Product . . .18
6.4.5 Modification of Product parameter .18
6.4.6 Termination of Product .19
6.4.7 Use and inspection of Product .19
6.4.8 Collection of data .20
6.4.9 Forwarding data .21
6.4.10 Generation and distribution of clearing reports .21
6.5 Security management .22
6.5.1 Monitoring of IFM processes and IFM data life cycle .22
6.5.2 Management of IFM security keys .23
6.5.3 Management of security lists .23
6.6 Customer Service Management (optional) .25
7 System interface identification .26
8 Identification .26
8.1 General .26
8.2 Numbering scheme .26
8.3 Prerequisites .26
9 Security in IFMSs .27
9.1 Protection of the interests of the public .27
9.2 Assets to be protected .27
9.3 General IFM security requirements .28
Annex A (informative) Information flow within the IFM .29
Annex B (informative) Examples of implementation .39
Annex C (informative) List of terms which are defined both in this part of ISO 24014
(IFMSA) and in APTA — UTFS .48
Annex D (informative) Example of Action List processes .49
Annex E (informative) Security domain, threats, and Protection Profiles .54
Annex F (informative) Media centric management and back-office centric management .58
Bibliography .60
iv © ISO 2015 – All rights reserved
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for
the different types of document should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical
Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/TC 204, Intelligent transport systems.
ISO 24014-1 was prepared by European Committee for Standardization (CEN) Technical Committee
CEN/TC 278 Road transport and traffic telematics, in collaboration with ISO/TC 204, Intelligent
transport systems, in accordance with the agreement on technical cooperation between ISO and CEN
(Vienna Agreement).
This second edition cancels and replaces the first edition (ISO 24014-1:2007), which has been
technically revised.
ISO 24014 consists of the following parts, under the general title Public transport — Interoperable fare
management system:
— Part 1: Architecture
— Part 2: Business practices
— Part 3: Complementary concepts to Part 1 for multi-application media
Introduction
Fare management (FM) encompasses all the processes designed to manage the distribution and use of
fare products in a public transport environment.
Fare management is called interoperable (IFM) when it enables the customer to use a portable
electronic medium (e.g. a contact/contactless smart card) with compatible equipment (e.g. at stops,
with retail systems, at platform entry points, or on board vehicles). IFM concepts can also be applied to
fare management systems not using electronic media.
Potential benefits for the customer include reductions in queuing, special and combined fares, one
medium for multiple applications, loyalty programmes, and seamless journeys.
Interoperability of fare management systems also provides benefits to operators and the other parties
involved. However, it requires an overall system architecture that defines the system functionalities,
the actors involved and their roles, the relationships, and the interfaces between them.
Interoperability also requires the definition of a security scheme to protect privacy, integrity, and
confidentiality between the actors to ensure fair and secure data flow within the IFM system (IFMS).
The overall architecture is the subject of this part of ISO 24014 which recognizes the need for legal and
commercial agreements between members of an IFM, but does not specify their form. The Technical
Specifications of the component parts and, particularly, the standards for customer media (e.g. smart
cards) are not included.
Note that there is not one single IFM. Individual operators, consortia of operators, public authorities,
and private companies can manage and/or participate in IFMSs. An IFM can span country boundaries
and can be combined with other IFMSs. Implementations of IFMSs require security and registration
functionalities. This part of ISO 24014 allows for the distribution of these functions to enable the
coordination/convergence of existing IFMSs to work together.
This part of ISO 24014 intends to provide three main benefits.
a) It provides a framework for an interoperable fare management implementation with minimum
complexity.
b) It aims to shorten the time and lower the cost of IFM procurement as both suppliers and purchasers
understand what is being purchased. Procurement against an open standard reduces cost as it
avoids the need for expensive bespoke system development and provides for second sourcing.
c) It aims to simplify interoperability between IFMSs to the benefit of all stakeholders.
The work has benefited from the architecture work done in Electronic Fee Collection (CEN/TC 278/WG 1)
and other domains including the following:
— ISO/TS 14904, Road transport and traffic telematics — Electronic fee collection (EFC) — Interface
specification for clearing between operators;
— ISO/TS 17573, Electronic fee collection — Systems architecture for vehicle-related tolling;
— existing international data security standards.
vi © ISO 2015 – All rights reserved
INTERNATIONAL STANDARD ISO 24014-1:2015(E)
Public transport — Interoperable fare management
system —
Part 1:
Architecture
1 Scope
This part of ISO 24014 provides the basis for the development of multi-operator/multi-service
Interoperable public surface (including subways) transport Fare Management Systems (IFMSs) on a
national and international level.
This part of ISO 24014 is applicable to bodies in public transport and related services which agree that
their systems need to interoperate.
While this part of ISO 24014 does not imply that existing interoperable fare management systems need
to be changed, it applies so far as it is practically possible to extensions of these.
This part of ISO 24014 covers the definition of a conceptual framework which is independent
of organisational and physical implementation. Any reference within this part of ISO 24014 to
organisational or physical implementation is purely informative.
The objective of this part of ISO 24014 is to define a reference functional architecture for IFMSs and
to identify the requirements that are relevant to ensure interoperability between several actors in the
context of the use of electronic tickets.
The IFMS includes all the functions involved in the fare management process such as
— management of application,
— management of products,
— security management, and
— certification, registration, and identification.
This part of ISO 24014 defines the following main elements:
— identification of the different set of functions in relation to the overall fare management system;
— a generic model of IFMS describing the logical and functional architecture and the interfaces within
the system and with other IFMSs;
— use cases describing the interactions and data flows between the different set of functions;
— security requirements.
This part of ISO 24014 excludes consideration of the following:
— the physical medium and its management;
— the technical aspects of the interface between the medium and the medium access device;
— the data exchanges between the medium and the medium access device;
NOTE The data exchanges between the Medium and the Medium Access Device are proposed by other
standardization committees.
— the financial aspects of fare management systems (e.g. customer payments, method of payment,
settlement, apportionment, reconciliation).
2 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
2.1
action list
list of items related to IFM applications or products (2.24) downloaded to medium access devices (2.18)
(MADs) processed by the MAD if and when a specific IFM application or product referenced in the list is
encountered by that MAD
2.2
actor
person, an organisation (2.19), or another (sub)system playing a coherent set of functions when
interacting with the IFM system within a particular use case (2.30)
2.3
application rules
application owner requirements
2.4
application specification
specification of functions, data elements, and security scheme according to the application rules (2.3)
2.5
application template
executable technical pattern of the application specification (2.4)
2.6
application
implemented and initialised application template (2.5)
Note 1 to entry: The application is identified by a unique identifier.
Note 2 to entry: The application houses products (2.24) and other optional customer information (customer
details, customer preferences).
Note 3 to entry: The application can be fully installed on a customer media or distributed on the customer media
and the IFM back offices.
2.7
commercial rules
rules defining the settlement and commission within the IFMS
2.8
component
any piece of hardware and/or software that performs one or more functions in the IFMS
2.9
component provider
anyone who wants to bring a component (2.8) to the IFMS
2.10
IFM functional model
model to define functions of IFM-roles (2.12) and how they interact
2.11
IFM policies
commercial, technical, security, and privacy objectives of IFM
2 © ISO 2015 – All rights reserved
2.12
IFM-role
abstract object performing a set of functions in an IFM functional model (2.10)
2.13
interoperable fare management
IFM
all the functions involved in the fare management process such as management of application, products
(2.24), security and certification, registration, and identification to enable customers to travel with
participating service operators using a single portable electronic medium
2.14
interoperable fare management system
IFMS
all technical, commercial, security, and legal elements which enable an interoperable fare
management (2.13)
2.15
medium
physical carrier of applications (2.6)
2.16
message
set of data elements transferred between two IFM-roles (2.12)
2.17
customer medium
medium (2.15) initialised with an application (2.6) through an application contract
2.18
medium access device
MAD
device with the necessary facilities (hardware and software) to communicate with a customer
medium (2.17)
2.19
organisation
legal entity covering the functions and implied responsibilities of one or more of the following
operational IFM-roles (2.12): application owner, application retailer, product owner, product retailer,
service operator, and collection and forwarding
2.20
pricing rules
rules defining the price and payment/billing relationships to the customer
2.21
product rules
set of usage, pricing, and commercial rules (2.7) defined by the product owner
2.22
product specification
complete specification of functions, data elements, and security scheme according to the product rules
(2.21)
2.23
product template
technical pattern of the product specification (2.22)
Note 1 to entry: The product template is identified by a unique identifier.
2.24
product
instance of a product template (2.23) stored in an application (2.6)
Note 1 to entry: It is identified by a unique identifier and enables the customer to benefit from a service provided
by a service operator.
2.25
role
abstract object performing a set of functions
2.26
security policy
objectives of the IFM to secure the public interests and the assets within the IFM
2.27
set of rules
regulations for achieving IFM policies (2.11) expressed as technical, commercial, security, and legal
requirements and standards relevant only to the IFMS
2.28
trigger
event that causes the execution of a use case (2.30)
2.29
usage rules
rules defining the usage time, the usage area, the personal status, and the type of service
2.30
use case
description of a process by defining a sequence of actions performed by one or more actors (2.2) and by
the system itself
3 Abbreviated terms
IFM Interoperable Fare Management
IFMS Interoperable Fare Management system
MAD Medium Access Device
PP Protection Profile
PT Public Transport
SSS Security SubSystem
TOE Target Of Evaluation
4 Requirements
The purpose of ISO 24014 is to achieve interoperability throughout fare management systems while
making sure that participating companies in public transport remain as commercially free as possible
to design their own implementation in pursuing their own business strategies.
Specific requirements of the IFMS model are as follows.
— A customer shall be able to travel with all participating operators (the seamless journey) using a
single medium.
4 © ISO 2015 – All rights reserved
— There shall be a capability to extract data appropriate to the revenue-sharing and statistical
requirements of the transport operators.
— The same medium may carry additional applications. Conversely, other media may carry the
IFM application.
— The ticketing methods associated with the application shall offer the opportunity to reduce the
current time taken to enter/exit the public transport system and may reduce payment handling
costs significantly.
— The IFMS model shall comply with data protection and financial services laws/regulations (e.g.
privacy).
— The IFMS model shall provide the capability to accommodate new product specifications as required
regardless of those already in existence.
— The IFMS model shall recognize and prevent internal or external fraud attacks.
— The IFMS model shall identify the customer while protecting their privacy as appropriate.
— The IFMS model shall protect the privacy of the customer.
— The IFMS model shall ensure the integrity of exchanged data.
— The IFMS model shall enable the implementation of additional services: loyalty programmes, car
sharing, park and ride, bike and ride, etc.
— The IFMS model shall provide interface definitions between identified functions within public
transport to enable different operator networks to interoperate.
— The IFMS model shall describe interfaces which are essential to enable data-forwarding functions
between different operator networks allowing revenue-sharing agreements to be met.
— The IFMS model shall provide a framework from which commercial agreements may be developed.
— The IFMS model shall be neutral with regard to different technologies which can be deployed [e.g.
contact medium, contactless medium (short range, wide range), independent of access technologies].
— The IFMS model shall be functionally neutral regarding specific transport organization structures.
5 Conceptual framework
The IFMS may be run by a single transport undertaking, a transport authority, an association of public
and private companies, or other groups.
An IFM manager establishes and manages the IFM policies on behalf of the IFMS. These policies are
embedded in the set of rules.
To manage the elements of the IFMS dealt with in this part of ISO 24014, the IFM manager shall appoint
— a security manager, and
— a registrar.
The functions and the responsibilities of the security manager and the registrar can be distributed to
several organisations within an IFM. This may be a necessary condition to allow the cooperation of
existing IFMSs. An example is shown in B.3. The example also shows how a new common set of rules for
the joint IFMS is built upon the existing sets of the cooperating IFMSs.
5.1 Description of IFM-roles
IFM-roles are identified by capitalized initial letters.
Product The Product Owner is responsible for his Products.
Owner
Functions of ownership:
— Specifying pricing, Usage Rules, and Commercial Rules.
Functions of clearing:
— Trip reconstruction
— Product aggregation based on received usage data using Product definition rules;
— Linking of aggregated usage data with acquisition data;
— Preparation of apportionment data based on Product Specification.
Functions of reporting:
— Detailed:
— acquisition data with no link to usage data within the reporting
period;
— usage data with no link to acquisition data within the reporting
period;
— linked aggregated Product data within the reporting period.
— Summary:
— apportionment data and clearing report.
— Total acquisition data.
Product The Product Retailer sells and terminates Products, collects, and refunds
Retailer value to a customer as authorized by a Product Owner.
The Product Retailer is the only financial interface between the customer
and the IFMS related to Products.
Application The Application Retailer sells and terminates Applications, collects, and
Retailer refunds value to a customer as authorized by an Application Owner.
The Application Retailer is the only financial interface between the
customer and the IFMS related to Applications.
Collection The IFM-role of Collection and Forwarding is the facilitation of data
and interchanges of the IFMS. The general functions are data collection and
Forwarding forwarding. They contain at least the following functions:
6 © ISO 2015 – All rights reserved
Functions of collecting
— Receiving Application Template from Application Owner.
— Receiving Product Template from Product Owner.
— Receiving data from Service Operators.
— Receiving data from Product Retailer.
— Receiving data from Application Retailer.
— Receiving data from other Collection and Forwarding functions.
— Receiving security list data from Security Manager.
— Receiving clearing reports from Product Owner.
— Consistency and completeness check of the data collected on a
technical level.
— Receiving the address list of all IFM-roles in the IFM from the Registrar.
Functions of forwarding
— Forwarding “Not On Us” data to other Collection and Forwarding
functions.
— Recording “Not On Us” data.
— Forwarding data with a corrupt destination address to the Security
Manager.
— Forwarding “On Us” data to the Product Owner for clearing and
reporting.
— Forwarding clearing reports, Application Template, Product Template,
and security list data to the Product Retailer and Service Operator.
— Forwarding Application Templates and security list data to the
Application Retailer and Service Operator.
NOTE The “ON US and NOT ON US” concept is as follows.
— A specific Collection and Forwarding function is to collect data from
one IFM-role and forward it to other IFM-roles.
— Logically, there may be several COLLECTION AND FORWARDING
functions within the IFM.
— IFM-roles may be linked to different COLLECTION AND FORWARDING
functions, but each IFM-role can only be linked to one.
— The concept of “ON US and NOT ON US” addresses this connectivity
functionality: Data held by a specific COLLECTION AND FORWARDING
function is either “ON US” or “NOT ON US” data.
— Data collected by a specific COLLECTION AND FORWARDING function
addressed to IFM-roles directly linked to this COLLECTION AND
FORWARDING function is termed “ON US” data.
— Data collected by a specific COLLECTION AND FORWARDING
function addressed to IFM-roles not linked to this COLLECTION AND
FORWARDING function is termed “NOT ON US” data.
Service The Service Operator provides a service to the customer against the use
Operator of a Product.
Application The Application Owner holds the Application contract for the use of the
Owner Application with the customer.
Customer Subject to commercial agreements, Customer Service may provide
Service “helpline” and any similar facilities including replacement of stolen and
damaged Customer Medium and consequent Product reinstalling.
Customer The Customer holds an Application and acquires Products in order to use
the public transport services.
Security The Security Manager is responsible for establishing and coordinating the
Manager Security Policy and for
— certification of Organisations, Application Templates, Components,
and Product Templates,
— auditing of Organisations, Application Templates/Applications,
Components, and Product Templates/Products,
— monitoring the system, and
— operation of the security of the IFMS, e.g. key management.
Registrar After the certification, the Registrar issues unique registration codes for
Organisations, Components, Application Templates, and Product
Templates. The Registrar function also issues unique identifiers or rules
for generating unique identifiers for the Applications, Products, and
messages.
5.2 Basic framework of the generic IFM functional model
The links between the operational IFM-roles of the IFMS are illustrated in Figure 1. These links
represent information flows. Optional links and IFM-roles are drawn in dotted lines. It is assumed
that the customer already has a medium or is provided with one by the application retailer, therefore,
the model considers only application and product issues. Within an IFMS, there may be several
organisations performing the functions of the IFM-roles.
Figure 1 — Links between operational IFM-roles within the IFMS
An IFM manager establishes and manages the IFM policies on behalf of the IFM. These policies are
embedded in the set of rules. The IFM manager will have relationships with media issuers. The customer
will have a relationship with the issuer of the customer medium they hold. Also, the application owner
will have relationships with media issuers.
8 © ISO 2015 – All rights reserved
To manage the elements, the IFM functional model includes two management IFM-roles:
— the registrar — the IFM-role for the identification of any organization, component, application
template and application, product template, and product involved in the IFMS;
— the security manager — the supporting IFM-role responsible for the secure operation of the IFMS.
Figure 2 shows the two domains of IFM-roles of the IFM and the connection between them.
The interactions between IFM-roles are described in detail in Clause 6.
Figure 2 — Two IFM domains (operational and management IFM-roles)
6 Use Case description for the IFM functional model
This clause describes Use Cases for the operation of an IFMS. The set of Use Cases described herein
provides a toolbox for the implementation of an IFMS. Where processes described within a Use Case are
implemented within an IFM, the Use Case is mandatory.
However, Use Cases may be adapted with modification depending on ways of management of
Applications and Products. An/A Application/Product can be managed either in a media centric or
back-office centric way. Any variation or combination between these two approaches may be possible.
Media centric management:
Main processes (e.g. fare calculation, billing) of management of Application and Product are done
between a Medium and MAD.
Back-office centric management:
Main processes of management of Application and/or Product are done in the back-office.
The following Use Cases describe functional aspects of the IFM. Contractual matters are outside the
scope of this part of ISO 24014, but a prerequisite to implementation.
All Actors in the Use Cases are written in UPPER CASE characters.
6.1 Certification
Each object to be brought into the IFM should meet the IFM requirements. The proof of compliance is
given by checking the object against a Set of Rules. This process is called certification.
Within the IFM, the certification certifies
— Organisations,
— security-related Components,
— Application Specification and Template, and
— Product Specification and Template.
The Security Manager is responsible for the certification.
6.1.1 Certification of Organization
Use Case name Certification of Organization
Outline Each Organization which wants to participate in the IFM shall agree to abide by the
Set of Rules.
Triggered by ORGANIZATION
Actor(s) SECURITY MANAGER
ORGANIZATION
Use Case description If the SECURITY MANAGER confirms that the Organization agrees to abide by the Set
of Rules,
— the ORGANIZATION will be certified,
— else the ORGANIZATION will not be certified.
6.1.2 Certification of Components
Use Case name Certification of Components
Outline Each Component to be brought into the IFM shall meet the IFM requirements. Proof
of this is given by checking this Component against a Set of Rules.
Triggered by COMPONENT PROVIDER
Actor(s) SECURITY MANAGER
COMPONENT PROVIDER
Use Case description The SECURITY MANAGER checks the Component against the Set of Rules.
If the Component is compliant with the Set of Rules,
— the Component will be certified,
— else the Component will not be certified.
6.1.3 Certification of Application Specification and Template
Use Case name Certification of Application Specification and Template
Outline Each Application Specification and Template to be brought into the IFMS shall meet
the IFM requirements. Proof of this is given by checking this Application
Specification and Template against a Set of Rules.
Triggered by APPLICATION OWNER
Actor(s) SECURITY MANAGER
APPLICATION OWNER
10 © ISO 2015 – All rights reserved
Use Case name Certification of Application Specification and Template
Use Case description The SECURITY MANAGER checks the Application Specification and Template against
the Set of Rules.
If the Application Specification and Template is compliant with the Set of Rules,
— the Application Specification and Template will be certified,
— else the Application Specification and Template will not be certified.
6.1.4 Certification of Product Specification and Template
Use Case name Certification of Product Specification and Template
Outline Each Product Specification and Template to be brought into the IFM shall meet the
IFM requirements. Proof of this is given by checking this Product Specification and
Template against a Set of Rules.
Triggered by PRODUCT OWNER
Actor(s) SECURITY MANAGER
PRODUCT OWNER
Use Case description The SECURITY MANAGER checks the Product Specification and Template against the
Set of Rules.
If the Product Specification and Template is compliant with the Set of Rules,
— the Product Specification and Template will be certified,
— else the Product Specification and Template will not be certified.
6.2 Registration
Registration is necessary to ensure that each instance of an object is unique within the IFM. This is
guaranteed by a unique identifier. The process of managing these identifiers is called registration.
Objects and instances of objects within the IFM which have to be registered are
— Organisations,
— Components,
— Application Template and Application, and
— Product Template and Product.
The Registrar of the IFM is responsible for the registration process.
6.2.1 Registration of Organization
Use Case name Registration of Organization
Outline A unique identification is given to each Organization.
Triggered by ORGANIZATION
Actor(s) REGISTRAR
ORGANIZATION
Use Case description The ORGANIZATION sends the Organization certification to the REGISTRAR.
The REGISTRAR returns a unique Organization identifier to the ORGANIZATION.
6.2.2 Registration of Component
Use Case name Registration of Component
Outline A unique identification is given to each Component.
Triggered by COMPONENT PROVIDER
Actor(s) REGISTRAR
COMPONENT PROVIDER
Use Case description The Component certification is sent to the REGISTRAR.
The REGISTRAR returns a unique Component identifier to the Organization which
asked for registration.
6.2.3 Registration of Application Template
Use Case name Registration of Application Template
Outline A unique identification is given to each Application Template.
Triggered by APPLICATION OWNER
Actor(s) REGISTRAR
APPLICATION OWNER
Use Case description The APPLICATION OWNER sends the Application Template certification to the
REGISTRAR.
The REGISTRAR returns a unique Application Template identifier to the
APPLICATION OWNER.
6.2.4 Registration of Application
Use Case name Registration of Application
Outline A unique identification is given to each Application.
Triggered by APPLICATION RETAILER
Actor(s) REGISTRAR
APPLICATION RETAILER
Use Case description a) The APPLICATION OWNER sends the Application Template identification to the
REGISTRAR and asks for an Application identification. The REGISTRAR sends a
unique Application identifier to the APPLICATION OWNER. This can be done for a
single identifier as well as for a batch of identifiers.
b) The APPLICATION RETAILER sends the Application Template identification to the
APPLICATION OWNER throughthrough the COLLECTION AND FORWARDING and
asks for an Application identification. The APPLICATION OWNER sends the unique
Application identifier throughthrough the COLLECTION AND FORWARDING to the
APPLICATION RETAILER.
The processes described in a) and b) could happen at any time in any order.
6.2.5 Registration of Product Template
Use Case name Registration of Product Template
Outline A unique identification is given to each Product Template.
Triggered by PRODUCT OWNER
Actor(s) REGISTRAR
PRODUCT OWNER
12 © ISO 2015 – All rights reserved
Use Case name Registration of Product Template
Use Case description The PRODUCT OWNER sends the Product Specification certification to the
REGISTRAR.
The REGISTRAR returns a unique Product Template identifier to the PRODUCT
OWNER.
6.2.6 Registration of Product
Use Case name Registration of Product
Outline A unique identification is given to each Product.
Triggered by PRODUCT RETAILER
Actor(s) REGISTRAR
PRODUCT RETAILER
Use Case description a) The PRODUCT OWNER sends the Product Template identification to the
REGISTRAR and asks for a Product identification. The REGISTRAR sends a unique
Product identifier to the PRODUCT OWNER. This can be done for a single identifier
as well as for a batch of identifiers.
b) The PRODUCT RETAILER sends the Product Template identification to the
PRODUCT OWNER throughthrough the COLLECTION AND FORWARDING and asks
for a Product identification. The PRODUCT OWNER sends the unique Product
identifier throughthrough the COLLECTION AND FORWARDING to the PRODUCT
RETAILER.
The processes described in a) and b) could happen at any time in any order.
6.3 Management of Application
The Management of Application comprises
— dissemination of Application Templates,
— acquisition of Applications,
— termination of Application Templates, and
— termination of Applications.
Only certified and registered Application Templates shall be disseminated.
Updating of Application consists of terminating an Application and acquiring a new Application.
6.3.1 Dissemination of Application Template
Use Case name Dissemination of an Application Template
Outline Dissemination of an Application Template enables the authorized Retailer to sell an
Application and an authorized Service Operator to access this Application.
Triggered by APPLICATION OWNER
Actor(s) APPLICATION RETAILER
COLLECTION AND FORWARDING
SERVICE OPERATOR
APPLICATION OWNER
Use Case name Dissemination of an Application Template
Use Case description Dissemination of Application Template comprises
— distribution of registered Application Template by APPLICATION OWNER to the
APPLICATION RETAILER throughthrough the COLLECTION AND FORWARDING, and
— distribution of registered Application Template by APPLICATION OWNER to the
SERVICE OPERATOR through the COLLECTION AND FORWARDING.
6.3.2 Acquisition of Application
Use Case name Acquisition of Application
Outline An Application is loaded on the Customer Mediu
...
NORME ISO
INTERNATIONALE 24014-1
Deuxième édition
2015-10-15
Transport public — Système de
gestion tarifaire interopérable —
Partie 1:
Architecture
Public transport — Interoperable fare management system —
Part 1: Architecture
Numéro de référence
©
ISO 2015
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2015, Publié en Suisse
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni utilisée
sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie, l’affichage sur
l’internet ou sur un Intranet, sans autorisation écrite préalable. Les demandes d’autorisation peuvent être adressées à l’ISO à
l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2015 – Tous droits réservés
Sommaire Page
Avant-propos .v
Introduction .vi
1 Domaine d’application . 1
2 Termes et définitions . 2
3 Abréviations . 4
4 Exigences . 4
5 Cadre conceptuel . 5
5.1 Description des rôles IFM . 6
5.2 Cadre de base du modèle fonctionnel IFM générique . 8
6 Description des cas d’utilisation du modèle fonctionnel IFM . 9
6.1 Certification .10
6.1.1 Certification des Entités juridiques .10
6.1.2 Certification des composants .10
6.1.3 Certification de la Spécification et du Masque d’application .11
6.1.4 Certification de la Spécification et de la Structure de produit.11
6.2 Enregistrement .11
6.2.1 Enregistrement d’une Entité juridique .11
6.2.2 Enregistrement d’un Composant .12
6.2.3 Enregistrement d’un Masque d’application .12
6.2.4 Enregistrement d’une Application .12
6.2.5 Enregistrement d’une Structure de produit .12
6.2.6 Enregistrement d’un Produit .13
6.3 Gestion d’Application .13
6.3.1 Diffusion d’un Masque d’application .13
6.3.2 Acquisition d’une Application .14
6.3.3 Résiliation d’un Masque d’application .14
6.3.4 Résiliation d’une Application .15
6.4 Gestion de Produit .15
6.4.1 Diffusion d’une Structure de produit .16
6.4.2 Résiliation d’une Structure de produit .16
6.4.3 Gestion d’une Liste d’actions .17
6.4.4 Acquisition d’un Produit .17
6.4.5 Modification des paramètres d’un Produit .17
6.4.6 Résiliation d’un Produit .18
6.4.7 Utilisation et contrôle d’un Produit .18
6.4.8 Collecte des données .19
6.4.9 Transfert des données .20
6.4.10 Etablissement et diffusion des états de compensation .20
6.5 Gestion de la sécurité .20
6.5.1 Surveillance des processus et du cycle de vie des données du système IFM .21
6.5.2 Gestion des clés de sécurité IFM .21
6.5.3 Gestion des listes de sécurité .21
6.6 Gestion du Service après-vente (optionnel) .23
7 Identification des interfaces système .24
8 Identification .24
8.1 Généralités .24
8.2 Modèle de numérotation .24
8.3 Prérequis .24
9 Sécurité dans les systèmes IFM .25
9.1 Protection des intérêts du public .25
9.2 Actifs à protéger .26
9.3 Exigences de sécurité IFM générales .26
Annexe A (informative) Flux d’informations dans le système IFM .28
Annexe B (informative) Exemples de mise en œuvre .38
Annexe C (informative) Liste de correspondance des termes entre la présente partie de
l’ISO 24014 (IFMSA) et l’APTA (UTFS) .49
Annexe D (informative) Exemple de processus de la liste d’actions.50
Annexe E (informative) Périmètre de sécurité, menaces et profils de protection .55
Annexe F (informative) Gestion centrée sur le support et gestion centrée sur le back-office .59
Bibliographie .61
iv © ISO 2015 – Tous droits réservés
Avant-propos
L’ISO/TS 19299 a été préparé par le comité européen de standardisation (CEN) en collaboration avec
l’ISO/TC 204, Intelligent transport systems, en accord avec les accords de coopération techniques entre
l’ISO et le CEN (accord de Vienne).
L’ISO (Organisation internationale de normalisation) est une fédération mondiale d’organismes
nationaux de normalisation (comités membres de l’ISO). L’élaboration des Normes internationales est
en général confiée aux comités techniques de l’ISO. Chaque comité membre intéressé par une étude
a le droit de faire partie du comité technique créé à cet effet. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l’ISO participent également aux travaux.
L’ISO collabore étroitement avec la Commission électrotechnique internationale (IEC) en ce qui
concerne la normalisation électrotechnique.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives
ISO/IEC, Partie 2.
La tâche principale des comités techniques est d’élaborer les Normes internationales. Les projets de
Normes internationales adoptés par les comités techniques sont soumis aux comités membres pour
vote. Leur publication comme Normes internationales requiert l’approbation de 75 % au moins des
comités membres votants.
L’attention est appelée sur le fait que certains des éléments du présent document peuvent faire l’objet de
droits de propriété intellectuelle ou de droits analogues. L’ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence.
Pour une explication sur la signification des termes et expressions spécifiques de l’ISO en lien avec
l’évaluation de la conformité, et de l’information sur l’adhérence de l’ISO aux principes WTO dans le TBT
(Technical Barriers to Trade), voir l’URL suivant:
http://www.iso.org/iso/home/standards_development/resources-for-technical-work/foreword.htm
L’ISO 24014-1 a été élaborée par le Comité Européen de Normalisation (CEN) en collaboration avec le
comité technique ISO/TC 204, Systèmes intelligents de transport, sous accord de la coopération technique
entre l’ISO et le CEN (Accord de Vienne).
Cette deuxième édition annule et remplace la première édition (ISO 24014-1:2007), qui fait l’objet d’une
révision technique.
L’ISO 24014 comprend les parties suivantes, présentées sous le titre général Transport public — Système
de gestion tarifaire interopérable:
— Partie 1: Architecture
— Partie 2: Pratiques commerciales
— Partie 3: Support multi applicatif
Introduction
Le système billettique (FM, Fare Management) englobe tous les processus conçus pour gérer la
distribution et l’utilisation de produits tarifaires dans un environnement de transport public.
Le système billettique est dit interopérable (IFM, Interoperable Fare Management) lorsqu’il permet
au client d’utiliser un support électronique portable (par exemple une carte à puce à contact / sans
contact) avec des équipements compatibles (par exemple aux arrêts, aux équipements de distribution,
aux points d’accès aux quais ou à bord des véhicules). Les concepts IFM peuvent aussi être utilisés dans
les systèmes billettiques qui n’utilisent pas de supports électroniques.
Les avantages potentiels pour le client comprennent la réduction des files d’attente, des tarifs spéciaux
ou combinés, un support unique pour plusieurs applications, des programmes de fidélisation et un
voyage sans couture.
L’interopérabilité des systèmes billettiques bénéficie aussi aux opérateurs et autres entités concernées.
Elle nécessite cependant une architecture globale qui définit les fonctionnalités, les acteurs concernés,
leurs rôles, leurs relations et leurs interfaces.
L’interopérabilité exige également la définition de principes de sécurité pour protéger la vie privée,
l’intégrité et la confidentialité des données entre les acteurs pour garantir l’exactitude et la sécurité des flux
de données au sein du système billettique interopérable (IFMS, Interoperable Fare Management System).
L’architecture globale est l’objet de la présente partie de l’ISO 24014 qui reconnaît le besoin d’accords
légaux et commerciaux entre les membres d’un système billettique interopérable, mais ne précise pas leur
forme. Les spécifications techniques des Composants et notamment les normes applicables aux Supports
client (par exemple les cartes à puce) ne sont pas couvertes par le présent document.
Il n’existe pas qu’un seul système billettique interopérable. Les opérateurs individuellement ou regroupés
en consortiums, les autorités publiques et les entreprises privées peuvent gérer et/ou participer à
plusieurs systèmes billettiques interopérables. Un système billettique interopérable peut dépasser
les frontières nationales et peut être combiné à d’autres systèmes. Les mises en œuvre de systèmes
billettiques interopérables exigent des fonctionnalités de sécurité et d’enregistrement. La présente partie
de l’ISO 24014 prévoit la distribution de ces fonctions pour permettre la coordination/convergence des
systèmes billettiques interopérables existants afin qu’ils fonctionnent ensemble.
La présente partie de l’ISO 24014 entend apporter trois principaux avantages.
a) Elle propose un cadre général de mise en œuvre d’un système billettique interopérable avec le
minimum de complexité.
b) Elle a pour objectif de raccourcir les délais et de diminuer les coûts d’acquisition de systèmes
billettiques interopérables en facilitant la compréhension de l’objet du contrat à la fois pour
les fournisseurs et pour les acheteurs. Fonder les achats sur une norme ouverte réduit les coûts
en évitant l’onéreux développement de systèmes sur mesure et en permettant des sources
d’approvisionnement alternatives.
c) Elle a pour but de simplifier l’interopérabilité entre les systèmes billettiques dans l’intérêt de toutes
les parties prenantes.
Les travaux correspondants ont bénéficié des travaux réalisés en matière d’architecture des systèmes
de péage électronique (CEN/TC 278/WG 1) et dans d’autres domaines tels que:
— ISO/TS 14904, Road transport and traffic telematics — Electronic fee collection (EFC) — Interface
specification for clearing between operators
— ISO/TS 17573, Road Transport and Traffic Telematics — Electronic Fee Collection (EFC) — Systems
architecture for vehicle related transport services
les normes internationales existantes en matière de sécurité des données.
vi © ISO 2015 – Tous droits réservés
NORME INTERNATIONALE ISO 24014-1:2015(F)
Transport public — Système de gestion tarifaire
interopérable —
Partie 1:
Architecture
1 Domaine d’application
La présente partie de l’ISO 24014 fournit les bases pour développer des systèmes billettiques
interopérables (IFMS, Interoperable Fare Management System) multi-opérateurs/multi-services pour le
transport public (y compris les métros), tant à l’échelle nationale qu’internationale.
La présente partie de l’ISO 24014 s’applique aux organismes de transport public et aux services
connexes qui conviennent que leurs systèmes doivent être interopérables.
Même si la présente partie de l’ISO 24014 n’implique pas qu’il soit nécessaire de modifier les systèmes
billettiques interopérables existants, elle s’applique, dans toute la mesure du possible, à leurs
extensions futures.
La présente partie de l’ISO 24014 couvre la définition d’un cadre conceptuel, qui est indépendante de la
mise en œuvre organisationnelle et physique. Toute référence à la mise en œuvre organisationnelle et
physique dans la présente partie de l’ISO 24014 est purement informative.
L’objectif de la présente partie de l’ISO 24014 est de définir une architecture fonctionnelle de référence
pour les systèmes IFMS et d’identifier les exigences de nature à assurer l’interopérabilité entre plusieurs
acteurs dans le contexte de l’utilisation de titres de transport électroniques.
Le système IFM comprend l’ensemble des fonctions du processus de gestion des titres de transport, tels
que:
— Gestion d’Application
— Gestion de Produit
— Gestion de la sécurité
— Certification, enregistrement et identification
La présente partie de l’ISO 24014 décrit les principaux éléments suivants:
— Identification des différents rôles IFM en relation avec le système billettique global
— Modèle générique de système IFM décrivant l’architecture logique et fonctionnelle ainsi que les
interfaces au sein du système et avec d’autres systèmes IFM.
— Cas d’utilisation décrivant les interactions et flux de données entre les différents rôles IFM fonctionnels
— Exigences relatives à la sécurité
La présente partie de l’ISO 24014 ne tient pas compte des éléments suivants:
— Support physique et sa gestion
— Aspects techniques de l’interface entre le Support et le Terminal billettique
— Echanges de données entre le Support et le Terminal billettique
NOTE Les échanges de données entre le Support et le Terminal billettique sont traités par d’autres
comités de normalisation.
— Aspects financiers des systèmes billettiques (par exemple le paiement par le client, les moyens de
paiement, le règlement, l’imputation, le rapprochement)
2 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent.
2.1
liste d’actions [anglais: action list]
liste d’éléments relatifs à des Applications IFM ou à des Produits, téléchargée (2.24) vers des Terminaux
billettiques (2.18) (MAD) et déclenchée par le Terminal billettique si et lorsque ce terminal rencontre
une Application ou un Produit IFM référencé dans la liste
2.2
acteur [anglais: actor]
personne, Entité juridique ou autre (sous-)système assumant un ensemble cohérent de fonctions
lorsqu’il interagit avec le système IFM dans un Cas d’utilisation particulier
2.3
règles relatives à une application [anglais: application rules]
exigences fonctionnelles du Propriétaire de l’application
2.4
spécification d’application [anglais: application specification]
spécification de fonctions, d’éléments de données et d’un plan de sécurité en correspondance avec la
Convention d’application (2.3)
2.5
masque d’application [anglais: application template]
schéma technique exécutable de la Spécification d’application (2.4)
2.6
application
masque d’application (2.5) mis en œuvre et initialisé
Note 1 à l’article: L’Application a un identifiant unique.
Note 2 à l’article: L’Application contient des Produits (2.24), ainsi que d’autres informations Client optionnelles
(détails Client, préférences Client).
Note 3 à l’article: L’Application peut être entièrement installée sur un Support client ou répartie sur le Support
client et dans les back-offices du système IFM
2.7
règles commerciales [anglais: commercial rules]
règles de partage des recettes et fixation des commissions dans le système IFM
2.8
composant [anglais: component]
élément matériel et/ou logiciel exécutant une ou plusieurs fonctions dans le système IFM
2.9
fournisseur du composant [anglais: component provider]
entité qui veut faire utiliser un Composant (2.8) dans le système IFM
2.10
modèle fonctionnel IFM [anglais: IFM functional model]
modèle servant à définir les fonctions et interactions des rôles IFM (2.12)
2 © ISO 2015 – Tous droits réservés
2.11
politique IFM [anglais: IFM policies]
objectifs commerciaux, techniques, de sécurité et de confidentialité du système IFM
2.12
rôle IFM [anglais: IFM-role]
concept abstrait réalisant un ensemble de fonctions dans un modèle fonctionnel IFM (2.10)
2.13
interopérabilité billettique [anglais: interoperable fare management]
système englobant toutes les fonctions impliquées dans le processus de gestion tarifaire telles
que la gestion d’application, de produit (2.24), de sécurité et de certification, d’enregistrement et
d’identification qui permettent aux Clients de se déplacer sur les réseaux des Opérateurs de transport
participants avec un seul Support électronique portable.
2.14
système billettique interopérable [anglais: interoperable fare management system]
système comprenant l’ensemble des éléments techniques, commerciaux, sécuritaires et légaux qui
permettent une gestion tarifaire interopérable (2.13)
2.15
support [anglais: medium]
support physique des Applications (2.6)
2.16
message
ensemble de données échangées entre deux rôles IFM (2.12)
2.17
support client [anglais: customer medium]
support initialisé (2.15) porteur d’une Application (2.6) sur la base d’un contrat d’application
2.18
terminal billettique
MAD (Medium Access Device)
appareil équipé des ressources (matérielles et logicielles) nécessaires pour communiquer avec un
Support client
2.19
entité juridique [anglais: organisation]
personne morale assurant les fonctions et les responsabilités correspondantes d’un ou de plusieurs des
rôles IFM opérationnels suivants: Propriétaire de l’application, Distributeur de l’application, Propriétaire
du produit, Distributeur du produit, Opérateur de transport et Agent de collecte et de diffusion
2.20
règles tarifaires [anglais: pricing rules]
définition des prix et des modes de paiement/facturation avec le Client
2.21
règles relatives à un produit [anglais: product rules]
ensemble de Règles tarifaires, commerciales (2.7) et d’utilisation définies par le Propriétaire du produit
2.22
spécification de produit [anglais: product specification]
spécification complète de fonctions, d’éléments de données et d’un plan de sécurité en correspondance
avec les Règles de produit (2.21)
2.23
structure de produit [anglais: product template]
matrice technique de la Spécification de produit (2.22)
Note 1 à l’article: La Structure de produit a un identifiant unique.
2.24
produit [anglais: product]
instance d’une Structure de produit (2.23) stockée dans une Application (2.6)
Note 1 à l’article: Le Produit a un identifiant unique. Il permet au Client de bénéficier d’un service fourni par un
Opérateur de transport.
2.25
rôle [anglais: role]
concept abstrait réalisant un ensemble de fonctions
2.26
politique de sécurité [anglais: security policy]
objectifs du système IFM pour sécuriser les intérêts publics et les actifs au sein du système IFM
2.27
convention d’interopérabilité [anglais: set of rules]
ensemble de règles permettant de réaliser la Politique IFM (2.11), exprimée sous la forme
d’exigences techniques, commerciales, sécuritaires et légales et dans des normes exclusivement
spécifiques au système IFM
2.28
déclencheur [anglais: trigger]
événement qui entraîne l’exécution d’un Cas d’utilisation (2.30)
2.29
règles d’utilisation [anglais: usage rules]
règles relatives à l’utilisation dans le temps, à l’utilisation dans l’espace, à l’état du personnel et au
type de service
2.30
cas d’application [anglais: use case]
description d’un processus en définissant une séquence d’actions réalisées par un ou plusieurs Acteurs
(2.2) et par le système lui-même
3 Abréviations
IFM (Interoperable Fare Management) gestion tarifaire interopérable
IFMS (Interoperable Fare Management System) système billettique interopérable
PP (Protection Profile) profil de protection
TP transport public
SSS (Security Sub System) sous-système de sécurité
TOE (Target of Evaluation) cible d’évaluation
4 Exigences
L’objet de l’ISO 24014 est de parvenir à l’interopérabilité de l’ensemble des systèmes billettiques tout
en garantissant autant que possible la liberté économique des entreprises impliquées dans le transport
public en matière de mise en œuvre au service de leurs stratégies commerciales.
4 © ISO 2015 – Tous droits réservés
Les exigences propres au modèle IFMS sont les suivantes:
— Un Client doit pouvoir se déplacer sur les réseaux de tous les opérateurs avec un seul Support (le
voyage sans couture).
— Il doit exister une fonction permettant d’isoler les données nécessaires au partage des recettes et
aux exigences statistiques de chaque Opérateur de transport.
— Le même Support peut porter des Applications supplémentaires; à l’inverse, d’autres supports
peuvent porter l’Application IFM.
— Les méthodes de billettique associées à l’Application doivent permettre de réduire le temps nécessaire
pour entrer/sortir du système de transport public et peuvent réduire de manière significative les
coûts de traitement de paiement
— Le modèle IFMS doit se conformer à la législation/réglementation en matière de protection de
données et de services financiers (par exemple la protection des données à caractère personnel).
— Le modèle IFMS doit pouvoir prendre en charge de nouvelles Spécifications de produits, si nécessaire,
indépendamment de celles déjà existantes.
— Le modèle IFMS doit détecter et prévenir les actes frauduleux et malveillants internes ou externes.
— Le modèle IFMS doit identifier le Client tout en protégeant sa vie privée comme approprié.
— Le modèle IFMS doit protéger la vie privée du Client.
— Le modèle IFMS doit assurer l’intégrité des données échangées.
— Le modèle IFMS doit permettre l’introduction de prestations additionnelles: programmes de fidélité,
covoiturage, parcs de rabattement, systèmes de vélo, etc.
— Le modèle IFMS doit fournir des définitions d’interfaces entre des fonctions identifiées dans
l’écosystème du transport public permettant l’interopérabilité des réseaux de différents opérateurs.
— Le modèle IFMS doit décrire les interfaces nécessaires aux fonctions de transfert de données entre
les réseaux de différents opérateurs afin de permettre le respect des accords de partage des recettes.
— Le modèle IFMS doit fournir un cadre à partir duquel des règles commerciales peuvent être développées.
— Le modèle IFMS doit être neutre vis-à-vis des différentes technologies qui peuvent être déployées
(par exemple, Support à contact, Support sans contact [courte ou longue portée] - indépendamment
des technologies d’accès).
— Le modèle IFMS doit être fonctionnellement neutre vis-à-vis de la nature des Entités juridiques
de transport.
5 Cadre conceptuel
Le système IFM peut être exploité par une seule entreprise de transport, une autorité de transport, une
association d’entreprises publiques et privées, ou d’autres types de groupements.
Un Responsable IFM établit et gère la Politique IFM pour le compte du système IFM. Ces politiques sont
formalisées dans la Convention d’interopérabilité.
Pour gérer les éléments du système IFM traités dans la présente partie de l’ISO 24014, le Responsable IFM
doit désigner
— un Responsable sécurité, et
— un Office d’enregistrement.
Les fonctions et responsabilités du Responsable sécurité et de l’Office d’enregistrement peuvent être
distribuées à plusieurs Entités juridiques au sein d’un système IFM. Cela peut être une condition
nécessaire pour permettre la coopération des systèmes billettiques interopérables existants.
Un exemple est donné en B.3. L’exemple montre également comment une nouvelle Convention
d’interopérabilité commune pour le système IFM joint est conçue à partir des ensembles existants des
systèmes IFMS membres.
5.1 Description des rôles IFM
Les rôles IFM sont identifiés par la première lettre de leur nom en majuscules.
Propriétaire du Le Propriétaire du produit est responsable de ses Produits.
produit [anglais:
Fonctions du propriétaire:
product owner]
— Définition des règles tarifaires, commerciales et d’utilisation
Fonctions de compensation:
— Reconstitution des voyages - consolidation Produit sur la base des données d’utilisation
reçues au moyen des règles de définition du Produit
— Etablissement du lien entre les données d’utilisation consolidées et les données d’achat
— Préparation des données d’imputation sur la base de la Spécification du Produit
Fonction de compte-rendu:
— Détaillé:
— Données d’achat sans lien avec les données d’utilisation au cours de la période de
référence
— Données d’utilisation sans lien avec les données d’achat au cours de la période de
référence
— Données d’utilisation du Produit consolidées et liées au cours de la période de référence
— Résumé:
— Données d’imputation et état de compensation
— Données d’achat complètes
Distributeur du Le Distributeur du produit vend et résilie les Produits, perçoit le paiement et rembourse le
produit [anglais: Client s’il y est autorisé par le Propriétaire du produit.
product retailer]
Le Distributeur du produit est la seule interface financière entre le Client et le système IFM
pour ce qui concerne les Produits.
Distributeur de Le Distributeur de l’application vend et résilie les Applications, perçoit le paiement et rem-
l’application [anglais:b ourse le Client s’il y est autorisé par le Propriétaire de l’application.
application retailer]
Le Distributeur de l’application est la seule interface financière entre le Client et le système
IFM pour ce qui concerne les Applications.
6 © ISO 2015 – Tous droits réservés
Agent de collecte et La fonction IFM Agent de collecte et de diffusion recouvre les échanges de données du sys-
de diffusion [anglais: tème IFM. Les fonctions générales sont la collecte et le transfert des données. Cette fonction
collection and couvre au minimum les cas suivants:
forwarding]
Fonction de collecte:
— Réception du Masque d’application envoyé par le Propriétaire de l’application
— Réception de la Structure de produit envoyée par le Propriétaire du produit
— Réception des données envoyées par les Opérateurs de transport
— Réception des données envoyées par le Distributeur du produit
— Réception des données envoyées par le Distributeur de l’application
— Réception des données envoyées par d’autres fonctions Agent de collecte et de diffusion
— Réception des données de la liste de sécurité envoyées par le Responsable sécurité
— Réception des états de compensation envoyés par le Propriétaire du produit
— Contrôle technique de la cohérence et de l’exhaustivité des données collectées au niveau
technique
— Réception de la liste des adresses de tous les rôles IFM envoyée par l’Office d’enregistrement
Fonctions de transfert:
— Transfert des données «Externes» aux autres fonctions Agent de collecte et de diffusion
— Enregistrement des données «Externes»
— Transfert au Responsable sécurité des données dont une adresse de destination est cor-
rompue
— Transfert des données «internes» au Propriétaire du produit pour compensation et reporting
— Transfert des états de compensation, du Masque d’application et de la Structure de pro-
duit ainsi que des données de la liste de sécurité au Distributeur du produit et à l’Opérateur
de transport
— Transfert des Masques d’applications et des données de la liste de sécurité au Distributeur
de l’application et à l’Opérateur de transport
NOTE Les concepts de données «internes» et «externes» s’expliquent comme suit.
— La fonction Agent de collecte et de diffusion vise spécifiquement à collecter les données
d’un rôle IFM et à les transférer à d’autres rôles IFM.
— Dans l’absolu, le système IFM peut comporter plusieurs fonctions AGENT DE COLLECTE
ET DE DIFFUSION.
Agent de collecte et — Les rôles IFM peuvent être reliés à des fonctions AGENT DE COLLECTE ET DE DIFFUSION
de diffusion [anglais: différentes, mais chaque rôle IFM ne peut être relié qu’à un seul AGENT DE COLLECTE ET DE
collection and DIFFUSION.
forwarding]
— Les concepts de données «INTERNES» et «EXTERNES» reflètent cette fonction de connec-
tivité: Les données détenues par une fonction AGENT DE COLLECTE ET DE DIFFUSION sont
soit «INTERNES» soit «EXTERNES».
— Les données collectées par une fonction AGENT DE COLLECTE ET DE DIFFUSION spécifique
adressée à des rôles IFM étant directement liés à elle sont appelées données «INTERNES».
— Les données collectées par une fonction AGENT DE COLLECTE ET DE DIFFUSION spé-
cifique adressée à des rôles IFM n’étant pas liés à elle sont appelées données «EXTERNES».
Opérateur de trans- L’Opérateur de transport fournit une prestation de service au client en contrepartie de l’uti-
port [anglais: service lisation d’un Produit.
operator]
Propriétaire de Le Propriétaire de l’application est lié au client par un contrat d’application qui régit l’utili-
l’application [anglais:s ation de l’Application.
application owner]
Service après-vente Dans le cadre d’accords commerciaux, le Service après-vente peut fournir une «assistance»
[anglais: customer ainsi que des services similaires, comme le remplacement d’un Support client volé et endom-
service] magé et la reconstitution des Produits qui en résulte.
Client [anglais: cus- Le Client détient une Application et achète des Produits lui permettant d’utiliser les services
tomer] de transport public.
Responsable sécu- Le Responsable sécurité est chargé d’établir et de coordonner la Politique de sécurité ainsi que:
rité [anglais: secu-
— la certification des Entités juridiques, des Masques d’applications, des Composants et des
rity manager]
Structures de produits;
— l’audit des Entités juridiques, des Masques d’applications/Applications, des Composants
et des Structures de produits/Produits;
— la surveillance du système;
— l’exploitation opérationnelle de la sécurité du système IFM, par exemple la gestion des clés.
Office d’enregis- Après la certification, l’Office d’enregistrement émet des codes d’enregistrement uniques
trement [anglais: pour les Entités juridiques, les Composants, les Masques d’applications et les Structures de
registrar] produits. Il émet également des identifiants uniques ou des règles de génération d’identifiants
uniques pour les Applications, les Produits et les messages.
5.2 Cadre de base du modèle fonctionnel IFM générique
Les liens entre les rôles IFMS opérationnels du système IFM sont décrits dans la Figure 1. Les liens
représentent des flux d’information. Les liens et les rôles IFM facultatifs sont représentés en lignes
pointillées. On suppose que le Client dispose déjà d’un Support ou que le Distributeur de l’application
lui en fournit un; par conséquent, le modèle tient uniquement compte des questions liées à l’Application
et au Produit. Dans un système IFM, les fonctions des rôles IFM peuvent être assurées par plusieurs
Entités juridiques.
Figure 1 — Liens entre les rôles IFM fonctionnels au sein du système IFM
Un Responsable IFM établit et gère la Politique IFM pour le compte du système IFM. Ces politiques sont
formalisées dans la Convention d’interopérabilité. Le Responsable IFM entretient des relations avec les
émetteurs de supports. Le Client entretient une relation avec l’émetteur du Support client qu’il possède.
Le Propriétaire de l’application entretient des relations avec les émetteurs de supports.
Pour gérer les éléments, le modèle IFM comprend deux rôles IFM de gestion:
— l’Office d’enregistrement, le rôle IFM qui identifie tout élément (Entité juridique, Composant, Masque
d’application et Application, Structure de produit et Produit) impliqué dans le système IFM;
8 © ISO 2015 – Tous droits réservés
— le Responsable sécurité, le rôle IFM de soutien chargé du fonctionnement en toute sécurité du
système IFM.
La Figure 2 présente les deux domaines d’application des rôles IFM du système IFM, ainsi que les
liaisons existantes entre eux.
L’Article 6 donne une description détaillée des interactions entre les rôles IFM.
Figure 2 — Les deux domaines IFM (rôles IFM opérationnels et de gestion)
6 Description des cas d’utilisation du modèle fonctionnel IFM
Le présent Article décrit les Cas d’utilisation pour le fonctionnement d’un système IFM. L’ensemble de
Cas d’utilisation décrits ici constitue une boîte à outils permettant de mettre en œuvre un système IFM.
Lorsque des processus décrits dans un Cas d’utilisation sont mis en œuvre dans un système IFM donné,
le Cas d’utilisation est obligatoire.
Cependant, certains cas d’utilisation pourraient être adaptés à l’aide de modifications en fonction de
la gestion des Applications et Produits. Une Application/Un produit peut être géré(e) soit de manière
centrée sur le support soit de manière centrée sur le back-office. Toute variation ou combinaison de ces
deux approches peut être envisagée.
Gestion centrée sur le support:
Les principaux processus (par exemple calcul des tarifs, facturation) de la gestion d’Application et
de Produit sont traités entre un Support et un Terminal billettique (MAD).
Gestion centrée sur le back-office:
Les principaux processus de la gestion d’Application et/ou de Produit sont traités dans le back-office.
Les Cas d’utilisation suivants décrivent les aspects fonctionnels du système IFM. Les questions
contractuelles n’entrent pas dans le cadre de la présente partie de l’ISO 24014, mais constituent un
prérequis à la mise en œuvre.
Tous les Acteurs impliqués dans les Cas d’utilisation sont écrits en LETTRES MAJUSCULES.
6.1 Certification
Il convient que chaque objet à intégrer au système IFM soit conforme aux exigences IFM. Cela est
démontré en vérifiant la conformité de l’objet à la Convention d’interopérabilité. Ce processus est appelé
certification.
Dans le système IFM, la certification concerne:
— les Entités juridiques,
— les Composants qui ont un impact sur la sécurité, et
— la Spécification et le Masque de l’application,
— la Spécification et la Structure de produit.
Le Responsable sécurité est chargé de la certification.
6.1.1 Certification des Entités juridiques
Nom du Cas d’utilisation Certification des Entités juridiques
Aperçu Chaque Entité juridique souhaitant participer au système IFM doit s’engager à respecter la Convention
d’interopérabilité.
Déclenché par ENTITE JURIDIQUE
Acteur(s) RESPONSABLE SECURITE
ENTITE JURIDIQUE
Description du Cas d’utilisation Si le RESPONSABLE SECURITE confirme que l’Entité juridique s’engage à respecter la Convention d’inte-
ropérabilité:
— L’ENTITE JURIDIQUE sera certifiée.
— Dans le cas contraire, l’ENTITE JURIDIQUE ne sera pas certifiée.
6.1.2 Certification des composants
Nom du Cas d’utilisation Certification des composants
Aperçu Il convient que chaque Composant à intégrer au système IFM soit conforme aux exigences IFM. Cela est
démontré en vérifiant la conformité du Composant à un la Convention d’interopérabilité.
Déclenché par FOURNISSEUR DU COMPOSANT
Acteur(s) RESPONSABLE SECURITE
FOURNISSEUR DU COMPOSANT
Description du Cas d’utilisation Le RESPONSABLE SECURITE vérifie la conformité du Composant à la Convention d’interopérabilité.
Si le Composant est conforme à la Convention d’interopérabilité:
— Le Composant sera certifié.
— Dans le cas contraire, le Composant ne sera pas certifié.
10 © ISO 2015 – Tous droits réservés
6.1.3 Certification de la Spécification et du Masque d’application
Nom du Cas d’utilisation Certification de la Spécification et du Masque d’application
Aperçu Chaque Spécification et Masque d’application à intégrer au système IFM doivent satisfaire aux exigences IFM.
Cela est démontré en vérifiant la conformité de cette Spécification et de ce Masque d’application à la
Convention d’interopérabilité.
Déclenché par PROPRIETAIRE DE L’APPLICATION
Acteur(s) RESPONSABLE SECURITE
PROPRIETAIRE DE L’APPLICATION
Description du Cas d’utilisation Le RESPONSABLE SECURITE vérifie la conformité de la Spécification et du Masque d’application à la
Convention d’interopérabilité.
Si la Spécification et le Masque d’application sont conformes à la Convention d’interopérabilité:
— La Spécification et le Masque d’application seront certifiés.
— Dans le cas contraire, la Spécification et le Masque d’application ne seront pas certifiés.
6.1.4 Certification de la Spécification et de la Structure de produit
Nom du Cas d’utilisation Certification de la Spécification et de la Structure de produit
Aperçu Chaque Spécification et Structure de produit à intégrer au système IFM doivent satisfaire aux exigences IFM.
Cela est démontré en vérifiant la conformité de cette Spécification et de cette Structure de produit à la
Convention d’interopérabilité.
Déclenché par PROPRIETAIRE DU PRODUIT
Acteur(s) RESPONSABLE SECURITE
PROPRIETAIRE DU PRODUIT
Description du Cas d’utilisation Le RESPONSABLE SECURITE vérifie la conformité de la Spécification et de la Structure de produit à la
Convention d’interopérabilité.
Si la Spécification et la Struct
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...