II 
(Actes non législatif s) 
RÈGLEMENTS 
RÈGLEMENT D'EXÉCUTION (UE) 2016/799 DE LA COMMISSION 
du 18 mars 2016 
mett ant en œuvre le règlement (UE) no 165/2014 du Parlement européen et du Conseil en ce qui 
concer ne les exigences applicables à la constr uction, aux essais, à l'inst allation, à l'utilisation et à la 
réparation des tachyg raphes et de leurs composants 
(Texte présentant de l'intérêt pour l'EEE) 
LA COMMISSION EUR OPÉENNE, 
vu le traité sur le fonctionnement de l'Union européenne, 
vu le règlement (UE) no 165/2014 du Parlement européen et du Conseil du 4 février 2014 relatif aux tach ygraphes dans 
les transpor ts routiers (1), et notamment son article 11 et son article 12, paragraphe 7, 
considérant ce qui suit: 
(1)  Le règlement (UE) no 165/2014 a instauré le tach ygraphe numér ique de deuxième génération, appelé tach ygraphe 
intelli gent, connecté au système mondial de navigat ion par satellite (ci-après «GNSS») et compr enant un dispositif 
de communication à distance à des fins de détection précoce et une interface avec les systèmes de transpor t 
intelli gents. Il convient de définir les exigences techniques applicables à la constr uction des tach ygraphes 
intelli gents. 
(2)  Le dispositif de détection précoce à distance prévu à l'article 9, paragraphe 4, du règlement (UE) no 165/2014 
devrait transmettre aux agents chargés du contrôle routier les données du tach ygraphe numér ique et les 
informations relatives au poids et au poids par essieu du train routier compl et (tract eur et remorques ou semi- 
remorques), conf ormément à la directive 96/53/CE du Parlement européen et du Conseil (2). Ce dispositif devrait 
permettre un contrôle efficace et rapide des véhicules par les services de contrôle, tout en réduisant le nombre 
d'appareils électroniques présents dans la cabine du véhicule. 
(3)  Conf ormément à la directive 96/53/CE, le dispositif de détec tion précoce à distance devrait utiliser les normes 
CEN DSR C (3) visées par ladite directive, dans la bande de fréquences 5 795-5 805 MHz. Étant donné que cette 
bande de fréquences est également utilisée pour le péage électronique, et pour éviter tout e interférence entre les 
applications de péag e et de contrôle, les agents de contrôle ne devraient pas utiliser le dispositif de détection 
précoce à distance dans les gares de péag e. 
(4)  L'instauration du tach ygraphe intelli gent devrait s'accom pagner de nouveaux mécanismes de sécur ité destinés à 
maint enir le niveau de sécur ité du tach ygraphe numér ique afin de pallier les failles de sécur ité actuelles. L'une de 
ces failles consiste en l'absence de date d'expiration des certificat s numér iques. Dans un souci de conf ormité avec 
les meilleures pratiques en matière de sécur ité, il est recommandé d'éviter l'utilisation de certificats numér iques 
sans date d'expiration. La durée de validité opérationnelle normale des unités embarquées sur les véhicules devrait 
être de 15 ans à comp ter de la date de délivrance de leurs certificat s numér iques. Les unités embarquées sur les 
véhicules devraient être rem placées au term e de cette période de validité . 26.5.2016 L 139/1 Jour nal officiel de l'Union européenne FR     
(1)JO L 60 du 28.2.2014, p. 1. 
(2)Directive 96/53/CE du Conseil du 25 juillet 1996 fixant, pour certains véhicules routiers circulant dans la Communaut é, les dimensions 
maximales auto risées en trafic national et international et les poids maximaux auto risés en trafic inter national (JO L 235 du 17.9.1996, 
p. 59) 
(3)Nor mes applicables aux communications spécialisées à cour te portée (Dedicated Shor t Range Communications, ou DSR C) du Comité 
européen de normalisation (CEN) EN 12253, EN 12795, EN 12834, EN 13372 et ISO 14906. 
(5)  La fourniture d'inf ormations de positionnement sûres et fiables est un élément essentiel du bon fonctionnement 
des tach ygraphes intellig ents. Par conséquent, il convi ent de veiller à leur compatib ilité avec les services à valeur 
ajoutée fournis par le programme Galileo, comme prévu par le règlement (UE) no 1285/2013 du Parlement 
européen et du Conseil (1), afin d'améliorer la sécur ité du tach ygraphe intellig ent. 
(6)  Conf ormément à l'article 8, paragraphe 1, à l'article 9, paragraphe 1, et à l'article 10, paragraphes 1 et 2, du 
règlement (UE) no 165/2014, les mécanismes de sécur ité prévus par ce règlement devraient s'appliquer 36 mois 
après la date d'entrée en vigueur des acte s d'exécuti on requis, de manière à permettre aux fabr icants de mettre au 
point la nouvelle génération de tach ygraphes intelligents et d'obte nir leurs certificats d'homologation des autori tés 
compét entes. 
(7)  Conf ormément au règlement (UE) no 165/2014, les véhicules immatr iculés pour la première fois dans un État 
membre 36 mois après l'entrée en vigueur du présent règlement de la Commission devraient être équipés d'un 
tach ygraphe intelligent conf orme aux exigenc es du présent règlement de la Commission. En tout état de cause, 
tous les véhicules circulant dans un État membre autre que leur État membre d'immatr iculation devraient être 
équipés d'un tach ygraphe intelligent conf orme 15 ans après la date de mise en application de ces exigenc es. 
(8)  Le règlement (CE) no 68/2009 de la Commission (2) autorise, pendant une période transitoire prenant fin le 
31 décembre 2013, l'utilisation d'un adap tateur afin de permettre l'installation de tach ygraphes dans les véhicules 
de types M1 et N1. Com pte tenu des difficulté s techniques liées à la recherc he d'une solution de rem placement à 
l'adaptat eur, les exper ts de l'industr ie automobi le et de l'industr ie des tach ygraphes ont conclu, en accord avec la 
Commission, que l'adapta teur ne peut être remplacé sans que cela entraîne, pour les entrepr ises, des coûts 
importants qui seraient dispropor tionnés au regard de la taille du marc hé. Par conséquent, l'utilisation de 
l'adaptat eur dans les véhicules de types M1 et N1 devrait être autori sée pour une durée indéter minée. 
(9)  Les mesures prévues par le présent règlement sont conf ormes à l'avis du comit é visé à l'article 42, paragraphe 3, 
du règlement (CE) no 165/2014, 
A ADOPTÉ LE PRÉSENT RÈGLEMENT : 
Article premier 
Objet et champ d'application 
1. Le présent règlement arrête les dispositions nécessaires à l'application unif orme des aspects suivants relatifs aux 
tach ygraphes: 
a)  enregistrement de la position du véhicule à certains points au cours de la période de travail jour nalière du 
conduct eur; 
b)  détection précoce à distance d'une éventuelle manipulation ou utilisation abusive des tach ygraphes intellig ents; 
c)  interf ace avec les systèmes de transpor t intelligents; 
d)  exigenc es administratives et techniques applicables aux procédures d'homolog ation des tach ygraphes, y compris aux 
mécanismes de sécur ité. 
2. La constr uction, les essais, l'installation, l'inspection, l'utilisation et la réparation des tach ygraphes intelligents et de 
leurs compo sants sont conf ormes aux exige nces techniques énoncées à l'annexe 1C du présent règlement. 
3. Les tach ygraphes autres que les tach ygraphes intellig ents continuent, en matière de constr uction, d'essais, d'instal ­
lation, d'inspection, d'utilisation et de réparation, de satisf aire aux exige nces de l'annex e 1 ou de l'annex e 1B, selon le cas, 
du règlement (CEE) no 3821/85 du Conseil (3). 26.5.2016 L 139/2 Jour nal officiel de l'Union européenne FR     
(1)Règlement (UE) no 1285/2013 du Parlement européen et du Conseil du 11 décembre 2013 relatif à la mise en place et à l'exploitation des 
systèmes européens de radionav igation par satellite et abrogean t le règlement (CE) no 876/2002 du Conseil et le règlement (CE) 
no 683/2008 du Parlement européen et du Conseil (JO L 347 du 20.12.2013, p. 1). 
(2)Règlement (CE) no 68/2009 de la Commission du 23 janvier 2009 portant neuvième adap tation au progrès technique du règlement (CEE) 
no 3821/85 du Conseil concer nant l'appareil de contrôle dans le domaine des transpor ts par route (JO L 21 du 24.1.2009, p. 3). 
(3)Règlement (CEE) no 3821/85 du Conseil du 20 décembre 1985 concer nant l'appareil de contrôle dans le domaine des transpor ts par 
rout e (JO L 370 du 31.12.1985, p. 8). 
4. En vertu de l'article 10 quinquies de la directive 96/53/CE du Parlement européen et du Conseil, le dispositif de 
détection précoce à distance transmet également les données relatives aux poids fournies par un système de pesage 
embarqué interne, aux fins de la détection précoce des fraudes. 
Article 2 
Déf initions 
Aux fins du présent règlement, les définitions établies à l'article 2 du règlement (UE) no 165/2014 s'appliquent. 
En outre, on entend par:  
1) «tach ygraphe numér ique» ou «tach ygraphe de première génération», un tach ygraphe numér ique autre qu'un 
tach ygraphe intelli gent ;  
2) «dispositif GNSS externe» , un dispositif contenant le récep teur GNSS lorsque l'unité embarquée sur le véhicule n'est 
pas une unité intégrée, ainsi que d'autres compo sants nécessaires à la protect ion de la communication des données de 
position au reste de l'unit é embarquée sur le véhicule;  
3) «dossier fabricant», le dossier compl et, sous forme électronique ou impr imée, contenant tout es les informations 
fournies par le fabricant ou son mandataire à l'autori té d'homolog ation aux fins de l'homolog ation d'un tach ygraphe 
ou d'un compo sant de tach ygraphe, y compris les certificats visés à l'article 12, paragraphe 3, du règlement (UE) 
no 165/2014, l'exécution des essais définis à l'annex e 1C du présent règlement, ainsi que les dessins, photographies et 
autres documents pertinents;  
4) «dossier d'homologat ion», le dossier fabr icant, sous forme électronique ou sur papier , accompag né de tous les autres 
documents que l'aut orité d'homologat ion a adjoints au dossier fabr icant dans l'exercice de ses fonctions, y compris, 
au term e de la procédure d'homologation, le certificat d'homologation CE du tach ygraphe ou de son compo sant ;  
5) «index du dossier d'homologation», le document présentant le cont enu du dossier d'homolog ation selon une 
numérotation permettant de localiser tous les éléments utiles dudit dossier . La structure de ce document permet de 
distinguer les étapes successives du processus d'homologation CE, y compris les dates des révisions et mises à jour 
éventuelles du dossier;  
6) «dispositif de détection précoce à distance», le dispositif de l'unit é embarquée sur le véhicule qui est utilisé pour 
effectuer des contrôles routiers ciblés;  
7) «tach ygraphe intellig ent» ou «tach ygraphe de deuxième génération», un tach ygraphe numér ique conf orme aux 
articles 8, 9 et 10 du règlement (UE) no 165/2014 ainsi qu'à l'annexe 1C du présent règlement ;  
8) «composant de tach ygraphe», l'un des éléments suivants: l'unit é embarquée sur le véhicule, le capt eur de mouvement, 
la carte tach ygraphique, la feuille d'enregistrement, le dispositif GNSS externe et le dispositif de détection précoce à 
distance;  
9) «autorité d'homolog ation», l'aut orité d'un État membre compét ente pour effectuer l'homolog ation du tach ygraphe ou 
de ses compo sants, le processus d'autoris ation, la délivrance et, le cas échéant, le retrait des certificats d'homolo ­
gation, servant de point de contact pour les autor ités d'homologa tion des autres États membres et veillant à ce que 
les fabricants remplissent leurs oblig ations de conf ormité aux exigences du présent règlement. 
Article 3 
Services basés sur la localisation 
1. Les fabr icants veillent à ce que les tach ygraphes intelli gents soient compatibles avec les services de positionnement 
fournis par les systèmes Galileo et EGNOS (système européen de navigat ion par recouvrement géostationnaire). 
2. En plus des systèmes visés au paragraphe 1, les fabricants peuvent aussi décider d'assurer la compatib ilité avec 
d'autres systèmes de navigat ion par satellite. 26.5.2016 L 139/3 Jour nal officiel de l'Union européenne FR     
Article 4 
Procédure d'homologation d'un tachyg raphe et de composants de tachy graphe 
1. Le fabr icant ou son mandataire soumet une demande d'homolog ation du tach ygraphe ou d'un de ses compo sants 
ou groupes de compo sants aux autor ités d'homolog ation désignées par chaque État membre. Cette demande se compo se 
d'un dossier fabricant conte nant les renseignements relatifs à chacun des compo sants concer nés, y compr is, le cas 
éché ant, les certificats d'homolog ation des autres compo sants nécessaires pour constr uire l'ensemble du tach ygraphe, 
ainsi que tous les autres documents pertinents. 
2. L'État membre accorde l'homolog ation à tout tach ygraphe, composant ou groupe de compo sants qui est conf orme 
aux exigences administratives et techniques visées à l'article 1er, paragraphe 2 ou 3, selon le cas. Dans ce cas, l'autorité 
d'homologat ion délivre au demandeur un certificat d'homologat ion conf orme au modèle figurant à l'annexe II du 
présent règlement. 
3. L'autorité d'homologa tion peut demander au fabricant ou à son mandataire de fournir des informations compl é­
mentaires. 
4. Le fabr icant ou son mandataire met à la disposition des autori tés d'homologat ion, ainsi que des entit és chargée s de 
la délivrance des certificats visés à l'article 12, paragraphe 3, du règlement (UE) no 165/2014, le nombre de tach ygraphes 
ou de compo sants de tach ygraphe nécessaire pour leur permettre de mener à bien la procédure d'homologation. 
5. Si le fabricant ou son mandataire sollicite l'homolog ation de certains compo sants ou groupes de compo sants d'un 
tach ygraphe, il fournit aux autori tés d'homologat ion les autres éléments déjà homologués et les autres éléments 
nécessaires à la constr uction de l'ensemble du tach ygraphe afin de permettre à ces autori tés d'effe ctuer les essais 
nécessaires. 
Article 5 
Modif ication des homologations 
1. Le fabr icant ou son mandataire informe sans tarder les autorités d'homologation qui ont accordé l'homolog ation 
initiale de tout e modifi cation appor tée au logiciel ou au maté riel du tach ygraphe ou à la nature des matér iaux emplo yés 
pour sa fabrication qui sont enregistrés dans le dossier d'homologa tion et présent e une demande de modification de 
l'homolog ation. 
2. Les autorités d'homologation peuvent réviser ou étendre une homologation existant e ou en délivrer une nouvelle 
en fonction de la nature et des caractér istiques de la modif ication. 
Une «révision» est effectuée lorsque l'aut orité d'homolog ation considère que les modifi cations appor tées au logiciel ou au 
maté riel du tach ygraphe ou à la nature des matér iaux emplo yés pour sa fabrication sont mineures. En pareil cas, 
l'aut orité d'homologation délivre les documents révisés du dossier d'homologation indiquant la nature des modifi cations 
effectuées et la date de leur approbation. Une version actualisée du dossier d'homolog ation sous forme consolidée, 
accompag née d'une descr iption détaillée des modific ations effectuées, est suffi sante pour satisf aire à cette exigenc e. 
Une «extension» est effectuée lorsque l'aut orité d'homologat ion considère que les modifications appor tées au logiciel ou 
au matér iel du tach ygraphe ou à la nature des maté riaux employés pour sa fabrication sont impor tantes . En pareil cas, 
elle peut demander que de nouveaux essais soient effectués et en informe le fabr icant ou son mandataire. Si ces essais 
sont satisf aisants, l'aut orité d'homologation délivre un certificat d'homologat ion révisé portant un numéro correspondant 
à l'ext ension accordée. Le certificat d'homologation mentionne le motif de l'extension ainsi que sa date de délivrance. 
3. L'index du dossier d'homologation indique la date de l'ext ension ou de la révision la plus récente de l'homolog ation 
ou la date de la consolidation la plus récent e de la version actualisée de l'homolog ation. 26.5.2016 L 139/4 Jour nal officiel de l'Union européenne FR     
4. Une nouvelle homologation est nécessaire au cas où les modifications concer nées du tach ygraphe homologué ou 
de ses compo sants conduiraient à la délivrance d'un nouveau certificat de sécur ité ou d'inter opérabilité. 
Article 6 
Entrée en vigueur 
Le présent règlement entre en vigueur le vingtième jour suivant celui de sa publication au Journal officiel de l'Union 
européenne. 
Il s'applique à comp ter du 2 mars 2016. 
Toutef ois, les annexes s'appliquent à comp ter du 2 mars 2019, à l'excep tion de l'appendice 16, qui s'applique à comp ter 
du 2 mars 2016. 
Le présent règlement est oblig atoire dans tous ses éléments et directement applicable dans tout 
État membre. 
Fait à Bruxelles, le 18 mars 2016. 
Par la Commission 
Le président 
Jean-Claude JUNCKER  26.5.2016 L 139/5 Jour nal officiel de l'Union européenne FR     
ANNEXE I C 
Exigences de constr uction, d'essai, d'inst allation et de contrôle 
INTR ODUCTION ............................................................................................................................................ 12 
1 DÉFINITIONS .................................................................................................................. 13 
2 CARACTÉRISTIQUES GÉNÉRALES ET FONCTIONS DE L'APP AREIL DE CONTRÔL E...................... 19 
2.1 Caractéristique s générales ................................................................................................... 19 
2.2 Fonctions ....................................................................................................................... 20 
2.3 Modes de fonctionnement .................................................................................................. 21 
2.4 Sécur ité.......................................................................................................................... 22 
3 EXIGENCES CONSTR UCTIVES ET FONCTIONNELLES APPLICAB LES À L'APP AREIL DE 
CONTRÔL E.................................................................................................................... 22 
3.1 Suivi de l'inser tion et du retrait des cartes.............................................................................. 22 
3.2 Mesure de la vitess e, de la position et de la distance parcour ue................................................... 23 
3.2.1 Mesure de la distance parcour ue.......................................................................................... 23 
3.2.2 Mesure de la vitess e.......................................................................................................... 23 
3.2.3 Mesure de la position ........................................................................................................ 24 
3.3 Mesure du temps.............................................................................................................. 24 
3.4 Surveillance des activités du conduct eur ................................................................................ 24 
3.5 Surveillance de l'état de conduit e......................................................................................... 25 
3.6 Saisie par le conduct eur ..................................................................................................... 25 
3.6.1 Saisie du lieu de début et/ou de fin de la période de travail jour nalière ......................................... 25 
3.6.2 Saisie manuelle des activités du conduct eur et consent ement du conducteur pour l'interface ITS ........ 25 
3.6.3 Saisie de conditions particulières .......................................................................................... 27 
3.7 Gestion des dispositifs de verrouillage de l'entrepr ise................................................................ 27 
3.8 Suivi des activités de contrôle ............................................................................................. 28 
3.9 Détection d'événements et/ou d'anomalies .............................................................................. 28 
3.9.1 Événement «Inser tion d'une carte non valable» ........................................................................ 28 
3.9.2 Événement «Conf lit de carte» .............................................................................................. 28 
3.9.3 Événement «Chevauche ment temporel» .................................................................................. 28 
3.9.4 Événement «Conduite sans carte appropr iée» .......................................................................... 29 
3.9.5 Événement «Inser tion d'une carte en cours de conduit e»............................................................ 29 
3.9.6 Événement «Der nière session incor rectement clôturée» .............................................................. 29 
3.9.7 Événement «Excès de vitesse» .............................................................................................. 29 
3.9.8 Événement «Interruption de l'alimentation électr ique» ............................................................... 29 
3.9.9 Événement «Erreur de communication avec le dispositif de communication à distance» .................... 29 
3.9.10 Événement «Absence d'inf ormations de positionnement en provenance du récep teur GNSS» .............. 29 26.5.2016 L 139/6 Jour nal officiel de l'Union européenne FR     
3.9.11 Événement «Erreur de communication avec le dispositif GNSS externe» ........................................ 30 
3.9.12 Événement «Erreur sur les données de mouvement» ................................................................. 30 
3.9.13 Événement «Conf lit concer nant le mouvement du véhicule» ....................................................... 30 
3.9.14 Événement «Tentative d'atteint e à la sécur ité».......................................................................... 30 
3.9.15 Événement «Conf lit temporel» ............................................................................................. 30 
3.9.16 Anomalie «Car te»............................................................................................................. 30 
3.9.17 Anomalie «Appareil de contrôle» .......................................................................................... 30 
3.10 Autotest s intégrés ............................................................................................................. 31 
3.11 Lecture de la mémoire ....................................................................................................... 31 
3.12 Enregistrement et stoc kage dans la mémoire ........................................................................... 31 
3.12.1 Données d'identification de l'appareil .................................................................................... 32 
3.12.1.1 Données d'identification de l'unit é embarquée sur le véhicule ..................................................... 32 
3.12.1.2 Données d'identification du capt eur de mouvement ................................................................. 32 
3.12.1.3 Données d'identification des systèmes mondiaux de navig ation par satelli te (Global Nav igation Sate llite 
Systems )......................................................................................................................... 33 
3.12.2 Clés et certificat s.............................................................................................................. 33 
3.12.3 Données d'inser tion et de retrait de la carte du conduct eur ou de l'atelier ...................................... 33 
3.12.4 Données relatives à l'activité du conducteur ............................................................................ 34 
3.12.5 Lieux et positions des lieux où les périodes de travail jour nalières commencent et se term inent et/ou 
où les 3 heures de temps de conduite continue sont attein tes..................................................... 34 
3.12.6 Données relatives au kilométrage ......................................................................................... 35 
3.12.7 Données détaillées relatives à la vitesse.................................................................................. 35 
3.12.8 Données relatives aux événements ........................................................................................ 35 
3.12.9 Données relatives aux anomalies .......................................................................................... 37 
3.12.10 Données d'étalonnag e........................................................................................................ 38 
3.12.11 Données de remise à l'heure ............................................................................................... 39 
3.12.12 Données d'activit é de contrôle ............................................................................................. 39 
3.12.13 Données relatives aux verrouillages d'entrepr ise ...................................................................... 39 
3.12.14 Données relatives au télécharg ement ..................................................................................... 39 
3.12.15 Données concer nant les conditions particulières ...................................................................... 40 
3.12.16 Données relatives à la carte tach ygraphique ............................................................................ 40 
3.13 Lecture des cartes tach ygraphiques ....................................................................................... 40 
3.14 Enregistrement et stoc kage sur cartes tach ygraphiques .............................................................. 40 
3.14.1 Enregistrement et stoc kage sur les cartes tach ygraphiques de première génération ........................... 40 
3.14.2 Enregistrement et stoc kage sur les cartes tach ygraphiques de deuxième génération .......................... 41 
3.15 Affichage ........................................................................................................................ 41 
3.15.1 Affichage par défa ut.......................................................................................................... 42 26.5.2016 L 139/7 Jour nal officiel de l'Union européenne FR     
3.15.2 Affichage d'aver tissements .................................................................................................. 43 
3.15.3 Menu d'accès ................................................................................................................... 43 
3.15.4 Autres affichag es.............................................................................................................. 43 
3.16 Imp ression ...................................................................................................................... 43 
3.17 Avertissements ................................................................................................................ 44 
3.18 Téléc hargement de données à destination de suppor ts externes ................................................... 45 
3.19 Communication à distance pour les contrôles routiers ciblés ...................................................... 45 
3.20 Données transmises à des dispositifs exte rnes supplémentaires ................................................... 46 
3.21 Étalonnag e...................................................................................................................... 47 
3.22 Contrôles routiers d'étalonnag e............................................................................................ 47 
3.23 Remise à l'heure ............................................................................................................... 48 
3.24 Caractéristique s de perf ormance .......................................................................................... 48 
3.25 Matériaux ....................................................................................................................... 48 
3.26 Inscr iptions ..................................................................................................................... 49 
4 EXIGENCES DE FABRICA TION ET EXIGENCES FONCTIONNELLES APPLIC ABLES AUX CARTES TA­
CHYGRAPHIQUES ........................................................................................................... 49 
4.1 Données visibles .............................................................................................................. 49 
4.2 Sécur ité.......................................................................................................................... 52 
4.3 Nor mes .......................................................................................................................... 53 
4.4 Spécifi cations environnementales et électr iques ....................................................................... 53 
4.5 Stoc kage des données ........................................................................................................ 53 
4.5.1 Fichier s élémentaires pour l'identif ication et la gestion des cartes................................................. 54 
4.5.2 Identif ication des cartes à circuit intégré ................................................................................ 54 
4.5.2.1 Identif ication du microprocesseur ........................................................................................ 54 
4.5.2.2 DIR (uniquement présent sur les cartes tach ygraphiques de deuxième génération) ........................... 54 
4.5.2.3 Informations ATR (conditionnelles, présentes uniquement sur les cartes tach ygraphiques de deuxième 
génération) ..................................................................................................................... 54 
4.5.2.4 Informations relatives à la période étendue (conditionnelles, présent es uniquement sur les cartes tach y­
graphiques de deuxième génération) ..................................................................................... 55 
4.5.3 Carte de conduct eur .......................................................................................................... 55 
4.5.3.1 Application tach ygraphique (accessible aux unités embarquées de première et deuxième 
générations) .................................................................................................................... 55 
4.5.3.1.1 Identif ication des applications ............................................................................................. 55 
4.5.3.1.2 Clés et certificat s.............................................................................................................. 55 
4.5.3.1.3 Identif ication de carte........................................................................................................ 55 
4.5.3.1.4 Identif ication du détent eur de la carte................................................................................... 55 
4.5.3.1.5 Téléc hargement (download) d'une carte................................................................................. 55 
4.5.3.1.6 Renseignements concer nant le permis de conduire ................................................................... 55 
4.5.3.1.7 Données relatives aux événements ........................................................................................ 56 26.5.2016 L 139/8 Jour nal officiel de l'Union européenne FR     
4.5.3.1.8 Données relatives aux anomalies .......................................................................................... 56 
4.5.3.1.9 Données relatives aux activités du conduct eur ......................................................................... 57 
4.5.3.1.10 Données concer nant les véhicules utilisés .............................................................................. 57 
4.5.3.1.11 Lieux de début/de fin des périodes jour nalières de travail ........................................................... 58 
4.5.3.1.12 Données concer nant les sessions pour chaque carte................................................................. 58 
4.5.3.1.13 Données relatives aux activités de contrôle ............................................................................. 58 
4.5.3.1.14 Données concer nant les conditions particulières ...................................................................... 58 
4.5.3.2 Application tach ygraphique de deuxième génération (non accessible aux VU de première 
génération) ..................................................................................................................... 59 
4.5.3.2.1 Identif ication des applications ............................................................................................. 59 
4.5.3.2.2 Clés et certificat s.............................................................................................................. 59 
4.5.3.2.3 Identif ication de carte........................................................................................................ 59 
4.5.3.2.4 Identif ication du détent eur de la carte................................................................................... 59 
4.5.3.2.5 Téléc hargement (download) d'une carte................................................................................. 59 
4.5.3.2.6 Renseignements concer nant le permis de conduire ................................................................... 59 
4.5.3.2.7 Données relatives aux événements ........................................................................................ 59 
4.5.3.2.8 Données relatives aux anomalies .......................................................................................... 60 
4.5.3.2.9 Données relatives aux activités du conduct eur ......................................................................... 61 
4.5.3.2.10 Données concer nant les véhicules utilisés .............................................................................. 61 
4.5.3.2.11 Lieux et positions de début/fi n des périodes jour nalières de travail ............................................... 62 
4.5.3.2.12 Données concer nant les sessions pour chaque carte................................................................. 62 
4.5.3.2.13 Données relatives aux activités de contrôle ............................................................................. 62 
4.5.3.2.14 Données concer nant les conditions particulières ...................................................................... 63 
4.5.3.2.15 Données concer nant les unités embarquées sur véhicule qui ont été utilisées ................................. 63 
4.5.3.2.16 Données relatives aux lieux où les trois heures de conduite continue ont été atteint es...................... 63 
4.5.4 Carte d'ateli er.................................................................................................................. 63 
4.5.4.1 Application tach ygraphique (accessible aux unités embarquées de première et deuxième 
générations) .................................................................................................................... 63 
4.5.4.1.1 Identif ication des applications ............................................................................................. 63 
4.5.4.1.2 Clés et certificat s.............................................................................................................. 63 
4.5.4.1.3 Identif ication de carte........................................................................................................ 64 
4.5.4.1.4 Identif ication du détent eur de la carte................................................................................... 64 
4.5.4.1.5 Téléc hargement (download) d'une carte................................................................................. 64 
4.5.4.1.6 Données concer nant l'étalonnag e et la remise à l'heure ............................................................. 64 26.5.2016 L 139/9 Jour nal officiel de l'Union européenne FR     
4.5.4.1.7 Données relatives aux événements et aux anomalies ................................................................. 65 
4.5.4.1.8 Données relatives aux activités du conduct eur ......................................................................... 65 
4.5.4.1.9 Données concer nant les véhicules utilisés .............................................................................. 65 
4.5.4.1.10 Données concer nant le début et/ou la fin des périodes de travail jour nalières ................................. 65 
4.5.4.1.11 Données concer nant les sessions pour chaque carte................................................................. 65 
4.5.4.1.12 Données relatives aux activités de contrôle ............................................................................. 65 
4.5.4.1.13 Données concer nant les conditions particulières ...................................................................... 65 
4.5.4.2 Application tach ygraphique de deuxième génération (non accessible aux VU de première 
génération) ..................................................................................................................... 65 
4.5.4.2.1 Identif ication des applications ............................................................................................. 65 
4.5.4.2.2 Clés et certificat s.............................................................................................................. 66 
4.5.4.2.3 Identif ication de carte........................................................................................................ 66 
4.5.4.2.4 Identif ication du détent eur de la carte................................................................................... 66 
4.5.4.2.5 Téléc hargement (download) d'une carte................................................................................. 66 
4.5.4.2.6 Données concer nant l'étalonnag e et la remise à l'heure ............................................................. 66 
4.5.4.2.7 Données relatives aux événements et aux anomalies ................................................................. 67 
4.5.4.2.8 Données relatives aux activités du conduct eur ......................................................................... 67 
4.5.4.2.9 Données concer nant les véhicules utilisés .............................................................................. 67 
4.5.4.2.10 Données concer nant le début et/ou la fin des périodes de travail jour nalières ................................. 67 
4.5.4.2.11 Données concer nant les sessions pour chaque carte................................................................. 67 
4.5.4.2.12 Données relatives aux activités de contrôle ............................................................................. 67 
4.5.4.2.13 Données concer nant les unités embarquées sur véhicule qui ont été utilisées ................................. 67 
4.5.4.2.14 Données relatives aux lieux où les trois heures de conduite continue ont été atteint es...................... 68 
4.5.4.2.15 Données concer nant les conditions particulières ...................................................................... 68 
4.5.5 Carte de contrôleur ........................................................................................................... 68 
4.5.5.1 Application tach ygraphique (accessible aux unités embarquées de première et deuxième 
générations) .................................................................................................................... 68 
4.5.5.1.1 Identif ication des applications ............................................................................................. 68 
4.5.5.1.2 Clés et certificat s.............................................................................................................. 68 
4.5.5.1.3 Identif ication de carte........................................................................................................ 68 
4.5.5.1.4 Identif ication du détent eur de la carte................................................................................... 68 
4.5.5.1.5 Données relatives aux activités de contrôle ............................................................................. 69 
4.5.5.2 Application tach ygraphique de deuxième génération (non accessible aux VU de première 
génération) ..................................................................................................................... 69 
4.5.5.2.1 Identif ication des applications ............................................................................................. 69 
4.5.5.2.2 Clés et certificat s.............................................................................................................. 69 26.5.2016 L 139/10 Jour nal officiel de l'Union européenne FR     
4.5.5.2.3 Identif ication de carte........................................................................................................ 69 
4.5.5.2.4 Identif ication du détent eur de la carte................................................................................... 69 
4.5.5.2.5 Données relatives aux activités de contrôle ............................................................................. 70 
4.5.6 Carte d'entrepr ise............................................................................................................. 70 
4.5.6.1 Application tach ygraphique (accessible aux unités embarquées de première et deuxième 
générations) .................................................................................................................... 70 
4.5.6.1.1 Identif ication des applications ............................................................................................. 70 
4.5.6.1.2 Clés et certificat s.............................................................................................................. 70 
4.5.6.1.3 Identif ication de carte........................................................................................................ 70 
4.5.6.1.4 Identif ication du détent eur de la carte................................................................................... 70 
4.5.6.1.5 Données concer nant l'activit é de l'entrepr ise........................................................................... 70 
4.5.6.2 Application tach ygraphique de deuxième génération (non accessible aux VU de première 
génération) ..................................................................................................................... 71 
4.5.6.2.1 Identif ication des applications ............................................................................................. 71 
4.5.6.2.2 Clés et certificat s.............................................................................................................. 71 
4.5.6.2.3 Identif ication de carte........................................................................................................ 71 
4.5.6.2.4 Identif ication du détent eur de la carte................................................................................... 71 
4.5.6.2.5 Données concer nant l'activit é de l'entrepr ise........................................................................... 71 
5 INST ALL ATION DE L'APP AREIL DE CONTRÔLE .................................................................... 72 
5.1 Installation ..................................................................................................................... 72 
5.2 Plaquett e d'installation ....................................................................................................... 73 
5.3 Scellement ...................................................................................................................... 74 
6 CONTRÔL ES, INSPECTIONS ET RÉPARA TIONS ..................................................................... 74 
6.1 Agrément des installate urs, des ateliers et des constr ucteurs de véhicules ....................................... 74 
6.2 Vérification d'instr uments neufs ou réparés ............................................................................ 75 
6.3 Inspection de l'installation .................................................................................................. 75 
6.4 Inspections périodiques ..................................................................................................... 75 
6.5 Détermination des erreurs .................................................................................................. 76 
6.6 Réparations ..................................................................................................................... 76 
7 DÉLIVRANCE DES CARTES............................................................................................... 76 
8 HOMOLOGA TION DE L'APP AREIL DE CONTRÔLE ET DES CARTES TACHY GRAPHIQUES ............. 77 
8.1 Points généraux ............................................................................................................... 77 
8.2 Certificat de sécur ité......................................................................................................... 78 
8.3 Certificat de fonctionnement ............................................................................................... 78 
8.4 Certificat d'interopérabilit é................................................................................................. 78 
8.5 Certificat d'homologation ................................................................................................... 79 
8.6 Procédure excep tionnelle: les premiers certificats d'inter opérabilité pour des unités de contrôle et des 
cartes tach ygraphiques de deuxième génération ....................................................................... 80  26.5.2016 L 139/11 Jour nal officiel de l'Union européenne FR     
INTR ODUCTION 
Le tach ygraphe numér ique de première génération est déplo yé depuis le 1er mai 2006. Il peut servir jusqu'à la fin de sa 
durée de vie pour le transpor t national. En revanc he, pour le transpor t internatio nal, il est impératif que 15 ans après 
l'entrée en vigueur du présent règlement de la Commission, tous les véhicules soient équipés d'un tach ygraphe intellig ent 
de deuxième génération conf orme au sens du présent règlement. 
La présente annexe contient les exigenc es relatives aux appareils de contrôle et cartes tach ygraphiques de deuxième 
génération. À partir de sa date de mise en œuvre, l'appareil de contrôle de deuxième génération devra être installé dans 
les véhicules immatr iculés pour la première fois et des cartes tach ygraphiques de deuxième génération devront être 
délivrées. 
Afin de favoriser une mise œuvre sans heur ts du tach ygraphe de deuxième génération: 
—  les cartes tach ygraphiques de deuxième génération doivent être conçues pour être également utilisées dans les unités 
embarquées de première génération, 
—  le remplacement des cartes tach ygraphiques de première génération en cours de validité à la date de mise œuvre ne 
sera pas exigé. 
Cela permettra aux conducteurs de garder leur carte de conduct eur unique et de l'utiliser dans les deux systèmes. 
Cependant, les appareils de contrôle de deuxième génération ne doivent être étalonnés qu'au moyen de cartes d'ate lier de 
deuxième génération. 
La présent e annexe contient tout es les exigenc es liées à l'interopérabilit é entre les tach ygraphes de première et de 
deuxième générations. 
L'appendice 15 contient des détails supplémentaires sur la façon dont la coexist ence des deux systèmes doit être gérée. 
Liste des appendices 
App 1: DICTIONNAIRE DE DONNÉES 
App 2: SPÉCIFICA TION DES CARTES TACHY GRAPHIQUES 
App 3: PICTOGRAMMES 
App 4: TIRA GES PAPIER 
App 5: AFFICHA GE 
App 6: CONNECTEUR FRONT AL POUR L'ÉT ALONNA GE ET LE TÉLÉC HAR GEMENT 
App 7: PROTOC OLES DE TÉLÉCHAR GEMENT DE DONNÉES 
App 8: PROTOC OLE D'ÉT ALONNA GE 
App 9: HOMOL OGA TION ET LISTE DES ESSAIS MINIMA UX REQUIS 
App 10: EXIGENCES EN MATIÈRE DE SÉCURITÉ 
App 11: MÉCANISMES DE SÉCURITÉ COMMUNS 
App 12: POSITIONNEMENT BASÉ SUR UN SYSTÈME MONDIAL DE NAVIGA TION PAR SATELLITE (GNSS) 
App 13: INTERF ACE ITS 
App 14: FONCTION DE COMMUNICA TION À DIST ANCE 
App 15: MIGRA TION: GÉRER LA COEXISTENCE DE PLUSIEURS GÉNÉRA TIONS D'ÉQUIPEMENTS 
App 16: ADAPT ATEUR POUR LES VÉHICULES DES TYPES M 1 ET N1  26.5.2016 L 139/12 Jour nal officiel de l'Union européenne FR     
1.  DÉFINITIONS 
Dans la présent e annexe, on entend par: 
a)  «activation»: 
la phase au cours de laquelle le tach ygraphe devient pleinement opérationnel et tout es les fonctions 
sont mises en œuvre, y compris les fonctions de sécur ité, au moyen d'une carte d'ate lier; 
b)  «authentification»: 
une fonction destinée à établir et vérifier une identité déclarée; 
c)  «authenticité» : 
le fait qu'une information provient d'une partie dont l'identité peut être vérifiée; 
d)  «test intégré»: 
des essais exécutab les sur demande, par une action de l'opérateur ou d'un dispositif externe; 
e)  «jour civil»: 
une jour née allant de minuit à minuit (24 heures). Tous les jours civils sont liés à l'heure universelle 
coordonnée (UTC); 
f)  «étalonnag e» d'un tach ygraphe intellig ent signif ie: 
la mise à jour ou la conf irmation des paramètres du véhicule à conser ver en mémoire. Les paramètres 
du véhicule comprenn ent l'identifi cation du véhicule [numéro d'identif ication (VIN), numéro d'imma ­
triculation (VRN) et État membre d'immatr iculation] et les caractér istiques du véhicule [w, k, l, taille 
des pneumatiques, réglage du limiteur de vitess e (le cas échéant), heure UTC, kilométrage]; pendant 
l'étalonnag e d'un appareil de contrôle, les types et les identifiants des scellements pertinents pour 
l'homolog ation doivent également être stoc kés en mémoire; 
tout e mise à jour ou confir mation de l'heure UTC uniquement est considérée comme une remise à 
l'heure et non comme un étalonnage, à condition qu'elle ne s'oppose pas à l'exige nce 409; 
l'étalonnag e d'un appare il de contrôle nécessite l'utilisation d'une carte d'atelier; 
g)  «numéro de carte»: 
un code alphanumér ique à 16 positions constituant le numéro d'identif ication unique d'une carte 
tach ygraphique dans un État membre; ce numéro compo rte un indice séquentiel de la carte (le cas 
échéant), un indice de rem placement de la carte et un indice de renouvellement de la carte; 
chaque carte est ainsi identifiable par le code de l'État membre qui l'a délivrée et par le numéro de 
carte; 
h)  «indice séquentiel de la carte»: 
le 14e caractère alphanumér ique du numéro de carte, utilisé pour diffé rencier les cartes délivrées à une 
entrepr ise, un ateli er ou une autori té de contrôle habilité à recevoi r plusieurs cartes tach ygraphiques. 
L'entrepr ise, l'ate lier ou l'aut orité de contrôle est identif ié(e) par les 13 premières positions du numéro 
de carte; 
i)  «indice de renouvellement de la carte»: 
le 16e caractère alphanumér ique du numéro de carte, incrément é à chaque renouvellement de la carte 
du tach ygraphe; 
j)  «indice de rem placement de la carte»: 
le 15e caractère alphanumér ique du numéro de carte, incrémenté à chaque remp lacement de la carte 
tach ygraphique; 26.5.2016 L 139/13 Jour nal officiel de l'Union européenne FR     
k)  «coefficient caractér istique du véhicule»: 
la caract éristique numér ique donnant la valeur du signal de sortie émis par la partie du véhicule qui 
relie celui-ci à l'appareil de contrôle (arbre de sortie de boîte de vitesses ou essieu) pendant que le 
véhicule se déplace sur une distance d'un kilomètre dans les conditions d'essai standard telles que 
définies dans l'exigence 414. Le coeffi cient caracté ristique est expr imé en impulsions par kilomètre (w 
= … imp/km); 
l)  «car te d'entrepr ise»: 
une carte tach ygraphique délivrée par les autori tés d'un État membre à une entrepr ise de transpor t 
tenue d'utiliser des véhicules équipés d'un tach ygraphe, ladit e carte permettant l'identifi cation de 
l'entrepr ise de transpor t ainsi que l'affichage , le télécharg ement et l'impr ession des données stoc kées 
dans le tach ygraphe, lesquelles données ont été verrouillées par cette même entrepr ise; 
m)  «constante de l'appareil de contrôle»: 
la caract éristique numér ique donnant la valeur du signal d'entrée nécessaire pour indiquer et 
enregistrer une distance parcour ue d'un kilomètre; cette constante est expr imée en impulsions par 
kilomètre (k = … imp /km); 
n)  «temps de conduite continue», le temps de conduite continue calculé par l'appareil de contrôle comme 
étant (1): 
la somme des temps de conduite accumulés par un conducteur donné depuis la fin de sa dernière 
période de DISPONIBILITÉ ou de PAUSE/REPOS ou INCONNUE (2) de 45 minutes ou plus [cette 
période peut avoir été divisée conf ormément au règlement (CE) no 561/2006 du Parlement européen 
et du Conseil (3)]. Les calculs tiennent comp te, en tant que de besoin, des activités antérieures 
enregistrées sur la carte de conducteur . Lorsque le conducteur n'a pas inséré sa carte, les calculs se 
fondent sur les données enregistrées dans la mémoire pour la période en cours où aucune carte n'a été 
insérée et correspondant au lecte ur pertinent ; 
o)  «car te de contrôleur»: 
une carte tach ygraphique délivrée par les autori tés d'un État membre à une autori té nationale de 
contrôle compét ente, ladite carte permettant l'identifi cation de l'organ isme de contrôle et, facultati ­
vement, de l'agen t de contrôle, ainsi que l'accès aux données stoc kées dans la mémoire ou sur les 
cartes de conduct eur et, facultativement, sur les cartes d'atelier , pour lecture, impression et/ou téléc har­
gement ; 
elle donne également accès à la fonction de contrôle de l'étalonnage routier et aux données se 
trouvant sur le lecteur de communication de détec tion précoce à distance. 
p)  «temps de pause cumulé», le temps de pause cumulé calculé par l'appareil de contrôle comme étant (1): 
la somme des périodes de DISPONIBILITÉ ou de PAUSE/REPOS ou INCONNUES (2) de 15 minutes ou 
plus accumulées par un conducteur donné, depuis la fin de sa dernière période de DISPONIBILITÉ ou 
PAUSE/REPOS ou INCONNU E (2) de 45 minute s ou plus [cette période peut avoir été divisée 
conf ormément au règlement (CE) no 561/2006.] 
Les calculs tiennent comp te, en tant que de besoin, des activité s antérieures enregistrées sur la carte de 
conduct eur. Les périodes inconnues de durée négativ e (début de la période inconnue > fin de la 
période inconnue) en raison de chevauc hements temporels entre deux appareils de contrôle diffé rents 
ne sont pas prises en comp te dans les calculs. 
Lorsque le conduct eur n'a pas inséré sa carte, les calculs se fondent sur les données enregistrées dans 
la mémoire pour la période en cours où aucune carte n'a été insérée et correspondant au lecteur 
pertinent ; 26.5.2016 L 139/14 Jour nal officiel de l'Union européenne FR     
(1)Ce mode de calcul du temps de travail continu et du temps de pause cumulé permet à l'appareil de contrôle de lancer en temps voulu 
l'aver tissement relatif au temps de travail continu. Il ne préjug e pas l'inter prétation léga le de ces temps. D'autres modes de calcul du temps 
de trav ail continu et du temps de pause cumulé peuvent être utilisés pour rem placer ces définitions si celles-ci ont été rendues obsolètes 
par la mise à jour d'autres instr uments législatifs applicables. 
(2)Les périodes INC ONNUES correspondent à des périodes où la carte de conducteur n'a pas été insérée dans l'appareil de contrôle et pour 
lesquelles aucune saisie manuelle des activit és du conducteu r n'a été effectuée. 
(3)Règlement (CE) no 561/2006 du Parlement européen et du Conseil du 15 mars 2006 relatif à l'har monisation de certaines dispositions de 
la législation sociale dans le domaine des transpor ts par route, modifiant les règlements (CEE) no 3821/85 et (CE) no 2135/98 du Conseil 
et abrogeant le règlement (CEE) no 3820/85 du Conseil (JO L 102 du 11.4.2006, p. 1). 
q)  «mémoire»: 
un dispositif de stockag e de données électroniques installé dans l'appareil de contrôle; 
r)  «signature numér ique»: 
les données attachées à un bloc de données, ou une transf ormation cryptographique de celui-ci, qui 
permettent à son destinataire d'av oir la preuve de son authenticit é et de son intégrité; 
s)  «téléchar gement»: 
la copie, avec signature numér ique, d'une partie ou de la tota lité d'un ensemble de fichiers de données 
enregistrés dans la mémoire de l'unit é embarquée ou dans la mémoire d'une carte tach ygraphique, 
pour autant que ce processus ne modifi e ni ne suppr ime aucune des données stoc kées; 
les fabr icants d'unités embarquées de tach ygraphes intellig ents et les fabricants d'équipements conçus 
pour téléc harger des fichiers de données prennent tout es les dispositions appropr iées, dans la mesure 
du raisonnable, pour que les entrepr ises de transpor t ou les conduct eurs puissent effectuer le téléchar ­
gement de ces données dans les meilleurs délais. 
Il se peut que le téléc hargement du fichier de relevés détaillés de la vitesse ne soit pas nécessaire pour 
établir la conf ormité avec le règlement (CE) no 561/2006, mais il peut servir à d'autres fins, 
notamment à des fins d'enquête dans le cadre d'un accident 
t)  «car te de conduct eur»: 
une carte tach ygraphique délivrée par les autori tés d'un État membre à un conduct eur. La carte 
tach ygraphique permet l'identifi cation du conducteur et le stockag e des données relatives à son 
activité ; 
u)  «circonf érence effective des roues»: 
la moyenne des distances parcour ues par chacune des roues entraînant le véhicule (roues motr ices) 
lors d'une rotation compl ète. La mesure de ces distances doit se faire dans les conditions normales 
d'essai telles que définies dans l'exig ence 414 et est expr imée sous la forme «l = … mm». Les 
constr ucteurs de véhicules peuvent remplacer la mesure de ces distances par un calcul théor ique 
tenant comp te de la répar tition du poids du véhicule sur les essieux, à vide et en ordre de marc he (1). 
Les méthodes suivies pour effectuer ce calcul théor ique devront être approuvées par une autori té 
compé tent e de l'État membre et ne pour ront s'appliquer qu'avant l'activation du tach ygraphe; 
v)  «événement»: 
une opération anor male détec tée par le tach ygraphe intelligent et pouvant résulter d'une tentative de 
fraude; 
w)  «dispositif GNSS exte rne»: 
un dispositif contenant le récep teur GNSS lorsque l'unité embarquée sur le véhicule n'est pas une unité 
intégrée, ainsi que les autres composants nécessaires à la protection de la communication des données 
de position au reste de l'unité embarquée sur le véhicule; 
x)  «anomalie»: 
une opération anor male détectée par le tach ygraphe intelligent et pouvant résult er d'un dysf onction ­
nement ou d'une panne de l'appareil; 
y)  «récep teur GNSS»: 
un dispositif électronique qui reçoit et traite numér iquement les signaux émis par un ou plusieurs 
systèmes mondiaux de navig ation par satelli te (GNSS en anglais) afin de déterminer la position, la 
vitesse et l'heure; 
z)  «installation»: 
le montage d'un tach ygraphe dans un véhicule; 26.5.2016 L 139/15 Jour nal officiel de l'Union européenne FR     
(1)Règlement (UE) no 1230/2012 de la Commission du 12 décembre 2012 portant application du règlement (CE) no 661/2009 du 
Parlement européen et du Conseil en ce qui concer ne les prescr iptions pour la réception par type relatives aux masses et dimensions des 
véhicules à moteu r et de leurs remorques et modifiant la directive 2007/46/CE du Parlement européen et du Conseil (JO L 353 du 
21.12.2012, p. 31), tel que modifié en dernier lieu. 
aa)  «interopérabilité»: 
la capacit é des systèmes et des processus sous-jacents à échang er des données et à partager des 
informations; 
bb)  «interface»: 
un mécanisme mis en place entre les systèmes, qui leur permet de communiquer et d'inte ragir; 
cc)  «position» 
les coordonnées géographiques du véhicule à un moment donné; 
dd)  «cap teur de mouvement»: 
un élément du tach ygraphe émettant un signal représentatif de la vitess e et/ou de la distance 
parcour ue par le véhicule; 
ee)  «car te non valable»: 
une carte détectée comme présentant un défa ut, ou dont l'authentification initiale a échoué, ou dont la 
date de début de validité n'a pas encore été atteint e, ou dont la date d'expiration est passée; 
ff)  «nor me ouver te»: 
une norme définie dans une spécifi cation de norme librement accessible ou disponible contre une 
somme symbolique et qu'il est permis de copier , de diffuser ou d'utiliser gratuit ement ou pour une 
somme symbolique; 
gg)  «hors champ»: 
tous les cas où l'utilisation de l'appareil n'est pas requise, conf ormément au règlement (CE) 
no 561/2006; 
hh)  «excès de vitesse»: 
le dépassement de la vitess e autor isée pour le véhicule, pendant tout e période de plus de 60 secondes 
au cours de laquelle la vites se mesurée du véhicule dépasse la limite fixée pour le réglage du dispositif 
de limitation de vitess e dans la directive 92/6/CEE du Conseil (1), telle que modifiée en dernier lieu; 
ii)  «inspection périodique»: 
une série d'opérations de contrôle réalisées pour s'assurer que le tach ygraphe fonctionne correctement, 
que ses réglage s correspondent aux paramètres du véhicule et qu'aucun dispositif de manipulation 
n'est adjoint au tach ygraphe; 
jj)  «imprimante»: 
un compo sant de l'appareil de contrôle qui permet d'im primer les données stoc kées; 
kk)  «communication de la détection précoce à distance»: 
la communication entre le dispositif de communication de la détection précoce à distance et le lecteur 
de communication de la détec tion précoce à distance lors de contrôles routiers ciblés afin de détect er 
à distance une éventuelle manipulation ou mauvaise utilisation de l'appareil de contrôle; 
ll)  «dispositif de communication à distance»: 
l'équipement de l'unité embarquée sur le véhicule utilisé pour les contrôles routiers ciblés; 26.5.2016 L 139/16 Jour nal officiel de l'Union européenne FR     
(1)Directive 92/6/CEE du Conseil du 10 février 1992 relative à l'installation et à l'utilisation, dans la Communauté, de limiteurs de vitesse 
sur certaines catégor ies de véhicules à moteu r (JO L 57 du 2.3.1992, p. 27). 
mm)  «lect eur de communication de la détection précoce à distance»: 
le système utilisé par les agents de contrôle pour les contrôles routiers ciblés; 
nn)  «renouvellement»: 
la délivrance d'une nouvelle carte tach ygraphique lorsqu'une carte arrive à expiration ou ne fonctionne 
pas correctement et a été retour née à l'autori té qui l'a délivrée; le renouvellement suppose la certitude 
que deux cartes en cours de validité ne coexistent pas; 
oo)  «réparation»: 
tout e réparation d'un capt eur de mouvement, d'une unité embarquée ou d'un câble qui impose de le 
ou de la déconnecter de son alimentation électr ique ou d'autres compo sants du tach ygraphe, ou 
d'ouvr ir le capt eur de mouvement ou l'unité embarquée; 
pp)  «rem placement de la carte»: 
la délivrance d'une carte tach ygraphique en rem placement d'une carte existante qui a été déclarée 
perdue, volée ou ne fonctionnant pas correctement, et n'a pas été retournée à l'aut orité qui l'a délivrée; 
le remplacement compo rte touj ours le risque que deux cartes en cours de validité coexist ent; 
qq)  «cer tification de sécur ité»: 
le processus consistant à certifier, par un organisme de certification «critères communs», que l'appareil 
de contrôle (ou le compo sant de cet appareil) ou la carte tach ygraphique satisfait aux exige nces de 
sécur ité définies dans les profils de prot ection correspondants; 
rr)  «aut otest»: 
les tests automatique s effectués périodiquement par l'appareil de contrôle afin de déceler les 
anomalies; 
ss)  «mesure du temps»: 
un enregistrement numér ique en continu de la date et du temps universel coordonné (UTC); 
tt)  «remise à l'heure»: 
un réglage automatique de l'heure à inter valles réguliers et dans la limite d'une tolérance maximale 
d'une minut e, ou un réglage effectué pendant l'étalonnag e; 
uu)  «dimension des pneumatiques»: 
la désignation des dimensions des pneumatiques (roues motr ices extern es) conf ormément à la 
directive 92/23/CEE du Conseil (1), telle que modifiée en dernier lieu; 
vv)  «identification du véhicule»: 
les numéros permettant d'identifier le véhicule: numéro d'immatr iculation (VRN) avec indication de 
l'État membre d'immatr iculation, et numéro d'identification du véhicule (VIN) (2); 
ww)  «semaine», aux fins du calcul dans l'appareil de contrôle: 
une période compris e entre 00:00 heure UTC le lundi et 24:00 heures UTC le dimanch e; 26.5.2016 L 139/17 Jour nal officiel de l'Union européenne FR     
(1)Directive 92/23/CEE du Conseil du 31 mars 1992 relative aux pneumatiques des véhicules à moteu r et de leurs remorques ainsi qu'à leur 
montage (JO L 129 du 14.5.1992, p. 95). 
(2)Directive 76/114/CEE du Conseil du 18 décembre 1975 concer nant le rapprochement des législations des États membres relatives aux 
plaques et inscr iptions réglementaires, ainsi qu'à leurs emplacement et modes d'apposition en ce qui concer ne les véhicules à moteu r et 
leurs remorques (JO L 24 du 30.1.1976, p. 1). 
xx)  «car te d'ate lier»: 
une carte tach ygraphique délivrée par les autori tés d'un État membre à certains membres du personnel 
d'un fabricant de tach ygraphes, d'un installate ur, d'un constr ucteur de véhicules ou d'un atelier, 
homologué par cet État membre. La carte d'ate lier permet l'identifi cation du détent eur ainsi que l'essai, 
l'étalonnag e et l'activation de tach ygraphes et/ou le téléc hargement à partir de ceux-ci; 
yy)  «adapta teur»: 
un dispositif émettant un signal permanent représentatif de la vitesse et/ou de la distance parcour ue 
par le véhicule, autre que celui qui est utilisé pour la détection de mouvement indépendant e, et qui 
est: 
—  installé et utilisé uniquement sur les types de véhicules M1 et N1 (tels que définis à l'annexe II de 
la directive 2007/46/CE du Parlement européen et du Conseil (1), telle que modifi ée en dernier 
lieu) mis en circulation pour la première fois après le 1er mai 2006, 
—  installé lorsqu'il n'est pas mécaniquement possible d'installer un autre type de capt eur de 
mouvement par ailleurs conf orme aux dispositions de la présent e annexe et de ses appendices 1 
à 15, 
—  installé entre l'unité embarquée sur le véhicule et le point d'où les impulsions de distance et de 
vitesse sont fournies par des capt eurs intégrés ou des interfaces de rem placement ; 
—  vu d'une unité embarquée, le compo rtement de l'adaptat eur est le même que si un capt eur de 
mouvement, conf orme aux dispositions de la présente annex e et de ses appendices 1 à 16, était 
connecté à l'unité embarquée sur le véhicule; 
l'utilisation d'un tel adaptat eur dans les véhicules décr its ci-dessus doit permettre l'installation et l'utili ­
sation correcte d'une unité embarquée conf orme à tout es les exigenc es de la présent e annexe ; 
pour ces véhicules, le tach ygraphe intelligent compr end des câbles, un adaptat eur et une unité 
embarquée sur le véhicule; 
zz)  «intégrité des données»: 
la précision et la cohérence des données stoc kées, indiquées par l'absence de tout e modification des 
données entre deux mises à jour d'un enregistrement de données. L'int égrité implique que les données 
soient la copie exacte de leur version originale et qu'elles n'aient par exem ple pas été endommagées 
lors des processus d'écr iture et de lecture vers et à partir d'une carte tach ygraphique, d'un équipement 
dédié ou lors de leur transmission via un canal de communication quel qu'il soit; 
aaa)  «confidentialité des données»: 
les mesures techniques globales prises pour assurer la bonne mise en œuvre des principes énoncés 
dans la directive 95/46/CE du Parlement européen et du Conseil (2), ainsi que de ceux énoncés dans la 
directive 2002/58/CE du Parlement européen et du Conseil (3); 
bbb)  «tachygraphe intelligent»: 
l'appareil de contrôle, les cartes tach ygraphiques et l'ensemble des équipements qui inter agissent 
direct ement ou indirect ement au cours de leur constr uction, de leur installation, de leur utilisation, des 
essais et des contrôles, tels que les cartes, les lecteurs de communication à distance et tout autre 
équipement servant au téléc hargement de données, à l'analyse des données, à l'étalonnag e, à la 
génération, à la gestion ou à l'introduction d'éléments de sécur ité, etc.; 
ccc)  date de mise en œuvre: 
36 mois après l'entrée en vigueur des dispositions détaillées visées à l'article 11 du règlement (UE) 
no 165/2014 du Parlement européen et du Conseil (4). 26.5.2016 L 139/18 Jour nal officiel de l'Union européenne FR     
(1)Directive 2007/46/CE du Parlement européen et du Conseil du 5 septembre 2007 établissant un cadre pour la réception des véhicules à 
moteu r, de leurs remorques et des systèmes, des com posants et des entit és techniques destinés à ces véhicules (directive-cadre) (JO L 263 
du 9.10.2007, p. 1). 
(2)Directive 95/46/CE du Parlement européen et du Conseil du 24 octobre 1995 relative à la prot ection des personnes physiques à l'égard 
du traitem ent des données à caractère personnel et à la libre circulation de ces données (JO L 281 du 23.11.1995, p. 31). 
(3)Directive 2002/58/CE du Parlement européen et du Conseil du 12 juillet 2002 concer nant le traitement des données à caractère 
personnel et la protection de la vie privée dans le secteu r des communications électroniques (directive vie privée et communications 
électroniques) (JO L 201 du 31.7.2002, p. 37). 
(4)Règlement (UE) no 165/2014 du Parlement Européen et du Conseil du 4 février 2014 relatif aux tach ygraphes dans les transpor ts 
routiers, abrogean t le règlement (CEE) no 3821/85 du Conseil concer nant l'appareil de contrôle dans le domaine des transpor ts par route 
et modifian t le règlement (CE) no 561/2006 du Parlement européen et du Conseil relatif à l'har monisation de certaines dispositions de la 
législation sociale dans le domaine des transpor ts par route (JO L 60 du 28.2.2014, p. 1). 
Il s'agit de la date après laquelle les véhicules immatr iculés pour la premièr e fois: 
—  doivent être équipés d'un tachyg raphe connecté à un service de positionnement s'appuyant sur un système de 
navig ation par satellite, 
—  doivent être capables, lorsque le véhicule est en mouvement, de communiquer des données aux autor ités de 
contrôle compétentes à des fins de contrô les routiers ciblés, 
—  et peuvent être équipés d'une interf ace normalisée permettant l'utilisation en mode opérationnel, par un 
dispositif extér ieur, des données enregistré es ou produites par le tachyg raphe; 
ddd)  «profil de protection»: 
un document utilisé dans le cadre d'un processus de certificat ion selon les «critères communs», qui 
définit, indépendamment de tout e mise en œuvre, les exigenc es de sécur ité en matière de garantie de 
l'information; 
eee)  «précision GNSS»: 
dans le cadre de l'enregistrement de la position par un système mondial de navig ation par satellite 
(GNSS) à l'aide de tach ygraphes, la valeur du coefficient d'aff aiblissement de la précision de position ­
nement horizontal (HDOP) calculée comme la minimale des valeurs HDOP recueillies sur les systèmes 
GNSS disponibles. 
2.  CARA CTÉRISTIQUES GÉNÉRALES ET FONCTIONS DE L'APP AREIL DE CONTRÔLE 
2.1  Caractér istiques générales 
La fonction de l'appareil de contrôle est d'enregistrer , de stoc ker, d'affi cher, d'imp rimer et de produire des 
données concer nant les activités du conduct eur. 
Tout véhicule équipé d'un appareil de contrôle conf orme aux dispositions de la présent e annexe doit 
compo rter un indicateur de vitesse et un comp teur kilométr ique. Ces fonctions peuvent être incluses dans 
l'appareil de contrôle. 
1)  L'appareil de contrôle comprend des câbles, un capt eur de mouvement et une unité embarquée sur le 
véhicule. 
2)  L'interface entre les capt eurs de mouvement et les unités embarquées se conf orme aux dispositions de 
l'appendice 11. 
3)  L'unité embarquée sur le véhicule doit être connecté e à un ou plusieurs systèmes mondiaux de 
navig ation par satellit e, comme indiqué à l'appendice 12. 
4)  L'unité embarquée sur le véhicule doit communiquer avec des lecteurs de communication et de 
détec tion précoces à distance conf ormément à l'appendice 14. 
5)  L'unité embarquée sur le véhicule peut compo rter une interface ITS, qui est spécifiée à l'appendice 13. 
L'appareil de contrôle peut être relié à d'autres équipements par le biais d'inte rfaces supplémentaires 
et/ou de l'interface ITS facultative. 
6)  Toute inser tion ou connexion de tout e fonction ou dispositif(s), homologué(s) ou non, dans ou à 
l'appareil de contrôle, ne doit pas interf érer ou être suscept ible d'interférer avec le fonctionnement 
correct et sûr de l'appareil de contrôle, ni avec les dispositions du présent règlement. 
Les utilisateurs de l'appareil de contrôle s'identifien t dans l'appareil à l'aide de cartes tach ygraphiques. 
7)  L'appareil de contrôle ouvre des droits d'accès sélectifs aux données et fonctions, selon le type et/ou 
l'identit é de l'utilisateur . 26.5.2016 L 139/19 Jour nal officiel de l'Union européenne FR     
L'appareil de contrôle enregistre et stoc ke des données dans sa mémoire, dans le dispositif de communi ­
cation à distance et sur les cartes tach ygraphiques. 
Ces fonctions sont assurées dans le respect de la directive 95/46/CE du 24 octobre 1995 relative à la 
prote ction des personnes physiques à l'égard du traitement des données à caractère personnel et à la libre 
circulation de ces données (1), de la directive 2002/58/CE du 12 juillet 2002 concer nant le traite ment des 
données à caractère personnel et la protection de la vie privée dans le secte ur des communications électro ­
niques (2) et en conf ormité avec l'article 7 du règlement (UE) no 165/2014. 
2.2  Fonctions 
8)  L'appareil de contrôle doit assurer les fonctions suivantes: 
—  surveillance des inser tions et retraits de carte, 
—  mesure de la vitesse, de la distance parcour ue et de la position, 
—  mesure du temps, 
—  suivi des activités du conduct eur, 
—  suivi de la situation de conduite , 
—  saisie manuelle de données par le conducteur: 
—  lieu de début et/ou de fin des périodes jour nalières de travai l, 
—  saisie manuelle des activités du conducteur , 
—  saisie des conditions particulières, 
—  gestion des verrouillages d'entrepr ise, 
—  suivi des activités de contrôle, 
—  détection des événements et/ou des anomalies, 
—  autot ests intégrés , 
—  lecture de données stoc kées sur la mémoire, 
—  enregistrement et stockag e de données sur la mémoire, 
—  lecture des cartes tach ygraphiques, 
—  enregistrement et stockag e de données sur les cartes tach ygraphiques, 
—  affichage, 
—  impression, 
—  avertissement, 
—  téléc hargem ent de données vers des médias externes, 
—  communication à distance pour les contrôles routiers ciblés, 
—  sortie de données vers des équipements additionnels, 
—  étalonnage, 
—  contrôle routier d'étalonnag e, 
—  remise à l'heure. 26.5.2016 L 139/20 Jour nal officiel de l'Union européenne FR     
(1)JO L 281 du 23.11.1995, p. 31. 
(2)JO L 201 du 31.7.2002, p. 37 
2.3  Modes de fonctionnement 
09)  L'appareil de contrôle doit permettre quatre modes de fonctionnement: 
—  mode «opérationnel», 
—  mode «contrôle», 
—  mode «étalonnage », 
—  mode «entrepr ise». 
10)  L'appareil de contrôle doit basculer dans les modes de fonctionnement suivants selon la carte 
tach ygraphique valable insérée dans l'inte rface de carte. La génération à laquelle appar tient la carte du 
tach ygraphe n'est pas pertinente en vue de déter miner le mode de fonctionnement à condition que la 
carte insérée soit valable. Une carte d'atelier de première génération doit touj ours être considérée 
comme non valable lorsqu'elle est insérée dans une unité embarquée de deuxième génération. 
Mode de fonctionnement Lect eur «conducteur» 
Pas de carte Carte du conduc ­
teur Carte de contrô ­
leur Carte d'ateli er Carte d'entrepr ise Lecteur «convoyeur» Pas de carte Opérationnel Opérationnel Contrôle Étalonnag e Entrepr ise 
Carte du 
conducteur Opérationnel Opérationnel Contrôle Étalonnag e Entrepr ise 
Carte de contrô ­
leur Contrôle Contrôle Contrôle (*) Opérationnel Opérationnel 
Carte d'atelier Étalonnage Étalonnag e Opérationnel Étalonnag e(*) Opérationnel 
Carte d'entre ­
prise Entrepr ise Entrepr ise Opérationnel Opérationnel Entrepr ise(*) 
(*)  En pareil cas, l'appareil de contrôle utilise uniquement la carte tach ygraphique insérée dans le lecteur «conducteur ».  
11)  L'appareil de contrôle doit refuser les cartes non valables, sauf pour l'affichag e, l'impre ssion ou le 
téléc hargement des données présentes sur une carte périmée, qui doit être possible. 
12)  Toutes les fonctions énumérées au point 2.2 doivent être disponibles dans tous les modes de 
fonctionnement, à l'exception de: 
—  la fonction d'étalonnag e, accessible uniquement en mode étalonnage, 
—  la fonction de contrôle routier d'étalonnag e, accessible uniquement en mode contrôle, 
—  la fonction de gestion des verrouillages d'entrepr ise, accessible uniquement en mode entrepr ise, 
—  le suivi des activité s de contrôle, accessible uniquement en mode contrôle, 
—  la fonction de téléc hargement, non accessible en mode opérationnel (sauf dans les cas prévus à 
l'exig ence 193), excep té le téléc harg ement d'une carte de conduct eur lorsqu'aucun autre type de 
carte n'est inséré dans la VU. 
13)  L'appareil de contrôle peut extraire tout e donnée pour affichage, impression ou télécharg ement vers 
des interfaces externes, sauf: 
—  en mode opérationnel, tout e identif ication personnelle [nom et prénom(s)] ne correspondant pas 
à la carte tach ygraphique insérée sera masquée, et tout numéro de carte ne correspondant pas à la 
carte tach ygraphique insérée sera partiellement masqué (un caractère sur deux, de gauc he à 
droite), 26.5.2016 L 139/21 Jour nal officiel de l'Union européenne FR     
—  en mode entrepr ise, les données relatives au conduct eur (exigen ces 102, 105 et 108) peuvent être 
extraite s seulement pour les périodes où aucun verrouillage n'existe ou où aucune autre entrepr ise 
(telle qu'identif iée par les 13 premiers chiffres du numéro de la carte d'entrepr ise) ne détient de 
verrouillage, 
—  lorsqu'aucune carte n'est insérée dans l'appareil de contrôle, seules peuvent être extraites les 
données relatives au conduct eur pour le jour même et les 8 jours civils précédents, 
—  les données à caractère personnel provenant de la VU ne doivent pas être extrait es via l'interface 
ITS de la VU à moins que le consentem ent du conducteur à qui se rappor tent ces données soit 
vérifié, 
—  les unités embarquées ont une période de validité opérationnelle normale de 15 ans à partir de la 
date de délivrance de leurs certificats mais peuvent être utilisées pendant 3 mois supplémentaires, 
uniquement aux fins du téléc harg ement de données. 
2.4  Sécur ité 
La sécur ité du système vise à proté ger la mémoire de manière à empêc her l'accès non autorisé et la 
manipulation de données, et à détec ter les tentatives de manipulation, à préser ver l'intégri té et l'authenticit é 
des données échang ées entre le capt eur de mouvement et l'unité embarquée sur le véhicule ainsi qu'entre 
l'appareil de contrôle et les cartes tach ygraphiques, à préser ver l'intégri té et l'authenticit é des données 
échang ées entre l'appareil de contrôle et le dispositif GNSS externe, à préser ver la confidentialité, l'inté grité 
et l'authenticit é des données écha ngées via la communication de détection précoce à distance à des fins de 
contrôle, et enfin à vérifier l'inté grité et l'authenticité des données téléc hargée s. 
14)  Afin d'assurer la sécur ité du système, les composants suivants doivent satisfaire aux exigenc es 
spécifi ées dans leur prof il de prot ection, comme le requier t l'appendice 10: 
—  unité embarquée sur le véhicule, 
—  carte tach ygraphique, 
—  capt eur de mouvement, 
—  dispositif GNSS externe (ce prof il n'est nécessaire et applicable que pour la variante du GNSS 
externe). 
3.  EXIGENCES CONSTR UCTIVES ET FONCTIONNELLES APPLICABLES À L'APP AREIL DE CONTRÔLE 
3.1  Suivi de l'inser tion et du retrait des cartes 
15)  L'appareil de contrôle doit assurer le suivi des inser tions et retraits de carte. 
16)  Lors de l'inser tion d'une carte, l'appareil de contrôle vérifie la validité de la carte et identif ie son type 
et la génération à laquelle elle appar tient. 
Si une carte portant le même numéro de carte et un indice de renouvellement supér ieur a déjà été 
insérée dans l'appareil de contrôle, la carte est déclarée non valable. 
Si une carte portant le même numéro de carte et le même indice de renouvellement, mais un indice 
de rem placement supér ieur, a déjà été insérée dans l'appareil de contrôle, la carte est déclarée non 
valable. 
17)  Les cartes tach ygraphiques de première génération doivent être considérées comme non valables par 
l'appareil de contrôle après que la possibilit é d'utiliser des cartes tach ygraphiques de première 
génération a été suppr imée par un atelier , en conf ormité avec l'appendice 15 (exige nce MIG003). 
18)  Les cartes d'atelier de première génération qui sont insérées dans l'appareil de contrôle de deuxième 
génération doivent être considérées comme non valables. 
19)  L'appareil de contrôle doit être conçu de manière à ce que les cartes tach ygraphiques soient 
verrouillées en position correcte dans l'inte rface. 26.5.2016 L 139/22 Jour nal officiel de l'Union européenne FR     
20)  Le retrait d'une carte tach ygraphique n'est possible que lorsque le véhicule est à l'arrêt, et après que 
les données pertinentes ont été stoc kées sur la carte. Le retrait de la carte nécessite une inter vention 
concrète de l'utilisat eur. 
3.2  Mesure de la vitesse, de la position et de la distance parcour ue 
21)  Le capt eur de mouvement (éventuellement intégré dans l'adaptat eur) est la principale source de 
mesure de la vites se et de la distance parcour ue. 
22) Cette fonction assure une mesure en continu et permet d'indiquer la valeur kilométr ique corres­
pondant à la distance totale parcour ue par le véhicule en utilisant les impulsions envoyées par le 
capt eur de mouvement. 
23)  Cette fonction assure une mesure en continu et permet d'indiquer la vites se du véhicule en utilisant 
les impulsions envoyées par le capt eur de mouvement. 
24)  La fonction de mesure de la vitess e doit également indiquer si le véhicule est en mouvement ou à 
l'arrêt. La fonction de mesure de la vites se doit également indiquer si le véhicule est en mouvement 
ou à l'arrêt. Le véhicule est considéré en mouvement dès que la fonction détect e plus de 1 imp/s 
pendant au moins 5 secondes en provenance du capt eur de mouvement, et dans le cas contraire le 
véhicule est considéré à l'arrêt. 
25)  Les dispositifs indicateurs de vitess e et kilométr iques installés sur tout véhicule muni d'un appareil de 
contrôle conf orme au présent règlement doivent satisfaire aux exigences concer nant les tolérances 
maximales (voir points 3.2.1 et 3.2.2) fixées dans la présent e annexe. 
26)  Pour détect er la manipulation de données de mouvement, les informations provenant du capt eur de 
mouvement sont corroborées par des informations relatives au mouvement du véhicule provenant du 
récept eur GNSS et éventuellement d'une ou plusieurs autres sources indépendantes du capt eur de 
mouvement. 
27)  Cette fonction doit mesurer la position du véhicule afin de permettre l'enregistrement automa tique: 
—  des positions correspondant aux lieux où le conduct eur et/ou le conv oyeur commencent leur 
période de travail jour nalière, 
—  des positions correspondant aux lieux où le temps de conduite continue du conduct eur atteint un 
multiple de trois heures, 
—  des positions correspondant aux lieux où le conduct eur et/ou le convoyeur term inent leur période 
de travai l jour nalière. 
3.2.1  Mesure de la distance parcouru e 
28)  La distance parcour ue peut être mesurée de manière à: 
—  soit cumuler les mouvements en march e avant et en marche arrière, 
—  soit prendre uniquement en comp te les mouvements en marche avant. 
29)  L'appareil de contrôle doit mesurer la distance parcour ue de 0 à 9 999 999,9 km. 
30)  La distance mesurée doit être dans les tolérances suivantes (distances d'au moins 1 000 m): 
—  ± 1 % avant installation, 
—  ± 2 % lors de l'installation et des inspections périodiques, 
—  ± 4 % en service. 
31)  La distance mesurée doit avoir une résolution meilleure que ou égale à 0,1 km. 
3.2.2  Mesure de la vitesse 
32)  L'appareil de contrôle doit mesurer la vitesse de 0 à 220 km/h. 26.5.2016 L 139/23 Jour nal officiel de l'Union européenne FR     
33)  Afin de garantir une tolérance maximale sur la vitesse indiquée de ± 6 km/h en service, et en tenant 
comp te: 
—  d'une tolérance de ± 2 km/h pour les variations du signal d'entrée (var iations dues aux 
pneumatiques, etc.), 
—  d'une tolérance de ± 1 km/h sur les mesures effectuées au cours de l'installation et des inspections 
périodiques, 
l'appareil de contrôle doit, pour les vitesses comprises entre 20 et 180 km/h, et pour des coeffi cients 
caractér istiques du véhicule compr is entre 4 000 et 25 000 imp/km, mesurer la vitesse avec une 
tolérance de ± 1 km/h (à vitess e constante ). 
Remarque: la résolution du stoc kage des données entraîne une tolérance additionnelle de ± 0,5 km/h 
sur la vitesse stoc kée par l'appareil de contrôle. 
34)  La vitesse doit être mesurée correctement, dans les tolérances normales, dans les 2 secondes qui 
suivent la fin d'un changement de vites se, lorsque la vitess e a changé à un rythme allant jusqu'à 
2 m/s2. 
35)  La mesure de la vitess e doit avoir une résolution meilleure que ou égale à 1 km/h. 
3.2.3  Mesure de la position 
36)  L'appareil de contrôle doit mesurer la position absolue du véhicule à l'aide du récep teur GNSS. 
37)  La position absolue est mesurée sous forme de coordonnées géographiques en degrés et minutes de 
latitude et de longitude, avec une résolution d'un dixième de minute . 
3.3  Mesure du temps 
38)  La fonction de mesure du temps doit assurer une mesure en continu et un affichage numér ique de la 
date et de l'heure UTC. 
39)  La date et l'heure UTC sont utilisées pour dater les données à l'intér ieur de l'appareil de contrôle 
(enregistrements, échang e de données) et pour tous les tirages papier spécifiés à l'appendice 4 «Tirag es 
papier». 
40)  Afin de visualiser l'heure locale, il doit être possible de changer le décalage horaire de l'heure affichée, 
par paliers d'une demi-heure. Aucun autre décalage qu'un multiple positif ou négat if de la demi-heure 
n'est autori sé. 
41)  La dérive temporelle ne doit pas excéder ± 2 secondes par jour dans les conditions d'homolog ation, 
en l'absence de tout e remise à l'heure. 
42)  Le temps mesuré doit avoir une résolution meilleure que ou égale à 1 seconde. 
43)  La mesure du temps ne doit pas être affect ée par une coupure de l'alimentation électr ique externe 
d'une durée inférieure à 12 mois dans les conditions d'homolog ation. 
3.4  Sur veillance des activités du conducteur 
44)  Cette fonction doit assurer une surveillance permanent e et séparée des activités d'un seul conducteur 
et d'un seul conv oyeur . 
45)  L'activité du conducteur doit être la CONDUITE, le TRA VAIL, la DISPONIBILITÉ ou la PAUSE/REPOS. 
46)  Il doit être possible au conducteur et/ou au conv oyeur de sélectionner manuellement l'activit é 
TRA VAIL, DISPONIBILITÉ ou PAUSE/REPOS. 
47)  Lorsque le véhicule est en mouvement, l'activité CONDUITE doit être automatiquement sélectionnée 
pour le conducteur , et l'activité DISPONIBILITÉ doit être automatiquement sélectionnée pour le 
conv oyeur . 26.5.2016 L 139/24 Jour nal officiel de l'Union européenne FR     
48)  Lorsque le véhicule s'arrête, l'activité TRA VAIL doit être automatiquement sélectionnée pour le 
conducteur . 
49)  Le premier changement d'activité vers REPOS ou DISPONIBILITÉ intervenant dans les 120 secondes 
qui suivent la sélection automatique de l'activité TRA VAIL en raison de l'arrêt du véhicule doit être 
considéré comme étant inter venu au moment de l'arrêt du véhicule (et peut par conséquent annuler 
le passage à l'activité TRA VAIL). 
50)  Cette fonction doit transmettre les changem ents d'activit é vers les fonctions d'enregistrement avec une 
résolution d'une minute. 
51)  Étant donné une minut e calendr ier, si la CONDUITE est enregistrée comme activité tant au cours de 
la minute qui précède que de la minute qui suit immédiatement, la minute entière est comp tabilisée 
comme de la CONDUITE. 
52)  Étant donné une minute calendr ier non considérée comme activité de CONDUITE en application de 
l'exigence 051, la minut e entière sera considérée comme relevant de la même activité que l'activité 
continue la plus longue survenue dans la minute (ou de la plus récente dans le cas de plusieurs 
activités de même durée). 
53)  Cette fonction doit également permettre le suivi permanent du temps de travail continu et le temps 
de pause cumulé du conduct eur. 
3.5  Sur veillance de l'état de conduite 
54)  Cette fonction doit assurer en permanence et automatique ment la surveillance de la situation de 
conduite. 
55)  La situation de conduite ÉQUIP AGE doit être sélectionnée lorsque deux cartes de conducteur en cours 
de validité sont insérées dans l'appareil, et la situation de conduite SEUL doit être sélectionnée dans 
tous les autres cas. 
3.6  Saisie par le conducteur 
3.6.1  Saisie du lieu de début et/ou de fin de la période de travail journalière 
56)  Cette fonction doit permettre la saisie des lieux où, selon le conduct eur et/ou le conv oyeur, leurs 
périodes de travail jour nalières commencent et/ou se term inent. 
57)  On entend par «lieu» le pays et, le cas échéa nt, la région, qui sont saisis ou conf irmés manuellement. 
58)  Lors du retrait d'une carte de conducteur , l'appareil de contrôle doit invit er le conduct eur/conv oyeur à 
saisir le «lieu où s'achève la période de travail jour nalière». 
59)  Le conducteur renseigne alors l'em placement actuel du véhicule, ce qui est considéré comme la saisie 
temporaire. 
60)  Il doit être possible de saisir le lieu de début et/ou de fin d'une période de travai l jour nalière au 
moyen de commandes dans les menus. Si plusieurs saisies de ce type sont effectuées au cours d'une 
minute calendr ier, seuls le dernier lieu de début et le dernier lieu de fin qui ont été saisis au cours de 
cette durée sont gardés enregistrés. 
3.6.2  Saisie manuelle des activités du conducteur et consentement du conducteur pour l'interface ITS 
61)  Lors de l'inser tion d'une carte de conducteur (ou d'ateli er), et seulement à ce moment, l'appareil de 
contrôle doit permettre la saisie manuelle d'activités. La saisie manuelle d'activit és est effectuée en 
indiquant la date et l'heure locale du fuseau horaire (décalage UTC) sélectionné pour l'unit é 
embarquée. 
Lors de l'inser tion de la carte de conduct eur ou d'ateli er, les informations suivante s sont rappelées au 
détent eur de la carte: 
—  la date et l'heure du dernier retrait de la carte, 
—  facultativement: le décalage de l'heure locale sélectionné pour l'unité embarquée. 26.5.2016 L 139/25 Jour nal officiel de l'Union européenne FR     
Lors de la première inser tion d'une carte de conduct eur ou d'atelier qui est encore inconnue de l'unité 
embarquée sur le véhicule, le détenteur est invit é à donner son accord pour que les données 
personnelles en lien avec le tach ygraphe puissent être extraites via l'interface ITS facultative. 
L'accord du conducteur/de l'ate lier peut être activé ou désactivé à tout moment par des commandes 
se trouvant dans le menu, à condition que la carte du conduct eur/de l'atelier soit insérée. 
Il doit être possible de saisir des activités, moyennant les restr ictions suivantes: 
—  le type d'activité doit être le TRA VAIL, la DISPONIBILITÉ ou la PAUSE/REPOS, 
—  les heures de début et de fin pour chaque activité doivent se situer excl usivement dans la période 
séparant le dernier retrait de l'inser tion actuelle de la carte, 
—  les activités ne doivent pas se chevaucher dans le temps. 
Il doit être possible d'eff ectuer des saisies manuelles, si nécessaire, lors de la première inser tion d'une 
carte de conduct eur (ou d'ate lier) encore inutilisée. 
La procédure de saisie manuelle d'activit és compre nd autant d'étapes consécutives que nécessaire 
pour sélectionner un type, une heure de début et une heure de fin pour chaque activité. Pour tout e 
partie de la période séparant le dernier retrait de la carte de son inser tion actuelle, le détent eur a le 
choix de ne déclarer aucune activité. 
Au cours des saisies manuelles associées à l'inser tion de la carte, le détent eur de celle-ci a, le cas 
échéant, la possibilité de saisir: 
—un lieu où s'est achevée une période de travail jour nalière précédente, associé à l'heure corres­
pondant e (qui se substitue à la saisie effectuée lors du dernier retrait de la carte), 
—  un lieu où débute la période de travail jour nalière actuelle, associé à l'heure correspondant e. 
Si le détenteur de la carte ne renseigne aucun emplacement de début ou de fin de la période de 
travail lors des saisies manuelles associées à l'inser tion de la carte, le logiciel considère qu'il s'agit 
d'une déclaration de période de travail identique à celle associée au précédent retrait de la carte. La 
saisie suivante d'un lieu où s'est achevée une période de travail jour nalière précédente se substitue 
alors à la saisie temporaire effectuée lors du dernier retrait de la carte. 
En cas de saisie d'un lieu, celui-ci est enregistré sur la carte tach ygraphique appropr iée. 
La saisie manuelle est interr ompue si: 
—  la carte est retirée ou 
—  le véhicule est mis en mouvement alors que la carte se trouve dans le lecteur réser vé au 
conduct eur. 
Des interrupti ons supplémentaires sont autori sées, par exem ple une temporisation après une certaine 
période d'inactivité de l'utilisateur . En cas d'interr uption de la saisie manuelle, l'appareil de contrôle 
valide tout e saisie compl ète de lieu et d'activité déjà effectuée (indiquant sans ambiguïté un lieu et une 
heure, ou un type d'activité, une heure de début et une heure de fin). 
Si une seconde carte de conduct eur ou d'ateli er est insérée alors que la saisie manuelle d'activit és est 
en cours pour une carte insérée auparavant, la saisie concer nant cette première carte doit pouvoi r 
être achevée avant le début de la saisie manuelle pour la seconde carte. 
Le détenteur de la carte a la possibilit é d'effectuer une saisie manuelle selon la procédure minimale 
suivante: 
—  saisie manuelle des activités, par ordre chronologique, pour la période allant du dernier retrait de 
la carte à son inser tion actuelle, 26.5.2016 L 139/26 Jour nal officiel de l'Union européenne FR     
—  l'heure de début de la première activité est fixée à l'heure du retrait de la carte. Pour chaque saisie 
ultérieure, l'heure de début présélectionnée suit immédiatement l'heure de fin de la saisie 
précédente. Le type d'activit é et l'heure de fin doivent être sélectionnés pour chaque activité. 
La procédure se term ine lorsque l'heure de fin d'une activité saisie manuellement correspond à l'heure 
d'inser tion de la carte. L'appareil de contrôle peut alors, à titre facultatif, permettre au détenteur de la 
carte de modifier tout e activité saisie manuellement, jusqu'à la validation par la sélection d'une 
commande particulière. Par la suite, tout e modification de ce type est interdit e. 
3.6.3  Saisie de conditions particulières 
62)  L'appareil de contrôle doit permettre au conduct eur de saisir en temps réel les deux conditions 
particulières suivantes : 
—  «HORS CHAMP» (début, fin), 
—  «TRAJET EN FERR Y/TRAIN» (début, fin). 
Un «TRAJET EN FERR Y/TRAIN» ne peut survenir lorsque la condition «HORS CHAMP» est ouver te. 
Une condition «HORS CHAMP» ouver te doit impérativement être automatique ment fermée en cas de 
retrait ou d'inser tion d'une carte de conduct eur. 
Une condition «HORS CHAMP» ouver te doit empêcher les événements et avertissements suivants: 
—  conduite sans carte appropr iée, 
—  avertissements liés à un temps de conduit e continue. 
Le début du TRAJET EN FERR Y/TRAIN doit être pointé avant l'arrêt du moteur sur le ferry/train. 
Un TRAJET EN FERR Y/TRAIN ouver t doit se term iner lorsque l'une des possibilités suivantes se 
produit : 
—  le conduct eur met fin au TRAJET EN FERR Y/TRAIN manuellement, 
—  le conduct eur éjecte sa carte, 
Un TRAJET EN FERR Y/TRAIN ouver t prend fin lorsqu'il n'est plus valable selon les règles énoncées 
dans le règlement (CE) no 561/2006. 
3.7  Gestion des dispositifs de verrouillage de l'entrepr ise 
63)  Cette fonction doit permettre la gestion des verrouillages placés par une entrepr ise en vue de 
restreindre à elle seule l'accès aux données en mode «entrepr ise». 
64)  Les verrouillages d'entrepr ise consistent en une date et une heure de début (verrouillage) et une date 
et une heure de fin (déver rouillage) associées à l'identification de l'entrepr ise par le numéro de carte 
d'entrepr ise (lors du verrouillage). 
65)  Le verrouillage et le déver rouillage ne sont possibles qu'en temps réel. 
66)  Le déver rouillage ne peut être effectué que par l'entrepr ise qui a verrouillé (telle qu'identif iée par les 
13 premiers chiffres du numéro de la carte d'entrepr ise), ou 26.5.2016 L 139/27 Jour nal officiel de l'Union européenne FR     
67)  le déver rouillage est automatique lorsqu'une autre entrepr ise verrouille. 
68)  Dans le cas où une entrepr ise verrouille et où le verrouillage précédent a été effectué pour la même 
entrepr ise, on supposera que le verrouillage précédent n'a pas été déver rouillé et qu'il est touj ours en 
fonction. 
3.8  Suivi des activités de contrôle 
69)  Cette fonction assure le suivi des activités d'AFFICHA GE, d'IMPRESSION, de TÉLÉCHAR GEMENT 
depuis l'unité embarquée sur le véhicule ou la carte et de contrôle ROUTIER de l'ÉTALONNA GE, 
tout es menées en mode «contrôle». 
70)  Cette fonction assure également le suivi des activités de CONTRÔLE DE VITESSE en mode «contrôle». 
Un contrôle de vitesse est supposé avoir eu lieu lorsqu'en mode «contrôle» un message «excès de 
vitesse» a été envoyé sur l'impr imant e ou l'écran, ou lorsque des données «événements ou anomalies» 
ont été téléc hargée s depuis la mémoire de la VU. 
3.9  Détection d'év énements et/ou d'anomalies 
71)  Cette fonction détecte les événements et/ou anomalies suivants: 
3.9.1  Événement «Inser tion d'une carte non valable» 
72)  Cet événement est déclenché par l'inser tion d'une carte non valable, par l'inser tion d'une carte de 
conducteur déjà remplacée et/ou lorsque la validité d'une carte insérée vient à expiration. 
3.9.2  Événement «Conf lit de carte» 
73)  Cet événement est déclenché pour chacune des combinaisons de cartes marquées d'une croix dans le 
tableau suivant : 
Conf lit de carte Lect eur «conducteur» 
Pas de carte Carte du conduc ­
teur Carte de contrô ­
leur Carte d'ateli er Carte d'entrepr ise Lecteur «convoyeur» Pas de carte      
Carte du 
conducteur    X  
Carte de contrô ­
leur   X X X 
Carte d'atelier  X X X X 
Carte d'entre ­
prise   X X X  
3.9.3  Événement «Che vauchemen t temporel» 
74)  Cet événement est déclenché lorsque la date /l'heure de dernier retrait d'une carte de conduct eur, tel 
qu'elle apparaît sur la carte, est postérieur e à la date/l'heure actuelle de l'appareil de contrôle dans 
lequel la carte est insérée. 26.5.2016 L 139/28 Jour nal officiel de l'Union européenne FR     
3.9.4  Événement «Conduite sans carte appropri ée» 
75)  Cet événement est déclenché pour tout e combinaison de cartes tach ygraphiques valables marquée 
d'une croix dans le tableau suivant, lorsque l'activité du conduct eur devient «CONDUI TE», ou en cas 
de chang ement de mode de fonctionnement lorsque l'activité du conduct eur est CONDUITE: 
Conduite sans carte 
appropr iée Lect eur «conducteur» 
Pas de carte (ou 
carte non valable) Carte du conduc ­
teur Carte de contrô ­
leur Carte d'ateli er Carte d'entrepr ise Lecteur «convoyeur» Pas de carte (ou 
carte non va­
lable) X  X  X 
Carte du 
conducteur X  X X X 
Carte de contrô ­
leur X X X X X 
Carte d'atelier X X X  X 
Carte d'entre ­
prise X X X X X  
3.9.5  Événement «Inser tion d'une carte en cours de conduite» 
76)  Cet événement est déclenché lorsqu'une carte tach ygraphique est insérée dans un lecteur quelconque 
alors que l'activit é du conducteur est CONDU ITE. 
3.9.6  Événement «Der nière session incor rectemen t clôturée» 
77)  Cet événement est déclench é lorsque l'appareil de contrôle détecte lors de l'inser tion de la carte que, 
malgré les dispositions du paragraphe 3.1., la session précédente n'a pas été correctement clôturée (la 
carte a été retirée avant que tout es les données nécessaires aient été enregistrées sur la carte). Cet 
événement ne peut concer ner que les cartes de conducteur et d'atelier . 
3.9.7  Événement «Excès de vitesse» 
78)  Cet événement est déclenché lors de chaque excès de vites se. 
3.9.8  Événement «Inter ruption de l'alimentation électr ique» 
79)  Cet événement est déclenché, en mode autre qu'étalonnage ou contrôle, en cas d'inte rrupti on pendant 
plus de 200 millisecondes de l'alimentation électr ique du capt eur de mouvement et/ou de l'unit é 
embarquée sur le véhicule. Le seuil d'interr upti on est fixé par le fabricant. La rupture de l'alimentation 
électr ique due au démar rage du mote ur du véhicule ne doit pas déclench er cet événement. 
3.9.9  Événement «Erreur de communication avec le dispositif de communication à distance» 
80)  Cet événement est déclenché en mode autre qu'«étalonnage» et que le dispositif de communication 
à distance ne confir me pas la bonne récep tion de données de communication à distance envoyées par 
l'unité embarquée sur le véhicule à plus de trois repr ises. 
3.9.10  Événement «Absence d'inf ormations de positionnement en provenance du récep teur GNSS» 
81)  Cet événement est déclench é lorsque la VU n'est pas en mode étalonn age, que le récep teur GNSS 
(intern e ou exte rne) ne fournit aucune information de position pendant plus de trois heures de 
conduite consécutives. 26.5.2016 L 139/29 Jour nal officiel de l'Union européenne FR     
3.9.11  Événement «Erreur de communication avec le dispositif GNSS exter ne» 
82)  Cet événement est déclenché en mode autre qu'«étalonnage», que la communication entre le 
dispositif GNSS exte rne et l'unit é embarquée sur le véhicule est interr ompue pendant plus de 20 
minutes consécutives et que le véhicule est en mouvement. 
3.9.12  Événement «Erreur sur les données de mouvement» 
83)  Cet événement est déclenché , en mode autre qu'«ét alonnage», en cas d'interr uption du flux normal 
de données entre le capt eur de mouvement et l'unité embarquée sur le véhicule et/ou en cas d'erreur 
sur l'intégrité des données ou l'authentification des données au cours de l'échange de données entre le 
capt eur de mouvement et la VU. 
3.9.13  Événement «Conf lit concer nant le mouv ement du véhicule» 
84)  Cet événement est déclenché en mode autre qu'«étalonnage» lorsque des informations relatives au 
mouvement calculées par le capt eur de mouvement entrent en conf lit avec les informations de 
mouvement fournies par le récep teur GNSS interne ou par le dispositif GNSS exte rne, voire par 
d'autres sources indépendant es, conf ormément à l'appendice 12. Cet événement n'est pas déclenché 
lors d'un trajet en ferry/train, en condition HORS DE PORTÉE ou lorsque les informations de 
position fournies par le récept eur GNSS ne sont pas disponibles. 
3.9.14  Événement «Tentativ e d'atteinte à la sécur ité» 
85)  Cet événement est déclenché en cas de tout autre événement affectant la sécur ité du capt eur de 
mouvement et/ou de l'unité embarquée sur le véhicule et/ou du dispositif GNSS externe, comme 
prévu dans l'appendice 10, dans les modes autres qu'étalonnage. 
3.9.15  Événement «Conf lit tempore l» 
86)  Cet événement est déclenché en mode autre qu'«ét alonnage» lorsque la VU détecte un écar t de plus 
d'une minute entre le temps fourni par sa fonction de mesure du temps et le temps fourni par le 
récept eur GNSS. Cet événement est enregistré conjointeme nt avec la valeur de l'horloge interne de 
l'unité embarquée sur le véhicule et s'accompa gne d'une remise à l'heure automatique. Après le 
déclenchement d'un événement «Conf lit temporel», la VU ne générera plus d'autres événements 
«Conf lit temporel» pendant les 12 heures suivantes. Cet événement n'est pas déclenché lorsqu'aucun 
signal GNSS valable n'a pu être détect é par le récep teur GNSS au cours des 30 derniers jours. 
Cependant, lorsque les informations de position fournies par le récept eur GNSS sont à nouveau 
disponibles, la remise à l'heure automatique sera effectuée. 
3.9.16  Anomalie «Car te» 
87) Cette anomalie est déclench ée en cas d'anomalie d'une carte tach ygraphique en cours de fonction ­
nement. 
3.9.17  Anomalie «Appar eil de contrô le» 
88) Cette anomalie est déclenchée dans le cas des anomalies suivantes, dans les modes autres qu'éta ­
lonnage: 
—  anomalie interne de la VU 
—  anomalie de l'impr imant e 
—  anomalie de l'affi chage 
—  anomalie de téléc hargement 
—  anomalie du capt eur 
—  anomalie du récep teur GNSS ou du dispositif GNSS externe, 
—  anomalie du dispositif de communication à distance. 26.5.2016 L 139/30 Jour nal officiel de l'Union européenne FR     
3.10  Autotests intég rés 
89)  L'appareil de contrôle détect e lui-même les anomalies par des autot ests et des tests intégré s, selon le 
tableau suivant : 
Élément à tester Autotest Test intégré 
Logiciels  Intégr ité 
Mémoire de données Accès Accès, intégr ité des don ­
nées 
Dispositifs d'inte rface carte Accès Accès 
Clavier  Contrôle manuel 
Impr imant e (au choix du fabricant) Impression 
Écran  Contrôle visuel 
Télécharg ement 
(effectué uniquement lors du téléc harge ­
ment) Fonctionnement correct  
Capt eur Fonctionnement correct Fonctionnement correct 
Dispositif de communication à distance Fonctionnement correct Fonctionnement correct 
Dispositif GNSS Fonctionnement correct Fonctionnement correct  
3.11  Lecture de la mémoire 
90)  L'appareil de contrôle doit pouvoir lire tout es les données stockées dans sa mémoire. 
3.12  Enregistrement et stockage dans la mémoire 
Aux fins du présent paragraphe, 
—  on entend par «365 jours» 365 jours civils d'activit é moyenne de conduct eurs dans un véhicule. L'activité 
moyenne par jour dans un véhicule est définie comme au moins 6 conducteurs ou conv oyeurs, 6 cycles 
d'inser tion/retrait de cartes et 256 chang ements d'activit és. «365 jours» incluent donc au moins 2 190 
conduct eurs/conv oyeurs, 2 190 cycles d'inser tion/retrait de carte et 93 440 chang ements d'activité, 
—  le nombre moyen de positions par jour est défini comme au moins 6 positions correspondant aux lieux 
où commence la période de travai l jour nalière, 6 positions correspondant aux lieux où le temps de 
conduit e continue du conducteur atteint un multiple de trois heures et 6 positions correspondant aux 
lieux où se term ine la période de travail jour nalière, de sorte qu'au moins 6 570 positions sont 
comprises dans ces «365 jours», 
—  les heures sont enregistrées à la minute près, sauf indication contraire, 
—  les valeurs kilométr iques sont enregistrées au kilomètre près, 
—  les vitess es sont enregistrées au kilomètre/heure près, 
—  les positions (latitudes et longitudes) sont enregistrées en degrés et en minut es, au dixième de minut e 
près, en association avec la précision et le temps d'acquisition du GNSS. 26.5.2016 L 139/31 Jour nal officiel de l'Union européenne FR     
91) Les données enregistrées dans la mémoire ne doivent pas être affectées par une coupure de l'alimen ­
tation électr ique externe d'une durée infér ieure à douze mois dans les conditions d'homologat ion. En 
outre, les données stoc kées dans le dispositif externe de communication à distance, tel que défini à 
l'appendice 14, ne doivent pas être affectées par les coupures d'alimentation de moins de 28 jours. 
92)  L'appareil de contrôle doit pouvoir enregistrer et stoc ker implicit ement ou explicitem ent dans sa 
mémoire les données suivantes: 
3.12.1  Données d'identif ication de l'appar eil 
3.12.1.1  Données d'identification de l'unité embarquée sur le véhicule 
93) L'appareil de contrôle doit pouvoir stoc ker dans sa mémoire les données suivante s pour l'identifi ­
cation de l'unité embarquée sur le véhicule: 
—  nom du fabr icant, 
—  adresse du fabr icant, 
—  numéro des pièces, 
—  numéro de série, 
—  génération de la VU, 
—  possibilit é d'utiliser des cartes tach ygraphiques de première génération, 
—  numéro de la version du logiciel, 
—  date d'installation de la version du logiciel, 
—  année de constr uction de l'appareil, 
—  numéro d'homologation. 
94)  Les données d'identif ication de l'unité embarquée sur le véhicule sont enregistrées et stoc kées une fois 
pour tout es par le fabr icant de l'unit é embarquée sur le véhicule, sauf les données concer nant le 
logiciel et le numéro d'homologa tion, qui peuvent être modifiés en cas d'év olution du logiciel, et la 
possibilit é d'utiliser des cartes tach ygraphiques de première génération. 
3.12.1.2  Données d'identification du capt eur de mouvement 
95)  Le capt eur de mouvement doit pouvoi r stoc ker dans sa mémoire les données d'identification 
suivantes: 
—  nom du fabr icant, 
—  numéro de série, 
—  numéro d'homologation. 
—  identif icateur du compo sant de sécur ité intégré (par ex. numéro de série du microprocesseur 
interne), 
—  identif icateur du système d'exploitation (par ex. numéro de la version du logiciel). 
96)  Les données d'identif ication du capt eur de mouvement sont enregistrées et stoc kées une fois pour 
tout es sur le capt eur par son fabricant. 
97)  L'unité embarquée sur le véhicule enregistre et mémor ise dans sa mémoire de données les données 
suivantes associées aux 20 appar iements de capt eurs de mouvement les plus récents (si plusieurs 
appar iements ont eu lieu en un jour calendaire, seuls le premier et le dernier de la jour née sont 
mémor isés): 
Les données suivantes sont enregistrées pour chacun de ces appar iements: 
—  données d'identification du capt eur de mouvement : 
—  numéro de série, 
—  numéro d'homologation, 26.5.2016 L 139/32 Jour nal officiel de l'Union européenne FR     
—  données de couplage du capt eur de mouvement : 
—  date d'appar iement. 
3.12.1.3  Données d'identification des systèmes mondiaux de navig ation par sate llite (Global 
Nav igation Satellit e Syst ems) 
98)  Le dispositif GNSS exte rne doit pouv oir stoc ker dans sa mémoire les données d'identif ication 
suivantes: 
—  nom du fabr icant, 
—  numéro de série, 
—  numéro d'homologation. 
—  identif icateur du compo sant de sécur ité intégré (par ex. numéro de série du microprocesseur 
interne), 
—  identif icateur du système d'exploitation (par ex. numéro de la version du logiciel). 
99)  Les données d'identif ication sont enregistrées et stoc kées une fois pour tout es sur le dispositif GNSS 
externe par le fabricant de ce dernier. 
100)  L'unité embarquée sur le véhicule enregistre et mémor ise dans sa mémoire de données les données 
suivantes associées aux 20 appar iements de dispositifs GNSS exte rnes les plus récents (si plusieurs 
appar iements ont eu lieu en un jour calendaire, seuls le premier et le dernier de la jour née sont 
mémor isés). 
Les données suivantes sont enregistrées pour chacun de ces appar iements: 
—  données d'identification du dispositif GNSS extern e: 
—  numéro de série, 
—  numéro d'homologation. 
—  données de couplage du dispositif GNSS externe: 
—  date d'appar iement 
3.12.2  Clés et certifica ts 
101)  L'appareil de contrôle doit être en mesure de stoc ker un certain nombre de certificat s et de clés 
cryptographiques, comme spécifi é à l'appendice 11, parties A et B. 
3.12.3  Données d'inser tion et de retrait de la carte du conducteur ou de l'atelier 
102)  Pour chaque cycle inser tion-retrait d'une carte de conduct eur ou d'atelier , l'appareil de contrôle 
enregistre et stoc ke dans sa mémoire: 
—  les nom et prénom(s) du détenteur de la carte tels que stoc kés sur la carte, 
—  le numéro de la carte, l'État membre qui l'a délivrée et la date d'expiration tels que stockés sur la 
carte, 
—  la génération de la carte, 
—  la date et l'heure d'inser tion, 
—  le kilométrage du véhicule au moment de l'inser tion de la carte, 
—  le lecte ur dans lequel est insérée la carte, 
—  la date et l'heure du retrait, 
—  le kilométrage du véhicule au moment du retrait de la carte, 26.5.2016 L 139/33 Jour nal officiel de l'Union européenne FR     
—  les informations suivante s relatives au dernier véhicule utilisé par le conduct eur, telles que 
stoc kées sur la carte: 
—  le numéro et l'État membre d'immatr iculation, 
—  la génération de la VU (si disponible), 
—  la date et l'heure du retrait de la carte, 
—  un code indiquant si le détent eur de la carte a saisi manuellement des activités lors de l'inser tion 
de la carte ou non. 
103)  La mémoire doit pouvoi r conser ver ces données pendant au moins 365 jours. 
104)  Lorsque la capacit é de stoc kage est épuisée, les données nouvelles rem placent les données les plus 
anciennes. 
3.12.4  Données relativ es à l'activité du conducteur 
105)  L'appareil de contrôle enregistre et stoc ke dans sa mémoire tout changement d'activit é du conduct eur 
et/ou du conv oyeur , et/ou tout changem ent de la situation de conduite, et/ou tout e inser tion ou 
retrait d'une carte de conduct eur ou d'atelier: 
—  situation de conduite (ÉQUIP AGE, SEUL), 
—  lecteur (COND UCTEUR, CONV OYEUR), 
—  situation de la carte dans le lecteur (INSÉRÉE/NON INSÉRÉE), 
—  activité (CONDUITE, DISPONIBILITÉ, TRA VAIL, PAUSE/REPOS), 
—  date et heure du change ment. 
INSÉRÉE signif ie qu'une carte de conducteur ou d'atelier en cours de validité est insérée dans le 
lecteur . NON INSÉRÉE signif ie le contraire, c'est-à-dire qu'aucune carte de conducteur ou d'atelier en 
cours de validité n'est insérée dans le lecteur (par ex. une carte d'entrepr ise est insérée, ou aucune 
carte n'est insérée). 
Les données relatives à l'activité saisies manuellement par un conduct eur ne sont pas enregistrées 
dans la mémoire. 
106)  La mémoire doit pouv oir conser ver les données relatives à l'activit é du conducteur pendant au moins 
365 jours. 
107)  Lorsque la capacit é de stoc kage est épuisée, les données nouvelles rem placent les données les plus 
anciennes. 
3.12.5  Lieux et positions des lieux où les périodes de travail journalières commencent et se terminent et/ou où les 3 heur es de 
temps de conduite continue sont atteintes 
108)  L'appareil de contrôle doit enregistrer et stoc ker dans sa mémoire: 
—  les lieux et positions des lieux où le conduct eur et/ou le conv oyeur commencent leur période de 
travail jour nalière, 
—  les positions des lieux où le temps de conduite continue du conduct eur atteint un multiple de 
trois heures, 
—  les lieux et positions des lieux où le conduct eur et/ou le conv oyeur term inent leur période de 
travail jour nalière. 
109)  Lorsque le récep teur GNSS ne peut communiquer la position du véhicule à ces instants précis, 
l'appareil de contrôle doit utiliser la dernière position disponible, ainsi que la date et l'heure corres­
pondante s. 
110)  Pour chaque lieu ou pour chaque position, l'appareil de contrôle doit enregistrer et stoc ker dans sa 
mémoire: 
—  le numéro de carte de conduct eur/conv oyeur et l'État membre qui a délivré la carte, 
—  la génération de la carte, 26.5.2016 L 139/34 Jour nal officiel de l'Union européenne FR     
—  la date et l'heure de la saisie, 
—  le type de saisie (début, fin ou 3 heures de conduit e continue), 
—  la précision GNSS, la date et l'heure correspondant es, le cas éché ant, 
—  kilométrage du véhicule. 
111)  La mémoire doit être en mesure de conser ver pendant au moins 365 jours les lieux et les positions 
des lieux où les périodes de travai l jour nalières commencent et se term inent, et/ou où les 3 heures de 
temps de conduite continue sont attein tes. 
112)  Lorsque la capacit é de stoc kage est épuisée, les données nouvelles rem placent les données les plus 
anciennes. 
3.12.6  Données relativ es au kilométr age 
113) L'appareil de contrôle enregistre dans sa mémoire le kilométrage du véhicule et la date corres­
pondante , chaque jour civil à minuit. 
114)  La mémoire doit pouvoi r conser ver les relevés quotidiens à minuit du comp teur kilométr ique 
pendant au moins 365 jours. 
115)  Lorsque la capacit é de stoc kage est épuisée, les données nouvelles rem placent les données les plus 
anciennes. 
3.12.7  Données détaillées relatives à la vitesse 
116)  L'appareil de contrôle enregistre et stoc ke dans sa mémoire la vites se instantanée du véhicule et la 
date et l'heure correspondante s à chaque seconde d'au moins les 24 dernières heures au cours 
desquelles le véhicule était conduit. 
3.12.8  Données relativ es aux événements 
Aux fins du présent point, l'heure est enregistrée à la seconde près. 
117)  L'appareil de contrôle enregistre et stoc ke dans sa mémoire les données suivante s pour chaque 
événement détecté, conf ormément aux règles de stoc kage suivantes: 
Événement Règles de stoc kage Données à enregistrer pour chaque événement 
Inser tion d'une carte non 
valable —les 10 événements les plus ré­
cents, —  la date et l'heure de l'événement, 
—  le type et le numéro de la carte ou des cartes, 
l'État membre de délivrance et la génération de 
la carte à l'origine de l'événement, 
—  le nombre d'événements semblables survenus le 
même jour . 
Conf lit de carte —les 10 événements les plus ré­
cents, —  la date et l'heure du début de l'événement, 
—  la date et l'heure de fin de l'événement, 
—  le type et le numéro de la carte ou des cartes, 
l'État membre de délivrance et la génération de 
chacune des deux cartes à l'origine du conf lit. 
Conduite sans carte ap­
propr iée —  l'événement le plus long survenu 
au cours de chacun des 10 der­
niers jours d'occur rence, 
—  les 5 événements les plus longs 
enregistrés au cours des 365 der­
niers jours, —  la date et l'heure du début de l'événement, 
—  la date et l'heure de fin de l'événement, 
—  le type et le numéro de la carte ou des cartes, 
l'État membre de délivrance et la génération de 
tout e carte insérée au début et/ou à la fin de 
l'événement, 
—  le nombre d'événements semblables survenus le 
même jour . 26.5.2016 L 139/35 Jour nal officiel de l'Union européenne FR     
Événement Règles de stoc kage Données à enregistrer pour chaque événement 
Inser tion d'une carte en 
cours de conduite —  le dernier événement pour chacun 
des 10 derniers jours d'occur ­
rence, —  la date et l'heure de l'événement, 
—  le type et le numéro de la carte ou des cartes, 
l'État membre de délivrance et la génération, 
—  le nombre d'événements semblables survenus le 
même jour . 
Clôture incor recte de la 
dernière session —les 10 événements les plus ré­
cents, —  la date et l'heure de l'inser tion, 
—  le type et le numéro de la carte ou des cartes, 
l'État membre de délivrance et la génération, 
—  les données relatives à la dernière session telles 
qu'elles figurent sur la carte: 
—  la date et l'heure de l'inser tion, 
—  le numéro d'immatr iculation, l'État membre 
d'immatr iculation et la génération de la VU. 
Excès de vitesse (1) —  l'événement le plus grav e (c.-à-d. 
celui présentant la vitesse 
moyenne la plus élevée) des 10 
derniers jours d'occur rence, 
—  les 5 événements les plus grav es 
au cours des 365 derniers jours, 
—  le premier événement survenu 
après le dernier étalonnage, —  la date et l'heure du début de l'événement, 
—  la date et l'heure de fin de l'événement, 
—la vitesse maximale mesurée au cours de l'événe ­
ment, 
—  la vitesse moyenne arithmétique mesurée au 
cours de l'événement, 
—le type, le numéro, la génération et l'État mem ­
bre ayant délivré la carte de conduct eur (le cas 
échéant), 
—  le nombre d'événements semblables survenus le 
même jour . 
Interr upti on de l'alimen ­
tation électr ique (2) —  l'événement le plus long survenu 
au cours de chacun des 10 der­
niers jours d'occur rence, 
—  les 5 événements les plus longs 
enregistrés au cours des 365 der­
niers jours, —  la date et l'heure du début de l'événement, 
—  la date et l'heure de fin de l'événement, 
—  le type et le numéro de la carte ou des cartes, 
l'État membre de délivrance et la génération de 
tout e carte insérée au début et/ou à la fin de 
l'événement, 
—  le nombre d'événements semblables survenus le 
même jour . 
Erreur de communication 
avec le dispositif de 
communication à dis­
tance —  l'événement le plus long survenu 
au cours de chacun des 10 der­
niers jours d'occur rence, 
—  les 5 événements les plus longs 
enregistrés au cours des 365 der­
niers jours, —  la date et l'heure du début de l'événement, 
—  la date et l'heure de fin de l'événement, 
—  le type et le numéro de la carte ou des cartes, 
l'État membre de délivrance et la génération de 
tout e carte insérée au début et/ou à la fin de 
l'événement, 
—  le nombre d'événements semblables survenus le 
même jour . 
Absence d'inf ormations 
de positionnement en 
provenance du récep teur 
GNSS —  l'événement le plus long survenu 
au cours de chacun des 10 der­
niers jours d'occur rence, 
—  les 5 événements les plus longs 
enregistrés au cours des 365 der­
niers jours, —  la date et l'heure du début de l'événement, 
—  la date et l'heure de fin de l'événement, 
—  le type et le numéro de la carte ou des cartes, 
l'État membre de délivrance et la génération de 
tout e carte insérée au début et/ou à la fin de 
l'événement, 
—  le nombre d'événements semblables survenus le 
même jour . 26.5.2016 L 139/36 Jour nal officiel de l'Union européenne FR     
Événement Règles de stoc kage Données à enregistrer pour chaque événement 
Erreur sur les données de 
mouvement —  l'événement le plus long survenu 
au cours de chacun des 10 der­
niers jours d'occur rence, 
—  les 5 événements les plus longs 
enregistrés au cours des 365 der­
niers jours, —  la date et l'heure du début de l'événement, 
—  la date et l'heure de fin de l'événement, 
—  le type et le numéro de la carte ou des cartes, 
l'État membre de délivrance et la génération de 
tout e carte insérée au début et/ou à la fin de 
l'événement, 
—  le nombre d'événements semblables survenus le 
même jour . 
Conf lit concer nant le 
mouvement du véhicule —  l'événement le plus long survenu 
au cours de chacun des 10 der­
niers jours d'occur rence, 
—  les 5 événements les plus longs 
enregistrés au cours des 365 der­
niers jours, —  la date et l'heure du début de l'événement, 
—  la date et l'heure de fin de l'événement, 
—  le type et le numéro de la carte ou des cartes, 
l'État membre de délivrance et la génération de 
tout e carte insérée au début et/ou à la fin de 
l'événement, 
—  le nombre d'événements semblables survenus le 
même jour . 
Tentative d'atte inte à la 
sécur ité —  les 10 événements les plus récents 
pour chaque type d'événement, —  la date et l'heure du début de l'événement, 
—  la date et l'heure de la fin de l'événement, 
—  le type et le numéro de la carte ou des cartes, 
l'État membre de délivrance et la génération de 
tout e carte insérée au début et/ou à la fin de 
l'événement, 
—  le type d'événement. 
Conf lit temporel —  l'événement le plus long survenu 
au cours de chacun des 10 der­
niers jours d'occur rence, 
—  les 5 événements les plus longs 
enregistrés au cours des 365 der­
niers jours, —  la date et l'heure de l'appareil de contrôle, 
—  la date et l'heure du GNSS, 
—  le type et le numéro de la carte ou des cartes, 
l'État membre de délivrance et la génération de 
tout e carte insérée au début et/ou à la fin de 
l'événement, 
—  le nombre d'événements semblables survenus le 
même jour .   
(1) L'appareil de contrôle doit également enregistrer et stoc ker dans sa mémoire: 
—  la date et l'heure du dernier CONTRÔL E D'EX CÈS DE VITESSE, 
—  la date et l'heure du premier excès de vites se après ce CONTRÔL E D'EX CÈS DE VITESSE, 
—  le nombre d'événements du type excè s de vitesse survenus depuis le dernier CONTRÔLE 
D'EX CÈS DE VITESSE.  
(2) Ces données peuvent être enregistrées uniquement lors du rétablissement de l'alimentation 
électr ique, les heures pouvant être connues avec une précision d'une minute . 
3.12.9  Données relativ es aux anomalies 
Aux fins du présent point, l'heure est enregistrée à la seconde près. 26.5.2016 L 139/37 Jour nal officiel de l'Union européenne FR     
118)  L'appareil de contrôle doit essa yer d'enregistrer et de stoc ker dans sa mémoire les données suivantes 
pour chaque anomalie détectée, conf ormément aux règles de stoc kage suivantes: 
Anomalie Règles de stoc kage Données à enregistrer pour chaque anomalie 
Anomalie de la carte —  les 10 dernières anomalies de la carte 
de conduct eur, —  la date et l'heure de début de l'anomalie, 
—  la date et l'heure de fin de l'anomalie, 
—  le type et le numéro de la carte ou des 
cartes, l'État membre de délivrance et la 
génération. 
Anomalies de l'appareil de 
contrôle —  les 10 anomalies les plus récent es pour 
chaque type d'anomalie, 
—  la première anomalie après le dernier 
étalonnage, —  la date et l'heure de début de l'anomalie, 
—  la date et l'heure de fin de l'anomalie, 
—  le type d'anomalie, 
—  le type et le numéro de la carte ou des 
cartes, l'État membre de délivrance et la 
génération de tout e carte insérée au dé­
but et/ou à la fin de l'anomalie.  
3.12.10  Données d'étalonnage 
119)  L'appareil de contrôle enregistre et stoc ke dans sa mémoire les données ayant trait: 
—  aux paramètres d'étalonnage connus au moment de l'activation, 
—  à son tout premier étalonnage après son activation, 
—  à son premier étalonnage dans le véhicule où il se trouve actuellement (tel qu'identifié par le 
numéro d'identif ication du véhicule, ou VIN), 
—  les 20 étalonnages les plus récents (lorsque plusieurs étalonnages inter viennent le même jour civil, 
seuls le premier et le dernier sont archivés). 
120)  Les données suivantes sont enregistrées pour chacun de ces étalonnages: 
—  l'objet de l'étalonnage (activation, première installation, installation, inspection périodique), 
—  le nom et l'adresse de l'atelier , 
—  le numéro de la carte d'atelier , l'État membre ayant délivré la carte et la date d'expiration de la 
carte, 
—  identif ication du véhicule, 
—  les paramètres mis à jour ou conf irmés: w, k, l, taille des pneumatiques, réglage du limiteur de 
vites se, comp teur kilométr ique (ancienne et nouvelle valeurs), date et heure (ancienne et nouvelle 
valeurs), 
—  les types et les identifiants de tous les scellements en place. 
121)  En outre, l'appareil de contrôle enregistre et stoc ke dans sa mémoire sa capacité à utiliser les cartes 
tach ygraphiques de première génération (encore activées ou non). 
122)  Le capt eur de mouvement enregistre et stoc ke dans sa mémoire les données suivantes concer nant son 
installation: 
—  première connexion à une VU (date, heure, numéro d'homolog ation de la VU, numéro de série de 
la VU), 
—  dernière connexion à une VU (date , heure, numéro d'homolog ation de la VU, numéro de série de 
la VU). 26.5.2016 L 139/38 Jour nal officiel de l'Union européenne FR     
123)  Le dispositif GNSS externe enregistre et stocke dans sa mémoire les données suivantes concer nant 
son installation: 
—  premier couplage à une VU (date, heure, numéro d'homologation de la VU, numéro de série de la 
VU), 
—  dernier couplage à une VU (date, heure, numéro d'homologat ion de la VU, numéro de série de la 
VU). 
3.12.11  Données de remise à l'heure 
124)  L'appareil de contrôle enregistre et stocke dans sa mémoire les données pertinentes relatives aux 
remises à l'heure exécut ées en mode «étalonnage» hors du cadre d'un étalonnage périodique (déf. f): 
—  la plus récente remise à l'heure, 
—  les 5 remises à l'heure les plus impor tantes. 
125)  Les données suivantes sont enregistrées pour chacune de ces remises à l'heure: 
—  la date et l'heure, l'ancienne valeur , 
—  la date et l'heure, la nouvelle valeur , 
—  le nom et l'adresse de l'atelier , 
—  le numéro de la carte d'ateli er, l'État membre ayant délivré la carte, la génération de la carte et la 
date d'expiration de la carte. 
3.12.12  Données d'activité de contrôle 
126)  L'appareil de contrôle enregistre et stoc ke dans sa mémoire les données suivantes ayant trait aux 20 
dernières activités de contrôle: 
—  date et heure du contrôle, 
—  le numéro de la carte de contrôleur , l'État membre qui a délivré la carte et la génération de la 
carte, 
—le type de contrôle (affichag e et/ou tirage papier et/ou téléc hargement depuis la VU et/ou téléchar ­
gement depuis la carte et/ou contrôle d'étalonnag e sur route). 
127)  En cas de télécharg ement, les dates de la jour née la plus ancienne et de la jour née la plus récente 
téléc hargées sont également enregistrées. 
3.12.13  Données relativ es aux verrouillages d'entrep rise 
128)  L'appareil de contrôle enregistre et stocke dans sa mémoire les données suivante s ayant trait aux 255 
plus récents verrouillages d'entrepr ise: 
—  la date et l'heure du verrouillage, 
—  la date et l'heure du déver rouillage , 
—  le numéro de la carte d'entrepr ise, l'État membre qui a délivré la carte et la génération de la carte, 
—  le nom et l'adresse de l'entrepr ise. 
Les données précédemment verrouillées par un verrouillage suppr imé de la mémoire en raison de la 
limite précité e sont traitée s comme étant non verrouillées. 
3.12.14  Données relativ es au télécharge ment 
129)  L'appareil de contrôle enregistre et stoc ke dans sa mémoire les données suivantes ayant trait au 
dernier téléc hargement depuis la mémoire vers des médias extéri eurs en mode «entrepr ise» ou 
«étalonnage»: 
—  la date et l'heure du téléc hargem ent, 26.5.2016 L 139/39 Jour nal officiel de l'Union européenne FR     
—  le numéro de la carte d'entrepr ise ou d'ateli er, l'État membre ayant délivré la carte et la génération 
de la carte, 
—  le nom de l'entrepr ise ou de l'atelier . 
3.12.15  Données concer nant les conditions particulières 
130)  L'appareil de contrôle enregistre et stoc ke dans sa mémoire les données suivante s ayant trait aux 
conditions particulières: 
—  la date et l'heure de la saisie, 
—  le type de condition particulière. 
131)  La mémoire doit pouv oir conser ver les données relatives aux conditions particulières pendant au 
moins 365 jours (en supposant qu'en moyenne 1 condition est ouver te et fermée par jour). Lorsque 
la capacit é de stoc kage est épuisée, les données nouvelles remplacent les données les plus anciennes. 
3.12.16  Données relativ es à la carte tachyg raphique 
132)  L'appareil de contrôle doit pouv oir stoc ker les données suivante s relatives aux différ entes cartes 
tach ygraphiques qui avaient été utilisées dans la VU: 
—  le numéro de la carte tach ygraphique et son numéro de série, 
—  le fabricant de la carte tach ygraphique, 
—  le type de carte tach ygraphique, 
—  la version de la carte tach ygraphique. 
133)  L'appareil de contrôle doit permettre le stoc kage d'au moins 88 enregistrements de ce type. 
3.13  Lecture des cartes tachyg raphiques 
134)  L'appareil de contrôle doit pouvoi r lire sur les cartes tach ygraphiques de première et deuxième 
générations, au besoin, les données nécessaires pour : 
—  identif ier le type de la carte, le détenteur de la carte, le véhicule utilisé précédemment, la date et 
l'heure du dernier retrait et l'activité sélectionnée à ce moment, 
—  vérifier que la dernière session a été correctement clôturée, 
—  calculer le temps de conduit e continue du conduct eur, le temps de pause cumulé et les temps de 
conduite cumulés pour la semaine précédente et la semaine en cours, 
—  imprimer les demandes d'im pression de données enregistrées sur une carte de conducteur , 
—  téléc harger une carte de conducteur sur un média externe. 
Cette exige nce ne s'applique qu'aux cartes tach ygraphiques de première génération si leur utilisation 
n'a pas été rendue impossible par un atelier. 
135)  En cas d'erreur de lecture, l'appareil de contrôle fait une nouvelle tentative, à trois repr ises au 
maximum, et déclare la carte défai llante et non valable en cas d'échec répété . 
3.14  Enregistrement et stockage sur cartes tachy graphiques 
3.14.1  Enregistr ement et stockage sur les cartes tachyg raphiques de premièr e génération 
136)  À condition que l'utilisation de cartes tach ygraphiques de première génération n'ait pas été rendue 
impossible par un atelier , l'appareil de contrôle doit enregistrer et stocker les données exactement 
comme le ferait un appareil de contrôle de première génération. 26.5.2016 L 139/40 Jour nal officiel de l'Union européenne FR     
137) L'appareil de contrôle règle les «données de session» sur la carte de conduct eur ou d'atelier immédia ­
tement après l'inser tion de la carte. 
138)  L'appareil de contrôle met à jour les données stoc kées sur une carte de conduct eur, d'ate lier, 
d'entrepr ise et/ou de contrôleur en cours de validité avec tout es les données nécessaires concer nant la 
période d'inser tion de la carte et en relation avec le détent eur de la carte. Les données enregistrées sur 
ces cartes sont spécifiées au chapitre 4. 
139)  L'appareil de contrôle met à jour les données concer nant l'activité du conduct eur et les lieux (telles 
que spécifiées aux points 4.5.3.1.9 et 4.5.3.1.11) stockées sur les cartes de conduct eur et/ou d'ateli er 
en cours de validité, avec les données relatives à l'activité et au lieu saisies manuellement par le 
détent eur de la carte. 
140)  Tous les événements non définis pour l'appareil de contrôle de première génération ne sont pas 
stoc kés sur les cartes de conducteur et d'atelier . 
141)  La mise à jour des données enregistrées sur les cartes tach ygraphiques est réalisée de telle manière 
que, lorsque cela est nécessaire comp te tenu de la capacit é réelle de stoc kage de la carte, les données 
les plus récentes remplacent les données les plus anciennes. 
142)  En cas d'erreur d'écr iture, l'appareil de contrôle fait une nouvelle tentative, à trois repr ises au 
maximum, et en cas d'éche c répété, déclare la carte défaillant e et non valable. 
143)  Avant la libération d'une carte de conducteur , et après que tout es les données pertinentes ont été 
stoc kées sur la carte, l'appareil de contrôle remet à zéro les «données de session». 
3.14.2  Enregistr ement et stockage sur les cartes tachyg raphiques de deuxième génération 
144)  Les cartes tach ygraphiques de deuxième génération doivent cont enir 2 applications de carte 
différ entes, la première devant être rigoureusement identique à l'application TACHO des cartes 
tach ygraphiques de première génération, la seconde étant l'application «TACHO_G2», comme spécifié 
dans le chapitre 4 et dans l'appendice 2. 
145) L'appareil de contrôle règle les «données de session» sur la carte de conduct eur ou d'atelier immédia ­
tement après l'inser tion de la carte. 
146)  L'appareil de contrôle met à jour les données stoc kées sur les 2 applications des cartes de conducteur , 
d'atelier , d'entrepr ise et/ou de contrôleur en cours de validité avec tout es les données nécessaires 
concer nant la période d'inser tion de la carte et en relation avec le détenteur de la carte. Les données 
enregistrées sur ces cartes sont spécifi ées au chapitre 4. 
147)  L'appareil de contrôle met à jour les données concer nant les lieux et les positions d'activit é du 
conducteur (telles que spécifi ées aux points 4.5.3.1.9, 4.5.3.1.11, 4.5.3.2.9 et 4.5.3.2.11) stoc kées sur 
les cartes de conduct eur et/ou d'atelier en cours de validité, avec les données relatives aux lieux et aux 
activités saisies manuellement par le détent eur de la carte. 
148)  La mise à jour des données enregistrées sur les cartes tach ygraphiques est réalisée de telle manière 
que, lorsque cela est nécessaire comp te tenu de la capacit é réelle de stoc kage de la carte, les données 
les plus récentes remplacent les données les plus anciennes. 
149)  En cas d'erreur d'écr iture, l'appareil de contrôle fait une nouvelle tentative, à trois repr ises au 
maximum, et en cas d'éche c répété, déclare la carte défaillant e et non valable. 
150)  Avant la libération d'une carte de conducteur , et après que tout es les données pertinentes ont été 
stoc kées sur les 2 applications de la carte, l'appareil de contrôle remet à zéro les «données de session». 
3.15  Affichage 
151)  L'affi chage doit compo rter au moins 20 caractères. 
152)  La taille des caractères doit être d'au moins 5 mm de haut eur et 3,5 mm de largeur . 26.5.2016 L 139/41 Jour nal officiel de l'Union européenne FR     
153)  Le dispositif d'affi chage doit prendre en charge les caractères spécifiés au chapitre 4 «Jeux de 
caractères» de l'appendice 1. L'affi chage peut utiliser des graphies simplifiées (par ex., les caractères 
accentués peuvent être affichés sans accent, ou les minuscules peuvent être affichées en majuscules). 
154)  L'affi chage doit être muni d'un éclairage non éblouissant. 
155)  Les indications doivent être visibles à l'ext érieur de l'appareil de contrôle. 
156)  L'appareil de contrôle doit pouvoir afficher: 
—  des données concer nant les anomalies, 
—  des données d'av ertissement, 
—  des données relatives à l'accès aux menus, 
—  d'autres données demandées par l'utilisat eur. 
Des informations additionnelles peuvent être affichées par l'appareil de contrôle, à condition d'être 
clairement distincte s des informations précitée s. 
157)  L'affi chage de l'appareil de contrôle doit utiliser les pictogrammes ou les combinaisons de 
pictogrammes énumérées à l'appendice 3. Des pictogrammes ou des combinaisons de pictogrammes 
additionnels peuvent également être utilisés, pour autant qu'ils soient clairement distincts des 
pictogrammes ou combinaisons de pictogram mes précités. 
158)  Le dispositif d'affi chage doit touj ours être allumé lorsque le véhicule est en mouvement. 
159)  L'appareil de contrôle peut compor ter une fonction manuelle ou automatique qui coupe le dispositif 
d'affi chage lorsque le véhicule est à l'arrêt. 
Le format d'aff ichage est indiqué à l'appendice 5. 
3.15.1  Affichag e par défaut 
160)  Lorsque l'affichage d'aucune autre information n'est requis, l'appareil de contrôle affiche, par défaut, 
les indications suivantes: 
—  heure locale (UTC + décalage fixé par le conducteur), 
—  mode de fonctionnement, 
—  activité en cours du conducteur et du conv oyeur, 
—  informations sur le conduct eur: 
—  si son activité en cours est la CONDU ITE, son temps de conduite continue et son temps de pause 
cumulé courants, 
—  si son activité en cours n'est pas la CONDUITE, la durée de cette activité (depuis sa sélection) et le 
temps de pause cumulé courants. 
161)  L'affi chage des données concer nant chaque conducteur doit être clair , simple et dépour vu 
d'ambiguïté. Lorsque les informations relatives au conducteur et au conv oyeur ne peuvent être 
affichées en même temps, l'appareil de contrôle doit afficher par défaut les informations ayant trait au 
conducteur et doit permettre à l'utilisat eur d'aff icher les informations sur le conv oyeur. 
162)  Lorsque la largeur d'affichag e n'est pas suffi sante pour afficher par défa ut le mode de fonctionnement, 
l'appareil de contrôle doit afficher brièvement le nouveau mode de fonctionnement à chaque 
chang ement de mode. 
163)  L'appareil de contrôle doit brièvement afficher le nom du détent eur de la carte lors de l'inser tion 
d'une nouvelle carte. 26.5.2016 L 139/42 Jour nal officiel de l'Union européenne FR     
164)  Lorsqu'une condition «HORS CHAMP» ou «FERR Y/TRAIN» est ouver te, le pictogramme appropr ié 
doit apparaître pour indiquer que la condition en question est ouver te (l'activité du conduct eur en 
cours peut ne pas être affichée en même temps). 
3.15.2  Affichag e d'avertiss ements 
165)  L'appareil de contrôle utilise principalement, pour les avertissements, les pictogrammes figurant à 
l'appendice 3, compl étés au besoin par des informations sous forme de code numér ique. Un message 
d'aver tissement dans la langue choisie par le conduct eur peut également être ajout é. 
3.15.3  Menu d'accès 
166)  L'appareil de contrôle doit compor ter les commandes nécessaires dans le cadre d'un menu appropr ié. 
3.15.4  Autres affichage s 
167)  Il doit être possible d'affi cher au choix, sur demande: 
—  la date et l'heure UTC et le décalage de l'heure locale, 
—  le conte nu d'un des six tirage s papier correspondants, dans le même format que le tirage papier 
lui-même, 
—  le temps de conduite continue et le temps de pause cumulé du conducteur , 
—  le temps de conduite continue et le temps de pause cumulé du conv oyeur , 
—  le temps de conduite cumulé du conduct eur pour la semaine précédente et la semaine en cours, 
—  le temps de conduit e cumulé du conv oyeur pour la semaine précédente et pour la semaine en 
cours, 
à titre facultat if: 
—  la durée actuelle de l'activité du convoyeur (depuis sa sélection), 
—  le temps de conduite cumulé du conduct eur pour la semaine en cours, 
—  le temps de conduite cumulé du convoyeur pour la période de travail jour nalière en cours, 
—  le temps de conduite cumulé du conduct eur pour la période de travail jour nalière en cours. 
168)  L'affi chage du cont enu du tirage papier est séquentiel, ligne par ligne. Si la largeur d'aff ichage est 
infér ieure à 24 caractères, l'utilisat eur peut visualiser l'ensemble des informations par un moyen 
appropr ié (plusieurs lignes, affichage déroulant…). 
Les lignes de tirag e papier prévues pour les informations manuscr ites peuvent être omises. 
3.16  Impression 
169)  L'appareil de contrôle doit pouvoir imprimer des informations stoc kées dans sa mémoire et/ou sur 
des cartes tach ygraphiques, de manière à obtenir les sept tirag es papier suivants: 
—  activités du conduct eur stockées sur la carte, 
—  activités du conduct eur stockées sur l'unité embarquée sur le véhicule, 
—  événements et anomalies stoc kés sur la carte, 
—  événements et anomalies stoc kés sur l'unit é embarquée sur le véhicule, 
—  données techniques, 26.5.2016 L 139/43 Jour nal officiel de l'Union européenne FR     
—  excès de vitesse, 
—  histo rique des données de la carte tach ygraphique pour une VU donnée (voir chapitre 3, point 
12.16). 
Le détail du format et du contenu à respecter pour ces tirages papier est spécifié à l'appendice 4. 
Des données additionnelles peuvent figur er à la fin des tirag es papier . 
D'autres tirages papier peuvent également être obtenu s à partir de l'appareil de contrôle, pour autant 
qu'ils soient clairement distincts des sept précité s. 
170)  Les tirages papier «activités du conducteur figurant sur la carte» et «événements et anomalies figurant 
sur la carte» ne peuvent être obte nus que lorsqu'une carte de conduct eur ou d'ateli er est insérée dans 
l'appareil de contrôle. L'appareil de contrôle met à jour les données stoc kées sur la carte en cause 
avant de lancer l'impression. 
171)  Afin d'impr imer les «activités du conduct eur figurant sur la carte» ou les «événements et anomalies 
figurant sur la carte», l'appareil de contrôle doit: 
—  soit sélectionner automatiquement la carte de conduct eur ou la carte d'atelier si une seule de ces 
cartes est insérée, 
—  soit compo rter une commande permettant de sélectionner la carte source ou de sélectionner la 
carte insérée dans le lecteur «conducteur» si deux de ces cartes sont insérées dans l'appareil de 
contrôle. 
172)  L'impr imant e doit pouv oir imprimer 24 caractères par ligne. 
173)  La taille des caractères doit être d'au moins 2,1 mm de haut eur et 1,5 mm de largeur . 
174)  L'impr imant e doit prendre en charge les caractères spécifi és au chapit re 4 «Jeux de caractères» de 
l'appendice 1. 
175)  Les imp rimant es doivent être conçues de telle manière que le degré de définition des sorties papier 
soit suffi sant pour évite r tout e ambiguïté à la lecture. 
176)  Les tirag es papier doivent conser ver leurs dimensions et leur cont enu dans les conditions normales 
d'humidité (10-90 %) et de température. 
177)  Le papier homologué utilisé par l'appareil de contrôle doit porter la marque d'homologation 
appropr iée et une indication du ou des types d'appareil de contrôle avec lesquels il peut être utilisé. 
178)  Les tirage s papier doivent rester facilement lisibles et identifiables dans les conditions normales de 
stoc kage, en term es d'intensit é lumineuse, d'humidit é et de température, pendant au moins deux ans. 
179)  Les tirage s papier doivent être conf ormes au minimum aux spécifications d'essai définies à 
l'appendice 9. 
180)  Il doit être également possible d'écr ire à la main sur ces documents, par exemple pour la signature du 
conducteur . 
181)  En cas de rupture de l'alimentation en papier en cours d'impression, et après recha rgement en papier , 
l'appareil de contrôle doit soit recommencer l'impr ession au début, soit la reprendre là où elle s'était 
interr ompue, en faisant clairement référence à la partie impr imée auparavant. 
3.17  Avertissements 
182)  L'appareil de contrôle doit aver tir le conduct eur lorsqu'il détect e un événement et/ou une anomalie. 
183)  L'aver tissement concer nant une interrupti on de l'alimentation électr ique peut être retardé jusqu'au 
rétablissement du courant. 26.5.2016 L 139/44 Jour nal officiel de l'Union européenne FR     
184)  L'appareil de contrôle prévient le conducteur 15 minut es avant et au moment du dépassement du 
temps de conduite continue maximal autori sé. 
185)  Les avertissements doivent être visuels. Des avertissements sonores peuvent être produits en plus des 
avertissements visuels. 
186)  Les aver tissements visuels doivent être clairement identif iables par l'utilisat eur, doivent apparaître 
dans le champ de vision du conducteur et doivent être facilement lisibles aussi bien de jour que de 
nuit. 
187)  Les avertissements visuels peuvent être intégrés à l'appareil de contrôle et/ou être exté rieurs à celui-ci. 
188)  Dans ce dernier cas, ils doivent compo rter le symbole «T». 
189)  Les avertissements doivent durer au moins 30 secondes, sauf si l'utilisateur en accuse récep tion en 
appuyant sur une ou plusieurs touc hes spécifi ques de l'appareil de contrôle. Ce premier accusé de 
réception ne doit pas effacer l'affichage de la cause de l'aver tissement visé au point suivant. 
190)  La cause de l'avertissement doit être affichée sur l'appareil de contrôle et rester visible jusqu'à ce que 
l'utilisateur en accuse récep tion à l'aide d'une touc he ou d'une commande spécifique sur l'appareil de 
contrôle. 
191)  Des avertissements additionnels peuvent être prévus, pour autant qu'ils ne prêt ent pas à confusion 
avec ceux définis précédemment. 
3.18  Téléchargement de données à destination de suppor ts exter nes 
192)  L'appareil de contrôle doit permettre le téléc hargem ent à la demande de données stoc kées sur sa 
mémoire ou sur une carte de conduct eur vers des médias externes, par l'intermédiaire d'une 
connexion d'étalonnag e/de téléc hargement. L'appareil de contrôle met à jour les données stoc kées sur 
la carte en cause avant de lancer le téléc hargem ent. 
193)  En outre, et en option, l'appareil de contrôle peut, dans tout mode de fonctionnement, télécharg er des 
données par n'im porte quel autre moyen vers une entrepr ise authentifiée par ce canal. En pareil cas, 
les données ainsi téléc hargées sont soumises aux droits d'accès applicables en mode «entrepr ise». 
194)  Le téléc hargement ne doit ni modifier ni effacer aucune des données stoc kées. 
195)  L'interface électr ique de connexion pour l'étalonnage et le télécharg ement est spécifi ée à l'appendice 
6. 
196)  Les protocoles de télécharg ement sont spécifi és à l'appendice 7. 
3.19  Communication à distance pour les contrôles routiers ciblés 
197)  Lorsque le contact est mis, la VU stoc ke, tout es les 60 secondes, dans le dispositif de communication 
à distance, les données les plus récent es nécessaires aux fins de contrôles routiers ciblés. Ces données 
sont chiffrées et signées, conf ormément aux appendices 11 et 14. 
198)  Les données qui doivent être contrôlées à distance doivent être disponibles pour les lecteur s de 
communication à distance par communication sans fil, comme indiqué à l'appendice 14. 
199)  Les données nécessaires aux fins de contrôles routiers ciblés doivent être liées aux éléments suivants: 
—  dernière tentative d'infraction à la sécur ité, 
—  interr upti on d'alimentation électr ique la plus longue, 26.5.2016 L 139/45 Jour nal officiel de l'Union européenne FR     
—  anomalie du capt eur, 
—  erreur sur les données de mouvement, 
—  conf lit concer nant le mouvement du véhicule, 
—  conduite sans carte en cours de validité, 
—  inser tion de carte pendant la conduite, 
—  données concer nant la remise à l'heure, 
—  données d'étalonnag e, y compris les dates des deux derniers enregistrements d'étalonnag e stoc kés, 
—  numéro d'immatr iculation du véhicule, 
—  vites se enregistrée par le tach ygraphe. 
3.20  Données transmises à des dispositifs exter nes supplémentaires 
200)  L'appareil de contrôle peut également être équipé d'inte rfaces normalisées permettant l'utilisation par 
un dispositif extern e, en mode opérationnel ou «étalonnage», des données enregistrées ou produites 
par le tach ygraphe. 
Dans l'appendice 13, une interf ace ITS facultative est spécifi ée et normalisée. D'autres interfaces 
similaires peuvent coexister , à condition qu'elles respecte nt pleinement les exigences de l'appendice 
13 en term es de liste minimale de données, de sécur ité et de consentement du conduct eur. 
Les exige nces suivantes sont applicables aux données ITS mises à disposition par l'inte rmédiaire de 
cette interface: 
—  ces données constituent un ensemble de données existant es sélectionnées qui proviennent du 
dictionnaire de données du tach ygraphe (appendice 1), 
—  un sous-ensemble de ces données sélectionnées constitue des «données à caractère personnel», 
—  ce sous-ensemble de «données à caractère personnel» n'est disponible que si le consent ement 
vérifiable du conducteur , qui accept e que ses données personnelles puissent quitter le réseau du 
véhicule, est activé, 
—  l'accord du conducteur peut être activé ou désactivé à tout moment,à l'aide de commandes se 
trouvant dans le menu, à condition que la carte du conducteur soit insérée, 
—  l'ensemble et le sous-ensemble de données seront diffusés via le protocole sans fil Bluetooth dans 
le rayon de la cabine du véhicule, avec une fréquence de rafraîchissement d'une minute , 
—  le couplage du dispositif exte rne avec l'interface ITS sera protég é par un code PIN dédié et 
aléatoi re d'au moins 4 chiffres, enregistré et affichable dans chaque VU, 
—  en aucun cas la présence de l'inte rface ITS ne peut perturber ou affecter le fonctionnement correct 
et la sécur ité de la VU. 
D'autres données peuvent également être transmises en plus de l'ensemble de données existant es 
sélectionnées, considérées comme la liste minimale, à condition qu'elles ne puissent pas être 
considérées comme des données à caractère personnel. 
L'appareil de contrôle doit informer les autres dispositifs externes du consente ment du conducteur . 
Lorsque le contact du véhicule est en position MAR CHE, ces données sont transmises en permanence. 
201)  L'interface de liaison série spécifiée dans l'annex e 1B du règlement (CEE) no 3821/85, tel que modifi é 
en dernier lieu, peut continuer à équiper les tach ygraphes afin d'assurer leur compatib ilité avec les 
équipements de première génération. Quoi qu'il en soit, le consent ement du conduct eur est touj ours 
nécessaire lorsque des données personnelles sont transmises. 26.5.2016 L 139/46 Jour nal officiel de l'Union européenne FR     
3.21  Étalonnage 
202)  La fonction d'étalonnage permet: 
—  le couplag e automatique du capt eur de mouvement avec la VU, 
—  le couplag e automatique du dispositif GNSS externe avec la VU, le cas échéa nt, 
—  l'adaptati on numér ique de la constant e de l'appareil de contrôle (k) au coefficient caractér istique 
du véhicule (w), 
—  la remise à l'heure au cours de la période de validité de la carte d'ate lier insérée, 
—  l'ajust ement du kilométrage, 
—  la mise à jour des données d'identification du capt eur de mouvement stoc kées dans la mémoire, 
—  la mise à jour , le cas échéant, des données d'identif ication du dispositif GNSS externe stoc kées 
dans la mémoire, 
—  la mise à jour des types et des identifiants de tous les scellements en place, 
—la mise à jour ou la conf irmation d'autres paramètres connus par l'appareil de contrôle: identifi ­
cation du véhicule, w, l, taille des pneumatiques et réglage du limiteur de vitesse le cas éché ant. 
203)  En outre, la fonction d'étalonnag e permet de rendre impossible l'utilisation de cartes tach ygraphiques 
de première génération dans l'appareil de contrôle, pour autant que les conditions spécifiées à 
l'appendice 15 soient rem plies. 
204)  Le couplage du capt eur de mouvement à la VU consiste au moins en: 
—  la mise à jour des données d'installation du capt eur de mouvement détenues par le capt eur de 
mouvement (au besoin), 
—  la copie, dans la mémoire de la VU, des données d'identification nécessaires du capt eur de 
mouvement. 
205)  Le couplage du dispositif GNSS externe avec la VU consiste au moins en: 
—  la mise à jour des données d'installation du dispositif GNSS externe cont enues dans le dispositif 
GNSS exte rne (si nécessaire), 
—la copie vers la mémoire de la VU, à partir du dispositif GNSS externe, des données d'identif i­
cation nécessaires du dispositif GNSS externe, y compris le numéro de série du dispositif GNSS 
externe, 
Le couplage doit être suivi par la vérification des informations de position du GNSS. 
206)  La fonction d'étalonnag e doit permettre la saisie des données nécessaires par l'intermédiaire de la 
connexion d'étalonnag e/de téléc hargement conf ormément au protocole d'étalonnage défini à 
l'appendice 8. La fonction d'étalonnag e peut également permettre la saisie des données nécessaires 
par d'autres moyens. 
3.22  Contrôles routiers d'ét alonnage 
207)  La fonction de contrôle routier d'étalonnag e doit permettre la lecture du numéro de série du capt eur 
de mouvement (qui peut être intégré dans l'adaptat eur) et du numéro de série du dispositif GNSS 
externe (le cas échéant) qui sont reliés à la VU au moment de la demande. 
208)  Cette lecture doit être au moins possible sur l'unit é embarquée sur le véhicule au moyen de 
commandes se trouvant dans les menus. 26.5.2016 L 139/47 Jour nal officiel de l'Union européenne FR     
209)  La fonction de contrôle routier d'étalonnag e doit également permettre le contrôle de la sélection du 
mode de la ligne de signalisation d'entrée/sor tie d'étalonnag e spécifié dans l'appendice 6, au moyen 
de l'interface avec la ligne K. Ceci doit être réalisé par le biais de la session de réglage «ECU Adjust ­
mentSession», comme spécifi é dans l'appendice 8, section 7, «Contrôle des impulsions d'essai — 
Unit é fonctionnelle de contrôle des entrées/sor ties». 
3.23  Remise à l'heure 
210)  La fonction de remise à l'heure doit permettre de régler l'heure automatiquemen t. Deux sources 
temporelles sont utilisées par l'appareil de contrôle pour la remise à l'heure: 1) l'horloge interne de la 
VU et 2) le récep teur GNSS. 
211)  Le réglage de l'heure de l'horloge interne de la VU est automatique ment réajusté tout es les 12 heures 
au maximum. Lorsque ce délai a expiré et que le signal GNSS n'est pas disponible, le réglage de 
l'heure se fait dès que la VU est en mesure d'accéder à une heure valable fournie par le récep teur 
GNSS, selon les conditions d'allumag e du véhicule. La base temps pour le réglage autom atique de 
l'heure de l'horloge intern e de la VU doit être déterminée à partir du récep teur GNSS. Un événement 
«Conf lit temporel» est déclench é si l'heure courante dévie de plus d'une (1) minute par rappor t à 
l'information temps fournie par le récep teur GNSS. 
212)  La fonction de remise à l'heure doit également permettre de déclenche r le réglage de l'heure courante 
en mode étalonnage. 
3.24  Caractér istiques de perfor mance 
213)  L'unité embarquée sur le véhicule et le dispositif GNSS extern e doivent pouvoir fonctionner 
correctement dans une gamme de températures allant de – 20 °C à 70 °C, et le capt eur de 
mouvement dans une gamme de températures allant de – 40 °C à 135 °C. Le conte nu de la mémoire 
doit être conser vé jusqu'à des températures de – 40 °C. 
214)  Le tach ygraphe doit pouvoir fonctionner correctement dans une gam me d'humidit é compr ise entre 
10 % et 90 %. 
215)  Les scellements utilisés dans le tach ygraphe intellig ent doivent résister aux mêmes conditions que 
celles applicables aux compo sants du tach ygraphe sur lesquels ils sont apposés. 
216)  L'appareil de contrôle doit être protég é contre les surtensions, l'invers ion de polar ités de son 
alimentation électr ique et les cour ts-circuits. 
217)  Le capt eur de mouvement doit: 
—  soit réagir à un cham p magnétique qui perturbe la détection des mouvements du véhicule. Dans 
ces circonstances, l'unit é embarquée enregistrera et stoc kera une anomalie du capt eur 
(exigen ce 88), 
—  soit posséder un élément de détection qui soit protég é des champs magnétiques ou immunisé 
contre ceux-ci. 
218)  L'appareil de contrôle et le dispositif GNSS extern e doivent être conf ormes à la réglementation 
intern ationale R10 de l'ECE-ONU et être protég és contre les déch arges électrostatiques et transitoires. 
3.25  Matér iaux 
219)  Tous les éléments constituant l'appareil de contrôle doivent être en maté riaux d'une stabilit é et d'une 
résistance mécanique suffi santes , et présenter des caract éristiques électr iques et magnétiques stables. 
220)  Toutes les parties internes de l'appareil doivent être protég ées contre l'humidité et la poussière dans 
les conditions normales d'utilisation. 
221)  L'unité embarquée sur le véhicule et le dispositif GNSS externe doivent satisfaire au niveau de 
protection IP 40, et le capt eur de mouvement au niveau de prote ction IP 64, aux term es de la norme 
IEC 60529:1989, y compris les annex es A1:1999 et A2:2013. 26.5.2016 L 139/48 Jour nal officiel de l'Union européenne FR     
222)  L'appareil de contrôle doit être conf orme aux spécifi cations techniques applicables en matière de 
conception ergonomique. 
223)  L'appareil de contrôle doit être protég é contre les détériorations accident elles. 
3.26  Inscr iptions 
224)  Si l'appareil de contrôle affiche la vitesse et le kilométrage du véhicule, les détails suivants doivent 
apparaître: 
—  à côté du chiffre indiquant la distance parcour ue, l'unit é de mesure de cette distance, indiquée par 
l'abréviation «km», 
—  à côté du chiffre indiquant la vitesse, l'indication «km/h». 
L'appareil de contrôle peut également être commuté de manière à afficher la vitess e en miles par 
heure, auquel cas l'unité de mesure de la vitess e sera indiquée par l'abréviation «mp h». L'appareil de 
contrôle peut également être commuté de manière à afficher la distance en miles, auquel cas l'unité 
de mesure de la distance sera indiquée par l'abréviation «mi». 
225)  Une plaque signalétique doit être fixée sur chaque compo sant séparé de l'appareil de contrôle et doit 
compo rter les indications suivante s: 
—  nom et adresse du fabricant de l'appareil, 
—  numéro de pièce du fabricant et année de fabr ication de l'appareil, 
—  numéro de série de l'appareil, 
—  marque d'homologation de l'appareil. 
226)  Lorsque l'espace disponible est insuffi sant pour faire figurer l'ensemble des indications précitées, la 
plaque signalétique doit indiquer au moins: le nom ou le logo du fabricant, et le numéro du 
compo sant de l'appareil. 
4.  EXIGENCES DE FABRICA TION ET EXIGENCES FONCTIONNELLES APPLICABLES AUX CARTES TACHY GRAPHIQUES 
4.1  Données visibles 
Le recto de la carte doit compor ter: 
227)  les mots «car te de conduct eur» ou «car te de contrôleur» ou «car te d'ate lier» ou «car te d'entrepr ise» 
impr imés en majuscules dans la ou les langues officielles de l'État membre qui a délivré la carte, selon 
le type de carte; 
228)  le nom de l'État membre qui a délivré la carte (facultatif); 
229)  le code de l'État membre qui a délivré la carte, imprimé en négatif dans un rectang le bleu et entouré 
de 12 étoiles jaunes. Les codes sont les suivants: 
B 
BG 
CZ 
CY Belgique 
Bulgar ie 
République tchèque 
Chypre LV 
L 
LT 
M Lettonie 
Luxembourg 
Lituanie 
Malte 
DK Danemark NL Pays-Bas 26.5.2016 L 139/49 Jour nal officiel de l'Union européenne FR     
D 
EST Allemagne 
Estonie A 
PL Autr iche 
Pologne 
GR Grèce P 
RO 
SK 
SLO Portugal 
Roumanie 
Slovaquie 
Slovénie 
E Espagne FIN Finlande 
F 
HR 
H France 
Croatie 
Hongr ie S Suède 
IRL Irlande UK Royaume-Uni 
I Italie    
230)  des indications particulières concer nant la carte délivrée, numérotées comme suit:  
Carte du conducteur Carte de contrôleur Carte d'entrepr ise ou d'atelier 
1. nom du conducteur nom de l'organ isme de 
contrôle nom de l'entrepr ise ou de 
l'atelier 
2. prénom(s) du conduct eur nom du contrôleur 
(le cas échéant) nom du détenteur de la carte 
(le cas échéa nt) 
3. date de naissance du conduc ­
teur prénom(s) du contrôleur 
(le cas échéant) prénom(s) du détenteur de la 
carte 
(le cas échéa nt) 
4.a date de début de validité de la carte 
4.b date d'expiration de la carte 
4.c la désignation de l'aut orité qui a délivré la carte (peut être impr imée au verso) 
4.d un numéro différent de celui indiqué au point 5, à des fins administratives (mention faculta ­
tive) 
5. a numéro du permis de 
conduire 
(à la date de délivrance de la 
carte de conducteur) — — 
5. b numéro de la carte 
6. photog raphie du conduct eur photog raphie du contrôleur 
(facultatif) photographie de l'installateur 
(facultatif) 26.5.2016 L 139/50 Jour nal officiel de l'Union européenne FR     
Carte du conducteur Carte de contrôleur Carte d'entrepr ise ou d'atelier 
7. signature du détent eur (facultatif) 
8. lieu habituel de résidence, ou 
adresse postale du détenteur 
(facultatif) adresse postale de l'orga ­
nisme de contrôle adresse postale de l'entrepr ise 
ou de l'atelier  
231)  Les date s sont indiquées sous la forme «jj/mm/aaaa» ou «jj.mm.aaaa» (jour , mois, année). 
Le verso de la carte doit compo rter: 
232)  une légende des numéros indiqués au recto; 
233)  avec l'accord écrit exprès du détent eur, des informations non liées à l'administration de la carte 
peuvent également être indiquées, pour autant qu'elles ne modifien t en rien l'utilisation du modèle 
comme carte tach ygraphique. 
234)  Les cartes tach ygraphiques doivent être imprimées sur les fonds de couleur suivants:  
— carte de conduct eur: blanc,  
— carte de contrôleur: bleu,  
— carte d'atelier: rouge,  
— carte d'entrepr ise: jaune. 
235)  Les cartes tach ygraphiques présent ent les éléments de prot ection suivants contre la contref açon et la 
manipulation: 
—  impression de fond de sécur ité finement guillochée et irisée, 
—  chevauchement de l'impr ession de fond de sécur ité et de la photog raphie, 
—  au moins une ligne bicolore micro-imprimée .  26.5.2016 L 139/51 Jour nal officiel de l'Union européenne FR     
236)  Après consultation de la Commission, les États membres peuvent ajout er des couleurs et des 
inscr iptions , tels que des symboles nationaux et des éléments de sécur ité, sans préjudice des autres 
dispositions de la présent e annexe . 
237)  Les cartes temporaires visées à l'article 26, paragraphe 4, du règlement (UE) no 165/2014 doivent être 
conf ormes aux dispositions de la présente annexe. 
4.2  Sécur ité 
La sécur ité du système vise à prot éger l'intégri té et l'authenticit é des données échang ées entre les cartes et 
l'appareil de contrôle, ainsi que l'intégri té et l'authenticité des données téléc hargée s à partir des cartes, en 
autori sant uniquement certaines opérations d'inscr iption sur les cartes par l'appareil de contrôle, en 
décr yptant certaines données, en excl uant tout e possibilit é de falsification des données stoc kées sur les 
cartes, en empê chant les manipulations et en détectant tout e tentative en ce sens. 
238)  Afin d'assurer cette sécur ité, les cartes tach ygraphiques doivent satisfaire aux exige nces de sécur ité 
définies dans les appendices 10 et 11. 26.5.2016 L 139/52 Jour nal officiel de l'Union européenne FR     
239)  Les cartes tach ygraphiques doivent pouvoi r être lues par d'autres appareils, tels que des micro- 
ordinateurs. 
4.3  Nor mes 
240)  Les cartes tach ygraphiques doivent être conf ormes aux normes suivantes: 
—  ISO/IEC 7810 Cartes d'identification — Caractéristi ques physiques, 
—  ISO/IEC 7816 Cartes d'identification — Cartes à circuit(s) intégré (s): 
—  Partie 1: caractér istiques physiques, 
—  Partie 2: dimensions et emplacement des contacts (ISO/IEC 7816-2:2007), 
—  Partie 3: interface électr ique et protocoles de transmission (ISO/IEC 7816-3:2006), 
—  Partie 4: organisation, sécur ité et commandes pour les échang es (ISO/IEC 7816-4:2013 + Cor 
1:2014), 
—  Partie 6: éléments de données intersector iels pour les échanges (ISO/IEC 7816-6:2004 + Cor 
1:2006), 
—  Partie 8: commandes pour des opérations de sécur ité (ISO/IEC 7816-8:2004). 
—  Les cartes tach ygraphiques doivent être testées conf ormément à la norme ISO/IEC 10373-3: 2010 
Cartes d'identif ication — Méthodes d'essai — Partie 3: cartes à circuit(s) intégré(s) à contacts et 
dispositifs d'interface assimilés. 
4.4  Spécif ications environnement ales et électr iques 
241)  Les cartes tach ygraphiques doivent pouv oir fonctionner correctement dans tout es les conditions 
climatiques normalement obser vées sur le territoire communautaire, et au minimum dans une 
gamme de température comprise entre – 25 °C et + 70 °C, avec des pointes occasionnelles à + 85 °C, 
«occasionnelles» signif iant d'une durée infér ieure ou égale à 4 heures et survenant au maximum à 
100 repr ises au cours de la durée de vie de la carte. 
242)  Les cartes tach ygraphiques doivent pouv oir fonctionner correcte ment dans une gamme d'humidit é 
compris e entre 10 % et 90 %. 
243)  Les cartes tach ygraphiques doivent pouvoi r fonctionner correctement pendant une période de cinq 
ans si elles sont utilisées conf ormément aux spécifi cations environnementales et électr iques. 
244)  En fonctionnement, les cartes tach ygraphiques doivent satisf aire à la réglementation R10 de l'ECE- 
ONU, relative à la compat ibilité électromagnétique, et doivent être protég ées contre les décharges 
électrostatiques. 
4.5  Stocka ge des données 
Aux fins du présent paragraphe, 
—  les heures sont enregistrées à la minute près, sauf indication contraire, 
—  le kilométrage est enregistré au kilomètre près, 
—  les vitess es sont enregistrées au kilomètre/heure près, 
—  les positions (latitudes et longitudes) sont enregistrées en degrés et en minut es, au dixième de minut e 
près. 
Les fonctions, les commandes et les structures logiques des cartes tach ygraphiques qui satisf ont aux 
exigenc es en matière de stoc kage des données sont spécifi ées à l'appendice 2. 
Sauf indication contraire, le stoc kage de données sur les cartes tach ygraphiques doit être organisé de telle 
manière que les données nouvelles rem placent les données stoc kées les plus anciennes dans les cas où la 
mémoire prévue pour les enregistrements concer nés est épuisée. 26.5.2016 L 139/53 Jour nal officiel de l'Union européenne FR     
245)  Le présent paragraphe précise la capacit é minimale de stoc kage des données des divers fichiers 
d'application. Les cartes tach ygraphiques doivent pouvoir indiquer à l'appareil de contrôle la capacit é 
réelle de stoc kage de ces fichiers. 
246)  Toutes les données supplémentaires qui peuvent être stoc kées sur des cartes tach ygraphiques, liées à 
d'autres applications éventuellement présentes sur la carte, doivent être stoc kées conf ormément à la 
directive 95/46/CE à la directive 2002/58/CE et en conf ormité avec l'article 7 du règlement (UE) 
no 165/2014. 
247)  Chaque fichier maître (MF) d'une carte tach ygraphique doit cont enir jusqu'à cinq fichiers élémentaires 
(EF) pour la gestion de la carte, l'application et les identif ications de puce, ainsi que deux fichiers 
dédiés (DF): 
—  DF Tachog raph, qui contient l'application accessible à la première génération de VU et qui est 
également présent sur les cartes tach ygraphiques de première génération, 
—  DF Tachog raph_G2, qui contient l'application accessible à la deuxième génération de VU et qui 
est seulement présent sur les cartes tach ygraphiques de deuxième génération. 
L'intégralit é des détails relatifs à la structure des cartes tach ygraphiques est spécifiée dans 
l'appendice 2. 
4.5.1  Fichiers élémentaires pour l'identific ation et la gestion des cartes 
4.5.2  Identific ation des cartes à circuit intég ré 
248)  Les cartes tach ygraphiques doivent pouvoi r stoc ker les données suivantes pour l'identifi cation des 
cartes intelligent es: 
—  arrêt d'horlog e, 
—  numéro de série de la carte (y compris les références de fabr ication), 
—  numéro d'homologation de la carte, 
—  identif ication personnelle de la carte, 
—  identif ication de l'intégrateur , 
—  identif icateur du circuit intégré. 
4.5.2.1  Identification du microprocesseur 
249)  Les cartes tach ygraphiques doivent pouvoi r stoc ker les données suivantes pour l'identifi cation des 
circuits intégrés: 
—  numéro de série du circuit intégré, 
—  référen ces de fabrication du circuit intégré. 
4.5.2.2  DIR (uniquement présent sur les car tes tach ygraphiques de deuxième génération) 
250)  Les cartes tach ygraphiques doivent pouvoi r stoc ker les objets de données pour l'identifi cation des 
applications spécifi és dans l'appendice 2. 
4.5.2.3  Informations ATR (conditionnelles, présent es uniquement sur les car tes tach ygraphiques 
de deuxième génération) 
251)  Les cartes tach ygraphiques doivent pouvoir stoc ker l'objet de données suivant relatif aux informations 
sur la période étendue: 
—  lorsque la carte de tach ygraphe prend en charge les champs de période étendue, l'objet de 
données relatif aux informations sur la période étendue spécifi é dans l'appendice 2. 26.5.2016 L 139/54 Jour nal officiel de l'Union européenne FR     
4.5.2.4  Informations relatives à la pér iode étendue (conditionnelles, présent es uniquement sur 
les car tes tach ygraphiques de deuxième génération) 
252)  Les cartes tach ygraphiques doivent pouv oir stoc ker les objets de données suivants relatifs aux 
informations sur la période étendue: 
—  lorsque la carte de tach ygraphe prend en charge les champs de période étendue, les objets de 
données relatifs aux informations sur la période étendue spécifiés dans l'appendice 2. 
4.5.3  Carte de conducteur 
4.5.3.1  Application tach ygraphique (accessible aux unité s embarquées de première et deuxième 
générations) 
4.5.3.1.1  Identification des applications 
253)  La carte de conduct eur doit pouvoir stoc ker les données suivantes pour l'identifi cation des 
applications: 
—  identif ication de l'application tach ygraphique, 
—  identif ication du type de carte tach ygraphique. 
4.5.3.1.2  Clés et certificats 
254)  La carte de conduct eur doit être en mesure de stoc ker un certain nombre de certificats et de clés 
cryptographiques, comme spécifi é dans l'appendice 11, partie A. 
4.5.3.1.3  Identification de carte 
255)  La carte de conduct eur doit pouvoir stoc ker les données suivantes pour l'identification de la carte: 
—  numéro de la carte, 
—  État membre qui a délivré la carte, autorité compét ente pour la délivrance, date de délivrance, 
—  date de début de validité de la carte, et date d'expiration. 
4.5.3.1.4  Identification du détenteur de la carte 
256)  La carte de conduct eur doit pouv oir stoc ker les données suivante s pour l'identifi cation du détenteur 
de la carte: 
—  nom du détent eur, 
—  prénom(s) du détenteur , 
—  date de naissance, 
—  langue habituelle. 
4.5.3.1.5  Téléc hargement (download) d'une carte 
257)  La carte de conducteur doit permettre le stoc kage des données suivantes concer nant le téléc hargem ent 
des cartes: 
—  date et heure du dernier téléc hargement d'une carte (à d'autres fins que le contrôle). 
258)  La carte de conduct eur doit permettre le stoc kage d'un de ces enregistrements. 
4.5.3.1.6  Renseignements concer nant le permis de conduire 
259)  La carte de conduct eur doit pouvoir stoc ker les données suivantes concer nant le permis de conduire: 
—  État membre qui a délivré le permis, nom de l'aut orité compét ente pour la délivrance, 
—  numéro du permis de conduire (à la date de délivrance de la carte). 26.5.2016 L 139/55 Jour nal officiel de l'Union européenne FR     
4.5.3.1.7  Données relatives aux événements 
Aux fins du présent point, l'heure est enregistrée à la seconde près. 
260)  La carte de conducteur doit permettre le stoc kage des données liées aux événements suivants détectés 
par l'appareil de contrôle alors que la carte est insérée: 
—  chevauchement temporel (lorsque la carte est la cause de l'événement), 
—  inser tion d'une carte en cours de conduite (lorsque cet événement concer ne la carte), 
—  clôture incor recte de la session précédente (lorsque cet événement concer ne la carte), 
—  interr upti on de l'alimentation électr ique, 
—  erreur sur les données de mouvement, 
—  tentatives d'attein te à la sécur ité. 
261)  La carte de conduct eur doit permettre le stoc kage des données suivantes concer nant ces événements: 
—  code d'événement, 
—  date et heure du début de l'événement (ou de l'inser tion de la carte dans le cas où l'événement 
était en cours à ce moment-là), 
—  date et heure de la fin de l'événement (ou du retrait de la carte si l'événement était en cours à ce 
moment-là), 
—  numéro et État membre d'immatr iculation du véhicule dans lequel l'événement est survenu. 
Remarque: concer nant l'événement «chevauc hement temporel»: 
—  la date et l'heure du début de l'événement doivent correspondre à la date et à l'heure du retrait de 
la carte du véhicule précédent, 
—  la date et l'heure de la fin de l'événement doivent correspondre à la date et à l'heure de l'inser tion 
de la carte dans le véhicule actuel, 
—  les données relatives au véhicule doivent correspondre au véhicule actuel où l'événement est 
appar u. 
Remarque: concer nant l'événement «clôture incor recte de la session précédente »: 
—  la date et l'heure du début de l'événement doivent correspondre à la date et à l'heure de l'inser tion 
de la carte correspondant à la session incor rectement clôturée, 
—  la date et l'heure de la fin de l'événement doivent correspondre à la date et à l'heure de l'inser tion 
de la carte pour la session au cours de laquelle l'événement a été détect é (session en cours), 
—  les données relatives au véhicule doivent correspondre au véhicule dans lequel la session a été 
incor recte ment clôturée. 
262)  La carte de conduct eur doit permettre le stockag e des données concer nant les six derniers 
événements de chaque type (soit 36 événements). 
4.5.3.1.8  Données relatives aux anomalies 
Aux fins du présent point, l'heure est enregistrée à la seconde près. 
263)  La carte de conducteur doit permettre le stockag e des données relatives aux anomalies suivantes 
détec tées par l'appareil de contrôle alors que la carte est insérée: 
—  anomalie de la carte (lorsque la carte est à l'origine de l'événement), 
—  anomalie de l'appareil de contrôle. 26.5.2016 L 139/56 Jour nal officiel de l'Union européenne FR     
264)  La carte de conduct eur doit permettre le stoc kage des données suivantes pour ces anomalies: 
—  code de l'anomalie, 
—  date et heure du début de l'anomalie (ou de l'inser tion de la carte dans le cas où l'anomalie était 
en cours à ce moment-là), 
—  date et heure de la fin de l'anomalie (ou du retrait de la carte si l'anomalie était en cours à ce 
moment-là), 
—  numéro et État membre d'immatr iculation du véhicule dans lequel l'anomalie est survenue. 
265)  La carte de conduct eur doit permettre le stoc kage des données relatives aux douze dernières 
anomalies par type (soit 24 anomalies). 
4.5.3.1.9  Données relatives aux activités du conduct eur 
266)  La carte de conduct eur doit pouvoi r stoc ker, pour chaque jour civil au cours duquel la carte a été 
utilisée ou le conduct eur a saisi les activités manuellement, les données suivantes: 
—  date , 
—  comp teur de présence jour nalière (augmenté d'une unité pour chacun de ces jours civils), 
—  distance totale parcour ue par le conducteur pendant cette jour née, 
—  situation du conduct eur à 00h00, 
—  les chang ements d'activit é du conduct eur et/ou les change ments de situation de conduite et/ou 
l'inser tion ou le retrait de la carte de conduct eur: 
—  situation de conduite (ÉQUIP AGE, SEUL), 
—  lecte ur (COND UCTEUR, CONV OYEUR), 
—  situation de la carte (INSÉRÉE, NON INSÉRÉE), 
—  activité (CONDUITE, DISPONIBILITÉ, TRA VAIL, PAUSE/REPOS), 
—  heure du changem ent. 
267)  La mémoire de la carte de conduct eur doit permettre le stoc kage des données relatives à l'activité du 
conducteur pendant au moins 28 jours (l'activité moyenne d'un conducteur est définie comme 93 
chang ements d'activité par jour). 
268)  Les données énumérées aux exigences 261, 264 et 266 doivent être stoc kées d'une manière 
permettant de retrouver les activités dans l'ordre de leur occur rence, même en cas de chevauchement 
temporel. 
4.5.3.1.10  Données concer nant les véhicules utilisés 
269)  La carte de conduct eur doit pouv oir stoc ker, pour chaque jour civil où la carte a été utilisée, et pour 
chaque période d'utilisation d'un véhicule donné ce jour -là (une période d'utilisation compr end tous 
les cycles consécutifs d'inser tion/retrait de la carte dans le véhicule, en se plaçant du point de vue de 
la carte), les données suivante s: 
—  date et heure de la première utilisation du véhicule (c'est-à-dire de la première inser tion de la carte 
pour cette période d'utilisation du véhicule, ou 00h00 si la période d'utilisation est en cours à 
cette heure-là), 
—  kilométrage du véhicule à ce moment, 
—  date et heure de la dernière utilisation du véhicule (c'est-à-dire le dernier retrait de la carte pour 
cette période d'utilisation du véhicule, ou 23h59 si la période d'utilisation est en cours à cette 
heure-là), 
—  kilométrage du véhicule à ce moment, 
—  numéro et État membre d'immatr iculation du véhicule. 26.5.2016 L 139/57 Jour nal officiel de l'Union européenne FR     
270)  La carte de conduct eur doit pouvoir stoc ker au moins 84 enregistrements de ce type. 
4.5.3.1.11  Lieux de début/de fin des périodes jour nalières de travai l 
271)  La carte de conduct eur doit permettre le stoc kage des données suivantes relatives aux lieux de début 
et/ou de fin des périodes jour nalières de travai l, saisies par le conduct eur: 
—  date et heure de la saisie (ou date/heure liée à la saisie, si celle-ci est réalisée au cours de la 
procédure de saisie manuelle), 
—  type de saisie (début ou fin, condition de saisie), 
—  pays et région saisis, 
—  kilométrage du véhicule. 
272) La mémoire de la carte de conduct eur doit permettre le stoc kage d'au moins 42 paires d'enregis ­
trements de ce type. 
4.5.3.1.12  Données concer nant les sessions pour chaque carte 
273)  La carte de conduct eur doit permettre le stoc kage des données suivante s relatives au véhicule dans 
lequel s'est ouver te la session en cours: 
—  date et heure d'ouver ture de la session (c.-à-d. de l'inser tion de la carte), à la seconde près, 
—  numéro et État membre d'immatr iculation du véhicule. 
4.5.3.1.13  Données relatives aux activités de contrôle 
274)  La carte de conduct eur doit permettre le stoc kage des données suivantes concer nant les activités de 
contrôle: 
—  date et heure du contrôle, 
—  numéro de la carte de contrôleur et État membre qui l'a délivrée, 
—  type de contrôle [affichage et/ou impression et/ou téléc hargement à partir de la VU et/ou à partir 
de la carte (voir remarque)], 
—  période téléc harg ée, le cas éché ant, 
—  numéro et État membre d'immatr iculation du véhicule dans lequel le contrôle a été effectué. 
Remarque: le téléc hargement d'une carte ne sera enregistré que s'il est effectué par l'intermédiaire d'un 
appareil de contrôle. 
275)  La carte de conduct eur doit permettre le stoc kage d'un de ces enregistrements. 
4.5.3.1.14  Données concer nant les conditions particulières 
276)  La carte de conducteur doit permettre le stoc kage des données suivantes relatives aux conditions 
particulières saisies alors que la carte est insérée (quel que soit le lecteur ): 
—  la date et l'heure de la saisie, 
—  le type de condition particulière. 
277)  La carte de conduct eur doit pouvoir stoc ker au moins 56 enregistrements de ce type. 26.5.2016 L 139/58 Jour nal officiel de l'Union européenne FR     
4.5.3.2  Application tach ygraphique de deuxième génération (non accessible aux VU de première 
génération) 
4.5.3.2.1  Identification des applications 
278)  La carte de conduct eur doit pouvoir stoc ker les données suivantes pour l'identifi cation des 
applications: 
—  identif ication de l'application tach ygraphique, 
—  identif ication du type de carte tach ygraphique. 
4.5.3.2.2  Clés et certificats 
279)  La carte de conduct eur doit être en mesure de stoc ker un certain nombre de certificats et de clés 
cryptographiques, comme spécifi é dans l'appendice 11, partie B. 
4.5.3.2.3  Identification de carte 
280)  La carte de conduct eur doit pouvoir stoc ker les données suivantes pour l'identification de la carte: 
—  numéro de la carte, 
—  État membre qui a délivré la carte, autorité compét ente pour la délivrance, date de délivrance, 
—  date de début de validité de la carte, et date d'expiration. 
4.5.3.2.4  Identification du détenteur de la carte 
281)  La carte de conduct eur doit pouv oir stoc ker les données suivante s pour l'identifi cation du détenteur 
de la carte: 
—  nom du détent eur, 
—  prénom(s) du détenteur , 
—  date de naissance, 
—  langue habituelle. 
4.5.3.2.5  Téléc hargement (download) d'une carte 
282)  La carte de conducteur doit permettre le stoc kage des données suivantes concer nant le téléc hargem ent 
des cartes: 
—  date et heure du dernier téléc hargement d'une carte (à d'autres fins que le contrôle). 
283)  La carte de conduct eur doit permettre le stoc kage d'un de ces enregistrements. 
4.5.3.2.6  Renseignements concer nant le permis de conduire 
284)  La carte de conduct eur doit pouvoir stoc ker les données suivantes concer nant le permis de conduire: 
—  État membre qui a délivré le permis, nom de l'aut orité compét ente pour la délivrance, 
—  numéro du permis de conduire (au moment de la délivrance de la carte). 
4.5.3.2.7  Données relatives aux événements 
Aux fins du présent point, l'heure est enregistrée à la seconde près. 26.5.2016 L 139/59 Jour nal officiel de l'Union européenne FR     
285)  La carte de conducteur doit permettre le stoc kage des données liées aux événements suivants détectés 
par l'appareil de contrôle alors que la carte est insérée: 
—  chevauchement temporel (lorsque la carte est la cause de l'événement), 
—  inser tion d'une carte en cours de conduite (lorsque cet événement concer ne la carte), 
—  clôture incor recte de la session précédente (lorsque cet événement concer ne la carte), 
—  interr upti on de l'alimentation électr ique, 
—  erreur de communication avec le dispositif de communication à distance, 
—  absence d'inf ormations de positionnement en provenance du récep teur GNSS, 
—  erreur de communication avec le dispositif GNSS extern e, 
—  erreur sur les données de mouvement, 
—  conf lit concer nant le mouvement du véhicule, 
—  tentatives d'attein te à la sécur ité, 
—  conf lit temporel. 
286)  La carte de conduct eur doit permettre le stoc kage des données suivantes concer nant ces événements: 
—  code d'événement, 
—  date et heure du début de l'événement (ou de l'inser tion de la carte dans le cas où l'événement 
était en cours à ce moment-là), 
—  date et heure de la fin de l'événement (ou du retrait de la carte si l'événement était en cours à ce 
moment-là), 
—  numéro et État membre d'immatr iculation du véhicule dans lequel l'événement est survenu. 
Remarque: concer nant l'événement «chevauc hement temporel»: 
—  la date et l'heure du début de l'événement doivent correspondre à la date et à l'heure du retrait de 
la carte du véhicule précédent, 
—  la date et l'heure de la fin de l'événement doivent correspondre à la date et à l'heure de l'inser tion 
de la carte dans le véhicule actuel, 
—  les données relatives au véhicule doivent correspondre au véhicule actuel où l'événement est 
appar u. 
Remarque: concer nant l'événement «clôture incor recte de la session précédente »: 
—  la date et l'heure du début de l'événement doivent correspondre à la date et à l'heure de l'inser tion 
de la carte correspondant à la session incor rectement clôturée, 
—  la date et l'heure de la fin de l'événement doivent correspondre à la date et à l'heure de l'inser tion 
de la carte pour la session au cours de laquelle l'événement a été détect é (session en cours), 
—  les données relatives au véhicule doivent correspondre au véhicule dans lequel la session a été 
incor recte ment clôturée. 
287)  La carte de conduct eur doit permettre le stockag e des données concer nant les six derniers 
événements de chaque type (soit 66 événements). 
4.5.3.2.8  Données relatives aux anomalies 
Aux fins du présent point, l'heure est enregistrée à la seconde près. 26.5.2016 L 139/60 Jour nal officiel de l'Union européenne FR     
288)  La carte de conducteur doit permettre le stockag e des données relatives aux anomalies suivantes 
détec tées par l'appareil de contrôle alors que la carte est insérée: 
—  anomalie de la carte (lorsque la carte est à l'origine de l'événement), 
—  anomalie de l'appareil de contrôle. 
289)  La carte de conduct eur doit permettre le stoc kage des données suivantes pour ces anomalies: 
—  code de l'anomalie, 
—  date et heure du début de l'anomalie (ou de l'inser tion de la carte dans le cas où l'anomalie était 
en cours à ce moment-là), 
—  date et heure de la fin de l'anomalie (ou du retrait de la carte si l'anomalie était en cours à ce 
moment-là), 
—  numéro et État membre d'immatr iculation du véhicule dans lequel l'anomalie est survenue. 
290)  La carte de conduct eur doit permettre le stoc kage des données relatives aux douze dernières 
anomalies par type (soit 24 anomalies). 
4.5.3.2.9  Données relatives aux activités du conduct eur 
291)  La carte de conduct eur doit pouvoi r stoc ker, pour chaque jour civil au cours duquel la carte a été 
utilisée ou le conduct eur a saisi les activités manuellement, les données suivantes: 
—  date , 
—  comp teur de présence jour nalière (augmenté d'une unité pour chacun de ces jours civils), 
—  distance totale parcour ue par le conducteur pendant cette jour née, 
—  situation du conduct eur à 00h00, 
—  les chang ements d'activit é du conduct eur; et/ou les changements de situation de conduit e, et/ou 
l'inser tion ou le retrait de la carte de conduct eur: 
—  situation de conduite (ÉQUIP AGE, SEUL), 
—  lecte ur (COND UCTEUR, CONV OYEUR), 
—  situation de la carte (INSÉRÉE, NON INSÉRÉE), 
—  activité (CONDUITE, DISPONIBILITÉ, TRA VAIL, PAUSE/REPOS), 
—  heure du changem ent. 
292)  La mémoire de la carte de conduct eur doit permettre le stoc kage des données relatives à l'activité du 
conducteur pendant au moins 28 jours (l'activité moyenne d'un conducteur est définie comme 93 
chang ements d'activité par jour). 
293)  Les données énumérées aux exigences 286, 289 et 291 doivent être stoc kées d'une manière 
permettant de retrouver les activités dans l'ordre de leur occur rence, même en cas de chevauchement 
temporel. 
4.5.3.2.10  Données concer nant les véhicules utilisés 
294)  La carte de conduct eur doit pouv oir stoc ker, pour chaque jour civil où la carte a été utilisée, et pour 
chaque période d'utilisation d'un véhicule donné ce jour -là (une période d'utilisation compr end tous 
les cycles consécutifs d'inser tion/retrait de la carte dans le véhicule, en se plaçant du point de vue de 
la carte), les données suivante s: 
—  date et heure de la première utilisation du véhicule (c'est-à-dire de la première inser tion de la carte 
pour cette période d'utilisation du véhicule, ou 00h00 si la période d'utilisation est en cours à 
cette heure-là), 26.5.2016 L 139/61 Jour nal officiel de l'Union européenne FR     
—  kilométrage du véhicule au moment de cette première utilisation, 
—  date et heure de la dernière utilisation du véhicule (c'est-à-dire le dernier retrait de la carte pour 
cette période d'utilisation du véhicule, ou 23h59 si la période d'utilisation est en cours à cette 
heure-là), 
—  kilométrage du véhicule au moment de cette dernière utilisation, 
—  numéro et État membre d'immatr iculation du véhicule, 
—  numéro d'identif ication du véhicule. 
295)  La carte de conduct eur doit pouvoir stoc ker au moins 84 enregistrements de ce type. 
4.5.3.2.11  Lieux et positions de début/fin des périodes jour nalières de travail 
296)  La carte de conduct eur doit permettre le stoc kage des données suivantes relatives aux lieux de début 
et/ou de fin des périodes jour nalières de travai l, saisies par le conduct eur: 
—  date et heure de la saisie (ou date/heure liée à la saisie, si celle-ci est réalisée au cours de la 
procédure de saisie manuelle), 
—  type de saisie (début ou fin, condition de saisie), 
—  pays et région saisis, 
—  kilométrage du véhicule, 
—  position du véhicule, 
—  la précision GNSS, la date et l'heure de détermination de la position. 
297) La mémoire de la carte de conduct eur doit permettre le stoc kage d'au moins 84 paires d'enregis ­
trements de ce type. 
4.5.3.2.12  Données concer nant les sessions pour chaque carte 
298)  La carte de conduct eur doit permettre le stoc kage des données suivante s relatives au véhicule dans 
lequel s'est ouver te la session en cours: 
—  date et heure d'ouver ture de la session (c.-à-d. de l'inser tion de la carte), à la seconde près, 
—  numéro et État membre d'immatr iculation du véhicule. 
4.5.3.2.13  Données relatives aux activités de contrôle 
299)  La carte de conduct eur doit permettre le stoc kage des données suivantes concer nant les activités de 
contrôle: 
—  date et heure du contrôle, 
—  numéro de la carte de contrôleur et État membre qui l'a délivrée, 
—  type de contrôle [affichage et/ou impression et/ou téléc hargement à partir de la VU et/ou à partir 
de la carte (voir remarque)], 
—  période téléc harg ée, le cas éché ant, 
—  numéro et État membre d'immatr iculation du véhicule dans lequel le contrôle a été effectué. 
Remarque: les exige nces de sécur ité impliquent que le télécharg ement d'une carte ne sera enregistré 
que s'il est effectué par l'inter médiaire d'un appareil de contrôle. 
300)  La carte de conduct eur doit permettre le stoc kage d'un de ces enregistrements. 26.5.2016 L 139/62 Jour nal officiel de l'Union européenne FR     
4.5.3.2.14  Données concer nant les conditions particulières 
301)  La carte de conducteur doit permettre le stoc kage des données suivantes relatives aux conditions 
particulières saisies alors que la carte est insérée (quel que soit le lecteur ): 
—  la date et l'heure de la saisie, 
—  le type de condition particulière. 
302)  La carte de conduct eur doit pouvoir stoc ker au moins 56 enregistrements de ce type. 
4.5.3.2.15  Données concer nant les unités embarquées sur véhicule qui ont été utilisées 
303)  La carte de conducteur doit permettre le stockag e des données suivantes relatives aux diffé rentes 
unités embarquées sur véhicule dans lesquelles la carte a été utilisée: 
—  la date et l'heure du début de la période d'utilisation de l'unit é embarquée sur le véhicule (c'est-à- 
dire de la première inser tion de la carte dans l'unit é embarquée sur véhicule pour cette période), 
—  le fabricant de l'unit é embarquée sur véhicule, 
—  le type de VU, 
—  le numéro de version du logiciel de la VU. 
304)  La carte de conduct eur doit pouvoir stoc ker au moins 84 enregistrements de ce type. 
4.5.3.2.16  Données relatives aux lieux où les trois heures de conduite continue ont été atteint es 
305)  La carte de conduct eur doit permettre le stoc kage des données suivantes relatives à la position du 
véhicule lorsque le temps de conduite continue du conduct eur atteint un multiple de trois heures: 
—  la date et l'heure où le temps de conduite continue du détenteur de la carte atteint un multiple de 
trois heures, 
—  la position du véhicule, 
—  la précision GNSS, la date et l'heure de détermination de la position. 
306)  La carte de conduct eur doit pouvoir stoc ker au moins 252 enregistrements de ce type. 
4.5.4  Carte d'atelier 
4.5.4.1  Application tach ygraphique (accessible aux unité s embarquées de première et deuxième 
générations) 
4.5.4.1.1  Identification des applications 
307)  La carte d'ate lier doit permettre le stoc kage des données suivantes pour l'identifi cation des 
applications: 
—  identif ication de l'application tach ygraphique, 
—  identif ication du type de carte tach ygraphique. 
4.5.4.1.2  Clés et certificats 
308) La carte d'ate lier doit être en mesure de stoc ker un certain nombre de certificat s et de clés cryptogra ­
phiques, comme spécifi é dans l'appendice 11, partie A. 26.5.2016 L 139/63 Jour nal officiel de l'Union européenne FR     
309)  La carte d'ateli er doit permettre le stoc kage d'un numéro personnel d'identification (code PIN). 
4.5.4.1.3  Identification de carte 
310)  La carte d'ateli er doit permettre le stoc kage des données suivantes pour l'identifi cation de la carte: 
—  numéro de la carte, 
—  État membre qui a délivré la carte, autorité compét ente pour la délivrance, date de délivrance, 
—  date de début de validité de la carte, et date d'expiration. 
4.5.4.1.4  Identification du détenteur de la carte 
311)  La carte d'ateli er doit permettre le stoc kage des données suivantes pour l'identifi cation du détenteur 
de la carte: 
—  nom de l'ate lier, 
—  adresse de l'ate lier, 
—  nom du détent eur, 
—  prénom(s) du détenteur , 
—  langue habituelle. 
4.5.4.1.5  Téléc hargement (download) d'une carte 
312) La carte d'ateli er doit permettre le stoc kage des enregistrements de données relatives au téléc har­
gement d'une carte de la même manière qu'une carte de conduct eur. 
4.5.4.1.6  Données concer nant l'étalonnage et la remise à l'heure 
313)  La carte d'ate lier doit permettre le stoc kage des enregistrements de données relatives aux étalonnages 
et/ou aux remises à l'heure réalisés alors que la carte est insérée dans l'appareil. 
314)  Chaque enregistrement d'étalonnage doit pouvoi r cont enir les données suivantes: 
—  objet de l'étalonnag e (activation, première installation, installation, inspection périodique), 
—  identif ication du véhicule, 
—  paramètres mis à jour ou confir més [w, k, l, taille des pneumatiques, réglage du limiteur de 
vites se, comp teur kilométr ique (valeurs nouvelle et ancienne), date et heure (valeurs nouvelle et 
ancienne)], 
—  identif ication de l'appareil de contrôle (numéros des pièces et numéro de série de la VU, numéro 
de série du capt eur de mouvement). 
315)  La carte d'ateli er doit permettre le stoc kage d'au moins 88 enregistrements de ce type. 
316)  La carte d'ateli er doit compo rter un comp teur indiquant le nombre total d'étalonnag es réalisés avec la 
carte. 
317)  La carte d'atelier doit compo rter un comp teur indiquant le nombre d'étalonnages réalisés depuis le 
dernier téléc hargement. 26.5.2016 L 139/64 Jour nal officiel de l'Union européenne FR     
4.5.4.1.7  Données relatives aux événements et aux anomalies 
318)  La carte d'atelier doit permettre le stoc kage des enregistrements de données relatives aux événements 
et aux anomalies de la même manière qu'une carte de conducteur . 
319)  La carte d'atelier doit permettre le stoc kage des trois derniers événements de chaque type (soit 18 
événements) et des six dernières anomalies de chaque type (soit 12 anomalies). 
4.5.4.1.8  Données relatives aux activités du conduct eur 
320)  La carte d'ate lier doit permettre le stoc kage de données concer nant l'activit é du conducteur de la 
même manière que la carte de conduct eur. 
321)  La carte d'ateli er doit permettre le stoc kage de données concer nant l'activité du conduct eur pendant 
au moins 1 jour d'activit é moyenne du conduct eur. 
4.5.4.1.9  Données concer nant les véhicules utilisés 
322)  La carte d'ate lier doit permettre le stoc kage des enregistrements de données relatives aux véhicules 
utilisés de la même manière que la carte de conducteur . 
323)  La carte d'ateli er doit permettre le stoc kage d'au moins 4 enregistrements de ce type. 
4.5.4.1.10  Données concer nant le début et/ou la fin des périodes de travail jour nalières 
324)  La carte d'atelier doit permettre le stoc kage des enregistrements de données relatives au début et/ou à 
la fin des périodes de travail jour nalières de la même manière qu'une carte de conduct eur. 
325)  La carte d'ateli er doit permettre le stoc kage d'au moins 3 paires d'enregistrements de ce type. 
4.5.4.1.11  Données concer nant les sessions pour chaque carte 
326)  La carte d'ateli er doit permettre le stoc kage des enregistrements de données relatives à une session de 
carte de la même manière qu'une carte de conduct eur. 
4.5.4.1.12  Données relatives aux activités de contrôle 
327)  La carte d'atelier doit permettre le stoc kage des enregistrements de données relatives aux activité s de 
contrôle de la même manière qu'une carte de conduct eur. 
4.5.4.1.13  Données concer nant les conditions particulières 
328)  La carte d'ateli er doit permettre le stockag e des données relatives aux conditions particulières de la 
même manière qu'une carte de conducteur . 
329)  La carte d'ateli er doit permettre le stoc kage d'au moins 2 enregistrements de ce type. 
4.5.4.2  Application tach ygraphique de deuxième génération (non accessible aux VU de première 
génération) 
4.5.4.2.1  Identification des applications 
330)  La carte d'ate lier doit permettre le stoc kage des données suivantes pour l'identifi cation des 
applications: 
—  identif ication de l'application tach ygraphique, 
—  identif ication du type de carte tach ygraphique. 26.5.2016 L 139/65 Jour nal officiel de l'Union européenne FR     
4.5.4.2.2  Clés et certificats 
331) La carte d'ate lier doit être en mesure de stoc ker un certain nombre de certificat s et de clés cryptogra ­
phiques, comme spécifi é dans l'appendice 11, partie B. 
332)  La carte d'ateli er doit permettre le stoc kage d'un numéro personnel d'identification (code PIN). 
4.5.4.2.3  Identification de carte 
333)  La carte d'ateli er doit permettre le stoc kage des données suivantes pour l'identifi cation de la carte: 
—  numéro de la carte, 
—  État membre qui a délivré la carte, autorité compét ente pour la délivrance, date de délivrance, 
—  date de début de validité de la carte, et date d'expiration. 
4.5.4.2.4  Identification du détenteur de la carte 
334)  La carte d'ateli er doit permettre le stoc kage des données suivantes pour l'identifi cation du détenteur 
de la carte: 
—  nom de l'ate lier, 
—  adresse de l'ate lier, 
—  nom du détent eur, 
—  prénom(s) du détenteur , 
—  langue habituelle. 
4.5.4.2.5  Téléc hargement (download) d'une carte 
335) La carte d'ateli er doit permettre le stoc kage des enregistrements de données relatives au téléc har­
gement d'une carte de la même manière qu'une carte de conduct eur. 
4.5.4.2.6  Données concer nant l'étalonnage et la remise à l'heure 
336)  La carte d'ate lier doit permettre le stoc kage des enregistrements de données relatives aux étalonnages 
et/ou aux remises à l'heure réalisés alors que la carte est insérée dans l'appareil. 
337)  Chaque enregistrement d'étalonnage doit pouvoi r cont enir les données suivantes: 
—  objet de l'étalonnag e (activation, première installation, installation, inspection périodique), 
—  identif ication du véhicule, 
—  paramètres mis à jour ou confir més [w, k, l, taille des pneumatiques, réglage du limiteur de 
vites se, comp teur kilométr ique (valeurs nouvelle et ancienne), date et heure (valeurs nouvelle et 
ancienne)], 
—  identif ication de l'appareil de contrôle (numéros des pièces de la VU, numéro de série de la VU, 
du capt eur de mouvement, du dispositif de communication à distance et du dispositif GNSS 
externe, le cas échéant), 
—  type et identif iant de tous les scellements en place, 
—  possibilit é pour la VU d'utiliser les cartes tach ygraphiques de première génération (activées ou 
non). 26.5.2016 L 139/66 Jour nal officiel de l'Union européenne FR     
338)  La carte d'ateli er doit permettre le stoc kage d'au moins 88 enregistrements de ce type. 
339)  La carte d'ateli er doit compo rter un comp teur indiquant le nombre total d'étalonnag es réalisés avec la 
carte. 
340)  La carte d'atelier doit compo rter un comp teur indiquant le nombre d'étalonnages réalisés depuis le 
dernier téléc hargement. 
4.5.4.2.7  Données relatives aux événements et aux anomalies 
341)  La carte d'atelier doit permettre le stoc kage des enregistrements de données relatives aux événements 
et aux anomalies de la même manière qu'une carte de conducteur . 
342)  La carte d'atelier doit permettre le stoc kage des trois derniers événements de chaque type (soit 33 
événements) et des six dernières anomalies de chaque type (soit 12 anomalies). 
4.5.4.2.8  Données relatives aux activités du conduct eur 
343)  La carte d'ate lier doit permettre le stoc kage de données concer nant l'activit é du conducteur de la 
même manière que la carte de conduct eur. 
344)  La carte d'ateli er doit permettre le stoc kage de données concer nant l'activité du conduct eur pendant 
au moins 1 jour d'activit é moyenne du conduct eur. 
4.5.4.2.9  Données concer nant les véhicules utilisés 
345)  La carte d'ate lier doit permettre le stoc kage des enregistrements de données relatives aux véhicules 
utilisés de la même manière que la carte de conducteur . 
346)  La carte d'ateli er doit permettre le stoc kage d'au moins 4 enregistrements de ce type. 
4.5.4.2.10  Données concer nant le début et/ou la fin des périodes de travail jour nalières 
347)  La carte d'atelier doit permettre le stoc kage des enregistrements de données relatives au début et/ou à 
la fin des périodes de travail jour nalières de la même manière qu'une carte de conduct eur. 
348)  La carte d'ateli er doit permettre le stoc kage d'au moins 3 paires d'enregistrements de ce type. 
4.5.4.2.11  Données concer nant les sessions pour chaque carte 
349)  La carte d'ateli er doit permettre le stoc kage des enregistrements de données relatives à une session de 
carte de la même manière qu'une carte de conduct eur. 
4.5.4.2.12  Données relatives aux activités de contrôle 
350)  La carte d'atelier doit permettre le stoc kage des enregistrements de données relatives aux activité s de 
contrôle de la même manière qu'une carte de conduct eur. 
4.5.4.2.13  Données concer nant les unités embarquées sur véhicule qui ont été utilisées 
351)  La carte d'atelier doit permettre le stoc kage des données suivantes relatives aux différ entes unités 
embarquées sur véhicule dans lesquelles la carte a été utilisée: 
—  la date et l'heure du début de la période d'utilisation du véhicule (c'est-à-dire de la première 
inser tion de la carte dans l'unité embarquée sur véhicule pour cette période), 
—  le fabricant de l'unit é embarquée sur véhicule, 26.5.2016 L 139/67 Jour nal officiel de l'Union européenne FR     
—  le type de VU, 
—  le numéro de version du logiciel de la VU. 
352)  La carte d'ateli er doit permettre le stoc kage d'au moins 4 enregistrements de ce type. 
4.5.4.2.14  Données relatives aux lieux où les trois heures de conduite continue ont été atteint es 
353)  La carte d'atelier doit permettre le stoc kage des données suivantes relatives à la position du véhicule 
lorsque le temps de conduite continue du conduct eur atteint un multiple de trois heures: 
—  la date et l'heure où le temps de conduite continue du détenteur de la carte atteint un multiple de 
trois heures, 
—  la position du véhicule, 
—  la précision GNSS, la date et l'heure de détermination de la position. 
354)  La carte d'ateli er doit permettre le stoc kage d'au moins 18 enregistrements de ce type. 
4.5.4.2.15  Données concer nant les conditions particulières 
355)  La carte d'ateli er doit permettre le stockag e des données relatives aux conditions particulières de la 
même manière qu'une carte de conducteur . 
356)  La carte d'ateli er doit permettre le stoc kage d'au moins 2 enregistrements de ce type. 
4.5.5  Carte de contrôleur 
4.5.5.1  Application tach ygraphique (accessible aux unité s embarquées de première et deuxième 
générations) 
4.5.5.1.1  Identification des applications 
357)  La carte de contrôleur doit permettre le stockag e des données suivantes pour l'identification des 
applications: 
—  identif ication de l'application tach ygraphique, 
—  identif ication du type de carte tach ygraphique. 
4.5.5.1.2  Clés et certificats 
358)  La carte de contrôleur doit être en mesure de stoc ker un certain nombre de certificats et de clés 
cryptographiques, comme spécifi é dans l'appendice 11, partie A. 
4.5.5.1.3  Identification de carte 
359)  La carte de contrôleur doit permettre le stoc kage des données suivantes pour l'identification de la 
carte: 
—  numéro de la carte, 
—  État membre qui a délivré la carte, autorité compét ente pour la délivrance, date de délivrance, 
—  date de début de validité de la carte, date d'expiration (le cas échéant). 
4.5.5.1.4  Identification du détenteur de la carte 
360)  La carte de contrôleur doit permettre le stoc kage des données suivantes pour l'identifi cation du 
détent eur de la carte: 
—  nom de l'organ isme de contrôle, 
—  adresse de l'organ isme de contrôle, 26.5.2016 L 139/68 Jour nal officiel de l'Union européenne FR     
—  nom du détent eur, 
—  prénom(s) du détenteur , 
—  langue habituelle. 
4.5.5.1.5  Données relatives aux activités de contrôle 
361)  La carte de contrôleur doit permettre le stoc kage des données suivantes relatives aux activités de 
contrôle: 
—  date et heure du contrôle, 
—le type de contrôle (affichag e et/ou tirage papier et/ou téléc hargement depuis la VU et/ou téléchar ­
gement depuis la carte et/ou contrôle d'étalonnag e sur route), 
—  période téléc harg ée (le cas échéant), 
—  numéro et autorité nationale d'immatr iculation du véhicule contrôlé, 
—  numéro de la carte de conduct eur contrôlée et État membre qui l'a délivrée. 
362)  La carte de contrôleur doit permettre le stoc kage d'au moins 230 enregistrements de ce type. 
4.5.5.2  Application tach ygraphique de deuxième génération (non accessible aux VU de première 
génération) 
4.5.5.2.1  Identification des applications 
363)  La carte de contrôleur doit permettre le stockag e des données suivantes pour l'identification des 
applications: 
—  identif ication de l'application tach ygraphique, 
—  identif ication du type de carte tach ygraphique. 
4.5.5.2.2  Clés et certificats 
364)  La carte de contrôleur doit être en mesure de stoc ker un certain nombre de certificats et de clés 
cryptographiques, comme spécifi é dans l'appendice 11, partie B. 
4.5.5.2.3  Identification de carte 
365)  La carte de contrôleur doit permettre le stoc kage des données suivantes pour l'identification de la 
carte: 
—  numéro de la carte, 
—  État membre qui a délivré la carte, autorité compét ente pour la délivrance, date de délivrance, 
—  date de début de validité de la carte, date d'expiration (le cas échéant). 
4.5.5.2.4  Identification du détenteur de la carte 
366)  La carte de contrôleur doit permettre le stoc kage des données suivantes pour l'identifi cation du 
détent eur de la carte: 
—  nom de l'organ isme de contrôle, 
—  adresse de l'organ isme de contrôle, 
—  nom du détent eur, 
—  prénom(s) du détenteur , 
—  langue habituelle. 26.5.2016 L 139/69 Jour nal officiel de l'Union européenne FR     
4.5.5.2.5  Données relatives aux activités de contrôle 
367)  La carte de contrôleur doit permettre le stoc kage des données suivantes relatives aux activités de 
contrôle: 
—  date et heure du contrôle, 
—  type du contrôle (affichag e et/ou impression et/ou téléc hargem ent à partir de la VU et/ou à partir 
de la carte et/ou contrôle de l'étalonnag e sur rout e), 
—  période téléc harg ée (le cas échéant), 
—  numéro et autorité nationale d'immatr iculation du véhicule contrôlé, 
—  numéro de la carte de conduct eur contrôlée et État membre qui l'a délivrée. 
368)  La carte de contrôleur doit permettre le stoc kage d'au moins 230 enregistrements de ce type. 
4.5.6  Carte d'entrep rise 
4.5.6.1  Application tach ygraphique (accessible aux unité s embarquées de première et deuxième 
générations) 
4.5.6.1.1  Identification des applications 
369)  La carte d'entrepr ise doit permettre le stoc kage des données suivantes pour l'identif ication des 
applications: 
—  identif ication de l'application tach ygraphique, 
—  identif ication du type de carte tach ygraphique. 
4.5.6.1.2  Clés et certificats 
370) La carte d'entrepr ise doit être en mesure de stocker un certain nombre de certificats et de clés crypto­
graphiques, comme spécifi é dans l'appendice 11, partie A. 
4.5.6.1.3  Identification de carte 
371)  La carte d'entrepr ise doit permettre le stoc kage des données suivantes pour l'identification de la carte: 
—  numéro de la carte, 
—  État membre qui a délivré la carte, autorité compét ente pour la délivrance, date de délivrance, 
—  date de début de validité de la carte, date d'expiration (le cas échéant). 
4.5.6.1.4  Identification du détenteur de la carte 
372)  La carte d'entrepr ise doit permettre le stoc kage des données suivantes pour l'identifi cation du 
détent eur de la carte: 
—  nom de l'entrepr ise, 
—  adresse de l'entrepr ise. 
4.5.6.1.5  Données concer nant l'activité de l'entrepr ise 
373)  La carte d'entrepr ise doit permettre le stoc kage des données suivante s concer nant les activités de 
l'entrepr ise: 
—  date et heure de l'activité, 
—  type de l'activité (verrouillage et/ou déver rouillage de la VU, téléc hargem ent à partir de la VU et/ 
ou de la carte), 
—  période téléc harg ée (le cas échéant), 26.5.2016 L 139/70 Jour nal officiel de l'Union européenne FR     
—  numéro et autorité nationale d'immatr iculation du véhicule, 
—  numéro de la carte et État membre qui l'a délivrée (en cas de téléc hargement à partir de la carte). 
374)  La carte d'entrepr ise doit permettre le stoc kage d'au moins 230 enregistrements de ce type. 
4.5.6.2  Application tach ygraphique de deuxième génération (non accessible aux VU de première 
génération) 
4.5.6.2.1  Identification des applications 
375)  La carte d'entrepr ise doit permettre le stoc kage des données suivantes pour l'identif ication des 
applications: 
—  identif ication de l'application tach ygraphique, 
—  identif ication du type de carte tach ygraphique. 
4.5.6.2.2  Clés et certificats 
376) La carte d'entrepr ise doit être en mesure de stocker un certain nombre de certificats et de clés crypto­
graphiques, comme spécifi é dans l'appendice 11, partie B. 
4.5.6.2.3  Identification de carte 
377)  La carte d'entrepr ise doit permettre le stoc kage des données suivantes pour l'identification de la carte: 
—  numéro de la carte, 
—  État membre qui a délivré la carte, autorité compét ente pour la délivrance, date de délivrance, 
—  date de début de validité de la carte, date d'expiration (le cas échéant). 
4.5.6.2.4  Identification du détenteur de la carte 
378)  La carte d'entrepr ise doit permettre le stoc kage des données suivantes pour l'identifi cation du 
détent eur de la carte: 
—  nom de l'entrepr ise, 
—  adresse de l'entrepr ise. 
4.5.6.2.5  Données concer nant l'activité de l'entrepr ise 
379)  La carte d'entrepr ise doit permettre le stoc kage des données suivante s concer nant les activités de 
l'entrepr ise: 
—  date et heure de l'activité, 
—  type de l'activité (verrouillage et/ou déver rouillage de la VU, téléc hargem ent à partir de la VU et/ 
ou de la carte), 
—  période téléc harg ée (le cas échéant), 
—  numéro et autorité nationale d'immatr iculation du véhicule, 
—  numéro de la carte et État membre qui l'a délivrée (en cas de téléc hargement à partir de la carte). 
380)  La carte d'entrepr ise doit permettre le stoc kage d'au moins 230 enregistrements de ce type. 26.5.2016 L 139/71 Jour nal officiel de l'Union européenne FR     
5.  INST ALL ATION DE L'APP AREIL DE CONTRÔLE 
5.1  Inst allation 
381)  L'appareil de contrôle neuf est livré non activé aux installate urs ou aux constr ucteur s de véhicules, 
avec tous les paramètres d'étalonnag e figurant sur la liste du chapitre 3, paragraphe 21, réglés aux 
valeurs par défaut appropr iées et à jour . Lorsqu'aucune valeur particulière ne convi ent, on aura 
recours à des séries de points d'interro gation pour les paramètres alphabétiques et au «0» pour les 
paramètres numér iques. La fourniture de pièces de l'appareil de contrôle en rappor t avec la sécur ité 
peut être restreinte au besoin au cours de la certificat ion de sécur ité. 
382)  Avant son activation, l'appareil de contrôle doit donner accès à la fonction d'étalonnage même s'il 
n'est pas en mode étalonnage. 
383)  Avant son activation, l'appareil de contrôle ne doit ni enregistrer ni stoc ker les données visées au 
chapit re 3, points 12.3, 12.9 et 12.12 à 12.15 inclus. 
384)  Au cours de l'installation, les constr ucteur s du véhicule doivent prérég ler tous les paramètres connus. 
385)  Les constr ucteur s de véhicules ou les installat eurs doivent activer l'appareil de contrôle installé au 
plus tard avant que le véhicule soit utilisé conf ormément au règlement (CE) no 561/2006. 
386)  L'activation de l'appareil de contrôle doit être déclenché e automatiquement par la première inser tion 
d'une carte d'ateli er en cours de validité dans une quelconque des interface s destinées aux cartes. 
387)  Les opérations particulières de couplage nécessaires entre le capt eur de mouvement et l'unité 
embarquée sur le véhicule, le cas échéant, inter viennent automatiquement avant ou pendant 
l'activation. 
388)  De même, les opérations particulières de couplage nécessaires entre le dispositif GNSS externe et 
l'unité embarquée sur le véhicule, le cas échéant, inter viennent automatique ment avant ou pendant 
l'activation. 
389)  Après l'activation, l'appareil de contrôle applique pleinement le contrôle d'accès aux fonctions et aux 
données. 
390)  Après son activation, l'appareil de contrôle communique au dispositif de communication à distance 
les données sécur isées nécessaires aux fins de contrôles routiers ciblés. 
391)  Les fonctions d'enregistrement et de stoc kage de l'appareil de contrôle doivent être pleinement 
opérationnelles après l'activation. 
392)  L'installation doit être suivie d'un étalonnage. Le premier étalonnage ne compor te pas nécessairement 
la saisie du numéro d'immatr iculation du véhicule (VRN) s'il n'est pas connu de l'atelier agréé qui doit 
procéder à cet étalonnage . Dans ces circonstances, il doit être possible pour le propr iétaire du 
véhicule, uniquement à ce moment, de saisir le VRN à l'aide de sa carte d'entrepr ise avant l'utilisation 
du véhicule conf ormément au règlement (CE) no 561/2006 (par exem ple à l'aide de commandes via 
une structure de menu appropr iée de l'interface homme-machine de l'unit é embarquée) (1). Seule 
l'utilisation d'une carte d'ate lier doit permettre la mise à jour ou la conf irmation de cette saisie. 
393)  L'installation d'un dispositif GNSS exte rne nécessite son couplage avec la VU et la vérification 
ultérieure des informations de position GNSS. 
394)  L'appareil de contrôle doit être positionné dans le véhicule de telle manière que le conduct eur ait 
accès aux fonctions nécessaires depuis son siège . 26.5.2016 L 139/72 Jour nal officiel de l'Union européenne FR     
(1)JO L 102 du 11.4.2006, p. 1. 
5.2  Plaquette d'inst allation 
395)  Après la vérification de l'appareil de contrôle une fois installé, une plaquette d'installation, gravé e ou 
impr imée de façon permanent e, bien visible et facilement accessible, doit être fixée sur l'appareil de 
contrôle. Dans les cas où cela n'est pas possible, la plaquette est apposée sur le pied milieu du 
véhicule, de manière à être clairement visible. Si le véhicule n'a pas de pied milieu, la plaquette 
d'installation doit être apposée sur l'encadrement de la portière du côté conduct eur, et être bien 
visible dans tous les cas. 
Après chaque inspection par un atelier ou un installat eur agréé, une nouvelle plaquette est fixée à la 
place de la précédente. 
396)  La plaquette doit compo rter au moins les indications suivantes: 
—  le nom, l'adresse ou la raison sociale de l'installat eur ou de l'atelier agréé, 
—  le coefficient caract éristique du véhicule, sous la forme «w = … imp/km», 
—  la constant e de l'appareil de contrôle, sous la forme «k = … imp/km», 
—  les circonférences effectives des pneumatiques, sous la forme «l = … mm», 
—  la taille des pneumatiques, 
—  la date à laquelle le coeff icient caracté ristique du véhicule et la circonf érence effective des 
pneumatiques ont été mesurés, 
—  le numéro d'identif ication du véhicule, 
—  la présence (ou non) d'un dispositif GNSS externe, 
—  le numéro de série du dispositif GNSS externe, 
—  le numéro de série de l'appareil de communication à distance, 
—  le numéro de série de tous les scellements en place, 
—  la partie du véhicule où l'adaptat eur, le cas éché ant, est installé, 
—  la partie du véhicule où le capt eur de mouvement est installé, s'il n'est pas connecté à la boîte de 
vites ses ou si un adap tateur n'est pas utilisé, 
—  une descr iption de la couleur du câble entre l'adaptat eur et la partie du véhicule qui fournit ses 
impulsions entrantes, 
—  le numéro de série du capt eur de mouvement intégré de l'adaptat eur. 
397)  Pour les véhicules des catégo ries M1 et N1 uniquement, équipés d'un adaptat eur conf ormément au 
règlement (CE) no 68/2009 de la Commission (1), tel que modifié en dernier lieu, et pour lesquels il 
n'est pas possible d'inclure tout es les informations nécessaires en vertu de l'exigence 396, une plaque 
supplémentaire peut être utilisée. Dans ce cas, celle-ci compor te au moins les informations figurant 
aux quatre derniers tirets de l'exigence 396. 
Si cette plaquette supplémentaire est utilisée, elle doit être apposée à côté ou en dessous de la 
plaquette principale décr ite à l'exige nce 396, et doit bénéficier du même niveau de protect ion. En 
outre, la plaquette supplémentaire doit aussi compo rter le nom, l'adresse ou la raison sociale de 
l'installateur ou de l'atelier agréé qui a procédé à l'installation, ainsi que la date d'installation. 26.5.2016 L 139/73 Jour nal officiel de l'Union européenne FR     
(1)Règlement (CE) no 68/2009 de la Commission du 23 janvier 2009 portant neuvième adap tation au progrès technique du règlement (CEE) 
no 3821/85 du Conseil concer nant l'appareil de contrôle dans le domaine des transpor ts par route (JO L 21 du 24.1.2009, p. 3). 
5.3  Scellement 
398)  Les éléments suivants doivent être scellés: 
—  tout e connexion qui, si elle était interr ompue, entraînerait des modifi cations indécelables ou des 
pertes de données indécelables (cela peut par exem ple s'appliquer au montag e du capt eur de 
mouvement sur la boîte de vitesses, à l'adaptat eur pour les véhicules des catégor ies M1/N1, à la 
connexion GNSS extern e ou à la VU); 
—  la plaquette d'installation, sauf si elle est fixée de telle manière qu'elle ne puisse être enlevée sans 
détr uire les indications qu'elle porte. 
399)  Les scellements précités peuvent être retirés: 
—  en cas d'urgence, 
—  afin d'installer , d'ajuster ou de réparer un limite ur de vitesse ou tout autre dispositif contr ibuant à 
la sécur ité routière, pour autant que l'appareil de contrôle continue à fonctionner de manière 
fiable et correcte, et qu'il soit scellé à nouveau par un installat eur ou un ateli er agréé 
(conf ormément au chapitre 6) immédiatement après l'installation du limiteur de vitesse ou de tout 
autre dispositif contr ibuant à la sécur ité routière, ou dans les sept jours pour les autres cas. 
400)  À chaque bris de ces scellements, une déclaration écrite indiquant les raisons de cette action est 
rédigée et transmise à l'aut orité compét ente. 
401)  Les scellements doivent porter un numéro d'identification, alloué par leur fabricant. Ce numéro doit 
être unique et distinct de tout autre numéro de scellement attribué par un fabricant de scellements. 
Ce numéro d'identif ication unique est défini comme suit: MM NNNNNN, faisant l'objet d'un 
marquage indélébile, où MM est l'identifiant unique du fabricant (enregistrement dans une base de 
données qui sera gérée par la CE) et NNNNNN est le numéro alphanumér ique du scellement, unique 
dans le domaine du fabricant. 
402)  Les scellements doivent présenter un espace libre où les installat eurs, ateliers ou constr ucteur s de 
véhicules agréés peuvent ajouter une marque particulière conf ormément à l'article 22, paragraphe 3 
du règlement (UE) no 165/2014. 
Cette marque ne doit pas couvr ir le numéro d'identif ication du scellement. 
403)  Les fabricants de scellements doivent être enregistrés dans une base de données dédiée et rendre 
publics leurs numéros d'identif ication de scellements par une procédure établie par la Commission 
européenne. 
404)  Les ateliers et constr ucteurs de véhicules agréés doivent, dans le cadre du règlement (UE) 
no 165/2014, n'utiliser que des scellements issus des fabricants de scellements réper torié s dans la 
base de données mentionnée ci-dessus. 
405)  Les fabricants de scellements et leurs distr ibut eurs doivent conser ver des dossiers de traçabilit é 
complèt e des scellements vendus pour une utilisation dans le cadre du règlement (UE) no 165/2014 
et doivent être prêts à les communiquer aux autorités nationales compét entes à chaque fois que c'est 
nécessaire. 
406) Les numéros d'identification uniques des scellements doivent être visibles sur la plaquette d'instal ­
lation. 
6.  CON TRÔLES, INSPECTIONS ET RÉPARA TIONS 
Les prescr iptions concer nant les circonstances dans lesquelles les scellements peuvent être retirés, comme 
indiqué à l'article 22, paragraphe 5, du règlement (UE) no 165/2014, sont définies au chapitre 5, point 3, de 
la présent e annex e. 
6.1  Agrément des inst allateurs, des ateliers et des constr ucteurs de véhicules 
Les États membres agréent, contrôlent régulièrement et certifient les organismes chargés des tâches 
suivantes: 
—  installations, 
—  contrôles, 26.5.2016 L 139/74 Jour nal officiel de l'Union européenne FR     
—  inspections, 
—  réparations. 
Les cartes d'ateli er ne doivent être délivrées qu'aux installat eurs et/ou aux ateli ers agréés pour l'activation et/ 
ou l'étalonnage d'appareils de contrôle, conf ormément à la présente annexe et, sauf cas dûment motivé: 
—  qui ne sont pas éligibles pour une carte d'entrepr ise; 
—  dont les autres activité s professionnelles ne sont pas de nature à comprome ttre la sécur ité globale du 
système telle que requis dans l'appendice 10. 
6.2  Vér ification d'instr uments neufs ou réparés 
407)  Chaque dispositif, neuf ou réparé, doit être vérifié pour s'assurer de son fonctionnement correct et de 
la précision de ses relevés et de ses enregistrements, dans les limites fixées au chapitre 3, points 2.1, 
2.2, 2.3 et 3 par le scellement prévu au chapitre 5, point 3, et à l'étalonnage . 
6.3  Inspection de l'inst allation 
408)  Lors de son montag e sur un véhicule, l'ensemble de l'installation (y compris l'appareil de contrôle) 
doit respecter les dispositions en matière de tolérances maximales fixées au chapitre 3, points 2.1, 
2.2, 2.3 et 3. 
6.4  Inspections périodiques 
409)  Des inspections périodiques des appareils mont és sur les véhicules ont lieu après tout e réparation, ou 
après tout e modification du coeffi cient caractér istique du véhicule ou de la circonf érence effective des 
pneumatiques, ou lorsque l'horloge UTC est fausse de plus de 20 minutes , ou lorsque le numéro 
d'immatr iculation a changé, et au moins une fois tous les deux ans (24 mois). 
410)  Ces inspections compre nnent les vérifications suivantes: 
—  fonctionnement correct de l'appareil de contrôle, y compr is la fonction de stockag e de données 
sur les cartes tach ygraphiques et la communication à l'aide de lecteur s de communication à 
distance, 
—  conf ormité aux dispositions du chapitre 3, points 2.1 et 2.2 concer nant les tolérances maximales 
à l'installation, 
—  conf ormité aux dispositions du chapitre 3, points 2.3 et 3, 
—  présence de la marque d'homologation sur l'appareil de contrôle, 
—  présence de la plaquette d'installation définie par l'exigence 396 et de la plaque signalétique 
définie par l'exigence 225 
—  taille des pneumatiques et circonférence effective des pneumatiques, 
—  absence de dispositifs de manipulation attachés à l'appareil, 
—  placement correct et bon état des scellements, validité de leurs numéros d'identification (le 
fabricant de scellements est référencé dans la base de données de la CE) et correspondance entre 
leurs numéros d'identif ication et les marquag es des plaquettes d'installation (voir exigence 401). 
411)  S'il est constaté qu'un des événements figurant au chapitre 3, point 9 (Dét ection des événements et/ 
ou des anomalies) est survenu depuis la dernière inspection, et que les fabricants de tach ygraphes et/ 
ou les autori tés nationales considèrent que cet événement fait peser un risque poten tiel sur la sécur ité 
de l'équipement, l'atelier : 
a.  effectue une compar aison entre les données d'identif ication du capt eur de mouvement connecté à 
la boît e de vitess e avec celles du capt eur de mouvement couplé enregistrées dans l'unit é 
embarquée; 26.5.2016 L 139/75 Jour nal officiel de l'Union européenne FR     
b.  vérifie si les informations inscr ites sur la plaquette d'installation correspondent à celles enregistrées 
dans l'unité embarquée; 
c.  vérifie si le numéro de série et le numéro d'homologation du capt eur de mouvement, s'ils sont 
imprimés sur le corps du capt eur de mouvement, correspondent aux informations enregistrées 
dans la mémoire de l'appareil de contrôle; 
d.  compar e les données d'identification inscr ites sur la plaque signalétique du dispositif GNSS 
exte rne, le cas échéant, à celles stoc kées dans la mémoire de la VU. 
412)  Les ateli ers consignent, dans leurs rappor ts d'inspection, tout e constatation concer nant un bris de 
scellement ou un dispositif de manipulation. Ils conser vent ces rappor ts pendant au moins 2 ans et 
les mett ent à la disposition de l'aut orité compét ente sur tout e demande. 
413)  Ces inspections comprennent un étalonnage et un rem placement préventif des scellements dont 
l'installation s'effectue sous la responsabilité d'ateliers. 
6.5  Déter mination des erreurs 
414)  La détermination des erreurs à l'installation et en service doit être effectuée dans les conditions 
suivantes, qui sont à considérer comme les conditions d'essai standard: 
—  véhicule à vide en ordre de marc he, 
—  pression des pneumatiques conf orme aux instr uctions du fabricant, 
—  usure des pneumatiques dans les limites autor isées en droit national, 
—  mouvement du véhicule: 
—  le véhicule doit avancer , sous l'action de son propre mote ur, en ligne droite sur sol plat à une 
vites se de 50 ± 5 km/h. La distance mesurée doit être d'au moins 1 000 m, 
—  pour autant qu'elles soient d'une précision compara ble, d'autres méthodes, comme par exem ple 
l'utilisation d'un banc appropr ié, peuvent également être mises en œuvre pour l'essai. 
6.6  Réparations 
415)  Les ateli ers doivent pouvoi r téléc harger des données à partir de l'appareil de contrôle afin de les 
restituer à l'entrepr ise de transpor t appropr iée. 
416)  Les ateliers agréés délivrent aux entrepr ises de transpor t un certificat attestant que les données ne 
peuvent être téléc hargées lorsqu'un dysf onctionnement de l'appareil de contrôle empê che de 
téléc harger les données stockées, même après réparation à l'atelier même. Les ateli ers conser vent une 
copie de chaque certificat délivré, pendant au moins deux ans. 
7.  DÉLIVRANCE DES CARTES 
Les processus mis en place par les États membres pour la délivrance des cartes sont conf ormes aux 
prescr iptions suivantes: 
417)  Le numéro de carte pour la première délivrance d'une carte tach ygraphique doit compor ter un indice 
séquentiel (au besoin), un indice de rem placement et un indice de renouvellement fixé à «0». 
418)  Les numéros de carte de tout es les cartes tach ygraphiques non nominatives délivrées au même 
orga nisme de contrôle ou au même atelier ou à la même entrepr ise de transpor t doivent compo rter 
13 chiffres identiques suivis d'un indice séquentiel. 
419)  Une carte tach ygraphique délivrée en rem placement d'une carte tach ygraphique existante doit avoir le 
même numéro que celle qu'elle rem place, sauf l'indice de rem placement, qui doit être augmenté d'une 
unité (dans une série 0 à 9, A à Z). 26.5.2016 L 139/76 Jour nal officiel de l'Union européenne FR     
420)  Une carte tach ygraphique délivrée en rem placement d'une carte tach ygraphique existant e doit avoir la 
même date d'expiration que cette dernière. 
421)  Une carte tach ygraphique délivrée en renouvellement d'une carte existante doit porter le même 
numéro que cette dernière, sauf pour l'indice de rem placement, qui doit être remis à «0», et pour 
l'indice de renouvellement, qui doit être augmenté d'une unité (dans une série de 0 à 9, A à Z). 
422) L'échang e d'une carte tach ygraphique existant e, aux fins de la modifi cation de données adminis ­
tratives, doit suivre les règles applicables au renouvellement s'il est effectué à l'intér ieur d'un même 
État membre, ou les règles applicables à une première délivrance s'il est effectué dans un autre État 
membre. 
423)  Dans le cas d'une carte d'ateli er ou de contrôleur non nominative, la rubrique «nom du détent eur de 
la carte» doit être compl étée par le nom de l'atelier , de l'organ isme de contrôle, de l'installat eur ou de 
l'agent de contrôle selon ce que décident les États membres. 
424)  Les États membres écha ngent des données par voie électronique afin d'assurer l'unicité des cartes de 
conducteur qu'ils délivrent conf ormément à l'article 31 du règlement (UE) no 165/2014. 
8.  HOMOL OGA TION DE L'APP AREIL DE CONTRÔLE ET DES CARTES TACHY GRAPHIQUES 
8.1  Points généraux 
Aux fins du présent chapitre, on entend par «appareil de contrôle», l'appareil de contrôle ou ses compo sants. 
Aucune homologation n'est exigé e pour le(s) câble(s) reliant le capt eur de mouvement à la VU, le dispositif 
GNSS externe à la VU ou le dispositif de communication à distance à la VU. Le papier utilisé pour l'appareil 
de contrôle est considéré comme un compo sant de l'appareil. 
Tout fabricant peut demander l'homolog ation de ses compo sants avec tout type de capt eur de mouvement, 
de dispositif GNSS extern e et vice versa, à condition que chaque composant soit conf orme aux exigenc es 
conte nues dans la présente annexe. Les fabricants peuvent également demander l'homolog ation de l'appareil 
de contrôle. 
425)  L'appareil de contrôle doit être présent é pour homolog ation avec tous ses composants ainsi que tout 
dispositif additionnel éventuellement intégré. 
426)  L'homologat ion d'un appareil de contrôle et de cartes tach ygraphiques compo rte des essais liés à la 
sécur ité, des essais fonctionnels et des essais d'interopérabilit é. Les résultats positifs à chacun de ces 
essais sont attestés par un certificat appropr ié. 
427)  Les autor ités d'homologation des États membres n'accorderont pas de certificat d'homologation tant 
qu'elles ne sont pas en possession: 
—  d'un certificat de sécur ité, 
—  d'un certificat de fonctionnement 
—  et d'un certificat d'inter opérabilit é 
pour l'appareil de contrôle ou la carte tach ygraphique faisant l'objet de la demande d'homologation. 
428)  Toute modifi cation du logiciel ou du maté riel, ou des mat ériaux utilisés dans la fabrication doit être 
notifi ée au préalable à l'autori té qui a accordé l'homolog ation de l'appareil. Cette autori té doit 
conf irmer au fabricant l'exte nsion de l'homologation, ou bien elle peut demander une mise à jour ou 
une conf irmation des certificats de fonctionnement, de sécur ité et/ou d'inter opérabilité. 
429)  Les procédures pour la mise à niveau in situ du logiciel de l'appareil de contrôle doivent être 
approuvées par l'autori té qui a accordé l'homolog ation pour l'appareil de contrôle concer né. La mise 
à niveau logicielle ne doit ni modifi er ni suppr imer aucune donnée relative à l'activité du conducteur 
stoc kée dans l'appareil de contrôle. Le logiciel ne peut être mis à niveau que sous la responsabilit é du 
fabricant de l'appareil de contrôle. 26.5.2016 L 139/77 Jour nal officiel de l'Union européenne FR     
430) L'homologat ion des modifications de logiciels visant à mettre à niveau un appareil de contrôle préala ­
blement homologué ne peut être refusée si ces modifications ne s'appliquent qu'à des fonctions non 
spécifi ées dans la présente annexe. La mise à jour logicielle d'un appareil de contrôle peut exclure 
l'introduction de nouveaux jeux de caractères si ce n'est pas techniquement faisable. 
8.2  Cer tificat de sécur ité 
431)  Le certificat de sécur ité est délivré conf ormément aux dispositions de l'appendice 10 de la présent e 
annexe. Les compo sants de l'appareil de contrôle qui doivent être certifiés sont: la VU, le capt eur de 
mouvement, le dispositif GNSS exte rne et les cartes tach ygraphiques. 
432)  Dans la circonstance excep tionnelle et spécifi que où les autori tés de certification de sécur ité refusent 
de certifier un nouvel appareil en invoquant l'obsolescence des mécanismes de sécur ité, l'homolo ­
gation continue à être accordée uniquement lorsqu'il n'existe aucune autre solution conf orme au 
règlement. 
433)  Dans cette circonstance, l'État membre concer né informe sans retard la Commission européenne qui, 
dans les douze mois civils qui suivent l'octroi de l'homolog ation, lance une procédure pour s'assurer 
que le niveau de sécur ité a été ramené à son niveau d'or igine. 
8.3  Cer tificat de fonctionnement 
434)  Chaque candidat à l'homolog ation doit fournir à l'autori té d'homologation de l'État membre tout le 
matér iel et la documentation que cette autorité juge nécessaires. 
435)  Les fabricants fournissent les échantillons pertinents de produits en attent e d'une homolog ation et la 
documentation associée requis par les laborat oires désignés pour effectuer les essais fonctionnels, et 
ce, dans le mois qui suit la demande. L'entit é qui fait la demande suppor te les coûts qui en résult ent. 
Les laborat oires traitent tout es les informations sensibles sur le plan commercial en respectant la 
conf identialit é. 
436)  Un certificat de fonctionnement est délivré par le fabricant uniquement après que l'appareil a obtenu 
des résultats positifs à tous les essais fonctionnels spécifiés à l'appendice 9. 
437)  L'autori té d'homologat ion délivre le certificat de fonctionnement. Ce certificat compo rte, outre le 
nom de son bénéficiaire et le nom du modèle, une liste détaillée des essais réalisés et des résultats 
obtenu s. 
438)  Le certificat de fonctionnement de tout compo sant d'appareil de contrôle mentionne aussi les 
numéros d'homolog ation des autres compo sants d'appareil de contrôle compatib les homologués qui 
sont testés en vue d'obtenir cette certification. 
439)  Le certificat de fonctionnement d'un compo sant de l'appareil de contrôle doit également indiquer la 
norme ISO ou CEN en vertu de laquelle l'interface fonctionnelle a été certifiée. 
8.4  Cer tificat d'interopérabilité 
440) Les essais d'interopérabilit é sont réalisés par un seul et même laboratoire sous l'aut orité et la responsa ­
bilité de la Commission européenne. 
441)  Le laborat oire enregistre les demandes d'essais d'inte ropérabilité introduites par les fabricants dans 
l'ordre chronologique de leur arrivée. 26.5.2016 L 139/78 Jour nal officiel de l'Union européenne FR     
442)  Les demandes ne sont officiellement enregistrées que lorsque le laboratoire est en possession: 
—  de l'ensemble du matér iel et des documents nécessaires pour les essais d'inter opérabilité, 
—  du certificat de sécur ité correspondant, 
—  du certificat de fonctionnement correspondant. 
La date de l'enregistrement de la demande est notifiée au fabr icant. 
443)  Aucun essai d'inter opérabilité n'est réalisé par le laboratoire sur un appareil de contrôle ou une carte 
tach ygraphique qui n'a pas reçu de certificat de sécur ité et de certificat de fonctionnement, sauf dans 
les circonstances excep tionnelles décr ites sous l'exig ence 432. 
444)  Tout fabricant demandant des essais d'inter opérabilité s'engag e à laisser au laborat oire chargé des 
essais l'ensemble du mat ériel et de la documentation fournis aux fins des essais. 
445)  Les essais d'inte ropérabilité sont effectués, conf ormément à l'appendice 9 de la présent e annex e, sur 
tous les types d'appareil de contrôle ou de cartes tach ygraphiques: 
—  dont l'homolog ation est en cours de validité, ou 
—  dont l'homolog ation est en instance et pour lesquels existe un certificat d'interopérabilit é en cours 
de validité. 
446)  Les tests d'interopérabilit é doivent couvr ir tout es les générations d'appareils de contrôle ou de cartes 
tach ygraphiques encore en usag e. 
447)  Le certificat d'interopérabilit é doit être délivré au fabricant par le laborat oire uniquement après que 
des résultats positifs ont été obtenu s pour tous les essais d'interopérabilit é. 
448)  En cas de résultat négatif des essais d'interopérabilit é sur un ou plusieurs appareils de contrôle ou 
cartes tach ygraphiques, le certificat d'interopérabilit é n'est pas délivré tant que le fabr icant concer né 
n'a pas appor té les modifications nécessaires et que l'appareil ou la carte n'a pas satisf ait à tous les 
essais d'interopérabilit é. Le laborat oire détermine l'origine du problème avec l'aide du fabricant 
concer né, et s'efforce d'assister ce fabr icant dans la recherche d'une solution technique. Dans les cas 
où le fabricant a modifié son produit, il lui incombe de s'assurer auprès des autor ités compét entes de 
la validité du certificat de sécur ité et du certificat de fonctionnement. 
449)  Le certificat d'interopérabilit é est valable six mois. Il expire à la fin de cette période si le fabricant n'a 
pas reçu un certificat d'homolog ation correspondant. Il est transmis par le fabricant à l'aut orité 
d'homologation de l'État membre qui a délivré le certificat de fonctionnement. 
450)  Tout élément susceptible d'être à l'origine d'une anomalie d'inte ropérabilité ne doit pas être utilisé 
pour réaliser des bénéfices ni pour accéder à une position dominante. 
8.5  Cer tificat d'homologation 
451)  L'autori té d'homologation de l'État membre peut délivrer le certificat d'homologat ion dès qu'elle est 
en possession des trois certificats requis. 
452)  Le certificat d'homolog ation de tout composant d'appareil de contrôle mentionne aussi les numéros 
d'homologation des autres compo sants d'appareil de contrôle interopérables homologués. 
453)  Une copie du certificat d'homologat ion doit être transmise par l'autori té d'homologation au 
laboratoire chargé des essais d'inte ropérabilité lors de la délivrance de ce certificat au fabricant. 26.5.2016 L 139/79 Jour nal officiel de l'Union européenne FR     
454)  Le laboratoire compét ent pour les essais d'interopérabilit é doit mettre à jour , sur un site Internet 
public qu'il gère, la liste des modèles d'appareil de contrôle ou de cartes tach ygraphiques: 
—  pour lesquels une demande d'essais d'interopérabilit é a été enregistrée, 
—  qui ont reçu un certificat d'interopérabilit é (même provisoire), 
—  qui ont reçu un certificat d'homologation. 
8.6  Procédure exceptionnelle: les premiers certificats d'interopérabilité pour des unités de contrôle et 
des cartes tachyg raphiques de deuxième génération 
455)  Pendant une période de quatre mois après qu'un premier couple appareil de contrôle de deuxième 
génération/car tes tach ygraphiques de deuxième génération (cartes de conducteur , d'atelier , de 
contrôleur et d'entrepr ise) a été certifié interopérable, tous les certificats d'interopérabilit é délivrés (y 
compris les premiers) en relation avec des demandes reçues pendant cette période seront considérés 
comme provisoires. 
456) À l'issue de cette période, si tous les produits concer nés sont interopérables, tous les certificat s d'inte ­
ropérabilité deviennent définitifs. 
457)  Si des anomalies d'interopérabilit é apparaissent au cours de cette période, le laboratoire charg é des 
essais d'inter opérabilité déter mine la cause des problèmes obser vés, avec l'aide de tous les fabricants 
concer nés, et les invit e à appor ter les modifications nécessaires. 
458)  Si, à la fin de cette période, des problèmes d'interopérabilit é demeurent, le laborat oire chargé des 
essais d'interopérabilit é détermine, en collaboration avec les fabricants concer nés et avec les autor ités 
d'homologation qui ont délivré les certificats de fonctionnement correspondants, les causes des 
anomalies d'inter opérabilité, et définissent les modifi cations que chaque fabricant concer né doit 
appor ter. La recherc he de solutions techniques peut se prolonger pendant un maximum de deux 
mois, après quoi la Commission, en l'absence de solution commune, et après consultation du 
laboratoire chargé des essais d'interopérabilit é, décide du ou des appareils et des cartes auxquels est 
délivré un certificat d'interopérabilit é définitif, en précisant les raisons de son choix. 
459)  Toute demande d'essais d'interopérabilit é enregistrée par le laboratoire entre la fin de la période de 
quatre mois suivant la délivrance du premier certificat d'inte ropérabilité provisoire et la date de la 
décision de la Commission visée à l'exig ence 455 est repoussée jusqu'à la résolution des problèmes 
d'interopérabilit é initiaux. Ces demandes sont ensuite traitées dans l'ordre de leur enregistrement.  26.5.2016 L 139/80 Jour nal officiel de l'Union européenne FR     
Appendice 1 
DICTIONNAIRE DE DONNÉES 
TABLE DES MATIÈRES 
1. INTR ODUCTION .............................................................................................................................. 88 
1.1. Méthode d'établissement des définitions de type de données .......................................................... 88 
1.2. Références .......................................................................................................................... 88 
2. DÉFINITIONS DES TYPES DE DONNÉES ................................................................................................ 89 
2.1. ActivityChang eInfo............................................................................................................... 89 
2.2. Address .............................................................................................................................. 90 
2.3. AESKe y.............................................................................................................................. 91 
2.4. AES128Key ......................................................................................................................... 91 
2.5. AES192Key ......................................................................................................................... 91 
2.6. AES256Key ......................................................................................................................... 92 
2.7. BCDStr ing .......................................................................................................................... 92 
2.8. CalibrationPur pose ............................................................................................................... 92 
2.9. CardA ctivityDailyRecord ........................................................................................................ 93 
2.10. CardA ctivityLengthRa nge ....................................................................................................... 93 
2.11. CardAppro valNumber ........................................................................................................... 93 
2.12. CardCer tificate..................................................................................................................... 94 
2.13. CardChipIdentification ........................................................................................................... 94 
2.14. CardConsecutiveIndex ........................................................................................................... 94 
2.15. CardControlA ctivityDataRecord ............................................................................................... 94 
2.16. CardCur rentUse ................................................................................................................... 95 
2.17. CardDr iverA ctivity ................................................................................................................ 95 
2.18. CardDr ivingLicenceInf ormation ............................................................................................... 95 
2.19. CardEventData ..................................................................................................................... 96 
2.20. CardEventRecord .................................................................................................................. 96 
2.21. CardF aultData ...................................................................................................................... 96 
2.22. CardF aultRecord .................................................................................................................. 97 
2.23. CardIccIdentification ............................................................................................................. 97 
2.24. CardIdentification ................................................................................................................. 97 
2.25. CardMA Certificate................................................................................................................ 98 
2.26. CardNumber ....................................................................................................................... 98 
2.27. CardPlaceDailyW orkPer iod ..................................................................................................... 99 
2.28. CardPublicKe y..................................................................................................................... 99 26.5.2016 L 139/81 Jour nal officiel de l'Union européenne FR     
2.29. CardPublicKe y..................................................................................................................... 99 
2.30. CardRenewalIndex ................................................................................................................ 99 
2.31. CardReplacementIndex .......................................................................................................... 99 
2.32. CardSignCer tificate............................................................................................................... 100 
2.33. CardSlotNumber .................................................................................................................. 100 
2.34. CardSlotsStatus .................................................................................................................... 100 
2.35. CardSlotsStatusRecordAr ray.................................................................................................... 100 
2.36. CardStr uctureV ersion ............................................................................................................ 101 
2.37. CardV ehicleRecord ................................................................................................................ 101 
2.38. CardV ehiclesUsed ................................................................................................................. 102 
2.39. CardV ehicleU nitRecord .......................................................................................................... 102 
2.40. CardV ehicleU nitsUsed ............................................................................................................ 102 
2.41. Certificat ............................................................................................................................ 103 
2.42. CertificateCont ent ................................................................................................................ 103 
2.43. CertificateRequestID Identification individuelle d'une demande de certificat ....................................... 104 
2.44. CertificateRequestID .............................................................................................................. 104 
2.45. CertificationAuthor ityKID ...................................................................................................... 104 
2.46. Com panyA ctivityData ........................................................................................................... 105 
2.47. Com panyA ctivityT ype ........................................................................................................... 106 
2.48. Com panyCard ApplicationIdentif ication ..................................................................................... 106 
2.49. Com panyCard HolderIdentif ication ........................................................................................... 106 
2.50. ControlCardApplicationIdentification ........................................................................................ 106 
2.51. ControlCardControlA ctivityData .............................................................................................. 107 
2.52. ControlCardHolderIdentification .............................................................................................. 107 
2.53. ControlT ype ........................................................................................................................ 108 
2.54. DailyPresenceCount er............................................................................................................ 109 
2.55. CurrentDateTimeRecordArr ay................................................................................................. 109 
2.56. DailyPresenceCount er............................................................................................................ 109 
2.57. Datef................................................................................................................................. 109 
2.58. DateOfDa yDo wnloaded ......................................................................................................... 110 
2.59. DateOfDa yDo wnloadedRecordAr ray......................................................................................... 110 
2.60. Distance ............................................................................................................................. 110 
2.61. DriverCardApplicationIdentifi cation ......................................................................................... 110 
2.62. DriverCardHolderIdentifi cation ................................................................................................ 111 
2.63. DSR CSecur ityData ................................................................................................................ 112 
2.64. EGFCer tificate...................................................................................................................... 112 
2.65. EmbedderIcAssemblerId ......................................................................................................... 112 26.5.2016 L 139/82 Jour nal officiel de l'Union européenne FR     
2.66. Entr yTypeDailyW orkPer iod ..................................................................................................... 113 
2.67. EquipmentT ype .................................................................................................................... 113 
2.68. EventF aultT ype .................................................................................................................... 114 
2.69. EventF aultRecordPur pose ....................................................................................................... 114 
2.70. EventF aultT ype .................................................................................................................... 114 
2.71. Exten dedSealIdentifi er........................................................................................................... 115 
2.72. Exten dedSer ialNumber .......................................................................................................... 116 
2.73. FullCardNumber .................................................................................................................. 116 
2.74. FullCardNumberAndGeneration ............................................................................................... 117 
2.75. Generation .......................................................................................................................... 117 
2.76. GeoCoordinates ................................................................................................................... 117 
2.77. GNSS Accuracy ..................................................................................................................... 118 
2.78. GNSSContinuousDr iving ........................................................................................................ 118 
2.79. GNSSContinuousDr ivingRecord ............................................................................................... 118 
2.80. GNSSPlaceRecord ................................................................................................................. 118 
2.81. HighResOdomete r................................................................................................................ 119 
2.82. HighResT ripDistance ............................................................................................................. 119 
2.83. HolderName ....................................................................................................................... 119 
2.84. InternalGNSSReceiver ............................................................................................................ 119 
2.85. K-ConstantOfRecordingEquipment ........................................................................................... 119 
2.86. KeyIdentifier ....................................................................................................................... 120 
2.87. KMW CKey.......................................................................................................................... 120 
2.88. Languag e............................................................................................................................ 120 
2.89. LastCardDo wnload ............................................................................................................... 120 
2.90. LinkCer tificate ..................................................................................................................... 120 
2.91. L-TyreCircumf erence ............................................................................................................. 121 
2.92. MAC................................................................................................................................. 121 
2.93. ManualIn putFlag .................................................................................................................. 121 
2.94. Manufa cturerCode ................................................................................................................ 121 
2.95. Manufa cturerSpecifi cEventF aultData ......................................................................................... 121 
2.96. MemberStat ePublicKey .......................................................................................................... 122 
2.97. MemberStat eCer tificateRecordAr ray.......................................................................................... 122 
2.98. MemberStat ePublicKey .......................................................................................................... 122 
2.99. Name ................................................................................................................................ 122 
2.100. NationAlpha ....................................................................................................................... 123 
2.101. Code numér ique national ....................................................................................................... 123 
2.102. NoOfCalibrationsSinceDo wnload ............................................................................................. 123 26.5.2016 L 139/83 Jour nal officiel de l'Union européenne FR     
2.103. NoOfCalibrationsSinceDo wnload ............................................................................................. 123 
2.104. NoOfCardPlaceRecords .......................................................................................................... 123 
2.105. NoOfCardV ehicleRecords ....................................................................................................... 124 
2.106. NoOfCardV ehicleU nitRecords .................................................................................................. 124 
2.107. NoOfControlA ctivityRecords .................................................................................................. 124 
2.108. NoOfEventsPe rType .............................................................................................................. 124 
2.109. NoOfEventsPe rType .............................................................................................................. 124 
2.110. NoOfF aultsPerT ype ............................................................................................................... 124 
2.111. NoOfGNSSCDRecords ........................................................................................................... 124 
2.112. NoOfSpecificConditionRecords ................................................................................................ 125 
2.113. Odomet erShor t.................................................................................................................... 125 
2.114. Odomet erValueMidnight ........................................................................................................ 125 
2.115. Odomet erValueMidnightRecordAr ray........................................................................................ 125 
2.116. OverspeedNumber ................................................................................................................ 125 
2.117. PlaceRecord ........................................................................................................................ 126 
2.118. PreviousV ehicleInf o............................................................................................................... 126 
2.119. PublicKey ........................................................................................................................... 127 
2.120. RecordT ype ......................................................................................................................... 127 
2.121. RegionAlpha ....................................................................................................................... 128 
2.122. Assignation de valeur: ........................................................................................................... 128 
2.123. Remot eCommunicationModuleSer ialNumber .............................................................................. 129 
2.124. RSA KeyModulus .................................................................................................................. 129 
2.125. RSA KeyPublicExponent ......................................................................................................... 129 
2.126. RSA KeyPublicExponent ......................................................................................................... 129 
2.127. RtmData ............................................................................................................................ 129 
2.128. SealDataCard ....................................................................................................................... 129 
2.129. SealDataV u......................................................................................................................... 130 
2.130. SealRecord .......................................................................................................................... 130 
2.131. SensorAppro valNumber ......................................................................................................... 130 
2.132. SensorExt ernalGNSSA ppro valNumber ....................................................................................... 131 
2.133. SensorExt ernalGNSSCoupledRecord ......................................................................................... 131 
2.134. SensorExt ernalGNSSIdentifi cation ............................................................................................ 131 
2.135. SensorExt ernalGNSSInstallation ............................................................................................... 132 
2.136. SensorExt ernalGNSSOSIdentifi er.............................................................................................. 132 
2.137. SensorExt ernalGNSSSCIdentifie r.............................................................................................. 132 
2.138. SensorGNSSCouplingDate ...................................................................................................... 133 26.5.2016 L 139/84 Jour nal officiel de l'Union européenne FR     
2.139. SensorGNSSSer ialNumber ...................................................................................................... 133 
2.140. SensorIdentification .............................................................................................................. 133 
2.141. SensorInstallation ................................................................................................................. 133 
2.142. SensorInstallationSecData ....................................................................................................... 134 
2.143. SensorOSIdentifier ................................................................................................................ 134 
2.144. SensorP aired ....................................................................................................................... 134 
2.145. SensorP airedRecord .............................................................................................................. 135 
2.146. SensorP airingDate ................................................................................................................ 135 
2.147. SensorSCIdentifier ................................................................................................................ 135 
2.148. SensorSer ialNumber .............................................................................................................. 135 
2.149. Signature ............................................................................................................................ 135 
2.150. SignatureRecordAr ray........................................................................................................... 136 
2.151. SimilarEventsNumber ............................................................................................................ 136 
2.152. SpecificConditionRecord ........................................................................................................ 136 
2.153. SpecificConditions ................................................................................................................ 136 
2.154. SpecificCondition Type ........................................................................................................... 137 
2.155. Speed ................................................................................................................................ 137 
2.156. SpeedA uthor ised .................................................................................................................. 137 
2.157. SpeedA verag e...................................................................................................................... 138 
2.158. SpeedMax ........................................................................................................................... 138 
2.159. TachographP ayload ............................................................................................................... 138 
2.160. TachographP ayloadEncr ypted .................................................................................................. 138 
2.161. TDesSessionKe y................................................................................................................... 138 
2.162. TimeReal ............................................................................................................................ 139 
2.163. TyreSize ............................................................................................................................. 139 
2.164. VehicleIdentif icationNumber ................................................................................................... 139 
2.165. VehicleIdentif icationNumberRecordAr ray................................................................................... 139 
2.166. VehicleRegistrationIdentificat ion .............................................................................................. 139 
2.167. Numéro d'immatr iculation du véhicule ...................................................................................... 140 
2.168. VehicleRegistrationNumberRecordAr ray.................................................................................... 140 
2.169. VuAbility ............................................................................................................................ 140 
2.170. VuActivityDailyData .............................................................................................................. 141 
2.171. VuActivityDailyRecordAr ray................................................................................................... 141 
2.172. VuAppro valNumber .............................................................................................................. 141 
2.173. VuCalibrationData ................................................................................................................ 142 
2.174. VuCalibrationRecord ............................................................................................................. 142 
2.175. VuCalibrationRecordAr ray...................................................................................................... 143 26.5.2016 L 139/85 Jour nal officiel de l'Union européenne FR     
2.176. VuCardIWData .................................................................................................................... 144 
2.177. VuCardIWRecord ................................................................................................................. 144 
2.178. VuCardIWRecordAr ray.......................................................................................................... 145 
2.179. VuCardRecord ..................................................................................................................... 145 
2.180. VuCardRecordAr ray.............................................................................................................. 146 
2.181. VuCer tificate ....................................................................................................................... 146 
2.182. VuCer tificateRecordAr ray....................................................................................................... 146 
2.183. VuCom panyL ocksData .......................................................................................................... 147 
2.184. VuCom panyL ocksRecord ....................................................................................................... 147 
2.185. VuCom panyL ocksRecordAr ray................................................................................................ 148 
2.186. VuControlA ctivityData .......................................................................................................... 148 
2.187. VuControlA ctivityRecord ....................................................................................................... 148 
2.188. VuControlA ctivityRecordAr ray................................................................................................ 149 
2.189. VuDataBloc kCounter ............................................................................................................. 149 
2.190. VuDetailedSpeedBlock ........................................................................................................... 149 
2.191. VuDetailedSpeedBlockRe cordAr ray........................................................................................... 150 
2.192. VuDetailedSpeedData ............................................................................................................ 150 
2.193. VuDo wnloadableP eriod.......................................................................................................... 150 
2.194. VuDo wnloadableP eriodRecordAr ray......................................................................................... 151 
2.195. VuDo wnloadA ctivityData ....................................................................................................... 151 
2.196. VuDo wnloadA ctivityDataRecordAr ray....................................................................................... 151 
2.197. VuEventData ....................................................................................................................... 152 
2.198. VuEventRecord .................................................................................................................... 152 
2.199. VuEventRecordAr ray............................................................................................................. 153 
2.200. VuFaul tData ........................................................................................................................ 154 
2.201. VuFaul tRecord ..................................................................................................................... 154 
2.202. VuFaul tRecordAr ray.............................................................................................................. 155 
2.203. VuGNSSCDRecord ................................................................................................................ 155 
2.204. VuGNSSCDRecordAr ray........................................................................................................ 156 
2.205. VuIdentification ................................................................................................................... 156 
2.206. VuIdentificationRecordAr ray................................................................................................... 157 
2.207. VuITSConsentRecord ............................................................................................................ 157 
2.208. VuITSConsentRecordAr ray..................................................................................................... 158 
2.209. VuManufa cturerAddress ......................................................................................................... 158 
2.210. VuManufa cturerName ............................................................................................................ 158 
2.211. VuManufa ctur ingDate ............................................................................................................ 158 26.5.2016 L 139/86 Jour nal officiel de l'Union européenne FR     
2.212. VuOverSpeedingControlData .................................................................................................. 159 
2.213. VuOverSpeedingControlDataRecordAr ray.................................................................................. 159 
2.214. VuOverSpeedingEventData ..................................................................................................... 159 
2.215. VuOverSpeedingEventRecord .................................................................................................. 159 
2.216. VuOverSpeedingEventRecordAr ray........................................................................................... 160 
2.217. VuPartNumber ..................................................................................................................... 161 
2.218. VuPlaceDailyW orkPe riodData .................................................................................................. 161 
2.219. VuPlaceDailyW orkPe riodRecord ............................................................................................... 161 
2.220. VuPlaceDailyW orkPe riodRecordAr ray....................................................................................... 162 
2.221. VuPublicKey ........................................................................................................................ 162 
2.222. VuPublicKey ........................................................................................................................ 162 
2.223. VuSer ialNumber ................................................................................................................... 162 
2.224. VuSof tInstallationDate ........................................................................................................... 162 
2.225. VuSof twareIdentif ication ........................................................................................................ 163 
2.226. VuSof twareV ersion ............................................................................................................... 163 
2.227. VuSpecificConditionData ....................................................................................................... 163 
2.228. VuSpecificConditionRecordAr ray............................................................................................. 163 
2.229. VuTimeAd justmentData ......................................................................................................... 164 
2.230. VuTimeAd justmentGNSSRecord .............................................................................................. 164 
2.231. VuTimeAd justmentGNSSRecordAr ray....................................................................................... 164 
2.232. VuTimeAd justmentRecord ...................................................................................................... 165 
2.233. VuTimeAd justmentRecordAr ray.............................................................................................. 165 
2.234. WorkshopCardApplicationIdentification .................................................................................... 166 
2.235. WorkshopCardCalibrationData ................................................................................................ 166 
2.236. WorkshopCardCalibrationRecord ............................................................................................. 167 
2.237. WorkshopCardHolderIdentificat ion .......................................................................................... 168 
2.238. WorkshopCardPIN ................................................................................................................ 168 
2.239. W-VehicleCharact eristicConstant .............................................................................................. 169 
2.240. VuPowerSupplyInt erruptionRecord ........................................................................................... 169 
2.241. VuPowerSupplyInt erruptionRecordArr ay................................................................................... 169 
2.242. VuSensorExt ernalGNSSCoupledRecordAr ray............................................................................... 170 
2.243. VuSensorP airedRecordAr ray.................................................................................................... 170 
3. DÉFINITIONS DES PLAGES DE VALEURS ET DE DIMENSIONS .................................................................... 171 
4. JEUX DE CARA CTÈRES ...................................................................................................................... 171 
5. ENCOD AGE .................................................................................................................................... 171 
6. IDENTIFICA TEURS D'OBJETS ET IDENTIFICA TEURS D'APPLICA TIONS .......................................................... 171 
6.1. Identificateurs d'objets ........................................................................................................... 171 
6.2. Identificateur d'application ..................................................................................................... 172  26.5.2016 L 139/87 Jour nal officiel de l'Union européenne FR     
1.  INTR ODUCTION 
Le présent appendice fournit une série de précisions concer nant les formats, éléments et structures de données 
utilisés au sein des appareils de contrôle et cartes tach ygraphiques. 
1.1.  Méthode d'ét ablissement des définitions de type de données 
Le présent appendice a recours à la méthode Abstract Syntax Notation One (ASN.1) pour définir les diffé rents 
types de données. Ce système autori se la définit ion de données simples et structurées sans nécessiter l'em ploi 
d'une syntaxe de transfer t spécifique (règles de codage) qui dépende de l'application et de l'env ironnement 
considérés. 
Les règles d'affecta tion des noms du type ASN.1 sont établies en conf ormité avec la norme ISO/IEC 8824-1. Cela 
implique que: 
—  dans la mesure du possible, la signification d'un type de données est implicitement fournie par le nom qui 
leur est attribué, 
—  si un type de données se compo se d'autres types de données, le nom de ce type de données se présent e 
encore et toujours sous la forme d'une seule séquence de caractères alphabétiques commençant par une 
majuscule, quoique ce nom compo rte un nombre indét erminé de majuscules qui en rappellent la signifi ­
cation, 
—  de manière général e, les noms de type de données sont en rappor t avec le nom des types de données à partir 
desquels ils sont constr uits, avec l'équipement au sein duquel les données sont mémor isées et avec la 
fonction associée aux données considérées. 
Si l'em ploi d'un type ASN.1 déjà défini dans le cadre d'une autre norme s'impose avec l'appareil de contrôle, ce 
type ASN.1 sera défini dans le présent appendice. 
Afin d'autor iser l'application de plusieurs types de règles de codag e, certains types ASN.1 évoqués dans le présent 
appendice sont soumis à des identif icateurs de plag e de valeurs. Ces identif icateurs de plage de valeurs sont 
définis au paragraphe 3, appendice 2. 
1.2.  Références 
Le présent appendice fait référence aux documents suivants: 
ISO 639  Code de représentation des noms de langue. Première édition: 1988. 
ISO 3166  Codes pour la représentation des noms de pays et de leurs subdivisions — Partie 1: Codes de 
pays, 2013 
ISO 3779  Véhicules routiers — Numéro d'identif ication du véhicule (VIN) — Contenu et structure. 2009 
ISO/IEC 7816-5  Cartes d'identif ication — Cartes à circuit intégré — Partie 5: Enregistrement des fournisseurs 
d'application. 
Deuxième édition: 2004. 
ISO/IEC 7816-6 Cartes d'identif ication — Cartes à circuit intégré — Partie 6: Éléments de données intersec ­
toriels pour les écha nges, 2004 + Rectif icatif technique 1: 2006 
ISO/IEC 8824-1 Techn ologies de l'information — Notation de syntaxe abstrait e numéro un (ASN.1): Spécifi ­
cation de la notation de base. 2008 + Rectifi catif technique 1: 2012 et Rectific atif technique 2: 
2014. 
ISO/IEC 8825-2  Techn ologies de l'information — Règles de codag e ASN.1: Spécific ation des règles de codag e 
compact (PER) 2008. 
ISO/IEC 8859-1  Techn ologies de l'information — Jeux de caractères graphiques codés sur un seul octet — 
Partie 1: Alphabet latin no.1. Première édition: 1998. 
ISO/IEC 8859-7  Techn ologies de l'information — Jeux de caractères graphiques codés sur un seul octet — 
Partie 7: Alphabet latin/grec. 2003. 26.5.2016 L 139/88 Jour nal officiel de l'Union européenne FR     
ISO 16844-3  Véhicules routiers — Systèmes tach ygraphes — Interface de capt eur de mouvement. 2004 + 
Rectif icatif technique 1: 2006. 
TR-03110-3  BSI/ANSSI Rappor t technique TR-03110-3, Mécanismes de sécur ité avancés pour les 
documents de voyage lisibles à la machi ne et jeton eIDAS — Partie 3 Spécifications 
communes, version 2.20, 3. Févr ier 2015 
2.  DÉFINITIONS DES TYPES DE DONNÉES 
Quel que soit le type de données considéré parmi ceux qui suivent, un contenu «inconnu» ou «sans objet» 
entraînera l'attr ibution d'une valeur par défa ut résultant du remp lissage de l'élément de données concer né au 
moyen d'oct ets ‘FF’. 
Tous les types de données servent aux applications de génération 1 et 2 sauf disposition contraire. 
2.1.  Acti vityChangeInfo 
Ce type de données autor ise le codag e, en mots de deux octets, d'un état du lecteur à 00h00 et/ou d'un état du 
conducteur à 00h00 et/ou de change ments d'activit é, d'état de conduite et/ou d'état de carte se rappor tant à un 
conducteur ou un conv oyeur . Ce type de données est lié aux exige nces 105, 266, 291, 320, 321, 343 et 344 de 
l'annexe 1C. 
Assignation de valeur — Octet aligné: ‘scpaattttttttttt’ B (16 bits) 
Pour les enregistrements en mémoire de données (ou de l'état du lecteur ): 
‘s’B  Lecteur: 
‘0’B: CONDUCTEUR 
‘1’B: CONV OYEUR 
‘c’B  État de conduite: 
‘0’B: SEUL 
‘1’B: ÉQUIP AGE 
‘p’B  État de la carte de conducteur (ou d'atelier) insérée dans le lecte ur appropr ié: 
‘0’B: INSÉRÉE, la carte est insérée 
‘1’B: NON INSÉRÉE, aucune carte n'est insérée (ou la carte est retirée) 
‘aa’B  Activité 
‘00’B: PAUSE/REPOS 
‘01’B: DISPONIBILITÉ 
‘10’B: TRA VAIL 
‘11’B: CONDU ITE 
‘ttttttttttt’B  Heure du chang ement : nombre de minut es écoulées depuis 00h00 le jour considéré. 26.5.2016 L 139/89 Jour nal officiel de l'Union européenne FR     
Pour les enregistrements (et l'état du conducteur) sur carte de conduct eur (ou d'ate lier): 
‘s’B  Lecteur (hors de propos si ‘p’ = 1 sauf remarque ci-après): 
‘0’B: CONDUCTEUR 
‘1’B: CONV OYEUR 
‘c’B  État de conduite (cas ‘p’=0) ou 
État d'activit é suivant (cas ‘p’=1): 
‘0’B: UNIQUE, 
‘0’B: INCONNU 
‘1’B: ÉQUIP AGE, 
‘1’B: CONNU (= saisie manuelle) 
‘p’B  État de la carte: 
‘0’B: INSÉRÉE, la carte est insérée dans un appareil de contrôle 
‘1’B: NON INSÉRÉE, aucune carte n'est insérée (ou la carte est retirée) 
‘aa’B  Activité (hors de propos si ‘p’ = 1 et ‘c’ = 0 sauf remarque ci-après): 
‘00’B: PAUSE/REPOS 
‘01’B: DISPONIBILITÉ 
‘10’B: TRA VAIL 
‘11’B: CONDU ITE 
‘ttttttttttt’B  Heure du chang ement : nombre de minut es écoulées depuis 00h00 le jour considéré. 
Remarque 
En cas de «retrait de la carte»: 
—  ‘s’ s'applique et indique le lecteur dont la carte a été extraite, 
—  ‘c’ doit être mis à 0, 
—  ‘p’ doit être mis à 1, 
—  ‘aa’ doit coder l'activité en cours sélectionnée au même moment. 
Rien ne s'oppose à ce que les bits ‘c’ et ‘aa’ du mot (enregistré sur une carte) soient écrasés à la suite d'une saisie 
manuelle pour refléter l'entrée de données correspondant e. 
2.2.  Addre ss 
Une adresse. 
26.5.2016 L 139/90 Jour nal officiel de l'Union européenne FR     
codePage spécifie un jeu de caractères défini au chapitre 4, 
address indique une adresse encodée à l'aide du jeu de caractères spécifi é. 
2.3.  AESKey 
Génération 2: 
Une clé AES d'une longueur de 128, 192 ou 256 bits. 
Attr ibution de valeur : pas spécifiée davantag e. 
2.4.  AES128Key 
Génération 2: 
Une clé AES128. 
length indique la longueur de la clé AES128 en octets. 
aes128Key désigne une clé AES d'une longueur de 128 bits. 
Attr ibution de valeur : 
La longueur possède une valeur de 16. 
2.5.  AES192Key 
Génération 2: 
Une clé AES192. 
length indique la longueur de la clé AES192 en octets. 
aes192Key désigne une clé AES d'une longueur de 192 bits. 
Attr ibution de valeur : 
La longueur possède une valeur de 24. 26.5.2016 L 139/91 Jour nal officiel de l'Union européenne FR     
2.6.  AES256Key 
Génération 2: 
Une clé AES256. 
length indique la longueur de la clé AES256 en octets. 
aes256Key désigne une clé AES d'une longueur de 256 bits. 
Attr ibution de valeur : 
La longueur possède une valeur de 32. 
2.7.  BCDStr ing 
BCDStr ing s'applique à la représentation de données en décimal codé binaire (DCB). Ce type de données s'utilise 
pour représent er un chiffre décimal par un quar tet (4 bits). BCDStr ing repose sur l'application de la norme ISO/ 
IEC 8824-1 ‘Character StringT ype’ (type de chaîne de caractères). 
BCDStr ing a recours à une notation «hstr ing». Le chiffre hexadécimal de gauc he sera considéré comme le quar tet 
le plus signif icatif du premier octet. Pour produire un multiple d'octets, il faut insérer le nombre appropr ié de 
quar tets de droite nuls à partir de la position qu'occupe le quar tet le plus signif icatif du premier octet. 
Chiffres admis: 0, 1, .. 9. 
2.8.  CalibrationPur pose 
Code indiquant la raison de l'enregistrement d'un jeu de paramètres d'étalonnag e. Ce type de données est lié aux 
exigenc es 097 et 098 de l'annexe 1B et des exigences 119 de l'annex e 1C. 
Attr ibution de valeur : 
Génération 1: 
‘00’H  valeur réser vée 
‘01’H  enregistrement de paramètres d'étalonnage connus, au moment de l'activation de la VU, 
‘02’H  premier étalonnage de la VU après son activation, 
‘03’H  premier étalonnage de l'unité embarquée sur le véhicule considéré, 
‘04’H  inspection périodique, 26.5.2016 L 139/92 Jour nal officiel de l'Union européenne FR     
Génération 2: 
Outre la génération 1, les valeurs suivantes sont utilisées: 
‘05’H  entrée des VRN par entrepr ise, 
‘06’H  mise à l'heure sans étalonnage, 
‘07’H à ‘7F’H  RFU, 
‘80’H à ‘FF’H  propre au fabricant. 
2.9.  CardActi vityDailyRecord 
Informations enregistrées sur une carte et se rappor tant aux activités auxquelles le conduct eur s'est livré pendant 
un jour civil précis. Ce type de données est lié aux exigences 266, 291, 320 et 343 de l'annex e 1C. 
activityPreviousRecordLength indique la longueur totale du précédent relevé quotidien expr imée en octets. La 
valeur maximale correspond à la longueur de la CHAÎNE D'OCTETS conte nant ces relevés (cf. CardA ctivityLeng ­
thRan ge, appendice 2, paragraphe 4) Lorsque ces données correspondent au relevé quotidien le plus ancien, la 
valeur de l'activityPreviousRecordLength doit être mise à 0. 
activityRecordLength indique la longueur tota le de ce relevé expr imée en octets. La valeur maximale 
correspond à la longueur de la CHAÎNE D'OCTETS conte nant ces relevés. 
activityRecordDate indique la date du relevé. 
activityDailyPresenceCounter indique l'état du comp teur de présence jour nalière pour la carte et le jour 
considérés. 
activityDayDi stance indique la distance totale parcour ue le jour considéré. 
activityChangeInfo indique le jeu de données ActivityChangeInf o se rappor tant au conducteur et au jour 
considérés. Cette chaîne d'oct ets ne peut cont enir plus de 1440 valeurs (un chang ement d'activit é par minute). 
Ce jeu compre nd toujour s l'ActivityChang eInfo encodant l'état du conducteur à 00h00. 
2.10.  CardActi vityLengthR ange 
Nombre d'oct ets qu'une carte de conducteur ou d'atelier est susceptible d'aff ecter à l'enregistrement de relevés 
d'activit é d'un conducteur . 
Attribution de valeur: cf. appendice 2. 
2.11.  CardAppro valNumber 
Numéro d'homologation de la carte. 
26.5.2016 L 139/93 Jour nal officiel de l'Union européenne FR     
Attr ibution de valeur : 
Le numéro d'homologation doit être fourni tel que publié par le site Internet de la Commission européenne 
correspondant, à savoir en incluant les traits d'union, par exem ple. Le numéro d'homologat ion doit être aligné à 
gauc he. 
2.12.  CardCer tificate 
Génération 1: 
Certificat associé à la clé publique d'une carte. 
2.13.  CardChipIdentif ication 
Informations enregistrées sur une carte et se rappor tant à l'identification du circuit intégré (CI) de cette carte 
(exigen ce 249 de l'annex e 1C). Le icSer ialNumber associé au icManufa ctur ingRef erences identif ie de manière 
unique le circuit de la carte. Le icSer ialNumber seul n'identif ie pas le circuit de la carte de manière unique. 
icSer ialNumber indique le numéro de série du CI. 
icManufactur ingReferences indique l'identifi cate ur du fabricant de CI. 
2.14.  CardConsecutiv eIndex 
Indice séquentiel de la carte considérée [définition h)]. 
Attr ibution de valeur: (cf. annexe 1C chapitre 7) 
Ordre croissant: ‘0, …, 9, A, …, Z, a, …, z’ 
2.15.  CardControlActivit yDat aRecord 
Informations enregistrées sur une carte de conduct eur ou d'ate lier et se rappor tant au dernier contrôle auquel le 
conducteur considéré a été soumis (exigen ces 274, 299, 327 et 350 de l'annex e 1C). 
controlT ype indique le type de contrôle. 
controlTime indique la date et l'heure du contrôle. 26.5.2016 L 139/94 Jour nal officiel de l'Union européenne FR     
controlCardNumber indique le numéro intégral de la carte du contrôleur qui a procédé au contrôle. 
controlV ehicleRegistration indique le VRN ainsi que l'État membre d'immatr iculation du véhicule soumis au 
contrôle considéré. 
controlDo wnloadPeriodBegin et controlDo wnloadPerio dEnd indiquent la période télécharg ée, en cas de 
téléc hargement. 
2.16.  CardCur rentUse 
Informations relatives à l'usage effectif de la carte (exigen ces 273, 298, 326 et 349 de l'annex e 1C). 
sessionOpen Time indique l'heure d'inser tion de la carte utilisée dans le cadre de l'activité en cours. Cet élément 
est mis à zéro lors du retrait de la carte. 
sessionOpenV ehicle correspond à l'identif ication du véhicule après inser tion de la carte. Cet élément est mis à 
zéro lors du retrait de la carte. 
2.17.  CardDr iverActivity 
Informations enregistrées sur une carte de conducteur ou d'ateli er et se rappor tant aux activités du conducteur 
(exigen ces 267, 268, 292, 293, 321 et 344 de l'annexe 1C). 
activityPointer Oldest Day Record indique avec précision le début de l'em placement en mémoire (nombre 
d'oct ets comp tés à partir du début de la chaîne) du relevé quotidien compl et le plus ancien que compor te la 
chaîne activityDailyRecords. La valeur maximale correspond à la longueur de la chaîne. 
activityPointer New estRecord indique avec précision le début de l'em placement en mémoire (nombre d'oct ets 
comp tés à partir du début de la chaîne) du relevé quotidien le plus récent que compo rte la chaîne activityDaily ­
Records. La valeur maximale correspond à la longueur de la chaîne. 
activityDailyRecords indique l'espace disponible affect é à l'enregistrement de données relatives aux activités du 
conducteur (structure de données: CardA ctivityDailyRecord) pour chaque jour civil au cours duquel la carte a été 
utilisée. 
Attr ibution de valeur : cette chaîne d'oct ets est périodiquement remplie de relevés du type CardA ctivityDaily ­
Record. Lors de la première utilisation, le début de l'enregistrement du premier relevé coïncide avec le premier 
octet de la chaîne. Les relevés suivants sont enregistrés à la fin du précédent. Lorsque la chaîne est saturée, l'enre ­
gistrement se poursuit en reprenant au premier octet de la chaîne, sans tenir comp te d'aucune interrupti on 
susceptible d'affect er un élément d'inf ormation quelconque. Avant d'introduire de nouvelles données d'activit é 
dans la chaîne (en étendant l'activityDailyRecord actuel ou en insérant un nouvel activityDailyRecord), lesquelles 
se substituent aux données d'activit é les plus anciennes, il convient d'actualiser l'activityP ointerO ldestDa yRecord 
pour rendre comp te du nouvel emplacement en mémoire qu'occupe désor mais le relevé quotidien compl et le 
plus ancien et de mettre à zéro l'activityPreviousRecordLength de ce (nouveau) relevé quotidien compl et le plus 
ancien. 
2.18.  CardDr ivingLicenceInfo rmation 
Informations enregistrées sur une carte de conduct eur et se rappor tant aux données du permis de conduire du 
détent eur de la carte (exigence 259 et 284 de l'annex e 1C). 26.5.2016 L 139/95 Jour nal officiel de l'Union européenne FR     
drivingLicenceIssuingAuthor ity indique l'aut orité compét ente pour la délivrance du permis de conduire. 
drivingLicenceIssuingNation indique la nationalité de l'autorité compét ente pour la délivrance du permis de 
conduire. 
drivingLicenceNumber indique le numéro du permis de conduire. 
2.19.  CardEv entData 
Informations enregistrées sur une carte de conducteur ou d'atelier et se rappor tant aux événements associés au 
détent eur de la carte (exigences 260, 285, 318 et 341 de l'annexe 1C). 
CardEv entData consiste en une séquence de cardEventRecords (à l'exce ption des relevés portant sur les 
tentatives éventuelles d'atte inte à la sécur ité, lesquels sont regroupés dans le dernier ensemble de données de la 
séquence) dont l'agen cement correspond à celui des EventFa ultT ype rangé s par ordre croissant. 
cardEv entRecords consist e en un jeu de relevés d'événement correspondant à un type d'événement donné (ou à 
cette catégor ie d'événements dans laquelle se rangent les tentatives d'atteint e à la sécur ité). 
2.20.  CardEv entRecord 
Informations enregistrées sur une carte de conducteur ou d'atelier et se rappor tant aux événements associés au 
détent eur de la carte (exigences 261, 286, 318 et 341 de l'annexe 1C). 
eventT ype indique le type d'événement. 
eventBegin Time indique la date et l'heure du début de l'événement. 
eventEndTime indique la date et l'heure de la fin de l'événement. 
eventV ehicleRegist ration indique le VRN ainsi que l'État membre d'immatr iculation du véhicule dans lequel 
l'événement considéré s'est produit. 
2.21.  CardFaultData 
Informations enregistrées sur une carte de conducteur ou d'atelier et se rappor tant aux événements associés au 
détent eur de la carte (exigences 263, 288, 318 et 341 de l'annexe 1C). 
26.5.2016 L 139/96 Jour nal officiel de l'Union européenne FR     
CardFaultData consiste en une séquence compo rtant un jeu de relevés des anomalies qui affectent l'appareil de 
contrôle suivi d'un jeu de relevés des anomalies qui affect ent la ou les cartes utilisée(s). 
cardFaultRecords consiste en un jeu de relevés des anomalies qui se rangent dans une catégo rie donnée 
(appareil de contrôle ou carte). 
2.22.  CardFaultRecord 
Informations enregistrées sur une carte de conducteur ou d'atelier et se rappor tant aux événements associés au 
détent eur de la carte (exigences 264, 289, 318 et 341 de l'annexe 1C). 
faultT ype indique le type d'anomalie. 
faultBegin Time indique la date et l'heure de début de l'anomalie. 
faultEndTime indique la date et l'heure de fin de l'anomalie. 
faultV ehicleRegist ration indique le VRN ainsi que l'État membre d'immatr iculation du véhicule dans lequel 
l'anomalie considérée s'est produit e. 
2.23.  CardIccIdentif ication 
Informations enregistrées sur une carte et se rappor tant à l'identification de cette carte à circuit intégré (CI) 
(exigen ce 248 de l'annex e 1C). 
clockStop indique le mode Cloc kstop défini dans l'appendice 2. 
cardExtendedSer ialNumber indique le numéro de série unique de la carte à circuit intégré spécifi é par le type 
de données Exten dedSer ialNumber . 
cardAppro valNumber indique le numéro d'homologation de la carte. 
cardPers onaliserID indique l'ID individuelle de la carte cryptée par le ManufacturerCode. 
embedderIcAssemblerId fournit des informations à propos de l'inté grateur/assembleur de CI. 
icIdentif ier indique l'identifi cate ur du CI monté sur la carte et de son fabricant défini dans la norme ISO/ 
IEC 7816-6. 
2.24.  CardIdentif ication 
Informations enregistrées sur une carte et se rappor tant à l'identifi cation de celle-ci (exigen ces 255, 280, 310, 
333, 359, 365, 371 et 377 de l'annexe 1C). 26.5.2016 L 139/97 Jour nal officiel de l'Union européenne FR     
cardIssuingMemberStat e désigne le code de l'État membre émetteur de la carte. 
cardNumber indique le numéro de carte de la carte considérée. 
cardIssuingAuthor ityName indique le nom de l'autorité compét ente pour la délivrance de la carte considérée. 
cardIssueDate indique la date de délivrance de la carte à son titulaire actuel. 
cardV alidityBegin indique la date de la première entrée en vigueur de la carte. 
cardExpir yDate indique la date d'expiration de la carte. 
2.25.  CardMA Cer tificate 
Génération 2: 
Certificat associé à la clé publique d'une carte destinée à son authentifi cation avec une VU. La structure de ce 
certificat est spécifiée dans l'appendice 11. 
2.26.  CardNumber 
Un numéro de carte conf orme à la définition g). 
driverIdentif ication indique l'identifi cation individuelle d'un conduct eur recensé dans un État membre. 
ownerIdentif ication indique l'identification individuelle d'une entrepr ise, d'un atelier ou d'un organisme de 
contrôle établis dans un État membre. 
cardConsecutiv eIndex indique l'indice séquentiel de la carte considérée. 
cardReplacementIndex indique l'indice de rem placement de la carte. 26.5.2016 L 139/98 Jour nal officiel de l'Union européenne FR     
cardRenewalIndex indique l'indice de renouvellement de la carte. 
La première séquence de la sélection permet de coder un numéro de carte de conduct eur, la seconde séquence de 
coder les numéros des cartes d'atelier , de contrôleur et d'entrepr ise. 
2.27.  CardPlaceDailyW orkPeriod 
Informations enregistrées sur une carte de conduct eur ou d'ateli er et se rappor tant aux lieux de début et/ou de 
fin des périodes de travail jour nalières (exigen ces 272, 297, 325 et 348 de l'annex e 1C). 
placeP ointerNew estR ecord désigne l'indice du plus récent relevé de lieux mis à jour . 
Attr ibution de valeur: nombre correspondant au numérat eur du relevé de site, commençant par une série de 
‘0’ pour la première occur rence d'un relevé de site dans la structure considérée. 
placeRecords indique le jeu de relevés cont enant les données relatives aux lieux entrés. 
2.28.  CardPublicKey 
Génération 1: 
Clé privée d'une carte. 
2.29.  CardPublicKey 
Clé publique d'une carte. 
2.30.  CardRenewalIndex 
Indice de renouvellement d'une carte [déf inition i)]. 
Attr ibution de valeur: (cf. Chapitre VII de la présent e annexe ). 
‘0’  Première édition. 
Ordre croissant: ‘0, …, 9, A, …, Z’ 
2.31.  CardReplacementIndex 
Indice de rem placement d'une carte [déf inition j)]. 
Attr ibution de valeur: (cf. Chapitre VII de la présent e annexe ). 
‘0’  Carte originale. 
Ordre croissant: ‘0, …, 9, A, …, Z’ 26.5.2016 L 139/99 Jour nal officiel de l'Union européenne FR     
2.32.  CardSignCer tificate 
Génération 2: 
Certificat associé à la clé publique d'une carte en vue de la signature. La structure de ce certificat est spécif iée 
dans l'appendice 11. 
2.33.  CardSlotNumber 
Code permettant de faire la distinction entre les deux lecteur s de carte d'une unité embarquée sur véhicule. 
Affectation de valeur: pas spécifi ée davan tage. 
2.34.  CardSlotsSt atus 
Code indiquant le type des cartes insérées dans les deux lecteurs de l'unit é embarquée. 
Assignation de valeur — Octet aligné: ‘ccccdddd’B 
‘cccc’B  Identif ication du type de carte insérée dans le lecte ur réser vé au conv oyeur 
‘dddd’B  Identif ication du type de carte insérée dans le lecte ur réser vé au conduct eur 
à l'aide des codes d'identif ication suivants: 
‘0000’B  aucune carte n'est insérée dans un lecteur 
‘0001’B  une carte de conducteur est insérée dans un lecteur 
‘0010’B  une carte d'ateli er est insérée dans un lecteur 
‘0011’B  une carte de contrôleur est insérée dans un lecteur 
‘0100’B  une carte d'entrepr ise est insérée dans un lecte ur. 
2.35.  CardSlotsSt atusRecordAr ray 
Génération 2: 
Le CardSlotsStatus plus les métadonnées tels qu'utilisés dans le protocole de téléc hargement. 
recordT ype indique le type de relevé (CardSlotsStatus). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des CardSlotsStatus expr imée en octets. 26.5.2016 L 139/100 Jour nal officiel de l'Union européenne FR     
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records indique le jeu de relevés de CardSlotsStatus. 
2.36.  CardStr uctureV ersion 
Code indiquant la version de la structure mise en œuvre au sein d'une carte tach ygraphique. 
Attr ibution de valeur: ‘aabb’H: 
‘aa’H  Index des modifications appor tées à la structure 
‘00’H pour les applications de génération 1 
‘01’H pour les applications de génération 2 
‘bb’H  Index des modifi cations concer nant l'utilisation des éléments d'inf ormation définis pour la 
structure donnée par l'octet de poids fort. 
‘00’H pour cette version d'applications de génération 1 
‘00’H pour cette version d'applications de génération 2 
2.37.  CardV ehicleRecord 
Informations enregistrées sur une carte de conduct eur ou d'ateli er et se rappor tant à une période d'utilisation 
d'un véhicule donné pendant un jour civil déterminé (exigen ces 269, 294, 322 et 345 de l'annexe 1C). 
Génération 1: 
vehicleOdometerBegin indique la valeur affichée par le comp teur kilométr ique d'un véhicule donné au début 
de la période d'utilisation considérée. 
vehicleOdometerEnd indique la valeur affichée par le comp teur kilométr ique d'un véhicule donné à la fin de la 
période d'utilisation considérée. 
vehicleFi rstUse indique la date et l'heure du début de la période d'utilisation du véhicule. 
vehicleLas tUse indique la date et l'heure de la fin de la période d'utilisation du véhicule. 
vehicleRegist ration indique le VRN ainsi que l'État membre où le véhicule considéré est immatr iculé. 
vuData BlockCounter indique la valeur affichée par le comp teur de blocs de données de la VU lors de la 
dernière extraction de la période d'utilisation du véhicule. 26.5.2016 L 139/101 Jour nal officiel de l'Union européenne FR     
Génération 2: 
Outre la génération 1, l'élément de données suivant est utilisé: 
VehicleIdentif icationNumber désigne le numéro d'identif ication du véhicule faisant référence au véhicule dans 
son entier . 
2.38.  CardV ehiclesUsed 
Informations enregistrées sur une carte de conducteur ou d'atelier et se rappor tant aux événements associés au 
détent eur de la carte (exigences 270, 295, 323 et 346 de l'annexe 1C). 
vehiclePointer New estRecord indique l'indice du dernier relevé de véhicule actualisé par le système. 
Attr ibution de valeur : nombre correspondant au numérat eur du relevé de véhicule, commençant par une série 
de ‘0’ pour la première occur rence d'un relevé de véhicule dans la structure considérée. 
cardV ehicleRecords indique le jeu de relevés conte nant des informations relatives aux véhicules utilisés. 
2.39.  CardV ehicleUnitRecord 
Génération 2: 
Informations enregistrées sur une carte de conducteur ou d'atelier et se rappor tant aux événements associés au 
véhicule (exigences 303 et 351 de l'annex e 1C). 
timeSt amp indique le début de la période d'utilisation du véhicule (c'est-à-dire de la première inser tion de la 
carte dans l'unité embarquée sur véhicule pour cette période). 
manufacturerCode identif ie le fabricant de l'unit é embarquée sur véhicule. 
deviceID identif ie le type d'unité embarquée sur le véhicule d'un fabricant. La valeur est propre au fabricant. 
vuSof twareV ersion indique le numéro de la version du logiciel de l'unité embarquée sur véhicule. 
2.40.  CardV ehicleUnitsUsed 
Génération 2: 
Informations enregistrées sur une carte de conducteur ou d'ateli er et se rappor tant aux unités embarquées sur 
véhicules associées au détent eur de la carte (exigences 306 et 352 de l'annex e 1C). 26.5.2016 L 139/102 Jour nal officiel de l'Union européenne FR     
vehicleUnitPoi nterNew estR ecord indique l'indice du dernier relevé d'unité embarquée sur véhicule actualisé. 
Attr ibution de valeur: nombre correspondant au numérat eur du relevé de l'unit é embarquée sur véhicule, 
commençant par une série de ‘0’ pour la première occur rence d'un relevé d'unité embarquée sur véhicule dans la 
structure considérée. 
cardV ehicleUnitRecords indique le jeu de relevés cont enant des informations relatives aux unités embarquées 
sur véhicules utilisés. 
2.41.  Cer tificat 
Certificat d'une clé publique délivrée par un organisme de certification. 
Génération 1: 
Attr ibution de valeur: signature numér ique avec récupération partielle du cont enu d'un certificat aux term es de 
l'appendice 11 «Mécanismes de sécur ité communs»: signature (128 octets) | reste de clé publique (58 octets) | 
références de l'organ isme de certificat ion (8 octets). 
Génération 2: 
Attribution de valeur: cf. appendice 11 
2.42.  Cer tificateContent 
Génération 1: 
Le contenu (accessible) du certificat d'une clé publique aux termes de l'appendice 11 «Mécanismes de sécur ité 
communs». 
certificateProf ileIdentif ier indique la version du certificat correspondant. 
Attr ibution de valeur: ‘01h’ pour cette version. 
certificationAuthor ityRefer ence identif ie l'organisme de certification qui a délivré le certificat considéré. Ces 
données font également référence à la clé publique de cet organisme de certification. 
certificateHolderAuthor isation identifie les droits du titulaire du certificat. 
certificateEndOfV alidity indique la date d'expiration administrative du certificat . 
certificateHolderRef erence identifie le titulaire du certificat. Ces données font également référence à sa clé 
publique. 
publicKey indique la clé publique certifiée par ce certificat. 26.5.2016 L 139/103 Jour nal officiel de l'Union européenne FR     
2.43.  Cer tificateRequest ID Identif ication individuelle d'une demande de certificat. 
Identif ication des droits d'un titulaire de certificat . 
Génération 1: 
tacho graphApplicationID indique l'identif icateur de l'application tach ygraphique. 
Attr ibution de valeur: ‘FFh’ ‘54h’ ‘41h’ ‘43h’ ‘48h’ ‘4Fh’. Cette ID d'application est un identificateur d'application 
excl usif non homologué, conf orme à la norme ISO/IEC 7816-5. 
equipmentT ype identif ie le type d'équipement visé par le certificat. 
Attr ibution de valeur: en conf ormité avec le type de données EquipmentT ype. 0 si le certificat émane de l'un 
des États membres. 
Génération 2: 
tacho graphApplicationID indique les 6 octets les plus signif icatifs de l'identifi cateur d'application (AID) pour 
carte tach ygraphique de deuxième génération. Le chapitre 6.2 spécifi e l'AID pour l'application de carte tach ygra ­
phique. 
Attr ibution de valeur : ‘FF 53 4D 52 44 54’ 
equipmentT ype identif ie le type d'équipement visé par le certificat et spécifié pour la génération 2. 
Attr ibution de valeur: en conf ormité avec le type de données EquipmentT ype. 
2.44.  Cer tificateRequest ID 
Identif ication individuelle d'une demande de certificat. Elle peut également faire office d'identif icateur de clé 
publique de l'unit é embarquée sur véhicule en cas de méconnaissance du numéro de série de l'unit é à laquelle la 
clé est destinée, lors de l'élaboration du certificat. 
request SerialNumber indique le numéro de série de la demande de certificat , propre au fabr icant, ainsi que le 
mois ci-après. 
request MonthY ear identifie le mois et l'année de la demande de certificat. 
Attr ibution de valeur: codag e BCD du mois (deux chiffres) et de l'année (les deux derniers chiffres). 
crIdentif ier est un identif icate ur permettant de faire la distinction entre une demande de certificat et un numéro 
de série étendu. 
Attr ibution de valeur: ‘FFh’ . 
manufacturerCode: Code du fabr icant correspond au code numér ique du fabr icant qui a émis la demande de 
certificat. 
2.45.  Cer tificationAuthor ityKID 
Identif icateur de la clé publique d'un organisme de certification (un État membre ou l'organ isme de certificat ion 
européen). 26.5.2016 L 139/104 Jour nal officiel de l'Union européenne FR     
nationNumer ic indique le code numér ique national de l'organ isme de certification. 
nationAlpha indique le code alphanumér ique national de l'organ isme de certification. 
keySer ialNumber est un numéro de série permettant de faire la distinction entre les différentes clés de 
l'organ isme de certificat ion si certaines clés font l'objet de modifi cations. 
additionalInfo est un cham p de deux octets autorisant l'introduction de codes supplémentaires (propres à 
l'organ isme de certificat ion). 
caIdentif ier est un identif icate ur permettant de faire la distinction entre l'identificateur d'une clé associée à un 
organisme de certification et d'autres identif icateurs de clé. 
Attr ibution de valeur: ‘01h’ . 
2.46.  CompanyA ctivityData 
Informations enregistrées sur une carte d'entrepr ise et se rappor tant aux activités menées avec cette carte 
(exigen ce 373 et 379 de l'annex e 1C). 
companyP ointerNew estRecord indique l'indice du dernier relevé d'activité de l'entrepr ise actualisé par le 
système. 
Attr ibution de valeur : nombre correspondant au numérate ur du relevé d'activité de l'entrepr ise, commençant 
par une série de ‘0’ pour la première occur rence d'un relevé d'activit é de l'entrepr ise dans la structure considérée. 
companyA ctivityRecords indique le jeu regroupant l'ensemble des relevés d'activit é de l'entrepr ise. 
companyA ctivityRecord indique la séquence d'inf ormations associée à une activité de l'entrepr ise. 
companyA ctivityT ype indique le type de l'activité menée par l'entrepr ise. 
companyA ctivityTime indique la date et l'heure de l'activité menée par l'entrepr ise. 
cardNumberInfo rmation indique le numéro de la carte et, le cas échéant, l'État membre où la carte téléc hargée 
est délivrée. 
vehicleRegist rationInf ormation indique le VRN ainsi que l'État membre d'immatr iculation du véhicule 
téléc hargés, verrouillés ou déver rouillés. 
downloadPerio dBegin et downloadPeriodEnd indiquent, le cas éché ant, la période téléc hargée à partir de la 
VU. 26.5.2016 L 139/105 Jour nal officiel de l'Union européenne FR     
2.47.  CompanyA ctivityT ype 
Code indiquant une activité menée par une entrepr ise recourant à l'utilisation de sa carte d'entrepr ise. 
2.48.  CompanyCardApplicat ionIdentif ication 
Informations enregistrées sur une carte d'entrepr ise et se rappor tant à l'identif ication de l'application de la carte 
(exigen ces 369 et 375 de l'annexe 1C). 
typeOfT achog raphCardId spécifi e le type de la carte mise en application. 
cardStr uctureV ersion spécifie la version de la structure mise en œuvre au sein de la carte. 
noOfCompan yActivityRecords indique le nombre des relevés d'activité d'entrepr ise que la carte est suscept ible 
de sauvegarder . 
2.49.  CompanyCardHo lderIdentif ication 
Informations enregistrées sur une carte d'entrepr ise et se rappor tant à l'identification du détent eur de la carte 
(exigen ce 372 et 378 de l'annex e 1C). 
companyName indique le nom de l'entrepr ise du titulaire. 
companyA ddress indique l'adresse de l'entrepr ise du titulaire. 
cardHolderPreferredLan guageindique la langue de travail préfé rentielle du titulaire. 
2.50.  ControlCardApplicationIdentif ication 
Informations enregistrées sur une carte de contrôle et se rappor tant à l'identifi cation de l'application de la carte 
(exigen ces 357 et 363 de l'annexe 1C). 
typeOfT achog raphCardId spécifi e le type de la carte mise en application. 
cardStr uctureV ersion spécifie la version de la structure mise en œuvre au sein de la carte. 
noOfControlAc tivityRecords indique le nombre des relevés d'activit é d'entrepr ise que la carte est susceptible 
de sauvegarder . 26.5.2016 L 139/106 Jour nal officiel de l'Union européenne FR     
2.51.  ControlCardControlActivityDa ta 
Informations enregistrées sur une carte de contrôle et se rappor tant aux activités menées avec cette carte 
(exigen ces 361 et 367 de l'annexe 1C). 
controlPoin terNew estRecord indique l'indice du dernier relevé d'activité de contrôle actualisé par le système. 
Attr ibution de valeur: nombre correspondant au numérateur du relevé d'activit é de contrôle, commençant par 
une série de ‘0’ pour la première occur rence d'un relevé d'activit é de contrôle dans la structure considérée. 
controlActivi tyRecords indique le jeu regroupant l'ensemble des relevés d'activit é de contrôle. 
controlActivi tyRecord indique la séquence d'inf ormations associée à un contrôle. 
controlT ype indique le type de contrôle. 
controlTime indique la date et l'heure du contrôle. 
controlledCardNumber indique le numéro de la carte ainsi que l'État membre qui délivre la carte contrôlée. 
controlledV ehicleRegistration indique le VRN ainsi que l'État membre d'immatr iculation du véhicule dans 
lequel le contrôle a été exécut é. 
controlDo wnloadPeriodBegin et controlDo wnloadPerio dEnd indiquent, le cas échéant, la période 
téléc hargée. 
2.52.  ControlCardHolderIdentif ication 
Informations enregistrées sur une carte de contrôleur et se rappor tant à l'identifi cation du détenteur de la carte 
(exigen ces 360 et 366, annexe 1C). 
controlBodyName indique le nom de l'organisme de contrôle dont dépend le détenteur de la carte. 
controlBodyA ddress indique l'adresse de l'organ isme de contrôle dont dépend le détent eur de la carte. 
cardHolderName indique les nom et prénom(s) du détent eur de la carte de contrôleur . 
cardHolderPreferredLan guageindique la langue de travail préfé rentielle du titulaire. 26.5.2016 L 139/107 Jour nal officiel de l'Union européenne FR     
2.53.  ControlT ype 
Code indiquant les activités menées pendant un contrôle. Ce type de données est lié aux exigenc es 126, 274, 
299, 327 et 350 de l'annex e 1C. 
Génération 1: 
Assignation de valeur — Octet aligné: ‘cvpdxxxx’B (8 bits) 
‘c’B  card downloading: 
‘0’B: pas de téléc harg ement de la carte pendant cette activité de contrôle, 
‘1’B: téléc hargem ent de la carte pendant cette activité de contrôle. 
‘v’B  téléc harg ement de la VU: 
‘0’B: pas de téléc harg ement de la VU pendant cette activité de contrôle, 
‘1’B: téléc hargem ent de la VU pendant cette activité de contrôle. 
‘p’B  impression: 
‘0’B: pas d'impression pendant cette activité de contrôle, 
‘1’B: exécuti on d'une impression pendant cette activité de contrôle. 
‘d’B  affichage: 
‘0’B: pas d'aff ichage de données pendant cette activité de contrôle, 
‘1’B: affichage de données pendant cette activité de contrôle. 
‘xxxx’B  Inutilisé. 
Génération 2: 
Assignation de valeur — Octet aligné: ‘cvpdexxx’B (8 bits) 
‘c’B  téléc harg ement de la carte: 
‘0’B: pas de téléc harg ement de la carte pendant cette activité de contrôle, 
‘1’B: téléc hargem ent de la carte pendant cette activité de contrôle. 
‘v’B  téléc harg ement de la VU: 
‘0’B: pas de téléc harg ement de la VU pendant cette activité de contrôle, 
‘1’B: téléc hargem ent de la VU pendant cette activité de contrôle. 
‘p’B  printing: 
‘0’B: pas d'impression pendant cette activité de contrôle, 
‘1’B: exécuti on d'un tirag e pendant cette activité de contrôle. 
‘d’B  affichage: 
‘0’B: pas d'aff ichage de données pendant cette activité de contrôle, 
‘1’B: affichage de données pendant cette activité de contrôle. 26.5.2016 L 139/108 Jour nal officiel de l'Union européenne FR     
‘e’B  contrôles routiers d'étalonnag e: 
‘0’B: paramètres d'étalonnag e non vérifiés pendant cette activité de contrôle, 
‘1’B: paramètres d'étalonnag e vérifiés pendant cette activité de contrôle. 
‘xxx’B  RFU. 
2.54.  DailyPresenceCounter 
Date et heure de l'appareil de contrôle. 
Affectation de valeur : pas spécifi ée davan tage. 
2.55.  Cur rentDateTimeRecordAr ray 
Génération 2: 
L'heure et la date actuelles plus les métadonnées tels qu'utilisées dans le protocole de téléc hargem ent. 
recordT ype indique le type de relevé (Cur rentDateTim e). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des CurrentDateTim e expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records désigne un jeu de relevés de date et d'heure. 
2.56.  DailyPresenceCounter 
Comp teur enregistré sur une carte de conduct eur ou d'ate lier, incrémenté d'une unité par jour civil d'inser tion de 
cette carte dans le lecteur d'une VU. Ce type de données est lié aux exigences 266, 299, 320 et 343 de l'annex e 
1C. 
Attr ibution de valeur: numérotation consécutive dont la valeur maximale est égale à 9 999, la numérotation 
recommençant par le numéro 0. Lors de la première entrée en vigueur d'une carte, le comp teur correspondant 
est à zéro. 
2.57.  Datef 
Date expr imée dans un format numér ique immédiatement impr imable. 
26.5.2016 L 139/109 Jour nal officiel de l'Union européenne FR     
Attr ibution de valeur: 
yyyy  Année 
mm  Mois 
dd  Jour 
‘00000000’H  dénote expliciteme nt l'absence de date. 
2.58.  DateOfDa yDo wnloaded 
Génération 2: 
La date et l'heure du téléc hargement. 
Affectation de valeur : pas spécifi ée davan tage. 
2.59.  DateOfDa yDo wnloadedRecordAr ray 
Génération 2: 
L'heure et la date du téléc hargement plus les métadonnées tels qu'utilisées dans le prot ocole de téléc hargement. 
recordT ype indique le type de relevé (DateOfDa yDo wnloaded). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des CurrentDateTim e expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records désigne le jeu de date et d'heure sur les relevés de téléc hargem ents. 
2.60.  Dist ance 
Distance parcour ue (résultat du calcul de la différence entre deux valeurs affichées par le comp teur kilométr ique 
du véhicule considéré). 
Attr ibution de valeur: binaire sans signe. Valeur expr imée en km et se situant dans une plage d'exploitation 
compris e entre 0 et 9 999 km. 
2.61.  DriverCardApplicationIdentif ication 
Informations enregistrées sur une carte de conduct eur et se rappor tant à l'identif ication de l'application de la 
carte (exigen ces 253 et 278 de l'annex e 1C). 26.5.2016 L 139/110 Jour nal officiel de l'Union européenne FR     
Génération 1: 
typeOfT achog raphCardId spécifi e le type de la carte mise en application. 
cardStr uctureV ersion spécifie la version de la structure mise en œuvre au sein de la carte. 
noOfEv entsP erType indique le nombre d'événements que la carte est suscep tible de sauveg arder par type 
d'événement. 
noOfFaultsPerT ype indique le nombre d'anomalies que la carte est susceptible de sauvegarder par type 
d'anomalie. 
activityStr uctureLength indique le nombre d'oct ets susceptibles d'être affectés à l'enregistrement de relevés 
d'activit é. 
noOfCardV ehicleRecords indique le nombre des relevés de véhicule que la carte est susceptible de mémor iser. 
noOfCardPlaceRecords indique le nombre de sites que la carte est susceptible de mémor iser. 
Génération 2: 
Outre la génération 1, les éléments de données suivants sont utilisés: 
noOfGNSSCDRecords indique le nombre de relevés de conduite continue GNSS que la carte est susceptible de 
sauvegarder . 
noOfSpecif icConditionRecords indique le nombre de relevés de conditions particulières que la carte est 
susceptible de mémor iser. 
2.62.  DriverCardHolderIdentif ication 
Informations enregistrées sur une carte de conducteur et se rappor tant à l'identification du détent eur de la carte 
(exigen ces 256 et 281 de l'annexe 1C). 
cardHolderName indique les nom et prénom(s) du détent eur de la carte de conduct eur. 26.5.2016 L 139/111 Jour nal officiel de l'Union européenne FR     
cardHolderBir thDate indique la date de naissance du détenteur de la carte de conducteur . 
cardHolderPreferredLan guageindique la langue de travail préfé rentielle du titulaire. 
2.63.  DSR CSecur ityData 
Génération 2: 
Les informations de texte en clair et le MAC à transmettre via DSR C depuis le tach ygraphe vers l'Interrogat eur 
distant (IDis), cf. appendice 11, partie b, chapitre 13 pour des détails compl émentaires. 
tagL ength fait partie du codage DER -TLV et doit être défini sur ‘81 10’ (cf. appendice 11, partie B, chapit re 13). 
currentDateTime indique la date et l'heure actuelles de l'unit é embarquée sur véhicule. 
counter énumère les messages RTM. 
vuSer ialNumber indique le numéro de série de l'unité embarquée sur véhicule. 
dSR CMKV ersionNumber désigne le numéro de version de la clé maîtresse DSR C d'où découlent les clés DSR C 
propres aux VU. 
tagL engthMac désigne la balise et la longueur de l'objet informatif MAC dans le cadre du codag e DER -TLV. La 
balise doit être définie à ‘8E’, la longueur doit coder la longueur du MAC en octets (cf. appendice 11, partie B, 
chapitre 13). 
mac désigne le MAC calculé sur le message RTM (cf. appendice 11, partie B, chapitre 13). 
2.64.  EGFCer tificate 
Génération 2: 
Certificat associé à la clé publique d'un dispositif GNSS destiné à l'authentif ication mutuel avec une VU. La 
structure de ce certificat est spécifi ée dans l'appendice 11. 
2.65.  EmbedderIcAssemblerId 
Four nit les informations relatives à l'intégrateur de CI. 
26.5.2016 L 139/112 Jour nal officiel de l'Union européenne FR     
countr yCode désigne le code à deux lettres du pays où se situe l'intégrat eur du module conf ormément à la 
norme ISO 3166. 
moduleEmbedder identifie l'intégrat eur du module. 
manufacturerInfor mation concer ne l'usage intern e du fabricant. 
2.66.  Entr yTypeDailyW orkPeriod 
Code permettant de faire la distinction entre le lieu de début et de fin d'une période de travail jour nalière et les 
conditions de saisie de ces données. 
Génération 1 
Attr ibution de valeur : conf orme à la norme ISO/IEC8824-1. 
Génération 2 
Attr ibution de valeur : conf orme à la norme ISO/IEC8824-1. 
2.67.  EquipmentT ype 
Code permettant de faire la distinction entre différ ents types d'équipement pour l'application tach ygraphique. 
Génération 1: 
Attr ibution de valeur: conf ormément à la norme ISO/IEC8824-1. 
La valeur 0 est réser vée aux fins de la désignation d'un État membre ou de l'Europe dans le champ CHA des 
certificats. 26.5.2016 L 139/113 Jour nal officiel de l'Union européenne FR     
Génération 2: 
Les mêmes valeurs que pour la génération 1 servent pour les ajouts suivants: 
Remarque: les valeurs de génération 2 pour la plaque, l'adaptat eur et la connexion exte rne GNSS ainsi que les 
valeurs de génération 1 pour l'unit é embarquée sur véhicule et le capt eur de mouvement peuvent servir en 
SealRecord, le cas échéant.  
2.68.  EventFaultT ype 
Génération 1: 
Clé publique européenne. 
2.69.  EventFaultRecordPur pose 
Code indiquant la raison de l'enregistrement d'un événement ou d'une anomalie. 
Attr ibution de valeur : 
l'un des 10 (der niers) événements ou anomalies les plus récents 
l'événement le plus long survenu au cours de chacun des 10 derniers jours d'occur rence 
l'un des 5 événements les plus longs enregistrés au cours des 365 derniers jours 
le dernier événement survenu au cours de chacun des 10 derniers jours d'occur rence 
l'événement le plus sérieux enregistré au cours de chacun des 10 derniers jours d'occur rence 
l'un des 5 événements les plus sérieux enregistrés au cours des 365 derniers jours 
le premier événement ou anomalie survenu après le dernier étalonnage 
un événement ou une anomalie en cours 
RFU 
propre au fabri cant  
2.70.  EventFaultT ype 
Code caract érisant un événement ou une anomalie. 
Attr ibution de valeur : 
Génération 1: 
événements généraux 
absence d'inf ormations complé mentaires 
inser tion d'une carte non valable 
conf lit de carte 
chevau chement temporel 
conduite sans carte appropr iée 
inser tion de carte en cours de conduite 
dernière session incor rectement clôturée 
excès de vitesse 
interr uption de l'alimentation électr ique 
erreur sur les données de mouvement 
conf lit concer nant le mouvement du véhicule 
RFU 26.5.2016 L 139/114 Jour nal officiel de l'Union européenne FR     
tentatives d'attein te à la sécur ité en rappor t avec l'unité embarquée sur véhicule 
absence d'inf ormations complé mentaires 
défaut d'authentification du capt eur de mouvement 
défaut d'authentification d'une carte tachygraphique 
remplacement sans autor isation du capt eur de mouvement 
défaut d'intégrité affectant l'entrée de données sur la carte 
défaut d'intégrité affectant les données utilisat eur mémor isées 
erreur de transfer t de données internes 
ouver ture illicite d'un boîtier , 
sabotage du matériel 
RFU 
tentatives d'attein te à la sécur ité en rappor t avec le capt eur de mouvement 
absence d'inf ormations complé mentaires 
échec d'une authentification 
défaut d'intégrité affectant les données mémor isées 
erreur de transfer t de données internes 
ouver ture illicite d'un boîtier 
sabotage du matériel 
RFU 
anomalies affectant l'appareil de contrôle 
absence d'inf ormations complé mentaires 
anomalie interne affectant la VU, 
anomalie affectant l'imprimante 
anomalie affectant l'affichag e 
anomalie affectant le télécharg ement 
anomalie affectant le capteur de mouvement, 
RFU 
anomalies affectant une carte 
absence d'inf ormations complé mentaires 
RFU 
RFU 
propre au fabri cant   
Génération 2: 
Les mêmes valeurs que pour la génération 1 servent pour les ajouts suivants: 
conf lit temporel (GNSS contre l'horloge interne de la VU) 
RFU 
événements liés au GNSS 
absence d'inf ormations complé mentaires 
anomalie du récept eur du dispositif GNSS interne 
anomalie du récept eur du dispositif GNSS extern e 
anomalie de communication du dispositif GNSS externe 
aucune donnée de position du dispositif GNSS, 
détection de violation du dispositif GNSS 
expiration du certificat du dispositif GNSS externe 
RFU 
anomalies liées au module de communication à distance 
absence d'inf ormations complé mentaires 
anomalie sur le module de communication à distance 
anomalie de communication sur le module de communication à distance 
RFU 
anomalies sur l'interf ace STI 
absence d'inf ormations complé mentaires 
RFU.   
2.71.  ExtendedSealIdentif ier 
Génération 2: 
L'identif iant de scellé étendu identif ie uniquement un scellé (exigence 401, annexe 1C). 26.5.2016 L 139/115 Jour nal officiel de l'Union européenne FR     
manufacturerCode correspond au code du fabricant du scellé. 
sealIdentif ier désigne l'identifi ant du scellé, unique pour le fabr icant. 
2.72.  ExtendedSer ialNumber 
Identif ication individuelle d'un équipement. Ce numéro peut également faire office d'identif icateur de clé 
publique d'équipement. 
Génération 1: 
serialNumber indique le numéro de série de l'équipement, propre au fabricant, ainsi que le type d'équipement, 
le mois et l'année ci-après. 
monthY ear identifie le mois et l'année de fabrication (ou de l'attr ibution d'un numéro de série). 
Attr ibution de valeur: codag e BCD du mois (deux chiffres) et de l'année (les deux derniers chiffres). 
type est un identif icateur du type d'équipement utilisé. 
Attr ibution de valeur: propre au fabricant, la valeur ‘FFh’ étant réser vée. 
manufacturerCode: désigne le code numér ique identifiant un fabricant d'appareil homologué. 
Génération 2: 
serialNumber cf. génération 1 
monthY ear cf. génération 1 
type indique le type d'équipement. 
monthY ear cf. génération 1 
2.73.  FullCardNumber 
Code permettant d'identifier avec certitude une carte tach ygraphique. 26.5.2016 L 139/116 Jour nal officiel de l'Union européenne FR     
cardT ype indique le type de la carte tach ygraphique. 
cardIssuingMemberStat e indique le code de l'État membre qui a délivré la carte considérée. 
cardNumber indique le numéro de la carte. 
2.74.  FullCardNumberAndGeneration 
Génération 2: 
Code permettant d'identifier avec certitude une carte tach ygraphique et sa génération. 
fullCardNumber identif ie la carte tach ygraphique. 
generation indique la génération de carte tach ygraphique utilisée. 
2.75.  Generation 
Génération 2: 
Indique la génération de tach ygraphe utilisé. 
Attr ibution de valeur : 
‘00’H  RFU 
‘01’H  Génération 1 
‘02’H  Génération 2 
‘03’H .. ‘FF’H  RFU 
2.76.  GeoCoordinates 
Génération 2: 
Les coordonnées longitudinales et latitudinales sont codées sous forme de valeurs entières. Ces valeurs entières 
sont des multiples du codag e ± DDMM.M pour la latitude et du codag e ± DDDMM.M pour la longitude. Les 
codag es ± DD et ± DDD indiquent respectivement les degrés et MM.M, les minut es. 
la latitude est codée comme un multiple (fact eur 10) de la représentation ± DDMM.M. 
longitude est codée comme un multiple (fact eur 10) de la représentation ± DDDMM.M. 26.5.2016 L 139/117 Jour nal officiel de l'Union européenne FR     
2.77.  GNSSA ccuracy 
Génération 2: 
Exactitude des données de position du dispositif GNSS (définition eee). Cette exactitude est codée sous la forme 
d'une valeur entière et est un multiple (fact eur 10) de la valeur X.Y fournie par la phrase GSA NMEA. 
2.78.  GNSSContinuousDr iving 
Génération 2: 
Informations enregistrées sur une carte de conduct eur ou d'ateli er, relatives à la position GNSS du véhicule 
lorsque le temps de conduite continue du conducteur atteint un multiple de trois heures (exigen ces 306 et 354, 
Annex 1C). 
gnssCDPoin terNew estRecord désigne l'indice du dernier relevé de conduit e continue GNSS actualisé par le 
système. 
Attr ibution de valeur: nombre correspondant au numérateur du relevé de conduite continue GNSS, 
commençant par une série de ‘0’ pour la première occur rence d'un relevé de conduite continue GNSS dans la 
structure considérée. 
gnssContinuousDr ivingRecords désigne le jeu de relevés conte nant la date et l'heure lorsque la conduite 
continue atteint un multiple de trois heures, ainsi que les informations relatives à la position du véhicule. 
2.79.  GNSSContinuousDr ivingRecord 
Génération 2: 
Informations enregistrées sur une carte de conduct eur ou d'ateli er, relatives à la position GNSS du véhicule 
lorsque le temps de conduite continue du conducteur atteint un multiple de trois heures (exigen ces 305 et 353, 
Annex e 1C). 
timeSt amp désigne la date et l'heure lorsque le temps de conduite continue du détent eur de la carte atteint un 
multiple de trois heures. 
gnssPlaceRecord contient les informations relatives à la position du véhicule. 
2.80.  GNSSPlaceRecord 
Génération 2: 
informations relatives à la position GNSS du véhicule (exigen ces 108, 109, 110, 296, 305, 347 et 353, 
annexe 1C). 
26.5.2016 L 139/118 Jour nal officiel de l'Union européenne FR     
timeSt amp indique la date et l'heure à laquelle la position GNSS du véhicule a été déterminée. 
gnssAccu racy précise le degré d'exactitude des données de position GNSS. 
geoCoordinates indique l'em placement enregistré à l'aide du dispositif GNSS. 
2.81.  HighResOdometer 
Valeur affichée par le comp teur kilométr ique du véhicule: distance totale parcour ue par le véhicule en cours 
d'exploitation. 
Attr ibution de valeur : binaire sans signe. Valeur expr imée en 1/200 de km et se situant dans une plage 
d'exploitation compris e entre 0 et 21 055 406 km. 
2.82.  HighResT ripDist ance 
Distance parcour ue pendant tout ou partie d'un trajet. 
Attr ibution de valeur : binaire sans signe. Valeur expr imée en 1/200 de km et se situant dans une plage 
d'exploitation compris e entre 0 et 21 055 406 km. 
2.83.  HolderName 
Nom et prénom(s) d'un détent eur de carte. 
holderSur name indique le nom du titulaire. Ce nom ne s'accompagne d'aucun titre. 
Attr ibution de valeur: si la carte considérée n'est pas individuelle, holderSur name contient les mêmes données 
que compan yName, workshopName ou controlBodyName. 
holderFir stNames indique le(s) prénom(s) et initiale(s) du titulaire. 
2.84.  Inter nalGNSSReceiv er 
Génération 2: 
Informations définissant si le récept eur GNSS est interne ou exte rne à l'unité embarquée sur le véhicule. Vrai 
signif ie que le récep teur GNSS est interne à la VU. Faux signif ie que le récep teur GNSS est exte rne. 
2.85.  K-Cons tantOfRecordingEquipment 
Constante de l'appareil de contrôle (définition m). 
Attr ibution de valeur: impulsions par kilomètre dans une plage d'exploitation compris e entre 0 et 
64 255 imp/km. 26.5.2016 L 139/119 Jour nal officiel de l'Union européenne FR     
2.86.  KeyIdent ifier 
Identif icateur unique d'une clé publique permettant de la désigner et de la sélectionner . Cet identif icateur identif ie 
également le titulaire de la clé. 
La première option permet de désigner la clé publique d'une unité embarquée sur véhicule ou d'une carte 
tach ygraphique. 
La seconde option permet de désigner la clé publique d'une unité embarquée sur véhicule (en cas de 
méconnaissance du numéro de série de l'unit é embarquée, lors de l'élaboration du certificat). 
La troisième option permet de désigner la clé publique d'un État membre. 
2.87.  KMW CKey 
Génération 2: 
Clé AES et version de clé associée utilisée pour la VU: couplage du capt eur de mouvement. Pour tout détail 
compl émentaire, cf. appendice 11. 
kMW CKey désigne la longueur de la clé AES concaté née avec la clé servant à la VU: couplag e du capt eur de 
mouvement. 
keyVersion indique la version clé de la clé AES. 
2.88.  Language 
Code identifiant une langue de travail. 
Attr ibution de valeur: code compo sé de deux lettres minuscules, en conf ormité avec la norme ISO 639. 
2.89.  Last CardDo wnload 
Date et heure, enregistrées sur une carte de conducteur , du dernier téléc hargement d'une carte (à d'autres fins 
que le contrôle) (exigen ces 257 et 282, annexe 1C). Cette date peut être mise à jour par une VU ou tout lecteur 
de carte. 
Affectation de valeur : pas spécifi ée davan tage. 
2.90.  LinkCer tificate 
Génération 2: 
Certificat du lien entre les clés couplées conf ormément à l'aut orité de certification racine européenne. 
26.5.2016 L 139/120 Jour nal officiel de l'Union européenne FR     
2.91.  L-TyreCircumference 
Circonfé rence effective des pneumatiques (définition u). 
Attr ibution de valeur: valeur expr imée en 1/8 de mm et se situant dans une plage d'exploitation comprise 
entre 0 et 8 031 mm. 
2.92.  MA C 
Génération 2: 
Un total de contrôle cryptographique sur une longueur de 8, 12 ou 16 octets correspondant à des suites 
chiffrées spécifi ées dans l'appendice 11. 
2.93.  ManualInputFlag 
Code permettant d'identif ier si un détent eur de carte a procédé ou non à la saisie manuelle d'activit és du 
conducteur lors de l'inser tion de cette carte (exigen ce 081, annexe 1B. exigenc e 102, annexe 1C). 
Affectation de valeur : pas spécifi ée davan tage. 
2.94.  ManufacturerCode 
Code identifiant un fabricant d'appareil homologué. 
Le laborat oire chargé des essais d'inter opérabilité maintient à jour et publie la liste des codes de fabricants sur 
son site web (exigen ce 454, annexe 1C). 
Les numéros Manufact urerCodes sont provisoirement attribués aux concept eurs de tach ygraphes sur demande 
auprès du laboratoire chargé des essais d'inter opérabilité. 
2.95.  ManufacturerSpecif icEv entFaultData 
Génération 2: 
Codes d'erreurs propres au fabr icant simplifiant l'analyse des erreurs et la maintenance des unités embarquées sur 
les véhicules. 
26.5.2016 L 139/121 Jour nal officiel de l'Union européenne FR     
manufacturerCode identif ie le fabricant de l'unit é embarquée sur véhicule. 
manufacturerSpecif icEr rorCode est un code d'erreur propre au fabricant. 
2.96.  MemberSta tePublicKe y 
Certificat de la clé publique d'un État membre délivré par l'organisme de certification européen. 
2.97.  MemberSta teCer tificateRecordAr ray 
Génération 2: 
Certificat de l'État membre plus les métadonnées tels qu'utilisés dans le protocole de téléc hargem ent. 
recordT ype indique le type de relevé (MemberStateCer tificate). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des MemberStat eCer tificate expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis . La valeur doit être définie sur 1, car les 
certificats peuvent présent er des longueurs variables. 
records désigne le jeu de certificats des États membres. 
2.98.  MemberSta tePublicKe y 
Génération 1: 
Clé publique d'un État membre. 
2.99.  Name 
Un nom. 
codePage spécifie un jeu de caractères défini au chapitre 4, 
name indique un nom encodé à l'aide du jeu de caractères spécif ié. 26.5.2016 L 139/122 Jour nal officiel de l'Union européenne FR     
2.100.  NationAlpha 
Renv oi alphabétique à un pays conf ormément aux signes distinctifs apposés sur les véhicules en circulation 
internati onale (Con vention de Vienne sur la circulation routière, Nations unies, 1968). 
Les codes NationAlpha et NationNumer ic sont consignés sur une liste maintenue à jour sur le site web du 
laboratoire désigné pour effectuer les essais d'interopérabilit é en vertu de l'exigence 440, annexe 1C. 
2.101.  Code numér ique national 
Code numér ique désignant un pays. 
Attr ibution de valeur : voir le type de données 2.100 (NationAlpha). 
Toute modifi cation ou mise à jour des spécifi cations NationAlpha ou NationNumer ic ne peut inter venir qu'après 
consultation, par le laborat oire désigné, des fabricants d'unité s embarquées de tach ygraphe numér ique et 
intellig ent homologuées. 
2.102.  NoOfCalibrationsSinceDo wnload 
Nombre des relevés d'étalonnag e qu'une carte d'atelier est suscept ible de mémor iser. 
Génération 1: 
Attr ibution de valeur : cf. appendice 2. 
Génération 2: 
Attr ibution de valeur : cf. appendice 2. 
2.103.  NoOfCalibrationsSinceDo wnload 
Comp teur indiquant le nombre d'étalonnag es exécut és avec une carte d'atelier depuis son dernier téléc hargement 
(exigen ce 317 et 340, annexe 1C). 
Attr ibution de valeur: absence d'inf ormations compl émentaires. 
2.104.  NoOfCardPlaceRecords 
Nombre des relevés de site qu'une carte de conduct eur ou d'atelier est suscept ible de mémor iser. 
Génération 1: 
Attr ibution de valeur : cf. appendice 2. 
Génération 2: 
Attr ibution de valeur : cf. appendice 2. 26.5.2016 L 139/123 Jour nal officiel de l'Union européenne FR     
2.105.  NoOfCardV ehicleRecords 
Nombre des relevés de véhicule qu'une carte de conduct eur ou d'atelier est susceptible de mémor iser. 
Attr ibution de valeur : cf. appendice 2. 
2.106.  NoOfCardV ehicleUnitRecords 
Génération 2: 
Nombre de relevés utilisés par les unités embarquées sur le véhicule qu'une carte de conducteur ou d'atelier est 
susceptible de mémor iser. 
Attr ibution de valeur : cf. appendice 2. 
2.107.  NoOfControlActivityRe cords 
Nombre des relevés d'activit é d'entrepr ise qu'une carte d'entrepr ise est susceptible de mémor iser. 
Attr ibution de valeur : cf. appendice 2. 
2.108.  NoOfEv entsPerT ype 
Nombre des relevés d'activit é de contrôle qu'une carte de contrôleur est susceptible de mémor iser. 
Attr ibution de valeur : cf. appendice 2. 
2.109.  NoOfEv entsPerT ype 
Nombre d'événements qu'une carte est susceptible de mémor iser par type d'événement. 
Attr ibution de valeur : cf. appendice 2 
2.110.  NoOfFaultsPerT ype 
Nombre d'anomalies qu'une carte est suscept ible de mémor iser par type d'anomalie. 
Attr ibution de valeur : cf. appendice 2 
2.111.  NoOfGNSSCDRecords 
Génération 2: 
Nombre de relevés de conduite continue GNSS que la carte est susceptible de sauveg arder . 
Attr ibution de valeur : cf. appendice 2 26.5.2016 L 139/124 Jour nal officiel de l'Union européenne FR     
2.112.  NoOfSpecif icConditionRecords 
Génération 2: 
Nombre de relevés de conditions particulières qu'une carte est suscep tible de mémor iser. 
Attr ibution de valeur : cf. appendice 2 
2.113.  OdometerShor t 
Valeur affichée par le comp teur kilométr ique du véhicule sous une forme abrég ée. 
Attr ibution de valeur: binaire sans signe. Valeur expr imée en km et se situant dans une plage d'exploitation 
compris e entre 0 et 9 999 999 km. 
2.114.  OdometerV alueMidnight 
Valeur affichée par le comp teur kilométr ique du véhicule à minuit un jour donné (exigence 090, annexe 1B; 
exigenc e 113, annexe 1C). 
Affectation de valeur : pas spécifi ée davan tage. 
2.115.  OdometerV alueMidnightRecordAr ray 
Génération 2: 
Odomet erValueMidnight plus les métadonnées tels qu'utilisés dans le protocole de téléc hargement. 
recordT ype indique le type de relevé (OdometerV alueMidnight). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des Odomet erValueMidnight expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records désigne le jeu de relevés de Odomet erValueMidnight. 
2.116.  OverspeedNumber 
Nombre d'événements du type excès de vitesse survenus depuis le dernier contrôle d'excès de vitesse. 
Attr ibution de valeur : 0 signifie qu'aucun événement du type excès de vitesse n'est survenu depuis le dernier 
contrôle d'excès de vitesse, 1 signifie qu'un événement du type excè s de vitesse est survenu depuis le dernier 
contrôle d'excès de vitess e … 255 signif ie que le nombre des événements du type excè s de vitesse enregistrés 
depuis le dernier contrôle d'excès de vitesse est égal ou supér ieur à 255. 26.5.2016 L 139/125 Jour nal officiel de l'Union européenne FR     
2.117.  PlaceRecord 
Informations relatives à un lieu de début ou de fin d'une période de travail jour nalière (exigen ces 108, 271, 296, 
324 et 347, annexe 1C). 
Génération 1: 
entr yTime indique la date et l'heure de la saisie des données. 
entr yTypeDailyW orkPeriod indique le type d'entrée. 
dailyW orkPeriod Countr y indique le pays entré. 
dailyW orkPeriod Region indique la région entrée. 
vehicleOdometerV alue indique la valeur affichée par le comp teur kilométr ique à l'heure de la saisie du lieu 
entré. 
Génération 2: 
Outre la génération 1, les compo sants suivants servent: 
entr yGNSSPlaceRecord désigne le lieu et l'heure enregistrés. 
2.118.  PreviousV ehicleInfo 
Informations relatives au véhicule précédemment utilisé par un conduct eur lors de l'inser tion de sa carte dans le 
lecteur d'une unité embarquée sur véhicule (exigence 081, annexe 1B; exigence 102, annexe 1C). 
Génération 1: 
vehicleRegist rationIdentif ication indique le VRN ainsi que l'État membre d'immatr iculation du véhicule. 
cardWithdrawa lTime indique la date et l'heure de retrait de la carte. 
Génération 2: 
26.5.2016 L 139/126 Jour nal officiel de l'Union européenne FR     
Outre la génération 1, l'élément de données suivant est utilisé: 
vuGeneration identifie la génération de l'unité embarquée sur véhicule. 
2.119.  PublicKey 
Génération 1: 
Clé publique RSA. 
rsaKeyMod ulus indique le module de la paire de clés. 
rsaKeyPu blicExponent indique l'exposant public de la paire de clés. 
2.120.  RecordT ype 
Génération 2: 
Référence à un type de relevé. Ce type de données sert au RecordAr rays. 
Attr ibution de valeur : 
ActivityChangeI nfo, 
CardSlotsStatus, 
CurrentDateTime, 
MemberStateCer tificate, 
OdometerV alueMidnight, 
DateOfD ayDo wnloaded, 
SensorPaired, 
Signature, 
Specific ConditionRecord, 
VehicleIdentif icationNumber , 
VehicleRegistrationNumber , 
VuCalibrationRecord, 
VuCardIWRecord, 
VuCardRecord, 
VuCer tificate, 
VuCom panyLoc ksRe cord, 
VuControlA ctivityRecord, 
VuDetailedSpeedBlock, 
VuDo wnloadableP eriod, 
VuDo wnloadA ctivityData, 
VuEventRecord, 
VuGNSSCDRecord, 
VuITSConsentRecord, 
VuFaultRecord, 
VuIdentification, 
VuOverSpeedingControlData, 
VuOverSpeedingEventRecord, 
VuPlaceDailyW orkP eriodRecord, 
VuTimeA djustmentGNSSRecord, 
VuTimeA djustmentRecord, 
VuPowerSupplyInter ruptionRecord, 
SensorPairedRecord, 
SensorExternalGNSSC oupledRecord, 
RFU, 
propre au fabri cant  26.5.2016 L 139/127 Jour nal officiel de l'Union européenne FR     
2.121.  RegionAlpha 
Référence alphabétique aux différ entes régions d'un pays déterminé. 
Génération 1: 
Attr ibution de valeur : 
Génération 2: 
Les codes RegionAlpha sont consignés sur une liste maint enue à jour sur le site web du laborat oire désigné pour 
effectuer les essais d'interopérabilit é. 
2.122.  Assignation de valeur : 
Référence alphabétique aux différ entes régions d'un pays déterminé. 
Génération 1: 
Attr ibution de valeur : 
26.5.2016 L 139/128 Jour nal officiel de l'Union européenne FR     
Génération 2: 
Les codes RegionNumer ic sont consignés sur une liste maintenue à jour sur le site web du laboratoire désigné 
pour effectuer les essais d'inter opérabilité. 
2.123.  RemoteCommunicationModuleSer ialNumber 
Génération 2: 
Numéro de série du module de communication à distance. 
2.124.  RSAKe yModulus 
Génération 1: 
Module d'une paire de clés RSA. 
Attr ibution de valeur: Non-spécifié. 
2.125.  RSAKe yPublicExponent 
Génération 1: 
Exposant privé d'une paire de clés RSA. 
Attr ibution de valeur: Non-spécifié. 
2.126.  RSAKe yPublicExponent 
Génération 1: 
Exposant public d'une paire de clés RSA. 
Attr ibution de valeur: Non-spécifié. 
2.127.  RtmDat a 
Génération 2: 
Pour la définit ion de ce type de données, cf. appendice 14. 
2.128.  SealDat aCard 
Génération 2: 
Ce type de données stoc ke les informations concer nant les scellés liés aux différ ents compo sants d'un véhicule 
sur une carte. Ce type de données est lié à l'exigence 337, annexe 1C. 26.5.2016 L 139/129 Jour nal officiel de l'Union européenne FR     
noOfSealRecords désigne le nombre de relevés dans sealRecords. 
sealRecords indique un jeu de relevés de scellés. 
2.129.  SealDat aVu 
Génération 2: 
Ce type de données stoc ke les informations concer nant les scellés liés aux différ ents compo sants d'un véhicule 
sur une unité embarquée sur le véhicule. 
sealRecords indique un jeu de relevés de scellés. S'il existe moins de 5 scellés disponibles, la valeur du type 
d'équipement dans tous les relevés de scellés inutilisés doit être définie sur 16, c'est-à-dire inutilisé. 
2.130.  SealRecord 
Génération 2: 
Ce type de données stoc ke des informations à propos d'un scellé lié au composant. Ce type de données est lié à 
l'exige nce 337, annexe 1C. 
equipmentT ype identif ie le type d'équipement auquel le scellé est associé. 
extendedSealIdentif ier désigne l'identifi cateur du scellé associé à l'équipement concer né. 
2.131.  SensorAppro valNumber 
Numéro d'homologation du capt eur. 
Génération 1: 
Attr ibution de valeur: Non-spécifié. 
Génération 2: 
Attr ibution de valeur : 
Le numéro d'homologation doit être fourni tel que publié par le site Internet de la Commission européenne 
correspondant, à savoir en incluant les traits d'union, par exem ple. Le numéro d'homologat ion doit être aligné à 
gauc he. 26.5.2016 L 139/130 Jour nal officiel de l'Union européenne FR     
2.132.  SensorExter nalGNSSA ppro valNumber 
Génération 2: 
Numéro d'homologation du dispositif GNSS extern e. 
Attr ibution de valeur : 
Le numéro d'homologation doit être fourni tel que publié par le site Internet de la Commission européenne 
correspondant, à savoir en incluant les traits d'union, par exem ple. Le numéro d'homologat ion doit être aligné à 
gauc he. 
2.133.  SensorExter nalGNSSCoupledRecord 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant à l'identif ication 
du dispositif GNSS externe couplé avec cette unité embarquée (exigence 100, annexe 1C). 
sensorSer ialNumber désigne le numéro de série du dispositif GNSS externe appairé à l'unité embarquée sur le 
véhicule. 
sensorAppro valNumber désigne le numéro d'homolog ation de ce dispositif GNSS externe. 
sensorCouplingDate indique la date de l'appar iement entre ce dispositif GNSS externe avec l'unité embarquée 
sur véhicule. 
2.134.  SensorExter nalGNSSIdentif ication 
Génération 2: 
Informations se rappor tant à l'identif ication du dispositif GNSS exte rne (exigence 98, annexe 1C). 
sensorSer ialNumber désigne le numéro de série étendu du dispositif GNSS externe. 
sensorAppro valNumber désigne le numéro d'homolog ation du dispositif GNSS exte rne. 
sensorSCIdentif ier indique l'identif icateur du compo sant de sécur ité du dispositif GNSS externe. 
sensorOSIdentif ier indique l'identifi cateur du système d'exploitation du dispositif GNSS externe. 26.5.2016 L 139/131 Jour nal officiel de l'Union européenne FR     
2.135.  SensorExter nalGNSSInst allation 
Génération 2: 
Informations mémor isées dans le dispositif GNSS externe se rappor tant à l'installation du capt eur GNSS externe 
(exigen ce 123, annexe 1C). 
sensorCouplingDateFir st indique la date du premier couplage entre une unité embarquée sur véhicule et le 
dispositif GNSS exte rne. 
firstV uAppro valNumber indique le numéro d'homologation de la première unité embarquée sur véhicule 
couplée avec le dispositif GNSS externe. 
firstV uSer ialNumber indique le numéro de série de la première unité embarquée sur véhicule couplée avec le 
dispositif GNSS exte rne. 
sensorCouplingDateCur rent indique la date du couplag e actuel entre l'unit é embarquée sur véhicule et le 
dispositif GNSS exte rne. 
currentV uAppro valNumber désigne le numéro d'homolog ation de l'unité embarquée sur le véhicule 
actuellement couplée avec le dispositif GNSS externe. 
currentVUSer ialNumber désigne le numéro de série de l'unité embarquée sur le véhicule actuellement couplée 
avec le dispositif GNSS extern e. 
2.136.  SensorExter nalGNSSOSIdentif ier 
Génération 2: 
Identif icateur du système d'exploitation du dispositif GNSS exte rne. 
Attribution de valeur: propre au fabricant. 
2.137.  SensorExter nalGNSSSCIdentif ier 
Génération 2: 
Ce type sert p. ex. à identif ier le module cryptographique du dispositif GNSS extern e. 
Identif icateur du compo sant de sécur ité du dispositif GNSS externe. 
Attr ibution de valeur : propre au fabricant. 26.5.2016 L 139/132 Jour nal officiel de l'Union européenne FR     
2.138.  SensorGNSSCouplingDate 
Génération 2: 
Date d'un couplage entre une unité embarquée sur véhicule et le dispositif GNSS extern e. 
Attr ibution de valeur: Non-spécifié. 
2.139.  SensorGNSSSer ialNumber 
Génération 2: 
Ce type sert à stoc ker le numéro de série du récept eur GNSS situé à l'intér ieur ou à l'ext érieur de la VU. 
Numéro de série du récep teur GNSS. 
2.140.  SensorIdentif ication 
Informations enregistrées dans la mémoire d'un capt eur de mouvement et se rappor tant à l'identifi cation de cet 
élément (exigence 077, annex e 1B et exigence 95, annexe 1C). 
sensorSer ialNumber indique le numéro de série étendu du capt eur de mouvement (numéro de pièce et code du 
fabricant inclus). 
sensorAppro valNumber indique le numéro d'homologation du capt eur de mouvement. 
sensorSCIdentif ier indique l'identif icateur du compo sant de sécur ité du capt eur de mouvement. 
sensorOSIdentif ier indique l'identifi cateur du système d'exploitation du capt eur de mouvement. 
2.141.  SensorInst allation 
Informations enregistrées dans la mémoire d'un capt eur de mouvement et se rappor tant à l'installation de cet 
élément (exigence 099, annex e 1B et exigence 122, annexe 1C). 
sensorPair ingDateF irst indique la date du premier couplage du capt eur de mouvement avec une unité 
embarquée sur véhicule. 
firstV uAppro valNumber indique le numéro d'homologation de la première unité embarquée sur véhicule 
couplée avec le capt eur de mouvement. 26.5.2016 L 139/133 Jour nal officiel de l'Union européenne FR     
firstV uSer ialNumber indique le numéro de série de la première unité embarquée sur véhicule couplée avec le 
capt eur de mouvement. 
sensorPair ingDateCur rent indique la date du couplage actuel du capt eur de mouvement avec l'unité embarquée 
sur véhicule. 
currentV uAppro valNumber indique le numéro d'homolog ation de l'unit é sur véhicule actuellement couplée 
avec le capt eur de mouvement. 
currentVUSer ialNumber indique le numéro de série de l'unit é sur véhicule actuellement couplée avec le 
capt eur de mouvement. 
2.142.  SensorInst allationSecData 
Informations enregistrées sur une carte d'ate lier et se rappor tant aux données de sécur ité nécessaires au couplage 
de capt eurs de mouvement avec des unités embarquées sur véhicule (exigen ces 308 et 331, annexe 1C). 
Génération 1: 
Attr ibution de valeur: conf orme à la norme ISO 16844-3. 
Génération 2: 
Comme décr it dans l'appendice 11, une carte d'ateli er doit mémor iser jusqu'à trois clés pour le couplage du 
capt eur de mouvement situé sur la VU. Ces clés existent en différent es versions. 
2.143.  SensorOSIdentif ier 
Identif icateur du système d'exploitation du capt eur de mouvement. 
Attribution de valeur: propre au fabricant. 
2.144.  SensorPaired 
Génération 1: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant à l'identif ication 
du capt eur de mouvement couplé avec cette unité embarquée (exigence 079, annexe 1B). 
sensorSer ialNumber indique le numéro de série du capt eur de mouvement actuellement couplé avec l'unit é 
embarquée sur véhicule. 
sensorAppro valNumber indique le numéro d'homologa tion du capt eur de mouvement actuellement couplé 
avec l'unité embarquée sur véhicule. 
sensorPair ingDateF irst indique la date du premier couplage entre une unité sur véhicule et le capt eur de 
mouvement actuellement couplé avec l'unit é embarquée sur le véhicule considéré. 26.5.2016 L 139/134 Jour nal officiel de l'Union européenne FR     
2.145.  SensorPairedRecord 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant à l'identif ication 
du capt eur de mouvement couplé avec cette unité embarquée (exigence 97, annexe 1C). 
sensorSer ialNumber indique le numéro de série du capt eur de mouvement actuellement couplé avec l'unit é 
embarquée sur véhicule. 
sensorAppro valNumber indique le numéro d'homologation du capt eur de mouvement. 
sensorPair ingDate indique une date d'appar iement du capt eur de mouvement avec l'unité embarquée sur 
véhicule. 
2.146.  SensorPair ingDate 
Date d'un couplage du capt eur de mouvement avec une unité embarquée sur véhicule. 
Attr ibution de valeur: Non-spécifié. 
2.147.  SensorSCIdentif ier 
Identif icateur du compo sant de sécur ité du capt eur de mouvement. 
Attr ibution de valeur : propre au fabricant. 
2.148.  SensorSer ialNumber 
Numéro de série du capt eur de mouvement. 
2.149.  Signature 
Signature numér ique. 
Génération 1: 
Attr ibution de valeur: en conf ormité avec l'appendice 11 (Mécanismes de sécur ité communs). 
Génération 2: 
Attr ibution de valeur: en conf ormité avec l'appendice 11 (Mécanismes de sécur ité communs). 26.5.2016 L 139/135 Jour nal officiel de l'Union européenne FR     
2.150.  SignatureRecordAr ray 
Génération 2: 
Jeu de signatures plus les métadonnées servant au protocole de téléc hargem ent. 
recordT ype indique le type de relevé (Signature). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des signatures expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis . La valeur doit être définie sur 1, car les 
signatures peuvent présent er des longueurs variables. 
records indique le jeu de relevés de signatures. 
2.151.  SimilarEv entsNumber 
Nombre d'événements similaires survenus un jour donné (exigen ce 094, annexe 1B; exigenc e 117, annexe 1C). 
Attr ibution de valeur : 0 n'est pas utilisé, 1 signifie qu'un seul événement de ce type s'est produit et a été 
enregistré le jour considéré, 2 signif ie que deux événements de ce type se sont produits le jour considéré (et un 
seul d'entre eux a été enregistré), … 255 signif ie que le jour considéré a vu la manifestat ion d'un nombre 
d'événements de ce type égal ou supér ieur à 255. 
2.152.  Specif icConditionRecord 
Informations enregistrées sur une carte de conduct eur, une carte d'atelier ou une unité embarquée sur véhicule et 
se rappor tant à une condition particulière (exigen ces 130, 276, 301, 328 et 355, annexe 1C). 
entr yTime indique la date et l'heure d'entrée de ces données. 
specif icCondition Type indique le code identif iant la condition particulière concer née. 
2.153.  Specif icConditions 
Informations enregistrées sur une carte de conduct eur, une carte d'atelier ou une unité embarquée sur véhicule et 
se rappor tant à une condition particulière (exigen ces 131, 277, 302, 329 et 356, annexe 1C). 
Génération 2: 
26.5.2016 L 139/136 Jour nal officiel de l'Union européenne FR     
conditionPoi nterNew estR ecord indique l'indice du dernier relevé de conditions particulières mis à jour . 
Attr ibution de valeur: nombre correspondant au numérat eur du relevé de conditions particulières, 
commençant par une série de ‘0’ pour la première occur rence d'un relevé de conditions particulières dans la 
structure considérée. 
specif icConditionRecords indique le jeu de relevés cont enant des informations relatives à des conditions 
particulières. 
2.154.  Specif icCondition Type 
Code identif iant une condition particulière (exigen ces 050b, 105a, 212a et 230a, annexe 1B; exigenc es 62, 
annexe 1C). 
Génération 1: 
Attr ibution de valeur : 
‘00’H  RFU 
‘01’H  Hors cham p — Début 
‘02’H  Hors cham p — Fin 
‘03’H  Trajet en ferry/train 
‘04’H .. ‘FF’H  RFU 
Génération 2: 
Attr ibution de valeur : 
‘00’H  RFU 
‘01’H  Hors cham p — Début 
‘02’H  Hors cham p — Fin 
‘03’H  Trajet en ferry/train — Début 
‘04’'H  Trajet en ferry/train — Fin 
‘05’H .. ‘FF’H  RFU 
2.155.  Speed 
Vites se du véhicule (km/h). 
Attr ibution de valeur: kilomètres à l'heure dans une plage d'exploitation compris e entre 0 et 220 km/h. 
2.156.  SpeedAuthor ised 
Vites se maximale autor isée du véhicule (définition hh). 
26.5.2016 L 139/137 Jour nal officiel de l'Union européenne FR     
2.157.  SpeedA verage 
Vites se moyenne mesurée par rappor t à une durée préalablement définie (km/h). 
2.158.  SpeedMax 
Vites se maximale mesurée pendant une durée préalablement définie. 
2.159.  Tachog raphPayload 
Génération 2: 
Pour la définit ion de ce type de données, cf. appendice 14. 
2.160.  Tachog raphPayloadEncr ypted 
Génération 2: 
La charg e du tach ygraphe codée DER -TLV, c'est-à-dire les données codées envoyées dans le message RTM. 
Concer nant le mécanisme de cryptage, cf. appendice 11 partie B chapitre 13. 
tag fait partie du codage DER -TLV et doit être défini sur ‘87’ (cf. appendice 11, partie B, chapitre 13). 
length fait partie du codage DER -TLV et doit coder la longueur de l'octet indicateur de contenu de rem plissage 
suivant ainsi que les données codées. 
paddingContentIndicatorB yte doit être défini sur ‘00’. 
encr yptedDat a désigne la charg e de tach ygraphe codée comme le précise l'appendice 11, partie B, chapitre 13. 
La longueur de ces données expr imée en octets doit toujours être un multiple de 16. 
2.161.  TDesSessionKey 
Génération 1: 
Clé de session Triple DES. 
Affectation de valeur : pas spécifi ée davan tage. 26.5.2016 L 139/138 Jour nal officiel de l'Union européenne FR     
2.162.  TimeReal 
Code associé à un champ combinant date et heure expr imées en secondes à comp ter de 00h00m00s TUC le 1er 
janv ier 1970. 
Assignation de valeur — Octet aligné: nombre de secondes écoulées depuis minuit TUC, le 1er janvier 1970. 
La date/heur e future la plus avancée se situe en l'an 2106. 
2.163.  TyreSize 
Désignation des dimensions des pneumatiques. 
Assignation de valeur: en conf ormité avec la directive 92/23/CEE du 31.3.1992 (JO L 129, p. 95). 
2.164.  VehicleIdentif icationNumber 
Numéro d'identif ication du véhicule (VIN) faisant référence au véhicule dans son entier ; il s'agit habituellement 
du numéro de série du châssis ou du numéro de cadre. 
Attr ibution de valeur: conf ormément à la norme ISO 3779. 
2.165.  VehicleIdentif icationNumberRecordAr ray 
Génération 2: 
Numéro d'identif ication du véhicule plus les métadonnées tels qu'utilisés dans le prot ocole de télécharg ement. 
recordT ype indique le type de relevé (VehicleIdentif icationNumber). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des VehicleIdentif icationNumber expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records désigne le jeu des numéros d'identif ication des véhicules. 
2.166.  VehicleRegist rationIdentif ication 
Identif ication d'un véhicule, unique à l'éch elle de l'Europe (VIN et État membre). 26.5.2016 L 139/139 Jour nal officiel de l'Union européenne FR     
vehicleRegist rationNation indique le pays d'immatr iculation du véhicule. 
vehicleRegist rationNumber indique le numéro d'immatr iculation du véhicule (VRN). 
2.167.  Numéro d'immatr iculation du véhicule 
Numéro d'immatr iculation du véhicule (VRN). Le numéro d'immatr iculation est attribué par l'aut orité 
compét ente en matière d'immatr iculation des véhicules. 
codePage spécifie un jeu de caractères défini au chapitre 4, 
vehicleRegNumber indique un VRN encodé à l'aide du jeu de caractères spécifi é. 
Attr ibution de valeur: propre à chaque pays. 
2.168.  VehicleRegist rationNumberRecordAr ray 
Génération 2: 
Immatr iculation du véhicule plus les métadonnées tels qu'utilisées dans le prot ocole de télécharg ement. 
recordT ype indique le type de relevé (VehicleRegistrationNumber). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des VehicleRegistrationNumber expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records désigne le jeu des immatr iculations des véhicules. 
2.169.  VuAbility 
Génération 2: 
Informations stoc kées dans une VU concer nant sa capacit é à utiliser des cartes tach ygraphiques de génération 1 
(exigen ce 121, annexe 1C). 
Assignation de valeur — Octet aligné: ‘xxxxxxxa’B (8 octets) 26.5.2016 L 139/140 Jour nal officiel de l'Union européenne FR     
Pour la compati bilité avec la génération 1: 
‘a’B  Compatibilit é avec les cartes tach ygraphiques de génération 1: 
‘0’ B, compati ble avec la génération 1, 
‘1’ B, incompat ible avec la génération1, 
‘xxxxxxx’B  RFU 
2.170.  VuActivityDailyData 
Génération 1: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux change ments 
d'activit é ainsi qu'aux changem ents d'état de conduite et/ou d'état de carte pour un jour civil donné (exigen ce 
084, annexe 1B; exigenc es 105, 106 et 107, annexe 1C) et à l'état des lecteur s à 00h00 ce même jour . 
noOfAc tivityChanges indique le nombre de mots que compo rte le jeu ActivityChangeInf os. 
activityChangeInfos indique le jeu de mots ActivityChangeInf o enregistrés dans la VU pour le jour considéré. Il 
comprend toujours deux mots ActivityChang eInfo donnant l'état des deux lecteurs à 00h00 ce même jour . 
2.171.  VuActivityDailyRecordAr ray 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux change ments 
d'activit é ainsi qu'aux changem ents d'état de conduite et/ou d'état de carte pour un jour civil donné (exigen ce 
105, 106 et 107 annexe 1C) et à l'état des lecteurs à 00h00 ce même jour . 
recordT ype indique le type de relevé (ActivityChangeInf o). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des ActivityChangeInf o expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records désigne le jeu de mots ActivityChange Info enregistrés dans la VU pour le jour considéré. Il comprend 
toujour s deux mots ActivityChangeInf o donnant l'état des deux lecteur s à 00h00 ce même jour . 
2.172.  VuAppro valNumber 
Numéro d'homologation de l'unit é embarquée sur véhicule. 26.5.2016 L 139/141 Jour nal officiel de l'Union européenne FR     
Génération 1: 
Attr ibution de valeur: Non-spécifié. 
Génération 2: 
Attr ibution de valeur : 
Le numéro d'homologation doit être fourni tel que publié par le site Internet de la Commission européenne 
correspondant, à savoir en incluant les traits d'union, par exem ple. Le numéro d'homologat ion doit être aligné à 
gauc he. 
2.173.  VuCalibrationDat a 
Génération 1: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux étalonnages 
successifs de l'appareil d'enregistrement (exigence 098, annexe 1B). 
noOfV uCalibrationRecords indique le nombre des relevés que contient le jeu vuCalibrationRecords. 
vuCalibrationRecords indique le jeu de relevés d'étalonnag e. 
2.174.  VuCalibrationRecord 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux étalonnages 
successifs de l'appareil d'enregistrement (exigence 098, annexe 1B; exigences 119 et 120, annexe 1C). 
Génération 1: 
calibrationPur pose indique la raison de l'étalonnage . 
workshopName, workshopA ddress indiquent les nom et adresse de l'atelier . 26.5.2016 L 139/142 Jour nal officiel de l'Union européenne FR     
workshopCardNumber identifie la carte d'ate lier utilisée lors de l'étalonnage. 
workshopCardExpir yDate indique la date d'expiration de la carte. 
vehicleIdentif icationNumber indique le VIN. 
vehicleRegist rationIdentif ication contient le VRN et l'État membre d'immatr iculation. 
wVehicleCharacter isticCons tant indique le coefficient caract éristique du véhicule. 
kCons tantOfRecordingEquipment indique la constant e de l'appareil de contrôle. 
lTyreCircumference indique la circonf érence effective des pneumatiques. 
tyreSize indique la désignation de la dimension des pneumatiques mont és sur le véhicule 
author isedSpeed indique la vitesse autor isée du véhicule. 
oldOdometerV alue, newOdometerV alue indiquent les ancienne et nouvelle valeurs affichées par le comp teur 
kilométr ique. 
oldTimeV alue, newTimeV alue indiquent les anciennes et nouvelles valeurs accordées à la date et à l'heure. 
nextCalibrationDate indique la date du prochain étalonnage correspondant au type spécifi é dans le champ 
CalibrationPur pose et auquel l'organisme d'inspection agréé doit procéder . 
Génération 2: 
Outre la génération 1, l'élément de données suivant est utilisé: 
sealDataV u fournit des informations relatives aux scellés liés aux différ ents compo sants du véhicule. 
2.175.  VuCalibrationRecordAr ray 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux étalonnages 
successifs de l'appareil d'enregistrement (exigence 119 et 120, annexe 1C). 26.5.2016 L 139/143 Jour nal officiel de l'Union européenne FR     
recordT ype indique le type de relevé (VuCalibrationRecord). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des VuCalibrationRecord expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records indique le jeu de relevés d'étalonnag e. 
2.176.  VuCardIWDat a 
Génération 1: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux cycles 
d'inser tion et de retrait des cartes de conduct eur ou d'atelier dans le lecte ur appropr ié de cette unité embarquée 
(exigen ce 081, annexe 1B et exigenc e 103, annexe 1C). 
noOfIWRecords désigne le nombre de relevés dans le jeu vuCardIWRecords 
vuCardIWRecords désigne un jeu de relevés portant sur les cycles d'inser tion et de retrait des cartes. 
2.177.  VuCardIWRecord 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux cycles 
d'inser tion et de retrait des cartes de conduct eur ou d'atelier dans le lecte ur appropr ié de cette unité embarquée 
(exigen ce 081, annexe 1B et exigenc e 102, annexe 1C). 
Génération 1: 
cardHolderName indique les nom et prénom(s) du conducteur ou du détent eur de la carte d'ate lier, tels qu'ils 
sont enregistrés sur celle-ci. 
fullCardNumber indique le type de carte, l'État membre où est délivrée la carte et le numéro de celle-ci, tels 
qu'ils sont enregistrés sur la carte. 
cardExpir yDate indique la date d'expiration de la carte telle qu'elle est enregistrée sur celle-ci. 26.5.2016 L 139/144 Jour nal officiel de l'Union européenne FR     
cardInser tion Time indique la date et l'heure d'inser tion de la carte. 
vehicleOdometerV alueAtInser tion indique la valeur affichée par le comp teur kilométr ique lors de l'inser tion 
de la carte. 
cardSlotNumber indique le lecte ur dans la fente duquel la carte est insérée. 
cardWithdrawa lTime indique la date et l'heure de retrait de la carte. 
vehicleOdometerV alueAtWithdra wal indique la valeur affichée par le comp teur kilométr ique lors du retrait de 
la carte. 
previousV ehicleInfo contient des informations relatives au précédent véhicule utilisé par le conduct eur, telles 
qu'elles sont enregistrées sur la carte. 
manualInputFlag correspond à un drapeau permettant d'identifier si le détenteur de la carte a procédé ou non à 
la saisie manuelle d'activit és du conduct eur lors de l'inser tion de cette carte. 
Génération 2: 
La structure de données de génération 2 n'utilise pas fullCardNumber , mais plutôt les éléments suivants. 
fullCardNumberAndGeneration indique le type de carte, l'État membre où elle a été délivrée, son numéro et sa 
génération, tels qu'ils sont enregistrés sur la carte. 
2.178.  VuCardIWRecordAr ray 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux cycles 
d'inser tion et de retrait des cartes de conduct eur ou d'atelier dans le lecte ur appropr ié de cette unité embarquée 
(exigen ce 103, annexe 1C). 
recordT ype indique le type de relevé (VuCardIWRecord). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des VuCardIWRecord expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records désigne un jeu de relevés portant sur les cycles d'inser tion et de retrait des cartes. 
2.179.  VuCardRecord 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant à la carte 
tach ygraphique utilisée (exigen ces 132, annexe 1C). 26.5.2016 L 139/145 Jour nal officiel de l'Union européenne FR     
cardExtendedSer ialNumber tel qu'extrait du fichier EF_ICC sous le FM de la carte. 
cardPers onaliserID tel qu'extrait du fichier EF_ICC sous le FM de la carte. 
typeOfT achog raphCardId tel qu'extrait du fichier élémentaire EF_Application_Identific ation sous le fichier 
spécialisé DF_T achog raph_G2 
cardStr uctureV ersion telle qu'extraite du fichier élémentaire EF_Application_Identif ication sous le fichier 
spécialisé DF_T achog raph_G2 
cardNumber tel qu'extrait du fichier élémentaire FE_Identification sous le fichier spécialisé DF_T achog raph_G2. 
2.180.  VuCardRecordAr ray 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux cartes 
tach ygraphiques utilisées par cette VU. Ces informations servent à l'analyse de la VU: problèmes de cartes 
(exigen ce 132, annexe 1C). 
recordT ype indique le type de relevé (VuCardRecord). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des VuCardRecord expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records désigne un jeu de relevés portant sur les cartes tach ygraphiques utilisées par la VU. 
2.181.  VuCer tificate 
Certificat associé à la clé publique d'une unité embarquée sur véhicule. 
2.182.  VuCer tificateRecordAr ray 
Génération 2: 
Certificat de la VU plus les métadonnées tels qu'utilisés dans le protocole de télécharg ement. 
26.5.2016 L 139/146 Jour nal officiel de l'Union européenne FR     
recordT ype indique le type de relevé (VuCer tificate). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des VuCer tificate expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis . La valeur doit être définie sur 1, car les 
certificats peuvent présent er des longueurs variables. 
records désigne un jeu de certificat s de VU. 
2.183.  VuCompan yLocksDat a 
Génération 1: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux verrouillages 
d'entrepr ise (exigence 104, annex e 1B). 
noOfLocks indique le nombre de verrouillages réper torié s dans les vuCompan yLocksRecords. 
vuCompany Lock sRecords correspond au jeu de relevés des verrouillages d'entrepr ise. 
2.184.  VuCompan yLocksR ecord 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant à un verrouillage 
d'entrepr ise déter miné (exigen ce 104, annexe 1B; exigenc e 128, annexe 1C). 
Génération 1: 
lockIn Time, lockOutTime indiquent les dates et heures de verrouillage et de déver rouillage. 
companyName, companyA ddress indiquent les nom et adresse de l'entrepr ise en rappor t avec le verrouillage . 
companyCardNumber identifie la carte utilisée lors du verrouillage. 
Génération 2: 
La structure de données de génération 2 n'utilise pas compan yCardNumber , mais plutôt l'élément suivant. 
companyCardNumberAndGeneration identif ie la carte utilisée lors du verrouillage et sa génération. 26.5.2016 L 139/147 Jour nal officiel de l'Union européenne FR     
2.185.  VuCompan yLocksR ecordAr ray 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux verrouillages 
d'entrepr ise (exigence 128, annex e 1C). 
recordT ype indique le type de relevé (VuCompan yLocksRecord). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des VuCom panyL ocksRecord expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. Valeur 0..255. 
records correspond au jeu de relevés des verrouillages d'entrepr ise. 
2.186.  VuControlA ctivityData 
Génération 1: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux contrôles 
exécut és à l'aide de cette VU (exigen ce 102, annexe 1B). 
noOfControls indique le nombre de contrôles réper toriés dans les vuControlA ctivityRecords. 
vuControlAct ivityRecords indique le jeu des relevés d'activité de contrôle. 
2.187.  VuControlA ctivityRecord 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux contrôles 
exécut és à l'aide de cette VU (exigen ce 102, annexe 1B; exigenc e 126, annexe 1C). 
Génération 1: 
controlT ype indique le type de contrôle. 
controlTime indique la date et l'heure du contrôle. 
ControlCardNumber identif ie la carte de contrôleur utilisée lors du contrôle. 26.5.2016 L 139/148 Jour nal officiel de l'Union européenne FR     
downloadPerio dBegin Time indique l'heure de début de la période télécharg ée, en cas de téléc hargement. 
downloadPerio dEndTime indique l'heure de fin de la période téléc hargée , en cas de télécharg ement. 
Génération 2: 
La structure de données de génération 2 n'utilise pas controlCardNumber , mais plutôt les éléments suivants. 
controlCardNumberAndGeneration identif ie la carte de contrôleur utilisée lors du contrôle ainsi que sa 
génération. 
2.188.  VuControlA ctivityRecordAr ray 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux contrôles 
exécut és à l'aide de cette VU (exigen ce 126, annexe 1C). 
recordT ype indique le type de relevé (VuControlA ctivityRecord). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des VuControlA ctivityRecord expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records indique le jeu regroupant l'ensemble des relevés d'activit é de contrôle de la VU. 
2.189.  VuDat aBlockCounter 
Comp teur enregistré sur une carte et identif iant séquentiellement les cycles d'inser tion et de retrait de la carte sur 
le lecteur appropr ié d'unité s embarquées sur véhicules. 
Attr ibution de valeur: numérotation consécutive dont la valeur maximale est égale à 9 999, la numérotation 
recommençant par le numéro 0. 
2.190.  VuDetai ledSpeedBlock 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant à l'évolution de 
la vites se du véhicule pendant une minut e au cours de laquelle le véhicule était en mouvement (exigen ce 093, 
annexe 1B; exigenc e 116, annexe 1C). 
26.5.2016 L 139/149 Jour nal officiel de l'Union européenne FR     
speedBlockBeginDate indique la date et l'heure de la première vitess e instantanée que compo rte le bloc de 
données. 
speedsPerSecon d indique la séquence chronologique des vitesses mesurées tout es les secondes pendant la 
minute qui a commencé à la speedBloc kBeginDate (incluse). 
2.191.  VuDetai ledSpeedBlockRecordAr ray 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant à l'évolution de 
la vitess e du véhicule. 
recordT ype indique le type de relevé (VuDetailedSpeedBlock). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des VuDetailedSpeedBlock expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records indique le jeu de blocs de mesure de la vitesse instantanée. 
2.192.  VuDetai ledSpeedData 
Génération 1: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant à l'évolution de 
la vitess e du véhicule. 
noOfSpeedBlock s indique le nombre des blocs de vitesse que compo rte le jeu de vuDetailedSpeedBlocks. 
vuDetail edSpeedBlocks indique le jeu de blocs de mesure de la vitesse instantanée. 
2.193.  VuDo wnloadableP eriod 
Dates les plus ancienne et récente pour lesquelles une unité embarquée sur véhicule détient des données relatives 
aux activités des conducteurs (exigen ces 081, 084 ou 087, annex e 1B; exigences 102, 105 et 108, annexe 1C). 
minDo wnloadableTime indique les date et heure de l'inser tion de carte, de l'entrée de site ou du chang ement 
d'activit é le plus ancien enregistrées dans la mémoire de l'unit é embarquée sur véhicule. 
maxDo wnloadableTime indique les date et heure du retrait de carte, de l'entrée de site ou du chang ement 
d'activit é le plus récent enregistrées dans la mémoire de l'unité embarquée sur véhicule. 26.5.2016 L 139/150 Jour nal officiel de l'Union européenne FR     
2.194.  VuDo wnloadableP eriodRecordAr ray 
Génération 2: 
VUDo wnloadableP eriod plus les métadonnées tels qu'utilisés dans le protocole de télécharg ement. 
recordT ype indique le type de relevé (VuDo wnloadableP eriod). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des VuDo wnloadableP eriod expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records indique le jeu de relevés VuDo wnloadableP eriod. 
2.195.  VuDo wnloadA ctivityData 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant au plus récent 
téléc hargement (exigence 105, annex e 1B; exige nce 129, annexe 1C). 
Génération 1: 
downloadingTime indique la date et l'heure du téléc hargement. 
fullCardNumber identif ie la carte utilisée pour autoriser le téléc hargem ent. 
companyOrW orkshopName indique le nom de l'entrepr ise ou de l'atelier . 
Génération 2: 
La structure de données de génération 2 n'utilise pas fullCardNumber , mais plutôt les éléments suivants. 
fullCardNumberAndGeneration identifie la carte utilisée pour autor iser le téléc hargem ent ainsi que sa 
génération. 
2.196.  VuDo wnloadA ctivityData RecordAr ray 
Génération 2: 
Informations se rappor tant au dernier téléc hargement de la VU (exigen ce 129, annexe 1C). 
26.5.2016 L 139/151 Jour nal officiel de l'Union européenne FR     
recordT ype indique le type de relevé (VuDo wnloadA ctivityData). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des VuDo wnloadA ctivityData expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records désigne le jeu regroupant l'ensemble des relevés de données d'activité relatives au téléc hargement. 
2.197.  VuEv entData 
Génération 1: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant à divers 
événements (exigen ce 094, annexe 1B, à l'excep tion des événements du type excès de vitesse). 
noOfV uEv ents indique le nombre des événements réper toriés dans le jeu des vuEventRecords. 
vuEv entRecords indique un jeu de relevés d'événements. 
2.198.  VuEv entRecord 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant à divers 
événements (exigen ce 094, annexe 1B; exigence 117, annexe 1C, à l'excep tion des événements du type excès de 
vitess e). 
Génération 1: 
eventT ype indique le type d'événement. 
eventRecordPur pose indique la raison de l'enregistrement de l'événement considéré. 
eventBegin Time indique la date et l'heure du début de l'événement. 
eventEndTime indique la date et l'heure de la fin de l'événement. 
cardNumberDr iverSlotBegin identif ie la carte insérée dans le lecteur réser vé au conduct eur, au début de 
l'événement. 
cardNumberCodr iverSlotBegin identif ie la carte insérée dans le lecteur réser vé au conv oyeur , au début de 
l'événement. 
cardNumberDr iverSlotEnd identifie la carte insérée dans le lecteur réser vé au conducteur , à la fin de 
l'événement. 
cardNumberCodr iverSlotEnd identif ie la carte insérée dans le lecteur réser vé au conv oyeur , à la fin de 
l'événement. 26.5.2016 L 139/152 Jour nal officiel de l'Union européenne FR     
similarEv entsNumber indique le nombre d'événements similaires survenus le même jour . 
Cette séquence s'utilise pour tous les événements, sauf ceux du type excès de vitesse. 
Génération 2: 
Outre la génération 1, les éléments de données suivants sont utilisés: 
manufacturerSpecif icEv entFaultData contient des informations complémentaires propres au fabricant et se 
rappor tant à l'événement. 
La structure de données de génération 2 n'utilise pas cardNumberDr iverSlotBegin, cardNumberCodr iverSlotBegin, 
cardNumberDr iverSlotEnd et cardNumberCodr iverSlotEnd, mais plutôt les éléments suivants: 
cardNumberAndGenDr iverSlotBegin identifie la carte insérée dans le lecte ur réser vé au conduct eur ainsi que 
sa génération, au début de l'événement. 
cardNumberAndGenCodr iverSlotBegin identif ie la carte insérée dans le lecteur réser vé au conv oyeur ainsi que 
sa génération, au début de l'événement. 
cardNumberAndGenDr iverSlotEnd identifie la carte insérée dans le lecteur réser vé au conducteur ainsi que sa 
génération, à la fin de l'événement. 
cardNumberAndGenCodr iverSlotEnd identifie la carte insérée dans le lecteur réser vé au conv oyeur ainsi que 
sa génération, à la fin de l'événement. 
Si l'événement est un conf lit temporel, il convie nt d'interpr éter eventBegin Time et eventEndTime de la manière 
suivante: 
eventBegin Time désigne la date et l'heure de l'appareil de contrôle. 
eventEndTime indique la date et l'heure du dispositif GNSS. 
2.199.  VuEv entRecordAr ray 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant à divers 
événements (exigen ce 117, annexe 1C, à l'exception des événements du type excès de vitesse). 
26.5.2016 L 139/153 Jour nal officiel de l'Union européenne FR     
recordT ype indique le type de relevé (VuEventRecord). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des VuEventRecord expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records indique un jeu de relevés d'événements. 
2.200.  VuFaultData 
Génération 1: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant à diverses 
anomalies (exigence 096, annexe 1B). 
noOfV uFaults indique le nombre des anomalies réper toriées dans le jeu des vuFaultRecords. 
vuFaultRecords indique un jeu de relevés d'anomalies. 
2.201.  VuFaultRecord 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant à une anomalie 
(exigen ce 096, annexe 1B; exigenc e 118, annexe 1C). 
Génération 1: 
faultT ype indique le type d'anomalie affectant l'appareil de contrôle. 
faultRecordPur pose indique la raison de l'enregistrement de l'anomalie considérée. 
faultBegin Time indique la date et l'heure de début de l'anomalie. 
faultEndTime indique la date et l'heure de fin de l'anomalie. 
cardNumberDr iverSlotBegin identif ie la carte insérée dans le lecteur réser vé au conduct eur, au début de 
l'anomalie. 
cardNumberCodr iverSlotBegin identif ie la carte insérée dans le lecteur réser vé au conv oyeur , au début de 
l'anomalie. 
cardNumberDr iverSlotEnd identifie la carte insérée dans le lecteur réser vé au conducteur , à la fin de 
l'anomalie. 
cardNumberCodr iverSlotEnd identif ie la carte insérée dans le lecteur réser vé au conv oyeur , à la fin de 
l'anomalie. 26.5.2016 L 139/154 Jour nal officiel de l'Union européenne FR     
Génération 2: 
Outre la génération 1, l'élément de données suivant est utilisé: 
manufacturerSpecif icEv entFaultData contient des informations complémentaires propres au fabricant et se 
rappor tant à l'événement. 
La structure de données de génération 2 n'utilise pas cardNumberDr iverSlotBegin, cardNumberCodr iverSlotBegin, 
cardNumberDr iverSlotEnd et cardNumberCodr iverSlotEnd, mais plutôt les éléments suivants: 
cardNumberAndGenDr iverSlotBegin identifie la carte insérée dans le lecte ur réser vé au conduct eur ainsi que 
sa génération, au début de l'événement. 
cardNumberAndGenCodr iverSlotBegin identif ie la carte insérée dans le lecteur réser vé au conv oyeur ainsi que 
sa génération, au début de l'anomalie. 
cardNumberAndGenDr iverSlotEnd identifie la carte insérée dans le lecteur réser vé au conducteur ainsi que sa 
génération, à la fin de l'anomalie. 
cardNumberAndGenCodr iverSlotEnd identifie la carte insérée dans le lecteur réser vé au conv oyeur ainsi que 
sa génération, à la fin de l'anomalie. 
2.202.  VuFaultRecordAr ray 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant à diverses 
anomalies (exigence 118, annexe 1C). 
recordT ype indique le type de relevé (VuFaultRecord). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des VuFaul tRecord expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records indique un jeu de relevés d'anomalies. 
2.203.  VuGNSSCDRecord 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule relatives à la position GNSS du 
véhicule lorsque le temps de conduite continue du conduct eur atteint un multiple de trois heures (exigen ces 108 
et 110, Annex e 1C). 26.5.2016 L 139/155 Jour nal officiel de l'Union européenne FR     
timeSt amp désigne la date et l'heure lorsque le temps de conduite continue du détent eur de la carte atteint un 
multiple de trois heures. 
cardNumberAndGenDr iverSlot identif ie la carte insérée dans le lecteur réser vé au conducteur ainsi que sa 
génération. 
cardNumberAndGenCodr iverSlot identif ie la carte insérée dans le lecteur réser vé au conv oyeur ainsi que sa 
génération. 
gnssPlaceRecord contient les informations relatives à la position du véhicule. 
2.204.  VuGNSSCDRecordAr ray 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule relatives à la position GNSS du 
véhicule lorsque le temps de conduite continue du conduct eur atteint un multiple de trois heures (exigen ces 108 
et 110, Annex 1C). 
recordT ype indique le type de relevé (VuGNSSCDRecord). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des VuGNSSCDRecord expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records désigne un jeu de relevés de conduite continue GNSS. 
2.205.  VuIdentif ication 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant à l'identif ication 
de l'unité embarquée (exigen ce 075, annexe 1B; exigenc es 93 et 121, annex e 1C). 
Génération 1: 
vuManufacturerName indique le nom du fabricant de l'unité embarquée sur véhicule. 
vuManufacturerAdd ress indique l'adresse du fabricant de l'unité embarquée sur véhicule. 26.5.2016 L 139/156 Jour nal officiel de l'Union européenne FR     
vuPar tNumber indique le numéro de pièce de l'unité embarquée sur véhicule. 
vuSer ialNumber indique le numéro de série de l'unité embarquée sur véhicule. 
vuSof twareIdentif ication identif ie le logiciel mis en œuvre au sein de l'unit é embarquée sur véhicule. 
vuManufactur ingDate indique la date de fabr ication de l'unité embarquée sur véhicule. 
vuAppro valNumber indique le numéro d'homologation de l'unit é embarquée sur véhicule. 
Génération 2: 
Outre la génération 1, l'élément de données suivant est utilisé: 
vuGeneration identifie la génération de l'unité embarquée sur véhicule. 
vuAbility fournit des informations sur l'éventuelle compat ibilité de la VU avec les cartes tach ygraphiques de 
génération 1. 
2.206.  VuIdentif icationRecordAr ray 
Génération 2: 
VuIdentif ication plus les métadonnées tels qu'utilisés dans le protocole de téléc hargement. 
recordT ype indique le type de relevé (VuIdentif ication). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des VuIdentification expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records indique un jeu de relevés VuIdentif ication. 
2.207.  VuITSConsentRecord 
Génération 2: 
Informations stockées dans une unité embarquée sur véhicule relatives à l'accord d'un conducteur sur l'utilisation 
des Intellig ent Transpor t Syste ms. 
26.5.2016 L 139/157 Jour nal officiel de l'Union européenne FR     
cardNumberAndGen identif ie la carte et sa génération. Il doit s'agir d'une carte de conduct eur ou d'ate lier. 
consent désigne un drapeau qui signale si le conducteur a donné son accord sur l'utilisation des Intellig ent 
Transpor t Syste ms avec ce véhicule ou cette unité embarquée sur véhicule. 
Attr ibution de valeur : 
VRAI  indique l'accord du conduct eur sur l'utilisation des Intellig ent Transpor t System s. 
FAUX  indique le refus du conduct eur sur l'utilisation des Intellig ent Transpor t Systems . 
2.208.  VuITSConsentRecordAr ray 
Génération 2: 
Informations stockées dans une unité embarquée sur véhicule relatives à l'accord d'un conducteur sur l'utilisation 
des Intellig ent Transpor t Syste ms (exigen ce 200, annexe 1C). 
recordT ype indique le type de relevé (VuITSConsentRecord). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des VuITSConsentRecord expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records indique un jeu de relevés d'accords STI. 
2.209.  VuManufacturerA ddress 
Adresse du fabr icant de l'unité embarquée sur véhicule. 
Attr ibution de valeur: Non-spécifié. 
2.210.  VuManufacturerName 
Nom du fabr icant de l'unité embarquée sur véhicule. 
Attr ibution de valeur: Non-spécifié. 
2.211.  VuManufactur ingDate 
Date de fabrication de l'unit é embarquée sur véhicule. 
Attr ibution de valeur: Non-spécifié. 26.5.2016 L 139/158 Jour nal officiel de l'Union européenne FR     
2.212.  VuOv erSpeedingControlDat a 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux événements 
du type excès de vitesse survenus depuis le dernier contrôle d'excès de vitesse (exigence 095, annexe 1B; 
exigenc e 117, annexe 1C). 
lastOverspeedControlTime indique la date et l'heure du dernier contrôle d'excès de vitesse. 
firstOv erspeedSince indique la date et l'heure du premier excès de vitesse constat é depuis ce contrôle d'excès 
de vitesse. 
numberOfOv erspeedSince indique le nombre d'événements du type excès de vitess e survenus depuis le dernier 
contrôle d'excès de vitesse. 
2.213.  VuOv erSpeedingControlDat aRecordAr ray 
Génération 2: 
VuOverSpeedingControlData plus les métadonnées tels qu'utilisés dans le protocole de téléc hargement. 
recordT ype indique le type de relevé (VuOverSpeedingControlData). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des VuOverSpeedingControlData expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records indique un jeu de relevés de données relatives au contrôle d'excès de vitesse. 
2.214.  VuOv erSpeedingEv entData 
Génération 1: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux événements 
du type excès de vites se (exigen ce 094, annexe 1B). 
noOfV uOv erSpeedingEv ents indique le nombre d'événements réper toriés dans le jeu vuOverSpeedingEven ­
tRecords. 
vuOv erSpeedingEv entRecords indique un jeu de relevés d'événements du type excès de vites se. 
2.215.  VuOv erSpeedingEv entRecord 
Génération 1: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux événements 
du type excès de vites se (exigen ce 094, annexe 1B; exigenc e 117, annexe 1C). 26.5.2016 L 139/159 Jour nal officiel de l'Union européenne FR     
eventT ype indique le type d'événement. 
eventRecordPur pose indique la raison de l'enregistrement de l'événement considéré. 
eventBegin Time indique la date et l'heure du début de l'événement. 
eventEndTime indique la date et l'heure de la fin de l'événement. 
maxSpeedV alue indique la vitess e maximale mesurée au cours de l'événement. 
averageSpeedV alue indique la vites se moyenne arithmétique mesurée au cours de l'événement. 
cardNumberDr iverSlotBegin identif ie la carte insérée dans le lecteur réser vé au conduct eur, au début de 
l'événement. 
similarEv entsNumber indique le nombre d'événements similaires survenus le même jour . 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux événements 
du type excès de vites se (exigen ce 094, annexe 1B; exigenc e 117, annexe 1C). 
La structure de données de génération 2 n'utilise pas cardNumberDr iverSlotBegin, mais plutôt l'élément suivant : 
cardNumberAndGenDr iverSlotBegin 
2.216.  VuOv erSpeedingEv entRecordAr ray 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux événements 
du type excès de vites se (exigen ce 117, annexe 1C). 
26.5.2016 L 139/160 Jour nal officiel de l'Union européenne FR     
recordT ype indique le type de relevé (VuOverSpeedingEventRecord). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des VuOverSpeedingEventRecord expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records indique un jeu de relevés d'événements du type excès de vitesse. 
2.217.  VuPar tNumber 
Numéro de pièce de l'unité embarquée sur véhicule. 
Attr ibution de valeur: propre au fabricant de la VU. 
2.218.  VuPlaceDailyW orkPeriodD ata 
Génération 1: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux lieux de 
début ou de fin des périodes de travail jour nalières des conducteurs (exigen ce 087, annexe 1B; exigenc es 
108 et 110, annexe 1C). 
noOfPlaceRecords indique le nombre des relevés réper toriés dans le jeu vuPlaceDailyW orkPer iodRecords. 
vuPlaceDailyW orkPeriodRecords indique un jeu de relevés de lieux. 
2.219.  VuPlaceDailyW orkPeriodR ecord 
Génération 1: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux lieux de 
début ou de fin des périodes de travail jour nalières des conducteurs (exigen ce 087, annexe 1B; exigenc es 
108 et 110, annexe 1C). 
fullCardNumber indique le type de carte, l'État membre où elle a été délivrée et son numéro. 
placeRecord contient les informations relatives au lieu entré. 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux lieux de 
début ou de fin des périodes de travail jour nalières des conducteurs (exigen ce 087, annexe 1B; exigenc es 
108 et 110, annexe 1C). 
26.5.2016 L 139/161 Jour nal officiel de l'Union européenne FR     
La structure de données de génération 2 n'utilise pas fullCardNumber , mais plutôt l'élément suivant : 
fullCardNumberAndGeneration indique le type de carte, l'État membre où elle a été délivrée, son numéro et sa 
génération, tels qu'ils sont enregistrés sur la carte. 
2.220.  VuPlaceDailyW orkPeriodR ecordAr ray 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux lieux de 
début ou de fin des périodes de travail jour nalières des conducteurs (exigence 108 et 110, annex e 1C). 
recordT ype indique le type de relevé (VuPlaceDailyW orkP eriodRecord). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des VuPlaceDailyW orkPe riodRecord expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records indique un jeu de relevés de lieux. 
2.221.  VuPublicKey 
Génération 1: 
Clé privée d'une unité embarquée sur véhicule. 
2.222.  VuPublicKey 
Génération 1: 
Clé publique d'une unité embarquée sur véhicule. 
2.223.  VuSer ialNumber 
Numéro de série de l'unité embarquée sur véhicule (exigen ce 075, annexe 1B; exigenc e 93, annex e 1C). 
2.224.  VuSof tInst allationDate 
Date d'installation de la version du logiciel d'exploitation de l'unité embarquée sur véhicule. 
Attr ibution de valeur: Non-spécifié. 26.5.2016 L 139/162 Jour nal officiel de l'Union européenne FR     
2.225.  VuSof twareIdentif ication 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant au logiciel 
installé. 
vuSof twareV ersion indique le numéro de la version du logiciel de l'unité embarquée sur véhicule. 
vuSof tIns tallationDate indique la date d'installation de cette version du logiciel. 
2.226.  VuSof twareV ersion 
Numéro de la version du logiciel de l'unit é embarquée sur véhicule. 
Attr ibution de valeur: Non-spécifié. 
2.227.  VuSpecif icConditionData 
Génération 1: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux conditions 
particulières. 
noOfSpecif icConditionRecords indique le nombre des relevés réper toriés dans le jeu specifi cCondition ­
Records. 
specif icConditionRecords indique un jeu de relevés relatifs à des conditions particulières. 
2.228.  VuSpecif icConditionRecordAr ray 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux conditions 
particulières (exigen ce 130, annexe 1C). 
recordT ype indique le type de relevé (Specif icConditionRecord). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des SpecificConditionRecord expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records indique un jeu de relevés relatifs à des conditions particulières. 26.5.2016 L 139/163 Jour nal officiel de l'Union européenne FR     
2.229.  VuTimeA djus tmentData 
Génération 1: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux remises à 
l'heure exécut ées hors du cadre d'un étalonnage compl et (exigence 101, annex e 1B). 
noOfV uTimeA djRecords indique le nombre des relevés réper toriés dans le jeu vuTimeA djustmentRecords. 
vuTimeAdjustmentRecords indique un jeu de relevés de remises à l'heure. 
2.230.  VuTimeA djus tmentGNSSRecord 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant à une remise à 
l'heure exécut ée sur la base des données horaires du GNSS (exigen ces 124 et 125, annex e 1C). 
oldTimeV alue, newTimeV alue indiquent les anciennes et nouvelles valeurs accordées à la date et à l'heure. 
2.231.  VuTimeA djus tmentGNSSRecordAr ray 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant à une remise à 
l'heure exécut ée sur la base des données horaires du GNSS (exigen ces 124 et 125, annex e 1C). 
recordT ype indique le type de relevé (VuTimeAdjustmentGNSSRecord). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des VuTimeAd justmentGNSSRecord expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records indique un jeu de relevés de remises à l'heure GNSS. 26.5.2016 L 139/164 Jour nal officiel de l'Union européenne FR     
2.232.  VuTimeA djus tmentRecord 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux remises à 
l'heure exécutées hors du cadre d'un étalonnage compl et (exigen ce 101, annexe 1B; exigenc es 124 et 125, 
annexe 1C). 
Génération 1: 
oldTimeV alue, newTimeV alue indiquent les anciennes et nouvelles valeurs accordées à la date et à l'heure. 
workshopName, workshopA ddress indiquent les nom et adresse de l'atelier . 
workshopCardNumber identifie la carte d'ate lier utilisée pour exécut er la remise à l'heure. 
Génération 2: 
La structure de données de génération 2 n'utilise pas workshopCardNumber , mais plutôt l'élément suivant : 
workshopCardNumberAndGeneration identif ie la carte d'ateli er utilisée pour exécuter la remise à l'heure ainsi 
que sa génération. 
2.233.  VuTimeA djus tmentRecordAr ray 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux remises à 
l'heure exécut ées hors du cadre d'un étalonnage compl et (exigences 124 et 125, annexe 1C). 
recordT ype indique le type de relevé (VuTimeAdjustmentRecord). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des VuTimeAd justmentRecord expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records indique un jeu de relevés de remises à l'heure. 26.5.2016 L 139/165 Jour nal officiel de l'Union européenne FR     
2.234.  WorkshopCardApplicationIdentif ication 
Informations enregistrées sur une carte d'atelier et se rappor tant à l'identification de l'application de la carte 
(exigen ces 307 et 330 de l'annexe 1C). 
Génération 1: 
typeOfT achog raphCardId spécifi e le type de la carte mise en application. 
cardStr uctureV ersion spécifie la version de la structure mise en œuvre au sein de la carte. 
noOfEv entsP erType indique le nombre d'événements que la carte est suscep tible de sauveg arder par type 
d'événement. 
noOfFaultsPerT ype indique le nombre d'anomalies que la carte est susceptible de sauvegarder par type 
d'anomalie. 
activityStr uctureLength indique le nombre d'oct ets susceptibles d'être affectés à l'enregistrement de relevés 
d'activit é. 
noOfCardV ehicleRecords indique le nombre des relevés de véhicule que la carte est susceptible de mémor iser. 
noOfCardPlaceRecords indique le nombre de sites que la carte est susceptible de mémor iser. 
noOfCalibrationRecords indique le nombre des relevés d'étalonnag e que la carte est suscept ible de mémor iser. 
Génération 2: 
Outre la génération 1, les éléments de données suivants sont utilisés: 
noOfGNSSCDRecords indique le nombre de relevés de conduite continue GNSS que la carte est susceptible de 
sauvegarder . 
noOfSpecif icConditionRecords indique le nombre de relevés de conditions particulières que la carte est 
susceptible de mémor iser. 
2.235.  WorkshopCardCalibrationDat a 
Informations enregistrées sur une carte d'atelier et se rappor tant aux activités d'ate lier menées avec cette carte 
(exigen ces 314, 316, 337 et 339, annexe 1C). 26.5.2016 L 139/166 Jour nal officiel de l'Union européenne FR     
calibration TotalNumber indique le nombre total d'étalonnag es exécut és avec la carte. 
calibrationPoin terNew estRecord indique l'indice du dernier relevé d'étalonnages mis à jour . 
Attr ibution de valeur: nombre correspondant au numérat eur du relevé d'étalonnage, commençant par une 
série de ‘0’ pour la première occur rence d'un relevé d'étalonnag e dans la structure considérée. 
calibrationRecords indique le jeu de relevés contenant des données d'étalonnag e et/ou de réglage temporel. 
2.236.  WorkshopCardCalibrationRecord 
Informations enregistrées sur une carte d'atelier et se rappor tant à un étalonnage exécut é avec la carte 
(exigen ces 314 et 337, annexe 1C). 
Génération 1: 
calibrationPur pose indique la raison de l'étalonnage . 
vehicleIdentif icationNumber indique le VIN. 
vehicleRegist ration contient le VRN et l'État membre d'immatr iculation. 
wVehicleCharacter isticCons tant indique le coefficient caract éristique du véhicule. 
kCons tantOfRecordingEquipment indique la constant e de l'appareil de contrôle. 
lTyreCircumference indique la circonf érence effective des pneumatiques. 
tyreSize indique la désignation de la dimension des pneumatiques mont és sur le véhicule. 
author isedSpeed indique la vitesse maximale autori sée du véhicule. 
oldOdometerV alue, newOdometerV alue indiquent les ancienne et nouvelle valeurs affichées par le comp teur 
kilométr ique. 
oldTimeV alue, newTimeV alue indiquent les anciennes et nouvelles valeurs accordées à la date et à l'heure. 26.5.2016 L 139/167 Jour nal officiel de l'Union européenne FR     
nextCalibrationDate indique la date du prochain étalonnage correspondant au type spécifi é dans le champ 
CalibrationPur pose et auquel l'organisme d'inspection agréé doit procéder . 
vuPar tNumber , vuSer ialNumber et sensorSer ialNumber constituent les éléments d'inf ormation nécessaires à 
l'identifi cation de l'appareil d'enregistrement. 
Génération 2: 
Outre la génération 1, les éléments de données suivants sont utilisés: 
sensorGNSSSer ialNumber qui identifie un dispositif GNSS externe. 
rcmSer ialNumber qui identif ie un module de communication à distance. 
sealDataCard fournit des informations relatives aux scellés liés aux différents composants du véhicule. 
2.237.  WorkshopCardHolderIdentif ication 
Informations enregistrées sur une carte d'ate lier et se rappor tant à l'identifi cation du détent eur de la carte 
(exigen ce 311 et 334, annexe 1C). 
workshopName indique le nom de l'atelier du détenteur de la carte. 
workshopAd dress indique l'adresse de l'ate lier du détenteur de la carte. 
cardHolderName indique les nom et prénom(s) du détent eur (p.ex. le nom du mécanicien). 
cardHolderPreferredLan guage indique la langue de travail préfé rentielle du titulaire. 
2.238.  WorkshopCardPIN 
Numéro d'identif ication individuel de la carte d'ate lier (exigences 309 et 332, annexe 1C). 26.5.2016 L 139/168 Jour nal officiel de l'Union européenne FR     
Attr ibution de valeur: le numéro d'identif ication individuel connu du détenteur de la carte, compl été à droite 
d'une série d'oct ets ‘FF’ suscept ible de comp ter 8 octets. 
2.239.  W-VehicleCharacter isticCons tant 
Coeff icient caractér istique du véhicule (définition k). 
Attr ibution de valeur: Impulsions par kilomètre dans la plage d'exploitation 0 à 64 255 imp/km. 
2.240.  VuPo werSupplyInter ruptionRecord 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux événements 
du type interr uption de l'alimentation électr ique (exigen ce 117, annexe 1C). 
eventT ype indique le type d'événement. 
eventRecordPur pose indique la raison de l'enregistrement de l'événement considéré. 
eventBegin Time indique la date et l'heure du début de l'événement. 
eventEndTime indique la date et l'heure de la fin de l'événement. 
cardNumberAndGenDr iverSlotBegin identifie la carte insérée dans le lecte ur réser vé au conduct eur ainsi que 
sa génération, au début de l'événement. 
cardNumberAndGenDr iverSlotEnd identifie la carte insérée dans le lecteur réser vé au conducteur ainsi que sa 
génération, à la fin de l'événement. 
cardNumberAndGenCodr iverSlotBegin identif ie la carte insérée dans le lecteur réser vé au conv oyeur ainsi que 
sa génération, au début de l'événement. 
cardNumberAndGenCodr iverSlotEnd identifie la carte insérée dans le lecteur réser vé au conv oyeur ainsi que 
sa génération, à la fin de l'événement. 
similarEv entsNumber indique le nombre d'événements similaires survenus le même jour . 
2.241.  VuPo werSupplyInter ruptionRecordAr ray 
Génération 2: 
Informations enregistrées dans la mémoire d'une unité embarquée sur véhicule et se rappor tant aux événements 
du type excès de vites se (exigen ce 117, annexe 1C). 26.5.2016 L 139/169 Jour nal officiel de l'Union européenne FR     
recordT ype indique le type de relevé (VuPowerSupplyInt erruptionRecord). Attr ibution de valeur : Cf. 
RecordT ype 
recordSize indique la taille des VuPowerSupplyInt erruptionRecord expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records indique un jeu de relevés d'événements du type interr upti ons de l'alimentation électr ique. 
2.242.  VuSensorExter nalGNSSCoupledRecordAr ray 
Génération 2: 
Jeu de SensorExt ernalGNSSCoupledRecord plus les métadonnées servant au protocole de téléc hargement. 
recordT ype indique le type de relevé (SensorExter nalGNSSCoupledRecord). Attr ibution de valeur : Cf. 
RecordT ype 
recordSize indique la taille des SensorExt ernalGNSSCoupledRecord expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records désigne un jeu de relevés couplés au dispositif GNSS externe du capt eur. 
2.243.  VuSensorPairedRecordAr ray 
Génération 2: 
Jeu de SensorP airedRecord plus les métadonnées servant au protocole de téléc hargement. 
recordT ype indique le type de relevé (SensorPairedRecord). Attr ibution de valeur : Cf. RecordT ype 
recordSize indique la taille des SensorP airedRecord expr imée en octets. 
noOfRecords désigne le nombre de relevés dans les relevés définis. 
records indique un jeu de relevés d'appar iement du capt eur. 26.5.2016 L 139/170 Jour nal officiel de l'Union européenne FR     
3.  DÉFINITIONS DES PLAGES DE VALEURS ET DE DIMENSIONS 
Défi nition des variables employées dans les définitions du paragraphe 2. 
4.  JEUX DE CARA CTÈRES 
Les chaînes IA5 se composent par définition de caractères ASCII aux term es de la norme ISO/IEC 8824-1. Pour 
plus de lisibilité et pour facilit er la désignation des caractères, leur assignation de valeur est indiquée ci-après. En 
cas de diverg ence, la norme ISO/IEC 8824-1 l'empor te sur cette note d'inf ormation. 
D'autres chaînes de caractères (Address, Name, VehicleRegistrationNumber) utilisent en outre les carac ­
tères de la plag e de caractères décimaux 161 à 255 des jeux de caractères standard à 8 bits suivants, 
spécifiés par leur numéro de page de code: 
Jeu de caractères standard Code Page 
(Décimal) 
ISO/IEC 8859-1 Latin-1 Européen occidental 1 
ISO/IEC 8859-2 Latin-2 Européen central 2 
ISO/IEC 8859-3 Latin-3 Européen du sud 3 
ISO/IEC 8859-5 Latin/Cyr illique 5 
ISO/IEC 8859-7 Latin/Grec 7 
ISO/IEC 8859-9 Latin-5 Turc 9 
ISO/IEC 8859-13 Latin-7 Balte 13 
ISO/IEC 8859-15 Latin-9 15 
ISO/IEC 8859-16 Latin-10 Européen du sud-est 16 
KOI8-R Latin/Cyr illique 80 
KOI8-U Latin/Cyr illique 85  
5.  ENCOD AGE 
Si les règles de codage ASN.1 s'appliquent aux diffé rents types de données définis , leur codage doit être 
conf orme à la norme ISO/IEC 8825-2, variante alignée. 
6.  IDENTIFICA TEURS D'OBJETS ET IDENTIFICA TEURS D'APPLICA TIONS 
6.1.  Identif icateurs d'objets 
Les identificateurs d'objets (IDO) réper toriés dans le présent chapitre concer nent exclusivement la génération 2. 
Ces IDO sont spécifi és dans le rappor t technique TR-03110-3 et rappelés aux présent es à titre d'exhaustivit é. Ces 
IDO sont cont enus dans la sous-arborescence bsi-de: 
26.5.2016 L 139/171 Jour nal officiel de l'Union européenne FR     
Identif icateurs de proto cole d'authentif ication destinés aux VU 
Exemple: si l'authentif ication de la VU est exécut ée à l'aide de SHA-384, l'identifi cateur d'objet à utiliser est (en 
notation ASN.1) 
 . La valeur de cet identificateur d'objet en 
notation par point est 
 .  
Notation par point Notation d'octets 
‘04 00 7F 00 07 02 02 02 02 03’ 
‘04 00 7F 00 07 02 02 02 02 04’ 
‘04 00 7F 00 07 02 02 02 02 05’  
Identif icateurs de proto cole d'authentif iation destinés aux circuits 
Exemple: prenons le cas d'une authentifi cation de circuit devant être exécutée à l'aide de l'algor ithme ECDH, ce 
qui entraîne une longueur de clé de session AES de 128 bits. Cette clé de session sera ensuite utilisée en mode 
d'exploitation CBC pour assurer la confidentialité des données et avec l'algor ithme CMA C pour garantir l'authen ­
ticité des données. Par conséquent, l'identificateur d'objet à utiliser est (en notation ASN.1) 
. La valeur de cet identif icateur d'objet en notation par point 
est 
 .  
Notation par point Notation d'octets 
‘04 00 7F 00 07 02 02 03 02 02’ 
‘04 00 7F 00 07 02 02 03 02 03’ 
‘04 00 7F 00 07 02 02 03 02 04’  
6.2.  Identif icateur d'application 
Génération 2: 
L'identif icateur d'applications (AID) destiné au dispositif GNSS externe (génér ation 2) est communiqué par ‘FF 44 
54 45 47 4D’. Il s'agit d'un AID excl usif conf orme à la norme ISO/IEC 7816-4. 26.5.2016 L 139/172 Jour nal officiel de l'Union européenne FR     
Remarque: les 5 derniers octets codent le DTEGM pour le dispositif GNSS externe de tach ygraphe intelligent. 
L'identif icateur d'applications destiné aux applications de cartes tach ygraphiques (génération 2) est communiqué 
par ‘FF 53 4D 52 44 54’. Il s'agit d'un AID excl usif conf orme à la norme ISO/IEC 7816-4.  26.5.2016 L 139/173 Jour nal officiel de l'Union européenne FR     
Appendice 2 
SPÉCIFIC ATION DES CARTES TACHY GRAPHIQUES 
TABLE DES MATIÈRES 
1. INTR ODUCTION .............................................................................................................................. 175 
1.1. Abréviations ....................................................................................................................... 175 
1.2. Références .......................................................................................................................... 176 
2. CARA CTÉRISTIQUES ÉLECTRIQUES ET PHYSIQUES ................................................................................. 176 
2.1. Tension d'alimentation et consommation de courant .................................................................... 177 
2.2. Tension de programmation Vpp................................................................................................ 177 
2.3. Génération et fréquence d'horlog e............................................................................................ 177 
2.4. Contacts d'E/S ..................................................................................................................... 177 
2.5. États de la carte................................................................................................................... 177 
3. MATÉRIEL ET COMMUNIC ATION ........................................................................................................ 177 
3.1. Introduction ........................................................................................................................ 177 
3.2. Protocol e de transmission ...................................................................................................... 178 
3.2.1 Protocol es.......................................................................................................................... 178 
3.2.2 ATR .................................................................................................................................. 179 
3.2.3 PTS ................................................................................................................................... 179 
3.3. Conditions d'accès ................................................................................................................ 180 
3.4. Vue d'ensemble des commandes et des codes d'erreur ................................................................... 183 
3.5. Descr iptions des commandes .................................................................................................. 185 
3.5.1 SELECT .......................................................................................................................................... 186 
3.5.2 READ BINAR Y................................................................................................................................. 187 
3.5.3 UPD ATE BINAR Y.............................................................................................................................. 194 
3.5.4 GET CHALLENGE ............................................................................................................................. 200 
3.5.5 VERIFY .......................................................................................................................................... 200 
3.5.6 GET RESPONSE ................................................................................................................................ 202 
3.5.7 PSO: VERIFY CERTIFICA TE.................................................................................................................. 202 
3.5.8 INTERNAL AUTHENTICA TE................................................................................................................ 204 
3.5.9 EXTERNAL AUTHENTICA TE ............................................................................................................... 205 
3.5.10 GENERAL AUTHENTICA TE................................................................................................................. 206 
3.5.11 MANA GE SECURIT Y ENVIR ONMENT .................................................................................................... 207 
3.5.12 PSO: HASH ..................................................................................................................................... 210 
3.5.13 PERFORM HASH OF FILE ................................................................................................................... 211 
3.5.14 PSO: COMP UTE DIGIT AL SIGNA TURE ................................................................................................... 212 
3.5.15 PSO: VERIFY DIGIT AL SIGNA TURE ....................................................................................................... 213 
3.5.16 PROCESS DSR C MESSA GE .................................................................................................................. 214 
4. STR UCTURE DES CARTES TACHY GRAPHIQUES ...................................................................................... 216 
4.1. Fichier Maître (MF) ............................................................................................................... 216 26.5.2016 L 139/174 Jour nal officiel de l'Union européenne FR     
4.2. Applications des cartes de conducteur ....................................................................................... 217 
4.2.1 Application de la carte de conduct eur de génération 1.................................................................. 217 
4.2.2 Application de la carte de conduct eur de génération 2.................................................................. 221 
4.3. Applications de la carte d'atelier .............................................................................................. 224 
4.3.1 Application de la carte d'ate lier de génération 1.......................................................................... 224 
4.3.2 Application de la carte d'ate lier de génération 2.......................................................................... 228 
4.4. Applications de la carte de contrôle .......................................................................................... 233 
4.4.1 Application de la carte de contrôle de génération 1...................................................................... 233 
4.4.2 Application de la carte de contrôle de génération 2...................................................................... 235 
4.5. Applications de la carte d'entrepr ise......................................................................................... 237 
4.5.1 Application de la carte d'entrepr ise de génération 1..................................................................... 237 
4.5.2 Application de la carte d'entrepr ise de génération 2..................................................................... 238  
1.  INTR ODUCTION 
1.1.  Abréviations 
Aux fins du présent appendice, les abréviations utilisées sont les suivantes. 
AC  Conditions d'accès 
AES  Nor me de chiffrement avancé (Advanced Encr yption Standard) 
AID  Identifiant d'application 
ALW  Toujours 
APDU  Unité de données de prot ocole d'application (structure de contrôle) 
ATR  Réponse pour remise à zéro 
AUT  Authentifi é 
C6, C7  Contacts numéros 6 et 7 de la carte conf ormément aux dispositions de la norme ISO/IEC 
7816-2 
cc  cycles d'horloge (clock cycles) 
CHV  Informations de vérification de l'identit é des titulaires 
CLA  Octet de classe de commande APDU 
DSR C  Communication spécialisée à cour te portée 
DF  Fichier spécialisé. Un DF contient d'autres fichiers (EF ou DF) 
ECC  Cryptographie à courbe elliptique 
EF  Fichier élémentaire 
etu  unité de temps élémentaire 
G1  Génération 1 
G2  Génération 2 
IC  Circuit intégré 
ICC  Carte à circuit intégré 
ID  Identificateur 
IFD  Périphér ique d'interface 
IFS  Longueur de la zone d'inf ormation 
IFSC  Longueur de la zone d'inf ormation pour la carte 26.5.2016 L 139/175 Jour nal officiel de l'Union européenne FR     
IFSD  Périphér ique de longueur de la zone d'inf ormation (pour le term inal) 
INS  Octet d'instr uction d'une commande APDU 
Lc  Longueur des données entrantes pour une commande APDU 
Le  Longueur des données attendues (données sortantes pour une commande) 
MF  Fichier maître (DF racine) 
NAD  Adresse du nœud servant au prot ocole T = 1 
NEV  Jamais 
P1-P2  Octet s de paramètre 
PIN  Numéro d'identif ication personnel 
PRO SM  Proté gé avec messag erie sécur isée 
PTS  Sélection de transmission de protocole 
RFU  Réser vé à une utilisation ultérieure 
RST  Réinitialisation (de la carte) 
SFID  Identificateur cour t de l'EF 
SM  Message rie sécur isée 
SW1-SW2  Octet s d'état 
TS  Caractère ATR initial 
VPP  Tension de programmation 
VU  Unité embarquée sur le véhicule 
XXh  Valeur XX en notation hexadécimale 
‘XXh’  Valeur XX en notation hexadécimale 
||  Symbole de concaténation 03||04=0304 
1.2.  Références 
Les références suivante s sont utilisées dans le présent appendice: 
ISO/IEC 7816-2  Identif ication cards — Integrat ed circuit cards — Part 2: Dimensions and location of the 
contacts. ISO/IEC 7816-2:2007. 
ISO/IEC 7816-3  Identif ication cards — Integrated circuit cards — Part 3: Electr ical interface and 
transmission protocols. ISO/IEC 7816-3:2006. 
ISO/IEC 7816-4  Identif ication cards — Integra ted circuit cards — Part 4: Org anization, secur ity and 
commands for interc hange. ISO/IEC 7816-4:2013 + Cor 1: 2014. 
ISO/IEC 7816-6  Identif ication cards — Integrated circuit cards — Part 6: Interin dustr y data elements for 
interc hange. ISO/IEC 7816-6:2004 + Cor 1: 2006. 
ISO/IEC 7816-8  Identif ication cards — Integrated circuit cards — Part 8: Commands for secur ity 
operations. ISO/IEC 7816-8:2004. 
ISO/IEC 9797-2  Information technology — Secur ity techniques — Message Auth entication Codes (MA Cs) 
— Part 2: Mechanisms using a dedicate d hash-function. ISO/IEC 9797-2:2011. 
2.  CARA CTERISTIQUES ELECTRIQUES ET PHYSIQUES 
TCS_01  Tous les signaux électr iques doivent respecter la norme ISO/IEC 7816-3 sauf disposition contraire. 
TCS_02  L'emplacem ent et les dimensions des contacts de la carte doivent respecter la norme ISO/IEC 
7816-2. 26.5.2016 L 139/176 Jour nal officiel de l'Union européenne FR     
2.1.  Tension d'aliment ation et consommation de courant 
TCS_03  La carte doit fonctionner selon les spécifi cations dans les limites de consommation définies par la 
norme ISO/IEC 7816-3. 
TCS_04  La carte doit fonctionner à Vcc = 3 V (± 0,3 V) ou à Vcc = 5 V (± 0,5 V). 
Le choix de la tension doit respecter la norme ISO/IEC 7816-3. 
2.2.  Tension de prog rammation Vpp 
TCS_05  La carte ne doit nécessiter l'application d'aucune tension de programmation au niveau de la broche 
C6. Il est prévu que la broche C6 d'un IFD quelconque ne sera pas connectée. Si le contact C6 est 
susceptible d'être connecté à la tension d'alimentation Vcc de la carte, il ne peut être raccordé à la 
masse. Cette tension ne doit donner lieu à aucune interprétation. 
2.3.  Génération et fréquence d'horloge 
TCS_06  La carte doit fonctionner dans une plag e de fréquences comprise entre 1 et 5 MHz ainsi qu'à des 
fréquences supér ieures. Au cours d'une même session de carte, la fréquence d'horloge est 
susceptible de subir des fluctuations de l'ordre de ± 2 %. La fréquence d'horloge est générée par 
l'unité embarquée sur véhicule et non par la carte considérée. Le coeffi cient d'utilisation peut varier 
entre 40 et 60 %. 
TCS_07  Il est possible d'interr ompr e l'horloge externe dans les conditions enregistrées dans le fichier sur 
carte EF ICC. Le premier octet du corps du fichier EF ICC programme les conditions d'application 
du mode Clockst op: 
Infér ieur Supér ieur   
Bit 3 Bit 2 Bit 1 
0 0 1 Clockst op autori sé, pas de niveau préféren tiel 
0 1 1 Clockst op autori sé, avec une préfé rence pour le niveau supér ieur 
1 0 1 Clockst op autori sé, avec une préfé rence pour le niveau inférieur 
0 0 0 Clockst op inter dit 
0 1 0 Clockst op autori sé uniquement au niveau supér ieur 
1 0 0 Clockst op autori sé uniquement au niveau infér ieur  
Les bits 4 à 8 ne sont pas utilisés. 
2.4.  Conta cts d'E/S 
TCS_08  Le contact d'E/S C7 autor ise la récep tion et l'émission de données en provenance comme à 
destination du IFD concer né. En cours d'exploitation, la carte et l'IFD ne peuvent pas fonctionner 
simultanément en mode émission. Dans l'éventualit é où ces deux composants seraient exploités en 
mode émission, la carte ne cour rait cependant aucun risque de détérioration. Sauf en émission, la 
carte passe systé matiquement en mode récep tion. 
2.5.  États de la carte 
TCS_09  La carte fonctionne selon deux états lorsque la tension d'alimentation est appliquée: 
État d'exploitation lors de l'exé cution de commandes ou en interfaçag e avec une unité numér ique; 
État de repos dans tous les autres cas de figure; dans cet état, la carte doit mémor iser tout es les 
données utiles. 
3.  MATERIEL ET COMMU NICA TION 
3.1.  Introduction 
Les fonctions minimales requises par les cartes tach ygraphiques et les VU pour garantir des conditions 
d'exploitation et d'interopérabilit é satisf aisante s font l'objet d'une descr iption détaillée dans le présent 
paragraphe. 26.5.2016 L 139/177 Jour nal officiel de l'Union européenne FR     
Les cartes tach ygraphiques doivent être aussi conf ormes que possible aux normes ISO/IEC en vigueur (et à la 
norme ISO/IEC 7816 en particulier). Toutef ois, les commandes et prot ocoles font l'objet d'une descr iption 
détaillée afin de fournir, s'il y a lieu, quelques précisions sur certains usages restreints ou certaines diffé rences 
éventuelles. Sauf indication contraire, les commandes spécifiées sont tout es conf ormes aux normes dont il 
est question. 
3.2.  Protoc ole de transmission 
TCS_10  Le protocole de transmission doit être conf orme à la norme ISO/IEC 7816-3 pour T = 0 et T = 1. 
En particulier , la VU doit être à même de reconnaître les extensions de délai d'att ente que lui envoie 
la carte. 
3.2.1  Protocoles 
TCS_11  La carte doit être à même de fournir les protocoles T=0 et T=1. De plus, la carte doit prendre en 
charge d'autres prot ocoles orientés connexion. 
TCS_12  Le protocole T=0 est sélectionné par défaut; par conséquent, le lancement d'une commande PTS est 
indispensable pour adopt er le prot ocole T=1. 
TCS_13  Les périphér iques doivent prendre en charg e la conv ention directe que compo rtent ces deux 
protocoles. En conséquence, la convention direct e est oblig atoire pour la carte. 
TCS_14  L'ATR doit présent er l'octet Longueur de la zone d'info rmation pour la carte au niveau du 
caractère TA3. Valeur minimale: ‘F0h’ (= 240 octets). 
Les restr ictions qui suivent s'appliquent aux protocoles: 
TCS_15  T=0 
—  Le périphér ique d'interface doit prendre en charge une réponse au niveau de l'E/S après le front 
montant du signal sur RST à partir de 400 cc. 
—  Le périphér ique d'interface doit être à même de lire des caractères séparés par 12 etu. 
—  Le périphér ique d'interf ace doit être capable de reconnaître un caractère erroné et sa répétition, 
même s'ils sont séparés par 13 etu. En cas de détection d'un caractère erroné, le signal d'erreur 
peut se manife ster à l'E/S dans un délai compr is entre 1 et 2 etu. Le périphér ique doit être en 
mesure de suppor ter un retard d'une etu. 
—  Le périphér ique d'interface doit accept er une ATR de 33 octets (TS + 32). 
—  Si l'ATR présent e le caractère TC1, le temps de garde supplémentaire (Extra Guard Time) prévu 
doit être ménagé pour les caractères transmis par le périphér ique d'interf ace bien que les 
caractères transmis par la carte puissent encore être séparés par 12 etu. Cette disposition 
s'applique également au caractère d'accusé de récep tion transmis par la carte après l'émission 
d'un caractère P3 par le périphér ique d'interfa ce. 
—  Le périphér ique d'interface doit prendre en comp te un caractère NUL émis par la carte. 
—  Le périphér ique d'interface doit accept er le mode compl émentaire pour accusé de récep tion. 
—  La commande GET RESPONSE (obt enir une réponse) ne peut s'utiliser en mode chaînag e pour 
obtenir des données dont la longueur pour rait excéde r 255 octets. 
TCS_16  T = 1 
—  Octet NAD: inutilisé (l'octet NAD doit être mis à ‘00’). 
—  S-bloc k ABOR T: inutilisé. 
—  S-bloc k VPP state error: inutilisé. 
—  La longueur totale de chaînage associée à une zone de données ne doit pas dépasser 255 octets 
(pour être garantie par l'IFD). 
—  L'IFD doit indiquer l'IFSD immédiate ment après l'ATR. L'IFD doit émettre la demande de S-Bloc k 
IFS après l'ATR et la carte doit lui renv oyer le S-Bloc k IFS. Il est recommandé d'accorder la 
valeur suivante à l'IFSD: 254 octets. 
—  La carte ne doit pas demander de réajust ement de l'IFS. 26.5.2016 L 139/178 Jour nal officiel de l'Union européenne FR     
3.2.2  ATR 
TCS_17  Le périphér ique procède à un contrôle des octets ATR conf ormément à la norme ISO/IEC 7816-3. 
Les caractères histo riques de l'ATR ne doivent être soumis à aucune vérification. 
Exemple de ATR biprotocole de base conf orme à la norme ISO/IEC 7816-3 
Character Value Remarks 
TS ‘3Bh’ Indicates direct convention. 
T0 ‘85h’ TD1 present ; 5 histo rical bytes are presents. 
TD1 ‘80h’ TD2 present ; T=0 to be used 
TD2 ‘11h’ TA3 present ; T=1 to be used 
TA3 ‘XXh’(at least ‘F0h’) Information Field Size Card ( IFSC) 
TH1 to TH5 ‘XXh’ Historical charact ers 
TCK ‘XXh’ Check Charact er (exclusive XOR)  
TCS_18  Après la réponse pour remise à zéro (ATR), le fichier maître (MF) est implicitement sélectionné. Il 
devient le réper toire en cours. 
3.2.3  PTS 
TCS_19  Le protocole par défaut est le suivant : T = 0. Pour sélectionner le protocole T = 1, le périphér ique 
doit envoyer à la carte un message de PTS (également désigné par l'abréviation PPS). 
TCS_20  Tout comme les prot ocoles T = 0 et T = 1, la PTS de base autori sant la permutation des protocoles 
est également oblig atoire pour la carte. 
La PTS s'utilise, conf ormément aux dispositions de la norme ISO/IEC 7816-3, pour passer à des 
débits binaires supér ieurs à celui proposé par défa ut, le cas échéant, par la carte au niveau de l'ATR 
[octe t TA(1)]. 
L'emploi de débits binaires supér ieurs est facultatif pour la carte. 
TCS_21  Si la carte ne prend en charge que le débit binaire par défaut (ou si le débit binaire sélectionné n'est 
pas pris en charg e), la carte doit répondre correcte ment à la PTS en omettant l'octe t PPS1, 
conf ormément à la norme ISO/IEC 7816-3. 
Ci-après figur e une série d'exem ples de PTS de base destinés à la sélection de prot ocoles: 
Character Value Remarks 
PPSS ‘FFh’ The Initiat e Characte r. 
PPS0 ‘00h’ or ‘01h’ PPS1 to PPS3 are not present ; ‘00h’ to select T0, ‘01h’ to select 
T1. 
PK ‘XXh’ Check Characte r:  ‘XXh’ = ‘FFh’ if PPS0 = ‘00h’ , 
‘XXh’ = ‘FEh’ if PPS0 = ‘01h’ .  26.5.2016 L 139/179 Jour nal officiel de l'Union européenne FR     
3.3.  Conditions d'accès 
TCS_22  Les conditions d'accès définissent les conditions de sécur ité correspondant à un mode d'accès (une 
commande). Les conditions d'accès doivent être satisf aites pour que la commande soit traité e. 
TCS_23  Les conditions d'accès applicables à la carte tach ygraphique se définissent comme suit: 
Abréviation Significa tion 
ALW L'action toujours envisag eable peut être exécut ée sans restr iction. La 
commande et sa réponse APDU sont envoyées en texte clair , sans messager ie 
sécur isée. 
NEV L'action n'est jamais envisag eable. 
PLAIN-C La commande APDU est envoyée en texte clair , sans message rie sécur isée. 
PWD L'action ne peut être exécut ée que si le PIN de la carte d'atelier a été vérifié, 
c'est-à-dire que l'état de sécur ité interne de la carte «PIN_V erified» est défini. 
La commande doit être envoyée sans messager ie sécur isée. 
EXT -AUT-G1 L'action ne peut être exécut ée que si la commande Extern al Authenticate de 
l'authentif ication de génération 1 (cf. appendice 11 partie A) a réussi. 
SM-MA C-G1 L'APDU (commande et réponse) doit être effectuée avec la messag erie sécur i­
sée de génération 1 en mode authentification uniquement (cf. appendice 11 
partie A). 
SM-C-MA C-G1 L'APDU doit être effectuée avec la messager ie sécur isée de génération 1 en 
mode authentifi cation uniquement (cf. appendice 11 partie A). 
SM-R -ENC-G1 La réponse APDU doit être effectuée avec la messager ie sécur isée de généra ­
tion 1 en mode chiffrement (cf. appendice 11 partie A), c'est-à-dire sans ren­
voi de code d'authentif ication de message . 
SM-R -ENC-MA C-G1 La réponse APDU doit être effectuée avec la messager ie sécur isée de généra ­
tion 1 en mode chiffrement puis authentific ation (cf. appendice 11 partie 
A). 
SM-MA C-G2 L'APDU (commande et réponse) doit être effectuée avec la messag erie sécur i­
sée de génération 2 en mode authentification uniquement (cf. appendice 11 
partie B). 
SM-C-MA C-G2 La commande APDU doit être effectuée avec la messager ie sécur isée de gé­
nération 2 en mode authentifi cation uniquement (cf. appendice 11 partie B). 
SM-R -ENC-MA C-G2 La réponse APDU doit être effectuée avec la messager ie sécur isée de généra ­
tion 2 en mode chiffrement puis authentifi cation (cf. appendice 11 partie B).  
TCS_24  Ces conditions de sécur ité peuvent être liées selon les manières suivantes: 
ET:Toutes les conditions de sécur ité doivent être rem plies 
OU: Au moins l'une des conditions de sécur ité doit être remplie 
Les conditions d'accès au système de fichiers, à savoir les commandes SELECT , READ BINAR Y and 
UPD ATE BINAR Y sont spécif iées au chapit re 4. Les conditions d'accès des autres commandes sont 
spécifi ées dans les tableaux suivants. 26.5.2016 L 139/180 Jour nal officiel de l'Union européenne FR     
TCS_25  Dans l'application DF Tachograph G1, les conditions d'accès suivantes sont appliquées: 
Commande Carte du conduc ­
teur Carte atelier Carte de contrôle Carte d'entrepr ise 
Extern al Authenticat e     
—Pour l'authentif i­
cation de généra ­
tion 1 ALW ALW ALW ALW 
—Pour l'authentif i­
cation de généra ­
tion 2 ALW PWD ALW ALW 
Internal Authenticat e ALW PWD ALW ALW 
General Auth enticate ALW ALW ALW ALW 
Get Challenge ALW ALW ALW ALW 
MSE:SET AT ALW ALW ALW ALW 
MSE:SET DST ALW ALW ALW ALW 
Process DSR C Mes ­
sage Sans objet Sans objet Sans objet Sans objet 
PSO: Com pute Digital 
Signature ALW OU 
SM-MA C-G2 ALW OU 
SM-MA C-G2 Sans objet Sans objet 
PSO: Hash Sans objet Sans objet ALW Sans objet 
PSO: Hash of File ALW OU 
SM-MA C-G2 ALW OU 
SM-MA C-G2 Sans objet Sans objet 
PSO: Verify Certificate ALW ALW ALW ALW 
PSO: Verify Digital Si­
gnature Sans objet Sans objet ALW Sans objet 
Verify Sans objet ALW Sans objet Sans objet  
TCS_26  Dans l'application DF Tachograph_G2, les conditions d'accès suivantes sont appliquées: 
Commande Carte du conduc ­
teur Carte atelier Carte de contrôle Carte d'entrepr ise 
Extern al Authenticat e     
—Pour l'authentif i­
cation de généra ­
tion 1 Sans objet Sans objet Sans objet Sans objet 
—Pour l'authentif i­
cation de généra ­
tion 2 ALW PWD ALW ALW 
Internal Authenticat e Sans objet Sans objet Sans objet Sans objet 26.5.2016 L 139/181 Jour nal officiel de l'Union européenne FR     
Commande Carte du conduc ­
teur Carte atelier Carte de contrôle Carte d'entrepr ise 
General Auth enticate ALW ALW ALW ALW 
Get Challenge ALW ALW ALW ALW 
MSE:SET AT ALW ALW ALW ALW 
MSE:SET DST ALW ALW ALW ALW 
Process DSR C Mes ­
sage Sans objet ALW ALW Sans objet 
PSO: Com pute Digital 
Signature ALW OU 
SM-MA C-G2 ALW OU 
SM-MA C-G2 Sans objet Sans objet 
PSO: Hash Sans objet Sans objet ALW Sans objet 
PSO: Hash of File ALW OU 
SM-MA C-G2 ALW OU 
SM-MA C-G2 Sans objet Sans objet 
PSO: Verify Certificate ALW ALW ALW ALW 
PSO: Verify Digital Si­
gnature Sans objet Sans objet ALW Sans objet 
Verify Sans objet ALW Sans objet Sans objet  
TCS_27  Dans le MF, les conditions d'accès suivantes sont appliquées: 
Commande Carte du conduc ­
teur Carte atelier Carte de contrôle Carte d'entrepr ise 
Extern al Authenticat e     
—Pour l'authentif i­
cation de généra ­
tion 1 Sans objet Sans objet Sans objet Sans objet 
—Pour l'authentif i­
cation de généra ­
tion 2 ALW PWD ALW ALW 
Internal Authenticat e Sans objet Sans objet Sans objet Sans objet 
General Auth enticate ALW ALW ALW ALW 
Get Challenge ALW ALW ALW ALW 
MSE:SET AT ALW ALW ALW ALW 
MSE:SET DST ALW ALW ALW ALW 
Process DSR C Mes ­
sage Sans objet Sans objet Sans objet Sans objet 26.5.2016 L 139/182 Jour nal officiel de l'Union européenne FR     
Commande Carte du conduc ­
teur Carte atelier Carte de contrôle Carte d'entrepr ise 
PSO: Com pute Digital 
Signature Sans objet Sans objet Sans objet Sans objet 
PSO: Hash Sans objet Sans objet Sans objet Sans objet 
PSO: Hash of File Sans objet Sans objet Sans objet Sans objet 
PSO: Verify Certificate ALW ALW ALW ALW 
Verify Sans objet ALW Sans objet Sans objet  
TCS_28  Une carte tach ygraphique peut accept er ou non une commande avec un niveau de sécur ité 
supér ieur à celui spécifi é dans les conditions de sécur ité. Par exem ple, si la condition de sécur ité est 
ALW (ou PLAIN-C), la carte peut accept er une commande avec messager ie sécur isée (mode 
chiffrement et/ou authentifi cation). Si la condition de sécur ité exige la messager ie sécur isée avec le 
mode d'authentif ication, la carte tach ygraphique peut accept er une commande avec messager ie 
sécur isée de même génération en mode chiffrement et authentifi cation. 
Remarque: les descr iptions de commande fournissent des informations compl émentaires sur leur 
prise en charge pour les diffé rents types de cartes tach ygraphiques et les divers DF. 
3.4.  Vue d'ensemble des commandes et des codes d'er reur 
Les commandes et la structure des fichiers découlent de la norme ISO/IEC 7816-4 et sont conf ormes à ses 
dispositions. 
Cette section décr it les paires commande-réponse APDU suivantes. Les variantes de commande prises en 
charge par les applications de génération 1 et 2 sont spécifiées dans les descr iptions de commande corres­
pondant es. 
Commande INS 
SELECT ‘A4h’ 
READ BINAR Y ‘B0h’, ‘B1h’ 
UPD ATE BINAR Y ‘D6h’, ‘D7h’ 
GET CHALLENGE ‘84h’ 
VERIFY ‘20h’ 
GET RESPONSE ‘C0h’ 
PERFORM SECURIT Y OPERA TION ‘2Ah’ 
—  VERIFY CER TIFIC ATE  
—  COMPUTE DIGIT AL SIGNA TURE  
—  VERIFY DIGIT AL SIGNA TURE  
—  HASH  
—  PERFORM HASH OF FILE  
—  PROCESS DSR C MESSA GE  26.5.2016 L 139/183 Jour nal officiel de l'Union européenne FR     
Commande INS 
INTERNAL AUTHENTICA TE ‘88h’ 
EXTERNAL AUTHENTICA TE ‘82h’ 
MANA GE SECURIT Y ENVIR ONMENT ‘22h’ 
—  SET DIGIT AL SIGNA TURE TEMPL ATE  
—  SET AUTHENTICA TION TEMPL ATE  
GENERAL AUTHENTICA TE ‘86h’  
TCS_29  Les mots d'état SW1 et SW2 accompagnent tout message de réponse. Ils indiquent l'état de 
traitement de la commande correspondante . 
SW1 SW2 Signification 
90 00 Traitem ent normal 
61 XX Traitem ent normal XX = nombre d'oct ets de réponse disponibles 
62 81 Traitem ent d'av ertissement. Une partie des données renv oyées peut être cor­
rompue 
63 00 Échec de l'authentif ication (Avertissement) 
63 CX CHV erronées (PIN). Com pteur de tentatives restant es assuré par ‘X’ 
64 00 Erreur d'exécution. État de la mémoire rémanente inchan gé. Erreur d'intégr ité 
65 00 Erreur d'exécution. État de la mémoire rémanente modifi é 
65 81 Erreur d'exécuti on. État de la mémoire rémanent e modifié — Défaillance de la 
mémoire 
66 88 Erreur de sécur ité:  Total de contrôle cryptographique erroné (en cours de 
messager ie sécur isée) ou 
Certificat erroné (pendant la vérification du certificat) ou 
Cryptogramme erroné (pendant l'authentification exte rne) 
ou 
Signature erronée (pendant la vérification de la signature) 
67 00 Longueur erronée (Lc ou Le erronée) 
68 82 Messageri e sécur isée non prise en charge 
68 83 Dernière commande de la chaîne prévisible 
69 00 Commande inter dite (pas de réponse disponible en T=0) 
69 82 État de sécur ité non satisf ait 
69 83 Méthode d'authentifi cation bloquée 
69 85 Conditions d'utilisation non satisf aites 
69 86 Commande non autorisée (pas d'EF actif) 26.5.2016 L 139/184 Jour nal officiel de l'Union européenne FR     
SW1 SW2 Signification 
69 87 Absence des objets informatifs SM prévus 
69 88 Objets informatifs SM incor rects 
6A 80 Paramètres incor rects dans les zones de données 
6A 82 Fichier introuvable 
6A 86 Paramètres P1-P2 erronés 
6A 88 Données désignées introuvables 
6B 00 Paramètres erronés (déplacement hors de l'EF) 
6C XX Longueur erronée, le SW2 indique la longueur exacte. Aucune zone de don ­
nées n'est renv oyée 
6D 00 Code d'instr uction non pris en charge ou incor rect 
6E 00 Classe non prise en charge 
6F 00 Autres erreurs de contrôle  
TCS_30  Si plusieurs conditions d'erreurs sont satisf aites dans une commande APDU, la carte peut renv oyer 
l'un ou l'autre des mots d'état appropr iés. 
3.5.  Descr iptions des commandes 
Le présent chapitre décr it les commandes obligat oires pour les cartes tach ygraphiques. 
L'appendice 11 (Mécanismes de sécur ité communs pour les tach ygraphes de génération 1 et 2) constitue une 
source d'inf ormations pertinentes concer nant les opérations cryptographi ques en jeu. 
Toutes les commandes sont décr ites indépendamment du protocole employé (T=0 ou T=1). Les octets APDU 
CLA, INS, P1, P2, Lc et Le sont toujour s indiqués. Si la commande décr ite peut se passer de l'octet Lc ou Le, 
les cellules longueur , valeur et descr iption associées à celui-ci demeurent vides. 
TCS_31  Si la présence des deux octets de longueur (Lc et Le) est requise, la commande décr ite doit être 
scindée en deux parties si l'IFD emploie le protocole T = 0: l'IFD envoie la commande décr ite avec 
P3 = Lc + données, puis il envoie une commande GET_RESPONSE (cf. paragraphe 3.5.6) avec P3 = 
Le. 
TCS_32  Si la présence des deux octets de longueur est requise et si Le=0 (messageri e sécur isée): 
—  En cas d'utilisation du prot ocole T = 1, la carte doit répondre à Le = 0 en envoyant tout es les 
données de sortie disponibles. 
—  En cas d'utilisation du prot ocole T = 0, l'IFD doit envoyer la première commande avec P3 = Lc 
+ données, la carte doit répondre (à ce Le = 0 implicite) en envoyant les octets d'état ‘61La’, où 
La correspond au nombre d'octets de réponse disponibles. Ensuite , l'IFD doit générer une 
commande GET RESPONSE avec P3 = La pour procéder à la lecture des données. 
TCS_33  Une carte tach ygraphique peut prendre en charge des zones de longueur étendue conf ormément à 
la norme ISO/IEC 7816-4, de manière facultat ive. Une carte tach ygraphique prenant en charge des 
zones de longueur étendue doit: 
—  indiquer la prise en charg e de la zone de longueur étendue dans l'ATR; 
—  prévoi r les tailles de tampon pris en charge au moyen d'inf ormations de longueur étendue dans 
l'EF ATR/INFO cf. TCS_146; 26.5.2016 L 139/185 Jour nal officiel de l'Union européenne FR     
—  indiquer si elle prend en charg e les zones de longueur étendue pour T = 1 et/ou T = 0 dans l'EF 
Exten ded Length, cf. TCS_147. 
—  prendre en charge les zones de longueur étendue pour les générations 1 et 2 d'application 
tach ygraphique. 
Remarques: 
Toutes les commandes sont spécifi ées pour les zones de longueur cour te. L'utilisation d'APDU de 
longueur étendue découle clairement de la norme ISO/IEC 7816-4. 
En règle générale, les commandes sont spécifiées pour le mode en clair , c'est-à-dire sans message rie 
sécur isée, car la couche de messager ie sécur isée est spécifiée en appendice 11. Les conditions d'accès 
à une commande indiquent clairement si la commande prend ou non en charge la message rie 
sécur isée et si la commande prend ou non en charge la message rie sécur isée de génération 1 et/ou 
2. Certaines variante s de commandes sont décr ites avec la messager ie sécur isée afin d'illustrer l'utili ­
sation de cette dernière. 
TCS_34  La VU doit prendre en charge la totalit é de la génération 2 de VU: protocole d'authentifi cation 
mutuelle de la carte pour une session compre nant la vérification du certificat (le cas éché ant) soit 
dans le DF Tachograph, soit dans le DF Tachog raph_G2, soit dans le MF. 
3.5.1  SELECT 
Cette commande est conf orme à la norme ISO/IEC 7816-4, mais elle se caractér ise par un usage restreint en 
comparaison avec la commande analogue définie dans cette norme. 
Emploi de la commande SELECT : 
—  sélection d'un DF d'application (sélection par nom impérative) 
—  sélection d'un fichier élémentaire correspondant à l'ID de fichier présent ée 
3.5.1.1  Sélection par nom (AID) 
Cette commande permet de sélectionner un DF d'application enregistré sur la carte. 
TCS_35  Cette commande s'exécute à partir d'un point quelconque de la structure des fichiers (après l'ATR 
ou à tout moment). 
TCS_36  La sélection d'une application réinitialise l'env ironnement de sécur ité actif. Après avoir procédé à la 
sélection de l'application, aucune clé publique active n'est plus sélectionnée. La condition d'accès 
EXT -AUT-G1 est également perdue. Si la commande a été exécut ée sans messag erie sécur isée, les 
clés de la session de message rie sécur isée précédente sont perdues. 
TCS_37  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘00h’  
INS 1 ‘A4h’  
P1 1 ‘04h’ Sélection par nom (AID) 
P2 1 ‘0Ch’ Aucune réponse attendue 
Lc 1 ‘NNh’ Nombre d'octets envoyés à la carte (longueur de l'AID): 
‘06h’ pour l'application tach ygraphique 
#6-#(5+NN) NN ‘XX..XXh’ AID: ‘FF 54 41 43 48 4F’ pour l'application tach ygraphique 
de génération 1 
AID: ‘FF 53 4D 52 44 54’ pour l'application tach ygraphique 
de génération 2  
Le système se passe de réponse à la commande SELECT (Le absent en T = 1 ou pas de réponse 
requise en T = 0). 26.5.2016 L 139/186 Jour nal officiel de l'Union européenne FR     
TCS_38  Message de réponse (pas de réponse requise) 
Octet Longueur Valeur Descr iption 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
—  Si la commande aboutit, la carte renv oie l'état ‘9000’. 
—  Si le logiciel ne parvient pas à trouver l'application correspondant à l'AID, il renv oie l'état de 
traitem ent ‘6A82’ . 
—  En T = 1, la présence de l'octet Le entraîne le renv oi de l'état ‘6700’. 
—  En T = 0, l'exig ence d'une réponse après récep tion de la commande SELECT entraîne le renv oi 
de l'état ‘6900’. 
—  Si l'application sélectionnée est considérée comme altérée (une erreur d'intégrité est détec tée 
dans les attributs du fichier), le logiciel renv oie l'état de traite ment ‘6400’ ou ‘6581’. 
3.5.1.2  Sélection d'un fichier élémentaire au moyen de son identifi cate ur de fichier 
TCS_39  Message de commande 
TCS_40  Une carte tach ygraphique doit prendre en charge la génération 2 de messag erie sécur isée comme le 
précise l'appendice 11 partie B pour cette variante de commande. 
Octet Longueur Valeur Descr iption 
CLA 1 ‘00h’  
INS 1 ‘A4h’  
P1 1 ‘02h’ Sélection d'un EF dans le DF actif 
P2 1 ‘0Ch’ Aucune réponse attendue 
Lc 1 ‘02h’ Nombre d'octets envoyé à la carte 
#6-#7 2 ‘XXXXh’ Identif icateur de fichier  
Le système se passe de réponse à la commande SELECT (Le absent en T=1 ou pas de réponse 
requise en T=0). 
TCS_41  Message de réponse (pas de réponse requise) 
Octet Longueur Valeur Descr iption 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
—  Si la commande aboutit, la carte renv oie l'état ‘9000’. 
—  Si le logiciel ne parvient pas à trouver le fichier correspondant à l'identificateur de fichier, il 
renv oie l'état de traitement ‘6A82’ . 
—  En T = 1, la présence de l'octet Le entraîne le renv oi de l'état ‘6700’. 
—  En T = 0, l'exig ence d'une réponse après récep tion de la commande SELECT entraîne le renv oi 
de l'état ‘6900’. 
—  Si le fichier sélectionné est considéré comme altéré (une erreur d'inté grité est détect ée dans les 
attributs du fichier), le logiciel renv oie l'état de traite ment ‘6400’ ou ‘6581’. 
3.5.2  READ BINARY 
Cette commande est conf orme à la norme ISO/IEC 7816-4, mais elle se caractér ise par un usage restreint en 
comparaison avec la commande analogue définie dans cette norme. 26.5.2016 L 139/187 Jour nal officiel de l'Union européenne FR     
La commande READ BINAR Y permet d'extraire les données enregistrées dans un fichier transparent. 
La réponse de la carte consist e à renv oyer les données extraites, en les intégrant, le cas échéant, dans une 
structure de messager ie sécur isée. 
3.5.2.1  Commande avec déplacement P1-P2. 
Cette commande permet à l'IFD de lire les données de l'EF sélectionné sans messager ie sécur isée. 
Remarque: cette commande sans messager ie sécur isée ne peut servir qu'à lire un fichier prenant en charge la 
condition de sécur ité ALW en mode Read Access. 
TCS_42  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘00h’  
INS 1 ‘B0h’ Read Binar y 
P1 1 ‘XXh’ Déplacement en octets à comp ter du début du fichier: octet le plus signi ­
ficatif 
P2 1 ‘XXh’ Déplacement en octets à comp ter du début du fichier: octet le moins si­
gnificatif 
Le 1 ‘XXh’ Longueur des données attendue. Nombre d'oct ets à extraire.  
Remarque: le bit 8 de P1 doit être mis à 0.  
TCS_43  Message de réponse 
Octet Longueur Valeur Descr iption 
#1-#X X ‘XX..XXh’ Données lues 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
—  Si la commande aboutit, la carte renv oie l'état ‘9000’. 
—  Si aucun EF n'est sélectionné, le logiciel renv oie l'état de traite ment ‘6986’. 
—  Si les conditions de sécur ité du fichier sélectionné ne sont pas rem plies, la commande est 
interrompue par ‘6982’. 
—  Si le déplacement n'est pas compati ble avec la taille de l'EF (déplacement > taille de l'EF), le 
logiciel renv oie l'état de traitem ent ‘6B00’. 
—  Si la taille des données à lire n'est pas compati ble avec la taille de l'EF (déplacement + Le > taille 
de l'EF), le logiciel renv oie l'état de traitement ‘6700’ ou ‘6Cxx’, où ‘xx’ indique la longueur 
exacte. 
—  Si une erreur d'intégrité est détectée dans les attributs du fichier , la carte considère le fichier 
sélectionné comme altéré et irrécupérable et le logiciel renv oie l'état de traitement ‘6400’ ou 
‘6581’. 
—  Si une erreur d'inté grité est détectée dans les données stoc kées, la carte renv oie les données 
demandées et le logiciel renv oie l'état de traitement ‘6281’. 
3.5.2.1.1  Commande avec messag erie sécur isée (exem ples) 
Cette commande permet à l'IFD d'extraire les données de l'EF sélectionné avec messag erie sécur isée afin de 
vérifier l'intégrité des données reçues et de prot éger la conf identialit é des données si la condition de sécur ité 
SM-R -ENC-MA C-G1 (génération 1) ou SM-R -ENC-MA C-G2 (génér ation 2) est exigé e. 26.5.2016 L 139/188 Jour nal officiel de l'Union européenne FR     
TCS_44  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘0Ch’ Messageri e sécur isée demandée 
INS 1 ‘B0h’ Read Binar y 
P1 1 ‘XXh’ P1 (déplacement en octets à comp ter du début du fichier): 
octet le plus signif icatif 
P2 1 ‘XXh’ P2 (déplacement en octets à comp ter du début du fichier): 
octet le moins signif icatif 
Lc 1 ‘XXh’ Longueur des données d'entrée pour la messag erie sécur isée 
#6 1 ‘97h’ TLE: balise de spécification de longueur attendue 
#7 1 ‘01h’ LLE: longueur de longueur attendue 
#8 1 ‘NNh’ Spécifi cation de longueur attendue (Le original): nombre 
d'octets à lire 
#9 1 ‘8Eh’ TCC: balise indiquant le total de contrôle cryptographique 
#10 1 ‘XXh’ LCC: longueur du total de contrôle cryptographique suivant 
‘04h’ pour la messag erie sécur isée de génération 1 (cf. ap­
pendice 11 partie A) 
‘08h’, ‘0Ch’ ou ‘10h’ selon la longueur de clé AES pour la 
messager ie sécur isée de génération 2 (cf. appendice 11 partie 
B) 
#11-#(10+L) L ‘XX..XXh’ Total de contrôle cryptographique 
Le 1 ‘00h’ Conf ormément à la norme ISO/IEC 7816-4  
TCS_45  Message de réponse si SM-R-ENC-MA C-G1 (génération 1) / SM-R-ENC-MA C-G2 (génération 
2) n'est pas requis et si le format d'entrée de la messager ie sécur isée est correct : 
Octet Longueur Valeur Descr iption 
#1 1 ‘99h’ Balise d'état de traitement (SW1-SW2): faculta ­
tif pour la messager ie sécur isée de génération 
1 
#2 1 ‘02h’ Longueur de l'état de traitement 
#3 — #4 2 ‘XX XXh’ État de traitement de l'APDU de réponse non 
prot égée 
#5 1 ‘81h’ TPV: balise indiquant la valeur des données or­
dinaires 
#6 L ‘NNh’ ou 
‘81 NNh’ LPV: longueur des données renv oyées (=Le ori­
ginal). 
L équivaut à 2 octets si LPV > 127 octets 26.5.2016 L 139/189 Jour nal officiel de l'Union européenne FR     
Octet Longueur Valeur Descr iption 
#(6+L)-#(5+L+NN) NN ‘XX..XXh’ Valeur des données ordinaires 
#(6+L+NN) 1 ‘8Eh’ TCC: balise indiquant le total de contrôle cryp­
tographique 
#(7+L+NN) 1 ‘XXh’ LCC: longueur du total de contrôle cryptogra ­
phique suivant 
‘04h’ pour la messag erie sécur isée de généra ­
tion 1 (cf. appendice 11 partie A) 
‘08h’ , ‘0Ch’ ou ‘10h’ selon la longueur de clé 
AES pour la messager ie sécur isée de génération 
2 (cf. appendice 11 partie B) 
#(8+L+NN)-#(7+M+L+NN) M ‘XX..XXh’ Total de contrôle cryptographique 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
TCS_46  Message de réponse si SM-R-ENC-MA C-G1 (génération 1) / SM-R-ENC-MA C-G2 (génération 
2) est requis et si le format d'entrée de la messager ie sécur isée est correct : 
Octet Longueur Valeur Descr iption 
#1 1 ‘87h’ TPI CG: balise indiquant des données codées 
(cryptogramme) 
#2 L ‘MMh’ ou 
‘81 MMh’ LPI CG: longueur des données chiffrées ren­
voyées (différ entes du Le original de la 
commande en raison du rem plissage). 
L équivaut à 2 octets si LPI CG > 127 octets 
#(2+L)-#(1+L+MM) MM ‘01XX..XXh’ Données codées: cryptogramme et indica ­
teur de remplissag e 
#(2+L+MM) 1 ‘99h’ Balise d'état de traite ment (SW1-SW2): fa­
cultatif pour la message rie sécur isée de gé­
nération 1 
#(3+L+MM) 1 ‘02h’ Longueur de l'état de trait ement 
#(4+L+MM) — #(5+L+MM) 2 ‘XX XXh’ État de traitement de l'APDU de réponse 
non proté gée 
#(6+L+MM) 1 ‘8Eh’ TCC: balise indiquant le total de contrôle 
cryptographique 
#(7+L+MM) 1 ‘XXh’ LCC: longueur du total de contrôle crypto­
graphique suivant 
‘04h’ pour la messager ie sécur isée de géné ­
ration 1 (cf. appendice 11 partie A) 
‘08h’ , ‘0Ch’ ou ‘10h’ selon la longueur de 
clé AES pour la message rie sécur isée de gé­
nération 2 (cf. appendice 11 partie B) 
#(8+L+MM)-#(7+N+L+MM) N ‘XX..XXh’ Total de contrôle cryptographique 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  26.5.2016 L 139/190 Jour nal officiel de l'Union européenne FR     
Il se peut que la commande READ BINAR Y renv oie des états de traitement normaux listé s en 
TCS_43 sous la balise ‘99h’ comme décr it en TCS_59 en adoptant la structure de réponse de la 
messager ie sécur isée. 
Par ailleurs, certaines erreurs propres à la messager ie sécur isée sont suscept ibles de se manifest er. 
Dans ce cas, le logiciel se content e de renv oyer l'état de traite ment concer né sans impliquer aucune 
structure de messager ie sécur isée: 
TCS_47  Message de réponse si le format d'entrée de la messager ie sécur isée est incor rect 
Octet Longueur Valeur Descr iption 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
—  Si aucune clé de session active n'est disponible, le logiciel renv oie l'état de traitement ‘6A88’ . Cet 
événement se produit si la clé de session n'a pas encore été générée ou si la clé de session est 
arrivée à expiration (dans ce cas, l'IFD doit réexécut er le processus d'authentific ation mutuel 
appropr ié pour définir une nouvelle clé de session). 
—  Si certains objets informatifs attendus (comme précisé ci-avant ) font défaut dans la structure de 
message rie sécur isée, le logiciel renv oie l'état de traite ment ‘6987’: cette erreur se produit si une 
balise attendue manque ou si le corps de la commande n'est pas correctement constr uit. 
—  Si certains objets informatifs sont incor rects, le logiciel renv oie l'état de traitement ‘6988’: cette 
erreur se produit si tout es les balises requises sont présentes, mais si certaines longueurs 
diffèrent de celles attendues. 
—  Si la vérification du total de contrôle cryptographique échoue, le logiciel renv oie l'état de 
traitem ent ‘6688’. 
3.5.2.2  Commande avec un identificateur EF cour t 
Cette variante de commande permet à l'IFD de sélectionner un EF à l'aide d'un identif icateur EF cour t et de 
lire des données à partir de cet EF. 
TCS_48  Une carte tach ygraphique doit prendre en charg e cette variante de commande pour tous les fichiers 
élémentaires dotés d'un identif icate ur d'EF cour t donné. Ces identif icateurs EF cour ts figurent au 
chapitre 4. 
TCS_49  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘00h’  
INS 1 ‘B0h’ Read Binar y 
P1 1 ‘XXh’ le bit 8 est mis à 1 
les bits 7 et 6 sont mis à 00 
les bits 5 — 1 codent l'identifi cateur EF cour t de l'EF correspondant 
P2 1 ‘XXh’ Code un déplacement de 0 à 255 octets dans l'EF référen cé par P1 
Le 1 ‘XXh’ Longueur des données attendue. Nombre d'oct ets à extraire.  
Remarque: les identif icate urs EF cour ts servant à l'application tach ygraphique de génération 2 
figurent au chapit re 4. 
Si P1 code un identificateur EF cour t et que la commande réussit, l'EF identif ié devient l'EF 
sélectionné (EF actif). 
TCS_50  Message de réponse 
Octet Longueur Valeur Descr iption 
#1-#L L ‘XX..XXh’ Données lues 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  26.5.2016 L 139/191 Jour nal officiel de l'Union européenne FR     
—  Si la commande aboutit, la carte renv oie l'état ‘9000’. 
—  Si le logiciel ne parvient pas à trouver le fichier correspondant à l'identif icateur EF cour t, il 
renv oie l'état de traitement ‘6A82’. 
—  Si les conditions de sécur ité du fichier sélectionné ne sont pas rem plies, la commande est 
interrompue par ‘6982’. 
—  Si le déplacement n'est pas compati ble avec la taille de l'EF (déplacement > taille de l'EF), le 
logiciel renv oie l'état de traitem ent ‘6B00’. 
—  Si la taille des données à lire n'est pas compati ble avec la taille de l'EF (déplacement + Le > taille 
de l'EF), le logiciel renv oie l'état de traitement ‘6700’ ou ‘6Cxx’, où ‘xx’ indique la longueur 
exacte. 
—  Si une erreur d'intégrité est détectée dans les attributs du fichier , la carte considère le fichier 
sélectionné comme altéré et irrécupérable et le logiciel renv oie l'état de traitement ‘6400’ ou 
‘6581’. 
—  Si une erreur d'inté grité est détectée dans les données stoc kées, la carte renv oie les données 
demandées et le logiciel renv oie l'état de traitement ‘6281’. 
3.5.2.3  Commande avec octe t d'instr uction impair 
Cette variante de commande permet à l'IFD d'extraire des données d'un EF contenant 32 768 octets ou 
davan tage. 
TCS_51  Une carte tach ygraphique prenant en charge les EF dotés de 32 768 octets ou davantag e doit 
prendre en charge cette variante de commande concer nant les EF. Une carte tach ygraphique peut 
prendre en charge ou non cette variante de commande pour les autres EF à l'exception de l'EF 
Sensor_Installation_Data cf. TCS_156 et TCS_160. 
TCS_52  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘00h’  
INS 1 ‘B1h’ Read Binar y 
P1 1 ‘00h’ EF actif 
P2 1 ‘00h’ 
Lc 1 ‘NNh’ Longueur Lc de l'objet informatif déplacé. 
#6-#(5+NN) NN ‘XX..XXh’ Déplacement de l'objet informatif: 
Balise  ‘54h’ 
Longueur  ‘01h’ ou ‘02h’ 
Valeur  déplacement 
Le 1 ‘XXh’ Nombre d'octets à extraire.  
L'IFD doit coder la longueur de l'objet informatif déplacé sur un minimum d'octets. C'est-à-dire que, 
à l'aide de l'octet de longueur ‘01h’ , l'IFD doit coder un déplacement de 0 à 255 et, à l'aide de l'oct et 
de longueur ‘02h’ , un déplacement de ‘256’ jusqu'à ‘65 535’ octets. 
TCS_53  Message de réponse 
Octet Longueur Valeur Descr iption 
#1-#L L ‘XX..XXh’ Les données extraite s sont intégrées dans un objet informatif discré ­
tionnaire avec une balise ‘53h’. 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  26.5.2016 L 139/192 Jour nal officiel de l'Union européenne FR     
—  Si la commande aboutit, la carte renv oie l'état ‘9000’. 
—  Si aucun EF n'est sélectionné, le logiciel renv oie l'état de traite ment ‘6986’. 
—  Si les conditions de sécur ité du fichier sélectionné ne sont pas rem plies, la commande est 
interrompue par ‘6982’. 
—  Si le déplacement n'est pas compati ble avec la taille de l'EF (déplacement > taille de l'EF), le 
logiciel renv oie l'état de traitem ent ‘6B00’. 
—  Si le volume des données à extraire n'est pas compatible avec la taille de l'EF (déplacement + Le 
> taille de l'EF) le logiciel renv oie l'état de traite ment suivant : ‘6700’ ou ‘6Cxx’ où ‘xx’ indique la 
longueur exacte. 
—  Si une erreur d'intégrité est détectée dans les attributs du fichier , la carte considère le fichier 
sélectionné comme altéré et irrécupérable et le logiciel renv oie l'état de traitement ‘6400’ ou 
‘6581’. 
—  Si une erreur d'inté grité est détectée dans les données stoc kées, la carte renv oie les données 
demandées et le logiciel renv oie l'état de traitement ‘6281’. 
3.5.2.3.1  Commande avec messag erie sécur isée (exem ple) 
L'exem ple suivant illustre l'utilisation de la messager ie sécur isée si la condition de sécur ité SM-MA C- 
G2 s'applique. 
TCS_54  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘0Ch’ Messagerie sécur isée demandée 
INS 1 ‘B1h’ Read Binar y 
P1 1 ‘00h’ EF actif 
P2 1 ‘00h’ 
Lc 1 ‘XXh’ Longueur de la zone de données sécur isée 
#6 1 ‘B3h’ Balise indiquant la valeur des données ordinaires 
codées dans BER -TLV 
#7 1 ‘NNh’ LPV: longueur des données transmises 
#(8)-#(7+NN) NN ‘XX..XXh’ Données ordinaires codées dans BER -TLV, c'est-à- 
dire l'objet informatif déplacé doté de la balise 
‘54’ 
#(8+NN) 1 ‘97h’ TLE: balise de spécifi cation de longueur attendue 
#(9+NN) 1 ‘01h’ LLE: longueur de longueur attendue 
#(10+NN) 1 ‘XXh’ Spécific ation de longueur prévisible (Le original): 
nombre d'octets à extraire 
#(11+NN) 1 ‘8Eh’ TCC: balise indiquant le total de contrôle crypto­
graphique 
#(12+NN) 1 ‘XXh’ LCC: longueur du total de contrôle cryptogra ­
phique suivant 
‘08h’ , ‘0Ch’ ou ‘10h’ selon la longueur de clé AES 
pour la messager ie sécur isée de génération 2 (cf. 
appendice 11 partie B) 
#(13+NN)-#(12+M+NN) M ‘XX..XXh’ Total de contrôle cryptographique 
Le 1 ‘00h’ Conf ormément à la norme ISO/IEC 7816-4  26.5.2016 L 139/193 Jour nal officiel de l'Union européenne FR     
TCS_55  Message de réponse si la commande réussit 
Octet Longueur Valeur Descr iption 
#1 1 ‘B3h’ Données ordinaires codées dans BER -TLV 
#2 L ‘NNh’ ou 
‘81 NNh’ LPV: longueur des données renv oyées (=Le ori­
ginal). 
L équivaut à 2 octets si LPV > 127 octets 
#(2+L)-#(1+L+NN) NN ‘XX..XXh’ Valeur de données ordinaires codées dans BER - 
TLV, c'est-à-dire les données extraite s intégré es 
dans un objet informatif discrétionnaire doté 
de la balise ‘53h’ 
#(2+L+NN) 1 ‘99h’ État de traitement de l'APDU de réponse non 
prot égée 
#(3+L+NN) 1 ‘02h’ Longueur de l'état de traitement 
#(4+L+NN) — #(5+L+NN) 2 ‘XX XXh’ État de traitement de l'APDU de réponse non 
prot égée 
#(6+L+NN) 1 ‘8Eh’ TCC: balise indiquant le total de contrôle cryp­
tographique 
#(7+L+NN) 1 ‘XXh’ LCC: longueur du total de contrôle cryptogra ­
phique suivant 
‘08h’ , ‘0Ch’ ou ‘10h’ selon la longueur de clé 
AES pour la messager ie sécur isée de génération 
2 (cf. appendice 11 partie B) 
#(8+L+NN)-#(7+M+L+NN) M ‘XX..XXh’ Total de contrôle cryptographique 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
3.5.3  UPD ATE BINARY 
Cette commande est conf orme à la norme ISO/IEC 7816-4, mais elle se caractér ise par un usage restreint en 
comparaison avec la commande analogue définie dans cette norme. 
Le messag e de commande UPD ATE BINAR Y lance l'actualisation (effacement + enregistrement) des bits déjà 
présents dans un EF avec les bits que recèle la commande APDU. 
3.5.3.1  Commande avec déplacement P1-P2. 
Cette commande permet à l'IFD d'enregistrer des données dans l'EF sélectionné, sans que la carte s'assure de 
l'inté grité des données reçues. 
Remarque: cette commande sans messager ie sécur isée ne peut servir qu'à actualiser un fichier prenant en 
charge la condition de sécur ité ALW en mode Updat e Access. 
TCS_56  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘00h’  
INS 1 ‘D6h’ Update Binar y 26.5.2016 L 139/194 Jour nal officiel de l'Union européenne FR     
Octet Longueur Valeur Descr iption 
P1 1 ‘XXh’ Déplacement en octets à comp ter du début du fichier: octet 
le plus signif icatif 
P2 1 ‘XXh’ Déplacement en octets à comp ter du début du fichier: octet 
le moins significatif 
Lc 1 ‘NNh’ Longueur Lc des données à actualiser . Nombre d'oct ets à en­
registrer . 
#6-#(5+NN) NN ‘XX..XXh’ Données à enregistrer  
Remarque: le bit 8 de P1 doit être mis à 0.  
TCS_57  Message de réponse 
Octet Longueur Valeur Descr iption 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
—  Si la commande aboutit, la carte renv oie l'état ‘9000’. 
—  Si aucun EF n'est sélectionné, le logiciel renv oie l'état de traite ment ‘6986’. 
—  Si les conditions de sécur ité du fichier sélectionné ne sont pas rem plies, la commande est 
interrompue par ‘6982’. 
—  Si le déplacement n'est pas compati ble avec la taille de l'EF (déplacement > taille de l'EF), le 
logiciel renv oie l'état de traitem ent ‘6B00’. 
—  Si le volume des données à enregistrer est n'est pas compat ible avec la taille de l'EF 
(déplacement + Le > taille de l'EF), le logiciel renv oie l'état de traitem ent ‘6700’. 
—  Si une erreur d'intégrité est détectée dans les attributs du fichier , la carte considère le fichier 
sélectionné comme altér é et irrécupérable et le logiciel renv oie l'état de traitement ‘6400’ ou 
‘6500’. 
—  Si l'enregistrement est impossible, le logiciel renv oie l'état de trait ement ‘6581’ . 
3.5.3.1.1  Commande avec messag erie sécur isée (exem ples) 
Cette commande permet à l'IFD d'enregistrer des données dans l'EF sélectionné, la carte s'assurant de 
l'inté grité des données reçues. Aucune conf identialit é n'étant requise, les données ne sont pas codées. 
TCS_58  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘0Ch’ Message rie sécur isée demandée 
INS 1 ‘D6h’ Update Binar y 
P1 1 ‘XXh’ Déplacement en octets à comp ter du début du 
fichier: 
octet le plus significatif 
P2 1 ‘XXh’ Déplacement en octets à comp ter du début du 
fichier: 
octet le moins signif icatif 
Lc 1 ‘XXh’ Longueur de la zone de données sécur isée 26.5.2016 L 139/195 Jour nal officiel de l'Union européenne FR     
Octet Longueur Valeur Descr iption 
#6 1 ‘81h’ TPV: balise indiquant la valeur des données or­
dinaires 
#7 L ‘NNh’ ou 
‘81 NNh’ LPV: longueur des données transmises 
L équivaut à 2 octets si LPV > 127 octets 
#(7+L)-#(6+L+NN) NN ‘XX..XXh’ Valeur des données ordinaires (données à enre ­
gistrer) 
#(7+L+NN) 1 ‘8Eh’ TCC: balise indiquant le total de contrôle cryp­
tographique 
#(8+L+NN) 1 ‘XXh’ LCC: longueur du total de contrôle cryptogra ­
phique suivant ‘04h’ pour la messager ie sécur i­
sée de génération 1 (cf. appendice 11 partie A) 
‘08h’ , ‘0Ch’ ou ‘10h’ selon la longueur de clé 
AES pour la messager ie sécur isée de génération 
2 (cf. appendice 11 partie B) 
#(9+L+NN)-#(8+M+L+NN) M ‘XX..XXh’ Total de contrôle cryptographique 
Le 1 ‘00h’ Conf ormément à la norme ISO/IEC 7816-4  
TCS_59  Message de réponse si le format d'entrée de la messager ie sécur isée est correct 
Octet Longueur Valeur Descr iption 
#1 1 ‘99h’ TSW: balise indiquant des mots d'état (à prot éger par CC) 
#2 1 ‘02h’ LSW: longueur des mots d'état renv oyés 
#3-#4 2 ‘XXXXh’ État de traitement de l'APDU de réponse non protég ée 
#5 1 ‘8Eh’ TCC: balise indiquant le total de contrôle cryptographique 
#6 1 ‘XXh’ LCC: longueur du tota l de contrôle cryptographi que suivant 
‘04h’ pour la messager ie sécur isée de génération 1 (cf. appen ­
dice 11 partie A) 
‘08h’ , ‘0Ch’ ou ‘10h’ selon la longueur de clé AES pour la mes ­
sagerie sécur isée de génération 2 (cf. appendice 11 partie B) 
#7-#(6+L) L ‘XX..XXh’ Total de contrôle cryptographique 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
La structure des messages de réponse décr ite plus haut permet de renv oyer les états de traitement 
«nor maux» précisés pour la commande UPD ATE BINAR Y sans messager ie sécur isée (cf. par. 
3.5.3.1). 
Par ailleurs, certaines erreurs propres à la messager ie sécur isée sont suscep tibles de se produire. 
Dans ce cas, le logiciel se content e de renv oyer l'état de traite ment concer né sans impliquer aucune 
structure de messager ie sécur isée: 
TCS_60  Message de réponse en cas d'er reur affect ant la messager ie sécur isée 
Octet Longueur Valeur Descr iption 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  26.5.2016 L 139/196 Jour nal officiel de l'Union européenne FR     
—  Si aucune clé de session active n'est disponible, le logiciel renv oie l'état de traitem ent ‘6A88’. 
—  Si certains objets informatifs attendus (comme précisé ci-avant ) font défaut dans la structure de 
message rie sécur isée, le logiciel renv oie l'état de traite ment ‘6987’: cette erreur se produit si une 
balise attendue manque ou si le corps de la commande n'est pas correctement constr uit. 
—  Si certains objets informatifs sont incor rects, le logiciel renv oie l'état de traitement ‘6988’: cette 
erreur se produit si tout es les balises requises sont présentes, mais si certaines longueurs 
diffèrent de celles attendues. 
—  Si la vérification du total de contrôle cryptographique échoue, le logiciel renv oie l'état de 
traitem ent ‘6688’. 
3.5.3.2  Commande avec un identificateur EF cour t 
Cette variante de commande permet à l'IFD de sélectionner un EF à l'aide d'un identif icateur EF cour t et 
d'enregistrer des données à partir de cet EF. 
TCS_61  Une carte tach ygraphique doit prendre en charg e cette variante de commande pour tous les fichiers 
élémentaires dotés d'un identif icate ur d'EF cour t donné. Ces identif icateurs EF cour ts figurent au 
chapitre 4. 
TCS_62  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘00h’  
INS 1 ‘D6h’ Update Binar y 
P1 1 ‘XXh’ le bit 8 est mis à 1 
les bits 7 et 6 sont mis à 00 
les bits 5 — 1 codent l'identificateur EF cour t de l'EF corres­
pondant 
P2 1 ‘XXh’ Code un déplacement de 0 à 255 octets dans l'EF référencé 
par P1 
Lc 1 ‘NNh’ Longueur Lc des données à actualiser . Nombre d'oct ets à en­
registrer . 
#6-#(5+NN) NN ‘XX..XXh’ Données à enregistrer  
TCS_63  Message de réponse 
Octet Longueur Valeur Descr iption 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
Remarque: les identif icate urs EF cour ts servant à l'application tach ygraphique de génération 2 
figurent au chapit re 4. 
Si P1 code un identificateur EF cour t et que la commande réussit, l'EF identif ié devient l'EF 
sélectionné (EF actif). 
—  Si la commande aboutit, la carte renv oie l'état ‘9000’. 
—  Si le logiciel ne parvient pas à trouver le fichier correspondant à l'identif icateur EF cour t, il 
renv oie l'état de traitement ‘6A82’. 
—  Si les conditions de sécur ité du fichier sélectionné ne sont pas rem plies, la commande est 
interrompue par ‘6982’. 26.5.2016 L 139/197 Jour nal officiel de l'Union européenne FR     
—  Si le déplacement n'est pas compati ble avec la taille de l'EF (déplacement > taille de l'EF), le 
logiciel renv oie l'état de traitem ent ‘6B00’. 
—  Si le volume des données à enregistrer est n'est pas compat ible avec la taille de l'EF 
(déplacement + Le > taille de l'EF), le logiciel renv oie l'état de traitem ent ‘6700’. 
—  Si une erreur d'intégrité est détectée dans les attributs du fichier , la carte considère le fichier 
sélectionné comme altéré et irrécupérable et le logiciel renv oie l'état de traitement ‘6400’ ou 
‘6581’. 
—  Si l'enregistrement est impossible, le logiciel renv oie l'état de trait ement ‘6581’ . 
3.5.3.3  Commande avec octe t d'instr uction impair 
Cette variante de commande permet à l'IFD d'enregistrer des données dans un EF contenant 32 768 octets 
ou davan tage. 
TCS_64  Une carte tach ygraphique prenant en charge les EF dotés de 32 768 octets ou davantag e doit 
prendre en charge cette variante de commande concer nant les EF. Une carte tach ygraphique peut 
prendre en charge ou non cette variante de commande pour d'autres EF. 
TCS_65  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘00h’  
INS 1 ‘D7h’ Update Binar y 
P1 1 ‘00h’ EF actif 
P2 1 ‘00h’ 
Lc 1 ‘NNh’ Longueur Lc des données dans la zone de données de la 
commande 
#6-#(5+NN) NN ‘XX..XXh’ Déplacement de l'objet informatif doté de la balise ‘54h’ || 
Objet informatif discrétionnaire doté de la balise ‘53h’ qui in­
tègre les données à enregistrer  
L'IFD doit coder la longueur de l'objet informatif déplacé et de l'objet informatif discrétionnaire sur 
un minimum d'oct ets. C'est-à-dire que, à l'aide de l'oct et de longueur ‘01h’, l'IFD doit coder un 
déplacement/une longueur de 0 à 255 et, à l'aide de l'oct et de longueur ‘02h’ , un déplacement/une 
longueur de ‘256’ jusqu'à ‘65 535’ octets. 
TCS_66  Message de réponse 
Octet Longueur Valeur Descr iption 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
—  Si la commande aboutit, la carte renv oie l'état ‘9000’ 
—  Si aucun EF n'est sélectionné, le logiciel renv oie l'état de traite ment ‘6986’. 
—  Si les conditions de sécur ité du fichier sélectionné ne sont pas rem plies, la commande est 
interrompue par ‘6982’. 
—  Si le déplacement n'est pas compati ble avec la taille de l'EF (déplacement > taille de l'EF), le 
logiciel renv oie l'état de traitem ent ‘6B00’. 
—  Si le volume des données à enregistrer est n'est pas compat ible avec la taille de l'EF 
(déplacement + Le > taille de l'EF), le logiciel renv oie l'état de traitem ent ‘6700’. 26.5.2016 L 139/198 Jour nal officiel de l'Union européenne FR     
—  Si une erreur d'intégrité est détectée dans les attributs du fichier , la carte considère le fichier 
sélectionné comme altér é et irrécupérable et le logiciel renv oie l'état de traitement ‘6400’ ou 
‘6500’. 
—  Si l'enregistrement est impossible, le logiciel renv oie l'état de trait ement ‘6581’ . 
3.5.3.3.1  Commande avec messag erie sécur isée (exem ple) 
L'exem ple suivant illustre l'utilisation de la messager ie sécur isée si la condition de sécur ité SM-MA C- 
G2 s'applique. 
TCS_67  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘0Ch’ Message rie sécur isée demandée 
INS 1 ‘D7h’ Update Binar y 
P1 1 ‘00h’ EF actif 
P2 1 ‘00h’ 
Lc 1 ‘XXh’ Longueur de la zone de données sécur isée 
#6 1 ‘B3h’ Balise indiquant la valeur des données ordinai ­
res codées dans BER -TLV 
#7 L ‘NNh’ ou 
‘81 NNh’ LPV: longueur des données transmises 
L équivaut à 2 octets si LPV > 127 octets 
#(7+L)-#(6+L+NN) NN ‘XX..XXh’ Données ordinaires codées dans BER -TLV, c.-à- 
d. le déplacement de l'objet informatif doté de 
la balise ‘54h’ || Objet informatif discrétion ­
naire doté de la balise ‘53h’ qui intègre les 
données à enregistrer 
#(7+L+NN) 1 ‘8Eh’ TCC: balise indiquant le total de contrôle cryp­
tographique 
#(8+L+NN) 1 ‘XXh’ LCC: longueur du total de contrôle cryptogra ­
phique suivant 
‘08h’ , ‘0Ch’ ou ‘10h’ selon la longueur de clé 
AES pour la messager ie sécur isée de génération 
2 (cf. appendice 11 partie B) 
#(9+L+NN)-#(8+M+L+NN) M ‘XX..XXh’ Total de contrôle cryptographique 
Le 1 ‘00h’ Conf ormément à la norme ISO/IEC 7816-4  
TCS_68  Message de réponse si la commande réussit 
Octet Longueur Valeur Descr iption 
#1 1 ‘99h’ TSW: balise indiquant des mots d'état (à prot éger par CC) 
#2 1 ‘02h’ LSW: longueur des mots d'état renv oyés 
#3-#4 2 ‘XXXXh’ État de traitement de l'APDU de réponse non protég ée 
#5 1 ‘8Eh’ TCC: balise indiquant le total de contrôle cryptographique 26.5.2016 L 139/199 Jour nal officiel de l'Union européenne FR     
Octet Longueur Valeur Descr iption 
#6 1 ‘XXh’ LCC: longueur du tota l de contrôle cryptographi que suivant 
‘08h’ , ‘0Ch’ ou ‘10h’ selon la longueur de clé AES pour la mes ­
sagerie sécur isée de génération 2 (cf. appendice 11 partie B) 
#7-#(6+L) L ‘XX..XXh’ Total de contrôle cryptographique 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
3.5.4  GET CHALLENGE 
Cette commande est conf orme à la norme ISO/IEC 7816-4, mais elle se caractér ise par un usage restreint en 
comparaison avec la commande analogue définie dans cette norme. 
La commande GET CHALLENGE (obt enir un challenge) demande à la carte d'émettre un challeng e afin de 
l'utiliser dans le cadre d'une procédure liée à la sécur ité et compo rtant l'env oi d'un cryptogramme ou de 
données chiffrées à la carte. 
TCS_69  Le challenge émis par la carte n'est valable que pour la commande suivante (laquelle a recours à un 
challenge) envoyée à la carte. 
TCS_70  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘00h’  
INS 1 ‘84h’ INS 
P1 1 ‘00h’ P1 
P2 1 ‘00h’ P2 
Le 1 ‘08h’ Le (longueur du challenge attendu)  
TCS_71  Message de réponse 
Octet Longueur Valeur Descr iption 
#1-#8 8 ‘XX..XXh’ Challenge 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
—  Si la commande aboutit, la carte renv oie l'état ‘9000’. 
—  Si Le est différ ent de ‘08h’, le logiciel renv oie l'état de traite ment ‘6700’. 
—  Si les paramètres P1-P2 sont incor rects, le logiciel renv oie l'état de traitement ‘6A86’. 
3.5.5  VERIFY 
Cette commande est conf orme à la norme ISO/IEC 7816-4, mais elle se caractér ise par un usage restreint en 
comparaison avec la commande analogue définie dans cette norme. 
Seule la carte d'ate lier doit prendre en charg e cette commande. 
D'autres types de cartes tach ygraphiques peuvent déclencher ou non cette commande, mais pour ces cartes 
aucune référence CHV n'est personnalisée. Par conséquent, ces cartes ne peuvent pas exécut er cette 
commande. Pour d'autres types de cartes tach ygraphiques que les cartes d'ate lier, le compo rtement, c'est-à- 
dire le code d'erreur renv oyé, sort du cham p de la présent e spécifi cation, si cette commande est envoyée. 26.5.2016 L 139/200 Jour nal officiel de l'Union européenne FR     
La commande VERIFY lance, au niveau de la carte, la compar aison entre les données CHV (PIN) envoyées et 
les données CHV de référen ce enregistrées dans la mémoire de la carte. 
TCS_72  Le PIN renseigné par l'utilisateur doit être codé en code ASCII et compl été à droite d'une série 
d'octets ‘FFh’ jusqu'à atteindre une longueur de 8 octets, par l'IFD; cf. le type de données Workshop ­
CardPIN en appendice 1. 
TCS_73  Les applications tach ygraphiques de génération 1 et 2 doivent utiliser la même référence CHV. 
TCS_74  La carte tach ygraphique doit contrôler si la commande est correctement codée. Si la commande 
n'est pas correctement codée, la carte ne doit pas compar er les valeurs CHV, ni décrémenter le 
comp teur CHV de tentatives restantes, ni réinitialiser l'état de sécur ité «PIN_V erified». Elle doit 
abandonner la commande. Une commande est correctement codée si les octets CLA, INS, P1, P2, Lc 
ont les valeurs spécifiées, Le est absent et la zone de données de la commande a la longueur 
adéquate. 
TCS_75  Si la commande aboutit, le comp teur de tentatives CHV restant es est réinitialisé. La valeur initiale du 
comp teur de tentatives CHV restant es est de 5. Si la commande aboutit, la carte définit l'état de 
sécur ité interne «PIN_V erified». La carte réinitialise cet état de sécur ité si la carte est réinitialisée ou 
si le code CHV transmis par la commande ne correspond pas à la CHV de référence stoc kée. 
Remarque: utiliser la même CHV de référence et un état de sécur ité global évite à un emplo yé 
d'atelier de devoir renseigner à nouveau le PIN après avoir sélectionné un autre DF d'application 
tach ygraphique.  
TCS_76  La carte enregistre l'échec d'une comparaison, c'est-à-dire que le comp teur de tentatives CHV 
restantes doit être décrémenté d'une unité afin de restreindre le nombre de nouvelles tentatives 
d'utilisation de la CHV de référence. 
TCS_77  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘00h’  
INS 1 ‘20h’ INS 
P1 1 ‘00h’ P1 
P2 1 ‘00h’ P2 (la CHV vérifiée est implicit ement connue) 
Lc 1 ‘08h’ Longueur du code CHV transmis 
#6-#13 8 ‘XX..XXh’ CHV  
TCS_78  Message de réponse 
Octet Longueur Valeur Descr iption 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
—  Si la commande aboutit, la carte renv oie l'état ‘9000’. 
—  Si les CHV de référence sont introuvables, le logiciel renv oie l'état de trait ement ‘6A88’. 
—  Si les CHV sont bloquées (le comp teur de tentatives CHV restant es est nul), le logiciel renv oie 
l'état de traite ment ‘6983’. Une fois dans cet état, les CHV ne pour ront jamais plus être 
présent ées avec succès. 
—  Si la comparaison échoue, le comp teur de tentatives restant es est décrémenté et le logiciel 
renv oie l'état ‘63CX’ (X > 0 et X correspond au comp teur de tentatives CHV restantes). 
—  Si les CHV de référence sont considérées comme altérées, le logiciel renv oie l'état de trait ement 
‘6400’ ou ‘6581’. 
—  Si Lc est différent e de ‘08h’ , le logiciel renv oie l'état de traitem ent ‘6700’. 26.5.2016 L 139/201 Jour nal officiel de l'Union européenne FR     
3.5.6  GET RESPONSE 
Cette commande est conf orme à la norme ISO/IEC 7816-4. 
Cette commande (indispensable et excl usivement disponible pour le protocole T=0) permet d'assurer la 
transmission de données préparées entre la carte et le périphér ique d'inte rface (cas où une commande aurait 
inclus les deux octets Lc et Le). 
La commande GET RESPONSE doit être émise immédiat ement après la commande de préparation des 
données, sinon la perte de ces dernières est inévitable. Après exécuti on de la commande GET RESPONSE 
(sauf si l'erreur ‘61xx’ ou ‘6Cxx’ s'est produite, cf. ci-après), les données préalablement préparées cessent 
d'être disponibles. 
TCS_79  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘00h’  
INS 1 ‘C0h’  
P1 1 ‘00h’  
P2 1 ‘00h’  
Le 1 ‘XXh’ Nombre d'oct ets attendus  
TCS_80  Message de réponse 
Octet Longueur Valeur Descr iption 
#1-#X X ‘XX..XXh’ Données 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
—  Si la commande aboutit, la carte renv oie l'état ‘9000’. 
—  Si la carte n'a préparé aucune donnée, elle renv oie l'état de traite ment ‘6900’ ou ‘6F00’. 
—  Si l'octe t Le dépasse le nombre d'oct ets disponibles ou si cet octet est nul, le logiciel renv oie 
l'état de traitement ‘6Cxx’ , les caractères ‘xx’ indiquant le nombre exact d'octets disponibles. 
Dans ce cas, les données préparées restent disponibles pour l'exécution d'une commande GET 
RESPONSE ultérieure. 
—  Si l'octet Le a une valeur non nulle inférieure au nombre d'oct ets disponibles, la carte procède 
normalement à l'env oi des données requises et elle renv oie l'état de traitement ‘61xx’ dans 
lequel ‘xx’ indique un nombre d'octets supplémentaires encore disponibles pour l'exécution 
d'une commande GET RESPONSE ultérieure. 
—  Si la commande n'est pas prise en charge (protocol e T=1), la carte renv oie l'état de trait ement 
‘6D00’ . 
3.5.7  PSO: VERIFY CER TIFICA TE 
Cette commande est conf orme à la norme ISO/IEC 7816-8, mais elle se caractér ise par un usage restreint en 
comparaison avec la commande analogue définie dans cette norme. 
La carte utilise la commande VERIFY CER TIFIC ATE pour obtenir une clé publique venant de l'exté rieur et 
pour en contrôler la validité. 
3.5.7.1  Commande de génération 1: paire de réponses 
TCS_81  Cette variante de commande est uniquement prise en charg e par une application tach ygraphique de 
génération 1. 26.5.2016 L 139/202 Jour nal officiel de l'Union européenne FR     
TCS_82  Lorsqu'une commande VERIFY CER TIFIC ATE aboutit, la clé publique correspondant e est mémor isée 
dans l'env ironnement de sécur ité aux fins d'utilisation ultér ieure. Cette clé doit être explicitement 
conf igurée pour être utilisée, dans le cadre de commandes touc hant à la sécur ité (INTERNAL 
AUTHENTICA TE, EXTERNAL AUTHENTICA TE ou VERIFY CERTIFICA TE), par la commande MSE 
(cf. paragraphe 3.5.11) à l'aide de son identif icateur de clé. 
TCS_83  En tout état de cause, la commande VERIFY CER TIFIC ATE utilise la clé publique préalablement 
sélectionnée par la commande MSE pour ouvr ir le certificat . Cette clé publique doit être celle d'un 
État membre ou de l'Europe. 
TCS_84  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘00h’  
INS 1 ‘2Ah’ Exécution d'une opération de sécur ité 
P1 1 ‘00h’ P1 
P2 1 ‘AEh’ P2: données codées non BER -TLV (concaténation d'éléments de 
données) 
Lc 1 ‘C2h’ Lc: longueur du certificat, 194 octets 
#6-#199 194 ‘XX..XXh’ Certificat : concaté nation des éléments de données (décr its en ap­
pendice 11)  
TCS_85  Message de réponse 
Octet Longueur Valeur Descr iption 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
—  Si la commande aboutit, la carte renv oie l'état ‘9000’. 
—  Si la vérification du certificat échoue, le logiciel renv oie l'état de traitement ‘6688’ . Le processus 
de vérification et de dévoi lement du certificat fait l'objet d'une descr iption détaillée à l'appendice 
11 pour G1 et G2. 
—  Si aucune clé publique n'est présent e dans l'env ironnement de sécur ité, le logiciel renv oie l'état 
de traitem ent ‘6A88’. 
—  Si la clé publique sélectionnée (et utilisée pour dévoiler le certificat) est considérée comme 
altér ée, le logiciel renv oie l'état de traitem ent ‘6400’ ou ‘6581’. 
—  Uniquement pour la génération 1: si la clé publique sélectionnée (utilisée pour dévoi ler le 
certificat) a un CHA .LSB (
 ) diffé rent 
de ‘00’ (donc n'est pas celle d'un État membre ni de l'Europe), le logiciel renv oie l'état de 
traitem ent ‘6985’. 
3.5.7.2  Commande de génération 2: paire de réponses 
Selon la dimension de la courbe, les certificats ECC peuvent être si longs qu'ils ne peuvent pas être transmis 
dans une seule APDU. Dans ce cas, le chaînage de commande conf ormément à la norme ISO/IEC 7816-4 
doit s'appliquer . Le certificat doit être transmis en deux PSO successifs. Vérifier l'APDU du certificat . 
La structure du certificat et les paramètres de domaine sont définis à l'appendice 11. 
TCS_86  La commande est exécutab le dans le MF, DF Tachograph et DF Tachograph_G2, cf. TCS_33. 26.5.2016 L 139/203 Jour nal officiel de l'Union européenne FR     
TCS_87  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘X0h’ L'octet CLA indique un chaînage de commandes: 
‘00h’ unique ou dernière commande de la chaîne 
‘10h’ pas la dernière commande d'une chaîne 
INS 1 ‘2Ah’ Exécution d'une opération de sécur ité 
P1 1 ‘00h’  
P2 1 ‘BEh’ Vérifier le certificat autodescr iptif 
Lc 1 ‘XXh’ Longueur de la zone de données de commande, cf. TCS_88 et 
TCS_89. 
#6-#5+L L ‘XX..XXh’ Données codées DER -TLV: l'objet informatif Corps du certificat 
ECC désigne le premier objet informatif concaténé et l'objet in­
formatif Signature du certificat ECC désigne le deuxième objet 
informatif ou une partie de cette concaté nation. La balise ‘7F21’ 
et la longueur correspondante ne doivent pas être transmises. 
L'ordre de ces objets informatifs est fixe.  
TCS_88  Pour les APDU cour tes, les dispositions suivante s s'appliquent: l'IFD doit utiliser le moins d'APDU 
possible pour transmettre la charge de la commande et transmettre le maximum d'oct ets dans la 
première APDU de commande en fonction de la valeur de l'octet de la carte Dimension de la zone 
d'inf ormations, cf. TCS_14. Si l'IFD a un autre compo rtement, celui de la carte sort du périmètre. 
TCS_89  Pour les APDU longues, les dispositions suivantes s'appliquent: si le certificat ne s'insère pas dans 
une seule APDU, la carte doit prendre en charge une chaîne de commandes. L'IFD doit utiliser le 
moins d'APDU possible pour transmettre la charge de la commande et transmettre le maximum 
d'octets dans la première APDU de commande. Si l'IFD adopt e un autre compo rtement, celui de la 
carte sort du périmètre. 
Remarque: l'appendice 11 prévoi t que la carte stoc ke le certificat ou les conte nus pertinents du 
certificat et actualise son currentA uthenticatedTime. 
La structure de message de réponse et les mots d'état figurent en TCS_85. 
TCS_90  Outre les codes d'erreurs listé s en TCS_85, la carte peut également renv oyer les codes d'erreur 
suivants: 
—Si la clé publique sélectionnée (utilisée pour dévoiler le certificat) possède un CHA .LSB (Cer tifi­
cateH olderAuthor isation.equipmentT ype) inadapt é à la vérification du certificat telle que prévue 
par l'appendice 11, le logiciel renv oie l'état de traitem ent ‘6985’. 
—  Si le currentA uthenticatedTime de la carte est ultérieur à la date d'expiration du certificat , le 
logiciel renv oie l'état de traitem ent ‘6985’. 
—  Si la dernière commande de la chaîne est attendue, la carte renv oie ‘6883’. 
—  Si des paramètres incor rects sont envoyés dans la zone de données de la commande, la carte 
renv oie ‘6A80’ (également utilisé dans le cas où les objets informatifs ne sont pas envoyés dans 
l'ordre spécifi é). 
3.5.8  INTERNAL AUTHENTICATE 
Cette commande est conf orme à la norme ISO/IEC 7816-4. 
TCS_91  Toutes les cartes tach ygraphiques doivent prendre en charge cette commande dans le DF 
Tachog raph de génération 1. La commande peut ou non être accessible dans le MF et/ou le DF 
Tachog raph_G2. Dans ce cas, le logiciel doit interrompre la commande avec un code d'erreur 
adapt é car la clé privée de la carte (Card.SK) pour le prot ocole d'authentification de la génération 1 
n'est accessible que dans le DF_T achog raph de génération 1. 26.5.2016 L 139/204 Jour nal officiel de l'Union européenne FR     
La commande INTERNAL AUTHENTICA TE permet à l'IFD d'authentifier la carte. Le processus d'authentifi ­
cation fait l'objet d'une descr iption détaillée à l'appendice 11. Il compr end les instr uctions suivantes : 
TCS_92  La commande INTERNAL AUTHENTICA TE utilise la clé privée de la carte (implicit ement 
sélectionnée) pour signer des données d'authentifi cation, y compr is K1 (premier élément indiquant 
la concordance des clés de session) et RND1, et elle utilise la clé publique sélectionnée (au moyen 
de la dernière commande MSE) pour coder la signature et constituer le jeton d'authentification 
(pour plus de détails, repor tez-vous à l'appendice 11). 
TCS_93  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘00h’ CLA 
INS 1 ‘88h’ INS 
P1 1 ‘00h’ P1 
P2 1 ‘00h’ P2 
Lc 1 ‘10h’ Longueur des données transmises à la carte 
#6 — #13 8 ‘XX..XXh’ Challenge utilisé pour authentifier la carte 
#14 -#21 8 ‘XX..XXh’ VU.CH R (cf. appendice 11) 
Le 1 ‘80h’ Longueur des données attendue en provenance de la carte  
TCS_94  Message de réponse 
Octet Longueur Valeur Descr iption 
#1-#128 128 ‘XX..XXh’ Jeton d'authentifi cation de carte (cf. appendice 11) 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
—  Si la commande aboutit, la carte renv oie l'état ‘9000’. 
—  Si aucune clé publique n'est présent e dans l'env ironnement de sécur ité, le logiciel renv oie l'état 
de traitem ent ‘6A88’. 
—  Si aucune clé privée n'est présent e dans l'env ironnement de sécur ité, le logiciel renv oie l'état de 
traitem ent ‘6A88’. 
—  Si la VU.CHR ne correspond pas à l'identificateur de clé publique actif, le logiciel renv oie l'état 
de traitem ent ‘6A88’. 
—  Si la clé privée sélectionnée est considérée comme altér ée, le logiciel renv oie l'état de traite ment 
‘6400’ ou ‘6581’. 
TCS_95  Si la commande INTERNAL AUTHENTICA TE aboutit, la clé de session active, pour autant qu'elle 
existe, est effacée et cesse d'être disponible. Pour disposer d'une nouvelle clé de session, il convient 
d'exécut er avec succès la commande EXTERNAL AUTHENTICA TE pour le mécanisme d'authentifi ­
cation de génération 1. 
3.5.9  EXTERNAL AUTHENTIC ATE 
Cette commande est conf orme à la norme ISO/IEC 7816-4. 
La commande EXTERNAL AUTHENTICA TE (authentifica tion extern e) permet à la carte d'authentifi er l'IFD. 
Le processus d'authentifi cation fait l'objet d'une descr iption détaillée à l'appendice 11 pour le tach ygraphe G1 
et G2 (authentifica tion VU). 26.5.2016 L 139/205 Jour nal officiel de l'Union européenne FR     
TCS_96  La variante de la commande pour le mécanisme d'authentifi cation mutuelle de génération 1 est 
uniquement prise en charge par une application tach ygraphique de génération 1. 
TCS_97  La variante de la commande pour l'authentif ication mutuelle de la carte VU de deuxième génération 
est exécutable dans le MF, DF Tachog raph et DF Tachog raph_G2, cf. TCS_34. 
TCS_98  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘00h’ CLA 
INS 1 ‘82h’ INS 
P1 1 ‘00h’ Clés et algor ithmes implicitement connus 
P2 1 ‘00h’  
Lc 1 ‘XXh’ Lc (longueur des données transmises à la carte) 
#6-#(5+L) L ‘XX..XXh’ Authentif ication de génération 1: cryptogramme (cf. appendice 
11 partie A) 
Authentif ication de génération 2: signature générée par l'IFD 
(cf. appendice 11 partie B)  
TCS_99  Message de réponse 
Octet Longueur Valeur Descr iption 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
—  Si la commande aboutit, la carte renv oie l'état ‘9000’. 
—Si le CHA de la clé publique active n'est pas la concaté nation de l'AID de l'application tach ygra ­
phique et d'un type d'équipement VU, le logiciel renv oie un état de traite ment ‘6F00’ . 
—  Si la commande n'est pas immédiatement précédée d'une commande GET CHALLENGE, le 
logiciel renv oie l'état de traitem ent ‘6985’. 
L'application tach ygraphique de génération 1 peut en outre renv oyer les codes d'erreur suivants: 
—  Si aucune clé publique n'est présent e dans l'env ironnement de sécur ité, le logiciel renv oie l'état 
de traitem ent ‘6A88’. 
—  Si aucune clé privée n'est présent e dans l'env ironnement de sécur ité, le logiciel renv oie l'état de 
traitem ent ‘6A88’. 
—  Si la vérification du cryptogramme échoue, le logiciel renv oie l'état de traitem ent ‘6688’. 
—  Si la clé privée sélectionnée est considérée comme altér ée, le logiciel renv oie l'état de traite ment 
‘6400’ ou ‘6581’. 
La variante de la commande pour l'authentif ication de génération 2 peut également renv oyer les 
codes d'erreurs suivants: 
—  Si la vérification de signature échoue, la carte renv oie ‘6300’. 
3.5.10  GENERAL AUTHENTIC ATE 
Cette commande sert au protocole d'authentifi cation du circuit intégré de génération 2 défini dans 
l'appendice 11 partie B conf ormément à la norme ISO/IEC 7816-4. 
TCS_100  La commande est exécutable dans le MF, DF Tachograph et DF Tachograph_G2, cf. TCS_34. 26.5.2016 L 139/206 Jour nal officiel de l'Union européenne FR     
TCS_101  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘00h’  
INS 1 ‘86h’  
P1 1 ‘00h’ Clés et protocoles implicitement 
connus 
P2 1 ‘00h’  
Lc 1 ‘NNh’ Lc: longueur de la zone de données 
ultéri eure 
#6-#(5+L) L ‘7Ch’ + L7C + ‘80h’ + L80 + ‘XX..XXh’ Valeur de la clé publique éphémère 
et codée DER -TLV (cf. appendice 
11) 
La VU doit envoyer les objets infor­
matifs dans cet ordre.  
TCS_102  Message de réponse 
Octet Longueur Valeur Descr iption 
#1-#L L ‘7Ch’ + L7C + ‘81h’ + ‘08h’ 
+ ‘XX..XXh’ + ‘82h’ + L82 + 
‘XX..XXh’ Données d'authentifi cation dynamique codées 
DER -TLV: jeton ‘nonce’ et d'authentifi cation (cf. 
appendice 11) 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
—  Si la commande aboutit, la carte renv oie l'état ‘9000’. 
—  La carte renv oie‘6A80’ pour indiquer des paramètres incor rects dans la zone de données. 
—  La carte renv oie ‘6982’ si la commande Extern al Authenticat e échoue. 
L'objet informatif d'authentific ation dynamique ‘7Ch’: 
—  doit être présent si l'opération aboutit, c'est-à-dire si les mots d'état sont‘9000’; 
—  doit être absent en cas d'erreur d'exécution ou de vérification, c'est-à-dire si les mots d'état se 
situent entre ‘6400’ et ‘6FFF’; et 
—  peut être absent en cas d'aver tissement, c'est-à-dire si les mots d'état se situent entre ‘6200’ et 
‘63FF’. 
3.5.11  MANA GE SECURIT Y ENVIRONMENT 
Cette commande permet de définir une clé publique aux fins d'authentifi cation. 
3.5.11.1  Commande de génération 1: paire de réponses 
Cette commande est conf orme à la norme ISO/IEC 7816-4. Son usag e est restreint relativement à la norme 
en question. 
TCS_103  Cette commande est uniquement prise en charg e par une application tach ygraphique de 
génération 1. 
TCS_104  La clé désignée dans la zone de données MSE reste la clé publique active jusqu'à la commande 
suivante MSE correcte ou la sélection d'un DF ou la réinitialisation de la carte. 
TCS_105  Si la clé mentionnée n'est pas (encore) présent e dans la mémoire de la carte, l'environnement de 
sécur ité reste inchan gé. 26.5.2016 L 139/207 Jour nal officiel de l'Union européenne FR     
TCS_106  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘00h’ CLA 
INS 1 ‘22h’ INS 
P1 1 ‘C1h’ P1: clé mentionnée valable pour l'ensemble des opérations cryp­
tographi ques 
P2 1 ‘B6h’ P2 (données mentionnées concer nant la signature numér ique) 
Lc 1 ‘0Ah’ Lc: longueur de la zone de données ultérieure 
#6 1 ‘83h’ Balise indiquant une clé publique en cas d'asymétr ie 
#7 1 ‘08h’ Longueur de la référence (identificateur de clé) 
#8-#15 8 ‘XX..XXh’ Identif icateur de clé conf orme aux dispositions énoncées à l'ap­
pendice 11  
TCS_107  Message de réponse 
Octet Longueur Valeur Descr iption 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
—  Si la commande aboutit, la carte renv oie l'état ‘9000’. 
—  Si la clé mentionnée n'est pas présente dans la mémoire de la carte, le logiciel renv oie l'état de 
traitement ‘6A88’. 
—  S'il manque certains objets informatifs attendus dans la structure de messager ie sécur isée, le 
logiciel renv oie l'état de traitement ‘6987’ . Cet événement est susceptible de se produire si la 
balise ‘83h’ fait défaut. 
—  Si certains objets informatifs sont incor rects, le logiciel renv oie l'état de traitement ‘6988’. Cet 
événement est suscept ible de se produire si la longueur de l'identifi cate ur de clé ne correspond 
pas à ‘08h’. 
—  Si la clé sélectionnée est considérée comme altér ée, le logiciel renv oie l'état de traitement 
‘6400’ ou ‘6581’. 
3.5.11.2  Commande de génération 2: paire de réponses 
Pour l'authentification de génération 2, la carte tach ygraphique prend en charge la MSE suivante: versions de 
commande définies et conf ormes à la norme ISO/IEC 7816-4. Ces versions de commande ne sont pas prises 
en charge pour l'authentif ication de génération 1. 
3.5.11.2.1  Aut hentifi cation de circuit MSE:SET AT 
La commande MSE:SET AT suivante sert à sélectionner les paramètres d'authentification du circuit effectuée 
par une commande ultérieure d'authentification générale. 
TCS_108  La commande est exécutable dans le MF, DF Tachograph et DF Tachograph_G2, cf. TCS_34. 
TCS_109  Message de commande MSE SET:A T pour authentif ier un circuit 
Octet Longueur Valeur Descr iption 
CLA 1 ‘00h’  
INS 1 ‘22h’  26.5.2016 L 139/208 Jour nal officiel de l'Union européenne FR     
Octet Longueur Valeur Descr iption 
P1 1 ‘41h’ Défi ni pour l'authentification interne 
P2 1 ‘A4h’ Authentif ication 
Lc 1 ‘NNh’ Lc: longueur de la zone de données ultérieure 
#6-#(5+L) L ‘80h’ + ‘0Ah’ + ‘XX..XXh’ Référence de mécanisme cryptographique 
codé DER -TLV: identif icate ur d'objet pour l'au­
thentifi cation de circuit (valeur uniquement, 
balise ‘06h’ absent e). 
Cf. appendice 1 pour les valeurs des identifica ­
teur s d'objets; utiliser la notation en octets. Cf. 
appendice 11 pour les instr uctions relatives à 
la sélection de l'un des identif icate urs d'objet.  
3.5.11.2.2  Aut hentifi cation de VU MSE:SET AT 
La commande MSE:SET AT suivante sert à sélectionner les paramètres et les clés de l'authentif ication de la 
VU effectuée par une commande ultérieure Extern al Authenticate. 
TCS_110  La commande est exécutable dans le MF, DF Tachograph et DF Tachograph_G2, cf. TCS_34. 
TCS_111  Message de commande MSE:SET AT pour authentif ier une VU 
Octet Longueur Valeur Descr iption 
CLA 1 ‘00h’  
INS 1 ‘22h’  
P1 1 ‘81h’ Défi nit l'authentif ication externe 
P2 1 ‘A4h’ Authentif ication 
Lc 1 ‘NNh’ Lc: longueur de la zone de données ultérieure 
#6-#(5+L) L ‘80h’ + ‘0Ah’ + ‘XX..XXh’ Référence de mécanisme cryptographique 
codé DER -TLV: identif icate ur d'objet pour l'au­
thentifi cation de VU (valeur uniquement, ba­
lise ‘06h’ absente ). 
Cf. appendice 1 pour les valeurs des identifica ­
teur s d'objets; utiliser la notation en octets. Cf. 
appendice 11 pour les instr uctions relatives à 
la sélection de l'un des identif icate urs d'objet. 
‘83h’ + ‘08h’ + ‘XX..XXh’ Référence codée DER -TLV de la clé publique 
de la VU par la Référence du titulaire de certi­
ficat mentionnée dans son certificat . 
‘91h’ + L91 + ‘XX..XXh’ Représentation compr imée et codée DER -TLV 
de la clé publique éphémère de la VU qui ser­
vira lors de l'authentif ication du circuit (cf. ap­
pendice 11)  
3.5.11.2.3  MSE:SET DST 
La commande MSE:SET DST suivante sert à définir une clé publique, soit 
—  en vue de vérifier une signature fournie dans un PSO ultérieur: commande Verify Digital Signature, soit 26.5.2016 L 139/209 Jour nal officiel de l'Union européenne FR     
—  en vue de vérifier une signature ou un certificat fourni dans un PSO ultér ieur: commande Verify 
Certificate. 
TCS_112  La commande est exécutable dans le MF, DF Tachograph et DF Tachograph_G2, cf. TCS_33. 
TCS_113  Message de commande MSE:SET DST 
Octet Longueur Valeur Descr iption 
CLA 1 ‘00h’  
INS 1 ‘22h’  
P1 1 ‘81h’ Défini pour vérification 
P2 1 ‘B6h’ Signature numér ique 
Lc 1 ‘NNh’ Lc: longueur de la zone de données ultéri eure 
#6-#(5+L) L ‘83h’ + ‘08h’ + ‘XX...XXh’ Référence codée DER -TLV d'une clé publique, 
c'est-à-dire la référence du titulaire de certifi­
cat dans le certificat de la clé publique (cf. ap­
pendice 11)  
Pour tout es les versions de commande, la structure du message de réponse et les mots d'état proviennent: 
TCS_114  Message de réponse 
Octet Longueur Valeur Descr iption 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
—  Si la commande aboutit, la carte renv oie l'état ‘9000’. Le protocole a été sélectionné et 
initialisé. 
—  ‘6A80’ indique des paramètres incor rects dans les zones de données de la commande. 
—  ‘6A88’ indique que les données de référence (p. ex. une clé mentionnée) ne sont pas 
disponibles. 
3.5.12  PSO: HASH 
Cette commande permet de transfé rer vers la carte le résultat du calcul de hachag e auquel certaines données 
pour raient être soumises. Cette commande s'emploie lors de la vérification de signatures numér iques. La 
valeur de hachag e est enregistrée temporairement en vue d'une commande PSO ultérieure: Verify Digital 
Signature. 
Cette commande est conf orme à la norme ISO/IEC 7816-8. Son usag e est restreint relativement à la norme 
en question. 
Seule la carte de contrôle doit prendre en charg e cette commande dans le DF Tachog raph et DF 
Tachog raph_G2. 
D'autres types de cartes tach ygraphiques peuvent ou non exécut er cette commande. La commande peut ou 
non être accessible dans le MF. 
L'application de la carte de contrôle de génération 1 prend uniquement en charg e SHA-1. 
TCS_115  La valeur de hachag e enregistrée temporairement doit être suppr imée si une nouvelle valeur de 
hachag e est calculée à l'aide de la commande PSO: Hash si un DF est sélectionné et si la carte 
tach ygraphique est réinitialisée. 26.5.2016 L 139/210 Jour nal officiel de l'Union européenne FR     
TCS_116  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘00h’ CLA 
INS 1 ‘2Ah’ Exécution d'une opération de sécur ité 
P1 1 ‘90h’ Ren voie d'un code de hachag e 
P2 1 ‘A0h’ Balise: zone de données conte nant les DO appropr iés pour le 
hachag e 
Lc 1 ‘XXh’ Longueur Lc de la zone de données suivante 
#6 1 ‘90h’ Balise indiquant le code de hachag e 
#7 1 ‘XXh’ Longueur L du code de hach age: 
‘14h’ dans l'application de génération 1 (cf. appendice 11 par­
tie A) 
‘20h’ , ‘30h’ ou ‘40h’ pour l'application de génération 2 (cf. ap­
pendice 11 partie B) 
#8-#(7+L) L ‘XX..XXh’ Code de hacha ge  
TCS_117  Message de réponse 
Octet Longueur Valeur Descr iption 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
—  Si la commande aboutit, la carte renv oie l'état ‘9000’. 
—  S'il manque certains objets informatifs attendus (comme précisé ci-avan t), le logiciel renv oie 
l'état de traite ment ‘6987’. Cet événement est suscep tible de se produire si la balise ‘90h’ fait 
défaut. 
—  Si certains objets informatifs sont incor rects, le logiciel renv oie l'état de trait ement ‘6988’. 
Cette erreur survient si la balise requise est présente mais d'une longueur diffé rente de ‘14h’ 
pour SHA-1, ‘20h’ pour SHA-256, ‘30h’ pour SHA-384, ‘40h’ pour SHA-512 (application de 
génération 2). 
3.5.13  PERFORM HASH OF FILE 
Cette commande n'est pas conf orme à la norme ISO/IEC 7816-8. L'octet CLA de cette commande indique 
donc un usage exclusif de la commande PERFORM SECURIT Y OPERA TION/HASH. 
Seules les cartes de conduct eur et d'ate lier doivent prendre en charge cette commande dans le DF Tachograph 
et le DF Tachog raph_G2. 
D'autres types de cartes tach ygraphiques peuvent ou non exécuter cette commande. Si une carte d'entrepr ise 
ou de contrôle exécute cette commande, la commande doit être exécut ée conf ormément aux dispositions du 
présent chapitre. 
La commande peut ou non être accessible dans le MF. Dans ce cas, la commande doit être exécut ée comme 
le prévoi t le présent chapitre, à savoir sans autor iser le calcul d'une valeur de hacha ge, mais avec abandon et 
communication d'un code d'erreur appropr ié. 
TCS_118  La commande PERFORM HASH of FILE s'utilise pour hache r la zone de données de l'EF 
transparent sélectionné. 
TCS_119  Une carte tach ygraphique doit prendre en charg e cette commande uniquement pour les EF listés 
au chapitre 4 sous les DF_T achograph et DF_T achog raph_G2 et en tenant comp te des excep tions 
suivantes. Une carte tach ygraphique ne doit pas prendre en charge la commande pour l'EF 
Sensor_Installation_Data du DF Tachograph_G2. 26.5.2016 L 139/211 Jour nal officiel de l'Union européenne FR     
TCS_120  Le résultat de l'opération de hachag e est enregistré temporairement dans la mémoire de la carte. 
Par la suite, son utilisation permettra d'obten ir une signature numér ique du fichier en recourant à 
la commande PSO: COMPUTE DIGIT AL SIGNA TURE. 
TCS_121  La valeur de hach age du fichier enregistrée temporairement doit être suppr imée si une nouvelle 
valeur de hachag e de fichier est calculée à l'aide de la commande PSO: Hash of File, si un DF est 
sélectionné et si la carte tach ygraphique est réinitialisée. 
TCS_122  L'application tach ygraphique de génération 1 doit prendre en charge SHA-1. 
TCS_123  L'application tach ygraphique de génération 2 doit prendre en charg e SHA-1 et SHA-2 (256, 384 
et 512 bits). 
TCS_124  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘80h’ CLA 
INS 1 ‘2Ah’ Exécution d'une opération de sécur ité 
P1 1 ‘90h’ Balise: Hash 
P2 1 ‘XXh’ P2: indique l'algor ithme à utiliser pour le hach age des données du fi­
chier transparent sélectionné: 
‘00h’ pour SHA-1 
‘01h’ pour SHA-256 
‘02h’ pour SHA-384 
‘03h’ pour SHA-512  
TCS_125  Message de réponse 
Octet Longueur Valeur Descr iption 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
—  Si la commande aboutit, la carte renv oie l'état ‘9000’. 
—  Si l'EF actif n'autorise pas cette commande (EF Sensor_Installation_Data dans le DF 
Tachog raph_G2), le logiciel renv oie l'état de traitement ‘6985’. 
—  Si l'EF sélectionné est considéré comme altér é (une erreur d'intégrité est détectée dans les 
attributs du fichier ou dans les données enregistrées), le logiciel renv oie l'état de traitement 
‘6400’ ou ‘6581’ . 
—  Si le fichier sélectionné n'est pas un fichier transparent ou s'il n'existe aucun EF actif, le logiciel 
renv oie l'état de traite ment ‘6986’. 
3.5.14  PSO: COMPUTE DIGIT AL SIGNATURE 
Cette commande permet de calculer la signature numér ique du code de hachag e préalablement calculé (cf. 
commande PERFORM HASH of FILE, paragraphe 3.5.13). 
Seules les cartes de conduct eur et d'ate lier doivent prendre en charge cette commande dans le DF Tachograph 
et le DF Tachog raph_G2. 
D'autres types de cartes tach ygraphiques peuvent ou non mettre en œuvre cette commande, mais ne 
disposent d'aucune clé de signature. Par conséquent, ces cartes ne peuvent pas exécuter cette commande mais 
l'abandonnent avec un code d'erreur appropr ié. 
La commande peut ou non être accessible dans le MF. Dans ce cas, la commande est abandonnée avec un 
code d'erreur appropr ié. 26.5.2016 L 139/212 Jour nal officiel de l'Union européenne FR     
Cette commande est conf orme à la norme ISO/IEC 7816-8. Son usag e est restreint relativement à la norme 
en question. 
TCS_126 Cette commande ne doit pas calculer une signature numér ique pour un code de hachag e préala ­
blement calculé avec la commande PSO: HASH. 
TCS_127  La clé privée de la carte sert à calculer la signature numér ique et est implicitement connue de la 
carte. 
TCS_128  L'application tach ygraphique de génération 1 exécut e une signature numér ique à l'aide d'une 
méthode de rem plissage conf orme avec la norme PKCS1 (cf. appendice 11 pour tout e information 
complémentaire). 
TCS_129  L'application tach ygraphique de génération 2 calcule une signature numér ique basée sur une 
courbe ellip tique (cf. appendice 11 pour tout e information complémentaire). 
TCS_130  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘00h’ CLA 
INS 1 ‘2Ah’ Exécution d'une opération de sécur ité 
P1 1 ‘9Eh’ Signature numér ique à renv oyer 
P2 1 ‘9Ah’ Balise: zone de données contenant les données à signer . Comme aucune 
zone de données n'est incluse, les données sont supposées être déjà pré­
sentes sur la carte (hachag e du fichier) 
Le 1 ‘NNh’ Longueur de la signature attendue  
TCS_131  Message de réponse 
Octet Longueur Valeur Descr iption 
#1-#L L ‘XX..XXh’ Signature du hachag e préalablement calculé 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
—  Si la commande aboutit, la carte renv oie l'état ‘9000’. 
—  Si la clé privée implicit ement sélectionnée est considérée comme altérée, le logiciel renv oie 
l'état de traitem ent ‘6400’ ou ‘6581’ . 
—  Si le hach age calculé lors d'une exécution antérieure de la commande Perform Hash of File 
n'est pas disponible, le logiciel renv oie l'état de traitement ‘6985’ . 
3.5.15  PSO: VERIFY DIGIT AL SIGNATURE 
Cette commande sert à vérifier la signature numér ique fournie en entrée, dont la carte connaît le hachag e. La 
carte connaît implicitement l'algor ithme de signature. 
Cette commande est conf orme à la norme ISO/IEC 7816-8. Son usag e est restreint relativement à la norme 
en question. 
Seule la carte de contrôle doit prendre en charg e cette commande dans le DF Tachog raph et DF 
Tachog raph_G2. 
D'autres types de cartes tach ygraphiques peuvent ou non exécut er cette commande. La commande peut ou 
non être accessible dans le MF. 
TCS_132  La commande VERIFY DIGIT AL SIGNA TURE utilise touj ours la clé publique sélectionnée à l'aide 
de la précédente commande MANA GE SECURIT Y ENVIR ONMENT MSE: Set DST et du code de 
hachag e antér ieur introduit à l'aide d'une commande PSO: HASH. 26.5.2016 L 139/213 Jour nal officiel de l'Union européenne FR     
TCS_133  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘00h’ CLA 
INS 1 ‘2Ah’ Exécution d'une opération de sécur ité 
P1 1 ‘00h’  
P2 1 ‘A8h’ Balise: zone de données conte nant les DO pertinents pour la 
vérification 
Lc 1 ‘83h’ Longueur Lc de la zone de données suivante 
6 1 ‘9Eh’ Balise indiquant une signature numér ique 
#7-#8 2 ‘81 XXh’ Longueur de la signature numér ique: 
128 octets codés conf ormément à l'appendice 11 partie A 
pour l'application tach ygraphique de génération 1; 
selon la courbe retenue pour l'application tach ygraphique de 
génération 2 (cf. appendice 11 partie B). 
#9-#(8+L) L ‘XX..XXh’ Contenu de la signature numér ique  
TCS_134  Message de réponse 
Octet Longueur Valeur Descr iption 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
—  Si la commande aboutit, la carte renv oie l'état ‘9000’. 
—  Si la vérification de la signature échoue, le logiciel renv oie l'état de traite ment ‘6688’. La 
procédure de vérification figure en appendice 11. 
—  Si aucune clé publique n'est sélectionnée, le logiciel renv oie l'état de traitem ent ‘6A88’. 
—  S'il manque certains objets informatifs attendus (comme précisé ci-avan t), le logiciel renv oie 
l'état de traitement ‘6987’ . Cet événement est susceptible de se produire si l'une des balises 
requises fait défaut. 
—  Si aucun code de hachag e n'est disponible pour traiter la commande (en raison du trait ement 
d'une commande PSO: Hash antér ieure), le logiciel renv oie l'état de traite ment ‘6985’. 
—  Si certains objets informatifs sont incor rects, le logiciel renv oie l'état de trait ement ‘6988’. 
Cette erreur est susceptible de se produire si la longueur de l'un des objets informatifs requis 
est incor recte. 
—  Si la clé publique sélectionnée est considérée comme altérée, le logiciel renv oie l'état de 
traitement ‘6400’ ou ‘6581’ . 
3.5.16  PROCE SS DSRC MESSA GE 
Cette commande sert à vérifier l'inté grité et l'authenticité du message DSR C et à déchiffrer les données 
communiquées par une VU et adressées à une autori té de contrôle ou un atelier au moyen d'un lien DSR C. 
Cette carte extrait la clé de crypta ge et la clé MAC servant à sécur iser le message DSR C comme le décr it 
l'appendice 11 partie B chapitre 13. 
Seules les cartes de contrôle et d'atelier doivent prendre en charg e cette commande dans le DF 
Tachog raph_G2. 
D'autres types de cartes tach ygraphiques peuvent ou non mettre en œuvre cette commande, mais ne 
disposent d'aucune clé maîtresse DSR C. Par conséquent, ces cartes ne peuvent pas exécut er cette commande, 
mais l'abandonnent avec un code d'erreur appropr ié. 26.5.2016 L 139/214 Jour nal officiel de l'Union européenne FR     
La commande peut ou non être accessible dans le MF et/ou le DF Tachog raph. Dans ce cas, la commande est 
abandonnée avec un code d'erreur appropr ié. 
TCS_135  La clé maîtresse DSR C est accessible uniquement dans le DF Tachog raph_G2, c'est-à-dire que la 
carte de contrôle et d'ate lier doivent prendre en charg e l'exé cution de la commande uniquement 
dans le DF Tachog raph_G2. 
TCS_136 La commande doit uniquement décr ypter les données DSR C et vérifier le total de contrôle crypto­
graphique, mais sans interpréter les données d'entrée. 
TCS_137 L'ordre des objets informatifs dans la zone de données de la commande est défini par cette spécifi ­
cation. 
TCS_138  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘80h’ CLA propr iétaire 
INS 1 ‘2Ah’ Exécution d'une opération de sécur ité 
P1 1 ‘80h’ Données de réponse: valeur ordinaire 
P2 1 ‘B0h’ Données de la commande: valeur ordinaire co­
dée BER -TLV et incluant des SM-DO 
Lc 1 ‘NNh’ Longueur Lc de la zone de données suivante 
#6-#(5+L) L ‘87h’ + L87 + ‘XX..XXh’ Indicateur de conte nu de rem plissage codé DER - 
TLV suivi d'une charge tach ygraphique codée. 
Pour l'octet de l'indicate ur de contenu de rem ­
plissage, il est impératif d'utiliser la valeur ‘00h’ 
(‘aucune autre information’ conf ormément à la 
norme ISO/IEC 7816-4:2013 Tableau 52). 
Concer nant le mécanisme de cryptag e, cf. appen ­
dice 11 partie B chapitre 13. 
Les valeurs autorisées pour la longueur L87 sont 
les multiples de la longueur du bloc AES plus 1 
pour l'octet indicateur du contenu de remp lis­
sage, soit entre 17 octets et 193 octets inclus. 
Remarque: cf. ISO/IEC 7816-4:2013 Tableau 49 
pour l'objet informatif de la SM doté de la balise 
‘87h’. 
‘81h’ + ‘10h’ Gabar it de référence et de contrôle de la confi ­
dentialité codé DER -TLV destiné à héberg er la 
concaténation des éléments de données suivants 
(cf. appendice 1 DSR CSecur ityData et appendice 
11 partie B chapitre 13). 
—  timbre horodateur sur 4 octets; 
—  comp teur sur 3 octets; 
—  numéro de série de la VU sur 8 octets; 
—  version de la clé maîtresse DSR C sur 1 octet. 
Remarque: cf. ISO/IEC 7816-4:2013 Tableau 49 
pour l'objet informatif de la SM doté de la balise 
‘81h’. 
‘8Eh’ + L8E + ‘XX..XXh’ MAC codé DER -TLV sur le message DSR C. Pour 
l'algor ithme et le calcul des MAC, cf. appendice 
11 partie B chapitre 13. 
Remarque: cf. ISO/IEC 7816-4:2013 Tableau 49 
pour l'objet informatif de la SM doté de la balise 
‘8Eh’.  26.5.2016 L 139/215 Jour nal officiel de l'Union européenne FR     
TCS_139  Message de réponse 
Octet Longueur Valeur Descr iption 
#1-#L L ‘XX..XXh’ Données absentes (en cas d'erreur) ou déch iffrées (contenu de 
rem plissage suppr imé) 
SW 2 ‘XXXXh’ Mots d'état (SW1, SW2)  
—  Si la commande aboutit, la carte renv oie l'état ‘9000’. 
—  ‘6A80’ indique si des paramètres incor rects sont envoyés dans la zone de données de la 
commande (également utilisé dans le cas où les objets informatifs ne sont pas envoyés dans 
l'ordre spécifi é). 
—  ‘6A88’ indique que les données de référence (p.ex. la clé maîtresse DSR C mentionnée) ne sont 
pas disponibles. 
—  ‘6900’ indique l'échec de la vérification du total de contrôle cryptographique ou du décr yptag e 
des données. 
4.  STR UCTURE DES CARTES TACHY GRAPHIQUES 
Le présent paragraphe définit les structures de fichiers des cartes tach ygraphiques en vue du stoc kage des 
données accessibles. 
Il n'appor te aucune précision quant à leur structure interne, laquelle dépend du fabricant (en-têtes de fichier 
par exem ple). Il n'aborde pas non plus l'arc hivage et le traitement d'éléments de données à usage interne tels 
que les
 ,
 ,
 ou
 . 
TCS_140  Une carte tach ygraphique de génération 2 doit héberger le fichier maître (MF) et deux applications 
tach ygraphiques de génération 1 et de génération 2 de type identique (p. ex. des applications de 
cartes de conduct eur). 
TCS_141  Une carte tach ygraphique doit prendre en charge au moins le nombre d'enregistrements spécifiés 
pour les applications correspondante s et ne doit pas prendre en charge plus d'enregistrements que 
le nombre maximum d'enregistrements spécifi és pour les applications correspondantes . 
Les nombres minimum et maximum d'enregistrements sont définis au présent chapitre pour les 
différent es applications. 
Pour les conditions de sécur ité servant aux conditions d'accès dans le présent chapitre, consult er le 
chapitre 3.3. En règle générale, le mode d'accès «read» indique la commande READ BINAR Y avec 
les octets pairs et le cas échéant les octets impairs INS à l'exception de l'EF Sensor_Installa ­
tion_Data de la carte d'ateli er, cf. TCS_156 et TCS_160. Le mode d'accès «update » indique la 
commande Updat e Binar y avec les octets pairs et le cas échéant les octets impairs INS ainsi que le 
mode d'accès «select» et la commande SELECT . 
4.1.  Fichier Maître (MF) 
TCS_142  Après personnalisation, le fichier maître MF doit avoir la structure de fichier et les conditions 
d'accès au fichier permanentes suivantes: 
Remarque: l'identificateur d'EF cour t SFID est communiqué sous la forme d'un nombre décimal, p. 
ex. la valeur 30 correspond au nombre binaire 11110. 
26.5.2016 L 139/216 Jour nal officiel de l'Union européenne FR     
Dans ce tableau, est utilisée l'abréviation suivante pour la condition de sécur ité: 
SC1  ALW OU SM-MA C-G2 
TCS_143  La structure de tous les EF doit être transparent e. 
TCS_144  Le fichier maître MF doit avoir la structure de données suivante: 
TCS_145  Le fichier élémentaire EF DIR doit contenir les objets informatifs liés à l'application suivants: ‘61 
08 4F 06 FF 54 41 43 48 4F 61 08 4F 06 FF 53 4D 52 44 54’ 
TCS_146  Le fichier élémentaire EF ATR/INFO doit être présent si la carte tach ygraphique indique dans son 
ATR qu'elle prend en charge des zones de longueur étendue. Dans ce cas, l'EF ATR/INFO doit 
contenir les objets informatifs de longueur étendue (DO‘7F66’) conf ormément à la norme ISO/IEC 
7816-4:2013 clause 12.7.1. 
TCS_147  Le fichier élémentaire EF Exten ded_Length doit être présent si la carte tach ygraphique indique dans 
son ATR qu'elle prend en charge des zones de longueur étendue. Dans ce cas, l'EF doit cont enir 
l'objet informatif suivant: ‘02 01 xx’ dont la valeur ‘xx’ indique si les zones de longueur étendue 
sont prises en charge pour les protocoles T = 1 et/ou T = 0. 
La valeur ‘01’ indique que la zone de longueur étendue est prise en charge pour le protocole 
T = 1. 
La valeur ‘10’ indique que la zone de longueur étendue est prise en charge pour le protocole 
T = 0. 
La valeur ‘11’ indique que la zone de longueur étendue est prise en charge pour les protocoles 
T = 1 et T = 0. 
4.2.  Applications des cartes de conducteur 
4.2.1  Application de la carte de conducteur de génération 1 
TCS_148  Après personnalisation, l'application de la carte de conduct eur de génération 1 doit avoir la 
structure de fichier et les conditions d'accès au fichier permanentes suivantes: 26.5.2016 L 139/217 Jour nal officiel de l'Union européenne FR     
Dans le tableau ci-dessus, sont utilisées les abréviations suivantes concer nant les conditions de 
sécur ité: 
SC1  ALW OU SM-MA C-G2 
SC2  ALW OU SM-MA C-G1 OU SM-MA C-G2 
SC3  SM-MA C-G1 OU SM-MA C-G2 
TCS_149  La structure de tous les EF doit être transparent e. 
TCS_150  L'application de la carte de conduct eur de génération 1 doit avoir la structure de données suivante :   26.5.2016 L 139/218 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/219 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/220 Jour nal officiel de l'Union européenne FR     
TCS_151  Les valeurs suivantes , qui servent à fournir les tailles dans le tableau ci-dessus, correspondent aux 
valeurs de nombre de relevés minimum et maximum que doit utiliser la structure des données de 
la carte du conducteur pour une application de génération 1: 
4.2.2  Application de la carte de conducteur de génération 2 
TCS_152  Après personnalisation, l'application de la carte de conduct eur de génération 2 doit avoir la 
structure de fichier et les conditions d'accès au fichier permanentes suivantes. 
Remarque: l'identificateur d'EF cour t SFID est communiqué sous la forme d'un nombre décimal, p. 
ex. la valeur 30 correspond au nombre binaire 11110. 
Dans le tableau ci-dessus, est utilisée l'abréviation suivante concer nant la condition de sécur ité: 
SC1  ALW OU SM-MA C-G2 
TCS_153  La structure de tous les EF doit être transparent e. 
TCS_154  L'application de la carte de conduct eur de génération 2 doit avoir la structure de données suivante :   26.5.2016 L 139/221 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/222 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/223 Jour nal officiel de l'Union européenne FR     
TCS_155  Les valeurs suivantes , qui servent à fournir les tailles dans le tableau ci-dessus, correspondent aux 
valeurs de nombre de relevés minimum et maximum que doit utiliser la structure des données de 
la carte du conducteur pour une application de génération 2: 
4.3.  Applications de la carte d'atelier 
4.3.1  Application de la carte d'atelier de génération 1 
TCS_156  Après personnalisation, l'application de la carte d'atelier de génération 1 doit avoir la structure de 
fichier et les conditions d'accès au fichier permanentes suivantes:  26.5.2016 L 139/224 Jour nal officiel de l'Union européenne FR     
Dans le tableau ci-dessus, sont utilisées les abréviations suivantes concer nant les conditions de 
sécur ité: 
SC1  ALW OU SM-MA C-G2 
SC2  ALW OU SM-MA C-G1 OU SM-MA C-G2 
SC3  SM-MA C-G1 OU SM-MA C-G2 
SC4  Concer nant la commande READ BINAR Y avec des octets pairs INS: 
(PLAIN-C AND SM-R -ENC-G1) OU (SM-C-MA C-G1 AND SM-R -ENC-MA C-G1) OU 
(SM-C-MA C-G2 AND SM-R -ENC-MA C-G2) 
Pour la commande READ BINAR Y avec octet impair INS (si pris en charge): NEV 
TCS_157  La structure de tous les EF doit être transparent e. 
TCS_158  L'application de la carte d'ateli er de génération 1 doit avoir la structure de données suivante:   26.5.2016 L 139/225 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/226 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/227 Jour nal officiel de l'Union européenne FR     
TCS_159  Les valeurs suivantes , qui servent à fournir les tailles dans le tableau ci-dessus, correspondent aux 
valeurs de nombre de relevés minimum et maximum que doit utiliser la structure des données de 
la carte d'ateli er pour une application de génération 1: 
4.3.2  Application de la carte d'atelier de génération 2 
TCS_160  Après personnalisation, l'application de la carte d'atelier de génération 2 doit avoir la structure de 
fichier et les conditions d'accès au fichier permanentes suivantes. 
Remarque: l'identificateur d'EF cour t SFID est communiqué sous la forme d'un nombre décimal, p. 
ex. la valeur 30 correspond au nombre binaire 11110.  26.5.2016 L 139/228 Jour nal officiel de l'Union européenne FR     
Dans le tableau ci-dessus, sont utilisées les abréviations suivantes concer nant les conditions de 
sécur ité: 
SC1  ALW OU SM-MA C-G2 
SC5  Concer nant la commande Read Binar y avec des octets pairs INS: SM-C-MA C-G2 ET SM-R - 
ENC-MA C-G2 
Concer nant la commande Read Binar y avec des octets impairs INS (si pris en charge): NEV 
TCS_161  La structure de tous les EF doit être transparent e. 
TCS_162  L'application de la carte d'ateli er de génération 2 doit avoir la structure de données suivante:   26.5.2016 L 139/229 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/230 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/231 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/232 Jour nal officiel de l'Union européenne FR     
TCS_163  Les valeurs suivantes , qui servent à fournir les tailles dans le tableau ci-dessus, correspondent aux 
valeurs de nombre de relevés minimum et maximum que doit utiliser la structure des données de 
la carte d'ateli er pour une application de génération 2: 
4.4.  Applications de la carte de contrôle 
4.4.1  Application de la carte de contrô le de génération 1 
TCS_164  Après personnalisation, l'application de la carte de contrôle de génération 1 doit avoir la structure 
de fichier et les conditions d'accès au fichier permanent es suivantes: 
Dans le tableau ci-dessus, sont utilisées les abréviations suivantes concer nant les conditions de 
sécur ité: 
SC1  ALW OU SM-MA C-G2 
SC2  ALW OU SM-MA C-G1 OU SM-MA C-G2 
SC3  SM-MA C-G1 OU SM-MA C-G2 
SC6  EXT -AUT-G1 OU SM-MA C-G1 OU SM-MA C-G2 
TCS_165  La structure de tous les EF doit être transparent e. 
TCS_166  L'application de la carte de contrôle de génération 1 doit avoir la structure de données suivante:   26.5.2016 L 139/233 Jour nal officiel de l'Union européenne FR     
TCS_167  Les valeurs suivantes , qui servent à fournir les tailles dans le tableau ci-dessus, correspondent aux 
valeurs de nombre de relevés minimum et maximum que doit utiliser la structure des données de 
la carte de contrôle pour une application de génération 1: 
4.4.2  Application de la carte de contrô le de génération 2 
TCS_168  Après personnalisation, l'application de la carte de contrôle de génération 2 doit avoir la structure 
de fichier et les conditions d'accès au fichier permanent es suivantes: 
Remarque: l'identificateur d'EF cour t SFID est communiqué sous la forme d'un nombre décimal, p. 
ex. la valeur 30 correspond au nombre binaire 11110. 26.5.2016 L 139/234 Jour nal officiel de l'Union européenne FR     
Dans le tableau ci-dessus, est utilisée l'abréviation suivante concer nant la condition de sécur ité: 
SC1  ALW OU SM-MA C-G2 
TCS_169  La structure de tous les EF doit être transparent e. 
TCS_170  L'application de la carte de contrôle de génération 2 doit avoir la structure de données suivante:   26.5.2016 L 139/235 Jour nal officiel de l'Union européenne FR     
TCS_171  Les valeurs suivantes , qui servent à fournir les tailles dans le tableau ci-dessus, correspondent aux 
valeurs de nombre de relevés minimum et maximum que doit utiliser la structure des données de 
la carte de contrôle pour une application de génération 2: 
4.5.  Applications de la carte d'entrepr ise 
4.5.1  Application de la carte d'entrep rise de génér ation 1 
TCS_172  Après personnalisation, l'application de la carte d'entrepr ise de génération 1 doit avoir la structure 
de fichier et les conditions d'accès au fichier permanent es suivantes: 26.5.2016 L 139/236 Jour nal officiel de l'Union européenne FR     
Dans le tableau ci-dessus, sont utilisées les abréviations suivantes concer nant les conditions de 
sécur ité: 
SC1  ALW OU SM-MA C-G2 
SC2  ALW OU SM-MA C-G1 OU SM-MA C-G2 
SC3  SM-MA C-G1 OU SM-MA C-G2 
SC6  EXT -AUT-G1 OU SM-MA C-G1 OU SM-MA C-G2 
TCS_173  La structure de tous les EF doit être transparent e. 
TCS_174  L'application de la carte d'entrepr ise de génération 1 doit avoir la structure de données suivante: 
26.5.2016 L 139/237 Jour nal officiel de l'Union européenne FR     
TCS_175  Les valeurs suivantes , qui servent à fournir les tailles dans le tableau ci-dessus, correspondent aux 
valeurs de nombre de relevés minimum et maximum que doit utiliser la structure des données de 
la carte d'entrepr ise pour une application de génération 1: 
4.5.2  Application de la carte d'entrep rise de génér ation 2 
TCS_176  Après personnalisation, l'application de la carte d'entrepr ise de génération 2 doit avoir la structure 
de fichier et les conditions d'accès au fichier permanent es suivantes: 
Remarque: l'identificateur d'EF cour t SFID est communiqué sous la forme d'un nombre décimal, p. 
ex. la valeur 30 correspond au nombre binaire 11110. 
Dans le tableau ci-dessus, est utilisée l'abréviation suivante concer nant les conditions de sécur ité: 
SC1  ALW OU SM-MA C-G2 
TCS_177  La structure de tous les EF doit être transparent e. 
TCS_178  L'application de la carte d'entrepr ise de génération 2 doit avoir la structure de données suivante:   26.5.2016 L 139/238 Jour nal officiel de l'Union européenne FR     
TCS_179  Les valeurs suivantes , qui servent à fournir les tailles dans le tableau ci-dessus, correspondent aux 
valeurs de nombre de relevés minimum et maximum que doit utiliser la structure des données de 
la carte d'entrepr ise pour une application de génération 2: 
26.5.2016 L 139/239 Jour nal officiel de l'Union européenne FR     
Appendice 3 
PICTOGRAMMES 
PIC_001  Le tach ygraphe est susceptible d'emplo yer les pictogrammes et combinaisons de pictogrammes qui suivent (ou 
des pictogrammes et combinaisons de pictogrammes suffisamment semblables pour être identifiables à ceux-ci 
sans ambiguïté ):  
1. PICTOGRAMMES DE BASE  
Ressources humaines Actions Modes d'exploitation 
Entrepr ise  Mode entrepr ise 
Contrôleur Contrôle Mode de contrôle 
Conducteur Route Mode opérationnel 
Atelier/P oste d'essai Inspection/Étalonnage Mode étalonnage 
Fabr icant     
Activités Durée 
Disponible Période de disponibilité en 
cours 
Conduite Temps de conduite continue 
Repos Période de repos en cours 
Autres tâches Période de travail en cours 
Pause Temps de pause cumulé 
Inconnue    
Équipements Fonctions 
Lecteur «conducteur »  
Lecteur «con voyeur»  
Carte  
Horloge  
Écran Afficha ge 
Mémoire exte rne Télécharg ement 
Alimentation  
Impr imante /Tirage Impression 
Capt eur  
Type de pneumatique  
Véhicule/Unit é embarquée 
sur le véhicule (UEV)  
Dispositif GNSS  
Dispositif de détec tion à dis­
tance  
Interface STI    
Conditions spécif iques 
Hors limites 
Traver sée en ferry/train  26.5.2016 L 139/240 Jour nal officiel de l'Union européenne FR     
Div ers   
Évènements 
 Anomalies 
Début de la période jour nalière de tra­
vail 
Fin de la période jour nalière de travail 
Adresse   
Saisie manuelle des activités du 
conducteur   
Sécur ité   
Vitesse   
Temps   
Total/Synthèse     
Qualif icatifs 
24h Jour nalier 
Hebdomadaire 
Bihebdomadaire 
De ou vers   
2. COMBINAISONS DE PICTOGRAMMES  
Div ers   
Lieu du contrôle   
Site de début de la période de travai l 
jour nalière 
Site de fin de la période de travail jour ­
nalière 
De (heure) 
 À (heure) 
Du véhicule   
Hors limites, début 
 Hors limite s, fin   
Car tes 
Carte du conduct eur 
Carte d'entrepr ise 
Carte de contrôleur 
Carte d'atelier 
Pas de carte   
Route 
Conduite en équipag e 
Temps de conduite hebdomadaire 
Temps de conduite bihebdomadaire   
Tirages 
Tirage quotidien des activités du conduct eur extrait es de la carte 
Tirage quotidien des activités du conduct eur extrait es de l'UEV 
Tirage des anomalies et événements extraits d'une carte 
Tirage des anomalies et événements extraits de l'UEV 
Tirage des données techniques 
Tirage des dépassements de la vitesse autori sée  26.5.2016 L 139/241 Jour nal officiel de l'Union européenne FR     
Événements 
Inser tion d'une carte erronée 
Conf lit de carte 
Dépassement du temps impar ti 
Conduite sans carte appropr iée 
Inser tion d'une carte en cours de rout e 
Clôture incor recte de la dernière session 
Dépassement de la vitesse autorisée 
Coupure d'alimentation électr ique 
Erreur au niveau des données de mouvement 
Conf lit concer nant le mouvement du véhicule 
Atteinte à la sécur ité 
Réglage de l'heure (en ateli er) 
Contrôle de dépassement de la vitess e autori sée   
Défauts 
Carte défectueuse (logeme nt de carte du conducteur) 
Carte défectueuse (logeme nt de carte du conv oyeur) 
Anomalie de l'affi chage 
Anomalie de téléc hargement 
Anomalie de l'impr imant e 
Anomalie du capt eur 
Défaillance interne de la VU 
Anomalie du dispositif GNSS 
Anomalie de détection à distance   
Procédure de saisie manuelle 
Même période jour nalière de travail? 
Fin de la période de travail antérie ure? 
Confi rmation ou saisie du lieu de fin de la période de travail 
Saisie de l'heure de dépar t 
Saisie du lieu de début de la période de travail.  
Remar que: diverses combinaisons de pictogrammes supplémentaires associées à autant d'identif icate urs d'enre ­
gistrement ou de blocs d'impression sont définies à l'appendice 4.   26.5.2016 L 139/242 Jour nal officiel de l'Union européenne FR     
Appendice 4 
TIRA GES PAPIER 
TABLE DES MATIÈRES 
1. GÉNÉRALITÉS ................................................................................................................................... 243 
2. CARA CTÉRISTIQUES DES BLOCS DE DONNÉES ........................................................................................ 243 
3. CARA CTÉRISTIQUES DES TIRA GES PAPIER .............................................................................................. 250 
3.1. Tirage quotidien des activités du conduct eur extraites d'une carte...................................................... 250 
3.2. Tirage quotidien des activités du conduct eur extraites de la VU ......................................................... 251 
3.3. Tirage des anomalies et événements extraits d'une carte.................................................................. 252 
3.4. Tirage des anomalies et événements extraits de la VU ..................................................................... 252 
3.5. Tirage des données techniques ................................................................................................... 253 
3.6. Tirage des dépassements de la vitess e autori sée ............................................................................. 253 
3.7. Histori que des cartes insérées .................................................................................................... 254  
1.  GÉNÉRALITÉS 
Toute sortie imprimée se compo se d'une succession de blocs de données séquencés susceptibles d'être désignés 
par un identificateur de bloc. 
Un bloc de données contient un ou plusieurs enregistrements désignés, le cas échéant, par un identif icate ur 
d'enregistrement. 
PRT_001  Si un identif icateur de bloc précède immédiate ment un identificateur d'enregistrement, ce dernier n'est 
pas imprimé. 
PRT_002  Si un élément d'inf ormation est inconnu ou ne doit pas être imprimé en raison de l'exist ence de droits 
d'accès aux données, le système impr ime des espaces en lieu et place de ces éléments. 
PRT_003 Si le cont enu d'une ligne compl ète est inconnu ou ne nécessite aucune impression, la ligne corres­
pondante est omise. 
PRT_004  Les champs de données numér iques sont justif iés à droite au tirage , leur impression s'accom pagnant 
d'espaces de séparation marquant le passage des centaines aux milliers et des milliers aux millions, sans 
compo rter de zéros en tête. 
PRT_005  Les champs constitués de chaînes de caractères sont justif iés à gauc he au tirag e et, le cas échéant, 
complét és d'espaces pour atteindre la longueur élémentaire requise ou tronqués pour la même raison 
(noms et adresses). 
PRT_006  Si la longueur du texte impose un retour à la ligne, la nouvelle ligne impr imée doit commencer par un 
caractère spécial (un point à mi-hauteur , «•»). 
2.  CARA CTÉRISTIQUES DES BLOCS DE DONNÉES 
Dans ce chapitre, les convention s de notation suivantes ont été appliquées: 
—  les caractères affichés en gras identif ient le texte en clair à impr imer (au tirage , les caractères sont normaux), 
—  les caractères normaux indiquent à l'affi chage des variables (pictog rammes ou données) rem placées au tirag e 
par leurs valeurs respectives, 
—  les noms de variable s'accompagnent de traits de soulignement indiquant la longueur élémentaire disponible 
pour la variable considérée, 
—  les date s respectent par défa ut le format «jj/mm/aaaa» (jour , mois, année). L'application du format «jj.mm.aaaa» 
est également envisageable, 
—  la rubrique «identifi cation de carte» se compo se des éléments suivants: type de carte indiqué par une 
combinaison de pictogrammes, code de l'État membre d'émission de la carte, barre oblique suivie du numéro 
de la carte, puis d'un indice de remplacement et d'un indice de renouvellement séparés tous deux de l'élément 
qui les précède par un espace: 
P 
 x x x / x x x x x x x x x x x x x x  x  x Combinaison 
de pictogrammes 
Code de l'État 
membre d'émission  14 premiers caractères du numéro de la carte 
(comp renant, le cas échéant, un indice séquentiel)  
Indice de 
remplacement  
Indice de 
renouvellement  26.5.2016 L 139/243 Jour nal officiel de l'Union européenne FR     
PRT_007 Les tirage s se compo sent des blocs et/ou enregistrements de données qui suivent. Leur signif ication et leur 
format sont les suivants: 
26.5.2016 L 139/244 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/245 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/246 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/247 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/248 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/249 Jour nal officiel de l'Union européenne FR     
3.  CARA CTÉRISTIQUES DES TIRA GES PAPIER 
Dans ce chapitre, les convention s de notation suivantes ont été appliquées: 
N Impression du bloc ou de l'enregistrement numéro N  
N Impression du bloc ou de l'enregistrement numéro N répété autant de fois que l'exig e 
la situation  
X/Y Impression des blocs ou enregistrements X et/ou Y selon les besoins, et répétition de 
l'opération autant de fois que l'exige la situation.  
3.1.  Tirage quotidien des activités du conducteur extraites d'une carte 
PRT_008 Le tirage quotidien des activités du conducteur extraite s d'une carte doit respecter le format suivant : 
1 Date et heure d'imp ression du document 
2 Type de document impr imé 
3 Identif ication du contrôleur (en cas d'inser tion d'une carte de contrôle dans la VU) 
3 Identif ication du conduct eur (extraite de la carte faisant l'objet de l'impre ssion + GEN) 
4 Identif ication du véhicule (à partir duquel le tirage est exécuté) 
5 Identif ication de la VU (à partir de laquelle le tirage est exécuté + GEN) 
6 Dernier étalonnage de cette VU 
7 Dernier contrôle auquel le conduct eur inspecté a été soumis 
8 Délimiteur des activités du conducteur 
8a Condition hors champ au début de cette jour née 
8.1a / 8.1b / 8.1c / 8.2 / 
8.3 / 8.3a / 8.4 Activit és du conduct eur par ordre chronologique 
11 Délimiteur de synthèse quotidienne 26.5.2016 L 139/250 Jour nal officiel de l'Union européenne FR     
11.4 Lieux saisis par ordre chronologique 
11.5 Données du GNSS 
11.6 Totaux par activité 
12.1 Délimiteur des événements et anomalies extraits d'une carte 
12.4 Enregistrements d'événements/anomalies (5 derniers événements ou anomalies enre ­
gistrés sur la carte) 
13.1 Délimiteur des événements ou anomalies extraits de la VU 
13.4 Enregistrements d'événements/anomalies (5 derniers événements ou anomalies enre ­
gistrés ou en cours dans la VU) 
22.1 Lieu du contrôle 
22.2 Signature du contrôleur 
22.5 Signature du conducteur  
3.2.  Tirage quotidien des activités du conducteur extraites de la VU 
PRT_009 Le tirage quotidien des activités du conducteur extraite s de la VU doit respecter le format suivant : 
1 Date et heure d'imp ression du document 
2 Type de document impr imé 
3 Identif ication du titulaire de la carte (pour tout es les cartes insérées dans la VU + 
GEN) 
4 Identif ication du véhicule (à partir duquel le tirage est exécuté) 
5 Identif ication de la VU (à partir de laquelle le tirage est exécuté + GEN) 
6 Dernier étalonnage de cette VU 
7 Dernier contrôle auquel ce tach ygraphe a été soumis 
9 Délimiteur des activités du conducteur 
10 Délimiteur de lecteur de carte du conduct eur (lecteur 1) 
10a Condition hors champ au début de cette jour née 
10.1 / 10.2 / 10.3 
/10.3a / 10.4 Activit és par ordre chronologique (lect eur conducteur) 
10 Délimiteur de lecteur de carte du conv oyeur (lect eur 2) 
10a Condition hors champ au début de cette jour née 
10.1 / 10.2 / 10.3 
/10.3a / 10.4 Activit és par ordre chronologique (lect eur conv oyeur) 
11 Délimiteur de synthèse quotidienne 
11.1 Synthèse des périodes sans carte dans le lecteur du conduct eur 
11.4 Lieux saisis par ordre chronologique 
11.5 Données du GNSS 
11.6 Totaux par activité 
11.2 Synthèse des périodes sans carte dans le lecteur du conv oyeur 
11.4 Lieux saisis par ordre chronologique 
11.5 Données du GNSS 26.5.2016 L 139/251 Jour nal officiel de l'Union européenne FR     
11.7 Totaux par activité 
11.3 Synthèse des activités par conduct eur, les deux lecteur s étant inclus  
11.4  Lieux saisis par ce conducteur , par ordre chronologique 
11.5 Données du GNSS 
11.8 Totaux par activité pour ce conduct eur 
13.1 Délimiteur d'événements et d'anomalies 
12.4 Enregistrements d'événements/anomalies (5 derniers événements ou anomalies enre ­
gistrés ou en cours dans la VU) 
13.1 Lieu du contrôle 
22.2 Signature du contrôleur 
22.3 De (heure) (espace disponible pour un conduct eur dépour vu de carte lui per­
mettant d'indiquer les périodes qui correspondent à ses prestations) 
22.4 À (heure) 
22.5 Signature du conducteur  
3.3.  Tirage des anomalies et événements extraits d'une carte 
PRT_010 Le tirage des anomalies et événements extraits d'une carte doit respecter le format suivant : 
1 Date et heure d'imp ression du document 
2 Type de document impr imé 
3 Identif ication du contrôleur (en cas d'inser tion d'une carte de contrôle dans la VU + 
GEN) 
3 Identif ication du conducteur (extraite de la carte faisant l'objet de l'impr ession) 
4 Identif ication du véhicule (à partir duquel le tirage est exécuté) 
12.2 Délimiteur des événements 
12.4 Enregistrements d'événements (tous les événements enregistrés sur la carte) 
12.3 Délimiteur des anomalies 
12.4 Enregistrements d'anomalies (tout es les anomalies enregistrées sur la carte) 
22.1 Lieu du contrôle 
22.2 Signature du contrôleur 
22.5 Signature du conducteur  
3.4.  Tirage des anomalies et événements extraits de la VU 
PRT_011 Le tirage des anomalies et événements extraits de la VU doit respecte r le format suivant: 
1 Date et heure d'imp ression du document 
2 Type de document impr imé 
3 Identif ication du titulaire de la carte (pour tout es les cartes insérées dans la VU + 
GEN) 
4 Identif ication du véhicule (à partir duquel le tirage est exécuté) 26.5.2016 L 139/252 Jour nal officiel de l'Union européenne FR     
13.2 Délimiteur des événements 
13.4 Enregistrements d'événements (tous les événements enregistrés ou en cours dans la 
VU) 
13.3 Délimiteur des anomalies 
13.4 Enregistrements d'anomalies (toutes les anomalies enregistrées ou en cours dans la 
VU) 
22.1 Lieu du contrôle 
22.2 Signature du contrôleur 
22.5 Signature du conducteur  
3.5.  Tirage des données techniques 
PRT_012 Le tirage des données techniques doit respecte r le format suivant: 
1 Date et heure d'imp ression du document 
2 Type de document impr imé 
3 Identif ication du titulaire de la carte (pour tout es les cartes insérées dans la VU + 
GEN) 
4 Identif ication du véhicule (à partir duquel le tirage est exécuté) 
14 Identif ication de la VU 
15 Identif ication des capt eurs 
15.1 Données relatives au couplage des capt eurs (toutes les données disponibles, par ordre 
chronologique) 
16 Identif ication du GNSS 
16.1 Données relatives au couplage du dispositif GNSS extern e (toutes les données disponi ­
bles, par ordre chronologique) 
17 Délimiteur des données d'étalonnag e 
17.1 Enregistrements d'étalonnag e (ensemble des enregistrements disponibles par ordre 
chronologique) 
18 Délimiteur de la remise à l'heure 
18.1 Enregistrement de la remise à l'heure (ensemble des enregistrements disponibles, ex­
traits des enregistrements de la remise à l'heure et des données d'étalonnag e) 
19 Événement et anomalie les plus récents enregistrés dans la VU  
3.6.  Tirage des dépassements de la vitesse autor isée 
PRT_013 Le tirage des dépassements de la vitesse autor isée doit respecter le format suivant : 
1 Date et heure d'imp ression du document 
2 Type de document impr imé 
3 Identif ication du titulaire de la carte (pour tout es les cartes insérées dans la VU + 
GEN) 
4 Identif ication du véhicule (à partir duquel le tirage est exécuté) 
20 Informations relatives au contrôle de dépassement de la vitesse autor isée 
21.1 Identif icateur des données de dépassement de la vitesse autor isée 
21.4 / 21.5 Premier dépassement de la vitesse autori sée après le dernier étalonnage 26.5.2016 L 139/253 Jour nal officiel de l'Union européenne FR     
21.2 Identif icateur des données de dépassement de la vitesse autor isée 
21.4 / 21.5 Les 5 dépassements les plus sérieux relevés au cours des 365 derniers jours écoulés 
21.3 Identif icateur des données de dépassement de la vitesse autor isée 
21.4 / 21.5 Le dépassement le plus sérieux pour chacune des périodes coïncidant avec les dix der­
niers jours de manife station 
22.1 Lieu du contrôle 
22.2 Signature du contrôleur 
22.5 Signature du conducteur  
3.7.  Histor ique des cartes insérées 
PRT_014 Le tirage de l'histori que des cartes insérées doit respecter le format suivant : 
1 Date et heure d'imp ression du document 
2 Type de document impr imé 
3 Identif ications du titulaire de la carte (pour tout es les cartes insérées dans la VU) 
23 Cartes les plus récent es insérées dans la VU 
23.1 Cartes insérées (jusqu'à 88 enregistrements) 
12.3 Délimiteur des anomalies   26.5.2016 L 139/254 Jour nal officiel de l'Union européenne FR     
Appendice 5 
AFFICHA GE 
Les conventions de présentation suivantes s'appliquent dans le présent appendice: 
—  les caractères gras indiquent le texte à afficher (l'affichage demeure en caractères normaux), 
—  les caractères normaux indiquent des variables (pictogrammes ou données) à remplacer par leurs valeurs respectives 
à l'affi chage:  
— jj mm aaaa:  jour , mois, année,  
— hh:  heures,  
— mm:  minutes,  
— D:  pictogramme de durée,  
— EF:  combinaison de pictogrammes d'événement ou d'anomalie,  
— O:  pictogramme de mode d'exploitation. 
DIS_001  Le tach ygraphe emploie les formats d'affichag e des données suivants: 
Données Format 
Affichage par défaut 
Heure locale 
Mode d'exploitation 
Informations relatives au conduct eur 
Informations relatives au conv oyeur 
Condition hors limite s 
Affichage d'avertissements 
Dépassement du temps de conduite continue 
Événement ou anomalie 
Autres affichages 
Date UTC 
Heure 
Temps de conduite continue et temps de pause cumulé du conduct eur 
Temps de conduite continue et temps de pause cumulé du convoyeur 
Temps de conduit e cumulé du conducteur , enregistré pendant la semaine en 
cours et la semaine précédente 
Temps de conduit e cumulé du conv oyeur, enregistré pendant la semaine en 
cours et la semaine précédente 
26.5.2016 L 139/255 Jour nal officiel de l'Union européenne FR     
Appendice 6 
CONNECTEUR FRONT AL POUR L'ÉT ALONNA GE ET LE TÉLÉC HAR GEMENT 
TABLE DES MATIÈRES 
1. MATÉRIEL .......................................................................................................................................... 256 
1.1. Connecteur ............................................................................................................................. 256 
1.2. Affectation des contacts ............................................................................................................. 257 
1.3. Schéma fonctionnel .................................................................................................................. 258 
2. INTERF ACE DE TÉLÉCHAR GEMENT .......................................................................................................... 258 
3. INTERF ACE D'ÉT ALONNA GE................................................................................................................... 259   
1.  MATÉRIEL 
1.1.  Connecteur 
INT_001  Le connect eur de téléc hargement/étalonnag e doit se présenter sous la forme d'un connecte ur à 
6 broches, accessible sur la face avant sans nécessiter la déconnexion d'aucun orga ne du tach ygraphe. Il 
doit être conf orme au plan suivant (tout es les cotes sont en millimètres): 
26.5.2016 L 139/256 Jour nal officiel de l'Union européenne FR     
Le schéma suivant illustre une fiche classique d'accouplement à 6 broches: 
1.2.  Affectation des contact s 
INT_002  L'affectation des contacts doit être conf orme au tableau suivant : 
Pin Descr iption Remarque 
1 Pôle négatif de la batt erie Raccordé à la borne négativ e de la batter ie mont ée sur le vé­
hicule 
2 Communication de données Ligne K (ISO 14230-1) 26.5.2016 L 139/257 Jour nal officiel de l'Union européenne FR     
Pin Descr iption Remarque 
3 RxD — Téléc hargem ent Entrée de données dans le tach ygraphe 
4 Signal d'entrée/sor tie Étalonnag e 
5 Puissance de sortie perma­
nent e La plag e de tensions doit être identique à celle de l'alimenta ­
tion électr ique du véhicule diminuée de 3 V afin de tenir 
comp te de la chut e de tension inhérente au passage du cou­
rant à travers les circuits de protection 
Sortie 40 mA 
6 TxD — Téléc hargement Sortie de données du tach ygraphe   
1.3.  Schéma fonctionnel 
INT_003  Le schéma fonctionnel doit être conf orme aux indications suivantes: 
2.  INTERF ACE DE TÉLÉC HAR GEMENT 
INT_004  L ' interface de téléc hargement doit être conf orme aux spécifications de la norme RS232. 
INT_005  L'interface de téléc hargem ent doit utiliser un bit de dépar t, huit bits d'inf ormation (bit le moins 
signif icatif en tête), un bit de parité pair et un bit d'arrêt. 
Agencement d'un octet d'infor mation 
Bit de dépar t:  un bit de niveau logique 0; 
Bits d'inf ormation:  transmis avec le bit le moins signif icatif en tête; 
Bit de parité:  parité paire 
Bit d'arrêt:  un bit de niveau logique 1; 26.5.2016 L 139/258 Jour nal officiel de l'Union européenne FR     
En cas de transmission de données numér iques compo sées de plus d'un octet, l'octet le plus signif icatif est transmis 
en premier , l'octet le moins signif icatif en dernier. 
INT_006  Les débits de transmission doivent être réglables dans une plage compris e entre 9 600 et 115 200 bits 
par seconde. Toute transmission doit s'opérer à la vitesse de transmission la plus élevée possible, le débit 
initial étant égal à 9 600 bits par seconde immédiatement après le début d'une communication. 
3.  INTERF ACE D'ÉT ALONNA GE 
INT_007  La communication de données doit être conf orme aux spécific ations de la norme ISO 14230-1 
Véhicules routiers — Systèmes de diagnostic — Protocol e à mots clés 2000 — Partie 1: Couc he 
physique. Première édition: 1999. 
INT_008  Le signal d'entrée/sor tie doit être conf orme aux spécifi cations électr iques suivantes: 
Paramètre Minimum Caractéristique Maximum Remarque 
U low (entrée)   1,0 V I = 750 µA 
U high (entrée) 4 V   I = 200 µA 
Fréquence   4 kHz  
U low (sor tie)   1,0 V I = 1 mA 
U high (sor tie) 4 V   I = 1 mA   
INT_009  Le signal d'entrée/sor tie doit être conf orme aux chronogrammes suivants: 
26.5.2016 L 139/259 Jour nal officiel de l'Union européenne FR     
Appendice 7 
PROTOCOLES DE TÉLÉCHARGEME NT DE DONNÉES 
TABLE DES MATIÈRES 
1. INTR ODUCTION ............................................................................................................................ 261 
1.1. Champ d'application ........................................................................................................... 261 
1.2. Abréviations et notations ..................................................................................................... 261 
2. TÉLÉCHAR GEMENT DE DONNÉES SUR LA VU ...................................................................................... 262 
2.1. Procédure de téléc hargement ................................................................................................. 262 
2.2. Prot ocole de télécharg ement des données ................................................................................. 262 
2.2.1 Structure des messages ........................................................................................................ 262 
2.2.2 Types de message ............................................................................................................... 264 
2.2.2.1 Star t Communication Request (SID 81) ................................................................................... 266 
2.2.2.2 Positive Response Star t Communication (SID C1) ...................................................................... 266 
2.2.2.3 Star t Diagnostic Session Request (SID 10) ................................................................................ 266 
2.2.2.4 Positive Response Star t Diagnostic (SID 50) ............................................................................. 266 
2.2.2.5 Link Control Service (SID 87) ............................................................................................... 266 
2.2.2.6 Link Control Positive Response (SID C7) ................................................................................. 266 
2.2.2.7 Request Upload (SID 35) ...................................................................................................... 266 
2.2.2.8 Positive Response Request Upload (SID 75) .............................................................................. 266 
2.2.2.9 Transf er Data Request (SID 36) .............................................................................................. 266 
2.2.2.10 Positive Response Transfer Data (SID 76) ................................................................................. 267 
2.2.2.11 Request Transfer Exit (SID 37) ............................................................................................... 267 
2.2.2.12 Positive Response Request Transf er Exit (SID 77) ....................................................................... 267 
2.2.2.13 Stop Communication Request (SID 82) ................................................................................... 267 
2.2.2.14 Positive Response Stop Communication (SID C2) ...................................................................... 267 
2.2.2.15 Ackno wledge Sub Message (SID 83) ....................................................................................... 267 
2.2.2.16 Neg ative Response (SID 7F) .................................................................................................. 268 
2.2.3 Acheminement des messages ................................................................................................ 268 
2.2.4 Sync hronisation ................................................................................................................. 269 
2.2.5 Traiteme nt des erreurs ......................................................................................................... 270 
2.2.5.1 Phase d'établissement de la communication .............................................................................. 270 
2.2.5.2 Phase de communication ..................................................................................................... 270 
2.2.6 Conte nu des messag es de réponse .......................................................................................... 272 
2.2.6.1 Positive Response Transfer Data Over view ............................................................................... 273 
2.2.6.2 Positive Response Transfer Data Activities ................................................................................ 274 
2.2.6.3 Réponse positive à une demande de transfer t de données relatives aux évènements et anomalies .......... 275 
2.2.6.4 Positive Response Transfer Data Detailed Speed ......................................................................... 276 
2.2.6.5 Positive Response Transfer Data Technical Data ......................................................................... 276 
2.3. Archivage de fichiers sur un suppor t de mémoire extern e........................................................... 277 26.5.2016 L 139/260 Jour nal officiel de l'Union européenne FR     
3. PROTOCOLE DE TÉLÉCHAR GEMENT DES CARTES TACHY GRAPHIQUES .................................................... 277 
3.1. Champ d'application ........................................................................................................... 277 
3.2. Définitions ........................................................................................................................ 277 
3.3. Téléc hargem ent d'une carte.................................................................................................. 277 
3.3.1 Séquence d'initialisation ....................................................................................................... 278 
3.3.2 Séquence de télécharg ement des fichiers de données non signés .................................................... 278 
3.3.3 Séquence de télécharg ement des fichiers de données signés .......................................................... 279 
3.3.4 Séquence de réinitialisation d'un comp teur d'étalonnage. ............................................................. 279 
3.4. Format d'archivag e des données ............................................................................................. 280 
3.4.1 Introduction ...................................................................................................................... 280 
3.4.2 Format des fichiers ............................................................................................................. 280 
4. TÉLÉCHAR GEMENT D'UNE CARTE TACHY GRAPHIQUE PAR L'INTERMÉDIAIRE D'UNE UNITÉ EMBARQUÉE SUR 
VÉHICULE. .................................................................................................................................... 281  
1.  INTR ODUCTION 
Le présent appendice traite des procédures qu'il convient d'appliquer pour exécut er les différ ents types de 
téléc hargem ent de données vers un suppor t de mémoire externe. Il traite également des protocoles qu'il y a 
lieu de mettre en œuvre pour assurer un transfer t de données correct et garantir la parfaite compati bilité des 
données télécharg ées afin de permettre à tout contrôleur d'inspect er ces données en s'assurant de leur 
authenticité et de leur intégr ité avant de procéder à leur analyse éventuelle. 
1.1.  Champ d'application 
Certaines données sont suscep tibles d'être télécharg ées vers un suppor t de mémoire externe (ESM): 
—  à partir d'une unité embarquée sur véhicule (VU) par l'inte rmédiaire d'un équipement spécialisé intelligent 
(IDE) raccordé à la VU, 
—  à partir d'une carte tach ygraphique par l'intermédiaire d'un IDE équipé d'un périphér ique de lecture de 
carte (IFD), 
—  à partir d'une carte tach ygraphique par l'inter médiaire d'une unité embarquée sur véhicule et par le biais 
d'un IDE raccordé à la VU. 
Afin de permettre la vérification de l'authenticit é et de l'intégrité des données téléc hargée s qui auraient été 
sauveg ardées sur un ESM, ces données s'accom pagnent d'une signature conf orme à l'appendice 11 
(Mécanismes de sécur ité communs). L'identif ication de l'équipement source (VU ou carte) et ses certificat s de 
sécur ité (État membre et équipement) sont également téléc hargés . Le vérificateur doit être en possession d'une 
clé publique européenne sécur isée. 
DDP_001  Les données téléc hargée s au cours d'une session de téléc hargem ent doivent être enregistrées dans 
un seul et même fichier sur l'ESM. 
1.2.  Abréviations et notations 
Les abréviations qui suivent apparaissent dans le présent appendice: 
AID  Identif iant d'application (Application Identifier) 
ATR  Réponse pour remise à zéro (Answer To Reset) 
CS  Octet de total de contrôle (Checksum byte) 
DF  Fichier spécialisé (Dedicated File) 
DS_  Session de diagnostic (Diagnostic Session) 
EF  Fichier élémentaire (Elementar y File) 
ESM  Suppor t de mémoire extern e (Exter nal Storage Medium) 
FID  Identif icateur de fichier (File Identifi er) 
FMT  Octet de structure (premier octet de l'en-tête d'un messag e) (Format Byte) 
ICC  Carte à circuit intégré (Integ rated Circuit Card) 
IDE  Équipement spécialisé intelligent: équipement servant à téléc harger des données vers l'ESM (par 
exem ple, le PC) (Intelligent Dedicated Equipment) 
IFD  Périphér ique d'interf ace (Inter face Device) 26.5.2016 L 139/261 Jour nal officiel de l'Union européenne FR     
KWP  Protocol e à mots clés (Keyword Protocol) 2000 
LEN  Octet de longueur (der nier octet de l'en-têt e d'un message ) (Length Byte) 
PPS  Sélection des paramètres de protocole (Protocol Parameter Selection) 
PSO  Exécution d'une opération de sécur ité (Perfor m Secur ity Oper ation) 
SID  Identif icateur de service (Service Identif ier) 
SRC  Octet source (Sour ce byte) 
TGT  Octet cible (Target byte) 
TLV  Longueur des balises (Tag Length Value) 
TREP  Paramètre de réponse du transfer t (Transfer Response Parameter) 
TRTP  Paramètre de demande du transfe rt (Transfer Request Parameter) 
VU  Unité embarquée sur le véhicule (Vehicle Unit) 
2.  TÉLÉCHAR GEMENT DE DONNÉES SUR LA VU 
2.1.  Procédure de téléchargement 
Pour procéder au téléc hargement de données sur la VU, l'opérate ur doit exécut er les opérations suivantes: 
—  introduire la carte de tach ygraphe qu'il détient dans la fente de l'un des lecteur s de carte de la VU (*); 
—  raccorder l'IDE au connecte ur de téléc hargem ent de la VU; 
—  établir la liaison entre l'IDE et la VU; 
—  sélectionner sur l'IDE les données à téléc harger et envoyer la requêt e à la VU; 
—  clôturer la session de télécharg ement. 
2.2.  Protoc ole de téléchargement des données 
La structure du protocole repose sur une relation maître-esclave, l'IDE jouant le rôle du maître et la VU celui 
de l'unité asser vie. 
La structure des message s, leur type et leur acheminement sont essentiellement basés sur le prot ocole à mots 
clés 2000 ( KWP) (ISO 14230-2 Véhicules routiers — Systèmes de diagnostic — Protocol e à mots clés 2000 
— Partie 2: Couche de liaison de données). 
La couc he d'application est principalement basée sur le projet actuel de norme ISO 14229-1 (Véhicules 
routiers — Systèmes de diagnostic — Partie 1: services de diagnostic, version 6 du 22 février 2001). 
2.2.1  Structure des messag es 
DDP_002  Tous les messages échang és entre l'IDE et la VU se caract érisent par une structure à trois éléments. 
—  En-tête compo sé d'un octet de structure (FMT), d'un octet cible (TGT), d'un octet source (SRC) 
et, le cas éché ant, d'un octet de longueur (LEN). 
—  Champ de données composé d'un octet d'identif ication de service (SID) et d'un nombre 
variable d'oct ets d'inf ormation qui peuvent compre ndre un octet optionnel de session de 
diagnostic (DS_) ou un octet optionnel de paramètre de transfer t (TRTP ou TREP). 
—  Total de contrôle composé d'un octet total de contrôle (CS). 
En-tête Champ de données Total de contrôle 
FMT TGT SRC LEN SID DON ­
NÉES … … … CS 
4 octets 255 octets max. 1 octet  26.5.2016 L 139/262 Jour nal officiel de l'Union européenne FR     
(*)L'inser tion de la carte déclenche l'activation des droits d'accès appropr iés tant aux données qu'à la fonction de télécharg ement. Il est 
toutef ois possible de téléc harger des données à partir d'une carte de conducteur insérée dans l'un des lecteurs de la VU lorsqu'aucun autre 
type de carte n'est inséré dans l'autre lecteur . 
Les octets TGT et SRC représente nt les adresses physiques du destinataire et de l'expédit eur du 
message . Ils prennent les valeurs F0 Hex pour l'IDE et EE Hex pour la VU. 
L'octet LEN indique la longueur du cham p de données. 
L'octet total de contrôle correspond à une série de sommes de 8 bits modulo 256 représentant 
tous les octets du message à l'exclusi on du CS lui-même. 
Les octets FMT , SID, DS_, TRTP et TREP font également l'objet d'une définition présent ée plus loin 
dans ce document. 
DDP_003  Si la longueur des données que le message est censé véhiculer est supér ieure à l'espace disponible 
dans la partie champ de données, l'env oi de ce message prend la forme de plusieurs sous- 
message s. Chacun de ces sous-message s compor te un en-tête, les mêmes SID et TREP ainsi qu'un 
comp teur de sous-message s de 2 octets indiquant le numéro d'ordre de chaque sous-message au 
sein du message global. Afin de permettre le contrôle d'erreur et l'abandon éventuel d'un échang e 
de données, l'IDE accuse récep tion de chaque sous-message . L'IDE est à même d'accept er le sous- 
message , d'en demander la réémission et de demander à la VU d'en reprendre ou d'en abandonner 
la transmission. 
DDP_004  Si le champ de données du dernier sous-message contient exacte ment 255 octets, il est 
indispensable d'adjoindre à l'ensemble un sous-messag e final compo rtant un champ de données 
vide (à l'exception des SID, TREP et comp teur de sous-messag es) pour indiquer la fin du messag e. 
Exemple: 
En-tête SID TREP Message CS 
4 octets Longueur supér ieure à 255 octets   
Transmis sous la forme suivante: 
En-tête SID TREP 00 01 Sous- 
message 1 CS 
4 octets 255 octets   
En-tête SID TREP 00 02 Sous- 
message 2 CS 
4 octets 255 octets   
… 
En-tête SID TREP xx yy Sous- 
message n CS 
4 octets Longueur inférieure à 255 octets   
ou comme: 
En-tête SID TREP 00 01 Sous- 
message 1 CS 
4 octets 255 octets   
En-tête SID TREP 00 02 Sous- 
message 2 CS 
4 octets 255 octets   26.5.2016 L 139/263 Jour nal officiel de l'Union européenne FR     
… 
En-tête SID TREP xx yy Sous- 
message n CS 
4 octets 255 octets   
En-tête SID TREP xx yy + 1 CS 
4 octets 4 octets   
2.2.2  Types de message s 
Le prot ocole de communication qui s'applique au télécharg ement de données entre la VU et l'IDE réclame 
l'éch ange de 8 types de messag es distincts. 
La table qui suit en présente une synthèse. 
Structure du message En-tête 
4 octets max. Données 
255 octets max. Total de 
contrôle 
1 octet 
IDE -> <- VU FMT TGT SRC LEN SID DS_/TRTP DONNÉE ­
S CS 
Demande d'établissement de la 
communication 81 EE F0  81   E0 
Réponse positive à une demande 
d'établissement de la communica ­
tion 80 F0 EE 03 C1  EA, 8F 9B 
Demande d'ouver ture d'une ses­
sion de diagnostic 80 EE F0 02 10 81  F1 
Réponse positive à une demande 
d'ouver ture de session de diag ­
nostic 80 F0 EE 02 50 81  31 
Service de contrôle de liaison  
Vérification du débit en bauds 
(étape 1) 
9 600 Bd 80 EE F0 04 87  01,01, 
01 EC 
19 200 Bd 80 EE F0 04 87  01,01, 
02 ED 
38 400 Bd 80 EE F0 04 87  01,01, 
03 EE 
57 600 Bd 80 EE F0 04 87  01,01, 
04 EF 
115 200 Bd 80 EE F0 04 87  01,01, 
05 F0 
Réponse positive à une demande 
de vérification du débit en bauds 80 F0 EE 02 C7  01 28 
Débit de transition en bauds 
(étape 2) 80 EE F0 03 87  02,03 ED 
Demande de télécharg ement 
(upload) 80 EE F0 0A 35  00,00, 
00,00, 
00,FF ,FF, 
FF,FF 99 
Réponse positive à une demande 
de téléc harg ement 80 F0 EE 03 75  00,FF D5 26.5.2016 L 139/264 Jour nal officiel de l'Union européenne FR     
Structure du message En-tête 
4 octets max. Données 
255 octets max. Total de 
contrôle 
1 octet 
IDE -> <- VU FMT TGT SRC LEN SID DS_/TRTP DONNÉE ­
S CS 
Demande de transfer t de données  
Récapitulatif 80 EE F0 02 36 01  97 
Activités 80 EE F0 06 36 02 Date CS 
Événements et anomalies 80 EE F0 02 36 03  99 
Vites se instantanée 80 EE F0 02 36 04  9A 
Données techniques 80 EE F0 02 36 05  9B 
Téléc hargement (download) 
d'une carte 80 EE F0 02 36 06 Lecteur CS 
Réponse positive à une demande 
de transfer t de données 80 F0 EE Len 76 TREP Données CS 
Demande de fin de transfer t 80 EE F0 01 37   96 
Réponse positive à une demande 
de fin de transfer t 80 F0 EE 01 77   D6 
Demande d'arrêt de la communi ­
cation 80 EE F0 01 82   E1 
Réponse positive à une demande 
d'arrêt de la communication 80 F0 EE 01 C2   21 
Accusé de réception d'un sous- 
messag e 80 EE F0 Len 83  Données CS 
Réponses néga tives  
Téléc hargement (général) refusé 80 F0 EE 03 7F Sid Req 10 CS 
Service incompatible 80 F0 EE 03 7F Sid Req 11 CS 
Sous-f onction incompatible 80 F0 EE 03 7F Sid Req 12 CS 
Longueur du messag e incor ­
recte 80 F0 EE 03 7F Sid Req 13 CS 
Conditions non correcte s ou er­
reur affectant la séquence d'in­
terrogation 80 F0 EE 03 7F Sid Req 22 CS 
Demande excessive 80 F0 EE 03 7F Sid Req 31 CS 
Télécharg ement (upload) refusé 80 F0 EE 03 7F Sid Req 50 CS 
Réponse en suspens 80 F0 EE 03 7F Sid Req 78 CS 
Données indisponibles 80 F0 EE 03 7F Sid Req FA CS  
Remarques: 
—  SID Req = SID de la demande correspondante 
—  TREP = le TRTP de la demande correspondante. 
—  La présence de cellules noires indique une absence de transmission. 
—  L'utilisation du term e «upload» (considéré à partir de l'IDE) s'impose pour garantir la compatibilit é du 
système avec la norme ISO 14229. Ce terme possède la même signification que «download» (considéré à 
partir de la VU). 
—  Cette table ne présente pas de comp teur poten tiel de sous-messages de 2 octets. 
—  Le lecteur désigne le numéro de lecteur , soit «1» (carte sur le lecteur du conducteur) soit «2» (carte sur le 
lecte ur du conv oyeur). 
—  Si le lecteur n'est pas précisé, la VU sélectionne le lecteur 1 s'il contient une carte et le lecteur 2 
uniquement si l'utilisateur le sélectionne. 26.5.2016 L 139/265 Jour nal officiel de l'Union européenne FR     
2.2.2.1  Demande d'établissement de la communication (SID 81) 
DDP_005  Ce message est émis par l'IDE pour établir la liaison d'intercommunication avec la VU. Les 
communications initiales sont toujours effectuées à 9 600 bauds (jusqu'à ce que ce débit soit 
modifié à l'aide des services appropr iés de contrôle des liaisons). 
2.2.2.2  Réponse positive à une demande d'établissement de la communication (SID C1) 
DDP_006  La VU émet ce message pour répondre positivement à une demande d'établissement de la 
communication. Il compo rte les deux octets clés «EA» ‘8F’ indiquant que l'unité correspondante 
prend en charge le protocole concer né, l'en-tête de chaque message incluant les octets cible, 
source et longueur . 
2.2.2.3  Demande d'ouver ture d'une session de diagnostic (SID 10) 
DDP_007  L'IDE émet un message de demande d'ouver ture d'une session de diagnostic dans le but de 
sollicit er une nouvelle session de diagnostic avec la VU. La sous-f onction «session par défaut» (81 
Hex) indique qu'une session de diagnostic standard va être ouver te. 
2.2.2.4  Réponse positive à une demande d'ouver ture de session de diagnostic (SID 50) 
DDP_008  La VU émet un message de réponse positive à une demande de diagnostic pour répondre 
positivement à une demande d'ouver ture d'une session de diagnostic. 
2.2.2.5  Ser vice de contrôle de liaison (SID 87) 
DDP_052  Le service de contrôle de liaison est utilisé par l'IDE pour initier une modification du débit en 
bauds. Cette opération compor te deux étapes. Dans la première étape, l'IDE propose une 
modific ation du débit en bauds, en indiquant le nouveau débit. À la récep tion d'un message positif 
de la VU, l'IDE envoie la confir mation du changem ent du débit en bauds à la VU (deuxième 
étape). L'IDE passe alors au nouveau débit en bauds. Après réception de la confir mation, la VU 
passe au nouveau débit en bauds. 
2.2.2.6  Réponse positive au contrôle de liaison (SID C7) 
DDP_053  La réponse positive au contrôle de liaison est délivrée par la VU sur demande du service de 
contrôle de liaison (première étape). À note r qu'aucune réponse n'est donnée à la demande de 
conf irmation (deuxième étape). 
2.2.2.7  Demande de télé charg ement (upload) (SID 35) 
DDP_009  L'IDE émet un message de demande de télécharg ement afin de préciser à la VU qu'il réclame 
l'exé cution d'une opération de télécharg ement. Afin de satisfaire aux exige nces de la norme 
ISO 14229, des données sont incluses concer nant l'adresse, la taille et les caract éristiques de 
format des données demandées. Ces informations n'étant pas connues de l'IDE avant le téléc har­
gement, l'adresse de mémoire est mise à 0, la structure est non cryptée et non compres sée et la 
taille de la mémoire est mise au maximum. 
2.2.2.8  Réponse positive à une demande de téléc harge ment (SID 75) 
DDP_010  La VU émet un message de réponse positive à une demande de téléc hargement pour signif ier à 
l'IDE que la VU est prêt e à téléc harger des données. Afin de satisf aire aux exige nces de la norme 
ISO 14229, le message de réponse positive comprend des données indiquant à l'IDE que les 
message s ultérieurs de réponse positive à une demande de transfer t de données compo rteront au 
maximum 00FF hex octets. 
2.2.2.9  Demande de transf ert de données (SID 36) 
DDP_011  L'IDE émet une demande de transfer t de données afin de préciser à la VU la nature des données à 
téléc harger . Un paramètre de demande de transfer t (TRTP) d'un octet indique de quel type de 
transfer t il s'agit. 
Il existe six types de transfer t de données: 
—  Récapitulatif (TRTP 01), 
—  Activités associées à une date précise (TRTP 02), 
—  Évènements et anomalies (TRTP 03), 26.5.2016 L 139/266 Jour nal officiel de l'Union européenne FR     
—  Vitesse instantanée (TRTP 04), 
—  Données techniques (TRTP 05), 
—  Téléc hargem ent de carte (TRTP 06). 
DDP_054  Il est oblig atoire pour l'IDE de demander un transfer t de données du type «récapitulatif» (TRTP 01) 
au cours d'une session de téléc hargement, car cela seul garantit que les certificats de la VU sont 
enregistrés sur le fichier téléc hargé (et permet ainsi la vérification de la signature numér ique). 
Dans le deuxième cas de figure (TRTP 02), le messag e de demande de transfer t de données 
compo rte l'indication du jour civil (
 format) auquel le téléc hargement est associé. 
2.2.2.10  Réponse positive à une demande de transfer t de données (SID 76) 
DDP_012  La VU émet un messag e de réponse positive à une demande de transfer t de données en réponse à 
une demande de cette nature. Ce message contient les données réclamées ainsi qu'un paramètre de 
réponse à une demande de transfe rt (TREP) correspondant à celui de la demande. 
DDP_055  Dans le premier cas (TREP 01), la VU enverra des données destinées à aider l'opérateur de l'IDE 
dans le choix des données qu'ils souhaiten t téléc harg er. Les informations conte nues dans ce 
message sont les suivante s: 
—  Certificats de sécur ité, 
—  Identification du véhicule, 
—  Date et heure actuelles sur la VU, 
—  Date la plus précoce et la plus tardive pour le télécharg ement (données de la VU), 
—  Indications concer nant la présence de cartes dans la VU. 
—  Téléc hargem ents antérieurs vers une entrepr ise, 
—  Verrouillages d'entrepr ise, 
—  Contrôles précédents. 
2.2.2.11  Demande de fin de transfer t (SID 37) 
DDP_013  L'IDE émet un message de demande de fin de transfer t pour informer la VU que la session de 
téléc hargem ent est terminée. 
2.2.2.12  Réponse positive à une demande de fin de transfe rt (SID 77) 
DDP_014  La VU émet un message de réponse positive à une demande de fin de transfer t pour accuser 
récep tion de la demande de fin de transfe rt. 
2.2.2.13  Demande d'ar rêt de la communication (SID 82) 
DDP_015  L'IDE émet un message de demande d'arrêt de la communication dans le but de rompr e la liaison 
d'inter communication avec la VU. 
2.2.2.14  Réponse positive à une demande d'ar rêt de la communication (SID C2) 
DDP_016  La VU émet un messag e de réponse positive à une demande d'arrêt de la communication pour 
accuser réception de la demande d'arrêt de la communication. 
2.2.2.15  Accusé de réception d'un sous-message (SID 83) 
DDP_017  L'IDE émet un accusé de réception de sous-message pour confir mer la réception des différ entes 
parties d'un messag e transmis sous forme de sous-messages. Le cham p de données contient le SID 
transmis par la VU ainsi qu'un code de 2 octets qui s'énonce comme suit: 
—  MsgC + 1 accuse la réception correcte du sous-message numéro MsgC. 
Demande d'env oi du sous-message suivant adressée à la VU par l'IDE 
—  MsgC indique la manifest ation d'un problème affectant la récep tion du sous-message numéro 
MsgC. 
Demande de renv oi du sous-messag e concer né adressée à la VU par l'IDE. 26.5.2016 L 139/267 Jour nal officiel de l'Union européenne FR     
—  FFFF réclame l'inte rrupti on du message en cours de transmission. 
L'IDE peut recour ir à ce code pour mettre un term e à la transmission du message envoyé par 
la VU et ce, quelle qu'en soit la raison. 
Le système permet d'accuser (ou non) récep tion du dernier sous-message d'un message quelconque 
(octet LEN < 255) en recourant ou non à l'un quelconque de ces codes. 
Com posée de plusieurs sous-messages , la réponse de la VU s'énonce comme suit: 
—  Réponse positive à une demande de transfer t de données (SID 76) 
2.2.2.16  Réponses nég atives (SID 7F) 
DDP_018  La VU émet le messag e de réponse négat ive en réponse aux messages ci-dessus si elle s'avère dans 
l'impossi bilité de satisf aire à la demande transmise. Les cham ps de données du messag e 
contiennent le SID de la réponse (7F), le SID de la demande, et un code précisant le motif de la 
réponse négativ e. Les codes suivants sont d'application: 
—  10 téléc hargem ent (généra l) refusé 
L'opération ne peut être exécut ée pour une raison qui n'est pas abordée ci-après. 
—  11 service incompati ble 
Le SID de la demande n'est pas intelligib le à la VU. 
—  12 sous-f onction incompati ble 
Le DS_ ou le TRTP de la demande ne sont pas intelligible s à la VU ou la transmission des 
sous-messag es est arrivée à son term e. 
—  13 longueur du messag e incor recte 
La longueur du message reçu est incor recte. 
—  22 conditions non correcte s ou erreur affectant la séquence d'interr ogation 
Le service demandé n'est pas disponible ou la séquence des message s de demande est 
incor recte. 
—  31 demande exce ssive 
Le relevé (champ de données) du paramètre de la demande n'est pas valable. 
—  50 téléc hargem ent (upload) refusé 
La demande ne peut être exécut ée (la VU est exploit ée dans un mode inappropr ié ou elle 
présent e une anomalie interne). 
—  78 réponse en suspens 
L'action réclamée ne peut être ache vée dans le temps impar ti et la VU n'est pas prêt e à 
accept er une autre demande. 
—  FA données indisponibles 
L'objet d'une demande de transfer t de données n'est pas accessible au sein de la VU (p. ex. 
absence d'inser tion de carte…). 
2.2.3  Achem inement des messages 
Pendant une procédure de télécharg ement normale, l'ach eminement des messages s'effect ue habituellement 
comme suit: 
IDE  VU 
Demande d'établissement de la communica ­
tion 
Réponse positive 
Demande d'ouver ture d'une session de diag ­
nostict 
Réponse positive 
Demande de télécharg ement (upload) 
Réponse positive 26.5.2016 L 139/268 Jour nal officiel de l'Union européenne FR     
IDE  VU 
Demande de transfer t de données — Réca ­
pitulatif 
Réponse positive 
Demande de transfer t de données #2 
Réponse positive #1 
Accusé de récep tion d'un sous-message #1 
Réponse positive #2 
Accusé de récep tion d'un sous-message #2 
Réponse positive #m 
Accusé de réception d'un sous-messag e #m 
Réponse positive (champ de données < 255 
octets) 
Accusé de réception d'un sous-messag e (fa­
cultatif) 
… 
Demande de transfer t de données #n 
Réponse positive 
Demande de fin de transfe rt 
Réponse positive 
Demande d'arrêt de la communication 
Réponse positive  
2.2.4  Synchr onisation 
DDP_019  Dans des conditions d'exploitation normales, les paramètres de synch ronisation dont la figure ci- 
après fournit l'illustration sont d'application: 
Figure 1 
Acheminement des messages, synchronisation 
26.5.2016 L 139/269 Jour nal officiel de l'Union européenne FR     
Où: 
P1  =Temps interoct et caractér isant une réponse de la VU. 
P2  =Temps ménagé entre la fin d'une demande de l'IDE et le début de la réponse de la VU ou 
entre la fin d'un accusé de récep tion de l'IDE et le début de la prochaine réponse de la VU. 
P3  =Temps ménag é entre la fin d'une réponse de la VU et le début d'une nouvelle demande de 
l'IDE, entre la fin d'une réponse de la VU et le début d'un accusé de réception de l'IDE ou 
entre la fin d'une demande de l'IDE et le début d'une nouvelle demande de l'IDE dans 
l'éventualité où la VU manquerait à répondre. 
P4  =Temps interoct et caractér isant une demande de l'IDE. 
P5  =Valeur étendue de P3 pour le télécharg ement de cartes. 
Le tableau ci-après présente les valeurs que les paramètres de synch ronisation sont suscep tibles de 
prendre (jeu étendu de paramètres de sync hronisation KWP , utilisés en cas d'adressage physique 
visant à accroître la vitesse des communications). 
Paramètre de synchronisation Limite inférieure 
(en ms) Limite supér ieure 
(en ms) 
P1 0 20 
P2 20 1 000 (*) 
P3 10 5 000 
P4 5 20 
P5 10 20 minute s 
(*)  Si la VU réagit en émettant une réponse négative contenant un code qui possède la signification suivante: 
«réception correcte de la demande, réponse en suspens», cette valeur est portée à la même limite supér ieure 
que celle de P3.  
2.2.5  Traitement des erreurs 
Si une erreur se manifest e pendant l'écha nge de messages, le plan d'acheminement des messages est modif ié 
en fonction de l'équipement qui a décelé l'erreur et du message à l'origine de celle-ci. 
Les figures 2 et 3 illustrent les procédures de traite ment d'erreur appliquées respectivement à la VU et à l'IDE. 
2.2.5.1  Phase d'établissement de la communication 
DDP_020  Si l'IDE détec te une erreur au cours de la phase d'établissement de la communication, tant au 
niveau de la synchronisation qu'au niveau du train de bits, celui-ci temporise alors pendant une 
période P3min avant d'émettre à nouveau la même demande. 
DDP_021  Si la VU détec te une erreur dans la séquence provenant de l'IDE, celle-ci n'en voie aucune réponse; 
elle attend un autre message de demande d'établissement de la communication dans un délai 
P3max. 
2.2.5.2  Phase de communication 
Deux procédures de traitement d'erreur distinctes peuvent être définie s:  
1. La VU détecte une erreur de transmission de l'IDE 
DDP_022  La VU procède à l'analyse de chaque message reçu afin de déceler tout e erreur éventuelle de 
synch ronisation, de structure des octets (p. ex. violations affectant les bits de dépar t et d'arrêt) 
ou de perte de verrouillage de trame (récept ion d'un nombre erroné d'octets, octet total de 
contrôle erroné). 
DDP_023  Si la VU détect e l'une des erreurs susmentionnées, elle n'en voie aucune réponse et ne tient 
aucun comp te du message reçu. 26.5.2016 L 139/270 Jour nal officiel de l'Union européenne FR     
DDP_024  La VU peut détecter d'autres erreurs dans le format ou le cont enu du message reçu (p. ex. un 
messag e incompat ible), même si le message satisf ait aux exige nces de longueur et de contrôle 
du total; dans ce cas, la VU répond à l'IDE par un message de réponse néga tif précisant la 
nature de l'erreur . 
Figure 2 
Traitement d'er reur au niveau de la VU 
26.5.2016 L 139/271 Jour nal officiel de l'Union européenne FR     
2. L'IDE détecte une erreur de transmission de la VU 
DDP_025  L'IDE procède à l'analyse de chaque message reçu afin de déceler tout e erreur éventuelle de 
synch ronisation, de structure des octets (p. ex. violations affectant les bits de dépar t et d'arrêt) 
ou de perte de verrouillage de trame (récept ion d'un nombre erroné d'octets, octet total de 
contrôle erroné). 
DDP_026  L'IDE détec te les erreurs de séquence telles que l'incrémentation incor recte du comp teur de 
sous-messag es que compo rtent les messages successifs reçus. 
DDP_027  Si l'IDE détecte une erreur ou si la VU ne lui envoie aucune réponse dans un délai P2max, le 
messag e de demande concer né sera renv oyé à trois repr ises au maximum à l'unit é destinataire. 
Aux fins de cette détection d'erreurs, tout accusé de récep tion d'un sous-message quelconque 
sera considéré comme une demande adressée à la VU. 
DDP_028  L'IDE attend au moins une période de P3min avant d'entamer chaque transmission; la période 
d'atte nte se mesure depuis la dernière occur rence calculée d'un bit d'arrêt suivant la détection 
d'erreur . 
Figure 3 
Traitement d'er reur au niveau de l'IDE 
2.2.6  Contenu des message s de réponse 
Ce paragraphe traite du contenu des champs de données que compor tent les différents messag es de réponse 
positive. 
Les éléments d'inf ormation sont définis dans l'appendice 1 (Dictionnaire de données). 
Remarque: concer nant les téléc hargements de génération 2, tout es les données de niveau supér ieur sont 
représenté es dans un tableau des relevés, même s'il ne contient qu'un relevé. Un tableau de relevés début e 
avec un en-tête; cet en-tête contient le type de relevés, sa taille et le nombre total de relevés. Les tableaux de 
relevés sont intitulés «…RecordAr ray» (avec en-tête) dans les tableaux suivants. 26.5.2016 L 139/272 Jour nal officiel de l'Union européenne FR     
2.2.6.1  Réponse positive à un récapitulatif de transf ert de données 
DDP_029  Le champ de données du messag e «Réponse positive à un récapitulatif de transfe rt de données» 
doit fournir les données ci-après dans l'ordre qui suit en vertu des SID 76 Hex, TREP 01 Hex et 
critères appropr iés de séparation et de comp tage des sous-message s: 
Structure de données de génération 1 
Élément de donnée  Commentaire 
Certificat s de sécur ité de la VU 
Identif ication du véhicule 
Date et heure actuelles sur la VU 
Période téléc hargea ble 
Catégor ie de cartes insérées dans la VU 
Téléc hargement précédent de la VU 
Tous les verrouillage s d'entrepr ise mémor isés. Si cette 
section est vide, seule l'expression noOfLocks = 0 est 
envoyée. 
Tous les relevés de contrôle mémor isés dans la VU. Si 
cette section est vide, seule l'expression noOfControls 
= 0 est envoyée. 
Signature RSA de tout es les données (hor mis les certi­
ficats) à partir de VehicleIdentificationNumber jusqu'au 
dernier octet du dernier VuControlA ctivityData.  
Structure de données de génération 2 
Élément de donnée  Commentaire 
Certificat de l'État membre 
Certificate de la VU 
Identif ication du véhicule 
Plaque minéralogique du véhicule 
Date et heure actuelles sur la VU 
Période téléc hargea ble 
Catégor ie de cartes insérées dans la VU 
Téléc hargement précédent de la VU 
Tous les verrouillage s d'entrepr ise mémor isés. Si cette 
section est vide, un en-tête de tableau avec l'expression 
noOfRecords = 0 est envoyé . 
Tous les relevés de contrôle mémor isés dans la VU. Si 
cette section est vide, un en-tête de tableau avec l'ex­
pression noOfRecords = 0 est envoyé . 
Signature ECC de tout es les données antérieures hor­
mis les certificat s.  26.5.2016 L 139/273 Jour nal officiel de l'Union européenne FR     
2.2.6.2  Réponse positive à une demande de transfer t de données relatives aux activit és 
DDP_030  Le champ de données du message «Réponse positive à une demande de transfer t de données 
relatives aux activités» doit fournir les données ci-après dans l'ordre qui suit en vertu des SID 76 
Hex, TREP 02 Hex et critères appropr iés de séparation et de comp tage des sous-message s: 
Structure de données de génération 1 
Élément de donnée  Commentaire 
Date du jour de télécharg ement 
Kilométrage à la fin de la jour née téléc hargée 
Données relatives aux cycles d'inser tion et de retrait des cartes. 
—  Si cette section ne contient aucune donnée disponible, 
seule l'expression noOfV uCardIWRecords = 0 est envoyée. 
—  Lorsque VuCardIWRecord figure à 00h00 (inser tion de 
carte de la veille) ou à 24h00 (retrait de carte du lende ­
main), elle apparaît entièrement sur les deux jours concer ­
nés. 
État des lecteurs à 00h00 et modifi cations d'activit é mémor isés 
pour la jour née téléc hargée . 
Données relatives aux emplacements mémor isés pour la jour ­
née téléc hargée . Si cette section est vide, seule l'expression 
noOfPlaceRecords = 0 est envoyée. 
Données relatives aux conditions particulières mémor isées 
pour la jour née téléc hargée. Si cette section est vide, seule l'ex­
pression noOfSpecificC onditionRecords = 0 est envoyée. 
Signature RSA de tout es les données à partir de TimeReal jus­
qu'au dernier octet du dernier relevé de conditions particuliè ­
res.  
Structure de données de génération 2: 
Élément de donnée  Commentaire 
Date du jour de télécharg ement 
Kilométrage à la fin de la jour née téléc hargée 
Données relatives aux cycles d'inser tion et de retrait des cartes. 
—  Si cette section ne contient aucune donnée disponible, un 
en-tête de tableau avec l'expression noOfRecords = 0 est 
envoyé. 
—  Lorsque VuCardIWRecord figure à 00h00 (inser tion de 
carte de la veille) ou à 24h00 (retrait de carte du lende ­
main), elle apparaît entièrement sur les deux jours concer ­
nés. 
État des lecteurs à 00h00 et modifi cations d'activit é mémor isés 
pour la jour née téléc hargée . 
Données relatives aux emplacements mémor isés pour la jour ­
née téléc hargée. Si cette section est vide, un en-tête de tableau 
avec l'expression noOfRecords = 0 est envoyé. 
Positions GNSS du véhicule si le temps de conduite continue 
du conduct eur atteint un multiple de trois heures. Si cette sec­
tion est vide, un en-tête de tableau avec l'expression noOfRe ­
cords = 0 est envoyé. 
Données relatives aux conditions particulières mémor isées 
pour la jour née téléc hargée . Si cette section est vide, un en-tête 
de tableau avec l'expression noOfRecords = 0 est envoyé. 
Signature ECC de tout es les données antérieures.  26.5.2016 L 139/274 Jour nal officiel de l'Union européenne FR     
2.2.6.3  Réponse positive à une demande de transf ert de données relatives aux événements et 
anomalies 
DDP_031  Le champ de données du message «Réponse positive à une demande de transfer t de données 
relatives aux événements et anomalies» doit fournir les données ci-après dans l'ordre qui suit en 
vertu des SID 76 Hex, TREP 03 Hex et critères appropr iés de séparation et de comp tage des sous- 
message s: 
Structure de données de génération 1 
Élément de donnée  Commentaire 
Toutes les anomalies enregistrées ou en cours au sein 
de la VU. 
Si cette section est vide, seule l'expression noOfV u­
Faul ts = 0 est envoyée. 
Tous les évènements enregistrés ou en cours au sein 
de la VU (hor mis les dépassements de vites se). 
Si cette section est vide, seule l'expression noOfV uE­
vents = 0 est envoyée. 
Données relatives au dernier contrôle de dépassement 
de vitess e (valeur par défaut en l'absence de données). 
Tous les évènements en matière de dépassements de 
vites se enregistrés dans la VU. 
Si cette section est vide, seule l'expression noOfV uO­
verSpeedingEvents = 0 est envoyée. 
Tous les évènements de réglage horaire mémor isés 
dans la VU (hor mis le cadre d'étalonnag e compl et). 
Si cette section est vide, seule l'expression noOfV uTi­
meAdjRecord s = 0 est envoyée. 
Signature RSA de tout es les données à partir de noOf ­
VuFaul ts jusqu'au dernier octet du dernier relevé de ré­
glage horaire.  
Structure de données de génération 2: 
Élément de donnée  Commentaire 
Toutes les anomalies enregistrées ou en cours au sein 
de la VU. 
Si cette section est vide, un en-tête de tableau avec 
l'expression noOfRecords = 0 est envoyé. 
Tous les évènements enregistrés ou en cours au sein 
de la VU (hor mis les dépassements de vites se). 
Si cette section est vide, un en-tête de tableau avec 
l'expression noOfRecords = 0 est envoyé. 
Données relatives au dernier contrôle de dépassement 
de vitess e (valeur par défaut en l'absence de données). 
Tous les évènements en matière de dépassements de 
vites se enregistrés dans la VU. 
Si cette section est vide, un en-tête de tableau avec 
l'expression noOfRecords = 0 est envoyé. 
Tous les évènements de réglage horaire mémor isés 
dans la VU (hor mis le cadre d'étalonnag e compl et). 
Si cette section est vide, un en-tête de tableau avec 
l'expression noOfRecords = 0 est envoyé. 
Signature ECC de tout es les données antér ieures.  26.5.2016 L 139/275 Jour nal officiel de l'Union européenne FR     
2.2.6.4  Réponse positive à une demande de transfer t de données relatives à la vitesse du véhicule 
DDP_032  Le champ de données du message «Réponse positive à une demande de transfer t de données 
relatives à la vitesse du véhicule» doit fournir les données ci-après dans l'ordre qui suit en vertu 
des SID 76 Hex, TREP 04 Hex et critères appropr iés de séparation et de comp tage des sous- 
message s: 
Structure de données de génération 1 
Élément de donnée  Commentaire 
Toutes les données se rappor tant à l'évolution de la vi­
tesse du véhicule pendant une minute au cours de la­
quelle le véhicule était en mouvement 
60 valeurs de vitesse par minute (une par seconde). 
Signature RSA de tout es les données à partir de 
noOfSpeedBlocks jusqu'au dernier octet du dernier 
bloc de vitess e.  
Structure de données de génération 2: 
Élément de donnée  Commentaire 
Toutes les données se rappor tant à l'évolution de la vi­
tesse du véhicule pendant une minute au cours de la­
quelle le véhicule était en mouvement 
60 valeurs de vitesse par minute (une par seconde). 
Signature ECC de tout es les données antér ieures.  
2.2.6.5  Réponse positive à une demande de transfer t de données techniques 
DDP_033  Le champ de données du message «Réponse positive à une demande de transfer t de données 
techniques» doit fournir les données ci-après dans l'ordre qui suit en vertu des SID 76 Hex, TREP 
05 Hex et critères appropr iés de séparation et de comp tage des sous-message s: 
Structure de données de génération 1 
Élément de donnée  Commentaire 
Tous les relevés d'étalonnag e mémor isés dans la VU. 
Signature RSA de tout es les données à partir de vuMa ­
nufactur erName jusqu'au dernier octet du dernier Vu­
CalibrationRecord.  26.5.2016 L 139/276 Jour nal officiel de l'Union européenne FR     
Structure de données de génération 2: 
Élément de donnée  Commentaire 
Tous les couplages MS mémor isés dans la VU. 
Tous les couplages du dispositif GNSS externe mémo ­
risés dans la VU 
Tous les relevés d'étalonnag e mémor isés dans la VU. 
Toutes les données relatives à l'inser tion de carte mé­
mor isées dans la VU. 
Signature ECC de tout es les données antér ieures.  
2.3.  Archivage de fichiers sur un suppor t de mémoire exter ne 
DDP_034  Si une session de téléc hargement a compo rté une opération de transfer t de données à partir de la 
VU, l'IDE doit enregistrer au sein d'un seul et même fichier physique tout es les données transmises 
par la VU pendant cette session de téléc hargement dans des messages de réponse positive 
concer nant le transfer t de données. La sauvegarde de ces données en excl ut les en-tête s de 
message , comp teurs de sous-messag es, sous-messages vides et totaux de contrôle; mais elle inclut 
les SID et TREP (du premier sous-message dans l'éventualité où leur nombre serait supér ieur à 
l'unit é). 
3.  PROTOCOLE DE TÉLÉCHAR GEMENT DES CARTES TACHY GRAPHIQUES 
3.1.  Champ d'application 
Ce paragraphe compo rte une descr iption du télécharg ement direct vers un IDE des données de carte 
mémor isées sur une carte tach ygraphique. L'IDE n'appar tient pas à l'env ironnement sécur isé; aucune authenti ­
fication n'a donc lieu entre la carte et l'IDE. 
3.2.  Déf initions 
Session de téléchargement :  chaque fois que le système procède à une opération de téléc hargem ent des 
données enregistrées sur une carte à circuit(s) intégré (s). Cette session couvre 
l'ensemble de la procédure, de la réinitialisation de l'ICC par un IFD à la 
désactivation de l'ICC (retrait de la carte ou réinitialisation suivante). 
Fichier de données signé:  fichier enregistré sur l'ICC. Ce fichier est transfér é en clair vers l'IFD. Sur l'ICC, 
le fichier est haché et signé; la signature est transfé rée vers l'IFD. 
3.3.  Téléchargement d'une carte 
DDP_035  Le téléc hargem ent d'une carte tach ygraphique compo rte les opérations suivantes: 
—  Téléc hargem ent des informations communes que contient la carte dans les EF (fichiers 
élémentaires) 
 et 
 . Ces informations à caractère facultatif ne sont protég ées par aucune 
signature numér ique. 
—  Téléc hargem ent des EF 
 (ou 
 ) et 
. Ces informations ne sont protég ées par aucune signature numér ique. 
Il faut imp érativement télécharg er ces fichiers lors de tout e session de téléc hargem ent. 
—  Téléc hargem ent des autres EF de données d'application (dans le 
 et 
le cas échéa nt) sauf l'EF 
 . Ces informations sont 
prot égées par une signature numér ique. 
—  Il y a lieu de téléc harger au moins les EF 
 et 
 lors de 
tout e session de télécharg ement. 26.5.2016 L 139/277 Jour nal officiel de l'Union européenne FR     
—  Lors du téléc hargem ent d'une carte de conducteur , il faut également procéder oblig atoireme nt 
au téléc hargement des EF suivants: 
—  Lors du télécharg ement d'une carte de conducteur , il convi ent de mettre à jour la date du 
dernier téléc hargement (
 dans l'
 . 
—  Lors du télécharg ement d'une carte d'ateli er, il convient de réinitialiser le comp teur 
d'étalonnag e enregistré dans l'EF 
 . 
—  Lors du téléc hargement d'une carte d'ate lier, l'
 n'est pas 
télécharg é. 
3.3.1  Séquence d'initialisation 
DDP_036  L'IDE doit lancer la séquence en procédant comme suit: 
Carte Sens IDE/IFD Signification/Remarques  
Réinitialisation maté rielle  
ATR 
L'utilisate ur a l'option de recour ir à la PPS pour passer à un débit supér ieur à condition que l'ICC 
en assure la prise en charg e. 
3.3.2  Séquence de téléchargement des fichiers de données non signés 
DDP_037  La séquence de téléc harg ement des EF ICC, IC, Card_Cer tificate (ou CardSignCer tificate) et 
CA_Cer tificate se présent e comme suit: 
Carte Sens IDE/IFD Signification/Remarques  
Select File Sélection par le biais d'identi ­
ficateur s de fichier 
OK 
Read Binar y Si le volume des données que 
contient le fichier est supér i­
eur à la capacité de la mé­
moire tamp on du lecteur ou 
de la carte, la commande doit 
être réitérée jusqu'à ce que les 
données que contient ce fi­
chier aient été extraites dans 
leur intégralit é. 
Données 
OK 
Sauvegarder les données sur 
l'ESM selon 3.4 Data storage for­
mat  
Note 1: avant de sélectionner l'EF Card_Cer tificate (ou CardSignCer tificate), il convient de 
sélectionner préalablement l'application tach ygraphique (sélection opérée par IDA). 
Note 2: la sélection et la lecture d'un fichier sont également réalisables en une étape à l'aide de la 
commande Read Binar y et d'un identif iant EF cour t. 26.5.2016 L 139/278 Jour nal officiel de l'Union européenne FR     
3.3.3  Séquence de téléchargement des fichiers de données signés 
DDP_038  Il y a lieu de recour ir à la séquence ci-après pour procéder au télécharg ement de chacun des 
fichiers qui suivent accompagnés de leur signature: 
Carte Dir IDE/IFD Signification/Remarques  
Select File  
OK 
Procéder au hachage du 
fichier (Hash of File) Permet de calculer la valeur 
de hachag e par rappor t au 
contenu du fichier sélec ­
tionné en appliquant l'algo ­
rithme de hachag e prescr it en 
conf ormité avec l'appendice 
11. Cette commande n'est 
pas une commande ISO. 
Calculer le hachag e du 
fichier et enregistrer 
temporairement la va­
leur de hachage retenue    
OK 
Read Binar y Si le fichier contient plus de 
données que le tam pon ou la 
carte ne peut en conte nir, la 
commande doit être réitérée 
jusqu'à ce que les données 
que contient ce fichier aient 
été extrait es dans leur inté­
gralité. 
Données 
OK 
Sauvegarder les données sur 
l'ESM selon 3.4 Data storage for­
mat  
PSO: Compute Digit al Si­
gnature  
Exécution opération de 
sécur ité «Calcul de la si­
gnature numér ique» à 
l'aide de la valeur de ha­
chage temporairement 
enregistrée    
Signature 
OK 
Adjonction de données à 
celles préalablement sauve ­
gardées sur l'ESM selon 3.4 Data storage for­
mat  
Remarque: la sélection et la lecture d'un fichier sont également réalisables en une étape à l'aide de 
la commande Read Binar y et d'un identif iant EF cour t. Dans ce cas, l'EF peut être sélectionné et lu 
avant d'exécut er la commande procédant au hachag e du fichier . 
3.3.4  Séquence de réinitialisation d'un compteur d'étalonnag e. 
DDP_039  La séquence de réinitialisation du comp teur 
 que contient 
l'EF 
 d'une carte d'atelier se présent e comme suit: 
Carte Dir IDE/IFD Signification/Remarques  
Select File EF Card_Do wn­
load Sélection par le biais d'iden ­
tificateurs de fichier 
OK 
26.5.2016 L 139/279 Jour nal officiel de l'Union européenne FR     
Carte Dir IDE/IFD Signification/Remarques  
Update Binar y 
NoOfCalibrationsSince ­
Download = ‘00 00’  
réinitialise le nombre de 
télécharg ements de la 
carte    
OK 
Remarque: la sélection et la mise à jour d'un fichier sont également réalisables en une étape à l'aide 
de la commande Update Binar y et d'un identif iant EF cour t.  
3.4.  Format d'archivage des données 
3.4.1  Intro duction 
DDP_040  Les données téléc hargées doivent être enregistrées dans les conditions suivante s: 
—  L'enregistrement des données doit être transparent. En d'autres termes, l'ordre dans lequel se 
présent ent les octets et les bits constitutifs de ces octets doit être préser vé lors de l'opération 
d'arc hivage exécut ée après leur transfer t de la carte. 
—  Tous les fichiers de la carte téléc hargés dans le cadre d'une session de télécharg ement doivent 
être enregistrés au sein d'un seul et même fichier sur l'ESM. 
3.4.2  Format des fichiers 
DDP_041  Le format des fichiers se présente comme la concaténation de plusieurs objets TLV. 
DDP_042  La balise associée à un EF doit prendre la forme du FDI du fichier assor ti de l'appendice ‘00’. 
DDP_043  La balise associée à la signature d'un EF doit prendre la forme du FDI du fichier assor ti de 
l'appendice ‘01’. 
DDP_044  La longueur correspond à une valeur expr imée par deux octets. Cette valeur détermine le nombre 
d'oct ets affectés au champ valeur . La valeur ‘FF FF’ que contient le champ longueur est réser vée à 
un usage ultérieur. 
DDP_045  Faut e de télécharg ement, aucune information relative à un fichier déter miné ne sera sauveg ardée 
(pas de balise et pas de longueur zéro). 
DDP_046  Toute signature doit être sauvegardée sous forme d'objet TLV immédiatement après l'objet TLV qui 
contient les données que recèle le fichier concer né. 
Défini tion Signif ication Longueur 
FDI (2 octets) ||‘00’ Balise pour EF (FDI) 3 octets 
FDI (2 octets) ||‘01’ Balise pour signature d'EF 
(FDI) 3 octets 
xx xx Longueur du champ valeur 2 octets  
Exemple de données enregistrées dans un fichier de téléc hargement sur un ESM: 
Balise Longueur Valeur 
Données du EF ICC 
Données du EF Card_Cer tificate   
… 
Données du EF 
Signature du EF 
26.5.2016 L 139/280 Jour nal officiel de l'Union européenne FR     
4.  TÉLÉCHAR GEMENT D'UNE CARTE TACHY GRAPHIQUE PAR L'INTERMÉDIAIRE D'UNE UNITÉ EMBARQ UÉE SUR 
VÉHICULE. 
DDP_047  La VU doit autori ser le téléc hargement du cont enu d'une carte de conduct eur insérée dans le 
lecteur d'un IDE connecté. 
DDP_048  Cet IDE doit envoyer un message «Demande de transfer t de données du type téléc hargem ent de 
carte» à la VU pour lancer ce mode de transmission (cf. 2.2.2.9). 
DDP_049  À ce stade, la VU doit procéder au téléc hargement de la carte dans son intégrali té, fichier par 
fichier , en conf ormité avec le protocole de téléc hargement de carte défini au paragraphe 3 ainsi 
qu'à l'env oi à l'IDE de tout es les données extraites de la carte dans le format de fichier TLV 
appropr ié (cf. 3.4.2) et encapsulées dans un message «Réponse positive à une demande de 
transfer t de données». 
DDP_050  L'IDE doit extraire les données de la carte intégrées au message «Réponse positive à une demande 
de transfer t de données» (en éliminant tous les en-tête s, SID, TREP , comp teur s de sous-messages et 
totaux de contrôle) et les enregistrer dans un seul et même fichier physique conf ormément à la 
descr iption présent ée au paragraphe 2.3. 
DDP_051  Ensuite , la VU doit, selon le cas, procéder à une actualisation du fichier de données des activités de 
contrôle ou de téléc hargem ent de cartes (
 ou 
 ) sur la 
carte du conduct eur.  26.5.2016 L 139/281 Jour nal officiel de l'Union européenne FR     
Appendice 8 
PROTOCOLE D'ÉT ALONN AGE 
TABLE DES MATIÈRES 
1. INTR ODUCTION ................................................................................................................................ 283 
2. TERMINOLOGIE, DÉFINITIONS ET RÉFÉRENCES ........................................................................................ 283 
3. VUE D'ENSEMBLE DES SER VICES ........................................................................................................... 284 
3.1. Services disponibles ................................................................................................................ 284 
3.2. Codes de réponse ................................................................................................................... 285 
4. SER VICES DE COMMUNICA TION ........................................................................................................... 285 
4.1. Service Star tCommunication ..................................................................................................... 285 
4.2. Service StopCommunication ..................................................................................................... 287 
4.2.1 Descr iption des message s......................................................................................................... 287 
4.2.2 Structure des messages ............................................................................................................ 288 
4.2.3 Définition des paramètres ........................................................................................................ 289 
4.3. Service TesterPresent ............................................................................................................... 289 
4.3.1 Descr iption des message s......................................................................................................... 289 
4.3.2 Structure des messages ............................................................................................................ 289 
5. SER VICES DE GESTION ........................................................................................................................ 291 
5.1. Service Star tDiagnosticSession ................................................................................................... 291 
5.1.1 Descr iption des message s......................................................................................................... 291 
5.1.2 Structure des messages ............................................................................................................ 292 
5.1.3 Définition du paramètre ........................................................................................................... 293 
5.2. Service Secur ityA ccess ............................................................................................................. 294 
5.2.1 Descr iption des message s......................................................................................................... 294 
5.2.2 Structure des messages — Secur ityA ccess — requestSeed ................................................................ 295 
5.2.3 Structure des messages — Secur ityA ccess — sendKey ..................................................................... 296 
6. SER VICES DE TRANSMISSION DE DONNÉES ............................................................................................ 297 
6.1. Service ReadDataByIdentifi er..................................................................................................... 298 
6.1.1 Descr iption des message s......................................................................................................... 298 
6.1.2 Structure des messages ............................................................................................................ 298 
6.1.3 Définition des paramètres ........................................................................................................ 299 
6.2. Service WriteDataByIdentifier .................................................................................................... 300 
6.2.1 Descr iption des message s......................................................................................................... 300 
6.2.2 Structure des messages ............................................................................................................ 300 
6.2.3 Définition du paramètre ........................................................................................................... 302 26.5.2016 L 139/282 Jour nal officiel de l'Union européenne FR     
7. CONTRÔLE DES IMPULSIONS D'ESSA I — UNITÉ FONCTIONNELLE DE CON TRÔLE DES ENTRÉES/SORTIES ........... 302 
7.1. Service InputOutputControlByIdentifier ....................................................................................... 302 
7.1.1 Descr iption des message s......................................................................................................... 302 
7.1.2 Structure des messages ............................................................................................................ 303 
7.1.3 Définition du paramètre ........................................................................................................... 304 
8. STR UCTURES DES DATARECORDS ........................................................................................................ 305 
8.1. Gammes des paramètres transmis .............................................................................................. 305 
8.2. Structures des dataRecords ....................................................................................................... 306  
1.  INTR ODUCTION 
Le présent appendice traite des modalités d'échang e des données entre un appareil d'essai et une unité embarquée 
sur véhicule par l'inter médiaire de la ligne K. Cette ligne fait partie intégrante de l'interface d'étalonnage décr ite à 
l'appendice 6. Le présent appendice traite aussi du contrôle de la ligne de signalisation d'entrée/sor tie exercé au 
niveau du connecteur d'étalonnage. 
L'établissement de communications sur la ligne K est décr it à la section 4 «Ser vices de communication». 
Le présent appendice s'appuie sur le concept de «sessions» de diagnostic pour déter miner la portée du contrôle de 
la ligne K au gré de l'évolution des modalités d'échang e. La session par défaut est la «StandardDiagnosticSession», 
où tout es les données que contient une unité embarquée sur véhicule sont susceptibles d'en être extrait es, mais 
aucune donnée ne peut être enregistrée sur cette unité . 
La sélection de la session de diagnostic fait l'objet d'une descr iption détaillée à la section 5 «Ser vices de gestion». 
Le présent appendice s'applique aux deux générations de VU et de cartes d'atelier , conf ormément aux exigenc es 
d'interopérabilit é établies par le présent règlement. 
CPR_001  La «ECUProgrammingSession» autor ise l'entrée de données au sein de l'unité embarquée sur véhicule. 
En cas d'entrée de données d'étalonnag e, l'unité embarquée sur véhicule doit en outre être exploité e en 
mode ÉTALONNA GE. 
Le transfer t de données par l'intermédiaire de la ligne K fait l'objet d'une descr iption détaillée à la 
section 6 «Ser vices de transmission de données». Les formats des données transférées sont décr its en 
détail à la section 8 «dataRecords formats». 
CPR_002  «ECU AdjustmentSession» permet de sélectionner le mode d'entrée/sor tie de la ligne de signalisation 
d'entrée/sor tie d'étalonnag e à l'aide de l'interface de la ligne K. Le contrôle de la ligne de signalisation 
d'entrée/sor tie d'étalonnag e fait l'objet d'une descr iption à la section 7 «Contrôle des impulsions d'essai 
— Unit é fonctionnelle de contrôle des entrées/sor ties». 
CPR_003  Tout au long du présent document, l'appareil d'essai possède l'adresse suivante: «tt». Bien que certaines 
adresses d'appareil d'essai soient privilégiées, la VU doit réagir correcte ment à tout e adresse d'appareil 
d'essai. L'adresse physique de la VU s'énonce comme suit: 0xEE. 
2.  TERMINOLOGIE, DÉFINITIONS ET RÉFÉRENCES 
Les protocoles, message s et codes d'erreur sont principalement basés sur un projet de norme ISO 14229-1 
(Véhicules routiers — Systèmes de diagnostic — Partie 1: services de diagnostic, version 6 du 22 février 2001). 
Des codages d'octets et autres valeurs hexadécimales s'utilisent lors de la définition des identif icateurs de service, 
de l'élaboration des demandes et réponses de service et de la conf iguration des paramètres standard. 
Le term e «appareil d'essai» fait référence à l'équipement utilisé pour saisir des données de programmation/ 
étalonnage dans la VU. 
Les term es «client» et «serveur» font respectivement référen ce à l'appareil d'essai et à la VU. 
Le term e ECU (Electr onic Control Unit) signif ie «unit é de commande électronique» et s'applique à la VU. 26.5.2016 L 139/283 Jour nal officiel de l'Union européenne FR     
Références: 
ISO 14230-2: Véhicules routiers — Systèmes de diagnostic — Prot ocole à mots clés 2000 — Partie 2: Couche de 
liaison de données. 
Première édition: 1999. 
Véhicules routiers — Diagnostic. 
3.  VUE D'ENSEMBLE DES SER VICES 
3.1.  Services disponibles 
Le tableau qui suit présent e une vue d'ensemble des services définis dans le présent document et auxquels doit 
pour voir le tach ygraphe. 
CPR_004  Ce tableau indique quels sont les services disponibles lors d'une session de diagnostic active. 
—  La 1re colonne réper torie les services disponibles. 
—  La 2e colonne indique le numéro de section qui présent e une descr iption détaillée du service 
considéré dans le présent appendice. 
—  La 3e colonne indique les valeurs affectées à l'identifi cateur de service dans les messages de 
demande de service. 
—  La 4e colonne précise quels sont les services de la «StandardDiagnos ticSession» (SD) dont la mise 
en œuvre dans la VU est indispensable. 
—  La e colonne précise quels sont les services de la «ECU AdjustmentSession» (ECU AS) dont la mise 
en œuvre est indispensable pour permettre un contrôle adéquat de la ligne de signalisation d'entrée/ 
sortie au niveau du connecteur d'étalonnag e mont é sur la face avant de la VU. 
—  La 6e colonne précise quels sont les services de la «ECUProg rammingSession» (ECUPS) dont la 
mise en œuvre est indispensable pour procéder à la programmation des paramètres d'exploitation 
dans la VU. 
Tableau 1 
Récapitulatif des valeurs affectées aux identif icateurs de service  
Sessions de diagnostic 
Noms des services de diagnostic Section no Valeurs affec ­
tées aux identi ­
ficateur s de 
service SD ECU AS ECUPS 
Star tCommunication 4.1 81             
StopCommunicatio n 4.2 82       
TesterPresent 4.3 3E             
Star tDiagnosticSession 5.1 10             
Secur ityA ccess 5.2 27             
ReadDataByIdentifi er 6.1 22             
WriteDataByIdentifier 6.2 2E       
InputOutputCont rolByIdentif ier 7.1 2F         
   Ce symbole rappelle le caractère obligat oire du service correspondant pendant cette session de diagnostic. 
Aucu n symbole n'indique que l'exécution du service correspondant n'est pas auto risée pendant cette session de diagnostic.  26.5.2016 L 139/284 Jour nal officiel de l'Union européenne FR     
3.2.  Codes de réponse 
Des codes de réponse sont définis pour chaque service. 
4.  SER VICES DE COMMUNICA TION 
Certains services sont nécessaires à l'établissement et au maintien des communications. Ils n'apparaissent pas dans 
la couch e application. Les services disponibles sont décr its dans le tableau ci-après: 
Tableau 2 
Services de communication 
Nom du service Descr iption 
Star tCommunication Le client demande le lancement d'une session de communication avec un ou 
plusieurs serveur(s). 
StopCommunicatio n Le client demande l'arrêt de la session de communication en cours. 
TesterPresent Le client indique au serveur qu'il est encore présent.  
CPR_005  Le service Star tCommunication est utilisé pour établir une communication. L'exécution de tout service 
suppose l'établissement d'une communication et la sélection de paramètres adap tés au mode d'exploi ­
tation souhaité. 
4.1.  Service Star tCommunication 
CPR_006  À la récep tion d'une primitive d'indication Star tCommunication, la VU vérifie si l'établissement de la 
liaison d'intercommunication requise est envisageable dans les conditions présent es. Les conditions 
d'établissement d'une liaison d'inte rcommunication font l'objet d'une descr iption détaillée dans le 
document ISO 14230-2. 
CPR_007 Ensuit e, la VU doit exécut er tout es les actions nécessaires à l'établissement de la liaison d'intercommuni ­
cation requise et envoyer une primitive de réponse Star tCommunication avec les paramètres de 
réponse positive sélectionnés. 
CPR_008 Si une VU déjà initialisée (et entrée en session de diagnostic) reçoit une nouvelle demande Star tCommu ­
nication (p.ex. en raison d'une repr ise sur incident au niveau de l'appareil d'essai), cette demande doit 
être accept ée et la VU réinitialisée. 
CPR_009  Si, pour une raison quelconque, l'établissement de la liaison d'intercommunication s'avère impossible, 
la VU doit continuer à fonctionner dans les mêmes conditions qu'immédiatement avant la tentative 
d'établissement d'une liaison d'inter communication. 
CPR_010  Le messag e de demande Star tCommunication doit compor ter une adresse physique. 
CPR_011  L'initialisation de la VU pour les services est réalisée par la méthode d'initialisation rapide. 
—  Il existe un temps d'inoccupation préalable à tout e activité. 
—  L'appareil d'essai envoie ensuite une conf iguration d'initialisation. 
—  Toutes les informations nécessaires à l'établissement d'une communication sont contenues dans la 
réponse de la VU. 
CPR_012  Après initialisation, 
—  tout es les valeurs attribuées à l'ensemble des paramètres de communication sont celles définies dans 
le tableau 4 en fonction des octets clés, 
—  la VU attend la première demande en provenance de l'appareil d'essai, 26.5.2016 L 139/285 Jour nal officiel de l'Union européenne FR     
—la VU se trouve en mode de diagnostic par défaut, autrement dit le mode StandardDiagnostic ­
Session; 
—  la ligne de signalisation d'entrée/sor tie d'étalonnage est dans son état d'exploitation par défaut , à 
savoir, désactivée. 
CPR_014  Le débit de données sur la ligne K est de 10 400 bauds. 
CPR_016  L'initialisation rapide est lancée par l'appareil d'essai, lequel émet une trame de réveil (Wup) sur la ligne 
K. Cette trame début e au term e d'un délai d'inoccupation de la ligne K suivi d'un temps de Tinil. 
L'appareil d'essai émet le premier bit du service Star tCommunication au term e d'un délai de Twup suivi 
du premier front descendant. 
CPR_017  Les valeurs de synchr onisation propres à l'initialisation rapide et aux communications en général font 
l'objet d'une descr iption détaillée dans les tableaux ci-après. Pour ce qui concer ne le temps d'inoccu ­
pation, plusieurs possibilit és sont envisageables: 
—  Première transmission après mise en marc he, Tidle = 300 ms. 
—  Après achè vement du Service StopCommunication, Tidle = P3 min. 
—  Après interrupti on d'une communication pour cause de dépassement du temps imp arti P3 max., 
Tidle = 0. 
Tableau 3 
Valeurs de synchronisation propres à l'initialisation rapide 
Paramètre Valeur minimale Valeur maximale 
Tinil 25 ± 1 ms 24 ms 26 ms 
Twup 50 ± 1 ms 49 ms 51 ms  
Tableau 4 
Valeurs de tempor isation des communications 
Paramètre 
de synchro ­
nisation Descr iption des paramètres Valeurs minimales 
admises (ms) Valeurs maxi ­
males admises 
(ms) 
min. max. 
P1 Délai interoctet à respecter dans l'attent e d'une ré­
ponse de la VU 0 20 
P2 Laps de temps entre une demande de l'appareil 
d'essai et une ou deux réponse(s) de la VU 25 250 
P3 Laps de temps entre la fin des réponses de la VU 
et le début d'une nouvelle demande émise par l'ap­
pareil d'essai 55 5 000 
P4 Délai inter octet à respecter dans l'attente d'une de­
mande émise par l'appareil d'essai 5 20  26.5.2016 L 139/286 Jour nal officiel de l'Union européenne FR     
CPR_018  La structure des messages transmis dans le cadre d'une initialisation rapide fait l'objet d'une descr iption 
détaillée dans les tableaux qui suivent. 
Tableau 5 
Message Star tCommunication Request 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 81 FMT 
#2 Octe t d'adresse de la cible EE TGT 
#3 Octe t d'adresse de la source tt SRC 
#4 Star tCommunication Request Service Id 81 SCR 
#5 Total de contrôle 00-FF CS  
Tableau 6 
Message StartCommunication Positiv e Response 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible tt TGT 
#3 Octe t d'adresse de la source EE SRC 
#4 Octe t de longueur supplémentaire 03 LEN 
#5 Star tCommunication Positiv e Response Ser­
vice Id C1 SCRPR 
#6 Octe t clé 1 EA KB1 
#7 Octe t clé 2 8F KB2 
#8 Total de contrôle 00-FF CS  
CPR_019  Il n'y a pas de réponse négat ive au message Star tCommunication Request. Faut e de messag e de réponse 
positive à transmettre, la VU n'est pas initialisée, aucune donnée n'est émise et le système demeure en 
mode d'exploitation normal. 
4.2.  Service StopCommunication 
4.2.1  Descr iption des messages 
Ce service portant sur la couc he communication vise à mettre un terme à tout e session de communication. 
CPR_020  À la réception d'une primitive d'indication StopCo mmunication, la VU doit vérifier si les conditions en 
vigueur permett ent d'interrompre la communication en cours. Si tel est le cas, la VU doit exécut er 
tout es les opérations requises pour mettre un terme à cette communication. 26.5.2016 L 139/287 Jour nal officiel de l'Union européenne FR     
CPR_021  Si une interrupti on de la communication est envi sageable, la VU doit émettre une primitive de réponse 
StopCommunication en recourant aux paramètres de réponse positive sélectionnés, avant de clore la 
communication. 
CPR_022  Si, pour une raison quelconque, il s'avère impos sible d'interr ompr e la communication concer née, la VU 
doit émettre une primitive de réponse StopCommunication en recourant au paramètre de réponse 
néga tive sélectionné. 
CPR_023 Si la VU détecte un dépassement du délai P3max, la communication est interrom pue sans s'accom ­
pagner de l'émission d'aucune primitive de réponse. 
4.2.2  Structur e des messages 
CPR_024  La structure des messages associés aux primitives StopCommunication fait l'objet d'une descr iption 
détaillée dans les tableaux ci-après. 
Tableau 7 
Message StopCommunication Request 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible EE TGT 
#3 Octe t d'adresse de la source tt SRC 
#4 Octe t de longueur supplémentaire 01 LEN 
#5 StopCommunication Request Service Id 82 SPR 
#6 Total de contrôle 00-FF CS  
Tableau 8 
Message StopCommunication Positiv e Response 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible tt TGT 
#3 Octe t d'adresse de la source EE SRC 
#4 Octe t de longueur supplémentaire 01 LEN 
#5 StopCommunication Positiv e Response Ser­
vice Id C2 SPRPR 
#6 Total de contrôle 00-FF CS  26.5.2016 L 139/288 Jour nal officiel de l'Union européenne FR     
Tableau 9 
Message StopCommunication Negativ e Response 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible tt TGT 
#3 Octe t d'adresse de la source EE SRC 
#4 Octe t de longueur supplémentaire 03 LEN 
#5 negativ e Response Service Id 7F NR 
#6 StopCommunication Request Service Identif ication 82 SPR 
#7 responseCode = generalReject 10 RC_GR 
#8 Total de contrôle 00-FF CS  
4.2.3  Définition des paramètres 
Ce service ne nécessite la définition d'aucun paramètre. 
4.3.  Service Tester Present 
4.3.1  Descr iption des messages 
Le service TesterPresent est utilisé par l'appareil d'essai pour indiquer au serveur qu'il est encore présent, afin 
d'empêc her que le serveur ne retour ne automatiquement en fonctionnement normal et ne coupe éventuellement 
la communication. Ce service, envoyé périodiquement, maintien en activité la session de diagnostic et la 
communication en remettant à zéro le comp teur P3 à chaque demande de prestation. 
4.3.2  Structur e des messages 
CPR_079  La structure des messag es associés aux primitives TesterPresent fait l'objet d'une descr iption détaillée 
dans les tableaux ci-après. 
Tableau 10 
Message TesterPresent Request 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible EE TGT 
#3 Octe t d'adresse de la source tt SRC 
#4 Octe t de longueur supplémentaire 02 LEN 
#5 Tester Present Request Service Id 3E TP 26.5.2016 L 139/289 Jour nal officiel de l'Union européenne FR     
Octet # Nom de paramètre Valeur hex. Mnémonique 
#6 Sous-f onction = responseRequired = [oui 01 RESPREQ_Y 
non ] 02 RESPREQ_NO 
#7 Total de contrôle 00-FF CS  
CPR_080  Si le paramètre responseRequired est «oui», le serveur répondra par le messag e positif suivant. Si le 
paramètre est «non», le serveur n'env oie pas de réponse. 
Tableau 11 
Message TesterPresent Positiv e Response 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible tt TGT 
#3 Octe t d'adresse de la source EE SRC 
#4 Octe t de longueur supplémentaire 01 LEN 
#5 Tester Present Positiv e Response Service Id 7E TPPR 
#6 Total de contrôle 00-FF CS  
CPR_081  Le service accep te les codes de réponse négative suivants: 
Tableau 12 
Message Tester Present Negativ e Response 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible tt TGT 
#3 Octe t d'adresse de la source EE SRC 
#4 Octe t de longueur supplémentaire 03 LEN 
#5 negativ e Response Service Id 7F NR 
#6 TesterPresent Request Service Identification 3E TP 26.5.2016 L 139/290 Jour nal officiel de l'Union européenne FR     
Octet # Nom de paramètre Valeur hex. Mnémonique 
#7 responseCode = [SubFunctionNotSuppor ted-In­
validFor mat 12 RC_SFNS_IF 
incor rectMessageL ength ] 13 RC_IML 
#8 Total de contrôle 00-FF CS  
5.  SER VICES DE GESTION 
Les services disponibles font l'objet d'une descr iption détaillée dans le tableau ci-après: 
Tableau 13 
Services de gestion 
Nom du service Descr iption 
Star tDiagnosticSession Le client demande le lancement d'une session de diagnostic avec une VU. 
Secur ityA ccess Le client demande l'accès à certaines fonctions réser vées aux utilisat eurs autori ­
sés.  
5.1.  Service Star tDiagnos ticSession 
5.1.1  Descr iption des messages 
CPR_025  Le service Star tDiagnosticSession permet d'activer différ entes sessions de diagnostic au sein du serveur . 
Une session de diagnostic autori se l'exploitation d'un jeu de services spécifi que, conf ormément aux 
indications fournies au Tableau 17. Une session peut permettre des services spécifi ques du constr ucteur 
du véhicule qui ne font pas partie du présent document. Les règles de mise en œuvre doivent satisf aire 
aux exige nces suivantes: 
—  il doit touj ours y avoir exactement une session de diagnostic en cours dans la VU, 
—  la VU doit touj ours ouvr ir la StandardDiagnosticSession lorsqu'elle est mise sous tension. Si aucune 
autre session de diagnostic n'est ouver te, la StandardDiagnosticSession doit rester ouver te aussi 
longtem ps que la VU est sous tension, 
—  si une session de diagnostic déjà ouver te a été demandée par l'appareil d'essai, la VU envoie un 
message de réponse positive; 
—  lorsque l'appareil d'essai demande une nouvelle session de diagnostic, la VU envoie d'abord un 
message de réponse positive Star tDiagnosticSession avant que la nouvelle session ne s'ouvre dans la 
VU. Si la VU n'a pu ouvr ir la nouvelle session de diagnostic demandée, elle envoie un message de 
réponse négative à Star tDiagnosticSession et la session en cours se poursuit. 
CPR_026  Le lancement d'une session de diagnostic n'est envisag eable qu'à la condition qu'une communication ait 
été préalablement établie entre le client et la VU. 
CPR_027  Les paramètres de sync hronisation définis dans le Tableau 4 deviendront actifs au terme de l'exécution 
réussie d'une Star tDiagnosticSession, pour autant que le message de demande compor te le paramètre 
diagnosticSession défini sur «StandardDiagnosticSession» dans l'éventualité où une autre session de 
diagnostic aurait été préalablement active. 26.5.2016 L 139/291 Jour nal officiel de l'Union européenne FR     
5.1.2  Structur e des messages 
CPR_028  La structure des messages associés aux primitives Star tDiagnosticSession fait l'objet d'une descr iption 
détaillée dans les tableaux ci-après. 
Tableau 14 
Message Star tDiagnos ticSession Reques t 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible EE TGT 
#3 Octe t d'adresse de la source tt SRC 
#4 Octe t de longueur supplémentaire 02 LEN 
#5 Star tDiagnos ticSession Request Service Id 10 STDS 
#6 diagnosticSession = [une valeur extraite du Tableau 
17] xx DS_… 
#7 Total de contrôle 00-FF CS  
Tableau 15 
Message StartDiagnos ticSession Positiv e Response 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible tt TGT 
#3 Octe t d'adresse de la source EE SRC 
#4 Octe t de longueur supplémentaire 02 LEN 
#5 Star tDiagnos ticSession Positiv e Response Ser­
vice Id 50 STDSPR 
#6 diagnosticSession = [même valeur que l'octet 6 du 
Tableau 14 ] xx DS_… 
#7 Total de contrôle 00-FF CS  
Tableau 16 
Message StartDiagnos ticSession Negativ e Response 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible tt TGT 26.5.2016 L 139/292 Jour nal officiel de l'Union européenne FR     
Octet # Nom de paramètre Valeur hex. Mnémonique 
#3 Octe t d'adresse de la source EE SRC 
#4 Octe t de longueur supplémentaire 03 LEN 
#5 Negativ e Response Service Id 7F NR 
#6 Star tDiagnosticSession Request Service Id 10 STDS 
#7 ResponseCode = [subFunctionNotSuppor ted(a) 12 RC_SFNS 
incor rectMessageL ength (b) 13 RC_IML 
conditionsNotCor rect (c) 22 RC_CNC 
#8 Total de contrôle 00-FF CS 
(a)  La valeur introduite dans l'octet 6 du message de demande n'est pas prise en charg e, c.-à-d. pas dans le Tableau 
17, 
(b)  la longueur du message est incor recte, 
(c)  les critères pour la demande Star tDiagnosticSession ne sont pas remplis.  
5.1.3  Définition du paramètre 
CPR_029  Le service Star tDiagnosticSession utilise le paramètre diagnosticSession (DS_) pour sélectionner le 
compo rtement particulier du ou des serveurs. Les sessions de diagnostic qui suivent sont précisées dans 
le présent document : 
Tableau 17 
Déf inition des valeurs diagnosti cSession 
Hex. Descr iption Mnémo ­
nique 
81 StandardDiagnos ticSession 
Cette session de diagnostic permet d'activer tous les services indiqués 
dans le Tableau 1 colonne 4 «SD». Ces services autori sent l'extraction de 
données enregistrées sur un serveur (VU). Cette session de diagnostic ne 
devient active qu'après la réussite de la phase d'initialisation entre client 
(appareil d'essai) et serveur (VU). Cette session de diagnostic est suscep ­
tible d'être écrasée par d'autres sessions de diagnostic spécifi ées dans ce 
chapitre. SD 
85 ECUProg rammingSession 
Cette session de diagnostic permet d'activer tous les services indiqués 
dans le Tableau 1 colonne 6 «ECUPS». Ces services prennent en charge 
la programmation de la mémoire d'un serveur (VU). Cette session de diag ­
nostic est suscept ible d'être écrasée par d'autres sessions de diagnostic spé­
cifiées dans cette Section. ECUPS 
87 ECU Adjust mentSession 
Cette session de diagnostic permet d'activer tous les services indiqués 
dans le Tableau 1 colonne 5 «ECU AS». Ces services prennent en charge 
le contrôle des entrées/sor ties d'un serveur (VU). Cette session de diagnos ­
tic est susceptible d'être écrasée par d'autres sessions de diagnostic spéci ­
fiées dans ce chapitre. ECU AS  26.5.2016 L 139/293 Jour nal officiel de l'Union européenne FR     
5.2.  Service Secur ityAc cess 
Il n'est possible d'écr ire des données d'étalonnag e que si la VU est en mode ÉTALONNA GE. Outre l'inser tion 
d'une carte d'atelier valide dans le lecteur appropr ié de la VU, il est indispensable d'entrer le numéro d'identifi ­
cation individuel adéquat dans la VU pour avoir accès au mode ÉTALONNA GE. 
Lorsque la VU est en mode ÉTALONNA GE ou CONTRÔLE, il est également possible d'accéder à la ligne E/S 
d'étalonnag e. 
Le service Secur ityA ccess permet d'introduire le numéro d'identif ication individuel et d'indiquer à l'appareil d'essai 
si la VU est exploit ée ou non en mode ÉTALONNA GE. 
Le système permet de recour ir à d'autres méthodes pour entrer ce numéro d'identification individuel. 
5.2.1  Descr iption des messages 
Le service Secur ityA ccess compo rte l'exécution d'un message Secur ityA ccess «requestSeed» (demande de germe), 
suivi le cas échéant d'un messag e Secur ityA ccess «sendKey» (demande d'en voi d'une clé). Le service Secur ityA ccess 
doit être exécut é après le service Star tDiagnosticSession. 
CPR_033  L'appareil d'essai doit utiliser le messag e Secur ityA ccess «requestSeed» pour vérifier si l'unit é embarquée 
sur véhicule est prêt e à accept er un PIN (numéro d'identif ication individuel). 
CPR_034  Si l'unité embarquée sur véhicule est déjà en mode ÉTALONNA GE, elle répond à la demande qui lui est 
adressée par l'env oi d'un «germe » de 0x0000 en utilisant le service Secur ityA ccess Positive Response. 
CPR_035  Si l'unité embarquée sur véhicule est prêt e à accept er un PIN en vue d'une opération de vérification au 
moyen d'une carte d'atelier , elle doit répondre à la demande qui lui est adressée par l'env oi d'un 
«germe» d'une valeur supér ieure à 0x0000 en utilisant le service Secur ityA ccess Positive Response. 
CPR_036  Si l'unité embarquée sur véhicule n'est pas prête à accept er un PIN émanant de l'appareil d'essai parce 
que la carte d'ateli er insérée dans le lecte ur n'est pas valable, parce que ce dernier n'en contient aucune 
ou que l'unité embarquée sur véhicule attend la transmission du PIN requis par une autre méthode, 
celle-ci doit répondre à la demande qui lui est adressée par l'env oi d'une réponse négative accompagnée 
d'un code de réponse conditionsNotCor rectOrRequestSequenceEr ror. 
CPR_037  En définitive, l'appareil d'essai devra recour ir au message Secur ityA ccess «sendKe y» pour transmettre un 
PIN à l'unit é embarquée sur véhicule. Pour ménager le temps nécessaire à l'exécution du processus 
d'authentification de la carte, la VU devra recour ir au code de réponse négat ive requestCor rectlyRe ­
ceived-ResponsePen ding (demande bien reçue — réponse suit) afin de prolonger le temps de réponse. 
Le temps de réponse ne devra cependant pas dépasser 5 minutes. Dès que le service demandé est 
exécuté, la VU envoie un messag e de réponse positive ou négative avec un code de réponse différ ent du 
code précité . Le code de réponse négative requestCor rectlyReceived-ResponseP ending peut être répété 
par la VU jusqu'à ce que le service demandé soit exécut é et le message de réponse finale envoyé. 
CPR_038  L'unité embarquée sur véhicule ne doit répondre à cette demande en utilisant le service Secur ityA ccess 
Positive Response qu'à la condition d'être exploit ée en mode ÉTALONNA GE. 
CPR_039  Dans les cas énumérés ci-après, l'unit é embarquée sur véhicule doit répondre à cette demande par une 
réponse négat ive accompag née de l'un des codes de réponse suivants: 
—  subFunctionNot suppor ted: format non valable pour le paramètre de la sous-f onction (accessT ype), 
—  conditionsNotCor rectOrRequestSequenceEr ror: unité embarquée sur véhicule pas prêt e à accept er 
l'entrée d'un PIN, 
—  invalidKe y: PIN non valable sans dépassement du nombre de tentatives de vérification de ce 
numéro, 
—  exceededNumberOfA ttem pts: PIN non valable et dépassement du nombre de tentatives de 
vérification de ce numéro, 
—  generalReject: PIN correct, mais échec de la tentative d'authentifi cation mutuelle avec la carte 
d'atelier utilisée. 26.5.2016 L 139/294 Jour nal officiel de l'Union européenne FR     
5.2.2  Structur e des messages — Secur ityA ccess — request Seed 
CPR_040  La structure des messages associés aux primitives Secur ityA ccess «requestSeed» fait l'objet d'une 
descr iption détaillée dans les tableaux ci-après. 
Tableau 18 
Message Secur ityAccess Request- request Seed 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible EE TGT 
#3 Octe t d'adresse de la source tt SRC 
#4 Octe t de longueur supplémentaire 02 LEN 
#5 Secur ityA ccess Request Service Id 27 SA 
#6 accessT ype — requestSeed 7D AT_RSD 
#7 Total de contrôle 00-FF CS  
Tableau 19 
Message Secur ityAc cess — request Seed Positiv e Response 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible tt TGT 
#3 Octe t d'adresse de la source EE SRC 
#4 Octe t de longueur supplémentaire 04 LEN 
#5 Secur ityA ccess Positiv e Response Service Id 67 SAPR 
#6 accessT ype — requestSeed 7D AT_RSD 
#7 Seed High 00-FF SEEDH 
#8 Seed Low 00-FF SEEDL 
#9 Total de contrôle 00-FF CS  
Tableau 20 
Message Secur ityAccess Negativ e Response 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible tt TGT 
#3 Octe t d'adresse de la source EE SRC 26.5.2016 L 139/295 Jour nal officiel de l'Union européenne FR     
Octet # Nom de paramètre Valeur hex. Mnémonique 
#4 Octe t de longueur supplémentaire 03 LEN 
#5 negativ eResponse Service Id 7F NR 
#6 Secur ityA ccess Request Service Id 27 SA 
#7 responseCode = [conditionsNotCor rectOrRe ­
questSequenceEr ror 22 RC_CNC 
incor rectMessageL ength] 13 RC_IML 
#8 Total de contrôle 00-FF CS  
5.2.3  Structur e des messages — Secur ityA ccess — sendKe y 
CPR_041  La structure des messag es associés aux primitives Secur ityA ccess «sendKey» fait l'objet d'une descr iption 
détaillée dans les tableaux ci-après. 
Tableau 21 
Message Secur ityAc cess Request — sendKey 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible EE TGT 
#3 Octe t d'adresse de la source tt SRC 
#4 Octe t de longueur supplémentaire m+2 LEN 
#5 Secur ityA ccess Request Service Id 27 SA 
#6 accessT ype — sendKey 7E AT_SK 
#7 à #m 
+6 Clé#1 (sup.) xx KEY 
… …  
Clé #m (inf., la valeur de m doit être comprise en­
tre 4 et 8 inclus) xx  
#m+7 Total de contrôle 00-FF CS  
Tableau 22 
Message Secur ityAccess — sendKey Positiv e Response 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible tt TGT 
#3 Octe t d'adresse de la source EE SRC 26.5.2016 L 139/296 Jour nal officiel de l'Union européenne FR     
Octet # Nom de paramètre Valeur hex. Mnémonique 
#4 Octe t de longueur supplémentaire 02 LEN 
#5 Secur ityA ccess Positiv e Response Service Id 67 SAPR 
#6 accessT ype — sendKey 7E AT_SK 
#7 Total de contrôle 00-FF CS  
Tableau 23 
Message Secur ityAccess Negativ e Response 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible tt TGT 
#3 Octe t d'adresse de la source EE SRC 
#4 Octe t de longueur supplémentaire 03 LEN 
#5 Negativ eResponse Service Id 7F NR 
#6 Secur ityA ccess Request Service Id 27 SA 
#7 ResponseCode = [generalReject 10 RC_GR 
subFunctionNotSuppor ted 12 RC_SFNS 
incor rectMessageL ength 13 RC_IML 
conditionsNotCor rectOrRe ­
questSequenceEr ror 22 RC_CNC 
invalidKey 35 RC_IK 
excee dedNumberOfAtt emp ts 36 RC_ENA 
requestCor rectlyReceived-Res ­
ponseP ending] 78 RC_R CR_RP 
#8 Total de contrôle 00-FF CS  
6.  SER VICES DE TRANSMISSION DE DONNÉES 
Les services disponibles font l'objet d'une descr iption détaillée dans le tableau ci-après: 
Tableau 24 
Services de transmission de données 
Nom du service Descr iption 
ReadDataByIdentifi er Le client demande la transmission de la valeur actuelle d'un relevé avec accès 
par recordDataIdentifie r. 
WriteDataByIdentifier Le client demande l'enregistrement d'un relevé avec accès par recordDataIdenti ­
fier.  26.5.2016 L 139/297 Jour nal officiel de l'Union européenne FR     
6.1.  Service ReadDataByIdentif ier 
6.1.1  Descr iption des messages 
CPR_050  Le message de demande ReadDataByIdentif ier est utilisé par le client pour demander l'extraction de 
valeurs enregistrées sur un serveur . Les données sont identif iées par recordDataIdentif ier. C'est au 
fabricant de la VU qu'incombe la responsabilité de s'assurer que les conditions d'exploitation normale 
du serveur sont réunies lors de l'exécution de ce service. 
6.1.2  Structur e des messages 
CPR_051  La structure des message s associés aux primitives ReadDataByIdentifi er fait l'objet d'une descr iption 
détaillée dans les tableaux ci-après. 
Tableau 25 
Message ReadDat aByIdentif ier Request 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible EE TGT 
#3 Octe t d'adresse de la source tt SRC 
#4 Octe t de longueur supplémentaire 03 LEN 
#5 ReadDataByIdentif ier Request Service Id 22 RDBI 
#6 à #7 recordDataIdentifier = [une valeur extraite du Ta­
bleau 28] xxxx RDI_… 
#8 Total de contrôle 00-FF CS  
Tableau 26 
Message ReadDataBy Identif ier Positiv e Response 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible tt TGT 
#3 Octe t d'adresse de la source EE SRC 
#4 Octe t de longueur supplémentaire m+3 LEN 
#5 ReadDataByIdentif ier Positiv e Response Ser­
vice Id 62 RDBIPR 
#6 et #7 recordDataIdentifier = [même valeur que les octets 
#6 et #7 Tableau 25] xxxx RDI_... 
#8 à #m 
+7 dataRecord[] = [data#1 xx DREC_D ATA1 
: : : 
data#m] xx DREC_D ATAm 
#m+8 Total de contrôle 00-FF CS  26.5.2016 L 139/298 Jour nal officiel de l'Union européenne FR     
Tableau 27 
Message ReadDataByIdentif ier Negativ e Response 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible tt TGT 
#3 Octe t d'adresse de la source EE SRC 
#4 Octe t de longueur supplémentaire 03 LEN 
#5 Negativ eResponse Service Id 7F NR 
#6 ReadDataByIdentifier Request Service Id 22 RDBI 
#7 ResponseCode= [requestOutOfRange 31 RC_R OOR 
incor rectMessageL ength 13 RC_IML 
conditionsNotCor rect] 22 RC_CNC 
#8 Total de contrôle 00-FF CS  
6.1.3  Définition des paramètres 
CPR_052  Le paramètre recor dDataIdentifier (RDI_) dans le message de demande ReadDataByIdentifi er identifie 
un relevé de données. 
CPR_053  Les valeurs recordDataIdentifie r définies par le présent document figurent dans le tableau ci-après. 
Ce tableau recordDataIdentifier se compo se de quatre colonnes et d'un certain nombre de lignes. 
—  La 1re colonne (Hex.) indique la «Valeur hex.» affectée à recordDataIdentif ier spécifié dans la 3e 
colonne. 
—  La 2e colonne (Élément de donnée) indique l'élément de donnée de l'Appendice 1 sur lequel est 
basé recordDataIdentif ier (un transcodage est parfoi s nécessaire). 
—  La 3e colonne (Descr iption) spécifi e le nom recordDataIdentif ier correspondant. 
—  La 4e colonne (Mnémonique) indique le mnémonique associé à ce recordDataIdentifier . 
Tableau 28 
Déf inition des valeurs recordData Identif ier 
Hex. Élément de données Nom du recordDataIdentifier 
(voir la structure indiquée à la Section 8.2) Mnémonique 
F90B 
 CurrentDateTim e RDI_TD 
F912 
 HighResOdomete r RDI_HRT VD 
F918 
 K-ConstantOfRecordingEquipment RDI_KF 26.5.2016 L 139/299 Jour nal officiel de l'Union européenne FR     
Hex. Élément de données Nom du recordDataIdentifier 
(voir la structure indiquée à la Section 8.2) Mnémonique 
F91C 
 L-TyreCircumference RDI_LF 
F91D 
 W-VehicleCharacte risticConstant RDI_WV CF 
F921 
 TyreSize RDI_TS 
F922 
 nextCalibrationDate RDI_NCD 
F92C 
 SpeedAuthor ised RDI_S A 
F97D 
 vehicleRegistrationNation RDI_RMS 
F97E 
 VehicleRegistrationNumber RDI_ VRN 
F190 
 VehicleIdentif icationNumber RDI_ VIN  
CPR_054  Le paramètre dataRecor d (DREC_) est utilisé par le messag e de réponse positive ReadDataByIdentifier 
pour fournir au client (appareil d'essai) la valeur du relevé de données identif iée par recordDataIden ­
tifier . Les structures de données sont indiquées à la Section 8. D'autres dataRecords facultatifs, telles 
que les entrées propres à la VU ainsi que les données de sortie internes et externes, peuvent être 
obte nus au choix de l'utilisat eur, mais ils ne sont pas définis dans le présent document. 
6.2.  Service WriteDat aByIdentif ier 
6.2.1  Descr iption des messages 
CPR_056  Le client a recours au service WriteDataByIdentif ier pour procéder à l'enregistrement de valeurs 
associées aux relevés de données sur un serveur . Les données sont identif iées par recordDataIdentif ier. 
C'est au fabricant de la VU qu'incombe la responsabilité de s'assurer que les conditions d'exploitation 
normale du serveur sont réunies lors de l'exé cution de ce service. Pour procéder à l'actualisation des 
paramètres réper toriés au Tableau 28, il faut que la VU soit exploité e en mode ÉTALONNA GE. 
6.2.2  Structur e des messages 
CPR_057  La structure des messages associés aux primitives WriteDataByIdentif ier fait l'objet d'une descr iption 
détaillée dans les tableaux ci-après. 
Tableau 29 
Message WriteDataByIdent ifier Request 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible EE TGT 
#3 Octe t d'adresse de la source tt SRC 
#4 Octe t de longueur supplémentaire m+3 LEN 
#5 WriteDat aByIdentif ier Request Service Id 2E WDBI 
#6 à #7 recordDataIdentifier = [une valeur extraite du Ta­
bleau 28] xxxx RDI_… 26.5.2016 L 139/300 Jour nal officiel de l'Union européenne FR     
Octet # Nom de paramètre Valeur hex. Mnémonique 
#8 à m+7 dataRecord[] = [data#1 xx DREC_D ATA1 
: : : 
data#m] xx DREC_D ATAm 
#m+8 Total de contrôle 00-FF CS  
Tableau 30 
Message WriteDat aByIdentif ier Positiv e Response 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible tt TGT 
#3 Octe t d'adresse de la source EE SRC 
#4 Octe t de longueur supplémentaire 03 LEN 
#5 WriteDat aByIdentif ier Positiv e Response Ser­
vice Id 6E WDBIPR 
#6 à #7 recordDataIdentifier = [même valeur que les octets 
#6 et #7 Tableau 29] xxxx RDI_... 
#8 Total de contrôle 00-FF CS  
Tableau 31 
Message WriteDat aByIdentif ier Negativ e Response 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible tt TGT 
#3 Octe t d'adresse de la source EE SRC 
#4 Octe t de longueur supplémentaire 03 LEN 
#5 Negativ eResponse Service Id 7F NR 
#6 WriteDataByIdentif ier Request Service Id 2E WDBI 26.5.2016 L 139/301 Jour nal officiel de l'Union européenne FR     
Octet # Nom de paramètre Valeur hex. Mnémonique 
#7 ResponseCode= [requestOutOfRange 31 RC_R OOR 
incor rectMessageL ength 13 RC_IML 
conditionsNotCor rect] 22 RC_CNC 
#8 Total de contrôle 00-FF CS  
6.2.3  Définition du paramètre 
Le paramètre recor dDataIdentifier (RDI_) est défini au Tableau 28. 
Le paramètre dataRecor d (DREC_) est utilisé pour le message de demande WriteDataByIdentifi er afin de fournir 
au serveur (VU) les valeurs de relevé identif iées par le recordDataIdentifie r. Les structures de données sont 
indiquées à la section 8. 
7.  CONTRÔLE DES IMPULSIONS D'ESSAI — UNITÉ FONCTIONNELLE DE CONTRÔLE DES ENTRÉES/SORTIES 
Les services disponibles font l'objet d'une descr iption détaillée dans le tableau ci-après: 
Tableau 32 
Unité fonctionnelle de contrôle des entrées/sor ties 
Nom du service Descr iption 
InputOutputCont rolByIdentif ier Le client demande le contrôle d'une entrée/sor tie propre au serveur .  
7.1.  Service InputOutputControlByIdentif ier 
7.1.1  Descr iption des messages 
La connexion réalisée par l'intermédiaire du connect eur frontal permet de contrôler ou de surveiller les 
impulsions d'essai au moyen d'un testeur appropr ié. 
CPR_058  Il est possible de conf igurer cette ligne de signalisation d'entrée/sor tie par le biais d'une commande 
lancée sur la ligne K en recourant au service InputOutputControlByIdentifier pour sélectionner la 
fonction d'entrée ou de sortie requise pour la ligne considérée. Les états disponibles sur la ligne sont les 
suivants: 
—  désactivé; 
—  speedSignalInput, où la ligne de signalisation d'entrée/sor tie est utilisée pour entrer un signal de 
vitesse (signal d'essai) en rem placement du signal de vitess e du détecteur de mouvement ; cette 
fonction n'est pas disponible en mode CONTRÔLE, 
—  realTimeSpeedSignalOutputSensor , où la ligne de signalisation d'entrée/sor tie est utilisée pour la 
sortie du signal de vitesse du détecteur de mouvement ; 
—  RTC Output, où la ligne de signalisation d'entrée/sor tie d'étalonnag e est utilisée pour la sortie du 
signal de l'horloge UTC; cette fonction n'est pas disponible en mode CONTRÔLE. 
CPR_059  Pour être en mesure de configurer l'état de la ligne, il faut que l'unité embarquée sur véhicule soit 
entrée en session de réglage et qu'elle soit exploit ée en mode ÉTALONNA GE ou CONTRÔLE. Lorsque 
la VU est en mode ÉTALONNA GE, les quatre états de la ligne peuvent être sélectionnés (désactivé; 
speedSignalInput; realTimeSpeedSignalOutputSensor; RTC Output). Lorsque la VU est en mode 
CONTRÔLE, seuls deux états de lignes peuvent être sélectionnés (désactivé; realTimeSpeedOutput ­
Sensor). Lorsque l'opérateur décide de sortir du ÉTALONNA GE ou CONTRÔLE, l'unité embarquée sur 
véhicule doit s'assurer que la ligne de signalisation d'entrée/sor tie d'étalonnag e est revenue à son état de 
désactivation (par défaut). 26.5.2016 L 139/302 Jour nal officiel de l'Union européenne FR     
CPR_060  En cas de réception d'impulsions de vitess e sur la ligne d'entrée du signal de vitesse instantanée de la 
VU alors que la ligne de signalisation d'E/S est exploité e en mode entrée, cette ligne de signalisation 
passera en mode sortie ou sera ramenée à son état de désactivation. 
CPR_061  La séquence est: 
—  Établissement d'une liaison d'inter communication par le biais du service Star tCommunication. 
—  Entrée en session de réglage par le biais du service Star tDiagnosticSession et passage en mode 
d'exploitation ÉTALONNA GE ou CONTRÔLE (l'ordre d'exécution de ces deux opérations est sans 
impor tance). 
—  Modif ication de l'état de la sortie par le biais du service InputOutp utControlByIdentif ier. 
7.1.2  Structur e des messages 
CPR_062  La structure des messages associés aux primitives InputOut putControlByIdentif ier fait l'objet d'une 
descr iption détaillée dans les tableaux ci-après. 
Tableau 33 
Message InputOutputControlByIdentif ier Request 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible EE TGT 
#3 Octe t d'adresse de la source tt SRC 
#4 Octe t de longueur supplémentaire xx LEN 
#5 InputOutputControlByIdentif ier Request Sid 2F IOCBI 
#6 et #7 Input OutputIdentif ier = [CalibrationInputOutput] F960 IOI_CIO 
#8 ou 
#8 à #9 ControlOp tionRecord = [  COR_… 
inputOut putControlParamet er — une valeur ex­
trait e du Tableau 36 xx IOCP_… 
controlStat e — une valeur extraite du Tableau 37 
(cf. Note ci-dessous)] xx CS_… 
#9 ou 
#10 Total de contrôle 00-FF CS  
Note: le paramètre controlState n'apparaît que dans certains cas (cf. 7.1.3). 
Tableau 34 
Message InputOutputControlByIdentif ier Positiv e Response 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible tt TGT 26.5.2016 L 139/303 Jour nal officiel de l'Union européenne FR     
Octet # Nom de paramètre Valeur hex. Mnémonique 
#3 Octe t d'adresse de la source EE SRC 
#4 Octe t de longueur supplémentaire xx LEN 
#5 inputOutputControlByIdentif ier Positiv e Res ­
ponse SId 6F IOCBIPR 
#6 et #7 inputOut putIdentif ier = [CalibrationInputOutput] F960 IOI_CIO 
#8 ou 
#8 à #9 controlStatusRecord = [  CSR_ 
inputOut putControlParamet er (valeur identique à 
l'oct et #8 Tableau 33) xx IOCP_… 
controlStat e (valeur identique à l'oct et #9 Tableau 
33)] (le cas éché ant) xx CS_… 
#9 ou 
#10 Total de contrôle 00-FF CS  
Tableau 35 
Message InputOutputControlByIdentif ier Negativ e Response 
Octet # Nom de paramètre Valeur hex. Mnémonique 
#1 Octe t de structure — adressage physique 80 FMT 
#2 Octe t d'adresse de la cible tt TGT 
#3 Octe t d'adresse de la source EE SRC 
#4 Octe t de longueur supplémentaire 03 LEN 
#5 negativ eResponse Service Id 7F NR 
#6 inputOut putControlByIdentif ier Request SId 2F IOCBI 
#7 responseCode=[   
incor rectMessageL ength 13 RC_IML 
conditionsNotCor rect 22 RC_CNC 
requestOutOfRange 31 RC_R OOR 
deviceControlLimitsEx ceeded] 7A RC_DCLE 
#8 Total de contrôle 00-FF CS  
7.1.3  Définition du paramètre 
CPR_064  Le paramètre inputOutputControlP arame ter (IOCP_) est défini dans le tableau ci-après. 26.5.2016 L 139/304 Jour nal officiel de l'Union européenne FR     
Tableau 36 
Déf inition des valeurs inputOutputControlParameter 
Hex. Descr iption Mnémo ­
nique 
00 Retur nControlT oECU 
Cette valeur doit indiquer au serveur (VU) que l'appareil d'essai ne 
commande plus la ligne de signalisation d'E/S. RCTECU 
01 ResetT oDefault 
Cette valeur doit indiquer au serveur (VU) qu'il est tenu de ramener à son 
état initial la ligne de signalisation E/S. RTD 
03 Shor tTermAdjustment 
Cette valeur doit indiquer au serveur (VU) qu'il est tenu de régler la ligne 
de signalisation E/S en lui attribuant la valeur incluse dans le paramètre 
controlStat e. STA  
CPR_065  Le paramètre controlSta te n'apparaît que lorsque le inputOutputCon trolParamet er est conf iguré 
comme Shor tTermAdjustment et défini dans le tableau ci-après: 
Tableau 37 
Déf inition des valeurs controlSt ate 
Mode Valeur hex. Descr iption 
Désactivé 00 Ligne d'E/S désactivée (par défaut) 
Activé 01 Active la ligne E/S d'étalonnag e comme speedSignalInput 
Activé 02 Active la ligne E/S d'étalonnage comme realTimeSpeedSignalOut ­
putSensor 
Activé 03 Active la ligne E/S d'étalonnag e comme RTCOutput  
8.  STR UCTURES DES DATARECORDS 
Le présent chapitre expose en détail: 
—  les règles générales applicables aux gam mes de paramètres transmises par l'unité embarquée sur le véhicule à 
l'appareil d'essai, 
—  les structures qui sont utilisées pour les données transférées par l'inte rmédiaire des services de transmission de 
données à la section 6. 
CPR_067  Tous les paramètres indiqués sont pris en charge par la VU. 
CPR_068  Les données transmises par la VU à l'appareil d'essai en réponse à une demande sont du type mesurées 
(c.-à-d. la valeur actuelle du paramètre demandé telle que mesurée ou obser vée par la VU). 
8.1.  Gammes des paramètres transmis 
CPR_069  Le Tableau 38 définit les gammes utilisées pour déterminer la validité d'un paramètre transmis. 26.5.2016 L 139/305 Jour nal officiel de l'Union européenne FR     
CPR_070  Les valeurs de la gam me «indicat eur d'erreur» permettent à l'unit é embarquée sur le véhicule d'indiquer 
immédiate ment qu'aucune donnée paramétr ique valable n'est actuellement disponible en raison d'une 
erreur quelconque au niveau du tach ygraphe. 
CPR_071  Les valeurs de la gamme «non disponible» permett ent à l'unit é embarquée sur le véhicule de transmettre 
un messag e cont enant un paramètre non disponible ou non pris en charge dans le module en cause. 
Les valeurs de la gamme «non demandé» permettent la transmission d'un message de commande et 
identifient les paramètres pour lesquels le récep teur n'att end pas de réponse. 
CPR_072  Lorsque la défaillance d'un composant empêche la transmission de données valables pour un 
paramètre, il convie nt d'utiliser l'indicat eur d'erreur décr it au Tableau 38 à la place des données de ce 
paramètre. Toutef ois, si les données mesurées ou calculées donnent une valeur valable, mais qui se 
situe en dehors de la gamme fixée pour ce paramètre, l'indicateur d'erreur ne devrait pas être utilisé. Il 
convi ent dans ce cas de transmettre les données en utilisant la valeur paramétr ique minimale ou 
maximale appropr iée. 
Tableau 38 
Plages de dataRecords 
Nom de la gamm e 1 octet 
(valeur hex.) 2 octets 
(valeur hex.) 4 octets 
(Hex Value) ASCII 
Signal valable 00 à FA 0000 à FAFF 00000000 à FAFFFFFF 1 à 254 
Indicateur propre au paramètre FB FB00 à FBFF FB000000 à FBFFFFFF aucun 
Gamme réser vée aux futurs bits 
de l'indicate ur FC à FD FC00 à FDFF FC000000 à FDFFFFFF aucun 
Indicateur d'erreur FE FE00 à FEFF FE000000 à FEFFFFFF 0 
Non disponible ou non de­
mandé FF FF00 à FFFF FF000000 à FFFFFFFF FF  
CPR_073  Pour les paramètres encodés en ASCII, le caractère ASCII «*» est réser vé comme délimiteur . 
8.2.  Structures des dataRecords 
Les Tableaux 39 à 42 ci-après exposent en détail les structures à utiliser par l'intermédiaire des services ReadData ­
ByIdentifier et WriteDataByIdentifi er. 
CPR_074  Le Tableau 39 indique la longueur , la résolution et la gamme opérationnelle de chaque paramètre 
identifié par son recordDataIdentifier : 
Tableau 39 
Structure des dataRecords 
Nom de paramètre Longueur 
des données 
(en octets) Résolution Gamme opérationnelle 
TimeDat e 8 Cf. détails au Tableau 40 
HighResolution TotalV ehicleDistance 4 gain 5 m/bit, décalage 0 m 0 à + 21 055 406 km 
Kfact or 2 gain 0,001 impulsion/m/bit, déca ­
lage 0 0 à 64,255 impulsion/m 
LfactorT yreCircumfe rence 2 gain 0,125 10– 3 m/bit, décalage 0 0 à 8,031 m 
WvehicleCharacter isticF actor 2 gain 0,001 impulsion/m/bit, déca ­
lage 0 0 à 64,255 impulsion/m 
TyreSize 15 ASCII ASCII 26.5.2016 L 139/306 Jour nal officiel de l'Union européenne FR     
Nom de paramètre Longueur 
des données 
(en octets) Résolution Gamme opérationnelle 
NextCalibrationDat e 3 Cf. détails au Tableau 41 
SpeedAuthor ised 2 gain 1/256 km/h/bit, décalage 0 0 à 250,996 km/h 
Regist eringMemberState 3 ASCII ASCII 
VehicleRegistrationNumber 14 Cf. détails au Tableau 42 
VIN 17 ASCII ASCII  
CPR_075  Le Tableau 40 expose en détail les structures des différ ents octets du paramètre TimeDat e: 
Tableau 40 
Structure détai llée de TimeDate (valeur de recordData Identif ier # F90B) 
Octet Défini tion du paramètre Résolution Gamme opération ­
nelle 
1 Secondes gain 0,25 s/bit, décalage 0 s 0 à 59,75 s 
2 Minute s gain 1 min/bit, décalage – 125 min 0 à 59 min 
3 Heures gain 1 h/bit, décalage 0 h 0 à 23 h 
4 Mois gain 1 mois/bit, décalage 0 mois 1 à 12 mois 
5 Jour gain 0,25 jour/bit, décalage 0 jour 
(voir la note ci-après au Tableau 41) 0,25 à 31,75 jours 
6 Année gain 1 année/bit, décalage année 
+ 1985 
(voir note ci-dessous au Tableau 41) années 1985 à 
2235 
7 Correction locale des 
minut es gain 1 min/bit, décalage – 125 min – 59 à + 59 min 
8 Correction locale des 
heures gain 1 h/bit, décalage – 125 h – 23 à + 23 h  
CPR_076  Le Tableau 41 expose en détail la structure des différents octets du paramètre NextCalibrationDat e. 
Tableau 41 
Structure déta illée de NextCalibrationDate (valeur de recordDataI dentif ier # F922) 
Octet Défini tion du paramètre Résolution Gamme opération ­
nelle 
1 Mois gain 1 mois/bit, décalage 0 mois 1 à 12 mois 
2 Jour gain 0,25 jour/bit, décalage 0 jour 
(voir la note ci-après) 0,25 à 31,75 jours 
3 Année gain 1 année/bit, décalage année 
+ 1985 
(voir note ci-dessous) années 1985 à 
2235  26.5.2016 L 139/307 Jour nal officiel de l'Union européenne FR     
Note concer nant l'utilisation du paramètre «Jour»:  
1) Une valeur de 0 pour la date est nulle. Les valeurs 1, 2, 3 et 4 servent à identif ier le premier jour du mois; 5, 
6, 7 et 8 identifient le deuxième jour du mois, etc.  
2) Ce paramètre n'inf luence pas ni ne modifie le paramètre des heures précité. 
Note concer nant l'utilisation de l'octet du paramètre «Année»: 
Une valeur ‘0’ pour l'année identif ie l'année 1985; une valeur ‘1’ identif ie 1986, etc 
CPR_078 Le Tableau 42 expose en détail la structure des différents octets du paramètre VehicleRegistration ­
Number: 
Tableau 42 
Structure déta illée du VehicleRegistration Number (valeur recordData Identif ier # F97E) 
Octet Définition du paramètre Résolution Gamme opéra ­
tionnelle 
1 Page de code (telle que définie à l'appendice 1) ASCII 01 à 0A 
2 à 14 Numéro d'immatr iculation du véhicule (tel que dé­
fini à l'appendice 1) ASCII ASCII   26.5.2016 L 139/308 Jour nal officiel de l'Union européenne FR     
Appendice 9 
HOMOLOGA TION ET LISTE DES ESSAIS MINIMA UX REQUIS 
TABLE DES MATIÈRES 
1. INTR ODUCTION ..................................................................................................................................... 309 
2. ESSAIS FONCTIONNELS DE L'UNITÉ EMBARQ UÉE SUR LE VÉHICULE ................................................................. 311 
3. ESSAIS DE FONCTIONNEMENT DU CAPTEUR DE MOUVEMENT ........................................................................ 315 
4. ESSAIS DE FONCTIONNEMENT DES CARTES TACHY GRAPHIQUES .................................................................... 318 
5. ESSAIS DU DISPOSITIF GNSS EXTERNE ........................................................................................................ 328 
6. ESSAIS DES ÉQUIPEMENTS DE COMMUNICA TION À DIST ANCE ....................................................................... 331 
7. ESSAIS FONCTIONNELS SUR LE PAPIER ....................................................................................................... 333 
8. ESSAIS D'INTER OPÉRABILITÉ ..................................................................................................................... 335  
1.  INTR ODUCTION 
1.1.  Homologation 
L'homolog ation CE destiné à un équipement (ou un compo sant) de contrôle ou à une carte tach ygraphique repose 
sur: 
—  une certification de sécur ité basée sur des spécifications de critères communs contre une cible de sécur ité 
parfaitement conf orme à l'appendice 10 de la présent e annexe (à compl éter ou à modifier), 
—  une certification de fonctionnement exécut ée par les autori tés compét entes d'un État membre certifia nt que 
l'élément testé satisfa it aux exigences de la présente annexe sur le plan des fonctions exécut ées, de la précision 
des mesures et des caracté ristiques environnementales, 
—  une certification d'interopérabilité exécut ée par l'orga nisme compét ent chargé de certifier l'interopérabilité de 
l'appareil de contrôle (ou la carte tach ygraphique) visé avec la carte tach ygraphique (ou l'appareil de contrôle) 
indispensable (cf. chapitre 8 de la présent e annexe ). 
Le présent appendice précise les tests minimaux que les autori tés compét entes d'un État membre doivent effectuer 
dans le cadre des essais de fonctionnement ainsi que les tests minimaux que l'organ isme compét ent doit effectuer 
dans le cadre des essais d'interopérabilit é. Ni les procédures d'exécution de ces essais ni leur type ne font l'objet 
d'explications plus détaillées. 
Le présent appendice ne traite pas des diffé rents aspects de la certificat ion de sécur ité. Si certains essais d'homolo ­
gation sont effectués pendant le processus d'évaluation et de certificat ion de la sécur ité, ils n'ont pas à être répété s. 
En pareil cas, seuls les résultats de ces essais de sécur ité sont susceptibles d'être contrôlés. À titre d'inf ormation, les 
exige nces qui doivent faire l'objet d'essais (ou sont étroitem ent liées aux essais qu'il y a lieu d'exécut er) pendant la 
certification de sécur ité sont repérées par un astérisque («*») dans le présent appendice. 
Les exigenc es numéroté es font référence au corpus de l'annexe. Les autres exige nces font référen ce aux autres 
appendices (p. ex. PIC_001 fait référence à l'exige nce PIC_001 de l'appendice 3 Pictogrammes). 
Le présent appendice traite séparément de l'homolog ation du détect eur de mouvement, de celle de l'unité 
embarquée sur le véhicule et du dispositif GNSS externe, respectivement considérés comme des compo sants 
distincts de l'appareil de contrôle. Chaque compo sant obtient son propre certificat d'homologation qui dresse la 
liste des autres compo sants compatibles. L'essai fonctionnel du capt eur de mouvement (ou du dispositif GNSS 
exte rne) est effectué simultanément à celui de l'unit é embarquée sur le véhicule et vice versa. 
L'int eropérabilité entre les modèles de capt eurs de mouvement (ou les dispositifs GNSS extern es) et chaque modèle 
d'unité embarquée sur le véhicule n'est pas requise. Dans ce cas l'homolog ation d'un capt eur de mouvement (ou des 
dispositifs GNSS externes) peut être attribuée en association avec l'homolog ation de l'unité embarquée sur véhicule 
et vice versa. 26.5.2016 L 139/309 Jour nal officiel de l'Union européenne FR     
1.2.  Références 
Le présent appendice fait référence aux documents suivants: 
IEC 60068-2-1: Essais d'en vironnement — Partie 2-1: Essais — Essai A: Froid 
IEC 60068-2-2: Procédures de base pour les essais d'en vironnement ; partie 2: essais; essai B: chaleur sèche 
(sinusoïdal). 
IEC 60068-2-6: Essais d'en vironnement — Partie 2: Essais — Essai Fc: Vibrations (sinusoïdales) 
IEC 60068-2-14: Essais d'en vironnement ; Partie 2-14: Essais; Essai N: Variation de température 
IEC 60068-2-27: Essais d'en vironnement. Part 2: Essais. Essai Ea et guide: Chocs 
IEC 60068-2-30: Essais d'en vironnement — Partie 2-30: Essais — Essai Db: Essai cyclique de chaleur humide (cycle 
de 12 h + 12 h) 
IEC 60068-2-64: Essais d'environnement — Partie 2-64: Essais — Essai Fh: Vibrations aléatoires à large bande et 
guide 
IEC 60068-2-78 Essais d'environnement — Part 2-78: Essais — Essai Cab: Chaleur humide, essai continu 
ISO 16750-3 —Contraintes mécaniques (2012-12) 
ISO 16750-4 —Contraintes climatiques (2010-04). 
ISO 20653: Véhicules routiers — Degrés de prote ction (codes IP) — Prote ction des équipements électr iques contre 
les corps étrangers , l'eau et les contacts 
ISO 10605:2008 + Rectifi catif technique: 2010 + AMD1:2014 Véhicules routiers — Méthodes d'essai des pertur­
bations électr iques provenant de décharges électrostatiques 
ISO 7637-1:2002 + AMD1: 2008 Véhicules routiers — Perturbations électr iques par conduction et par couplage 
— Partie 1: Défi nitions et généralit és 
ISO 7637-2 Véhicules routiers — Perturbations électr iques par conduction et par couplage — Partie 2: Pertur­
bations électr iques transito ires par conduction uniquement le long des lignes d'alimentation. 
ISO 7637-3 Véhicules routiers — Perturbations électr iques par conduction et par couplage — Partie 3: 
Transmission des perturbations électr iques par couplage capacitif ou inductif le long des lignes autres que les lignes 
d'alimentation. 
ISO/IEC 7816-1 Cartes d'identif ication — Cartes à circuit intégré — Partie 1: Cartes à contacts — Caractéristi ques 
physiques. 
ISO/IEC 7816-2 Cartes d'identification — Cartes à circuit intégré — Partie 2: Dimensions et emplacements des 
contacts. 
ISO/IEC 7816-3 Cartes d'identif ication — Cartes à circuit intégré — Partie 3: Interface électr ique et protocoles de 
transmission. 
ISO/IEC 10373-1:2006 + AMD1:2012 ICar tes d'identif ication — Méthodes d'essai — Partie 1: Caractéri stiques 
générales 
ISO/IEC 10373-3:2010 + Rectificatif technique:2013 ICar tes d'identif ication — Méthodes d'essai — Partie 3: Cartes 
à circuit(s) intégré (s) à contacts et dispositifs d'interfa ce assimilés 
ISO 16844-3:2004, Cor 1:2006 Véhicules routiers — Systèmes tach ygraphes — Partie 3: Interfa ce de capt eur de 
mouvement (avec les unités embarquées sur le véhicule). 
ISO 16844-4 Véhicules routiers — Systèmes tach ygraphes — Partie 4: Interface CAN 
ISO 16844-6 Véhicules routiers — Systèmes tach ygraphes — Partie 6: Diagnostic 26.5.2016 L 139/310 Jour nal officiel de l'Union européenne FR     
ISO 16844-7 Véhicules routiers — Systèmes tach ygraphes — Partie 7: Paramè tres 
ISO 534 Papier et carton – Détermination de l'épaisseur , de la masse volumique et du volume spécifique 
UN ECE R10 Prescr iptions unif ormes relatives à l'homologation des véhicules en ce qui concer ne la compati bilité 
électromagnétique (Commission économique pour l'Europe des Nations unies) 
2.  ESSAIS FONCTIONNELS DE L'UNITÉ EMBARQUÉE SUR LE VÉHICULE 
No Essai Descr iption Exigences connexes 
1 Exa men administ ratif 
1.1 Documentation Exactitude de la documentation  
1.2 Résultats des es­
sais du fabr icant Résultats des essais menés par le fabricant pendant la phase 
d'intégration. 
Démonstrations sur papier . 88, 89,91 
2 Inspection visuelle 
2.1 Conf ormité avec la documentation  
2.2 Identif ication/marquag e 224 à 226 
2.3 Matériaux 219 à 223 
2.4 Scellements 398, 401 à 405 
2.5 Interfa ces externes  
3 Essais de fonctionnement 
3.1 Fonctions prévues 03, 04, 05, 07, 382, 
3.2 Modes d'exploitation 09 à 11*, 132, 133 
3.3 Droits d'accès aux fonctions et données 12* 13*, 382, 383, 386 
à 389 
3.4 Surveillance de l'inser tion et du retrait des cartes 15, 16, 17, 18, 19*, 
20*, 132 
3.5 Mesure de la vites se et de la distance 21 à 31 
3.6 Chronométrage (essai exécut é à 20 °C) 38 à 43 
3.7 Surveillance des activité s du conduct eur 44 à 53, 132 
3.8 Surveillance de l'état de conduit e 54, 55, 132 26.5.2016 L 139/311 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes 
3.9 Entrées manuelles 56 à 62 
3.10 Gestion des dispositifs de verrouillage de l'entrepr ise 63 à 68 
3.11 Suivi des activités de contrôle 69, 70 
3.12 Détection d'événements et/ou d'anomalies 71 à 88 132 
3.13 Données d'identification des équipements 93*, 94*, 97, 100 
3.14 Données d'inser tion et de retrait de la carte du conduct eur 102* à 104* 
3.15 Données relatives aux activités du conduct eur 105* à 107* 
3.16 Données relatives aux lieux et aux emplacements 108* à 112* 
3.17 Données relatives aux kilométrages 113* à 115* 
3.18 Données détaillées relatives à la vitesse 116* 
3.19 Données relatives aux événements 117* 
3.20 Données relatives aux anomalies 118* 
3.21 Données d'étalonnag e 119* à 121* 
3.22 Données de réglage de l'heure 124*, 125* 
3.23 Données relatives aux activités de contrôle 126*, 127* 
3.24 Données relatives aux dispositifs de verrouillage de l'entrepr ise 128* 
3.25 Téléc hargement de données relatives aux activités 129* 
3.26 Données relatives aux conditions particulières 130*, 131* 
3.27 Enregistrement et mémor isation sur les cartes tach ygraphiques 134, 135,, 136*, 137*, 
139*, 140, 141 
142, 143, 144*, 145*, 
146*, 147, 148 
3.28 Affichage 90, 132, 
149 à 166, 
PIC_001, DIS_001 
3.29 Imp ression 90, 132, 167 à 179, 
PIC_001, PRT_001 à 
PRT_014 
3.30 Avertissement 132, 180 à 189, 
PIC_001 26.5.2016 L 139/312 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes 
3.31 Téléc hargement de données à destination de suppor ts externes 90, 132, 190 à 194 
3.32 Communication à distance pour les contrôles routiers ciblés 195 à 197 
3.33 Données de sortie à destination de dispositifs externes supplémentaires 198, 199 
3.34 Étalonnag e 202 à 206*, 383, 384, 
386 à 391 
3.35 Contrôles routiers d'étalonnag e 207 à 209 
3.36 Réglage de l'heure 210 à 212* 
3.37 Absence d'interfé rence des fonctions supplémentaires 06, 425 
3.38 Interfa ce des capt eurs de mouvement 02, 122 
3.39 Dispositif GNSS extern e 03, 123 
3.40 Vérifier que la VU détec te, enregistre et stoc ke les événements et/ou anomalies 
défini(e)s par le fabricant de la VU lorsqu'un capt eur de mouvement couplé réa­
git à des champs magnétiques qui perturbent la détection des mouvements du 
véhicule. 217 
3.41 Suit e de chiffrement et paramètres de domaines normalisés CSM_48, CSM_50 
4 Essais environnement aux 
4.1 Temp érature S'assurer de la fonctionnalit é en exécutant les essais sui­
vants: 
Essai conf orme à la norme ISO 16750-4, Chapitre 5.1.1.2: 
Essai d'exploitation à basse température (72 h @ – 20 °C) 
Cet essai satisfait à la norme CEI 60068-2-1: Essais d'envi ­
ronnement — Partie 2-1: essais — essai A: froid 
Essai conf orme à la norme ISO 16750-4: Chapitre 5.1.2.2: 
Essai d'exploitation à haute température (72 h à 70 °C) 
Cet essai satisfait à la norme CEI 60068-2-2: Procédures 
d'essai environnemental de base; partie 2: essais; essais B: 
chaleur sèche 
Essai conf orme à la norme ISO 16750-4: Chapitre 5.3.2: 
Variation rapide de température avec durée de transition 
spécifi ée (– 20 °C/70 °C, 20 cycles, temps de maintien de 
2h à chaque température). 
Il est possible de se livrer à un nombre limité d'essais 
(par mi ceux définis à la section 3 de ce tableau) aux tempé­
ratures minimale et maximale indiquées ainsi que pendant 
les cycles de variation de la température. 213 26.5.2016 L 139/313 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes 
4.2 Humidité S'assurer que l'unit é embarquée sur le véhicule est capable 
de résister à un cycle de chaleur humide (essai de résistance 
à la chaleur) en exécutant l'essai CEI 60068-2-30, essai Db, 
compo rtant six cycles de 24 heures, la température variant 
de + 25 °C à + 55 °C et le taux d'humidit é relative attei­
gnant 97 % à + 25 °C et 93 % à + 55 °C. 214 
4.3 Mécanique 1.  Vibrations sinusoïdales. 
S'assurer que l'unité embarquée sur le véhicule est ca­
pable de résist er à des vibrations sinusoïdales possédant 
les caractér istiques suivantes: 
déplacement constant compris entre 5 et 11 Hz: 
10 mm max; 
accélération constant e compris e entre 11 et 300 Hz: 5 g 
L'essai CEI 60068-2-6, essai Fc, permet de vérifier la sa­
tisfa ction de cette exige nce. La durée minimale de cet es­
sai s'élève à 3 × 12 heures (12 heures par essieu). 
La norme ISO 16750-3 n'im pose pas d'essai de vibra ­
tions sinusoïdales aux dispositifs situés dans la cabine 
découplée du véhicule. 
2.  Vibrations aléatoires: 
Essai conf orme à la norme ISO 16750-3: Chapitre 
4.1.2.8: Essai VIII: Véhicule commercial, cabine de véhi ­
cule découplée. 
Essai de vibrations aléatoi res, 10…2 000 Hz, RMS verti­
cal 21,3 m/s2, RMS longitudinal 11,8 m/s2, RMS latéral 
13,1 m/s2, 3 essieux, 32 h par essieu, y compris un cy­
cle de température – 20…70 °C. 
Cet essai satisfait à la norme CEI 60068-2-64: Essais 
d'en vironnement — Partie 2-64: essais — essai Fh: vi­
brations aléatoi res à large bande et guide 
3.  Chocs: 
choc mécanique d'un demi-sinus de 3 g conf ormément 
à la norme ISO 16750. 
Il convient d'exécut er les essais décr its ci-avant sur des 
échantillon s distincts du type d'équipement testé. 219 
4.4 Protection contre 
l'eau et les corps 
étrangers Essai conf orme à la norme ISO 20653: Véhicules routiers 
— Degrés de prote ction (codes IP) — Prote ction des équi ­
pements électr iques contre les corps étrangers, l'eau et les 
contacts (paramètres inchan gés); valeur minimale IP 40 220, 221 
4.5 Protection contre 
les surtensions S'assurer que l'unit é embarquée sur le véhicule est capable 
de suppor ter une tension d'alimentation de: 216 
versions 24 V: 34 V à + 40 °C 1 heure 
versions 12 V: 17 V à + 40 °C 1 heure 
(ISO 16750-2)  
4.6 Protection contre 
les inversions de 
polar ité S'assurer que l'unit é embarquée sur le véhicule est capable 
de suppor ter une inve rsion de polar ité au niveau de son ali­
mentation électr ique 
(ISO 16750-2) 216 26.5.2016 L 139/314 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes 
4.7 Protection contre 
les cour ts-circuits S'assurer que les signaux d'entrée et de sortie sont protég és 
contre les cour ts-circuits à l'alimentation électr ique et à la 
terre 
(ISO 16750-2) 216 
5 Essais de compatibilité électromagnétique 
5.1 Émissions rayon­
nées et sensibilit é Conf ormité avec le règlement CEE R10 218 
5.2 Déch arge électro ­
statique Conf ormité avec la norme ISO 10605:2008 + Rectif icatif 
technique:2010 + AMD1:2014: +/– 4 kV pour le contact et 
+/– 8 kV pour la décharg e d'air 218 
5.3 Suscept ibilité 
transito ire par 
conduction au ni­
veau de l'alimen ­
tation Pour les versions 24 V: conf ormité avec la norme ISO 
7637-2 + Règlement CEE no 10 Rév. 3: 
impulsion 1a: Vs = – 450 V Ri = 50 ohms 
impulsion 2a: Vs = + 37 V Ri = 2 ohms 
impulsion 2b: Vs = + 20 V Ri = 0,05 ohms 
impulsion 3a: Vs = – 150 V Ri = 50 ohms 
impulsion 3b: Vs = + 150 V Ri = 50 ohms 
impulsion 4: Vs = – 16 V Va = – 12 V t6 = 100 ms 
impulsion 5: Vs = + 120 V, Ri = 2,2 ohms, td = 250 ms 
Pour les versions 12 V: conf ormité avec la norme ISO 
7637-1 + Règlement CEE no 10 Rév. 3: 
impulsion 1: Vs = – 75 V Ri = 10 ohms 
impulsion 2a: Vs = + 37 V Ri = 2 ohms 
impulsion 2b: Vs = + 10 V Ri = 0,05 ohms 
impulsion 3a: Vs = – 112 V Ri = 50 ohms 
impulsion 3b: Vs = + 75 V Ri = 50 ohms 
impulsion 4: Vs = – 6 V Va = -5 V t6 = 15 ms 
impulsion 5: Vs = + 65 V, Ri = 3 ohms, td = 100 ms 
L'im pulsion 5 ne sera testée que pour les unités à installer 
sur des véhicules dépour vus de dispositif commun de pro­
tectio n exte rne contre la perte de charge. 
Pour la proposition concer nant la perte de charg e, consul ­
ter la norme ISO 16750-2, 4e édition, chapitre 4.6.4. 218  
3.  ESSAIS DE FONCTIONNEMENT DU CAPTEUR DE MOUVEMENT 
No Essai Descr iption Exigences connexes 
1. Exa men administ ratif 
1.1 Documentation Exactitude de la documentation  26.5.2016 L 139/315 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes 
2. Inspection visuelle 
2.1. Conf ormité avec la documentation  
2.2. Identif ication/marquag e 225, 226, 
2.3 Matériaux 219 à 223 
2.4. Scellements 398, 401 à 405 
3. Essais de fonctionnement 
3.1 Données d'identification du capt eur 95 à 97* 
3.2 Appar iement capt eur de mouvement — unité embarquée sur véhicule 122*, 204 
3.3 Détection de mouvement 
Exactitude de la mesure du mouvement 30 à 35 
3.4 Interfa ce d'unité embarquée sur le véhicule 02 
3.5 Vérifier que le capt eur de mouvement est immunisé contre les champs magnéti ­
ques constants. Autrement, vérifier que le capt eur de mouvement réagit aux 
champs magnétiques constants qui perturbent la détection des mouvements du 
véhicule, de sorte qu'une VU connectée puisse détect er, enregistrer et stoc ker les 
anomalies du capt eur 217 
4. Essais environnement aux 
4.1 Temp érature d'ex ­
ploitation S'assurer de la fonctionnalit é de ce composant (telle qu'elle 
est définie dans le test no 3.3) pour la plag e de températures 
[– 40 °C + 135 °C] en exécutant les essais suivants: 
CEI 60068-2-1 essai Ad, en appliquant une durée d'essai de 
96 heures à la température minimale Tomin 
CEI 60068-2-2 essai Bd, en appliquant une durée d'essai de 
96 heures à la température maximale Tomax 
Essai conf orme à la norme ISO 16750-4: Chapitre 5.1.1.2: 
Essai d'exploitation à basse température (24 h @ – 40 °C) 
Cet essai satisfait à la norme CEI 60068-2-1: Essais d'envi ­
ronnement — Partie 2-1: essais — essai A: CEI 68-2-2 essai 
froid Bd, en appliquant une durée d'essai de 96 heures à la 
température minimale de – 40 °C. 
Essai conf orme à la norme ISO 16750-4: Chapitre 5.1.2.2: 
Essai d'exploitation à haute température (96 h @ 135 °C) 
Cet essai satisfait à la norme CEI 60068-2-2: Procédures 
d'essai environnemental de base; partie 2: essais; essais B: 
chaleur sèche 213 26.5.2016 L 139/316 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes 
4.2 Cycles de tempé­
rature Essai conf orme à la norme ISO 16750-4: Chapitre 5.3.2: 
Variation rapide de température avec durée de transition 
spécifi ée (– 40 °C/135 °C, 20 cycles, temps de maintien de 
30 minutes à chaque température) 
IEC 60068-2-14: Essais d'environnement — Partie 2-14: es­
sais — essai N: change ment de température 213 
4.3 Cycles humides S'assurer de la fonctionnalit é de ce composant (telle qu'elle 
est définie dans le test no 3.3) en exécutant l'essai CEI 
60068-2-30, essai Db, compo rtant six cycles de 24 heures, 
la température variant de + 25 °C à + 55 °C et le taux d'hu ­
midité relative atteignant 97 % à + 25 °C et 93 % à + 55 °C 214 
4.4 vibrations ISO 16750-3: Chapitre 4.1.2.6: Essai VI: Véhicule commer ­
cial, moteur , engrenage 
Essai de vibration en mode mixt e compre nant 
a)  un essai de vibrations sinusoïdales, 20...520 Hz, 11.4 … 
120 m/s2, <= 0,5 oct/min 
b)  un essai de vibrations aléat oires, 10...2 000 Hz, RMS 
177 m/s2 
94 h par essieu, avec un cycle de température – 20…70 °C) 
Cet essai satisfait à la norme CEI 60068-2-80: Essais d'envi ­
ronnement — Partie 2-80: Essais — Essai Fi: Vibrations — 
Mode mixte 219 
4.5 Chocs mécani ­
ques ISO 16750-3: Chapitre 4.2.3: Essai VI: Essai pour disposi ­
tifs dans ou sur l'engrenage 
Choc demi-sinusoïdal, accélération à conven ir dans la plage 
entre 3 000…15 000 m/s2, durées de l'impulsi on à conve ­
nir, cependant < 1 ms, nombre de chocs: à convenir 
Cet essai satisfait à la norme CEI 60068-2-27: Essais d'envi ­
ronnement. Partie 2: Essais. Essai Ea et guide: Chocs 219 
4.6 Protection contre 
l'eau et les corps 
étrangers Essai conf orme à la norme ISO 20653: Véhicules routiers 
— Degrés de prot ection (code IP) — Protection des équipe ­
ments électr iques contre les corps étrangers, l'eau et les 
contacts 
(Valeur cible IP 64) 220, 221 
4.7 Protection contre 
les inversions de 
polar ité S'assurer que le détec teur de mouvement est capable de 
suppor ter une inversion de polar ité au niveau de son ali­
mentation électr ique 216 
4.8 Protection contre 
les cour ts-circuits S'assurer que les signaux d'entrée et de sortie sont protég és 
contre les cour ts-circuits à l'alimentation électr ique et à la 
terre 216 26.5.2016 L 139/317 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes 
5. Essais de compatibilité électromagnétique 
5.1 Émissions rayon­
nées et sensibilit é Contrôler la conf ormité avec le règlement CEE R10 218 
5.2 Déch arge électro ­
statique Conf ormité avec la norme ISO 10605:2008 + Rectif icatif 
technique:2010 + AMD1:2014: +/– 4 kV pour le contact et 
+/– 8 kV pour la décharg e d'air 218 
5.3 Suscept ibilité 
transito ire par 
conduction au ni­
veau des lignes 
de transmission 
de données Pour les versions 24 V: conf ormité avec la norme ISO 
7637-2 + Règlement CEE no 10 Rév. 3: 
impulsion 1a: Vs = – 450 V Ri = 50 ohms 
impulsion 2a: Vs = + 37 V Ri = 2 ohms 
impulsion 2b: Vs = + 20 V Ri = 0,05 ohms 
impulsion 3a: Vs = – 150 V Ri = 50 ohms 
impulsion 3b: Vs = + 150 V Ri = 50 ohms 
impulsion 4: Vs = – 16 V Va = – 12 V t6 = 100 ms 
impulsion 5: Vs = + 120 V, Ri = 2,2 ohms, td = 250 ms 
Pour les versions 12 V: conf ormité avec la norme ISO 
7637-1 + Règlement CEE no 10 Rév. 3: 
impulsion 1: Vs = – 75 V Ri = 10 ohms 
impulsion 2a: Vs = + 37 V Ri = 2 ohms 
impulsion 2b: Vs = + 10 V Ri = 0,05 ohms 
impulsion 3a: Vs = – 112 V Ri = 50 ohms 
impulsion 3b: Vs = + 75 V Ri = 50 ohms 
impulsion 4: Vs = – 6 V Va = -5 V t6 = 15 ms 
impulsion 5: Vs = + 65 V, Ri = 3 ohms, td = 100 ms 
L'im pulsion 5 ne sera testée que pour les unités à installer 
sur des véhicules dépour vus de dispositif commun de pro­
tectio n exte rne contre la perte de charge. 
Pour la proposition concer nant la perte de charg e, consul ­
ter la norme ISO 16750-2, 4e édition, chapitre 4.6.4 218  
4.  ESSAIS DE FONCTIONNEMENT DES CARTES TACHY GRAPHIQUES 
Essais conf ormes à la présente Section 4, 
no 5 «Essais de protocole», 
no 6 «Structure de la carte» et 
no 7 «Essais de fonctionnement» 
peuvent être effectués par l'évaluate ur ou le certificateur pendant la procédure de certificat ion de la sécur ité Critères 
communs (CC) du module avec circuit. 
Les essais numéros 2.3 et 4.2 sont identiques. Il s'agit des essais mécaniques de la combinaison incluant le corps de 
la carte et le module du circuit. En cas de modific ation de l'un de ces compo sants (cor ps de la carte ou module du 
circuit), les essais deviennent nécessaires. 26.5.2016 L 139/318 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes 
1. Exa men administ ratif 
1.1 Documentation Exactitude de la documentation  
2 Cor ps de la carte 
2.1 Conceptio n im­
primée S'assurer de la conf ormité et de la qualité d'im pression de 
tout es les fonctions de protection et données visibles. 
[Indicatif] 
Annex e 1C, chapitre 4.1 «Données visibles», 227) 
La première page doit compo rter: 
les mots «car te de conduct eur» ou «car te de contrôleur» 
ou «car te d'ate lier» ou «car te d'entrepr ise» impr imés en 
majuscules dans la ou les langue(s) officielle(s) de l'État 
membre qui a délivré la carte, selon le type de carte. 
[nom de l'État membre] 
Annex e 1C, chapitre 4.1 «Données visibles», 228) 
La première page doit compo rter: 
le nom de l'État membre qui a délivré la carte (facultatif). 
[Signature] 
Annex e 1C, chapitre 4.1 «Données visibles», 229) 
La première page doit compo rter: 
le signe distinctif de l'État membre qui a délivré la carte, 
imprimé en négat if dans un rectang le bleu et entouré de 
12 étoiles jaunes. 
[Énumération] 
Annex e 1C, chapitre 4.1 «Données visibles», 232 
Le verso doit compo rter: 
une légende des numéros indiqués au recto. 
[Couleur] 
Annex e 1C, chapitre 4.1 «Données visibles», 234) 
Les cartes tach ygraphiques doivent être imprimées sur 
les fonds de couleur suivants: 
—  carte du conducteur: blanche, 
—  carte d'ateli er: roug e, 
—  carte de contrôle: bleu, 
—  carte d'entrepr ise: jaune.  227 à 229*, 232, 234 
à 236 26.5.2016 L 139/319 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes  
[Sécur ité] 
Annex e 1C, chapitre 4.1 «Données visibles», 235) 
Les cartes tach ygraphiques présent ent au minimum les 
éléments de prote ction suivants contre la contref açon et 
la manipulation du corps de la carte: 
—  impression de fond de sécur ité finement guillochée et 
irisée, 
—  au moins une ligne bicolore micro-impri mée. 
[Marquage ] 
Annex e 1C, chapitre 4.1 «Données visibles», 236 
Les États membres ajout ent des couleurs ou des marqua ­
ges, comme des symboles nationaux et des caracté risti­
ques de sécur ité. 
[Marque d'homologation] 
Les cartes tach ygraphiques contiennent une marque d'ho ­
mologa tion. 
La marque d'homologation est compo sée: 
—  d'un rectang le à l'inté rieur duquel est placée la lettre 
«e» minuscule suivie d'un numéro distinctif ou d'une 
lettre distinctive du pays ayant délivré l'homolog a­
tion, 
—d'un numéro d'homologat ion correspondant au nu­
méro du certificat d'homolog ation établie pour une 
carte tach ygraphique, placé dans une position quel ­
conque à proximité du rectang le.      
2.2 Essais 
mécaniques  240, 243 
ISO/CEI 7810   [Taille de la carte] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7810 Cartes d'identif ication — Caracté ristiques 
physiques, 
[5] Dimension de la carte, 
[5.1] Taille de la carte, 
[5.1.1] Dimensions et tolérances de la carte, 
type de carte ID-1 Carte inutilisée 
[Bords de la carte] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7810 Cartes d'identif ication — Caracté ristiques 
physiques, 
[5] Dimension de la carte, 
[5.1] Taille de la carte, 
[5.1.2] Bords de la carte  26.5.2016 L 139/320 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes    
[Constr uction de la carte] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7810 Cartes d'identif ication — Caracté ristiques 
physiques, 
[6] Constr uction de la carte 
[Matériaux des cartes] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7810 Cartes d'identif ication — Caracté ristiques 
physiques, 
[7] Matéri aux des cartes 
[Rigidité à la flexion] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7810 Cartes d'identif ication — Caracté ristiques 
physiques, 
[8] Caractéristi ques de la carte, 
[8.1] Rigidité à la flexion 
[Toxicité] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7810 Cartes d'identif ication — Caracté ristiques 
physiques, 
[8] Caractéristi ques de la carte, 
[8.3] Toxicité 
[Résistance aux agents chimiques] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7810 Cartes d'identif ication — Caracté ristiques 
physiques, 
[8] Caractéristi ques de la carte, 
[8.4] Résistance aux agents chimiques 
[Stabilit é de la carte] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7810 Cartes d'identif ication — Caracté ristiques 
physiques, 
[8] Caractéristi ques de la carte, 
[8.5] Stabilité des dimensions de la carte et déformations 
à la température et à l'humidité  26.5.2016 L 139/321 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes    
[Lum ière] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7810 Cartes d'identif ication — Caracté ristiques 
physiques, 
[8] Caractéristi ques de la carte, 
[8.6] Lumièr e 
[Durabilit é] 
Annex e 1C, chapitre 4.4 «Spécif ications environnementa ­
les et électr iques», 241) 
Les cartes tach ygraphiques doivent pouvoir fonctionner 
correcte ment pendant une période de cinq ans si elles 
sont utilisées conf ormément aux spécifi cations environ ­
nementales et électr iques. 
[Résistance au pelage] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7810 Cartes d'identif ication — Caracté ristiques 
physiques, 
[8] Caractéristi ques de la carte, 
[8.8] Résistance au pelage 
[Adhésion ou blocage] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7810 Cartes d'identif ication — Caracté ristiques 
physiques, 
[8] Caractéristi ques de la carte, 
[8.9] Adhésion ou blocage 
[Déf ormation] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7810 Cartes d'identif ication — Caracté ristiques 
physiques, 
[8] Caractéristi ques de la carte, 
[8.11] Déformation globale de la carte 
[Résistance à la chaleur] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7810 Cartes d'identif ication — Caracté ristiques 
physiques, 
[8] Caractéristi ques de la carte, 
[8.12] Résistance à la chaleur  26.5.2016 L 139/322 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes    
[Déf ormations de surface] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7810 Cartes d'identif ication — Caracté ristiques 
physiques, 
[8] Caractéristi ques de la carte, 
[8.13] Déformations de surface 
[Contamination] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7810 Cartes d'identif ication — Caracté ristiques 
physiques, 
[8] Caractéristi ques de la carte, 
[8.14] Contamination et interaction entre les compo ­
sants de la carte   
2.3 Essais 
mécaniques avec 
module de circuit 
intégré [Flexion] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7810:2003/Amd. 1:2009, Cartes d'identif ication 
— Caractéristique s physiques, Amendement 1: Critères 
des cartes conte nant des circuits intégré s 
[9.2] Contraintes de flexion dynamique 
Nombre total de cycles de flexion: 4 000. 
[Torsion] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7810:2003/Amd. 1:2009, Cartes d'identif ication 
— Caractéristique s physiques, Amendement 1: Critères 
des cartes conte nant des circuits intégré s 
[9.3] Contraintes de torsion dynamique 
Nombre total de cycles de torsion: 4 000.  ISO/CEI 7810 
3 Module 
3.1 Module Le module désigne l'encapsulation du circuit et la plaque de 
contact. 
[Profil de surface] 
Les cartes tach ygraphiques doivent respecte r la norme. 
ISO/CEI 7816-1:2011, Cartes d'identif ication — Cartes à 
circuit intégré — Partie 1: Cartes avec contacts — Carac ­
téristiques physiques 
[4.2] Profil de surface des contacts  ISO/CEI 7816 26.5.2016 L 139/323 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes  
[Résistance mécanique] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7816-1:2011, Cartes d'identif ication — Cartes à 
circuit intégré — Partie 1: Cartes avec contacts — Carac ­
téristiques physiques 
[4.3] Résistance mécanique (d'une carte et des contacts) 
[Résistance électr ique] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7816-1:2011, Cartes d'identif ication — Cartes à 
circuit intégré — Partie 1: Cartes avec contacts — Carac ­
téristiques physiques 
[4.4] Résistance électr ique (des contacts) 
[Dimension] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7816-2:2007, Cartes d'identif ication — Cartes à 
circuit intégré — Partie 2 Cartes avec contacts — Di­
mensions et emplacements des contacts 
[3] Dimension des contacts 
[Em placement] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7816-2:2007, Cartes d'identif ication — Cartes à 
circuit intégré — Partie 2 Cartes avec contacts — Di­
mensions et emplacements des contacts 
[4] Nombre et emp lacements des contacts 
Si les modules possèdent six contacts, les contacts ‘C4’ et 
‘C8’ ne sont pas soumis à cette exigenc e d'essai.      
4 Circuit 
4.1 Circuit  241 à 244 
CEE R10 
ISO/CEI 7810 
ISO/CEI 10373   
[Température d'exploitation] 
Le circuit de la carte tach ygraphique fonctionne dans une 
plag e de température ambiante de – 25°C à + 85 °C.  26.5.2016 L 139/324 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes    
[Température et humidit é] 
Annex e 1C, chapitre 4.4 «Spécif ications environnementa ­
les et électr iques», 241) 
Les cartes tach ygraphiques doivent pouvoir fonctionner 
correcte ment dans tout es les conditions climatiques nor­
malement obser vées sur le territoire communautaire, et 
au minimum dans une gam me de température compris e 
entre – 25 °C et + 70 °C, avec des pointes occasionnelles 
à + 85 °C, «occasionnelles» signif iant d'une durée infé­
rieure ou égale à 4 heures et survenant au maximum à 
100 repr ises au cours de la durée de vie de la carte. 
Les cartes tach ygraphiques sont exposées en plusieurs 
étapes aux températures et hygrométr ies suivantes pen­
dant une période donnée. Après chaque étape, la fonc­
tionnalité électr ique des cartes tach ygraphiques fait l'ob­
jet d'essais. 
1.  Température de – 20 °C pendant 2 heures. 
2.  Température de +/–0 °C pendant 2 heures. 
3.  Température de + 20 °C, 50 % HR pendant 2 heures. 
4.  Température de + 50 °C, 50 % HR pendant 2 heures. 
5.  Température de + 70 °C, 50 % HR pendant 2 heures. 
La température augmente par interm ittence à 
+ 85 °C, 50 % HR, pendant 60 min. 
6.  Température de + 70 °C, 85 % HR pendant 2 heures. 
La température augmente par interm ittence à 
+ 85 °C, 85 % HR, pendant 30 min. 
[Humidité] 
Annex e 1C, chapitre 4.4 «Spécif ications environnementa ­
les et électr iques», 242 
Les cartes tach ygraphiques doivent pouvoir fonctionner 
correcte ment dans une gamme d'humidit é compris e en­
tre 10 % et 90 %. 
[Com patibilité électromagnétique — CEM] 
Annex e 1C, chapitre 4.4 «Spécif ications environnementa ­
les et électr iques», 244 
En fonctionnement, les cartes tach ygraphiques doivent 
satisf aire à la réglementation CEE R10, relative à la 
compati bilité électromagnétique.   26.5.2016 L 139/325 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes  
[Électr icité statique] 
Annex e 1C, chapitre 4.4 «Spécif ications environnementa ­
les et électr iques», 244 
En fonctionnement, les cartes tach ygraphiques doivent 
être protég ées contre les décharges électrostatiques. 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7810:2003/Amd. 1:2009, Cartes d'identif ication 
— Caractéristique s physiques, Amendement 1: Critères 
des cartes conte nant des circuits intégré s 
[9.4] Électr icité statique 
[9.4.1] Cartes à circuit intégré avec contacts 
Tension d'essai: 4 000 V. 
[Rayons X] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7810:2003/Amd. 1:2009, Cartes d'identif ication 
— Caractéristique s physiques, Amendement 1: Critères 
des cartes conte nant des circuits intégré s 
[9.1] Rayons X 
[Lum ière ultravi olette] 
ISO/CEI 10373-1:2006, Cartes d'identif ication — Métho ­
des d'essai Partie 1: Caractéristique s générales 
[5.11] Lumière ultraviolett e 
[3-roues] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 10373-1:2006/Amd. 1:2012, Cartes d'identif ica­
tion — Méthodes d'essai — Partie 1: Caractéristique s gé­
nérales, Amendement 1 
[5.22] CCI — Résistance mécanique: Essai trois roues 
pour les CCI avec contacts 
[Envelo ppe] 
Les cartes tach ygraphiques doivent respecte r la norme 
Mast erCard CQM V2.03:2013 
[11.1.3] R-L3-14-8: Essai de robuste sse de l'env eloppe 
[13.2.1.32] TM-422: Fiabilité mécanique: Essai d'en ve­
loppe  26.5.2016 L 139/326 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes 
4.2 Module de circuit 
intégré des essais 
mécaniques 
intégré dans le 
corps de la carte 
-> identique 2.3 [Flexion] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7810:2003/Amd. 1:2009, Cartes d'identif ication 
— Caractéristique s physiques, Amendement 1: Critères 
des cartes conte nant des circuits intégré s 
[9.2] Contraintes de flexion dynamique 
Nombre total de cycles de flexion: 4 000. 
[Torsion] 
Les cartes tach ygraphiques doivent respecte r la norme 
ISO/CEI 7810:2003/Amd. 1:2009, Cartes d'identif ication 
— Caractéristique s physiques, Amendement 1: Critères 
des cartes conte nant des circuits intégré s 
[9.3] Contraintes de torsion dynamique 
Nombre total de cycles de torsion: 4 000.  ISO/CEI 7810 
5 Essais de protocole 
5.1 ATR S'assurer de la conf ormité de l'ATR ISO/CEI 7816-3 
TCS_14, TCS_17, 
TCS_18 
5.2 T=0 S'assurer de la conf ormité du protocole T=0 ISO/CEI 7816-3 
TCS_11, TCS_12, 
TCS_13, TCS_15 
5.3 PTS S'assurer de la conf ormité de la commande PTS en passant 
de T=0 à T=1 ISO/CEI 7816-3 
TCS_12, TCS_19, 
TCS_20, TCS_21 
5.4 T=1 S'assurer de la conf ormité du protocole T=1 ISO/CEI 7816-3 
TCS_11, TCS_13, 
TCS_16 
6 Structure de la carte 
6.1  S'assurer de la conf ormité de la structure des fichiers 
enregistrée sur la carte en contrôlant la présence des 
fichiers oblig atoires sur la carte ainsi que leurs conditions 
d'accès TCS_22 à TCS_28 
TCS_140 à TCS_179 
7 Essais de fonctionnement 
7.1 Fonctionnement 
normal Vérifier au moins une fois chaque usage autori sé de chaque 
commande. (ex: essa yer la commande UPD ATE BINAR Y 
avec CLA = ′00′, CLA = ′0C′ pour des paramètres P1, P2 
et Lc distincts). 
S'assurer que les opérations voulues ont été correctement 
exécut ées sur la carte (ex.: en extra yant le fichier sur lequel 
la commande considérée a été exécut ée). TCS_29 à TCS_139 26.5.2016 L 139/327 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes 
7.2 Messages d'erreur Il convi ent de tester une fois au moins chaque message 
d'erreur (comme indiqué à l'appendice 2) pour chaque 
commande. 
Tester une fois au moins chaque erreur génér ique (à 
l'excep tion des erreurs d'intégrité ′6400′ contrôlées 
pendant la phase de certification de sécur ité).  
7.3 Suit e de chiffrement et paramètres de domaines normalisés CSM_48, CSM_50 
8 Personnalisation 
8.1 Personnalisation 
optique Annex e 1C, chapitre 4.1 «Données visibles», 230) 
La première page doit compo rter: 
des indications particulières concer nant la carte délivrée. 
Annex e 1C, chapitre 4.1 «Données visibles», 231) 
La première page doit compo rter: 
Les dates sont indiquées sous la forme «jj/mm/aaaa» ou 
«jj.mm.aaaa» (jour , mois, année). 
Annex e 1C, chapitre 4.1 «Données visibles», 235) 
Les cartes tach ygraphiques présent ent au minimum les 
éléments de prote ction suivants contre la contref açon et 
la manipulation du corps de la carte: 
—  chevauc hement de l'impression de fond de sécur ité et 
de la photographie.  230, 231, 235  
5.  ESSAIS DU DISPOSITIF GNSS EXTERNE 
No Essai Descr iption Exigences connexes 
1. Exa men administ ratif 
1.1 Documentation Exactitude de la documentation  
2. Inspection visuelle d'un dispositif GNSS exter ne 
2.1. Conf ormité avec la documentation  
2.2. Identif ication/marquag e 224 à 226 
2.3 Matériaux 219 à 223 
3. Essais de fonctionnement 
3.1 Données d'identification du capt eur 98,99 
3.2 Couplage module GNSS exte rne — unité embarquée sur véhicule 123, 205 26.5.2016 L 139/328 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes 
3.3 Position du GNSS 36, 37 
3.4 Interfa ce de l'unit é embarquée sur véhicule lorsque le récep teur GNSS est ex­
terne à l'unit é embarquée sur le véhicule 03 
3.5 Suit e de chiffrement et paramètres de domaines normalisés CSM_48, CSM_50 
4. Essais environnement aux 
4.1 Temp érature S'assurer de la fonctionnalit é en exécutant les essais sui­
vants: 
Essai conf orme à la norme ISO 16750-4, Chapitre 5.1.1.2: 
Essai d'exploitation à basse température (72 h @ – 20 °C) 
Cet essai satisfait à la norme CEI 60068-2-1: Essais d'envi ­
ronnement — Partie 2-1: essais — essai A: froid 
Essai conf orme à la norme ISO 16750-4: Chapitre 5.1.2.2: 
Essai d'exploitation à haute température (72 h @ 70 °C) 
Cet essai satisfait à la norme CEI 60068-2-2: Procédures 
d'essai environnemental de base; partie 2: essais; essais B: 
chaleur sèche 
Essai conf orme à la norme ISO 16750-4: Chapitre 5.3.2: 
Variation rapide de température avec durée de transition 
spécifi ée (– 20 °C/70 °C, 20 cycles, temps de maintien de 
1 h à chaque température) 
Il est possible de se livrer à un nombre limité d'essais 
(par mi ceux définis à la section 3 de ce tableau) aux tempé­
ratures minimale et maximale indiquées ainsi que pendant 
les cycles de variation de la température 213 
4.2 Humidité S'assurer que l'unit é embarquée sur le véhicule est capable 
de résister à un cycle de chaleur humide (essai de résistance 
à la chaleur) en exécutant l'essai CEI 60068-2-30, essai Db, 
compo rtant six cycles de 24 heures, la température variant 
de + 25 °C à + 55 °C et le taux d'humidit é relative attei­
gnant 97 % à + 25 °C et 93 % à + 55 °C 214 
4.3 Mécanique 1.  Vibrations sinusoïdales. 
S'assurer que l'unité embarquée sur le véhicule est ca­
pable de résist er à des vibrations sinusoïdales possédant 
les caractér istiques suivantes: 
déplacement constant compris entre 5 et 11 Hz: 
10 mm max; 
accélération constant e compris e entre 11 et 300 Hz: 5 g 
L'essai CEI 60068-2-6, essai Fc, permet de vérifier la sa­
tisfa ction de cette exige nce. La durée minimale de cet es­
sai s'élève à 3 × 12 heures (12 heures par essieu). 
La norme ISO 16750-3 n'im pose pas d'essai de vibra ­
tions sinusoïdales aux dispositifs situés dans la cabine 
découplée du véhicule.  219 26.5.2016 L 139/329 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes 
2.  Vibrations aléatoires: 
Essai conf orme à la norme ISO 16750-3: Chapitre 
4.1.2.8: Essai VIII: Véhicule commercial, cabine de véhi ­
cule découplée. 
Essai de vibrations aléatoi res, 10...2 000 Hz, RMS verti­
cal 21,3 m/s2, RMS longitudinal 11,8 m/s2, RMS latéral 
13,1 m/s2, 3 essieux, 32 h par essieu, y compris un cy­
cle de température – 20...70 °C. 
Cet essai satisfait à la norme CEI 60068-2-64: Essais 
d'en vironnement — Partie 2-64: essais — essai Fh: vi­
brations aléatoi res à large bande et guide 
3.  Chocs: 
choc mécanique d'un demi-sinus de 3 g conf ormément 
à la norme ISO 16750. 
Il convient d'exécut er les essais décr its ci-avant sur des 
échantillon s distincts du type d'équipement testé. 
4.4 Protection contre 
l'eau et les corps 
étrangers Essai conf orme à la norme ISO 20653: Véhicules routiers 
— Degrés de prot ection (code IP) — Protection des équipe ­
ments électr iques contre les corps étrangers, l'eau et les 
contacts (aucune modifi cation des paramètres) 220, 221 
4.5 Protection contre 
les surtensions S'assurer que l'unit é embarquée sur le véhicule est capable 
de suppor ter une tension d'alimentation de: 216 
versions 24 V: 34 V à + 40 °C 1 heure 
versions 12 V: 17 V à + 40 °C 1 heure 
(ISO 16750-2, chapitre 4.3) 
4.6 Protection contre 
les inversions de 
polar ité S'assurer que l'unit é embarquée sur le véhicule est capable 
de suppor ter une inve rsion de polar ité au niveau de son ali­
mentation électr ique 
(ISO 16750-2, chapitre 4.7) 216 
4.7 Protection contre 
les cour ts-circuits S'assurer que les signaux d'entrée et de sortie sont protég és 
contre les cour ts-circuits à l'alimentation électr ique et à la 
terre 
(ISO 16750-2, chapitre 4.10) 216 
5 Essais de compatibilité électromagnétique 
5.1 Émissions rayon­
nées et sensibilit é Conf ormité avec le règlement CEE R10 218 26.5.2016 L 139/330 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes 
5.2 Déch arge électro ­
statique Conf ormité avec la norme ISO 10605:2008 + Rectif icatif 
technique:2010 + AMD1:2014: +/– 4 kV pour le contact et 
+/– 8 kV pour la décharg e d'air 218 
5.3 Suscept ibilité 
transito ire par 
conduction au ni­
veau de l'alimen ­
tation Pour les versions 24 V: conf ormité avec la norme ISO 
7637-2 + Règlement CEE no 10 Rév. 3: 
impulsion 1a: Vs = – 450 V Ri = 50 ohms 
impulsion 2a: Vs = + 37 V Ri = 2 ohms 
impulsion 2b: Vs = + 20 V Ri = 0,05 ohms 
impulsion 3a: Vs = – 150 V Ri = 50 ohms 
impulsion 3b: Vs = + 150 V Ri = 50 ohms 
impulsion 4: Vs = – 16 V Va = – 12 V t6 = 100 ms 
impulsion 5: Vs = + 120 V, Ri = 2,2 ohms, td = 250 ms 
Pour les versions 12 V: conf ormité avec la norme ISO 
7637-1 + Règlement CEE no 10 Rév. 3: 
impulsion 1: Vs = – 75 V Ri = 10 ohms 
impulsion 2a: Vs = + 37 V Ri = 2 ohms 
impulsion 2b: Vs = + 10 V Ri = 0,05 ohms 
impulsion 3a: Vs = – 112 V Ri = 50 ohms 
impulsion 3b: Vs = + 75 V Ri = 50 ohms 
impulsion 4: Vs = – 6 V Va = -5 V t6 = 15 ms 
impulsion 5: Vs = + 65 V, Ri = 3 ohms, td = 100 ms 
L'im pulsion 5 ne sera testée que pour les unités à installer 
sur des véhicules dépour vus de dispositif commun de pro­
tectio n exte rne contre la perte de charge. 
Pour la proposition de perte de charg e, consulte r la norme 
ISO 16750-2, 4e édition, chapitre 4.6.4. 218  
6.  ESSAIS DES ÉQUIPEMENTS DE COMMUNICA TION À DIST ANCE 
No Essai Descr iption Exigences connexes 
1. Exa men administ ratif 
1.1 Documentation Exactitude de la documentation  
2. Inspection visuelle 
2.1. Conf ormité avec la documentation  
2.2. Identif ication/marquag e 225, 226 
2.3 Matériaux 219 à 223 26.5.2016 L 139/331 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes 
4. Essais environnement aux 
4.1 Temp érature S'assurer de la fonctionnalit é en exécutant les essais sui­
vants: 
Essai conf orme à la norme ISO 16750-4, Chapitre 5.1.1.2: 
Essai d'exploitation à basse température (72 h @ -20 °C) 
Cet essai satisfait à la norme CEI 60068-2-1: Essais d'envi ­
ronnement — Partie 2-1: essais — essai A: froid 
Essai conf orme à la norme ISO 16750-4: Chapitre 5.1.2.2: 
Essai d'exploitation à haute température (72 h @ 70 °C) 
Cet essai satisfait à la norme CEI 60068-2-2: Procédures 
d'essai d'en vironnement de base; partie 2: essais; essais B: 
chaleur sèche 
Essai conf orme à la norme ISO 16750-4: Chapitre 5.3.2: 
Variation rapide de température avec durée de transition 
spécifi ée (-20 °C/70 °C, 20 cycles, temps de maintien de 
1 h (?) à chaque température). 
Il est possible de se livrer à un nombre limité d'essais 
(par mi ceux définis à la section 3 de ce tableau) aux tempé­
ratures minimale et maximale indiquées ainsi que pendant 
les cycles de variation de la température 213 
4.4 Protection contre 
l'eau et les corps 
étrangers Essai conf orme à la norme ISO 20653: Véhicules routiers 
— Degrés de prot ection (code IP) — Protection des équipe ­
ments électr iques contre les corps étrangers, l'eau et les 
contacts (valeur ciblée IP40) 220, 221 
5 Essais de compatibilité électromagnétique 
5.1 Émissions rayon­
nées et sensibilit é Conf ormité avec le règlement CEE R10 218 
5.2 Déch arge électro ­
statique Conf ormité avec la norme ISO 10605:2008 + Rectif icatif 
technique:2010 + AMD1:2014: +/– 4 kV pour le contact et 
+/– 8 kV pour la décharg e d'air 218 
5.3 Suscept ibilité 
transito ire par 
conduction au ni­
veau de l'alimen ­
tation Pour les versions 24 V: conf ormité avec la norme ISO 
7637-2 + Règlement CEE no 10 Rév. 3: 
impulsion 1a: Vs = – 450 V Ri = 50 ohms 
impulsion 2a: Vs = + 37 V Ri = 2 ohms 
impulsion 2b: Vs = + 20 V Ri = 0,05 ohms 
impulsion 3a: Vs = – 150 V Ri = 50 ohms 
impulsion 3b: Vs = + 150 V Ri = 50 ohms 
impulsion 4: Vs = – 16 V Va = – 12 V t6 = 100 ms 
impulsion 5: Vs = + 120 V, Ri = 2,2 ohms, td = 250 ms  218 26.5.2016 L 139/332 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes 
Pour les versions 12 V: conf ormité avec la norme ISO 
7637-1 + Règlement CEE no 10 Rév. 3: 
impulsion 1: Vs = – 75 V Ri = 10 ohms 
impulsion 2a: Vs = + 37 V Ri = 2 ohms 
impulsion 2b: Vs = + 10 V Ri = 0,05 ohms 
impulsion 3a: Vs = – 112 V Ri = 50 ohms 
impulsion 3b: Vs = +75 V Ri = 50 ohms 
impulsion 4: Vs = – 6 V Va = -5 V t6 = 15 ms 
impulsion 5: Vs = + 65 V, Ri = 3 ohms, td = 100 ms 
L'im pulsion 5 ne sera testée que pour les unités à installer 
sur des véhicules dépour vus de dispositif commun de pro­
tectio n exte rne contre la perte de charge. 
Pour la proposition concer nant la perte de charg e, consul ­
ter la norme ISO 16750-2, 4e édition, chapitre 4.6.4.  
7.  ESSAIS FONCTIONNELS SUR LE PAPIER 
No Essai Descr iption Exigences connexes 
1. Exa men administ ratif 
1.1 Documentation Exactitude de la documentation  
2 Essais généraux 
2.1 Nombre de carac ­
tères par ligne Inspection visuelle des impressions. 172 
2.2 Taille min. des 
caractères Inspection visuelle des impressions et contrôle des caractè ­
res. 173 
2.3 Jeux de caractères 
compati bles L'im primante doit prendre en charg e les caractères spécifiés 
au chapitre 4 «Jeux de caractères» de l'appendice 1. 174 
2.4 Défi nition des 
imp ressions Contrôle de l'homolog ation du type de tach ygraphe et ins­
pection visuelle des impressions 174 
2.5 Lisibilit é et identi ­
fication des im­
pressions Inspection des impressions 
Étayé par des rappor ts d'essai et des protocoles d'essai par 
le fabricant. 
Tous les numéros d'homologation des tach ygraphes avec 
lesquels il est possible d'utiliser le papier d'im pression sont 
impr imés sur le papier . 175, 177, 178 
2.6 Ajout de 
commentaires 
manuscr its Contrôle visuel: la zone de signature du conduct eur est dis­
ponible. 
D'autres zones de saisie manuscr ites sont disponibles. 180 26.5.2016 L 139/333 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes 
2.7 Détails complé ­
mentaires sur le 
recto et le verso 
du papier . Le recto et le verso du papier peuvent fournir des détails et 
des informations supplémentaires. 
Ces détails et ces informations supplémentaires n'interfèrent 
pas systé matiquement avec la lisibilité des impressions. 
Contrôle visuel 177, 178 
3 Essais de stocka ge 
3.1 Chaleur sèche Préconditionnement: 16 heures à + 23 °C ± 2 °C/55 % ± 
3 % d'humidit é relative 
Environneme nt d'essai: 72 h à + 70 °C ± 2 °C 
Récupération: 16 heures à + 23 °C ± 2 °C/55 % ± 3 % d'hu ­
midité relative 176, 178 
CEI 60068-2-2-Bb 
2.2 Chaleur humide Préconditionnement: 16 heures à + 23 °C ± 2 °C/55 % ± 
3 % d'humidit é relative 
Environneme nt d'essai: 144 heures à + 55 °C ± 2 °C et 
93 % ± 3 % d'h.r . 
Récupération: 16 heures à + 23 °C ± 2 °C/55 % ± 3 % d'hu ­
midité relative 176, 178 
CEI 60068-2-78-Cab 
4 Essais sur papier en circulation 
4.1 Context e de résis ­
tance à l'humidité 
(papier non im­
primé) Préconditionnement: 16 heures à + 23 °C ± 2 °C/55 % ± 
3 % d'humidit é relative 
Environneme nt d'essai: 144 heures à + 55 °C ± 2 °C et 
93 % ± 3 % d'h.r . 
Récupération: 16 heures à + 23 °C ± 2 °C/55 % ± 3 % d'hu ­
midité relative 176, 178 
CEI 60068-2-78-Cab 
4.2 Imp rimabilit é Préconditionnement: 24 heures à + 40 °C ± 2 °C/93 % ± 
3 % d'humidit é relative 
Environneme nt d'essai: imp ression produite à + 23 °C ± 
2 °C 
16 heures à + 23 °C ± 2 °C/55 % ± 3 % d'humidit é relative 176, 178 
4.3 Ther morésistance Préconditionnement: 16 heures à + 23 °C ± 2 °C/55 % ± 
3 % d'humidit é relative 
Environneme nt d'essai: 2 heures at + 70 °C ± 2 °C, chaleur 
sèche 
Récupération: 16 heures à + 23 °C ± 2 °C/55 % ± 3 % d'hu ­
midité relative 176, 178 
CEI 60068-2-2-Bb 
4.4 Résistance aux 
températures bas­
ses Préconditionnement: 16 heures à + 23 °C ± 2 °C/55 % ± 
3 % d'humidit é relative 
Environneme nt d'essai: 24 heures at – 20 °C ± 3 °C, chaleur 
sèche 
Récupération: 16 heures à + 23 °C ± 2 °C/55 % ± 3 % d'hu ­
midité relative 176, 178 
ISO 60068-2-1-Ab 26.5.2016 L 139/334 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption Exigences connexes 
4.5 Photorés istance Préconditionnement: 16 heures à + 23 °C ± 2 °C/55 % ± 
3 % d'humidit é relative 
Environneme nt d'essai: 100 heures sous une lumière de 
5 000 Lux à + 23 °C ± 2 °C/55 % ± 3 % d'humidit é rela­
tive 
Récupération: 16 heures à + 23 °C ± 2 °C/55 % ± 3 % d'hu ­
midité relative 176, 178  
Critère de lisibilité pour les essais 3.x et 4.x: 
La lisibilité des impressions est garantie si la densité optique respecte les contraintes suivantes: 
Caractères imprimés: min. 1 
Suppor t (papier non imprimé): max 0,2 
La mesure de densité optique des impressions produite s respecte la norme DIN EN ISO 534. 
Les impressions ne subissent aucune modifi cation de dimension et demeurent parfaitem ent lisibles. 
8.  ESSAIS D'INTER OPÉRABILITÉ 
No Essai Descr iption 
9.1 Essais d'inter opérabilité entre unités embarquées sur véhicule et cartes tach ygraphiques 
1 Auth entif ication 
mutuelle S'assurer de la bonne exécuti on de la procédure d'authentification mutuelle entre 
l'unité embarquée sur le véhicule et la carte tach ygraphique. 
2 Essais de lecture/ 
écriture Mettre à exécution un scénar io d'activit é classique sur l'unité embarquée sur le véhi ­
cule. Le scénar io doit être adap té au type de carte testé et compo rter l'exécution d'opé ­
rations d'écr iture dans le plus grand nombre possible d'EF que présente la carte. 
Procéder à un téléc hargement sur VU pour s'assurer de la bonne exécution de tous les 
enregistrements correspondants. 
Procéder à un téléc hargement sur carte pour s'assurer de la bonne exécuti on de tous 
les enregistrements correspondants. 
Procéder à des impressions quotidiennes pour s'assurer de la bonne lisibilité des enre ­
gistrements correspondants. 
9.2 Essais d'interopérabilit é entre unité s embarquées sur véhicule et capt eurs de mouvement 
1 Appar iement S'assurer de la bonne exécution de l'appar iement entre l'unité embarquée sur le véhi ­
cule et le capt eur de mouvement 
2 Essais d'activit é Exécuter un scénar io d'activit é classique sur le capt eur de mouvement. Le scénar io im­
plique une activité normale et la création d'un nombre d'événement et d'anomalies 
aussi élevé que possible. 
Procéder à un téléc hargement sur VU pour s'assurer de la bonne exécution de tous les 
enregistrements correspondants. 
Procéder à un téléc hargement sur carte pour s'assurer de la bonne exécuti on de tous 
les enregistrements correspondants. 
Procéder à une impression quotidienne pour s'assurer de la bonne lisibilité des enre ­
gistrements correspondants. 26.5.2016 L 139/335 Jour nal officiel de l'Union européenne FR     
No Essai Descr iption 
9.3 Essais d'inte ropérabilité entre les VU et les dispositifs GNSS externes (le cas échéant) 
1 Auth entif ication 
mutuelle S'assurer de la bonne exécution de la procédure d'authentification mutuelle (couplage) 
entre l'unité embarquée sur le véhicule et le module GNSS extern e. 
2 Essais d'activit é Exécuter un scénar io d'activit é classique sur le dispositif GNSS externe. Le scénar io 
implique une activité normale et la création d'un nombre d'événement et d'anomalies 
aussi élevé que possible. 
Procéder à un téléc hargement sur VU pour s'assurer de la bonne exécution de tous les 
enregistrements correspondants. 
Procéder à un téléc hargement sur carte pour s'assurer de la bonne exécuti on de tous 
les enregistrements correspondants. 
Procéder à une impression quotidienne pour s'assurer de la bonne lisibilité des enre ­
gistrements correspondants.   26.5.2016 L 139/336 Jour nal officiel de l'Union européenne FR     
Appendice 10 
EXIGENCES EN MA TIÈRE DE SÉCURITÉ 
Le présent appendice précise les exige nces en matière de sécur ité informatique concer nant les compo sants du 
tach ygraphe intellig ent (tach ygraphe de seconde génération). 
SEC_001  Les compo sants suivants du tach ygraphe intellig ent doivent faire l'objet d'une certification de sécur ité 
conf orme aux critères communs: 
—  unité embarquée sur le véhicule, 
—  carte tach ygraphique, 
—  capt eur de mouvement, 
—  dispositif GNSS externe. 
SEC_002  Les exige nces minimales de sécur ité informatique à satisfa ire par chaque compo sant soumis à une certification 
de sécur ité doivent être définies par un profil de protection du compo sant, conf ormément aux Critères 
communs. 
SEC_003  La Commission européenne doit s'assurer que quatre prof ils de prote ction conf ormes à la présent e annexe 
sont parrainés, développés, approuvés par les organismes gouver nementaux de certification de la sécur ité 
informatique conjointeme nt avec le groupe de travai l d'interpr étation conjointe (JIW G), qui encourage nt la 
reconnaissance mutuelle des certificats sous l'égide européenne du SOG-IS MRA (accord sur la reconnaissance 
mutuelle des certificats d'évaluation de la sécur ité en matière de technologie de l'information) et qu'ils font 
l'objet d'un enregistrement: 
—  profil de prote ction d'une unité embarquée sur le véhicule; 
—  profil de prote ction d'une carte tach ygraphique; 
—  profil de prote ction d'un capt eur de mouvement ; 
—  profil de prote ction d'un dispositif GNSS externe. 
Le profil de protect ion d'une unité embarquée sur le véhicule est destiné aux cas où l'unit é embarquée sur le véhicule a 
été conçue pour être utilisée avec ou sans dispositif GNSS externe. Dans le premier cas, les exigenc es de sécur ité du 
dispositif GNSS extern e sont stipulées dans le profil de prote ction dédié. 
SEC_004  Pour établir un objectif de sécur ité en vue de l'obtention de certificat s de sécur ité du composant, les fabricants 
de compo sants habilités affineront et compl èteront selon les besoins le prof il de protection de compo sant 
appropr ié, sans suppr imer ni modifier les spécifi cations concer nant les menaces, les objectifs, les ressources 
procédurales et les fonctions de maintien de la sécur ité. 
SEC_005  La stricte conf ormité dudit objectif de sécur ité avec le profil de prote ction correspondant doit être déclarée au 
cours du processus d'évaluation. 
SEC_006  Le niveau de garant ie exigé par chaque prof il de prote ction est le niveau EAL4 augmenté des compo sants de 
garan tie ATE_DPT .2 et AVA_V AN.5.  26.5.2016 L 139/337 Jour nal officiel de l'Union européenne FR     
Appendice 11 
MÉC ANISMES DE SÉCURITÉ COMMUNS 
TABLE DES MATIÈRES 
PRÉAMBULE ................................................................................................................................... 340 
PARTI E A TACHY GRAPHE DE PREMIÈRE GÉNÉRA TION ...................................................................................... 341 
1. INTR ODUCTION ........................................................................................................................... 341 
1.1. Références ....................................................................................................................... 341 
1.2. Notations et abréviations .................................................................................................... 341 
2. SYSTÈMES ET ALGORITHMES CRYPTOGRAPHIQUES ............................................................................ 343 
2.1. Systèmes cryptographiques .................................................................................................. 343 
2.2. Algor ithmes cryptographiques .............................................................................................. 343 
2.2.1 Algor ithme RSA ............................................................................................................... 343 
2.2.2 Algor ithme de hachag e....................................................................................................... 343 
2.2.3 Algor ithme de cryptage des données ..................................................................................... 343 
3. CLÉS ET CER TIFIC ATS.................................................................................................................... 343 
3.1. Génération et distr ibution de clés .......................................................................................... 343 
3.1.1 Génération et distr ibution de clés RSA ................................................................................... 343 
3.1.2 Clés de contrôle RSA ......................................................................................................... 345 
3.1.3 Clés du capt eur de mouvement ............................................................................................ 345 
3.1.4 Génération et distr ibution de clés de session T-DES ................................................................... 345 
3.2. Clés ................................................................................................................................ 345 
3.3. Certificat s........................................................................................................................ 345 
3.3.1 Contenu des certificats ....................................................................................................... 346 
3.3.2 Certificat s émis ................................................................................................................. 348 
3.3.3 Vérification et dévoilem ent des certificat s............................................................................... 349 
4. MÉCAN ISME D'AUTHENTIFIC ATION MUTUELLE .................................................................................. 349 
5. MÉCAN ISMES DE CONFIDENTIALITÉ, D'INTÉGRITÉ ET D'AUTHENTIFICA TION DES DONNÉES TRANSFÉRÉES 
ENTRE LES VU ET LES CARTES ........................................................................................................ 352 
5.1. Messagerie sécur isée ........................................................................................................... 352 
5.2. Traitement des erreurs de messager ie sécur isée ......................................................................... 354 
5.3. Algor ithme de calcul des totaux de contrôle cryptographiques ..................................................... 354 
5.4. Algor ithme de calcul des cryptogrammes destinés aux instr uctions DO de confidentialité .................. 355 
6. MÉCAN ISMES DE SIGNA TURE NUMÉRIQUE DES TÉLÉC HAR GEMENTS DE DONNÉES ................................... 355 
6.1. Génération de signatures ..................................................................................................... 355 
6.2. Vérification de signatures .................................................................................................... 356 26.5.2016 L 139/338 Jour nal officiel de l'Union européenne FR     
PARTI E B TACHY GRAPHE DE DEUXIÈME GÉNÉRA TION ...................................................................................... 357 
7. INTR ODUCTION ........................................................................................................................... 357 
7.1. Références ....................................................................................................................... 357 
7.2. Notations et abréviations .................................................................................................... 357 
7.3. Défi nitions ....................................................................................................................... 359 
8. SYSTÈMES ET ALGORITHMES CRYPTOGRAPHIQUES ............................................................................ 359 
8.1. Systèmes cryptographiques .................................................................................................. 359 
8.2. Algor ithmes cryptographiques .............................................................................................. 360 
8.2.1 Algor ithmes symétr iques .................................................................................................... 360 
8.2.2 Algor ithmes asymétr iques et paramètres de domaine normalisés .................................................. 360 
8.2.3 Algor ithmes de hach age ...................................................................................................... 361 
8.2.4 Méthodes de cryptage ......................................................................................................... 361 
9. CLÉS ET CER TIFIC ATS.................................................................................................................... 361 
9.1. Paires de clés asymétr iques et certificats de clé publique ............................................................. 361 
9.1.1 Généralités ....................................................................................................................... 361 
9.1.2 Niveau européen ............................................................................................................... 362 
9.1.3 Niveau État membre .......................................................................................................... 362 
9.1.4 Niveau équipement: unités embarquées sur véhicule .................................................................. 363 
9.1.5 Niveau équipement: cartes tach ygraphiques ............................................................................. 365 
9.1.6 Niveau équipement: dispositifs GNSS extern es......................................................................... 366 
9.1.7 Généralités : certificat de substitution ...................................................................................... 367 
9.2. Clés symétr iques ............................................................................................................... 368 
9.2.1 Clés de sécur isation de la communication du capt eur de mouvement de la VU ................................ 368 
9.2.2 Clés de sécur isation de la communication DSR C...................................................................... 372 
9.3. Certificat s........................................................................................................................ 375 
9.3.1 Généralités ....................................................................................................................... 375 
9.3.2 Contenu du certificat ......................................................................................................... 375 
9.3.3 Certificat s de demande ....................................................................................................... 377 
10. AUTHENTIFIC ATION MUTUELLE DE LA CARTE ET DE LA VU ET MESSA GERIE SÉCURISÉE ............................ 378 
10.1. Généralités ....................................................................................................................... 378 
10.2. Vérification mutuelle de la chaîne de certificat ......................................................................... 379 
10.2.1 Vérification de la chaîne de certificat de la carte par la VU ......................................................... 379 
10.2.2 Vérification de la chaîne de certificat de la VU par la carte......................................................... 381 
10.3. Auth entif ication de VU ....................................................................................................... 384 
10.4. Auth entif ication du circuit et concordance des clés de session ..................................................... 385 26.5.2016 L 139/339 Jour nal officiel de l'Union européenne FR     
10.5. Messagerie sécur isée ........................................................................................................... 387 
10.5.1 Généralités ....................................................................................................................... 387 
10.5.2 Structure de message sécur isé .............................................................................................. 388 
10.5.3 Abandon de la session de message rie sécur isée ........................................................................ 391 
11. COUPLA GE DE L'UV ET DU DISPOSITIF GNSS, AUTHENTIFICA TION MUTUELLE ET MESSA GERIE SÉCURISÉE .... 392 
11.1. Généralités ....................................................................................................................... 392 
11.2. couplage d'une VU et d'un dispositif extern e GNSS ................................................................... 393 
11.3. Vérification mutuelle de la chaîne de certificat ......................................................................... 393 
11.3.1 Généralités ....................................................................................................................... 393 
11.3.2 Pendant le couplage VU — EGF ............................................................................................ 393 
11.3.3 Pendant le fonctionnement normal ........................................................................................ 394 
11.4. Auth entif ication de la VU, Authentif ication du circuit et concordance des clés de session .................. 395 
11.5. Messagerie sécur isée ........................................................................................................... 395 
12. COUPLA GE ET COMMUNIC ATION DE LA VU ET DU CAPTEUR DE MOUVEMENT ....................................... 396 
12.1. Généralités ....................................................................................................................... 396 
12.2. Couplage de la VU et du capt eur de mouvement à l'aide de générations de clés différ entes ................. 396 
12.3. couplage et communication de la VU et du capt eur de mouvement en utilisant AES ......................... 397 
12.4. couplage de la VU et du capt eur de mouvement pour des équipements de générations diffé rentes ....... 399 
13. SÉCURITÉ DES COMMUNICA TIONS DIST ANTES UTILISANT DSR C........................................................... 399 
13.1. Généralités ....................................................................................................................... 399 
13.2. Cryptage des données utiles du tach ygraphe et génération du MAC.............................................. 400 
13.3. Vérification et décr yptage de la charg e du tach ygraphe .............................................................. 401 
14. SIGNA TURE DES TÉLÉCHAR GEMENT DE DONNÉES ET CONTRÔLE DES SIGNA TURES ................................. 401 
14.1. Généralités ....................................................................................................................... 401 
14.2. Génération de signatures ..................................................................................................... 402 
14.3. Vérification de signatures .................................................................................................... 402  
PRÉAMBULE 
Le présent appendice indique les mécanismes de sécur ité garantissant 
—  l'authentification mutuelle entre les différ ents compo sants du tach ygraphe. 
—  confidentialité, intégr ité, authenticité et/ou non-répudiation des données transfé rées entre les différ ents compo sants 
du tach ygraphe ou téléc harg ées vers un suppor t de stoc kage exte rne. 
Le présent appendice se compo se de deux parties. La partie A définit les mécanismes de sécur ité pour le tach ygraphe de 
première génération (tachygraphe numér ique). La partie B définit les mécanismes de sécur ité pour le tach ygraphe de 
deuxième génération (tachygraphe intellig ent). 
Les mécanismes spécifi és dans la partie A du présent appendice s'appliquent si au moins l'un des compo sants du 
tach ygraphe concer né par une authentifi cation mutuelle et/ou le processus de transfe rt des données est de première 
génération. 26.5.2016 L 139/340 Jour nal officiel de l'Union européenne FR     
Les mécanismes spécifi és dans la partie B du présent appendice s'appliquent si les deux compo sants concer nés par une 
authentification mutuelle et/ou le processus de transfer t des données sont de deuxième génération. 
L'appendice 15 fournit davant age d'inf ormations à propos de l'utilisation des compo sants de première génération avec 
ceux de deuxième génération. 
PARTIE A 
TACHY GRAPHE DE PREMIÈRE GÉNÉRA TION 
1.  INTR ODUCTION 
1.1.  Référence s 
Le présent appendice fait référen ce aux documents suivants: 
SHA-1  National Institute of Standards and Technology (NIST). FIPS Publication 180-1: Secure Hash 
Standar d. Avril 1995. 
PKCS1  RSA Laborator ies. PKCS # 1: RSA Encr yption Standar d. Version 2.0. Octobre 1998. 
TDES  National Institute of Standards and Technology (NIST). FIPS Publication 46-3: Data Encr yption 
Standar d. Projet 1999. 
TDES-OP  ANSI X9.52, Triple Data Encr yption Algor ithm Modes of Operation. 1998. 
ISO/CEI 7816-4  Techn ologies de l'information — Cartes d'identif ication — Cartes à circuit(s) intégré(s) à 
contacts — Partie 4: commandes intersector ielles pour les échang es. Première édition: 
1995 + Amendement 1: 1997. 
ISO/CEI 7816-6  Techn ologies de l'information — Cartes d'identif ication — Cartes à circuit(s) intégré(s) à 
contacts — Partie 6: éléments de données inter sectori elles. Première édition: 1996 + Cor 1: 
1998. 
ISO/CEI 7816-8  Techn ologies de l'information — Cartes d'identif ication — Cartes à circuit(s) intégré(s) à 
contacts — Partie 8: commandes intersect orielles de sécur ité. Première édition: 1999. 
ISO/CEI 9796-2  Techn ologies de l'information — Techniques de sécur ité — Schémas de signature numér ique 
rétablissant le message — Partie 2: mécanismes utilisant une fonction de hachag e. Première 
édition: 1997. 
ISO/CEI 9798-3  Techn ologies de l'information — Techniques de sécur ité — Mécanismes d'authentifi cation 
d'entité — Partie 3: authentific ation d'entité utilisant un algor ithme à clé publique. Seconde 
édition: 1998. 
ISO 16844-3  Véhicules routiers — Systèmes tach ygraphiques — Partie 3: Interface de capt eur de 
mouvement. 
1.2.  Notations et abréviations 
Les notations et abréviations qui suivent apparaissent dans le présent appendice: 
(Ka, Kb, Kc)  Faisceau de clés destiné au triple algor ithme de cryptage des données 
CA  Organisme de certification 
CAR  Références de l'orga nisme de certification 
CC  Total de contrôle cryptographique 
CG  Cryptogramme 
CH  En-tête de commande 
CHA  Autorisation d'un titulaire de certificat 
CHR  Références d'un titulaire de certificat 
D()  Décr yptage avec DES (Data Encr yption Standard) 26.5.2016 L 139/341 Jour nal officiel de l'Union européenne FR     
DE  Élément de données 
DO  Objet de données 
d  Clé privée — Exposant privé RSA 
e  Clé publique — Exposant public RSA 
E()  cryptag e avec DES 
EQT  Équipement 
Hash()  Valeur de hachag e, en tant que sortie de Hash 
Hash  Fonction Hash 
KID  Identif icateur de clé 
Km  Clé TDES. Clé maîtresse définie dans ISO 16844-3 
KmVU  Clé TDES insérée dans les unités embarquées sur le véhicule 
KmWC  Clé TDES insérée dans les cartes d'ateliers 
m  Représentant de message, nombre entier compris entre 0 et n-1 
n  Clés RSA , modulo 
PB  Octets de rem plissage 
PI  Octet indicateur de remplissag e (emplo yé dans les cryptogrammes destinés aux instr uctions 
DO de confidentialité) 
PV  Valeur ordinaire 
s  Représentant de signature, nombre entier compris entre 0 et n-1 
SSC  Comp teur de séquences d'émission 
SM  Messageri e sécur isée 
TCBC  Mode d'exploitation par chaînage de blocs de données cryptées TDEA 
TDEA  Triple algor ithme d'crypta ge des données 
TLV  Longueur des marqueurs 
VU  Unit é embarquée sur le véhicule 
X.C  Certificat de l'utilisat eur X, émis par un organisme de certification 
X.CA  Organisme de certification de l'utilisat eur X 
X.CA .PK o X.C  Opération de dévoi lement d'un certificat pour en extraire une clé publique. Il s'agit d'un 
opérateur infixe dont l'opérande de gauche correspond à la clé publique d'un organisme de 
certificat ion et l'opérande de droite au certificat émis par ce même organisme. Nous obtenons 
en résultat la clé publique de l'utilisateur X, dont le certificat est l'opérande de droite. 
X.PK  Clé publique RSA d'un utilisateur X 
X.PK[I]  cryptag e RSA de certaines informations I, à l'aide de la clé publique de l'utilisateur X 
X.SK  Clé privée RSA d'un utilisateur X 
X.SK[I]  cryptag e RSA de certaines informations I, à l'aide de la clé privée de l'utilisat eur X 
‘xx’  Valeur hexadécimale 
||  Opérateur de concat énation 26.5.2016 L 139/342 Jour nal officiel de l'Union européenne FR     
2.  SYST ÈMES ET ALGORIT HMES CRYPTOGRAPHIQUES 
2.1.  Syst èmes cryptog raphiques 
CSM_001  Les unité s embarquées sur véhicule et les cartes tach ygraphiques auront recours à un système 
cryptographique classique à clé publique RSA pour assurer les mécanismes de sécur ité suivants: 
—  Authentifi cation mutuelle entre unités embarquées sur véhicule et cartes tach ygraphiques. 
—  Acheminement des clés triples de session DES (Data Encr yption Standard) entre unités 
embarquées sur véhicule et cartes tach ygraphiques. 
—  Signature numér ique des données téléc hargées sur des suppor ts externes à partir d'unités sur 
véhicule ou de cartes tach ygraphiques. 
CSM_002  Les unité s embarquées sur véhicule et les cartes tach ygraphiques auront recours à un système 
cryptographique symétr ique DES triple pour assurer un mécanisme garantissant l'intégri té des 
données lors des échang es de données utilisate ur entre les unité s embarquées sur véhicule et les 
cartes tach ygraphiques et pour assurer , le cas échéant, la confidentialité des échang es de données 
entre les unité s embarquées sur véhicule et les cartes tach ygraphiques. 
2.2.  Algor ithmes cryptog raphiques 
2.2.1  Algor ithme RSA 
CSM_003  L'algor ithme RSA est parfaite ment défini par les relations suivantes: 
X.SK[m] = s = md mod n 
X.PK[s] = m = se mod n  
Pour une descr iption plus détaillée de la fonction RSA, repor tez-v ous au document de référence 
[PKCS1]. L'exposant public, e, pour les calculs de RSA est un nombre entier compris entre 3 et n-1 
et tel que gcd[e, lcm(p-1, q-1)] = 1. 
2.2.2  Algor ithme de hachage 
CSM_004  Les mécanismes de signature numér ique auront recours à l'algor ithme de hachag e SHA-1 tel qu'il 
est défini dans le document de référence [SHA-1]. 
2.2.3  Algor ithme de cryptage des données 
CSM_005  Des algor ithmes DES seront utilisés en mode chaînag e de blocs de données cryptées. 
3.  CLÉS ET CER TIFIC ATS 
3.1.  Génération et distribution de clés 
3.1.1  Génér ation et distr ibution de clés RSA 
CSM_006  Des clés RSA seront générées à trois niveaux hiérarchiques fonctionnels: 
—  niveau européen, 
—  niveau État membre, 
—  niveau équipement. 26.5.2016 L 139/343 Jour nal officiel de l'Union européenne FR     
CSM_007  Au niveau européen, une seule paire de clés européenne (EUR.SK et EUR.PK) sera générée. La clé 
privée européenne permettra d'homologuer les clés publiques des États membres. Des registres de 
l'ensemble des clés certifiées seront conser vés. Ces tâch es seront exécutées par un orga nisme de 
certification européen, placé sous l'autorité et la responsabilité de la Commission européenne. 
CSM_008  Au niveau État membre, une paire de clés par État membre (MS.SK et MS.PK) sera générée. Les clés 
publiques des États membres seront homologuées par l'orga nisme de certificat ion européen. La clé 
privée de l'État membre permettra d'homologuer les clés publiques à introduire dans l'équipement 
(unité embarquée sur le véhicule ou carte tach ygraphique). Des registres de l'ensemble des clés 
publiques certifiées seront conser vés avec les données d'identif ication de l'équipement auquel elles 
sont destinées. Ces tâches seront exécut ées par un organisme de certification national. Tout État 
membre est habilit é à chang er régulièrement de paire de clés. 
CSM_009  Au niveau équipement, une seule paire de clés (EQT .SK et EQT .PK) sera générée et introduite dans 
chaque équipement. Les clés publiques d'équipement seront homologuées par un organisme de 
certification national. Ces tâches seront exécut ées par les fabricants d'équipements, personnali ­
sateurs d'équipement ou autori tés compét entes à l'échelon national. Cette paire de clés sera utilisée 
par les services d'authentif ication, de signature numér ique et de cryptage. 
CSM_010  La conf identialit é des clés privées doit être préser vée durant leur génération, leur achem inement 
(éventuel) et leur archiv age. 
Le schém a fonctionnel qui suit représente une synthèse du cheminement des données caract érisant 
ce processus: 
26.5.2016 L 139/344 Jour nal officiel de l'Union européenne FR     
3.1.2  Clés de contrôle RSA 
CSM_011  Aux fins d'essai des équipements (essais d'inter opérabilité inclus), l'organ isme de certificat ion 
européen générera une paire de clés de contrôle européenne distincte et deux paires de clés de 
contrôle nationales au moins, dont les clés publiques seront homologuées conjointement avec la 
clé de contrôle privée européenne. Les fabricants introduiront, dans les équipements en cours de 
certification de type, des clés de test certifiées par l'une des clés de test nationales. 
3.1.3  Clés du capteur de mouv ement 
La confidentialité des trois clés triple DES décr ites ci-après est prot égée de manière appropr iée au cours de la 
génération, du transpor t (le cas échéant) et du stoc kage. 
Afin de permettre l'utilisation de compo sants de tach ygraphes conf ormes à la norme ISO 16844, l'aut orité de 
certification européenne et les organismes de certification de l'État membre veilleront également aux aspects 
suivants: 
CSM_036  L'organisme de certificat ion européen génère les clés KmVU et KmW C, deux clés triple 
DES uniques et indépendantes, ainsi que la clé Km selon la formule:  Km = KmVU XOR KmWC  . 
L'organisme de certification européen transmet ces clés, selon les procédures sécur isées 
appropr iées, aux organismes de certificat ion des États membres qui en font la demande. 
CSM_037  Les organismes de certification des États membres: 
—  utilisent la clé Km pour chiffrer les données du capt eur de mouvement demandées par les 
fabricants des capt eurs de mouvement (les données à chiffrer avec la clé Km sont définies par la 
norme ISO 16844-3), 
—  transmette nt la clé KmVU aux fabricants d'unités embarquées sur le véhicule, selon les 
procédures sécur isées appropr iées, afin qu'elles soient insérées dans les VU, 
—  veillent à ce que la clé KmWC soit insérée dans tout es les cartes d'atelier 
(
 dans le fichier élémentaire 
 ) 
lors de la personnalisation de la carte. 
3.1.4  Génér ation et distr ibution de clés de session T-DES 
CSM_012  Lors de leur processus d'authentifi cation mutuelle, les unités embarquées sur véhicule et les cartes 
tach ygraphiques généreront et échangeront les données nécessaires à l'élaboration d'une clé de 
session T-DES commune. La conf identialit é de cet échange de données sera préser vée par un 
mécanisme de cryptage RSA. 
CSM_013  Cette clé sera utilisée lors de tout es les opérations cryptographi ques ultérieures, en faisant appel à la 
message rie sécur isée. Sa validité expirera à la fin de la session (retrait ou réinitialisation de la carte) 
et/ou après 240 usages (définition d'un usage de la clé: l'env oi d'une commande recourant à la 
message rie sécur isée vers la carte appropr iée et la réponse associée à cet envoi). 
3.2.  Clés 
CSM_014  Les clés RSA ont les longueurs suivantes (indépendamment de leur niveau): modulo n 1 024 bits, 
exposant public e 64 bits maximum, exposant privé d 1 024 bits. 
CSM_015  Les T-DES prendront la forme (Ka, Kb, Ka), où Ka et Kb sont des clés indépendant es de 64 bits de 
long. Aucun bit de détection d'erreur de parité ne doit être établi. 
3.3.  Cer tificats 
CSM_016  Les certificat s associés aux clés publiques RSA seront du type «non self-descr iptive» et «card 
verifiable» (Réf.: ISO/CEI 7816-8). 26.5.2016 L 139/345 Jour nal officiel de l'Union européenne FR     
3.3.1  Contenu des certificats 
CSM_017  Les certificats associés aux clés publiques RSA compo rtent les données ci-après dans l'ordre suivant : 
Données Format Octet s Obser vations 
CPI ENTIER  1 Identificateur de prof il du certificat (‘01’ pour cette version) 
CAR CHAÎNE D'OC ­
TETS  8 Références de l'organisme de certificat ion 
CHA CHAÎNE D'OC ­
TETS  7 Autorisation d'un titulaire de certificat 
EOV TimeReal  4 Expiration du certificat. Optionnel , ‘FF’ compl été par des octets de 
rem plissage en cas de non-utilisation. 
CHR CHAÎNE D'OC ­
TETS  8 Références d'un titulaire de certificat 
n CHAÎNE D'OC ­
TETS  128 Clé publique (module) 
e CHAÎNE D'OC ­
TETS  8 Clé publique (exposant public)   
164   
Remarques: 
1.  «L'Identificateur de profil du certificat » (CPI) déter mine la structure précise d'un certificat d'authentif ication. 
Il fait office d'identif icateur intern e d'équipement au sein d'une liste en-tête appropr iée qui décr it la concaté ­
nation des éléments de données que compo rte le certificat. 
La liste en-tête associée au cont enu de ce certificat se présent e comme suit: 
‘4D’ ‘16’ ‘5F 29’ ‘01’ ‘42’ ‘08’ ‘5F 4B’ ‘07’ ‘5F 24’ ‘04’ ‘5F 20’ ‘08’ ‘7F 49’ ‘05’ ‘81’ ‘81 80’ ‘82’ ‘08’ Balise de liste en-tête étendue 
Longueur de la liste en-tête 
Balise CPI 
Longueur CPI 
Balise CAR 
Longueur CAR 
Balise CHA 
Longueur CHA 
Balise EOV 
Longueur EOV 
Balise CHR 
Longueur CHR 
Balise de clé publique (construite) 
Longueur des objets de données ultérieurs 
Balise module 
Longueur module 
Balise exposant public 
Longueur exposant public    
2.  Les «Références de l'organ isme de certificat ion» (CAR) permettent d'identif ier l'organ isme de certification 
émetteur du certificat de telle manière que l'élément de données puisse faire simultanément office d'identif i­
cateur de clé d'autorité renv oyant à la clé publique de l'organ isme de certification (pour plus d'inf ormations 
concer nant le codage, repor tez-v ous à l'Identifi cateur de clé ci-après). 26.5.2016 L 139/346 Jour nal officiel de l'Union européenne FR     
3.  «L'Aut orisation du titulaire de certificat» (CHA) permet d'identif ier les droits du titulaire de certificat. Elle se 
compo se de l'ID d'application du tach ygraphe et du type d'équipement auquel est destiné le certificat 
considéré (en fonction de l'élément de données 
 , ‘00’ pour un État membre). 
4.  La «Référence du titulaire de certificat » (CHR) permet d'identif ier excl usivement le titulaire de certificat de 
telle manière que l'élément de données puisse faire simultanément office d'identificateur de clé de sujet 
renv oyant à la clé publique du titulaire de certificat. 
5.  Les identif icate urs de clé identif ient uniquement les titulaires de certificat ou les organismes de certification. 
Ils sont codés comme suit:  
5.1. Équipement (VU ou carte): 
Données Numéro de série de 
l'équipement Date Type Fabric ant 
Longueur 4 octets 2 octets 1 octet 1 octet 
Valeur Entier Codage DCB mm 
aa Caractéri stiques du 
fabr icant Code du fabricant  
S'il s'agit d'une VU, le fabricant est suscept ible, lors de la demande de certificats, de connaître ou non 
les données d'identification de l'équipement au sein duquel les clés seront introduites. 
Dans le premier cas de figure, le fabr icant enverra les données d'identif ication de l'équipement 
accompagnées de la clé publique à l'organ isme de certification national compét ent. Le certificat 
contiendra alors les données d'identif ication de l'équipement concer né. Le fabricant devra veiller à ce 
que les clés et le certificat appropr iés soient introduits dans l'équipement voulu. L'Identif icateur de clé 
se présent e sous la forme indiquée ci-avant. 
Dans le second cas de figure, le fabricant doit identifier individuellement chaque demande de certificat 
et envoyer les données d'identif ication correspondant es accompagnées de la clé publique à l'orga nisme 
de certification national compét ent. Le certificat contiendra alors les données d'identif ication de la 
demande de certificat concer née. Le fabricant doit communiquer en retour à l'organ isme de certifi­
cation national compét ent les données d'aff ectation des clés à l'équipement concer né (c.-à-d., les 
données d'identif ication de la demande de certificat et d'identif ication de l'équipement visé) après leur 
installation sur cet équipement. L'Identif icateur de clé se présent e sous la forme indiquée ci-après: 
Données Numéro de série de 
la demande de cer­
tificat Date Type Fabric ant 
Longueur 4 octets 2 octets 1 octet 1 octet 
Valeur Entier Codage DCB mm 
aa 'FF' Code du fabricant   
5.2 Organisme de certification: 
Données Identif ication de 
l'organisme Numéro de série de 
la clé Informations 
complémentaires Identificateur 
Longueur 4 octets 1 octet 2 octets 1 octet 26.5.2016 L 139/347 Jour nal officiel de l'Union européenne FR     
Valeur Code numér ique 
national sur un oc­
tet 
Code alphanumé ­
rique national sur 
trois octets Entier codage additionnel 
(propre à la CA) 
′FF FF′ en cas de 
non-utilisation ‘01’  
Le numéro de série d'une clé permet de faire la distinction entre les différ entes clés d'un État membre, 
en cas de changement de clé. 
6.  Les vérificateurs de certificat sauront implicitement que la clé publique certifiée est une clé RSA propre à 
l'authentification, à la vérification et au crypta ge de signatures numér iques aux fins de conf identialit é (le 
certificat ne contient aucun Identificateur d'objet permettant de le préciser). 
3.3.2  Certificats émis 
CSM_018  Le certificat émis se présent e comme une signature numér ique assor tie d'une récupération partielle 
du contenu du certificat en conf ormité avec la norme ISO/CEI 9796-2 (annexe A.4 non compr ise), 
les «Références de l'organisme de certification» clôturant le certificat. 
X.C = X.CA .SK[‘6A ’ || Cr || Hash(Cc) || ‘BC’] || Cn || X.CAR  
Avec cont enu de certificat = Cc = Cr || Cn  
106 octets  58 octets  
Remarques: 
1.  Ce certificat compo rte 194 octets. 
2.  Les CAR, masquées par la signature, s'ajout ent également à cette dernière, afin que la clé publique de 
l'organ isme de certification puisse être sélectionnée pour procéder à la vérification du certificat. 
3.  Le vérificateur du certificat connaîtra implicit ement l'algor ithme employé par l'organ isme de certificat ion 
pour signer le certificat . 
4.  La liste en-tête associée à ce certificat émis se présent e comme suit: 
‘7F 21’ ‘09’ ‘5F 37’ ‘81 80’ ‘5F 38’ ‘3A’ ‘42’ ‘08’ Balise certificat CV (construite) 
Longueur des objets de données ultérieurs 
Balise signature 
Longueur signature 
Balise solde 
Longueur solde 
Balise CAR 
Longueur CAR   26.5.2016 L 139/348 Jour nal officiel de l'Union européenne FR     
3.3.3  Vérification et dévoilement des certificats 
La vérification et le dévoilement des certificats consistent à vérifier la signature conf ormément à la norme ISO/ 
CEI 9796-2, à extraire le cont enu du certificat et la clé publique qu'il contient : X.PK = X.CA .PK o X.C, et à 
vérifier la validité du certificat . 
CSM_019  Cette procédure compo rte les opérations suivantes : 
Vérification de la signature et extraction du cont enu: 
—  À partir de X.C, extraire la Sign., Cn' et 
CAR': X.C = Sign || Cn' || CAR'   
128 octets  58 octets  8 octets  
—  À partir de CAR′, sélectionner la clé publique de l'organisme de certification appropr ié (dans 
l'éventualit é où cette opération n'aurait pas été exécut ée par d'autres moyens). 
—  Ouvr ir Sign avec la clé publique de la CA: Sr'= X.CA .PK [Sign]. 
—  S'assurer que le Sr′ commence par ‘6A’ et se term ine par ′BC′. 
—  Calculer Cr' et H' d'après: Sr' = ‘6A’ || Cr' || H' || ‘BC’    
106 octets  20 octets    
—  Récupérer le cont enu du certificat C' = Cr' || Cn', 
—  Vérifier Hash(C') = H'. 
Si les vérifications sont concluant es, le certificat est un original et son contenu est C'. 
Vérifier la validité. À partir de C': 
—  Contrôler , le cas échéant, la date d'expiration. 
Extraire et mémor iser la clé publique, l'identifi cateur de clé, l'aut orisation du titulaire de certificat et 
la date d'expiration du certificat à partir du certificat C': 
—  X.PK = n || e 
—  X.KID = CHR 
—  X.CHA = CHA 
—  X.EO V = EOV 
4.  MÉCANISME D'AUTHENTIFICA TION MUTUELLE 
L'authentificati on mutuelle entre les cartes et les VU repose sur le principe suivant : 
Chacune des parties doit démontrer à l'autre qu'elle possède une paire de clés valides, la clé publique qui aura 
permis leur homolog ation par l'organ isme de certification national compét ent étant elle-même homologuée 
par l'organ isme de certificat ion européen. 
Cette démonstration consiste à signer avec la clé privée un nombre aléatoi re envoyé par l'autre partie, laquelle 
doit récupérer , lors de la vérification de cette signature, le nombre aléatoi re préalablement envoyé. 
La VU concer née déclenche le mécanisme d'authentific ation dès l'inser tion de la carte. La procédure 
commence par l'échange des certificats et le dévoi lement des clés publiques; elle prend fin avec la définition 
d'une clé de session. 26.5.2016 L 139/349 Jour nal officiel de l'Union européenne FR     
CSM_020  Le protocole ci-après sera utilisé [les flèches indiquent les commandes et données échang ées (voir 
appendice 2)]: 
26.5.2016 L 139/350 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/351 Jour nal officiel de l'Union européenne FR     
5.  MÉCANISMES DE CONFIDENTIALITÉ, D'INTÉGRITÉ ET D'AUTHENTIFIC ATION DES DONNÉES TRANSFÉRÉES ENTRE 
LES VU ET LES CARTES 
5.1.  Messager ie sécur isée 
CSM_021  L'intégri té des transfer ts de données entre les VU et les cartes sera préser vée par un dispositif de 
message rie sécur isée, en conf ormité avec les normes de référen ce [ISO/CEI 7816-4] et [ISO/CEI 
7816-8]. 
CSM_022  Si la prot ection de données s'im pose pendant leur transfer t, le système adjoindra un objet de 
données du type total de contrôle cryptographique aux objets de données transmis dans la 
commande ou la réponse. Le récep teur procédera à une vérification du total de contrôle cryptogra ­
phique. 
CSM_023  Le total de contrôle cryptographi que des données transmises dans une commande intégrera l'en- 
tête de cette commande ainsi que la totali té des objets de données envoyés (= > CLA = ‘0C’, et tous 
les objets de données seront encapsulés dans des balises au sein desquelles b1=1). 
CSM_024 Les octets d'état/inf ormation transmis en réponse seront prot égés par un total de contrôle crypto­
graphique si cette réponse ne compo rte aucun champ de données. 
CSM_025  Les totaux de contrôle cryptographiques mesureront 4 octets de long. 
Par conséquent, en cas de recours à la message rie sécur isée, les commandes et réponses présent ent 
la structure suivante: 
Les instr uctions DO utilisées représentent un jeu partiel des DO de messager ie sécur isée décr ites 
dans les dispositions de la norme ISO/CEI 7816-4: 
Balise Mnémonique Signification 
‘81’ TPV Valeur simple non codée en BER -TLV (à prot éger par CC) 
‘97’ TLE Valeur de Le dans la commande non sécur isée (à protég er par CC) 
‘99’ TSW Infos d'état (à proté ger par CC) 
‘8E’ TCC Total de contrôle cryptographi que 
‘87’ TPI CG Octe t indicateur de remplissag e || Cryptogramme (valeur simple non 
codée en BER -TLV)  
Étant donné une paire de réponses à une commande non sécur isée: 
En-tête de commande Corps de la commande 
CLA INS P1 P2 [champ Lc ] [champ de don ­
nées] [cham p Le ] 
quatre octets Octets L, indiquant B1 à BL  
Corps de la réponse En queue de réponse 
[champ de données] SW1 SW2 
Octet s de données Lr deux octets  26.5.2016 L 139/352 Jour nal officiel de l'Union européenne FR     
La paire correspondante de réponses à une commande sécur isée se présent e comme suit: 
Commande sécur isée: 
En-tête de commande 
(CH) Corps de la commande 
CLA INS P1 P2 [nouveau 
champ Lc] [nouveau champ de données] [nou ­
veau 
champ 
Le] 
‘OC’ Longueur du 
nouveau cham p 
de données TPV LPV PV TLE LLE Le TCC LCC CC ‘00’ 
‘81’ Lc Champ 
de don ­
nées ‘97’ ‘01’ Le ‘8E’ ‘04’ CC  
Données à intégrer au total de contrôle = CH || PB || TPV || LPV || PV || TLE || LLE || Le || PB 
PB = Octet s de rem plissage (80.. 00) en conf ormité avec les normes ISO-CEI 7816-4 et ISO 9797 
méthode 2. 
Les PV et LE des DO ne sont présents que si la commande non sécur isée compo rte un certain 
nombre de données correspondantes. 
Réponse sécur isée:  
1. Cas où le champ de données de la réponse n'est pas vide et ne nécessite aucune prot ection aux 
fins de confidentialité: 
Corps de la réponse En queue de réponse 
[nouveau cham p de données] Nouveau SW1 SW2 
TPV LPV PV TCC LCC CC  
‘81’ Lr Champ de don ­
nées ‘8E’ ‘04’ CC  
Données à intégrer dans le total de contrôle = TPV || LPV || PV || PB  
2. Cas où le champ de données de la réponse n'est pas vide, mais nécessite une protection 
garantissant sa confidentialité: 
Corps de la réponse En queue de réponse 
[nouveau cham p de données] Nouveau SW1 SW2 
TPI CG LPI CG PI CG TCC LCC CC  
‘87’  PI || CG ‘8E’ ‘04’ CC  
Données à transfér er par CG: données non codées BER -TLV et octets de rem plissage. 
Données à intégrer dans le total de contrôle = TPI CG || LPI CG || PI CG || PB 26.5.2016 L 139/353 Jour nal officiel de l'Union européenne FR     
3. Cas où le cham p de données de la réponse est vide: 
Corps de la réponse En queue de réponse 
[nouveau cham p de données] Nouveau SW1 SW2 
TSW LSW SW TCC LCC CC  
‘99’ ‘02’ Nouveaux SW1 
et SW2 ‘8E’ ‘04’ CC  
Données à intégrer dans le total de contrôle = TSW || LSW || SW || PB 
5.2.  Traitement des erreurs de messager ie sécur isée 
CSM_026  Si la carte tach ygraphique reconnaît une erreur SM lors de l'inter prétation d'une commande, les 
octets d'état doivent être renv oyés sans MS. Conf ormément à la norme ISO/CEI 7816-4, les octets 
d'état suivants sont définis pour indiquer la manifestation d'erreurs de SM: 
‘66 88’:  Échec de la vérification du tota l de contrôle cryptographi que, 
‘69 87’:  Absence d'objets de données SM prévus, 
‘69 88’:  Objets de données SM incor rects. 
CSM_027  Si la carte tach ygraphique renv oie des octets d'état sans DO SM ou avec une DO SM erronée, la VU 
doit mettre fin à la session en cours. 
5.3.  Algor ithme de calcul des totaux de contrôle cryptog raphiques 
CSM_028  La constitution des totaux de contrôle cryptographiques se fait à l'aide des contrôles d'accès au 
suppor t (MA C) détaillés, en conf ormité avec la norme ANSI X9.19 à l'aide de DES: 
—  Phase initiale: le bloc de contrôle y0 est E(Ka, SSC). 
—  Phase séquentielle: les blocs de contrôle y1, .., yn se calculent à l'aide de Ka. 
—  Phase finale: le total de contrôle cryptographique se calcule à partir du dernier bloc de contrôle 
yn en procédant comme suit: E(Ka, D(Kb, yn)). 
Où l'abréviation E() signif ie le cryptage avec DES et l'abréviation D() le décr yptage avec DES. 
Les quatre octets les plus significatif s du tota l de contrôle cryptographi que sont transférés. 
CSM_029  Le comp teur de séquences à l'émission (SSC) sera lancé pendant la procédure d'acceptation des clés: 
SSC initial: Rnd3 (4 derniers octets signif icatifs) || Rnd1 (4 derniers octets significatifs). 
CSM_030  Le comp teur de séquences à l'émission sera incrément é d'une unité avant le calcul de chaque MAC 
(en d'autres termes, le SSC associé à la première commande correspond au SSC initial + 1, tandis 
que le SSC associé à la première réponse correspond au SSC initial + 2). 26.5.2016 L 139/354 Jour nal officiel de l'Union européenne FR     
La figure ci-après illustre le calcul du MAC détaillé: 
5.4.  Algor ithme de calcul des cryptogrammes destinés aux instr uctions DO de conf identialité 
CSM_031  Ces cryptogramme s se calculent à l'aide du TDEA en mode d'exploitation TCBC, en conf ormité 
avec les [TDES] et [TDES-OP] de référence et avec le vect eur nul comme bloc de valeur initial. 
La figure qui suit illustre l'application des clés en TDES: 
6.  MÉCANISMES DE SIGNA TURE NUMÉRIQUE DES TÉLÉCHAR GEMENTS DE DONNÉES 
CSM_032  L'équipement spécialisé intelligent (IDE) enregistre au sein d'un fichier de données physiques les 
données transmises à partir d'un équipement (VU ou carte) donné, pendant une session de téléc har­
gement. Ce fichier doit conteni r les certificats MSi.C et EQT .C. Le fichier contient les signatures 
numér iques associées de blocs de données conf ormément aux indications fournies dans l'appendice 
7 (Protoc oles de téléc hargement des données). 
CSM_033  Les signatures numér iques des données téléc hargées reposeront sur l'utilisation d'un schém a de 
signature numér ique avec appendice permettant, le cas éché ant, de lire des données téléc hargées 
sans aucun décr yptage. 
6.1.  Génération de signatures 
CSM_034  La génération de signatures de données par l'équipement respecter a le schéma de signature avec 
appendice, défini dans le document de référence [PKCS1] avec la fonction de hachag e SHA-1: 
Signature = EQT .SK[‘00’ || ‘01’ || PS || ‘00’ || DER(SHA-1(Data))] 26.5.2016 L 139/355 Jour nal officiel de l'Union européenne FR     
PS = Chaîne d'octets de rem plissage de valeur ‘FF’ dont la longueur équivaut à 128. 
DER(SHA-1(M)) correspond à l'encodage de l'ID de l'algor ithme pour la fonction de hachag e et la 
valeur de hach age, dans une valeur ASN.1 de type Dige stInf o (règles d'encodag e distincte s): 
‘30’||‘21’||‘30’||‘09’||‘06’||‘05’||‘2B’|‘0E’||‘03’||‘02’||‘1A ’||‘05’||‘00’||‘04’||‘14’||V aleur de hachag e 
6.2.  Vér ification de signatures 
CSM_035  La vérification de signatures de données, à laquelle sont soumises les données télécharg ées, 
respecter a le schéma de signature avec appendice, défini dans le document de référence [PKCS1] 
avec la fonction de hachag e SHA-1. 
Le vérificateur doit connaître (et approuver) la clé publique européenne EUR.PK. 
Le tableau qui suit illustre le protocole qu'un équipement IDE doté d'une carte de contrôle est 
susceptible de respecte r pour vérifier l'intégrité des données télécharg ées et enregistrées sur l'ESM 
(suppor t de mémoire externe). La carte de contrôle permet de procéder au décr yptage des 
signatures numér iques. Dans le cas présent, cette fonction n'est pas nécessairement implément ée au 
sein de l'IDE. 
L'équipement qui a participé au télécharg ement et à la signature des données à analyser est désigné 
par l'abréviation EQT . 
26.5.2016 L 139/356 Jour nal officiel de l'Union européenne FR     
PARTI E B 
TACHY GRAPHE DE DEUXIÈME GÉNÉRA TION 
7.  INTR ODUCTION 
7.1.  Référence s 
Le présent appendice fait référen ce aux références suivante s: 
AES  National Institute of Standards and Techn ology (NIST), FIPS PUB 197: Advanced Encr yption 
Standard, 26 novembre 2001 
DSS  National Institut e of Standards and Techn ology (NIST), FIPS PUB 186-4: Digital Signature 
Standard (DSS), juillet 2013 
ISO 7816-4  ISO/CEI 7816-4 Cartes d'identif ication — Cartes à circuit intégré — Partie 4 Org anisation, 
sécur ité et commandes pour les échang es. Troisième édition 2013-04-15 
ISO 7816-8  ISO/CEI 7816-8 Cartes d'identif ication — Cartes à circuit intégré — Partie 8 Commandes pour 
des opérations de sécur ité. Seconde édition: 2004-06-01 
ISO 8825-1  ISO/CEI 8825-1 Techn ologies de l'information — Règles de codage ASN.1: Spécification des 
règles de codag e de base (BER), des règles de codage canoniques (CER) et des règles de codag e 
distinctives (DER). Quatr ième édition, 2008-12-15 
ISO 9797-1 ISO/CEI 9797-1 Techn ologies de l'information — Techn iques de sécur ité — Codes d'authentifi ­
cation de messag e (MA C) — Partie 1: Mécanismes utilisant un cryptage par blocs. Seconde 
édition: 2011-03-01 
ISO 10116  ISO/CEI 10116,T echnologies de l'information — Techn iques de sécur ité — Modes opérat oires 
pour un cryptage par blocs de n bits. Troisième édition 2006-02-01 
ISO16844-3  ISO/CEI 16844-3 Véhicules routiers — Systèmes tach ygraphiques — Partie 3: Interface de 
capt eur de mouvement. Première édition 2004, compre nant le rectifi catif technique 1 2006 
RFC 5480  Informations relatives à la clé publique soumise à cryptographie à courbe elliptique, mars 2009 
RFC 5639  Cryptographie à courbe elliptique (ECC) — Génération de courbes et de courbes standard 
Brain pool, 2010 
RFC 5869  Fonction de dérivation de clé par extraction et expansion basée sur HMA C (HKDF), mai 2010 
SHS  National Institute of Standards and Technology (NIST), FIPS PUB 180-4: Nor me de hachag e 
sécur isé, mars 2012 
SP 800-38B National Institute of Standards and Technology (NIST), Special Publication 800-38B: Recomman ­
dation pour les modes d'exploitation de cryptage par blocs: Mode CMA C d'authentific ation, 
2005 
TR-03111  BSI Techn ical Guideline TR-03111, Cryptographie à courbe elliptique , version 2.00, 2012-06-28 
7.2.  Notations et abréviations 
Les notations et abréviations qui suivent apparaissent dans le présent appendice: 
AES  Nor me de cryptage avancé (Advanced Encr yption Standard) 
CA  Org anisme de certification 
CAR  Références de l'organ isme de certification 
CBC  Mode d'exploitation par chaînag e de blocs de données cryptées TDEA 26.5.2016 L 139/357 Jour nal officiel de l'Union européenne FR     
CH  En-tête de commande 
CHA  Autor isation d'un titulaire de certificat 
CHR  Références d'un titulaire de certificat 
CV  Vecteur constant 
DER  Règles de codag e distincte s 
DO  Objet de données 
DSR C  Communication dédiée de cour te portée 
ECC  Cryptographie à courbe elliptique 
ECDSA  Algor ithme de signature numér ique à courbe elliptiq ue 
ECDH  Courbe elliptique de Diff ie-Hellman (algor ithme de concordance de clé) 
EGF  Dispositif GNSS externe 
EQT  Équipement 
IDS  identificateur de service 
KM  Clé maîtresse du capt eur de mouvement permettant de coupler une unité embarquée sur 
véhicule avec un capt eur de mouvement 
KM-V U  Clé insérée dans les unités embarquées sur véhicule permettant à une VU d'extraire la clé 
maîtresse du capt eur de mouvement si une carte d'atelier est insérée dans la VU 
KM-W C  Clé insérée dans les cartes d'ate lier permettant à une VU d'extraire la clé maîtresse du capt eur de 
mouvement si une carte d'ateli er est insérée dans la VU 
MAC  Code d'authentifi cation du message 
MoS  Cap teur de mouvement 
MSB  Octe t le plus signif icatif 
PKI  Infrastr ucture à clé(s) publique(s) (ICP) ou infrastr ucture de gestion de clés (IGC) 
RCF  Équipement de communication à distance 
SSC  Com pteur de séquences d'émission 
MS  Message rie sécur isée 
TDES  Triple Data Encr yption Standard (nor me relative au cryptage triple des données) 
TLV  Longueur des marqueurs 
VU  Unité embarquée sur le véhicule 
X.C  Certificat de clé publique d'un utilisate ur X 
X.CA  Org anisme de certification qui a émis le certificat d'un utilisateur X 
X.CAR  Référence de l'organ isme de certificat ion mentionnée dans le certificat d'un utilisat eur X 
X.CHR  Référence du titulaire du certificat mentionné dans le certificat d'un utilisateur X 
X.PK  Clé publique d'un utilisateur X 
X.SK  Clé privée d'un utilisateur X 
X.PKeph  Clé publique éphémère d'un utilisateur X 
X.SKeph  Clé privée éphémère d'un utilisate ur X 
‘xx’  Valeur hexadécimale 
||  Opérateur de concaténation 26.5.2016 L 139/358 Jour nal officiel de l'Union européenne FR     
7.3.  Déf initions 
Les définitions des term es utilisés dans le présent appendice figurent à la section 1 de l'annexe 1C. 
8.  SYST ÈMES ET ALGORIT HMES CRYPTOGRAPHIQUES 
8.1.  Syst èmes cryptog raphiques 
CSM_38 Les unités embarquées sur véhicule et les cartes tach ygraphiques auront recours à un système crypto­
graphique classique à clé publique à courbe elliptique pour assurer les mécanismes de sécur ité 
suivants: 
—  authentif ication mutuelle entre une unité embarquée sur véhicule et une carte, 
—  concordance des clés de session AES entre une unité embarquée sur véhicule et une carte, 
—  assurer l'authenticit é, l'inté grité et la non- répudiation des données télécharg ées depuis les unités 
embarquées sur véhicule ou depuis les cartes tach ygraphiques vers un suppor t de stoc kage 
extern e. 
CSM_39  Les unités embarquées sur véhicule et les dispositifs GNSS exte rnes auront recours à un système 
cryptographique à clé publique à courbe ellip tique pour assurer les mécanismes de sécur ité suivants: 
—  couplage d'une unité embarquée sur véhicule et d'un dispositif GNSS externe, 
—  authentif ication mutuelle entre une unité embarquée sur véhicule et un dispositif GNSS externe, 
—  concordance d'une session de clé AES entre une unité embarquée sur véhicule et un dispositif 
GNSS extern e. 
CSM_40 Les unités embarquées sur véhicule et les cartes tach ygraphiques auront recours à un système crypto­
graphique AES symétr ique pour assurer les mécanismes de sécur ité suivants: 
—  assurer l'authenticité et l'inté grité des données écha ngées entre une unité embarquée sur véhicule 
et une carte tach ygraphique, 
—  le cas éché ant, assurer la conf identialit é des données échang ées entre une unité embarquée sur 
véhicule et une carte tach ygraphique. 
CSM_41  Les unités embarquées sur véhicule et les dispositifs GNSS exte rnes auront recours à un système 
cryptographique AES symétr ique pour assurer les mécanismes de sécur ité suivants: 
—  assurer l'authenticité et l'inté grité des données écha ngées entre une unité embarquée sur véhicule 
et un dispositif GNSS externe. 
CSM_42  Les unités embarquées sur véhicule et les capt eurs de mouvement auront recours à un système 
cryptographique AES symétr ique pour assurer les mécanismes de sécur ité suivants: 
—  couplage d'une unité embarquée sur véhicule et d'un capt eur de mouvement, 
—  authentif ication mutuelle entre une unité embarquée sur véhicule et un capt eur de mouvement, 
—  assurer la confidentialité des données échang ées entre une unité embarquée sur véhicule et un 
capt eur de mouvement. 
CSM_43 Les unités embarquées sur véhicule et les cartes de contrôle auront recours à un système cryptogra ­
phique AES symétr ique pour assurer les mécanismes de sécur ité suivants: 
—  assurer la conf identialit é, l'authenticit é et l'inté grité des données transmises par une unité 
embarquée sur véhicule à une carte de contrôle. 26.5.2016 L 139/359 Jour nal officiel de l'Union européenne FR     
Remar ques: 
—  Pour être précis, les données sont transmises par une unité embarquée sur véhicule vers un 
interr ogat eur distant sous le contrôle d'un agent de contrôle, qui se sert d'un dispositif de 
communication à distance interne ou externe à la VU; cf. appendice 14. Cependant, l'interro­
gateur distant adresse les données reçues à une carte de contrôle qui les déchiffre et valide leur 
authenticité. Du point de vue de la sécur ité, le dispositif de communication distant et l'inter ro­
gateur distant sont entièrement transparents. 
—  Une carte d'ateli er offre les mêmes services de sécur ité au regard de l'interface DSR C qu'une carte 
de contrôle. Cela permet à un atelier de valider le fonctionnement satisf aisant de l'inte rface de 
communication à distance d'une VU, y compris la sécur ité. Consult er la section 9.2.2 pour tout e 
information compl émentaire. 
8.2.  Algor ithmes cryptog raphiques 
8.2.1  Algor ithmes symétr iques 
CSM_44  Les unité s embarquées sur véhicule, cartes tach ygraphiques, capt eurs de mouvement et dispositifs 
GNSS extern es devront être compati bles avec l'algor ithme AES défini dans [AES] en respectant les 
longueurs de clés de 128, 192 et 256 bits. 
8.2.2  Algor ithmes asymétr iques et paramètres de domaine normalisés 
CSM_45  Les unités embarquées sur véhicule, cartes tach ygraphiques et dispositifs GNSS externes devront être 
compati bles avec la cryptographie à courbe ellip tique et respecter les longueurs de clés 
de 256, 384 et 512/521 bits. 
CSM_46  Les unités embarquées sur véhicule, cartes tach ygraphiques et dispositifs GNSS externes devront être 
compati bles avec l'algor ithme de signature ECDS A défini dans [DSS]. 
CSM_47  Les unités embarquées sur véhicule, cartes tach ygraphiques et dispositifs GNSS externes devront être 
compati bles avec l'algor ithme de concordance avec les clés ECKA-EG défini dans [TR 03111]. 
CSM_48  Les unités embarquées sur véhicule, cartes tach ygraphiques et dispositifs GNSS externes devront être 
compati bles avec tous les paramètres de domaines normalisés définis au Tableau 1 ci-après se 
rappor tant à la cryptographi e à courbe ellipt ique. 
Tableau 1 
Paramètres de domaines nor malisés 
Nom Tailles (en bits) Référence Identificateur d'objet 
NIST P-256 256 [DSS], [RFC 5480] 
Brain poolP256r1 256 [RFC 5639] 
NIST P-384 384 [DSS], [RFC 5480] 
Brain poolP384r1 384 [RFC 5639] 
Brain poolP512r1 512 [RFC 5639] 
NIST P-521 521 [DSS], [RFC 5480] 
Note: les identificateurs d'objet mentionnés dans la dernière colonne du Tableau 1 sont spécifiés dans 
[RFC 5639] pour les courbes Brainp ool et dans [RFC 5480] pour les courbes NIST . 
26.5.2016 L 139/360 Jour nal officiel de l'Union européenne FR     
8.2.3  Algor ithmes de hachag e 
CSM_49  Les unités embarquées sur véhicule et les cartes tach ygraphiques devront être compati bles avec les 
algor ithmes SHA-256, SHA-384 et SHA-512 définis dans [SHS]. 
8.2.4  Méthodes de cryptage 
CSM_50  Dans le cas où un algor ithme symétr ique, un algor ithme asymétr ique et/ou un algor ithme de 
hacha ge sont associés pour former un protocole de sécur ité, leur longueur de clé et taille de hacha ge 
respectives doivent être de force (quasiment) égale. Le Tableau 2 montre les méthodes de cryptag e 
autorisées: 
Tableau 2 
Méthodes de cryptage auto risées 
ID Suite cryptée Taille de clé ECC 
(en bits) Longueur de clé 
AES (en bits) Algor ithme de 
hachage Longueur MAC (en 
octets) 
CS#1 256 128 SHA-256 8 
CS#2 384 192 SHA-384 12 
CS#3 512/521 256 SHA-512 16  
Remar que: les tailles de clés ECC de 512 et 521 bits sont considérées de force égale quelle que soit 
leur utilisation dans le cadre du présent appendice. 
9.  CLÉS ET CER TIFIC ATS 
9.1.  Paires de clés asymétr iques et certificats de clé publique 
9.1.1  Génér alités 
Note: les clés décr ites dans cette section servent à l'authentification mutuelle et à la messager ie sécur isée entre 
les unités embarquées sur véhicule et les cartes tach ygraphiques, ainsi qu'entre les unités embarquées sur 
véhicule et les dispositifs GNSS extern es. Ces processus sont décr its en détail dans les chapit res 10 et 11 du 
présent appendice. 
CSM_51  Au sein du système de tach ygraphie intelligent e européenne, les paires de clés ECC et leurs certificats 
sont générés et gérés selon trois niveaux hiérarchiques fonctionnels: 
—  niveau européen, 
—  niveau État membre, 
—  niveau équipement. 26.5.2016 L 139/361 Jour nal officiel de l'Union européenne FR     
CSM_52  Au sein du système de tach ygraphie intellig ente européenne, les clés privées et publiques ainsi que 
les certificat s sont générés, gérés et communiqués au moyen de méthodes sécur isées et normalisées. 
9.1.2  Niveau européen 
CSM_53  Au niveau européen, il est généré une seule paire de clés ECC, appelées EUR. Elle se compose d'une 
clé privée (EUR.SK) et d'une clé publique (EUR.PK). Cette paire de clés forment la paire racine de la 
PKI de tach ygraphie intellig ente européenne. Ces tâches sont exécutées par une Autorité de certifi­
cation racine européenne (ERCA), placée sous l'aut orité et la responsabilité de la Commission 
européenne. 
CSM_54  L'ER CA utilise la clé privée européenne pour signer un certificat racine (auto signé) de la clé publique 
européenne et communique ce certificat racine européen à tous les États membres. 
CSM_55  L'ER CA utilise la clé privée européenne pour signer les certificats des clés publiques dans les États 
membres sur demande. L'ER CA conser ve les relevés de tous les certificats de clé publique signés 
délivrés aux États membres. 
CSM_56  Comme le montre la Figure 1 de la section 9.1.7, l'ERCA génère une nouvelle paire de clés racine 
européenne tous les 17 ans. Dès lors que l'ERCA génère une nouvelle paire de clés racine 
européenne, l'organ isme crée un nouveau certificat racine autosi gné destiné à la nouvelle clé 
publique européenne. La durée de validité d'un certificat racine européen est de 34 ans plus trois 
mois. 
Remar que: l'introduction d'une nouvelle paire de clés racine implique également que l'ERCA génère 
une nouvelle clé maîtresse pour le capt eur de mouvement et une nouvelle clé maîtresse DSR C; cf. 
sections 9.2.1.2 et 9.2.2.2. 
CSM_57  Avant de générer une nouvelle paire de clés racine européenne, l'ERCA mène une analyse de la force 
cryptographique nécessaire pour la nouvelle paire de clés, sachant qu'elle doit rester sécur isée 
pendant les 34 prochaines années. Si cela se révèle nécessaire, l'ERCA adop te une méthode de 
cryptage plus puissante que l'actuelle, comme le prévoi t CSM_50. 
CSM_58  Dès lors que l'ERCA génère une nouvelle paire de clés racine européenne, l'organ isme crée un 
nouveau certificat de lien destiné à la nouvelle clé publique européenne et le signe avec la clé privée 
européenne précédente . La durée de validité du certificat de lien est de 17 ans. La Figure 1 de la 
section 9.1.7 l'illustre également. 
Remar que: un certificat de lien contient la clé publique ERCA de génération X et il est signé avec la 
clé privée ERCA de génération X-1. Il offre donc à l'équipement de génération X-1, une méthode 
permettant de se fier à l'équipement de génération X. 
CSM_59  L'ER CA n'utilise pas la clé privée d'une paire de clés racine à d'autres fins après le début de validité 
d'un nouveau certificat de clé racine. 
CSM_60  À tout moment, l'ERCA doit disposer des clés et des certificat s cryptographi ques suivants: 
—  la paire de clés EUR en vigueur et le certificat correspondant, 
—  tous les certificats EUR antér ieurs à utiliser pour vérifier les certificats MSCA toujour s valides, 
—  les certificats de lien de tout es les générations de certificats EUR à l'excep tion du premier . 
9.1.3  Niveau État membre 
CSM_61 Au niveau de l'État membre, tous les États membres devant signer les certificats de carte tach ygra ­
phique génèrent une ou plusieurs paires de clés ECC unique, appelée MSCA_ Card. Tous les États 
membres devant signer les certificat s des unités embarquées sur véhicule ou des dispositifs GNSS 
exte rnes génèrent en plus une ou plusieurs paires de clés ECC unique, appelée MSCA_VU-EGF . 26.5.2016 L 139/362 Jour nal officiel de l'Union européenne FR     
CSM_62  La tâch e de la génération des paires de clés de l'État membre incombe à l'autorité de certification de 
l'État membre (MSCA) . Dès lors qu'une MSCA génère une paire de clés pour un État membre, elle 
doit adresser la clé publique à l'ERCA afin d'obten ir un certificat propre à l'État membre corres­
pondant, signé par l'ERCA. 
CSM_63  Une MSCA choisit la force de la paire de clés de l'État membre égale à celle de la paire de clés racine 
européenne servant à signer le certificat de l'État membre correspondant. 
CSM_64  Une paire de clés MSCA_VU-EGF , le cas éché ant, se compo se d'une clé privée MSCA_ VU-EGF .SK et 
d'une clé publique MSCA _VU-EGF .PK. Une MSCA utilise la clé privée MSCA_VU-EGF .SK excl usi­
vement pour signer les certificats de clé publique des unités embarquées sur véhicule et des 
dispositifs GNSS externes. 
CSM_65  Une paire de clés MSCA_Card se compo se d'une clé privée MSCA_Card.SK et d'une clé publique 
MSCA_Card.PK. Une MSCA utilise la clé privée MSCA _Card.SK excl usivement pour signer les 
certificats de clé publique des cartes tach ygraphiques. 
CSM_66  Une MSCA conser ve des archives de tous les certificats de VU signés, de tous les certificat s de 
dispositifs GNSS externes signés et de tous les certificats de cartes ainsi que l'identifi cation de 
l'équipement auquel est destiné chacun de ces certificats. 
CSM_67  La durée de validité d'un certificat MSCA_ VU-EGF est de 17 ans plus trois mois. La durée de validité 
d'un certificat MSCA_ Card est de 7 ans plus un mois. 
CSM_68  Comme l'illustre la Figure 1 à la section 9.1.7, la clé privée d'une paire de clés MSCA_ VU-EGF et la 
clé privée d'une paire de clé MSCA_ Card possèdent une durée d'utilisation de deux années. 
CSM_69  Une MSCA n'utilise pas la clé privée d'une paire de clés MSCA_VU-EGF à quelque fin que ce soit 
après l'expiration de sa période d'utilisation. De même, une MSCA n'utilise pas la clé privée d'une 
paire de clés MSCA_ Card à quelque fin que ce soit après l'expiration de sa période d'utilisation. 
CSM_70  À tout moment, une MSCA doit disposer des clés et des certificats cryptographiques suivants: 
—  la paire de clés MSCA _Card en vigueur et le certificat correspondant, 
—tous les certificats MSCA_ Card antér ieurs à utiliser pour vérifier les certificats des cartes tach ygra ­
phiques toujours valides, 
—  le certificat EUR en vigueur nécessaire pour vérifier le certificat MSCA en vigueur , 
—  tous les certificats EUR antérieurs nécessaires pour vérifier tous les certificat s MSCA touj ours 
valides. 
CSM_71  Si une MSCA doit signer des certificats pour des unités embarquées sur véhicule ou pour des 
dispositifs GNSS externes, la MSCA doit également avoir à disposition les clés et certificats suivants: 
—  la paire de clés MSCA _VU-EGF en vigueur et le certificat correspondant, 
—  tout es les clés publiques MSCA_VU-EGF antérieures à utiliser pour vérifier les certificat s des VU 
ou des dispositifs GNSS exte rnes toujours valides. 
9.1.4  Niveau équipement: unités embar quées sur véhic ule 
CSM_72  Deux paires de clés ECC uniques sont générées pour chaque unité embarquée sur véhicule, appelées 
VU_MA et VU_Sign. Cette tâche incombe aux fabricants de VU. Dès lors qu'une paire de clés VU est 
générée, la partie qui la génère doit adresser la clé publique à la MSCA de son pays de résidence afin 
d'obten ir un certificat VU correspondant, signé par la MSCA . La clé privée sert uniquement à une 
unité embarquée sur véhicule. 26.5.2016 L 139/363 Jour nal officiel de l'Union européenne FR     
CSM_73  Les certificat s VU_MA et VU_Sign attribués à une unité embarquée sur véhicule donnée possèdent la 
même date d'entrée en vigueur de certificat. 
CSM_74  Un fabr icant de VU choisit la force d'une paire de clés VU égale à celle de la paire de clés MSCA 
servant à signer le certificat VU correspondant. 
CSM_75  Une unité embarquée sur véhicule utilise sa paire de clés VU_MA, compo sée d'une clé privée 
VU_MA.SK et d'une clé publique VU_MA. PK, exclusivement pour effectuer des opérations d'authenti ­
fication de VU avec les cartes tach ygraphiques et les dispositifs GNSS externes, comme le prévoient 
les sections 10.3 et 11.4 du présent appendice. 
CSM_76  Une unité embarquée sur véhicule doit pouvoi r générer des paires de clés ECC éphémères et utiliser 
une paire de clés éphémères excl usivement pour effectuer la concordance de clés de session avec une 
carte tach ygraphique ou un dispositif GNSS extern e, comme le prévoi ent les sections 10.4 et 11.4 
du présent appendice. 
CSM_77  Une unité embarquée sur véhicule utilise la clé privée VU_Sign.SK de sa paire de clés VU_Sign 
excl usivement pour signer des fichiers de données télécharg és, comme le prévoi t le chapitre 14 du 
présent appendice. La clé publique VU_Sign.PK correspondant e sert exclusivement à vérifier les 
signatures créées par la VU. 
CSM_78  Comme le montre la Figure 1 de la section 9.1.7, la durée de validité d'un certificat VU_MA est de 
15 ans et trois mois. La durée de validité d'un certificat VU_Sign est également de 15 ans et trois 
mois. 
Remar ques: 
—  La durée de validité étendue d'un certificat VU_Sign permet à une unité embarquée sur véhicule 
de créer des signatures valides par rappor t à des données télécharg ées pendant les trois premiers 
mois qui suivent sa date d'expiration, comme l'exig e le règlement no 581/2010 
—  La durée de validité étendue d'un certificat VU_MA est nécessaire pour permettre à la VU 
d'authentif ier une carte de contrôle ou une carte d'entrepr ise pendant les trois premiers mois qui 
suivent sa date d'expiration, de manière à pouvoi r effectuer des téléc hargements de données. 
CSM_79  Une VU n'utilise pas la clé privée d'une paire de clés VU à quelque fin que ce soit après l'expiration 
du certificat correspondant. 
CSM_80  Les paires de clés VU (hor mis les paires de clés éphémères) et les certificats correspondants pour une 
VU donnée ne sont ni remplacés ni renouvelés sur le terrain une fois que la VU a été mise en 
service. 
Remar ques: 
—  Les paires de clés éphémères ne sont pas soumises à cette exige nce, car une nouvelle paire de 
clés éphémères est générée par la VU à chaque exécution d'une authentifi cation de circuit et à 
chaque concordance de clé de session; cf. section 10.4. Remar que: les paires de clés éphémères ne 
possèdent pas de certificats correspondants. 
—  Cette exigenc e n'interdi t pas la possibilit é de remplacer les paires de clés VU statiques lors d'une 
maintenance ou d'une réparation dans un environnement contrôlé et sécur isé par le fabr icant de 
VU. 
CSM_81  Lorsqu'elle est mise en service, la VU contient les clés et les certificat s cryptographi ques suivants: 
—  la clé privée VU_MA et le certificat correspondant ; 
—  la clé privée VU_Sign et le certificat correspondant ; 
—  le certificat MSCA_ VU-EGF compr enant la clé publique MSCA _VU-EGF .PK à utiliser pour vérifier 
les certificats VU_MA et VU_Sign; 
—  le certificat EUR compre nant la clé publique EUR.PK à utiliser pour vérifier le certificat 
MSCA _VU-EGF; 26.5.2016 L 139/364 Jour nal officiel de l'Union européenne FR     
—  le certificat EUR dont la durée de validité précède directement celle du certificat EUR à utiliser 
pour vérifier le certificat MSCA _VU-EGF , le cas échéant ; 
—  le certificat de lien reliant ces deux certificats EUR, le cas éché ant. 
CSM_82  Outre les clés et les certificat s cryptographiques listés en CSM_81, les VU contiennent également les 
clés et les certificat s précisés à la partie A du présent appendice, permettant à une VU d'inter agir 
avec les cartes tach ygraphiques de première génération. 
9.1.5  Niveau équipement: cartes tachyg raphiques 
CSM_83  Une paire de clés ECC unique appelée Card_MA est générée pour chaque carte tach ygraphique. Une 
deuxième paire de clés ECC unique, appelé Card_Sign, est générée en plus pour chaque carte de 
conduct eur et chaque carte d'ate lier. Cette tâche incombe aux fabricants et aux personnalisat eurs de 
cartes. Dès lors qu'une paire de clés pour carte est générée, la partie la générant doit adresser la clé 
publique à la MSCA de son pays de résidence afin d'obte nir un certificat pour carte correspondant, 
signé par la MSCA . La clé privée sert uniquement à la carte tach ygraphique. 
CSM_84  Les certificat s Card_MA et Card_Sign attribués à une carte de conducteur ou d'atelier donnée 
possèdent la même date d'entrée en vigueur de certificat . 
CSM_85  Un fabricant ou un personnalisateur de carte choisit la force d'une paire de clés pour carte égale à 
celle de la paire de clés MSCA servant à signer le certificat pour carte correspondant. 
CSM_86  Une carte tach ygraphique utilise sa paire de clés Card_MA, compo sée d'une clé privée Card_MA. SK 
et d'une clé publique Card_MA. PK, exclusivement pour effectuer des opérations d'authentifi cation 
mutuelle et de concordance des clés de session avec les VU, comme le prévoient les sections 10.3 et 
10.4 du présent appendice. 
CSM_87  Une carte de conduct eur ou d'atelier utilise la clé privée Card_Sign.SK de sa paire de clés Card_Sign 
excl usivement pour signer des fichiers de données télécharg és, comme le prévoi t le chapitre 14 du 
présent appendice. La clé publique Card_Sign.PK correspondante sert excl usivement à vérifier les 
signatures créées par la carte. 
CSM_88  La durée de validité d'un certificat Card_MA est la suivante: 
—  Pour les cartes de conducteur: 5 ans 
—  Pour les cartes d'entrepr ise: 2 ans 
—  Pour les cartes de contrôle: 2 ans 
—  Pour les cartes d'atelier: 1 an  
CSM_89  La durée de validité d'un certificat Card_Sign est la suivante: 
—  Pour les cartes de conducteur: 5 ans et 1 mois 
—  Pour les cartes d'atelier: 1 an et 1 mois  
Note: la durée de validité étendue d'un certificat Card_Sign permet à une carte de conduct eur de 
créer des signatures valides par rappor t à des données télécharg ées pendant le premier mois qui suit 
sa date d'expiration. Cela est nécessaire en vertu du règlement (UE) no 581/2010 qui exige qu'un 
télécharg ement de données depuis une carte de conduct eur soit possible jusqu'à 28 jours après la 
mémor isation des dernières données. 
CSM_90  Les paires de clés et les certificat s correspondants d'une carte tach ygraphique donnée ne sont ni 
rem placés ni renouvelés après l'émission de ladit e carte. 26.5.2016 L 139/365 Jour nal officiel de l'Union européenne FR     
CSM_91  Une fois émises, les cartes tach ygraphiques contiennent les clés et les certificat s cryptographiques 
suivants: 
—  la clé privée Card_MA et le certificat correspondant ; 
—en sus, pour les cartes de conduct eur et d'ate lier: la clé privée Card_Sign et le certificat corres­
pondant 
—  le certificat MSCA_ Card compr enant la clé publique MSCA_Card.PK à utiliser pour vérifier les 
certificats Card_MA et Card_Sign; 
—  le certificat EUR compre nant la clé publique EUR.PK à utiliser pour vérifier le certificat 
MSCA _Card; 
—  le certificat EUR dont la durée de validité précède directement celle du certificat EUR à utiliser 
pour vérifier le certificat MSCA _Card, le cas échéant ; 
—  le certificat de lien reliant ces deux certificats EUR, le cas éché ant. 
CSM_92  Outre les clés et les certificats cryptographiques listés en CSM_91, les cartes tach ygraphiques 
contiennent également les clés et les certificat s précisés à la partie A du présent appendice, leur 
permettant d'inter agir avec les VU de première génération. 
9.1.6  Niveau équipement: dispositifs GNSS exter nes 
CSM_93  Une paire de clés ECC unique appelée EGF_MA est générée pour chaque dispositif GNSS externe. 
Cette tâche incombe aux fabricants des dispositifs GNSS extern es. Dès lors qu'une paire de clés 
EGF_MA est générée, la clé publique doit être adressée à la MSCA du pays de résidence afin d'obte nir 
un certificat EGF_MA correspondant, signé par la MSCA . La clé privée sert uniquement au dispositif 
GNSS exte rne. 
CSM_94  Un fabricant d'EGF choisit la force d'une paire de clés EGF_MA égale à celle de la paire de clés 
MSCA servant à signer le certificat EGF_MA correspondant. 
CSM_95  Un dispositif GNSS externe utilise sa paire de clés EGF_MA, compo sée d'une clé privée EGF_MA. SK 
et d'une clé publique EGF_MA. PK, exclusivement pour effectuer des opérations d'authentification 
mutuelle et de concordance des clés de session avec les VU, comme le prévoient les sections 11.4 et 
11.4 du présent appendice. 
CSM_96  La durée de validité d'un certificat EGF_MA est de 15 ans. 
CSM_97  Un dispositif GNSS exte rne n'utilise pas la clé privée d'une paire de clés EGF_MA pour se coupler à 
une VU après l'expiration du certificat correspondant. 
Note: comme l'explique la section 11.3.3, un EGF peut utiliser sa clé privée pour procéder à une 
authentification mutuelle avec la VU à laquelle il est couplé, y compr is après l'expiration du certificat 
correspondant. 
CSM_98  La paire de clés EGF_MA et les certificats correspondants pour un dispositif GNSS externe donné ne 
sont ni remplacés ni renouvelés sur le terrain une fois que l'EGF entre en opération. 
Remar que: cette exige nce n'interdi t pas la possibilit é de rem placer les paires de clés EGF lors d'une 
maint enance ou d'une réparation dans un environnement contrôlé et sécur isé par le fabricant d'EGF . 
CSM_99 Lorsqu'il entre en opération, le dispositif GNSS extern e contient les clés et les certificat s cryptogra ­
phiques suivants: 
—  la clé privée EGF_MA et le certificat correspondant ; 26.5.2016 L 139/366 Jour nal officiel de l'Union européenne FR     
—  le certificat MSCA_ VU-EGF compr enant la clé publique MSCA _VU-EGF .PK à utiliser pour vérifier 
le certificat EGF_MA; 
—  le certificat EUR compre nant la clé publique EUR.PK à utiliser pour vérifier le certificat 
MSCA _VU-EGF; 
—  le certificat EUR dont la durée de validité précède directement celle du certificat EUR à utiliser 
pour vérifier le certificat MSCA _VU-EGF , le cas échéant ; 
—  le certificat de lien reliant ces deux certificats EUR, le cas éché ant. 
9.1.7  Génér alités: certificat de substitution 
La Figure 1 ci-après montre comment diffé rentes générations de certificats racine ERCA, de certificats de lien 
ERCA, de certificats MSCA et d'équipement (VU et carte) sont émis et utilisés au fil du temps: 
Figure 1 
Émission et utilisation de différentes générations de certificats racine ERCA, de certificats de lien ERCA, de 
certificats MSC A et d'équipement 
26.5.2016 L 139/367 Jour nal officiel de l'Union européenne FR     
Notes relatives à la Figure 1: 
1.  Le nombre entre parenthèses indique les différentes générations du certificat racine. P. ex. ERCA (1) désigne 
le certificat racine ERCA de première génération; ERCA (2) désigne celui de deuxième génération; etc. 
2.  D'autres certificat s sont repérés par deux nombres entre parenthèses. Le premier indique la génération du 
certificat racine dont relève leur émission, le deuxième indique la génération du certificat lui-même. P. ex. 
MSCA_Card (1-1) désigne le premier certificat MSCA_Card émis sous ERCA (1); MSCA _Card (2-1) désigne 
le premier certificat MSCA_Card émis sous ERCA (2); MSCA_ Card (2-last) désigne le dernier certificatMS ­
CA_Card émis sous ERCA (2); Card_MA(2-1) désigne le premier certificat Card pour l'authentification 
mutuelle émis sous ERCA (2), etc. 
3.  Les certificats MSCA_ Card (2-1) et MSCA_ Card (1-last) sont émis quasiment à la même date. MSCA_Card 
(2-1) désigne le premier certificat MSCA_Card émis sous ERCA (2) peu de temps après MSCA_ Card (1-last), 
le dernier certificat MSCA_ Card sous ERCA (1). 
4.  Comme l'illustre la figure, les premiers certificats VU et Card émis sous ERCA (2) apparaissent presque 
deux ans avant que n'apparaissent les derniers certificats VU et Card émis sous ERCA (1). Cela s'explique 
par le fait que les certificat s VU et Card sont émis sous un certificat MSCA, pas directemen t sous le 
certificat ERCA. Le certificat MSCA (2-1) est émis immédiatem ent après l'entrée en validité d'ER CA (2), 
mais le certificat MSCA (1-last) est émis légèrement avant, à la tout e fin de validité du certificat ERCA (1). 
Par conséquent, ces deux certificat s MSCA présentent à peu de chose près la même durée de validité, 
malgré le fait qu'ils sont de générations différ entes. 
5.  La durée de validité indiquée sur ces cartes est celle des cartes de conducteur (5 ans). 
6.  Pour gagner de l'espace, la différ ence entre les durées de validité des certificats Card_MA et Card_Sign et les 
certificats VU_MA et VU_Sign n'est précisée que pour la première génération. 
9.2.  Clés symétr iques 
9.2.1  Clés de sécur isation de la communication du capteur de mouv ement de la VU 
9.2.1.1  Génér alités 
Note: les lecteurs de la présent e section doivent maîtr iser le cont enu de la norme [ISO 16844-3] qui décr it 
l'interface entre une VU et un capt eur de mouvement. La procédure de couplage entre une VU et un capt eur 
de mouvement est décr ite en détail au chapitre 12 du présent appendice. 
CSM_100  Un nombre de clés symétr iques donné est nécessaire pour coupler des VU et des capt eurs de 
mouvement, en vue de leur authentification mutuelle et afin de chiffrer la communication entre 
eux, comme l'illustre le Tableau 3. Toutes ces clés sont des clés AES dont la longueur est égale à 
celle de la clé maîtresse du capt eur de mouvement, cette dernière étant liée à la longueur de la paire 
de clés racine européenne (anticipée), comme le prév oit le CSM_50. 
Tableau 3 
Clés de sécur isation de la VU — communication du capteur de mouv ement 
Légende Symbole Produit par Méthode de génératio n Mémor isé par 
Clé maîtresse du capt eur 
de mouvement — partie 
VU KM-V U ERCA Aléat oire ERCA, MSCA impliquées 
dans l'émission des certi­
ficats VU, fabricants de 
VU, VU 26.5.2016 L 139/368 Jour nal officiel de l'Union européenne FR     
Légende Symbole Produit par Méthode de génératio n Mémor isé par 
Clé maîtresse du capt eur 
de mouvement — partie 
ateli er KM-W C ERCA Aléat oire ERCA, MSCA, fabr icants 
de cartes, cartes d'atelier 
Clé maîtresse du capt eur 
de mouvement KM Généré de manière non 
indépendante Calculé comme KM = 
KM-V U XOR KM-W C ERCA, MSCA impliquées 
dans l'émission des clés 
de capt eurs de mouve ­
ment (facultatif) (*) 
Clé d'identif ication KID Généré de manière non 
indépendante Calculé comme KID = KM 
XOR CV, où CV est dé­
fini par le CSM_106 ERCA, MSCA impliquées 
dans l'émission des clés 
de capt eurs de mouve ­
ment (facultatif) (*) 
Clé de couplage KP Fabri cant des capt eurs 
de mouvement Aléat oire Un capt eur de mouve ­
ment 
Clé de session KS VU (durant le couplag e 
de la VU et du capt eur 
de mouvement) Aléat oire Une VU et un capt eur de 
mouvement 
(*)  Le stockag e de KM et KID est facultatif, car ces clés peuvent être calculées selon KM-V U, KM-WC et CV.  
CSM_101  L'autori té de certification racine européenne génère KM-V U et KM-W C, deux clés AES aléat oires et 
uniques dont dérive le calcul de la clé maîtresse du capt eur de mouvement KM comme KM-V U XOR 
KM-W C. L'ER CA communique KM, KM-VU et KM-WC aux organismes de certificat ion de l'État membre sur 
leur demande. 
CSM_102  L'ER CA attribue à chaque clé maîtresse du capt eur de mouvement KM un numéro de version 
unique, qui s'applique également à la constitution des clés KM-V U et KM-W C ainsi qu'à l'identif ication 
du KID.de la clé qui y est associée. L'ER CA informe les MSCA du numéro de version lorsqu'elle leur 
adresse KM-V U et KM-WC. 
Remarque: le numéro de version sert à distinguer les générations de ces clés, comme l'explique en 
détail la section 9.2.1.2. 
CSM_103  Les orga nismes de certificat ion de l'État membre transmettent KM-VU, et son numéro de version aux 
fabricants de VU sur leur demande. Les fabr icants de VU insèrent KM-VUet son numéro de version 
dans tout es les VU fabriquées. 
CSM_104  Les organismes de certificat ion de l'État membre vérifient que KM-WC et son numéro de version sont 
insérés dans chaque carte d'atelier émise sous leur responsabilit é. 
Remarques: 
—  Voir la descr iption du type de données 
 dans l'appendice 2. 
—  Comme l'explique la section 9.2.1.2, il s'avère possible de devoir insérer plusieurs générations 
de KM-W C dans une même carte d'atelier . 
CSM_105  Outre la clé AES spécifiée au CSM_104, la MSCA garantit que la clé TDES KmWC, spécifiée par le 
CSM_037 dans la partie A du présent appendice, est insérée dans chaque carte d'ateli er émise sous 
sa responsabilité. 26.5.2016 L 139/369 Jour nal officiel de l'Union européenne FR     
Remarques: 
—  Cela permet d'utiliser une carte d'atelier de deuxième génération pour coupler une VU de 
première génération. 
—  Une carte d'ateli er de deuxième génération contient deux applications distinctes. L'une se 
conf orme à la partie B du présent appendice et l'autre à la partie A. Cette dernière contient la 
clé TDES KmWC. 
CSM_106  Une MSCA impliquée dans l'émission de capt eurs de mouvement calcule la clé d'identification de la 
clé maîtresse du capt eur de mouvement en appliquant la fonction XOR ainsi qu'un vecteur 
constant, CV. La valeur du vect eur constant est la suivante: 
—  Pour les clés maîtresses du capt eur de mouvement sur 128 bits: CV = ‘B6 44 2C 45 0E F8 D3 
62 0B 7A 8A 97 91 E4 5E 83’ 
—  Pour les clés maîtresses du capt eur de mouvement sur 192 bits: CV = ‘72 AD EA FA 00 BB F4 
EE F4 99 15 70 5B 7E EE BB 1C 54 ED 46 8B 0E F8 25’ 
—  Pour les clés maîtresses du capt eur de mouvement sur 256 bits: CV = ‘1D 74 DB F0 34 C7 37 
2F 65 55 DE D5 DC D1 9A C3 23 D6 A6 25 64 CD BE 2D 42 0D 85 D2 32 63 AD 60’ 
Note: les vect eurs constants sont générés de la manière suivante: 
Pi_10 = 10 premiers octets de la portion décimale de la constante mathématique π = ‘24 3F 6A 88 
85 A3 08 D3 13 19’ 
CV_128-bits = 16 premiers octets de SHA-256(Pi_10) 
CV_192-bits = 24 premiers octets de SHA-384(Pi_10) 
CV_256-bits = 32 premiers octets de SHA-512(Pi_10) 
CSM_107  Les fabricants de capt eurs de mouvement génèrent une clé de couplage aléat oire unique KP pour 
chaque capt eur de mouvement et communiquent chaque clé de couplage aux organismes de certifi­
cation de l'État membre. La MSCA chiffre chaque clé de couplage séparément à l'aide de la clé 
maîtresse du capt eur de mouvement KM et retour ne la clé cryptée au fabricant de capt eurs de 
mouvement. Pour chaque clé cryptée, la MSCA aver tit le fabr icant de capt eurs de mouvement du 
numéro de version de la KM. associée. 
Note: comme l'explique la section 9.2.1.2, il se peut qu'un fabricant de capt eurs de mouvement 
doive générer plusieurs clés de couplage uniques pour un même capt eur de mouvement. 
CSM_108  Les fabricants de capt eurs de mouvement génèrent un numéro de série unique pour chaque capt eur 
de mouvement et communiquent tous les numéros de série aux organismes de certification de 
l'État membre. La MSCA chiffre chaque numéro de série séparément à l'aide de la clé d'identif ication 
KID et retourne le numéro de série crypté au fabricant de capt eurs de mouvement. Pour chaque 
numéro de série crypté, la MSCA avertit le fabricant de capt eurs de mouvement du numéro de 
version du KID associé. 
CSM_109  En ce qui concer ne les exigenc es CSM_107 et CSM_108, la MSCA a recours à l'algor ithme AES 
dans le mode d'exploitation par chaînag e de blocs de données cryptées, tel que le définit la norme 
[ISO 10116], en respectant un paramètre d'entrelacement de m = 1 et un vecteur d'initialisation 
SV = ‘00’ {16}, c'est-à-dire seize octets de valeur binaire = 0. Lorsque cela s'avère nécessaire, la 
MSCA utilise la méthode de rem plissage numéro deux définie par la norme [ISO 9797-1]. 
CSM_110  Le fabricant de capt eurs de mouvement stoc ke la clé de couplage et le numéro de série cryptés dans 
le capt eur de mouvement auquel ils sont destinés. Il y stoc ke également les valeurs de texte en clair 
correspondantes et le numéro de version de KM et de KID qui a servi au cryptage. 
Note: comme l'explique la section 9.2.1.2, il se peut qu'un fabricant de capt eurs de mouvement 
doive enregistrer plusieurs clés de couplage uniques cryptées et plusieurs numéros de série cryptés 
pour un même capt eur de mouvement. 26.5.2016 L 139/370 Jour nal officiel de l'Union européenne FR     
CSM_111  Outre le matér iel cryptographique AES spécifié en CSM_110, le fabr icant de capt eurs de 
mouvement peut également stoc ker dans chaque capt eur de mouvement le mat ériel cryptogra ­
phique TDES spécifié dans l'exigence CSM_037 dans la partie A du présent appendice. 
Note: ce faisant, il permet à un capt eur de mouvement de deuxième génération de se coupler avec 
une VU de première génération. 
CSM_112  La longueur de la clé de session KS générée par une VU pendant le couplage avec un capt eur de 
mouvement est liée à la longueur de son KM-V U, comme décr it au CSM_50. 
9.2.1.2  Remplacement de la clé maîtresse du capteur de mouv ement dans un équipement de deuxième génération 
CSM_113  Toutes les clés maîtresses des capt eurs de mouvement et tout es les clés associées (cf. Tableau 3) 
sont liées à une génération donnée de paire de clés racine ERCA. Ces clés doivent donc être 
rem placées tous les 17 ans. La durée de validité de chaque génération de clés maîtresses de capt eur 
de mouvement commence un an avant que la paire de clés racine ERCA associée n'entre en validité 
et elle finit à l'expiration de la paire de clés racine ERCA associée. La Figure 2 illustre ce principe. 
Figure 2 
Émission et utilisation de diverses générations de clés maîtresses de capteurs de mouv ement sur des VU, des 
capteurs de mouv ement et des cartes d'ateliers 
CSM_114  Au moins un an avant la génération d'une nouvelle paire de clés racine européenne, conf ormément 
au CSM_56, l'ERCA génère une nouvelle clé maîtresse de capt eur de mouvement KM en générant de 
nouvelles KM-V U et KM-WC. La longueur de la clé maîtresse du capt eur de mouvement est liée à la 
force anticipée de la nouvelle paire de clés racine européenne conf ormément au CSM_50. L'ER CA 
communique les nouvelles KM, KM-VU et KM-W C ainsi que leur numéro de version aux MSCA sur leur 
demande. 
CSM_115  Les MSCA s'assurent que tout es les générations valides de KM-W C sont stoc kées dans chaque carte 
d'ateli er émise sous leur autorité, de même que leurs numéros de version, comme illustré à la 
Figure. 26.5.2016 L 139/371 Jour nal officiel de l'Union européenne FR     
cela implique qu'au cours de la dernière année de validité d'un certificat ERCA, les cartes d'atelier 
sont émises avec trois générations de KM-W C, comme l'illustre la Figure 2. 
CSM_116  À propos de la procédure décr ite par lesCSM_107 et CSM_108 ci-dessus: la MSCA chiffre chaque 
paire de clés de couplage KP reçue des fabricants de capt eurs de mouvement séparément selon 
chaque génération valide de clé maîtresse de capt eur de mouvement KM. La MSCA chiffre également 
chaque numéro de série reçu des fabricants de capt eurs de mouvement séparément selon chaque 
génération valide de clé d'identification KID. Le fabricant de capt eurs de mouvement stoc ke tous les 
crypta ges de clé de couplage et de numéro de série dans le capt eur de mouvement auquel ils sont 
destinés. Il y stoc ke également les valeurs de texte en clair correspondante s et le ou les numéro(s) 
de version de KM et KID qui ont servi au cryptag e. 
Remarque: cela implique qu'au cours de la dernière année de validité d'un certificat ERCA, les 
capt eurs de mouvement sont émis avec des données cryptées selon trois générations de KM,, comme 
l'illustre la Figure 2. 
CSM_117  À propos de la procédure décr ite par le CSM_107 ci-dessus: du fait que la longueur de la clé de 
couplage KP doit être liée à celle de KM (cf. CSM_100), il se peut que le fabr icant de capt eurs de 
mouvement doive générer jusqu'à trois clés de couplage distinct es (de longueurs diffé rentes) pour 
un même capt eur de mouvement, pour anticiper les éventuelles longueurs des générations futures 
de KM. Dans ce cas, le fabricant adresse chaque clé de couplage à la MSCA . La MSCA vérifie que 
chaque clé de couplage est cryptée selon la génération adéquate de la clé maîtresse du capt eur de 
mouvement, c'est-à-dire celle présentant la même longueur . 
Remarque: si le fabricant de capt eurs de mouvement choisit de générer une clé de couplage TDES 
pour un capt eur de mouvement de deuxième génération (cf. CSM_111), il indique à la MSCA que 
la clé maîtresse du capt eur de mouvement TDES doit servir à chiffrer cette clé de couplage. Cela 
s'impose parce que la longueur de la clé TDES pour rait être égale à celle de la clé AES. La MSCA ne 
pour rait alors pas les distinguer sur leurs longueurs respectives. 
CSM_118  Les fabr icants de VU insèrent uniquement une génération de KM-V U dans chaque VU, accompag née 
de son numéro de version. Cette génération de KM-V U est liée au certificat ERCA dont découlent les 
certificats VU. 
Remarques: 
—  Une VU liée à un certificat ERCA de génération X contient uniquement une KM-V U, de génération 
X même si elle est émise après le début de la durée de validité du certificat ERCA de génération 
X+1. La Figure 2 illustre ce principe. 
—  Une VU de génération X ne peut pas se coupler avec un capt eur de mouvement de génération 
X-1. 
—  Du fait que les cartes d'ateli er présent ent une validité d'un an, les exigenc es CSM_113 — 
CSM_118 font que tout es les cartes d'atelier contiennent le nouveau KM-W C à l'émission de la 
première VU cont enant le nouveau KM-V U. Par conséquent, une telle VU pour ra toujours calculer 
la nouvelle KM. De plus, pendant ce temps, la plupar t des nouveaux capt eurs de mouvement 
contiendront des données codées basées sur la nouvelle KM, également. 
9.2.2  Clés de sécur isation de la communication DSRC 
9.2.2.1  Génér alités 
CSM_119  L'authenticité et la conf identialit é des données communiquées par la VU aux autori tés de contrôle à 
l'aide d'un canal de communication distant DSR C sont garanties par un jeu de clés AES propres à 
la VU découlant d'une unique clé maîtresse DSR C, KMDSR C. 
CSM_120  La clé maîtresse DSR C KMDSR C est une clé AES générée, stoc kée et diffusée de manière sécur isée par 
l'ERCA. La longueur de la clé peut être de 128, 192 ou 256 bits. Elle dépend de la longueur de la 
paire de clés racine européenne, conf ormément au CSM_50. 26.5.2016 L 139/372 Jour nal officiel de l'Union européenne FR     
CSM_121  L'ER CA communique la clé maîtresse DSR C aux organismes de certification de l'État membre sur 
leur demande et de manière sécur isée. Cela leur permet de calculer les clés DSR C propres aux VU 
et de s'assurer que la clé maîtresse DSR C est insérée dans tout es les cartes de contrôle et d'atelier 
émises sous leur responsabilit é. 
CSM_122  L'ER CA attribue un numéro de version unique à chaque clé maîtresse DSR C. L'ER CA informe les 
MSCA du numéro de version lorsqu'elle leur adresse la clé maîtresse DSR C. 
Remarque: le numéro de version sert à distinguer les générations de ces clés maîtresses DSR C, 
comme l'explique en détail la section 9.2.2.2. 
CSM_123  Pour chaque VU, le fabricant de VU crée un numéro de série VU unique qu'il adresse aux 
organismes de certification de l'État membre en vue d'obte nir un jeu de deux clés DSR C propre aux 
VU. Le numéro de série VU relève du type de données 
 et les règles de codag e 
distinctes (DER) conf ormes à la norme [ISO 8825-1] servent à son cryptag e. 
CSM_124  Dès récep tion d'une demande de clés DSR C propres aux VU, la MSCA calcule deux clés AES pour 
la VU, appelées K_VUDSR C_ENC et K_VUDSR C_MA C. Ces clés propres aux VU sont de longueur 
identique à celle de la clé maîtresse DSR C. La MSCA utilise la fonction de dérivation de clé définie 
au [RFC 5869]. La fonction de hachag e nécessaire pour instancier la fonction de hach age HMA C 
est liée à la longueur de la clé maîtresse DSR C, conf ormément au CSM_50. La fonction de 
dérivation de clé figurant au [RFC 5869] sert de la manière suivante: 
Étape no 1 (extraction): 
—  PRK = HMA C-Hash (salt, IKM) où salt représente une chaîne vide ‘ ’ et IKM correspond à 
KMDSR C. 
Étape no 2 (expansion): 
—  OKM = T(1), avec 
T(1) = HMA C-Hash (PRK, T(0) || info || ‘01’) et 
—  T(0) = chaîne vide (‘ ’) 
—  info = numéro de série VU conf orme au CSM_123 
—  K_VUDSR C_ENC = premiers L octets de OKM et 
K_VUDSR C_MA C = derniers L octets de OKM 
où L de la longueur requise de K_VUDSR C_ENC et K_VUDSR C_MA C en octets. 
CSM_125  La MSCA communique K_VUDSR C_ENC et K_VUDSR C_MA C aux fabricants de VU de manière 
sécur isée en vue de leur inser tion dans les VU auxquelles ils sont destinés. 
CSM_126  Après leur émission, la VU enregistre K_VUDSR C_ENC et K_VUDSR C_MA C dans sa mémoire sécur isée, 
de façon à pouv oir assurer l'inté grité, l'authenticit é et la conf identialit é des données envoyées au 
moyen du canal de communication distant. La VU mémor ise également le numéro de version de la 
clé maîtresse DSR C servant à calculer les clés propres aux VU. 
CSM_127  Après leur émission, les cartes de contrôles et d'ateli er enregistrent KMDSR C dans leur mémoire 
sécur isée, de façon à pouvoir vérifier l'intégrité et l'authenticit é des données envoyées par la VU par 
le canal de communication distant et de façon à pouvoi r décr ypter ces données. Les cartes de 
contrôle et d'atelier mémor isent également le numéro de version de la clé maîtresse DSR C. 
Note: comme l'explique la section 9.2.2.2, il s'avère possible de devoir insérer plusieurs générations 
de KMDSR C dans une même carte d'ate lier ou de contrôle. 26.5.2016 L 139/373 Jour nal officiel de l'Union européenne FR     
CSM_128  La MSCA archive tout es les clés DSR C propres aux VU qu'elle a générées, ainsi que leur numéro de 
version et l'identificateur de la VU destinés à chaque jeu de clés. 
9.2.2.2  Substitution de clé maîtresse DSRC 
CSM_129  Toutes les clés maîtresses DSR C sont liées à une génération donnée de paire de clés racine ERCA. 
L'ER CA rem place donc chaque clé maîtresse DSR C tous les 17 ans. La durée de validité de chaque 
génération de clés maîtresses DSR C commence deux ans avant que la paire de clés racine ERCA 
associée n'entre en validité et elle finit à l'expiration de la paire de clés racine ERCA associée. La 
Figure 3 illustre ce principe. 
Figure 3 
Émission et utilisation de diverses générations de clés maîtresses DSR C sur des VU, des cartes d'ateliers et de 
contrôle 
CSM_130  Au moins deux ans avant la génération d'une nouvelle paire de clés racine européenne, 
conf ormément au CSM_56, l'ERCA génère une nouvelle clé maîtresse DSR C. La longueur de la clé 
maîtresse DSR C est liée à la force anticipée de la nouvelle paire de clés racine européenne 
conf ormément au CSM_50. L'ER CA communique la nouvelle clé maîtresse DSR C ainsi que son 
numéro de version aux MSCA sur leur demande. 
CSM_131  Les MSCA s'assurent que tout es les générations valides de KMDSR C sont stoc kées dans chaque carte 
de contrôle émise sous leur autor ité, de même que leurs numéros de version, comme illustré à la 
Figure 2. 
Note: cela implique qu'au cours des deux dernières années de validité d'un certificat ERCA, les 
cartes de contrôle sont émises avec trois générations de KMDSR C, comme l'illustre la Figure 2. 26.5.2016 L 139/374 Jour nal officiel de l'Union européenne FR     
CSM_132  Les MSCA s'assurent que tout es les générations de KMDSR C valides depuis au moins un an et 
toujour s en cours de validité sont stoc kées dans chaque carte d'atelier émise sous leur autor ité, de 
même que leurs numéros de version, comme illustré à la Figure 2. 
Note: cela implique qu'au cours de la dernière année de validité d'un certificat ERCA, les cartes 
d'ateli er sont émises avec trois générations de KMDSR C, comme l'illustre la Figure 2. 
CSM_133  Les fabr icants de VU insèrent uniquement un jeu de clés DSR C propres aux VU dans chaque VU, 
accompag né de son numéro de version. Ce jeu de clés résult e de la génération KMDSR C liée au 
certificat ERCA dont découlent les certificat s VU. 
Remarques: 
—  Cela implique qu'une VU liée à un certificat ERCA de génération X contient uniquement une 
K_VUDSR C_ENC et une K_VUDSR C_MA C, de génération X même si la VU est émise après le début 
de la durée de validité du certificat ERCA de génération X+1. La Figure 3 illustre ce principe. 
—  Du fait que les cartes d'atelier présent ent une validité d'un an et les cartes de contrôle une 
validité de deux ans, les exigences CSM_131 — CSM_133 font que tout es les cartes d'ate lier et 
de contrôle contiennent la nouvelle clé maîtresse DSR C à l'émission de la première VU 
cont enant les clés propres aux VU relevant de cette clé maîtresse. 
9.3.  Cer tificats 
9.3.1  Génér alités 
CSM_134  Tous les certificats inscr its dans le système de tach ygraphie intellig ente européenne sont de type 
autode scriptifs et vérifiables par carte (VC) conf ormément aux normes [ISO 7816-4] et [ISO 
7816-8]. 
CSM_135  Les règles de codage distinct es (DER) conf ormes à la norme [ISO 8825-1] servent à encoder les 
structures de données ASN.1 et (selon l'application) les objets de données au sein des certificats. 
Note: cet cryptag e produit la structure Tag-Length- Value (TLV) suivante: 
Balise:  la balise est cryptée sur un ou deux octet(s) et indique le conte nu. 
Longueur :  la longueur est cryptée comme un entier non signé sur un, deux ou trois octet(s), soit 
une longueur maximale de 65 535 octets. On utilise le nombre minimal d'oct ets. 
Valeur:  la valeur est cryptée sur zéro octet ou plus. 
9.3.2  Contenu du certificat 
CSM_136  Tous les certificat s possèdent une structure présent ée dans le profil de certificat du Tableau 4. 
Tableau 4 
Prof il de certificat version 1 
Cham p ID de cham p Balise Longueur (en 
octets) Type de données ASN.1 
(voir appendice 1) 
Certificat ECC C ‘7F 21’ var  
Corps du certificat ECC B ‘7F 4E’ var  26.5.2016 L 139/375 Jour nal officiel de l'Union européenne FR     
Cham p ID de cham p Balise Longueur (en 
octets) Type de données ASN.1 
(voir appendice 1) 
Identificateur de prof il du certificat CPI ‘5F 29’ ‘01’ 
Référence de l'organisme de certification CAR ‘42’ ‘08’ 
Autor isation du titulaire de certificat CHA ‘5F 4C’ ‘07’ 
Clé publique PK ‘7F 49’ var  
Paramètres de domaines DP ‘06’ var 
Point public PP ‘86’ var 
Référence du titulaire de certificat CHR ‘5F 20’ ‘08’ 
Date d'entrée en vigueur du certificat CEfD ‘5F 25’ ‘04’ 
Date d'expiration du certificat CExD ‘5F 24’ ‘04’ 
Signature du certificat ECC S ‘5F 37’ var 
Note: l'ID de champ sert dans les sections ultérieures du présent appendice à indiquer les zones 
individuelles d'un certificat, p. ex. X.CA R désigne la référen ce des organismes de certification 
mentionnée dans le certificat d'un utilisateur X. 
9.3.2.1  Certificate Profi le Identif ier 
CSM_137  Les certificats adopt ent un identificateur de prof il de certificat pour indiquer le prof il de certificat 
utilisé. La version 1, comme précisé au Tableau 4, est identifiée par une valeur de ‘00’. 
9.3.2.2  Certificate Author ity Reference 
CSM_138  La référence des organismes de certification sert à identifier la clé publique à utiliser pour vérifier la 
signature du certificat. La référen ce des organismes de certification doit donc être identique à celle 
du titulaire de certificat dans le certificat des organismes de certificat ion correspondants. 
CSM_139  Un certificat racine ERCA est autos igné, c'est-à-dire que la référence des organismes de certificat ion 
et la référence du titulaire du certificat figurant sur le certificat sont identiques. 
CSM_140  Pour un certificat de lien ERCA, la référence du titulaire du certificat est identique au CHR du 
nouveau certificat racine ERCA. La référence des orga nismes de certification d'un certificat de lien 
est identique au CHR du certificat racine ERCA antér ieur. 
9.3.2.3  Certificate Holder Author isation 
CSM_141  L'autori sation du titulaire de certificat permet d'identifier le type de certificat. Elle se compo se des 
six octets principaux de l'ID de l'application tach ygraphique concaténée avec le type d'équipement 
auquel est destiné le certificat. 26.5.2016 L 139/376 Jour nal officiel de l'Union européenne FR     
9.3.2.4  Public Key 
La clé publique héberge deux éléments de données: les paramètres du domaine normalisé à utiliser avec la clé 
publique du certificat et la valeur du point public. 
CSM_142  L'élément de données Paramètres de domaine contient l'un des identif icate urs d'objet précisé au 
Tableau 1 en vue de référencer un jeu de paramètres de domaines normalisés. 
CSM_143  L'élément de données Public Point contient le point public. Les points publics de la courbe 
elliptique sont conver tis en chaînes d'oct ets comme le précise le [TR-03111]. On utilise la structure 
cryptée non compre ssée. Les validations décr ites au [TR-03111] s'appliquent toujour s lorsque l'on 
décode un point de la courbe elliptiq ue. 
9.3.2.5  Certificate Holder Reference 
CSM_144  La référence du titulaire de certificat sert d'identif icateur pour la clé publique fournie avec le 
certificat. Elle sert à référencer cette clé publique dans d'autres certificats. 
CSM_145  Concer nant les certificat s de cartes et de dispositifs GNSS externes, la référen ce du titulaire de 
certificat relève du type de données 
 comme précisé en appendice 1. 
CSM_146  Concer nant les VU, le fabricant, lorsqu'il demande un certificat , connaît ou non le numéro de série 
propre au fabricant de la VU à laquelle s'adresse ce certificat et la clé privée associée. Dans le 
premier cas, la référence du titulaire de certificat relève du type de données 
comme précisé en appendice 1. Dans le dernier cas, la référence du 
titulaire de certificat relève du type de données 
 comme précisé en 
appendice 1. 
CSM_147  Concer nant les certificat s ERCA et MSCA, la référence du titulaire de certificat relève du type de 
données 
 comme précisé en appendice 1. 
9.3.2.6  Certificate Effective Date 
CSM_148  La date d'entrée en vigueur du certificat indique la date et l'heure de début de la durée de validité 
du certificat. La date d'entrée en vigueur du certificat correspond à la date de génération du 
certificat. 
9.3.2.7  Certificate Expiration Date 
CSM_149  La date d'expiration du certificat indique la date et l'heure de fin de la durée de validité du certificat. 
9.3.2.8  Certificate Signature 
CSM_150  La signature du certificat est créée en fonction du corps de certificat codé, y compris la balise et la 
longueur de ce dernier. Les [DSS] préconisent d'adopt er l'algor ithme de signature ECDS A et le 
CSM_50 préconise d'utiliser l'algor ithme de hachag e associé à la taille de la clé des autorités de 
signature. La structure de la signature est en clair , conf ormément au [TR-03111]. 
9.3.3  Certificats de demande 
CSM_151  Lors de la demande d'un certificat, le demandeur adresse les données suivantes à ses orga nismes de 
certification: 
—  l'identificateur de profil de certificat du certificat demandé, 
—  la référence des organismes de certification attendue pour signer le certificat, 
—  la clé publique à signer . 26.5.2016 L 139/377 Jour nal officiel de l'Union européenne FR     
CSM_152  Outre les données dans le CSM_151, une MSCA envoie les données suivantes dans une demande 
de certificat à l'ERCA, ce qui permet à l'ERCA de créer la référence du titulaire de certificat du 
nouveau certificat MSCA: 
—  le code numér ique national des organismes de certificat ion (type de données 
défini à l'appendice 1), 
—  le code numér ique national des organismes de certificat ion (type de données 
défini à l'appendice 1), 
—  le numéro de série sur un octet permettant de faire la distinction entre les différ entes clés de 
l'organ isme de certification si certaines clés font l'objet de modifications, 
—  le champ de deux octets contenant les informations compl émentaires spécifi ques à l'organ isme 
de certification. 
CSM_153  Outre les données dans le CSM_151, un fabricant d'équipement envoie les données suivante s dans 
une demande de certificat à une MSCA, ce qui lui permet de créer la référen ce du titulaire de 
certificat du nouvel équipement: 
—  un identif icateur propre au fabricant pour le type d'équipement considéré; 
—  s'il est connu (cf. CSM_154), un numéro de série de l'équipement, propre au fabricant, ainsi que 
le type d'équipement et le mois de sa fabrication. Sinon, un identificateur unique de demande 
de certificat ; 
—  le mois et l'année de fabr ication de l'équipement ou de la demande de certificat. 
Le fabricant s'assure de l'exactitude de ces données et du fait que le certificat renv oyé par la MSCA 
est inséré dans l'équipement auquel il est destiné. 
CSM_154  Concer nant les VU, le fabriquant, lorsqu'il demande un certificat, connaît ou non le numéro de 
série propre au fabr icant de la VU à laquelle s'adresse ce certificat et la clé privée associée. S'il est 
connu, le fabricant de VU adresse le numéro de série à la MSCA . S'il n'est pas connu, le fabricant 
identif ie de manière distinct e chaque demande de certificat et adresse le numéro de série de la 
demande de certificat à la MSCA . Le certificat produit contient le numéro de série de la demande 
de certificat. Après inser tion du certificat dans une VU donnée, le fabricant communique la 
connexion entre le numéro de série de la demande de certificat et l'identifi cateur de la VU à la 
MSCA . 
10.  AUTHENTIFIC ATION MUTUELLE DE LA CARTE ET DE LA VU ET MESSA GERIE SÉCURISÉE 
10.1.  Généralités 
CSM_155  À haut niveau, la sécur ité des communications échang ées entre une VU et une carte tach ygraphique 
repose sur les étapes suivantes: 
—  D'abord, chaque partie montre à l'autre qu'elle détient un certificat de clé publique valide, signé 
par l'organ isme de certification d'un État membre. En retour, le certificat de clé publique MSCA 
doit être signé par l'organisme de certificat ion racine européen. Cette étape correspond à la 
vérification de la chaîne de certification et fait l'objet d'une spécifi cation détaillée à la section 
10.2 
—  Deuxièmement, la VU montre à la carte qu'elle détient la clé privée correspondant à la clé 
publique du certificat présent é. Cela revient à signer un numéro aléat oire envoyé par la carte. La 
carte vérifie la signature par rappor t au numéro aléatoire. Si cette vérification aboutit, la VU est 
authentifiée. Cette étape correspond à l'authentification de la VU et fait l'objet d'une spécifi ­
cation détaillée à la section 10.3. 26.5.2016 L 139/378 Jour nal officiel de l'Union européenne FR     
—  Troisièmement, les deux parties calculent indépendamment deux clés de session AES à l'aide 
d'un algor ithme de concordance de clé asymétr ique. En utilisant l'une de ces clés de session, la 
carte crée un code d'authentifi cation de message (MA C) en fonction de certaines données 
envoyées par la VU. La VU vérifie le MAC. Si cette vérification aboutit, la carte est authentifi ée. 
Cette étape correspond à l'authentification de la carte et fait l'objet d'une spécifi cation détaillée 
à la section 10.4. 
—  Quatr ièmement, la VU et la carte utilisent les clés de session conven ues pour assurer la 
confidentialité, l'intégri té et l'authenticit é de tous les messages échang és. Cette étape correspond 
à la messager ie sécur isée et fait l'objet d'une spécif ication détaillée à la section 10.5. 
CSM_156  Le mécanisme décr it au CSM_155 est déclench é par la VU dès lors qu'une carte est insérée dans 
l'un de ses lecteurs de carte. 
10.2.  Vér ification mutuelle de la chaîne de certificat 
10.2.1  Vérification de la chaîne de certificat de la carte par la VU 
CSM_157  Les VU adopt ent le protocole prévu à la Figure 4 pour vérifier la chaîne de certificat d'une carte 
tach ygraphique. 
Notes relatives à la Figure 4: 
—  Les certificat s et les clés publiques associés à la carte mentionnés sur cette Figure sont ceux de 
l'authentification mutuelle. La section 9.1.5 précise leur intitulé: Card_MA. 
—  Les certificats Card.CA et les clés publiques mentionnées dans la figure sont ceux destinés à la 
signature des certificats de carte; cela est indiqué dans le CAR du certificat Card. La section 
9.1.3 précise leur intitulé: MSCA_ Card. 
—  Le certificat Card.CA .EUR mentionné sur cette figure est le certificat racine européen indiqué 
dans le CAR du certificat Card.CA . 
—  Le certificat Card.Link mentionné sur cette figure est le certificat de lien de la carte, le cas 
éché ant. Comme le précise la section 9.1.2, il s'agit d'un certificat de lien pour une nouvelle 
paire de clés racine européenne créé par l'ERCA et signé par la précédente clé privée 
européenne. 
—  Le certificat Card.Link.E UR est le certificat racine européen indiqué dans le CAR du certificat 
Card.Link. 
CSM_158  Comme illustré sur la Figure 4, la vérification du certificat de la carte commence dès l'inser tion de 
la carte. La VU lit la référence du titulaire de la carte (
 ) à partir du 
EF ICC. La VU vérifie si elle connaît la carte, c'est-à-dire si elle a vérifié la chaîne de certificat de la 
carte dans le passé et si elle l'a stoc kée pour la réutiliser à l'avenir . Si tel est le cas et que le certificat 
de la carte est touj ours valide, la procédure se poursuit avec la vérification de la chaîne de certificat 
de la VU. Sinon, la VU lit successivement depuis la carte le certificat MSCA_Card à utiliser pour 
vérifier le certificat de la carte, Card.CA . Le certificat EUR à utiliser pour vérifier le certificat 
MSCA_ Card et éventuellement le certificat de lien, jusqu'à trouver un certificat reconnu ou 
vérifiable. Si un tel certificat est reconnu, la VU utilise ce certificat pour vérifier les certificats de 
carte sous-jacents lus à partir de la carte. En cas de réussit e, la procédure se poursuit avec la 
vérification de la chaîne de certificat de la VU. En cas d'échec, la VU ignore la carte. 
Remarque: la VU peut connaître le certificat Card.CA .EUR pour trois raisons: 
—  le certificat Card.CA .EUR est identique à celui de la VU; 26.5.2016 L 139/379 Jour nal officiel de l'Union européenne FR     
—  le certificat Card.C A.EUR précède celui de la VU et la VU contient ce certificat dès son émission 
(cf. CSM_81); 
—  le certificat Card.CA .EUR succède à celui de la VU et la VU a reçu un certificat de lien d'une 
autre carte tach ygraphique, l'a vérifié et mémor isé pour une utilisation ultérieure. 
CSM_159  Comme l'indique la Figure 4, une fois que la VU a vérifié l'authenticit é et la validité d'un certificat 
encore inconnu, elle le mémor ise pour l'utiliser ultérieurement, de manière à ne pas devoi r le 
vérifier à nouveau s'il lui est représenté . Au lieu de mémor iser la totalit é du certificat , une VU peut 
choisir de ne mémor iser que le contenu du corps du certificat, conf ormément à la section 9.3.2. 
CSM_160  La VU vérifie la validité temporelle de tout certificat lu depuis la carte ou mémor isé et refuse les 
certificats expirés. Pour vérifier la validité temporelle d'un certificat présent é par la carte, une VU 
utilise son horloge intern e.  26.5.2016 L 139/380 Jour nal officiel de l'Union européenne FR     
Figure 4 
Protocole de vérification de la chaîne de certificat de la carte par la VU 
10.2.2  Vérification de la chaîne de certificat de la VU par la carte 
CSM_161  Les cartes tach ygraphiques adopt ent le protocole prévu à la Figure 5 pour vérifier la chaîne de 
certificat d'une VU. 26.5.2016 L 139/381 Jour nal officiel de l'Union européenne FR     
Figure 5 
Protocole de vérification de la chaîne de certificat de la VU par la carte 
26.5.2016 L 139/382 Jour nal officiel de l'Union européenne FR     
Notes relatives à la Figure 5: 
—Les certificat s et les clés publiques associés à la VU mentionnés sur cette figure sont ceux de l'authentif i­
cation mutuelle. La section 9.1.4 précise leur intitulé: VU_MA. 
—  Les certificats et les clés publiques VU.C A mentionnés sur cette figure sont ceux de la signature des 
certificats de la VU et du dispositif GNSS externe. La section 9.1.3 précise leur intitulé: MSCA _VU-EGF . 
—  Le certificat VU.CA .EUR mentionné sur cette figur e est le certificat racine européen indiqué dans le CAR 
du certificat VU.CA . 
—  Le certificat VU.Link mentionné sur cette Figure est le certificat de lien de la VU, le cas échéant. Comme le 
précise la section 9.1.2, il s'agit d'un certificat de lien pour une nouvelle paire de clés racine européenne 
créé par l'ERCA et signé par la précédente clé privée européenne. 
—  Le certificat VU.Link.EUR est le certificat racine européen indiqué dans le CAR du certificat VU.Link. 
CSM_162  Comme l'illustre la Figure 5, la vérification de la chaîne de certificat de la VU commence avec la 
tentative de la VU de fixer sa propre clé publique afin de l'utiliser dans la carte tach ygraphique. En 
cas de réussite, cela signif ie que la carte a déjà vérifié la chaîne de certificat de la VU par le passé et 
a mémor isé le certificat de la VU pour l'utiliser ultérieurement. Dans ce cas, le certificat de la VU 
est prêt à servir et la procédure se poursuit avec l'authentification de la VU. Si la carte ne reconnaît 
par le certificat de la VU, la VU présente successivement le certificat MSCA _VU afin de vérifier le 
certificat de la VU, le certificat VU.CA .EUR afin de vérifier le certificat MSCA _VU et éventuellement 
le certificat de lien dans le but d'identif ier un certificat que la carte connaisse. Si un tel certificat est 
reconnu, la carte utilise ce certificat pour vérifier les certificats VU sous-jacents qui lui sont 
présent és. En cas de réussite , la VU définit finalement sa clé publique pour l'utiliser dans la carte 
tach ygraphique. En cas d'échec, la VU ignore la carte. 
Remarque: la carte peut connaître le certificat VU.CA .EUR pour trois raisons: 
—  le certificat VU.CA .EUR est identique à celui de la VU; 
—  le certificat VU.CA .EUR précède celui de la VU et la carte contient ce certificat dès son émission 
(cf. CSM_91); 
—  le certificat VU.CA .EUR succède à celui de la carte, et la carte a reçu un certificat de lien d'une 
autre VU, l'a vérifié et mémor isé pour une utilisation ultérieure. 
CSM_163  La VU utilise la commande MSE: Set AT pour définir sa clé publique et l'utiliser dans la carte 
tach ygraphique. Comme spécifi é dans l'appendice 2, cette commande contient une indication du 
mécanisme cryptographi que qui servira avec la clé définie. Ce mécanisme correspond à l'authentifi ­
cation de la VU utilisant l'algor ithme ECDS A, en combinaison avec l'algor ithme de hacha ge associé 
à la taille de clé de la paire de clés VU_MA de la VU, comme le spécifie le CSM_50. 
CSM_164  La commande MSE: Set AT contient également une indication de la paire de clés éphémères 
qu'utilise la VU pendant la concordance des clés de session (cf. section 10.4). Par conséquent, avant 
d'en voyer la commande MSE: Set AT, la VU génère une paire de clés ECC éphémères. Pour la 
génération de la paire de clés éphémères, la VU utilise les paramètres de domaine normalisés 
indiqués par le certificat de la carte. La paire de clés éphémères est noté e (VU.SKeph, VU.PKeph, Card. 
DP). La VU utilise l'abscisse du point public éphémère ECDH comme identification de clé; il s'agit 
de la représentation comprim ée de la clé publique appelée Comp (VU.PKeph). 
CSM_165  Si la commande MSE: Set AT aboutit, la carte définit le VU.PK indiqué pour une utilisation 
ultérieure pendant l'authentif ication de la VU et mémor ise temporairement Com p(VU.PKeph). Si 
plusieurs commandes MSE: Set AT aboutissent, elles sont adressées avant de procéder à la 
concordance des clés de session. La carte mémor ise uniquement le dernier Comp(VU.PKeph) reçu. 26.5.2016 L 139/383 Jour nal officiel de l'Union européenne FR     
CSM_166  La carte vérifie la validité temporelle de tout certificat présent é par la VU ou référencé par la VU 
pendant qu'il était en mémoire dans la carte et refuse les certificats expirés. 
CSM_167  Pour vérifier la validité temporelle d'un certificat présent é par la VU, chaque carte tach ygraphique 
stoc ke en interne des données représentant le temps actuel. Ces données ne sont pas directe ment 
actualisables par une VU. Enfin, l'heure actuelle d'une carte est définie comme étant la date effective 
du certificat Card_MA de la carte. Une carte actualise son heure actuelle si la Date effective d'un 
certificat authentique représentant une «source d'heure valide» présenté par une VU est plus récente 
que l'heure actuelle de la carte. Dans ce cas, la carte définit son heure actuelle sur la date effective 
dudit certificat . La carte accept e uniquement les certificats suivants comme source d'heure valide: 
—  certificats de lien ERCA de deuxième génération; 
—  certificats MSCA de deuxième génération; 
—  certificats de VU de deuxième génération émis par le même pays que le ou les certificat(s) de 
carte de ladite carte. 
Note: la dernière exige nce implique qu'une carte doit pouv oir reconnaître le CAR du certificat de la 
VU, p. ex. le certificat MSCA_VU-EGF . Il ne s'agit pas du même que le CAR de son propre 
certificat, qui est le certificat MSCA_Card. 
CSM_168  Comme l'indique la Figure 5, une fois que la carte a vérifié l'authenticit é et la validité d'un certificat 
encore inconnu, elle le mémor ise pour l'utiliser ultérieurement, de manière à ne pas devoi r le 
vérifier à nouveau s'il lui est représent é. Au lieu de mémor iser la totalit é du certificat, une carte 
peut choisir de ne mémor iser que le contenu du corps du certificat, conf ormément à la section 
9.3.2. 
10.3.  Authentif ication de VU 
CSM_169  Les unités embarquées sur véhicule et les cartes adopt ent le protocole d'authentification de VU 
illustré sur la Figure 6 pour authentifi er la VU par rappor t à la carte. L'authentification de la VU 
permet à la carte tach ygraphique de vérifier explicitement l'authenticit é de la VU. Pour ce faire , la 
VU utilise sa clé privée pour signer un défi généré par la carte. 
CSM_170  La VU inclut à proximité du défi de la carte, la signature de la référence du titulaire de la carte 
extraite du certificat de la carte. 
Remarque: cela garantit que la carte auprès de laquelle la VU s'authentifie est la même que celle dont 
la VU a préalablement vérifié la chaîne de certificat. 
CSM_171  La VU insère également dans la signature l'identifi cateur de la clé publique éphémère Comp (VU. 
PKeph) que la VU utilise pour définir la messag erie sécur isée pendant la procédure d'authentifi cation 
de circuit, conf ormément aux spécifications de la section 10.4. 
Remarque: cela garant it que la VU avec laquelle une carte communique pendant une session de 
message rie sécur isée est la même VU que celle authentifiée par la carte.  26.5.2016 L 139/384 Jour nal officiel de l'Union européenne FR     
Figure 6 
Protocole d'authentif ication de la VU 
CSM_172  Si la VU envoie plusieurs commandes GET CHALLENGE pendant son authentification, la carte 
renv oie un nouveau défi aléatoi re sur 8 octets à chaque fois, mais mémor ise uniquement le dernier. 
CSM_173  L'algor ithme de signature utilisé par la VU pour authentifi er la VU est l'ECDS A préconisé par les 
[DSS], en combinaison avec l'algor ithme de hachag e associé à la taille de clé de la paire de clés 
VU_MA de la VU, conf ormément au CSM_50. La structure de la signature est en clair , 
conf ormément au [TR-03111]. La VU adresse la signature produite à la carte. 
CSM_174  À réception de la signature de la VU dans une commande EXTERNAL AUTHENTICA TE, la carte: 
—  calcule le jeton d'authentifi cation en concaténant Card.CH R, le lanceur de défis de la carte rcard 
et l'identifi cateur de la clé publique éphémère de la VU Comp(VU.PKeph); 
—  calcule le hachag e en fonction du jeton d'authentifi cation, à l'aide de l'algor ithme de hachag e 
associé à la taille de clé de la paire de clés VU_MA de la VU, conf ormément au CSM_50; 
—  vérifie la signature de la VU à l'aide de l'algor ithme ECDSA combiné au VU.PK et au hachag e 
calculé. 
10.4.  Authentif ication du circuit et concordance des clés de session 
CSM_175  Les unités embarquées sur véhicule et les cartes adopt ent le protocole d'authentification de circuit 
illustré sur la Figure 7 pour authentifier la carte par rappor t à la VU. L'authentificati on du circuit 
permet à l'unit é embarquée sur véhicule de vérifier explicite ment l'authenticit é de la carte. 26.5.2016 L 139/385 Jour nal officiel de l'Union européenne FR     
Figure 7 
Authentif ication du circuit et concordance des clés de session 
CSM_176  La VU et la carte suivent les étapes suivantes :  
1. La VU lance la procédure d'authentific ation du circuit en adressant la commande MSE: Set AT 
indiquant «Authenti fication du circuit à l'aide de l'algor ithme ECDH produisant une longueur de 
clés de session AES liée à la taille de clé de la paire de clés Card_MA de la carte, conf ormément 
au CSM_50». La VU détermine la taille de clé de la paire de clés de la carte d'après le certificat 
de la carte.  
2. La VU adresse le point public VU.PKeph de sa paire de clés éphémères à la carte. Conf ormément 
au CSM_164, la VU génère cette paire de clés éphémères avant de vérifier la chaîne de certificat 
de la VU. La VU a envoyé l'identif icateur de la clé publique éphémère Comp(VU.PKeph) à la carte 
qui l'a mémor isé.  
3. La carte calcule Com p(VU.PKeph) d'après VU.PKeph et compare le résultat avec la valeur 
mémor isée de Comp(VU.PKeph).  
4. À l'aide de l'algor ithme ECDH combiné à la clé privée statique de la carte et la clé publique 
éphémère de la VU, la carte calcule un K secret.  
5. La carte choisit un mot aléatoi re forgé pour l'occasion sur 8 octets NPICC et l'utilise pour calculer 
les deux clés de session AES KMAC et KENC d'après K. Cf. CSM_179.  
6. En utilisant KMAC, la carte calcule un jeton d'authentification en fonction de l'identifi cateur de la 
clé publique éphémère de la VU: TPICC = CMA C(KMAC, VU.PKeph). La carte envoie NPICC et TPICC à 
l'unit é embarquée sur véhicule.  
7. À l'aide de l'algor ithme ECDH combiné à la clé publique statique de la carte et la clé privée 
éphémère de la VU, la VU calcule le même K secret que la carte à l'étape 4. 26.5.2016 L 139/386 Jour nal officiel de l'Union européenne FR     
8. La VU calcule les clés de session KMAC et KENC d'après K et NPICC; cf. CSM_179  
9. La VU vérifie le jeton d'authentifi cation TPICC. 
CSM_177  À l'étape 3 ci-dessus, la carte calcule Com p(VU.PKeph) comme l'abscisse du point public dans VU. 
PKeph. 
CSM_178  Aux étapes 4 et 7 ci-dessus, la carte et l'unité embarquée sur véhicule utilisent l'algor ithme ECK A- 
EG défini au [TR-03111]. 
CSM_179  Aux étapes 5 et 8 ci-dessus, la carte et l'unit é embarquée sur véhicule utilisent la fonction de 
dérivation de clé pour les clés de session AES définie au [TR-03111], en respectant les précisions et 
modifi cations suivantes: 
—  La valeur du comp teur est de ‘00 00 00 01’ pour KENC et de ‘00 00 00 02’ pour KMAC. 
—  Le numéro à usag e unique r est utilisé et est égal à NPICC. 
—  Pour calculer les clés AES 128 bits, l'algor ithme de hachag e à utiliser est SHA-256. 
—  Pour calculer les clés AES 192 bits, l'algor ithme de hachag e à utiliser est SHA-384. 
—  Pour calculer les clés AES 256 bits, l'algor ithme de hachag e à utiliser est SHA-512. 
La longueur des clés de session (c'est-à-dire la longueur à laquelle le hachag e est tronqué) est liée à 
la taille de la paire de clés Card_MA, conf ormément au CSM_50. 
CSM_180  Aux étapes 6 et 9 ci-dessus, la carte et l'unit é embarquée sur véhicule utilisent l'algor ithme AES en 
mode CMA C, conf ormément au [SP 800-38B]. La longueur de TPICC est liée à la longueur des clés 
de session AES, conf ormément au CSM_50. 
10.5.  Messager ie sécur isée 
10.5.1  Génér alités 
CSM_181  Toutes les commandes et réponses échang ées entre une unité embarquée sur véhicule et une carte 
tach ygraphique après authentifi cation réussie du circuit et jusqu'à la fin de la session sont protég ées 
par la messager ie sécur isée. 
CSM_182  Hor mis la lecture d'un fichier avec les règles d'accès SM-R -ENC-MA C-G2 (cf. appendice 2, section 
4), la messager ie sécur isée sert uniquement en mode d'authentifi cation. Dans ce mode, un total de 
contrôle cryptographique (MA C) s'ajoute à tout es les commandes et réponses pour garantir 
l'authenticit é et l'inté grité du messag e. 
CSM_183  Lors de la lecture de données provenant d'un fichier soumis aux règles d'accès SM-R -ENC-MA C-G2, 
la message rie sécur isée est utilisée en mode chiffrer -puis-authentif ier. Cela signif ie que les données 
de réponse sont d'abord cryptées pour assurer la conf identialit é du message , puis qu'un MAC est 
calculé par rappor t aux données cryptées formatée s pour garantir l'authenticit é et l'intégrité. 
CSM_184  La messager ie sécur isée utilise AES comme défini en [AES] avec les clés de session KMAC et KENC 
conven ues pendant l'authentif ication du circuit. 
CSM_185  Un entier non signé sert de comp teur de séquences à l'émission (SSC) pour empê cher les attaques 
par relecture. La taille du SSC est égale à la taille du bloc AES, soit 128 bits. Le SSC respecte la 
structure MSB-First. Le comp teur de séquences d'en voi est initialisé à zéro (c'est-à-dire ‘00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00’) au lancement de la messager ie sécur isée. Le SSC est 
incrément é avant chaque commande ou réponse APDU générée, c'est-à-dire que la valeur de dépar t 
du SSC dans une session de SM est égale à zéro et qu'à la première commande, la valeur du SSC est 
égale à un. La valeur du SSC pour la première réponse est égale à deux. 26.5.2016 L 139/387 Jour nal officiel de l'Union européenne FR     
CSM_186  En ce qui concer ne le cryptag e des messag es, KENC est utilisé avec l'AES dans le mode d'exploitation 
par chaînage de cryptage par blocs (CBC), tel que le définit la norme [ISO 10116], en respectant un 
paramètre d'entrelacement de m = 1 et un vecteur d'initialisation SV = E(KENC SSC), c'est-à-dire la 
valeur actuelle du comp teur de séquences d'en voi cryptée avec KENC. 
CSM_187  En ce qui concer ne l'authentif ication de messag e, KMAC est utilisé avec AES en mode CMA C 
conf ormément au [SP 800-38B]. La longueur de MAC est liée à la longueur des clés de session 
AES, conf ormément au CSM_50. Le comp teur de séquence d'env oi est inclus dans le MAC en le 
préfixant avant le datagramme à authentifier . 
10.5.2  Structure de message sécur isé 
CSM_188  La messager ie sécur isée n'utilise que des objets de données de messager ie sécur isée (cf. [ISO 7816- 
4]) au Tableau 5. Dans tous les messages, ces objets de données servent dans l'ordre défini par ce 
tableau. 
Tableau 5 
Objets de données de messager ie sécur isée 
Nom de l'objet de données Balise Présence Obligat oire (M), Condition ­
nelle (C) ou Interdit e (F) dans 
Commandes Réponses 
Valeur en clair non codée en BER -TLV ‘81’ C C 
Valeur en clair codée BER -TLV sans SM-DO ‘B3’ C C 
Indicateur de contenu de remplissag e par crypto­
gramme, valeur en clair non codée en BER -TLV ‘87’ C C 
Le proté gé ‘97’ C F 
État de traitement ‘99’ F M 
Total de contrôle cryptographique ‘8E’ M M  
Remarque: comme le précise l'appendice 2, les cartes tach ygraphiques sont compat ibles avec les 
commandes READ BINAR Y et UPD ATE BINAR Y avec un octet imp air INS (‘B1’ resp. ‘D7’). Ces 
variantes de commande sont nécessaires pour lire et actualiser des fichiers de 32 768 octets et 
davan tage. Dans ce cas, on utilise la variante suivante: un objet de données avec la balise ‘B3’ plutôt 
qu'un objet avec la balise ‘81’. Cf. appendice 2 pour tout e information compl émentaire. 
CSM_189  Tous les objets de données de SM sont codés DER -TLV conf ormément à la norme [ISO 8825-1]. Ce 
crypta ge produit la structure Tag-Length- Value (TLV) suivante: 
Balise:  la balise est cryptée sur un ou deux octet(s) et indique le conte nu. 
Longueur :  la longueur est cryptée comme un entier non signé sur un, deux ou trois octet(s), soit 
une longueur maximale de 65 535 octets. On utilise le nombre minimal d'oct ets. 
Valeur:  la valeur est cryptée sur zéro octet ou plus. 26.5.2016 L 139/388 Jour nal officiel de l'Union européenne FR     
CSM_190  Les APDU prot égés par la messager ie sécur isée sont créés de la manière suivante : 
—  L'entêt e de commande est inclus dans le calcul MAC, par conséquent la valeur ‘0C’ sert pour 
l'octe t de classe CLA. 
—  Comme le précise l'appendice 2, tous les octets INS sont pairs, hormis éventuellement les octets 
INS impairs des commandes READ BINAR Y et UPD ATE BINAR Y. 
—  La valeur réelle de Lc est modifiée en Lc' après l'application de la messag erie sécur isée. 
—  La zone de données se compo se d'objets de données SM. 
—  Dans la commande protég ée APDU, le nouvel octet Le est défini à ‘00’. Si nécessaire, un objet 
de données ‘97’ est inclus dans le champ de données afin de transmettre la valeur initiale de Le. 
CSM_191  Tout objet de données à chiffrer doit être compl été conf ormément à la norme [ISO 7816-4] en 
utilisant l'indicateur ‘01’ de contenu de rem plissage. Concer nant le calcul du MAC, chaque objet de 
données de l'APDU est également compl été séparément conf ormément à la norme [ISO 7816-4]. 
Remarque: le rem plissage destiné à la messager ie sécur isée est touj ours affect é à la couc he de 
message rie sécur isée, jamais aux algor ithmes CMA C ou CBC. 
Résumé et exemples 
Une commande APDU de la messag erie sécur isée appliquée respecte la structure suivante, selon le cas de 
chaque commande non sécur isée (DO correspond à l'objet de données): 
Cas 1: CLA INS P1 P2 || Lc' || DO ‘8E’ || Le 
Cas no 2: CLA INS P1 P2 || Lc' || DO ‘97’ || DO‘8E’ || Le 
Cas no 3 (octet INS pair): CLA INS P1 P2 || Lc' || DO ‘81’ || DO‘8E’ || Le 
Cas 3 (octet INS impair): CLA INS P1 P2 || Lc' || DO ‘B3’ || DO‘8E’ || Le 
Cas no 4 (octet INS pair): CLA INS P1 P2 || Lc' || DO ‘81’ || DO‘97’ || DO'8E' || Le 
Cas 4 (octet INS impair): CLA INS P1 P2 || Lc' || DO ‘B3’ || DO‘97’ || DO‘8E’ || Le  
où Le = ‘00’ ou ‘00 00’ selon que l'on utilise des zones de longueur cour te ou étendue; cf. [ISO 7816-4]. 
Une réponse APDU de la messag erie sécur isée appliquée respecte la structure suivante, selon le cas de chaque 
réponse non sécur isée: 
Cas 1 ou 3: DO ‘99’ || DO ‘8E’ || SW1SW2 
Cas no 2 ou no 4 (octet INS pair) avec codage: DO ‘81’ || DO ‘99’ || DO ‘8E’ || SW1SW2 
Cas 2 ou 4 (octet INS pair) sans cryptag e: DO ‘87’ || DO ‘99’ || DO ‘8E’ || SW1SW2 
Cas 2 ou 4 (octet INS impair) sans cryptage: DO ‘B3’ || DO ‘99’ || DO ‘8E’ || SW1SW2  
Remarque: Les cas 2 ou 4 (octet INS imp air) avec cryptag e ne servent jamais pour la communication entre une 
VU et une carte. 26.5.2016 L 139/389 Jour nal officiel de l'Union européenne FR     
Ci-après suivent trois exem ples de transf ormations APDU pour des commandes avec un code INS pair . La 
Figure 8 illustre une commande APDU authentifiée relevant du cas 4, la Figure 9 illustre une réponse APDU 
authentifiée relevant des cas 2 ou 4 et la Figure 10 indique une réponse APDU cryptée et authentifiée relevant 
des cas 2 ou 4. 
Figure 8 
Transforma tion d'une commande APDU authentif iée relevant du cas 4 
Figure 9 
Transfor mation d'une réponse APDU authentif iée relevant des cas 1 ou 3 
26.5.2016 L 139/390 Jour nal officiel de l'Union européenne FR     
Figure 10 
Transf ormation d'une réponse APDU cryptée et authentif iée relevant des cas 2 ou 4 
10.5.3  Abandon de la session de message rie sécur isée 
CSM_192  Une unité embarquée sur véhicule abandonne une session de messager ie sécur isée en cours si et 
seulement si l'une des conditions suivantes survient : 
—  elle reçoit une réponse APDU en clair , 
—  elle détect e une erreur de message rie sécur isée dans une réponse APDU: 
—  un objet de données de messag erie sécur isée manque, l'ordre des objets de données est 
erroné ou un objet de données inconnu est présent. 
—  un objet de données de la messager ie sécur isée est erroné, p. ex. la valeur MAC est erronée, 
la structure TLV est erronée ou l'indicateur de rem plissage de la balise ‘87’ est égal à ‘01’. 
—  la carte adresse un octet d'état indiquant qu'il a détecté une erreur de SM (cf. CSM_194), 
—  la limite pour le nombre de commandes et de réponses associées de la session actuelle est 
atteinte. Pour une VU donnée, cette limite est définie par son fabricant et tient comp te des 
exige nces de sécur ité du matér iel utilisé, avec une valeur maximale de 240 commandes et 
réponses associées de SM par session. 
CSM_193  Une carte tach ygraphique abandonne une session de messag erie sécur isée en cours si et seulement 
si l'une des conditions suivantes survient : 
—  elle reçoit une réponse APDU en clair , 26.5.2016 L 139/391 Jour nal officiel de l'Union européenne FR     
—  elle détect e une erreur de message rie sécur isée dans une commande APDU: 
—  un objet de données de messag erie sécur isée manque, l'ordre des objets de données est 
erroné ou un objet de données inconnu est présent. 
—  un objet de données de la message rie sécur isée est erroné, p. ex. la valeur MAC est erronée 
ou la structure TLV est erronée. 
—  l'alimentation est coupée ou la carte est réinitialisée, 
—  la VU sélectionne une application sur la carte, 
—  la VU entame la procédure d'authentifi cation de la VU, 
—  la limite pour le nombre de commandes et de réponses associées de la session actuelle est 
atteinte. Pour une carte donnée, cette limite est définie par son fabr icant et tient comp te des 
exige nces de sécur ité du matér iel utilisé, avec une valeur maximale de 240 commandes et 
réponses associées de SM par session. 
CSM_194  Concer nant la gestion des erreurs de SM par une carte tach ygraphique: 
—  si dans une commande APDU, certains objets de données de messager ie sécur isée attendus 
manquent, l'ordre des objets de données est erroné ou des objets de données inconnus sont 
présents, une carte tach ygraphique répond au moyen des octets d'état ‘69 87’. 
—  si un objet de données de messager ie sécur isée dans une commande APDU est erroné, une 
carte tach ygraphique répond au moyen des octets d'état ‘69 88’. 
Dans ce cas, les octets d'état sont renv oyés sans utiliser la SM. 
CSM_195  Si une session de Message rie sécur isée entre une VU et une carte tach ygraphique est abandonnée, la 
VU et la carte tach ygraphique: 
—  détr uisent de façon sécur isée les clés de sessions mémor isées; 
—  établissent immédiatement une nouvelle session de messag erie sécur isée, conf ormément aux 
dispositions des sections 10.2 à 10.5. 
CSM_196  Si pour une raison quelconque, la VU décide de redémar rer une authentification mutuelle vis-à-vis 
d'une carte insérée, la procédure est relancée avec la vérification de la chaîne de certificat ion de la 
carte, conf ormément aux dispositions de la section 10.2 et continue conf ormément aux 
dispositions des sections 10.2 à 10.5. 
11.  COUPLA GE DE L'UV ET DU DISPOSITIF GNSS, AUTHENTIFICA TION MUTUELLE ET MESSA GERIE SÉCURISÉE 
11.1.  Généralités 
CSM_197  Le dispositif GNSS qu'utilise une VU pour déterminer sa position peut être intern e (c'est-à-dire 
intégré au boîtier de la VU et non extractible) ou extern e (module indépendant). Dans le premier 
cas, il n'est pas nécessaire de normaliser la communication intern e entre le dispositif GNSS et la 
VU. Les exigenc es du présent chapitre ne s'appliquent donc pas. Dans le deuxième cas, il est 
nécessaire de normaliser la communication entre le dispositif GNSS et la VU. Les exigences de 
prote ction du présent chapitre s'appliquent donc. 
CSM_198  La sécur isation des communications échangées entre une unité embarquée sur véhicule et un 
dispositif GNSS extern e passe par les mêmes exige nces que la communication sécur isée entre une 
unité embarquée sur véhicule et une carte tach ygraphique. Le dispositif GNSS externe (EGF) joue le 
rôle de la carte tach ygraphique. Toutes les exige nces mentionnées au chapitre 10 pour les cartes 
tach ygraphiques sont satisfa ites par l'EGF et tiennent comp te des écar ts, clarifications et ajouts 
mentionnés au présent chapitre. En particulier , la vérification de la chaîne de certification mutuelle, 
l'authentif ication de la VU et l'authentif ication du circuit sont menées conf ormément aux 
dispositions des sections 11.3et 11.4. 26.5.2016 L 139/392 Jour nal officiel de l'Union européenne FR     
CSM_199 La communication entre une unité embarquée sur véhicule et un EGF se distingue de la communi ­
cation entre une unité embarquée sur véhicule et une carte tach ygraphique en cela qu'une unité 
embarquée sur véhicule et un EGF doivent être couplés une fois dans l'ate lier avant que la VU et 
l'EGF puissent échanger des données basées GNSS en fonctionnement normal. Le processus de 
couplage fait l'objet d'une descr iption détaillée à la section 11.2. 
CSM_200  Concer nant la communication entre une unité embarquée sur véhicule et un EGF , on utilise les 
commandes et les réponses APDU relevant des normes [ISO 7816-4] et [ISO 7816-8]. La structure 
exacte de ces APDU fait l'objet d'une descr iption détaillée en appendice 2 de la présente Annex e. 
11.2.  couplage d'une VU et d'un dispositif exter ne GNSS 
CSM_201  Une unité embarquée sur véhicule et un EGF sont couplés par un atelier. Seuls une unité 
embarquée sur véhicule et un EGF couplés peuvent communiquer en fonctionnement normal. 
CSM_202  Le couplage d'une unité embarquée sur véhicule et d'un EGF n'est possible que si la VU est en 
mode étalonnage. Le couplage est lancé par l'unité embarquée sur le véhicule. 
CSM_203  Un ateli er peut coupler de nouveau une unité embarquée sur véhicule à un autre EGF ou au même 
EGF , et ce, à tout moment. Pendant le nouveau couplage, la VU détr uit effic acement le certificat 
EGF_MA existant mémor isé et enregistre le certificat EGF_MA de l'EGF auquel elle vient d'être 
couplée. 
CSM_204  Un atelier peut coupler de nouveau un EGF à une autre unité embarquée sur véhicule ou à la 
même, et ce, à tout moment. Pendant le nouveau couplage, l'EGF détr uit efficacement le certificat 
VU_MA existant mémor isé et enregistre le certificat VU_MA de la VU à laquelle il vient d'être 
couplé. 
11.3.  Vér ification mutuelle de la chaîne de certificat 
11.3.1  Génér alités 
CSM_205  La vérification de la chaîne de certificat ion mutuelle entre une VU et un EGF prend place 
uniquement durant le couplage d'une VU et d'un EGF par un ateli er. Pendant le fonctionnement 
normal d'une VU et d'un EGF couplés, aucun certificat n'est vérifié. La VU et l'EGF font confiance 
aux certificats mémor isés pendant le couplage , après avoir vérifié leur validité dans le temps. La VU 
et l'EGF ne font conf iance à aucun autre certificat pour protég er la communication entre la VU et 
l'EGF en fonctionnement normal. 
11.3.2  Pendant le couplag e VU — EGF 
CSM_206  Pendant le couplage à un EGF , une unité embarquée sur véhicule utilise le protocole décr it à la 
Figure 4 (section 10.2.1) pour vérifier la chaîne de certification de l'EGF . 
Notes relatives à la Figure 4 dans ce contexte: 
—  Le contrôle de la communication sort du cham p d'application du présent appendice. 
Cependant, un EGF n'est pas une carte intelligent e. La VU n'en verra donc vraisemblablement 
pas une Réinitialisation pour lancer la communication et ne recevra pas d'ATR. 
—  Les certificat s et les clés publiques associés à la carte mentionnés sur cette Figure sont ceux de 
l'EGF en vue de l'authentification mutuelle. La section 9.1.6 précise leur intitulé: EGF_MA. 
—  Les certificats et les clés publiques Card.CA mentionnés sur cette Figure sont ceux du MSCA en 
vue de la signature des certificats EGF . La section 9.1.3 précise leur intitulé: MSCA_ VU-EGF . 26.5.2016 L 139/393 Jour nal officiel de l'Union européenne FR     
—  Le certificat Card.CA .EUR mentionné sur cette Figure est le certificat racine européen indiqué 
dans le CAR du certificat MSCA_VU-EGF . 
—  Le certificat Card.Link mentionné sur cette Figure correspond au certificat de lien de l'EGF , le 
cas éché ant. Comme le précise la section 9.1.2, il s'agit d'un certificat de lien pour une nouvelle 
paire de clés racine européenne créé par l'ERCA et signé par la précédente clé privée 
européenne. 
—  Le certificat Card.Link.E UR est le certificat racine européen indiqué dans le CAR du certificat 
Card.Link. 
—  Au lieu du 
 , la VU lit le 
 depuis 
l'EF ICC. 
—  Au lieu de sélectionner l'AID de la carte tach ygraphique, la VU sélectionne l'AID de l'EGF . 
—  «Ignorer la carte» devient «Ignorer l'EGF». 
CSM_207  Une fois le certificat EGF_MA vérifié, l'unité embarquée sur véhicule mémor ise ce certificat pour 
l'utiliser en fonctionnement normal; cf. section 11.3.3. 
CSM_208  Pendant le couplage à une VU, un dispositif GNSS extern e utilise le protocole décr it à la Figure 5 
(section 10.2.2) pour vérifier la chaîne de certificat ion de la VU. 
Notes relatives à la Figure 5 dans ce contexte: 
—  La VU génère une nouvelle paire de clés éphémères en utilisant les paramètres de domaine du 
certificat EGF . 
—  Les certificat s et les clés publiques associés à la VU mentionnés sur cette Figure sont ceux de 
l'authentification mutuelle. La section 9.1.4 précise leur intitulé: VU_MA. 
—  Les certificat s et les clés publiques VU.CA mentionnés sur cette Figure sont ceux de la signature 
des certificats de la VU et du dispositif GNSS externe. La section 9.1.3 précise leur intitulé: 
MSCA_VU-EGF . 
—  Le certificat VU.C A.EUR mentionné sur cette Figure est le certificat racine européen indiqué 
dans le CAR du certificat VU.CA . 
—  Le certificat VU.Link mentionné sur cette Figure est le certificat de lien de la VU, le cas échéant. 
Comme le précise la section 9.1.2, il s'agit d'un certificat de lien pour une nouvelle paire de clés 
racine européenne créé par l'ERCA et signé par la précédente clé privée européenne. 
—  Le certificat VU.Link.EUR est le certificat racine européen indiqué dans le CAR du certificat VU. 
Link. 
CSM_209  À titre d'excep tion par rappor t à l'exigence du CSM_167, un EGF utilise le temps GNSS pour 
vérifier la validité dans le temps de tout certificat présent é. 
CSM_210  Une fois le certificat VU_MA vérifié, le dispositif GNSS externe mémor ise ce certificat pour l'utiliser 
en fonctionnement normal; cf. section 11.3.3. 
11.3.3  Pendant le fonctionnement normal 
CSM_211  En fonctionnement normal, une unité embarquée sur véhicule et un EGF respectent le protocole 
décr it sur la Figure 11 pour vérifier la validité dans le temps des certificats EGF_MA et VU_MA 
mémor isés et pour définir la clé publique VU_MA en vue de l'authentif ication ultéri eure de la VU. 
Aucune autre vérification mutuelle des chaînes de certificats n'a lieu en fonctionnement normal. 26.5.2016 L 139/394 Jour nal officiel de l'Union européenne FR     
Note: la Figure 11 illustre essentiellement les premières étapes indiquées sur les Figure 4 et Figure 5. 
Cependant, un EGF n'étant pas une carte intelli gent e, la VU n'en verra donc vraisemblablement pas 
une réinitialisation pour lancer la communication et ne recevra pas d'ATR. Dans tous les cas, cela 
sort du champ d'application du présent appendice. 
Figure 11 
Vér ification mutuelle de la validité dans le temps du certificat en fonctionnement nor mal entre la VU et l'EGF 
CSM_212  Comme l'illustre la Figure 11, l'unité embarquée sur véhicule enregistre une erreur si le certificat 
EGF_MA n'est plus valide. Cependant, l'authentification mutuelle, la concordance des clés et la 
communication ultéri eure au moyen de la messager ie sécur isée se déroulent normalement. 
11.4.  Authentif ication de la VU, Authentif ication du circuit et concordance des clés de session 
CSM_213  L'authentificati on de la VU, l'authentif ication du circuit et la concordance des clés de la session 
entre une VU et un EGF ont lieu pendant le couplage et dès qu'une session de messager ie sécur isée 
est réétablie en fonctionnement normal. La VU et l'EGF exécut ent les procédures décr ites aux 
sections 10.3 et 10.4. Toutes les exige nces prévues dans ces sections s'appliquent. 
11.5.  Messager ie sécur isée 
CSM_214  Toutes les commandes et réponses échang ées entre une unité embarquée sur véhicule et un 
dispositif GNSS externe après l'authentif ication réussie du circuit et jusqu'à la fin de la session sont 
proté gées par la messager ie sécur isée en mode authentifi cation uniquement. Toutes les exigenc es 
prévues dans la section 10.5 s'appliquent. 
CSM_215  Si une session de message rie sécur isée entre une VU et un EGF est abandonnée, la VU établit 
immédiatem ent une nouvelle session de messager ie sécur isée, comme le prévoi ent les sections 
11.3.3 et 11.4. 26.5.2016 L 139/395 Jour nal officiel de l'Union européenne FR     
12.  COUPLA GE ET COMMUNIC ATION DE LA VU ET DU CAPTEUR DE MOUVEMENT 
12.1.  Généralités 
CSM_216  Une unité embarquée sur véhicule et un capt eur de mouvement communiquent à l'aide du 
protocole d'interface prévu par la norme [ISO 16844-3] pendant le couplage et le fonctionnement 
normal. Cela inclut les chang ements prévus au présent chapitre et à la section 9.2.1. 
Note: les lecteurs de la présente section sont censés maîtr iser le cont enu de la norme [ISO 
16844-3]. 
12.2.  Couplage de la VU et du capteur de mouv ement à l'aide de générations de clés différentes 
Comme expliqué à la section 9.2.1, la clé maîtresse du capt eur de mouvement et tout es les clés associées sont 
régulièrement rem placées. Cela entraîne la présence de trois clés AES KM-W C liées au capt eur de mouvement, au 
maximum, (de générations de clés consécutives) sur les cartes d'ateli er. De même, un maximum de trois 
différ ents cryptages de données de type AES (sur la base de générations consécutives de clé maîtresse KM du 
capt eur de mouvement) peuvent être présents sur les capt eurs de mouvement. Une unité embarquée sur 
véhicule contient une seule clé KM-V U associée au capt eur de mouvement. 
CSM_217  Une VU et un capt eur de mouvement de deuxième génération sont couplés comme suit (com parer 
au tableau 6 de la norme [ISO 16844-3]):  
1. Une carte d'ateli er de deuxième génération est insérée dans la VU et cette dernière est raccordée 
au capt eur de mouvement.  
2. La VU lit tout es les clés KM-W C disponibles sur la carte d'atelier , inspecte leur numéro de version 
de clé et choisit celui qui correspond au numéro de version de la clé VU KM-V U. Si la clé KM-WC 
correspondante est absente de la carte d'ateli er, la VU abandonne la procédure de couplage et 
affiche le message d'erreur appropr ié pour le titulaire de la carte d'ateli er.  
3. La VU calcule la clé maîtresse du capt eur de mouvement KM à partir de KM-VU et de KM-W C, et 
calcule la clé d'identif ication KID à partir de KM, comme le prévoit la section 9.2.1.  
4. La VU envoie les instr uctions pour lancer la procédure de couplage par rappor t au capt eur de 
mouvement, comme le prévoit la norme [ISO 16844-3] et chiffre le numéro de série reçu du 
capt eur de mouvement avec la clé d'identif ication KID. génération. En retour , la VU envoie le 
numéro de série crypté au capt eur de mouvement.  
5. Le capt eur de mouvement compare le numéro de série crypté consécutivement avec les 
cryptages des numéros de série dont il dispose en intern e. S'il identif ie une correspondance, la 
VU est authentifiée. Le capt eur de mouvement prend note de la génération de KID qu'utilise la 
VU et renv oie la version codée correspondante de sa clé de couplage; c'est-à-dire que le codage a 
été créé avec la même génération de KM.  
6. La VU déchiffre la clé de couplage à l'aide de KM, génère une clé de session KS,, la chiffre à l'aide 
d'une clé de couplag e et envoie le résultat au capt eur de mouvement. Le capt eur de mouvement 
déch iffre KS.  
7. La VU assemble les informations de couplag e comme le prévoit la norme [ISO 16844-3], chiffre 
les informations à l'aide de la clé de couplag e et envoie le résultat au capt eur de mouvement. Le 
capt eur de mouvement déch iffre les informations de couplage.  
8. Le capt eur de mouvement chiffre les informations relatives au couplage reçues à l'aide de la KS 
reçue et les renv oie à la VU. La VU vérifie que les informations de couplage sont identiques à 
celles qu'elle a adressées au capt eur de mouvement à l'étape précédente . Dans l'affir mative, cela 
prouve que le capt eur de mouvement utilise la même KS que la VU. Par conséquent, à l'étape 5, 
il adresse sa clé de couplage cryptée avec la bonne génération de KM. Le capt eur de mouvement 
est ainsi authentifié. 
Note: les étapes 2 et 5 divergent de la procédure normalisée [ISO 16844-3]; les autres étapes 
restent standard. 26.5.2016 L 139/396 Jour nal officiel de l'Union européenne FR     
Exemple: imaginons qu'un couplage ait lieu durant la première année de validité du certificat ERCA 
(3); cf. Figure 2 de la section 9.2.1.2. En outre, 
—  Imaginons que le capt eur de mouvement ait été émis pendant la dernière année de validité du 
certificat ERCA(1). Il contient alors les clés et les données suivantes: 
—  Ns[1]: son numéro de série crypté avec KID de génération 1, 
—  Ns[2]: son numéro de série crypté avec KID de génération 2, 
—  Ns[3]: son numéro de série crypté avec KID de génération 3, 
—  KP[1]: sa clé de couplage (1) de génération 1, cryptée avec KM de génération 1, 
—  KP[2]: sa clé de couplage de génération 2, cryptée avec KM de génération 2, 
—  KP[3]: sa clé de couplage de génération 3, cryptée avec KM de génération 3, 
—  Imaginons que la carte d'atelier ait été émise pendant la première année de validité du certificat 
ERCA (3). Elle contient donc les générations 2 et 3 de la clé KM-W C. 
—  Imaginons que la VU est de génération 2 et contient KM-V U de génération 2. 
Dans ce cas, voici le déroulement des étapes 2 à 5: 
—  Étape 2: la VU lit la KM-W C de génération 2 et de génération 3 depuis la carte d'ateli er et inspect e 
leur numéro de version. 
—  Étape 3: la VU combine la KM-W C de génération 2 avec sa KM-V U afin de calculer KM et KID. 
—  Étape 4: la VU chiffre le numéro de série reçu du capt eur de mouvement avec KID. 
—  Étape 5: le capt eur de mouvement compare les données reçues avec Ns[1] sans trouver de 
correspondance. Il compare ensuit e les données avec Ns[2] et identif ie une correspondance. Il 
conclut que la VU est de génération 2 et renv oie donc la KP[2]. 
12.3.  couplage et communication de la VU et du capteur de mouv ement en utilisant AES 
CSM_218  Comme le précise le Tableau 3 de la section 9.2.1, tout es les clés impliquées dans le couplage d'une 
VU et d'un capt eur de mouvement de deuxième génération et dans leur communication ultérieure 
sont des clés AES, plutôt que des clés TDES de double longueur , comme le prévoit la norme [ISO 
16844-3]. La longueur de ces clés AES peuvent être de 128, 192 ou 256 bits. La taille des blocs 
AES étant de 16 octets, la longueur d'un messag e crypté doit être un multiple de 16 octets, 
comparé aux 8 octets des clés TDES. Par ailleurs, certains de ces messag es servent au transpor t des 
clés AES, dont la longueur peut être de 128, 192 ou 256 bits. Par conséquent, le nombre d'oct ets 
de données par instr uction figur ant dans le tableau 5 de la norme [ISO 16844-3] peuvent évoluer 
vers celui figurant au Tableau 6. 
Tableau 6 
Nombre d'octets de données cryptées et en clair par instr uction comme le prév oit la nor me [ISO 16844-3] 
Instr uc­
tion Demande/ 
Réponse Descr iption des 
données nbre d'octets de 
données en clair 
selon  
[ISO 16844-3] nbre d'octets de 
données en clair 
utilisant des clés 
AES nbre d'octets de données cryptées 
utilisant des clés AES d'une 
longueur de 
128 192 256 
10 demande Données d'authenti ­
fication + numéro 
de fichier 8 8 16 16 16 26.5.2016 L 139/397 Jour nal officiel de l'Union européenne FR     
(1)Note: les clés de couplage de génération 1, 2 et 3 peuvent être identiques ou peuvent toutes être de longueur différent es, comme le prév oit 
le CSM_117. 
Instr uc­
tion Demande/ 
Réponse Descr iption des 
données nbre d'octets de 
données en clair 
selon  
[ISO 16844-3] nbre d'octets de 
données en clair 
utilisant des clés 
AES nbre d'octets de données cryptées 
utilisant des clés AES d'une 
longueur de 
128 192 256 
11 réponse Données d'authenti ­
fication + conte nu 
de fichier 16 bits ou 
32 bits selon le 
fichier 16 bits ou 
32 bits selon le 
fichier 16 / 32 16 / 32 16 / 32 
41 demande numéro de série 
MoS 8 8 16 16 16 
41 réponse Clé de couplage 16 16 / 24 / 32 16 32 32 
42 demande Clé de session 16 16 / 24 / 32 16 32 32 
43 demande Informations de cou­
plag e 24 24 32 32 32 
50 réponse Informations de cou­
plag e 24 24 32 32 32 
70 demande Données d'authenti ­
fication 8 8 16 16 16 
80 réponse Valeur du comp teur 
MoS + données d'au ­
then. 8 8 16 16 16  
CSM_219  Les informations relatives au couplage envoyées dans les instr uctions 43 (demande de la VU) et 50 
(réponse du MoS) sont assemblées comme le prévoit la section 7.6.10 de la norme [ISO 16844-3], 
hormis l'utilisation de l'algor ithme AES au lieu de l'algor ithme TDES dans la procédure de crypta ge 
des données de couplag e. Cela entraine donc deux cryptages AES et l'adop tion du rem plissage 
prévu au CSM_220 pour correspondre à la taille des blocs AES. La clé K'p servant à cet cryptage est 
générée comme suit: 
—  Dans le cas où la clé de couplage KP est de 16 octets: K'p = KP XOR (Ns||Ns) 
—  Dans le cas où la clé de couplage KP est de 24 octets: K'p = KP XOR (Ns||Ns||Ns) 
—  Dans le cas où la clé de couplage KP est de 32 octets: K'p = KP XOR (Ns||Ns||Ns||Ns) 
où Ns correspond au numéro de série sur 8 octets du capt eur de mouvement. 
CSM_220  Si la longueur des données en clair (utilisant les clés AES) n'est pas un multiple de 16 octets, la 
méthode de rem plissage no 2 définie par la norme [ISO 9797-1] est utilisée. 
Note: la norme [ISO 16844-3] prévoit un nombre d'oct ets de données en clair multiples de 8 de 
sorte que le rem plissage n'est pas nécessaire lorsque des clés TDES sont utilisées. Le présent 
appendice ne modifi e pas la définition des données et des messag es prévue par la norme [ISO 
16844-3]. Il reste donc nécessaire de procéder au rem plissage. 
CSM_221  Concer nant l'instr uction 11 et lorsque plusieurs blocs de données doivent être cryptés, il convient 
d'utiliser le mode d'exploitation par chaînage de cryptage par blocs comme le prévoit la norme 
[ISO 10116], avec un paramètre d'entrelacement m = 1. L'IV à utiliser est: 
—  Concer nant l'instr uction 11: le bloc d'authentifi cation sur 8 octets spécifié à la section 7.6.3.3. 
de la norme (ISO 16844-3], compl été selon la méthode de rem plissage no 2 définie par la 
norme [ISO 9797-2]; cf. sections 7.6.5. et 7.6.6. de la norme [ISO 16844-3]. 26.5.2016 L 139/398 Jour nal officiel de l'Union européenne FR     
—  Concer nant tout es les autres instr uctions dont plus de 16 octets sont transférés, comme le 
spécifie le Tableau 6: ‘00’ {16}, c'est-à-dire 16 octets de valeur binaire égale à 0. 
Remarque: comme indiqué aux sections 7.6.5 et 7.6.6 de la norme [ISO 16844-3], lorsque le MoS 
chiffre des fichiers de données pour inser tion dans l'instr uction 11, le bloc d'authentification est à 
la fois: 
—  utilisé comme vecteur d'initialisation pour le cryptage en mode CBC des fichiers de données; et 
—  crypté et inclus comme premier bloc dans les données envoyées à la VU. 
12.4.  couplage de la VU et du capteur de mouv ement pour des équipements de générations différentes 
CSM_222  Comme l'explique la section 9.2.1, un capt eur de mouvement de deuxième génération contient le 
crypta ge TDES des données de couplage (comme le définit la partie A du présent appendice), qui 
permet de coupler le capt eur de mouvement avec une VU de première génération. Dans ce cas, une 
VU de première génération et un capt eur de mouvement de deuxième génération sont couplés 
comme le prévoi ent la partie A du présent appendice et la norme [ISO 16844-3]. Concer nant la 
procédure de couplage, une carte d'ateli er de première ou de deuxième génération peut être utilisée 
indifféremm ent. 
Remarques: 
—  Il n'est pas possible de coupler une VU de deuxième génération avec un capt eur de mouvement 
de première génération. 
—  Il n'est pas possible d'utiliser une carte d'atelier de première génération pour coupler une VU de 
deuxième génération avec capt eur de mouvement. 
13.  SÉCURITÉ DES COMMUNIC ATIONS DIST ANTES UTILISAN T DSR C 
13.1.  Généralités 
Comme le prévoi t l'appendice 14, une VU génère régulièrement des données de surveillance du tach ygraphe à 
distance (RTM) qu'elle envoie au dispositif (interne ou externe) de communication à distance (RCF). Le 
dispositif de communication à distance est responsable de l'env oi de ces données vers l'inter rogateur distant 
via l'interface DSR C décr ite à l'appendice 14. L'appendice 1 spécifi e que les données RTM résult ent de la 
concaté nation de: 
Données utiles cryptées du tachyg raphe le cryptage des données utiles en clair du tach ygraphe 
Données de sécur ité DSR Cdécr ites ci-dessous 
Les appendices 1 et 14 spécifient la structure des données utiles en clair du tach ygraphe. La présent e section 
décr it la structure des données de sécur ité DSR C; les spécifi cations formelles figurent dans l'appendice 1. 
CSM_223  Les données en clair 
 communiquées par une VU à un dispositif de 
communication à distance (si le RCF est externe à la VU) ou par une VU à l'inte rrogat eur distant au 
moyen de l'interface DSR C (si le RCF est interne à la VU) sont prot égées en mode chiffrer -puis- 
authentifi er. Cela signif ie que les données utiles du tach ygraphe sont d'abord cryptées pour prot éger 
la conf identialit é du message, puis qu'un MAC est calculé pour garantir l'authenticité et l'intégrité 
des données. 
CSM_224  Les données relatives à la sécur ité DSR C correspondent à une concat énation des éléments de 
données suivants dans l'ordre indiqué; cf. Figure 12 
Date et heure actuelles  la date et l'heure actuels de la VU (type de 
données 
 ). 
Compteur  un comp teur sur trois octets, cf.CSM_225. 26.5.2016 L 139/399 Jour nal officiel de l'Union européenne FR     
Numéro de série de la VU  le numéro de série de la VU (type de données 
). 
Numéro de version de la clé maîtresse DSR C  le numéro de version sur un octet de la clé 
maîtresse DSR C de laquelle découlent les clés 
DSR C propres à la VU; cf. section 9.2.2. 
MA C  le MAC calculé en fonction de tous les octets 
précédents dans les données RTM. 
CSM_225  Le comp teur sur trois octets dans les données relatives à la sécur ité DSR C respecte la structure 
MSB-f irst. La première fois qu'une VU calcule un jeu de données RTM après son entrée en 
production, elle définit la valeur du comp teur à zéro. La VU incrémente le comp teur d'une unité 
avant chaque nouveau calcul du jeu de données RTM suivant. 
13.2.  Cryptage des données utiles du tachyg raphe et génération du MA C 
CSM_226  En partant d'un élément de données en clair de type 
 tel que décr it à 
l'appendice 14, une VU chiffre ces données comme illustré à la Figure 12: la clé DSR C de la VU 
pour codage K_VUDSR C_ENC (cf. section 9.2.2) avec AES, en mode d'exploitation par chaînag e de 
crypta ge par blocs (CBC), tel que défini par la norme [ISO 10116], selon un paramètre d'entrela ­
cement m = 1. Le vecteur d'initialisation est égal à IV = date et heure actuelles || ‘00 00 00 00 00 00 
00 00 00’ || où la date et l'heure actuelles ainsi que le compteur sont spécifi és en CSM_224. Les données 
à chiffrer sont complétées par un contenu de remp lissage à l'aide de la méthode no 2 défin ie par la norme 
[ISO 9797-1]. 
CSM_227  Une VU calcule le MAC dans les données de sécur ité DSR C comme illustré sur la Figure 12: le 
MAC est calculé sur tous les octets précédents des données RTM, jusqu'au numéro de version de la 
clé maîtresse DSR C incluse, y compris les balises et les longueurs des objets de données. La VU 
utilise sa clé DSR C d'authentifi cation K_VUDSR C_MA C (cf. section 9.2.2) avec l'algor ithme AES en 
mode CMA C comme spécifi é au [SP 800-38B]. La longueur de MAC est liée à la longueur des clés 
de DSR C propres à la VU, conf ormément au CSM_50. 
Figure 12 
cryptage des données utiles du tachy graphe et génération du MA C 
26.5.2016 L 139/400 Jour nal officiel de l'Union européenne FR     
13.3.  Vér ification et décr yptage de la charge du tachy graphe 
CSM_228  Lorsqu'un interr ogateur reçoit les données RTM d'une VU, il envoie la totali té des données RTM à 
une carte de contrôle dans le cham p de données d'une commande PROCESS DSR C MESS AGE, 
conf ormément à l'appendice 2. Puis:  
1. la carte de contrôle inspect e le numéro de version de la clé maîtresse DSR C dans les données 
relatives à la sécur ité DSR C. Si la carte de contrôle ne connaît pas la clé maîtresse DSR C 
indiquée, elle envoie une erreur conf ormément à l'appendice 2 et abandonne la procédure.  
2. la carte de contrôle utilise la clé maîtresse DSR C indiquée en combinaison avec le numéro de 
série de la VU dans les données relatives à la sécur ité DSR C pour calculer les clés DSR C propres 
à la VU K_VUDSR C_ENC et K_VUDSR C_MA C, comme le précise le CSM_124.  
3. la carte de contrôle utilise K_VUDSR C_MA C pour vérifier le MAC dans les données relatives à la 
sécur ité DSR C, conf ormément au CSM_227. Si le MAC est erroné, la carte de contrôle envoie 
une erreur conf ormément à l'appendice 2 et abandonne la procédure.  
4. la carte de contrôle utilise K_VUDSR C_ENC pour décr ypter les données utiles cryptées du 
tach ygraphe, comme le précise CSM_226. La carte de contrôle suppr ime le rem plissage et 
envoie les données utiles du tach ygraphe décr yptées à l'inte rrogat eur distant. 
CSM_229  Pour éviter les attaques par relecture, l'inte rrogat eur distant vérifie la récence des données RTM en 
contrôlant que le current date time dans les données relatives à la sécur ité DSR C ne diffère pas trop 
de ses propres date et heure actuelles. 
Remarques: 
—  Cela impose à l'inter rogateur distant de disposer d'une source horaire exacte et fiable. 
—  L'appendice 14 exigea nt qu'une VU calcule un nouveau jeu de données RTM tout es les 60 
secondes, d'une part et l'horloge de la VU intégrant une marge d'erreur autor isée d'une minute 
par rappor t à l'heure exacte, d'autre part, la limite basse de récence des données RTM est fixée à 
deux minute s. La récence exigé e varie également selon le degré de précision de l'horloge de 
l'interroga teur distant. 
CSM_230  Lorsqu'un atelier vérifie le fonctionnement correct de la fonctionnalit é DSR C d'une VU, il envoie la 
totalit é des données RTM reçues de la VU à une carte d'atelier dans la zone de données d'une 
commande PROCESS DSR C MESSA GE, conf ormément à l'appendice 2. La carte d'ate lier effectue 
tous les contrôles et tout es les actions spécifiés au CSM_228. 
14.  SIGNA TURE DES TÉLÉCHAR GEMENT DE DONNÉES ET CONTRÔLE DES SIGNA TURES 
14.1.  Généralités 
CSM_231  L'équipement spécialisé intelli gent (IDE) enregistre les données reçues d'une VU ou d'une carte 
donnée pendant une session de téléc hargement au sein d'un fichier de données physiques. Les 
données peuvent être mémor isées sur un suppor t de stoc kage externe. Ce fichier contient les 
signatures numér iques en fonction des blocs de données, comme le spécifi e l'appendice 7. Ce 
fichier contient également les certificats suivants (cf. section 9.1): 
—  en cas de téléc hargement depuis une VU: 
—  le certificat VU_Sign; 
—  le certificat MSCA_ VU-EGF compre nant la clé publique à utiliser pour vérifier le certificat 
VU_Sign. 26.5.2016 L 139/401 Jour nal officiel de l'Union européenne FR     
—  en cas de téléc hargement depuis une carte: 
—  le certificat Card_Sign; 
—  le certificat MSCA_Card comprenan t la clé publique à utiliser pour vérifier le certificat 
Card_Sign. 
CSM_232  L'IDE dispose également des éléments suivants: 
—  en cas d'utilisation d'une carte de contrôle pour vérifier la signature, comme illustré sur la 
Figure 13: le certificat de lien reliant le plus récent certificat EUR à celui dont la validité le 
précède immédiatem ent, le cas échéant. 
—  S'il vérifie la signature: tous les certificats racines européens valides. 
Note: la méthode qu'utilise l'IDE pour extraire ces certificats ne figure pas au présent appendice. 
14.2.  Génération de signatures 
CSM_233  L'algor ithme de signature pour créer des signatures numér iques en fonction des données 
téléc hargée s doit être de type ECDSA conf ormément aux règles [DSS], en ayant recours à 
l'algor ithme de hach age associé à la taille de clé de la VU ou de la carte, conf ormément au 
CSM_50. La structure de la signature est en clair , conf ormément au [TR-03111]. 
14.3.  Vér ification de signatures 
CSM_234  Un IDE peut procéder à la vérification d'une signature par rappor t aux données téléc hargée s lui- 
même ou utiliser une carte de contrôle à cette fin. S'il utilise une carte de contrôle, la vérification 
de la signature respecte l'illustration de la Figure 13. S'il procède lui-même à la vérification de la 
signature, l'IDE vérifie l'authenticité et la validité de tous les certificat s dans la chaîne de certificats 
conte nue dans le fichier de données ainsi que la signature par rappor t aux données conf ormément 
à la procédure relative aux signatures définie par les [DSS]. 
Notes relatives à la Figure 13: 
—  L'équipement qui a participé à la signature des données à analyser est désigné par l'abréviation 
EQT . 
—  Les certificats et les clés publiques EQT mentionnées sur la Figure sont destinés à la signature, 
c'est-à-dire VU_Sign ou Card_Sign. 
—  Les certificats et les clés publiques EQT .CA mentionnés sur la Figure sont ceux destinés à la 
signature des certificats VU ou Card, selon le cas. 
—  Le certificat EQT .CA.EUR mentionné sur cette Figure est le certificat racine européen indiqué 
dans le CAR du certificat EQT .CA 
—  Le certificat EQT .Link mentionné sur cette Figure est le certificat de lien de l'EQT , le cas 
éché ant. Comme le précise la section 9.1.2, il s'agit d'un certificat de lien pour une nouvelle 
paire de clés racine européenne créé par l'ERCA et signé par la précédente clé privée 
européenne. 
—  Le certificat EQT .Link .EUR désigne le certificat racine européen indiqué dans le CAR du 
certificat EQT .Link . 
CSM_235  Pour calculer le M de hach age envoyé à la carte de contrôle dans la commande PSO:hash, l'IDE 
utilise l'algor ithme de hachag e associé à la taille de la clé de la VU ou de la carte depuis laquelle les 
données sont télécharg ées, conf ormément au CSM_50. 
CSM_236  Pour vérifier la signature EQT , la carte de contrôle respecte la procédure relative aux signatures 
définie s par les règles [DSS]. 
Remarque: le présent document ne spécifi e aucune action à entreprendre s'il est impossible de 
vérifier une signature associée à un fichier de données téléc hargé ou si cette vérification échoue. 26.5.2016 L 139/402 Jour nal officiel de l'Union européenne FR     
Figure 13 
Protocole de vérification de la signature associée à un fichier de données téléchargé 
26.5.2016 L 139/403 Jour nal officiel de l'Union européenne FR     
Appendice 12 
POSITIONNEMENT BASÉ SUR UN SYSTÈME MONDIAL DE NAVIGA TION PAR SATELLITE (GNSS) 
TABLE DES MATIÈRES 
1. INTR ODUCTION ................................................................................................................................ 405 
1.1. Champ d'application ............................................................................................................... 405 
1.2. Abréviations et notations ......................................................................................................... 405 
2. SPÉCIFIC ATIONS DU RÉCEPTEUR GNSS .................................................................................................. 406 
3. PHRASES NMEA ................................................................................................................................ 406 
4. UNITÉ EMBARQUÉE SUR LE VÉHICULE AVEC UN DISPOSITIF GNSS EXTERNE ................................................. 408 
4.1. Confi guration ........................................................................................................................ 408 
4.1.1 Principaux compo sants et principales interfaces ............................................................................ 408 
4.1.2 État du dispositif GNSS exte rne à la fin de la production ................................................................. 408 
4.2. Communication entre le dispositif GNSS extern e et l'unit é embarquée sur le véhicule ............................ 409 
4.2.1 Protocole de communication .................................................................................................... 409 
4.2.2 Transf ert sécur isé de données GNSS ........................................................................................... 411 
4.2.3 Structure de la commande Read Record ...................................................................................... 412 
4.3. Appar iement, authentific ation mutuelle et concordance de clés de session du dispositif GNSS externe avec 
la VU .................................................................................................................................. 413 
4.4. Traitem ent des erreurs ............................................................................................................. 413 
4.4.1 Erreur de communication avec le dispositif GNSS externe ............................................................... 413 
4.4.2 Atteinte à l'intégrité physique du dispositif GNSS externe................................................................ 413 
4.4.3 Absence d'inf ormations de positionnement en provenance du récep teur GNSS ..................................... 413 
4.4.4 Expiration du certificat du dispositif GNSS exte rne........................................................................ 414 
5. UNITÉ EMBARQUÉE SUR LE VÉHICULE SANS DISPOSITIF GNSS EXTERNE ...................................................... 414 
5.1. Confi guration ........................................................................................................................ 414 
5.2. Traitem ent des erreurs ............................................................................................................. 414 
5.2.1 Absence d'inf ormations de positionnement en provenance du récep teur GNSS ..................................... 414 
6. CONFLIT TEMPOREL GNSS ................................................................................................................... 414 
7. CONFLIT CON CERNANT LE MOUVEMENT DU VÉHICULE ........................................................................... 415  26.5.2016 L 139/404 Jour nal officiel de l'Union européenne FR     
1.  INTR ODUCTION 
Le présent appendice présent e les exigenc es techniques associées aux données GNSS qu'utilise l'unité embarquée 
sur le véhicule, y compris les prot ocoles à appliquer pour garant ir la sécur ité et l'exactitude du transfer t de 
données des informations relatives au positionnement. 
Les principaux articles du règlement (UE) no 165/2014 dont découlent les présentes exigenc es sont les suivants: 
«Article 8 Enregistrement de la position du véhicule à certains points de la période de travail jour nalière», 
«Article 10 Interface avec les systèmes de transpor t intelli gents» et «Article 11 Dispositions détaillées relatives au 
tach ygraphe intelli gent». 
1.1.  Champ d'application 
GNS_1  L'unité embarquée sur le véhicule recueille les données de localisation d'au moins un GNSS afin de 
prendre en charge l'application de l'article 8. 
L'unité embarquée sur le véhicule peut disposer ou non d'un dispositif GNSS externe, comme illustré à la figur e 1: 
Figure 1 
Différentes conf igurations du récepteur GNSS 
1.2.  Abréviations et notations 
Dans le présent appendice, sont utilisées les abréviations suivantes: 
DOP  Affaiblissement de la précision 
EGF  Fichier élémentaire de dispositif GNSS 26.5.2016 L 139/405 Jour nal officiel de l'Union européenne FR     
EGNOS  Système européen de navigat ion par recouvrement géostationnaire 
GNSS  Global navi gation satellite system (système mondial de radionavig ation par satellit e) 
GSA  DOP du GPS et satellites actifs 
HDOP  Affaiblissement de la précision horizontale 
ICD  Document de contrôle des interfaces 
NMEA  National Mar ine Electronics Association 
PDOP  Affaiblissement de la précision de position 
RMC  Minimum spécifi que recommandé 
SIS  Signal dans l'espace 
VDOP  Affaiblissement de la précision verticale 
VU  Unit é embarquée sur le véhicule 
2.  SPÉCIFIC ATIONS DU RÉCEPTEUR GNSS 
Indépendamment de la conf iguration du tach ygraphe intellig ent, avec ou sans dispositif GNSS exte rne, la 
délivrance d'inf ormations de positionnement précises et fiables constitue un critère fondamental du fonction ­
nement efficace du tach ygraphe intellig ent. Il convient donc d'exiger sa compatibilit é avec les services fournis par 
le programme Galileo et le programme EGNOS (European Geostationar y Navig ation Overla y Service) tels qu'ils 
sont définis par le règlement (UE) no 1285/2013 du Parlement Européen et du Conseil (1). Le système établi en 
vertu du programme Galileo est un système mondial de radiona vigation par satellite indépendant et celui établi en 
vertu du programme EGNOS est un système régional de radiona vigat ion par satellite destiné à améliorer la qualité 
du signal du système de positionnement mondial (GPS). 
GNS_2  Les constr ucteur s veillent à ce que les récep teurs GNSS des tach ygraphes intellig ents soient compati bles 
avec les services de positionnement fournis par les systèmes Galileo et EGNOS. Les fabricants ont 
également la possibilit é de choisir , en plus, d'assurer la compat ibilité avec d'autres systèmes de navigation 
par satellit e. 
GNS_3  Le récept eur GNSS prend en charge l'authentif ication sur le service ouver t Galileo lorsque ledit service est 
fourni par le système Galileo et pris en charge par les fabr icants de récept eurs GNSS. 
3.  PHRASES NMEA 
La présente section décr it les phrases NMEA utilisées pendant le fonctionnement du tach ygraphe intellig ent. Cette 
section est applicable à la conf iguration du tach ygraphe intelli gent avec et sans dispositif GNSS exte rne. 
GNS_4  Les données de localisation reposent sur les données GNSS du minimum spécif ique recommandé (RMC) 
de la phrase NMEA, qui contiennent les informations de positionnement (latitude et longitude), l'heure au 
format UTC (hhmmss.ss) et la vitesse sur le fond en nœuds plus d'autres valeurs compl émentaires. 
La structure de la phrase RMC est la suivante (d'après la norme NMEA V4.1): 26.5.2016 L 139/406 Jour nal officiel de l'Union européenne FR     
(1)Règlement (UE) no 1285/2013 du Parlement européen et du Conseil du 11 décembre 2013 relatif à la mise en place et à l'exploitation des 
systèmes européens de radionav igation par satellite et abrogean t le règlement (CE) du Conseil no 876/2002 et le règlement (CE) 
no 683/2008 du Parlement européen et du Conseil (OJ L 347, 20.12.2013, p. 1). 
Figure 2 
Structure de la phrase RMC 
L'état indique la disponibilité du signal GNSS. Tant que la valeur de l'état n'est pas fixée à A, les données reçues 
(c'est-à-dire l'heure ou la latitude ou la longitude) ne peuvent pas servir à enregistrer la position du véhicule dans 
la VU. 
La résolution de la position repose sur la structure de la phrase RMC décr ite ci-dessus. La première partie des 
zones 3) et 5) correspondent aux degrés. Le reste correspond aux minut es avec trois décimales. La résolution est 
donc de 1/1 000 minute ou 1/60 000 degré (parce qu'une minute correspond à 1/60 degré). 
GNS_5  L'unité embarquée sur le véhicule mémor ise dans la base de données de la VU les informations relatives 
au positionnement en term es de latitude et de longitude selon une résolution d'1/10 minute ou 
1/600 degré, comme le décr it l'appendice 1 pour les coordonnées géographiques type. 
La VU peut utiliser la commande GPS DOP et satellites actifs (GSA) pour déterminer et enregistrer la 
disponibilité et l'exactitude du signal. En particulier , HDOP sert à fournir une indication sur le degré 
d'exactitude des données de localisation enregistrées (cf. 4.2.2). La VU enregistre la valeur du coefficient 
d'affaibliss ement de la précision de positionnement horizontal (HDOP) calculée comme étant la minimale 
des valeurs HDOP recueillies sur les systèmes GNSS disponibles. 
L'identif icateur du système GNSS indique GPS, Glonass, Galileo, Beidou ou Sate llite-Based Augmentation 
System (SBAS). 
Figure 3 
Structure de la phrase GSA 
26.5.2016 L 139/407 Jour nal officiel de l'Union européenne FR     
Ici, le Mode (2) indique que certains points de repère (fix) sont indisponibles (Mode = 1) ou qu'ils sont disponibles 
en 2D (Mode = 2) ou en 3D (Mode = 3). 
GNS_6  La phrase GSA est mémor isée avec le numéro d'enregistrement ‘06’. 
GNS_7  La taille maximale des phrases NMEA (p. ex. RMC, GSA ou d'autres), qui peut servir à étalonner la 
commande Read Record, est de 85 octets (cf. tableau 1). 
4.  UNITÉ EMBARQUÉE SUR LE VÉHICULE AVEC UN DISPOSITIF GNSS EXTERNE 
4.1.  Conf iguration 
4.1.1  Principaux composants et principales interf aces 
Dans cette conf iguration, le récep teur GNSS fait partie du dispositif GNSS extern e. 
GNS_8  Le dispositif GNSS externe doit être alimenté par une interfa ce de véhicule spécifi que. 
GNS_9  Le dispositif GNSS externe se compo se des éléments suivants (cf. figure 4): 
a)  Un récept eur GNSS commercial pour fournir les données de positionnement à l'aide de l'interface de 
données GNSS. Par exem ple, l'interface de données GNSS peut être la norme NMEA V4.10 selon 
laquelle le récept eur GNSS tient le rôle de l'émetteur et transmet les phrases NMEA à l'émette ur- 
récept eur sécur isé GNSS sur une fréquence d'1 Hz pour le jeu prédéfini de phrases NMEA, lequel 
doit comprendre au moins les phrases RMC et GSA. Le choix de la mise en œuvre de l'interface de 
données GNSS revient aux fabricants du dispositif GNSS extern e. 
b)  Une unité d'émett eur-récep teur (émett eur-récept eur sécur isé GNSS) compati ble avec la norme ISO/ 
IEC 7816-4:2013 (cf. 4.2.1) pour communiquer avec l'unité embarquée sur le véhicule et prendre en 
charg e l'interface de données GNSS s'adressant au récep teur GNSS. L'unité est dotée d'une mémoire 
qui enregistre les données relatives à l'identif ication du récep teur GNSS et du dispositif GNSS 
extern e. 
c)  Un système clos doté d'une fonction de détection des fraudes qui intègre le récep teur GNSS et 
l'émetteur -récep teur sécur isé GNSS. La fonction de détection des fraudes met en pratique les mesures 
de protection de la sécur ité comme le définit le profil de prote ction du tach ygraphe intellig ent. 
d)  Une antenne GNSS installée sur le véhicule et connecté e au récep teur GNSS à l'aide du système clos. 
GNS_10  Le dispositif GNSS externe dispose au minimum des interfaces externes suivantes : 
a)  l'interface avec l'ante nne GNSS installée sur le véhicule, dans le cas où l'on utilise une antenne 
extern e; 
b)  l'interface avec l'unité embarquée sur le véhicule. 
GNS_11  Dans la VU, l'émette ur-récep teur sécur isé de la VU constitue l'autre extrémité de la communication 
sécur isée avec l'émetteur -récep teur sécur isé GNSS. Il respecte la norme ISO/IEC 7816-4:2013 relative à 
la connexion au dispositif GNSS externe. 
GNS_12  Pour la couche de communication avec le dispositif GNSS exte rne, la VU respecte la norme ISO/IEC 
7816-12:2005 ou tout e autre norme compati ble avec la norme ISO/IEC 7816-4:2013. (cf. 4.2.1). 
4.1.2  État du dispositif GNSS exter ne à la fin de la prod uction 
GNS_13  Le dispositif GNSS externe mémor ise les valeurs suivantes dans la mémoire non volatile de l'émetteur - 
récept eur sécur isé GNSS lorsqu'il quitt e l'usine: 
—  la paire de clé EGF_MA et son certificat, 
—  le certificat MSCA _VU-EGF compr enant la clé publique MSCA _VU-EGF .PK à utiliser pour vérifier le 
certificat EGF_MA, 26.5.2016 L 139/408 Jour nal officiel de l'Union européenne FR     
—  le certificat EUR comprenant la clé publique EUR.PK à utiliser pour vérifier le certificat MSCA_VU- 
EGF , 
—  le certificat EUR dont la durée de validité précède directement celle du certificat EUR à utiliser pour 
vérifier le certificat MSCA_ VU-EGF , le cas échéant, 
—  le certificat de lien reliant ces deux certificats EUR, le cas échéant, 
—  le numéro de série étendu du dispositif GNSS externe, 
—  l'identifi cateur du système d'exploitation du dispositif GNSS, 
—  le numéro d'homologation du dispositif GNSS externe; 
—  l'identifi cateur du composant de sécur ité du dispositif GNSS extern e. 
4.2.  Communication entre le dispositif GNSS exter ne et l'unité embarquée sur le véhicule 
4.2.1  Protocole de communication 
GNS_14  Le protocole de communication entre le dispositif GNSS exte rne et l'unité embarquée sur le véhicule 
remplit trois fonctions:  
1. la collect e et la distr ibution des données GNSS (p. ex. la position, l'heure et la vitesse),  
2. la collect e des données de configuration du dispositif GNSS extern e,  
3. le protocole de gestion à l'appui de l'appar iement, de l'authentification mutuelle et de la concordance 
de clés de session entre le dispositif GNSS extern e et la VU. 
GNS_15  Le protocole de communication repose sur la norme ISO/IEC 7816-4:2013 où l'émetteur -récept eur 
sécur isé de la VU tient le rôle du maître et l'émetteur -récep teur sécur isé du GNSS, le rôle de l'esclave. La 
connexion physique entre le dispositif GNSS exte rne et la VU repose sur la norme ISO/IEC 7816- 
12:2005 ou tout e autre norme compati ble avec la norme ISO/IEC 7816-4:2013 
GNS_16  Le protocole de communication ne doit pas prendre en charge les zones de longueur étendue. 
GNS_17  Le protocole de communication de la norme ISO 7816 (*-4:2013 et *-12:2005) entre le dispositif GNSS 
extern e et la VU est fixé à T = 1. 
GNS_18  Concer nant les fonctions 1) de collecte et de diffusion des données GNSS, 2) de collect e des données de 
conf iguration du dispositif GNSS externe et 3) du protocole de gestion, l'émetteur -récep teur sécur isé 
GNSS simule une carte intellig ente dont l'arc hitecture du système de fichiers compr end un fichier maître 
(MF), un fichier spécialisé (DF) doté de l'identificateur d'application spécifié en Appendice 1, chapitre 6.2 
(‘FF 44 54 45 47 4D’), trois fichiers élémentaires contenant des certificats et un fichier élémentaire 
unique (EF.EGF) dont l'identifi cate ur de fichier correspond à ‘2F2F’ comme le prévoit le tableau 1. 
GNS_19 L'émetteur -récept eur sécur isé GNSS mémor ise les données provenant du récep teur GNSS et la conf igu­
ration dans le fichier EF.EGF . Il s'agit d'un fichier d'enregistrement d'une longueur variable et linéaire 
dont l'identifi cateur correspond à ‘2F2F’ au format hexadécimal. 
GNS_20  L'émetteur -récept eur sécur isé GNSS doit utiliser une mémoire pour enregistrer les données et pouvoi r 
effectuer au moins 20 millions de cycles d'écr iture et de lecture. Hor mis cet aspect, la conception 
intern e et la mise en œuvre de l'émette ur-récep teur sécur isé GNSS incombent aux fabricants. 
Le tableau 1 fournit la modélisation des numéros d'enregistrement et des données. Remarque: il existe 
quatre phrases GSA correspondant aux quatre systèmes de satellite et au SBAS (Satellite-Based 
Augmentation System ). 
GNS_21  Le tableau 1 présent e la structure de fichier. Concer nant les règles d'accès (ALW, NEV , SM-MA C), cf. 
appendice 2, chapitre 3.5. 26.5.2016 L 139/409 Jour nal officiel de l'Union européenne FR     
Tableau 1 
Structure de fichier   
Conditions d'accès 
Fichier ID de fichier Lire Actualiser Codé 
MF 3F00    
EF.ICC 0002 ALW NEV 
(par la VU) Non 
DF GNSS Facili ty 0501 ALW NEV Non 
EF EGF_MA Certificate C100 ALW NEV Non 
EF CA_Cer tificate C108 ALW NEV Non 
EF Link_Cer tificate C109 ALW NEV Non 
EF.EGF 2F2F SM-MA C NEV 
(par la VU) Non  
Fichier /Élément d'inf ormation Numéro de 
l'enregistre ­
ment Taille (octets) Valeurs par 
défaut   
Min Max  
MF  552 1 031  
EF.ICC     
sensorGNSSSer ialNumber  8 8       
DF GNSS Faci lity  612 1 023  
EF EGF_MA Certificate  204 341  
EGFCer tificate  204 341 {00..00} 
EF CA_Cer tificate  204 341  
MemberStateCer tificate  204 341 {00..00} 
EF Link_Cer tificate  204 341  
LinkCer tificate  204 341 {00..00}      
EF.EGF     
RMC NMEA Sentenc e ‘01’ 85 85  
1st GSA NMEA Sentenc e ‘02’ 85 85  
2nd GSA NMEA Sentence ‘03’ 85 85  26.5.2016 L 139/410 Jour nal officiel de l'Union européenne FR     
Fichier /Élément d'inf ormation Numéro de 
l'enregistre ­
ment Taille (octets) Valeurs par 
défaut   
Min Max  
3rd GSA NMEA Sente nce ‘04’ 85 85  
4th GSA NMEA Sentenc e ‘05’ 85 85  
5th GSA NMEA Sentenc e ‘06’ 85 85  
Numéro de série étendu du dispositif GNSS 
extern e défini à l'appendice 1 comme Sen­
sorGNSSSer ialNumber . ‘07’ 8 8  
Identif icateur du système d'exploitation de 
l'émetteur -récep teur sécur isé GNSS défini à 
l'appendice 1 comme SensorOSIdentifier . ‘08’ 2 2  
Numéro d'homologation du dispositif 
GNSS externe défini à l'appendice 1 
comme SensorExt ernalGNSSA ppro valNum ­
ber. ‘09’ 16 16  
Identif icateur du compo sant de sécur ité du 
dispositif GNSS exte rne défini à l'appendice 
1 comme SensorExt ernalGNSSSCIdentifie r ‘10’ 8 8  
RFU — Reser ved for Future Use De ‘11’ à ‘FD’     
4.2.2  Transfert sécur isé de données GNSS 
GNS_22  Le transfe rt sécur isé des données de positionnement GNSS est autorisé uniquement dans les conditions 
suivantes:  
1. La procédure d'appar iement a abouti conf ormément aux dispositions de l'appendice 11. Mécanismes 
de sécur ité communs.  
2. L'authentifi cation mutuelle régulière et la concordance de clés de session entre la VU et le dispositif 
GNSS extern e également décr ites à l'appendice 11. Les mécanismes de sécur ité communs sont 
appliqués à la fréquence indiquée. 
GNS_23  Toutes les T secondes, où T est une valeur inférieure ou égale à 10, sauf pendant le déroulement de 
l'appar iement, de l'authentification mutuelle et de la concordance de clés de session, la VU demande au 
dispositif GNSS externe les informations de positionnement selon la séquence suivante:  
1. La VU demande les données de localisation et les données relatives à l'affaiblissement de la précision 
(pro venant de la phrase GSA NMEA) au dispositif GNSS extern e. L'émetteur -récept eur sécur isé de la 
VU utilise les commandes SELECT et READ RECORD(S) conf ormément à la norme ISO/IEC 7816- 
4:2013 en mode authentifi cation uniquement de la message rie sécur isée, tel que le prévoi t 
l'appendice 11, section 11.5, avec l'identif icateur de fichier ‘2F2F’ et le nombre de REC ORD 
égal à ‘01’ pour la phrase NMEA RMC et ‘02’,‘03’,‘04’ ,‘05’ ,‘06’ pour la phrase GSA NMEA.  
2. Les dernières données de localisation reçues sont mémor isées dans l'EF avec l'identificateur ‘2F2F’ et 
les enregistrements décr its au tableau 1 dans l'émett eur-récept eur sécur isé GNSS car ce dernier reçoit 
les données NMEA du récep teur GNSS, sur une fréquence d'au moins 1 Hz, par l'inte rface de 
données GNSS.  
3. L'émetteur -récept eur sécur isé GNSS envoie la réponse à l'émett eur-récept eur sécur isé de la VU à l'aide 
du message de réponse UDP A en mode authentifi cation uniquement de la messager ie sécur isée, 
comme le décr it l'appendice 11, section 11.5. 26.5.2016 L 139/411 Jour nal officiel de l'Union européenne FR     
4. L'émetteur -récept eur sécur isé de la VU contrôle l'authenticit é et l'intégrité de la réponse reçue. En cas 
de résultat positif, les données de localisation sont transfé rées au processeur de la VU par l'inte rface 
de données GNSS.  
5. Le processeur de la VU vérifie les données reçues en extra yant les informations (p. ex. la latitude, la 
longitude ou l'heure) de la phrase RMC NMEA. Cette dernière inclut les informations si le position ­
nement est valide. Si tel n'est pas le cas, les données de localisation ne sont pas encore mises à 
disposition et ne peuvent pas servir à enregistrer la position du véhicule. Si le positionnement est 
valide, le processeur de la VU extrait également les valeurs HDOP des phrases GSA NMEA et calcule 
la valeur moyenne d'après les systèmes de satellites disponibles (p. ex., lorsque les points de repère 
sont disponibles).  
6. Le processeur de la VU mémor ise les informations reçues et traité es comme la latitude, la longitude, 
l'heure et la vitesse dans la VU, selon la structure définie à l'appendice 1 Dictionnaire de données, 
comme coordonnées géographiques avec la valeur HDOP calculée selon le minimum des valeurs 
HDOP recueillies sur les systèmes GNSS disponibles. 
4.2.3  Structur e de la commande Read Record 
La présent e section décr it en détail la structure de la commande Read Record (lecture des enregistrements). La 
messager ie sécur isée (mode authentification uniquement) est ajoutée conf ormément aux dispositions de 
l'appendice 11 Mécanismes de sécur ité communs. 
GNS_24  La commande est compat ible avec le mode authentifi cation uniquement de la message rie sécur isée; 
cf. appendice 11. 
GNS_25  Message de commande 
Octet Longueur Valeur Descr iption 
CLA 1 ‘0Ch’ Message rie sécur isée demandée. 
INS 1 ‘B2h’ Lire l'enregistrement. 
P1 1 ‘XXh’ Nombre d'enregistrements (‘00’ indique l'enregistrement en 
cours). 
P2 1 ‘04h’ Lire l'enregistrement avec le nombre d'enregistrements indiqué 
en P1. 
Le 1 ‘XXh’ Longueur de données prévisible. Nombre d'oct ets à extraire.  
GNS_26  L'enregistrement référencé en P1 devient l'enregistrement en cours. 
Octet Longueur Valeur Descr iption 
#1-#X X ‘XX..XXh’ Données extraites 
SW 2 ‘XXXXh’ Mots d'état (ME1, ME2)  
—  Si la commande aboutit, l'émett eur-récept eur sécur isé GNSS renv oie ‘9000’. 
—  Si le fichier en cours n'est pas orienté enregistrement, l'émett eur-récept eur sécur isé GNSS renv oie 
‘6981’. 
—  Si la commande est utilisée avec P1 = ‘00’, mais sans aucun EF en cours, l'émetteur -récep teur 
sécur isé GNSS renv oie ‘6986’ (commande inter dite). 
—  Si l'enregistrement est introuvable, l'émetteur -récep teur sécur isé GNSS renv oie ‘6A 83’. 
—  Si le dispositif GNSS extern e détecte une fraude, il renv oie les mots d'état ‘66 90’. 26.5.2016 L 139/412 Jour nal officiel de l'Union européenne FR     
GNS_27  L'émetteur -récept eur sécur isé GNSS est compatib le avec les commandes suivantes de la deuxième 
génération de tach ygraphes, définies à l'appendice 2: 
Commande Référence 
Select Appendice 2 chapitre 3.5.1 
Read Binar y Appendice 2 chapitre 3.5.2 
Get Challenge Appendice 2 chapitre 3.5.4 
PSO: Verify Certificate Appendice 2 chapitre 3.5.7 
Extern al Authenticate Appendice 2 chapitre 3.5.9 
General Authenticat e Appendice 2 chapitre 3.5.10 
MSE:SET Appendice 2 chapitre 3.5.11  
4.3.  Appar iement, authentif ication mutuelle et concordance de clés de session du dispositif GNSS exter ne 
avec la VU 
L'appar iement, l'authentif ication mutuelle et la concordance de clés de session du dispositif GNSS exte rne avec la 
VU sont décr its à l'appendice 11. Mécanismes de sécur ité communs, chapitre 11. 
4.4.  Traitement des erreurs 
La présent e section décr it comment des conditions d'erreur poten tielles du dispositif GNSS exte rne sont traité es et 
enregistrées dans la VU. 
4.4.1  Erreur de communication avec le dispositif GNSS exter ne 
GNS_28  Si la VU ne parvient pas à gérer la communication avec le dispositif GNSS externe appar ié pendant plus 
de 20 minut es consécutives, la VU génère et enregistre dans la VU un évènement de type EventF aultT ype 
avec la valeur enum ‘53’H Exter nal GNSS communication fault assor ti d'un horodatag e indiquant l'heure 
actuelle. L'évènement n'est généré que si les deux conditions suivantes sont satisfait es: a) le tach ygraphe 
intellig ent n'est pas en mode étalonnage et b) le véhicule circule. Dans ce cont exte, une erreur de 
communication survient lorsque l'émette ur-récep teur sécur isé de la VU ne reçoit pas de message de 
réponse après un messag e de demande, au sens de la section 4.2. 
4.4.2  Atteinte à l'intég rité physiq ue du dispositif GNSS exter ne 
GNS_29  En cas d'att einte au dispositif GNSS exte rne, l'émetteur -récept eur sécur isé GNSS efface tout e sa mémoire, 
y compris le mat ériel cryptographique. Comme le prévoi ent GNS_25 et GNS_26, la VU détect e les 
infractions si la réponse possède l'état ‘6690’. La VU génère ensuite un évènement de type 
EventFaultT ype enum ‘55’H Tamper detection of GNSS. 
4.4.3  Absence d'infor mations de positionnement en provenance du récep teur GNSS 
GNS_30  Si l'émette ur-récep teur sécur isé GNSS ne reçoit aucune donnée du récept eur GNSS pendant plus de trois 
heures successives, il génère un messag e de réponse à la commande READ RECORD où le nombre 
RECORD est égal à ‘01’ et contenant une zone de données de 12 octets tous définis sur 0xFF . Dès 
réception du message de réponse avec cette valeur de zone de données, la VU génère et mémor ise un 
évènement de type EventFa ultT ype enum ‘52’H exter nal GNSS receiv er fault assor ti d'un horodatag e 
indiquant l'heure actuelle uniquement si les deux conditions suivantes sont satisf aites: a) le tach ygraphe 
intellig ent n'est pas en mode étalonnage et b) le véhicule circule. 26.5.2016 L 139/413 Jour nal officiel de l'Union européenne FR     
4.4.4  Expir ation du certificat du dispositif GNSS exter ne 
GNS_31  Si la VU détecte que le certificat EGF utilisé pour l'authentif ication mutuelle n'est plus valide, la VU 
génère et enregistre une anomalie de l'équipement d'enregistrement de type EventFaultT ype enum ‘56’H 
Exter nal GNSS facility certificate expir ed assor ti d'un horodatage indiquant l'heure actuelle. La VU utilise 
encore les données de positionnement GNSS reçues. 
Figure 4 
Schéma du dispositif GNSS exter ne 
5.  UNITÉ EMBARQUÉE SUR LE VÉHICULE SANS DISPOSITIF GNSS EXTERNE 
5.1.  Conf iguration 
Dans cette conf iguration, le récep teur GNSS est situé à l'inté rieur de la VU tel qu'illustré à la figure 1. 
GNS_32  Le récep teur GNSS tient le rôle de l'émett eur qui transmet les phrases NMEA au processeur de la VU, 
qui tient le rôle de récep teur sur une fréquence d'1/10 Hz ou supér ieure pour le jeu prédéf ini de phrases 
NMEA, lequel doit comprendre au moins les phrases RMC et GSA. 
GNS_33  Une antenne GNSS externe installée sur le véhicule ou une antenne GNSS interne doit être connect ée à 
la VU. 
5.2.  Traitement des erreurs 
5.2.1  Absence d'infor mations de positionnement en provenance du récep teur GNSS 
GNS_34  Si la VU ne reçoit aucune donnée du récept eur GNSS pendant plus de trois heures successives, la VU 
génère et mémor ise un évènement de type EventFaultT ype enum ‘51’H Inter nal GNSS receiv er fault assor ti 
d'un horodatag e indiquant l'heure actuelle uniquement si les deux conditions suivantes sont satisf aites: a) 
le tach ygraphe intelligent n'est pas en mode étalonnage et b) le véhicule circule. 
6.  CONFLIT TEMPOREL GNSS 
Si la VU détecte un écar t de plus d'une minut e entre le temps indiqué par sa fonction de mesure du temps et le 
temps indiqué par le récept eur GNSS, la VU mémor ise un évènement de type EventF aultT ype enum ‘0B’H Time 
conf lict (GNSS versus VU inter nal clock). Cet événement est enregistré avec la valeur de l'horloge interne de l'unit é 
embarquée sur le véhicule et s'accom pagne d'une remise à l'heure automatique. Après le déclenchement d'un 
événement «Conf lit temporel», la VU ne vérifie plus les écar ts temporels pendant les 12 heures suivantes. Cet 
événement n'est pas déclenché lorsqu'aucun signal GNSS valable n'a pu être détect é par le récep teur GNSS au 
cours des 30 derniers jours. Cependant, lorsque les informations de positionnement fournies par le récep teur 
GNSS sont à nouveau disponibles, la remise à l'heure automat ique est effectuée. 26.5.2016 L 139/414 Jour nal officiel de l'Union européenne FR     
7.  CONFLIT CONCERNANT LE MOUVEMENT DU VÉHICULE 
GNS_35  La VU déclenche et mémor ise un évènement de conf lit de mouvement du véhicule (cf. exigence 84 de 
l'annexe 1C) assor ti d'un horodatag e indiquant l'heure actuelle si les informations relatives au 
mouvement calculées par le capt eur de mouvement entrent en conf lit avec les informations relatives au 
mouvement calculées par le récept eur GNSS interne ou le dispositif GNSS extern e. Pour détecter ces 
conf lits, on utilise la valeur médiane des écar ts de vitess e entre ces sources, comme précisé ci-dessous: 
—  tout es les dix secondes, la valeur absolue de l'écar t entre la vitesse du véhicule estimée par le 
dispositif GNSS et celle estimée par le capt eur de mouvement est calculée. 
—  tout es les données calculées dans une fenêtre horaire compo rtant les dernières cinq minut es de 
mouvement servent à calculer la valeur médiane. 
—  la valeur médiane est calculée comme la moyenne des 80 % de valeurs restantes après élimination 
des plus élevées en valeur absolue. 
L'évènement de conf lit de mouvement du véhicule est déclenché si la valeur médiane dépasse 10 km/h 
pendant cinq minutes de circulation du véhicule ininte rrom pues. On peut également utiliser d'autres 
sources indépendant es de détection du mouvement du véhicule afin de renf orcer la fiabilité de détection 
des manipulations du tach ygraphe. (Remar que: utiliser la valeur médiane des cinq dernières minutes 
limite le risque d'aber rations de mesure et de valeurs transito ires.) Cet évènement ne se déclenche pas 
dans les cas suivants: a) lors d'un trajet en ferry/train, b) lorsque les informations de positionnement 
fournies par le récep teur GNSS ne sont pas disponibles et c) en mode étalonnage.  26.5.2016 L 139/415 Jour nal officiel de l'Union européenne FR     
Appendice 13 
INTERF ACE ITS 
TABLE DES MATIÈRES 
1. INTR ODUCTION ................................................................................................................................ 416 
2. CHA MP D'APPLICA TION ...................................................................................................................... 416 
2.1. Abréviations, définit ions et notations .......................................................................................... 417 
3. RÈGLEMENT ET NORMES RÉFÉRENTS ..................................................................................................... 418 
4. PRINCIPES DE FONCTIONNEMENT DE L'INTERF ACE .................................................................................. 418 
4.1. Conditions prérequises pour le transfer t de données au moyen de l'interface ITS ................................... 418 
4.1.1 Les données fournies grâce à l'interface ITS .................................................................................. 418 
4.1.2 Contenu des données .............................................................................................................. 418 
4.1.3 Applications ITS .................................................................................................................... 418 
4.2. Techn ologie de communication ................................................................................................. 419 
4.3. Autorisation PIN .................................................................................................................... 419 
4.4. Structure des messages ............................................................................................................ 421 
4.5. Consentement du conducteur .................................................................................................... 425 
4.6. Retrait de données standard ...................................................................................................... 426 
4.7. Récupération de données à caractère personnel ............................................................................. 426 
4.8. Récupération de données associées aux évènements et aux anomalies ................................................ 426  
1.  INTR ODUCTION 
Le présent appendice précise la conception et les procédures à respecter pour mettre en œuvre l'interface avec le 
système de transpor t intellig ent (ITS) tel que le préconise l'article 10 du règlement (UE) no 165/2014 (le règlement). 
Le règlement précise que les tach ygraphes des véhicules peuvent être équipés d'interfa ces normalisées permettant 
l'utilisation en mode opérationnel, par un dispositif extéri eur, des données enregistrées ou produite s par le 
tach ygraphe, pour autant que les conditions suivantes soient rem plies: 
(a)  l'inte rface n'aff ecte pas l'authenticit é ou l'intégrité des données du tach ygraphe; 
(b)  l'inte rface est conf orme aux dispositions détaillées énoncées à l'article 11 du règlement ; 
(c)  le dispositif extérieur connecté à l'interface n'a accès aux données à caractère personnel, y compr is celles 
relatives à la géolocalisation, qu'après obte ntion du consente ment vérifiable du conducteur auquel les données 
se rappor tent. 
2.  CHAMP D'APPLICA TION 
Le champ d'application du présent appendice consiste à préciser comment les applications héberg ées sur des 
dispositifs extern es obtiennent les données émanant d'un tach ygraphe par connexion Bluetooth®. 
Les données disponibles au moyen de cette interface sont décr ites à l'annex e 1 du présent document. Cette 
interf ace n'empêc he de mettre en œuvre d'autres interfaces (p. ex. au moyen d'un bus CAN) afin de transmettre les 
données de la VU à d'autres unités de traite ment sur véhicule. 26.5.2016 L 139/416 Jour nal officiel de l'Union européenne FR     
Le présent appendice précise: 
—  Les données disponibles grâce à l'interface ITS 
—  Le profil Bluet ooth® utilisé pour transfé rer les données 
—  Les procédures de demande et de télécharg ement et la séquence des opérations. 
—  Le mécanisme de couplage entre le tach ygraphe et le dispositif externe 
—  Le mécanisme d'accord accessible au conduct eur 
À titre d'éclaircissement, la présente annexe ne précise pas: 
—  la collect e de l'opération et de la gestion des données au sein de la VU (qui sera spécif iée ailleurs dans le 
Règlement ou constituera autrement une fonction de la concep tion du produit). 
—  La forme de la présentation des données collectées pour l'application héberg ée sur le dispositif extern e. 
—  Les dispositions de prote ction des données au-delà de ce que prévoi t Bluetooth ® (comme le codag e) 
concer nant le conte nu des données (qui sera précisé ailleurs dans le règlement [Appendice 10 — Mécanismes de 
sécur ité communs]). 
—  Les protocoles Bluetooth ® qu'utilise l'inte rface ITS. 
2.1.  Abréviations, définitions et notations 
Les abréviations et définitions qui suivent apparaissent dans le présent appendice: 
la communication  échang e d'inf ormations ou de données entre une unité maîtresse (comme les tach ygraphes) et 
une unité extern e à l'aide de l'inte rface ITS et de Bluet ooth®. 
les données  telles que définies à l'annexe 1. 
le règlement  Règlement (UE) no 165/2014 du Parlement européen et du Conseil du 4 février 2014 relatif 
aux tach ygraphes dans les transpor ts routiers, abrogeant le règlement (CEE) no 3821/85 du 
Conseil concer nant l'appareil de contrôle dans le domaine des transpor ts par route et 
modifiant le règlement (CE) no 561/2006 du Parlement européen et du Conseil relatif à 
l'har monisation de certaines dispositions de la législation sociale dans le domaine des 
transpor ts par rout e 
BR  Débit de base 
EDR  Débit de données amélioré 
GNSS  Global Navig ation Satellite Syste m (système mondial de radionavig ation par satellit e) 
IRK  Clé de résolution d'identité 
ITS (ITS)  Système de transpor t intellig ent 
LE  Faible valeur énergét ique 
PIN  Numéro d'identif ication personnel 
PUC  Code de déver rouillage personnel 
SID  Identif iant de diagnostic 
SPP  Profil de port série 
SSP  Couplage simple et sécur isé 
TRTP  Paramètre de demande du transfer t 
TREP  Paramètre de réponse du transfer t 
VU  Unité embarquée sur le véhicule 26.5.2016 L 139/417 Jour nal officiel de l'Union européenne FR     
3.  RÈGLEMENT ET NORMES RÉFÉRENTS 
La spécifi cation définie au présent appendice se réfère et dépend en tout ou en partie des règlements et normes 
suivants. Les normes ou leurs clauses concer nées figurent au fil des clauses du présent appendice. En cas de 
conf lit, les clauses du présent appendice prévalent. 
Les règlements et normes mentionnés au présent appendice sont les suivants: 
—  Règlement (UE) no 165/2014 du Parlement Européen et du Conseil du 4 févr ier 2014 relatif aux tach ygraphes 
dans les transpor ts routiers, abrogeant le règlement (CEE) no 3821/85 du Conseil concer nant l'appareil de 
contrôle dans le domaine des transpor ts par route et modifi ant le règlement (CE) no 561/2006 du Parlement 
européen et du Conseil relatif à l'har monisation de certaines dispositions de la législation sociale dans le 
domaine des transpor ts par route. 
—  Règlement (CE) no 561/2006 du Parlement européen et du Conseil du 15 mars 2006 relatif à l'har monisation 
de certaines dispositions de la législation sociale dans le domaine des transpor ts par route , modifiant les 
règlements (CEE) no 3821/85 et (CE) no 2135/98 du Conseil et abrogeant le règlement (CEE) no 3820/85 du 
Conseil. 
—  ISO 16844 — 4: Véhicules routiers — Systèmes tach ygraphes — Partie 4: Interface CAN 
—  ISO 16844 — 7: Véhicules routiers — Systèmes tach ygraphes — Partie 7: Paramètres 
—  Bluet ooth® — Profil de port série — V1.2 
—  Bluet ooth® — Version standard 4.2 
—  Prot ocole NMEA 0183 V4.1 
4.  PRINCIPES DE FONCTIONNEMENT DE L'INTERF ACE 
4.1.  Conditions prérequises pour le transfer t de données au moyen de l'interface ITS 
La VU est responsable de l'actualisation et de la mémor isation des données dans la VU sans impliquer l'inte rface 
ITS. Les moyens pour y parvenir sont intern es à la VU. Ils sont précisés ailleurs dans le règlement et pas au 
présent Appendice. 
4.1.1  Les données fournies grâce à l'interface ITS 
La VU est responsable de l'actualisation des données qui seront disponibles grâce à l'interface ITS selon une 
fréquence déterminée par les procédures de la VU, sans impliquer l'interface ITS. Les données de la VU sont 
utilisées comme base d'alimentation et d'actualisation des données. Les moyens pour y parvenir sont précisés 
ailleurs dans le règlement. En l'absence de précision, il s'agit d'une fonction liée à la concep tion du produit non 
spécifiée dans le présent Appendice. 
4.1.2  Contenu des données 
Le cont enu des données est spécifié en Annex e 1 du présent Appendice. 
4.1.3  Applications ITS 
Les applications ITS utilisent les données mises à disposition par l'inte rface ITS, par exem ple, dans le but 
d'op timiser la gestion des activité s du conduct eur tout en respectant le Règlement et pour détecter les éventuelles 
anomalies du tach ygraphe ou utiliser les données du dispositif GNSS. Les spécifi cations des applications sortent 
du cham p d'application du présent Appendice. 26.5.2016 L 139/418 Jour nal officiel de l'Union européenne FR     
4.2.  Technologie de communication 
L'écha nge de données à l'aide de l'interface ITS se fait par une interface Bluetooth® compat ible de version 4.2 ou 
ultérieure. Bluetooth® opère sur la bande de fréquence industr ielle, scientifi que et médicale (ISM) sans licence 
entre 2,4 GHZ et 2,485 GHz. Bluetooth® 4.2 comprend des mécanismes de sécur ité et de conf identialit é 
renf orcés et accroît la vitesse et la fiabilité des transfer ts de données. Aux fins de la présent e spécification, on 
utilise la portée radio Bluetooth® classe 2 pouvant atteindre 10 m. Pour tout complément d'inf ormation sur 
Bluetooth® 4.2, consulter www .bluet ooth.com (https://www .bluet ooth.org/en-us/specif ication/adop ted- 
specific ations?_ga= 1.215147412.2083380574.1435305676). 
La communication est établie avec l'équipement de communication après avoir procédé au couplage à l'aide d'un 
dispositif homologué. Le concep t Bluetooth® utilisant un modèle maître/esclave pour contrôler quand et où les 
dispositifs peuvent envoyer des données, le tach ygraphe joue le rôle d'unité maitresse et le dispositif externe, celui 
d'esclav e. 
Lorsqu'un dispositif exte rne entre dans le champ de portée de la VU pour la première fois, la procédure de 
couplage Bluetooth ® peut être démar rée (cf. Annexe 2). Les dispositifs partagent leur adresse, nom, profil et clé 
secrète commune. Cela leur permet de se connecte r dès qu'ils se retrouvent à proximité l'un de l'autre à nouveau. 
Après cette étape, le dispositif exte rne est sécur isé et en mesure d'eff ectuer des demandes de téléc harg ement de 
données émanant du tach ygraphe. Il n'est pas prévu d'ajout er des mécanismes de codage supplémentaires au-delà 
de ceux assurés par Bluetooth®. Cependant, si des mécanismes de sécur ité additionnels se révélaient nécessaires, 
ils seraient ajout és conf ormément à l'appendice 10 Mécanismes de sécur ité communs. 
Les principes de communication globaux sont décr its par la figure suivante. 
Le prof il SPP (Ser ial Port Profi le) de Bluetooth® sert à transfér er des données émanant de la VU à destination du 
dispositif exte rne. 
4.3.  Autori sation PIN 
Pour des raisons de sécur ité, la VU exécut e un système d'autoris ation de code PIN distinct du couplage 
Bluetooth®. Chaque VU est en mesure de générer des codes PIN à des fins d'authentification, composés d'au 
moins quatre chiffres. Chaque fois qu'un dispositif exte rne se couple avec la VU, il doit fournir le code PIN correct 
avant de recevoir des données, quelles qu'elles soient. 26.5.2016 L 139/419 Jour nal officiel de l'Union européenne FR     
Renseigner le PIN place le dispositif sur la liste autorisée. La liste autorisée mémor ise au moins 64 dispositifs 
couplés avec la VU considérée. 
Trois tentatives infructueuses de renseignement du code PIN placent temporairement le dispositif sur la liste noire, 
ce qui le verrouille. Tant qu'il est excl u, tout e nouvelle tentative du dispositif est vouée à l'éch ec. Toute nouvelle 
série de trois tentatives infructueuses successives à fournir le code PIN allonge la durée du verrouillage (cf. 
tableau 1). Renseigner le code PIN correct réinitialise la durée du verrouillage et le nombre de tentatives. La 
figure 1 de l'annexe 2 représente le déroulement chronologique d'une tentative de validation du PIN. 
Tableau1 
Durée du verrouillage selon le nombre d'échecs successifs à renseigner le code PIN correct 
Nombre d'échec s successifs Durée du verrouillage 
3 30 secondes 
6 5 minut es 
9 1 heure 
12 24 heures 
15 Perman ents  
Après quinze tentatives infructueuses successives (5 × 3) à renseigner le code PIN, l'unité ITS est définitivement 
verrouillée. La seule solution pour déver rouiller le système consiste à renseigner le code PUC correct. 
Le code PUC est compo sé de huit chiffres. Il est communiqué par le fabricant avec la VU. Après dix tentatives 
infructueuses successives à fournir le code PUC, l'unit é ITS est définitivement verrouillée et placée en liste noire. 
Il arrive que le fabricant permette à titre facultatif de modifi er le code PIN directement sur la VU; tout efois, le code 
PUC n'est pas modifi able. La modification du code PIN, le cas échéa nt, requier t de renseigner le code PIN 
direct ement sur la VU. 
De plus, tous les dispositifs placés en liste autori sée y demeurent jusqu'à leur retrait manuel par l'utilisateur (p. ex. 
à l'aide de l'interface homme-mac hine de la VU ou par d'autres moyens). Procéder de la sorte permet de 
suppr imer les unités ITS perdues ou volées de la liste autori sée. De même, tout es les unités ITS sortant de la 
portée de connexion Bluetooth® plus de vingt-quatre heures doivent être automatique ment suppr imées de la liste 
autori sée de la VU, et l'on doit renseigner le code PIN exact une nouvelle fois lorsque la connexion est rétablie. 
La structure des messag es entre l'interface de la VU et la VU n'est pas imposée, mais laissée à la discrétion du 
fabricant. Ledit fabr icant doit tout efois s'assurer que la structure des message s échangés entre l'unit é ITS et 
l'interface de la VU est respectée (cf. spécifi cations ASN.1). 
Toute demande de données doit donc satisfaire à la vérification correcte des identif iants de l'expédit eur préala ­
blement à tout e autre forme de traite ment. La figure 2 de l'annex e 2 représente le schém a du déroulement chrono ­
logique de cette procédure. Tout dispositif verrouillé reçoit un refus automat ique. Tout dispositif ni verrouillé ni 
autori sé reçoit une demande de PIN à renseigner avant de faire suivre sa demande de données. 26.5.2016 L 139/420 Jour nal officiel de l'Union européenne FR     
4.4.  Structure des messages 
Tous les messag es échang és entre l'unit é ITS et la VU se caract érisent par une structure à trois éléments: en-tête 
compo sé d'un octet cible (TGT), d'un octet source (SRC) et d'un octet de longueur (LEN). 
La zone de données compo sée d'un octet d'identif ication de diagnostic (SID) et d'un nombre variable d'oct ets 
d'inf ormation (maximum 255). 
L'octet total de contrôle correspond à une série de sommes d'1 octet modulo 256 représentant tous les octets du 
message à l'exclusion du CS lui-même. 
Le message correspond au Big Endian. 
Tableau2 
Structure générale des messages 
données Zone de données Total de 
contrôle 
TGT SRC LEN SID TRTP CC CM données CS 
3 octets 255 octets max. 1 octet  
En-tête 
TGT et SRC: ID des dispositifs cible (TGT) et source (SRC) du message . L'interf ace VU porte par défaut l'ID «EE». 
Cet ID n'est pas modifi able. L'unité ITS utilise l'ID «A0» par défaut pour son premier message de session de 
communication. L'interf ace de la VU assigne alors un ID unique à l'unité ITS et l'informe de cet ID pour les futurs 
message s de la session. 
L'octet LEN tient comp te uniquement de la partie «données» de la zone de données (cf. Tableau 2), car les quatre 
premiers octets sont implicites. 
L'inte rface VU confir me l'authenticité de l'expédit eur du messag e en contre-vér ifiant sa propre liste d'ID avec les 
données Bluetooth® et en vérifiant que l'unit é ITS correspondant à l'ID fourni est bien à portée de la connexion 
Bluetooth®. 
Zone de données 
Outre le SID, la zone de données doit également compo rter les paramètres suivants: un paramètre de demande du 
transfer t (TRTP) et des octets de comp teur . 
Si les données à transfér er dépassent l'espace disponible dans un message , elles seront partagées en plusieurs sous- 
message s. Chaque sous-message présente le même en-tête et le même SID, mais contient un comp teur sur deux 
octets, un comp teur courant (CC) et un comp teur max (CM) pour indiquer le numéro du sous-message. Afin de 
permettre le contrôle d'erreur et l'abandon éventuel d'un échange de données, le dispositif récep teur accuse 
récep tion de chaque sous-message . Le dispositif récep teur est à même d'accept er le sous-message , d'en demander 
la réémission et de demander au dispositif émetteur d'en reprendre ou d'en abandonner la transmission. 
Non utilisés, CC et CM présent ent la valeur 0xFF . 
Par exem ple: le message suivant 
EN-TÊTE SID TRTP CC CM données CS 
3 octets Longueur supér ieure à 255 octets 1 octet  26.5.2016 L 139/421 Jour nal officiel de l'Union européenne FR     
est transmis ainsi: 
EN-TÊTE SID TRTP 01 n données CS 
3 octets 255 octets 1 octet  
EN-TÊTE SID TRTP 02 n données CS 
3 octets 255 octets 1 octet  
… 
EN-TÊTE SID TRTP N N données CS 
3 octets 255 octets max. 1 octet  
Le tableau 3 présente les messages que la VU et l'unité ITS seront en mesure d'écha nger . Le contenu de chaque 
paramètre est fourni en code hexadécimal. Le tableau n'inclut pas CC et CM. Voir ci-dessus pour la structure 
compl ète. 
Tableau3 
Contenu déta illé des messages 
Messag e En-tête DONNÉES Total de 
contrôle 
TGT SRC LEN SID TRTP DONNÉES  
RequestPIN ITSID EE 00 01 FF   
SendITSID ITSID EE 01 02 FF ITSID  
SendPIN EE ITSID 04 03 FF 4*INTEGER (0..9)  
PairingR esult ITSID EE 01 04 FF BOOLEAN (T/F)  
SendPUC EE ITSID 08 05 FF 8*INTEGER (0..9)  
BanLif tingResu lt ITSID EE 01 06 FF BOOLEAN (T/F)  
RequestRejected ITSID EE 08 07 FF Temps  
RequestData  
standardT achData EE ITSID 01 08 01   
personalT achData EE ITSID 01 08 02   
gnssData EE ITSID 01 08 03   
standardEventData EE ITSID 01 08 04   
personalEventData EE ITSID 01 08 05   
standardFaultD ata EE ITSID 01 08 06   
manufa cturerData EE ITSID 01 08 07   26.5.2016 L 139/422 Jour nal officiel de l'Union européenne FR     
Messag e En-tête DONNÉES Total de 
contrôle 
TGT SRC LEN SID TRTP DONNÉES  
ResquestAccepted ITSID EE Len 09 TREP Résultats  
DataUnavail able  
Chiffres non disponi ­
bles ITSID EE 02 0A TREP 10  
données à caractère 
personnel non parta­
gées ITSID EE 02 0A TREP 11  
NegativeAnsw er  
Téléc hargement refusé ITSID EE 02 0B SID Req 10  
Service incompati ble ITSID EE 02 0B SID Req 11  
Sous-f onction incompa ­
tible ITSID EE 02 0B SID Req 12  
Longueur du message 
incor recte ITSID EE 02 0B SID Req 13  
Conditions non correc­
tes ou erreur affectant 
la séquence d'inte rroga ­
tion ITSID EE 02 0B SID Req 22  
Demande excessive ITSID EE 02 0B SID Req 31  
Réponse en suspens ITSID EE 02 0B SID Req 78  
Décalage ITSID ITSID EE 02 0B SID Req FC  
ITSID introuvable ITSID EE 02 0B SID Req FB   
RequestPIN (SID 01) 
Ce message est émis par l'interface de la VU si une unité ITS ni verrouillée ni autor isée lui adresse une demande 
de données. 
SendITSID (SID 02) 
Ce message est émis par l'interface de la VU dès qu'un nouveau dispositif lui adresse une demande. Ce dispositif 
utilise l'ID par défa ut «A0» avant de se voir assigner un ID unique pour la session de communication. 
SendPIN (SID 03) 
Ce message est émis par l'unité ITS pour que la VU la place en liste autorisée. Le cont enu de ce messag e est un 
code constitué d'un nombre ENTIER de 4 chiffres compris entre 0 et 9. 
PairingR esult (SID 04) 
Ce message est émis par l'interface de la VU pour informer l'unité du ITS si le code PIN envoyé est correct. Le 
conte nu de ce messag e est une valeur BOOLÉENNE d'une valeur «Vrai» si le code PIN est correct et «Faux» dans le 
cas contraire. 
SendPUC (SID 05) 
Ce message est émis par l'unit é ITS pour que la VU la suppr ime de la liste noire. Le cont enu de ce message est un 
code constitué d'un nombre ENTIER de 8 chiffres compris entre 0 et 9. 26.5.2016 L 139/423 Jour nal officiel de l'Union européenne FR     
BanLif tingResu lt (SID 06) 
Ce messag e est émis par l'inte rface de la VU pour informer l'unit é du ITS si le code PUC envoyé est correct. Le 
conte nu de ce message est une valeur BOOLÉENNE «vraie» si le code PUC est correct et «fausse» dans le cas 
contraire. 
RequestRejected (SID 07) 
Ce message est émis par l'interface de la VU en réponse à tout message émis par une unité ITS verrouillée hormis 
«SendPUC». Ce message compor te la durée restant e de verrouillage de l'unité ITS, selon la structure séquentielle 
«chr onologique» définie à l'annex e 3. 
RequestData (SID 08) 
Ce messag e d'accès aux données est émis par l'unit é ITS. Un paramètre de demande de transfer t (TRTP) d'un octet 
indique de quelle catégor ie de données il s'agit. Il existe plusieurs catégo ries de données: 
—  standardT achDa ta (TRTP 01): données disponibles en provenance du tach ygraphe classées non personnelles. 
—  personalT achD ata (TRTP 02): données disponibles en provenance du tach ygraphe classées personnelles. 
—  gnssData (TRTP 03): données du dispositif GNSS, toujours personnelles. 
—  standardEventData (TRTP 04): données relatives aux événements mémor isés classées non personnelles. 
—  personalEventData (TRTP 05): données relatives aux événements mémor isés classées personnelles. 
—  standardFa ultData (TRTP 06): anomalies mémor isées classées non personnelles. 
—  manuf acturerData (TRTP 07): données mises à disposition par le fabricant. 
Cf. Annexe 3 du présent Appendice pour tout e information compl émentaire relative à chaque catégo rie de 
données. 
Cf. l'appendice 12 pour tout complément d'inf ormation à propos de la structure et du cont enu des données du 
dispositif GNSS. 
Cf. les annexe s 1B et 1C pour tout compl ément d'inf ormation à propos du code et des anomalies relatifs aux 
données liées aux évènements. 
ResquestAccepted (SID 09) 
Ce message est émis par l'interface de la VU si un message «RequestData» émanant d'une unité ITS a été accept é. 
Ce message compo rte un octet TREP , qui correspond à l'octe t TRTP du message RequestData associé et tout es les 
données de la caté gorie demandée. 
DataUnavail able (SID 0A) 
Ce message est émis par l'inte rface de la VU si, pour une raison quelconque, il est impossible d'en voyer les 
données demandées à une unité ITS autori sée. Ce message compor te un octet TREP , qui correspond au TRTP des 
données demandées et un octet de code d'erreur spécifi é au Tableau 3. Les codes suivants sont disponibles: 
—  Aucune donnée disponible (10): l'interface de la VU ne parvient pas à accéder aux données de la VU pour des 
raisons non précisées. 
—  Données à caractère personnel non partagées (11): L'unit é ITS tent e d'extraire des données à caractère 
personnel non partagées. 26.5.2016 L 139/424 Jour nal officiel de l'Union européenne FR     
NegativeAnsw er (SID 0B) 
Ces message s sont émis par l'interface de la VU si une demande ne peut aboutir pour tout e autre raison que 
l'indisponibilit é des données. Ces messages résult ent généralement d'une mauvaise formulation de la structure de 
la demande (longueur , SID, ITSID…), sans s'y limite r. Le TRTP dans la zone de données compo rte le SID de la 
demande. La zone de données compo rte un code identif iant la raison de la réponse négative. Les codes suivants 
sont d'application: 
—  Rejet général (code: 10) 
—  L'action ne peut aboutir pour une raison non spécifi ée, ni ci-dessous ni dans la section (Renseigner le numéro 
de section DataUnavailabl e). 
—  Service non pris en charg e (code: 11) 
—  Le SID de la demande n'est pas compris . 
—  Sous-f onction non prise en charg e (code: 12) 
—  Le TRTP de la demande n'est pas compr is. Il peut par exem ple être manquant ou en dehors de la plage de 
valeurs accept ée. 
—  Longueur du messag e incor recte (code: 13) 
—  La longueur du message reçu est erronée (décalag e entre l'oct et LEN et la longueur réelle du message). 
—  Conditions non correcte s ou erreur affectant la séquence d'interr ogat ion (code: 22) 
—  Le service demandé n'est pas disponible ou la séquence des messag es de demande est incor recte. 
—  Demande excessiv e (code: 33) 
—  Le relevé (champ de données) du paramètre de la demande n'est pas valable. 
—  Réponse en suspens (code: 78) 
—  L'action réclamée ne peut être achevée dans le temps imparti et la VU n'est pas prête à accept er une autre 
demande. 
—  Décalag e ITSID (code: FB) 
—  L'ITSID du SRC ne correspond pas au dispositif associé après comparaison avec les informations émanant de 
Bluet ooth®. 
—  ITSID introuvable (code: FC) 
—  L'ITSID SRC n'est pas associé à un dispositif. 
Les lignes 1 à 72 (For matMessageModule) du code ASN.1 dans l'annex e 3 spécifi ent la structure des message s 
telle que décr ite au tableau 3. Davantage d'inf ormations suivent à propos du conte nu des messag es. 
4.5.  Consentement du conducteur 
Toutes les données disponibles sont classées comme standard ou à caractère personnel. Les données à caractère 
personnel sont uniquement accessibles si le conduct eur a donné son accord et accept er que ses données à 
caractère personnel liées au tach ygraphe quittent le réseau du véhicule à destination d'applications tierces. 
Le conduct eur donne son accord lorsqu'à la première inser tion d'une carte de conduct eur ou d'ate lier qui est 
encore inconnue de l'unité embarquée sur le véhicule, le détent eur est invité à donner son accord pour que les 
données à caractère personnel en lien avec le tach ygraphe puissent être extrait es via l'interface ITS facultative. (cf. 
Annex e 1C, paragraphe 3.6.2). 
L'état de l'accord (activé/désactivé) est mémor isé par le tach ygraphe. 
Dans le cas de conduct eurs multiples, seules les données à caractère personnel concer nant les conducteurs qui ont 
donné leur accord sont partagées avec l'inte rface ITS. Par exem ple, si deux conduct eurs occupent le véhicule et 
que seulement l'un d'entre eux accept e de partager ses données à caractère personnel, celles de l'autre conduct eur 
ne sont pas partagées. 26.5.2016 L 139/425 Jour nal officiel de l'Union européenne FR     
4.6.  Retrait de données standard 
La figure 3 de l'annex e 2 représent e le schém a de la séquence d'une demande valable adressée par l'unité ITS pour 
accéder aux données standard. L'unité ITS est placée en liste autori sée et ne demande aucune donnée à caractère 
personnel. Aucune autre vérification n'est requise. Les schémas illustrent le respect de la procédure adéquat e sur la 
Figure 2 de l'annexe 2. Cela correspond à la case grisée REQUES T TREATMENT de la Figure 2. 
Parmi les données disponibles, les données suivante s sont considérées comme standard: 
—  standardT achDa ta (TRTP 01) 
—  standardEventData (TRTP 04) 
—  standardFa ultData (TRTP 06) 
4.7.  Récupération de données à caractère personnel 
La Figure 4 de l'annex e 2 représente le schém a séquentiel du traitement d'une demande de données à caractère 
personnel. Comme précédemment expliqué, l'inte rface de la VU adresse des données à caractère personnel 
uniquement si le conducteur a donné son accord explicite (cf. 4.5). Dans le cas contraire, la demande doit être 
automat iquement rejet ée. 
Parmi les données disponibles, les données suivante s sont considérées comme personnelles: 
—  personalT achD ata (TRTP 02) 
—  gnssData (TRTP 03) 
—  personalEventData (TRTP 05) 
—  manuf acturerData (TRTP 07) 
4.8.  Récupération de données associées aux évènements et aux anomalies 
Les unités ITS sont en mesure de demander des données associées aux évènements compo rtant la liste de tous les 
évènements imprévus. Ces données sont considérées comme étant des données standard ou personnelles, cf. 
annexe 3. Le contenu de chaque évènement varie selon la documentation fournie en annex e 1 du présent 
Appendice.  26.5.2016 L 139/426 Jour nal officiel de l'Union européenne FR     
ANNEXE 1 
LISTE DES DONNÉES DISPONIBLES GRÂ CE À L'INTERF ACE ITS 
Data Source Data classif ication (personal/ 
not personal) 
VehicleIdentif icationNumber Vehicle Unit not personal 
CalibrationDat e Vehicle Unit not personal 
Tachog raphV ehicleSpeed speed instant t Vehicle Unit personal 
Driver1W orkingStat e Select or driver Vehicle Unit personal 
Driver2W orkingStat e Vehicle Unit personal 
DriveRecognize Speed Threshold detected Vehicle Unit not personal 
Driver1TimeRelatedStat es Weekly day time Driver Card personal 
Driver2TimeRelatedStat es Driver Card personal 
DriverCardDr iver1 Vehicle Unit not personal 
DriverCardDr iver2 Vehicle Unit not personal 
OverSpeed Vehicle Unit personal 
TimeDate Vehicle Unit not personal 
HighResolution TotalV ehicleDistance Vehicle Unit not personal 
ServiceComponentIdentification Vehicle Unit not personal 
ServiceDela yCalendarTimeBased Vehicle Unit not personal 
Driver1Identif ication Driver Card personal 
Driver2Identif ication Driver Card personal 
NextCalibrationDat e Vehicle Unit not personal 
Driver1ContinuousDr ivingTime Driver Card personal 
Driver2ContinuousDr ivingTime Driver Card personal 
Driver1CumulativeBreakTime Driver Card personal 
Driver2CumulativeBreakTime Driver Card personal 
Driver1Cur rentDurationOfSelectedA ctivity Driver Card personal 
Driver2Cur rentDurationOfSelectedA ctivity Driver Card personal 26.5.2016 L 139/427 Jour nal officiel de l'Union européenne FR     
Data Source Data classif ication (personal/ 
not personal) 
SpeedA uthor ised Vehicle Unit not personal 
Tachog raphCardSlot1 Driver Card not personal 
Tachog raphCardSlot2 Driver Card not personal 
Driver1Name Driver Card personal 
Driver2Name Driver Card personal 
OutOfScopeCondition Vehicle Unit not personal 
ModeOfOperation Vehicle Unit not personal 
Driver1CumulatedDr ivingTimePreviousAndCur rentW eek Driver Card personal 
Driver2CumulatedDr ivingTimePreviousAndCur rentW eek Driver Card personal 
EngineSpeed Vehicle Unit personal 
Regist eringMemberState Vehicle Unit not personal 
VehicleRegistrationNumber Vehicle Unit not personal 
Driver1EndOfLastDailyRestPer iod Driver Card personal 
Driver2EndOfLastDailyRestPer iod Driver Card personal 
Driver1EndOfLastW eeklyRestP eriod Driver Card personal 
Driver2EndOfLastW eeklyRestP eriod Driver Card personal 
Driver1EndOfSecondLastW eeklyRestPer iod Driver Card personal 
Driver2EndOfSecondLastW eeklyRestPer iod Driver Card personal 
Driver1Cur rentDailyDr ivingTime Driver Card personal 
Driver2Cur rentDailyDr ivingTime Driver Card personal 
Driver1Cur rentW eeklyDr ivingTime Driver Card personal 
Driver2Cur rentW eeklyDr ivingTime Driver Card personal 
Driver1TimeLef tUntilN ewDailyRestPer iod Driver Card personal 
Driver2TimeLef tUntilN ewDailyRestPer iod Driver Card personal 
Driver1CardExpir yDate Driver Card personal 26.5.2016 L 139/428 Jour nal officiel de l'Union européenne FR     
Data Source Data classif ication (personal/ 
not personal) 
Driver2CardExpir yDate Driver Card personal 
Driver1CardNextMandatory DownloadDat e Driver Card personal 
Driver2CardNextMandatory DownloadDat e Driver Card personal 
Tachog raphNextMandatory DownloadDat e Vehicle Unit not personal 
Driver1TimeLef tUntilN ewW eeklyRestP eriod Driver Card personal 
Driver2TimeLef tUntilN ewW eeklyRestP eriod Driver Card personal 
Driver1NumberOfTimes9hDailyDr ivingTimesExceeded Driver Card personal 
Driver2NumberOfTimes9hDailyDr ivingTimesExceeced Driver Card personal 
Driver1CumulativeUnint erruptedRestTime Driver Card personal 
Driver2CumulativeUnint erruptedRestTime Driver Card personal 
Driver1MinimumDailyRest Driver Card personal 
Driver2MinimumDailyRest Driver Card personal 
Driver1MinimumW eeklyRest Driver Card personal 
Driver2MinimumW eeklyRest Driver Card personal 
Driver1MaximumDailyPer iod Driver Card personal 
Driver2MaximumDailyPer iod Driver Card personal 
Driver1MaximumDailyDr ivingTime Driver Card personal 
Driver2MaximumDailyDr ivingTime Driver Card personal 
Driver1NumberOfUsedReducedDailyRestPer iods Driver Card personal 
Driver2NumberOfUsedReducedDailyRestPer iods Driver Card personal 
Driver1RemainingCur rentDr ivingTime Driver Card personal 
Driver2RemainingCur rentDr ivingTime Driver Card personal 
GNSS position Vehicle Unit personal  
2)DONNÉES ÉMANANT DU DISPOSITIF GNSS CONTINU APRÈS ACCORD DU CONDUCTEUR 
Cf. Appendice 12: GNSS 26.5.2016 L 139/429 Jour nal officiel de l'Union européenne FR     
3)CODES LIÉS AUX ÉVÈNEMENTS DISPONIBLES SANS L'ACCORD DU CONDUCTEUR 
Événement Règles de stoc kage données à enregistrer pour chaqu e événement 
Inser tion d'une carte 
non valable —  les 10 événements les plus 
récents —  la date et l'heure de l'événement, 
—le type et le numéro de la carte ou des cartes, l'État mem ­
bre de délivrance et la génération de la carte à l'origine de 
l'événement, 
—  le nombre d'événements semblables survenus le même 
jour . 
Conf lit de carte —  les 10 événements les plus 
récents —  la date et l'heure du début de l'événement, 
—  la date et l'heure de la fin de l'événement, 
—le type et le numéro de la carte ou des cartes, l'État mem ­
bre de délivrance et la génération de chacune des deux car­
tes à l'origine du conf lit. 
Clôture incor recte de 
la dernière session —  les 10 événements les plus 
récents —  la date et l'heure de l'inser tion, 
—  le type et le numéro de la ou des cartes, l'État membre de 
délivrance et la génération, 
—les données relatives à la dernière session telles qu'elles fi­
gurent sur la carte: 
—  la date et l'heure de l'inser tion, 
—le numéro d'immatr iculation, l'État membre d'immatr i­
culation et la génération de la VU. 
Interr upti on de l'ali­
mentation élec­
trique (2) —  l'événement le plus long 
survenu au cours de cha­
cun des 10 derniers jours 
d'occur rence, 
—  les 5 événements les plus 
longs enregistrés au cours 
des 365 derniers jours. —  la date et l'heure du début de l'événement, 
—  la date et l'heure de la fin de l'événement, 
—le type et le numéro de la carte ou des cartes, l'État mem ­
bre de délivrance et la génération de tout e carte insérée au 
début et/ou à la fin de l'événement, 
—  le nombre d'événements semblables survenus le même 
jour . 
Erreur de communi ­
cation avec l'équipe ­
ment de communica ­
tion à distance —  l'événement le plus long 
survenu au cours de cha­
cun des 10 derniers jours 
d'occur rence, 
—  les 5 événements les plus 
longs enregistrés au cours 
des 365 derniers jours. —  la date et l'heure du début de l'événement, 
—  la date et l'heure de la fin de l'événement, 
—  le type et le numéro de la ou des cartes, l'État membre de 
délivrance et la génération de tout e carte insérée au début 
et/ou à la fin de l'événement, 
—  le nombre d'événements semblables survenus le même 
jour . 
Absence d'inf orma­
tions de position en 
provenance du récep ­
teur GNSS —  l'événement le plus long 
survenu au cours de cha­
cun des 10 derniers jours 
d'occur rence, 
—  les 5 événements les plus 
longs enregistrés au cours 
des 365 derniers jours. —  la date et l'heure du début de l'événement, 
—  la date et l'heure de la fin de l'événement, 
—le type et le numéro de la carte ou des cartes, l'État mem ­
bre de délivrance et la génération de tout e carte insérée au 
début et/ou à la fin de l'événement, 
—  le nombre d'événements semblables survenus le même 
jour . 
Erreur au niveau des 
données de mouve ­
ment —  l'événement le plus long 
survenu au cours de cha­
cun des 10 derniers jours 
d'occur rence, 
—  les 5 événements les plus 
longs enregistrés au cours 
des 365 derniers jours. —  la date et l'heure du début de l'événement, 
—  la date et l'heure de la fin de l'événement, 
—le type et le numéro de la carte ou des cartes, l'État mem ­
bre de délivrance et la génération de tout e carte insérée au 
début et/ou à la fin de l'événement, 
—  le nombre d'événements semblables survenus le même 
jour . 26.5.2016 L 139/430 Jour nal officiel de l'Union européenne FR     
Événement Règles de stoc kage données à enregistrer pour chaqu e événement 
Conf lit concer nant le 
mouvement du véhi ­
cule —  l'événement le plus long 
survenu au cours de cha­
cun des 10 derniers jours 
d'occur rence, 
—  les 5 événements les plus 
longs enregistrés au cours 
des 365 derniers jours. —  la date et l'heure du début de l'événement, 
—  la date et l'heure de la fin de l'événement, 
—le type et le numéro de la carte ou des cartes, l'État mem ­
bre de délivrance et la génération de tout e carte insérée au 
début et/ou à la fin de l'événement, 
—  le nombre d'événements semblables survenus le même 
jour . 
Tentative d'atte inte à 
la sécur ité les 10 événements les plus ré­
cents pour chaque type d'évé ­
nements. —  la date et l'heure du début de l'événement, 
—  la date et l'heure de la fin de l'événement, 
—le type et le numéro de la carte ou des cartes, l'État mem ­
bre de délivrance et la génération de tout e carte insérée au 
début et/ou à la fin de l'événement, 
—  le type d'événement. 
Conf lit temporel —  l'événement le plus long 
survenu au cours de cha­
cun des 10 derniers jours 
d'occur rence, 
—  les 5 événements les plus 
longs enregistrés au cours 
des 365 derniers jours. —  la date et l'heure de l'appareil de contrôle, 
—  la date et l'heure du GNSS, 
—  le type et le numéro de la ou des cartes, l'État membre de 
délivrance et la génération de tout e carte insérée au début 
et/ou à la fin de l'événement, 
—  le nombre d'événements semblables survenus le même 
jour .  
4)CODES LIÉS AUX ÉVÈNEMENTS DISPONIBLES SANS L'ACCORD DU CONDUCTEUR 
Événement Règles de stoc kage données à enregistrer pour chaqu e événement 
Conduite sans carte 
appropr iée —  l'événement le plus long 
survenu au cours de cha­
cun des 10 derniers jours 
d'occur rence, 
—  les 5 événements les plus 
longs enregistrés au cours 
des 365 derniers jours. —  la date et l'heure du début de l'événement, 
—  la date et l'heure de la fin de l'événement, 
—le type et le numéro de la carte ou des cartes, l'État mem ­
bre de délivrance et la génération de tout e carte insérée au 
début et/ou à la fin de l'événement, 
—  le nombre d'événements semblables survenus le même 
jour . 
Inser tion d'une carte 
en cours de route —  le dernier événement pour 
chacun des 10 derniers 
jours d'occur rence, —  la date et l'heure de l'événement, 
—le type et le numéro de la carte ou des cartes, l'État mem ­
bre de délivrance et la génération, 
—  le nombre d'événements semblables survenus le même 
jour . 
Excès de vitesse (1) —  l'événement le plus grave 
(c.-à.-d. celui présentant la 
vitesse moyenne la plus 
élevée) des 10 derniers 
jours d'occur rence, 
—  les 5 événements les plus 
grav es au cours des 365 
derniers jours. 
—le premier événement sur­
venu après le dernier éta­
lonnag e, —  la date et l'heure du début de l'événement, 
—  la date et l'heure de la fin de l'événement, 
—  la vitesse maximale mesurée au cours de l'événement, 
—la vitesse moyenne arithmétique mesurée au cours de l'évé ­
nement, 
—  le type et le numéro de carte, l'État membre de délivrance 
et la génération de la carte de conduct eur (le cas éché ant), 
—  le nombre d'événements semblables survenus le même 
jour .  26.5.2016 L 139/431 Jour nal officiel de l'Union européenne FR     
5)CODES LIÉS AUX DONNÉES REL ATIVES AUX ANOMALIES DISPONIBLES SANS L'ACCORD DU CONDUCTEUR 
Faut e Règles de stoc kage données à enregistrer pour chaque anomalie 
Anomalie de la carte —  les dix dernières anomalies 
de la carte de conducteur . —  la date et l'heure du début de l'anomalie, 
—  la date et l'heure de la fin de l'anomalie, 
—le type et le numéro de la carte ou des cartes, l'État mem ­
bre de délivrance et la génération. 
Anomalies de l'appa ­
reil de contrôle —  les 10 anomalies les plus 
récent es pour chaque type 
d'anomalie, 
—  la première anomalie après 
le dernier étalonnage, —  la date et l'heure du début de l'anomalie, 
—  la date et l'heure de la fin de l'anomalie, 
—  la type de l'anomalie, 
—  le type et le numéro de la ou des cartes, l'État membre de 
délivrance et la génération de tout e carte insérée au début 
et/ou à la fin de l'anomalie.  
Cette anomalie est déclenché e dans le cas des anomalies suivantes, dans les modes autres qu'étalonnage: 
—  Défaillance interne de la VU 
—  anomalie de l'impri mante, 
—  anomalie de l'affichage, 
—  anomalie de téléc hargement, 
—  anomalie du capt eur, 
—  anomalie du récept eur GNSS ou du dispositif GNSS exte rne, 
—  anomalie de l'équipement de communication à distance. 
6)ÉVÈNEMENTS ET ANOMALIES PARTICULIERS SE RAPPORT ANT AU FABRICANT SANS ACCORD DU CONDUCTEUR 
Événement ou 
anomalie Règles de stoc kage données à enregistrer pour chaqu e événement 
À définir par le fabri­
cant À définir par le fabricant À définir par le fabr icant   26.5.2016 L 139/432 Jour nal officiel de l'Union européenne FR     
ANNEXE 2 
SCHÉMAS SÉQUENTIELS DES ÉCHANGES DE MESSA GES AVEC L'UNITÉ ITS. 
Figure 1 
Schéma séquentiel de la tentati ve de validation du PIN 
26.5.2016 L 139/433 Jour nal officiel de l'Union européenne FR     
Figure 2 
Schéma séquentiel de la vérification d'autori sation par l'unité ITS 
26.5.2016 L 139/434 Jour nal officiel de l'Union européenne FR     
Figure 3 
Schéma séquentiel du traitement d'une demande de données non personnelles (après accès PIN correct) 
Figure 4 
Schéma séquentiel du traitement d'une demande de données à caractère personnel (après accès PIN correct) 
26.5.2016 L 139/435 Jour nal officiel de l'Union européenne FR     
Figure 5 
Schéma séquentiel de la tent ativ e de validation du PUC 
26.5.2016 L 139/436 Jour nal officiel de l'Union européenne FR     
ANNEXE 3 
SPÉCIFIC ATIONS ASN .1 
26.5.2016 L 139/437 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/438 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/439 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/440 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/441 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/442 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/443 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/444 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/445 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/446 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/447 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/448 Jour nal officiel de l'Union européenne FR     
Appendice 14 
FONCTION DE COMMUNIC ATION À DIST ANCE 
TABLE DES MATIÈRES 
1 INTR ODUCTION ................................................................................................................................ 450 
2 CHA MP D'APPLICA TION ...................................................................................................................... 451 
3 ABRÉVIA TIONS, DÉFINITIONS ET NOT ATIONS ......................................................................................... 452 
4 CAS DE FIGURE OPÉRA TIONNELS ......................................................................................................... 454 
4.1 Vue d'ensemble ...................................................................................................................... 454 
4.1.1 Conditions prérequises pour le transfer t de données au moyen de l'interface DSR C 5,8 GHz ................... 454 
4.1.2 Profi l 1a: à l'aide d'un lecteur de communication à distance à des fins de détection précoce qui est dirigé 
manuellement ou installé et dirigé temporairement en bord de route ................................................. 455 
4.1.3 Profi l 1b: à l'aide d'un lecte ur de communication à distance à des fins de détec tion précoce (REDCR) qui est 
installé et dirigé dans un véhicule ............................................................................................... 456 
4.2 Sécur ité/Intégr ité.................................................................................................................... 456 
5 CONCEPTION ET PROTOCOLES DE LA COMMUNIC ATION À DIST ANCE ........................................................ 456 
5.1 Conception ........................................................................................................................... 456 
5.2 Déroulement des opérations ..................................................................................................... 459 
5.2.1 Opérations ........................................................................................................................... 459 
5.2.2 Interp rétation des données reçues au moyen de la communication DSR C............................................ 461 
5.3 Paramètres de l'interface DSR C physique pour la communication à distance ........................................ 461 
5.3.1 Contraintes d'emplacem ent ....................................................................................................... 461 
5.3.2 Paramètres de liaisons descendant e et montante ............................................................................ 461 
5.3.3 Conception de l'antenne .......................................................................................................... 466 
5.4 Exigences du prot ocole DSR C pour RTM..................................................................................... 466 
5.4.1 Vue d'ensemble ...................................................................................................................... 466 
5.4.2 Commandes .......................................................................................................................... 469 
5.4.3 Séquence de commande d'inte rrogation ....................................................................................... 469 
5.4.4 Structures de données ............................................................................................................. 470 
5.4.5 Éléments de RtmData, actions effectuées et définitions .................................................................... 472 
5.4.6 Mécanisme de transfer t de données ............................................................................................ 476 
5.4.7 Descr iption détaillée de la transaction DSR C................................................................................. 476 
5.4.8 Descr iption de la transaction d'essai DSR C................................................................................... 486 
5.5 Conf ormité à la directive 2015/71/CE ......................................................................................... 490 
5.5.1 Vue d'ensemble ...................................................................................................................... 490 26.5.2016 L 139/449 Jour nal officiel de l'Union européenne FR     
5.5.2 Commandes .......................................................................................................................... 490 
5.5.3 Séquence de commande d'inte rrogation ....................................................................................... 490 
5.5.4 Structures de données ............................................................................................................. 490 
5.5.5 Module ASN.1 de la transaction DSR C OWS ................................................................................ 491 
5.5.6 Éléments OwsData, actions effectuées et définitions ....................................................................... 492 
5.5.7 Mécanismes de transfer t de données ........................................................................................... 492 
5.6 Transf ert de données entre la DSR C-VU et la VU ........................................................................... 492 
5.6.1 Connexion physique et interfaces ............................................................................................... 492 
5.6.2 Protocole d'application ............................................................................................................ 493 
5.7 Traitem ent des erreurs ............................................................................................................. 494 
5.7.1 Enregistrement et communication des données dans la DSR C-VU ...................................................... 494 
5.7.2 Anomalies de communication sans fil......................................................................................... 494 
6 MISE EN SER VICE ET ESSAIS D'INSPECTION PÉRIODIQUES REL ATIFS À LA FONCTION DE COMMUNICA TION À 
DIST ANCE ........................................................................................................................................ 496 
6.1 Généralités ............................................................................................................................ 496 
6.2 ECHO .................................................................................................................................. 496 
6.3 Essais de validation du cont enu des données sécur isées ................................................................... 496  
1  INTR ODUCTION 
Le présent appendice spécifi e la concep tion et les procédures à respecter pour mettre en œuvre la fonction de 
communication à distance (la communication) conf ormément aux dispositions de l'article 9 du règlement (UE) 
no 165/2014 (le règlement). 
DSC_1  Le règlement (UE) no 165/2014 détermine que le tach ygraphe est équipé d'une fonctionnalité de 
communication à distance qui permet aux autor ités chargée s du contrôle compét entes de lire les 
informations du tach ygraphe embarqué sur les véhicules en circulation à l'aide d'un équipement 
d'interro gation à distance (lect eur de communication à distance à des fins de détection précoce, 
REDCR). Il s'agit notamment d'un équipement d'interr ogation à connexion sans fil utilisant des 
interfa ces de communication spécialisée à cour te portée (DSR C) dans la bande de fréquences CEN 
5,8 GHz 
Il est important de comprendre que cette fonctionnalité sert uniquement de préfiltre pour sélectionner 
les véhicules qui feront l'objet d'un contrôle plus approf ondi. Cette fonctionnalité ne remplace pas la 
procédure d'inspection formelle définie par les dispositions du règlement (UE) no 165/2014. Voir le 
considérant 9 du préambule de ce règlement qui énonce que la communication à distance entre le 
tach ygraphe et les autor ités chargée s des contrôles routiers facilite les contrôles routiers ciblés. 
DSC_2  Les données sont échang ées à l'aide de la communication qui désigne un appareil sans fil utilisant la 
bande de fréquences de 5,8 GHz pour communiquer à distance, conf orme à cet appendice, et validé 
en fonction des paramètres pertinents de la norme EN 300 674-1, {Electromagnetic compati bility and 
Radio spectr um Matters (ERM); Road Transpor t and Traffic Telematics (RTTT); Dedicat ed Shor t Range 
Communication (DSR C) transmission equipment (500 kbit/s / 250 kbit/s) operating in the 5,8 GHz 
Industr ial, Scientifi c and Medical (ISM) band; Part 1: General charact eristics and test methods for Road 
Side Units (RSU) and On -Board Units (OBU)}. 
DSC_3  La communication est établie à l'aide de l'équipement de communication uniquement lorsque 
l'équipement de l'autorité de contrôle compét ent en fait la demande, à l'aide des moyens de radiocom ­
munication compatibles (lecteur de communication de détection précoce à distance, REDCR). 
DSC_4  Les données sont prot égées pour assurer leur intégr ité. 26.5.2016 L 139/450 Jour nal officiel de l'Union européenne FR     
DSC_5  L'accès aux données communiquées est restreint aux autori tés de contrôle compét entes autor isées à 
contrôler les infractions au règlement (CE) no 561/2006, au règlement (UE) no 165/2014 et aux 
ateli ers dans la mesure où cela s'avère nécessaire pour vérifier le fonctionnement satisfaisant du 
tach ygraphe. 
DSC_6  Les données échang ées durant la communication sont limité es à celles qui sont nécessaires aux fins des 
contrôles routiers ciblant les véhicules dont le tach ygraphe a pu être manipulé ou faire l'objet d'une 
utilisation abusive. 
DSC_7  L'intégri té et la sécur ité des données résult ent de la sécur isation des données dans l'unité embarquée sur 
le véhicule (VU) combinée à l'utilisation excl usive du suppor t de communication à distance sans fil 
DSR C sur la bande 5,8 GHz pour transfé rer les données utiles sécur isées et les données relatives à la 
sécur ité (cf. 5.4.4). Cela implique que seul le personnel autor isé des autor ités de contrôle compét entes 
dispose des moyens d'interpréter les données reçues par le canal de communication et de vérifier leur 
authenticité . Cf. appendice 11 — Mécanismes communs de sécur ité. 
DSC_8  Les données contiennent un timbre horodateur indiquant l'heure de leur dernière mise à jour . 
DSC_9  Le cont enu des données relatives à la sécur ité est uniquement connu des autor ités de contrôle 
compét entes qui le régissent et des parties avec lesquelles elles partagent ces informations et ne relève 
pas des dispositions de la communication, faisant l'objet du présent appendice, hormis en ce que la 
communication prévoit le transfer t d'un paquet de données relatives à la sécur ité avec chaque paquet de 
données utiles. 
DSC_10  La même archit ecture et le même équipement servent à extraire d'autres concep ts de données (comme 
le poids à bord) en adoptant l'arc hitecture spécifi ée aux présent es. 
DSC_11  Par souci de précision, conf ormément aux dispositions du règlement (UE) no 165/2014 (article 7), les 
données concer nant l'identit é du conduct eur ne sont pas transmises par la communication. 
2  CHAMP D'APPLICA TION 
Le présent appendice vise à préciser la manière dont les agents des autor ités de contrôle compét entes utilisent 
une communication sans fil DSR C spécifi ée sur la bande des 5,8 GHz pour obtenir à distance des données (les 
données) provenant d'un véhicule ciblé, ces données devant servir à déterminer si ce véhicule est éventuellement 
en infraction avec le règlement (UE) no 165/2014 et s'il faut envisager de l'arrêter afin de procéder à un contrôle 
plus poussé. 
Le règlement (UE) no 165/2014 exige que les données collectées se limitent à celles qui identif ient une 
infraction éventuelle ou qui s'y appor tent, conf ormément à l'article 9 du règlement (UE) no 165/2014. 
Ce cas de figure prévoit une durée de communication limitée parce que la communication est ciblée et qu'elle se 
fait à cour te portée. Par ailleurs, les autori tés de contrôle compé tent es peuvent utiliser les moyens de communi ­
cation assurant le contrôle à distance des tach ygraphes (RTM) pour d'autres applications, comme le poids 
maximal et les dimensions maximales des poids lourds définis dans la directive (UE) 2015/719. Ces opérations 
peuvent être distinctes du contrôle à distance des tach ygraphes ou consécutives à celui-ci, à la discrétion des 
autorités de contrôle compét entes. 
Le présent appendice spécifi e: 
—  L'équipement, les procédures et les protocoles de communication à utiliser pour la communication. 
—  Les normes et règlements que l'équipement radio doit respecter . 
—  La présentation des données à l'équipement de communication. 
—  Les procédures de demande et de télécharg ement et la séquence des opérations. 
—  Les données à transfér er. 
—  L'inter prétation poten tielle des données transmises via la communication. 
—  Les dispositions relatives aux données de sécur ité liées à la communication. 26.5.2016 L 139/451 Jour nal officiel de l'Union européenne FR     
—  La mise à disposition des données aux autor ités de contrôle compét entes. 
—  La façon dont le lecteur de communication à distance à des fins de détection précoce (REDCR) peut demander 
plusieurs concep ts de données relatifs au fret et à la flotte. 
Pour plus de précision, le présent appendice ne spécif ie pas: 
—  La collect e et la gestion des données dans la VU (qui dépendent de la concep tion du produit sauf mention 
contraire dans le règlement (UE) no 165/2014). 
—  La forme de présentation des données collect ées à l'agen t des autori tés de contrôle compét entes ou les 
critères utilisés par celles-ci pour décider quel véhicule arrêter (qui dépendent de la concep tion du produit, 
sauf s'il y est fait mention ailleurs dans le règlement (UE) no 165/2014 ou dans une décision des autori tés de 
contrôle compét entes). Par souci de précision: la communication se limite à mettre les données à la disposition 
des autor ités de contrôle compét entes afin qu'elles puissent prendre des décisions éclairées. 
—  Les dispositions relatives à la sécur ité des données (telles que le crypta ge) concer nant le contenu des données 
(spécif iées à l'appendice 11 Mécanismes communs de sécur ité). 
—  Le détail de tous les concep ts de données autres que RTM pouvant être obtenu s à l'aide de la même 
archit ecture et du même équipement. 
—  Les détails du compo rtement et de la gestion entre la VU et la DSR C-VU ou le compo rteme nt au sein de la 
DSR C-VU (autre que dans le but de fournir les données en réponse à la demande d'un REDCR). 
3  ABRÉVIA TIONS, DÉFINITIONS ET NOT ATIONS 
Dans le présent appendice, sont utilisées les abréviations et définit ions suivantes: 
Antenne  Dispositif électr ique qui conver tit l'énergie électr ique en ondes radio et 
inversement, utilisé avec un émette ur ou un récept eur radio. En fonction ­
nement, un émetteur radio fournit un courant électr ique oscillant à une 
fréquence radio aux bornes de l'antenne . L'ant enne rayonne et émet l'énergie 
du courant électr ique sous forme d'ondes électromagnétiques (ondes radio). En 
mode réception, une antenne capt e une part de l'énergie émise par une onde 
électromagnétique pour produire une tension très faible à ses bornes, 
qu'am plifie un récept eur. 
Communication  Échange d'inf ormations et de données entre un DSR C-REDCR et une DSR C- 
VU conf ormément à la section 5 et selon une relation maître-escla ve en vue 
d'obte nir les données. 
Données  Données sécur isées adoptant une structure définie (cf. 5.4.4) demandées par le 
DSRC-REDCR et fournies par la DSRC-VU à l'aide d'une liaison DSR C sur la 
bande de 5,8 GHz, comme défini au point 5 ci-après. 
Règl ement (UE) no 165/2014  Règlement (UE) no 165/2014 du Parleme nt Européen et du Conseil du 4 
février 2014 relatif aux tach ygraphes dans les transpor ts routiers, abrogeant le 
règlement (CEE) no 3821/85 du Conseil concer nant l'appareil de contrôle dans 
le domaine des transpor ts par route et modifiant le règlement (CE) 
no 561/2006 du Parlement européen et du Conseil relatif à l'har monisation de 
certaines dispositions de la législation sociale dans le domaine des transpor ts 
par route. 
AID  Identificateur d'application 
BLE  Bluet ooth Low Energy 
BST  Table de service de balise (Beacon Service Table) 26.5.2016 L 139/452 Jour nal officiel de l'Union européenne FR     
CIWD  Inser tion d'une carte en cours de conduit e 
CRC  Contrôle de redondance cyclique 
DSC (n)  Identificateur d'une exigenc e pour un appendice DSR C donné 
DSR C  communication spécialisée à cour te portée 
DSR C-REDCR  Lect eur de communication à distance à des fins de détection précoce DSR C 
DSR C-VU  Unité embarquée sur le véhicule DSR C Il s'agit du «dispositif de détection 
précoce à distance» défini à l'annex e 1C. 
DWV C  Conduite sans carte en cours de validité 
EID  Identificateur d'élément 
LLC  Contrôle de liaison logique 
LPDU  Unité de données de prot ocole LLC 
OWS  Système de pesage embarqué 
PDU  Unité de données de prot ocole 
REDCR  Lect eur de communication à distance à des fins de détection précoce. Il s'agit 
du «lect eur de communication à distance à des fins de détec tion précoce» 
défini à l'annex e 1C. 
RTM  Contrôle à distance du tach ygraphe 
SM-REDCR  Lect eur de communication à distance à des fins de détection précoce, module 
de sécur ité 
TARV  Applications télématiques collaboratives pour véhicules de fret commercial 
réglementé (série de normes ISO 15638) 
VU  Unité embarquée sur le véhicule 
VUPM  Mémoire utile de la VU 
VUSM  Module de sécur ité de la VU 
VST  Table de service de véhicule 
WIM  Poids en mouvement 
WOB  Poids à bord 
La spécifi cation définie au présent appendice renv oie aux règlements et normes suivants, et dépend d'eux en 
tout ou en partie. Les normes ou leurs clauses applicables figurent dans le présent appendice. En cas de conf lit, 
les dispositions du présent appendice prévalent. En cas de conf lit qu'aucune spécification du présent appendice 
ne résout, le fonctionnement conf ormément à la recommandation ERC 70-03 (et testé selon les paramètres 
pertinents de la norme EN 300 674-1) prévaut, suivi, dans l'ordre, par les normes EN 12795, EN 12253, EN 
12834 et EN 13372, 6.2, 6.3, 6.4 et 7.1. 
Les règlements et normes mentionnés au présent appendice sont les suivants:  
[1] Règlement (UE) no 165/2014 du Parlement européen et du Conseil du 4 février 2014 relatif aux 
tach ygraphes dans les transpor ts routiers, abrogeant le règlement (CEE) no 3821/85 du Conseil concer nant 
l'appareil de contrôle dans le domaine des transpor ts par route et modifi ant le règlement (CE) 
no 561/2006 du Parlement européen et du Conseil relatif à l'har monisation de certaines dispositions de la 
législation sociale dans le domaine des transpor ts par rout e. 26.5.2016 L 139/453 Jour nal officiel de l'Union européenne FR     
[2] Règlement (UE) no 561/2006 du Parlement européen et du Conseil du 15 mars 2006 relatif à l'har moni ­
sation de certaines dispositions de la législation sociale dans le domaine des transpor ts par route, 
modifi ant les règlements (CEE) no 3821/85 et (CE) no 2135/98 du Conseil et abrogea nt le règlement (CEE) 
no 3820/85 du Conseil (Texte présentant de l'intérêt pour l'EEE).  
[3] ERC 70-03 CEPT : Recommandation CCE 70-03 relative à l'utilisation des dispositifs à cour te portée (DCP).  
[4] Nor me ISO 15638 Intellig ent transpor t systems — Framew ork for cooperative telematics applications for 
regulated commercial freight vehicles (TARV).  
[5] Nor me EN 300 674-1 Electromagnetic compatibility and Radio spectr um Matt ers (ERM); Road Transpor t 
and Traffi c Telematics (RTTT); Dedicat ed Shor t Range Communication (DSR C) transmission equipment 
(500 kbit/s / 250 kbit/s) operating in the 5,8 GHz Industr ial, Scientifi c and Medical (ISM) band; Part 1: 
General charact eristics and test methods for Road Side Units (RSU) and On-Board Units (OBU).  
[6] Nor me EN 12253 Road transpor t and traff ic telem atics — Dedicat ed shor t-rang e communication — 
Physical layer using micro wave at 5.8 GHz..  
[7] Nor me EN 12795 Road transpor t and traff ic telem atics — Dedicated shor t-rang e communication — Data 
link layer: medium access and logical link control.  
[8] Nor me EN 12834 Road transpor t and traff ic telem atics — Dedicat ed shor t-rang e communication — 
Application layer.  
[9] Nor me EN 13372 Road transpor t and traff ic telem atics — Dedicat ed shor t-rang e communication — 
Profi les for RTTT applications  
[10] Nor me ISO 14906 Electronic fee collection — Application interfa ce definition for dedicat ed shor t- range 
communication 
4  CAS DE FIGURE OPÉRA TIONNELS 
4.1  Vue d'ensemble 
Le règlement (UE) no 165/2014 prévoit des cas de figure spécifi ques et contrôlés encadrant la communication. 
Les scénar ios pris en charge sont les suivants: 
«Pro fil de communication 1: contrô le routier utilisant un lecteur de communication à distance à des fins de détection 
précoce, sans fil et à cour te portée afin de procéder à des contrô les routiers physiq ues (maître/esclav e) 
Profil de lecteur 1a: à l'aide d'un lecteur de communication à distance à des fins de détection précoce qui est dirigé 
manuellement ou installé et dirigé tempor airement en bord de route 
Profil de lecteur 1b: à l'aide d'un lecteur de communication à distance à des fins de détection précoce qui est installé et dirigé 
à bord d'un véhicule». 
4.1.1  Conditions prérequises pour le transfer t de données au moyen de l'interf ace DSRC 5,8 GHz 
NOTE: pour compre ndre le context e des conditions prérequises, le lecteur se référera à la figure 14.3 ci-dessous.  
4.1.1.1  Données détenues par la VU 
DSC_12  La VU est responsable de l'actualisation et de la mémor isation des données qu'elle stoc ke selon une 
fréquence de 60 secondes sans impliquer la fonction de communication DSR C. Les moyens pour y 
parvenir sont internes à la VU, spécifi és par le règlement (UE) no 165/2014, annex e 1 C, section 3.19 
«communication à distance pour les contrô les routiers ciblés» et ne sont pas spécifi és au présent appendice. 26.5.2016 L 139/454 Jour nal officiel de l'Union européenne FR     
4.1.1.2  Données communiquées au dispositif DSR C-VU 
DSC_13  La VU est responsable de l'actualisation des données tach ygraphiques DSR C (les données) dès lors 
qu'elle actualise les données qu'elle stoc ke selon une fréquence définie à la section 4.1.1.1 (DSC_12), 
sans impliquer la fonction de communication DSR C. 
DSC_14  Les données de la VU sont utilisées comme base d'alimentation et d'actualisation des données. Les 
moyens pour y parvenir sont précisés dans l'annex e 1C, section 3.19 «Communication à distance pour les 
contrô les routiers ciblés». En l'absence de précision, ces moyens dépendent de la concept ion du produit et 
ne sont pas décr its dans le présent appendice. En ce qui concer ne la conception de la connexion entre 
le dispositif DSR C-VU et la VU, consult er la section 5.6. 
4.1.1.3  Conte nu des données 
DSC_15  Le contenu et la structure des données sont tels qu'une fois décr yptés, ils sont structurés et mis à 
disposition selon la forme et la structure spécifiées à la section 5.4.4 du présent appendice (Structures 
de données). 
4.1.1.4  Présentation des données 
DSC_16  Les données, régulièrement actualisées conf ormément aux procédures définies à la section 4.1.1.1, sont 
sécur isées avant d'être présentées à la VU-DSRC, sont présent ées comme une valeur de concep t de 
données sécur isées et enfin stoc kées temporairement dans la VU-DSRC en tant que version actuelle 
des données. Ces données sont transfér ées du VUSM à la fonction DSR C VUPM. Le VUSM et la VUPM 
désignent des fonctions, pas nécessairement des entités physiques. La forme des instanciations 
physiques exécutant ces fonctions est affaire de concep tion de produit, sauf indication dans une autre 
partie du règlement UE no 165/2014. 
4.1.1.5  Données de sécur ité 
DSC 17  Les données de sécur ité (secur ityData), comprenan t les données requises par le REDCR pour décr ypter 
les données, sont communiquées conf ormément à l'appendice 11 Mécanismes communs de sécur ité et 
sont présentées comme une valeur de concep t de données en vue de leur stoc kage temporaire dans la 
DSRC-VU comme étant la version actuelle des secur ityData, selon la structure définie par le présent 
appendice, section 5.4.4. 
4.1.1.6  Données VUPM disponibles pour le transfer t à l'aide de l'inte rface DSR C 
DSC 18  Le concep t de données qui doit touj ours être disponible dans la fonction DSR C VUPM en vue de son 
transfer t immédiat sur demande du REDCR est défini à la section 5.4.4, qui contient les spécifications 
compl ètes du module ASN.1. 
Récapitulatif du prof il de communication no 1 
Ce prof il couvre le cas de figure dans lequel un agent des autori tés de contrôle compé tent es utilise un lecteur de 
communication à distance à des fins de détection précoce à cour te portée (interfa ces DSR C 5,8 GHz 
fonctionnant conf ormément à la recommandation ERC 70-03 et testées selon les paramètres pertinents de la 
norme EN 300 674-1 comme décr it à la section 5) (le REDCR) pour identif ier un véhicule en infraction 
pote ntielle au règlement (UE) no 165/2014. Une fois le véhicule identifié, l'agen t décide si le véhicule doit être 
intercept é. 
4.1.2  Profil 1a: à l'aide d'un lecteur de communication à distance à des fins de détection précoce qui est dirigé manuellement ou 
installé et dirigé tempor airement en bord de route 
Dans ce cas de figure, l'agent des autori tés de contrôle compét entes est placé sur le bord de la voie et utilise un 
REDCR manuel, posé sur un tripode ou sur une structure portable similaire positionné au bord de la voie et 
orienté vers le centre du pare-br ise du véhicule ciblé. L'inte rrogation utilise les interface s DSR C 5,8 GHz 
fonctionnant conf ormément à la recommandation ERC 70-03 et testées selon les paramètres pertinents de la 
norme EN 300 674-1, décr ite à la section 5. Cf. figure 14.1 (cas de figure no 1). 26.5.2016 L 139/455 Jour nal officiel de l'Union européenne FR     
Figure 14.1 
Inter rogation en bord de route avec DSR C 5,8 GHz 
4.1.3  Profil 1b: à l'aide d'un lecteur de communication à distance à des fins de détection précoce (REDCR) qui est installé et 
dirigé dans un véhic ule 
Dans ce cas, l'agen t des autori tés de contrôle compét entes se trouve dans un véhicule en circulation et soit il 
utilise un REDCR manuel et portable depuis le véhicule en le pointant vers le centre du pare-br ise du véhicule 
ciblé, soit le REDCR est installé dans ou sur le véhicule de manière à être dirigé vers le centre du pare-br ise du 
véhicule ciblé lorsque le véhicule à bord duquel se trouve le REDCR est dans une position particulière par 
rappor t au véhicule ciblé (par exem ple directement en amont dans un flux de circulation). L'inte rrogation utilise 
les interfaces DSR C 5,8 GHz fonctionnant conf ormément à la recommandation ERC 70-03 et testées selon les 
paramètres pertinents de la norme EN 300 674-1, décr ite à la section 5. Cf. figure 14.2. (Cas de figure no 2). 
Figure 14.2 
Inter rogation depuis un véhicule avec DSR C 5,8 GHz 
4.2  Sécur ité/Intég rité 
Afin de permettre la vérification de l'authenticit é et de l'intégrité des données télécharg ées à l'aide de la 
communication à distance, ces données sécur isées font l'objet d'une vérification et d'un décr yptag e 
conf ormément à l'appendice 11 Mécanismes communs de sécur ité. 
5  CONCEPTION ET PROTOCOLES DE LA COMMUNIC ATION À DIST ANCE 
5.1  Conception 
La conception de la fonction de communication à distance du tach ygraphe intellig ent est illustrée à la figure 
14.3. 26.5.2016 L 139/456 Jour nal officiel de l'Union européenne FR     
Figure 14.3 
Conception de la fonction de communication à dist ance 
DSC_19  Les fonctions suivante s sont situées dans la VU: 
—  Module de sécur ité (VUSM). Cette fonction présent e dans la VU est responsable de la sécur isation 
des données à transmettre depuis la DSRC-VU à l'agent des autori tés de contrôle compét entes par 
communication à distance. 
—  Les données sécur isées sont enregistrées dans la mémoire VUSM. La section 4.1.1.1 (DSC_12) 
prévoi t la fréquence à laquelle la VU crypte et renouvelle le concept RTMdata (qui inclut les 
valeurs de concep t des données utiles et des données de sécur ité déterminées ci-après au présent 
appendice) détenu dans la mémoire de la DSR C-VU. L'exploitation du module de sécur ité est 
définie à l'appendice 11 Mécanismes communs de sécur ité et est exclue de la portée du présent 
appendice, hormis le fait que tout e modifi cation des données du VUSM doit entraîner la mise à 
jour du dispositif de communication de la VU. 
—  La communication entre la VU et la DSR C-VU peut être filaire ou de type Bluetooth Low Energy 
(BLE). La DSR C-VU peut soit être intégrée physiquement sur le pare-br ise du véhicule avec 
l'ante nne, soit être interne à la VU, soit être située à tout point intermédiaire. 
—  La DSR C-VU dispose d'une source d'alimentation électr ique fiable à tout moment. Les moyens 
d'alimentation relèvent de la décision concep tuelle. 
—  La mémoire de la DSR C-VU est non volatile, afin de préser ver les données dans la DSR C-VU y 
compris lorsque le contact du véhicule est coupé. 
—  Si la communication entre la VU et la DSR C-VU s'établit par BLE et que l'alimentation provient 
d'une batter ie non rechargeable, l'alimentation de la DSR C-VU doit être rem placée lors de chaque 
inspection périodique. En outre, il incombe au fabr icant de la DSR C-VU de vérifier que l'alimen ­
tation électr ique perdure d'une inspection périodique à l'autre. Il doit mainte nir l'accès normal aux 
données au moyen d'un REDCR durant tout e la période sans anomalie ni interr upti on. 26.5.2016 L 139/457 Jour nal officiel de l'Union européenne FR     
—  Dispositif de «mémoire utile» RTM VU (VUPM). Il incombe à cette fonction présent e dans la VU de 
fournir et d'actualiser les données. Le contenu des données («TachographP ayload») est défini aux 
sections 5.4.4/5.4.5 ci-après et mis à jour selon la fréquence précisée à la section 4.1.1.1 
(DSC_12). 
—  DSR C-VU. Il s'agit de la fonction intégrée à l'antenne ou connectée à celle-ci, qui communique 
avec la VU grâce à une connexion filaire ou sans fil (BLE), qui détient les données actuelles (données 
VUPM) et gère la réponse à une interrogation par DSR C 5,8 GHz. Toute déconnexion du dispositif 
DSR C ou interférence avec le fonctionnement de celui-ci pendant l'exploitation normale du 
véhicule constitue une infraction au règlement (UE) no 165/2014. 
—  Le module de sécur ité (REDCR) (SM-REDCR) désigne la fonction servant à décr ypter et à vérifier 
l'intégrité des données provenant de la VU. Les moyens pour y parvenir sont déterminés à 
l'appendice 11 Mécanismes communs de sécur ité. Ils ne sont pas précisés au présent appendice. 
—  La fonction du dispositif DSR C (REDCR) (DSRC-REDCR) inclut un émetteur -récept eur de 5,8 GHz 
ainsi que le progiciel et le logiciel associés qui gèrent la communication avec la DSRC-VU 
conf ormément au présent appendice. 
—  Le DSRC-REDCR interroge la DSRC-VU du véhicule ciblé et obtient les données (les données VUPM 
actuelles du véhicule ciblé) grâce à la liaison et aux procédures DSR C et enregistre les données 
reçues dans son SM-REDCR. 
—  L'ant enne DSR C-VU est placée de manière à optimiser la communication DSR C entre le véhicule et 
l'ante nne en bord de route (en général, au centre ou à proximité du centre du pare-br ise du 
véhicule). Pour les véhicules légers, une installation sur la partie supér ieure du pare-br ise convient. 
—  Aucun objet métallique (ex.: porte-badge, autoco llant, bande (teint ée) anti-ref lets, pare-soleil, 
essuie-g lace au repos) ne doit se trouver à proximité ou devant l'ante nne, car ils pour raient 
interférer avec la communication. 
—  L'antenne est installée de sorte que son axe de visée est à peu près parallèle avec la surface de 
la route. 
DSC_20  L'ant enne et la communication fonctionnent conf ormément à la recommandation ERC 70-03 et sont 
testées selon les paramètres pertinents de la norme EN 300 674-1, comme décr it à la section 5. 
L'ant enne et la communication peuvent mettre en œuvre des techniques d'atté nuation contre le risque 
d'interfé rence sans fil comme décr it au rappor t ECC 228, en utilisant notamment des filtres dans la 
communication CEN DSR C 5,8 GHz. 
DSC_21  L'ant enne DSR C est connectée à la DSR C-VU soit directement au sein du module installé sur ou à 
proximité du pare-br ise, soit à l'aide d'un câble spécialement conçu pour rendre difficile tout e 
déconnexion illégal e. Toute déconnexion de l'antenne ou interf érence avec son fonctionnement 
constitue une infraction au règlement (UE) no 165/2014. Le masquag e délibéré ou tout autre 
agissement qui nuit à la performa nce opérationnelle de l'antenne constitue une infraction au 
règlement (UE) no 165/2014. 
DSC_22  Le format de l'antenne n'est pas défini et demeure une décision commerciale, à condition que la 
DSR C-VU installée satisfasse aux exigenc es de conf ormité définies à la section 5 ci-dessous. L'ant enne 
est positionnée comme défini au point DSC_19 et comme illustré à la figure 14.4 (ligne ovale) et elle 
prend efficacement en charg e les cas d'usage décr its en 4.1.2 et en 4.1.3. 26.5.2016 L 139/458 Jour nal officiel de l'Union européenne FR     
Figure 14.4 
Exemple de positionnement de l'antenne DSR C 5,8 GHz sur le pare-br ise de véhicules réglementés 
Le format du REDCR et de son antenne varie selon les caract éristiques du lecteur (installé sur un tripode, tenu à 
la main, installé dans un véhicule, etc.) et le mode opératoire adop té par l'agent des autori tés de contrôle 
compét entes. 
Une fonction d'aff ichage et/ou de notifi cation sert à présenter les résultats de la fonction de communication à 
distance à l'agent des autori tés de contrôle compét entes. Il est possible de disposer d'un affichage sur écran ou 
sous forme impr imée, d'un signal audio ou d'une combinaison de ces notificati ons. La forme de cet affichag e et/ 
ou de cette notific ation dépend des exigenc es des agents des autori tés de contrôle compét entes et de la 
concep tion de l'équipement. Elle n'est pas spécifiée au présent appendice. 
DSC_23  La concept ion et le format du REDCR dépendent de la conception commerciale dans le cadre de la 
recommandation ERC 70-03 et des spécifi cations de concep tion et de performa nce définies au présent 
appendice (5.3.2). Le marc hé dispose de fait d'une souplesse optimale pour concevoir et fournir les 
équipements nécessaires dans le but de répondre à l'ensemble des cas de figure d'interr ogation propres 
à tout e autor ité de contrôle compét ente. 
DSC_24  La conception et le format de la DSRC-VU et son positionnement à l'inté rieur ou à l'exté rieur de la 
VU varient selon la concept ion commerciale, dans le cadre de la recommandation ERC 70-03, et selon 
les spécifications de conception et de performa nce définies dans cet appendice à la section 5.3.2 et 
dans la présente section (5.1). 
DSC_25  Cependant, la DSRC-VU doit raisonnablement être en mesure d'accept er les valeurs de concep t de 
données provenant d'autres équipements de véhicule intelligent (tel qu'un équipement de pesage 
embarqué) et transmises au moyen d'une connexion et de prot ocoles ouver ts et normalisés, pour vu 
que de tels concepts de données soient identifiés par des identif icateurs/noms de dossiers d'application 
connus et uniques et à condition que les instr uctions d'exploitation desdits protocoles soient mises à 
la disposition de la Commission européenne et disponibles sans frais pour les fabricants des 
équipements pertinents. 
5.2  Déroulement des opérations 
5.2.1  Opér ations 
Le déroulement des opérations est illustré sur la figure 14.5. 26.5.2016 L 139/459 Jour nal officiel de l'Union européenne FR     
Figure 14.5 
Déroulement des opérations de la fonction de communication à distance 
Les étapes sont décr ites ci-après: 
a.  Dès lors que le véhicule est en marche (mis sous contact), le tach ygraphe fournit des données à la fonction 
VU. La fonction VU prépare les données pour la fonction de communication à distance (cryptée) et actualise 
la VUPM mémor isée dans la DSRC-VU (comme défini aux sections 4.1.1.1 – 4.1.1.2). Les données collect ées 
sont formaté es comme défini aux sections 5.4.4 – 5.4.5 ci-dessous. 26.5.2016 L 139/460 Jour nal officiel de l'Union européenne FR     
b.  À chaque fois que les données sont actualisées, le timbre horodateur défini dans le concep t de données de 
sécur ité doit être actualisé. 
c.  La fonction VUSM protège les données conf ormément aux procédures déterminées à l'appendice 11. 
d.  À chaque mise à jour des données (cf. sections 4.1.1.1 – 4.1.1.2), les données sont transfé rées à la DSRC-VU 
où elles remplacent tout es les données antérieures afin que les données actualisées (les données) demeurent 
touj ours disponibles en cas d'interr ogat ion par un REDCR. Lorsqu'elles sont fournies par la VU à la DSRC-VU , 
les données sont identifiables par le nom de fichier RTMData ou par l'identific ateur d'application et les identifi cateurs 
d'attr ibut. 
e.  Si un agent des autori tés de contrôle compét entes souhaite cibler un véhicule et recueillir les données émanant 
du véhicule ciblé, l'agent des autorités de contrôle compét entes insère d'abord sa carte intellig ente dans le 
REDCR pour établir la communication et permettre au SM-REDCR de vérifier son authenticité et de décr ypter 
les données. 
f.  L'ag ent des autori tés de contrôle compét entes vise ensuite un véhicule et procède à la demande de données 
par l'intermédiaire de la communication à distance. Le REDCR ouvre une session d'interf ace DSR C 5,8 GHz 
avec la DSRC-VU du véhicule ciblé et procède à la demande des données. Les données sont transférées vers le 
REDCR grâce au système de communication sans fil en tant qu'attr ibut DSR C utilisant le service d'application 
GET , comme défini à la section 5.4. L'attr ibut contient les valeurs de données utiles chiffrées et les données 
relatives à la sécur ité DSR C. 
g.  Le REDCR procède à l'analyse des données qui sont ensuite communiquées à l'agent des autor ités de 
contrôle compét entes. 
h.  L'ag ent des autori tés de contrôle compé tent es utilise les données pour prendre la décision d'arrêter ou non le 
véhicule en vue d'une inspection plus détaillée ou pour demander à un autre agent des autorités de contrôle 
compét entes d'inte rcept er le véhicule. 
5.2.2  Inter prétation des données reçues au moyen de la communication DSRC 
DSC_26  Les données reçues via l'interface 5,8 GHz incluent la signif ication et le format définis aux sections 
5.4.4 et 5.4.5 ci-dessous et uniquement ceux-là et doivent être interpr étés au regard des objectifs qui y 
sont définis. Conf ormément aux dispositions du règlement (UE) no 165/2014, les données servent 
uniquement à fournir les informations pertinentes à une autori té de contrôle compét ente pour l'aider 
à déterminer quel véhicule inter cept er pour un contrôle physique et sont détr uites par la suite 
conf ormément à l'article 9 du règlement (UE) no 165/2014. 
5.3  Paramètres de l'inter face DSR C physique pour la communication à distance 
5.3.1  Contr aintes d'emplacement 
DSC_27  L'inter rogation à distance de véhicules avec l'interface DSR C 5,8 GHz ne doit pas se faire dans un 
rayon de 200 mètres autour d'un portique DSR C 5,8 GHz opérationnel. 
5.3.2  Paramètr es de liaisons descendante et montante 
DSC_28  L'équipement servant au contrôle du tach ygraphe à distance doit être conf orme à la recommandation 
ERC 70-03 et fonctionner selon celle-ci. Il doit également satisf aire aux paramètres définis aux 
tableaux 14.1 et 14.2 ci-dessous. 26.5.2016 L 139/461 Jour nal officiel de l'Union européenne FR     
DSC_29  Par ailleurs, pour garan tir la compatibilit é avec les paramètres opérationnels d'autres systèmes DSR C 
5,8 GHz normalisés, l'équipement utilisé pour le contrôle du tach ygraphe à distance doit être 
conf orme aux paramètres des normes EN 12253 et EN 13372. 
À savoir: 
Tableau 14.1 
Paramètres de liaison descendante 
Point Param ètre Valeur(s) Remarque 
D1 Fréquences porteuses 
descendantes Le REDCR dispose de quatre possibili ­
tés: 
5,7975 GHz 
5,8025 GHz 
5,8075 GHz 
5,8125 GHz Dans les limites de ERC 70-03. 
Les fréquences porteus es peuvent être 
sélectionnées par le responsable de la 
mise en œuvre du système de contrôle 
routier , et ne doivent pas être connues 
au niveau de la DSR C-VU 
(conf orme à EN 12253, EN 13372) 
D1a (*) Tolérance de fréquence 
des porteuses ± 5 ppm (conf orme à EN 12253) 
D2 (*) Masque spectral d'émis ­
sion de la RSU (REDCR) Dans les limite s de ERC 70-03. 
Le REDCR doit correspondre à la 
classe B,C telle que définie dans la 
norme EN 12253. 
Pas d'autre exigenc e spécifi que dans la 
présent e annex e Paramètre utilisé pour maîtr iser les in­
terfé rences entre interr ogat eurs à proxi­
mité (comme défini dans les normes EN 
12253 et EN 13372). 
D3 Gamme de fréquences 
minimale OBU(DSR C- 
VU) 5,795 — 5,815 GHz (conf orme à EN 12253) 
D4 (*) P.I.R.E. maximale Dans les limites de ERC 70-03 (sans 
autorisations) et de la réglementation 
nationale 
Maximum + 33 dBm (conf orme à EN 12253) 
D4a Masque angulaire p.i.r .e. Conf ormément à la spécific ation décla ­
rée et publiée du concept eur de l'inter­
rogateur (conf orme à EN 12253) 
D5 Polar isation Circulaire anti-horaire (conf orme à EN 12253) 
D5a Polar isation croisée XPD: 
Dans l'axe de visée: (REDCR) RSU t ≥ 
15 dB 
(DSR C-VU) OBU r ≥ 10 dB 
Dans la zone – 3 dB: (REDCR) RSU t ≥ 
10 dB 
(DSR C-VU) OBU r ≥ 6 dB (conf orme à EN 12253) 
D6 (*) Modulation Modulation d'ampli tude à deux ni­
veaux (conf orme à EN 12253) 
D6a (*) Indice de modulation 0,5 … 0,9 (conf orme à EN 12253) 26.5.2016 L 139/462 Jour nal officiel de l'Union européenne FR     
Point Param ètre Valeur(s) Remarque 
D6b Diagramme de l'œil ≥ 90 % (temps)/≥ 85 % (amplitude)  
D7 (*) Codage de données FM0 
Le bit ‘1’ ne présent e de transitions 
qu'au début et à la fin de l'inte rvalle du 
bit. Le bit ‘0’ présent e une transition 
supplémentaire au milieu de l'inter valle 
du bit par rappor t au bit ‘1’. (conf orme à EN 12253) 
D8 (*) Débit binaire 500 kBit/s (conf orme à EN 12253) 
D8a Tolérance de l'horloge 
bit mieux que ± 100 ppm (conf orme à EN 12253) 
D9 (*) Taux d'erreur binaire (B. 
E.R.) pour la communi ­
cation ≤ 10 – 6 si la puissance incident e à 
l'OBU (DSR C-VU) se situe dans la plage 
donnée par [D11a à D11b]. (conf orme à EN 12253) 
D10 Signal déclenchant le ré­
veil de l'OBU (DSR C- 
VU) L'OBU (DSR C-VU) est réveillé à la ré­
cept ion d'une trame compor tant 11 
octets ou plus (préambule compr is) Aucune structure particulière n'est né­
cessaire pour le signal de réveil. 
La DSR C-VU peut s'éveiller à la récep ­
tion d'une trame compo rtant moins de 
11 octets 
(conf orme à EN 12253) 
D10a Temps de démar rage 
maximal ≤ 5 ms (conf orme à EN 12253) 
D11 Zone de communica ­
tion Région spatiale dans laquelle un B.E.R. 
conf orme à D9a est atteint (conf orme à EN 12253) 
D11a (*) Limit e de puissance (su­
périeure) pour la 
communication. – 24dBm (conf orme à EN 12253) 
D11b (*) Limit e de puissance (in­
férieure) pour la 
communication. Puissance incident e: 
– 43 dBm (axe de visée) 
– 41 dBm (dans la plage – 45° — + 
45° Correspondant au plan parallèle à 
la surface de la route, lorsque la DSR C- 
VU est installée ultéri eurement dans le 
véhicule (Azimuth)) (conf orme à EN 12253) 
Exigen ce supér ieure pour des angles ho­
rizontaux jusqu'à ±45°, comp te tenu des 
cas de figure définis dans la présente an­
nexe . 
D12 (*) Niveau de puissance de 
coupure de (DSR C-VU) – 60 dBm (conf orme à EN 12253) 
D13 Préambule Préambule obligat oire. (conf orme à EN 12253) 
D13a Longueur et structure 
du préambule 16 bits — 1 bit ‘1’ codé en FM0 (conf orme à EN 12253) 26.5.2016 L 139/463 Jour nal officiel de l'Union européenne FR     
Point Param ètre Valeur(s) Remarque 
D13b Forme d'onde du pré­
ambule Séquence alternant les niveaux faible et 
élevé, avec une durée d'im pulsion de 
2 µs. 
La tolérance est donnée par D8a (conf orme à EN 12253) 
D13c Bits non significatifs La RSU (REDCR) peut émettre au 
maximum 8 bits après le drapeau de 
fin. Un OBU (DSR C-VU) n'est pas tenu 
de tenir comp te de ces bits supplémen ­
taires. (conf orme à EN 12253) 
(*)  – Paramètres de liaison descendante soumis à des essais de conf ormité selon l'essai de paramétrag e pertinent prévu par la norme EN 
300 674-1  
Tableau 14.2 
Paramètres de liaison mont ante 
Point Param ètre Valeur(s) Remarque 
U1 (*) Fréquences sous-por te­
uses Un OBU (DSR C-VU) prend en charge 
les fréquences 1,5 MHz et 2,0 MHz 
Une RSU (REDCR) prend en charge les 
fréquences 1,5 MHz ou 2,0 MHz ou 
les deux. U1-0: 1,5 MHz U1-1: 
2,0 MHz La sélection de la fréquence sous-por te­
use 
(1,5 MHz ou 2,0 MHz) dépend du profil 
EN 13372 choisi. 
U1a (*) Tolérance de fréquence 
des sous-por teuses ± 0,1 % (conf orme à EN 12253) 
U1b Utilisation de bandes la­
térales Mêmes données des deux côtés (conf orme à EN 12253) 
U2 (*) Masque spectral d'émis ­
sion de l'OBU (DSR C- 
VU) conf ormément à EN12253 
1)  Puissance hors bande: 
voir ETSI EN 300674-1 
2)  Puissance dans la bande: 
[U4a] dBm à 500 kHz 
3)  Émission dans tout e autre voie 
montante : 
U2(3)-1 = – 35 dBm à 500 kHz (conf orme à EN 12253) 
U4a (*) P.I.R.E. maximale — 
bande latérale unique 
(axe de visée) Deux options: 
U4a-0: – 14 dBm 
U4a-1: – 21 dBm Conf ormément à la spécification décla ­
rée et publiée du concep teur de l'équipe ­
ment 
U4b (*) P.I.R.E. maximale — 
bande latérale unique 
(35°) Deux options: 
—  Non applicable 
—  – 17dBm Conf ormément à la spécification décla ­
rée et publiée du concep teur de l'équipe ­
ment 
U5 Polar isation Circulaire anti-horaire (conf orme à EN 12253) 26.5.2016 L 139/464 Jour nal officiel de l'Union européenne FR     
Point Param ètre Valeur(s) Remarque 
U5a Polar isation croisée XPD: 
Dans l'axe de visée: (REDCR) RSU r ≥ 
15 dB 
(DSR C-VU) OBU t ≥ 10 dB 
À – 3 dB: (REDCR) RSU r ≥ 10 dB 
(DSR C-VU) OBU t ≥ 6 dB (conf orme à EN 12253) 
U6 Modulation de sous- 
porteuse 2-PSK 
Données codées synchr onisées avec la 
sous-por teuse: les transitions des don ­
nées codées coïncident avec les transi ­
tions de la sous-por teuse . (conf orme à EN 12253) 
U6b Cycle de fonctionne ­
ment Cycle de fonctionnement : 
50 % ± α, α ≤ 5 % (conf orme à EN 12253) 
U6c Modulation sur porte­
use Multiplication de sous-por teuse modu ­
lée par la porteuse . (conf orme à EN 12253) 
U7 (*) Codage de données NRZI (pas de transition au début du 
bit ‘1’, transition au début du bit ‘0’, 
pas de transition à l'intérieur du bit) (conf orme à EN 12253) 
U8 (*) Débit binaire 250 kbit/s (conf orme à EN 12253) 
U8a Tolérance de l'horloge 
bit ± 1 000 ppm (conf orme à EN 12253) 
U9 Taux d'erreur binaire (B. 
E.R.) pour la communi ­
cation ≤ 10 – 6 (conf orme à EN 12253) 
U11 Zone de communica ­
tion La région spatiale dans laquelle se situe 
la DSR C-VU, telle que ses émissions 
soient reçues par le REDCR avec un B. 
E.R. inférieur à celui indiqué par U9a. (conf orme à EN 12253) 
U12a (*) Gain de conversion (li­
mite inférie ure) 1 dB pour chaque bande latér ale 
Plag e angulaire: circulairement symé ­
trique entre l'axe de visée et ± 35°  
et dans la plage – 45° — + 45° Corres­
pondant au plan parallèle à la surface 
de la route , lorsque la DSR C-VU est in­
stallée ultéri eurement dans le véhicule 
(Azimuth) Supér ieur à la plage de valeurs spécifiée 
pour des angles horizontaux jusqu'à ± 
45°, comp te tenu des cas de figure défi­
nis dans la présent e annexe . 
U12b (*) Gain de conversion (li­
mite supér ieure) 10 dB pour chaque bande latér ale Moins que la plag e de valeurs spécifi ée 
pour chaque bande latérale à l'intérieur 
d'un cône circulaire autour de l'axe de 
visée, de ± 45° d'ang le d'ouver ture 
U13 Préambule Préambule obligat oire. (conf orme à EN 12253) 26.5.2016 L 139/465 Jour nal officiel de l'Union européenne FR     
Point Param ètre Valeur(s) Remarque 
U13a Préambule 
Longueur et structure 32 à 36 µs, modulé par sous-por teuse 
uniquement, puis 8 bits ‘0’ en codag e 
NRZI. (conf orme à EN 12253) 
U13b Bits non significatifs La DSR C-VU peut émettre au maxi ­
mum 8 bits après le drapeau de fin. 
Un RSU (REDCR) n'est pas tenu de te­
nir comp te de ces bits supplémentai ­
res. (conf orme à EN 12253) 
(*)  – Paramètres de liaison montante soumis à essai de conf ormité selon l'essai de paramétrage pertinent prévu par la norme EN 
300 674-1  
5.3.3  Conception de l'antenne 
5.3.3.1  Ante nne REDCR 
DSC_30  La concep tion de l'antenne REDCR dépend de la conception commerciale, dans les limites définies à la 
section 5.3.2, et adapt ée pour optimiser la performance de lecture du DSRC-REDCR aux fins 
spécifi ques et pour les circonstances de lecture pour lesquelles le REDCR a été conçu pour 
fonctionner . 
5.3.3.2  Ante nne VU 
DSC_31  La concept ion de l'antenne DSRC-VU dépend de la concep tion commerciale, dans les limites définie s à 
la section 5.3.2, et adapt ée pour optimiser la performa nce de lecture du DSRC-REDCR aux fins 
spécifi ques et pour les circonstances de lecture pour lesquelles le REDCR a été conçu pour 
fonctionner . 
DSC_32  L'ant enne VU est fixée sur le pare-br ise du véhicule ou à proximité de celui-ci, comme spécifi é à la 
section 5.1 ci-dessus. 
DSC_33  Dans l'environnement d'essai en atelier (cf. section 6.3), une antenne DSR C-VU, installée selon la 
section 5.1, doit pouv oir se connecter à l'aide d'une communication d'essai standard et effectuer la 
transaction RTM telle que définie au présent appendice, à une distance située entre 2 et 10 mètres, 
plus de 99 % du temps en moyenne, sur plus de 1 000 interr ogat ions en lecture. 
5.4  Exigences du protocole DSR C pour RTM 
5.4.1  Vue d'ensemble 
DSC_34  Le protocole de transaction pour télécharg er les données au moyen de la liaison d'interface DSR C 
5,8 GHz respecte les étapes suivante s. La présent e section décr it un flux de transaction dans les 
conditions idéales sans retransmission ou interrupti on de la communication. 
NOTE: l'objectif de l'étape d'initialisation (Étape 1) est d'établir la communication entre le REDCR et 
les DSR C-VU présent es dans la zone de transaction (maître-esclave) DSR C à 5,8 GHz, mais qui n'ont 
pas encore établi de communication avec le REDCR, puis d'en aver tir les processus d'application.  
— Étape 1Initialisation. Le REDCR envoie une trame cont enant une «table de service de balise» 
(BST) qui inclut les identif icateurs d'application (AID) dans la liste de services pris en charge. Dans 
l'application RTM, elle correspond simplement au service de valeur AID = 2 (Freight&Fleet). La 
DSRC-VU évalue la BST reçue et répond (cf. ci-dessous) avec la liste des applications prises en 
charge dans le domaine Freight&Fleet ou ne répond pas si aucune n'est prise en charge. Si le 
REDCR ne propose pas AID = 2, la DSR C-VU ne répond pas au REDCR. 26.5.2016 L 139/466 Jour nal officiel de l'Union européenne FR     
— Étape 2La DSRC-VU envoie une trame contenant une demande pour une allocation de fenêtre 
privée.  
— Étape 3Le REDCR envoie une trame cont enant une allocation de fenêtre privée.  
— Étape 4La DSRC-VU utilise cette fenêtre privée allouée pour envoyer une trame cont enant sa 
table de service de véhicule (VST). Cette VST comprend la liste de tout es les instanciations d'appli ­
cations différ entes prises en charge par cette DSRC-VU dans le cadre d'une valeur AID = 2. Les 
diffé rentes instanciations sont identif iées au moyen d'EID générés de manière excl usive. Chacun est 
associé à une valeur de paramètres «marque de conte xte d'application» indiquant la norme et 
l'application prises en charge.  
— Étape 5Ensuite le REDCR analyse la VST proposée et décide soit de mettre fin à la connexion 
(RELEASE) car rien ne l'intéresse dans l'offre de la VST (c'est-à-dire qu'il reçoit une VST d'une 
DSRC-VU qui ne prend pas en charge la transaction RTM), soit de lancer une instanciation d'appli ­
cation, s'il reçoit une VST appropr iée.  
— Étape 6À cette fin, le REDCR envoie une trame cont enant une commande pour extraire les 
données RTM en identif iant l'instanciation de l'application RTM par la spécif ication de son identif i­
cate ur (tel qu'indiqué par la DSR C-VU dans la VST) avant d'allouer une fenêtre privée.  
— Étape 7La DSRC-VU utilise la fenêtre privée qui vient d'être allouée pour envoyer une trame qui 
contient l'identifi cateur adressé correspondant à l'instanciation de l'application RTM tel que fourni 
dans la VST , suivi de l'attr ibut RtmData (élément de données utiles + élément de sécur ité).  
— Étape 8Si plusieurs services sont requis, la valeur ‘n’ est remplacée par le numéro de référence du 
service suivant et la procédure se répète.  
— Étape 9Le REDCR confir me la récep tion des données en envoyant une trame contenant une 
commande RELEASE à la DSRC-VU pour mettre fin à la session OU en cas d'échec de la 
validation d'un accusé de récep tion du LDPU, elle revient à l'étape 6. 
Cf. figure 14.6 pour une illustration du protocole de transaction.  26.5.2016 L 139/467 Jour nal officiel de l'Union européenne FR     
Figure 14.6 
Déroulement d'une procédure RTM via DSR C à 5,8 GHz 
26.5.2016 L 139/468 Jour nal officiel de l'Union européenne FR     
5.4.2  Commandes 
DSC_35  Les commandes suivantes sont les seules fonctions utilisées dans une phase de transaction RTM  
— INITIALIS ATION .reques t:commande émanant du REDCR sous la forme d'une diffusion avec la 
définition des applications prises en charge par le REDCR.  
— INITIALIS ATION .response: réponse émanant de la DSR C-VU confir mant la connexion et 
cont enant la liste des instances d'application prises en charg e, avec les caracté ristiques et les 
informations relatives à la façon de les adresser (EID).  
— GET .reques t:commande émanant du REDCR et envoyée à la DSRC-VU spécifi ant l'instanciation 
de l'application à adresser au moyen d'un EID défini, tel que reçu dans la VST, donnant 
instr uctions à la DSRC-VU d'en voyer l'attr ibut ou les attributs sélectionnés avec les données. 
L'objectif de la commande GET est que le REDCR obtienne les données de la DSRC-VU.  
— GET .response: réponse de la DSRC-VU contenant les données demandées.  
— ACTION .reques t ECH O:commande donnant instr uction à la DSRC-VU de renv oyer les données 
de la DSRC-VU au REDCR. L'objectif de la commande ECHO est de permettre aux ateliers ou aux 
infrastr uctures d'essai d'homologat ion de vérifier que la liaison DSR C fonctionne sans devoi r 
accéder aux éléments d'authentifi cation de sécur ité.  
— ACTION.response ECH O:réponse de la DSR C-VU à la commande ECH O.  
— EVENT_REPORT .reques t RELEASE: commande informant la DSRC-VUque la transaction est 
terminée. L'objectif de la commande RELEASE est de mettre fin à la session avec la DSRC-VU. Dès 
récep tion de RELEASE, la DSRC-VU ne répond plus à aucune interr ogation dans le cadre de la 
connexion en cours. Remarque: la norme EN 12834 prévoi t qu'une DSR C-VU ne se connecte pas 
deux fois au même interrogateur sauf si elle a quitté la zone de communication pendant 255 
secondes ou si l'ID de balise de l'inte rrogateur a changé. 
5.4.3  Séquence de commande d'inter rogation 
DSC_36  Du point de vue de la séquence commande-réponse, la transaction se décr it comme suit: 
Séquence Émetteur  Récept eur Descr iption Action 
1 REDCR > DSR C-VU Initialisation de la liaison de 
communication — Demande Le REDCR diffuse la BST 
2 DSRC-VU > REDCR Initialisation de la liaison de 
communication — Réponse Si la BST prend en charge AID=2 
alors la DSRC-VU demande l'allo ­
cation d'une fenêtre privée 
3 REDCR > DSR C-VU Alloue une fenêtre privée Envoie une trame conte nant une 
allocation de fenêtre privée 
4 DSRC-VU > REDCR Envo ie une VST Envo ie une trame contenant une 
VST 
5 REDCR > DSR C-VU Envoie GET .request concer nant 
les données figur ant dans l'at­
tribut pour l'EID spécif ique  
6 DSRC-VU > REDCR Envo ie GET .response avec l'attr ibut 
demandé pour l'EID spécifiqu e Envo ie l'attr ibut (RTMData, OWS­
Data….) avec les données pour 
l'EID spécifiqu e 26.5.2016 L 139/469 Jour nal officiel de l'Union européenne FR     
Séquence Émetteur  Récept eur Descr iption Action 
7 REDCR > DSR C-VU Envoie GET .request concer nant 
les données d'un autre attribut 
(si nécessaire)  
8 DSRC-VU > REDCR Envo ie GET .response avec l'attr ibut 
demandé Envo ie l'attr ibut avec les données 
pour l'EID spécifiqu e 
9 REDCR > DSR C-VU Accuse réception des données Envoie la commande RELEASE 
qui met fin à la transaction 
10 DSRC-VU   Met fin à la transaction   
Un exem ple de la séquence de transaction et du conte nu des trames échang ées figure aux sections 
5.4.7 et 5.4.8. 
5.4.4  Structures de données 
DSC_37  La structure sémantique des données ayant emprun té l'interface DSR C 5,8 GHz doit être cohérent e avec 
la descr iption faite au présent appendice. La présent e section spécifi e la manière dont ces données 
sont structurées. 
DSC_38  Les données utiles (données RTM) correspondent à la concat énation des:  
1. données Encr yptedTachog raphPa yload, qui résult ent du cryptage de TachographP ayload tel que 
défini dans ASN.1 à la section 5.4.5. La méthode de cryptage fait l'objet d'une descr iption à 
l'appendice 11.  
2. DSR CSecur ityData, qui font l'objet d'une descr iption à l'appendice 11. 
DSC_39  Les données RTM sont adressées comme Attribut RTM = 1 et transfér ées dans le conteneur RTM 
= 10. 
DSC_40  La marque de cont exte RTM doit identif ier la partie normalisée prise en charge dans la série de 
normes TARV (RTM correspond à la partie 9); 
Le module ASN.1 concer nant les données DSR C dans l'application RTM est défini comme suit:  26.5.2016 L 139/470 Jour nal officiel de l'Union européenne FR     
26.5.2016 L 139/471 Jour nal officiel de l'Union européenne FR     
5.4.5  Éléments de RtmData, actions effectu ées et définitions 
DSC_41  Les valeurs de données à calculer par la VU et utilisées pour actualiser les données sécur isées dans la 
DSR C-VU sont calculées selon les règles prévues au tableau 14.3: 
Tableau 14.3 
Éléments de RtmDat a, actions effectuées et définitions 
(1) Élément de 
données RTM (2) Action effectuée par la VU  (3) Défini tion des données 
ASN.1 
RTM1 
Plaque d'im ­
matr iculation 
du véhicule La VU définit la valeur de l'élément de données RTM1 
tp15638V ehicleR egistr ationPlate provenant de la valeur enregis ­
trée du type de données VehicleR egistr ationIdentifi cation tel que 
défini à l'appendice 1 VehicleR egistr ationIdentifi cation Plaque d'immatr i­
culation du véhi ­
cule expr imée 
par une chaîne 
de caractères 
26.5.2016 L 139/472 Jour nal officiel de l'Union européenne FR     
(1) Élément de 
données RTM (2) Action effectuée par la VU  (3) Défini tion des données 
ASN.1 
RTM2 
Événement 
«Exc ès de vi­
tesse» La VU génère une valeur booléenne pour l'élément de données 
RTM2 tp15638SpeedingEvent. 
La valeur tp15638SpeedingEvent est calculée par la VU d'après 
le nombre d'événements «excès de vitesse» (tel que défini à l'an­
nexe 1C) enregistrés dans la VU au cours des 10 derniers jours 
d'occur rence. 
S'il existe au moins un tp15638SpeedingEvent dans les 10 der­
niers jours d'occur rence, tp15638SpeedingEvent prend la va­
leur TRUE (vrai). 
AUTREMENT , si aucun événement n'est survenu au cours des 
10 derniers jours d'occur rence, tp15638SpeedingEvent prend 
la valeur FALSE (faux). 1 (TRUE) — In­
dique des irrégu ­
larités de vites se 
au cours des 10 
derniers jours 
d'occur rence 
RTM3 
Conduite sans 
carte valide La VU génère une valeur booléenne pour l'élément de données 
RTM3 tp15638Dr ivingWithoutV alidCard. 
La VU attribue la valeur TRUE à la variable tp15638Dr iving ­
WithoutV alidCard si les données de la VU ont enregistré au 
moins un événement de type «Conduit e sans carte valable» (tel 
que défini à l'annex e 1C) au cours des 10 derniers jours d'oc ­
currence. 
AUTREMENT , si aucun événement n'est survenu au cours des 
10 derniers jours d'occur rence, la variable tp15638Dr ivingWi ­
thoutV alidCard prend la valeur FALSE. 1 (TRUE) = In­
dique l'utilisation 
d'une carte inva ­
lide 
RTM4 
Car te de 
conducteur 
valide La VU génère une valeur booléenne pour l'élément de données 
RTM4 
tp15638Dr iverCard basée sur les données enregistrées dans la 
VU et conf ormément à l'appendice 1. 
Si aucune carte de conducteur valide n'est présent e, la VU attri­
bue la valeur TRUE à la variable. 
AUTREMENT , si une carte de conducteur valide est présent e, la 
VU attribue la valeur FALSE à la variable. 0 (FALSE) = In­
dique une carte 
de conduct eur 
valide 
RTM5 
Inser tion 
d'une carte 
pendant la 
conduite La VU génère une valeur booléenne pour l'élément de données 
RTM5. 
La VU attribue la valeur TRUE à la variable tp15638CardInser ­
tion si les données de la VU ont enregistré au moins un événe ­
ment de type «Inser tion d'une carte pendant la conduite» (tel 
que défini à l'annex e 1C) au cours des 10 derniers jours d'oc ­
currence. 
AUTREMENT si aucun événement de ce type n'est survenu au 
cours des 10 derniers jours d'occur rence, la variable 
tp15638CardInser tion prend la valeur FALSE. 1 (TRUE) = Indique 
l'inser tion d'une 
carte pendant la 
conduite au cours 
des 10 derniers 
jours d'occur ­
rence 
RTM6 
Erreur de 
données de 
mouv ement La VU génère une valeur booléenne pour l'élément de données 
RTM6. 
La VU attribue la valeur TRUE à la variable tp15638MotionDa ­
taEr ror si les données de la VU ont enregistré au moins un évé­
nement de type «erreur de données de mouvement» (tel que dé­
fini à l'annex e 1C) au cours des 10 derniers jours d'occur rence. 
AUTREMENT , si aucun événement de ce type n'est survenu au 
cours des 10 derniers jours d'occur rence, la variable 
tp15638MotionDataEr ror prend la valeur FALSE. 1 (TRUE) = In­
dique une erreur 
de données de 
mouvement au 
cours des 10 der­
niers jours d'oc ­
currence 
26.5.2016 L 139/473 Jour nal officiel de l'Union européenne FR     
(1) Élément de 
données RTM (2) Action effectuée par la VU  (3) Défini tion des données 
ASN.1 
RTM7 
Conf lit 
concer nant le 
mouv ement 
du véhicule La VU génère une valeur booléenne pour l'élément de données 
RTM7. 
La VU assigne la valeur TRUE à la variable tp15638vehicleMo ­
tionConf lict si les données de la VU ont enregistré au moins 
un événement de type «conf lit concer nant le mouvement du 
véhicule» (valeur ‘0A’H) au cours des 10 derniers jours d'occur ­
rence. 
AUTREMENT , si aucun événement de ce type n'est survenu au 
cours des 10 derniers jours d'occur rence, la variable 
tp15638vehicleMotionConf lict prend la valeur FALSE. 1 (TRUE) = In­
dique un conf lit 
concer nant le 
mouvement du 
véhicule au cours 
des 10 derniers 
jours d'occur ­
rence 
RTM8 
Deuxième 
carte de 
conducteur La VU génère une valeur booléenne pour l'élément de données 
RTM8 sur la base de l'annex e 1C («Données relatives à l'activité 
du conduct eur» ÉQUIP AGE et CONV OYEUR). 
Si une deuxième carte de conduct eur valide est présente, la VU 
attribue la valeur TRUE à la variable. 
AUTREMENT , en l'absence d'une deuxième carte de conducteur 
valide, la VU attribue la valeur FALSE à la variable. 1 (TRUE) = In­
dique qu'une deu­
xième carte de 
conduct eur a été 
insérée 
RTM9 
Activité en 
cours La VU génère une valeur booléenne pour l'élément de données 
RTM9. 
Si l'activité en cours est enregistrée dans la VU en tant qu'acti ­
vité autre que «CONDUI TE» (telle que définie à l'annex e 1C), la 
VU attribue la valeur TRUE à la variable. 
AUTREMENT , si l'activit é en cours est enregistrée dans la VU 
comme «CONDUITE», la VU attribue la valeur FALSE à la va­
riable. 1 (TRUE) = autre 
activité sélection ­
née; 
0 (FALSE) = 
conduite sélec ­
tionnée 
RTM10 
Clôture de la 
dernière ses­
sion La VU génère une valeur booléenne pour l'élément de données 
RTM10. 
Si la dernière session d'une carte n'a pas été clôturée correcte ­
ment comme le prévoit l'annex e 1C, la VU attribue la valeur 
TRUE à la variable. 
AUTREMENT , si la dernière session d'une carte a été correcte ­
ment clôturée, la VU attribue la valeur FALSE à la variable. 1 (TRUE) = la 
clôture de session 
a échoué 
0 (FALSE) = la 
clôture de session 
a abouti 
RTM11 
Coupure de 
l'alimentation 
électr ique La VU génère une valeur expr imée par un nombre entier pour 
l'élément de données RTM11. 
La VU affecte une valeur à la variable tp15638P owerSupplyIn ­
terruption égale à la coupure d'électr icité la plus longue 
(conf ormément aux dispositions de l'article 9 du règlement 
(UE) no 165/2014), de type «inter rupti on de l'alimentation élec­
trique» (tel que défini à l'annexe 1C). 
AUTREMENT , si aucun événement de type «inter rupti on de 
l'alimentation électr ique» n'est survenu au cours des 10 der­
niers jours d'occur rence, la variable du nombre entier est 0. —  Nombre de 
coupures de 
l'alimentation 
électr ique au 
cours des 10 
derniers jours 
d'occur rence 
26.5.2016 L 139/474 Jour nal officiel de l'Union européenne FR     
(1) Élément de 
données RTM (2) Action effectuée par la VU  (3) Défini tion des données 
ASN.1 
RTM12 
Anomalie du 
capteur La VU génère une valeur indiquée par un nombre entier pour 
l'élément de données RTM12. 
La VU attribue à la variable sensorFault une valeur de: 
—  1 si un événement de type anomalie de capt eur ‘35’H a été 
enregistré au cours des 10 derniers jours, 
—  2 si un événement de type anomalie du récep teur GNSS 
(interne ou externe, avec les valeurs enum ‘51’H ou ‘52’H) 
a été enregistré au cours des 10 derniers jours. 
—  3 si un événement de type anomalie de communication du 
dispositif GNSS exte rne ‘53’H a été enregistré au cours des 
10 derniers jours d'occur rence. 
—  4 si des anomalies de capt eur et des anomalies de récept eur 
GNSS ont été enregistrées au cours des 10 derniers jours 
d'occur rence 
—5 si des anomalies de capt eur et des anomalies de commu ­
nication du dispositif GNSS externe ont été enregistrées au 
cours des 10 derniers jours d'occur rence 
—  6 si des anomalies de récep teur GNSS et des anomalies de 
communication du dispositif GNSS externe ont été enregis ­
trées au cours des 10 derniers jours d'occur rence 
—  7 si des anomalies des trois types ont été enregistrées au 
cours des 10 derniers jours d'occur rence. 
AUTREMENT , une valeur de 0 est attribuée si aucun événe ­
ment n'a été enregistré au cours des 10 derniers jours d'occur ­
rence. —erreur de cap­
teur un octet 
conf ormé­
ment au dic­
tionnaire des 
données 
RTM13 
Remise à 
l'heure La VU génère une valeur indiquée par un nombre entier (time ­
Real de l'appendice 1) pour l'élément de données RTM13, en 
fonction de la présence de la présence de données concer nant 
la remise à l'heure (telles que définies à l'annexe 1C). 
La VU doit attribuer la valeur horaire correspondant au dernier 
événement de remise à l'heure. 
AUTREMENT , si aucun événement «remise à l'heure» (tel que 
défini à l'annex e 1C) n'est présent dans la VU, la valeur attri­
buée est 0. Heure de la der­
nière remise à 
l'heure 
RTM14 
Tentative d'in ­
fraction à la 
sécur ité La VU génère une valeur indiquée par un nombre entier (time ­
Real de l'appendice 1) pour l'élément de données RTM14, en 
fonction de la présence d'une tentative d'infraction à la sécur ité 
(telle que définie à l'annex e 1C). 
La VU doit attribuer la valeur horaire correspondant au dernier 
événement de tentative d'infraction à la sécur ité enregistrée par 
la VU. 
AUTREMENT , si aucune «tentative d'infraction à la sécur ité» 
(telle que définie à l'annexe 1C) n'est présente dans les données 
de la VU, la valeur 0x00FF est attribuée. Heure de la der­
nière tentative 
d'infraction 
—Valeur par dé­
faut = 0x00FF 
RTM15 
Der nier éta­
lonnage La VU génère une valeur indiquée par un nombre entier (time ­
Real de l'appendice 1) pour l'élément de données RTM15, en 
fonction de la présence de données de dernier étalonnage (tel 
que défini à l'annexe 1C). 
La VU doit attribuer la valeur temporelle des deux derniers éta­
lonnages (RTM15 et RTM16), fixée dans VuCalibrationData 
comme le précise l'appendice 1. 
La VU attribue la valeur pour RTM15 au timeReal du dernier 
enregistrement d'étalonnag e. Heure des don ­
nées de dernier 
étalonnage 
26.5.2016 L 139/475 Jour nal officiel de l'Union européenne FR     
(1) Élément de 
données RTM (2) Action effectuée par la VU  (3) Défini tion des données 
ASN.1 
RTM16 
Étalonnage 
précédent La VU génère une valeur indiquée par un nombre entier (time ­
Real de l'appendice 1) pour l'élément de données RTM16 de 
l'enregistrement d'étalonnag e précédant celui du dernier étalon ­
nage. 
AUTREMENT , si aucun étalonnage n'a été effectué précédem ­
ment, la VU attribue la valeur 0 à RTM16. Heure des don ­
nées de l'étalon ­
nage précédent 
RTM17 
Date de 
connexion du 
tachyg raphe Pour l'élément de données RTM17, la VU attribue une valeur 
indiquée par un nombre entier (timeReal de l'appendice 1). 
La VU attribue la valeur temporelle de l'installation initiale de 
la VU. 
La VU extrait ces données des VuCalibrationData (appendice 1) 
des vuCalibrationRecords, où CalibrationPur pose est égal à: 
‘03’H Date de conne ­
xion du tach y­
graphe 
RTM18 
Vitesse ac­
tuelle La VU génère une valeur expr imée par un nombre entier pour 
l'élément de données RTM18. 
La VU attribue comme valeur pour l'élément RTM18 la der­
nière vites se actuelle enregistrée au moment de la dernière 
mise à jour des RtmData. Dernière vites se 
actuelle enregis ­
trée 
RTM19 
Horodatage Pour l'élément de données RTM19, la VU attribue une valeur 
indiquée par un nombre entier (timeReal de l'appendice 1). 
La VU attribue comme valeur pour l'élément RTM19 le mo­
ment de la dernière mise à jour des RtmData. Horodatage de 
l'enregistrement 
TachographPa y­
load actuel 
5.4.6  Mécanisme de transfert de données 
DSC_42  Les données utiles définies précédemment sont réclamées par le REDCR après la phase d'initialisation 
puis sont transmises par la DSRC-VU dans la fenêtre allouée. Le REDCR utilise la commande GET 
pour extraire les données. 
DSC_43  Pour tous les échanges DSR C, les données sont codées à l'aide des règles PER (Packed Encoding Rules). 
5.4.7  Descr iption détaillée de la transaction DSRC 
DSC_44  L'initialisation est conf orme aux dispositions DSC_44 à DSC_48 et des tableaux 14.4 à 14.9. Durant 
la phase d'initialisation, le REDCR commence à envoyer une trame cont enant une BST (table de 
service de balise) selon les normes EN 12834 et EN 13372, 6.2, 6.3, 6.4, et 7.1 avec le paramétrage 
défini au tableau 14.4 ci-après. 26.5.2016 L 139/476 Jour nal officiel de l'Union européenne FR     
Tableau 14.4 
Initialisation — paramétrage de la trame BST 
Champ Paramétrag e 
Link Identifier Adresse de diffusion 
BeaconId Conf ormément à EN 12834 
Time Conf ormément à EN 12834 
Profile Pas d'extension, utiliser 0 ou 1 
MandApplications Pas d'extensi on, EID non présent, paramètre non présent, AID= 2 
Freight&Fleet 
NonMandApplications Non présent 
ProfileL ist Pas d'extension, nombre de prof ils dans la liste = 0 
Fragmentation header Pas de fragmentation 
Layer 2 settings PDU de commande, Commande UI  
Un exem ple pratique du paramétrage indiqué au tableau 14.4 est fourni dans le tableau 14.5 suivant, 
avec un exem ple de codag e binaire. 
Tableau 14.5 
Initialisation — Exem ple de contenu de la trame BST Octet # Attr ibut/Champ Bits dans 
l'octet Descr iption 
1 FLAG 
 Drapeau de début 
2 Broadcast ID 
 Adresse de diffusion 
3 MAC Control Field 
 PDU de commande 
4 LLC Control field 
 Commande UI 
5 Fragmentation header 
 Pas de fragmentation 26.5.2016 L 139/477 Jour nal officiel de l'Union européenne FR     
Octet # Attr ibut/Champ Bits dans 
l'octet Descr iption 
6 BST 
 Demande d'initialisation 
SEQUENCE {   
OPTION indicator 
BeaconID SEQUENCE { 
ManufacturerId INTEGER 
(0..65535)  
Applications NonMand non présent es    
Identif icateur du fabricant 
7  
8  
IndividualID INTEGER 
(0..134217727)  
} 
ID 27 bits disponible pour le fabricant 
9 
10 
11 
12 Time INTEGER (0..4294967295)  
 Temps réel UNIX 32 bits 
13 
14 
15 
16 Profil eINTEGER (0..127,...)  
 Pas d'extensi on. Profi l d'exem ple 0 
17 MandApplications SEQUENCE 
(SIZE 
(0..127,...)) OF 
{  
Pas d'extensi on, Nombre mandApplica ­
tions = 1 
18 SEQUENCE {   
OPTION indicator 
 EID non présent 
OPTION indicator 
 Paramè tre non présent 
AID DSR CApplicationEntityID 
} }  
Pas d'extensi on. AID= 2 Freight&Fleet 26.5.2016 L 139/478 Jour nal officiel de l'Union européenne FR     
Octet # Attr ibut/Champ Bits dans 
l'octet Descr iption 
19 Profil eList SEQUENCE (0..127,...) 
OF Profile }  
Pas d'extensi on, nombre de prof ils 
dans la liste = 0 
20 FCS 
 Séquence de contrôle de trame 
21 
22 Flag 
 Drapeau de fin  
DSC_45  Lorsqu'une DSRC-VU reçoit une BST, elle demande l'allocation d'une fenêtre privée, telle que définie 
dans les normes EN 12795 et EN 13372, 7.1.1 sans paramétrage RTM particulier . Le tableau 14.6 
fournit un exem ple de codage binaire. 
Tableau 14.6 
Initialisation — Contenu de la trame d'une demande d'allocation de fenêtre privée Octet # Attr ibut/Champ Bits dans 
l'octet Descr iption 
1 FLAG 
 Drapeau de début 
2 Private LID 
 Adresse de liaison de la DSR C-VU spé­
cifique 
3 
4 
5 
6 MAC Control field 
 Demande d'allocation de fenêtre privée 
7 FCS 
 Séquence de contrôle de trame 
8 
9 Flag 
 Drapeau de fin  
DSC_46  Le REDCR répond en allouant une fenêtre privée, comme le définis sent les normes EN 12795 et EN 
13372, 7.1.1 sans paramétrage RTM particulier . 
Le tableau 14.7 fournit un exem ple de codag e binaire. 26.5.2016 L 139/479 Jour nal officiel de l'Union européenne FR     
Tableau 14.7 
Initialisation — Contenu de la trame d'allocation de fenêtre privée Octet # Attr ibut/Champ Bits dans 
l'octet Descr iption 
1 FLAG 
 Drapeau de début 
2 Private LID 
 Adresse de liaison de la DSR C-VU spé­
cifique 
3 
4 
5 
6 MAC Control field 
 Allocation de fenêtre privée 
7 FCS 
 Séquence de contrôle de trame 
8 
9 Flag 
 Drapeau de fin  
DSC_47  Lorsque la DSRC-VU reçoit l'allocation de fenêtre privée, elle envoie sa VST (table de service de 
véhicule) telle que définie dans les normes EN 12834 et EN 13372, 6.2., 6,3, 6.4. et 7.1. avec le 
paramétrage spécifi é au tableau 14.8, en utilisant la fenêtre de transmission allouée. 
Tableau 14.8 
Initialisation — Paramétrage de la trame VST 
Champ Paramétrag e 
Private LID Conf ormément à EN 12834 
VST parameters Fill=0, puis pour chaque application prise en charge: EID présent, para ­
mètre présent, AID=2, EID tel que généré par l'OBU 
Parameter Pas d'extension, contient la marque de cont exte RTM 
ObeConfiguration Le champ optionnel ObeStatus peut être présent, mais n'est pas utilisé 
par le REDCR 
Fragmentation header Pas de fragmentation 
Layer 2 settings PDU de commande, Commande UI  26.5.2016 L 139/480 Jour nal officiel de l'Union européenne FR     
DSC_48  La DSRC-VU prend en charg e l'application «Freight&Fleet», identif iée par l'identificateur d'application 
‘2’. D'autres identificateurs d'application peuvent être pris en charge, mais ne doivent pas être présents 
dans cette VST, car la BST exige uniquement AID = 2. Le champ «Applications» contient une liste des 
instances d'application prises en charge dans la DSRC-VU. Pour chaque instanciation d'application 
prise en charge, une référence à la norme appropr iée est indiquée. Cette référen ce est constituée d'une 
marque de cont exte RTM, elle-même compo sée d'un IDENTIFICA TEUR D'OBJET qui représente la 
norme associée, sa partie (9 pour RTM) et éventuellement sa version, ainsi qu'un EID généré par la 
DSR C-VU et associé à cette instance d'application. 
Un exem ple pratique du paramétrage indiqué au tableau 14.8 est fourni dans le tableau 14.9, avec une 
indication du codag e binaire. 
Tableau 14.9 
Initialisation — Exemple de contenu de la trame VST Octet # Attr ibut/Champ Bits dans 
l'octet Descr iption 
1 FLAG 
 Drapeau de début 
2 Private LID 
 Adresse de liaison de la DSR C-VU spé­
cifique 
3 
4 
5 
6 MAC Control field 
 PDU de commande 
7 LLC Control field 
 Commande UI 
8 Fragmentation header 
 Pas de fragmentation 
9 VST 
SEQUENCE { 
Réponse d'initialisation 
Fill BIT STRING (SIZE(4)) 
 Inutilisé, prend la valeur 0 
10 Profil eINTEGER (0..127,...) 
Applications SEQUENCE OF { 
Pas d'extensi on. Profi l d'exem ple 0 
11 
 Pas d'extensi on, 1 application 
12 SEQUENCE {   
OPTION indicator 
 EID présent 
OPTION indicator 
 Paramè tre présent 
AID DSR CApplicationEntityID 
 Pas d'extensi on. AID= 2 Freight&Fleet 
13 EID Dsrc-EID 
 Défi ni dans le cadre de l'OBU et identi ­
fie l'instance d'application. 26.5.2016 L 139/481 Jour nal officiel de l'Union européenne FR     
Octet # Attr ibut/Champ Bits dans 
l'octet Descr iption 
14 Parameter Container { 
 Pas d'extensi on, choix de conteneur 
= 02, chaîne d'oct et 
15  
 Pas d'extensi on, longueur de marque 
de context e RTM = 8 
16 Rtm-Cont extMark::= SEQUENCE 
{ 
StandardIdentifier 
standardIdentifier  
Identif icateur d'objet de la norme, par­
tie et version prise en charg e. Exem ple: 
ISO (1) Standard (0) TARV (15638) 
part9(9) Version1 (1). 
Le premier octet est 06H, qui est 
l'identifi cateur d'objet. Le deuxième oc­
tet est 06H, qui est sa longueur . Les 6 
octets suivants codent l'identifi cate ur 
d'objet de l'exem ple. 
Remarque: un seul élément de la sé­
quence est présent (l'élément optionnel 
RtmCommProf ile est omis). 17 
18 
19 
20 
21 
22 
23 
24 ObeConfiguration Sequence {   
OPTION indicator 
 ObeStatus non présent 
EquipmentClass INTEGER 
(0..32767) 
25 
26 Manufactur erId INTEGER 
(0..65535) 
Identif icateur du fabricant pour la 
DSR C-VU tel qu'il figure au registre 
ISO 14816 27 
28 FCS 
 Séquence de contrôle de trame 
29 
30 Flag 
 Drapeau de fin  
DCS_49  Le REDCR lit ensuite les données en émettant une commande GET , conf orme à la commande GET 
définie dans les normes EN 13372 6.2, 6.3, 6.4 et EN 12834, avec le paramétrage spécifi é dans le 
tableau 14.10. 
Tableau 14.10 
Présent ation — Paramétrage de la trame de la demande GET 
Champ Paramétrag e 
Invoker Identif ier (IID) Non présent 
Link Identifier (LID) Adresse de liaison de la DSR C-VU spécif ique 
Chaining Non 26.5.2016 L 139/482 Jour nal officiel de l'Union européenne FR     
Champ Paramétrag e 
Element Identif ier (EID) Comme spécifié dans la VST . Pas d'extension 
Access Credentials Non 
AttributeIdList Pas d'extension, 1 attribut, AttributeID = 1 (RtmData) 
Fragmentation Non 
Layer2 settings PDU de commande, commande ACn sollicit ée  
Le tableau 14.11 montre un exem ple de lecture des données RTM. 
Tableau 14.11 
Présentation — Exe mple de trame de demande GET Octet # Attr ibut/Champ Bits dans 
l'octet Descr iption 
1 FLAG 
 Drapeau de début 
2 Private LID 
 Adresse de liaison de la DSR C-VU spé­
cifique 
3 
4 
5 
6 MAC Control field 
 PDU de commande 
7 LLC Control field 
 Commande ACn sollicit ée, bit n 
8 Fragmentation header 
 Pas de fragmentation 
9 Get.request 
SEQUENCE { 
Demande Get 
OPTION indicator 
 Éléments d'authentification d'accès non 
présents 
OPTION indicator 
 IID non présent 
OPTION indicator 
 Attr ibut eIdList présent 
Fill BIT STRING(SIZE(1)) 
 Mis à 0. 
10 EID INTEGER(0..127,…) 
 L'EID de l'instance d'application RTM, 
tel que spécifi é dans la VST. Pas d'ex ­
tension 
11 AttributeIdList SEQUENCE OF { 
AttributeId }} 
Pas d'extensi on, nombre d'attr ibuts = 1 
12 
 Attr ibut eId=1, RtmData. Pas d'exten ­
sion 26.5.2016 L 139/483 Jour nal officiel de l'Union européenne FR     
Octet # Attr ibut/Champ Bits dans 
l'octet Descr iption 
13 FCS 
 Séquence de contrôle de trame 
14 
15 Flag 
 Drapeau de fin  
DSC_50  Lorsque la DSRC-VU reçoit la demande GET , elle envoie une réponse GET avec les données 
demandées conf ormes à la réponse GET définie par la norme EN 13372, 6.2, 6.3, 6.4 et la norme EN 
12834, avec le paramétrage spécifié au tableau 14.12. 
Tableau 14.12 
Présentati on — Paramétrage de la trame de réponse GET 
Champ Paramétrag e 
Invoker Identif ier (IID) Non présent 
Link Identifier (LID) Conf ormément à EN 12834 
Chaining Non 
Element Identif ier (EID) Comme indiqué dans la VST . 
Access Credentials Non 
Fragmentation Non 
Layer2 settings PDU de réponse, réponse disponible et commande accept ée, 
commande ACn  
Le tableau 14.13 montre un exem ple de lecture des données RTM. 
Tableau 14.13 
Présentat ion — Exemple de contenu de trame de réponse Octet # Attr ibut/Champ Bits dans 
l'octet Descr iption 
1 FLAG 
 Drapeau de début 
2 Private LID 
 Adresse de liaison de la DSR C-VU spé­
cifique 
3 
4 
5 
26.5.2016 L 139/484 Jour nal officiel de l'Union européenne FR     
Octet # Attr ibut/Champ Bits dans 
l'octet Descr iption 
6 MAC Control field 
 PDU de réponse 
7 LLC Control field 
 Réponse disponible, commande ACn 
bit n 
8 LLC Status field 
 Réponse disponible et commande ac­
cept ée 
9 Fragmentation header 
 Pas de fragmentation 
10 Get.response 
SEQUENCE { 
Réponse Get 
OPTION indicator 
 IID non présent 
OPTION indicator 
 Liste d'attr ibuts présent e 
OPTION indicator 
 Statut de retour non présent 
Fill BIT STRING(SIZE(1)) 
 Non utilisé 
11 EID INTEGER(0..127,…) 
 Réponse provenant de l'instance d'ap ­
plication RTM. 
Pas d'extensi on, 
12 AttributeList SEQUENCE OF { 
 Pas d'extensi on, nombre d'attr ibuts = 1 
13 Attr ibut es SEQUENCE { 
Attribut eId 
Pas d'extensi on, Attr ibut eId=1 
(RtmData) 
14 Attribut eValue CONT AINER { 
 Pas d'extensi on, choix de conteneur 
= 1010. 
15 
 RtmData 
16 
17 
… … 
n }}}} 
n+1 FCS 
 Séquence de contrôle de trame 
n+2 
n+3 Flag 
 Drapeau de fin  26.5.2016 L 139/485 Jour nal officiel de l'Union européenne FR     
DSC_51  Le REDCR met alors fin à la connexion en émettant une commande EVENT_REPORT RELEASE 
conf orme aux normes EN 13372, 6.2, 6.3, 6.4 et EN 12834,7.3.8, sans paramétrage RTM spécifique. 
Le tableau 14.14 montre un exem ple de codag e binaire de la commande RELEASE. 
Tableau 14.14 
Fin de connexion Contenu de trame de fin de connexion EVENT_REPORT Octet # Attr ibut/Champ Bits dans 
l'octet Descr iption 
1 FLAG 
 Drapeau de début 
2 Private LID 
 Adresse de liaison de la DSR C-VU spé­
cifique 
3 
4 
5 
6 MAC Control field 
 La trame contient une LPDU de 
commande 
7 LLC Control field 
 Commande UI 
8 Fragmentation header 
 Pas de fragmentation 
9 EVENT_REPOR T.request 
SEQUENCE { 
EVENT_REPOR T (Release) 
OPTION indicator 
 Éléments d'authentification d'accès non 
présents 
OPTION indicator 
 Paramè tre d'événement non présent 
OPTION indicator 
 IID non présent 
Mode BOOLEAN 
 Pas de réponse attendue 
10 EID INTEGER (0..127,…) 
 Pas d'extensi on, EID = 0 (System) 
11 EventT ype INTEGER (0..127,…) } 
 Type d'événement 0 = Release 
12 FCS 
 Séquence de contrôle de trame 
13 
14 Flag 
 Drapeau de fin  
DSC_52 La DSRC-VU n'est pas censée répondre à la commande RELEASE. Il est alors mis fin à la communi ­
cation. 
5.4.8  Descr iption de la transaction d'essai DSRC 
DSC_53  Les essais exhaustifs, compr enant la sécur isation des données, doivent être menés conf ormément aux 
dispositions de l'appendice 11 Mécanismes communs de sécur ité, par les personnes autorisées ayant 
accès aux procédures de sécur ité, à l'aide de la commande GET normale définie ci-dessus. 26.5.2016 L 139/486 Jour nal officiel de l'Union européenne FR     
DSC_54  Les essais de mise en service et d'inspection régulière demandant le décr yptage et la compr éhension 
du contenu des données décr yptées sont menés conf ormément aux dispositions de l'appendice 11 
Mécanismes communs de sécur ité et de l'appendice 9 Homolog ation — Liste des essais minimaux 
requis. 
Cependant, il est possible de procéder à un essai de la communication DSR C de base avec la 
commande ECHO. De tels essais peuvent se révéler nécessaires lors de la mise en service, lors des 
inspections régulières ou sur demande des autori tés de contrôle compét entes ou conf ormément aux 
dispositions du règlement (UE) no 165/2014 (cf. 6 ci-dessous). 
DSC_55  Pour procéder à cet essai de communication de base, la commande ECHO est émise par le REDCR 
pendant une session, c'est-à-dire après une phase d'initialisation réussie. La séquence des interactions 
est donc similaire à celle d'une interrogation:  
— Étape 1Le REDCR envoie une «table de service de balise» (BST) cont enant les identificateurs 
d'application (AID) dans la liste de services pris en charge. Dans les applications RTM, cela 
correspond simplement au service de valeur AID = 2. 
La DSRC-VU évalue la BST reçue et répond lorsqu'elle détect e que la BST demande Freight&Fleet 
(AID = 2). Si le REDCR ne propose pas AID = 2, la DSRC-VU met fin à la transaction avec le 
REDCR.  
— Étape 2La DSRC-VU envoie une demande d'allocation de fenêtre privée.  
— Étape 3Le REDCR envoie une allocation de fenêtre privée.  
— Étape 4La DSRC-VU utilise cette fenêtre privée allouée pour envoyer sa table de service de 
véhicule (VST). Cette VST comprend la liste de tout es les instanciations d'application diffé rentes 
prises en charge par cette DSRC-VU dans le cadre d'une valeur AID = 2. Les différ entes instan ­
ciations sont identif iées au moyen d'EID générés de manière excl usive. Chacun est associé à une 
valeur de paramètres indiquant l'instance de l'application prise en charg e.  
— Étape 5Ensuite le REDCR analyse la VST proposée et décide soit de mettre fin à la connexion 
(RELEASE) car rien ne l'intéresse dans l'offre de la VST (c'est-à-dire qu'il reçoit une VST d'une 
DSRC-VU qui n'est pas une RTM VU), soit, s'il reçoit une VST appropr iée, de lancer une instan ­
ciation d'application.  
— Étape 6Le REDCR émet une commande (ECH O) vers la DSRC-VU spécifique et alloue une fenêtre 
privée.  
— Étape 7La DSRC-VU utilise la fenêtre privée qui vient d'être allouée pour envoyer une trame de 
réponse. 
Les tableaux suivants donnent un exem ple pratique de session d'échang e ECHO. 
DSC_56  L'initialisation est effectuée conf ormément aux dispositions de la section 5.4.7 (DSC_44 – DSC_48) et 
des tableaux 14.4 – 14.9. 
DSC_57  Le REDCR émet alors une commande ACTION, ECHO conf orme à la norme ISO 14906, conte nant 
100 octets de données, sans paramétrage particulier pour RTM. Le tableau 14.15 indique le contenu 
de la trame envoyée par le REDCR. 
Tableau 14.15 
Exemple de trame de demande ACTION , ECHO Octet # Attr ibut/Champ Bits dans 
l'octet Descr iption 
1 FLAG 
 Drapeau de début 
2 Private LID 
 Adresse de liaison de la DSR C-VU spé­
cifique 
3 
26.5.2016 L 139/487 Jour nal officiel de l'Union européenne FR     
Octet # Attr ibut/Champ Bits dans 
l'octet Descr iption 
4  
5 
6 MAC Control field 
 PDU de commande 
7 LLC Control field 
 Commande ACn sollicit ée, bit n 
8 Fragmentation header 
 Pas de fragmentation 
9 ACTION.request 
SEQUENCE { 
Demande d'action (ECHO) 
OPTION indicator 
 Éléments d'authentification d'accès non 
présents 
OPTION indicator 
 Paramè tre d'action présent 
OPTION indicator 
 IID non présent 
Mode BOOLEAN 
 Réponse attendue 
10 EID INTEGER (0..127,…) 
 Pas d'extensi on, EID = 0 (System) 
11 Action Type INTEGER (0..127,…) 
 Pas d'extensi on, Type d'action demande 
ECH O 
12 ActionParamet er CONT AINER { 
 Pas d'extensi on, Choix de conteneur 
= 2 
13 
 Pas d'extensi on. Longueur de chaîne 
= 100 octets 
14  
 Données à renv oyer 
… … 
113 }} 
114 FCS 
 Séquence de contrôle de trame 
115 
116 Flag 
 Drapeau de fin  
DSC_58  Lorsque la DSRC-VU reçoit la demande ECHO, elle envoie une réponse ECHO sur 100 octets de 
données en reflétant la commande reçue, conf ormément aux dispositions de la norme ISO 14906, 
sans paramétrage RTM spécif ique. Le tableau 14.16 montre un exem ple de codag e binaire. 26.5.2016 L 139/488 Jour nal officiel de l'Union européenne FR     
Tableau 14.16 
Exemple de trame de réponse ACTION , ECHO Octet # Attr ibut/Champ Bits dans 
l'octet Descr iption 
1 FLAG 
 Drapeau de début 
2 Private LID 
 Adresse de liaison de la VU spécifique 
3 
4 
5 
6 MAC Control field 
 PDU de réponse 
7 LLC Control field 
 Commande ACn, bit n 
8 LLC status field 
 Réponse disponible 
9 Fragmentation header 
 Pas de fragmentation 
10 ACTION.response 
SEQUENCE { 
Réponse ACTION (ECH O) 
OPTION indicator 
 IID non présent 
OPTION indicator 
 Paramè tre de réponse présent 
OPTION indicator 
 Statut de retour non présent 
Fill BIT STRING (SIZE (1)) 
 Non utilisé 
11 EID INTEGER (0..127,…) 
 Pas d'extensi on, EID = 0 (System) 
12 ResponseP arameter CONT AINER { 
 Pas d'extensi on, Choix de conteneur 
= 2 
13 
 Pas d'extensi on. Longueur de chaîne 
= 100 octets 
14  
 Données renv oyées 
… … 
113 }} 
114 FCS 
 Séquence de contrôle de trame 
115 
116 Flag 
 Drapeau de fin  26.5.2016 L 139/489 Jour nal officiel de l'Union européenne FR     
5.5  Conf ormité à la directiv e 2015/71/CE 
5.5.1  Vue d'ensemble 
DSC_59  Pour respecter la directive (UE) 2015/719 sur les poids et les dimensions maximaux des poids lourds, 
le protocole de transaction de télécharg ement des données OWS utilisant la liaison d'interface DSR C 
5,8 GHz est le même que celui servant aux données RTM (cf. 5.4.1). La seule différence réside dans le 
fait que l'identifi cate ur d'objet associé à la norme TARV respecte la norme ISO 15638 (TARV) partie 
20 concer nant les WOB/O WS. 
5.5.2  Commandes 
DSC_60  Les commandes servant à une transaction OWS sont identiques à celles utilisées pour une transaction 
RTM . 
5.5.3  Séquence de commande d'inter rogation 
DSC_61  La séquence de commande d'interrogation concer nant les données OWS est identique à celle 
concer nant les données RTM. 
5.5.4  Structures de données 
DSC_62  Les données utiles (données OWS) correspondent à la concaténation des données:  
1. Encr yptedOwsP ayload, qui correspondent au cryptage de OwsPa yload tel que défini en ASN.1 à la 
section 5.5.5. La méthode de cryptage est identique à celle adopt ée pour RtmData, spécifiée à 
l'appendice 11;  
2. DSR CSecur ityData, calculées avec les mêmes algor ithmes que pour RtmData, dont les spécifi cations 
se trouvent à l'appendice 11.  26.5.2016 L 139/490 Jour nal officiel de l'Union européenne FR     
5.5.5  Module ASN.1 de la transaction DSRC OWS 
DSC_63.  Le module ASN.1 concer nant les données DSR C dans l'application RTM est défini comme suit: 
26.5.2016 L 139/491 Jour nal officiel de l'Union européenne FR     
5.5.6  Éléments Ows Data, actions effectuées et définitions 
Les éléments OwsData sont définis de manière à satisf aire aux dispositions de la directive (UE) 2015/719 
relative aux poids et aux dimensions maximaux des poids lourds. Leur signif ication est la suivante: 
—  recordedW eight représente le poids total mesuré du poids lourd avec une résolution de 10 kg, tel que défini 
par la norme EN ISO 14906. Par exem ple, une valeur de 2500 représente un poids tota l de 25 tonnes. 
—axlesConf iguration représent e la conf iguration du poids lourd en term es de nombre d'essieux. La conf igu­
ration est définie par le masque de bit de 20 bits (étendu à partir de la norme EN ISO 14906). 
Un masque de deux bits représente la conf iguration d'un essieu, selon la structure suivante: 
—  La valeur 00B signif ie que la valeur est «indisponible» parce que le véhicule ne possède pas l'équipement 
permettant de mesurer le poids à l'essieu. 
—  La valeur 01B signif ie que l'essieu est absent. 
—  La valeur 10B signif ie que l'essieu est présent et que le poids a été calculé et collect é et qu'il est 
communiqué dans le champ axlesRecordedW eight 
—  La valeur 11B est réser vée à de futures utilisations. 
Les quatre derniers bits sont réser vés à des utilisations ultérieures. 
Nombre d'essieux  
Nombre d'essieux dont est pour vu 
le tract eur Nombre d'essieux dont est pour vue la remorque 
00/01/ 
10/11 00/01/ 
10/11 00/01/ 
10/11 00/01/ 
10/11 00/01/ 
10/11 00/01/ 
10/11 00/01/ 
10/11 00/01/ 
10/11 00/01/ 
10/11 00/01/ 
10/11 RFU 
(4 bits)  
—  axlesRecordedW eight représente le poids spécifi que enregistré pour chaque essieu avec une résolution de 
10 kg. Deux octets servent à chaque essieu. Par exem ple, une valeur de 150 représente un poids total de 
1 500 kg. 
Les autres types de données sont définis en 5.4.5. 
5.5.7  Mécanismes de transfert de données 
DSC_64  Le mécanisme de transfer t de données OWS entre l'interroga teur et le dispositif DSR C dans le véhicule 
est identique à celui utilisé pour les données RTM (cf. 5.4.6). 
DSC_65  Le transfe rt de données entre la platef orme qui recueille les données de poids maximaux et le 
dispositif DSR C dans le véhicule repose sur la connexion physique et les interfaces et le protocole 
définis à la section 5.6. 
5.6  Transfer t de données entre la DSR C-VU et la VU 
5.6.1  Connexion physiq ue et interfaces 
DSC_66  La connexion entre la VU et la DSRC-VU peut être établie soit par un câble physique, soit par le biais 
d'une communication sans fil de cour te portée reposant sur le prot ocole Bluetooth v4.0 BLE. 
DSC_67  Indépendamment du choix de la connexion physique et de l'interface, les exigenc es suivantes doivent 
être satisf aites: 
DSC_68  a)Pour que la fourniture de la VU et de la DSR C-VU, voire de diffé rents lots de la DSR C-VU, puisse 
être sous-traitées à plusieurs fournisseurs, la connexion reliant la VU et la DSR C-VU doit être une 
connexion ouver te normalisée. La VU doit être connectée à la DSR C-VU: 
i)  via un câble fixe de 2 mètres au minimum avec un connecte ur mâle homologué à 11 broches 
Straight DIN 41612 H11 sur la DSR C-VU, s'emboîtant dans un connect eur femelle homologué 
DIN/ISO correspondant sur la VU; 26.5.2016 L 139/492 Jour nal officiel de l'Union européenne FR     
ii)  via Bluetooth Low Energy (BLE); ou 
iii)  via une connexion normalisée ISO 11898 ou SAE J1939. 
DSC_69  b)a définit ion des interface s et de la connexion entre la VU et la DSR C-VU doit être compatible avec 
les commandes du protocole d'application définies à la section 5.6.2 et 
DSC_70  c)la VU et la DSR C-VU doivent permettre l'opération de transfe rt de données par la connexion en 
term es de perf ormance et d'alimentation électr ique. 
5.6.2  Protocole d'application 
DSC_71  Le protocole d'application entre le dispositif de communication à distance de la VU et la DSR C-VU est 
responsable du transfer t régulier des données de communication à distance de la VU vers le DSR C. 
DSC_72  Les principales commandes suivantes sont identif iées:  
1. Initialisation de la liaison de communication — Demande  
2. Initialisation de la liaison de communication — Réponse  
3. Envoi de données avec l'identifi cate ur de l'application RTM et les données utiles définies par les 
données RTM  
4. Accusé de réception de données  
5. Fin de la liaison de communication — Demande  
6. Fin de la liaison de communication — Réponse 
DSC_73  En ASN1.0, les commandes précédente s peuvent être définies comme suit: 
26.5.2016 L 139/493 Jour nal officiel de l'Union européenne FR     
DSC_74  La descr iption des commandes et des paramètres est la suivante: 
—  
 sert à initialiser la liaison de 
communication. Les commandes sont adressées par la VU à la DSR C-VU. Le LinkIdentifier est 
défini par la VU et communiqué à la DSR C-VU pour suivre une liaison de communication 
spécifique. 
(Not e: cela permet d'assurer la prise en charge de liaisons ultérieures et d'autres applications ou 
d'autres modules comme la pesée à bord).  
—  
 sert à la DSR C-VU pour 
fournir la réponse à la demande d'initialiser la liaison de communication. La commande est 
adressée par la DSR C-VU à la VU. La commande fournit le résultat de l'initialisation à titre de 
réponse = 1 (Réussite) ou =0 (Échec). 
DSC_75  L'initialisation de la liaison de communication a lieu après l'installation, l'étalonnage et le démar rage 
du moteur ou de la VU. 
—  
 sert à la VU pour envoyer les RCDTData signées (c'est-à-dire, les données de 
communication à distance) à la DSR C-VU. Les données sont envoyées tout es les 60 secondes. Le 
paramètre DataT ransactionId identif ie la transmission spécifique de données. Le LinkIdentif ier sert 
également à faire en sorte que la liaison appropr iée soit correcte . 
—  
 est envoyé par la DSR C-VU pour appor ter un retour à la VU 
quant à la réception des données à partir d'une commande 
 identif iée par le 
paramètre DataT ransactionId. Le paramètre de réponse est 1 (Réussite) ou 0 (Échec). Si une VU 
reçoit plus de trois réponses égales à 0 ou si la VU ne reçoit pas de RCDT Data Ackno wledgment 
pour un RCDT — Send Data antérie ur avec un DataT ransactionId spécifi que, la VU génère et 
mémor ise un événement. 
—  
 est envoyé par la VU à la DSR C-VU 
pour mettre fin à une liaison avec un LinkIdentif ier spécifi que. 
DSC_76  Au redémar rage de la DSR C-VU ou d'une VU, il est nécessaire de suppr imer tout es les liaisons de 
communication existant es, car il pour rait demeurer des liaisons «fantômes» du fait de la coupure 
brutale d'une VU. 
—  
 est envoyé par la DSR C-VU à la VU 
pour conf irmer la demande de fin de la liaison de la VU pour le LinkIdentif ier spécifique. 
5.7  Traitement des erreurs 
5.7.1  Enreg istrement et communication des données dans la DSRC-VU 
DSC_77  Les données sont fournies déjà sécur isées par la fonction VUSM à la DSRC-VU. La VUSM vérifie que 
les données enregistrées dans la DSRC-VU le sont de manière satisf aisante. L'enregistrement et le 
signalement de tout es les erreurs survenues pendant le transfer t de données depuis la VU vers la 
mémoire de la DSRC-VU doivent être consignés avec le type EventF aultT ype et la valeur enum 
d'erreur de communication ‘62’H Dispositif de communication à distance, accompag nées de 
l'horodatage. 
DSC_78  La VU tient à jour un fichier identif ié par un intitulé unique aisément identif iable par les inspect eurs 
aux fins de l'enregistrement des «Anomalies de communication internes à la VU». 
DSC_79  Si la VUPM tente d'obtenir les données VU du module de sécur ité (pour les transfér er à la DSR C-VU), 
mais échoue, elle doit mémor iser cet échec avec le type EventFaultT ype et la valeur enum d'erreur de 
communication ‘62’H Dispositif de communication à distance, ainsi que l'horodatage. L'anomalie de 
communication est détectée lorsque, plus de trois fois consécutives, un message 
n'est pas reçu pour le 
 correspondant (c'est-à- 
dire muni du même DataT ransactionId 
). 
5.7.2  Anomalies de communication sans fil 
DSC_80  La gestion des anomalies de communication est cohérente avec les dispositions des normes DSR C, à 
savoir EN 300 674-1, EN 12253, EN 12795, EN 12834 et les paramètres appropr iés de la norme EN 
13372. 26.5.2016 L 139/494 Jour nal officiel de l'Union européenne FR     
5.7.2.1  Anomalies de cryptage et de signature 
DSC_81  Les anomalies de crypta ge et de signature sont gérées conf ormément aux dispositions de l'appendice 
11 Mécanismes communs de sécur ité et ne figurent pas dans les messages d'erreur associés au 
transfer t de données DSR C. 
5.7.2.2  Rele vé des anomalies 
Le suppor t DSR C désigne une communication sans fil dynamique dans un environnement marqué par des 
conditions atmosphér iques et d'inte rférences incer taines, en particulier dans les cas où sont combinés le REDCR 
portable et le véhicule en circulation impliqués dans cette application. Il est donc nécessaire de distinguer une 
«anomalie de lecture» d'une condition d'«er reur». Dans une transaction avec une interface sans fil, l'anomalie de 
lecture est courante et entraîne habituellement une nouvelle tentative, c'est-à-dire la rediffusion de la BST et une 
nouvelle tentative de séquence, qui dans la plupar t des cas mènent à une connexion de communication réussie 
et au transfer t des données, sauf si le véhicule ciblé devient hors portée pendant le temps nécessaire à la retrans ­
mission. (Une instance «réussie» de «lecture» peut requér ir plusieurs tentatives). 
L'anomalie de lecture peut provenir du fait que les antennes ne sont pas appairées correctement (anomalie de 
«visée»); du fait que l'une des antennes est blindée — de manière délibérée ou à cause de la présence physique 
d'un autre véhicule; d'interfé rences radio, en particulier à proximité de communications WIFI autour de 
5,8 GHz ou d'autres types de communication sans fil d'accès public; ou de l'interférence avec des radars ou 
encore du fait des conditions atmosphér iques (p. ex. pendant un orag e); ou simplement en raison d'un 
déplacement hors de la portée de la communication DSR C. Les cas individuels d'anomalies de lecture, par 
essence, ne peuvent pas faire l'objet d'un relevé. En effet, la communication n'a pas eu lieu. 
Cependant, si l'agen t des autori tés de contrôle compét entes cible un véhicule et tente d'interr oger sa DSRC-VU, 
mais qu'aucun transfer t de données n'aboutit, cette anomalie peut s'expliquer par une falsification délibérée. Par 
conséquent, l'agen t des autor ités de contrôle compét entes a besoin d'un moyen de consigner l'anomalie et 
d'aler ter ses collègues en aval d'un risque d'infraction. Les collègues peuvent inter cept er le véhicule et procéder à 
une inspection physique. Toutef ois, aucune communication n'ayant abouti, la DSR C-VU ne peut fournir aucune 
donnée concer nant cette anomalie. Ce type de rappor t doit donc être une fonction intégré e à la concep tion de 
l'équipement du REDCR. 
L'«anomalie de lecture» est techniquement différ ente d'une «erreur». Dans ce conte xte, une «erreur» désigne 
l'acquisition d'une valeur fausse. 
Les données transférées à la DSRC-VU sont fournies déjà sécur isées et doivent donc faire l'objet d'une 
vérification par le fournisseur de données (cf. 5.4). 
Les données transférées ultér ieurement par l'inte rface aérienne sont soumises à des contrôles de redondance 
cyclique au niveau de la communication. Si le CRC les valide, les données sont exactes. Si le CRC ne les valide 
pas, les données sont transmises à nouveau. La probabilit é que des données erronées passent à travers un 
contrôle CRC est tellem ent faible qu'elle peut être ignorée. 
Si le CRC ne valide pas les données et que le temps manque pour procéder à une retransmission et à une 
récep tion des données exactes , la situation n'entraîne pas une erreur , mais une instanciation d'une catégor ie 
spécifique d'anomalie de lecture. 
Les seules données d'«anomalie» signif icatives qui peuvent être enregistrées sont le nombre d'initiations de 
transactions réussies qui ne se concluent pas par un transfer t des données au REDCR. 
DSC_82  Le REDCR doit donc mémor iser et horodater le nombre de transactions pour lesquelles la phase 
d'«initialisation» d'une interrogation DSR C a abouti, mais qui ont été interro mpue s avant que les 
données n'aient pu être extraites par le REDCR. Ces données sont disponibles pour l'agent des autorités 
de contrôle compét entes et sont enregistrées dans la mémoire de l'équipement REDCR. Les moyens d'y 
parvenir relèvent de la conception du produit ou de la spécification des autorités de contrôle 
compét entes. 
Les seules données d'«er reur» significatives qui peuvent être enregistrées sont le nombre de fois où le 
REDCR échoue à décr ypter les données reçues. Cependant, il est à noter que cela ne concer ne que 
l'efficience du logiciel REDCR. Les données peuvent être décr yptées techniquement, mais pas 
interprétées du point de vue sémantique. 26.5.2016 L 139/495 Jour nal officiel de l'Union européenne FR     
DSC_83  Le REDCR enregistre et horodate par conséquent le nombre de tentatives infructueuses de décr yptage 
des données reçues par l'interface DSR C. 
6  MISE EN SER VICE ET ESSAIS D'INSPECTION PÉRIODIQUES REL ATIFS À LA FONCTION DE COMMUNICA TION À 
DIST ANCE 
6.1  Généralités 
DSC_84  Deux catégor ies d'essais sont prévues pour la fonction de communication à distance:  
1) Un essai ECHO pour valider le canal de communication sans fil DSRC-REDCR >>-:-< DSRC-VU.  
2) Un essai de sécur ité de bout en bout pour s'assurer qu'une carte d'ate lier est en mesure d'accéder 
au cont enu de données signées et cryptées créé par la VU et transmis à l'aide du canal de 
communication sans fil. 
6.2  ECHO 
La présent e section contient des dispositions spécifiques pour vérifier uniquement l'activité fonctionnelle de la 
liaison DSRC-REDCR >>-:-<DSRC-VU. 
L'objectif de la commande ECHO est de permettre aux ateli ers ou aux infrastr uctures d'essai d'homologation de 
vérifier que la liaison DSR C fonctionne sans devoir accéder aux éléments d'authentification de sécur ité. 
L'équipement d'essai doit donc uniquement être en mesure d'initialiser une communication DSR C (envoi d'une 
BST avec AID = 2), d'env oyer la commande ECH O et, dans l'hypothèse où la communication DSR C fonctionne, 
de recev oir la réponse ECHO. Cf. 5.4.8 pour davant age de détails. Dans l'hypothèse où cette réponse est reçue 
correctement, le fonctionnement de la liaison DSR C (DSRC-REDCR >>-:-< DSRC-VU) peut être validé comme 
satisf aisant. 
6.3  Essais de validation du contenu des données sécur isées 
DSC_85  Cet essai sert à valider le flux de données de bout en bout sur le plan de la sécur ité. Il est nécessaire de 
disposer d'un lecte ur d'essai DSR C pour procéder à cet essai. Le lecteur d'essai DSR C assure les mêmes 
fonctionnalit és et est mis en œuvre selon les mêmes spécif ications que le lecteur utilisé par les agents 
de la force publique, avec une seule différ ence, à savoir qu'une carte d'atelier est utilisée pour 
authentifier l'utilisateur du lecteur , plutôt qu'une carte de contrôle. Il est possible de procéder à cet 
essai après l'activation initiale d'un tach ygraphe intelligent ou à la fin de la procédure d'étalonnag e. 
Après son activation, l'unité embarquée sur le véhicule génère et communique à la DSR C-VU les 
données sécur isées de détection précoce. 
DSC_86  Le personnel d'ateli er doit placer le lecteur d'essai DSR C à une distance située entre 2 et 10 mètres 
devant le véhicule. 
DSC_87  Le personnel d'ateli er doit ensuite insérer une carte d'ateli er dans le lecteur d'essai DSR C pour adresser 
une interro gation portant sur les données de détection précoce à l'unit é embarquée sur le véhicule. 
Après une interr ogation réussie, le personnel d'ateli er accède aux données reçues pour vérifier que leur 
intégrité et leur décr yptage sont validés.  26.5.2016 L 139/496 Jour nal officiel de l'Union européenne FR     
Appendice 15 
MIGRA TION: GÉRER LA COEXISTENCE DE PLUSIEURS GÉNÉRA TIONS D'ÉQUIPEMENTS 
TABLE DES MATIÈRES 
1. DÉFINITIONS .................................................................................................................................... 497 
2. DISPOSITIONS GÉNÉRALES .................................................................................................................. 497 
2.1. Présentation de la transition ...................................................................................................... 497 
2.2. Interopérabilit é entre les unités embarquées sur les véhicules et les cartes............................................ 498 
2.3. Interopérabilit é entre les unités embarquées sur les véhicules et les capt eurs de mouvement .................... 498 
2.4. Interopérabilit é entre les unités embarquées sur les véhicules, les cartes tach ygraphiques et l'équipement de 
téléc hargement de données ....................................................................................................... 498 
2.4.1 Télécharg ement direct de carte par IDE ....................................................................................... 498 
2.4.2 Télécharg ement de carte via une unité embarquée sur un véhicule ..................................................... 499 
2.4.3 Télécharg ement d'unité embarquée sur un véhicule ........................................................................ 499 
2.5. Interopérabilit é entre les unités embarquées sur les véhicules et l'équipement d'étalonnag e...................... 499 
3. PRINCIP ALES ÉTAPES PRÉCÉD ANT LE LANCEMENT ................................................................................... 499 
4. DISPOSITIONS REL ATIVES À LA PÉRIODE QUI SUIT LE LANCEMENT ............................................................ 499  
1.  DÉFINITIONS 
Aux fins du présent appendice, les définitions suivantes sont applicables: 
tachygraphe intelligent :tel que défini à la présent e annex e (chapitre 1: définition bbb); 
tachygraphe de première génération: tel que défini par le présent règlement (article 2: définition 1); 
tachygraphe de deuxième génération: tel que défini par le présent règlement (article 2: définition 7); 
date d'introduction: telle que définie dans la présent e annexe (chapitre 1: définition ccc); 
équipement spécialisé intelligent (IDE): équipement servant à télécharg er des données, comme défini à 
l'appendice 7 de la présente annexe. 
2.  DISPOSITIONS GÉNÉRALES 
2.1.  Présent ation de la transition 
Le préambule de la présent e annexe présente la transition de la première à la deuxième génération de 
tach ygraphes. 
Outre les dispositions de ce préambule: 
—  La première génération de capt eurs de mouvement ne sera pas interopérable avec la deuxième génération 
d'unités embarquées sur les véhicules. 
—  L'installation de la deuxième génération des capt eurs de mouvement sur les véhicules commencera en même 
temps que celle de la deuxième génération d'unités embarquées sur les véhicules. 
—  le téléc hargem ent de données et l'équipement d'étalonnag e devront évoluer pour être compati bles avec les 
deux générations d'équipement d'enregistrement et de cartes tach ygraphiques. 26.5.2016 L 139/497 Jour nal officiel de l'Union européenne FR     
2.2.  Interopérabilité entre les unités embarquées sur les véhicules et les cartes 
Il est entendu que la première génération de cartes tach ygraphiques est inter opérable avec la première génération 
d'unités embarquées sur les véhicules (conf ormément à l'annexe 1B de la présent e directive), alors que la deuxième 
génération de cartes tach ygraphiques est interopérable avec la deuxième génération d'unité s embarquées sur les 
véhicules (conf ormément à l'annex e 1C de la présent e directive). De plus, les exige nces ci-dessous s'appliquent. 
MIG_001  Hor mis les dispositions prévues aux exige nces MIG_004 et MIG_005, les cartes tach ygraphiques de 
première génération peuvent continuer à être utilisée dans les unité s embarquées sur les véhicules de 
deuxième génération jusqu'à expiration de leur validité. Leurs détent eurs peuvent tout efois demander 
leur replacement par des cartes tach ygraphiques de deuxième génération dès que ces dernières sont 
disponibles. 
MIG_002  Les unités embarquées sur des véhicules de deuxième génération pour ront utiliser tout e carte de 
conducteur , de contrôleur et d'entrepr ise valides de première génération qui auront été insérés. 
MIG_003  Les ateliers pour raient suppr imer définitivement cette possibilit é dans lesdites unités embarquées sur les 
véhicules, de sorte que la première génération de cartes tach ygraphiques ne serait plus accept ée. Cela 
ne pour rait avoir lieu qu'après que la Commission européenne ait lancé une procédure visant à 
demander aux ateli ers de procéder ainsi, par exem ple, lors de chaque inspection périodique du 
tach ygraphe. 
MIG_004  La deuxième génération d'unités embarquées sur des véhicules ne pour ra utiliser que des cartes 
d'ateliers de deuxième génération. 
MIG_005  Pour déterminer le mode de fonctionnement de la deuxième génération d'unités embarquées sur les 
véhicules, il suffira de consult er les types de cartes valides insérées, indépendamment de leur 
génération. 
MIG_006  Toute carte tach ygraphique de deuxième génération valide pour ra être utilisée sur des unité s 
embarquées de première génération exacte ment de la même manière qu'une carte tach ygraphique de 
première génération de type identique. 
2.3.  Interopérabilité entre les unités embarquées sur les véhicules et les capteurs de mouv ement 
Il est entendu que la première génération de capt eurs de mouvement est interopérable avec la première génération 
d'unités embarquées sur les véhicules, et que la deuxième génération de capt eurs de mouvement est interopérable 
avec la deuxième génération d'unités embarquées sur les véhicules. De plus, les exigenc es ci-dessous s'appliquent. 
MIG_007  Les unités embarquées sur les véhicules de deuxième génération ne pour ront pas être couplées et 
utilisées les capt eurs de mouvement de première génération. 
MIG_008  Les capt eurs de mouvement de deuxième génération pour ront être couplés et utilisés soit uniquement 
avec des unités embarquées sur les véhicules de deuxième génération, soit avec les deux générations 
d'unités embarquées sur les véhicules. 
2.4.  Interopérabilité entre les unités embarquées sur les véhicules, les cartes tachy graphiques et l'équipement 
de téléchargement de données 
MIG_009  L'équipement de téléc hargement de données peut être utilisé avec une seule génération d'unités 
embarquées sur des véhicules et de cartes tach ygraphiques ou avec les deux. 
2.4.1  Téléchargement direct de carte par IDE 
MIG_010  Les données sont téléc hargées par IDE depuis les cartes tach ygraphiques d'une génération qui ont été 
insérées dans les lecteurs de cartes, selon les mécanismes de sécur ité et les protocoles de téléc hargem ent 
des données de cette génération, et les données téléc hargées sont au format défini pour ladit e 
génération. 
MIG_011  Pour permettre le contrôle des conduct eurs par des autori tés de contrôles autres que celles de l'UE, il 
sera également possible de téléc harger des cartes de conduct eurs (et d'ateli ers) de deuxième génération 
de la même manière que les cartes de conducteurs (et d'ateli ers) de première génération. Ce type de 
téléc hargement inclura: 
—  des EF (fichiers élémentaires) 
 et 
 non signés, 
—  des EF (de première génération) 
 et 
 non signés, 26.5.2016 L 139/498 Jour nal officiel de l'Union européenne FR     
—  d'autres EF de données d'application (au sein du DF (fichier spécialisé) 
 ) nécessaires au 
protocole de téléc hargement des cartes de première génération. Ces informations seront prot égées 
par une signature numér ique conf ormément aux mécanismes de sécur ité de première génération. 
Ce type de téléc hargement n'inclura pas d'EF de données d'application uniquement présents sur les 
cartes de lecteurs (et d'ate liers) de deuxième génération (EF de données d'application au sein du DF 
). 
2.4.2  Téléchargement de carte via une unité embar quée sur un véhic ule 
MIG_012  Les données sont téléc hargées depuis une carte de deuxième génération insérée dans une unité 
embarquée sur un véhicule de première génération selon le protocole de téléc hargement de données de 
la première génération. La carte réagira aux commandes de l'unit é embarquée sur le véhicule 
exactement de la même manière qu'une carte de première génération. Les données téléc hargées auront 
le même format que les données téléc hargées depuis une carte de première génération. 
MIG_013  Les données sont télécharg ées depuis une carte de première génération insérée dans une unité 
embarquée sur un véhicule de deuxième génération selon le protocole de téléc hargement de données 
défini à l'appendice 7 de la présent e annexe . L'unité embarquée sur le véhicule adressera des 
commandes à la carte exactement de la même manière qu'une unité embarquée sur un véhicule de 
première génération. Les données téléc hargées auront le format défini pour les cartes de première 
génération. 
2.4.3  Téléchargement d'unité embar quée sur un véhicule 
MIG_014  Les données sont téléc hargée s depuis une unité embarquée sur un véhicule de deuxième génération 
selon les mécanismes de sécur ité de deuxième génération et le protocole de téléc hargement de données 
défini à l'appendice 7 de la présent e annex e. 
MIG_015  Pour permettre le contrôle des conducteurs par des autorités de contrôles autres que celles de l'UE et le 
téléc hargement de données des unités embarquées sur les véhicules par des ateli ers autres que ceux de 
l'UE, il peut également être rendu possible de téléc harger des données depuis des unités embarquées sur 
des véhicules de deuxième génération selon les mécanismes de sécur ité de première génération et le 
protocole de téléc hargement de données de première génération. Les données téléc hargées auront le 
même format que les données télécharg ées depuis une unité embarquée sur un véhicule de première 
génération. Cette fonctionnalit é peut être sélectionnée grâce aux commandes du menu. 
2.5.  Interopérabilité entre les unités embarquées sur les véhicules et l'équipement d'ét alonnage 
MIG_016  L'équipement d'étalonnag e pour ra procéder à l'étalonnage de chaque génération de tach ygraphe selon 
le protocole d'étalonnage de cette génération. L'équipement d'étalonnag e peut être utilisé avec une seule 
génération de tach ygraphe ou avec les deux. 
3.  PRINCIP ALES ÉTAPES PRÉCÉD ANT LE LANCEMENT 
MIG_017  Les clés et les certificat s d'essai seront à la disposition des fabricants au moins 30 mois avant la date 
d'introduction. 
MIG_018  Les essais d'interopérabilit é seront prêts à commencer sur demande des fabr icants au plus tard 
15 mois avant la date d'introduction. 
MIG_019  Les clés et les certificat s officiels seront à la disposition des fabr icants au moins 12 mois avant la date 
d'introduction. 
MIG_020  Les États membres pour ront émettre des cartes d'ateliers de deuxième génération au plus tard 3 mois 
avant la date d'introduction. 
MIG_021  Les États membres pour ront émettre tous les types de cartes tach ygraphiques de deuxième génération 
au plus tard 1 mois avant le lancement. 
4.  DISPOSITIONS REL ATIVES À LA PÉRIODE QUI SUIT LE LANCEMENT 
MIG_022  Après la date d'introduction, les États membres n'émettront que des cartes tach ygraphiques de 
deuxième génération. 26.5.2016 L 139/499 Jour nal officiel de l'Union européenne FR     
MIG_023  Les fabr icants d'unités embarquées sur un véhicule ou de capt eurs de mouvement seront autori sés à 
produire des unités embarquées sur un véhicule ou des capt eurs de mouvement de première génération 
tant qu'ils resteront utilisés sur le terrain, de façon à pouv oir remplacer les compo sants qui dysf onc­
tionneraient. 
MIG_024  Les fabr icants d'unités embarquées sur un véhicule ou de capt eurs de mouvement seront autori sés à 
demander et à obtenir le maintien de l'homolog ation pour des unité s embarquées sur un véhicule ou 
des capt eurs de mouvement de première génération dont le type est déjà homologué.  26.5.2016 L 139/500 Jour nal officiel de l'Union européenne FR     
Appendice 16 
ADAPT ATEUR POUR LES VÉHICULES DES TYPES M 1 ET N1 
TABLE DES MATIÈRES 
1. ABRÉVIA TIONS ET DOCUMENTS DE RÉFÉRENCE ........................................................................................ 501 
1.1. Abréviations ........................................................................................................................... 501 
1.2. Nor mes de référence ................................................................................................................. 501 
2. CARA CTÉRISTIQUES GÉNÉRALES ET FONCTIONS DE L'AD APT ATEUR ............................................................. 502 
2.1. Descr iption générale de l'adaptat eur .............................................................................................. 502 
2.2. Fonctions ............................................................................................................................... 502 
2.3. Sécur ité.................................................................................................................................. 502 
3. EXIGENCES REL ATIVES À L'APP AREIL DE CON TRÔLE LORSQU'UN ADAPT ATEUR EST INST ALLÉ .......................... 502 
4. EXIGENCES DE CONSTR UCTION ET DE FONCTIONNEMENT DE L'AD APT ATEUR ............................................... 503 
4.1. Connexion et adap tation des impulsions de vitesse entrante s.............................................................. 503 
4.2. Orientation des impulsions entrantes vers le capt eur de mouvement intégré ......................................................... 503 
4.3. Capt eur de mouvement intégré ................................................................................................................. 503 
4.4. Exigence s de sécur ité................................................................................................................. 503 
4.5. Caractéristi ques de perf ormance .................................................................................................. 504 
4.6. Matéri aux ............................................................................................................................... 504 
4.7. Inscr iptions ............................................................................................................................. 504 
5. INST ALL ATION DE L'APP AREIL DE CON TRÔLE LORSQU'UN ADAPT ATEUR EST UTILISÉ ..................................... 504 
5.1. Installation ............................................................................................................................. 504 
5.2. Scellement .............................................................................................................................. 505 
6. CONTRÔLES, INSPECTIONS ET RÉPARA TIONS ........................................................................................... 505 
6.1. Inspections périodiques ............................................................................................................. 505 
7. HOMOLOGA TION DE L'APP AREIL DE CONTRÔLE LORSQU'UN ADAPT ATEUR EST UTILISÉ ................................. 505 
7.1. Points généraux ....................................................................................................................... 505 
7.2. Certificat fonctionnel ................................................................................................................ 506  
1.  ABRÉVIA TIONS ET DOCUMENTS DE RÉFÉRENCE 
1.1.  Abréviations 
À déf.  À définir 
VU  Unit é embarquée sur le véhicule (Vehicle Unit) 
1.2.  Nor mes de référence 
ISO 16844-3 Véhicules routiers — Systèmes tach ygraphiques — Partie 3: Interface des capt eurs de mouvement 26.5.2016 L 139/501 Jour nal officiel de l'Union européenne FR     
2.  CARA CTÉRISTIQUES GÉNÉRALES ET FONCTIONS DE L'AD APT ATEUR 
2.1.  Descr iption générale de l'adapt ateur 
ADA_001  L'adap tateur fournit une VU connectée avec des données de mouvement sécur isées représentatives de 
la vitesse du véhicule et de la distance parcour ue. 
L'adap tateur est conçu uniquement pour les véhicules qui doivent être munis d'un appareil de contrôle 
conf ormément au présent règlement. 
Il est installé et utilisé uniquement dans les types de véhicule définis au point yy) «adaptat eur», lorsqu'il 
n'est pas mécaniquement possible d'installer un autre type de capt eur de mouvement existant 
conf orme par ailleurs aux dispositions de la présent e annexe et de ses appendices 1 à 16. 
L'adap tateur n'est pas mécaniquement connecté à un élément mobile du véhicule mais connecté aux 
impulsions de vites se/distance produites par des capt eurs intégrés ou d'autres interf aces. 
ADA_002  Un capt eur de mouvement homologué (conf ormément aux dispositions de la présente annexe IC, 
section 8 — Homologation de l'appareil de contrôle et des cartes tach ygraphiques) est installé dans le 
boîtier de l'adaptat eur, qui compo rte également un conver tisseur d'im pulsions générant des impulsions 
entrante s dirigées vers le capt eur de mouvement intégré. Le capt eur de mouvement intégré lui-même 
est connecté à la VU, si bien que l'interface entre la VU et l'adaptat eur est conf orme aux exigences de 
la norme ISO 16844-3. 
2.2.  Fonctions 
ADA_003  L'adap tateur compo rte les fonctions suivantes: 
—  interfaçag e et adaptation des impulsions de vitesse entrantes; 
—  orientation des impulsions entrante s vers le capt eur de mouvement intégré; 
—  tout es les fonctions du capt eur de mouvement intégré , fournissant des données de mouvement 
sécur isées à la VU. 
2.3.  Sécur ité 
ADA_004  La sécur ité de l'adaptat eur n'est pas certifiée conf orme aux objectifs de sécur ité génér ique du capt eur 
de mouvement définis à l'appendice 10 de la présent e annex e, mais conf orme aux exigences de 
sécur ité spécifiées au point 4.4 du présent appendice. 
3.  EXIGENCES REL ATIVES À L'APP AREIL DE CON TRÔLE LORSQU'UN ADAPT ATEUR EST INST ALLÉ 
Les exige nces figurant dans le présent chapitre et dans les chapitres suivants indiquent comment les exigenc es 
énoncées dans la présente annexe doivent être compr ises lorsqu'un adapt ateur est utilisé. Les numéros des 
exigenc es concer nées sont indiqués entre parenthèses. 
ADA_005  L'appareil de contrôle de tout véhicule équipé d'un adap tateur doit être conf orme à tout es les 
dispositions de la présente annexe, sauf indications contraires dans le présent appendice. 
ADA_006  Lorsqu'un adaptat eur est installé, l'appareil de contrôle compo rte des câbles, l'adapta teur (comprenant 
un capt eur de mouvement) et une VU (01). 
ADA_007  La fonction de détec tion d'événements et/ou d'anomalies de l'appareil de contrôle est modifiée comme 
suit: 
—  l'événement «coupure d'alimentation» est déclench é par la VU, lorsqu'elle n'est pas en mode 
étalonnage, en cas d'interr upti on de l'alimentation électr ique du capt eur de mouvement intégré 
(79) dépassant 200 millisecondes (ms); 
—  l'événement «erreur sur les données de mouvement» est déclenché par la VU en cas d'interr upti on 
du flux de données normal entre le capt eur de mouvement intégré et la VU et/ou en cas 
d'anomalie d'intégr ité ou d'authentific ation de données au cours de l'échange de données entre le 
capt eur de mouvement intégré et la VU (83); 26.5.2016 L 139/502 Jour nal officiel de l'Union européenne FR     
—  l'événement «tentative d'atte inte à la sécur ité» est déclenché par la VU pour tout autre événement 
affectant la sécur ité du capt eur de mouvement intégré , lorsqu'il n'est pas en mode étalonnage (85), 
—  l'anomalie «appareil de contrôle» est déclenché e par la VU, lorsqu'elle n'est pas en mode 
étalonnage, pour tout e anomalie du capt eur de mouvement intégré (88). 
ADA_008  Les anomalies de l'adaptat eur détectables par l'appareil de contrôle sont celles liées au capt eur de 
mouvement intégré (88). 
ADA_009  La fonction d'étalonnag e de la VU permet de coupler automatique ment le capt eur de mouvement 
intégré à la VU (202, 204). 
4.  EXIGENCES DE CONSTR UCTION ET DE FONCTIONNEMENT DE L'AD APT ATEUR 
4.1.  Connexion et adaptati on des impulsions de vitesse entrantes 
ADA_011  L'inte rface d'entrée de l'adaptat eur accept e des impulsions de fréquences représentatives de la vites se du 
véhicule et de la distance parcour ue. Les caract éristiques électr iques des impulsions entrantes sont: à 
déf. par le fabricant. Les ajustements réalisables uniquement par le fabricant de l'adaptat eur et l'atelier 
agréé qui procède à l'installation de l'adaptat eur permettent le bon interfaçage de l'adaptat eur au 
véhicule, le cas éché ant. 
ADA_012  L'inte rface d'entrée de l'adaptat eur peut, le cas échéa nt, multiplier ou diviser les impulsions de 
fréquence des impulsions de vitesse entrante s par un facteur fixe pour adapt er le signal à la fourche tte 
de valeurs du facteur k définie dans la présente annexe (4 000 à 25 000 impulsions/km). Ce facteur 
fixe ne peut être programmé que par le fabricant de l'adaptat eur et l'ate lier agréé qui effectue l'instal ­
lation de l'adapta teur . 
4.2.  Orienta tion des impulsions entrantes vers le capteur de mouv ement intég ré 
ADA_013  Les impulsions entrantes, éventuellement adapt ées comme indiqué ci-dessus, sont orienté es vers le 
capt eur de mouvement intégré de manière que chaque impulsion entrante soit détect ée par le capt eur 
de mouvement. 
4.3.  Capteur de mouv ement intég ré 
ADA_014  Le capt eur de mouvement intégré est stimulé par les impulsions, ce qui lui permet de générer des 
données de mouvement représentant exactement les mouvements du véhicule, comme s'il était 
mécaniquement couplé à un élément mobile du véhicule. 
ADA_015  Les données d'identification du capt eur de mouvement intégré sont utilisées par la VU pour identif ier 
l'adaptat eur (95). 
ADA_016  Les données d'installation stoc kées dans le capt eur de mouvement intégré sont considérées comme 
représentant les données d'installation de l'adaptat eur (122). 
4.4.  Exigences de sécur ité 
ADA_017  Le boîtier de l'adaptat eur doit être inviolable. Il est scellé de manière à ce que tout e tentative de 
manipulation soit aisément décelable (par exem ple, lors d'une inspection visuelle, voir ADA_035). Les 
scellements répondent aux mêmes exigenc es que les scellements des capt eurs de mouvement 
(398 à 406) 
ADA_018  Il doit être impossible de retirer le capt eur de mouvement intégré de l'adaptat eur sans rom pre le(s) 
scellement(s) du boîtier de l'adaptat eur ni sans rompre le scellement entre le capt eur et le boîtier de 
l'adaptat eur (voir ADA_034). 
ADA_019  L'adap tateur garantit que les données de mouvement ne peuvent être traitées et extraites qu'à partir de 
l'entrée de l'adaptat eur. 26.5.2016 L 139/503 Jour nal officiel de l'Union européenne FR     
4.5.  Caractér istiques de perfor mance 
ADA_020  L'adap tateur fonctionne correctement dans la fourchett e de températures définie par le fabricant. 
ADA_021  L'adap tateur fonctionne correctement dans une fourche tte de taux d'humidit é allant de 10 % à 90 % 
(214). 
ADA_022  L'adap tateur est protég é contre les surtensions, l'invers ion de polar ités et les cour ts-circuits (216). 
ADA_023  L'adap tateur doit: 
—  soit réagir à un cham p magnétique qui perturbe la détection des mouvements du véhicule. Dans 
ces circonstances, l'unit é embarquée enregistrera et stoc kera une anomalie du capt eur (88), 
—  soit posséder un élément de détection qui soit protég é des cham ps magnétiques ou insensible à 
ceux-ci (217). 
ADA_024  L'adap tateur est conf orme à la réglementation internati onale R10 de la CEE-ONU, relative à la 
compati bilité électromagnétique, et est protég é contre les décharges électrostatiques et les transito ires 
(218). 
4.6.  Matér iaux 
ADA_025 L'adap tateur satisf ait au niveau de protect ion (à déf. par le fabricant, en fonction de la position de l'instal ­
lation) (220, 221). 
ADA_026  Le boîtier de l'adaptat eur est jaune. 
4.7.  Inscr iptions 
ADA_027  Une plaque signalétique est fixée sur l'adaptat eur et compo rte les indications suivantes: 
—  nom et adresse du fabr icant de l'adaptat eur; 
—  numéro de pièce du fabr icant et année de fabrication de l'adaptat eur; 
—  marque d'homolog ation du type d'adapta teur ou de l'appareil de contrôle incluant l'adaptat eur; 
—  date d'installation de l'adaptat eur; 
—  numéro d'identif ication du véhicule sur lequel il est installé. 
ADA_028  La plaque signalétique compo rte aussi les indications suivantes (si elles ne sont pas direct ement 
visibles de l'extér ieur du capt eur de mouvement intégré ): 
—  nom du fabricant du capt eur de mouvement intégré; 
—  numéro de pièce du fabr icant et année de fabrication du capt eur de mouvement intégré; 
—  marque d'homolog ation du capt eur de mouvement intégré. 
5.  INST ALL ATION DE L'APP AREIL DE CON TRÔLE LORSQU'UN ADAPT ATEUR EST UTILISÉ 
5.1.  Inst allation 
ADA_029  Les adaptat eurs à installer sur les véhicules le sont uniquement par des fabricants de véhicules ou par 
des ateliers agréés autori sés à installer , activer et calibrer les tach ygraphes numér iques et intellig ents. 
ADA_030  L'atelier agréé qui installe l'adaptat eur ajuste l'interface d'entrée et choisit le taux de division du signal 
d'entrée (le cas échéant). 26.5.2016 L 139/504 Jour nal officiel de l'Union européenne FR     
ADA_031  L'atelier agréé qui installe l'adaptat eur scelle le boîtier de l'adaptat eur. 
ADA_032  L'adap tateur est mont é aussi près que possible de la partie du véhicule qui lui fournit ses impulsions 
d'entrée. 
ADA_033  Les câbles fournissant l'alimentation de l'adaptat eur sont rouges (courant positif) et noirs (câbles de 
terre). 
5.2.  Scellement 
ADA_034  Les exigences suivantes en matière de scellement doivent être respectée s: 
—  le boîtier de l'adaptat eur est scellé (voir ADA_017); 
—  le boîtier du capt eur intégré est scellé au boîtier de l'adaptat eur, à moins qu'il ne soit pas possible 
de retirer le capt eur intégré sans rompre le(s) scellement(s) du boîtier de l'adaptat eur (voir 
ADA_018); 
—  le boîtier de l'adaptat eur est scellé au véhicule; 
—  la connexion entre l'adaptat eur et l'équipement qui lui fournit ses impulsions d'entrée est scellée 
aux deux extrémit és (dans la mesure où cela est raisonnablement possible). 
6.  CONTRÔLES, INSPECTIONS ET RÉPARA TIONS 
6.1.  Inspections périodiques 
ADA_035  Lorsqu'un adapt ateur est utilisé, chaque inspection périodique (conf ormément aux exigences 409 
à 413 de l'annex e 1C) de l'appareil de contrôle compo rte les vérifications suivante s: 
—  l'adaptat eur porte les marques d'homologation appropr iées; 
—  les scellements placés sur l'adaptat eur et ses connexions sont intacts; 
—  l'adaptat eur est installé comme indiqué sur la plaquette d'installation; 
—  l'adaptat eur est installé comme indiqué par le fabr icant de l'adaptat eur et/ou du véhicule; 
—  le montage d'un adap tateur est autor isé pour le véhicule inspect é. 
ADA_036  Ces inspections comprennent un étalonnage et un rem placement de tous les scellements, quel que soit 
leur état. 
7.  HOMOLOGA TION DE L'APP AREIL DE CONTRÔLE LORSQU'UN ADAPT ATEUR EST UTILISÉ 
7.1.  Points généraux 
ADA_037  L'appareil de contrôle est soumis pour homologation tout entier , muni de l'adaptat eur (425). 
ADA_038  Tout adap tateur peut être soumis pour homologation en tant que tel ou en tant que compo sant d'un 
appareil de contrôle. 
ADA_039  Cette homologat ion doit inclure des essais fonctionnels portant sur l'adaptat eur. Les résultats positifs 
de chacun de ces essais sont établis par un certificat appropr ié (426). 26.5.2016 L 139/505 Jour nal officiel de l'Union européenne FR     
7.2.  Cer tificat fonctionnel 
ADA_040  Le certificat fonctionnel de l'adaptat eur ou de l'appareil de contrôle compo rtant un adaptat eur n'est 
délivré au fabricant de l'adaptat eur que si les essais fonctionnels minimaux suivants ont été passés avec 
succès. 
No Essai Descr iption Exigences connex es 
1. Exa men administ ratif 
1.1 Documentation Exactitude de la documentation de l'adaptat eur  
2. Inspection visuelle 
2.1. Conf ormité de l'adaptat eur avec la documentation  
2.2. Identif ication / marquag es de l'adaptat eur ADA_027, ADA_028 
2.3 Matéri aux de l'adapta teur (219) à (223) 
ADA_026 
2.4. Scellement ADA_017, ADA_018, 
ADA_034 
3. Essais de fonctionnement 
3.1 Orientation des impulsions de vitesse vers le capt eur de mouvement intégré ADA_013 
3.2 Interfaçag e et adaptation des impulsions de vitesse entrantes ADA_011, ADA_012 
3.3 Précision de la mesure des mouvements (30) à (35), (217) 
4. Essais environnement aux 
4.1 Résultats des essais menés par 
le fabricant Résultats des essais environnementaux du fabri­
cant ADA_020, ADA_021, 
ADA_022, ADA_024 
5. Essais de compatibilité électromagnétique 
5.1 Émissions rayonnées et suscep ­
tibilité S'assurer de la conf ormité avec la directive 
2006/28/CE ADA_024 
5.2 Résultats des essais menés par 
le fabricant Résultats des essais environnementaux du fabri­
cant ADA_024   26.5.2016 L 139/506 Jour nal officiel de l'Union européenne FR