ISO 14906:2011

Electronic fee collection - Application interface definition for dedicated short-range communication

ISO 14906:2011 specifies the application interface in the context of electronic fee collection (EFC) systems using the dedicated short-range communication (DSRC).

Perception du télépéage — Définition de l'interface d'application relative aux communications dédiées à courte portée

L'ISO 14906:2011 spécifie l'interface d'application dans le contexte des installations de perception du télépéage utilisant des communications dédiées à courte portée.

General Information

• Status: Withdrawn
• Publication Date: 05-Oct-2011
• Withdrawal Date: 05-Oct-2011
• ICS: 03.220.20 - Road transport
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 5 - Fee and toll collection
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 31-Oct-2018
• Completion Date: 13-Dec-2025

Relations

• Amended By: ISO 14906:2011/Amd 1:2015 - Electronic fee collection - Application interface definition for dedicated short-range communication - Amendment 1
• Effective Date: 18-Dec-2021
• Revised: ISO 14906:2018 - Electronic fee collection - Application interface definition for dedicated short-range communication
• Effective Date: 06-Aug-2016
• Revises: ISO 14906:2004 - Road transport and traffic telematics - Electronic fee collection - Application interface definition for dedicated short-range communication
• Effective Date: 31-Jul-2008

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 14906
Second edition
2011-10-15
Electronic fee collection — Application
interface definition for dedicated short-
range communication
Perception du télépéage — Définition de l'interface d'application relative
aux communications dédiées à courte portée

Reference number
©
ISO 2011
©  ISO 2011
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO 2011 – All rights reserved

Contents Page
Foreword . iv
Introduction . v
1 Scope . 1
2 Normative references . 2
3 Terms and definitions . 2
4 Abbreviated terms . 5
5 EFC application interface architecture . 7
5.1 Relation to the DSRC communication architecture . 7
5.2 Usage of DSRC application layer by the EFC application interface . 9
5.3 Addressing of EFC attributes . 9
5.4 Addressing of components . 11
6 EFC Transaction Model . 12
6.1 General . 12
6.2 Initialisation Phase . 12
6.3 Transaction phase . 15
7 EFC Functions . 17
7.1 Overview and general concepts . 17
7.2 EFC functions . 21
8 EFC Attributes . 34
8.1 General . 34
8.2 Data group CONTRACT . 36
8.3 Data group RECEIPT . 36
8.4 Data group VEHICLE . 36
8.5 Data group EQUIPMENT . 37
8.6 Data group DRIVER . 37
8.7 Data group PAYMENT . 37
Annex A (normative) EFC data type specifications . 51
Annex B (informative) CARDME transaction . 67
Annex C (informative) Examples of EFC transaction types . 93
Annex D (informative) Functional requirements . 103
Annex E (normative) Mapping table from LatinAlphabetNo2 & 5 to LatinAlphabetNo1 . 110
Annex F (informative) Mapping table between EFC Vehicledata attribute and European
registration certificate . 111
Bibliography . 113

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 14906 was prepared by Technical Committee ISO/TC 204, Intelligent transport systems, in collaboration
with Technical Committee CEN/TC 278, Road transport and traffic telematics.
This second edition cancels and replaces the first edition (ISO 14906:2004), which has been technically
revised.
iv © ISO 2011 – All rights reserved

Introduction
This International Standard specifies an application interface for electronic fee collection (EFC) systems,
which are based on dedicated short-range communication (DSRC). It supports interoperability between EFC
systems on an EFC-DSRC application interface level. This International Standard is intended for DSRC
charging applications, but specifically the definition of EFC data elements is valid beyond the use of a DSRC
charging interface and might be used for other DSRC applications (e.g. compliance checking communication)
and/or on other interfaces (e.g. the application interface of autonomous systems).
This International Standard provides specifications for the EFC transaction model, EFC data elements
(referred to as attributes) and functions, from which an EFC transaction can be built. The EFC transaction
model provides a mechanism that allows handling of different versions of EFC transactions and associated
contracts. A certain EFC transaction supports a certain set of EFC attributes and EFC functions as defined in
this International Standard. It is not envisaged that the complete set of EFC attributes and functions be
present in each piece of EFC equipment, on-board equipment (OBE) or roadside equipment (RSE).
This International Standard provides the basis for agreements between operators, which are needed to
achieve interoperability. Based on the tools specified in this International Standard, interoperability can be
reached by operators recognising each others' EFC transactions (including the exchange of security
algorithms and keys) and implementing the EFC transactions in each others' RSEs, or they can reach an
agreement to define a new transaction (and contract) that is common to both. Considerations should also be
made by each operator so that the RSE has sufficient resources to implement such additional EFC
transactions.
In order to achieve interoperability, operators should agree on issues such as
 which optional features are actually being implemented and used,
 access rights and ownership of EFC application data in the OBE,
 security policy (including encryption algorithms and key management, if applicable),
 operational issues, such as how many receipts may be stored for privacy reasons, how many receipts are
necessary for operational reasons (for example as entry tickets or as proof of payment),
 the agreements needed between operators in order to regulate the handling of different EFC transactions.
In this revision, users are faced with issues related to backward compatibility. This issue can be managed by
using the following:
 EfcModule ASN.1 module, including a version number;
 Efc-ContextMark (incl. the ContextVersion), denoting the implementation version, provides a means to
ensure co-existence of different implementation versions by means of a look-up table and associated
appropriate transaction processing. This will enable the software of the RSE to determine the version of
the OBE and his capabilty to accept the new features of this version of this International Standard.
Annex A provides the normative ASN.1 specifications of the used data types (EFC action parameters and
attributes).
Annex B presents an informative example of a transaction based on the CARDME specification, including
bit-level specification.
Annex C presents informative examples of EFC transaction types, using the specified EFC functions and
attributes.
Annex D presents an informative listing of functional requirements, which can be satisfied by using the tools
provided by this International Standard.
Annex E presents an informative mapping table from LatinAlphabetNo2 & 5 to LatinAlphabetNo1 to ease for a
Service Provider the use of LatinAlphabetNo1 to encode an OBE for data available wiitten with non-Latin1
characters.
Annex F presents an informative mapping table between EFC vehicle data attributes and European
registration certificates to ease the task of a service provider when he needs to personalise an OBE by
obtaining vehicle data.
This application interface definition can also be used with other DSRC media which do not use a layer 7
according to ISO 15628/EN 12834. Any DSRC medium which provides services to read and write data, to
initialise communication and to perform actions is suitable to be used as a basis for this application interface.
Adaptations are medium specific and are not further covered here. As Annex B describes in detail a
transaction for central account systems, this International Standard can also be used for onboard account
systems, in conjunction with ISO/TS 25110, which provides examples of systems based on onboard accounts.

vi © ISO 2011 – All rights reserved

INTERNATIONAL STANDARD ISO 14906:2011(E)

Electronic fee collection — Application interface definition for
dedicated short-range communication
1 Scope
This International Standard specifies the application interface in the context of electronic fee collection (EFC)
systems using the dedicated short-range communication (DSRC).
The EFC application interface is the EFC application process interface to the DSRC application layer, as can
be seen in Figure 1 below. This International Standard comprises specifications of
 EFC attributes (i.e. EFC application information) that can also be used for other applications and/or
interfaces,
 the addressing procedures of EFC attributes and (hardware) components (e.g. ICC and MMI),
 EFC application functions, i.e. further qualification of actions by definitions of the concerned services,
assignment of associated ActionType values and content and meaning of action parameters,
 the EFC transaction model, which defines the common elements and steps of any EFC transaction,
 the behaviour of the interface so as to ensure interoperability on an EFC-DSRC application interface level.
RSE OBE
Application process
Application process
Attributes Attributes
(e.g. PaymentMeans, (e.g. PaymentMeans,
VehicleDimensions, …) VehicleDimensions, …)
ADU
ActionType (e.g. debit,
ActionType (e.g. debit,
set_MMI, transfer_channel, …) set_MMI, transfer_channel, …)
Scope of this
NotifyApplicationRSU
NotifyApplicationOBU
GET
GET
International
SET
SET
Standard
ACTION
EndApplication ACTION
RegisterApplicationOBU
RegisterApplicationRSU
.request .confirm DeregisterApplication
.response .indication
DeregisterApplication
EndApplication
T-ASDU T-ASDU
DSRC DSRC
I-Kernel
I-Kernel
application application
layer layer
T-APDU T-Kernel
T-Kernel
Kernel
Kernel
Figure 1 — The EFC application interface
This is an interface standard, adhering to the open systems interconnection (OSI) philosophy (see
ISO/IEC 7498-1), and it is as such not concerned with the implementation choices to be realised at either side
of the interface.
This International Standard provides security-specific functionality as place holders (data and functions) to
enable the implementation of secure EFC transactions. Yet the specification of the security policy (including
specific security algorithms and key management) remains at the discretion and under the control of the EFC
operator, and hence is outside the scope of this International Standard.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 612, Road vehicles — Dimensions of motor vehicles and towed vehicles — Terms and definitions
ISO 1176, Road vehicles — Masses — Vocabulary and codes
ISO 3166-1, Codes for the representation of names of countries and their subdivisions — Part 1: Country
codes
ISO 3779, Road vehicles — Vehicle identification number (VIN) — Content and structure
ISO 4217, Codes for the representation of currencies and funds
ISO 7812-1, Identification cards — Identification of issuers — Part 1: Numbering system
ISO/IEC 8824-1, Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic
notation
ISO/IEC 8825-2, Information technology — ASN.1 encoding rules: Specification of Packed Encoding Rules
(PER)
ISO 14816:2005, Road transport and traffic telematics — Automatic vehicle and equipment identification —
Numbering and data structure
ISO 15628:2007, Road transport and traffic telematics — Dedicated short range communication (DSRC) —
DSRC application layer
EN 12834:2003, Road transport and traffic telematics — Dedicated Short Range Communication (DSRC) —
DSRC application layer
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
access credentials
data that is transferred to on-board equipment (OBE), in order to establish the claimed identity of a roadside
equipment (RSE) application process entity
NOTE The access credentials carry information needed to fulfil access conditions in order to perform the operation
on the addressed element in the OBE. The access credentials can carry passwords as well as cryptographic based
information such as authenticators.
3.2
action
function that an application process resident at the roadside equipment can invoke in order to make the on-
board equipment (OBE) execute a specific operation during the transaction
2 © ISO 2011 – All rights reserved

