ISO 12813:2015

NORME ISO
INTERNATIONALE 12813
Première édition
2015-12-01
Perception du télépéage —
Communication de contrôle de
conformité pour systèmes autonomes
Electronic fee collection — Compliance check communication for
autonomous systems
Numéro de référence
©
ISO 2015
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2015, Publié en Suisse
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni utilisée
sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie, l’affichage sur
l’internet ou sur un Intranet, sans autorisation écrite préalable. Les demandes d’autorisation peuvent être adressées à l’ISO à
l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2015 – Tous droits réservés

Sommaire Page
Avant-propos .v
Introduction .vi
1 Domaine d’application . 1
2 Références normatives . 2
3 Termes et définitions . 3
4 Abréviations . 5
5 Architecture de l’interface d’application . 5
5.1 Généralités . 5
5.2 Services fournis . 6
5.3 Attributs . 6
5.4 Contexte de péage . 6
5.5 Utilisation des couches basses . 7
5.5.1 Piles de communication DSRC prises en charge . 7
5.5.2 Utilisation de la pile de communication CEN-DSRC . 7
6 Fonctions . 8
6.1 Fonctions en détail . 8
6.1.1 Généralités . 8
6.1.2 Initialisation de la communication . 8
6.1.3 Extraction des données . 8
6.1.4 Extraction des données authentifiées . 8
6.1.5 Notification du conducteur . 9
6.1.6 Arrêt de la communication . 9
6.1.7 Essai de la communication . 9
6.2 Sécurité . 9
6.2.1 Généralités . 9
6.2.2 Authentification/Non-répudiation.10
6.2.3 Identifiants d’accès .10
7 Attributs .10
7.1 Généralités .10
7.2 Données relatives à l’identification .12
7.3 Données relatives à l’état .12
7.4 Données relatives au véhicule.15
8 Modèle de transaction .17
8.1 Généralités .17
8.2 Phase d’initialisation .17
8.2.1 Requête d’initialisation .17
8.2.2 Contenu spécifique à l’application CCC sur la BST .17
8.2.3 Contenu spécifique à l’application CCC sur la VST .18
8.3 Phase de transaction .18
Annexe A (normative) Spécifications de types de données CCC .19
Annexe B (normative) Formulaire PICS pour les attributs .20
Annexe C (informative) Utilisation de la pile de communication ETSI/ES 200 674-1 pour les
applications CCC .28
Annexe D (informative) Utilisation de la pile de communication IR DSRC (CALM IR) pour les
applications CCC .31
Annexe E (informative) Utilisation de la pile de communication ARIB DSRCpour les
applications CCC .32
Annexe F (informative) Exemple de transaction CCC .34
Annexe G (informative) Considérations sur la sécurité .36
Annexe H (informative) Utilisation de la présente norme pour le SET .41
Bibliographie .43
iv © ISO 2015 – 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 (CEI) 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. 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 brevet. L’IEC et l’ISO ne sauraient être tenues pour responsables 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/patents).
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 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’OMC concernant les obstacles techniques au commerce (OTC), voir le lien suivant: Avant-propos -
Informations supplémentaires
Le comité technique responsable de ce document est le ISO/TC204, Systèmes intelligents de transport.
Cette première édition annule et remplace la Spécification technique ISO/TS 12813:2009 qui a fait
l’objet d’une révision technique. Cette première édition inclut les principales modifications suivantes:
— Passage d’une Spécification technique au stade de Norme internationale;
— Ajout de nouveaux attributs (TrailerCharacteristics, Attibute Updated Interval,
VehiculecurrentMaxTrainWeignt, VehiculeWeightHistory, ExtendedOBEStatusHistory,
ExtendedVehiculeAxlesHistory, et LocalVehiculeClassId);
— Intégration de corrections rédactionnelles en vue de refléter l’harmonisation de la terminologie
entre les normes du télépéage(EFC).
— Intégration de corrections rédactionnelles en vue de souligner les changements des normes de base
comme ISO 14906 et EN 15509.
— Ajout d’une nouvelle annexe informative (par exemple Annexe H) sur la façon d’utiliser les normes
internationales dans les services du télépéage européen.
− Intégration de corrections rédactionnelles et formelles, ainsi que de modifications pour améliorer
la lisibilité
Introduction
L’équipement embarqué (OBE, On-Board Equipment) qui s’appuie sur la technologie de localisation par
satellite pour collecter les données nécessaires au calcul de la redevance d’usage du réseau routier
fonctionne de manière autonome, autrement dit il repose sur une infrastructure routière dédiée.
L’équipement embarqué consigne le taux d’utilisation du réseau routier dans l’ensemble des systèmes
de péage par lesquels transitent les véhicules.
La présente Norme définit les exigences concernant les communications dédiées à courte portée (DSRC,
Dedicated Short-Range Communication) entre un équipement embarqué et un interrogateur destiné
à vérifier la correspondance entre les données d’usage du réseau routier et le régime de péage local.
Elle suppose une architecture de services de perception du télépéage (EFC, Electronic Fee Collection)
conforme à l’ISO 17573 (voir Figure 1).
Interoperability
management
Service
provision
Toll
charging
Compliance check
communication
Service usage
Figure 1 — Communication de contrôle de conformité dans une architecture EFC conforme à
l’ISO 17573
Les percepteurs de péage doivent vérifier que l’usage du réseau routier est conforme aux règles du
régime de péage local. Pour effectuer le contrôle de conformité, une méthode consiste à observer
un véhicule passant et à interroger l’équipement embarqué. Cette interrogation intervient sous le
contrôle d’une entité responsable du péage (voir Figure 1) et s’effectue via une communication dédiée
à courte portée entre un interrogateur résidant sur l’équipement routier (ou dans un autre véhicule) et
l’équipement embarqué. Dans un environnement interopérable, il est essentiel que ces communications
d’interrogation soient normalisées afin que chaque exploitant d’équipement de contrôle de conformité
puisse contrôler tous les équipements embarqués passants. Dans ce but, la présente Norme
internationale définit les attributs nécessaires sur l’ensemble des équipements embarqués afin de
permettre la lecture par un interrogateur.
La présente Norme a été élaborée en tenant compte des conditions prérequises répertoriées ci-
dessous de a) à e).
a) Les preuves collectées doivent être recevables devant les tribunaux. Les données doivent être
indiscutables et fiables de manière que l’exploitant de l’interrogateur de contrôle de conformité
puisse prouver l’intégrité et l’authenticité des données en cas de litige.
b) Les données exigibles aux fins de contrôle de conformité doivent être en lecture seule, l’exploitant
de l’interrogateur étant tenu de ne pas interférer avec le fonctionnement de l’équipement embarqué.
vi © ISO 2015 – Tous droits réservés

