Ce texte constitue seulement un outil de documentation et n’a aucun effet juridique. Les institutions de l’Union déclinent 
toute responsabilité quant à son contenu. Les versions faisant foi des actes concernés, y compris leurs préambules, sont celles  
qui ont été publiées au Journal officiel de l’Union européenne et sont disponibles sur EUR-Lex. Ces textes officiels peuvent 
être consultés directement en cliquant sur les liens qui figurent dans ce document  
►B RÈGLEMENT D'EXÉCUTION (UE) 2016/799 DE LA COMMISSION  
du 18 mars 2016  
mettant en œuvre le règlement (UE) n  o 165/2014 du Parlement européen et du Conseil en ce qui 
concerne les exigences applicables à la construction, aux essais, à l'installation, à l'utilisation et à la 
réparation des tachygraphes et de leurs composants  
(Texte présentant de l'intérêt pour l'EEE)  
(JO L 139 du 26.5.2016, p. 1)  
Modifié par:  
Journal officiel  
n o page  date  
►M1 Règlement d’exécution (UE) 2018/502 de la Commission du 28 février 
2018  L 85  1  28.3.2018  
►M2 Règlement d’exécution (UE) 2020/158 de la Commission du 5 février 
2020  L 34  20  6.2.2020  
Rectifié par:  
►C1 Rectificatif, JO L 146 du 3.6.2016, p. 31 (2016/799)  
►C2 Rectificatif, JO L 27 du 1.2.2017, p. 169 (2016/799)  
►C3 Rectificatif, JO L 124 du 17.5.2017, p. 37 (2016/799)  
►C4 Rectificatif, JO L 215 du 19.8.2019, p. 3 (2016/799)  02016R0799 — FR — 26.02.2020 — 002.001 — 1
02016R0799 — FR — 26.02.2020 — 002.001 — 2  
RÈGLEMENT D'EXÉCUTION (UE) 2016/799 DE LA 
COMMISSION  
du 18 mars 2016  
mettant en œuvre le règlement (UE) n  o 165/2014 du Parlement 
européen et du Conseil en ce qui concerne les exigences 
applicables à la construction, aux essais, à l'installation, à 
l'utilisation et à la réparation des tachygraphes et de leurs 
composants  
(Texte présentant de l'intérêt pour l'EEE)  
Article premier  
Objet et champ d'application  
1. Le présent règlement arrête les dispositions nécessaires à l'appli ­
cation uniforme des aspects suivants relatifs aux tachygraphes:  
a) enregistrement de la position du véhicule à certains points au cours 
de la période de travail journalière du conducteur;  
b) détection précoce à distance d'une éventuelle manipulation ou utili ­
sation abusive des tachygraphes intelligents;  
c) interface avec les systèmes de transport intelligents;  
d) exigences administratives et techniques applicables aux procédures 
d'homologation des tachygraphes, y compris aux mécanismes de 
sécurité.  
▼M1 
2. La construction, les essais, l’installation, l’inspection, l’utilisation 
et la réparation des tachygraphes intelligents et de leurs composants sont 
conformes aux exigences techniques énoncées à l’annexe IC du présent 
règlement.  
3. Les tachygraphes autres que les tachygraphes intelligents conti ­
nuent, en matière de construction, d’essais, d’installation, d’inspection, 
d’utilisation et de réparation, de satisfaire aux exigences de l’annexe I 
du règlement (UE) n  o 165/2014 ou de l’annexe IB du règlement (CEE) 
n o 3821/85 du Conseil (  1 ), selon le cas.  
▼B 
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.  
▼M1 
5. Le présent règlement est sans préjudice de l’application de la 
directive 2014/53/UE du Parlement européen et du Conseil (  2 ). 
▼B 
Article 2  
Définitions  
Aux fins du présent règlement, les définitions établies à l'article 2 du 
règlement (UE) n  o 165/2014 s'appliquent.  ▼B 
( 1 ) Règlement (CEE) n  o 3821/85 du Conseil du 20 décembre 1985 concernant 
l’appareil de contrôle dans le domaine des transports par route (JO L 370 du 
31.12.1985, p. 8). 
( 2 ) Directive 2014/53/UE du Parlement européen et du Conseil du 16 avril 2014 
relative à l’harmonisation des législations des États membres concernant la 
mise à disposition sur le marché d’équipements radioélectriques et abrogeant 
la directive 1999/5/CE (JO L 153 du 22.5.2014, p. 62).
 02016R0799 — FR — 26.02.2020 — 002.001 — 3  
En outre, on entend par:  
1) «tachygraphe numérique» ou «tachygraphe de première généra ­
tion», un tachygraphe numérique autre qu'un tachygraphe intelli ­
gent;  
2) «dispositif GNSS externe», un dispositif contenant le récepteur 
GNSS lorsque l'unité embarquée sur le véhicule n'est pas une 
unité intégrée, ainsi que d'autres composants nécessaires à la protec ­
tion de la communication des données de position au reste de 
l'unité embarquée sur le véhicule;  
▼M1 
3) «dossier fabricant», le dossier complet, sous forme électronique ou 
imprimée, contenant toutes les informations fournies par le fabricant 
ou son mandataire à l’autorité d’homologation aux fins de l’homo ­
logation d’un tachygraphe ou d’un composant de tachygraphe, y 
compris les certificats visés à l’article 12, paragraphe 3, du règle ­
ment (UE) n  o 165/2014, l’exécution des essais définis à l’annexe IC 
du présent règlement, ainsi que les dessins, photographies et autres 
documents pertinents;  
▼B 
4) «dossier d'homologation», le dossier fabricant, sous forme électro ­
nique ou sur papier, accompagné de tous les autres documents que 
l'autorité d'homologation a adjoints au dossier fabricant dans l'exer ­
cice de ses fonctions, y compris, au terme de la procédure d'homo ­
logation, le certificat d'homologation CE du tachygraphe ou de son 
composant;  
5) «index du dossier d'homologation», le document présentant le 
contenu du dossier d'homologation selon une numérotation permet ­
tant 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;  
▼M1 
7) «tachygraphe intelligent» ou «tachygraphe de deuxième généra ­
tion», un tachygraphe numérique conforme aux articles 8, 9 et 10 
du règlement (UE) n  o 165/2014 ainsi qu’à l’annexe IC du présent 
règlement;  
8) «composant de tachygraphe», l’un des éléments suivants: l’unité 
embarquée sur le véhicule, le capteur de mouvement, la feuille 
d’enregistrement, le dispositif GNSS externe et le dispositif 
externe de détection précoce à distance;  
▼B 
9) «autorité d'homologation», l'autorité d'un État membre compétente 
pour effectuer l'homologation du tachygraphe ou de ses compo ­
sants, le processus d'autorisation, la délivrance et, le cas échéant, 
le retrait des certificats d'homologation, servant de point de contact 
pour les autorités d'homologation des autres États membres et veil ­
lant à ce que les fabricants remplissent leurs obligations de confor ­
mité aux exigences du présent règlement;  
▼M1 
10) «unité embarquée sur le véhicule», le tachygraphe à l’exclusion du 
capteur de mouvement et des câbles de connexion de ce capteur.  
Elle peut se présenter sous la forme d’un seul élément ou de 
plusieurs composants répartis dans le véhicule et comprend une 
unité de traitement, une mémoire électronique, une fonction de 
mesure du temps, deux interfaces pour cartes à mémoire pour le  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 4  
conducteur et le convoyeur, une imprimante, un écran, des connec ­
teurs ainsi que des dispositifs permettant la saisie de données par 
l’utilisateur, un récepteur GNSS et un dispositif de communication 
à distance.  
L’unité embarquée sur le véhicule peut se composer des éléments 
suivants soumis à homologation:  
— une unité composée d’un seul élément (intégrant un récepteur 
GNSS et un dispositif de communication à distance),  
— un élément principal (intégrant un dispositif de communication 
à distance) et un récepteur GNSS externe,  
— un élément principal (intégrant un récepteur GNSS) et un dispo ­
sitif de communication à distance externe,  
— un élément principal, un récepteur GNSS externe et un dispo ­
sitif de communication à distance externe.  
Si l’unité embarquée sur le véhicule se présente sous la forme de 
plusieurs éléments répartis dans le véhicule, son élément principal 
est celui qui comprend l’unité de traitement, la mémoire électro ­
nique et la fonction de mesure du temps.  
Le terme «unité embarquée sur le véhicule (VU)» désigne l’«unité 
embarquée sur le véhicule» ou l’«élément principal de l’unité 
embarquée sur le véhicule».  
▼B 
Article 3  
Services basés sur la localisation  
1. Les fabricants veillent à ce que les tachygraphes intelligents soient 
compatibles avec les services de positionnement fournis par les 
systèmes Galileo et EGNOS (système européen de navigation par recou ­
vrement géostationnaire).  
2. En plus des systèmes visés au paragraphe 1, les fabricants peuvent 
aussi décider d'assurer la compatibilité avec d'autres systèmes de navi ­
gation par satellite.  
Article 4  
Procédure d'homologation d'un tachygraphe et de composants de 
tachygraphe  
1. Le fabricant ou son mandataire soumet une demande d'homologa ­
tion du tachygraphe ou d'un de ses composants ou groupes de compo ­
sants aux autorités d'homologation désignées par chaque État membre. 
Cette demande se compose d'un dossier fabricant contenant les rensei ­
gnements relatifs à chacun des composants concernés, y compris, le cas 
échéant, les certificats d'homologation des autres composants nécessaires 
pour construire l'ensemble du tachygraphe, ainsi que tous les autres 
documents pertinents.  
2. L'État membre accorde l'homologation à tout tachygraphe, compo ­
sant ou groupe de composants qui est conforme aux exigences adminis ­
tratives et techniques visées à l'article 1  er , paragraphe 2 ou 3, selon le 
cas. Dans ce cas, l'autorité d'homologation délivre au demandeur un 
certificat d'homologation conforme au modèle figurant à l'annexe II 
du présent règlement.  
3. L'autorité d'homologation peut demander au fabricant ou à son 
mandataire de fournir des informations complémentaires.  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 5  
4. Le fabricant ou son mandataire met à la disposition des autorités 
d'homologation, ainsi que des entités chargées de la délivrance des 
certificats visés à l'article 12, paragraphe 3, du règlement (UE) 
n o 165/2014, le nombre de tachygraphes ou de composants de tachy ­
graphe nécessaire pour leur permettre de mener à bien la procédure 
d'homologation.  
5. Si le fabricant ou son mandataire sollicite l'homologation de 
certains composants ou groupes de composants d'un tachygraphe, il 
fournit aux autorités d'homologation les autres éléments déjà homolo ­
gués et les autres éléments nécessaires à la construction de l'ensemble 
du tachygraphe afin de permettre à ces autorités d'effectuer les essais 
nécessaires.  
Article 5  
Modification des homologations  
1. Le fabricant ou son mandataire informe sans tarder les autorités 
d'homologation qui ont accordé l'homologation initiale de toute modifi ­
cation apportée au logiciel ou au matériel du tachygraphe ou à la nature 
des matériaux employés pour sa fabrication qui sont enregistrés dans le 
dossier d'homologation et présente une demande de modification de 
l'homologation.  
2. Les autorités d'homologation peuvent réviser ou étendre une 
homologation existante ou en délivrer une nouvelle en fonction de la 
nature et des caractéristiques de la modification.  
Une «révision» est effectuée lorsque l'autorité d'homologation considère 
que les modifications apportées au logiciel ou au matériel du tachy ­
graphe ou à la nature des matériaux employés pour sa fabrication 
sont mineures. En pareil cas, l'autorité d'homologation délivre les docu ­
ments révisés du dossier d'homologation indiquant la nature des modi ­
fications effectuées et la date de leur approbation. Une version actua ­
lisée du dossier d'homologation sous forme consolidée, accompagnée 
d'une description détaillée des modifications effectuées, est suffisante 
pour satisfaire à cette exigence.  
Une «extension» est effectuée lorsque l'autorité d'homologation consi ­
dère que les modifications apportées au logiciel ou au matériel du 
tachygraphe ou à la nature des matériaux employés pour sa fabrication 
sont importantes. En pareil cas, elle peut demander que de nouveaux 
essais soient effectués et en informe le fabricant ou son mandataire. Si 
ces essais sont satisfaisants, l'autorité d'homologation délivre un certi ­
ficat d'homologation révisé portant un numéro correspondant à l'exten ­
sion accordée. Le certificat d'homologation mentionne le motif de l'ex ­
tension ainsi que sa date de délivrance.  
3. L'index du dossier d'homologation indique la date de l'extension 
ou de la révision la plus récente de l'homologation ou la date de la 
consolidation la plus récente de la version actualisée de l'homologation.  
4. Une nouvelle homologation est nécessaire au cas où les modifica ­
tions concernées du tachygraphe homologué ou de ses composants 
conduiraient à la délivrance d'un nouveau certificat de sécurité ou d'in ­
teropérabilité.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 6  
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 à compter du 2 mars 2016.  
▼M1 
Toutefois, l’annexe IC s’applique à compter du 15 juin 2019, à l’ex ­
ception de l’appendice 16, qui s’applique à compter du 2 mars 2016.  
▼B 
Le présent règlement est obligatoire dans tous ses éléments et directe ­
ment applicable dans tout État membre.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 7  
ANNEXE I C  
Exigences de construction, d'essai, d'installation et de contrôle  
INTRODUCTION  
1 DÉFINITIONS  
2 CARACTÉRISTIQUES GÉNÉRALES ET FONCTIONS DE 
L'APPAREIL DE CONTRÔLE  
2.1 Caractéristiques générales  
2.2 Fonctions  
2.3 Modes de fonctionnement  
2.4 Sécurité  
3 EXIGENCES CONSTRUCTIVES ET FONCTIONNELLES 
APPLICABLES À L'APPAREIL DE CONTRÔLE  
3.1 Suivi de l'insertion et du retrait des cartes  
3.2 Mesure de la vitesse, de la position et de la distance parcourue  
3.2.1 Mesure de la distance parcourue  
3.2.2 Mesure de la vitesse  
3.2.3 Mesure de la position  
3.3 Mesure du temps  
3.4 Surveillance des activités du conducteur  
3.5 Surveillance de l'état de conduite  
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 jour ­ 
nalière  
3.6.2 Saisie manuelle des activités du conducteur et consentement du 
conducteur pour l'interface ITS  
3.6.3 Saisie de conditions particulières  
3.7 Gestion des dispositifs de verrouillage de l'entreprise  
3.8 Suivi des activités de contrôle  
3.9 Détection d'événements et/ou d'anomalies  
3.9.1 Événement «Insertion d'une carte non valable»  
3.9.2 Événement «Conflit de carte»  
3.9.3 Événement «Chevauchement temporel»  
3.9.4 Événement «Conduite sans carte appropriée»  
3.9.5 Événement «Insertion d'une carte en cours de conduite»  
3.9.6 Événement «Dernière session incorrectement clôturée»  
3.9.7 Événement «Excès de vitesse»  
3.9.8 Événement «Interruption de l'alimentation électrique»  
3.9.9 Événement «Erreur de communication avec le dispositif de 
communication à distance»  
3.9.10 Événement «Absence d'informations de positionnement en prove ­ 
nance du récepteur GNSS»  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 8  
3.9.11 Événement «Erreur de communication avec le dispositif GNSS 
externe»  
3.9.12 Événement «Erreur sur les données de mouvement»  
3.9.13 Événement «Conflit concernant le mouvement du véhicule»  
3.9.14 Événement «Tentative d'atteinte à la sécurité»  
3.9.15 Événement «Conflit temporel»  
3.9.16 Anomalie «Carte»  
3.9.17 Anomalie «Appareil de contrôle»  
3.10 Autotests intégrés  
3.11 Lecture de la mémoire  
3.12 Enregistrement et stockage dans la mémoire  
3.12.1 Données d'identification de l'appareil  
3.12.1.1 Données d'identification de l'unité embarquée sur le véhicule  
3.12.1.2 Données d'identification du capteur de mouvement  
3.12.1.3 Données d'identification des systèmes mondiaux de navigation par 
satellite (Global Navigation Satellite Systems)  
3.12.2 Clés et certificats  
3.12.3 Données d'insertion et de retrait de la carte du conducteur ou de 
l'atelier  
3.12.4 Données relatives à l'activité du conducteur  
▼M1 
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 heures de temps de 
conduite accumulé sont atteintes  
▼B 
3.12.6 Données relatives au kilométrage  
3.12.7 Données détaillées relatives à la vitesse  
3.12.8 Données relatives aux événements  
3.12.9 Données relatives aux anomalies  
3.12.10 Données d'étalonnage  
3.12.11 Données de remise à l'heure  
3.12.12 Données d'activité de contrôle  
3.12.13 Données relatives aux verrouillages d'entreprise  
3.12.14 Données relatives au téléchargement  
3.12.15 Données concernant les conditions particulières  
3.12.16 Données relatives à la carte tachygraphique  
3.13 Lecture des cartes tachygraphiques  
3.14 Enregistrement et stockage sur cartes tachygraphiques  
3.14.1 Enregistrement et stockage sur les cartes tachygraphiques de 
première génération  
3.14.2 Enregistrement et stockage sur les cartes tachygraphiques de 
deuxième génération  
3.15 Affichage  
3.15.1 Affichage par défaut  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 9  
3.15.2 Affichage d'avertissements  
3.15.3 Menu d'accès  
3.15.4 Autres affichages  
3.16 Impression  
3.17 Avertissements  
3.18 Téléchargement de données à destination de supports externes  
3.19 Communication à distance pour les contrôles routiers ciblés  
3.20 Données transmises à des dispositifs externes supplémentaires  
3.21 Étalonnage  
3.22 Contrôles routiers d'étalonnage  
3.23 Remise à l'heure  
3.24 Caractéristiques de performance  
3.25 Matériaux  
3.26 Inscriptions  
4 EXIGENCES DE FABRICATION ET EXIGENCES FONCTION ­ 
NELLES APPLICABLES AUX CARTES TACHYGRAPHIQUES  
4.1 Données visibles  
4.2 Sécurité  
4.3 Normes  
4.4 Spécifications environnementales et électriques  
4.5 Stockage des données  
4.5.1 Fichiers élémentaires pour l'identification et la gestion des cartes  
4.5.2 Identification des cartes à circuit intégré  
4.5.2.1 Identification du microprocesseur  
4.5.2.2 DIR (uniquement présent sur les cartes tachygraphiques de 
deuxième génération)  
4.5.2.3 Informations ATR (conditionnelles, présentes uniquement sur les 
cartes tachygraphiques de deuxième génération)  
4.5.2.4 Informations relatives à la période étendue (conditionnelles, 
présentes uniquement sur les cartes tachygraphiques de deuxième 
génération)  
4.5.3 Carte de conducteur  
4.5.3.1 Application tachygraphique (accessible aux unités embarquées de 
première et deuxième générations)  
4.5.3.1.1 Identification des applications  
4.5.3.1.2 Clés et certificats  
4.5.3.1.3 Identification de carte  
4.5.3.1.4 Identification du détenteur de la carte  
4.5.3.1.5 Téléchargement (download) d'une carte  
4.5.3.1.6 Renseignements concernant le permis de conduire  
4.5.3.1.7 Données relatives aux événements  
4.5.3.1.8 Données relatives aux anomalies  
4.5.3.1.9 Données relatives aux activités du conducteur  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 10  
4.5.3.1.10 Données concernant les véhicules utilisés  
4.5.3.1.11 Lieux de début/de fin des périodes journalières de travail  
4.5.3.1.12 Données concernant les sessions pour chaque carte  
4.5.3.1.13 Données relatives aux activités de contrôle  
4.5.3.1.14 Données concernant les conditions particulières  
4.5.3.2 Application tachygraphique de deuxième génération (non accessible 
aux VU de première génération)  
4.5.3.2.1 Identification des applications  
4.5.3.2.2 Clés et certificats  
4.5.3.2.3 Identification de carte  
4.5.3.2.4 Identification du détenteur de la carte  
4.5.3.2.5 Téléchargement (download) d'une carte  
4.5.3.2.6 Renseignements concernant le permis de conduire  
4.5.3.2.7 Données relatives aux événements  
4.5.3.2.8 Données relatives aux anomalies  
4.5.3.2.9 Données relatives aux activités du conducteur  
4.5.3.2.10 Données concernant les véhicules utilisés  
4.5.3.2.11 Lieux et positions de début/fin des périodes journalières de travail  
4.5.3.2.12 Données concernant les sessions pour chaque carte  
4.5.3.2.13 Données relatives aux activités de contrôle  
4.5.3.2.14 Données concernant les conditions particulières  
4.5.3.2.15 Données concernant les unités embarquées sur véhicule qui ont été 
utilisées  
▼M1 
4.5.3.2.16 Données relatives aux lieux où les trois heures de temps de 
conduite accumulé ont été atteintes  
▼B 
4.5.4 Carte d'atelier  
4.5.4.1 Application tachygraphique (accessible aux unités embarquées de 
première et deuxième générations)  
4.5.4.1.1 Identification des applications  
4.5.4.1.2 Clés et certificats  
4.5.4.1.3 Identification de carte  
4.5.4.1.4 Identification du détenteur de la carte  
4.5.4.1.5 Téléchargement (download) d'une carte  
4.5.4.1.6 Données concernant l'étalonnage et la remise à l'heure  
4.5.4.1.7 Données relatives aux événements et aux anomalies  
4.5.4.1.8 Données relatives aux activités du conducteur  
4.5.4.1.9 Données concernant les véhicules utilisés  
4.5.4.1.10 Données concernant le début et/ou la fin des périodes de travail 
journalières  
4.5.4.1.11 Données concernant les sessions pour chaque carte  
4.5.4.1.12 Données relatives aux activités de contrôle  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 11  
4.5.4.1.13 Données concernant les conditions particulières  
4.5.4.2 Application tachygraphique de deuxième génération (non accessible 
aux VU de première génération)  
4.5.4.2.1 Identification des applications  
4.5.4.2.2 Clés et certificats  
4.5.4.2.3 Identification de carte  
4.5.4.2.4 Identification du détenteur de la carte  
4.5.4.2.5 Téléchargement (download) d'une carte  
4.5.4.2.6 Données concernant l'étalonnage et la remise à l'heure  
4.5.4.2.7 Données relatives aux événements et aux anomalies  
4.5.4.2.8 Données relatives aux activités du conducteur  
4.5.4.2.9 Données concernant les véhicules utilisés  
4.5.4.2.10 Données concernant le début et/ou la fin des périodes de travail 
journalières  
4.5.4.2.11 Données concernant les sessions pour chaque carte  
4.5.4.2.12 Données relatives aux activités de contrôle  
4.5.4.2.13 Données concernant les unités embarquées sur véhicule qui ont été 
utilisées  
▼M1 
4.5.4.2.14 Données relatives aux lieux où les trois heures de temps de 
conduite accumulé ont été atteintes  
▼B 
4.5.4.2.15 Données concernant les conditions particulières  
4.5.5 Carte de contrôleur  
4.5.5.1 Application tachygraphique (accessible aux unités embarquées de 
première et deuxième générations)  
4.5.5.1.1 Identification des applications  
4.5.5.1.2 Clés et certificats  
4.5.5.1.3 Identification de carte  
4.5.5.1.4 Identification du détenteur de la carte  
4.5.5.1.5 Données relatives aux activités de contrôle  
4.5.5.2 Application tachygraphique de deuxième génération (non accessible 
aux VU de première génération)  
4.5.5.2.1 Identification des applications  
4.5.5.2.2 Clés et certificats  
4.5.5.2.3 Identification de carte  
4.5.5.2.4 Identification du détenteur de la carte  
4.5.5.2.5 Données relatives aux activités de contrôle  
4.5.6 Carte d'entreprise  
4.5.6.1 Application tachygraphique (accessible aux unités embarquées de 
première et deuxième générations)  
4.5.6.1.1 Identification des applications  
4.5.6.1.2 Clés et certificats  
4.5.6.1.3 Identification de carte  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 12  
4.5.6.1.4 Identification du détenteur de la carte  
4.5.6.1.5 Données concernant l'activité de l'entreprise  
4.5.6.2 Application tachygraphique de deuxième génération (non accessible 
aux VU de première génération)  
4.5.6.2.1 Identification des applications  
4.5.6.2.2 Clés et certificats  
4.5.6.2.3 Identification de carte  
4.5.6.2.4 Identification du détenteur de la carte  
4.5.6.2.5 Données concernant l'activité de l'entreprise  
5 INSTALLATION DE L'APPAREIL DE CONTRÔLE  
5.1 Installation  
5.2 Plaquette d'installation  
5.3 Scellement  
6 CONTRÔLES, INSPECTIONS ET RÉPARATIONS  
6.1 Agrément des installateurs, des ateliers et des constructeurs de 
véhicules  
▼M1 
6.2 Vérification de composants neufs ou réparés  
▼B 
6.3 Inspection de l'installation  
6.4 Inspections périodiques  
6.5 Détermination des erreurs  
6.6 Réparations  
7 DÉLIVRANCE DES CARTES  
8 HOMOLOGATION DE L'APPAREIL DE CONTRÔLE ET DES 
CARTES TACHYGRAPHIQUES  
8.1 Points généraux  
8.2 Certificat de sécurité  
8.3 Certificat de fonctionnement  
8.4 Certificat d'interopérabilité  
8.5 Certificat d'homologation  
8.6 Procédure exceptionnelle: les premiers certificats d'interopérabilité 
pour des unités de contrôle et des cartes tachygraphiques de 
deuxième génération  
INTRODUCTION  
Le tachygraphe numérique de première génération est déployé depuis le 1  er mai 
2006. Il peut servir jusqu'à la fin de sa durée de vie pour le transport national. En 
revanche, pour le transport international, 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 tachygraphe intelligent de deuxième génération conforme au sens du 
présent règlement.  
La présente annexe contient les exigences relatives aux appareils de contrôle et 
cartes tachygraphiques 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 immatriculés pour la première fois et des cartes tachygraphiques de 
deuxième génération devront être délivrées.  
Afin de favoriser une mise œuvre sans heurts du tachygraphe de deuxième 
génération:  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 13  
— les cartes tachygraphiques 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 tachygraphiques 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 conducteur 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'atelier de deuxième génération.  
La présente annexe contient toutes les exigences liées à l'interopérabilité entre les 
tachygraphes 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 coexis ­
tence des deux systèmes doit être gérée.  
Liste des appendices  
App 1: DICTIONNAIRE DE DONNÉES  
App 2: SPÉCIFICATION DES CARTES TACHYGRAPHIQUES  
App 3: PICTOGRAMMES  
App 4: TIRAGES PAPIER  
App 5: AFFICHAGE  
App 6: CONNECTEUR FRONTAL POUR L'ÉTALONNAGE ET LE 
TÉLÉCHARGEMENT  
App 7: PROTOCOLES DE TÉLÉCHARGEMENT DE DONNÉES  
App 8: PROTOCOLE D'ÉTALONNAGE  
App 9: HOMOLOGATION ET LISTE DES ESSAIS MINIMAUX 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 
NAVIGATION PAR SATELLITE (GNSS)  
App 13: INTERFACE ITS  
App 14: FONCTION DE COMMUNICATION À DISTANCE  
App 15: MIGRATION: GÉRER LA COEXISTENCE DE PLUSIEURS 
GÉNÉRATIONS D'ÉQUIPEMENTS  
App 16: ADAPTATEUR POUR LES VÉHICULES DES TYPES M 1 ET N1  
1. DÉFINITIONS  
Dans la présente annexe, on entend par:  
a) «activation»:  
la phase au cours de laquelle le tachygraphe devient pleine ­
ment opérationnel et toutes les fonctions sont mises en œuvre, 
y compris les fonctions de sécurité, au moyen d'une carte 
d'atelier;  
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écutables sur demande, par une action de l'opé ­
rateur ou d'un dispositif externe;  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 14  
e) «jour civil»:  
une journée allant de minuit à minuit (24 heures). Tous les 
jours civils sont liés à l'heure universelle coordonnée (UTC);  
f) «étalonnage» d'un tachygraphe intelligent signifie:  
la mise à jour ou la confirmation des paramètres du véhicule à 
conserver en mémoire. Les paramètres du véhicule compren ­
nent l'identification du véhicule [numéro d'identification 
(VIN), numéro d'immatriculation (VRN) et État membre d'im ­
matriculation] et les caractéristiques du véhicule [w, k, l, taille 
des pneumatiques, réglage du limiteur de vitesse (le cas 
échéant), heure UTC, kilométrage]; pendant l'étalonnage d'un 
appareil de contrôle, les types et les identifiants des scelle ­
ments pertinents pour l'homologation doivent également être 
stockés en mémoire;  
toute mise à jour ou confirmation 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'exigence 
409; 
l'étalonnage d'un appareil de contrôle nécessite l'utilisation 
d'une carte d'atelier;  
g) «numéro de carte»:  
un code alphanumérique à 16 positions constituant le numéro 
d'identification unique d'une carte tachygraphique dans un État 
membre; ce numéro comporte un indice séquentiel de la carte 
(le cas échéant), un indice de remplacement 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 14  e caractère alphanumérique du numéro de carte, utilisé 
pour différencier les cartes délivrées à une entreprise, un 
atelier ou une autorité de contrôle habilité à recevoir plusieurs 
cartes tachygraphiques. L'entreprise, l'atelier ou l'autorité de 
contrôle est identifié(e) par les 13 premières positions du 
numéro de carte;  
i) «indice de renouvellement de la carte»:  
le 16  e caractère alphanumérique du numéro de carte, incré ­
menté à chaque renouvellement de la carte du tachygraphe;  
j) «indice de remplacement de la carte»:  
le 15  e caractère alphanumérique du numéro de carte, incré ­
menté à chaque remplacement de la carte tachygraphique;  
k) «coefficient caractéristique du véhicule»:  
la caractéristique numérique donnant la valeur du signal de 
sortie émis par la partie du véhicule qui relie celui-ci à l'ap ­
pareil 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 coefficient caractéristique est 
exprimé en impulsions par kilomètre (w = … imp/km);  
l) «carte d'entreprise»:  
une carte tachygraphique délivrée par les autorités d'un État 
membre à une entreprise de transport tenue d'utiliser des véhi ­
cules équipés d'un tachygraphe, ladite carte permettant l'iden ­
tification de l'entreprise de transport ainsi que l'affichage, le 
téléchargement et l'impression des données stockées dans le 
tachygraphe, lesquelles données ont été verrouillées par cette 
même entreprise;  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 15  
m) «constante de l'appareil de contrôle»:  
la caractéristique numérique donnant la valeur du signal d'en ­
trée nécessaire pour indiquer et enregistrer une distance 
parcourue d'un kilomètre; cette constante est exprimé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 DISPONIBI ­
LITÉ ou de PAUSE/REPOS ou INCONNUE (  2 ) de 45 minutes 
ou plus [cette période peut avoir été divisée conformément au 
règlement (CE) n  o 561/2006 du Parlement européen et du 
Conseil (  3 )]. Les calculs tiennent compte, 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 lecteur pertinent;  
o) «carte de contrôleur»:  
une carte tachygraphique délivrée par les autorités d'un État 
membre à une autorité nationale de contrôle compétente, ladite 
carte permettant l'identification de l'organisme de contrôle et, 
facultativement, de l'agent de contrôle, ainsi que l'accès aux 
données stockées dans la mémoire ou sur les cartes de conduc ­
teur et, facultativement, sur les cartes d'atelier, pour lecture, 
impression et/ou téléchargement;  
elle donne également accès à la fonction de contrôle de l'éta ­
lonnage routier et aux données se trouvant sur le lecteur de 
communication de détection 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 accumu ­
lées par un conducteur donné, depuis la fin de sa dernière 
période de DISPONIBILITÉ ou PAUSE/REPOS ou INCON ­
NUE (  3 ) de 45 minutes ou plus [cette période peut avoir été 
divisée conformément au règlement (CE) n  o 561/2006.]  
Les calculs tiennent compte, en tant que de besoin, des acti ­
vités antérieures enregistrées sur la carte de conducteur. Les 
périodes inconnues de durée négative (début de la période 
inconnue > fin de la période inconnue) en raison de chevau ­
chements temporels entre deux appareils de contrôle différents 
ne sont pas prises en compte dans les calculs.  ▼B 
( 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'avertissement relatif au temps de travail 
continu. Il ne préjuge pas l'interprétation légale de ces temps. D'autres modes de calcul 
du temps de travail continu et du temps de pause cumulé peuvent être utilisés pour 
remplacer ces définitions si celles-ci ont été rendues obsolètes par la mise à jour d'autres 
instruments législatifs applicables. 
( 2 ) Les périodes INCONNUES 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 conducteur n'a été effectuée. 
( 3 ) Règlement (CE) n  o 561/2006 du Parlement européen et du Conseil du 15 mars 2006 
relatif à l'harmonisation de certaines dispositions de la législation sociale dans le domaine 
des transports par route, modifiant les règlements (CEE) n  o 3821/85 et (CE) n  o 2135/98 
du Conseil et abrogeant le règlement (CEE) n  o 3820/85 du Conseil (JO L 102 du 
11.4.2006, p. 1).
 02016R0799 — FR — 26.02.2020 — 002.001 — 16  
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 correspon ­
dant au lecteur pertinent;  
q) «mémoire»:  
un dispositif de stockage de données électroniques installé 
dans l'appareil de contrôle;  
r) «signature numérique»:  
les données attachées à un bloc de données, ou une trans ­
formation cryptographique de celui-ci, qui permettent à son 
destinataire d'avoir la preuve de son authenticité et de son 
intégrité;  
s) «téléchargement»:  
la copie, avec signature numérique, 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 
tachygraphique, pour autant que ce processus ne modifie ni ne 
supprime aucune des données stockées;  
les fabricants d'unités embarquées de tachygraphes intelligents 
et les fabricants d'équipements conçus pour télécharger des 
fichiers de données prennent toutes les dispositions appro ­
priées, dans la mesure du raisonnable, pour que les entreprises 
de transport ou les conducteurs puissent effectuer le téléchar ­
gement de ces données dans les meilleurs délais.  
Il se peut que le téléchargement du fichier de relevés détaillés 
de la vitesse ne soit pas nécessaire pour établir la conformité 
avec le règlement (CE) n  o 561/2006, mais il peut servir à 
d'autres fins, notamment à des fins d'enquête dans le cadre 
d'un accident  
t) «carte de conducteur»:  
une carte tachygraphique délivrée par les autorités d'un État 
membre à un conducteur. La carte tachygraphique permet 
l'identification du conducteur et le stockage des données rela ­
tives à son activité;  
u) «circonférence effective des roues»:  
la moyenne des distances parcourues par chacune des roues 
entraînant le véhicule (roues motrices) 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'exigence 
414 et est exprimée sous la forme «l = … mm». Les construc ­
teurs de véhicules peuvent remplacer la mesure de ces 
distances par un calcul théorique tenant compte de la réparti ­
tion du poids du véhicule sur les essieux, à vide et en ordre de 
marche (  1 ). Les méthodes suivies pour effectuer ce calcul théo ­
rique devront être approuvées par une autorité compétente de 
l'État membre et ne pourront s'appliquer qu'avant l'activation 
du tachygraphe;  
v) «événement»:  
une opération anormale détectée par le tachygraphe intelligent 
et pouvant résulter d'une tentative de fraude;  
w) «dispositif GNSS externe»:  
un dispositif contenant le récepteur 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;  ▼B 
( 1 ) Règlement (UE) n  o 1230/2012 de la Commission du 12 décembre 2012 portant appli ­
cation du règlement (CE) n  o 661/2009 du Parlement européen et du Conseil en ce qui 
concerne les prescriptions pour la réception par type relatives aux masses et dimensions 
des véhicules à moteur 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.
 02016R0799 — FR — 26.02.2020 — 002.001 — 17  
x) «anomalie»:  
une opération anormale détectée par le tachygraphe intelligent 
et pouvant résulter d'un dysfonctionnement ou d'une panne de 
l'appareil;  
y) «récepteur GNSS»:  
un dispositif électronique qui reçoit et traite numériquement 
les signaux émis par un ou plusieurs systèmes mondiaux de 
navigation par satellite (GNSS en anglais) afin de déterminer 
la position, la vitesse et l'heure;  
z) «installation»:  
le montage d'un tachygraphe dans un véhicule;  
aa) «interopérabilité»:  
la capacité des systèmes et des processus sous-jacents à 
échanger 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'interagir;  
cc) «position»  
les coordonnées géographiques du véhicule à un moment 
donné;  
dd) «capteur de mouvement»:  
un élément du tachygraphe émettant un signal représentatif de 
la vitesse et/ou de la distance parcourue par le véhicule;  
ee) «carte non valable»:  
une carte détectée comme présentant un défaut, ou dont l'au ­
thentification initiale a échoué, ou dont la date de début de 
validité n'a pas encore été atteinte, ou dont la date d'expiration 
est passée;  
ff) «norme ouverte»:  
une norme définie dans une spécification de norme librement 
accessible ou disponible contre une somme symbolique et qu'il 
est permis de copier, de diffuser ou d'utiliser gratuitement ou 
pour une somme symbolique;  
gg) «hors champ»:  
tous les cas où l'utilisation de l'appareil n'est pas requise, 
conformément au règlement (CE) n  o 561/2006;  
hh) «excès de vitesse»:  
le dépassement de la vitesse autorisée pour le véhicule, 
pendant toute période de plus de 60 secondes au cours de 
laquelle la vitesse mesurée du véhicule dépasse la limite 
fixée pour le réglage du dispositif de limitation de vitesse 
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 tachygraphe fonctionne correctement, que ses réglages 
correspondent aux paramètres du véhicule et qu'aucun dispo ­
sitif de manipulation n'est adjoint au tachygraphe;  ▼B 
( 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égories de véhicules à 
moteur (JO L 57 du 2.3.1992, p. 27).
 02016R0799 — FR — 26.02.2020 — 002.001 — 18  
jj) «imprimante»:  
un composant de l'appareil de contrôle qui permet d'imprimer 
les données stocké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étection précoce à distance lors de contrôles routiers ciblés 
afin de détecter à distance une éventuelle manipulation ou 
mauvaise utilisation de l'appareil de contrôle;  
▼M1 
ll) «dispositif de communication à distance» ou «dispositif de 
détection précoce à distance»:  
l’équipement de l’unité embarquée sur le véhicule utilisé pour 
les contrôles routiers ciblés;  
▼B 
mm) «lecteur 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 tachygraphique lorsqu'une 
carte arrive à expiration ou ne fonctionne pas correctement et 
a été retournée à l'autorité qui l'a délivrée; le renouvellement 
suppose la certitude que deux cartes en cours de validité ne 
coexistent pas;  
oo) «réparation»:  
toute réparation d'un capteur de mouvement, d'une unité 
embarquée ou d'un câble qui impose de le ou de la décon ­
necter de son alimentation électrique ou d'autres composants 
du tachygraphe, ou d'ouvrir le capteur de mouvement ou 
l'unité embarquée;  
pp) «remplacement de la carte»:  
la délivrance d'une carte tachygraphique en remplacement 
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'au ­
torité qui l'a délivrée; le remplacement comporte toujours le 
risque que deux cartes en cours de validité coexistent;  
qq) «certification de sécurité»:  
le processus consistant à certifier, par un organisme de certi ­
fication «critères communs», que l'appareil de contrôle (ou le 
composant de cet appareil) ou la carte tachygraphique satisfait 
aux exigences de sécurité définies dans les profils de protec ­
tion correspondants;  
rr) «autotest»:  
les tests automatiques effectués périodiquement par l'appareil 
de contrôle afin de déceler les anomalies;  
ss) «mesure du temps»:  
un enregistrement numérique en continu de la date et du temps 
universel coordonné (UTC);  
▼M1 
tt) «remise à l’heure»:  
un réglage de l’heure actuelle; ce réglage peut être exécuté de 
manière automatique à intervalles réguliers, sur la base de 
l’heure fournie par le récepteur GNSS, ou être effectué en 
mode «étalonnage»;  
▼B 
uu) «dimension des pneumatiques»:  
la désignation des dimensions des pneumatiques (roues 
motrices externes) conformément à la directive 92/23/CEE 
du Conseil (  1 ), telle que modifiée en dernier lieu;  ▼B 
( 1 ) Directive 92/23/CEE du Conseil du 31 mars 1992 relative aux pneumatiques des véhi ­
cules à moteur et de leurs remorques ainsi qu'à leur montage (JO L 129 du 14.5.1992, 
p. 95).
 02016R0799 — FR — 26.02.2020 — 002.001 — 19  
vv) «identification du véhicule»:  
les numéros permettant d'identifier le véhicule: numéro d'im ­
matriculation (VRN) avec indication de l'État membre d'imma ­
triculation, et numéro d'identification du véhicule (VIN) (  1 ); 
ww) «semaine», aux fins du calcul dans l'appareil de contrôle:  
une période comprise entre 00:00 heure UTC le lundi et 24:00 
heures UTC le dimanche;  
xx) «carte d'atelier»:  
une carte tachygraphique délivrée par les autorités d'un État 
membre à certains membres du personnel d'un fabricant de 
tachygraphes, d'un installateur, d'un constructeur de véhicules 
ou d'un atelier, homologué par cet État membre. La carte 
d'atelier permet l'identification du détenteur ainsi que l'essai, 
l'étalonnage et l'activation de tachygraphes et/ou le télécharge ­
ment à partir de ceux-ci;  
yy) «adaptateur»:  
un dispositif émettant un signal permanent représentatif de la 
vitesse et/ou de la distance parcourue par le véhicule, autre 
que celui qui est utilisé pour la détection de mouvement indé ­
pendante, et qui est:  
▼M1 
— 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 (  2 ), 
telle que modifiée en dernier lieu),  
▼B 
— installé lorsqu'il n'est pas mécaniquement possible d'ins ­
taller un autre type de capteur de mouvement par ailleurs 
conforme aux dispositions de la présente 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 capteurs intégrés ou des interfaces de remplace ­
ment;  
— vu d'une unité embarquée, le comportement de l'adaptateur 
est le même que si un capteur de mouvement, conforme 
aux dispositions de la présente annexe et de ses appendices 
1 à 16, était connecté à l'unité embarquée sur le véhicule;  
l'utilisation d'un tel adaptateur dans les véhicules décrits ci- 
dessus doit permettre l'installation et l'utilisation correcte d'une 
unité embarquée conforme à toutes les exigences de la 
présente annexe;  
pour ces véhicules, le tachygraphe intelligent comprend des 
câbles, un adaptateur et une unité embarquée sur le véhicule;  ▼B 
( 1 ) Directive 76/114/CEE du Conseil du 18 décembre 1975 concernant le rapprochement des 
législations des États membres relatives aux plaques et inscriptions réglementaires, ainsi 
qu'à leurs emplacement et modes d'apposition en ce qui concerne les véhicules à moteur 
et leurs remorques (JO L 24 du 30.1.1976, p. 1). 
( 2 ) Directive 2007/46/CE du Parlement européen et du Conseil du 5 septembre 2007 établis ­
sant un cadre pour la réception des véhicules à moteur, de leurs remorques et des 
systèmes, des composants et des entités techniques destinés à ces véhicules (directive- 
cadre) (JO L 263 du 9.10.2007, p. 1).
 02016R0799 — FR — 26.02.2020 — 002.001 — 20  
zz) «intégrité des données»:  
la précision et la cohérence des données stockées, indiquées 
par l'absence de toute 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 exemple pas été 
endommagées lors des processus d'écriture et de lecture vers 
et à partir d'une carte tachygraphique, 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 direc ­
tive 95/46/CE du Parlement européen et du Conseil (  1 ), ainsi 
que de ceux énoncés dans la directive 2002/58/CE du Parle ­
ment européen et du Conseil (  2 ); 
bbb) «tachygraphe intelligent»:  
l'appareil de contrôle, les cartes tachygraphiques et l'ensemble 
des équipements qui interagissent directement ou indirecte ­
ment au cours de leur construction, 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échargement de données, à l'analyse 
des données, à l'étalonnage, à la génération, à la gestion ou à 
l'introduction d'éléments de sécurité, 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) n  o 165/2014 du Parle ­
ment européen et du Conseil (  3 ). 
Il s'agit de la date après laquelle les véhicules immatriculés 
pour la première fois:  
— doivent être équipés d'un tachygraphe connecté à un 
service de positionnement s'appuyant sur un système de 
navigation par satellite,  
— doivent être capables, lorsque le véhicule est en mouve ­
ment, de communiquer des données aux autorités de 
contrôle compétentes à des fins de contrôles routiers 
ciblés,  
— et peuvent être équipés d'une interface normalisée permet ­
tant l'utilisation en mode opérationnel, par un dispositif 
extérieur, des données enregistrées ou produites par le 
tachygraphe;  
ddd) «profil de protection»:  
un document utilisé dans le cadre d'un processus de certifica ­
tion selon les «critères communs», qui définit, indépendam ­
ment de toute mise en œuvre, les exigences de sécurité en 
matière de garantie de l'information;  ▼B 
( 1 ) Directive 95/46/CE du Parlement européen et du Conseil du 24 octobre 1995 relative à la 
protection des personnes physiques à l'égard du traitement des données à caractère 
personnel et à la libre circulation de ces données (JO L 281 du 23.11.1995, p. 31). 
( 2 ) Directive 2002/58/CE du Parlement européen et du Conseil du 12 juillet 2002 concernant 
le traitement des données à caractère personnel et la protection de la vie privée dans le 
secteur des communications électroniques (directive vie privée et communications élec ­
troniques) (JO L 201 du 31.7.2002, p. 37). 
( 3 ) Règlement (UE) n  o 165/2014 du Parlement Européen et du Conseil du 4 février 2014 
relatif aux tachygraphes dans les transports routiers, abrogeant le règlement (CEE) 
n o 3821/85 du Conseil concernant l'appareil de contrôle dans le domaine des transports 
par route et modifiant le règlement (CE) n  o 561/2006 du Parlement européen et du 
Conseil relatif à l'harmonisation de certaines dispositions de la législation sociale dans 
le domaine des transports par route (JO L 60 du 28.2.2014, p. 1).
 02016R0799 — FR — 26.02.2020 — 002.001 — 21  
eee) «précision GNSS»:  
dans le cadre de l'enregistrement de la position par un système 
mondial de navigation par satellite (GNSS) à l'aide de tachy ­
graphes, la valeur du coefficient d'affaiblissement de la préci ­
sion de positionnement horizontal (HDOP) calculée comme la 
minimale des valeurs HDOP recueillies sur les systèmes 
GNSS disponibles;  
▼M1 
fff) «temps de conduite accumulé»:  
valeur représentant le nombre total de minutes de temps de 
conduite accumulé d’un véhicule donné.  
La valeur du temps de conduite accumulé est un comptage 
libre de l’ensemble des minutes comptabilisées comme de la 
CONDUITE par la fonction de suivi des activités de conduite 
de l’appareil de contrôle. Elle n’est utilisée que pour déclen ­
cher l’enregistrement de la position du véhicule à chaque fois 
qu’un multiple de trois heures de conduite accumulé est 
atteint. L’accumulation débute au moment de l’activation de 
l’appareil de contrôle. Elle n’est affectée par aucune autre 
condition (p. ex. «hors champ» ou «trajet en ferry/train»).  
La valeur du temps de conduite accumulé n’est pas destinée à 
être affichée, imprimée ou téléchargée.  
▼B 
2. CARACTÉRISTIQUES GÉNÉRALES ET FONCTIONS DE L'AP ­
PAREIL DE CONTRÔLE  
2.1 Caractéristiques générales  
La fonction de l'appareil de contrôle est d'enregistrer, de stocker, 
d'afficher, d'imprimer et de produire des données concernant les 
activités du conducteur.  
Tout véhicule équipé d'un appareil de contrôle conforme aux dispo ­
sitions de la présente annexe doit comporter un indicateur de vitesse 
et un compteur kilométrique. Ces fonctions peuvent être incluses 
dans l'appareil de contrôle.  
1) L'appareil de contrôle comprend des câbles, un capteur de 
mouvement et une unité embarquée sur le véhicule.  
2) L'interface entre les capteurs de mouvement et les unités 
embarquées se conforme aux dispositions de l'appen ­
dice 11.  
3) L'unité embarquée sur le véhicule doit être connectée à un 
ou plusieurs systèmes mondiaux de navigation par satel ­
lite, comme indiqué à l'appendice 12.  
4) L'unité embarquée sur le véhicule doit communiquer avec 
des lecteurs de communication et de détection précoces à 
distance conformément à l'appendice 14.  
5) L'unité embarquée sur le véhicule peut comporter une 
interface ITS, qui est spécifiée à l'appendice 13.  
L'appareil de contrôle peut être relié à d'autres équipe ­
ments par le biais d'interfaces supplémentaires et/ou de 
l'interface ITS facultative.  
6) Toute insertion ou connexion de toute fonction ou dispo ­
sitif(s), homologué(s) ou non, dans ou à l'appareil de 
contrôle, ne doit pas interférer ou être susceptible d'inter ­
fé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'identifient dans 
l'appareil à l'aide de cartes tachygraphiques.  
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'uti ­
lisateur.  
L'appareil de contrôle enregistre et stocke des données dans sa 
mémoire, dans le dispositif de communication à distance et sur les 
cartes tachygraphiques.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 22  
Ces fonctions sont assurées dans le respect de la directive 95/46/CE 
du 24 octobre 1995 relative à la protection 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 concernant le traitement des données à caractère 
personnel et la protection de la vie privée dans le secteur des 
communications électroniques (  2 ) et en conformité avec l'article 7 
du règlement (UE) n  o 165/2014.  
2.2 Fonctions  
8) L'appareil de contrôle doit assurer les fonctions suivantes:  
— surveillance des insertions et retraits de carte,  
— mesure de la vitesse, de la distance parcourue et de la 
position,  
— mesure du temps,  
— suivi des activités du conducteur,  
— 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 journalières 
de travail,  
— saisie manuelle des activités du conducteur,  
— saisie des conditions particulières,  
— gestion des verrouillages d'entreprise,  
— suivi des activités de contrôle,  
— détection des événements et/ou des anomalies,  
— autotests intégrés,  
— lecture de données stockées sur la mémoire,  
— enregistrement et stockage de données sur la mémoire,  
— lecture des cartes tachygraphiques,  
— enregistrement et stockage de données sur les cartes 
tachygraphiques,  
— affichage,  
— impression,  
— avertissement,  
— téléchargement 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'étalonnage,  
— remise à l'heure.  
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 «entreprise».  
10) L'appareil de contrôle doit basculer dans les modes de 
fonctionnement suivants selon la carte tachygraphique 
valable insérée dans l'interface de carte. La génération à 
laquelle appartient la carte du tachygraphe n'est pas perti ­
nente en vue de déterminer le mode de fonctionnement à 
condition que la carte insérée soit valable. Une carte d'ate ­
lier de première génération doit toujours être considérée 
comme non valable lorsqu'elle est insérée dans une unité 
embarquée de deuxième génération.  ▼B 
( 1 ) JO L 281 du 23.11.1995, p. 31. 
( 2 ) JO L 201 du 31.7.2002, p. 37
 02016R0799 — FR — 26.02.2020 — 002.001 — 23  
Mode de fonctionnement  Lecteur «conducteur»  
Pas de carte  Carte du conducteur  Carte de contrôleur  Carte d'atelier  Carte d'entreprise
 Lecteur «convoyeur» Pas de carte  Opérationnel  Opérationnel  Contrôle  Étalonnage  Entreprise  
Carte du 
conducteur  Opérationnel  Opérationnel  Contrôle  Étalonnage  Entreprise  
Carte de 
contrôleur  Contrôle  Contrôle  Contrôle (*)  Opérationnel  Opérationnel  
Carte d'atelier  Étalonnage  Étalonnage  Opérationnel  Étalonnage (*)  Opérationnel  
Carte d'entre ­
prise  Entreprise  Entreprise  Opérationnel  Opérationnel  Entreprise (*)  
(*) En pareil cas, l'appareil de contrôle utilise uniquement la carte tachygraphique insérée dans le lecteur «conducteur».  
11) L'appareil de contrôle doit refuser les cartes non valables, 
sauf pour l'affichage, l'impression ou le téléchargement 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'ex ­
ception de:  
— la fonction d'étalonnage, accessible uniquement en 
mode étalonnage,  
— la fonction de contrôle routier d'étalonnage, accessible 
uniquement en mode contrôle,  
— la fonction de gestion des verrouillages d'entreprise, 
accessible uniquement en mode entreprise,  
— le suivi des activités de contrôle, accessible unique ­
ment en mode contrôle,  
— la fonction de téléchargement, non accessible en mode 
opérationnel (sauf dans les cas prévus à l'exigence 
193), excepté le téléchargement d'une carte de conduc ­
teur lorsqu'aucun autre type de carte n'est inséré dans 
la VU.  
13) L'appareil de contrôle peut extraire toute donnée pour affi ­
chage, impression ou téléchargement vers des interfaces 
externes, sauf:  
— en mode opérationnel, toute identification personnelle 
[nom et prénom(s)] ne correspondant pas à la carte 
tachygraphique insérée sera masquée, et tout numéro 
de carte ne correspondant pas à la carte tachygraphique 
insérée sera partiellement masqué (un caractère sur 
deux, de gauche à droite),  
— en mode entreprise, les données relatives au conduc ­
teur (exigences 102, 105 et 108) peuvent être extraites 
seulement pour les périodes où aucun verrouillage 
n'existe ou où aucune autre entreprise (telle qu'identi ­
fiée par les 13 premiers chiffres du numéro de la carte 
d'entreprise) 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 rela ­
tives au conducteur 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 extraites via l'interface ITS de la 
VU à moins que le consentement du conducteur à qui 
se rapportent ces données soit vérifié,  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 24  
— les unités embarquées ont une période de validité 
opérationnelle normale de 15 ans à partir de la date 
effective de leurs certificats mais peuvent être utilisées 
pendant 3 mois supplémentaires, uniquement aux fins 
du téléchargement de données.  
▼B 
2.4 Sécurité  
▼M1 
La sécurité du système vise à protéger la mémoire de manière à 
empêcher l’accès non autorisé et la manipulation de données, et à 
détecter les tentatives de manipulation, à préserver l’intégrité et 
l’authenticité des données échangées entre le capteur de mouvement 
et l’unité embarquée sur le véhicule ainsi qu’entre l’appareil de 
contrôle et les cartes tachygraphiques, à préserver l’intégrité et l’au ­
thenticité des données échangées entre l’unité embarquée sur véhi ­
cule et le dispositif GNSS externe, le cas échéant, à préserver la 
confidentialité, l’intégrité et l’authenticité des données échangé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échargées.  
▼B 
14) Afin d'assurer la sécurité du système, les composants 
suivants doivent satisfaire aux exigences spécifiées dans 
leur profil de protection, comme le requiert l'appendice 10:  
— unité embarquée sur le véhicule,  
— carte tachygraphique,  
— capteur de mouvement,  
— dispositif GNSS externe (ce profil n'est nécessaire et 
applicable que pour la variante du GNSS externe).  
3. EXIGENCES CONSTRUCTIVES ET FONCTIONNELLES 
APPLICABLES À L'APPAREIL DE CONTRÔLE  
3.1 Suivi de l'insertion et du retrait des cartes  
15) L'appareil de contrôle doit assurer le suivi des insertions et 
retraits de carte.  
16) Lors de l'insertion d'une carte, l'appareil de contrôle vérifie 
la validité de la carte et identifie son type et la génération 
à laquelle elle appartient.  
Si une carte portant le même numéro de carte et un indice 
de renouvellement supérieur a déjà été insérée dans l'ap ­
pareil 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 remplacement 
supérieur, a déjà été insérée dans l'appareil de contrôle, la 
carte est déclarée non valable.  
17) Les cartes tachygraphiques 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 tachy ­
graphiques de première génération a été supprimée par un 
atelier, en conformité avec l'appendice 15 (exigence 
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.  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 25  
19) L'appareil de contrôle doit être conçu de manière à ce que 
les cartes tachygraphiques soient verrouillées en position 
correcte dans l'interface.  
20) Le retrait d'une carte tachygraphique n'est possible que 
lorsque le véhicule est à l'arrêt, et après que les données 
pertinentes ont été stockées sur la carte. Le retrait de la 
carte nécessite une intervention concrète de l'utilisateur.  
3.2 Mesure de la vitesse, de la position et de la distance parcourue  
21) Le capteur de mouvement (éventuellement intégré dans 
l'adaptateur) est la principale source de mesure de la 
vitesse et de la distance parcourue.  
22) Cette fonction assure une mesure en continu et permet 
d'indiquer la valeur kilométrique correspondant à la 
distance totale parcourue par le véhicule en utilisant les 
impulsions envoyées par le capteur de mouvement.  
23) Cette fonction assure une mesure en continu et permet 
d'indiquer la vitesse du véhicule en utilisant les impulsions 
envoyées par le capteur de mouvement.  
24) La fonction de mesure de la vitesse doit également indi ­
quer si le véhicule est en mouvement ou à l'arrêt. La 
fonction de mesure de la vitesse 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étecte 
plus de 1 imp/s pendant au moins 5 secondes en prove ­
nance du capteur de mouvement, et dans le cas contraire le 
véhicule est considéré à l'arrêt.  
25) Les dispositifs indicateurs de vitesse et kilométriques 
installés sur tout véhicule muni d'un appareil de contrôle 
conforme au présent règlement doivent satisfaire aux 
exigences concernant les tolérances maximales (voir 
points 3.2.1 et 3.2.2) fixées dans la présente annexe.  
26) Pour détecter la manipulation de données de mouvement, 
les informations provenant du capteur de mouvement sont 
corroborées par des informations relatives au mouvement 
du véhicule provenant du récepteur GNSS et éventuelle ­
ment d'une ou plusieurs autres sources indépendantes du 
capteur de mouvement.  
27) Cette fonction doit mesurer la position du véhicule afin de 
permettre l'enregistrement automatique:  
— des positions correspondant aux lieux où le conducteur 
et/ou le convoyeur commencent leur période de travail 
journalière,  
▼M1 
— des positions correspondant aux lieux où le temps de 
conduite accumulé atteint un multiple de trois heures,  
▼B 
— des positions correspondant aux lieux où le conducteur 
et/ou le convoyeur terminent leur période de travail 
journalière.  
3.2.1  Mesure de la distance parcourue  
28) La distance parcourue peut être mesurée de manière à:  
— soit cumuler les mouvements en marche avant et en 
marche arrière,  
— soit prendre uniquement en compte les mouvements en 
marche avant.  
29) L'appareil de contrôle doit mesurer la distance parcourue 
de 0 à 9 999 999,9 km.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 26  
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ério ­
diques,  
— ± 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.  
33) Afin de garantir une tolérance maximale sur la vitesse 
indiquée de ± 6 km/h en service, et en tenant compte:  
— d'une tolérance de ± 2 km/h pour les variations du 
signal d'entrée (variations 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 coefficients caractéris ­
tiques du véhicule compris entre 4 000 et 25 000 imp/km, 
mesurer la vitesse avec une tolérance de ± 1 km/h (à 
vitesse constante).  
Remarque:  la résolution du stockage des données entraîne 
une tolérance additionnelle de ± 0,5 km/h sur la vitesse 
stocké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 vitesse, lorsque la vitesse a changé 
à un rythme allant jusqu'à 2 m/s  2 . 
35) La mesure de la vitesse 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écepteur GNSS.  
37) La position absolue est mesurée sous forme de coordon ­
né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érique 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érieur de l'appareil de contrôle (enregistre ­
ments, échange de données) et pour tous les tirages papier 
spécifiés à l'appendice 4 «Tirages 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égatif de la demi-heure n'est autorisé.  
41) La dérive temporelle ne doit pas excéder ± 2 secondes par 
jour dans les conditions d'homologation, en l'absence de 
toute remise à l'heure.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 27  
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 électrique externe d'une durée 
inférieure à 12 mois dans les conditions d'homologation.  
3.4 Surveillance des activités du conducteur  
44) Cette fonction doit assurer une surveillance permanente et 
séparée des activités d'un seul conducteur et d'un seul 
convoyeur.  
45) L'activité du conducteur doit être la CONDUITE, le 
TRAVAIL, la DISPONIBILITÉ ou la PAUSE/REPOS.  
46) Il doit être possible au conducteur et/ou au convoyeur de 
sélectionner manuellement l'activité TRAVAIL, DISPONI ­
BILITÉ 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 auto ­
matiquement sélectionnée pour le convoyeur.  
48) Lorsque le véhicule s'arrête, l'activité TRAVAIL doit être 
automatiquement sélectionnée pour le conducteur.  
▼M1 
49) Le premier changement d’activité vers PAUSE/REPOS ou 
DISPONIBILITÉ intervenant dans les 120 secondes qui 
suivent la sélection automatique de l’activité TRAVAIL 
en raison de l’arrêt du véhicule doit être considéré 
comme étant intervenu au moment de l’arrêt du véhicule 
(et peut par conséquent annuler le passage à l’activité 
TRAVAIL).  
▼B 
50) Cette fonction doit transmettre les changements d'activité 
vers les fonctions d'enregistrement avec une résolution 
d'une minute.  
51) Étant donné une minute calendrier, 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 comptabilisée comme de la 
CONDUITE.  
52) Étant donné une minute calendrier non considérée comme 
activité de CONDUITE en application de l'exigence 051, 
la minute 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 conducteur.  
3.5 Surveillance 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 ÉQUIPAGE 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 jour ­
nalière  
56) Cette fonction doit permettre la saisie des lieux où, selon 
le conducteur et/ou le convoyeur, leurs périodes de travail 
journalières commencent et/ou se terminent.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 28  
57) On entend par «lieu» le pays et, le cas échéant, la région, 
qui sont saisis ou confirmés manuellement.  
58) Lors du retrait d'une carte de conducteur, l'appareil de 
contrôle doit inviter le conducteur/convoyeur à saisir le 
«lieu où s'achève la période de travail journalière».  
▼M1 
59) Le conducteur indique alors l’emplacement actuel du véhi ­
cule, ce qui est considéré comme une saisie temporaire.  
Dans les conditions suivantes, la saisie temporaire effec ­
tuée lors du dernier retrait de la carte est validée (c’est-à- 
dire qu’elle n’est plus écrasée):  
— saisie d’un lieu où débute la période de travail journa ­
lière actuelle lors de la saisie manuelle en application 
de l’exigence 61,  
— saisie suivante d’un lieu où débute la période de travail 
journalière actuelle si le détenteur de la carte n'indique 
aucun emplacement de début ou de fin de la période de 
travail lors de la saisie manuelle en application de 
l’exigence 61.  
Dans les conditions suivantes, la saisie temporaire effec ­
tuée lors du dernier retrait de la carte est écrasée et la 
nouvelle valeur est validée:  
— saisie suivante d’un lieu où s’achève la période de 
travail journalière actuelle si le détenteur de la carte 
n'indique aucun emplacement de début ou de fin de la 
période de travail lors de la saisie manuelle en appli ­
cation de l’exigence 61.  
▼B 
60) Il doit être possible de saisir le lieu de début et/ou de fin 
d'une période de travail journalière au moyen de 
commandes dans les menus. Si plusieurs saisies de ce 
type sont effectuées au cours d'une minute calendrier, 
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'insertion d'une carte de conducteur (ou d'atelier), 
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'insertion de la carte de conducteur ou d'atelier, 
les informations suivantes sont rappelées au détenteur de la 
carte:  
— la date et l'heure du dernier retrait de la carte,  
— facultativement: le décalage de l'heure locale sélec ­
tionné pour l'unité embarquée.  
Lors de la première insertion d'une carte de conducteur 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 tachy ­
graphe puissent être extraites via l'interface ITS facultative.  
L'accord du conducteur/de l'atelier peut être activé ou 
désactivé à tout moment par des commandes se trouvant 
dans le menu, à condition que la carte du conducteur/de 
l'atelier soit insérée.  
Il doit être possible de saisir des activités, moyennant les 
restrictions suivantes:  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 29  
— le type d'activité doit être le TRAVAIL, la DISPONI ­
BILITÉ ou la PAUSE/REPOS,  
— les heures de début et de fin pour chaque activité 
doivent se situer exclusivement dans la période sépa ­
rant le dernier retrait de l'insertion actuelle de la carte,  
— les activités ne doivent pas se chevaucher dans le 
temps.  
Il doit être possible d'effectuer des saisies manuelles, si 
nécessaire, lors de la première insertion d'une carte de 
conducteur (ou d'atelier) encore inutilisée.  
La procédure de saisie manuelle d'activités comprend 
autant d'étapes consécutives que nécessaire pour sélec ­
tionner un type, une heure de début et une heure de fin 
pour chaque activité. Pour toute partie de la période sépa ­
rant le dernier retrait de la carte de son insertion actuelle, 
le détenteur a le choix de ne déclarer aucune activité.  
Au cours des saisies manuelles associées à l'insertion de la 
carte, le détenteur de celle-ci a, le cas échéant, la possibi ­
lité de saisir:  
▼M1 
— un lieu où s’est achevée une période de travail journa ­
lière précédente, associé à l’heure correspondante (qui 
écrase et valide la saisie effectuée lors du dernier 
retrait de la carte),  
— un lieu où débute la période de travail journalière 
actuelle, associé à l’heure correspondante (qui valide 
une saisie temporaire effectuée lors du dernier retrait 
de la carte).  
▼B 
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'insertion 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 journaliè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 tachygraphique appropriée.  
La saisie manuelle est interrompue si:  
— la carte est retirée ou  
— le véhicule est mis en mouvement alors que la carte se 
trouve dans le lecteur réservé au conducteur.  
Des interruptions supplémentaires sont autorisées, par 
exemple une temporisation après une certaine période 
d'inactivité de l'utilisateur. En cas d'interruption de la 
saisie manuelle, l'appareil de contrôle valide toute 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 conducteur ou d'atelier est insérée 
alors que la saisie manuelle d'activités est en cours pour 
une carte insérée auparavant, la saisie concernant cette 
première carte doit pouvoir ê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 insertion actuelle,  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 30  
— 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édia ­
tement 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 termine lorsque l'heure de fin d'une acti ­
vité saisie manuellement correspond à l'heure d'insertion 
de la carte. L'appareil de contrôle peut alors, à titre facul ­
tatif, permettre au détenteur de la carte de modifier toute 
activité saisie manuellement, jusqu'à la validation par la 
sélection d'une commande particulière. Par la suite, toute 
modification de ce type est interdite.  
3.6.3  Saisie de conditions particulières  
62) L'appareil de contrôle doit permettre au conducteur de 
saisir en temps réel les deux conditions particulières 
suivantes:  
— «HORS CHAMP» (début, fin),  
— «TRAJET EN FERRY/TRAIN» (début, fin).  
Un «TRAJET EN FERRY/TRAIN» ne peut survenir 
lorsque la condition «HORS CHAMP» est ouverte.  
Une condition «HORS CHAMP» ouverte doit impérative ­
ment être automatiquement fermée en cas de retrait ou 
d'insertion d'une carte de conducteur.  
Une condition «HORS CHAMP» ouverte doit empêcher 
les événements et avertissements suivants:  
— conduite sans carte appropriée,  
— avertissements liés à un temps de conduite continue.  
Le début du TRAJET EN FERRY/TRAIN doit être pointé 
avant l'arrêt du moteur sur le ferry/train.  
Un TRAJET EN FERRY/TRAIN ouvert doit se terminer 
lorsque l'une des possibilités suivantes se produit:  
— le conducteur met fin au TRAJET EN FERRY/TRAIN 
manuellement,  
— le conducteur éjecte sa carte,  
Un TRAJET EN FERRY/TRAIN ouvert prend fin lorsqu'il 
n'est plus valable selon les règles énoncées dans le règle ­
ment (CE) n  o 561/2006.  
3.7 Gestion des dispositifs de verrouillage de l'entreprise  
63) Cette fonction doit permettre la gestion des verrouillages 
placés par une entreprise en vue de restreindre à elle seule 
l'accès aux données en mode «entreprise».  
64) Les verrouillages d'entreprise consistent en une date et une 
heure de début (verrouillage) et une date et une heure de 
fin (déverrouillage) associées à l'identification de l'entre ­
prise par le numéro de carte d'entreprise (lors du verrouil ­
lage).  
65) Le verrouillage et le déverrouillage ne sont possibles qu'en 
temps réel.  
66) Le déverrouillage ne peut être effectué que par l'entreprise 
qui a verrouillé (telle qu'identifiée par les 13 premiers 
chiffres du numéro de la carte d'entreprise), ou  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 31  
67) le déverrouillage est automatique lorsqu'une autre entre ­
prise verrouille.  
68) Dans le cas où une entreprise verrouille et où le verrouil ­
lage précédent a été effectué pour la même entreprise, on 
supposera que le verrouillage précédent n'a pas été déver ­
rouillé et qu'il est toujours en fonction.  
3.8 Suivi des activités de contrôle  
69) Cette fonction assure le suivi des activités d'AFFICHAGE, 
d'IMPRESSION, de TÉLÉCHARGEMENT depuis l'unité 
embarquée sur le véhicule ou la carte et de contrôle 
ROUTIER de l'ÉTALONNAGE, toutes 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'imprimante ou l'écran, ou lorsque des 
données «événements ou anomalies» ont été téléchargées 
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 «Insertion d'une carte non valable»  
72) Cet événement est déclenché par l'insertion d'une carte non 
valable, par l'insertion 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 «Conflit de carte»  
73) Cet événement est déclenché pour chacune des combinai ­
sons de cartes marquées d'une croix dans le tableau 
suivant:  
Conflit de carte  Lecteur «conducteur»  
Pas de carte  Carte du conduc ­
teur Carte de contrôleur  Carte d'atelier  Carte d'entreprise
 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'entreprise  X  X  X  
3.9.3  Événement «Chevauchement temporel»  
74) Cet événement est déclenché lorsque la date/l'heure de 
dernier retrait d'une carte de conducteur, tel qu'elle appa ­
raît sur la carte, est postérieure à la date/l'heure actuelle de 
l'appareil de contrôle dans lequel la carte est insérée.  
3.9.4  Événement «Conduite sans carte appropriée»  
75) Cet événement est déclenché pour toute combinaison de 
cartes tachygraphiques valables marquée d'une croix dans 
le tableau suivant, lorsque l'activité du conducteur devient 
«CONDUITE», ou en cas de changement de mode de 
fonctionnement lorsque l'activité du conducteur est 
CONDUITE:  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 32  
Conduite sans carte appropriée  Lecteur «conducteur»  
Pas de carte (ou 
carte non valable)  Carte du conduc ­
teur Carte de contrôleur  Carte d'atelier  Carte d'entreprise
 Lecteur «convoyeur» Pas de carte (ou carte 
non valable)  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'entreprise  X  X  X  X  X  
3.9.5  Événement «Insertion d'une carte en cours de conduite»  
76) Cet événement est déclenché lorsqu'une carte tachygra ­
phique est insérée dans un lecteur quelconque alors que 
l'activité du conducteur est CONDUITE.  
3.9.6  Événement «Dernière session incorrectement clôturée»  
77) Cet événement est déclenché lorsque l'appareil de contrôle 
détecte lors de l'insertion de la carte que, malgré les dispo ­
sitions 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 
toutes les données nécessaires aient été enregistrées sur 
la carte). Cet événement ne peut concerner 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 
vitesse.  
3.9.8  Événement «Interruption de l'alimentation électrique»  
79) Cet événement est déclenché, en mode autre qu'étalonnage 
ou contrôle, en cas d'interruption pendant plus de 200 
millisecondes de l'alimentation électrique du capteur de 
mouvement et/ou de l'unité embarquée sur le véhicule. 
Le seuil d'interruption est fixé par le fabricant. La 
rupture de l'alimentation électrique due au démarrage du 
moteur du véhicule ne doit pas déclencher cet événement.  
3.9.9  Événement «Erreur de communication avec le dispositif de commu ­
nication à distance»  
80) Cet événement est déclenché  en mode autre qu'«étalon ­
nage»  et que le dispositif de communication à distance ne 
confirme pas la bonne réception de données de communi ­
cation à distance envoyées par l'unité embarquée sur le 
véhicule à plus de trois reprises.  
3.9.10  Événement «Absence d'informations de positionnement en prove ­
nance du récepteur GNSS»  
81) Cet événement est déclenché lorsque la VU  n'est pas en 
mode étalonnage , que le récepteur GNSS (interne ou 
externe) ne fournit aucune information de position 
pendant plus de trois heures de conduite consécutives.  
3.9.11  Événement «Erreur de communication avec le dispositif GNSS 
externe»  
82) Cet événement est déclenché  en mode autre qu'«étalon ­
nage» , que la communication entre le dispositif GNSS 
externe et l'unité embarquée sur le véhicule est inter ­
rompue pendant plus de 20 minutes consécutives et que 
le véhicule est en mouvement.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 33  
3.9.12  Événement «Erreur sur les données de mouvement»  
83) Cet événement est déclenché,  en mode autre qu'«étalon ­
nage» , en cas d'interruption du flux normal de données 
entre le capteur 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 capteur de mouvement et la VU.  
3.9.13  Événement «Conflit concernant le mouvement du véhicule»  
84) Cet événement est déclenché  en mode autre qu'«étalon ­
nage»  lorsque des informations relatives au mouvement 
calculées par le capteur de mouvement entrent en conflit 
avec les informations de mouvement fournies par le récep ­
teur GNSS interne ou par le dispositif GNSS externe, 
voire par d'autres sources indépendantes, conformé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écepteur GNSS ne sont pas disponibles.  
3.9.14  Événement «Tentative d'atteinte à la sécurité»  
85) Cet événement est déclenché en cas de tout autre événe ­
ment affectant la sécurité du capteur 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.  
▼M1 
3.9.15 Événement «Conflit temporel»  
86) Cet événement est déclenché  en mode autre qu’étalon ­
nage  lorsque la VU détecte un écart de plus d’une minute 
entre le temps fourni par sa fonction de mesure du temps 
et le temps fourni par le récepteur GNSS. Cet événement 
est enregistré avec la valeur de l’horloge interne de l’unité 
embarquée sur le véhicule et s’accompagne d’une remise à 
l’heure automatique. Après le déclenchement d’un événe ­
ment «Conflit temporel», la VU ne générera plus d’autres 
événements «Conflit 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écepteur 
GNSS depuis au moins 30 jours.  
▼B 
3.9.16  Anomalie «Carte»  
87) Cette anomalie est déclenchée en cas d'anomalie d'une 
carte tachygraphique en cours de fonctionnement.  
3.9.17  Anomalie «Appareil de contrôle»  
88) Cette anomalie est déclenchée dans le cas des anomalies 
suivantes, dans les modes autres qu'étalonnage:  
— anomalie interne de la VU  
— anomalie de l'imprimante  
— anomalie de l'affichage  
— anomalie de téléchargement  
— anomalie du capteur  
— anomalie du récepteur GNSS ou du dispositif GNSS 
externe,  
— anomalie du dispositif de communication à distance.  
▼M1 
— anomalie sur l’interface ITS (le cas échéant).  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 34  
3.10 Autotests intégrés  
89) ►M1 L’appareil de contrôle détecte les anomalies par des 
autotests et des tests intégrés, selon le tableau suivant: ◄ 
Élément à tester  Autotest  Test intégré  
Logiciels  Intégrité  
Mémoire de données  Accès  Accès, intégrité des 
données  
Dispositifs d'interface 
carte  Accès  Accès  
Clavier  Contrôle manuel  
Imprimante  (au choix du fabri ­
cant)  Impression  
Écran  Contrôle visuel  
Téléchargement 
(effectué uniquement lors 
du téléchargement)  Fonctionnement 
correct  
Capteur  Fonctionnement 
correct  Fonctionnement correct  
Dispositif de communica ­
tion à distance  Fonctionnement 
correct  Fonctionnement correct  
Dispositif GNSS  Fonctionnement 
correct  Fonctionnement correct  
▼M1 
Interface ITS (facultatif)  Fonctionnement 
correct  
▼B 
3.11 Lecture de la mémoire  
90) L'appareil de contrôle doit pouvoir lire toutes 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 
conducteurs dans un véhicule. L'activité moyenne par jour dans 
un véhicule est définie comme au moins 6 conducteurs ou 
convoyeurs, 6 cycles d'insertion/retrait de cartes et 256 change ­
ments d'activités. «365 jours» incluent donc au moins 2 190 
conducteurs/convoyeurs, 2 190 cycles d'insertion/retrait de carte 
et 93 440 changements d'activité,  
▼M1 
— le nombre moyen de positions par jour est défini comme au 
moins 6 positions correspondant aux lieux où commence la 
période de travail journalière, 6 positions correspondant aux 
lieux où le temps de conduite accumulé atteint un multiple de 
trois heures et 6 positions correspondant aux lieux où se termine 
la période de travail journalière, de sorte qu’au moins 6570 
positions sont comprises dans ces «365 jours»,  
▼B 
— les heures sont enregistrées à la minute près, sauf indication 
contraire,  
— les valeurs kilométriques sont enregistrées au kilomètre près,  
— les vitesses sont enregistrées au kilomètre/heure près,  
— les positions (latitudes et longitudes) sont enregistrées en degrés 
et en minutes, au dixième de minute près, en association avec la 
précision et le temps d'acquisition du GNSS.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 35  
91) Les données enregistrées dans la mémoire ne doivent pas 
être affectées par une coupure de l'alimentation électrique 
externe d'une durée inférieure à douze mois dans les 
conditions d'homologation. En outre, les données stocké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 stocker 
implicitement ou explicitement dans sa mémoire les 
données suivantes:  
3.12.1  Données d'identification de l'appareil  
3.12.1.1 D o n n é e s d ' i d e n t i f i c a t i o n d e l ' u n i t é e m b a r q u é e 
s u r l e v é h i c u l e  
93) L'appareil de contrôle doit pouvoir stocker dans sa 
mémoire les données suivantes pour l'identification de 
l'unité embarquée sur le véhicule:  
— nom du fabricant,  
— adresse du fabricant,  
— numéro des pièces,  
— numéro de série,  
— génération de la VU,  
— possibilité d'utiliser des cartes tachygraphiques de 
première génération,  
— numéro de la version du logiciel,  
— date d'installation de la version du logiciel,  
— année de construction de l'appareil,  
— numéro d'homologation.  
94) Les données d'identification de l'unité embarquée sur le 
véhicule sont enregistrées et stockées une fois pour 
toutes par le fabricant de l'unité embarquée sur le véhicule, 
sauf les données concernant le logiciel et le numéro d'ho ­
mologation, qui peuvent être modifiés en cas d'évolution 
du logiciel, et la possibilité d'utiliser des cartes tachygra ­
phiques de première génération.  
3.12.1.2 D o n n é e s d ' i d e n t i f i c a t i o n d u c a p t e u r d e m o u v e ­
m e n t  
95) Le capteur de mouvement doit pouvoir stocker dans sa 
mémoire les données d'identification suivantes:  
— nom du fabricant,  
— numéro de série,  
— numéro d'homologation.  
— identificateur du composant de sécurité intégré (par ex. 
numéro de série du microprocesseur interne),  
— identificateur du système d'exploitation (par ex. 
numéro de la version du logiciel).  
96) Les données d'identification du capteur de mouvement 
sont enregistrées et stockées une fois pour toutes sur le 
capteur par son fabricant.  
97) L'unité embarquée sur le véhicule enregistre et mémorise 
dans sa mémoire de données les données suivantes asso ­
ciées aux 20 appariements de capteurs de mouvement les 
plus récents (si plusieurs appariements ont eu lieu en un 
jour calendaire, seuls le premier et le dernier de la journée 
sont mémorisés):  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 36  
Les données suivantes sont enregistrées pour chacun de 
ces appariements:  
— données d'identification du capteur de mouvement:  
— numéro de série,  
— numéro d'homologation,  
— données de couplage du capteur de mouvement:  
— date d'appariement.  
3.12.1.3 D o n n é e s d ' i d e n t i f i c a t i o n d e s s y s t è m e s m o n d i a u x 
d e n a v i g a t i o n p a r s a t e l l i t e ( G l o b a l N a v i g a t i o n 
S a t e l l i t e S y s t e m s )  
98) Le dispositif GNSS externe doit pouvoir stocker dans sa 
mémoire les données d'identification suivantes:  
— nom du fabricant,  
— numéro de série,  
— numéro d'homologation.  
— identificateur du composant de sécurité intégré (par ex. 
numéro de série du microprocesseur interne),  
— identificateur du système d'exploitation (par ex. 
numéro de la version du logiciel).  
99) Les données d'identification sont enregistrées et stockées 
une fois pour toutes sur le dispositif GNSS externe par le 
fabricant de ce dernier.  
100) L'unité embarquée sur le véhicule enregistre et mémorise 
dans sa mémoire de données les données suivantes asso ­
ciées aux 20 appariements de dispositifs GNSS externes 
les plus récents (si plusieurs appariements ont eu lieu en 
un jour calendaire, seuls le premier et le dernier de la 
journée sont mémorisés).  
Les données suivantes sont enregistrées pour chacun de 
ces appariements:  
— données d'identification du dispositif GNSS externe:  
— numéro de série,  
— numéro d'homologation.  
— données de couplage du dispositif GNSS externe:  
— date d'appariement  
3.12.2  Clés et certificats  
101) L'appareil de contrôle doit être en mesure de stocker un 
certain nombre de certificats et de clés cryptographiques, 
comme spécifié à l'appendice 11, parties A et B.  
3.12.3  Données d'insertion et de retrait de la carte du conducteur ou de 
l'atelier  
102) Pour chaque cycle insertion-retrait d'une carte de conduc ­
teur ou d'atelier, l'appareil de contrôle enregistre et stocke 
dans sa mémoire:  
— les nom et prénom(s) du détenteur de la carte tels que 
stocké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,  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 37  
— la date et l'heure d'insertion,  
— le kilométrage du véhicule au moment de l'insertion de 
la carte,  
— le lecteur 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,  
— les informations suivantes relatives au dernier véhicule 
utilisé par le conducteur, telles que stockées sur la 
carte:  
— le numéro et l'État membre d'immatriculation,  
— 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étenteur de la carte a saisi 
manuellement des activités lors de l'insertion de la 
carte ou non.  
103) La mémoire doit pouvoir conserver ces données pendant 
au moins 365 jours.  
104) Lorsque la capacité de stockage est épuisée, les données 
nouvelles remplacent les données les plus anciennes.  
3.12.4  Données relatives à l'activité du conducteur  
105) L'appareil de contrôle enregistre et stocke dans sa mémoire 
tout changement d'activité du conducteur et/ou du 
convoyeur, et/ou tout changement de la situation de 
conduite, et/ou toute insertion ou retrait d'une carte de 
conducteur ou d'atelier:  
— situation de conduite (ÉQUIPAGE, SEUL),  
— lecteur (CONDUCTEUR, CONVOYEUR),  
— situation de la carte dans le lecteur (INSÉRÉE/NON 
INSÉRÉE),  
— activité (CONDUITE, DISPONIBILITÉ, TRAVAIL, 
PAUSE/REPOS),  
— date et heure du changement.  
INSÉRÉE signifie qu'une carte de conducteur ou d'atelier 
en cours de validité est insérée dans le lecteur. NON 
INSÉRÉE signifie 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'entreprise est 
insérée, ou aucune carte n'est insérée).  
Les données relatives à l'activité saisies manuellement par 
un conducteur ne sont pas enregistrées dans la mémoire.  
106) La mémoire doit pouvoir conserver les données relatives à 
l'activité du conducteur pendant au moins 365 jours.  
107) Lorsque la capacité de stockage est épuisée, les données 
nouvelles remplacent les données les plus anciennes.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 38  
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 heures de temps de 
conduite accumulé sont atteintes  
108) L’appareil de contrôle doit enregistrer et stocker dans sa 
mémoire:  
— les lieux et positions des lieux où le conducteur et/ou 
le convoyeur commencent leur période de travail jour ­
nalière;  
— les positions des lieux où le temps de conduite accu ­
mulé atteint un multiple de trois heures;  
— les lieux et positions des lieux où le conducteur et/ou 
le convoyeur terminent leur période de travail journa ­
lière. 
▼B 
109) Lorsque le récepteur GNSS ne peut communiquer la posi ­
tion 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 correspondantes.  
110) Pour chaque lieu ou pour chaque position, l'appareil de 
contrôle doit enregistrer et stocker dans sa mémoire:  
— le numéro de carte de conducteur/convoyeur et l'État 
membre qui a délivré la carte,  
— la génération de la carte,  
— la date et l'heure de la saisie,  
▼M1 
— le type de saisie (début, fin ou 3 heures de temps de 
conduite accumulé),  
▼B 
— la précision GNSS, la date et l'heure correspondantes, 
le cas é chéant,  
— kilométrage du véhicule.  
▼M1 
111) La mémoire doit être en mesure de conserver pendant au 
moins 365 jours les lieux et les positions des lieux où les 
périodes de travail journalières commencent et se termi ­
nent, et/ou où les 3 heures de temps de conduite accumulé 
sont atteintes.  
▼B 
112) Lorsque la capacité de stockage est épuisée, les données 
nouvelles remplacent les données les plus anciennes.  
3.12.6  Données relatives au kilométrage  
113) L'appareil de contrôle enregistre dans sa mémoire le kilo ­
métrage du véhicule et la date correspondante, chaque jour 
civil à minuit.  
114) La mémoire doit pouvoir conserver les relevés quotidiens 
à minuit du compteur kilométrique pendant au moins 365 
jours.  
115) Lorsque la capacité de stockage est épuisée, les données 
nouvelles remplacent les données les plus anciennes.  
3.12.7  Données détaillées relatives à la vitesse  
▼M1 
116) L’appareil de contrôle enregistre et stocke dans sa 
mémoire la vitesse instantanée du véhicule et la date et 
l’heure correspondante à chaque seconde d’au moins les 
24 dernières heures au cours desquelles le véhicule était en 
mouvement.  
▼B 
3.12.8  Données relatives 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 stocke dans sa mémoire 
les données suivantes pour chaque événement détecté, 
conformément aux règles de stockage suivantes:  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 39  
Événement  Règles de stockage  Données à enregistrer pour chaque événement  
Insertion 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.  
Conflit de carte  — les 10 événements les plus récents,  — la date et l'heure du début de l'événe ­
ment, 
— 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 conflit.  
Conduite sans carte appro ­
priée  — l'événement le plus long survenu au 
cours de chacun des 10 derniers jours 
d'occurrence, 
— les 5 événements les plus longs enregis ­
trés au cours des 365 derniers jours,  — la date et l'heure du début de l'événe ­
ment, 
— 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 toute 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.  
Insertion d'une carte en 
cours de conduite  — le dernier événement pour chacun des 
10 derniers jours d'occurrence,  — 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 incorrecte de la 
dernière session  — les 10 événements les plus récents,  — la date et l'heure de l'insertion, 
— 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'insertion, 
— le numéro d'immatriculation, l'État 
membre d'immatriculation et la 
génération de la VU.  
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 graves 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éne ­
ment, 
— la date et l'heure de 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, le numéro, la génération et l'État 
membre ayant délivré la carte de conduc ­
teur (le cas échéant), 
— le nombre d'événements semblables 
survenus le même jour.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 40  
Événement  Règles de stockage  Données à enregistrer pour chaque événement  
Interruption de l'alimenta ­
tion électrique (2)  — l'événement le plus long survenu au 
cours de chacun des 10 derniers jours 
d'occurrence, 
— les 5 événements les plus longs enregis ­
trés au cours des 365 derniers jours,  — la date et l'heure du début de l'événe ­
ment, 
— 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 toute 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 à distance  — l'événement le plus long survenu au 
cours de chacun des 10 derniers jours 
d'occurrence, 
— les 5 événements les plus longs enregis ­
trés au cours des 365 derniers jours,  — la date et l'heure du début de l'événe ­
ment, 
— 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 toute 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'informations de 
positionnement en prove ­
nance du récepteur GNSS  — l'événement le plus long survenu au 
cours de chacun des 10 derniers jours 
d'occurrence, 
— les 5 événements les plus longs enregis ­
trés au cours des 365 derniers jours,  — la date et l'heure du début de l'événe ­
ment, 
— 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 toute 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.  
▼M1 
Erreur de communication 
avec le dispositif GNSS 
externe  — l’événement le plus long survenu au 
cours de chacun des 10 derniers jours 
d’occurrence, 
— les 5 événements les plus longs enregis ­
trés au cours des 365 derniers jours,  — la date et l’heure du début de l’événe ­
ment, 
— 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 toute 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.  
▼B 
Erreur sur les données de 
mouvement  — l'événement le plus long survenu au 
cours de chacun des 10 derniers jours 
d'occurrence, 
— les 5 événements les plus longs enregis ­
trés au cours des 365 derniers jours,  — la date et l'heure du début de l'événe ­
ment, 
— 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 toute 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.  
Conflit concernant le 
mouvement du véhicule  — l'événement le plus long survenu au 
cours de chacun des 10 derniers jours 
d'occurrence, 
— les 5 événements les plus longs enregis ­
trés au cours des 365 derniers jours,  — la date et l'heure du début de l'événe ­
ment, 
— 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 toute 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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 41  
Événement  Règles de stockage  Données à enregistrer pour chaque événement  
Tentative d'atteinte à la 
sécurité  — 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éne ­
ment, 
— la date et l'heure de la fin de l'événe ­
ment, 
— le type et le numéro de la carte ou des 
cartes, l'État membre de délivrance et la 
génération de toute carte insérée au 
début et/ou à la fin de l'événement, 
— le type d'événement.  
▼M1 
Conflit temporel  — l’événement le plus grave (c'est-à-dire 
celui présentant l’écart le plus important 
entre la date et l’heure de l’appareil de 
contrôle et la date et l’heure du GNSS) 
des 10 derniers jours d’occurrence, 
— les 5 événements les plus graves 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 carte ou des 
cartes, l’État membre de délivrance et la 
génération de toute 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.  
▼B 
(1) L'appareil de contrôle doit également enregistrer et 
stocker dans sa mémoire:  
— la date et l'heure du dernier CONTRÔLE 
D'EXCÈS DE VITESSE,  
— la date et l'heure du premier excès de vitesse après 
ce CONTRÔLE D'EXCÈS DE VITESSE,  
— le nombre d'événements du type excès de vitesse 
survenus depuis le dernier CONTRÔLE D'EXCÈS 
DE VITESSE.  
(2) Ces données peuvent être enregistrées uniquement lors 
du rétablissement de l'alimentation électrique, les 
heures pouvant être connues avec une précision 
d'une minute.  
3.12.9  Données relatives aux anomalies  
Aux fins du présent point, l'heure est enregistrée à la seconde près.  
118) L'appareil de contrôle doit essayer d'enregistrer et de 
stocker dans sa mémoire les données suivantes pour 
chaque anomalie détectée, conformément aux règles de 
stockage suivantes:  
Anomalie  Règles de stockage  Données à enregistrer pour chaque anomalie  
Anomalie de la carte  — les 10 dernières anomalies de la carte 
de conducteur,  — 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écentes 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 toute carte insérée au 
début et/ou à la fin de l'anomalie.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 42  
3.12.10  Données d'étalonnage  
119) L'appareil de contrôle enregistre et stocke 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'identification du véhicule, ou VIN),  
— les 20 étalonnages les plus récents (lorsque plusieurs 
étalonnages interviennent 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,  
— identification du véhicule,  
— les paramètres mis à jour ou confirmés: w, k, l, taille 
des pneumatiques, réglage du limiteur de vitesse, 
compteur kilométrique (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 stocke dans sa 
mémoire sa capacité à utiliser les cartes tachygraphiques 
de première génération (encore activées ou non).  
122) Le capteur de mouvement enregistre et stocke dans sa 
mémoire les données suivantes concernant son installation:  
— première connexion à une VU (date, heure, numéro 
d'homologation de la VU, numéro de série de la VU),  
— dernière connexion à une VU (date, heure, numéro 
d'homologation de la VU, numéro de série de la VU).  
123) Le dispositif GNSS externe enregistre et stocke dans sa 
mémoire les données suivantes concernant son installation:  
— premier couplage à une VU (date, heure, numéro d'ho ­
mologation de la VU, numéro de série de la VU),  
— dernier couplage à une VU (date, heure, numéro d'ho ­
mologation 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 importantes.  
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'atelier, l'État membre ayant 
délivré la carte, la génération de la carte et la date 
d'expiration de la carte.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 43  
3.12.12  Données d'activité de contrôle  
126) L'appareil de contrôle enregistre et stocke 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 (affichage et/ou tirage papier et/ou 
téléchargement depuis la VU et/ou téléchargement 
depuis la carte et/ou contrôle d'étalonnage sur route).  
127) En cas de téléchargement, les dates de la journée la plus 
ancienne et de la journée la plus récente téléchargées sont 
également enregistrées.  
3.12.13  Données relatives aux verrouillages d'entreprise  
128) L'appareil de contrôle enregistre et stocke dans sa mémoire 
les données suivantes ayant trait aux 255 plus récents 
verrouillages d'entreprise:  
— la date et l'heure du verrouillage,  
— la date et l'heure du déverrouillage,  
— le numéro de la carte d'entreprise, l'État membre qui a 
délivré la carte et la génération de la carte,  
— le nom et l'adresse de l'entreprise.  
Les données précédemment verrouillées par un verrouil ­
lage supprimé de la mémoire en raison de la limite 
précitée sont traitées comme étant non verrouillées.  
3.12.14  Données relatives au téléchargement  
129) L'appareil de contrôle enregistre et stocke dans sa mémoire 
les données suivantes ayant trait au dernier téléchargement 
depuis la mémoire vers des médias extérieurs en mode 
«entreprise» ou «étalonnage»:  
— la date et l'heure du téléchargement,  
— le numéro de la carte d'entreprise ou d'atelier, l'État 
membre ayant délivré la carte et la génération de la 
carte,  
— le nom de l'entreprise ou de l'atelier.  
3.12.15  Données concernant les conditions particulières  
130) L'appareil de contrôle enregistre et stocke dans sa mémoire 
les données suivantes ayant trait aux conditions particu ­
lières:  
— la date et l'heure de la saisie,  
— le type de condition particulière.  
131) La mémoire doit pouvoir conserver les données relatives 
aux conditions particulières pendant au moins 365 jours 
(en supposant qu'en moyenne 1 condition est ouverte et 
fermée par jour). Lorsque la capacité de stockage est épui ­
sée, les données nouvelles remplacent les données les plus 
anciennes.  
3.12.16  Données relatives à la carte tachygraphique  
132) L'appareil de contrôle doit pouvoir stocker les données 
suivantes relatives aux différentes cartes tachygraphiques 
qui avaient été utilisées dans la VU:  
— le numéro de la carte tachygraphique et son numéro de 
série,  
— le fabricant de la carte tachygraphique,  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 44  
— le type de carte tachygraphique,  
— la version de la carte tachygraphique.  
133) L'appareil de contrôle doit permettre le stockage d'au 
moins 88 enregistrements de ce type.  
3.13 Lecture des cartes tachygraphiques  
134) L'appareil de contrôle doit pouvoir lire sur les cartes tachy ­
graphiques de première et deuxième générations, au 
besoin, les données nécessaires pour:  
— identifier 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 conduite continue du conducteur, 
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'impression de données enre ­
gistrées sur une carte de conducteur,  
— télécharger une carte de conducteur sur un média 
externe.  
Cette exigence ne s'applique qu'aux cartes tachygraphiques 
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 reprises au maximum, et déclare 
la carte défaillante et non valable en cas d'échec répété.  
3.14 Enregistrement et stockage sur cartes tachygraphiques  
3.14.1  Enregistrement et stockage sur les cartes tachygraphiques de 
première génération  
136) À condition que l'utilisation de cartes tachygraphiques 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.  
137) L'appareil de contrôle règle les «données de session» sur la 
carte de conducteur ou d'atelier immédiatement après l'in ­
sertion de la carte.  
138) L'appareil de contrôle met à jour les données stockées sur 
une carte de conducteur, d'atelier, d'entreprise et/ou de 
contrôleur en cours de validité avec toutes les données 
nécessaires concernant la période d'insertion 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.  
139) L'appareil de contrôle met à jour les données concernant 
l'activité du conducteur 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 conducteur et/ou d'atelier en cours de validité, avec les 
données relatives à l'activité et au lieu saisies manuelle ­
ment par le détenteur 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 stockés sur 
les cartes de conducteur et d'atelier.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 45  
141) La mise à jour des données enregistrées sur les cartes 
tachygraphiques est réalisée de telle manière que, lorsque 
cela est nécessaire compte tenu de la capacité réelle de 
stockage de la carte, les données les plus récentes rempla ­
cent les données les plus anciennes.  
142) En cas d'erreur d'écriture, l'appareil de contrôle fait une 
nouvelle tentative, à trois reprises au maximum, et en 
cas d'échec répété, déclare la carte défaillante et non vala ­
ble. 
143) Avant la libération d'une carte de conducteur, et après que 
toutes les données pertinentes ont été stockées sur la carte, 
l'appareil de contrôle remet à zéro les «données de 
session».  
3.14.2  Enregistrement et stockage sur les cartes tachygraphiques de 
deuxième génération  
144) Les cartes tachygraphiques de deuxième génération 
doivent contenir 2 applications de carte différentes, la 
première devant être rigoureusement identique à l'applica ­
tion TACHO des cartes tachygraphiques 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 conducteur ou d'atelier immédiatement après l'in ­
sertion de la carte.  
146) L'appareil de contrôle met à jour les données stockées sur 
les 2 applications des cartes de conducteur, d'atelier, d'en ­
treprise et/ou de contrôleur en cours de validité avec toutes 
les données nécessaires concernant la période d'insertion 
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 concernant 
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) stockées sur les cartes de conducteur et/ou 
d'atelier en cours de validité, avec les données relatives 
aux lieux et aux activités saisies manuellement par le 
détenteur de la carte.  
148) La mise à jour des données enregistrées sur les cartes 
tachygraphiques est réalisée de telle manière que, lorsque 
cela est nécessaire compte tenu de la capacité réelle de 
stockage de la carte, les données les plus récentes rempla ­
cent les données les plus anciennes.  
149) En cas d'erreur d'écriture, l'appareil de contrôle fait une 
nouvelle tentative, à trois reprises au maximum, et en 
cas d'échec répété, déclare la carte défaillante et non vala ­
ble. 
150) Avant la libération d'une carte de conducteur, et après que 
toutes les données pertinentes ont été stocké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'affichage doit comporter au moins 20 caractères.  
152) La taille des caractères doit être d'au moins 5 mm de 
hauteur et 3,5 mm de largeur.  
153) Le dispositif d'affichage doit prendre en charge les carac ­
tères spécifiés au chapitre 4 «Jeux de caractères» de l'ap ­
pendice 1. L'affichage 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 majus ­
cules).  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 46  
154) L'affichage doit être muni d'un éclairage non éblouissant.  
155) Les indications doivent être visibles à l'extérieur de l'ap ­
pareil de contrôle.  
156) L'appareil de contrôle doit pouvoir afficher:  
— des données concernant les anomalies,  
— des données d'avertissement,  
— des données relatives à l'accès aux menus,  
— d'autres données demandées par l'utilisateur.  
Des informations additionnelles peuvent être affichées par 
l'appareil de contrôle, à condition d'être clairement 
distinctes des informations précitées.  
157) L'affichage de l'appareil de contrôle doit utiliser les picto ­
grammes ou les combinaisons de pictogrammes énumérées 
à l'appendice 3. Des pictogrammes ou des combinaisons 
de pictogrammes additionnels peuvent également être utili ­
sés, pour autant qu'ils soient clairement distincts des picto ­
grammes ou combinaisons de pictogrammes précités.  
158) Le dispositif d'affichage doit toujours être allumé lorsque 
le véhicule est en mouvement.  
159) L'appareil de contrôle peut comporter une fonction 
manuelle ou automatique qui coupe le dispositif d'affi ­
chage lorsque le véhicule est à l'arrêt.  
Le format d'affichage est indiqué à l'appendice 5.  
3.15.1  Affichage 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 convoyeur,  
— informations sur le conducteur:  
— si son activité en cours est la CONDUITE, 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'affichage des données concernant chaque conducteur 
doit être clair, simple et dépourvu d'ambiguïté. Lorsque 
les informations relatives au conducteur et au convoyeur 
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'utilisateur d'affi ­
cher les informations sur le convoyeur.  
162) Lorsque la largeur d'affichage n'est pas suffisante pour 
afficher par défaut le mode de fonctionnement, l'appareil 
de contrôle doit afficher brièvement le nouveau mode de 
fonctionnement à chaque changement de mode.  
163) L'appareil de contrôle doit brièvement afficher le nom du 
détenteur de la carte lors de l'insertion d'une nouvelle 
carte.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 47  
164) Lorsqu'une condition «HORS CHAMP» ou «FERRY/ 
TRAIN» est ouverte, le pictogramme approprié doit appa ­
raître pour indiquer que la condition en question est 
ouverte (l'activité du conducteur en cours peut ne pas 
être affichée en même temps).  
3.15.2  Affichage d'avertissements  
165) L'appareil de contrôle utilise principalement, pour les aver ­
tissements, les pictogrammes figurant à l'appendice 3, 
complétés au besoin par des informations sous forme de 
code numérique. Un message d'avertissement dans la 
langue choisie par le conducteur peut également être 
ajouté.  
3.15.3  Menu d'accès  
166) L'appareil de contrôle doit comporter les commandes 
nécessaires dans le cadre d'un menu approprié.  
3.15.4  Autres affichages  
167) Il doit être possible d'afficher au choix, sur demande:  
— la date et l'heure UTC et le décalage de l'heure locale,  
— le contenu d'un des six tirages 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 convoyeur,  
— le temps de conduite cumulé du conducteur pour la 
semaine précédente et la semaine en cours,  
— le temps de conduite cumulé du convoyeur pour la 
semaine précédente et pour la semaine en cours,  
à titre facultatif:  
— la durée actuelle de l'activité du convoyeur (depuis sa 
sélection),  
— le temps de conduite cumulé du conducteur pour la 
semaine en cours,  
— le temps de conduite cumulé du convoyeur pour la 
période de travail journalière en cours,  
— le temps de conduite cumulé du conducteur pour la 
période de travail journalière en cours.  
168) L'affichage du contenu du tirage papier est séquentiel, 
ligne par ligne. Si la largeur d'affichage est inférieure à 
24 caractères, l'utilisateur peut visualiser l'ensemble des 
informations par un moyen approprié (plusieurs lignes, 
affichage déroulant…).  
Les lignes de tirage papier prévues pour les informations 
manuscrites peuvent être omises.  
3.16 Impression  
169) L'appareil de contrôle doit pouvoir imprimer des informa ­
tions stockées dans sa mémoire et/ou sur des cartes tachy ­
graphiques, de manière à obtenir les sept tirages papier 
suivants:  
— activités du conducteur stockées sur la carte,  
— activités du conducteur stockées sur l'unité embarquée 
sur le véhicule,  
— événements et anomalies stockés sur la carte,  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 48  
— événements et anomalies stockés sur l'unité embarquée 
sur le véhicule,  
— données techniques,  
— excès de vitesse,  
— historique des données de la carte tachygraphique 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 figurer à la fin des 
tirages papier.  
D'autres tirages papier peuvent également être obtenus à 
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 obtenus que lorsqu'une carte de conducteur 
ou d'atelier est insérée dans l'appareil de contrôle. L'appa ­
reil de contrôle met à jour les données stockées sur la carte 
en cause avant de lancer l'impression.  
171) Afin d'imprimer les «activités du conducteur 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 conduc ­
teur ou la carte d'atelier si une seule de ces cartes est 
insérée,  
— soit comporter une commande permettant de sélec ­
tionner 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'imprimante doit pouvoir imprimer 24 caractères par 
ligne.  
173) La taille des caractères doit être d'au moins 2,1 mm de 
hauteur et 1,5 mm de largeur.  
174) L'imprimante doit prendre en charge les caractères spéci ­
fiés au chapitre 4 «Jeux de caractères» de l'appendice 1.  
175) Les imprimantes doivent être conçues de telle manière que 
le degré de définition des sorties papier soit suffisant pour 
éviter toute ambiguïté à la lecture.  
176) Les tirages papier doivent conserver leurs dimensions et 
leur contenu 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 appropriée et une indica ­
tion du ou des types d'appareil de contrôle avec lesquels il 
peut être utilisé.  
178) Les tirages papier doivent rester facilement lisibles et iden ­
tifiables dans les conditions normales de stockage, en 
termes d'intensité lumineuse, d'humidité et de température, 
pendant au moins deux ans.  
179) Les tirages papier doivent être conformes au minimum aux 
spécifications d'essai définies à l'appendice 9.  
180) Il doit être également possible d'écrire à la main sur ces 
documents, par exemple pour la signature du conducteur.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 49  
181) En cas de rupture de l'alimentation en papier en cours 
d'impression, et après rechargement en papier, l'appareil 
de contrôle doit soit recommencer l'impression au début, 
soit la reprendre là où elle s'était interrompue, en faisant 
clairement référence à la partie imprimée auparavant.  
3.17 Avertissements  
182) L'appareil de contrôle doit avertir le conducteur lorsqu'il 
détecte un événement et/ou une anomalie.  
183) L'avertissement concernant une interruption de l'alimenta ­
tion électrique peut être retardé jusqu'au rétablissement du 
courant.  
184) L'appareil de contrôle prévient le conducteur 15 minutes 
avant et au moment du dépassement du temps de conduite 
continue maximal autorisé.  
185) Les avertissements doivent être visuels. Des avertissements 
sonores peuvent être produits en plus des avertissements 
visuels.  
186) Les avertissements visuels doivent être clairement identi ­
fiables par l'utilisateur, 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'appa ­
reil de contrôle et/ou être extérieurs à celui-ci.  
188) Dans ce dernier cas, ils doivent comporter le symbole «T».  
189) Les avertissements doivent durer au moins 30 secondes, 
sauf si l'utilisateur en accuse réception en appuyant sur une 
ou plusieurs touches spécifiques de l'appareil de contrôle. 
Ce premier accusé de réception ne doit pas effacer l'affi ­
chage de la cause de l'avertissement 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éception à l'aide d'une touche 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êtent pas à confusion avec ceux définis 
précédemment.  
3.18 Téléchargement de données à destination de supports externes  
192) L'appareil de contrôle doit permettre le téléchargement à la 
demande de données stockées sur sa mémoire ou sur une 
carte de conducteur vers des médias externes, par l'inter ­
médiaire d'une connexion d'étalonnage/de téléchargement. 
L'appareil de contrôle met à jour les données stockées sur 
la carte en cause avant de lancer le téléchargement.  
193) En outre, et en option, l'appareil de contrôle peut, dans 
tout mode de fonctionnement, télécharger des données par 
n'importe quel autre moyen vers une entreprise authentifiée 
par ce canal. En pareil cas, les données ainsi téléchargées 
sont soumises aux droits d'accès applicables en mode 
«entreprise».  
194) Le téléchargement ne doit ni modifier ni effacer aucune 
des données stockées.  
195) L'interface électrique de connexion pour l'étalonnage et le 
téléchargement est spécifiée à l'appendice 6.  
196) Les protocoles de téléchargement sont spécifiés à l'appen ­
dice 7.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 50  
3.19 Communication à distance pour les contrôles routiers ciblés  
197) Lorsque le contact est mis, la VU stocke, toutes les 60 
secondes, dans le dispositif de communication à distance, 
les données les plus récentes nécessaires aux fins de 
contrôles routiers ciblés. Ces données sont chiffrées et 
signées, conformément aux appendices 11 et 14.  
198) Les données qui doivent être contrôlées à distance doivent 
être disponibles pour les lecteurs 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écurité,  
— interruption d'alimentation électrique la plus longue,  
— anomalie du capteur,  
— erreur sur les données de mouvement,  
— conflit concernant le mouvement du véhicule,  
— conduite sans carte en cours de validité,  
— insertion de carte pendant la conduite,  
— données concernant la remise à l'heure,  
— données d'étalonnage, y compris les dates des deux 
derniers enregistrements d'étalonnage stockés,  
— numéro d'immatriculation du véhicule,  
— vitesse enregistrée par le tachygraphe.  
3.20 Données transmises à des dispositifs externes supplémentaires  
▼M1 
200) L’appareil de contrôle peut également être équipé d’inter ­
faces normalisées permettant l’utilisation par un dispositif 
externe, en mode opérationnel ou «étalonnage», des 
données enregistrées ou produites par le tachygraphe.  
Dans l’appendice 13, une interface ITS facultative est 
spécifiée et normalisée. D’autres interfaces d’unité embar ­
quée sur le véhicule peuvent coexister, à condition qu’elles 
respectent pleinement les exigences de l’appendice 13 en 
termes de liste minimale de données, de sécurité et de 
consentement du conducteur.  
Le consentement du conducteur ne s’applique pas aux 
données transmises par l’appareil de contrôle au réseau 
du véhicule. En cas de traitement ultérieur, hors du 
réseau du véhicule, des données à caractère personnel 
introduites dans le réseau du véhicule, il relève de la 
responsabilité du constructeur du véhicule de s’assurer 
que ce traitement de données à caractère personnel est 
conforme au règlement (UE) 2016/679 (le «règlement 
général sur la protection des données»).  
Le consentement du conducteur ne s’applique pas non plus 
aux données tachygraphiques téléchargées vers une entre ­
prise à distance (exigence 193), ce cas de figure étant 
contrôlé par le droit d’accès de la carte d’entreprise.  
Les exigences suivantes sont applicables aux données ITS 
mises à disposition par l’intermédiaire de cette interface:  
— ces données constituent un ensemble de données exis ­
tantes sélectionnées qui proviennent du dictionnaire de 
données du tachygraphe (appendice 1),  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 51  
— 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 consentement vérifiable du 
conducteur, qui accepte 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 externe avec l’interface ITS 
sera protégé par un code PIN dédié et aléatoire d’au 
moins 4 chiffres, enregistré et affichable dans chaque 
VU, 
— en aucun cas la présence de l’interface ITS ne peut 
perturber ou affecter le fonctionnement correct et la 
sécurité de la VU.  
D’autres données peuvent également être transmises en 
plus de l’ensemble de données existantes 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 permet de communiquer le statut du 
consentement du conducteur aux autres plateformes du 
réseau du véhicule.  
Lorsque le contact du véhicule est en position MARCHE, 
ces données sont transmises en permanence.  
▼B 
201) L'interface de liaison série spécifiée dans l'annexe 1B du 
règlement (CEE) n  o 3821/85, tel que modifié en dernier 
lieu, peut continuer à équiper les tachygraphes afin d'as ­
surer leur compatibilité avec les équipements de première 
génération. Quoi qu'il en soit, le consentement du conduc ­
teur est toujours nécessaire lorsque des données person ­
nelles sont transmises.  
3.21 Étalonnage  
202) La fonction d'étalonnage permet:  
— le couplage automatique du capteur de mouvement 
avec la VU,  
— le couplage automatique du dispositif GNSS externe 
avec la VU, le cas échéant,  
— l'adaptation numérique de la constante de l'appareil de 
contrôle (k) au coefficient caractéristique du véhicule 
(w), 
— la remise à l'heure au cours de la période de validité de 
la carte d'atelier insérée,  
— l'ajustement du kilométrage,  
— la mise à jour des données d'identification du capteur 
de mouvement stockées dans la mémoire,  
— la mise à jour, le cas échéant, des données d'identifi ­
cation du dispositif GNSS externe stockées dans la 
mémoire,  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 52  
— la mise à jour des types et des identifiants de tous les 
scellements en place,  
— la mise à jour ou la confirmation d'autres paramètres 
connus par l'appareil de contrôle: identification 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'étalonnage permet de rendre impos ­
sible l'utilisation de cartes tachygraphiques de première 
génération dans l'appareil de contrôle, pour autant que 
les conditions spécifiées à l'appendice 15 soient remplies.  
204) Le couplage du capteur de mouvement à la VU consiste au 
moins en:  
— la mise à jour des données d'installation du capteur de 
mouvement détenues par le capteur de mouvement (au 
besoin),  
— la copie, dans la mémoire de la VU, des données 
d'identification nécessaires du capteur 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 contenues dans le dispositif GNSS 
externe (si nécessaire),  
— la copie vers la mémoire de la VU, à partir du dispo ­
sitif GNSS externe, des données d'identification néces ­
saires 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 informa ­
tions de position du GNSS.  
206) La fonction d'étalonnage doit permettre la saisie des 
données nécessaires par l'intermédiaire de la connexion 
d'étalonnage/de téléchargement conformément au protocole 
d'étalonnage défini à l'appendice 8. La fonction d'étalon ­
nage peut également permettre la saisie des données néces ­
saires par d'autres moyens.  
3.22 Contrôles routiers d'étalonnage  
207) La fonction de contrôle routier d'étalonnage doit permettre 
la lecture du numéro de série du capteur de mouvement 
(qui peut être intégré dans l'adaptateur) 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é embar ­
quée sur le véhicule au moyen de commandes se trouvant 
dans les menus.  
209) La fonction de contrôle routier d'étalonnage doit également 
permettre le contrôle de la sélection du mode de la ligne 
de signalisation d'entrée/sortie d'étalonnage 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 «ECUAdjustmentSession», comme spécifié dans 
l'appendice 8, section 7, «Contrôle des impulsions d'essai 
— Unité fonctionnelle de contrôle des entrées/sorties».  
3.23 Remise à l'heure  
210) La fonction de remise à l'heure doit permettre de régler 
l'heure automatiquement. 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écepteur GNSS.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 53  
211) Le réglage de l’heure de l’horloge interne de la VU est 
automatiquement réajusté toutes les 12 heures. Lorsque ce 
réajustement est impossible en raison de l’indisponibilité 
du signal GNSS, 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écepteur GNSS, selon les conditions d’allumage du 
véhicule. La base temps pour le réglage automatique de 
l’heure de l’horloge interne de la VU doit être déterminée 
à partir du récepteur GNSS.  
▼B 
212) La fonction de remise à l'heure doit également permettre 
de déclencher le réglage de l'heure courante en mode 
étalonnage.  
3.24 Caractéristiques de performance  
213) L'unité embarquée sur le véhicule et le dispositif GNSS 
externe doivent pouvoir fonctionner correctement dans une 
gamme de températures allant de – 20 °C à 70 °C, et le 
capteur de mouvement dans une gamme de températures 
allant de – 40 °C à 135 °C. Le contenu de la mémoire doit 
être conservé jusqu'à des températures de – 40 °C.  
214) Le tachygraphe doit pouvoir fonctionner correctement dans 
une gamme d'humidité comprise entre 10 % et 90 %.  
215) Les scellements utilisés dans le tachygraphe intelligent 
doivent résister aux mêmes conditions que celles applica ­
bles aux composants du tachygraphe sur lesquels ils sont 
apposés.  
216) L'appareil de contrôle doit être protégé contre les surten ­
sions, l'inversion de polarités de son alimentation élec ­
trique et les courts-circuits.  
217) Le capteur de mouvement doit:  
— soit réagir à un champ magnétique qui perturbe la 
détection des mouvements du véhicule. Dans ces 
circonstances, l'unité embarquée enregistrera et 
stockera une anomalie du capteur (exigence 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 externe 
doivent être conformes à la réglementation internationale 
R10 de l'ECE-ONU et être protégés contre les décharges 
électrostatiques et transitoires.  
3.25 Matériaux  
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éca ­
nique suffisantes, et présenter des caractéristiques élec ­
triques 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 capteur de mouvement au niveau de protection IP 64, 
aux termes de la norme IEC 60529:1989, y compris les 
annexes A1:1999 et A2:2013.  
222) L'appareil de contrôle doit être conforme aux spécifica ­
tions techniques applicables en matière de conception 
ergonomique.  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 54  
223) L'appareil de contrôle doit être protégé contre les détério ­
rations accidentelles.  
3.26 Inscriptions  
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 parcourue, 
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 vitesse en miles par heure, auquel 
cas l'unité de mesure de la vitesse sera indiquée par l'abré ­
viation «mph». 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».  
▼M1 
225) Une plaque signalétique doit être fixée sur chaque compo ­
sant séparé de l’appareil de contrôle et doit comporter les 
indications suivantes:  
— nom et adresse du fabricant,  
— numéro de pièce du fabricant et année de fabrication,  
— numéro de série,  
— marque d'homologation.  
226) Lorsque l'espace disponible est insuffisant 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 de la pièce.  
▼B 
4. EXIGENCES DE FABRICATION ET EXIGENCES FONCTION ­
NELLES APPLICABLES AUX CARTES TACHYGRAPHIQUES  
4.1 Données visibles  
Le recto de la carte doit comporter:  
227) les mots «carte de conducteur» ou «carte de contrôleur» ou 
«carte d'atelier» ou «carte d'entreprise» imprimé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 rectangle bleu et entouré de 12 étoiles 
jaunes. Les codes sont les suivants: 
B 
BG 
CZ 
CY Belgique 
Bulgarie 
République tchèque 
Chypre  LV 
L 
LT 
M Lettonie 
Luxembourg 
Lituanie 
Malte  
DK Danemark  NL  Pays-Bas  
D 
EST Allemagne 
Estonie  A 
PL Autriche 
Pologne  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 55  
GR Grèce  P 
RO 
SK 
SLO  Portugal 
Roumanie 
Slovaquie 
Slovénie  
E Espagne  FIN  Finlande  
F 
HR 
H France 
Croatie 
Hongrie  S Suède  
IRL Irlande  UK  Royaume-Uni  
I Italie  
230) des indications particulières concernant la carte délivrée, 
numérotées comme suit:  
Carte du conducteur  Carte de contrôleur  Carte d'entreprise ou d'ate ­
lier 
1. nom du conducteur  nom de l'organisme de 
contrôle  nom de l'entreprise ou de 
l'atelier  
2. prénom(s) du conducteur  nom du contrôleur 
(le cas échéant)  nom du détenteur de la 
carte 
(le cas échéant)  
3. date de naissance du 
conducteur  prénom(s) du contrôleur 
(le cas échéant)  prénom(s) du détenteur 
de la carte 
(le cas échéant)  
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'autorité qui a délivré la carte (peut être imprimée au verso)  
4.d un numéro différent de celui indiqué au point 5, à des fins administratives (mention 
facultative)  
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. photographie du conducteur  photographie du contrôleur 
(facultatif)  photographie de l'instal ­
lateur (facultatif)  
7. signature du détenteur (facultatif)  
8. lieu habituel de résidence, 
ou adresse postale du déten ­
teur (facultatif)  adresse postale de l'orga ­
nisme de contrôle  adresse postale de l'en ­
treprise ou de l'atelier  
231) Les dates sont indiquées sous la forme «jj/mm/aaaa» ou 
«jj.mm.aaaa» (jour, mois, année).  
Le verso de la carte doit comporter:  
232) une légende des numéros indiqués au recto;  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 56  
233) avec l'accord écrit exprès du détenteur, des informations 
non liées à l'administration de la carte peuvent également 
être indiquées, pour autant qu'elles ne modifient en rien 
l'utilisation du modèle comme carte tachygraphique.  
234) Les cartes tachygraphiques doivent être imprimées sur les 
fonds de couleur suivants:  
— carte de conducteur: blanc,  
— carte de contrôleur: bleu,  
— carte d'atelier: rouge,  
— carte d'entreprise: jaune.  
235) Les cartes tachygraphiques présentent les éléments de 
protection suivants contre la contrefaçon et la manipula ­
tion: 
— impression de fond de sécurité finement guillochée et 
irisée,  
— chevauchement de l'impression de fond de sécurité et 
de la photographie,  
— au moins une ligne bicolore micro-imprimée.
  
► (1) M1 
236) Après consultation de la Commission, les États membres 
peuvent ajouter des couleurs et des inscriptions, tels que 
des symboles nationaux et des éléments de sécurité, sans 
préjudice des autres dispositions de la présente annexe.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 57  
237) Les cartes temporaires visées à l'article 26, paragraphe 4, 
du règlement (UE) n  o 165/2014 doivent être conformes 
aux dispositions de la présente annexe.  
4.2 Sécurité  
La sécurité du système vise à protéger l'intégrité et l'authenticité des 
données échangées entre les cartes et l'appareil de contrôle, ainsi que 
l'intégrité et l'authenticité des données téléchargées à partir des 
cartes, en autorisant uniquement certaines opérations d'inscription 
sur les cartes par l'appareil de contrôle, en décryptant certaines 
données, en excluant toute possibilité de falsification des données 
stockées sur les cartes, en empêchant les manipulations et en détec ­
tant toute tentative en ce sens.  
238) Afin d'assurer cette sécurité, les cartes tachygraphiques 
doivent satisfaire aux exigences de sécurité définies dans 
les appendices 10 et 11.  
239) Les cartes tachygraphiques doivent pouvoir être lues par 
d'autres appareils, tels que des micro-ordinateurs.  
4.3 Normes  
240) Les cartes tachygraphiques doivent être conformes aux 
normes suivantes:  
— ISO/IEC 7810 Cartes d'identification — Caractéris ­
tiques physiques,  
— ISO/IEC 7816 Cartes d'identification — Cartes à 
circuit(s) intégré(s):  
— Partie 1: caractéristiques physiques,  
— Partie 2: dimensions et emplacement des contacts 
(ISO/IEC 7816-2:2007),  
— Partie 3: interface électrique et protocoles de trans ­
mission (ISO/IEC 7816-3:2006),  
— Partie 4: organisation, sécurité et commandes pour 
les échanges (ISO/IEC 7816-4:2013 + Cor 1:2014),  
— Partie 6: éléments de données intersectoriels pour 
les échanges (ISO/IEC 7816-6:2004 + Cor 1:2006),  
— Partie 8: commandes pour des opérations de sécu ­
rité (ISO/IEC 7816-8:2004).  
— Les cartes tachygraphiques doivent être testées confor ­
mément à la norme ISO/IEC 10373-3: 2010 Cartes 
d'identification — Méthodes d'essai — Partie 3: 
cartes à circuit(s) intégré(s) à contacts et dispositifs 
d'interface assimilés.  
4.4 Spécifications environnementales et électriques  
241) Les cartes tachygraphiques doivent pouvoir fonctionner 
correctement dans toutes les conditions climatiques norma ­
lement observé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» signifiant d'une durée infé ­
rieure ou égale à 4 heures et survenant au maximum à 
100 reprises au cours de la durée de vie de la carte.  
242) Les cartes tachygraphiques doivent pouvoir fonctionner 
correctement dans une gamme d'humidité comprise entre 
10 % et 90 %.  
243) Les cartes tachygraphiques doivent pouvoir fonctionner 
correctement pendant une période de cinq ans si elles 
sont utilisées conformément aux spécifications environne ­
mentales et électriques.  
244) En fonctionnement, les cartes tachygraphiques doivent 
satisfaire à la réglementation R10 de l'ECE-ONU, relative 
à la compatibilité électromagnétique, et doivent être proté ­
gées contre les décharges électrostatiques.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 58  
4.5 Stockage 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 vitesses sont enregistrées au kilomètre/heure près,  
— les positions (latitudes et longitudes) sont enregistrées en degrés 
et en minutes, au dixième de minute près.  
Les fonctions, les commandes et les structures logiques des cartes 
tachygraphiques qui satisfont aux exigences en matière de stockage 
des données sont spécifiées à l'appendice 2.  
Sauf indication contraire, le stockage de données sur les cartes 
tachygraphiques doit être organisé de telle manière que les 
données nouvelles remplacent les données stockées les plus 
anciennes dans les cas où la mémoire prévue pour les enregistre ­
ments concernés est épuisée.  
245) Le présent paragraphe précise la capacité minimale de 
stockage des données des divers fichiers d'application. 
Les cartes tachygraphiques doivent pouvoir indiquer à l'ap ­
pareil de contrôle la capacité réelle de stockage de ces 
fichiers.  
246) Toutes les données supplémentaires qui peuvent être 
stockées sur des cartes tachygraphiques, liées à d'autres 
applications éventuellement présentes sur la carte, 
doivent être stockées conformément à la directive 
95/46/CE à la directive 2002/58/CE et en conformité 
avec l'article 7 du règlement (UE) n  o 165/2014.  
247) Chaque fichier maître (MF) d'une carte tachygraphique 
doit contenir jusqu'à cinq fichiers élémentaires (EF) pour 
la gestion de la carte, l'application et les identifications de 
puce, ainsi que deux fichiers dédiés (DF):  
— DF Tachograph, qui contient l'application accessible à 
la première génération de VU et qui est également 
présent sur les cartes tachygraphiques de première 
génération,  
— DF Tachograph_G2, qui contient l'application acces ­
sible à la deuxième génération de VU et qui est seule ­
ment présent sur les cartes tachygraphiques de 
deuxième génération.  
L'intégralité des détails relatifs à la structure des cartes 
tachygraphiques est spécifiée dans l'appendice 2.  
4.5.1  Fichiers élémentaires pour l'identification et la gestion des cartes  
4.5.2  Identification des cartes à circuit intégré  
248) Les cartes tachygraphiques doivent pouvoir stocker les 
données suivantes pour l'identification des cartes intelli ­
gentes:  
— arrêt d'horloge,  
— numéro de série de la carte (y compris les références 
de fabrication),  
— numéro d'homologation de la carte,  
— identification personnelle de la carte,  
— identification de l'intégrateur,  
— identificateur du circuit intégré.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 59  
4.5.2.1 I d e n t i f i c a t i o n d u m i c r o p r o c e s s e u r  
249) Les cartes tachygraphiques doivent pouvoir stocker les 
données suivantes pour l'identification des circuits inté ­
grés:  
— numéro de série du circuit intégré,  
— références de fabrication du circuit intégré.  
4.5.2.2 D I R ( u n i q u e m e n t p r é s e n t s u r l e s c a r t e s t a c h y ­
g r a p h i q u e s d e d e u x i è m e g é n é r a t i o n )  
250) Les cartes tachygraphiques doivent pouvoir stocker les 
objets de données pour l'identification des applications 
spécifiés dans l'appendice 2.  
4.5.2.3 I n f o r m a t i o n s A T R ( c o n d i t i o n n e l l e s , p r é s e n t e s 
u n i q u e m e n t s u r l e s c a r t e s t a c h y g r a p h i q u e s d e 
d e u x i è m e g é n é r a t i o n )  
251) Les cartes tachygraphiques doivent pouvoir stocker l'objet 
de données suivant relatif aux informations sur la période 
étendue:  
— lorsque la carte de tachygraphe 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.  
4.5.2.4 I n f o r m a t i o n s r e l a t i v e s à l a p é r i o d e é t e n d u e 
( c o n d i t i o n n e l l e s , p r é s e n t e s u n i q u e m e n t s u r l e s 
c a r t e s t a c h y g r a p h i q u e s d e d e u x i è m e g é n é r a t i o n )  
252) Les cartes tachygraphiques doivent pouvoir stocker les 
objets de données suivants relatifs aux informations sur 
la période étendue:  
— lorsque la carte de tachygraphe prend en charge les 
champs de période étendue, les objets de données rela ­
tifs aux informations sur la période étendue spécifiés 
dans l'appendice 2.  
4.5.3  Carte de conducteur  
4.5.3.1 A p p l i c a t i o n t a c h y g r a p h i q u e ( a c c e s s i b l e a u x 
u n i t é s e m b a r q u é e s d e p r e m i è r e e t d e u x i è m e 
g é n é r a t i o n s )  
4.5.3.1.1 Identification des applications  
253) La carte de conducteur doit pouvoir stocker les données 
suivantes pour l'identification des applications:  
— identification de l'application tachygraphique,  
— identification du type de carte tachygraphique.  
4.5.3.1.2 Clés et certificats  
254) La carte de conducteur doit être en mesure de stocker 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 conducteur doit pouvoir stocker 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étente 
pour la délivrance, date de délivrance,  
— date de début de validité de la carte, et date d'expira ­
tion. 
4.5.3.1.4 Identification du détenteur de la carte  
256) La carte de conducteur doit pouvoir stocker les données 
suivantes pour l'identification du détenteur de la carte:  
— nom du détenteur,  
— prénom(s) du détenteur,  
— date de naissance,  
— langue habituelle.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 60  
4.5.3.1.5 Téléchargement (download) d'une carte  
257) La carte de conducteur doit permettre le stockage des 
données suivantes concernant le téléchargement des cartes:  
— date et heure du dernier téléchargement d'une carte (à 
d'autres fins que le contrôle).  
258) La carte de conducteur doit permettre le stockage d'un de 
ces enregistrements.  
4.5.3.1.6 Renseignements concernant le permis de conduire  
259) La carte de conducteur doit pouvoir stocker les données 
suivantes concernant le permis de conduire:  
— État membre qui a délivré le permis, nom de l'autorité 
compétente pour la délivrance,  
— numéro du permis de conduire (à la date de délivrance 
de la carte).  
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 stockage des 
données liées aux événements suivants détectés par l'appa ­
reil de contrôle alors que la carte est insérée:  
— chevauchement temporel (lorsque la carte est la cause 
de l'événement),  
— insertion d'une carte en cours de conduite (lorsque cet 
événement concerne la carte),  
— clôture incorrecte de la session précédente (lorsque cet 
événement concerne la carte),  
— interruption de l'alimentation électrique,  
— erreur sur les données de mouvement,  
— tentatives d'atteinte à la sécurité.  
261) La carte de conducteur doit permettre le stockage des 
données suivantes concernant ces événements:  
— code d'événement,  
— date et heure du début de l'événement (ou de l'insertion 
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'immatriculation du véhicule 
dans lequel l'événement est survenu.  
Remarque: concernant l'événement «chevauchement 
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'insertion 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 apparu.  
Remarque: concernant l'événement «clôture incorrecte 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'insertion de la 
carte correspondant à la session incorrectement clôtu ­
rée, 
— la date et l'heure de la fin de l'événement doivent 
correspondre à la date et à l'heure de l'insertion de la 
carte pour la session au cours de laquelle l'événement a 
été détecté (session en cours),  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 61  
— les données relatives au véhicule doivent correspondre 
au véhicule dans lequel la session a été incorrectement 
clôturée.  
262) La carte de conducteur doit permettre le stockage des 
données concernant 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 stockage des 
données relatives aux anomalies suivantes détectées par 
l'appareil de contrôle alors que la carte est insérée:  
▼M1 
— anomalie de la carte (lorsque la carte est à l’origine de 
l’anomalie),  
▼B 
— anomalie de l'appareil de contrôle.  
264) La carte de conducteur doit permettre le stockage des 
données suivantes pour ces anomalies:  
— code de l'anomalie,  
— date et heure du début de l'anomalie (ou de l'insertion 
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'immatriculation du véhicule 
dans lequel l'anomalie est survenue.  
265) La carte de conducteur doit permettre le stockage 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 conducteur  
266) La carte de conducteur doit pouvoir stocker, pour chaque 
jour civil au cours duquel la carte a été utilisée ou le 
conducteur a saisi les activités manuellement, les 
données suivantes:  
— date,  
— compteur de présence journalière (augmenté d'une 
unité pour chacun de ces jours civils),  
— distance totale parcourue par le conducteur pendant 
cette journée,  
— situation du conducteur à 00h00,  
— les changements d'activité du conducteur et/ou les 
changements de situation de conduite et/ou l'insertion 
ou le retrait de la carte de conducteur:  
— situation de conduite (ÉQUIPAGE, SEUL),  
— lecteur (CONDUCTEUR, CONVOYEUR),  
— situation de la carte (INSÉRÉE, NON INSÉRÉE),  
— activité (CONDUITE, DISPONIBILITÉ, 
TRAVAIL, PAUSE/REPOS),  
— heure du changement.  
267) La mémoire de la carte de conducteur doit permettre le 
stockage des données relatives à l'activité du conducteur 
pendant au moins 28 jours (l'activité moyenne d'un 
conducteur est définie comme 93 changements d'activité 
par jour).  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 62  
268) Les données énumérées aux exigences 261, 264 et 266 
doivent être stockées d'une manière permettant de 
retrouver les activités dans l'ordre de leur occurrence, 
même en cas de chevauchement temporel.  
4.5.3.1.10 Données concernant les véhicules utilisés  
269) La carte de conducteur doit pouvoir stocker, 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 comprend 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 suivantes:  
— date et heure de la première utilisation du véhicule 
(c'est-à-dire de la première insertion 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'immatriculation du véhicule.  
270) La carte de conducteur doit pouvoir stocker au moins 84 
enregistrements de ce type.  
4.5.3.1.11 Lieux de début/de fin des périodes journalières de travail  
271) La carte de conducteur doit permettre le stockage des 
données suivantes relatives aux lieux de début et/ou de 
fin des périodes journalières de travail, saisies par le 
conducteur:  
— 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 conducteur doit permettre le 
stockage d'au moins 42 paires d'enregistrements de ce 
type.  
4.5.3.1.12 Données concernant les sessions pour chaque carte  
273) La carte de conducteur doit permettre le stockage des 
données suivantes relatives au véhicule dans lequel s'est 
ouverte la session en cours:  
— date et heure d'ouverture de la session (c.-à-d. de l'in ­
sertion de la carte), à la seconde près,  
— numéro et État membre d'immatriculation du véhicule.  
4.5.3.1.13 Données relatives aux activités de contrôle  
274) La carte de conducteur doit permettre le stockage des 
données suivantes concernant 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é ­
chargement à partir de la VU et/ou à partir de la carte 
(voir remarque)],  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 63  
— période téléchargée, le cas échéant,  
— numéro et État membre d'immatriculation du véhicule 
dans lequel le contrôle a été effectué.  
Remarque: le téléchargement 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 conducteur doit permettre le stockage d'un de 
ces enregistrements.  
4.5.3.1.14 Données concernant les conditions particulières  
276) La carte de conducteur doit permettre le stockage 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 conducteur doit pouvoir stocker au moins 56 
enregistrements de ce type.  
4.5.3.2 A p p l i c a t i o n t a c h y g r a p h i q u e d e d e u x i è m e g é n é ­
r a t i o n ( n o n a c c e s s i b l e a u x V U d e p r e m i è r e g é n é ­
r a t i o n )  
4.5.3.2.1 Identification des applications  
278) La carte de conducteur doit pouvoir stocker les données 
suivantes pour l'identification des applications:  
— identification de l'application tachygraphique,  
— identification du type de carte tachygraphique.  
4.5.3.2.2 Clés et certificats  
279) La carte de conducteur doit être en mesure de stocker 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 conducteur doit pouvoir stocker 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étente 
pour la délivrance, date de délivrance,  
— date de début de validité de la carte, et date d'expira ­
tion. 
4.5.3.2.4 Identification du détenteur de la carte  
281) La carte de conducteur doit pouvoir stocker les données 
suivantes pour l'identification du détenteur de la carte:  
— nom du détenteur,  
— prénom(s) du détenteur,  
— date de naissance,  
— langue habituelle.  
4.5.3.2.5 Téléchargement (download) d'une carte  
282) La carte de conducteur doit permettre le stockage des 
données suivantes concernant le téléchargement des cartes:  
— date et heure du dernier téléchargement d'une carte (à 
d'autres fins que le contrôle).  
283) La carte de conducteur doit permettre le stockage d'un de 
ces enregistrements.  
4.5.3.2.6 Renseignements concernant le permis de conduire  
284) La carte de conducteur doit pouvoir stocker les données 
suivantes concernant le permis de conduire:  
— État membre qui a délivré le permis, nom de l'autorité 
compétente pour la délivrance,  
— numéro du permis de conduire (au moment de la déli ­
vrance de la carte).  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 64  
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.  
285) La carte de conducteur doit permettre le stockage des 
données liées aux événements suivants détectés par l'appa ­
reil de contrôle alors que la carte est insérée:  
— chevauchement temporel (lorsque la carte est la cause 
de l'événement),  
— insertion d'une carte en cours de conduite (lorsque cet 
événement concerne la carte),  
— clôture incorrecte de la session précédente (lorsque cet 
événement concerne la carte),  
— interruption de l'alimentation électrique,  
— erreur de communication avec le dispositif de commu ­
nication à distance,  
— absence d'informations de positionnement en prove ­
nance du récepteur GNSS,  
— erreur de communication avec le dispositif GNSS 
externe,  
— erreur sur les données de mouvement,  
— conflit concernant le mouvement du véhicule,  
— tentatives d'atteinte à la sécurité,  
— conflit temporel.  
286) La carte de conducteur doit permettre le stockage des 
données suivantes concernant ces événements:  
— code d'événement,  
— date et heure du début de l'événement (ou de l'insertion 
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'immatriculation du véhicule 
dans lequel l'événement est survenu.  
Remarque: concernant l'événement «chevauchement 
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'insertion 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 apparu.  
Remarque: concernant l'événement «clôture incorrecte 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'insertion de la 
carte correspondant à la session incorrectement clôtu ­
rée, 
— la date et l'heure de la fin de l'événement doivent 
correspondre à la date et à l'heure de l'insertion de la 
carte pour la session au cours de laquelle l'événement a 
été détecté (session en cours),  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 65  
— les données relatives au véhicule doivent correspondre 
au véhicule dans lequel la session a été incorrectement 
clôturée.  
287) La carte de conducteur doit permettre le stockage des 
données concernant 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.  
288) La carte de conducteur doit permettre le stockage des 
données relatives aux anomalies suivantes détectées par 
l'appareil de contrôle alors que la carte est insérée:  
▼M1 
— anomalie de la carte (lorsque la carte est à l’origine de 
l’anomalie),  
▼B 
— anomalie de l'appareil de contrôle.  
289) La carte de conducteur doit permettre le stockage des 
données suivantes pour ces anomalies:  
— code de l'anomalie,  
— date et heure du début de l'anomalie (ou de l'insertion 
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'immatriculation du véhicule 
dans lequel l'anomalie est survenue.  
290) La carte de conducteur doit permettre le stockage 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 conducteur  
291) La carte de conducteur doit pouvoir stocker, pour chaque 
jour civil au cours duquel la carte a été utilisée ou le 
conducteur a saisi les activités manuellement, les 
données suivantes:  
— date,  
— compteur de présence journalière (augmenté d'une 
unité pour chacun de ces jours civils),  
— distance totale parcourue par le conducteur pendant 
cette journée,  
— situation du conducteur à 00h00,  
— les changements d'activité du conducteur; et/ou les 
changements de situation de conduite, et/ou l'insertion 
ou le retrait de la carte de conducteur:  
— situation de conduite (ÉQUIPAGE, SEUL),  
— lecteur (CONDUCTEUR, CONVOYEUR),  
— situation de la carte (INSÉRÉE, NON INSÉRÉE),  
— activité (CONDUITE, DISPONIBILITÉ, 
TRAVAIL, PAUSE/REPOS),  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 66  
— heure du changement.  
292) La mémoire de la carte de conducteur doit permettre le 
stockage des données relatives à l'activité du conducteur 
pendant au moins 28 jours (l'activité moyenne d'un 
conducteur est définie comme 93 changements d'activité 
par jour).  
293) Les données énumérées aux exigences 286, 289 et 291 
doivent être stockées d'une manière permettant de 
retrouver les activités dans l'ordre de leur occurrence, 
même en cas de chevauchement temporel.  
4.5.3.2.10 Données concernant les véhicules utilisés  
294) La carte de conducteur doit pouvoir stocker, 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 comprend 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 suivantes:  
— date et heure de la première utilisation du véhicule 
(c'est-à-dire de la première insertion 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 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'immatriculation du véhicule,  
— numéro d'identification du véhicule.  
295) La carte de conducteur doit pouvoir stocker au moins 84 
enregistrements de ce type.  
4.5.3.2.11 Lieux et positions de début/fin des périodes journalières de travail  
296) La carte de conducteur doit permettre le stockage des 
données suivantes relatives aux lieux de début et/ou de 
fin des périodes journalières de travail, saisies par le 
conducteur:  
— 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 conducteur doit permettre le 
stockage d'au moins 84 paires d'enregistrements de ce 
type. ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 67  
4.5.3.2.12 Données concernant les sessions pour chaque carte  
298) La carte de conducteur doit permettre le stockage des 
données suivantes relatives au véhicule dans lequel s'est 
ouverte la session en cours:  
— date et heure d'ouverture de la session (c.-à-d. de l'in ­
sertion de la carte), à la seconde près,  
— numéro et État membre d'immatriculation du véhicule.  
4.5.3.2.13 Données relatives aux activités de contrôle  
299) La carte de conducteur doit permettre le stockage des 
données suivantes concernant 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é ­
chargement à partir de la VU et/ou à partir de la carte 
(voir remarque)],  
— période téléchargée, le cas échéant,  
— numéro et État membre d'immatriculation du véhicule 
dans lequel le contrôle a été effectué.  
Remarque: les exigences de sécurité impliquent que le 
téléchargement d'une carte ne sera enregistré que s'il est 
effectué par l'intermédiaire d'un appareil de contrôle.  
300) La carte de conducteur doit permettre le stockage d'un de 
ces enregistrements.  
4.5.3.2.14 Données concernant les conditions particulières  
301) La carte de conducteur doit permettre le stockage 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 conducteur doit pouvoir stocker au moins 56 
enregistrements de ce type.  
4.5.3.2.15 Données concernant les unités embarquées sur véhicule qui ont été 
utilisées  
303) La carte de conducteur doit permettre le stockage des 
données suivantes relatives aux différentes unités embar ­
qué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 insertion 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 conducteur doit pouvoir stocker au moins 84 
enregistrements de ce type.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 68  
4.5.3.2.16 Données relatives aux lieux où les trois heures de temps de conduite 
accumulé ont été atteintes  
305) La carte de conducteur doit permettre le stockage des 
données suivantes relatives à la position du véhicule 
lorsque le temps de conduite accumulé atteint un multiple 
de trois heures:  
— la date et l’heure où le temps de conduite accumulé 
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,  
— le kilométrage du véhicule.  
306) La carte de conducteur doit pouvoir stocker au moins 252 
enregistrements de ce type.  
▼B 
4.5.4  Carte d'atelier  
4.5.4.1 A p p l i c a t i o n t a c h y g r a p h i q u e ( a c c e s s i b l e a u x 
u n i t é s e m b a r q u é e s d e p r e m i è r e e t d e u x i è m e 
g é n é r a t i o n s )  
4.5.4.1.1 Identification des applications  
307) La carte d'atelier doit permettre le stockage des données 
suivantes pour l'identification des applications:  
— identification de l'application tachygraphique,  
— identification du type de carte tachygraphique.  
4.5.4.1.2 Clés et certificats  
308) La carte d'atelier doit être en mesure de stocker un certain 
nombre de certificats et de clés cryptographiques, comme 
spécifié dans l'appendice 11, partie A.  
309) La carte d'atelier doit permettre le stockage d'un numéro 
personnel d'identification (code PIN).  
4.5.4.1.3 Identification de carte  
310) La carte d'atelier doit permettre le stockage 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étente 
pour la délivrance, date de délivrance,  
— date de début de validité de la carte, et date d'expira ­
tion. 
4.5.4.1.4 Identification du détenteur de la carte  
311) La carte d'atelier doit permettre le stockage des données 
suivantes pour l'identification du détenteur de la carte:  
— nom de l'atelier,  
— adresse de l'atelier,  
— nom du détenteur,  
— prénom(s) du détenteur,  
— langue habituelle.  
4.5.4.1.5 Téléchargement (download) d'une carte  
312) La carte d'atelier doit permettre le stockage des enregis ­
trements de données relatives au téléchargement d'une 
carte de la même manière qu'une carte de conducteur.  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 69  
4.5.4.1.6 Données concernant l'étalonnage et la remise à l'heure  
313) La carte d'atelier doit permettre le stockage des enregis ­
trements 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 pouvoir contenir 
les données suivantes:  
— objet de l'étalonnage (activation, première installation, 
installation, inspection périodique),  
— identification du véhicule,  
— paramètres mis à jour ou confirmés [w, k, l, taille des 
pneumatiques, réglage du limiteur de vitesse, compteur 
kilométrique (valeurs nouvelle et ancienne), date et 
heure (valeurs nouvelle et ancienne)],  
— identification 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 capteur de mouvement).  
315) La carte d'atelier doit permettre le stockage d'au moins 88 
enregistrements de ce type.  
316) La carte d'atelier doit comporter un compteur indiquant le 
nombre total d'étalonnages réalisés avec la carte.  
317) La carte d'atelier doit comporter un compteur indiquant le 
nombre d'étalonnages réalisés depuis le dernier télécharge ­
ment.  
4.5.4.1.7 Données relatives aux événements et aux anomalies  
318) La carte d'atelier doit permettre le stockage des enregis ­
trements 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 stockage 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 conducteur  
320) La carte d'atelier doit permettre le stockage de données 
concernant l'activité du conducteur de la même manière 
que la carte de conducteur.  
321) La carte d'atelier doit permettre le stockage de données 
concernant l'activité du conducteur pendant au moins 1 
jour d'activité moyenne du conducteur.  
4.5.4.1.9 Données concernant les véhicules utilisés  
322) La carte d'atelier doit permettre le stockage des enregis ­
trements de données relatives aux véhicules utilisés de la 
même manière que la carte de conducteur.  
323) La carte d'atelier doit permettre le stockage d'au moins 4 
enregistrements de ce type.  
4.5.4.1.10 Données concernant le début et/ou la fin des périodes de travail 
journalières  
324) La carte d'atelier doit permettre le stockage des enregis ­
trements de données relatives au début et/ou à la fin des 
périodes de travail journalières de la même manière qu'une 
carte de conducteur.  
325) La carte d'atelier doit permettre le stockage d'au moins 3 
paires d'enregistrements de ce type.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 70  
4.5.4.1.11 Données concernant les sessions pour chaque carte  
326) La carte d'atelier doit permettre le stockage des enregis ­
trements de données relatives à une session de carte de la 
même manière qu'une carte de conducteur.  
4.5.4.1.12 Données relatives aux activités de contrôle  
327) La carte d'atelier doit permettre le stockage des enregis ­
trements de données relatives aux activités de contrôle de 
la même manière qu'une carte de conducteur.  
4.5.4.1.13 Données concernant les conditions particulières  
328) La carte d'atelier doit permettre le stockage des données 
relatives aux conditions particulières de la même manière 
qu'une carte de conducteur.  
329) La carte d'atelier doit permettre le stockage d'au moins 2 
enregistrements de ce type.  
4.5.4.2 A p p l i c a t i o n t a c h y g r a p h i q u e d e d e u x i è m e g é n é ­
r a t i o n ( n o n a c c e s s i b l e a u x V U d e p r e m i è r e g é n é ­
r a t i o n )  
4.5.4.2.1 Identification des applications  
330) La carte d'atelier doit permettre le stockage des données 
suivantes pour l'identification des applications:  
— identification de l'application tachygraphique,  
— identification du type de carte tachygraphique.  
4.5.4.2.2 Clés et certificats  
331) La carte d'atelier doit être en mesure de stocker un certain 
nombre de certificats et de clés cryptographiques, comme 
spécifié dans l'appendice 11, partie B.  
332) La carte d'atelier doit permettre le stockage d'un numéro 
personnel d'identification (code PIN).  
4.5.4.2.3 Identification de carte  
333) La carte d'atelier doit permettre le stockage 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étente 
pour la délivrance, date de délivrance,  
— date de début de validité de la carte, et date d'expira ­
tion. 
4.5.4.2.4 Identification du détenteur de la carte  
334) La carte d'atelier doit permettre le stockage des données 
suivantes pour l'identification du détenteur de la carte:  
— nom de l'atelier,  
— adresse de l'atelier,  
— nom du détenteur,  
— prénom(s) du détenteur,  
— langue habituelle.  
4.5.4.2.5 Téléchargement (download) d'une carte  
335) La carte d'atelier doit permettre le stockage des enregis ­
trements de données relatives au téléchargement d'une 
carte de la même manière qu'une carte de conducteur.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 71  
4.5.4.2.6 Données concernant l'étalonnage et la remise à l'heure  
336) La carte d'atelier doit permettre le stockage des enregis ­
trements 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 pouvoir contenir 
les données suivantes:  
— objet de l'étalonnage (activation, première installation, 
installation, inspection périodique),  
— identification du véhicule,  
— paramètres mis à jour ou confirmés [w, k, l, taille des 
pneumatiques, réglage du limiteur de vitesse, compteur 
kilométrique (valeurs nouvelle et ancienne), date et 
heure (valeurs nouvelle et ancienne)],  
— identification de l'appareil de contrôle (numéros des 
pièces de la VU, numéro de série de la VU, du 
capteur de mouvement, du dispositif de communication 
à distance et du dispositif GNSS externe, le cas 
échéant),  
— type et identifiant de tous les scellements en place,  
— possibilité pour la VU d'utiliser les cartes tachygra ­
phiques de première génération (activées ou non).  
338) La carte d'atelier doit permettre le stockage d'au moins 88 
enregistrements de ce type.  
339) La carte d'atelier doit comporter un compteur indiquant le 
nombre total d'étalonnages réalisés avec la carte.  
340) La carte d'atelier doit comporter un compteur indiquant le 
nombre d'étalonnages réalisés depuis le dernier télécharge ­
ment.  
4.5.4.2.7 Données relatives aux événements et aux anomalies  
341) La carte d'atelier doit permettre le stockage des enregis ­
trements 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 stockage 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 conducteur  
343) La carte d'atelier doit permettre le stockage de données 
concernant l'activité du conducteur de la même manière 
que la carte de conducteur.  
344) La carte d'atelier doit permettre le stockage de données 
concernant l'activité du conducteur pendant au moins 1 
jour d'activité moyenne du conducteur.  
4.5.4.2.9 Données concernant les véhicules utilisés  
345) La carte d'atelier doit permettre le stockage des enregis ­
trements de données relatives aux véhicules utilisés de la 
même manière que la carte de conducteur.  
346) La carte d'atelier doit permettre le stockage d'au moins 4 
enregistrements de ce type.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 72  
4.5.4.2.10 Données concernant le début et/ou la fin des périodes de travail 
journalières  
347) La carte d'atelier doit permettre le stockage des enregis ­
trements de données relatives au début et/ou à la fin des 
périodes de travail journalières de la même manière qu'une 
carte de conducteur.  
348) La carte d'atelier doit permettre le stockage d'au moins 3 
paires d'enregistrements de ce type.  
4.5.4.2.11 Données concernant les sessions pour chaque carte  
349) La carte d'atelier doit permettre le stockage des enregis ­
trements de données relatives à une session de carte de la 
même manière qu'une carte de conducteur.  
4.5.4.2.12 Données relatives aux activités de contrôle  
350) La carte d'atelier doit permettre le stockage des enregis ­
trements de données relatives aux activités de contrôle de 
la même manière qu'une carte de conducteur.  
4.5.4.2.13 Données concernant les unités embarquées sur véhicule qui ont été 
utilisées  
351) La carte d'atelier doit permettre le stockage 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 du 
véhicule (c'est-à-dire de la première insertion 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.  
352) La carte d'atelier doit permettre le stockage d'au moins 4 
enregistrements de ce type.  
▼M1 
4.5.4.2.14 Données relatives aux lieux où les trois heures de temps de conduite 
accumulé ont été atteintes  
353) La carte d’atelier doit permettre le stockage des données 
suivantes relatives à la position du véhicule lorsque le 
temps de conduite accumulé atteint un multiple de trois 
heures:  
— la date et l’heure où le temps de conduite accumulé 
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,  
— le kilométrage du véhicule.  
354) La carte d’atelier doit permettre le stockage d’au moins 18 
enregistrements de ce type.  
▼B 
4.5.4.2.15 Données concernant les conditions particulières  
355) La carte d'atelier doit permettre le stockage des données 
relatives aux conditions particulières de la même manière 
qu'une carte de conducteur.  
356) La carte d'atelier doit permettre le stockage d'au moins 2 
enregistrements de ce type.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 73  
4.5.5  Carte de contrôleur  
4.5.5.1 A p p l i c a t i o n t a c h y g r a p h i q u e ( a c c e s s i b l e a u x 
u n i t é s e m b a r q u é e s d e p r e m i è r e e t d e u x i è m e 
g é n é r a t i o n s )  
4.5.5.1.1 Identification des applications  
357) La carte de contrôleur doit permettre le stockage des 
données suivantes pour l'identification des applications:  
— identification de l'application tachygraphique,  
— identification du type de carte tachygraphique.  
4.5.5.1.2 Clés et certificats  
358) La carte de contrôleur doit être en mesure de stocker 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 stockage 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étente 
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 stockage des 
données suivantes pour l'identification du détenteur de la 
carte:  
— nom de l'organisme de contrôle,  
— adresse de l'organisme de contrôle,  
— nom du détenteur,  
— 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 stockage des 
données suivantes relatives aux activités de contrôle:  
— date et heure du contrôle,  
— le type de contrôle (affichage et/ou tirage papier et/ou 
téléchargement depuis la VU et/ou téléchargement 
depuis la carte et/ou contrôle d'étalonnage sur route),  
— période téléchargée (le cas échéant),  
— numéro et autorité nationale d'immatriculation du véhi ­
cule contrôlé,  
— numéro de la carte de conducteur contrôlée et État 
membre qui l'a délivrée.  
362) La carte de contrôleur doit permettre le stockage d'au 
moins 230 enregistrements de ce type.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 74  
4.5.5.2 A p p l i c a t i o n t a c h y g r a p h i q u e d e d e u x i è m e g é n é ­
r a t i o n ( n o n a c c e s s i b l e a u x V U d e p r e m i è r e g é n é ­
r a t i o n )  
4.5.5.2.1 Identification des applications  
363) La carte de contrôleur doit permettre le stockage des 
données suivantes pour l'identification des applications:  
— identification de l'application tachygraphique,  
— identification du type de carte tachygraphique.  
4.5.5.2.2 Clés et certificats  
364) La carte de contrôleur doit être en mesure de stocker 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 stockage 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étente 
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 stockage des 
données suivantes pour l'identification du détenteur de la 
carte:  
— nom de l'organisme de contrôle,  
— adresse de l'organisme de contrôle,  
— nom du détenteur,  
— prénom(s) du détenteur,  
— langue habituelle.  
4.5.5.2.5 Données relatives aux activités de contrôle  
367) La carte de contrôleur doit permettre le stockage des 
données suivantes relatives aux activités de contrôle:  
— date et heure du contrôle,  
— type du contrôle (affichage et/ou impression et/ou télé ­
chargement à partir de la VU et/ou à partir de la carte 
et/ou contrôle de l'étalonnage sur route),  
— période téléchargée (le cas échéant),  
— numéro et autorité nationale d'immatriculation du véhi ­
cule contrôlé,  
— numéro de la carte de conducteur contrôlée et État 
membre qui l'a délivrée.  
368) La carte de contrôleur doit permettre le stockage d'au 
moins 230 enregistrements de ce type.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 75  
4.5.6  Carte d'entreprise  
4.5.6.1 A p p l i c a t i o n t a c h y g r a p h i q u e ( a c c e s s i b l e a u x 
u n i t é s e m b a r q u é e s d e p r e m i è r e e t d e u x i è m e 
g é n é r a t i o n s )  
4.5.6.1.1 Identification des applications  
369) La carte d'entreprise doit permettre le stockage des 
données suivantes pour l'identification des applications:  
— identification de l'application tachygraphique,  
— identification du type de carte tachygraphique.  
4.5.6.1.2 Clés et certificats  
370) La carte d'entreprise doit être en mesure de stocker un 
certain nombre de certificats et de clés cryptographiques, 
comme spécifié dans l'appendice 11, partie A.  
4.5.6.1.3 Identification de carte  
371) La carte d'entreprise doit permettre le stockage 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étente 
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'entreprise doit permettre le stockage des 
données suivantes pour l'identification du détenteur de la 
carte:  
— nom de l'entreprise,  
— adresse de l'entreprise.  
4.5.6.1.5 Données concernant l'activité de l'entreprise  
373) La carte d'entreprise doit permettre le stockage des 
données suivantes concernant les activités de l'entreprise:  
— date et heure de l'activité,  
— type de l'activité (verrouillage et/ou déverrouillage de 
la VU, téléchargement à partir de la VU et/ou de la 
carte),  
— période téléchargée (le cas échéant),  
— numéro et autorité nationale d'immatriculation du véhi ­
cule,  
— numéro de la carte et État membre qui l'a délivrée (en 
cas de téléchargement à partir de la carte).  
374) La carte d'entreprise doit permettre le stockage d'au moins 
230 enregistrements de ce type.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 76  
4.5.6.2 A p p l i c a t i o n t a c h y g r a p h i q u e d e d e u x i è m e g é n é ­
r a t i o n ( n o n a c c e s s i b l e a u x V U d e p r e m i è r e g é n é ­
r a t i o n )  
4.5.6.2.1 Identification des applications  
375) La carte d'entreprise doit permettre le stockage des 
données suivantes pour l'identification des applications:  
— identification de l'application tachygraphique,  
— identification du type de carte tachygraphique.  
4.5.6.2.2 Clés et certificats  
376) La carte d'entreprise doit être en mesure de stocker un 
certain nombre de certificats et de clés cryptographiques, 
comme spécifié dans l'appendice 11, partie B.  
4.5.6.2.3 Identification de carte  
377) La carte d'entreprise doit permettre le stockage 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étente 
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'entreprise doit permettre le stockage des 
données suivantes pour l'identification du détenteur de la 
carte:  
— nom de l'entreprise,  
— adresse de l'entreprise.  
4.5.6.2.5 Données concernant l'activité de l'entreprise  
379) La carte d'entreprise doit permettre le stockage des 
données suivantes concernant les activités de l'entreprise:  
— date et heure de l'activité,  
— type de l'activité (verrouillage et/ou déverrouillage de 
la VU, téléchargement à partir de la VU et/ou de la 
carte),  
— période téléchargée (le cas échéant),  
— numéro et autorité nationale d'immatriculation du véhi ­
cule,  
— numéro de la carte et État membre qui l'a délivrée (en 
cas de téléchargement à partir de la carte).  
380) La carte d'entreprise doit permettre le stockage d'au moins 
230 enregistrements de ce type.  
5. INSTALLATION DE L'APPAREIL DE CONTRÔLE  
5.1 Installation  
381) L'appareil de contrôle neuf est livré non activé aux instal ­
lateurs ou aux constructeurs de véhicules, avec tous les 
paramètres d'étalonnage figurant sur la liste du chapitre 
3, paragraphe 21, réglés aux valeurs par défaut appropriées 
et à jour. Lorsqu'aucune valeur particulière ne convient, on 
aura recours à des séries de points d'interrogation pour les 
paramètres alphabétiques et au «0» pour les paramètres 
numériques. La fourniture de pièces de l'appareil de 
contrôle en rapport avec la sécurité peut être restreinte 
au besoin au cours de la certification de sécurité.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 77  
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 stocker les données visées au chapitre 3, 
points 12.3, 12.9 et 12.12 à 12.15 inclus.  
384) Au cours de l'installation, les constructeurs du véhicule 
doivent prérégler tous les paramètres connus.  
385) Les constructeurs de véhicules ou les installateurs doivent 
activer l'appareil de contrôle installé au plus tard avant que 
le véhicule soit utilisé conformément au règlement (CE) 
n o 561/2006.  
386) L'activation de l'appareil de contrôle doit être déclenchée 
automatiquement par la première insertion d'une carte 
d'atelier en cours de validité dans une quelconque des 
interfaces destinées aux cartes.  
387) Les opérations particulières de couplage nécessaires entre 
le capteur de mouvement et l'unité embarquée sur le véhi ­
cule, le cas échéant, interviennent automatiquement avant 
ou pendant l'activation.  
388) De même, les opérations particulières de couplage néces ­
saires entre le dispositif GNSS externe et l'unité embar ­
quée sur le véhicule, le cas échéant, interviennent automa ­
tiquement avant ou pendant l'activation.  
389) Après l'activation, l'appareil de contrôle applique pleine ­
ment 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écurisées nécessaires aux fins de contrôles routiers ciblés.  
391) Les fonctions d'enregistrement et de stockage 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 comporte pas nécessairement la saisie du 
numéro d'immatriculation du véhicule (VRN) s'il n'est 
pas connu de l'atelier agréé qui doit procéder à cet étalon ­
nage. Dans ces circonstances, il doit être possible pour le 
propriétaire du véhicule, uniquement à ce moment, de 
saisir le VRN à l'aide de sa carte d'entreprise avant l'uti ­
lisation du véhicule conformément au règlement (CE) 
n o 561/2006 (par exemple à l'aide de commandes via 
une structure de menu appropriée de l'interface homme- 
machine de l'unité embarquée) (  1 ). Seule l'utilisation 
d'une carte d'atelier doit permettre la mise à jour ou la 
confirmation de cette saisie.  
393) L'installation d'un dispositif GNSS externe nécessite son 
couplage avec la VU et la vérification ultérieure des infor ­
mations de position GNSS.  
394) L'appareil de contrôle doit être positionné dans le véhicule 
de telle manière que le conducteur ait accès aux fonctions 
nécessaires depuis son siège.  ▼B 
( 1 ) JO L 102 du 11.4.2006, p. 1.
 02016R0799 — FR — 26.02.2020 — 002.001 — 78  
5.2 Plaquette d'installation  
395) Après la vérification de l'appareil de contrôle une fois 
installé, une plaquette d'installation, gravée ou imprimée 
de façon permanente, 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'installa ­
tion doit être apposée sur l'encadrement de la portière du 
côté conducteur, et être bien visible dans tous les cas.  
Après chaque inspection par un atelier ou un installateur 
agréé, une nouvelle plaquette est fixée à la place de la 
précédente.  
▼M1 
396) La plaquette doit comporter au moins les indications 
suivantes:  
— le nom, l’adresse ou la raison sociale de l’installateur 
ou de l’atelier agréé,  
— le coefficient caractéristique du véhicule, sous la forme 
«w = … imp/km»,  
— la constante 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 coefficient caractéristique du véhi ­
cule et la circonférence effective des pneumatiques ont 
été mesurés,  
— le numéro d’identification du véhicule,  
— la présence (ou non) d’un dispositif GNSS externe,  
— le numéro de série du dispositif GNSS externe, le cas 
échéant,  
— le numéro de série de l’appareil de communication à 
distance, le cas échéant,  
— le numéro de série de tous les scellements en place,  
— la partie du véhicule où l’adaptateur, le cas échéant, est 
installé,  
— la partie du véhicule où le capteur de mouvement est 
installé, s’il n’est pas connecté à la boîte de vitesses ou 
si un adaptateur n’est pas utilisé,  
— une description de la couleur du câble entre l’adapta ­
teur et la partie du véhicule qui fournit ses impulsions 
entrantes,  
— le numéro de série du capteur de mouvement intégré 
de l’adaptateur.  
▼B 
397) Pour les véhicules des catégories M1 et N1 uniquement, 
équipés d'un adaptateur conformément au règlement (CE) 
n o 68/2009 de la Commission (  1 ), tel que modifié en 
dernier lieu, et pour lesquels il n'est pas possible d'inclure 
toutes les informations nécessaires en vertu de l'exigence 
396, une plaque supplémentaire peut être utilisée. Dans ce 
cas, celle-ci comporte au moins les informations figurant 
aux quatre derniers tirets de l'exigence 396.  ▼B 
( 1 ) Règlement (CE) n  o 68/2009 de la Commission du 23 janvier 2009 portant neuvième 
adaptation au progrès technique du règlement (CEE) n  o 3821/85 du Conseil concernant 
l'appareil de contrôle dans le domaine des transports par route (JO L 21 du 24.1.2009, 
p. 3).
 02016R0799 — FR — 26.02.2020 — 002.001 — 79  
Si cette plaquette supplémentaire est utilisée, elle doit être 
apposée à côté ou en dessous de la plaquette principale 
décrite à l'exigence 396, et doit bénéficier du même niveau 
de protection. En outre, la plaquette supplémentaire doit 
aussi comporter le nom, l'adresse ou la raison sociale de 
l'installateur ou de l'atelier agréé qui a procédé à l'instal ­
lation, ainsi que la date d'installation.  
5.3 Scellement  
398) Les éléments suivants doivent être scellés:  
— toute connexion qui, si elle était interrompue, entraîne ­
rait des modifications indécelables ou des pertes de 
données indécelables (cela peut par exemple s'appli ­
quer au montage du capteur de mouvement sur la 
boîte de vitesses, à l'adaptateur pour les véhicules 
des catégories M1/N1, à la connexion GNSS externe 
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étruire les 
indications qu'elle porte.  
▼M1 
398 bis) Les scellements susmentionnés sont certifiés sur la base de 
la norme EN 16882:2016.  
▼B 
399) Les scellements précités peuvent être retirés:  
— en cas d'urgence,  
— afin d'installer, d'ajuster ou de réparer un limiteur de 
vitesse ou tout autre dispositif contribuant à la sécurité 
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 installateur ou un atelier agréé 
(conformément au chapitre 6) immédiatement après 
l'installation du limiteur de vitesse ou de tout autre 
dispositif contribuant à la sécurité 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 trans ­
mise à l'autorité compétente.  
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.  
▼M1 
Ce numéro d’identification unique est défini comme suit: 
MMNNNNNNNN, faisant l’objet d’un marquage indélé ­
bile, où MM est l’identifiant unique du fabricant (enregis ­
trement dans une base de données qui sera gérée par la 
CE) et NNNNNNNN est le numéro alphanumérique du 
scellement, unique dans le domaine du fabricant.  
▼B 
402) Les scellements doivent présenter un espace libre où les 
installateurs, ateliers ou constructeurs de véhicules agréés 
peuvent ajouter une marque particulière conformément à 
l'article 22, paragraphe 3 du règlement (UE) n  o 165/2014.  
Cette marque ne doit pas couvrir le numéro d'identification 
du scellement.  
▼M1 
403) Les fabricants de scellements doivent être enregistrés dans 
une base de données dédiée lorsqu’ils obtiennent la certi ­
fication d’un modèle de scellement selon la norme EN 
16882:2016 et rendre publics leurs numéros d’identifica ­
tion de scellements par une procédure établie par la 
Commission européenne.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 80  
404) Les ateliers et constructeurs de véhicules agréés doivent, 
dans le cadre du règlement (UE) n  o 165/2014, n’utiliser 
que des scellements certifiés selon la norme EN 
16882:2016 issus des fabricants de scellements répertoriés 
dans la base de données mentionnée ci-dessus.  
▼B 
405) Les fabricants de scellements et leurs distributeurs doivent 
conserver des dossiers de traçabilité complète des scelle ­
ments vendus pour une utilisation dans le cadre du règle ­
ment (UE) n  o 165/2014 et doivent être prêts à les commu ­
niquer aux autorités nationales compétentes à chaque fois 
que c'est nécessaire.  
406) Les numéros d'identification uniques des scellements 
doivent être visibles sur la plaquette d'installation.  
6. CONTRÔLES, INSPECTIONS ET RÉPARATIONS  
Les prescriptions concernant les circonstances dans lesquelles les 
scellements peuvent être retirés, comme indiqué à l'article 22, para ­
graphe 5, du règlement (UE) n  o 165/2014, sont définies au chapitre 
5, point 3, de la présente annexe.  
6.1 Agrément des installateurs, des ateliers et des constructeurs 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,  
— inspections,  
— réparations.  
Les cartes d'atelier ne doivent être délivrées qu'aux installateurs 
et/ou aux ateliers agréés pour l'activation et/ou l'étalonnage d'appa ­
reils de contrôle, conformément à la présente annexe et, sauf cas 
dûment motivé:  
— qui ne sont pas éligibles pour une carte d'entreprise;  
— dont les autres activités professionnelles ne sont pas de nature à 
compromettre la sécurité globale du système telle que requis 
dans l'appendice 10.  
▼M1 
6.2 Vérification de composants 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.  
▼B 
6.3 Inspection de l'installation  
▼M1 
408) Lors de son montage sur un véhicule, l’ensemble de l’ins ­
tallation (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. L’ensemble de 
l’installation doit être scellé conformément au chapitre 
5.3 et comprendre un étalonnage.  
▼B 
6.4 Inspections périodiques  
409) Des inspections périodiques des appareils montés sur les 
véhicules ont lieu après toute réparation, ou après toute 
modification du coefficient caractéristique 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'immatriculation a changé, et au moins une 
fois tous les deux ans (24 mois).  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 81  
410) Ces inspections comprennent les vérifications suivantes:  
— fonctionnement correct de l'appareil de contrôle, y 
compris la fonction de stockage de données sur les 
cartes tachygraphiques et la communication à l'aide 
de lecteurs de communication à distance,  
— conformité aux dispositions du chapitre 3, points 2.1 et 
2.2 concernant les tolérances maximales à l'installation,  
— conformité 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'exi ­
gence 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'ap ­
pareil,  
— placement correct et bon état des scellements, validité 
de leurs numéros d'identification (le fabricant de scel ­
lements est référencé dans la base de données de la 
CE) et correspondance entre leurs numéros d'identifi ­
cation et les marquages des plaquettes d'installation 
(voir exigence 401).  
411) S'il est constaté qu'un des événements figurant au chapitre 
3, point 9 (Détection des événements et/ou des anomalies) 
est survenu depuis la dernière inspection, et que les fabri ­
cants de tachygraphes et/ou les autorités nationales consi ­
dèrent que cet événement fait peser un risque potentiel sur 
la sécurité de l'équipement, l'atelier:  
a. effectue une comparaison entre les données d'identifi ­
cation du capteur de mouvement connecté à la boîte de 
vitesse avec celles du capteur de mouvement couplé 
enregistrées dans l'unité embarquée;  
b. vérifie si les informations inscrites 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'homologa ­
tion du capteur de mouvement, s'ils sont imprimés sur 
le corps du capteur de mouvement, correspondent aux 
informations enregistrées dans la mémoire de l'appareil 
de contrôle;  
d. compare les données d'identification inscrites sur la 
plaque signalétique du dispositif GNSS externe, le cas 
échéant, à celles stockées dans la mémoire de la VU.  
412) Les ateliers consignent, dans leurs rapports d'inspection, 
toute constatation concernant un bris de scellement ou 
un dispositif de manipulation. Ils conservent ces rapports 
pendant au moins 2 ans et les mettent à la disposition de 
l'autorité compétente sur toute demande.  
413) Ces inspections comprennent un étalonnage et un rempla ­
cement préventif des scellements dont l'installation s'ef ­
fectue sous la responsabilité d'ateliers.  
6.5 Détermination 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:  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 82  
— véhicule à vide en ordre de marche,  
— pression des pneumatiques conforme aux instructions 
du fabricant,  
— usure des pneumatiques dans les limites autorisées en 
droit national,  
— mouvement du véhicule:  
— le véhicule doit avancer, sous l'action de son propre 
moteur, en ligne droite sur sol plat à une vitesse 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 comparable, 
d'autres méthodes, comme par exemple l'utilisation 
d'un banc approprié, peuvent également être mises en 
œuvre pour l'essai.  
6.6 Réparations  
415) Les ateliers doivent pouvoir télécharger des données à 
partir de l'appareil de contrôle afin de les restituer à l'en ­
treprise de transport appropriée.  
416) Les ateliers agréés délivrent aux entreprises de transport un 
certificat attestant que les données ne peuvent être télé ­
chargées lorsqu'un dysfonctionnement de l'appareil de 
contrôle empêche de télécharger les données stockées, 
même après réparation à l'atelier même. Les ateliers 
conservent 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 conformes aux prescriptions suivantes:  
417) Le numéro de carte pour la première délivrance d'une carte 
tachygraphique doit comporter un indice séquentiel (au 
besoin), un indice de remplacement et un indice de renou ­
vellement fixé à «0».  
418) Les numéros de carte de toutes les cartes tachygraphiques 
non nominatives délivrées au même organisme de contrôle 
ou au même atelier ou à la même entreprise de transport 
doivent comporter 13 chiffres identiques suivis d'un indice 
séquentiel.  
419) Une carte tachygraphique délivrée en remplacement d'une 
carte tachygraphique existante doit avoir le même numéro 
que celle qu'elle remplace, sauf l'indice de remplacement, 
qui doit être augmenté d'une unité (dans une série 0 à 9, A 
à Z).  
420) Une carte tachygraphique délivrée en remplacement d'une 
carte tachygraphique existante doit avoir la même date 
d'expiration que cette dernière.  
421) Une carte tachygraphique 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 remplacement, 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'échange d'une carte tachygraphique existante, aux fins de 
la modification de données administratives, doit suivre les 
règles applicables au renouvellement s'il est effectué à 
l'intérieur d'un même État membre, ou les règles applica ­
bles à une première délivrance s'il est effectué dans un 
autre État membre.  
423) Dans le cas d'une carte d'atelier ou de contrôleur non 
nominative, la rubrique «nom du détenteur de la carte» 
doit être complétée par le nom de l'atelier, de l'organisme 
de contrôle, de l'installateur ou de l'agent de contrôle selon 
ce que décident les États membres.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 83  
424) Les États membres échangent des données par voie élec ­
tronique afin d'assurer l'unicité des cartes de conducteur 
qu'ils délivrent conformément à l'article 31 du règlement 
(UE) n  o 165/2014.  
8. HOMOLOGATION DE L'APPAREIL DE CONTRÔLE ET DES 
CARTES TACHYGRAPHIQUES  
8.1 Points généraux  
▼M1 
Aux fins du présent chapitre, on entend par «appareil de contrôle», 
l’«appareil de contrôle ou ses composants». Aucune homologation 
n’est exigée pour le(s) câble(s) reliant le capteur de mouvement à la 
VU, le dispositif GNSS externe à la VU ou le dispositif externe de 
communication à distance à la VU. Le papier utilisé pour l'appareil 
de contrôle est considéré comme un composant de l'appareil.  
Tout fabricant peut demander l’homologation de son ou ses compo ­
sants d’appareil de contrôle avec tout autre composant d’appareil de 
contrôle, pour autant que chaque composant soit conforme aux 
exigences contenues dans la présente annexe. Les fabricants 
peuvent également demander l’homologation de l’appareil de 
contrôle.  
Comme décrit dans la définition 10 de l’article 2 du présent règle ­
ment, les unités embarquées ont des variantes en ce qui concerne 
l’assemblage des composants. Quel que soit l’assemblage des 
composants de l’unité embarquée sur véhicule, l’antenne externe 
et (le cas échéant) du coupleur d’antenne connecté au récepteur 
GNSS ou au dispositif de communication à distance ne sont pas 
couverts par l’homologation de l’unité embarquée sur véhicule.  
Les fabricants ayant obtenu l’homologation de leur appareil de 
contrôle doivent néanmoins tenir une liste publique des antennes 
et coupleurs compatibles avec chaque unité embarquée sur véhicule, 
dispositif GNSS externe et équipement externe de communication à 
distance homologués.  
▼B 
425) L'appareil de contrôle doit être présenté pour homologation 
avec tous ses composants ainsi que tout dispositif addi ­
tionnel éventuellement intégré.  
426) L'homologation d'un appareil de contrôle et de cartes 
tachygraphiques comporte des essais liés à la sécurité, 
des essais fonctionnels et des essais d'interopérabilité. 
Les résultats positifs à chacun de ces essais sont attestés 
par un certificat approprié.  
▼M1 
427) Les autorités d'homologation des États membres n'accor ­
deront pas de certificat d'homologation tant qu'elles ne 
sont pas en possession:  
— d’un certificat de sécurité (s'il est requis au titre de la 
présente annexe),  
— d’un certificat de fonctionnement,  
— et d’un certificat d’interopérabilité (s'il est requis au 
titre de la présente annexe)  
pour l’appareil de contrôle ou la carte tachygraphique 
faisant l’objet de la demande d’homologation.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 84  
428) Toute modification du logiciel ou du matériel, ou des 
matériaux utilisés dans la fabrication doit être notifiée au 
préalable à l'autorité qui a accordé l'homologation de l'ap ­
pareil. Cette autorité doit confirmer au fabricant l'extension 
de l'homologation, ou bien elle peut demander une mise à 
jour ou une confirmation des certificats de fonctionnement, 
de sécurité et/ou d'interopé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'autorité 
qui a accordé l'homologation pour l'appareil de contrôle 
concerné. La mise à niveau logicielle ne doit ni modifier 
ni supprimer aucune donnée relative à l'activité du conduc ­
teur stocké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.  
430) L'homologation des modifications de logiciels visant à 
mettre à niveau un appareil de contrôle préalablement 
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 Certificat de sécurité  
431) Le certificat de sécurité est délivré conformément aux 
dispositions de l'appendice 10 de la présente annexe. Les 
composants de l'appareil de contrôle qui doivent être certi ­
fiés sont: la VU, le capteur de mouvement, le dispositif 
GNSS externe et les cartes tachygraphiques.  
432) Dans la circonstance exceptionnelle et spécifique où les 
autorités de certification de sécurité refusent de certifier 
un nouvel appareil en invoquant l'obsolescence des méca ­
nismes de sécurité, l'homologation continue à être 
accordée uniquement lorsqu'il n'existe aucune autre solu ­
tion conforme au règlement.  
433) Dans cette circonstance, l'État membre concerné informe 
sans retard la Commission européenne qui, dans les douze 
mois civils qui suivent l'octroi de l'homologation, lance 
une procédure pour s'assurer que le niveau de sécurité a 
été ramené à son niveau d'origine.  
8.3 Certificat de fonctionnement  
434) Chaque candidat à l'homologation doit fournir à l'autorité 
d'homologation de l'État membre tout le matériel et la 
documentation que cette autorité juge nécessaires.  
435) Les fabricants fournissent les échantillons pertinents de 
produits en attente d'une homologation et la documentation 
associée requis par les laboratoires désignés pour effectuer 
les essais fonctionnels, et ce, dans le mois qui suit la 
demande. L'entité qui fait la demande supporte les coûts 
qui en résultent. Les laboratoires traitent toutes les infor ­
mations sensibles sur le plan commercial en respectant la 
confidentialité.  
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'appen ­
dice 9.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 85  
437) L'autorité d'homologation délivre le certificat de fonction ­
nement. Ce certificat comporte, 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 obtenus.  
438) Le certificat de fonctionnement de tout composant d'appa ­
reil de contrôle mentionne aussi les numéros d'homologa ­
tion des autres composants d'appareil de contrôle compati ­
bles homologués qui sont testés en vue d'obtenir cette 
certification.  
439) Le certificat de fonctionnement d'un composant de l'appa ­
reil de contrôle doit également indiquer la norme ISO ou 
CEN en vertu de laquelle l'interface fonctionnelle a été 
certifiée.  
8.4 Certificat d'interopérabilité  
440) Les essais d'interopérabilité sont réalisés par un seul et 
même laboratoire sous l'autorité et la responsabilité de la 
Commission européenne.  
441) Le laboratoire enregistre les demandes d'essais d'interopé ­
rabilité introduites par les fabricants dans l'ordre chrono ­
logique de leur arrivée.  
442) Les demandes ne sont officiellement enregistrées que 
lorsque le laboratoire est en possession:  
— de l'ensemble du matériel et des documents nécessaires 
pour les essais d'interopérabilité,  
— du certificat de sécurité correspondant,  
— du certificat de fonctionnement correspondant.  
La date de l'enregistrement de la demande est notifiée au 
fabricant.  
443) Aucun essai d'interopérabilité n'est réalisé par le labora ­
toire sur un appareil de contrôle ou une carte tachygra ­
phique qui n'a pas reçu de certificat de sécurité et de 
certificat de fonctionnement, sauf dans les circonstances 
exceptionnelles décrites sous l'exigence 432.  
444) Tout fabricant demandant des essais d'interopérabilité s'en ­
gage à laisser au laboratoire chargé des essais l'ensemble 
du matériel et de la documentation fournis aux fins des 
essais.  
445) Les essais d'interopérabilité sont effectués, conformément 
à l'appendice 9 de la présente annexe, sur tous les types 
d'appareil de contrôle ou de cartes tachygraphiques:  
— dont l'homologation est en cours de validité, ou  
— dont l'homologation est en instance et pour lesquels 
existe un certificat d'interopérabilité en cours de vali ­
dité. 
446) Les tests d'interopérabilité doivent couvrir toutes les géné ­
rations d'appareils de contrôle ou de cartes tachygra ­
phiques encore en usage.  
447) Le certificat d'interopérabilité doit être délivré au fabricant 
par le laboratoire uniquement après que des résultats posi ­
tifs ont été obtenus 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 tachygra ­
phiques, le certificat d'interopérabilité n'est pas délivré tant 
que le fabricant concerné n'a pas apporté les modifications 
nécessaires et que l'appareil ou la carte n'a pas satisfait à  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 86  
tous les essais d'interopérabilité. Le laboratoire détermine 
l'origine du problème avec l'aide du fabricant concerné, et 
s'efforce d'assister ce fabricant 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 autorités compétentes de la validité du certificat de 
sécurité 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'homologation correspondant. Il est 
transmis par le fabricant à l'autorité 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'interopérabilité ne doit pas être utilisé pour réaliser des 
bénéfices ni pour accéder à une position dominante.  
8.5 Certificat d'homologation  
451) L'autorité d'homologation de l'État membre peut délivrer le 
certificat d'homologation dès qu'elle est en possession des 
trois certificats requis.  
452) Le certificat d'homologation de tout composant d'appareil 
de contrôle mentionne aussi les numéros d'homologation 
des autres composants d'appareil de contrôle interopérables 
homologués.  
453) Une copie du certificat d'homologation doit être transmise 
par l'autorité d'homologation au laboratoire chargé des 
essais d'interopérabilité lors de la délivrance de ce certi ­
ficat au fabricant.  
454) Le laboratoire compétent 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 tachy ­
graphiques:  
— 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érabi ­
lité pour des unités de contrôle et des cartes tachygraphiques 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/cartes 
tachygraphiques de deuxième génération (cartes de 
conducteur, d'atelier, de contrôleur et d'entreprise) 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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 87  
456) À l'issue de cette période, si tous les produits concernés 
sont interopérables, tous les certificats d'interopérabilité 
deviennent définitifs.  
457) Si des anomalies d'interopérabilité apparaissent au cours de 
cette période, le laboratoire chargé des essais d'interopéra ­
bilité détermine la cause des problèmes observés, avec 
l'aide de tous les fabricants concernés, et les invite à 
apporter les modifications nécessaires.  
458) Si, à la fin de cette période, des problèmes d'interopérabi ­
lité demeurent, le laboratoire chargé des essais d'interopé ­
rabilité détermine, en collaboration avec les fabricants 
concernés et avec les autorités d'homologation qui ont 
délivré les certificats de fonctionnement correspondants, 
les causes des anomalies d'interopérabilité, et définissent 
les modifications que chaque fabricant concerné doit 
apporter. La recherche 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'in ­
teropé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'interopérabilité provi ­
soire et la date de la décision de la Commission visée à 
l'exigence 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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 88  
Appendice 1  
DICTIONNAIRE DE DONNÉES  
TABLE DES MATIÈRES  
1. INTRODUCTION  
1.1. Méthode d'établissement des définitions de type de données  
1.2. Références  
2. DÉFINITIONS DES TYPES DE DONNÉES  
2.1. ActivityChangeInfo  
2.2. Address  
2.3. AESKey  
2.4. AES128Key  
2.5. AES192Key  
2.6. AES256Key  
2.7. BCDString  
2.8. CalibrationPurpose  
2.9. CardActivityDailyRecord  
2.10. CardActivityLengthRange  
2.11. CardApprovalNumber  
2.12. CardCertificate  
2.13. CardChipIdentification  
2.14. CardConsecutiveIndex  
2.15. CardControlActivityDataRecord  
2.16. CardCurrentUse  
2.17. CardDriverActivity  
2.18. CardDrivingLicenceInformation  
2.19. CardEventData  
2.20. CardEventRecord  
2.21. CardFaultData  
2.22. CardFaultRecord  
2.23. CardIccIdentification  
2.24. CardIdentification  
2.25. CardMACertificate  
2.26. CardNumber  
2.27. CardPlaceDailyWorkPeriod  
2.28. CardPublicKey  
2.29. CardPublicKey  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 89  
2.30. CardRenewalIndex  
2.31. CardReplacementIndex  
2.32. CardSignCertificate  
2.33. CardSlotNumber  
2.34. CardSlotsStatus  
2.35. CardSlotsStatusRecordArray  
2.36. CardStructureVersion  
2.37. CardVehicleRecord  
2.38. CardVehiclesUsed  
2.39. CardVehicleUnitRecord  
2.40. CardVehicleUnitsUsed  
2.41. Certificat  
2.42. CertificateContent  
2.43. CertificateRequestID Identification individuelle d'une demande de certi ­ 
ficat.  
2.44. CertificateRequestID  
2.45. CertificationAuthorityKID  
2.46. CompanyActivityData  
2.47. CompanyActivityType  
2.48. CompanyCardApplicationIdentification  
2.49. CompanyCardHolderIdentification  
2.50. ControlCardApplicationIdentification  
2.51. ControlCardControlActivityData  
2.52. ControlCardHolderIdentification  
2.53. ControlType  
2.54. DailyPresenceCounter  
2.55. CurrentDateTimeRecordArray  
2.56. DailyPresenceCounter  
2.57. Datef  
2.58. DateOfDayDownloaded  
2.59. DateOfDayDownloadedRecordArray  
2.60. Distance  
2.61. DriverCardApplicationIdentification  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 90  
2.62. DriverCardHolderIdentification  
▼M1 
2.63. Réservé pour une utilisation future  
▼B 
2.64. EGFCertificate  
2.65. EmbedderIcAssemblerId  
2.66. EntryTypeDailyWorkPeriod  
2.67. EquipmentType  
2.68. EventFaultType  
2.69. EventFaultRecordPurpose  
2.70. EventFaultType  
2.71. ExtendedSealIdentifier  
2.72. ExtendedSerialNumber  
2.73. FullCardNumber  
2.74. FullCardNumberAndGeneration  
2.75. Generation  
2.76. GeoCoordinates  
2.77. GNSSAccuracy  
▼M1 
2.78. GNSSAccumulatedDriving  
2.79. GNSSAccumulatedDrivingRecord  
▼B 
2.80. GNSSPlaceRecord  
2.81. HighResOdometer  
2.82. HighResTripDistance  
2.83. HolderName  
2.84. InternalGNSSReceiver  
2.85. K-ConstantOfRecordingEquipment  
2.86. KeyIdentifier  
2.87. KMWCKey  
2.88. Language  
2.89. LastCardDownload  
2.90. LinkCertificate  
2.91. L-TyreCircumference  
2.92. MAC  
2.93. ManualInputFlag  
2.94. ManufacturerCode  
2.95. ManufacturerSpecificEventFaultData  
2.96. MemberStatePublicKey  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 91  
2.97. MemberStateCertificateRecordArray  
2.98. MemberStatePublicKey  
2.99. Name  
2.100. NationAlpha  
2.101. Code numérique national  
2.102. NoOfCalibrationsSinceDownload  
2.103. NoOfCalibrationsSinceDownload  
2.104. NoOfCardPlaceRecords  
2.105. NoOfCardVehicleRecords  
2.106. NoOfCardVehicleUnitRecords  
2.107. NoOfControlActivityRecords  
2.108. NoOfEventsPerType  
2.109. NoOfEventsPerType  
2.110. NoOfFaultsPerType  
▼M1 
2.111. NoOfGNSSADRecords  
▼B 
2.112. NoOfSpecificConditionRecords  
2.113. OdometerShort  
2.114. OdometerValueMidnight  
2.115. OdometerValueMidnightRecordArray  
2.116. OverspeedNumber  
2.117. PlaceRecord  
2.118. PreviousVehicleInfo  
2.119. PublicKey  
2.120. RecordType  
2.121. RegionAlpha  
▼C4 
2.122. RegionNumeric  
▼B 
2.123. RemoteCommunicationModuleSerialNumber  
2.124. RSAKeyModulus  
2.125. RSAKeyPublicExponent  
2.126. RSAKeyPublicExponent  
2.127. RtmData  
2.128. SealDataCard  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 92  
2.129. SealDataVu  
2.130. SealRecord  
2.131. SensorApprovalNumber  
2.132. SensorExternalGNSSApprovalNumber  
2.133. SensorExternalGNSSCoupledRecord  
2.134. SensorExternalGNSSIdentification  
2.135. SensorExternalGNSSInstallation  
2.136. SensorExternalGNSSOSIdentifier  
2.137. SensorExternalGNSSSCIdentifier  
2.138. SensorGNSSCouplingDate  
2.139. SensorGNSSSerialNumber  
2.140. SensorIdentification  
2.141. SensorInstallation  
2.142. SensorInstallationSecData  
2.143. SensorOSIdentifier  
2.144. SensorPaired  
2.145. SensorPairedRecord  
2.146. SensorPairingDate  
2.147. SensorSCIdentifier  
2.148. SensorSerialNumber  
2.149. Signature  
2.150. SignatureRecordArray  
2.151. SimilarEventsNumber  
2.152. SpecificConditionRecord  
2.153. SpecificConditions  
2.154. SpecificConditionType  
2.155. Speed  
2.156. SpeedAuthorised  
2.157. SpeedAverage  
2.158. SpeedMax  
2.159. TachographPayload  
▼M1 
2.160. Réservé pour une utilisation future  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 93  
2.161. TDesSessionKey  
2.162. TimeReal  
2.163. TyreSize  
2.164. VehicleIdentificationNumber  
2.165. VehicleIdentificationNumberRecordArray  
2.166. VehicleRegistrationIdentification  
2.167. Numéro d'immatriculation du véhicule  
2.168. VehicleRegistrationNumberRecordArray  
2.169. VuAbility  
2.170. VuActivityDailyData  
2.171. VuActivityDailyRecordArray  
2.172. VuApprovalNumber  
2.173. VuCalibrationData  
2.174. VuCalibrationRecord  
2.175. VuCalibrationRecordArray  
2.176. VuCardIWData  
2.177. VuCardIWRecord  
2.178. VuCardIWRecordArray  
2.179. VuCardRecord  
2.180. VuCardRecordArray  
2.181. VuCertificate  
2.182. VuCertificateRecordArray  
2.183. VuCompanyLocksData  
2.184. VuCompanyLocksRecord  
2.185. VuCompanyLocksRecordArray  
2.186. VuControlActivityData  
2.187. VuControlActivityRecord  
2.188. VuControlActivityRecordArray  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 94  
2.189. VuDataBlockCounter  
2.190. VuDetailedSpeedBlock  
2.191. VuDetailedSpeedBlockRecordArray  
2.192. VuDetailedSpeedData  
2.193. VuDownloadablePeriod  
2.194. VuDownloadablePeriodRecordArray  
2.195. VuDownloadActivityData  
2.196. VuDownloadActivityDataRecordArray  
2.197. VuEventData  
2.198. VuEventRecord  
2.199. VuEventRecordArray  
2.200. VuFaultData  
2.201. VuFaultRecord  
2.202. VuFaultRecordArray  
▼M1 
2.203. VuGNSSADRecord  
2.204. VuGNSSADRecordArray  
▼B 
2.205. VuIdentification  
2.206. VuIdentificationRecordArray  
2.207. VuITSConsentRecord  
2.208. VuITSConsentRecordArray  
2.209. VuManufacturerAddress  
2.210. VuManufacturerName  
2.211. VuManufacturingDate  
2.212. VuOverSpeedingControlData  
2.213. VuOverSpeedingControlDataRecordArray  
2.214. VuOverSpeedingEventData  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 95  
2.215. VuOverSpeedingEventRecord  
2.216. VuOverSpeedingEventRecordArray  
2.217. VuPartNumber  
2.218. VuPlaceDailyWorkPeriodData  
2.219. VuPlaceDailyWorkPeriodRecord  
2.220. VuPlaceDailyWorkPeriodRecordArray  
2.221. VuPublicKey  
2.222. VuPublicKey  
2.223. VuSerialNumber  
2.224. VuSoftInstallationDate  
2.225. VuSoftwareIdentification  
2.226. VuSoftwareVersion  
2.227. VuSpecificConditionData  
2.228. VuSpecificConditionRecordArray  
2.229. VuTimeAdjustmentData  
▼M1 
2.230. Réservé pour une utilisation future  
2.231. Réservé pour une utilisation future  
▼B 
2.232. VuTimeAdjustmentRecord  
2.233. VuTimeAdjustmentRecordArray  
2.234. WorkshopCardApplicationIdentification  
2.235. WorkshopCardCalibrationData  
2.236. WorkshopCardCalibrationRecord  
2.237. WorkshopCardHolderIdentification  
2.238. WorkshopCardPIN  
2.239. W-VehicleCharacteristicConstant  
2.240. VuPowerSupplyInterruptionRecord  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 96  
2.241. VuPowerSupplyInterruptionRecordArray  
2.242. VuSensorExternalGNSSCoupledRecordArray  
2.243. VuSensorPairedRecordArray  
3. DÉFINITIONS DES PLAGES DE VALEURS ET DE DIMENSIONS  
4. JEUX DE CARACTÈRES  
5. ENCODAGE  
6. IDENTIFICATEURS D'OBJETS ET IDENTIFICATEURS D'APPLI ­ 
CATIONS  
6.1. Identificateurs d'objets  
6.2. Identificateur d'application  
1. INTRODUCTION  
Le présent appendice fournit une série de précisions concernant les 
formats, éléments et structures de données utilisés au sein des appareils 
de contrôle et cartes tachygraphiques.  
1.1. Méthode d'établissement 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 
autorise la définition de données simples et structurées sans nécessiter 
l'emploi d'une syntaxe de transfert spécifique (règles de codage) qui 
dépende de l'application et de l'environnement considérés.  
Les règles d'affectation des noms du type ASN.1 sont établies en confor ­
mité 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 compose d'autres types de données, le nom 
de ce type de données se présente encore et toujours sous la forme 
d'une seule séquence de caractères alphabétiques commençant par 
une majuscule, quoique ce nom comporte un nombre indéterminé 
de majuscules qui en rappellent la signification,  
— de manière générale, les noms de type de données sont en rapport 
avec le nom des types de données à partir desquels ils sont 
construits, avec l'équipement au sein duquel les données sont mémo ­
risées et avec la fonction associée aux données considérées.  
Si l'emploi 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'autoriser l'application de plusieurs types de règles de codage, 
certains types ASN.1 évoqués dans le présent appendice sont soumis à 
des identificateurs de plage de valeurs. Ces identificateurs 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'identification du 
véhicule (VIN) — Contenu et structure. 2009  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 97  
ISO/IEC 7816-5 Cartes d'identification — Cartes à circuit intégré — 
Partie 5: Enregistrement des fournisseurs d'applica ­
tion. 
Deuxième édition: 2004.  
ISO/IEC 7816-6 Cartes d'identification — Cartes à circuit intégré — 
Partie 6: Éléments de données intersectoriels pour les 
échanges, 2004 + Rectificatif technique 1: 2006  
ISO/IEC 8824-1 Technologies de l'information — Notation de syntaxe 
abstraite numéro un (ASN.1): Spécification de la 
notation de base. 2008 + Rectificatif technique 1: 
2012 et Rectificatif technique 2: 2014.  
ISO/IEC 8825-2 Technologies de l'information — Règles de codage 
ASN.1: Spécification des règles de codage compact 
(PER) 2008.  
ISO/IEC 8859-1 Technologies 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 Technologies de l'information — Jeux de caractères 
graphiques codés sur un seul octet — Partie 7: 
Alphabet latin/grec. 2003.  
ISO 16844-3 Véhicules routiers — Systèmes tachygraphes — 
Interface de capteur de mouvement. 2004 + Rectifi ­
catif technique 1: 2006.  
TR-03110-3 BSI/ANSSI Rapport technique TR-03110-3, Méca ­
nismes de sécurité avancés pour les documents de 
voyage lisibles à la machine et jeton eIDAS — 
Partie 3 Spécifications communes, version 2.20, 3. 
Février 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'attribution d'une valeur 
par défaut résultant du remplissage de l'élément de données concerné au 
moyen d'octets ‘FF’.  
Tous les types de données servent aux applications de génération 1 et 2 
sauf disposition contraire.  
▼M1 
Pour les types de données de carte utilisés pour les applications de 
génération 1 et 2, la taille indiquée dans le présent appendice est celle 
relative à l’application de génération 2. La taille relative à l’application 
de génération 1 est censée être déjà connue du lecteur. Les numéros des 
exigences de l’annexe IC relatives à ces types de données couvrent à la 
fois les applications de génération 1 et de génération 2.  
▼B 
2.1. ActivityChangeInfo  
Ce type de données autorise le codage, en mots de deux octets, d'un état 
du lecteur à 00h00 et/ou d'un état du conducteur à 00h00 et/ou de 
changements d'activité, d'état de conduite et/ou d'état de carte se rappor ­
tant à un conducteur ou un convoyeur. Ce type de données est lié aux 
exigences 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: CONVOYEUR  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 98  
‘c’B État de conduite:  
‘0’B: SEUL  
‘1’B: ÉQUIPAGE  
‘p’B État de la carte de conducteur (ou d'atelier) insérée 
dans le lecteur approprié:  
‘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: TRAVAIL  
‘11’B: CONDUITE  
‘ttttttttttt’B Heure du changement: nombre de minutes écoulées 
depuis 00h00 le jour considéré.  
Pour les enregistrements (et l'état du conducteur) sur carte de conducteur 
(ou d'atelier):  
‘s’B Lecteur (hors de propos si ‘p’ = 1 sauf remarque ci- 
après):  
‘0’B: CONDUCTEUR  
‘1’B: CONVOYEUR  
‘c’B État de conduite (cas ‘p’=0) ou  
État d'activité suivant (cas ‘p’=1):  
‘0’B: UNIQUE,  
‘0’B: INCONNU  
‘1’B: ÉQUIPAGE,  
‘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: TRAVAIL  
‘11’B: CONDUITE  
‘ttttttttttt’B Heure du changement: nombre de minutes écoulées 
depuis 00h00 le jour considéré.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 99  
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 correspondante.  
2.2. Address  
Une adresse.
  
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éci ­
fié. 
2.3. AESKey  
Génération 2:  
Une clé AES d'une longueur de 128, 192 ou 256 bits.
  
Attribution de valeur:  pas spécifiée davantage.  
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.  
Attribution de valeur:  
La longueur possède une valeur de 16.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 100  
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.  
Attribution de valeur:  
La longueur possède une valeur de 24.  
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.  
Attribution de valeur:  
La longueur possède une valeur de 32.  
2.7. BCDString  
BCDString s'applique à la représentation de données en décimal codé 
binaire (DCB). Ce type de données s'utilise pour représenter un chiffre 
décimal par un quartet (4 bits). BCDString repose sur l'application de la 
norme ISO/IEC 8824-1 ‘CharacterStringType’ (type de chaîne de carac ­
tères).
  
BCDString a recours à une notation «hstring». Le chiffre hexadécimal de 
gauche sera considéré comme le quartet le plus significatif du premier 
octet. Pour produire un multiple d'octets, il faut insérer le nombre appro ­
prié de quartets de droite nuls à partir de la position qu'occupe le quartet 
le plus significatif du premier octet.  
Chiffres admis: 0, 1, .. 9.  
2.8. CalibrationPurpose  
Code indiquant la raison de l'enregistrement d'un jeu de paramètres 
d'étalonnage. Ce type de données est lié aux exigences 097 et 098 de 
l'annexe 1B et des exigences 119 de l'annexe 1C.
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 101  
Attribution de valeur:  
Génération 1:  
‘00’H valeur réservé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éhi ­
cule considéré,  
‘04’H inspection périodique,  
Génération 2:  
Outre la génération 1, les valeurs suivantes sont utilisées:  
‘05’H entrée des VRN par entreprise,  
‘06’H mise à l'heure sans étalonnage,  
‘07’H à ‘7F’H RFU,  
‘80’H à ‘FF’H propre au fabricant.  
2.9. CardActivityDailyRecord  
Informations enregistrées sur une carte et se rapportant aux activités 
auxquelles le conducteur 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'annexe 
1C.
 
activityPreviousRecordLength  indique la longueur totale du précédent 
relevé quotidien exprimée en octets. La valeur maximale correspond à la 
longueur de la CHAÎNE D'OCTETS contenant ces relevés (cf. CardAc ­
tivityLengthRange, appendice 2, paragraphe 4) Lorsque ces données 
correspondent au relevé quotidien le plus ancien, la valeur de l'activity ­
PreviousRecordLength doit être mise à 0.  
activityRecordLength  indique la longueur totale de ce relevé exprimée 
en octets. La valeur maximale correspond à la longueur de la CHAÎNE 
D'OCTETS contenant ces relevés.  
activityRecordDate  indique la date du relevé.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 102  
activityDailyPresenceCounter  indique l'état du compteur de présence 
journalière pour la carte et le jour considérés.  
activityDayDistance  indique la distance totale parcourue le jour consi ­
déré.  
activityChangeInfo  indique le jeu de données ActivityChangeInfo se 
rapportant au conducteur et au jour considérés. Cette chaîne d'octets 
ne peut contenir plus de 1440 valeurs (un changement d'activité par 
minute). Ce jeu comprend toujours l'ActivityChangeInfo encodant l'état 
du conducteur à 00h00.  
2.10.  CardActivityLengthRange  
Nombre d'octets qu'une carte de conducteur ou d'atelier est susceptible 
d'affecter à l'enregistrement de relevés d'activité d'un conducteur.
  
Attribution de valeur: cf. appendice 2.  
2.11.  CardApprovalNumber  
Numéro d'homologation de la carte.
  
Attribution 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 exemple. Le numéro d'homologation 
doit être aligné à gauche.  
2.12.  CardCertificate  
Génération 1:  
Certificat associé à la clé publique d'une carte.
  
2.13.  CardChipIdentification  
Informations enregistrées sur une carte et se rapportant à l'identification 
du circuit intégré (CI) de cette carte (exigence 249 de l'annexe 1C). Le 
icSerialNumber associé au icManufacturingReferences identifie de 
manière unique le circuit de la carte. Le icSerialNumber seul n'identifie 
pas le circuit de la carte de manière unique.
  
icSerialNumber  indique le numéro de série du CI.  
icManufacturingReferences  indique l'identificateur du fabricant de CI.  
2.14.  CardConsecutiveIndex  
Indice séquentiel de la carte considérée [définition h)].
  
Attribution de valeur : (cf. annexe 1C chapitre 7)  
Ordre croissant: ‘0, …, 9, A, …, Z, a, …, z’  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 103  
2.15.  CardControlActivityDataRecord  
Informations enregistrées sur une carte de conducteur ou d'atelier et se 
rapportant au dernier contrôle auquel le conducteur considéré a été 
soumis (exigences 274, 299, 327 et 350 de l'annexe 1C).
  
controlType  indique le type de contrôle.  
controlTime  indique la date et l'heure du contrôle.  
controlCardNumber  indique le numéro intégral de la carte du contrô ­
leur qui a procédé au contrôle.  
controlVehicleRegistration  indique le VRN ainsi que l'État membre 
d'immatriculation du véhicule soumis au contrôle considéré.  
controlDownloadPeriodBegin  et controlDownloadPeriodEnd  indi­
quent la période téléchargée, en cas de téléchargement.  
2.16.  CardCurrentUse  
Informations relatives à l'usage effectif de la carte (exigences 273, 298, 
326 et 349 de l'annexe 1C).
  
sessionOpenTime  indique l'heure d'insertion 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.  
sessionOpenVehicle  correspond à l'identification du véhicule après 
insertion de la carte. Cet élément est mis à zéro lors du retrait de la carte.  
2.17.  CardDriverActivity  
Informations enregistrées sur une carte de conducteur ou d'atelier et se 
rapportant aux activités du conducteur (exigences 267, 268, 292, 293, 
321 et 344 de l'annexe 1C).
  
activityPointerOldestDayRecord  indique avec précision le début de 
l'emplacement en mémoire (nombre d'octets comptés à partir du début 
de la chaîne) du relevé quotidien complet le plus ancien que comporte la 
chaîne activityDailyRecords. La valeur maximale correspond à la 
longueur de la chaîne.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 104  
activityPointerNewestRecord  indique avec précision le début de l'em ­
placement en mémoire (nombre d'octets comptés à partir du début de la 
chaîne) du relevé quotidien le plus récent que comporte la chaîne acti ­
vityDailyRecords. La valeur maximale correspond à la longueur de la 
chaîne.  
activityDailyRecords  indique l'espace disponible affecté à l'enregistre ­
ment de données relatives aux activités du conducteur (structure de 
données: CardActivityDailyRecord) pour chaque jour civil au cours 
duquel la carte a été utilisée.  
Attribution de valeur : cette chaîne d'octets est périodiquement remplie 
de relevés du type CardActivityDailyRecord. Lors de la première utili ­
sation, 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'enregistrement se poursuit 
en reprenant au premier octet de la chaîne, sans tenir compte d'aucune 
interruption susceptible d'affecter un élément d'information 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 activity ­
DailyRecord), lesquelles se substituent aux données d'activité les plus 
anciennes, il convient d'actualiser l'activityPointerOldestDayRecord pour 
rendre compte du nouvel emplacement en mémoire qu'occupe désormais 
le relevé quotidien complet le plus ancien et de mettre à zéro l'activity ­
PreviousRecordLength de ce (nouveau) relevé quotidien complet le plus 
ancien.  
2.18.  CardDrivingLicenceInformation  
Informations enregistrées sur une carte de conducteur et se rapportant 
aux données du permis de conduire du détenteur de la carte (exigence 
259 et 284 de l'annexe 1C).
  
drivingLicenceIssuingAuthority  indique l'autorité compétente pour la 
délivrance du permis de conduire.  
drivingLicenceIssuingNation  indique la nationalité de l'autorité compé ­
tente pour la délivrance du permis de conduire.  
drivingLicenceNumber  indique le numéro du permis de conduire.  
▼M1 
2.19.  CardEventData  
Génération 1:  
Informations enregistrées sur une carte de conducteur ou d’atelier et se 
rapportant aux événements associés au détenteur de la carte (exigences 
260 et 318 de l’annexe IC).
  
CardEventData  consiste en une séquence de cardEventRecords (à l’ex ­
ception des relevés portant sur les tentatives éventuelles d’atteinte à la 
sécurité, lesquels sont regroupés dans le dernier ensemble de données de 
la séquence) dont l’agencement correspond à celui des EventFaultType 
rangés par ordre croissant.  
cardEventRecords  consiste en un jeu de relevés d’événements corres ­
pondant à un type d’événement donné (ou à cette catégorie d’événe ­
ments dans laquelle se rangent les tentatives d’atteinte à la sécurité).  
Génération 2:  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 105  
Informations enregistrées sur une carte de conducteur ou d’atelier et se 
rapportant aux événements associés au détenteur de la carte (exigences 
285 et 341 de l’annexe IC).
  
CardEventData  consiste en une séquence de cardEventRecords (à l’ex ­
ception des relevés portant sur les tentatives éventuelles d’atteinte à la 
sécurité, lesquels sont regroupés dans le dernier ensemble de données de 
la séquence) dont l’agencement correspond à celui des EventFaultType 
rangés par ordre croissant.  
cardEventRecords  consiste en un jeu de relevés d’événements corres ­
pondant à un type d’événement donné (ou à cette catégorie d’événe ­
ments dans laquelle se rangent les tentatives d’atteinte à la sécurité).  
▼B 
2.20.  CardEventRecord  
Informations enregistrées sur une carte de conducteur ou d'atelier et se 
rapportant aux événements associés au détenteur de la carte (exigences 
261, 286, 318 et 341 de l'annexe 1C).
  
eventType  indique le type d'événement.  
eventBeginTime  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.  
eventVehicleRegistration  indique le VRN ainsi que l'État membre d'im ­
matriculation 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 
rapportant aux événements associés au détenteur de la carte (exigences 
263, 288, 318 et 341 de l'annexe 1C).
  
CardFaultData  consiste en une séquence comportant un jeu de relevés 
des anomalies qui affectent l'appareil de contrôle suivi d'un jeu de 
relevés des anomalies qui affectent la ou les cartes utilisée(s).  
cardFaultRecords  consiste en un jeu de relevés des anomalies qui se 
rangent dans une catégorie donnée (appareil de contrôle ou carte).  
2.22.  CardFaultRecord  
Informations enregistrées sur une carte de conducteur ou d'atelier et se 
rapportant aux événements associés au détenteur de la carte (exigences 
264, 289, 318 et 341 de l'annexe 1C).
  
faultType  indique le type d'anomalie.  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 106  
faultBeginTime  indique la date et l'heure de début de l'anomalie.  
faultEndTime  indique la date et l'heure de fin de l'anomalie.  
faultVehicleRegistration  indique le VRN ainsi que l'État membre d'im ­
matriculation du véhicule dans lequel l'anomalie considérée s'est 
produite.  
2.23.  CardIccIdentification  
Informations enregistrées sur une carte et se rapportant à l'identification 
de cette carte à circuit intégré (CI) (exigence 248 de l'annexe 1C).
  
clockStop  indique le mode Clockstop défini dans l'appendice 2.  
cardExtendedSerialNumber  indique le numéro de série unique de la 
carte à circuit intégré spécifié par le type de données ExtendedSerial ­
Number.  
cardApprovalNumber  indique le numéro d'homologation de la carte.  
cardPersonaliserID  indique l'ID individuelle de la carte cryptée par le 
ManufacturerCode.  
embedderIcAssemblerId  fournit des informations à propos de l'intégra ­
teur/assembleur de CI.  
icIdentifier  indique l'identificateur du CI monté sur la carte et de son 
fabricant défini dans la norme ISO/IEC 7816-6.  
2.24.  CardIdentification  
Informations enregistrées sur une carte et se rapportant à l'identification 
de celle-ci (exigences 255, 280, 310, 333, 359, 365, 371 et 377 de 
l'annexe 1C).
  
cardIssuingMemberState  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.  
cardIssuingAuthorityName  indique le nom de l'autorité compétente 
pour la délivrance de la carte considérée.  
cardIssueDate  indique la date de délivrance de la carte à son titulaire 
actuel.  
cardValidityBegin  indique la date de la première entrée en vigueur de la 
carte.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 107  
cardExpiryDate  indique la date d'expiration de la carte.  
2.25.  CardMACertificate  
Génération 2:  
Certificat associé à la clé publique d'une carte destinée à son authenti ­
fication avec une VU. La structure de ce certificat est spécifiée dans 
l'appendice 11.
  
2.26.  CardNumber  
Un numéro de carte conforme à la définition g).
  
driverIdentification  indique l'identification individuelle d'un conducteur 
recensé dans un État membre.  
ownerIdentification  indique l'identification individuelle d'une entreprise, 
d'un atelier ou d'un organisme de contrôle établis dans un État membre.  
cardConsecutiveIndex  indique l'indice séquentiel de la carte considérée.  
cardReplacementIndex  indique l'indice de remplacement de la carte.  
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 conducteur, la seconde séquence de coder les numéros des 
cartes d'atelier, de contrôleur et d'entreprise.  
2.27.  CardPlaceDailyWorkPeriod  
Informations enregistrées sur une carte de conducteur ou d'atelier et se 
rapportant aux lieux de début et/ou de fin des périodes de travail jour ­
nalières (exigences 272, 297, 325 et 348 de l'annexe 1C).
  
placePointerNewestRecord  désigne l'indice du plus récent relevé de 
lieux mis à jour.  
Attribution de valeur : nombre correspondant au numérateur du relevé 
de site, commençant par une série de ‘0’ pour la première occurrence 
d'un relevé de site dans la structure considérée.  
placeRecords  indique le jeu de relevés contenant les données relatives 
aux lieux entrés.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 108  
2.28.  CardPublicKey  
Génération 1:  
Clé privée d'une carte.
  
2.29.  CardPublicKey  
Clé publique d'une carte.
  
▼M1 
2.30.  CardRenewalIndex  
Indice de renouvellement d’une carte [définition i)].
  
Attribution de valeur:  (cf. chapitre 7 de la présente annexe).  
«0» Première édition.  
Ordre croissant: «0, …, 9, A, …, Z»  
▼B 
2.31.  CardReplacementIndex  
Indice de remplacement d'une carte [définition j)].
  
Attribution de valeur : (cf. Chapitre VII de la présente annexe).  
‘0’ Carte originale.  
Ordre croissant: ‘0, …, 9, A, …, Z’  
2.32.  CardSignCertificate  
Génération 2:  
Certificat associé à la clé publique d'une carte en vue de la signature. La 
structure de ce certificat est spécifiée dans l'appendice 11.
  
2.33.  CardSlotNumber  
Code permettant de faire la distinction entre les deux lecteurs de carte 
d'une unité embarquée sur véhicule.
  
Affectation de valeur: pas spécifiée davantage.  
2.34.  CardSlotsStatus  
Code indiquant le type des cartes insérées dans les deux lecteurs de 
l'unité embarquée.
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 109  
Assignation de valeur — Octet aligné:  ‘ccccdddd’B  
‘cccc’B Identification du type de carte insérée dans le lecteur 
réservé au convoyeur  
‘dddd’B Identification du type de carte insérée dans le lecteur 
réservé au conducteur  
à l'aide des codes d'identification 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'atelier 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'entreprise est insérée dans un lecteur.  
2.35.  CardSlotsStatusRecordArray  
Génération 2:  
Le CardSlotsStatus plus les métadonnées tels qu'utilisés dans le protocole 
de téléchargement.
  
recordType  indique le type de relevé (CardSlotsStatus).  Attribution de 
valeur:  Cf. RecordType  
recordSize  indique la taille des CardSlotsStatus exprimée en octets.  
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.  CardStructureVersion  
Code indiquant la version de la structure mise en œuvre au sein d'une 
carte tachygraphique.
  
Attribution de valeur : ‘aabb’H:  
‘aa’H Index des modifications apporté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 modifications concernant l'utilisation des 
éléments d'information 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  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 110  
2.37.  CardVehicleRecord  
Informations enregistrées sur une carte de conducteur ou d'atelier et se 
rapportant à une période d'utilisation d'un véhicule donné pendant un 
jour civil déterminé (exigences 269, 294, 322 et 345 de l'annexe 1C).  
Génération 1:
  
vehicleOdometerBegin  indique la valeur affichée par le compteur kilo ­
métrique d'un véhicule donné au début de la période d'utilisation consi ­
dérée.  
vehicleOdometerEnd  indique la valeur affichée par le compteur kilomé ­
trique d'un véhicule donné à la fin de la période d'utilisation considérée.  
vehicleFirstUse  indique la date et l'heure du début de la période d'uti ­
lisation du véhicule.  
vehicleLastUse  indique la date et l'heure de la fin de la période d'utili ­
sation du véhicule.  
vehicleRegistration  indique le VRN ainsi que l'État membre où le véhi ­
cule considéré est immatriculé.  
vuDataBlockCounter  indique la valeur affichée par le compteur de 
blocs de données de la VU lors de la dernière extraction de la période 
d'utilisation du véhicule.  
Génération 2:
  
Outre la génération 1, l'élément de données suivant est utilisé:  
VehicleIdentificationNumber  désigne le numéro d'identification du 
véhicule faisant référence au véhicule dans son entier.  
2.38.  CardVehiclesUsed  
Informations enregistrées sur une carte de conducteur ou d'atelier et se 
rapportant aux événements associés au détenteur de la carte (exigences 
270, 295, 323 et 346 de l'annexe 1C).
  
vehiclePointerNewestRecord  indique l'indice du dernier relevé de véhi ­
cule actualisé par le système.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 111  
Attribution de valeur : nombre correspondant au numérateur 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.  
cardVehicleRecords  indique le jeu de relevés contenant des informa ­
tions relatives aux véhicules utilisés.  
2.39.  CardVehicleUnitRecord  
Génération 2:  
Informations enregistrées sur une carte de conducteur ou d'atelier et se 
rapportant aux événements associés au véhicule (exigences 303 et 351 de 
l'annexe 1C).
  
timeStamp  indique le début de la période d'utilisation du véhicule (c'est- 
à-dire de la première insertion de la carte dans l'unité embarquée sur 
véhicule pour cette période).  
manufacturerCode  identifie le fabricant de l'unité embarquée sur véhi ­
cule.  
deviceID  identifie le type d'unité embarquée sur le véhicule d'un fabri ­
cant. La valeur est propre au fabricant.  
vuSoftwareVersion  indique le numéro de la version du logiciel de 
l'unité embarquée sur véhicule.  
2.40.  CardVehicleUnitsUsed  
Génération 2:  
Informations enregistrées sur une carte de conducteur ou d'atelier et se 
rapportant aux unités embarquées sur véhicules associées au détenteur de 
la carte (exigences 306 et 352 de l'annexe 1C).
  
vehicleUnitPointerNewestRecord  indique l'indice du dernier relevé 
d'unité embarquée sur véhicule actualisé.  
Attribution de valeur : nombre correspondant au numérateur du relevé 
de l'unité embarquée sur véhicule, commençant par une série de ‘0’ pour 
la première occurrence d'un relevé d'unité embarquée sur véhicule dans 
la structure considérée.  
cardVehicleUnitRecords  indique le jeu de relevés contenant des infor ­
mations relatives aux unités embarquées sur véhicules utilisés.  
2.41.  Certificat  
Certificat d'une clé publique délivrée par un organisme de certification.  
Génération 1:
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 112  
Attribution de valeur : signature numérique avec récupération partielle 
du contenu d'un certificat aux termes de l'appendice 11 «Mécanismes de 
sécurité communs»: signature (128 octets) | reste de clé publique (58 
octets) | références de l'organisme de certification (8 octets).  
Génération 2:
  
Attribution de valeur: cf. appendice 11  
2.42.  CertificateContent  
Génération 1:  
Le contenu (accessible) du certificat d'une clé publique aux termes de 
l'appendice 11 «Mécanismes de sécurité communs».
  
certificateProfileIdentifier  indique la version du certificat correspon ­
dant.  
Attribution de valeur : ‘01h’ pour cette version.  
certificationAuthorityReference  identifie 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.  
certificateHolderAuthorisation  identifie les droits du titulaire du certi ­
ficat.  
certificateEndOfValidity  indique la date d'expiration administrative du 
certificat.  
certificateHolderReference  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.  
2.43.  CertificateRequestID Identification individuelle d'une demande de 
certificat.  
Identification des droits d'un titulaire de certificat.
  
Génération 1:  
tachographApplicationID  indique l'identificateur de l'application tachy ­
graphique.  
Attribution de valeur : ‘FFh’ ‘54h’ ‘41h’ ‘ 43h’ ‘48h’ ‘4Fh’. Cette ID 
d'application est un identificateur d'application exclusif non homologué, 
conforme à la norme ISO/IEC 7816-5.  
equipmentType  identifie le type d'équipement visé par le certificat.  
Attribution de valeur : en conformité avec le type de données Equip ­
mentType.  0 si le certificat émane de l'un des États membres.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 113  
Génération 2:  
tachographApplicationID  indique les 6 octets les plus significatifs de 
l'identificateur d'application (AID) pour carte tachygraphique de 
deuxième génération. Le chapitre 6.2 spécifie l'AID pour l'application 
de carte tachygraphique.  
Attribution de valeur:  ‘FF 53 4D 52 44 54’  
equipmentType  identifie le type d'équipement visé par le certificat et 
spécifié pour la génération 2.  
Attribution de valeur : en conformité avec le type de données Equip ­
mentType.  
2.44.  CertificateRequestID  
Identification individuelle d'une demande de certificat. Elle peut égale ­
ment faire office d'identificateur 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.
  
requestSerialNumber  indique le numéro de série de la demande de 
certificat, propre au fabricant, ainsi que le mois ci-après.  
requestMonthYear  identifie le mois et l'année de la demande de certi ­
ficat.  
Attribution de valeur : codage BCD du mois (deux chiffres) et de 
l'année (les deux derniers chiffres).  
crIdentifier  est un identificateur permettant de faire la distinction entre 
une demande de certificat et un numéro de série étendu.  
Attribution de valeur : ‘FFh’.  
manufacturerCode : Code du fabricant correspond au code numérique 
du fabricant qui a émis la demande de certificat.  
2.45.  CertificationAuthorityKID  
Identificateur de la clé publique d'un organisme de certification (un État 
membre ou l'organisme de certification européen).
  
nationNumeric  indique le code numérique national de l'organisme de 
certification.  
nationAlpha  indique le code alphanumérique national de l'organisme de 
certification.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 114  
keySerialNumber  est un numéro de série permettant de faire la distinc ­
tion entre les différentes clés de l'organisme de certification si certaines 
clés font l'objet de modifications.  
additionalInfo  est un champ de deux octets autorisant l'introduction de 
codes supplémentaires (propres à l'organisme de certification).  
caIdentifier  est un identificateur permettant de faire la distinction entre 
l'identificateur d'une clé associée à un organisme de certification et d'au ­
tres identificateurs de clé.  
Attribution de valeur : ‘01h’.  
2.46.  CompanyActivityData  
Informations enregistrées sur une carte d'entreprise et se rapportant aux 
activités menées avec cette carte (exigence 373 et 379 de l'annexe 1C).
  
companyPointerNewestRecord  indique l'indice du dernier relevé d'ac ­
tivité de l'entreprise actualisé par le système.  
Attribution de valeur : nombre correspondant au numérateur du relevé 
d'activité de l'entreprise, commençant par une série de ‘0’ pour la 
première occurrence d'un relevé d'activité de l'entreprise dans la structure 
considérée.  
companyActivityRecords  indique le jeu regroupant l'ensemble des 
relevés d'activité de l'entreprise.  
companyActivityRecord  indique la séquence d'informations associée à 
une activité de l'entreprise.  
companyActivityType  indique le type de l'activité menée par l'entre ­
prise.  
companyActivityTime  indique la date et l'heure de l'activité menée par 
l'entreprise.  
cardNumberInformation  indique le numéro de la carte et, le cas 
échéant, l'État membre où la carte téléchargée est délivrée.  
vehicleRegistrationInformation  indique le VRN ainsi que l'État 
membre d'immatriculation du véhicule téléchargés, verrouillés ou déver ­
rouillés.  
downloadPeriodBegin  et downloadPeriodEnd  indiquent, le cas 
échéant, la période téléchargée à partir de la VU.  
2.47.  CompanyActivityType  
Code indiquant une activité menée par une entreprise recourant à l'utili ­
sation de sa carte d'entreprise.
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 115  
2.48.  CompanyCardApplicationIdentification  
Informations enregistrées sur une carte d'entreprise et se rapportant à 
l'identification de l'application de la carte (exigences 369 et 375 de 
l'annexe 1C).
  
typeOfTachographCardId  spécifie le type de la carte mise en applica ­
tion. 
cardStructureVersion  spécifie la version de la structure mise en œuvre 
au sein de la carte.  
noOfCompanyActivityRecords  indique le nombre des relevés d'activité 
d'entreprise que la carte est susceptible de sauvegarder.  
2.49.  CompanyCardHolderIdentification  
Informations enregistrées sur une carte d'entreprise et se rapportant à 
l'identification du détenteur de la carte (exigence 372 et 378 de l'an ­
nexe 1C).
  
companyName  indique le nom de l'entreprise du titulaire.  
companyAddress  indique l'adresse de l'entreprise du titulaire.  
cardHolderPreferredLanguage indique la langue de travail préféren ­
tielle du titulaire.  
2.50.  ControlCardApplicationIdentification  
Informations enregistrées sur une carte de contrôle et se rapportant à 
l'identification de l'application de la carte (exigences 357 et 363 de 
l'annexe 1C).
  
typeOfTachographCardId  spécifie le type de la carte mise en applica ­
tion. 
cardStructureVersion  spécifie la version de la structure mise en œuvre 
au sein de la carte.  
noOfControlActivityRecords  indique le nombre des relevés d'activité 
d'entreprise que la carte est susceptible de sauvegarder.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 116  
2.51.  ControlCardControlActivityData  
Informations enregistrées sur une carte de contrôle et se rapportant aux 
activités menées avec cette carte (exigences 361 et 367 de l'annexe 1C).
  
controlPointerNewestRecord  indique l'indice du dernier relevé d'activité 
de contrôle actualisé par le système.  
Attribution 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 
occurrence d'un relevé d'activité de contrôle dans la structure considérée.  
controlActivityRecords  indique le jeu regroupant l'ensemble des relevés 
d'activité de contrôle.  
controlActivityRecord  indique la séquence d'informations associée à un 
contrôle.  
controlType  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.  
controlledVehicleRegistration  indique le VRN ainsi que l'État membre 
d'immatriculation du véhicule dans lequel le contrôle a été exécuté.  
controlDownloadPeriodBegin  et controlDownloadPeriodEnd  indi­
quent, le cas échéant, la période téléchargée.  
2.52.  ControlCardHolderIdentification  
Informations enregistrées sur une carte de contrôleur et se rapportant à 
l'identification du détenteur de la carte (exigences 360 et 366, annexe 
1C).
 
controlBodyName  indique le nom de l'organisme de contrôle dont 
dépend le détenteur de la carte.  
controlBodyAddress  indique l'adresse de l'organisme de contrôle dont 
dépend le détenteur de la carte.  
cardHolderName  indique les nom et prénom(s) du détenteur de la carte 
de contrôleur.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 117  
cardHolderPreferredLanguage indique la langue de travail préféren ­
tielle du titulaire.  
2.53.  ControlType  
Code indiquant les activités menées pendant un contrôle. Ce type de 
données est lié aux exigences 126, 274, 299, 327 et 350 de l'annexe 1C.
  
Génération 1:  
Assignation de valeur — Octet aligné:  ‘cvpdxxxx’B (8 bits)  
‘c’B card downloading:  
‘0’B: pas de téléchargement de la carte pendant cette 
activité de contrôle,  
‘1’B: téléchargement de la carte pendant cette activité de 
contrôle.  
‘v’B téléchargement de la VU:  
‘0’B: pas de téléchargement de la VU pendant cette 
activité de contrôle,  
‘1’B: téléchargement 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écution d'une impression pendant cette activité 
de contrôle.  
‘d’B affichage:  
‘0’B: pas d'affichage 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échargement de la carte:  
‘0’B: pas de téléchargement de la carte pendant cette 
activité de contrôle,  
‘1’B: téléchargement de la carte pendant cette activité de 
contrôle.  
‘v’B téléchargement de la VU:  
‘0’B: pas de téléchargement de la VU pendant cette 
activité de contrôle,  
‘1’B: téléchargement 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écution d'un tirage pendant cette activité de 
contrôle.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 118  
‘d’B affichage:  
‘0’B: pas d'affichage de données pendant cette activité 
de contrôle,  
‘1’B: affichage de données pendant cette activité de 
contrôle.  
‘e’B contrôles routiers d'étalonnage:  
‘0’B: paramètres d'étalonnage non vérifiés pendant cette 
activité de contrôle,  
‘1’B: paramètres d'étalonnage vérifiés pendant cette acti ­
vité 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 davantage.  
2.55.  CurrentDateTimeRecordArray  
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échargement.
  
recordType  indique le type de relevé (CurrentDateTime).  Attribution 
de valeur:  Cf. RecordType  
recordSize  indique la taille des CurrentDateTime exprimé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  
Compteur enregistré sur une carte de conducteur ou d'atelier, incrémenté 
d'une unité par jour civil d'insertion 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'annexe 1C.
  
Attribution de valeur : numérotation consécutive dont la valeur maxi ­
male 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 compteur corres ­
pondant est à zéro.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 119  
2.57.  Datef  
Date exprimée dans un format numérique immédiatement imprimable.
  
Attribution de valeur : 
yyyy Année  
mm Mois  
dd Jour  
‘00000000’H dénote explicitement l'absence de date.  
2.58.  DateOfDayDownloaded  
Génération 2:  
La date et l'heure du téléchargement.
  
Affectation de valeur:  pas spécifiée davantage.  
2.59.  DateOfDayDownloadedRecordArray  
Génération 2:  
L'heure et la date du téléchargement plus les métadonnées tels qu'utili ­
sées dans le protocole de téléchargement.
  
recordType  indique le type de relevé (DateOfDayDownloaded).  Attri­
bution de valeur:  Cf. RecordType  
recordSize  indique la taille des CurrentDateTime exprimé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écharge ­
ments.  
2.60.  Distance  
Distance parcourue (résultat du calcul de la différence entre deux valeurs 
affichées par le compteur kilométrique du véhicule considéré).
  
Attribution de valeur : binaire sans signe. Valeur exprimée en km et se 
situant dans une plage d'exploitation comprise entre 0 et 9 999 km.  
2.61.  DriverCardApplicationIdentification  
Informations enregistrées sur une carte de conducteur et se rapportant à 
l'identification de l'application de la carte (exigences 253 et 278 de 
l'annexe 1C).  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 120  
Génération 1:
  
typeOfTachographCardId  spécifie le type de la carte mise en applica ­
tion. 
cardStructureVersion  spécifie la version de la structure mise en œuvre 
au sein de la carte.  
noOfEventsPerType  indique le nombre d'événements que la carte est 
susceptible de sauvegarder par type d'événement.  
noOfFaultsPerType  indique le nombre d'anomalies que la carte est 
susceptible de sauvegarder par type d'anomalie.  
activityStructureLength  indique le nombre d'octets susceptibles d'être 
affectés à l'enregistrement de relevés d'activité.  
noOfCardVehicleRecords  indique le nombre des relevés de véhicule 
que la carte est susceptible de mémoriser.  
noOfCardPlaceRecords  indique le nombre de sites que la carte est 
susceptible de mémoriser.  
Génération 2:  
▼M1
 
Outre la génération 1, les éléments de données suivants sont utilisés:  
noOfGNSSADRecords  indique le nombre de relevés de temps de 
conduite accumulé GNSS que la carte est susceptible de sauvegarder.  
noOfSpecificConditionRecords  indique le nombre de relevés de condi ­
tions particulières que la carte est susceptible de mémoriser.  
noOfCardVehicleUnitRecords  indique le nombre de relevés utilisés par 
les unités embarquées sur le véhicule que la carte est susceptible de 
mémoriser.  
▼B 
2.62.  DriverCardHolderIdentification  
Informations enregistrées sur une carte de conducteur et se rapportant à 
l'identification du détenteur de la carte (exigences 256 et 281 de l'an ­
nexe 1C).
  
cardHolderName  indique les nom et prénom(s) du détenteur de la carte 
de conducteur.  
cardHolderBirthDate  indique la date de naissance du détenteur de la 
carte de conducteur.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 121  
cardHolderPreferredLanguage indique la langue de travail préféren ­
tielle du titulaire.  
▼M1 
2.63.  Réservé pour une utilisation future  
▼B 
2.64.  EGFCertificate  
Génération 2:  
Certificat associé à la clé publique d'un dispositif GNSS destiné à l'au ­
thentification mutuel avec une VU. La structure de ce certificat est 
spécifiée dans l'appendice 11.
  
2.65.  EmbedderIcAssemblerId  
Fournit les informations relatives à l'intégrateur de CI.
  
countryCode  désigne le code à deux lettres du pays où se situe l'inté ­
grateur du module conformément à la norme ISO 3166.  
moduleEmbedder  identifie l'intégrateur du module.  
manufacturerInformation  concerne l'usage interne du fabricant.  
2.66.  EntryTypeDailyWorkPeriod  
Code permettant de faire la distinction entre le lieu de début et de fin 
d'une période de travail journalière et les conditions de saisie de ces 
données.  
Génération 1
  
Attribution de valeur:  conforme à la norme ISO/IEC8824-1.  
Génération 2
  
Attribution de valeur:  conforme à la norme ISO/IEC8824-1.  
2.67.  EquipmentType  
Code permettant de faire la distinction entre différents types d'équipe ­
ment pour l'application tachygraphique.
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 122  
Génération 1:
  
Attribution de valeur : conformément à la norme ISO/IEC8824-1.  
La valeur 0 est réservée aux fins de la désignation d'un État membre ou 
de l'Europe dans le champ CHA des certificats.  
Génération 2:  
▼M1 
Les mêmes valeurs que pour la génération 1 servent pour les ajouts 
suivants:
  
Note 1:  Les valeurs de génération 2 pour la plaque, l’adaptateur et la 
connexion externe GNSS ainsi que les valeurs de génération 1 pour 
l’unité embarquée sur véhicule et le capteur de mouvement peuvent 
servir en SealRecord, le cas échéant.  
Note 2:  Dans le champ CardHolderAuthorisation (CHA) d’un certificat 
de génération 2, les valeurs (1), (2) et (6) doivent être interprétées 
comme indiquant un certificat d’authentification mutuelle du type d’équi ­
pement concerné. Pour indiquer le certificat à utiliser pour la création 
d’une signature numérique, les valeurs (17), (18) ou (19) doivent être 
utilisées.  
▼B 
2.68.  EventFaultType  
Génération 1:  
Clé publique européenne.
  
2.69.  EventFaultRecordPurpose  
Code indiquant la raison de l'enregistrement d'un événement ou d'une 
anomalie.
  
Attribution de valeur:  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 123
  
l'un des 10 (derniers) événements ou anomalies les plus récents 
l'événement le plus long survenu au cours de chacun des 10 derniers jours 
d'occurrence 
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'occurrence 
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 fabricant  
2.70.  EventFaultType  
Code caractérisant un événement ou une anomalie.
  
Attribution de valeur:  
Génération 1:
  
événements généraux 
absence d'informations complémentaires 
insertion d'une carte non valable 
conflit de carte 
chevauchement temporel 
conduite sans carte appropriée 
insertion de carte en cours de conduite 
dernière session incorrectement clôturée 
excès de vitesse 
interruption de l'alimentation électrique 
erreur sur les données de mouvement 
conflit concernant le mouvement du véhicule 
RFU
  
tentatives d'atteinte à la sécurité en rapport avec l'unité embarquée sur véhicule 
absence d'informations complémentaires 
défaut d'authentification du capteur de mouvement 
défaut d'authentification d'une carte tachygraphique 
remplacement sans autorisation du capteur 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 utilisateur mémorisées 
erreur de transfert de données internes 
ouverture illicite d'un boîtier, 
sabotage du matériel 
RFU
  
tentatives d'atteinte à la sécurité en rapport avec le capteur de mouvement 
absence d'informations complémentaires 
échec d'une authentification 
défaut d'intégrité affectant les données mémorisées 
erreur de transfert de données internes 
ouverture illicite d'un boîtier 
sabotage du matériel 
RFU
  
anomalies affectant l'appareil de contrôle 
absence d'informations complémentaires 
anomalie interne affectant la VU, 
anomalie affectant l'imprimante 
anomalie affectant l'affichage 
anomalie affectant le téléchargement 
anomalie affectant le capteur de mouvement, 
RFU ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 124
  
anomalies affectant une carte 
absence d'informations complémentaires 
RFU
  
RFU
  
propre au fabricant  
▼M1 
Génération 2:
  
événements généraux, 
absence d’informations complémentaires, 
insertion d’une carte non valable, 
conflit de carte, 
chevauchement temporel, 
conduite sans carte appropriée, 
insertion de carte en cours de conduite, 
dernière session incorrectement clôturée, 
excès de vitesse, 
Coupure d’alimentation électrique, 
erreur sur les données de mouvement, 
conflit concernant le mouvement du véhicule, 
conflit temporel (GNSS contre l’horloge interne de la VU), 
erreur de communication avec l’équipement de communication à distance, 
absence d’informations de positionnement en provenance du récepteur GNSS, 
erreur de communication avec le dispositif GNSS externe, 
RFU,
  
tentatives d’atteinte à la sécurité en rapport avec l’unité embarquée sur véhicule, 
absence d’informations complémentaires, 
défaut d’authentification du capteur de mouvement, 
défaut d’authentification d’une carte tachygraphique, 
remplacement sans autorisation du capteur 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 utilisateur mémorisées, 
erreur de transfert de données internes, 
ouverture illicite d’un boîtier, 
sabotage du matériel, 
détection de violation du dispositif GNSS, 
défaut d’authentification du dispositif GNSS externe, 
expiration du certificat du dispositif GNSS externe, 
RFU,
  
tentatives d’atteinte à la sécurité en rapport avec le capteur de mouvement, 
absence d’informations complémentaires, 
échec d’une authentification, 
défaut d’intégrité affectant les données mémorisées, 
erreur de transfert de données internes, 
ouverture illicite d’un boîtier, 
sabotage du matériel, 
RFU,  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 125
  
anomalies affectant l’appareil de contrôle, 
absence d’informations complémentaires, 
anomalie interne affectant la VU, 
anomalie affectant l’imprimante, 
anomalie affectant l’affichage, 
anomalie affectant le téléchargement, 
anomalie affectant le capteur de mouvement, 
récepteur du dispositif GNSS interne, 
dispositif GNSS externe, 
dispositif de communication à distance, 
interface ITS, 
RFU,
  
anomalies affectant une carte, 
absence d’informations complémentaires, 
RFU,
  
RFU,
  
propre au fabricant.  
2.71.  ExtendedSealIdentifier  
Génération 2:  
L’identifiant de scellement étendu identifie un scellement de manière 
unique (exigence 401, annexe IC).
  
manufacturerCode  correspond au code du fabricant du scellement.  
sealIdentifier  désigne l’identifiant du scellement, unique pour le fabri ­
cant. 
▼B 
2.72.  ExtendedSerialNumber  
Identification individuelle d'un équipement. Ce numéro peut également 
faire office d'identificateur 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.  
monthYear  identifie le mois et l'année de fabrication (ou de l'attribution 
d'un numéro de série).  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 126  
Attribution de valeur : codage BCD du mois (deux chiffres) et de 
l'année (les deux derniers chiffres).  
type est un identificateur du type d'équipement utilisé.  
Attribution de valeur : propre au fabricant, la valeur ‘FFh’ étant réser ­
vée. 
manufacturerCode : désigne le code numérique identifiant un fabricant 
d'appareil homologué.  
Génération 2:
  
serialNumber  cf. génération 1  
monthYear  cf. génération 1  
type indique le type d'équipement.  
monthYear  cf. génération 1  
2.73.  FullCardNumber  
Code permettant d'identifier avec certitude une carte tachygraphique.
  
cardType  indique le type de la carte tachygraphique.  
cardIssuingMemberState  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 tachygraphique et sa 
génération.
  
fullCardNumber  identifie la carte tachygraphique.  
generation  indique la génération de carte tachygraphique utilisée.  
2.75.  Generation  
Génération 2:  
Indique la génération de tachygraphe utilisé.
  
Attribution de valeur:  
‘00’H RFU  
‘01’H Génération 1  
‘02’H Génération 2  
‘03’H .. ‘FF’H RFU  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 127  
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 codage ± 
DDMM.M pour la latitude et du codage ± DDDMM.M pour la longi ­
tude. Les codages ± DD et ± DDD indiquent respectivement les degrés et 
MM.M, les minutes.
  
la latitude  est codée comme un multiple (facteur 10) de la représentation 
± DDMM.M.  
longitude  est codée comme un multiple (facteur 10) de la représentation 
± DDDMM.M.  
2.77.  GNSSAccuracy  
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 (facteur 10) de la valeur X.Y fournie par la phrase GSA NMEA.
  
▼M1 
2.78.  GNSSAccumulatedDriving  
Génération 2:  
Informations enregistrées sur une carte de conducteur ou d’atelier, rela ­
tives à la position GNSS du véhicule lorsque le temps de conduite 
accumulé atteint un multiple de trois heures (exigences 306 et 354, 
annexe IC).
  
gnssADPointerNewestRecord  désigne l’indice du dernier relevé de 
temps de conduite accumulé GNSS actualisé par le système.  
Attribution de valeur  est le nombre correspondant au numérateur du 
relevé de temps de conduite accumulé GNSS, commençant par une série 
de '0' pour la première occurrence d’un relevé de temps de conduite 
accumulé GNSS dans la structure considérée.  
gnssContinuousDrivingRecords  désigne le jeu de relevés contenant la 
date et l’heure lorsque le temps de conduite accumulé atteint un multiple 
de trois heures, ainsi que les informations relatives à la position du 
véhicule.  
2.79.  GNSSAccumulatedDrivingRecord  
Génération 2:  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 128  
Informations enregistrées sur une carte de conducteur ou d’atelier, rela ­
tives à la position GNSS du véhicule lorsque le temps de conduite 
accumulé atteint un multiple de trois heures (exigences 305 et 353, 
annexe IC).
  
timeStamp  désigne la date et l’heure lorsque le temps de conduite 
accumulé du détenteur de la carte atteint un multiple de trois heures.  
gnssPlaceRecord  contient les informations relatives à la position du 
véhicule.  
vehicleOdometerValue  est la valeur affichée par le compteur kilomé ­
trique pour laquelle le temps de conduite accumulé atteint un multiple de 
trois heures.  
▼B 
2.80.  GNSSPlaceRecord  
Génération 2:  
informations relatives à la position GNSS du véhicule (exigences 108, 
109, 110, 296, 305, 347 et 353, annexe 1C).
  
timeStamp  indique la date et l'heure à laquelle la position GNSS du 
véhicule a été déterminée.  
gnssAccuracy  précise le degré d'exactitude des données de position 
GNSS.  
geoCoordinates  indique l'emplacement enregistré à l'aide du dispositif 
GNSS.  
2.81.  HighResOdometer  
Valeur affichée par le compteur kilométrique du véhicule: distance totale 
parcourue par le véhicule en cours d'exploitation.
  
Attribution de valeur : binaire sans signe. Valeur exprimée en 1/200 de 
km et se situant dans une plage d'exploitation comprise entre 0 et 
21 055 406 km.  
2.82.  HighResTripDistance  
Distance parcourue pendant tout ou partie d'un trajet.
  
Attribution de valeur : binaire sans signe. Valeur exprimée en 1/200 de 
km et se situant dans une plage d'exploitation comprise entre 0 et 
21 055 406 km.  
2.83.  HolderName  
Nom et prénom(s) d'un détenteur de carte.
  
holderSurname  indique le nom du titulaire. Ce nom ne s'accompagne 
d'aucun titre.  
Attribution de valeur : si la carte considérée n'est pas individuelle, 
holderSurname contient les mêmes données que companyName, works ­
hopName ou controlBodyName.  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 129  
holderFirstNames  indique le(s) prénom(s) et initiale(s) du titulaire.  
2.84.  InternalGNSSReceiver  
Génération 2:  
Informations définissant si le récepteur GNSS est interne ou externe à 
l'unité embarquée sur le véhicule. Vrai signifie que le récepteur GNSS 
est interne à la VU. Faux signifie que le récepteur GNSS est externe.
  
2.85.  K-ConstantOfRecordingEquipment  
Constante de l'appareil de contrôle (définition m).
  
Attribution de valeur : impulsions par kilomètre dans une plage d'ex ­
ploitation comprise entre 0 et 64 255 imp/km.  
▼M1 
2.86.  KeyIdentifier  
Identificateur unique d’une clé publique permettant de la désigner et de 
la sélectionner. Cet identificateur identifie é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, d’une carte tachygraphique ou d’un dispositif 
GNSS externe.  
La seconde option permet de désigner la clé publique d’une unité embar ­
qué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.  
▼B 
2.87.  KMWCKey  
Génération 2:  
Clé AES et version de clé associée utilisée pour la VU: couplage du 
capteur de mouvement. Pour tout détail complémentaire, cf. appen ­
dice 11.
  
kMWCKey  désigne la longueur de la clé AES concaténée avec la clé 
servant à la VU: couplage du capteur de mouvement.  
keyVersion  indique la version clé de la clé AES.  
2.88.  Language  
Code identifiant une langue de travail.
  
Attribution de valeur : code composé de deux lettres minuscules, en 
conformité avec la norme ISO 639.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 130  
2.89.  LastCardDownload  
Date et heure, enregistrées sur une carte de conducteur, du dernier télé ­
chargement d'une carte (à d'autres fins que le contrôle) (exigences 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 davantage.  
2.90.  LinkCertificate  
Génération 2:  
Certificat du lien entre les clés couplées conformément à l'autorité de 
certification racine européenne.
  
2.91.  L-TyreCircumference  
Circonférence effective des pneumatiques (définition u).
  
Attribution de valeur : valeur exprimée en 1/8 de mm et se situant dans 
une plage d'exploitation comprise entre 0 et 8 031 mm.  
▼M1 
2.92.  MAC  
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.
  
▼B 
2.93.  ManualInputFlag  
Code permettant d'identifier si un détenteur de carte a procédé ou non à 
la saisie manuelle d'activités du conducteur lors de l'insertion de cette 
carte (exigence 081, annexe 1B. exigence 102, annexe 1C).
  
Affectation de valeur:  pas spécifiée davantage.  
2.94.  ManufacturerCode  
Code identifiant un fabricant d'appareil homologué.
  
Le laboratoire chargé des essais d'interopérabilité maintient à jour et 
publie la liste des codes de fabricants sur son site web (exigence 454, 
annexe 1C).  
Les numéros ManufacturerCodes sont provisoirement attribués aux 
concepteurs de tachygraphes sur demande auprès du laboratoire chargé 
des essais d'interopérabilité.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 131  
2.95.  ManufacturerSpecificEventFaultData  
Génération 2:  
Codes d'erreurs propres au fabricant simplifiant l'analyse des erreurs et la 
maintenance des unités embarquées sur les véhicules.
  
manufacturerCode  identifie le fabricant de l'unité embarquée sur véhi ­
cule.  
manufacturerSpecificErrorCode  est un code d'erreur propre au fabri ­
cant.  
2.96.  MemberStatePublicKey  
Certificat de la clé publique d'un État membre délivré par l'organisme de 
certification européen.
  
2.97.  MemberStateCertificateRecordArray  
Génération 2:  
Certificat de l'État membre plus les métadonnées tels qu'utilisés dans le 
protocole de téléchargement.
  
recordType  indique le type de relevé (MemberStateCertificate).  Attri­
bution de valeur:  Cf. RecordType  
recordSize  indique la taille des MemberStateCertificate exprimé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ésenter des 
longueurs variables.  
records  désigne le jeu de certificats des États membres.  
2.98.  MemberStatePublicKey  
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écifié.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 132  
2.100.  NationAlpha  
Renvoi alphabétique à un pays conformément aux signes distinctifs 
apposés sur les véhicules en circulation internationale (Convention de 
Vienne sur la circulation routière, Nations unies, 1968).
  
Les codes NationAlpha et NationNumeric 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érique national  
Code numérique désignant un pays.
  
Attribution de valeur:  voir le type de données 2.100 (NationAlpha).  
Toute modification ou mise à jour des spécifications NationAlpha ou 
NationNumeric ne peut intervenir qu'après consultation, par le laboratoire 
désigné, des fabricants d'unités embarquées de tachygraphe numérique et 
intelligent homologuées.  
2.102.  NoOfCalibrationsSinceDownload  
Nombre des relevés d'étalonnage qu'une carte d'atelier est susceptible de 
mémoriser.  
Génération 1:
  
Attribution de valeur:  cf. appendice 2.  
Génération 2:
  
Attribution de valeur:  cf. appendice 2.  
2.103.  NoOfCalibrationsSinceDownload  
Compteur indiquant le nombre d'étalonnages exécutés avec une carte 
d'atelier depuis son dernier téléchargement (exigence 317 et 340, 
annexe 1C).
  
Attribution de valeur : absence d'informations complémentaires.  
2.104.  NoOfCardPlaceRecords  
Nombre des relevés de site qu'une carte de conducteur ou d'atelier est 
susceptible de mémoriser.  
Génération 1:
  
Attribution de valeur:  cf. appendice 2.  
Génération 2:
  
Attribution de valeur:  cf. appendice 2.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 133  
2.105.  NoOfCardVehicleRecords  
Nombre des relevés de véhicule qu'une carte de conducteur ou d'atelier 
est susceptible de mémoriser.
  
Attribution de valeur:  cf. appendice 2.  
2.106.  NoOfCardVehicleUnitRecords  
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émoriser.
  
Attribution de valeur:  cf. appendice 2.  
2.107.  NoOfControlActivityRecords  
Nombre des relevés d'activité d'entreprise qu'une carte d'entreprise est 
susceptible de mémoriser.
  
Attribution de valeur:  cf. appendice 2.  
2.108.  NoOfEventsPerType  
Nombre des relevés d'activité de contrôle qu'une carte de contrôleur est 
susceptible de mémoriser.
  
Attribution de valeur:  cf. appendice 2.  
2.109.  NoOfEventsPerType  
Nombre d'événements qu'une carte est susceptible de mémoriser par type 
d'événement.
  
Attribution de valeur:  cf. appendice 2  
2.110.  NoOfFaultsPerType  
Nombre d'anomalies qu'une carte est susceptible de mémoriser par type 
d'anomalie.
  
Attribution de valeur:  cf. appendice 2  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 134  
2.111.  NoOfGNSSADRecords  
Génération 2:  
Nombre de relevés de temps de conduite accumulé GNSS que la carte 
est susceptible de sauvegarder.
  
Assignation de valeur:  cf. appendice 2.  
▼B 
2.112.  NoOfSpecificConditionRecords  
Génération 2:  
Nombre de relevés de conditions particulières qu'une carte est susceptible 
de mémoriser.
  
Attribution de valeur:  cf. appendice 2  
2.113.  OdometerShort  
Valeur affichée par le compteur kilométrique du véhicule sous une forme 
abrégée.
  
Attribution de valeur : binaire sans signe. Valeur exprimée en km et se 
situant dans une plage d'exploitation comprise entre 0 et 9 999 999 km.  
2.114.  OdometerValueMidnight  
Valeur affichée par le compteur kilométrique du véhicule à minuit un 
jour donné (exigence 090, annexe 1B; exigence 113, annexe 1C).
  
Affectation de valeur:  pas spécifiée davantage.  
2.115.  OdometerValueMidnightRecordArray  
Génération 2:  
OdometerValueMidnight plus les métadonnées tels qu'utilisés dans le 
protocole de téléchargement.
  
recordType  indique le type de relevé (OdometerValueMidnight).  Attri­
bution de valeur:  Cf. RecordType  
recordSize  indique la taille des OdometerValueMidnight exprimé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 OdometerValueMidnight.  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 135  
2.116.  OverspeedNumber  
Nombre d'événements du type excès de vitesse survenus depuis le 
dernier contrôle d'excès de vitesse.
  
Attribution 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 vitesse … 255 signifie 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érieur à 255.  
2.117.  PlaceRecord  
Informations relatives à un lieu de début ou de fin d'une période de 
travail journalière (exigences 108, 271, 296, 324 et 347, annexe 1C).  
Génération 1:
  
entryTime  indique la date et l'heure de la saisie des données.  
entryTypeDailyWorkPeriod  indique le type d'entrée.  
dailyWorkPeriodCountry  indique le pays entré.  
dailyWorkPeriodRegion  indique la région entrée.  
vehicleOdometerValue  indique la valeur affichée par le compteur kilo ­
métrique à l'heure de la saisie du lieu entré.  
Génération 2:
  
Outre la génération 1, les composants suivants servent:  
entryGNSSPlaceRecord  désigne le lieu et l'heure enregistrés.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 136  
2.118.  PreviousVehicleInfo  
Informations relatives au véhicule précédemment utilisé par un conduc ­
teur lors de l'insertion 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:
  
vehicleRegistrationIdentification  indique le VRN ainsi que l'État 
membre d'immatriculation du véhicule.  
cardWithdrawalTime  indique la date et l'heure de retrait de la carte.  
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.  
2.119.  PublicKey  
Génération 1:  
Clé publique RSA.
  
rsaKeyModulus  indique le module de la paire de clés.  
rsaKeyPublicExponent  indique l'exposant public de la paire de clés.  
2.120.  RecordType  
Génération 2:  
Référence à un type de relevé. Ce type de données sert au RecordArrays.
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 137  
Attribution de valeur:
  
► (1) M1 ActivityChangeInfo, 
CardSlotsStatus, 
CurrentDateTime, 
MemberStateCertificate, 
OdometerValueMidnight, 
DateOfDayDownloaded, 
SensorPaired, 
Signature, 
SpecificConditionRecord, 
VehicleIdentificationNumber, 
VehicleRegistrationNumber, 
VuCalibrationRecord, 
VuCardIWRecord, 
VuCardRecord, 
VuCertificate, 
VuCompanyLocksRecord, 
VuControlActivityRecord, 
VuDetailedSpeedBlock, 
VuDownloadablePeriod, 
VuDownloadActivityData, 
VuEventRecord,  
►M1 VuGNSSADRecord, ◄ 
VuITSConsentRecord, 
VuFaultRecord, 
VuIdentification, 
VuOverSpeedingControlData, 
VuOverSpeedingEventRecord, 
VuPlaceDailyWorkPeriodRecord, 
VuTimeAdjustmentGNSSRecord, 
VuTimeAdjustmentRecord, 
VuPowerSupplyInterruptionRecord, 
SensorPairedRecord, 
SensorExternalGNSSCoupledRecord, 
RFU, 
propre au fabricant  
2.121.  RegionAlpha  
Référence alphabétique aux différentes régions d'un pays déterminé.
  
Génération 1:  
Attribution de valeur:
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 138  
Génération 2:  
Les codes RegionAlpha sont consignés sur une liste maintenue à jour sur 
le site web du laboratoire désigné pour effectuer les essais d'interopéra ­
bilité.  
2.122.  ►C4 RegionNumeric  ◄ 
Référence alphabétique aux différentes régions d'un pays déterminé.
  
Génération 1:  
Attribution de valeur:
  
Génération 2:  
Les codes RegionNumeric 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.  RemoteCommunicationModuleSerialNumber  
Génération 2:  
Numéro de série du module de communication à distance.
  
2.124.  RSAKeyModulus  
Génération 1:  
Module d'une paire de clés RSA.
  
Attribution de valeur : Non-spécifié.  
2.125.  RSAKeyPublicExponent  
Génération 1:  
Exposant privé d'une paire de clés RSA.
  
Attribution de valeur : Non-spécifié.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 139  
2.126.  RSAKeyPublicExponent  
Génération 1:  
Exposant public d'une paire de clés RSA.
  
Attribution de valeur : Non-spécifié.  
2.127.  RtmData  
Génération 2:  
Pour la définition de ce type de données, cf. appendice 14.  
2.128.  SealDataCard  
Génération 2:  
Ce type de données stocke les informations concernant les scellés liés 
aux différents composants d'un véhicule sur une carte. Ce type de 
données est lié à l'exigence 337, annexe 1C.
  
noOfSealRecords  désigne le nombre de relevés dans sealRecords.  
sealRecords  indique un jeu de relevés de scellés.  
2.129.  SealDataVu  
Génération 2:  
Ce type de données stocke les informations concernant les scellés liés 
aux différents composants 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 stocke des informations à propos d'un scellé lié au 
composant. Ce type de données est lié à l'exigence 337, annexe 1C.
  
equipmentType  identifie le type d'équipement auquel le scellé est asso ­
cié. 
extendedSealIdentifier  désigne l'identificateur du scellé associé à l'équi ­
pement concerné.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 140  
2.131.  SensorApprovalNumber  
Numéro d'homologation du capteur.  
Génération 1:
  
Attribution de valeur : Non-spécifié.  
Génération 2:
  
Attribution 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 exemple. Le numéro d'homologation 
doit être aligné à gauche.  
2.132.  SensorExternalGNSSApprovalNumber  
Génération 2:  
Numéro d'homologation du dispositif GNSS externe.
  
Attribution 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 exemple. Le numéro d'homologation 
doit être aligné à gauche.  
2.133.  SensorExternalGNSSCoupledRecord  
Génération 2:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant à l'identification du dispositif GNSS externe 
couplé avec cette unité embarquée (exigence 100, annexe 1C).
  
sensorSerialNumber  désigne le numéro de série du dispositif GNSS 
externe appairé à l'unité embarquée sur le véhicule.  
sensorApprovalNumber  désigne le numéro d'homologation de ce dispo ­
sitif GNSS externe.  
sensorCouplingDate  indique la date de l'appariement entre ce dispositif 
GNSS externe avec l'unité embarquée sur véhicule.  
2.134.  SensorExternalGNSSIdentification  
Génération 2:  
Informations se rapportant à l'identification du dispositif GNSS externe 
(exigence 98, annexe 1C).  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 141
  
sensorSerialNumber  désigne le numéro de série étendu du dispositif 
GNSS externe.  
sensorApprovalNumber  désigne le numéro d'homologation du dispo ­
sitif GNSS externe.  
sensorSCIdentifier  indique l'identificateur du composant de sécurité du 
dispositif GNSS externe.  
sensorOSIdentifier  indique l'identificateur du système d'exploitation du 
dispositif GNSS externe.  
2.135.  SensorExternalGNSSInstallation  
Génération 2:  
Informations mémorisées dans le dispositif GNSS externe se rapportant à 
l'installation du capteur GNSS externe (exigence 123, annexe 1C).
  
sensorCouplingDateFirst  indique la date du premier couplage entre une 
unité embarquée sur véhicule et le dispositif GNSS externe.  
firstVuApprovalNumber  indique le numéro d'homologation de la 
première unité embarquée sur véhicule couplée avec le dispositif 
GNSS externe.  
firstVuSerialNumber  indique le numéro de série de la première unité 
embarquée sur véhicule couplée avec le dispositif GNSS externe.  
sensorCouplingDateCurrent  indique la date du couplage actuel entre 
l'unité embarquée sur véhicule et le dispositif GNSS externe.  
currentVuApprovalNumber  désigne le numéro d'homologation de 
l'unité embarquée sur le véhicule actuellement couplée avec le dispositif 
GNSS externe.  
currentVUSerialNumber  désigne le numéro de série de l'unité embar ­
quée sur le véhicule actuellement couplée avec le dispositif GNSS 
externe.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 142  
2.136.  SensorExternalGNSSOSIdentifier  
Génération 2:  
Identificateur du système d'exploitation du dispositif GNSS externe.
  
Attribution de valeur: propre au fabricant.  
2.137.  SensorExternalGNSSSCIdentifier  
Génération 2:  
Ce type sert p. ex. à identifier le module cryptographique du dispositif 
GNSS externe.  
Identificateur du composant de sécurité du dispositif GNSS externe.
  
Attribution de valeur:  propre au fabricant.  
2.138.  SensorGNSSCouplingDate  
Génération 2:  
Date d'un couplage entre une unité embarquée sur véhicule et le dispo ­
sitif GNSS externe.
  
Attribution de valeur : Non-spécifié.  
2.139.  SensorGNSSSerialNumber  
Génération 2:  
Ce type sert à stocker le numéro de série du récepteur GNSS situé à 
l'intérieur ou à l'extérieur de la VU.  
Numéro de série du récepteur GNSS.
  
2.140.  SensorIdentification  
Informations enregistrées dans la mémoire d'un capteur de mouvement et 
se rapportant à l'identification de cet élément (exigence 077, annexe 1B 
et exigence 95, annexe 1C).
  
sensorSerialNumber  indique le numéro de série étendu du capteur de 
mouvement (numéro de pièce et code du fabricant inclus).  
sensorApprovalNumber  indique le numéro d'homologation du capteur 
de mouvement.  
sensorSCIdentifier  indique l'identificateur du composant de sécurité du 
capteur de mouvement.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 143  
sensorOSIdentifier  indique l'identificateur du système d'exploitation du 
capteur de mouvement.  
2.141.  SensorInstallation  
Informations enregistrées dans la mémoire d'un capteur de mouvement et 
se rapportant à l'installation de cet élément (exigence 099, annexe 1B et 
exigence 122, annexe 1C).
  
sensorPairingDateFirst  indique la date du premier couplage du capteur 
de mouvement avec une unité embarquée sur véhicule.  
firstVuApprovalNumber  indique le numéro d'homologation de la 
première unité embarquée sur véhicule couplée avec le capteur de 
mouvement.  
firstVuSerialNumber  indique le numéro de série de la première unité 
embarquée sur véhicule couplée avec le capteur de mouvement.  
sensorPairingDateCurrent  indique la date du couplage actuel du 
capteur de mouvement avec l'unité embarquée sur véhicule.  
currentVuApprovalNumber  indique le numéro d'homologation de 
l'unité sur véhicule actuellement couplée avec le capteur de mouvement.  
currentVUSerialNumber  indique le numéro de série de l'unité sur véhi ­
cule actuellement couplée avec le capteur de mouvement.  
2.142.  SensorInstallationSecData  
Informations enregistrées sur une carte d'atelier et se rapportant aux 
données de sécurité nécessaires au couplage de capteurs de mouvement 
avec des unités embarquées sur véhicule (exigences 308 et 331, 
annexe 1C).  
Génération 1:
  
Attribution de valeur : conforme à la norme ISO 16844-3.  
Génération 2:  
Comme décrit dans l'appendice 11, une carte d'atelier doit mémoriser 
jusqu'à trois clés pour le couplage du capteur de mouvement situé sur 
la VU. Ces clés existent en différentes versions.
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 144  
2.143.  SensorOSIdentifier  
Identificateur du système d'exploitation du capteur 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 rapportant à l'identification du capteur de mouvement 
couplé avec cette unité embarquée (exigence 079, annexe 1B).
  
sensorSerialNumber  indique le numéro de série du capteur de mouve ­
ment actuellement couplé avec l'unité embarquée sur véhicule.  
sensorApprovalNumber  indique le numéro d'homologation du capteur 
de mouvement actuellement couplé avec l'unité embarquée sur véhicule.  
sensorPairingDateFirst  indique la date du premier couplage entre une 
unité sur véhicule et le capteur de mouvement actuellement couplé avec 
l'unité embarquée sur le véhicule considéré.  
2.145.  SensorPairedRecord  
Génération 2:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant à l'identification du capteur de mouvement 
couplé avec cette unité embarquée (exigence 97, annexe 1C).
  
sensorSerialNumber  indique le numéro de série du capteur de mouve ­
ment actuellement couplé avec l'unité embarquée sur véhicule.  
sensorApprovalNumber  indique le numéro d'homologation du capteur 
de mouvement.  
sensorPairingDate  indique une date d'appariement du capteur de 
mouvement avec l'unité embarquée sur véhicule.  
2.146.  SensorPairingDate  
Date d'un couplage du capteur de mouvement avec une unité embarquée 
sur véhicule.
  
Attribution de valeur : Non-spécifié.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 145  
2.147.  SensorSCIdentifier  
Identificateur du composant de sécurité du capteur de mouvement.
  
Attribution de valeur:  propre au fabricant.  
2.148.  SensorSerialNumber  
Numéro de série du capteur de mouvement.
  
2.149.  Signature  
Signature numérique.  
Génération 1:
  
Attribution de valeur : en conformité avec l'appendice 11 (Mécanismes 
de sécurité communs).  
Génération 2:
  
Attribution de valeur : en conformité avec l'appendice 11 (Mécanismes 
de sécurité communs).  
2.150.  SignatureRecordArray  
Génération 2:  
Jeu de signatures plus les métadonnées servant au protocole de téléchar ­
gement.
  
recordType  indique le type de relevé (Signature).  Attribution de 
valeur:  Cf. RecordType  
recordSize  indique la taille des signatures exprimé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ésenter des 
longueurs variables.  
records  indique le jeu de relevés de signatures.  
2.151.  SimilarEventsNumber  
Nombre d'événements similaires survenus un jour donné (exigence 094, 
annexe 1B; exigence 117, annexe 1C).
  
Attribution de valeur:  0 n'est pas utilisé, 1 signifie qu'un seul événe ­
ment de ce type s'est produit et a été enregistré le jour considéré, 2 
signifie que deux événements de ce type se sont produits le jour consi ­
déré (et un seul d'entre eux a été enregistré), … 255 signifie que le jour 
considéré a vu la manifestation d'un nombre d'événements de ce type 
égal ou supérieur à 255.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 146  
2.152.  SpecificConditionRecord  
Informations enregistrées sur une carte de conducteur, une carte d'atelier 
ou une unité embarquée sur véhicule et se rapportant à une condition 
particulière (exigences 130, 276, 301, 328 et 355, annexe 1C).
  
entryTime  indique la date et l'heure d'entrée de ces données.  
specificConditionType  indique le code identifiant la condition particu ­
lière concernée.  
2.153.  SpecificConditions  
Informations enregistrées sur une carte de conducteur, une carte d'atelier 
ou une unité embarquée sur véhicule et se rapportant à une condition 
particulière (exigences 131, 277, 302, 329 et 356, annexe 1C).  
Génération 2:
  
conditionPointerNewestRecord  indique l'indice du dernier relevé de 
conditions particulières mis à jour.  
Attribution de valeur : nombre correspondant au numérateur du relevé 
de conditions particulières, commençant par une série de ‘0’ pour la 
première occurrence d'un relevé de conditions particulières dans la struc ­
ture considérée.  
specificConditionRecords  indique le jeu de relevés contenant des infor ­
mations relatives à des conditions particulières.  
2.154.  SpecificConditionType  
Code identifiant une condition particulière (exigences 050b, 105a, 212a 
et 230a, annexe 1B; exigences 62, annexe 1C).
  
Génération 1:  
Attribution de valeur:  
‘00’H RFU  
‘01’H Hors champ — Début  
‘02’H Hors champ — Fin  
‘03’H Trajet en ferry/train  
‘04’H .. ‘FF’H RFU  
Génération 2:  
Attribution de valeur:  
‘00’H RFU  
‘01’H Hors champ — Début  
‘02’H Hors champ — Fin  
‘03’H Trajet en ferry/train — Début  
‘04’'H Trajet en ferry/train — Fin  
‘05’H .. ‘FF’H RFU  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 147  
2.155.  Speed  
Vitesse du véhicule (km/h).
  
Attribution de valeur : kilomètres à l'heure dans une plage d'exploita ­
tion comprise entre 0 et 220 km/h.  
2.156.  SpeedAuthorised  
Vitesse maximale autorisée du véhicule (définition hh).
  
2.157.  SpeedAverage  
Vitesse moyenne mesurée par rapport à une durée préalablement définie 
(km/h).
  
2.158.  SpeedMax  
Vitesse maximale mesurée pendant une durée préalablement définie.
  
2.159.  TachographPayload  
Génération 2:  
Pour la définition de ce type de données, cf. appendice 14.  
▼M1 
2.160.  Réservé pour une utilisation future  
▼B 
2.161.  TDesSessionKey  
Génération 1:  
Clé de session Triple DES.
  
Affectation de valeur:  pas spécifiée davantage.  
▼M1 
2.162.  TimeReal  
Code associé à un champ combinant date et heure exprimées en 
secondes à compter de 00h00m00s TUC le 1  er janvier 1970 (UTC).
  
Assignation de valeur — Octet aligné:  nombre de secondes écoulées 
depuis minuit TUC, le 1  er janvier 1970.  
La date/heure future la plus avancée se situe en l’an 2106.  
▼B 
2.163.  TyreSize  
Désignation des dimensions des pneumatiques.
  
Assignation de valeur : en conformité avec la directive 92/23/CEE du 
31.3.1992 (JO L 129, p. 95).  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 148  
2.164.  VehicleIdentificationNumber  
Numéro d'identification 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.
  
Attribution de valeur : conformément à la norme ISO 3779.  
2.165.  VehicleIdentificationNumberRecordArray  
Génération 2:  
Numéro d'identification du véhicule plus les métadonnées tels qu'utilisés 
dans le protocole de téléchargement.
  
recordType  indique le type de relevé (VehicleIdentificationNumber).  
Attribution de valeur:  Cf. RecordType  
recordSize  indique la taille des VehicleIdentificationNumber exprimé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'identification des véhicules.  
2.166.  VehicleRegistrationIdentification  
Identification d'un véhicule, unique à l'échelle de l'Europe (VIN et État 
membre).
  
vehicleRegistrationNation  indique le pays d'immatriculation du véhi ­
cule.  
vehicleRegistrationNumber  indique le numéro d'immatriculation du 
véhicule (VRN).  
2.167.  Numéro d'immatriculation du véhicule  
Numéro d'immatriculation du véhicule (VRN). Le numéro d'immatricu ­
lation est attribué par l'autorité compétente en matière d'immatriculation 
des véhicules.
  
codePage  spécifie un jeu de caractères défini au chapitre 4,  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 149  
vehicleRegNumber  indique un VRN encodé à l'aide du jeu de carac ­
tères spécifié.  
Attribution de valeur : propre à chaque pays.  
2.168.  VehicleRegistrationNumberRecordArray  
Génération 2:  
Immatriculation du véhicule plus les métadonnées tels qu'utilisées dans 
le protocole de téléchargement.
  
recordType  indique le type de relevé (VehicleRegistrationNumber).  
Attribution de valeur:  Cf. RecordType  
recordSize  indique la taille des VehicleRegistrationNumber exprimée en 
octets.  
noOfRecords  désigne le nombre de relevés dans les relevés définis.  
records  désigne le jeu des immatriculations des véhicules.  
2.169.  VuAbility  
Génération 2:  
Informations stockées dans une VU concernant sa capacité à utiliser des 
cartes tachygraphiques de génération 1 (exigence 121, annexe 1C).
  
Assignation de valeur — Octet aligné:  ‘xxxxxxxa’B (8 octets)  
Pour la compatibilité avec la génération 1:  
‘a’B Compatibilité avec les cartes tachygraphiques de 
génération 1:  
‘0’ B, compatible avec la génération 1,  
‘1’ B, incompatible 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 rapportant aux changements d'activité ainsi qu'aux chan ­
gements d'état de conduite et/ou d'état de carte pour un jour civil donné 
(exigence 084, annexe 1B; exigences 105, 106 et 107, annexe 1C) et à 
l'état des lecteurs à 00h00 ce même jour.
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 150  
noOfActivityChanges  indique le nombre de mots que comporte le jeu 
ActivityChangeInfos.  
activityChangeInfos  indique le jeu de mots ActivityChangeInfo enregis ­
trés dans la VU pour le jour considéré. Il comprend toujours deux mots 
ActivityChangeInfo donnant l'état des deux lecteurs à 00h00 ce même 
jour. 
2.171.  VuActivityDailyRecordArray  
Génération 2:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux changements d'activité ainsi qu'aux chan ­
gements d'état de conduite et/ou d'état de carte pour un jour civil donné 
(exigence 105, 106 et 107 annexe 1C) et à l'état des lecteurs à 00h00 ce 
même jour.
  
recordType  indique le type de relevé (ActivityChangeInfo).  Attribution 
de valeur:  Cf. RecordType  
recordSize  indique la taille des ActivityChangeInfo exprimée en octets.  
noOfRecords  désigne le nombre de relevés dans les relevés définis.  
records  désigne le jeu de mots ActivityChangeInfo enregistrés dans la 
VU pour le jour considéré. Il comprend toujours deux mots Activity ­
ChangeInfo donnant l'état des deux lecteurs à 00h00 ce même jour.  
2.172.  VuApprovalNumber  
Numéro d'homologation de l'unité embarquée sur véhicule.  
Génération 1:
  
Attribution de valeur : Non-spécifié.  
Génération 2:
  
Attribution 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 exemple. Le numéro d'homologation 
doit être aligné à gauche.  
2.173.  VuCalibrationData  
Génération 1:  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 151  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux étalonnages successifs de l'appareil d'en ­
registrement (exigence 098, annexe 1B).
  
noOfVuCalibrationRecords  indique le nombre des relevés que contient 
le jeu vuCalibrationRecords.  
vuCalibrationRecords  indique le jeu de relevés d'étalonnage.  
2.174.  VuCalibrationRecord  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux étalonnages successifs de l'appareil d'en ­
registrement (exigence 098, annexe 1B; exigences 119 et 120, 
annexe 1C).  
Génération 1:
  
calibrationPurpose  indique la raison de l'étalonnage.  
workshopName, workshopAddress  indiquent les nom et adresse de 
l'atelier.  
workshopCardNumber  identifie la carte d'atelier utilisée lors de l'éta ­
lonnage.  
workshopCardExpiryDate  indique la date d'expiration de la carte.  
vehicleIdentificationNumber  indique le VIN.  
vehicleRegistrationIdentification  contient le VRN et l'État membre 
d'immatriculation.  
wVehicleCharacteristicConstant  indique le coefficient caractéristique 
du véhicule.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 152  
kConstantOfRecordingEquipment  indique la constante de l'appareil de 
contrôle.  
lTyreCircumference  indique la circonférence effective des pneuma ­
tiques.  
tyreSize  indique la désignation de la dimension des pneumatiques 
montés sur le véhicule  
authorisedSpeed  indique la vitesse autorisée du véhicule.  
oldOdometerValue , newOdometerValue  indiquent les ancienne et 
nouvelle valeurs affichées par le compteur kilométrique.  
oldTimeValue, newTimeValue  indiquent les anciennes et nouvelles 
valeurs accordées à la date et à l'heure.  
nextCalibrationDate  indique la date du prochain étalonnage correspon ­
dant au type spécifié dans le champ CalibrationPurpose et auquel l'or ­
ganisme 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é:  
sealDataVu  fournit des informations relatives aux scellés liés aux diffé ­
rents composants du véhicule.  
2.175.  VuCalibrationRecordArray  
Génération 2:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux étalonnages successifs de l'appareil d'en ­
registrement (exigence 119 et 120, annexe 1C).  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 153
  
recordType  indique le type de relevé (VuCalibrationRecord).  Attribu­
tion de valeur:  Cf. RecordType  
recordSize  indique la taille des VuCalibrationRecord exprimé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'étalonnage.  
2.176.  VuCardIWData  
Génération 1:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux cycles d'insertion et de retrait des cartes 
de conducteur ou d'atelier dans le lecteur approprié de cette unité embar ­
quée (exigence 081, annexe 1B et exigence 103, annexe 1C).
  
noOfIWRecords  désigne le nombre de relevés dans le jeu vuCardIW ­
Records  
vuCardIWRecords  désigne un jeu de relevés portant sur les cycles 
d'insertion 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 rapportant aux cycles d'insertion et de retrait des cartes 
de conducteur ou d'atelier dans le lecteur approprié de cette unité embar ­
quée (exigence 081, annexe 1B et exigence 102, annexe 1C).  
Génération 1:
  
cardHolderName  indique les nom et prénom(s) du conducteur ou du 
détenteur de la carte d'atelier, 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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 154  
cardExpiryDate  indique la date d'expiration de la carte telle qu'elle est 
enregistrée sur celle-ci.  
cardInsertionTime  indique la date et l'heure d'insertion de la carte.  
vehicleOdometerValueAtInsertion  indique la valeur affichée par le 
compteur kilométrique lors de l'insertion de la carte.  
cardSlotNumber  indique le lecteur dans la fente duquel la carte est 
insérée.  
cardWithdrawalTime  indique la date et l'heure de retrait de la carte.  
vehicleOdometerValueAtWithdrawal  indique la valeur affichée par le 
compteur kilométrique lors du retrait de la carte.  
previousVehicleInfo  contient des informations relatives au précédent 
véhicule utilisé par le conducteur, 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 
conducteur lors de l'insertion 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.  VuCardIWRecordArray  
Génération 2:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux cycles d'insertion et de retrait des cartes 
de conducteur ou d'atelier dans le lecteur approprié de cette unité embar ­
quée (exigence 103, annexe 1C).
  
recordType  indique le type de relevé (VuCardIWRecord).  Attribution 
de valeur:  Cf. RecordType  
recordSize  indique la taille des VuCardIWRecord exprimée en octets.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 155  
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'insertion et de 
retrait des cartes.  
▼M1 
2.179.  VuCardRecord  
Génération 2:  
Informations enregistrées dans la mémoire d’une unité embarquée sur 
véhicule et se rapportant à la carte tachygraphique utilisée (exigence 
132, annexe IC).
  
cardNumberAndGenerationInformation  est le numéro complet et la 
génération de la carte utilisée (type de données 2.74).  
cardExtendedSerialNumber  tel qu’extrait du fichier EF_ICC sous le 
FM de la carte.  
cardStructureVersion  telle qu’extraite du fichier élémentaire EF_Ap ­
plication_Identification sous le fichier spécialisé DF_Tachograph_G2.  
cardNumber  tel qu’extrait du fichier élémentaire FE_Identification sous 
le fichier spécialisé DF_Tachograph_G2.  
▼B 
2.180.  VuCardRecordArray  
Génération 2:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux cartes tachygraphiques utilisées par cette 
VU. Ces informations servent à l'analyse de la VU: problèmes de cartes 
(exigence 132, annexe 1C).
  
recordType  indique le type de relevé (VuCardRecord).  Attribution de 
valeur:  Cf. RecordType  
recordSize  indique la taille des VuCardRecord exprimé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 tachygraphiques 
utilisées par la VU.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 156  
2.181.  VuCertificate  
Certificat associé à la clé publique d'une unité embarquée sur véhicule.
  
2.182.  VuCertificateRecordArray  
Génération 2:  
Certificat de la VU plus les métadonnées tels qu'utilisés dans le proto ­
cole de téléchargement.
  
recordType  indique le type de relevé (VuCertificate).  Attribution de 
valeur:  Cf. RecordType  
recordSize  indique la taille des VuCertificate exprimé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ésenter des 
longueurs variables.  
records  désigne un jeu de certificats de VU.  
2.183.  VuCompanyLocksData  
Génération 1:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux verrouillages d'entreprise (exigence 104, 
annexe 1B).
  
noOfLocks  indique le nombre de verrouillages répertoriés dans les 
vuCompanyLocksRecords.  
vuCompanyLocksRecords  correspond au jeu de relevés des verrouil ­
lages d'entreprise.  
2.184.  VuCompanyLocksRecord  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant à un verrouillage d'entreprise déterminé (exi ­
gence 104, annexe 1B; exigence 128, annexe 1C).  
Génération 1:
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 157  
lockInTime, lockOutTime  indiquent les dates et heures de verrouillage 
et de déverrouillage.  
companyName, companyAddress  indiquent les nom et adresse de l'en ­
treprise en rapport 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 companyCardNum ­
ber, mais plutôt l'élément suivant.  
companyCardNumberAndGeneration  identifie la carte utilisée lors du 
verrouillage et sa génération.  
2.185.  VuCompanyLocksRecordArray  
Génération 2:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux verrouillages d'entreprise (exigence 128, 
annexe 1C).
  
recordType  indique le type de relevé (VuCompanyLocksRecord).  Attri­
bution de valeur:  Cf. RecordType  
recordSize  indique la taille des VuCompanyLocksRecord exprimé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'entreprise.  
2.186.  VuControlActivityData  
Génération 1:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux contrôles exécutés à l'aide de cette VU 
(exigence 102, annexe 1B).
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 158  
noOfControls  indique le nombre de contrôles répertoriés dans les 
vuControlActivityRecords.  
vuControlActivityRecords  indique le jeu des relevés d'activité de 
contrôle.  
2.187.  VuControlActivityRecord  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux contrôles exécutés à l'aide de cette VU 
(exigence 102, annexe 1B; exigence 126, annexe 1C).  
Génération 1:
  
controlType  indique le type de contrôle.  
controlTime  indique la date et l'heure du contrôle.  
ControlCardNumber  identifie la carte de contrôleur utilisée lors du 
contrôle.  
downloadPeriodBeginTime  indique l'heure de début de la période télé ­
chargée, en cas de téléchargement.  
downloadPeriodEndTime  indique l'heure de fin de la période téléchar ­
gée, en cas de téléchargement.  
Génération 2:
  
La structure de données de génération 2 n'utilise pas controlCardNum ­
ber, mais plutôt les éléments suivants.  
controlCardNumberAndGeneration  identifie la carte de contrôleur 
utilisée lors du contrôle ainsi que sa génération.  
2.188.  VuControlActivityRecordArray  
Génération 2:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux contrôles exécutés à l'aide de cette VU 
(exigence 126, annexe 1C).  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 159
  
recordType  indique le type de relevé (VuControlActivityRecord).  Attri­
bution de valeur:  Cf. RecordType  
recordSize  indique la taille des VuControlActivityRecord exprimé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.  VuDataBlockCounter  
Compteur enregistré sur une carte et identifiant séquentiellement les 
cycles d'insertion et de retrait de la carte sur le lecteur approprié d'unités 
embarquées sur véhicules.
  
Attribution de valeur : numérotation consécutive dont la valeur maxi ­
male est égale à 9 999, la numérotation recommençant par le numéro 0.  
2.190.  VuDetailedSpeedBlock  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant à l'évolution de la vitesse du véhicule 
pendant une minute au cours de laquelle le véhicule était en mouvement 
(exigence 093, annexe 1B; exigence 116, annexe 1C).
  
speedBlockBeginDate  indique la date et l'heure de la première vitesse 
instantanée que comporte le bloc de données.  
speedsPerSecond  indique la séquence chronologique des vitesses mesu ­
rées toutes les secondes pendant la minute qui a commencé à la speed ­
BlockBeginDate (incluse).  
2.191.  VuDetailedSpeedBlockRecordArray  
Génération 2:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant à l'évolution de la vitesse du véhicule.
  
recordType  indique le type de relevé (VuDetailedSpeedBlock).  Attri­
bution de valeur:  Cf. RecordType  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 160  
recordSize  indique la taille des VuDetailedSpeedBlock exprimé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.  VuDetailedSpeedData  
Génération 1:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant à l'évolution de la vitesse du véhicule.
  
noOfSpeedBlocks  indique le nombre des blocs de vitesse que comporte 
le jeu de vuDetailedSpeedBlocks.  
vuDetailedSpeedBlocks  indique le jeu de blocs de mesure de la vitesse 
instantanée.  
2.193.  VuDownloadablePeriod  
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 
(exigences 081, 084 ou 087, annexe 1B; exigences 102, 105 et 108, 
annexe 1C).
  
minDownloadableTime  indique les date et heure de l'insertion de carte, 
de l'entrée de site ou du changement d'activité le plus ancien enregistrées 
dans la mémoire de l'unité embarquée sur véhicule.  
maxDownloadableTime  indique les date et heure du retrait de carte, de 
l'entrée de site ou du changement d'activité le plus récent enregistrées 
dans la mémoire de l'unité embarquée sur véhicule.  
2.194.  VuDownloadablePeriodRecordArray  
Génération 2:  
VUDownloadablePeriod plus les métadonnées tels qu'utilisés dans le 
protocole de téléchargement.
  
recordType  indique le type de relevé (VuDownloadablePeriod).  Attri­
bution de valeur:  Cf. RecordType  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 161  
recordSize  indique la taille des VuDownloadablePeriod exprimée en 
octets.  
noOfRecords  désigne le nombre de relevés dans les relevés définis.  
records  indique le jeu de relevés VuDownloadablePeriod.  
2.195.  VuDownloadActivityData  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant au plus récent téléchargement (exigence 105, 
annexe 1B; exigence 129, annexe 1C).  
Génération 1:
  
downloadingTime  indique la date et l'heure du téléchargement.  
fullCardNumber  identifie la carte utilisée pour autoriser le télécharge ­
ment.  
companyOrWorkshopName  indique le nom de l'entreprise ou de l'ate ­
lier. 
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 auto ­
riser le téléchargement ainsi que sa génération.  
2.196.  VuDownloadActivityDataRecordArray  
Génération 2:  
Informations se rapportant au dernier téléchargement de la VU (exigence 
129, annexe 1C).
  
recordType  indique le type de relevé (VuDownloadActivityData).  
Attribution de valeur:  Cf. RecordType  
recordSize  indique la taille des VuDownloadActivityData exprimée en 
octets.  
noOfRecords  désigne le nombre de relevés dans les relevés définis.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 162  
records  désigne le jeu regroupant l'ensemble des relevés de données 
d'activité relatives au téléchargement.  
2.197.  VuEventData  
Génération 1:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant à divers événements (exigence 094, annexe 1B, 
à l'exception des événements du type excès de vitesse).
  
noOfVuEvents  indique le nombre des événements répertoriés dans le 
jeu des vuEventRecords.  
vuEventRecords  indique un jeu de relevés d'événements.  
2.198.  VuEventRecord  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant à divers événements (exigence 094, annexe 1B; 
exigence 117, annexe 1C, à l'exception des événements du type excès de 
vitesse).  
Génération 1:
  
eventType  indique le type d'événement.  
eventRecordPurpose  indique la raison de l'enregistrement de l'événe ­
ment considéré.  
eventBeginTime  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.  
cardNumberDriverSlotBegin  identifie la carte insérée dans le lecteur 
réservé au conducteur, au début de l'événement.  
cardNumberCodriverSlotBegin  identifie la carte insérée dans le lecteur 
réservé au convoyeur, au début de l'événement.  
cardNumberDriverSlotEnd  identifie la carte insérée dans le lecteur 
réservé au conducteur, à la fin de l'événement.  
cardNumberCodriverSlotEnd  identifie la carte insérée dans le lecteur 
réservé au convoyeur, à la fin de l'événement.  
similarEventsNumber  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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 163  
Génération 2:
  
Outre la génération 1, les éléments de données suivants sont utilisés:  
manufacturerSpecificEventFaultData  contient des informations 
complémentaires propres au fabricant et se rapportant à l'événement.  
La structure de données de génération 2 n'utilise pas cardNumberDri ­
verSlotBegin, cardNumberCodriverSlotBegin, cardNumberDriverSlotEnd 
et cardNumberCodriverSlotEnd, mais plutôt les éléments suivants:  
cardNumberAndGenDriverSlotBegin  identifie la carte insérée dans le 
lecteur réservé au conducteur ainsi que sa génération, au début de l'évé ­
nement.  
cardNumberAndGenCodriverSlotBegin  identifie la carte insérée dans 
le lecteur réservé au convoyeur ainsi que sa génération, au début de 
l'événement.  
cardNumberAndGenDriverSlotEnd  identifie la carte insérée dans le 
lecteur réservé au conducteur ainsi que sa génération, à la fin de l'évé ­
nement.  
cardNumberAndGenCodriverSlotEnd  identifie la carte insérée dans le 
lecteur réservé au convoyeur ainsi que sa génération, à la fin de l'évé ­
nement.  
Si l'événement est un conflit temporel, il convient d'interpréter eventBe ­
ginTime et eventEndTime de la manière suivante:  
eventBeginTime  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.  VuEventRecordArray  
Génération 2:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant à divers événements (exigence 117, annexe 1C, 
à l'exception des événements du type excès de vitesse).
  
recordType  indique le type de relevé (VuEventRecord).  Attribution de 
valeur:  Cf. RecordType  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 164  
recordSize  indique la taille des VuEventRecord exprimé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 rapportant à diverses anomalies (exigence 096, 
annexe 1B).
  
noOfVuFaults  indique le nombre des anomalies répertorié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 rapportant à une anomalie (exigence 096, annexe 1B; 
exigence 118, annexe 1C).  
Génération 1:
  
faultType  indique le type d'anomalie affectant l'appareil de contrôle.  
faultRecordPurpose  indique la raison de l'enregistrement de l'anomalie 
considérée.  
faultBeginTime  indique la date et l'heure de début de l'anomalie.  
faultEndTime  indique la date et l'heure de fin de l'anomalie.  
cardNumberDriverSlotBegin  identifie la carte insérée dans le lecteur 
réservé au conducteur, au début de l'anomalie.  
cardNumberCodriverSlotBegin  identifie la carte insérée dans le lecteur 
réservé au convoyeur, au début de l'anomalie.  
cardNumberDriverSlotEnd  identifie la carte insérée dans le lecteur 
réservé au conducteur, à la fin de l'anomalie.  
cardNumberCodriverSlotEnd  identifie la carte insérée dans le lecteur 
réservé au convoyeur, à la fin de l'anomalie.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 165  
Génération 2:
  
Outre la génération 1, l'élément de données suivant est utilisé:  
manufacturerSpecificEventFaultData  contient des informations 
complémentaires propres au fabricant et se rapportant à l'événement.  
La structure de données de génération 2 n'utilise pas cardNumberDri ­
verSlotBegin, cardNumberCodriverSlotBegin, cardNumberDriverSlotEnd 
et cardNumberCodriverSlotEnd, mais plutôt les éléments suivants:  
cardNumberAndGenDriverSlotBegin  identifie la carte insérée dans le 
lecteur réservé au conducteur ainsi que sa génération, au début de l'évé ­
nement.  
cardNumberAndGenCodriverSlotBegin  identifie la carte insérée dans 
le lecteur réservé au convoyeur ainsi que sa génération, au début de 
l'anomalie.  
cardNumberAndGenDriverSlotEnd  identifie la carte insérée dans le 
lecteur réservé au conducteur ainsi que sa génération, à la fin de l'ano ­
malie.  
cardNumberAndGenCodriverSlotEnd  identifie la carte insérée dans le 
lecteur réservé au convoyeur ainsi que sa génération, à la fin de l'ano ­
malie.  
2.202.  VuFaultRecordArray  
Génération 2:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant à diverses anomalies (exigence 118, 
annexe 1C).
  
recordType  indique le type de relevé (VuFaultRecord).  Attribution de 
valeur:  Cf. RecordType  
recordSize  indique la taille des VuFaultRecord exprimé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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 166  
2.203.  VuGNSSADRecord  
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 accumulé atteint un multiple de trois heures (exigences 108 et 
110, annexe IC).
  
timeStamp  désigne la date et l’heure où le temps de conduite accumulé 
atteint un multiple de trois heures.  
cardNumberAndGenDriverSlot  identifie la carte insérée dans le lecteur 
réservé au conducteur ainsi que sa génération.  
cardNumberAndGenCodriverSlot  identifie la carte insérée dans le 
lecteur réservé au convoyeur ainsi que sa génération.  
gnssPlaceRecord  contient les informations relatives à la position du 
véhicule.  
vehicleOdometerValue  est la valeur affichée par le compteur kilomé ­
trique pour laquelle le temps de conduite accumulé atteint un multiple de 
trois heures.  
2.204.  VuGNSSADRecordArray  
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 accumulé atteint un multiple de trois heures (exigences 108 et 
110, annexe IC).
  
recordType  indique le type de relevé (VuGNSSADRecord).  
Assignation de valeur:  Cf. RecordType  
recordSize  indique la taille des VuGNSSADRecord exprimé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 temps de conduite accumulé 
GNSS.  
▼B 
2.205.  VuIdentification  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant à l'identification de l'unité embarquée (exigence 
075, annexe 1B; exigences 93 et 121, annexe 1C).  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 167  
Génération 1:
  
vuManufacturerName  indique le nom du fabricant de l'unité embar ­
quée sur véhicule.  
vuManufacturerAddress  indique l'adresse du fabricant de l'unité 
embarquée sur véhicule.  
vuPartNumber  indique le numéro de pièce de l'unité embarquée sur 
véhicule.  
vuSerialNumber  indique le numéro de série de l'unité embarquée sur 
véhicule.  
vuSoftwareIdentification  identifie le logiciel mis en œuvre au sein de 
l'unité embarquée sur véhicule.  
vuManufacturingDate  indique la date de fabrication de l'unité embar ­
quée sur véhicule.  
vuApprovalNumber  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 compatibilité de la 
VU avec les cartes tachygraphiques de génération 1.  
2.206.  VuIdentificationRecordArray  
Génération 2:  
VuIdentification plus les métadonnées tels qu'utilisés dans le protocole 
de téléchargement.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 168
  
recordType  indique le type de relevé (VuIdentification).  Attribution de 
valeur:  Cf. RecordType  
recordSize  indique la taille des VuIdentification exprimée en octets.  
noOfRecords  désigne le nombre de relevés dans les relevés définis.  
records  indique un jeu de relevés VuIdentification.  
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 Intelligent Transport 
Systems.
  
cardNumberAndGen  identifie la carte et sa génération. Il doit s'agir 
d'une carte de conducteur ou d'atelier.  
consent  désigne un drapeau qui signale si le conducteur a donné son 
accord sur l'utilisation des Intelligent Transport Systems avec ce véhicule 
ou cette unité embarquée sur véhicule.  
Attribution de valeur:  
VRAI indique l'accord du conducteur sur l'utilisation des 
Intelligent Transport Systems.  
FAUX indique le refus du conducteur sur l'utilisation des 
Intelligent Transport Systems.  
2.208.  VuITSConsentRecordArray  
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 Intelligent Transport 
Systems (exigence 200, annexe 1C).
  
recordType  indique le type de relevé (VuITSConsentRecord).  Attribu­
tion de valeur:  Cf. RecordType  
recordSize  indique la taille des VuITSConsentRecord exprimé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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 169  
2.209.  VuManufacturerAddress  
Adresse du fabricant de l'unité embarquée sur véhicule.
  
Attribution de valeur : Non-spécifié.  
2.210.  VuManufacturerName  
Nom du fabricant de l'unité embarquée sur véhicule.
  
Attribution de valeur : Non-spécifié.  
2.211.  VuManufacturingDate  
Date de fabrication de l'unité embarquée sur véhicule.
  
Attribution de valeur : Non-spécifié.  
2.212.  VuOverSpeedingControlData  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux événements du type excès de vitesse 
survenus depuis le dernier contrôle d'excès de vitesse (exigence 095, 
annexe 1B; exigence 117, annexe 1C).
  
lastOverspeedControlTime  indique la date et l'heure du dernier 
contrôle d'excès de vitesse.  
firstOverspeedSince  indique la date et l'heure du premier excès de 
vitesse constaté depuis ce contrôle d'excès de vitesse.  
numberOfOverspeedSince  indique le nombre d'événements du type 
excès de vitesse survenus depuis le dernier contrôle d'excès de vitesse.  
2.213.  VuOverSpeedingControlDataRecordArray  
Génération 2:  
VuOverSpeedingControlData plus les métadonnées tels qu'utilisés dans 
le protocole de téléchargement.
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 170  
recordType  indique le type de relevé (VuOverSpeedingControlData).  
Attribution de valeur:  Cf. RecordType  
recordSize  indique la taille des VuOverSpeedingControlData exprimé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.  VuOverSpeedingEventData  
Génération 1:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux événements du type excès de vitesse (exi ­
gence 094, annexe 1B).
  
noOfVuOverSpeedingEvents  indique le nombre d'événements réperto ­
riés dans le jeu vuOverSpeedingEventRecords.  
vuOverSpeedingEventRecords  indique un jeu de relevés d'événements 
du type excès de vitesse.  
2.215.  VuOverSpeedingEventRecord  
Génération 1:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux événements du type excès de vitesse (exi ­
gence 094, annexe 1B; exigence 117, annexe 1C).
  
eventType  indique le type d'événement.  
eventRecordPurpose  indique la raison de l'enregistrement de l'événe ­
ment considéré.  
eventBeginTime  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.  
maxSpeedValue  indique la vitesse maximale mesurée au cours de l'évé ­
nement.  
averageSpeedValue  indique la vitesse moyenne arithmétique mesurée 
au cours de l'événement.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 171  
cardNumberDriverSlotBegin  identifie la carte insérée dans le lecteur 
réservé au conducteur, au début de l'événement.  
similarEventsNumber  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 rapportant aux événements du type excès de vitesse (exi ­
gence 094, annexe 1B; exigence 117, annexe 1C).
  
La structure de données de génération 2 n'utilise pas cardNumberDri ­
verSlotBegin, mais plutôt l'élément suivant:  
cardNumberAndGenDriverSlotBegin  
2.216.  VuOverSpeedingEventRecordArray  
Génération 2:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux événements du type excès de vitesse (exi ­
gence 117, annexe 1C).
  
recordType  indique le type de relevé (VuOverSpeedingEventRecord).  
Attribution de valeur:  Cf. RecordType  
recordSize  indique la taille des VuOverSpeedingEventRecord exprimé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.  VuPartNumber  
Numéro de pièce de l'unité embarquée sur véhicule.
  
Attribution de valeur : propre au fabricant de la VU.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 172  
2.218.  VuPlaceDailyWorkPeriodData  
Génération 1:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux lieux de début ou de fin des périodes de 
travail journalières des conducteurs (exigence 087, annexe 1B; exigences 
108 et 110, annexe 1C).
  
noOfPlaceRecords  indique le nombre des relevés répertoriés dans le jeu 
vuPlaceDailyWorkPeriodRecords.  
vuPlaceDailyWorkPeriodRecords  indique un jeu de relevés de lieux.  
2.219.  VuPlaceDailyWorkPeriodRecord  
Génération 1:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux lieux de début ou de fin des périodes de 
travail journalières des conducteurs (exigence 087, annexe 1B; exigences 
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 rapportant aux lieux de début ou de fin des périodes de 
travail journalières des conducteurs (exigence 087, annexe 1B; exigences 
108 et 110, annexe 1C).
  
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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 173  
2.220.  VuPlaceDailyWorkPeriodRecordArray  
Génération 2:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux lieux de début ou de fin des périodes de 
travail journalières des conducteurs (exigence 108 et 110, annexe 1C).
  
recordType  indique le type de relevé (VuPlaceDailyWorkPeriodRe ­
cord).  Attribution de valeur:  Cf. RecordType  
recordSize  indique la taille des VuPlaceDailyWorkPeriodRecord 
exprimé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.  VuSerialNumber  
Numéro de série de l'unité embarquée sur véhicule (exigence 075, 
annexe 1B; exigence 93, annexe 1C).
  
2.224.  VuSoftInstallationDate  
Date d'installation de la version du logiciel d'exploitation de l'unité 
embarquée sur véhicule.
  
Attribution de valeur : Non-spécifié.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 174  
2.225.  VuSoftwareIdentification  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant au logiciel installé.
  
vuSoftwareVersion  indique le numéro de la version du logiciel de 
l'unité embarquée sur véhicule.  
vuSoftInstallationDate  indique la date d'installation de cette version du 
logiciel.  
2.226.  VuSoftwareVersion  
Numéro de la version du logiciel de l'unité embarquée sur véhicule.
  
Attribution de valeur : Non-spécifié.  
2.227.  VuSpecificConditionData  
Génération 1:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux conditions particulières.
  
noOfSpecificConditionRecords  indique le nombre des relevés réperto ­
riés dans le jeu specificConditionRecords.  
specificConditionRecords  indique un jeu de relevés relatifs à des condi ­
tions particulières.  
2.228.  VuSpecificConditionRecordArray  
Génération 2:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux conditions particulières (exigence 130, 
annexe 1C).
  
recordType  indique le type de relevé (SpecificConditionRecord).  Attri­
bution de valeur:  Cf. RecordType  
recordSize  indique la taille des SpecificConditionRecord exprimé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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 175  
2.229.  VuTimeAdjustmentData  
Génération 1:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux remises à l'heure exécutées hors du 
cadre d'un étalonnage complet (exigence 101, annexe 1B).
  
noOfVuTimeAdjRecords  indique le nombre des relevés répertoriés 
dans le jeu vuTimeAdjustmentRecords.  
vuTimeAdjustmentRecords  indique un jeu de relevés de remises à 
l'heure.  
▼M1 
2.230. Réservé pour une utilisation future  
2.231. Réservé pour une utilisation future  
▼B 
2.232.  VuTimeAdjustmentRecord  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux remises à l'heure exécutées hors du 
cadre d'un étalonnage complet (exigence 101, annexe 1B; 
exigences 124 et 125, annexe 1C).  
Génération 1:
  
oldTimeValue, newTimeValue  indiquent les anciennes et nouvelles 
valeurs accordées à la date et à l'heure.  
workshopName, workshopAddress  indiquent les nom et adresse de 
l'atelier.  
workshopCardNumber  identifie la carte d'atelier utilisée pour exécuter 
la remise à l'heure.  
Génération 2:
  
La structure de données de génération 2 n'utilise pas workshopCard ­
Number, mais plutôt l'élément suivant:  
workshopCardNumberAndGeneration  identifie la carte d'atelier 
utilisée pour exécuter la remise à l'heure ainsi que sa génération.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 176  
2.233.  VuTimeAdjustmentRecordArray  
Génération 2:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux remises à l'heure exécutées hors du 
cadre d'un étalonnage complet (exigences 124 et 125, annexe 1C).
  
recordType  indique le type de relevé (VuTimeAdjustmentRecord).  
Attribution de valeur:  Cf. RecordType  
recordSize  indique la taille des VuTimeAdjustmentRecord exprimé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.  
2.234.  WorkshopCardApplicationIdentification  
Informations enregistrées sur une carte d'atelier et se rapportant à l'iden ­
tification de l'application de la carte (exigences 307 et 330 de l'an ­
nexe 1C).  
Génération 1:
  
typeOfTachographCardId  spécifie le type de la carte mise en applica ­
tion. 
cardStructureVersion  spécifie la version de la structure mise en œuvre 
au sein de la carte.  
noOfEventsPerType  indique le nombre d'événements que la carte est 
susceptible de sauvegarder par type d'événement.  
noOfFaultsPerType  indique le nombre d'anomalies que la carte est 
susceptible de sauvegarder par type d'anomalie.  
activityStructureLength  indique le nombre d'octets susceptibles d'être 
affectés à l'enregistrement de relevés d'activité.  
noOfCardVehicleRecords  indique le nombre des relevés de véhicule 
que la carte est susceptible de mémoriser.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 177  
noOfCardPlaceRecords  indique le nombre de sites que la carte est 
susceptible de mémoriser.  
noOfCalibrationRecords  indique le nombre des relevés d'étalonnage 
que la carte est susceptible de mémoriser.  
Génération 2:  
▼M1
 
Outre la génération 1, les éléments de données suivants sont utilisés:  
noOfGNSSADRecords  indique le nombre de relevés de temps de 
conduite accumulé GNSS que la carte est susceptible de sauvegarder.  
noOfSpecificConditionRecords  indique le nombre de relevés de condi ­
tions particulières que la carte est susceptible de mémoriser.  
noOfCardVehicleUnitRecords  indique le nombre de relevés utilisés par 
les unités embarquées sur le véhicule que la carte est susceptible de 
mémoriser.  
▼B 
2.235.  WorkshopCardCalibrationData  
Informations enregistrées sur une carte d'atelier et se rapportant aux 
activités d'atelier menées avec cette carte (exigences 314, 316, 337 et 
339, annexe 1C).
  
calibrationTotalNumber  indique le nombre total d'étalonnages exécutés 
avec la carte.  
calibrationPointerNewestRecord  indique l'indice du dernier relevé 
d'étalonnages mis à jour.  
Attribution de valeur : nombre correspondant au numérateur du relevé 
d'étalonnage, commençant par une série de ‘0’ pour la première occur ­
rence d'un relevé d'étalonnage dans la structure considérée.  
calibrationRecords  indique le jeu de relevés contenant des données 
d'étalonnage et/ou de réglage temporel.  
2.236.  WorkshopCardCalibrationRecord  
Informations enregistrées sur une carte d'atelier et se rapportant à un 
étalonnage exécuté avec la carte (exigences 314 et 337, annexe 1C).  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 178  
Génération 1:
  
calibrationPurpose  indique la raison de l'étalonnage.  
vehicleIdentificationNumber  indique le VIN.  
vehicleRegistration  contient le VRN et l'État membre d'immatriculation.  
wVehicleCharacteristicConstant  indique le coefficient caractéristique 
du véhicule.  
kConstantOfRecordingEquipment  indique la constante de l'appareil de 
contrôle.  
lTyreCircumference  indique la circonférence effective des pneuma ­
tiques.  
tyreSize  indique la désignation de la dimension des pneumatiques 
montés sur le véhicule.  
authorisedSpeed  indique la vitesse maximale autorisée du véhicule.  
oldOdometerValue , newOdometerValue  indiquent les ancienne et 
nouvelle valeurs affichées par le compteur kilométrique.  
oldTimeValue, newTimeValue  indiquent les anciennes et nouvelles 
valeurs accordées à la date et à l'heure.  
nextCalibrationDate  indique la date du prochain étalonnage correspon ­
dant au type spécifié dans le champ CalibrationPurpose et auquel l'or ­
ganisme d'inspection agréé doit procéder.  
vuPartNumber , vuSerialNumber  et sensorSerialNumber  constituent 
les éléments d'information nécessaires à l'identification de l'appareil d'en ­
registrement.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 179  
Génération 2:
  
Outre la génération 1, les éléments de données suivants sont utilisés:  
sensorGNSSSerialNumber  qui identifie un dispositif GNSS externe.  
rcmSerialNumber  qui identifie un module de communication à 
distance.  
sealDataCard  fournit des informations relatives aux scellés liés aux 
différents composants du véhicule.  
2.237.  WorkshopCardHolderIdentification  
Informations enregistrées sur une carte d'atelier et se rapportant à l'iden ­
tification du détenteur de la carte (exigence 311 et 334, annexe 1C).
  
workshopName  indique le nom de l'atelier du détenteur de la carte.  
workshopAddress  indique l'adresse de l'atelier du détenteur de la carte.  
cardHolderName  indique les nom et prénom(s) du détenteur (p.ex. le 
nom du mécanicien).  
cardHolderPreferredLanguage  indique la langue de travail préféren ­
tielle du titulaire.  
2.238.  WorkshopCardPIN  
Numéro d'identification individuel de la carte d'atelier (exi ­
gences 309 et 332, annexe 1C).
  
Attribution de valeur : le numéro d'identification individuel connu du 
détenteur de la carte, complété à droite d'une série d'octets ‘FF’ suscep ­
tible de compter 8 octets.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 180  
2.239.  W-VehicleCharacteristicConstant  
Coefficient caractéristique du véhicule (définition k).
  
Attribution de valeur : Impulsions par kilomètre dans la plage d'exploi ­
tation 0 à 64 255 imp/km.  
2.240.  VuPowerSupplyInterruptionRecord  
Génération 2:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux événements du type interruption de l'ali ­
mentation électrique (exigence 117, annexe 1C).
  
eventType  indique le type d'événement.  
eventRecordPurpose  indique la raison de l'enregistrement de l'événe ­
ment considéré.  
eventBeginTime  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.  
cardNumberAndGenDriverSlotBegin  identifie la carte insérée dans le 
lecteur réservé au conducteur ainsi que sa génération, au début de l'évé ­
nement.  
cardNumberAndGenDriverSlotEnd  identifie la carte insérée dans le 
lecteur réservé au conducteur ainsi que sa génération, à la fin de l'évé ­
nement.  
cardNumberAndGenCodriverSlotBegin  identifie la carte insérée dans 
le lecteur réservé au convoyeur ainsi que sa génération, au début de 
l'événement.  
cardNumberAndGenCodriverSlotEnd  identifie la carte insérée dans le 
lecteur réservé au convoyeur ainsi que sa génération, à la fin de l'évé ­
nement.  
similarEventsNumber  indique le nombre d'événements similaires 
survenus le même jour.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 181  
2.241.  VuPowerSupplyInterruptionRecordArray  
Génération 2:  
Informations enregistrées dans la mémoire d'une unité embarquée sur 
véhicule et se rapportant aux événements du type excès de vitesse (exi ­
gence 117, annexe 1C).
  
recordType  indique le type de relevé (VuPowerSupplyInterruptionRe ­
cord).  Attribution de valeur:  Cf. RecordType  
recordSize  indique la taille des VuPowerSupplyInterruptionRecord 
exprimé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 interruptions de 
l'alimentation électrique.  
2.242.  VuSensorExternalGNSSCoupledRecordArray  
Génération 2:  
Jeu de SensorExternalGNSSCoupledRecord plus les métadonnées 
servant au protocole de téléchargement.
  
recordType  indique le type de relevé (SensorExternalGNSSCoupledRe ­
cord).  Attribution de valeur:  Cf. RecordType  
recordSize  indique la taille des SensorExternalGNSSCoupledRecord 
exprimé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 capteur.  
2.243.  VuSensorPairedRecordArray  
Génération 2:  
Jeu de SensorPairedRecord plus les métadonnées servant au protocole de 
téléchargement.
  
recordType  indique le type de relevé (SensorPairedRecord).  Attribu­
tion de valeur:  Cf. RecordType  
recordSize  indique la taille des SensorPairedRecord exprimée en octets.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 182  
noOfRecords  désigne le nombre de relevés dans les relevés définis.  
records  indique un jeu de relevés d'appariement du capteur.  
3. DÉFINITIONS DES PLAGES DE VALEURS ET DE DIMENSIONS  
Définition des variables employées dans les définitions du paragraphe 2.
  
4. JEUX DE CARACTÈRES  
Les chaînes IA5 se composent par définition de caractères ASCII aux 
termes de la norme ISO/IEC 8824-1. Pour plus de lisibilité et pour 
faciliter la désignation des caractères, leur assignation de valeur est 
indiquée ci-après. En cas de divergence, la norme ISO/IEC 8824-1 l'em ­
porte sur cette note d'information.
  
D'autres chaînes de caractères (Address, Name, VehicleRegistration ­
Number) utilisent en outre les caractères de la plage de caractères déci ­
maux 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/Cyrillique  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/Cyrillique  80  
KOI8-U Latin/Cyrillique  85  
5. ENCODAGE  
Si les règles de codage ASN.1 s'appliquent aux différents types de 
données définis, leur codage doit être conforme à la norme ISO/IEC 
8825-2, variante alignée.  
6. IDENTIFICATEURS D'OBJETS ET IDENTIFICATEURS D'APPLI ­
CATIONS  
6.1. Identificateurs d'objets  
Les identificateurs d'objets (IDO) répertoriés dans le présent chapitre 
concernent exclusivement la génération 2. Ces IDO sont spécifiés dans  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 183  
le rapport technique TR-03110-3 et rappelés aux présentes à titre d'exhaus ­
tivité. Ces IDO sont contenus dans la sous-arborescence bsi-de:
  
Identificateurs de protocole d'authentification destinés aux VU
  
Exemple:  si l'authentification de la VU est exécutée à l'aide de SHA-384, 
l'identificateur 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’  
Identificateurs de protocole d'authentifiation destinés aux circuits
  
Exemple:  prenons le cas d'une authentification de circuit devant être 
exécutée à l'aide de l'algorithme 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'algorithme CMAC 
pour garantir l'authenticité des données. Par conséquent, l'identifica ­
teur 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 03 02 02’
  
‘04 00 7F 00 07 02 02 03 02 03’
  
‘04 00 7F 00 07 02 02 03 02 04’  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 184  
6.2. Identificateur d'application  
Génération 2:  
L'identificateur d'applications (AID) destiné au dispositif GNSS externe 
(génération 2) est communiqué par ‘FF 44 54 45 47 4D’. Il s'agit d'un 
AID exclusif conforme à la norme ISO/IEC 7816-4.  
Remarque:  les 5 derniers octets codent le DTEGM pour le dispositif 
GNSS externe de tachygraphe intelligent.  
L'identificateur d'applications destiné aux applications de cartes tachy ­
graphiques (génération 2) est communiqué par ‘FF 53 4D 52 44 54’. Il 
s'agit d'un AID exclusif conforme à la norme ISO/IEC 7816-4.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 185  
Appendice 2  
SPÉCIFICATION DES CARTES TACHYGRAPHIQUES  
TABLE DES MATIÈRES  
1. INTRODUCTION  
1.1. Abréviations  
1.2. Références  
2. CARACTÉRISTIQUES ÉLECTRIQUES ET PHYSIQUES  
2.1. Tension d'alimentation et consommation de courant  
2.2. Tension de programmation V  pp 
2.3. Génération et fréquence d'horloge  
2.4. Contacts d'E/S  
2.5. États de la carte  
3. MATÉRIEL ET COMMUNICATION  
3.1. Introduction  
3.2. Protocole de transmission  
3.2.1 Protocoles  
3.2.2 ATR  
3.2.3 PTS  
3.3. Conditions d'accès  
3.4. Vue d'ensemble des commandes et des codes d'erreur  
3.5. Descriptions des commandes  
3.5.1 SELECT  
3.5.2 READ BINARY  
3.5.3 UPDATE BINARY  
3.5.4 GET CHALLENGE  
3.5.5 VERIFY  
3.5.6 GET RESPONSE  
3.5.7 PSO: VERIFY CERTIFICATE  
3.5.8 INTERNAL AUTHENTICATE  
3.5.9 EXTERNAL AUTHENTICATE  
3.5.10 GENERAL AUTHENTICATE  
3.5.11 MANAGE SECURITY ENVIRONMENT  
3.5.12 PSO: HASH  
3.5.13 PERFORM HASH OF FILE  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 186  
3.5.14 PSO: COMPUTE DIGITAL SIGNATURE  
3.5.15 PSO: VERIFY DIGITAL SIGNATURE  
3.5.16 PROCESS DSRC MESSAGE  
4. STRUCTURE DES CARTES TACHYGRAPHIQUES  
4.1. Fichier Maître (MF)  
4.2. Applications des cartes de conducteur  
4.2.1 Application de la carte de conducteur de génération 1  
4.2.2 Application de la carte de conducteur 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  
4.3.2 Application de la carte d'atelier 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  
4.4.2 Application de la carte de contrôle de génération 2  
4.5. Applications de la carte d'entreprise  
4.5.1 Application de la carte d'entreprise de génération 1  
4.5.2 Application de la carte d'entreprise de génération 2  
1. INTRODUCTION  
1.1. Abréviations  
Aux fins du présent appendice, les abréviations utilisées sont les 
suivantes.  
AC Conditions d'accès  
AES Norme de chiffrement avancé (Advanced Encryption 
Standard)  
AID Identifiant d'application  
ALW Toujours  
APDU Unité de données de protocole 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 conformément aux 
dispositions de la norme ISO/IEC 7816-2  
cc cycles d'horloge (clock cycles)  
▼M1 
CHA Autorisation d’un titulaire de certificat  
▼B 
CHV Informations de vérification de l'identité des titulaires  
CLA Octet de classe de commande APDU  
▼M1 
DO Objet de données  
▼B 
DSRC Communication spécialisée à courte 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  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 187  
G1 Génération 1  
G2 Génération 2  
IC Circuit intégré  
ICC Carte à circuit intégré  
ID Identificateur  
IFD Périphérique d'interface  
IFS Longueur de la zone d'information  
IFSC Longueur de la zone d'information pour la carte  
IFSD Périphérique de longueur de la zone d'information (pour 
le terminal)  
INS Octet d'instruction 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 protocole T = 1  
NEV Jamais  
P1-P2 Octets de paramètre  
PIN Numéro d'identification personnel  
PRO SM Protégé avec messagerie sécurisée  
PTS Sélection de transmission de protocole  
RFU Réservé à une utilisation ultérieure  
RST Réinitialisation (de la carte)  
SFID Identificateur court de l'EF  
SM Messagerie sécurisée  
SW1-SW2 Octets 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  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 188  
1.2. Références  
Les références suivantes sont utilisées dans le présent appendice:  
ISO/IEC 7816-2 Identification cards — Integrated circuit cards — 
Part 2: Dimensions and location of the contacts. 
ISO/IEC 7816-2:2007.  
ISO/IEC 7816-3 Identification cards — Integrated circuit cards — 
Part 3: Electrical interface and transmission proto ­
cols. ISO/IEC 7816-3:2006.  
ISO/IEC 7816-4 Identification cards — Integrated circuit cards — 
Part 4: Organization, security and commands for 
interchange. ISO/IEC 7816-4:2013 + Cor 1: 2014.  
ISO/IEC 7816-6 Identification cards — Integrated circuit cards — 
Part 6: Interindustry data elements for interchange. 
ISO/IEC 7816-6:2004 + Cor 1: 2006.  
ISO/IEC 7816-8 Identification cards — Integrated circuit cards — 
Part 8: Commands for security operations. ISO/IEC 
7816-8:2004.  
ISO/IEC 9797-2 Information technology — Security techniques — 
Message Authentication Codes (MACs) — Part 2: 
Mechanisms using a dedicated hash-function. 
ISO/IEC 9797-2:2011.  
2. CARACTERISTIQUES ELECTRIQUES ET PHYSIQUES  
TCS_01 Tous les signaux électriques doivent respecter la norme 
ISO/IEC 7816-3 sauf disposition contraire.  
TCS_02 L'emplacement et les dimensions des contacts de la carte 
doivent respecter la norme ISO/IEC 7816-2.  
2.1. Tension d'alimentation et consommation de courant  
TCS_03 La carte doit fonctionner selon les spécifications 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 programmation V  pp 
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 V  cc de la carte, il ne peut être raccordé à la 
masse. Cette tension ne doit donner lieu à aucune inter ­
prétation.  
2.3. Génération et fréquence d'horloge  
TCS_06 La carte doit fonctionner dans une plage de fréquences 
comprise entre 1 et 5 MHz ainsi qu'à des fréquences supé ­
rieures. 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 
coefficient d'utilisation peut varier entre 40 et 60 %.  
TCS_07 Il est possible d'interrompre 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 Clockstop:  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 189  
Inférieur  Supérieur  
Bit 3  Bit 2  Bit 1  
0 0  1  Clockstop autorisé, pas de niveau préférentiel  
0 1  1  Clockstop autorisé, avec une préférence pour le 
niveau supérieur  
1 0  1  Clockstop autorisé, avec une préférence pour le 
niveau inférieur  
0 0  0  Clockstop interdit  
0 1  0  Clockstop autorisé uniquement au niveau supé ­
rieur  
1 0  0  Clockstop autorisé uniquement au niveau inférieur  
Les bits 4 à 8 ne sont pas utilisés.  
2.4. Contacts d'E/S  
TCS_08 Le contact d'E/S C7 autorise la réception et l'émission de 
données en provenance comme à destination du IFD 
concerné. 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 courrait cependant 
aucun risque de détérioration. Sauf en émission, la carte 
passe systématiquement en mode réception.  
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çage avec une unité numérique;  
État de repos dans tous les autres cas de figure; dans cet 
état, la carte doit mémoriser toutes les données utiles.  
3. MATERIEL ET COMMUNICATION  
3.1. Introduction  
Les fonctions minimales requises par les cartes tachygraphiques et les 
VU pour garantir des conditions d'exploitation et d'interopérabilité 
satisfaisantes font l'objet d'une description détaillée dans le présent 
paragraphe.  
Les cartes tachygraphiques doivent être aussi conformes que possible 
aux normes ISO/IEC en vigueur (et à la norme ISO/IEC 7816 en 
particulier). Toutefois, les commandes et protocoles font l'objet 
d'une description détaillée afin de fournir, s'il y a lieu, quelques 
précisions sur certains usages restreints ou certaines différences éven ­
tuelles. Sauf indication contraire, les commandes spécifiées sont toutes 
conformes aux normes dont il est question.  
3.2. Protocole de transmission  
TCS_10 Le protocole de transmission doit être conforme à 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'attente 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 
protocoles 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 adopter le protocole  T=1 . ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 190  
TCS_13 Les périphériques doivent prendre en charge la  convention 
directe  que comportent ces deux protocoles. En consé ­
quence, la convention directe est obligatoire pour la carte.  
TCS_14 L'ATR doit présenter l'octet  Longueur de la zone d'infor ­
mation pour la carte  au niveau du caractère TA3. Valeur 
minimale: ‘F0h’ (= 240 octets).  
Les restrictions qui suivent s'appliquent aux protocoles:  
TCS_15  T=0  
— Le périphérique 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érique d'interface doit être à même de lire des 
caractères séparés par 12 etu.  
— Le périphérique d'interface doit être capable de recon ­
naî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 carac ­
tère erroné, le signal d'erreur peut se manifester à l'E/S 
dans un délai compris entre 1 et 2 etu. Le périphérique 
doit être en mesure de supporter un retard d'une etu.  
— Le périphérique d'interface doit accepter une ATR de 
33 octets (TS + 32).  
— Si l'ATR présente 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érique 
d'interface bien que les caractères transmis par la carte 
puissent encore être séparés par 12 etu. Cette disposi ­
tion s'applique également au caractère d'accusé de 
réception transmis par la carte après l'émission d'un 
caractère P3 par le périphérique d'interface.  
— Le périphérique d'interface doit prendre en compte un 
caractère NUL émis par la carte.  
— Le périphérique d'interface doit accepter le mode 
complémentaire pour accusé de réception.  
— La commande GET RESPONSE (obtenir une réponse) 
ne peut s'utiliser en mode chaînage pour obtenir des 
données dont la longueur pourrait excéder 255 octets.  
TCS_16  T = 1  
— Octet NAD: inutilisé (l'octet NAD doit être mis à ‘00’).  
— S-block ABORT: inutilisé.  
— S-block 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édiatement après l'ATR. 
L'IFD doit émettre la demande de S-Block IFS après 
l'ATR et la carte doit lui renvoyer le S-Block IFS. Il est 
recommandé d'accorder la valeur suivante à l'IFSD: 254 
octets.  
— La carte ne doit pas demander de réajustement de l'IFS.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 191  
3.2.2  ATR  
TCS_17 Le périphérique procède à un contrôle des octets ATR 
conformément à la norme ISO/IEC 7816-3. Les caractères 
historiques de l'ATR ne doivent être soumis à aucune véri ­
fication.  
Exemple de ATR biprotocole de base conforme à la norme 
ISO/IEC 7816-3  
▼C2 
Caractère  Valeur  Remarques  
TS «3Bh»  Indique une convention directe  
T0 «85h»  TD1 présent; présence de 5 octets historiques  
TD1 «80h»  TD2 présent; T = 0 à utiliser  
TD2 «11h»  TA3 présent; T = 1 à utiliser  
TA3 «XXh» («F0h» au 
moins)  Longueur de la zone d'information réservée à la carte 
(IFSC)  
TH1 à TH5  «XXh»  Caractères historiques  
TCK  «XXh»  Caractère de contrôle (OU exclusif)  
▼B 
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épertoire en cours.  
3.2.3  PTS  
TCS_19 Le protocole par défaut est le suivant: T = 0. Pour sélec ­
tionner le protocole T = 1, le périphérique doit envoyer à la 
carte un message de PTS (également désigné par l'abrévia ­
tion PPS).  
TCS_20 Tout comme les protocoles T = 0 et T = 1, la PTS de base 
autorisant la permutation des protocoles est également obli ­
gatoire pour la carte.  
La PTS s'utilise, conformément aux dispositions de la 
norme ISO/IEC 7816-3, pour passer à des débits binaires 
supérieurs à celui proposé par défaut, le cas échéant, par la 
carte au niveau de l'ATR [octet TA(1)].  
L'emploi de débits binaires supérieurs 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 
charge), la carte doit répondre correctement à la PTS en 
omettant l'octet PPS1, conformément à la norme ISO/IEC 
7816-3.  
Ci-après figure une série d'exemples de PTS de base 
destinés à la sélection de protocoles:  
▼C2 
Caractère  Valeur  Remarques  
PPSS  «FFh»  Caractère de lancement  
PPS0  «00h» ou «01h»  PPS1 à PPS3 sont absents; «00h» pour sélectionner T0, 
«01h» pour sélectionner T1.  
PK «XXh»  Caractère de contrôle: «XXh» = «FFh» si PPS0 = 
«00h», 
«XXh» = «FEh» si PPS0 = 
«01h».  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 192  
3.3. Conditions d'accès  
TCS_22 Les conditions d'accès définissent les conditions de sécurité 
correspondant à un mode d'accès (une commande). Les 
conditions d'accès doivent être satisfaites pour que la 
commande soit traitée.  
TCS_23 Les conditions d'accès applicables à la carte tachygraphique 
se définissent comme suit:  
Abréviation  Signification  
ALW  L'action toujours envisageable peut être exécutée sans restriction. La 
commande et sa réponse APDU sont envoyées en texte clair, sans messagerie 
sécurisée.  
NEV  L'action n'est jamais envisageable.  
PLAIN-C  La commande APDU est envoyée en texte clair, sans messagerie sécurisé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écurité interne de la carte «PIN_Verified» est défini. 
La commande doit être envoyée sans messagerie sécurisée.  
EXT-AUT-G1  L'action ne peut être exécutée que si la commande External Authenticate de 
l'authentification de génération 1 (cf. appendice 11 partie A) a réussi.  
SM-MAC-G1  L'APDU (commande et réponse) doit être effectuée avec la messagerie sécu ­
risée de génération 1 en mode authentification uniquement (cf. appendice 11 
partie A).  
SM-C-MAC-G1  L'APDU doit être effectuée avec la messagerie sécurisée de génération 1 en 
mode authentification uniquement (cf. appendice 11 partie A).  
SM-R-ENC-G1  La réponse APDU doit être effectuée avec la messagerie sécurisée de géné ­
ration 1 en mode chiffrement (cf. appendice 11 partie A), c'est-à-dire sans 
renvoi de code d'authentification de message.  
SM-R-ENC- 
MAC-G1  La réponse APDU doit être effectuée avec la messagerie sécurisée de géné ­
ration 1 en mode chiffrement puis authentification (cf. appendice 11 partie A).  
SM-MAC-G2  L'APDU (commande et réponse) doit être effectuée avec la messagerie sécu ­
risée de génération 2 en mode authentification uniquement (cf. appendice 11 
partie B).  
SM-C-MAC-G2  La commande APDU doit être effectuée avec la messagerie sécurisée de 
génération 2 en mode authentification uniquement (cf. appendice 11 partie B).  
SM-R-ENC- 
MAC-G2  La réponse APDU doit être effectuée avec la messagerie sécurisée de géné ­
ration 2 en mode chiffrement puis authentification (cf. appendice 11 partie B).  
▼M1 
TCS_24 Ces conditions de sécurité peuvent être liées selon les 
manières suivantes:  
ET: Toutes les conditions de sécurité doivent être remplies  
OU: Au moins l’une des conditions de sécurité doit être 
remplie  
Les conditions d’accès au système de fichiers, à savoir les 
commandes SELECT, READ BINARY et UPDATE 
BINARY sont spécifiées au chapitre 4. Les conditions 
d’accès des autres commandes sont spécifiées dans les 
tableaux suivants. Le terme «non applicable» est utilisé 
s’il n’est pas exigé de prendre en charge cette commande. 
Dans ce cas, la commande est ou n’est pas prise en charge, 
mais la condition d’accès est hors champ.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 193  
TCS_25 Dans l'application DF Tachograph G1, les conditions 
d'accès suivantes sont appliquées:  
▼M1 
Commande  Carte du 
conducteur  Carte atelier  Carte de 
contrôle  Carte d’entre ­
prise 
External Authenticate  
— Pour l’authentification de 
génération 1  ALW  ALW  ALW  ALW  
— Pour l’authentification de 
génération 2  ALW  PWD  ALW  ALW  
Internal Authenticate  ALW  PWD  ALW  ALW  
General Authenticate  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 DSRC Message  Sans objet  Sans objet  Sans objet  Sans objet  
PSO: Compute Digital Signature  ALW OU 
SM-MAC- 
G2 ALW OU 
SM-MAC- 
G2 Sans objet  Sans objet  
PSO: Hash  Sans objet  Sans objet  ALW  Sans objet  
PERFORM HASH of FILE  ALW OU 
SM-MAC- 
G2 ALW OU 
SM-MAC- 
G2 Sans objet  Sans objet  
PSO: Verify Certificate  ALW  ALW  ALW  ALW  
PSO: Verify Digital Signature  Sans objet  Sans objet  ALW  Sans objet  
Verify  Sans objet  ALW  Sans objet  Sans objet  
▼B 
TCS_26 Dans l'application DF Tachograph_G2, les conditions 
d'accès suivantes sont appliquées:  
▼M1 
Commande  Carte du 
conducteur  Carte atelier  Carte de 
contrôle  Carte d’entre ­
prise 
External Authenticate  
— Pour l’authentification de 
génération 1  Sans objet  Sans objet  Sans objet  Sans objet  
— Pour l’authentification de 
génération 2  ALW  PWD  ALW  ALW  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 194  
Commande  Carte du 
conducteur  Carte atelier  Carte de 
contrôle  Carte d’entre ­
prise 
Internal Authenticate  Sans objet  Sans objet  Sans objet  Sans objet  
General Authenticate  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 DSRC Message  Sans objet  ALW  ALW  Sans objet  
PSO: Compute Digital Signature  ALW OU 
SM-MAC- 
G2 ALW OU 
SM-MAC- 
G2 Sans objet  Sans objet  
PSO: Hash  Sans objet  Sans objet  ALW  Sans objet  
PERFORM HASH of FILE  ALW OU 
SM-MAC- 
G2 ALW OU 
SM-MAC- 
G2 Sans objet  Sans objet  
PSO: Verify Certificate  ALW  ALW  ALW  ALW  
PSO: Verify Digital Signature  Sans objet  Sans objet  ALW  Sans objet  
Verify  Sans objet  ALW  Sans objet  Sans objet  
▼B 
TCS_27 Dans le MF, les conditions d'accès suivantes sont appli ­
quées:  
▼M1 
Commande  Carte du 
conducteur  Carte atelier  Carte de 
contrôle  Carte d’entre ­
prise 
External Authenticate  
— Pour l'authentification de 
génération 1  Sans objet  Sans objet  Sans objet  Sans objet  
— Pour l'authentification de 
génération 2  ALW  PWD  ALW  ALW  
Internal Authenticate  Sans objet  Sans objet  Sans objet  Sans objet  
General Authenticate  ALW  ALW  ALW  ALW  
Get Challenge  ALW  ALW  ALW  ALW  
MSE:SET AT  ALW  ALW  ALW  ALW  
MSE:SET DST  ALW  ALW  ALW  ALW  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 195  
Commande  Carte du 
conducteur  Carte atelier  Carte de 
contrôle  Carte d’entre ­
prise 
Process DSRC Message  Sans objet  Sans objet  Sans objet  Sans objet  
PSO: Compute Digital Signature  Sans objet  Sans objet  Sans objet  Sans objet  
PSO: Hash  Sans objet  Sans objet  Sans objet  Sans objet  
PERFORM HASH of FILE  Sans objet  Sans objet  Sans objet  Sans objet  
PSO: Verify Certificate  ALW  ALW  ALW  ALW  
PSO: Verify Digital Signature  Sans objet  Sans objet  Sans objet  Sans objet  
Verify  Sans objet  ALW  Sans objet  Sans objet  
▼B 
TCS_28 Une carte tachygraphique peut accepter ou non une 
commande avec un niveau de sécurité supérieur à celui 
spécifié dans les conditions de sécurité. Par exemple, si 
la condition de sécurité est ALW (ou PLAIN-C), la carte 
peut accepter une commande avec messagerie sécurisée 
(mode chiffrement et/ou authentification). Si la condition 
de sécurité exige la messagerie sécurisée avec le mode 
d'authentification, la carte tachygraphique peut accepter 
une commande avec messagerie sécurisée de même géné ­
ration en mode chiffrement et authentification.  
Remarque:  les descriptions de commande fournissent des 
informations complémentaires sur leur prise en charge pour 
les différents types de cartes tachygraphiques et les divers 
DF. 
3.4. Vue d'ensemble des commandes et des codes d'erreur  
Les commandes et la structure des fichiers découlent de la norme 
ISO/IEC 7816-4 et sont conformes à ses dispositions.  
Cette section décrit 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 descriptions de commande 
correspondantes.  
Commande  INS  
SELECT  ‘A4h’  
READ BINARY  ‘B0h’, ‘B1h’  
UPDATE BINARY  ‘D6h’, ‘D7h’  
GET CHALLENGE  ‘84h’  
VERIFY  ‘20h’  
GET RESPONSE  ‘C0h’  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 196  
Commande  INS  
PERFORM SECURITY OPERA ­
TION  ‘2Ah’  
— VERIFY CERTIFICATE  
— COMPUTE DIGITAL SIGNA ­
TURE  
— VERIFY DIGITAL SIGNA ­
TURE  
— HASH  
— PERFORM HASH OF FILE  
— PROCESS DSRC MESSAGE  
INTERNAL AUTHENTICATE  ‘88h’  
EXTERNAL AUTHENTICATE  ‘82h’  
MANAGE SECURITY ENVIRON ­
MENT  ‘22h’  
— SET DIGITAL SIGNATURE 
TEMPLATE  
— SET AUTHENTICATION 
TEMPLATE  
GENERAL AUTHENTICATE  ‘86h’  
▼M1 
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  Traitement normal.  
61 XX  Traitement normal. XX = nombre d’octets de réponse disponi ­
bles. 
62 81  Traitement d’avertissement. Une partie des données renvoyées 
peut être corrompue  
63 00  Échec de l’authentification (Avertissement)  
63 CX  CHV erronées (PIN). Compteur de tentatives restantes assuré par 
«X» 
64 00  Erreur d’exécution - État de la mémoire rémanente inchangé. 
Erreur d’intégrité  
65 00  Erreur d’exécution - État de la mémoire rémanente modifié.  
65 81  Erreur d’exécution - État de la mémoire rémanente modifié - 
Défaillance de la mémoire.  
66 88  Erreur de sécurité: Total de contrôle cryptographique erroné (en 
cours de messagerie sécurisée) ou 
Certificat erroné (pendant la vérification du 
certificat) ou 
Cryptogramme erroné (pendant l’authentifi ­
cation externe) ou 
Signature erronée (pendant la vérification de 
la signature)  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 197  
SW1  SW2  Signification  
67 00  Longueur erronée (Lc ou Le erronée)  
68 83  Dernière commande de la chaîne prévisible  
69 00  Commande interdite (pas de réponse disponible en T=0)  
69 82  État de sécurité non satisfait  
69 83  Méthode d’authentification bloquée  
69 85  Conditions d’utilisation non satisfaites  
69 86  Commande non autorisée (pas d’EF actif)  
69 87  Absence des objets informatifs SM prévus  
69 88  Objets informatifs SM incorrects  
6A 80  Paramètres incorrects 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 données n’est renvoyée.  
6D 00  Code d’instruction non pris en charge ou incorrect  
6E 00  Classe non prise en charge  
6F 00  — Autres erreurs de contrôle  
Les mots d’état supplémentaires au sens de la norme 
ISO/IEC 7816-4 peuvent être renvoyés si leur comporte ­
ment n’est pas explicitement mentionné dans le présent 
appendice.  
Par exemple, les mots d’état suivants peuvent éventuelle ­
ment être renvoyés:  
6881: Canal logique non pris en charge  
6882: Messagerie sécurisée non prise en charge  
▼B 
TCS_30 Si plusieurs conditions d'erreurs sont satisfaites dans une 
commande APDU, la carte peut renvoyer l'un ou l'autre des 
mots d'état appropriés.  
3.5. Descriptions des commandes  
Le présent chapitre décrit les commandes obligatoires pour les cartes 
tachygraphiques.  
L'appendice 11 (Mécanismes de sécurité communs pour les tachy ­
graphes de génération 1 et 2) constitue une source d'informations 
pertinentes concernant les opérations cryptographiques en jeu.  
Toutes les commandes sont décrites indépendamment du protocole 
employé (T=0 ou T=1). Les octets APDU CLA, INS, P1, P2, Lc et 
Le sont toujours indiqués. Si la commande décrite peut se passer de 
l'octet Lc ou Le, les cellules longueur, valeur et description associées 
à celui-ci demeurent vides.  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 198  
TCS_31 Si la présence des deux octets de longueur (Lc et Le) est 
requise, la commande décrite doit être scindée en deux 
parties si l'IFD emploie le protocole T = 0: l'IFD envoie 
la commande décrite 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 (messagerie sécurisée):  
— En cas d'utilisation du protocole T = 1, la carte doit 
répondre à Le = 0 en envoyant toutes les données de 
sortie disponibles.  
— En cas d'utilisation du protocole 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 tachygraphique peut prendre en charge des zones 
de longueur étendue conformément à la norme ISO/IEC 
7816-4, de manière facultative. Une carte tachygraphique 
prenant en charge des zones de longueur étendue doit:  
— indiquer la prise en charge de la zone de longueur 
étendue dans l'ATR;  
— prévoir les tailles de tampon pris en charge au moyen 
d'informations de longueur étendue dans l'EF ATR/ 
INFO cf. TCS_146;  
— indiquer si elle prend en charge les zones de longueur 
étendue pour T = 1 et/ou T = 0 dans l'EF Extended 
Length, cf. TCS_147.  
— prendre en charge les zones de longueur étendue pour 
les générations 1 et 2 d'application tachygraphique.  
Remarques:  
Toutes les commandes sont spécifiées pour les zones de 
longueur courte. 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 messagerie sécurisée, car la 
couche de messagerie sécurisée est spécifiée en appendice 
11. Les conditions d'accès à une commande indiquent clai ­
rement si la commande prend ou non en charge la messa ­
gerie sécurisée et si la commande prend ou non en charge 
la messagerie sécurisée de génération 1 et/ou 2. Certaines 
variantes de commandes sont décrites avec la messagerie 
sécurisée afin d'illustrer l'utilisation de cette dernière.  
TCS_34 La VU doit prendre en charge la totalité de la génération 2 
de VU: protocole d'authentification mutuelle de la carte 
pour une session comprenant la vérification du certificat 
(le cas échéant) soit dans le DF Tachograph, soit dans le 
DF Tachograph_G2, soit dans le MF.  
3.5.1  SELECT  
Cette commande est conforme à la norme ISO/IEC 7816-4, mais elle 
se caractérise par un usage restreint en comparaison avec la 
commande analogue définie dans cette norme.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 199  
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 é l e c t i o n p a r n o m ( A I D )  
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'environnement 
de sécurité actif. Après avoir procédé à la sélection de 
l'application, aucune clé publique active n'est plus sélec ­
tionnée. La condition d'accès EXT-AUT-G1 est également 
perdue. Si la commande a été exécutée sans messagerie 
sécurisée, les clés de la session de messagerie sécurisée 
précédente sont perdues.  
TCS_37  Message de commande  
Octet  Longueur  Valeur  Description  
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 tachygraphique  
#6-#(5+NN)  NN  ‘XX..XXh’  AID: ‘FF 54 41 43 48 4F’ pour l'application tachygra ­
phique de génération 1 
AID: ‘FF 53 4D 52 44 54’ pour l'application tachygra ­
phique 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).  
TCS_38  Message de réponse (pas de réponse requise)  
Octet  Longueur  Valeur  Description  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
— Si la commande aboutit, la carte renvoie l'état ‘ 9000 ’. 
— Si le logiciel ne parvient pas à trouver l'application 
correspondant à l'AID, il renvoie l'état de traitement 
‘6A82 ’. 
— En T = 1, la présence de l'octet Le entraîne le renvoi de 
l'état ‘ 6700 ’. 
— En T = 0, l'exigence d'une réponse après réception de la 
commande SELECT entraîne le renvoi de l'état ‘ 6900 ’. 
▼M1 
— Si l’application sélectionnée est considérée comme 
altérée (une erreur d’intégrité est détectée dans les attri ­
buts du fichier), le logiciel renvoie l’état de traitement 
‘6400 ’ ou ‘ 6500 ’. ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 200  
3.5.1.2 S é l e c t i o n d ' u n f i c h i e r é l é m e n t a i r e a u m o y e n d e 
s o n i d e n t i f i c a t e u r d e f i c h i e r  
TCS_39  Message de commande  
TCS_40 Une carte tachygraphique doit prendre en charge la géné ­
ration 2 de messagerie sécurisée comme le précise l'appen ­
dice 11 partie B pour cette variante de commande.  
Octet  Longueur  Valeur  Description  
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’  Identificateur 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  Description  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
— Si la commande aboutit, la carte renvoie l'état ‘ 9000 ’. 
— Si le logiciel ne parvient pas à trouver le fichier corres ­
pondant à l'identificateur de fichier, il renvoie l'état de 
traitement ‘ 6A82 ’. 
— En T = 1, la présence de l'octet Le entraîne le renvoi de 
l'état ‘ 6700 ’. 
— En T = 0, l'exigence d'une réponse après réception de la 
commande SELECT entraîne le renvoi de l'état ‘ 6900 ’. 
▼M1 
— 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 renvoie l’état de traitement ‘ 6400 ’ 
ou ‘6500 ’. 
▼B 
3.5.2  READ BINARY  
Cette commande est conforme à la norme ISO/IEC 7816-4, mais elle 
se caractérise par un usage restreint en comparaison avec la 
commande analogue définie dans cette norme.  
La commande READ BINARY permet d'extraire les données enregis ­
trées dans un fichier transparent.  
La réponse de la carte consiste à renvoyer les données extraites, en les 
intégrant, le cas échéant, dans une structure de messagerie sécurisée.  
3.5.2.1 C o m m a n d e a v e c d é p l a c e m e n t P 1 - P 2 .  
Cette commande permet à l'IFD de lire les données de l'EF sélec ­
tionné sans messagerie sécurisée.  
Remarque:  cette commande sans messagerie sécurisée ne peut servir 
qu'à lire un fichier prenant en charge la condition de sécurité ALW en 
mode Read Access.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 201  
TCS_42  Message de commande  
Octet  Longueur  Valeur  Description  
CLA  1  ‘00h’  
INS 1  ‘B0h’  Read Binary  
P1 1  ‘XXh’  Déplacement en octets à compter du début du fichier: 
octet le plus significatif  
P2 1  ‘XXh’  Déplacement en octets à compter du début du fichier: 
octet le moins significatif  
Le 1  ‘XXh’  Longueur des données attendue. Nombre d'octets à 
extraire.  
Remarque:  le bit 8 de P1 doit être mis à 0.  
TCS_43  Message de réponse  
Octet  Longueur  Valeur  Description  
#1-#X  X  ‘XX..XXh’  Données lues  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
— Si la commande aboutit, la carte renvoie l'état ‘ 9000 ’. 
— Si aucun EF n'est sélectionné, le logiciel renvoie l'état 
de traitement ‘ 6986 ’. 
— Si les conditions de sécurité du fichier sélectionné ne 
sont pas remplies, la commande est interrompue par 
‘6982 ’. 
— Si le déplacement n'est pas compatible avec la taille de 
l'EF (déplacement > taille de l'EF), le logiciel renvoie 
l'état de traitement ‘ 6B00 ’. 
— Si la taille des données à lire n'est pas compatible avec 
la taille de l'EF (déplacement + Le > taille de l'EF), le 
logiciel renvoie l'état de traitement ‘ 6700 ’ ou ‘ 6Cxx ’, 
où ‘xx’ indique la longueur exacte.  
▼M1 
— 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 renvoie 
l’état de traitement ‘ 6400 ’ ou ‘ 6500 ’. 
▼B 
— Si une erreur d'intégrité est détectée dans les données 
stockées, la carte renvoie les données demandées et le 
logiciel renvoie l'état de traitement ‘ 6281 ’. 
3.5.2.1.1 C o m m a n d e a v e c m e s s a g e r i e s é c u r i s é e ( e x e m p l e s )  
Cette commande permet à l'IFD d'extraire les données de l'EF sélec ­
tionné avec messagerie sécurisée afin de vérifier l'intégrité des 
données reçues et de protéger la confidentialité des données si la 
condition de sécurité SM-R-ENC-MAC-G1 (génération 1) ou SM-R- 
ENC-MAC-G2 (génération 2) est exigée.  
TCS_44  Message de commande  
Octet  Longueur  Valeur  Description  
CLA  1  ‘0Ch’  Messagerie sécurisée demandée  
INS 1  ‘B0h’  Read Binary  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 202  
Octet  Longueur  Valeur  Description  
P1 1  ‘XXh’  P1 (déplacement en octets à compter du début du 
fichier): octet le plus significatif  
P2 1  ‘XXh’  P2 (déplacement en octets à compter du début du 
fichier): octet le moins significatif  
Lc 1  ‘XXh’  Longueur des données d'entrée pour la messagerie sécu ­
risée  
#6 1  ‘97h’  T  LE: balise de spécification de longueur attendue  
#7 1  ‘01h’  L  LE : longueur de longueur attendue  
#8 1  ‘NNh’  Spécification de longueur attendue (Le original): nombre 
d'octets à lire  
#9 1  ‘8Eh’  T  CC : balise indiquant le total de contrôle cryptographi ­
que 
#10 1  ‘XXh’  L  CC : longueur du total de contrôle cryptographique 
suivant 
‘04h’ pour la messagerie sécurisée de génération 1 (cf. 
appendice 11 partie A) 
‘08h’, ‘0Ch’ ou ‘10h’ selon la longueur de clé AES 
pour la messagerie sécurisée de génération 2 (cf. appen ­
dice 11 partie B)  
#11-#(10+L)  L  ‘XX..XXh’  Total de contrôle cryptographique  
Le 1  ‘00h’  Conformément à la norme ISO/IEC 7816-4  
TCS_45  Message de réponse si SM-R-ENC-MAC-G1 (génération 
1) / SM-R-ENC-MAC-G2 (génération 2) n'est pas requis 
et si le format d'entrée de la messagerie sécurisée est 
correct:  
▼M1 
Octet  Lon- 
gueur  Valeur  Description  
#1 1  ‘81h’  T  PV : balise indiquant la valeur des données 
ordinaires  
#2 L  ‘NNh’ ou 
‘81 NNh’  L PV : longueur des données renvoyées (=Le 
original). 
L équivaut à 2 octets si L  PV > 127 octets.  
#(2+L) - #(1+L+NN)  NN  ‘XX..XXh’  Valeur des données ordinaires  
#(2+L+NN)  1  ‘99h’  Balise d’état de traitement (SW1-SW2) - 
facultatif pour la messagerie sécurisée de 
génération 1  
#(3+L+NN)  1  ‘02h’  Longueur de l’état de traitement – facultatif 
pour la messagerie sécurisée de génération 1  
#(4+L+NN) - #(5+L+NN)  2  ‘XX XXh’  État de traitement de l’APDU de réponse 
non protégée - facultatif pour la messagerie 
sécurisée de génération 1  
#(6+L+NN)  1  ‘8Eh’  TCC: balise indiquant le total de contrôle 
cryptographique  
#(7+L+NN)  1  ‘XXh’  LCC: longueur du total de contrôle crypto ­
graphique suivant 
‘04h’ pour la messagerie sécurisée de géné ­
ration 1 (cf. appendice 11, partie A) 
‘08h’, ‘0Ch’ ou ‘10h’ selon la longueur de 
clé AES pour la messagerie sécurisée de 
génération 2 (cf. appendice 11, partie B)  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 203  
Octet  Lon- 
gueur  Valeur  Description  
#(8+L+NN)-#(7+M+L+NN)  M  ‘XX..XXh’  Total de contrôle cryptographique  
SW 2  ‘XXXXh’  Mots d’état (SW1, SW2)  
▼B 
TCS_46  Message de réponse si SM-R-ENC-MAC-G1 (génération 
1) / SM-R-ENC-MAC-G2 (génération 2) est requis et si 
le format d'entrée de la messagerie sécurisée est correct:  
▼M1 
Octet  Lon- 
gueur  Valeur  Description  
#1 1  ‘87h’  T  PI CG  : balise indiquant des données codées 
(cryptogramme)  
#2 L  ‘MMh’ ou 
‘81 MMh’  L PI CG  : longueur des données chiffrées 
renvoyées (différentes du Le original de la 
commande en raison du remplissage). 
L équivaut à 2 octets si LPI CG > 127 octets  
#(2+L)-#(1+L+MM)  MM  ‘01XX..XXh’  Données codées: cryptogramme et indicateur 
de remplissage  
#(2+L+MM)  1  ‘99h’  Balise d’état de traitement (SW1-SW2) – 
facultatif pour la messagerie sécurisée de 
génération 1  
#(3+L+MM)  1  ‘02h’  Longueur de l’état de traitement - facultatif 
pour la messagerie sécurisée de génération 1  
#(4+L+MM) - #(5+L+MM)  2  ‘XX XXh’  État de traitement de l’APDU de réponse 
non protégée – facultatif pour la messagerie 
sécurisée de génération 1  
#(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 messagerie sécurisée de géné ­
ration 1 (cf. appendice 11, partie A) 
‘08h’, ‘0Ch’ ou ‘10h’ selon la longueur de 
clé AES pour la messagerie sécurisé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)  
▼B 
Il se peut que la commande READ BINARY renvoie des 
états de traitement normaux listés en TCS_43 sous la balise 
‘99h’ comme décrit en TCS_59 en adoptant la structure de 
réponse de la messagerie sécurisée.  
Par ailleurs, certaines erreurs propres à la messagerie sécu ­
risée sont susceptibles de se manifester. Dans ce cas, le 
logiciel se contente de renvoyer l'état de traitement 
concerné sans impliquer aucune structure de messagerie 
sécurisée:  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 204  
TCS_47  Message de réponse si le format d'entrée de la messa ­
gerie sécurisée est incorrect  
Octet  Longueur  Valeur  Description  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
— Si aucune clé de session active n'est disponible, le logi ­
ciel renvoie 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écuter le processus d'authentification 
mutuel approprié 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 messagerie 
sécurisée, le logiciel renvoie l'état de traitement 
‘6987 ’: cette erreur se produit si une balise attendue 
manque ou si le corps de la commande n'est pas correc ­
tement construit.  
— Si certains objets informatifs sont incorrects, le logiciel 
renvoie l'état de traitement ‘ 6988 ’: cette erreur se 
produit si toutes 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 renvoie l'état de traitement ‘ 6688 ’. 
3.5.2.2 C o m m a n d e a v e c u n i d e n t i f i c a t e u r E F c o u r t  
Cette variante de commande permet à l'IFD de sélectionner un EF à 
l'aide d'un identificateur EF court et de lire des données à partir de cet 
EF. 
TCS_48 Une carte tachygraphique doit prendre en charge cette 
variante de commande pour tous les fichiers élémentaires 
dotés d'un identificateur d'EF court donné. Ces identifica ­
teurs EF courts figurent au chapitre 4.  
TCS_49  Message de commande  
Octet  Longueur  Valeur  Description  
CLA  1  ‘00h’  
INS 1  ‘B0h’  Read Binary  
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 court de l'EF 
correspondant  
P2 1  ‘XXh’  Code un déplacement de 0 à 255 octets dans l'EF réfé ­
rencé par P1  
Le 1  ‘XXh’  Longueur des données attendue. Nombre d'octets à 
extraire.  
Remarque:  les identificateurs EF courts servant à l'applica ­
tion tachygraphique de génération 2 figurent au chapitre 4.  
Si P1 code un identificateur EF court et que la commande 
réussit, l'EF identifié devient l'EF sélectionné (EF actif).  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 205  
TCS_50  Message de réponse  
Octet  Longueur  Valeur  Description  
#1-#L  L  ‘XX..XXh’  Données lues  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
— Si la commande aboutit, la carte renvoie l'état ‘ 9000 ’. 
— Si le logiciel ne parvient pas à trouver le fichier corres ­
pondant à l'identificateur EF court, il renvoie l'état de 
traitement  ‘6A82’ . 
— Si les conditions de sécurité du fichier sélectionné ne 
sont pas remplies, la commande est interrompue par 
‘6982 ’. 
— Si le déplacement n'est pas compatible avec la taille de 
l'EF (déplacement > taille de l'EF), le logiciel renvoie 
l'état de traitement ‘ 6B00 ’. 
— Si la taille des données à lire n'est pas compatible avec 
la taille de l'EF (déplacement + Le > taille de l'EF), le 
logiciel renvoie l'état de traitement ‘ 6700 ’ ou ‘ 6Cxx ’, 
où ‘xx’ indique la longueur exacte.  
▼M1 
— 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 renvoie 
l’état de traitement ‘ 6400 ’ ou ‘ 6500 ’. 
▼B 
— Si une erreur d'intégrité est détectée dans les données 
stockées, la carte renvoie les données demandées et le 
logiciel renvoie l'état de traitement ‘ 6281 ’. 
3.5.2.3 C o m m a n d e a v e c o c t e t d ' i n s t r u c t i o n i m p a i r  
Cette variante de commande permet à l'IFD d'extraire des données 
d'un EF contenant 32 768 octets ou davantage.  
TCS_51 Une carte tachygraphique prenant en charge les EF dotés de 
32 768 octets ou davantage doit prendre en charge cette 
variante de commande concernant les EF. Une carte tachy ­
graphique 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  Description  
CLA  1  ‘00h’  
INS 1  ‘B1h’  Read Binary  
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  
▼M1 
Le 1  ‘XXh’  Conformément à la norme ISO/IEC 7816-4  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 206  
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'octet de longueur ‘02h’, un déplacement 
de ‘256’ jusqu'à ‘65 535’ octets.  
▼M1 
Si T=0, la carte suppose la valeur Le = ‘00h’ si aucune 
messagerie sécurisée n’est appliquée.  
Si T=1, l’état de traitement renvoyé est ‘6700’ si Le=‘01h’.  
▼B 
TCS_53  Message de réponse  
Octet  Longueur  Valeur  Description  
#1-#L  L  ‘XX..XXh’  Les données extraites sont intégrées dans un objet infor ­
matif discrétionnaire avec une balise ‘53h’.  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
— Si la commande aboutit, la carte renvoie l'état ‘ 9000 ’. 
— Si aucun EF n'est sélectionné, le logiciel renvoie l'état 
de traitement ‘ 6986 ’. 
— Si les conditions de sécurité du fichier sélectionné ne 
sont pas remplies, la commande est interrompue par 
‘6982 ’. 
— Si le déplacement n'est pas compatible avec la taille de 
l'EF (déplacement > taille de l'EF), le logiciel renvoie 
l'état de traitement ‘ 6B00 ’. 
— Si le volume des données à extraire n'est pas compa ­
tible avec la taille de l'EF (déplacement + Le > taille de 
l'EF) le logiciel renvoie l'état de traitement suivant: 
‘6700 ’ ou ‘ 6Cxx ’ où ‘xx’ indique la longueur exacte.  
▼M1 
— 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 renvoie 
l’état de traitement ‘ 6400 ’ ou ‘ 6500 ’. 
▼B 
— Si une erreur d'intégrité est détectée dans les données 
stockées, la carte renvoie les données demandées et le 
logiciel renvoie l'état de traitement ‘ 6281 ’. 
3.5.2.3.1 C o m m a n d e a v e c m e s s a g e r i e s é c u r i s é e ( e x e m p l e )  
L'exemple suivant illustre l'utilisation de la messagerie sécurisée si la 
condition de sécurité SM-MAC-G2 s'applique.  
TCS_54 Message de commande  
Octet  Longueur  Valeur  Description  
CLA  1  ‘0Ch’  Messagerie sécurisée demandée  
INS 1  ‘B1h’  Read Binary  
P1 1  ‘00h’  EF actif  
P2 1  ‘00h’  
Lc 1  ‘XXh’  Longueur de la zone de données sécurisée  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 207  
Octet  Longueur  Valeur  Description  
#6 1  ‘B3h’  Balise indiquant la valeur des données ordinaires codées 
dans BER-TLV  
#7 1  ‘NNh’  L  PV : 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’  T  LE : balise de spécification de longueur attendue  
#(9+NN)  1  ‘01h’  L  LE : longueur de longueur attendue  
#(10+NN)  1  ‘XXh’  Spécification de longueur prévisible (Le original): 
nombre d'octets à extraire  
#(11+NN)  1  ‘8Eh’  T  CC : balise indiquant le total de contrôle cryptographi ­
que 
#(12+NN)  1  ‘XXh’  L  CC : longueur du total de contrôle cryptographique 
suivant 
‘08h’, ‘0Ch’ ou ‘10h’ selon la longueur de clé AES 
pour la messagerie sécurisée de génération 2 (cf. appen ­
dice 11 partie B)  
#(13+NN)- 
#(12+M+NN)  M ‘XX..XXh’  Total de contrôle cryptographique  
Le 1  ‘00h’  Conformément à la norme ISO/IEC 7816-4  
TCS_55 Message de réponse si la commande réussit  
Octet  Longueur  Valeur  Description  
#1 1  ‘B3h’  Données ordinaires codées dans BER-TLV  
#2 L  ‘NNh’ ou 
‘81 NNh’  L PV : longueur des données renvoyées (=Le original). 
L équivaut à 2 octets si L  PV > 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 extraites 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’  T  CC : balise indiquant le total de contrôle cryptographi ­
que 
#(7+L+NN)  1  ‘XXh’  L  CC : longueur du total de contrôle cryptographique 
suivant 
‘08h’, ‘0Ch’ ou ‘10h’ selon la longueur de clé AES 
pour la messagerie sécurisée de génération 2 (cf. appen ­
dice 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  UPDATE BINARY  
Cette commande est conforme à la norme ISO/IEC 7816-4, mais elle 
se caractérise par un usage restreint en comparaison avec la 
commande analogue définie dans cette norme.  
Le message de commande UPDATE BINARY lance l'actualisation 
(effacement + enregistrement) des bits déjà présents dans un EF 
avec les bits que recèle la commande APDU.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 208  
3.5.3.1 C o m m a n d e a v e c d é p l a c e m e n t P 1 - P 2 .  
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 messagerie sécurisée ne peut servir 
qu'à actualiser un fichier prenant en charge la condition de sécurité 
ALW en mode Update Access.  
TCS_56  Message de commande  
Octet  Longueur  Valeur  Description  
CLA  1  ‘00h’  
INS 1  ‘D6h’  Update Binary  
P1 1  ‘XXh’  Déplacement en octets à compter du début du fichier: 
octet le plus significatif  
P2 1  ‘XXh’  Déplacement en octets à compter du début du fichier: 
octet le moins significatif  
Lc 1  ‘NNh’  Longueur Lc des données à actualiser. Nombre d'octets 
à enregistrer.  
#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  Description  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
— Si la commande aboutit, la carte renvoie l'état ‘ 9000 ’. 
— Si aucun EF n'est sélectionné, le logiciel renvoie l'état 
de traitement ‘ 6986 ’. 
— Si les conditions de sécurité du fichier sélectionné ne 
sont pas remplies, la commande est interrompue par 
‘6982 ’. 
— Si le déplacement n'est pas compatible avec la taille de 
l'EF (déplacement > taille de l'EF), le logiciel renvoie 
l'état de traitement ‘ 6B00 ’. 
— Si le volume des données à enregistrer est n'est pas 
compatible avec la taille de l'EF (déplacement + Le > 
taille de l'EF), le logiciel renvoie l'état de traitement 
‘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 renvoie 
l'état de traitement  ‘6400’  ou ‘6500’ . 
— Si l'enregistrement est impossible, le logiciel renvoie 
l'état de traitement  ‘6581’ . 
3.5.3.1.1 C o m m a n d e a v e c m e s s a g e r i e s é c u r i s é e ( e x e m p l e s )  
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 confidentialité n'étant requise, les données ne sont pas codées.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 209  
TCS_58  Message de commande  
Octet  Longueur  Valeur  Description  
CLA  1  ‘0Ch’  Messagerie sécurisée demandée  
INS 1  ‘D6h’  Update Binary  
P1 1  ‘XXh’  Déplacement en octets à compter du début du fichier: 
octet le plus significatif  
P2 1  ‘XXh’  Déplacement en octets à compter du début du fichier: 
octet le moins significatif  
Lc 1  ‘XXh’  Longueur de la zone de données sécurisée  
#6 1  ‘81h’  T  PV : balise indiquant la valeur des données ordinaires  
#7 L  ‘NNh’ ou 
‘81 NNh’  L PV : longueur des données transmises 
L équivaut à 2 octets si L  PV > 127 octets  
#(7+L)- 
#(6+L+NN)  NN ‘XX..XXh’  Valeur des données ordinaires (données à enregistrer)  
#(7+L+NN)  1  ‘8Eh’  T  CC : balise indiquant le total de contrôle cryptographi ­
que 
#(8+L+NN)  1  ‘XXh’  L  CC : longueur du total de contrôle cryptographique 
suivant ‘04h’ pour la messagerie sécurisée de généra ­
tion 1 (cf. appendice 11 partie A) 
‘08h’, ‘0Ch’ ou ‘10h’ selon la longueur de clé AES 
pour la messagerie sécurisée de génération 2 (cf. appen ­
dice 11 partie B)  
#(9+L+NN)- 
#(8+M+L+ 
NN) M ‘XX..XXh’  Total de contrôle cryptographique  
Le 1  ‘00h’  Conformément à la norme ISO/IEC 7816-4  
TCS_59  Message de réponse si le format d'entrée de la messa ­
gerie sécurisée est correct  
Octet  Longueur  Valeur  Description  
#1 1  ‘99h’  T  SW : balise indiquant des mots d'état (à protéger par 
CC) 
#2 1  ‘02h’  L  SW : longueur des mots d'état renvoyés  
#3-#4  2  ‘XXXXh’  État de traitement de l'APDU de réponse non protégée  
#5 1  ‘8Eh’  T  CC : balise indiquant le total de contrôle cryptographi ­
que 
#6 1  ‘XXh’  L  CC : longueur du total de contrôle cryptographique 
suivant 
‘04h’ pour la messagerie sécurisée de génération 1 (cf. 
appendice 11 partie A) 
‘08h’, ‘0Ch’ ou ‘10h’ selon la longueur de clé AES 
pour la messagerie sécurisée de génération 2 (cf. appen ­
dice 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écrite plus haut 
permet de renvoyer les états de traitement «normaux» 
précisés pour la commande UPDATE BINARY sans 
messagerie sécurisée (cf. par. 3.5.3.1).  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 210  
Par ailleurs, certaines erreurs propres à la messagerie sécu ­
risée sont susceptibles de se produire. Dans ce cas, le logi ­
ciel se contente de renvoyer l'état de traitement concerné 
sans impliquer aucune structure de messagerie sécurisée:  
TCS_60  Message de réponse en cas d'erreur affectant la messa ­
gerie sécurisée  
Octet  Longueur  Valeur  Description  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
— Si aucune clé de session active n'est disponible, le logi ­
ciel renvoie l'état de traitement  ‘6A88’ . 
— Si certains objets informatifs attendus (comme précisé 
ci-avant) font défaut dans la structure de messagerie 
sécurisée, le logiciel renvoie l'état de traitement 
‘6987 ’: cette erreur se produit si une balise attendue 
manque ou si le corps de la commande n'est pas correc ­
tement construit.  
— Si certains objets informatifs sont incorrects, le logiciel 
renvoie l'état de traitement ‘ 6988 ’: cette erreur se 
produit si toutes 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 renvoie l'état de traitement ‘ 6688 ’. 
3.5.3.2 C o m m a n d e a v e c u n i d e n t i f i c a t e u r E F c o u r t  
Cette variante de commande permet à l'IFD de sélectionner un EF à 
l'aide d'un identificateur EF court et d'enregistrer des données à partir 
de cet EF.  
TCS_61 Une carte tachygraphique doit prendre en charge cette 
variante de commande pour tous les fichiers élémentaires 
dotés d'un identificateur d'EF court donné. Ces identifica ­
teurs EF courts figurent au chapitre 4.  
TCS_62  Message de commande  
Octet  Longueur  Valeur  Description  
CLA  1  ‘00h’  
INS 1  ‘D6h’  Update Binary  
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 court de l'EF 
correspondant  
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'octets 
à enregistrer.  
#6-#(5+NN)  NN  ‘XX..XXh’  Données à enregistrer  
TCS_63  Message de réponse  
Octet  Longueur  Valeur  Description  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
Remarque:  les identificateurs EF courts servant à l'applica ­
tion tachygraphique de génération 2 figurent au chapitre 4.  
Si P1 code un identificateur EF court et que la commande 
réussit, l'EF identifié devient l'EF sélectionné (EF actif).  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 211  
— Si la commande aboutit, la carte renvoie l'état ‘ 9000 ’. 
— Si le logiciel ne parvient pas à trouver le fichier corres ­
pondant à l'identificateur EF court, il renvoie l'état de 
traitement  ‘6A82’ . 
— Si les conditions de sécurité du fichier sélectionné ne 
sont pas remplies, la commande est interrompue par 
‘6982 ’. 
— Si le déplacement n'est pas compatible avec la taille de 
l'EF (déplacement > taille de l'EF), le logiciel renvoie 
l'état de traitement ‘ 6B00 ’. 
— Si le volume des données à enregistrer est n'est pas 
compatible avec la taille de l'EF (déplacement + Le > 
taille de l'EF), le logiciel renvoie l'état de traitement 
‘6700 ’. 
▼M1 
— 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 renvoie 
l’état de traitement ‘ 6400 ’ ou ‘ 6500 ’. 
▼B 
— Si l'enregistrement est impossible, le logiciel renvoie 
l'état de traitement  ‘6581’ . 
3.5.3.3 C o m m a n d e a v e c o c t e t d ' i n s t r u c t i o n i m p a i r  
Cette variante de commande permet à l'IFD d'enregistrer des données 
dans un EF contenant 32 768 octets ou davantage.  
TCS_64 Une carte tachygraphique prenant en charge les EF dotés de 
32 768 octets ou davantage doit prendre en charge cette 
variante de commande concernant les EF. Une carte tachy ­
graphique peut prendre en charge ou non cette variante de 
commande pour d'autres EF.  
TCS_65  Message de commande  
Octet  Longueur  Valeur  Description  
CLA  1  ‘00h’  
INS 1  ‘D7h’  Update Binary  
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 intè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'oc ­
tets. C'est-à-dire que, à l'aide de l'octet de longueur ‘01h’, 
l'IFD doit coder un déplacement/une longueur de 0 à 255 
et, à l'aide de l'octet de longueur ‘02h’, un déplacement/une 
longueur de ‘256’ jusqu'à ‘65 535’ octets.  
TCS_66  Message de réponse  
Octet  Longueur  Valeur  Description  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 212  
— Si la commande aboutit, la carte renvoie l'état ‘ 9000 ’ 
— Si aucun EF n'est sélectionné, le logiciel renvoie l'état 
de traitement ‘ 6986 ’. 
— Si les conditions de sécurité du fichier sélectionné ne 
sont pas remplies, la commande est interrompue par 
‘6982 ’. 
— Si le déplacement n'est pas compatible avec la taille de 
l'EF (déplacement > taille de l'EF), le logiciel renvoie 
l'état de traitement ‘ 6B00 ’. 
— Si le volume des données à enregistrer est n'est pas 
compatible avec la taille de l'EF (déplacement + Le > 
taille de l'EF), le logiciel renvoie l'état de traitement 
‘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 renvoie 
l'état de traitement  ‘6400’  ou ‘6500’ . 
— Si l'enregistrement est impossible, le logiciel renvoie 
l'état de traitement  ‘6581’ . 
3.5.3.3.1 C o m m a n d e a v e c m e s s a g e r i e s é c u r i s é e ( e x e m p l e )  
L'exemple suivant illustre l'utilisation de la messagerie sécurisée si la 
condition de sécurité SM-MAC-G2 s'applique.  
TCS_67 Message de commande  
Octet  Longueur  Valeur  Description  
CLA  1  ‘0Ch’  Messagerie sécurisée demandée  
INS 1  ‘D7h’  Update Binary  
P1 1  ‘00h’  EF actif  
P2 1  ‘00h’  
Lc 1  ‘XXh’  Longueur de la zone de données sécurisée  
#6 1  ‘B3h’  Balise indiquant la valeur des données ordinaires codées 
dans BER-TLV  
#7 L  ‘NNh’ ou 
‘81 NNh’  L PV : longueur des données transmises 
L équivaut à 2 octets si L  PV > 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étionnaire doté de la 
balise ‘53h’ qui intègre les données à enregistrer  
#(7+L+NN)  1  ‘8Eh’  T  CC : balise indiquant le total de contrôle cryptographi ­
que 
#(8+L+NN)  1  ‘XXh’  L  CC : longueur du total de contrôle cryptographique 
suivant 
‘08h’, ‘0Ch’ ou ‘10h’ selon la longueur de clé AES 
pour la messagerie sécurisée de génération 2 (cf. appen ­
dice 11 partie B)  
#(9+L+NN)- 
#(8+M+L+ 
NN) M ‘XX..XXh’  Total de contrôle cryptographique  
Le 1  ‘00h’  Conformément à la norme ISO/IEC 7816-4  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 213  
TCS_68 Message de réponse si la commande réussit  
Octet  Longueur  Valeur  Description  
#1 1  ‘99h’  T  SW : balise indiquant des mots d'état (à protéger par 
CC) 
#2 1  ‘02h’  L  SW : longueur des mots d'état renvoyés  
#3-#4  2  ‘XXXXh’  État de traitement de l'APDU de réponse non protégée  
#5 1  ‘8Eh’  T  CC : balise indiquant le total de contrôle cryptographi ­
que 
#6 1  ‘XXh’  L  CC : longueur du total de contrôle cryptographique 
suivant 
‘08h’, ‘0Ch’ ou ‘10h’ selon la longueur de clé AES 
pour la messagerie sécurisée de génération 2 (cf. appen ­
dice 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 conforme à la norme ISO/IEC 7816-4, mais elle 
se caractérise par un usage restreint en comparaison avec la 
commande analogue définie dans cette norme.  
La commande GET CHALLENGE (obtenir un challenge) demande à 
la carte d'émettre un challenge afin de l'utiliser dans le cadre d'une 
procédure liée à la sécurité et comportant l'envoi 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  Description  
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  Description  
#1-#8  8  ‘XX..XXh’  Challenge  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
— Si la commande aboutit, la carte renvoie l'état ‘ 9000 ’. 
— Si Le est différent de ‘08h’, le logiciel renvoie l'état de 
traitement ‘ 6700 ’. 
— Si les paramètres P1-P2 sont incorrects, le logiciel 
renvoie l'état de traitement  ‘6A86’ . ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 214  
3.5.5  VERIFY  
Cette commande est conforme à la norme ISO/IEC 7816-4, mais elle 
se caractérise par un usage restreint en comparaison avec la 
commande analogue définie dans cette norme.  
Seule la carte d'atelier doit prendre en charge cette commande.  
D'autres types de cartes tachygraphiques 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écuter cette 
commande. Pour d'autres types de cartes tachygraphiques que les 
cartes d'atelier, le comportement, c'est-à-dire le code d'erreur renvoyé, 
sort du champ de la présente spécification, si cette commande est 
envoyée.  
La commande VERIFY lance, au niveau de la carte, la comparaison 
entre les données CHV (PIN) envoyées et les données CHV de réfé ­
rence enregistrées dans la mémoire de la carte.  
▼M1 
TCS_72 Le PIN indiqué 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 WorkshopCardPIN en appendice 1.  
▼B 
TCS_73 Les applications tachygraphiques de génération 1 et 2 
doivent utiliser la même référence CHV.  
TCS_74 La carte tachygraphique doit contrôler si la commande est 
correctement codée. Si la commande n'est pas correctement 
codée, la carte ne doit pas comparer les valeurs CHV, ni 
décrémenter le compteur CHV de tentatives restantes, ni 
réinitialiser l'état de sécurité «PIN_Verified». 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 compteur de tentatives CHV 
restantes est réinitialisé. La valeur initiale du compteur de 
tentatives CHV restantes est de 5. Si la commande aboutit, 
la carte définit l'état de sécurité interne «PIN_Verified». La 
carte réinitialise cet état de sécurité si la carte est réinitia ­
lisée ou si le code CHV transmis par la commande ne 
correspond pas à la CHV de référence stockée.  
Remarque:  utiliser la même CHV de référence et un état de 
sécurité global évite à un employé d'atelier de devoir 
renseigner à nouveau le PIN après avoir sélectionné un 
autre DF d'application tachygraphique.  
TCS_76 La carte enregistre l'échec d'une comparaison, c'est-à-dire 
que le compteur 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  Description  
CLA  1  ‘00h’  
INS 1  ‘20h’  INS  
P1 1  ‘00h’  P1  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 215  
Octet  Longueur  Valeur  Description  
P2 1  ‘00h’  P2 (la CHV vérifiée est implicitement connue)  
Lc 1  ‘08h’  Longueur du code CHV transmis  
#6-#13  8  ‘XX..XXh’  CHV  
TCS_78  Message de réponse  
Octet  Longueur  Valeur  Description  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
— Si la commande aboutit, la carte renvoie l'état ‘ 9000 ’. 
— Si les CHV de référence sont introuvables, le logiciel 
renvoie l'état de traitement  ‘6A88’ . 
— Si les CHV sont bloquées (le compteur de tentatives 
CHV restantes est nul), le logiciel renvoie l'état de 
traitement  ‘6983’ . Une fois dans cet état, les CHV ne 
pourront jamais plus être présentées avec succès.  
— Si la comparaison échoue, le compteur de tentatives 
restantes est décrémenté et le logiciel renvoie l'état  
‘63CX’  (X > 0 et X correspond au compteur de tenta ­
tives CHV restantes).  
— Si les CHV de référence sont considérées comme alté ­
rées, le logiciel renvoie l'état de traitement  ‘6400’  ou 
‘6581’ . 
— Si Lc est différente de ‘08h’, le logiciel renvoie l'état de 
traitement ‘ 6700 ’. 
3.5.6  GET RESPONSE  
Cette commande est conforme à la norme ISO/IEC 7816-4.  
Cette commande (indispensable et exclusivement disponible pour le 
protocole T=0) permet d'assurer la transmission de données préparées 
entre la carte et le périphérique d'interface (cas où une commande 
aurait inclus les deux octets Lc et Le).  
La commande GET RESPONSE doit être émise immédiatement après 
la commande de préparation des données, sinon la perte de ces 
dernières est inévitable. Après exécution 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  Description  
CLA  1  ‘00h’  
INS 1  ‘C0h’  
P1 1  ‘00h’  
P2 1  ‘00h’  
Le 1  ‘XXh’  Nombre d'octets attendus  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 216  
TCS_80  Message de réponse  
Octet  Longueur  Valeur  Description  
#1-#X  X  ‘XX..XXh’  Données  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
— Si la commande aboutit, la carte renvoie l'état ‘ 9000 ’. 
— Si la carte n'a préparé aucune donnée, elle renvoie l'état 
de traitement  ‘6900’  ou ‘6F00’ . 
— Si l'octet Le dépasse le nombre d'octets disponibles ou 
si cet octet est nul, le logiciel renvoie l'état de traite ­
ment  ‘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'octets disponibles, la carte procède normale ­
ment à l'envoi des données requises et elle renvoie 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 (protocole 
T=1), la carte renvoie l'état de traitement  ‘6D00’ . 
3.5.7  PSO: VERIFY CERTIFICATE  
Cette commande est conforme à la norme ISO/IEC 7816-8, mais elle 
se caractérise par un usage restreint en comparaison avec la 
commande analogue définie dans cette norme.  
La carte utilise la commande VERIFY CERTIFICATE pour obtenir 
une clé publique venant de l'extérieur et pour en contrôler la validité.  
3.5.7.1 C o m m a n d e d e g é n é r a t i o n 1 : p a i r e d e r é p o n s e s  
TCS_81 Cette variante de commande est uniquement prise en 
charge par une application tachygraphique de génération 1.  
TCS_82 Lorsqu'une commande VERIFY CERTIFICATE aboutit, la 
clé publique correspondante est mémorisée dans l'environ ­
nement de sécurité aux fins d'utilisation ultérieure. Cette clé 
doit être explicitement configurée pour être utilisée, dans le 
cadre de commandes touchant à la sécurité (INTERNAL 
AUTHENTICATE, EXTERNAL AUTHENTICATE ou 
VERIFY CERTIFICATE), par la commande MSE (cf. 
paragraphe 3.5.11) à l'aide de son identificateur de clé.  
TCS_83 En tout état de cause, la commande VERIFY CERTIFI ­
CATE utilise la clé publique préalablement sélectionnée 
par la commande MSE pour ouvrir le certificat. Cette clé 
publique doit être celle d'un État membre ou de l'Europe.  
TCS_84  Message de commande  
Octet  Longueur  Valeur  Description  
CLA  1  ‘00h’  
INS 1  ‘2Ah’  Exécution d'une opération de sécurité  
P1 1  ‘00h’  P1  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 217  
Octet  Longueur  Valeur  Description  
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écrits en appendice 11)  
TCS_85  Message de réponse  
Octet  Longueur  Valeur  Description  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
— Si la commande aboutit, la carte renvoie l'état ‘ 9000 ’. 
— Si la vérification du certificat échoue, le logiciel renvoie 
l'état de traitement  ‘6688’ . Le processus de vérification 
et de dévoilement du certificat fait l'objet d'une descrip ­
tion détaillée à l'appendice 11 pour G1 et G2.  
— Si aucune clé publique n'est présente dans l'environne ­
ment de sécurité, le logiciel renvoie l'état de traitement  
‘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 
renvoie l'état de traitement  ‘6400’  ou ‘6581’ . 
— Uniquement pour la génération 1: si la clé publique sélec ­
tionnée (utilisée pour dévoiler 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 renvoie l'état de traitement  ‘6985’ . 
3.5.7.2 C o m m a n d e d e g é n é r a t i o n 2 : p a i r e d e r é p o n s e s  
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 conformé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écutable dans le MF, DF Tachograph 
et DF Tachograph_G2, cf. TCS_33.  
TCS_87  Message de commande  
Octet  Longueur  Valeur  Description  
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écurité  
P1 1  ‘00h’  
P2 1  ‘BEh’  Vérifier le certificat autodescriptif  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 218  
Octet  Longueur  Valeur  Description  
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 conca ­
téné et l'objet informatif 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 courtes, les dispositions suivantes s'appli ­
quent: 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 
en fonction de la valeur de l'octet de la carte Dimension de 
la zone d'informations, cf. TCS_14. Si l'IFD a un autre 
comportement, celui de la carte sort du périmètre.  
TCS_89 Pour les APDU longues, les dispositions suivantes s'appli ­
quent: 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 trans ­
mettre la charge de la commande et transmettre le 
maximum d'octets dans la première APDU de commande. 
Si l'IFD adopte un autre comportement, celui de la carte 
sort du périmètre.  
Remarque:  l'appendice 11 prévoit que la carte stocke le 
certificat ou les contenus pertinents du certificat et actualise 
son currentAuthenticatedTime.  
La structure de message de réponse et les mots d'état figu ­
rent en TCS_85.  
TCS_90 Outre les codes d'erreurs listés en TCS_85, la carte peut 
également renvoyer les codes d'erreur suivants:  
— Si la clé publique sélectionnée (utilisée pour dévoiler le 
certificat) possède un CHA.LSB (CertificateHolderAu ­
thorisation.equipmentType) inadapté à la vérification du 
certificat telle que prévue par l'appendice 11, le logiciel 
renvoie l'état de traitement ‘ 6985 ’. 
— Si le currentAuthenticatedTime de la carte est ultérieur 
à la date d'expiration du certificat, le logiciel renvoie 
l'état de traitement ‘ 6985 ’. 
— Si la dernière commande de la chaîne est attendue, la 
carte renvoie ‘ 6883 ’. 
— Si des paramètres incorrects sont envoyés dans la zone 
de données de la commande, la carte renvoie ‘ 6A80 ’ 
(également utilisé dans le cas où les objets informatifs 
ne sont pas envoyés dans l'ordre spécifié).  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 219  
3.5.8  INTERNAL AUTHENTICATE  
Cette commande est conforme à la norme ISO/IEC 7816-4.  
TCS_91 Toutes les cartes tachygraphiques doivent prendre en 
charge cette commande dans le DF Tachograph de généra ­
tion 1. La commande peut ou non être accessible dans le 
MF et/ou le DF Tachograph_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 protocole 
d'authentification de la génération 1 n'est accessible que 
dans le DF_Tachograph de génération 1.  
La commande INTERNAL AUTHENTICATE permet à 
l'IFD d'authentifier la carte. Le processus d'authentification 
fait l'objet d'une description détaillée à l'appendice 11. Il 
comprend les instructions suivantes:  
TCS_92 La commande INTERNAL AUTHENTICATE utilise la clé 
privée de la carte (implicitement sélectionnée) pour signer 
des données d'authentification, y compris 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 signa ­
ture et constituer le jeton d'authentification (pour plus de 
détails, reportez-vous à l'appendice 11).  
TCS_93  Message de commande  
Octet  Longueur  Valeur  Description  
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.CHR (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  Description  
#1-#128  128  ‘XX..XXh’  Jeton d'authentification de carte (cf. appendice 11)  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
— Si la commande aboutit, la carte renvoie l'état ‘ 9000 ’. 
— Si aucune clé publique n'est présente dans l'environne ­
ment de sécurité, le logiciel renvoie l'état de traitement  
‘6A88’ . 
— Si aucune clé privée n'est présente dans l'environnement 
de sécurité, le logiciel renvoie l'état de traitement  
‘6A88’ . 
— Si la VU.CHR ne correspond pas à l'identificateur de 
clé publique actif, le logiciel renvoie l'état de traitement  
‘6A88’ . ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 220  
— Si la clé privée sélectionnée est considérée comme alté ­
rée, le logiciel renvoie l'état de traitement  ‘6400’  ou 
‘6581’ . 
▼M1 
TCS_95 Si la commande INTERNAL AUTHENTICATE aboutit, la 
clé de session active de génération 1, pour autant qu’elle 
existe, est effacée et cesse d’être disponible. Pour disposer 
d’une nouvelle clé de session de génération 1, il convient 
d’exécuter avec succès la commande EXTERNAL 
AUTHENTICATE pour le mécanisme d’authentification 
de génération 1.  
Remarque:  Pour les clés de session de génération 2, voir 
l’appendice 11, paragraphes CSM_193 et CSM_195. Si les 
clés de session de génération 2 sont établies et que la carte 
tachygraphique reçoit la commande INTERNAL 
AUTHENTICATE en clair APDU, elle abandonne la 
session de messagerie sécurisée de génération 2 et détruit 
les clés de session de génération 2.  
▼B 
3.5.9  EXTERNAL AUTHENTICATE  
Cette commande est conforme à la norme ISO/IEC 7816-4.  
La commande EXTERNAL AUTHENTICATE (authentification 
externe) permet à la carte d'authentifier l'IFD. Le processus d'authen ­
tification fait l'objet d'une description détaillée à l'appendice 11 pour 
le tachygraphe G1 et G2 (authentification VU).  
TCS_96 La variante de la commande pour le mécanisme d'authen ­
tification mutuelle de génération 1 est uniquement prise en 
charge par une application tachygraphique de génération 1.  
▼M1 
TCS_97 La variante de la commande pour l’authentification 
mutuelle de la carte VU de deuxième génération est exécu ­
table dans le MF, DF Tachograph et DF Tachograph_G2, 
cf. également TCS_34. Si cette commande EXTERNAL 
AUTHENTICATE de génération 2 aboutit, la clé de 
session active de génération 1, pour autant qu’elle existe, 
est effacée et cesse d’être disponible.  
Remarque:  Pour les clés de session de génération 2, voir 
l’appendice 11, paragraphes CSM_193 et CSM_195. Si les 
clés de session de génération 2 sont établies et que la carte 
tachygraphique reçoit la commande EXTERNAL 
AUTHENTICATE en clair APDU, elle abandonne la 
session de messagerie sécurisée de génération 2 et détruit 
les clés de session de génération 2.  
▼B 
TCS_98  Message de commande  
Octet  Longueur  Valeur  Description  
CLA  1  ‘00h’  CLA  
INS 1  ‘82h’  INS  
P1 1  ‘00h’  Clés et algorithmes implicitement connus  
P2 1  ‘00h’  
Lc 1  ‘XXh’  Lc (longueur des données transmises à la carte)  
#6-#(5+L)  L  ‘XX..XXh’  Authentification de génération 1: cryptogramme (cf. 
appendice 11 partie A) 
Authentification de génération 2: signature générée par 
l'IFD (cf. appendice 11 partie B)  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 221  
TCS_99  Message de réponse  
Octet  Lon- 
gueur  Valeur  Description  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
— Si la commande aboutit, la carte renvoie l'état ‘ 9000 ’. 
— Si le CHA de la clé publique active n'est pas la conca ­
ténation de l'AID de l'application tachygraphique et 
d'un type d'équipement VU, le logiciel renvoie un état 
de traitement  ‘6F00’ . 
— Si la commande n'est pas immédiatement précédée 
d'une commande GET CHALLENGE, le logiciel 
renvoie l'état de traitement  ‘6985’ . 
L'application tachygraphique de génération 1 peut en outre 
renvoyer les codes d'erreur suivants:  
— Si aucune clé publique n'est présente dans l'environne ­
ment de sécurité, le logiciel renvoie l'état de traitement  
‘6A88’ . 
— Si aucune clé privée n'est présente dans l'environnement 
de sécurité, le logiciel renvoie l'état de traitement  
‘6A88’ . 
— Si la vérification du cryptogramme échoue, le logiciel 
renvoie l'état de traitement  ‘6688’ . 
— Si la clé privée sélectionnée est considérée comme alté ­
rée, le logiciel renvoie l'état de traitement  ‘6400’  ou 
‘6581’ . 
La variante de la commande pour l'authentification de 
génération 2 peut également renvoyer les codes d'erreurs 
suivants:  
— Si la vérification de signature échoue, la carte renvoie 
‘6300 ’. 
3.5.10  GENERAL AUTHENTICATE  
Cette commande sert au protocole d'authentification du circuit intégré 
de génération 2 défini dans l'appendice 11 partie B conformé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.  
TCS_101  Message de commande  
Octet  Lon- 
gueur  Valeur  Description  
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érieure  
#6-#(5+L)  L  ‘7Ch’ + L  7C + 
‘80h’ + L  80 + 
‘XX..XXh’  Valeur de la clé publique éphémère et codée DER- 
TLV (cf. appendice 11) 
La VU doit envoyer les objets informatifs dans cet 
ordre.  
▼M1 
5 + L + 1  1  ‘00h’  Conformément à la norme ISO/IEC 7816-4  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 222  
TCS_102  Message de réponse  
Octet  Lon- 
gueur  Valeur  Description  
#1-#L  L  ‘7Ch’ + L  7C + ‘81h’ 
+ ‘08h’ + ‘XX..XXh’ 
+ ‘82h’ + L  82 + 
‘XX..XXh’  Données d'authentification dynamique codées 
DER-TLV: jeton ‘nonce’ et d'authentification 
(cf. appendice 11)  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
— Si la commande aboutit, la carte renvoie l'état ‘ 9000 ’. 
— La carte renvoie‘ 6A80 ’ pour indiquer des paramètres 
incorrects dans la zone de données.  
— La carte renvoie ‘ 6982 ’ si la commande External 
Authenticate échoue.  
L'objet informatif d'authentification 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éri ­
fication, c'est-à-dire si les mots d'état se situent entre 
‘6400 ’ et ‘ 6FFF ’; et 
— peut être absent en cas d'avertissement, c'est-à-dire si 
les mots d'état se situent entre ‘ 6200 ’ et ‘ 63FF ’. 
3.5.11  MANAGE SECURITY ENVIRONMENT  
Cette commande permet de définir une clé publique aux fins d'au ­
thentification.  
3.5.11.1 C o m m a n d e d e g é n é r a t i o n 1 : p a i r e d e r é p o n s e s  
Cette commande est conforme à la norme ISO/IEC 7816-4. Son usage 
est restreint relativement à la norme en question.  
TCS_103 Cette commande est uniquement prise en charge par une 
application tachygraphique 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ésente dans la 
mémoire de la carte, l'environnement de sécurité reste 
inchangé.  
TCS_106  Message de commande  
Octet  Lon- 
gueur  Valeur  Description  
CLA  1  ‘00h’  CLA  
INS 1  ‘22h’  INS  
P1 1  ‘C1h’  P1: clé mentionnée valable pour l'ensemble des opéra ­
tions cryptographiques  
P2 1  ‘B6h’  P2 (données mentionnées concernant la signature numé ­
rique)  
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étrie  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 223  
Octet  Lon- 
gueur  Valeur  Description  
#7 1  ‘08h’  Longueur de la référence (identificateur de clé)  
#8-#15  8  ‘XX..XXh’  Identificateur de clé conforme aux dispositions énoncées 
à l'appendice 11  
TCS_107  Message de réponse  
Octet  Lon- 
gueur  Valeur  Description  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
— Si la commande aboutit, la carte renvoie l'état ‘ 9000 ’. 
— Si la clé mentionnée n'est pas présente dans la mémoire 
de la carte, le logiciel renvoie l'état de traitement  
‘6A88’ . 
— S'il manque certains objets informatifs attendus dans la 
structure de messagerie sécurisée, le logiciel renvoie 
l'état de traitement  ‘6987’ . Cet événement est suscep ­
tible de se produire si la balise ‘83h’ fait défaut.  
— Si certains objets informatifs sont incorrects, le logiciel 
renvoie l'état de traitement  ‘6988’ . Cet événement est 
susceptible de se produire si la longueur de l'identifica ­
teur de clé ne correspond pas à ‘08h’.  
— Si la clé sélectionnée est considérée comme altérée, le 
logiciel renvoie l'état de traitement  ‘6400’  ou ‘6581’ . 
3.5.11.2 C o m m a n d e d e g é n é r a t i o n 2 : p a i r e d e r é p o n s e s  
Pour l'authentification de génération 2, la carte tachygraphique prend 
en charge la MSE suivante: versions de commande définies et 
conformes à la norme ISO/IEC 7816-4. Ces versions de commande 
ne sont pas prises en charge pour l'authentification de génération 1.  
3.5.11.2.1 A u t h e n t i f i c a t i o n d e c i r c u i t M S E : S E T A T  
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:AT pour authentifier 
un circuit  
Octet  Lon- 
gueur  Valeur  Description  
CLA  1  ‘00h’  
INS 1  ‘22h’  
P1 1  ‘41h’  Défini pour l'authentification interne  
P2 1  ‘A4h’  Authentification  
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: identificateur d'objet pour l'authentification de 
circuit (valeur uniquement, balise ‘06h’ absente). 
Cf. appendice 1 pour les valeurs des identificateurs d'ob ­
jets; utiliser la notation en octets. Cf. appendice 11 pour 
les instructions relatives à la sélection de l'un des iden ­
tificateurs d'objet.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 224  
3.5.11.2.2 A u t h e n t i f i c a t i o n d e V U M S E : S E T A T  
La commande MSE:SET AT suivante sert à sélectionner les paramè ­
tres et les clés de l'authentification de la VU effectuée par une 
commande ultérieure External 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 authentifier 
une VU  
Octet  Lon- 
gueur  Valeur  Description  
CLA  1  ‘00h’  
INS 1  ‘22h’  
P1 1  ‘81h’  Définit l'authentification externe  
P2 1  ‘A4h’  Authentification  
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: identificateur d'objet pour l'authentification de 
VU (valeur uniquement, balise ‘06h’ absente). 
Cf. appendice 1 pour les valeurs des identificateurs d'ob ­
jets; utiliser la notation en octets. Cf. appendice 11 pour 
les instructions relatives à la sélection de l'un des iden ­
tificateurs 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 certificat mentionnée 
dans son certificat.  
‘91h’ + L  91 + 
‘XX..XXh’  Représentation comprimée et codée DER-TLV de la clé 
publique éphémère de la VU qui servira lors de l'authen ­
tification du circuit (cf. appendice 11)  
3.5.11.2.3 M S E : S E T D S T  
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  
— en vue de vérifier une signature ou un certificat fourni dans un 
PSO ultérieur: 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  Lon- 
gueur  Valeur  Description  
CLA  1  ‘00h’  
INS 1  ‘22h’  
P1 1  ‘81h’  Défini pour vérification  
P2 1  ‘B6h’  Signature numérique  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 225  
Octet  Lon- 
gueur  Valeur  Description  
Lc 1  ‘NNh’  Lc: longueur de la zone de données ultérieure  
#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 certificat dans le certificat 
de la clé publique (cf. appendice 11)  
Pour toutes les versions de commande, la structure du message de 
réponse et les mots d'état proviennent:  
TCS_114  Message de réponse  
Octet  Lon- 
gueur  Valeur  Description  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
— Si la commande aboutit, la carte renvoie l'état ‘ 9000 ’. 
Le protocole a été sélectionné et initialisé.  
— ‘6A80’  indique des paramètres incorrects 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.  
▼M1 
— Si le currentAuthenticatedTime de la carte est ultérieur 
à la date d’expiration de la clé publique sélectionnée, le 
logiciel renvoie l’état de traitement ‘ 6A88 ’. 
Remarque:  En cas de MSE: SET AT pour authentification 
de VU, la clé mentionnée est une clé publique VU_MA. La 
carte définit la clé publique VU_MA pour utilisation, si elle 
est disponible dans sa mémoire, correspondant à la réfé ­
rence du titulaire du certificat (CHR) indiquée dans la zone 
de données de la commande (la carte peut identifier les clés 
publiques VU_MA au moyen du champ CHA du certifi ­
cat). Une carte ne renvoie «6A 88» à cette commande que 
lorsque seule la clé publique VU_Sign est disponible ou 
lorsqu’aucune clé publique de l’unité embarquée sur véhi ­
cule n’est disponible. Voir la définition du champ CHA à 
l’appendice 11 et la définition du type de données Equip ­
mentType à l’appendice 1.  
De même, en cas de commande MSE: SET DST indiquant 
un EQT (une VU ou une carte) est envoyée à une carte de 
contrôle, aux termes du paragraphe CSM_234, la clé 
mentionnée est toujours une clé EQT_Sign à utiliser lors 
de la vérification d’une signature numérique. Selon la 
figure 13 de l’appendice 11, la carte de contrôle enregistre 
toujours la clé publique EQT_Sign pertinente. Dans 
certains cas, la carte de contrôle peut avoir enregistré la 
clé publique EQT_MA correspondante. La carte de contrôle 
définit toujours la clé publique EQT_Sign pour utilisation 
lorsqu’elle reçoit une commande MSE: SET DST.  
▼B 
3.5.12  PSO: HASH  
Cette commande permet de transférer vers la carte le résultat du calcul 
de hachage auquel certaines données pourraient être soumises. Cette 
commande s'emploie lors de la vérification de signatures numériques. 
La valeur de hachage est enregistrée temporairement en vue d'une 
commande PSO ultérieure: Verify Digital Signature.  
Cette commande est conforme à la norme ISO/IEC 7816-8. Son usage 
est restreint relativement à la norme en question.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 226  
Seule la carte de contrôle doit prendre en charge cette commande dans 
le DF Tachograph et DF Tachograph_G2.  
D'autres types de cartes tachygraphiques peuvent ou non exécuter 
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 charge SHA-1.  
TCS_115 La valeur de hachage enregistrée temporairement doit être 
supprimée si une nouvelle valeur de hachage est calculée à 
l'aide de la commande PSO: Hash si un DF est sélectionné 
et si la carte tachygraphique est réinitialisée.  
TCS_116  Message de commande  
Octet  Lon- 
gueur  Valeur  Description  
CLA  1  ‘00h’  CLA  
INS 1  ‘2Ah’  Exécution d'une opération de sécurité  
P1 1  ‘90h’  Renvoie d'un code de hachage  
P2 1  ‘A0h’  Balise: zone de données contenant les DO appropriés 
pour le hachage  
Lc 1  ‘XXh’  Longueur Lc de la zone de données suivante  
#6 1  ‘90h’  Balise indiquant le code de hachage  
#7 1  ‘XXh’  Longueur L du code de hachage: 
‘14h’ dans l'application de génération 1 (cf. appendice 11 
partie A) 
‘20h’, ‘30h’ ou ‘40h’ pour l'application de génération 2 
(cf. appendice 11 partie B)  
#8-#(7+L)  L  ‘XX..XXh’  Code de hachage  
TCS_117  Message de réponse  
Octet  Lon- 
gueur  Valeur  Description  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
— Si la commande aboutit, la carte renvoie l'état ‘ 9000 ’. 
— S'il manque certains objets informatifs attendus (comme 
précisé ci-avant), le logiciel renvoie l'état de traitement  
‘6987’ . Cet événement est susceptible de se produire si 
la balise ‘90h’ fait défaut.  
— Si certains objets informatifs sont incorrects, le logiciel 
renvoie l'état de traitement  ‘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 conforme à la norme ISO/IEC 7816-8. 
L'octet CLA de cette commande indique donc un usage exclusif de 
la commande PERFORM SECURITY OPERATION/HASH.  
Seules les cartes de conducteur et d'atelier doivent prendre en charge 
cette commande dans le DF Tachograph et le DF Tachograph_G2.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 227  
D'autres types de cartes tachygraphiques peuvent ou non exécuter 
cette commande. Si une carte d'entreprise ou de contrôle exécute 
cette commande, la commande doit être exécutée conformé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évoit le présent chapitre, à 
savoir sans autoriser le calcul d'une valeur de hachage, mais avec 
abandon et communication d'un code d'erreur approprié.  
TCS_118 La commande PERFORM HASH of FILE s'utilise pour 
hacher la zone de données de l'EF transparent sélectionné.  
TCS_119 Une carte tachygraphique doit prendre en charge cette 
commande uniquement pour les EF listés au chapitre 4 
sous les DF_Tachograph et DF_Tachograph_G2 et en 
tenant compte des exceptions suivantes. Une carte tachy ­
graphique ne doit pas prendre en charge la commande pour 
l'EF Sensor_Installation_Data du DF Tachograph_G2.  
TCS_120 Le résultat de l'opération de hachage est enregistré tempo ­
rairement dans la mémoire de la carte. Par la suite, son 
utilisation permettra d'obtenir une signature numérique du 
fichier en recourant à la commande PSO: COMPUTE 
DIGITAL SIGNATURE.  
▼M1 
TCS_121 La valeur de hachage du fichier enregistrée temporairement 
doit être supprimée si une nouvelle valeur de hachage de 
fichier est calculée à l’aide de la commande PERFORM 
HASH of FILE, si un DF est sélectionné et si la carte 
tachygraphique est réinitialisée.  
▼B 
TCS_122 L'application tachygraphique de génération 1 doit prendre 
en charge SHA-1.  
▼M1 
TCS_123 L’application tachygraphique de génération 2 doit prendre 
en charge l’algorithme SHA-2 (SHA-256, SHA-384 ou 
SHA-512), spécifié par la méthode de cryptage à l’appen ­
dice 11, partie B, pour la clé de signature de carte 
Card_Sign.  
▼B 
TCS_124  Message de commande  
▼M1 
Octet  Lon- 
gueur  Valeur  Description  
CLA  1  ‘80h’  CLA  
INS 1  ‘2Ah’  Exécution d’une opération de sécurité  
P1 1  ‘90h’  Balise: Hash  
P2 1  ‘00h’  Algorithme implicitement connu 
Pour l’application tachygraphique de génération 1: SHA- 
1 
Pour l’application tachygraphique de génération 2: l’al ­
gorithme SHA-2 (SHA-256, SHA-384 ou SHA-512), 
défini par la méthode de cryptage à l’appendice 11, 
partie B, pour la clé de signature de carte Card_Sign  
▼B 
TCS_125  Message de réponse  
Octet  Lon- 
gueur  Valeur  Description  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
— Si la commande aboutit, la carte renvoie l'état ‘ 9000 ’. 
— Si l'EF actif n'autorise pas cette commande (EF 
Sensor_Installation_Data dans le DF Tachograph_G2), 
le logiciel renvoie l'état de traitement  ‘6985’ . ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 228  
— 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 
renvoie 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 renvoie l'état 
de traitement ‘ 6986 ’. 
3.5.14  PSO: COMPUTE DIGITAL SIGNATURE  
▼M1 
Cette commande permet de calculer la signature numérique du code 
de hachage préalablement calculé (cf. commande PERFORM HASH 
of FILE, paragraphe 3.5.13).  
Seules les cartes de conducteur et d’atelier doivent prendre en charge 
cette commande dans le DF Tachograph et le DF Tachograph_G2.  
D’autres types de cartes tachygraphiques peuvent ou non exécuter 
cette commande. Pour l'application tachygraphique de génération 2, 
seule la carte du conducteur et la carte d’atelier possèdent une clé de 
signature de génération 2; les autres cartes ne peuvent pas exécuter 
cette commande, mais l’abandonnent avec un code d’erreur approprié.  
La commande peut ou non être accessible dans le MF. Si la 
commande n'est pas accessible dans le MF, le logiciel doit inter ­
rompre la commande avec un code d'erreur adapté.  
Cette commande est conforme à la norme ISO/IEC 7816-8. Son usage 
est restreint relativement à la norme en question.  
▼B 
TCS_126 Cette commande ne doit pas calculer une signature numé ­
rique pour un code de hachage préalablement calculé avec 
la commande PSO: HASH.  
TCS_127 La clé privée de la carte sert à calculer la signature numé ­
rique et est implicitement connue de la carte.  
TCS_128 L'application tachygraphique de génération 1 exécute une 
signature numérique à l'aide d'une méthode de remplissage 
conforme avec la norme PKCS1 (cf. appendice 11 pour 
toute information complémentaire).  
TCS_129 L'application tachygraphique de génération 2 calcule une 
signature numérique basée sur une courbe elliptique (cf. 
appendice 11 pour toute information complémentaire).  
TCS_130  Message de commande  
Octet  Lon- 
gueur  Valeur  Description  
CLA  1  ‘00h’  CLA  
INS 1  ‘2Ah’  Exécution d'une opération de sécurité  
P1 1  ‘9Eh’  Signature numérique à renvoyer  
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 
(hachage du fichier)  
Le 1  ‘NNh’  Longueur de la signature attendue  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 229  
TCS_131  Message de réponse  
Octet  Lon- 
gueur  Valeur  Description  
#1-#L  L  ‘XX..XXh’  Signature du hachage préalablement calculé  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
— Si la commande aboutit, la carte renvoie l'état ‘ 9000 ’. 
— Si la clé privée implicitement sélectionnée est consi ­
dérée comme altérée, le logiciel renvoie l'état de traite ­
ment ‘ 6400 ’ ou ‘6581’ . 
— Si le hachage calculé lors d'une exécution antérieure de 
la commande Perform Hash of File n'est pas disponible, 
le logiciel renvoie l'état de traitement  ‘6985’ . 
3.5.15  PSO: VERIFY DIGITAL SIGNATURE  
Cette commande sert à vérifier la signature numérique fournie en 
entrée, dont la carte connaît le hachage. La carte connaît implicitement 
l'algorithme de signature.  
Cette commande est conforme à la norme ISO/IEC 7816-8. Son usage 
est restreint relativement à la norme en question.  
Seule la carte de contrôle doit prendre en charge cette commande dans 
le DF Tachograph et DF Tachograph_G2.  
D'autres types de cartes tachygraphiques peuvent ou non exécuter 
cette commande. La commande peut ou non être accessible dans le 
MF. 
TCS_132 La commande VERIFY DIGITAL SIGNATURE utilise 
toujours la clé publique sélectionnée à l'aide de la précé ­
dente commande MANAGE SECURITY ENVIRONMENT 
MSE: Set DST et du code de hachage antérieur introduit à 
l'aide d'une commande PSO: HASH.  
TCS_133  Message de commande  
▼M1 
Octet  Lon- 
gueur  Valeur  Description  
CLA  1  ‘00h’  CLA  
INS 1  ‘2Ah’  Exécution d’une opération de sécurité  
P1 1  ‘00h’  
P2 1  ‘A8h’  Balise: zone de données contenant les DO pertinents 
pour la vérification  
Lc 1  ‘XXh’  Longueur Lc de la zone de données suivante  
#6 1  ‘9Eh’  Balise indiquant une signature numérique  
#7 ou 
#7-#8  L ‘NNh’ ou 
‘81 NNh’  Longueur de la signature numérique (L équivaut à 2 
octets si la signature numérique est plus longue que 
127 octets): 
128 octets codés conformément à l’appendice 11 partie 
A pour l’application tachygraphique de génération 1. 
Selon la courbe retenue pour l’application tachygra ­
phique de génération 2 (cf. appendice 11 partie B).  
#(7+L)- 
#(6+L+NN)  NN ‘XX..XXh’  Contenu de la signature numérique  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 230  
TCS_134  Message de réponse  
Octet  Lon- 
gueur  Valeur  Description  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
— Si la commande aboutit, la carte renvoie l'état ‘ 9000 ’. 
— Si la vérification de la signature échoue, le logiciel 
renvoie l'état de traitement  ‘6688’ . La procédure de 
vérification figure en appendice 11.  
— Si aucune clé publique n'est sélectionnée, le logiciel 
renvoie l'état de traitement  ‘6A88’ . 
— S'il manque certains objets informatifs attendus (comme 
précisé ci-avant), le logiciel renvoie 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 hachage n'est disponible pour traiter 
la commande (en raison du traitement d'une commande 
PSO: Hash antérieure), le logiciel renvoie l'état de trai ­
tement  ‘6985’ . 
— Si certains objets informatifs sont incorrects, le logiciel 
renvoie l'état de traitement  ‘6988’ . Cette erreur est 
susceptible de se produire si la longueur de l'un des 
objets informatifs requis est incorrecte.  
— Si la clé publique sélectionnée est considérée comme 
altérée, le logiciel renvoie l'état de traitement  ‘6400’  ou 
‘6581’ . 
▼M1 
— Si la clé publique sélectionnée (utilisée pour vérifier la 
signature numérique) possède un CHA.LSB (Certifica ­
teHolderAuthorisation.equipmentType) inadapté à la 
vérification de la signature numérique telle que prévue 
par l’appendice 11, le logiciel renvoie l’état de traite ­
ment ‘ 6985 ’. 
▼B 
3.5.16  PROCESS DSRC MESSAGE  
Cette commande sert à vérifier l'intégrité et l'authenticité du message 
DSRC et à déchiffrer les données communiquées par une VU et 
adressées à une autorité de contrôle ou un atelier au moyen d'un 
lien DSRC. Cette carte extrait la clé de cryptage et la clé MAC 
servant à sécuriser le message DSRC comme le décrit l'appendice 11 
partie B chapitre 13.  
Seules les cartes de contrôle et d'atelier doivent prendre en charge 
cette commande dans le DF Tachograph_G2.  
D'autres types de cartes tachygraphiques peuvent ou non mettre en 
œuvre cette commande, mais ne disposent d'aucune clé maîtresse 
DSRC. Par conséquent, ces cartes ne peuvent pas exécuter cette 
commande, mais l'abandonnent avec un code d'erreur approprié.  
La commande peut ou non être accessible dans le MF et/ou le DF 
Tachograph. Dans ce cas, la commande est abandonnée avec un code 
d'erreur approprié.  
TCS_135 La clé maîtresse DSRC est accessible uniquement dans le 
DF Tachograph_G2, c'est-à-dire que la carte de contrôle et 
d'atelier doivent prendre en charge l'exécution de la 
commande uniquement dans le DF Tachograph_G2.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 231  
TCS_136 La commande doit uniquement décrypter les données 
DSRC et vérifier le total de contrôle cryptographique, 
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écification.  
TCS_138  Message de commande  
Octet  Lon- 
gueur  Valeur  Description  
CLA  1  ‘80h’  CLA propriétaire  
INS 1  ‘2Ah’  Exécution d'une opération de sécurité  
P1 1  ‘80h’  Données de réponse: valeur ordinaire  
P2 1  ‘B0h’  Données de la commande: valeur ordinaire codé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’ + L  87 + 
‘XX..XXh’  Indicateur de contenu de remplissage codé DER-TLV 
suivi d'une charge tachygraphique codée. Pour l'octet 
de l'indicateur de contenu de remplissage, il est impératif 
d'utiliser la valeur ‘00h’ (‘aucune autre information’ 
conformément à la norme ISO/IEC 7816-4:2013 
Tableau 52). Concernant le mécanisme de cryptage, cf. 
appendice 11 partie B chapitre 13. 
Les valeurs autorisées pour la longueur L  87 sont les 
multiples de la longueur du bloc AES plus 1 pour 
l'octet indicateur du contenu de remplissage, 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’  Gabarit de référence et de contrôle de la confidentialité 
codé DER-TLV destiné à héberger la concaténation des 
éléments de données suivants (cf. appendice 1 DSRCSe ­
curityData et appendice 11 partie B chapitre 13). 
— timbre horodateur sur 4 octets; 
— compteur sur 3 octets; 
— numéro de série de la VU sur 8 octets; 
— version de la clé maîtresse DSRC 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’ + L  8E + 
‘XX..XXh’  MAC codé DER-TLV sur le message DSRC. Pour l'al ­
gorithme 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’.  
▼M1 
5 + L + 1  1  ‘00h’  Conformément à la norme ISO/IEC 7816-4  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 232  
TCS_139  Message de réponse  
Octet  Lon- 
gueur  Valeur  Description  
#1-#L  L  ‘XX..XXh’  Données absentes (en cas d'erreur) ou déchiffrées 
(contenu de remplissage supprimé)  
SW 2  ‘XXXXh’  Mots d'état (SW1, SW2)  
— Si la commande aboutit, la carte renvoie l'état ‘ 9000 ’. 
— ‘6A80’  indique si des paramètres incorrects 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 DSRC mentionnée) ne sont pas disponi ­
bles. 
— ‘6900’  indique l'échec de la vérification du total de 
contrôle cryptographique ou du décryptage des 
données.  
▼M1 
— ‘6985 ’ indique que le timbre horodateur sur 4 octets 
indiqué dans la zone de données de la commande est 
antérieur à cardValidityBegin ou postérieur à cardExpi ­
ryDate.  
▼B 
4. STRUCTURE DES CARTES TACHYGRAPHIQUES  
Le présent paragraphe définit les structures de fichiers des cartes 
tachygraphiques en vue du stockage des données accessibles.  
Il n'apporte aucune précision quant à leur structure interne, laquelle 
dépend du fabricant (en-têtes de fichier par exemple). Il n'aborde pas 
non plus l'archivage et le traitement d'éléments de données à usage 
interne tels que les
  ,
  ,
  
ou
 .  
TCS_140 Une carte tachygraphique de génération 2 doit héberger le 
fichier maître (MF) et deux applications tachygraphiques de 
génération 1 et de génération 2 de type identique (p. ex. 
des applications de cartes de conducteur).  
TCS_141 Une carte tachygraphique doit prendre en charge au moins 
le nombre d'enregistrements spécifiés pour les applications 
correspondantes et ne doit pas prendre en charge plus d'en ­
registrements 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érentes applications.  
Pour les conditions de sécurité servant aux conditions 
d'accès dans le présent chapitre, consulter le chapitre 3.3. 
En règle générale, le mode d'accès «read» indique la 
commande READ BINARY avec les octets pairs et le 
cas échéant les octets impairs INS à l'exception de l'EF 
Sensor_Installation_Data de la carte d'atelier, cf. TCS_156 
et TCS_160. Le mode d'accès «update» indique la 
commande Update Binary 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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 233  
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 court SFID est commu ­
niqué sous la forme d'un nombre décimal, p. ex. la 
valeur 30 correspond au nombre binaire 11110.
  
Dans ce tableau, est utilisée l'abréviation suivante pour la 
condition de sécurité:  
SC1 ALW OU SM-MAC-G2  
TCS_143 La structure de tous les EF doit être transparente.  
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 tachygraphique 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’) conformément à la norme ISO/IEC 
7816-4:2013 clause 12.7.1.  
TCS_147 Le fichier élémentaire EF Extended_Length doit être 
présent si la carte tachygraphique indique dans son ATR 
qu'elle prend en charge des zones de longueur étendue. 
Dans ce cas, l'EF doit contenir 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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 234  
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 conduc ­
teur de génération 1 doit avoir la structure de fichier et les 
conditions d'accès au fichier permanentes suivantes:
  
Dans le tableau ci-dessus, sont utilisées les abréviations 
suivantes concernant les conditions de sécurité:  
SC1 ALW OU SM-MAC-G2  
SC2 ALW OU SM-MAC-G1 OU SM-MAC-G2  
SC3 SM-MAC-G1 OU SM-MAC-G2  
TCS_149 La structure de tous les EF doit être transparente.  
TCS_150 L'application de la carte de conducteur de génération 1 doit 
avoir la structure de données suivante:  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 235
  
▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 236
  
▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 237  
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 struc ­
ture des données de la carte du conducteur pour une appli ­
cation 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 conduc ­
teur 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 court SFID est commu ­
niqué 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 
concernant la condition de sécurité:  
SC1 ALW OU SM-MAC-G2  
TCS_153 La structure de tous les EF doit être transparente.  
TCS_154 L'application de la carte de conducteur de génération 2 doit 
avoir la structure de données suivante:  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 238
  
► (1) M1 ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 239
  
▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 240
  
► (1) M1 
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 struc ­
ture des données de la carte du conducteur pour une appli ­
cation de génération 2:
  
► (1) M1 
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 condi ­
tions d'accès au fichier permanentes suivantes:  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 241
  
Dans le tableau ci-dessus, sont utilisées les abréviations 
suivantes concernant les conditions de sécurité:  
SC1 ALW OU SM-MAC-G2  
SC2 ALW OU SM-MAC-G1 OU SM-MAC-G2  
SC3 SM-MAC-G1 OU SM-MAC-G2  
▼M1 
SC4 Concernant la commande READ BINARY avec des 
octets pairs INS:  
(SM-C-MAC-G1 AND SM-R-ENC-MAC-G1) OU  
(SM-C-MAC-G2 AND SM-R-ENC-MAC-G2)  
Pour la commande READ BINARY avec octet 
impair INS (si pris en charge): NEV  
▼B 
TCS_157 La structure de tous les EF doit être transparente.  
TCS_158 L'application de la carte d'atelier de génération 1 doit avoir 
la structure de données suivante:  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 242
  
▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 243
  
▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 244
  
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 struc ­
ture des données de la carte d'atelier 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 condi ­
tions d'accès au fichier permanentes suivantes.  
Remarque:  l'identificateur d'EF court SFID est commu ­
niqué sous la forme d'un nombre décimal, p. ex. la 
valeur 30 correspond au nombre binaire 11110.
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 245  
Dans le tableau ci-dessus, sont utilisées les abréviations 
suivantes concernant les conditions de sécurité:  
SC1 ALW OU SM-MAC-G2  
SC5 Concernant la commande Read Binary avec des 
octets pairs INS: SM-C-MAC-G2 ET SM-R-ENC- 
MAC-G2  
Concernant la commande Read Binary avec des 
octets impairs INS (si pris en charge): NEV  
TCS_161 La structure de tous les EF doit être transparente.  
TCS_162 L'application de la carte d'atelier de génération 2 doit avoir 
la structure de données suivante:
  
► (1) (2) M1 ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 246
  
► (1) M1 ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 247
  
► (1) M1 ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 248  
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 struc ­
ture des données de la carte d'atelier pour une application 
de génération 2:
  
► (1) M1 
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 permanentes suivantes:
  
Dans le tableau ci-dessus, sont utilisées les abréviations 
suivantes concernant les conditions de sécurité:  
SC1 ALW OU SM-MAC-G2  
SC2 ALW OU SM-MAC-G1 OU SM-MAC-G2  
SC3 SM-MAC-G1 OU SM-MAC-G2  
SC6 EXT-AUT-G1 OU SM-MAC-G1 OU SM-MAC-G2  
TCS_165 La structure de tous les EF doit être transparente.  
TCS_166 L'application de la carte de contrôle de génération 1 doit 
avoir la structure de données suivante:  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 249
  
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 struc ­
ture des données de la carte de contrôle pour une applica ­
tion 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 permanentes suivantes:  
Remarque:  l'identificateur d'EF court SFID est commu ­
niqué sous la forme d'un nombre décimal, p. ex. la 
valeur 30 correspond au nombre binaire 11110.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 250
  
Dans le tableau ci-dessus, est utilisée l'abréviation suivante 
concernant la condition de sécurité:  
SC1 ALW OU SM-MAC-G2  
TCS_169 La structure de tous les EF doit être transparente.  
TCS_170 L'application de la carte de contrôle de génération 2 doit 
avoir la structure de données suivante:
  
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 struc ­
ture des données de la carte de contrôle pour une applica ­
tion de génération 2:  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 251
  
4.5. Applications de la carte d'entreprise  
4.5.1  Application de la carte d'entreprise de génération 1  
TCS_172 Après personnalisation, l'application de la carte d'entreprise 
de génération 1 doit avoir la structure de fichier et les 
conditions d'accès au fichier permanentes suivantes:
  
Dans le tableau ci-dessus, sont utilisées les abréviations 
suivantes concernant les conditions de sécurité:  
SC1 ALW OU SM-MAC-G2  
SC2 ALW OU SM-MAC-G1 OU SM-MAC-G2  
SC3 SM-MAC-G1 OU SM-MAC-G2  
SC6 EXT-AUT-G1 OU SM-MAC-G1 OU SM-MAC-G2  
TCS_173 La structure de tous les EF doit être transparente.  
TCS_174 L'application de la carte d'entreprise de génération 1 doit 
avoir la structure de données suivante:
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 252  
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 struc ­
ture des données de la carte d'entreprise pour une applica ­
tion de génération 1:
  
4.5.2  Application de la carte d'entreprise de génération 2  
TCS_176 Après personnalisation, l'application de la carte d'entreprise 
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 court SFID est commu ­
niqué 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 
concernant les conditions de sécurité:  
SC1 ALW OU SM-MAC-G2  
TCS_177 La structure de tous les EF doit être transparente.  
TCS_178 L'application de la carte d'entreprise de génération 2 doit 
avoir la structure de données suivante:
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 253  
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 struc ­
ture des données de la carte d'entreprise pour une applica ­
tion de génération 2:
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 254  
Appendice 3  
PICTOGRAMMES  
PIC_001 Le tachygraphe est susceptible d'employer les pictogrammes et combi ­
naisons de pictogrammes qui suivent (ou des pictogrammes et combi ­
naisons de pictogrammes suffisamment semblables pour être identifia ­
bles à ceux-ci sans ambiguïté):  
1. PICTOGRAMMES DE BASE  
Ressources humaines  Actions  Modes d'exploitation
  
Entreprise  Mode entreprise
  
Contrôleur  Contrôle  Mode de contrôle
  
Conducteur  Route  Mode opérationnel
  
Atelier/Poste d'essai  Inspection/Étalonnage  Mode étalonnage
  
Fabricant  
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 «convoyeur»
  
Carte
  
Horloge
  
Écran  Affichage
  
Mémoire externe  Téléchargement
  
Alimentation
  
Imprimante/Tirage  Impression
  
Capteur
  
Type de pneumatique
  
Véhicule/Unité embarquée sur 
le véhicule (UEV)
  
Dispositif GNSS
  
Dispositif de détection à 
distance
  
Interface STI  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 255  
Conditions spécifiques
  
Hors limites
  
Traversée en ferry/train  
Divers
  
Évènements
  Anomalies
  
Début de la période journalière de 
travail
  Fin de la période journalière de 
travail
  
Adresse
  
Saisie manuelle des activités du 
conducteur
  
Sécurité
  
Vitesse
  
Temps
  
Total/Synthèse  
Qualificatifs  
24h Journalier
  
Hebdomadaire
  
Bihebdomadaire
  
De ou vers  
2. COMBINAISONS DE PICTOGRAMMES  
Divers
  
Lieu du contrôle
  
Site de début de la période de travail 
journalière
  Site de fin de la période de 
travail journalière  
▼M1
 
Position après trois heures de temps 
de conduite accumulé  
▼B
 
De (heure)
  À (heure)
  
Du véhicule
  
Hors limites, début
  Hors limites, fin  
Cartes
  
Carte du conducteur
  
Carte d'entreprise
  
Carte de contrôleur
  
Carte d'atelier
  
Pas de carte  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 256  
Route
  
Conduite en équipage
  
Temps de conduite hebdomadaire
  
Temps de conduite bihebdomadaire  
Tirages
  
Tirage quotidien des activités du conducteur extraites de la carte
  
Tirage quotidien des activités du conducteur extraites 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 autorisée  
Événements
  
Insertion d'une carte erronée
  
Conflit de carte
  
Dépassement du temps imparti
  
Conduite sans carte appropriée
  
Insertion d'une carte en cours de route
  
Clôture incorrecte de la dernière session
  
Dépassement de la vitesse autorisée
  
Coupure d'alimentation électrique
  
Erreur au niveau des données de mouvement
  
Conflit concernant le mouvement du véhicule
  
Atteinte à la sécurité  
▼M1
 
Conflit temporel ou réglage de l’heure (en atelier)  
▼B
 
Contrôle de dépassement de la vitesse autorisée  
▼M1
 
Absence d’informations de positionnement en provenance du récepteur 
GNSS ou Erreur de communication avec le dispositif GNSS externe
  
Erreur de communication avec le dispositif de communication à distance  
▼B 
Défauts
  
Carte défectueuse (logement de carte du conducteur)
  
Carte défectueuse (logement de carte du convoyeur)
  
Anomalie de l'affichage  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 257
  
Anomalie de téléchargement
  
Anomalie de l'imprimante
  
Anomalie du capteur
  
Défaillance interne de la VU
  
Anomalie du dispositif GNSS
  
Anomalie de détection à distance  
Procédure de saisie manuelle
  
Même période journalière de travail?
  
Fin de la période de travail antérieure?
  
Confirmation ou saisie du lieu de fin de la période de travail
  
Saisie de l'heure de départ
  
Saisie du lieu de début de la période de travail.  
Remarque:  diverses combinaisons de pictogrammes supplémentaires 
associées à autant d'identificateurs d'enregistrement ou de blocs d'im ­
pression sont définies à l'appendice 4.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 258  
Appendice 4  
TIRAGES PAPIER  
TABLE DES MATIÈRES  
1. GÉNÉRALITÉS  
2. CARACTÉRISTIQUES DES BLOCS DE DONNÉES  
3. CARACTÉRISTIQUES DES TIRAGES PAPIER  
3.1. Tirage quotidien des activités du conducteur extraites d'une carte  
3.2. Tirage quotidien des activités du conducteur extraites de la VU  
3.3. Tirage des anomalies et événements extraits d'une carte  
3.4. Tirage des anomalies et événements extraits de la VU  
3.5. Tirage des données techniques  
3.6. Tirage des dépassements de la vitesse autorisée  
3.7. Historique des cartes insérées  
1. GÉNÉRALITÉS  
Toute sortie imprimée se compose 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 identificateur d'enregistrement.  
PRT_001 Si un identificateur de bloc précède immédiatement un iden ­
tificateur d'enregistrement, ce dernier n'est pas imprimé.  
PRT_002 Si un élément d'information est inconnu ou ne doit pas être 
imprimé en raison de l'existence de droits d'accès aux 
données, le système imprime des espaces en lieu et place 
de ces éléments.  
PRT_003 Si le contenu d'une ligne complète est inconnu ou ne néces ­
site aucune impression, la ligne correspondante est omise.  
PRT_004 Les champs de données numériques sont justifiés à droite au 
tirage, leur impression s'accompagnant d'espaces de sépara ­
tion marquant le passage des centaines aux milliers et des 
milliers aux millions, sans comporter de zéros en tête.  
PRT_005 Les champs constitués de chaînes de caractères sont justifiés 
à gauche au tirage 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 imprimée doit commencer par un caractère 
spécial (un point à mi-hauteur, «•»).  
2. CARACTÉRISTIQUES DES BLOCS DE DONNÉES  
Dans ce chapitre, les conventions de notation suivantes ont été appli ­
quées:  
— les caractères affichés en  gras  identifient le texte en clair à imprimer 
(au tirage, les caractères sont normaux),  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 259  
— les caractères normaux indiquent à l'affichage des variables (picto ­
grammes ou données) remplacées au tirage par leurs valeurs respec ­
tives,  
— les noms de variable s'accompagnent de traits de soulignement indi ­
quant la longueur élémentaire disponible pour la variable considérée,  
— les dates respectent par défaut le format «jj/mm/aaaa» (jour, mois, 
année). L'application du format «jj.mm.aaaa» est également envisa ­
geable,  
— la rubrique «identification de carte» se compose des éléments 
suivants: type de carte indiqué par une combinaison de picto ­
grammes, code de l'État membre d'émission de la carte, barre 
oblique suivie du numéro de la carte, puis d'un indice de remplace ­
ment 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 
(comprenant, le cas échéant, un indice séquentiel)
 
Indice de 
remplacement  
Indice de renouvellement ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 260  
PRT_007 Les tirages se composent des blocs et/ou enregistrements de données 
qui suivent. Leur signification et leur format sont les suivants:
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 261
  
▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 262
  
► (1) (2) M1 ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 263
  
▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 264
  
▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 265
  
▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 266
  
3. CARACTÉRISTIQUES DES TIRAGES PAPIER  
Dans ce chapitre, les conventions de notation suivantes ont été appli ­
qué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'exige 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 extraites d'une 
carte doit respecter le format suivant: 
1 Date et heure d'impression du document  
2 Type de document imprimé  
3 Identification du contrôleur (en cas d'insertion d'une carte de contrôle 
dans la VU)  
3 Identification du conducteur (extraite de la carte faisant l'objet de 
l'impression + GEN)  
4 Identification du véhicule (à partir duquel le tirage est exécuté)  
5 Identification de la VU (à partir de laquelle le tirage est exécuté + 
GEN)  
6 Dernier étalonnage de cette VU  
7 Dernier contrôle auquel le conducteur inspecté a été soumis  
8 Délimiteur des activités du conducteur  
8a Condition hors champ au début de cette journée  
8.1a / 8.1b / 8.1c / 8.2 / 
8.3 / 8.3a / 8.4  Activités du conducteur par ordre chronologique  
11 Délimiteur de synthèse quotidienne  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 267  
11.4 Lieux saisis par ordre chronologique  
▼M1 
11.5 Positions après trois heures de temps de conduite accumulé par ordre 
chronologique  
▼B 
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 enregistré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 enregistré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 extraites de la 
VU doit respecter le format suivant:  
▼M1 
1 Date et heure d’impression du document  
2 Type de document imprimé  
3 Identification du titulaire de la carte (pour toutes les cartes 
insérées dans la VU + GEN)  
4 Identification du véhicule (à partir duquel le tirage est 
exécuté)  
5 Identification de la VU (à partir de laquelle le tirage est 
exécuté + GEN)  
6 Dernier étalonnage de cette VU  
7 Dernier contrôle auquel ce tachygraphe a été soumis  
9 Délimiteur des activités du conducteur  
10 Délimiteur de lecteur de carte du conducteur (lecteur 1)  
10a Condition hors champ au début de cette journée  
10.1 / 10.2 / 10.3 / 
10.3a / 10.4  Activités par ordre chronologique (lecteur conducteur)  
10 Délimiteur de lecteur de carte du convoyeur (lecteur 2)  
10a Condition hors champ au début de cette journée  
10.1 / 10.2 / 10.3 / 
10.3a / 10.4  Activités par ordre chronologique (lecteur convoyeur)  
11 Délimiteur de synthèse quotidienne  
11.1 Synthèse des périodes sans carte dans le lecteur du conduc ­
teur ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 268  
11.4 Lieux saisis par ordre chronologique  
11.5 Positions après trois heures de temps de conduite accumulé 
par ordre chronologique  
11.7 Totaux par activité  
11.2 Synthèse des périodes sans carte dans le lecteur du 
convoyeur  
11.4 Lieux saisis par ordre chronologique  
11.5 Positions après trois heures de temps de conduite accumulé 
par ordre chronologique  
11.8 Totaux par activité  
11.3 Synthèse des activités par conducteur, les deux lecteurs étant 
inclus  
11.4 Lieux saisis par ce conducteur, par ordre chronologique  
11.5 Positions après trois heures de temps de conduite accumulé 
par ordre chronologique  
11.9 Totaux par activité pour ce conducteur  
13.1 Délimiteur d’événements et d’anomalies  
13.4 Enregistrements d’événements/anomalies (5 derniers événe ­
ments ou anomalies enregistrés ou en cours dans la VU)  
22.1 Lieu du contrôle  
22.2 Signature du contrôleur  
22.3 De (heure)  
22.4 À (heure) (espace disponible pour un conducteur dépourvu 
de carte lui permettant d’indiquer les périodes qui corres ­
pondent à ses prestations)  
22.5 Signature du conducteur  
▼B 
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'impression du document  
2 Type de document imprimé  
3 Identification du contrôleur (en cas d'insertion d'une carte de contrôle 
dans la VU + GEN)  
3 Identification du conducteur (extraite de la carte faisant l'objet de 
l'impression)  
4 Identification 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 (toutes les anomalies enregistrées sur la 
carte)  
22.1 Lieu du contrôle  
22.2 Signature du contrôleur  
22.5 Signature du conducteur  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 269  
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 
respecter le format suivant: 
1 Date et heure d'impression du document  
2 Type de document imprimé  
3 Identification du titulaire de la carte (pour toutes les cartes insérées 
dans la VU + GEN)  
4 Identification du véhicule (à partir duquel le tirage est exécuté)  
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 respecter le format 
suivant: 
1 Date et heure d'impression du document  
2 Type de document imprimé  
3 Identification du titulaire de la carte (pour toutes les cartes insérées 
dans la VU + GEN)  
4 Identification du véhicule (à partir duquel le tirage est exécuté)  
14 Identification de la VU  
15 Identification des capteurs  
15.1 Données relatives au couplage des capteurs (toutes les données dispo ­
nibles, par ordre chronologique)  
16 Identification du GNSS  
16.1 Données relatives au couplage du dispositif GNSS externe (toutes les 
données disponibles, par ordre chronologique)  
17 Délimiteur des données d'étalonnage  
17.1 Enregistrements d'étalonnage (ensemble des enregistrements disponi ­
bles par ordre chronologique)  
18 Délimiteur de la remise à l'heure  
18.1 Enregistrement de la remise à l'heure (ensemble des enregistrements 
disponibles, extraits des enregistrements de la remise à l'heure et des 
données d'étalonnage)  
19 Événement et anomalie les plus récents enregistrés dans la VU  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 270  
3.6. Tirage des dépassements de la vitesse autorisée  
PRT_013 Le tirage des dépassements de la vitesse autorisée doit 
respecter le format suivant: 
1 Date et heure d'impression du document  
2 Type de document imprimé  
3 Identification du titulaire de la carte (pour toutes les cartes insérées 
dans la VU + GEN)  
4 Identification du véhicule (à partir duquel le tirage est exécuté)  
20 Informations relatives au contrôle de dépassement de la vitesse auto ­
risée  
21.1 Identificateur des données de dépassement de la vitesse autorisée  
21.4 / 21.5  Premier dépassement de la vitesse autorisée après le dernier étalon ­
nage  
21.2 Identificateur des données de dépassement de la vitesse autorisé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 Identificateur des données de dépassement de la vitesse autorisée  
21.4 / 21.5  Le dépassement le plus sérieux pour chacune des périodes coïncidant 
avec les dix derniers jours de manifestation  
22.1 Lieu du contrôle  
22.2 Signature du contrôleur  
22.5 Signature du conducteur  
3.7. Historique des cartes insérées  
▼M1 
PRT_014 Le tirage de l’historique des cartes insérées doit respecter le 
format suivant: 
1 Date et heure d’impression du document  
2 Type de document imprimé  
3 Identifications du titulaire de la carte (pour toutes les cartes insérées 
dans la VU)  
23 Cartes les plus récentes insérées dans la VU  
23.1 Cartes insérées (jusqu’à 88 enregistrements)  
12.3 Délimiteur des anomalies  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 271  
Appendice 5  
AFFICHAGE  
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 carac ­
tères normaux),  
— les caractères normaux indiquent des variables (pictogrammes ou données) à 
remplacer par leurs valeurs respectives à l'affichage:  
— 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'anoma ­
lie, 
— O: pictogramme de mode d'exploitation.  
DIS_001 Le tachygraphe emploie les formats d'affichage des données suivants:  
Données  Format  
Affichage par défaut  
Heure locale
  
Mode d'exploitation
  
Informations relatives au conducteur
  
Informations relatives au convoyeur
  
Condition hors limites
  
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 
conducteur
  
Temps de conduite continue et temps de pause cumulé du 
convoyeur
  
Temps de conduite cumulé du conducteur, enregistré 
pendant la semaine en cours et la semaine précédente
  
Temps de conduite cumulé du convoyeur, enregistré 
pendant la semaine en cours et la semaine précédente
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 272  
Appendice 6  
CONNECTEUR FRONTAL POUR L'ÉTALONNAGE ET LE 
TÉLÉCHARGEMENT  
TABLE DES MATIÈRES  
1. MATÉRIEL  
1.1. Connecteur  
1.2. Affectation des contacts  
1.3. Schéma fonctionnel  
2. INTERFACE DE TÉLÉCHARGEMENT  
3. INTERFACE D'ÉTALONNAGE  
1. MATÉRIEL  
1.1. Connecteur  
INT_001 Le connecteur de téléchargement/étalonnage doit se présenter 
sous la forme d'un connecteur à 6 broches, accessible sur la 
face avant sans nécessiter la déconnexion d'aucun organe du 
tachygraphe. Il doit être conforme au plan suivant (toutes les 
cotes sont en millimètres):
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 273  
Le schéma suivant illustre une fiche classique d'accouplement à 
6 broches:
  
1.2. Affectation des contacts  
INT_002 L'affectation des contacts doit être conforme au tableau suivant:  
Pin Description  Remarque  
1 Pôle négatif de la batterie  Raccordé à la borne négative de la batterie montée sur le 
véhicule  
2 Communication de données  Ligne K (ISO 14230-1)  
3 RxD — Téléchargement  Entrée de données dans le tachygraphe  
4 Signal d'entrée/sortie  Étalonnage  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 274  
Pin Description  Remarque  
5 Puissance de sortie perma ­
nente  La plage de tensions doit être identique à celle de l'alimen ­
tation électrique du véhicule diminuée de 3 V afin de tenir 
compte de la chute de tension inhérente au passage du 
courant à travers les circuits de protection 
Sortie 40 mA  
6 TxD — Téléchargement  Sortie de données du tachygraphe  
1.3. Schéma fonctionnel  
INT_003 Le schéma fonctionnel doit être conforme aux indications 
suivantes:
  
2. INTERFACE DE TÉLÉCHARGEMENT  
INT_004 L ' interface de téléchargement doit être conforme aux spécifi ­
cations de la norme RS232.  
INT_005 L'interface de téléchargement doit utiliser un bit de départ, huit 
bits d'information (bit le moins significatif en tête), un bit de 
parité pair et un bit d'arrêt.
  
Agencement d'un octet d'information  
Bit de départ: un bit de niveau logique 0;  
Bits d'information: transmis avec le bit le moins significatif en tête;  
Bit de parité: parité paire  
Bit d'arrêt: un bit de niveau logique 1;  
En cas de transmission de données numériques composées de plus d'un 
octet, l'octet le plus significatif est transmis en premier, l'octet le moins 
significatif en dernier.  
INT_006 Les débits de transmission doivent être réglables dans une plage 
comprise entre 9 600 et 115 200 bits par seconde. Toute trans ­
mission 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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 275  
3. INTERFACE D'ÉTALONNAGE  
INT_007 La communication de données doit être conforme aux spécifica ­
tions de la norme ISO 14230-1 Véhicules routiers — Systèmes 
de diagnostic — Protocole à mots clés 2000 — Partie 1: Couche 
physique. Première édition: 1999.  
INT_008 Le signal d'entrée/sortie doit être conforme aux spécifications 
électriques 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 (sortie)  1,0 V  I = 1 mA  
U high (sortie)  4 V  I = 1 mA  
INT_009 Le signal d'entrée/sortie doit être conforme aux chronogrammes 
suivants:
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 276  
Appendice 7  
PROTOCOLES DE TÉLÉCHARGEMENT DE DONNÉES  
TABLE DES MATIÈRES  
1. INTRODUCTION  
1.1. Champ d’application  
1.2. Abréviations et notations  
2. TÉLÉCHARGEMENT DE DONNÉES SUR LA VU  
2.1. Procédure de téléchargement  
2.2. Protocole de téléchargement des données  
2.2.1 Structure des messages  
2.2.2 Types de message  
2.2.2.1 Start Communication Request (SID 81)  
2.2.2.2 Positive Response Start Communication (SID C1)  
2.2.2.3 Start Diagnostic Session Request (SID 10)  
2.2.2.4 Positive Response Start Diagnostic (SID 50)  
2.2.2.5 Link Control Service (SID 87)  
2.2.2.6 Link Control Positive Response (SID C7)  
2.2.2.7 Request Upload (SID 35)  
2.2.2.8 Positive Response Request Upload (SID 75)  
2.2.2.9 Transfer Data Request (SID 36)  
2.2.2.10 Positive Response Transfer Data (SID 76)  
2.2.2.11 Request Transfer Exit (SID 37)  
2.2.2.12 Positive Response Request Transfer Exit (SID 77)  
2.2.2.13 Stop Communication Request (SID 82)  
2.2.2.14 Positive Response Stop Communication (SID C2)  
2.2.2.15 Acknowledge Sub Message (SID 83)  
2.2.2.16 Negative Response (SID 7F)  
2.2.3 Acheminement des messages  
2.2.4 Synchronisation  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 277  
2.2.5 Traitement des erreurs  
2.2.5.1 Phase d'établissement de la communication  
2.2.5.2 Phase de communication  
2.2.6 Contenu des messages de réponse  
2.2.6.1 Positive Response Transfer Data Overview  
2.2.6.2 Positive Response Transfer Data Activities  
2.2.6.3 Réponse positive à une demande de transfert de données relatives aux 
évènements et anomalies  
2.2.6.4 Positive Response Transfer Data Detailed Speed  
2.2.6.5 Positive Response Transfer Data Technical Data  
2.3. Archivage de fichiers sur un support de mémoire externe  
3. PROTOCOLE DE TÉLÉCHARGEMENT DES CARTES TACHY ­ 
GRAPHIQUES  
3.1. Champ d'application  
3.2. Définitions  
3.3. Téléchargement d'une carte  
3.3.1 Séquence d'initialisation  
3.3.2 Séquence de téléchargement des fichiers de données non signés  
3.3.3 Séquence de téléchargement des fichiers de données signés  
3.3.4 Séquence de réinitialisation d'un compteur d'étalonnage.  
3.4. Format d'archivage des données  
3.4.1 Introduction  
3.4.2 Format des fichiers  
4. TÉLÉCHARGEMENT D'UNE CARTE TACHYGRAPHIQUE PAR 
L'INTERMÉDIAIRE D'UNE UNITÉ EMBARQUÉE SUR VÉHI ­ 
CULE.  
1. INTRODUCTION  
Le présent appendice traite des procédures qu'il convient d'appliquer 
pour exécuter les différents types de téléchargement de données vers un 
support de mémoire externe. Il traite également des protocoles qu'il y a 
lieu de mettre en œuvre pour assurer un transfert de données correct et 
garantir la parfaite compatibilité des données téléchargées afin de 
permettre à tout contrôleur d'inspecter ces données en s'assurant de 
leur authenticité et de leur intégrité avant de procéder à leur analyse 
éventuelle.  
▼M1 
1.1. Champ d’application  
Certaines données sont susceptibles d’être téléchargées vers un support 
de mémoire externe (ESM):  
— à partir d’une unité embarquée sur véhicule (VU) par l’inter ­
médiaire d’un équipement spécialisé intelligent (IDE) raccordé à 
la VU,  
— à partir d’une carte tachygraphique par l’intermédiaire d’un IDE 
équipé d’un périphérique de lecture de carte (IFD),  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 278  
— à partir d’une carte tachygraphique par l’intermé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échargées qui auraient été sauvegardées sur un ESM, ces 
données s’accompagnent d’une signature conforme à l’appendice 11 
(Mécanismes de sécurité communs). L’identification de l’équipement 
source (VU ou carte) et ses certificats de sécurité (État membre et 
équipement) sont également téléchargés. Le vérificateur doit être en 
possession d’une clé publique européenne sécurisée.  
Les données téléchargées à partir d’une VU sont signées conformément 
aux dispositions de l’appendice 11, Mécanismes de sécurité communs, 
partie B (tachygraphe de deuxième génération), excepté lorsque le 
contrôle des conducteurs est effectué par des autorités de contrôle 
autres que celles de l’UE, au moyen d’une carte de contrôle de 
première génération, auquel cas les données sont signées conformément 
aux dispositions de l’appendice 11, Mécanismes de sécurité communs, 
partie A (tachygraphe de première génération), conformément à l’ap ­
pendice 15 Migration, exigence MIG_015.  
Cet appendice spécifie dès lors deux types de téléchargements de 
données à partir de la VU:  
— téléchargement de données de la VU de génération 2, fournissant la 
structure de données de génération 2 et signées conformément aux 
dispositions de l’appendice 11, Mécanismes de sécurité communs, 
partie B,  
— téléchargement de données de la VU de génération 1, fournissant la 
structure de données de génération 1 et signées conformément aux 
dispositions de l’appendice 11, Mécanismes de sécurité communs, 
partie A,  
De même, on distingue deux types de téléchargements de données à 
partir de cartes de conducteur de deuxième génération insérées dans 
une VU, comme indiqué aux paragraphes 3 et 4 du présent appendice.  
▼B 
1.2. Abréviations et notations  
Les abréviations qui suivent apparaissent dans le présent appendice:  
AID Identifiant 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 ( Elementary File ) 
ESM  Support de mémoire externe ( External Storage Medium ) 
FID Identificateur de fichier ( File Identifier ) 
FMT  Octet de structure (premier octet de l'en-tête d'un message) 
(Format Byte ) 
ICC Carte à circuit intégré ( Integrated Circuit Card ) 
IDE Équipement spécialisé intelligent: équipement servant à télé ­
charger des données vers l'ESM (par exemple, le PC) ( Intelli­
gent Dedicated Equipment ) 
IFD Périphérique d'interface ( Interface Device ) 
KWP  Protocole à mots clés ( Keyword Protocol ) 2000  
LEN  Octet de longueur (dernier octet de l'en-tête 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écurité ( Perform Security 
Operation ) 
SID Identificateur de service ( Service Identifier ) 
SRC  Octet source ( Source byte ) 
TGT  Octet cible ( Target byte ) ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 279  
TLV  Longueur des balises ( Tag Length Value ) 
TREP  Paramètre de réponse du transfert ( Transfer Response Parame ­
ter) 
TRTP  Paramètre de demande du transfert ( Transfer Request Parame ­
ter) 
VU Unité embarquée sur le véhicule ( Vehicle Unit ) 
2. TÉLÉCHARGEMENT DE DONNÉES SUR LA VU  
2.1. Procédure de téléchargement  
Pour procéder au téléchargement de données sur la VU, l'opérateur doit 
exécuter les opérations suivantes:  
— introduire la carte de tachygraphe qu'il détient dans la fente de l'un 
des lecteurs de carte de la VU (*);  
— raccorder l'IDE au connecteur de téléchargement de la VU;  
— établir la liaison entre l'IDE et la VU;  
— sélectionner sur l'IDE les données à télécharger et envoyer la 
requête à la VU;  
— clôturer la session de téléchargement.  
2.2. Protocole 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é asservie.  
La structure des messages, leur type et leur acheminement sont essen ­
tiellement basés sur le protocole à mots clés 2000 ( KWP) (ISO 14230- 
2 Véhicules routiers — Systèmes de diagnostic — Protocole à mots 
clés 2000 — Partie 2: Couche de liaison de données).  
La couche 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 messages  
DDP_002 Tous les messages échangés entre l'IDE et la VU se carac ­
térisent par une structure à trois éléments.  
— En-tête composé 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'identification 
de service (SID) et d'un nombre variable d'octets d'in ­
formation qui peuvent comprendre un octet optionnel de 
session de diagnostic (DS_) ou un octet optionnel de 
paramètre de transfert (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  
Les octets TGT et SRC représentent les adresses physiques 
du destinataire et de l'expéditeur du message. Ils prennent 
les valeurs F0 Hex pour l'IDE et EE Hex pour la VU.  
L'octet LEN indique la longueur du champ de données.  ▼B 
(*) L'insertion de la carte déclenche l'activation des droits d'accès appropriés tant aux 
données qu'à la fonction de téléchargement. Il est toutefois possible de télécharger 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.
 02016R0799 — FR — 26.02.2020 — 002.001 — 280  
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'exclusion 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 docu ­
ment.  
DDP_003 Si la longueur des données que le message est censé véhi ­
culer est supérieure à l'espace disponible dans la partie 
champ de données, l'envoi de ce message prend la forme 
de plusieurs sous-messages. Chacun de ces sous-messages 
comporte un en-tête, les mêmes SID et TREP ainsi qu'un 
compteur de sous-messages 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 échange de données, l'IDE accuse réception de chaque 
sous-message. L'IDE est à même d'accepter 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 
exactement 255 octets, il est indispensable d'adjoindre à 
l'ensemble un sous-message final comportant un champ de 
données vide (à l'exception des SID, TREP et compteur de 
sous-messages) pour indiquer la fin du message.  
Exemple:  
En-tête  SID  TREP  Message  CS  
4 octets  Longueur supérieure à 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  
… 
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  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 281  
2.2.2  Types de messages  
Le protocole de communication qui s'applique au téléchargement de 
données entre la VU et l'IDE réclame l'échange de 8 types de messages 
distincts.  
La table qui suit en présente une synthèse.  
▼M1 
Structure du message  4 octets max. En-tête  255 octets max. Données  1 octet 
Total de 
contrôle  
IDE ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  DONNÉES  CS  
Demande d’établissement de la 
communication  81 EE  F0  81  E0  
Réponse positive à une 
demande d’établissement 
de la communication  80 F0  EE  03  C1  EA, 8F  9B  
Demande d’ouverture d’une 
session 
de diagnostic  80 EE  F0  02  10  81  F1  
Réponse positive à une demande 
d’ouverture de session 
de diagnostic  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échargement 
(upload)  80 EE  F0  0A  35  00,00,00, 
00,00,FF,FF, 
FF,FF  99 
Réponse positive à une demande 
de téléchargement  80 F0  EE  03  75  00,FF  D5  
Demande de transfert de 
données  
Récapitulatif  80  EE  F0  02  36  01 ou 21  97  
Activités  80  EE  F0  06  36  02 ou 22  Date  CS  
Événements et anomalies  80  EE  F0  02  36  03 ou 23  Date  99  
Vitesse instantanée  80  EE  F0  02  36  04 ou 24  Date  9A  
Données techniques  80  EE  F0  02  36  05 ou 25  Date  9B  
Téléchargement (download) 
d’une carte  80 EE  F0  02  36  06  Lecteur  CS  
Réponse positive à une demande 
de transfert de données  80 F0  EE  Len  76  TREP  Données  CS  
Demande de fin de transfert  80  EE  F0  01  37  96  
Réponse positive à une demande 
de fin de transfert  80 F0  EE  01  77  D6  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 282  
Structure du message  4 octets max. En-tête  255 octets max. Données  1 octet 
Total de 
contrôle  
IDE ->  <- VU  FMT  TGT  SRC  LEN  SID  DS_ / TRTP  DONNÉES  CS  
Demande d’arrêt de la commu ­
nication  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- 
message  80 EE  F0  Len  83  Données  CS  
Réponses négatives  
Téléchargement (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-fonction incompatible  80  F0  EE  03  7F  Sid Req  12  CS  
Longueur du message incorrecte  80  F0  EE  03  7F  Sid Req  13  CS  
Conditions non correctes ou 
erreur affectant la séquence 
d’interrogation  80 F0  EE  03  7F  Sid Req  22  CS  
Demande excessive  80  F0  EE  03  7F  Sid Req  31  CS  
Téléchargement (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  
▼B 
Remarques:  
▼M1 
— Les TRTP 21 à 25 sont utilisés pour les demandes de télécharge ­
ment de données de la VU de génération 2, les TRTP 01 à 05 sont 
utilisés pour les demandes de téléchargement de données de la VU 
de génération 1, qui ne peuvent être acceptées par la VU que dans 
le cadre des contrôles des conducteurs effectués par des autorités de 
contrôle autres que celles de l’UE, au moyen d’une carte de 
contrôle de première génération.  
— Les TRTP 11 à 19 et 31 à 39 sont réservés aux demandes de 
téléchargement propres au fabricant.  
▼B 
— 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 terme «upload» (considéré à partir de l'IDE) s'im ­
pose 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 compteur potentiel 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 lecteur du convoyeur).  
— 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.  
2.2.2.1 D e m a n d e d ' é t a b l i s s e m e n t d e l a c o m m u n i c a t i o n 
( S I D 8 1 )  
DDP_005 Ce message est émis par l'IDE pour établir la liaison d'inter ­
communication 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 appropriés de 
contrôle des liaisons).  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 283  
2.2.2.2 R é p o n s e p o s i t i v e à u n e d e m a n d e d ' é t a b l i s s e m e n t 
d e l a c o m m u n i c a t i o n ( S I D C 1 )  
DDP_006 La VU émet ce message pour répondre positivement à une 
demande d'établissement de la communication. Il comporte 
les deux octets clés «EA» ‘8F’ indiquant que l'unité corres ­
pondante prend en charge le protocole concerné, l'en-tête de 
chaque message incluant les octets cible, source et longueur.  
2.2.2.3 D e m a n d e d ' o u v e r t u r e d ' u n e s e s s i o n d e d i a g n o s t i c 
( S I D 1 0 )  
DDP_007 L'IDE émet un message de demande d'ouverture d'une 
session de diagnostic dans le but de solliciter une nouvelle 
session de diagnostic avec la VU. La sous-fonction «session 
par défaut» (81 Hex) indique qu'une session de diagnostic 
standard va être ouverte.  
2.2.2.4 R é p o n s e p o s i t i v e à u n e d e m a n d e d ' o u v e r t u r e d e 
s e s s i o n d e d i a g n o s t i c ( S I D 5 0 )  
DDP_008 La VU émet un message de réponse positive à une demande 
de diagnostic pour répondre positivement à une demande 
d'ouverture d'une session de diagnostic.  
2.2.2.5 S e r v i c e d e c o n t r ô l e d e l i a i s o n ( S I D 8 7 )  
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 
comporte deux étapes. Dans la première étape, l'IDE 
propose une modification du débit en bauds, en indiquant 
le nouveau débit. À la réception d'un message positif de la 
VU, l'IDE envoie la confirmation du changement 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 confirmation, 
la VU passe au nouveau débit en bauds.  
2.2.2.6 R é p o n s e p o s i t i v e a u c o n t r ô l e d e l i a i s o n ( S I D C 7 )  
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). À noter qu'aucune réponse n'est donnée à la 
demande de confirmation (deuxième étape).  
2.2.2.7 D e m a n d e d e t é l é c h a r g e m e n t ( u p l o a d ) ( S I D 3 5 )  
DDP_009 L'IDE émet un message de demande de téléchargement afin 
de préciser à la VU qu'il réclame l'exécution d'une opération 
de téléchargement. Afin de satisfaire aux exigences de la 
norme ISO 14229, des données sont incluses concernant 
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échargement, l'adresse de mémoire est 
mise à 0, la structure est non cryptée et non compressée et 
la taille de la mémoire est mise au maximum.  
2.2.2.8 R é p o n s e p o s i t i v e à u n e d e m a n d e d e t é l é c h a r g e m e n t 
( S I D 7 5 )  
DDP_010 La VU émet un message de réponse positive à une demande 
de téléchargement pour signifier à l'IDE que la VU est prête 
à télécharger des données. Afin de satisfaire aux exigences 
de la norme ISO 14229, le message de réponse positive 
comprend des données indiquant à l'IDE que les messages 
ultérieurs de réponse positive à une demande de transfert de 
données comporteront au maximum 00FF hex octets.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 284  
2.2.2.9 D e m a n d e d e t r a n s f e r t d e d o n n é e s ( S I D 3 6 )  
▼M1 
DDP_011 L’IDE émet une demande de transfert de données afin de 
préciser à la VU la nature des données à télécharger. Un 
paramètre de demande de transfert (TRTP) d’un octet 
indique de quel type de transfert il s’agit.  
Il existe six types de transfert de données. Pour les téléchar ­
gements de données de la VU, deux différentes valeurs 
TRTP peuvent être utilisées pour chaque type de transfert:  
Type de transfert de 
données  Valeur de TRTP 
pour les télécharge ­
ments de données de 
la VU de génération 
1 Valeur de TRTP 
pour les télécharge ­
ments de données de 
la VU de génération 
2 
Récapitulatif  01  21  
Activités associées 
à une date précise  02 22  
Événements et 
anomalies  03 23  
Vitesse instanta ­
née 04 24  
Données techni ­
ques 05 25  
Type de transfert 
de données  Valeur de TRTP  
Téléchargement 
de carte  06 
DDP_054 Il est obligatoire pour l’IDE de demander un transfert de 
données du type «récapitulatif» (TRTP 01 ou 21) au cours 
d’une session de téléchargement, car cela seul garantit que 
les certificats de la VU sont enregistrés sur le fichier télé ­
chargé (et permet ainsi la vérification de la signature numé ­
rique).  
Dans le deuxième cas de figure (TRTP 02 ou 22), le 
message de demande de transfert de données comporte l’in ­
dication du jour civil (format
  ) auquel le 
téléchargement est associé.  
▼B 
2.2.2.10 R é p o n s e p o s i t i v e à u n e d e m a n d e d e t r a n s f e r t d e 
d o n n é e s ( S I D 7 6 )  
DDP_012 La VU émet un message de réponse positive à une demande 
de transfert 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 transfert 
(TREP) correspondant à celui de la demande.  
▼M1 
DDP_055 Dans le premier cas (TREP 01 ou 21), la VU enverra des 
données destinées à aider l’opérateur de l’IDE dans le choix 
des données qu’ils souhaitent télécharger. Les informations 
contenues dans ce message sont les suivantes:  
— Certificats de sécurité,  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 285  
— Identification du véhicule,  
— Date et heure actuelles sur la VU,  
— Date la plus précoce et la plus tardive pour le téléchar ­
gement (données de la VU),  
— Indications concernant la présence de cartes dans la VU,  
— Téléchargements antérieurs vers une entreprise,  
— Verrouillages d’entreprise,  
— Contrôles précédents.  
▼B 
2.2.2.11 D e m a n d e d e f i n d e t r a n s f e r t ( S I D 3 7 )  
DDP_013 L'IDE émet un message de demande de fin de transfert pour 
informer la VU que la session de téléchargement est termi ­
née. 
2.2.2.12 R é p o n s e p o s i t i v e à u n e d e m a n d e d e f i n d e t r a n s f e r t 
( S I D 7 7 )  
DDP_014 La VU émet un message de réponse positive à une demande 
de fin de transfert pour accuser réception de la demande de 
fin de transfert.  
2.2.2.13 D e m a n d e d ' a r r ê t d e l a c o m m u n i c a t i o n ( S I D 8 2 )  
DDP_015 L'IDE émet un message de demande d'arrêt de la commu ­
nication dans le but de rompre la liaison d'intercommunica ­
tion avec la VU.  
2.2.2.14 R é p o n s e p o s i t i v e à u n e d e m a n d e d ' a r r ê t d e l a 
c o m m u n i c a t i o n ( S I D C 2 )  
DDP_016 La VU émet un message 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 A c c u s é d e r é c e p t i o n d ' u n s o u s - m e s s a g e ( S I D 8 3 )  
DDP_017 L'IDE émet un accusé de réception de sous-message pour 
confirmer la réception des différentes parties d'un message 
transmis sous forme de sous-messages. Le champ 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'envoi du sous-message suivant adressée à la 
VU par l'IDE  
— MsgC indique la manifestation d'un problème affectant 
la réception du sous-message numéro MsgC.  
Demande de renvoi du sous-message concerné adressée 
à la VU par l'IDE.  
— FFFF réclame l'interruption du message en cours de 
transmission.  
L'IDE peut recourir à ce code pour mettre un terme à 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éception du dernier 
sous-message d'un message quelconque (octet LEN < 255) 
en recourant ou non à l'un quelconque de ces codes.  
Composée de plusieurs sous-messages, la réponse de la VU 
s'énonce comme suit:  
— Réponse positive à une demande de transfert de données 
(SID 76)  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 286  
2.2.2.16 R é p o n s e s n é g a t i v e s ( S I D 7 F )  
DDP_018 La VU émet le message de réponse négative en réponse aux 
messages ci-dessus si elle s'avère dans l'impossibilité de 
satisfaire à la demande transmise. Les champs de données 
du message 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égative. Les codes suivants sont d'application:  
— 10 téléchargement (général) refusé  
L'opération ne peut être exécutée pour une raison qui 
n'est pas abordée ci-après.  
— 11 service incompatible  
Le SID de la demande n'est pas intelligible à la VU.  
— 12 sous-fonction incompatible  
Le DS_ ou le TRTP de la demande ne sont pas intelli ­
gibles à la VU ou la transmission des sous-messages est 
arrivée à son terme.  
— 13 longueur du message incorrecte  
La longueur du message reçu est incorrecte.  
— 22 conditions non correctes ou erreur affectant la 
séquence d'interrogation  
Le service demandé n'est pas disponible ou la séquence 
des messages de demande est incorrecte.  
— 31 demande excessive  
Le relevé (champ de données) du paramètre de la 
demande n'est pas valable.  
— 50 téléchargement (upload) refusé  
La demande ne peut être exécutée (la VU est exploitée 
dans un mode inapproprié ou elle présente une anomalie 
interne).  
— 78 réponse en suspens  
L'action réclamée ne peut être achevée dans le temps 
imparti et la VU n'est pas prête à accepter une autre 
demande.  
▼M1 
— FA données indisponibles  
L’objet d’une demande de transfert de données n’est pas 
accessible au sein de la VU (p. ex. absence d’insertion 
de carte, téléchargement de données de la VU de géné ­
ration 1 demandé en dehors du cadre du contrôle d’un 
conducteur par une autorité de contrôle autre qu'une 
autorité de contrôle de l’UE, etc.).  
▼B 
2.2.3  Acheminement des messages  
Pendant une procédure de téléchargement normale, l'acheminement des 
messages s'effectue habituellement comme suit:  
IDE VU  
Demande d'établissement de la communication  ⇨ 
⇦  Réponse positive  
Demande d'ouverture d'une session de diagnos ­
tict ⇨ 
⇦  Réponse positive  
Demande de téléchargement (upload)  ⇨ 
⇦  Réponse positive  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 287  
IDE VU  
Demande de transfert de données — Récapitu ­
latif ⇨ 
⇦  Réponse positive  
Demande de transfert de données #2  ⇨ 
⇦  Réponse positive #1  
Accusé de réception d'un sous-message #1  ⇨ 
⇦  Réponse positive #2  
Accusé de réception d'un sous-message #2  ⇨ 
⇦  Réponse positive #m  
Accusé de réception d'un sous-message #m  ⇨ 
⇦  Réponse positive (champ de données < 255 
octets)  
Accusé de réception d'un sous-message (facul ­
tatif) ⇨  
… 
Demande de transfert de données #n  ⇨ 
⇦  Réponse positive  
Demande de fin de transfert  ⇨ 
⇦  Réponse positive  
Demande d'arrêt de la communication  ⇨ 
⇦  Réponse positive  
2.2.4  Synchronisation  
DDP_019 Dans des conditions d'exploitation normales, les paramètres 
de synchronisation dont la figure ci-après fournit l'illustra ­
tion sont d'application:  
Figure 1  
Acheminement des messages, synchronisation
  
Où: 
P1 = Temps interoctet caractérisant 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éception 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 interoctet caractérisant une demande de l'IDE.  
P5 = Valeur étendue de P3 pour le téléchargement de 
cartes.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 288  
Le tableau ci-après présente les valeurs que les paramètres 
de synchronisation sont susceptibles de prendre (jeu étendu 
de paramètres de synchronisation 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érieure 
(en ms)  
P1 0  20  
P2 20  1 000 (*)  
P3 10  5 000  
P4 5  20  
P5 10  20 minutes  
(*) 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érieure 
que celle de P3.  
2.2.5  Traitement des erreurs  
Si une erreur se manifeste pendant l'échange de messages, le plan 
d'acheminement des messages est modifié 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 traitement d'erreur appli ­
quées respectivement à la VU et à l'IDE.  
2.2.5.1 P h a s e d ' é t a b l i s s e m e n t d e l a c o m m u n i c a t i o n  
DDP_020 Si l'IDE détecte une erreur au cours de la phase d'établisse ­
ment de la communication, tant au niveau de la synchroni ­
sation 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étecte une erreur dans la séquence provenant de 
l'IDE, celle-ci n'envoie aucune réponse; elle attend un autre 
message de demande d'établissement de la communication 
dans un délai P3max.  
2.2.5.2 P h a s e d e c o m m u n i c a t i o n  
Deux procédures de traitement d'erreur distinctes peuvent être définies:  
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 toute erreur éventuelle de synchronisation, de 
structure des octets (p. ex. violations affectant les bits de 
départ et d'arrêt) ou de perte de verrouillage de trame 
(réception d'un nombre erroné d'octets, octet total de 
contrôle erroné).  
DDP_023 Si la VU détecte l'une des erreurs susmentionnées, elle 
n'envoie aucune réponse et ne tient aucun compte du 
message reçu.  
DDP_024 La VU peut détecter d'autres erreurs dans le format ou le 
contenu du message reçu (p. ex. un message incompati ­
ble), même si le message satisfait aux exigences de 
longueur et de contrôle du total; dans ce cas, la VU 
répond à l'IDE par un message de réponse négatif préci ­
sant la nature de l'erreur.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 289  
Figure 2  
Traitement d'erreur au niveau de la VU
  
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 toute erreur éventuelle de synchronisation, de 
structure des octets (p. ex. violations affectant les bits 
de départ et d'arrêt) ou de perte de verrouillage de 
trame (réception d'un nombre erroné d'octets, octet total 
de contrôle erroné).  
DDP_026 L'IDE détecte les erreurs de séquence telles que l'incré ­
mentation incorrecte du compteur de sous-messages que 
comportent 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 message de 
demande concerné sera renvoyé à trois reprises au 
maximum à l'unité destinataire. Aux fins de cette détec ­
tion d'erreurs, tout accusé de réception d'un sous-message 
quelconque sera considéré comme une demande adressée 
à la VU.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 290  
DDP_028 L'IDE attend au moins une période de P3min avant d'en ­
tamer chaque transmission; la période d'attente se mesure 
depuis la dernière occurrence calculée d'un bit d'arrêt 
suivant la détection d'erreur.  
Figure3  
Traitement d'erreur au niveau de l'IDE
  
2.2.6  Contenu des messages de réponse  
Ce paragraphe traite du contenu des champs de données que compor ­
tent les différents messages de réponse positive.  
Les éléments d'information sont définis dans l'appendice 1 (Diction ­
naire de données).  
Remarque: concernant les téléchargements de génération 2, toutes les 
données de niveau supérieur 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ébute 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 inti ­
tulés «…RecordArray» (avec en-tête) dans les tableaux suivants.  
2.2.6.1 R é p o n s e p o s i t i v e à u n r é c a p i t u l a t i f d e t r a n s f e r t d e 
d o n n é e s  
DDP_029  ►M1 Le champ de données du message «Réponse positive 
à un récapitulatif de transfert de données» doit fournir les 
données ci-après dans l’ordre qui suit en vertu des SID 76 
Hex, TREP 01 ou 21 Hex et critères appropriés de sépara ­
tion et de comptage des sous-messages: ◄ ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 291  
Structure de données de génération 1 (TREP 01 Hex)  
▼B 
Élément de donnée  Commentaire
  
Certificats de sécurité de la VU
  
Identification du véhicule
  
Date et heure actuelles sur la VU
  
Période téléchargeable
  
Catégorie de cartes insérées dans la VU
  
Téléchargement précédent de la VU
  
Tous les verrouillages d'entreprise mémorisés. Si 
cette section est vide, seule l'expression 
noOfLocks = 0 est envoyée.
  
Tous les relevés de contrôle mémorisés dans la 
VU. Si cette section est vide, seule l'expression 
noOfControls = 0 est envoyée.
  
Signature RSA de toutes les données (hormis les 
certificats) à partir de VehicleIdentification ­
Number jusqu'au dernier octet du dernier 
VuControlActivityData.  
▼M1 
Structure de données de génération 2 (TREP 21 Hex)  
▼B 
Élément de donnée  Commentaire
  
Certificat de l'État membre
  
Certificate de la VU
  
Identification du véhicule
  
Plaque minéralogique du véhicule
  
Date et heure actuelles sur la VU
  
Période téléchargeable
  
Catégorie de cartes insérées dans la VU
  
Téléchargement précédent de la VU
  
Tous les verrouillages d'entreprise mémorisé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émorisés dans la 
VU. Si cette section est vide, un en-tête de 
tableau avec l'expression noOfRecords = 0 est 
envoyé .
  
Signature ECC de toutes les données antérieures 
hormis les certificats.  
2.2.6.2 R é p o n s e p o s i t i v e à u n e d e m a n d e d e t r a n s f e r t d e 
d o n n é e s r e l a t i v e s a u x a c t i v i t é s  
DDP_030  ►M1 Le champ de données du message «Réponse positive 
à une demande de transfert de données relatives aux activi ­
tés» doit fournir les données ci-après dans l’ordre qui suit en 
vertu des SID 76 Hex, TREP 02 ou 22 Hex et critères 
appropriés de séparation et de comptage des sous- 
messages: ◄ ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 292  
Structure de données de génération 1 (TREP 02 Hex)  
▼B 
Élément de donnée  Commentaire
  
Date du jour de téléchargement
  
Kilométrage à la fin de la journée téléchargée
  
Données relatives aux cycles d'insertion et de retrait des 
cartes. 
— Si cette section ne contient aucune donnée disponi ­
ble, seule l'expression noOfVuCardIWRecords = 0 
est envoyée. 
— Lorsque VuCardIWRecord figure à 00h00 (insertion 
de carte de la veille) ou à 24h00 (retrait de carte du 
lendemain), elle apparaît entièrement sur les deux 
jours concernés.
  
État des lecteurs à 00h00 et modifications d'activité 
mémorisés pour la journée téléchargée.
  
Données relatives aux emplacements mémorisés pour la 
journée téléchargée. Si cette section est vide, seule l'ex ­
pression noOfPlaceRecords = 0 est envoyée.
  
Données relatives aux conditions particulières mémori ­
sées pour la journée téléchargée. Si cette section est 
vide, seule l'expression noOfSpecificConditionRecords 
= 0 est envoyée.
  
Signature RSA de toutes les données à partir de Time ­
Real jusqu'au dernier octet du dernier relevé de condi ­
tions particulières.  
▼M1 
Structure de données de génération 2 (TREP 22 Hex)  
▼B 
Élément de donnée  Commentaire
  
Date du jour de téléchargement
  
Kilométrage à la fin de la journée téléchargée
  
Données relatives aux cycles d'insertion et de retrait des 
cartes. 
— Si cette section ne contient aucune donnée disponi ­
ble, un en-tête de tableau avec l'expression noOfRe ­
cords = 0 est envoyé. 
— Lorsque VuCardIWRecord figure à 00h00 (insertion 
de carte de la veille) ou à 24h00 (retrait de carte du 
lendemain), elle apparaît entièrement sur les deux 
jours concernés.
  
État des lecteurs à 00h00 et modifications d'activité 
mémorisés pour la journée téléchargée.
  
Données relatives aux emplacements mémorisés pour la 
journée téléchargée. Si cette section est vide, un en-tête 
de tableau avec l'expression noOfRecords = 0 est 
envoyé.  
▼M1
 
Positions GNSS du véhicule lorsque le temps de 
conduite accumulé du véhicule atteint un multiple de 
trois heures. Si cette section est vide, un en-tête de 
tableau avec l’expression noOfRecords = 0 est envoyé.  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 293  
Élément de donnée  Commentaire
  
Données relatives aux conditions particulières mémori ­
sées pour la journée téléchargée. Si cette section est 
vide, un en-tête de tableau avec l'expression noOfRe ­
cords = 0 est envoyé.
  
Signature ECC de toutes les données antérieures.  
2.2.6.3 R é p o n s e p o s i t i v e à u n e d e m a n d e d e t r a n s f e r t d e 
d o n n é e s r e l a t i v e s a u x é v é n e m e n t s e t a n o m a l i e s  
DDP_031  ►M1 Le champ de données du message «Réponse positive 
à une demande de transfert de données relatives aux événe ­
ments et anomalies» doit fournir les données ci-après dans 
l’ordre qui suit en vertu des SID 76 Hex, TREP 03 ou 23 
Hex et critères appropriés de séparation et de comptage des 
sous-messages: ◄ 
▼M1 
Structure de données de génération 1 (TREP 03 Hex)  
▼B 
É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 noOf ­
VuFaults = 0 est envoyée.
  
Tous les évènements enregistrés ou en cours au 
sein de la VU (hormis les dépassements de 
vitesse). 
Si cette section est vide, seule l'expression noOf ­
VuEvents = 0 est envoyée.
  
Données relatives au dernier contrôle de dépas ­
sement de vitesse (valeur par défaut en l'absence 
de données).
  
Tous les évènements en matière de dépassements 
de vitesse enregistrés dans la VU. 
Si cette section est vide, seule l'expression noOf ­
VuOverSpeedingEvents = 0 est envoyée.
  
Tous les évènements de réglage horaire mémo ­
risés dans la VU (hormis le cadre d'étalonnage 
complet). 
Si cette section est vide, seule l'expression noOf ­
VuTimeAdjRecords = 0 est envoyée.
  
Signature RSA de toutes les données à partir de 
noOfVuFaults jusqu'au dernier octet du dernier 
relevé de réglage horaire.  
▼M1 
Structure de données de génération 2 (TREP 23 Hex)  
▼B 
É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 (hormis les dépassements de 
vitesse). 
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épas ­
sement de vitesse (valeur par défaut en l'absence 
de données).
  
Tous les évènements en matière de dépassements 
de vitesse enregistrés dans la VU. 
Si cette section est vide, un en-tête de tableau 
avec l'expression noOfRecords = 0 est envoyé.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 294  
Élément de donnée  Commentaire
  
Tous les évènements de réglage horaire mémo ­
risés dans la VU (hormis le cadre d'étalonnage 
complet). 
Si cette section est vide, un en-tête de tableau 
avec l'expression noOfRecords = 0 est envoyé.  
▼M1 __________  
▼B
 
Signature ECC de toutes les données antérieures.  
2.2.6.4 R é p o n s e p o s i t i v e à u n e d e m a n d e d e t r a n s f e r t d e 
d o n n é e s r e l a t i v e s à l a v i t e s s e d u v é h i c u l e  
DDP_032  ►M1 Le champ de données du message «Réponse positive 
à une demande de transfert 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 ou 24 Hex et 
critères appropriés de séparation et de comptage des sous- 
messages: ◄ 
▼M1 
Structure de données de génération 1 (TREP 04)  
▼B 
Élément de donnée  Commentaire
  
Toutes les données se rapportant à l'évolution de 
la vitesse du véhicule pendant une minute au 
cours de laquelle le véhicule était en mouvement 
60 valeurs de vitesse par minute (une par 
seconde).
  
Signature RSA de toutes les données à partir de 
noOfSpeedBlocks jusqu'au dernier octet du 
dernier bloc de vitesse.  
▼M1 
Structure de données de génération 2 (TREP 24)  
▼B 
Élément de donnée  Commentaire
  
Toutes les données se rapportant à l'évolution de 
la vitesse du véhicule pendant une minute au 
cours de laquelle le véhicule était en mouvement 
60 valeurs de vitesse par minute (une par 
seconde).
  
Signature ECC de toutes les données antérieures.  
2.2.6.5 R é p o n s e p o s i t i v e à u n e d e m a n d e d e t r a n s f e r t d e 
d o n n é e s t e c h n i q u e s  
DDP_033  ►M1 Le champ de données du message «Réponse positive 
à une demande de transfert 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 ou 25 Hex et critères appropriés 
de séparation et de comptage des sous-messages: ◄ ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 295  
Structure de données de génération 1 (TREP 05)  
▼B 
Élément de donnée  Commentaire
  
Tous les relevés d'étalonnage mémorisés dans la 
VU.
 
Signature RSA de toutes les données à partir de 
vuManufacturerName jusqu'au dernier octet du 
dernier VuCalibrationRecord.  
▼M1 
Structure de données de génération 2 (TREP 25)  
▼B 
Élément de donnée  Commentaire
  
Tous les couplages MS mémorisés dans la VU.
  
Tous les couplages du dispositif GNSS externe 
mémorisés dans la VU
  
Tous les relevés d'étalonnage mémorisés dans la 
VU.
 
Toutes les données relatives à l'insertion de carte 
mémorisées dans la VU.
  
Signature ECC de toutes les données antérieures.  
2.3. Archivage de fichiers sur un support de mémoire externe  
DDP_034 Si une session de téléchargement a comporté une opération 
de transfert de données à partir de la VU, l'IDE doit enre ­
gistrer au sein d'un seul et même fichier physique toutes les 
données transmises par la VU pendant cette session de télé ­
chargement dans des messages de réponse positive concer ­
nant le transfert de données. La sauvegarde de ces données 
en exclut les en-têtes de message, compteurs de sous- 
messages, 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érieur à l'unité).  
3. PROTOCOLE DE TÉLÉCHARGEMENT DES CARTES TACHY ­
GRAPHIQUES  
3.1. Champ d'application  
Ce paragraphe comporte une description du téléchargement direct vers 
un IDE des données de carte mémorisées sur une carte tachygraphique. 
L'IDE n'appartient pas à l'environnement sécurisé; aucune authentifica ­
tion n'a donc lieu entre la carte et l'IDE.  
3.2. Définitions  
Session de téléchargement : chaque fois que le système procède à 
une opération de téléchargement 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).  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 296  
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 trans ­
férée vers l'IFD.  
3.3. Téléchargement d'une carte  
▼M1 
DDP_035 Le téléchargement d’une carte tachygraphique comporte les 
opérations suivantes:  
— Téléchargement 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érique.  
— (pour les cartes tachygraphiques de première et 
deuxième générations) Téléchargement des EF dans le 
fichier spécialisé
  :  
— Téléchargement des EF
  
et
 . Ces informations ne 
sont protégées par aucune signature numérique.  
Il faut impérativement télécharger ces fichiers lors de 
toute session de téléchargement.  
— Téléchargement des autres EF de données d’applica ­
tion (dans le
  ) sauf l'EF
  
. Ces informations sont proté ­
gées par une signature numérique, conformément 
aux dispositions de l’appendice 11, Mécanismes de 
sécurité communs, partie A.  
— Il y a lieu de télécharger au moins les
  
et
 
lors de toute session de télé ­
chargement.  
— Lors du téléchargement d’une carte de conducteur, il 
faut également procéder obligatoirement au téléchar ­
gement des EF suivants:
  
— (pour les cartes tachygraphiques de deuxième géné ­
ration uniquement) Excepté lorsque le télécharge ­
ment d’une carte de conducteur insérée dans une 
VU est effectué durant le contrôle des conducteurs 
par une autorité de contrôle autre qu'une autorité de 
contrôle de l’UE, au moyen d’une carte de contrôle 
de première génération, télécharger les EF dans le
  
: 
— Télécharger les EF CardSignCertificate, CA_Cer ­
tificate et Link_Certificate (le cas échéant). Ces 
informations ne sont protégées par aucune signa ­
ture numérique.  
Il faut impérativement télécharger ces fichiers 
lors de toute session de téléchargement.  
— Téléchargement des autres EF de données d’ap ­
plication (dans le
  ) 
sauf l'EF
  . Ces informa ­
tions sont protégées par une signature numérique, 
conformément aux dispositions de l’appendice 
11, Mécanismes de sécurité communs, partie B.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 297  
— Il y a lieu de télécharger au moins les
  
et
 
lors de toute session de 
téléchargement.  
— Lors du téléchargement d’une carte de conduc ­
teur, il faut également procéder obligatoirement 
au téléchargement des EF suivants:
  
— Lors du téléchargement d’une carte de conduc ­
teur, il convient de mettre à jour la date
  
dans l’EF
  
, dans les DF
  
et, le cas échéant,
  
. 
— Lors du téléchargement d’une carte d’atelier, il 
convient de réinitialiser le compteur d’étalonnage 
enregistré dans l’EF
  dans 
les DF
  et, le cas échéant,
  
. 
— Lors du téléchargement d’une carte d’atelier, 
l’EF
 
dans les DF
  et, le cas échéant,
  
n’est pas téléchargé.  
▼B 
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'utilisateur a l'option de recourir à la PPS pour passer à un 
débit supérieur à condition que l'ICC en assure la prise en 
charge.  
3.3.2  Séquence de téléchargement des fichiers de données non signés  
DDP_037  ►M1 La séquence du téléchargement des EF ICC, IC, 
Card_Certificate (ou CardSignCertificate pour le DF Tacho ­
graph_G2), CA_Certificate et Link_Certificate (pour le DF 
Tachograph_G2 uniquement) est la suivante: ◄ 
Carte  Sens  IDE/IFD  Signification/Remarques  
⇦ Select File  Sélection par le biais d'iden ­
tificateurs de fichier  
OK ⇨ 
⇦ Read Binary  Si le volume des données que 
contient le fichier est supé ­
rieur à la capacité de la 
mémoire tampon du lecteur 
ou de la carte, la commande 
doit être réitérée jusqu'à ce 
que les données que contient 
ce fichier aient été extraites 
dans leur intégralité.  
Données 
OK ⇨ Sauvegarder les données sur 
l'ESM  selon  3.4 Data storage format  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 298  
Note 1:  avant de sélectionner l'EF Card_Certificate (ou 
CardSignCertificate), il convient de sélectionner préalable ­
ment l'application tachygraphique (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 
Binary et d'un identifiant EF court.  
3.3.3  Séquence de téléchargement des fichiers de données signés  
DDP_038 Il y a lieu de recourir à la séquence ci-après pour procéder 
au téléchargement de chacun des fichiers qui suivent accom ­
pagnés de leur signature:  
▼M1 
Carte  Dir  IDE/IFD  Signification/Remarques
  
Select File  
OK
 
Procéder au hachage du 
fichier (Hash of File)  — Permet de calculer la 
valeur de hachage par 
rapport au contenu du 
fichier sélectionné en 
appliquant l’algorithme 
de hachage prescrit en 
conformité avec l’appen ­
dice 11, partie A ou B. 
Cette commande n’est 
pas une commande ISO.  
Calculer le hachage du 
fichier et enregistrer 
temporairement la 
valeur de hachage rete ­
nue 
OK
 
Read Binary  Si le fichier contient plus de 
données que le tampon ou la 
carte ne peut en contenir, la 
commande doit être réitérée 
jusqu’à ce que les données 
que contient ce fichier aient 
été extraites dans leur inté ­
gralité.  
Données 
OK
 Sauvegarder les données sur 
l’ESM  conformément à  3.4  Data 
storage format
  
PSO: Compute Digital 
Signature  
Exécution opération de 
sécurité «Calcul de la 
signature numérique» à 
l’aide de la valeur de 
hachage temporairement 
enregistrée  
Signature 
OK
 Adjonction de données à 
celles préalablement sauve ­
gardées sur l’ESM  conformément à  3.4  Data 
storage format  
▼B 
Remarque:  la sélection et la lecture d'un fichier sont égale ­
ment réalisables en une étape à l'aide de la commande Read 
Binary et d'un identifiant EF court. Dans ce cas, l'EF peut 
être sélectionné et lu avant d'exécuter la commande procé ­
dant au hachage du fichier.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 299  
3.3.4  Séquence de réinitialisation d'un compteur d'étalonnage.  
DDP_039 La séquence de réinitialisation du compteur
  
que contient 
l'EF
 d'une carte d'atelier se présente 
comme suit:  
Carte  Dir  IDE/IFD  Signification/Remarques  
⇦ Select File  EF Card_Down ­
load Sélection par le biais d'iden ­
tificateurs de fichier  
OK ⇨ 
⇦ Update Binary  
NoOfCalibrationsSinceDown ­
load = ‘00 00’  
réinitialise le nombre de 
téléchargements 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 Binary et d'un identifiant EF court.  
3.4. Format d'archivage des données  
3.4.1  Introduction  
DDP_040 Les données téléchargées doivent être enregistrées dans les 
conditions suivantes:  
— L'enregistrement des données doit être transparent. En 
d'autres termes, l'ordre dans lequel se présentent les 
octets et les bits constitutifs de ces octets doit être 
préservé lors de l'opération d'archivage exécutée après 
leur transfert de la carte.  
— Tous les fichiers de la carte téléchargés dans le cadre 
d'une session de téléchargement 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 assorti de l'appendice ‘00’.  
DDP_043 La balise associée à la signature d'un EF doit prendre la 
forme du FDI du fichier assorti de l'appendice ‘01’.  
DDP_044 La longueur correspond à une valeur exprimée par deux 
octets. Cette valeur détermine le nombre d'octets affectés 
au champ valeur. La valeur ‘FF FF’ que contient le 
champ longueur est réservée à un usage ultérieur.  
DDP_045 Faute de téléchargement, aucune information relative à un 
fichier déterminé ne sera sauvegardée (pas de balise et pas 
de longueur zéro).  
▼M1 
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 concerné.  
Définition  Signification  Longueur  
FDI (2 octets) || «00»  Balise pour EF (FDI) dans 
le
 ou pour 
les informations communes 
que contient la carte  3 octets  
FDI (2 octets) || «01»  Balise pour signature d’EF 
(FDI) dans le DF
  3 octets  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 300  
Définition  Signification  Longueur  
FDI (2 octets) || «02»  Balise pour EF (FDI) dans 
le DF
  3 octets  
FDI (2 octets) || «03»  Balise pour signature d’EF 
(FDI) dans le DF
  3 octets  
xx xx  Longueur du champ valeur  2 octets  
Exemple de données enregistrées dans un fichier de télé ­
chargement sur un ESM:  
Balise  Longueur  Valeur
  
— Données de l'EF ICC
  
— Données de l'EF Card_Certificate  
— ...
  
Données de l'EF
  
(dans le DF
  )
  
Signature de l'EF
  
(dans le DF
  )
  
Données de l'EF
  
(dans le DF
  )
  
Signature de l'EF
  
(dans le DF
  )  
▼B 
4. TÉLÉCHARGEMENT D'UNE CARTE TACHYGRAPHIQUE PAR 
L'INTERMÉDIAIRE D'UNE UNITÉ EMBARQUÉE SUR VÉHI ­
CULE.  
DDP_047 La VU doit autoriser le téléchargement du contenu d'une 
carte de conducteur insérée dans le lecteur d'un IDE 
connecté.  
DDP_048 Cet IDE doit envoyer un message «Demande de transfert de 
données du type téléchargement de carte» à la VU pour 
lancer ce mode de transmission (cf. 2.2.2.9).  
▼M1 
DDP_049 Cartes de conducteur de première génération: Les données 
doivent être téléchargées selon le protocole de télécharge ­
ment de données de première génération. Les données télé ­
chargées auront le même format que les données téléchar ­
gées depuis une unité embarquée sur un véhicule de 
première génération.  
Cartes de conducteur de deuxième génération: À ce stade, la 
VU doit procéder au téléchargement de la carte dans son 
intégralité, fichier par fichier, en conformité avec le proto ­
cole de téléchargement de carte défini au paragraphe 3 ainsi 
qu’à l’envoi à l’IDE de toutes les données extraites de la 
carte dans le format de fichier TLV approprié (cf. 3.4.2) et 
encapsulées dans un message «Réponse positive à une 
demande de transfert de données».  
▼B 
DDP_050 L'IDE doit extraire les données de la carte intégrées au 
message «Réponse positive à une demande de transfert de 
données» (en éliminant tous les en-têtes, SID, TREP, 
compteurs de sous-messages et totaux de contrôle) et les 
enregistrer dans un seul et même fichier physique confor ­
mément à la description présentée au paragraphe 2.3.  
DDP_051 Ensuite, la VU doit, selon le cas, procéder à une actualisa ­
tion du fichier de données des activités de contrôle ou de 
téléchargement de cartes (
  
ou
 ) sur la carte du conducteur.  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 301  
Appendice 8  
PROTOCOLE D'ÉTALONNAGE  
TABLE DES MATIÈRES  
1. INTRODUCTION  
2. TERMINOLOGIE, DÉFINITIONS ET RÉFÉRENCES  
3. VUE D'ENSEMBLE DES SERVICES  
3.1. Services disponibles  
3.2. Codes de réponse  
4. SERVICES DE COMMUNICATION  
4.1. Service StartCommunication  
4.2. Service StopCommunication  
4.2.1 Description des messages  
4.2.2 Structure des messages  
4.2.3 Définition des paramètres  
4.3. Service TesterPresent  
4.3.1 Description des messages  
4.3.2 Structure des messages  
5. SERVICES DE GESTION  
5.1. Service StartDiagnosticSession  
5.1.1 Description des messages  
5.1.2 Structure des messages  
5.1.3 Définition du paramètre  
5.2. Service SecurityAccess  
5.2.1 Description des messages  
5.2.2 Structure des messages — SecurityAccess — requestSeed  
5.2.3 Structure des messages — SecurityAccess — sendKey  
6. SERVICES DE TRANSMISSION DE DONNÉES  
6.1. Service ReadDataByIdentifier  
6.1.1 Description des messages  
6.1.2 Structure des messages  
6.1.3 Définition des paramètres  
6.2. Service WriteDataByIdentifier  
6.2.1 Description des messages  
6.2.2 Structure des messages  
6.2.3 Définition du paramètre  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 302  
7. CONTRÔLE DES IMPULSIONS D'ESSAI — UNITÉ FONCTION ­ 
NELLE DE CONTRÔLE DES ENTRÉES/SORTIES  
7.1. Service InputOutputControlByIdentifier  
7.1.1 Description des messages  
7.1.2 Structure des messages  
7.1.3 Définition du paramètre  
8. STRUCTURES DES DATARECORDS  
8.1. Gammes des paramètres transmis  
8.2. Structures des dataRecords  
1. INTRODUCTION  
Le présent appendice traite des modalités d'échange 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écrite à l'appendice 6. Le présent appendice traite aussi 
du contrôle de la ligne de signalisation d'entrée/sortie exercé au niveau 
du connecteur d'étalonnage.  
L'établissement de communications sur la ligne K est décrit à la section 
4 «Services de communication».  
Le présent appendice s'appuie sur le concept de «sessions» de diag ­
nostic pour déterminer la portée du contrôle de la ligne K au gré de 
l'évolution des modalités d'échange. La session par défaut est la «Stan ­
dardDiagnosticSession», où toutes les données que contient une unité 
embarquée sur véhicule sont susceptibles d'en être extraites, 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 description 
détaillée à la section 5 «Services de gestion».  
Le présent appendice s'applique aux deux générations de VU et de 
cartes d'atelier, conformément aux exigences d'interopérabilité établies 
par le présent règlement.  
CPR_001 La «ECUProgrammingSession» autorise 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'étalonnage, l'unité embarquée sur véhicule doit en 
outre être exploitée en mode ÉTALONNAGE.  
Le transfert de données par l'intermédiaire de la ligne K fait 
l'objet d'une description détaillée à la section 6 «Services de 
transmission de données». Les formats des données trans ­
férées sont décrits en détail à la section 8 «dataRecords 
formats».  
CPR_002 «ECUAdjustmentSession» permet de sélectionner le mode 
d'entrée/sortie de la ligne de signalisation d'entrée/sortie 
d'étalonnage à l'aide de l'interface de la ligne K. Le contrôle 
de la ligne de signalisation d'entrée/sortie d'étalonnage fait 
l'objet d'une description à la section 7 «Contrôle des impul ­
sions d'essai — Unité fonctionnelle de contrôle des entrées/ 
sorties».  
CPR_003 Tout au long du présent document, l'appareil d'essai possède 
l'adresse suivante: «tt». Bien que certaines adresses d'appa ­
reil d'essai soient privilégiées, la VU doit réagir correcte ­
ment à toute adresse d'appareil d'essai. L'adresse physique 
de la VU s'énonce comme suit: 0xEE.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 303  
2. TERMINOLOGIE, DÉFINITIONS ET RÉFÉRENCES  
Les protocoles, messages 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 identificateurs de service, de l'élaboration des 
demandes et réponses de service et de la configuration des paramètres 
standard.  
Le terme «appareil d'essai» fait référence à l'équipement utilisé pour 
saisir des données de programmation/étalonnage dans la VU.  
Les termes «client» et «serveur» font respectivement référence à l'ap ­
pareil d'essai et à la VU.  
Le terme ECU ( Electronic Control Unit ) signifie «unité de commande 
électronique» et s'applique à la VU.  
Références:  
▼M1 
ISO 14230-2: Véhicules routiers — Systèmes de diagnostic — Proto ­
cole à mots clés 2000 — Partie 2: Couche de liaison de données.  
Première édition: 1999.  
▼B 
3. VUE D'ENSEMBLE DES SERVICES  
3.1. Services disponibles  
Le tableau qui suit présente une vue d'ensemble des services définis 
dans le présent document et auxquels doit pourvoir le tachygraphe.  
CPR_004 Ce tableau indique quels sont les services disponibles lors 
d'une session de diagnostic active.  
— La  1 re colonne  répertorie les services disponibles.  
— La  2 e colonne  indique le numéro de section qui présente 
une description détaillée du service considéré dans le 
présent appendice.  
— La  3 e colonne  indique les valeurs affectées à l'identifi ­
cateur de service dans les messages de demande de 
service.  
— La  4 e colonne  précise quels sont les services de la 
«StandardDiagnosticSession » (SD) dont la mise en 
œuvre dans la VU est indispensable.  
— La  e colonne  précise quels sont les services de la 
«ECUAdjustmentSession » (ECUAS ) 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'étalonnage monté sur la face 
avant de la VU.  
— La  6 e colonne  précise quels sont les services de la 
«ECUProgrammingSession » (ECUPS ) dont la mise 
en œuvre est indispensable pour procéder à la program ­
mation des paramètres d'exploitation dans la VU.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 304  
Tableau 1  
Récapitulatif des valeurs affectées aux identificateurs de service  
Sessions de diagnostic  
Noms des services de diagnostic  Section 
n o Valeurs affec ­
tées aux identi ­
ficateurs de 
service  SD ECUAS  ECUPS  
StartCommunication  4.1  81  ■ ■ ■ 
StopCommunication  4.2  82  ■ 
TesterPresent  4.3  3E  ■ ■ ■ 
StartDiagnosticSession  5.1  10  ■ ■ ■ 
SecurityAccess  5.2  27  ■ ■ ■ 
ReadDataByIdentifier  6.1  22  ■ ■ ■ 
WriteDataByIdentifier  6.2  2E  ■ 
InputOutputControlByIdentifier  7.1  2F  ■ 
■ Ce symbole rappelle le caractère obligatoire du service correspondant pendant cette session de 
diagnostic. 
Aucun symbole n'indique que l'exécution du service correspondant n'est pas autorisée pendant 
cette session de diagnostic.  
3.2. Codes de réponse  
Des codes de réponse sont définis pour chaque service.  
4. SERVICES DE COMMUNICATION  
Certains services sont nécessaires à l'établissement et au maintien des 
communications. Ils n'apparaissent pas dans la couche application. Les 
services disponibles sont décrits dans le tableau ci-après:  
Tableau 2  
Services de communication  
Nom du service  Description  
StartCommunication  Le client demande le lancement d'une 
session de communication avec un ou 
plusieurs serveur(s).  
StopCommunication  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 StartCommunication est utilisé pour établir une 
communication. L'exécution de tout service suppose l'éta ­
blissement d'une communication et la sélection de paramè ­
tres adaptés au mode d'exploitation souhaité.  
4.1. Service StartCommunication  
CPR_006 À la réception d'une primitive d'indication StartCommunica ­
tion, la VU vérifie si l'établissement de la liaison d'inter ­
communication requise est envisageable dans les conditions 
présentes. Les conditions d'établissement d'une liaison d'in ­
tercommunication font l'objet d'une description détaillée 
dans le document ISO 14230-2.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 305  
CPR_007 Ensuite, la VU doit exécuter toutes les actions nécessaires à 
l'établissement de la liaison d'intercommunication requise et 
envoyer une primitive de réponse StartCommunication 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 diagnos ­
tic) reçoit une nouvelle demande StartCommunication (p.ex. 
en raison d'une reprise sur incident au niveau de l'appareil 
d'essai), cette demande doit être acceptée et la VU réinitia ­
lisée.  
CPR_009 Si, pour une raison quelconque, l'établissement de la liaison 
d'intercommunication s'avère impossible, la VU doit conti ­
nuer à fonctionner dans les mêmes conditions qu'immédia ­
tement avant la tentative d'établissement d'une liaison d'in ­
tercommunication.  
CPR_010 Le message de demande StartCommunication doit 
comporter 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 à toute acti ­
vité. 
— L'appareil d'essai envoie ensuite une configuration d'ini ­
tialisation.  
— Toutes les informations nécessaires à l'établissement 
d'une communication sont contenues dans la réponse 
de la VU.  
CPR_012 Après initialisation,  
— toutes 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,  
— la VU se trouve en mode de diagnostic par défaut, 
autrement dit le mode StandardDiagnosticSession;  
— la ligne de signalisation d'entrée/sortie d'étalonnage est 
dans son état d'exploitation par défaut, à savoir, désacti ­
vé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ébute au terme 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 StartCommunication au terme d'un délai de Twup 
suivi du premier front descendant.
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 306  
CPR_017 Les valeurs de synchronisation propres à l'initialisation 
rapide et aux communications en général font l'objet d'une 
description détaillée dans les tableaux ci-après. Pour ce qui 
concerne le temps d'inoccupation, plusieurs possibilités sont 
envisageables:  
— Première transmission après mise en marche, 
Tidle = 300 ms.  
— Après achèvement du Service StopCommunication, 
Tidle = P3 min.  
— Après interruption d'une communication pour cause de 
dépassement du temps imparti 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 temporisation des communications  
Paramètre 
de synchro ­
nisation  Description des paramètres  Valeurs mini ­
males admises 
(ms) Valeurs maxi ­
males admises 
(ms) 
min. max.  
P1 Délai interoctet à respecter 
dans l'attente 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'appareil d'essai  55 5 000  
P4 Délai interoctet à respecter 
dans l'attente d'une demande 
émise par l'appareil d'essai  5 20  
CPR_018 La structure des messages transmis dans le cadre d'une 
initialisation rapide fait l'objet d'une description détaillée 
dans les tableaux qui suivent.  
Tableau 5  
Message StartCommunication Request  
Octet #  Nom de paramètre  Valeur hex.  Mnémonique  
#1 Octet de structure — adressage 
physique  81 FMT  
#2 Octet d'adresse de la cible  EE  TGT  
#3 Octet d'adresse de la source  tt  SRC  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 307  
Octet #  Nom de paramètre  Valeur hex.  Mnémonique  
#4 StartCommunication Request 
Service Id  81 SCR  
#5 Total de contrôle  00-FF  CS  
Tableau 6  
Message StartCommunication Positive Response  
Octet #  Nom de paramètre  Valeur hex.  Mnémonique  
#1 Octet de structure — adressage 
physique  80 FMT  
#2 Octet d'adresse de la cible  tt  TGT  
#3 Octet d'adresse de la source  EE  SRC  
#4 Octet de longueur supplémen ­
taire 03 LEN  
#5 StartCommunication Positive 
Response Service Id  C1 SCRPR  
#6 Octet clé 1  EA  KB1  
#7 Octet clé 2  8F  KB2  
#8 Total de contrôle  00-FF  CS  
CPR_019 Il n'y a pas de réponse négative au message StartCommu ­
nication Request. Faute de message 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  Description des messages  
Ce service portant sur la couche communication vise à mettre un terme 
à toute session de communication.  
CPR_020 À la réception d'une primitive d'indication StopCommunica ­
tion, la VU doit vérifier si les conditions en vigueur permet ­
tent d'interrompre la communication en cours. Si tel est le 
cas, la VU doit exécuter toutes les opérations requises pour 
mettre un terme à cette communication.  
CPR_021 Si une interruption de la communication est envisageable, la 
VU doit émettre une primitive de réponse StopCommunica ­
tion en recourant aux paramètres de réponse positive sélec ­
tionnés, avant de clore la communication.  
CPR_022 Si, pour une raison quelconque, il s'avère impossible d'inter ­
rompre la communication concernée, la VU doit émettre une 
primitive de réponse StopCommunication en recourant au 
paramètre de réponse négative sélectionné.  
CPR_023 Si la VU détecte un dépassement du délai P3max, la 
communication est interrompue sans s'accompagner de 
l'émission d'aucune primitive de réponse.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 308  
4.2.2  Structure des messages  
CPR_024 La structure des messages associés aux primitives StopCom ­
munication fait l'objet d'une description détaillée dans les 
tableaux ci-après.  
Tableau 7  
Message StopCommunication Request  
Octet #  Nom de paramètre  Valeur hex.  Mnémonique  
#1 Octet de structure — adressage 
physique  80 FMT  
#2 Octet d'adresse de la cible  EE  TGT  
#3 Octet d'adresse de la source  tt  SRC  
#4 Octet de longueur supplémen ­
taire 01 LEN  
#5 StopCommunication Request 
Service Id  82 SPR  
#6 Total de contrôle  00-FF  CS  
Tableau 8  
Message StopCommunication Positive Response  
Octet #  Nom de paramètre  Valeur hex.  Mnémonique  
#1 Octet de structure — adressage 
physique  80 FMT  
#2 Octet d'adresse de la cible  tt  TGT  
#3 Octet d'adresse de la source  EE  SRC  
#4 Octet de longueur supplémen ­
taire 01 LEN  
#5 StopCommunication Positive 
Response Service Id  C2 SPRPR  
#6 Total de contrôle  00-FF  CS  
Tableau 9  
Message StopCommunication Negative Response  
Octet #  Nom de paramètre  Valeur hex.  Mnémonique  
#1 Octet de structure — adressage 
physique  80 FMT  
#2 Octet d'adresse de la cible  tt  TGT  
#3 Octet d'adresse de la source  EE  SRC  
#4 Octet de longueur supplémen ­
taire 03 LEN  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 309  
Octet #  Nom de paramètre  Valeur hex.  Mnémonique  
#5 negative Response Service Id  7F  NR  
#6 StopCommunication Request 
Service Identification  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 TesterPresent  
4.3.1  Description 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êcher que le serveur ne 
retourne automatiquement en fonctionnement normal et ne coupe éven ­
tuellement la communication. Ce service, envoyé périodiquement, 
maintien en activité la session de diagnostic et la communication en 
remettant à zéro le compteur P3 à chaque demande de prestation.  
4.3.2  Structure des messages  
CPR_079 La structure des messages associés aux primitives Tester ­
Present fait l'objet d'une description détaillée dans les 
tableaux ci-après.  
Tableau 10  
Message TesterPresent Request  
Octet #  Nom de paramètre  Valeur hex.  Mnémonique  
#1 Octet de structure — adressage 
physique  80 FMT  
#2 Octet d'adresse de la cible  EE  TGT  
#3 Octet d'adresse de la source  tt  SRC  
#4 Octet de longueur supplémentaire  02  LEN  
#5 TesterPresent Request Service 
Id 3E TP  
#6 Sous-fonction = response 
Required =  [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 message positif suivant. Si le paramètre 
est «non», le serveur n'envoie pas de réponse.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 310  
Tableau 11  
Message TesterPresent Positive Response  
Octet #  Nom de paramètre  Valeur hex.  Mnémonique  
#1 Octet de structure — adressage 
physique  80 FMT  
#2 Octet d'adresse de la cible  tt  TGT  
#3 Octet d'adresse de la source  EE  SRC  
#4 Octet de longueur supplémen ­
taire 01 LEN  
#5 TesterPresent Positive 
Response Service Id  7E TPPR  
#6 Total de contrôle  00-FF  CS  
CPR_081 Le service accepte les codes de réponse négative suivants:  
Tableau 12  
Message TesterPresent Negative Response  
Octet #  Nom de paramètre  Valeur 
hex. Mnémonique  
#1 Octet de structure — adressage 
physique  80 FMT  
#2 Octet d'adresse de la cible  tt  TGT  
#3 Octet d'adresse de la source  EE  SRC  
#4 Octet de longueur supplémentaire  03  LEN  
#5 negative Response Service Id  7F  NR  
#6 TesterPresent Request Service Identi ­
fication  3E TP  
#7 response ­
Code =  [SubFunctionNotSup ­
ported-InvalidFormat  12 RC_SFNS_IF  
incorrectMessage ­
Length ]  13 RC_IML  
#8 Total de contrôle  00-FF  CS  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 311  
5. SERVICES DE GESTION  
Les services disponibles font l'objet d'une description détaillée dans le 
tableau ci-après:  
Tableau 13  
Services de gestion  
Nom du service  Description  
StartDiagnosticSession  Le client demande le lancement d'une 
session de diagnostic avec une VU.  
SecurityAccess  Le client demande l'accès à certaines 
fonctions réservées aux utilisateurs 
autorisés.  
5.1. Service StartDiagnosticSession  
5.1.1  Description des messages  
CPR_025 Le service StartDiagnosticSession permet d'activer diffé ­
rentes sessions de diagnostic au sein du serveur. Une 
session de diagnostic autorise l'exploitation d'un jeu de 
services spécifique, conformément aux indications fournies 
au Tableau 17. Une session peut permettre des services 
spécifiques du constructeur du véhicule qui ne font pas 
partie du présent document. Les règles de mise en œuvre 
doivent satisfaire aux exigences suivantes:  
— il doit toujours y avoir exactement une session de diag ­
nostic en cours dans la VU,  
— la VU doit toujours ouvrir la StandardDiagnosticSession 
lorsqu'elle est mise sous tension. Si aucune autre session 
de diagnostic n'est ouverte, la StandardDiagnosticSes ­
sion doit rester ouverte aussi longtemps que la VU est 
sous tension,  
— si une session de diagnostic déjà ouverte 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 StartDiagnosticSession avant que la 
nouvelle session ne s'ouvre dans la VU. Si la VU n'a 
pu ouvrir la nouvelle session de diagnostic demandée, 
elle envoie un message de réponse négative à StartDia ­
gnosticSession et la session en cours se poursuit.  
CPR_026 Le lancement d'une session de diagnostic n'est envisageable 
qu'à la condition qu'une communication ait été préalable ­
ment établie entre le client et la VU.  
CPR_027 Les paramètres de synchronisation définis dans le Tableau 4 
deviendront actifs au terme de l'exécution réussie d'une 
StartDiagnosticSession, pour autant que le message de 
demande comporte le paramètre diagnosticSession défini 
sur «StandardDiagnosticSession» dans l'éventualité où une 
autre session de diagnostic aurait été préalablement active.  
5.1.2  Structure des messages  
CPR_028 La structure des messages associés aux primitives StartDia ­
gnosticSession fait l'objet d'une description détaillée dans les 
tableaux ci-après.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 312  
Tableau 14  
Message StartDiagnosticSession Request  
Octet #  Nom de paramètre  Valeur hex.  Mnémonique  
#1 Octet de structure — adressage 
physique  80 FMT  
#2 Octet d'adresse de la cible  EE  TGT  
#3 Octet d'adresse de la source  tt  SRC  
#4 Octet de longueur supplémen ­
taire 02 LEN  
#5 StartDiagnosticSession 
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 StartDiagnosticSession Positive Response  
Octet #  Nom de paramètre  Valeur hex.  Mnémonique  
#1 Octet de structure — adressage 
physique  80 FMT  
#2 Octet d'adresse de la cible  tt  TGT  
#3 Octet d'adresse de la source  EE  SRC  
#4 Octet de longueur supplémen ­
taire 02 LEN  
#5 StartDiagnosticSession Posi ­
tive Response Service 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 StartDiagnosticSession Negative Response  
Octet #  Nom de paramètre  Valeur 
hex. Mnémonique  
#1 Octet de structure — adressage 
physique  80 FMT  
#2 Octet d'adresse de la cible  tt  TGT  
#3 Octet d'adresse de la source  EE  SRC  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 313  
Octet #  Nom de paramètre  Valeur 
hex. Mnémonique  
#4 Octet de longueur supplémentaire  03  LEN  
#5 Negative Response Service Id  7F  NR  
#6 StartDiagnosticSession Request 
Service Id  10 STDS  
#7 Response ­
Code =  [subFunctionNotSup ­
ported (  a ) 12 RC_SFNS  
incorrectMessage ­
Length (  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 charge, 
c.-à-d. pas dans le Tableau 17, 
( b ) la longueur du message est incorrecte, 
( c ) les critères pour la demande StartDiagnosticSession ne sont pas remplis.  
5.1.3  Définition du paramètre  
CPR_029 Le service StartDiagnosticSession utilise le paramètre  diag­
nosticSession (DS_)  pour sélectionner le comportement 
particulier du ou des serveurs. Les sessions de diagnostic 
qui suivent sont précisées dans le présent document:  
Tableau 17  
Définition des valeurs diagnosticSession  
Hex.  Description  Mnémonique  
81 StandardDiagnosticSession  
Cette session de diagnostic permet d'activer tous 
les services indiqués dans le  Tableau 1 colonne 
4 «SD».  Ces services autorisent 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 susceptible d'être écrasée par 
d'autres sessions de diagnostic spécifiées dans 
ce chapitre.  SD 
85 ECUProgrammingSession  
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 diagnostic est susceptible 
d'être écrasée par d'autres sessions de diagnostic 
spécifiées dans cette Section.  ECUPS  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 314  
Hex.  Description  Mnémonique  
87 ECUAdjustmentSession  
Cette session de diagnostic permet d'activer tous 
les services indiqués dans le  Tableau 1 colonne 
5 «ECUAS».  Ces services prennent en charge 
le contrôle des entrées/sorties d'un serveur 
(VU). Cette session de diagnostic est susceptible 
d'être écrasée par d'autres sessions de diagnostic 
spécifiées dans ce chapitre.  ECUAS  
5.2. Service SecurityAccess  
Il n'est possible d'écrire des données d'étalonnage que si la VU est en 
mode ÉTALONNAGE. Outre l'insertion d'une carte d'atelier valide 
dans le lecteur approprié de la VU, il est indispensable d'entrer le 
numéro d'identification individuel adéquat dans la VU pour avoir 
accès au mode ÉTALONNAGE.  
Lorsque la VU est en mode ÉTALONNAGE ou CONTRÔLE, il est 
également possible d'accéder à la ligne E/S d'étalonnage.  
Le service SecurityAccess permet d'introduire le numéro d'identifica ­
tion individuel et d'indiquer à l'appareil d'essai si la VU est exploitée 
ou non en mode ÉTALONNAGE.  
Le système permet de recourir à d'autres méthodes pour entrer ce 
numéro d'identification individuel.  
5.2.1  Description des messages  
Le service SecurityAccess comporte l'exécution d'un message Securi ­
tyAccess «requestSeed» (demande de germe), suivi le cas échéant d'un 
message SecurityAccess «sendKey» (demande d'envoi d'une clé). Le 
service SecurityAccess doit être exécuté après le service StartDiagnos ­
ticSession.  
CPR_033 L'appareil d'essai doit utiliser le message SecurityAccess 
«requestSeed» pour vérifier si l'unité embarquée sur véhi ­
cule est prête à accepter un PIN (numéro d'identification 
individuel).  
CPR_034 Si l'unité embarquée sur véhicule est déjà en mode 
ÉTALONNAGE, elle répond à la demande qui lui est 
adressée par l'envoi d'un «germe» de 0x0000 en utilisant 
le service SecurityAccess Positive Response.  
CPR_035 Si l'unité embarquée sur véhicule est prête à accepter 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'envoi d'un «germe» d'une valeur supé ­
rieure à 0x0000 en utilisant le service SecurityAccess Posi ­
tive Response.  
CPR_036 Si l'unité embarquée sur véhicule n'est pas prête à accepter 
un PIN émanant de l'appareil d'essai parce que la carte 
d'atelier insérée dans le lecteur 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'envoi d'une réponse négative accompagnée 
d'un code de réponse conditionsNotCorrectOrRequestSe ­
quenceError.  
CPR_037 En définitive, l'appareil d'essai devra recourir au message 
SecurityAccess «sendKey» 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 recourir au code de réponse négative 
requestCorrectlyReceived-ResponsePending (demande bien  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 315  
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 message de réponse positive ou négative 
avec un code de réponse différent du code précité. Le code 
de réponse négative requestCorrectlyReceived-ResponsePen ­
ding 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 SecurityAccess Positive 
Response qu'à la condition d'être exploitée en mode 
ÉTALONNAGE.  
CPR_039 Dans les cas énumérés ci-après, l'unité embarquée sur véhi ­
cule doit répondre à cette demande par une réponse négative 
accompagnée de l'un des codes de réponse suivants:  
— subFunctionNot supported: format non valable pour le 
paramètre de la sous-fonction (accessType),  
— conditionsNotCorrectOrRequestSequenceError: unité 
embarquée sur véhicule pas prête à accepter l'entrée 
d'un PIN,  
— invalidKey: PIN non valable sans dépassement du 
nombre de tentatives de vérification de ce numéro,  
— exceededNumberOfAttempts: PIN non valable et dépas ­
sement du nombre de tentatives de vérification de ce 
numéro,  
— generalReject: PIN correct, mais échec de la tentative 
d'authentification mutuelle avec la carte d'atelier utilisée.  
5.2.2  Structure des messages — SecurityAccess — requestSeed  
CPR_040 La structure des messages associés aux primitives Securi ­
tyAccess «requestSeed» fait l'objet d'une description 
détaillée dans les tableaux ci-après.  
Tableau 18  
Message SecurityAccess Request- requestSeed  
Octet #  Nom de paramètre  Valeur hex.  Mnémonique  
#1 Octet de structure — adressage 
physique  80 FMT  
#2 Octet d'adresse de la cible  EE  TGT  
#3 Octet d'adresse de la source  tt  SRC  
#4 Octet de longueur supplémen ­
taire 02 LEN  
#5 SecurityAccess Request 
Service Id  27 SA  
#6 accessType — requestSeed  7D  AT_RSD  
#7 Total de contrôle  00-FF  CS  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 316  
Tableau 19  
Message SecurityAccess — requestSeed Positive Response  
Octet #  Nom de paramètre  Valeur hex.  Mnémonique  
#1 Octet de structure — adressage 
physique  80 FMT  
#2 Octet d'adresse de la cible  tt  TGT  
#3 Octet d'adresse de la source  EE  SRC  
#4 Octet de longueur supplémen ­
taire 04 LEN  
#5 SecurityAccess Positive 
Response Service Id  67 SAPR  
#6 accessType — 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 SecurityAccess Negative Response  
Octet #  Nom de paramètre  Valeur 
hex. Mnémonique  
#1 Octet de structure — adressage physique  80  FMT  
#2 Octet d'adresse de la cible  tt  TGT  
#3 Octet d'adresse de la source  EE  SRC  
#4 Octet de longueur supplémentaire  03  LEN  
#5 negativeResponse Service Id  7F  NR  
#6 SecurityAccess Request Service Id  27  SA  
#7 responseCode =  [conditionsNotCorrec ­
tOrRequestSequen ­
ceError  22 RC_CNC  
incorrectMessage ­
Length]  13 RC_IML  
#8 Total de contrôle  00-FF  CS  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 317  
5.2.3  Structure des messages — SecurityAccess — sendKey  
CPR_041 La structure des messages associés aux primitives Securi ­
tyAccess «sendKey» fait l'objet d'une description détaillée 
dans les tableaux ci-après.  
Tableau 21  
Message SecurityAccess Request — sendKey  
Octet #  Nom de paramètre  Valeur hex.  Mnémonique  
#1 Octet de structure — adressage 
physique  80 FMT  
#2 Octet d'adresse de la cible  EE  TGT  
#3 Octet d'adresse de la source  tt  SRC  
#4 Octet de longueur supplémen ­
taire m+2 LEN  
#5 SecurityAccess Request 
Service Id  27 SA  
#6 accessType — sendKey  7E  AT_SK  
#7 à #m+6  Clé#1 (sup.)  xx  KEY  
… …  
Clé #m (inf., la valeur de m 
doit être comprise entre 4 et 
8 inclus)  xx 
#m+7  Total de contrôle  00-FF  CS  
Tableau 22  
Message SecurityAccess — sendKey Positive Response  
Octet #  Nom de paramètre  Valeur hex.  Mnémonique  
#1 Octet de structure — adressage 
physique  80 FMT  
#2 Octet d'adresse de la cible  tt  TGT  
#3 Octet d'adresse de la source  EE  SRC  
#4 Octet de longueur supplémen ­
taire 02 LEN  
#5 SecurityAccess Positive 
Response Service Id  67 SAPR  
#6 accessType — sendKey  7E  AT_SK  
#7 Total de contrôle  00-FF  CS  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 318  
Tableau 23  
Message SecurityAccess Negative Response  
Octet #  Nom de paramètre  Valeur 
hex. Mnémonique  
#1 Octet de structure — adressage physique  80  FMT  
#2 Octet d'adresse de la cible  tt  TGT  
#3 Octet d'adresse de la source  EE  SRC  
#4 Octet de longueur supplémentaire  03  LEN  
#5 NegativeResponse Service Id  7F  NR  
#6 SecurityAccess Request Service Id  27  SA  
#7 ResponseCode =  [generalReject  10  RC_GR  
subFunctionNotSup ­
ported  12 RC_SFNS  
incorrectMessage ­
Length  13 RC_IML  
conditionsNotCorrect 
OrRequestSequen ­
ceError  22 RC_CNC  
invalidKey  35  RC_IK  
exceededNumberOf 
Attempts  36 RC_ENA  
requestCorrectlyRe ­
ceived-ResponsePen ­
ding]  78 RC_RCR_RP  
#8 Total de contrôle  00-FF  CS  
6. SERVICES DE TRANSMISSION DE DONNÉES  
Les services disponibles font l'objet d'une description détaillée dans le 
tableau ci-après:  
Tableau 24  
Services de transmission de données  
Nom du service  Description  
ReadDataByIdentifier  Le client demande la transmission de la 
valeur actuelle d'un relevé avec accès par 
recordDataIdentifier.  
WriteDataByIdentifier  Le client demande l'enregistrement d'un 
relevé avec accès par recordDataIdentifier.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 319  
6.1. Service ReadDataByIdentifier  
6.1.1  Description des messages  
CPR_050 Le message de demande ReadDataByIdentifier est utilisé par 
le client pour demander l'extraction de valeurs enregistrées 
sur un serveur. Les données sont identifiées par recordDa ­
taIdentifier. 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  Structure des messages  
CPR_051 La structure des messages associés aux primitives ReadDa ­
taByIdentifier fait l'objet d'une description détaillée dans les 
tableaux ci-après.  
Tableau 25  
Message ReadDataByIdentifier Request  
Octet #  Nom de paramètre  Valeur hex.  Mnémonique  
#1 Octet de structure — adressage 
physique  80 FMT  
#2 Octet d'adresse de la cible  EE  TGT  
#3 Octet d'adresse de la source  tt  SRC  
#4 Octet de longueur supplémen ­
taire 03 LEN  
#5 ReadDataByIdentifier 
Request Service Id  22 RDBI  
#6 à #7  recordDataIdentifier = [une 
valeur extraite du Tableau 28]  xxxx  RDI_…  
#8 Total de contrôle  00-FF  CS  
Tableau 26  
Message ReadDataByIdentifier Positive Response  
Octet #  Nom de paramètre  Valeur 
hex. Mnémonique  
#1 Octet de structure — adressage 
physique  80 FMT  
#2 Octet d'adresse de la cible  tt  TGT  
#3 Octet d'adresse de la source  EE  SRC  
#4 Octet de longueur supplémentaire  m+3  LEN  
#5 ReadDataByIdentifier Positive 
Response Service Id  62 RDBIPR  
#6 et #7  recordDataIdentifier = [même valeur 
que les octets #6 et #7 Tableau 25]  xxxx  RDI_...  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 320  
Octet #  Nom de paramètre  Valeur 
hex. Mnémonique  
#8 à #m+7  dataRecord[] =  [data#1  xx  DREC_DAT ­
A1 
: :  :  
data#m]  xx  DREC_DA ­
TAm  
#m+8  Total de contrôle  00-FF  CS  
Tableau 27  
Message ReadDataByIdentifier Negative Response  
Octet #  Nom de paramètre  Valeur 
hex. Mnémonique  
#1 Octet de structure — adressage physique  80  FMT  
#2 Octet d'adresse de la cible  tt  TGT  
#3 Octet d'adresse de la source  EE  SRC  
#4 Octet de longueur supplémentaire  03  LEN  
#5 NegativeResponse Service Id  7F  NR  
#6 ReadDataByIdentifier Request Service Id  22  RDBI  
#7 ResponseCode=  [requestOutOf 
Range  31 RC_ROOR  
incorrectMessage ­
Length  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  recordDataIdentifier (RDI_)  dans le message 
de demande ReadDataByIdentifier identifie un relevé de 
données.  
CPR_053 Les valeurs recordDataIdentifier définies par le présent 
document figurent dans le tableau ci-après.  
Ce tableau recordDataIdentifier se compose de quatre 
colonnes et d'un certain nombre de lignes.  
— La  1 re colonne (Hex.)  indique la «Valeur hex.» affectée 
à recordDataIdentifier spécifié dans la 3  e colonne.  
— La 2  e colonne (Élément de donnée)  indique l'élément 
de donnée de l'Appendice 1 sur lequel est basé record ­
DataIdentifier (un transcodage est parfois nécessaire).  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 321  
— La 3  e colonne (Description)  spécifie le nom recordDa ­
taIdentifier correspondant.  
— La  4 e colonne (Mnémonique)  indique le mnémonique 
associé à ce recordDataIdentifier.  
Tableau 28  
Définition des valeurs recordDataIdentifier  
Hex.  Élément de données  Nom du recordDataIdentifier 
(voir la structure indiquée à la 
Section 8.2)  Mnémonique  
F90B
  CurrentDateTime  RDI_TD  
F912
  HighResOdometer  RDI_HRTVD  
F918
  K-ConstantOfRecordingE ­
quipment  RDI_KF  
F91C
  L-TyreCircumference  RDI_LF  
F91D
  W-VehicleCharacteristic ­
Constant  RDI_WVCF  
F921
  TyreSize  RDI_TS  
F922
  nextCalibrationDate  RDI_NCD  
F92C
  SpeedAuthorised  RDI_SA  
F97D
  vehicleRegistrationNation  RDI_RMS  
F97E
  VehicleRegistrationNumber  RDI_ VRN  
F190
  VehicleIdentificationNumber  RDI_ VIN  
CPR_054 Le paramètre  dataRecord (DREC_)  est utilisé par le 
message de réponse positive ReadDataByIdentifier pour 
fournir au client (appareil d'essai) la valeur du relevé de 
données identifiée par recordDataIdentifier. Les structures 
de données sont indiquées à la Section 8. D'autres dataRe ­
cords facultatifs, telles que les entrées propres à la VU ainsi 
que les données de sortie internes et externes, peuvent être 
obtenus au choix de l'utilisateur, mais ils ne sont pas définis 
dans le présent document.  
6.2. Service WriteDataByIdentifier  
6.2.1  Description des messages  
CPR_056 Le client a recours au service WriteDataByIdentifier pour 
procéder à l'enregistrement de valeurs associées aux relevés 
de données sur un serveur. Les données sont identifiées par 
recordDataIdentifier. C'est au fabricant de la VU qu'incombe 
la responsabilité de s'assurer que les conditions d'exploita ­
tion normale du serveur sont réunies lors de l'exécution de 
ce service. Pour procéder à l'actualisation des paramètres 
répertoriés au Tableau 28, il faut que la VU soit exploitée 
en mode ÉTALONNAGE.  
6.2.2  Structure des messages  
CPR_057 La structure des messages associés aux primitives WriteDa ­
taByIdentifier fait l'objet d'une description détaillée dans les 
tableaux ci-après.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 322  
Tableau 29  
Message WriteDataByIdentifier Request  
Octet #  Nom de paramètre  Valeur 
hex. Mnémonique  
#1 Octet de structure — adressage 
physique  80 FMT  
#2 Octet d'adresse de la cible  EE  TGT  
#3 Octet d'adresse de la source  tt  SRC  
#4 Octet de longueur supplémentaire  m+3  LEN  
#5 WriteDataByIdentifier Request 
Service Id  2E WDBI  
#6 à #7  recordDataIdentifier = [une valeur 
extraite du Tableau 28]  xxxx  RDI_…  
#8 à m+7  dataRecord[] =  [data#1  xx  DREC_DAT ­
A1 
: :  :  
data#m]  xx  DREC_DA ­
TAm  
#m+8  Total de contrôle  00-FF  CS  
Tableau 30  
Message WriteDataByIdentifier Positive Response  
Octet #  Nom de paramètre  Valeur hex.  Mnémonique  
#1 Octet de structure — adressage 
physique  80 FMT  
#2 Octet d'adresse de la cible  tt  TGT  
#3 Octet d'adresse de la source  EE  SRC  
#4 Octet de longueur supplémen ­
taire 03 LEN  
#5 WriteDataByIdentifier Posi ­
tive Response Service 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  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 323  
Tableau 31  
Message WriteDataByIdentifier Negative Response  
Octet #  Nom de paramètre  Valeur 
hex. Mnémonique  
#1 Octet de structure — adressage physique  80  FMT  
#2 Octet d'adresse de la cible  tt  TGT  
#3 Octet d'adresse de la source  EE  SRC  
#4 Octet de longueur supplémentaire  03  LEN  
#5 NegativeResponse Service Id  7F  NR  
#6 WriteDataByIdentifier Request Service Id  2E  WDBI  
#7 ResponseCode=  [requestOutOf 
Range  31 RC_ROOR  
incorrectMessage ­
Length  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  recordDataIdentifier (RDI_)  est défini au Tableau 28.  
Le paramètre  dataRecord (DREC_)  est utilisé pour le message de 
demande WriteDataByIdentifier afin de fournir au serveur (VU) les 
valeurs de relevé identifiées par le recordDataIdentifier. Les structures 
de données sont indiquées à la section 8.  
7. CONTRÔLE DES IMPULSIONS D'ESSAI — UNITÉ FONCTION ­
NELLE DE CONTRÔLE DES ENTRÉES/SORTIES  
Les services disponibles font l'objet d'une description détaillée dans le 
tableau ci-après:  
Tableau 32  
Unité fonctionnelle de contrôle des entrées/sorties  
Nom du service  Description  
InputOutputControl ­
ByIdentifier  Le client demande le contrôle d'une entrée/ 
sortie propre au serveur.  
7.1. Service InputOutputControlByIdentifier  
7.1.1  Description des messages  
La connexion réalisée par l'intermédiaire du connecteur frontal permet 
de contrôler ou de surveiller les impulsions d'essai au moyen d'un 
testeur approprié.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 324  
CPR_058 Il est possible de configurer cette ligne de signalisation 
d'entrée/sortie par le biais d'une commande lancée sur la 
ligne K en recourant au service InputOutputControlByIden ­
tifier 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/ 
sortie est utilisée pour entrer un signal de vitesse (signal 
d'essai) en remplacement du signal de vitesse du détec ­
teur de mouvement; cette fonction n'est pas disponible 
en mode CONTRÔLE,  
— realTimeSpeedSignalOutputSensor, où la ligne de signa ­
lisation d'entrée/sortie est utilisée pour la sortie du signal 
de vitesse du détecteur de mouvement;  
— RTCOutput, où la ligne de signalisation d'entrée/sortie 
d'étalonnage est utilisée pour la sortie du signal de l'hor ­
loge 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 ÉTALONNAGE 
ou CONTRÔLE. Lorsque la VU est en mode ÉTALON ­
NAGE, les quatre états de la ligne peuvent être sélectionnés 
(désactivé; speedSignalInput; realTimeSpeedSignalOutput ­
Sensor; RTCOutput). Lorsque la VU est en mode 
CONTRÔLE, seuls deux états de lignes peuvent être sélec ­
tionnés (désactivé; realTimeSpeedOutputSensor). Lorsque 
l'opérateur décide de sortir du ÉTALONNAGE ou 
CONTRÔLE, l'unité embarquée sur véhicule doit s'assurer 
que la ligne de signalisation d'entrée/sortie d'étalonnage est 
revenue à son état de désactivation (par défaut).  
CPR_060 En cas de réception d'impulsions de vitesse 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'intercommunication par le 
biais du service StartCommunication.  
— Entrée en session de réglage par le biais du service 
StartDiagnosticSession et passage en mode d'exploita ­
tion ÉTALONNAGE ou CONTRÔLE (l'ordre d'exécu ­
tion de ces deux opérations est sans importance).  
— Modification de l'état de la sortie par le biais du service 
InputOutputControlByIdentifier.  
7.1.2  Structure des messages  
CPR_062 La structure des messages associés aux primitives InputOut ­
putControlByIdentifier fait l'objet d'une description détaillée 
dans les tableaux ci-après.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 325  
Tableau 33  
Message InputOutputControlByIdentifier Request  
Octet #  Nom de paramètre  Valeur hex.  Mnémonique  
#1 Octet de structure — adressage 
physique  80 FMT  
#2 Octet d'adresse de la cible  EE  TGT  
#3 Octet d'adresse de la source  tt  SRC  
#4 Octet de longueur supplémen ­
taire xx LEN  
#5 InputOutputControlByIden ­
tifier Request Sid  2F IOCBI  
#6 et #7  InputOutputIdentifier = [Cali ­
brationInputOutput]  F960  IOI_CIO  
#8 ou 
#8 à #9  ControlOptionRecord = [  COR_…  
inputOutputControlParameter 
— une valeur extraite du 
Tableau 36  xx IOCP_…  
controlState — 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 InputOutputControlByIdentifier Positive Response  
Octet #  Nom de paramètre  Valeur hex.  Mnémonique  
#1 Octet de structure — adressage 
physique  80 FMT  
#2 Octet d'adresse de la cible  tt  TGT  
#3 Octet d'adresse de la source  EE  SRC  
#4 Octet de longueur supplémen ­
taire xx LEN  
#5 inputOutputControlByIdenti ­
fier Positive Response SId  6F IOCBIPR  
#6 et #7  inputOutputIdentifier = [Cali ­
brationInputOutput]  F960  IOI_CIO  
#8 ou 
#8 à #9  controlStatusRecord = [  CSR_  
inputOutputControlParameter 
(valeur identique à l'octet #8 
Tableau 33)  xx IOCP_…  
controlState (valeur identique à 
l'octet #9 Tableau 33)] (le cas 
échéant)  xx CS_…  
#9 ou #10  Total de contrôle  00-FF  CS  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 326  
Tableau 35  
Message InputOutputControlByIdentifier Negative Response  
Octet #  Nom de paramètre  Valeur hex.  Mnémonique  
#1 Octet de structure — adressage 
physique  80 FMT  
#2 Octet d'adresse de la cible  tt  TGT  
#3 Octet d'adresse de la source  EE  SRC  
#4 Octet de longueur supplémen ­
taire 03 LEN  
#5 negativeResponse Service Id  7F  NR  
#6 inputOutputControlByIdentifier 
Request SId  2F IOCBI  
#7 responseCode=[  
incorrectMessageLength  13  RC_IML  
conditionsNotCorrect  22  RC_CNC  
requestOutOfRange  31  RC_ROOR  
deviceControlLimitsExceeded]  7A  RC_DCLE  
#8 Total de contrôle  00-FF  CS  
7.1.3  Définition du paramètre  
CPR_064 Le paramètre  inputOutputControlParameter (IOCP_)  est 
défini dans le tableau ci-après.  
Tableau 36  
Définition des valeurs inputOutputControlParameter  
Hex.  Description  Mnémonique  
00 ReturnControlToECU  
Cette valeur doit indiquer au serveur (VU) que 
l'appareil d'essai ne commande plus la ligne de 
signalisation d'E/S.  RCTECU  
01 ResetToDefault  
Cette valeur doit indiquer au serveur (VU) qu'il 
est tenu de ramener à son état initial la ligne de 
signalisation E/S.  RTD ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 327  
Hex.  Description  Mnémonique  
03 ShortTermAdjustment  
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 
controlState.  STA  
CPR_065 Le paramètre  controlState  n'apparaît que lorsque le inpu ­
tOutputControlParameter est configuré comme ShortTer ­
mAdjustment et défini dans le tableau ci-après:  
Tableau 37  
Définition des valeurs controlState  
Mode  Valeur hex.  Description  
Désactivé  00  Ligne d'E/S désactivée (par défaut)  
Activé  01  Active la ligne E/S d'étalonnage comme 
speedSignalInput  
Activé  02  Active la ligne E/S d'étalonnage comme 
realTimeSpeedSignalOutputSensor  
Activé  03  Active la ligne E/S d'étalonnage comme 
RTCOutput  
8. STRUCTURES DES DATARECORDS  
Le présent chapitre expose en détail:  
— les règles générales applicables aux gammes de paramètres trans ­
mises 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'intermé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 
observé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.  
CPR_070 Les valeurs de la gamme «indicateur d'erreur» permettent à 
l'unité embarquée sur le véhicule d'indiquer immédiatement 
qu'aucune donnée paramétrique valable n'est actuellement 
disponible en raison d'une erreur quelconque au niveau du 
tachygraphe.  
CPR_071 Les valeurs de la gamme «non disponible» permettent à 
l'unité embarquée sur le véhicule de transmettre un 
message contenant 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écepteur n'attend pas de réponse.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 328  
CPR_072 Lorsque la défaillance d'un composant empêche la transmis ­
sion de données valables pour un paramètre, il convient 
d'utiliser l'indicateur d'erreur décrit au Tableau 38 à la 
place des données de ce paramètre. Toutefois, 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 
convient dans ce cas de transmettre les données en utilisant 
la valeur paramétrique minimale ou maximale appropriée.  
Tableau 38  
Plages de dataRecords  
Nom de la gamme  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éservée aux futurs bits 
de l'indicateur  FC à FD  FC00 à FDFF  FC000000 à FDFFFFFF  aucun  
Indicateur d'erreur  FE  FE00 à FEFF  FE000000 à FEFFFFFF  0  
Non disponible ou non demandé  FF  FF00 à FFFF  FF000000 à FFFFFFFF  FF  
CPR_073 Pour les paramètres encodés en ASCII, le caractère ASCII 
«*» est réservé 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 ReadDataByIdentifier et Write ­
DataByIdentifier.  
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  
TimeDate  8  Cf. détails au Tableau 40  
HighResolutionTotalVehicle ­
Distance  4 gain 5 m/bit, décalage 0 m  0 à + 21 055 406 km  
Kfactor  2  gain 0,001 impulsion/m/bit, déca ­
lage 0  0 à 64,255 impulsion/m  
LfactorTyreCircumference  2  gain 0,125 10  – 3 m/bit, décalage 0  0 à 8,031 m  
WvehicleCharacteristicFactor  2  gain 0,001 impulsion/m/bit, déca ­
lage 0  0 à 64,255 impulsion/m  
TyreSize  15  ASCII  ASCII  
NextCalibrationDate  3  Cf. détails au Tableau 41  
SpeedAuthorised  2  gain 1/256 km/h/bit, décalage 0  0 à 250,996 km/h  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 329  
Nom de paramètre  Longueur des 
données (en octets)  Résolution  Gamme opérationnelle  
RegisteringMemberState  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érents 
octets du paramètre TimeDate:  
Tableau 40  
Structure détaillée de TimeDate (valeur de recordDataIdentifier # F90B)  
Octet  Définition du 
paramètre  Résolution  Gamme opéra ­
tionnelle  
1 Secondes  gain 0,25 s/bit, décalage 0 s  0 à 59,75 s  
2 Minutes  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 jo ­
urs 
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 
minutes  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 
NextCalibrationDate.  
Tableau 41  
Structure détaillée de NextCalibrationDate (valeur de recordDataIdentifier 
# F922)  
Octet  Définition du 
paramètre  Résolution  Gamme opéra ­
tionnelle  
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 jo ­
urs 
3 Année  gain 1 année/bit, décalage année 
+ 1985 
(voir note ci-dessous)  années 1985 à 
2235 ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 330  
Note concernant l'utilisation du paramètre «Jour»:  
1) Une valeur de 0 pour la date est nulle. Les valeurs 1, 2, 3 et 4 
servent à identifier le premier jour du mois; 5, 6, 7 et 8 identifient le 
deuxième jour du mois, etc.  
2) Ce paramètre n'influence pas ni ne modifie le paramètre des heures 
précité.  
Note concernant l'utilisation de l'octet du paramètre «Année»:  
Une valeur ‘0’ pour l'année identifie l'année 1985; une valeur ‘1’ 
identifie 1986, etc  
CPR_078 Le Tableau 42 expose en détail la structure des différents 
octets du paramètre VehicleRegistrationNumber:  
Tableau 42  
Structure détaillée du VehicleRegistrationNumber (valeur recordDataIden ­
tifier # 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'immatriculation du 
véhicule (tel que défini à l'ap ­
pendice 1)  ASCII  ASCII  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 331  
Appendice 9  
HOMOLOGATION ET LISTE DES ESSAIS MINIMAUX REQUIS  
TABLE DES MATIÈRES  
1. INTRODUCTION  
2. ESSAIS FONCTIONNELS DE L'UNITÉ EMBARQUÉE SUR LE VÉHI ­ 
CULE  
3. ESSAIS DE FONCTIONNEMENT DU CAPTEUR DE MOUVEMENT  
4. ESSAIS DE FONCTIONNEMENT DES CARTES TACHYGRAPHIQUES  
5. ESSAIS DU DISPOSITIF GNSS EXTERNE  
▼M1 
6. ESSAIS DES ÉQUIPEMENTS EXTERNES DE COMMUNICATION À 
DISTANCE  
▼B 
7. ESSAIS FONCTIONNELS SUR LE PAPIER  
8. ESSAIS D'INTEROPÉRABILITÉ  
1. INTRODUCTION  
1.1. Homologation  
L'homologation CE destiné à un équipement (ou un composant) de contrôle 
ou à une carte tachygraphique repose sur:  
▼M1 
— une  certification de sécurité  basée sur des spécifications de critères 
communs contre une cible de sécurité parfaitement conforme à l’appen ­
dice 10 de la présente annexe,  
▼B 
— une  certification de fonctionnement  exécutée par les autorités compé ­
tentes d'un État membre certifiant que l'élément testé satisfait 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 c ertification d'interopérabilité  exécutée par l'organisme compétent 
chargé de certifier l'interopérabilité de l'appareil de contrôle (ou la carte 
tachygraphique) visé avec la carte tachygraphique (ou l'appareil de 
contrôle) indispensable (cf. chapitre 8 de la présente annexe).  
Le présent appendice précise les tests minimaux que les autorités compé ­
tentes d'un État membre doivent effectuer dans le cadre des essais de fonc ­
tionnement ainsi que les tests minimaux que l'organisme compétent 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 certification 
de sécurité. Si certains essais d'homologation sont effectués pendant le 
processus d'évaluation et de certification de la sécurité, ils n'ont pas à être 
répétés. En pareil cas, seuls les résultats de ces essais de sécurité sont 
susceptibles d'être contrôlés. À titre d'information, les exigences qui 
doivent faire l'objet d'essais (ou sont étroitement liées aux essais qu'il y a 
lieu d'exécuter) pendant la certification de sécurité sont repérées par un 
astérisque («*») dans le présent appendice.  
Les exigences numérotées font référence au corpus de l'annexe. Les autres 
exigences font référence aux autres appendices (p. ex. PIC_001 fait réfé ­
rence à l'exigence PIC_001 de l'appendice 3 Pictogrammes).  
Le présent appendice traite séparément de l'homologation du détecteur de 
mouvement, de celle de l'unité embarquée sur le véhicule et du dispositif 
GNSS externe, respectivement considérés comme des composants distincts 
de l'appareil de contrôle. Chaque composant obtient son propre certificat  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 332  
d'homologation qui dresse la liste des autres composants compatibles. 
L'essai fonctionnel du capteur de mouvement (ou du dispositif GNSS 
externe) est effectué simultanément à celui de l'unité embarquée sur le 
véhicule et vice versa.  
L'interopérabilité entre les modèles de capteurs de mouvement (ou les dispo ­
sitifs GNSS externes) et chaque modèle d'unité embarquée sur le véhicule 
n'est pas requise. Dans ce cas l'homologation d'un capteur de mouvement 
(ou des dispositifs GNSS externes) peut être attribuée en association avec 
l'homologation de l'unité embarquée sur véhicule et vice versa.  
1.2. Références  
Le présent appendice fait référence aux documents suivants:  
IEC 60068-2-1: Essais d'environnement — Partie 2-1: Essais — Essai A: 
Froid  
IEC 60068-2-2: Procédures de base pour les essais d'environnement; partie 
2: essais; essai B: chaleur sèche (sinusoïdal).  
IEC 60068-2-6: Essais d'environnement — Partie 2: Essais — Essai Fc: 
Vibrations (sinusoïdales)  
IEC 60068-2-14: Essais d'environnement; Partie 2-14: Essais; Essai N: 
Variation de température  
IEC 60068-2-27: Essais d'environnement. Part 2: Essais. Essai Ea et guide: 
Chocs  
IEC 60068-2-30: Essais d'environnement — 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 protection (codes IP) — 
Protection des équipements électriques contre les corps étrangers, l'eau et 
les contacts  
ISO 10605:2008 + Rectificatif technique: 2010 + AMD1:2014 Véhicules 
routiers — Méthodes d'essai des perturbations électriques provenant de 
décharges électrostatiques  
ISO 7637-1:2002 + AMD1: 2008 Véhicules routiers — Perturbations élec ­
triques par conduction et par couplage — Partie 1: Définitions et généralités  
ISO 7637-2 Véhicules routiers — Perturbations électriques par conduction 
et par couplage — Partie 2: Perturbations électriques transitoires par conduc ­
tion uniquement le long des lignes d'alimentation.  
ISO 7637-3 Véhicules routiers — Perturbations électriques par conduction 
et par couplage — Partie 3: Transmission des perturbations électriques par 
couplage capacitif ou inductif le long des lignes autres que les lignes d'ali ­
mentation.  
ISO/IEC 7816-1 Cartes d'identification — Cartes à circuit intégré — Partie 
1: Cartes à contacts — Caractéristiques physiques.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 333  
ISO/IEC 7816-2 Cartes d'identification — Cartes à circuit intégré — Partie 
2: Dimensions et emplacements des contacts.  
ISO/IEC 7816-3 Cartes d'identification — Cartes à circuit intégré — Partie 
3: Interface électrique et protocoles de transmission.  
ISO/IEC 10373-1:2006 + AMD1:2012 ICartes d'identification — Méthodes 
d'essai — Partie 1: Caractéristiques générales  
ISO/IEC 10373-3:2010 + Rectificatif technique:2013 ICartes d'identification 
— Méthodes d'essai — Partie 3: Cartes à circuit(s) intégré(s) à contacts et 
dispositifs d'interface assimilés  
ISO 16844-3:2004, Cor 1:2006 Véhicules routiers — Systèmes tachy ­
graphes — Partie 3: Interface de capteur de mouvement (avec les unités 
embarquées sur le véhicule).  
ISO 16844-4 Véhicules routiers — Systèmes tachygraphes — Partie 4: 
Interface CAN  
ISO 16844-6 Véhicules routiers — Systèmes tachygraphes — Partie 6: 
Diagnostic  
ISO 16844-7 Véhicules routiers — Systèmes tachygraphes — Partie 7: 
Paramètres  
ISO 534 Papier et carton – Détermination de l'épaisseur, de la masse volu ­
mique et du volume spécifique  
UN ECE R10 Prescriptions uniformes relatives à l'homologation des véhi ­
cules en ce qui concerne la compatibilité électromagnétique (Commission 
économique pour l'Europe des Nations unies)  
2. ESSAIS FONCTIONNELS DE L'UNITÉ EMBARQUÉE SUR LE VÉHI ­
CULE  
▼M1 
N o Essai  Description  Exigences connexes  
1. Examen administratif  
1.1 Documentation  Exactitude de la documentation  
1.2 Résultats des essais 
menés par le fabricant  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 Conformité avec la documentation  
2.2 Identification/marquage  224 à 226  
2.3 Matériaux  219 à 223  
2.4 Scellements  398, 401 à 405  
2.5 Interfaces externes  
3. Essais de fonctionnement  
3.1 Fonctions prévues  02, 03, 04, 05, 07, 382  
3.2 Modes d’exploitation  09 à 11*, 134, 135  
3.3 Droits d’accès aux fonctions et données  12* 13*, 382, 383, 386 à 389  
3.4 Surveillance de l’insertion et du retrait des cartes  15, 16, 17, 18, 19*, 20*, 134  
3.5 Mesure de la vitesse et de la distance  21 à 31  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 334  
N o Essai  Description  Exigences connexes  
3.6 Chronométrage (essai exécuté à 20 °C)  38 à 43  
3.7 Surveillance des activités du conducteur  44 à 53, 134  
3.8 Surveillance de l’état de conduite  54, 55, 134  
3.9 Entrées manuelles  56 à 62  
3.10 Gestion des dispositifs de verrouillage de l’entreprise  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, 134  
3.13 Données d’identification des équipements  93*, 94*, 97, 100  
3.14 Données d’insertion et de retrait de la carte du conducteur  102* à 104*  
3.15 Données relatives aux activités du conducteur  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’étalonnage  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’entreprise  128*  
3.25 Téléchargement de données relatives aux activités  129*  
3.26 Données relatives aux conditions particulières  130*, 131*  
3.27 Enregistrement et mémorisation sur les cartes tachygraphiques  136, 137, 138*, 139*, 141*, 
142, 143 
144, 145, 146*, 147*, 148*, 
149, 150  
3.28 Affichage  90, 134, 
151 à 168, 
PIC_001, DIS_001  
3.29 Impression  90, 134, 
169 à 181, PIC_001, PRT_001 
à PRT_014  
3.30 Avertissement  134, 182 à 191, 
PIC_001  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 335  
N o Essai  Description  Exigences connexes  
3.31 Téléchargement de données à destination de supports externes  90, 134, 192 à 196  
3.32 Communication à distance pour les contrôles routiers ciblés  197 à 199  
3.33 Données de sortie à destination de dispositifs externes supplémentaires  200, 201  
3.34 Étalonnage  202 à 206*, 383, 384, 386 à 
391 
3.35 Contrôles routiers d’étalonnage  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 Interface des capteurs de mouvement  02, 122  
3.39 Dispositif GNSS externe  03, 123  
3.40 Vérifier que la VU détecte, enregistre et stocke les événements et/ou 
anomalies défini(e)s par le fabricant de la VU lorsqu’un capteur de 
mouvement couplé réagit à des champs magnétiques qui perturbent la 
détection des mouvements du véhicule.  217 
3.41 Suite de chiffrement et paramètres de domaines normalisés  CSM_48, CSM_50  
4. Essais environnementaux  
4.1 Température  S’assurer de la fonctionnalité en exécutant les 
essais suivants: 
Essai conforme à 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’environnement — Partie 2-1: essais - 
essai A: froid 
Essai conforme à 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 conforme à la norme ISO 16750-4: 
Chapitre 5.3.2: Variation rapide de tempéra ­
ture avec durée de transition spécifiée 
(– 20 °C/70 °C, 20 cycles, temps de maintien 
de 2 h à chaque température). 
Il est possible de se livrer à un nombre limité 
d’essais (parmi 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éhi ­
cule 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, comportant 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 ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 336  
N o Essai  Description  Exigences connexes  
4.3 Mécanique  1. Vibrations sinusoïdales. 
S’assurer que l’unité embarquée sur le 
véhicule est capable de résister à des vibra ­
tions sinusoïdales possédant les caractéris ­
tiques suivantes: 
déplacement constant compris entre 5 et 
11 Hz: 10 mm max; 
accélération constante comprise entre 11 et 
300 Hz: 5 g 
L’essai CEI 60068-2-6, essai Fc, permet 
de vérifier la satisfaction de cette exigence. 
La durée minimale de cet essai s’élève à 
3 × 12 heures (12 heures par essieu). 
La norme ISO 16750-3 n’impose pas 
d’essai de vibrations sinusoïdales aux 
dispositifs situés dans la cabine découplée 
du véhicule. 
2. Vibrations aléatoires: 
Essai conforme à la norme ISO 16750-3: 
Chapitre 4.1.2.8: Essai VIII: Véhicule 
commercial, cabine de véhicule découplée. 
Essai de vibrations aléatoires, 10...2 
000 Hz, RMS vertical 21,3 m/s  2 , RMS 
longitudinal 11,8 m/s  2 , RMS latéral 
13,1 m/s  2 , 3 essieux, 32 h par essieu, y 
compris un cycle de température 
– 20...70 °C. 
Cet essai satisfait à la norme CEI 60068-2- 
64: Essais d’environnement — Partie 2-64: 
Essais — Essai Fh: Vibrations aléatoires à 
large bande et guide 
3. Chocs: 
choc mécanique d’un demi-sinus de 3 g 
conformément à la norme ISO 16750. 
Il convient d’exécuter les essais décrits ci- 
avant sur des échantillons distincts du type 
d’équipement testé.  219 
4.4 Protection contre l’eau 
et les corps étrangers  Essai conforme à la norme ISO 20653: Véhi ­
cules routiers - Degrés de protection (codes 
IP) - Protection des équipements électriques 
contre les corps étrangers, l’eau et les contacts 
(paramètres inchangés); valeur minimale IP 
40 220, 221  
4.5 Protection contre les 
surtensions  S’assurer que l’unité embarquée sur le véhi ­
cule est capable de supporter une tension 
d’alimentation de: 
versions 24 V: 34 V à +40 °C 1 heure 
versions 12 V: 17 V à + 40 °C 1 heure 
(ISO 16750-2)  216 ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 337  
N o Essai  Description  Exigences connexes  
4.6 Protection contre les 
inversions de polarité  S’assurer que l’unité embarquée sur le véhi ­
cule est capable de supporter une inversion de 
polarité au niveau de son alimentation élec ­
trique 
(ISO 16750-2)  216 
4.7 Protection contre les 
courts-circuits  S’assurer que les signaux d’entrée et de sortie 
sont protégés contre les courts-circuits à l’ali ­
mentation électrique et à la terre 
(ISO 16750-2)  216 
5. Essais de compatibilité électromagnétique  
5.1 Émissions rayonnées et 
sensibilité  Conformité avec le règlement CEE R10  218  
5.2 Décharge électrostati ­
que Conformité avec la norme ISO 10605:2008 + 
Rectificatif technique: 2010 + 
AMD1:2014: +/- 4 kV pour le contact et +/- 
8 kV pour la décharge d’air  218 
5.3 Susceptibilité transi ­
toire par conduction 
au niveau de l’alimen ­
tation  Pour les versions 24 V: conformité avec la 
norme ISO 7637-2 + Règlement CEE n  o 10 
Rév. 3: 
impulsion 1a: Vs = – 450 V Ri = 50 ohms 
impulsion 2a: Vs = +37V Ri = 2 ohms 
impulsion 2b: Vs = +20V Ri = 0,05 ohms 
impulsion 3a: Vs = – 150V Ri = 50 ohms 
impulsion 3b: Vs = +150V 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 12V: conformité avec la 
norme ISO 7637-1 + Règlement CEE n  o 10 
Rév. 3: 
impulsion 1: Vs = –+75V Ri = 10 ohms 
impulsion 2a: Vs = +37V Ri = 2 ohms 
impulsion 2b: Vs = +10V Ri = 0,05 ohms 
impulsion 3a: Vs = – 112V Ri = 50 ohms 
impulsion 3b: Vs = +75V 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’impulsion 5 ne sera testée que pour les 
unités à installer sur des véhicules dépourvus 
de dispositif commun de protection externe 
contre la perte de charge. 
Pour la proposition concernant la perte de 
charge, consulter la norme ISO 16750-2, 4  e 
édition, chapitre 4.6.4.  218 ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 338  
3. ESSAIS DE FONCTIONNEMENT DU CAPTEUR DE MOUVEMENT  
N o Essai  Description  Exigences connexes  
1. Examen administratif  
1.1 Documentation  Exactitude de la documentation  
2. Inspection visuelle  
2.1. Conformité avec la documentation  
2.2. Identification/marquage  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 capteur  95 à 97*  
3.2 Appariement capteur 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 Interface d'unité embarquée sur le véhicule  02  
3.5 Vérifier que le capteur de mouvement est immunisé contre les champs magné ­
tiques constants. Autrement, vérifier que le capteur 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étecter, enregistrer et stocker les 
anomalies du capteur  217 
4. Essais environnementaux  
4.1 Température d'exploitation  S'assurer de la fonctionnalité de ce composant 
(telle qu'elle est définie dans le test n  o 3.3) pour 
la plage 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 
To min 
CEI 60068-2-2 essai Bd, en appliquant une durée 
d'essai de 96 heures à la température maximale 
Tomax 
Essai conforme à 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'environnement — 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 conforme à 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 ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 339  
N o Essai  Description  Exigences connexes  
4.2 Cycles de température  Essai conforme à 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: essais — essai N: changement 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 n  o 3.3) en exécutant 
l'essai CEI 60068-2-30, essai Db, comportant 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.4 vibrations  ISO 16750-3: Chapitre 4.1.2.6: Essai VI: Véhicule 
commercial, moteur, engrenage 
Essai de vibration en mode mixte comprenant 
a) un essai de vibrations sinusoïdales, 20...520 Hz, 
11.4 … 120 m/s  2 , <= 0,5 oct/min 
b) un essai de vibrations aléatoires, 10...2 000 Hz, 
RMS 177 m/s  2 
94 h par essieu, avec un cycle de température – 
20…70 °C) 
Cet essai satisfait à la norme CEI 60068-2-80: 
Essais d'environnement — Partie 2-80: Essais — 
Essai Fi: Vibrations — Mode mixte  219 
4.5 Chocs mécaniques  ISO 16750-3: Chapitre 4.2.3: Essai VI: Essai pour 
dispositifs dans ou sur l'engrenage 
Choc demi-sinusoïdal, accélération à convenir 
dans la plage entre 3 000…15 000 m/s  2 , durées 
de l'impulsion à convenir, cependant < 1 ms, 
nombre de chocs: à convenir 
Cet essai satisfait à la norme CEI 60068-2-27: 
Essais d'environnement. Partie 2: Essais. Essai 
Ea et guide: Chocs  219 
4.6 Protection contre l'eau et les 
corps étrangers  Essai conforme à la norme ISO 20653: Véhicules 
routiers — Degrés de protection (code IP) — 
Protection des équipements électriques contre les 
corps étrangers, l'eau et les contacts 
(Valeur cible IP 64)  220, 221  
4.7 Protection contre les inver ­
sions de polarité  S'assurer que le détecteur de mouvement est 
capable de supporter une inversion de polarité au 
niveau de son alimentation électrique  216 
4.8 Protection contre les courts- 
circuits  S'assurer que les signaux d'entrée et de sortie sont 
protégés contre les courts-circuits à l'alimentation 
électrique et à la terre  216 ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 340  
N o Essai  Description  Exigences connexes  
5. Essais de compatibilité électromagnétique  
5.1 Émissions rayonnées et 
sensibilité  Contrôler la conformité avec le règlement CEE 
R10 218 
5.2 Décharge électrostatique  Conformité avec la norme ISO 10605:2008 + Recti ­
ficatif technique:2010 + AMD1:2014: +/– 4 kV 
pour le contact et +/– 8 kV pour la décharge d'air  218 
5.3 Susceptibilité transitoire par 
conduction au niveau des 
lignes de transmission de 
données  Pour les versions 24 V: conformité avec la norme 
ISO 7637-2 + Règlement CEE n  o 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: conformité avec la norme 
ISO 7637-1 + Règlement CEE n  o 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'impulsion 5 ne sera testée que pour les unités à 
installer sur des véhicules dépourvus de dispositif 
commun de protection externe contre la perte de 
charge. 
Pour la proposition concernant la perte de charge, 
consulter la norme ISO 16750-2, 4e édition, 
chapitre 4.6.4  218 
4. ESSAIS DE FONCTIONNEMENT DES CARTES TACHYGRAPHIQUES  
Essais conformes à la présente Section 4,  
n o 5 «Essais de protocole»,  
n o 6 «Structure de la carte» et  
n o 7 «Essais de fonctionnement»  
peuvent être effectués par l'évaluateur ou le certificateur pendant la procé ­
dure de certification de la sécurité 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 modification de l'un de ces composants (corps de la carte ou module 
du circuit), les essais deviennent nécessaires.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 341  
N o Essai  Description  Exigences connexes  
1. Examen administratif  
1.1 Documentation  Exactitude de la documentation  
2 Corps de la carte  
2.1 Conception imprimée  S'assurer de la conformité et de la qualité d'impres ­
sion de toutes les fonctions de protection et données 
visibles. 
[Indicatif] 
Annexe 1C, chapitre 4.1 «Données visibles», 227) 
La première page doit comporter: 
les mots «carte de conducteur» ou «carte de contrô ­
leur» ou «carte d'atelier» ou «carte d'entreprise» 
imprimé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] 
Annexe 1C, chapitre 4.1 «Données visibles», 228) 
La première page doit comporter: 
le nom de l'État membre qui a délivré la carte 
(facultatif). 
[Signature] 
Annexe 1C, chapitre 4.1 «Données visibles», 229) 
La première page doit comporter: 
le signe distinctif de l'État membre qui a délivré la 
carte, imprimé en négatif dans un rectangle bleu et 
entouré de 12 étoiles jaunes. 
[Énumération] 
Annexe 1C, chapitre 4.1 «Données visibles», 232 
Le verso doit comporter: 
une légende des numéros indiqués au recto. 
[Couleur] 
Annexe 1C, chapitre 4.1 «Données visibles», 234) 
Les cartes tachygraphiques doivent être imprimées sur 
les fonds de couleur suivants: 
— carte du conducteur: blanche, 
— carte d'atelier: rouge, 
— carte de contrôle: bleu, 
— carte d'entreprise: jaune.  227 à 229*, 232, 234 à 
236 ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 342  
N o Essai  Description  Exigences connexes  
[Sécurité] 
Annexe 1C, chapitre 4.1 «Données visibles», 235) 
Les cartes tachygraphiques présentent au minimum les 
éléments de protection suivants contre la contrefaçon 
et la manipulation du corps de la carte: 
— impression de fond de sécurité finement guillo- 
chée et irisée, 
— au moins une ligne bicolore micro-imprimée. 
[Marquage] 
Annexe 1C, chapitre 4.1 «Données visibles», 236 
Les États membres ajoutent des couleurs ou des 
marquages, comme des symboles nationaux et des 
caractéristiques de sécurité. 
[Marque d'homologation] 
Les cartes tachygraphiques contiennent une marque 
d'homologation. 
La marque d'homologation est composée: 
— d'un rectangle à 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'homologation, 
— d'un numéro d'homologation correspondant au 
numéro du certificat d'homologation établie pour 
une carte tachygraphique, placé dans une position 
quelconque à proximité du rectangle.  
2.2 Essais mécaniques  
[Taille de la carte] 
Les cartes tachygraphiques doivent respecter la 
norme 
ISO/CEI 7810 Cartes d'identification — Caractéris ­
tiques 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 tachygraphiques doivent respecter la norme 
ISO/CEI 7810 Cartes d'identification — Caractéris- 
tiques physiques, 
[5] Dimension de la carte, 
[5.1] Taille de la carte, 
[5.1.2] Bords de la carte  240, 243 
ISO/CEI 7810  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 343  
N o Essai  Description  Exigences connexes  
[Construction de la carte] 
Les cartes tachygraphiques doivent respecter la norme 
ISO/CEI 7810 Cartes d'identification — Caractéris- 
tiques physiques, 
[6] Construction de la carte 
[Matériaux des cartes] 
Les cartes tachygraphiques doivent respecter la norme 
ISO/CEI 7810 Cartes d'identification — Caractéris- 
tiques physiques, 
[7] Matériaux des cartes 
[Rigidité à la flexion] 
Les cartes tachygraphiques doivent respecter la norme 
ISO/CEI 7810 Cartes d'identification — Caractéris- 
tiques physiques, 
[8] Caractéristiques de la carte, 
[8.1] Rigidité à la flexion 
[Toxicité] 
Les cartes tachygraphiques doivent respecter la norme 
ISO/CEI 7810 Cartes d'identification — Caractéris- 
tiques physiques, 
[8] Caractéristiques de la carte, 
[8.3] Toxicité 
[Résistance aux agents chimiques] 
Les cartes tachygraphiques doivent respecter la norme 
ISO/CEI 7810 Cartes d'identification — Caractéris- 
tiques physiques, 
[8] Caractéristiques de la carte, 
[8.4] Résistance aux agents chimiques 
[Stabilité de la carte] 
Les cartes tachygraphiques doivent respecter la norme 
ISO/CEI 7810 Cartes d'identification — Caractéris- 
tiques physiques, 
[8] Caractéristiques de la carte, 
[8.5] Stabilité des dimensions de la carte et déforma- 
tions à la température et à l'humidité  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 344  
N o Essai  Description  Exigences connexes  
[Lumière] 
Les cartes tachygraphiques doivent respecter la norme 
ISO/CEI 7810 Cartes d'identification — Caractéris- 
tiques physiques, 
[8] Caractéristiques de la carte, 
[8.6] Lumière 
[Durabilité] 
Annexe 1C, chapitre 4.4 «Spécifications environne- 
mentales et électriques», 241) 
Les cartes tachygraphiques doivent pouvoir fonction- 
ner correctement pendant une période de cinq ans si 
elles sont utilisées conformément aux spécifications 
environnementales et électriques. 
[Résistance au pelage] 
Les cartes tachygraphiques doivent respecter la norme 
ISO/CEI 7810 Cartes d'identification — Caractéris- 
tiques physiques, 
[8] Caractéristiques de la carte, 
[8.8] Résistance au pelage 
[Adhésion ou blocage] 
Les cartes tachygraphiques doivent respecter la norme 
ISO/CEI 7810 Cartes d'identification — Caractéris- 
tiques physiques, 
[8] Caractéristiques de la carte, 
[8.9] Adhésion ou blocage 
[Déformation] 
Les cartes tachygraphiques doivent respecter la norme 
ISO/CEI 7810 Cartes d'identification — Caractéris- 
tiques physiques, 
[8] Caractéristiques de la carte, 
[8.11] Déformation globale de la carte 
[Résistance à la chaleur] 
Les cartes tachygraphiques doivent respecter la norme 
ISO/CEI 7810 Cartes d'identification — Caractéris- 
tiques physiques, 
[8] Caractéristiques de la carte, 
[8.12] Résistance à la chaleur  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 345  
N o Essai  Description  Exigences connexes  
[Déformations de surface] 
Les cartes tachygraphiques doivent respecter la norme 
ISO/CEI 7810 Cartes d'identification — Caractéris- 
tiques physiques, 
[8] Caractéristiques de la carte, 
[8.13] Déformations de surface 
[Contamination] 
Les cartes tachygraphiques doivent respecter la norme 
ISO/CEI 7810 Cartes d'identification — Caractéris- 
tiques physiques, 
[8] Caractéristiques 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 tachygraphiques doivent respecter la 
norme 
ISO/CEI 7810:2003/Amd. 1:2009, Cartes d'identifi ­
cation — Caractéristiques physiques, Amendement 
1: Critères des cartes contenant des circuits intégrés 
[9.2] Contraintes de flexion dynamique 
Nombre total de cycles de flexion: 4 000. 
[Torsion] 
Les cartes tachygraphiques doivent respecter la norme 
ISO/CEI 7810:2003/Amd. 1:2009, Cartes d'identifica- 
tion — Caractéristiques physiques, Amendement 1: 
Critères des cartes contenant 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 tachygraphiques doivent respecter la 
norme. 
ISO/CEI 7816-1:2011, Cartes d'identification — 
Cartes à circuit intégré — Partie 1: Cartes avec 
contacts — Caractéristiques physiques 
[4.2] Profil de surface des contacts  ISO/CEI 7816  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 346  
N o Essai  Description  Exigences connexes  
[Résistance mécanique] 
Les cartes tachygraphiques doivent respecter la 
norme 
ISO/CEI 7816-1:2011, Cartes d'identification — 
Cartes à circuit intégré — Partie 1: Cartes avec 
contacts — Caractéristiques physiques 
[4.3] Résistance mécanique (d'une carte et des 
contacts) 
[Résistance électrique] 
Les cartes tachygraphiques doivent respecter la norme 
ISO/CEI 7816-1:2011, Cartes d'identification — 
Cartes à circuit intégré — Partie 1: Cartes avec 
contacts — Caractéristiques physiques 
[4.4] Résistance électrique (des contacts) 
[Dimension] 
Les cartes tachygraphiques doivent respecter la norme 
ISO/CEI 7816-2:2007, Cartes d'identification — 
Cartes à circuit intégré — Partie 2 Cartes avec 
contacts — Dimensions et emplacements des contacts 
[3] Dimension des contacts 
[Emplacement] 
Les cartes tachygraphiques doivent respecter la norme 
ISO/CEI 7816-2:2007, Cartes d'identification — 
Cartes à circuit intégré — Partie 2 Cartes avec 
contacts — Dimensions et emplacements des contacts 
[4] Nombre et emplacements des contacts 
Si les modules possèdent six contacts, les contacts 
‘C4’ et ‘C8’ ne sont pas soumis à cette exigence 
d'essai.  
4 Circuit  
4.1 Circuit  
[Température d'exploitation] 
Le circuit de la carte tachygraphique fonctionne dans 
une plage de température ambiante de – 25°C à + 85 °C.  241 à 244 
CEE R10 
ISO/CEI 7810 
ISO/CEI 10373  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 347  
N o Essai  Description  Exigences connexes  
[Température et humidité] 
Annexe 1C, chapitre 4.4 «Spécifications environne ­
mentales et électriques», 241) 
Les cartes tachygraphiques doivent pouvoir fonctionner 
correctement dans toutes les conditions climatiques 
normalement observées sur le territoire communau ­
taire, et au minimum dans une gamme de température 
comprise entre – 25 °C et + 70 °C, avec des pointes 
occasionnelles à + 85 °C, «occasionnelles» signifiant 
d'une durée inférieure ou égale à 4 heures et survenant 
au maximum à 100 reprises au cours de la durée de vie 
de la carte. 
Les cartes tachygraphiques sont exposées en plusieurs 
étapes aux températures et hygrométries suivantes 
pendant une période donnée. Après chaque étape, la 
fonctionnalité électrique des cartes tachygraphiques 
fait l'objet 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 intermittence 
à + 85 °C, 50 % HR, pendant 60 min. 
6. Température de + 70 °C, 85 % HR pendant 
2 heures. 
La température augmente par intermittence 
à + 85 °C, 85 % HR, pendant 30 min. 
[Humidité] 
Annexe 1C, chapitre 4.4 «Spécifications environne- 
mentales et électriques», 242 
Les cartes tachygraphiques doivent pouvoir fonction- 
ner correctement dans une gamme d'humidité com- 
prise entre 10 % et 90 %. 
[Compatibilité électromagnétique — CEM] 
Annexe 1C, chapitre 4.4 «Spécifications environne- 
mentales et électriques», 244 
En fonctionnement, les cartes tachygraphiques doivent 
satisfaire à la réglementation CEE R10, relative à la 
compatibilité électromagnétique.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 348  
N o Essai  Description  Exigences connexes  
[Électricité statique] 
Annexe 1C, chapitre 4.4 «Spécifications environne- 
mentales et électriques», 244 
En fonctionnement, les cartes tachygraphiques doivent 
être protégées contre les décharges électrostatiques. 
Les cartes tachygraphiques doivent respecter la norme 
ISO/CEI 7810:2003/Amd. 1:2009, Cartes d'identifica- 
tion — Caractéristiques physiques, Amendement 1: 
Critères des cartes contenant des circuits intégrés 
[9.4] Électricité statique 
[9.4.1] Cartes à circuit intégré avec contacts 
Tension d'essai: 4 000 V. 
[Rayons X] 
Les cartes tachygraphiques doivent respecter la norme 
ISO/CEI 7810:2003/Amd. 1:2009, Cartes d'identifica- 
tion — Caractéristiques physiques, Amendement 1: 
Critères des cartes contenant des circuits intégrés 
[9.1] Rayons X 
[Lumière ultraviolette] 
ISO/CEI 10373-1:2006, Cartes d'identification — 
Méthodes d'essai Partie 1: Caractéristiques générales 
[5.11] Lumière ultraviolette 
[3-roues] 
Les cartes tachygraphiques doivent respecter la norme 
ISO/CEI 10373-1:2006/Amd. 1:2012, Cartes d'identi- 
fication — Méthodes d'essai — Partie 1: Caractéris- 
tiques générales, Amendement 1 
[5.22] CCI — Résistance mécanique: Essai trois roues 
pour les CCI avec contacts 
[Enveloppe] 
Les cartes tachygraphiques doivent respecter la norme 
MasterCard CQM V2.03:2013 
[11.1.3] R-L3-14-8: Essai de robustesse de l'enve- 
loppe 
[13.2.1.32] TM-422: Fiabilité mécanique: Essai 
d'enveloppe  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 349  
N o Essai  Description  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 tachygraphiques doivent respecter la 
norme 
ISO/CEI 7810:2003/Amd. 1:2009, Cartes d'identifi ­
cation — Caractéristiques physiques, Amendement 
1: Critères des cartes contenant des circuits intégrés 
[9.2] Contraintes de flexion dynamique 
Nombre total de cycles de flexion: 4 000. 
[Torsion] 
Les cartes tachygraphiques doivent respecter la norme 
ISO/CEI 7810:2003/Amd. 1:2009, Cartes d'identifica- 
tion — Caractéristiques physiques, Amendement 1: 
Critères des cartes contenant 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 conformité de l'ATR  ISO/CEI 7816-3 
TCS_14, TCS_17, 
TCS_18  
5.2 T=0  S'assurer de la conformité du protocole T=0  ISO/CEI 7816-3 
TCS_11, TCS_12, 
TCS_13, TCS_15  
5.3 PTS  S'assurer de la conformité 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 conformité 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 conformité de la structure des fichiers 
enregistrée sur la carte en contrôlant la présence des 
fichiers obligatoires sur la carte ainsi que leurs condi ­
tions 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 autorisé de 
chaque commande. (ex: essayer la commande 
UPDATE BINARY avec CLA = ′00′, CLA = ′0C′ 
pour des paramètres P1, P2 et Lc distincts). 
S'assurer que les opérations voulues ont été correcte ­
ment exécutées sur la carte (ex.: en extrayant le fichier 
sur lequel la commande considérée a été exécutée).  TCS_29 à TCS_139  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 350  
N o Essai  Description  Exigences connexes  
7.2 Messages d'erreur  Il convient 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érique (à 
l'exception des erreurs d'intégrité ′6400′ contrôlées 
pendant la phase de certification de sécurité).  
7.3 Suite de chiffrement et paramètres de domaines normalisés  CSM_48, CSM_50  
8 Personnalisation  
8.1 Personnalisation opti ­
que Annexe 1C, chapitre 4.1 «Données visibles», 230) 
La première page doit comporter: 
des indications particulières concernant la carte déli ­
vrée. 
Annexe 1C, chapitre 4.1 «Données visibles», 231) 
La première page doit comporter: 
Les dates sont indiquées sous la forme «jj/mm/aaaa» 
ou «jj.mm.aaaa» (jour, mois, année). 
Annexe 1C, chapitre 4.1 «Données visibles», 235) 
Les cartes tachygraphiques présentent au minimum les 
éléments de protection suivants contre la contrefaçon 
et la manipulation du corps de la carte: 
— chevauchement de l'impression de fond de sécurité 
et de la photographie.  230, 231, 235  
5. ESSAIS DU DISPOSITIF GNSS EXTERNE  
N o Essai  Description  Exigences connexes  
1. Examen administratif  
1.1 Documentation  Exactitude de la documentation  
2. Inspection visuelle d'un dispositif GNSS externe  
2.1. Conformité avec la documentation  
2.2. Identification/marquage  224 à 226  
2.3 Matériaux  219 à 223  
3. Essais de fonctionnement  
3.1 Données d'identification du capteur  98,99  
3.2 Couplage module GNSS externe — unité embarquée sur véhicule  123, 205  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 351  
N o Essai  Description  Exigences connexes  
3.3 Position du GNSS  36, 37  
3.4 Interface de l'unité embarquée sur véhicule lorsque le récepteur GNSS est 
externe à l'unité embarquée sur le véhicule  03 
3.5 Suite de chiffrement et paramètres de domaines normalisés  CSM_48, CSM_50  
4. Essais environnementaux  
4.1 Température  S'assurer de la fonctionnalité en exécutant les essais 
suivants: 
Essai conforme à 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'en ­
vironnement — Partie 2-1: essais — essai A: froid 
Essai conforme à 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 conforme à 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 (parmi 
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, 
comportant 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 
capable de résister à des vibrations sinusoïdales possé ­
dant les caractéristiques suivantes: 
déplacement constant compris entre 5 et 11 Hz: 10 mm 
max; 
accélération constante comprise entre 11 et 300 Hz: 5 g 
L'essai CEI 60068-2-6, essai Fc, permet de vérifier la 
satisfaction de cette exigence. La durée minimale de cet 
essai s'élève à 3 × 12 heures (12 heures par essieu). 
La norme ISO 16750-3 n'impose pas d'essai de vibrations 
sinusoïdales aux dispositifs situés dans la cabine décou ­
plée du véhicule.  219 ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 352  
N o Essai  Description  Exigences connexes  
2. Vibrations aléatoires: 
Essai conforme à la norme ISO 16750-3: Chapitre 4.1.2.8: 
Essai VIII: Véhicule commercial, cabine de véhicule 
découplée. 
Essai de vibrations aléatoires, 10...2 000 Hz, RMS vertical 
21,3 m/s  2 , RMS longitudinal 11,8 m/s  2 , RMS latéral 
13,1 m/s  2 , 3 essieux, 32 h par essieu, y compris un cycle 
de température – 20...70 °C. 
Cet essai satisfait à la norme CEI 60068-2-64: Essais 
d'environnement — Partie 2-64: essais — essai Fh: 
vibrations aléatoires à large bande et guide 
3. Chocs: 
choc mécanique d'un demi-sinus de 3 g conformément à la 
norme ISO 16750. 
Il convient d'exécuter les essais décrits ci-avant sur des 
échantillons distincts du type d'équipement testé.  
4.4 Protection contre 
l'eau et les corps 
étrangers  Essai conforme à la norme ISO 20653: Véhicules routiers — 
Degrés de protection (code IP) — Protection des équipe ­
ments électriques contre les corps étrangers, l'eau et les 
contacts (aucune modification 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 supporter 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 
polarité  S'assurer que l'unité embarquée sur le véhicule est capable 
de supporter une inversion de polarité au niveau de son 
alimentation électrique 
(ISO 16750-2, chapitre 4.7)  216 
4.7 Protection contre 
les courts- 
circuits  S'assurer que les signaux d'entrée et de sortie sont protégés 
contre les courts-circuits à l'alimentation électrique et à la 
terre 
(ISO 16750-2, chapitre 4.10)  216 
5 Essais de compatibilité électromagnétique  
5.1 Émissions 
rayonnées et 
sensibilité  Conformité avec le règlement CEE R10  218  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 353  
N o Essai  Description  Exigences connexes  
5.2 Décharge élec ­
trostatique  Conformité avec la norme ISO 10605:2008 + Rectificatif 
technique:2010 + AMD1:2014: +/– 4 kV pour le contact 
et +/– 8 kV pour la décharge d'air  218 
5.3 Susceptibilité 
transitoire par 
conduction au 
niveau de l'ali ­
mentation  Pour les versions 24 V: conformité avec la norme ISO 7637- 
2 + Règlement CEE n  o 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: conformité avec la norme ISO 7637- 
1 + Règlement CEE n  o 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'impulsion 5 ne sera testée que pour les unités à installer 
sur des véhicules dépourvus de dispositif commun de 
protection externe contre la perte de charge. 
Pour la proposition de perte de charge, consulter la norme 
ISO 16750-2, 4e édition, chapitre 4.6.4.  218 
▼M1 
6. ESSAI DES ÉQUIPEMENTS EXTERNES DE COMMUNICATION À 
DISTANCE  
N o Essai  Description  Exigences connexes  
1. Examen administratif  
1.1 Documentation  Exactitude de la 
documentation  
2. Inspection visuelle  
2.1. Conformité avec la documentation  
2.2. Identification/marquage  225, 226  
2.3 Matériaux  219 à 223  
3. Essais de fonctionnement  
3.1 Communication à distance pour les contrôles routiers ciblés  4, 197 à 199  
3.2 Enregistrement et stockage de données sur la mémoire  91  
3.3 Communication avec l’unité embarquée sur le véhicule  Appendice 14, para ­
graphes DSC_66 à 
DSC_70, DSC_71 à 
DSC_76  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 354  
N o Essai  Description  Exigences connexes  
4. Essais environnementaux  
4.1 Température  S’assurer de la fonctionnalité en exécutant les essais 
suivants: 
Essai conforme à 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’environnement — Partie 2-1: essais - essai A: froid 
Essai conforme à 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 conforme à 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 
(parmi 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 Protection contre 
l’eau et les corps 
étrangers  Essai conforme à la norme ISO 20653: Véhicules 
routiers - Degrés de protection (code IP) - Protection 
des équipements électriques contre les corps étrangers, 
l’eau et les contacts (valeur ciblée IP 40)  220, 221  
5 Essais de compatibilité électromagnétique  
5.1 Émissions rayon ­
nées et sensibilité  Conformité avec le règlement CEE R10  218  
5.2 Décharge électrosta ­
tique  Conformité avec la norme ISO 10605:2008 + Rectificatif 
technique: 2010 + AMD1:2014: +/- 4 kV pour le contact 
et +/- 8 kV pour la décharge d’air  218 
5.3 Susceptibilité transi ­
toire par conduction 
au niveau de l’ali ­
mentation  Pour les versions 24 V: conformité avec la norme ISO 
7637-2 + Règlement CEE n  o 10 Rév. 3: 
impulsion 1a: Vs = -450 V Ri = 50 ohms 
impulsion 2a: Vs = +37V Ri = 2 ohms 
impulsion 2b: Vs = +20V Ri = 0,05 ohms 
impulsion 3a: Vs = -150V Ri = 50 ohms 
impulsion 3b: Vs = +150V 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 12V: conformité avec la norme ISO 
7637-1 + Règlement CEE n  o 10 Rév. 3: 
impulsion 1: Vs = -75V Ri = 10 ohms 
impulsion 2a: Vs = +37V Ri = 2 ohms 
impulsion 2b: Vs = +10V Ri = 0,05 ohms 
impulsion 3a: Vs = -112V Ri = 50 ohms  218 ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 355  
N o Essai  Description  Exigences connexes  
impulsion 3b: Vs = +75V 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’impulsion 5 ne sera testée que pour les unités à 
installer sur des véhicules dépourvus de dispositif 
commun de protection externe contre la perte de charge. 
Pour la proposition concernant la perte de charge, 
consulter la norme ISO 16750-2, 4  e édition, chapitre 
4.6.4.  
▼B 
7. ESSAIS FONCTIONNELS SUR LE PAPIER  
N o Essai  Description  Exigences connexes  
1. Examen administratif  
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 carac ­
tères  Inspection visuelle des impressions et contrôle des 
caractères.  173 
2.3 Jeux de caractères 
compatibles  L'imprimante doit prendre en charge les caractères 
spécifiés au chapitre 4 «Jeux de caractères» de l'appen ­
dice 1.  174 
2.4 Définition des 
impressions  Contrôle de l'homologation du type de tachygraphe et 
inspection visuelle des impressions  174 
2.5 Lisibilité et identifi ­
cation des impres ­
sions  Inspection des impressions 
Étayé par des rapports d'essai et des protocoles d'essai 
par le fabricant. 
Tous les numéros d'homologation des tachygraphes 
avec lesquels il est possible d'utiliser le papier d'impres ­
sion sont imprimés sur le papier.  175, 177, 178  
2.6 Ajout de commen ­
taires manuscrits  Contrôle visuel: la zone de signature du conducteur est 
disponible. 
D'autres zones de saisie manuscrites sont disponibles.  180 
2.7 Détails complémen ­
taires 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'inter ­
fèrent pas systématiquement avec la lisibilité des 
impressions. 
Contrôle visuel  177, 178  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 356  
N o Essai  Description  Exigences connexes  
3 Essais de stockage  
3.1 Chaleur sèche  Préconditionnement: 16 heures à + 23 °C ± 2 °C/55 % ± 
3 % d'humidité relative 
Environnement d'essai: 72 h à + 70 °C ± 2 °C 
Récupération: 16 heures à + 23 °C ± 2 °C/55 % ± 3 % 
d'humidité 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 
Environnement 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'humidité relative  176, 178 
CEI 60068-2-78-Cab  
4 Essais sur papier en circulation  
4.1 Contexte de résis ­
tance à l'humidité 
(papier non imprimé)  Préconditionnement: 16 heures à + 23 °C ± 2 °C/55 % ± 
3 % d'humidité relative 
Environnement 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'humidité relative  176, 178 
CEI 60068-2-78-Cab  
4.2 Imprimabilité  Préconditionnement: 24 heures à + 40 °C ± 2 °C/93 % ± 
3 % d'humidité relative 
Environnement d'essai: impression produite à + 23 °C ± 
2 °C 
16 heures à + 23 °C ± 2 °C/55 % ± 3 % d'humidité 
relative  176, 178  
4.3 Thermorésistance  Préconditionnement: 16 heures à + 23 °C ± 2 °C/55 % ± 
3 % d'humidité relative 
Environnement d'essai: 2 heures at + 70 °C ± 2 °C, 
chaleur sèche 
Récupération: 16 heures à + 23 °C ± 2 °C/55 % ± 3 % 
d'humidité relative  176, 178 
CEI 60068-2-2-Bb  
4.4 Résistance aux 
températures basses  Préconditionnement: 16 heures à + 23 °C ± 2 °C/55 % ± 
3 % d'humidité relative 
Environnement d'essai: 24 heures at – 20 °C ± 3 °C, 
chaleur sèche 
Récupération: 16 heures à + 23 °C ± 2 °C/55 % ± 3 % 
d'humidité relative  176, 178 
ISO 60068-2-1-Ab  
4.5 Photorésistance  Préconditionnement: 16 heures à + 23 °C ± 2 °C/55 % ± 
3 % d'humidité relative 
Environnement d'essai: 100 heures sous une lumière de 
5 000 Lux à + 23 °C ± 2 °C/55 % ± 3 % d'humidité 
relative 
Récupération: 16 heures à + 23 °C ± 2 °C/55 % ± 3 % 
d'humidité 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  
Support (papier non imprimé): max 0,2  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 357  
La mesure de densité optique des impressions produites respecte la norme 
DIN EN ISO 534.  
Les impressions ne subissent aucune modification de dimension et demeu ­
rent parfaitement lisibles.  
8. ESSAIS D'INTEROPÉRABILITÉ  
▼M1 
N o Essai  Description  
8.1 Essais d’interopérabilité entre unités embarquées sur véhicule et cartes tachygraphiques  
1 Authentification mutuelle  S’assurer de la bonne exécution de la procédure d’authentification 
mutuelle entre l’unité embarquée sur le véhicule et la carte tachygra ­
phique  
2 Essais de lecture/écriture  Mettre à exécution un scénario d’activité classique sur l’unité embar ­
quée sur le véhicule. Le scénario doit être adapté au type de carte 
testé et comporter l’exécution d’opérations d’écriture dans le plus 
grand nombre possible d’EF que présente la carte. 
Procéder à un téléchargement sur VU pour s’assurer de la bonne 
exécution de tous les enregistrements correspondants. 
Procéder à un téléchargement sur carte pour s’assurer de la bonne 
exécution de tous les enregistrements correspondants 
Procéder à des impressions quotidiennes pour s’assurer de la bonne 
lisibilité des enregistrements correspondants.  
8.2 Essais d’interopérabilité entre unités embarquées sur véhicule et capteurs de mouvement  
1 Appariement  S’assurer de la bonne exécution de l’appariement entre l’unité embar ­
quée sur le véhicule et le capteur de mouvement  
2 Essais d’activité  Exécuter un scénario d’activité classique sur le capteur de mouve ­
ment. Le scénario 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échargement sur VU pour s’assurer de la bonne 
exécution de tous les enregistrements correspondants. 
Procéder à un téléchargement sur carte pour s’assurer de la bonne 
exécution de tous les enregistrements correspondants 
Procéder à une impression quotidienne pour s’assurer de la bonne 
lisibilité des enregistrements correspondants.  
8.3 Essais d’interopérabilité entre les VU et les dispositifs GNSS externes (le cas échéant)  
1 Authentification 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 externe.  
2 Essais d’activité  Exécuter un scénario d’activité classique sur le dispositif GNSS 
externe. Le scénario 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échargement sur VU pour s’assurer de la bonne 
exécution de tous les enregistrements correspondants. 
Procéder à un téléchargement sur carte pour s’assurer de la bonne 
exécution de tous les enregistrements correspondants 
Procéder à une impression quotidienne pour s’assurer de la bonne 
lisibilité des enregistrements correspondants.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 358  
Appendice 10  
EXIGENCES EN MATIÈRE DE SÉCURITÉ  
Le présent appendice précise les exigences en matière de sécurité informatique 
concernant les composants du tachygraphe intelligent (tachygraphe de seconde 
génération).  
SEC_001 Les composants suivants du tachygraphe intelligent doivent faire 
l'objet d'une certification de sécurité conforme aux critères communs:  
— unité embarquée sur le véhicule,  
— carte tachygraphique,  
— capteur de mouvement,  
— dispositif GNSS externe.  
SEC_002 Les exigences minimales de sécurité informatique à satisfaire par 
chaque composant soumis à une certification de sécurité doivent 
être définies par un profil de protection du composant, conformément 
aux Critères communs.  
SEC_003 La Commission européenne doit s'assurer que quatre profils de protec ­
tion conformes à la présente annexe sont parrainés, développés, 
approuvés par les organismes gouvernementaux de certification de 
la sécurité informatique conjointement avec le groupe de travail d'in ­
terprétation conjointe (JIWG), qui encouragent 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écurité en matière de technologie de l'information) et qu'ils 
font l'objet d'un enregistrement:  
— profil de protection d'une unité embarquée sur le véhicule;  
— profil de protection d'une carte tachygraphique;  
— profil de protection d'un capteur de mouvement;  
— profil de protection d'un dispositif GNSS externe.  
Le profil de protection 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 exigences de sécurité du 
dispositif GNSS externe sont stipulées dans le profil de protection dédié.  
SEC_004 Pour établir un objectif de sécurité en vue de l'obtention de certificats 
de sécurité du composant, les fabricants de composants habilités affi ­
neront et complèteront selon les besoins le profil de protection de 
composant approprié, sans supprimer ni modifier les spécifications 
concernant les menaces, les objectifs, les ressources procédurales et 
les fonctions de maintien de la sécurité.  
SEC_005 La stricte conformité dudit objectif de sécurité avec le profil de 
protection correspondant doit être déclarée au cours du processus 
d'évaluation.  
SEC_006 Le niveau de garantie exigé par chaque profil de protection est le 
niveau EAL4 augmenté des composants de garantie ATE_DPT.2 et 
AVA_VAN.5.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 359  
Appendice 11  
MÉCANISMES DE SÉCURITÉ COMMUNS  
TABLE DES MATIÈRES  
PRÉAMBULE  
PARTIE A TACHYGRAPHE DE PREMIÈRE GÉNÉRATION  
1. INTRODUCTION  
1.1. Références  
1.2. Notations et abréviations  
2. SYSTÈMES ET ALGORITHMES CRYPTOGRAPHIQUES  
2.1. Systèmes cryptographiques  
2.2. Algorithmes cryptographiques  
2.2.1 Algorithme RSA  
2.2.2 Algorithme de hachage  
2.2.3 Algorithme de cryptage des données  
3. CLÉS ET CERTIFICATS  
3.1. Génération et distribution de clés  
3.1.1 Génération et distribution de clés RSA  
3.1.2 Clés de contrôle RSA  
3.1.3 Clés du capteur de mouvement  
3.1.4 Génération et distribution de clés de session T-DES  
3.2. Clés  
3.3. Certificats  
3.3.1 Contenu des certificats  
3.3.2 Certificats émis  
3.3.3 Vérification et dévoilement des certificats  
4. MÉCANISME D'AUTHENTIFICATION MUTUELLE  
5. MÉCANISMES DE CONFIDENTIALITÉ, D'INTÉGRITÉ ET 
D'AUTHENTIFICATION DES DONNÉES TRANSFÉRÉES 
ENTRE LES VU ET LES CARTES  
5.1. Messagerie sécurisée  
5.2. Traitement des erreurs de messagerie sécurisée  
5.3. Algorithme de calcul des totaux de contrôle cryptographiques  
5.4. Algorithme de calcul des cryptogrammes destinés aux instructions 
DO de confidentialité  
6. MÉCANISMES DE SIGNATURE NUMÉRIQUE DES TÉLÉ ­ 
CHARGEMENTS DE DONNÉES  
6.1. Génération de signatures  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 360  
6.2. Vérification de signatures  
PARTIE B TACHYGRAPHE DE DEUXIÈME GÉNÉRATION  
7. INTRODUCTION  
7.1. Références  
7.2. Notations et abréviations  
7.3. Définitions  
8. SYSTÈMES ET ALGORITHMES CRYPTOGRAPHIQUES  
8.1. Systèmes cryptographiques  
8.2. Algorithmes cryptographiques  
8.2.1 Algorithmes symétriques  
8.2.2 Algorithmes asymétriques et paramètres de domaine normalisés  
8.2.3 Algorithmes de hachage  
8.2.4 Méthodes de cryptage  
9. CLÉS ET CERTIFICATS  
9.1. Paires de clés asymétriques et certificats de clé publique  
9.1.1 Généralités  
9.1.2 Niveau européen  
9.1.3 Niveau État membre  
9.1.4 Niveau équipement: unités embarquées sur véhicule  
9.1.5 Niveau équipement: cartes tachygraphiques  
9.1.6 Niveau équipement: dispositifs GNSS externes  
9.1.7 Généralités: certificat de substitution  
9.2. Clés symétriques  
9.2.1 Clés de sécurisation de la communication du capteur de mouve ­ 
ment de la VU  
9.2.2 Clés de sécurisation de la communication DSRC  
9.3. Certificats  
9.3.1 Généralités  
9.3.2 Contenu du certificat  
9.3.3 Certificats de demande  
10. AUTHENTIFICATION MUTUELLE DE LA CARTE ET DE LA 
VU ET MESSAGERIE SÉCURISÉE  
10.1. Généralités  
10.2. Vérification mutuelle de la chaîne de certificat  
10.2.1 Vérification de la chaîne de certificat de la carte par la VU  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 361  
10.2.2 Vérification de la chaîne de certificat de la VU par la carte  
10.3. Authentification de VU  
10.4. Authentification du circuit et concordance des clés de session  
10.5. Messagerie sécurisée  
10.5.1 Généralités  
10.5.2 Structure de message sécurisé  
10.5.3 Abandon de la session de messagerie sécurisée  
11. COUPLAGE DE L'UV ET DU DISPOSITIF GNSS, AUTHENTI ­ 
FICATION MUTUELLE ET MESSAGERIE SÉCURISÉE  
11.1. Généralités  
11.2. couplage d'une VU et d'un dispositif externe GNSS  
11.3. Vérification mutuelle de la chaîne de certificat  
11.3.1 Généralités  
11.3.2 Pendant le couplage VU — EGF  
11.3.3 Pendant le fonctionnement normal  
11.4. Authentification de la VU, Authentification du circuit et concor ­ 
dance des clés de session  
11.5. Messagerie sécurisée  
12. COUPLAGE ET COMMUNICATION DE LA VU ET DU 
CAPTEUR DE MOUVEMENT  
12.1. Généralités  
12.2. Couplage de la VU et du capteur de mouvement à l'aide de géné ­ 
rations de clés différentes  
12.3. couplage et communication de la VU et du capteur de mouvement 
en utilisant AES  
12.4. couplage de la VU et du capteur de mouvement pour des équipe ­ 
ments de générations différentes  
13. SÉCURITÉ DES COMMUNICATIONS DISTANTES UTILI ­ 
SANT DSRC  
13.1. Généralités  
13.2. Cryptage des données utiles du tachygraphe et génération du MAC  
13.3. Vérification et décryptage de la charge du tachygraphe  
14. SIGNATURE DES TÉLÉCHARGEMENT DE DONNÉES ET 
CONTRÔLE DES SIGNATURES  
14.1. Généralités  
14.2. Génération de signatures  
14.3. Vérification de signatures  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 362  
PRÉAMBULE  
Le présent appendice indique les mécanismes de sécurité garantissant  
— l'authentification mutuelle entre les différents composants du tachygraphe.  
— confidentialité, intégrité, authenticité et/ou non-répudiation des données trans ­
férées entre les différents composants du tachygraphe ou téléchargées vers un 
support de stockage externe.  
Le présent appendice se compose de deux parties. La partie A définit les méca ­
nismes de sécurité pour le tachygraphe de première génération (tachygraphe 
numérique). La partie B définit les mécanismes de sécurité pour le tachygraphe 
de deuxième génération (tachygraphe intelligent).  
Les mécanismes spécifiés dans la partie A du présent appendice s'appliquent si 
au moins l'un des composants du tachygraphe concerné par une authentification 
mutuelle et/ou le processus de transfert des données est de première génération.  
Les mécanismes spécifiés dans la partie B du présent appendice s'appliquent si 
les deux composants concernés par une authentification mutuelle et/ou le 
processus de transfert des données sont de deuxième génération.  
L'appendice 15 fournit davantage d'informations à propos de l'utilisation des 
composants de première génération avec ceux de deuxième génération.  
PARTIE A  
TACHYGRAPHE DE PREMIÈRE GÉNÉRATION  
1. INTRODUCTION  
1.1. Références  
Le présent appendice fait référence aux documents suivants:  
SHA-1 National Institute of Standards and Technology 
(NIST).  FIPS Publication 180-1: Secure Hash Stan ­
dard . Avril 1995.  
PKCS1 RSA Laboratories. PKCS # 1:  RSA Encryption Stan ­
dard . Version 2.0. Octobre 1998.  
TDES National Institute of Standards and Technology 
(NIST).  FIPS Publication 46-3: Data Encryption 
Standard . Projet 1999.  
TDES-OP ANSI X9.52, Triple Data Encryption Algorithm 
Modes of Operation. 1998.  
ISO/CEI 7816-4 Technologies de l'information — Cartes d'identifica ­
tion — Cartes à circuit(s) intégré(s) à contacts — 
Partie 4: commandes intersectorielles pour les 
échanges. Première édition: 1995 + Amendement 1: 
1997.  
ISO/CEI 7816-6 Technologies de l'information — Cartes d'identifica ­
tion — Cartes à circuit(s) intégré(s) à contacts — 
Partie 6: éléments de données intersectorielles. 
Première édition: 1996 + Cor 1: 1998.  
ISO/CEI 7816-8 Technologies de l'information — Cartes d'identifica ­
tion — Cartes à circuit(s) intégré(s) à contacts — 
Partie 8: commandes intersectorielles de sécurité. 
Première édition: 1999.  
ISO/CEI 9796-2 Technologies de l'information — Techniques de sécu ­
rité — Schémas de signature numérique rétablissant le 
message — Partie 2: mécanismes utilisant une fonc ­
tion de hachage. Première édition: 1997.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 363  
ISO/CEI 9798-3 Technologies de l'information — Techniques de sécu ­
rité — Mécanismes d'authentification d'entité — Partie 
3: authentification d'entité utilisant un algorithme à clé 
publique. Seconde édition: 1998.  
ISO 16844-3 Véhicules routiers — Systèmes tachygraphiques — 
Partie 3: Interface de capteur de mouvement.  
1.2. Notations et abréviations  
Les notations et abréviations qui suivent apparaissent dans le présent 
appendice:  
(K a , K  b , K  c ) Faisceau de clés destiné au triple algorithme de cryp ­
tage des données  
CA Organisme de certification  
CAR Références de l'organisme 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écryptage avec DES (Data Encryption Standard)  
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() cryptage avec DES  
EQT Équipement  
Hash()  Valeur de hachage, en tant que sortie de  Hash  
Hash  Fonction Hash  
KID Identificateur de clé  
Km Clé TDES. Clé maîtresse définie dans ISO 16844-3  
Km  VU Clé TDES insérée dans les unités embarquées sur le 
véhicule  
Km  WC 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 remplissage  
PI Octet indicateur de remplissage (employé dans les 
cryptogrammes destinés aux instructions DO de confi ­
dentialité)  
PV Valeur ordinaire  
s Représentant de signature, nombre entier compris 
entre 0 et n-1  
SSC Compteur de séquences d'émission  
SM Messagerie sécurisée  
TCBC Mode d'exploitation par chaînage de blocs de données 
cryptées TDEA  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 364  
TDEA Triple algorithme d'cryptage des données  
TLV Longueur des marqueurs  
VU Unité embarquée sur le véhicule  
X.C Certificat de l'utilisateur X, émis par un organisme de 
certification  
X.CA Organisme de certification de l'utilisateur X  
X.CA.PK  o X.C Opération de dévoilement 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 certification et l'opérande 
de droite au certificat émis par ce même organisme. 
Nous obtenons en résultat la clé publique de l'utilisa ­
teur X, dont le certificat est l'opérande de droite.  
X.PK Clé publique RSA d'un utilisateur X  
X.PK[I] cryptage 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] cryptage RSA de certaines informations I, à l'aide de 
la clé privée de l'utilisateur X  
‘xx’ Valeur hexadécimale  
|| Opérateur de concaténation  
2. SYSTÈMES ET ALGORITHMES CRYPTOGRAPHIQUES  
2.1. Systèmes cryptographiques  
CSM_001 Les unités embarquées sur véhicule et les cartes tachygra ­
phiques auront recours à un système cryptographique clas ­
sique à clé publique RSA pour assurer les mécanismes de 
sécurité suivants:  
— Authentification mutuelle entre unités embarquées sur 
véhicule et cartes tachygraphiques.  
— Acheminement des clés triples de session DES (Data 
Encryption Standard) entre unités embarquées sur véhi ­
cule et cartes tachygraphiques.  
— Signature numérique des données téléchargées sur des 
supports externes à partir d'unités sur véhicule ou de 
cartes tachygraphiques.  
CSM_002 Les unités embarquées sur véhicule et les cartes tachygra ­
phiques auront recours à un système cryptographique symé ­
trique DES triple pour assurer un mécanisme garantissant 
l'intégrité des données lors des échanges de données utilisa ­
teur entre les unités embarquées sur véhicule et les cartes 
tachygraphiques et pour assurer, le cas échéant, la confiden ­
tialité des échanges de données entre les unités embarquées 
sur véhicule et les cartes tachygraphiques.  
2.2. Algorithmes cryptographiques  
2.2.1  Algorithme RSA  
CSM_003 L'algorithme RSA est parfaitement défini par les relations 
suivantes:  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 365  
X.SK[ m] = s = m d mod n 
X.PK[ s] = m = s e mod n 
Pour une description plus détaillée de la fonction RSA, 
reportez-vous 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  Algorithme de hachage  
CSM_004 Les mécanismes de signature numérique auront recours à 
l'algorithme de hachage SHA-1 tel qu'il est défini dans le 
document de référence [SHA-1].  
2.2.3  Algorithme de cryptage des données  
CSM_005 Des algorithmes DES seront utilisés en mode chaînage de 
blocs de données cryptées.  
3. CLÉS ET CERTIFICATS  
3.1. Génération et distribution de clés  
3.1.1  Génération et distribution 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.  
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 euro ­
péenne permettra d'homologuer les clés publiques des États 
membres. Des registres de l'ensemble des clés certifiées 
seront conservés. Ces tâches 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'organisme de certi ­
fication européen. La clé privée de l'État membre permettra 
d'homologuer les clés publiques à introduire dans l'équipe ­
ment (unité embarquée sur le véhicule ou carte tachygra ­
phique). Des registres de l'ensemble des clés publiques certi ­
fiées seront conservés avec les données d'identification 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é à changer 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écu ­
tées par les fabricants d'équipements, personnalisateurs 
d'équipement ou autorités compétentes à l'échelon national. 
Cette paire de clés sera utilisée par les services d'authentifi ­
cation, de signature numérique et de cryptage.  
CSM_010 La confidentialité des clés privées doit être préservée durant 
leur génération, leur acheminement (éventuel) et leur archi ­
vage.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 366  
Le schéma fonctionnel qui suit représente une synthèse du 
cheminement des données caractérisant ce processus:  
▼C2
 
▼B 3.1.2  Clés de contrôle RSA  
CSM_011 Aux fins d'essai des équipements (essais d'interopérabilité 
inclus), l'organisme de certification 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 introdui ­
ront, 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 mouvement  
La confidentialité des trois clés triple DES décrites ci-après est protégée 
de manière appropriée au cours de la génération, du transport (le cas 
échéant) et du stockage.  
Afin de permettre l'utilisation de composants de tachygraphes conformes 
à la norme ISO 16844, l'autorité de certification européenne et les orga ­
nismes de certification de l'État membre veilleront également aux aspects 
suivants:  
CSM_036 L'organisme de certification européen génère les clés KmVU 
et KmWC, deux clés triple DES uniques et indépendantes, 
ainsi que la clé Km selon la 
formule:  Km = Km  VU XOR Km  WC . L'organisme 
de certification européen transmet ces clés, selon les procé ­
dures sécurisées appropriées, aux organismes de certification 
des États membres qui en font la demande.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 367  
CSM_037 Les organismes de certification des États membres:  
— utilisent la clé Km pour chiffrer les données du capteur 
de mouvement demandées par les fabricants des capteurs 
de mouvement (les données à chiffrer avec la clé Km 
sont définies par la norme ISO 16844-3),  
— transmettent la clé Km  VU aux fabricants d'unités embar ­
quées sur le véhicule, selon les procédures sécurisées 
appropriées, afin qu'elles soient insérées dans les VU,  
— veillent à ce que la clé Km  WC soit insérée dans toutes les 
cartes d'atelier (
  dans 
le fichier élémentaire
  ) 
lors de la personnalisation de la carte.  
3.1.4  Génération et distribution de clés de session T-DES  
CSM_012 Lors de leur processus d'authentification mutuelle, les unités 
embarquées sur véhicule et les cartes tachygraphiques géné ­
reront et échangeront les données nécessaires à l'élaboration 
d'une clé de session T-DES commune. La confidentialité de 
cet échange de données sera préservée par un mécanisme de 
cryptage RSA.  
CSM_013 Cette clé sera utilisée lors de toutes les opérations cryptogra ­
phiques ultérieures, en faisant appel à la messagerie sécuri ­
sé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'envoi d'une commande recourant à la 
messagerie sécurisée vers la carte approprié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 (K  a , K b , K a ), où K  a et K  b sont 
des clés indépendantes de 64 bits de long. Aucun bit de 
détection d'erreur de parité ne doit être établi.  
3.3. Certificats  
CSM_016 Les certificats associés aux clés publiques RSA seront du 
type «non self-descriptive» et «card verifiable» (Réf.: 
ISO/CEI 7816-8).  
3.3.1  Contenu des certificats  
CSM_017 Les certificats associés aux clés publiques RSA comportent 
les données ci-après dans l'ordre suivant:  
Données  Format  Octets  Observations  
CPI ENTIER  1  Identificateur de profil du 
certificat (‘01’ pour cette 
version)  
CAR  CHAÎNE 
D'OCTETS  8 Références de l'organisme 
de certification  
CHA  CHAÎNE 
D'OCTETS  7 Autorisation d'un titulaire 
de certificat  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 368  
Données  Format  Octets  Observations  
EOV  TimeReal  4  Expiration du certificat. 
Optionnel, ‘FF’ complété 
par des octets de remplis ­
sage en cas de non-utilisa ­
tion. 
CHR  CHAÎNE 
D'OCTETS  8 Références d'un titulaire de 
certificat  
n CHAÎNE 
D'OCTETS  128 Clé publique (module)  
e CHAÎNE 
D'OCTETS  8 Clé publique (exposant 
public)  
164 
Remarques:  
1. «L'Identificateur de profil du certificat» (CPI) détermine la structure 
précise d'un certificat d'authentification. Il fait office d'identificateur 
interne d'équipement au sein d'une liste en-tête appropriée qui décrit la 
concaténation des éléments de données que comporte le certificat.  
La liste en-tête associée au contenu de ce certificat se présente 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'organisme de certification» (CAR) permettent 
d'identifier l'organisme de certification émetteur du certificat de telle 
manière que l'élément de données puisse faire simultanément office 
d'identificateur de clé d'autorité renvoyant à la clé publique de l'orga ­
nisme de certification (pour plus d'informations concernant le codage, 
reportez-vous à l'Identificateur de clé ci-après).  
3. «L'Autorisation du titulaire de certificat» (CHA) permet d'identifier les 
droits du titulaire de certificat. Elle se compose de l'ID d'application 
du tachygraphe 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).  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 369  
4. La «Référence du titulaire de certificat» (CHR) permet d'identifier 
exclusivement 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 renvoyant à la clé publique du titulaire de certificat.  
5. Les identificateurs de clé identifient uniquement les titulaires de certi ­
ficat 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'équi­
pement  Date  Type  Fabricant  
Longueur  4 octets  2 octets  1 octet  1 octet  
Valeur  Entier  Codage DCB mm 
aa Caractéristiques 
du fabricant  Code du fabri ­
cant 
S'il s'agit d'une VU, le fabricant est susceptible, lors de la 
demande de certificats, de connaître ou non les données d'iden ­
tification de l'équipement au sein duquel les clés seront intro ­
duites.  
Dans le premier cas de figure, le fabricant enverra les données 
d'identification de l'équipement accompagnées de la clé publique 
à l'organisme de certification national compétent. Le certificat 
contiendra alors les données d'identification de l'équipement 
concerné. Le fabricant devra veiller à ce que les clés et le certi ­
ficat appropriés soient introduits dans l'équipement voulu. L'Iden ­
tificateur de clé se présente sous la forme indiquée ci-avant.  
Dans le second cas de figure, le fabricant doit identifier indivi ­
duellement chaque demande de certificat et envoyer les données 
d'identification correspondantes accompagnées de la clé publique 
à l'organisme de certification national compétent. Le certificat 
contiendra alors les données d'identification de la demande de 
certificat concernée. Le fabricant doit communiquer en retour à 
l'organisme de certification national compétent les données d'af ­
fectation des clés à l'équipement concerné (c.-à-d., les données 
d'identification de la demande de certificat et d'identification de 
l'équipement visé) après leur installation sur cet équipement. 
L'Identificateur de clé se présente sous la forme indiquée ci- 
après: 
Données  Numéro 
de série 
de la 
demande 
de certifi­
cat Date  Type  Fabricant  
Longueur  4 octets  2 octets  1 octet  1 octet  
Valeur  Entier  Codage DCB mm 
aa 'FF' Code du fabri ­
cant ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 370  
5.2 Organisme de certification: 
Données  Identification de 
l'organisme  Numéro de 
série de la clé  Informations 
complémen ­
taires  Identificateur  
Longueur  4 octets  1 octet  2 octets  1 octet  
Valeur  Code numérique 
national sur un 
octet 
Code alphanumé ­
rique national sur 
trois octets  Entier  codage addi ­
tionnel 
(propre à la 
CA) 
′FF FF′ en cas 
de non-utili ­
sation  ‘01’ 
Le numéro de série d'une clé permet de faire la distinction entre 
les différentes 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 cryptage de signatures numériques aux fins de confi ­
dentialité (le certificat ne contient aucun Identificateur d'objet permet ­
tant de le préciser).  
3.3.2  Certificats émis  
CSM_018 Le certificat émis se présente comme une signature numé ­
rique assortie d'une récupération partielle du contenu du 
certificat en conformité avec la norme ISO/CEI 9796-2 
(annexe A.4 non comprise), les «Références de l'organisme 
de certification» clôturant le certificat.  
X.C = X.CA.SK[‘6A’ || C  r || Hash (Cc) || ‘BC’] || C  n || X.CAR 
Avec contenu de certificat = Cc =  C  r || C  n 
106 octets  58 octets  
Remarques:  
1. Ce certificat comporte 194 octets.  
2. Les CAR, masquées par la signature, s'ajoutent également à cette 
dernière, afin que la clé publique de l'organisme de certification 
puisse être sélectionnée pour procéder à la vérification du certificat.  
3. Le vérificateur du certificat connaîtra implicitement l'algorithme 
employé par l'organisme de certification pour signer le certificat.  
4. La liste en-tête associée à ce certificat émis se présente 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 ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 371  
3.3.3  Vérification et dévoilement des certificats  
La vérification et le dévoilement des certificats consistent à vérifier la 
signature conformément à la norme ISO/CEI 9796-2, à extraire le 
contenu 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 comporte les opérations suivantes:  
Vérification de la signature et extraction du contenu: 
— À partir de X.C, extraire la Sign., C  n ' et CAR':  X.C =  Sign  ||  C  n ' ||  CAR'  
128 octets  58 octets  8 octets  
— À partir de CAR ′, sélectionner la clé publique de l'orga ­
nisme de certification approprié (dans l'éventualité où 
cette opération n'aurait pas été exécutée par d'autres 
moyens).  
— Ouvrir Sign avec la clé publique de la CA: Sr'= X.CA.PK 
[Sign].  
— S'assurer que le Sr ′ commence par ‘6A’ et se termine par 
′BC′. 
— Calculer C  r ' et H' d'après: Sr' =  ‘6A’  || C  r ' ||  H'  ||  ‘BC’  
106 octets  20 octets  
— Récupérer le contenu du certificat C' = C  r ' || C  n ', 
— Vérifier  Hash (C') = H'.  
Si les vérifications sont concluantes, 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émoriser la clé publique, l'identificateur de clé, 
l'autorisation 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.EOV = EOV  
4. MÉCANISME D'AUTHENTIFICATION MUTUELLE  
L'authentification mutuelle entre les cartes et les VU repose sur le prin ­
cipe 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 homologation par 
l'organisme de certification national compétent étant elle-même homolo ­
guée par l'organisme de certification européen.  
Cette démonstration consiste à signer avec la clé privée un nombre 
aléatoire envoyé par l'autre partie, laquelle doit récupérer, lors de la 
vérification de cette signature, le nombre aléatoire préalablement envoyé.  
La VU concernée déclenche le mécanisme d'authentification dès l'inser ­
tion de la carte. La procédure commence par l'échange des certificats et 
le dévoilement des clés publiques; elle prend fin avec la définition d'une 
clé de session.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 372  
CSM_020 Le protocole ci-après sera utilisé [les flèches indiquent les 
commandes et données échangées (voir appendice 2)]:
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 373
  
▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 374  
5. MÉCANISMES DE CONFIDENTIALITÉ, D'INTÉGRITÉ ET D'AU ­
THENTIFICATION DES DONNÉES TRANSFÉRÉES ENTRE LES 
VU ET LES CARTES  
5.1. Messagerie sécurisée  
CSM_021 L'intégrité des transferts de données entre les VU et les cartes 
sera préservée par un dispositif de messagerie sécurisée, en 
conformité avec les normes de référence [ISO/CEI 7816-4] et 
[ISO/CEI 7816-8].  
CSM_022 Si la protection de données s'impose pendant leur transfert, 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écepteur procédera à 
une vérification du total de contrôle cryptographique.  
CSM_023 Le total de contrôle cryptographique des données transmises 
dans une commande intégrera l'en-tête de cette commande 
ainsi que la totalité 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/information transmis en réponse seront 
protégés par un total de contrôle cryptographique si cette 
réponse ne comporte 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 messagerie sécurisée, 
les commandes et réponses présentent la structure suivante:  
Les instructions DO utilisées représentent un jeu partiel des 
DO de messagerie sécurisée décrites dans les dispositions de 
la norme ISO/CEI 7816-4:  
Balise  Mnémoni ­
que Signification  
‘81’ T  PV Valeur simple non codée en BER-TLV (à protéger 
par CC)  
‘97’ T  LE Valeur de Le dans la commande non sécurisée (à 
protéger par CC)  
‘99’ T  SW Infos d'état (à protéger par CC)  
‘8E’ T  CC Total de contrôle cryptographique  
‘87’ T  PI CG  Octet indicateur de remplissage || Cryptogramme 
(valeur simple non codée en BER-TLV)  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 375  
Étant donné une paire de réponses à une commande non 
sécurisée:  
En-tête de commande  Corps de la commande  
CLA  INS  P1  P2  [champ L  c ] [champ de données]  [champ L  e ] 
quatre octets  Octets L, indiquant B  1 à B  L 
Corps de la réponse  En queue de réponse  
[champ de données]  SW1  SW2  
Octets de données L  r deux octets  
La paire correspondante de réponses à une commande sécu ­
risée se présente comme suit:  
Commande sécurisée:  
En-tête de commande (CH)  Corps de la commande  
CLA  INS  P1  P2  [nouveau champ 
L c ] [nouveau champ de données]  [nou ­
veau 
champ 
L e ] 
‘OC’  Longueur du 
nouveau champ 
de données  T PV L PV PV T  LE L LE L e T CC L CC CC ‘00’  
‘81’ L  c Champ de 
données  ‘97’ ‘01’  L  e ‘8E’ ‘04’  CC  
Données à intégrer au total de contrôle = CH || PB || T  PV || 
L PV || PV || T  LE || L  LE || L  e || PB  
PB = Octets de remplissage (80.. 00) en conformité 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écurisée comporte un certain nombre de données corres ­
pondantes.  
Réponse sécurisée:  
1. Cas où le champ de données de la réponse n'est pas vide 
et ne nécessite aucune protection aux fins de confidentia ­
lité: 
Corps de la réponse  En queue de réponse  
[nouveau champ de données]  Nouveau SW1 SW2  
T PV L PV PV T  CC L CC CC 
‘81’ L  r Champ de données  ‘8E’  ‘04’  CC  
Données à intégrer dans le total de contrôle = T  PV || L  PV || 
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 confidentia ­
lité: ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 376  
Corps de la réponse  En queue de réponse  
[nouveau champ de données]  Nouveau SW1 SW2  
T PI CG  L PI 
CG PI CG  T  CC L CC CC 
‘87’ PI || CG  ‘8E’  ‘04’  CC  
Données à transférer par CG: données non codées BER- 
TLV et octets de remplissage.  
Données à intégrer dans le total de contrôle = T  PI CG  || L PI 
CG || PI CG || PB  
3. Cas où le champ de données de la réponse est vide:  
Corps de la réponse  En queue de réponse  
[nouveau champ de données]  Nouveau SW1 SW2  
T SW L SW SW T  CC L CC CC 
‘99’ ‘02’  Nouveaux SW1 et 
SW2  ‘8E’ ‘04’  CC  
Données à intégrer dans le total de contrôle = T  SW || L  SW 
|| SW || PB  
5.2. Traitement des erreurs de messagerie sécurisée  
CSM_026 Si la carte tachygraphique reconnaît une erreur SM lors de 
l'interprétation d'une commande, les octets d'état doivent être 
renvoyés sans MS. Conformé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 total de contrôle crypto ­
graphique,  
‘69 87’: Absence d'objets de données SM prévus,  
‘69 88’: Objets de données SM incorrects.  
CSM_027 Si la carte tachygraphique renvoie 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. Algorithme de calcul des totaux de contrôle cryptographiques  
CSM_028 La constitution des totaux de contrôle cryptographiques se 
fait à l'aide des contrôles d'accès au support (MAC) détaillés, 
en conformité 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() signifie le cryptage avec DES et l'abré ­
viation D() le décryptage avec DES.  
Les quatre octets les plus significatifs du total de contrôle 
cryptographique sont transférés.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 377  
CSM_029 Le compteur de séquences à l'émission (SSC) sera lancé 
pendant la procédure d'acceptation des clés:  
SSC initial: Rnd3 (4 derniers octets significatifs) || Rnd1 (4 
derniers octets significatifs).  
CSM_030 Le compteur 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).  
La figure ci-après illustre le calcul du MAC détaillé:
  
5.4. Algorithme de calcul des cryptogrammes destinés aux instructions 
DO de confidentialité  
CSM_031 Ces cryptogrammes se calculent à l'aide du TDEA en mode 
d'exploitation TCBC, en conformité avec les [TDES] et 
[TDES-OP] de référence et avec le vecteur nul comme 
bloc de valeur initial.  
La figure qui suit illustre l'application des clés en TDES:
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 378  
6. MÉCANISMES DE SIGNATURE NUMÉRIQUE DES TÉLÉCHARGE ­
MENTS 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échargement. Ce fichier doit contenir les certi ­
ficats MS  i .C et EQT.C. Le fichier contient les signatures 
numériques associées de blocs de données conformément 
aux indications fournies dans l'appendice 7 (Protocoles de 
téléchargement des données).  
CSM_033 Les signatures numériques des données téléchargées repose ­
ront sur l'utilisation d'un schéma de signature numérique avec 
appendice permettant, le cas échéant, de lire des données 
téléchargées sans aucun décryptage.  
6.1. Génération de signatures  
CSM_034 La génération de signatures de données par l'équipement 
respectera le schéma de signature avec appendice, défini 
dans le document de référence [PKCS1] avec la fonction 
de hachage SHA-1:  
Signature = EQT.SK[‘00’ || ‘01’ ||  PS || ‘00’ || DER(SHA-1 
(Data))]  
PS = Chaîne d'octets de remplissage de valeur ‘FF’ dont la 
longueur équivaut à 128.  
DER(SHA-1( M)) correspond à l'encodage de l'ID de l'algo ­
rithme pour la fonction de hachage et la valeur de hachage, 
dans une valeur ASN.1 de type DigestInfo (règles d'encodage 
distinctes):  
‘30’||‘21’||‘30’||‘09’||‘06’||‘05’|| ‘2B’|‘0E’||‘03’||‘02’||‘1A’||‘05’|| 
‘00’||‘04’||‘14’||Valeur de hachage  
6.2. Vérification de signatures  
CSM_035 La vérification de signatures de données, à laquelle sont 
soumises les données téléchargées, respectera le schéma de 
signature avec appendice, défini dans le document de réfé ­
rence [PKCS1] avec la fonction de hachage 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 respecter 
pour vérifier l'intégrité des données téléchargées et enregis ­
trées sur l'ESM (support de mémoire externe). La carte de 
contrôle permet de procéder au décryptage des signatures 
numériques. 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échargement et à la signa ­
ture des données à analyser est désigné par l'abréviation 
EQT.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 379
  
PARTIE B  
TACHYGRAPHE DE DEUXIÈME GÉNÉRATION  
7. INTRODUCTION  
7.1. Références  
Le présent appendice fait référence aux références suivantes:  
AES National Institute of Standards and Technology (NIST), 
FIPS PUB 197: Advanced Encryption Standard, 
26 novembre 2001  
DSS National Institute of Standards and Technology (NIST), 
FIPS PUB 186-4: Digital Signature Standard (DSS), 
juillet 2013  
ISO 7816-4 ISO/CEI 7816-4 Cartes d'identification — Cartes à circuit 
intégré — Partie 4 Organisation, sécurité et commandes 
pour les échanges. Troisième édition 2013-04-15  
ISO 7816-8 ISO/CEI 7816-8 Cartes d'identification — Cartes à circuit 
intégré — Partie 8 Commandes pour des opérations de 
sécurité. Seconde édition: 2004-06-01  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 380  
ISO 8825-1 ISO/CEI 8825-1 Technologies de l'information — Règles 
de codage ASN.1: Spécification des règles de codage de 
base (BER), des règles de codage canoniques (CER) et des 
règles de codage distinctives (DER). Quatrième édition, 
2008-12-15  
ISO 9797-1 ISO/CEI 9797-1 Technologies de l'information — Tech ­
niques de sécurité — Codes d'authentification de message 
(MAC) — Partie 1: Mécanismes utilisant un cryptage par 
blocs. Seconde édition: 2011-03-01  
ISO 10116 ISO/CEI 10116,Technologies de l'information — Tech ­
niques de sécurité — Modes opératoires 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 tachy ­
graphiques — Partie 3: Interface de capteur de mouve ­
ment. Première édition 2004, comprenant le rectificatif 
technique 1 2006  
RFC 5480 Informations relatives à la clé publique soumise à crypto ­
graphie à courbe elliptique, mars 2009  
RFC 5639 Cryptographie à courbe elliptique (ECC) — Génération de 
courbes et de courbes standard Brainpool, 2010  
RFC 5869 Fonction de dérivation de clé par extraction et expansion 
basée sur HMAC (HKDF), mai 2010  
SHS National Institute of Standards and Technology (NIST), 
FIPS PUB 180-4: Norme de hachage sécurisé, mars 2012  
SP 800-38B National Institute of Standards and Technology (NIST), 
Special Publication 800-38B: Recommandation pour les 
modes d'exploitation de cryptage par blocs: Mode 
CMAC d'authentification, 2005  
TR-03111 BSI Technical 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 Norme de cryptage avancé (Advanced Encryption Stan ­
dard)  
CA Organisme de certification  
CAR Références de l'organisme de certification  
CBC Mode d'exploitation par chaînage de blocs de données 
cryptées TDEA  
CH En-tête de commande  
CHA Autorisation d'un titulaire de certificat  
CHR Références d'un titulaire de certificat  
CV Vecteur constant  
DER Règles de codage distinctes  
DO Objet de données  
DSRC Communication dédiée de courte portée  
ECC Cryptographie à courbe elliptique  
ECDSA Algorithme de signature numérique à courbe elliptique  
ECDH Courbe elliptique de Diffie-Hellman (algorithme de 
concordance de clé)  
EGF Dispositif GNSS externe  
EQT Équipement  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 381  
IDS identificateur de service  
K M Clé maîtresse du capteur de mouvement permettant de 
coupler une unité embarquée sur véhicule avec un 
capteur de mouvement  
K M-VU  Clé insérée dans les unités embarquées sur véhicule 
permettant à une VU d'extraire la clé maîtresse du 
capteur de mouvement si une carte d'atelier est insérée 
dans la VU  
K M-WC  Clé insérée dans les cartes d'atelier permettant à une VU 
d'extraire la clé maîtresse du capteur de mouvement si une 
carte d'atelier est insérée dans la VU  
MAC Code d'authentification du message  
MoS Capteur de mouvement  
MSB Octet le plus significatif  
PKI Infrastructure à clé(s) publique(s) (ICP) ou infrastructure 
de gestion de clés (IGC)  
RCF Équipement de communication à distance  
SSC Compteur de séquences d'émission  
MS Messagerie sécurisée  
TDES Triple Data Encryption Standard (norme relative au cryp ­
tage triple des données)  
TLV Longueur des marqueurs  
VU Unité embarquée sur le véhicule  
X.C Certificat de clé publique d'un utilisateur X  
X.CA Organisme de certification qui a émis le certificat d'un 
utilisateur X  
X.CAR Référence de l'organisme de certification mentionnée dans 
le certificat d'un utilisateur X  
X.CHR Référence du titulaire du certificat mentionné dans le certi ­
ficat d'un utilisateur X  
X.PK Clé publique d'un utilisateur X  
X.SK Clé privée d'un utilisateur X  
X.PK  eph Clé publique éphémère d'un utilisateur X  
X.SK  eph Clé privée éphémère d'un utilisateur X  
‘xx’ Valeur hexadécimale  
|| Opérateur de concaténation  
7.3. Définitions  
Les définitions des termes utilisés dans le présent appendice figurent à la 
section 1 de l'annexe 1C.  
8. SYSTÈMES ET ALGORITHMES CRYPTOGRAPHIQUES  
8.1. Systèmes cryptographiques  
CSM_38 Les unités embarquées sur véhicule et les cartes tachygra ­
phiques auront recours à un système cryptographique clas ­
sique à clé publique à courbe elliptique pour assurer les 
mécanismes de sécurité suivants:  
— authentification mutuelle entre une unité embarquée sur 
véhicule et une carte,  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 382  
— 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 tachygraphiques vers 
un support de stockage externe.  
CSM_39 Les unités embarquées sur véhicule et les dispositifs GNSS 
externes auront recours à un système cryptographique à clé 
publique à courbe elliptique pour assurer les mécanismes 
de sécurité suivants:  
— couplage d'une unité embarquée sur véhicule et d'un 
dispositif GNSS externe,  
— authentification 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 externe.  
CSM_40 Les unités embarquées sur véhicule et les cartes tachygra ­
phiques auront recours à un système cryptographique AES 
symétrique pour assurer les mécanismes de sécurité 
suivants:  
— assurer l'authenticité et l'intégrité des données échan ­
gées entre une unité embarquée sur véhicule et une 
carte tachygraphique,  
— le cas échéant, assurer la confidentialité des données 
échangées entre une unité embarquée sur véhicule et 
une carte tachygraphique.  
CSM_41 Les unités embarquées sur véhicule et les dispositifs GNSS 
externes auront recours à un système cryptographique AES 
symétrique pour assurer les mécanismes de sécurité 
suivants:  
— assurer l'authenticité et l'intégrité des données échan ­
gé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 capteurs de 
mouvement auront recours à un système cryptographique 
AES symétrique pour assurer les mécanismes de sécurité 
suivants:  
— couplage d'une unité embarquée sur véhicule et d'un 
capteur de mouvement,  
— authentification mutuelle entre une unité embarquée sur 
véhicule et un capteur de mouvement,  
— assurer la confidentialité des données échangées entre 
une unité embarquée sur véhicule et un capteur de 
mouvement.  
CSM_43 Les unités embarquées sur véhicule et les cartes de 
contrôle auront recours à un système cryptographique 
AES symétrique pour assurer les mécanismes de sécurité 
suivants:  
— assurer la confidentialité, l'authenticité et l'intégrité des 
données transmises par une unité embarquée sur véhi ­
cule à une carte de contrôle.  
Remarques:  
— Pour être précis, les données sont transmises par une 
unité embarquée sur véhicule vers un interrogateur 
distant sous le contrôle d'un agent de contrôle, qui se 
sert d'un dispositif de communication à distance interne  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 383  
ou externe à la VU; cf. appendice 14. Cependant, l'in ­
terrogateur distant adresse les données reçues à une 
carte de contrôle qui les déchiffre et valide leur authen ­
ticité. Du point de vue de la sécurité, le dispositif de 
communication distant et l'interrogateur distant sont 
entièrement transparents.  
— Une carte d'atelier offre les mêmes services de sécurité 
au regard de l'interface DSRC qu'une carte de contrôle. 
Cela permet à un atelier de valider le fonctionnement 
satisfaisant de l'interface de communication à distance 
d'une VU, y compris la sécurité. Consulter la section 
9.2.2 pour toute information complémentaire.  
8.2. Algorithmes cryptographiques  
8.2.1  Algorithmes symétriques  
CSM_44 Les unités embarquées sur véhicule, cartes tachygra ­
phiques, capteurs de mouvement et dispositifs GNSS 
externes devront être compatibles avec l'algorithme AES 
défini dans [AES] en respectant les longueurs de clés de 
128, 192 et 256 bits.  
8.2.2  Algorithmes asymétriques et paramètres de domaine normalisés  
CSM_45 Les unités embarquées sur véhicule, cartes tachygraphiques 
et dispositifs GNSS externes devront être compatibles avec 
la cryptographie à courbe elliptique 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 tachygraphiques 
et dispositifs GNSS externes devront être compatibles avec 
l'algorithme de signature ECDSA défini dans [DSS].  
CSM_47 Les unités embarquées sur véhicule, cartes tachygraphiques 
et dispositifs GNSS externes devront être compatibles avec 
l'algorithme de concordance avec les clés ECKA-EG défini 
dans [TR 03111].  
CSM_48 Les unités embarquées sur véhicule, cartes tachygraphiques 
et dispositifs GNSS externes devront être compatibles avec 
tous les paramètres de domaines normalisés définis au 
Tableau 1 ci-après se rapportant à la cryptographie à 
courbe elliptique.  
Tableau 1  
Paramètres de domaines normalisés  
Nom  Tailles (en bits)  Référence  Identificateur d'objet  
NIST P-256  256  [DSS], [RFC 5480]
  
BrainpoolP256r1  256  [RFC 5639]
  
NIST P-384  384  [DSS], [RFC 5480]
  
BrainpoolP384r1  384  [RFC 5639]
  
BrainpoolP512r1  512  [RFC 5639]
  
NIST P-521  521  [DSS], [RFC 5480]
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 384  
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 Brainpool et dans [RFC 5480] pour 
les courbes NIST.
  
8.2.3  Algorithmes de hachage  
▼M1 
CSM_49 Les unités embarquées sur véhicule, les cartes tachygra ­
phiques et les dispositifs GNSS externes devront être 
compatibles avec les algorithmes SHA-256, SHA-384 et 
SHA-512 définis dans [SHS].  
▼B 
8.2.4  Méthodes de cryptage  
CSM_50 Dans le cas où un algorithme symétrique, un algorithme 
asymétrique et/ou un algorithme de hachage sont associés 
pour former un protocole de sécurité, leur longueur de clé 
et taille de hachage respectives doivent être de force (qua ­
siment) égale. Le Tableau 2 montre les méthodes de cryp ­
tage autorisées:  
Tableau 2  
Méthodes de cryptage autorisées  
ID Suite cryptée  Taille de clé ECC (en 
bits) Longueur de clé AES 
(en bits)  Algorithme 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  
Remarque:  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 CERTIFICATS  
9.1. Paires de clés asymétriques et certificats de clé publique  
9.1.1  Généralités  
Note:  les clés décrites dans cette section servent à l'authentification 
mutuelle et à la messagerie sécurisée entre les unités embarquées sur 
véhicule et les cartes tachygraphiques, ainsi qu'entre les unités embar ­
quées sur véhicule et les dispositifs GNSS externes. Ces processus sont 
décrits en détail dans les chapitres 10 et 11 du présent appendice.  
CSM_51 Au sein du système de tachygraphie intelligente euro ­
péenne, les paires de clés ECC et leurs certificats sont 
générés et gérés selon trois niveaux hiérarchiques fonction ­
nels:  
— niveau européen,  
— niveau État membre,  
— niveau équipement.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 385  
CSM_52 Au sein du système de tachygraphie intelligente euro ­
péenne, les clés privées et publiques ainsi que les certifi ­
cats sont générés, gérés et communiqués au moyen de 
méthodes sécurisé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 tachygraphie 
intelligente européenne. Ces tâches sont exécutées par une 
Autorité de certification racine européenne (ERCA), placée 
sous l'autorité et la responsabilité de la Commission euro ­
péenne.  
CSM_54 L'ERCA utilise la clé privée européenne pour signer un 
certificat racine (autosigné) de la clé publique européenne 
et communique ce certificat racine européen à tous les 
États membres.  
CSM_55 L'ERCA utilise la clé privée européenne pour signer les 
certificats des clés publiques dans les États membres sur 
demande. L'ERCA conserve les relevés de tous les certifi ­
cats 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'organisme crée un nouveau 
certificat racine autosigné 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.  
Remarque:  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 capteur de mouvement et 
une nouvelle clé maîtresse DSRC; 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 euro ­
péenne, l'ERCA mène une analyse de la force cryptogra ­
phique nécessaire pour la nouvelle paire de clés, sachant 
qu'elle doit rester sécurisée pendant les 34 prochaines 
années. Si cela se révèle nécessaire, l'ERCA adopte une 
méthode de cryptage plus puissante que l'actuelle, comme 
le prévoit CSM_50.  
▼M1 
CSM_58 Dès lors que l’ERCA génère une nouvelle paire de clés 
racine européenne, l’organisme 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é d’un certificat de lien est de 17 ans plus trois 
mois. La figure 1 de la section 9.1.7 l’illustre également.  
▼B 
Remarque:  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'équi ­
pement de génération  X. 
CSM_59 L'ERCA 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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 386  
CSM_60 À tout moment, l'ERCA doit disposer des clés et des 
certificats cryptographiques suivants:  
— la paire de clés EUR en vigueur et le certificat corres ­
pondant,  
— tous les certificats EUR antérieurs à utiliser pour véri ­
fier les certificats MSCA toujours valides,  
— les certificats de lien de toutes les générations de certi ­
ficats EUR à l'exception 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 tachygraphique génè ­
rent une ou plusieurs paires de clés ECC unique, appelée 
MSCA_Card. Tous les États membres devant signer les 
certificats des unités embarquées sur véhicule ou des 
dispositifs GNSS externes génèrent en plus une ou 
plusieurs paires de clés ECC unique, appelée 
MSCA_VU-EGF.  
CSM_62 La tâche 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'obtenir un certificat propre à 
l'État membre correspondant, 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 correspon ­
dant.  
CSM_64 Une paire de clés MSCA_VU-EGF, le cas échéant, se 
compose 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 exclusivement 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 compose 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 exclusivement pour signer les certificats 
de clé publique des cartes tachygraphiques.  
CSM_66 Une MSCA conserve des archives de tous les certificats de 
VU signés, de tous les certificats de dispositifs GNSS 
externes signés et de tous les certificats de cartes ainsi 
que l'identification 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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 387  
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'expira ­
tion 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érieurs à utiliser 
pour vérifier les certificats des cartes tachygraphiques 
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 certificats MSCA toujours 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 certi ­
ficat correspondant,  
— toutes les clés publiques MSCA_VU-EGF antérieures à 
utiliser pour vérifier les certificats des VU ou des 
dispositifs GNSS externes toujours valides.  
9.1.4  Niveau équipement: unités embarquées sur véhicule  
▼M1 
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 à sa MSCA afin 
d’obtenir un certificat VU correspondant, signé par la 
MSCA. La clé privée sert uniquement à une unité embar ­
quée sur véhicule.  
▼B 
CSM_73 Les certificats 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 fabricant 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, composée d'une clé privée VU_MA.SK et d'une 
clé publique VU_MA.PK, exclusivement pour effectuer 
des opérations d'authentification de VU avec les cartes 
tachygraphiques 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 pouvoir générer des 
paires de clés ECC éphémères et utiliser une paire de clés 
éphémères exclusivement pour effectuer la concordance de 
clés de session avec une carte tachygraphique ou un dispo ­
sitif GNSS externe, comme le prévoient les sections 10.4 
et 11.4 du présent appendice.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 388  
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 exclusivement 
pour signer des fichiers de données téléchargés, comme le 
prévoit le chapitre 14 du présent appendice. La clé 
publique VU_Sign.PK correspondante 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.  
Remarques:  
— 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 rapport à des données téléchar ­
gées pendant les trois premiers mois qui suivent sa date 
d'expiration, comme l'exige le règlement n  o 581/2010  
— La durée de validité étendue d'un certificat VU_MA est 
nécessaire pour permettre à la VU d'authentifier une 
carte de contrôle ou une carte d'entreprise pendant les 
trois premiers mois qui suivent sa date d'expiration, de 
manière à pouvoir effectuer des téléchargements 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 (hormis 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.  
Remarques:  
— Les paires de clés éphémères ne sont pas soumises à 
cette exigence, car une nouvelle paire de clés éphé ­
mères est générée par la VU à chaque exécution 
d'une authentification de circuit et à chaque concor ­
dance de clé de session; cf. section 10.4.  Remarque:  
les paires de clés éphémères ne possèdent pas de certi ­
ficats correspondants.  
— Cette exigence n'interdit 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écurisé par le fabricant de VU.  
CSM_81 Lorsqu'elle est mise en service, la VU contient les clés et 
les certificats cryptographiques 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 comprenant la clé 
publique MSCA_VU-EGF.PK à utiliser pour vérifier 
les certificats VU_MA et VU_Sign;  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 389  
— 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éri ­
fier 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 certificats cryptographiques listés en 
CSM_81, les VU contiennent également les clés et les 
certificats précisés à la partie A du présent appendice, 
permettant à une VU d'interagir avec les cartes tachygra ­
phiques de première génération.  
9.1.5  Niveau équipement: cartes tachygraphiques  
▼M1 
CSM_83 Une paire de clés ECC unique appelée Card_MA est 
générée pour chaque carte tachygraphique. Une deuxième 
paire de clés ECC unique, appelé Card_Sign, est générée 
en plus pour chaque carte de conducteur et chaque carte 
d’atelier. Cette tâche incombe aux fabricants et aux person ­
nalisateurs de cartes. Dès lors qu’une paire de clés pour 
carte est générée, la partie qui la génère doit adresser la clé 
publique à sa MSCA afin d’obtenir un certificat pour carte 
correspondant, signé par la MSCA. La clé privée sert 
uniquement à la carte tachygraphique.  
▼B 
CSM_84 Les certificats 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 tachygraphique utilise sa paire de clés 
Card_MA, composée d'une clé privée Card_MA.SK et 
d'une clé publique Card_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 10.3 et 10.4 du présent appendice.  
CSM_87 Une carte de conducteur ou d'atelier utilise la clé privée 
Card_Sign.SK de sa paire de clés Card_Sign exclusive ­
ment pour signer des fichiers de données téléchargés, 
comme le prévoit le chapitre 14 du présent appendice. 
La clé publique Card_Sign.PK correspondante sert exclu ­
sivement à vérifier les signatures créées par la carte.  
▼M1 
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’entreprise: 5 ans  
— Pour les cartes de contrôle: 2 ans  
— Pour les cartes d’atelier: 1 an  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 390  
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 conducteur de créer des signatures 
valides par rapport à des données téléchargées pendant le 
premier mois qui suit sa date d'expiration. Cela est néces ­
saire en vertu du règlement (UE) n  o 581/2010 qui exige 
qu'un téléchargement de données depuis une carte de 
conducteur soit possible jusqu'à 28 jours après la mémo ­
risation des dernières données.  
CSM_90 Les paires de clés et les certificats correspondants d'une 
carte tachygraphique donnée ne sont ni remplacés ni 
renouvelés après l'émission de ladite carte.  
CSM_91 Une fois émises, les cartes tachygraphiques contiennent les 
clés et les certificats cryptographiques suivants:  
— la clé privée Card_MA et le certificat correspondant;  
— en sus, pour les cartes de conducteur et d'atelier: la clé 
privée Card_Sign et le certificat correspondant  
— le certificat MSCA_Card comprenant la clé publique 
MSCA_Card.PK à utiliser pour vérifier les certificats 
Card_MA et Card_Sign;  
— le certificat EUR comprenant 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éri ­
fier le certificat MSCA_Card, le cas échéant;  
— le certificat de lien reliant ces deux certificats EUR, le 
cas échéant;  
▼M1 
— en outre, uniquement pour les cartes de contrôle, les 
cartes d’entreprise et les cartes d’atelier et seulement si 
ces cartes sont émises dans les trois premiers mois de 
la période de validité d’un nouveau certificat EUR: le 
certificat EUR plus ancien de deux générations, le cas 
échéant.  
Remarque pour le dernier point:  par exemple, au cours 
des trois premiers mois du certificat ERCA(3) (voir la 
figure 1), les cartes mentionnées incluent le certificat 
ERCA(1). L’inclusion du certificat ERCA est néces ­
saire pour permettre à ces cartes d’effectuer des télé ­
chargements de données à partir des VU d’ERCA(1), 
dont la durée de vie normale de 15 ans, à laquelle 
s’ajoute la période de téléchargement des données de 
trois mois, expire au cours de ces mois; voir le dernier 
point de l’exigence 13 de l’annexe IC.  
▼B 
CSM_92 Outre les clés et les certificats cryptographiques listés en 
CSM_91, les cartes tachygraphiques contiennent également 
les clés et les certificats précisés à la partie A du présent 
appendice, leur permettant d'interagir avec les VU de 
première génération.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 391  
9.1.6  Niveau équipement: dispositifs GNSS externes  
▼M1 
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 
externes. Dès lors qu’une paire de clés EGF_MA est géné ­
rée, la partie qui la génère doit adresser la clé publique à 
sa MSCA afin d’obtenir un certificat EGF_MA correspon ­
dant, signé par la MSCA. La clé privée sert uniquement au 
dispositif GNSS externe.  
▼B 
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.  
▼M1 
CSM_95 Un dispositif GNSS externe utilise sa paire de clés 
EGF_MA, composé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évoit la section 11.4 du présent appendice.  
▼B 
CSM_96 La durée de validité d'un certificat EGF_MA est de 15 ans.  
CSM_97 Un dispositif GNSS externe 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 compris 
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.  
Remarque:  cette exigence n'interdit pas la possibilité de 
remplacer les paires de clés EGF lors d'une maintenance 
ou d'une réparation dans un environnement contrôlé et 
sécurisé par le fabricant d'EGF.  
CSM_99 Lorsqu'il entre en opération, le dispositif GNSS externe 
contient les clés et les certificats cryptographiques 
suivants:  
— la clé privée EGF_MA et le certificat correspondant;  
— le certificat MSCA_VU-EGF comprenant la clé 
publique MSCA_VU-EGF.PK à utiliser pour vérifier 
le certificat EGF_MA;  
— le certificat EUR comprenant la clé publique EUR.PK 
à utiliser pour vérifier le certificat MSCA_VU-EGF;  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 392  
— le certificat EUR dont la durée de validité précède 
directement celle du certificat EUR à utiliser pour véri ­
fier 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éralités: certificat de substitution  
La Figure 1 ci-après montre comment différentes générations de certifi ­
cats 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:  
▼M1 
Figure 1  
Émission et utilisation de différentes générations de certificats racine ERCA, de certificats de lien ERCA, de 
certificats MSCA et d’équipement
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 393  
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 certificats 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 certificatMSCA_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'apparais ­
sent les derniers certificats VU et Card émis sous ERCA (1). Cela 
s'explique par le fait que les certificats VU et Card sont émis sous un 
certificat MSCA, pas directement sous le certificat ERCA. Le certi ­
ficat MSCA (2-1) est émis immédiatement après l'entrée en validité 
d'ERCA (2), mais le certificat MSCA (1-last) est émis légèrement 
avant, à la toute fin de validité du certificat ERCA (1). Par consé ­
quent, ces deux certificats 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érentes.  
5. La durée de validité indiquée sur ces cartes est celle des cartes de 
conducteur (5 ans).  
▼M1 
6. Pour gagner de l’espace, la différence entre les durées de validité des 
certificats Card_MA et des certificats Card_Sign n’est précisée que 
pour la première génération.  
▼B 
9.2. Clés symétriques  
9.2.1  Clés de sécurisation de la communication du capteur de mouvement de 
la VU  
9.2.1.1  Généralités  
Note:  les lecteurs de la présente section doivent maîtriser le contenu de la 
norme [ISO 16844-3] qui décrit l'interface entre une VU et un capteur de 
mouvement. La procédure de couplage entre une VU et un capteur de 
mouvement est décrite en détail au chapitre 12 du présent appendice.  
CSM_100 Un nombre de clés symétriques donné est nécessaire pour 
coupler des VU et des capteurs de mouvement, en vue de 
leur authentification mutuelle et afin de chiffrer la commu ­
nication 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 capteur de mouvement, cette dernière 
étant liée à la longueur de la paire de clés racine européenne 
(anticipée), comme le prévoit le CSM_50.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 394  
Tableau 3  
Clés de sécurisation de la VU — communication du capteur de mouvement  
Légende  Symbole  Produit par  Méthode de génération  Mémorisé par  
Clé maîtresse du capteur 
de mouvement — partie 
VU K M-VU  ERCA  Aléatoire  ERCA, MSCA impliquées dans 
l'émission des certificats VU, 
fabricants de VU, VU  
Clé maîtresse du capteur 
de mouvement — partie 
atelier  K M-WC  ERCA  Aléatoire  ERCA, MSCA, fabricants de 
cartes, cartes d'atelier  
Clé maîtresse du capteur 
de mouvement  K M Généré de manière 
non indépendante  Calculé comme K  M = 
K M-VU  XOR K  M-WC  ERCA, MSCA impliquées dans 
l'émission des clés de capteurs 
de mouvement (facultatif) (*)  
Clé d'identification  K  ID Généré de manière 
non indépendante  Calculé comme K  ID =  
K M XOR CV, où CV 
est défini par le 
CSM_106  ERCA, MSCA impliquées dans 
l'émission des clés de capteurs 
de mouvement (facultatif) (*)  
Clé de couplage  K  P Fabricant des 
capteurs de 
mouvement  Aléatoire  Un capteur de mouvement  
Clé de session  K  S VU (durant le 
couplage de la 
VU et du capteur 
de mouvement)  Aléatoire  Une VU et un capteur de 
mouvement  
(*) Le stockage de K  M et K  ID est facultatif, car ces clés peuvent être calculées selon K  M-VU  , K  M-WC  et CV.  
CSM_101 L'autorité de certification racine européenne génère K  M-VU  et 
K M-WC  , deux clés AES aléatoires et uniques dont dérive le 
calcul de la clé maîtresse du capteur de mouvement K  M 
comme K  M-VU  XOR K  M-WC  . L'ERCA communique K  M, 
K M-VU  et K  M-WC  aux organismes de certification de l'État 
membre sur leur demande.  
CSM_102 L'ERCA attribue à chaque clé maîtresse du capteur de 
mouvement K  M un numéro de version unique, qui s'applique 
également à la constitution des clés K  M-VU  et K  M-WC  ainsi 
qu'à l'identification du K  ID. de la clé qui y est associée. 
L'ERCA informe les MSCA du numéro de version 
lorsqu'elle leur adresse K  M-VU  et K  M-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 organismes de certification de l'État membre transmet ­
tent K  M-VU,  et son numéro de version aux fabricants de VU 
sur leur demande. Les fabricants de VU insèrent K  M-VU  et 
son numéro de version dans toutes les VU fabriquées.  
CSM_104 Les organismes de certification de l'État membre vérifient 
que K  M-WC  et son numéro de version sont insérés dans 
chaque carte d'atelier émise sous leur responsabilité.  
Remarques:  
— Voir la description du type de données
  
dans l'appen ­
dice 2.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 395  
— Comme l'explique la section 9.2.1.2, il s'avère possible 
de devoir insérer plusieurs générations de K  M-WC  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 Km  WC, spécifiée par le CSM_037 dans la 
partie A du présent appendice, est insérée dans chaque carte 
d'atelier émise sous sa responsabilité.  
Remarques:  
— Cela permet d'utiliser une carte d'atelier de deuxième 
génération pour coupler une VU de première généra ­
tion. 
— Une carte d'atelier de deuxième génération contient 
deux applications distinctes. L'une se conforme à la 
partie B du présent appendice et l'autre à la partie A. 
Cette dernière contient la clé TDES Km  WC . 
CSM_106 Une MSCA impliquée dans l'émission de capteurs de 
mouvement calcule la clé d'identification de la clé maîtresse 
du capteur de mouvement en appliquant la fonction XOR 
ainsi qu'un vecteur constant, CV. La valeur du vecteur 
constant est la suivante:  
▼M1 
— Pour les clés maîtresses du capteur de mouvement sur 
128 bits: CV = «B6 44 2C 45 0E F8 D3 62 0B 7A 8A 
97 91 E4 5D 83»  
▼B 
— Pour les clés maîtresses du capteur 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 capteur 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 vecteurs 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  ►M1 Chaque fabricant de capteurs de mouvement génère 
une clé de couplage aléatoire unique K  P pour chaque capteur 
de mouvement et communique chaque clé de couplage à 
l’organisme de certification de son État membre. La 
MSCA chiffre chaque clé de couplage séparément à l’aide 
de la clé maîtresse du capteur de mouvement K  M et retourne 
la clé cryptée au fabricant de capteurs de mouvement. Pour 
chaque clé cryptée, la MSCA avertit le fabricant de capteurs 
de mouvement du numéro de version de la K  M associée. ◄ 
Note:  comme l'explique la section 9.2.1.2, il se peut qu'un 
fabricant de capteurs de mouvement doive générer plusieurs 
clés de couplage uniques pour un même capteur de mouve ­
ment.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 396  
CSM_108 Chaque fabricant de capteurs de mouvement génère un 
numéro de série unique pour chaque capteur de mouvement 
et communique tous les numéros de série à l’organisme de 
certification de son État membre. La MSCA chiffre chaque 
numéro de série séparément à l’aide de la clé d’identification 
K ID et retourne le numéro de série crypté au fabricant de 
capteurs de mouvement. Pour chaque numéro de série 
crypté, la MSCA avertit le fabricant de capteurs de mouve ­
ment du numéro de version du K  ID associé.  
▼B 
CSM_109 En ce qui concerne les exigences CSM_107 et CSM_108, la 
MSCA a recours à l'algorithme AES dans le mode d'exploi ­
tation par chaînage 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 remplissage numéro deux définie par la norme [ISO 
9797-1].  
CSM_110 Le fabricant de capteurs de mouvement stocke la clé de 
couplage et le numéro de série cryptés dans le capteur de 
mouvement auquel ils sont destinés. Il y stocke également 
les valeurs de texte en clair correspondantes et le numéro de 
version de K  M et de K  ID qui a servi au cryptage.  
Note:  comme l'explique la section 9.2.1.2, il se peut qu'un 
fabricant de capteurs 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 capteur de mouve ­
ment.  
CSM_111 Outre le matériel cryptographique AES spécifié en 
CSM_110, le fabricant de capteurs de mouvement peut 
également stocker dans chaque capteur de mouvement le 
matériel cryptographique TDES spécifié dans l'exigence 
CSM_037 dans la partie A du présent appendice.  
Note:  ce faisant, il permet à un capteur 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 K  S générée par une VU 
pendant le couplage avec un capteur de mouvement est liée 
à la longueur de son K  M-VU,  comme décrit au CSM_50.  
9.2.1.2  Remplacement de la clé maîtresse du capteur de mouvement dans un 
équipement de deuxième génération  
CSM_113 Toutes les clés maîtresses des capteurs de mouvement et 
toutes 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 remplacées tous les 17 ans. La durée de 
validité de chaque génération de clés maîtresses de capteur 
de mouvement commence un an avant que la paire de clés 
racine ERCA associée n'entre en validité et elle finit à l'ex ­
piration de la paire de clés racine ERCA associée. La Figure 
2 illustre ce principe.  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 397  
Figure 2  
Émission et utilisation de diverses générations de clés maîtresses de capteurs de mouvement sur des VU, des 
capteurs de mouvement 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, conformément au CSM_56, l'ERCA 
génère une nouvelle clé maîtresse de capteur de mouvement 
K M en générant de nouvelles K  M-VU  et K  M-WC  . La longueur 
de la clé maîtresse du capteur de mouvement est liée à la 
force anticipée de la nouvelle paire de clés racine euro ­
péenne conformément au CSM_50. L'ERCA communique 
les nouvelles K  M , K  M-VU  et K  M-WC  ainsi que leur numéro 
de version aux MSCA sur leur demande.  
CSM_115 Les MSCA s'assurent que toutes les générations valides de 
K M-WC  sont stockées dans chaque carte d'atelier émise sous 
leur autorité, de même que leurs numéros de version, 
comme illustré à la Figure.  
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 K  M-WC  , comme l'illustre la Figure 2.  
CSM_116 À propos de la procédure décrite par lesCSM_107 et 
CSM_108 ci-dessus: la MSCA chiffre chaque paire de clés 
de couplage K  P reçue des fabricants de capteurs de mouve ­
ment séparément selon chaque génération valide de clé 
maîtresse de capteur de mouvement K  M . La MSCA chiffre 
également chaque numéro de série reçu des fabricants de 
capteurs de mouvement séparément selon chaque génération 
valide de clé d'identification K  ID . Le fabricant de capteurs de 
mouvement stocke tous les cryptages de clé de couplage et 
de numéro de série dans le capteur de mouvement auquel ils 
sont destinés. Il y stocke également les valeurs de texte en 
clair correspondantes et le ou les numéro(s) de version de 
K M et K  ID qui ont servi au cryptage.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 398  
Remarque:  cela implique qu'au cours de la dernière année de 
validité d'un certificat ERCA, les capteurs de mouvement 
sont émis avec des données cryptées selon trois générations 
de K  M, , comme l'illustre la Figure 2.  
CSM_117 À propos de la procédure décrite par le CSM_107 ci-dessus: 
du fait que la longueur de la clé de couplage K  P doit être 
liée à celle de K  M (cf. CSM_100), il se peut que le fabricant 
de capteurs de mouvement doive générer jusqu'à trois clés 
de couplage distinctes (de longueurs différentes) pour un 
même capteur de mouvement, pour anticiper les éventuelles 
longueurs des générations futures de K  M. 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 capteur de 
mouvement, c'est-à-dire celle présentant la même longueur.  
Remarque:  si le fabricant de capteurs de mouvement choisit 
de générer une clé de couplage TDES pour un capteur de 
mouvement de deuxième génération (cf. CSM_111), il 
indique à la MSCA que la clé maîtresse du capteur de 
mouvement TDES doit servir à chiffrer cette clé de 
couplage. Cela s'impose parce que la longueur de la clé 
TDES pourrait être égale à celle de la clé AES. La 
MSCA ne pourrait alors pas les distinguer sur leurs 
longueurs respectives.  
CSM_118 Les fabricants de VU insèrent uniquement une génération de 
K M-VU  dans chaque VU, accompagnée de son numéro de 
version. Cette génération de K  M-VU  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 K  M-VU,  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 
capteur de mouvement de génération  X-1. 
— Du fait que les cartes d'atelier présentent une validité 
d'un an, les exigences CSM_113 — CSM_118 font 
que toutes les cartes d'atelier contiennent le nouveau 
K M-WC  à l'émission de la première VU contenant le 
nouveau K  M-VU  . Par conséquent, une telle VU pourra 
toujours calculer la nouvelle K  M . De plus, pendant ce 
temps, la plupart des nouveaux capteurs de mouvement 
contiendront des données codées basées sur la nouvelle 
K M , également.  
9.2.2  Clés de sécurisation de la communication DSRC  
9.2.2.1  Généralités  
CSM_119 L'authenticité et la confidentialité des données communi ­
quées par la VU aux autorités de contrôle à l'aide d'un 
canal de communication distant DSRC sont garanties par 
un jeu de clés AES propres à la VU découlant d'une 
unique clé maîtresse DSRC, KM  DSRC  . ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 399  
CSM_120 La clé maîtresse DSRC KM  DSRC  est une clé AES générée, 
stockée et diffusée de manière sécurisé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, 
conformément au CSM_50.  
CSM_121 L'ERCA communique la clé maîtresse DSRC aux orga ­
nismes de certification de l'État membre sur leur demande 
et de manière sécurisée. Cela leur permet de calculer les clés 
DSRC propres aux VU et de s'assurer que la clé maîtresse 
DSRC est insérée dans toutes les cartes de contrôle et d'ate ­
lier émises sous leur responsabilité.  
CSM_122 L'ERCA attribue un numéro de version unique à chaque clé 
maîtresse DSRC. L'ERCA informe les MSCA du numéro de 
version lorsqu'elle leur adresse la clé maîtresse DSRC.  
Remarque:  le numéro de version sert à distinguer les géné ­
rations de ces clés maîtresses DSRC, comme l'explique en 
détail la section 9.2.2.2.  
▼M1 
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 certifica ­
tion de l’État membre en vue d’obtenir un jeu de deux clés 
DSRC propre aux VU. Le numéro de série VU relève du 
type de données
  .  
Remarque:  
— Ce numéro de série VU est identique à l’élément vuSe ­
rialNumber de VuIdentification (voir l’appendice 1) et à 
la référence du titulaire de certificat figurant dans les 
certificats de la VU.  
— Le numéro de série de la VU peut ne pas être connu au 
moment où un fabricant d’unité embarquée sur véhicule 
demande les clés de DSRC propres à la VU. Dans ce 
cas, le fabricant de VU envoie l’ID unique de demande 
de certificat qu’il a utilisé au moment de sa demande de 
certificats de la VU; cf. CSM_153. Cet ID de demande 
de certificat est donc identique à la référence des orga ­
nismes de certification indiquée dans les certificats de la 
VU. 
▼B 
CSM_124 Dès réception d'une demande de clés DSRC propres aux 
VU, la MSCA calcule deux clés AES pour la VU, appelées 
K_VU  DSRC  _ENC et K_VU  DSRC  _MAC. Ces clés propres 
aux VU sont de longueur identique à celle de la clé 
maîtresse DSRC. La MSCA utilise la fonction de dérivation 
de clé définie au [RFC 5869]. La fonction de hachage néces ­
saire pour instancier la fonction de hachage HMAC est liée 
à la longueur de la clé maîtresse DSRC, conformément au 
CSM_50. La fonction de dérivation de clé figurant au [RFC 
5869] sert de la manière suivante:  
Étape n  o 1 (extraction):  
— PRK  = HMAC-Hash ( salt, IKM ) où salt représente une 
chaîne vide ‘’ et  IKM  correspond à KM  DSRC  . ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 400  
Étape n  o 2 (expansion):  
— OKM  = T(1) , avec  
T(1) = HMAC-Hash ( PRK , T(0)  || info  || ‘01’) et  
— T(0)  = chaîne vide (‘ ’)  
— ►M1 info  = numéro de série VU ou ID de la 
demande de certificat, comme indiqué au 
CSM_123 ◄ 
— K_VU  DSRC  _ENC = premiers  L octets de  OKM  et 
K_VU  DSRC  _MAC = derniers  L octets de  OKM  
où L de la longueur requise de K_VU  DSRC  _ENC et 
K_VU  DSRC  _MAC en octets.  
CSM_125 La MSCA communique K_VU  DSRC  _ENC et 
K_VU  DSRC  _MAC aux fabricants de VU de manière sécu ­
risée en vue de leur insertion dans les VU auxquelles ils 
sont destinés.  
CSM_126 Après leur émission, la VU enregistre K_VU  DSRC  _ENC et 
K_VU  DSRC  _MAC dans sa mémoire sécurisée, de façon à 
pouvoir assurer l'intégrité, l'authenticité et la confidentialité 
des données envoyées au moyen du canal de communication 
distant. La VU mémorise également le numéro de version de 
la clé maîtresse DSRC servant à calculer les clés propres 
aux VU.  
CSM_127 Après leur émission, les cartes de contrôles et d'atelier enre ­
gistrent KM  DSRC  dans leur mémoire sécurisé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 à pouvoir décrypter ces données. Les cartes de 
contrôle et d'atelier mémorisent également le numéro de 
version de la clé maîtresse DSRC.  
Note:  comme l'explique la section 9.2.2.2, il s'avère possible 
de devoir insérer plusieurs générations de KM  DSRC  dans une 
même carte d'atelier ou de contrôle.  
▼M1 
CSM_128 La MSCA archive toutes les clés DSRC propres aux VU 
qu’elle a générées, ainsi que leur numéro de version et le 
numéro de série VU ou l’ID de la demande de certificat 
utilisé pour les obtenir.  
▼B 
9.2.2.2  Substitution de clé maîtresse DSRC  
CSM_129 Toutes les clés maîtresses DSRC sont liées à une génération 
donnée de paire de clés racine ERCA. L'ERCA remplace 
donc chaque clé maîtresse DSRC tous les 17 ans. La durée 
de validité de chaque génération de clés maîtresses DSRC 
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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 401  
Figure 3  
Émission et utilisation de diverses générations de clés maîtresses DSRC 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, conformément au CSM_56, 
l'ERCA génère une nouvelle clé maîtresse DSRC. La 
longueur de la clé maîtresse DSRC est liée à la force anti ­
cipée de la nouvelle paire de clés racine européenne confor ­
mément au CSM_50. L'ERCA communique la nouvelle clé 
maîtresse DSRC ainsi que son numéro de version aux 
MSCA sur leur demande.  
CSM_131 Les MSCA s'assurent que toutes les générations valides de 
KM  DSRC  sont stockées dans chaque carte de contrôle émise 
sous leur autorité, 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 KM  DSRC  , comme l'illustre 
la Figure 2.  
CSM_132 Les MSCA s'assurent que toutes les générations de KM  DSRC  
valides depuis au moins un an et toujours en cours de vali ­
dité sont stockées dans chaque carte d'atelier émise sous leur 
autorité, de même que leurs numéros de version, comme 
illustré à la Figure 2.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 402  
Note:  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  DSRC  , comme l'illustre 
la Figure 2.  
CSM_133 Les fabricants de VU insèrent uniquement un jeu de clés 
DSRC propres aux VU dans chaque VU, accompagné de 
son numéro de version. Ce jeu de clés résulte de la généra ­
tion KM  DSRC  liée au certificat ERCA dont découlent les 
certificats VU.  
Remarques:  
— Cela implique qu'une VU liée à un certificat ERCA de 
génération  X contient uniquement une K_VU  DSRC  _ENC 
et une K_VU  DSRC  _MAC  , 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ésentent une validité 
d'un an et les cartes de contrôle une validité de deux 
ans, les exigences CSM_131 — CSM_133 font que 
toutes les cartes d'atelier et de contrôle contiennent la 
nouvelle clé maîtresse DSRC à l'émission de la première 
VU contenant les clés propres aux VU relevant de cette 
clé maîtresse.  
9.3. Certificats  
9.3.1  Généralités  
CSM_134 Tous les certificats inscrits dans le système de tachygraphie 
intelligente européenne sont de type autodescriptifs et véri ­
fiables par carte (VC) conformément aux normes [ISO 7816- 
4] et [ISO 7816-8].  
CSM_135  ►M1 Les règles de codage distinctes (DER) conformes à la 
norme [ISO 8825-1] servent à encoder les objets de données 
au sein des certificats. Le tableau 4 présente le codage inté ­
gral du certificat, y compris toutes les balises et les 
longueurs en octets. ◄ 
Note:  cet cryptage produit la structure Tag-Length-Value 
(TLV) suivante:  
Balise: la balise est cryptée sur un ou deux octet(s) et 
indique le contenu.  
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'octets.  
Valeur: la valeur est cryptée sur zéro octet ou plus.  
9.3.2  Contenu du certificat  
CSM_136 Tous les certificats possèdent une structure présentée dans le 
profil de certificat du Tableau 4.  
Tableau 4  
Profil de certificat version 1  
Champ  ID de champ  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  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 403  
Champ  ID de champ  Balise  Longueur (en octets)  Type de données ASN.1 
(voir appendice 1)  
Identificateur de 
profil du certificat  CPI ‘5F 29’  ‘01’
  
Référence de l'orga ­
nisme de certification  CAR  ‘42’  ‘08’
  
Autorisation du titu ­
laire de certificat  CHA  ‘5F 4C’  ‘07’
  
Clé publique  PK  ‘7F 49’  var  
Paramètres de domai ­
nes 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.CAR désigne la référence des organismes 
de certification mentionnée dans le certificat d'un utilisa ­
teur X.  
9.3.2.1 Certificate Profile Identifier  
CSM_137 Les certificats adoptent un identificateur de profil de certi ­
ficat pour indiquer le profil 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 Authority Reference  
CSM_138 La référence des organismes de certification sert à identifier 
la clé publique à utiliser pour vérifier la signature du certi ­
ficat. La référence des organismes de certification doit donc 
être identique à celle du titulaire de certificat dans le certi ­
ficat des organismes de certification correspondants.  
CSM_139 Un certificat racine ERCA est autosigné, c'est-à-dire que la 
référence des organismes de certification et la référence du 
titulaire du certificat figurant sur le certificat sont identiques.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 404  
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 organismes de certification d'un 
certificat de lien est identique au CHR du certificat racine 
ERCA antérieur.  
9.3.2.3 Certificate Holder Authorisation  
▼M1 
CSM_141 L’autorisation du titulaire de certificat permet d’identifier le 
type de certificat. Elle se compose des six octets principaux 
de l’ID de l’application tachygraphique concaténée avec le 
type d’équipement, qui indique le type d’équipement auquel 
est destiné le certificat. Concernant les certificats VU, les 
certificats de carte de conducteur et les certificats de carte 
d’atelier, le type d’équipement est également utilisé pour 
distinguer les certificats pour l’authentification mutuelle 
des certificats à utiliser pour la création d’une signature 
numérique (voir la section 9.1 et l’appendice 1, type de 
données EquipmentType).  
▼B 
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 identificateurs 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 convertis en 
chaînes d'octets comme le précise le [TR-03111]. On utilise 
la structure cryptée non compressée. Les validations décrites 
au [TR-03111] s'appliquent toujours lorsque l'on décode un 
point de la courbe elliptique.  
9.3.2.5 Certificate Holder Reference  
CSM_144 La référence du titulaire de certificat sert d'identificateur 
pour la clé publique fournie avec le certificat. Elle sert à 
référencer cette clé publique dans d'autres certificats.  
CSM_145 Concernant les certificats de cartes et de dispositifs GNSS 
externes, la référence du titulaire de certificat relève du type 
de données
  comme précisé en 
appendice 1.  
CSM_146 Concernant les VU, le fabricant, lorsqu'il demande un certifi ­
cat, 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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 405  
Remarque:  pour un certificat de carte, la valeur du CHR est 
égale à la valeur de l’élément cardExtendedSerialNumber du 
fichier EF_ICC; voir appendice 2. Pour un certificat EGF, la 
valeur du CHR est égale à la valeur de l’élément sensor ­
GNSSSerialNumber du fichier EF_ICC; voir appendice 14. 
Pour un certificat VU, la valeur du CHR est égale à l’élé ­
ment vuSerialNumber de VuIdentification (voir l’appendice 
1), à moins que le fabricant ne connaisse pas le numéro de 
série propre au fabricant au moment où le certificat est 
demandé.  
▼B 
CSM_147 Concernant les certificats 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  
▼M1 
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.  
▼B 
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'adopter l'algorithme de 
signature ECDSA et le CSM_50 préconise d'utiliser l'algo ­
rithme de hachage associé à la taille de la clé des autorités 
de signature. La structure de la signature est en clair, confor ­
mément au [TR-03111].  
9.3.3  Certificats de demande  
CSM_151  ►M1 Lors de la demande d’un certificat, la MSCA adresse 
les données suivantes à l’ERCA: ◄ 
— 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.  
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érique national des organismes de certifica ­
tion (type de données
  défini à l'ap ­
pendice 1),  
— le code numérique national des organismes de certifica ­
tion (type de données
  défini à l'appen ­
dice 1),  
— le numéro de série sur un octet permettant de faire la 
distinction entre les différentes clés de l'organisme de 
certification si certaines clés font l'objet de modifica ­
tions,  
— le champ de deux octets contenant les informations 
complémentaires spécifiques à l'organisme de certifica ­
tion. ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 406  
CSM_153 Un fabricant d’équipement envoie les données suivantes 
dans une demande de certificat à une MSCA, ce qui lui 
permet de créer la référence du titulaire de certificat du 
nouvel équipement:  
— 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 fabrication 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 renvoyé par la MSCA est inséré dans l’équipement auquel il est 
destiné.  
▼B 
CSM_154 Concernant les VU, le fabriquant, 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. 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 identifie de manière distincte 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 insertion du certificat dans une VU donnée, le fabri ­
cant communique la connexion entre le numéro de série de 
la demande de certificat et l'identificateur de la VU à la 
MSCA.  
10. AUTHENTIFICATION MUTUELLE DE LA CARTE ET DE LA VU 
ET MESSAGERIE SÉCURISÉE  
10.1.  Généralités  
CSM_155 À haut niveau, la sécurité des communications échangées 
entre une VU et une carte tachygraphique 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'organisme de 
certification d'un État membre. En retour, le certificat de 
clé publique MSCA doit être signé par l'organisme de 
certification racine européen. Cette étape correspond à la 
vérification de la chaîne de certification et fait l'objet 
d'une spécification 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éatoire 
envoyé par la carte. La carte vérifie la signature par 
rapport au numéro aléatoire. Si cette vérification aboutit, 
la VU est authentifiée. Cette étape correspond à l'authen ­
tification de la VU et fait l'objet d'une spécification 
détaillée à la section 10.3.  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 407  
— Troisièmement, les deux parties calculent indépendam ­
ment deux clés de session AES à l'aide d'un algorithme 
de concordance de clé asymétrique. En utilisant l'une de 
ces clés de session, la carte crée un code d'authentifica ­
tion de message (MAC) 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écification détaillée à la section 10.4.  
— Quatrièmement, la VU et la carte utilisent les clés de 
session convenues pour assurer la confidentialité, l'inté ­
grité et l'authenticité de tous les messages échangés. 
Cette étape correspond à la messagerie sécurisée et fait 
l'objet d'une spécification détaillée à la section 10.5.  
CSM_156 Le mécanisme décrit 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érification 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  ►M1 Les VU adoptent le protocole prévu à la figure 4 
pour vérifier la chaîne de certificat d’une carte tachygra ­
phique. Pour chaque certificat lu à partir de la carte, la 
VU vérifie que le champ «Autorisation du titulaire de certi ­
ficat» (CHA) est correct:  
— Le champ CHA du certificat Card indique un certificat 
Card pour l’authentification mutuelle (voir l’appendice 1, 
type de données EquipmentType).  
— Le champ CHA du certificat Card.CA indique une 
MSCA.  
— Le champ CHA du certificat Card.Link indique une 
ERCA. ◄ 
Notes relatives à la Figure 4:  
— Les certificats et les clés publiques associés à la carte 
mentionnés sur cette Figure sont ceux de l'authentifica ­
tion mutuelle. La section 9.1.5 précise leur intitulé: 
Card_MA.  
— Les certificats Card.CA et les clés publiques mention ­
né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 euro ­
péenne.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 408  
— Le certificat Card.Link.EUR est le certificat racine euro ­
pé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'insertion 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 stockée pour la réutiliser à l'avenir. Si tel est le cas et 
que le certificat de la carte est toujours 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éussite, 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; 
— le certificat Card.CA.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 tachy ­
graphique, l'a vérifié et mémorisé 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émorise pour l'utiliser ultérieurement, de manière à ne 
pas devoir le vérifier à nouveau s'il lui est représenté. Au 
lieu de mémoriser la totalité du certificat, une VU peut 
choisir de ne mémoriser que le contenu du corps du certifi ­
cat, conformément à la section 9.3.2.  ►M1 Si l’enregistre ­
ment de tous les autres types de certificats est facultatif, la 
VU a l’obligation d’enregistrer les nouveaux certificats de 
lien présentés par une carte. ◄ 
CSM_160 La VU vérifie la validité temporelle de tout certificat lu 
depuis la carte ou mémorisé 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 interne.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 409  
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  ►M1 Les cartes tachygraphiques adoptent le protocole 
prévu à la figure 5 pour vérifier la chaîne de certificat 
d’une VU. Pour chaque certificat présenté par la VU, la 
carte vérifie que le champ de l’autorisation du titulaire de 
certificat (CHA) est correct:  
— Le champ CHA du certificat VU.Link indique l’ERCA.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 410  
— Le champ CHA du certificat VU.CA indique une 
MSCA.  
— Le champ CHA du certificat VU indique un certificat 
VU pour l’authentification mutuelle (voir l’appendice 1, 
type de données EquipmentType). ◄ 
Figure 5  
Protocole de vérification de la chaîne de certificat de la VU par la carte
  
Notes relatives à la Figure 5:  
— Les certificats 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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 411  
— Les certificats et les clés publiques VU.CA mentionnés sur cette 
figure sont ceux de la signature des certificats de la VU et du dispo ­
sitif GNSS externe. La section 9.1.3 précise leur intitulé: MSCA_VU- 
EGF.  
— Le certificat VU.CA.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_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 
tachygraphique. En cas de réussite, cela signifie que la carte 
a déjà vérifié la chaîne de certificat de la VU par le passé et 
a mémorisé le certificat de la VU pour l'utiliser ultérieure ­
ment. 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'identifier 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 tachygraphique. 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émorisé pour une utilisation ultérieure.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 412  
CSM_163 La VU utilise la commande MSE: Set AT pour définir sa 
clé publique et l'utiliser dans la carte tachygraphique. 
Comme spécifié dans l'appendice 2, cette commande 
contient une indication du mécanisme cryptographique qui 
servira avec la clé définie. Ce mécanisme correspond à 
l'authentification de la VU utilisant l'algorithme ECDSA, 
en combinaison avec l'algorithme de hachage 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 indi ­
cation 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'envoyer 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.SK  eph , VU.PK  eph , Card.DP). La VU utilise l'abs ­
cisse 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.PK  eph ). 
▼M1 
CSM_165 Si la commande MSE: Set AT aboutit, la carte définit le 
VU.PK indiqué pour une utilisation ultérieure pendant l’au ­
thentification de la VU et mémorise temporairement 
Comp(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émorise unique ­
ment le dernier Comp(VU.PKeph) reçu. La carte réinitialise 
Comp(VU.PKeph) après une commande GENERAL 
AUTHENTICATE réussie.  
▼B 
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 expi ­
rés. 
CSM_167 Pour vérifier la validité temporelle d'un certificat présenté 
par la VU, chaque carte tachygraphique stocke en interne 
des données représentant le temps actuel. Ces données ne 
sont pas directement 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 actua ­
lise 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 accepte unique ­
ment 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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 413  
Note:  la dernière exigence implique qu'une carte doit 
pouvoir 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émorise pour l'utiliser ultérieurement, de manière 
à ne pas devoir le vérifier à nouveau s'il lui est représenté. 
Au lieu de mémoriser la totalité du certificat, une carte peut 
choisir de ne mémoriser que le contenu du corps du certi ­
ficat, conformément à la section 9.3.2.  
10.3.  Authentification de VU  
CSM_169 Les unités embarquées sur véhicule et les cartes adoptent le 
protocole d'authentification de VU illustré sur la Figure 6 
pour authentifier la VU par rapport à la carte. L'authentifi ­
cation de la VU permet à la carte tachygraphique 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  ►M1 La VU inclut à proximité du défi de la carte, la 
signature de la référence du titulaire du certificat 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éala ­
blement vérifié la chaîne de certificat.  
CSM_171 La VU insère également dans la signature l'identificateur de 
la clé publique éphémère Comp(VU.PK  eph ) que la VU 
utilise pour définir la messagerie sécurisée pendant la procé ­
dure d'authentification de circuit, conformément aux spéci ­
fications de la section 10.4.  
Remarque:  cela garantit que la VU avec laquelle une carte 
communique pendant une session de messagerie sécurisée 
est la même VU que celle authentifiée par la carte.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 414  
Figure 6  
Protocole d’authentification de la VU
  
▼B 
CSM_172 Si la VU envoie plusieurs commandes GET CHALLENGE 
pendant son authentification, la carte renvoie un nouveau 
défi aléatoire sur 8 octets à chaque fois, mais mémorise 
uniquement le dernier.  
CSM_173 L'algorithme de signature utilisé par la VU pour authentifier 
la VU est l'ECDSA préconisé par les [DSS], en combi ­
naison avec l'algorithme de hachage associé à la taille de 
clé de la paire de clés VU_MA de la VU, conformément au 
CSM_50. La structure de la signature est en clair, confor ­
mément au [TR-03111]. La VU adresse la signature 
produite à la carte.  
▼M1 
CSM_174 À réception de la signature de la VU dans une commande 
EXTERNAL AUTHENTICATE, la carte:  
— calcule le jeton d’authentification en concaténant 
Card.CHR, le lanceur de défis de la carte rcard et l’iden ­
tificateur de la clé publique éphémère de la VU 
Comp(VU.PKeph);  
— vérifie la signature de la VU à l’aide de l’algorithme 
ECDSA, en utilisant l’algorithme de hachage associé à 
la taille de clé de la paire de clés VU_MA de la VU, 
conformément au CSM_50, combiné à la VU.PK et au 
jeton d’authentification calculé.  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 415  
10.4.  Authentification du circuit et concordance des clés de session  
CSM_175 Les unités embarquées sur véhicule et les cartes adoptent le 
protocole d'authentification de circuit illustré sur la  Figure 7  
pour authentifier la carte par rapport à la VU. L'authentifi ­
cation du circuit permet à l'unité embarquée sur véhicule de 
vérifier explicitement l'authenticité de la carte.  
Figure 7  
Authentification 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'authentification du circuit en 
adressant la commande MSE: Set AT indiquant 
«Authentification du circuit à l'aide de l'algorithme 
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, conformé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.  
▼M1 
2. La VU adresse le point public VU.PK  eph de sa paire de 
clés éphémères à la carte. Le point public est converti en 
chaîne d’octets comme le précise le [TR-03111]. On 
utilise la structure cryptée non compressée. Conformé ­
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’identificateur de la clé publique 
éphémère Comp(VU.PK  eph ) à la carte qui l’a mémorisé.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 416  
3. La carte calcule Comp(VU.PK  eph ) d'après VU.PK  eph et 
compare le résultat avec la valeur mémorisée de 
Comp(VU.PK  eph ). 
4. À l'aide de l'algorithme 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éatoire forgé pour l'occasion 
sur 8 octets N  PICC et l'utilise pour calculer les deux clés 
de session AES K  MAC et K  ENC d'après K. Cf. CSM_179.  
▼M1 
6. En utilisant K  MAC , la carte calcule un jeton d’authentifi ­
cation en fonction du point public éphémère de la VU: 
T PICC = CMAC(K  MAC , VU.PK  eph ). Le point public 
prend le format utilisé par la VU (voir le point 2 ci- 
dessus). La carte envoie N  PICC et T  PICC à l’unité embar ­
quée sur véhicule.  
▼B 
7. À l'aide de l'algorithme 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.  
8. La VU calcule les clés de session K  MAC et K  ENC d'après 
K et N  PICC ; cf. CSM_179  
9. La VU vérifie le jeton d'authentification T  PICC . 
CSM_177 À l'étape 3 ci-dessus, la carte calcule Comp(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'algorithme ECKA-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 modifications suivantes:  
— La valeur du compteur est de ‘00 00 00 01’ pour K  ENC 
et de ‘00 00 00 02’ pour K  MAC.  
— Le numéro à usage unique  r est utilisé et est égal à 
N PICC. 
— Pour calculer les clés AES 128 bits, l'algorithme de 
hachage à utiliser est SHA-256.  
— Pour calculer les clés AES 192 bits, l'algorithme de 
hachage à utiliser est SHA-384.  
— Pour calculer les clés AES 256 bits, l'algorithme de 
hachage à utiliser est SHA-512.  
La longueur des clés de session (c'est-à-dire la longueur à 
laquelle le hachage est tronqué) est liée à la taille de la paire 
de clés Card_MA, conformément au CSM_50.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 417  
CSM_180 Aux étapes 6 et 9 ci-dessus, la carte et l'unité embarquée sur 
véhicule utilisent l'algorithme AES en mode CMAC, 
conformément au [SP 800-38B]. La longueur de T  PICC est 
liée à la longueur des clés de session AES, conformément 
au CSM_50.  
10.5.  Messagerie sécurisée  
10.5.1  Généralités  
CSM_181 Toutes les commandes et réponses échangées entre une 
unité embarquée sur véhicule et une carte tachygraphique 
après authentification réussie du circuit et jusqu'à la fin de 
la session sont protégées par la messagerie sécurisée.  
CSM_182 Hormis la lecture d'un fichier avec les règles d'accès SM-R- 
ENC-MAC-G2 (cf. appendice 2, section 4), la messagerie 
sécurisée sert uniquement en mode d'authentification. Dans 
ce mode, un total de contrôle cryptographique (MAC) 
s'ajoute à toutes les commandes et réponses pour garantir 
l'authenticité et l'intégrité du message.  
CSM_183 Lors de la lecture de données provenant d'un fichier soumis 
aux règles d'accès SM-R-ENC-MAC-G2, la messagerie 
sécurisée est utilisée en mode chiffrer-puis-authentifier. 
Cela signifie que les données de réponse sont d'abord cryp ­
tées pour assurer la confidentialité du message, puis qu'un 
MAC est calculé par rapport aux données cryptées forma ­
tées pour garantir l'authenticité et l'intégrité.  
CSM_184 La messagerie sécurisée utilise AES comme défini en [AES] 
avec les clés de session K  MAC et K  ENC convenues pendant 
l'authentification du circuit.  
CSM_185 Un entier non signé sert de compteur de séquences à l'émis ­
sion (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 compteur de 
séquences d'envoi 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 messagerie sécurisé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épart 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.  
CSM_186 En ce qui concerne le cryptage des messages, K  ENC 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(K  ENC SSC), 
c'est-à-dire la valeur actuelle du compteur de séquences 
d'envoi cryptée avec K  ENC . 
CSM_187 En ce qui concerne l'authentification de message, K  MAC est 
utilisé avec AES en mode CMAC conformément au [SP 
800-38B]. La longueur de MAC est liée à la longueur des 
clés de session AES, conformément au CSM_50. Le 
compteur de séquence d'envoi est inclus dans le MAC en 
le préfixant avant le datagramme à authentifier.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 418  
10.5.2  Structure de message sécurisé  
CSM_188 La messagerie sécurisée n'utilise que des objets de données 
de messagerie sécurisé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 messagerie sécurisée  
Nom de l'objet de données  Balise  Présence Obligatoire (M), 
Conditionnelle (C) ou 
Interdite (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 remplissage 
par cryptogramme, 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 tachy ­
graphiques sont compatibles avec les commandes READ 
BINARY et UPDATE BINARY avec un octet impair INS 
(‘B1’ resp. ‘D7’). Ces variantes de commande sont néces ­
saires pour lire et actualiser des fichiers de 32 768 octets et 
davantage. 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 toute information 
complémentaire.  
CSM_189 Tous les objets de données de SM sont codés DER-TLV 
conformément à la norme [ISO 8825-1]. Ce cryptage 
produit la structure Tag-Length-Value (TLV) suivante:  
Balise: la balise est cryptée sur un ou deux octet(s) et 
indique le contenu.  
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'octets.  
Valeur: la valeur est cryptée sur zéro octet ou plus.  
CSM_190 Les APDU protégés par la messagerie sécurisée sont créés 
de la manière suivante:  
— L'entête de commande est inclus dans le calcul MAC, 
par conséquent la valeur ‘0C’ sert pour l'octet de classe 
CLA.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 419  
— Comme le précise l'appendice 2, tous les octets INS sont 
pairs, hormis éventuellement les octets INS impairs des 
commandes READ BINARY et UPDATE BINARY.  
— La valeur réelle de Lc est modifiée en Lc' après l'appli ­
cation de la messagerie sécurisée.  
— La zone de données se compose 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.  
▼M1 
CSM_191 Tout objet de données à chiffrer doit être complété confor ­
mément à la norme [ISO 7816-4] en utilisant l’indicateur 
«01» de contenu de remplissage. Concernant le calcul du 
MAC, les objets de données de l’APDU sont complétés 
conformément à la norme [ISO 7816-4].  
Remarque:  le remplissage destiné à la messagerie sécurisée 
est toujours affecté à la couche de messagerie sécurisée, 
jamais aux algorithmes CMAC ou CBC.  
Résumé et exemples  
Une commande APDU de la messagerie sécurisée appliquée respecte la 
structure suivante, selon le cas de chaque commande non sécurisée (DO 
correspond à l’objet de données):  
Cas 1: CLA INS P1 P2 || Lc’ || DO ‘8E’ || Le  
Cas 2: CLA INS P1 P2 || Lc’ || DO ‘97’ || DO‘8E’ || 
Le 
Cas 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 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 
courte ou étendue; cf. [ISO 7816-4].  
Une réponse APDU de la messagerie sécurisée appliquée respecte la 
structure suivante, selon le cas de chaque réponse non sécurisée:  
Cas 1 ou 3: DO ‘99’ || DO ‘8E’ || 
SW1SW2  
Cas 2 ou 4 (octet INS pair) sans cryptage: DO ‘81’ || DO ‘99’ || DO 
‘8E’ || SW1SW2  
Cas 2 ou no 4 (octet INS pair) avec cryptage: 
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 impair) avec cryptage ne servent 
jamais pour la communication entre une VU et une carte.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 420  
Ci-après suivent trois exemples de transformations 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 1 ou 3 et la figure 10 indique une 
réponse APDU cryptée et authentifiée relevant des cas 2 ou 4.  
Figure 8  
Transformation d’une commande APDU authentifiée relevant du cas 4
  
Figure 9  
Transformation d’une réponse APDU authentifiée relevant des cas 1 ou 3
  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 421  
Figure 10  
Transformation d’une réponse APDU cryptée et authentifiée relevant des cas 2 ou 4
  
▼B 
10.5.3  Abandon de la session de messagerie sécurisée  
CSM_192 Une unité embarquée sur véhicule abandonne une session de 
messagerie sécurisée en cours si et seulement si l'une des 
conditions suivantes survient:  
— elle reçoit une réponse APDU en clair,  
— elle détecte une erreur de messagerie sécurisée dans une 
réponse APDU:  
— un objet de données de messagerie sécurisé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 messagerie sécurisée est 
erroné, p. ex. la valeur MAC est erronée, la structure 
TLV est erronée ou l'indicateur de remplissage 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 
compte des exigences de sécurité du matériel utilisé, avec 
une valeur maximale de 240 commandes et réponses 
associées de SM par session.  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 422  
CSM_193 Une carte tachygraphique abandonne une session de messa ­
gerie sécurisée en cours si et seulement si l’une des condi ­
tions suivantes survient:  
— elle reçoit une réponse APDU en clair,  
— elle détecte une erreur de messagerie sécurisée dans une 
commande APDU:  
— un objet de données de messagerie sécurisé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 messagerie sécurisée est 
erroné, p. ex. la valeur MAC est erronée ou la struc ­
ture TLV est erronée.  
— l’alimentation est coupée ou la carte est réinitialisée,  
— la VU entame la procédure d’authentification 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 fabricant 
et tient compte des exigences de sécurité du matériel 
utilisé, avec une valeur maximale de 240 commandes 
et réponses associées de SM par session.  
▼B 
CSM_194 Concernant la gestion des erreurs de SM par une carte tachy ­
graphique:  
— si dans une commande APDU, certains objets de 
données de messagerie sécurisée attendus manquent, 
l'ordre des objets de données est erroné ou des objets 
de données inconnus sont présents, une carte tachygra ­
phique répond au moyen des octets d'état ‘69 87’.  
— si un objet de données de messagerie sécurisée dans une 
commande APDU est erroné, une carte tachygraphique 
répond au moyen des octets d'état ‘69 88’.  
Dans ce cas, les octets d'état sont renvoyés sans utiliser la 
SM. 
CSM_195 Si une session de Messagerie sécurisée entre une VU et une 
carte tachygraphique est abandonnée, la VU et la carte tachy ­
graphique:  
— détruisent de façon sécurisée les clés de sessions mémo ­
risées;  
— établissent immédiatement une nouvelle session de 
messagerie sécurisée, conformément aux dispositions 
des sections 10.2 à 10.5.  
CSM_196 Si pour une raison quelconque, la VU décide de redémarrer 
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 
certification de la carte, conformément aux dispositions de la 
section 10.2 et continue conformément aux dispositions des 
sections 10.2 à 10.5.  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 423  
11. COUPLAGE DE L'UV ET DU DISPOSITIF GNSS, AUTHENTIFICA ­
TION MUTUELLE ET MESSAGERIE 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 interne (c'est-à-dire intégré au boîtier de 
la VU et non extractible) ou externe (module indépendant). 
Dans le premier cas, il n'est pas nécessaire de normaliser la 
communication interne entre le dispositif GNSS et la VU. 
Les exigences 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 protection du présent chapitre s'appliquent 
donc.  
CSM_198 La sécurisation des communications échangées entre une 
unité embarquée sur véhicule et un dispositif GNSS 
externe passe par les mêmes exigences que la communica ­
tion sécurisée entre une unité embarquée sur véhicule et une 
carte tachygraphique. Le dispositif GNSS externe (EGF) 
joue le rôle de la carte tachygraphique. Toutes les exigences 
mentionnées au chapitre 10 pour les cartes tachygraphiques 
sont satisfaites par l'EGF et tiennent compte des écarts, clari ­
fications et ajouts mentionnés au présent chapitre. En parti ­
culier, la vérification de la chaîne de certification mutuelle, 
l'authentification de la VU et l'authentification du circuit sont 
menées conformément aux dispositions des sections 11.3et 
11.4.  
CSM_199 La communication entre une unité embarquée sur véhicule et 
un EGF se distingue de la communication entre une unité 
embarquée sur véhicule et une carte tachygraphique en cela 
qu'une unité embarquée sur véhicule et un EGF doivent être 
couplés une fois dans l'atelier avant que la VU et l'EGF 
puissent échanger des données basées GNSS en fonctionne ­
ment normal. Le processus de couplage fait l'objet d'une 
description détaillée à la section 11.2.  
CSM_200 Concernant 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 descrip ­
tion détaillée en appendice 2 de la présente Annexe.  
11.2.  couplage d'une VU et d'un dispositif externe 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 atelier 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étruit effica ­
cement le certificat EGF_MA existant mémorisé 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étruit efficacement le 
certificat VU_MA existant mémorisé et enregistre le certi ­
ficat VU_MA de la VU à laquelle il vient d'être couplé.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 424  
11.3.  Vérification mutuelle de la chaîne de certificat  
11.3.1  Généralités  
CSM_205 La vérification de la chaîne de certification mutuelle entre 
une VU et un EGF prend place uniquement durant le 
couplage d'une VU et d'un EGF par un atelier. 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émorisés pendant le couplage, après avoir 
vérifié leur validité dans le temps. La VU et l'EGF ne font 
confiance à aucun autre certificat pour protéger la commu ­
nication entre la VU et l'EGF en fonctionnement normal.  
11.3.2  Pendant le couplage VU — EGF  
CSM_206 Pendant le couplage à un EGF, une unité embarquée sur 
véhicule utilise le protocole décrit à 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 champ d'appli ­
cation du présent appendice. Cependant, un EGF n'est 
pas une carte intelligente. La VU n'enverra donc vrai ­
semblablement pas une Réinitialisation pour lancer la 
communication et ne recevra pas d'ATR.  
— Les certificats 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 signa ­
ture des certificats EGF. La section 9.1.3 précise leur 
intitulé: MSCA_VU-EGF.  
— 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 corres ­
pond 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.EUR est le certificat racine euro ­
pé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 tachygraphique, 
la VU sélectionne l'AID de l'EGF.  
— «Ignorer la carte» devient «Ignorer l'EGF».  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 425  
CSM_207 Une fois le certificat EGF_MA vérifié, l'unité embarquée sur 
véhicule mémorise ce certificat pour l'utiliser en fonctionne ­
ment normal; cf. section 11.3.3.  
CSM_208  ►M1 Pendant le couplage à une VU, un dispositif GNSS 
externe utilise le protocole décrit à la figure 5 (section 
10.2.2) pour vérifier la chaîne de certification 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 certificats et les clés publiques associés à la VU 
mentionnés sur cette Figure sont ceux de l'authentifica ­
tion mutuelle. La section 9.1.4 précise leur intitulé: 
VU_MA.  
— Les certificats 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.CA.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 euro ­
péenne.  
— Le certificat VU.Link.EUR est le certificat racine euro ­
péen indiqué dans le CAR du certificat VU.Link.  
CSM_209 À titre d'exception par rapport à l'exigence du CSM_167, un 
EGF utilise le temps GNSS pour vérifier la validité dans le 
temps de tout certificat présenté.  
▼M1 
CSM_210 Une fois le certificat VU_MA vérifié, le dispositif GNSS 
externe mémorise ce certificat pour l’utiliser en fonctionne ­
ment normal; cf. section 11.3.3.  
▼B 
11.3.3  Pendant le fonctionnement normal  
CSM_211  ►M1 En fonctionnement normal, une unité embarquée sur 
véhicule et un EGF respectent le protocole décrit sur la 
figure 11 pour vérifier la validité dans le temps du certificat 
EGF_MA mémorisé et pour définir la clé publique VU_MA 
en vue de l’authentification ultérieure de la VU. Aucune 
autre vérification mutuelle des chaînes de certificats n’a 
lieu en fonctionnement normal. ◄ 
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 intelligente, la VU n'enverra 
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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 426  
Figure 11  
Vérification mutuelle de la validité dans le temps du certificat en fonctionnement normal 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érieure au moyen de la 
messagerie sécurisée se déroulent normalement.  
11.4.  Authentification de la VU, Authentification du circuit et concordance 
des clés de session  
CSM_213 L'authentification de la VU, l'authentification 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 messa ­
gerie sécurisée est réétablie en fonctionnement normal. La 
VU et l'EGF exécutent les procédures décrites aux sections 
10.3 et 10.4. Toutes les exigences prévues dans ces sections 
s'appliquent.  
11.5.  Messagerie sécurisé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'authentification réussie du circuit et jusqu'à la fin de la 
session sont protégées par la messagerie sécurisée en mode 
authentification uniquement. Toutes les exigences prévues 
dans la section 10.5 s'appliquent.  
CSM_215 Si une session de messagerie sécurisée entre une VU et un 
EGF est abandonnée, la VU établit immédiatement une 
nouvelle session de messagerie sécurisée, comme le 
prévoient les sections 11.3.3 et 11.4.  
12. COUPLAGE ET COMMUNICATION 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 capteur de mouve ­
ment communiquent à l'aide du protocole d'interface prévu 
par la norme [ISO 16844-3] pendant le couplage et le fonc ­
tionnement normal. Cela inclut les changements prévus au 
présent chapitre et à la section 9.2.1.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 427  
Note:  les lecteurs de la présente section sont censés maîtriser 
le contenu de la norme [ISO 16844-3].  
12.2.  Couplage de la VU et du capteur de mouvement à l'aide de généra ­
tions de clés différentes  
Comme expliqué à la section 9.2.1, la clé maîtresse du capteur de 
mouvement et toutes les clés associées sont régulièrement remplacées. 
Cela entraîne la présence de trois clés AES K  M-WC  liées au capteur de 
mouvement, au maximum, (de générations de clés consécutives) sur les 
cartes d'atelier. De même, un maximum de trois différents cryptages de 
données de type AES (sur la base de générations consécutives de clé 
maîtresse K  M du capteur de mouvement) peuvent être présents sur les 
capteurs de mouvement. Une unité embarquée sur véhicule contient une 
seule clé K  M-VU  associée au capteur de mouvement.  
CSM_217 Une VU et un capteur de mouvement de deuxième généra ­
tion sont couplés comme suit (comparer au tableau 6 de la 
norme [ISO 16844-3]):  
1. Une carte d'atelier de deuxième génération est insérée 
dans la VU et cette dernière est raccordée au capteur de 
mouvement.  
2. La VU lit toutes les clés K  M-WC  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 
K M-VU  . Si la clé K  M-WC  correspondante est absente de la 
carte d'atelier, la VU abandonne la procédure de couplage 
et affiche le message d'erreur approprié pour le titulaire 
de la carte d'atelier.  
3. La VU calcule la clé maîtresse du capteur de mouvement 
K M à partir de K  M-VU  et de K  M-WC,  et calcule la clé 
d'identification K  ID à partir de K  M , comme le prévoit la 
section 9.2.1.  
4. La VU envoie les instructions pour lancer la procédure de 
couplage par rapport au capteur de mouvement, comme le 
prévoit la norme [ISO 16844-3] et chiffre le numéro de 
série reçu du capteur de mouvement avec la clé d'identi ­
fication K  ID. génération. En retour, la VU envoie le 
numéro de série crypté au capteur de mouvement.  
5. Le capteur 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 interne. S'il identifie une 
correspondance, la VU est authentifiée. Le capteur de 
mouvement prend note de la génération de K  ID qu'utilise 
la VU et renvoie 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 K  M . 
6. La VU déchiffre la clé de couplage à l'aide de K  M , génère 
une clé de session K  S, , la chiffre à l'aide d'une clé de 
couplage et envoie le résultat au capteur de mouvement. 
Le capteur de mouvement déchiffre K  S . 
7. La VU assemble les informations de couplage comme le 
prévoit la norme [ISO 16844-3], chiffre les informations à 
l'aide de la clé de couplage et envoie le résultat au capteur 
de mouvement. Le capteur de mouvement déchiffre les 
informations de couplage.  
8. Le capteur de mouvement chiffre les informations rela ­
tives au couplage reçues à l'aide de la K  S reçue et les 
renvoie à la VU. La VU vérifie que les informations de 
couplage sont identiques à celles qu'elle a adressées au 
capteur de mouvement à l'étape précédente. Dans l'affir ­
mative, cela prouve que le capteur de mouvement utilise  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 428  
la même K  S que la VU. Par conséquent, à l'étape 5, il 
adresse sa clé de couplage cryptée avec la bonne généra ­
tion de K  M . Le capteur de mouvement est ainsi authenti ­
fié. 
Note:  les étapes 2 et 5 divergent de la procédure normalisée 
[ISO 16844-3]; les autres étapes restent standard.  
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 capteur 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:  
— N  s [1]: son numéro de série crypté avec K  ID de géné­
ration 1,  
— N  s [2]: son numéro de série crypté avec K  ID de géné­
ration 2,  
— N  s [3]: son numéro de série crypté avec K  ID de géné­
ration 3,  
— K  P [1]: sa clé de couplage (  1 ) de génération 1, cryptée 
avec K  M de génération 1,  
— K  P [2]: sa clé de couplage de génération 2, cryptée 
avec K  M de génération 2,  
— K  P [3]: sa clé de couplage de génération 3, cryptée 
avec K  M 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é K  M-WC  . 
— Imaginons que la VU est de génération 2 et contient K  M- 
VU de génération 2.  
Dans ce cas, voici le déroulement des étapes 2 à 5:  
— Étape 2: la VU lit la K  M-WC  de génération 2 et de géné ­
ration 3 depuis la carte d'atelier et inspecte leur numéro 
de version.  
— Étape 3: la VU combine la K  M-WC  de génération 2 avec 
sa K  M-VU  afin de calculer K  M et K  ID. 
— Étape 4: la VU chiffre le numéro de série reçu du capteur 
de mouvement avec K  ID. 
— Étape 5: le capteur de mouvement compare les données 
reçues avec N  s [1] sans trouver de correspondance. Il 
compare ensuite les données avec N  s [2] et identifie une 
correspondance. Il conclut que la VU est de génération 2 
et renvoie donc la K  P [2]. ▼B 
( 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érentes, comme le prévoit le CSM_117.
 02016R0799 — FR — 26.02.2020 — 002.001 — 429  
12.3.  couplage et communication de la VU et du capteur de mouvement en 
utilisant AES  
CSM_218 Comme le précise le Tableau 3 de la section 9.2.1, toutes les 
clés impliquées dans le couplage d'une VU et d'un capteur 
de mouvement de deuxième génération et dans leur commu ­
nication 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 message crypté doit être un 
multiple de 16 octets, comparé aux 8 octets des clés 
TDES. Par ailleurs, certains de ces messages servent au 
transport des clés AES, dont la longueur peut être de 
128, 192 ou 256 bits. Par conséquent, le nombre d'octets 
de données par instruction figurant dans le tableau 5 de la 
norme [ISO 16844-3] peuvent évoluer vers celui figurant au 
Tableau 6.  
▼M1 
Tableau 6  
Nombre d’octets de données cryptées et en clair par instruction comme le prévoit la norme [ISO 16844-3]  
Instruction  Demande/ 
Réponse  Description 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 (en bits) de  
128 192  256  
10 demande  Données d’authentifi ­
cation + numéro de 
fichier  8 8  16  16  16  
11 réponse  Données d’authentifi ­
cation + contenu de 
fichier  16 bits ou 32 bits 
selon le fichier  16 bits ou 32 bits 
selon le fichier  32 / 48  32 / 48  32 / 48  
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 
couplage  24 24  32  32  32  
50 réponse  Informations de 
couplage  24 24  32  32  32  
70 demande  Données d’authentifi ­
cation  8 8  16  16  16  
80 réponse  Valeur du compteur 
MoS + données d’au ­
then.  8 8  16  16  16  
▼B 
CSM_219 Les informations relatives au couplage envoyées dans les 
instructions 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'algo ­
rithme AES au lieu de l'algorithme TDES dans la procédure 
de cryptage des données de couplage. Cela entraine donc 
deux cryptages AES et l'adoption du remplissage 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 K  P est de 16 octets: 
K' p = K  P XOR (N  s ||N s ) ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 430  
— Dans le cas où la clé de couplage K  P est de 24 octets: 
K' p = K  P XOR (N  s ||N s ||N s ) 
— Dans le cas où la clé de couplage K  P est de 32 octets: 
K' p = K  P XOR (N  s ||N s ||N s ||N s ) 
où N  s correspond au numéro de série sur 8 octets du capteur 
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 remplissage 
n o 2 définie par la norme [ISO 9797-1] est utilisée.  
Note:  la norme [ISO 16844-3] prévoit un nombre d'octets de 
données en clair multiples de 8 de sorte que le remplissage 
n'est pas nécessaire lorsque des clés TDES sont utilisées. Le 
présent appendice ne modifie pas la définition des données et 
des messages prévue par la norme [ISO 16844-3]. Il reste 
donc nécessaire de procéder au remplissage.  
CSM_221 Concernant l'instruction 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'entrela ­
cement  m = 1. L'IV à utiliser est:  
— Concernant l'instruction 11: le bloc d'authentification sur 
8 octets spécifié à la section 7.6.3.3. de la norme (ISO 
16844-3], complété selon la méthode de remplissage n  o 2 
définie par la norme [ISO 9797-2]; cf. sections 7.6.5. et 
7.6.6. de la norme [ISO 16844-3].  
— Concernant toutes les autres instructions 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 insertion dans l'instruction 11, le bloc d'au ­
thentification 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 mouvement pour des équipe ­
ments de générations différentes  
CSM_222 Comme l'explique la section 9.2.1, un capteur de mouvement 
de deuxième génération contient le cryptage TDES des 
données de couplage (comme le définit la partie A du 
présent appendice), qui permet de coupler le capteur de 
mouvement avec une VU de première génération. Dans ce 
cas, une VU de première génération et un capteur de mouve ­
ment de deuxième génération sont couplés comme le 
prévoient la partie A du présent appendice et la norme 
[ISO 16844-3]. Concernant la procédure de couplage, une 
carte d'atelier de première ou de deuxième génération peut 
être utilisée indifféremment.  
Remarques:  
— Il n'est pas possible de coupler une VU de deuxième 
génération avec un capteur de mouvement de première 
génération.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 431  
— 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 capteur de mouvement.  
13. SÉCURITÉ DES COMMUNICATIONS DISTANTES UTILISANT 
DSRC  
13.1.  Généralités  
Comme le prévoit l'appendice 14, une VU génère régulièrement des 
données de surveillance du tachygraphe à distance (RTM) qu'elle 
envoie au dispositif (interne ou externe) de communication à distance 
(RCF). Le dispositif de communication à distance est responsable de 
l'envoi de ces données vers l'interrogateur distant via l'interface DSRC 
décrite à l'appendice 14. L'appendice 1 spécifie que les données RTM 
résultent de la concaténation de:  
Données utiles cryptées du tachygraphe  le cryptage des données utiles 
en clair du tachygraphe  
Données de sécurité DSRC  décrites ci-dessous  
Les appendices 1 et 14 spécifient la structure des données utiles en clair 
du tachygraphe. La présente section décrit la structure des données de 
sécurité DSRC; les spécifications formelles figurent dans l'appendice 1.  
CSM_223 Les données en clair
  communi ­
quées par une VU à un dispositif de communication à 
distance (si le RCF est externe à la VU) ou par une VU à 
l'interrogateur distant au moyen de l'interface DSRC (si le 
RCF est interne à la VU) sont protégées en mode chiffrer- 
puis-authentifier. Cela signifie que les données utiles du 
tachygraphe sont d'abord cryptées pour protéger la confiden ­
tialité 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écurité DSRC 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 compteur sur trois octets, cf.CSM_225.  
▼M1 
Numéro de série de la VU  le numéro de série de la VU ou l’ID de la 
demande de certificat (type de données 
VuSerialNumber ou CertificateRequestID) - 
voir le paragraphe CSM_123.  
▼B 
Numéro de version de la clé maîtresse DSRC  le numéro de version sur un octet de la clé 
maîtresse DSRC de laquelle découlent les 
clés DSRC propres à la VU; cf. section 
9.2.2.  
MAC  le MAC calculé en fonction de tous les octets 
précédents dans les données RTM.  
CSM_225 Le compteur sur trois octets dans les données relatives à la 
sécurité DSRC respecte la structure MSB-first. 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 compteur à 
zéro. La VU incrémente le compteur d'une unité avant 
chaque nouveau calcul du jeu de données RTM suivant.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 432  
13.2.  Cryptage des données utiles du tachygraphe et génération du MAC  
CSM_226 En partant d'un élément de données en clair de type
  
tel que décrit à l'appendice 14, 
une VU chiffre ces données comme illustré à la Figure 12: 
la clé DSRC de la VU pour codage K_VU  DSRC  _ENC (cf. 
section 9.2.2) avec AES, en mode d'exploitation par chaî ­
nage de cryptage par blocs (CBC), tel que défini par la 
norme [ISO 10116], selon un paramètre d'entrelacement 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 remplissage à l'aide de la méthode n  o 2 définie 
par la norme [ISO 9797-1] . 
CSM_227 Une VU calcule le MAC dans les données de sécurité DSRC 
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 DSRC incluse, y compris les 
balises et les longueurs des objets de données. La VU 
utilise sa clé DSRC d'authentification K_VU  DSRC  _MAC 
(cf. section 9.2.2) avec l'algorithme AES en mode CMAC 
comme spécifié au [SP 800-38B]. La longueur de MAC est 
liée à la longueur des clés de DSRC propres à la VU, 
conformément au CSM_50.  
Figure 12  
cryptage des données utiles du tachygraphe et génération du MAC
  
13.3.  Vérification et décryptage de la charge du tachygraphe  
CSM_228 Lorsqu'un interrogateur reçoit les données RTM d'une VU, il 
envoie la totalité des données RTM à une carte de contrôle 
dans le champ de données d'une commande PROCESS 
DSRC MESSAGE, conformément à l'appendice 2. Puis:  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 433  
1. la carte de contrôle inspecte le numéro de version de la 
clé maîtresse DSRC dans les données relatives à la sécu ­
rité DSRC. Si la carte de contrôle ne connaît pas la clé 
maîtresse DSRC indiquée, elle envoie une erreur confor ­
mément à l'appendice 2 et abandonne la procédure.  
▼M1 
2. La carte de contrôle utilise la clé maîtresse DSRC indi ­
quée en combinaison avec le numéro de série de la VU 
ou l’ID de la demande de certificat dans les données 
relatives à la sécurité DSRC pour calculer les clés 
DSRC propres à la VU K_VU  DSRC  _ENC et 
K_VU  DSRC  _MAC, comme le précise le CSM_124.  
▼B 
3. la carte de contrôle utilise K_VU  DSRC  _MAC pour vérifier 
le MAC dans les données relatives à la sécurité DSRC, 
conformément au CSM_227. Si le MAC est erroné, la 
carte de contrôle envoie une erreur conformément à l'ap ­
pendice 2 et abandonne la procédure.  
4. la carte de contrôle utilise K_VU  DSRC  _ENC pour 
décrypter les données utiles cryptées du tachygraphe, 
comme le précise CSM_226. La carte de contrôle 
supprime le remplissage et envoie les données utiles du 
tachygraphe décryptées à l'interrogateur distant.  
CSM_229 Pour éviter les attaques par relecture, l'interrogateur 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écurité 
DSRC ne diffère pas trop de ses propres date et heure 
actuelles.  
Remarques:  
— Cela impose à l'interrogateur distant de disposer d'une 
source horaire exacte et fiable.  
— L'appendice 14 exigeant qu'une VU calcule un nouveau 
jeu de données RTM toutes les 60 secondes, d'une part et 
l'horloge de la VU intégrant une marge d'erreur autorisée 
d'une minute par rapport à l'heure exacte, d'autre part, la 
limite basse de récence des données RTM est fixée à 
deux minutes. La récence exigée varie également selon 
le degré de précision de l'horloge de l'interrogateur 
distant.  
CSM_230 Lorsqu'un atelier vérifie le fonctionnement correct de la 
fonctionnalité DSRC 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 DSRC 
MESSAGE, conformément à l'appendice 2. La carte d'atelier 
effectue tous les contrôles et toutes les actions spécifiés au 
CSM_228.  
14. SIGNATURE DES TÉLÉCHARGEMENT DE DONNÉES ET 
CONTRÔLE DES SIGNATURES  
14.1.  Généralités  
CSM_231 L'équipement spécialisé intelligent (IDE) enregistre les 
données reçues d'une VU ou d'une carte donnée pendant 
une session de téléchargement au sein d'un fichier de 
données physiques. Les données peuvent être mémorisées 
sur un support de stockage externe. Ce fichier contient les 
signatures numériques en fonction des blocs de données, 
comme le spécifie l'appendice 7. Ce fichier contient égale ­
ment les certificats suivants (cf. section 9.1):  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 434  
— en cas de téléchargement depuis une VU:  
— le certificat VU_Sign;  
— le certificat MSCA_VU-EGF comprenant la clé 
publique à utiliser pour vérifier le certificat VU_Sign.  
— en cas de téléchargement depuis une carte:  
— le certificat Card_Sign;  
— le certificat MSCA_Card comprenant 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édiatement, le cas échéant.  
— S'il vérifie la signature: tous les certificats racines euro ­
pé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'algorithme de signature pour créer des signatures numé ­
riques en fonction des données téléchargées doit être de type 
ECDSA conformément aux règles [DSS], en ayant recours à 
l'algorithme de hachage associé à la taille de clé de la VU ou 
de la carte, conformément au CSM_50. La structure de la 
signature est en clair, conformément au [TR-03111].  
14.3.  Vérification de signatures  
CSM_234  ►M1 Un IDE peut procéder à la vérification d’une signa ­
ture par rapport aux données téléchargées 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. Pour vérifier la validité tempo ­
relle d’un certificat présenté par l’IDE, la carte de contrôle 
utilise son heure interne actuelle, comme indiqué au 
CSM_167. La carte de contrôle actualise son heure actuelle 
si la Date effective d’un certificat authentique représentant 
une «source d’heure valide» est plus récente que l’heure 
actuelle de la carte. La carte accepte uniquement les certifi ­
cats 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 VU_Sign ou Card_Sign de deuxième généra ­
tion émis par le même pays que le certificat de carte de 
ladite carte de contrôle.  
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 certificats dans 
la chaîne de certificats contenue dans le fichier de données 
ainsi que la signature par rapport aux données conformément 
à la procédure relative aux signatures définie par les [DSS]. 
Dans les deux cas, pour chaque certificat lu depuis le fichier 
de données, il est nécessaire de vérifier que le champ «Auto ­
risation du titulaire de certificat» (CHA) est correct:  
— Le champ CHA du certificat EQT indique un certificat 
de la VU ou de la carte (le cas échéant) à signer (voir 
l’appendice 1, type de données EquipmentType).  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 435  
— Le champ CHA du certificat EQT.CA indique une 
MSCA.  
— Le champ CHA du certificat EQT.Link indique une 
ERCA. ◄ 
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 certi ­
ficats 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 euro ­
pé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 hachage envoyé à la carte de contrôle 
dans la commande PSO:hash, l'IDE utilise l'algorithme de 
hachage associé à la taille de la clé de la VU ou de la 
carte depuis laquelle les données sont téléchargées, confor ­
mé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éfinies par les règles 
[DSS].  
Remarque:  le présent document ne spécifie aucune action à 
entreprendre s'il est impossible de vérifier une signature 
associée à un fichier de données téléchargé ou si cette véri ­
fication échoue.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 436  
Figure 13  
Protocole de vérification de la signature associée à un fichier de données téléchargé
  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 437  
Appendice 12  
POSITIONNEMENT BASÉ SUR UN SYSTÈME MONDIAL DE 
NAVIGATION PAR SATELLITE (GNSS)  
TABLE DES MATIÈRES  
1. INTRODUCTION  
1.1. Champ d'application  
1.2. Abréviations et notations  
2. SPÉCIFICATIONS DU RÉCEPTEUR GNSS  
3. PHRASES NMEA  
4. UNITÉ EMBARQUÉE SUR LE VÉHICULE AVEC UN DISPOSITIF 
GNSS EXTERNE  
4.1. Configuration  
4.1.1 Principaux composants et principales interfaces  
4.1.2 État du dispositif GNSS externe à la fin de la production  
4.2. Communication entre le dispositif GNSS externe et l'unité embarquée sur 
le véhicule  
4.2.1 Protocole de communication  
4.2.2 Transfert sécurisé de données GNSS  
4.2.3 Structure de la commande Read Record  
4.3. Appariement, authentification mutuelle et concordance de clés de session 
du dispositif GNSS externe avec la VU  
4.4. Traitement des erreurs  
4.4.1 Erreur de communication avec le dispositif GNSS externe  
4.4.2 Atteinte à l'intégrité physique du dispositif GNSS externe  
4.4.3 Absence d'informations de positionnement en provenance du récepteur 
GNSS  
4.4.4 Expiration du certificat du dispositif GNSS externe  
5. UNITÉ EMBARQUÉE SUR LE VÉHICULE SANS DISPOSITIF GNSS 
EXTERNE  
5.1. Configuration  
5.2. Traitement des erreurs  
5.2.1 Absence d'informations de positionnement en provenance du récepteur 
GNSS  
6. CONFLIT TEMPOREL GNSS  
7. CONFLIT CONCERNANT LE MOUVEMENT DU VÉHICULE  
1. INTRODUCTION  
Le présent appendice présente les exigences techniques associées aux 
données GNSS qu'utilise l'unité embarquée sur le véhicule, y compris 
les protocoles à appliquer pour garantir la sécurité et l'exactitude du 
transfert de données des informations relatives au positionnement.  
Les principaux articles du règlement (UE) n  o 165/2014 dont découlent 
les présentes exigences sont les suivants: «Article 8 Enregistrement de la 
position du véhicule à certains points de la période de travail journa ­
lière», «Article 10 Interface avec les systèmes de transport intelligents» et 
«Article 11 Dispositions détaillées relatives au tachygraphe intelligent».  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 438  
1.1. Champ d'application  
GNS_1 L'unité embarquée sur le véhicule recueille les données de loca ­
lisation d'au moins un GNSS afin de prendre en charge l'appli ­
cation de l'article 8.  
L'unité embarquée sur le véhicule peut disposer ou non d'un dispositif 
GNSS externe, comme illustré à la figure 1:  
Figure 1  
Différentes configurations 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  
EGNOS Système européen de navigation par recouvrement géostation ­
naire  
GNSS Global navigation satellite system (système mondial de radio ­
navigation par satellite)  
GSA DOP du GPS et satellites actifs  
HDOP Affaiblissement de la précision horizontale  
ICD Document de contrôle des interfaces  
NMEA National Marine Electronics Association  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 439  
PDOP Affaiblissement de la précision de position  
RMC Minimum spécifique recommandé  
SIS Signal dans l'espace  
VDOP Affaiblissement de la précision verticale  
VU Unité embarquée sur le véhicule  
2. SPÉCIFICATIONS DU RÉCEPTEUR GNSS  
Indépendamment de la configuration du tachygraphe intelligent, avec ou 
sans dispositif GNSS externe, la délivrance d'informations de position ­
nement précises et fiables constitue un critère fondamental du fonction ­
nement efficace du tachygraphe intelligent. Il convient donc d'exiger sa 
compatibilité avec les services fournis par le programme Galileo et le 
programme EGNOS (European Geostationary Navigation Overlay 
Service) tels qu'ils sont définis par le règlement (UE) n  o 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 radionavigation par satel ­
lite indépendant et celui établi en vertu du programme EGNOS est un 
système régional de radionavigation par satellite destiné à améliorer la 
qualité du signal du système de positionnement mondial (GPS).  
GNS_2 Les constructeurs veillent à ce que les récepteurs GNSS des 
tachygraphes intelligents soient compatibles 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 compatibilité avec d'autres systèmes de navigation 
par satellite.  
▼C3 
GNS_3 Le récepteur GNSS prend en charge l'authentification sur le 
service ouvert Galileo lorsque ledit service est fourni par le 
système Galileo et pris en charge par les fabricants de récep ­
teurs GNSS. Toutefois, pour les tachygraphes intelligents mis 
sur le marché avant que les conditions précédentes ne soient 
remplies et qui ne prennent pas en charge l'authentification du 
service ouvert Galileo, aucune mise en conformité rétroactive 
ne sera exigée.  
▼B 
3. PHRASES NMEA  
La présente section décrit les phrases NMEA utilisées pendant le fonc ­
tionnement du tachygraphe intelligent. Cette section est applicable à la 
configuration du tachygraphe intelligent avec et sans dispositif GNSS 
externe.  
GNS_4 Les données de localisation reposent sur les données GNSS du 
minimum spécifique 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):  ▼B 
( 1 ) Règlement (UE) n  o 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 radionavi ­
gation par satellite et abrogeant le règlement (CE) du Conseil n  o 876/2002 et le règle ­
ment (CE) n  o 683/2008 du Parlement européen et du Conseil (OJ L 347, 20.12.2013, 
p. 1).
 02016R0799 — FR — 26.02.2020 — 002.001 — 440  
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.  
▼M1 
La résolution de la position repose sur la structure de la phrase RMC 
décrite ci-dessus. La première partie des champs 3) et 5) correspondent 
aux degrés. Le reste correspond aux minutes 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émorise dans la base de 
données de la VU les informations relatives au positionnement 
en termes de latitude et de longitude selon une résolution 
d’1/10 minute ou 1/600 degré, comme le décrit 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’exac ­
titude du signal. En particulier, HDOP sert à fournir une indi ­
cation sur le degré d’exactitude des données de localisation 
enregistrées (cf. 4.2.2). La VU enregistre la valeur du coeffi ­
cient d’affaiblissement de la précision de positionnement hori ­
zontal (HDOP) calculée comme étant la minimale des valeurs 
HDOP recueillies sur les systèmes GNSS disponibles.  
L’identificateur du système GNSS indique l’identifiant NMEA 
correspondant pour chaque constellation GNSS et pour le 
SBAS (Satellite-Based Augmentation System).  
Figure 3  
Structure de la phrase GSA
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 441  
GNS_6 La phrase GSA est mémorisée avec le numéro d’enregistre ­
ment «02» à «06».  
▼B 
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. Configuration  
4.1.1  Principaux composants et principales interfaces  
Dans cette configuration, le récepteur GNSS fait partie du dispositif 
GNSS externe.  
GNS_8 Le dispositif GNSS externe doit être alimenté par une interface 
de véhicule spécifique.  
GNS_9 Le dispositif GNSS externe se compose des éléments suivants 
(cf. figure 4):  
a) Un récepteur GNSS commercial pour fournir les données 
de positionnement à l'aide de l'interface de données GNSS. 
Par exemple, l'interface de données GNSS peut être la 
norme NMEA V4.10 selon laquelle le récepteur GNSS 
tient le rôle de l'émetteur et transmet les phrases NMEA 
à l'émetteur-récepteur sécurisé 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 externe.  
b) Une unité d'émetteur-récepteur (émetteur-récepteur sécurisé 
GNSS) compatible 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 charge l'interface de données 
GNSS s'adressant au récepteur GNSS. L'unité est dotée 
d'une mémoire qui enregistre les données relatives à l'iden ­
tification du récepteur GNSS et du dispositif GNSS 
externe.  
c) Un système clos doté d'une fonction de détection des 
fraudes qui intègre le récepteur GNSS et l'émetteur-récep ­
teur sécurisé GNSS. La fonction de détection des fraudes 
met en pratique les mesures de protection de la sécurité 
comme le définit le profil de protection du tachygraphe 
intelligent.  
d) Une antenne GNSS installée sur le véhicule et connectée 
au récepteur GNSS à l'aide du système clos.  
GNS_10 Le dispositif GNSS externe dispose au minimum des inter ­
faces externes suivantes:  
a) l'interface avec l'antenne GNSS installée sur le véhicule, 
dans le cas où l'on utilise une antenne externe;  
b) l'interface avec l'unité embarquée sur le véhicule.  
GNS_11 Dans la VU, l'émetteur-récepteur sécurisé de la VU constitue 
l'autre extrémité de la communication sécurisée avec l'émet ­
teur-récepteur sécurisé GNSS. Il respecte la norme 
ISO/IEC 7816-4:2013 relative à la connexion au dispositif 
GNSS externe.  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 442  
GNS_12 Pour la couche de communication avec le dispositif GNSS 
externe, la VU respecte la norme ISO/IEC 7816-12:2005 ou 
toute autre norme compatible avec la norme ISO/IEC 7816- 
4:2013. (cf. 4.2.1).  
4.1.2  État du dispositif GNSS externe à la fin de la production  
GNS_13 Le dispositif GNSS externe mémorise les valeurs suivantes 
dans la mémoire non volatile de l'émetteur-récepteur sécurisé 
GNSS lorsqu'il quitte l'usine:  
— la paire de clé EGF_MA et son certificat,  
— le certificat MSCA_VU-EGF comprenant la clé publique 
MSCA_VU-EGF.PK à utiliser pour vérifier le certificat 
EGF_MA,  
— 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 direc ­
tement 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'identificateur du système d'exploitation du dispositif 
GNSS,  
— le numéro d'homologation du dispositif GNSS externe;  
— l'identificateur du composant de sécurité du dispositif 
GNSS externe.  
4.2. Communication entre le dispositif GNSS externe et l'unité embar ­
quée sur le véhicule  
4.2.1  Protocole de communication  
GNS_14 Le protocole de communication entre le dispositif GNSS 
externe et l'unité embarquée sur le véhicule remplit trois fonc ­
tions:  
1. la collecte et la distribution des données GNSS (p. ex. la 
position, l'heure et la vitesse),  
2. la collecte des données de configuration du dispositif 
GNSS externe,  
3. le protocole de gestion à l'appui de l'appariement, de l'au ­
thentification mutuelle et de la concordance de clés de 
session entre le dispositif GNSS externe et la VU.  
GNS_15 Le protocole de communication repose sur la norme 
ISO/IEC 7816-4:2013 où l'émetteur-récepteur sécurisé de la 
VU tient le rôle du maître et l'émetteur-récepteur sécurisé du 
GNSS, le rôle de l'esclave. La connexion physique entre le 
dispositif GNSS externe et la VU repose sur la norme 
ISO/IEC 7816-12:2005 ou toute autre norme compatible 
avec la norme ISO/IEC 7816-4:2013  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 443  
GNS_16 Le protocole de communication ne doit pas prendre en charge 
les zones de longueur étendue.  
▼B 
GNS_17 Le protocole de communication de la norme ISO 7816 
(*-4:2013 et *-12:2005) entre le dispositif GNSS externe et 
la VU est fixé à T = 1.  
▼M1 
GNS_18 Concernant les fonctions 1) de collecte et de diffusion des 
données GNSS, 2) de collecte des données de configuration 
du dispositif GNSS externe et 3) du protocole de gestion, 
l’émetteur-récepteur sécurisé GNSS simule une carte intelli ­
gente dont l’architecture du système de fichiers comprend un 
fichier maître (MF), un fichier spécialisé (DF) doté de l’iden ­
tificateur 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’identificateur de fichier correspond à «2F2F» comme le 
prévoit le tableau 1.  
▼B 
GNS_19 L'émetteur-récepteur sécurisé GNSS mémorise les données 
provenant du récepteur GNSS et la configuration dans le 
fichier EF.EGF. Il s'agit d'un fichier d'enregistrement d'une 
longueur variable et linéaire dont l'identificateur correspond 
à ‘2F2F’ au format hexadécimal.  
▼M1 
GNS_20 L’émetteur-récepteur sécurisé GNSS doit utiliser une mémoire 
pour enregistrer les données et pouvoir effectuer au moins 
20 millions de cycles d’écriture et de lecture. Hormis cet 
aspect, la conception interne et la mise en œuvre de l’émet ­
teur-récepteur sécurisé GNSS incombent aux fabricants.  
Le tableau 1 fournit la modélisation des numéros d’enregis ­
trement et des données. Remarque: il existe cinq phrases GSA 
correspondant aux constellations GNSS et au SBAS (Satellite- 
Based Augmentation System).  
▼B 
GNS_21 Le tableau 1 présente la structure de fichier. Concernant les 
règles d'accès (ALW, NEV, SM-MAC), cf. appendice 2, 
chapitre 3.5.  
Tableau 1  
Structure de fichier  
▼C2 
Conditions d'accès  
Fichier  ID de fichier  Lire  Actualiser  Codé  
MF 3F00  
EF.ICC  0002  ALW  NEV 
(par la VU)  Non 
DF GNSS Facility  0501  ALW  NEV  Non  
EF EGF_MACertificate  C100  ALW  NEV  Non  
EF CA_Certificate  C108  ALW  NEV  Non  
EF Link_Certificate  C109  ALW  NEV  Non  
EF.EGF  2F2F  SM-MAC  NEV 
(par la VU)  Non ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 444  
Fichier/Élément d'information  Numéro de l'enre ­
gistrement  Taille (octets)  Valeurs par 
défaut  
Min Max  
MF 552  1 031  
EF.ICC  
sensorGNSSSerialNumber  8  8  
DF GNSS Facility  612  1 023  
EF EGF_MACertificate  204  341  
EGFCertificate  204  341  {00..00}  
EF CA_Certificate  204  341  
MemberStateCertificate  204  341  {00..00}  
EF Link_Certificate  204  341  
LinkCertificate  204  341  {00..00}  
EF.EGF  
Phrase RMC NMEA  '01'  85  85  
1 e phrase GSA NMEA  '02'  85  85  
2 e phrase GSA NMEA  '03'  85  85  
3 e phrase GSA NMEA  '04'  85  85  
4 e phrase GSA NMEA  '05'  85  85  
5 e phrase GSA NMEA  '06'  85  85  
Numéro de série étendu du dispositif 
GNSS externe défini à l'appendice 1 
comme SensorGNSSSerialNumber.  '07' 8  8  
Identificateur du système d'exploita ­
tion de l'émetteur-récepteur sécurisé 
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 SensorExternalGNSSAppro ­
valNumber.  '09' 16  16  
Identificateur du composant de sécu ­
rité du dispositif GNSS externe défini 
à l'appendice 1 comme SensorExter ­
nalGNSSSCIdentifier  '10' 8  8  
RFU — Reserved for Future Use  De «11» à «FD»  
▼B 
4.2.2  Transfert sécurisé de données GNSS  
GNS_22 Le transfert sécurisé des données de positionnement GNSS est 
autorisé uniquement dans les conditions suivantes:  
1. La procédure d'appariement a abouti conformément aux 
dispositions de l'appendice 11. Mécanismes de sécurité 
communs.  ▼C2
 02016R0799 — FR — 26.02.2020 — 002.001 — 445  
2. L'authentification mutuelle régulière et la concordance de 
clés de session entre la VU et le dispositif GNSS externe 
également décrites à l'appendice 11. Les mécanismes de 
sécurité 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'appariement, de l'au ­
thentification 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 (provenant de la 
phrase GSA NMEA) au dispositif GNSS externe. L'émet ­
teur-récepteur sécurisé de la VU utilise les commandes 
SELECT et READ RECORD(S) conformément à la 
norme ISO/IEC 7816-4:2013 en mode authentification 
uniquement de la messagerie sécurisée, tel que le prévoit 
l'appendice 11, section 11.5, avec l'identificateur de fichier 
‘2F2F’ et le nombre de RECORD é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émori ­
sées dans l'EF avec l'identificateur ‘2F2F’ et les enregis ­
trements décrits au tableau 1 dans l'émetteur-récepteur 
sécurisé GNSS car ce dernier reçoit les données NMEA 
du récepteur GNSS, sur une fréquence d'au moins 1 Hz, 
par l'interface de données GNSS.  
3. L'émetteur-récepteur sécurisé GNSS envoie la réponse à 
l'émetteur-récepteur sécurisé de la VU à l'aide du 
message de réponse UDPA en mode authentification 
uniquement de la messagerie sécurisée, comme le décrit 
l'appendice 11, section 11.5.  
4. L'émetteur-récepteur sécurisé de la VU contrôle l'authenti ­
cité 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'interface de données GNSS.  
▼M1 
5. Le processeur de la VU vérifie les données reçues en 
extrayant les informations (p. ex. la latitude, la longitude 
ou l’heure) de la phrase RMC NMEA. Cette dernière inclut 
les informations si le positionnement 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 minimale 
d’après les systèmes de satellites disponibles (p. ex., 
lorsque les points de repère sont disponibles).  
▼B 
6. Le processeur de la VU mémorise 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éogra ­
phiques avec la valeur HDOP calculée selon le minimum 
des valeurs HDOP recueillies sur les systèmes GNSS 
disponibles.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 446  
4.2.3  Structure de la commande Read Record  
La présente section décrit en détail la structure de la commande Read 
Record (lecture des enregistrements). La messagerie sécurisée (mode 
authentification uniquement) est ajoutée conformément aux dispositions 
de l'appendice 11 Mécanismes de sécurité communs.  
GNS_24 La commande est compatible avec le mode authentification 
uniquement de la messagerie sécurisée; cf. appendice 11.  
GNS_25 Message de commande  
Octet  Lon- 
gueur  Valeur  Description  
CLA  1  ‘0Ch’  Messagerie sécurisée demandée.  
INS 1  ‘B2h’  Lire l'enregistrement.  
P1 1  ‘XXh’  Nombre d'enregistrements (‘00’ indique l'en ­
registrement en cours).  
P2 1  ‘04h’  Lire l'enregistrement avec le nombre d'enre ­
gistrements indiqué en P1.  
Le 1  ‘XXh’  Longueur de données prévisible. Nombre 
d'octets à extraire.  
GNS_26 L'enregistrement référencé en P1 devient l'enregistrement en 
cours.  
Octet  Lon- 
gueur  Valeur  Description  
#1-#X  X  ‘XX..XXh’  Données extraites  
SW 2  ‘XXXXh’  Mots d'état (ME1, ME2)  
— Si la commande aboutit, l'émetteur-récepteur sécurisé 
GNSS renvoie ‘ 9000 ’. 
— Si le fichier en cours n'est pas orienté enregistrement, 
l'émetteur-récepteur sécurisé GNSS renvoie  ‘6981’ . 
— Si la commande est utilisée avec P1 = ‘00’, mais sans 
aucun EF en cours, l'émetteur-récepteur sécurisé GNSS 
renvoie  ‘6986’  (commande interdite).  
— Si l'enregistrement est introuvable, l'émetteur-récepteur 
sécurisé GNSS renvoie  ‘6A 83’ . 
— Si le dispositif GNSS externe détecte une fraude, il renvoie 
les mots d'état  ‘66 90’ . 
GNS_27 L'émetteur-récepteur sécurisé GNSS est compatible avec les 
commandes suivantes de la deuxième génération de tachy ­
graphes, définies à l'appendice 2:  
Commande  Référence  
Select  Appendice 2 chapitre 3.5.1  
Read Binary  Appendice 2 chapitre 3.5.2  
Get Challenge  Appendice 2 chapitre 3.5.4  
PSO: Verify Certificate  Appendice 2 chapitre 3.5.7  
External Authenticate  Appendice 2 chapitre 3.5.9  
General Authenticate  Appendice 2 chapitre 3.5.10  
MSE:SET  Appendice 2 chapitre 3.5.11  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 447  
4.3. Appariement, authentification mutuelle et concordance de clés de 
session du dispositif GNSS externe avec la VU  
L'appariement, l'authentification mutuelle et la concordance de clés de 
session du dispositif GNSS externe avec la VU sont décrits à l'appen ­
dice 11. Mécanismes de sécurité communs, chapitre 11.  
4.4. Traitement des erreurs  
La présente section décrit comment des conditions d'erreur potentielles 
du dispositif GNSS externe sont traitées et enregistrées dans la VU.  
4.4.1  Erreur de communication avec le dispositif GNSS externe  
▼M1 
GNS_28 Si la VU ne parvient pas à gérer la communication avec le 
dispositif GNSS externe apparié pendant plus de 20 minutes 
consécutives, la VU génère et enregistre dans la VU un évène ­
ment de type EventFaultType avec la valeur enum «0E»H 
Communication error with the external GNSS facility assorti 
d’un horodatage indiquant l’heure actuelle. L’événement n’est 
généré que si les deux conditions suivantes sont satisfaites: a) 
le tachygraphe intelligent n’est pas en mode étalonnage et b) 
le véhicule circule. Dans ce contexte, une erreur de commu ­
nication survient lorsque l’émetteur-récepteur sécurisé de la 
VU ne reçoit pas de message de réponse après un message 
de demande, au sens de la section 4.2.  
▼B 
4.4.2  Atteinte à l'intégrité physique du dispositif GNSS externe  
▼M1 
GNS_29 En cas d’atteinte au dispositif GNSS externe, l’émetteur-récep ­
teur sécurisé GNSS efface toute sa mémoire, y compris le 
matériel cryptographique. Comme le prévoient GNS_25 et 
GNS_26, la VU détecte les infractions si la réponse possède 
l’état «6690». La VU génère ensuite un événement de type 
EventFaultType enum «19»H Tamper detection of GNSS. Le 
dispositif GNSS externe peut également arrêter de répondre 
aux demandes externes.  
▼B 
4.4.3  Absence d'informations de positionnement en provenance du récepteur 
GNSS  
▼M1 
GNS_30 Si l’émetteur-récepteur sécurisé GNSS ne reçoit aucune 
donnée du récepteur GNSS pendant plus de trois heures 
successives, il génère un message 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émorise un évènement 
de type EventFaultType enum «0D»H Absence of position 
information from GNSS receiver assorti d’un horodatage indi ­
quant l’heure actuelle uniquement si les deux conditions 
suivantes sont satisfaites: a) le tachygraphe intelligent n’est 
pas en mode étalonnage et b) le véhicule circule.  
▼B 
4.4.4  Expiration du certificat du dispositif GNSS externe  
GNS_31  ►M1 Si la VU détecte que le certificat EGF utilisé pour 
l’authentification mutuelle n’est plus valide, la VU génère et 
enregistre un événement de l’équipement d’enregistrement de 
type EventFaultType enum  «1B»H External GNSS facility 
certificate expired  assorti d’un horodatage indiquant l’heure 
actuelle. La VU utilise encore les données de positionnement 
GNSS reçues. ◄ ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 448  
Figure 4  
Schéma du dispositif GNSS externe
  
5. UNITÉ EMBARQUÉE SUR LE VÉHICULE SANS DISPOSITIF GNSS 
EXTERNE  
5.1. Configuration  
Dans cette configuration, le récepteur GNSS est situé à l'intérieur de la 
VU tel qu'illustré à la figure 1.  
GNS_32 Le récepteur GNSS tient le rôle de l'émetteur qui transmet les 
phrases NMEA au processeur de la VU, qui tient le rôle de 
récepteur sur une fréquence d'1/10 Hz ou supérieure pour le 
jeu prédéfini 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'informations de positionnement en provenance du récepteur 
GNSS  
▼M1 
GNS_34 Si la VU ne reçoit aucune donnée du récepteur GNSS pendant 
plus de trois heures successives, la VU génère et mémorise un 
évènement de type EventFaultType enum «0D»H Absence of 
position information from GNSS receiver assorti d’un horoda ­
tage indiquant l’heure actuelle uniquement si les deux condi ­
tions suivantes sont satisfaites: a) le tachygraphe intelligent 
n’est pas en mode étalonnage et b) le véhicule circule.  
6. CONFLIT TEMPOREL GNSS  
Si la VU détecte un écart de plus d’une minute entre le temps indiqué par 
sa fonction de mesure du temps et le temps indiqué par le récepteur 
GNSS, la VU mémorise un évènement de type EventFaultType enum  
«0B»H Time conflict (GNSS versus VU internal clock).  Après le déclen ­
chement d’un événement «Conflit temporel», la VU ne vérifie plus les 
écarts 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écepteur GNSS au cours des 30 derniers jours.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 449  
7. CONFLIT CONCERNANT LE MOUVEMENT DU VÉHICULE  
GNS_35 La VU déclenche et mémorise un évènement de conflit de 
mouvement du véhicule (cf. exigence 84 de l'annexe 1C) 
assorti d'un horodatage indiquant l'heure actuelle si les infor ­
mations relatives au mouvement calculées par le capteur de 
mouvement entrent en conflit avec les informations relatives 
au mouvement calculées par le récepteur GNSS interne ou le 
dispositif GNSS externe. Pour détecter ces conflits, on utilise 
la valeur médiane des écarts de vitesse entre ces sources, 
comme précisé ci-dessous:  
— toutes les dix secondes, la valeur absolue de l'écart entre la 
vitesse du véhicule estimée par le dispositif GNSS et celle 
estimée par le capteur de mouvement est calculée.  
— toutes les données calculées dans une fenêtre horaire 
comportant les dernières cinq minutes 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 conflit 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 ininterrompues. On 
peut également utiliser d'autres sources indépendantes de 
détection du mouvement du véhicule afin de renforcer la fiabi ­
lité de détection des manipulations du tachygraphe. 
(Remarque:  utiliser la valeur médiane des cinq dernières 
minutes limite le risque d'aberrations de mesure et de 
valeurs transitoires.) 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écepteur GNSS ne sont pas disponibles et c) en mode étalon ­
nage.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 450  
Appendice 13  
INTERFACE ITS  
TABLE DES MATIÈRES  
1. INTRODUCTION  
2. CHAMP D'APPLICATION  
2.1. Abréviations, définitions et notations  
3. RÈGLEMENT ET NORMES RÉFÉRENTS  
4. PRINCIPES DE FONCTIONNEMENT DE L'INTERFACE  
4.1. Conditions prérequises pour le transfert de données au moyen de l'inter ­ 
face ITS  
4.1.1 Les données fournies grâce à l'interface ITS  
4.1.2 Contenu des données  
4.1.3 Applications ITS  
4.2. Technologie de communication  
4.3. Autorisation PIN  
4.4. Structure des messages  
4.5. Consentement du conducteur  
4.6. Retrait de données standard  
4.7. Récupération de données à caractère personnel  
4.8. Récupération de données associées aux évènements et aux anomalies  
1. INTRODUCTION  
Le présent appendice précise la conception et les procédures à respecter 
pour mettre en œuvre l'interface avec le système de transport intelligent 
(ITS) tel que le préconise l'article 10 du règlement (UE) n  o 165/2014 ( le 
règlement ). 
Le règlement  précise que les tachygraphes des véhicules peuvent être 
équipés d'interfaces normalisées permettant l'utilisation en mode opération ­
nel, par un dispositif extérieur, des données enregistrées ou produites par 
le tachygraphe, pour autant que les conditions suivantes soient remplies:  
(a) l'interface n'affecte pas l'authenticité ou l'intégrité des données du 
tachygraphe;  
(b) l'interface est conforme aux dispositions détaillées énoncées à l'ar ­
ticle 11 du règlement;  
(c) le dispositif extérieur connecté à l'interface n'a accès aux données à 
caractère personnel, y compris celles relatives à la géolocalisation, 
qu'après obtention du consentement vérifiable du conducteur auquel 
les données se rapportent.  
2. CHAMP D'APPLICATION  
Le champ d'application du présent appendice consiste à préciser comment 
les applications hébergées sur des dispositifs externes obtiennent  les 
données  émanant d'un tachygraphe par connexion Bluetooth®.  
Les données disponibles au moyen de cette interface sont décrites à l'an ­
nexe 1 du présent document. Cette interface n'empêche de mettre en 
œuvre d'autres interfaces (p. ex. au moyen d'un bus CAN) afin de trans ­
mettre les données de la VU à d'autres unités de traitement sur véhicule.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 451  
Le présent appendice précise:  
— Les données  disponibles grâce à l'interface ITS  
— Le profil Bluetooth® utilisé pour transférer les données  
— Les procédures de demande et de téléchargement et la séquence des 
opérations.  
— Le mécanisme de couplage entre le tachygraphe et le dispositif externe  
— Le mécanisme d'accord accessible au conducteur  
▼M1 
Pour plus de précision, le présent appendice ne spécifie  pas:  
— la collecte de l’opération et de la gestion des  données  au sein de la VU 
(qui sera spécifiée ailleurs dans le  règlement  ou constituera autrement 
une fonction de la conception du produit).  
— La forme de la présentation des données collectées pour l’application 
hébergée sur le dispositif externe.  
— Les dispositions de protection des données au-delà de ce que prévoit 
Bluetooth® (comme le codage) concernant le contenu des  données  
(qui sera précisé ailleurs dans le  règlement  [appendice 11 — Méca ­
nismes de sécurité communs]).  
— Les protocoles Bluetooth® qu’utilise l’interface ITS.  
▼B 
2.1. Abréviations, définitions et notations  
Les abréviations et définitions qui suivent apparaissent dans le présent 
appendice:  
la communication  échange d'informations ou de données entre une unité 
maîtresse (comme les tachygraphes) et une unité 
externe à l'aide de l'interface ITS et de Bluetooth®.  
les données  telles que définies à l'annexe 1.  
le règlement  Règlement (UE) n  o 165/2014 du Parlement européen et du 
Conseil du 4 février 2014 relatif aux tachygraphes dans les 
transports routiers, abrogeant le règlement (CEE) 
n o 3821/85 du Conseil concernant l'appareil de contrôle 
dans le domaine des transports par route et modifiant le 
règlement (CE) n  o 561/2006 du Parlement européen et du 
Conseil relatif à l'harmonisation de certaines dispositions 
de la législation sociale dans le domaine des transports par 
route  
BR Débit de base  
EDR  Débit de données amélioré  
GNSS  Global Navigation Satellite System (système mondial de 
radionavigation par satellite)  
IRK  Clé de résolution d'identité  
ITS (ITS)  Système de transport intelligent  
LE Faible valeur énergétique  
PIN Numéro d'identification personnel  
PUC  Code de déverrouillage personnel  
SID Identifiant de diagnostic  
SPP Profil de port série  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 452  
SSP Couplage simple et sécurisé  
TRTP  Paramètre de demande du transfert  
TREP  Paramètre de réponse du transfert  
VU Unité embarquée sur le véhicule  
3. RÈGLEMENT ET NORMES RÉFÉRENTS  
La spécification 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 concernées figurent au fil des clauses du présent appendice. En 
cas de conflit, 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) n  o 165/2014 du Parlement Européen et du Conseil du 
4 février 2014 relatif aux tachygraphes dans les transports routiers, 
abrogeant le règlement (CEE) n  o 3821/85 du Conseil concernant l'ap ­
pareil de contrôle dans le domaine des transports par route et modifiant 
le règlement (CE) n  o 561/2006 du Parlement européen et du Conseil 
relatif à l'harmonisation de certaines dispositions de la législation 
sociale dans le domaine des transports par route.  
— Règlement (CE) n  o 561/2006 du Parlement européen et du Conseil du 
15 mars 2006 relatif à l'harmonisation de certaines dispositions de la 
législation sociale dans le domaine des transports par route, modifiant 
les règlements (CEE) n  o 3821/85 et (CE) n  o 2135/98 du Conseil et 
abrogeant le règlement (CEE) n  o 3820/85 du Conseil.  
— ISO 16844 — 4: Véhicules routiers — Systèmes tachygraphes — 
Partie 4: Interface CAN  
— ISO 16844 — 7: Véhicules routiers — Systèmes tachygraphes — 
Partie 7: Paramètres  
— Bluetooth® — Profil de port série — V1.2  
— Bluetooth® — Version standard 4.2  
— Protocole NMEA 0183 V4.1  
4. PRINCIPES DE FONCTIONNEMENT DE L'INTERFACE  
4.1. Conditions prérequises pour le transfert de données au moyen de 
l'interface ITS  
La VU est responsable de l'actualisation et de la mémorisation des 
données dans la VU sans impliquer l'interface ITS. Les moyens pour y 
parvenir sont internes à 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 disponi ­
bles 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'ab­
sence de précision, il s'agit d'une fonction liée à la conception du produit 
non spécifiée dans le présent Appendice.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 453  
4.1.2  Contenu des données  
Le contenu des  données  est spécifié en Annexe 1 du présent Appendice.  
4.1.3  Applications ITS  
Les applications ITS utilisent les données mises à disposition par l'inter ­
face ITS, par exemple, dans le but d'optimiser la gestion des activités du 
conducteur tout en respectant le Règlement et pour détecter les éventuelles 
anomalies du tachygraphe ou utiliser les données du dispositif GNSS. Les 
spécifications des applications sortent du champ d'application du présent 
Appendice.  
4.2. Technologie de communication  
L'échange de  données  à l'aide de l'interface ITS se fait par une interface 
Bluetooth® compatible de version 4.2 ou ultérieure. Bluetooth® opère sur 
la bande de fréquence industrielle, scientifique et médicale (ISM) sans 
licence entre 2,4 GHZ et 2,485 GHz. Bluetooth® 4.2 comprend des méca ­
nismes de sécurité et de confidentialité renforcés et accroît la vitesse et la 
fiabilité des transferts de données. Aux fins de la présente spécification, on 
utilise la portée radio Bluetooth® classe 2 pouvant atteindre 10 m. Pour 
tout complément d'information sur Bluetooth® 4.2, consulter www.blue ­
tooth.com (https://www.bluetooth.org/en-us/specification/adopted-specifi ­
cations?_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 concept 
Bluetooth® utilisant un modèle maître/esclave pour contrôler quand et où 
les dispositifs peuvent envoyer des données, le tachygraphe joue le rôle 
d'unité maitresse et le dispositif externe, celui d'esclave.  
▼M1 
Lorsqu’un dispositif externe entre dans le champ de portée de la VU pour 
la première fois, la procédure de couplage Bluetooth® peut être démarrée 
(cf. également annexe 2). Les dispositifs partagent leur adresse, nom, 
profil et clé secrète commune. Cela leur permet de se connecter dès 
qu’ils se retrouvent à proximité l’un de l’autre à nouveau. Après cette 
étape, le dispositif externe est sécurisé et en mesure d’effectuer des 
demandes de téléchargement de données émanant du tachygraphe. Il 
n’est pas prévu d’ajouter des mécanismes de codage supplémentaires au- 
delà de ceux assurés par Bluetooth®. Cependant, si des mécanismes de 
sécurité additionnels se révélaient nécessaires, ils seraient ajoutés confor ­
mément à l’appendice 11 Mécanismes de sécurité communs.  
▼B 
Les principes de communication globaux sont décrits par la figure 
suivante.
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 454  
Le profil SPP (Serial Port Profile) de Bluetooth® sert à transférer des 
données émanant de la VU à destination du dispositif externe.  
4.3. Autorisation PIN  
▼M1 
Pour des raisons de sécurité, la VU nécessite un système d’autorisation 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 externe se couple avec la VU, 
il doit fournir le code PIN correct avant de recevoir des données, quelles 
qu’elles soient.  
▼B 
Renseigner le PIN place le dispositif sur la liste autorisée. La liste auto ­
risée mémorise 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 exclu, toute nouvelle tentative du dispositif est vouée à l'échec. 
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 chronolo ­
gique 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'échecs successifs  Durée du verrouillage  
3 30 secondes  
6 5 minutes  
9 1 heure  
12 24 heures  
15 Permanents  
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éverrouiller le système consiste à renseigner le code PUC correct.  
Le code PUC est composé 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.  
▼M1 
Il arrive que le fabricant permette à titre facultatif de modifier le code PIN 
directement sur la VU; toutefois, le code PUC n’est pas modifiable. La 
modification du code PIN, le cas échéant, requiert d'indiquer le code PIN 
directement sur la VU.  
▼B 
De plus, tous les dispositifs placés en liste autorisée y demeurent jusqu'à 
leur retrait manuel par l'utilisateur (p. ex. à l'aide de l'interface homme- 
machine de la VU ou par d'autres moyens). Procéder de la sorte permet de 
supprimer les unités ITS perdues ou volées de la liste autorisée. De même, 
toutes les unités ITS sortant de la portée de connexion Bluetooth® plus de 
vingt-quatre heures doivent être automatiquement supprimées de la liste 
autorisée de la VU, et l'on doit renseigner le code PIN exact une nouvelle 
fois lorsque la connexion est rétablie.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 455  
La structure des messages entre l'interface de la VU et la VU n'est pas 
imposée, mais laissée à la discrétion du fabricant. Ledit fabricant doit 
toutefois s'assurer que la structure des messages échangés entre l'unité 
ITS et l'interface de la VU est respectée (cf. spécifications ASN.1).  
Toute demande de données doit donc satisfaire à la vérification correcte 
des identifiants de l'expéditeur préalablement à toute autre forme de trai ­
tement. La figure 2 de l'annexe 2 représente le schéma du déroulement 
chronologique de cette procédure. Tout dispositif verrouillé reçoit un refus 
automatique. Tout dispositif ni verrouillé ni autorisé reçoit une demande 
de PIN à renseigner avant de faire suivre sa demande de données.  
4.4. Structure des messages  
Tous les messages échangés entre l'unité ITS et la VU se caractérisent par 
une structure à trois éléments: en-tête composé d'un octet cible (TGT), 
d'un octet source (SRC) et d'un octet de longueur (LEN).  
La zone de données composée d'un octet d'identification de diagnostic 
(SID) et d'un nombre variable d'octets d'information (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'interface VU porte par défaut l'ID «EE». Cet ID n'est pas modifiable. 
L'unité ITS utilise l'ID «A0» par défaut pour son premier message de 
session de communication. L'interface de la VU assigne alors un ID 
unique à l'unité ITS et l'informe de cet ID pour les futurs messages de 
la session.  
L'octet LEN tient compte uniquement de la partie «données» de la zone de 
données (cf. Tableau 2), car les quatre premiers octets sont implicites.  
L'interface VU confirme l'authenticité de l'expéditeur du message en 
contre-vérifiant 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 comporter les paramètres 
suivants: un paramètre de demande du transfert (TRTP) et des octets de 
compteur.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 456  
Si les données à manipuler dépassent l’espace disponible dans un 
message, elles seront partagées en plusieurs sous-messages. Chaque 
sous-message présente le même en-tête et le même SID, mais contient 
un compteur sur deux octets, un compteur courant (CC) et un compteur 
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 dispo ­
sitif récepteur accuse réception de chaque sous-message. Le dispositif 
récepteur est à même d’accepter le sous-message, d’en demander la 
réémission et de demander au dispositif émetteur d’en reprendre ou d’en 
abandonner la transmission.  
▼B 
Non utilisés, CC et CM présentent la valeur 0xFF.  
Par exemple: le message suivant  
EN-TÊTE  SID  TRTP  CC  CM  donné­
es CS 
3 octets  Longueur supérieure à 255 octets  1 octet  
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'échanger. 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étaillé des messages  
Message  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)  
PairingResult  ITSID  EE  01  04  FF  BOOLEAN (T/F)  
SendPUC  EE  ITSID  08  05  FF  8*INTEGER (0..9)  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 457  
Message  En-tête  DONNÉES  Total de 
contrôle  
TGT  SRC  LEN  SID  TRTP  DONNÉES  
BanLiftingResult  ITSID  EE  01  06  FF  BOOLEAN (T/F)  
RequestRejected  ITSID  EE  08  07  FF  Temps  
RequestData  
standardTachData  EE  ITSID  01  08  01  
personalTachData  EE  ITSID  01  08  02  
gnssData  EE  ITSID  01  08  03  
standardEventData  EE  ITSID  01  08  04  
personalEventData  EE  ITSID  01  08  05  
standardFaultData  EE  ITSID  01  08  06  
manufacturerData  EE  ITSID  01  08  07  
ResquestAccepted  ITSID  EE  Len  09  TREP  Résultats  
DataUnavailable  
Chiffres non 
disponibles  ITSID  EE  02  0A  TREP  10  
données à carac ­
tère personnel non 
partagées  ITSID  EE  02  0A  TREP  11  
NegativeAnswer  
Téléchargement 
refusé  ITSID  EE  02  0B  SID Req  10  
Service incompati ­
ble ITSID  EE  02  0B  SID Req  11  
Sous-fonction 
incompatible  ITSID  EE  02  0B  SID Req  12  
Longueur du 
message incorrecte  ITSID  EE  02  0B  SID Req  13  
Conditions non 
correctes ou erreur 
affectant la 
séquence d'inter ­
rogation  ITSID  EE  02  0B  SID Req  22  
Demande exces ­
sive 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 autorisée lui adresse une demande de données.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 458  
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éfaut «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 contenu de ce message est un code constitué d'un nombre 
ENTIER de 4 chiffres compris entre 0 et 9.  
PairingResult (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 contenu de ce message 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 supprime de la liste 
noire. Le contenu de ce message est un code constitué d'un nombre 
ENTIER de 8 chiffres compris entre 0 et 9.  
BanLiftingResult (SID 06)  
Ce message est émis par l'interface de la VU pour informer l'unité du ITS 
si le code PUC envoyé est correct. Le contenu 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 
comporte la durée restante de verrouillage de l'unité ITS, selon la structure 
séquentielle «chronologique» définie à l'annexe 3.  
RequestData (SID 08)  
Ce message d'accès aux données est émis par l'unité ITS. Un paramètre de 
demande de transfert (TRTP) d'un octet indique de quelle catégorie de 
données il s'agit. Il existe plusieurs catégories de données:  
— standardTachData (TRTP 01): données disponibles en provenance du 
tachygraphe classées non personnelles.  
— personalTachData (TRTP 02): données disponibles en provenance du 
tachygraphe classées personnelles.  
— gnssData (TRTP 03): données du dispositif GNSS, toujours person ­
nelles.  
— standardEventData (TRTP 04): données relatives aux événements 
mémorisés classées non personnelles.  
— personalEventData (TRTP 05): données relatives aux événements 
mémorisés classées personnelles.  
— standardFaultData (TRTP 06): anomalies mémorisées classées non 
personnelles.  
— manufacturerData (TRTP 07): données mises à disposition par le fabri ­
cant. ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 459  
Cf. Annexe 3 du présent Appendice pour toute information complémen ­
taire relative à chaque catégorie de données.  
Cf. l'appendice 12 pour tout complément d'information à propos de la 
structure et du contenu des données du dispositif GNSS.  
Cf. les annexes 1B et 1C pour tout complément d'information à 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 «Request ­
Data» émanant d'une unité ITS a été accepté. Ce message comporte un 
octet TREP, qui correspond à l'octet TRTP du message RequestData 
associé et toutes les données de la catégorie demandée.  
DataUnavailable (SID 0A)  
Ce message est émis par l'interface de la VU si, pour une raison quel ­
conque, il est impossible d'envoyer les données demandées à une unité 
ITS autorisée. Ce message comporte 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 tente 
d'extraire des données à caractère personnel non partagées.  
NegativeAnswer (SID 0B)  
Ces messages sont émis par l'interface de la VU si une demande ne peut 
aboutir pour toute autre raison que l'indisponibilité des données. Ces 
messages résultent généralement d'une mauvaise formulation de la struc ­
ture de la demande (longueur, SID, ITSID…), sans s'y limiter. Le TRTP 
dans la zone de données comporte le SID de la demande. La zone de 
données comporte un code identifiant 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  DataUnavailable ). 
— Service non pris en charge (code: 11)  
— Le SID de la demande n'est pas compris.  
— Sous-fonction non prise en charge (code: 12)  
— Le TRTP de la demande n'est pas compris. Il peut par exemple être 
manquant ou en dehors de la plage de valeurs acceptée.  
— Longueur du message incorrecte (code: 13)  
— La longueur du message reçu est erronée (décalage entre l'octet LEN et 
la longueur réelle du message).  
— Conditions non correctes ou erreur affectant la séquence d'interrogation 
(code: 22)  
— Le service demandé n'est pas disponible ou la séquence des messages 
de demande est incorrecte.  
— Demande excessive (code: 33)  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 460  
— 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 à accepter une autre demande.  
— Décalage  ITSID  (code: FB)  
— L' ITSID  du SRC ne correspond pas au dispositif associé après compa ­
raison avec les informations émanant de Bluetooth®.  
— ITSID  introuvable (code: FC)  
— L' ITSID  SRC n'est pas associé à un dispositif.  
Les lignes 1 à 72 ( FormatMessageModule ) du code ASN.1 dans l'an ­
nexe 3 spécifient la structure des messages telle que décrite au tableau 3. 
Davantage d'informations suivent à propos du contenu des messages.  
4.5. Consentement du conducteur  
Toutes les données disponibles sont classées comme standard ou à carac ­
tère personnel. Les données à caractère personnel sont uniquement acces ­
sibles si le conducteur a donné son accord et accepter que ses données à 
caractère personnel liées au tachygraphe quittent le réseau du véhicule à 
destination d'applications tierces.  
Le conducteur donne son accord lorsqu'à la première insertion d'une carte 
de conducteur 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 à caractère personnel en lien avec le tachygraphe puissent être 
extraites via l'interface ITS facultative. (cf. Annexe 1C, paragraphe 3.6.2).  
L'état de l'accord (activé/désactivé) est mémorisé par le tachygraphe.  
Dans le cas de conducteurs multiples, seules les données à caractère 
personnel concernant les conducteurs qui ont donné leur accord sont 
partagées avec l'interface ITS. Par exemple, si deux conducteurs occupent 
le véhicule et que seulement l'un d'entre eux accepte de partager ses 
données à caractère personnel, celles de l'autre conducteur ne sont pas 
partagées.  
4.6. Retrait de données standard  
La figure 3 de l'annexe 2 représente le schéma de la séquence d'une 
demande valable adressée par l'unité ITS pour accéder aux données stan ­
dard. L'unité ITS est placée en liste autorisé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équate sur la Figure 2 
de l'annexe 2. Cela correspond à la case grisée  REQUEST TREATMENT  
de la Figure 2.  
Parmi les données disponibles, les données suivantes sont considérées 
comme standard:  
— standardTachData (TRTP 01)  
— standardEventData (TRTP 04)  
— standardFaultData (TRTP 06)  
4.7. Récupération de données à caractère personnel  
La Figure 4 de l'annexe 2 représente le schéma séquentiel du traitement 
d'une demande de données à caractère personnel. Comme précédemment 
expliqué, l'interface 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 automatiquement rejetée.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 461  
Parmi les données disponibles, les données suivantes sont considérées 
comme personnelles:  
— personalTachData (TRTP 02)  
— gnssData (TRTP 03)  
— personalEventData (TRTP 05)  
— manufacturerData (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 comportant la liste de tous les évènements imprévus. Ces 
données sont considérées comme étant des données standard ou person ­
nelles, cf. annexe 3. Le contenu de chaque évènement varie selon la 
documentation fournie en annexe 1 du présent Appendice.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 462  
ANNEXE 1  
▼M1 
1) LISTE DES DONNÉES DISPONIBLES GRÂCE À L'INTERFACE ITS  
▼C2 
Données  Source  Classification des données 
(à caractère personnel/sans 
caractère personnel)  
VehicleIdentificationNumber  Unité embarquée sur le véhicule  sans caractère personnel  
CalibrationDate  Unité embarquée sur le véhicule  sans caractère personnel  
TachographVehicleSpeed 
speed instant t  Unité embarquée sur le véhicule  à caractère personnel  
Driver1WorkingState Selector 
driver  Unité embarquée sur le véhicule  à caractère personnel  
Driver2WorkingState  Unité embarquée sur le véhicule  à caractère personnel  
DriveRecognize Speed Thres ­
hold detected  Unité embarquée sur le véhicule  sans caractère personnel  
Driver1TimeRelatedStates 
Weekly day time  Carte du conducteur  à caractère personnel  
Driver2TimeRelatedStates  Carte du conducteur  à caractère personnel  
DriverCardDriver1  Unité embarquée sur le véhicule  sans caractère personnel  
DriverCardDriver2  Unité embarquée sur le véhicule  sans caractère personnel  
OverSpeed  Unité embarquée sur le véhicule  à caractère personnel  
TimeDate  Unité embarquée sur le véhicule  sans caractère personnel  
HighResolutionTotalVehicle ­
Distance  Unité embarquée sur le véhicule  sans caractère personnel  
ServiceComponentIdentifica ­
tion Unité embarquée sur le véhicule  sans caractère personnel  
ServiceDelayCalendarTimeBa ­
sed Unité embarquée sur le véhicule  sans caractère personnel  
Driver1Identification  Carte du conducteur  à caractère personnel  
Driver2Identification  Carte du conducteur  à caractère personnel  
NextCalibrationDate  Unité embarquée sur le véhicule  sans caractère personnel  
Driver1ContinuousDriving ­
Time  Carte du conducteur  à caractère personnel  
Driver2ContinuousDriving ­
Time  Carte du conducteur  à caractère personnel  
Driver1CumulativeBreakTime  Carte du conducteur  à caractère personnel  
Driver2CumulativeBreakTime  Carte du conducteur  à caractère personnel  
Driver1CurrentDurationOfSe ­
lectedActivity  Carte du conducteur  à caractère personnel  
Driver2CurrentDurationOfSe ­
lectedActivity  Carte du conducteur  à caractère personnel  
SpeedAuthorised  Unité embarquée sur le véhicule  sans caractère personnel  
TachographCardSlot1  Carte du conducteur  sans caractère personnel  
TachographCardSlot2  Carte du conducteur  sans caractère personnel  
Driver1Name  Carte du conducteur  à caractère personnel  
Driver2Name  Carte du conducteur  à caractère personnel  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 463  
Données  Source  Classification des données 
(à caractère personnel/sans 
caractère personnel)  
OutOfScopeCondition  Unité embarquée sur le véhicule  sans caractère personnel  
ModeOfOperation  Unité embarquée sur le véhicule  sans caractère personnel  
Driver1CumulatedDrivingTi ­
mePreviousAndCurrentWeek  Carte du conducteur  à caractère personnel  
Driver2CumulatedDrivingTi ­
mePreviousAndCurrentWeek  Carte du conducteur  à caractère personnel  
EngineSpeed  Unité embarquée sur le véhicule  à caractère personnel  
RegisteringMemberState  Unité embarquée sur le véhicule  sans caractère personnel  
VehicleRegistrationNumber  Unité embarquée sur le véhicule  sans caractère personnel  
Driver1EndOfLastDailyRest ­
Period  Carte du conducteur  à caractère personnel  
Driver2EndOfLastDailyRest ­
Period  Carte du conducteur  à caractère personnel  
Driver1EndOfLastWeeklyRest ­
Period  Carte du conducteur  à caractère personnel  
Driver2EndOfLastWeeklyRest ­
Period  Carte du conducteur  à caractère personnel  
Driver1EndOfSecondLastWee ­
klyRestPeriod  Carte du conducteur  à caractère personnel  
Driver2EndOfSecondLastWee ­
klyRestPeriod  Carte du conducteur  à caractère personnel  
Driver1CurrentDailyDriving ­
Time  Carte du conducteur  à caractère personnel  
Driver2CurrentDailyDriving ­
Time  Carte du conducteur  à caractère personnel  
Driver1CurrentWeeklyDriving ­
Time  Carte du conducteur  à caractère personnel  
Driver2CurrentWeeklyDriving ­
Time  Carte du conducteur  à caractère personnel  
Driver1TimeLeftUntilNewDai ­
lyRestPeriod  Carte du conducteur  à caractère personnel  
Driver2TimeLeftUntilNewDai ­
lyRestPeriod  Carte du conducteur  à caractère personnel  
Driver1CardExpiryDate  Carte du conducteur  à caractère personnel  
Driver2CardExpiryDate  Carte du conducteur  à caractère personnel  
Driver1CardNextMandatory ­
DownloadDate  Carte du conducteur  à caractère personnel  
Driver2CardNextMandatory ­
DownloadDate  Carte du conducteur  à caractère personnel  
TachographNextMandatory ­
DownloadDate  Unité embarquée sur le véhicule  sans caractère personnel  
Driver1TimeLeftUntilNew ­
WeeklyRestPeriod  Carte du conducteur  à caractère personnel  
Driver2TimeLeftUntilNew ­
WeeklyRestPeriod  Carte du conducteur  à caractère personnel  
Driver1NumberOfTimes9hDai ­
lyDrivingTimesExceeded  Carte du conducteur  à caractère personnel  
Driver2NumberOfTimes9hDai ­
lyDrivingTimesExceeced  Carte du conducteur  à caractère personnel  ▼C2
 02016R0799 — FR — 26.02.2020 — 002.001 — 464  
Données  Source  Classification des données 
(à caractère personnel/sans 
caractère personnel)  
Driver1CumulativeUninterrup ­
tedRestTime  Carte du conducteur  à caractère personnel  
Driver2CumulativeUninterrup ­
tedRestTime  Carte du conducteur  à caractère personnel  
Driver1MinimumDailyRest  Carte du conducteur  à caractère personnel  
Driver2MinimumDailyRest  Carte du conducteur  à caractère personnel  
Driver1MinimumWeeklyRest  Carte du conducteur  à caractère personnel  
Driver2MinimumWeeklyRest  Carte du conducteur  à caractère personnel  
Driver1MaximumDailyPeriod  Carte du conducteur  à caractère personnel  
Driver2MaximumDailyPeriod  Carte du conducteur  à caractère personnel  
Driver1MaximumDailyDri ­
vingTime  Carte du conducteur  à caractère personnel  
Driver2MaximumDailyDri ­
vingTime  Carte du conducteur  à caractère personnel  
Driver1NumberOfUsedRedu ­
cedDailyRestPeriods  Carte du conducteur  à caractère personnel  
Driver2NumberOfUsedRedu ­
cedDailyRestPeriods  Carte du conducteur  à caractère personnel  
Driver1RemainingCurrentDri ­
vingTime  Carte du conducteur  à caractère personnel  
Driver2RemainingCurrentDri ­
vingTime  Carte du conducteur  à caractère personnel  
GNSS position  Unité embarquée sur le véhicule  à caractère personnel  
▼B 
2) DONNÉES ÉMANANT DU DISPOSITIF GNSS CONTINU APRÈS 
ACCORD DU CONDUCTEUR  
Cf. Appendice 12: GNSS  
3) CODES LIÉS AUX ÉVÈNEMENTS DISPONIBLES SANS L'ACCORD DU 
CONDUCTEUR  
Événement  Règles de stockage  données à enregistrer pour chaque événement  
Insertion 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.  
Conflit 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 membre de délivrance et la génération de 
chacune des deux cartes à l'origine du conflit.  
Clôture incorrecte de la 
dernière session  — les 10 événements les plus 
récents  — la date et l'heure de l'insertion, 
— 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 figurent sur la carte: 
— la date et l'heure de l'insertion, 
— le numéro d'immatriculation, l'État membre 
d'immatriculation et la génération de la VU.  ▼C2
 02016R0799 — FR — 26.02.2020 — 002.001 — 465  
Événement  Règles de stockage  données à enregistrer pour chaque événement  
Interruption de l'alimenta ­
tion électrique (2)  — l'événement le plus long 
survenu au cours de chacun 
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 membre de délivrance et la génération de 
toute 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 l'équipement de 
communication à distance  — l'événement le plus long 
survenu au cours de chacun 
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 toute 
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'informations de 
position en provenance du 
récepteur GNSS  — l'événement le plus long 
survenu au cours de chacun 
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 membre de délivrance et la génération de 
toute 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.  
▼M1 
Erreur de communication 
avec le dispositif GNSS 
externe  — l’événement le plus long 
survenu au cours de chacun 
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 membre de délivrance et la génération de 
toute 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.  
▼B 
Erreur au niveau des 
données de mouvement  — l'événement le plus long 
survenu au cours de chacun 
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 membre de délivrance et la génération de 
toute 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.  
Conflit concernant le 
mouvement du véhicule  — l'événement le plus long 
survenu au cours de chacun 
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 membre de délivrance et la génération de 
toute 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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 466  
Événement  Règles de stockage  données à enregistrer pour chaque événement  
Tentative d'atteinte à la 
sécurité  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 membre de délivrance et la génération de 
toute carte insérée au début et/ou à la fin de 
l'événement, 
— le type d'événement.  
Conflit temporel  — l'événement le plus long 
survenu au cours de chacun 
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 toute 
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 stockage  données à enregistrer pour chaque événement  
Conduite sans carte appro ­
priée  — l'événement le plus long survenu 
au cours de chacun des 10 
derniers jours d'occurrence, 
— 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 membre de délivrance et la 
génération de toute 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.  
Insertion d'une carte en cours 
de route  — le dernier événement pour 
chacun des 10 derniers jours 
d'occurrence,  — 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.  
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'occurrence, 
— les 5 événements les plus graves 
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 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 conducteur (le cas échéant), 
— le nombre d'événements semblables 
survenus le même jour.  
5) CODES LIÉS AUX DONNÉES RELATIVES AUX ANOMALIES DISPO ­
NIBLES SANS L'ACCORD DU CONDUCTEUR  
Faute  Règles de stockage  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 membre de délivrance et la 
génération.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 467  
Faute  Règles de stockage  données à enregistrer pour chaque anomalie  
Anomalies de l'appareil de 
contrôle  — les 10 anomalies les plus 
récentes pour chaque type d'ano ­
malie, 
— 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éra ­
tion de toute 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'imprimante,  
— anomalie de l'affichage,  
— anomalie de téléchargement,  
— anomalie du capteur,  
— anomalie du récepteur GNSS ou du dispositif GNSS externe,  
— anomalie de l'équipement de communication à distance,  
▼M1 
— anomalie sur l’interface ITS (le cas échéant).  
▼B 
6) ÉVÈNEMENTS ET ANOMALIES PARTICULIERS SE RAPPORTANT 
AU FABRICANT SANS ACCORD DU CONDUCTEUR  
Événement ou anomalie  Règles de stockage  données à enregistrer pour chaque événement  
À définir par le fabricant  À définir par le fabricant  À définir par le fabricant  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 468  
ANNEXE 2  
SCHÉMAS SÉQUENTIELS DES ÉCHANGES DE MESSAGES AVEC L'UNITÉ ITS.  
Figure 1  
Schéma séquentiel de la tentative de validation du PIN
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 469  
Figure 2  
Schéma séquentiel de la vérification d'autorisation par l'unité ITS
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 470  
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)
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 471  
Figure 5  
Schéma séquentiel de la tentative de validation du PUC
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 472  
ANNEXE 3  
SPÉCIFICATIONS ASN.1
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 473
  
▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 474
  
▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 475
  
▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 476
  
► (1) M1 ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 477
  
► (1) (2) (3)  M1 ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 478
  
► (1) M1 ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 479
  
► (1) (2) M1 ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 480
  
▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 481
  
▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 482
  
► (1) M1 ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 483
  
▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 484  
Appendice 14  
FONCTION DE COMMUNICATION À DISTANCE  
TABLE DES MATIÈRES  
1 INTRODUCTION  
2 CHAMP D'APPLICATION  
3 ABRÉVIATIONS, DÉFINITIONS ET NOTATIONS  
4 CAS DE FIGURE OPÉRATIONNELS  
4.1 Vue d'ensemble  
4.1.1 Conditions prérequises pour le transfert de données au moyen de l'inter ­ 
face DSRC 5,8 GHz  
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é 
temporairement en bord de route  
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éhicule  
4.2 Sécurité/Intégrité  
5 CONCEPTION ET PROTOCOLES DE LA COMMUNICATION À 
DISTANCE  
5.1 Conception  
5.2 Déroulement des opérations  
5.2.1 Opérations  
5.2.2 Interprétation des données reçues au moyen de la communication DSRC  
5.3 Paramètres de l'interface DSRC physique pour la communication à 
distance  
5.3.1 Contraintes d'emplacement  
5.3.2 Paramètres de liaisons descendante et montante  
5.3.3 Conception de l'antenne  
5.4 Exigences du protocole DSRC pour RTM  
5.4.1 Vue d'ensemble  
5.4.2 Commandes  
5.4.3 Séquence de commande d'interrogation  
5.4.4 Structures de données  
5.4.5 Éléments de RtmData, actions effectuées et définitions  
5.4.6 Mécanisme de transfert de données  
5.4.7 Description détaillée de la transaction DSRC  
5.4.8 Description de la transaction d'essai DSRC  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 485  
5.6 Transfert de données entre la DSRC-VU et la VU  
5.6.1 Connexion physique et interfaces  
5.6.2 Protocole d'application  
5.7 Traitement des erreurs  
5.7.1 Enregistrement et communication des données dans la DSRC-VU  
5.7.2 Anomalies de communication sans fil  
6 MISE EN SERVICE ET ESSAIS D'INSPECTION PÉRIODIQUES 
RELATIFS À LA FONCTION DE COMMUNICATION À 
DISTANCE  
6.1 Généralités  
6.2 ECHO  
6.3 Essais de validation du contenu des données sécurisées  
1 INTRODUCTION  
Le présent appendice spécifie la conception et les procédures à respecter 
pour mettre en œuvre la fonction de communication à distance (la 
communication) conformément aux dispositions de l'article 9 du règle ­
ment (UE) n  o 165/2014 (le règlement).  
DSC_1 Le règlement (UE) n  o 165/2014 détermine que le tachygraphe 
est équipé d'une fonctionnalité de communication à distance 
qui permet aux autorités chargées du contrôle compétentes de 
lire les informations du tachygraphe embarqué sur les véhi ­
cules en circulation à l'aide d'un équipement d'interrogation à 
distance (lecteur de communication à distance à des fins de 
détection précoce, REDCR). Il s'agit notamment d'un équipe ­
ment d'interrogation à connexion sans fil utilisant des inter ­
faces de communication spécialisée à courte portée (DSRC) 
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 approfondi. Cette fonctionna ­
lité ne remplace pas la procédure d'inspection formelle définie 
par les dispositions du règlement (UE) n  o 165/2014. Voir le 
considérant 9 du préambule de ce règlement qui énonce que la 
communication à distance entre le tachygraphe et les autorités 
chargées 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, conforme à cet appen ­
dice, et validé en fonction des paramètres pertinents de la 
norme EN 300 674-1, {Electromagnetic compatibility and 
Radio spectrum Matters (ERM); Road Transport and Traffic  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 486  
Telematics (RTTT); Dedicated Short Range Communication 
(DSRC) transmission equipment (500 kbit/s / 250 kbit/s) 
operating in the 5,8 GHz Industrial, Scientific and Medical 
(ISM) band; Part 1: General characteristics 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étent en fait la demande, à l'aide des moyens 
de radiocommunication compatibles ( lecteur de communica ­
tion de détection précoce à distance, REDCR ). 
DSC_4  Les données  sont protégées pour assurer leur intégrité.  
DSC_5 L'accès aux  données  communiquées est restreint aux autorités 
de contrôle compétentes autorisées à contrôler les infractions 
au règlement (CE) n  o 561/2006, au règlement (UE) 
n o 165/2014 et aux ateliers dans la mesure où cela s'avère 
nécessaire pour vérifier le fonctionnement satisfaisant du 
tachygraphe.  
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 tachygraphe a pu être manipulé 
ou faire l'objet d'une utilisation abusive.  
DSC_7 L'intégrité et la sécurité des  données  résultent de la sécurisa ­
tion des  données  dans l'unité embarquée sur le véhicule (VU) 
combinée à l'utilisation exclusive du support de communica ­
tion à distance sans fil DSRC sur la bande 5,8 GHz pour 
transférer les données utiles sécurisées et les données relatives 
à la sécurité (cf. 5.4.4). Cela implique que seul le personnel 
autorisé des autorités de contrôle compétentes 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écurité.  
DSC_8  Les données  contiennent un timbre horodateur indiquant 
l'heure de leur dernière mise à jour.  
DSC_9 Le contenu des données relatives à la sécurité est uniquement 
connu des autorités de contrôle compétentes 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  communica ­
tion prévoit le transfert d'un paquet de données relatives à la 
sécurité avec chaque paquet de données utiles.  
DSC_10 La même architecture et le même équipement servent à 
extraire d'autres concepts de données (comme le poids à 
bord) en adoptant l'architecture spécifiée aux présentes.  
DSC_11 Par souci de précision, conformément aux dispositions du 
règlement (UE) n  o 165/2014 (article 7), les données concer ­
nant l'identité du conducteur ne sont pas transmises par la  
communication . 
2 CHAMP D'APPLICATION  
Le présent appendice vise à préciser la manière dont les agents des 
autorités de contrôle compétentes utilisent une communication sans fil 
DSRC 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  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 487  
servir à déterminer si ce véhicule est éventuellement en infraction avec 
le règlement (UE) n  o 165/2014 et s'il faut envisager de l'arrêter afin de 
procéder à un contrôle plus poussé.  
Le règlement (UE) n  o 165/2014 exige que les données collectées se 
limitent à celles qui identifient une infraction éventuelle ou qui s'y 
apportent, conformément à l'article 9 du règlement (UE) n  o 165/2014.  
▼M1 
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 à courte portée. Par 
ailleurs, les autorités de contrôle compétentes peuvent utiliser les 
moyens de communication assurant le contrôle à distance des tachy ­
graphes (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 tachygraphes ou consécutives à celui-ci, à la discrétion des autorités 
de contrôle compétentes.  
▼B 
Le présent appendice spécifie:  
— 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échargement et la séquence des 
opérations.  
— Les données  à transférer.  
— L'interprétation potentielle  des données  transmises via  la communi ­
cation . 
— Les dispositions relatives aux données de sécurité liées à  la commu ­
nication . 
— La mise à disposition  des données  aux autorités de contrôle compé ­
tentes.  
— La façon dont le  lecteur de communication à distance à des fins de 
détection précoce  (REDCR) peut demander plusieurs concepts de 
données relatifs au fret et à la flotte.  
Pour plus de précision, le présent appendice ne spécifie pas:  
— La collecte et la gestion des  données  dans la VU (qui dépendent de 
la conception du produit sauf mention contraire dans le règlement 
(UE) n  o 165/2014).  
— La forme de présentation des données collectées à l'agent des auto ­
rités de contrôle compétentes ou les critères utilisés par celles-ci pour 
décider quel véhicule arrêter (qui dépendent de la conception du 
produit, sauf s'il y est fait mention ailleurs dans le règlement (UE) 
n o 165/2014 ou dans une décision des autorités de contrôle compé ­
tentes). Par souci de précision:  la communication  se limite à mettre  
les données  à la disposition des autorités de contrôle compétentes 
afin qu'elles puissent prendre des décisions éclairées.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 488  
— Les dispositions relatives à la sécurité des données (telles que le 
cryptage) concernant le contenu  des données  (spécifiées à l'appen ­
dice 11 Mécanismes communs de sécurité).  
— Le détail de tous les concepts de données autres que RTM pouvant 
être obtenus à l'aide de la même architecture et du même équipe ­
ment.  
— Les détails du comportement et de la gestion entre la VU et la 
DSRC-VU ou le comportement au sein de la DSRC-VU (autre 
que dans le but de fournir les  données  en réponse à la demande 
d'un REDCR).  
3 ABRÉVIATIONS, DÉFINITIONS ET NOTATIONS  
Dans le présent appendice, sont utilisées les abréviations et définitions 
suivantes:  
Antenne  Dispositif électrique qui convertit 
l'énergie électrique en ondes radio 
et inversement, utilisé avec un émet ­
teur ou un récepteur radio. En fonc ­
tionnement, un émetteur radio 
fournit un courant électrique oscil ­
lant à une fréquence radio aux 
bornes de l'antenne. L'antenne 
rayonne et émet l'énergie du 
courant électrique sous forme 
d'ondes électromagnétiques (ondes 
radio). En mode réception, une 
antenne capte une part de l'énergie 
émise par une onde électromagné ­
tique pour produire une tension très 
faible à ses bornes, qu'amplifie un 
récepteur.  
Communication  Échange d'informations et de 
données entre un DSRC-REDCR et 
une DSRC-VU conformément à la 
section 5 et selon une relation 
maître-esclave en vue d'obtenir les 
données.  
Données  Données sécurisées adoptant une 
structure définie (cf. 5.4.4) deman ­
dées par le  DSRC-REDCR  et four­
nies par la  DSRC-VU  à l'aide d'une 
liaison DSRC sur la bande de 
5,8 GHz, comme défini au point 5 
ci-après.  
Règlement (UE) n  o 165/2014  Règlement (UE) n  o 165/2014 du 
Parlement Européen et du Conseil 
du 4 février 2014 relatif aux tachy ­
graphes dans les transports routiers,  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 489  
abrogeant le règlement (CEE) 
n o 3821/85 du Conseil concernant 
l'appareil de contrôle dans le 
domaine des transports par route et 
modifiant le règlement (CE) 
n o 561/2006 du Parlement européen 
et du Conseil relatif à l'harmonisa ­
tion de certaines dispositions de la 
législation sociale dans le domaine 
des transports par route.  
AID Identificateur d'application  
BLE  Bluetooth Low Energy  
BST  Table de service de balise (Beacon 
Service Table)  
CIWD  Insertion d'une carte en cours de 
conduite  
CRC  Contrôle de redondance cyclique  
DSC (n)  Identificateur d'une exigence pour 
un appendice DSRC donné  
DSRC  communication spécialisée à courte 
portée  
DSRC-REDCR  Lecteur de communication à 
distance à des fins de détection 
précoce DSRC  
DSRC-VU  Unité embarquée sur le véhicule 
DSRC Il s'agit du «dispositif de 
détection précoce à distance» défini 
à l'annexe 1C.  
DWVC  Conduite sans carte en cours de vali ­
dité 
EID Identificateur d'élément  
LLC  Contrôle de liaison logique  
LPDU  Unité de données de protocole LLC  
OWS  Système de pesage embarqué  
PDU  Unité de données de protocole  
REDCR  Lecteur de communication à 
distance à des fins de détection 
précoce. Il s'agit du «lecteur de 
communication à distance à des 
fins de détection précoce» défini à 
l'annexe 1C.  
RTM  Contrôle à distance du tachygraphe  
SM-REDCR  Lecteur de communication à 
distance à des fins de détection 
précoce, module de sécurité  
TARV  Applications télématiques collabora ­
tives pour véhicules de fret commer ­
cial réglementé (série de normes 
ISO 15638)  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 490  
VU Unité embarquée sur le véhicule  
VUPM  Mémoire utile de la VU  
VUSM  Module de sécurité de la VU  
VST  Table de service de véhicule  
WIM  Poids en mouvement  
WOB  Poids à bord  
La spécification définie au présent appendice renvoie 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 
conflit, les dispositions du présent appendice prévalent. En cas de conflit 
qu'aucune spécification du présent appendice ne résout, le fonctionne ­
ment conformé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) n  o 165/2014 du Parlement européen et du Conseil 
du 4 février 2014 relatif aux tachygraphes dans les transports 
routiers, abrogeant le règlement (CEE) n  o 3821/85 du Conseil 
concernant l'appareil de contrôle dans le domaine des transports 
par route et modifiant le règlement (CE) n  o 561/2006 du Parlement 
européen et du Conseil relatif à l'harmonisation de certaines dispo ­
sitions de la législation sociale dans le domaine des transports par 
route.  
[2] Règlement (UE) n  o 561/2006 du Parlement européen et du Conseil 
du 15 mars 2006 relatif à l'harmonisation de certaines dispositions 
de la législation sociale dans le domaine des transports par route, 
modifiant les règlements (CEE) n  o 3821/85 et (CE) n  o 2135/98 du 
Conseil et abrogeant le règlement (CEE) n  o 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'utili ­
sation des dispositifs à courte portée (DCP).  
[4] Norme ISO 15638 Intelligent transport systems — Framework for 
cooperative telematics applications for regulated commercial freight 
vehicles (TARV).  
[5] Norme EN 300 674-1 Electromagnetic compatibility and Radio 
spectrum Matters (ERM); Road Transport and Traffic Telematics 
(RTTT); Dedicated Short Range Communication (DSRC) transmis ­
sion equipment (500 kbit/s / 250 kbit/s) operating in the 5,8 GHz 
Industrial, Scientific and Medical (ISM) band; Part 1: General 
characteristics and test methods for Road Side Units (RSU) and 
On-Board Units (OBU).  
[6] Norme EN 12253 Road transport and traffic telematics — Dedi ­
cated short-range communication — Physical layer using micro ­
wave at 5.8 GHz..  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 491  
[7] Norme EN 12795 Road transport and traffic telematics — Dedi ­
cated short-range communication — Data link layer: medium 
access and logical link control.  
[8] Norme EN 12834 Road transport and traffic telematics — Dedi ­
cated short-range communication — Application layer.  
[9] Norme EN 13372 Road transport and traffic telematics — Dedi ­
cated short-range communication — Profiles for RTTT applications  
[10] Norme ISO 14906 Electronic fee collection — Application inter ­
face definition for dedicated short- range communication  
4 CAS DE FIGURE OPÉRATIONNELS  
4.1 Vue d'ensemble  
Le règlement (UE) n  o 165/2014 prévoit des cas de figure spécifiques et 
contrôlés encadrant  la communication . 
Les scénarios pris en charge sont les suivants:  
«Profil de communication 1: contrôle routier utilisant un lecteur de 
communication à distance à des fins de détection précoce, sans fil et 
à courte portée afin de procéder à des contrôles routiers physiques 
(maître/esclave)  
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é temporairement 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 transfert de données au moyen de l'inter ­
face DSRC 5,8 GHz  
NOTE: pour comprendre le contexte 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émorisation 
des données qu'elle stocke selon une fréquence de 60 secondes 
sans impliquer la fonction de communication DSRC. Les 
moyens pour y parvenir sont internes à la VU, spécifiés par 
le règlement (UE) n  o 165/2014, annexe 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.  
4.1.1.2 Données communiquées au dispositif DSRC-VU  
DSC_13 La VU est responsable de l'actualisation des données tachygra ­
phiques DSRC ( les données ) dès lors qu'elle actualise les 
données qu'elle stocke selon une fréquence définie à la 
section 4.1.1.1 (DSC_12), sans impliquer la fonction de 
communication DSRC.  
DSC_14 Les données de la VU sont utilisées comme base d'alimenta ­
tion et d'actualisation des  données . Les moyens pour y 
parvenir sont précisés dans l'annexe 1C, section 3.19 « Commu­
nication à distance pour les contrôles routiers ciblés ». En 
l'absence de précision, ces moyens dépendent de la conception 
du produit et ne sont pas décrits dans le présent appendice. En 
ce qui concerne la conception de la connexion entre le dispo ­
sitif DSRC-VU et la VU, consulter la section 5.6.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 492  
4.1.1.3 Contenu des données  
DSC_15 Le contenu et la structure des  données  sont tels qu'une fois 
décrypté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 conformément aux 
procédures définies à la section 4.1.1.1, sont sécurisées avant 
d'être présentées à la  VU-DSRC , sont présentées comme une 
valeur de concept de données sécurisées et enfin stocké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 DSRC  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 conception de produit, sauf indication dans une autre partie 
du règlement UE n  o 165/2014 . 
4.1.1.5 Données de sécurité  
DSC 17 Les données de sécurité ( securityData ), comprenant les 
données requises par le  REDCR  pour décrypter les  données , 
sont communiquées conformément à l'appendice 11 Méca ­
nismes communs de sécurité et sont présentées comme une 
valeur de concept de données en vue de leur stockage tempo ­
raire dans la  DSRC-VU  comme étant la version actuelle des  
securityData , selon la structure définie par le présent appen ­
dice, section 5.4.4.  
4.1.1.6 Données VUPM disponibles pour le transfert à l'aide de l'interface 
DSRC  
DSC 18 Le concept de données qui doit toujours être disponible dans la 
fonction DSRC VUPM en vue de son transfert 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 profil de communication n  o 1 
Ce profil couvre le cas de figure dans lequel un agent des autorités de 
contrôle compétentes utilise un lecteur de communication à distance à 
des fins de détection précoce à courte portée (interfaces DSRC 5,8 GHz 
fonctionnant conformément à la recommandation ERC 70-03 et testées 
selon les paramètres pertinents de la norme EN 300 674-1 comme décrit 
à la section 5) (le  REDCR ) pour identifier un véhicule en infraction 
potentielle au règlement (UE) n  o 165/2014. Une fois le véhicule identi ­
fié, l'agent 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é 
temporairement en bord de route  
Dans ce cas de figure, l'agent des autorités de contrôle compétentes 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-brise du véhicule ciblé. L'inter ­
rogation utilise les interfaces DSRC 5,8 GHz fonctionnant conformément 
à la recommandation ERC 70-03 et testées selon les paramètres perti ­
nents de la norme EN 300 674-1, décrite à la section 5. Cf. figure 14.1 
(cas de figure n  o 1). ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 493  
Figure 14.1  
Interrogation en bord de route avec DSRC 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éhicule  
Dans ce cas, l'agent des autorités de contrôle compétentes 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-brise 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-brise du véhicule ciblé lorsque le 
véhicule à bord duquel se trouve le REDCR est dans une position 
particulière par rapport au véhicule ciblé (par exemple directement en 
amont dans un flux de circulation). L'interrogation utilise les interfaces 
DSRC 5,8 GHz fonctionnant conformément à la recommandation ERC 
70-03 et testées selon les paramètres pertinents de la norme EN 300 674- 
1, décrite à la section 5. Cf. figure 14.2. (Cas de figure n  o 2). 
Figure 14.2  
Interrogation depuis un véhicule avec DSRC 5,8 GHz
  
4.2 Sécurité/Intégrité  
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écurisées font l'objet d'une vérification et d'un décryptage 
conformément à l'appendice 11 Mécanismes communs de sécurité.  
5 CONCEPTION ET PROTOCOLES DE LA COMMUNICATION À 
DISTANCE  
5.1 Conception  
La conception de la fonction de communication à distance du tachy ­
graphe intelligent est illustrée à la figure 14.3.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 494  
Figure 14.3  
Conception de la fonction de communication à distance
  
DSC_19 Les fonctions suivantes sont situées dans la VU:  
— Module de sécurité ( VUSM ). Cette fonction présente dans 
la VU est responsable de la sécurisation des  données  à 
transmettre depuis la  DSRC-VU  à l'agent des autorités de 
contrôle compétentes par communication à distance.  
— Les données sécurisées sont enregistrées dans la mémoire 
VUSM. La section 4.1.1.1 (DSC_12) prévoit la fréquence 
à laquelle la VU crypte et renouvelle le concept RTMdata 
(qui inclut les valeurs de concept des données utiles et des 
données de sécurité déterminées ci-après au présent appen ­
dice) détenu dans la mémoire de la DSRC-VU. L'exploi ­
tation du module de sécurité est définie à l'appendice 11 
Mécanismes communs de sécurité et est exclue de la portée 
du présent appendice, hormis le fait que toute modification 
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 DSRC-VU peut être 
filaire ou de type Bluetooth Low Energy (BLE). La DSRC- 
VU peut soit être intégrée physiquement sur le pare-brise 
du véhicule avec l'antenne, soit être interne à la VU, soit 
être située à tout point intermédiaire.  
— La DSRC-VU dispose d'une source d'alimentation élec ­
trique fiable à tout moment. Les moyens d'alimentation 
relèvent de la décision conceptuelle.  
— La mémoire de la DSRC-VU est non volatile, afin de 
préserver les données dans la DSRC-VU y compris 
lorsque le contact du véhicule est coupé.  
— Si la communication entre la VU et la DSRC-VU s'établit par 
BLE et que l'alimentation provient d'une batterie non rechar ­
geable, l'alimentation de la DSRC-VU doit être remplacée 
lors de chaque inspection périodique. En outre, il incombe  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 495  
au fabricant de la DSRC-VU de vérifier que l'alimentation 
électrique perdure d'une inspection périodique à l'autre. Il 
doit maintenir l'accès normal aux données au moyen d'un 
REDCR durant toute la période sans anomalie ni interrup ­
tion. 
— Dispositif de «mémoire utile» RTM VU ( VUPM ). Il 
incombe à cette fonction présente dans la VU de fournir 
et d'actualiser  les données.  Le contenu des  données  («Ta­
chographPayload») 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).  
— DSRC-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 DSRC 5,8 GHz. Toute déconnexion 
du dispositif DSRC ou interférence avec le fonctionnement 
de celui-ci pendant l'exploitation normale du véhicule 
constitue une infraction au règlement (UE) n  o 165/2014.  
— Le module de sécurité (REDCR) ( SM-REDCR ) désigne la 
fonction servant à décrypter 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écurité. Ils ne sont pas précisés au présent appendice.  
— La fonction du dispositif DSRC (REDCR) ( DSRC- 
REDCR ) inclut un émetteur-récepteur de 5,8 GHz ainsi 
que le progiciel et le logiciel associés qui gèrent  la commu ­
nication  avec la  DSRC-VU  conformé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 
DSRC et enregistre les données reçues dans son  SM- 
REDCR.  
▼M1 
— L’antenne DSRC-VU est placée de manière à optimiser la 
communication DSRC entre le véhicule et l’antenne de 
lecture en bord de route, lorsque le lecteur se trouve à 
une distance de 15 mètres devant le véhicule et à 2 
mètres de hauteur, en ciblant le centre horizontal et vertical 
du pare-brise. Pour les véhicules légers, une installation sur 
la partie supérieure du pare-brise convient. Pour tous les 
autres véhicules, l’antenne DSRC est placée près de la 
partie inférieure ou de la partie supérieure du pare-brise.  
▼B 
DSC_20 L'antenne et la communication fonctionnent conformément à la 
recommandation ERC 70-03 et sont testées selon les paramè ­
tres pertinents de la norme EN 300 674-1, comme décrit à la 
section 5. L'antenne et la communication peuvent mettre en 
œuvre des techniques d'atténuation contre le risque d'inter ­
férence sans fil comme décrit au rapport ECC 228, en utilisant 
notamment des filtres dans la communication CEN DSRC 
5,8 GHz.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 496  
DSC_21 L'antenne DSRC est connectée à la DSRC-VU soit directement 
au sein du module installé sur ou à proximité du pare-brise, 
soit à l'aide d'un câble spécialement conçu pour rendre difficile 
toute déconnexion illégale. Toute déconnexion de l'antenne ou 
interférence avec son fonctionnement constitue une infraction 
au règlement (UE) n  o 165/2014. Le masquage délibéré ou tout 
autre agissement qui nuit à la performance opérationnelle de 
l'antenne constitue une infraction au règlement (UE) 
n o 165/2014.  
DSC_22  ►M1 Le format de l’antenne n’est pas défini et demeure une 
décision commerciale, à condition que la DSRC-VU installée 
satisfasse aux exigences de conformité définies à la section 5 
ci-dessous. L’antenne est positionnée comme défini au point 
DSC_19 et elle prend efficacement en charge les cas d’usage 
décrits en 4.1.2 et en 4.1.3. ◄ 
Figure 14.4  
Exemple de positionnement de l'antenne DSRC 5,8 GHz sur le pare- 
brise 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 adopté par l'agent des autorités de 
contrôle compétentes.  
Une fonction d'affichage et/ou de notification sert à présenter les résul ­
tats de la fonction de communication à distance à l'agent des autorités de 
contrôle compétentes. Il est possible de disposer d'un affichage sur écran 
ou sous forme imprimée, d'un signal audio ou d'une combinaison de ces 
notifications. La forme de cet affichage et/ou de cette notification 
dépend des exigences des agents des autorités de contrôle compétentes 
et de la conception de l'équipement. Elle n'est pas spécifiée au présent 
appendice.  
DSC_23 La conception et le format du  REDCR  dépendent de la concep ­
tion commerciale dans le cadre de la recommandation ERC 
70-03 et des spécifications de conception et de performance 
définies au présent appendice (5.3.2). Le marché dispose de 
fait d'une souplesse optimale pour concevoir et fournir les  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 497  
équipements nécessaires dans le but de répondre à l'ensemble 
des cas de figure d'interrogation propres à toute autorité de 
contrôle compétente.  
DSC_24 La conception et le format de la  DSRC-VU  et son positionne ­
ment à l'intérieur ou à l'extérieur de la VU varient selon la 
conception commerciale, dans le cadre de la recommandation 
ERC 70-03, et selon les spécifications de conception et de 
performance 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'accepter les valeurs de concept 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 protocoles ouverts et normalisés, pourvu que de tels 
concepts de données soient identifiés par des identificateurs/ 
noms de dossiers d'application connus et uniques et à condi ­
tion que les instructions d'exploitation desdits protocoles soient 
mises à la disposition de la Commission européenne et dispo ­
nibles sans frais pour les fabricants des équipements pertinents.  
5.2 Déroulement des opérations  
5.2.1  Opérations  
Le déroulement des opérations est illustré sur la figure 14.5.  
Figure 14.5  
Déroulement des opérations de la fonction de communication à 
distance
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 498  
Les étapes sont décrites ci-après:  
a. Dès lors que le véhicule est en marche (mis sous contact), le tachy ­
graphe 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émorisé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.  
b. À chaque fois que  les données  sont actualisées, le timbre horodateur 
défini dans le concept de données de sécurité doit être actualisé.  
c. La fonction  VUSM  protège les données conformé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 toutes les 
données antérieures afin que les données actualisées ( les données ) 
demeurent toujours disponibles en cas d'interrogation 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'identificateur d'application et les identificateurs d'attribut.  
e. Si un agent des autorités de contrôle compétentes souhaite cibler un 
véhicule et recueillir  les données  émanant du véhicule ciblé, l'agent 
des autorités de contrôle compétentes insère d'abord sa carte intelli ­
gente dans  le REDCR  pour établir  la communication  et permettre au  
SM-REDCR  de vérifier son authenticité et de décrypter les données.  
f. L'agent des autorités de contrôle compétentes vise ensuite un véhicule 
et procède à la demande de données par l'intermédiaire de la commu ­
nication à distance.  Le REDCR  ouvre une session d'interface DSRC 
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'attribut DSRC utilisant 
le service d'application GET, comme défini à la section 5.4. L'attribut 
contient les valeurs de données utiles chiffrées et les données rela ­
tives à la sécurité DSRC.  
g. Le  REDCR  procède à l'analyse des données qui sont ensuite commu ­
niquées à l'agent des autorités de contrôle compétentes.  
h. L'agent des autorités de contrôle compétentes utilise les données pour 
prendre la décision d'arrêter ou non le véhicule en vue d'une inspec ­
tion plus détaillée ou pour demander à un autre agent des autorités de 
contrôle compétentes d'intercepter le véhicule.  
5.2.2  Interpré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 signi ­
fication 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. Conformément aux 
dispositions du règlement (UE) n  o 165/2014,  les données  
servent uniquement à fournir les informations pertinentes à 
une autorité de contrôle compétente pour l'aider à déterminer  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 499  
quel véhicule intercepter pour un contrôle physique et sont 
détruites par la suite conformément à l'article 9 du règlement 
(UE) n  o 165/2014.  
5.3 Paramètres de l'interface DSRC physique pour la communication à 
distance  
5.3.1  Contraintes d'emplacement  
DSC_27 L'interrogation à distance de véhicules avec l'interface DSRC 
5,8 GHz ne doit pas se faire dans un rayon de 200 mètres 
autour d'un portique DSRC 5,8 GHz opérationnel.  
5.3.2  Paramètres de liaisons descendante et montante  
DSC_28 L'équipement servant au contrôle du tachygraphe à distance 
doit être conforme à la recommandation ERC 70-03 et fonc ­
tionner selon celle-ci. Il doit également satisfaire aux paramè ­
tres définis aux tableaux 14.1 et 14.2 ci-dessous.  
DSC_29 Par ailleurs, pour garantir la compatibilité avec les paramètres 
opérationnels d'autres systèmes DSRC 5,8 GHz normalisés, 
l'équipement utilisé pour le contrôle du tachygraphe à distance 
doit être conforme 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 possibilités: 
5,7975 GHz 
5,8025 GHz 
5,8075 GHz 
5,8125 GHz  Dans les limites de ERC 70-03. 
Les fréquences porteuses peuvent 
être sélectionnées par le respon ­
sable de la mise en œuvre du 
système de contrôle routier, et ne 
doivent pas être connues au 
niveau de la DSRC-VU 
(conforme à EN 12253, EN 13372)  
D1a (*) Tolérance de fréquence des 
porteuses  ± 5 ppm  (conforme à EN 12253)  
D2 (*) Masque spectral d'émission 
de la RSU (REDCR)  Dans les limites de ERC 
70-03. 
Le REDCR doit corres ­
pondre à la classe B,C 
telle que définie dans la 
norme EN 12253. 
Pas d'autre exigence spéci ­
fique dans la présente 
annexe  Paramètre utilisé pour maîtriser les 
interférences entre interrogateurs à 
proximité (comme défini dans les 
normes EN 12253 et EN 13372).  
D3 Gamme de fréquences mini ­
male OBU(DSRC-VU)  5,795 — 5,815 GHz  (conforme à 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  (conforme à EN 12253)  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 500  
Point  Paramètre  Valeur(s)  Remarque  
D4a Masque angulaire p.i.r.e.  Conformément à la spécifi ­
cation déclarée et publiée 
du concepteur de l'inter ­
rogateur  (conforme à EN 12253)  
D5 Polarisation  Circulaire anti-horaire  (conforme à EN 12253)  
D5a Polarisation croisée  XPD: 
Dans l'axe de visée: 
(REDCR) RSU t ≥ 15 dB 
(DSRC-VU) OBU r ≥ 
10 dB 
Dans la zone – 3 dB: 
(REDCR) RSU t ≥ 10 dB 
(DSRC-VU) OBU r ≥ 6 dB  (conforme à EN 12253)  
D6 (*) Modulation  Modulation d'amplitude à 
deux niveaux  (conforme à EN 12253)  
D6a (*) Indice de modulation  0,5 … 0,9  (conforme à EN 12253)  
D6b Diagramme de l'œil  ≥ 90 % (temps)/ ≥ 85 % 
(amplitude)  
D7 (*) Codage de données  FM0 
Le bit ‘1’ ne présente de 
transitions qu'au début et à 
la fin de l'intervalle du bit. 
Le bit ‘0’ présente une tran ­
sition supplémentaire au 
milieu de l'intervalle du bit 
par rapport au bit ‘1’.  (conforme à EN 12253)  
D8 (*) Débit binaire  500 kBit/s  (conforme à EN 12253)  
D8a Tolérance de l'horloge bit  mieux que ± 100 ppm  (conforme à EN 12253)  
D9 (*) Taux d'erreur binaire 
(B.E.R.) pour la communi ­
cation  ≤ 10 – 6 si la puissance inci ­
dente à l'OBU (DSRC-VU) 
se situe dans la plage 
donnée par [D11a à D11b].  (conforme à EN 12253)  
D10 Signal déclenchant le réveil 
de l'OBU (DSRC-VU)  L'OBU (DSRC-VU) est 
réveillé à la réception 
d'une trame comportant 11 
octets ou plus (préambule 
compris)  Aucune structure particulière n'est 
nécessaire pour le signal de réveil. 
La DSRC-VU peut s'éveiller à la 
réception d'une trame comportant 
moins de 11 octets 
(conforme à EN 12253)  
D10a  Temps de démarrage maxi ­
mal ≤ 5 ms  (conforme à EN 12253)  
D11 Zone de communication  Région spatiale dans 
laquelle un B.E.R. 
conforme à D9a est atteint  (conforme à EN 12253)  
D11a  (*) Limite de puissance (supé ­
rieure) pour la communica ­
tion. – 24dBm  (conforme à EN 12253)  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 501  
Point  Paramètre  Valeur(s)  Remarque  
D11b  (*) Limite de puissance (infé ­
rieure) pour la communica ­
tion. Puissance incidente: 
– 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 DSRC-VU est installée 
ultérieurement dans le véhi ­
cule (Azimuth))  (conforme à EN 12253) 
Exigence supérieure pour des 
angles horizontaux jusqu'à ±45°, 
compte tenu des cas de figure 
définis dans la présente annexe.  
D12 (*) Niveau de puissance de 
coupure de (DSRC-VU)  – 60 dBm  (conforme à EN 12253)  
D13 Préambule  Préambule obligatoire.  (conforme à EN 12253)  
D13a  Longueur et structure du 
préambule  16 bits — 1 bit ‘1’ codé en 
FM0  (conforme à EN 12253)  
D13b  Forme d'onde du préambule  Séquence alternant les 
niveaux faible et élevé, 
avec une durée d'impulsion 
de 2 μs. 
La tolérance est donnée par 
D8a (conforme à EN 12253)  
D13c  Bits non significatifs  La RSU (REDCR) peut 
émettre au maximum 8 bits 
après le drapeau de fin. Un 
OBU (DSRC-VU) n'est pas 
tenu de tenir compte de ces 
bits supplémentaires.  (conforme à EN 12253)  
(*) – Paramètres de liaison descendante soumis à des essais de conformité selon l'essai de paramétrage pertinent prévu par la n orme EN 
300 674-1  
Tableau 14.2  
Paramètres de liaison montante  
Point  Paramètre  Valeur(s)  Remarque  
U1 (*) Fréquences sous-porteuses  Un OBU (DSRC-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- 
porteuse 
(1,5 MHz ou 2,0 MHz) dépend du 
profil EN 13372 choisi.  
U1a (*) Tolérance de fréquence des 
sous-porteuses  ± 0,1 %  (conforme à EN 12253)  
U1b Utilisation de bandes latéra ­
les Mêmes données des deux 
côtés  (conforme à EN 12253)  
U2 (*) Masque spectral d'émission 
de l'OBU (DSRC-VU)  conformément à EN12253 
1) Puissance hors bande: 
voir ETSI EN 300674-1  (conforme à EN 12253)  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 502  
Point  Paramètre  Valeur(s)  Remarque  
2) Puissance dans la bande: 
[U4a] dBm à 500 kHz 
3) Émission dans toute 
autre voie montante: 
U2(3)-1 = – 35 dBm à 
500 kHz  
U4a (*) P.I.R.E. maximale — bande 
latérale unique (axe de 
visée)  Deux options: 
U4a-0: – 14 dBm 
U4a-1: – 21 dBm  Conformément à la spécification 
déclarée et publiée du concepteur 
de l'équipement  
U4b (*) P.I.R.E. maximale — bande 
latérale unique (35°)  Deux options: 
— Non applicable 
— – 17dBm  Conformément à la spécification 
déclarée et publiée du concepteur 
de l'équipement  
U5 Polarisation  Circulaire anti-horaire  (conforme à EN 12253)  
U5a Polarisation croisée  XPD: 
Dans l'axe de visée: 
(REDCR) RSU r ≥ 15 dB 
(DSRC-VU) OBU t ≥ 
10 dB 
À – 3 dB: (REDCR) RSU r 
≥ 10 dB 
(DSRC-VU) OBU t ≥ 6 dB  (conforme à EN 12253)  
U6 Modulation de sous- 
porteuse  2-PSK 
Données codées synchroni ­
sées avec la sous-porteuse: 
les transitions des données 
codées coïncident avec les 
transitions de la sous- 
porteuse.  (conforme à EN 12253)  
U6b Cycle de fonctionnement  Cycle de fonctionnement: 
50 % ± α, α ≤ 5 %  (conforme à EN 12253)  
U6c Modulation sur porteuse  Multiplication de sous- 
porteuse modulée par la 
porteuse.  (conforme à 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) (conforme à EN 12253)  
U8 (*) Débit binaire  250 kbit/s  (conforme à EN 12253)  
U8a Tolérance de l'horloge bit  ± 1 000 ppm  (conforme à EN 12253)  
U9 Taux d'erreur binaire 
(B.E.R.) pour la communi ­
cation  ≤ 10  – 6 (conforme à EN 12253)  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 503  
Point  Paramètre  Valeur(s)  Remarque  
U11 Zone de communication  La région spatiale dans 
laquelle se situe la DSRC- 
VU, telle que ses émissions 
soient reçues par le REDCR 
avec un B.E.R. inférieur à 
celui indiqué par U9a.  (conforme à EN 12253)  
U12a  (*) Gain de conversion (limite 
inférieure)  1 dB pour chaque bande 
latérale 
Plage angulaire: circulaire ­
ment symétrique entre l'axe 
de visée et ± 35°  
et dans la plage – 45° — + 
45° Correspondant au plan 
parallèle à la surface de la 
route, lorsque la DSRC-VU 
est installée ultérieurement 
dans le véhicule (Azimuth)  Supérieur à la plage de valeurs 
spécifiée pour des angles horizon ­
taux jusqu'à ± 45°, compte tenu des 
cas de figure définis dans la 
présente annexe.  
U12b  (*) Gain de conversion (limite 
supérieure)  10 dB pour chaque bande 
latérale  Moins que la plage 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'angle d'ouverture  
U13 Préambule  Préambule obligatoire.  (conforme à EN 12253)  
U13a  Préambule 
Longueur et structure  32 à 36 μs, modulé par 
sous-porteuse uniquement, 
puis 8 bits ‘0’ en codage 
NRZI.  (conforme à EN 12253)  
U13b  Bits non significatifs  La DSRC-VU peut émettre 
au maximum 8 bits après le 
drapeau de fin. Un RSU 
(REDCR) n'est pas tenu de 
tenir compte de ces bits 
supplémentaires.  (conforme à EN 12253)  
(*) – Paramètres de liaison montante soumis à essai de conformité 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 Antenne REDCR  
DSC_30 La conception 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écifiques et pour les circonstances de 
lecture pour lesquelles le  REDCR  a été conçu pour fonction ­
ner. 
5.3.3.2 Antenne VU  
DSC_31 La conception de l'antenne  DSRC-VU  dépend de la concep ­
tion 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écifiques et pour les circonstances de 
lecture pour lesquelles le  REDCR  a été conçu pour fonction ­
ner. ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 504  
DSC_32 L'antenne VU est fixée sur le pare-brise 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 DSRC-VU, installée selon la section 5.1, doit pouvoir 
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 interroga ­
tions en lecture.  
5.4 Exigences du protocole DSRC pour RTM  
5.4.1  Vue d'ensemble  
DSC_34 Le protocole de transaction pour télécharger  les données  au 
moyen de la liaison d'interface DSRC 5,8 GHz respecte les 
étapes suivantes. La présente section décrit un flux de trans ­
action dans les conditions idéales sans retransmission ou 
interruption de la communication.  
NOTE: l'objectif de l'étape d'initialisation (Étape 1) est d'éta ­
blir la communication entre le  REDCR  et les DSRC-VU 
présentes dans la zone de transaction (maître-esclave) DSRC 
à 5,8 GHz, mais qui n'ont pas encore établi de communication 
avec le  REDCR , puis d'en avertir les processus d'application.  
— Étape 1  Initialisation. Le  REDCR  envoie une trame 
contenant une «table de service de balise» (BST) qui 
inclut les identificateurs 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 DSRC-VU ne 
répond pas au REDCR.  
— Étape 2  La DSRC-VU  envoie une trame contenant une 
demande pour une allocation de fenêtre privée.  
— Étape 3  Le REDCR  envoie une trame contenant une 
allocation de fenêtre privée.  
— Étape 4  La DSRC-VU  utilise cette fenêtre privée allouée 
pour envoyer une trame contenant sa table de service de 
véhicule (VST). Cette VST comprend la liste de toutes les 
instanciations d'applications différentes prises en charge 
par cette  DSRC-VU  dans le cadre d'une valeur AID = 
2. Les différentes instanciations sont identifiées au 
moyen d'EID générés de manière exclusive. Chacun est 
associé à une valeur de paramètres «marque de contexte 
d'application» indiquant la norme et l'application prises en 
charge.  
— Étape 5  Ensuite 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 instancia ­
tion d'application, s'il reçoit une VST appropriée.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 505  
— Étape 6  À cette fin, le REDCR envoie une trame conte ­
nant une commande pour extraire les données RTM en 
identifiant l'instanciation de l'application RTM par la 
spécification de son identificateur (tel qu'indiqué par la 
DSRC-VU dans la VST) avant d'allouer une fenêtre 
privée.  
— Étape 7  La DSRC-VU  utilise la fenêtre privée qui vient 
d'être allouée pour envoyer une trame qui contient l'iden ­
tificateur adressé correspondant à l'instanciation de l'ap ­
plication RTM tel que fourni dans la VST, suivi de l'at ­
tribut  RtmData  (élément de données utiles + élément de 
sécurité).  
— Étape 8  Si 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 9  Le REDCR  confirme la réception 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éception du 
LDPU, elle revient à l'étape 6.  
Cf. figure 14.6 pour une illustration du protocole de trans ­
action.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 506  
Figure 14.6  
Déroulement d'une procédure RTM via DSRC à 5,8 GHz
  
5.4.2  Commandes  
DSC_35 Les commandes suivantes sont les seules fonctions utilisées 
dans une phase de transaction RTM  
— INITIALISATION.request : commande émanant du 
REDCR sous la forme d'une diffusion avec la définition 
des applications prises en charge par le REDCR.  
— INITIALISATION.response : réponse émanant de la 
DSRC-VU confirmant la connexion et contenant la liste 
des instances d'application prises en charge, avec les 
caractéristiques et les informations relatives à la façon 
de les adresser (EID).  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 507  
— GET.request : commande émanant du  REDCR  et envoyée 
à la DSRC-VU  spécifiant l'instanciation de l'application à 
adresser au moyen d'un EID défini, tel que reçu dans la 
VST, donnant instructions à la  DSRC-VU  d'envoyer l'at ­
tribut ou les attributs sélectionnés avec  les données . L'ob­
jectif 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.request ECHO : commande donnant instruc ­
tion à la  DSRC-VU  de renvoyer les données de la  
DSRC-VU  au REDCR . L'objectif de la commande 
ECHO est de permettre aux ateliers ou aux infrastructures 
d'essai d'homologation de vérifier que la liaison DSRC 
fonctionne sans devoir accéder aux éléments d'authentifi ­
cation de sécurité.  
— ACTION .response ECHO: réponse de la DSRC-VU à la 
commande ECHO.  
— EVENT_REPORT.request  RELEASE: commande 
informant la  DSRC-VU que la transaction est terminée. 
L'objectif de la commande RELEASE est de mettre fin 
à la session avec la  DSRC-VU . Dès réception de 
RELEASE, la  DSRC-VU  ne répond plus à aucune inter ­
rogation dans le cadre de la connexion en cours. 
Remarque: la norme EN 12834 prévoit qu'une DSRC- 
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'interrogateur a 
changé.  
5.4.3  Séquence de commande d'interrogation  
DSC_36 Du point de vue de la séquence commande-réponse, la trans ­
action se décrit comme suit:  
Séquence  Émetteur  Récepteur  Description  Action  
1 REDCR  >  DSRC-VU  Initialisation de la 
liaison de communica ­
tion — Demande  Le REDCR diffuse la BST  
2 DSRC-VU  >  REDCR  Initialisation de la 
liaison de communica ­
tion — Réponse  Si la BST prend en charge 
AID=2 alors la DSRC-VU 
demande l'allocation d'une 
fenêtre privée  
3 REDCR  >  DSRC-VU  Alloue une fenêtre 
privée  Envoie une trame conte ­
nant une allocation de 
fenêtre privée  
4 DSRC-VU  >  REDCR  Envoie une VST  Envoie une trame conte ­
nant une VST  
5 REDCR  >  DSRC-VU  Envoie GET.request 
concernant les données 
figurant dans l'attribut 
pour l'EID spécifique  
6 DSRC-VU  >  REDCR  Envoie GET.response 
avec l'attribut demandé 
pour l'EID spécifique  Envoie l'attribut 
(RTMData, OWSData….) 
avec les données pour 
l'EID spécifique  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 508  
Séquence  Émetteur  Récepteur  Description  Action  
▼M1 
7 REDCR  >  DSRC-VU  Envoie GET.request 
concernant les données 
d’un autre attribut (si 
nécessaire)  
▼B 
8 DSRC-VU  >  REDCR  Envoie GET.response 
avec l'attribut demandé  Envoie l'attribut avec les 
données pour l'EID spécifi ­
que 
9 REDCR  >  DSRC-VU  Accuse réception des 
données  Envoie la commande 
RELEASE qui met fin à 
la transaction  
10 DSRC-VU  Met fin à la transaction  
Un exemple de la séquence de transaction et du contenu 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 emprunté l'inter ­
face DSRC 5,8 GHz doit être cohérente avec la description 
faite au présent appendice. La présente section spécifie la 
manière dont ces données sont structurées.  
DSC_38 Les données utiles (données RTM) correspondent à la conca ­
ténation des:  
1. données EncryptedTachographPayload, qui résultent du 
cryptage de TachographPayload tel que défini dans 
ASN.1 à la section 5.4.5. La méthode de cryptage fait 
l'objet d'une description à l'appendice 11.  
2. DSRCSecurityData, qui font l'objet d'une description à 
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 contexte RTM doit identifier la partie norma ­
lisée prise en charge dans la série de normes TARV (RTM 
correspond à la partie 9);  
Le module ASN.1 concernant les données DSRC dans l'ap ­
plication RTM est défini comme suit:  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 509
  
► (1) (2) (3) (4)  M1 ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 510
  
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écurisées dans la DSRC-VU sont 
calculées selon les règles prévues au tableau 14.3:  
Tableau 14.3  
Éléments de RtmData, actions effectuées et définitions  
(1) Élément de 
données RTM  (2) Action effectuée par la VU  (3)  Définition des données ASN.1  
RTM1 
Plaque d'im ­
matriculation 
du véhicule  La VU définit la valeur de l'élément de 
données RTM1  tp15638VehicleRegistration ­
Plate  provenant de la valeur enregistrée du 
type de données  VehicleRegistrationIdentifica ­
tion tel que défini à l'appendice 1  VehicleRe ­
gistrationIdentification  Plaque d'immatri ­
culation du véhi ­
cule exprimée par 
une chaîne de 
caractères
  
RTM2 
Événement 
«Excès de 
vitesse»  La VU génère une valeur booléenne pour l'élé ­
ment de données RTM2 tp15638SpeedingE ­
vent. 
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'annexe 
1C) enregistrés dans la VU au cours des 10 
derniers jours d'occurrence.  1 (TRUE) — 
Indique des irré ­
gularités de 
vitesse au cours 
des 10 derniers 
jours d'occur ­
rence
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 511  
(1) Élément de 
données RTM  (2) Action effectuée par la VU  (3)  Définition des données ASN.1  
S'il existe au moins un tp15638SpeedingEvent 
dans les 10 derniers jours d'occurrence, 
tp15638SpeedingEvent prend la valeur 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).  
RTM3 
Conduite 
sans carte 
valide  La VU génère une valeur booléenne pour l'élé ­
ment de données RTM3 tp15638DrivingWi ­
thoutValidCard. 
La VU attribue la valeur TRUE à la variable 
tp15638DrivingWithoutValidCard si les 
données de la VU ont enregistré au moins un 
événement de type «Conduite sans carte vala ­
ble» (tel que défini à l'annexe 1C) au cours des 
10 derniers jours d'occurrence. 
AUTREMENT, si aucun événement n'est 
survenu au cours des 10 derniers jours d'occur ­
rence, la variable tp15638DrivingWithoutVa ­
lidCard prend la valeur FALSE.  1 (TRUE) = 
Indique l'utilisa ­
tion d'une carte 
invalide
  
RTM4 
Carte de 
conducteur 
valide  La VU génère une valeur booléenne pour l'élé ­
ment de données RTM4 
tp15638DriverCard basée sur les données enre ­
gistrées dans la VU et conformément à l'appen ­
dice 1. 
Si aucune carte de conducteur valide n'est 
présente, la VU attribue la valeur TRUE à la 
variable. 
AUTREMENT, si une carte de conducteur 
valide est présente, la VU attribue la valeur 
FALSE à la variable.  0 (FALSE) = 
Indique une carte 
de conducteur 
valide
  
RTM5 
Insertion 
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 
tp15638CardInsertion si les données de la VU 
ont enregistré au moins un événement de type 
«Insertion d'une carte pendant la conduite» (tel 
que défini à l'annexe 1C) au cours des 10 
derniers jours d'occurrence. 
AUTREMENT si aucun événement de ce type 
n'est survenu au cours des 10 derniers jours 
d'occurrence, la variable tp15638CardInsertion 
prend la valeur FALSE.  1 
(TRUE) = Indique 
l'insertion d'une 
carte pendant la 
conduite au cours 
des 10 derniers 
jours d'occur ­
rence
  
RTM6 
Erreur de 
données de 
mouvement  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 
tp15638MotionDataError 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'annexe 1C) au cours des 10 
derniers jours d'occurrence. 
AUTREMENT, si aucun événement de ce type 
n'est survenu au cours des 10 derniers jours 
d'occurrence, la variable tp15638MotionDa ­
taError prend la valeur FALSE.  1 (TRUE) = 
Indique une 
erreur de données 
de mouvement au 
cours des 10 
derniers jours 
d'occurrence
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 512  
(1) Élément de 
données RTM  (2) Action effectuée par la VU  (3)  Définition des données ASN.1  
RTM7 
Conflit 
concernant le 
mouvement 
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 
tp15638vehicleMotionConflict si les données 
de la VU ont enregistré au moins un événe ­
ment de type «conflit concernant le mouve ­
ment du véhicule» (valeur ‘0A’H) au cours 
des 10 derniers jours d'occurrence. 
AUTREMENT, si aucun événement de ce type 
n'est survenu au cours des 10 derniers jours 
d'occurrence, la variable tp15638vehicleMo ­
tionConflict prend la valeur FALSE.  1 (TRUE) = 
Indique un 
conflit concer ­
nant le mouve ­
ment du véhicule 
au cours des 10 
derniers jours 
d'occurrence
  
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'an ­
nexe 1C («Données relatives à l'activité du 
conducteur» ÉQUIPAGE et CONVOYEUR). 
Si une deuxième carte de conducteur 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) = 
Indique qu'une 
deuxième carte 
de conducteur 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'activité autre que «CONDUITE» 
(telle que définie à l'annexe 1C), la VU 
attribue la valeur TRUE à la variable. 
AUTREMENT, si l'activité en cours est enre ­
gistrée dans la VU comme «CONDUITE», la 
VU attribue la valeur FALSE à la variable.  1 (TRUE) = autre 
activité sélection ­
née; 
0 (FALSE) = 
conduite sélec ­
tionnée
  
RTM10 
Clôture de la 
dernière 
session  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 correctement comme le prévoit l'an ­
nexe 1C, la VU attribue la valeur TRUE à la 
variable. 
AUTREMENT, si la dernière session d'une 
carte a été correctement 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 
électrique  La VU génère une valeur exprimée par un 
nombre entier pour l'élément de données 
RTM11. 
La VU affecte une valeur à la variable 
tp15638PowerSupplyInterruption égale à la 
coupure d'électricité la plus longue (conformé ­
ment aux dispositions de l'article 9 du règle ­
ment (UE) n  o 165/2014), de type «interruption 
de l'alimentation électrique» (tel que défini à 
l'annexe 1C).  — Nombre de 
coupures de 
l'alimentation 
électrique au 
cours des 10 
derniers 
jours d'oc ­
currence
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 513  
(1) Élément de 
données RTM  (2) Action effectuée par la VU  (3)  Définition des données ASN.1  
AUTREMENT, si aucun événement de type 
«interruption de l'alimentation électrique» 
n'est survenu au cours des 10 derniers jours 
d'occurrence, la variable du nombre entier 
est 0.  
▼M1 
RTM12 
Anomalie du 
capteur  La VU génère une valeur exprimé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 
capteur «35»H a été enregistré au cours 
des 10 derniers jours, 
— 2 si un événement de type anomalie du 
récepteur GNSS (interne ou externe, avec 
les valeurs enum «36»H ou «37»H) a été 
enregistré au cours des 10 derniers jours. 
— 3 si un événement de type erreur de 
communication avec le dispositif GNSS 
externe «0E»H a été enregistré au cours 
des 10 derniers jours 
— 4 si à la fois des anomalies de capteur et 
des anomalies de récepteur GNSS ont été 
enregistrées au cours des 10 derniers jours 
— 5 si à la fois des anomalies de capteur et 
des erreurs de communication avec le 
dispositif GNSS externe ont été enregis ­
trées au cours des 10 derniers jours 
— 6 si à la fois des anomalies de récepteur 
GNSS et des erreurs de communication 
avec le dispositif GNSS externe ont été 
enregistrées au cours des 10 derniers jours 
— 7 si des anomalies des trois types ont été 
enregistrées au cours des 10 derniers jours 
AUTREMENT, une valeur de 0 est attri ­
buée si aucun événement n’a été enregistré 
au cours des 10 derniers jours.  – erreur de 
capteur un 
octet confor ­
mément au 
dictionnaire 
des données
  
▼B 
RTM13 
Remise à 
l'heure  La VU génère une valeur indiquée par un 
nombre entier (timeReal 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 
concernant la remise à l'heure (telles que défi ­
nies à l'annexe 1C). 
La VU doit attribuer la valeur horaire corres ­
pondant au dernier événement de remise à 
l'heure. 
AUTREMENT, si aucun événement «remise à 
l'heure» (tel que défini à l'annexe 1C) n'est 
présent dans la VU, la valeur attribuée est 0.  Heure de la 
dernière remise à 
l'heure
  
RTM14 
Tentative 
d'infraction à 
la sécurité  La VU génère une valeur indiquée par un 
nombre entier (timeReal 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écurité (telle que définie à l'annexe 1C).  Heure de la 
dernière tentative 
d'infraction 
— Valeur par 
défaut = 
0x00FF
  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 514  
(1) Élément de 
données RTM  (2) Action effectuée par la VU  (3)  Définition des données ASN.1  
La VU doit attribuer la valeur horaire corres ­
pondant au dernier événement de tentative d'in ­
fraction à la sécurité enregistrée par la VU. 
AUTREMENT, si aucune «tentative d'infra ­
ction à la sécurité» (telle que définie à l'an ­
nexe 1C) n'est présente dans les données de 
la VU, la valeur 0x00FF est attribuée.  
RTM15 
Dernier 
étalonnage  La VU génère une valeur indiquée par un 
nombre entier (timeReal de l'appendice 1) 
pour l'élément de données RTM15, en fonction 
de la présence de données de dernier étalon ­
nage (tel que défini à l'annexe 1C). 
La VU doit attribuer la valeur temporelle des 
deux derniers étalonnages (RTM15 et RTM16), 
fixée dans VuCalibrationData comme le 
précise l'appendice 1. 
La VU attribue la valeur pour RTM15 au time ­
Real du dernier enregistrement d'étalonnage.  Heure des 
données de 
dernier étalon ­
nage
  
RTM16 
Étalonnage 
précédent  La VU génère une valeur indiquée par un 
nombre entier (timeReal de l'appendice 1) 
pour l'élément de données RTM16 de l'enregis ­
trement d'étalonnage précédant celui du dernier 
étalonnage. 
AUTREMENT, si aucun étalonnage n'a été 
effectué précédemment, la VU attribue la 
valeur 0 à RTM16.  Heure des 
données de l'éta ­
lonnage précé ­
dent
 
RTM17 
Date de 
connexion du 
tachygraphe  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'ins ­
tallation initiale de la VU. 
La VU extrait ces données des VuCalibration ­
Data (appendice 1) des vuCalibrationRecords, 
où CalibrationPurpose est égal à: ‘03’H  Date de 
connexion du 
tachygraphe
  
RTM18 
Vitesse 
actuelle  La VU génère une valeur exprimée par un 
nombre entier pour l'élément de données 
RTM18. 
La VU attribue comme valeur pour l'élément 
RTM18 la dernière vitesse actuelle enregistrée 
au moment de la dernière mise à jour des 
RtmData.  Dernière vitesse 
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 moment de la dernière mise à jour 
des RtmData.  Horodatage de 
l'enregistrement 
TachographPay ­
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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 515  
DSC_43 Pour tous les échanges DSRC, les données sont codées à 
l’aide des règles PER (Packed Encoding Rules) NON 
ALIGNÉES, à l’exception de
  et
  
, qui sont encodées à l’aide des règles 
OER (Octet Encoding Rules) définies par la norme ISO/IEC 
8825-7, Rec. ITU-T X.696.  
▼B 
5.4.7  Description détaillée de la transaction DSRC  
DSC_44 L'initialisation est conforme aux dispositions DSC_44 à 
DSC_48 et des tableaux 14.4 à 14.9. Durant la phase d'ini ­
tialisation, le REDCR commence à envoyer une trame conte ­
nant 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.  
Tableau 14.4  
Initialisation — paramétrage de la trame BST  
Champ  Paramétrage  
Link Identifier  Adresse de diffusion  
BeaconId  Conformément à EN 12834  
Time  Conformément à EN 12834  
Profile  Pas d'extension, utiliser 0 ou 1  
MandApplications  Pas d'extension, EID non 
présent, paramètre non 
présent, AID= 2 
Freight&Fleet  
NonMandApplications  Non présent  
ProfileList  Pas d'extension, nombre de 
profils dans la liste = 0  
Fragmentation header  Pas de fragmentation  
Layer 2 settings  PDU de commande, 
Commande UI  
Un exemple pratique du paramétrage indiqué au tableau 14.4 
est fourni dans le tableau 14.5 suivant, avec un exemple de 
codage binaire.  
Tableau 14.5  
Initialisation — Exemple de contenu de la trame BST
 Octet # 
Attribut/Champ  Bits dans l'octet  Description  
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  ▼M1
 02016R0799 — FR — 26.02.2020 — 002.001 — 516
 Octet # 
Attribut/Champ  Bits dans l'octet  Description  
5 Fragmentation header
  Pas de fragmentation  
6 BST
  Demande d'initialisation  
SEQUENCE {  
OPTION indicator 
BeaconID SEQUENCE { 
ManufacturerId INTEGER (0..65535)
  Applications NonMand 
non présentes
  
Identificateur 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 Profile INTEGER (0..127,...)
  Pas d'extension. Profil 
d'exemple 0  
17 MandApplications SEQUENCE 
(SIZE(0..127,...)) 
OF {
  Pas d'extension, Nombre 
mandApplications = 1  
18 SEQUENCE {  
OPTION indicator
  EID non présent  
OPTION indicator
  Paramètre non présent  
AID DSRCApplicationEntityID } }
  Pas d'extension. AID= 2 
Freight&Fleet  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 517
 Octet # 
Attribut/Champ  Bits dans l'octet  Description  
19 ProfileList SEQUENCE (0..127,...) OF 
Profile }
  Pas d'extension, nombre de 
profils 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'alloca ­
tion 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 exemple de codage binaire.  
Tableau 14.6  
Initialisation — Contenu de la trame d'une demande d'allocation de fenêtre privée
 Octet # 
Attribut/Champ  Bits dans l'octet  Description  
1 FLAG
  Drapeau de début  
2 Private LID
  Adresse de liaison de la 
DSRC-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éfinissent les normes EN 12795 et EN 13372, 7.1.1 sans 
paramétrage RTM particulier.  
Le tableau 14.7 fournit un exemple de codage binaire.  
Tableau 14.7  
Initialisation — Contenu de la trame d'allocation de fenêtre privée
 Octet # 
Attribut/Champ  Bits dans l'octet  Description  
1 FLAG
  Drapeau de début  
2 Private LID
  Adresse de liaison de la 
DSRC-VU spécifique  
3
 ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 518
 Octet # 
Attribut/Champ  Bits dans l'octet  Description  
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étrage  
Private LID  Conformé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 
contexte 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  
DSC_48 La  DSRC-VU  prend en charge l'application «Freight&Fleet», 
identifiée par l'identificateur d'application ‘2’. D'autres identi ­
ficateurs 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 appropriée est indiquée. 
Cette référence est constituée d'une marque de contexte 
RTM, elle-même composée d'un IDENTIFICATEUR 
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 DSRC-VU et associé à cette instance d'applica ­
tion. 
Un exemple pratique du paramétrage indiqué au tableau 14.8 
est fourni dans le tableau 14.9, avec une indication du codage 
binaire.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 519  
Tableau 14.9  
Initialisation — Exemple de contenu de la trame VST
 Octet # 
Attribut/Champ  Bits dans l'octet  Description  
1 FLAG
  Drapeau de début  
2 Private LID
  Adresse de liaison de la 
DSRC-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 Profile INTEGER (0..127,...) 
Applications SEQUENCE OF {
  Pas d'extension. Profil 
d'exemple 0  
11
 Pas d'extension, 1 applica ­
tion 
12 SEQUENCE {  
OPTION indicator
  EID présent  
OPTION indicator
  Paramètre présent  
AID DSRCApplicationEntityID
  Pas d'extension. AID= 2 
Freight&Fleet  
13 EID Dsrc-EID
  Défini dans le cadre de 
l'OBU et identifie l'ins ­
tance d'application.  
14 Parameter Container {
  Pas d'extension, choix de 
conteneur = 02, chaîne 
d'octet  
15
 Pas d'extension, longueur 
de marque de contexte 
RTM = 8  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 520
 Octet # 
Attribut/Champ  Bits dans l'octet  Description  
16 Rtm-ContextMark::= SEQUENCE { 
StandardIdentifier 
standardIdentifier
  ►M1 Identificateur 
d’objet de la norme, 
partie et version prise en 
charge. Exemple: ISO (1) 
Standard (0) TARV 
(15638) part9 (9) 
Version1 (1). 
Le premier octet est 06H, 
qui est l’identificateur 
d’objet. Le deuxième 
octet est 06H, qui est sa 
longueur. Les 6 octets 
suivants codent l’identifi ­
cateur d’objet de 
l’exemple. ◄ 17
 
18
 
19
 
20
 
21
 
22
 
23
 
24 ObeConfiguration Sequence {  
OPTION indicator
  ObeStatus non présent  
EquipmentClass INTEGER (0..32767)
  
25
 
26 ManufacturerId INTEGER (0..65535)
  Identificateur du fabricant 
pour la DSRC-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, conforme à 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ésentation — Paramétrage de la trame de la demande GET  
Champ  Paramétrage  
Invoker Identifier (IID)  Non présent  
Link Identifier (LID)  Adresse de liaison de la DSRC-VU 
spécifique  
Chaining  Non  
Element Identifier (EID)  Comme spécifié dans la VST. Pas 
d'extension  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 521  
Champ  Paramétrage  
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 exemple de lecture des données 
RTM.  
Tableau 14.11  
Présentation — Exemple de trame de demande GET
 Octet # 
Attribut/Champ  Bits dans l'octet  Description  
1 FLAG
  Drapeau de début  
2 Private LID
  Adresse de liaison de la 
DSRC-VU spécifique  
3
 
4
 
5
 
6 MAC Control field
  PDU de commande  
7 LLC Control field
  Commande ACn sollici ­
tée, bit n  
8 Fragmentation header
  Pas de fragmentation  
9 Get.request 
SEQUENCE {
  Demande Get  
OPTION indicator
  Éléments d'authentifica ­
tion d'accès non présents  
OPTION indicator
  IID non présent  
OPTION indicator
  AttributeIdList présent  
Fill BIT STRING(SIZE(1))
  Mis à 0.  
10 EID INTEGER(0..127,…)
  L'EID de l'instance d'ap ­
plication RTM, tel que 
spécifié dans la VST. Pas 
d'extension  
11 AttributeIdList SEQUENCE OF { 
AttributeId }}
  Pas d'extension, nombre 
d'attributs = 1  
12
 AttributeId=1, RtmData. 
Pas d'extension  
13 FCS
  Séquence de contrôle de 
trame  
14
 
15 Flag
  Drapeau de fin  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 522  
DSC_50 Lorsque la  DSRC-VU  reçoit la demande GET, elle envoie une 
réponse GET avec les données demandées conformes à 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ésentation — Paramétrage de la trame de réponse GET  
Champ  Paramétrage  
Invoker Identifier (IID)  Non présent  
Link Identifier (LID)  Conformément à EN 12834  
Chaining  Non  
Element Identifier (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 exemple de lecture des données 
RTM.  
Tableau 14.13  
Présentation — Exemple de contenu de trame de réponse
 Octet # 
Attribut/Champ  Bits dans l'octet  Description  
1 FLAG
  Drapeau de début  
2 Private LID
  Adresse de liaison de la 
DSRC-VU spécifique  
3
 
4
 
5
 
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 acceptée  
9 Fragmentation header
  Pas de fragmentation  
10 Get.response 
SEQUENCE {
  Réponse Get  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 523
 Octet # 
Attribut/Champ  Bits dans l'octet  Description  
OPTION indicator
  IID non présent  
OPTION indicator
  Liste d'attributs présente  
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'application 
RTM. 
Pas d'extension,  
12 AttributeList SEQUENCE OF {
  Pas d'extension, nombre 
d'attributs = 1  
13 Attributes SEQUENCE { 
AttributeId
  Pas d'extension, Attribu ­
teId=1 (RtmData)  
14 AttributeValue CONTAINER {
  Pas d'extension, choix de 
conteneur = 10  10 . 
15
 RtmData  
16
 
17
 
… …  
n }}}}
  
n+1 FCS
  Séquence de contrôle de 
trame  
n+2
 
n+3 Flag
  Drapeau de fin  
DSC_51 Le REDCR met alors fin à la connexion en émettant une 
commande EVENT_REPORT RELEASE conforme 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 
exemple de codage binaire de la commande RELEASE.  
Tableau 14.14  
Fin de connexion Contenu de trame de fin de connexion EVENT_REPORT
 Octet # 
Attribut/Champ  Bits dans l'octet  Description  
1 FLAG
  Drapeau de début  
2 Private LID
  Adresse de liaison de la 
DSRC-VU spécifique  
3
 
4
 ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 524
 Octet # 
Attribut/Champ  Bits dans l'octet  Description  
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_REPORT.request 
SEQUENCE {
  EVENT_REPORT 
(Release)  
OPTION indicator
  Éléments d'authentifica ­
tion 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'extension, EID = 0 
(System)  
11 EventType 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 communication.  
5.4.8  Description de la transaction d'essai DSRC  
DSC_53 Les essais exhaustifs, comprenant la sécurisation des données, 
doivent être menés conformément aux dispositions de l'appen ­
dice 11 Mécanismes communs de sécurité, par les personnes 
autorisées ayant accès aux procédures de sécurité, à l'aide de 
la commande GET normale définie ci-dessus.  
DSC_54 Les essais de mise en service et d'inspection régulière deman ­
dant le décryptage et la compréhension du contenu des 
données décryptées sont menés conformément aux disposi ­
tions de l'appendice 11 Mécanismes communs de sécurité et 
de l'appendice 9 Homologation — Liste des essais minimaux 
requis.  
Cependant, il est possible de procéder à un essai de la 
communication DSRC 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 
autorités de contrôle compétentes ou conformément aux 
dispositions du règlement (UE) n  o 165/2014 (cf. 6 ci- 
dessous).  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 525  
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 1  Le REDCR  envoie une «table de service de 
balise» (BST) contenant 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étecte 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 2  La DSRC-VU  envoie une demande d'allocation de 
fenêtre privée.  
— Étape 3 Le REDCR envoie une allocation de fenêtre 
privée.  
— Étape 4 La  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 toutes les instanciations d'ap ­
plication différentes prises en charge par cette  DSRC-VU  
dans le cadre d'une valeur AID = 2. Les différentes 
instanciations sont identifiées au moyen d'EID générés 
de manière exclusive. Chacun est associé à une valeur 
de paramètres indiquant l'instance de l'application prise 
en charge.  
— Étape 5 Ensuite  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 appropriée, de lancer une 
instanciation d'application.  
— Étape 6 Le  REDCR  émet une commande (ECHO) vers la  
DSRC-VU  spécifique et alloue une fenêtre privée.  
— Étape 7 La  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 exemple pratique de session d'échange 
ECHO.  
DSC_56 L'initialisation est effectuée conformé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 
conforme à la norme ISO 14906, contenant 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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 526  
Tableau 14.15  
Exemple de trame de demande ACTION, ECHO
 Octet # 
Attribut/Champ  Bits dans l'octet  Description  
1 FLAG
  Drapeau de début  
2 Private LID
  Adresse de liaison de la 
DSRC-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 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'extension, EID = 0 
(System)  
11 ActionType INTEGER (0..127,…)
  Pas d'extension, Type d'ac ­
tion demande ECHO  
12 ActionParameter CONTAINER {
  Pas d'extension, Choix de 
conteneur = 2  
13
 Pas d'extension. Longueur 
de chaîne = 100 octets  
14
 Données à renvoyer  
… …  
113 }}
  
114 FCS
  Séquence de contrôle de 
trame  
115
 
116 Flag
  Drapeau de fin  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 527  
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, conformément aux dispositions de la norme 
ISO 14906, sans paramétrage RTM spécifique. Le tableau 
14.16 montre un exemple de codage binaire.  
Tableau 14.16  
Exemple de trame de réponse ACTION, ECHO
 Octet # 
Attribut/Champ  Bits dans l'octet  Description  
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 
(ECHO)  
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'extension, EID = 0 
(System)  
12 ResponseParameter CONTAINER {
  Pas d'extension, Choix de 
conteneur = 2  
13
 Pas d'extension. Longueur 
de chaîne = 100 octets  
14
 Données renvoyées  
… …  
113 }}
  
114 FCS
  Séquence de contrôle de 
trame  
115
 
116 Flag
  Drapeau de fin  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 528  
__________  
▼B 
5.6 Transfert de données entre la DSRC-VU et la VU  
5.6.1  Connexion physique 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 communi ­
cation sans fil de courte portée reposant sur le protocole 
Bluetooth v4.0 BLE.  
DSC_67 Indépendamment du choix de la connexion physique et de 
l'interface, les exigences suivantes doivent être satisfaites:  
DSC_68  ►M1 a) Pour que la fourniture de la VU et de la DSRC- 
VU, voire de différents lots de la DSRC-VU, 
puisse être sous-traitée à plusieurs fournisseurs, la 
connexion reliant la VU et la DSRC-VU non 
interne à la VU doit être une connexion ouverte 
normalisée. La VU doit être connectée à la DSRC- 
VU ◄ 
i) via un câble fixe de 2 mètres au minimum 
avec un connecteur mâle homologué à 11 
broches Straight DIN 41612 H11 sur la 
DSRC-VU, s'emboîtant dans un connecteur 
femelle homologué DIN/ISO correspondant 
sur la VU;  
ii) via Bluetooth Low Energy (BLE); ou  
iii) via une connexion normalisée ISO 11898 ou 
SAE J1939.  
DSC_69 b) a définition des interfaces et de la connexion entre la VU 
et la DSRC-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 DSRC-VU doivent permettre l'opération de 
transfert de données par la connexion en termes de perfor ­
mance et d'alimentation électrique.  
5.6.2  Protocole d'application  
DSC_71 Le protocole d'application entre le dispositif de communica ­
tion à distance de la VU et la DSRC-VU est responsable du 
transfert régulier des données de communication à distance de 
la VU vers le DSRC.  
DSC_72 Les principales commandes suivantes sont identifié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'identificateur 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édentes peuvent être définies 
comme suit:  ▼M2
 02016R0799 — FR — 26.02.2020 — 002.001 — 529
  
DSC_74 La description des commandes et des paramètres est la 
suivante:  
—
 
sert à initialiser la liaison de communication. Les 
commandes sont adressées par la VU à la DSRC-VU. 
Le LinkIdentifier est défini par la VU et communiqué à 
la DSRC-VU pour suivre une liaison de communication 
spécifique.  
(Note: 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 DSRC-VU pour fournir la réponse à la demande 
d'initialiser la liaison de communication. La commande est 
adressée par la DSRC-VU à la VU. La commande fournit 
le résultat de l'initialisation à titre de réponse = 1 (Réus ­
site) ou =0 (Échec).  
DSC_75 L'initialisation de la liaison de communication a lieu après 
l'installation, l'étalonnage et le démarrage du moteur ou de 
la VU.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 530  
—
 sert à la VU pour envoyer les 
RCDTData signées (c'est-à-dire, les  données de communi ­
cation à distance ) à la DSRC-VU. Les données sont 
envoyées toutes les 60 secondes. Le paramètre DataTran ­
sactionId identifie la transmission spécifique de données. 
Le LinkIdentifier sert également à faire en sorte que la 
liaison appropriée soit correcte.  
—
 est envoyé par la 
DSRC-VU pour apporter un retour à la VU quant à la 
réception des données à partir d'une commande
  
identifiée par le paramètre Data ­
TransactionId. 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 
Acknowledgment pour un RCDT — Send Data antérieur 
avec un DataTransactionId spécifique, la VU génère et 
mémorise un événement.  
—
 
est envoyé par la VU à la DSRC-VU pour mettre fin à 
une liaison avec un LinkIdentifier spécifique.  
DSC_76 Au redémarrage de la DSRC-VU ou d'une VU, il est néces ­
saire de supprimer toutes les liaisons de communication exis ­
tantes, car il pourrait demeurer des liaisons «fantômes» du fait 
de la coupure brutale d'une VU.  
—
 
est envoyé par la DSRC-VU à la VU pour confirmer la 
demande de fin de la liaison de la VU pour le LinkIden ­
tifier spécifique.  
5.7 Traitement des erreurs  
5.7.1  Enregistrement et communication des données dans la DSRC-VU  
▼M1 
DSC_77  Les données  sont fournies déjà sécurisé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 satisfai ­
sante. L’enregistrement et le signalement de toutes les 
erreurs survenues pendant le transfert de données depuis la  
VU vers la mémoire de la  DSRC-VU  doivent être consignés 
avec le type EventFaultType et la valeur enum d’erreur de 
communication ‘0C’H Communication error with the remote 
communication facility, ainsi que l’horodatage.  
▼B 
DSC_78 La  VU tient à jour un fichier identifié par un intitulé unique 
aisément identifiable par les inspecteurs aux fins de l'enregis ­
trement des «Anomalies de communication internes à la VU».  
DSC_79 Si la VUPM tente d'obtenir les données VU du module de sécu ­
rité (pour les transférer à la DSRC-VU), mais échoue, elle doit 
mémoriser cet échec avec le type EventFaultType 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  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 531  
consécutives, un message
  
n'est pas reçu pour le
  correspondant 
(c'est-à-dire muni du même DataTransactionId
  
). 
5.7.2  Anomalies de communication sans fil  
DSC_80 La gestion des anomalies de communication est cohérente 
avec les dispositions des normes DSRC, à savoir EN 300 
674-1, EN 12253, EN 12795, EN 12834 et les paramètres 
appropriés de la norme EN 13372.  
5.7.2.1  Anomalies de cryptage et de signature  
DSC_81 Les anomalies de cryptage et de signature sont gérées confor ­
mément aux dispositions de l'appendice 11 Mécanismes 
communs de sécurité et ne figurent pas dans les messages 
d'erreur associés au transfert de données DSRC.  
5.7.2.2  Relevé des anomalies  
Le support DSRC désigne une communication sans fil dynamique dans 
un environnement marqué par des conditions atmosphériques et d'inter ­
férences incertaines, en particulier dans les cas où sont combinés le 
REDCR portable et le véhicule en circulation impliqués dans cette appli ­
cation. Il est donc nécessaire de distinguer une «anomalie de lecture» 
d'une condition d'«erreur». 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 plupart des cas mènent à une 
connexion de communication réussie et au transfert des données, sauf 
si le véhicule ciblé devient hors portée pendant le temps nécessaire à la 
retransmission. (Une instance «réussie» de «lecture» peut requérir 
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 à proxi ­
mité 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ériques (p. ex. pendant 
un orage); ou simplement en raison d'un déplacement hors de la portée 
de la communication DSRC. Les cas individuels d'anomalies de lecture, 
par essence, ne peuvent pas faire l'objet d'un relevé. En effet, la commu ­
nication n'a pas eu lieu.  
Cependant, si l'agent des autorités de contrôle compétentes cible un 
véhicule et tente d'interroger sa  DSRC-VU , mais qu'aucun transfert de 
données n'aboutit, cette anomalie peut s'expliquer par une falsification 
délibérée. Par conséquent, l'agent des autorités de contrôle compétentes a 
besoin d'un moyen de consigner l'anomalie et d'alerter ses collègues en 
aval d'un risque d'infraction. Les collègues peuvent intercepter le véhi ­
cule et procéder à une inspection physique. Toutefois, aucune commu ­
nication n'ayant abouti, la DSRC-VU ne peut fournir aucune donnée 
concernant cette anomalie. Ce type de rapport doit donc être une fonc ­
tion intégrée à la conception de l'équipement du REDCR.  
L'«anomalie de lecture» est techniquement différente d'une «erreur». 
Dans ce contexte, une «erreur» désigne l'acquisition d'une valeur fausse.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 532  
Les données transférées à la  DSRC-VU  sont fournies déjà sécurisé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érieurement par l'interface 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 tellement 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éception des données exactes, 
la situation n'entraîne pas une erreur, mais une instanciation d'une caté ­
gorie spécifique d'anomalie de lecture.  
Les seules données d'«anomalie» significatives qui peuvent être enregis ­
trées sont le nombre d'initiations de transactions réussies qui ne se 
concluent pas par un transfert des données au REDCR.  
DSC_82 Le  REDCR  doit donc mémoriser et horodater le nombre de 
transactions pour lesquelles la phase d'«initialisation» d'une 
interrogation DSRC a abouti, mais qui ont été interrompues 
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étentes 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 auto ­
rités de contrôle compétentes.  
Les seules données d'«erreur» significatives qui peuvent être 
enregistrées sont le nombre de fois où le REDCR échoue à 
décrypter  les données  reçues. Cependant, il est à noter que 
cela ne concerne que l'efficience du logiciel REDCR. Les 
données peuvent être décryptées techniquement, mais pas 
interprétées du point de vue sémantique.  
DSC_83 Le  REDCR  enregistre et horodate par conséquent le nombre 
de tentatives infructueuses de décryptage des données reçues 
par l'interface DSRC.  
6 MISE EN SERVICE ET ESSAIS D'INSPECTION PÉRIODIQUES 
RELATIFS À LA FONCTION DE COMMUNICATION À DISTANCE  
6.1 Généralités  
DSC_84 Deux catégories 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écurité de bout en bout pour s'assurer qu'une 
carte d'atelier est en mesure d'accéder au contenu 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ésente section contient des dispositions spécifiques pour vérifier 
uniquement l'activité fonctionnelle de la liaison  DSRC-REDCR  
>>-:-< DSRC-VU . ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 533  
L'objectif de la commande ECHO est de permettre aux ateliers ou aux 
infrastructures d'essai d'homologation de vérifier que la liaison DSRC 
fonctionne sans devoir accéder aux éléments d'authentification de sécu ­
rité. L'équipement d'essai doit donc uniquement être en mesure d'initia ­
liser une communication DSRC (envoi d'une BST avec AID = 2), d'en ­
voyer la commande ECHO et, dans l'hypothèse où la communication 
DSRC fonctionne, de recevoir la réponse ECHO. Cf. 5.4.8 pour davan ­
tage de détails. Dans l'hypothèse où cette réponse est reçue correctement, 
le fonctionnement de la liaison DSRC ( DSRC-REDCR  >>-:-<  DSRC- 
VU) peut être validé comme satisfaisant.  
6.3 Essais de validation du contenu des données sécurisées  
DSC_85 Cet essai sert à valider le flux de données de bout en bout sur 
le plan de la sécurité. Il est nécessaire de disposer d'un lecteur 
d'essai DSRC pour procéder à cet essai. Le lecteur d'essai 
DSRC assure les mêmes fonctionnalités et est mis en œuvre 
selon les mêmes spécifications que le lecteur utilisé par les 
agents de la force publique, avec une seule différence, à 
savoir qu'une carte d'atelier est utilisée pour authentifier l'uti ­
lisateur 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 tachygraphe intelligent ou à la fin de la procédure d'éta ­
lonnage. Après son activation, l'unité embarquée sur le véhi ­
cule génère et communique à la DSRC-VU les données sécu ­
risées de détection précoce.  
DSC_86 Le personnel d'atelier doit placer le lecteur d'essai DSRC à 
une distance située entre 2 et 10 mètres devant le véhicule.  
DSC_87 Le personnel d'atelier doit ensuite insérer une carte d'atelier 
dans le lecteur d'essai DSRC pour adresser une interrogation 
portant sur les données de détection précoce à l'unité embar ­
quée sur le véhicule. Après une interrogation réussie, le 
personnel d'atelier accède aux données reçues pour vérifier 
que leur intégrité et leur décryptage sont validés.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 534  
Appendice 15  
MIGRATION: GÉRER LA COEXISTENCE DE PLUSIEURS 
GÉNÉRATIONS D'ÉQUIPEMENTS  
TABLE DES MATIÈRES  
1. DÉFINITIONS  
2. DISPOSITIONS GÉNÉRALES  
2.1. Présentation de la transition  
2.2. Interopérabilité entre les unités embarquées sur les véhicules et les cartes  
2.3. Interopérabilité entre les unités embarquées sur les véhicules et les capteurs 
de mouvement  
2.4. Interopérabilité entre les unités embarquées sur les véhicules, les cartes 
tachygraphiques et l'équipement de téléchargement de données  
2.4.1 Téléchargement direct de carte par IDE  
2.4.2 Téléchargement de carte via une unité embarquée sur un véhicule  
2.4.3 Téléchargement d'unité embarquée sur un véhicule  
2.5. Interopérabilité entre les unités embarquées sur les véhicules et l'équipe ­ 
ment d'étalonnage  
3. PRINCIPALES ÉTAPES PRÉCÉDANT LE LANCEMENT  
4. DISPOSITIONS RELATIVES À LA PÉRIODE QUI SUIT LE LANCE ­ 
MENT  
1. DÉFINITIONS  
Aux fins du présent appendice, les définitions suivantes sont applicables:  
tachygraphe intelligent : tel que défini à la présente annexe (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ésente annexe (cha ­
pitre 1: définition ccc);  
équipement spécialisé intelligent (IDE) : équipement servant à télé ­
charger des données, comme défini à l'appendice 7 de la présente 
annexe.  
2. DISPOSITIONS GÉNÉRALES  
2.1. Présentation de la transition  
Le préambule de la présente annexe présente la transition de la première 
à la deuxième génération de tachygraphes.  
Outre les dispositions de ce préambule:  
— La première génération de capteurs de mouvement ne sera pas inter ­
opé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 capteurs 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.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 535  
— le téléchargement de données et l'équipement d'étalonnage devront 
évoluer pour être compatibles avec les deux générations d'équipe ­
ment d'enregistrement et de cartes tachygraphiques.  
2.2. Interopérabilité entre les unités embarquées sur les véhicules et les 
cartes  
▼M1 
Il est entendu que la première génération de cartes tachygraphiques est 
interopérable avec la première génération d’unités embarquées sur les 
véhicules (conformément à l’annexe 1B du règlement (CEE) n  o 3821/85), 
alors que la deuxième génération de cartes tachygraphiques est inter ­
opérable avec la deuxième génération d’unités embarquées sur les véhi ­
cules (conformément à l’annexe IC de la présente directive). De plus, les 
exigences ci-dessous s’appliquent.  
▼B 
MIG_001 Hormis les dispositions prévues aux exigences MIG_004 et 
MIG_005, les cartes tachygraphiques 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étenteurs peuvent toutefois demander 
leur replacement par des cartes tachygraphiques 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 pourront utiliser toute carte de conducteur, de contrô ­
leur et d'entreprise valides de première génération qui auront 
été insérés.  
MIG_003 Les ateliers pourraient supprimer définitivement cette possi ­
bilité dans lesdites unités embarquées sur les véhicules, de 
sorte que la première génération de cartes tachygraphiques ne 
serait plus acceptée. Cela ne pourrait avoir lieu qu'après que 
la Commission européenne ait lancé une procédure visant à 
demander aux ateliers de procéder ainsi, par exemple, lors de 
chaque inspection périodique du tachygraphe.  
MIG_004 La deuxième génération d'unités embarquées sur des véhi ­
cules ne pourra 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 
consulter les types de cartes valides insérées, indépendam ­
ment de leur génération.  
MIG_006 Toute carte tachygraphique de deuxième génération valide 
pourra être utilisée sur des unités embarquées de première 
génération exactement de la même manière qu'une carte 
tachygraphique 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 mouvement  
Il est entendu que la première génération de capteurs 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 capteurs de mouvement 
est interopérable avec la deuxième génération d'unités embarquées sur 
les véhicules. De plus, les exigences ci-dessous s'appliquent.  
MIG_007 Les unités embarquées sur les véhicules de deuxième géné ­
ration ne pourront pas être couplées et utilisées les capteurs 
de mouvement de première génération.  
MIG_008 Les capteurs de mouvement de deuxième génération pourront 
ê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éhi ­
cules.  
2.4. Interopérabilité entre les unités embarquées sur les véhicules, les 
cartes tachygraphiques et l'équipement de téléchargement de 
données  
MIG_009 L'équipement de téléchargement de données peut être utilisé 
avec une seule génération d'unités embarquées sur des véhi ­
cules et de cartes tachygraphiques ou avec les deux.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 536  
2.4.1  Téléchargement direct de carte par IDE  
MIG_010 Les données sont téléchargées par IDE depuis les cartes 
tachygraphiques d'une génération qui ont été insérées dans 
les lecteurs de cartes, selon les mécanismes de sécurité et les 
protocoles de téléchargement des données de cette généra ­
tion, et les données téléchargées sont au format défini pour 
ladite génération.  
MIG_011 Pour permettre le contrôle des conducteurs par des autorités 
de contrôles autres que celles de l'UE, il sera également 
possible de télécharger des cartes de conducteurs (et d'ate ­
liers) de deuxième génération de la même manière que les 
cartes de conducteurs (et d'ateliers) de première génération. 
Ce type de téléchargement inclura:  
▼M1 
— EF ICC, IC non signés (facultatif),  
▼B 
— des EF (de première génération)
  
et
 non signés,  
▼M1 
— d’autres EF de données d’application (au sein du DF 
Tachograph) nécessaires au protocole de téléchargement 
des cartes de première génération. Ces informations 
seront protégées par une signature numérique conformé ­
ment aux mécanismes de sécurité de première génération.  
Ce type de téléchargement n’inclura pas d’EF de données 
d’application uniquement présents sur les cartes de conduc ­
teur (et d’atelier) de deuxième génération (EF de données 
d’application au sein du DF Tachograph_G2).  
▼B 
2.4.2  Téléchargement de carte via une unité embarquée sur un véhicule  
MIG_012 Les données sont téléchargé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échargement 
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échargées auront le même format que les données 
téléchargé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échargement 
de données défini à l'appendice 7 de la présente 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échargées auront le format défini pour les cartes 
de première génération.  
2.4.3  Téléchargement d'unité embarquée sur un véhicule  
▼M1 
MIG_014 En dehors du cadre du contrôle d’un conducteur par des 
autorités de contrôle autre que celles de l’UE, les données 
sont téléchargées depuis une unité embarquée sur véhicule de 
deuxième génération selon les mécanismes de sécurité de 
deuxième génération et le protocole de téléchargement de 
données défini à l’appendice 7 de la présente annexe.  
MIG_015 Pour permettre le contrôle des conducteurs par des autorités 
de contrôle autres que celles de l’UE, il peut également être 
rendu possible de télécharger des données depuis des unités 
embarquées sur véhicule de deuxième génération selon les 
mécanismes de sécurité de première génération. Les données 
téléchargées auront alors 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élec ­
tionnée grâce aux commandes du menu.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 537  
2.5. Interopérabilité entre les unités embarquées sur les véhicules et l'équi ­
pement d'étalonnage  
MIG_016 L'équipement d'étalonnage pourra procéder à l'étalonnage de 
chaque génération de tachygraphe selon le protocole d'éta ­
lonnage de cette génération. L'équipement d'étalonnage peut 
être utilisé avec une seule génération de tachygraphe ou avec 
les deux.  
3. PRINCIPALES ÉTAPES PRÉCÉDANT LE LANCEMENT  
MIG_017 Les clés et les certificats 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 fabricants au plus tard  15 mois  avant la date 
d'introduction.  
MIG_019 Les clés et les certificats officiels seront à la disposition des 
fabricants au moins  12 mois  avant la date d'introduction.  
MIG_020 Les États membres pourront émettre des cartes d'ateliers de 
deuxième génération au plus tard  3 mois  avant la date d'in ­
troduction.  
MIG_021 Les États membres pourront émettre tous les types de cartes 
tachygraphiques de deuxième génération au plus tard  1 mois 
avant le lancement . 
4. DISPOSITIONS RELATIVES À LA PÉRIODE QUI SUIT LE LANCE ­
MENT  
MIG_022 Après la date d'introduction, les États membres n'émettront 
que des cartes tachygraphiques de deuxième génération.  
MIG_023 Les fabricants d'unités embarquées sur un véhicule ou de 
capteurs de mouvement seront autorisés à produire des 
unités embarquées sur un véhicule ou des capteurs de 
mouvement de première génération tant qu'ils resteront 
utilisés sur le terrain, de façon à pouvoir remplacer les 
composants qui dysfonctionneraient.  
MIG_024 Les fabricants d'unités embarquées sur un véhicule ou de 
capteurs de mouvement seront autorisés à demander et à 
obtenir le maintien de l'homologation pour des unités embar ­
quées sur un véhicule ou des capteurs de mouvement de 
première génération dont le type est déjà homologué.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 538  
Appendice 16  
ADAPTATEUR POUR LES VÉHICULES DES TYPES M 1 ET N1  
TABLE DES MATIÈRES  
1. ABRÉVIATIONS ET DOCUMENTS DE RÉFÉRENCE  
1.1. Abréviations  
1.2. Normes de référence  
2. CARACTÉRISTIQUES GÉNÉRALES ET FONCTIONS DE L'ADAP ­ 
TATEUR  
2.1. Description générale de l'adaptateur  
2.2. Fonctions  
2.3. Sécurité  
3. EXIGENCES RELATIVES À L'APPAREIL DE CONTRÔLE 
LORSQU'UN ADAPTATEUR EST INSTALLÉ  
4. EXIGENCES DE CONSTRUCTION ET DE FONCTIONNEMENT DE 
L'ADAPTATEUR  
4.1. Connexion et adaptation des impulsions de vitesse entrantes  
4.2. Orientation des impulsions entrantes vers le capteur de mouvement intégré  
4.3. Capteur de mouvement intégré  
4.4. Exigences de sécurité  
4.5. Caractéristiques de performance  
4.6. Matériaux  
4.7. Inscriptions  
5. INSTALLATION DE L'APPAREIL DE CONTRÔLE LORSQU'UN 
ADAPTATEUR EST UTILISÉ  
5.1. Installation  
5.2. Scellement  
6. CONTRÔLES, INSPECTIONS ET RÉPARATIONS  
6.1. Inspections périodiques  
7. HOMOLOGATION DE L'APPAREIL DE CONTRÔLE LORSQU'UN 
ADAPTATEUR EST UTILISÉ  
7.1. Points généraux  
7.2. Certificat fonctionnel  
1. ABRÉVIATIONS 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. Normes de référence  
ISO 16844-3 Véhicules routiers — Systèmes tachygraphiques — Partie 3: 
Interface des capteurs de mouvement  
2. CARACTÉRISTIQUES GÉNÉRALES ET FONCTIONS DE L'ADAPTA ­
TEUR  
2.1. Description générale de l'adaptateur  
ADA_001 L'adaptateur fournit une VU connectée avec des données de 
mouvement sécurisées représentatives de la vitesse du véhicule 
et de la distance parcourue.  
L'adaptateur est conçu uniquement pour les véhicules qui 
doivent être munis d'un appareil de contrôle conformément 
au présent règlement.  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 539  
Il est installé et utilisé uniquement dans les types de véhicule 
définis au point yy) «adaptateur», lorsqu'il n'est pas mécani ­
quement possible d'installer un autre type de capteur de 
mouvement existant conforme par ailleurs aux dispositions de 
la présente annexe et de ses appendices 1 à 16.  
L'adaptateur n'est pas mécaniquement connecté à un élément 
mobile du véhicule mais connecté aux impulsions de vitesse/ 
distance produites par des capteurs intégrés ou d'autres inter ­
faces.  
ADA_002 Un capteur de mouvement homologué (conformément aux 
dispositions de la présente annexe IC, section 8 — Homolo ­
gation de l'appareil de contrôle et des cartes tachygraphiques) 
est installé dans le boîtier de l'adaptateur, qui comporte égale ­
ment un convertisseur d'impulsions générant des impulsions 
entrantes dirigées vers le capteur de mouvement intégré. Le 
capteur de mouvement intégré lui-même est connecté à la 
VU, si bien que l'interface entre la VU et l'adaptateur est 
conforme aux exigences de la norme ISO 16844-3.  
2.2. Fonctions  
ADA_003 L'adaptateur comporte les fonctions suivantes:  
— interfaçage et adaptation des impulsions de vitesse 
entrantes;  
— orientation des impulsions entrantes vers le capteur de 
mouvement intégré;  
— toutes les fonctions du capteur de mouvement intégré, four ­
nissant des données de mouvement sécurisées à la VU.  
2.3. Sécurité  
ADA_004 La sécurité de l'adaptateur n'est pas certifiée conforme aux 
objectifs de sécurité générique du capteur de mouvement 
définis à l'appendice 10 de la présente annexe, mais conforme 
aux exigences de sécurité spécifiées au point 4.4 du présent 
appendice.  
3. EXIGENCES RELATIVES À L'APPAREIL DE CONTRÔLE 
LORSQU'UN ADAPTATEUR EST INSTALLÉ  
Les exigences figurant dans le présent chapitre et dans les chapitres 
suivants indiquent comment les exigences énoncées dans la présente 
annexe doivent être comprises lorsqu'un adaptateur est utilisé. Les 
numéros des exigences concernées sont indiqués entre parenthèses.  
ADA_005 L'appareil de contrôle de tout véhicule équipé d'un adaptateur 
doit être conforme à toutes les dispositions de la présente 
annexe, sauf indications contraires dans le présent appendice.  
ADA_006 Lorsqu'un adaptateur est installé, l'appareil de contrôle 
comporte des câbles, l'adaptateur (comprenant un capteur de 
mouvement) et une VU (01).  
ADA_007 La fonction de détection 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'in ­
terruption de l'alimentation électrique du capteur de mouve ­
ment intégré (79) dépassant 200 millisecondes (ms);  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 540  
— l'événement «erreur sur les données de mouvement» est 
déclenché par la VU en cas d'interruption du flux de 
données normal entre le capteur de mouvement intégré et 
la VU et/ou en cas d'anomalie d'intégrité ou d'authentifica ­
tion de données au cours de l'échange de données entre le 
capteur de mouvement intégré et la VU (83);  
— l'événement «tentative d'atteinte à la sécurité» est déclenché 
par la VU pour tout autre événement affectant la sécurité 
du capteur 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 toute 
anomalie du capteur de mouvement intégré (88).  
ADA_008 Les anomalies de l'adaptateur détectables par l'appareil de 
contrôle sont celles liées au capteur de mouvement intégré 
(88).  
ADA_009 La fonction d'étalonnage de la VU permet de coupler automa ­
tiquement le capteur de mouvement intégré à la VU (202, 204).  
4. EXIGENCES DE CONSTRUCTION ET DE FONCTIONNEMENT DE 
L'ADAPTATEUR  
4.1. Connexion et adaptation des impulsions de vitesse entrantes  
ADA_011 L'interface d'entrée de l'adaptateur accepte des impulsions de 
fréquences représentatives de la vitesse du véhicule et de la 
distance parcourue. Les caractéristiques électriques des impul ­
sions entrantes sont:  à déf. par le fabricant . Les ajustements 
réalisables uniquement par le fabricant de l'adaptateur et l'ate ­
lier agréé qui procède à l'installation de l'adaptateur permettent 
le bon interfaçage de l'adaptateur au véhicule, le cas échéant.  
ADA_012 L'interface d'entrée de l'adaptateur peut, le cas échéant, multi ­
plier ou diviser les impulsions de fréquence des impulsions de 
vitesse entrantes par un facteur fixe pour adapter le signal à la 
fourchette 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'adaptateur et 
l'atelier agréé qui effectue l'installation de l'adaptateur.  
4.2. Orientation des impulsions entrantes vers le capteur de mouvement 
intégré  
ADA_013 Les impulsions entrantes, éventuellement adaptées comme 
indiqué ci-dessus, sont orientées vers le capteur de mouvement 
intégré de manière que chaque impulsion entrante soit détectée 
par le capteur de mouvement.  
4.3. Capteur de mouvement intégré  
ADA_014 Le capteur de mouvement intégré est stimulé par les impul ­
sions, 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éhi ­
cule.  
ADA_015 Les données d'identification du capteur de mouvement intégré 
sont utilisées par la VU pour identifier l'adaptateur (95).  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 541  
ADA_016 Les données d'installation stockées dans le capteur de mouve ­
ment intégré sont considérées comme représentant les données 
d'installation de l'adaptateur (122).  
4.4. Exigences de sécurité  
ADA_017 Le boîtier de l'adaptateur doit être inviolable. Il est scellé de 
manière à ce que toute tentative de manipulation soit aisément 
décelable (par exemple, lors d'une inspection visuelle, voir 
ADA_035). Les scellements répondent aux mêmes exigences 
que les scellements des capteurs de mouvement (398 à 406)  
ADA_018 Il doit être impossible de retirer le capteur de mouvement 
intégré de l'adaptateur sans rompre le(s) scellement(s) du 
boîtier de l'adaptateur ni sans rompre le scellement entre le 
capteur et le boîtier de l'adaptateur (voir ADA_034).  
ADA_019 L'adaptateur garantit que les données de mouvement ne 
peuvent être traitées et extraites qu'à partir de l'entrée de l'adap ­
tateur.  
4.5. Caractéristiques de performance  
ADA_020 L'adaptateur fonctionne correctement dans la fourchette de 
températures définie par le fabricant.  
ADA_021 L'adaptateur fonctionne correctement dans une fourchette de 
taux d'humidité allant de 10 % à 90 % (214).  
ADA_022 L'adaptateur est protégé contre les surtensions, l'inversion de 
polarités et les courts-circuits (216).  
ADA_023 L'adaptateur doit:  
— soit réagir à un champ magnétique qui perturbe la détection 
des mouvements du véhicule. Dans ces circonstances, 
l'unité embarquée enregistrera et stockera une anomalie 
du capteur (88),  
— soit posséder un élément de détection qui soit protégé des 
champs magnétiques ou insensible à ceux-ci (217).  
ADA_024 L'adaptateur est conforme à la réglementation internationale 
R10 de la CEE-ONU, relative à la compatibilité électromagné ­
tique, et est protégé contre les décharges électrostatiques et les 
transitoires (218).  
4.6. Matériaux  
ADA_025 L'adaptateur satisfait au niveau de protection ( à déf. par le 
fabricant, en fonction de la position de l'installation ) (220, 
221).  
ADA_026 Le boîtier de l'adaptateur est jaune.  
4.7. Inscriptions  
ADA_027 Une plaque signalétique est fixée sur l'adaptateur et comporte 
les indications suivantes:  
— nom et adresse du fabricant de l'adaptateur;  
— numéro de pièce du fabricant et année de fabrication de 
l'adaptateur;  
— marque d'homologation du type d'adaptateur ou de l'appa ­
reil de contrôle incluant l'adaptateur;  
— date d'installation de l'adaptateur;  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 542  
— numéro d'identification du véhicule sur lequel il est installé.  
ADA_028 La plaque signalétique comporte aussi les indications suivantes 
(si elles ne sont pas directement visibles de l'extérieur du 
capteur de mouvement intégré):  
— nom du fabricant du capteur de mouvement intégré;  
— numéro de pièce du fabricant et année de fabrication du 
capteur de mouvement intégré;  
— marque d'homologation du capteur de mouvement intégré.  
5. INSTALLATION DE L'APPAREIL DE CONTRÔLE LORSQU'UN 
ADAPTATEUR EST UTILISÉ  
5.1. Installation  
ADA_029 Les adaptateurs à installer sur les véhicules le sont uniquement 
par des fabricants de véhicules ou par des ateliers agréés auto ­
risés à installer, activer et calibrer les tachygraphes numériques 
et intelligents.  
ADA_030 L'atelier agréé qui installe l'adaptateur ajuste l'interface d'entrée 
et choisit le taux de division du signal d'entrée (le cas échéant).  
ADA_031 L'atelier agréé qui installe l'adaptateur scelle le boîtier de 
l'adaptateur.  
ADA_032 L'adaptateur 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'adaptateur 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ées:  
— le boîtier de l'adaptateur est scellé (voir ADA_017);  
— le boîtier du capteur intégré est scellé au boîtier de l'adap ­
tateur, à moins qu'il ne soit pas possible de retirer le 
capteur intégré sans rompre le(s) scellement(s) du boîtier 
de l'adaptateur (voir ADA_018);  
— le boîtier de l'adaptateur est scellé au véhicule;  
— la connexion entre l'adaptateur 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 possi ­
ble). 
6. CONTRÔLES, INSPECTIONS ET RÉPARATIONS  
6.1. Inspections périodiques  
ADA_035 Lorsqu'un adaptateur est utilisé, chaque inspection périodique 
(conformément aux exigences 409 à 413 de l'annexe 1C) de 
l'appareil de contrôle comporte les vérifications suivantes:  
— l'adaptateur porte les marques d'homologation appropriées;  
— les scellements placés sur l'adaptateur et ses connexions 
sont intacts;  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 543  
— l'adaptateur est installé comme indiqué sur la plaquette 
d'installation;  
— l'adaptateur est installé comme indiqué par le fabricant de 
l'adaptateur et/ou du véhicule;  
— le montage d'un adaptateur est autorisé pour le véhicule 
inspecté.  
ADA_036 Ces inspections comprennent un étalonnage et un remplace ­
ment de tous les scellements, quel que soit leur état.  
7. HOMOLOGATION DE L'APPAREIL DE CONTRÔLE LORSQU'UN 
ADAPTATEUR EST UTILISÉ  
7.1. Points généraux  
ADA_037 L'appareil de contrôle est soumis pour homologation tout 
entier, muni de l'adaptateur (425).  
ADA_038 Tout adaptateur peut être soumis pour homologation en tant 
que tel ou en tant que composant d'un appareil de contrôle.  
ADA_039 Cette homologation doit inclure des essais fonctionnels portant 
sur l'adaptateur. Les résultats positifs de chacun de ces essais 
sont établis par un certificat approprié (426).  
7.2. Certificat fonctionnel  
ADA_040 Le certificat fonctionnel de l'adaptateur ou de l'appareil de 
contrôle comportant un adaptateur n'est délivré au fabricant 
de l'adaptateur que si les essais fonctionnels minimaux suivants 
ont été passés avec succès.  
N o Essai  Description  Exigences connexes  
1. Examen administratif  
1.1 Documentation  Exactitude de la 
documentation de 
l'adaptateur  
2. Inspection visuelle  
2.1. Conformité de l'adaptateur avec la documentation  
2.2. Identification / marquages de l'adaptateur  ADA_027, 
ADA_028  
2.3 Matériaux de l'adaptateur  (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 
capteur de mouvement intégré  ADA_013  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 544  
N o Essai  Description  Exigences connexes  
3.2 Interfaçage 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 environnementaux  
4.1 Résultats des essais menés 
par le fabricant  Résultats des essais 
environnementaux 
du fabricant  ADA_020, 
ADA_021, 
ADA_022, 
ADA_024  
5. Essais de compatibilité électromagnétique  
5.1 Émissions rayonnées et 
susceptibilité  S'assurer de la 
conformité 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 fabricant  ADA_024  ▼B
 02016R0799 — FR — 26.02.2020 — 002.001 — 545  
ANNEXE II  
MARQUE ET CERTIFICAT D'HOMOLOGATION  
I. MARQUE D'HOMOLOGATION  
1. La marque d'homologation est composée:  
a) d'un rectangle à 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'homologation, conformément aux conventions suivantes: 
Belgique  6,  
Bulgarie  34,  
République tchèque  8,  
Danemark  18,  
Allemagne  1,  
Estonie  29,  
Irlande  24,  
Grèce  23,  
Espagne  9,  
France  2,  
Croatie  25,  
Italie  3,  
Chypre  CY,  
Lettonie  32,  
Lituanie  36,  
Luxembourg  13,  
Hongrie  7,  
Malte  MT,  
Pays-Bas  4,  
Autriche  12,  
Pologne  20,  
Portugal  21,  
Roumanie  19,  
Slovénie  26,  
Slovaquie  27,  
Finlande  17,  
Suède  5,  
Royaume-Uni  11;  
et 
▼M1 
b) d’un numéro d’homologation correspondant au numéro du certificat d’ho ­
mologation établi pour le prototype de l’appareil de contrôle, de la feuille 
d’enregistrement ou de la carte tachygraphique, placé dans une position 
quelconque à proximité immédiate du rectangle.  ▼C1
 02016R0799 — FR — 26.02.2020 — 002.001 — 546  
2. La marque d'homologation est apposée sur la plaque signalétique de chaque 
appareil, sur chaque feuille d'enregistrement et sur chaque carte tachygra ­
phique. Elle doit être indélébile et rester toujours parfaitement lisible.  
3. Les dimensions de la marque d'homologation dessinée ci-après (  1 ) sont expri ­
mées en millimètres, ces dimensions constituant des minima. Les rapports 
entre ces dimensions doivent être respectés.
  ▼C1 
( 1 ) Ces chiffres sont donnés à titre indicatif uniquement.
 02016R0799 — FR — 26.02.2020 — 002.001 — 547  
II. CERTIFICAT D'HOMOLOGATION DES TACHYGRAPHES 
ANALOGIQUES  
L'État membre ayant procédé à l'homologation délivre au demandeur un certificat 
d'homologation, établi selon le modèle figurant ci-après. Des copies de ce certi ­
ficat doivent être utilisées pour informer les autres États membres des homolo ­
gations délivrées ou, le cas échéant, retirées.  
CERTIFICAT D'HOMOLOGATION  
Nom de l'administration compétente  
Communication concernant (  1 ): 
— l'homologation d'un modèle d'appareil de contrôle  
— le retrait d'homologation d'un modèle d'appareil de contrôle  
— l'homologation d'un modèle de feuille d'enregistrement  
— le retrait d'homologation d'un modèle de feuille d'enregistrement  
N o d'homologation:  
...................................  
1. Marque de fabrique ou de commerce  
2. Dénomination du modèle  
3. Nom du fabricant  
4. Adresse du fabricant  
5. Présenté à l'homologation le  
6. Laboratoire(s)  
7. Date et numéro de l'essai ou des essais  
8. Date de l'homologation  
9. Date du retrait de l'homologation  
10. Modèle(s) d'appareil(s) de contrôle sur le(s)quel(s) la feuille est destinée à 
être utilisée  
11. Lieu  
12. Date  
13. Documents descriptifs annexés  
14. Remarques (notamment, le cas échéant, concernant l'emplacement des scel ­
lements)  
(Signature)  ▼C1 
( 1 ) Rayer les mentions inutiles.
 02016R0799 — FR — 26.02.2020 — 002.001 — 548  
III. CERTIFICAT D'HOMOLOGATION DES TACHYGRAPHES 
NUMÉRIQUES  
Un État membre ayant procédé à une homologation délivre au demandeur un 
certificat d'homologation, établi selon le modèle figurant ci-après. Des copies de 
ce certificat doivent être utilisées pour informer les autres États membres des 
homologations délivrées ou, le cas échéant, retirées.  
CERTIFICAT D'HOMOLOGATION DES TACHYGRAPHES NUMÉRIQUES  
Nom de l'administration compétente  
Communication concernant (  1 ): 
□ l'homologation de:  □ le retrait de l'homologation de  
□ un modèle d'appareil de contrôle  
□ un composant d'appareil de contrôle (  2 ) 
□ une carte de conducteur  
□ une carte d'atelier  
□ une carte d'entreprise  
□ une carte d'agent de contrôle  
N o d'homologation:  
1. Marque de fabrique ou marque commerciale  
2. Nom du modèle  
3. Nom du fabricant  
4. Adresse du fabricant  
▼M1 
5. Présenté à l'homologation le  
▼C1 
6. Laboratoire(s)  
7. Date et numéro du procès-verbal du laboratoire  
8. Date de l'homologation  
9. Date du retrait de l'homologation  
10. Modèle(s) d'appareil(s) de contrôle avec le(s)quel(s) le composant est destiné 
à être utilisé  
11. Lieu  
12. Date  
13. Documents descriptifs annexés  
14. Remarques (notamment, le cas échéant, concernant l'emplacement des scel ­
lements)  
(Signature)  ▼C1 
( 1 ) Cochez les cases pertinentes. 
( 2 ) Préciser le composant qui fait l'objet de la notification.
 02016R0799 — FR — 26.02.2020 — 002.001 — 549  
IV. CERTIFICAT D'HOMOLOGATION DES TACHYGRAPHES 
INTELLIGENTS  
Un État membre ayant procédé à une homologation délivre au demandeur un 
certificat d'homologation, établi selon le modèle figurant ci-après. Des copies de 
ce certificat doivent être utilisées pour informer les autres États membres des 
homologations délivrées ou, le cas échéant, retirées.  
CERTIFICAT D'HOMOLOGATION DES TACHYGRAPHES INTELLIGENTS  
Nom de l'administration compétente  
Communication concernant (  1 ): 
□ l'homologation de:  □ le retrait de l'homologation de  
□ un modèle d'appareil de contrôle  
□ un composant d'appareil de contrôle (  2 ) 
□ une carte de conducteur  
□ une carte d'atelier  
□ une carte d'entreprise  
□ une carte d'agent de contrôle  
N o d'homologation:  
1. Marque de fabrique ou marque commerciale  
2. Nom du modèle  
3. Nom du fabricant  
4. Adresse du fabricant  
▼M1 
5. Présenté à l'homologation le  
▼C1 
6. a) Laboratoire d'essai pour la certification de fonctionnement  
b) Laboratoire d'essai pour la certification de sécurité  
c) Laboratoire d'essai pour la certification d'interopérabilité  
7. a) Date et numéro du certificat de fonctionnement  
b) Date et numéro du certificat de sécurité  
c) Date et numéro du certificat d'interopérabilité  
8. Date de l'homologation  
9. Date du retrait de l'homologation  
10. Modèle(s) d'appareil(s) de contrôle avec le(s)quel(s) le composant est destiné 
à être utilisé  
11. Lieu  
12. Date  
13. Documents descriptifs annexés  
14. Remarques (notamment, le cas échéant, concernant l'emplacement des scel ­
lements)  
(Signature)  ▼C1 
( 1 ) Cochez les cases pertinentes. 
( 2 ) Préciser le composant qui fait l'objet de la notification.