3.3
attribute
application information formed by one or by a sequence of data elements, and that is managed by different
actions used for implementation of a transaction
3.4
authenticator
data appended to, or a cryptographic transformation of, a data unit that allows a recipient of the data unit to
prove the source and/or the integrity of the data unit and protect against forgery
3.5
channel
information transfer path
[ISO 7498-2:1989, definition 3.3.13]
3.6
component
logical and physical entity composing an on-board equipment, supporting a specific functionality
3.7
contract
expression of an agreement between two or more parties concerning the use of the road infrastructure
3.8
cryptography
discipline which embodies principles, means, and methods for the transformation of data in order to hide its
information content, prevent its undetected modification and/or prevent its unauthorised use
[ISO 7498-2:1989, definition 3.3.20]
3.9
data group
collection of closely related EFC data attributes which together describe a distinct part of an EFC transaction
3.10
data integrity
property that data has not been altered or destroyed in an unauthorised manner
[ISO 7498-2:1989, definition 3.3.21]
3.11
element
DSRC directory containing application information in the form of attributes
3.12
empty list
container for attributeValues (OCTET STRING) with the length equal to zero
3.13
on-board equipment
equipment fitted within or on the outside of a vehicle and used for toll purposes
NOTE The OBE does not need to include payment means.
3.14
on-board unit
minimum component of an on-board equipment, whose functionality always includes at least the support of
the DSRC interface
3.15
operator
entity involved in the process outside the user
NOTE An operator is a generic term which can be used for a toll service provider or a toll charger.
3.16
roadside equipment
equipment located along the road transport network, for the purpose of communication and data exchanges
with on-board equipment
3.17
service
EFC road transport related facility provided by a service provider, normally a type of infrastructure, the use of
which is offered to the user, for which the user may be requested to pay
3.18
service primitive
communication elementary communication service provided by the application layer protocol to the
application processes
NOTE The invocation of a service primitive by an application process implicitly calls upon and uses services offered
by the lower protocol layers.
3.19
session
exchange of information and interaction occurring at a specific EFC station between the roadside equipment
and the user/vehicle
3.20
toll charger
legal entity charging toll for vehicles in a toll domain
[ISO/TS 17574:2009, definition 3.27]
3.21
toll domain
area or part of a road network where a toll regime is applied
[ISO 17573:2010, definition 3.18]
3.22
toll service
EFC service enabling users having only one contract and one set of on-board equipment (OBE) to use a
vehicle in one or more toll domains
NOTE Adapted from ISO/TS 12813:2009.
3.23
toll service provider
EFC legal entity providing to his customers toll services on one or more toll domains for one or more classes
of vehicle
NOTE 1 In other documents the terms issuer or contract issuer may be used.
NOTE 2 The toll service provider may provide the OBE or may provide only a magnetic card or a smart card to be used
with OBE provided by a third party (like a mobile telephone and a SIM card can be obtained from different parties).
NOTE 3 The toll service provider is responsible for the operation (functioning) of the OBE.
[ISO/TS 17574:2009, definition 3.28]
4 © ISO 2011 – All rights reserved

3.24
transaction
whole of the exchange of information between the roadside equipment and the on-board equipment
necessary for the completion of an EFC operation over the DSRC
3.25
transaction model
functional model describing the general structure of electronic payment fee collection transactions
3.26
user
customer of a toll service provider, one liable for toll, the owner of the vehicle, a fleet operator, a driver, etc.,
depending on the context
4 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply unless otherwise specified.
4.1
APDU
Application Protocol Data Unit
4.2
AP
Application Process
4.3
ASN.1
Abstract Syntax Notation One (ISO/IEC 8824-1)
4.4
BST
Beacon Service Table
4.5
CCC
Compliance check communication
4.6
cf
Confirm
4.7
DSRC
Dedicated Short-Range communication
4.8
EID
Element Identifier
4.9
EFC
Electronic Fee Collection
4.10
GPS
Global Positioning System
4.11
ICC
Integrated Circuit(s) Card
4.12
I-Kernel
Initialisation Kernel
4.13
IID
Invoker Identifier
4.14
ind
Indication
4.15
LAC
Localisation Augmentation Communication
4.16
L1
Layer 1 of DSRC (Physical Layer)
4.17
L2
Layer 2 of DSRC (Data Link Layer)
4.18
L7
Application Layer Core of DSRC
4.19
LID
Logical Link Control Identifier
4.20
LLC
Logical Link Control
4.21
LPDU
LLC Protocol Data Unit
4.22
MAC
Medium Access Control
4.23
MMI
Man-Machine Interface
4.24
n.a.
Not applicable
4.25
OBE
On-Board Equipment
6 © ISO 2011 – All rights reserved

4.26
PDU
Protocol Data Unit
4.27
PER
Packed Encoding Rules (ISO/IEC 8825-2)
4.28
req
Request
4.29
rs
Response
4.30
RSE
Roadside Equipment
4.31
RTTT
Road Transport and Traffic Telematics
4.32
SAM
Secure Application Module
4.33
T-APDU
Transfer-Application Protocol Data Unit
4.34
T-ASDU
Transfer-Application Service Data Unit
4.35
T-Kernel
Transfer Kernel
4.36
VST
Vehicle Service Table
5 EFC application interface architecture
5.1 Relation to the DSRC communication architecture
The DSRC services are provided to an application process by means of the DSRC Application Layer service
primitives, which are abstract implementation interactions between a communication service user and a
provider. The services are offered by the DSRC communication entities by means of its DSRC Application
Layer (EN 12834/ISO 15628).
RSU OBU
AP ADU AP
NotifyApplicationRSU NotifyApplicationOBU
GET GET
SET SET
EndApplication RegisterApplicationOBU
ACTION ACTION
RegisterApplicationRSU DeregisterApplication
.response .indication
.request .confirm
DeregisterApplication EndApplication
B-Kernel
B-Kernel
I-Kernel I-Kernel
n.a. for
n.a. for
EFC
EFC
DSRC-L7 DSRC-L7
T-Kernel
T-APDU T-Kernel
LLC sublayer LLC sublayer
DSRC-L2 LPDU DSRC-L2
MAC sublayer MAC sublayer
DSRC-L1 Physical layer
PPDU Physical layer DSRC-L1
Figure 2 — The EFC application process on top of the DSRC communication stack
NOTE The abbreviations used in Figure 2 are defined in Clause 4.
The Transfer Kernel of DSRC Application Layer offers the following services to application processes (see
also Figure 2 above):
 GET: The invocation of a GET service request results in retrieval (i.e. reading) of application information
(i.e. Attributes) from the peer service user (i.e. the OBE application process), a reply is always expected.
 SET: The invocation of a SET service request results in modification (i.e. writing) of application
information (i.e. Attributes) of the peer service user (i.e. the OBE application process). This service may
be requested in confirmed or non-confirmed mode, a reply is only expected in the former case.
 ACTION: The invocation of an ACTION service request results in a performance of an action by the peer
service user (i.e. the OBE application process). An action is further qualified by the value of the
ActionType. This service may be requested in confirmed or non-confirmed mode, a reply is only expected
in the former case.
8 © ISO 2011 – All rights reserved

 EVENT-REPORT: The invocation of an EVENT-REPORT service request forwards a notification of an
event to the peer service user.
 INITIALISATION: The invocation of an initialisation service request by RSE results in an attempt to
initialise communication between a RSE and each OBE that has not yet established communication with
the concerned RSE. The Initialisation service is only used by the Initialisation Kernel as defined in
EN 12834/ISO 15628.
5.2 Usage of DSRC application layer by the EFC application interface
EFC uses the following services offered by DSRC Application Layer (as defined in EN 12834/ISO 15628):
 The INITIALISATION services:
 Notify Application RSU (at RSE);
 End Application (at RSE);
 Register Application RSU (at RSE);
 Deregister Application (at RSE and OBE);
 Notify Application OBU (at OBE);
 Register Application OBU (at OBE)