c) Tous les attributs doivent être présents dans l’équipement embarqué de sorte que l’exploitant
d’un interrogateur puisse lire les mêmes données que l’ensemble des équipements embarqués
indépendamment de leurs types et marques. Pour les cas où un attribut ne s’applique pas à la mise
en œuvre d’un équipement embarqué spécifique, la mention « non applicable » ou « non défini » est
fournie dans chaque cas.
d) Les attributs doivent être issus du régime de péage individuel et avoir une importance générale
pour tous les types de systèmes de péage (autoroutes, zones, ferries, ponts, tunnels, cordons, etc.).
e) Les attributs doivent s’appliquer à l’ensemble des architectures d’équipements embarqués,
notamment aux architectures client léger (« edge-light ») et lourd (« edge-heavy »). L’interrogateur
doit être capable de recevoir les mêmes informations, quelles que soient les décisions de mise en
œuvre concernant l’équipement embarqué.
On suppose que l’objectif principal de l’exploitant de l’interrogateur de contrôle de conformité est de
vérifier que l’usager a rempli ses obligations, plus particulièrement:
— si l’équipement embarqué est monté dans le véhicule adéquat;
— si les données de classification transmises par l’équipement embarqué sont correctes; et
— si l’équipement embarqué est en état de marche, d’un point de vue technique et contractuel.
En ce qui concerne le dernier point de la liste ci-dessus, pour l’état de fonctionnement de l’équipement
embarqué, on suppose le modèle suivant.
Aussi longtemps que l’équipement embarqué signale à l’usager un état de fonctionnement correct
(« vert »), le prestataire de services assume l’entière responsabilité du bon fonctionnement de
l’équipement embarqué et du paiement de la redevance par l’usager; par conséquent, aussi longtemps
que l’équipement embarqué signale un état de fonctionnement « vert » et que l’usager remplit toutes
ses autres obligations (telles que saisir les données de classification adéquates et ne pas modifier
l’équipement embarqué), l’usager peut s’attendre à utiliser l’équipement embarqué comme un
moyen de paiement valide. Aussi longtemps que l’équipement embarqué renvoie à l’usager un état de
fonctionnement incorrect (« rouge ») — défini par le système central du prestataire de services (ex:
compte de l’usager débiteur) ou par un dispositif interne de l’équipement embarqué lui-même (ex: du
fait d’un défaut détecté ou de données périmées), l’usager sait que l’équipement embarqué n’est plus un
moyen de paiement valide. L’usager doit alors recourir à un autre moyen de paiement du péage jusqu’à ce
1)
que l’incident soit résolu et que l’équipement embarqué ait retrouvé un état de fonctionnement « vert » .
En dernier ressort, il revient au prestataire de services de déterminer à partir de quel moment l’état de
fonctionnement d’un équipement embarqué est considéré comme « vert » ou « rouge ».
Au cas où l’équipement embarqué renvoie un état de fonctionnement « rouge », l’usager doit prendre une
mesure et s’acquitter des sommes redevables à l’aide d’un autre moyen de paiement le plus rapidement
possible. Tant qu’il ne l’a pas fait, l’usager se trouve dans une situation de non-conformité potentielle.
Afin de juger si l’usager a bel et bien pris la mesure adéquate dans un délai acceptable, la présente
Norme fournit non seulement des informations sur l’état de fonctionnement « vert »/« rouge » mais
également sur la durée pendant laquelle l’équipement embarqué est resté dans son état actuel.
Différents contextes de péage peuvent se chevaucher géographiquement. Un usager pourrait être
assujetti à plusieurs contextes de péage à la fois (ex: taxe de circulation nationale fondée sur la distance
parcourue et accès au centre-ville payant), ce dont l’utilisateur pourrait ne pas avoir connaissance dans
tous les cas. La présente Norme se base sur le fait qu’il n’existe pas de notion de contexte de péage
dans le contrôle de conformité (voir 5.4 plus précisément). Il est de la responsabilité du prestataire de
services de résoudre les problèmes de chevauchement de plusieurs contextes de péage et de présenter
l’ensemble des informations à l’usager sous la forme d’un message « rouge/vert » binaire.
1) Ici, les adjectifs « rouge » et « vert » sont utilisés de façon abstraite et au sens symbolique; ils n’impliquent
pas une quelconque mise en œuvre physique. La conception de l’interface utilisateur de l’équipement embarqué est
fonction de la mise en œuvre, et de nombreuses méthodes de signalement du mode de fonctionnement « rouge » ou
« vert » sont concevables.
L’exploitant de l’interrogateur de contrôle de conformité pourrait avoir comme objectif secondaire de
collecter les données relatives à la performance de l’équipement embarqué dans le but de vérifier son bon
fonctionnement technique par exemple. Étant donné que les équipements embarqués peuvent mettre
en œuvre des principes relativement différents, les possibilités de le faire de manière normalisée sont
relativement limitées. La présente Norme propose quelques dispositions concernant cette tâche (ex:
attributs CommunicationStatus, GnssStatus, DistanceRecordingStatus), mais on suppose néanmoins
que les percepteurs de péage veillent à un enregistrement correct en comparant la circulation observée
(ex: à l’aide de caméras) aux données d’utilisation transmises par les prestataires de services.
La présente Norme internationale a été élaborée avec l’intention de demeurer « minimaliste » dans le
sens où elle aborde les caractéristiques exigées par les systèmes d’exploitation et les systèmes prévus
dans un futur proche.
Une série de tests pour vérifier la conformité des implémentations des OBE ou RSE avec la première
édition de la Norme internationale est définie dans l’édition correspondante de l’ISO/TS 13141-1 et
ISO/TS 13143-2. Cette série de tests subit actuellement une mise à jour pour prendre en compte les
changements introduits dans la présente édition de l’ISO 12813.
viii © ISO 2015 – Tous droits réservés

