ISO 14906:2018
(Main)Electronic fee collection — Application interface definition for dedicated short-range communication
Electronic fee collection — Application interface definition for dedicated short-range communication
This document 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
Le présent document 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).
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 14906
Third edition
2018-10
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 2018
© ISO 2018
All rights reserved. Unless otherwise specified, or required in the context of its implementation, 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
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2018 – All rights reserved
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 2
3 Terms and definitions . 2
4 Abbreviated terms . 4
5 EFC application interface architecture . 5
5.1 Relation to the DSRC communication architecture . 5
5.2 Usage of DSRC application layer by the EFC application interface . 7
5.3 Addressing of EFC attributes . 7
5.3.1 Basic mechanism . 7
5.3.2 Role of the EID . 8
5.3.3 Multiple Instances of Attributes . 8
5.4 Addressing of components . 9
6 EFC Transaction Model .10
6.1 General .10
6.2 Initialisation Phase .10
6.2.1 Overview .10
6.2.2 EFC application-specific contents of the BST .11
6.2.3 EFC application-specific contents of the VST .12
6.3 Transaction phase .13
7 EFC functions .14
7.1 Overview and general concepts .14
7.1.1 EFC functions and service primitives .14
7.1.2 Overview of EFC functions .15
7.1.3 Handling of multiple instances .16
7.1.4 Security .18
7.2 EFC functions .21
7.2.1 General.21
7.2.2 GET_STAMPED .21
7.2.3 SET_STAMPED .22
7.2.4 GET_SECURE .23
7.2.5 SET_SECURE .24
7.2.6 GET_INSTANCE .25
7.2.7 SET_INSTANCE . .25
7.2.8 GET_NONCE . .26
7.2.9 SET_NONCE .27
7.2.10 TRANSFER_CHANNEL .27
7.2.11 COPY .28
7.2.12 SET_MMI .29
7.2.13 SUBTRACT .29
7.2.14 ADD . .30
7.2.15 DEBIT .30
7.2.16 CREDIT .31
7.2.17 ECHO .32
8 EFC Attributes .33
8.1 General .33
8.2 Data group CONTRACT .35
8.3 Data group RECEIPT .38
8.4 Data group VEHICLE .44
8.5 Data group EQUIPMENT .51
8.6 Data group DRIVER .53
8.7 Data group PAYMENT .55
Annex A (normative) EFC data type specifications .57
Annex B (informative) CARDME transaction .58
Annex C (informative) Examples of EFC transaction types .92
Annex D (normative) Mapping table from LatinAlphabetNo2 & 5 to LatinAlphabetNo1 .104
Annex E (informative) Mapping table between EFC Vehicledata attribute and European
registration certificate .105
Annex F (normative) Security calculations for DES .108
Annex G (informative) Security computation examples for DES .113
Annex H (normative) Security calculations for AES .116
Annex I (informative) Security computation examples for AES .121
Bibliography .123
iv © ISO 2018 – All rights reserved
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.
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 ISO documents 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 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 voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following
URL: www .iso .org/iso/foreword .html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
This third edition cancels and replaces the second edition (ISO 14906:2011), which has been technically
revised. It also incorporates the Corrigendum ISO 14906:2011/Cor1: 2013 and the Amendment
I S O 14906:2011/A md1: 2015 .
The main changes compared to the previous edition are as follows:
— Inclusion of security calculations according to advanced encryption standard, as recommended in
CEN/TR 16968 on security mechanisms (revision of Clause 7 and new Annexes F, G, H and I);
— Update of the normative references, terms and definitions and abbreviated terms clauses and the
Bibliography;
— Conversion of the ASN.1 module into an electronic insert;
— Revision of Annex C;
— Removal of Annex D (informative) on functional requirements.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
Introduction
This document specifies an application interface for electronic fee collection (EFC) systems, which
is based on dedicated short-range communication (DSRC). It supports interoperability between
EFC systems on an EFC-DSRC application interface level. This document 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 document 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 document. 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 document provides the basis for agreements between operators, which are needed to achieve
interoperability. Based on the tools specified in this document, 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 edition of this document, 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 introduced by this
edition of ISO 14906.
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 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.
vi © ISO 2018 – All rights reserved
Annex E presents an informative mapping table between EFC vehicle data attributes and European
registration certificates to ease the task of a service provider in the OBE personalisation with vehicle data.
Annex F presents the security calculations according to the data encryption standard (DES). This annex
is based on EN 15509:2014, Annex B.
Annex G presents the security computations examples for DES. This annex is based on EN 15509:2014,
Annex E.
Annex H presents the security calculations for advanced encryption standard (AES). This annex is the
adaptation of EN 15509:2014, Annex B for the case of AES.
Annex I presents the security computations examples for AES. This annex is the adaptation of
EN 15509:2014, Annex E for the case of AES.
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 document can also be used for on-board account
systems, in conjunction with ISO 25110, which provides examples of systems based on on-board
accounts.
INTERNATIONAL STANDARD ISO 14906:2018(E)
Electronic fee collection — Application interface definition
for dedicated short-range communication
1 Scope
This document 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 document 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.
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 primarily concerned with the implementation choices to be realised at
either side of the interface.
This document 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 document.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements 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
ISO/IEC 7812-1, Identification cards — Identification of issuers — Part 1: Numbering system
ISO/IEC 8825-2, Information technology — ASN.1 encoding rules: Specification of Packed Encoding Rules
(PER) — Part 2
ISO/IEC 9797-1:2011, Information technology — Security techniques — Message Authentication Codes
(MACs) — Part 1: Mechanisms using a block cipher
ISO 14816:2005, Road transport and traffic telematics — Automatic vehicle and equipment identification —
Numbering and data structure
ISO 15628:2013, Intelligent transport systems — Dedicated short range communication (DSRC) — DSRC
application layer
ISO/IEC 18033-3:2010, Information technology — Security techniques — Encryption algorithms — Part 3:
Block ciphers
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.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http: //www .electropedia .org/
— ISO Online browsing platform: available at http: //www .iso .org/obp
3.1
access credentials
trusted attestation or secure module that establishes the claimed identity of an object or application
3.2
attribute
addressable package of data consisting of a single data element or structured sequences of data
elements
[SOURCE: ISO 17575-1:2016, definition 3.2]
3.3
authenticator
data, possibly encrypted, that is used for authentication
2 © ISO 2018 – All rights reserved
3.4
channel
information transfer path
[SOURCE: ISO 7498-2:1989, definition 3.3.13]
3.5
cryptography
principles, means and methods for the transformation of data in order to hide its information content,
prevent its undetected modification or prevent its unauthorized use
3.6
data group
class of closely related attributes
[SOURCE: ISO 17575-1:2016, definition 3.10]
3.7
data integrity
property that data has not been altered or destroyed in an unauthorised manner
3.8
Element
DSRC directory containing application information in the form of attributes
3.9
on-board equipment
all required equipment on-board a vehicle for performing required EFC functions and communication
services
3.10
on-board unit
single electronic unit on-board a vehicle for performing specific EFC functions and for communication
with external systems
3.11
roadside equipment
equipment located along the road, either fixed or mobile
3.12
toll charger
entity which levies toll for the use of vehicles in a toll domain
3.13
toll domain
area or part of a road network where a toll regime is applied
[SOURCE: ISO 17573:2010, definition 3.18]
3.14
toll service
service enabling users to pay toll
3.15
toll service provider
entity providing toll services in one or more toll domains
3.16
transaction
whole of the exchange of information between two physically separated communication facilities
[SOURCE: ISO 17575-1:2016, definition 3.21]
3.17
transaction model
functional model describing the structure of electronic payment transactions
4 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply unless otherwise specified.
AP Application Process
APDU Application Protocol Data Unit
ASN.1 Abstract Syntax Notation One (ISO/IEC 8824-1)
BST Beacon Service Table
CCC Compliance check communication
cf Confirm
DSRC Dedicated Short-Range communication
EFC Electronic Fee Collection
EID Element Identifier
GNSS Global Navigation Satellite System
ICC Integrated Circuit(s) Card
IID Invoker Identifier
I-Kernel Initialisation Kernel
ind Indication
L1 Layer 1 of DSRC (Physical Layer)
L2 Layer 2 of DSRC (Data Link Layer)
L7 Application Layer Core of DSRC
LAC Localisation Augmentation Communication
LID Logical Link Control Identifier
LLC Logical Link Control
LPDU LLC Protocol Data Unit
MAC Medium Access Control
MMI Man-Machine Interface
n.a. Not applicable
OBE On-Board Equipment
PDU Protocol Data Unit
PER Packed Encoding Rules (ISO/IEC 8825-2)
4 © ISO 2018 – All rights reserved
req Request
rs Response
RSE Roadside Equipment
SAM Secure Application Module
T-APDU Transfer-Application Protocol Data Unit
T-ASDU Transfer-Application Service Data Unit
T-Kernel Transfer Kernel
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) as shown in Figure 2.
Figure 2 — The EFC application process on top of the DSRC communication stack
NOTE The abbreviated terms 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.
— EVENT-REPORT: The invocation of an EVENT-REPORT service request forwards a notification of an
event to the peer service user.
6 © ISO 2018 – All rights reserved
— 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 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 document.
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 document, 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.
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 Figure 4 illustrates the role of the EID.
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 the OBE.
The maximum number of instances N of one Attribute may be limited according to the needs of
max
operators and users. The default maximum number of instances is N =1. The value of N is
max max
determined at the time of OBE configuration.
EXAMPLE Figure 5 illustrates multiple instances (0-2) of attribute 5.
8 © ISO 2018 – All rights reserved
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;
— GNSS;
— 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 can activate some MMI function (e.g.
a SET command on the attribute ReceiptText might display the text on a liquid crystal 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 document.
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 ITS 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 as shown in Figure 6.
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 the OBE should not exchange
any information with the RSE. If the OBE supports at least one of the application(s) supported by the RSE,
then the OBE should inform the RSE of which application it wishes to execute in its corresponding VST.
10 © ISO 2018 – All rights reserved
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 document:
BST :: = SEQUENCE{
rsu BeaconID,
time Time,
profile Profile,
mandApplications ApplicationList,
nonmandApplications ApplicationList OPTIONAL,
profileList SEQUENCE (SIZE(0.127,.)) OF Profile
}
where
ApplicationList :: = SEQUENCE (SIZE (0.127,.)) OF SEQUENCE {
aid DSRCApplicationEntityID, -- AID = 1
eid Dsrc-EID OPTIONAL, -- empty
parameter ApplicationContextMark 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 document 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 can 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 extensibility of the ContextVersion should not be used. ContextVersion is coded as a single octet.
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 document:
VST:: = SEQUENCE{
fill BIT STRING (SIZE(4)),
profile Profile,
applications ApplicationList,
obeConfiguration ObeConfiguration
}
12 © ISO 2018 – All rights reserved
where
ApplicationList ::= SEQUENCE (SIZE (0.127,.)) OF SEQUENCE {
aid DSRCApplicationEntityID, -- AID = 1
eid Dsrc-EID OPTIONAL, -- EID = e.g. 2
parameter ApplicationContextMark 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 that 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 the OBE via the DSRC interface, check the status of the battery and
signal this status 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 EF
...
NORME ISO
INTERNATIONALE 14906
Troisième édition
2018-10
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 2018
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2018
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, 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, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
Fax: +41 22 749 09 47
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii © ISO 2018 – Tous droits réservés
Sommaire Page
Avant-propos .v
Introduction .vi
1 Domaine d’application . 1
2 Références normatives . 2
3 Termes et définitions . 2
4 Abréviations . 4
5 Architecture d’interface d’application EFC . 5
5.1 Relation avec l’architecture de communication de DSRC . 5
5.2 Utilisation de la couche application de DSRC par l’interface d’application de l’EFC . 7
5.3 Adressage des attributs d’EFC . 7
5.3.1 Mécanisme de base . 7
5.3.2 Rôle de l’EID . 8
5.3.3 Instances multiples d’attributs . 8
5.4 Adressage des composants. 9
6 Modèle de transaction d’EFC .10
6.1 Généralités .10
6.2 Phase d’initialisation .10
6.2.1 Vue d’ensemble .10
6.2.2 Contenu du BST spécifique à une application d’EFC.11
6.2.3 Contenu du VST spécifique à une application d’EFC .12
6.3 Phase de transaction .13
7 Fonctions d’EFC .15
7.1 Vue d’ensemble et concepts généraux .15
7.1.1 Fonctions d’EFC et primitives de service .15
7.1.2 Vue d’ensemble des fonctions d’EFC.16
7.1.3 Traitement d’instances multiples .17
7.1.4 Sécurité .18
7.2 Fonctions d’EFC .22
7.2.1 Généralités .22
7.2.2 GET_STAMPED .22
7.2.3 SET_STAMPED .23
7.2.4 GET_SECURE .23
7.2.5 SET_SECURE .24
7.2.6 GET_INSTANCE .25
7.2.7 SET_INSTANCE . .26
7.2.8 GET_NONCE . .26
7.2.9 SET_NONCE .27
7.2.10 TRANSFER_CHANNEL .28
7.2.11 COPY .29
7.2.12 SET_MMI .29
7.2.13 SUBTRACT .30
7.2.14 ADD . .31
7.2.15 DEBIT .31
7.2.16 CREDIT .32
7.2.17 ECHO .33
8 Attributs d’EFC .34
8.1 Généralités .34
8.2 Groupe de données CONTRACT .35
8.3 Groupe de données RECEIPT .38
8.4 Groupe de données VEHICLE .44
8.5 Groupe de données EQUIPMENT .51
8.6 Groupe de données DRIVER .53
8.7 Groupe de données PAYMENT .55
Annexe A (normative) Spécifications de type de données d’EFC .57
Annexe B (informative) Transaction CARDME .58
Annexe C (informative) Exemples de types de transaction EFC .90
Annexe D (normative) Tableau de mappage de LatinAlphabetNo2 et 5 à LatinAlphabetNo1 .101
Annexe E (informative) Tableau de mappage entre l’attribut Vehicledata d’EFC et le
certificat d’immatriculation européen .102
Annexe F (normative) Calculs de sécurité pour DES .105
Annexe G (informative) Exemples de calculs de sécurité pour DES .110
Annexe H (normative) Calculs de sécurité pour AES .113
Annexe I (informative) Exemples de calculs de sécurité pour AES .118
Bibliographie .120
iv © ISO 2018 – Tous droits réservés
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 (IEC) en ce qui
concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier de prendre note des différents
critères d'approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir www
.iso .org/directives).
L'attention est attiré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. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l'élaboration du document sont indiqués dans l'Introduction et/ou dans la liste des déclarations de
brevets reçues par l'ISO (voir www .iso .org/brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un
engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions
spécifiques de l'ISO liés à l'évaluation de la conformité, ou pour toute information au sujet de l'adhésion
de l'ISO aux principes de l’Organisation mondiale du commerce (OMC) concernant les obstacles
techniques au commerce (OTC), voir le lien suivant: www .iso .org/iso/fr/avant -propos.
La norme ISO 14906 a été élaborée par le Comité technique ISO/TC 204, Systèmes de transport intelligent.
Cette troisième édition annule et remplace la deuxième édition (ISO 14906:2011), qui a fait l’objet d’une
révision technique. Elle prend en compte les rectificatifs ISO 14906:2011/Cor 1:2013 et l’amendement
ISO 14906:2011/Amd 1:2015.
Les principaux changements par rapport à l’édition précédente sont les suivants:
— Prise en compte des calculs de sécurité conformément à la norme de chiffrement avancé, comme
recommandé dans la norme CEN/TR 16968 sur les mécanismes de sécurité (révision de l’Article 7
et nouvelles Annexes F, G, H et I);
— Mise à jour des articles références normatives, termes et définitions, abréviations et de la
Bibliographie;
— Conversion du module ASN.1 en insert électronique;
— Révision de l’Annexe C;
— Suppression de l’Annexe D (informative) sur les exignces fonctionnelles.
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes
se trouve à l’adresse www .iso .org/fr/members .html.
Introduction
Le présent document 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). Il permet
l’interopérabilité entre installations EFC à un niveau donné d’interface d’application EFC-DSRC. Ce
document est destiné 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).
Le présent document 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 le présent document. 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).
Le présent document 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 cette édition, 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, qui comprend un numéro de version;
— Efc-ContextMark (y compris 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é. Cela permet au logiciel
du RSE de déterminer la version de l’OBE et sa capacité à prendre en charge les nouvelles fonctions
introduites par cette édition de l’ISO 14906.
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.
vi © ISO 2018 – Tous droits réservés
L’Annexe C donne des exemples informatifs de types de transaction EFC avec les fonctions et attributs
EFC spécifiés.
L’Annexe D 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 E 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 pour
la personnalisation d’un OBE avec des données de véhicule.
L’Annexe F présente les calculs de sécurité selon la norme de chiffrement des données (DES). Cette
annexe se base sur l’Annexe B de l’EN 15509:2014.
L’Annexe G présente les exemples de calculs de sécurité pour DES. Cette annexe se base sur l’Annexe E
de l’EN 15509:2014.
L’Annexe H présente les calculs de sécurité selon la norme de chiffrement avancée (AES). Cette annexe
est l’adaptation de l’Annexe B de l’EN 15509:2014 pour AES.
L’Annexe I présente les exemples de calculs de sécurité pour AES. Cette annexe est l’adaptation de
l’Annexe E de l’EN 15509:2014 pour AES.
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é. Le présent document peut également être utilisé pour des systèmes
de comptabilité embarquée, conjointement à l’ISO 25110, qui donne des exemples de systèmes basés sur
une comptabilité embarquée.
NORME INTERNATIONALE ISO 14906:2018(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
Le présent document 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. Le présent document 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.
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 essentiellement des choix de mise en
œuvre réalisés de part et d’autre de l’interface.
Le présent document 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 suivants sont mentionnés dans le texte de sorte qu'une partie ou la totalité de leur
contenu constitue les exigences 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éhicules 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 — Partie 1: Codes de pays
ISO 3779, Véhicules routiers — Numéro d'identification des véhicules (VIN) — Contenu et structure
ISO 4217, Codes pour la représentation des monnaies
ISO/IEC 7812-1, Cartes d'identification — Identification des émetteurs — Partie 1: Système de numérotation
ISO/IEC 8825-2, Technologies de l'information — Règles de codage ASN.1: Spécification des règles de
codage compact (PER) — Partie 2
ISO/IEC 9797-1:2011, Technologies de l'information — Techniques de sécurité — Codes d'authentification
de message (MAC) — Partie 1: Mécanismes utilisant un chiffrement par blocs
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:2013, Systèmes intelligents de transport — Communications spécialisées à courte portée
(DSRC) — Couche d'application DSRC
ISO/IEC 18033-3:2010, Technologies de l'information — Techniques de sécurité — Algorithmes de
chiffrement — Partie 3: Chiffrement par blocs
EN 12834:2003, Télématique de la circulation et du transport routier — Communication dédiée à courte
portée — Couche application
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent.
L'ISO et la CEI tiennent à jour des bases de données terminologiques destinées à la normalisation aux
adresses suivantes:
— IEC Electropedia: disponible sur http: //www .electropedia .org/
— Plate-forme de navigation en ligne de l'ISO: disponible à l'adresse http: //www .iso .org/obp
3.1
justificatifs d’accès
attestation de confiance ou module sécurisé établissant l’identité déclarée d’un objet ou d’une
application
2 © ISO 2018 – Tous droits réservés
3.2
attribut
paquet de données adressables consistant en un élément de données unique ou des séquences
structurées d’éléments de données
[SOURCE: ISO 17575-1:2016, définition 3.2]
3.3
authentifiant
données (pouvant être chiffrées) utilisées à des fins d’authentification
3.4
voie
chemin de transfert des informations
[SOURCE: ISO 7498-2:1989, définition 3.3.13]
3.5
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
[SOURCE: EN 15509:2014, définition 3.6]
3.6
groupe de données
classe d’attributs étroitement liés
[SOURCE: ISO 17575-1:2016, définition 3.10]
3.7
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
[SOURCE: ISO/TS 19299:2015, définition 3.28]
3.8
élément
répertoire DSRC contenant des informations d’application sous la forme d’attributs
3.9
équipement embarqué
tout équipement nécessaire à bord d’un véhicule pour l’exécution des fonctions requises de collecte du
télépéage et des services de communication
3.10
unité embarquée
appareil électronique simple installé à bord d’un véhicule servant à l’exécution des fonctions requises
de collecte du télépéage et à la communication avec les systèmes externes
3.11
équipement routier
équipement fixe ou mobile installé le long de la route
3.12
percepteur de péage
entité juridique qui collecte le péage dû pour la circulation des véhicules dans un secteur à péage
[SOURCE: ISO 17573:2010, définition 3.16]
3.13
secteur à péage
domaine ou partie d’un réseau routier où est appliqué un régime de péage
[SOURCE: ISO 17573:2010, définition 3.18]
3.14
service de perception du télépéage
service permettant aux utilisateurs de régler le péage
3.15
fournisseur de services de télépéage
entité juridique assurant des services de télépéage dans un ou plusieurs secteurs à péage
[SOURCE: ISO 17573:2010, définition 3.23 modifiée]
3.16
transaction
ensemble des échanges d’informations entre deux installations de communication physiquement
séparées
[SOURCE: ISO 17575-1:2016, définition 3.21]
3.17
modèle de transaction
modèle fonctionnel décrivant la structure des transactions de paiement électronique
4 Abréviations
Pour les besoins du présent document, les termes abrégés suivants s’appliquent, sauf indication
contraire.
AP Processus d’application (Application Process)
APDU Unité de données de protocole d’application (Application Protocol Data Unit)
ASN.1 Notation de syntaxe abstraite un (Abstract Syntax Notation One) (ISO/IEC 8824-1)
BST Tableau de service de balises (Beacon Service Table)
CCC Communication de contrôle de conformité
cf Confirmer
DSRC Communication dédiée à courte portée (Dedicated Short-Range Communication)
EFC Perception du télépéage (Electronic Fee Collection)
EID Identifiant d’élément (Element Identifier)
GNSS Géolocalisation et navigation par un système de satellites
ICC Carte à circuit(s) intégré(s) (Integrated Circuit(s) Card)
IID Identifiant du demandeur (Invoker Identifier)
I-Kernel Noyau d’initialisation (Initialisation Kernel)
ind Indication
4 © ISO 2018 – Tous droits réservés
L1 Couche 1 (Layer 1) de la DSRC (Couche physique)
L2 Couche 2 (Layer 2) de la DSRC (Couche liaison de données)
L7 Noyau de la couche (layer) application de DSRC
LAC Communication de complément de localisation (Localisation Augmentation Communication)
LID Identifiant de contrôle de liaison logique (Logical Link Control Identifier)
LLC Contrôle de liaison logique (Logical Link Control)
LPDU Unité de données de protocole de LLC (LLC Protocol Data Unit)
MAC Contrôle d’accès au support (Medium Access Control)
MMI Interface homme-machine (Man-Machine Interface)
n.a. Non applicable
OBE Équipement embarqué (On-Board Equipment)
PDU Unité de données de protocole (Protocol Data Unit)
PER Règles de codage compact (Packed Encoding Rules) (ISO/IEC 8825-2)
req Requête
rs Réponse
RSE Équipement d’infrastructures routières (Roadside Equipment)
SAM Module d’application sécurisé (Secure Application Module)
T-APDU Unité de données de protocole d’application de transfert (Transfer-Application Protocol
Data Unit)
T-ASDU Unité de données de service d’application de transfert (Transfer-Application Service Data Unit)
T-Kernel Noyau de transfert (Transfer Kernel)
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) comme le montre la
Figure 2.
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.
— 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.
6 © ISO 2018 – Tous droits réservés
5.2 Utilisation de la couche 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’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 (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 suite du
présent document.
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 du présent document, 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.
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 EFC ContextMark, ainsi que l’EID à utiliser pour adresser les attributs et
utiliser les fonctions d’EFC qu’il prend en charge.
EXEMPLE La Figure 4 illustre le rôle de l’EID.
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 l'OBE, n étant un entier.
Le nombre maximal d’instances N d’un attribut peut être limité en fonction des besoins des
max
opérateurs et des utilisateurs. Le nombre maximal d’instances par défaut est N =1. La valeur de N
max max
est déterminée au moment de la configuration de l’OBE.
EXEMPLE La Figure 5 illustre les instances multiples (0 à 2) de l’attribut 5.
8 © ISO 2018 – Tous droits réservés
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;
— GNSS;
— 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 le présent document.
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 ITS (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, comme le montre la Figure 6.
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 RSE.
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.
10 © ISO 2018 – Tous droits réservés
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 communication DSRC utilisée pour les paiements multi-usages (lorsque l’AID = 14 est utilisé
au Japon, les champs de l’EID et des paramètres sont définis via le 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é du présent document.
BST :: = SEQUENCE{
rsu BeaconID,
time Time,
profile Profile,
mandApplications ApplicationList,
nonmandApplications ApplicationList OPTIONAL,
profileList SEQUENCE (SIZE(0.127,.)) OF Profile
}
où
ApplicationList :: = SEQUENCE (SIZE (0.127,.)) OF SEQUENCE {
aid DSRCApplicationEntityID, -- AID = 1
eid Dsrc-EID OPTIONAL, -- empty
parameter ApplicationCo
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.