are used to realise the EFC-specific initialisation mechanism (see Clause 6);
 The GET service is used to retrieve EFC attributes (For attribute specifications see Clause 8);
 The SET service is used to set EFC attributes;
 The ACTION services are applied to realise additional EFC specific functionality needed to support EFC
application processes, such as TRANSFER_CHANNEL, SET_MMI and ECHO (see 7.2).
In the following, the EFC-specific usage of the DSRC Layer 7 services is specified in detail.
NOTE The EVENT-REPORT-service can be implicitly used by EFC application processes. It is e.g. used indirectly as
part of an already defined command to release an application process (see EN 12834/ISO 15628, Ready Application).
However as the EVENT-REPORT-service is not explicitly used by EFC application processes, this service is not further
referred to in this International Standard.
5.3 Addressing of EFC attributes
5.3.1 Basic mechanism
EFC Attributes are used to transfer the EFC application-specific information.
EFC Attributes are composed of one or more data elements of specified ASN.1 types. Each data element is
associated with, within the context of this International Standard, an unambiguous name.
To each EFC Attribute, an AttributeID is associated. The AttributeId enables to unambiguously identify and
address an EFC Attribute.
EXAMPLE Figure 3 illustrates the basic addressing mechanism.
Attribute ID AttrlD = 0 AttrlD = 2 AttrlD = 3 AttrlD = 4 AttrlD = n
Contract Contract Contract
….
……….
Attribute
Validity Vehicle Authenticator
ContractAuthenticator ::=
ContractVehicle ::=
ASN.1-Type
ContractValidity ::= SEQUENCE {
contractRestrictions OCTET STRING (SIZE(4))
contractExpiryDate  DateCompact
}
Figure 3 — Basic addressing mechanism
5.3.2 Role of the EID
In a given OBE, the DSRC-EID (different from 0) is used to address an EFC context, identified by the
EFC-ContextMark (see 6.2.3), in which Attributes can be addressed unambiguously by AttributeIDs inside an
Element of the OBE. In the VST, the OBE specifies one or several of these EFC contexts, each corresponding
to an EFC ContextMark and the EID to be used for addressing the attributes and using the EFC functions
supported by it.
EXAMPLE
AttrlD = 0 AttrlD = 2 AttrlD = 3 AttrlD = 4 AttrlD = n
Contract Contract Contract
….
Validity Vehicle Authenticator ……….
EID = 1
A A A
Contract Contract Contract
…. ……….
Validity Vehicle Authenticator
EID = 2
B B B
Contract Contract Contract
…. ……….
EID = 3 Validity Vehicle Authenticator
C C C
Figure 4 — Role of the EID
EID equals 0 shall be used to address application-independent functions and components, e.g. SET_MMI and
TRANSFER_CHANNEL (see 7.2).
5.3.3 Multiple Instances of Attributes
There may be n, where n is an integer, instances of an Attribute available in an OBE.
The maximum number of instances N of one Attribute may be limited according to the needs of operators
max
and users. The default maximum number of instances is N =1. The value of N is determined at the time of
max max
OBE configuration.
10 © ISO 2011 – All rights reserved

EXAMPLE
AttrlD = 0 AttrlD = 5 AttrlD = n
ReceiptServicePart2
………. ……….
ReceiptServicePart 1
EID = 1
ReceiptServicePart 0
Figure 5 — Multiple instances (0-2) of attribute 5
The handling of multiple instances and the corresponding addressing mechanism are described in detail as
part of the behaviour specification of the corresponding functions supporting multiple instances (see 7.2.6 for
GET_INSTANCE and 7.2.7 for SET_INSTANCE).
5.4 Addressing of components
Components of an OBE to be addressed via the EFC Application Interface include for example:
— OBU;
— SAM 1;
— SAM 2;
— ICC;
— Display;
— Buzzer;
— Printer;
— Serial interface;
— Parallel interface;
— GPS;
— Tachograph;
— Bluetooth.
Addressing of these components is enabled on two levels, device-specific and device-independent addressing.
The device-specific transparent addressing mechanism enables the transfer of information, which shall be
processed by the addressed device (such as an ICC-command). The addressed device is identified by a
channel Id. The EFC function TRANSFER_CHANNEL (see 7.2.10) supports this functionality.
EXAMPLE 1 Transfer of a bit string to an ICC.
The device-independent addressing mechanism uses a set of commands, which describe a certain
functionality, which can be performed by various OBE components. In this case, the operating system of the
OBE will address the corresponding components. The EFC function SET_MMI supports this functionality
(see 7.2.12).
EXAMPLE 2 Invocation of a SET_MMI(EID=0, ContactOperator) function activates an OBE MMI-device, e.g. a buzzer
or a display.
NOTE In a specific implementation, specific attributes or data elements may activate some MMI function (e.g. a SET
command on the attribute ReceiptText might display the text on an LCD display. A SET command on the attribute
ReceiptServicePart with data element SessionResultOperational other than SessionOK might activate an alert beep).
Proprietary addressing mechanisms are not defined by this International Standard.
6 EFC Transaction Model
6.1 General
The EFC Transaction Model related to the EFC Application Interface for the DSRC comprises two phases, the
initialisation phase and the transaction phase.
NOTE The purpose of the initialisation phase is to set up the communication between the RSE and OBEs that have
entered the DSRC zone but have not yet established communication with the RSE, and to notify the application processes.
It provides amongst others a multi-application switching mechanism, allowing for execution of several RTTT applications
(in parallel) at one RSE station.
The transaction phase can only be reached after completion of the initialisation phase. The EFC functions, as
defined in Clause 7, can be performed in the transaction phase. The GET and SET services (DSRC
application layer functions) as defined in EN 12834/ISO 15628 (in 6.2) may also be used in an EFC
transaction phase.
6.2 Initialisation Phase
6.2.1 Overview
This clause provides an overview of the functionality of, and the information exchanges in, the initialisation
phase.
The Initialisation procedures, by means of beacon service table (BST) and vehicle service table (VST)
exchanges, are defined in EN 12834/ISO 15628 6.2.2 and 6.2.3 below account for the EFC application-
specific information that shall be included in the BST and VST, respectively.
NOTE The OBE evaluates the received BST, and selects the applications that it wishes to perform out of the lists of
applications supported by the RSE. If the OBE does not support any of application(s) supported by the RSE, then it is
recommended that the OBE does not exchange any information with the RSE. If the OBE supports at least one of the
application(s) supported by the RSE, then it is recommended that the OBE informs the RSE of which application it wishes
to execute in its corresponding VST.
12 © ISO 2011 – All rights reserved

RSE OBE
EFC-
EFC-
Layer 7 Layer 7
application
application
I-Kernel T-Kernel I-Kernel T-Kernel
RegisterApplication
INIT.rq(BST) RegAppVehicle
Beacon
T-APDU(INIT.rq(BST))
BST
INIT.ind(BST)
NotifyApplication
Vehicle
T-APDU(INIT.rs(VST))
INIT.cf(VST)
VST
NotifyApplication
Beacon
Figure 6 — Initialisation phase: BST - VST exchanges
The Initialisation service associated with the initialisation phase is only used by the Initialisation Kernel
(of EN 12834/ISO 15628), which in its turn is configured by the application(s) wishing to execute applications
over a DSRC link. The Initialisation Kernels of the RSE and of the concerned OBE shall have been configured,
according to EN 12834/ISO 15628, prior to the invocation of the Initialisation service by the RSE.
6.2.2 EFC application-specific contents of the BST
An RSE supporting EFC shall have configured its Initialisation Kernel to carry the following information related
specifically to the EFC application(s):
 the application identifier (AID) shall be equal to 1 (i.e. the value assigned for EFC);
 the EFC application shall be qualified as a mandatory application;
 EID shall not be transmitted in the BST related to the EFC application;
 no Parameter shall be transmitted in the BST related to the EFC application.
NOTE 1 AID equals to 14 identifies the multi-purpose payment context. In Japan, ISO 14906 specifies the application
interface for DSRC used for multi-purpose payment (when the Aid=14 is used in Japan, the EID and parameter fields are
defined through the BST).
There shall be only one EFC application present in the BST (i.e. there shall be only one instance of AID=1 in
the BST) regardless of whether the RSE supports more than one EFC-ContextMark (see also 6.2.3).
NOTE 2 The above is the EFC application-specific contents of the BST. The complete BST is defined in
EN 12834/ISO 15628 and is given below for readability of this International Standard:
BST ::= SEQUENCE {
beacon BeaconID,
time Time,
profile Profile,
mandApplications ApplicationList,
nonmandApplications ApplicationList OPTIONAL,
profileList SEQUENCE(0.127, .) OF Profile
}
where
ApplicationList ::= SEQUENCE (0.127,.) OF
SEQUENCE{
aid DSRCApplicationEntityID, -- AID=1
eid Dsrc-EID OPTIONAL, -- empty
parameter Container OPTIONAL -- empty
}
6.2.3 EFC application-specific contents of the VST
Each EFC application and corresponding contract shall be associated with an EFC-ContextMark, as defined
below. An OBE may support several EFC applications.
NOTE 1 It is outside the scope of this International Standard to define in which order EFC-ContextMarks shall be
presented in order to indicate a user's order of preference, in case his OBE supports several EFC applications. Such rules
for indicating the user's order of preference may be subject to agreements between operators.
An OBE supporting EFC shall have configured its Initialisation Kernel to carry the following information related
specifically to the concerned EFC application:
 the AID shall be equal to 1;
 the EID value shall be logically associated with the corresponding EFC-ContextMark, contained in the