NORME INTERNATIONALE ISO 12813:2015(F)
Perception du télépéage — Communication de contrôle de
conformité pour systèmes autonomes
1 Domaine d’application
La présente Norme définit les exigences relatives aux communications à courte portée aux fins de
contrôle de conformité dans les systèmes de perception du télépéage autonomes. La communication
de contrôle de conformité (CCC, Compliance Checking Communication) survient entre l’équipement
embarqué (OBE) d’un véhicule routier et un interrogateur externe (équipement routier, appareil mobile
ou dispositif portable) et permet de déterminer si les données fournies par l’équipement embarqué
reflètent correctement l’usage du réseau routier du véhicule correspondant selon les règles du régime
de péage applicable.
L’exploitant de l’interrogateur de contrôle de conformité est supposé occuper le rôle Perception du
péage défini dans l’ISO 17573. L’application CCC permet d’identifier l’équipement embarqué, le véhicule
et le contrat, de vérifier que le conducteur a bien rempli ses obligations et de déterminer l’état de
fonctionnement et la performance de l’équipement embarqué. L’application CCC lit, mais n’écrit pas les
données de l’équipement embarqué.
La présente Norme s’applique aux équipements embarqués autonomes; elle ne s’applique pas au
contrôle de conformité dans les systèmes de taxation reposant sur des communications dédiées à
courte portée (DSRC).
Elle définit la syntaxe et la sémantique des données, mais ne définit pas de séquence de communication.
Tous les attributs définis dans le présent document sont exigés dans tout équipement embarqué
revendiqué conforme à la présente Norme, même si certaines valeurs sont définies comme étant « non
définies » dans les cas où certaines fonctionnalités ne sont pas présentes dans un équipement embarqué
donné. L’interrogateur est libre de choisir quels attributs sont lus, ainsi que l’ordre dans lequel ils
sont lus. Afin de permettre la compatibilité avec les systèmes existants, la communication utilise les
attributs définis dans l’ISO 14906 dès que possible.
L’application CCC convient à une gamme de supports de communication à courte portée. Des définitions
spécifiques sont données pour la pile de communication CEN-DSRC spécifiée dans l’EN 15509, ainsi
que pour l’utilisation des piles ISO CALM IR, UNI DSRC et ARIB DSRC comme alternatives à CEN-
DSRC. Les attributs et fonctions définis sont destinés au contrôle de conformité via les services de
communication DSRC fournis par la couche DSRC 7, à l’aide des attributs et fonctions CCC mis à la
disposition des applications CCC sur l’équipement routier (RSE, Road-Side Equipment) et l’équipement
embarqué. Les attributs et fonctions sont définis au niveau des unités de données d’application (ADU,
Application Data Unit).
La définition de la communication CCC inclut:
— l’interface d’application entre l’équipement embarqué (OBE) et l’équipement routier (RSE) comme
décrit en Figure 2,
— l’utilisation de la couche d’application DSRC générique spécifiée dans l’ISO 15628 et l’EN 12834,
— l’utilisation de la pile de communication CEN-DSRC selon l’EN 15509 ou d’autres piles de
communication DSRC équivalentes comme décrit dans les Annexes C, D et E, et
— des services de sécurité dans le cadre de l’authentification mutuelle des partenaires de communication
et de la signature des données (voir Annexe G).
Les spécifications de types de données CCC sont données à l’Annexe A. Le formulaire de déclaration de
conformité d’une mise en œuvre de protocole (PICS, Protocol Implementation Conformance Statement)
est fourni à l’Annexe B. Un exemple de transaction CCC est présenté à l’Annexe F.
Les spécifications d’essai n’entrent pas dans le domaine d’application de la présente Norme (voir Figure 2).
OBE
RSE
Road-side CCC On-board CCC
application application
RSE CCC OBE CCC
function calls function calls
Scope of
DSRC functions ADU DSRC functions
this
International for CCC for CCC
Standard
Communication Communication
service primitives service primitives
DSRC communication services
Figure 2 — Interface d’application CCC
2 Références normatives
Les documents suivants, en totalité ou partie, sont référencés comme norme dans ce document et sont
indispensables à son application. 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/IEC 8824-1:2008, Technologies de l’information — Notation de syntaxe abstraite numéro un (ASN.1):
Spécification de la notation de base — Partie 1
ISO/IEC 8825-2:2008, Technologies de l’information — Règles de codage ASN.1: Spécification des règles de
codage compact (PER) — Partie 2
ISO 14906:2011/Amd.1: 2015, Perception du télépéage — Définition de l’interface d’application relative
aux communications dédiées à courte portée
ISO 15628:2013, Systèmes intelligents de transport — Communications spécialisé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 (disponible en anglais seulement)
2 © ISO 2015 – Tous droits réservés

EN 15509:2014, Perception de télépéage — Profil d’application d’interopérabilité pour DSRC
NIMA Technical Report TR8350.2, Department of Defense World Geodetic System 1984, Its Definition and
Relationships With Local Geodetic Systems (disponible en anglais seulement)
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent.
3.1
identifiants d’accès
attestation certifiée ou module sécurisé qui établit l’identité déclarée d’un objet ou d’une application
[SOURCE: EN 15509:2014, définition 3.1]
3.2
attribut
paquetage de données adressable constitué d’un seul élément de données ou de séquences structurées
d’éléments de données
3.3
authentification
mécanisme de sécurité permettant la vérification de l’identité fournie
[SOURCE: EN 301 175]
3.4
authentificateur
données (pouvant être chiffrées) qui sont utilisées à des fins d’authentification
[SOURCE: ISO/TS 19299:2015, définition 3.5]
3.5
intégrité des données
propriété indiquant que les données n’ont pas été altérées ni supprimées d’une manière non autorisée
[SOURCE: ISO/TS 19299:2015, définition 3.28]
3.6
équipement routier fixe
équipement routier situé à un poste fixe
3.7
équipement routier mobile
équipement fixé sur une unité mobile ou équipement portatif devant être utilisé le long de la route
3.8
équipement embarqué
OBE
tout équipement à bord d’un véhicule pour réaliser les fonctions EFC et les services de
communication requis
3.9
équipement routier
RSE
équipement fixe ou mobile situé le long de la route
3.10
service de péage
service EFC
service de paiement électronique proposé par un prestataire de services de paiement
[SOURCE: ISO 17573:2010]
3.11
primitive de service
communication des primitives de service
service de communication élémentaire fourni par le protocole de couche d’application aux processus
d’application
[SOURCE: ISO 14906:2011, définition 3.18, modifiée]
3.12
contexte de péage
vue logique définie par les attributs et fonctions des éléments de base d’un régime de péage se
caractérisant par un principe de recouvrement de base unique, une distribution spatiale des objets de
facturation et un comportement unique des systèmes frontaux associés
3.13
régime de péage
ensemble des règles, y compris de contrôle-sanction, applicable au recouvrement des péages dans un
secteur à péage
[SOURCE: ISO 17573:2010, définition 3.20]
3.14
transaction
intégralité de l’échange d’informations entre deux dispositifs de communication physiquement séparés
4 © ISO 2015 – Tous droits réservés