Parameter, and shall be unique within the OBE throughout the complete DSRC session;
 the Parameter shall be of Container CHOICE type OCTET STRING and shall comprise the EFC-
ContextMark as defined below, and may also be configured to carry additional EFC attributes (as defined
in Clause 8 and Annex A).
EFC-ContextMark::=SEQUENCE{
ContractProvider Provider,
TypeOfContract OCTET STRING (SIZE(2)),
ContextVersion INTEGER(0.127,.)
}
The EFC-ContextMark denotes a specific EFC context in the OBE, comprising the organization that issued
the contract, the type of contract and the context version. ContractProvider, TypeOfContract and
ContextVersion are further defined in Clause 8 as data elements of the Attribute EFC-ContextMark.
NOTE 2 The above is the EFC application-specific contents of the VST. The complete VST is defined in
EN 12834/ISO 15628 and is given below for readability of this International Standard:
VST ::=  SEQUENCE {
fill BIT STRING (SIZE(4))
profile Profile,
applications ApplicationList,
obeConfiguration ObeConfiguration
}
14 © ISO 2011 – All rights reserved

where:
ApplicationList ::= SEQUENCE (0.127,.) OF
SEQUENCE{
aid DSRCApplicationEntityID, -- AID =1
eid Dsrc-EID OPTIONAL, -- EID = e.g. 2
parameter Container OPTIONAL -- EFC-ContextMark
-- plus any EFC Attribute
}
NOTE 3 Means to ensure backwards compatibility and co-existence:
 EfcModule ASN.1 module, including a version number
 Efc-ContextMark (incl. the ContextVersion), denoting the implementation version, provides a means to ensure co-
existence of different implementation versions by means of a look-up table and associated appropriate transaction
processing.
NOTE 4 Aid equals to 14 identifies the Multi-purpose payment context. In Japan, ISO 14906 specifies the application
interface for DSRC used for multi-purpose payment (when the Aid=14 is used in Japan, the EID and parameter fields are
defined through the BST).
NOTE 5 An EFC application provider retains the ultimate control of his security domain, i.e. the security level and the
associated security mechanisms to be used within his system.
The data element obeStatus contained in the data element obeConfiguration shall always be present and may
indicate the status of the OBE's battery. This information may be used by the RSE to notify the driver (e.g.
using the SET_MMI code “contact operator”). See Annex A for details.
NOTE 6 Retrofit DSRC OBE are mostly battery powered, and the battery usually has a lifetime which is dependent on
the actual usage of the OBE (number of transactions per day, activation of MMI, etc.). In an interoperable environment, the
Toll Charger(s) can access to the OBE via the DSRC interface and can can check the status of the battery and indicate it
to the driver.
6.3 Transaction phase
After completion of the Initialisation phase, the appropriate RSE application is informed (by means of the
Notify Application RSU service) of the EFC-ContextMark and associated EID. The RSE shall use the functions
defined in Clause 7 to complete the EFC transaction.
The RSE may invoke any sequence of EFC functions to complete the EFC transaction, provided that they are
supported by the EFC-ContextMark. The OBE shall respond to the EFC functions invoked by the RSE, and
shall not initiate any EFC functions (by usage of a request service primitive, see further Clause 7) on its side.
EXAMPLE A transaction may consist of the following steps:
 GET(EID, ContractValidity, ContractVehicle, ReceiptServicePart, PaymentMeansBalance)
 DEBIT(EID, DebitPaymentFee)
 SET(EID, ReceiptServicePart)
Due to the construction of the EFC part of the VST, each EID identifies a certain EFC-ContextMark and shall
be used by the RSE as parameter of every function to unambiguously address data elements within the
context given by the EFC-ContextMark. More than one EID may be used in one session.
Both which attributes that are to be implemented and the maximum number of instances of an attribute is
defined at time of configuration of the OBE, and is outside the scope of this International Standard. These
implementation dependent aspects are referenced unambiguously by the EFC-ContextMark (for each element
present in the OBE).
AttrlD = 1 AttrlD = 2 AttrlD = 3 AttrlD = 4 AttrlD = 5 AttrlD = 6
EID = 1
EID = 2
EID = 3
Multiple Same type
Same type
and same instances but different
value for
values
all EIDs
Figure 7 — Context of attributes given by EFC-ContextMark and identified by the EID
NOTE 1 This construction of contexts being identified by EIDs allows amongst others to implement the following
transactions:
 Booking from two contracts in one transaction. There is sometimes the need to book from two contracts in one
session, e.g. when a customer has a contract with a reduced price (e.g. a commuter contract) for part of the route
being tolled, plus an ordinary (not reduced) contract for the rest of the route. This may be implemented by having all
data groups identical between two EIDs, except for the data group contract.
 Having either two instances of the data group Vehicle to accommodate a pulling vehicle plus a trailer, or having two
Elements containing same attribute one for the pulling vehicle and one for the trailer (and probably also separate
Contract).
NOTE 2 This EFC transaction model and associated procedures allow for different levels of co-existence and
interoperability between operators:
 No agreement between operators - each operator has a completely separate application domain, i.e. there are no
common data groups. Each operator uses the attributes associated with “his” EFC-Context Mark.
 Agreement to share some data groups, but not others. E.g. the data groups Vehicle, Receipt and Payment are