4 Abréviations
Pour les besoins du présent document, les abréviations suivantes s’appliquent.
AC_CR (ACcess CRedentials) Identifiants d’accès
ADU (Application Data Unit) Unité de données d’application (ISO 14906)
ASN.1 (Abstract Syntax Notation one) Notation de syntaxe abstraite numéro un
(ISO/IEC 8824-1)
BST (Beacon Service Table) Table de service des balises (ISO 14906)
CCC (Compliance Check Communication) Communication de contrôle de conformité
DSRC (Dedicated Short-Range Communication) Communication dédiée à courte portée
(ISO 14906)
EID (Element IDentifier) Identifiant d’élément (ISO 15628 et
(EN 12834)
EFC (Electronic Fee Collection) Perception du télépéage
GNSS/CN (Global Navigation Satellite System/ Système mondial de navigation par satellite
(SMNS)/réseau cellulaire
Cellular Network)
MAC (Media Access Control/Message Authentication Code) Contrôle d’accès au support (EN 12795)
ou code d’authentification de message
(ISO 14906)
OBE (On-Board Equipment) Equipement embarqué (ISO 14906)
PICS (Protocol Implementation Conformance Statement) Déclaration de conformité d’une mise en
œuvre de protocole
RSE (Road-Side Equipment) Equipement routier (ISO 14906)
TSP (Toll service provider) Prestataire de service de péage
VST (Vehicle Service Table) Table de service des véhicules (ISO 14906)
WGS84 (World Geodetic System 1984) Système géodésique mondial 1984
5 Architecture de l’interface d’application
5.1 Généralités
Le présent Article donne un aperçu de l’architecture CCC. Il identifie les services fournis aux
applications CCC, ainsi que les fonctions qui mettent en œuvre ces services. Il définit également les
principes concernant les attributs et l’utilisation des primitives de communication DSRC. Pour une
description détaillée des fonctions, se reporter à l’Article 6. Pour la liste détaillée des attributs, se
reporter à l’Article 7.
L’interface d’application CCC a été conçue pour utiliser la pile de communication CEN-DSRC via la couche
d’application spécifiée dans l’ISO 15628 et l’EN 12834. Pour les autres supports de communication DSRC
identifiés, des mappages détaillés avec les services correspondants sont donnés en annexes.
D’un point de vue général sur l’adressage, il convient de noter qu’un seul contexte CCC est utilisé étant
donné que les attributs d’application sont indépendants du contexte.
5.2 Services fournis
L’interface d’application CCC fournit les services suivants aux applications CCC:
— extraction des attributs ayant trait à la conformité pour permettre à l’équipement routier de valider
la conformité de l’équipement embarqué,
— authentification mutuelle de l’équipement routier et de l’équipement embarqué par le biais de
l’échange des identifiants, et
— envoi d’une commande à l’équipement embarqué pour signifier le résultat du contrôle de
conformité à l’usager.
NOTE 1 La décision de signaler ou non à l’usager le résultat du contrôle de conformité ou la survenue d’une
transaction appartient à l’entité exploitant l’interrogateur CCC et n’entre pas dans le cadre de la présente Norme.
Les services susmentionnés sont réalisés à partir d’échanges de protocole, effectués au moyen des
services de communication et des transactions décrits à l’Article 8.
Les services sont fournis par les fonctions suivantes:
— la fonction « initialisation de la communication » qui doit être utilisée pour établir la liaison de
communication CCC entre l’équipement routier et l’équipement embarqué;
— la fonction « extraction des données » qui est utilisée pour extraire les attributs CCC;
— la fonction « extraction des données authentifiées » qui doit être utilisée pour extraire les données
possédant un authentificateur à partir de l’équipement embarqué;
— la fonction « notification du conducteur » qui doit être utilisée pour appeler une fonction d’interface
homme/machine (IHM) (ex: signal « OK » via un avertisseur sonore);
— la fonction « arrêt de la communication » qui doit être utilisée pour mettre fin à la communication CCC;
— la fonction « essai de la communication » qui doit être utilisée pour soumettre à essai et localiser
l’équipement embarqué.
NOTE 2 Aucun service « écriture » n’est fourni, car il n’est pas prévu que les données soient écrites dans
l’équipement embarqué.
5.3 Attributs
Les attributs disponibles côté équipement embarqué pour une application CCC résidant sur l’équipement
routier dans le cadre du contrôle de la conformité d’un véhicule sont détaillés à l’Article 7.
Tous les attributs définis dans la présente Norme doivent être disponibles côté équipement embarqué.
L’équipement routier est libre de décider de lire n’importe quelle combinaison d’attributs à partir
de l’équipement embarqué. Les attributs doivent être identifiés et extraits à l’aide des mécanismes
définis dans l’ISO 14906. Plus précisément, l’adressage des données d’application CCC mises en
œuvre par l’équipement embarqué et l’équipement routier doit se conformer aux règles définies dans
l’ISO 14906:2011, 5.3.
Les instances multiples d’attributs ne sont pas prises en charge.
5.4 Contexte de péage
Un équipement embarqué peut résider dans plusieurs contextes de péage à la fois. Cela peut être le
cas, par exemple, lorsqu’un péage autoroutier chevauche géographiquement un système de taxation
de zone. Dans ces contextes de péage différents, l’équipement embarqué pourrait exécuter différentes
applications de taxation ou plusieurs instances d’une application de taxation en parallèle.
6 © ISO 2015 – Tous droits réservés

La présente Norme internationale se base sur le fait qu’il n’existe pas de distinction entre les contextes
de péage dans le contrôle de conformité. Les données applicables au contrôle de conformité (ex: identité
du véhicule, paramètres de classification et état de fonctionnement de l’équipement embarqué « rouge »
ou « vert ») sont indépendantes du contexte de péage. En outre, pour des raisons légales, l’usager doit
savoir s’il agit ou non dans le bon droit sans comprendre tous les détails techniques (comme le nombre
de contextes de péage se chevauchant à un moment donné, par exemple).
De ce fait, il n’existe qu’un seul contexte CCC et les concepts relatifs au contexte connus des systèmes de
taxation DSRC (ex: identification du contexte de péage via la marque de contexte EFC ou adressage d’un
contexte spécifique via un EID correspondant) ne sont pas nécessaires. Par conséquent, l’équipement
embarqué ne doit posséder qu’un seul contexte CCC, identifié par une valeur EID unique.
5.5 Utilisation des couches basses
5.5.1 Piles de communication DSRC prises en charge
L’interface d’application CCC utilise la pile de communication CEN-DSRC (voir Tableau 1). D’autres
supports de communication peuvent être utilisés parmi ceux répertoriés dans le Tableau 1 à condition
qu’un mappage équivalent avec les services correspondants soit fourni. Des exemples détaillés sont
donnés en annexes informatives.
Tableau 1 — Piles de communication DSRC prises en charge
Couche d’applica- Couches basses
Support Spécifications détaillées
tion
ISO 15628 EN 12795
CEN-DSRC Spécifications en 5.5.2
EN 12834 EN 12253
UNI 10607-4 UNI 10607-2
UNI DSRC (Italie) Exemple de mise en œuvre à l’Annexe C
UNI 10607-3 UNI 10607-1
ISO 15628
ISO CALM IR ISO 21214 Exemple de mise en œuvre à l’Annexe D
EN 12834
ARIB STD-T75 ARIB STD-T75
ARIB DSRC Exemple de mise en œuvre à l’Annexe E
ISO 15628 ITU-R.M1453-2
NOTE L’EN 12795 et l’EN 12253 ont été adoptées dans l’ITU-R.M 1453–2.
Si plus d’un support de communication est mis en œuvre dans un équipement embarqué, l’équipement
embarqué doit alors répondre aux interrogations de l’équipement routier sur le même support utilisé
par l’équipement routier.
5.5.2 Utilisation de la pile de communication CEN-DSRC
Les exigences suivantes s’appliquent à l’application CCC lorsqu’elle est utilisée avec la pile de
communication CEN-DSRC.
L’équipement embarqué doit se conformer à l’EN 15509:2014, Article 6.1.2.
L’équipement routier fixe doit se conformer à l’EN 15509:2014, Article 6.2.2.
L’équipement routier mobile doit se conformer à l’EN 15509:2014, 5.2.2, à l’exception du paramètre
Downlink D4a (il ne s’applique pas aux équipements routiers mobiles).
NOTE L’EN 15509 définit la pile de communication CEN-DSRC uniquement pour les équipements routiers fixes.
6 Fonctions
6.1 Fonctions en détail
6.1.1 Généralités
Toutes les fonctions définies en 6.1 doivent être disponibles côté équipement embarqué.
Pour la pile de communication CEN-DSRC, les fonctions doivent être fournies par:
— la couche d’application DSRC comme indiqué dans l’ISO 15628 et l’EN 12834 (services INITIALISATION,
GET et RELEASE);
— EFC correspondantes de l’ISO 14906 (fonctions GET_STAMPED, SET_MMI et ECHO).
Les paragraphes 6.1.2 à 6.1.7 définissent les fonctions applicables à la pile de communication CEN-DSRC
seulement. Pour les autres supports pris en charge selon 5.5.1, des fonctionnalités équivalentes doivent
être fournies. Voir l’Annexe C pour la technologie micro-ondes UNI DSRC 5,8 GHz, l’Annexe D pour la
technologie infrarouge CALM DSRC et l’Annexe E pour la technologie micro-ondes ARIB DSRC.
6.1.2 Initialisation de la communication
L’initialisation de la communication doit être effectuée par l’équipement routier. L’invocation d’une
requête d’initialisation par l’équipement routier tente d’initialiser la communication entre l’équipement
routier et l’équipement embarqué. A l’issue de l’initialisation, la fonction « initialisation de la
communication » doit notifier les applications côtés équipement routier et équipement embarqué.
La notification d’initialisation côté équipement embarqué doit acheminer au minimum l’identité de la
balise (ex: numéro de série de la balise) et une date absolue.
La notification d’initialisation côté équipement routier doit acheminer au minimum l’identité de
l’application CCC et doit également acheminer les données requises pour les services de sécurité (ex:
valeur nonce, identificateur de clé).
La fonction « initialisation de la communication » doit être fournie par les services INITIALISATION de
la couche d’application comme indiqué dans l’ISO 15628 et l’EN 12834. Elle est définie à l’Annexe A (voir
CCC-InitialiseComm-Request et CCC-InitialiseComm-Response).
6.1.3 Extraction des données
La fonction « extraction des données » doit être fournie par le service GET de la couche d’application
comme indiqué dans l’ISO 15628. Elle est définie à l’Annexe A (voir CCC-DataRetrieval-Request et CCC-
DataRetrieval-Response).
Dans les primitives de service GET, iid ne doit pas être utilisé.
NOTE L’invocation d’une primitive de service par un processus d’application appelle implicitement et utilise
les services fournis par les couches de protocole basses.
Le service GET doit toujours intégrer des identifiants d’accès.
6.1.4 Extraction des données authentifiées
La fonction « extraction des données authentifiées » doit être mise en œuvre par la fonction EFC GET_
STAMPED comme indiqué dans l’ISO 14906. Elle est définie à l’Annexe A (voir CCC-AuthDataRetrieval-
Request et CCC-AuthDataRetrieval-Response).
8 © ISO 2015 – Tous droits réservés

La fonction GET_STAMPED doit toujours intégrer des identifiants d’accès.
NOTE Les identifiants d’accès contiennent les informations nécessaires pour réunir les conditions d’accès
afin de réaliser l’opération sur l’élément adressé dans l’équipement embarqué. Les identifiants d’accès peuvent
contenir des mots de passe, ainsi que des informations de cryptographie comme les authentificateurs.
6.1.5 Notification du conducteur
La fonction « notification du conducteur » doit être mise en œuvre par la fonction EFC SET_MMI
comme indiqué dans l’ISO 14906. Elle est définie à l’Annexe A (voir CCC-Notification-Request et CCC-
Notification-Response).
NOTE Selon l’ISO 14906, SET_MMI.request utilise l’EID = 0 et n’intègre pas d’identifiants d’accès.
6.1.6 Arrêt de la communication
L’équipement routier peut mettre fin à la communication au moyen de la fonction « arrêt de la
communication ». L’invocation d’une demande de libération par l’équipement routier a pour effet de
tenter de mettre fin à la communication au niveau de l’application.
NOTE 1 L’arrêt de la communication au niveau de la liaison n’entre pas dans le cadre de la présente Norme.
La fonction « arrêt de la communication » doit être fournie par le service EVENT-REPORT de la couche
d’application comme indiqué dans l’ISO 15628 et l’EN 12834. Elle est définie à l’Annexe A (voir CCC-
TerminateComm).
NOTE 2 Selon l’ISO 15628 et l’EN 12834, la requête EVENT-REPORT (libération) utilise l’EID = 0 et n’intègre
pas d’identifiants d’accès.
6.1.7 Essai de la communication
La fonction « essai de la communication » doit être mise en œuvre par la fonction EFC ECHO comme indiqué
dans l’ISO 14906. Elle est définie à l’Annexe A (voir CCC-TestComm-Request et CCC-TestComm-Response).
NOTE Selon l’ISO 14906, la fonction ECHO utilise l’EID = 0 et n’intègre pas d’identifiants d’accès.
6.2 Sécurité
6.2.1 Généralités
La sécurité constitue un aspect clé des applications CCC. La présente Norme détaille les services de
sécurité génériques. Les mises en œuvre détaillées sont spécifiques au support.
La présente Norme internationale spécifie un service d’authentification qui peut servir à prouver
l’id
...