shared, but not Contract. Different security measures (algorithms) are used by the two operators (or more. Or, all
data groups are shared, except for Payment - each operator books from an account issued by himself.
 Agreement between operators (Toll Chargers and ETS Provider): each Toll Charger has the possibility to select only
the attributes needed for a given toll context (principle of “Pick what you need”) amongst common Data Group.
16 © ISO 2011 – All rights reserved

7 EFC Functions
7.1 Overview and general concepts
7.1.1 EFC functions and service primitives
This clause describes the EFC functions invoked by T-ASDUs exchanged between peer applications
communicating via a DSRC link. The T-ASDUs are exchanged by means of service primitives of the DSRC
Application Layer (EN 12834/ISO 15628). Exchanges of service primitives (and the corresponding T-ASDUs)
associated with EFC functions adhere to the following basic pattern:
 xxx.rq (request) service primitive invoked by the RSE application to DSRC Application Layer;
 xxx.ind (indication) service primitive issued by the DSRC Application Layer to the OBE application;
 xxx.rs (response) service primitive invoked by th
...

NORME ISO
INTERNATIONALE 14906
Deuxième édition
2011-10-15
Perception du télépéage — Définition de
l'interface d'application relative aux
communications dédiées à courte portée
Electronic fee collection — Application interface definition for dedicated
short-range communication
Numéro de référence
©
ISO 2011
DOCUMENT PROTÉGÉ PAR COPYRIGHT

©  ISO 2011
Droits de reproduction réservés. Sauf prescription différente, 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 et les microfilms, sans l'accord écrit
de l'ISO à l'adresse ci-après ou du comité membre de l'ISO dans le pays du demandeur.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Publié en Suisse
ii © ISO 2011 – Tous droits réservés

Sommaire Page
Avant-propos . iv
Introduction . v
1 Domaine d'application . 1
2 Références normatives . 2
3 Termes et définitions . 2
4 Termes abrégés . 5
5 Architecture d'interface d'application EFC . 8
5.1 Relation avec l'architecture de communication de DSRC . 8
5.2 Utilisation de la couche d'application de DSRC par l'interface d'application de l'EFC . 9
5.3 Adressage des attributs d'EFC . 9
5.4 Adressage des composants . 11
6 Modèle de transaction d'EFC . 12
6.1 Généralités . 12
6.2 Phase d'initialisation . 12
6.3 Phase de transaction . 15
7 Fonctions d'EFC . 17
7.1 Vue d'ensemble et concepts généraux . 17
7.2 Fonctions d'EFC . 21
8 Attributs d'EFC . 34
8.1 Généralités . 34
8.2 Groupe de données CONTRACT . 36
8.3 Groupe de données RECEIPT . 36
8.4 Groupe de données VEHICLE . 36
8.5 Groupe de données EQUIPMENT . 37
8.6 Groupe de données DRIVER . 37
8.7 Groupe de données PAYMENT . 37
Annexe A (informative) Spécifications de type de données d'EFC . 50
Annexe B (informative) Transaction CARDME . 67
Annexe C (informative) Exemples de types de transactions d'EFC . 93
Annexe D (informative) Exigences fonctionnelles . 103
Annexe E (normative) Tableau de mappage de LatinAlphabetNo2 et 5 à LatinAlphabetNo1 . 110
Annexe F (informative) Tableau de mappage entre l'attribut Vehicledata d'EFC et le certificat
d'immatriculation européen . 111
Bibliographie . 114

Avant-propos
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 (CEI) 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/CEI,
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.
L'ISO 14906 a été élaborée par le comité technique ISO/TC 204, Systèmes intelligents de transport, en
collaboration avec le comité technique CEN/TC 278, Application télématique pour le transport routier et la
circulation routière.
Cette deuxième édition annule et remplace la première édition (ISO 14906:2004), qui a fait l'objet d'une
révision technique.
iv © ISO 2011 – Tous droits réservés

Introduction
La présente Norme internationale spécifie une interface d'application relative aux installations de perception
du télépéage (EFC) reposant sur des systèmes de communication dédiés à courte portée (DSRC). Elle
permet l'interopérabilité entre installations EFC à un niveau donné d'interface d'application EFC-DSRC. Elle
est destinée aux applications de facturation par DSRC, mais de façon spécifique la validité de la définition des
éléments de données EFC dépasse l'utilisation d'une interface de facturation par DSRC et peut être utilisée
pour d'autres applications de DSRC (par exemple une communication de contrôle de conformité) et/ou sur
d'autres interfaces (par exemple l'interface d'application de systèmes autonomes).
La présente Norme internationale définit les spécifications du modèle de transaction EFC, des éléments de
données EFC (appelés attributs) ainsi que des fonctions EFC sur lesquels peut se construire une transaction
EFC. Le modèle de transaction EFC fournit un mécanisme qui permet de traiter différentes versions de
transactions EFC ainsi que les contrats associés. Une transaction EFC donnée comporte un certain nombre
des attributs et des fonctions EFC qui sont définis dans la présente Norme internationale. Il n'est pas
envisagé d'introduire l'ensemble complet des attributs et fonctions EFC dans chaque élément d'installation
EFC, qu'il s'agisse d'équipements embarqués (OBE) ou d'infrastructures routières (RSE).
La présente Norme internationale fournit, à l'intention des opérateurs, une base d'accord indispensable pour
assurer l'interopérabilité. Les outils spécifiés dans le document permettent d'assurer cette interopérabilité
entre opérateurs pourvu que chacun reconnaisse les transactions EFC des autres (y compris l'échange des
algorithmes et des clés de sécurité) et les mette en œuvre dans ses infrastructures comme dans celles des
autres ou bien que les opérateurs s'accordent pour définir une nouvelle transaction — et un nouveau
contrat — qui leur soient communs. Il convient également que chaque opérateur examine si son infrastructure
routière possède les ressources nécessaires pour mettre en œuvre les transactions EFC supplémentaires du
type défini.
Pour assurer l'interopérabilité, il convient que les opérateurs se mettent d'accord sur des points tels que:
 les aspects facultatifs à mettre effectivement en œuvre et à utiliser;
 les droits d'accès et la propriété des données de l'application EFC dans l'OBE;
 la politique de sécurité (y compris les algorithmes de chiffrement et la gestion des clés, le cas échéant);
 les questions opérationnelles, comme le nombre de reçus pouvant être conservés pour des raisons de
confidentialité, le nombre de reçus nécessaires pour des raisons opérationnelles (tickets d'entrée ou
preuves de paiement par exemple);
 les accords entre opérateurs nécessaires pour réglementer les différentes transactions EFC.
Dans la présente révision, les utilisateurs sont confrontés à des problèmes de compatibilité ascendante. Ce
problème peut être traité en utilisant les éléments suivants:
 Module EfcModule ASN.1, incluant un numéro de version;
 Efc-ContextMark (incluant ContextVersion), représentant la version de mise en œuvre, qui fournit un
moyen pour garantir la coexistence de différentes versions de mise en œuvre au moyen d'un tableau de
correspondance et du traitement de transactions associées appropriées. Cela permet au logiciel du RSE
de déterminer la version de l'OBE et sa capacité à prendre en charge les nouvelles fonctions de cette
version de la présente Norme internationale.
L'Annexe A comporte les spécifications normatives ASN.1 des types de données utilisés (paramètres et
attributs de l'action EFC).
L'Annexe B donne un exemple de transaction reposant sur la spécification CARDME, avec la spécification du
niveau des éléments binaires.
L'Annexe C donne des exemples informatifs de types de transaction EFC avec les fonctions et attributs EFC
spécifiés.
L'Annexe D répertorie de manière informative les exigences fonctionnelles qui peuvent être respectées si l'on
utilise les outils fournis dans la présente Norme internationale.
L'Annexe E présente un tableau informatif de mappage des alphabets LatinAlphabetNo2 et 5 sur l'alphabet
LatinAlphabetNo1 pour faciliter à un fournisseur de service l'utilisation de l'alphabet LatinAlphabetNo1 pour
coder un OBE pour des données disponibles écrites avec des caractères non-Latin1.
L'Annexe F présente un tableau informatif de mappage entre les attributs de données de véhicule EFC et les
certificats d'immatriculation européens, destiné à faciliter la tâche d'un fournisseur de service lorsqu'il a besoin
de personnaliser un OBE par rapport à la façon d'obtenir certaines données de véhicule.
Cette définition d'interface d'application peut également être utilisée avec d'autres supports de DSRC qui
n'utilisent pas la couche 7 selon l'ISO 15628/l'EN 12834. Tout support de DSRC fournissant des services de
lecture et d'écriture de données pour initialiser une communication et pour exécuter des actions convient pour
être utilisé comme base pour cette interface d'application. Les adaptations sont spécifiques au support et ne
sont pas traitées ici. L'Annexe B décrit en détail une transaction pour un système de comptabilité centralisé.
La présente Norme internationale peut également être utilisée pour un système de comptabilité embarqué,
conjointement à l'ISO/TS 25110, qui donne des exemples de systèmes basés sur une comptabilité
embarquée.
vi © ISO 2011 – Tous droits réservés

NORME INTERNATIONALE ISO 14906:2011(F)

Perception du télépéage — Définition de l'interface
d'application relative aux communications dédiées à courte
portée
1 Domaine d'application
La présente Norme internationale spécifie l'interface d'application dans le contexte des installations de
perception du télépéage (EFC) utilisant des communications dédiées à courte portée (DSRC).
Cette interface d'application EFC est l'interface du processus d'application EFC avec la couche d'application
DSRC, comme le montre la Figure 1 ci-dessous. La présente Norme internationale spécifie les éléments
suivants:
 les attributs EFC (c'est-à-dire les informations sur l'application EFC) pouvant également être utilisés pour
d'autres applications et/ou interfaces;
 les procédures d'adressage des attributs EFC et des composants (matériels) (par exemple ICC et MMI);
 les fonctions de l'application EFC, c'est-à-dire la qualification ultérieure des actions par la définition des
services concernés, l'attribution des valeurs ActionType associées ainsi que le contenu et la signification
des paramètres des actions;
 le modèle de transaction EFC, qui définit les éléments et les étapes que toutes les transactions ont en
commun;
 le comportement de l'interface qui doit assurer l'interopérabilité à un niveau donné d'interface
d'application EFC-DSRC.
RSE OBE
Processus d’application
Processus d’application
Attributs (par exemple Attributs (par exemple
PaymentMeans, PaymentMeans,
VehicleDimensions, …) VehicleDimensions, …)
ADU
ActionType (par exemple débit, ActionType (par exemple débit,
set_MMI, transfer_channel, …)
set_MMI, transfer_channel, …)
Domaine
d’application
NotifyApplicationRSU
NotifyApplicationOBU
GET
GET
de la
SET
SET
présente
ACTION EndApplication
ACTION RegisterApplicationOBU
Norme
RegisterApplicationRSU
.request .confirm DeregisterApplication
.response .indication
internationale DeregisterApplication
EndApplication
T-ASDU
T-ASDU
Couche Couche
I-Kernel
d’application d’application
I-Kernel
DSRC DSRC
T-APDU T-Kernel
T-Kernel
Kernel
Kernel
Figure 1 — Interface d'application EFC
Il s'agit d'une interface normalisée répondant à la philosophie de l'interconnexion des systèmes ouverts (OSI)
(voir l'ISO/CEI 7498-1) et qui, en tant que telle, ne dépend pas des choix de mise en œuvre réalisés de part et
d'autre de l'interface.
La présente Norme internationale définit en termes de paramètres fictifs (données et fonctions) la
fonctionnalité spécifique permettant d'assurer la sécurité de mise en œuvre des transactions EFC. La
spécification de la politique de sécurité (y compris les algorithmes de sécurité particuliers et la gestion des
clés) demeure toutefois de la responsabilité de l'opérateur EFC et ne relève donc pas du domaine
d'application du présent document.
2 Références normatives
Les documents de référence suivants sont indispensables pour l'application du présent document. Pour les
références datées, seule l'édition citée s'applique. Pour les références non datées, la dernière édition du
document de référence s'applique (y compris les éventuels amendements).
ISO 612, Véhicules routiers — Dimensions des automobiles et véhiculés tractés — Dénominations et
définitions
ISO 1176, Véhicules routiers — Masses — Vocabulaire et codes
ISO 3166-1, Codes pour la représentation des noms de pays et de leurs subdivisions — Codes de pays
ISO 3779, Véhicules routiers — Numéro d'identification des véhiculés (VIN) — Contenu et structure
ISO 4217, Codes pour la représentation des monnaies et types de fonds
ISO 7812-1, Cartes d'identification — Identification des émetteurs — Partie 1: Système de numérotation
ISO/CEI 8824-1, Technologies de l'information — Notation de syntaxe abstraite numéro un (ASN.1):
Spécification de la notation de base
ISO/CEI 8825-2, Technologies de l'information — Règles de codage ASN.1: Spécification des règles de
codage compact (PER)
ISO 14816:2005, Télématique du transport routier et de la circulation routière — Identification automatique
des véhicules et des équipements — Codification et structure des données
ISO 15628:2007, Télématique du transport routier et de la circulation routière — Communications dédiées à
courte portée (DSRC) — Couche d'application DSRC
EN 12834:2003, Télématique de la circulation et du transport routier — Communication à courte portée —
Couche applicative
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s'appliquent.
3.1
justificatifs d'accès
données transmises à l'équipement embarqué (OBE) afin de déterminer l'identité déclarée d'une entité de
processus d'application d'équipement d'infrastructures routières (RSE)
NOTE Les justificatifs d'accès comportent les informations nécessaires pour satisfaire aux conditions d'accès afin
d'exécuter l'opération sur l'élément adressé dans l'OBE. Les justificatifs d'accès peuvent comporter des mots de passe
ainsi que des informations cryptographiques, par exemple des authentifiants.
2 © ISO 2011 – Tous droits réservés

3.2
action
fonction pouvant être appelée par un processus d'application résident sur l'équipement d'infrastructures
routières afin de faire exécuter une opération spécifique par l'équipement embarqué (OBE) durant la
transaction
3.3
attribut
information d'application constituée d'un élément de données ou d'une séquence de tels éléments et gérée
par différentes actions utilisées pour la mise en œuvre d'une transaction
3.4
authentifiant
donnée ajoutée à une unité de données ou transformation cryptographique (voir 3.8) d'une telle unité,
permettant à un destinataire de l'unité de données de prouver la source et l'intégrité de l'unité de données et
la protection contre la contrefaçon
3.5
voie
chemin de transfert de l'information
[ISO 7498-2:1989, définition 3.3.13]
3.6
composant
entité logique et physique composant un équipement embarqué, prenant en charge une fonctionnalité
particulière
3.7
contrat
expression d'un accord entre deux parties ou plus, concernant l'utilisation de l'infrastructure routière
3.8
cryptographie
discipline incluant les principes, moyens et méthodes de transformation des données, dans le but de cacher
leur contenu, d'empêcher que leur modification passe inaperçue et/ou d'empêcher leur utilisation non
autorisée
[ISO 7498-2:1989, définition 3.3.20]
3.9
groupe de données
collection d'attributs de données EFC étroitement liés décrivant ensemble une partie distincte d'une
transaction EFC
3.10
intégrité des données
propriété assurant que des données n'ont pas été modifiées ou détruites de façon non autorisée
[ISO 7498-2:1989, définition 3.3.21]
3.11
élément
DSRC répertoire contenant des informations d'application sous la forme d'attributs
3.12
liste vide
contenant pour attributeValues (OCTET STRING) ayant une longueur de zéro
3.13
équipement embarqué
équipement installé dans un véhicule ou en dehors de celui-ci et utilisé à des fins de péage
NOTE Il n'est pas nécessaire que l'OBE contienne un moyen de paiement.
3.14
unité embarquée
composant minimal d'un équipement embarqué, dont la fonctionnalité comprend toujours au moins la prise en
charge de l'interface DSRC
3.15
opérateur
entité participant au processus en dehors de l'utilisateur
NOTE Terme générique; l'opérateur peut être un fournisseur de service de péage ou un organisme de facturation de
péage.
3.16
équipement d'infrastructures routières
équipement placé le long du réseau de transport routier, dont le but est la communication et les échanges de
données avec l'équipement embarqué
3.17
service
EFC installation associée au transport routier, fournie par un fournisseur de services, normalement un type
d'infrastructure, dont l'utilisation offerte à l'utilisateur peut demander un paiement
3.18
service primaire
communication service de communication élémentaire fourni par le protocole de la couche application aux
processus d'application
NOTE L'appel d'un service primaire par un processus d'application demande et utilise implicitement les services
offerts par les couches de protocole inférieures.
3.19
session
échange d'informations et interaction survenant à une station EFC spécifique entre l'équipement
d'infrastructures routières et l'utilisateur/le véhicule
3.20
organisme de facturation de péage
personne morale facturant le péage aux véhicules situés dans un secteur à péage
[ISO/TS 17574:2009, définition 3.27]
3.21
secteur à péage
domaine ou partie d'un réseau routier où est appliqué un régime de péage
[ISO 17573:2010, définition 3.18]
3.22
service de perception du télépéage
EFC service permettant aux utilisateurs ayant un seul contrat et un ensemble d'équipements embarqués
(OBE) d'utiliser un véhicule dans un ou plusieurs secteurs à péage
NOTE Adapté de l'ISO/TS 12813:2009.
4 © ISO 2011 – Tous droits réservés

3.23
fournisseur de service de perception du télépéage
EFC personne morale fournissant des services de perception du télépéage à ses clients dans un ou
plusieurs secteurs à péage pour une ou plusieurs classes de véhicule
NOTE 1 Dans d'autres documents, le terme émetteur ou émetteur de contrat peut être utilisé.
NOTE 2 Le fournisseur de service de perception du télépéage peut délivrer l'OBE ou peut ne délivrer qu'une carte
magnétique ou une carte à puce destinée à être utilisée avec l'OBE fournie par une tierce partie (de même qu'une carte
de téléphone portable et une carte SIM peuvent être obtenues auprès de parties différentes).
NOTE 3 Le fournisseur de service de perception du télépéage est responsable de l'exploitation (du fonctionnement) de
l'OBE.
[ISO/TS 17574:2009, définition 3.28]
3.24
transaction
totalité de l'échange d'informations entre l'équipement d'infrastructures routières et l'équipement embarqué,
nécessaire pour réaliser une opération d'EFC sur la DSRC
3.25
modèle de transaction
modèle fonctionnel décrivant la structure générale des transactions de collecte de péage par paiement
électronique
3.26
utilisateur
client d'un fournisseur de service de péage, assujetti au péage, propriétaire du véhicule, opérateur d'une flotte,
conducteur, etc., selon le contexte
4 Termes abrégés
Pour les besoins du présent document, les termes abrégés suivants s'appliquent, sauf indication contraire.
4.1
APDU
Unité de données de protocole d'application (Application Protocol Data Unit)
4.2
AP
Processus d'application (Application Process)
4.3
ASN.1
Abstract Syntax Notation One (ISO/CEI 8824-1)
4.4
BST
Tableau de service de balises (Beacon Service Table)
4.5
CCC
Communication de contrôle de conformité
4.6
cf
Confirmation
4.7
DSRC
Communication dédiée à courte portée (Dedicated Short-Range Communication)
4.8
EID
Identifiant d'élément (Element Identifier)
4.9
EFC
Perception du télépéage (Electronic Fee Collection)
4.10
GPS
Système mondial de positionnement (Global Positioning System)
4.11
ICC
Carte à circuit(s) intégré(s) [Integrated Circuit(s) Card]
4.12
I-Kernel
Noyau d'initialisation (Initialisation Kernel)
4.13
IID
Identifiant du demandeur (Invoker Identifier)
4.14
ind
Indication
4.15
LAC
Communication de complément de localisation (Localisation Augmentation Communication)
4.16
L1
Couche 1 (Layer 1) de la DSRC (Couche physique)
4.17
L2
Couche 2 (Layer 2) de la DSRC (Couche liaison de données)
4.18
L7
Noyau de la couche (layer) application de DSRC
4.19
LID
Identifiant de contrôle de liaison logique (Logical Link Control Identifier)
4.20
LLC
Contrôle de liaison logique (Logical Link Control)
4.21
LPDU
Unité de données de protocole de LLC (LLC Protocol Data Unit)
6 © ISO 2011 – Tous droits réservés

4.22
MAC
Contrôle d'accès au support (Medium Access Control)
4.23
MMI
Interface homme-machine (Man-Machine Interface)
4.24
n.a.
Non applicable
4.25
OBE
Équipement embarqué (On-Board Equipment)
4.26
PDU
Unité de données de protocole (Protocol Data Unit)
4.27
PER
Règles de codage compact (Packed Encoding Rules) (ISO/CEI 8825-2)
4.28
req
Demande (Request)
4.29
rs
Réponse
4.30
RSE
Équipement d'infrastructures routières (Roadside Equipment)
4.31
RTTT
Télématique pour le transport et le trafic routier (Road Transport and Traffic Telematics)
4.32
SAM
Module d'application sécurisé (Secure Application Module)
4.33
T-APDU
Unité de données de protocole d'application de transfert (Transfer-Application Protocol Data Unit)
4.34
T-ASDU
Unité de données de service d'application de transfert (Transfer-Application Service Data Unit)
4.35
T-Kernel
Noyau de transfert (Transfer Kernel)
4.36
VST
Tableau de service de véhicules (Vehicle Service Table)
5 Architecture d'interface d'application EFC
5.1 Relation avec l'architecture de communication de DSRC
Les services de DSRC sont fournis à un processus d'application au moyen des primitives de service de la
couche application de DSRC, qui sont des interactions de mise en œuvre abstraite entre un utilisateur de
service de communication et un fournisseur. Les services sont offerts par les entités de communication de
DSRC au moyen de sa couche application de DSRC (EN 12834/ISO 15628).
RSU OBU
AP ADU AP
NotifyApplicationRSU NotifyApplicationOBU
GET GET
SET
SET
EndApplication RegisterApplicationOBU
ACTION ACTION
RegisterApplicationRSU DeregisterApplication
.request .response .indication
.confirm
DeregisterApplication EndApplication
B-Kernel B-Kernel
I-Kernel I-Kernel
n.a. pour n.a. pour
l’EFC l’EFC
DSRC-L7 DSRC-L7
T-Kernel
T-APDU T-Kernel
Sous-couche LLC Sous-couche LLC
LPDU
DSRC-L2 DSRC-L2
Sous-couche MAC Sous-couche MAC
DSRC-L1 Couche physique
PPDU Couche physique DSRC-L1
Figure 2 — Processus d'application EFC au-dessus de la pile de communication de DSRC
NOTE Les abréviations utilisées à la Figure 2 sont définies à l'Article 4.
Le noyau de transfert de la couche application de DSRC offre les services suivants aux processus
d'application (voir également Figure 2 ci-dessus):
 GET: L'appel d'une demande de service GET produit une récupération (c'est-à-dire, une lecture)
d'informations d'application (c'est-à-dire, d'attributs) de l'utilisateur du service pair (c'est-à-dire, le
processus d'application d'OBE), une réponse est toujours attendue.
 SET: L'appel d'une demande de service SET produit une modification (c'est-à-dire, une écriture)
d'informations d'application (c'est-à-dire, d'attributs) de l'utilisateur du service pair (c'est-à-dire, le
processus d'application d'OBE). Le service peut être demandé en mode confirmé ou non confirmé, une
réponse n'est attendue que dans le premier cas.
 ACTION: L'appel d'une demande de service ACTION produit l'exécution d'une action par l'utilisateur du
service pair (c'est-à-dire, le processus d'application d'OBE). En outre, une action est qualifiée par la
valeur d'ActionType. Le service peut être demandé en mode confirmé ou non confirmé, une réponse n'est
attendue que dans le premier cas.
8 © ISO 2011 – Tous droits réservés

 EVENT-REPORT: L'appel d'une demande de service EVENT-REPORT achemine une notification d'un
événement à l'utilisateur du service pair.
 INITIALISATION: L'appel d'une demande de service d'initialisation par le RSE produit une tentative
d'initialisation de communication entre un RSE et chaque OBE n'ayant pas encore établi de
communication avec le RSE concerné. Le service d'initialisation n'est utilisé que par le noyau
d'initialisation, comme défini dans l'EN 12834/ISO 15628.
5.2 Utilisation de la couche d'application de DSRC par l'interface d'application de l'EFC
L'EFC utilise les services suivants offerts par la couche application de DSRC (comme défini dans
l'EN 12834/ISO 15628).
 Les services INITIALISATION:
 Notification d'application RSU (au RSE);
 Fin d'application (au RSE);
 Enregistrement d'application RSU (au RSE);
 Résiliation d'application RSU (au RSE et à l'OBE);
 Notification d'application OBU (à l'OBE);
 Enregistrement d'application OBU (à l'OBE)
sont utilisés pour réaliser le mécanisme d'initialisation spécifique à l'EFC (voir Article 6);
 Le service GET est utilisé pour récupérer les attributs d'EFC (pour les spécifications des attributs, voir
Article 8);
 Le service SET est utilisé pour fixer les attributs d'EFC;
 Les services ACTION sont appliqués pour réaliser une fonctionnalité spécifique supplémentaire d'EFC
nécessaire pour prendre en charge les processus d'application d'EFC, par exemple
TRANSFER_CHANNEL, SET_MMI et ECHO (voir 7.2).
L'utilisation spécifique à l'EFC des services de la couche 7 de DSRC est spécifiée ci-dessous en détail.
NOTE Le service EVENT-REPORT peut être utilisé implicitement par les processus d'application d'EFC. Il est utilisé
par exemple indirectement en tant que partie d'une commande déjà définie pour libérer un processus d'application (voir
l'EN 12384/ISO 15628, Ready Application). Toutefois, le service EVENT-REPORT n'étant pas utilisé explicitement par les
processus d'application d'EFC, il n'est plus fait référence à ce service dans la présente Norme internationale.
5.3 Adressage des attributs d'EFC
5.3.1 Mécanisme de base
Les attributs d'EFC sont utilisés pour transférer les informations spécifiques à une application d'EFC.
Les attributs d'EFC sont constitués d'un ou plusieurs éléments de données de types ASN.1 spécifiés. Dans le
contexte de la présente Norme internationale, chaque élément de données est associé à un nom sans
ambiguïté.
Un AttributeID est associé à chaque attribut d'EFC. L'AttributeId permet d'identifier et d'adresser sans
ambiguïté un attribut d'EFC.
EXEMPLE La Figure 3 illustre le mécanisme d'adressage de base.
Attribute ID AttrlD = 0 AttrlD = 2 AttrlD = 3 AttrlD = 4 AttrlD = n
Contract Contract Contract
…. ……….
Attribute
Validity Vehicle Authenticator
ContractAuthenticator ::=
ContractVehicle ::=
ASN.1-Type
ContractValidity ::= SEQUENCE {
contractRestrictions OCTET STRING (SIZE(4))
contractExpiryDate  DateCompact
}
Figure 3 — Mécanisme d'adressage de base
5.3.2 Rôle de l'EID
Dans un OBE donné, le DSRC-EID (différent de 0) est utilisé pour identifier un contexte d'EFC, donné par
l'EFC-ContextMark (voir 6.2.3), dans lequel les attributs peuvent être adressés sans ambiguïté par
AttributeIDs au sein d'un élément de l'OBE. Dans le VST, l'OBE spécifie plusieurs de ces contextes d'EFC,
correspondant chacun à un ensemble d'attributs d'EFC et de fonctions d'EFC qu'il prend en charge.
EXEMPLE
AttrlD = 0 AttrlD = 2 AttrlD = 3 AttrlD = 4 AttrlD = n
Contract Contract Contract
…. ……….
EID = 1 Validity Vehicle Authenticator
A A A
Contract Contract Contract
…. ……….
EID = 2 Validity Vehicle Authenticator
B B B
Contract Contract Contract
…. ……….
Validity Vehicle Authenticator
EID = 3
C C C
Figure 4 — Rôle de l'EID
Un EID égal à 0 doit être utilisé pour adresser des fonctions et des composants indépendants de l'application,
par exemple SET_MMI et TRANSFER_CHANNEL (voir 7.2).
5.3.3 Instances multiples d'attributs
Il peut y avoir n instances d'un attribut disponibles dans un OBE, n étant un entier.
Le nombre maximal d'instances N d'un attribut peut être limité en fonction des besoins des opérateurs et
max
des utilisateurs. Le nombre maximal d'instances par défaut est N = 1. La valeur de N est déterminée au
max max
moment de la configuration de l'OBE.
10 © ISO 2011 – Tous droits réservés

EXEMPLE
AttrlD = 0 AttrlD = 5 AttrlD = n
ReceiptServicePart2
………. ……….
ReceiptServicePart 1
EID = 1
ReceiptServicePart 0
Figure 5 — Instances multiples (0 à 2) de l'attribut 5
Le traitement d'instances multiples et le mécanisme d'adressage correspondant sont décrits en détail dans
une partie de la spécification de comportement des fonctions correspondantes prenant en charge des
instances multiples (voir 7.2.6 pour GET_INSTANCE et 7.2.7 pour SET_INSTANCE).
5.4 Adressage des composants
Les composants d'un OBE devant être adressés par l'intermédiaire de l'interface d'application d'EFC
comportent par exemple:
 OBU;
 SAM 1;
 SAM 2;
 ICC;
 Afficheur;
 Bruiteur;
 Imprimante;
 Interface série;
 Interface parallèle;
 GPS;
 Tachygraphe;
 Bluetooth.
L'adressage de ces composants s'effectue à deux niveaux, adressage spécifique au dispositif et adressage
indépendant du dispositif.
Le mécanisme d'adressage transparent spécifique au dispositif permet le transfert d'informations, qui
doivent être traitées par le dispositif adressé (par exemple une commande ICC). Le dispositif adressé est
identifié par un channel Id. La fonction d'EFC TRANSFER_CHANNEL (voir 7.2.10) prend en charge cette
fonctionnalité.
EXEMPLE 1 Transfert d'une chaîne de bits vers un ICC.
Le mécanisme d'adressage indépendant du dispositif utilise un jeu de commandes qui décrivent une
certaine fonctionnalité qui peut être exécutée par divers composants d'OBE. Dans ce cas, le système
d'exploitation de l'OBE adresse les composants correspondants. La fonction d'EFC SET_MMI (voir 7.2.12)
prend en charge cette fonctionnalité.
EXEMPLE 2 L'appel d'une fonction SET_MMI(EID = 0, ContactOperator) active un dispositif MMI d'OBE, par exemple
un bruiteur ou un afficheur.
NOTE Dans une mise en œuvre spécifique, des attributs ou des éléments de données spécifiques peuvent activer
une fonction MMI (par exemple, une commande SET sur l'attribut ReceiptText peut afficher le texte sur un afficheur à
cristaux liquides. Une commande SET sur l'attribut ReceiptServicePart avec l'élément de données
SessionResultOperational différent de SessionOK peut activer un bip d'avertissement). Les mécanismes d'adressage
propriétaires ne sont pas définis par la présente Norme internationale.
6 Modèle de transaction d'EFC
6.1 Généralités
Le modèle de transaction d'EFC associé à l'interface d'application d'EFC pour la DSRC comprend deux
phases, la phase d'initialisation et la phase de transaction.
NOTE L'objectif de la phase d'initialisation est d'établir la communication entre le RSE et les OBE qui ont pénétré
dans la zone de DSRC mais qui n'ont pas encore établi de communication avec le RSE, et d'en avertir les processus
d'application. Elle fournit entre autres un mécanisme de commutation multi-application pour exécuter plusieurs
applications de RTTT (en parallèle) dans une station de RSE.
La phase de transaction ne peut être atteinte qu'après la fin de la phase d'initialisation. Les fonctions d'EFC,
telles que définies à l'Article 7, peuvent être exécutées dans la phase de transaction. Les services GET et
SET (fonctions de la couche application de DSRC), comme définis dans l'EN 12834/ISO 15628 (en 6.2),
peuvent également être utilisés dans une phase de transaction d'EFC.
6.2 Phase d'initialisation
6.2.1 Vue d'ensemble
Cet article fournit une vue d'ensemble de la fonctionnalité de la phase d'initialisation et des échanges
d'informations dans celle-ci.
Les procédures d'initialisation, au moyen des échanges du tableau de service de balises (BST) et du tableau
de service de véhicules (VST) sont définies dans l'EN 12834/ISO 15628, 6.2.2 et 6.2.3 ci-dessous pour les
informations spécifiques à l'application d'EFC qui doivent être respectivement incluses dans le BST et le VST.
NOTE L'OBE évalue le BST reçu et choisit les applications qu'il souhaite exécuter dans les listes d'applications
prises en charge par le BSE. Si l'OBE ne prend en charge aucune des applications prises en charge par le RSE, il est
alors recommandé que l'OBE n'échange aucune information avec le RSE. Si l'OBE prend en charge au moins l'une des
applications prises en charge par le RSE, il est alors recommandé que l'OBE informe le RSE des applications qu'il
souhaite exécuter dans son VST correspondant.
12 © ISO 2011 – Tous droits réservés

RSE OBE
Application
Application
Couche 7 Couche 7
EFC
EFC
I-Kernel T-Kernel I-Kernel T-Kernel
RegisterApplication
INIT.rq(BST) RegAppVehicle
Beacon
T-APDU(INIT.rq(BST))
BST
INIT.ind(BST)
NotifyApplication
Vehicle
T-APDU(INIT.rs(VST))
INIT.cf(VST)
VST
NotifyApplication
Beacon
Figure 6 — Phase d'initialisation: échanges BST - VST
Le service d'initialisation associé à la phase d'initialisation n'est utilisé que par le noyau d'initialisation (de
l'EN 12834/ISO 15628), qui est lui-même configuré par la ou les applications souhaitant exécuter des
applications sur une liaison de DSRC. Les noyaux d'initialisation du RSE et de l'OBE concerné doivent avoir
été configurés selon l'EN 12834/ISO 15628, avant appel du service d'initialisation par le RSE.
6.2.2 Contenu du BST spécifique à une application d'EFC
Un RSE prenant en charge l'EFC doit avoir configuré son noyau d'initialisation pour comporter les
informations suivantes associées spécifiquement à la ou aux applications d'EFC:
 l'identifiant d'application (AID) doit être égal à 1 (c'est-à-dire la valeur assignée pour l'EFC);
 l'application d'EFC doit être qualifiée comme une application obligatoire;
 l'EID ne doit pas être transmis dans le BST associé à l'application d'EFC;
 aucun paramètre ne doit être transmis dans le BST associé à l'application d'EFC.
NOTE 1 AID égal à 14 identifie le contexte de paiement polyvalent. Au Japon, l'ISO 14906 spécifie l'interface
d'application pour la DSRC utilisée pour le paiement polyvalent (lorsque AID = 14 est utilisé au Japon, l'EID et les champs
de paramètres sont définis par l'intermédiaire du BST).
Une seule application d'EFC doit être présente dans le BST (c'est-à-dire qu'il ne doit y avoir qu'une seule
instance d'AID = 1 dans le BST) sans tenir compte du fait que le RSE prend en charge plusieurs
EFC-ContextMark (voir également 6.2.3).
NOTE 2 Ce qui précède est le contenu du BST spécifique à une application d'EFC. Le BST complet est défini dans
l'EN 12834/ISO 15628 et est fourni ci-dessous pour faciliter la lisibilité de la présente Norme internationale.
BST::= SEQUENCE {
beacon BeaconID,
time Time,
profile Profile,
mandApplications ApplicationList,
nonmandApplications ApplicationList OPTIONAL,
profileList SEQUENCE(0.127,.) OF Profile
}
where
ApplicationList::= SEQUENCE (0.127,.) OF
SEQUENCE{
aid DSRCApplicationEntityID, -- AID=1
eid Dsrc-EID OPTIONAL, -- vide
parameter Container OPTIONAL -- vide
}
6.2.3 Contenu du VST spécifique à une application d'EFC
Chaque application d'EFC et le contrat correspondant doivent être associés à un EFC-ContextMark, comme
défini ci-dessous. Un OBE peut prendre en charge plusieurs applications d'EFC.
NOTE 1 La définition de l'ordre dans lequel les EFC-ContextMarks doivent être présentés pour indiquer un ordre de
préférence de l'utilisateur, dans le cas où son OBE prend en charge plusieurs applications d'EFC ne fait pas partie du
domaine d'application de la présente Norme internationale. De telles règles pour indiquer l'ordre de préférence de
l'utilisateur peuvent faire l'objet d'accords entre opérateurs.
Un OBE prenant en charge l'EFC doit avoir configuré son noyau d'initialisation pour comporter les
informations suivantes associées spécifiquement à l'application d'EFC concernée:
 AID doit être égal à 1;
 la valeur d'EID doit être associée logiquement à l'EFC-ContextMark correspondant, contenu dans le
paramètre et doit être unique dans l'OBE dans l'ensemble de la session de DSRC;
 le paramètre doit être un OCTET STRING de type Container CHOICE et doit comprendre
l'EFC-ContextMark tel que défini ci-dessous et il peut également être configuré pour comporter d'autres
attributs d'EFC (comme défini à l'Article 8 et à l'Annexe A).
EFC-ContextMark::=SEQUENCE{
ContractProvider Provider,
TypeOfContract OCTET STRING (SIZE(2)),
ContextVersion INTEGER(0.127,.)
}
EFC-ContextMark indique un contexte d'EFC spécifique dans l'OBE, comprenant l'organisme qui a délivré le
contrat, le type de contrat et la version de contexte. ContractProvider, TypeOfContract et ContextVersion sont
définis de façon plus détaillée à l'Article 8 comme éléments de données d'Attribute EFC-ContextMark.
14 © ISO 2011 – Tous droits réservés

NOTE 2 Ce qui précède est le contenu du VST spécifique à une application d'EFC. Le VST complet est défini dans
l'EN 12834/ISO 15628 et est fourni ci-dessous pour faciliter la lisibilité du présent document.
VST::=  SEQUENCE {
fill BIT STRING (SIZE(4))
profile Profile,
applications ApplicationList,
obeConfiguration ObeConfiguration
}
where:
ApplicationList::= SEQUENCE (0.127,.) OF
SEQUENCE{
aid DSRCApplicationEntityID, -- AID =1
eid Dsrc-EID OPTIONAL, -- EID = par exemple 2
parameter Container OPTIONAL -- EFC-ContextMark
-- plus tout EFC Attribute
}
NOTE 3 Moyens pour assurer la compatibilité ascendante et la coexistence:
 Module EfcModule ASN.1, incluant un numéro de version
 Efc-ContextMark (incluant ContextVersion), représentant la version de mise en œuvre, fournit un moyen pour
garantir la coexistence de différentes versions de mise en œuvre au moyen d'un tableau de correspondance et du
traitement de transactions appropriées associées.
NOTE 4 AID égal à 14 identifie le contexte de paiement polyvalent. Au Japon, l'ISO 14906 spécifie l'interface
d'application pour DSRC utilisée pour le paiement polyvalent (lorsque AID = 14 est utilisé au Japon, l'EID et les champs
de paramètres sont définis par l'intermédiaire du BST).
NOTE 5 Un fournisseur d'application d'EFC conserve le contrôle final de son domaine de sécurité, c'est-à-dire le
niveau de sécurité et les mécanismes de sécurité associés à utiliser dans son système.
L'élément de données obeStatus contenu dans l'élément de données obeConfiguration doit toujours être
présent et peut indiquer l'état de la batterie de l'OBE. Cette information peut être utilisée par le RSE pour
avertir le conducteur (e
...